Browsed by
Tag: cloud

Design for failure

Design for failure

Comments 0 Comment

“Scusa ma non siamo capaci di offrirti la stabilità di cui hai bisogno, potresti pensarci tu?”

(Anonimo Cloud-Eretico sul Design for Failure)

C’erano una volta… gli sviluppatori, e le applicazioni. Gli sviluppatori si concentravano sul codice, dando per scontata la stabilità e la scalabilità dell’infrastruttura sottostante: usavano query SQL indescrivibili, ed era compito del sistemista farle girare velocemente, scrivevano codice senza gestione delle eccezioni perchè era compito del sistemista far si che quel determinato database server fosse sempre disponibile e non restituisse mai errori. Scrivevano software impossibile da distribuire su più macchine perchè tanto il sysadmin, in qualche modo, avrebbe fatto.

La colpa di ogni rallentamento o malfunzionamento di chi era? Del sistemista. Questo ha portato chi si occupa di infrastrutture a progettare soluzioni sempre più avanzate per far sopravvivere l’applicativo alle più inimmaginabili catastrofi, senza che questo subisse mai malfunzionamenti. Qualunque disgrazia fosse accaduta alle macchine che la servivano, l’applicazione sarebbe dovuta rimanere in piedi e funzionante.

Va detto che ci siamo (quasi) riusciti. Grazie alla virtualizzazione siamo arrivati a creare quello che è a tutti gli effetti hardware indistruttubile: la macchina fisica è diventata virtuale e quella virtuale sappiamo muoverla tra diversi nodi senza spegnerla, al solo costo di qualche millisecondo di freeze.

Abbiamo così creato piattaforme che astraevano quasi completamente la complessità sottostante, usando processori virtuali che restavano disponibili anche se quelli fisici prendevano fuoco e dischi virtuali che continuavano a servire dati anche se l’intero rack di storage veniva rubato dagli alieni.

Questa soluzione non era però ottimale: la replica sincrona, per esempio, era possibile solo in ristretti contesti geografici. Il costo di queste soluzioni era spesso proibitivo, e la loro complessità alta e non necessaria. Queste strutture, per quanto immortali potessero essere, erano sempre sotto la stessa autorità amministrativa. Tutto per non dare agli sviluppatori un compito in più: gestire la disponibilità dell’applicazione.

Screen Shot 2014-01-28 at 20.58.15

(Anonimo Cloud-Eretico che non ha compreso il ‘Design for Failure’)

Poi è arrivata una nuova generazione di developers: sviluppatori che volevano più controllo, volevano poter decidere come l’applicazione avrebbe reagito a malfunzionamenti dell’infrastruttura, e soprattutto si rifiutavano di pagare al fornitore complessi meccanismi di failover perchè… non ne avevano bisogno. Sapevano fare di meglio e sapevano farlo in modo più economico ma soprattutto più effettivo, più semplice.

Questi sviluppatori non chiedevano più a chi vendeva infrastrutture hardware immortale, chiedevano semplicemente del ferro: di qualunque tipo, prestazioni, forma, colore e dimensione, ed in ogni luogo. Si sarebbero occupati loro di inoltrare meno richieste ai processori meno potenti, di tenere in RAM i dati se i dischi della macchina erano troppo lenti. Si sarebbero curati loro di evitare di interrogare un database server che non rispondeva più ai comandi.

Volevano occuparsi, soprattutto, delle azioni di disaster recovery nel caso in cui un intero datacenter fosse andato a fuoco. Perchè nessuno meglio dello sviluppatore può sapere come deve reagire una applicazione a determinati eventi e di cosa questa ha bisogno.

Hanno poi iniziato a chiamarlo ‘Design for Failure’. La disponibilità non è più compito di chi gestisce l’infrastruttura: è l’applicazione ad esser progettata per far fronte a ogni evento o disgrazia, e la struttura sottostante fa solo il sollevamento pesi.

Nel modello ‘Design for Failure’ ognuno fa il suo lavoro: lo sviluppatore conosce l’applicazione e si occupa di farla funzionare, il gestore dell’infrastruttura si occupa delle prestazioni ma non si infila più in infiniti tunnel senza uscita per garantirne la disponibilità. Tutti risparmiano, perchè è tutto più semplice, con meno sovrapposizioni. Tutti vincono: perde solo chi non ha voglia di innovare.

