Balloon driver

vSphere troubleshooting – Memoria

rsz_vmware

Que tal gente, el día de hoy estaré continuando con la serie de vSphere troubleshooting, en este caso estaremos hablando sobre Memoria. En el articulo anterior hablamos de algunos pasos para poder comenzar con el proceso de troubleshooting a nivel general por lo que no estaremos hablando sobre eso en esta ocasión de cualquier manera […]

VCAP – Sección 3 – optimizando recursos de VMs

Que tal gente, continuando con los temas de estudio para el examen VDCA410 nos toca hablar sobre el manejo de recursos de vms, que mecanismos existen y como podemos optimizar estos recursos.

Identificar mecanismos que VMware nos ofrece para el manejo de memoria

Aquí más que nada necesitamos enfocarnos en los mecanismos para reclamar memoria y manejar la memoria en momentos de overcommitment en la versión 4.1 de vSphere existen 4 mecanismos:

  • Transparent Page Sharing: cuando varias vms se están ejecutando concurrentemente en un mismo host ESX/ESXi muchas veces en su memoria de ejecución tienen páginas idénticas, ejemplo, si tenemos 2 máquinas windows 2003 ejecutándose en un mismo host es muy posible que un gran porcentaje de sus páginas de memoria sean iguales debido a que se trata del mismo sistema operativo. Esta funcionalidad siempre esta activada, y esta todo el tiempo escaneando las páginas de memoria que tiene  las vms si dichas páginas generan un mismo hash ,resultado del algoritmo utilizado por TPS, estas son guardadas en una tabla utilizada como referencia para nuevas páginas, en el momento que se identifica que otra página genera el mismo hash se escanea dicha página para confirmar que sean exactamente iguales en caso de ser iguales solo se crea un apuntador a dicha página y con esto el hipervisor puede re utilizar la página liberada.  Si la alguna de las vms necesita escribir a la memoria se utiliza un mecanismo llamado Copy on write (CoW) donde se crea una copia privada de dicha memoria compartida y se mapea la vm con su nueva página de memoria para que pueda escribir sin ningún problema. Cabe destacar que este mecanismo solo trabaja con vms que no utilizan large pages (2 MB) en dichas vms el primer mecanismo es el balloon driver puesto que encontrar páginas idénticas de 2 MB es mucho mas difícil y el hash de estas mismas sería un proceso más tardado.

  • Ballooning: este mecanismo para reclamar memoria ram comienza a trabajar en el momento que el host ESX/ESXi ya no tiene la capacidad de reclamar mas memoria utilizando TPS. Este mecanismo trabaja utilizando un driver instalado en el momento de instalación de las vmware tools (vmmemctl driver), este driver se comunica internamente con el hipervisor para saber que cantidad de memoria es la que se necesita reclamar dentro del OS de la vm, una vez que se tiene dicho valor de memoria (target balloon size) este driver comienza a reclamar dicha cantidad de memoria, en el momento que se tiene la memoria necesaria se le notifica al hipervisor el cual reclama dichas páginas de memoria utilizadas por el balloon driver puesto que son páginas que no están siendo utilizadas por el sistema operativo de dicha vm y es seguro reclamarlas.

  • Swap del hipervisor: en el caso que nos encontremos en un punto de consumo memoria demasiado alto a tal grado que los mecanismos previos (TPS y balloon) ya no pueden reclamar más memoria el hipervisor comienza a swapear páginas de memoria de la vm hacia el archivo swap de dicha vm. Aquí es importante entender que no se trata de swapeo dentro del OS de dicha vm (pagefile en windows o swap en linux) sino un swapeo a nivel hipervisor, cada vez que se enciende una vm se crea un archivo .vswp que es igual al tamaño de memoria asignada a dicha vm ,en el caso que exista una reservación de memoria es igual al tamaño de dicha reservación, es aquí donde se swapean páginas de memoria de las vms. El problema que tenemos con este mecanismo es claramente la diferencia en la velocidad de acceso a dicha memoria debido a que se encuentra almacenada en disco por lo tanto nos presenta una latencia mayor.
  • Memory Compression: este mecanismo fue introducido a vSphere en la versión 4.1, este actúa justo antes de que se necesite swapear una página de memoria (solo en páginas de 4kb no large pages) tratando de comprimir las páginas de 4kb que se necesitan swapear si estas pueden ser comprimidas a 2kb o menos serán almacenadas en un cache de memoria de dicha vm (cada vm tiene su propio cache de memoria 10%  es valor default de este cache), en el caso que no puedan ser comprimidas estas son swapeadas al disco. Lo que obtenemos aquí es un acceso mucho mas rápido a las páginas almacenadas dentro del “compression cache” debido a que el proceso de descompresión de dichas páginas es mucho más veloz que el acceso a disco. Aquí me gustaría aclarar que el cache de compresión esta dentro de la misma memoria de las vms, es decir nuestros hosts ESX/ESXi no necesitan asignar memoria ram extra para dicho cache. Para modificar este cache lo podemos realizar desde advanced settings , buscamos “Mem.MemZipMaxPct”:

 

Identificar mecanismos que VMware nos ofrece para el balanceo de CPU

