Solo un veloce aggiornamento sulla vicenda (di cui ho parlato dettagliatamente qui). L’idea di Class-Action contro Aruba da parte del Codacons ha riscosso molto meno successo di quanto pensassi. Immaginavo centinaia di commenti in pochi giorni sul blog dell’Avv. Rienzi (sul quale è stato formalmente richiesto dal Codacons di rilasciare una pre-adesione), invece dopo 5 giorni questi sono appena una sessantina, di cui almeno la metà sono contro l’azione di gruppo nei confronti del colosso dell’hosting o di persone che come me tentano di spiegare, a tempo perso, la situazione.

Così tanto FLOP che da ieri ho iniziato a taggare i miei tweet riguardo la vicenda con il tag #FLOP oltre che #Aruba e #Codacons.

Segnalo l’articolo di Antonio Angelino, che riprende in parte i miei punti del precedente post ed estende il discorso. Per chi fosse interessato ad approfondire un minimo il discorso tecnico o a leggere pareri di professionisti come me, segnalo questo thread su HostingTalk.it.

Sto anche continuando a leggere (e a rispondere) divertito ai commenti dei vari utenti che si lamentano delle perdite milionarie subite a causa del down di 12 ore si un hosting lowcost da 30 € annuali che non offre garanzie da contratto. Inutile commentarli o rispondere a uno a uno, ma nell’insieme emergono alcuni punti interessanti. Non intendo trattarli nel dettaglio (anche perchè un professionista del settore o presunto tale -questo dovrebbe essere il mio target, considerato che non so scrivere in modo umano- dovrebbe capire senza troppe spiegazioni), ma solo elencarli:

• Nessuno dei clienti che intendono proseguire nell’azione contro Aruba ha letto il contratto prima di sottoscriverlo. Appare ovvio, perchè al suo interno è esplicitamente contemplata la possibilità di danni per incendio e l’impossibilità di offrire rimborsi ai clienti. Più in generale non ci si rende conto che al momento della firma di un contratto per un servizio lowcost, la sostanza dell’accordo tra Provider e Cliente è “Ok Cliente, io ti do un servizio che costa la metà, ma sappi che per abbassare il prezzo devo togliere garanzie, va bene?”.
• C’è una scarsissima conoscenza del mercato. Anche una nocciolina (fatta eccezione per qualche mia amica l’arachide è la cosa più stupida che conosca), vedendo che esistono pacchetti di hosting da 10 €, da 40 €, da 250 € e da 1500, tenterebbe di informarsi e di capirne le differenze, arrivando così in ben poco tempo a parlare di uptime, garanzie, penali etc.
• C’è anche una conoscenza tecnica pari a zero. E’ comprensibile ovviamente, ma quello che non è comprensibile è la pari presunzione di esprimere pareri a riguardo. Ci sono persone che parlano di “server di emergenza” senza sapere minimamente cosa significhino la parola failover o la parola sincronizzazione, altri che parlando di “misure di emergenza” che Aruba AVREBBE DOVUTO mettere in atto senza riuscire minimamente a spiegare di cosa si stia parlando.
• Si nota anche un certo livello di illogicità: c’è chi fatica a capire che anche se ha acquistato 20 pacchetti da 40 €, questi rimangono 20 pacchetti lowcost, o chi tira fuori la solita storia del mancato pagamento del rinnovo causa imprevisto dell’ultimo momento (si, esatto, quello li, quello che ti impedisce di pagare al sessantesimo giorno il dominio, senza che si capisca bene cosa hai fatto per i 59 giorni precedenti).
• AGGIUNTA: Me l’ero dimenticata ma è di importanza fondamentale. Certi utenti hanno un’idea di “pagamento rateale” abbastanza alterata. Il ragionamento, in sostanza è: “sono dieci anni che pago 30 euro, quindi dovrebbero aggiungere ridondanza”. Bene, svelerò un segreto: no, non funziona così. Pagare 30 euro annuali per 10 anni non obbliga l’azienda ad offrire un servizio da 300 euro annuali.

E molto, molto altro. #FLOP

Giorgio

PS: Non so quale sia la fonte dell’immagine di Aruba in fiamme. Io l’ho presa QUI.

Ieri, Venerdì 29 Aprile 2011, alle 4 di mattina un corto circuito nella sala batterie del sistema UPS della WebFarm di Arezzo del gruppo Aruba ha causato uno spegnimento di tutta la struttura, portando offline i milioni di siti ospitati, caselle email, server dedicati etc. Ne hanno parlato testate autorevoli, come il TGCOM, il Quotidiano Nazionale o il Giornale.