Ecco perchè questo modello non è un fallimento, come tanti lo descrivono: è il futuro.

Ingegneria del Cloud Computing

Ingegneria del Cloud Computing

Comments 3 comments

Glossy Blue Cloud with ShadowMi auguro di non essere più su questo pianeta il giorno in cui qualcuno istituirà il corso di laurea in Ingegneria del Cloud Computing. Se dovessi ancora essere qui quando quel momento arriverà… ragazzi, sapete cosa fare.

La scorsa settimana ho scoperto che ci sono università che offrono corsi in materia di cloud: per ora si tratta di singoli corsi, i nostri classici 10 CFU. Mi sono documentato, ho cercato i programmi, le slide ed il materiale didattico. Il risultato è stato catastrofico: ho avuto modo di notare quanto il modello di insegnamento “passivo” universitario possa impoverire i concetti. Mi rendo conto che il problema sia il modello in sè (lo confermano persone parecchio più autorevoli di me) e so anche che impoverisce ogni materia, non solo il cloud, ma quest’ultimo mi tocca più da vicino, e penso di avere le competenze per cercare (e trovare, ovviamente) il pelo nell’uovo nonchè il diritto (dovere?) di criticare.

Faccio una premessa (e vi avviso già che me la tirerò non poco). Sono sul campo dal 2006/2007: gli anni in cui venivano lanciate le prime offerte “cloud” (2/3 anni prima del vero e proprio boom). Sono di quelli che l’hanno visto nascere e crescere, di quelli che hanno fatto in tempo a chiedersi “cos’è sta roba?” e che a questa domanda hanno trovato 150 risposte diverse, che hanno visto lanciarsi sul mercato i player che oggi sono i “big” del settore, sono tra quelli che hanno partecipato alle discussioni sullo sviluppo o anche solo sul naming dei vari componenti che lo rendono possibile.

Ho visto scorrere sangue in conseguenza a domande come “Hey, cos’è il cloud?”, date le centinaia di opinioni diverse in merito. Fin dagli albori ho iniziato a intravedere i vantaggi (e le sfide) che questo nuovo modello portava, e ho subito iniziato a lavorarci (forse sarebbe più onesto dire “giocarci”, almeno per quanto riguarda i primi tempi): è stato amore a prima vista. Ci ho dedicato, in un modo o nell’altro, ogni giorno della mia vita professionale fino ad oggi, e continuo a farlo. So come si usa, so come lo si rende possibile, so perchè va usato e quando.

Ecco perchè secondo me con l’università non può funzionare:

  • Nel cloud, in tutte le sue forme (SaaS/PaaS/IaaS) ci sono ancora troppe di discussioni aperte (la definizione stessa non è univoca). C’è parecchia instabilità, su tutti i livelli: com’è possibile insegnarne una singola versione, facendola passare per verità rivelata? Com’è possibile pretendere che qualcuno impari questa “verità rivelata” da un libro, quando se ci si mettesse a studiare su Google (anche se, purtroppo, non sembra pratica comune) emergerebbero milioni di opinioni diverse su ogni singola parola? Stiamo forse nuovamente premiando chi si mette li piegato sul libro e impara tutto a memoria senza mai guardarsi intorno?
  • I professori che tengono questi corsi, a quanto ho visto, non sono esattamente dei giovincelli. Parlo di persone che hanno passato gli ultimi 20/30 anni di vita nella didattica. Questo fa di loro degli ottimi professori, ma forse non ne fa degli ottimi insegnanti per un modello, il cloud computing, che esiste si e no da 6 anni: quante ore possono averci dedicato sul campo? Zero? Forse non sono nemmeno stati in prima linea abbastanza tempo per comprendere come mai è nato, quali sono le richieste che l’hanno fatto crescere, ed in quali ambiti si colloca. Come insegnano, ma soprattutto cosa insegnano? Parlano forse per sentito dire come la peggior pettegola di paese?
  • La volatilità dei concetti è estrema: parlando in generale, e non del singolo servizio dello specifico fornitore, quello che è vero oggi potrebbe non esserlo più domani. La difficoltà nello spiegare cosa sia un’istanza cloud è enorme: chiedetemi piuttosto cos’è un’istanza Amazon EC2, che a differenza della prima è qualcosa di ben definito.

Con questa poca esperienza e con questa miriade di discussioni attualmente in sviluppo, come si può pretendere di valutare con un numero le competenze di uno studente?

Mi spiego con un esempio: 4 anni fa, lo storage a blocchi tra le nuvole era presente in due forme. Quella persistente, affidabile, ultra ridondata ma tremendamente lenta, e quello locale, più veloce ma estremamente instabile e inaffidabile. Era opinione comune che i RDBMS “classici” come MySQL e Oracle non potessero essere spostati nella cloud, perchè avidi di IOPS. Se qualcuno mi avesse chiesto di elencare le differenze tra un VPS ed un Cloud Server avrei sicuramente citato questo punto: 4 anni fa, sarebbe stato parte della definizione.

Poi le cose sono cambiate: è arrivato chi ha messo una SAN ad alte prestazioni dietro agli hypervisor, offrendo storage ridondato ma ad alte prestazioni. Amazon ha lanciato gli EBS con “Provisioned IOPS”, che permettono di prevedere e garantire le prestazioni di un certo storage. Altri player hanno messo sul mercato soluzioni SSD-based sulle quali quasi non ci si accorge di essere in un ambiente virtuale.

Nel giro di pochi mesi, la “lentezza” dei dischi è sparita dalla definizione: non era più parte del cloud. MySQL tra le nuvole è diventato d’un tratto non solo possibile ma anche ottimale. Tutto è cambiato, di nuovo. A che cosa sarebbe servito spendere 10 CFU, 300 ore di studio, per imparare definizioni che erano già predestinate a diventare superate (e quindi, sbagliate)?

Questa è per tutti una grande occasione per buttare via il modello di insegnamento verticale, che evidentemente in questa materia non può funzionare, e per comprendere la dinamicità con cui ci si deve formare in un ambiente lavorativo, in contrasto con quello scolastico.

Lasciate che ad insegnarvi il cloud siano le centinaia di persone che l’hanno fatto, e non dei professori che, mentre tutti noi traslocavamo tra le nuvole, erano in aula a spiegare.

Sysadmin SI NASCE.

Sysadmin SI NASCE.

Comments 5 comments

Esiste un problema. Un problema che nel mio settore si fa ogni giorno più pressante. Si chiama “improvvisazione”. Noi definiamo “improvvisato” quella persona che, dopo aver installato un server seguendo un howto e copiaincollando i comandi senza averli minimamente capiti, si sente, alla pari di ben più skillati sistemisti, pronta a gestire sistemi in produzione. E si lancia a farlo.

devotion_to_duty

I (veri) professionisti si trovano ogni giorno a dover combattere attacchi di vario genere, dallo spam ai DDoS, e nel 99.9% dei casi si scopre che provengono da macchine, appunto, in mano a persone che non hanno praticamente nessuna esperienza nella gestione di sistemi.

Non l’ho raccontato qui per pietà nei confronti degli interessati, ma qualche tempo fa alcuni siti su un server che gestisco, tutti facenti capo alla stessa persona, sono stati defacciati. Dopo una approfondita analisi dei log, ho concluso che chi è entrato via FTP aveva la password (probabilmente recuperata con un keylogger). Avendo trovato IP italiani nei log del deface, ho contattato i proprietari di due di quelle macchine, diventate sicuramente parte di una botnet ed usate da terzi per commettere illeciti. Il primo, dopo una risposta iniziale particolarmente sgarbata, confermando di non essersi accorto del fatto che il suo server veniva usato da terze persone per defacciare siti, ha preso le misure necessarie. Il secondo, no. Mi ha minacciato, dicendo che mi avrebbe denunciato per diffamazione, perchè quello che stavo dicendo era sicuramente inventato, e che se il provider, al cui abuse avevo segnalato la questione, gli avesse bloccato il server, mi avrebbe chiesto i danni. Perchè io mi stavo inventando tutto.

Inutile dirlo, dopo avergli spiegato come connettersi via SSH e come lanciare il comando “last”, sono venuti fuori login (root) da ogni parte del mondo sulla sua macchina. Login di cui lui, ovviamente, non sapeva niente.

Non sapeva bene cosa fosse SSH, ma il server lo aveva installato. I servizi erano up, il sito web era correttamente funzionante. Perchè, questo? Perchè siamo nel 2013. Perchè esistono pannelli di controllo e howto. Pannelli di controllo come Plesk e cPanel, che svolgono egregiamente tutte le operazioni di configurazione iniziale e di gestione ordinaria di una macchina. Questo è il punto. Il sistemista improvvisato, non fa niente che già non si possa fare con dei semplici click in un pannello di controllo. Non fa niente che non si possa fare cercando una guida su internet e copiaincollando i comandi indicati.

Considero infatti gli howto alla pari dei pannelli di controllo “tuttofare”. Guide passo a passo, che portano anche la persona più incapace a configurare un determinato servizio. I sistemisti improvvisati esistono perchè esistono le guide step by step, e queste guide esistono perchè vendono, perchè fanno views, e le fanno perchè esistono gli improvvisati. Il nocciolo della questione è che la guida spiega come installare qualcosa e come effettuare configurazioni basilari. Ma non spiega come gestire. Non spiega come affrontare i casi eccezionali. Perchè questo, forse, non può essere insegnato.

Chi usa una guida pronta, delega a terzi (cioè a chi quella guida l’ha scritta) tutta la fase preliminare di ricerca, di documentazione e di assemblaggio di diverse fonti, nonchè il testing. Si tratta invece di una componente fondamentale del nostro lavoro. Perchè è così che impariamo a muoverci senza usare guide, è questo il modo in cui impariamo ad affrontare situazioni non ordinarie. È così, e solo così, che impariamo a camminare (anzi, a correre) nel buio.

Partiamo dal presupposto che tutto quello che può essere spiegato in termini semplici ed in modo sequenziale a degli incapaci, può anche essere eseguito da una macchina. Anni e anni di howto su come installare un ambiente LAMP. Poi arriva cPanel. Si inventa EasyApache. E da quel momento con un comando si può fare in 3 secondi tutto quello che con la guida si faceva in 3 ore. A copiare righe di codice, sono capaci tutti. Le macchine sono bravissime ad eseguire comandi in sequenza prestabilita. Sono le migliori: le abbiamo inventate inventate noi, e le abbiamo inventate per fare proprio questo.

Se ne deduce che una persona che gestisca macchine in questo modo, non ha senso di esistere. Se l’amministrazione di un sistema consistesse solo in queste semplici e sequenziali operazioni, le macchine stesse saprebbero autogestirsi. Anzi, lo fanno già: ci sono strutture che svolgono il 90% delle operazioni di routine senza supervisione umana.

Ma gestire server è molto, molto altro. Le situazioni ordinarie durano ben poco, e ci si trova spessissimo a dover gestire casistiche eccezionali, a dover svolgere operazioni impossibili da eseguire attraverso un pannello di controllo. A dover svolgere operazioni per le quali non si trova da nessuna parte una guida pronta all’uso, perchè magari prima di noi nessuno si è trovato incastrato nella situazione in cui noi invece ci troviamo. Interventi per cui serve una mente umana, un cervello. Un cervello che funzioni, non un cervello che sappia solo usare i comandi cut&paste.

Si, è vero, molte operazioni sono state automatizzate negli ultimi anni, prima le svolgeva un uomo e adesso le svolge una macchina. Ma, state attenti: sono stati automatizzati quei processi che già il sistemista svolgeva in modo “automatico”, comportandosi come una macchina. Solo quelli: tutto il resto non potrà mai essere automatizzato. Forse si, un giorno succederà. Ma non a breve/medio termine.

Alcuni sostengono che stia proprio in questo l’abilità innata dei sysadmin. Saper affrontare situazioni, saper gestire casistiche eccezionali, saper gestire (e risolvere) i problemi. Saper cercare soluzioni, conoscere e saper usare gli strumenti a disposizione. Avere la tendenza che ti porta ogni giorno, senza nessuna spinta, a trovare nuovi strumenti e a scoprire nuove cose. Le capacità tecniche si possono acquisire, il resto no: si imparano i comandi da utilizzare, ma non si impara il modo in cui affrontare le situazioni critiche. Ed è questo che conta, è questo a fare la differenza.

