Buongiorno a tutti!
Oggi voglio raccontare un piccolo aneddoto che mi è successo la settimana scorsa presso un nostro importante e Cliente (del quale, per ragioni di NDA, non posso condividere in questa sede il nome).
Partiamo da una premessa che ritengo sia molto importante per cogliere il contesto di questa storia: come molti colleghi e amici sanno, poco più di tre mesi ho deciso di cogliere l’opportunità di entrare a far parte del team di professionisti Pure Storage Italia. Come per ogni nuova avventura, anche in questo caso, sono tutt’oggi in una fase di induction. I miei nuovi colleghi, con grande pazienza e passione, mi stanno aiutando a conoscere la nuova azienda con i suoi prodotti e soluzioni. Proprio nell’ambito di questo percorso, sono stato “invitato” a partecipare ad una attività NDU (Non-Disruptive Upgrade – https://www.purestorage.com/it/knowledge/what-are-non-disruptive-upgrades.html ) di un array acquistato un paio d’anni fa dal Cliente di cui sopra.
Quando parlo di NDU, parlo di un’attività di trasformazione “a caldo” della nostra soluzione FlashArray//X: dovevamo infatti “trasformare” un FlashArray//X50 R2 in un sistema FlashArray//X70 R3.
A tal proposito, mi permetto di aggiungere anche una piccola nota tecnica che, ci aiuta a comprendere meglio il processo che descrivo poi sotto. Ogni FlashArray//X è costituito da due controller (controller 0 e controller 1); dal punto di vista architetturale, nel front-end dello storage, entrambe le controller sono attive e gestiscono le richieste di I/O degli host collegato allo storage (in una logica di bilanciamento e parallelismo); mentre nel back-end le operazioni di I/O vengono presa in carico e gestite da una sola controller (che viene definita come primaria). L’obiettivo e il plus offerto da questa architettura, è quello di garantire che in caso di riavvio/spegnimento/sostituzione della controller primaria, l’altra controller (la secondaria) possa erogare il servizio di accesso ai dati con lo stesso livello di performance: senza alcun degrado prestazionale nei confronti degli host connessi.
Con molta onestà (e umiltà) posso dire che avevo sentito parlare del processo di NDU di Pure da competitor (nelle mie esperienze lavorative pregresse), lo avevo visto raccontato attraverso tante presentazioni e/o video promozionali, ma mai avevo visto farlo “live”!
Lo ammetto: ero scettico! Ero scettico soprattutto rispetto al concetto di “semplicità” che accompagna i messaggi promozionali di Pure Storage.
Ma veniamo al dunque: ore 09:40 – Accompagnati dal Cliente, siamo andati nel datacenter dove erano già arrivati gli imballi delle nuove controller FA//X70 R3. Insieme ai tecnici certificati di uno dei nostri più importanti partner di canale, abbiamo sballato il tutto e verificato che il nostro centro di supporto europeo fosse collegato da remoto.
Tutto ok? Sì! Allora via, “apriamo le danze” e iniziamo con l’attività…
- Pre-Check dello stato del sistema in produzione (FlashArray//X50 R2 con due Disk Shelf NVMe di espansione connessi)
- Verifica dello stato e della quantità delle operazioni di I/O generate dagli host sullo storage (semplicemente per averne conoscenza, a nessun host è stato richiesto di ridurre o addirittura azzerare l’attività di lettura/scrittura generata verso gli array)
- Disconnessione di tutti i cavi che interconnettevano il controller 0 con gli shelf di espansione (2) e quelli che la attestavano verso la SAN
- Estrazione “estrazione a caldo” del controller 0 //X50 R2
- Inserimento, sempre “a caldo” della nuova controller 0 //X70 R3
- Attivazione software della nuova controller 0 //X70 R3
- Riconnessione di tutti i cavi di interconnessione con gli shelf di espansione (2) e quelli che la attestavano verso la SAN per la nuova controller 0 //X70 R3
- Check dello stato del sistema (attivo con un “vecchio” Controller //X50 R2 e un nuovo controller //X70 R3)
- Assegnazione di tutti i data services sul nuovo controller //X70 R3
- Disconnessione di tutti i cavi che interconnettevano il controller 1 con gli shelf di espansione (2) e quelli che la attestavano verso la SAN
- Estrazione “estrazione a caldo” del controller 1 //X50 R2
- Inserimento, sempre “a caldo” della nuova controller 1 //X70 R3
- Attivazione software della nuova controller 1 //X70 R3
- Riconnessione di tutti i cavi di interconnessione con gli shelf di espansione (2) e quelli che la attestavano verso la SAN per la nuova controller 1 //X70 R3
- Check dello stato del sistema con i due nuovi controller //X70 R3
- Verifica dello stato e della quantità delle operazioni di I/O generate dagli host sul “nuovo” storage)
E voilà!
Senza nemmeno un secondo di interruzione dei servizi di accesso ai dati per gli host connessi (VMware Infrastructures, Physical Oracle databases systems, Physical MS-SQL databases systems e qualche Application Server Linux) abbiamo trasformato un FlashArray//X50 R2 in nuovo FlashArray//X70 R3!!!
No downtime, No data migration!
Al mio stupore, si è poi aggiunto altro stupore: parlo del tempo necessario per completare l’intero processo di NDU; 2 Ore e 15 min!!! Tutto rigorosamente svolto in pieno orario di produzione. Abbiamo iniziato alle 10:00 del mattino di un qualunque martedì infrasettimanale e, abbiamo terminato (senza che nessuno potesse minimamente accorgersene) alle 12:15!!
Lo ammetto ancora una volta: ero scettico quando sentivo parlare di aggiornamento NDU dei nostri FlashArray, ma ora ho visto con i miei occhi e posso dire:
