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.
Che cos’è il disaster recovery
Il significato di disaster recovery in informatica fa riferimento alle tecnologie e pratiche metodologiche e organizzative pensate per ripristinare infrastrutture e sistemi di dati utili per far funzionare applicazioni e servizi in seguito a emergenze e criticità quali attacchi informatici, incidenti causati da errori umani, guasti alle apparecchiature, interruzione di energia elettrica. Il disaster recovery è quindi un elemento fondante la Business continuity.
Vantaggi del disaster recovery
È importante premettere che in alcuni casi il disaster recovery è necessario per essere compliance con il GDPR che impone di adottare misure per garantire il ripristino dell’accesso a determinati dati in tempi certi per rispettare i diritti degli interessati. Dimostrare di essersi preparati per fare disaster recovery è quindi finalizzato a essere conformi alle normative in vigore.
Il principale vantaggio riconducibile a un efficace piano di disaster recovery è quello di ridurre costi e perdite di una eventuale interruzione dei sistemi e quindi di business operations e processi critici.
Disegnare una strategia di disaster recovery consente, inoltre, di gestire in maniera efficace e veloce gli interventi necessari senza dover ricorrere a decisioni esclusivamente dettate dall’emergenza.
Da un punto di vista di business, sapere come agire in casi di problemi significa dare un’immagine del brand di solidità che, altrimenti, potrebbe subire un grave danno di reputazione.
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. E questo sebbene la mole di informazioni da processare, archiviare e rendere disponibile sia enormemente aumentata. Già in tempi normali una struttura di storage primario deve riuscire a gestire l’interazione con una serie di device, dagli smartphone ai laptop fino ai dispositivi IoT, che generano terabyte di dati. Figurarsi in un periodo in cui la parte digitale prende il sopravvento a causa della distanza forzata dai luoghi fisici in cui solitamente ci si incontra. 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. Ma che cos’è esattamente lo storage primario?
Storage primario: definizione e funzionamento
Il primary storage si occupa della gestione dei carichi di lavoro delle applicazioni core di un’organizzazione. In quanto tale identifica quell’insieme di tecnologie che permettono l’accesso a un archivio di dati digitali, generati dai database e dalle applicazioni aziendali, in uso costante. I dati, perciò, vengono gestiti da memorie volatili, come la RAM, o da altri componenti integrati in maniera tale da garantire scalabilità e rapido accesso. Ne consegue che i sistemi di storage primario sono fatti per assicurare prestazioni di alto livello, in particolare nelle operazioni di input e di output. Questa è la ragione per cui i tradizionali hard disk drive (HDD) oggi tendono a essere soppiantati da unità solid-state drive (SSD) che, in virtù dell’uso della memoria Flash, un tipo di memoria a stato solido e non volatile, offrono prestazioni nettamente superiori rispetto ai consueti dischi rigidi HDD. Velocità di accesso e affidabilità sono le principali caratteristiche degli SSD che utilizzano memoria Flash, come avremo modo di approfondire più avanti a proposito delle architetture storage per il disaster recovery. Quest’ultimo entra in gioco soprattutto nei casi in cui 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, crea infatti 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 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.
Le classificazioni all’interno di un DRP
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. A tale scopo, vige una classificazione standardizzata dei possibili disastri che sono suddivisi in due grandi categorie:
- disastri naturali, che comprendono inondazioni, uragani, tornado e terremoti;
- disastri provocati dall’uomo, di cui fanno parte guasti infrastrutturali, fuoriuscita di materiale pericoloso, attacchi informatici, errori involontari.
Per quanto riguarda, invece, i dati e i sistemi da proteggere, la loro classe di rilevanza si articola su un valore che va da 1 a 4 ed è così rappresentata:
- Critici
Si tratta dei sistemi e delle applicazioni le cui funzionalità sono uniche e non possono essere eseguite da altri sistemi e applicazioni. Generalmente non possono essere sostituiti con metodi manuali e la loro interruzione genera costi fuori controllo che possono perfino mettere in crisi il business dell’azienda.
- Vitali
Le funzioni gestite tramite questi sistemi possono essere svolte manualmente, ma solo per un breve periodo di tempo. Per questo, a differenza di quelli critici, hanno una maggiore tolleranza rispetto alle interruzioni, con relativi costi inferiori, a patto però che vengano riattivati nell’arco di un intervallo di tempo che non superi all’incirca i 5 giorni.
- Delicati
Sono i sistemi che possono essere gestiti manualmente, e a costi tollerabili, anche per un lungo periodo di tempo. Tuttavia, l’impiego di risorse superiore alla norma durante il loro malfunzionamento crea delle inefficienze e, di conseguenza, un aggravio perdurante dei costi associati.
- Non-critici
Sono i sistemi e le applicazioni la cui interruzione anche prolungata non provoca quasi nessun costo, o costi assai limitati, all’azienda. Analogamente lo sforzo per ripristinarli è pressoché nullo.
RTO e RPO, in due valori chiave nel disaster recovery
I due valori di riferimento che intervengono in un piano di disaster recovery sono 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.
Gestione dello storage in un ambiente di disaster recovery
Nel disaster revovery il concetto chiave è quello della ridondanza, cioè della replica dei dati dello storage del sito primario in un sito secondario. Quest’ultimo entra in funzione non appena il primo non sia utilizzabile per qualsiasi motivo. La replica può essere di 3 tipi: sincrona, asincrona e mista.
Replica sincrona
È uno dei metodi più adottati e prevede la replicazione di dati e sistemi su entrambi i siti, primario e secondario. Quindi, ogni blocco scritto in locale viene copiato anche su un secondo array remoto. È una tecnica che garantisce estrema rapidità di riavvio, e perciò RTO e RPO molto bassi, con livelli elevati di affidabilità. Ha lo svantaggio di comportare costi onerosi che dipendono dalla qualità dello storage sia sul sito primario sia su quello secondario, a cui si aggiunge la necessità di avere a disposizione banda larga e bassa latenza (quindi è indicata la fibra ottica). Inoltre, la distanza geografica tra i due siti potrebbe essere un problema, poiché incide sull’efficacia delle performance, così come la giusta collocazione di quello secondario, che può trovare spazio in un’altra sede dell’azienda, in co-location condivisa o all’interno di un servizio in cloud.
Replica asincrona
Il problema della distanza non si pone con la replica asincrona. In quest’ultimo caso, quando lo storage è avvenuto sul sito primario, si procede alla scrittura e alla propagazione su quello secondario. Il che supplisce alla criticità della lontananza tra i due siti, pur generando un disallineamento tra le due scritture e perciò rendendo impossibile la disponibilità di copie identiche in tempo reale. Nella replica asincrona entra in gioco il controller dell’array, su cui torneremo più avanti, che deve riuscire a gestire una cache superiore. L’adozione di sistemi di snapshot più innovativi, fra l’altro, oggi permette di copiare a intervalli regolari i volumi di dati memorizzati e non richiede spazio supplementare. Con il vantaggio di non avere alcun impatto sulle prestazioni del sistema neanche nelle fasi di testing comprese in un piano di disaster recovery (si veda a tal proposito il paragrafo conclusivo sulle sicure snapshot).
Tecnica mista
La tecnica mista si fonda sulla selezione dei sistemi e dei dati, tra quelli critici e non-critici, per i quali approntare una copia sincrona e una asincrona. In questo modo, anche in caso di disastro esteso, i critical data non vengono intaccati.
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.
Sicurezza negli array: i sistemi di crittografia hardware
Per garantire la protezione dei dati e mantenerli sicuri negli array, esistono dei sistemi di crittografia hardware all’interno dell’unità stessa. Analogamente ai motori di machine learning, che sono integrati nell’infrastruttura storage, l’hardware encryption è parte integrante dell’unità. Con il beneficio che le procedure di scrittura risultano meno rallentate, come avverrebbe invece se ci fosse una crittografia software aggiuntiva. Inoltre, cercare di violare i codici di autenticazione è praticamente impossibile, visto che la crittografia è attiva prima ancora che qualsiasi software abbia iniziato il caricamento. Le forme più diffuse di hardware encryption vengono definite SED (Self-Encrypting Drive) e assicurano la crittografia dei dati a riposo principalmente per tutelare la sicurezza in caso di perdita di un’unità. Nonostante si tratti di un metodo consolidato se si dispone di una sola unità, questo modello ha lo svantaggio che i costi si sommano quando si aggiunge questo tipo di tecnologia a tutte le unità del data center aziendale. I SED hanno anche il limite di crittografare i dati solo quando raggiungono l’unità.
L’evoluzione dell’hw encryption basata su controller
Sul mercato, per ovviare ai problemi appena accennati, sono comparse soluzioni più evolute proposte da alcuni vendor in cui la crittografia è basata su controller (CBE, controller-based encryption). In questo caso, la protezione dei dati prevede la crittografia lungo tutto il percorso, dall’interfaccia PCIe (Peripheral Component Interconnect Express) fino all’unità, ivi compresi i cavi e la cache di scrittura con backup flash. Il funzionamento del CBE contempla che per ogni unità venga generata una chiave o DEK (data encryption key) con cui crittografare/decodificare i dati man mano che vengono inviati all’unità. Solitamente l’algoritmo utilizzato dalle chiavi DEK adotta la cifratura a blocchi AES (Advanced Encryption Standard) a 256 bit, cioè lo standard di riferimento riconosciuto dall’agenzia governativa americana National Institute of Standards and Technology. Anche se nel GDPR non è specificato lo standard di cifratura che occorre implementare nelle aziende ai fini della protezione dei dati, l’AES risponde de facto ai requisiti genericamente indicati nell’art. 32 del provvedimento europeo in materia di privacy e gestione dei dati personali.
Secure snapshot per la qualità e integrità dei dati
L’altra misura posta a presidio della qualità e dell’integrità dei dati presenti negli array è quella rappresentata dalle secure snapshot. Come noto, la “fotografia istantanea” è un servizio di replica dei dati che serve a preservare il file system del disco e la memoria di sistema e, quindi, a impedire l’eliminazione accidentale o malevola dei dati. Le secure snapshot, perciò, consentono di recuperare l’ambiente contro attacchi ransomware e altre minacce. Si tratta di una forma di protezione locale che, per essere efficiente, necessita della giusta compressione in termini di spazio. Per questo oggi tende a essere associata a paradigmi di thin provisioning che, a differenza del provisioning tradizionale, è in grado di ottimizzare l’utilizzo dello storage, riducendo nel contempo il consumo energetico. In questo modo la deduplica e la compressione in linea non hanno alcun impatto sulle prestazioni, possono essere utilizzate con tutti i data service e vengono attivate o disattivate dall’applicazione. Gli utenti, da parte loro, possono assegnare nomi per identificare le snapshot e impostare date di scadenza automatiche su ciascuna di esse. In più, le secure snapshot locali efficienti cosiddette “a impatto zero” non solo possono essere adoperate per la protezione locale e il ripristino, ma servono anche a supportare altri casi d’uso quali, per esempio, sviluppo e test, analisi, backup e applicazione di patch.