Spesso, infatti, quando consiglio ad un improvvisato di cambiare professione, non lo faccio perchè abbia dimostrato di non conoscere semplici comandi o di non sapere il significato di alcuni termini tecnici, ma perchè noto la mancanza di abilità e tendenze ben più importanti. A volte vengo ricoperto di domande, domande la cui risposta è contenuta nell’anteprima del primo risultato di ricerca su Google. Questo, a mio parere, è un chiaro segno. Se l’istinto ti porta a chiedere a qualcuno che già sa piuttosto che a cercare da solo una risposta, sarai un perfetto studente, un perfetto schiavo del metodo educativo moderno. Ma, tranquillo, non farai mai il sistemista. Non giriamoci intorno. È così.

C’è chi nasce particolarmente portato al gioco di squadra e fisicamente agile, e diventa calciatore. Ci sono ragazze che nascono particolarmente belle, fini e portate alla cura della persona, e diventano modelle. Non si capisce perchè si sia invece diffusa la convinzione che chiunque possa diventare sistemista. Non si capisce come mai chiunque voglia diventarlo, e come mai sia così difficile difendere la professionalità in un mestiere che sta diventando sempre più critico e importante.

Non vorreste mai volare su un aereo pilotato da una persona con in mano una guida step by step. Non vi fareste mai trapiantare il cuore da qualcuno che, forte di 20 anni di esperienza in macelleria e con l’aiuto di un video su Youtube, vi garantisce di saperlo fare. Perchè, per risparmiare qualche euro, date in mano i vostri siti, i vostri gestionali e i vostri strumenti di comunicazione a persone che non fanno niente di più di quanto già le macchine stesse non facciano?

E tu. Si, tu, sistemista improvvisato che stai leggendo. Fai un favore a tutti noi: lascia che le tue 40 ore di lavoro settimanali diventino 2 ore di un vero professionista, anche se queste sue due ore costeranno al cliente come le tue 40. Sarà meglio per tutti.

Per oggi ho finito.

Giorgio

Anche i più grandi tra i grandi…

Anche i più grandi tra i grandi…

Comments 2 comments

…eh si, volano giù

Sono un Google-Lover. Da quando esiste, ho spostato tutte le mie applicazioni su Google App Engine. Non mi dilungo nei dettagli, ma la struttura fa impressione: scala senza il minimo problema, sia per quanto riguarda la parte web che la parte db/storage, e non ha i limite che ha Amazon AWS. Ho fatto diversi test sul servizio, se a qualcuno interessano potrei pubblicare un post descrivendone i risultati.

Torniamo al down: il 24 Febbraio stavo lavorando ad una mia applicazione basata su GAE, quando, intorno alle 17.00, tutte le richieste hanno iniziato a finire in timeout. Appena il tempo di realizzare (ho impiegato 30 minuti per convincermi che il servizio era veramente down) e il mio aggregatore mi segnala un nuovo post nel gruppo GAE Downtime Notify di Google in cui vengono pubblicate informazioni sui down previsti e su quelli un pò meno previsti. Sono circa le 17.30.

Il suo contenuto è:

Since 7:53am PST, App Engine has been experiencing an unexpected outage affecting the majority of App Engine applications.  The team is working quickly to correct the cause and will have an ETA on the fix shortly.

Please watch this thread for updates. We sincerely apologies for the inconvenience.

Il servizio rimane KO, e alle 18.30 circa ricevo un confortante aggiornamento:

We are still actively working on the on-going outage.  We’ve also experienced a problem with our backup datacenter. We will continue to provide status updates on this thread every thirty minutes.

Il messaggio mi informa che stanno lavorando al problema, ma che ci sono altri problemi con il datacenter secondario (su cui, probabilmente, avevano pianificato di swappare il traffico in caso di failure del primario).

Dopo altri 20 minuti, alle 18.50 (o qualcosa di simile) la mia applicazione riprende a rispondere, ma segnala che il DataStore è in read-only. Un nuovo post conferma quanto ho appena notato:

As of 9:48am, all applications should now be available in read-only mode.

