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.