VXLAN: Redes virtuales Overlay Multitenant

"La necesidad de redes virtuales propias a cada cliente dentro de las infraestructuras Cloud multitenant, suele implicar la utilización de técnicas de Overlay que permitan la separación lógica de los datos que por ellas circulan, así como una gestión segmentada y la elasticidad de la topología de red, alcanzando de esta manera las ventajas de la virtualización de máquinas también para el ámbito de red. En esta entrada se describen los pormenores de estructuras Overlay destinadas a la virtualización de redes dentro de los Data Centers, prestando especial atención a las VXLAN"

En esta entrada se describirá la necesidad de los Overlay Networks destinados a la virtualización de redes en entornos Multitenant. Tras ello se procederá a detallar las posibles arquitecturas que se pueden lograr mediante estas técnicas, remarcando sus ventajas y algunas implicaciones negativas de su adopción. 

Por último se revisarán algunas implementaciones de VXLANs de los fabricantes VMware y Nuage a modo de ejemplo, ilustrando las posibles topologías tratadas en los primeros apartados.

¿Por qué utilizar redes Overlay en los Data Centers Multitenant?

Los Data Centers Multitenant son aquellos que permiten proveer de un servicio y gestión aislados a varios clientes diferenciados, reservando a cada cliente un segmento de esa "partición" del Data Center. La separación de estos clientes, también llamados tenant, requiere un alto grado de aislamiento, ya que los datos de uno nunca debería poder ser visibles desde otro tenant. A parte de que el tráfico de un tenant nunca deba ser expuesto a otro, también será necesario que cada tenant haga un uso indiscriminado de ciertos recursos (como por ejemplo las IPs) sin que sea necesario tener en cuenta las asignaciones de otros tenant.

Gracias a las plataformas de virtualización, el uso de los Data Center Multitenant se ha visto incrementado . Actualmente no son solo encontrados en grandes proveedores de servicio, sino que también son utilizados internamente en algunas compañías para, por ejemplo, asignar a cada departamento un tenant diferente y de esa manera proveer de los servicios IT de una manera controlada y segura.

Cada tenant posee una división del Data Center y para ello dispondrá de una serie de recursos de almacenamiento y computación, los cuales son fácilmente virtualizables o divisibles a día de hoy. Pero existe un problema a la hora de completar esta arquitectura, la virtualización de la red del Data Center (balanceo, firewall, routing, etc...), ya que, aparte de la separación lógica, también hay que tener en cuenta que la manera en la que están implementadas estas redes virtuales debe ser transparente a los tenant, por lo que este no debe percibir diferencia en su rendimiento, utilización, seguridad, etc, con respecto a las redes físicas.

Tradicionalmente, una forma de proveer "redes virtuales" ha sido mediante el despliegue de arquitecturas "Overlay". El concepto de Overlay Network (redes superpuestas en español) es ampliamente utilizado en proveedores de servicio y empresas con redes de gran tamaño. La idea es crear redes "encima" de otras redes ya creadas, habitualmente tunelizando enlaces entre los nodos Overlay sobre una infraestructura de red establecida, llamada Underlay, mediante la encapsulación de paquetes.

Para clarificar el concepto de redes Overlay se muestra este esquema (obtenido de esta web):

Figura 1 - Ejemplo de Overlay Networks

En entradas anteriores del blog, ya se han comentado otros protocolos de encapsulación utilizados en el Data Center (ver "TRILL, SPB, VXLAN, NVGRE, EVI, OTV, EVB, VNTag: nuevas soluciones para antiguos problemas") mediante los cuales se conseguían Fabrics de redes y otras soluciones Overlay, resolviendo problemas como los siguientes:

• Interconexión de DCs o Data Center Interlink (DCI): En este grupo se encontrarían EVI y OTV que encapsulan en GRE . También con el nuevo protocolo Ethernet-VPN (EVPN)

• Sustitución de Spanning-Tree Protocol (STP): como el protocolo SPB con encapsulación Q-in-Q o MAC-in-MAC, y TRILL que añade una cabecera de 16bits

• Incremento de la escalabilidad: con 802.1ad (Q-in-Q) y 802.1ah (Mac-in-Mac)

• VPNs: donde se podrían encontrar MPLS y  BGP/MPLS IP-VPN

• Optimización de caminos: como LISP, que crea túneles utilizando una cabecera de 36bytes, o el protocolo  VDP (Virtual Station Interface Discovery Protocol), mediante el cual se advierte a la red de los movimientos de las máquinas virtuales

No obstante, los protocolos Overlay que van a ser tratados en esta entrada han sido especialmente diseñados para ser utilizados en una arquitectura Multitenant en los Data Centers, y por tanto intentando resolver  una serie de problemas adicionales que se presentan en estos entornos:

• Escalabilidad de las tablas de forwarding, segmentos de red y direccionamiento: El alto número de máquinas virtuales que puede albergar una infraestructura Cloud multitenant implica que los valores máximos de direcciones MAC, segmentos de red y direcciones IPs disponibles dentro del Data Center puedan llegar a ser alcanzados, el ejemplo más recurrente son el máximo de 4094 VLANs permitidas, por lo que se necesita aumentar estos valores de algún modo.

• Flexibilidad de movimientos de máquinas virtuales: Cuando una máquina virtual se mueve, necesita conservar los parámetros de red, como son su dirección MAC y dirección IP, aunque el movimiento se produzca entre dos Data Centers diferentes.

• Facilidad de reconfiguración de red: En las plataformas Cloud los cambios de configuración necesitan ser rápidos y fáciles de abordar, incluso la creación de nuevos segmentos de red, por ello los protocolos deben facilitar el aprovisionamiento dinámico y las modificaciones de los parámetros de red de forma ágil.

• Separación lógica de redes de cada tenant: Cada tenant inidividual deberá tener acceso a los recursos de red así como a su configuración, pero tendría que estar aislado del resto de redes.

Algunos de estos problemas pueden ser resueltos de forma individual con los protocolos Overlay mostrados al comienzo. Un ejemplo es cuando se habla de escalabilidad. En este caso concreto se podría utilizar 802.1ad (Q-in-Q), el cual fue diseñado para proveedores de Internet que quisiesen dar a sus clientes la posibilidad de gestionar sus propias VLANs en las conexiones que les adquirían: Cada cliente iría en una VLAN "padre" que estaría en el dominio del proveedor, que transportaría a su vez dentro de ella las 4094 VLANs de ese mismo cliente, que podrían ser gestionadas de forma independiente por el cliente. Es fácil ver que este protocolo posibilitaría el uso de un mayor número de VLANs diferentes (16 millones), ya que podría haber 4094 VLANs de cliente encapsuladas en cada una de las 4094 VLANs del proveedor.

Aunque algunos de estas problemáticas como el anterior puedan ser resueltas de forma aislada por protocolos puntuales, lo que realmente se busca con los protocolos Overlay destinados a las plataformas virtuales (llamados en alguna ocasión "Host based Overlay Network Protocols" ), y presentados a continuación,  es un medio de resolver a la vez los tres problemas anteriores, mediante la creación de "redes virtuales" dentro del Data Center, para poder obtener la separación lógica necesaria en los entornos Multitenant.

Se podría pensar que aparte de los Overlay Networks, tratados en esta entrada, existen otros medios para la creación de pseudo redes virtuales: las VLANs, para segmentar los dominios de broadcast y los VRFs, para dividir las tablas de enrutamiento de un dispositivo. Hay que tener en cuenta que la posibilidad de segmentación de los dominios de broadcast por parte de las VLANs, también trae consigo la posibilidad de reutilizar direcciones MAC lo cual podría verse como una mejora de la escalabilidad en este sentido. Por su parte, los VRFs, permiten reutilizar los direccionamientos IP al posibilitar tener varias tablas de rutas aisladas en dispositivos compartidos.

Si se suman las dos técnicas (VLAN + VRF) se puede llegar a disponer de una red virtual (ya que se segmentan y aíslan las direcciones MAC e IP) pero este acercamiento tiene dos problemas:

• Se mantiene el número máximo de VLANs en 4094, aunque existen otras técnicas para solventar esto (como por ejemplo con otra técnica Network-based Overlay: "Q-in-Q").

• Cada VRF necesita una capa de control independiente para mantener su tabla de enrutamiento, con lo que se necesitarán múltiples planos de control independientes entre sí.

En los protocolos Overlay presentados más abajo se resuelven todos estos problemas, diferenciando cada red virtual con un identificador ("Virtual Network ID" o VNID) único:

• Dentro de cada red virtual, identificada univocamente, se podrán utilizar los 4094 tags de VLANs, al ser estos diferenciados de los 4094 tags que se puedan utilizar en otra red virtual, la cual tendría otro VNID diferente. Esto daría un número posible de VLANs iguales al número de VNID por 4094 posibles VLANs. Si se toma un ID de 12 bits para el VNID, se tendrá 4094 * 4094 = 16,760,836 segmentos de red diferentes.

• Con la distinción mediante un identificador único (VNID) se puede hacer que un solo plano de control gestione todas las redes virtuales, ya sea desde el punto de vista L2 o L3.

Introducción a los Overlay networks para multitenancy

La arquitectura de  Overlay Networks viene a implementar redes virtuales aisladas que serán utilizadas por las máquinas virtuales de cada Tenant. 

Las redes virtuales se conforman creando una serie de túneles que transportan los paquetes de cada red Virtual por la red Underlay. Este concepto no es nuevo, y funcionaría del mismo modo que otras tunelizaciones de red, es decir, los elementos de red intermedios (Underlay) no son conscientes del paquete original, si no que revisan sus tablas de enrutamiento atendiendo al destino y otros valores de las cabeceras de red incluidas por el dispositivo de red que encapsuló el paquete original. 

En este esquema se muestra un ejemplo de las redes Overlay en el mundo virtual a la hora de crear las redes virtuales Multitenant (obtenido de esta web):

Figura 2 - Overlay  para entornos virtuales Multitenant

La implementación de la arquitectura se basa en estos componentes (siguiendo la nomenclatura de este documento):

Figura 3 - Componentes para la generación de las redes virtuales Overlay

El elemento nombrado como "Overlay module" realizará las funciones de encapsulación/desencapsulación, es decir, será el punto terminador del túnel creado para formar el Overlay de la red virtual. Este terminador tuneliza las conexiones de cada red virtual, o Virtual Network Instance (VNI). Cada VNI tendrá asociado un VNID que el Overlay Module utilizará para crear las encapsulaciones. Las máquinas virtuales se conectan a la red virtual (VNI) mediante los Virtual Attachment Points (VAP), lo que serían las VNICs en los entornos virtuales tradicionales.

Es conveniente que el Tunelizador esté contenido en el propio Host hipervisor, ya que de no ser así, se debería recurir a algún protocolo como VDP (VSI Discovery and Configuration Protocol ), BGP u otros, para trasladar el estado de las VNICs hasta él, ya que debe estar al tanto de los cambios de localizaciones y estado de las diferentes VNICs a lo largo de la plataforma virtual para que el plano de control del Overlay pueda decidir cómo enrutar los paquetes dentro de la red virtual. Lo habitual es que el Tunelizador sea parte del propio switch virtual.

Para comprender mejor el modelo, se revisará el comportamiento de estos Overlay desde el punto de vista del plano de control y el plano de datos.

Plano de control

Las redes virtuales han de poseer un plano de control ("Control Plane") que se encargue de conocer la localización de cada una de las interfaces de las máquinas virtuales dentro del/los Data Centers, de modo que sepa dónde enviar los paquetes para poder alcanzar el destino dentro de esa red virtual.

El plano de control se encarará, al menos de los siguientes puntos:

1. Completar las tablas de enrutamiento/flujos que utilizarán los tunelizadores para  conocer el tunelizador destino al que enviar los paquetes encapsulados
2. Mecanismos para gestionar los paquetes enviados desde un origen a varios destinos a la vez (broadcast y multicast) dentro de la red virtual
3. Un modo de permitir compartir información con los hipervisores para conocer qué VMs corresponden a qué red virtual, así como su incorporación y eliminación de su asociación a estas

Los planos de control de las redes virtuales pueden estar construidos de dos modos:

• Plano de control basado en auto-aprendizaje

Este tipo de plano de control está basado en el auto-aprendizaje de las localizaciones de las máquinas virtuales por parte de los terminadores de túneles. 

En este grupo se encontrarían, por ejemplo, las implementaciones en las que los terminadores de túneles, cuando no conocen el tunelizador destino del paquete, utilizan grupos multicast para hacer un broadcast "controlado" por toda la red Underlay (cada red virtual estaría vinculada a un grupo multicast), y de este modo llegar a todos los demás terminadores, y por tanto a las máquinas virtuales que se encuentran tras ellos.

En el siguiente esquema se muestra el ejemplo de Overlay VXLAN basado en el concepto de vCNS de VMware, el cual dispone de un plano de control con auto-aprendizaje (el cual realiza el Virtual Distributed Switch):

Figura 4 - Esquema de conexión L2 con VXLAN vCNS de VMware

• Plano de control basado en directorio

En este apartado se encontraría, por ejemplo, la implementación de VXLAN de VMware con NSX. En estos despliegues, existe un elemento adicional denominado "Controlador" que monitoriza de manera centralizada los estados y las localizaciones de las máquinas virtuales a lo largo de la plataforma, recopilando estos datos e incluyéndolos en un "directorio", el utiliza para crear una tabla de flujos, la cual exporta a cada uno de los terminadores de túneles Overlay con el fin de que estos envíen los paquetes encapsulados de la manera deseada.

Estos controladores son capaces de alterar los enrutamientos de los flujos en los terminadores de túneles Overlay, atendiendo a la información contenida en su directorio, de manera que cada terminador no se necesita hacer uso de los paquetes multicast para conocer la localización de las máquinas, con las ventajas de reducción de consumo de recursos en la plataforma que ello conlleva.

Las modificaciones de forwarding sobre los elementos tunelizadores del Overlay en algunas implementaciones se pueden realizan con protocolos como Openflow:

Figura 5 - Esquema de conexión con VXLAN con plano de control basado en directorio

Estos Controllers también pueden utilizar protocolos como OVSDB para configurar los elementos Terminadores de las redes Overlay.

A su vez, si existiesen varios controladores, estos podrían ser "federados", de manera que compartan entre sí la información de sus directorios. Para realizar la federación, existen implementaciones que utilizan protocolos como BGP o ISIS entre los controladores. Esto es útil, a parte de por la escalabilidad, a la hora de garantizar la alta disponibilidad de los Controladores, ya que se pueden repartir entre diferentes Data Centers:

Figura 6 - Federación de controladores

La federación de Controladores es necesaria si lo que se busca es una arquitectura flexible y escalable, o si se desea comunicar dos despliegues diferenciados.

Plano de datos

En el plano de datos se puede hacer la distinción entre el Overlay y el Underlay.

El Underlay network debería ser transparente para los elementos conectados a la red virtual (Overlay Network), no obstante hay que tener en cuenta una serie de consideraciones, algunas de ellas dependientes del tipo de implementación de Overlay que se quiera desplegar. Por ejemplo, ya que se encapsula el tráfico de las redes virtuales, añadiendo bytes a la cabecera, la red Underlay deberá permitir una MTU mayor de la típica de 1500 bytes. A parte, si se desplegase una solución de plano de control distribuido basado en la utilización de multicast (el ejemplo mostrado antes), también se deberá permitir IGMP en la red L2 del Underlay y, en el caso de que la conexión entre los terminadores de túneles Overlay tuviese que ser L3, también se debería configurar el enrutamiento Multicast (ver "Encaminamiento Multicast").

Descontando lo anterior, lo que siempre ha de asegurar la red Underlay, es que existe conectividad entre los terminadores de túneles Overlay, ya sea L2 o L3.

Para crear las redes virtuales, el tráfico del Overlay Network debe ser convenientemente marcado y encapsulado. Para añadir el identificador VNID en el tráfico, la trama original (sin el VNID) es encapsulada por el primer dispositivo de red (OVS, vSwitch, etc). Este dispone de una "tabla" en la que figuraría el dispositivo destino (que debe desencapsular el tráfico) al que le enviará el paquete encapsulado a través de la red tradicional que los conecta. 

Para comprender un poco mejor el funcionamiento, se muestran a continuación un par de ejemplos de flujos de una VM-A de un Host a otra VM-B de otro Host en la misma red virtual. 

En el primer ejemplo se exponen los pasos a la hora de realizar la conexión cuando se utiliza la implementación de de VXLAN con vCNS (Virtual Cloud Network & Security) de VMware, es decir, con plano de control basado en auto-aprendizaje en el terminador de túneles (VTEP):

1. La máquina virtual A (VM-A) desea enviar un paquete a la máquina virtual B (VM-B) que se encuentra en la misma red virtual, pora ello envía una petición ARP para poder resolver la dirección MAC de la VM-B 
2. El dispositivo de red local al Host que termina los túneles (VTEP) captura ese paquete.  En este punto hay dos variantes, una primera en la que el terminador de túneles funcionase como proxy ARP, en cuyo caso respondería a la petición de la VM-A con su propia MAC, o un segundo caso en el que podría reenviar el paquete hasta el destino final (VM-B) para que fuese esa máquina quien respondiese. Para el ejemplo actual se reenvía la petición ARP, es decir, sin funcionamiento proxy ARP.
3. El VTEP local (Terminador 1) buscará en su tabla de redes virtuales para saber a que otro terminador de túneles ha de enviar el paquete, lo cual dependerá de en qué Host se encuentre la VM-B. De no disponer de la información  en la tabla (pensemos que en este ejemplo se parte de cero), hará uso de la implementación de su plano de control y lanzará paquetes multicast al grupo IGMP vinculado a la VXLAN.
4. El tráfico multicast llegará al terminador remoto (Terminador 2), el cual  lo desencapsula y lo envía a las máquinas virtuales  que se encuentra local a ese Host
5. El paquete ARP enviado por la VM-A llega desencapsulado a la VM-B habiendo sido tunelizado por la red tradicional por los Terminadores 1 y 2. La VM-B responderá a la petición ARP.
6. El paquete de respuesta llegará al VTEP 2, el cual conoce la situación de la VM-A (ya que recibió el paquete de petición), por lo que envía directamente la respuesta al Terminador 1
7. El Terminador 1 desencapsula y envía el tráfico de vuelta a la VM-A
8. La VM-A comienza a enviar el tráfico directamente a la VM-A ahora que ha resuelto su MAC mediante ARP
9. El VTEP local a la VM-A recibe el tráfico, busca en su tabla y lo encapsula con destino el VTEP 2
10. El VTEP 2 desencapsula y le hace llegar el tráfico a la VM-B

En el segundo ejemplo se presenta el mismo caso pero con una implementación del Fabricante Nuage, basada en planos de control localizado en Controllers, la cual no utiliza multicast para enviar los paquetes cuando no sabe específicamente el destino, con las ventajas de ahorro de recursos que ello conlleva:

1. La máquina virtual A desea enviar un paquete a la máquina virtual B que se encuentra en la misma red virtual, por ello envía una petición ARP para poder resolver la dirección MAC de la VM-B 
2. El dispositivo de red local al Host que termina los túneles (en este caso el VRS, la implementación propia de Nuage del Open vSwtich) captura ese paquete. 
3. El VRS buscará en su tabla de flujos qué hacer con el paquete. La implementación de Nuage pre-provisiona todos los flujos desde el primer momento (mediante Openflow desde el Controller), por lo que directamente responde el ARP a la máquina virtual VM-A, es decir, hace de proxy ARP.
4. La máquina virtual comienza a transmitir el tráfico a la VM-B
5. El VRS consulta su tabla de flujos y envía los paquetes encapsulados directamente al VRS 2, que se encuentra en el Host donde reside VM-B
6. El VRS desencapsula y envía el paquete a VM-B

Para realizar este tipo de conexión, los dos equipos han de estar dentro de la misma red virtual, por lo que si se quisiese conectar por L2 una máquina virtual dentro de una red virtual, con un dispositivo físico externo (e incluso un DC remoto con conexión L2) se necesitaría un elemento que realizase las tareas de gateway L2, es decir, un elemento físico terminador de los túneles Overlay que permita la conversión de los paquetes entre las redes tradicionales y las virtuales. 

