VMware: Mejores prácticas en la sobresuscripción de CPU

Como es bien sabido, una de las ventajas de la virtualización es la de poder asignar mas recursos virtuales de los que realmente disponemos sobre un determinado hardware. Esto hace que el uso de los recursos sea mas eficiente y los aprovechemos mejor. Si bien es posible hacer una sobresuscripción con un ratio elevado, esto nos puede llevar a tener problemas de rendimiento en las máquinas virtuales. He encontrado una guía muy completa donde se establecen algunas mejores prácticas a la hora de dimensionar las máquinas virtuales.

pCPU vs vCPU

Lo primero a tener en cuenta es que se entiende por pCPU y vCPU:
  • pCPU se refiere a las CPU físicas. El número de CPUs físicas presentes en un determinado host depende de varios factores como son el número de sockets, el número de cores y si tiene hiperthreading y está habilitado. 
  • vCPU son las CPU que se asignan a una máquina virtual y no tiene porque está ligado al número de pCPU. Cuando se crea una máquina virtual las vCPU se asignan a una pCPU. Debe haber un número de pCPU disponibles para soportar el número de vCPU asignadas a una máquina virtual o esta no podrá arrancar.

En vSphere 5 el número máximo de vCPU por pCPU es de 25:1. Aunque se recomienda que por temas de rendimiento esta relación no sobrepase el 5:1. No obstante esto siempre dependerá del tipo de carga de trabajo que ejecuten las máquinas virtuales.

    Cuando se supera la relación 1:1 debe entrar en funcionamiento el “scheduler” para distribuir los tiempos de procesador entre las máquinas que lo necesiten.

    A la hora de dimensionar el ratio vCPU:pCPU la guía recomienda seguir dos estrategias:

    1. Empezar con una vCPU en la máquina virtual. Una vez analizada la carga de la máquina virtual ir añadiendo vCPU según la necesidad. Cuando la máquina virtual necesite realizar una operación, esta tendrá que esperar a que haya disponibles un número de pCPU igual al número de vCPU. Con lo que, al añadir mas vCPU se incrementa el riesgo de que el tiempo de espera de pCPU aumente provocando un rendimiento peor.
    2. Como la relación vCPU:pCPU depende de la carga de trabajo, la relación puede ser mayor en hosts que ejecuten máquinas virtuales con necesidades de procesamiento marginal. Por otro lado, en hosts que requieran intensivas cargas de trabajo, el ratio deberá ser inferior.

    Métricas

    Existirán ciertas métricas que nos servirán para determinar si el host está teniendo algún problema de rendimiento y para hacer un uso mas eficiente de los recursos mientras se mantienen las cargas de trabajo.

    • Uso de CPU de la máquina virtual: Se deberán añadir vCPU adicionales cuando el uso medio de CPU se mantenga en altos niveles.
    • CPU Ready en el host: Desde el punto de vista de la salud del host, esta es la métrica mas importante. Esta métrica determina el tiempo que una máquina virtual esta esperando para obtener vCPU disponibles que necesita. Por ejemplo, si una máquina virtual tiene asignadas cuatro vCPU, esta métrica indica el tiempo que una máquina virtual ha esperado para que cuatro pCPU estén disponibles en el mismo instante de tiempo.
    • Uso de CPU del host: permite analizar la carga que está soportando el host.

    En el White paper se establecen estos criterios:

    • Una relación entre 1:1 y 3:1 no provoca problemas
    • Entre 3:1 y 5:1 puede empezar a causar alguna degradación de rendimiento
    • Si la relación es superior a 6:1 se suelen tener problemas.

    Adicionalmente se recomienda que el CPU Ready este por debajo del 5%.

    Calculo del CPU Ready

    Como hemos comentado esta métrica es realmente importante para determinar si estamos teniendo problemas de rendimiento. En el cliente de vSphere esta métrica se representa en segundos, mientras que con un ESXTOP se devuelve en porcentaje.

    Para realizar la conversión debemos tener en cuenta el tiempo de muestreo de la gráfica, 20 segundos en la gráfica de real time. La fórmula será la siguiente:
    (x ms  / 20.000 ms) * 100 = %rdy
    Por ejemplo, con esta formula sabremos que:

    • 1% = 200ms
    • 5% = 1000ms
    • 10% = 2000ms
    • 100% = 20000ms

    Hay que tener en cuenta que estas medidas se dan por vCPU, co lo que una máquina con 4 vCPU podrá llegar a tener un 400% de tiempo de planificación. La misma máquina con un 10% de CPU Ready implicará que cada vCPU tenga un CPU Ready de 2.5%.

    Caso Real

    En el siguiente ejemplo tenemos un host HP Prolian DL580 G7 con 4 CPU octacore y con Hyperthreading activado:

    En dicho host hay máquinas virtuales de todo tipo, pero especialmente hay varias “Monster Machines” con hasta 128GB de RAM y 32 vCPU. Como se puede ver en la siguiente gráfica, estas máquinas están sobredimensionadas, ya que el uso de CPU medio es muy bajo:

    Otras tienen un uso de CPU mas elevado, la media en torno al 65%.

    Sin embargo en momentos puntuales llegamos a tener contención y el CPU ready se dispara como podemos ver en esta gráfica donde aparece el acumulado en el host. Esto es debido a que estas máquinas forman parte de un servicio que hace que todas tengan una carga intensiva de CPU en momentos puntuales haciendo que el CPU Ready suba tanto que al final el rendimiento de las máquinas es peor del esperado:

     Como vemos en las gráficas de rendimiento de estas  “Monster Machines”, en momentos puntuales el CPU Ready se dispara a la vez, llegando a los 13 segundos:

     
    Según la fórmula de conversión al %rdy esos 13 segundos corresponden a un 65% de CPU Ready. Para la máquina de 32 vCPU es un 2% por CPU y para la máquina de 8 vCPU corresponde a un 8%. Esta última es la que realmente está teniendo un peor rendimiento y la que se vé mas afectada. Lo ideal sería bajar el número de vCPU asignadas a estas máquinas virtuales para adecuarse mas al consumo real que están teniendo.


    Algunos enlaces interesantes respecto a este tema:

    Anuncios

    Fallo al arrancar máquinas virtuales despues de migrar oVirt a 3.5

    Recientemente he actualizado una instalación de oVirt de la versión 3.4 a la versión 3.5. El proceso es bastante trasparente y básicamente consiste en actualizar el repositorio y seguir los mismos pasos que durante la instalación. Una vez con la nueva versión podemos actualizar la compatibilidad del cluster que tengamos configurado a la versión 3.5. Para ello es recomendable poner los hosts en mantenimiento. Una vez actualizado se pueden actualizar también los Hosts. Ya con todo actualizado vemos que hay funcionalidades nuevas, como la gestión de memoria con NUMA. 
    Esta funcionalidad puede ser interesante en entornos que requieren un uso intensivo de CPU y Memoria, pero debe estar bien configurado. Si, como en mi caso, tenemos un entorno mas estándar no es necesario configurarlo, pero al intentar arrancar las máquinas de nuevo podemos tener el siguiente error:
    VM compute1 is down with error. Exit message: internal error internal error NUMA memory tuning in ‘preferred’ mode only supports single node.
    Para solucionarlo basta seguir los pasos que se indican en la lista de distribución:
    Resumiendo, hay que editar la máquina virtual que presenta los problemas y acceder a la opción Host:
    Allí veremos que el “Tune Mode” esta deshabilitado y configurado por defecto en “Preferred”. Para poder cambiarlo seleccionaremos un host sobre el que correrá esta máquina y deshabilitaremos las migraciones. En ese momento ya podemos seleccionar la opción “Interleave” como “Tune Mode”:
    Una vez cambiado podemos volver los parámetros por defecto. Una vez aplicados podremos arrancar la máquina