Estamos usando um aplicativo com cerca de 300 usuários simultâneos. Agora tudo é virtualizado: 1 VM como balanceador de carga, 2 VMs como servidor web (neste host ESXi há +25 outras VMs adicionais) e 1 servidor (bare metal) como SQL Server. Tivemos alguns problemas com o desempenho e decidimos comprar hardware físico para aumentá-lo.
Não tenho certeza, como podemos obter melhor desempenho?:
compramos 1 hardware de servidor em rack e executamos ESXi com apenas todas as 3 VMs acima,
compramos hardware de servidor rack 1-1 para os servidores web e instalamos o servidor Windows apenas com o aplicativo. (e deixe o balanceador de carga como antes - VM)
- compramos 3 servidores rack para o balanceador de carga e para os 2 servidores web.
Os usuários estão conectados com interface web/aplicativo de desktop ao servidor.
Obrigado pela ajuda, Drawo
Responder1
Algumas informações para as quais você deve encontrar a resposta antes de decidir o caminho a seguir:
Uso de CPU para as VMs afetadas
- Do ponto de vista do sistema operacional convidado, o uso da CPU geralmente está acima de 80% e/ou mostra estagnações em vez de picos de uso? É provável que sua VM esteja com falta de CPU. Adicione mais vCPUs (mas pense em possíveis problemas de licenciamento).
- Algumas vCPUs em seus servidores estão significativamente menos carregadas do que outras? Você pode ter um problema de dimensionamento em seu aplicativo, onde simplesmente colocar mais vCPUs em uma única VM (ou em uma máquina física) não ajudará em nada.
- Os
CPU readytempos indicam que o host está supercomprometido? Uma regra prática que você às vezes vê é que você deseja menos de 5% do tempo médio de prontidão, mas minha experiência é que mesmo isso é demais para um sistema no qual você realmente trabalha. Observe que se você usar o vCenter, o tempo de prontidão indicado está em milissegundos agregados desde a última atualização do gráfico. Na visualização "tempo real", o gráfico é atualizado a cada 20 segundos (=20.000 ms), portanto, a porcentagem média por CPU para uma VM pode ser calculada usando a fórmula(indicated_ready_time * 100 / 20000) / number_of_vcpu.
Uso de RAM
(Deve sempre ser verificado no sistema operacional convidado)
- Geralmente acima de 80%? Adicione memória.
- Sinais de vazamentos de memória? Corrija o aplicativo ou esteja preparado para reiniciar/reiniciar com mais frequência.
- Sinais de troca pesada? Verifique se há problemas de configuração. Adicione memória.
- Você tem aplicativos/processos importantes que "inexplicavelmente" usam menos de 4 GB de memória? Eles podem precisar ser reconstruídos ou reconfigurados para utilizar o endereçamento de 64 bits.
Verifique também o desempenho do disco e da rede quanto a problemas de latência.
Dependendo de como seu aplicativo é dimensionado, pode ser uma ideia adicionar mais servidores Web em vez de adicionar capacidade de computação ou memória aos existentes.
Depois de ter uma ideia de onde estão seus gargalos e qual a melhor forma de utilizar seu hardware, você pode começar a elaborar um caso de negócios sobre o que comprar.
O principal argumento das máquinas virtuais é que elas são mais fáceis de gerenciar, de fazer backup e de migrar em caso de falha do sistema. Eles permitem uma melhor utilização do seu hardware, desde que na verdade não exijam todos os recursos que você pode fornecer a eles, e se você usar interfaces de rede paravirtualizadas, a comunicação entre máquinas no mesmo host será tão rápida quanto a CPU pode gerenciar, em vez de sendo limitado às velocidades da interface de rede física.
Um sistema executado diretamente em uma máquina física não terá, é claro, sobrecarga devido ao compartilhamento de recursos, mas isso só será um benefício se você puder usar a energia disponível.
Responder2
Sem investigação da causa dos seus problemas de desempenho e conhecimento do seu aplicativo, você não pode dizer qual será a solução mais fácil/melhor.
No caso de seu problema ser realmente falta de recursos de hardware, o monitoramento deve deixar bem claro onde você está atingindo os limites agora e o que comprar (núcleos de CPU ou velocidade de CPU, mais memória RAM, discos mais rápidos) e onde atribuir isso .
Na minha experiência, mais da metade dos problemas de desempenho foram resolvidos mais ou menos facilmente com o ajuste adequado, em vez de usar mais recursos de hardware para resolver o problema. A maioria dos desenvolvedores e muitos fornecedores não têm capacidade ou recursos para testar seus aplicativos e back-end de banco de dados com a mesma quantidade de dados e carga semelhante à que você obtém na produção e eles fazem suposições e escolhas de design que não serão dimensionadas também bem na prática.
O monitoramento cuidadoso lhe dará uma ideia de quais são seus gargalos e o que você pode precisar resolver no aplicativo, no banco de dados ou no nível do hardware.
Observe que a análise e o ajuste de desempenho são tanto uma ciência quanto uma arte negra.
Problemas de aplicação muito comuns que podem ser facilmente resolvidos e muitas vezes proporcionam benefícios significativos são
- índices ausentes em um banco de dados
- pool de conexões e cache de consultas
- ajuste de limites de memória, número de conexões, soquetes e threads simultâneos de aplicativos
Falhas no design do aplicativo que são mais difíceis de resolver são onde há muita lógica de processamento de dados no front-end do aplicativo e as consultas ao banco de dados são muito simples, não vinculadas e retornam muitos dados (como com um SELECT * from GrowingDataSet) - no monitoramento dos sintomas para isso pode ser tão diverso quanto alta carga de E/S de disco no servidor de banco de dados - alto consumo de memória no servidor de aplicativos - links de rede saturados - cada um dos quais pode ser usado para suportar uma decisão diferente de compra de hardware (atualizar para SSDs no servidor de banco de dados - aumentar RAM no servidor de aplicativos - atualize a rede) provavelmente nada disso será necessário quando o aplicativo começar a aplicar melhor lógica e paginação nas consultas.