Os usuários de sistemas virtualizados, e especialmente os provedores de serviços, costumam se perguntar: "como tirar o máximo proveito do hardware disponível?" E, nesse contexto, geralmente precisamos discutir o hipervisor KVM e as diferenças entre as diferentes versões do Virtuozzo. Neste post, falaremos sobre uma série de testes do mais recente sistema de virtualização, juntamente com estimativas de desempenho real sob cargas típicas, além de levar em consideração os patches Meltdown e Spectre.
O que é mais importante para uma empresa de hospedagem ou para um departamento de TI que precisa organizar o suporte para o número máximo de tarefas nos equipamentos existentes? Se uma empresa trabalha de acordo com um modelo orientado a serviços ou vende serviços, a prática mostra que o principal é o indicador de lucro por servidor. Quais tecnologias são usadas ao mesmo tempo e devido às quais a densidade de distribuição é alcançada, os representantes comerciais não estão tão preocupados.
No entanto, a pergunta por que usamos o KVM como um hypervisor no Virtuozzo 7 e como diferimos de um simples sistema de virtualização OpenSource nesse caso é feita com muita frequência. E hoje eu quero dar uma resposta para isso.
No passado, a Virtuozzo trabalhava com seu próprio hypervisor proprietário, mas há vários anos percebemos que desenvolvê-lo é mais caro e mais difícil do que otimizar uma KVM razoavelmente bem-sucedida e eficiente. No entanto, o KVM não é uma referência de desempenho e, como qualquer plataforma OpenSource, precisa ser atualizado com um arquivo. Isso faz parte do nosso departamento de desenvolvimento. Otimizamos o código, integramos à plataforma de armazenamento de dados e outros componentes, aumentando assim a produtividade e a densidade.
Comparação com outros hipervisores
Um dos testes que usamos para medir o desempenho é a loja de DVD. Ele usa um conjunto clássico de software para servidor: Linux, Apache, MySQL, PHP (LAMP). Dentro de cada máquina virtual, o teste simula a operação de uma loja de DVD online. O resultado do teste é o número de transatais confirmadas no total em todas as máquinas virtuais (eixo de ordenadas). O número de máquinas virtuais envolvidas no teste aumenta sequencialmente de 1 para 100 (eixo da abcissa).
LAMP: OpenSource QEMU KVM vs Virtuozzo @ CentOS 7.4 (máquinas virtuais)
Como você pode ver nos gráficos acima, o desempenho das máquinas virtuais com o CentOS Linux 7.4 em execução no hipervisor Virtuozzo 7 é até 30% maior do que quando se inicia uma carga semelhante no KVM padrão. A maior diferença é observada no ponto de confirmação excessiva da CPU, em que o número total de núcleos de processador alocados em todas as máquinas virtuais atinge o número de núcleos físicos do servidor da CPU. Para este servidor, este ponto corresponde a 20 máquinas virtuais. Além disso, a política de gerenciamento de memória adaptável e de núcleo do Virtuozzo 7 garante a operação estável de máquinas virtuais após o ponto de confirmação excessiva da RAM, em que a quantidade total de RAM alocada para todas as máquinas virtuais excede o tamanho da memória física do servidor. Com essa carga, o KVM padrão não pode criar as condições para operação normal.
Outra comparação foi feita entre o hypervisor Virtuozzo 7 e o Microsoft Hyper-V 3.0. Aqui, o desempenho foi avaliado usando o teste vConsolidate e o Windows Server 2012 R2 foi usado como um sistema operacional convidado para máquinas virtuais.
vConsolidate: Hyper-V vs Virtuozzo no Windows 2012 R2 (máquinas virtuais)
Diferentemente da DVD Store, no vConsolidate, a carga não é a mesma para todas as máquinas virtuais. Nesse teste, eles são divididos na chamada CSU (Consolidation Stack Units). Cada CSU é um grupo de quatro máquinas virtuais que carregam SPECjbb, WebBench e SysBench (OLTP). A quarta VM em cada CSU está ociosa, ou seja, sem carga. O resultado quantitativo é a média geométrica dos resultados dos três testes mencionados acima, obtidos no total de todas as máquinas virtuais (eixo das ordenadas). O número de CSUs envolvidas no teste aumenta sequencialmente de 1 para 24 (abscissa).
Para os dois hipervisores, o teste foi realizado duas vezes: com patches para as vulnerabilidades Meltdown e Spectre instalados, e sem eles. A aproximação dos resultados mostra que o Virtuozzo 7 em média demonstra desempenho 15% maior que o hipervisor "nativo" da Microsoft.
Fusão e Espectro
Como você sabe, em 4 de janeiro de 2018, toda a comunidade de TI ficou animada com a descoberta de vulnerabilidades conceituais em grande escala em todos os processadores Intel, com exceção do Itanium e do Atom antigo (até 2013). O uso dessas vulnerabilidades permite que qualquer processo não privilegiado do sistema acesse dados do kernel (Meltdown) ou dados de outro processo (Spectre). Os desenvolvedores de software se concentraram em lançar atualizações de software para solucionar essas vulnerabilidades. No entanto, os usuários naturalmente tinham dúvidas sobre como essas atualizações afetavam o desempenho do sistema.
Verificamos como os patches para Meltdown e Spectre afetam o desempenho dos contêineres com o CentOS Linux 7.4 usando o teste vConsolidate como exemplo. Depois fizemos outra medição - com o kernel, um compilador modificado compilado com a opção “Retpoline” (por exemplo, GCC e Clang / LLVM oferecem essa oportunidade).
Desempenho com Retpoline: vConsolidate @ CentOS 7.4 (contêineres)
Como você pode ver nos gráficos acima, a aplicação de patches no Meltdown and Spectre reduz significativamente o desempenho do contêiner. Além disso, o patch mais "difícil" foi para o Spectre-V2. No entanto, o uso do compilador com a nova opção Retpoline permite que você abandone esse patch com segurança em sistemas com processadores anteriores à Skylake e recupere até 25% do desempenho. No entanto, ainda perdemos cerca de 5% devido aos patches para Meltdown e Spectre-V1.
Desempenho com Retpoline: vConsolidate @ CentOS 7.4 (máquinas virtuais)
No caso do CentOS Linux 7.4, a situação dentro das máquinas virtuais é um pouco mais otimista: os patches para Meltdown e Spectre degradam o desempenho em apenas 15%, e a diferença de desempenho entre o kernel não corrigido e o kernel compilado com o Retpoline é de apenas 1-2%. Assim, o uso do novo compilador tornou possível compensar quase completamente a queda no desempenho. No entanto, vale a pena considerar que todas as três medições foram realizadas nas mesmas máquinas virtuais - com kernels de SO convidados não corrigidos. A atualização de sistemas operacionais convidados resultará em degradação adicional do desempenho dos aplicativos do usuário.
Desempenho com o Retpoline: vConsolidate @ Windows 2012 R2 (máquinas virtuais)
O gráfico mais recente de hoje é uma comparação semelhante, mas com as máquinas virtuais do Windows Server 2012 R2. Aqui a desaceleração dos patches não foi tão grande e chegou a cerca de 10%, e o uso do kernel com Retpoline permitiu reduzir a diferença para 2-3% em relação ao kernel não corrigido.
Conclusão
Obviamente, a KVM não modificada tem suas vantagens, e a principal vantagem é a sua gratuidade. Mas os testes realizados provam que melhorias e modernização privadas podem melhorar o retorno da infraestrutura usada. Ou seja, se você precisar colocar o máximo de contêineres e máquinas virtuais, garanta armazenamento permanente para eles - todos na mesma plataforma e com um mínimo de danças xamânicas - o KVM aprimorado é muito mais eficaz, especialmente se os serviços executados na plataforma mostrarem boas margens e trazerem real o dinheiro Nesse caso, o custo de licenças e suporte mais do que compensa no menor tempo possível.
A força do VZ7 continua sendo o suporte de diferentes tipos de VMs e contêineres na mesma plataforma e com maior desempenho para cada categoria de objetos virtuais. No entanto, também não se pode falar de panacéia aqui. Por exemplo, se um aumento na densidade não gerar financiamento adicional para a organização e sua própria equipe puder administrar e concluir soluções OpenSource, a lógica tenderá a usar ferramentas abertas, incluindo o CentOS e o KVM original.
A propósito, no próximo post falaremos sobre a evolução de nosso armazenamento distribuído e seus recursos reais para trabalhar com VMs e contêineres.