Cambios de zoning Fibre Channel, un fabric cada vez

Dos fabrics Fibre Channel le protegen de un switch muerto. No le protegen de un cambio de zoning descuidado aplicado a los dos fabrics en el mismo minuto. La disciplina que cierra ese hueco es sencilla de describir y fácil de saltarse: cambie un fabric, demuéstrelo, y solo entonces toque el otro.

Por qué el zoning es la tarea rutinaria más arriesgada de una SAN

El zoning decide qué initiators (puertos HBA de los hosts) pueden hablar con qué targets (puertos de la cabina). Cambia cada vez que se añade, sustituye o retira un servidor, así que es trabajo de rutina, y el trabajo de rutina es donde la atención se relaja. En un fabric Brocade la configuración de zoning activa es un único objeto. Cuando activa una nueva versión, todo el fabric adopta la nueva versión de golpe. Una errata que elimina una zona, un miembro pegado en la zona equivocada o una configuración activada antes de terminarla puede quitarle al instante a un host de producción el acceso a sus discos en ese fabric.

En un solo fabric, eso es una caída. En un doble fabric bien construido, es una pérdida de camino, siempre que el otro fabric no se haya cambiado de la misma manera en el mismo momento. Muchos operadores preparan un script y lo ejecutan contra los dos switches uno detrás de otro. Eso convierte dos fabrics independientes en un único punto de fallo compartido: la persona que tiene el script.

Diseñe las zonas para que los errores se vean

Zoning single initiator. Cada zona contiene un puerto HBA de host y los puertos de la cabina que debe ver. Los hosts nunca comparten zona, así que una HBA que se comporta mal no puede molestar a sus vecinas, y retirar un host significa retirar sus zonas y nada más.

Aliases, no WWPN en crudo. Cada puerto recibe un alias, y las zonas se construyen a partir de aliases.

Una regla de nombres que lleve el fabric. Ponga la letra del fabric en cada nombre de alias y de zona, de modo que una zona del Fabric A pegada en el Fabric B sea obviamente un error para cualquiera que lea el cambio. Limite los nombres a letras mayúsculas, dígitos y guiones bajos. Algunos fabrics rechazan guiones y otros caracteres en los nombres de objetos, y los nombres distinguen mayúsculas de minúsculas, así que una sola convención usada en todas partes elimina toda una clase de errores.

alias:  WEB01_HBA_A          -> <host port WWPN, fabric A>
alias:  ARRAY1_N0_P1_A       -> <array port WWPN, fabric A>
zone:   Z_WEB01_A__ARRAY1    -> WEB01_HBA_A; ARRAY1_N0_P1_A; ARRAY1_N1_P1_A
config: CFG_FABRIC_A

Antes de empezar: comprobaciones previas

Guarde el estado actual de los dos fabrics antes de cambiar nada:

cfgshow
cfgactvshow
zoneshow
alishow
nsshow
cfgtransshow

nsshow (el name server) confirma que los puertos del nuevo host han hecho login de verdad en el fabric y muestra los WWPN tal como los ve el switch, que es de donde debe construir los aliases, y no de una etiqueta pegada en una caja. cfgtransshow le dice si alguien más tiene una transacción de zoning abierta en este fabric. Si hay una abierta y no es suya, pare y averigüe de quién es.

En cada host existente que el cambio pudiera tocar, anote el número de caminos (multipath -ll), para poder demostrar después que nada cambió para ellos.

El cambio en sí, un fabric cada vez

Empiece por el fabric que preferiría perder. Construya todo el cambio en una sola sesión, como una sola transacción:

alicreate "WEB01_HBA_B", "<host port WWPN, fabric B>"
zonecreate "Z_WEB01_B__ARRAY1", "WEB01_HBA_B; ARRAY1_N0_P2_B; ARRAY1_N1_P2_B"
cfgadd "CFG_FABRIC_B", "Z_WEB01_B__ARRAY1"
cfgenable "CFG_FABRIC_B"

cfgenable guarda la configuración y la activa en un solo paso, y pide confirmación antes de hacer el commit. Si lo automatiza con un script, el script debe responder a ese prompt y después leer la salida en busca del mensaje de commit, no dar por hecho el éxito porque el comando haya terminado. Nada está en vivo hasta que el enable se completa, y ese es su último momento para leer el cambio preparado una vez más con cfgshow.

Después verifique, desde tres sitios:

1. El switch. cfgactvshow contiene la nueva zona, y cada zona que estaba antes sigue ahí.
2. La cabina. El puerto del nuevo host en este fabric aparece ahora conectado a los puertos de cabina esperados.
3. Los hosts. El nuevo host ve sus volúmenes a través del puerto HBA de este fabric. Los hosts existentes muestran exactamente el número de caminos que anotó en las comprobaciones previas.

En el nuevo host Linux, basta con un rescan y un vistazo a la HBA:

cat /sys/class/fc_host/host*/port_state
rescan-scsi-bus.sh
multipath -ll

Solo cuando las tres coinciden repite el mismo cambio en el otro fabric, construido de la misma manera y verificado de la misma manera. Si algo tiene mal aspecto en el primer fabric, se detiene ahí. La producción sigue corriendo sobre el fabric intacto, y tiene su configuración guardada para restaurarla.

Después del cambio

Actualice el inventario en la misma sesión, para que el fabric y el registro nunca estén en desacuerdo.

Cómo lo hacemos nosotros

Nuestros fabrics están construidos como dos fabrics Brocade totalmente independientes, desde los switches core hasta los switches integrados en nuestros chasis de blades HPE. Un lote de servidores nuevos puede entrar en zonas un fabric cada vez en minutos de tiempo de cambio del fabric, mientras las zonas que llevan producción se quedan exactamente como estaban.

Si su próximo cambio de storage implica tocar los dos fabrics, con gusto revisamos el plan con usted antes de ejecutarlo.

Hable con un ingeniero

Related (rows[1])

Relacionado: SAN Fibre Channel de doble fabric sobre Brocade · Storage SAN enterprise en HPE 3PAR, all-flash · Servidores bare metal en HPE y Dell