Jay Parikh, a capo della divisione ingegneria ed infrastruttura presso Facebook, ha recentemente tenuto all’evento @Scale un interessante intervento sui data center ed i blackout programmati. Come abbiamo visto in un altro post, i piani di disaster recovery sono cruciali per qualsiasi azienda e le modalità di approccio ai fallimenti di sistema (failure) si sono rapidamente evolute nel corso degli anni – ricordiamo ad esempio le architetture always on.
La compagnia dietro al noto social network si cimenta regolarmente da quattro anni nella gestione di situazioni d’emergenza, i cosidetti blackout programmati – perchè indotti volontariamente dall’azienda per mettere alla prova lo staff tecnico. Parikh ha spiegato che si tratta di vere e proprie esercitazioni dal valore inestimabile per il team.
L’idea di fronteggiare “situazioni al limite” nacque a seguito dell’eccezionale evento meteorologico che colpì gli USA nel 2012, ovvero l’uragano soprannominato Sandy. In quell’occasione diversi data center statunitensi vennero danneggiati e/o andarono offline causando prolungati disservizi. L’infrastruttura della compagnia non subì fortunatamente danni (i principali data center si trovavano infatti lontano dalle zone più duramente colpite) ma fu allora che si iniziò a pensare cosa sarebbe potuto accadere se uno di questi fosse stato coinvolto dal fenomeno.
Per rispondere al “semplice” quesito venne creato un apposito team (Project Storm) di ingegneri il quale, da quel momento in poi, sarebbe stato coinvolto periodicamente in un’esercitazione su larga scala rivolta non solo a loro ma a buona parte della staff tecnico e della compagnia in generale, ha precisato Parikh.
Traffico e load balancing
Mandare offline un singolo data center, ha proseguito, non è per niente semplice. Ogni infrastruttura processa infatti decine di terabyte di traffico al secondo, consuma non trascurabili quantità di energia elettrica (nell’ordine dei megawatt) ed esegue migliaia di servizi software. “Si tratta di un problema [complesso da gestire e del quale venire a capo ogni volta]. […] Le prime esercitazioni non sono andate per il verso giusto” – gli utenti del social network più celebre della Rete non si sono naturalmente accorti di nulla, ha sottolineato.
Il team, sebbene l’esperienza del blackout sia tutt’altro che piacevole, ha potuto in ogni caso consolidare notevolmente la propria esperienza sui disservizi. Di seguito viene mostrato un grafico di riepilogo delle prime esercitazioni:
L’andamento instabile del grafico suggerisce la complessità di una situazione d’emergenza post blackout
Anche l’utente più inesperto nota come la situazione sia tutt’altro che stabile. Quando un ingegnere si trova davanti ad un grafico del genere, ha commentato Parikh, significa che il sistema sta lavorando male e che, in pratica, non si ha la minima idea di quel che potrà accadere di lì a poco. Ecco invece il grafico dei flussi una volta affinate le procedure di gestione:
Le linee del grafico suggeriscono in questo caso che la situazione è sotto controllo
Una seconda (prevedibile) lezione appresa dallo Storm Project è la seguente: riportare un data center online richiede tempo – per questo altre compagnie cercano di affidarsi a strategie alternative. E’ molto più rapido mandare un data center offline piuttosto che ripristinarne il funzionamento, ha aggiunto l’ingegnere. Si tratta di una scoperta molto simile a quella di un bambino in tenera età: smontare un giocattolo richiede molto meno tempo di un eventuale riassemblaggio.
L’esperienza acquisita è stato inoltre sfruttata per la stesura di un “manuale” dedicato alla messa offline ed al ripristino di un data center. Al suo interno sono indicate le migliori procedure manuali ed automatiche individuate in questi anni dagli ingegneri. Durante ogni esercitazione viene inoltre misurata la tempistica d’esecuzione di ogni passaggio elencato nel manuale, al fine di migliorare le prestazioni del team. Secondo Parikh sono tre gli elementi chiave in grado di garantire la scalabilità e la resilienza delle infrastrutture:
- l’utilizzo di adeguati strumenti.
- Affrontare situazioni al limite (embrace the failure).
- La dedizione. Per l’ingegnere, il rinvio di una esercitazione in favore del lancio di un prodotto è un esempio di “non dedizione”. Il lancio avverrà comunque e non potrai mai sapere come potrà comportarsi il prodotto in caso di blackout. Le esercitazioni sono state pensate anche per scoprirlo, ha concluso Jay Parikh.
