Modifiche di zoning Fibre Channel, un fabric alla volta

Due fabric Fibre Channel vi proteggono da uno switch morto. Non vi proteggono da una modifica di zoning disattenta applicata a entrambi i fabric nello stesso minuto. La disciplina che chiude quel varco è semplice da descrivere e facile da saltare: cambiate un fabric, dimostratelo, e solo allora toccate l'altro.

Perché lo zoning è il lavoro di routine più rischioso in una SAN

Lo zoning decide quali initiator (porte HBA degli host) possono parlare con quali target (porte dell'array). Cambia ogni volta che un server viene aggiunto, sostituito o dismesso, quindi è lavoro di routine, e il lavoro di routine è dove l'attenzione cala. Su un fabric Brocade la configurazione di zoning attiva è un oggetto unico. Quando ne abilitate una nuova versione, l'intero fabric prende la nuova versione in un colpo solo. Un refuso che fa cadere una zona, un membro incollato nella zona sbagliata o una configurazione abilitata prima di essere finita possono togliere all'istante a un host di produzione l'accesso ai suoi dischi su quel fabric.

Su un fabric singolo, è un disservizio. Su un dual fabric costruito correttamente, è una perdita di percorso, a patto che l'altro fabric non sia stato modificato allo stesso modo nello stesso momento. Molti operatori preparano uno script e lo eseguono sui due switch uno dietro l'altro. Questo trasforma due fabric indipendenti in un unico punto di guasto condiviso: la persona che tiene lo script.

Progettate le zone perché gli errori siano visibili

Zoning single initiator. Ogni zona contiene una porta HBA di un host e le porte dell'array che deve vedere. Gli host non condividono mai una zona, così un HBA che si comporta male non può disturbare i vicini, e rimuovere un host significa rimuovere le sue zone e nient'altro.

Alias, non WWPN nudi. Ogni porta riceve un alias, e le zone si costruiscono dagli alias.

Una regola di nomenclatura che porta con sé il fabric. Mettete la lettera del fabric in ogni nome di alias e di zona, così una zona per il Fabric A incollata nel Fabric B è palesemente sbagliata per chiunque legga la modifica. Tenete i nomi a lettere maiuscole, cifre e underscore. Alcuni fabric rifiutano i trattini e altri caratteri nei nomi degli oggetti, e i nomi sono case sensitive, quindi una sola convenzione usata ovunque elimina un'intera classe di errori.

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

Prima di iniziare: controlli preliminari

Salvate lo stato corrente di entrambi i fabric prima di cambiare qualsiasi cosa:

cfgshow
cfgactvshow
zoneshow
alishow
nsshow
cfgtransshow

nsshow (il name server) conferma che le porte del nuovo host hanno davvero fatto login nel fabric e mostra i WWPN come li vede lo switch, che è ciò da cui dovreste costruire gli alias, invece che da un'etichetta su una scatola. cfgtransshow vi dice se qualcun altro ha una transazione di zoning aperta su questo fabric. Se ce n'è una aperta e non è la vostra, fermatevi e scoprite di chi è.

Su ogni host esistente che la modifica potrebbe toccare, registrate il numero di percorsi (multipath -ll), così da poter dimostrare dopo che per loro non è cambiato nulla.

La modifica vera e propria, un fabric alla volta

Cominciate dal fabric che preferireste perdere. Costruite l'intera modifica in una sola sessione, come una sola transazione:

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 salva la configurazione e la rende attiva in un solo passaggio, e chiede conferma prima di fare il commit. Se lo mettete in uno script, lo script deve rispondere a quel prompt e poi leggere l'output cercando il messaggio di commit, non presumere il successo perché il comando è tornato. Nulla è attivo finché l'enable non è completato, che è la vostra ultima occasione di rileggere la modifica preparata con cfgshow.

Poi verificate, da tre punti:

1. Lo switch. cfgactvshow contiene la nuova zona, e ogni zona che c'era prima c'è ancora.
2. L'array. La porta del nuovo host su questo fabric risulta ora connessa alle porte dell'array attese.
3. Gli host. Il nuovo host vede i suoi volumi attraverso la porta HBA di questo fabric. Gli host esistenti mostrano esattamente il numero di percorsi registrato nei controlli preliminari.

Sul nuovo host Linux bastano un rescan e un'occhiata all'HBA:

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

Solo quando tutti e tre concordano ripetete la stessa modifica sull'altro fabric, costruita allo stesso modo e verificata allo stesso modo. Se qualcosa sembra sbagliato sul primo fabric, vi fermate lì. La produzione gira ancora sul fabric intatto, e avete la configurazione salvata da ripristinare.

Dopo la modifica

Aggiornate l'inventario nella stessa sessione, così il fabric e il registro non saranno mai in disaccordo.

Come lo facciamo noi

I nostri fabric sono costruiti come due fabric Brocade completamente indipendenti, dagli switch core fino agli switch integrati nei nostri enclosure blade HPE. Un lotto di nuovi server può essere messo in zona un fabric alla volta in pochi minuti di tempo di modifica del fabric, mentre le zone che trasportano la produzione restano esattamente com'erano.

Se la vostra prossima modifica allo storage prevede di toccare entrambi i fabric, saremo lieti di rivedere il piano con voi prima che venga eseguito.

Parla con un ingegnere

Related (rows[1])

Correlati: SAN Fibre Channel dual fabric su Brocade · Storage SAN enterprise su HPE 3PAR, all-flash · Server bare metal su HPE e Dell