CENNI DI CONTINUITA’ OPERATIVA E DISASTER RECOVERY - Parte Prima

Autore: Massimiliano Traspadini

INTRODUZIONE

In quest'articolo, descrivo il servizio di Disaster Recovery come soluzione per la Continuità Operativa, secondo le esperienze professionali, tecniche e di gestione, maturate durante gli ultimi 10 anni presso un importante datacenter di Disaster Recovery.

L’argomento verrà suddiviso in tre parti, corrispondenti ciascuna a un articolo.

Dopo alcune fondamentali definizioni introduttive relative alla Continuità Operativa, nella prima parte viene presentato il Disaster Recovery, descrivendo gli scenari di disastro e le sue caratteristiche basilari e qualificanti, dal sito di recovery all’importanza del backup.

La seconda parte introduce la storia del DR a partire dalla sua nascita negli anni ’60, attraverso l’evoluzione a servizio personalizzato sulle peculiarità e criticità di ciascun cliente, fino alle radicali modifiche introdotte dall’avvento di Internet, del Cloud e della tragedia 11 settembre 2001 e analizza l’evoluzione degli scenari di ripristino negli ultimi anni.

La modalità di ripristino physical to physical, P2P, physical to virtual, P2V, virtual to virtual, V2V, i rispettivi vantaggi e problematiche, sono oggetto della terza parte dell’articolo.

INDICE - Parte Prima

1. Continuità Operativa
2. Disaster Recovery
3. Alta affidabilità
4. Possibili scenari di disastro
5. Sito di Disaster Recovery
6. Replica dati per Disaster Recovery
7. Backup
8. Strategie di Disaster Recovery
9. Piano di Ripristino
10. Test di Disaster Recovery
11. Processo di Disaster Recovery

1. CONTINUITA' OPERATIVA

I paragrafi seguenti illustrano il concetto di continuità operativa, articolata nelle soluzioni di alta affidabilità e, soprattutto, disaster recovery.

E’ opportuno ricordare quanto prevede la legislazione italiana riguardo la necessità di un servizio di disaster recovery.

Il Decreto Legislativo 30 giugno 2003, n. 196 "Codice in materia di protezione dei dati personali “Titolo V - SICUREZZA DEI DATI E DEI SISTEMI - CAPO I - MISURE DI SICUREZZA - Art. 31 (Obblighi di sicurezza) e Art. 34 - Trattamenti con strumenti elettronici” recita:

“I dati personali oggetto di trattamento sono custoditi e controllati, anche in relazione alle conoscenze acquisite in base al progresso tecnico, alla natura dei dati e alle specifiche caratteristiche del trattamento, in modo da ridurre al minimo, mediante l'adozione di idonee e preventive misure di sicurezza, i rischi di distruzione o perdita, anche accidentale, dei dati stessi, di accesso non autorizzato o di trattamento non consentito o non conforme alle finalita' della raccolta.”

La Continuità Operativa (Business Continuity, BC) viene così definita dallo standard BS25999:

“La Continuità Operativa è la capacità di un’organizzazione di pianificare e rispondere a incidenti e a distruzioni e di continuare ad operare ad un livello accettabile e prestabilito”. 

“Incidenti” e “distruzioni” sono termini che possono comprendere guasti limitati e locali, per esempio localizzati sull’infrastruttura di rete, oppure Storage Area Network, SAN, in un data center, oppure disastri di scala e impatto maggiori, quali alluvioni, terremoti, incendi, attacchi informatici, ecc.

Di seguito, vengono riportati alcuni esempi di noti eventi di disastro:

Nel grafico seguente, invece, risulta evidente la frequenza delle varie tipoligie di evento disastroso, riferita alle rispettive conseguenze espresse come danno in €.

 A causa dell’ampio ventaglio di possibili cause di un disastro, non esiste un’unica soluzione ottimale che garantisca la continuità operativa.

Due, infatti, sono le categorie di soluzioni possibili:

• disaster recovery, attua il ripristino di funzionalità e servizi a seguito di un evento di disastro, minimizzando la perdita di dati;
• alta affidabilità, garantisce l’eliminazione di ogni “single point of failure”, SPoF, nell’infrastruttura hardware e nell’architettura software ed annulla la perdita di dati.

2. Disaster recovery, DR

Il disaster recovery, DR, comprende un insieme di risorse e procedure atte al ripristino di servizi dopo un evento di disastro.

Il disastro è definibile come evento inaspettato, che disturba e/o interrompe il normale flusso di elaborazione dati per un intero data center, oppure per almeno un insieme di server che, collettivamente, forniscono servizi informatici.

Il ripristino dei servizi di una parte oppure dell’intero data center avviene presso il sito di produzione, detto primario, se il disastro è limitato, non permanente e non distruttivo. Ad esempio, la perdita di connettività di tutta la rete per un periodo lungo di tempo può essere intesa come evento di disastro.

Il ripristino del servizio infrastrutturale può essere garantito trasferendo ogni funzionalità verso un sito di disaster recovery, attraverso un’operazione detta failover, qualora l’evento sia di dimensioni ed impatto più ampie.

Quando il sito primario viene ripristinato al termine delle attività di recovery, le funzionalità tornano su di esso attive, con l’operazione di failback, reciproca della precedente.

Il sito di disaster recovery deve rispettare determinati requisiti, quali la distanza di sicurezza dal sito originario, per non essere coinvolto nel medesimo disastro; oppure, la dotazione di risorse hardware sufficienti a sostenere il carico dei sistemi del sito originario a seguito del failover.

Le risorse presso il sito di recovery devono necessariamente essere multipiattaforma ed in grado di coprire tutti i servizi possibili. Sono, quindi, presenti risorse Intel/VMware, AS400, Mainframe, AIX systems, storage, tra loro interconnessi da apparecchiature rete e SAN.

Il sito di recovery, può essere direttamente gestito dal proprietario del sito primario, oppure, più frequentemente, può essere parte di un’infrastruttura condivisa, “shared”, controllata da terze parti.

In questo caso, il sito è strutturato e dimensionato per garantire il ripristino contemporaneo di più siti di produzione cliente.

Le perdite di dati vengono annullate attraverso il ripristino da backup, oppure dalla messa in linea dei dati replicati.

Il tempo di ripristino, infine, comprende il tempo per risolvere il problema hardware e software, aggiunto a quello per acquisire la configurazione da backup e quello, infine, di ripristino di tale configurazione.

Lo schema seguente illustra quanto finora descritto.

In evidenza, il sito primario, con un datacenter multipiattaforma, ed il sito di ricovery, gestito da un provider, in cui alcune risorse “shared” vengono assegnate al cliente in disastro, oppure in DR test.

Il failover, inoltre, viene mostrato attivabile da replica dati, oppure, con trasporto dei nastri di backup e successivo ripristino.

 

3. Alta affidabilità (High Availability, HA)

L’alta affidabilità esprime ridondanza hardware e software, che permette continuità di servizio a seguito di un disastro.

Infatti, idealmente, istanze multiple delle risorse garantiscono che le medesime risorse, e i servizi ad esse collegati, siano sempre operative.

La configurazione dell’alta affidabilità è definita “attivo/attivo”, se la ridondanza software è contemporaneamente attiva su più di un dispositivo hardware. In questo caso, l’hardware disponibile in un dato momento deve garantire prestazioni adeguate e sufficienti.

Nell’approccio alternativo “attivo/passivo” la componente ridondante non è in uso, ma in standby, durante le operazioni consuete, e viene attivata solo in caso di fallimento dell’istanza di default.

Esempi di ridondanze per alta affidabilità sono Microsoft clustering (attivo/passivo), oppure sistemi storage RAID (attivo/attivo).

 Un evento di disastro è un singolo fallimento, oppure una combinazione di fallimenti contemporanei, che può coinvolgere tutte le risorse ridondate, superando il concetto di “single point of failure”, SPoF, ed in contrasto con l’alta affidabilità.

Il disastro, infatti, comprende sia il mancato accesso ai dati, che la perdita permanente dei medisimi. In quest’ultimo caso, quindi, la riattivazione delle risorse e dei servizi può avvenire con ripristino, presso un sito diverso da quello di produzione.

 4. Possibili scenari di disastro

Gli eventi di disastro possono comprendere sia cause naturali, che errori umani, non strettamente in ambito tecnologico.

Alcuni disastri naturali che possono interrompere temporaneamente e permanentemente le attività e i servizi del sito primario sono:

• alluvioni,
• terremoti,
• incendi,
• cicloni e tornado.

 Disastri, invece, riconducibili ad azioni umane sono:

• incidenti in lavori infrastrutturali (taglio accidentale del cablaggio rete e di alimentazione),
• guerre,
• incendi,
• fallimenti del sistema software,
• errori umani (cancellazione di dati importanti),
• sabotaggi.

5. Sito di disaster recovery

Molteplici sono le possibili scelte della locazione di un sito di recovery, differenziate dai costi richiesti, in particolare:

• Acquisto di nuovo hardware, secondo le caratteristiche del sito primario, e ripristino dei dati dati da backup su nastro. In questo caso, i costi sono ridotti alla gestione del backup (server, librerie, nastri, trasporto offsite). Il tempo di ripristino, però, può essere molto lungo e, di conseguenza, le grandi compagnie optano per scelte alternative più costose ma performanti.
•  Affido della continuità di servizio a un provider. Il contratto stipulato con quest’ultimo specifica le caratteristiche hardware e software delle risorse fornite in caso di disastro e le condizioni per accedervi e farne uso: frequenza dei test di failover, requisiti per la dichiarazione di disastro, durata d’uso delle risorse durante il disastro. Il sito di recovery è, in questo caso, gestito dal provider e permette il ripristino sia da nastro su risorse “shared” e in uso solo durante il disastro, che da storage replicato su risorse dedicate, attive sempre per garantire la consistenza della replica. In quest’ultimo caso, inoltre, i costi sono superiori e il cliente è realmente proprietario delle risorse dedicate. Il provider che gestisce un sito di recovery di grandi dimensioni può prevedere una priorità in caso di disastro di più clienti contemporaneamente.
•  Acquisto di un sito di recovery nella medesima area metropolitana di quello primario, oppure lontano dal primario. Si tratta delle due soluzioni più costose, ma gestite integralmente dall’azienda proprietaria e con i vantaggi più significativi: tempi di ripristino minimali con replica, uso del sito di recovery senza termini di tempo, massima flessibilità nella pianificazione dei ripristini. L’uso, però, di un sito di ripristino nella medesima area metropolitana di quello primario non corrisponde a “best practices”, poichè un evento di disastro catastrofico coinvolgerebbe entrambe le strutture annullando la continuità operativa. Ne consegue, che la soluzione ottimale è un sito di recovery molto lontano dal primario, tipicamente 650 km.

 La realizzazione di un sito di recovery richiede un’analisi che verta su differenti ambiti con la dovuta precisione, in particolare:

• Configurazione hardware: le risorse hardware del sito di recovery non devono essere esattamente uguali a quelle di produzione, ma supportare la medesima versione del software attivo in produzione e garantire pretazioni tali da gestirne il carico; identica compatibilità deve vigere tra i dispositivi storage SAN/NAS di produzione e di replica.
• Configurazione software: il software attivo presso il sito di recovery mantiene la medesica versione di quello di produzione.

6. Replica dati per disaster recovery

La replica dati è una tecnica che porta in continuità i dati correnti (o quasi) dal sito primario a quello di recovery.

Sono disponibili quattro modalità realizzative per la replica, che si differenziano per il livello al quale la replica è condotta all’interno dello stack hardware/software, in particolare:

• Application level. Disponibile per i database, è implementata con un’instanza sul sito primario ed una sul sito di recovery. L’istanza remota è sempre consistente è può essere avviata rapidamente, in caso di failover.
• Host level. Implementa un livello software in esecuzione sul sistema operativo del server replicato, che può lavorare a livello di file, la cui versione modificata viene copiata sul sito remoto alla chiusura del file stesso, e a livello di blocco, in cui ciascun blocco viene contemporaneamente scritto sul sito primario e sul quello di recovery.
• Storage level. In questo caso, la replica è gestita dal dispositivo storage stesso ed è eseguita a livello di blocco.
• Network level. Simile alla precedente, ma controllata da dispositivi in SAN.

 La replica a livello di blocco può essere sincrona, oppure asincrona.

La replica sincrona indica che, nel caso d’esempio di storage level, prima che il dispositivo storage invii al sistema operativo sorgente il risultato di una scrittura di blocco, scrive anche il medesimo blocco sul corrispondente dispositivo remoto, con esito di commit.

La replica sincrona assicura potenzialmente la perdita dati nulla.

In realtà, questo non avviene, poichè la perdita può avvenire durante il controllo di consistenza del file system e dell’applicazione.

Si indica con la latenza il tempo impiegato da ciascun pacchetto per attraversare la rete dal sito primario a quello di recovery, compreso il tempo di elaborazione nel dispositivo hardware (es. storage) e del sistema operativo.

La latenza causa, comunque, un tempo di scrittura remota di un singolo blocco molto superiore a quello della scrittura locale.

 In contrasto con quella sincrona, la replica asincrona implica, che, ad ogni scrittura di blocchi sullo storage del sito primario, una richiesta di scrittura del medesimo blocco venga accodata sul sito di recovery.

Al termine della replica del blocco, una risposta viene inviata al sistema operativo sorgente, così da non bloccare il processo computazionale del software in scrittura.

 

7. Backup

Il backup possiede un ruolo fondamentale del piano di disaster recovery.

Infatti, la replica dei dati verso il sito di recovery, pur essendo una forma di backup, non può esserne il sostituto per differenti motivi, quali:

• Consistenza

La replica a livello di blocco disco non garantisce che il dato replicato presso il sito di recovery sia sempre consistente. Le inconsistenze possono manifestarsi sia a livello di file-system, che applicativo. Tale limite viene, però, tollerato, poichè la replica consente un ripristino più recente di qualsiasi backup. In realtà, al momento della dichiarazione di disastro, è possibile che il sistema storage di recovery non possa essere attivato, rendendo fondamentale l’accesso al backup per garantire il ripristino del sito di produzione.

• Ripristino a timestamp multipli

La replica è la soluzione ideale se i dati persi sono i più recenti possibili, ma non è efficace a fronte di altre situazioni, quali la cancellazione accidentale di dati. In questo caso, infatti, la replica estende il danno anche al sistema storage di recovery ed in nessun modo è possibile procedere al ripristino.

•  Costi

I costi per garantire efficaci politiche di backup sono nettamente inferiori a quelli per realizzare un’infrastruttura di replica.

Infatti, solo le grandi aziende sono in grado di investire in soluzioni di recovery con replica, soprattutto se devono essere gestite grandi quantità di dati.

In realtà, “best practices” per un efficiente recovery indicano l’obbligo di backups regolari e che coprono timestamp multipli.

I backups vengono archiviati su nastro, per essere trasportati e conservati presso un sito lontano da quello primario, poichè sarebbero coinvolti nel medesimo evento di disastro che blocca la produzione.

Inoltre, è necessaria una politica di retention, basata sulle caratteristiche e necessità della infrastruttura di produzione, in termini di tempo di ritention, regole di archiviazione, formato dati, encryption.

Esistono tre modalità di backup: cold oppure offline, warm, e hot.

• Il cold/offline backup è condotto con tutte le componenti di sistema ferme. In questo modo, file, metadati e configurazioni possono essere considerati stabili e consistenti. Le condizioni ottimali, quindi, per l’avvio di cold backup prevedono tutti gli utenti disconnessi dal sistema, tutti i processi front/backend ed i database fermi.
• Durante il warm backup, invece, i prerequisiti precedenti non sono necessari, ad eccezione della limitazione di alcune funzionalità che potrebbero rendere la configurazione del backup troppo complessa, oppure provocare inconsistenza tra file e metadati. Ad esempio, la sospensione dei privilegi di scrittura in un database. Al termine del backup, naturalmente, tali privilegi vengono riattivati, permettendo la scrittura della cache nel database.
• Solo un hot backup permette, infine, che ogni attività, funzionalità e servizio possa continuare senza interruzioni e limitazioni. Essendo di complessa attuazione, i software di backup e gli applicativi stessi forniscono appositi moduli che gestiscono questa modalità.

 Il backup non richiede necessariamente la copia completa di file, metadati, configurazioni e indici full-text.

Ne conseguono diversi approcci al backup, secondo le specifiche esigenze.

I principali sono i seguenti:

Full backup

Comprende la copia di tutti i file di uno determinato percorso storage, riferita ad uno specifico stato (indicato per esempio, con l’archive bit per i savesets di Symantec Enterprise Vault in regime di backup con Symantec NetBackup), all’ultima data di modifica, oppure di creazione.

Backup incrementale

In quest’approccio, vengono copiati solo i file modificati a partire dall’ultimo backup, se quest’ultimo è stato di tipo full, oppure incrementale.

Il vantaggio derivante è il ridotto carico nel trasferimento dagli host al backup server sulle infrastrutture rete e SAN e la contenuta occupazione di spazio storage. Si sottolinea, che quest’ultimo aspetto è condizionato anche dalla politica di retention.

Il backup incrementale è svantaggioso, invece, durante il ripristino, poichè quest’ultimo deve partire dall’ultimo full, che, sequenzialmente, viene aggiornato con gli incrementali.

 Backup differenziale

In apparenza simile al backup incrementale, il differenziale, detto anche delta backup, copia solo i file modificati dall’ultimo full backup.

La differenza tra i due approcci è che, durante il restore, il backup differenziale richiede l’ultimo full e solo l’ultimo differenziale, mentre l’incrementale necessità anche della sequenza di incrementi dal full alla modifica più recente.

In tempo di ripristino da backup differenziale è, quindi, il più ridotto.

 

8. Strategie di Disaster Recovery

La scelta di un’ottimale strategia di disaster recovery richiede l’equilibrio tra costi e servizi, la cui relazione è mostrata nella sottostante figura:

L’affidabilità viene articolata in livelli caratterizzati dalle soluzioni, hardware e software, che ne incrementano l’efficacia.

Ovviamente, strategie migliori richiedono costi più alti.

Il primo passo nella pianificazione di tale strategia consiste nella definizione dei valori di Recovery Point Objective, RPO, e Recovery Time Objective, RTO.

RPO rappresenta la quantità massima di dati che un flusso di dati può perdere a seguito di un evento di disastro. E’ espresso in termini di tempo come intervallo massimo tra la produzione del dato e la sua messa in sicurezza.

RTO, invece, è la quantità di tempo che intercorre tra l’evento di disastro ed il momento in cui il ripristino si conclude completamente e correttamente.

Questi due valori sono fissati dalle caratteristiche e necessità del servizio che deve essere garantito e da essi consegue la strategia di disaster recovery.

In generale, la prima linea di difesa è un’efficace politica di backup, come discusso nei paragrafi precedenti.

In aggiunta al backup, la maggioranza delle strategie prediligono l’implementazione di soluzioni di alta affidabilità, prima di considerare sistemi di replica, poichè la probabilità di fallimento di una singola componente hardware oppure software è più elevata di quella che implica il collasso di un intero data center.

Inoltre, backup regolari coprono l’eventuale perdita di dati, pur essendo inefficaci nel ripristino di dati presti nell’intervallo tra l’ultimo backup e l’evento di disastro.

In effetti, solo flussi dati con stringenti valori di RPO attuano strategie con replica dati, pur richiedendo costi notevolmente più elevati.

 

 9. Piano di ripristino (Disaster Recovery Plan, DRP)

Il piano di ripristino, DRP, è il documento formale ed ufficiale che descrive l’architettura dell’ambiente di produzione e di recovery e tutte le procedure che devono essere attuate per ripristinare i servizi del sito di produzione.

E’ parte di un piano di continuità operativa, BCP (Business Continuity Plan), che è riferito alla conitnuità dell’insieme dei servizi di business.

Il documento comprende tutte le piattaforme infrastrutturali di produzione, quindi: server (Windows ed ESX VMware), AS400, Mainframe, AIX systems, network, storage, SAN.

Le procedure di ripristino, invece, sono costituite dai passi necessari al failover dei servizi e dati di produzione e alla loro successiva attivazione sul sito di DR.

DRP elenca, inoltre, i team coinvolti nelle attività, tecnici, amministrativi e logisitici, e specifica le responsabilità dei singoli attori.

E’ prevista anche un’appedice di change-management. E’ frequente, infatti, l’aggiornamento delle soluzioni infrastrutturali e l’ottimizzazione delle procedure, soprattutto a seguito dei test di DR.

 

10. Test di Disaster Recovery

Dopo aver dimensionato e predisposto un sito di recovery e configurato e avviato la replica dati, è obbligatorio verificare, se realmente tale sito è in grado di sostituire quello primario con il failover.

Ne consegue la necessità di svolgere test periodici, solitamente ogni 12 mesi, presso il sito di recovery.

Durante il test, vengono verificate correttezza ed efficacia del piano di ripristino nelle sue fasi seguenti:

1. allestimento risorse “shared” presso il sito di recovery secondo il perimetro contratturale, oppure un sottoinsieme di esso oggetto di test,
2. verifica consistenza dei dati di replica e/o attivazione backup server;
3. ripristino sistemi operativi, dati e applicativi, da backups oppure con replica dati;
4. switch rete, failover servizi e test applicativi;
5. failback e conclusione test.

 

Numerosi test possono essere necessari per raggiungere procedure che si concludono con successo.

E’ da sottolineare, infatti, che obbiettivo del test non è soltanto e semplicemente il rispetto di SLA, soprattutto temporali, quanto la verifica, la correzione ed il miglioramento del piano di ripristino e delle sue procedure.

E’ richiesto, infatti, durante il test di disaster recovery la presenza del project manager sia del provider, che del cliente.

 

11. Processo di Disaster Recovery

Dall’evento di disastro, le operazione di failover e failback dovrebbero essere il più possibile automatizzate, attraverso l’esecuzione di programmi e scripts.

Dove l’automatismo non è attuabile, una checklist raccoglie ogni operazione sequenziale e il pool di quelle parallelizzabili.

Tale checklist possiede un ruolo fondamentale nel piano di riprisitino.

Il vantaggio dell’automatismo, però, risulta evidente proprio durante l’evento di disastro, poichè riduce i tempi di ripristino e, soprattutto, minimizza l’errore derivabile dall’azione umana, certo più frequente in una situazione anomala come è, in effetti, il disastro.

In realtà, poichè ciascun disastro possiede caratteristiche proprie, molte imprese non scelgono processi di failover completamente automatizzati.

Soprattutto l’avvio del disaster recovery non può essere automatizzato, poichè è molto difficile trovare un evento che sia totalmente imputabile al disastro e che indichi in modo inequivocabile l’avvento.

Ad esempio, l’interruzione del link di rete tra il sito primario e quello di disaster recovery, che avvia il processo di ripristino, non necessariamente è dovuto ad un evento di disastro, ma può essere causato problematiche estranee al sito primario.

Di conseguenza, il processo di disaster recovery è avviato da una dichiarazione di disastro, trasmessa a mezzo di fax, telefono, mail.

Dalla dichiarazione di disastro, i fondamentali passi del processo di recovery e failover sono i medesimi descritti nel piano di ripristino e verificati durante i test, dall’allestimento delle risorse al failback.

(Continua nella Parte Seconda)