Trovo molto divertente vedere in rete come si dibatte parlando continuamente e spesso inappropriatamente di cloud computing sia positivamente che negativamente. Ognuno “spara” la propria opinione definendosi esperto di questo o quest’altro.

Come si legge dal titolo siamo ad un nuovo evento “disastroso” per il cloud computing. E sento il dovere di analizzare il caso e rispondere a tutti coloro i quali hanno saputo solo demonizzare il “cloud computing” come se fosse un qualcosa a cui sia possibile puntare il dito contro.

Ricordo ai più che il cloud computing è un paradigma non una tecnologia, ricordo che può essere pubblico e privato, per chi se lo fosse dimenticato o non avesse mai avuto modo di leggersi una definizione ufficiale.

Evento

Veniamo a cosa è successo questa volta, almeno per quello che ne sappiamo.

Una fortissima tempesta si è abbattuta il 30 giugno sugli USA nelle zone della Virginia causando almeno 12 morti, chissà quanti feriti, quanti son rimasti senza casa. Si sà inoltre che in tutta l’area 2 milioni di persone sono rimaste senza corrente per molto tempo, e subito i tecnici si sono mossi per cercare di ripristinare la corrente nel minor tempo possibile, onde evitare che l’ afa record di quell’area potesse aumentare il numero dei morti a causa del non funzionamento dei condizionatori.

In Virginia ci sono dei datacenter di Amazon Web Services, questa è la region storica di AWS, la prima ed anche quella di “default” delle API di management, cioè se il cliente non cambia region userà sempre e solo le risorse di questa area (basta aggiungere –region nel caso della API Tool o fare un set_region se usiamo l’ SDK php o magari più facilmente con la Management Console), mentre AWS è distribuito su tutto il globo (US, EU, ASIA, Giappone, SudAmerica) con molti datacenter.

Uno di questi datacenter ha perso corrente in base a quanto dice Amazon. (perchè AWS rende pubblico lo status di tutti i suoi servizi in tutte le region).

Molti servizi di molti clienti erano però presenti in questa region e si sono trovati offline da un momento all’altro. Il caso ha fatto scalpore perchè questa volta son caduti due grossi portali social molto di moda, Instagram e Pinterest (anche NetFlix), che sono rimasti fuori linea per qualche ora.

Ma mi domando quanti altri datacenter meno noti con hosting old style hanno avuto la stessa sorte?

E’ stato un evento estremo (probabilmente per come si sta mettendo il clima del nostro pianeta, non sarà l’ultimo),

AWS è il primo è più grosso Cloud Provider, il più diffuso, il più usato, quello con maggior presenza di siti e portali di notevole traffico, pertanto ha maggiori probabilità di essere notato in rete da un vasto pubblico, diciamo che è molto sotto occhio.

Il 21 aprile del 2011 la stessa region fu compromessa da un errore umano ed a mio avviso in questo evento risiede il vero problema che le grosse infrastrutture piene di dati in continuo aumento devono affrontare, il 7 agosto invece i datacenter irlandesi di AWS e di Microsoft furono compromessi da una tempesta di fulmini, in questo caso pare che i DC erano forniti degli stessi sistemi di backup automatico dell’energia elettrica, sistema saltato evidentemente per l’extra-tensione del fulmine caduto nelle vicinanze.

Consideriamo i due casi con origine nei problemi atmosferici estremi senza giocare troppo con le simbologie tra le nuvole (clouds) e tempeste (storms), cosi come molti articolisti hanno fatto.

Ci troviamo di fronte a dei datacenter che hanno avuto problemi legati ai sistemi di backup dell’energia e qui una breve descrizione di come funzionano i sistemi di backup dell’energia di un DC è doverosa. Un DC riceve generalmente l’energia elettrica da un provider di energia, questa va direttamente ai gruppi di continuità UPS (praticamente dei gruppi di batterie), poi da qui vanno alle sale server piene di rack dove ci sono gli apparati di network, i server e gli storage.

Una piccola parentesi di GreenIT. Si perde circa il 30% di energia nel passaggio da corrente alternata in continua (UPS) e da continua in alternata verso le sale server, mentre ogni apparato internamente usa riconvertire l’energia elettrica in corrente continua. Questo è un dei vari punti che abbiamo noi sollevato nel nostro progetto Make The Cloud Green.