Alle 10.30 è iniziata la rimessa in tensione delle sale. In qualche ora tutti i server erano nuovamente alimentati e i servizi iniziavano a tornare online (discorso diverso chiaramente per le macchine con filesystem corrotti a causa dello spegnimento improvviso). In serata, poi, è arrivato il Comunicato Stampa.

Il Comunicato spiega che si è attivato normalmente il sistema antincendio della sala UPS, ma che poi il fumo, diffuso in tutta la struttura, ha fatto scattare anche quello delle sale dati che ha causato l’interruzione di corrente. Sembra quindi che dopo il corto circuito relativo agli UPS sia entrato in funzione senza problemi il sistema di bypass di questi ultimi e le sale dati siano rimaste alimentate, salvo poi essere “spente” per un “errore” del sistema antincendio. Ma la questione è di poca importanza, perchè comunque i Vigili del Fuoco avrebbero chiesto di staccare l’interruttore generale prima di intervenire.

La cosa veramente interessante (cioè, ridicola) in tutta la vicenda è la Class-Action (cos’è?) che il Codacons ha promesso nei confronti di Aruba, per i disagi causati ai clienti durante il downtime. Da leggere assolutamente i commenti sul blog dell’Avv. Rienzi di chi non si rende conto che nessuno ha in mano coltelli, ma c’è un contratto, firmato, di chi ha una mail fondamentale per il suo lavoro ma la mette su un lowcost, di chi ha un sito fondamentale tramite il quale fa un immenso fatturato ma decide di ospitarlo su un pacchetto lowcost senza garanzie etc etc.

Mi fanno piacere i commenti di chi ha si scelto di ospitare un E-Commerce (anzi, 30) su sistema lowcost, ma sapeva a cosa andava incontro, sapeva cosa stava comprando e ha agito di conseguenza. Sono molti anche quelli che insultano il Codacons contro la class-action, da notare chi assume un atteggiamento “pan per focaccia” nei confronti dell’avvocato e del suo blog. C’è poi chi come al solito incolpa l’Italia, e confonde il bollino dorato “Uptime Garantito” con una garanzia da contratto e non si rende conto che per quel prezzo è semplicemente IMPOSSIBILE offrire garanzie. Ovviamente ci sono anche il MIO commento e quello dello (stimato) ex-collega Domenico De Monte.

Il punto focale è che il contratto firmato dai clienti spiega chiaramente che non sono fornite garanzie in termini di uptime, e che il prodotto offerto è soggetto a questo tipo di problemi. Il pacchetto di hosting è quindi qualcosa di “best effort”, ovvero “il meglio possibile”, in parole povere Aruba promette di offrire al cliente un buon servizio (ovviamente non può essere down 24ore al giorno), ma senza offrire garanzie in caso di problemi. Il cliente deve quindi saper valutare, decidere se il rischio di downtime per lui è accettabile.

Se lo ritiene accettabile, utilizza un servizio risparmiando non pochi euro (per soluzioni con delle garanze di uptime si parlerebbe di prezzi intorno alle migliaia di euro annuali), ma accetta di non richiedere risarcimenti in caso di downtime. Se non lo ritiene accettabile, ovvero crede che il rischio sia troppo alto e che l’eventuale perdita sarebbe troppo grossa, deve guardare da altre parti e tirare fuori il libretto degli assegni.

Una class-action che costringa il provider a risarcire i clienti quando da contratto negava questa possibilità, nata da clienti insoddisfatti di un servizio che hanno semplicemente sbagliato a comprare, sarebbe distruttiva per il settore: si costringerebbero le aziende ad offrire risarcimenti in situazioni economicamente impossibili. Il che può portare ad una sola cosa: la fine del lowcost. Essendo costretti a fornire risarcimenti in caso di problemi, i provider deciderebbero di offrire solo servizi all’altezza di una simile prospettiva, al fine di evitare inutili perdite.

Insomma, se volete sottoscrivere questa class-action, fatelo ma ricordate:

1. Chi ha subito danni li ha subiti in quanto non ha letto il contratto e ha acquistato un servizio inadatto alle sue esigenze
2. No, non avete perso email. Il protocollo SMTP è studiato per far fronte a queste situazioni
3. Una azione simile, se vinta dai consumatori, creerebbe conseguenze catastrofiche sul mercato
4. Eventi simili sono rarissimi, si fa prima a cancellare e ripartire

