Comienzo el post con una cuestión. Quien no se ha encontrado en más de una ocasión, en que se solicita crear una nueva máquina virtual y al preguntarle por los recursos que necesita, el solicitante, ni corto, ni perezoso, te dice que le asignes lo máximo. Te dice que cuanto más tenga la máquina mejor!!!! Es un error muy común, siempre hay que analizar los requerimientos que va a necesitar una máquina, porque malas configuraciones de recursos dan lugar a problemas de rendimiento. Y sí, cuando los haya, el principal señalado será el “De Virtualización”.
A continuación vamos a hablar sobre problemas de sobreasignación de memoria a nuestras máquinas virtuales. Hablaremos también de como el ESXi intenta solucionar estos problemas, lo que llamamos “Técnicas de reclamación de memoria”.
- Técnicas de reclamación de memoria
Para que reclama memoria el hipervisor? Pues bien, VMware tiene la capacidad de poder sobreaprovisionar recursos, es decir, aprovisionar más recursos virtuales que los que disponemos físicos. Es lo que llamamos “Overcommitment“. En el caso de la sobreasignación de la memoria virtual, VMware dispone en sus hipervisores de unas herramientas para reclamar la memoria que necesitan las máquinas en caso de no disponer de recursos suficientes. Por lo que hablamos de técnico para la administración de recursos de memoria con el fin de optimizar el rendimiento.
Aclarar, que el hipervisor únicamente puede reclamar la memoria “No reservada”, es decir, la memoria que ha sido reservada no podrá ser reclamada y la máquina virtual tendrá total uso para sí misma de esa memoria reservada.
Ahora vamos a detallar cuales son las técnicas de reclamación de memoria que utilizan los ESXi en caso de darse el caso de “Memory Overcommitment”. Iré describiendo según prioridad de uso y por lo tanto de menor o mayor impacto.
- Transparent Page Sharing (TPS): el hipervisor analiza la actividad de una máquina virtual e identifica las páginas de memoria similares entre otras máquinas virtuales en el host. Si el hipervisor descubre páginas de memorias idénticas o redundantes en diferentes máquinas virtuales, compartirá estas páginas con las máquinas virtuales y establecerá punteros a los bloques de memoria. Tiene una gran utilidad en el caso de que se utilicen para las mismas máquina virtuales el mismo Sistema Operativo, por lo que utilizarán un mayor número de archivos similares.
2. Ballooning: para poder utilizar la técnica de Ballooning, es necesario tener instaladas las VMware Tools, ya que es un controlador que se instala con las VMware Tools (Balloon Drive). Cuando necesita que la máquina virtual libere memoria, “infla” el Balloon diciéndole al “Balloon Driver” que intente consumir más memoria como un proceso en el sistema operativo de la máquina virtual. El Sistema Operativo decide entonces que paginas de memoria puede liberar para asignárselas a este “proceso”.
- Si la máquina virtual tiene mucha memoria libre, esta es entregada al “Balloon Driver”, y el Driver puede decirle al hypervisor que paginas de memoria liberar.
- Si la máquina virtual no tiene memoria libre, el Sistema Operativo elige que paginas de memoria pasaría a la memoria Swap usando su propio archivo de paginación (Windows) o particion Swap (Linux).
Posteriormente el hipervisor puede hacer uso completo de la memoria recolectada con el Balloon Driver, pudiendo esta ser traspasada a otra máquina virtual que requiera más memoria.
3. Compresión: el hipervisor analiza las páginas de memoria de 4KB de tamaño y las comprime a 2 KB. Si la página de memoria no puede ser comprimida, se marca y pasaría al Swap de la máquina virtual (Archivo de Paginación (Windows) o Swap (Linux)). Ahora bien, en el caso de que la máquina virtual necesite de una página comprimida, el hipervisor se encargará de descomprimir la página de memoria y se la entregará a la máquina. Evidentemente, esto impactará y mucho sobre la CPU en el proceso de compresión y descompresión. Cabe mencionar que el hipervisor tiene una caché de compresión que es del 10% de la máquina virtual, por lo que si se llena, empezará a descomprimir las página más antiguas para dar paso a las nuevas página comprimidas.
4. Swapping: esta técnica es utilizada como último recurso y es muy crítico llegar a este punto. El hipervisor envía páginas de memoria al disco de la máquina virtual. A diferencia de lo que ocurre con Ballooning, el hipervisor no tiene en cuenta la administración de memoria del Guest OS de la máquina virtual, sino que envía páginas de memoria aleatorias a disco. Este proceso impacta totalmente en el performance del Host y por tanto de las máquinas que se ejecutan en el. Por un lado, al ser aleatorio el envío de páginas de memoria, moverá páginas de memoria activas, por lo que las máquinas sufrirán. Y en cuanto al Host el consumo de CPU se dispara en este proceso de “Swapeo”.
Como he indicado anteriormente, únicamente hará uso de las técnicas de reclamación de memoria el hipervisor, en caso de tener problemas de uso de memoria. A continuación podemos ver en que casos entraría en uso cada técnica, irán de menor a mayor impacto.
Ante un 94% de uso: el hipervisor empezaría a utilizar TPS, para intentar bajar el uso de memoria.
Ante un 96% de uso: el hipervisor activaría la opción de Ballooning, para intentar bajar el uso de memoria al 94%.
Ante un 98% de uso: el hipervisor intenta evitar el envío de páginas a swap, por lo que activa la compresión de páginas de memoria.
Ante un 99% de uso: el hipervisor se ve obligado a enviar páginas de memoria realizando swapping. Aquí tendríamos un problema crítico de rendimiento. No podemos dejar que llegue a este punto.
- Análisis rendimiento
Como en el caso de la CPU, podemos analizar el rendimiento de la memoria a través de vSphere Client con la pestaña de Performance o bien con esxtop.
La vista más rápida y más simple podemos verla en vSphere Client, seleccionando la máquina virtual y en la pestaña “Resource Allocation” vemos lo siguiente:
Para analizar el rendimiento de la memoria, debemos tener en cuenta los siguientes valores:
Que valores debemos tener en cuenta y posibles causas:
- PSHARE/MB: son las páginas de memoria que se están compartiendo (TPS)
- SWAP/MB : valor de swapping que se estaría realizando. Si es mayor de 0 (We have a problem my friend)
- ZIP/MB : Tamaño de páginas de memoria comprimidas.
- MEMCTL/MB: Si es mayor de cero, indicará el tamaño de memoria que se ha recuperado por Balloon Driver.
- MCTLSZ: Si es mayor de 0, nuestro host tiene problemas de Memory Overcommited y ha activado Ballooning.
- SWR/s: Si es mayor de 0, el host está leyendo desde swap (vswp). Memory Overcommited excesiva.
- SWW/s: Si es mayor de 0, el host está escribiendo a swap (vswp). Memory Overcommited excesiva.
- CACHEUSD: Si es mayor de 0, el host ya ha comprimido memoria. Memory Overcommited.
- ZIP/s: Si es mayor de 0, el host está comprimiendo de manera activa. Memory Overcommited.
- UNZIP/s: Si es mayor de 0, el host está accediendo a memoria ya comprimida. Memory Overcommited previo.
Como método de previsión para evitar tener estos problemas, ante todo, configurar correctamente las máquinas virtuales e intentar analizar los requerimientos. Es bueno tener un buen sistema de monitorización para curarnos en salud.
Espero que os haya gustado y muchas gracias por compartir 🙂