Por que não é aconselhável ter o banco de dados e o servidor da web na mesma máquina?

Ao ouvir a entrevista de Scott Hanselman com a equipe do Stack Overflow ( partes 1 e 2 ), ele afirmou que o servidor SQL e o servidor de aplicativos deveriam estar em máquinas separadas. Isso é apenas para garantir que, se um servidor estiver comprometido, os dois sistemas não estejam acessíveis? As preocupações de segurança superam a complexidade de dois servidores (custo extra, conexão de rede dedicada entre os dois, mais manutenção etc.), especialmente para um aplicativo pequeno, em que nenhuma das partes está usando muita CPU ou memória? Mesmo com dois servidores, com um servidor comprometido, um invasor ainda pode causar sérios danos, excluindo o banco de dados ou mexendo no código do aplicativo.

Por que isso seria tão importante se o desempenho não é um problema?

1. Segurança. Seu servidor da Web vive em uma DMZ, acessível à Internet pública e recebendo informações não confiáveis ​​de usuários anônimos. Se seu servidor da Web for comprometido e você seguir regras de privilégios mínimos ao se conectar ao seu banco de dados, a exposição máxima é o que seu aplicativo pode fazer por meio da API do banco de dados. Se você tiver uma camada comercial no meio, terá mais uma etapa entre o invasor e os dados. Se, por outro lado, seu banco de dados estiver no mesmo servidor, o invasor agora terá acesso root aos seus dados e servidor.
2. Escalabilidade. Manter o servidor da Web sem estado permite que você dimensione seus servidores da Web horizontalmente sem esforço. É muito difícil dimensionar horizontalmente um servidor de banco de dados.
3. Atuação. 2 caixas = 2 vezes a CPU, 2 vezes a RAM e 2 vezes os eixos para acesso ao disco.

Tudo o que foi dito, certamente posso ver casos razoáveis ​​em que nenhum desses pontos realmente importa.

Realmente não importa (você pode executar o site com muita facilidade / web / banco de dados na mesma máquina), é apenas a etapa mais fácil no dimensionamento.

É exatamente o que o StackOverflow fez - começando com uma única máquina executando o IIS / SQL Server e, quando começou a ficar muito carregado, um segundo servidor foi comprado e o servidor SQL foi movido para ele.

Se o desempenho não for um problema, não perca dinheiro comprando / mantendo dois servidores.

Por outro lado, referindo-se a um blog diferente de Scott (Watermasyck, da Telligent) - eles descobriram que a maioria dos usuários poderia acelerar os sites (usando o Community Server da Telligent), colocando o banco de dados na mesma máquina que o site. No entanto, no caso de seus clientes, geralmente o servidor db & Web é o único aplicativo nessa máquina, e o site não está sobrecarregando tanto a máquina. Então, a eficiência de não precisar enviar dados pela rede mais do que compensava o aumento da tensão.

Eu pensaria que o grande fator seria o desempenho. O código do servidor / aplicativo da Web e o SQL Server armazenariam em cache os dados solicitados na memória e você está diminuindo o desempenho do cache executando-os no mesmo espaço de memória.

Tom está correto nisso. Algumas outras razões são que não é rentável e que existem riscos adicionais à segurança.

Servidores da Web têm requisitos de hardware diferentes dos servidores de banco de dados. Os servidores de banco de dados se saem melhor com muita memória e uma matriz de disco muito rápida, enquanto os servidores Web exigem apenas memória suficiente para armazenar em cache arquivos e solicitações freqüentes de banco de dados (dependendo da configuração). Em relação à relação custo-benefício, os dois servidores não serão necessariamente mais baratos, no entanto, a relação desempenho / custo deve ser maior, pois você não precisa de aplicativos diferentes competindo por recursos. Por esse motivo, você provavelmente precisará gastar muito mais em um servidor que atenda a ambos e ofereça desempenho equivalente a dois servidores especializados.

A preocupação com a segurança é que, se a máquina única for comprometida, o servidor da Web e o banco de dados estarão vulneráveis. Com dois servidores, você tem espaço para respirar, pois o segundo servidor ainda estará seguro (por um tempo, pelo menos).

