Anche i più grandi…

…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.

Quanto resta agli ambienti LAMP mono-server?

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?