VMware vSphere 4.1: Soporte NUMA

Hola que tal,

En este articulo hablaremos un poco acerca de lo que es el soporte NUMA (non-uniform memory access) en vSphere 4.1. En arquitecturas de servidores que soporten NUMA, vSphere 4.1 soporta la optimización de acceso a memoria para procesadores Intel Nehalem y AMD Opteron.

Cuando logramos entender como se realiza la programacion NUMA en vSphere, y como funciona el algoritmo NUMA de VMware, es posible utilizar este conocimiento para optimizar la performance de las maquinas virtuales.

Que es NUMA?

Los sistemas NUMA son plataformas avanzadas de servidores con más de un bus de sistema, que permite un mejor aprovechamiento de un gran numero de procesadores en un unico servidor.

Antes de existir los nodos NUMA, una CPU de gran capacidad necesitaba ser provista de un gran ancho de banda de memoria, para poder usar su poder de procesamiento de forma efectiva. Esto era aplicable tanto en equipos con un solo procesador, como en equipos con multiples procesadores. De hecho en sistemas con múltiples procesadores este problema tenia un impacto potencialmente mayor, ya que muchos procesadores debían competir por el ancho de banda en el mismo bus de sistema.

NUMA apareció como un enfoque alternativo que conecta varios nodos pequeños, utilizando conexiones de alta performance. Cada nodo contiene procesadores y memoria (formando un nodo NUMA), como un pequeño sistema multiprocesador (SMP). Adicionalmente, un controlador avanzado de memoria permite a un nodo usar memoria de todos los otros nodos, creando una unica imagen de sistema.

Cuando un procesador accede a memoria que no se encuentra en su mismo nodo (memoria remota), la data debe ser transferida sobre la conexión NUMA, lo cual es más lento que acceder a la memoria del mismo nodo (memoria local), ya que las instrucciones tienen que atravezar el link de interconexion, lo cual introduce un salto adicional en la conexion, introduciendo una mayor latencia en la comunicacion. El tiempo de acceso a la memoria no es uniforme y depende de la ubicación de la memoria, y del nodo desde el cual se accede.

Como funciona NUMA en ESX/ESXi

vSphere utiliza un programador NUMA sofisticado para balancear dinamicamente la carga del procesador y la asignacion de memoria:

• Cada MV administrada por el programador NUMA es asignada a un "Nodo Home". El Nodo Home es uno de los nodos NUMA, conteniendo procesadores y memoria local.
• Cuando la memoria es asignada a una MV, el host ESX/ESXi preferentemente la asigna dentro del "Nodo Home".
• El programador NUMA puede cambiar dinamicamente el "Nodo Home" de una VM para responder a cambios en la carga del sistema. El programador podria migrar una MV a un nuevo "Nodo Home" para reducir la carga de un procesador que no esté balanceado. Adicionalmente, el programador muede migrar dinamicamente la memoria de la MV a su nuevo "Nodo Home" para proveer de memoria local.

Algunas MV no son administradas por el programador NUMA, por ejemplo cuando se configura manualmente la afinidad de CPU en una MV. Las MV que no son gestionadas por el programador NUMA, aun puedes ejecutarse correctamente, sin embargo no se benefician de la optimizacion NUMA.
La optimizacion NUMA funciona sin problemas, sin importar el tipo de sistema operativo que utilice la MV. De hecho, vSphere provee de soporte NUMA incluso para MV que no soporten hardware NUMA, como Windows NT 4.0. Esto permite aprovechar las funcionalidades del nuevo hardware, incluso con sistemas operativos legacy.

Una MV que tiene mas vCPU que el numero de cores fisicos disponibles en un unico nodo NUMA, tambien puede ser gestionada automaticamente. El programador NUMA acomoda dicha MV utilizando nodos NUMA expandidos. La MV es dividida en multiples clientes NUMA, cada uno de los cuales es asignado a un nodo NUMA y administrados por el programador NUMA en forma normal.

Esto puede mejorar la performance de ciertas MV con cargas de trabajo intensivas en el uso de memoria, manteniendo la asignación de memoria local en lo posible. En vez de asignar paginas de memoria aleatoreas, la memoria es asignada desde los nodos NUMA en que la MV se está ejecutando.

Asignación Inicial de Nodo Home

Cuando una MV es encendida, el host le asigna un Nodo Home. Una MV corre solo sobre procesadores dentro de su Nodo Home, y la memoria asignada tambien viene de dicho Nodo Home.

Adicionalmente, y en caso de que la MV utilice más vCPU que los cores existentes en un nodo NUMA, el programador NUMA determina el numero de clientes NUMA que necesitan ser creados para que cada uno de estos resida dentro de un nodo NUMA.

