Ma torniamo al motivo per cui ho deciso di scrivere: ho comprato un Chromebook (il Samsung Serie 5 Wifi + 3G), che mi è stato consegnato in mattinata. Sapevo bene cosa stavo comprando, ma devo dire che ne sono rimasto (positivamente) impressionato, ed è per questo che ne sto già partorendo una bozza di recensione.

Non andrò molto in dettaglio sulle caratteristiche tecniche poichè sono già elencate perfettamente nelle pagine che ho linkato qui sopra. Per descrivere brevemente il Chromebook a qualcuno che non ne ha mai sentito parlare, possiamo dire che “fisicamente” è un normale portatile di medie dimensioni (12 pollici di schermo), la cui rivoluzione sta nel software: Google Chrome OS. In altre parole, un PC il cui unico programma installato è Google Chrome. Tutto il resto, tutte le applicazioni, sono online: Google Docs al posto di Microsoft Word, webmail varie al posto che il vostro client di posta preferito, e così via.

Si tratta di un modo diverso di lavorare, molto “cloud”, a cui io mi ero già avvicinato da tempo (ho da anni abolito OpenOffice o Office, in favore di Google Docs e così via -l’unica applicazione che forse continuo ad usare è Thunderbird, ma posso permettermelo grazie a IMAP-). Chi mi legge spesso lo sa, sono terrorizzato dalle perdite di dati (ma così terrorizzato che morirei se non avessi copie delle mie ultime ore di lavoro sparse per tutto il mondo), e il sapere che il mio lavoro viene istantaneamente salvato online, mi rassicura. Per questo non è stato più di tanto difficile muovermi.

In questa pagina sono indicate le varie modalità con cui è possibile comprarlo. Il mio costa circa 400€, mentre la versione solo Wifi costa circa 300€.

Viene pubblicizzato principalmente per: sicurezza, velocità, e durata della batteria. Il lato “sicurezza” è puramente teorico, e difficile da spiegare in modo semplice. Sostanzialmente, tutti i dati salvati sono cifrati. Tutto, ogni cosa. Al primo sospetto di manomissione, il sistema torna in automatico ad uno stato sicuro e cancella tutti i dati personali che contiene (seppur cifrati: può permetterselo, in quanto tutto è salvato online).

Gli altri due termini, dovrebbero invece essere più o meno familiari a tutti.

Iniziamo con la velocità. Seriamente, io non credevo fosse vero, ma ho dovuto ammetterlo dopo aver stressato installato riempito e riavviato mille volte questo ‘coso’: si avvia in 7/8 secondi e si “sveglia” (dallo standby) in meno di 2. Non si fa in tempo ad aprire lo schermo che lui è già lì, che chiede la password. Trovo anche incredibile la fluidità con cui si aprano le pagine web, le animazioni e video in flash e così via. Ero stato abituato ben diversamente, dagli altri netbook.

Veniamo invece alla durata della batteria, che è il motivo principale per cui l’ho comprato. La durata ufficiale dichiarata, sotto un normale utilizzo, è di 8 ore, ma molti utenti in rete riportano addirittura record di 12/13 ore. E sto verificando anche questo: l’ho tirato fuori dalla scatola e risultava carico al 90%, oggi alle 12, indicando 8 ore e qualche minuto di energia disponibile. Adesso sono le 18.30, sono passate 6 ore e 30 minuti da quando l’ho acceso, e la batteria è al 61%. Carica disponibile: 5 ore. Potete solo immaginare quanto “anormale” sia l’utilizzo che ne sto facendo essendo così poco che l’ho ricevuto: ho una 20ina di schede aperte, Youtube che va a tutto volume da quando l’ho acceso, e stress test vari.

Questo mi porta addirittura a pensare che quando smetterò di testarlo e inizierò ad usarlo seriamente, con la mia decina di schede aperte, raggiungerò altri e ben più alti numeri.

