Frequentemente, uma instalação de nosso aplicativo no local, baseado em debian-stable, é executado em uma máquina virtual - normalmente no VMware ESXi. No caso geral, não temos visibilidade ou influência sobre seu ambiente de virtualização e não temos acesso, por exemplo, ao cliente VMware vCenter ou equivalente. Concentro-me no VMware aqui, porque esse é de longe o mais comum que vemos.
Gostaríamos de:
- Diga ao administrador VMware de um cliente: Você pode executar nosso aplicativo em, por exemplo, seu ambiente VMware ESX, desde que atenda aos critérios de desempenho X, Y e Z.
- Ser capaz de determinar se os critérios X, Y e Z são de fato atendidos continuamente (por exemplo, também agora ), mesmo em um sistema em execução (não podemos parar nosso aplicativo e executar benchmarks, e um benchmark inicial não será suficiente, pois o desempenho em ambientes virtuais mudam ao longo do tempo).
- Tenha certeza de que se os critérios X, Y e Z forem atendidos, teremos recursos de HW virtuais adequados para executar nosso aplicativo com desempenho satisfatório.
Agora, o que são X, Y e Z?
Temos visto repetidas vezes que, quando há problemas de desempenho, o problema não é com nosso aplicativo, mas com o ambiente de virtualização. Por exemplo, outra máquina virtual usa toneladas de CPU, memória ou a SAN em que os discos estão realmente armazenados, sendo muito usada por algo que não seja nosso aplicativo. Atualmente, não temos como provar ou refutar isso.
Teoricamente também pode ser possível que às vezes nossa aplicação seja lenta... ;-)
Como determinar a causa raiz de nossos problemas de desempenho: ambiente virtual ou nosso aplicativo?
Normalmente existem 3 áreas para problemas de desempenho CPU, Memória e E/S de DISCO.
CPU
Em, por exemplo, VMware, o administrador pode especificar Reserva e Limite, expressos em MHz, mas, por exemplo, 512 MHz em um host ESX é exatamente igual a 512 MHz em outro host ESX, possivelmente em um cluster ESX completamente diferente?
E como medir se realmente conseguimos isso? Enquanto nosso aplicativo está em execução, talvez possamos ver que estamos com 212% de utilização da CPU em 4 CPUs. Isso é porque nosso aplicativo está fazendo muito ou porque outra VM no mesmo host está executando uma tarefa intensiva da CPU e usando toda a CPU?
Memória (balão?)
Se pedirmos, por exemplo, 16 GB de RAM, que geralmente é configurado, mas por causa do balonismo , na verdade recebemos apenas 4 GB e, surpresa, nosso aplicativo tem um desempenho ruim.
Pode-se perguntar às ferramentas VMware sobre o aumento atual, mas descobrimos que muitas vezes ele mente (ou pelo menos é impreciso). Vimos exemplos em que o sistema operacional pensa que há 16 GB de RAM total, a soma da memória residente (RSS) de todos os processos é de 4 GB de RAM, mas há apenas 2 GB de RAM livre, mesmo quando as ferramentas VMware nos informam que há 0 balonismo : -(
Além disso, apenas adicionar RSS não é válido, pois pode haver RAM compartilhada facilmente, por exemplo, memória de cópia na gravação, então 512 MB + 512 MB não significa necessariamente 1 GB, mas pode significar algo menos. Portanto, não se pode simplesmente subtrair RSS de todos os processos para obter uma medida de quanta RAM deve estar livre e, assim, detectar o aumento de volume de forma confiável. Pode-se detectar alguns casos de balonismo, mas há outros casos em que o balonismo está em vigor, mas não detectável por este método.
E/S de disco
Acho que poderíamos representar graficamente ao longo do tempo o número de leituras e gravações de disco, o número de bytes lidos e gravados e a % de espera de E/S. Mas isso nos dará uma imagem precisa da E/S do disco? Imagino que, se houver um minerador de bitcoin em execução em outra VM usando toda a CPU, nosso IO wait % aumentará, mesmo que a SAN subjacente forneça exatamente o mesmo desempenho, simplesmente porque nossos recursos de CPU caem e, portanto, IO wait ( que é medido em % ) aumenta.
Então, em resumo, que linguagem podemos usar para descrever, por exemplo, para um administrador VMware, qual desempenho precisamos, de maneira portátil e mensurável?
Sério, a maioria dos administradores de VMware não é boa nisso: pouca compreensão do gerenciamento de recursos, geralmente nenhum conhecimento de Linux (isso ajuda) e falta de largura de banda de tempo. Acho que a maioria dos administradores internos tem dificuldade em manter um conhecimento profundo de virtualização.
Felizmente, há um livro que você pode ler !
A maioria dos ambientes VMware não são bons: design de cluster ruim, planejamento de recursos ruim , armazenamento abaixo do padrão (ou seja, Synology NAS), HA mal configurado, sem monitoramento ou aplicação de patches.
A VMware como uma organização falha conosco: eles são particularmente ruins em divulgar informações atualizadas e promover as melhores práticas. Pesquisas básicas para perguntas comuns geram resultados de 2009 e revisões anteriores do VMware, apesar do fato de que processos e designs mudaram ao longo do tempo.
Todas essas coisas funcionarão contra você.
Você deve determinar os requisitos reais de sua solução. Ser capaz de afirmar com precisão que seu dispositivo requer: 2 vCPU, 8 GB de RAM e 500 IOPs de desempenho de armazenamento ajudaria muito alguém como eu.
A outra abordagem é observar um ambiente saudável ou ideal e extrapolar as métricas a partir daí.
Você descreveu problemas com determinadas implantações. Quais foram os problemas e gargalos?
Um exemplo de uma VM do tamanho certo:
Um servidor Exchange para uma organização de 300 usuários.
Exemplos de monitoramento de recursos de VM.
Bom-ish: - VM é do tamanho certo. - A CPU está sobrecarregada em todo o cluster, mas não estamos enfrentando contenção.
Ruim: