vSphere troubleshooting – Memoria

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 el primer articulo lo pueden encontrar aquí:

http://hispavirt.com/2014/11/27/vsphere-troubleshooting-cpu/

Troubleshooting de Memoria

Existen múltiples mecanismos utilizados en ESXi para la gestión de memoria, no estaremos revisando estos mecanismos ya que nos podría tomar una cantidad de tiempo considerable, si quieren conocer mas les recomiendo las siguientes ligas:

http://hispavirt.com/2010/11/20/vcap-%E2%80%93-seccion-3-%E2%80%93-optimizando-recursos-de-vms/

Una vez que comprendemos como maneja la memoria ESXi debemos de entender algunos conceptos básicos que estaremos utilizando para el troubleshooting de memoria:

(copiado de mi articulo http://hispavirt.com/2011/01/30/vcap-%E2%80%93-seccion-6-%E2%80%93-troubleshooting-de-memoria-y-cpu/)

Vamos a definir algunos conceptos que estaremos tocando a lo largo de este articulo:

  • Memoria física de VM – Memoria ram de servidor ESXi presentada a la VM en cuestión, la VM la gestiona de manera igual que lo haría el gOS en un mundo físico.
  • Memoría fisica de Host (PMEM) – La memoria RAM presente en el host ESXi, generalmente es un valor muy cercano al presentado por el BIOS. Este grupo de métricas esta compuesta por total, vmk, other y free. Donde Total hace referencia a la totalidad de memoria en el sistema (se tiene un poco de variación), other hace referencia a la memoria asignada a VMs y otros servicios y por último free hace referencia a la memoria libre en el host ESXi.
  • SWR/s – Métrica de ESXTOP, en caso de tener este medidor distinto a “0″  nuestro host esta leyendo de swap (.vswp).
  • SWW/s – Métrica de ESXTOP, en caso de tener este medidor distinto a “0″ nuestro host esta escribiendo a swap (.vswp).
  • PSHARE – Compartición de memoria, esto es realizado a través de TPS (generalmente esto es  bastante importante y ofrece reducciones en memoria muy altas en ambientes pre EPT/RVI). Este grupo de indicadores de ESXTOP esta constituido por shared, common y savings.
  • MCTL– Métrica de ESXTOP, en el caso que el valor de este medidor sea distinto a “0″ nuestro host esta reclamando memoria de las VMs utilizando el balloon driver. No hay que confundirnos al pensar que si se esta reclamando memoria con el balloon driver nuestro host esta en problemas, muchas veces debido a las reservaciones que se tienen el host tiende a reclamar memoria aún cuando no se tenga un estado crítico de la misma.
  • ZIP–  Métrica de ESXTOP, en el caso que el valor de este medidor sea distinto a “0″ nuestro host esta comprimiendo memoria.
  • Estado de memoria del sistema – Esto es algo bastante importante de comprender, no se trata de una métrica tal cual sino que es mas que nada la cantidad de memoria restante. Se definen ciertos estados de sistema para definir que mecanismos para la gestión de memoria tendrán precedencia o serán utilizados para poder mitigar la situación. Esto se realiza en base a la memoria restante como ya lo habíamos comentado, teniendo los estados “High, soft, hard y Low”, los cuales hoy en día tienen un valor dependiendo de la cantidad de memoria RAM disponible en el sistema a través de la función de “Sliding scale” que permite tener valores auto ajustables de Mem.MinFreePct indicando la cantidad de memoria que el vmkernel necesita tener libre. 
  • MEM overcommit avg – este indicador nos muestra el porcentaje de overcommitment que tenemos en el sistema en lapsos de 1, 5 y 15 minutos.

Ahora veamos donde encontramos esto dentro de ESXTOP, en la siguiente imagen de mi laboratorio les muestro un host bajo una demanda excesiva de memoria:

Screen Shot 2014-12-07 at 12.48.42 AM

 (Vista de memoria, ejecutar ESXTOP e ingresar la tecla “M”)

  1. Estadísticas de PMEM, en este caso podemos ver que mi servidor tiene 65512MB de Memoria, 1509MB utilizados por el vmkernel, 61272MB por “otros” donde se incluyen las VMs y user worlds (procesos) y por último tiene 2703MB libres.
  2. Estadísticas de PSHARE, en este caso podemos ver que se están “salvando” alrededor de 10GB lo cual no es muy grande, en versiones anteriores y con procesadores no EPT/RVI yo llegue a ver hasta 70GB.
  3. Estadísticas de SWAP, podemos ver que en ese momento se tenían 584MB en swap de host y un objetivo de páginas a ser enviadas a swap de  858MB. Podemos ver (aunque no es muy claro en este ejemplo) que la lectura de swap (r/s) tiene actividad y en teoría la escritura (w/s) también debería de  tener ya que el objetivo todavía no se alcanzaba.
  4. Estadísticas de ZIP, podemos ver que en ese momento que 1393MB fueron comprimidos y debido a esto se tiene una ganancia de 934MB que pueden ser utilizados para otros fines.
  5. Estadísticas de MEMCTL, aquí podemos ver que se han reclamado a través del driver de balloon 6918MB  y se tiene un objetivo de 6924MB. En este caso se tiene un máximo de 37230MB reclamables a través de ballooning (en este punto no estoy 100% seguro de como se determina este valor pero lo investigaré y actualizaré este articulo).
  6. En este caso podemos ver que se esta en un estado de sistema “High State”, algunos se preguntarán el porque se tienen pruebas de que TPS, el driver de balloon y SWAP ocurrieron siendo que tenemos High state donde no debería de haber reclamación de memoria… es fácil, el host ESXi puede estar en un “high state” debido a que anteriormente se tuvo problemas de memoria y los distintos mecanismos para la reclamación regresaron una buena cantidad al host llevándolo así al estado “High”. Un ejemplo podría ser el hecho que se reclamen 1000MB con balloon driver, estos MB son entregados al host pero si se regresaran (por ejemplo que las VMs necesitasen mas memoria) claramente se la cantidad de memoria libre se reduciría y por ende el estado del host debería de cambiar a un Soft, hard o low.
  7. Aquí podemos ver que mi sistema esta entregando 52% de recursos de memoria extra de los cuales tiene.

 

Ahora es el momento de poder aplicar esto, vamos a ver algunos casos prácticos:

  •  Sobre asignación de recursos de Memoria:

La causa es muy simple, entregar mas recursos de los cuales tenemos hablando específicamente de memoria RAM.

Posibles síntomas:

  • MEM overcommit avg alto
  • Valores de Swap distintos a 0
  • Valores de MEMCTL distintos a 0

Posibles soluciones:

  • Reducir la cantidad de VMs en el host
  • Invocar DRS (en el caso que no este configurado de manera automática)
  • Utilizar herramientas como vRealize Operations para determinar recursos que pueden ser decomisados a ciertas VMs.

 

  • Lentitud de VM 

Aunque este caso aplica para TODOS los recursos que pueden ser entregados por un host ESXi (Red/Storage/CPU/RAM) en este caso nos estaremos enfocando a lentitud de VM causada por memoria. Esto puede ser causado por que la VM ha sido dimensionada de manera incorrecta (con menos recursos de memoria) o porque el host esta teniendo problemas en asignarle memoria física.

Posibles síntomas:

  • Lentitud dentro del gOS
  • Swap dentro del gOS
  • Valores de SWAP distintos a 0 en el host ESXi y actividad en escritura y lectura al swap (.vswp) a nivel global del ESXi
  • Valor de ZIP distinto a 0
  • Valores de MEMCTL distintos a 0 (al reclamar memoria con el balloon driver muchas veces se induce a swapping dentro del gOS).
  • Estado de sistema distinto a “High”

Posibles soluciones:

  • Agregar mas memoria a la VM (si se dispone de ella)
  • migrarla a otro host ESXi
  • NO RECOMENDADO PERO FUNCIONARIA DEPENDIENDO DE LA CARGA DEL HOST – Configurar una reservación o dar mas shares a dicha(s) VM(s), claramente esto asumiendo que el dimensionamiento y la cantidad de memoria que la VMs y los servicios/apps que viven dentro de ellas puede ser satisfecha por la cantidad de vRAM configurada y que esto esta causado por una competencia con otras VMs por los recursos.
  • invocar DRS

Existen muchos otros casos que se pueden llegar a presentar debido a la contención de recursos de memoria claramente en este articulo el objetivo no es cubrirlos todos, si tienen un caso que quisieran que analizáramos compártanlo en la sección de comentarios :)

