Quantcast
Channel: snapshot | VMengine S.R.L.
Viewing all articles
Browse latest Browse all 4

DataCenter Failure : downtime in not an option

0
0

Si parla di dati evaporati, di turbolenze, di uragani, di temporali, ognuno utilizza la sua metafora associata alle nuvole, proprio perché parliamo di cloud computing, di disaster recovery, di downtime nei datacenter. Parliamo di Amazon Web Service, di Aruba, di Google Mail, di sistemi di storage clusterizzati, parliamo di dati centralizzati, di servizi centralizzati in datacenter che nascono per fare questo lavoro, di errori umani, di errori di pianificazione e anche di leggerezza dei clienti nell’affidarsi completamente senza aver magari letto i contratti di SLA, senza aver correttamente implementato il proprio sistema con i servizi erogati dal provider, infine senza aver valutato i danni economici e di immagine derivanti dal downtime, la famosa business continuity.

AWS Outage

Partiamo da Amazon, come già indicato in quest’altro post il giorno 21 aprile si sono verificati dei problemi in un datacenter della zona us-east (Virginia), ai servizi fondamentali EC2 e RDS. Questi hanno messo a terra alcuni servizi social famosi di internet come Foursquare, Reddit e Quora.

Ma NetFlix, Twilio, ed altri pur utilizzando risorse nella stessa availability zone, non hanno subito lo stesso destino, lo stesso Reddit è quasi subito ritornato in linea grazie ad un contratto di assistenza forte con Amazon che gli ha garantito degli ingegneri dedicati. Amazon ci dona un sommario a conclusione della vicenda dove illustra quello che è accaduto e come hanno gestito l’evento, cosa hanno imparato e come si muoveranno nell’immediato futuro per evitare che si ripeta, si scusano con tutti il clienti e parlano di rimborso in crediti per i clienti. Ovviamente il rimborso non è misurato in base all’entità del danno subito, ma questo dipende come noto dal tipo di contratto che si stipula con il provider.

EBS Storage synch problems

Per il servizio EC2 la causa scatenante è stato un sottoinsieme di dischi EBS in una zona di disponibilità. Sembrano essersi bloccati, incapaci di leggere e scrivere, ovviamente le istanze che dipendevano da questi dischi erano altrettanto bloccate. Hanno disabilitato le API di controllo di questo cluster di EBS in quella zona colpita. A questo punto Amazon illustra in breve il funzionamento del servizio dei dischi EBS e del cluster relativo. Come molti esperti avranno già intuito EBS è uno storage distribuito, costituito da una serie di cluster contenenti i dati in replica coerente ed a livello di blocco tra loro, ed una serie di altri sistemi utile a coordinare le richieste degli utenti ai nodi. Le repliche dei dati tra i nodi dei cluster sono assicurate da un peer-to-peer con strategia fast-failover per attivare nuove repliche se una va fuori sincronia o non è più disponibile. I nodi sono collegati tra loro da due reti, la prima a banda larga e la secondaria di capacità inferiore usata come backup e come rete d’espansione per la replica dei dati. La seconda rete non nasce per gestire tutto il traffico della primaria ma per fornire connettività molto affidabile tra i nodi.

Il problema è nato a causa di un errore umano durante una normale attività di ridimensionamento della rete primaria di un cluster EBS, la modifica doveva servire per potenziarne la capacità, ma il traffico che doveva essere spostato per trasferire l’aggiornamento è stato erroneamente trasferito sulla rete secondaria che non ha retto e le repliche sono saltate. Il problema dello storage EBS ha ovviamente avuto impatto anche sul servizio di database relazionale RDS che ne è totalmente dipendente

Secondo una analisi di RightScale ci sarebbero stati più di 500k volumi EBS colpiti, inoltre sostiene che un evento di tale portata superi i parametri di progettazione, non può essere testato e che non vi è sistema di scala comparabile in funzione da nessuna altra parte.

Amazon dichiara che provvederà a fare una serie di modifiche per migliorarsi ed evitare il ripetersi di questo tipo di eventi.

Un commento interessante di Lew Moorman di Rightscale in una intervista sul New York Times : “L’interruzione di Amazon è l’equivalente informatico di un incidente aereo. Si tratta di un episodio importante con danni diffusi. Ma il viaggio aereo è ancora più sicuro che viaggiare in auto – analogo al cloud computing di essere più sicuro dei data center gestiti dalle singole imprese. Ogni giorno, nelle aziende di tutto il mondo, si verificano interruzioni della tecnologia, ogni episodio è molto piccolo, ma può far perdere più tempo, soldi e affari.”

Lezioni e giusti approcci d’uso di AWS

