auto-ballooning

Escrevi um código que traz uma ferramenta que faz falta a quem faz uso do QEMU/KVM: auto-ballooning das máquinas virtuais!


| Se você apoia nosso site, desative o AdBlock quando visitá-lo, inclusive em Mobile!
Os anúncios são poucos e não invasivos. Se quiser contribuir com nosso trabalho, clique em qualquer banner de sua preferência, exceto dos Parceiros. 
Mais detalhes clicando aqui.


1. Introdução

Já abordei aqui na Linux Universe uma publicação sobre como configurar o QEMU/KVM pra rodar máquinas virtuais.
De todos os recursos poderosos que o KVM possui nativamente, um dos mais interessantes é o Balloon!

2. Balloon

O Balloon – literalmente balão de memória – permite que você possa alterar dinamicamente e ao vivo a quantidade de memória disponibilizada para uma máquina virtual.

Ou seja, você define 1 GB de Memória, e precisa de mais, com um comando você muda de 1024Mb para 2048 Mb, elevando a quantidade de RAM de 1 para 2 Gb, por exemplo.

No Virt-Manager, o menu é este:

Ou seja, defini até 2048 Mb para serem usado, porém aloquei apenas 1024.
Para a máquina virtual, somente 1024 Mb estarão disponíveis como se fossem 1024 MB em memória física! Alterar esse valor altera a coluna “total” do comando “free -h”, o sistema aceita que a RAM física foi aumentada ou diminuída em tempo real.

Até o presente momento o Balloon só ocorre em máquinas virtuais Linux.
O Windows 10 e o Windows 11 não suportam adequadamente esse recurso, consumindo toda a memória disponibilizada imediatamente!

Como essa magia acontece?

3. Funcionamento

O Balloon é relativamente simples: Um código INFLA dentro da memória da máquina virtual, diminuindo seu espaço real e o kernel Linux da máquina virtual é igualmente alertado desse fato.

Ao inflar, para a máquina virtual aquele espaço não é mais alocado. Porém essa inflação é virtual, não real, portanto não consome espaço e a máquina hospedeira entende que essa memória ficou livre para que outros processos ou outras máquinas virtuais possam usa-la novamente.

Memory ballooning principles. | Download Scientific Diagram

Da mesma forma ocorre a deflação da memória, o balloon murcha, aumentando a memória da máquina virtual e diminuindo a parte compartilhada com a máquina hospedeira.

Lembrando que o limite do balloon é delimitado na quantidade de memória RAM máxima que poderá ser alocada. Isso impede que a máquina hospedeira possa congelar por inanição de recursos.

4. auto-ballooning

O Balloon é poderoso e muito eficiente como citado acima, mas tem um problema: não é automático.
Se você quiser alocar memória, terá de faze-lo manualmente, vigiando a máquina virtual de forma contínua…

Desde 2013 houveram notificações de que o projeto KVM poderia receber um auto-ballooning mas isso foi deixado de lado até os dias atuais!

Como eu cuido de máquinas virtuais sob KVM, a ideia de balloon automático seria importante para gerenciar melhor o consumo de hardware: Se a máquina virtual demandar mais memória, ela ganhará mais memória; se sobrar memória, ela vai devolve-la para a hospedeira. Portanto, abracei o desafio de escrever uma solução para a questão que seja relativamente funcional.

5. O Código

A ideia foi inspirada no código do usuário berkerogluu do github, que criou algo que permite liberar a memória sobrando das máquinas virtuais, fazendo uma média do consumo entre todas e pegando uma % geral.

Então escrevi este código que implementa definitivamente o auto-ballooning em todas as máquinas virtuais do sistema operacional!

5.1 Estrutura

Observando o comportamento das máquinas virtuais com o gerenciamento de memória do Linux, o código apenas exige 1 coisa: Que o swappiness seja alterado para 10, assim quando a memória RAM encher até 90%, ele comece então o despejo de SWAP.

A partir desse ponto, observei o valor da memória RAM alocada para o balloon – ou seja, o valor de actual do comando virsh dommemstat – e o valor de memória disponível – o valor usable do referido comando; Aqui, usable é a memória livre + parte de buff/cache que pode ser liberado sem causar SWAP, equivale a “available” exibido com o comando “free -h”.

Cheguei á conclusão que a SWAP começa a despejar com 15% de RAM usable. O daemon inicializa e 1Mb é despejado como “teste”, quando chegamos em 10% livre a SWAP é despejada agressivamente. Então eu fiz 3 condições:

  • Se a memória RAM usable estiver abaixo de 25%, falta memória para a VM e a ameaça de SWAP é real.
    O auto-ballooning executa e dá 50Mb para a RAM. – Esse valor pode ser alterado no código para algo de sua preferência.
  • Se a memória RAM usable estiver acima de 35%, está sobrando memória para a VM.
    O auto-ballooning executa e retira 50Mb para a RAM. – Esse valor pode ser alterado no código para algo de sua preferência.
  • Caso o valor de usable esteja entre 25% e 35%, o script classifica como uma situação Ok e encerra sua execução.

A cada execução, o código faz essa verificação, pra manter o balanceamento da memória.

O interessante é programa-lo para executar a cada 15 minutos.
Uma forma “suja” de fazer isso pelo Cron é criando regras dessa forma:

***** sleep 15; bash /caminho/para/automatic
***** sleep 30; bash /caminho/para/automatic
***** sleep 45; bash /caminho/para/automatic
***** sleep 60; bash /caminho/para/automatic

Assim o código vai executar a cada 15 segundos!
Como o consumo de RAM é algo rápido, o código não pode demorar muito pra monitorar a situação e tomar atitude antes que a VM fique com pouca memória.

6. Conclusão

O código ainda está em fase de melhorias, mas as execuções preliminares mostraram que está promissor.
Também deixei as variáveis de uma forma fácil de trocar, se quiser que a VM tenha entre 40-60% de memória livre proporcional ao total alocado, pode também. Tudo vai depender da sua necessidade.

O código está distribuído no meu github sob a GPLv3:
Façam bom proveito!

#UrbanCompassPony

Deixe um comentário