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


126

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?

Respostas:


158
  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.


27
Mas com 2 máquinas você tem o dobro da probabilidade de falha de hardware;)
TWith2Sugars

4
@ TWith2Sugars - em oposição a quê?
Kev

3
Ref. ponto 1. Se a camada da Web é de propriedade, o que mais você deseja ou precisa além da interface da API do aplicativo / banco de dados? Certamente já acabou o jogo nesse ponto? As coisas ficam muito interessantes em termos de serviços necessários para suportar a infraestrutura DMZ, por exemplo, qualquer serviço AD ou Microsoft em jogo?
28909 Noelie Dunne

4
@ Noelie - Seu nível da web não teria acesso, por exemplo, faça backup do banco de dados em um arquivo e envie-o por ftp.hackers.com usando xp_cmdshell. Ou largue o banco de dados. Ou modifique os valores de configuração. etc.
Mark Brackett

6
@kirgy - como as duas máquinas estão em paralelo e são um ponto único de falha, a confiabilidade geral é menor; tecnicamente não é o dobro (na verdade é 1 - (r1 * r2)), mas é suficientemente próximo para confiabilidade grande e pequenos nós ... No caso de 0,01%, seria 0,0199%. Mas para 100 nós, seria 36,6%, em vez dos 100% implícitos na declaração de duplicação.
21816 Mark Brackett

45

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.


3
Eu concordo, isso pode ser feito enquanto a carga é baixa ... conforme a carga aumenta, é fácil separá-los em 2 ou mais máquinas.
EJ Brennan

4
Eu entrei e ia comentar a mesma coisa. Mudar seu servidor de banco de dados é tão fácil quanto alterar a cadeia de conexão (na maioria dos casos).
CitizenBane 5/10/09

Eu gosto disso. Alguém está pensando no contexto antes de sugerir uma solução!
Demisx

22

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.


4
... até que o uso simultâneo aumente e o servidor db precise de mais memória para fazer uso efetivo de buffers e caches. Uma vez que os servidores web / app e db precisam de mais memória do que podem compartilhar em uma única caixa, a E / S de paginação e disco aumenta e os tanques de desempenho.
21909 kermatt

@ MattK - mas e se você tiver grandes quantidades de memória? Temos um aplicativo em que cada cliente tem seu próprio banco de dados, para que o servidor de banco de dados e a web possam escalar horizontalmente com muita facilidade. Dado que temos mais memória do que disco em uso (64 GB x ~ 40 GB), não seria melhor para o desempenho manter tudo na mesma máquina?
Bip

1
Se o seu conjunto de trabalho couber na memória, talvez você não veja nenhum dos problemas de desempenho mencionados. Na maioria dos casos, os servidores têm mais disco que RAM, mas parece que no seu caso você tem bancos de dados que cabem inteiramente na RAM - desde que os aplicativos no servidor compartilhado não consumam muito dele.
kermatt

15

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.


12
E se você tiver um banco de dados pequeno (ish), mas com muita memória? O custo de passar pela rede para cada chamada ao banco de dados, principalmente se houver muitos, superaria os benefícios?
Beep beep

1
@ Tom Ritter Embora o desempenho seja uma preocupação (de acordo com esta resposta e o ponto 3 da resposta de Mark Brackett), eu sei que algumas pessoas (incluindo eu) provavelmente economizariam dinheiro, NÃO colocando um servidor de banco de dados separado em MAIS CPU / RAM / etc. no servidor único que o substituiu. Portanto, isso deve ser levado em consideração. Quanto à memória separada, o IIS e o SQL podem ser configurados para dar conta da concorrência por recursos. Pessoalmente, o "chutador" para mim era o ponto 1 de Mark ... a segurança. Gosto da ideia do acesso limitado que um servidor da Web comprometido teria a um servidor de banco de dados separado .
Dylan - INNO Software

@ Tom, você sempre pode dividir o espaço da memória em duas unidades separadas. Metade para servidor e metade para banco de dados.
Pacerier 17/10

15

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).


2
Se você estiver executando qualquer coisa, mas SPs, em seguida, o seu servidor web provavelmente tem pleno acesso aos dados em seu banco de dados de qualquer maneira
George Mauer

Por que não é rentável? Por favor especifique.
Robert Jeppesen

Robert I expandiu isso e acrescentou alguns comentários sobre escalabilidade e manutenção.
Dana the Sane

9

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.


