Gerencie Recursos em Hosts de KVM Sobrealocados

Consolidando cargas de trabalho ao sobrealocar recursos

Um dos principais benefícios da virtualização é a capacidade de consolidar diversas cargas de trabalho em um único sistema de computador. Essa consolidação proporciona economia no consumo de energia, despesas de capital e custos de administração. O grau de economia depende da capacidade de sobrealocar recursos de hardware como memória, ciclos de CPU, E/S e largura da banda da rede. Tecnologias como balão de memória e Kernel Same-page Merging (KSM) podem melhorar a sobrealocação de memória com um ajuste manual adequado. A reconfiguração autonômica desses controles em resposta às condições do host e da VM pode proporcionar economias ainda maiores. Neste artigo, aprenda a aplicar essas técnicas para aumentar as suas economias.

Adam Litke, Software Engineer, IBM

Adam Litke começou o trabalho com Linux ajudando a atualizar a arquitetura do PPC64 na IBM em 2001. Desde então, trabalhou em vários projetos, como crash dumping baseado em kexec, páginas grandes, libhugetlbfs, e um equipamento de automação usado por test.kernel.org. Atualmente, Adam trabalha com virtualização e contribui para o qemu, libvirt, o kernel Linux e o Memory Overcommitment Manager.



01/Mar/2011

A virtualização promete aumentar a eficiência possibilitando a consolidação da carga de trabalho. Maximizar a densidade da máquina virtual e, ao mesmo tempo, manter um bom desempenho pode ser um grande desafio:

  • A utilização de recursos como CPU, memória e largura da banda para rede e acesso de armazenamento pela carga de trabalho varia ao longo do tempo; se você consegue alocar dinamicamente esses recursos de acordo com a demanda, pode obter uma densidade maior com a sobrealocação.
  • O gerenciamento ótimo dos recursos também depende de fatores como a configuração do sistema e do hardware.

Uma das formas de desenvolver uma estratégia de gerenciamento que incorpora os dois fatores é escrever um conjunto de regras em uma linguagem de política. É possível padronizar a política de acordo com as suas condições específicas e equilibrar de forma efetiva os objetivos de consolidação e desempenho.

Este artigo explora os desafios associados à sobrealocação agressiva e propõe uma ferramenta de gerenciamento baseada em políticas que pode ajudar a superar os desafios. A ferramenta é implementada em um ambiente normal de KVM e gerencia duas cargas de trabalho distintas. Este artigo avalia os resultados desse exercício e termina com sugestões de itens de trabalho adicionais e possíveis temas de pesquisa.

Desafios da sobrealocação

Uma investigação completa sobre a sobrealocação de memória na KVM deve começar pelo próprio gerenciador de memória do Linux. Por estar baseado nos conceitos de memória virtual, o Linux usa técnicas de sobrealocação de memória por motivos estruturais.

As páginas de memória solicitadas por um processo não são alocadas até que sejam realmente usadas. Usando o cache de página do Linux, diversos processos podem economizar memória acessando arquivos por meio de páginas compartilhadas. À medida que a memória se esgota, o sistema pode liberar memória trocando as páginas menos usadas com o disco. Embora não sejam perfeitas, essas técnicas podem ter como resultado uma diferença considerável entre a quantidade de memória alocada e a quantidade que realmente é usada.

Já que as máquinas virtuais KVM são processos regulares, as técnicas padrão de conservação de memória se aplicam a elas. Entretanto, ao contrário dos processos regulares, os guests de KVM contêm um sistema operacional aninhado, que afeta a sobrealocação da memória de duas formas importantes. Os guests de KVM podem ter mais potencial para a sobrealocação de memória que os processos regulares. Isso se deve a uma grande diferença entre o requisito mínimo e o requisito máximo de memória do guest, causada por variações na utilização.

O fato de aproveitar essa variabilidade é fundamental para que a virtualização seja interessante, mas isso nem sempre é fácil. Enquanto o host está gerenciando a memória alocada a um guest da KVM, o kernel do guest está gerenciando a mesma memória simultaneamente. Sem alguma forma de colaboração entre o host e o guest, nem o host nem o gerenciador de memória do guest consegue tomar decisões ótimas sobre cache e troca, e isso pode levar a um uso menos eficiente da memória e à diminuição do desempenho.

