O banco de dados deve estar na mesma caixa que o servidor web ou separado

Question

Estou usando o SQL Server 2005 e o IIS6. Eu tenho cada um em caixas separadas (Quad cpu, 4G). O cliente quer consolidar em uma caixa. Este é um aplicativo corporativo com 400 usuários. O desempenho está bom agora, mas questiono qualquer economia para consolidar com mudanças de desempenho, gerenciamento de serviços. Então, para 1) recursos futuros / crescimento, 2) desempenho, 3) Modularidade, outro ?, mova para 1 caixa ou mantenha 2.

    

Answer 1

Eu sou praticamente 100% baseado em Linux, mas acho que alguns princípios comuns se aplicam.

Se você pretende dimensionar, ter os servidores separados, mesmo que apenas o uso de software de virtualização forneça a capacidade de adicionar nós facilmente, conforme necessário, e balancear a carga entre eles - também oferece mais segurança, pois você só abre as portas necessidade.

Ter um servidor de banco de dados na caixa que encontrei é bom para serviços suplementares como servidores de e-mail ou alguma outra ferramenta de configuração que usa um banco de dados back-end ... essas pegadas são relativamente pequenas e a escalabilidade é menos preocupante.

    

Answer 2

Não há informações suficientes para determinar qual direção seguir, dependendo do seu ambiente. Para fazer a chamada certa, você vai querer reunir métricas nos dois servidores em seus estados atuais e analisar o que você tem. Você precisa de dados reais para provar o ponto, de qualquer forma. "Aplicativo corporativo" não diz muito sobre métricas que não sejam "pode ser grande". Você pode ser capaz de combinar, mas se você tiver que comprar um novo hardware com mais potência, pode estar atirando no próprio pé.

Algumas reflexões (principalmente da perspectiva do banco de dados):

• Uma teoria de segurança é que, se um invasor obtiver acesso ao seu servidor da Web, ele terá acesso ao servidor de banco de dados. Isso pode ou não ser necessariamente verdadeiro, dependendo de como o invasor obtiver acesso, como você configurou a segurança em seu servidor da Web e como as seqüências de conexão são armazenadas. Certamente vale a pena prestar atenção, no entanto.

• O SQL, por padrão, consumirá o máximo de memória possível no servidor. Ao hospedar a Web e o SQL Server na mesma caixa, encontrar o lugar feliz em que ambos funcionem de maneira aceitável exigirá um pouco de planejamento e ajuste. Isso mudará constantemente à medida que seu banco de dados cresce e o uso de seu aplicativo sobe. Não que isso não mude constantemente, só que às vezes é mais difícil encontrar o equilíbrio entre dois serviços

• Você não terá a sobrecarga de conexões de rede do servidor da Web para o servidor SQL.

Answer 3

Quais são os supostos benefícios da consolidação?

• Manutenção? Dificilmente, será um pouco mais difícil na melhor das hipóteses.
• Custo? Talvez ... por enquanto.

Se você quer o melhor dos dois mundos, pode configurar duas VMs no único host. Como quando um deles cresce muito grande, você pode simplesmente movê-lo para um novo host (ou talvez para uma nova máquina dedicada).

Em geral, aconselho não executá-los na mesma caixa em um ambiente de produção; Além das implicações de segurança, a configuração e a manutenção não serão tão fáceis quanto as duas funções sempre estarão disputando recursos.

    

Answer 4

Algumas pessoas de segurança não gostam de ter um servidor da Web e um servidor de banco de dados na mesma máquina. O nosso deixa deslizar se instalarmos o IIS em uma partição separada.

    

Answer 5

Eu diria, experimente em uma cópia que não seja de produção do seu sistema e veja.

Qualquer aplicativo significativo que esteja sendo ativamente suportado deve ser testado quanto ao desempenho. Obtenha caixas de hardware de nível de produção (a mesma especificação que você implantaria na produção agora - não obsoleta) e teste-a com uma única caixa e duas caixas.

Meu palpite é que colocar o banco de dados na mesma máquina tem melhor desempenho, desde que o aplicativo de banco de dados + se ajuste ao RAM - e, caso contrário, será pior. Isso significa efetivamente que colocá-los na mesma máquina melhora o desempenho, mas reduz a escalabilidade. Esse desempenho versus trade-off de escalabilidade é típico.

Mas tente e veja. Certifique-se de usar hardware de nível de produção e alguns softwares para simular pelo menos o nível de uso de produção.

Há também implicações para a robustez (de usar uma única máquina). Mas você poderia ter outros como backups mornos (ish) sem afetar muito a produção (dependendo de qual tipo de replicação / clustering você usa).