Tecnologie DR

Tecnologie di Disaster Recovery: Journal o Delta?

Non esiste una scelta universalmente giusta quando ci si trova di fronte a due tecnologie per il disaster recovery come Journal e Delta. Valutando i pro e i contro di entrambe si può comprendere quando e come usarle senza scordare di valutarne gli impatti economici

22 Dic 2021

I VMware Cloud Provider offrono servizi di Disaster Recovery e di backup e ripristino utilizzando diverse tecnologie che vengono spesso confrontate per valutare benefici e svantaggi di ognuna. Per il Disaster Recovery ci sono due le tecnologie chiave da utilizzare per replicare i dati: journaling e snapshot. Hanno entrambe pro e contro da approfondire e analizzare anche per sfatare alcuni falsi miti che le riguardano.

In primo luogo, cosa sono gli snapshot?

Gli snapshot sono un point in time  dello status e dei dati di una macchina virtuale (VM), non dovrebbero essere considerati un backup. Nello status è indicato lo stato di alimentazione della VM al momento dello snapshot e i dati includono tutti i file e le cartelle che la costituiscono, compresi gli elementi dei file della VM come la memoria e la vNIC, vmdk ecc. Solitamente questo si ottiene con la quiescenza o con uno stunning della VM che la rende temporaneamente non disponibile per operazioni come vMotion, snapshot, ecc. e irraggiungibile, il che implica che si verifichi un’interruzione dell’applicazione

Va considerato sempre lo ‘status’ di una replica: se il sistema operativo non supporta la quiescenza diventa fondamentale curare attentamente il processo di recupero in caso di disastro per garantire la continuità per il tipo di applicazione in oggetto.

Perché non dovrebbero essere considerati un backup? Semplicemente perché gli snapshot sono utili solo per un rollback veloce, visto che registrano principalmente il delta tra il disco sorgente originale da un certo punto nel tempo e richiedono che il genitore sia sulla stessa infrastruttura di archiviazione. I backup devono essere separati e interi (non dipendenti dal genitore) e non devono assolutamente essere sulla stessa infrastruttura che stanno proteggendo. Gli snapshot sono quindi intrinsecamente a breve termine.

VMware Cloud Director Availability usa gli snapshot?

No, usa vmdk Delta alla sorgente e istanze Point in Time (PIT) alla destinazione: una scelta diversa dagli snapshot. I Point in Time multipli (PIT), mPIT, si basano sui delta del disco di origine, questi vengono inviati tramite l’agente Host Based Replication (HBR) IO Filter sull’host ESXi. VMware Cloud Director Availability si differenzia anche perché non fa lo stunning della VM per replicare l’origine.

vSphere Replication, ha diversi componenti che sono utilizzati da VMware Cloud Director Availability: il Data Mover e i servizi Host Based Replicator (HBR) sugli host ESXi che essenzialmente filtrano l’IO dalla VM in esecuzione al lightweight delta sync, che viene poi replicato al sito di destinazione tramite un Replicator Appliance. Si possono avere più PITS (mPITS), vSphere Replication supporta infatti 24 istanze – cioè 23 lightweight delta dalla sincronizzazione iniziale prima che compiano il ciclo e siano sovrascritti.

Per la sincronizzazione iniziale, solo le aree scritte del disco “base” della VM sono contrassegnate come “sporche” e l’intero vmdk viene copiato. Questo causa un piccolo aumento dell’IO mentre il disco viene replicato, e il tempo necessario dipenderà molto dai tipi di datastore di origine e destinazione. Da questo momento in poi solo le modifiche delta sono contrassegnate come “sporche” e necessitano di una copia.

Sincronizzazione completa iniziale

Avviene quando la replica viene configurata per la prima volta utilizzando VMware Cloud Director Availability per una macchina virtuale accesa e l’intero contenuto di un disco virtuale di origine (VMDK) viene copiato sul suo disco virtuale vuoto di destinazione (che viene creato nella posizione di destinazione). Li si confronta utilizzando i checksum, un processo che identifica le differenze tra i dischi virtuali di origine e di destinazione richiedendo pochissimi cicli di CPU essendo esse pari a zero in una nuova replica. Mentre tutto ciò avviene, vSphere Replication invia periodicamente tutte le differenze identificate. Il tempo necessario per completare una sincronizzazione dipende principalmente dalla dimensione dei dischi virtuali che compongono una macchina virtuale, dalla quantità di dati che devono essere replicati e dalla larghezza di banda di rete disponibile per la replica.