Svantaggi? Per ora non ne vedo. Certo, bisogna sapere cosa si sta comprando, perchè non è un PC utilizzabile per giocare, scaricare cose o per modificare video, convertire files multimediali e così via, ma passato questo ostacolo, non si riescono a trovare lati negativi.

Un fatto fastidioso per ora è che il tasto di spegnimento è esattamente nella stessa posizione del tasto Canc del mio Dell Studio. Fortunatamente, la semplice pressione veloce del tasto non ha conseguenze.

Due cose interessanti, non pubblicizzate (almeno, io che ho fatto estese ricerche prima di comprarlo, non me ne ero accorto). Primo: non esiste il tasto Bloc Maiusc, sostituito da un più comodo tasto che apre una nuova scheda e punta il cursore nella Omnibox (la barra in cui si digitano l’indirizzo o i termini da ricercare). Solo ora mi sono accorto di quanto raramente usassi quel tasto. Secondo: non esiste nemmeno il tasto Canc (c’è solo il backspace). E su questo devo investigare.

Che dire: vi aggiornerò.

Giorgio

EDIT – Ho appena realizzato: la batteria è interna, quindi spero non si blocchi mai. Se dovesse, rimarrei senza pc per mesi (se dura 12 ore in utilizzo non oso immaginare quante ore di autonomia abbia in stato di freeze).

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.

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.

Settimana scorsa FlareVM.it, di cui già avevo parlato ha lanciato una nuova offerta: VPS Windows. Come per le offerte Linux, il prezzo appare molto competitivo: poco meno di 25  € mensili per una macchina virtuale con 512 MB di RAM, 20 GB di hard disk e una 10 Mbps Flat (in alternativa 400 GB di traffico su linea 100 Mbps).

Il sistema di virtualizzazione usato è XEN HVM (ovverto virtualizzazione totale). Al momento -che io sappia- in italia l’offerta non ha eguali: gli altri servizi di VPS Windows sono tutti basati su Virtuozzo, sistema a virtualizzazione parziale che io tendenzialmente scarto in questi casi (preferisco usarlo quando l’host fisico è mio e la suddivisione in macchine virtuali è solo una questione di comodità).

Virtuozzo crea diversi problemi specialmente con firewall, antivirus e simili, anche se (soprattutto per motivi legati alle licenze di Windows) permette di offrire servizi apparente simili a questo a prezzi inferiori. E’ importante fare questa distinzione al fine di sapere che cosa si compra ed evitare errori. FlareVM offre un’ambiente totalmente isolato, con ram garantita. Fatta eccezione per alcune limitazioni dovute in generale alla virtualizzazione, la macchina è considerabile come un server fisico. I servizi basati su Virtuozzo, come Aruba VPS, costano meno, ma spesso non hanno risorse garantite e generalmente le prestazioni sono di gran lunga inferiori.

Il pannello di controllo fornito per la gestione della macchina è sviluppato internamente, ma appare molto curato e ricco di le funzionalità utili: riavvio e reinstallazione della macchina, console VNC remota (KVM remoto praticamente), e statistiche (grafiche) di utilizzo.

Interessante è il servizio di backup remoto compreso nel prezzo: sono disponibili 10 GB di spazio FTP su server remoto (in un datacenter diverso da quello in cui è ospitata la macchina virtuale) in cui effettuare dei backup di sistema. Il traffico verso il server di backup non viene conteggiato ed è totalmente gratuito.

Il sistema operativo, Windows Server 2008 viene fornito con i driver di virtualizzazione preinstallati. Questo pare aumentarne le prestazioni.

Per non rischiare test falsati (come spesso accade) ho chiesto che la mia VPS fosse attivata su un nodo fisico che la società già considerasse “pieno” (ovvero a carico massimo raggiunto, dove l’aggiunta di nuove macchine virtuali porta ad un degrado prestazionale). Sono rimasto letteralmente impressionato: le prestazioni sono eccezionali. Sia come CPU/IO che come banda.

