Arquitectura MultiDataCenter – Extensión de red L2

"Esta es la primera de una serie de entradas sobre el diseño de infraestructuras multi-DataCenter (red, almacenamiento y sistemas). En este caso se trata de aclarar la extensión de VLANs y direccionamientos a lo largo de varios Centros de Datos, o también llamado extensiones de Data Center (DCI)"

 

Aunque existen argumentos en contra de la extensión L2 de los Data Centers relacionados con las restricciones de latencia y ancho de banda que se encuentran en los enlaces inter-DC, o los costes asociados al despliegue de estas arquitecturas, se pretende dar un repaso a los principales conceptos relacionados con estas topologías.

 

Como primer paso hay que aclarar el origen de la necesidad de expandir una misma red a lo largo de varios Data Centers, entre los más destacables se encuentran:

•   Movilidad de cargas: Pensando en un despliegue de infraestructura de servidores virtualizados, al disponer de una misma red extendida, se pueden transferir máquinas virtuales de un Data Center a otro, sin las complicaciones de terceras herramientas o complicados sistemas de reconfiguración automática de servidores virtuales, posibilitando el reparto de cargas (Data Centers activo-activo) y el máximo aprovechamiento de recursos.

• Prevención de desastres y continuidad de sistemas: En caso de un desastre en uno de los centros, se pueden restablecer los servicios en un tiempo mínimo gracias a la posibilidad de creación de clusters extendidos entre varios Data Centers

• ·Minimizar el tiempo de parada: Esta ventaja es, en realidad, la suma de las dos anteriores. Al disponer de varios Centros de Datos activos, se pueden balancear los servicios prestados por un Data Center a otro diferente ante posibles actuaciones programadas que requieran parada de uno de estos centros.

Aislamiento de caminos

Antes de abordar las topologías y los protocolos asociados es necesario aclarar un concepto importante, el aislamiento de caminos en los enlaces de interconexión de Data Centers.

Cada vez más a menudo es necesario llevar a cabo una virtualización de la red, desde la creación de redes paralelas que presten acceso a Internet a los usuarios “invitados”, la segmentación departamental o la provisión de redes a varios clientes bajo una misma infraestructura. Esta diferenciación es necesario que se conserve en el enlace que une los Centros de Datos distribuidos.

Para llevar a cabo esta virtualización de manera sencilla se puede realizar un diseño con varios VRFs, de manera que se crearía un VRF por cada zona, a la cual se asociarían las diferentes redes/VLANs. Para aislar cada uno de los caminos en la interconexión de los Data Center se podría utilizar un enlace físico para cada uno de ellos, pero esto no sería eficiente y en la práctica se deben utilizan otras técnicas de virtualización del enlace. Si el enlace entre los Data Centers tiene más de un salto, se debe realizar algún tipo de túnel o recurrir a funcionalidades proporcionadas por los protocolos de interconexión de los Centros de Datos. 

Protocolos y topologías

Tradicionalmente se han extendido las VLANs de cada DC mediante protocolos como Frame-Relay o ATM, ya que el concepto de VLAN puede ser similar al conseguido mediante DLCIs y PVCs. También se han utilizado las llamadas Metro-Ethernet que es una VPN L2, en la que la red del proveedor transporta tramas Ethernet y donde las direcciones MAC son usadas para determinar el encaminamiento. Estos enfoques tienen como principal problema la escalabilidad y el aporte de servicios añadidos como QoS, encriptación, etc, por lo que actualmente suelen utilizarse otros protocolos como MPLS, como se verá a continuación.

La solución adoptada depende de varios factores fuera del dominio meramente técnico, como el coste o la disponibilidad del servicio por parte del proveedor, por ello se van a plantear la tres posibilidades de interconexión que puede proporcionar el ISP, apuntando a sus ventajas y deficiencias:

• Conectividad a nivel 1
  También llamada conectividad sobre fibra oscura, es el método más sencillo de despliegue pero no siempre está disponible, además hay que contar con el elevado coste de esta solución. 
  
  Al ser conectividad L1, puede ser utilizada para también extender la SAN.
  
  Puede ser utilizada tanto para arquitecturas de Data Center punto a punto como para topologías multipunto, gracias a la formación de anillos DWDM.
  

• Conectividad a nivel 2

Este método suele ser utilizado cuando no se puede disponer de fibra oscura ya sea por precio, disponibilidad o distancia entre Data Centers.

El protocolo utilizado más extensamente es MPLS ya que permite el aislamiento de caminios en el enlace mediante la utilización de etiquetas y por su capacidad de proveer conexiones del tipo any-to-any sin tener que mantener múltiples conexiones punto a punto.

Existen dos aproximaciones para realizar la conexión a nivel L2: Ethernet over MPLS (EoMPLS), para entornos punto a punto; y Virtual Private VLAN Service (VPLS), para multipunto.

Con EoMPLS  los operadores pueden ofrecer conectividad con servicios LAN transparentes garantizados, escalables y seguros. Además con el aprovisionamiento dinámico de MPLS, se mejora la gestión y manejabilidad de los túneles, reduciendo los problemas relacionados con su despliegue a gran escala.

