Gerenciamento de Memoria no ESXI – Pt.1

Faaaala galera, 100%?!

“Tenho um servidor com 16GB, criei 3 VMs com 4GB de memória para cada. Passaram-se 6 meses e agora preciso de outra VM com mais 4GB de memória…será que meu host vai suportar?!”. Leia o artigo até o final e se inscreva aqui no site pra entender quais recursos existem para gerenciamento de memória no ESXI!

Um dos tópicos que mais me chama atenção no mundo da virtualização é como o hypervisor da vmware consegue “brincar” com os recursos de um servidor físicos para atender as maquinas virtuais que estão sob ele. Um ponto que sempre me chamou a atenção é a capacidade de gerenciamento de memória onde o esxi consegue entender que uma VM possui recursos ocioso e acaba por “emprestar” memoria, por exemplo, a uma VM que naquele momento está sob pressão. Neste artigo darei inicio a uma série sobre gerenciamento de recursos, e vamos começar falando sobre o tal gerenciamento de memória no ESXI. A ideia aqui e mostrar a você, de forma simples e objetiva, quais recursos o ESXI entrega para melhorar o uso de seus recursos, neste caso a memória.

É de conhecimento da nação brasileira (by: Cabo Daciolo) que memória não é um recursos barato. E por ironia do destino é um dos, senão o mais caro, dentre os recursos comuns necessários para termos um ambiente virtualizado. Por conta disso é importantíssimo que nós, administradores de ambientes esxi/vcenter, saibamos o que existe de melhor a nível de gestão e obviamente como cada recurso para gerenciamento de memória dentro do esxi funciona. Let’s rock!

Logo durante a criação de uma nova máquina virtual (VM) a tela de configuração nos questiona: “E ai, vai quanto de memória pra esse cara?”. Junto com essa pergunta o próprio esxi já manda a resposta, lhe sugerindo uma quantidade de memória baseando-se em pre requisitos disponibilizados pelos OS. Como exemplo podemos usar um Windows Server 2012 R2, que, caso selecionado, já trará a sugestão de 4GB de memória para uso. Em ambientes menores até que isso não requer tanto planejamento, entretanto, quando falamos de ambientes de maior porte um dos grandes desafio que enfrentará será definir da forma mais correta possível a alocação da bendita memória para determinada VM. Existem alguns recursos que te ajudam a ter melhor gestão sobre os recursos do servidor físico…vamos começar com os mais tranquilos de entender e na próxima parte iremos a recursos mais avançados.

Ballooning

O primeiro deles e muito conhecido – penso eu – é o “Ballooning”. Esse cara engana as VMs e consegue “emprestar” paginas de memória que estão ociosas em determinada VM  para outra que está precisando de recurso naquele momento. O ballooning é parte integrante do VMware Tools – aquele complemente que muitas vezes você esquece de instalar -. Assim que o tools é instalado no S.O um driver de ballooning passa a rodar e consegue executar sua função que já explicarei com mais detalhes. É importante lembrar que existem drivers distintos para cada S.O instalado e que nada acontecerá de forma automática…se liga, você precisa solicitar a instalação do Vmware tools.

Bom, indo para a parte bacana, esse componente permite que paginas de memória que estão ociosas (aqui vale lembrar das aulas de arquitetura de computadores) sejam alocadas para outra VM. Vamos utilizar a VM 1 e a VM 2 como exemplo, basicamente o que acontece é o seguinte…suponha que a VM 1 possui 12 GB de memória e nesse momento está utilizando apenas 6 GB, por outro lado a VM 2 possui apenas 4GB de memória e está sob pressão, precisando de recursos. O esxi tem a capacidade de identificar esse tipo de situação e solicitar que as páginas de memória sem uso/ociosas da VM 1 sejam “emprestadas” a VM 2 para que a demanda seja atendida sem a necessidade de swapping (falamos mais sobre isso a frente).

