Un intero edificio della società francese è stato distrutto dalle fiamme. È successo nel campus di Strasburgo della OVH.

Cosa è successo?

Intorno alle 2 di notte dello scorso 10 marzo uno dei quattro edifici di data center della OVH, SBG2 è stato invaso dalle fiamme. L’intero sito è stato isolato e questo ha implicato un blocco dei data center da SGB1 a 4. 

Le riaperture di SGB1 e SGB4 sono programmate entro il prossimo 15 marzo, mentre SGB3 verrà ripristinato entro venerdì 19 marzo.

L’azienda, attraverso un comunicato stampa, sta aggiornando progressivamente i suoi clienti sullo status dell’accaduto. 

L’intervento dei vigili del fuoco non è riuscito a contenere i danni, ma pare che non ci siano state vittime. Le cause dell’incendio non sono state ancora stabilite, intanto è stata avviata un’indagine su mandato delle autorità.

L’improvvisa interruzione delle attività ha causato non pochi problemi ai clienti del fornitore di servizi cloud, che conta di più un milione e mezzo di applicativi sui propri data center. 

 

Down di migliaia di siti, caselle di posta non attive, insieme alle numerose lamentele da parte degli utenti sui profili social ufficiali della società, che chiedono una maggiore assistenza tecnica per tamponare le svariate problematiche. L’azienda si è dimostrata pronta ad intervenire con assistenza diretta ai clienti, ma la situazione sembra essere ancora poco gestibile.

 

Cos’è il Disaster Recovery Plan?

Tramite il  profilo twitter il fondatore e CEO Octave Kabla ha sollecitato i suoi utenti ad attivare quanto prima il Disaster Recovery Plan per fronteggiare l’improvvisa emergenza.

 Il Disaster Recovery Plan è un processo relativo alla preparazione per il recupero e la continuità dei servizi vitali di un’impresa dopo un evento naturale o per un errore umano. È composto da un insieme di fasi tra cui:

  • Testing: Dopo aver installato la soluzione DR, è necessario testarla. “Game day” è quando si esegue un failover nell’ambiente DR.
  • Monitoring and Alerting: È necessario disporre di controlli regolari e di un monitoraggio sufficiente per avvisare l’utente nel caso il proprio ambiente DR è stato interessato da guasti del server, problemi di connettività e problemi applicativi.
  • Backups: Una volta implementato l’ambiente DR, è necessario continuare a eseguire backup regolari. Test di backup e ripristino periodici sono essenziali come soluzione di ripiego.
  • Automation: È possibile automatizzare la distribuzione di applicazioni sui server basati su AWS e sui server locali utilizzando il software di gestione della configurazione.

Ridondanza dei dati

A destare preoccupazione e stupore è anche l’apparente assenza di una ridondanza dei dati, ovvero una progettazione dell’architettura dei server che ne replica il contenuto, garantendo la continua erogazione di un servizio anche se un impianto diventa inaccessibile. 

In effetti tutti i dati che erano hostati sui data center che sono andati in fiamme non erano stati preventivamente sottoposti a backup. 

Perché con AWS i tuoi dati sono al sicuro?

Uno dei punti di forza di AWS è la sua infrastruttura cloud globale. AWS possiede, infatti, l’ecosistema più grande, dinamico e sicuro con milioni di clienti attivi e decine di migliaia di partner in tutto il mondo. 

La rete AWS è organizzata in Regioni, definite come luogo fisico nel mondo in cui si clusterizzano i data center. Ogni regione è composta da una serie di zone di disponibilità isolate e fisicamente e separate all’interno di un’area geografica. 

Le zone di disponibilità  consentono ai clienti di eseguire applicazioni e database in ambienti di produzione con elevata disponibilità, tolleranza ai guasti e scalabilità, altrimenti impossibili da ottenere all’interno di un singolo data center. 

Tutte le zone di disponibilità in una regione AWS sono interconnesse tramite una rete a elevata larghezza di banda e a bassa latenza, su una fibra metropolitana dedicata completamente ridondante che distribuisce reti a alto throughput e bassa latenza tra esse.

Tutto il traffico tra le zone di disponibilità è crittografato. La prestazione di rete è sufficiente per ottenere una replica sincrona fra le zone di disponibilità. Il partizionamento di un’applicazione in diverse zone di disponibilità consente l’isolamento delle aziende e le protegge da problemi come blackout, fulmini, tornado, terremoti e altro ancora. 

Le zone di disponibilità sono fisicamente separate tra loro da una distanza significativa di molti chilometri, pur restando nel raggio di 100 km l’una dall’altra.

Disponibilità elevata

A differenza di altri provider di infrastrutture tecnologiche, ogni regione AWS ha diverse zone di disponibilità. Le zone di disponibilità sono collegate tra loro con velocissime reti in fibra ottica private, per consentire ai clienti di progettare applicazioni che eseguano il failover su diverse zone senza interruzioni.

Il piano di controllo AWS e la Console di gestione AWS sono distribuiti nelle regioni AWS e utilizzano un’architettura multi AZ all’interno di ogni regione per fornire resilienza e assicurare continua disponibilità. 

Ciò assicura che i clienti evitino dipendenze dal servizio critiche su un unico data center.  può condurre attività di manutenzione senza rendere temporaneamente non disponibile un servizio critico per il cliente.

Miglioramento della continuità

Oltre a replicare le applicazioni e i dati in diversi data center all’interno di una singola regione utilizzando le zone di disponibilità, è possibile anche ottenere una maggiore ridondanza e tolleranza ai guasti replicando i dati su più regioni AWS. 

È possibile utilizzare sia reti private ad alta velocità sia connessioni a Internet pubbliche, in modo da migliorare ulteriormente la continuità aziendale e tenere sotto controllo la bassa latenza in tutto il mondo.

Cosa fa VMEngine per proteggere i suoi clienti?

A seguito di un evento così drammatico, sono molte le domande senza risposta rispetto a quanto si potesse prevedere un evento di questa portata. 

Fatto sta che le conseguenze (inaspettate) hanno fatto parlare molto di più dell’evento in sé, basti pensare alla quantità di utenti che dovranno aspettare la prossima settimana per tornare alla normalità.

Si poteva evitare?  È possibile proteggere le proprie infrastrutture da incidenti o da errori umani? Il Cloud è sempre una certezza? 

Di seguito riportiamo alcuni dei Case Study VMEngine che hanno sfruttato le potenzialità di uno dei cloud provider più importanti al mondo e, con l’aiuto di AWS Architect Specializzati, hanno realizzato infrastrutture ad hoc adottando anche tutte le soluzioni per salvaguardare i propri dati e le proprie architetture.

 

 
 Scopri il Case Study su Fantacalcio
 
 Scopri il Case Study su Uninettuno
Share This