"Esta entrada presenta algunos de los nuevos protocolos que han aparecido, para dar solución a los requisitos que surgen habitualmente en las arquitecturas de Data Center, comparándolos con los que se vienen utilizando hasta ahora, pero dejando a un lado las soluciones puramente SDN"
En lugar de ir enumerando los diferentes protocolos y explicándolos cada uno por separado, se expondrán una serie de problemas comunes a los Data Centers, y se mostrarán las soluciones que se vienen implementando y, a continuación, los nuevos protocolos que pueden ser utilizados.
No se hace mención de la utilización de SDN (ver entrada en el blog sobre la introducción al Software Defined Network) ya que, aunque solucionaría todos y cada uno de los siguientes problemas de un modo sencillo, es un cambio total del paradigma del envío tradicional de paquetes. A pesar de ello, también es cierto que la arquitectura SDN se está empezando a implementar para dar soporte adicional a elementos mostrados en esta misma entrada, como en la creación automatizada de los túneles dentro de los overlay networks, como se verá más adelante.
Tampoco se abordan los conceptos de Network Functions Virtualization ( NFV ), ya que su único cometido es el de virtualizar los componentes de red para introducirlos dentro de algún hipervisor, del mismo modo que se haría con una máquina virtual, y no el de solventar los problemas que aquí se muestran mediante la introducción de un nuevo protocolo.
Tampoco se abordan los conceptos de Network Functions Virtualization ( NFV ), ya que su único cometido es el de virtualizar los componentes de red para introducirlos dentro de algún hipervisor, del mismo modo que se haría con una máquina virtual, y no el de solventar los problemas que aquí se muestran mediante la introducción de un nuevo protocolo.
De los protocolos mostrados, habrá algunos casos en los que dos protocolos diferentes se solapen en funcionalidades, o que directamente solventen un problema de diferentes maneras.
Por otro lado, algunos de los protocolos mostrados tienen una misión similar dentro del Data Center, y se podría decir que son parejos, con la salvedad de que uno es propietario y otro es el estándar.
A continuación se comienzan a mostrar algunos de los requisitos más comunes a la hora de diseñar las arquitecturas DC de hoy en día.
Optimización del uso de enlaces
La optimización tratada no es la correspondiente a la utilización del ancho de banda de cada uno de los enlaces, la cual se realizaría mediante QoS, si no la utilización de todos los enlaces disponibles para la comunicación de datos (elección del camino de los paquetes a nivel 2).
Normalmente se utilizan enlaces redundantes para conectar cada uno de los switches, para garantizar la alta disponibilidad, pero no siempre se puede hacer un uso eficiente de todos ellos, es decir, una utilización activo-activo de los enlaces, sino que se tiene que recurrir al uso en modo activo-pasivo.
La utilización de todos los enlaces es importante, más si cabe cuando los enlaces son costos, como por ejemplo enlaces 10G o enlaces inter-DC (suponiendo que les hemos conectado con DWDM, por ejemplo).
También existe el problema de los altos tiempos de convergencia tras una modificación/caída de uno de los enlaces, así como el grado de impacto que este acontecimiento tiene en la arquitectura global.
Para mejorar la utilización de los enlaces, ya que STP habilitará siempre un único camino (siempre será activo-pasivo), normalmente se utilizan dos métodos adicionales: la agregación de enlaces o la utilización de MST o PVSTP para poder crear diferentes árboles STP por cada VLAN o grupo de VLANs (en el caso de MST).
Otra solución adicional es la formación de agregados de enlace, también llamados PortChannels o EtherChannels. La utilización de todos los enlaces mediante la utilización de agregados de enlace era bastante restringida, ya que hasta hace unos años (se verá más tarde) no se podrían crear agregados de enlace distribuidos a lo largo de varios switches (el agregado tenía que inicial y finalizar en los mismos dos switches físicos), por lo que el único esquema válido era el siguiente (y para un máximo de 8 enlaces):
Aún así, si se incluía un tercer switch, los agregados ya no podrían verse como una solución para la optimización de utilización de caminos, por lo que había que recurrir a las correctas configuraciones de MST y PVSTP.
En la siguiente figura se presenta el típico esquema de tres switches conectados de manera redundante, en el cual STP bloquea uno de los enlaces para que no existan bucles L2:
En los últimos años han aparecido otros métodos, basados en la virtualización de componentes, para poder crear un único gran switch virtual y eliminar así los enlaces inter-switch:
En primer lugar aparecieron los stacks físicos de switches, los cuales se forman mediante un cable que une varios switches, con los que se permite la consolidación de varios dispositivos en
uno solo, de modo que este nuevo switch virtual resultante aparezca, desde
el punto de vista lógico, como un único equipo, tanto para su gestión como en
el sentido de funcionamiento, por lo que podrían formarse agregados terminados en Hardware físico distribuido (Multichasis Etherchannel o MEC).
De tenerse un único equipo (stack formando un switch virtual), o incluso dos (y agregados de enlace), se podría deshabilitar STP, ya que no habría posibilidad de bucles L2 (este despliegue conservaría el HA al tener varios equipos dentro del stack), por lo que se obtendría una ventaja añadida y es que no entrarían en juego los temporizadores de STP a la hora del recálculo de pesos en caso de un fallo en un enlace o switch, mejorando los tiempos de respuesta globales de la plataforma ante fallos.
Más tarde aparecieron los chasis virtuales, los cuales podrían formarse sin la necesidad de un cable especial, si no mediante conexiones Ethernet. Este es el caso del IRF en HP o el VSS en Cisco.
En caso de tener que conectar (al stack) switches que no soporten ninguno de estos protocolos, también se consigue una optimización de caminos, ya que se podrá formar un agregado de enlace distribuido entre diferentes terminaciones físicas entre el stack y el nuevo switch, al ser considerado el stack como un switch único. Puede verse un ejemplo de agregado distribuido en la siguiente figura:
Existe otra tecnología que permite la creación de agregados a lo largo de switches distribuidos, como el virtual PortChannel (vPC), mac-pinning, etc (ver entrada en el blog sobre configuraciones de vPC, mac-pinning, etc en Nexus 1000v), y diversos fabricantes han hecho sus propias implementaciones al respecto, con lo que se podrían utilizar todos los caminos aunque no se pudiesen formar stacks de switches propiamente dichos.
Resumiendo lo anterior, habitualmente para poder proporcionar servicio de red en HA, intentando optimizar la utilización de los enlaces, se puede:
Solución con nuevos protocolos ( TRILL / SPB )
Se han visto fundamentalmente dos métodos para la utilización de todos los caminos: configuración de MST/PVSTP o la creación de agregados y stacks.
Ya que en despliegues muy grandes no se podrán tener únicamente dos switches, aún realizando stacks, para poder formar entre ellos como mucho un agregado de enlace, se deberá contar con la configuración de STP para garantizar el HA.
Al tener habilitado STP se deberá contar con los retardos que introduce a la hora de re-converger la red en caso de fallo de algún componente, o los posibles recortes de tiempo aging de las tablas CAM cuando existen cambios en la topología.
Para conseguir un comportamiento Multipath, a la vez que eliminar los problemas de los retardos de reconvergencia de STP, se han creado varios protocolos que, en lugar de utilizar pesos y selecionar los enlaces activos, como hace STP, se crea un Fabric Ethernet (siguiendo una filosofía parecida a la del Fabric de los switches FC de almacenamiento) por el cual las tramas son enrutadas desde el origen al destino, como si de la capa L3 se tratase.
Los nuevos protocolos estándar para este fin son: Transparent Interconnection of Lots of Links (TRILL) y Shortest Path Bridging (SPB). También existen implementaciones propietarias, como FabricPath, que realizan el mismo trabajo que los dos estándares que se van a abordar.
Como se ha comentado, el proposito es crear un Fabric, por lo que la "nube de switches" podría ser vista como un único gran dispositivo (desde el punto de vista de transmisión de paquetes, no de gestión de los equipos).
Para entender esta afirmación hay que tener claro que mediante TRILL o SPB, cada equipo conoce de antemano el interfaz de salida para el paquete, gracias a la tabla de enrutamiento interna que almacena (del mismo modo que los protocolos de enrutamiento L3), lo cual puede asemejarse mucho a la tabla CAM que mantiene un único switch para decidir la interfaz de salida de una trama.
Resumiendo, un paquete de un cliente conectado a un switch perteneciente al fabric es enrutado internamente por el protocolo (TRILL/SPB) para llegar al destino de manera transparente, pudiendo utilizar varios caminos y manejando los fallos que puedan producirse en la topología. De esta manera se ha eliminado por completo la necesidad de utilización de STP para garantizar la alta disponibilidad de la plataforma.
Aunque en este enlace se puede encontrar una comparativa (algo parcial al punto de vista del fabricante Avaya), o en esta presentación, y en este otro enlace hay una buena descripción de TRILL y SPB, y teniendo en cuenta que la comparación extensiva entre TRILL y SPB queda fuera del ámbito que se está abordando, tan solo se va a realizar un escueto resumen de ambas propuestas de estándares.
Transparent Interconnection of Lots of Links (TRILL), es un estándar propuesto por la IETF que utiliza el protocolo de enrutamiento IS-IS (aprovechando que este se basa en el modelo OSI y no TCP/IP) para enrutar las tramas L2 desde su origen hasta su destino, para lo cual introduce una nueva cabecera sobre la cabecera MAC, encapsulando los paquetes para más tarde poder encaminarlos. Los equipos que realizan el enrutamiento L2 son llamados Rbridges.
Shortest Path Bridging (SPB) se encuentra recogido bajo el estándar 802.1aq del IEEE como borrador (draft) y puede que sea incluido en el estándar 802.1q. Este estándar también utiliza IS-IS para realizar el enrutamiento interno y tiene dos métodos para introducir los identificadores internos, y permitir el multipath: Shortest Path Bridging VLAN (SPBV) y Shortest Path Bridging Mac-in-Mac (SPBM). La diferencia entre ellos son los identificadores que utilizan para conocer cual es el mejor camino hasta el destino. Mientras SPBV utiliza lo que se llama Shortest Path VLAN ID (SPVID), SPBM utiliza una combinación de una Backbone MAC (BMAC) y un Backbone VLAN ID (BVID). SPBV utiliza el encapsulamiento Q-in-Q mientras que SPBM utiliza MAC-in-MAC.
Otro problema de los actuales grandes DCs es la imposibilidad de escalar más allá de ciertos límites en, por ejemplo número de VLANs IDs (4096) a configurar o número de MACs en las tablas CAM de los switches, sobretodo si se realizan extensiones L2 a lo largo de varios Data Centers, así como la duplicidad de IPs.
A este problema de escalabilidad hay que sumar la necesidad de separar lógicamente varias zonas del mismo Data Center, lo que se llama Multitenancy, por ejemplo porque se desea dar servicio a varios clientes completamente independientes.
Las necesidades de Multitenancy y de escalabilidad pueden verse como dos puntos completamente diferentes, pero la verdad es que muchas de las soluciones para conseguir una mayor escalabilidad consisten precisamente en explotar las funcionalidades multitenancy.
Solución hasta el momento
El problema del escalado de IPs, VLANs IDs y MACs aprendidas en los switches, así como el concepto Multitenant no es nuevo, ya que los ISPs se han estado enfrentando a estos problemas durante muchos años. Para solventarlos se han ido utilizando una serie de métodos como Q-in-Q (802.1ad), MAC-in-MAC (802.1ah) y la utilización de MPLS. Estos métodos pueden ser igualmente utilizados dentro de un Data Center (o a lo largo de DCs distribuidos).
Q-in-Q no es más que utilizar dos tags de VLANs, uno para la parte cliente y otro para la parte proveedor, de manera que cuando el tráfico de las VLANs de un cliente (tenant) entra en la red del proveedor en forma de trunk de VLANs, este tráfico se encapsula dentro de una nueva VLAN del proveedor. Con esto se consigue que dentro de cada una de las VLANs que posee el proveedor se encapsula el trunk 802.1q de cada cliente. Esta técnica proporciona 16 millones de posibles "VLANs" (4096 x 4096).
La técnica de MAC-in-MAC es utilizada por protocolos como PBB y PBT, y su cometido no es más que encapsular las tramas de cliente dentro de una nueva trama Ethernet con una MAC del propio proveedor. Del mismo modo que en una LAN un servidor envía y recibe datos desde una MAC asignada a su NIC, con MAC-in-MAC dentro de de la red del proveedor un cliente enviará y recibirá tráfico identificado por otra MAC diferente. Esta técnica de encapsulación separa completamente los dominios de cliente y proveedor y proporciona una ventaja considerable con respecto a Q-in-Q, ya que los dispositivos de la red de proveedor no tienen que aprender todas las MACs de cliente, ya que estas se encuentran enmascaradas dentro de la MAC de proveedor, lo que hace que que equipamiento de red no complete sus tablas CAM con tanta asiduidad.
Por último, la utilización de MPLS es otra de las medidas utilizadas (y posiblemente la mejor) para proporcionar una mayor escalabilidad, gracias a que el número de tags MPLS posibles es mucho mayor que el de VLANs IDs, además de que permite la separación lógica de los flujos de cada cliente.
Solución con nuevos protocolos ( TRILL + FGL o NVGRE / VXLAN )
Las últimas soluciones tienen ciertas similitudes con la solución MAC-in-MAC y se basan en que, para proporcionar escalabilidad y Multitenancy, se han de desplegar lo que se llama overlay networks que son arquitecturas en las cuales cada cliente (tenant) dispone de una red virtual propia (que utiliza los mismos componentes físicos que el resto de clientes) mediante la cual sus equipos pueden comunicarse.
Mediante los Network Overlays se aislan los espacios de direccionamiento de los clientes, MACs y VLANs IDs duplicadas,etc sin importar si existen niveles L3 de por medio.
Aunque este video es explicativo de Openflow, la verdad es que deja claro el concepto básico de lo que son overlay networks. También se puede visitar la entrada de este blog para comprender un poco mejor este tipo de solución.
Es importante distinguir los diferentes "tipos" de virtualización de las redes para tener claro donde encajan los overlay networks, y conocer las diferencias cuando la virtualización se habla de NFV, ni tampoco asociar los overlay networks unívocamente a SDN:
Existen varias tendencias de encapsulación, como la que se hace mediante NVGRE y VXLAN , y la utilización de tags adicionales contenidos en otros protocolos, como sucede con el tag Fine-Grained Labeling ( FGL ) de TRILL.
Los mostrados aquí no son los únicos protocolos, existen más, pero si son los que se percibe que pueden ser tendencia en los próximos años. Un ejemplo de alguno de estos "otros" protocolos puede ser Stateless Transport Tunneling Protocol for Network Virtualization ( STT ), que es un borrador del protocolo utilizado por la empresa Nicira (adquirida por VMware) para encapsular con unas cabeceras al estilo de TCP.
NVGRE y VXLAN son bastante parecidos. NVGRE está siendo impulsado por Microsoft mientras que VXLAN por VMware, pero los dos se basan en la encapsulación.
NVGRE utiliza el protocolo GRE (MAC-in-GRE) para tunelizar las tramas L2 sobre redes L3 y, a esto, le añade a su vez un identificador llamado Tenant Network ID (TNI), mientras que VXLAN utiliza UDP (MAC-in-UDP) y un identificador llamado VXLAN Net Identifier (VNI).
Una vez tunelizado el tráfico viaja por las redes L2 y L3 hasta que llega al end-point, momento en el cual se realiza la des-encapsulación y se reenvía al la ubicación final. Estos end-point se llaman NVGRE Endpoint en NVGRE y VXLAN Tunnel End Points (VTEP) en VXLAN.
Por tanto, entre las ventajas de la utilización de NVGRE o VXLAN se pueden encontrar:
El que el equipamiento de red pueda hacer de endpoint para los túneles de los overlay networks puede ser muy útil (rendimiento, gestión por el personal de comunicaciones, etc), ya que las máquinas que se encuentren en una VXLAN, para poder alcanzar a otra maquina (ya sea virtual o física) que se encuentre en una VLAN tradicional fuera de la VXLAN/NVGRE-LAN, deberá terminar el túnel (GRE o UDP) en su correspondiente end-point, como se puede ver en la siguiente ilustración, donde en la parte izquierda aparece la terminación en el elemento de red mientras que en la derecha se utiliza una máquina adicional (virtual o física) para poder acabar el túnel:
Como contrapartida a NVGRE se tienen una implicación negativa del uso de este protocolo, y es que GRE no tiene visibilidad de flujo (al contrario que TCP y UDP, utilizado por VXLAN), por lo que no se podrán utilizar parámetros como el número de puerto dentro del fabric de red intermedio para lograr caminos de igual coste (ECMP), o incluso en la distribución del tráfico en los agregados de enlace, lo cual permitiría poder lograr un mejor aprovechamiento de los enlaces (debido a los cálculos de HASH diferentes IP/puerto).
Tanto NVGRE como VXLAN requieren que la plataforma de red que hay por debajo (la que conecta los end-point) suporte multicast y a nivel 3 el propio encaminamiento multicast (ver entrada en el blog sobre encaminamiento multicast) para poder lograr tanto las comunicaciones broadcast como multicast a lo largo de los overlay networks, lo cual complica la configuración de la arquitectura e incluso, en ocasiones, imposibilita la utilización de estos protocolos (muchos ISPs no lo soportan).
Es más, para el caso concreto de VXLAN, VMware recomienda que para cada VXLAN se utilice un arbol multicast para reducir los problemas de flooding. Este requisito/recomendación implica unas altas necesidades de CPU y RAM en los equipos de red intermedios.
El requisito de utilización de multicast podrá ser sustituido en el futuro mediante la integración de VXLAN y NVGRE con controladores de SDN, ya que en ese caso los controllers conocerían todos los servidores pertenecientes a la VXLAN (haciendo innecesario el uso de broadcast ARP) y no se tendría por qué realizar flooding de paquetes a toda la VXLAN.
También, al ser protocolos basados en la encapsución, es importante tener en cuenta las implicaciones de las modificaciones de la MTU a valores por encima de 1500 bytes, lo que induciría a la fragmentación intermedia de no tener correctamente configurada toda la red (de principio a fin), lo que perjudicaría gravemente al rendimiento de las comunicaciones.
Por último, otra implicación del uso de comunicaciones encapsuladas, es la imposibilidad de garantizar políticas de seguridad para esos flujos en los firewalls intermedios, por lo menos a día de hoy, ya que en el futuro puede que se incluya soporte para comunicaciones VXLAN o NVGRE en las releases de los firewalls físicos. Como contramedida a esta falta de seguridad, se pueden implementar firewalls virtuales tras los end-points, que podrán ver los flujos de tráfico des-encapsulados. Lo anterior no solo es aplicable a la seguridad, sucedería lo mismo con otros servicios de red como por ejemplo los balanceadores de carga o los optimizadores WAN.
Los anteriores métodos NVGRE y VXLAN están principalmente pensados para el mundo virtual (al menos por el momento) y tienen los problemas derivados de la incorporación de nuevas cabeceras para el encapsulamiento. Por otro lado está la solución basada en tags, como la de TRILL con la etiqueta FGL, si bien es cierto que por ahora no es más que un borrador, en el futuro, dentro de una red con TRILL desplegado, se podría hacer uso de la etiqueta FGL para proporcionar 16 millones de VLANs diferentes.
Con este método no se incluiría el encapsulamiento con las cabeceras adicionales UDP (VXLAN) o IP (NVGRE), con lo que el funcionamiento de la red sería igual al tradicional y, no menos importante, no se desvirtuaría la dupla mundo de sistemas/virtualización y mundo de comunicaciones, únicamente se ganaría una mayor escalabilidad de VLANs en las arquitecturas actuales.
Para lograr el multitenancy mediante el método de TRILL + etiqueta, se podrá utilizar en el futuro Q-in-Q dentro del propio fabric TRILL, aunque nuevamente este tipo de soluciones todavía está en sus primeros pasos.
También podrían utilizarse métodos NFV o virtualización de equipos físicos para realizar las funciones Multitenancy, tal y como se viene haciendo hoy en día.
Extensión L2 y Data Center Interconnect (DCI)
En las actuales arquitecturas de Data Center habitualmente se hace necesario inter-conectar a nivel 2 los diferentes centros.
La extensión L2 a lo largo de diferentes Data Centers puede ser bastante problemática, por el hecho de que los bucles de un DC pueden propagarse al otro, con lo que se perdería la alta disponibilidad, además de que el formar grandes segmentos L2 puede hacer alcanzar los valores máximos de número de MAC por VLAN.
Otros problemas de la extensión de VLANs son los propios del uso eficiente de los enlaces a nivel 2, como se mostrado en el punto anterior.
Solución hasta el momento
Existe múltiples métodos para la inter-conexión de Data Centers a nivel 2. Algunos de ellos se comentan en la entrada "Arquitectura MultiDataCenter - Extensión L2".
Resumiendo lo más común, existe la posibilidad de conexión mediante tres opciones fundamentales, dependiendo del tipo de conectividad que esté disponible entre los DCs:
Con relación al punto "Optimización de enlaces", explicado anteriormente, es importante ver cómo los protocolos STP y los nuevos TRILL o SPB pueden encajar dentro de la inter-conexión tradicional de Data Centers.
En el caso de la utilización de enlaces de nivel 1 (DWDM o fibra oscura), las consideraciones de los protocolos STP o TRILL/SPB serían la mismas que las mostradas anteriormente, ya que los enlaces DCI podrían ser vistos como cables directos entre los DCs.
De realizarse una conexión DWDM/fibra, se deberían solucionar los mismos problemas que los tratados en el anterior punto, como si de un enlace local al DC se tratase, y habría que tener en cuenta que existiría un único dominio STP, o un único Fabric (si se utilizase TRILL/SPB) compartido por los dos Data Centers (al igual que en las consideraciones locales hechas en el anterior punto para un solo Data Center).
En el caso de conectar más de dos DCs se pueden utilizar los mismos métodos:
En el caso de utilizar una variante de STP uno de los enlaces será bloqueado (ya sea para todas las VLANs o para un grupo de ellas) por lo que para poder alcanzar el DC3 desde el DC1, habría que pasar previamente por el DC2, con el aumento de retardo y consumo de anchos de banda que ello conlleva:
La formación de chasis virtuales a lo largo de conexiones WAN es posible siempre y cuando se cumplan una serie de requisitos de ancho de banda y retardo, no obstante el hecho de utilizar enlaces WAN en lugar de LAN para la formación del chasis virtual conlleva riesgos que deberían ser estudiados a fondo antes de optar por esta solución:
Normalmente se utilizan enlaces redundantes para conectar cada uno de los switches, para garantizar la alta disponibilidad, pero no siempre se puede hacer un uso eficiente de todos ellos, es decir, una utilización activo-activo de los enlaces, sino que se tiene que recurrir al uso en modo activo-pasivo.
La utilización de todos los enlaces es importante, más si cabe cuando los enlaces son costos, como por ejemplo enlaces 10G o enlaces inter-DC (suponiendo que les hemos conectado con DWDM, por ejemplo).
También existe el problema de los altos tiempos de convergencia tras una modificación/caída de uno de los enlaces, así como el grado de impacto que este acontecimiento tiene en la arquitectura global.
Soluciones hasta el momento
El primer método encontrado para poder implementar un despliegue L2 con redundancia fue la utilización del protocolo Spanning-Tree, o mejor dicho, alguna de sus variantes como MST, PVSTP (propietario), RSTP...Para mejorar la utilización de los enlaces, ya que STP habilitará siempre un único camino (siempre será activo-pasivo), normalmente se utilizan dos métodos adicionales: la agregación de enlaces o la utilización de MST o PVSTP para poder crear diferentes árboles STP por cada VLAN o grupo de VLANs (en el caso de MST).
Otra solución adicional es la formación de agregados de enlace, también llamados PortChannels o EtherChannels. La utilización de todos los enlaces mediante la utilización de agregados de enlace era bastante restringida, ya que hasta hace unos años (se verá más tarde) no se podrían crear agregados de enlace distribuidos a lo largo de varios switches (el agregado tenía que inicial y finalizar en los mismos dos switches físicos), por lo que el único esquema válido era el siguiente (y para un máximo de 8 enlaces):
Figura 1 - Utilización de todos los caminos mediante agregados de enlace
Aún así, si se incluía un tercer switch, los agregados ya no podrían verse como una solución para la optimización de utilización de caminos, por lo que había que recurrir a las correctas configuraciones de MST y PVSTP.
En la siguiente figura se presenta el típico esquema de tres switches conectados de manera redundante, en el cual STP bloquea uno de los enlaces para que no existan bucles L2:
Figura 2 - Bloqueo de enlace por protocolo STP
Con este esquema, el enlace bloqueado no será utilizado, a no ser que el enlace entre los switches A y B falle.
Para poder utilizar también el enlace entre el Switch A y el Switch C, se podrían hacer dos grupos (si se utiliza MST) de VLANs, el grupo color azul y el grupo color verde, y a cada uno se le asignaría un arbol STP diferente, con diferentes pesos e incluso root bridge, para que de este modo cada arbol STP bloquee uno de los enlaces disponibles, como se muestra a continuación:
Figura 3 - Optimización mediante división de árboles STP
En los últimos años han aparecido otros métodos, basados en la virtualización de componentes, para poder crear un único gran switch virtual y eliminar así los enlaces inter-switch:
Figura 4 - Stacks de switches
De tenerse un único equipo (stack formando un switch virtual), o incluso dos (y agregados de enlace), se podría deshabilitar STP, ya que no habría posibilidad de bucles L2 (este despliegue conservaría el HA al tener varios equipos dentro del stack), por lo que se obtendría una ventaja añadida y es que no entrarían en juego los temporizadores de STP a la hora del recálculo de pesos en caso de un fallo en un enlace o switch, mejorando los tiempos de respuesta globales de la plataforma ante fallos.
Más tarde aparecieron los chasis virtuales, los cuales podrían formarse sin la necesidad de un cable especial, si no mediante conexiones Ethernet. Este es el caso del IRF en HP o el VSS en Cisco.
En caso de tener que conectar (al stack) switches que no soporten ninguno de estos protocolos, también se consigue una optimización de caminos, ya que se podrá formar un agregado de enlace distribuido entre diferentes terminaciones físicas entre el stack y el nuevo switch, al ser considerado el stack como un switch único. Puede verse un ejemplo de agregado distribuido en la siguiente figura:
Figura 5 - Agregados de enlace a stacks de switches
Existe otra tecnología que permite la creación de agregados a lo largo de switches distribuidos, como el virtual PortChannel (vPC), mac-pinning, etc (ver entrada en el blog sobre configuraciones de vPC, mac-pinning, etc en Nexus 1000v), y diversos fabricantes han hecho sus propias implementaciones al respecto, con lo que se podrían utilizar todos los caminos aunque no se pudiesen formar stacks de switches propiamente dichos.
Resumiendo lo anterior, habitualmente para poder proporcionar servicio de red en HA, intentando optimizar la utilización de los enlaces, se puede:
- Utilizar una variante de STP (MST o PVSTP) haciendo grupos de VLANs y diferenciando los enlaces activos en el árbol STP para cada uno de ellos.
- Creación de stacks o chasis virtuales (por ejemplo IRF o VSS)
- Creación de agregados de enlace. Para mejorar la alta disponibilidad se pueden realizar agregados sobre stacks/chasis virtuales (Multichasis Etherchannel).
Solución con nuevos protocolos ( TRILL / SPB )
Se han visto fundamentalmente dos métodos para la utilización de todos los caminos: configuración de MST/PVSTP o la creación de agregados y stacks.
Ya que en despliegues muy grandes no se podrán tener únicamente dos switches, aún realizando stacks, para poder formar entre ellos como mucho un agregado de enlace, se deberá contar con la configuración de STP para garantizar el HA.
Al tener habilitado STP se deberá contar con los retardos que introduce a la hora de re-converger la red en caso de fallo de algún componente, o los posibles recortes de tiempo aging de las tablas CAM cuando existen cambios en la topología.
Para conseguir un comportamiento Multipath, a la vez que eliminar los problemas de los retardos de reconvergencia de STP, se han creado varios protocolos que, en lugar de utilizar pesos y selecionar los enlaces activos, como hace STP, se crea un Fabric Ethernet (siguiendo una filosofía parecida a la del Fabric de los switches FC de almacenamiento) por el cual las tramas son enrutadas desde el origen al destino, como si de la capa L3 se tratase.
Los nuevos protocolos estándar para este fin son: Transparent Interconnection of Lots of Links (TRILL) y Shortest Path Bridging (SPB). También existen implementaciones propietarias, como FabricPath, que realizan el mismo trabajo que los dos estándares que se van a abordar.
Como se ha comentado, el proposito es crear un Fabric, por lo que la "nube de switches" podría ser vista como un único gran dispositivo (desde el punto de vista de transmisión de paquetes, no de gestión de los equipos).
Para entender esta afirmación hay que tener claro que mediante TRILL o SPB, cada equipo conoce de antemano el interfaz de salida para el paquete, gracias a la tabla de enrutamiento interna que almacena (del mismo modo que los protocolos de enrutamiento L3), lo cual puede asemejarse mucho a la tabla CAM que mantiene un único switch para decidir la interfaz de salida de una trama.
Figura 6 - Transformación de la topología hacia un Fabric de red
Aunque en este enlace se puede encontrar una comparativa (algo parcial al punto de vista del fabricante Avaya), o en esta presentación, y en este otro enlace hay una buena descripción de TRILL y SPB, y teniendo en cuenta que la comparación extensiva entre TRILL y SPB queda fuera del ámbito que se está abordando, tan solo se va a realizar un escueto resumen de ambas propuestas de estándares.
Transparent Interconnection of Lots of Links (TRILL), es un estándar propuesto por la IETF que utiliza el protocolo de enrutamiento IS-IS (aprovechando que este se basa en el modelo OSI y no TCP/IP) para enrutar las tramas L2 desde su origen hasta su destino, para lo cual introduce una nueva cabecera sobre la cabecera MAC, encapsulando los paquetes para más tarde poder encaminarlos. Los equipos que realizan el enrutamiento L2 son llamados Rbridges.
Shortest Path Bridging (SPB) se encuentra recogido bajo el estándar 802.1aq del IEEE como borrador (draft) y puede que sea incluido en el estándar 802.1q. Este estándar también utiliza IS-IS para realizar el enrutamiento interno y tiene dos métodos para introducir los identificadores internos, y permitir el multipath: Shortest Path Bridging VLAN (SPBV) y Shortest Path Bridging Mac-in-Mac (SPBM). La diferencia entre ellos son los identificadores que utilizan para conocer cual es el mejor camino hasta el destino. Mientras SPBV utiliza lo que se llama Shortest Path VLAN ID (SPVID), SPBM utiliza una combinación de una Backbone MAC (BMAC) y un Backbone VLAN ID (BVID). SPBV utiliza el encapsulamiento Q-in-Q mientras que SPBM utiliza MAC-in-MAC.
Escalabilidad y Multitenancy
A este problema de escalabilidad hay que sumar la necesidad de separar lógicamente varias zonas del mismo Data Center, lo que se llama Multitenancy, por ejemplo porque se desea dar servicio a varios clientes completamente independientes.
Las necesidades de Multitenancy y de escalabilidad pueden verse como dos puntos completamente diferentes, pero la verdad es que muchas de las soluciones para conseguir una mayor escalabilidad consisten precisamente en explotar las funcionalidades multitenancy.
Solución hasta el momento
El problema del escalado de IPs, VLANs IDs y MACs aprendidas en los switches, así como el concepto Multitenant no es nuevo, ya que los ISPs se han estado enfrentando a estos problemas durante muchos años. Para solventarlos se han ido utilizando una serie de métodos como Q-in-Q (802.1ad), MAC-in-MAC (802.1ah) y la utilización de MPLS. Estos métodos pueden ser igualmente utilizados dentro de un Data Center (o a lo largo de DCs distribuidos).
Q-in-Q no es más que utilizar dos tags de VLANs, uno para la parte cliente y otro para la parte proveedor, de manera que cuando el tráfico de las VLANs de un cliente (tenant) entra en la red del proveedor en forma de trunk de VLANs, este tráfico se encapsula dentro de una nueva VLAN del proveedor. Con esto se consigue que dentro de cada una de las VLANs que posee el proveedor se encapsula el trunk 802.1q de cada cliente. Esta técnica proporciona 16 millones de posibles "VLANs" (4096 x 4096).
La técnica de MAC-in-MAC es utilizada por protocolos como PBB y PBT, y su cometido no es más que encapsular las tramas de cliente dentro de una nueva trama Ethernet con una MAC del propio proveedor. Del mismo modo que en una LAN un servidor envía y recibe datos desde una MAC asignada a su NIC, con MAC-in-MAC dentro de de la red del proveedor un cliente enviará y recibirá tráfico identificado por otra MAC diferente. Esta técnica de encapsulación separa completamente los dominios de cliente y proveedor y proporciona una ventaja considerable con respecto a Q-in-Q, ya que los dispositivos de la red de proveedor no tienen que aprender todas las MACs de cliente, ya que estas se encuentran enmascaradas dentro de la MAC de proveedor, lo que hace que que equipamiento de red no complete sus tablas CAM con tanta asiduidad.
Por último, la utilización de MPLS es otra de las medidas utilizadas (y posiblemente la mejor) para proporcionar una mayor escalabilidad, gracias a que el número de tags MPLS posibles es mucho mayor que el de VLANs IDs, además de que permite la separación lógica de los flujos de cada cliente.
Solución con nuevos protocolos ( TRILL + FGL o NVGRE / VXLAN )
Las últimas soluciones tienen ciertas similitudes con la solución MAC-in-MAC y se basan en que, para proporcionar escalabilidad y Multitenancy, se han de desplegar lo que se llama overlay networks que son arquitecturas en las cuales cada cliente (tenant) dispone de una red virtual propia (que utiliza los mismos componentes físicos que el resto de clientes) mediante la cual sus equipos pueden comunicarse.
Mediante los Network Overlays se aislan los espacios de direccionamiento de los clientes, MACs y VLANs IDs duplicadas,etc sin importar si existen niveles L3 de por medio.
Aunque este video es explicativo de Openflow, la verdad es que deja claro el concepto básico de lo que son overlay networks. También se puede visitar la entrada de este blog para comprender un poco mejor este tipo de solución.
Figura 7 - Ejemplo de Overlay Network
Es importante distinguir los diferentes "tipos" de virtualización de las redes para tener claro donde encajan los overlay networks, y conocer las diferencias cuando la virtualización se habla de NFV, ni tampoco asociar los overlay networks unívocamente a SDN:
- Software Defined Network (SDN) se refiere a la deslocalización del la capa de control de los elementos de red, desde los equipos de red a uno o varios gestores centrales (controllers), los cuales mediante APIs se hablan con aplicativos que pueden, de este modo, modificar la configuración y comportamiento de la red. Esta deslocalización puede ser completa (utilizando el protocolo OpenFlow), de manera que los equipos de red son meros forwarders de paquetes siguiendo los dictados del controller, o mediante la gestión centralizada de la configuración de red, lo cual podría ser un software corriendo en un servidor que lanza los comandos necesarios en cada uno de los equipos de red para que estos repliquen el funcionamiento que se requiere. Cuando VMware hace referencia a NSX y NVP se refiere principalmente a la utilización de SDN junto con overlay networks, es decir, a la introducción de un controlador que podría crear dinámicamente los túneles formados por VXLAN, pero esto no quiere decir que no se puedan formar overlay networks con VXLAN de manera manual si ningún tipo de infraestructura SDN adicional (controller y API).
- Network Functions Virtualizacion (NFV) no es más que la generación de "maquinas virtuales" que realizan las funciones que típicamente realizan los dispositivos de red, como puedan ser routers, firewalls, balanceadores, proxys, etc e introducirlos en la plataforma de virtualización (VMware, Hiper-V, KVM, etc). Tampoco hay que confundir NFV con la virtualización de equipos físicos de red, en donde por ejemplo de un solo firewall físico pueden obtener varios firewalls lógicos, ya que estos no correrían bajo un hipervisor para máquinas virtuales, sino sobre el software del propio equípo físico.
Existen varias tendencias de encapsulación, como la que se hace mediante NVGRE y VXLAN , y la utilización de tags adicionales contenidos en otros protocolos, como sucede con el tag Fine-Grained Labeling ( FGL ) de TRILL.
Los mostrados aquí no son los únicos protocolos, existen más, pero si son los que se percibe que pueden ser tendencia en los próximos años. Un ejemplo de alguno de estos "otros" protocolos puede ser Stateless Transport Tunneling Protocol for Network Virtualization ( STT ), que es un borrador del protocolo utilizado por la empresa Nicira (adquirida por VMware) para encapsular con unas cabeceras al estilo de TCP.
NVGRE y VXLAN son bastante parecidos. NVGRE está siendo impulsado por Microsoft mientras que VXLAN por VMware, pero los dos se basan en la encapsulación.
NVGRE utiliza el protocolo GRE (MAC-in-GRE) para tunelizar las tramas L2 sobre redes L3 y, a esto, le añade a su vez un identificador llamado Tenant Network ID (TNI), mientras que VXLAN utiliza UDP (MAC-in-UDP) y un identificador llamado VXLAN Net Identifier (VNI).
Una vez tunelizado el tráfico viaja por las redes L2 y L3 hasta que llega al end-point, momento en el cual se realiza la des-encapsulación y se reenvía al la ubicación final. Estos end-point se llaman NVGRE Endpoint en NVGRE y VXLAN Tunnel End Points (VTEP) en VXLAN.
Por tanto, entre las ventajas de la utilización de NVGRE o VXLAN se pueden encontrar:
- Los nuevos identificadores TNI y VNI son de 24-bits, frente a los 12 de los VLAN ID tradicionales, lo cual permite 16 millones de VLANs frente a las 4096.
- Al ser el tráfico encapsulado hasta su destino final, se pueden crear overlay networks que segmentan los dominios de conectividad de los clientes, solventando los problemas de IPs/VLANs/MACs duplicadas y seguridad.
- También, debido a la encapsulación del tráfico con UDP o GRE, como funcionalidad añadida se tiene la posibilidad de transportar el tráfico L2 a lo largo de redes L3, o lo que es lo mismo extender el dominio L2. Esto puede permitir la formación de comunicaciones inter-Data Center, las cuales serán tratadas en el siguiente punto. Esta funcionalidad, por ahora, tiene varias restricciones que también serán descritas en el siguiente punto que habla de los enlaces DCI.
- Facilita la creación dinámica y automatizada (bueno para el cloud) de los overlay networks, ya que se independizan las comunicaciones de este tipo de la configuración de los equipos de red intermedios. Esto, que puede verse como una ventaja para la adopción de una arquitectura cloud, puede también ser considerado como un problema desde el punto de vista de la gestión y control de red, ya que el personal de comunicaciones queda muchas veces al margen de estas topologías y porque las plataformas virtuales pasan a ser un punto crítico en las comunicaciones de red de los servicios de la empresa.
El que el equipamiento de red pueda hacer de endpoint para los túneles de los overlay networks puede ser muy útil (rendimiento, gestión por el personal de comunicaciones, etc), ya que las máquinas que se encuentren en una VXLAN, para poder alcanzar a otra maquina (ya sea virtual o física) que se encuentre en una VLAN tradicional fuera de la VXLAN/NVGRE-LAN, deberá terminar el túnel (GRE o UDP) en su correspondiente end-point, como se puede ver en la siguiente ilustración, donde en la parte izquierda aparece la terminación en el elemento de red mientras que en la derecha se utiliza una máquina adicional (virtual o física) para poder acabar el túnel:
Figura 8 - Terminación de túneles VXLAN para comunicación con máquinas externas
Como contrapartida a NVGRE se tienen una implicación negativa del uso de este protocolo, y es que GRE no tiene visibilidad de flujo (al contrario que TCP y UDP, utilizado por VXLAN), por lo que no se podrán utilizar parámetros como el número de puerto dentro del fabric de red intermedio para lograr caminos de igual coste (ECMP), o incluso en la distribución del tráfico en los agregados de enlace, lo cual permitiría poder lograr un mejor aprovechamiento de los enlaces (debido a los cálculos de HASH diferentes IP/puerto).
Tanto NVGRE como VXLAN requieren que la plataforma de red que hay por debajo (la que conecta los end-point) suporte multicast y a nivel 3 el propio encaminamiento multicast (ver entrada en el blog sobre encaminamiento multicast) para poder lograr tanto las comunicaciones broadcast como multicast a lo largo de los overlay networks, lo cual complica la configuración de la arquitectura e incluso, en ocasiones, imposibilita la utilización de estos protocolos (muchos ISPs no lo soportan).
Es más, para el caso concreto de VXLAN, VMware recomienda que para cada VXLAN se utilice un arbol multicast para reducir los problemas de flooding. Este requisito/recomendación implica unas altas necesidades de CPU y RAM en los equipos de red intermedios.
El requisito de utilización de multicast podrá ser sustituido en el futuro mediante la integración de VXLAN y NVGRE con controladores de SDN, ya que en ese caso los controllers conocerían todos los servidores pertenecientes a la VXLAN (haciendo innecesario el uso de broadcast ARP) y no se tendría por qué realizar flooding de paquetes a toda la VXLAN.
También, al ser protocolos basados en la encapsución, es importante tener en cuenta las implicaciones de las modificaciones de la MTU a valores por encima de 1500 bytes, lo que induciría a la fragmentación intermedia de no tener correctamente configurada toda la red (de principio a fin), lo que perjudicaría gravemente al rendimiento de las comunicaciones.
Por último, otra implicación del uso de comunicaciones encapsuladas, es la imposibilidad de garantizar políticas de seguridad para esos flujos en los firewalls intermedios, por lo menos a día de hoy, ya que en el futuro puede que se incluya soporte para comunicaciones VXLAN o NVGRE en las releases de los firewalls físicos. Como contramedida a esta falta de seguridad, se pueden implementar firewalls virtuales tras los end-points, que podrán ver los flujos de tráfico des-encapsulados. Lo anterior no solo es aplicable a la seguridad, sucedería lo mismo con otros servicios de red como por ejemplo los balanceadores de carga o los optimizadores WAN.
Los anteriores métodos NVGRE y VXLAN están principalmente pensados para el mundo virtual (al menos por el momento) y tienen los problemas derivados de la incorporación de nuevas cabeceras para el encapsulamiento. Por otro lado está la solución basada en tags, como la de TRILL con la etiqueta FGL, si bien es cierto que por ahora no es más que un borrador, en el futuro, dentro de una red con TRILL desplegado, se podría hacer uso de la etiqueta FGL para proporcionar 16 millones de VLANs diferentes.
Con este método no se incluiría el encapsulamiento con las cabeceras adicionales UDP (VXLAN) o IP (NVGRE), con lo que el funcionamiento de la red sería igual al tradicional y, no menos importante, no se desvirtuaría la dupla mundo de sistemas/virtualización y mundo de comunicaciones, únicamente se ganaría una mayor escalabilidad de VLANs en las arquitecturas actuales.
Para lograr el multitenancy mediante el método de TRILL + etiqueta, se podrá utilizar en el futuro Q-in-Q dentro del propio fabric TRILL, aunque nuevamente este tipo de soluciones todavía está en sus primeros pasos.
También podrían utilizarse métodos NFV o virtualización de equipos físicos para realizar las funciones Multitenancy, tal y como se viene haciendo hoy en día.
Extensión L2 y Data Center Interconnect (DCI)
En las actuales arquitecturas de Data Center habitualmente se hace necesario inter-conectar a nivel 2 los diferentes centros.
La extensión L2 a lo largo de diferentes Data Centers puede ser bastante problemática, por el hecho de que los bucles de un DC pueden propagarse al otro, con lo que se perdería la alta disponibilidad, además de que el formar grandes segmentos L2 puede hacer alcanzar los valores máximos de número de MAC por VLAN.
Otros problemas de la extensión de VLANs son los propios del uso eficiente de los enlaces a nivel 2, como se mostrado en el punto anterior.
Existe múltiples métodos para la inter-conexión de Data Centers a nivel 2. Algunos de ellos se comentan en la entrada "Arquitectura MultiDataCenter - Extensión L2".
Resumiendo lo más común, existe la posibilidad de conexión mediante tres opciones fundamentales, dependiendo del tipo de conectividad que esté disponible entre los DCs:
- Nivel 1 (Fibra oscura o DWDM): se tratarían del como un cable directo.
- Nivel 2 (MPLS): Se utilizaría EoMPLS, o VPLS (enlaces multipunto).
- Nivel 3 (IP): Se tuneliza con GRE para poder utilizar alguno de los protocolos del punto 2: EoMPLSoGRE o VPLSoGRE.
Con relación al punto "Optimización de enlaces", explicado anteriormente, es importante ver cómo los protocolos STP y los nuevos TRILL o SPB pueden encajar dentro de la inter-conexión tradicional de Data Centers.
En el caso de la utilización de enlaces de nivel 1 (DWDM o fibra oscura), las consideraciones de los protocolos STP o TRILL/SPB serían la mismas que las mostradas anteriormente, ya que los enlaces DCI podrían ser vistos como cables directos entre los DCs.
De realizarse una conexión DWDM/fibra, se deberían solucionar los mismos problemas que los tratados en el anterior punto, como si de un enlace local al DC se tratase, y habría que tener en cuenta que existiría un único dominio STP, o un único Fabric (si se utilizase TRILL/SPB) compartido por los dos Data Centers (al igual que en las consideraciones locales hechas en el anterior punto para un solo Data Center).
En el caso de conectar más de dos DCs se pueden utilizar los mismos métodos:
- Variante de STP
- Formación de chasis (stack) virtual
- TRILL o SPB
En el caso de utilizar una variante de STP uno de los enlaces será bloqueado (ya sea para todas las VLANs o para un grupo de ellas) por lo que para poder alcanzar el DC3 desde el DC1, habría que pasar previamente por el DC2, con el aumento de retardo y consumo de anchos de banda que ello conlleva:
Figura 9 - DWDM con STP para múltiples DCs
La formación de chasis virtuales a lo largo de conexiones WAN es posible siempre y cuando se cumplan una serie de requisitos de ancho de banda y retardo, no obstante el hecho de utilizar enlaces WAN en lugar de LAN para la formación del chasis virtual conlleva riesgos que deberían ser estudiados a fondo antes de optar por esta solución:
Figura 10 - DWDM y formación de chasis virtuales extendidos
TRILL y SPB solventan este problema de utilización no optima de los recursos como ya se ha visto anteriormente, por lo que puede ser una buena solución en arquitecturas con DWDM:
Figura 11 - DWDM con TRILL/SPB para múltiples DCs
Este comportamiento con TRILL y SPB se ve minimizado, porque no hay que contar con los problemas implícitos de STP, pero si es verdad que ante un eventual fallo de TRILL se verían afectados todos los centros a la vez. Por ello es por lo que siempre se recomienda aislar los dominios L2 entre los DCs y confinarlos localmente, para poder disponer de una verdadera HA de los servicios a nivel global.
Los protocolos EoMPLS y VPLS proporcionan dicho aislamiento (conservando la conectividad a nivel 2), por lo que en ocasiones estos son utilizados sobre los propios enlaces DWDM, aunque no exista una red MPLS entre los DCs, para lograr el confinamiento de los dominio L2 dentro de cada Data Center:
Figura 12 - Confinamiento de dominios STP/TRILL/SPB en el DC local
Por otra parte, la solución del chasis virtual extendido, vista anteriormente, tiene un problema similar al del dominio STP único, ya que el chasis formado es un punto único de fallo que, teóricamente, podría afectar a todos los DCs al unisono, por lo que este deberá ser otro punto a tener en cuenta en la elección de su posible implementación.
Solución con nuevos protocolos ( EVI / OTV o NVGRE / VXLAN)
Existen dos tendencias diferentes a la hora de dar nuevas soluciones a la interconectividad L2 entre DCs remotos, uno principalmente vinculado al mundo de sistemas y virtualización (NVGRE / VXLAN), y otro punto de vista tradicional de las comunicaciones (EVI / OTV).
EVI y OTV
Si bien es cierto que VPLS cubre las necesidades de interconexión de DCs distribuidos, hay que tener presente algunos aspectos que son mejorables:
- Depende de MPLS por debajo, por lo que, de no existir entre los DCs, hay que utilizar métodos de encapsulación GRE.
- Para poder propagar las MACs realiza un flooding de estas, por lo que no se puede eliminar el flooding de un DC a otro.
- Se necesitan protocolos adicionales para poder formar las conexiones multihoming (por ejemplo BGP), lo que complica la configuración final.
- Requiere una conexión full mesh entre todos los DCs
- No puede escalar más allá de 4096 VLANs (para soportar más VLANs hay que recurrir a métodos como QinQ)
Es por ello que han surgido nuevos protocolos como EVI - Ethernet Virtual Interconnect (HP) y OTV - Overlay Transport Virtualization (Cisco), los cuales:
- Permiten realizar conexiones L2 sobre cualquier tipo de plataforma IP (se obtendría una homogeneización del tipo de interconexión de los Data Centers sin necesidad de túneles adicionales)
- Transmisiones multicast (no es necesario el flooding)
- No se necesitaría la complejidad de MPLS, BGP y otros protocolos por debajo.
- Autogestionan las conexiones multihoming sin necesidad de tener que realizar un full mesh
Aparte, aunque en primera instancia tienen soporte para 4k VLANs, en ambos se incluyen tags dentro de las cabeceras que en un futuro podrán ser utilizados para alcanzar un mayor número de VLANs ID, lo cual puede ser necesario cuando se extiende el nivel 2 por múltiples Data Centers.
EVI y OTV son parecidos, y ambos utilizan IS-IS por debajo para poder enrutar el tráfico de las inter-conexiones de DCs y tunelizan mediante GRE.
Los dos protocolos simplifican los enlaces entre DCs pero introducen alguna restricción, como el número de centros (8 DCs), o la necesidad de Hardware compatible con estos protocolos.
No se ha de confundir el cometido de EVI y OTV con el de TRILL o SPB, ya que ambos utilicen un método similar para enrutar las tramas/paquetes de modo interno (protocolo IS-IS), tienen funciones diferentes, TRILL/SPB sustituyen a STP para obtener una red de nivel 2 de alta disponibilidad y EVI/OTV proporcionan un método de extender el nivel 2 entre DCs, es más es probable que se requieran utilizar conjuntamente para extender los Fabrics a lo largo de los diferentes Data Centers.
Hay que recordar que es recomendable mantener la mayor independencia posible ente DCs, tal y como se vio anteriormente, para poder aislar los problemas entre centros:
Figura 13 - EVI / OTV y TRILL / SPB
NVGRE / VXLAN
Como se ha mencionado antes, la solución DCI mediante NVGRE (Microsoft, principalmente) o VXLAN (VMware) ha sido desarrollada desde el punto de vista de los ingenieros de sistemas, los cuales muchas veces se encuentran con el problema de tener que conectar máquinas virtuales que se encuentran en diferentes redes de diferentes DCs, lo cual implica que el equipo de comunicaciones tenga que reconfigurar y reestructurar la arquitectura de red para poder acometer ese requerimiento, o lo que es lo mismo, tiempo y dinero.
Para evitar tener que involucrar, en la medida de lo posible, a las áreas de comunicaciones y para encontrar solución a problemas que los protocolos tradicionales de red todavía no podrían aportar, se crearon métodos de encapsulamiento para "independizarse" de las restricciones de la red subyacente.
Al utilizar tecnologías de encapsulamiento que puedan ser enrutadas por redes L3, se proporciona la habilidad de conectar, mediante estos túneles, máquinas que se encuentren en DCs diferentes, por lo que podría verse como una especie de enlace DCI.
Aunque se aporte conectividad L2 entre los Data Centers, este tipo de DCI no cumple con varios de los requisitos básicos de este tipo de enlaces (cosas que sí que hacen protocolos ya vistos, como VPLS, EVI o OTV), como por ejemplo que extiende 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.
Sumado a esto hay que añadir los problemas que ya se han revisado de la necesidad de multicast 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).
A parte de lo anterior, a día de hoy, cuando todavía hay que utilizar end-point vinculados plenamente a las plataformas virtuales, puede existir el problema de "traffic tromboning" o "traffic trombons", o lo que es lo mismo, ineficiencias en los flujos de tráfico (los flujos pasan más veces de las necesarias por la WAN).
Esto puede darse cuando una máquina vitual se mueve de un DC a otro y a su vez necesita comunicarse con máquinas o clientes en el DC origen.
Un ejemplo recurrente de este comportamiento se da cuando se utilizan en VMware elementos como los vShields, cuya misión sería securizar las diferentes VXLANs, en este caso podría suceder lo explicado en este blog:
Figura 14 - Problema de los traffic tromboning con VXLAN y vShield
Y por último, las tecnologías VXLAN y NVGRE, por el momento, solo pueden utilizarse para plataformas virtuales, si se necesita la extensión L2 para equipos físicos, por ejemplo para crear un cluster extendido, se tendrá que recurrir a otras tecnologías como HP EVI , Cisco OTV, VPLS, etc.
Resumiendo lo anterior, VXLAN y NVGRE no pueden verse, a día de hoy, como tecnologías para interconectar Data Centers, aunque es posible que mediante modificaciones futuras (introducción de controller SDN, funcionalidades de end-points dentro del equipamiento de red, etc) puedan ser una opción para realizar este trabajo.
Visibilidad y control de conexiones de VMs
Los principales problemas que plantea la virtualización de sistemas, desde el punto de vista de la arquitectura de red son:
• Pérdida de visibilidad del tráfico entre máquinas virtuales dentro del mismo host físico, ya que si una máquina virtual quiere comunicarse con otra dentro del mismo hipervisor el tráfico no fluye fuera del host físico:
• Difuminación de línea de diferenciación de responsabilidades entre departamentos de sistemas y de comunicaciones.
• Necesidad de consumo de CPU en los host físicos para gestión del tráfico de red en los vSwitches o adquisición de tarjetas NIC específicas para realizar el offload de dicho trabajo.
• Imposibilidad de aplicar políticas de seguridad y QoS que sean consistentes (en configuración y gestión) con el resto de la arquitectura de red
Solución hasta el momento
Existen maneras de solventar algunas de estas problemáticas:
1. Externalización de los trabajos de red con NIC Hardware especiales
Los problemas de performance, relativos al uso de ciclos de CPU para gestionar el tráfico de red en el los vSwitches, puede ser solventado mediante la externalización de este trabajo a unas NICs con Hardware especializado gracias a la tecnología Single Root I/O Virtualization (SR-IOV).
Este método tiene ciertos problemas y es que hace necesaria la adquisición de nuevo Hardware especializado, además de que la BIOS de los equipos en los que se pretenda instalar lo soporten.
A esto hay que sumar que se requerirá también la instalación de los drivers específicos de dichas NICs, los cuales tendrán que ser compatibles con el sistema operativo sobre el que se ejecute el hipervisor.
Si a lo comentado se le añade que tan solo se solventa el problema derivado del rendimiento del procesado de red en los entornos de virtualización, hace que en algunos casos se deseche esta implementación.
2. Incorporación de switches software dentro de las plataformas virtuales.
Debido a que varios de los hipervisores presentes en el mercado, han liberado una API para poder desarrollar productos que se integren con sus soluciones de virtualización, existen algunos fabricantes que han creado switches software que implementan funcionalidades avanzadas que pueden ser instalados en los sistemas operativos que gestionan los hipervisores.
Esta solución no compensa el incremento de CPU necesitado en los host físicos que albergan las máquinas virtuales, es más, puede que lo aumente, además de implicar más elementos de gestión a la plataforma y de complicar el despliegue y el mantenimiento de la solución, sin sumar el aumento de coste, tanto de compra como mantenimiento, que tienen este tipo de switches software.
Solución con nuevos protocolos ( EVB / VNLink )
Existe una nueva solución, la configuración de nuevas funcionalidades de la propagación de los interfaces virtuales a los switches físicos de red, como la estandar Edge Virtual Bridging (EVB) y la tecnología propietaria Virtual Network Link (VNlink).
Estos métodos consisten en propagar las interfaces de red de los servidores virtualizados de manera que puedan ser considerados como interfaces físicos propios por los switches físicos a los que se conecta el host que alberga dichas máquinas virtuales.
Al considerar las interfaces de las máquinas virtuales como interfaces físicos propios, se les pueden aplicar las mismas políticas de securización, gestión o configuración que el resto de los interfaces del switch, mejorando todos los aspectos negativos relacionados con la visibilidad y falta de funcionalidades que se comentaron como problemas de los entornos virtualizados.
Los switches físicos pueden “descubrir” las interfaces de las máquinas gracias a la configuración de ciertos protocolos que permiten dicha visibilidad entre el hipervisor y los switches.
Existe algún protocolo propietario como VN-Tag (VNLink), mediante el cual se añaden unos nuevos tags (que deberán ser soportados por todo el Hardware por que fluyan) los cuales permiten "ver" las vNICs de las máquinas virtuales en los switches físicos, como si fuesen interfaces reales para ellos.
Pero, por otro lado existe VEPA. Con VEPA el tráfico fluye por los switches físicos externos sin necesidad de añadir tag adicionales, por lo que se tiene completa visibilidad de él, a parte de poder configurar los interfaces virtuales a los cuales está conectado la VM como si fuese físicos y, además, no el tráfico de red no consume ciclos de CPU (al ser gestionado el tráfico por los switches físicos). Tan solo hay que tener en cuenta que se requerirá un mayor ancho de banda de las interfaces del host físico, lo cual no es problema debido a la normalización de las NICs de 10G:
Gracias a la funcionalidad Multichannel de VEPA, permite una gran flexibilidad de configuración al poder hacer convivir varios tipos de conexión de las máquinas virtuales con el exterior (Virtual Ethernet Switch (vSwitch habitual de los hipervisores), VEPA o mapeo directo) dentro de un mismo hipervisor:
Por el momento, este tipo de implementaciones necesitan de componentes adicionales que deberán ser instalados en los Host que mantienen los hipervisores pero no será así en el futuro (en KVM ya se encuentra soportado nativamente).
• Pérdida de visibilidad del tráfico entre máquinas virtuales dentro del mismo host físico, ya que si una máquina virtual quiere comunicarse con otra dentro del mismo hipervisor el tráfico no fluye fuera del host físico:
Ilustración 15 –Comunicación interna por vSwitch entre VMs dentro de mismo Host físico
• Necesidad de consumo de CPU en los host físicos para gestión del tráfico de red en los vSwitches o adquisición de tarjetas NIC específicas para realizar el offload de dicho trabajo.
• Imposibilidad de aplicar políticas de seguridad y QoS que sean consistentes (en configuración y gestión) con el resto de la arquitectura de red
Solución hasta el momento
Existen maneras de solventar algunas de estas problemáticas:
1. Externalización de los trabajos de red con NIC Hardware especiales
Los problemas de performance, relativos al uso de ciclos de CPU para gestionar el tráfico de red en el los vSwitches, puede ser solventado mediante la externalización de este trabajo a unas NICs con Hardware especializado gracias a la tecnología Single Root I/O Virtualization (SR-IOV).
Ilustración 16 –Hardware especifico para externalizar del hipervisor el procesado de red
Este método tiene ciertos problemas y es que hace necesaria la adquisición de nuevo Hardware especializado, además de que la BIOS de los equipos en los que se pretenda instalar lo soporten.
A esto hay que sumar que se requerirá también la instalación de los drivers específicos de dichas NICs, los cuales tendrán que ser compatibles con el sistema operativo sobre el que se ejecute el hipervisor.
Si a lo comentado se le añade que tan solo se solventa el problema derivado del rendimiento del procesado de red en los entornos de virtualización, hace que en algunos casos se deseche esta implementación.
2. Incorporación de switches software dentro de las plataformas virtuales.
Debido a que varios de los hipervisores presentes en el mercado, han liberado una API para poder desarrollar productos que se integren con sus soluciones de virtualización, existen algunos fabricantes que han creado switches software que implementan funcionalidades avanzadas que pueden ser instalados en los sistemas operativos que gestionan los hipervisores.
Ilustración 17 –Switches software avanzados en los hipervisores
Esta solución no compensa el incremento de CPU necesitado en los host físicos que albergan las máquinas virtuales, es más, puede que lo aumente, además de implicar más elementos de gestión a la plataforma y de complicar el despliegue y el mantenimiento de la solución, sin sumar el aumento de coste, tanto de compra como mantenimiento, que tienen este tipo de switches software.
Solución con nuevos protocolos ( EVB / VNLink )
Existe una nueva solución, la configuración de nuevas funcionalidades de la propagación de los interfaces virtuales a los switches físicos de red, como la estandar Edge Virtual Bridging (EVB) y la tecnología propietaria Virtual Network Link (VNlink).
Estos métodos consisten en propagar las interfaces de red de los servidores virtualizados de manera que puedan ser considerados como interfaces físicos propios por los switches físicos a los que se conecta el host que alberga dichas máquinas virtuales.
Ilustración 18 – Propagación de interfaces virtuales a switches físicos
Al considerar las interfaces de las máquinas virtuales como interfaces físicos propios, se les pueden aplicar las mismas políticas de securización, gestión o configuración que el resto de los interfaces del switch, mejorando todos los aspectos negativos relacionados con la visibilidad y falta de funcionalidades que se comentaron como problemas de los entornos virtualizados.
Los switches físicos pueden “descubrir” las interfaces de las máquinas gracias a la configuración de ciertos protocolos que permiten dicha visibilidad entre el hipervisor y los switches.
Existe algún protocolo propietario como VN-Tag (VNLink), mediante el cual se añaden unos nuevos tags (que deberán ser soportados por todo el Hardware por que fluyan) los cuales permiten "ver" las vNICs de las máquinas virtuales en los switches físicos, como si fuesen interfaces reales para ellos.
Pero, por otro lado existe VEPA. Con VEPA el tráfico fluye por los switches físicos externos sin necesidad de añadir tag adicionales, por lo que se tiene completa visibilidad de él, a parte de poder configurar los interfaces virtuales a los cuales está conectado la VM como si fuese físicos y, además, no el tráfico de red no consume ciclos de CPU (al ser gestionado el tráfico por los switches físicos). Tan solo hay que tener en cuenta que se requerirá un mayor ancho de banda de las interfaces del host físico, lo cual no es problema debido a la normalización de las NICs de 10G:
Ilustración 19 – Distribución de switches virtuales en las capas de la arquitectura
Ilustración 20 – Distribución de switches virtuales en las capas de la arquitectura
Por el momento, este tipo de implementaciones necesitan de componentes adicionales que deberán ser instalados en los Host que mantienen los hipervisores pero no será así en el futuro (en KVM ya se encuentra soportado nativamente).
Multihoming y movilidad inter-DC de VMs
Para proporcionar alta disponibilidad de los servicios, o para poder manejar las cagas de trabajo de cada Data Center, muchas veces se hace necesario permitir la movilidad de las máquinas virtuales entre los diferentes DCs.
Desde el punto de vista de la red tradicional puede llegar a ser muy complicado dar soporte a este tipo de movimientos si se quiere minimizar el impacto sobre el servicio debido a los cortes en la comunicación, ya que cuando se hacen movimientos de carga es muy probable que se produzcan flujos no optimizados (traffic trombons) en las cuales las comunicaciones tienen que transcurrir varias veces por la WAN antes de devolver la respuesta al cliente (del mismo modo que pasaba en el anterior ejemplo de las VXLANs y vShield).
Solución hasta el momento
No se pueden enumerar aquí todas las soluciones actuales a esta problemática, ya que cada diseño es diferente, pero si se tiene presente la complejidad de los flujos de comunicación cuando las máquinas virtuales se mueven de un DC a otro (consultar entrada en el blog sobre ejemplos de movilidad de VMs entre DCs) y las dependencias del conexionado externo con los ISPs (ver entrada en el blog sobre ejemplos de conectividad con ISPs) se puede llegar a la conclusión de que, cualquier diseño de arquitectura que se realice para dar soporte a este tipo de comunicaciones, utilizando las herramientas actuales, se encontrará lleno de carencias que muchas veces son suplidas mediante Hardware (costosos equipos) o con complejas configuraciones de la plataforma de red.
Solución con nuevos protocolos ( LISP, HIP, RANGI, Ivip, ... )
Existen dos métodos para abordar esta problemática: las integraciones entre dispositivos (por ejemplo, que la plataforma virtual "hable" con los balanceadores globales) y la creación de nuevos protocolos, que es lo que se está revisando en esta entrada.
Existen múltiples protocolos que intentan dar solución a este problema, tal y como puede verse en este enlace, sin estar ninguno realmente extendido o implementado en redes importantes, pero hay uno que está siendo impulsado por Cisco: Locator/ID Separation Protocol (LISP).
Lo primero que hay que decir de LISP es un protocolo que está siendo estudiado por el Internet Engineering Task Force (IETF), y que todavía no se recomienda instalar en redes de producción, más allá de tareas de experimentación.
LISP se basa en separar la localización de la identificación de los servidores, es decir, crear dos espacios de nombramiento, uno que sería el routing locator RLOC (donde está conectado el cliente) y el identificador EID (quién es el cliente). Ambos identificadores pueden ser IPs, coordenadas GPS, MACs, ....
Los routers LISP realizan el mapeo entre EID y RLOC de modo transparente a los clientes finales. Esos mapeos son guardados y distribuidos ya que será esta la información necesaria para resolver la dirección final de los clientes a la cual deben ser enviados los paquetes.
Para poder enviar los paquetes de forma transparente realiza un encapsulado IP-in-IP, de manera que, si una máquina virtual se mueve de un DC a otro, el tráfico es encapsulado hasta el DC donde residirá la máquina virtual, de manera que no exista ningún tipo de tromboning, como puede verse en este enlace:
Mediante esta técnica, el tráfico se envía directamente a la localización correcta sin necesidad de cambios de IP en el servidor ni en los elementos de red intermedios, conservando además la conexión, la cual no se corta.
Aunque en la conexión no se rompa, en las pruebas que se están realizando, se están encontrando problemas con retardos importantes en el reestablecimiento de la conexión tras los movimientos de las VMs. Este problema, y otros que están saliendo a la luz con los experimentos (por ejemplo, no se tiene claro el comportamiento ante ataques DoS) dan una clara idea del estado de desarrollo de esta tecnología por el momento.
En resumen, la falta de adopción por parte de los fabricantes de este tipo de protocolos, así como el estado experimental de ellos, hace que no puedan ser explotados en la vida real por el momento, y tal vez no salgan adelante debido a las soluciones, mucho más sencillas, que pueden lograrse a día de hoy mediante el uso de SDN o integraciones entre los compornentes de la solución, no obstante es una posible solución (por el medio de "nuevo protocolo") al problema de los movimientos de máquinas virtuales.
Desde el punto de vista de la red tradicional puede llegar a ser muy complicado dar soporte a este tipo de movimientos si se quiere minimizar el impacto sobre el servicio debido a los cortes en la comunicación, ya que cuando se hacen movimientos de carga es muy probable que se produzcan flujos no optimizados (traffic trombons) en las cuales las comunicaciones tienen que transcurrir varias veces por la WAN antes de devolver la respuesta al cliente (del mismo modo que pasaba en el anterior ejemplo de las VXLANs y vShield).
Solución hasta el momento
No se pueden enumerar aquí todas las soluciones actuales a esta problemática, ya que cada diseño es diferente, pero si se tiene presente la complejidad de los flujos de comunicación cuando las máquinas virtuales se mueven de un DC a otro (consultar entrada en el blog sobre ejemplos de movilidad de VMs entre DCs) y las dependencias del conexionado externo con los ISPs (ver entrada en el blog sobre ejemplos de conectividad con ISPs) se puede llegar a la conclusión de que, cualquier diseño de arquitectura que se realice para dar soporte a este tipo de comunicaciones, utilizando las herramientas actuales, se encontrará lleno de carencias que muchas veces son suplidas mediante Hardware (costosos equipos) o con complejas configuraciones de la plataforma de red.
Solución con nuevos protocolos ( LISP, HIP, RANGI, Ivip, ... )
Existen dos métodos para abordar esta problemática: las integraciones entre dispositivos (por ejemplo, que la plataforma virtual "hable" con los balanceadores globales) y la creación de nuevos protocolos, que es lo que se está revisando en esta entrada.
Existen múltiples protocolos que intentan dar solución a este problema, tal y como puede verse en este enlace, sin estar ninguno realmente extendido o implementado en redes importantes, pero hay uno que está siendo impulsado por Cisco: Locator/ID Separation Protocol (LISP).
Lo primero que hay que decir de LISP es un protocolo que está siendo estudiado por el Internet Engineering Task Force (IETF), y que todavía no se recomienda instalar en redes de producción, más allá de tareas de experimentación.
LISP se basa en separar la localización de la identificación de los servidores, es decir, crear dos espacios de nombramiento, uno que sería el routing locator RLOC (donde está conectado el cliente) y el identificador EID (quién es el cliente). Ambos identificadores pueden ser IPs, coordenadas GPS, MACs, ....
Los routers LISP realizan el mapeo entre EID y RLOC de modo transparente a los clientes finales. Esos mapeos son guardados y distribuidos ya que será esta la información necesaria para resolver la dirección final de los clientes a la cual deben ser enviados los paquetes.
Para poder enviar los paquetes de forma transparente realiza un encapsulado IP-in-IP, de manera que, si una máquina virtual se mueve de un DC a otro, el tráfico es encapsulado hasta el DC donde residirá la máquina virtual, de manera que no exista ningún tipo de tromboning, como puede verse en este enlace:
Ilustración 21 – Uso de la tunelizacion LISP en movimientos de VMs
Mediante esta técnica, el tráfico se envía directamente a la localización correcta sin necesidad de cambios de IP en el servidor ni en los elementos de red intermedios, conservando además la conexión, la cual no se corta.
Aunque en la conexión no se rompa, en las pruebas que se están realizando, se están encontrando problemas con retardos importantes en el reestablecimiento de la conexión tras los movimientos de las VMs. Este problema, y otros que están saliendo a la luz con los experimentos (por ejemplo, no se tiene claro el comportamiento ante ataques DoS) dan una clara idea del estado de desarrollo de esta tecnología por el momento.
En resumen, la falta de adopción por parte de los fabricantes de este tipo de protocolos, así como el estado experimental de ellos, hace que no puedan ser explotados en la vida real por el momento, y tal vez no salgan adelante debido a las soluciones, mucho más sencillas, que pueden lograrse a día de hoy mediante el uso de SDN o integraciones entre los compornentes de la solución, no obstante es una posible solución (por el medio de "nuevo protocolo") al problema de los movimientos de máquinas virtuales.
No hay comentarios:
Publicar un comentario