Backup, snapshot, clonazione e replica sono tutti modi preziosi per proteggere i dati dell’organizzazione.
In questo articolo, esamineremo la replica, in particolare tra array di storage. Chiave di questo sarà quello di definire e presentare i pro ei contro della replica con riferimento ad altri metodi di protezione dei dati.
Troppo spesso in ESSO c’è una mancanza di chiarezza su cosa sia esattamente una tecnologia, o lo faccia. Quest’ultimo è il bit importante, perché è come funzionano le diverse tecnologie che possono determinare come si incastrano.
Replica contro snapshot
La replica è fondamentalmente un metodo per produrre un clone di un’unità di archiviazione. In altre parole, è una replica di un’unità, volume o numero di unità logica (LUN), ad esempio. Nella maggior parte dei casi, ciò che viene cercato è una copia esatta – forse quasi immediatamente, forse solo alla fine.
Ciò rende un clone o una replica diverso da uno snapshot, perché gli snapshot nella maggior parte dei casi possono diventare una replica utilizzabile solo dopo una sorta di processo di ricostruzione. Questo perché le istantanee comprendono una copia originale dell’unità o del volume più gli aggiornamenti ad esso, così come forse i blocchi cancellati che devono essere reincorporati per creare una copia accurata da un punto precedente nel tempo.
L’idea è che le istantanee possano essere ricostruite e ripristinate abbastanza rapidamente, ma non sono disponibili come copia alternativa e utilizzabile del supporto sorgente. Nel frattempo, cloni e repliche spesso sono.
Il clone/replica più semplice di tutti è quando, ad esempio, uno sviluppatore ha bisogno di un database su cui eseguire alcune query di test. Possono clonare una copia esatta di un database di produzione esistente e fare ciò che vogliono con esso nell’ambiente di test. Quel clone sarà una replica esatta del database nel momento in cui è stato creato, ma probabilmente non rifletterà mai ulteriori modifiche alla copia di origine.
Ma all’altra estremità della scala in termini di creazione di un clone disponibile e funzionante è la replica sincrona. Questo vede i dati scritti su due o più unità di archiviazione il più vicino possibile contemporaneamente per fornire una copia di lavoro che può essere fallita al volo.
Ovviamente questo ha un prezzo in termini di costi e complessità tecnica e ci sono limitazioni, come vedremo. Ma questo è spesso ciò che intendiamo quando parliamo di replica.
Replica contro backup
La replica può sostituire i backup? La semplice risposta è no. I backup e la replica (e forse anche le istantanee) devono completarsi a vicenda.
Poiché la replica può essere quasi continua e crea una copia quasi in tempo reale, può anche creare una replica di file corrotti o infetti. In tal caso, è necessaria una versione a cui eseguire il rollback.
Che potrebbero essere derivati da un’istantanea, ma poi devono anche essere supportati da backup – e la replica è spesso costosa, quindi potrebbe essere che solo alcuni set di dati vengano replicati mentre tutto viene eseguito il backup.
Replica sincrona e asincrona
Nella replica sincrona, i dati possono essere scritti nel secondo sito non appena viene raggiunta la cache nel sito principale. Al ricevimento, il secondo sito invia una conferma all’archiviazione del sito principale e all’host in cui è stata originata la modifica. È il metodo di replica che si avvicina alla scrittura di più copie di dati il più vicino possibile contemporaneamente.
La replica sincrona è spesso appannaggio degli array di storage a blocchi più di fascia alta.
La replica asincrona aggiunge una fase al processo, riconoscendo l’host nel sito principale quando i dati vengono scritti. Quindi la scrittura viene inviata al secondo sito, che riconosce che la scrittura torna all’array del sito primario. La replica asincrona si trova in una gamma più ampia di prodotti di storage, ad esempio storage iSsi, Network-attached Storage (NAS) e così via.
La replica su grandi distanze inizia a soffrire di circa 1 millisecondo di latenza per 100 miglia e i fornitori spesso raccomandano non più di poche centinaia di miglia di andata e ritorno.
Per questo motivo, la replica sincrona può avere un impatto maggiore sulle prestazioni dell’applicazione. Richiede il riconoscimento prima che il prossimo input/output (I/O) possa aver luogo, mentre la replica asincrona riconosce localmente in modo che la prossima modifica possa avvenire, con il movimento dei dati ritardato. Naturalmente, ciò significa anche che i due set di dati saranno diversi per un tempo più lungo.
Una strategia di replica del mondo reale potrebbe utilizzare una combinazione di replica sincrona-per gli elementi più critici di un’applicazione come redo logs – mentre i dati meno critici che potrebbero essere ripristinati passano tramite asincrono. Anche le istantanee potrebbero far parte del mix, ma dovrebbero essere supportate da backup regolari.
Replica di host, hypervisor e cloud
Qui ci siamo occupati principalmente della replica sincrona e asincrona negli array di storage.
Esistono altre forme di replica, come:
- Replica host – tra server, forse di singole applicazioni, database o l’intero server.
- Hypervisor Replication-Replica gestita a livello di hypervisor e composta dai suoi elementi, come le singole macchine virtuali (VM) e lo storage virtuale, ad esempio.
- Replica cloud: potrebbe trattarsi di replica nel cloud o di più cloud come target o tra cloud.
- Geo-replica: è qui che i dati vengono archiviati in più posizioni remote, potenzialmente molto distanti l’una dall’altra. Questo può essere per motivi di disaster recovery o per migliorare la disponibilità. È improbabile che la replica su distanze così lunghe sia sincrona.