Sincronizzazioni del lightweight delta

Dopo aver effettuato una sincronizzazione completa, l’agent vSphere Replication integrato in vSphere tiene traccia delle modifiche ai dischi virtuali appartenenti alle macchine virtuali configurate per la replica. Una lightweight delta sync replica queste modifiche su base regolare a seconda dell’obiettivo del punto di recupero (RPO) configurato per la replica di una macchina virtuale: i dati modificati in una macchina virtuale con un RPO di quattro ore saranno ad esempio replicati ogni quattro ore. I dati relativi a questa finestra andranno nel vmdk lightweight delta, quindi qualsiasi cosa aggiunta e rimossa entro le 4 ore non sarà nel delta. Questo comporta una riduzione del traffico di rete in quanto le scritture multiple allo stesso blocco entro l’intervallo RPO comporteranno solo l’invio dell’ultimo valore al momento della sincronizzazione. Questo tipo di pianificazione può cambiare in base a una serie di fattori che vanno dai tassi di cambiamento dei dati, al tempo richiesto da ogni ciclo di replica e al numero di macchine virtuali configurate per la replica sullo stesso host vSphere. vSphere Replication utilizza un algoritmo che considera tutti questi fattori per programmare la replica in modo da garantire che l’RPO per ogni macchina virtuale replicata non sia violato.

E per quanto riguarda le prestazioni?

Più lightweight delta sync vmdk si hanno, più i dati potenzialmente variano tra i delta, più tempo ci vorrà per ripristinare. Allo stesso modo più delta “drift” si hanno dalla base, più calcolo e storage saranno necessari per consolidare tutte le differenze, inoltre più si mantiene, più spazio su disco verrà utilizzato. Se il datastore di destinazione esaurisce lo spazio, non è possibile creare nuove istanze delta, ma le istanze esistenti non sono influenzate, poi quando si libera dello spazio viene creata una nuova istanza incrementale (anche se probabilmente con qualche violazione dell’RPO) ma senza che avvengano risincronizzazioni.

Con VMware Cloud Director Availability, si utilizzano le policy SLA per controllare ciò che è permesso dalle policy di conservazione della replica (numero di istanze PIT) e si ha un obiettivo generale di Recovery Point. Un PIT è un lightweight delta sync, cioè un vmdk delta record, ma non è un intero vmdk in quanto non c’è stato alcuno stunning o clonazione, è un sottoinsieme della catena dal disco base a un’istanza designativa ed è un vmdk piatto indipendente.

I lightweight delta sync vmdk sono a cascata e interdipendenti, ogni volta che un’istanza scade viene quindi liberato dello spazio su disco. É anche possibile ritirare le istanze esplicitamente o recuperare urgentemente spazio dopo eventi I/O insoliti che creano istanze più grandi, regolando la policy di conservazione di Cloud Director Availability. Si può poi andare a ripristinarla quando lo spazio torna disponibile. I provider possono monitorare tutti gli aspetti del consumo di IAAS e visualizzare lo storage allocato rispetto a quello utilizzato dall’organizzazione del tenant.

Istanze memorizzate: sono backup o snapshot?

Le istanze memorizzate in VMware Cloud Director Availability sono vmdk delta. Sono delta che sono stati “tolti” dal ciclo di conservazione e quindi hanno bisogno del disco genitore per essere utilizzati per un ripristino. Una replica di VMware Cloud Director Availability può avere sia istanze memorizzate che istanze ruotate (mPITS), sono controllate da delle policy e risulteranno relativamente veloci da ripristinare rispetto ai delta in corso (perché più vicine al genitore sorgente) che cresceranno (‘drift’) con il passare del tempo.

Il consolidamento dei dischi aiuta ad aumentare la velocità di recovery?