Cosa può fare il cliente per usare correttamente i servizi citati per ovviare le problematiche tecniche del provider? Innanzitutto il servizio EC2 usato semplicemente e singolarmente non garantisce l ‘alta affidabilità, bensi ha uno SLA di 99.95%, lo stesso dicasi di RDS che dipende da EC2 ed EBS. Ma la stessa Amazon comunica che un corretto uso dei servizi porta a soluzioni in alta affidabilità. Ad esempio, usare più zone di distribuzione (NetFlix ne usa tre), usare snapshot degli EBS crea la possibilità di replicare il volume in altre zone di disponibilità (lo snapshot è fisicamente localizzato sul sistema S3), backuppare i dati su S3, i backup e snapshot di RDS o addirittura attivare le repliche su multi-AZ, cioè tra diverse zone di disponibilità. Questi sono gli approcci che hanno impedito a certi clienti di essere offline nonostante le problematiche del provider.

Aruba

In base alle dichiarazioni di aruba sulla seguente comunicazione : http://ticket.aruba.it/News/212/webfarm-arezzo-aggiornamenti-3.aspx

Stamane alle h. 04:30, un corto circuito avvenuto all’interno degli armadi batterie a servizio dei sistemi UPS della Server Farm aretina di Aruba ha causato un principio di incendio: è immediatamente entrato in funzione il sistema di rilevamento incendi che in sequenza spegne il condizionamento e attiva il sistema di estinzione. Poiché il fumo sprigionato dalla combustione della plastica delle batterie ha invaso completamente i locali della struttura, il sistema ha interpretato la persistenza di fumo come una prosecuzione dell’incendio e ha tolto automaticamente l’energia elettrica.

Il sistema UPS dovrebbe essere di switch dell’alimentazione principale di rete, mentre un errore di progettazione (errore umano) dell’impianto di areazione del locale UPS, ha causato lo spegnimento di tutti i sistemi, che per il mercato italiano ha significato l’offline di milioni di siti dei clienti. Come dice la stessa Aruba nel comunicato questo errore sarà risolto:

Inoltre, nonostante sia consuetudine installare le batterie all’interno del data center, per evitare il ripetersi di quanto accaduto, da oggi le batterie del data center di Arezzo e di tutti gli altri data center del Gruppo Aruba saranno installate in appositi locali, esterni e separati dalla struttura principale.

Google Gmail

Nel caso del disservizio per alcuni clienti della posta gmail dello scorso febbraio, come comunicato nel http://static.googleusercontent.com/external_content/untrusted_dlcp/www.google.com/it//appsstatus/ir/nfed4uv2f8xby99.pdf, il disservizio è stato causato da un bug inavvertitamente introdotto in un aggiornamento software (errore umano), e per evitare problemi di integrità dei dati sono stati disabilitati gli accessi alle google apps per il numero di clienti interessato, il team di ingegneri ha dovuto ripristinare le mailboxe dai nastri di backup, confermandoci che i backup su nastro sono ancora in uso ed ancora affidabili.

Conclusioni

Nonostante questi incidenti, come dice Lew Moorman nell’intervista al NYT, prima citata, i datacenter grossi gestiti da queste grandi entità, sono sempre più sicuri delle soluzioni che le piccole medie imprese potrebbero adottare.

Invece la discussione andrebbe spostata su una questione molto complessa che parte dalla seguente constatazione:

perchè facebook, google ed amazon si costruiscono i server (facebook e google nello specifico), i datacenter (vedi facebook opencompute project), modificano o creano progetti software opensource per le proprie esigenze (vedi bigtable di google), esempio i sistemi di storage S3 EBS (pare usino DRDB), SDB, dove il cuore pulsante sono batterie di server classici ma potenti, sistemi di rete dedicati che replicano i dati tra i numerosi nodi, quindi soluzioni software proprietarie o modifiche di progetti opensource nati in qualche università nel mondo e magari ancora in fase di sviluppo su qualche share mondiale.

la domanda è provocatoria per i vendor dei maxi sistemi (IBM,HP,Dell,etc),  ma la risposta potrebbe essere nelle seguenti nostre vecchie pubblicazioni ( Isilon tecnologia,  EMC compra Isilon, HP compra LefHand, ed altre recenti acquisizioni), cioè i grossi vendor solo da pochi anni hanno iniziato a comprendere la necessità di specializzarsi nei sistemi di storage distribuiti clusterizzati, perchè solo questi sistemi hanno la capacità di rispondere a grosse quantità di dati e grosse necessità di banda e di accessi simultanei, inoltre le enormi necessità di amazon,google,facebook fanno pendere l’ago della bilancia economica verso soluzioni open o proprietarie rispetto i costi di licenze e di assistenza che avrebbero tramite i vendor di prima.

Insomma la maggior parte delle soluzioni software o hardware dei servizi che noi usiamo ed useremo sempre più, appartenenti o meno al paradigma del cloud computing, sono sistemi che per la loro dimensione e portata, non saranno mai testati efficacemente per evitare il disastro.


Viewing all articles
Browse latest Browse all 4

Latest Images

Trending Articles



Latest Images