Negli ultimi tempi, molti dei progetti che ho seguito ruotavano sull’argomento della protezione dei dati: backup di ambienti VMware, backup remoto, storage a lungo termine, repliche, Disaster Recovery e via discorrendo.
Nell’analizzare i requisiti che il cliente si aspetta dalla nuova piattaforma di “data protection”, i più “gettonati” sono sempre due:
- una velocità di backup maggiore rispetto alla soluzione attuale, solitamente basata su un software “classico” adattato a funzionare in un ambiente virtualizzato
- la possibilità di effettuare con un solo passaggio il backup sia dell’intera virtual machine, sia dei dati in essa contenuti
La seconda richiesta può forse far sorridere chi già da anni utilizza software “image-based” e sa che questa cosa è perfettamente possibile, e anzi è una caratteristica “scontata”, ma il messaggio di fondo che esce da entrambe le richieste è riassumibile nella medesima esigenza:
Il backup deve durare meno!E’ possibile, alla luce delle tecnologie ad oggi disponibili, ridurre il più possibile i valori di RPO di un backup?
vStorage API, gioie e dolori
Vediamo innanzitutto come ad oggi è possibile fare un backup in ambienti VMware.
Le vStorage API danno la possibilità di effettuare backup a caldo delle virtual machine senza interrompere la loro esecuzione. Il flusso operativo di un tale backup è il seguente:
- viene effettuata una snapshot della virtual machine
- il disco vmdk viene sbloccato in lettura, e le scritture vengono nel frattempo salvate in un “delta disk”
- tramite le librerie, un software di backup copia il disco vmdk (interamente o incrementalmente) in una posizione differente
- terminato il backup, le modifiche registrate nel delta disk vengono nuovamente scritte dentro il disco originale in modo che della snapshot non resti più traccia (quello che solitamente viene indicato come attività di Commit della snapshot)
Questo sistema si è rivelato sempre efficiente: permette di utilizzare qualsiasi software di backup senza che esso sia stato specificatamente scritto per una determinata applicazione, ma con l’unico requisito di supportare le vStorage API stesse. Inoltre, qualsiasi storage supportato da VMware diventa automaticamente supportato dalle librerie.
Da un punto di vista aziendale, è possibile quindi sostituire lo storage, piuttosto che il software di backup stesso, senza perdere questa funzionalità dell’ambiente virtualizzato.
Ma ci sono anche problemi e limiti, che stanno lentamente emergendo man mano che passa il tempo.
Vediamo i limiti. Basare questa tecnologia sulle snapshots ha portato con sè di fatto tutti i vincoli delle snapshots stesse: dal momento che non è possibile fare un snapshot di dischi indipendenti, dischi di virtual machine protette da FT, dischi RDM fisici o di linked clones, di questi dischi non è nemmeno possibile fare il backup tramite le vStorage API. Se per i clienti di piccole dimensioni questo non è un grande problema, usando raramente queste configurazioni, per clienti medio-grandi questi vincoli pongono seri problemi, e obbligano spesso a mantenere in uso sistemi di backup che prevedano anche la presenza di agent all’interno delle virtual machine, facendo di fatto gli stessi backup che si facevano anni fa con i server fisici.
Ma il problema forse più serio che sta ultimamente emergendo è un altro: anche con l’uso delle vStorage API un backup può durare più del necessario, e il problema sta tutto nel punto 4 dell’elenco che ho fatto prima.
Vediamo di capire insieme in cosa consiste: l’evoluzione tecnologica dell’hardware di storage e gli algoritmi sempre più efficienti dei software di backup hanno permesso nel tempo di incrementare man mano le velocità a cui è possibile realizzare un backup, specie se si usa come target un sistema disco invece di un nastro.
Dall’altro lato però i backup di tipo image-based soffrono quando una virtual machine produce un elevato I/O sul disco virtuale: per tutto il tempo in cui il software di backup sta salvando il disco virtuale, le nuove scritture vengono “parcheggiate” nel delta disk. Tanto più dura il backup, tante più scritture verranno salvate, e dovranno poi tutte essere riscritte nel disco originale leggendole dal delta disk.
Non è infrequente imbattersi in situazioni dove un backup di 1 ora è seguito da 3-4 ore di commit della snapshot. Se possedete tra le vostre virtual machine un server MS Exchange (specie 2010) avrete probabilmente assistito a questo fenomeno. In questi casi, garantire un RPO definito diventa tecnicamente impossibile: a seconda della quantità di modifiche registrate, una commit può durare un giorno pochi minuti e il giorno successivo diverse ore; questa variabilità per molti IT managers è forse più indigesta dell’avere un RPO scarso ma sempre costante.
Nel futuro, questi problemi a mio avviso peggioreranno sempre più: gli ambienti di produzione ospiteranno applicazioni sempre più esigenti, che produrranno sempre più I/O oppure che hanno logiche di scrittura sui dischi virtuali per cui a fronte di pochi bytes modificati le modifiche ai blocchi del vmdk sono numerose (Exchange 2010 ad oggi è l’esempio migliore in tal senso). E se anche la virtual machine da salvare non produce tanto I/O, il fatto che condivida lo stesso datastore con altre VM che potrebbero produrre un elevato I/O la espone a questi problemi.
Per citare Einstein: “Non possiamo pretendere di risolvere i problemi pensando allo stesso modo di quando li abbiamo creati.”. E’ necessario probabilmente un nuovo approccio alle problematiche dei backup.
Nuove metodologie di backup?
In cosa consistono? Essenzialmente, in una maggiore integrazione tra il software di backup è lo storage che ospita i dischi vmdk, al fine di ridurre al minimo se non addirittura eliminare l’impatto delle operazioni di snapshot di VMware.
Detto in una sentenza: Niente più snapshots di VMware, niente più dolorose commit a fine backup, e un RPO certo!
Tra le varie implementazioni di queste idee, ho potuto testare CommVault Simpana SnapProtect, e Veeam Explorer for SAN Snapshots. Vediamo innanzitutto come funzionano.
Simpana SnapProtect
- vCenter effettua una snapshot della virtual machine da salvare
- Simpana richiede allo storage una snapshot della LUN che ospita quel vmdk
- appena effettuata la snapshot della LUN, simpana chiede a vCenter il commit della snapshot da lui effettuata. Dato che l’operazione precedente è durata idealmene meno di un minuto, il commit di vCenter dovrebbe essere sempre rapido e indolore anche in presenza di elevato I/O
- Simpana monta la snapshot dello storage come nuova LUN su un server ESXi che farà da “proxy”, e da qui con calma realizza il backup. Se anche il backup dovesse durare 1 ora, il punto di ripristino corrisponde al momento in cui è avvenuta la creazone della snapshot da parte di vCenter.
Veeam Explorer for SAN Snapshots
- Lo storage realizza la snapshot della LUN
- In caso di restore, la LUN viene montata su un server ESXi, e il suo contenuto letto da Veeam per effettuare i restore.
Ad oggi Veeam non estrae i file dalla snapshot, perciò i dati restano confinati nello storage di produzione, a meno di non realizzare una remote snapshot su un secondo storage. Mi auguro e ritengo che nelle prossime versioni ci sarà la possibilità di estrarre i backup direttamente dalle snapshots dello storage.
Sicuramente, ad oggi l’implementazione più avanzata di questa metodologia è quella di CommVault Simpana, e mi ha molto intrigato.
Analizzando però a fondo i requisiti di queste due tecnologie, possiamo trarne alcune considerazioni finali.
“Storage-Aware” Backups
Se con le vStorage API i backup sono indipendenti dallo storage, le nuove tecnologie che si stanno introducendo si basano al contrario su una elevata integrazione tra software di backup e storage. Sia CommVault che Veeam supportano una lista ben definita di marche e modelli di storage, e non è possibile usare le loro tecnologie avanzate con sistemi genericamente supportati da VMware (è comunque sempre possibile usare le vStorage API).
Mi è già capitato in alcuni progetti di virtualizzazione, che tra i requisiti del cliente ci fosse il supporto per tali funzioni di backup. Questa scelta ovviamente ha influenzato la scelta anche dello storage da usare per l’ambiente virtualizzato.
In futuro, potremmo forse assistere a un’integrazione sempre più spinta tra questi due elementi.