En el mercado ya se puede encontrar switches Hardware que pueden actual como terminadores de los túneles para este tipo de redes Overlay (sobretodo VTEPs para el protocolo VXLAN), lo cual permite que los elementos de la red virtual puedan comunicarse directamente con dispositivos no virtualizados:

Figura 6 - Gateway VXLAN L2

En el caso de una comunicación entre dos redes virtuales o con las redes tradicional, se deberá añadir la funcionalidad de interconexión de dichas redes virtuales aisladas, es decir, el flujo de este tráfico debe ser gestionado por un elemento que sea capaz de desencapsular el tráfico de la red virtual e inyectarlo en una red virtual diferente o directamente en la red tradicional. Este  servicio de interconexión de redes podría ser acompañado de otros servicios adicionales como firewall o balanceadores de carga, los cuales también podría ser parte del servicio de networking del Host, junto con el servicio terminador de túneles para las redes virtuales.

A tal efecto se tienen varias opciones de gateway L3 para las redes Overlay: una máquina virtual especializada, un servicio del propio Host (normalmente contenido en el vSwitch) o un Hardware físico externo.

A continuación se presenta el ejemplo de la utilización de gateway L3 en una máquina virtual especializada para redes Overlay VXLAN (el concepto sería igual en NVGRE o STT). 

En este primer esquema se puede ver cómo el flujo de la conexión L2 sigue siendo el mismo que cuando no se disponía del gateway:

Figura 7 - Gateway VXLAN L3 en máquina virtual - Conexión entre misma VXLAN

Al disponer de esta máquina virtual que hace las vedes de gateway L3, se permiten también los flujos entre diferentes VXLAN:

Figura 8 - Gateway VXLAN L3 en máquina virtual - Conexión entre diferentes VXLANs

Así como también de VXLAN hacia VLANs tradicionales:

Figura 9 - Gateway VXLAN L3 en máquina virtual - Conexión con redes no VXLAN

Por otro lado, en este ejemplo se presenta la opción de gateway L3 como un servicio de Host/vSwitch distribuido:

Figura 10 - Gateway VXLAN L3 como servicio distribuido

Por último, he aquí un ejemplo de gateway L3 en Hardware:

Figura 11 - Gateway VXLAN L3 en Hardware

De utilizarse una máquina virtual especializada (como los vShield Edges de VMware) o un Hardware físico, la función de terminador de túneles no podría estar distribuida a lo largo de todos los Host, lo cual puede inducir a que una conexión entre una máquina conectada a una red virtual, y otra máquina que se encuentra conectada a las redes tradicionales (u otra red virtual), realice un camino "no-optimo", para llegar de un extremo al otro, ya que se debe pasar por el terminador de túneles como paso intermedio. El comportamiento de caminos no óptimos es especialmente preocupante cuando los Host que albergan las máquinas virtuales que hacen uso de una red virtual se encuentran en diferentes Data Centers. 

He aquí un ejemplo de una máquina virtual de una VXLAN que quiere conversar con otra máquina del mismo Host pero que se encuentra en otra VXLAN cuando la máquina virtual gateway L3 se encuentra en un segundo Host (el cual podría localizarse en otro Data Center):

Figura 12 - Gateway VXLAN L3 en máquina virtual - Caminos de comunicación no óptimos

Como se puede imaginar, es preferible buscar soluciones distribuidas a lo largo de los Host, debido a que se podrá obtener siempre una mayor flexibilidad en el crecimiento de la plataforma virtual sin repercutir en el rendimiento de las redes virtuales.

Ya se ha revisado en anteriores entradas del Blog, la problemática de los despliegues de redes extendidas a lo largo de varios Data Centers (ver "Arquitectura MultiDataCenter – Extensión de red L2") así como también se repasaron las restricciones en la utilización de Overlays para realizar una extensión L2  en "TRILL, SPB, VXLAN, NVGRE, EVI, OTV, EVB, VNTag: nuevas soluciones para antiguos problemas", donde se expuso cómo la utilización de Overlay networks para realizar DCI (Data Center Interlink) no cumplía con varios de los requisitos básicos de este tipo de enlaces, como por ejemplo que no evitan la extesión de los problemas potenciales de un DC al otro, al no tener métodos de contención de errores y aislamiento de ellos entre los diferentes DCs , o que no contiene el flooding de paquetes ni minimiza el efecto de los broadcast entre los DCs (cosa que sí que hacen protocolos como VPLS, EVI o OTV).

Además, sumado a esto hay que añadir los problemas que anteriormente se han tratado, como la necesidad de multicast (en algunos casos) y la modificación de las MTUs para evitar la fragmentación, elementos muy difíciles de manejar cuando de conexiones WAN se tratan (sobretodo si son manejadas por ISPs).

Si bien lo visto entonces sigue siendo válido, lo cierto es que existen dos posibles soluciones a la hora de utilizar los Overlay Networks extendidos a lo lago de los Data Centers:

• Utilizar una tecnología específica en el tramo de DCI que conecte con los diferentes Overlays de cada DC

• Obtener una implementación de Overlay que solvente las carencias del Overlay tradicional en los enlaces DCI

Para el primer caso, se puede utilizar una tecnología de extensión L2 como VPLS, EVI, o las nuevas EVPN y hacer que los routers de frontera puedan distinguir qué paquetes corresponde a qué Overlay. Un ejemplo puede verse en este documento, donde se encuentra descrita una implementación en la cual cada Data Center dispone de sus redes Overlay con VXLAN, y para conectar los DCs se dispone EVPN, conservando la topología de VXLAN. En este esquema, EVPN solventa las carencias de la VXLAN, con lo que la problemática de la extensión L2 entre Data Centers estaría resuelta.

Para ilustrarlo, se presenta el siguiente esquema, en el cual existen dos Overlays VXLAN diferentes (Los Host 1, 2 y A en una VXLAN y los Host 2 y B en otra diferente). La topología se conserva por el DCI pero los flujos se envía mediante EVPN o VPLS. La conversión VXLAN-EVPN se realiza en los PEs que conectan a la MPLS:

Figura 13 - VXLAN en local y DCI con EVPN

El segundo caso, la implementación desplegada debe resolver por si misma los problemas que se han señalado. El más importante es la restricción de los broadcast y multicast de una red L2 entre DCs, es decir ,no enviar broadcast o multicast desde un DC a otro si no es estrictamente necesario, y aún así se debería reducir el número de estos broadcast mediante técnicas como ARP proxy. 

En esta línea también se debería controlar el envío del flooding de paquetes debido a los destinos unicast desconocidos, por ejemplo con la implementación tradicional de VXLAN de VMware, cuando se tiene un destino unicast desconocido, se envían paquetes a un grupo multicast en el que se encuentran todos los VTEPs de la red virtual, y este tráfico debería ser limitado en los límites del DC.