Las MV nuevas son inicialmente asignadas a un Nodo Home de una forma similar a Round Robin, donde la primera MV va al primer nodo, la segunda MV va al segundo nodo, etc. Esto asegura que la capacidad de procesamiento es siempre utilizada en todos los nodos del sistema.

De todas maneras, la asignacion inicial no es suficiente para garantizar una buena performance y un buen balanceo de carga en el tiempo. Por ejemplo, el uso de recursos de una MV en un nodo, con el tiempo puede aumentar llegando ser muy superior al uso de recursos de las MV en otro nodo NUMA. Esto no es balanceado con la asignacion inicial del Nodo Home.

Balanceo de Carga Dinamico

ESX/ESXi combina la asignacion inicial del Nodo Home con un algoritmo de rebalanceo dinamico. Periodicamente (por defecto cada dos segundos), el sistema examina las cargas de los distintos nodos NUMA y determina si debiera rebalancear la carga moviendo una MV de un nodo a otro. Este calculo siempre toma en cuenta la configuracion de recursos de una MV y Resource Pools para mejorar la performance respetando los recursos asignados.

El algoritmo selecciona una MV apropiada y cambia su Nodo Home, al nodo menos utilizado. Adicionalmente, el algoritmo mueve la memoria asignada a la MV al nodo de destino. De aqui en adelante, la MV asigna memoria de su nuevo Nodo Home y se ejecuta solo en procesadores dentro de su nuevo Nodo home.

El rebalanceo es una solucion efectiva para asegurarse de que todos los nodos estan siendo utilizados de manera equitativa y eficiente.

Adicionalmente, el algoritmo de migracion de memoria tambien se asegura que el host ESX/ESXi no mueva memoria que no sea necesaria si una MV es movida a un nuevo nodo solo por un periodo corto de tiempo.

Con la asignación inicial, el balanceo dinamico, y la migración inteligente de memoria trabajando en conjunto, es posible asegurar una buena performance en sistemas NUMA, incluso cuando existen cambios en la carga de trabajo. Cuando se produce un cambio de carga de trabajo mayor, como cuando nuevas MV son encendidas, el sistema se toma un tiempo para reajustar la carga, migrando MV y memoria a nuevos nodos. Despues de algunos segundos o minutos, el sistema completa el rebalanceo.

Transparente Page Sharing optimizado para NUMA.

Muchas cargas de trabajo de ESX/ESXi presentan oportunidades para compartir memoria entre MV. Por ejemplo, si varias MV están ejecutando una instancia del mismo sistema operativo, tienen las mismas aplicaciones o componentes cargados, o contienen datos en comun. En tales casos vSphere utiliza una tecnica de TPS propietaria, que elimina las copias redundantes de paginas de memoria.

Con la memoria compartida, una MV frecuentemente utiliza menos memoria de la que utilizaría cuando se ejecuta en un equipo fisico. Por lo anterior, vSphere puede soportar en forma eficiente altos niveles de sobre-aprovisionamiento (overcommintment).

TPS para ESX/ESXi tambien ha sido optimizado para su uso en sistemas NUMA. En sistemas NUMA, las paginas son compartidas por nodo NUMA, por lo que cada nodo tiene sus propias copias locales de paginas compartidas.

Paginas compartidas entre nodos NUMA

La opcion VMkernel.Boot.sharePerNode controla si las paginas de memoria pueden ser compartidas solo dentro de un unico nodo NUMA, o a traves de multiples nodos NUMA.

Por defecto, esta opcion está activada, por lo que las paginas identicas son solo compartidas dentro del mismo nodo NUMA. Esto mejora la asignacion de memoria local, debido a que todas las MV que utilizan paginas compartidas utilizan solo memoria local.

Si se desactiva esta opcion, las paginas identicas pueden ser compartidas entre diferentes nodos NUMA. Esto aumenta la cantidad de paginas compartidas, lo cual reduce el consumo de memoria global, pero no se beneficia de forma eficiente del uso de memoria local. Esta opción puede ser de utilidad en ambientes con limitaciones de memoria.

NUMA y Hyper-Threading

El programador de CPU en un sistema NUMA ignora Hyper-Threading, contando solamente el numero de cores disponibles por nodo NUMA. En una CPU Nehalem Quadcore con HT habilitado, se pueden contar 8 Threads y 4 Cores, sin embargo el programador NUMA contará solamente 4 cores.

Espero que les sea de utilidad.  Cualquier duda me pueden realizar todas las consultas que estimen.

Posted in: Best Practices,ESX-ESXi,Formacion,NUMA,VMware,vSphere