Devo hospedar meus dados na mesma caixa em que atendo minhas páginas da web?

Question

Eu estava ouvindo Hanselminutes um dia e essa pergunta surgiu. Em que circunstâncias deve separar os dados do código? Por exemplo, em um dos sistemas em que trabalhei, o DB está na mesma caixa que serve o conteúdo da web. Em outro cenário, os separamos. Qual é melhor porque você se sente assim?

Pessoalmente, acho que a separação é boa se você puder pagar.

Os dados estão melhor protegidos contra intrusos. A separação permite um melhor controle de failover. e Separação permite gerenciar e balancear o tráfego de maneira melhor.

Quando isso se torna um problema, é com os tempos de acesso aos dados. A latência na caixa quando ambos estão juntos é significativamente reduzida em relação à rede.

Quais são seus pensamentos?

    

Answer 1

Existem vários motivos pelos quais você consideraria a separação do banco de dados e do servidor da Web, e alguns refletirão o que já foi mencionado.

Primeiro, há o possível problema de desempenho. Geralmente, um servidor de banco de dados adora memória. Quanto mais memória ele puder alocar para armazenar dados em cache, menor será o acesso necessário para ler do disco. Então, há um benefício em ter memória. Como resultado, você pode ter um problema de contenção de memória entre o servidor da Web e o servidor de banco de dados. Com isso dito, há muitos casos em que os servidores de banco de dados estão sendo executados na mesma caixa do servidor da Web, como o MySQL ou o SQL Server Express ou até mesmo o SQL Server completo com o SQL Server 2005 Reporting Services.

Em segundo lugar, há o caso em que seu aplicativo pode usar alguns, mas não todos os dados. Isso é especialmente verdadeiro se os sistemas internos também tocarem no banco de dados. Este não é um cenário provável em um ambiente de hospedagem na web, que eu estou supondo que você esteja olhando com base em suas tags. Mas, nesse caso, você pode limitar o acesso do servidor da Web ao banco de dados apenas ao que é necessário. Sim, se o servidor da Web estiver comprometido, eles poderão obter esse acesso, mas se for um conjunto limitado de permissões, eles não poderão obter tudo. Hospede-o no mesmo servidor da web e essa é uma história totalmente diferente.

Em terceiro lugar, é possível obter algumas dicas sobre se o seu servidor da Web está comprometido, observando o tráfego de rede entre o servidor da web e o servidor de banco de dados usando o IDS / IPS. Por exemplo, se estamos falando de SQL Server e xp_cmdshell é enviado para o servidor de banco de dados, ou sp_configure, isso deve dizer ao IDS / IPS que algo está ativo. E isso fornece um aviso imediato de que o servidor da Web está comprometido.

A quarta é a separação de deveres. Se você tiver pessoas responsáveis pela implantação do aplicativo da Web, elas provavelmente precisarão de direitos escalados para o servidor da Web para fazer isso. Que tipo de direitos depende do que você está fazendo, do sistema operacional, do servidor da Web, etc., mas você entende a ideia. Se essas pessoas não tiverem acesso a tudo o que está no servidor de banco de dados e as atualizações ao servidor de banco de dados forem tratadas por um conjunto diferente de pessoas (como DBAs), elas poderão proteger melhor a empresa usando servidores diferentes.

    

Answer 2

Idéia muito ruim para o mínimo. Eu tive uma configuração antes de onde eu tinha Apache + MySQL no mesmo servidor e iria regularmente mais de 10 média de carga e as páginas demorariam uma eternidade para carregar. Nós dividimos os dois serviços e colocamos o MySQL em um servidor menor. Os dois servidores nunca ultrapassariam 0,35 da média de carga.

Faça as contas ... Há muita perda em colocar o servidor Web + o servidor DB no mesmo servidor.

Evan também tem um bom argumento. Mesclar coisas em uma máquina tende a levar a muitos atalhos que dificultam muito o dimensionamento. Um serviço = um sistema operacional é uma boa regra de ouro (teria dito um serviço = uma máquina, mas agora há virtualização).

    

Answer 3

O primeiro pensamento que me veio à mente foi não criar uma solução.

Tudo bem colocar tudo em uma caixa. O todo-poderoso Stack Overflow começou assim também.

Quando você tem demanda suficiente (e recursos) para justificar várias caixas, faça isso. Construir a configuração perfeita não acontecerá da primeira vez.

Mantenha backups excelentes, independentemente de como e como você os configurou para recuperação e restauração rápidas. Replicar seu banco de dados fora do site para que você possa reconstruí-lo e restaurá-lo em qualquer lugar (na nuvem, em outros hosts, etc.)