Além disso, existem alguns benefícios de escalabilidade, pois talvez você precise manter apenas alguns servidores de banco de dados usados ​​por vários aplicativos da web. Dessa forma, você tem menos trabalho para aplicar atualizações ou patches e ajustar o desempenho. Eu acredito que existem ferramentas de gerenciamento de servidor para facilitar essas tarefas (no caso de uma única máquina).

A segurança é uma grande preocupação. Idealmente, o servidor de banco de dados deve estar atrás de um firewall, com apenas as portas necessárias para executar o acesso aos dados abertos. Seu aplicativo da web deve estar se conectando ao servidor de banco de dados com uma conta SQL que tenha direitos suficientes para o aplicativo funcionar e não mais. Por exemplo, você deve remover os direitos que permitem a queda de objetos e, certamente, não deve se conectar usando contas como 'sa'.

No caso de você perder o servidor da Web por um seqüestro (ou seja, uma escalação completa de privilégios aos direitos de administrador), o pior cenário é que o banco de dados do aplicativo pode estar comprometido, mas não o servidor de banco de dados inteiro (como seria o caso se o servidor de banco de dados e servidor web eram a mesma máquina). Se você criptografou as seqüências de conexão do banco de dados e o hacker não é experiente o suficiente para descriptografá-las, tudo o que você perdeu é o servidor da web.

Um fator que ainda não foi mencionado é o balanceamento de carga. Se você começar a pensar no servidor da web e no banco de dados como máquinas separadas, otimizará para menos viagens de ida e volta à rede e também fica mais fácil adicionar um segundo servidor da web ou um segundo mecanismo de banco de dados conforme as necessidades aumentam.

Posso dizer por experiência própria que muitas vezes é uma boa idéia colocar o servidor da Web e o banco de dados em máquinas diferentes. Se você tiver um aplicativo que consome muitos recursos, ele pode facilmente causar o pico dos ciclos da CPU na máquina, essencialmente interrompendo a máquina. No entanto, se o seu aplicativo tiver uso limitado do banco de dados, provavelmente não será grande coisa para eles compartilharem um servidor.

Uau, ninguém traz à tona o fato de que, se você comprar um servidor SQL a 5 mil dólares, poderá usá-lo para mais do que seu aplicativo da web. Se você estiver usando express, talvez você não se importe. Vejo servidores SQL executando bancos de dados para 20 a 30 aplicativos, portanto, colocá-lo no servidor da web não seria inteligente.

Em segundo lugar, depende de quem é o servidor. Eu trabalho para empresas financeiras e para o governo. Portanto, usamos uma abordagem louca na abordagem de usar apenas sprocs e limitar portas de servidor da web para SQL. Portanto, se o aplicativo da Web for invadido. A única coisa que o hacker pode fazer é chamar sprocs, pois a conta do usuário no servidor da web está bloqueada para ver / chamar sprocs no banco de dados. Então agora o hacker precisa descobrir como entrar no banco de dados. Se estiver no servidor da web, é fácil chegar a ele.

Eu concordo com Daniel Earwicker - a questão da segurança é praticamente imperfeita.

Se você tiver uma configuração de caixa única com um servidor da Web e apenas o banco de dados para esse servidor, se esse servidor estiver comprometido, você perderá o servidor da Web e apenas o banco de dados para esse aplicativo específico.

É exatamente o mesmo que acontece se você perder o servidor da web em uma configuração de 2 servidores. Você perde o servidor web e apenas o banco de dados para esse aplicativo específico.

O argumento de que 'o restante da integridade do servidor de banco de dados é mantido' onde você tem uma configuração de 2 servidores é irrelevante, porque no primeiro cenário, todos os outros servidores de banco de dados relacionados a todos os outros aplicativos (se houver algum) permanecem inalterados. - sendo, como estão, hospedados em outro lugar.

Da mesma forma, para a pergunta feita por Kev 'e quanto a todos os outros bancos de dados residentes no servidor de banco de dados? Tudo o que você perdeu é um banco de dados.

• se você estivesse hospedando um aplicativo e um banco de dados em um servidor, hospedaria apenas bancos de dados nesse servidor relacionados a esse aplicativo. Portanto, você não perderia nenhum banco de dados adicional em uma configuração de servidor único quando comparado a uma configuração de vários servidores.

