Finestre di manutenzione: cosa si fa sotto carico invece

Due tipi di lavoro pianificato

Il lavoro pianificato ricade in due gruppi. Il primo viene assorbito dal design: un controller storage che riceve nuovo firmware, un leaf switch che viene sostituito, un host hypervisor che va giù per la memoria, una coppia di firewall che applica un aggiornamento. Il secondo cambia qualcosa che in quel momento non ha un partner: un cutover di piattaforma, la sincronizzazione finale di una migrazione storage, una modifica irreversibile dello schema. Il primo gruppo si fa sotto carico. Il secondo riceve una finestra, e la finestra viene progettata invece che semplicemente annunciata.

Cosa assorbe il design

Un array HPE 3PAR porta due nodi controller che servono gli stessi volumi, con ogni host collegato attraverso due fabric Brocade indipendenti. Il firmware va su un nodo alla volta; mentre quello si riavvia, il livello multipath degli host mantiene l'I/O in movimento sui percorsi superstiti, e il nodo rientra prima che il secondo venga toccato. Lo stesso schema vale a ogni livello costruito in coppia. I leaf Cisco Nexus 9000 sono distribuiti in coppie con ogni host in bond su entrambi, così uno switch può ricevere un aggiornamento o una sostituzione mentre l'altro link porta il traffico. Gli host hypervisor vengono svuotati con la live migration prima che vi si faccia qualsiasi cosa, e le macchine virtuali tornano indietro dopo. I router di edge mantengono sessioni con più di un carrier, e una sessione viene drenata prima che il suo router venga toccato.

Nulla di questo è insolito in un datacenter serio. Ciò che conta è se le coppie vengono esercitate. Un partner che esiste sul diagramma ma non ha mai portato produzione è una supposizione, e il momento di scoprire che era una supposizione non è durante la modifica.

Verificate il partner prima di toccare il primario

La disciplina utile è il controllo che avviene prima della modifica. Prima che un controller venga messo giù, a ogni host collegato si chiede quanti percorsi attivi mantiene verso l'array; un host che riporta un solo percorso viene corretto per primo, perché per quell'host la finestra arriverebbe altrimenti senza invito. Prima che uno switch venga toccato, si legge il bond su ogni host per confermare che entrambi i membri siano up e stiano passando traffico, e si conferma che il secondo switch stia inoltrando e non sia semplicemente acceso. Prima che un host venga drenato, si conferma che la destinazione della migrazione abbia il margine per ciò che sta arrivando.

# on each attached host, before controller work: every LUN should show two or more active paths
$ multipath -ll | grep -c 'active ready'

# before switch work: both bond members up and passing traffic
$ grep -E 'Slave Interface|MII Status' /proc/net/bonding/bond0

Poi la modifica viene fatta, e le stesse letture vengono ripetute mentre il partner rientra. Il risultato è lavoro pianificato che non vi interrompe, che è diverso da lavoro pianificato non comunicato: la modifica è nel nostro registro e, dove tocca la vostra piattaforma, nella vostra casella di posta, con il meccanismo dichiarato.

Le modifiche che meritano una finestra

Una finestra è la risposta giusta quando un passaggio è irreversibile, quando il componente per sua natura non ha un partner in quel momento, o quando la procedura del vendor richiede che il servizio sia quiescente. Un cutover di piattaforma è il caso comune: nel momento in cui il traffico si sposta dal vecchio ambiente al nuovo, c'è un intervallo, di solito delimitato dalla propagazione DNS o dallo spostamento di un VIP, in cui il servizio è in transito.

Una finestra ben progettata è riconoscibile. Nomina il componente e il meccanismo, così sapete cosa sta cambiando e perché non può essere fatto sotto carico. Dichiara l'impatto atteso visibile al cliente separatamente dalla durata dell'operazione; un'operazione di due ore può avere un impatto visibile di minuti, e l'avviso dice quale è quale. Ha un punto di decisione e un rollback che è stato provato, non descritto. È concordata con voi: se una modifica potrebbe toccare il vostro traffico, concordiamo prima la tempistica con voi. E si chiude con un rapporto che confronta l'effettivo con l'annunciato.

Leggere un avviso di manutenzione

Tre domande vi dicono gran parte di ciò che vi serve sul design sotto qualsiasi piattaforma, la nostra compresa: qual è il componente, perché non può essere fatto sotto carico, e qual è l'impatto visibile atteso rispetto alla durata dell'operazione. Un avviso che risponde a tutte e tre è un piano. Noi scriviamo i nostri per rispondervi.