Llegamos a ustedes gracias a:



Reportajes y análisis

Opciones de interconexión de centros de datos de capa 2

[13/09/2010] Durante más de 20 años hemos estado utilizando conectividad de Capa 3 que funciona con protocolos de enrutamiento dinámico para canalizar el tráfico entre los centros de datos, pero la adopción de la virtualización y las tecnologías de geo-agrupación nos obliga a revisar nuestros modelos de interconexión de centros de datos (data center interconnect o DCI).

Aprovechar el poder de la virtualización permite a las organizaciones ver y tratar a sus recursos informáticos como un conjunto de recursos globales, sin restricciones de fronteras de los centros de datos individuales. Los recursos pueden abarcar varios edificios, áreas metropolitanas, o –teóricamente- incluso países. Esto básicamente significa que puede aumentar su poder de cómputo colectivo en un centro de datos que necesita de un "préstamo" de los recursos, de un centro de datos que tiene capacidad de sobra en ese momento. Esta tarea se consigue al mover máquinas virtuales entre los centros de datos.
Todos los proveedores de virtualización más importantes, tales como VMware, Xen y Microsoft apoyan el concepto de migración de máquinas virtuales en vivo, dentro del cual se puede mover máquinas virtuales en vivo desde un host físico (servidor) a otro sin tener que apagarlas o sufrir una interrupción de las conectividad de las aplicaciones  (hay una breve pausa, pero no lo suficiente como para cortar sesiones TCP).
Ahora la pregunta es ¿qué pasa con la configuración de red -específicamente la dirección IP / máscara de subred / Puerta de enlace predeterminada- de la máquina virtual cuando se mueve del centro de datos A hacia el centro de datos B?
La respuesta es que siguen siendo los mismos. Bueno, para ser precisos, siguen siendo los mismos cuando se lleva a cabo la migración en vivo. Sin embargo, si la máquina virtual se apaga en un centro de datos, se copia en ese estado en el centro de datos B y entonces se enciende, el administrador de servidor tendrá que cambiar la dirección IP en el sistema operativo que se ejecuta dentro de la máquina virtual para que coincida con la configuración requerida en el centro de datos B, el de destino.
Esta, sin embargo, no es una solución muy elegante, ya que requerirá que todas las conexiones que se reestablezcan, sin considerar la posible creación de un caos en las aplicaciones debido al cambio de dirección IP, ya que todos sabemos cómo les gusta a los desarrolladores utilizar direcciones IP estáticas en lugar de nombres DNS. Así que por el bien de nuestra discusión, estamos manteniendo la misma dirección IP, mientras que las máquinas virtuales en vivo se mueven entre los centros de datos.
En el nivel de red, ahora ambos, el centros de datos de origen y de destino necesitan acomodar la misma subred IP donde se encuentran las máquinas virtuales. Tradicionalmente, tener la misma subred IP en ambos centros de datos en general se considera una mala configuración o un diseño muy malo. Por consiguiente, también significa que la capa 2, también conocida como VLAN, debe ser extendida entre esos centros de datos, y esto constituye un cambio importante en la forma en que ha sido hecha la interconexión de centros de datos tradicionales.
El otro acontecimiento que nos obliga a volver a examinar nuestros modelos de interconexión de centros de datos es el geo-agrupamiento, lo que implica el uso de las tecnologías de clustering de aplicaciones existente, mientras que la colocación de los servidores, los miembros de la agrupación, en los centros de datos por separado. El principal motivo para hacer eso es lograr una recuperación de desastres (DR) muy rápida. Después de todo, solo se necesita la recuperación automática contra fallas mediante computadoras redundantes para reestablecer el servicio fuera del centro de datos de DR.
La recuperación automática usualmente significa que el miembro del cluster en stand by, el que está en el sitio de DR, se hace cargo de la dirección IP del miembro del clúster previamente activo para permitir la supervivencia de las sesiones TCP. En la capa de red de nuevo se traduce en el hecho de que ambos centros de datos que alojan miembros del clúster, necesitan acomodar las mismas subredes IP y extender las redes VLAN en los servidores en clúster que están conectados.
Algunas de las soluciones de clustering, por ejemplo Microsoft Server 2008, actualmente permiten a los miembros del cluster separarse opcionalmente por nivel 3, lo que significa que no tiene que pertenecer a la misma subred IP y residir en la misma VLAN. Estas soluciones, sin embargo, dependen de actualizaciones de DNS dinámico y de la infraestructura de DNS para propagar un nuevo mapeo de nombre a dirección IP a través de la red para reflejar el cambio de la dirección IP de la aplicación, una vez que la restauración de clúster se produce. Esto introduce otra capa de complejidad y perfora un agujero en el concepto del uso del geo-clustering para una RD rápida.
Lo que podemos hacer
Ahora que entendemos por que la interconexión de centros de datos se está transformando, echemos un vistazo a las tecnologías en el conjunto de herramientas de diseño de red que pueden ayudar a resolver el rompecabezas de subredes IP y extensiones VLAN a través de múltiples centros de datos.
* Puerto del canal: Los centros de datos se pueden interconectar con tecnología de puerto canalización, que puede ejecutarse en la parte superior de la fibra oscura (debido a las distancias, el cableado de cobre es muy poco probable), en longitudes de onda xWDM o Ethernet sobre pseudo-cables MPLS (Capa 2). Los canales de puerto pueden ser establecidos tanto de forma estática como dinámica, usando el protocolo LACP (IEEE 802.3ad).
* Canal de puerto multi-chasis: El canal de puerto multi-chasis es un caso especial en el que los enlaces de los miembros del canal de puerto se distribuyen a través de varios switches. El valor añadido es, por supuesto, que el canal del puerto puede sobrevivir a una falla entera del switch. Una aplicación popular de esta tecnología es de Cisco, con Virtual Switching System (VSS) en switches Catalyst series o un puerto virtual de canal (VPC) en los switches Nexus de la serie 7000 y 5000. Nortel tiene una implementación similar llamada Split Multi-Link Trunking (SMLT). El canal de puerto multi chasis puede correr sobre el mismo conjunto de tecnologías que el canal de puerto tradicional, y también puede ser establecido estáticamente o negociado dinámicamente.
* Con ambos: Canales de puerto y canales de puerto Multi-Chasis, la extensión de VLAN se consigue mediante el envío (también conocido como trunking) de VLAN entre los centros de datos a través del canal del puerto. Sin configuración especial, se extiende de forma predeterminada el Spanning Tree Protocol, la fusión de dominios STP de ambos centros de datos.
Esto es a menudo un resultado no deseado debido a los problemas, como los famosos bucles de capa 2, que de un centro de datos se puede propagar e impactar el centro de datos. Los métodos de filtrado Bridged Protocol Data Units o BPDU son usualmente empleados para aislar el STP, y por lo tanto las fallas de dominios entre los centros de datos. La accesibilidad de información del Media Access Control (MAC) se obtiene a través de la inundación de tráfico unicast a través de los enlaces de puertos canalizados, lo cual es común y no es una forma particularmente eficiente de aprender MAC adrresess en un ambiente de puente transparente. El uso de canales de puerto como DCI es relativamente simple e intuitivo, sin embargo, sufre de una escalabilidad pobre más allá de dos centros de datos y por lo tanto no encaja bien en despliegues DCI más grandes.
* Ethernet sobre MPLS: Esta es la más antigua de las tecnologías de pseudo-cable en la cual el backbone MPLS es usado para establecer un conducto lógico, llamado un pseudo cable, para hacer túnel de capa 2 -en este caso Ethernet- a través de frames. El EoMPLS alguna vez es nombrado como VPN de capa 2.
Los frames Etnernet de capa 2 son recogidos en un lado, encapsulados, cambiados de etiqueta a través de la red troncal MPLS, desencapsulados en el otro lado y luego son retransmitidos como frames de capa 2 nativos hacia su destino. Los frames pueden incluir una etiqueta de trunking 802.1q si transportan múltiples VLAN a través del mismo seudo cable.
Los seudo cables EoMPLS hacen que ambos lados aparezcan como si estuvieran conectados con un cable largo físico. Si está pensando que eso suena similar a los Canales de puerto o Port Channels, tiene razón. Dejando a un lado el backbone MPLS en el medio, los pseudo cables EoMPLS comparten características similares con la solución DCI basada en canales de puerto de la que hemos hablado antes.
Al igual que con los canales de puerto, los BPDU son enviados de manera predeterminada a través de pseudo-cables que fusionan dominios STP, y el filtrado BPDU puede ser empleado para prevenir eso. El aprendizaje de MAC se sigue haciendo a través de las inundaciones, por lo que el EoMPLS no cambia ese concepto ineficiente.
De hecho estas dos tecnologías, incluso se pueden superponer una encima de la otra y, como hemos mencionado brevemente antes, a veces los canales del puerto se construyen a través de los pseudo cables EoMPLS para ofrecer conectividad DCI y extensión de VLAN.
Si una red troncal MPLS es demasiado para que usted la maneje, el EoMPLS puede ejecutarse en la parte superior del backbone usando tunneling GRE. Recuerde que el intercambio de etiqueta MPLS ocurre aún a través de túneles GRE, así que usando EoMPLSoGRE ahora tenemos una capa más de protocolo para resolver problemas y para tener en cuenta, pero el lado positivo es que no hay backbone MPLS que mantener.
El uso de túneles GRE también tiene implicaciones en el tamaño de la Máxima Unidad de Transmisión (MTU) a ser soportada a través del backebone IP, debido a que el uso del protocolo GRE añade 24 bytes de sobrecarga (20 bytes de cabecera IP exterior, 4 bytes de cabecera GRE) por cada paquete, además del tamaño de la pila de la etiqueta MPLS encapsulada.
* VPLS: Servicios de LAN privada virtual extienden el EoMPLS al permitir la conectividad multipunto, que se logra a través de una serie de pseudo-cables que corren entre los routers VPLS Provider Edge (PE). Los extremos de los pseudo-cables pueden ser definidos estáticamente o descubiertos automáticamente usando multi-protocolo BGP (BGP-MP).
Los VPLS ofrecen un aislamiento de dominio STP de forma predeterminada, lo cual es una mejora con respecto a EoMPLS y los Canales de Puerto DCI; sin embargo, lograr la redundancia de borde con los VPLS no es tarea fácil y los diseñadores de redes deben ser astutos para asegurarse de que los lazos entre los centros de datos están rotos.
Los VPLS no traen buenas noticias sobre el aprendizaje de direcciones MAC, el cual sigue siendo logrado por la inundación de tráfico unicast desconocido en toda la red a través de la pseudo-cables, sin embargo, una vez sintonizados correctamente, los VPLS ofrecen una muy eficaz interconexión de centro de datos.
Así como EoMPLS, los VPLS tienen una variante VPLSoGRE para entornos no-MPLS y como EoMPLSoGRE, añade 24 bytes de GRE generales en comparación con los VPLS tradicionales, así que la interfase MTU tiene que estar correctamente planificada a través del backbone.
Uno de los puntos más interesantes: en caso de que el MP-BGP se utilice para detectar automáticamente los extremos de los pseudo-cables, los túneles GRE son todavía necesarios para ser creados manualmente, lo que socava las ventajas de la utilización de MP-BGP en el despliegue de VPLSoGRE.
Dos enfoques propietarios
Todas las tecnologías de interconexión de centros de datos de capa 2 discutidas hasta ahora son estándares de la industria. Veamos ahora dos tecnologías innovadoras de propiedad de Cisco.
* Advance-VPLS: A-VPLS-es otra variante de la tecnología VPLS, pero introduce varias características nuevas, que hacen que se destaque. En primer lugar, mitiga las dificultades en proporcionar redundancia DCI perimetral sin utilizar ningún mecanismo de lujo de secuencias de comandos. Para lograrlo, A-VPLS se construye en la parte superior del Sistema Virtual de switching de Cisco (VSS-1440) disponible en switches Catalyst 6500.
En segundo lugar, utiliza técnicas de hashing de canal de puerto, que realizan el cálculo de la información de la Capa 2, Capa 3 y Capa 4 para determinar la interfase de salida del switch de borde DCI. Esto permite un excelente intercambio de carga de tráfico entre centros de datos sobre múltiples enlaces DCI.
En tercer lugar, a medida que los paquetes atraviesan los enlaces DCI, los A-VPLS introducen etiquetas de flujo MPLS opcional para mejorar aún más el balance de carga de tráfico a través del núcleo conmutado de etiqueta.
En cuarto lugar, se simplifica considerablemente la configuración del usuario, lo que intuitivamente se asemeja a la configuración de una interfase de troncal en los switches de Cisco con una adición de muy pocos comandos relacionados con MPLS. Ya no hay necesidad de la configuración de VLAN VFI, lo cual es un gran ahorro de tiempo y tiene menores posibilidades de error humano.
En cuanto a requisitos de conectividad de red subyacente, una VPLS-se puede ejecutar en diversos medios de transporte, con tres opciones claramente identificables: a) Core de Nivel 2 o sin ningún core, b) Core conmutado de etiqueta de capa 3 y c) Core conmutado no etiquetado de capa 3.
En el caso del Core de capa 2, los A-VPLS se puede ejecutar en la parte superior de las tecnologías, tales como EoMPLS e incluso VPLS (sí, un VPLSoVPLS). Si la red se simplifica para no tener un núcleo de DCI, a continuación, la fibra oscura o la longitud de onda xWDM pueden ser usadas para conectividad back-to-back entre los A-VPLS. La opción de Core conmutado de etiqueta de capa 3 puede hacer uso del tradicional servicio MPLS VPN interconectando sitios A-VPLS, en cuyo caso ocurrirá algún intercambio de etiqueta entre los MPLS VPN PE y los A-VPLS PE (para las interfases de bucle invertido de routers A-VPLS-PE).
Por último, un Core conmutado no etiquetado de nivel 3 hace uso de túneles GRE creados entre todos los participantes A-VPLS PE, mientras que la conmutación de etiquetas sucede dentro de la encapsulación GRE. La imitación del comportamiento de los VPLS y  los ambientes de Spanning Tree son automáticamente aislados entre los centros de datos para limitar el dominio de falla de Capa 2 y prevenir que un centro sea impactado por problemas de STP del otro.
El aprendizaje de direcciones MAC es, de nuevo, realizado a través de las inundaciones de unicast desconocidas, después de todo, los A-VPLS son una variante de VPLS y ese comportamiento no cambia. El tráfico inundado consume algo de ancho de banda del DCI, sin embargo, las tablas de direcciones MAC se llenarán muy rápidamente antes de que este tráfico cause alguna preocupación, por lo que normalmente no es un tema a considerar. Incluso con los requerimientos actuales específicos de los switches Catalyst 6500 (Sup720) y las tarjetas SIP-400, línea para hacer uso de la tecnología A-VPLS (esto va a cambiar con el tiempo), es una excelente opción para un eficiente DCI de Capa 2.
* Virtualización de transporte de Superposición (OTV): Esta es una tecnología emergente que es diferente a cualquier otra solución de interconexión de centros de datos que hemos discutido hasta ahora. Puede llamarlo un protocolo de evolución, que utiliza las lecciones aprendidas del pasado de las soluciones de DCI y las integra en unan operación de protocolo inherente. Es agnóstico respecto al y puede ser igualmente soportado por un backbone IP o MPLS, lo cual le confiere una gran versatilidad.
Cisco llama al concepto subyacente de reenvío de tráfico OTV "enrutamiento de MAC", ya que se comporta como si estuviera enrutando frames de Ethernet sobre el transporte DCI. OTV utiliza un protocolo de plano de control para propagar de forma proactiva la accesibilidad a de direcciones MAC antes que se le permita el paso al tráfico, lo que elimina la dependencia de los mecanismos de inundaciones para aprender direcciones MAC o para retransmitir multicasts desconocidos.
Al mantener el tráfico innecesario a distancia de la interconexión del centro de datos se consigue una mejor escalabilidad de ancho de banda y se evita el desperdicio de ancho de banda. El aprendizaje proactivo de MAC es uno de los diferenciadores OTV únicos.
La redundancia perimetral DCI se consigue teniendo dispositivos de borde OTV que automáticamente eligen un dispositivo de borde autoritario (AED) en un una base per-VLAN, la cual permite el intercambio de carga de tráfico mientras se simplifica el modelo de despliegue. Solo el AED es responsable por enviar tráfico VLAN hacia dentro y hacia fuera en el centro de datos, lo cual garantiza una topología libre de bucles a través del DCI. El aislamiento del Spanning Tree entre los data centers es inherente dentro del protocolo, lo cual se está convirtiendo en un estándar de buenas prácticas.
Una característica OTV adicional que vale la pena mencionar es la replicación del tráfico multicast, que se lleva a cabo por los routers backbone, en lugar de por dispositivos de borde OTV DCI en el centro de datos donde reside la fuente multicast, también conocida como replicación de cabecera. Posteriormente, la carga en esos dispositivos de borde se reduce significativamente, sin embargo, la desventaja es que los routers backbone ahora necesitan estás conscientes de cierta información de ruteo de algunos clientes.
OTV actualmente requiere switches Nexus 7000 en el borde y núcleo habilitado para multicast (para el protocolo del plano de control). El requerimiento de multicast se levantará en los lanzamientos de software próximos de Nexus 7000 NX-OS.
A estas alturas debe ver que es más fácil hablar que hacer una extensión de las redes VLAN a través de los centros de datos; sin embargo, no hemos terminado todavía. Tener conexiones de Capa 2 es solo la mitad de la historia, ahora necesitamos proveer la forma de conectar de entrada y salida todas esas VLAN y para eso necesitamos traer conectividad de nivel 3 a la mezcla.
El método más fácil es mantener todas las funcionalidades de nivel 3 en un centro de datos y ampliar la capa 2 al otro. Esta configuración simplifica el manejo de enrutamiento dentro y fuera de las VLAN extendidas; sin embargo, cuando el tráfico entra en una VLAN extendida en el centro de datos donde la funcionalidad de Capa 3, será enviado a través del enlace DCI si el servidor de destino está en el otro centro de datos.
Esta solución aumenta la carga en la interconexión del centro de datos y la latencia por el tráfico que necesita atravesar. Si la puerta de enlace por defecto del servidor está en el otro centro de datos (recuerde, en este escenario solo hay una entidad de capa 3 para esa VLAN), el tráfico que sale de la VLAN también cruzará el enlace DCI con la misma latencia potencial y los problemas de ancho de banda.
Para proporcionar redundancia de capa 3 para VLAN extendidas, cada uno de los centros de datos debe tener un componente de capa de 3 para esas VLAN. Tan ventajoso como suena, la mayor preocupación en esta configuración es la simetría de tráfico, la cual se requiere para los dispositivos de estado, tales como firewalls y balanceadores de carga, que a menudo son parte de la instalación.
Sin simetría, el tráfico que entra a la VLAN extendida en el centro de datos A y luego trata de salir a través del Centro de Datos B será dejado caer, a menos que la información del estado de sesión se sincronice entre firewalls / balanceadores de carga en los centros de datos.
Si tal sincronización no existe, tendrá que asegurarse de que el tráfico de retorno sea reenviado de nuevo al centro de datos original, de donde provino la solicitud. Esto es logrado con mayor frecuencia utilizando técnicas de Source Network Address Translation (SNAT). Tan ineficiente como puede ser desde una perspectiva de latencia y ancho de banda, al menos funciona, a menos, claro, que el uso de NAT suspenda la aplicación.
Otros métodos incluyen la inyección / 32 rutas de host o el uso global de equilibrio de carga para dirigir el tráfico hacia el centro de datos real, donde se encuentra el servidor. También existen iniciativas más audaces de los proveedores, como Cisco, para realizar la integración del flujo de trabajo entre los componentes múltiples para ofrecer conjuntamente la solución que une las extensiones de interconexión de la Capa 2 y la Capa 3 del Centro de Datos. Además, permanezca atento a las nuevas tecnologías, como LISP (Localizador de identificación del Protocolo de separación), que abordan ese tema.
La interconexión del centro de datos está sin duda cambiando; pero antes de tirar lo que tiene, debe diseñar la solución para ser escalable y flexible mediante la selección de la tecnología que se ocupe de sus necesidades de conectividad desde todos los ángulos.
David Klebanov, Network World (US)