Conectividad de red de NetApp FAS

Diseño de esquema de conectividad de una NetApp FAS a la arquitectura de red

 

Antes de comenzar, como punto adicional a tener en cuenta, es necesario hacer notar que las controladoras de NetApp soportan el tag de VLANs pero no contemplan la existencia de ninguna VLAN nativa, es decir, todas las VLANs deberán conservar un tag ID. Es por ello que, en el caso de ser indispensable la utilización de la VLAN nativa, se haga una reconversión en los interfaces de los switches, de manera que se cambie la VLAN nativa a otra, no utilizada, y aporte un tag todas las VLANs de producción, haciendo posible la gestión de ella en el NetApp.

Conexiones con controladora única

Toda arquitectura de almacenamiento debe garantizar dos puntos, la alta disponibilidad y el mayor throughput posible.

Para cumplir los dos requisitos en una plataforma con una única controladora se debe hacer uso combinado de los diferentes tipos de agregados de enlace que proporciona NetApp.

NetApp nombra a los agregados de enlace con el nombre de “Virtual Interface” (VIF) y proporciona tres tipos, cada uno de ellos con las siguientes propiedades:

1.     Single-mode VIF: Que permite generar una interfaz lógico con una única interfaz física activa, dejando el resto en modo pasivo a la espera de que exista algún problema.

2.     Static Multi-mode VIF: Que forma un agregado de enlace (activo-activo) entre sus componentes sin necesidad de ninguna negociación.

Este tipo de agregado tiene el requisito de que todos los enlaces que formen parte de él, deben terminar en un mismo switch físico, o que tenga capacidad de stack o algún sistema de gestión centralizada como puedas ser Cisco VSS.

3.     Dynamic Multi-mode VIF (LACP): Es el protocola estándar (802.1ad) de formación de agregados de enlace. La principal diferencia con el anterior es que para que un enlace forme parte del agregado, es necesaria una negociación previa.

Mientras que el modo Single-mode VIF proporciona una mayor disponibilidad a la plataforma frente a fallos, ya que en el caso de ambos Multi-mode VIF se hace necesario terminal el enlace en un único switch (punto único de fallo), los dos últimos modos garantizan un mayor ancho de banda total, al poseer activos todos sus enlaces.

Para consensuar las necesidades de HA y de alta capacidad de transferencia se puede optar por el despliegue de un modelo híbrido entre los dos, como se puede observar en este esquema.

Ilustración 1 - Arquitectura de conexión de NetApp FAS con una única controladora

En este posible diseño existen dos VIF, el primero agregará de modo activo-activo (LACP) tres enlaces mientras que el otro unirá ese grupo LACP con un cuarto enlace que se dejará en pasivo (gracias a un VIF single-mode de segundo nivel entre el LACP y el enlace secundario), de tal modo que si el LACP se desconectase, porque se apaga el switch al que están conectados por ejemplo, entraría en funcionamiento el stand-by. Se ha optado por un grupo activo de tres y uno pasivo de tan solo uno porque se cree necesario aumentar al máximo el posible ancho de banda en los momentos en los que no hay ninguna incidencia, dejando tan solo 1Gbps para la contingencia, lo que disminuiría el throughput pero mantendría activo el servicio, que es justo lo necesario para proporcionar un rango de tiempo para solventar el problema y volver a los 3Gbps del LACP.

Se ha decidido implementar el Dynamic Multi-mode VIF en lugar del modo estático debido a que proporciona un mayor nivel de visibilidad a la hora de corregir y detectar posibles problemas. Esto es debido a que durante la negociación se producen mensajes de log con bastante información relevante.

A esto hay que añadir que el modo estático tiene el riesgo de producir inestabilidades en la red debido a que, en lugar de comprobarse si un enlace puede pertenecer con seguridad a un agregado, como se hace en el modo dinámico, en el modo estático pasa a formar parte de él sin ningún filtro. Este comportamiento pude ser origen de muchos de los problemas asociados a un bucle de nivel 2 en la red, como puedan ser aumentos repentinos en la CPU de los switches físicos a los que esté conectado, flooding de paquetes en la red.

Otro punto a tener en cuenta es el balanceo de carga en lo enlaces de los agregados. Al disponer de todos los enlaces activos tenemos tres posibles caminos que pueden llegar a proporcionar hasta 3Gbps en conjunto. Esta aseveración hay que matizarla ya que un concepto erróneo que se suele tener es que un agregado con N enlaces de 1Gbps proporcionará en todo caso N Gbps. Esto que en teoría con una distribución perfecta de los paquetes de datos sería cierto, no es del todo correcto ya que todo depende de la política de balanceo que se marque. LACP nos brinda los siguientes métodos de balanceo de carga entre los enlaces que componen el agregado:

1.     Balanceo basado en Hash de IPs origen y destino: Para que dos paquetes correlativos sigan enlaces diferentes, sumando así sus capacidades, deberá darse que el hash entre la dirección IP de origen y la dirección IP de destino sea diferente. Así un único host con IP A que acceda a los recursos situados en una IP B siempre accederá por un único enlace, el siguiente host con IP C si que tomaría un enlace diferente.

2.     Balanceo por Hash de MAC origen y destino: Igual que el anterior pero, en este caso el hash se hace con las direcciones MAC de origen y destino.

3.     Round Robin: Simplemente se envía cada paquete por un enlace sin importar ni su origen ni su procedencia.

El tercer método, aunque pueda parecer el que mejor balanceo produce, no es aconsejable utilizaro ya que genera dos problemas. El primero de ello es un aumento en el consumo la CPU de los switches a los que se encuentra conectado ya que deberán reestructurar, casi por cada paquete, su CAM en la que almacenan los datos de correspondencia MAC-puerto. La segunda es la necesidad de reordenación de paquetes en destino debido a que es muy probable que lleguen desordenados, lo cual también introduce retardo y aumenta la utilización de recursos en el host destino.

En el método de balanceo por MAC se solventan los problemas anteriores pero la distribución de los paquetes a lo largo de los diferentes enlaces queda restringida a las NICs físicas del origen y destino, ya que serán estas las dueñas de las diferentes MAC, y no solo eso, en el caso de que el acceso se produzca desde una red IP diferente de la de la IP del recurso del NetApp, no se producirá balanceo, ya que todas las peticiones en ese caso provendrán de una única MAC, la del interfaz del router que une ambas redes, ya que será el elemento que envíe todos los paquetes de las redes externas.

Debido a los puntos anteriores, se podría optadar por el balanceo hash IP ya que se puede lograr una mayor distribución del tráfico en el caso de poder añadir más de una IP por interfaz.

En el caso de NFS esto puede darse desde añadiendo más IPs secundarias (IP Alias) a un mismo interfaz del NetApp (se recomienda una por enlace), y luego añadiendo los Data Store de VMware de manera distribuida entre esas IPs, con lo que conseguimos que una misma NIC de un host utilice todos los enlaces, esto sumado a que las diferentes NICs de todos los host también lo harán, consiguiendo una mejor distribución del tráfico.

Para el caso iSCSI el balanceo se consigue de otra manera, utilizando algún software multipath.

Conexiones con doble controladora

Cuando se disponen de dos controladoras, la conectividad se puede diseñar de una manera diferente ya que no se ha de pensar tan solo en el failover de enlaces, sino también en el failover de una controladora completa.

A partir de la versión ONTAP 7.1, si todas las NICs que conectan una controladora se desconectan, automáticamente se realiza un failover de controladora, lo que permitiría prescindir del VIF secundario mostrado en el punto anterior, el que realizaba un funcionamiento activo-pasivo entre el agregado LACP y el enlace stand-by, ya que su función la realizaría este comportamiento entre controladoras; aun así se cree preferible que ante la caída de un switch se realice un failover de enlace antes que uno de controladora, por lo que se dispondrá de un enlace pasivo del mismo modo que en el diseño de una única controladora.

Para gestionar cómo la controladora a la que se realiza el failover se deberá configurar un modo de funcionamiento de las interfaces de este. NetApp permite los siguientes tres tipos:

1.     Dedicado: Este tipo de funcionamiento se configura en el nodo en el que se quiere que resida el servicio que se situará detrás de esta interfaz y la reserva frente al uso por parte de otra interfaz en un failover.

2.     Stand-by: Este modo va asociado al modo dedicado y es configurado en la controladora a la que se realizaría failover en caso de fallo, de manera que existiría una relación uno a uno entre interfaces dedicadas (en producción en controladora A) con interfaces stand-by (en reserva en controladora B).

3.     Compartido: Con este modo la interfaz es compartida por el recurso en producción de un nodo y como interfaz stand-by del nodo adyacente.

Para el diseño que se va a mostrar se ha optado por crear una interfaz con los cuatro enlaces, tres activos y uno pasivo, por cada controladora y asignarle a esta el rol compartido, de manera que mantenga la IP del recurso de la controladora pareja en caso de contingencia. Este diseño maximiza la utilización de los enlaces disponibles al tener 3 enlaces activos por controladora, como puede contemplarse en el siguiente diagrama:

 

Ilustración 2 - Arquitectura de conexión de NetApp FAS con controladora doble

La utilización de ambas controladoras a un mismo tiempo depende de la configuración de los recursos que se presten por parte del NetApp.