Veeam Backup & Replication 7 e BackupCopy: un nuovo modo di progettare il backup storage

0 Flares Twitter 0 Facebook 0 Google+ 0 LinkedIn 0 Email -- 0 Flares ×

Solitamente, uno dei problemi maggiori nel disegno di una infrastruttura di backup con Veeam è sempre stato il corretto dimensionamento dello storage da dedicare ai backup.

I compromessi del backup storage per Veeam

Prima della versione 7, il disegno prevedeva solitamente l’uso di un unico storage di backup. Questo però doveva possedere un giusto bilanciamento (e quindi, in definitiva, un compromesso) tra la velocità e le dimensioni, in modo da poter contenere la retention desiderata. Ho spesso visto i clienti scegliere di usare un NAS o uno storage locale sui server fisici che agivano da repository dato che il prezzo e la capacità dello storage erano i due elementi più importanti del progetto. E questo ovviamente sacrificando la velocità.

Purtroppo, il repository di Veeam possiede dei requisiti specifici che un normale storage di backup non ha:

– i backup non sono delle scritture completamene sequenziali, dato che i file vengono compressi e deduplicati, quindi vi è sempre una percentuale di letture che avvengono sullo storage, e parte di queste attività sono random, dato che i blocchi già presenti sullo storage e che vengono confrontati con i nuovi durante la deduplica possono trovarsi in aree differenti dello storage stesso. Questo è ancora più evidente se si sceglie la modalità Reverse Incremental, come ho spiegato dettagliatamente in una mia white paper.

– i restore hanno le stesse caratteristiche di accesso random esattamente per gli stessi motivi elencati prima

– Instant VM recovery è il culmine di questi problemi. Per poter eseguire una VM direttamente da questo storage deduplicato e compresso, lo storage deve essere molto veloce. Se pensate che deduplica e compressione in tempo reale non vengono usate nemmeno in molti storage di produzione, capite perchè a maggior ragione questo è un problema sullo storage usato per salvare i backup di Veeam

In ultima analisi, quello che accadeva era una scelta a priori tra velocità e numero di punti di ripristino, dato che uno storage che fosse allo stesso tempo veloce e capiente andava ad incidere in modo eccessivo sui budget. Parafrasando un noto adagio “Large, Fast, Cheap: You Can Only Pick Two!”

BackupCopy, e un nuovo design per i backup

Con Veeam Backup & Replication 7, una singola funzione cambierà completamente questo modo di disegnare un’architettura di backup: BackupCopy.

Per avere ulteriori informazioni su questa funzione, potete leggere un mio post a riguardo, così come l’annuncio ufficiale fatto da Veeam. Veeam ha posto molto l’attenzione sulla funzione di WAN Acceleration, ma questa sarà un’aggiunta alla BackupCopy, che rimane la funzione di base della nuova soluzione. Per capire come funziona, vi riporto un loro schema, ignorate la WAN Acceleration e concentratevi invece sulla BackupCopy:

Veeam backup copy how it works

Potendo adesso copiare il contenuto dei backup primari in un backup secondario, senza dover realizzare due attività di backup sullo storage di produzione, ma nemmeno dovendo replicare gli stessi file di backup del backup rimario, si aprono nuovi scenari che vanno assolutamenti considerati (e implementati!).

Innanzitutto, dal punto di vista architetturale, andremo a disegnare una struttura a due livelli in cui avremo due storage, uno primario e uno secondatio. Questi due livelli avranno caratteristiche completamente differenti. Innanzitutto, il loro posizionamento all’interno dell’infrastruttura esistente: lo storage primario sarà responsabile di ricevere i backup dallo storage di produzione, mentre lo storage secondario riceverà le copie dal backup rimario tramite la funzione di BackupCopy.

Lo storage primario è disegnato principalmente per poter soddisfare i livelli di RPO e RTO più stringenti che verranno richiesti. Questo anche a scapito, anzi soprattutto a scapito della capacità. Sarà uno storage molto veloce (usando anche dischi SSD se necessario) per permettere backup in tempi rapidi e restore molto veloci, comprese le attività di Instant VM Recovery; sarà poco capiente per contenerne i costi, in grado quindi di conservare pochi punti di ripristino. Statisticamente, la gran parte delle attività di ripristino avvengono a partire dalle ultime versioni, quindi uno storage in grado di conservare 2-3 punti di ripristino sarà più che sufficiente. E in caso di problemi di spazio, andremo ad usarlo unicamente per quei backup veramente importanti, e magari gli affiancheremo un secondo repository più lento per i backup di “seconda fascia”.

Lo storage secondario è disegnato unicamente valutando la sua capacità e il costo per GB che può offrire. Dedicando una rete apposita alla comunicazione tra storage primario e secondario, possiamo fare in modo che il BackupCopy Job venga effettuato anche in pieno giorno, prelevando i dati che tipicamente durante la notte il backup primario ha ricevuto dallo storage di produzione. Il disegno di questo storage può prevedere differenti soluzioni: NAS di ampia capacità, Object Storage, oppure le Dedup Appliances, che prima dimostravano tutti i loro limiti nell’essere usate come storage primario di Veeam (ne avevo parlato qui ad esempio), diventano invece un target quasi perfetto per questo scenario.

Un’altra alternativa, se riteniamo che i backup più vecchi non verranno acceduti frequentemente, potrebbe anche essere l’uso dei tape direttamente come storage secondario, grazie al fatto che Veeam supporterà i nastri a partire proprio dalla versione 7.

Il Backup tiering è la soluzione

Durante alcuni eventi in cui sono stato invitato come speaker a parlare di Data Protecton, ho parlato di Backup Tiering, ed era anche l’argomento di cui avrei voluto parlare al VMworld 2013 se la mia sessione fosse stata accettata (potete leggere qui l’abstract che avevo proposto).

Con il concetto di Backup Tiering descrivevo l’uso di differenti livelli di backup che insieme portavano ad avere una protezione completa, combinando i differenti pregi di ogni livello e annullando vicendevolmente i difetti. Veeam con la sua nuova versione 7 ha introdotto gli stessi concetti, confermando che i backup monolitici non sono fatti per il mondo virtualizzato così come già non lo erano per il mondo fisico anni fa.

Se state iniziando un nuovo progetto di data protection con Veeam Backup o volete revisionare quello già in essere, anche se userete ancora per alcuni mesi la versione 6.5, iniziate fin da ora a disegnare la nuova architettura in previsione dell’uso della versione 7, e di come sfruttare al meglio questi nuovi concetti.

0 Flares Twitter 0 Facebook 0 Google+ 0 LinkedIn 0 Email -- 0 Flares ×