O Linux fornece mecanismos adicionais, específicos para a virtualização, para tratar da sobrealocação de memória.

  • O balão de memória é uma técnica na qual o host instrui um guest cooperativo a liberar parte de sua memória designada para que seja usada para outro fim. Essa técnica pode ajudar a passar do host para o guest a pressão referente à memória.
  • O Kernel Same-page Merging (KSM) usa um encadeamento kernel que varre intervalos de memória previamente identificados para procurar páginas iguais, mescla essas páginas e libera as duplicadas. Os sistemas que executam um grande número de máquinas virtuais homogêneas se beneficiam mais dessa forma de compartilhamento de memória.
  • Outros dispositivos de gerenciamento de recursos como o Cgroups, têm aplicativos em sobrealocação de memória que podem mudar recursos de uma máquina virtual para outra de forma dinâmica.

Esses mecanismos fornecem um framework efetivo para gerenciar a memória sobrealocada, mas todos eles têm a mesma limitação: devem ser configurados e ajustados por uma entidade externa. A configuração automática não está disponível porque os componentes individuais da pilha de virtualização não têm informações suficientes para tomar decisões sobre ajuste.

Por exemplo, está além do escopo de um único processo de qemu saber se o host está ficando sem memória e quanta memória pode ser obtida por balão a partir do guest sem prejudicar o desempenho. Essas decisões só podem ser tomadas quando a política administrativa é combinada com informações em tempo real sobre o host e os seus guests.

Para superar esse desafio com o KSM, foi escrito um daemon chamado ksmtuned para gerenciar dinamicamente os parâmetros ajustáveis de acordo com o potencial de compartilhamento e a necessidade de memória. Já que ksmtuned gerencia um único mecanismo em isolamento, não pode fazer parte de uma solução abrangente.

O uso de qualquer mecanismo de sobrealocação afeta de forma fundamental a operação dos sistemas de gerenciamento de memória do host e do guest. Sendo assim, é provável que o uso simultâneo de diversos mecanismos cause efeitos colaterais. A Figura 1 ilustra uma interação entre o balão de memória e o KSM.

Figura 1. Os efeitos do balão de memória no KSM
The effects of memory ballooning on KSM

Nesse exemplo, a pressão crescente do balão compromete a capacidade que a KSM tem de compartilhar páginas. Os drivers de balão do guest selecionam páginas para executar balão sem levar em conta se a página do host pode ser compartilhada ou não. A execução de balão em uma página compartilhada é um erro porque priva o guest de recursos sem efetivamente poupar memória. Para maximizar a eficiência, esses tipos de interação devem ser previstos e gerenciados.

É possível implementar virtualização baseada em KVM em uma grande variedade de configurações usando arquiteturas projetadas para alcançar objetivos diferentes. A consolidação agressiva de máquinas virtuais requer um comprometimento do desempenho. O desempenho adequado entre consolidação e desempenho depende da situação.

A sobrealocação de memória pode aumentar a demanda por todos os outros recursos do sistema. A pressão sobre os caches de memória aumenta a E/S de disco ou de rede, e o aumento da atividade de reivindicação de páginas faz com que o guest consuma mais ciclos de CPU.

É possível superar esses desafios com um novo daemon projetado para a tarefa: Memory Overcommitment Manager (MOM).


Gerenciamento dinâmico com o MOM

A Figura 2 mostra o daemon MOM (Memory Overcommitment Manager).

Figura 2. Memory Overcommitment Manager
Memory Overcommitment Manager

O MOM fornece um framework flexível para a coleção de estatísticas do host e do guest, um mecanismo de política e pontos de controle para balão e KSM. Com o MOM, o administrador pode desenvolver uma política de sobrealocação que responde às condições em tempo real com ajustes dinâmicos do sistema que são ajustáveis para obter um nível mais alto de sobrealocação de memória.

O MOM usa uma libvirt para manter uma lista de máquinas virtuais que estão executando no host. A um intervalo de coleta regular, são reunidos dados sobre o host e os guests. Os dados podem vir de diversas origens (a interface /proc do host, a API libvirt, virtio-serial ou uma conexão de rede ao guest). Uma vez coletados, os dados são organizados para uso pelo mecanismo de política. O (Virtio é um padrão para os drivers de rede e dispositivos de disco, no qual só o driver de dispositivo do guest "sabe" que está executando em um ambiente virtual e, portanto, coopera com o hypervisor, possibilitando que os guests obtenham operações de disco e rede de alto desempenho. No total, o Virtio proporciona a maioria dos benefícios de desempenho da paravirtualização.)

O mecanismo de política é basicamente um pequeno interpretador que entende os programas escritos em uma linguagem de política simples. O MOM avalia periodicamente a política fornecida pelo usuário usando os dados coletados. A política pode acionar mudanças na configuração, como o enchimento do balão de memória de um guest ou uma mudança na taxa de varredura do KSM.

