Opciones para la consolidación de las redes SAN y LAN

"La consolidación de las redes SAN y LAN no se limita al protocolo FCoE, hay más protocolos que permiten una arquitectura común no obstante, FCoE es la que habitualmente mejor puede encajar en las arquitecturas de los Data Centrer debido a las cualidades que se expondrán a continuación"

Si bien es cierto que hoy en día las implementaciones de este tipo de redes no son las más numerosas , también lo es que la utilización de este tipo de despliegues, en el que se utilizan los mismos elementos para encaminar tanto el tráfico de red (LAN) como el de almacenamiento basado en bloque (SAN), será la tendencia en los siguientes años, ya que proporciona algunas ventajas derivadas de la reducción de la infraestructura física, al consolidar los switches FC y de red en un mismo equipo, como por ejemplo:

• Reducción de las necesidades de alimentación eléctrica

• Disminución de las tareas de gestión

• Simplificación del cableado

• Reducción del número de tarjetas de red y almacenamiento necesarias en los equipos terminales

• Reducción del equipamiento de red

Existen varios protocolos que pueden unificar la transmisión de datos de red y almacenamiento, cada uno de ellos con sus peculiaridades, aunque todos deben cumplir lo siguiente:

1. Baja latencia
2. Alto ancho de banda disponible
3. Transmisión sin pérdidas

Estos son algunos de los protocolos que son o podrían ser utilizados a tal efecto:

  

Figura 1– Capas en los protocolos convergentes LAN/SAN

1. Fibre Channel (FC)

Aunque en teoría el protocolo FC se podría haber utilizado para el envío de los paquetes de red, esto nunca se llevó a cabo debido al alto coste de la infraestructura FC y a la convención global de utilizar Ethernet como método de transporte, no obstante ha quedado como el protocolo más común de transporte para la información de almacenamiento basada en bloques, debido a sus procedimientos de detección de errores y control de flujos.

2. InfiniBand (IB)

Este protocolo puede ser utilizado para transportar la comunicación inter-procesador, LAN y de almacenamiento pero su despliegue para este cometido no es práctico debido a su alto coste, no solo de los componentes puramente IB, sino también de los elementos que harían la traducción al resto de protocolos LAN y almacenamiento en los bordes de la red convergente.

Este protocolo ha sido adoptado casi únicamente por los entornos de supercomputación y grid computing, es decir, computación de alto rendimiento.

3. Internet SCSI (iSCSI)

iSCSI realiza un mapeo directo entre la información SCSI de almacenamiento y la pila de protocolos TCP/IP. 

Su implementación permite despliegues capaces de encaminar el almacenamiento por bloque con un coste mucho más reducido que con la infraestructura Fibre-Channel, es por ello que muchas empresas de mediano y pequeño tamaño han adoptado esta tecnología, consolidando los switches de almacenamiento y de red en solo un elemento físico, o bien creando una red paralela dedicada de almacenamiento pero basada en switches de red (más económicos) en lugar de switches FC. También suele ser utilizado en las SAN destinadas a desarrollo mientras que FC es utilizado en producción.

Como contra se puede señalar un número menor de funcionalidades de los dispositivos iSCSI de almacenamiento, comparándolas con Fibre-Channel, que la implementación de arquitecturas de almacenamiento puede necesitar, tanto desde el punto de vista de seguridad como de rendimiento.

Por otro lado, para poder desplegarlo como un protocolo destinado a la consolidación de las comunicaciones LAN y SAN, habría que tener en cuenta los dispositivos que permitan la conversión desde la red convergente a los protocolos de red y almacenamiento por separado, y para el caso de iSCSI se puede constatar que dichos equipos conversores iSCSI/FC (denominados gateways) tiene un elevado coste. 

4. Fibre-Channel over IP (FCIP)

FCIP realiza un mapeo directo entre el protocolo FC y la pila de protocolos de red TCP/IP. Debido a ello es un protocolo que es comúnmente utilizado para realizar extensiones de SAN geográficamente separadas a lo largo de redes TCP/IP, eliminando la necesidad de adquisición de líneas de fibra dedicadas exclusivamente al tráfico FC entre ambos puntos, lo que en algunas ocasiones físicamente es imposible o genera un coste adicional de infraestructura no asumible.

Sin  embargo FCIP no debería ser considerado un protocolo que pueda llevar a cabo la consolidación LAN/SAN pues no está diseñado para la comunicación entre los host y el almacenamiento, sino para el cometido descrito anteriormente, la extensión SAN, ya que de él derivarían una serie de problemas de complejidad, falta de escalabilidad y coste de la solución.

5. Fibre-Channel over Ethernet (FCoE)