Se está trabajando en las actuales implementaciones de Overlays para solventar estos problemas y poder decir así que estas redes virtuales suplen la necesidad de multitenancy y de extensión de redes L2 a la vez (aunque siempre podría ser un problema la modificación de la MTU de los paquetes debido a la encapsulación). 

Las modificación de los protocolos que utilizan el auto-aprendizaje para su capa de control, es algo más complicado que los cambios en las arquitecturas en las cuales se utiliza un plano de control en las que el Controller inyecta los flujos en redes Openflow compuestas por los terminadores de túneles Overlay, ya que, al ser en esencia redes programables SDN (ver "Ideas básicas sobre Software Defined Network (SDN)"), se puede realizar un desarrollo Software que haga que el tráfico de la red se comporte de la manera que se desee (sin multicast o broadcast inecesarios).

Para obtener un buen resultado en esta último tipo de implementación (Overlay regido por Controller), es necesaria la federación entre los Controllers del modo que antes se ha visto, para que todos ellos conozcan la localización precisa de todas las máquinas virtuales de la red virtual.

Protocolos actuales

En la actualidad, los tres principales protocolos de Overlay pensados para entornos virtualizados Multitenancy son:

• VXLAN (impulsado por VMware, Cisco y Broadcom)
• NVGRE (impulsado por Microsoft)
• STT (propiedad de Nicira, ahora parte de VMware)

Las mayores diferencias entre ellos vienen dadas en el modo de encapsulación. VXLAN utiliza encapsulación en UDP, frente al GRE de NVGRE y a un pseudo-TCP de STT. 

Esta diferencia es muy significativa ya que, por ejemplo, gracias a que VXLAN está encapsulado en UDP, podrá ser distribuido en los bondings de NICs, mientras que esto es  mucho más complicado con el encapsulamiento GRE; o traspasar un firewall sin que este deseche implicitamente el tráfico, caso posible con STT, al utilizar una encapsulación que es parecida a TCP pero no es puro TCP.

Otra diferencia entre ellos es la longitud de los VNID. En VXLAN y NVGRE se utilizan 24bits (con lo que se obtienen los 16 millones de redes virtuales vistas antes), mientras que con STT se usan 32bits, lo cual aporta un mayor número de redes virtuales pero afecta al coste de los Hardware que lo soportan.

Debido al motivo de la mayor capacidad de balanceo en el Underlay de los paquetes con encapsulación VXLAN, frente a los NVGRE o STT, y a que en el mercado ya existen NICs hardware que pueden realizar el offload del encapsulamiento VXLAN (liberando la CPU del Host a la hora de realizar este trabajo), es probable que VXLAN tomará más fuerza que sus competidores.

Ventajas y limitaciones de los Overlay Networks

Durante la introducción a los Overlays para multitenancy ya se han ido desvelando algunas ventajas. Aquí se hace un repaso completo a ellas así como a las limitaciones encontradas en el uso de Overlays para la creación de redes virtuales Multitenant.

Ventajas
Estas son algunas de las principales ventajas:

• Escalabilidad y flexibilidad

Las redes Overlay permiten crear un gran número de pequeños segmentos aislados de red más allá de los 4094 VLANs lo que permite arquitecturas Multitenancy escalables.

También se gana en flexibilidad, ya que los administradores de la plataforma de visualización son capaces de crear, destruir y modificar por ellos mismos de forma ágil las redes virtuales que sus máquinas virtuales utilizan, ya que no existe necesidad de preconfigurar las VLANs a utilizar en todas las localizaciones de red donde podrán residir las VMs, proporcionando conectividad L2 independientemente del lugar donde estas se encuentren.

• Conexión L2 de las redes virtuales con conexiones L3 del Underlay

Las redes Overlay desvinculan el servicio de red proporcionado a las redes virtuales de las tecnologías utilizadas en la red física Underlay, y permite extender dominios L2 a lo largo de conexiones Underlay L3.

En este punto hay que volver a recordar las carencias vistas antes a la hora de controlar los paquetes multicast/brodcast que tienen algunas implementaciones de redes Overlay cuando pretenden ser utilizadas como DCI para conexiones L2 entre Data Centers.

Las extensiones de los dominios L2 son muy necesarias en los entornos virtualizados, para poder permitir los movimientos de máquinas virtuales sin tener la necesidad de cambiar la IP que tienen configurada, pero hay que evitar que esta topología afecte a la alta disponibilidad y el rendimiento de cada uno de los Data Centers.

• Posibilidad de solapamiento de direccionamientos

Al haber creado redes virtuales aisladas mediante los Overlay, es posible reutilizar tanto las direcciones MAC como las direcciones IPs entre diferentes tenants.

También, al estar tunelizado el tráfico de las redes virtuales del Overlay, tanto las direcciones MAC como las direcciones IPs de las redes virtuales no son visibles en la red Underlay, por lo que también podrían repetirse entre el entorno Overlay y Undelay.

• Separación de roles y responsabilidades

Otro hecho ventajoso es que, debido a la independencia que existe entre las redes virtuales Overlay y las redes "tradicionales" Undelay, puede existir una división clara entre ambas responsabilidades de los departamentos IT, es decir, podría existir personal responsable de hacer que el el Undelay estuviese optimizado y siempre disponible, mientras que otro personal, o incluso cada Tenant, fuesen responsables de configurar sus propias redes virtuales, con direccionamiento, QoS, balanceo, etc.

Limitaciones y consideraciones

La utilización de Overlays no solo trae ventajas, también introduce algunas limitaciones, generalmente vinculadas a la utilización del encapsulamiento, que han de tenerse en cuenta. 

Muchas de estas carencias o limitaciones ya han sido solventadas por algunas de las implementaciones de los protocolos para crear redes virtuales Multitenant, aunque todavía hay casos que deben ser corregidos en el futuro.

• Pérdida de control y visibilidad general de la red

La independencia entre el Overlay y en Underlay, que antes se veía como una ventaja al producir una separación lógica de responsabilidades, también conlleva una pérdida de visibilidad y control total de la red en las comunicaciones entre máquinas virtuales.

Esto puede provocar que el personal de red, encargado del buen funcionamiento del Overlay, pierda la visibilidad de lo que está sucediendo en las redes virtuales tunelizadas, lo cual puede ser un problema a la hora de realizar troubleshooting.

Para obtener una visión general se ha de desgranar la información tanto del Overlay como del Underlay, por lo que, para solucionar esta problemática, es importante que en las implantaciones de redes virtuales mediante Overlay, se cuente con herramientas de monitorización conjunta de las redes Overlay y Underlay, que provean de una visión global del estado y configuración de la red.

• Control de seguridad de las redes virtuales desde el Underlay

El tráfico encapsulado de la red virtual no puede ser gestionado por dispositivos de la red Undelay, como firewalls, balanceadores, etc, por lo que no se puede conservar la arquitectura tradicional de seguridad y balanceo.