Ao longo do tempo, o framework do MOM pode ser expandido para coletar a partir de origens de dados adicionais e para controlar novos mecanismos de sobrealocação de memória conforme o desenvolvimento progride nessa área.


Avaliando o MOM

Para avaliar o MOM e a sua eficácia no gerenciamento da memória sobrealocada, vamos examinar duas cargas de trabalho de virtualização:

  • Na primeira carga de trabalho, as máquinas virtuais são configuradas para consumir quantidades variadas de memória anônima, de acordo com um padrão de acesso prescrito.
  • A segunda carga de trabalho usa uma referência de LAMP, na qual cada máquina virtual funciona como uma instância independente do MediaWiki.

Para cada carga de trabalho, uma política do MOM que controla o balão de memória e o KSM é avaliada. Para evitar a troca de host, o balão de memória de cada guest é ajustado dinamicamente de acordo com a pressão sobre a memória do host e do guest. Usando o mesmo algoritmo de ksmtuned, o KSM é ajustado com base na pressão sobre a memória e a quantidade de memória compartilhável.

Os dois cenários de carga de trabalho

O cenário de carga de trabalho do Memknobs usa um programa simples chamado Memknobs para criar pressão sobre a memória alocando e tocando páginas de memória anônima em um padrão que desafia os algoritmos de reivindicação de memória do kernel. O Memknobs aloca um buffer de tamanho fixo e faz um loop pelas páginas do buffer, gravando em cada uma delas. Ao chamar o Memknobs repetidamente com um tamanho de buffer que muda gradualmente em cada iteração, o guest pode simular uma carga de trabalho limitada pela memória sem componente de E/S. Para sobrealocar a memória em um host, implementamos o Memknobs em 32 máquinas virtuais nas quais cada instância usou a memória segundo um padrão exclusivo.

Para o cenário de carga de trabalho do Cloudy, geramos uma carga de trabalho realista com um componente de E/S de disco usando um conjunto aberto chamado Cloudy. O Cloudy é uma referência de LAMP fácil de configurar que mede a escalabilidade da virtualização e mostra os efeitos da sobrealocação de recursos. Diversas máquinas virtuais são configuradas como servidores do MediaWiki. Cada wiki é carregado com páginas da Wikipédia e com dados de imagem gerados aleatoriamente.

Um plano de teste JMeter incluído exerce todas as instâncias e mede o rendimento e os tempos de resposta. O plano de teste pode ser configurado para produzir uma carga de trabalho em estado estável ou para introduzir variabilidade alternando a carga de trabalho entre diversos grupos de máquinas virtuais. É possível variar a quantidade e o tipo de carga alterando a taxa de solicitação, o número de usuários simultâneos e o tamanho dos arquivos de imagem wiki gerados aleatoriamente. Um acelerador de PHP reduz o consumo de CPU a um nível desprezível. Essa carga de trabalho pode gerar uma quantidade significativa de E/S e é sensível à quantidade de largura da banda disponível ao acessar o dispositivo de armazenamento de imagens da máquina virtual.

A política

Nossa estratégia de balão de memória foi projetada para evitar a troca de host, direcionando a pressão sobre a memória aos guests. O host, sem ter informações de acesso às páginas do guest, não consegue aplicar adequadamente os seus algoritmos de LRU ao selecionar páginas para trocar. Além disso, o sistema operacional guest tem a maior parte das informações sobre o uso da memória pela carga de trabalho e deve ser capaz de tomar as melhores decisões sobre decisões de substituição de páginas.

A política depende do balão de memória para manter um pool de memória do host que pode ser liberada prontamente. Definimos a memória liberável como a soma de MemFree, Buffers e Cache conforme o relatado em /proc/meminfo. Quando o tamanho desse pool fica abaixo de 20% da memória total, o balão de memória é iniciado. Aplica-se pressão aos guests de acordo com o nível de pressão sobre a memória do host. A memória livre é reivindicada primeiro; portanto, os guests com mais memória não utilizada executam mais balão. Com uma pressão suficiente do balão, os guests despejarão as páginas em cache e iniciar a troca. Quando a pressão sobre a memória diminui, os balões são esvaziados para devolver memória aos guests.

Nosso algoritmo de ajuste de KSM foi projetado para corresponder ao do ksmtuned. Primeiro, toma-se a decisão de ativar ou não o encadeamento kernel de acordo com um limite de memória livre que definimos como 20% da memória total do host. O KSM tem permissão para executar, a não ser que o host cumpra as duas condições a seguir:

  • A memória livre excede o limite e
  • A memória total menos o limite de memória livre excede a quantidade total de memória designada a todas as máquinas virtuais.