Vi terrò aggiornati.

Giorgio

Return-Path: <donotreply@akismet.com>
X-Original-To: giorgio@FAKEDOMAIN.COM
received: from mx2.runhosting.com (mx2.runhosting.com [82.197.130.202])by mbox2.runhosting.com (Postfix) with ESMTP id 4B1F3607F34Efor <giorgio@FAKEDOMAIN.COM>; Sat, 22 Jan 2011 16:03:26 +0000 (UTC)
received: from mx2.runhosting.com (in2.defender.mail [82.197.130.203])by mx2.runhosting.com (Postfix) with ESMTP id B26D850600for <giorgio@FAKEDOMAIN.COM>; Sun, 23 Jan 2011 00:07:07 +0000 (UTC)
received: by mx2.runhosting.com (Postfix, from userid 65534)id A426C50615; Sun, 23 Jan 2011 00:07:07 +0000 (UTC)
received: from mail2.runhosting.com (mail2.runhosting.com [82.197.130.204])by mx2.runhosting.com (Postfix) with ESMTP id 6390C50600for <giorgio@FAKEDOMAIN.COM>; Sun, 23 Jan 2011 00:07:06 +0000 (UTC)
received: from mail2.runhosting.com (unknown [82.197.130.206])by mail2.runhosting.com (Postfix) with ESMTP id 965413EADCfor <giorgio@FAKEDOMAIN.COM>; Sun, 23 Jan 2011 00:07:06 +0000 (UTC)
received: by mail2.runhosting.com (Postfix, from userid 65534)id 7D3163F708; Sun, 23 Jan 2011 00:07:06 +0000 (UTC)
received: from mbox2.runhosting.com (mbox2.runhosting.com [82.197.130.207])(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))(No client certificate requested)by mail2.runhosting.com (Postfix) with ESMTPS id 088E63EADCfor <giorgio@FAKEDOMAIN.COM>; Sun, 23 Jan 2011 00:07:05 +0000 (UTC)
received: from mx2.runhosting.com (mx2.runhosting.com [82.197.130.202])by mbox2.runhosting.com (Postfix) with ESMTP id 8F221607F34Efor <admin@FAKEDOMAIN.COM>; Sat, 22 Jan 2011 16:02:54 +0000 (UTC)
received: from mx2.runhosting.com (in2.defender.mail [82.197.130.203])by mx2.runhosting.com (Postfix) with ESMTP id 14FC850600for <admin@FAKEDOMAIN.COM>; Sun, 23 Jan 2011 00:06:36 +0000 (UTC)
received: by mx2.runhosting.com (Postfix, from userid 65534)id F17CC50615; Sun, 23 Jan 2011 00:06:35 +0000 (UTC)
received: from smtp1.sat.wordpress.com (smtp1.sat.wordpress.com [76.74.254.15])by mx2.runhosting.com (Postfix) with ESMTP id 192E950600for <admin@FAKEDOMAIN.COM>; Sun, 23 Jan 2011 00:06:33 +0000 (UTC)
received: from smtp1.sat.wordpress.com (localhost.localdomain [127.0.0.1])by smtp1.sat.wordpress.com (Postfix) with ESMTP id 02EC4241C198for <admin@FAKEDOMAIN.COM>; Sat, 22 Jan 2011 16:02:57 +0000 (UTC)
received: from _ (c6.sat.akismet.com [66.135.58.48])by smtp1.sat.wordpress.com (Postfix) with ESMTP id E7883241C18Afor <admin@FAKEDOMAIN.COM>; Sat, 22 Jan 2011 16:02:56 +0000 (UTC)
X-Spam-Score: -2.0
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on in2.defender.mail
X-Spam-Level:
X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL autolearn=disabledversion=3.2.5
Dkim-Signature: v=1; a=rsa-sha1; c=relaxed; d=akismet.com; h=date:to:from:subject:message-id:reply-to:mime-version:content-transfer-encoding:content-type; s=my3; bh=CC4iVqFNhHYEprW6wy8MS/KCPqo=; b=l28OC3lmyUmdoLIK+8ts7rfM9RV81WUySnA3O6aDa55rCS00aSTV8Cp70ziz0e6mrbOuoRwPPanQC77Xm/agtA==
Domainkey-Signature: a=rsa-sha1; c=nofws; d=akismet.com; h=date:to:from:subject:message-id:reply-to:mime-version:content-transfer-encoding:content-type; q=dns; s=my3; b=weli02Y9jlA0+tE5g8DpzJAwO+PFYAPGqC4iAOw7AYXthPs3m2Rx//oJ2iN2kkL6/Ixa1Ba9raPhtNxoNlqYtg==
Date: Sat, 22 Jan 2011 16:02:56 +0000
To: admin@FAKEDOMAIN.COM
From: Akismet Support <support@akismet.com>
Subject: Your new Akismet API key
Message-Id: <2c88cc629485167f7c160c4737027367@_>
X-Priority: 3
X-Mailer: PHPMailer (phpmailer.sourceforge.net) [version 2.0.4]
Reply-To: support@akismet.com
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=”UTF-8″
x-virus-scanned: ClamAV using ClamSMTP (in2.defender.mail(82.197.130.203), client: 82.197.130.202)
x-virus-scanned: ClamAV using ClamSMTP (out2.defender.mail(82.197.130.206), client: 82.197.130.204)
x-virus-scanned: ClamAV using ClamSMTP (in2.defender.mail(82.197.130.203), client: 82.197.130.202)

