Hoy quisiera explicar algunos conceptos importantes y fundamentales sobre VMware NSX y que pueden no ser familiares para muchos de los que recién empiezan con el amplio mundo del networkig.
Quizás esta parte sea aburrida para aquellos que en cambio tienen muchos años de experiencia, para ellos les recomiendo continuar con Los planos en el NSX.
Los tres planos
Cualquier equipo de networking se puede dividir en tres planos distintos según sus funciones, a saber, el plano de gestión (management), el plano de control y el plano de datos. En algunos equipos modulares, estos planos están físicamente definidos, por una controladora que es el cerebro del equipo (la supervisora) que es responsable del plano de control y gestión, y los módulos de I/O (entrada/salida) en el plano de datos.
El plano de gestión es el responsable de permitir al administrador del equipo poder conectarse al mismo y configurarlo. Muchos equipos por ejemplo tienen un plano de gestión basado únicamente en una CLI (interfaz de línea de comandos), otros en cambio, tienen una interfaz web y muchos soportan APIs (application program interfaces) que no son ni más ni menos que rutinas que permiten ejecutar programáticamente ciertas funciones. Aclaro este detalle porque justamente una de las funcionalidades principales del NSX es que soporta API REST, lo que permite administrar el equipo a través de orquestadores o herramientas como el vCloud Director o el gestor de OpenStack.
El plano de control incluye tareas como la de averiguar la topología de la red, aprender cómo llegar a todas las redes o subredes que la componen. Esta tarea es responsabilidad de ciertos protocolos bien conocidos que dependen del tipo de dispositivo del que hablemos. Si es un equipo de nivel 2 (un switch o bridge), entonces los protocolos serán por ejemplo STP (Spanning Tree Protocol) o el mecanismo de aprendizaje de las direcciones MAC (Transparent Learning), en cambio si el equipo es de nivel 3 (un router), podemos encontrar a ARP (Address Resolution Protocol), OSPF (Open Short Path First) o BGP (Border Gateway Protocol) entre muchos otros.
El plano de datos es el responsable de conmutar los paquetes que llegan por un puerto del equipo, analizarlo y tomar la decisión de qué hacer con este paquete, que generalmente será enviarlo por otro puerto para que este pueda llegar a su destino. Esa tarea puede ser ejecutada por un circuito electrónico (ASIC) o por el procesador del equipo (cada vez menos frecuente por su lentitud).
Históricamente estos tres planos siempre estuvieron incluidos en el mismo equipo, lo que hacía que la red sea algo complejo de administrar porque para lograr comunicar a los usuarios con las aplicaciones de negocio se requería configurar los switches para crear las VLANs, configurar los routers para habilitar los protocolos necesarios y probablemente configurar algún firewall para abrir algunos puertos.
En algunos casos esto requería la interacción de varias personas (los responsables de red y de seguridad) y el resultado era que pasaban varios días hasta que todos los componentes estaban listos para que el tráfico al fin pudiera llegar a los extremos. Dicho sea de paso, y solo para agregar algo más a este tema, el paradigma de SDN (Software Defined Networking) propone separar estos tres planos y ejecutarlos no en el mismo equipo, sino en diferentes instancias, de manera de tener un componente responsable de la gestión, que permitirá configurar centralizadamente no uno, sino varios equipos (responsables del plano de datos) con una visión global en vez de con una visión individual de la red.
Si alguna vez han visto como se gestionan los puntos de acceso lightway entenderán perfectamente este concepto.
Los planos en el NSX
En el NSX el plano de gestión es responsabilidad del NSX Manager y la principal interfaz de gestión es la de web, ya sea utilizando un navegador para conectarnos y gestionarlo mediante el web client, o bien gracias al soporte de REST APIs.
El plano de control en cambio es la responsabilidad principal de un componente que no casualmente se llama el NSX Controller. Esta función es realizada por un cluster de tres o más VMs que se distribuyen distintas tareas de los protocolos de control. ¿Por qué tres o más? La best practice es implementarlos en números impares para reducir el fenómeno llamado Split-Brain que ya explicaré en alguna otra nota. En la primera versión del NSX las instancias del NSX Controller podían ser hasta 5, pero en la versión 6.1 creo que podrán ser hasta 7. La otra ventaja de tener varias instancias del NSX Controller es poder distribuir la carga de las tareas de los protocolos de control en forma más o menos equitativa. Ya veremos que esto se hace mediante una técnica llamada slicing en otra nota.
Por último, en el plano de datos encontramos varios componentes, que son los responsables de manejar los paquetes (o tramas), y que pueden estar centralizados en una VM en el caso de el NSX edge router, o distribuidos como en el caso del el vDS (virtual Distributed Switch), o el Distributed Logical Router. Si las funciones de estos componentes no les son familiares, les recomiendo que lean mi nota anterior en este mismo blog.
Una de las cosas que más me costó entender del NSX era justamente qué función cumplían cada uno de esos componentes, pero ahora está totalmente claro para mi, y espero que también para vosotros.
Los componentes en el NSX
En la figura siguiente podrán ver los íconos que representan dichos componentes y la asociación con cada una de las tres capas. En la capa de consumption podrían situar al vCloud Director por ejemplo.
En la figura de la cabecera de este post encontramos un escenario típico de los componentes VMware NSX.
En este diagrama vemos a los dos componentes principales responsables del routing, el NSX edge (una o más VMs) que conecta nuestra red virtual a una red externa como si fuera un Border router, y al Distributed Logical Router que controla a los agentes del router distribuído que corren en cada uno de los servidores ESXi.
En el paso 1 a través del NSX manager (plano de gestión) activamos por ejemplo OSPF en las instancias ambos routers, y entre ellos establecerán adyacencia (OSPF peering) y comenzarán a intercambiar la información (plano de control) para entender la topología de la red. En el caso del NSX Edge router el plano de control y de datos trabajan en la misma VM, como si se tratara de un router físico estándar, porque los paquetes pasan a través de si, mediante dos interfaces (port groups) que podríamos llamar interna y externa.
Distinto es el caso del Distributed Logical Router representado por esta figura.
Este router está compuesto a su vez por dos componentes, una VM (
) que se ejecutará en uno de los ESXi que compone el NSX y que es responsable del plano de control (ejecutar OSPF, establecer adyacencias, enviar Hellos) y varios agentes (
) que es software (VIBs) corriendo en el kernel del ESXi y que reciben instrucciones sobre cómo conmutar los paquetes de las VMs clientes comportándose como un Default Gateway (DG) distribuido. Para aquellos que conocen la solución de Cisco del Nexus 1000v, estos agentes son equivalentes a los VEM (Virtual Ethernet Modules).
En el paso 2 cada componente se conectará con sus vecinos y establecerán las adyacencias para comenzar a intercambiar información sobre la topología de la red (plano de control).
Las rutas aprendidas por cada uno de los routers son enviadas al cluster de controladores para que los distribuya a los demás (pasos 3 y 4).
Si la VM 172.16.10.11 quiere enviar un paquete a otra subred lo enviará a su DG, que será el agente que ejecuta el kernel del ESXi donde reside y que tendrá asociado una dirección IP (que a su vez será compartida, al igual que la dirección MAC con los demás agentes en los demás ESXi).
En este punto pueden pasar varias cosas.
- Que el destino sea una IP de una subnet directamente conectada y que se trate de una VM que corre en el mismo ESXi, por ejemplo 172.16.20.10. El agente entonces será capaz de conmutarlo y el paquete nunca abandonará el host.
- Que el destino sea una IP de una subnet directamente conectada y que se trate de una VM cliente que corre en otro ESXi. Entonces el agente solo tendrá que conmutarlo y enviarlo al servidor que corre el VM y que es el responsable de la MAC de destino (ARP mediante). Este escenario puede ser muy complejo, y lo explicaré en mi próxima nota cuando hablemos de VXLAN, que es la función de L2 que usa el NSX.
- Que el destino sea una IP de una subnet remota, por lo que el paquete será enviado a la VM que controla el agente (next hop).
- Que el agente no conozca la subred de destino y entonces haga un drop.
- Que exista un filtro para la dirección de destino y que el agente tenga que hacer un drop del paquete.
- Y muchas cosas más que hacen los routers estándar.
Aprovecho la ocasión para hacer notar que en el kernel del ESXi pueden haber otros agentes que cumplen otras funciones, a saber:
Es el agente que controla las operaciones de nivel 2 (VXLAN). En mi próxima nota hablaremos de él.
Es el agente responsable de aplicar las reglas de seguridad que indica el firewall para controlar el tráfico Este-Oeste (explicado en mi nota anterior).
Espero que esta nota haya servido para aclarar algunos conceptos muy importantes en el NSX como los planos de gestión, control y datos, y cuáles son los componentes responsables de ejecutar dichos planos en la función de routing.
Los espero en la próxima nota para hablar sobre VXLAN. Saludos
Gracias por leer nuestro blog, participar y compartir.