Existen 2 tecnologías que VMware utiliza para realizar el balanceo de cargas entre los procesadores que tienen nuestros hosts:

  • HyperThreading: esta tecnología desarrollada por intel nos permite mandar dos hilos de instrucciones a un mismo core de un cpu físico, con esto este core se comporta como si fuera en realidad 2 cores lógicos, el problema aquí es que estos 2 cores lógicos estarán compartiendo los mismos recursos del core físico (ciclos, cache,etc) por lo que por ninguna razón se debe de pensar que habilitando HT tenemos el doble de capacidad de cpu, sino solo un consumo mas eficiente de los recursos. No todas las aplicaciones se verán beneficiadas por hyperthreading les recomiendo verificar con el proveedor de cada aplicación y también realizar tests por su lado. Esta tecnología tiene que estar habilitada en el BIOS para poder ser utilizada. Cabe destacar que el hipervisor por default tratará de distribuir todos los vCPUs entre distintos cores físicos. Nosotros podemos especificar como queremos que se distribuyan los vCPUs de una vm entre los cores de nuestro host, para esto editamos nuestra vm y vamos a la pestaña de Resources>Advanced CPU:

  1. Any:los vCPUs de nuestra vm pueden compartir un core físico del host con cualquier otro vCPU de distintas vms incluso otros vCPUs propios.
  2. None: Aquí el o los vCPUs de nuestra vm no compartirán un core físico con ningún otro vCPU (incluyendo sus propios vCPUs), y el core “lógico” o creado por HT no es utilizado.
  3. Internal: En esta opción solo el o los vCPUs que pertenezcan a esta vm podrán estar utilizando un mismo core.

Aquí me gustaría platicarles de un parámetro avanzado que involucra la colocación de los vCPUs entre los nodos NUMA y HT.  Este valor es “Numa.PreferHT” por default viene deshabilitado, con esto los vCPUs podrán ser asignados a distintos nodos numa. Si nosotros tenemos una aplicación en la cual lo más importante es el performance de nuestra memoria RAM, sería bueno realizar pruebas modificando este valor a 1 para habilitarlo, así el hipervisor tratará de colocar todos los vCPUs de una vm en un mismo nodo numa, por lo cual el acceso a memoria será local y no remoto mejorando así el acceso a memoria ram. NO les recomiendo hacer esto en un entorno productivo, si tienen una aplicación que es muy dependiente de memoria podrían realizar pruebas habilitando este parámetro y comparándolo con el parámetro deshabilitado. Cabe destacar que este parámetro si es modificado aplica al host ESX/ESXi por completo, por lo cual podríamos estar teniendo problemas con otras aplicaciones que se estén ejecutando en otra vms dentro del mismo host. Este parámetro aplicaría en el caso de tener un cluster ejecutando la misma aplicación en distintas vms por lo tanto todas las vms ser verían beneficiadas. Les recomiendo leer el siguiente articulo:

http://frankdenneman.nl/2010/10/numa-hyperthreading-and-numa-preferht/

 

Identificar pre-requisitos para el uso de Hot-add

Hot-add nos permite el agregar memoria ram,vcpus,vnics y discos duros en caliente a nuestras vms, existen varios puntos importantes:

  • Se soporta memory hot add desde vSphere, no se soporte hot remove.
  • Se soporta cpu hot plug en ciertos sistemas windows, el problema principal es que generalmente se requiere un reinicio para que las aplicaciones  aprovechen correctamente los vcpus.
  • No se soporta cpu hot remove en ningún sistema windows.
  • No se soporta cpu hot plug en ningún sistema Linux.
  • Hot add no es compatible con Fault Tolerance.

Requerimientos:

  • Hardware virtual versión 7.
  • Licenciamiento advanced, enterprise o enterprise plus.
  • en el caso de no haberse habilitado hot add / hot plug  requerimos apagar dicha vm para poder habilitarlo.

¿Cómo habilito hot add y hot plug?

Ingresamos con nuestro vsphere client y seleccionamos la vm a la cual necesitamos habilitar estas funciones hacemos click derecho y “edit settings” vamos a la pestaña de options>Memory/CPU hotplug y habilitamos lo deseado:

¿Qué  sistemas son compatibles con hot add y hot plug?

Aquí les dejo una tabla creada por Jason Boche, para leer el articulo completo hagan click en este link http://www.boche.net/blog/index.php/2009/05/10/vsphere-memory-hot-add-cpu-hot-plug/

© 2010 boche.net

En el caso de hot add para sistemas linux estos deberán tener un kernel 2.6.14 en adelante, no existe registros de algun sistema linux compatible con cpu hot plug.

Configuración de Large pages

Configurar large pages para windows:

Paso 1-. Hacemos click en Start > Control Panel > Administrative Tools > Local Security Policy

Paso 2-. Hacemos click en local policies y después en User Rights Assignment, buscamos la política “Lock pages in memory” click derecho y click en properties.  Aquí solo asignamos los grupos de usuario y/o usuarios que estarán ejecutando aplicaciones y reiniciamos la vm.

Configurar large pages para linux

Paso 1-. Pre-alojamos la cantidad de MB necesitados (recordar que cada página es de 2 MB):

echo (cantidad en mb) > /proc/sys/vm/nr_hugepages

Paso 2-. Verificamos la cantidad de large pages mostradas por el sistema;

cat /proc/sys/vm/nr_hugepages

 

Casos de uso para CPU affinity

  • Para asegurarnos que no estaremos corriendo aplicaciones muy demandantes el el primer core (0) donde se ejecuta el service console.
  • No podemos utilizar CPU affinity en un cluster de HA/DRS.