Servidores virtuales ESXi (Nested) y valores de %KAVG

Que tal gente, el día de hoy les voy a platicar sobre un problema que tuve en mi laboratorio. Me encontraba instalando un vPOD de Horizon Suite donde incluía Mirage, View, etc, lo interesante es que también estoy incluyendo VSAN para poder mostrar la interacción. Como he platicado en algunas otras ocasiones, mi laboratorio esta basado en vCloud Director (y creo que se quedará por mucho tiempo así) lo que me permite tener ambientes 100% contenidos e independientes el uno del otro. Extrañamente cada vez que iniciaba el vApp de vCD donde tenia todo el ambiente de VSAN y Horizon mis servidores ESXi experimentaban una lentitud demasiado alta, como buen nerd apasionado por encontrar los problemas y resolverlos (aun cuando tome tiempo de mis noches y madrugadas) comencé a analizar los datos de rendimiento del ambiente a través de ESXTOP (la herramienta con la cual me siento mucho mas comodo) y pude notar lo primero que era un valor IMPRESIONANTEMENTE ALTO de %KAVG (Kernel Average Latency) en el datastore donde se encontraban almacenadas todas las VMs que constituyen el vApp:

kavg1

Basándome en esto lo primero que pensé fue “¿Tal vez existen reservaciones SCSI por la cantidad de VMs que estoy ejecutando?”, claramente esto no era el caso (el valor de CONS/s era 0), debido que aunque mi almacenamiento (PX6-300D) no soporta VAAI y necesita utilizar reservaciones SCSI para operaciones privilegiadas (como actualizaciones de metadata) pero también por que solo tenia 15 VMs ejecutándose y no es un ambiente “dinámico” donde se enciendan o apaguen VMs constantemente, se tomen snapshots, etc. Basándome en este problema de latencia a nivel del Kernel lo primero que quise hacer fue migrar mis vApps de datastores basados en iSCSI hacia un datastore basado en NFS (presentando nuevos perfiles a través de tags a vCD)… lamentablemente esto tampoco resolvió el problema (y me tomó horas migrar todo :( ). Después de esto seguí revisando la infraestructura y en este momento me tocó revisar la red desde ESXTOP, y ¡voilà! pude notar que tenia una cantidad enorme de paquetes caidos en todas las VMs de ESXi (vESXis) que formaban parte de dicho vApp:

paquetescaidos

Una vez sabiendo que este problema podía ser la causa de toda la lentitud, me di a la tarea de buscar que era lo que estaba ocasionando esta situación en mis servidores virtuales ESXi ya que en otros vApps no presentaba esta lentitud… Lo único distinto con estos servidores es el hecho que estos ESXi virtuales tienen VSAN activado y mis demás vPODs están basados en almacenamiento iSCSI provisto por appliances virtuales de HP, primero instale las VMware tools en dichos servidores virtuales ESXi (https://labs.vmware.com/flings/vmware-tools-for-nested-esxi) y cambie la tarjeta de red de E1000 a vmxnet3 (si, vmxnet3 esta soportado en ESXi 5) basándome en un problema que Duncan Epping describió en este articulo http://www.yellow-bricks.com/2010/02/02/e1000-and-dropped-rx-packets/ , nuevamente no tuve suerte y el problema persistía… Como último recurso opté por incrementar el buffer de la tarjeta vmxnet3 de 256 a 4096 utilizando el siguiente comando:

ethtool -G vmnicX rx 4096

RXbuffers

Y para mi buena fortuna esto resolvió el problema :) , el razonamiento detrás de este problema (desde mi perspectiva, estoy por confirmarlo internamente) es que al tener trafico de multicast y una cantidad muy alta de paquetes viajando, estas vNICs no eran capaces de procesar correctamente el tráfico con el buffer de RX (paquetes recibidos) tan pequeño que tiene. Aquí podemos ver que efectivamente el problema fue resuelto:

Screen Shot 2014-08-18 at 1.39.45 AM

3 comments on “Servidores virtuales ESXi (Nested) y valores de %KAVG

  1. Mauricio Pennini August 19, 2014 10:39 pm

    Agustin,
    Es totalmente razonable que aumentando el buffer se solucione el problema, ahora como impacta entonces en un ambiente de Producción con VSAN activado? cual seria entonces una Best Practices en ambientes pequeños los cuales tenemos un montón en LATAM?

    • amalanco August 20, 2014 7:38 pm

      Mau, el tema aquí es que este ambiente esta sobre redes de VCNI que es lo que estoy creyendo que al final de día causa el problema real (VCNI no trabaja muy bien con multicast). De igual manera, este es un ambiente en servidores nesteados, por lo que el impacto de que unos paquetes se caigan es muchísimo mas “grave” debido a que el host ESXi se ve forzado a trabajar extra (ya que todos los esxi virtuales re envían paquetes) y en el caso especifico de VSAN en ambientes nesteados es que al estar esperando a que los paquetes lleguen con ese nivel de caída (DRPPX) pues el KAVG aumenta. En un ambiente físico no se presentaría este mismo comportamiento.

  2. davosmirror August 21, 2014 8:08 am

    Hola
    Confirmo que en uno de nuestros entornos de producción, llevar el RX y TX buffer al máximo soportado resolvió un problema de TCP.IP heap size que se agotaba por alto tráfico generado por tareas de backup y replicación con un producto de terceros que no cerraba apropiadamente los sockets que abría. Al agotarse el heap size los host se desconectaban de vCenter y la única solución era reiniciarlos.
    Elevar entonces el ring hizo el truco, solo hay que tener en cuenta el uso adicional de memoria que implica y bueno, asesorarse siempre de GSS.

    Gracias.

    Saludos.

Leave a Reply