Aspetto altri 20 minuti e tutto torna a funzionare normalmente, anche se in modo estremamente lento. Probabilmente -penso- sono partiti tutti i processi cron schedulati durante il down.

Arriva un nuovo update:

As of 10:09am, all application should be serving traffic and successfully reading/writing from the datastore.  Again, apologies for the inconvenience of the outage.  We will follow up with a post-mortem.

Per me si chiude qui, nel senso che dalle 19.30 più o meno, lentezza a parte, riprende a funzionare tutto. Per altri utenti no, Google infatti parla di problemi ancora presenti su “a small percentage of datastore entity groups”. Più tardi, in una rettifica, parleranno di problemi di inconsistenza del DataStore per circa 25 applicazioni.

La sera del 25 Febbraio (il giorno dopo) Google pubblica un aggiornamento:

We continue to work diligently in the wake of yesterday’s unforeseen App Engine outage on a number of issues, so we wanted to provide you an update with our current list of tasks.

– Applications will not be charged for any App Engine resource usage that occurred during Feb 24th, 2010.

– We are still working on fix for writes and transactional reads affecting a small number of datastore entity groups.  We have determined that approximately 25 application IDs have been affected by this issue.  If you feel you are having difficulties with certain entity groups in your application, please respond to this thread with your App ID.

– We are working hard on putting together a detailed post mortem that we will be making public.  We expect to have this available to you next week.

Again we sincerely apologize for yesterday’s service disruption.  We take App Engine’s reliability very seriously and we are confident we can use the hard lessons learned from yesterday’s event to improve our offering to you.

Attendo il post-mortem fino al 5 Marzo, quando, finalmente, ricevo la tanto attesa mail. Inizia con un riepilogo sul downtime:

On February 24th, 2010, all Googe App Engine applications were in varying degraded states of operation for a period of two hours and twenty minutes from 7:48 AM to 10:09 AM PT | 15:48 to 18:09 GMT.

The underlying cause of the outage was a power failure in our primary datacenter. While the Google App Engine infrastructure is designed to quickly recover from these sort of failures, this type of rare problem, combined with internal procedural issues  extended the time required to restore the service.

Parla di “internal procedural issues”, “problemi nelle procedure interne” meglio descritti poco sotto:

– Although we had procedures ready for this sort of outage, the oncall staff was unfamiliar with them and had not trained sufficiently with the specific recovery procedure for this type of failure.

– Recent work to migrate the datastore for better multihoming changed and improved the procedure for handling these failures significantly. However, some documentation detailing the procedure to support the datastore during failover incorrectly referred to the old configuration. This led to confusion during the event.

– The production team had not agreed on a policy that clearly indicates when, and in what situations, our oncall staff should take aggressive user-facing actions, such as an unscheduled failover.  This led to a bad call of returning to a partially working datacenter.

– We failed to plan for the case of a power outage that might affect some, but not all, of our machines in a datacenter (in this case, about 25%). In particular, this led to incorrect analysis of the serving state of the failed datacenter and when it might recover.

In breve (ed in italiano): lo staff oncall non era pronto a far fronte a questo tipo di problemi. La documentazione di supporto, si riferiva ad una versione obsoleta del sistema (e probabilmente totalmente incompatibile, perchè è stato recentemente aggiornato il sistema di replicazione del DS), e i tecnici che avrebbero dovuto iniziare il failover si sono trovati davanti a due procedure contrastanti senza sapere quale utilizzare.

I sistemi di controllo interni hanno poi segnalato come utilizzabile un datacenter che non lo era, poichè non erano studiati per considerare una perdita di alimentazione parziale e non totale. Lo staff, infine, dopo aver tentato, con esito negativo, di spostare il traffico in read-only sul datacenter secondario, ha deciso di girare di nuovo il tutto sul primario, credendo, erroneamente, che stesse tornando online.

Dalla cronologia, riportata in calce al post mortem,  scopro in dettaglio cosa è successo durante le due ore di down (riporto gli orari originali, tenete conto che noi siamo avanti di 9 ore):

Alle 7.48 si iniziano a riscontrare errori nel traffico servito dal DC primario. Alle 7.53 i “Google Site Reliabilty Engineers” segnalano che nel DC c’è stata una perdita di alimentazione, e che a causa di un problema con l’alimentazione secondaria circa il 25 % dei server sono in crash.

