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.