Ci sono quindi dei sistemi totalmente automatici ed affidabili che intervengono stabilizzando l’energia elettrica verso le sale server, cioè se manca corrente alla fonte gli apparati la prendono dai gruppi UPS. Ovviamente questi sono tarati per reggere il carico pieno poche decine di minuti, pertanto ogni DC che si rispetti è fornito da più di un gruppo di generatori che sempre automaticamente entrano in funzione qualora l’ente energetico non dovesse fornire più energia. Di solito questi gruppi, in generale costituiti da motori a gasolio, ci mettono pochissimi minuti a partire, quindi il funzionamento di un DC dovrebbe essere garantito per molte ore, cioè fino alla fine del carburante.

Un’altra parentesi GreenIT: questo caso di una banca interamente alimentata a fuel cells, cioè off-the-grid

In generale tutte queste apparecchiature, che magari non entrano mai in funzione, richiedono monitoraggio, manutenzione e test di funzionamento periodici che si traducono in simulazioni programmate di eventi catastrofici. Pertanto è un errore parlare di Cloud Computing Outage dobbiamo concentrarci sul fatto che i DC sono stati progettati male, o non è stata fatta la dovuta manutenzione o le dovute simulazioni.

Oppure magari si dovrebbe richiedere ad AWS di rendere pubblici anche i test e gli esiti che vengono fatti a tutti gli apparati di contorno dei DC, o meglio creare nuovi standard, nuove regolamentazioni relative alla costruzione dei DC, renderli energeticamente separati dalla rete, più sicuri rispetto gli eventi atmosferici, ad esempio vediamo questo datacenter costruito a Stoccolma in un ex bunker nucleare. Un’altra parentesi GreenIT sarebbe quella di riscaldare le cittadine adiacenti con il calore emesso dai sistemi piuttosto che sprecare altra energia per raffreddare i sistemi ed altra per riscaldare le abitazioni.(qualcuno lo fà già)

Responsabilità del SW del cliente

Veniamo ora a cosa hanno sottovalutato i clienti che si sono trovati offline. AWS fornisce strumenti di cloud computing di livello IaaS, fornisce molteplici datacenter e fornisce linee guida su come implementare le proprie architetture sottolineando l’uso di più datacenter per le applicazioni Business Critical. Significa che una Instagram che ha ricevuto milioni di dollari di investimento, che non sa progettare la soluzione appoggiandosi a più di un datacenter, è da condannare, non il cloud computing in se, ne AWS per come è stata disegnata l’architettura SW di Instagram.

AWS fornisce una serie di servizi su cui garantisce Fault Tolerance e High Availability e sono S3, SimpleDB, Simple Queue Service, Elastic Load Balancing, Elastic IP e direi anche Route53 e sui quali è possibile costruire i propri servizi High Available, cosi come già hanno fatto molti altri clienti più intelligenti.

Molto disdicevole invece sarebbe vedere un Cloud Provider Pubblico Paas e soprattutto SaaS con problemi di High Availability, come è successo tempo fa per esempio a Gmail di Google.

Per finire gustiamoci ora un elenco dei 10 casi peggiori di Cloud Outage non aggiornati ad ora.

  • Colossal cloud outage No. 1: Amazon Web Services goes poof
  • Colossal cloud outage No. 2: The Sidekick shutdown
  • Colossal cloud outage No. 3: Gmail fail
  • Colossal cloud outage No. 4: Hotmail’s hot mess
  • Colossal cloud outage No. 5: The Intuit double-down
  • Colossal cloud outage No. 6: Microsoft’s BPOS oops
  • Colossal cloud outage No. 7: The Salesforce slipup
  • Colossal cloud outage No. 8: Terremark’s terrible day
  • Colossal cloud outage No. 9: The PayPal fall-down
  • Colossal cloud outage No. 10: Rackspace’s rough year

Ora un piccolo consiglio per stimolare lo standard di costruzione di una nuova generazione di datacenter off the grid. La NASA da mesi se non almeno un paio di anni sta ufficialmente avvisando che sono in continuo aumento le tempeste solari che raggiungeranno l’apice da fine 2012 a tutto il 2013 e che secondo loro potranno mettere a rischio grave le nostre infrastrutture digitali con molti lunghi blackout.