Disaster recovery: come e perché proteggere lo storage secondario

pittogramma Zerouno

Guida

Disaster recovery: come e perché proteggere lo storage secondario

La fase di lockdown ha spinto le aziende a concentrarsi soprattutto sullo storage primario, ma le ha esposte ad attacchi e incidenti su quello secondario la cui vulnerabilità nasce dalla mancanza di un piano adeguato di disaster revovery che oggi, invece, grazie alla tecnologia flash e al protocollo di comunicazione NVMe, può far raggiungere a sistemi e applicazioni livelli elevati di capacità, prestazioni e disponibilità

07 Lug 2020

di Carmelo Greco

Il disaster recovery ha assunto un’importanza cruciale durante il lockdown. Non che prima non la avesse, ma lo stress test a cui è stato sottoposto tutto il mondo a causa del Covid-19 ha fatto emergere vulnerabilità nelle infrastrutture IT finora sconosciute. Se, infatti, come sostiene la rivista MIT Technology Review, la quarantena da coronavirus ha reso Internet più forte che mai, reggendo perfino in Italia dove si è registrato un aumento del 40% negli accessi alla Rete, altro discorso è quello della strategia resiliente ad attacchi e incidenti. Solo per fare un esempio, nel mese di marzo le organizzazioni della Gran Bretagna hanno censito “solo” 67 incidenti, per un totale di oltre 832 milioni di record interessati. È bene ricordare, tuttavia, che la maggior parte di queste violazioni richiede 100 giorni o più per essere scoperta. Quindi, gli effetti di cyber attack e data breach potrebbero manifestarsi anche in tempi in cui si suppone di essere tornati alla normalità. Ecco perché è necessario proteggere lo storage secondario con un adeguato disaster recovery plan o DRP.

Come funziona il disaster recovery

L’indicazione che possiamo trarre dall’analisi della MIT Technology Review è che in generale lo storage primario sostanzialmente non è collassato. In altri termini, nonostante la crescita esponenziale dei dispositivi che, soprattutto da remoto, si sono collegati ai database e alle applicazioni aziendali per attingere ai dati digitali in uso costante, l’ondata in qualche modo è stata tamponata, al netto di rallentamenti e fisiologico buffering. Ciò non toglie che nei casi in cui invece i sistemi siano stati oggetto di un attacco informatico, si siano guastati per qualsiasi motivo o siano stati danneggiati per un errore umano, l’impossibilità di ripristinare accesso e funzionalità, cioè di garantire la business continuity, ha creato un danno calcolabile con il tempo di inaccessibilità e la qualità del dato recuperato. Secondo quanto riporta il sito Statista, il costo medio orario dei tempi di inattività dei server nel 2019 è stato compreso tra 301 mila e 400 mila dollari. Costi che si potrebbero evitare con un piano di disaster recovery che verte, infatti, sulla replica dei dati e dell’elaborazione su una posizione diversa rispetto a quella coinvolta dall’evento disastroso. Per questo si parla, appunto, di storage secondario.

Elementi di un piano di disaster recovery

Nella definizione di un DRP efficace è necessario contemplare alcuni elementi essenziali. Anzitutto una fase di assessment per valutare la dotazione di partenza e i livelli di rischio che un downtime potrebbe arrecare all’azienda. In questo modo si possono elaborare i due valori di riferimento che intervengono in un piano di disaster recovery: il Recovery Time Objective (RTO) e il Recovery Point Objective (RPO). Il primo si riferisce al tempo “tollerabile” tra l’interruzione e il momento del ripristino, mentre il secondo indica la frequenza di backup che andranno effettuati e, di conseguenza, la quantità di dati che si è disposti a perdere in seguito a un arresto. La pratica del backup è molto diffusa tra le organizzazioni, ma ha lo svantaggio che il suo apporto nel disaster recovery si limita alla messa in sicurezza dei dati, ma non a quella dell’infrastruttura IT. Gli ulteriori elementi di un DRP, poi, sono:

  • la scelta della soluzione;
  • l’implementazione del sito secondario che, nel caso in cui ci si affidi a un provider, presuppone che siano concordati determinati SLA (Service Level Agreement);
  • il rilascio della documentazione formale contenente tutte le informazioni sulle caratteristiche dell’ambiente di ripristino, nonché sulle policy, le procedure e le figure previste;
  • una serie di test periodici e una manutenzione che tenga sempre aggiornati i processi di disaster recovery dal punto di vista tecnologico e di compliance.