EoMPLS permite, además, ofrecer gran ancho de banda a un coste menor, lo que unido a los mecanismos de QoS extremo a extremo garantizan el rendimiento de los servicios desplegados.

Mientras que EoMPLS es utilizado en entornos punto a punto, cuando existen varios DC el protocolo elegido es VPLS. Este protocolo forma un grupo de virtual switch instances (VSI), conectados utilizando Ethernet over MPLS en una topología full-mesh, consiguiendo actuar como un único switch general para todos los DC.

Aun así existen varios problemas de los vpls basadas en VLAN como la limitación del número de VLANs 4094 VLANs o la limitación de direcciones MAC que pueden gestionar, así como el tiempo de convergencia ante fallos o la transmisión de tráfico multicast.

• Conectividad de nivel 3
  Esta debería ser la última opción, debido a sus problemas de rendimiento (latencia, jitter, etc), ya que consiste en el encapsulamiento de los anteriores protocolos en un túnel GRE.
  
  Al existir este encapsulamiento adicional se deberá tener en cuenta que es necesario, para minimizar el efecto de la fragmentación de paquetes, disminuir el MTU de los Data Centers debido a la adicción de cabeceras que supone el protocolo GRE.
  
  Existen nuevas alternativas, como la nueva versión del protocolo L2TP, el denominado L2TPv3 que permite la multiplexación de enlaces punto a punto (pseudowires), del mismo modo que MPLS, además de aportar otras funcionalidades que minimizan el riesgo de creación de “blackholes” en el tráfico

Problemas a tener en cuenta

Tras abordar las topologías de Data Centers con redes expandidas, es necesario conocer los principales aspectos a tener en cuenta en el diseño de este tipo de soluciones: 

• ·         Aislamiento de protocolo Spanning-Tree

Es importante que cualquier problema L2 quede contenido en un único Data Center, por lo que el protocolo STP sea suprimido en los enlaces inter-site.

Este aislamiento también beneficia al rendimiento, ya que se no se extenderán los paquetes TCN producidos por los cambios de topología a nivel 2,  y cuyo efecto es la disminución del temporizador de la tabla CAM, provocando aumentos en el consumo de CPU por parte de los switches e incluso la pérdida de paquetes.

• ·         Prevención de bucles extremo a extremo

Al no disponer de protocolo Spanning-Tree  entre los DC (punto anterior) puede provocarse un bucle a nivel 2, por lo que hay que confiar en técnicas que eviten esta posibilidad, como los agregados de enlace en topologías punto a punto.

Por otro lado, aunque se eviten bucles con agregados en arquitecturas punto a punto, o  mediante los procedimientos del protocolo de interconexión (IP, MPLS, etc), puede existir un bucle global generado por la interconexión de varios DC mediante enlaces dobles, como puede verse a continuación:

Ilustración 1 – Bucle inter-DataCenter

Para evitar estos bucles existen tecnologías que pueden ser utilizadas, como por ejemplo VSS, o la utilización de la técnica de semáforos, mediante la cual solo uno de los uplinks del Data Center está activo, por lo que no pueden existir este tipo de bucles.

La metodología de semáforos utiliza la técnica de N-PE en backup, utilizando el Embedded Event Manager (EEM) para asegurarse de que solo uno de los nodos está activo por cada VLAN.

•            Blockholes
  
  Es importante propagar la caída del enlace pseudowire o los enlaces externos a los nodos que forman
  parte de la capa de agregación, por ejemplo extendiendo el fallo a los puertos configurados como
  MPLS port-mode,  para que no se formen blackholes. En las plataformas Cisco existen varios
  métodos, dependiendo de la plaforma, como la funcionalidad Remote Ethernet Port Shutdown de los
  routers ASR1000 o la utilización del EEM por parte de los Catalyst 6500, a parte del track en los
  grupos HSRP.

• ·         Optimización de rutas

Existe un problema claro al extender la capa 2 a lo largo de múltiples Data Centers y es la utilización de rutas no optimizadas al enviar paquetes al Gateway por defecto que reside en el Data Center remoto, no en al que está situado localmente, tal y como puede comprobarse en el siguiente esquema:

Ilustración 2 –Rutas sub-óptimas

Para mejorar este esquema se podrían formar grupos de VLANs y balancear entre los dos centros pero, si lo que se desea es suprimir estas rutas no optimizadas, existe la posibilidad de crear listas ACL que impidan la comunicación entre las direcciones MAC de los nodos HSRP, de tal manera que la IP virtual de default Gateway sea conservada a la vez por nodos residentes en diferentes Data Center, permitiendo que siempre el Default Gateway esté situado localmente. 

Nuevos protocolos