E’ spaventoso. C’è un forwarding che per qualche motivo a me sconosciuto non viene effettuato in locale pur essendo parte dello stesso dominio (probabilmente un doppio check antispam sulle mail in uscita). Si notano poi continui rimbalzi altrettanto inspiegabili (le mail tornano ad un certo nodo dopo che le ha buttate fuori lui stesso).

Chiederò spiegazioni al supporto.

UPDATE: @cxunix ha definito il fenomeno come “Il giro della posta in 80 MX”. Ci facciamo un film?

Le autorità rassicurano, considerata la differente tipologia del reattore e le differenti misure di sicurezza, è impossibile il ripetersi di un incidente simile a quello di Chernobyl del 1986.

Comunque, lascio il lavoro da reporter alla BBC che ne sa sicuramente più di me e torno al mio. Guardate l’immagine qui sotto:

Si tratta di uno screenshot della pagina in cui è riassunto lo stato di tutti i servizi Amazon AWS di tutte le regioni. Come potete notare, durante e dopo il sisma la struttura Amazon di Tokyo non ha subito nessun downtime nè nessun rallentamento. Quando dico che mi fido ciecamente del Cloud computing.

Sono curioso, voglio vedere se Amazon rilascerà un comunicato ufficiale sull’accaduto.

L’ultimo pensiero va, ovviamente, alle vittime del sisma e alle decine di migliaia di persone che hanno perso tutto.

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

…volano giù.

WordPress.com e i 10 milioni di blog che ospita in 3 datacenter su un migliaio di servers HP, down per 110 minuti il 19 Febbraio 2010. Il peggiore down di sempre per il secondo servizio di blogging mondiale (online dal 21 Novembre 2005).

La descrizione delle cause dell’accaduto non è proprio precisa e completa, ma il down è stato dovuto, stando al post pubblicato sul blog ufficiale del servizio, pubblicato qualche ora dopo l’accaduto, ad un problema di configurazione “hardware”: un cavo collegato nel posto sbagliato, che ha causato il routing del traffico di rete interno su un link che non poteva -sempre secondo la fonte- reggere nemmeno il 10 % del flusso dati.

Questa configurazione, non si spiega come, ha retto per diversi mesi, finchè la saturazione di questo link ha portato offline uno dei 3 datacenters. I sistemi di failover, non preparati a far fronte ad un problema di questo tipo, non hanno funzionato correttamente e hanno bloccato l’erogazione del traffico anche dagli altri due DC.

Certamente, fa riflettere. Io stesso ho considerato lo spostamento del mio blog su Blogspot o WordPress.com, a causa delle maggiori garanzie che danno rispetto ad un servizio di hosting.

A dire il vero, da diversi mesi mi faccio paranoie, definite da una amica “paranoie da scalasistemistanonrelazionale*”, sulla ridondanza e scalabilità dei sistemi, e stavo considerando lo spostamento di blog e tutto quello che ci sta dietro su una struttura SERIA. Questo vuol dire, dominio da Directi o Google. Email su Google Apps Premium. Blog su Blogspot. E qualunque tipo di applicazione su GAE. Per i documenti uso ormai da tempo Google Docs.

