Home Cloud Come si affronta un fermo del public cloud

Come si affronta un fermo del public cloud

È successo da poco, nulla impedisce che si verifichi ancora: uno dei principali servizi di public cloud del mondo ha avuto problemi di continuità, e molti dipartimenti IT hanno ricevuto chiamate che lamentavano un sito web o, peggio, un ecommerce non disponibile.

Qualche giorno fa i repository cloud storage Simple Storage Service (S3) di Amazon della regione US-East-1 hanno riscontrato una situazione nella quale “tassi di errore in aumento” impedivano il collegamento a siti web e servizi di primaria importanza.

Siti pubblici, tecnologici, commerciali, universitari ed e-commerce si sono bloccati o hanno rallentato fino a non poter più funzionare. Alcune aziende hanno perso soldi.

Alcuni clienti hanno mostrato comprensione, altri meno, minacciando di chiudere i contratti.  Molti hanno espresso il loro malcontento sui social media.

A partire da quanto accaduto, traiamo alcune lezioni con l’aiuto di Vincenzo Costantino, Emea South Technical Services Director di Commvault: sapere dove sono i propri dati e capire con che velocità si possono recuperare i dati necessari al proprio business.

Prima lezione: gestire i dati sulla base di diverse regioni

Non c’è nulla di sbagliato nel collocare tutti i propri dati in un public cloud, ma è consigliabile avere traccia di dove si trovino i dati a livello geografico.

Se una regione va in tilt, la piattaforma di data management dovrebbe dare indicazioni chiare su dove si trovino i dati distribuiti su più regioni.

Riguardo gli utenti americani, se i dati si trovano a Est, è saggio che abbiano un backup completo dei dati a Ovest, se non addirittura in una regione di un continente diverso.

Se si verifica un problema di grandi dimensioni, si può riprendere velocemente dalla seconda regione, mantenendo attivo il business anche durante un blocco di servizi.

La componente fondamentale in questo senso è il backup.

Servizi critici nativi nel cloud dovrebbero garantire backup programmati nel cloud, o su cloud diversi, in modo da garantire la disponibilità dei dati.

La possibilità di programmare backup automatici, e di verificare che questi backup effettivamente avvengano, aiuta molto i responsabili IT.

Seconda lezione: sapere dove si trovano i dati

Molte aziende hanno scoperto solamente in questa occasione che i loro dati si trovavano nella regione US-East-1 di Amazon S3. Al contrario, sapere dove si trovano i propri dati è un’informazione che i responsabili IT dovrebbero avere.

Quando si trasferiscono i dati in un cloud pubblico, non è sempre scontato che questi siano protetti su tutte le regioni. Conviene gestire in modo attivo il proprio storage, in modo da sapere dove si trovano gli asset più vitali dell’azienda, i dati appunto.

Serve una dashboard che mostri in modo immediato quali dati sarebbero colpiti da un blocco, in modo da poter avere un report di insieme e preparare le risposte prima che il CIO si faccia sentire. Se un blocco riguardasse la costa Est, si potrebbe passare immediatamente al ripristino sulla costa Ovest.

Le soluzioni puntuali di data backup o cloud recovery non danno una visione complessiva dello scenario complessivo dei dati, e si finisce per avere più versioni della verità.

Senza contare che avere diverse soluzioni puntuali implica la necessità di creare report manuali integrando i differenti feed, con conseguente necessità di personale dedicato.

Terza lezione: avere una exit strategy

Poniamo che una copia dei dati al di fuori della regione primaria di riferimento sia stata effettuata. Magari facendo copie onsite e trasferendole nel cloud, o viceversa.

In ogni caso, il problema ora sarebbe di riportare online i propri servizi da qualche altra parte. Ce n’è la possibilità?

Cosa succede se tutti i dati sono codificati nel formato AMI di Amazon e l’infrastruttura on-premise è Microsoft Hyper-V o VMware? C’è il modo di accedere a questi dati e renderli utilizzabili?

La possibilità di trasferire dati tra location e cloud differenti è vitale, una flessibilità che va ben oltre quanto gli strumenti cloud nativi oggi offrano.

Se una fonte non è disponibile, serve la possibilità di effettuare un ripristino sul posto, in una location differente e tra piattaforme diverse di hypervisor.

Se si blocca la regione US-East-1 di AWS, serve la flessibilità di poter ripristinare gli stessi dati localmente, nella regione US-West, oppure anche su Microsoft Azure, Oracle Cloud o altrove ancora.

Ultima, ma non ultima, la lezione davvero rilevante che discende da questi fatti è l’invito a costruire una strategia attorno ai dati, già oggi. Una strategia che consideri i dati nel suo complesso, dal cloud fino a quelli che si trovano on-premises, comprese le differenti tipologie di cloud.

Solamente in questo modo, anche un problema di portata realmente notevole potrà essere superato in modo davvero efficace.

1 COMMENTO

LASCIA UN COMMENTO

Inserisci il tuo commento
Inserisci il tuo nome

Se questo articolo ti è piaciuto e vuoi rimanere sempre informato sulle novità tecnologiche
css.php