Sì e no. Il consolidamento prende in considerazione il disco base e tutti i delta, riguarda la gerarchia dei dischi e viene eseguito fino al punto di ripristino richiesto. È un’attività che richiede molto calcolo e storage per aggregare e confrontare i delta, e da quel punto in poi tutti i delta vengono creati con il disco consolidato come genitore. Per un failover, consolidare quando c’è una gerarchia di dischi di delta non sarà più veloce se ci sono molti vmdk delta da confrontare, specialmente se c’è un alto tasso di cambiamento dei dati. Tuttavia, da quel punto in poi il recupero sarà veloce perché il “drift” tra il vmdk base e il vmdk delta sarà minore. VMware Cloud Director Availability permette di forzare il consolidamento come parte del recovery, o più tardi, indipendentemente dallo stato di alimentazione della VM.

Che dire di RPO e RTO?

Alcuni fornitori dichiarano un RPO molto veloce con il journaling ed è vero quando ogni blocco di dati modificato viene scritto costantemente sul target. Perché allora usare le istanze delta? La tipica VM genera dati preziosi che devono essere replicati, usando lo split IO, per cui l’IO va in 2 punti – la VM e il target recovery delta o il journal – e c’è un RTO virtualmente nullo, finché i dati non vengono generati. I dati vengono però generati, ovviamente, visto che si sta assicurando il recupero di un workload importante, quindi ci sono poche possibilità che tale parametro rimanga fermo. A questo punto il journaling, che offre la massima granularità, aumenta considerevolmente l’RTO e più dati vengono scritti, più lungo è il recovery time objective (RTO) da consolidare.

Con gli MPIT c’è anche un impatto sull’RTO che dipende dal tempo necessario per calcolare la differenza delta tra il genitore sorgente e l’MPIT desiderato da ripristinare. Nel delta, a differenza del journaling, la maggior parte del consolidamento sarà già fatto. Più MPIT ci sono in mezzo, più lungo è l’RTO, i dati sono ancora ad un RPO granulare (VMware Cloud Director Availability supporta un RPO di 5 minuti), ma il tempo per il ripristino (RTO) è più lungo, poiché è necessario il calcolo sia nel journaling che negli MPIT per recuperare i dati.

Una best practice per i workload ad alta intensità di dati sarebbe quella di consolidare regolarmente e mantenere basso il numero di MPIT in modo che non siano mai troppo lontani dal disco base principale. Per le VM a bassa intensità di dati è possibile espandere significativamente il numero di MPIT e consolidare a rotazione come richiesto.

Un altro punto da notare sull’RPO e la generazione di dati. Quando i dati passano attraverso il filtro IO, sono diretti al datastore della VM e, a seconda della tecnologia utilizzata, a un lightweight delta vmdk o a un journal. Il percorso verso la destinazione deve essere veloce, specialmente per il journaling, e il volume di traffico sarà alto se ogni blocco di cambiamento dei dati viene scritto 24 ore su 24, 7 giorni su 7. Tuttavia, le istanze Delta vengono eseguite solo sul programma di replica, quindi il traffico è basso e il volume di dati è basso, di solito questo semplifica radicalmente il networking e rende una soluzione di implementazione e operativa molto più semplice da supportare.

La considerazione?

Velocità di recupero (RTO) e perdita di dati accettabile (RPO) per una VM

vs

Minimizzare la perdita di dati (RPO), ma aumentare il tempo di recupero (RTO)

E la rehydratation?

Anche i dati per essere accessibili e utilizzabili devono in qualche modo “essere reidratati”, quindi decompressi.

Alcuni vendor sostengono che il processo di rehydratation sia “istantaneo” ma non esiste nulla di “istantaneo” nella decompressione che utilizza il calcolo e influenza anche le prestazioni e l’utilizzo dello spazio di archiviazione su disco. Al termine si ottengono blocchi di dati messi nella loro forma originale sul disco che può essere “ottimizzato” per evitare l’impatto a lungo termine per quei fornitori che supportano il processo di rehydratation in lettura anche se questo influenzerà ancora lo spazio di archiviazione utilizzato mentre i dati sono recuperati.

