Nota técnica: Gestión y sobresuscripción de memoria

Mucho se ha hablado y leído estos días sobre la conveniencia o no de la ventaja de la tecnología de Memory Overcommit usada por VMware. Para los no iniciados, VMware ESX utiliza un conjunto de tecnologías para "ahorrar" memoría en los host, permitiendo que la suma de la memoria asignada a las VM supere la del host que las alberga. A continuación, una pequeña descripción de estas tecnologías:

Transparent Page sharing.

Mediante esta tecnología, ESX identifica págins de memoria con igual contenido entre todas las máquinas virtuales ejecutándose, almacenando una sola copia de la misma. De esta manera, si tenemos varias máquinas virtuales similares ejecutándose (igual sistema operativo y/o funciones similares), ESX permite, dependiendo del entorno ahorros de memoria considerables. ESX identifica las páginas mediante un hash que es usado como clave de búsqueda. Si la búsqueda es exitosa, se procede a una comparación del contenido de la página.
Este proceso es completamente transparente al sistema operativo, por lo que no requiere modificación en el mismo, y con un overhead de proceso mínumo. El proceso no es exhaustivo, ya que ESX escanea las páginas de memoria de las máquinas virtuales de manera pseudoaleatoria. ESX siempre intenta compartir páginas antes de aplicar otras tecnologías de Memory Overcommit.


Ballooning.

Mediante el uso de un pseudodriver, el conocido vmmemctl, ESX, en colaboración con el propio sistema operativo de la máquina virtual, reclama páginas cosideradas de menos valor por el propio sistema opeativo. Básicamente, para el sistema operativo, el vmmemctl es un programa que reclama más o menos memoria durante su ejecución. La memoria reclamada es puesta a disposiión del sisema operativo. El driver utiliza tecnología propietaria que suministra un rendimiento predecible y equivalente a las propias de los sisteas operativos de las VM. Esta técnica incrementa o decrementa la presión derivada de la disponibilidad de la memoria, permitiendo a los sistemas operativos de las máquinas virtuales administrar la misma mediante sus propias técnicas de gestión de memoria. Cuando la cantidad de memoria es baja, el sistema perativo de la máquina virtual decide dué páginas de memoria reclamar y, si es necesario, las envía a su propio archivo de swap en su propio disco virtual.


Swapping.

Si el ballooning no es posible (Proceso de carga del sistema operativo de la máquina virtual, o el driver no está instalado), ESX usa el método tradicional de swapping a disco de la memoria de la máquina virtual. Este método es el más costoso desde el punto de vista de rendimiento y siempre es usado en última instancia. El método de ballooning puede utilizar el swap como "salida" para las páginas reclamadas, o cuando el driver vmmemctl no es capaz de reclamar memoria a la velocidad requerida por la operación del sistema. En determinados entornos de carga, puede darse el fenómeno de doble swapping, esto es, que tanto ESX como la máquina virtual estén enviando páginas a memoria.

El uso de cualquiera de estas técnicas viene definido y limitado por los límites especificados para una máquina virtual. El modo de establecimiento de estos límites definirá si se aplican o no las técnicas de overcommitting. Existen dos métodos para especificar estos límites:

Reservation.

Mediante el método de reservation o reservas, especificamos cuál es el mínimo y el máximo de memoria física que ESX asignará a una máquina virtual. ASí, por ejemplo, si a una máquina virtual de 4Gb de memoria le especificamos 2Gb de limite inferior y 3Gb de superior, ESX nunca asignará menos de 2Gb de memoria RAM del host a esta máquina, pero tampoco asignará más de 3, dejando el giga restante en manos del ballooning o swapping.

Shares.

Esta técnica se basa en la prioridad relativa que asignemos a una máquina virtual. Si una máquina virtual tiene el doble de shares asignados que otra, esta podrá disponer del doble de los recurso disponibles que la otra. Por poner un ejemplo, imaginad una tarta dividida en n porciones. Si uno de los comensales tiene derecho al doble que otro, ste siempre tendrá dos veces más pedazos de tarta que el otro. El número exacto de pedazos de tarta de los que disponga, dependerá del tamaño y el número de porciones de la tarta.

Memory Tax

Esta técnica se basa en penalizar la memoria inactiva frente a activa. La memoria inactiva cuenta más que la activa a la hora de asignar shares. El ratio por defecto es el 75%, es decir, una página inactiva "cuesta" tanto como cuatro páginas activas. Esta técnica evita que las máquinas virtuales (o sus aplicativos) acumulen memoria inactiva.

Las dos técnicas primeramente nombradas son, estrictamente hablando, ténicas de overcommit de memoria, y son en la actualidad, terreno de batalla en la blogosfera entre partidarios de VMware (que incluye estas técnicas) y sus competidores (que no las incuyen).

Ahora viene la pregunta..... ¿Es el overcommiting de memoria para mí?. La respuesta no es simple: Depende.

Depende de nuestro entorno de virtualización. Si tenemos unas pocas máquinas virtuales y no hay previsión de crecimiento, el overcommiting no es para nosotros. Sin embargo, si nuestra instalación tiene o va a tener mútiples host on ratios de virtualización altos y un crecimiento no predecible, donde mezclamos entornos de producción y desarrollo, el overcommit quizá nos salve la vida alguna que otra vez, en especial cuando alguien nos pide un par de entornos de desarrollo para ayer. Todos sabemos que los tiempos de provisionamiento de memoria (periodo desde que a nosotros se nos ocurre necesitarla hasta que llega el pedido) no son precisamente inmediatos. O quizá nos dé algo de grima invertir en memoria para algún host "de mediana edad" que usamos para entornos de desarrollo.

En entornos de Desktop Virtual sí he observado que las técnicas de overcommit dan un fruto bastante apetecible. En mis entorno de pruebas con simulación de carga, he llegado a observar ratios 2:1 sin degradación sensible del rendimiento. En estos entornos de rendimiento variable, donde las cargas individuales de las máquinas virtuales no son lineales y las máquinas virtuales son bastante similares en lo que a memoria se refiere, la versatilidad y escalabilidad, junto con el ahorro de costes (tema especialmente sensible en lo que a virtual desktop se refiere), si aconsejan el disponer de este tipo de tecnologías.

No estoy totalmente de acuerdo con los defensores de el VMware Memory Overcommit, que usan el argumento del "cost per vm" como buque insignia de la defensa del overcommit... pero sí que pienso que es mejor tenerlo disponible que no tenerlo. Tenerlo o no puede ser la diferencia entre tener que comprar memoria y parar un host (o varios) en producción para poder meter más máquinas virtuales o no tener que hacerlo.

Un saludo.