Essas condições testam, respectivamente, se o host está sob pressão de memória e se a virtualização é responsável por isso. A desativação do ksmd quando ele não é necessário economiza ciclos de CPU.

Quando o ksmd está ativado, a sua operação é ajustada de acordo com o tamanho total da memória e a pressão de memória. O intervalo entre as varreduras é ajustado de acordo com o tamanho da memória do host. Para um host de 16 GB, 10 segundos é o padrão. Máquinas maiores terão intervalos menores e vice-versa. O número de páginas a varrer por intervalo aumenta ou diminui de acordo com a quantidade de memória livre. Se a quantidade de memória livre é inferior ao limite de memória livre, a taxa de varredura é aumentada em 300 páginas. Do contrário, é diminuída em 50. O número de páginas a varrer não pode estar fora do intervalo de 64 a 1.250.


Os resultados

Nossos experimentos foram realizados em um IBM BladeCenter® HS22. O sistema tem 16 CPUs lógicas com suporte para EPT e 48 GB de RAM. Para aumentar a capacidade de armazenamento e a largura da banda, as imagens de máquina virtual foram hospedadas em um dispositivo externo de NFS conectado por meio de uma LAN Ethernet privada de 10 gigabits. Avaliamos a eficácia da política do MOM usando o Memknobs e os cenários de carga de trabalho do Cloudy. Para medir o impacto de cada cenário no desempenho, foram realizados testes de uma hora com e sem a política do MOM ativa.

Cenário de carga de trabalho do Memknobs

Para esse experimento, providenciamos 32 máquinas virtuais com 2 GB de RAM e 1 VCPU cada uma. Calibramos a carga de memória do Memknobs, mostrado na Figura 3, para colocar o host sob uma pressão de memória suficiente para causar a atividade regular de troca. Por meio da experimentação, conseguimos produzir um padrão que proporcionou o comportamento desejado do host.

Figura 3. Padrão de acesso à memória do Memknobs
Memknobs memory access pattern

O programa Memknobs controla o número de páginas que ele conseguiu tocar em cada iteração. Esse valor de rendimento é relatado em unidades de megabytes de memória tocados por segundo. Para facilitar comparações entre experimentos diferentes, derivamos uma pontuação de rendimento médio total calculando o rendimento médio de cada guest e somando os 32 valores. A Tabela 1 compara as pontuações obtidas ao usar políticas diferentes do Memory Overcommitment Manager.

Tabela 1. Resultados das políticas do MOM: rendimento total médio do Memknobs
Política do MOMResultado
Nenhuma4331,1
Somente KSM4322,6
KSM e balão5399,5

Esses resultados mostram que o uso do balão de memória contribuiu com um aumento de quase 20% no rendimento. Embora o KSM tenha sido altamente efetivo no compartilhamento de páginas para essa carga de trabalho, não foi responsável pelo aumento do desempenho. A Figura 4 compara a atividade de troca entre uma execução do Memknobs com balão de memória e uma execução sem ele.

Figura 4. Comparação das trocas com o Memknobs
Memknobs swap comparison

Com a política do MOM ativa, a atividade de troca foi concentrada efetivamente nos guests e o número total de operações de troca foi reduzido pela metade.

Cenário de carga de trabalho do Cloudy

Para dimensionar o Cloudy adequadamente para o nosso ambiente, configuramos 32 instâncias de MediaWiki em máquinas virtuais. Essa carga de trabalho usa menos memória que o Memknobs. Para garantir que o guest tivesse uma memória limitada, só foi designado 1 GB de RAM para cada VM. Compensando a ocupação de espaço reduzida das máquinas virtuais, reservamos 15.714 páginas grandes — reduzindo efetivamente a memória disponível do host a 16 GB.

O plano de teste JMeter foi configurado para fornecer solicitações a uma taxa média de 16 solicitações por segundo por máquina virtual. Isso produziu uma carga moderada sem gargalos de recursos quando o sistema não estava sobrealocado. O JMeter registra estatísticas sobre cada solicitação que faz. Calculamos uma métrica de qualidade de serviço (QOS) como o percentil 95 da duração das solicitações em milissegundos. O rendimento médio da instância é o tamanho total de todas as solicitações concluídas em kilobytes, dividido pelo número de guests participantes.

A Tabela 2 mostra a QOS e o rendimento obtido com e sem o nosso KSM e sem a política de balão de memória do MOM ativados.

Tabela 2. QOS e rendimento do Cloudy
VMsPolítica do MOMQoSRendimento
1Não1669710007
32Não3240774555
32Sim3231764762