Mas você faz backup do banco de dados, certo? Caso contrário, você correria o mesmo risco de perdê-lo devido a uma falha de hardware ou bug raramente excitado. Um ataque que mata o servidor da web causa tempo de inatividade por si só. Privilégios suficientes para adicionar registros às tabelas são suficientes para tornar um site inútil.
21119 Daniel Earwicker

É claro que você faz backup do banco de dados, isso está implícito. Onde, no meu post, sugeri o contrário.
Kev

1
Sim, mas a conclusão é que um ataque destinado a derrubar o site pode fazê-lo destruindo a configuração do servidor web ou o banco de dados, e a solução é a mesma para os dois: restaurar a partir do backup. Especialmente proteger o banco de dados é (a) desnecessário e (b) impossível de qualquer maneira.
21119 Daniel Earwicker

@Earwicker - e todos os outros bancos de dados residentes no servidor DB? Tudo o que você perdeu é um banco de dados.
Kev

8
Além de Daniel, você está perdendo um ponto ENORME. Não se trata de um backup de banco de dados, mas de dados comprometidos. Seus clientes concordariam que "um hacker roubou todos os seus dados de clientes e vendas, mas não se preocupe, eu tenho um backup". :)
Dylan - INNO Software

9

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.


6

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.


6

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.


5

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.


4

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.


2

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.


1
George, acho que você deveria se referir à resposta de Mark Brackett. A segurança do servidor da Web no banco de dados NÃO seria a mesma que seria se o servidor estivesse separado. Especificamente, o "disco local" não estaria acessível. Além disso, se apenas um único site (de muitos) fosse invadido, eles provavelmente teriam apenas comprometido o acesso ao banco de dados desse site (a menos que você use um usuário muito poderoso para essa cadeia de conexão). Existem inúmeros outros cenários, só não acho que um comentário aqui seja o lugar para eles.
Dylan - INNO Software

2

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.


Não é verdade. Você tem acesso a quaisquer dados ou privilégios que a Caixa A tenha para a Caixa B. Em uma configuração segura, isso significa que você tem o nível mais alto de acesso ao banco de dados que o aplicativo da Caixa A possui. Você não, no entanto, tem sa privs no DB, ou de raiz no sistema operacional de caixa B.
Mark Brackett

2
"Você tem acesso a quaisquer dados ou privilégios que a Caixa A tenha da Caixa B" - foi o que eu quis dizer com "você tem acesso instantâneo aos dados no servidor B". Se o RDBMS estivesse na caixa A e não houvesse caixa B, que diferença faria? NB. estamos assumindo que você já invadiu a caixa A, de qualquer maneira.
21119 Daniel Earwicker

Em uma configuração de duas caixas, se você estiver aplicando o princípio do menor privilégio, se a caixa A (web) estiver comprometida, o pior que deveria ter acontecido é que você perdeu o banco de dados na caixa B e não mais.
Kev

1
E em uma configuração de uma caixa, se essa caixa estiver comprometida, você perdeu essa caixa, que inclui o banco de dados nela. Qual é a diferença?
21119 Daniel Earwicker

2
A diferença é que, em uma configuração de duas caixas, se o servidor da Web estiver comprometido, tudo o que você perdeu será o servidor da Web e, na pior das hipóteses, o DB. O restante da integridade do servidor de banco de dados é mantido.
Kev

2

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


Por favor, explique como isso representa uma economia.
John Saunders

1
John - ele está dizendo que, para obter desempenho equivalente a duas máquinas, você precisará dobrar o número de núcleos, o que dobraria os custos de licenciamento do SQL Server. Por que pagar um adicional de US $ 10 a 20 mil pelo SQL Server se tudo o que você obtém é o mesmo desempenho que a utilização de 2 máquinas.
Bip

verdadeiro somente se a utilização de desempenho / recursos (por exemplo, CPU) for dominada pelos servidores de aplicativos e não pelo servidor db. se o db precisar de 8 cpus, não funcionará.
Andreas Dietrich

1

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.


-1

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.


1
A pergunta original feita sobre servidores de aplicativos, não necessariamente a Internet pública voltada para servidores web.
João Bragança

-2

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.


Não votei negativamente, mas "Embora seu banco de dados possa exigir maiores espaços de memória e, portanto, UNIX" - Se você estiver executando janelas de 64 bits e SQL de 64 bits, há muito espaço para brincar.
Kev

Desculpe, a memória foi um exemplo de motivo para a necessidade de implantação em sistemas operacionais divididos. Outras razões incluem: desempenho, segurança, padrões corporativos / licenciamento, suporte do fornecedor, etc.
Chris Noe

-6

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.


3
por que é mais seguro?
Bryan Chen
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.