Debido al “fenómeno Cloud”, existe bastante innovación en tecnologías relacionadas con la interconexión de Centros de Datos, algunas de ellas provenientes del sector Open Source, aunque todavía tengan muy poco recorrido, como Quantum (http://wiki.openstack.org/Quantum) que forma parte del conglomerado de tecnologías OpenStack, pero una de las más interesantes es la desarrollada por Cisco para su gama de productos Nexus 7000 llamada Overlay Transport Virtualization (OTV).

OTV proporciona un medio de transporte L2 a lo largo de una infraestructura IP introduciendo el concepto de MAC routing mediante la compartición de un plano de control distribuido por la plataforma que actualiza la información de las direcciones MAC conectadas a cada Site, de modo que se limita el flooding de paquetes L2 por la infraestructura.

También con OTV se elimina la necesidad de creación de circuitos virtuales (pseudowires), lo que aporta cierto grado de flexibilidad e independencia de los protocolos subyacentes, tiene medios internos para evitar los bucles inter-site y mejora los tiempos de failover y el tratamiento del tráfico multicast.

También es remarcables que posee la capacidad de realizar el filtrado automático del tráfico FHRP, por lo que no hay que recurir al método mostrado en el punto anterior para evitar las rutas subóptimas al default Gateway.

Dimensionamiento de dispositivos Big-IP de F5

Algunos de los puntos más importantes a tener en cuenta en el dimensionameinto de una solución con los dispositivos BIG-IP de F5

Normalmente los dispositivos se dimensionan por un número determinado de parámetros determinados de forma fija por el hardware, pero en el caso de las plataformas BIG-IP, al ser a su vez un cúmulo de módulos que realizan diferentes funciones (hay que recordad que el BIG-IP no solo aporta el servicio de balanceo de su módulo LTM), hay que tener en cuenta los aspectos que se exponen a continuación:

Funcionalidades requeridas

La plataforma Big-IP incluye diferentes funcionalidades que se pueden licenciar, por lo que el primer paso será definir cuáles de estos módulos mejor se adaptan a la solución global que se busca.

1.     BIG-IP Local Traffic Manager (LTM)

Este es el componente básico y más conocido de la solución. Su cometido es realizar las tareas de balanceo de carga convirtiéndose en un full-proxy TCP entre los clientes y servidores.

El balanceo se puede realizar a nivel de aplicación, aunque existe la posibilidad de adquisición de un LTM básico en el cual solo se realiza a nivel TCP.

2.     Edge Gateway

Proporciona accesos remotos mediante la creación de VPNs SSL de usuario, de forma similar a otras soluciones como pueden ser el SSL Secure Access de Juniper.

3.     BIG-IP WAN Optimization Manager (WOM)

Proporciona optimización de WAN de un modo similar a los productos SteelHead de Riverbed, enviado patrones entre los dispositivos y reduciendo las necesidades de interacciones entre los extremos (chatty protrocols) aportando, por ejemplo, grandes mejoras en los tiempos de transmisión en protocolos como CIFS.

4.     BIG-IP Access Policy Manager (APM)

Realiza las tareas de un servidor RADIUS que integre los Servicios AAA (Autenticación, Autorización y Contabilidad) muy utilizadas por despliegues Wireless y otros como puedan ser proyectos de escritorios virtuales.

5.     BIG-IP Application Security Manager (ASM)

Es el firewall de aplicación integrado en el BIG-IP. Aunque aporta una securización muy fuerte contra todo tipo de ataques que los firewall tradicionales no son capaces de interceptar, su configuración y gestión puede llegar a ser bastante costoso si los servicios protegidos son bastante dinámicos, como puedan ser páginas web en continuo desarrollo.

6.     BIG-IP WebAccelerator (WBA)

Gracias al Offload de las tareas de encriptación, el caché, o la compresión de paquetes, se consigue la aceleración de prestación de páginas WEB y un consumo menor de ancho de banda.

7.     BIG-IP Link Controller (LC)

Este módulo, que también puede conseguirse como un producto a parte, controla los flujos de tráfico hacia las diferentes líneas externas de los proveedores ISP contratados dependiendo de diversos parámetros, como puedan ser errores o velocidad de acceso.

También tiene la capacidad de realizar compresión de la transmisión para minimizar el consumo de ancho de banda.

8.     BIG-IP Global Traffic Manager (GTM)

Realiza un balanceo selectivo entre Data Centers, lo que permite disminuir las interrupciones de servicio y mejora los tiempos de respuesta del servicio.

Este balanceo es posible gracias a la gestión de las entradas DNS asociadas a los diferentes servicios alojados simultáneamente en los diversos Data Centers.

           

Virtualización

Pueden surgir dos tipos de necesidades de virtualización de la plataforma que también influirán en los modelos finalmente adoptados:

1.     Conversión del BIG-IP en una máquina virtual.

Se puede disponer del BIG-IP en forma de Virtual Appliance, bajo el nombre de Virtual Edition. Hay que tener en cuenta que la elección de este despliegue condiciona mucho tanto las funcionalidades posibles como el rendimiento que se conseguirá con él.

2.     Virtualización del hardware BIG-IP, posibilitando varias instancias en un mismo dispositivo.

Existen ocasiones e las que es necesario virtualiza un hardware y correr sobre él varias instancias del Sistema Operativo, como por ejemplo hacen los Firewalls ASA de Cisco con los denominados “Contextos”. Esa necesidad viene dada principalmente por el requisito de una división lógica de la gestión y de recursos hardware (Multitenance).

La única gama de BIG-IP que permite esto son los productos Viprion. Los Viprion permiten dos grados de virtualización:

·         Particiones: En las que se separa la gestión pero no se puede hacer reserva de recursos.

·         Instancias: También llamadas vCMP. Permiten restringir la utilización de RAM y CPU a la vez que proporcionan el aislamiento de gestión.

Compatibilidad entre módulos

Una vez determinados los módulos requeridos, es necesario comprobar que pueden integrarse todos bajo un mismo BIG-IP, ya que cada hardware soporta un número concreto de módulos y, a parte, existen incompatibilidades que hacen que no puedan coexistir ciertos módulos a la vez bajo el mismo BIG-IP

Para aclarar lo anterior se puede consultar el siguiente recurso:

http://support.f5.com/content/dam/f5/kb/global/solutions/sol10288_images.html/BIG-IP_Product_Matrix.pdf

En dicha tabla aparecen las compatibilidades de los módulos con las versiones de firmware y los modelos de hardware, así como la posibilidad de ejecutar varios de ellos a la vez.

Mediante esta tabla se puede comprobar las restricciones de funcionalidades existentes en la edición virtual comentadas en el apartado anterior.

Throughput

Siguiendo las consideraciones de los apartados anteriores se reduce a unos cuantos posibles hardware BIG-IP que cumplen los objetivos marcados. Una vez que se dispone de esa lista de candidatos se ha de comprobar cuales no cumplen los requisitos de throughput.

Los documentos en los que se pueden encontrar los límites de throughput de cada uno de los hardware son los siguientes:

·         BIG-IP: http://www.f5.com/pdf/products/big-ip-platforms-ds.pdf

·         Viprion: http://www.f5.com/pdf/products/viprion-overview-ds.pdf

En estos documentos se exponen diversos elementos para el dimensionamiento del hardware. Para saber cuál aplicar hay que conocer las peculiaridades de los servicios que se encontrarán detrás de la plataforma BIG-IP.

Puede darse el caso que sea necesario balancear una base de datos sea más restrictivo el componente de transacciones SSL por segundo que los requisitos de ancho de banda que ese servicio necesita.

Para cualquier tipo de servicio se ha de tomar como referencia el  “Throughput de tráfico”, mientras que si se requiere realizar Offload de SSL también entrará en consideración las  “Transacciones SSL por segundo (TPS)”. Por último, en el caso de que también se requiera compresión de tráfico, se ha de cumplir el mínimo de “Throughput de tráfico comprimido”

Es necesario tener en cuenta que los documentos señalados antes muestran las especificaciones generales de la gama, pero hay casos en los que dentro de una misma gama existe un producto para soportar servicios específicos que supera alguno de esos límites, como por ejemplo el dispositivo 8600S que dispone de más throughput SSL (pero menos capacidad de compresión) que el indicado en la tabla para la gama 8600.

             

Por último es de utilidad señalar que en ciertos casos en los que es necesario ajustar mucho el hardware a los requisitos marcados,  hay que tener en cuenta que ciertos módulos consumen más recursos que otros y puede que el throughput real logrado sea inferior al mostrado en las tablas. Este punto es muy difícil de definir y no puede ser consultado a título personal en ninguna documentación de F5, por lo que, en caso de duda, hay que contactar con el fabricante para aclarar este punto.

Interfaces físicas

El último punto importante que puede hacer desestimar el modelo elegido es la carencia del número o de los tipos de  interfaces físicas (velocidad, conectores, etc) necesarios para poder integrar el producto en la arquitectura de red existente. Estos datos aparecen también en las tablas que se encuentran en los enlaces del apartado anterior.

Ejemplos de diseño de uplinks en HP Virtual Connect

Algunos ejemplos explicativos de diseño de uplinks en los Virtual Connect

Para poder entender el esquema de conexionado externo hay que tener en cuenta que los Virtual Connect no interactúan con el protocolo Spanning-tree,  ya que nunca formará un bucle de red debido a su arquitectura interna.

La topología habitual para los Virtual Connect es la creación de un único dominio de configuración (Virtual Connect Domain) mediante la conexión de los diferentes módulos de Virtual Connect con enlaces de stack. Gracias a la existencia de un solo dominio la plataforma puede ser gestionada desde un mismo punto y permite compartir los uplinks de cada módulo de Virtual Connect a lo largo de toda la arquitectura, incluso si se disponen en diferentes Enclosures (chasis c7000).

Ilustración 1 – Módulo Virtual Connect Ethernet

Los Virtual Connect disponen de 8 puertos, nombrados desde X1 a X8. Hay que remarcar el comportamiento de algunos de ellos:

·         X1: La interfaz nombrada X1 dispone de dos conectores físicos diferentes que trabajan como una única desde un punto de vista lógico. El conector X1 de la izquierda es 10GBASE-CX4 mientras que el de la derecha es XFP. Este interfaz suele ser utilizado para la formación de stack externo.

·         X7 y X8: Los conectores X7 y X8 pueden ser utilizados tanto para la conectividad interna entre los Virtual Connect de las bahías 1 y 2 (formación de stack), como para conexiones externas.

·         X2 al X6: Interfaces para uplink de datos.

A continuación se exponen algunos ejemplos de diferentes utilizaciones de los uplinks disponibles.

Ejemplo A: 1 Enclosure, 2 Virtual Connect, 2 túneles y 2 agregados activo-activo

Este es el esquema puesto a modo de ejemplo en este apartado. En la parte superior aparecen las dos bahías que son ocupadas por los Virtual Connect de red en la inferior cada uno de los Blade Server.

Ilustración 2 -  Ejemplo A de Gestión de uplinks en Virtual Connect

El diseño anterior refleja una configuración de dos túneles a los cuales se les ha asociado cada una de las dos tarjetas físicas de los servidores Blade, es decir, las NICs no están divididas, pero se muestran cuatro muescas para indicar que cada una de ellas puede ser dividida hasta en cuatro FLEX-NICs.

Entre los dos Virtual Connect se ha formado el stack mediante los puertos X7 y X8.

Debido a que, para que se forme un agregado las interfaces deben pertenecer a un mismo módulo, para maximizar la utilización se han vinculado los 4 uplink de cada Virtual Connect a un túnel respectivo, de tal manera que todos los uplinks podrán funcionar de manera activa. Para que se puedan utilizar los dos agregados al mismo tiempo se debe configurar algún método de balanceo de carga por parte del Sistema Operativo que esté instalado en cada uno de los Blade (deberá hacer uso de ambas NICs).

El control de failover también recaerá sobre el sistema operativo del Blade, es decir, si se pierde uno de los agregados deberá ser el Sistema Operativo quien envíe todo el tráfico por el interfaz restante. Debido a que dicho control se realiza en el propio Blade, la falta de conectividad en el uplink deberá propagarse hasta la tarjeta NIC de cada uno de los servidores, es decir, en el ejemplo citado, si se desconectasen los cuatro enlaces de la izquierda, se deberían desconectar también todos los enlaces de color verde. Esta propagación del error se realiza mediante una funcionalidad llamada Smart Link, cuya configuración se verá más adelante dentro de este mismo documento.

Ejemplo B: 1 Enclosure, 2 Virtual Connect, 2 SUS y 2 agregados activo-activo

Este caso es casi idéntico al anterior, con la salvedad de que no se está utilizando el VLAN tunneling, tal y como se refleja en el esquema de conectividad:

Ilustración 3 -  Ejemplo B de Gestión de uplinks en Virtual Connect

Dentro de cada Shared Uplink Set se definen las Virtual Networks asociadas, pudiendo modificar en cada una de ellas el tag de VLAN entrante.

Lo más destacable es que cada SUS mantiene sus propias Virtual Networks, aunque se comparta el id de VLAN, lo que permite la utilización de ambos enlaces de manera diferenciada.

Ejemplo C: 2 Enclosures, 4 Virtual Connect, 4 SUS y 4 agregados activo-activo

Este ejemplo introduce el concepto de propagación del dominio de Virtual Connect a lo largo de múltiples Enclosures:

Ilustración 4 -  Ejemplo C de Gestión de uplinks en Virtual Connect

Como se puede observar,  en este diseño existen dos Enclosures diferentes unidos por las interfaces X1 de los Virtual Connect. Gracias a esos enlaces de Stack se puede configurar que las NIC de los servidores Blade de un Enclosure estén asociados a un Tunel que tenga los uplinks por el Enclosure parejo, es decir, un servidor del Chasis A puede estar conectado al exterior mediante los uplinks del Chasis B.

Ejemplo D: 1 Enclosure,2 Virtual Connect, 2 túneles y 4 agregados activo-pasivo

El último ejemplo es este diseño en el que se asocian dos grupos de interfaces agregados a un único túnel/SUS.

 

Existen dos diferencias fundamentales en el caso de optar por este diseño:

1.     El failover ante la caída del agregado de enlace lo realiza el Virtual Connect, no el Sistema Operativo contenido en los Blade Server. Este punto también determina que no es completamente necesaria la activación de la funcionalidad de SmartLink.

2.     Solo uno de los agregados asociados al mismo túnel/SUS se encontrará activo, no como en los anteriores diseños en los que, dependiendo de las políticas de balanceo implementadas en los Sistemas Operativos instalados en los Blades, podían ser utilizados todos al mismo tiempo. En el caso de este diseño, el agregado activo es siempre el que más interfaces tiene conectadas correctamente.

Optimizaciones adicionales para despliegues iSCSI

Algunas configuraciones adicionales que mejoran el rendimiento de una plataforma virtual VMware desplegada con almacenamiento iSCSI con NetApp

Aunque iSCSI es relativamente sencillo de conectar y utilizar, en ocasiones es necesario realizar pequeñas modificaciones en la plataforma de red para adecuar esta al tráfico iSCSI y obtener así unos mejor resultados.

El primer punto sería la comprobación de la deshabilitación de los temporizadores de Spanning-tree  en los puertos conectados a los ESXi y al NetApp ya que, aunque se esté utilizando el protocolo “Rapid per-VLAN Spanning-tree”, el cual utiliza unos temporizadores más rápidos que el STP tradicional, es muy conveniente que no se introduzca ningún retardo en la prestación de conectividad en esos puntos.

También es conveniente restringir los paquetes BPDU en esos mismos puntos. Esto se puede conseguir en switches Cisco mediante la funcionalidad BPDU filter. Se debe tener precaución con la utilización de este comando ya que si se configura en un puerto incorrecto (si no es un host final), puede provocar bucles L2 en la red, al ser “invisibles” los switches que se conecten a esa interfaz.

Otra buena práctica es la de configurar el “Flow Control” para evitar pérdidas de paquetes, a las cuales el protocolo iSCSI es muy sensible, ya que transporta un protocolo superior de almacenamiento en el cual no están contempladas las pérdidas.

Flow Control es el método de control utilizado por la capa Ethernet (L2) para “frenar” el envío de paquetes en un enlace punto a punto debido a que por su cantidad no se puedan gestionar, es decir, cuando el buffer de recepción se está llenando.

Por defecto este protocolo está deshabilitado en todos los puertos de los switches ya que para el funcionamiento normal de TCP, en muchas ocasiones, provoca una ineficiencia en la utilización de los enlaces, ya que el control de flujo se realiza una capa por encima mediante la gestión de ventanas TCP de extremo a extremo. Esta ineficiencia viene dada por la utilización de enlaces con sobre-suscripción entre switches, en los cuales la propagación de los mensajes de Flow Control podría frenar flujos de tráfico que no deberían ser frenados.

Para el caso de iSCSI es recomendable hacer una excepción, pero siempre teniendo en cuenta que no se ha de habilitar libremente ya que se provocaría la ineficiencia comentada. Para ello se debe activar el protocolo Flow Control tan solo en los extremos de la comunicación, es decir, entre los host ESXi y los switches y entre el NetApp y los switches. También hay que notar que no se activa para ambas direcciones, como se puede ver en el esquema siguiente, si no que en los switches se deberá activar el Flow Control de recepción y en los puntos terminadores (ESXi y NetApp) de envío.

Ilustración 1 - Configuración del protocolo Flow Control

Esta configuración garantiza que si alguno de los puntos terminadores no pudiese afrontar más tráfico, informaría de este hecho al switch y este disminuiría su tasa de transferencia hacia él, de modo que se minimizaría el riesgo de pérdida de paquetes en ese tramo de la conexión.

Por último se recomienda permitir las llamadas Jumbo Frames en toda la infraestructura de red que utilice iSCSI. Las Jumbo Frames no son más que tramas que superan  la MTU de 1500 que es la destinada a tramas Ethernet. Aunque 1500 bytes es una cifra óptima para el tráfico habitual, iSCSI es un protocolo que contiene a su vez un protocolo de almacenamiento (SCSI) que requiere un intercambio masivo de información, por lo que aumentando el tamaño de trama se disminuye la sobrecarga de bytes por las cabeceras de cada trama, al enviarse menos tramas, se aumenta la eficiencia global de la plataforma. Para que ese incremento de la eficiencia sea real se presupone que la red que mantiene las comunicaciones iSCSI está libre de pérdidas de paquetes.

Ilustración 2 - Configuración de Jumbo Frames

Para dar soporte de Jumbo Frames en la red se deberá aumentar el tamaño de MTU permitido de la manera que indica el esquema anterior y activar el soporte en el vSwitch y los puertos iSCSI.

Diseño iSCSI con VMware

Un posible diseño de una plataforma virtual con el almacenamiento con iSCSI aportado por un NetApp FAS

La arquitectura iSCSI de VMware vSphere ha sido completamente reescrita desde la versión anterior, mejorando la eficiencia del uso de CPU y soportando múltiples sesiones por target iSCSI, aunque siempre desde una única conexión TCP por sesión. Esto permitirá ver varios caminos hasta un mismo almacenamiento posibilitando la utilización de software multipath para realizar balanceo de carga.

Se reservarán 3 tarjetas NIC físicas por ESXi para poder tener una alta disponibilidad de la plataforma y aumentar del mismo modo el throughput total de iSCSI. Para vincular las tarjetas destinadas a este tipo de almacenamiento al iniciador iSCSI de cada ESXi (existe un único iniciador software por cada ESXi) existen dos posibles diseños:

1.     Crear un vSwitch por cada tarjeta NIC y asociar a este el puerto virtual iSCSI con su dirección IP correspondiente

2.     Crear un único switch al cual se unirán las tres tarjetas de red y los puertos virtuales de iSCSI.

Los dos diseños son válidos pero se va ha optar por explicar el segundo ya que aporta la flexibilidad de introducir en ese vSwitch en un futuro otro tipo de almacenamiento, como pueda ser NFS, sin requerir más NICs.

Al existir un único vSwitch y varias tarjetas NIC físicas se debe preestablecer el tratamiento del tráfico por parte de esos uplinks, ya que por defecto se realiza un teaming y balanceo que no es recomendado para entornos iSCSI, como se explicará más adelante, por lo que se hará una asociación unívoca entre los puertos virtuales iSCSI y las NICs físicas (lo que lleva a poseer 3  puertos iSCSI en cada ESXi).

No se dispondrán en este diseño tampoco ninguna NIC en modo stand-by para ningún puerto iSCSI ya que el HA lo manejaría también el software de multipath.

A continuación se muestra un esquema que resume lo comentado anteriormente.

Ilustración 1 - Estructura de iniciador iSCSI en ESXi

Como se puede observar, una vez creados los 3 puertos virtuales, se deberán añadir al iniciador, paso necesario para que puedan utilizarse los tres caminos al almacenamiento. Este proceso solo se puede puede hacer mediante comando.

 Diseño del balanceo de carga

El diseño del balanceo de carga se subdivide en los diferentes puntos donde esta acción puede ser realizada: en la elección del camino por parte del ESX, el transcurso de los paquetes a través de los switches Ethernet y la presentación de recursos en el NetApp FAS.

Balanceo de carga en ESXi

Como se ha descrito antes, se puede configurar un vSwitch con tres interfaces de red físicas asociadas a él. No se debe permitir la realización de ningún tipo de teaming entre ellas, ya que el balanceo que posibilitaría este método sería un balanceo de paquete Ethernet, y tendría solo valided entre el ESX y el switch físico al que esté conectado, por lo que es mejor optar por delegar el proceso de decisión del balanceo al software de multipath, el cual hace un balanceo extremo a externo, que es lo necesario en un entorno de almacenamiento.

Para que pueda actuar el software multipath se debe diseñar una solución en la que aparezcan varios caminos al almacenamiento. Previamente a vSphere no existía posibilidad de tener varios caminos a un mismo target ya que no se soportaba la creación de múltiples sesiones por target iSCSI, por ello el único modo de realizar un pseudo-balanceo era mediante el teaming de tarjetas. Este método no es el recomendado en la actualidad porque con vSphere ya se pueden crear varias sesiones por target y aprovechar las ventajas del software multipath. Para poder crear varias sesiones el único requisito, ya que no se permiten varias conexiones por sesión, es crear tanto puertos virtuales de iSCSI como caminos a un target se deseen. En el caso abordado 3 posibles caminos existirán al haber tres NICs destinadas a este efecto con su puerto iSCSI unívocamente asociado.

El software de multipath soporte tres tipos de balanceo en vSphere:

1.     MRU (Most Recently Used): Selecciona la ruta que el host uso más recientemente para acceder a un dispositivo de storage. Si esta ruta llega a encontrarse no disponible, el host cambia a una ruta alternativa y la continúa utilizando mientras ésta se encuentre disponible. MRU es la política de multipathing recomendada para los despliegues con controladoras en activo-pasivo.

2.     Fija o Fixed: Utiliza la ruta designada como preferida si esta ha sido configurada. De lo contrario utiliza la primera ruta descubierta que se encuentre funcionando correctamente. Si el host no puede usar la ruta preferida, selecciona una ruta alternativa disponible en forma aleatoria. El host vuelve a utilizar la ruta preferida tan pronto como dicha ruta vuelva a encontrarse disponible. Esta politica es recomendada para los despliegues con controladoras en activo-activo.

3.     Round Robin: Utiliza un algoritmo de seleccion de rutas que va rotando a través de todas las rutas activas disponibles, permitiendo balanceo de carga a traves de las rutas.

Las recomendaciones de utilizar MRU en un entorno activo-pasivo viene dado a que si se implementa la política Fixed en una arquitectura activo-pasivo es posible que se produzcan eventos que necesiten una condición de failover y que este no se produzca. Esto es debido a los diferentes tipos de mensajes que envían los sistemas activo-activo a los host frente al único tipo de mensaje que envían los activo-pasivo.

Para el ejemplo de diseño se ha elegido el balanceo Round Robin debido a que simplifica la gestión y la topología no consta de un alto número de host, por lo que los tráficos que necesiten más de un salto en los switches Ethernet no afectarán demasiado a la totalidad del tráfico (más adelante explicado).

Round Robin puede cambiar el camino seleccionado tras cierto número de comandos o número de bloques I/O. También es posible modificar los umbrales de esos valores. 

Balanceo de carga en NetApp FAS

Para poder balancear la carga se necesitan dos controladoras funcionando de manera activa-activa. Para ello, en iSCSI, se pueden configurar diferentes portales para discriminar qué peticiones irán contra qué controladora.

Este tipo de balanceo se corresponde más con un diseño de almacenamiento, ya que dependiendo de una LUN se asocia a uno u otro portal se deberá realizar la petición a una u otra controladora.

Esta distribución normalmente no puede ser indiferente a la conectividad subyacente de los enlaces a los switches y los caminos a cada host pero, para facilitar la gestión, se ha cree conveniente diseñar el balanceo de carga en los switches (explicado más adelante) de manera que estos dos conceptos sean lo más independientes posible. De esta manera se podrá aportar más o menos carga a una u otra controladora sin importar la arquitectura de red que los sustenta. Esta afirmación se explica a continuación.

Balanceo de carga en switches

Una parte fundamental del correcto funcionamiento del protocolo iSCSI es un buen diseño de la arquitectura de red que sustenta la plataforma. Para ello, como  partida, se tienen que dimensionar los punto en los que se conectan los ESXi así como el NetApp, pero también es necesario afrontar el diseño de las conexiones intermedias entre los diferentes switches que componen la solución.

Como primer punto hay que mencionar que el diseño de ejemplo no tiene en cuenta la existencia de otro tráfico diferente al de iSCSI entre los dos switches de Core, ya que se considera necesario crear nuevas conexiones destinadas únicamente a este tipo de tráfico. Para ello se pueden asociar a esos nuevos agregados entre los switches, la VLAN de iSCSI (como puerto de acceso ya que tan solo se creará una VLAN para el almacenamiento por red) y restringir en los enlaces troncales que puedan existir de manera previa al despliegue de esta solución.

El número de nuevos enlaces que formarán parte del agregado destinado al almacenamiento iSCSI depende del diseño del  sobre-suscripción de los enlaces y para ello hay que tener en cuenta los flujos de tráfico implicados, los cuales depende directamente, en este caso, de la localización de los recursos iSCSI.

Como primer paso se presenta el diseño de la arquitectura en el caso de la presentación de recursos en una única controladora.

Ilustración 2 - Diseño de balanceo de red en switches con un portal iSCSI

Para dimensionar los agregados de enlaces hay que tener en cuenta el modelo de balanceo. Como se ha indicado previamente, el balanceo de los agregados será de hash de dirección IP de origen y destino.

Debido a que el software de multipath necesita una IP para el puerto virtual iSCSI de los ESXi por camino, y que cada uno de los port-groups dispondrá de una dirección IP, se crea una correspondencia entre los tres caminos que puede elegir el software multipath y los tres diferentes hash que utilizarán los agregados LACP para balancear el tráfico por cada ESXi, haciendo de este un diseño muy eficiente.

Para calcular el número recomendado de enlaces del agregado hay que tener en cuenta el concepto de sobre-suscripción, es decir, el número de orígenes que utilizan cada enlace. En el diseño de red del esquema anterior se tiene una sobre-suscripción de “1:2“, es decir, por cada enlace del agregado engloba a dos orígenes. Esto se calcula fácilmente si se tiene en cuenta que cada una de las interfaces de los ESXi se transmitirá por un enlace distinto (debido al balanceo antes mencionado), que existirán 2 ESXi, lo que suman 6 orígenes, y el agregado del NetApp contará con tres enlaces, lo que lleva a un 3:6, o lo que es lo mismo un 1:2.

Para no crear el “cuello de botella” en la transferencia de paquetes entre los dos switches de Core, hay que garantizar que el resultado de la sobre-suscripción sea siempre menor que el del agregado de enlace del NetApp, lo que se podría haber optado por un único enlace entre los switches, lo que da una sobre-suscripción exacta de 1:2, pero por motivos de alta disponibilidad se ha realizado un diseño con dos enlaces (sobre-suscripción de 1:1).

En caso de pérdida del agregado principal del NetApp entraría en producción un único enlace (que anteriormente se encontraba suspendido) con una sobre-suscripción de 1:6, aunque el caso más usual de este tipo de failover sea la pérdida del switch al que está conectado el agregado principal, con lo que el enlace de contingencia tan solo soportará una sobre-suscripción de 1:2. Que la sobre-suscripción sea la misma en este caso no es sinónimo de que se obtenga el mismo throughput ya que hay que tener en cuenta que el software multipath del ESXi estará encaminando las mismas peticiones que hacía por tres enlaces tan solo por uno, con lo cual el porcentaje de utilización del enlace, así como la posibilidad de saturación de este, será mucho mayor. Aun así hay que tener en cuenta que este estado sería transitorio y tan solo tendría como misión el aportar un soporte mínimo hasta la recuperación del servicio.

Para el diseño con dos controladoras activas los cálculos anteriores varían, como se puede comprobar:

Ilustración 3 - Diseño de balanceo de red en switches con dos portales iSCSI

En este caso las sobre-suscripciones de los agregados del NetApp serían de 4:6 o lo que es lo mismo de 2:3.

La sobre-suscripción del agregado entre switches de Core varía si se tiene como destino la controladora de la izquierda o la de la derecha, ya existe un mayor número de enlaces directamente conectados al switch de al izquierda que al de la derecha, de este modo, si se tiene como destino la controladora de la izquierda, la sobre-suscripción en el caso de dejar dos enlaces como en el diseño anterior seria de 1:1, pero si el destino fuese la controladora de la derecha, la sobre-suscripción sería de 1:2.

Al tener siempre que tomar la mayor sobre-suscripción, se tiene que la del agregado inter-switch es de 1:2 frente a 2:3 de la del agregado del NetApp, por lo que el “cuello de botella” estaría entre los switches. Para solventar esto se ha decidido en este diseño aumentar el número de enlaces entre los switches a tres, de tal manera que su sobre-suscripción baje a 3:4.