Buenas chic@s! En el día de hoy iniciamos una nueva serie de posts sobre como optimizar NSX-T. Por ello iremos desde la capa de hardware, pasando por la BIOS-ESXI, haremos hincapié en la optimización de la tarjeta de red Mellanox para NSX-T y finalizando por el Edge Node. Hoy empezaremos con la optimización con la tarjeta de red, vamos a ello!:)
Introducción
Cuando hablamos de obtener el mejor rendimiento en nuestro entorno NSX-T, muchas veces no prestamos atención a los pequeños detalles, y es en ellos donde a veces esta la clave. Como recordareis hace cosa de año, ya hablamos acerca de las » Optimizacion fisica para nuestro entorno de NSX-T » que debía de tener nuestro entorno, además vimos como saber si la teníamos activada en el siguiente post » Optimizacion fisica para nuestro entorno de NSX-T – Parte-2 «.
Por ello, en este post vamos a ir mas allá y vamos a intentar ir desde la base hasta la capa del Edge Node. Si me preguntarais para mi cual son las bases para obtener el mejor rendimiento, serian las siguientes, por supuesto empezando de abajo arriba:
- Elegir el Hardware adecuado
- Optimizar la BIOS y ESXI
- Optimizar nuestra tarjeta de red
- Configurar el Edge Node para un uso eficiente del hardware
En el día de hoy nos vamos a centrar en Optimizar nuestra tarjeta de red, concretamente aquellas basada en el chipset Mellanox. En los siguientes post veremos los 3 pilares restantes.
Introducción a optimización tarjeta de red
Cuando compramos una tarjeta de red, muchas veces solo nos fijamos en el ancho de banda de la tarjeta de red, y si, es una de la cosas mas importantes, pero no la que mas. Como hablamos en los post de «Optimización física de para nuestro entorno de NSX-T«, es muy importante fijarse en las características que tenga nuestra tarjeta de red. Por ello, o acudimos a la documentación del vendedor, o como en este caso, nos fijamos en el contenido de la HCL de VMware.
Antes de seguir leyendo, sino sabéis lo que son las «features» que vienen descritas en la imagen, os recomiendo leer los post que menciono arriba, ya que exploramos muchas de ellas.
Como bien sabemos, entre las características mas importante para obtener el mejor rendimiento en NSX-T, se encuentran GENEVE, RSS y GENEVE RX-FILTER. Estas viene activadas por defecto, antiguamente teníamos que activarlas.
La primera viene activada por defecto como ya vimos. Hay que recordar que GENEVE RX-FILTER es » como un plugin» el cual hace mas inteligente a RSS, ya que sin este plugin siempre balancearía a la misma cola, ya que es no es capaz de ver dentro del paquete GENEVE, por ello, gracias a este filtro puede ver lo que hay dentro del paquete GENEVE, y tomar decisiones de balanceo en base a su algoritmo . No todos los filtros GENEVE RX-FILTER balancean de igual forma, aquí os dejo concretamente el de Mellanox.
Una vez comentado esto, vamos hablar de RSS en su conjunto.
Configuración RSS
Como hemos comentado, RSS viene activado por defecto con el filtro GENEVE RX-FILTER. Una de las preguntas que tenemos que hacernos es, ¿ Es la configuración por defecto la adecuada para nosotros?.
Vamos a fijarnos en todos los parámetros que son configurables dentro del driver de Mellanox. Para ello lanzamos el siguiente comando:
esxcli system module parameters list -m nmlx5_core
Una vez obtenidos todos los parámetros del driver vamos a analizarlos los relacionados con RSS:
- DRSS: Numero de colas(queue) que tendrá el «Default RSS Engine».
- GEN RSS: Numero de RSS «Netqueue Engine» que tendremos
- Dentro de este numero viene incluido el «Default RSS Engine».
- RSS: Determina el número total de colas que se podrán asignar a los «RSS Netqueue Engines».
- Si GEN_RSS es superior a 2, el valor asignado a RSS será dividido entre los RSS Netqueue Engine.
- Max_queues : Numero máximos de colas(queues).
Todo estos valores se aplican por puerto, es decir si nuestra tarjeta de tiene 2 puertos. Tendremos un total de 48 colas(queues), dado que el valor por defecto es 24.
Ahora que hemos entendido un poco los parámetros del driver, vamos a meternos de lleno con un ejemplo. Este ejemplo será única y exclusivamente para un clúster de Edge, mas tarde entenderéis la importancia.
Ejemplo
Partimos de un servidor dual socket con 32 cores cada socket, cada socket(Numa Node) tiene asociada una tarjeta de red de 2 puertos de 100Gbe. Por lo tanto tenemos un servidor con 64 cores, 128 Threads y 4 puertos de 100 Gbps.
Una de las cosas que a la gente se le suele olvidar, es que el procesamiento del trafico no es gratis, con lleva usos de ciclos de CPU. Todas nuestras colas(queues) dentro del kernel de VMware van asociadas a un proceso, este proceso se llama «Pollworld».
Cada Pollworld va asociada a un core o thread, por lo tanto a la hora de dimensionar nuestras colas(queues),debemos tener en cuenta el trafico que vamos a recibir/enviar, sumados al numero de cores/threads de nuestra CPU. Esto es así ya que si tenemos un gran numero de colas, sumado a mucho de procesamiento de trafico, nos quedaran poco cores o ciclos de CPU para alojar/correr maquinas virtuales.
No hay que olvidar que los Edge Node necesitan recursos para procesar el trafico.
En caso de que no tengamos mucho procesamiento de trafico, estas colas(queues) estarán «idle» y no supondrán un gran problema, pero como me gusta decir, es mejor hacer un buen «sizing» y si hay que aumentar, siempre hay tiempo.
Aquí os dejo un KB, que describe el alto uso de CPU debido a los Pollword para aquellos chipset Mellanox.
Continuando con ejemplo, vamos a optar por la siguiente configuración:
- DRSS: 4
- GEN_RSS: 3
- RSS: 8
- Max_queues: 16
Con esta configuración tendremos: 1 «Default Queue RSS Engine» con 4 colas(queues), 2 «Netqueue RSS Engine» con 4 colas cada uno(recordar que al ser GEN_RSS > 2, se divide el valor asignado a RSS entre 2) y por ultimo Max_queue :16. Recordar que estos valores son puerto de red.
Si hacemos todos los cálculos, tendremos un total de 16 colas(Queues) por cada puerto, siendo un total de 32 colas(Queues) entre los 2 puertos de red. Si los dividimos seria 16 colas(Netqueues) para «Netqueue RSS Engine», 8 colas(Queues) para el «Default Queue RSS Engine» y 8 colas independientes(Standalone queues).
Tener en cuenta que el parametro «Max_queue» tiene un rango de valores posibles, así que cuidado con asignar un valor que no este en en ese rango, o el servidor una vez reiniciado, no tendrá red. Si esto te sucede bastara con acceder via ILO, asignar un valor del rango y reiniciar.
Para configurar lo que hemos comentado lanzaríamos el siguiente comando:
esxcli system module parameters set -m nmlx5_core -p "max_queues=16 DRSS=4 RSS=8 GEN_RSS=3"De esta manera habría quedado configurado.
Preguntas y respuestas
Para entender mejor todo esto, vamos a responder a unas preguntas que yo mismo me he hecho.
¿ Cuando se usa el Default RSS Engine?
El Default RSS Engine se utiliza en en el siguiente caso. Cuando las máquinas virtuales comienzan a recibir trafico se les asigna al Default RSS Engine , una vez que consigue superar los 2mbps o 2000 paquetes por segundo, se moverá a una cola(queue) dedicada. Si este patrón de trafico vuelve a bajar de estos umbrales, se le vuelve a asignar al Default RSS Engine.
¿ Cuantas colas tiene asignada el Default RSS Engine?
El default RSS Engine tiene asignada un total de 4 colas(queues) por defecto, esto lo podemos ver en el valor DRSS.
Si necesitaríamos añadir mas colas usuraríamos el parámetros DRSS.
¿Qué necesita una maquina para que le sea asignada un RSS Nequeue Engine?
Para que una maquina tenga acceso al RSS Netqueue Engine, primero debe superar la condición de 2mbps o 2000 paquetes por segundo, luego dentro del vmx debe tener asignado el siguiente valor «pnicsFeatures=4 «, recordar que este parámetro es por cada «Network Adapter» de la VM.
Los Edges Nodes, tiene configurado este por cada interfaz.
¿ Que sucede si una maquina virtual no tiene configurado pnicsFeatures=4?
Si supera la condición de 2mbps o 2000 paquetes por segundo será movida a una cola independiente(standalone queue).
¿ A que nos referimos con el termino cola independiente(StandaloneQueue)?
Una cola independiente(standalone queue) es aquella a la que una vNic de una maquia virtual es asociada, cuando ha superado los 2mbps o 2000 paquetes por segundo pero no tiene configurado pnicsFeatures=4, es decir, no puede optar al «Netqueue RSS Engine». En el caso de un clúster de Edge dedicado, nos interesa tener mas colas(queues) dentro del «Netqueue RSS Engine» que colas independientes(standalone queues), ya que los Edge Nodes si tienen en su configuración pnicsFeatures=4.
¿Qué sucede si nos encontramos con que ninguna maquina virtual tiene configurado pnicsFeatures=4 dentro del host ?
En este caso, las colas (queues) no serán asignadas al «Netqueue RSS Engine» y por lo tanto serán tratadas como colas independientes(Standalone Queues).
¿ Como sabemos si los colas asignadas a cada «Netqueue RSS Engine» es suficiente?
Como hemos comentado cada Pollworld(cola/queue) es un proceso que se asigna a un core/thread, si observamos que estos Pollworlds tienen unos valores bastante altos de uso, quizá deberíamos subir los valores RSS de los Netqueue RSS Engine.
¿ Debemos seguir el mismo patrón de diseño para un clúster Workload o Collapsed?
En todos los diseños es importante el numero de cores que tenga cada CPU, ya que marcara mucho el numero total de colas(queues). En el caso de un clúster Workload, yo lo dividiría en si las maquinas van hacer a solicitar «Netqueue RSS Engine» o no . En el caso de que no, intentaría hacer un enfoque mas hacia un uso de colas independientes(standalone queues), creando quizá solo un «Netqueue RSS engine», y enfocándome mas en optimizar el parámetro «max_queues».Recordar que el «Default RSS Engine» siempre esta.
En caso de que hubiera alguna maquina configurada con el parámetro «pnicsFeatures=4«, el cual solicitaría un «Netqueue RSS Engine» , también lo tendríamos cubierto.
Por otro lado, si tengo un clúster Collapsed, quizá podríamos hacer uso de la configuración anterior( 1 Netqueue RSS Engine y 1 Default RSS Engine) pero añadiendo mas colas RSS a nuestro Netqueue RSS Engine que colas independientes(standalone queues). Recordar que el parámetro «Max_queue» determina el numero de total de colas, fijaros en la ultima pregunta.
¿ Que sucede si tenemos configurados varios Netqueue RSS Engine y no tenemos ninguna maquina que los solicita?
En ese caso todas las colas serias tratas como colas independientes(Standalone queues), hasta que alguna vNic solicitada un «Netqueue RSS Engine».
¿ Que sucede si tengo la siguiente configuración » DRSS= 4 RSS=8 GEN_RSS=3″ y el max_queue por defecto es de 24?
En este caso tendríamos un total de 2 Netqueue RSS Engine con 4 colas cada uno y 1 «Default RSS Engine» de 4 colas. Esto nos daría un total de 12 colas configuradas, el problema vendría en que tendríamos 12 colas independientes(Standalone queues).¿Es esto lo que necesitamos?.
¿Por qué pongo este ejemplo?. Ya que aunque hayamos hecho una buena configuración, no hemos optimizado el parámetro «max_queue» y tenderíamos demasiadas colas independientes (Standalone queues) sin usarse. Estas si no se usan no generarían ningún problema, pero en caso de que si, estaríamos comprometiendo el clúster. Recordar el KB.
Conclusión
Bueno chic@s! Hasta aquí hemos llegado, la verdad que es un post bastante teórico que sin la ayuda de Dixon Ly(VMware) no habría podido escribir. Espero que os guste y si tenéis cualquier duda, no dudes en preguntar. Nos vemos en los siguientes post.
Un comentario