Il blackout dei sistemi informatici della compagnia di volo statunitense Delta si è rivelato un’ottima fonte d’ispirazione per la stampa di settore, la quale ha colto l’occasione per riaprire la discussione su importanti temi come la disponibilità delle risorse, le procedure di failover ed i piani disaster recovery. In relazione agli ultimi due, il portale High Scalability ha pubblicato un interessante articolo dedicato alle cosidette architetture always on, definite come il naturale passo evolutivo dei vecchi approcci disaster recovery. Vediamo meglio come funzionano e quali vantaggi sono in grado di offrire.
Per diversi anni, esordisce l’editorialista, ci si è preparati a fronteggiare problematiche inattese (guasti hardware, problemi di connettività etc.) appoggiandosi all’occorrenza ad una serie di elementi di supporto (un data center, un router, un generatore e così via) una volta individuata la causa dell’evento critico – procedura alla quale ci si riferisce con il termine “failover“. Grazie alle infrastrutture cloud i piani disaster recovery “vecchio stile” non sono più necessari: citando l’esempio di Google (certo non tutti dispongono dei mezzi della nota compagnia), veniamo introdotti al concetto di always on architecture o, nel caso di Mountain View, natively multihomed architecture. In cosa consiste esattamente? In sintesi l’approccio permette di distribuire dati tra vari data center in modo che ciascuno di essi resti sempre attivo, scalando automaticamente la propria capacità in base a quello che accade nelle infrastrutture collegate. A prima vista il solito spot pubblicitario dei provider cloud, osserva il giornalista.
Come funzionano le architetture always on
Il paper High-Availability at Massive Scale: Building Google’s Data Infrastructure for Ads spiega invece in maniera più dettagliata il funzionamento di tali architetture e perchè siano preferibili alle vecchie procedure failover. All’atto pratico il failover, il passare da uno a più data center in caso di imprevisti, non funziona come dovrebbe. L’always on permette invece di preservare l’elevata disponibilità delle risorse con un impiego minimo di risorse:
“il nostro attuale approccio è quello di costruire sistemi nativamente multihomed. Questi sistemi sono costantemente in esecuzione in più data center e muovono adattivamente il carico di lavoro [tra le infrastrutture] affrontando blackout di qualsiasi scala in maniera completamente trasparente. In aggiunta anche le operazioni di manutenzione ed i blackout programmati avvengono in maniera trasparente, causando minime interferenze con i sistemi operativi (operational system). In passato tali situazioni richiedevano eccezionali sforzi per spostare i sistemi operativi da un data center ad un altro”.
Il principale problema degli approcci basati su failover, si legge nel documento, è che non sono in grado di garantire realmente l’alta disponibilità rivelandosi inoltre costosi in termini di risorse – per via del deploy delle risorse da mantenere in “standby” ed utilizzare in caso di necessità:
“i nostri team hanno avuto diverse esperienze negative con sistemi basati su failover. Considerando che i blackout non programmati rappresentano un evento raro, le procedure di failover sono sempre implementate come una [sorta di piano b] non automatizzato e non testato a dovere. In più occasioni i team hanno impiegato giorni per risolvere i problemi causati da un blackout – riportando online ciascun componente dei sistemi, recuperando gli stati con tool specifici come MapReduce, configurando manualmente i sistemi mano a mano che riprendevano ad eseguire le task rimaste in arretrato dall’inizio del disservizio. Queste situazioni non solo provocano una prolungata non disponibilità dei servizi ma si rivelano estremamente stressanti per i team che supervisionano complessi sistemi mission critical”.
Nello schema si confronta un classico setup failover (data center) con uno multihomed (3 data center). Il quantitativo di risorse impiegate è rispettivamente del 300% e del 170% dello stato di normale funzionamento del sistema (steady state). Il quantitativo di risorse extra per il recupero del lavoro (catch-up) rimasto arretrato è sensibilmente inferiore nel setup multihomed perchè gli altri data center contribuiscono attivamente al processo
“I sistemi multihomed sono parte integrante dell’infrastruttura, una scelta di design stabilita fin dall’inizio che non prevede il concetto di failover. Il sistema resta sempre in esecuzione in diversi data center. Ciascun data center si occupa di processare i lavori che sono dinamicamente condivisi tra le altre strutture per bilanciare il carico complessivo. Quando un data center rallenta il passo, una parte del lavoro assegnatogli viene spostato automaticamente ad un data center più veloce. Se un data center risulta completamente irraggiungibile tutte le sue task sono ridistribuite presso gli altri data center.
Secondo lo schema appena delineato nel paper, le procedure di failover sono superate: il bilanciamento dinamico dei carichi di lavoro ed il coordinamento tra i vari data center consentono, all’atto pratico, di automatizzare procedure attuabili nei classici piani disaster recovery solo dallo staff tecnico.
