Servizi Cloud, 5 punti per migliorare il livello di disponibilità

Gli SLA non sono sufficienti per proteggersi dalle interruzioni di funzionamento di un ambiente Cloud. La disponibilità di un servizio che si misura nell’ordine percentuale del 99 seguito da due o più decimali non può essere pari al 100%.

In base al modello della “share responsability” non solo il provider della nuvola, ma anche chi usa il Cloud per erogare propri servizi è responsabile per l’applicazione delle corrette pratiche di backup e di configurazione.

I guasti dei Cloud, per fortuna poco frequenti, bloccano migliaia di aziende provocando grandi danni. Tra i più famosi ci sono quelli di AWS (Amazon Web Services) dell’aprile 2011 e dell’ottobre 2012 che fermarono i servizi di Reddit, Netflix e FourSquare; l’incendio alla farm Aruba del 29 aprile 2011 che spense molti siti Web italiani o ancora il blocco di circa due ore sofferto nel luglio scorso dai server europei di Microsoft Windows Azure.

Anche i servizi Cloud meglio gestiti e sicuri possono subire delle cadute e diventare indisponibili. Per prevenirne le conseguenze è necessario progettare sistemi capaci di minimizzare l’impatto dei guasti attraverso i classici metodi della ridondanza e del failover automatico. Sulla base della propria esperienza, Nati Shalom, fondatore di GigaSpaces, suggerisce una strategia in cinque punti per ottenere più alti livelli di disponibilità dei servizi basati su Cloud.

1. Progettare l’architettura per resistere ai guasti. Serve distribuire il sistema in più luoghi fisici per poter lavorare anche in caso di indisponibilità di singoli siti. L’architettura deve riconoscere i guasti e avviare automaticamente il failover spostando i carichi di lavoro su altri siti disponibili, regioni o Cloud assicurando l’alta disponibilità. Questo può essere ottenuto in AWS con l’Elastic Load Balancer applicato su differenti zone geografiche. Secondo una rilevazione di Newven, ad oggi solo il 29% degli utenti AWS usano il load balancer su differenti zone.
2. Conoscere gli SLA. La “shared responsibility” significa che il service provider che usa il Cloud ha la responsabilità dei servizi nei riguardi dei propri utenti per quanto riguarda funzionamento, compliance e disponibilità. Quando si spostano le applicazioni nel Cloud si cede il controllo dell’infrastruttura e quindi occorre conoscere molto bene i limiti di responsabilità. Se il servizio cade, gli SLA assumono un’importanza relativa. Diventano fattori chiave la comunicazione con gli utilizzatori finali e la massima trasparenza sullo stato e i tempi del ripristino. E’ inoltre importante l’analisi a posteriori del guasto per evitare che si ripeta.
3. Prepararsi allo scenario peggiore. La sfida maggiore dell’alta disponibilità è definire un’appropriata strategia di disaster recovery. Serve monitorare le attività di backup dei dati critici, creare sistemi automatici per un rapido recupero. Disaster recovery e ridondanza sono competenze classiche della gestione dati così come comprendere termini quali RTO e RPO (tempi e punti di recovery). Il Cloud crea nuove opzioni per il data recovery e lo rende più facile compatibilmente con i costi dello storage utilizzato.
4. Valutare i costi. Un blocco di un ora di un servizio come Amadeus si stima possa costare circa 89mila dollari di fatturato perso, mentre per Paypal il danno può superare i 225mila dollari. Se da, una parte, è facile ottenere l’alta disponibilità duplicando tutti i sistemi, dall’altra parte questa soluzione non è economicamente conveniente. Con il Cloud è inoltre possibile disporre di una sorta di “disponibilità on demand” in cui script automatici permettono di scalare la potenza richiesta e spegnere i server nei siti geografici che non servono. Non occorre quindi comprare più server, ma avere un’architettura in grado di mantene i processi in linea anche in caso di blocco di alcuni servizi Cloud.
5. Trasparenza e test. La trasparenza è un aspetto molto apprezzato, in particolare dagli utenti di grandi imprese che hanno al loro interno personale abituato al controllo fisico delle risorse. I fornitori Cloud e gli sviluppatori di applicazioni basate su questa modalità di erogazione hanno bisogno di avere il feedback degli utenti, conoscere i progressi di adozione delle soluzioni. Un ambiente trasparente favorisce il miglioramento dei servizi, è cruciale per evitare guasti o altrimenti aiuta a prevedere i problemi, avvisando gli utenti prima che inondino di chiamate il supporto.