NUMA y vNUMA en VMware vSphere

Cuando definimos los recursos que tendrá una máquina virtual (VM) hay una serie de reglas que tenemos que tener en cuenta, si queremos asegurarnos un funcionamiento óptimo y evitar problemas de rendimiento.

Parece que no tenemos problemas para entender cómo las VMs consumen los recursos de disco y memoria de nuestra infraestructura virtual, ya que es una relación más o menos directa (nº GB virtuales -> nº GB físicos) con añadidos para el ahorro de recursos como el Thin Provisioning o la asignación dinámica de RAM. Algo más complejo se muestra la asignación de recuros de CPU, ya que hay que conocer el funcionamiento de NUMA para no llevarnos sorpresas.

¿Que es NUMA?

NUMA (Non-Uniform Memory Acces). NUMA nació para optimizar rendimiento y permitir escalar de una forma más óptima los sitemas de cómputo. En una arquitectura NUMA, cada CPU física (socket) tiene acceso mediante un bus directo a su memoria local, y esto es a lo que llamamos un NUMA Node.

NUMA Node = Local MEM + CPU CORES

En la imagen siguiente, se puede ver un sistema de dos socket CPUs de 6 cores cada una. Además, si tenemos Hyperthreading habilitado, el número de logical cores disponibles se duplica. Quedarían dos NUMA nodes de 12 logical cores cada uno, para un total de 24 logical CPUs en el sistema.

De esta forma, se permite un acceso muy rápido del procesador a la memoria local, pero pueden aparecer latencias en el acceso a la memoria remota, por lo que hay que tener en cuenta nuestra arquitectura de NUMA cuando dimensionamos nuestras VMs.

vNUMA en VMware vSphere

A partir de vSphere 5.0 y las VMs versión 8, la topología virtual de NUMA puede ser expuesta al SO.
vNUMA se activa automáticamente cuando:

• se configura una VM de más de 8 vCPUs.
• Se configura una VM con más vCPU que cores físicos tiene un NUMA Node.

Cuando esto ocurre, la VM queda fijada por ESXi NUMA Scheluder a los nodos NUMA físicos del host. Hay que tener en cuenta que para la alineación NUMA no se computa el Hyperthreading, a no ser que configuremos expresamente el parámetro avanzado numa.PreferHT=1 (https://kb.vmware.com/s/article/2003582).

Si el número de vCPUs es igual o inferior al número de cores de un Nodo NUMA, entonces la VM quedará fijada a un único Nodo NUMA. Mientras la cantidad de memoria configurada en la VM no supere la memoria que tiene el Nodo NUMA, estaremos en el caso óptimo, ya que todas las operaciones se ejecutarán en local dentro del Nodo NUMA. Ver imagen.

Si el número de vCPUs es mayor al número de cores de un Nodo NUMA, entonces la VM quedará fijada al menos a 2 Nodos NUMA. Se cumplirán con los requerimientos de recursos de la VM, pero se puede experimentar una penalización en el rendimiento cuando las operaciones tengan que saltar de un Nodo NUMA a otro (Spanning). Ver imagen.

Alineción NUMA

Conclusión, para la creación de nuestras VMs, tendremos que intentar que el número de vCores per vSocket no sea mayor al número de cores de un nodo NUMA (sin contar Hyperthreading).

Para comprobar si tenemos una VM alineada, tenemos dos opciones; esxtop y esxcli. Desde la shell de un host ESXi, ejecutamos esxtop. Luego pulsamos “m” para habilitar las estadísticas de memoria,  pulsamos “f” para elegir los campos mostrados y pulsamos “g” para visualizar NUMA STATS. Podemos observar la cantidad de memoria asignada a cada Nodo NUMA y, si vNUMA está activado, podemos ver en el campo NHN si la VM está asociada a más de un Nodo NUMA. Cada Nodo NUMA tiene un valor (0,1,2,3,…).

Desde esxcli podemos ver de una forma sencilla la configuración NUMA del host ESXi, con los siguientes comandos, para ver el número de Nodos NUMA y el número de logical CPUs asociados a cada Nodo NUMA:

Espero no haberme enrollado mucho.

Gracias por compartir 😉