Boa sorte!

    

Answer 4

Do ponto de vista da segurança, deve estar em caixas separadas. No entanto, dependendo do orçamento, deve ser uma decisão de negócios aceitar ou não o risco.

Por que isso? Primeiro, as práticas recomendadas recomendam:

• Defesa em profundidade.
• Menos privilégio e separação de dados

Se o seu banco de dados estiver em uma máquina separada, será necessário um passo adicional para atacá-lo. Se você seguir a defesa em profundidade, o servidor web não será capaz de acessar qualquer outra coisa na caixa db além do db (portanto, nenhum shell, nenhum script em execução, etc). É por isso que um firewall é bom para o controle interno também.

Se você está realmente fazendo bem a segurança, seu usuário do web-2-db terá privilégios mínimos no db, podendo apenas acessar / modificar o que ele realmente precisa (então, nenhuma tabela drop, etc). É engraçado a frequência com que vemos GRANT * em um banco de dados, para um usuário que só precisa selecionar e atualizar de algumas tabelas.

Assim, só porque muitas pessoas executam db + servidor web + servidor de email + DNS em uma única caixa, não significa que seja a melhor decisão de segurança, apenas um risco aceito com base no $$.

    

Answer 5

Uma coisa importante a ter em mente é que, quando você vai de uma máquina para outra, suas chances de inatividade dobram - isto é, se o seu site depende do funcionamento do banco de dados. Se o tempo de atividade é importante para você, você pode estar olhando para 4 (ou mais) servidores - e então você é de ouro.

Eu não acho que você precise se preocupar com a velocidade do DB se comunicando com o servidor web. A potência da CPU que você adquire ao adicionar uma máquina acelera as próprias consultas de banco de dados, e a transmissão entre servidores, mesmo a 100Mb, deve ser insignificante comparada à velocidade com que você pode servidor de páginas da Web na Internet.

    

Answer 6

Eu não acho que a segurança é significativamente melhor com uma caixa separada. Se um invasor comprometer a caixa que atende à Web, isso provavelmente levará a um comprometimento do banco de dados, independentemente. Os argumentos de failover e balanceamento de carga / escalabilidade são muito melhores.

Mas se você tiver apenas uma caixa da web, eu definitivamente prefiro manter os dados na mesma caixa.

    

Answer 7

Se eles tiverem acesso à sua máquina web, eles podem extrair os detalhes do banco de dados de seus arquivos de configuração, carregar um shell php e descarregar os dados de lá. A única vantagem de segurança é se você tiver mais de um banco de dados na mesma máquina.

No entanto, ele permite que você distribua a carga e, se você precisar fazer isso para obter desempenho, é bom, desde que você tenha uma conexão rápida, conforme indicado.

    

Answer 8

Se você está preocupado com a redundância, então seria bom ter todos os dados em uma caixa e backup na outra.

Concordo que a separação é melhor se puder ser oferecida.

    

Answer 9

Se a caixa puder manipular a carga CPU / RAM -, tê-los na mesma caixa pode ser melhor por motivos de desempenho, pois não haveria latência de rede entre o servidor da Web e o servidor de banco de dados.

    

Answer 10

Eu não tenho uma opinião strong de um jeito contra o outro. No entanto, se você planeja "dimensionar", considere tornar o (s) servidor (es) da Web o mais sem estado possível para permitir o dimensionamento sem reformular o design.

    

Answer 11

Se você tiver um banco de dados pequeno, relativamente estático, que é acessado com freqüência, então armazená-lo no mesmo servidor que o servidor da Web pode ser benéfico (já que você aproveitará o armazenamento em cache de dados na memória). No entanto, para qualquer outro cenário, é melhor dividir as duas funções se você puder pagar os $ 1-2K extras para outro servidor.

    

Answer 12

Acho que separar o banco de dados e o servidor da web em máquinas diferentes pode adicionar outra camada para o intruso, mas muito fina.

Se você quiser "interceptar" invasores dessa maneira, é possível usar um proxy reverso ou um cache da web em uma máquina separada. O intruso irá para esta máquina e não encontrará dados, assim como detalhes sobre como chegar à máquina do banco de dados. Somente o servidor da web será definido no proxy reverso e poderá ser bloqueado para além da porta em que ele serve as páginas da web.

Security: the proxy server may provide an additional layer of defense by separating or masquerading the type of server that is behind the reverse proxy. This configuration may protect the servers further up the chain - mainly through obfuscation.

link