¿Que hay de TPS en los últimos días?

Como pueden saber VMware anuncio que TPS o “Transparent Page Sharing” será deshabilitado por defecto en los siguientes releases de ESXi incluyendo updates a las versiones actuales, esto causado por un hoyo en la seguridad/diseño de como trabaja TPS que fue descubierto por un grupo de investigadores, donde se demostró que se podía obtener la clave AES con la cual se encriptan las páginas de memoria de otra VM ejecutándose en el mismo host, permitiendo así tener acceso a memoria remota de dicha VM e incluso ejecutar código (este tipo de ataque se le conoce como vm escape).

Las condiciones para realizar esto son bastante estrictas y difíciles de cumplir:

  • [Ataque] VM origen y   [Ataque] VM destino deben de estar en el mismo nodo NUMA
  • TPS debe de estar sucediendo entre ambas VMs
  • La persona que realiza el ataque debe de tener acceso a la VM origen donde estará ejecutando aplicaciones y realizando un flush y reload de el cache de memoria
  • Las vms no pueden participar en una operación de vMotion durante el ataque

Como pueden ver esto es bastante difícil de cumplir, aunque existe la posibilidad… Claramente todo comienza con los principios de seguridad básica donde se permite acceso a las VMs y/o infraestructura sin que se deba tenerlo. Debido a esto VMware decidió deshabilitar TPS, lo importante es entender COMO LO DESHABILITA… no se deshabilito de manera total, sino TPS “entre vms” es decir, por defecto no se podrá compartir páginas de memoria entre distintas VMs solo “intra VM” o dentro de la VM. Con esto también se implemento un nuevo mecanismo llamado “salting” que básicamente identifica a las VMs, permitiendo si es que así nosotros lo quisiéramos tener VMs que esten participando en TPS entre VMs.