Para solucionar esta carencia, y hacer efectiva la seguridad de red, deben implementarse nuevos mecanismos dentro de la propia red virtual que realicen el filtrado de paquetes. También se podrían incorporar los firewalls físicos a las redes virtuales mediante la utilización de gateways L2, u obtener algún firewall que sea capaz de manejar las redes virtuales Overlay (próximamente  es posible que existan firewalls que soporten VXLANs nativamente).

A parte del filtrado, también se podríann incorporar elementos de balanceo o incluso otros procesos L3 como la realización de NAT.

Tambien existe el problema añadido de que los dispositivos firewall del Underlay pueden descartar el tráfico encapsulado del Overlay, al no poder determinar correctamente los tipos de cabeceras, como ya se comentó antes para el caso del protocolo STT.

• Requisitos del protocolo Overlay sobre el Underlay

Dependiendo de la implementación del protocolo Overlay, pueden existir varios requisitos que deban ser cumplidos por parte del Underlay. Algunos de ellos pueden ser problemáticos, como por ejemplo el soporte de Multicast end-to-end (necesario para la implementación tradicional de VXLAN de VMware como se ha visto antes), sobretodo si la conexión es L3, ya que se debería implementar protocolos de encaminamiento multicast (ver "Encaminamiento Multicast").

A parte, se ha de tener en cuenta que, por el mero hecho de utilizar encapsulación, se requerirá, sea cual sea el protocolo utilizado, un aumento de la MTU de la red, para evitar que los paquetes sean segmentados o descartados.

• El balanceo de los paquetes encapsulados en el Underlay puede no ser el óptimo

Este problema también se ha tratado anteriormente, y es que al realizar una encapsulación de los paquetes, se pierde la visibilidad de los parámetros de las cabeceras que son utilizados para balancear los flujos, tanto a nivel de agregado de enlace como de balanceo de sesiones en los equipos destinados a tal efecto.

Este problema del balanceo en los agregados de enlaces se minimiza algo con la utilización de VXLAN, ya que encapsula sobre UDP y este puede utilizarse para realizar un balanceo basado en el Hash de 5 variables (5-tupla).

• Aumento de los requisitos de CPU en el hipervisor

El encapsulado/desencapsulado es una tarea que requiere ciclos de CPU, con lo que, ya sea porque el tunelizador se encuentre desplegado en una máquina virtual especializada, o como parte del switch virtual, el Host hipervisor aumentará sus necesidades de CPU.