Por outro lado, em uma configuração de 2 servidores, em que o invasor tinha acesso ao servidor Web e, por proxy, direitos limitados (no melhor dos casos) ao servidor de banco de dados, eles podiam colocar em risco os bancos de dados de todos os outros aplicativos, carregando faça consultas lentas e com muita memória ou maximize o espaço de armazenamento disponível no servidor de banco de dados. Ao separar os aplicativos em suas próprias preocupações, como a virtualização, você também os isola por motivos de segurança de maneira positiva.

Depende da aplicação e da finalidade. Quando alta disponibilidade e desempenho não são críticos, não é ruim não separar o banco de dados e o servidor da web. Considerando especialmente os ganhos de desempenho - se o aplicativo fizer uma grande quantidade de consultas ao banco de dados, uma quantidade considerável de carga de rede pode ser removida mantendo tudo no mesmo sistema, mantendo os tempos de resposta baixos.

Eu acho que é porque as duas máquinas geralmente precisam ser otimizadas de maneiras diferentes. Fora isso, não faço ideia, executamos todos os nossos aplicativos com o banco de dados do servidor na mesma máquina - desde que não enfrentemos o público -, mas não tivemos problemas.

Não posso imaginar que muitas pessoas se preocupem com o comprometimento de uma máquina, pois o aplicativo da Web normalmente terá acesso quase irrestrito a pelo menos os dados, se não o esquema dentro do banco de dados.

Interessado no que os outros possam dizer.

Ouvi o podcast e foi divertido, mas o argumento de segurança não fazia sentido para mim. Se você comprometer o servidor A e esse servidor puder acessar dados no servidor B, você terá acesso instantâneo aos dados no servidor B.

As licenças do banco de dados não são exigentes e geralmente são cobradas por CPU; portanto, ao separar os servidores da web, você pode reduzir o custo das licenças do banco de dados.

Por exemplo, se você tiver um servidor executando Web e banco de dados que contém 8 CPUs, terá que pagar por uma licença de 8 cpu. No entanto, se você tiver dois servidores, cada um com 4 CPUs e executar o banco de dados em um servidor, precisará pagar apenas pelas licenças de 4 cpu

Uma preocupação adicional é que os bancos de dados gostam de ocupar toda a memória disponível e mantê-la reservada quando quiser usá-la. Você pode forçá-lo a limitar a memória, mas isso pode diminuir consideravelmente o acesso aos dados.

Argumentar que existe um ganho real de desempenho ao executar um servidor de banco de dados em um servidor web é um argumento defeituoso.

Como os servidores de banco de dados usam seqüências de caracteres de consulta e retornam conjuntos de resultados, os dados que realmente fluem do servidor de dados para o servidor da Web são relativamente pequenos, mas a potência necessária para processar a consulta e gerar o conjunto de resultados é relativamente grande. Portanto, otimizar o desempenho em torno do tempo de transferência de dados é otimizar a coisa errada.

Em relação à segurança, há vantagens em ter o servidor de dados em uma caixa diferente do servidor web. Ter essa configuração não é tudo e acaba com toda a segurança, mas é um passo na direção certa.

Em relação à escalabilidade, é fácil e relativamente barato adicionar servidores da Web e colocá-los em cluster para lidar com o aumento do tráfego. Não é tão fácil e barato adicionar servidores de dados e agrupá-los. Além disso, servidores da Web e servidores de dados têm necessidades de hardware diferentes, portanto, várias caixas ajudam na escalabilidade.

Se você estiver começando pequeno e tiver apenas uma caixa, um bom caminho seria usar máquinas virtuais. A execução do servidor da Web e do servidor de dados em diferentes VMs em um host oferece todos os ganhos de caixas separadas ao custo de um preço grande.

O sistema operacional é outra consideração. Embora seu banco de dados possa exigir maiores espaços de memória e, portanto, o UNIX, seu servidor da Web - ou mais especificamente o servidor de aplicativos, já que você menciona apenas duas camadas - pode ser baseado em .Net e, portanto, exigir o Windows.

Está bem! Aqui está a questão: é mais seguro ter seu servidor de banco de dados instalado em outra máquina e seu aplicativo no servidor da Web. Em seguida, conecte seu aplicativo ao banco de dados com um link da Web. Obrigado.