La manera como trabaja el salting es configurando un parámetro avanzado dentro del host ESXi para definir que estaremos utilizando salting (Mem.ShareForceSalting=1) y después definir un valor del “salt” para cada una de las VMs que queramos que este participando de manera activa en la compartición de memoria a través de una propiedad en el VMX de la máquina virtual (sched.mem.pshare.salt). De esta manera TPS trabajará compartiendo memoria exclusivamente dentro de la misma VM en el caso que no se defina un “salt” para la misma (siguiendo el comportamiento por defecto) mientras que para las VMs donde se defina este “salt” se estará compartiendo memoria entre ellas (entre vms).

Muchos decían que esto tendría un impacto bastante importante, tal vez si dependiendo de algunos factores. Lo mas importante para entender es (como ya lo había comentado previamente en este articulo) que para ambientes donde tengamos procesadores con EPT/RVI (intel/AMD) el impacto será mucho menor, debido a que el host ESXi trata de respaldar todas las páginas de memoria con “large pages” o “paginas grandes” (2MB vs 4KB) lo cual causa que TPS no entre en acción (ya que analizar y encontrar páginas de memoria de 2MB exactamente iguales es difícil/costoso para el sistema) hasta que se tenga un consumo de 96% de RAM donde se comienza a “romper” estas páginas grandes en páginas de 4KB.

Aquí les dejo algo de material de lectura:

http://www.yellow-bricks.com/2014/10/27/tps-disabled-default/

http://blogs.vmware.com/apps/2014/10/disabling-tps-vsphere-impact-critical-applications.html

http://longwhiteclouds.com/2014/10/19/vmware-turns-off-tps-taps-in-vsphere-esxi-and-vcloud-air-to-avoid-rare-vmescape-security-bug/

http://www.vmware.com/files/pdf/large_pg_performance.pdf

http://blogs.vmware.com/vsphere/2012/05/memminfreepct-sliding-scale-function.html

2 comments on “vSphere troubleshooting – Memoria

  1. Gilberto Canales December 9, 2014 2:04 pm

    Primero que nada, muy buen post, gracias por compartir, segundo.. ¿Porque no recomiendas reservar memoria? Así le respaldas RAM física a la VM, y además le garantizas que puede reiniciar en un evento de HA si tienes configurado el admission control “Percentage of Cluster Resources…”. IMHO puede ser un win-win para la VM y mas si es de las críticas del entorno.

    Saludos

  2. amalanco December 11, 2014 3:25 pm

    En realidad la reservación NO garantiza el reinicio de la VM en el caso de un control de admisión configurado con Percentage of Cluster Resources, mas bien es la cantidad de recursos que reservas que tienen que ser igual o mayores a las reservaciones seteadas en las VMs “criticas”(Además que DRS participaría desfragmentando recursos para poder satisfacer las reservaciones y reiniciar las VMs). En el caso de Hosts Tolerates también podrías tener un correcto reinicio si conces bien como esta la distribución de slots :) . En un ambiente de Tier1 se tienen dos opciones, o arquitectar pensando en no tener overcommitment (donde podrías presendir de las reservaciones) o un ambiente donde ademas de overcommtiment puedas tener otras VMs ejecutandose en los mismos hosts, en este último caso si es recomendado configurar reservaciones para poder asegurar que las VMs siempre tengan acceso a páginas físicas. Las reservaciones y otros mecanismos como shares tienden a inducir complejidad al ambiente (tanto en diseño como operativamente).

    Saludos!

Leave a Reply