Este post también está disponible en Español
Uno dei driver principali nell’acquisto di uno storage di tipo AFA riguarda le prestazioni. Tuttavia, l’azienda ha anche altre esigenze tra cui, di particolare importanza, vi è la protezione dei dati.
Come protezione dei dati, mi riferisco alla possibilità di creare copie remote del sito di produzione in un secondo array. Una volta implementato un meccanismo di copia remota, le prestazioni di un array AFA inevitabilmente diminuiscono.
Nel caso delle replica sincrona, aggiungiamo il tempo di latenza della distanza. Nel caso di una replica asincrona, è necessario considerare attentamente la “larghezza di banda” del collegamento per consentire all’array di produzione di non “essere troppo indietro” con le scritture, altrimenti l’array di produzione deve svolgere un lavoro aggiuntivo per mantenere l’RPO.
In questo post esamineremo come XtremIO X2, grazie ad un’unica e particolare implementazione del meccanismo di replica asincrona, è in grado di mantenere un RPO molto basso riducendo al contempo la larghezza di banda necessaria per realizzare le copie.
Un RPO = 0 è davvero sempre possibile?
Un RPO = 0 significa nessuna perdita di dati. Si consideri un’applicazione come un DB. Le scritture all’interno di una transazione vengono per prima cosa copiate nel file di log e poi successivamente nei file di dati.
La nostra auspicata NON perdita di dati (RPO=0) può essere ottenuta solo se al momento dell’errore di sistema siano state scritte entrambe le due strutture (registro e file di dati). Se nel mezzo di una transazione c’è un errore di sistema, tutti i dati scritti che non hanno ancora raggiunto il “commit” vengono persi.
Allo stesso modo, tutti i dati che hanno raggiunto il “commit” ma non il file di dati vengono persi. Ora aggiungiamo all’equazione che un’applicazione solitamente scrive molti dati prima di eseguire il “commit” e che al momento dell’errore si possono ancora trovare molte scritture nella cache del server o del sistema di storage. È chiaro che un RPO=0 o zero perdita di dati non è un obiettivo facile da raggiungere. Quando si fa riferimento a un RPO=0 è più corretta un’espressione come il tentativo di ottenere una replica con coerenza dell’applicazione nel più breve tempo possibile.
Una replica sincrona, come abbiamo visto all’inizio del post, aggiunge un tempo di latenza all’applicazione che fa perdere, in parte, i vantaggi prestazionali ottenuti con uno storage AFA.
Forse il punto più importante su cui dobbiamo riflettere è perché vogliamo eseguire una replica sincrona. La risposta è probabilmente perché vogliamo perdere la minore quantità di dati possibili se c’è un guasto del sistema di produzione ma anche, proteggerci da una possibile mancata disponibilità dei dati
Ora, qual è l’evento più comune che produce un tempo di inattività? La perdita dell’intero array, la perdita dell’intero datacenter o la corruzione dei dati? Mentre i primi due eventi, di tipo fisico, sono meno frequenti, la corruzione dei dati dovuta a cause di un errore umano o di un evento logico (cancellazione accidentale di dati, aggiornamento del software applicativo, ecc.) è molto più frequente. In quest’ultimo caso, una replica sincrona “corromperà” i dati sul sito remoto in un tempo pari al tempo di latenza tra i due siti.
Non sto affermando che non dovremmo eseguire copie sincrone dei dati, spesso in base ai requisiti del business, questo è necessario. L’idea è quella di riflettere sulla validità di una metodologia di protezione remota dei dati, asincrona in questo caso, che consenta di ottenere un RPO molto basso, in grado di proteggere l’ambiente da possibili corruzioni logiche, che non limiti le prestazioni dell’applicazione e che, allo stesso tempo, sia in grado di ridurre la larghezza di banda necessaria nel eseguire le copie.
XtremIO X2, un meccanismo di copia asincrona efficiente
In un meccanismo di copia tradizionale tra due array, produzione e DR, le scritture dei dati eseguite sull’array di produzione vengono inviate all’array DR anche se questi dati esistono già nel sito di DR.
Nel caso di XtremIO X2, il meccanismo di copia è di tipo “metadata aware” e con “global data reduction”. In altre parole, in X2 quando un dato viene scritto sull’array di produzione e il dato esiste già nel sito DR, questo dato non viene copiato remotamente. Questo meccanismo è estremamente efficiente poiché implica il passaggio attraverso la WAN di solo i dati unici (solo quelli che non possono essere deduplicati), dati che in ogni caso vengono trasmessi attraverso il link già compressi, il che si traduce in una diminuzione della banda necessaria.
Esaminiamo brevemente come funziona la replica nativa di X2
La replica nativa di X2 utilizza un meccanismo di “snapshot shipping”. Lo storage crea snapshot con la frequenza determinata dell’RPO desiderato. (Tecnicamente, la frequenza di snapshot è uguale a RPO/2).
X2 non trasmette l’intero contenuto dello snapshot, solo i blocchi di dati che sono stati modificati tra uno snapshot e quello successivo (snapshot delta) vengono inviati attraverso il link. Possiamo immaginare la soluzione di replica remota X2 come un meccanismo a due fasi.
Fase 1: l’array di produzione (source) trasferisce all’array di destinazione (target) solo i metadati (XtremIO fingerprint) dei blocchi che sono stati modificati tra i due snapshot (snap snapshot delta). Questa prima fase serve a fare un “check” se nell’array di DR (target) quei metadati già esistono. In XtremIO i metadati sono sempre contenuti nella RAM, motivo per cui questo check è immediato.
Fase 2: se i metadati esistono già nell’array di destinazione significa che non è necessario inviare i blocchi di dati corrispondenti, è sufficiente solo aggiornare il contatore e i “pointer” ai metadati.In questo modo si ottiene la “deduplica globale”. Se i metadati non esistono, lo storage source invia i blocchi di dati mancanti alla destinazione. I blocchi di dati, come sempre in XtremIO, vengono inviati già deduplicati e compressi.
Considerazioni sull’efficienza della larghezza di banda in X2
Facciamo ora alcune considerazioni per quanto riguarda l’efficienza sul link. Nella fase iniziale di sincronizzazione tra l’array di produzione e quello di DR, ovvero con l’invio del primo snapshot, la quantità di dati trasmessi attraverso il link sarà simile ai valori osservati come DRR (Data Reduction Ratio) nello storage source.
Ad esempio, se nell’array di produzione vediamo una compressione di 2:1 e una deduplica di 2:1, ovvero un’efficienza di 4:1, significa che attraverso il link invieremo solo il 25% dei dati. In altre parole, con una deduplica del 2:1 metà dei dati non verranno inviati, applicando ora ai dati rimanenti una compressione del 2:1, il risultato finale sarà un’ulteriore riduzione del 50% e quindi un’efficienza totale del 75% sul link.
Da quel momento in poi, per i nuovi dati che verranno scritti sull’array di produzione, la quantità di informazioni trasmesse attraverso la WAN dipenderà dalla DRR per questi nuovi dati. Potremmo pensare che se il tipo di carico di lavoro è dello stesso tipo di quello già presente nell’array, continueremo a ottenere un’efficienza del 75%. In realtà il valore di efficienza per i nuovi dati può essere persino più alto. Vediamo il perché con un esempio numerico reale.
Supponiamo che un server scriva, in un certo intervallo di tempo, 1000 pagine di 16 KB (16 MB). Supponiamo Diciamo che il 20% di questi dati siano scritture ripetute, cioè, scritture eseguite sullo stesso indirizzo logico all’interno del ciclo di copia (RPO).
In questo caso, XtremIO invia solo l’ultima scrittura, la più recente, vale a dire che su 1000 pagine dovremo copiare 800 pagine in remoto. Supponendo che de queste 800 pagine, 400 esistano già nell’array di DR (a causa di una modesta deduplica di 2:1), risultano 400 pagine da trasmettere. Queste restanti 400 pagine vengono inviate compresse, ad esempio con un rapporto di compressione di 2: 1. Quindi, 400 * 8 KB = 3,2 MB. Nell’esempio precedente, che non è estremo, 16 MB di scritture sull’array di produzione si traducono in 3,2 MB sul link, valore che equivale a una riduzione dell’80% sulla larghezza di banda necessaria.
In sintesi: X2 fa uso allo stesso tempo di 3 tecniche diverse per ottenere una maggiore efficienza nel replicare i dati remotamente:
1) solo l’ultima versione del blocco di dati viene inviata attraverso il link,
2) grazie alla deduplica globale vengono inviati solo dati univoci,
3) X2 trasmette i dati già compressi mentre allo stesso tempo il sistema X2 di destinazione li legge e li memorizza compressi, senza consumare risorse di CPU aggiuntive.
X2, protezione contro errori “logici”
Vale la pena notare che il meccanismo di copia remota di X2 è in grado di proteggere l’ambiente da eventuali errori logici (cancellazione accidentale di un dato, problemi causati durante un aggiornamento dell’applicazione, ecc.). Abbiamo già detto che questo tipo di evento è più probabile rispetto ad un evento come la perdita completa del sito di produzione.
Come parte integrante del suo meccanismo di copia remota, X2 crea e mantiene automaticamente nel sito DR una serie di snapshot all’interno di una struttura logica chiamata “finestra di protezione” (protection window). Il numero, la frequenza e la durata di questi snapshot possono essere facilmente definiti grazie alla GUI di X2. Supponiamo che durante il normale processo di copia remota, a un certo punto si verifichi un errore logico sui dati di produzione. Sarà quindi possibile selezionare dall’interno della “finestra di protezione” una copia precedente (Point in Time Copy) all’errore e utilizzarla per tornare immediatamente allo stato antecedente all’evento che ha causato il danneggiamento dei dati.
Per concludere
La scelta del tipo di copia remota dei dati pone una serie di sfide all’operatività delle applicazioni
I meccanismi tradizionali di copia remota richiedono un attento bilanciamento tra l’RPO e l’uso della banda.
La ricerca di un RPO=0 comporta una perdita di performance equivalente al tempo di latenza tra l’array di origine e il target, con un impatto negativo sui benefici prestazionali di uno storage AFA.
La replica nativa di XtremIO X2 consente di ottenere un RPO molto basso con l’ulteriore vantaggio di un consumo minimo sulla larghezza di banda necessaria.
La replica remota di XtremIO X2 non ha alcun impatto sulle prestazioni dell’array di produzione o quello di destinazione e supporta, allo stesso tempo, numerosi PiT (copie Point in Time Copy) al fine di proteggere l’ambiente da possibili corruzioni logiche.
Per maggiori informazioni:
Sistemi di Storage Dell EMC XtremIO
#IWork4Dell
Este post también está disponible en: Español (Spagnolo)
