vSphere troubleshooting – CPU

Que tal gente, el día de hoy después de muchos meses fuera de mi blog por diversos temas he regresado. En este caso estaré hablando de como poder realizar troubleshooting a nivel de CPU en un ambiente de vSphere, conociendo las métricas y problemas comunes que nos encontramos en este tipo de recurso.

Vamos a revisar una metodología sencilla a seguir para realizar troubleshooting:

  • ¿Cuales son los síntomas? – ¿Es un síntoma subjetivo o cuantificable? Por ejemplo, el usuario se queja de lentitud en el sistema (subjetivo) vs la cantidad de páginas en SWAP es de X%.
  • ¿Cuando fue la última vez que funciono/trabajo como se esperaba? – Simple, ¿Cuando comenzaron los síntomas? (o al menos un aprox.)
  • ¿Que ha cambiado desde la última vez que el sistema funciono como se esperaba? – Esto muchas veces es difícil de saber, en muchos ambientes no se lleva un control de cambios que nos pueda dar visibilidad de esto.

Una vez que tenemos una idea mas clara debemos de ir localizando la causa raíz, claramente esto es un trabajo que en ambientes de virtualización se vuelve mas complejo ya que tenemos muchas variables y muchísimos elementos que considerar, ejemplos para ir localizando o al menos reduciendo el área de búsqueda serían:

  • Tiempos específicos
  • ¿Sucede solo en una VM?, ¿un conjunto de VMs?
  • ¿Se presenta en un solo cluster?
  • ¿Un host?
  • ¿Un datastore?

Claramente hoy en día tenemos muchas herramientas pensadas para ambientes virtuales que nos permiten tener visibilidad de los problemas y comportamientos específicos que tienen nuestras infraestructuras, permiten correlacionar los distintos eventos con el estado actual e incluso ayudarnos a determinar la causa raíz, un ejemplo claro es vRealize Operations (el nuevo “nombre” de vC Ops). Pero aquí les estaré explicando como entender estos problemas sin necesidad de esas herramientas los cuales les dará muchas mas armas y conocimiento para poder comprender lo que ese tipo de herramientas presentan.

Troubleshooting de CPU

Comencemos por definir algunos conceptos básicos que estaremos utilizando a lo largo de esta sección:

  • vCPU – Virtual CPU, CPU de la VM se trata de una abstracción lógica
  • pCPU – Physical CPU, Cores físicos de un CPU en el host ESXi
  • VMM – Virtual Machine Monitor, esta capa o proceso que es ejecutado cada vez que una VM es encendida le ofrece el hardware x86 virtualizado a la VM (gestión de Memoria, scheduling de CPU, etc), en el caso de vSphere se tiene un VMM por VM (world). También se encarga claramente de interceptar peticiones que no pueden llegar directamente al HW y debe de ser procesado por el hipervisor. (si quieren saber mas del VMM en la sección de links les dejo información, claramente es mucho mas de lo que he descrito).
  • %RDY (Ready) – Métrica de ESXTOP, un vCPU tiene trabajo que hacer y no puede debido a que este no ha sido asignado a un pCPU para su ejecución en HW
  • %CSTP (CoStop) – Métrica de ESXTOP, un vCPU tiene trabajo que hacer y no puede debido a que no esta asignado a un pCPU, la diferencia en este caso con respecto a %RDY es que no esta siendo asignado debido a la ejecución de otros vCPUs con menos trabajo. Esto generalmente es causado por una sobre asignación de vCPUs vs pCPUs, teniendo vCPUs que solo están quitando tiempo de ejecución a otros vCPUs.
  • %WAIT (WAIT) – Métrica de ESXTOP,un vCPU tiene trabajo que hacer pero esta esperando a un recurso provisto por le hipervisor, como pueden ser Red y almacenamiento (I/O). Esta métrica incluye %IDLE o el tiempo que la VM esta “ociosa”.
  • %RUN (RUN) – Métrica de ESXTOP, tiempo que la VM ha sido ejecutada.

Ahora vamos a ver como podemos obtener estas métricas de ESXTOP:

  1. Habilitar SSH en nuestro Host ESXi
  2. Establecer una sesión a través de un cliente como PuTTY
  3. Dentro de la sesión ingresar el comando:

    ESXTOP

  4. Una vez dentro de ESXTOP cambiaremos la vista a CPU con la tecla “c”, para después cambiar la vista específica de VM con la letra “V” (mayúscula), lo cual nos dará la visión de dichas métricas:

Screen Shot 2014-11-26 at 5.33.45 PM

 

Ahora es momento de entender como se relacionan estas métricas con casos comunes de troubleshooting:

  •  Sobre asignación de recursos físicos de CPU:

En este caso la causa es muy simple, asignar mas recursos de los disponibles , tener VMs altamente activas consumiendo los recursos o incluso la sobre asignación de vCPUs vs pCPU/pCores. Para poder determinar si estamos en un caso de contención de recursos de físicos de CPU debemos de verificar si se cumplen síntomas como:

  • Si se tiene un valor alto de %RDY y %USED
  • Si la latencia en disco es baja y aún así se tienen consumos altos en CPU
  • Si se tiene un valor alto de %CSTP

En la vista de CPU de ESXTOP podemos notar todo esto:

Screen Shot 2014-11-27 at 12.02.49 AM

 

  1.  Cantidad de VMs en ejecución y vCPUs asignados
  2. Carga en los CPUs en los últimos 5, 10 y 15 minutos, si se tiene un valor igual a 1 equivale al uso del 100% (se puede tener valores mayores indicando que se necesita x cantidad extra de los recursos disponibles)
  3. pCPU %USED muestra el uso de CPU sin ser parado desde la última lectura
  4. pCPU %UTIL muestra el uso efectivo (procesamiento real) del CPU desde la última lectura, en el caso que no se tenga Hyperthreading o tecnologías para la gestión y/o optimización de energía %USED y %UTIL deberían de ser iguales
  5. Core %UTIL, lo mismo que pCPU %UTIL pero por core
  6. %CSTP (ver descripción en el inicio del articulo)
  7. %RDY (ver descripción en el inicio del articulo)
  8. %WAIT (ver descripción en el inicio del articulo), en este caso es importante notar que también tenemos el %VMWAIT, en realidad el indicador en el cual debemos de prestar atención es en %VMWAIT debido a que %WAIT incluye el tiempo de %IDLE.

Posibles soluciones:

  • Verificar la configuración de las aplicaciones y/o gOS para reducir el consumo de CPU (“Tunear” las apps y gOS)
  • Migrar VMs a otros Hosts
  • Verificar posibles recomendaciones de DRS (en caso que no este en automático)

 

  • Valor Alto de %CSTP

Contrariamente de lo que podríamos pensar, una VM o grupo de VMs pueden estar ejecutándose bastante mal cuando asignamos mas vCPUs de los necesarios, en estos casos existirán VMs que están mas activas y otras que tal vez no tienen mucha actividad, el Host ESXi tratará que aquellas VMs que no tienen mucha actividad “se pongan al corriente” con respecto a las VMs activas y que el tiempo de ejecución en procesador no sea bastante distinto entre ellas, lo cual puede llevar a que el mismo hipervisor limite a las VMs activas.

Posibles síntomas:

  • Valor alto de %CSTP en ESXTOP

Posibles soluciones:

  • Reducir la cantidad de vCPUs asignados, a menor cantidad mayor chance de ejecutar los vCPUs en un pCPU/pCore, los vCPUs en estado activo no tendrán que competir demasiado con vCPUs en estado inactivo.
  • Reducir la cantidad de VMs por Host ESXi
  • Tunear el gOS/aplicación para usar los vCPUs correctamente (HALs, aplicaciones multithread, si la aplicación no es multi thread no tiene sentido tener SMP).

 

  • Valor alto en %WAIT 

En este caso lo mas recomendado es averiguar si tenemos latencia en disco o en la red, recordemos que %WAIT nos indica que el vCPU esta a la espera de un recurso por parte del hipervisor (vmkernel) generalmente acceso a I/O.

Posibles sintomas:

  • Valor alto en %WAIT
  • Latencia alta en storage (IP/FC)
  • Latencia en red

Posibles soluciones:

  • Determinar cuello de botella, por ejemplo, un datastore que esta presentando latencias bastante altas donde tal vez nos beneficiaríamos a través de la migración de VMs a otros datastores (claramente respaldados por otras LUNs).

 

Referencias

Claramente en este articulo no cubro todos los posibles casos y métricas que están disponibles, les recomiendo leer el siguiente material:

https://communities.vmware.com/docs/DOC-11812

http://www.vmware.com/files/pdf/perf-vsphere-monitor_modes.pdf

http://www.yellow-bricks.com/esxtop/

One comment on “vSphere troubleshooting – CPU

Leave a Reply