¿vNUMA?

Que tal gente, hace BASTANTE tiempo que no tenía oportunidad de escribir debido al trabajo y compromisos personales, pero estoy de vuelta y esta vez les voy a platicar de algo bastante interesante que se introdujo con vSphere 5.0 y ofrece una plataforma aun más escalable y capaz de virtualizar todo tipo de aplicaciones. Vamos a platicar un poco sobre vNUMA

Comencemos por entender lo básico:

¿Que es NUMA?

(Tomando un extracto de mi articulo “VCAP – Sección 3 – optimización de performance para vSphere”)

NUMA (non uniform memory access) un tipo de arquitectura en cuanto a la comunicación entre procesadores y memoria se refiere, a diferencia de arquitecturas anteriores cada procesador o grupo de procesadores  tienes  su propia memoria ram, a este grupo de memoria y procesadores se le llama “nodo numa”:

NODO NUMA

Cada nodo numa tiene un bus a través de cual se lleva a cabo la comunicación entre cpu y memoria a esto se le llama memoria local, pero también se puede acceder memoria de otros nodos que se le conoce como “foreign” o memoria remota claro que bajo un costo en cuanto al performance.

El algoritmo de numa en VMware se encarga de balancear las vms entre los nodos dependiendo de la carga que tiene el sistema, el nodo al que se asigna se le llama “home node” y este mismo algoritmo trata de asignar memoria en su mismo nodo numa para que esta memoria sea local.

¿Que es vNUMA?

En vSphere 5.0 se presenta la topología NUMA del sistema físico a las vms, permitiéndole a los sistemas operativos guest y las aplicaciones que son ejecutadas dentro de estas VMs el poder tomar decisiones y optimizaciones “numa-aware” y poder colocar los distintos threads en donde se podría entregar un mejor rendimiento.

vNUMA esta activado por defecto en todas aquellas VMs con 8 vCPUS en adelante (se puede modificar a través de la opción avanzada ” numa.vcpu.min “), en versiones anteriores de vSphere o VI las VMs creían que estaban siendo ejecutadas en un sistema UMA.

Con el aumento en la capacidad de vSphere 5.0 en cuanto a vCPUs y Memoria RAM que puede tener las VMs también aumenta la posibilidad que estas “Monster VMs” deban de ser servidas por varios nodos numa del sistema físico es por eso que poderle presentar al sistema operativo guest la topología es esencial para que el rendimiento también pueda escalar acorde.

En las siguientes imágenes (Extracto de la sesión VSP2884 del VMworld 2011) podemos ver con mayor claridad esto:

Sin vNUMA

Esta imagen nos muestra como las VMs trabajan sin vNUMA. Podemo ver que en la vista del sistema operativo guest (VM) se cree que se está trabajando en un sistema UMA, en este caso teniendo 4 vCPUs (cuadros rojos) los cuales al tener que ser procesados por el vmkernel son enviados a distintos nodos NUMA teniendo una localidad de memoria RAM mucho menor, 25%.

Con vNUMA

En este caso podemos ver que nuevamente tenemos el sistema operativo guest con 4 vCPUs, y se le presenta la topología NUMA del sistema físico, permitiéndole así al sistema operativo guest tomar decisiones “numa-aware” y colocar los distintos threads en un mismo nodo obteniendo así una localidad de memoria del 100%.

Existe un whitepaper excelente que les invito a leer sobre el rendimiento de aplicaciones HPC virtualizadas utilizando vNUMA y como se puede obtener rendimiento muy cercano al nativo, ¿Estaremos contemplando el comienzo de HPC sobre VMware?:

http://labs.vmware.com/publications/performance-evaluation-of-hpc-benchmarks-on-vmwares-esxi-server

Leave a Reply