ACESSO EXTERNO AO BANCO DE DADOS
Tenho um cliente que montou filial e vou precisar colocar acesso ao banco online. O bd é sql server . Na matriz tem speedy de 8 mega com ip fixo e na filial fibra óptica da net de 10 mega, será que da um acesso legal ? Estou em dúvida porque o upload do speedy é muito baixo. Pesquisando vi que a vivo tem link de dados dedicado, mas parece ser bem caro. Alguém tem esta situação para dar uma luz ?
1 - Esses números 10 mega, 20, 30, se referem a bits, não bytes, portanto uma conexão de 8 megaBITS, equivale a uma conexão de 1 megaBYTES.
2 - Além disso, esses números se referem a banda de download, a de upload costuma ser muito mais estreita
E é justamente essa banda que vai ser exigida, tanto no lado do cliente quanto do servidor. No cliente, você executa uma query cujo texto seja de digamos, 500 bytes e o retorno, são 100 linhas com 30 colunas, sendo 20 delas VARCHAR(10), sem valores null, todas preenchidas, 2 colunas DateTime, e algumas outras numéricas. Com isso você pode fazer uma média: 20 colunas de 10 caracteres, são 200 caracteres, vamos somar mais algo em torno de 50 caracteres para as demais colunas e chegamos à um valor aproximado de 250 caracteres por linha. Multiplicando por 100 linhas teremos um total de dados de 2500 caracteres, ou 2.5 kiloBYTES. Imagine 3 usuários fazendo consultas similares ao mesmo tempo, você vai ter que mandar do servidor para os 3 clientes, um total de 7.5 KB de informação, fora dados de cabeçalho de pacote, que embora sejam fixos, também são informações que são enviadas. Tudo isso em questão de alguns segundos e consumindo a banda de upload do servidor e a banda de download do cliente. Sem falar no consumo de memória e de processamento, que nesse caso não vamos levar em conta.
Mas para que tudo isso possa funcionar, você vai precisar abrir as portas no servidor para que o(s) cliente(s) tenham acesso e isso nos leva à uma questão muitas vezes até negligenciada: segurança. Você terá que [Ô]preparar[Ô] seu sistema para poder se conectar ao SQL Server usando algum tipo de controle de usuário. Talvez até ter que criar um pipe(VPN) para melhorar um pouco a segurança, ou usar um DNS próprio para restringir o acesso de mal intencionados, além de configurações adicionais de Firewall, NAT, DHCP e DNS. Mas isso tudo influi diretamente no desempenho da sua aplicação e também no custo para o cliente. Um IP Fixo não é barato e tende à ficar cada vez mais caro à medida que se tornam mais raros. Também temos que levar em conta que estamos falando de IPv4 e ainda nem mencionamos que o servidor terá que ter suporte à ele, pois a tendência é que aos poucos, o IPv4 caia em desuso, dando lugar ao IPv6. Além de IP fixo, existe também a solução do uso de DNS, o que acarreta na necessidade de registro de um domÃnio por parte do seu cliente, caso este ainda não o possua. E se já possuir, é aconselhável o registro de um sub-domÃnio(quase sempre gratuito) para servir como referenciador para sua conexão remota, sem necessidade do IP fixo, mas isso acarreta em resolução de endereço o que pode piorar um pouco o desempenho, pois para cada chamada ao servidor, o nome de domÃnio deve ser resolvido para IP, isso por parte do seu provedor de domÃnio(DNS).
Aà é que entra o que falo incansavelmente aqui no fórum: o uso de WebAPI. Com ela, você alivia, de cara, o problema da segurança, que é muito melhor gerenciada para serviços que usam a porta 80, como é o caso da WebAPI. Por ser HTTP, ele pode fazer uso de certificados de segurança SSL e TLS como CertiSign, VeriSign ou outro qualquer, o que melhora consideravelmente nesse fator(segurança). A melhora no tráfego de informação também é considerável. trabalhando com dados JSON, você terá pacotes consideravelmente menores que aqueles enviados diretamente(em formato binário) pelo SQL Server. Se tiver curiosidade, posso citar mais várias vantagens do uso de WebAPI, mas vamos nos ater ao seu problema.
Provavelmente seu sistema já está pronto, testado e funcional, pelo menos o bastante para deixar seu cliente confiante o suficiente para expandir o uso para acesso remoto. Então escrever uma WebAPI, pode ser considerado, por enquanto, carta fora do baralho. Como já expliquei acima, existem os fatores, segurança e desempenho que são diretamente afetados pelo uso de um banco de dados [Ô]aberto[Ô]. Por isso, considere começar a desenvolver, ainda que em paralelo, uma WebAPI para ser consumida com seus sistemas, enquanto ainda usa o SQL Server de forma remota.
Qualquer dúvida, basta postar!
2 - Além disso, esses números se referem a banda de download, a de upload costuma ser muito mais estreita
E é justamente essa banda que vai ser exigida, tanto no lado do cliente quanto do servidor. No cliente, você executa uma query cujo texto seja de digamos, 500 bytes e o retorno, são 100 linhas com 30 colunas, sendo 20 delas VARCHAR(10), sem valores null, todas preenchidas, 2 colunas DateTime, e algumas outras numéricas. Com isso você pode fazer uma média: 20 colunas de 10 caracteres, são 200 caracteres, vamos somar mais algo em torno de 50 caracteres para as demais colunas e chegamos à um valor aproximado de 250 caracteres por linha. Multiplicando por 100 linhas teremos um total de dados de 2500 caracteres, ou 2.5 kiloBYTES. Imagine 3 usuários fazendo consultas similares ao mesmo tempo, você vai ter que mandar do servidor para os 3 clientes, um total de 7.5 KB de informação, fora dados de cabeçalho de pacote, que embora sejam fixos, também são informações que são enviadas. Tudo isso em questão de alguns segundos e consumindo a banda de upload do servidor e a banda de download do cliente. Sem falar no consumo de memória e de processamento, que nesse caso não vamos levar em conta.
Mas para que tudo isso possa funcionar, você vai precisar abrir as portas no servidor para que o(s) cliente(s) tenham acesso e isso nos leva à uma questão muitas vezes até negligenciada: segurança. Você terá que [Ô]preparar[Ô] seu sistema para poder se conectar ao SQL Server usando algum tipo de controle de usuário. Talvez até ter que criar um pipe(VPN) para melhorar um pouco a segurança, ou usar um DNS próprio para restringir o acesso de mal intencionados, além de configurações adicionais de Firewall, NAT, DHCP e DNS. Mas isso tudo influi diretamente no desempenho da sua aplicação e também no custo para o cliente. Um IP Fixo não é barato e tende à ficar cada vez mais caro à medida que se tornam mais raros. Também temos que levar em conta que estamos falando de IPv4 e ainda nem mencionamos que o servidor terá que ter suporte à ele, pois a tendência é que aos poucos, o IPv4 caia em desuso, dando lugar ao IPv6. Além de IP fixo, existe também a solução do uso de DNS, o que acarreta na necessidade de registro de um domÃnio por parte do seu cliente, caso este ainda não o possua. E se já possuir, é aconselhável o registro de um sub-domÃnio(quase sempre gratuito) para servir como referenciador para sua conexão remota, sem necessidade do IP fixo, mas isso acarreta em resolução de endereço o que pode piorar um pouco o desempenho, pois para cada chamada ao servidor, o nome de domÃnio deve ser resolvido para IP, isso por parte do seu provedor de domÃnio(DNS).
Aà é que entra o que falo incansavelmente aqui no fórum: o uso de WebAPI. Com ela, você alivia, de cara, o problema da segurança, que é muito melhor gerenciada para serviços que usam a porta 80, como é o caso da WebAPI. Por ser HTTP, ele pode fazer uso de certificados de segurança SSL e TLS como CertiSign, VeriSign ou outro qualquer, o que melhora consideravelmente nesse fator(segurança). A melhora no tráfego de informação também é considerável. trabalhando com dados JSON, você terá pacotes consideravelmente menores que aqueles enviados diretamente(em formato binário) pelo SQL Server. Se tiver curiosidade, posso citar mais várias vantagens do uso de WebAPI, mas vamos nos ater ao seu problema.
Provavelmente seu sistema já está pronto, testado e funcional, pelo menos o bastante para deixar seu cliente confiante o suficiente para expandir o uso para acesso remoto. Então escrever uma WebAPI, pode ser considerado, por enquanto, carta fora do baralho. Como já expliquei acima, existem os fatores, segurança e desempenho que são diretamente afetados pelo uso de um banco de dados [Ô]aberto[Ô]. Por isso, considere começar a desenvolver, ainda que em paralelo, uma WebAPI para ser consumida com seus sistemas, enquanto ainda usa o SQL Server de forma remota.
Qualquer dúvida, basta postar!
Muito bacana e técnica sua explicação, ja tinha uma noção disso tudo, mas o fato é que temos o sistema de gestão que roda interno no cliente, e preciso colocar o acesso a apenas 1 micro na filial ( que na verdade é um depósito) apenas para despacho de cargas, então pensei em colocar o exe do sistema no micro, e se conectar ao servidor pelo ip fixo da matriz, onde vou direcionar a porta no roteador para acesso ao banco. De inicio seria simples assim, a duvida é mesmo a lentidão, por isso pensei no link dedicado da vivo, onde dow e up tem mesma velocidade, sei que é caro, mas ainda não sei o valor, por isso postei aqui para pesquisar com os colegas, as opções...pensei tbm em deixar off na filial, mas ai vou ter que criar rotinas de integração destes dados..
Minha sugestão é a seguinte:
1 - Servidor com Windows Server 2008 em diante
2 - Use os serviços de terminal
3 - Pesquise por serviços da área de trabalho remota
As vantagens são:
1 - Você não precisa expor o banco de dados na net através do IP do seu cliente,
2 - Na filial você só precisa de um computador com acesso a internet e mais nada
O que você precisa fazer:
1 - Seu cliente já tem IP fixo? Então fica fácil essa parte, crie uma VPN, pois é mais seguro do que conectar direto pelo IP
2 - Defina no Windows Server cada usuário que vai acessar o sistema pelo serviço de area de trabalho remota
3 - Cada usuário precisara de uma licença chamada CAL
4 - Defina senha fortes, e defina também que a sessão do usuário será encerrada após x minutos ociosa, dessa forma você libera recursos no servidor liberando os usuários ociosos.
5 - Obviamente que você precisará de um bom servidor, processador x memória pra suportar x usuários conectados simultaneamente.
6 - Seu sistema tem que estar instalado no servidor e apenas nele e rodando direitinho.
Como o seu cenário não lhe permite agora criar uma infraestrutura baseada em WEB API, então essa é a minha sugestão, uso essa técnica a bastante tempo, conectando clientes RECIFE x SALVADOR X SÃO PAULO X RIO DE JANEIRO, onde o servidor fica em SÃO PAULO, com a vantagem ainda que estando no Rio de Janeiro eu posso imprimir um pedido na loja de Recife e vice-versa, cara é muito prático.
Também é uma solução adotada em vários bancos, você só precisará concentrar seus esforços no servidor, garantindo a saúde dele e não permitindo através de diretivas de grupos que os usuários instalem programas no servidor, na verdade você deve configurar o usuário pra que ao acessa o sistema, só abra o sistema e mais nada, na verdade você pode configurar isso de forma automática, ou seja, quando o usuário se logar no terminal já abre a tela do sistema, e ao fechar o sistema fecha também a sessão dele.
Essa é a minha recomendação, conexões de ponta a ponta direto no banco de dados, é um risco muito alto sem falar que por mais que se tenha uma boa internet, vai ficar lento, precisamente o que o KERPLUNK explicou acima.
Abraços
1 - Servidor com Windows Server 2008 em diante
2 - Use os serviços de terminal
3 - Pesquise por serviços da área de trabalho remota
As vantagens são:
1 - Você não precisa expor o banco de dados na net através do IP do seu cliente,
2 - Na filial você só precisa de um computador com acesso a internet e mais nada
O que você precisa fazer:
1 - Seu cliente já tem IP fixo? Então fica fácil essa parte, crie uma VPN, pois é mais seguro do que conectar direto pelo IP
2 - Defina no Windows Server cada usuário que vai acessar o sistema pelo serviço de area de trabalho remota
3 - Cada usuário precisara de uma licença chamada CAL
4 - Defina senha fortes, e defina também que a sessão do usuário será encerrada após x minutos ociosa, dessa forma você libera recursos no servidor liberando os usuários ociosos.
5 - Obviamente que você precisará de um bom servidor, processador x memória pra suportar x usuários conectados simultaneamente.
6 - Seu sistema tem que estar instalado no servidor e apenas nele e rodando direitinho.
Como o seu cenário não lhe permite agora criar uma infraestrutura baseada em WEB API, então essa é a minha sugestão, uso essa técnica a bastante tempo, conectando clientes RECIFE x SALVADOR X SÃO PAULO X RIO DE JANEIRO, onde o servidor fica em SÃO PAULO, com a vantagem ainda que estando no Rio de Janeiro eu posso imprimir um pedido na loja de Recife e vice-versa, cara é muito prático.
Também é uma solução adotada em vários bancos, você só precisará concentrar seus esforços no servidor, garantindo a saúde dele e não permitindo através de diretivas de grupos que os usuários instalem programas no servidor, na verdade você deve configurar o usuário pra que ao acessa o sistema, só abra o sistema e mais nada, na verdade você pode configurar isso de forma automática, ou seja, quando o usuário se logar no terminal já abre a tela do sistema, e ao fechar o sistema fecha também a sessão dele.
Essa é a minha recomendação, conexões de ponta a ponta direto no banco de dados, é um risco muito alto sem falar que por mais que se tenha uma boa internet, vai ficar lento, precisamente o que o KERPLUNK explicou acima.
Abraços
Lampião, mas neste caso o server precisa estar com AD ativo ?, porque é uma rede pequena e o servidor windows 2008 esta como grupo de trabalho apenas, onde esta instalado o BD, e as estações com os EXEs que acessam por IP-Porta. eu ja vi casos de terminal server, onde a filial acessa e trabalha no servidor, a resposta do sistema é rapida, mas o receio é de o usuário acessar e [Ô]mexer[Ô] no servidor. No caso da opção que passei, os dados de conexão ao banco, estão criptografados, mas ai teria o problema da lentidão....
O AD é necessário se você quiser ter um controle maior sobre o que o usuário pode executar ou não, entre outras coisas. Como o seu caso é apenas acessar o sistema, você só precisa configurar cada usuário pra acessar apenas o seu sistema.
Você define isso no nÃvel do usuário, e não coloque ele no grupo Administradores, ele só precisa estar no grupo users, power users, e remote desktop users, e dependendo de como o seu sistema lida com as permissões talvez nem precise estar no grupo power users.
Sobre sua questão do usuário acessar e mexer, ele só conseguirá fazer isso se você der permissão ou se o grupo no qual ele faz parte tiver as permissões pra isso.
A ressalva é: Nunca cadastre um usuário com direitos de administrador, restrinja sempre o máximo que for possÃvel.
No meu cenário, quando o usuário se conecta ao terminal o sistema já iniciliza pra ele de forma automática e já cai na tela de login, se ele minimizar, vai ter uma tela vazia, e se tentar navegar nas pastas pelo Explorer, será solicitado a senha do Administrador, ou seja, ele não consegue instalar nada, não consegue desisntalar nada, e muito menos mexer nas configurações, a única coisa na qual ele tem acesso é o sistema mesmo.
Então tudo vai depender de como você vai configurar o servidor ai ok.
Abraços
Você define isso no nÃvel do usuário, e não coloque ele no grupo Administradores, ele só precisa estar no grupo users, power users, e remote desktop users, e dependendo de como o seu sistema lida com as permissões talvez nem precise estar no grupo power users.
Sobre sua questão do usuário acessar e mexer, ele só conseguirá fazer isso se você der permissão ou se o grupo no qual ele faz parte tiver as permissões pra isso.
A ressalva é: Nunca cadastre um usuário com direitos de administrador, restrinja sempre o máximo que for possÃvel.
No meu cenário, quando o usuário se conecta ao terminal o sistema já iniciliza pra ele de forma automática e já cai na tela de login, se ele minimizar, vai ter uma tela vazia, e se tentar navegar nas pastas pelo Explorer, será solicitado a senha do Administrador, ou seja, ele não consegue instalar nada, não consegue desisntalar nada, e muito menos mexer nas configurações, a única coisa na qual ele tem acesso é o sistema mesmo.
Então tudo vai depender de como você vai configurar o servidor ai ok.
Abraços
Ok. Mas esse acesso seria por terminal server ou área de trabalho remota ?
Depende da versão que for usar, segue abaixo:
RDS - Remote Desktop Services no Windows Server 2012
Ãrea de Trabalho Remota Windows Server 2008
Terminal Server no Windows Server 2003
Abracos
RDS - Remote Desktop Services no Windows Server 2012
Ãrea de Trabalho Remota Windows Server 2008
Terminal Server no Windows Server 2003
Abracos
Lampião, fis um teste, e ativei a area de trabalho remota no win server 2003, após configurei a conexão no meu micro que é win7, após liberar no firewall do win 2003, conectou normal. Porém se eu colocar pra carregar o sistema na conexão, ou mesmo tentar abrir o sistema após conectado, me retorna erro de ocx, pelo que vi na mscomctl.ocx , outdate, ou algo assim, mas só ocorre pela area de trabalho remota, se eu conectar por vnc, teamviewer, etc.. abro o sistema e rodo normal, sera que precisa atualizar algo ?
Grato.
Grato.
Citação::
Minha sugestão é a seguinte:
1 - Servidor com Windows Server 2008 em diante
2 - Use os serviços de terminal
3 - Pesquise por serviços da área de trabalho remota
As vantagens são:
1 - Você não precisa expor o banco de dados na net através do IP do seu cliente,
2 - Na filial você só precisa de um computador com acesso a internet e mais nada
O que você precisa fazer:
1 - Seu cliente já tem IP fixo? Então fica fácil essa parte, crie uma VPN, pois é mais seguro do que conectar direto pelo IP
2 - Defina no Windows Server cada usuário que vai acessar o sistema pelo serviço de area de trabalho remota
3 - Cada usuário precisara de uma licença chamada CAL
4 - Defina senha fortes, e defina também que a sessão do usuário será encerrada após x minutos ociosa, dessa forma você libera recursos no servidor liberando os usuários ociosos.
5 - Obviamente que você precisará de um bom servidor, processador x memória pra suportar x usuários conectados simultaneamente.
6 - Seu sistema tem que estar instalado no servidor e apenas nele e rodando direitinho.
Como o seu cenário não lhe permite agora criar uma infraestrutura baseada em WEB API, então essa é a minha sugestão, uso essa técnica a bastante tempo, conectando clientes RECIFE x SALVADOR X SÃO PAULO X RIO DE JANEIRO, onde o servidor fica em SÃO PAULO, com a vantagem ainda que estando no Rio de Janeiro eu posso imprimir um pedido na loja de Recife e vice-versa, cara é muito prático.
Também é uma solução adotada em vários bancos, você só precisará concentrar seus esforços no servidor, garantindo a saúde dele e não permitindo através de diretivas de grupos que os usuários instalem programas no servidor, na verdade você deve configurar o usuário pra que ao acessa o sistema, só abra o sistema e mais nada, na verdade você pode configurar isso de forma automática, ou seja, quando o usuário se logar no terminal já abre a tela do sistema, e ao fechar o sistema fecha também a sessão dele.
Essa é a minha recomendação, conexões de ponta a ponta direto no banco de dados, é um risco muito alto sem falar que por mais que se tenha uma boa internet, vai ficar lento, precisamente o que o KERPLUNK explicou acima.
Abraços
Lampião aproveitando este tópico, estou pensando em adotar esse método de área de trabalho remota estive fazendo um teste com a impressão e tive problema quando envio para uma impressora matricial (LPT1) você sabe como resolve isto?
Citação::
Lampião, fis um teste, e ativei a area de trabalho remota no win server 2003, após configurei a conexão no meu micro que é win7, após liberar no firewall do win 2003, conectou normal. Porém se eu colocar pra carregar o sistema na conexão, ou mesmo tentar abrir o sistema após conectado, me retorna erro de ocx, pelo que vi na mscomctl.ocx , outdate, ou algo assim, mas só ocorre pela area de trabalho remota, se eu conectar por vnc, teamviewer, etc.. abro o sistema e rodo normal, sera que precisa atualizar algo ?
Grato.
Olá, você precisa garantir que o seu sistema esta instalado e rodando corretamente no servidor, não haverá conexão direta com o sistema, o usuário vai acessar apenas a sessão que foi configurada pra ele, por exemplo: o seu servidor tem o ip 10.1.5.25, então você configura o usuário pra acessar a sua sessão atraves desse IP, e quando sessão for aberta ele vai digitar o usuario e a senha da sessão dele, pra só depois aguardar o sistema abrir ou clicar no icone pra abrir o sistema, o mais correto é abrir de forma automatica o sistema, como havia explicado anteriormente, pra isso vc precisa configurar na conta do usuário.
é bem simples de fazer isso, o que mais demora é configurar cada usuário.
Abraços
Tópico encerrado , respostas não são mais permitidas