Hasta hace poco existían dos problemas para utilizar Ethernet como sustento de las redes LAN/SAN consolidadas:

• Limitación del ancho de banda que permitía transmitir, si se comparaba con FC

• Imposibilidad de dedicación de recursos y fiabilidad a flujos concretos

Desde la aparición y popularización de los enlaces Ethernet de 10Gbps el primer problema ha desaparecido, por lo que actualmente es considerado el método principal para logar la consolidación de las redes de almacenamiento y LAN.

El segundo problema ha sido resuelto mediante los nuevos estándares IEEE Data Center Bridging (DCB) se ha logrado mejorar el protocolo Ethernet, eliminando las pérdidas de paquetes debido a la congestión de colas y añadiendo la posibilidad de reservar anchos de banda específicos a los enlaces.

DCB  define las siguientes tecnologías que proporcionan ventajas al protocolo FCoE:

• 802.1Qbb  - Priority-based Flow Control (PFC): Permite realizar control de flujo, pero diferenciando entre tipos de tráfico sobre los  que puede utilizar las “pausas”. Evita las pérdidas de paquetes y es por el por el que a las redes DCB también se las denomina redes Ethernet sin pérdidas, o “lossless Ethernet”.

• 802.1Qaz  - Enhanced Transmission Selection (ETS): Define el procedimiento para garantizar ancho de banda del enlace así como para asignar prioridades a los flujos de tráfico.

• 802.1Qau  - Quantized Congestion Notification (QCN): Gestiona el control de flujo de extremo a extremo, lo cual elimina la congestión que pueda existir. Es importante que para que este protocolo funcione correctamente, todos los elementos intermedios en la comunicación LAN deben poseer esta funcionalidad.

• 802.1Qaz -  Data Center Bridging Exchange Protocol (DCBX): Es el protocolo que conversa y descubre a los elementos colindantes que soportan los anteriores protocolos.

Ya que los protocolos DCB son imprescindibles para lograr una red SAN, con propiedades similares en rendimiento y fiabilidad que las redes FC, para poder implementar FCoE será necesario que los switches de la red que formen parte de la red convergente sean de última generación, ya que son estos los que incluyen dichas funcionalidades DCB.

Por parte de los servidores, FCoE también requiere un nuevo tipo de conector llamado CNA que sustituye a las NICs y HBAs y que también incluye los protocolos DCB.

No obstante, aunque FCoE imponga la necesidad de switches con capacidades DCB y nuevas tarjetas CNA en los servidores, presenta numerosas ventajas frente al resto de posibilidades presentadas anteriormente, ya que el coste de adquisición y mantenimiento de los equipos implicados es menor (y este cada vez será inferior debido a la popularización de este protocolo entre los fabricantes de productos de red y almacenamiento durante los últimos años), por lo que es más fácil que el ahorro en infraestructura y costes de gestión que proporcione la red convergente, compense la inversión en nuevo equipamiento.

También hay que tener en cuenta que la mayor parte de los conceptos de seguridad y gestión de las redes SAN FC han sido trasladados a las redes convergentes basadas en FCoE, lo cual hace más fácil la transición a este tipo de red convergente.

A continuación se muestra un ejemplo entre un servidor tradicional con diferentes NICs que conectan a los segmentos de red y las HBAs que conectan al Fabric FC:

  

Figura 2 – Ejemplo de conexión de servidor a redes SAN LAN de modo tradicional

La utilización de varias NICs que conectan a los diferentes segmentos suele venir dada por las restricciones de ancho de banda, y fiabilidad (por perdida de paquetes ante congestión), hechos que con las interfaces de 10Gbps con capacidades DCB han sido solventados, por lo que un posible esquema de conexión de los servidores conectados a la red convergente podría ser el siguiente:

  

Figura 3 – Ejemplo de conexión de servidor a redes SAN LAN de modo convergente

El hecho de disponer de 10Gbps en cada enlace, no reduce la necesidad de la correcta configuración de QoS en toda la red convergente, para evitar que el tráfico de unas pocas redes pueda constreñir al del resto dentro de un mismo enlace físico, así como para garantizas latencias bajas en las redes que sean necesarias.

A día de hoy se recomienda que la convergencia de las redes SAN y LAN se limite al primer salto, debido a las restricciones de funcionalidades y conectividad que existen en algunos fabricantes cuando se tiene más de un salto FCoE en la arquitectura. La mayor parte de los fabricantes de Chasis para servidores Blade ya pueden proporcionar esa red convergente de primer salto tal y como se muestra a continuación:

Ilustración 186 – Ejemplo de conexión de servidor a redes SAN LAN de modo convergente

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.