Fibre-Channel-Zoning-Änderungen, eine Fabric nach der anderen

Zwei Fibre-Channel-Fabrics schützen Sie vor einem toten Switch. Sie schützen Sie nicht vor einer unachtsamen Zoning-Änderung, die in derselben Minute auf beide Fabrics angewendet wird. Die Disziplin, die diese Lücke schließt, ist einfach zu beschreiben und leicht zu überspringen: Ändern Sie eine Fabric, beweisen Sie es, und erst dann fassen Sie die andere an.

Warum Zoning die riskanteste Routinearbeit in einem SAN ist

Zoning entscheidet, welche Initiatoren (HBA-Ports der Hosts) mit welchen Targets (Array-Ports) sprechen dürfen. Es wird jedes Mal geändert, wenn ein Server hinzukommt, ersetzt oder außer Betrieb genommen wird, also ist es Routinearbeit, und Routinearbeit ist der Ort, an dem die Aufmerksamkeit nachlässt. In einer Brocade-Fabric ist die aktive Zoning-Konfiguration ein einziges Objekt. Wenn Sie eine neue Version davon aktivieren, übernimmt die ganze Fabric die neue Version auf einmal. Ein Tippfehler, der eine Zone fallen lässt, ein Mitglied, das in die falsche Zone eingefügt wurde, oder eine Konfiguration, die aktiviert wurde, bevor sie fertig war, kann einem Produktionshost sofort den Zugriff auf seine Platten in dieser Fabric nehmen.

In einer einzelnen Fabric ist das ein Ausfall. In einer korrekt gebauten Doppel-Fabric ist es ein Pfadverlust, vorausgesetzt, die andere Fabric wurde nicht zur selben Zeit auf dieselbe Weise geändert. Viele Betreiber bereiten ein Skript vor und lassen es direkt nacheinander gegen beide Switches laufen. Das verwandelt zwei unabhängige Fabrics in einen gemeinsamen Fehlerpunkt: die Person, die das Skript in der Hand hält.

Entwerfen Sie die Zonen so, dass Fehler sichtbar sind

Single-Initiator-Zoning. Jede Zone enthält einen HBA-Port eines Hosts und die Array-Ports, die er sehen soll. Hosts teilen sich nie eine Zone, sodass ein HBA, der sich falsch verhält, seine Nachbarn nicht stören kann, und einen Host zu entfernen heißt, seine Zonen zu entfernen und sonst nichts.

Aliase, keine rohen WWPNs. Jeder Port bekommt einen Alias, und Zonen werden aus Aliasen gebaut.

Eine Namensregel, die die Fabric mitführt. Setzen Sie den Fabric-Buchstaben in jeden Alias- und Zonennamen, sodass eine Zone für Fabric A, die in Fabric B eingefügt wird, für jeden, der die Änderung liest, offensichtlich falsch ist. Beschränken Sie Namen auf Großbuchstaben, Ziffern und Unterstriche. Manche Fabrics verweigern Bindestriche und andere Zeichen in Objektnamen, und Namen unterscheiden Groß- und Kleinschreibung, sodass eine überall verwendete Konvention eine ganze Fehlerklasse beseitigt.

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

Bevor Sie anfangen: Pre-Flight

Sichern Sie den aktuellen Zustand beider Fabrics, bevor Sie irgendetwas ändern:

cfgshow
cfgactvshow
zoneshow
alishow
nsshow
cfgtransshow

nsshow (der Name Server) bestätigt, dass die Ports des neuen Hosts sich tatsächlich in die Fabric eingeloggt haben, und zeigt die WWPNs, wie der Switch sie sieht, und daraus sollten Sie Aliase bauen, nicht aus einem Etikett auf einem Gehäuse. cfgtransshow sagt Ihnen, ob jemand anderes eine offene Zoning-Transaktion in dieser Fabric hat. Wenn eine offen ist und sie nicht Ihre ist, halten Sie an und finden Sie heraus, wessen sie ist.

Erfassen Sie auf jedem bestehenden Host, den die Änderung berühren könnte, die Pfadanzahlen (multipath -ll), damit Sie hinterher beweisen können, dass sich für sie nichts geändert hat.

Die Änderung selbst, eine Fabric nach der anderen

Beginnen Sie mit der Fabric, die Sie lieber verlieren würden. Bauen Sie die ganze Änderung in einer Sitzung, als eine Transaktion:

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 speichert die Konfiguration und aktiviert sie in einem Schritt, und es fragt vor dem Commit nach Bestätigung. Wenn Sie es skripten, muss das Skript diese Abfrage beantworten und dann die Ausgabe auf die Commit-Meldung lesen, nicht Erfolg annehmen, weil der Befehl zurückgekehrt ist. Nichts ist live, bis das Enable abgeschlossen ist, und das ist Ihre letzte Gelegenheit, die vorbereitete Änderung noch einmal mit cfgshow zu lesen.

Verifizieren Sie dann von drei Stellen aus:

1. Der Switch. cfgactvshow enthält die neue Zone, und jede Zone, die vorher da war, ist noch da.
2. Das Array. Der Port des neuen Hosts in dieser Fabric zeigt sich jetzt als verbunden mit den erwarteten Array-Ports.
3. Die Hosts. Der neue Host sieht seine Volumes über den HBA-Port dieser Fabric. Bestehende Hosts zeigen genau die Pfadanzahlen, die Sie im Pre-Flight erfasst haben.

Auf dem neuen Linux-Host genügen ein Rescan und ein Blick auf den HBA:

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

Erst wenn alle drei übereinstimmen, wiederholen Sie dieselbe Änderung auf der anderen Fabric, auf dieselbe Weise gebaut und auf dieselbe Weise verifiziert. Wenn auf der ersten Fabric irgendetwas falsch aussieht, halten Sie dort an. Die Produktion läuft noch auf der unberührten Fabric, und Sie haben Ihre gesicherte Konfiguration zum Wiederherstellen.

Nach der Änderung

Aktualisieren Sie das Inventar in derselben Sitzung, damit Fabric und Datensatz nie auseinanderlaufen.

Wie wir es machen

Unsere Fabrics sind als zwei vollständig unabhängige Brocade-Fabrics gebaut, von den Core-Switches bis hinunter zu den Switches, die in unsere HPE-Blade-Enclosures eingebettet sind. Eine Charge neuer Server kann eine Fabric nach der anderen in wenigen Minuten Fabric-Änderungszeit gezont werden, während die Zonen, die Produktion tragen, genau so bleiben, wie sie waren.

Wenn Ihre nächste Storage-Änderung beide Fabrics berührt, sehen wir uns den Plan gern mit Ihnen an, bevor er läuft.

Mit einem Ingenieur sprechen

Related (rows[1])

Verwandte Themen: Fibre-Channel-SAN mit zwei Fabrics auf Brocade · Enterprise-SAN-Storage auf HPE 3PAR, All-Flash · Bare-Metal-Server auf HPE und Dell