Changements de zoning Fibre Channel, un fabric à la fois

Deux fabrics Fibre Channel vous protègent d'un switch mort. Ils ne vous protègent pas d'un changement de zoning imprudent appliqué aux deux fabrics dans la même minute. La discipline qui comble cette brèche est simple à décrire et facile à sauter : changez un fabric, prouvez-le, et seulement ensuite touchez l'autre.

Pourquoi le zoning est la tâche de routine la plus risquée d'un SAN

Le zoning décide quels initiators (ports HBA des hôtes) peuvent parler à quels targets (ports de baie). Il change chaque fois qu'un serveur est ajouté, remplacé ou retiré, c'est donc un travail de routine, et le travail de routine est là où l'attention se relâche. Sur un fabric Brocade, la configuration de zoning active est un objet unique. Quand vous en activez une nouvelle version, tout le fabric prend la nouvelle version d'un coup. Une faute de frappe qui supprime une zone, un membre collé dans la mauvaise zone, ou une configuration activée avant d'être terminée peut retirer instantanément à un hôte de production l'accès à ses disques sur ce fabric.

Sur un fabric unique, c'est une panne. Sur un double fabric correctement construit, c'est une perte de chemin, à condition que l'autre fabric n'ait pas été modifié de la même manière au même moment. Beaucoup d'opérateurs préparent un script et l'exécutent sur les deux switches l'un après l'autre. Cela transforme deux fabrics indépendants en un point de défaillance partagé : la personne qui tient le script.

Concevez les zones pour que les erreurs soient visibles

Zoning single initiator. Chaque zone contient un port HBA d'hôte et les ports de baie qu'il doit voir. Les hôtes ne partagent jamais de zone, donc un HBA qui se comporte mal ne peut pas perturber ses voisins, et retirer un hôte revient à retirer ses zones et rien d'autre.

Des alias, pas des WWPN bruts. Chaque port reçoit un alias, et les zones sont construites à partir des alias.

Une règle de nommage qui porte le fabric. Mettez la lettre du fabric dans chaque nom d'alias et de zone, pour qu'une zone destinée au Fabric A collée dans le Fabric B saute aux yeux de quiconque lit le changement. Limitez les noms aux lettres majuscules, aux chiffres et aux tirets bas. Certains fabrics refusent les traits d'union et d'autres caractères dans les noms d'objets, et les noms sont sensibles à la casse, donc une seule convention utilisée partout supprime toute une classe d'erreurs.

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

Avant de commencer : les vérifications préalables

Sauvegardez l'état actuel des deux fabrics avant de changer quoi que ce soit :

cfgshow
cfgactvshow
zoneshow
alishow
nsshow
cfgtransshow

nsshow (le name server) confirme que les ports du nouvel hôte se sont réellement connectés au fabric et montre les WWPN tels que le switch les voit, ce qui est la source à partir de laquelle construire les alias, plutôt qu'une étiquette sur un boîtier. cfgtransshow vous dit si quelqu'un d'autre a une transaction de zoning ouverte sur ce fabric. S'il y en a une d'ouverte et qu'elle n'est pas la vôtre, arrêtez-vous et trouvez à qui elle appartient.

Sur chaque hôte existant que le changement pourrait toucher, relevez le nombre de chemins (multipath -ll), pour pouvoir prouver ensuite que rien n'a changé pour eux.

Le changement lui-même, un fabric à la fois

Commencez par le fabric que vous préféreriez perdre. Construisez tout le changement en une seule session, comme une seule transaction :

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 enregistre la configuration et l'active en une étape, et demande confirmation avant de valider. Si vous le scriptez, le script doit répondre à cette invite puis lire la sortie pour y trouver le message de validation, et non supposer le succès parce que la commande a rendu la main. Rien n'est actif tant que l'activation n'est pas terminée, ce qui est votre dernière occasion de relire le changement préparé avec cfgshow.

Puis vérifiez, depuis trois endroits :

1. Le switch. cfgactvshow contient la nouvelle zone, et chaque zone qui existait avant est toujours là.
2. La baie. Le port du nouvel hôte sur ce fabric apparaît désormais connecté aux ports de baie attendus.
3. Les hôtes. Le nouvel hôte voit ses volumes à travers le port HBA de ce fabric. Les hôtes existants montrent exactement le nombre de chemins relevé lors des vérifications préalables.

Sur le nouvel hôte Linux, un rescan et un coup d'œil au HBA suffisent :

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

Ce n'est que lorsque les trois concordent que vous répétez le même changement sur l'autre fabric, construit de la même façon et vérifié de la même façon. Si quelque chose semble anormal sur le premier fabric, vous vous arrêtez là. La production tourne toujours sur le fabric intact, et vous avez votre configuration sauvegardée à restaurer.

Après le changement

Mettez à jour l'inventaire dans la même session, pour que le fabric et l'enregistrement ne soient jamais en désaccord.

Comment nous le faisons

Nos fabrics sont construits comme deux fabrics Brocade totalement indépendants, des switches de cœur jusqu'aux switches embarqués dans nos châssis de lames HPE. Un lot de nouveaux serveurs peut être mis en zone un fabric à la fois en quelques minutes de temps de changement sur le fabric, pendant que les zones qui portent la production restent exactement telles qu'elles étaient.

Si votre prochain changement de stockage implique de toucher les deux fabrics, nous serons heureux de relire le plan avec vous avant qu'il ne s'exécute.

Parler à un ingénieur

Related (rows[1])

Voir aussi : SAN Fibre Channel à double fabric sur Brocade · Stockage SAN enterprise sur HPE 3PAR, all-flash · Serveurs bare metal sur HPE et Dell