Alle 8.01 viene confermato che GAE è down. Viene deciso di darne comunicazione ufficiale agli utenti. Alle 8.22 viene confermato che diverse macchine non sono ripartite, e che il cluster GFS e BigTable non sono funzionanti a causa dell’alto numero di server persi. Si decide di avviare la procedura di failover verso il DC secondario.

Alle 8.40 viene scoperto un conflitto nella documentazione sulle procedure di failover. Non potendo decidere quale fosse la procedura da utilizzare, gli ingegneri decidono di contattare la persona responsabile del cambio di procedura. Alle 8.44, mentre una parte dello staff sta ancora lavorando alla procedura di failover, si tenta di servire il traffico in sola lettura dal DC primario. Un problema nella configurazione, però, impedisce al DC secondario di servire il traffico.

Alle 9.08, mentre parte dello staff sta tentando di risolvere il problema di configurazione nel DC secondario che impedisce di servire le richieste e un’altra parte sta ancora lavorando alla procedura di failover, il “Primary OnCall Engineer” ritenendo che il DC primario fosse tornato completamente operativo e pronto a servire tutte le richieste, avendo in mano dati dei sistemi di diagnosi che confermavano ciò, senza sapere però che non era mai usccesso prima che un DC dopo un danno simile tornasse utilizzabile, devia nuovamente il traffico su quest’ultimo, nel tentativo di far tornare online il servizio.

Alle 9.18 si rendono conto che il DC primario non è tornato online, e che non può servire il traffico. Si concentrano quindi gli sforzi sul DC secondario, si devia nuovamente lì tutto il traffico e si inizia la procedura di failover.

Alle 9.35 viene raggiunto un ingegnere con esperienza nella procedura e si inizia il failover. Alle 9.48 il DC secondario inizia a servire le richieste in read-only.

Alle 9.53 viene confermata la corretta procedura di failover per il read-write, e si avvia il processo.

Alle 10.09 il processo termina, ed il traffico riprende ad essere servito normalmente. Google App Engine da questo momento è considerato online.

Il post-mortem contiene anche una serie di correzioni che Google intende attuare per evitare il ripetersi di casi simili:

As a result, we have instituted the following procedures going forward:

– Introduce regular drills by all oncall staff of all of our production procedures. This will include the rare and complicated procedures, and all members of the team will be required to complete the drills before joining the oncall rotation.

– Implement a regular bi-monthly audit of our operations docs to ensure that all needed procedures are properly findable, and all out-of-date docs are properly marked “Deprecated.”

– Establish a clear policy framework to assist oncall staff to quickly and decisively make decisions about taking intrusive, user-facing actions during failures. This will allow them to act confidently and without delay in emergency situations.

We believe that with these new procedures in place, last week’s outage would have been reduced in impact from about 2 hours of total unavailability to about 10 to 20 minutes of partial unavailability.

In response to this outage, we have also decided to make a major infrastructural change in App Engine. Currently, App Engine provides a one-size-fits-all Datastore, that provides low write latency combined with strong consistency, in exchange for lower availability in situations of unexpected failure in one of our serving datacenters. In response to this outage, and feedback from our users, we have begun work on providing two different Datastore configurations:

– The current option of low-latency, strong consistency, and lower availability during unexpected failures (like a power outage)

– A new option for higher availability using synchronous replication for reads and writes, at the cost of significantly higher latency

We believe that providing both of these options to you, our users, will allow you to make your own informed decisions about the tradeoffs you want to make in running your applications.

Termina con delle scuse:

We sincerely apologize for the impact of Feb 24th’s service disruption on your applications. We take great pride in the reliability that App Engine offers, but we also recognize that we can do more to improve it. You can be confident that we will continue to work diligently to improve the service and ensure the impact of low level outages like this have the least possible affect on our customers.

Un down, prima o poi capita a tutti. Per quanto mi riguarda, rinnovo la mia fiducia nella grande G.

Giorgio

Quanto tempo resta agli ambienti monolitici?

Quanto tempo resta agli ambienti monolitici?

Comments 0 Comment

lamp