Il journaling ha una rehydratation che è compute e storage intensive (imita il file system e ha bisogno di convertire i dati in formato vSphere) quindi, in sintesi, c’è un impatto sulle prestazioni quando si attua questo processo. VMware Cloud Director Availability utilizza vmdk nativo, quindi non c’è bisogno di convertire i dati in un formato vmdk, è già in questo formato e quindi è ottimizzato a priori.

E se ho bisogno del recovery più veloce dal malware?

Prima di tutto, guardiamo il recovery point. La tecnologia journaling offre una flessibilità granulare nel recovery, poiché può essere innescato da qualsiasi punto mentre i PIT sono impostati a intervalli regolari. Facciamo un esempio: se su una VM  con un RPO di 4 ore si scopre un ransomware alle 12.30 dopo l’infestazione (punto B) nel grafico sottostante.

Figura 1: Gestione progressiva di un attacco ransomware su una VM con Delta

L’infezione è stata trasmessa da un trojan alle 9 del mattino, ma non si è attivata fino alle 13, il trojan del ransomware è stato replicato nel delta sync a mezzogiorno, é quindi necessario tornare al delta delle 8, perdendo 4 ore di dati, per evitare che il ransomware sia presente. È accettabile una perdita di dati di 4 ore? Questo è l’impatto della granularità, allineato all’RPO.

Anche la velocità di recupero è importante, in questo caso ci sono diversi punti di ripristino tra cui scegliere. Si inizia con un ripristino del delta precedente, che in questo caso è un vmdk consolidato, non un delta, e quindi il confronto di calcolo rispetto ai blocchi cambiati sul delta consolidato non ci sarebbe, perché non c’è niente da confrontare. Il recovery in questo caso sarebbe veloce, ma il trojan sarebbe ancora presente. Solo tornando al delta delle 8 lo si potrebbe escludere ma questo implicherebbe un confronto sia con l’ultimo delta sia con il disco sorgente consolidato. Dato però che il volume delle modifiche delta è piccolo, ancora una volta questo sarebbe un RTO veloce: anche se si ha una certa perdita di dati, si è di nuovo in grado di funzionare velocemente.

Come regola, la granularità dell’RPO dovrebbe essere allineata alla criticità della VM. VMware Cloud Director Availability supporta un RPO di 5 minuti, ma il tempo di recovery effettivo che fa la differenza dipende da quanto è lontano il delta dal disco consolidato di origine. Mantenere basso il numero di punti di recovery garantisce un recovery più veloce, poiché il consolidamento avverrà più velocemente e ci sarà meno data drift tra la sorgente e l’ultimo delta. Ciò che è meglio fare é trovare un RPO e un numero di mPIT accettabili e usare il backup per fare una copia permanente.

Il journaling d’altra parte fornisce il 100% di granularità: con ogni blocco cambiato, replicato, si può potenzialmente evitare qualsiasi perdita di dati ma questo non impatterebbe sulla coerenza dell’applicazione, come con il lightweight delta, a meno che non si usi il quiescing che ad ogni modo non dà alcuna garanzia di successo, soprattutto con applicazioni localizzate nella memoria. É molto importante sempre considerare lo status di una replica.

Figura 2: Confronto delle prestazioni di journaling vs Delta rispetto al cambiamento dei dati l volume dei dati nell’arco di una settimana