São mostrados resultados de uma execução envolvendo uma única VM para ilustrar o desempenho em um host sem restrições. A principal observação a partir desses dados é que a mesma política do MOM que aumentou drasticamente o desempenho do Memknobs não teve nenhum efeito em relação ao Cloudy. O uso de memória nessa carga de trabalho pode ser atribuído principalmente à E/S de arquivos, memória não anônima e observou-se muito pouca atividade de troca. Em vez disso, a sobrealocação de memória pressiona os caches de página do host e do guest, causando o aumento de E/S conforme o sistema tenta manter o conjunto de trabalhos carregado em uma quantidade menor de memória (veja a Figura 5).

Figura 5. Impacto do balão de memória na E/S referente a um único guest
The impact of memory ballooning on I/O for a single guest

Embora seja efetivo na limitação da memória, o uso da reserva de páginas grandes para reduzir a memória disponível no host pode interferir nos algoritmos de gerenciamento de memória do host de forma sutil. Futuramente, esse experimento deve ser repetido em uma máquina com 16 GB de memória física para avaliar o sistema no cenário mais realista possível.

Analisando os resultados

Os resultados contrastantes que foram encontrados ao estudar essas duas cargas de trabalho diferentes levaram a uma conclusão óbvia: ao sobrealocar a memória, todos os aspectos do sistema e sua carga de trabalho devem ser levados em conta. Não existe política de gerenciamento com "tamanho único".


Melhorias planejadas

Embora ainda esteja nos estágios iniciais, este trabalho promete aprimorar o estado da sobrealocação de recursos com o KVM, e há muitas melhorias planejadas e em andamento.

Atualmente, não há nenhum método padronizado de comunicação entre o host e os guests. As abordagens atuais (como a comunicação de rede do host com o guest) dependem da configuração manual do host e de cada guest, e essa configuração é determinada pelos tipos e versões do sistema operacional, configuração de rede do datacenter e modelos de dispositivo das máquinas virtuais. Nosso objetivo é simplificar esse problema ao integrar um mecanismo de comunicação ao qemu que possa suportar diversos transportes de dados, incluindo virtio-serial e serial emulado. O lado do guest do canal seria suportado por um pacote de ferramentas de guest de qemu multiplataforma de software livre. Um mecanismo desse tipo melhoraria a capacidade do MOM de reunir estatísticas do guest e seria muito útil para recursos como copiar/colar e tarefas de administração.

Como foi demonstrado, uma política de sobrealocação pode ajudar em algumas situações e atrapalhar em outras. Para ser implementável de forma segura, a política não pode atrapalhar o desempenho. As políticas do MOM devem ser melhoradas ao incluir proteções que retrocedam operações de gerenciamento quando não produzem os resultados esperados.

Atualmente, o KVM tem um mecanismo muito eficiente de compartilhamento efetivo de CPU. Quando uma CPU de guest executa a instrução hlt , ela cede voluntariamente tempo de CPU para outros guests. Seria possível reduzir os impactos da sobrealocação de memória no desempenho se houvesse um protocolo semelhante baseado no guest para ceder recursos de memória.

Quando a comunidade desenvolver novos recursos que possam melhorar a sobrealocação de KVM, o suporte para esses recursos será integrado à infraestrutura do MOM. Por exemplo, planejamos habilitar o suporte para limites de RSS baseados em cgroups para impor as diretivas de balão e proteger o sistema contra guests não cooperativos ou mal intencionados.


Conclusão

A sobrealocação de recursos é fundamental para maximizar os benefícios da virtualização e é objeto de muita pesquisa e desenvolvimento. Conforme a virtualização em Linux for evoluindo, as boas práticas de sobrealocação também evoluirão. Uma abordagem holística e baseada em políticas para gerenciar a sobrealocação é a melhor forma de maximizar a eficiência e impulsionar melhorias incrementais.

Agradecimentos

De uma longa lista de colegas merecedores, eu gostaria de agradecer especificamente a Anthony Liguori e Karl Rister. Seus conselhos e conhecimento técnico foram fundamentais para a concepção e desenvolvimento do Memory Overcommitment Manager e desta pesquisa.

Recursos

Aprender

Obter produtos e tecnologias

Discutir

  • Leia essa discussão sobre as limitações do recurso de processador EPT.
  • Participe da comunidade do My developerWorks. Entre em contato com outros usuários do developerWorks e explore os blogs, fóruns, grupos e wikis voltados para desenvolvedores.

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Linux, Cloud computing
ArticleID=630204
ArticleTitle=Gerencie Recursos em Hosts de KVM Sobrealocados
publish-date=03012011