Buenas chic@s! Un día mas estamos aquí con un post sobre NSX-T, durante los post venideros acerca de NSX-T hemos tocado muchas de las “features” que incorpora este producto. En el caso de hoy vengo hablaros de como sacar el mayor rendimiento a nuestro entorno de NSX-T, haciendo hincapié en una de la parte mas criticas, y que a veces prestamos menos atención, como son las tarjetas de red, y las características que vienen con ellas.
Introducción
Cuando estamos diseñando un entorno como NSX-T, la mayoría de veces solo nos fijamos en la capa lógica, es decir, nos fijamos en que tenemos que tener redundado nuestros edges, controllers, adyacencias,… dejando del lado la optimización de la capa física. Pensamos que con comprar tarjeta dedicadas con un par de puertos de 25 Gbps, y dejando de lado soluciones de sobresuscripción por puerto como Virtual Connect, Fabric Interconect, etc, ya tendremos todo hecho. Por ello cuando tenemos una falta de rendimiento, nos acordaremos de no haberle dedicado el tiempo necesario a esto. Buscando un símil con vSAN, no todo es comprar los mejores discos, también tenemos que invertir en buenas tarjetas de red para que procesen el trafico sin que se sature, tenemos que tener switches que tengas buenos buffer por puerto. En resumen todo influye, es por ello que a lo largo de este post, vamos a ver cuales serian las “features” que deberían de tener nuestras tarjetas de red, tanto para nuestro clúster de computo, como nuestro clúster de edge.
A continuación os deja ciertas ” Features” las cuales nos ayudaran a obtener un mejor rendimiento en nuestro entorno NSX-T, ayudando de esta manera a liberar ciclos de CPU, y obtener un “line rate” en el procesamiento de paquetes similar a la capacidad de nuestra tarjeta de red.
Features
Geneve Offload
TCP Segmentation Offload (TSO) permite a los segmentos grandes pasar a través de la pila TCP, en lugar de paquetes más pequeños como lo impone la MTU en la capa física. Geneve Offload es un TSO “tuneado” para entender las cabeceras Geneve.
Geneve Offload proporcionara un aumento de rendimiento, liberando ciclos de la CPU del host para para que estos sean aprovechados por otros procesos.
La segmentación sólo se produce cuando el paquete debe atravesar la capa física. En el diagrama podemos observar cómo la VM transmite segmentos de 64K, que pasan por la capa switiching, routing, firewall y la pila TCP del hipervisor. La NIC física del hipervisor se encarga de dividir los segmentos en paquetes de tamaño MTU antes de pasarlos a la estructura física.
Se requieren NICs compatibles para realizar Geneve Offload . En caso de no ser así, el hipervisor realizara el TSO por software justo antes de pasar los paquetes de tamaño MTU a la NIC.
RSS
RSS permite el uso de múltiples núcleos, y colas para procesar el tráfico entrante. RSS nos ayudara a mejorar el rendimiento, que escalara con la cantidad de núcleos, o colas.
Sin RSS, sólo se utiliza un núcleo para procesar el tráfico entrante, lo que crea un cuello de botella, y afecta negativamente al rendimiento general.
La parte izquierda del diagrama muestra un sistema sin RSS, con una sola cola de NIC y un núcleo de hipervisor que procesa todo el tráfico entrante. Como vemos si habría una gran carga, la cola de la NIC podría llenarse, y el núcleo de la CPU podría alcanzar el 100 por ciento de utilización, lo que resultaría en un rendimiento pobre, e incluso en una degradación del procesamiento de los paquetes. La parte derecha del diagrama muestra un sistema con RSS. Se utilizan múltiples colas y núcleos para procesar el tráfico entrante. Como resultado, la carga se repartiría, y se podría llegar a conseguir un mayor rendimiento sin sobrecargar ninguna cola, o núcleo.
Se necesitan NICs compatibles con RSS. La mayoría de las NIC son capaces de soportar al menos cuatro colas.
RSS and Geneve
El RSS utiliza la cabecera exterior de la trama para distribuir los flujos en diferentes colas. El RSS no está optimizado para trabajar con el tráfico de encapsulación Geneve, ya que la mayoría de filtros que usa RSS para distribuir el trafico están basados en IP Origen, IP destino, Mac Origen, Mac destino, y puerto destino. Esto deriva en que si tenemos mucho trafico este-oeste, el trafico entre 2 hipervisores será procesado por la misma cola, todo ello por no tener la capacidad de ver la cabecera del paquete de la maquina virtual( inner packet o Original ethernet frame), y que viene encapsulado en la trama Geneve.
Recordemos que el trafico encapsulado viaja en los TEP, siendo estos siempre con la misma IP origen.
Geneve RX Filters
Geneve Rx Filters son unos filtros “tuneados” para que RSS pueda ver dentro de las tramas encapsuladas por Geneve. Geneve Rx Filters utilizara la trama Ethernet original (paquete interno) además del VNI(Identificador del segmento) para proporcionar decisiones de cola óptimas para el tráfico de Geneve.
Utilizando los filtros Rx de Geneve se nos proporcionara un mejor rendimiento, y desempeño en los ” transport node “en comparación con lo que puede proporcionar el RSS.
En ausencia de filtros RX de Geneve, el RSS sigue proporcionando un aumento de rendimiento para el tráfico de encapsulamiento de Geneve, pero no será tan optimo como si tendríamos los filtros de Geneve.
Otros factores que afectan al rendimiento
- Para procesar paquetes mas rápido tenemos que fijarnos que nuestras tarjetas de red soporten “Enhanced Data Path – Interrupt mode,Enhanced data path – Poll mode”, util si tenemos cargas NFV.
- Una tarjeta dual port de 25 Gbps es lo recomendado para un clúster de computo, si por el contrario es para un clúster de edge mi recomendación iria por una tarjeta dual port de 40 Gbps o 100 Gbps.
- Debemos de fijarnos en la generación de PCI Express de la tarjeta de red, así como donde insertamos nuestra tarjeta para evitar sorpresas de rendimiento..
Conclusión
Hasta aquí hemos llegado, como hemos podido ver, hay un montón de características que se tienen que tener en cuenta en las tarjetas de red, para obtener el mejor rendimiento dentro de nuestro entorno de NSX-T. En la 2 parte veremos como encontrar todo estas características dentro del hipervisor, además de echar un ojo a la HCL, driver, firmware, etc. Nada mas, nos vemos pronto. Un saludo.