Ok, e how the hell isso é possível? Utilizando o vmware tools o ballooning será inflado fazendo com que o S.O entenda que a nada mudou em relação a quantidade de memória que ele possui, enquanto isso ocorre, as páginas ociosas da VM 1 retornam ao esxi que pode realocar esse recurso, em nosso exemplo a VM 2 seria beneficiada. Tudo isso é feito para evitar outros tipos de ações, como o swapping que já falamos e que não é um grande amigo quando se pensa em desempenho. Algo que me surpreende em relação a esse recurso é o fato dele ser o que menos impacta na performance dos hosts, mas é preciso destacar também que esse processo é o que mais leva tempo para solicitar a memória e realoca-la.

Compressão

Esse é o último ponto até irmos para o não bem quisto swapping. Desde o ESXI 4.1 é possível que, caso um host entre em estado crítico a nível, o VMKernel tentará comprimir paginas de memória, mantendo isso tudo em cache antes de realizar swapping.

A compressão de memória ocorre com paginas de 4KB. Se esta pagina for comprimida para 2KB ou menos ela será armazenada no tal cache per-VM. Ok, mas o cache também não é eterno, o que acontece quando o espaço acabar?! Simples, as páginas mais antigas passam a ser substituídas por páginas mais recentes. Quando um dado que está na área de compressão precisa ser acessado o processo o processo de descompressão é realizado e a página entregue a VM. Toda essa brincadeira de comprimir e descomprimir paginas de memória tem um custo obviamente. Ciclos de CPU são utilizados para tais procedimentos, mas, mesmo assim, tudo isso torna-se mais rápido do que depender de I/O de disco.

Um ponto interessante de se lembrar é que o cache ocupa espaço da memória da VM, por padrão 10% da memória total, ou seja, tenha em mente que a compressão ajuda mas estará consumindo recurso da mesma forma.

Nathan, quer aumentar o espaço para cache, consigo?! Sim, alterando a configuração avançada Mem.MemZipMaxPact.
Nathan, eu devo fazer isso?! Se souber o que está fazendo, faça, se tiver 0,5% de dúvida, não altere NADA nas configurações avanças, isso pode impactar seu ambiente de forma drástica.

Swapping

O maldito querido swapping! Esse recurso é comum a sistemas operacionais e ocorre quando existem requisições que estouram a quantidade de memória disponível. Pra quem dormiu na aula de Sistemas Operacionais, esse processo faz com que, ao invés de utilizar a RAM para armazenar e acessar dados e blocos de instruções o S.O passa a usar parte do disco para isso, pois a memória RAM está escassa. Esse tipo de situação deve ser evitada ao máximo, pois sabemos que o acesso a memória RAM é infinitamente mais veloz do que acessar dados em um disco, seja ele mecânico ou SSD.

Agora que clareou a memória, vamos aos fatos. Caso nenhuma das duas opções explicadas anteriormente tiverem efeito teremos duas possíveis situações:

1. Swapping na VM: Você alocou pouca memória para sua VM e as aplicações ou S.O instalados nela estão solicitando mais recursos. A VM realizará swapping para seu disco interno. Assim como já dito anteriormente, não é uma situação desejada, mas, caso isso ocorra apenas no ambiente da VM o problema pode ser menor e de solução mais facilitada.
2. Swapping no Hypervisor: Neste caso todo o seu host esta com recurso escasso e as VMs solicitando mais e mais. O que acontecera aqui sera similar ao já citado anteriormente, mas a nível de hypervisor, ou seja, os discos passarão a ser “utilizados como RAM” o que por consequência afetará diretamente a performance de TODO o seu ambiente virtual

Esse possui algumas variantes e pode ser controlado de algumas formas. Farei um artigo somente sobre swapping pra deixar tudo mais claro.

Obviamente existem formas de contornar algumas situações que falamos aqui, além do uso dos 3 recursos acima. Vejam que esse foi apenas a parte 1 de nosso estudo sobre gerenciamento de memoria no ESXI. Na parte 2 darei detalhes de outros recursos mais avançadosque podem nos ajudar nesse desafio.

Espero que tenha curtido! Grande abraço \,,/