Ho buone parole anche sulla latenza ovviamente. Come sapete io sono un grande fan di KPN, datacenter di Milano in cui sono situati gli host di FlareVM. Ha ottima connettività internazionale e nazionale. Da una normale ADSL italiana la VPS dista circa 20 millisecondi. Dalla VPS ad Aruba sono 6 millisecondi, e ci vogliono circa 100 millisecondi per arrivare oltreoceano.

Il supporto, secondo diversi feedback ma come io stesso ho potuto verificare, è molto veloce, cordiale e risolutivo.

Non vi prometto una recensione dettagliata con test e grafici di IO/Banda/CPU perchè in questo periodo ho molto poco tempo, ma non posso che consigliarvi di provare il servizio.

Se state cercando una VPS Windows in italia, sicuramente FlareVM è una delle migliori scelte.

E’ da un pò che non mi sentite, e ho deciso di riapparire con una recensione. Giorni fa ho trovato su twitter (io sono @g_bonfiglio) un codice coupon TopHost per attivare un pacchetto ad 1 € per il primo anno. Ero curioso, ed essendo in vacanza ho deciso di provare un TopBlog. Il servizio si presenta come una piattaforma di blogging completa basata su WordPress, corredata di un dominio e di 1 GB di spazio per gli allegati ed una casella email di 200 MB di spazio con infiniti alias attivabili, al prezzo normale di 9.59 € + IVA annuali.

Ho ordinato il pacchetto con un dominio .net, nelle prime ore del pomeriggio ed è stato attivato la mattina dopo. L’attivazione non è istantanea (non azzarderei, forse non è automatica) ma è veloce. Ho impressione che giri un qualche tipo di cron per completare le attivazioni, quindi con forte probabilità sarebbe stato attivato alle 7 di mattina anche se lo aveste ordinato due ore prima.

TopBlog è corredato da due pannelli di controllo: uno, quello classico di TopHost (ridotto) tramite il quale posso gestire l’account e gli alias email ed accedere alla webmail Horde e alle statistiche del server, ed il pannello di WordPress MU tramite cui si lavora sul blog vero e proprio.

Come ho più e piùvolte ripetuto, trovo il servizio email di TopHost ottimo: i filtri antispam funzionano egregiamente, è disponibile accesso sia POP3 sia IMAP4, ed è offerto anche il servizio SMTP (autenticato ovviamente). I tempi di accesso e le prestazioni del servizio in generale sono ottimi.

Per quanto riguarda il blog, non sono altrettanto soddisfatto. La prima cosa che mi ha colpito è stato lo sfondo blu dell’area di amministrazione e il suo vecchio design: chi conosce WP saprà certamente che la grafica è stata rinnovata da più di 2 anni. Ne deduco quindi che la versione di WordPress usata sia qualcosa come la 2.3/2.5, entrambe datate a metà 2008. Da una azienda che parla spesso di CMS abbandonati (nel post promettono la sospensione dei siti con cms non aggiornati… spero solo non si auto-sospendano) e chiede ai clienti frequenti aggiornamenti degli script usati, mi sarei aspettato se non una latest almeno una versione recente.

Non parliamo infatti di un CMS vecchio di qualche settimana o mese, ma di qualche anno: i rischi per la sicurezza derivanti da CMS non aggiornati come loro stessi ricordano sono alti, e non solo, gli utenti potrebbero apprezzare le nuove features e la notevole semplicità delle nuove versioni di WordPress. Ho subito aperto un ticket chiedendo la data dell’aggiornamento, credendo fosse una procedura ovvia e pianificata: mi è stato risposto che al momento non ci sono piani per l’aggiornamento della piattaforma.

Ho poi fatto un giro tra i plugin disponibili, che sono datati ed in numero veramente limitato. La stessa cosa dicasi per i temi: non sono molti (una ventina), e sono decisamente scarni, semplici e molto simili. La scelta dunque non è molta.

Mi sono poi imbattuto in un bug: un plugin chiede l’aggiornamento e mi offre il link per effettuarlo, ma non ho i permessi per completare l’operazione.

