Técnicas de recuperação de memória no ESXi – parte 1

Padrão

A virtualização trouxe consigo uma grande revolução quando se trata de gerenciamento de recursos. A possibilidade de consolidar vários sistemas operacionais em uma lata, exige que o hypervisor coordene a alocação dos recursos físicos do host para as máquinas virtuais. O ESXi utiliza de várias técnicas para maximizar o desempenho do host e também economizar recursos em momento de contenção. Importante lembrar que o ESXi permite o overcommitment, processo que permite provisionar recursos à uma maquina virtual, mesmo que ultrapasse a capacidade física do host.

Um dos destaques do hypervisor da VMware é o gerenciamento de memória. Quando os recursos físicos do host estão escassos, o VMkernel sai à procura de oportunidades para recuperar um espaço de memória que foi alocado, mas que não está sendo utilizado pelas máquinas virtuais.

As técnicas utilizadas são: TPS (transparent page sharing), balloon driver (ou vmmemctl), memory compression e memory swapping.

Antes de falar sobre cada um deles, vamos entender como o ESXi sabe em qual situação ele deve usar cada técnica. O ESXi se baseia em uma métrica chamada “host memory state”, que é determinada pela quantidade de memória livre do host em um determinado momento.

E qual threshold que o ESXi utiliza para associar à cada estado de memória? O ESXi usa uma métrica própria chamada de “minFree“, que serve como referência de quando as técnicas de gerenciamento de memória precisam ser usadas. O cálculo é feito da seguinte forma:

Para os primeiros 28GB de memória do seu host o valor inicial do minFree será 899 MB + 1% sobre o restante de memória.

Por exemplo, vamos supor que seu host possua 64 GB de memória. O cálculo ficaria assim:

64 GB – 28 GB = 36 GB

899MB + 1% de 36GB = 899MB + 360MB = 1259 MB

Com o valor do minFree, é possível entender os thresholds:

  • high state: há memória suficiente disponível
  • clear state: de 64 a 100% do minFree
  • soft state: entre 32 e 64% do minFree
  • hard state: entre 16 e 32% do minFree
  • low state: entre 0 e 16% do minFree

De acordo com o estado de memória de cada host, as seguintes técnicas de recuperação de memória são utilizadas:

Vamos entrar à fundo e falar sobre cada uma delas.

  1. TPS (transparent page sharing)

O hypervisor tem conhecimento sobre a alocação de memória de cada máquina virtual. Em um ambiente virtualizado podem existir várias máquinas com o mesmo sistema operacional que executam funções semelhantes.

O TPS funciona com qualquer VM ligada e em todos os memory states. É um método oportunístico de gerenciamento de memória, ou seja, só age quando o guest-os dá a possibilidade dele agir. Ele fica a todo tempo procurando por oportunidades de quebrar diferentes páginas de memória com conteúdo idêntico em apenas uma.

Trocando em miúdos, é um processo de deduplicação de memória.

O TPS é discreto, utiliza um processo que fica em background e tem baixíssimo overhead. A todo momento, o host analisa e armazena em uma tabela o conteúdo de memória das máquinas virtuais através de uma função hash. Se a tabela de hash já possuir o valor em questão, o TPS compara byte por byte para verificar se o conteúdo de memória é realmente idêntico. Se o conteúdo for idêntico, o TPS armazena somente uma vez e compartilha o conteúdo semelhante entre as máquinas virtuais.

O TPS não funciona bem com páginas de memória muito grandes, pois o overhead para a operação é alto e a possibilidade de haver páginas de memória idênticas é baixa.

A confiabilidade do TPS foi colocada à risca depois da descoberta de uma possível vulnerabilidade. Para mais detalhes veja o KB: http://kb.vmware.com/kb/2080735.

Devido à preocupação com a segurança no uso do TPS, a VMware introduziu o conceito de salting. salting permite que você tenha um gerenciamento mais granular do TPS e habilite o seu uso somente nas máquinas virtuais que você decidir. Ou seja, o TPS só compartilhará a página de memória se o conteudo for idêntico e os valores de salt das máquinas virtuais forem iguais. Cada máquina virtual possui um valor diferente de salt.

O processo de salting pode ocorrer apenas dentro de uma máquina virtual (Intra-VM) ou entre máquinas virtuais (Inter-VM).

O valor de salt das máquinas virtuais pode ser configurado através do arquivo .vmx. Se você verificar que um grupo de máquinas virtuais possuem uma função em comum e podem, possivelmente, compartilhar páginas de memória, atribua o mesmo valor de salt à elas.

2. Balloon driver

Esse método se diferencia completamente do TPS. O balloon driver faz acreditar que a máquina virtual está usando mais memória do que de fato ela consome e a disponibiliza de volta para o hypervisor gerenciar da forma que achar necessário. O principal objetivo do balloon driver é interagir com a máquina virtual, informando que o host está congestionado e que precisa que o SO libere um pouco de sua memória.

O balloon driver utiliza uma técnica que se parece com “encher um balão”. Esse balão pode aumentar ou diminuir o consumo de memória em uma máquina virtual, forçando que o seu sistema operacional utilize suas próprias técnicas para gerenciar a memória. No caso do Windows por exemplo, o arquivo pagefile.sys seria usado para swap em disco. Em um último momento, o balão desincharia e o sistema operacional faria o swap novamente de volta para a memória.

Nos parâmetros avançados da máquina virtual, é possível editar a quantidade de memória em MB que o balloon driver pode recuperar, através do comando sched.mem.maxmemctl. Esse processo de “enganar” o sistema operacional é feito através do VMware Tools. Isso significa nas máquinas sem VMware Tools o balloon driver não funcionará.

É importante enfatizar que o processo de ballooning só acontece quando há pouca memória disponível no host. Você nunca vai ver o balloon driver trabalhar em um ambiente com recursos de sobra.

Na parte 2 vou dar continuidade ao assunto e falar sobre memory compression e memory swapping.

Até mais!

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *