La Storage Networking Industry Association (SNIA) definisce la protezione continua dei dati (CDP) come “una metodologia che rileva o tiene traccia costantemente delle modifiche dei dati e memorizza i relativi cambiamenti indipendenti, permettendo il ripristino in un qualsiasi momento nel passato.
Le modifiche dei dati vengono continuamente monitorate… conservate in un luogo separato … e i recovery point object (RPO) sono arbitrari e non devono essere definiti in anticipo rispetto al recovery attuale”.
Da notare che nelle definizione sopra non si vede mai la parola “snapshot“. Nonostante gran parte degli attuali software per la protezione continua dati permettano agli utenti di creare punti di ripristino noti in anticipo, questi non sono richiesti. Per essere considerato tale un sistema, la protezione continua dei dati deve poter effettuare un recovery di qualsiasi punto nel tempo, non solo quando vengono presi gli snapshot.
Come funziona un sistema di CDP
I sistemi di CDP partono da un data tap. I dati destinati allo storage primario sono “divisi” in due percorsi: ogni informazione scritta viene inviata alla destinazione effettiva ma anche al sistema di protezione continua dei dati.
Il data tap può essere un agente nell’host protetto oppure può risiedere da qualche parte nella rete di storage. Facendo girare un agente in un host, il data tap ha un impatto minimo (o addirittura nessun impatto) sul sistema host perché “il grosso del lavoro” è fatto da qualche altra parte.
I prodotti per la protezione continua dei dati che consentono di inserire il data tap nella rete di storage possono utilizzare sistemi di archiviazione progettati proprio a tale scopo, come Storage Application Services API di Brocade, la linea MDS di Cisco Systems e il suo Service SANTap o Clarion di EMC, che include la funzionalità di splitter (ovvero la possibilità di dividere in due i percorsi di storage). Alcuni sistemi CDP offrono la possibilità di scegliere dove posizionare i data tap.
Gli utenti devono quindi definire un gruppo consistente di volumi e di host che devono essere ripristinati a un medesimo punto nel tempo. Alcuni sistemi per la protezione continua dei dati consentono la creazione di un “gruppo di gruppi”, che riunisce i gruppi più coerenti, creando più livelli di granularità senza particolari sacrifici. Gli utenti possono anche scegliere di effettuare snapshot a livello di applicazione sugli host protetti, attraverso l’esecuzione di Oracle in modalità backup o di snapshot Volume Shadow Copy Service (VSS) su Windows. (ricordate: gli snapshot non sono obbligatori.)
Alcuni sistemi CDP semplicemente registrano questi snapshot a livello di applicazione quando sono attivati, mentre altri forniscono l’assistenza necessaria affinché ciò avvenga. Risulta particolarmente comodo che il sistema per la protezione continua dei dati mantenga un registro centralizzato degli anapshot a livello di applicazione, perché questi possono essere molto utili.
Ogni scrittura è trasferita sul primo dispositivo di recovery, che in genere è un altro appliance o array di storage posizionato da qualche altra parte all’interno del data center. Questa vicinanza ai dati che devono essere protetti consente a quanto viene scritto di essere replicato in modo sincrono o asincrono in un breve lasso di tempo.
Anche se un sistema per la protezione continua dei dati supporta la replica sincrona, la maggior parte degli utenti opta per la replica asincrona per evitare qualsiasi impatto sulle prestazioni del sistema di produzione.
Un sistema CDP può supportare una modalità di replica adattativa, dove la replica viene effettuata in modo sincrono quando possibile, ma di default opera in modalità asincrona durante i periodi di intensa attività.
I dati vengono memorizzati in due posizioni: il volume di ripristino e il recovery journal.
Nel primo caso, si ha la copia replicata del volume che deve essere protetto che sarà usata al posto di tale volume durante un’operazione di ripristino.
Il recovery journal prevede invece il log di tutte le attività di scrittura nell’ordine in cui sono state eseguite sul volume protetto; viene utilizzato per far “scorrere” il volume di ripristino in avanti o indietro nel tempo durante un recovery. Può anche essere utilizzato come un buffer ad alta velocità in cui tutte le attività di scrittura sono memorizzate prima di essere applicate al volume di recupero.
Questa architettura permette usare uno sistema economico di storage come volume di ripristino di essere uno storage poco costoso purché il recovery journal utilizzi un’archiviazione veloce almeno quanto quella del volume protetto.
Una volta che i dati sono stati copiati sul primo dispositivo di recovery, possono essere poi replicati off-site. A causa del comportamento dei link della WAN, il sistema CDP deve far fronte a variazioni nella larghezza di banda disponibile, quindi deve essere in grado di “andare oltre” e “adattarsi” quando tali condizioni cambiano. Con alcuni sistemi è possibile definire un ritardo di tempo accettabile (da pochi secondi a un’ora o più), che si traduce nell’RPO del sistema replicato.
Il sistema di CDP invia tutte le attività di scrittura come un batch di grandi dimensioni. Se un singolo blocco è stato modificato più volte durante un certo periodo di tempo, è possibile specificare che solo l’ultima modifica sia inviata tramite un processo noto come “write folding“. Questo significa ovviamente che la copia del disaster recovery non avrà lo stesso livello di granularità di ripristino del sistema on-site, ma può anche rappresentare la differenza tra un sistema che funziona e uno che non funziona.
I moderni sistemi per la protezione continua dei dati offrono built-in anche un’alternativa di storage a lungo termine. È possibile selezionare un intervallo di tempo breve (per esempio, dalle 12:00:00 alle 12:00:30 di ogni giorno) e dire al sistema CDP di prendere solo i blocchi di cui ha bisogno per mantenere i punti di ripristino e di eliminare il blocchi che sono stati modificati. Per motivi di coerenza, gli utenti che prendono snapshot a livello di applicazione in genere li coordinano in modo che coincidano con i punti di ripristino.
L’eliminazione dei cambiamenti estranei consente al sistema CDP di conservare i dati per periodi di tempo molto più lunghi. In questo caso, è anche possibile eseguire il backup su nastro di uno di tali punti di ripristino e poi cancellarlo dal disco.
Molte aziende utilizzano tutti e tre gli approcci: la conservazione di tutte le modifiche per alcuni giorni, i punti di ripristino orari per una settimana o poco più e i punti di ripristino quotidiani, seguito della copia su nastro dopo una novantina di giorni.
Protezione continua dei dati e recovery
Il vero punto di forza della protezione continua dei dati è il modo in cui viene gestito un recovery. Un sistema CDP può istantaneamente presentare un logical unit number (LUN) a qualunque applicazione abbia bisogno di avvalersene per il recupero o il test, scorrendo avanti o indietro nel tempo fino a trovare il punto desiderato. (Come è noto, molti utenti scelgono di riportare il volume di ripristino al punto in cui hanno creato un’immagine coerente dell’applicazione. Anche se questo comporta la perdita di qualsiasi differenza tra tale punto e la situazione attuale, molti preferiscono ritornare a un’immagine conosciuta e affidabile, piuttosto che avviare un processo di recupero a fronte del crash del sistema.)
A seconda del prodotto, il LUN di recovery può essere l’effettivo volume recuperato (scorso avanti o indietro), un volume virtuale progettato principalmente per il test di un ripristino, o qualcosa che sta in mezzo ai due, in cui il volume di ripristino è presentato all’applicazione come se fosse già stato fatto scorrere avanti o indietro, mentre in realtà tale scorrimento sta avvenendo in background. Alcuni sistemi possono presentare contemporaneamente più punti nel tempo dello stesso volume di ripristino.
Una volta che il sistema di produzione originale è stato riparato, il processo di recupero viene invertito. Il volume di recovery è utilizzato per ricostruire il volume di produzione originale replicando i dati di nuovo nella loro posizione originale. (Se il sistema si fosse semplicemente bloccato, e quindi non aveva bisogno di essere sostituito, in genere è possibile solo aggiornarlo fino al punto attuale tramite l’invio delle sole modifiche che si sono verificate dopo l’interruzione.) Con il volume originale aggiornato, l’applicazione può essere riportata nella sua posizione originale e la direzione di replica invertita.
Se confrontate questa descrizione di uno tipico scenario di recovery CDP-based con il processo di recovery richiesto da un tradizionale sistema di backup dovreste avere una buona idea del motivo per cui la protezione continua dei dati è il futuro del backup e del recovery.