Con il journaling è possibile tornare indietro e recuperare da qualsiasi punto a ritroso nel tempo: se c’è stato un malware rilevato nel grafico sopra, si potrebbe tornare indietro fino a qualsiasi punto della linea blu, precedente all’evento. Si può anche fare il ripristino a livello di file, che è vantaggioso rispetto al lightweight delta. I delta infatti funzionano solo su una finestra di 4 ore e non in modo coerente come i journal, quindi il delta più vicino verrebbe misurato rispetto al vmdk di origine all’ultimo consolidamento. Come per ogni cosa c’è un compromesso; il journaling può portare granularità, ma a quale costo?

  • Networking: Il journaling richiede velocità di rete elevate per copiare ogni byte, questo spesso avviene localmente per evitare questo overhead. Spesso i dati del journal vengono compressi alla fonte per minimizzare i requisiti di larghezza di banda e ciò permette di fare il recovery anche localmente e più velocemente, ma questo dipende dal tipo di disaster subito. Le reti più veloci costano di più e sono più complesse, ci si può quindi aspettare di spendere di più per questa soluzione. É una differenza fondamentale: con Lightweight Delta le scritture multiple sullo stesso blocco all’interno dell’intervallo RPO comportano invece solo l’invio dell’ultimo valore e l’utilizzo della rete si riduce notevolmente.
  • Storage: mentre entrambi utilizzano lo storage, la quantità utilizzata dipende dalla granularità della sincronizzazione: maggiore è, più dati devono essere memorizzati. In questo caso il journaling creerà la maggior parte dell’overhead dello storage, dato che nel sito di destinazione saranno conservati il dati disk e il journal, ma il rovescio della medaglia è una capacità di ripristino più granulare.

Figura 3: Confronto delle prestazioni di journaling vs Delta rispetto al volume dei dati e la sincronizzazione durante il recovery

Come mostra il diagramma, mentre il volume dei dati per il journaling e i processi di sincronizzazione per Delta non riguardano lo storage (ma la rete), il volume aggregato sì: più passa tempo maggiore é la differenza tra lo storage aggregato del journal e quello delta. Si noti che questo non include alcuna tecnologia di deduplicazione dello storage nel sito di destinazione, ma è una rappresentazione accurata del volume.

Qual è la scelta migliore?

Non c’è una risposta semplice a questa domanda: gran parte delle prestazioni dipendono dal tasso di cambiamento dei dati in possesso e dalla granularità del ripristino desiderata. Non esiste un approccio sempre vincente, ciascuno ha pro e contro e vanno valutati anche gli aspetti economici. L’importante è rendersi conto che non esiste un vero RPO al secondo (senza replica sincrona con array di storage costosi e un networking molto costoso), a meno che non ci siano cambiamenti di dati ma, a quel punto, ciò varrebbe per tutti i prodotti. Il più veloce sarebbe la soluzione VMDK nativa che non ha bisogno di conversione? Poco importa, però, perché nella realtà ci sono pochissime possibilità che i dati non cambino assolutamente. Nella realtà ci sono grandi volumi di dati, scenari imprevedibili, alti e bassi di comunicazione e picchi di utilizzo imprevisti: ciò che importa e scegliere la soluzione DR corretta per proprio workload tenendo conto delle leve chiave:

  • Risorse di calcolo: Il journaling probabilmente richiede più calcolo che i delta, ma dipende dai programmi di consolidamento. Mantenere journal più piccoli e meno delta minimizza l’overhead di calcolo quando sono richieste operazioni di confronto per il recovery.
  • Storage: maggiore è la granularità, maggiore è lo storage necessario, bisogna assegnare il corretto livello di granularità alla criticità della VM.
  • Networking: Il journaling, replicando off site in modo consistente, avrà bisogno di una larghezza di banda assegnata riservata in modo che la replica non sia influenzata. La replica locale minimizza i costi WAN ma non fornisce una protezione regionale.
  • Granularità RPO: Quanto ci si può permettere di perdere? Niente, allora il journaling è la corretta soluzione, in caso contrario meglio i lightweight delta. Anche in questo caso va assegnato il corretto livello di granularità alla criticità della VM.
  • Tempo di recupero RTO: Per i Delta dipende dal data drift e dal numero di delta rispetto all’ultimo vmdk consolidato. Per il journaling questo dipende di nuovo dalla quantità di dati del journal che devono essere consolidati e convertiti in formato vmdk.

Come spesso accade non c’è un vincitore e un perdente tra journaling e delta, sono solo le tipologie di replica DR disponibili. Per scegliere vanno considerati inevitabilmente anche i costi: se avete bisogno della granularità del journaling, allora è probabile che ci siano costi più alti nello storage e soprattutto nel networking.

@RIPRODUZIONE RISERVATA

Articolo 1 di 5