Questo down, non si direbbe, è per me una forte spinta in quella direzione.

Giorgio

* Non si è ancora capito se il nonrelazionale fosse dovuto al tipo di DBM’s su cui lavoro o proprio alle mie relazioni interpersonali O_O.

Oggi parlando con un amico mi è venuto in mente un paragone, tecnicamente non proprio completo e rigoroso*, ma veramente utile per capire, con una tecnica che definirei “da fruttivendolo”, il progresso e gli enormi vantaggi portati dalle fibre ottiche.

Un cavo in fibra ottica può portare 160 lunghezze d’onda. Ognuna di queste lunghezze d’onda porta un segnale da 10 Gbps. Ci sono quindi 1600 Gbps disponibili**. Un cavo seriale porta, in totale, al massimo 115200 bps. Quindi:

Velocità max fibra ottica = MaxFC = 1600 Gbps = 1 600 000 Mbps

Velocità max cavo seriale = MaxSC = 115200 bps = 0.1152 Mbps

Calcoliamo quindi quanti cavi seriali ci servono per raggiungere la velocità di una fibra ottica:

Numero cavi seriali = NSC = MaxFC / MaxSC = 1 600 000 Mbps / 0.1152 Mbps = 13 888 889

Adesso arriva la perla: un metro di cavo seriale pesa 50 grammi. Un metro di fibra ottica ne pesa meno di 2:

Peso fibra ottica = PFC = 2 g

Peso cavo seriale = PSC = 50 g

Per finire dobbiamo quindi calcolare quanti Kg di cavi seriali ci servono per raggiungere la velocità di un singolo cavo in fibra, dal peso di 2 grammi (0.002 Kg):

PtotSC = NSC x PSC = 13 888 889 x 50 g = 694 444 450 g = 694 444 , 450 Kg

Concludendo: per sostituire un cavo in fibra ottica (dal peso, come già detto, di due soli grammi) utilizzato per connettere due punti ad una velocità di 1600 Gbps ed alla distanza di un metro, ci servirebbero 14 milioni di cavi seriali, che avrebbero un peso totale di circa 700 tonnellate. Per UN SOLO metro di distanza. Vi lascio solo immaginare cosa vorrebbe dire sostituire anche solo le fibre transatlantiche.

C’è un’altro dato interessante: la fibra ottica ha una latenza di 5 microsecondi al Km, mentre un cavo seriale ha una latenza di 5 millisecondi al metro.

Latenza fibra ottica = LFC = 5 microsec / Km = 0.005 ms / Km

Latenza cavo seriale = LSC = 5 ms / m = 5000 ms / Km

Immaginiamo di dover collegare Amsterdam a New York e consideriamo una distanza in linea retta tra le due città di circa 6000 Km (inutile dire che chiaramente quella reale percorsa dai cavi sarebbe maggiore). Calcoliamo quindi la latenza, ovvero il tempo impiegato per percorrere questa distanza sui due tipi di cavi:

Distanza = D = 6000 Km

Tempo di percorrenza fibra ottica = TFC = LFC x D = (0.005 ms/Km) * 6000 Km = 30  ms

Tempo di percorrenza cavo seriale = TSC = LSC x D = (5000 ms / Km) * 6000 Km = 30 000 000 ms = 30 000 secondi = 500 minuti = 8 ore e 30 minuti

Questo, in linea teorica. Perchè per percorrere distanze così enormi il segnale deve essere rigenerato, e questo introduce tremendi ritardi nella trasmissione. Ricordo che per percorrere questi 6000 Km il segnale sul cavo in fibra (che percorre 50 Km senza rigenerazione) dovrebbe essere rigenerato (amplificato) 120 volte, mentre quello seriale dovrebbe essere rigenerato ogni 8 metri, ovvero 750 000 volte.

Numero rigenerazioni fibra ottica = NrFC = 120

Numero rigenerazioni cavo seriale = NrSC = 750 000

Qui azzardo una serie di conti, di cui non garantisco l’accuratezza teorica. Quello che è certo, è che comunque i numeri che otterrò saranno inferiori a quelli reali:

Il tempo reale di percorrenza in fibra ottica della linea Amsterdam – New York è di circa 80 ms. Quello teorico calcolato in linea retta è di 30 ms, quindi sembra ragionevole calcolare 40 ms teorici sulla tratta realmente percorsa. Significa che abbiamo circa 40 ms (sottraggo i 40 di tempo teorico agli 80 di tempo reale misurato) di tempo perso nelle 120 rigenerazioni. Questo vuol dire che una rigenerazione del segnale in fibra ottica ritarda il tutto di 0.34 ms.

