Questo post è la traduzione di Delivering snapshots.

Negli ambienti IT una degli aspetti più importanti è la capacità di replicare i dati da un sito ad un altro o, in alcuni casi, all’interno dello stesso sito. Le repliche sono una delle funzionalità di base per affrontare problematiche di Disaster Recovery e Business Continuity. Ogni grande azienda, istituzione finanziaria, ospedali, ecc. ha bisogno di replicare i dati il più velocemente possibile su altri siti per garantire un buon livello di servizio, evitare di perdere denaro e, qualche volta, vite umane!

Ci sono molti sistemi diversi di replicazione, il più adottato negli ambienti tradizionali è la replica sincrona: ogni blocco scritto localmente viene copiato immediatamente anche su un secondo array remoto, l’operazione sarà conclusa quando il blocco sarà presente su entrambi gli array. Questo approccio ha dei pro e dei contro:

I pro sono legati alla qualità e alla consistenza dei dati, si è sempre sicuri di cosa è stato scritto in ogni momento per cui non c’è dubbio sullo stato del sito remoto e la ripartenza può avvenire “al volo” se necessaria. I contro sono principalmente i costi: c’è necessità di storage performante sia sul primo che sul secondo sito, disponibilità di fibra ottica, banda e bassa latenza (quindi la distanza è un problema e le telecom un altro!), e così via!

Se invece l’azienda non ha bisogna di una replica in tempo reale o, in altre parole, si può perdere qualche transazione perchè non è una banca, un pronto soccorso ospedaliero o una centrale nucleare ci sono vie più economiche per replicare i dati: copie asincrone e delivery di snapshot.

La replica asincrona è una evoluzione di quanto già descritto… lo storage locale da l’OK alla scrittura quando questa è avvenuta localmente e si occupa di propagarla in remoto nel tempo più rapido possibile: si otterrà quindi un piccolo disallineamento dovuto al ritardo delle diverse scritture. Il controller dell’array dovrà anche fare un lavoro superiore, gestire una cache più grande e un sistema di journaling per garantire la qualità delle scritture ma, dall’altra parte, ci sarà bisogno di molte meno necessità sul fronte risorse di comunicazione in termini di banda e latenza che portano quindi ad una spesa minore!

Negli ultimi anni, grazie all’adozione di sistemi di snapshot più sofisticati da parte di alcuni vendor (per esempio: NetApp e Compellent) c’è una terza via: il delivery (o consegna/spedizione) delle snapshot ad intervalli prestabiliti! Le snapshot sono delle copie “point-in-time”di volumi di dati memorizzate nel sistema di storage stesso, occupano poco spazio (solo le differenze) e sono facili da usare. Ogni vendor ha la sua implementazione ma quelle dei vendor menzionati sono particolarmente integrate con le funzionalità di replica.

E’ possibile prendere molte snapshot ogni giorno, in alcuni casi anche ogni 15 minuti o meno, poi è possibile spedire queste snapshot via FC o TCP/IP ad un secondo storage. Se la vostra azienda può perdere 15 minuti (qualche volta meno) di transazioni in caso di recovery da un disastro, allora, probabilmente, questo è il sistema di replica che più vi potrà interessare.

Fare il delivery delle snapshot ha molti vantaggi e pochi svantaggi se comparati con le repliche tradizionali.

Lo svantaggio più grosso è, come già detto, il ritardo: non è possibile arrivare ad avere copie in tempo reale o quasi in tempo reale e quindi non è possibile utilizzare questa modalità per tutte le applicazioni!

Per il resto ci sono solo vantaggi:

  • La replica viene fatta dopo aver preso la snapshot: nessun impatto sulle prestazioni del sistema di produzione;
  • La replica dei volumi può essere su TCP/IP senza la necessità di acquistare costose fibre dedicate;
  • Le repliche possono essere fatte su linee con poca banda e alta latenza (alcune volte i siti possono essere anche molto distanti);
  • La replica può essere deduplicata! (alcuni vendor hanno delle funzionalità di deduplica sui controller o si possono utilizzare appliance come Riverbed);
  • La replica ha una storia ed è quindi possibile fare il recovery di repliche più indietro nel tempo se necessario;
  • Si possono configurare repliche N:1 (esempio tanti siti remoti piccoli e un sito grande centrale);
  • Le snapshot possono essere usate per testare il DR senza impatto sulla produzione;
  • … e altro ancora.

Noi usiamo molto lo snapshot delivery nei nostri progetti e, qualche volta, è usato anche come un primo backup on line dei dati!

ES