Per quanto mi riguarda il servizio allo stato in cui è ora, è inutilizzabile: non trovo un tema fresco e decente, mi mancano alcuni plugin utili e non affiderei mai il mio blog ad una piattaforma così vecchia e a rischio (googlando si trovano diversi report di vulnerabilità XSS di WordPress MU, sempre prontamente corretti… per chi ha aggiornato).

Sono rimasto seriamente deluso dal servizio, e come risultato, dopo neanche 10 giorni di TopBlog (di cui 8 passati lontano dal pc) ho chiesto il passaggio a TopWeb che ho potuto completare rinnovando il pacchetto in anticipo, con l’idea di installare il CMS per conto mio. Per chi continuasse a preferire una piattaforma hosted per la sua semplicità, consiglio wordpress.com o blogger.com, a cui manca solo il dominio di secondo livello, che è acquistabile a circa 15 $.

A questo  punto sarei curioso di recensire le alternative (tra cui anche Aruba Blog e i servizi classici come Tiscali Blog o Libero Blog), potrebbe interessare come serie di articoli? Fatemelo sapere, grazie.

Buone Vacanze

Giorgio

]]> http://blog.grg-web.eu/2010/08/recensione-tophost-topblog/feed/ 7 http://blog.grg-web.eu/2010/04/hello-mx/ http://blog.grg-web.eu/2010/04/hello-mx/#comments Sun, 25 Apr 2010 09:34:08 +0000 Giorgio Bonfiglio http://blog.grg-web.eu/?p=140

A volte capita, dopo aver lanciato un HELO ad un MX, di ricevere risposte veramente simpatiche, carine, o stupide e inutili, comunque molto lontane dal default. Lo stesso, a volte, succede dopo il QUIT.

E’ curioso notare come gli amministratori di queste strutture si divertano a studiare queste risposte, quasi come fosse un must alla pari dell’antispam nel processo di configurazione di un mailserver.

Mi sembra quindi il caso di farne una sorta di rassegna di seguito:

Postini, il noto servizio di Google, appare molto freddo e professionale, mettendo subito in chiaro chi comanda:

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.

fx-in-f83.1e100.net

fx-in-f147.1e100.net

fx-in-f118.1e100.net

La struttura dei nomi mi ha subito ricordato lo schema che usa Google per i suoi load balancers, ed un veloce controllo WHOIS e sugli IP ha confermato quello che avevo intuito: si trattava di un suo dominio “di servizio”. In rete, non avevo trovato nessuna informazione. Alla fine, mi è uscito dalla testa.

Ieri per caso ho trovato questo articolo su TheRegister.co.uk, ed ho scoperto il senso del nome 1e100.net (su cui non avevo fatto alcuna ricerca, credevo fosse totalmente casuale):

But on closer inspection, the domain is obviously Google’s, chosen with a mathematician’s wink at the search giant’s famously misspelled name. This mystery domain is 1e100.net. “1e100″ would be scientific notation for 10 100, a one followed by 100 zeros, also known as a googol.

Il nome è quindi, come spiega TheRegister, la notazione scientifica di 10^100, 1 seguito da 100 zero, definito googol, da cui deriva il nome google.

E’ interessante notare la crescita delle visite verso il dominio, secondo Alexa:

Una linea verticale!

Giorgio

Google Public DNS:

8.8.8.8, 8.8.4.4

Level3 DNS (Unofficial*):

4.2.2.1, 4.2.2.2, 4.2.2.3, 4.2.2.4

4.2.2.5, 4.2.2.6

OpenDNS:

208.67.222.222, 208.67.220.220

208.67.222.220, 208.67.220.222

DNSAdvantage (UltraDNS):

156.154.70.1, 156.154.71.1

* Il servizio non è mai stato reso pubblico. Questi resolver funzionano, funzionano perfettamente, ma Level3 li ha mai resi disponibili al pubblico ufficialmente.