Come dicevo, negli ultimi mesi ho dedicato moltissimo tempo allo studio delle infrastrutture che stanno dietro ai servizi cosiddetti “Cloud” più utilizzati al giorno d’oggi (Google, Youtube, Facebook, Amazon, Linkedin, Azure etc).

Il motivo è semplice: gli ambienti LAMP usati fino ad ora (e qui mi riferisco alle classiche strutture utilizzate dalla maggior parte degli hosting provider, un server con su installato mysql, apache, php), non coprono le più basilari necessità di un sito web. Stiamo parlando, sia chiaro, di un sito qualunque, quale può essere il mio blog.

Mi spiego meglio: fino a qualche anno fa (ma, oserei dire, qualche mese fa, perchè, alla fine, l’esplosione di questo cloud computing è stata tutta questa estate), era assolutamente normale, quando il pacchetto hosting non bastava più (spazio esaurito, costanti abusi di cpu), acquistarne uno più grande, scaricare files e db dal vecchio spazio, spostarli sul nuovo e riconfigurare il tutto (io stesso lo ho fatto più volte con il mio blog: partito da tophost, passato a netsons, poi a eticoweb openhost e poi ad un piano personalizzato eticoweb).

Ma, riflettendoci, che senso ha? Perchè stressarsi con questo lavoro quando con un account Blogger/WordPress ho un sito esattamente uguale a questo in grado di reggere praticamente qualunque carico di lavoro? Stessa cosa dicasi per i server dedicati. Quando il mio dedicatino non regge più ne prendo uno nuovo più potente e ci sposto tutto. Anche qui, c’è un senso? Perchè comprare un piccolo dedicato quando con una VPS (mi riferisco a RackSpace CloudServers, Amazon EC2 e GoGrid) ho lo stesso servizio, scalabilità immediata e semplice, ridondanza ed in più i vantaggi di un ambiente “burstable”?

Altro problema ricorrente è l’uptime. Leggevo tempo fa “The Big Switch” di Nicholas Carr. Fa un interessante paragone tra gli anni 70, in cui, se cadeva il server aziendale, si chiamava IBM che lo ritirava su in 3/4 giorni, gli anni 80/90 in cui c’è stata la corsa all’offerta del servizio di supporto onsite più efficiente (il down di un server con un gestionale iniziava ad essere un serio problema, avendo completamente sostituito gli archivi cartacei), e oggi, dove si è capito che l’erogazione del servizio semplicemente NON PUO’ più interrompersi (basti pensare allo scompiglio creato dal down di 12 minuti di GMail di qualche mese fa).

Il servizio, è ovviamente erogato da servers. L’ultimo passaggio è quindi immediato: ogni singolo componente dell’infrastruttura, per quanto ridondato possa essere, può fermarsi. Servono quindi strutture che sappiano utilizzare gruppi (pool) di macchine, e che possano gestire il down di uno o più componenti in modo totalmente trasparente all’utente finale, l’utlizzatore del servizio. La struttura deve essere in grado di gestire la caduta di un singolo server, rack, sala o datacenter, come se fosse una cosa di routine che può accadere tutti i giorni.

E qui abbiamo una ulteriore divisione: per grandi servizi come Google, per cui adattare gli strumenti esistenti sarebbe complicato se non impossibile, sono state create strutture proprietarie, perfettamente ottimizzate, volte a svolgere precisi compiti. In altre parole, “su misura”.

C’è poi chi sta lavorando per “accogliere” gli utenti che vengono dagli ambienti che ho definito mono-server, che sta quindi lavorando per creare piattaforme che pur essendo basate su quello che compone i sistemi LAMP (banalmente, Linux, Apache, MySQL e PHP), godano di caratteristiche che a questi mancavano, come, ancora una volta, scalabilità e ridondanza (io resto comunque abbastanza convinto che tuttora ci siano limiti sopra i quali non si può andare. non ho infatti trovato uno di questi servizi “cloud hosting” in cui mysql scali a dovere).

Quindi, concludendo, mi chiedo: per quanti anni ancora vedremo siti ospitati su server singoli senza alcun tipo di fail-over? Questi vecchi ambienti, alla luce di queste considerazioni, sono davvero così terribili? Strutture come RackSpace CloudSites e Seeweb Cloud Hosting, prenderanno piede così velocemente?