Para solventar este problema existen dos soluciones. La primera sería desplegar el tunelizador en un elemento externo (un switch Hardware compatible por ejemplo) y utilizar mecanimos como VEPA para forzar el tráfico a que pase por él (ver ""TRILL, SPB, VXLAN, NVGRE, EVI, OTV, EVB, VNTag: nuevas soluciones para antiguos problemas" y "KVM: Driver Macvtap para la conexión de VMs"). De esta manera la carga de CPU recaería sobre este elemento. 

Si no se utilizase VEPA parte de la gestión del tráfico se perdería y además se deberían utilizar VLANs internas u otro medio de segmentación de tráfico internamente entre el vSwitch y el elemento tunelizador, por lo que se perdería parte de la escalabilidad y flexibilidad que aportan las redes virtuales.

Otra solución, y posiblemente la mejor, es la utilización de NICs Hardware en el Host que sean capaces de realizar el offload de la encapsulación/desencapsulación de los paquetes del Overlay. Ya existen en el mercado varios fabricantes que han puesto en el mercado Hardware capaz de realizar este offload para las VXLAN ("aceleración VXLAN").

• Overhead del encapsulamiento

Otra consideración a tener en cuenta es que siempre que se aumenta el tamaño de la cabecera de un paquete, y esto es necesario cuando se encapsula, se pierde algo de eficiencia en el trasporte de datos por red, ya se transmitirán en porcentaje menos datos por paquete, al aumentar el porcentaje de bytes de la cabecera.

Esto no puede considerarse como un gran problema con el througput del que se dispone hoy en día en los Data Centers, pero es un punto más a considerar.

• Multicast, IPv6 y 802.1q  en las redes virtuales

No solo se ha de tener en cuenta que algunas implementaciones de Overlays requieren que se permita tráfico Multicast por el Underlay para enviar las peticiones broadcast de las VMs de la red virtual, sino que también se debe contemplar cómo se gestiona en tráfico multicast enviado/recibido por las propias máquinas virtuales dentro de la red virtual y desde la red virtual hacia el exterior.

El mayor problema en este punto es cómo gestionar el tráfico multicast generado dentro de una red virtual y que este pueda ser accedido desde las redes tradicionales. Para proporcionar este tipo de conectividad, se debe hacer una inyección del tráfico multicast de una red virtual en grupos multicast de la red tradicional, lo cual es un problema, ya que se pierde la escalabilidad necesaria en los entornos multitenant, pues todos los tenants compartirán los grupos multicast de la red Undelay.

Por otro lado, otro punto a considerar es la utilización de marcado 802.1q e IPv6 en las propias máquinas virtuales que pertenezcan a una red virtual. Esto también es un problema ya que podría no estar soportado.

• Necesidad de gateways L2 y L3 para integración de elementos externos al Overlay.

Como ya se ha mostrado, para poder conectar un elemento externo a la red Overlay, por ejemplo un fireweall o balanceador conectado a un switch tradicional, se necesitará un gateway L2 o L3.

Actualmente en el mercado hay Hardware que permiten realizar estar tareas, pero seguramente en el futuro los propios switches Hardware serán capaces de tratar encapsulaciones como la de VXLAN.

• Escalabilidad real

Otro concepto que hay que tener en cuenta es la escalabilidad real de estas arquitecturas Overlay ya que, en teoría, permiten implementar despliegues que alberguen sistemas multitenant masivamente, pero existen restricciones que en ocasiones no se tienen en cuenta.

Un ejemplo claro es el de la implementación de VXLAN de VMware por auto-aprendizaje que se ha visto, la cual depende de multicast en el Underlay para poder realizar los broadcast por la red virtual, y es que no todos los switches/routers Hardware soportan un número tan alto de grupos y árboles multicast sin sobrecargar su CPU, con lo cual, en este caso, en realidad no se llegará al nivel de escalabilidad que se plantea teóricamente con las VXLANs.

Otro aspecto restrictivo se tiene cuando la implementación de los gateway L3 del Overlay se encuentra contenida en una máquina virtual especializada. En estos casos, se ha de tener en cuenta que todo el tráfico inter-VXLAN y VXLAN-Underlay deberá ser procesado por estas máquinas, por lo que estas pueden llegar a ser un cuello de botella (ciclos de CPU de la VM y throughput de red). Para minimizar esto se deberán desplegar tantas máquinas de este tipo como sea posible.

Ejemplos de implementación (VXLAN)

A continuación se señalan de forma breve algunos ejemplos concretos de implementaciones VXLAN para ilustrar las arquitecturas generales vistas hasta ahora.

En primer lugar se presentarán las soluciones de VMware y más tarde la del fabricante NUAGE, con el motivo de ver las similitudes y diferencias entre ellas y a su adecuación a las topologías genéricas mostradas hasta ahora.

Los primeros ejemplos serán más específicos que los subsiguientes, ya que múltiples conceptos se repiten entre las arquitecturas  mostradas.

VMware

Si se desea crear un Overlay de redes virtuales con los productos VMware, se dispone a día de hoy de dos despliegues diferentes: usando vCNS o mediante NSX

Utilizando vCloud Networking & Security (vCNS)

El primer tipo es un ejemplo de arquitectura VXLAN sin Controller, es decir, con plano de control basado en auto-aprendizaje.

Este sería el esquema de esta implementación:

Figura 14 - Componentes de la solución VXLAN con VMware vCNS

El detalle de los componentes es el siguiente:

• vCloud Networking and Security Manager (vCNS)

Es un componente para la gestión centralizada de la red de la plataforma VMware (junto con un plug-in adicional en el vCenter). Desde este elemento se configuran los parámetros de las VXLAN, pero no realiza funciones propias de un Controller, y como se verá esta implementación hace uso del plano de control basado en auto-aprendizaje.

• vSphere Distributed Switch (VDS)

Para poder desplegar las VXLANs, en lugar de los vSwitches, se debe hacer uso de los switches virtuales distribuidos (VDS) debido a sus funcionalidades avanzadas. Al menos habrá un VDS por cada Clúster de VMware ESXi.

Se ha de tener en cuenta que también existen restricciones a la hora de elegir los posibles métodos de teaming de NICs, tan solo son permitidos LACP, agregado estático o failover, impidiendo el uso de “Virtual Port ID” o “Load Based Teaming”.

• VXLAN Tunnel End Point (VTEP)

El tunelizador (encapsulador/desencapsulador) de la VXLAN, llamado virtual tunnel endpoint (VTEP), a su vez se compone de estas partes:

1. Módulo del vmkernel dentro del VDS, donde se procesarán los paquetes
2. vmknic, que es la NIC que se utiliza para enviar el tráfico tunelizado, paquetes multicast, etc.
3. PortGroup de la VXLAN, para conectar los elementos de la red virtual

El VTEP dispondrá de una dirección IP (la de la vmknic) que utiliza para poder alcanzar los VTEPs remotos.

Como se ha mencionado, el plano de control es del tipo auto-aprendizaje, mediante el envío de paquetes multicast cuando no se conoce la dirección el Tunelizador (VTEP) destino, requiriendo configurar multicast en el Overlay, lo cual como se ha visto puede llegar a ser problemático, no solo por su configuración sino también por su escalabilidad.

Existe una posible mejora, con respecto a la obligación de utilizar multicast, y es haciendo uso de la funcionalidad contenida en los Cisco Nexus 1000v, los cuales se pueden configurar para utilizar paquetes unicast en lugar de multicast, cuando no conocen el destino de un paquete.

Se ha de recordar aumentar la MTU de la red Underlay, como mínimo a 1600 bytes.

• vCloud Networking and Security Edge Gateway (vShield Edge) 

La función de gateway L3 se realiza en una máquina virtual especializada (vShield Edge), lo cual también puede restringir la escalabilidad real. La máquina virtual se presenta en tres tamaños preestablecidos, atendiendo a la capacidad que sea necesaria, y  se puede configurar en alta disponibilidad, pero siempre en activo-pasivo.

La utilización de gateway L3 en una appliance también provoca posibles potenciales problemas de caminos no-óptimos en los flujos de las VXLANs. Por otro lado también es señalable que los vShield Edges no soportan protocolos de encaminamiento dinámico, pero pueden proporcionar servicios básicos de firewall y balanceo.

Utilizando NSX

La solución NSX es un despliegue de VXLAN con plano de control gestionado por un Controller. Ya que se trata de una topología SDN, además de permitir la fácil integración con elementos de terceros, proporciona varias ventajas considerables frente a la implementación VMware vCNS: Eliminación de la necesidad de Multicast para el plano de control,  posibilidad de forzado de flujos y posibilidad de enrutamiento distribuido en los Host. 

La primera de las ventajas es clara, sin la necesidad de multicast se facilita la gestión y mantenimiento de la plataforma, se obtiene un mayor rango de escalabilidad e incluso se podría utilizar switches y routers de menor coste.

También, al disponer de una arquitectura SDN, se posibilita el forzado de flujos de tráfico a través de elementos externos como firewalls, balanceadores (modificando las tablas de flujo inyectadas por Openflow tal y como se vio anteriormente), también nombrado como "Service Chain", gracias al cual se puede hacer pasar un paquete de red por todos los elementos que se deseen antes de alcanzar el destino final, aunque estos no se encuentren conectados in-line dentro de la comunicación (un ejemplo parecido se puede encontrar en "Ataques DoS y DDoS, prevención, detección y mitigación" donde se habla de la solución SDN de Radware para hacer pasar el tráfico por el Defense Pro).

Otra de las ventajas de la topología con Controller era la posibilidad de enrutamiento distribuido en los Host hipervisores. La implementación NSX permite dos tipos de arquitectura diferente con respecto a la localización del routing entre VXLAN. 

La primera es el routing centralizado. Este sería bastante parecido al caso del routing del despliegue vCNS, el cual se utiliza la máquina virtual Edge para realizar estas tareas.

La segunda arquitectura es el routing distribuido, de manera que las funcionalidades L3 se encuentren contenidas en los propios hipervisores (gracias a unos componentes adicionales). Como se ha visto en la primera parte de esta entrada, las implementaciones de VXLAN con routing distribuido aumentan la capacidad de escalabilidad de la plataforma y a la vez soluciona el problema de las rutas no optimas (hairpinning) cuando se desea realizar el routing de VXLANs.

Este sería un esquema con el routing centralizado tomado de VMware:

Figura 15 - VXLAN con VMware NSX y routing centralizado

Mientras que aquí se puede ver otro esquema con el routing distribuido, incluyendo los pasos en la decisión de enrutamiento (también tomado de VMware):

Figura 16 - VXLAN con VMware NSX y routing distribuido

En el siguiente esquema se presentan los componentes generales de la solución NSX dentro de los diagramas presentados en la primera parte de esta entrada (arquitectura de Overlay Networks con Controller):

Figura 17 - Componentes de la solución VXLAN con VMware NSX

Los componentes de la arquitectura NSX son:

• NSX Manager

Máquina virtual que proporciona un punto único de gestión de la arquitectura de redes virtuales, incluyendo un API REST para poder integrarse con productos externos, como VMware vCloud Automation Center, vCloud Director, HP VAN  y OpenStack (con el plugin de Neutron para NSX).

• NSX Controller

Otra máquina virtual que realiza la tarea de Controller, el cual es responsable de gestionar los módulos de switching/routing que se encuentran en los hipervisores (elementos vistos más adelante).

Gracias al uso de la arquitectura del plano de control basada en Controller,  se puede prescindir del uso de Multicast en la red Underlay, lo cual es bastante ventajoso en lo que respecta a la escalabilidad de la plataforma y facilidad de gestión, como ya se ha visto anteriormente.

Esta escalabilidad de ve aumentada gracias a la posibilidad de desplegar varios controladores federados y repartir la carga de trabajo entre ellos.

• NSX vSwitch

El switch NSX está basado en Open vSwitch, cuando el Host no es un ESXi, y en el vSphere Distributed Switch (VDS) cuando se utiliza un ESXi.

Al igual que en casos anteriores, este Switch proporciona funcionalidades avanzadas como Port Mirroring, NetFlow/IPFIX, QoS, LACP, etc.

• VXLAN Tunnel Endpoint (VTEP)

Igual al caso anterior (VXLAN con vCNS), es el componente encargado de  crear los túneles VXLAN entre los hipervisores.

• User World Agent (UWA)

Este es un componente del plano de datos instalado en los hipervisores adicional al VTEP. Su tarea consiste en establecer la conexión con el NSX Controller.

• NSX Edge

Máquina virtual que provee la capacidad de conectar las redes tradicionales (VLANs) con las VXLAN y las VXLAN entre sí.

Al igual que el Edge del despliegue vCNS, puede incorporar servicios adicionales, en este caso firewall, balanceo, VPN SSL, DHCP, etc...

Cuando se realiza un despliegue de routing centralizado el NSX Edge permite la interacción con protocolos de encaminamiento dinámico como BGP, OSPF e ISIS.

• Logical Router Control VM y Logical Router Kernel Module: Componentes adicionales para routing distribuido

Existen componentes adicionales necesarios si se desea realizar un despliegue de routing distribuido.

El primero de ellos es el Logical Router Control VM que, como su nombre indica, es una máquina virtual (también se puede desplegar en HA activo-pasivo) que se comunica con los routers del próximo salto en la red mediante OSPF o BGP e inyecta las rutas aprendidas en los hipervisores a través del NSX Cluster, con el que también se comunica.

El otro componente adicional es el Logical Router Kernel Module, el cual es el módulo del kernel del Host encargado de albergar la tabla RIB (routing information base) recibida desde el NSX Controller.

NUAGE

Para proporcionar un ejemplo de implementación de arquitecturas VXLAN diferentes a las aportadas por VMware, se presenta el ejemplos de la arquitectura del fabricante NUAGE. 

La solución de Nuage es parecida a la de NSX. Dispone de vswitches instalables en los hipervisores, los cuales encaminan siguiendo los flujos de paquetes marcados desde los Controllers y también cuenta con un elemento adicional desde el cual se gestiona toda la plataforma.

La separación entre este elemento de gestión y los Controller se realiza tanto en la solución NSX como en esta de Nuage debido a los diferentes requisitos de escalabilidad de cada uno de estos componentes, ya que en una plataforma grande serán necesarios múltiples Controllers federados para poder repartir la carga de trabajo, mientras que todos ellos pueden ser manejados por un elemento de gestión.

La arquitectura de Nuage, del mismo modo que NSX, también permite realizar configuraciones de Service Chain, obligando a ciertos tráficos de red a atravesar equipamiento aunque este no estuviese en el camino de la comunicación.

En el caso concreto de Nuage los elementos de la arquitectura son:

• Virtualized Services Directory (VSD)

Es un servicio contenido en una o varias máquinas virtuales, desde la cual se gestiona y monitoriza la plataforma y se aporta la API REST para integración con terceros.

Un punto adicional a comentar es que para poder proporcionar el HA del directorio se necesitan tres máquinas virtuales, no dos, ya que estas deben alcanzar un quorum de quién dispone del permiso de escritura en la base de datos.

• Virtualized Services Controller (VSC)

También en formato appliance virtual, provee del servicio de Controlador de la red SDN, inyectando los flujos que deben hacerse efectivos por los componentes VRS instalados en cada hipervisor.

Los Controllers pueden integrase mediante BGP con los routers frontera de redes MPLS con lo que los movimientos de máquinas podrían reflejarse casi instantáneamente. Los Controllers también utilizan BGP para conversar con otros Controllers Nuage y de este modo poder federarse. VMware NSX soporta hasta 4 Controloadores federados, mediante una sincronización efectuada por un protocolo propietario, pero Nuage, gracias a utilizar BGP, podría federarse con cientos de Controllers adicionales, lo cual es una clara ventaja de escalabilidad frente a la solución de VMware NSX.

El VSC utiliza Openflow para comunicarse con los VRS por un doble motivo. El primero de ellos es la propia inyección de las tablas de rutas, y la segunda es la gestión adicional que otros fabricantes realizan mediante OVSDB. Es decir, se utilizan instrucciones Openflow para ambas funciones.

A continuación pueden verse una relación de comunicaciones de los diversos componentes de la solución de Nuage:

Figura 19 - Comunicación entre componentes de la solución VXLAN de Nuage y el Controller

• Virtual Routing & Switching (VRS)

En entornos propietarios (VMware, Hyper-v) es una máquina virtual (del mismo modo que el Edge en los entornos VMware) mientras que en KVM y XEN, en este momento, son servicios integrados en el kernel. 

El modelo de integración en el kernel de KVM y XEN cambiará en las siguientes releases ya que, según las estimaciones de NUAGE, esta no sería la arquitectura más eficiente, debido principalmente a dos motivos: que el kernel es preventivo (tienes interrupciones) y que en kernel no se pueden producir todas las aceleraciones de transmisión de paquetes que solo se lograrían en espacio de usuario.

El VRS también permite desplegar una arquitectura de routing distribuido de un modo similar al mostrado en la solución NSX.

• Virtualized Services Gateway (VSG)

Como componente adicional, Nuage ofrece un Hardware propietario que puede realizar las funciones de gateway L2 de VXLAN, permitiendo conectar a la VXLAN cualquier dispositivo físico "tradicional". 

Figura 18 - Componentes de la solución VXLAN de Nuage

Tal y como se ha mostrado, la arquitectura de Nuage es similar a la de otras soluciones de VXLAN con plano de control gestionado por Controller, pero añade variaciones en lo que respecta a las posibilidades de integración con elementos terceros, como routers MPLS, e incrementa las opciones de escalabilidad gracias a utilizar el protocolo BGP para federarse. 

También existe una ventaja añadida a ser un fabricante no directamente vinculado con los desarrollos VMWare, y es que permite la fácil integración de comunicaciones VXLAN entre máquinas residentes en hipervisores de varios tipos (XEN, ESXi, KVM, Hiper-V,...).