Tipologie di disaster recovery

Come anticipato, al primo stadio di un disaster revovery si colloca il backup che solitamente avviene su due o tre posizioni che memorizzano copie dei file: onsite, su un’unità rimovibile ed, eventualmente, nei data center di un Managed Service Provider. Sull’insufficienza del solo backup in un piano DR si è già detto, poiché RTO e RPO rimarrebbero molto alti e non ci sarebbe alcuna protezione di sistemi e applicazioni. Perciò, le modalità che vengono utilizzate tradizionalmente sono quattro: cold site, hot site, DRaaS, virtualizzazione.

  • Cold site – Questo piano di ripristino prevede lo storage secondario in una seconda sede, ma siccome è quasi sempre inattivo, tranne quando serve, i tempi di recupero sono più lenti rispetto ad altri piani e richiedono dai tre ai cinque giorni. Probabilmente troppi per i requisiti di uptime di qualsiasi azienda, anche a fronte di un investimento meno oneroso rispetto alle altre soluzioni.
  • Hot site – A differenza dei cold site, sono sempre attivi e dispongono di copie aggiornate dei dati in ogni momento, quindi lo spostamento dallo storage primario a quello secondario è senza soluzione di continuità. L’unico problema è rappresentato dai costi elevati, in quanto vengono praticamente raddoppiati hardware, licenze, manutenzione, connessione, alimentazione e raffreddamento.
  • DRaaS – Il disaster recovery as-a-service (DRaaS) mette a disposizione un’infrastruttura cloud in caso di indisponibilità del sito primario e viene offerto sia in abbonamento sia con il metodo pay-per-use. Presenta due pecche: la questione della latenza che varia in funzione della vicinanza alla sede dell’organizzazione, il rischio che l’evento disastroso che ha colpito i server aziendali non abbia escluso i data center del vendor se si trovano in prossimità all’epicentro dell’evento.
  • Virtualizzazione – Con i servizi di disaster recovery virtuale si può creare una replica dell’intero ambiente informatico, inclusi server, storage, sistemi operativi, applicazioni e dati. Le macchine virtuali off-site sono indipendenti dall’hardware, il che significa che possono essere copiate e installate ovunque senza alcuna configurazione.

Le architetture storage per il disaster recovery

A prescindere dalla tipologia di disaster recovery per cui si opta, resta fondamentale l’architettura storage che si sceglie, anche quando ci si affida a un service provider. Dall’architettura, infatti, dipende la minore o maggiore efficienza nell’eseguire i workload. Generalmente i carichi di lavoro vengono classificati in base a requisiti di capacità, prestazioni e disponibilità. È interessante notare che i primi due si riferiscono anche allo storage primario, oltre che a quello secondario, mentre è soprattutto sulla disponibilità o availability che si misurano RTP, RPO e fault tolerance. Quest’ultimo, in particolare, è proprio il parametro che assicura la continuità operativa e, nelle architetture maggiormente performanti, garantisce una percentuale di disponibilità pari al 99,999%. Oggi sono soltanto quelle di tipo All flash che possono vantare queste caratteristiche, tanto da essere diventate uno standard sempre più diffuso nello storage array, destinato a crescere ulteriormente tramite la tecnologia SSD NVMe. Vediamo perché.

Tecnologie NVMe, NVMe-oF e Storage-class memory (SCM): caratteristiche e differenze

NVMe (Non Volatile Memory Express) e NVMe-oF (over Fabrics) sono due interfacce software, o protocolli di comunicazione, sviluppati per conseguire il massimo della performance nei sistemi di flash storage. A differenza dei protocolli SATA per le unità di memoria elettromeccaniche e degli stack SCSI per il disco rigido, la tecnologia NVMe permette a un dispositivo flash di funzionare quasi senza restrizioni. In altri termini, raggiunge l’obiettivo di far lavorare la CPU in maniera più efficiente e con tempi di latenza notevolmente inferiori. Inoltre, la variante NVMe-oF estende a più host la possibilità dello storage basato su SSD NVMe poiché supporta sistemi di networking quali Ethernet, Fibre Channel, Infiniband e TCP. Se a questo si aggiunge che l’introduzione dello Storage-Class Memory (SCM), un tipo di RAM non volatile che mantiene il contenuto della memoria anche in caso di interruzione imprevista dell’alimentazione, si intuisce perché il loro binomio possa trovare una felice applicazione nella data protection degli storage secondari.

I vantaggi dell’architettura multi controller

È opportuno sottolineare che il ricorso al flash storage, perché sia adeguato a gestire modelli di disaster recovery e paradigmi di data security di classe enterprise, deve far sì che l’intero path si avvalga della tecnologia NVMe giusta. La fase di assessment per individuare la tipologia di DR che fa al caso proprio, va considerata anche per identificare l’architettura flash dello storage secondario. Basti pensare che architetture che non siano multi controller non offrirebbero quello scale-out che impedisce la rapida saturazione delle risorse. Un problema che, ai fini del ripristino, creerebbe tempi di interruzione troppo lunghi e difficilmente sostenibili. Al contrario, l’architettura multi controller è in grado di ripartire uniformemente il carico di lavoro, riuscendo a scalare fino a centinaia di TB e milioni di I/O. Con il risultato che capacità, prestazioni e disponibilità sono assicurati molto di più che con qualsiasi altra soluzione disponibile sul mercato.

AI e machine learning al servizio delle moderne architetture storage

All’interno di queste tipologie di architetture storage un contributo supplementare all’ottimizzazione arriva dall’Artificial Intelligence (AI). In particolare, l’integrazione di motori di machine learning (ML) consente di posizionare automaticamente i dati sul supporto idoneo, che sia flash o SCM, in base al profilo I/O. L’engine ML, in sostanza, analizza in chiave predittiva milioni, se non miliardi di data set, identificando pattern in ogni array per poi distribuire i dati senza causare overhead. In teoria, si tratta di una tecnologia che non teme l’obsolescenza giacché, se in futuro dovesse presentarsi un supporto più veloce di quelli attualmente conosciuti, è già predisposta a collocarvi armonicamente i dati, concretizzando quei meccanismi di razionalizzazione intelligente propri dell’apprendimento automatico. Anzi, man mano che aumenta il volume dei dati su cui l’algoritmo “impara”, anche la sua abilità e celerità a trovare la giusta posizione nello storage ideale diventa maggiore. Un’abilità che risponde, fra l’altro, a una suddivisione dei carichi di lavoro che tenderà a spostarsi sempre di più da workload tradizionali, come possono essere quelli generati da ERP o CRM on premise, verso moderne applicazioni cloud native e piattaforme in cui convergono sistemi IoT e servizi AI.

Sul versante del disaster recovery questo vuol dire abbassare, fino quasi ad azzerarli, i parametri RTO e RPO, visto che i passaggi dallo storage primario a quello secondario possono avvenire in maniera automatizzata e permanente, cioè in ottica continuous data protection (CDP). Con il vantaggio che la replica, governata dall’intelligenza artificiale, ruota attorno a criteri di efficienza e quindi fa in modo di inviare al sito di destinazione solo dati univoci al fine di ridurre al minimo i requisiti di larghezza di banda necessaria.

Carmelo Greco

Giornalista

Giornalista professionista, si occupa come freelance e formatore di temi connessi all'innovazione digitale e alle trasformazioni del mercato del lavoro. Collabora alla collana “La bellezza dell'impresa” edita da Rubbettino ed è autore di opere teatrali e di narrativa.

Argomenti trattati

Approfondimenti

B
Backup

Articolo 1 di 4