[NSX-T 3.2.x] Integración de AVI ALB ¿Qué cambia respecto al balanceador de NSX?.

Como muchos de vosotros sabéis, VMware decidió descontinuar el balanceador de carga tradicional de NSX-T, para dar paso al NSX Advanced Load Balancer, antiguamente conocido como AVI ALB o AVI Vantage.

Esto ha conllevado a la incertidumbre de muchos usuarios, ya que este nuevo producto cambia por completo la topología y diseño de nuestro entorno NSX-T, introduciéndonos en un producto donde muchos no son expertos.

Sin embargo, las buenas noticias son varias, como por ejemplo, que a pesar de que el balanceador nativo de NSX-T pasará a ser descontinuado, todavía no hay una fecha o release de retirada, por lo que tenemos un buen margen de tiempo para planear nuestra migración o familiarizarnos con el cambio. Igualmente nos encontramos ante un producto con el que personalmente he podido trabajar mucho y puedo confirmar que funciona muy bien y que resulta muy interesante de cara a un posible futuro enfoque cloud-native de NSX-T.

Por otro lado, a raíz de este cambio se incluye una licencia «Basic» por cada instancia de NSX-T que tuviéramos licenciada, dando lugar a un balanceador con prestaciones muy similares a las que teníamos con el balanceador de NSX-T, pero con opción a escalar hacia una versión «Enterprise» donde además contaremos con características como Web Application Firewall (WAF), GSLB, balanceos Activo/Activo, o Datascripts (scripts que aplican directamente sobre el Dataplane, permitiéndonos crear una política de balanceo muy customizada, al estilo HAproxy)

De igual manera, si no disponemos de NSX-T, pero disponemos de licencias de Tanzu, nuestra licencia será válida para la edición «Essentials» de AVI, que nos permitirá exponer servicios de hasta capa 4 mediante la integración con AKO (Avi Kubernetes Operator).

¡Al turrón! ¿Qué es lo que cambia?

Esta es una de las preguntas más comunes, y la primera que nos haremos si deseamos ir hacia un entorno AVI y no hemos trabajado con este balanceador previamente.

Vamos por partes:

Si hacemos memoria, la arquitectura del balanceador de carga tradicional de NSX-T no es otra que un servicio Stateful que corre dentro de una VM de EDGE, más concretamente dentro de un T1.

Esto realmente nos aportaba ventajas sobre todo en sencillez de despliegue, ya que una vez desplegado nuestro cluster de EDGEs, podíamos tener nuestro balanceador en marcha con un par de «clicks». Sin embargo tenía algunas desventajas, como por ejemplo que quedaba montado sobre el Service Router (SR) haciendo que todo el tráfico que viniera por el Distributed Router (DR) como por ejemplo aquel que proviene de otro segmento conectado al mismo T1 no funcionase a no ser que se aplicara SNAT

(Documentacion de VMware)

In the inline mode, the load balancer is in the traffic path between the client and the server. Clients and servers should not be connected to overlay segments on the same tier-1 logical router if SNAT on the load balancer is not desired. If clients and servers are connected to overlay segments on the same tier-1 logical router, SNAT is required.”

Así como el hecho de tener la escalabilidad del propio balanceador limitada al tamaño de nuestro cluster de EDGEs sin poder crecer de una manera más «flexible».

Igualmente, a pesar de tratarse de un buen balanceador cuyo funcionamiento es muy estable, en ocasiones, sobre todo cuando llega la hora de «salirse de lo establecido» o de trabajar a nivel de scripting, me he encontrado algo limitado en características. Algo que no sucedía con el balanceador de NSX-V al ser un derivado directo de HAproxy.

Entendiendo la arquitectura AVI

La arquitectura AVI, es una arquitectura moderna, definida por software y con sus diferentes planos desacoplados, al igual que sucede con NSX-T, nos encontramos con dos componentes:

• El cluster de controladores, habitualmente compuesto por 3 AVI controllers para dar HA. La función de los controladores es servir tanto el Control Plane como el Management Plane
• Los AVI Service-Engines o SEs, serán el Data Plane de nuestra red de balanceo, es decir, los encargados de procesar el tráfico de balanceo tanto entrante como saliente. Para su correcto funcionamiento necesitaremos que tengan conectividad directa tanto con la red de Management como con nuestra red de FrontEnd (publicaciones) así como con la red de Backend, bien sea mediante enrutamiento o con pata directa.

A pesar de que el balanceador de AVI puede trabajar por sí solo como One-Arm o In-Line, por el momento la única topología contemplada como válida para NSX-T es One-Arm, es decir, el tráfico de entrada y de salida ha de cursarse por la misma interfaz del Service-Engine, pudiendo existir una interfaz dedicada para cada VRF.

Ejemplo de arquitectura AVI con NSX-T

¿Qué ganamos con esto?

• Desacoplamiento de la infraestructura de EDGEs de NSX-T, pasando a ser un balanceador independiente
• Escalabilidad, basando nuestra estrategia de licenciamiento o emplazamiento de los SEs, así como recursos consumidos por los mismos en función de los servicios a balancear
• Posibilidad de balancear en Activo/Activo (Licencia Enterprise)
• Posibilidad de control 100% desde la API, facilitando en gran medida la automatización con respecto al LB de NSX-T
• Posibilidad de parametrización, logs y métricas en tiempo real superiores a las ofrecidas por NSX-T, aumentando la capacidad de troubleshooting
• Escalabilidad hacia funcionalidades como GSLB o WAF (Licencia Enterprise)

La única duda que me queda pendiente, es si VMware proporcionará alguna herramienta para migrar servicios al estilo «Migration coordinator» de manera que podamos llevarnos nuestras cargas a AVI fácilmente.

Por mi parte ya lo he preguntado, pero por el momento es secreto de sumario, ¡En cuanto sepa algo os lo traeré!

Por favor, si os ha gustado el artículo sentiros libres de compartir así como de dejar feedback o dudas en la sección de comentarios.

¡¡Gracias por leerme!!