Minha equipe de desenvolvedores sugeriu uma estrutura de servidor para um próximo projeto que estamos desenvolvendo. Nossa estrutura é "lógica", o que significa que os vários componentes lógicos do aplicativo (é distribuído) dependem de diferentes servidores. Alguns componentes são mais críticos do que outros e estarão sujeitos a mais carga.
Nossa proposta era ter 1 servidor por componente, mas os caras de hardware sugeriram substituir as várias máquinas por uma única maior, com servidores virtuais. Eles vão usar servidores blade.
Agora, eu não sou um especialista, mas a minha pergunta para os caras era: então se precisarmos, por exemplo, de 3 máquinas 2GHz CPU / 2GB RAM e você me der 1 máquina com 3 CPUs de 2GHz e 6 GB de RAM é o mesmo? Eles me disseram que é.
Isso é preciso? Quais são as vantagens ou desvantagens de ambas as soluções? Quais são as práticas recomendadas geralmente aceitas? Você poderia apontar alguma referência de URL para lidar com o problema?
EDITAR:
Mais algumas informações. O aplicativo (internet / intranet) já está em camadas. Temos alguns servidores no DMZ que exporão páginas à internet e os bancos de dados estão em suas próprias máquinas. O que queremos dividir (e eles querem participar) são alguns servidores Web que expõem principalmente os serviços web. Um é um DAL que se comunica com a camada de banco de dados, um é nosso aplicativo Single Sign On / Perfil de Usuário que é chamado uma vez por página e um é um clone do que é visto na Internet para ser usado em nossa rede.
Dado que seus requisitos soam um pouco "lanosos" e na verdade são bem baixos, eu seria strongmente tentado a virtualizar isso. Eu começaria com apenas dois blades e algum armazenamento compartilhado, então você pode criar, modificar e excluir suas VMs conforme necessário, você perderá muito desempenho e ganhará um alto grau de flexibilidade, além de poder dimensionar linearmente e sem impacto do usuário.
Acho que a maneira sadia seria identificar onde os gargalos cruciais são ou podem ocorrer. As VMs são ótimas para isolamento e, dependendo do tipo de hipervisor usado, podem ter pouco impacto no desempenho real. A rede virtual provavelmente funcionaria melhor do que a rede física também.
No entanto, eu recomendaria ter algumas máquinas físicas devido à redundância. Se você tiver um servidor físico com um milhão de VMs, quando esse servidor físico morrer (e ocorrerá), levará um milhão de VMs com ele.
Nunca coloque todos os ovos na mesma cesta!
Eles estão falando sobre fornecer a você um único chassi blade ? Porque, se assim for, ainda há muitos servidores individuais, apenas contidos em uma unidade de alojamento. Se eles estão literalmente falando sobre um grande servidor para administrar o lote, eles (provavelmente) não fariam falar de lâminas.
De qualquer forma, ignorando a questão das lâminas, eis a minha perspectiva: se o seu aplicativo escalar de forma feliz em vários servidores menores, faça isso. Servidores menores são mais baratos de comprar, você pode facilmente escalar para os lados adicionando mais servidores, e os aplicativos individuais tenderão a funcionar de forma mais confiável se tiverem um servidor praticamente para si mesmos.
No entanto, existem extremos. É muito comum dividir a arquitetura em pelo menos duas camadas (front-end e banco de dados) ou 3 camadas (front-end, aplicativo, banco de dados), mas a menos que você esteja criando um monstro absoluto de um sistema, precisa ir além disso.
Você pode fornecer mais informações sobre o sistema que está desenvolvendo? Que tipo de plataforma você está usando, sistema operacional, idioma, base de usuários, ciclo de vida de desenvolvimento?
EDITAR: Com base na sua edição, surge uma outra questão - Qual é o fator limitante da sua configuração atual? Você está ficando sem RAM, ou os discos não estão lendo rápido o suficiente, ou você está tendo problemas para extrair os registros do banco de dados com rapidez suficiente? maximizou a CPU? O fator limitante sobre o que você tem agora, deve ser o principal guia para onde você precisa ir com isso.
Uma configuração de servidor único pode ser benéfica ou muito ruim. Você pode manter um único servidor mais fácil do que você pode manter 3, e quando ele desce, tudo fica com ele.
Com uma configuração de vários servidores, você pode compartimentalizar, mas isso pode ser inútil se um dos seus três servidores ficar inativo e os outros dois dependerem dele para funcionar, já que você estará no mesmo local.
Eles podem estar errados, dependendo de:
A arquitetura não é tão simples quanto matemática. Mas não podemos aconselhá-lo mais sem mais detalhes
Os requisitos de capacidade são melhor determinados através de testes de carga e dados empíricos. Não confie em previsões ou adivinhações inspiradas.
A disponibilidade é outra questão. Claro, vários servidores são melhores que um. Pode haver outros fatores que influenciam a arquitetura. Principalmente custo, especialmente se isso não for código aberto e houver taxas de licença por servidor ou se você estiver usando componentes de terceiros que exigem pagamentos de royalties.
3 2GHz CPU / 2GB RAM machines and you give me 1 machine with 3 2GHz CPUs and 6 GB of RAM it is the same? They told me it is.
Não Não é o mesmo. Dependendo da plataforma de virtualização, haverá sobrecarga (de 5-30%) da camada de hipervisor.
What are the advantages or disadvantages of both the solutions?
É difícil sem mais detalhes, mas aqui estão algumas generalidades
Vantagens:
Desvantagens:
No seu caso particular, um sistema pode ser OK se o seu serviço estiver morto, caso algum desses sistemas esteja inoperante. Você não adicionou nenhum risco nesse caso. Também parece que esses sistemas não precisarão de 6 Ghz de potência de processamento; nesse caso, a consolidação certamente economizará dinheiro, já que você não compraria 6ghz apenas para essas 3 máquinas. A outra coisa que você precisa observar é (e certamente não menos importante em consideração) os requisitos de E / S e a potencial contenção de E / S.
Como alternativa, se esses serviços da Web puderem coexistir na mesma máquina, considere também fazer duas VMs com o mesmo serviços e usar clustering ou simplesmente manter um em standby deve ser um problema.
Para URLs, dê uma olhada em
Guia de virtualização do Windows Server
O Guia de Atalho para Implementar a Virtualização no Pequeno Ambiente
Servidores blade não são bons servidores virtuais. Você está severamente limitado em largura de banda e memória, as duas maiores demandas em um ambiente virtual. Nós tendemos a correr em torno de 4 vituals por núcleo. Mesmo com o melhor chassi blade você está limitado a 40Gb de conectividade de rede por blade. Se você estiver executando 32 Webs virtuais de alto desempenho, mesmo com assinaturas em excesso, ainda estará maximizando suas conexões por virtual. Se você obtiver 40Gb de conectividade com um blade, precisará sacrificar uma rede de armazenamento e usar uma malha convergente, o que tira a largura de banda da Web necessária. Um dell 910 ou um HP 585 são uma boa plataforma de virtualização. 1 servidor com 24 núcleos, 140GB de rede rodando 96 virtuais.
Em seguida, você deseja dimensionar corretamente os virtuais. Nunca dê um virtual mais de 1 núcleo, sempre dimensionar. Se você adicionar núcleos adicionais, causas de pesquisa de CPU e carga e bloqueios artificiais. Para um bom apache virtual rodamos 1 núcleo, 1.8Gb mem e ~ 4gb de rede. Sob carga, o virtual fica em torno de 2ghz, e o servidor reporta uma carga de 1.28.Nossos virtuais de banco de dados executam 1 núcleo, 6gb de mem e ~ 4gb de rede.
Sempre separe os aplicativos; você não pode ajustar um virtual se continuar adicionando variáveis. Um único virtual deve ter uma única função. Deve executar uma coisa muito bem. DMZ. O DMZ deve estar em plataformas virtuais físicas separadas. Para requisitos regulamentares e proteção.