Tempo reale percorrenza fibra ottica = TpFC = 80 ms

Tempo totale rigenerazione fibra ottica = TtotrFC = 40 ms

Tempo rigenerazione fibra ottica = TrFC = 0.34 ms

Con questi dati, calcolo il tempo impiegato da una rigenerazione del segnale per un cavo seriale. Uso la relazione LFC : TrFC = LSC : TrSC, quindi:

Tempo rigenerazione cavo seriale = TrSC = (LSC x TrFC) / LFC = (5000 ms / Km x 0.34 ms) / 0.005 ms/Km = 340 000 ms

Come già detto, per percorrere questa distanza, il segnale di un cavo seriale deve essere rigenerato 750 000 volte, quindi calcoliamo il tempo totale di rigenerazione:

Tempo totale rigenerazione cavo seriale = TtotrSC = TrSC * NrSC = 340 000 ms * 750 000 = 225 000 000 000 ms

Per concludere devo calcolare il tempo totale impiegato per la percorrenza di questa tratta tramite cavo seriale:

Tempo reale percorrenza cavo seriale = TpSC = TtotrSC + TSC = 255 000 000 000 ms + 30 000 000 ms = 255 030 000 000 ms = 255 030 000 secondi = 4 250 500 minuti = 70 842 ore = 2951 giorni = 8 anni.

In fibra ottica, andiamo da Amsterdam a New York in 80 millisecondi. Con un cavo seriale, impiegheremmo 8 anni. Probabilmente sarebbe molto più conveniente inviare una lettera invece che una mail.

Giorgio

* RS 232 non è stato concepito per comunicazioni a lunga distanza: era usato per collegare i modem o i nodi di un cluster, comunque entro pochi metri. La sua portata è intorno agli 8 metri, questo vuol dire che ogni 8 metri serve un rigeneratore di segnale. Le fibre vanno invece per 50 Km o più senza essere toccate. Per finire, ad oggi non esiste modo di connettere due singoli punti utilizzando tutta la banda disponibile su un cavo in fibra ottica. Allo stesso modo non esiste un modo per connettere due host con 14 milioni di cavi seriali.

** Metto lì un dato senza approfondirlo ulteriormente: abbiamo una velocità di 1600 Gbps per singolo cavo. Le linee transoceaniche sono però composte di fasci di 864 cavi, e di solito sono stese a coppie.

Stavo notando un improvviso incremento dello spam, senza notare un incremento del numero totale di mail ricevute su alcuni server che gestisco. Cosa chiaramente anomala.

Con un pò di smanettamenti ho notato che le email che venivano falciate risultavano positive per “FH_DATE_PAST_20XX”.

Con ulteriori smanettamenti sono arrivato qui:

http://wiki.apache.org/spamassassin/Rules/FH_DATE_PAST_20XX

In pratica il test verifica se l’header “Date:” è palesemente nel futuro. Come fa? Controlla se è tra il 2010 e il 2099. Con conseguenze catastrofiche visto che ormai siamo veramente nel 2010.

Mi sembra strano che nessuno ne parli, son l’unico pistola che lo ha notato?

Al momento comunque l’unica soluzione credo sia inserire nel local.cf questo:

score FH_DATE_PAST_20XX 0.0

Giorgio

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?

Non viene fatto questo grandissimo lavoro, semplicemente recuperano tutte le informazioni disponibili in rete, le espongono in forma schematica e uniforme, e ne vengono fuori articoli, a mio parere, molto ben fatti e utili.

Ho pensato di fare lo stesso, descrivendo le strutture di alcuni hosting-provider a cui mi sono interessato in passato.

Per ora la lista è questa:

• ovh.it
• aruba.it
• servage.net
• byethost.com
• rackspacecloud.com

Si tratta ovviamente solo dell’inizio, pubblicati questi primi 5 articoli, su richiesta dei lettori o seguendo quel mio mitico sesto senso continuerò.

Quello su OVH è praticamente pronto (l’ho descritta qualche giorno fa su hostingtalk), devo solo riordinarlo poi lo pubblico.

Giorgio

]]> http://blog.grg-web.eu/2009/11/infrastrutture-la-nuova-serie/feed/ 0