Cloud e Data Protection: i vantaggi di una soluzione nativa per la virtualizzazione. Andrea Mauro vexpert e VCDX

Transcript

1 Cloud e Data Protection: i vantaggi di una soluzione nativa per la virtualizzazione Andrea Mauro vexpert e VCDX Febbraio 2013

2 Sommario Introduzione alla Data Protection 3 Perché proteggere 3 Cosa proteggere 3 Come proteggere 3 Dove proteggere 5 Ripristino 5 Cosa cambia nel virtuale? 5 Introduzione alle soluzioni di backup 6 Evoluzioni della specie 6 Soluzioni di backup tradizionali 7 Soluzioni di backup native per la virtualizzazione 9 Aspetti da considerare nei backup 13 Lavorare con la sorgente dei dati 13 Modalità agent-less 13 Modalità Network-free (o LAN-free ) 13 Ottimizzazione della sorgente 14 Ottimizzazione del trasferimento 14 Consistenza dei backup 15 Lavorare con la destinazione dei backup 16 Formato dei backup 16 Deduplica lato target 17 Deduplica source + target 17 Aspetti da considerare nei restore 17 Come diminuire i tempi di restore? 17 Verificare i restore 18 Restore granulari 19 Cloud Backup un futuro già presente 20 Conclusioni 21 2

3 Introduzione alla Data Protection Perché proteggere Vi sono così tante motivazioni per richiedere la data protection, da doverla considerare requisito progettuale di ogni architettura IT (anche se spesso viene invece considerata in un secondo passo o ad un livello di importanza minore, soprattutto nelle realtà di tipo PMI). La prima motivazione, che è anche la più importante, è di natura funzionale: essere in grado, a seconda di quali siano le policy di protezione (per maggiori informazioni sulle policy di backup e protezione vedere il relativo corso in inglese sulla Backup Academy), di ripristinare un dato (o un informazione) a seguito di una qualche perdita o compromissione dell integrità dello stesso. Le cause possono essere le più disparate e vanno dall errore umano, a cause esterne naturali (i cosiddetti disastri ), a problemi legati alla sicurezza informatica (in particolare le minacce volte a togliere disponibilità o integrità). Ma vi sono poi altre motivazioni, che vanno dalla storicizzazione dei dati, dalla gestione di versioni temporali diverse a problematiche più legate alla Business Continuity. In ogni caso vanno individuati degli obiettivi, in termini di parametri RTO e RPO, da tenere a mente nel disegnare l infrastruttura. Cosa proteggere In ambito informatico, parlare della protezione dei dati può essere spesso limitativo: il dato è solo uno degli oggetti o asset da proteggere e spesso bisogna considerare la visione d insieme che include anche le applicazioni, i servizi, i sistemi, l infrastruttura stessa. Di conseguenza si passa dalla Data Protection, che è più rivolta ai dati (che possono essere di natura diversa a seconda delle applicazioni e dei servizi), alla System Protection, volta invece a proteggere i sistemi (e di conseguenza quanto in essi vi è contenuto), fino ad arrivare alle soluzioni per la protezione di interi Datacenter (permettendo quindi di gestire la casistica di Disaster Recovery). Questi livelli di protezione possono intersecarsi ed uno includere l altro, ma non sempre si possono usare le stesse tecniche di protezione e/o le stesse tecniche di ripristino. Inoltre le diverse soluzioni di protezione possono soddisfare in modo diverso i requisiti di Business Continuity. Come proteggere Il backup è sicuramente la forma più nota per implementare la protezione dei dati: tramite un apposito programma e opportune procedure (policy) si decide cosa salvare, come, ogni quanto, dove, per quanto tempo (con quale retention). Tipicamente il programma di backup va anche a definire quali sono le procedure di ripristino dei dati. Ma il backup tradizionale a livello di file ( file-based ) non è l unico modo per proteggere dei dati (o sistemi), poiché vi possono essere soluzioni alternative o complementari. 3

4 Una è quella di utilizzare funzioni di snapshot ad un qualche livello (a livello di storage, a livello di virtualizzazione o a livello di file system): in questo caso sia i tempi di creazione della snapshot sia i tempi di ripristino spesso sono molto bassi (o comunque normalmente minori di quelli dei backup tradizionali), ma per contro non c è una vera separazione tra i dati originali e quelli protetti. Anzi, per come funzionano le snapshot queste sono solo delle differenze rispetto all originale, con il rischio di perdita di dati nel caso la sorgente originale non sia più disponibile. Vi è poi l archiviazione, che è una forma alternativa al backup: il dato viene spostato o salvato esplicitamente (e di norma manualmente) in un qualche sistema di archiviazione che può andare dal più generico file server o NAS, fino ad appliance dedicati più sofisticati (che, ad esempio, includono funzioni di deduplica/ottimizzazione dei dati o di ridondanza). Da notare che i sistemi di archiviazione possono a loro volta essere sottoposti a backup, oppure essere usati come possibile destinazione di alcuni backup. Un altro approccio è la replica, dove un dato viene copiato su un altro sistema, locale o remoto (talvolta, come in Veeam Backup & Replication, con tecniche di ottimizzazione di banda e di controllo delle modifiche, compressione e/o deduplica per trasferire solo il minimo indispensabile). Esistono due macro-tipi di replica: quella sincrona, dove il dato viene duplicato in tempo reale, e quella asincrona, dove invece il dato viene copiato periodicamente (automaticamente o manualmente). Normalmente si usa la replica asincrona per una serie di ragioni, principalmente infrastrutturali ed economiche, che esulano da questo documento. A differenza dell archiviazione, con la replica si tende a mantenere la disponibilità del dato (e potenzialmente quindi del servizio) nel sistema di destinazione. A differenza dei backup, la replica ha procedure di restore distinte e spesso limitate (ad esempio, in varie soluzioni è possibile il restore solo dall ultimo stato disponibile, vedasi il caso della replica nativa con VMware vsphere 5.1). Tutte queste soluzioni hanno però un potenziale limite: agiscono periodicamente (a parte la replica di tipo sincrono) ed esiste quindi una finestra di non protezione corrispondente all intervallo tra due operazioni successive, nella quale eventuali dati modificati possono essere persi. Per questo spesso si utilizzano diverse tecniche di protezione per cercare di avere finestre con frequenza diversa o sfalsate tra di loro. Un approccio alternativo, dove ogni modifica viene tracciata e protetta, è quello della Continous Data Protection e normalmente è implementabile solo per dati di tipo file. Vanno infine citate soluzioni specifiche per diversi servizi dove la protezione dei dati può essere una funzionalità inclusa nel servizio stesso. Si pensi ad esempio al recycle bin delle versioni più recenti dell Active Directory o al DAG di Microsoft Exchange a partire dalla versione

5 Dove proteggere Come è stato introdotto in precedenza, esistono diverse tecniche di protezione che possono essere usate in combinazione tra di loro. Allo stesso modo esistono diverse destinazioni ( target ). Queste diverse destinazioni possono essere visti come livelli ( tier ) di una soluzione multi-livello di protezione: partendo dallo storage (usando le snapshot), si può arrivare a memorizzazione su disco, storage removibile come ad esempio i tape, o destinazioni remote come siti secondari o cloud pubblici. Ogni tipo di destinazione corrisponde a caratteristiche diverse quali costi, tempi di ripristino, capacità, livello di protezione, e l uso combinato di più di queste soluzioni (non necessariamente tutte) permette di disegnare una soluzione di protezione ottimale. Ripristino Le procedure e le esigenze di ripristino (recovery) possono cambiare in base al tipo di oggetto da ripristinare, dai tempi richiesti per l operazione e dalla causa della perdita di disponibilità o integrità. Nel caso peggiore di un guasto che interessi l intero datacenter bisogna ripristinare tutti i sistemi e i dati in un sito remoto. Questa operazione presenta una certa complessità che deve essere esplicitata in un piano di disaster recovery, magari anche avvalendosi di opportune soluzioni di orchestrazione. Quando si ha bisogno di ripristinare un servizio e/o dei dati a livello applicativo occorre valutare aspetti di consistenza applicativa: ad esempio, un servizio multi-tier come Microsoft SharePoint ha delle dipendenze tra diversi livelli e sistemi (in particolare lo stato dei file system e quello dei database): un ripristino che non garantisca questa correlazione potrebbe portare ad un ripristino parziale o persino a problemi di integrità. Altro aspetto da considerare è quello legato ai tempi di ripristino: in alcune situazioni devono essere molto brevi e l uso di soluzioni di protezione multilivello può sicuramente aiutare a rispettare i requisiti. Cosa cambia nel virtuale? In un ambiente virtualizzato ogni macchina virtuale (o VM) è un sottoinsieme di un sistema fisico ed agisce e si comporta in un modo del tutto simile. In una prima approssimazione si potrebbe pensare di considerare sistemi fisici e virtuali allo stesso modo ed adottare fondamentalmente le stesse soluzioni. Ma è un approccio conservativo e spesso limitante che non sfrutta a dovere le funzionalità uniche offerte dagli ambienti di virtualizzazione. Bisogna inoltre considerare che i sistemi virtuali tendono a crescere molto più velocemente dei sistemi fisici (fenomeno noto come VM sprawl ) e quindi trattarli allo stesso modo ridurrebbe l efficacia delle soluzioni di protezione. Con la virtualizzazione ogni macchina virtuale è rappresentabile da un numero finito di file ed esiste uno strato di virtualizzazione (chiamato hypervisor) che 5

6 gestisce questi file. Inoltre anche lo storage può vedere questi file (a livello file in sistemi NAS o a livello di blocco in sistemi DAS o SAN). Si può quindi pensare di salvare questi file (con opportune chiamate all hypervisor) per avere una soluzione di system protection, visto che viene salvata l intera macchina virtuale nel momento stesso in cui si salvano i suoi file. Ma dato che il formato di questi file è noto (ad esempio VMDK per VMware e VHD/VHDX per Hyper-V), come pure i file system più comuni usati dai sistemi operativi guest, una soluzione evoluta di backup può a sua volta ispezionarne il contenuto per ottenere una data protection, almeno a livello file. A quel punto si potrebbero individuare alcuni file ben noti di applicazioni particolari (il database di Active Directory, quelli di Exchange, ) e diventa possibile implementare anche una protezione dei dati a livello di applicazione. Tutto partendo da un unico backup! Questo è, ad esempio, l approccio di Veeam Backup & Replication, soluzione innovativa che garantisce un ripristino multi-livello a partire da un unico backup a livello immagine. Un aspetto fondamentale è garantire la consistenza dei dati, dato che solo il sistema operativo guest e/o le sue applicazioni possono sapere quali file sono in uno stato integro (ossia che l immagine su disco corrisponda a qualcosa di consistente). Ma questo è un aspetto che può essere gestito creando dei canali di comunicazione tra l hypervisor e i sistemi guest (come ad esempio le VMware Tools per VMware o gli Integration Services per Hyper-V). Per maggiori informazioni sulle differenze tra il backup di sistemi fisici e virtuali si rimanda ai relativi corsi (in inglese) di approfondimento sulla Backup Academy. Introduzione alle soluzioni di backup Evoluzioni della specie L evoluzione delle infrastrutture IT, passando dai mainframe agli ambienti distribuiti, per arrivare poi alla virtualizzazione ed ora al cloud, hanno permesso e, per certi versi, imposto anche un evoluzione delle soluzioni di backup. Semplificando al massimo lo scenario, potremmo suddividere le soluzioni di backup in tre grosse famiglie: le soluzioni storiche di backup nate nel mondo fisico e col tempo adattate al virtuale, le soluzioni di nuova generazione nate direttamente sul virtuale (e in alcuni casi ri-adattate al fisico), le soluzioni specifiche come quelle di protezione di sistema (tramite ad esempio imaging) e/o di application protection. Di seguito si descriveranno le peculiarità dei prodotti tradizionali rispetto a quelli di nuova generazione, tralasciando per semplicità i prodotti con approcci specifici a singole applicazioni. 6

7 Soluzioni di backup tradizionali In questa famiglia annoveriamo prodotti storici e tutt ora presenti nelle soluzioni di backup. Tra questi figurano, ad esempio, prodotti di vendor come IBM, EMC, Symantec, Questi prodotti sono nati nel e per il mondo fisico e di volta in volta si sono adattati al modificarsi dell infrastruttura IT e/o al modificarsi delle esigenze dell utente. Partendo dalle prime soluzioni per sistemi mini e mainframe, dove tutto era centralizzato in un unico sistema, si sono evoluti in soluzioni per il mondo PC dove all inizio in ogni server era presente un software di backup e i relativi supporti di salvataggio. Storicamente sono nati per salvare su dispositivi di tipo tape (per chi è curioso, basti notare come su Unix il comando tar di default cerchi un unità a nastro o di come NTbackup su Windows aveva incluso il supporto per tape locali) secondo l approccio piramidale e tradizionale delle memorie: Registri Cache L1/L2 Memoria centrale Memoria di massa Costo e Velocità Capacità Memorie removibili Figura 1 Diverse tipologie di memorie, classificate per costo/prestazioni/capacità Questo modello però, nel corso degli anni ha presentato alcuni evidenti incongruenze: se per velocità e costo la regola rimane valida (benché per i supporti removibili bisognerebbe includere anche il costo dell unità, che nel caso di nastri e librerie o autoloader ha un incidenza non trascurabile), la capacità non necessariamente ha seguito questo modello e, ad esempio la capacità dei dischi rigidi SATA supera di gran lunga la capacità dei tape. Vi è poi un altro limite nell approccio originario dei sistemi di backup tradizionali: quello di un sistema di backup locale su ogni server che poteva funzionare per i mainframe, ma non era più scalabile per gli ambienti distribuiti. Questo ha richiesto un primo re-design dell architettura di backup più complessa e distribuita simile a questa: 7

8 Client Server (client di backup) Server di backup & nodo storage Catalogo metadati Set di dati Storage a disco Figura 2 Architettura distribuita di backup Backup su nastro Il server di backup diviene un sistema a se stante (a sua volta potenzialmente scalabile e parallelizzabile separando i diversi ruoli che lo compongono) e i diversi server che devono essere protetti sono collegati tramite appositi client di backup (in molti casi sono chiamati anche agenti di backup ). Funzioni come la scrittura su disco (in alternativa o in coesistenza a quella su tape) vengono aggiunte, ma spesso senza considerarne le potenzialità o le diverse necessità: ad esempio nei tape la compressione è spesso demandata all hardware, mentre su disco la compressione (così come la deduplica) va gestita esplicitamente e può essere molto importante, dato che permette di ottimizzare gli spazi, ma spesso anche i tempi di ripristino (poiché vi sono meno blocchi da leggere sul disco). D altro canto, l uso di agenti specifici sui server da proteggere ha permesso l aggiunta di funzionalità specifiche per la protezione di diversi applicativi, consentendo quindi sia di salvarne lo stato in modo coerente, ma anche di permettere ripristini granulari su singoli oggetti dell applicativo (ad esempio singole nel caso di un sistema di posta elettronica o singole tabelle di un database). 8

9 La protezione a livello applicativo si è evoluta con l evolversi degli applicativi e si possono quindi trovare prodotti di backup con agenti specifici per SAP, Lotus Domino, Oracle, oltre che per i più comuni prodotti Microsoft. Bisogna però considerare che di norma il backup a livello applicativo viene implementato come un operazione a parte che richiede una sua policy: questo vuol dire che potrebbe richiedere una seconda operazione distinta rispetto a quella del backup a livello file system. In questi casi bisogna gestire esplicitamente regole di esclusione per evitare di trovarsi a sottoporre a backup gli stessi oggetti due volte (in un caso a livello file, in caso a livello applicativo). Alcune versioni più recenti di programmi di backup tradizionali sono oramai in grado, per buona parte degli applicativi, di eseguire tutto in unica passata partendo dal semplice backup a livello file. Ma rimane un esempio di come il programma si sia dovuto evolvere ed adattare alle nuove esigenze. Con l avvento della virtualizzazione gli scenari si sono ulteriormente complicati portando la necessità di dover integrare ulteriore codice all interno della soluzione di backup. Da una primo approccio molto scarno, basato su script, si è passati ad un integrazione più strutturata, ma in alcuni casi stravolgendo la logica di funzionamento del programma di backup e/o delle sue policy. Il passaggio al cloud rimarrà forse il meno traumatico visto che oramai questi programmi hanno subito una grande trasformazione, che però in alcuni casi ha comportato una complicazione della soluzione a livello architetturale e funzionale. In molti casi l aggiunta di funzionalità, come ad esempio la deduplica, ha portato a grossi appesantimenti. Vi è poi un ulteriore aspetto da considerare: in questo tipo di soluzioni ogni opzione, ogni tipo di agente, ogni nuovo server di backup (nel caso di architetture scalabili), ogni nuovo supporto di memorizzazione (ad esempio un ulteriore unità tape all interno della libreria), spesso corrisponde ad una licenza aggiuntiva rendendo quindi complicata e dispendiosa la scelta di quali funzionalità scegliere. Anche qui in alcuni casi vi sono state delle doverose semplificazioni nelle modalità di licenza, ma in generale i listini sono discretamente complicati. Non solo il licensing è complesso, ma spesso anche l architettura l architettura è complessa. Non a caso si stanno diffondendo soluzioni basate su (hardware) appliance dedicati e già preconfigurati per scenari di private cloud. Per scenari di public cloud invece vi sono varie offerte di tipo tipo SaaS (Software-as-a-Service), sia di alcuni vendor sia di aziende di terze parti. Da notare che questo tipo di soluzioni, in generale, implementano solo funzioni di backup (a livello di file e spesso anche a livello applicazione e/o sistema), ma possono implementare anche alcune funzioni di archiviazione (più propriamente potremmo chiamarle funzioni di vaulting). Per contro non implementano funzioni di replica, delegando questo compito ad eventuali appliance di archiviazione. Soluzioni di backup native per la virtualizzazione In questa famiglia possiamo annoverare prodotti nati all interno dell ecosistema di virtualizzazione (che all inizio era prettamente VMware-oriented). Per citare alcune soluzioni storiche erano (e sono): Veeam Backup & Replication, Vizioncore 9

10 (ora Dell Quest) e PhdVirtual. A questi possiamo aggiungere, per dovere di cronaca, almeno le soluzioni entry-level di backup proposte da VMware (VDR prima e VDP da vsphere 5.0 in poi). Queste soluzioni sono relativamente giovani (dato che la virtualizzazione dei sistemi si è imposta solo negli ultimi 10 anni), ma nascendo per un ambiente nuovo hanno avuto la capacità di partire da zero abbandonando qualunque necessità di compatibilità con il passato e soprattutto già focalizzandosi sui nuovi modelli di riferimento delle infrastrutture IT. Lavorando poi in un ecosistema a stretto contatto con il vendor della soluzione di virtualizzazione sono riusciti a implementare, per primi, funzioni specifiche e sfruttarle per implementare in modo ottimale i backup. Semplificando e sintetizzando ai concetti fondamentali il vendor della virtualizzazione espone delle funzionalità per risolvere le diverse problematiche: come gestire il backup delle macchine virtuali comunicando direttamente solo con l host (nel caso di VMware sono le API della famiglia VADP), come gestire il backup di macchine virtuali accese e possibilmente in modo coerente (si combinano tecniche di snapshot a livello di hypervisor e funzioni come il VSS nei guest di tipo Windows), come gestire un backup incrementale delle macchine virtuali (nel caso di VMware si può utilizzare il Changed Block Tracking - CBT introdotto con il virtual hardware 7 di vsphere 4.x) e così via Per maggiori informazioni, consultare il relativo corso (in inglese) sulla Backup Academy. Il backup così ottenuto è di fatto l insieme dei file che rappresentano la macchina virtuale e quindi già rappresenta una forma di system protection (l intera VM può essere ripristinata, anche su un altro host a parità o compatibilità di hypervisor). Ma è possibile, come detto, anche offrire più modalità di restore a fronte di un unico backup a livello immagine: Veeam Backup & Replication offre grande flessibilità per ripristinare intere VM, file guest e/o oggetti applicativi. Figura 3 Opzioni di ripristino disponibili in Veeam Backup & Replication 10

11 Le differenze rispetto ad un approccio tradizionale, dove le macchine virtuali sono trattate come normali macchine fisiche, sono numerose e verranno trattate in maggior dettaglio nel prossimo capitolo. Nascendo come soluzioni che trattano file e in un periodo storico dove la capacità dei dischi era già ben superiore a quella dei nastri, le soluzioni native per la virtualizzazione salvano tipicamente su disco o su share di rete (VMware VDP in realtà salva solo su disco) che potrebbe anche risiedere su un sistema di archiviazione/deduplica (ad esempio HP StoreOnce, DataDomain, ExaGrid ). Da notare che, se è vero che queste soluzioni sono nate per il mondo VMware, alcune hanno esteso la compatibilità ad altri hypervisor. Ad esempio, Veeam Backup & Replication è in grado di supportare nativamente, da una singola console, sia piattaforme VMware vsphere che Microsoft Hyper-V. Le soluzioni native per la virtualizzazione possono ulteriormente migliorare, evolvere ed innovare? Assolutamente sì, ma bisogna capire in quale direzione. Ad esempio cercare di sostituire i prodotti di backup tradizione nel mondo fisico potrebbe essere un potenziale svantaggio perché si rischierebbe di stravolgere il funzionamento di molti di questi sistemi. L approccio virtualization first che molte aziende hanno già adottato prevede a medio termine una virtualizzazione completa dei sistemi e può rendere di fatto non più necessaria la gestione del mondo fisico. Esso infatti potrebbe essere composto (a livello di server) solo da host di virtualizzazione ed eventualmente dai server di backup, benché si possano virtualizzare anche questi. Rimane poi la potenziale necessità di gestire destinazioni di backup che includano i tape, visto che in alcuni casi sono necessari o comunque utili (anche solo come ultimo livello di backup). In questo però l emergente standard Linear Tape File System (LTFS) potrebbe venire a supporto di questo tipo di programmi, trasformando un target di tipo tape in un comune target simile ad un NAS. Veeam Backup & Replication ha annunciato il supporto per unità a nastro a partire dalla prossima versione 7.0, in uscita nel terzo trimestre del Aree di possibile innovazione possono essere l integrazione tra diversi livelli di protezione, ad esempio gestire le snapshot a livello di storage come primo livello di protezione, i backup su disco come secondo livello, le repliche verso un sito remoto e magari il vaulting su dispositivi di vario tipo (da supporti di archiviazione removibile a cloud pubblici) come terzo livello. Se l integrazione tra le funzionalità di backup e replica è oramai comune nei prodotti storici, il resto è ancora un divenire. Ulteriori spazi di miglioramento, volti ad un ottimizzazione delle operazioni, possono esserci nello sfruttare questi diversi livelli anche per eseguire le operazioni di trasferimento dati (ad esempio leggendo da una snapshot su storage piuttosto che dal datastore delle varie VM). In questo senso la funzionalità Veeam Explorer for SAN Snapshots rappresenta un interessante innovazione. Da notare che questo tipo di soluzioni sono, di solito, più semplici (anche a livello architetturale), delle soluzioni tradizionali e quindi non sono previsti hardware appliance dedicati; al più virtual appliance per le soluzioni più entry-level (ad esempio PhdVirtual). Invece, alla pari delle soluzioni tradizionali, possono esistere offerte di tipo public cloud in modalità SaaS. 11

12 Una possibile critica alle soluzioni native è che, apparentemente, non dispongono di un architettura complessa (e potenzialmente scalabile) tipica di alcune soluzioni tradizionali. In realtà la semplicità (o pulizia a seconda dei punti di vista) architetturale può essere vista più come un vantaggio. E comunque, nel caso delle soluzioni basate su virtual appliance, è possibile usare più virtual appliance per parallelizzare le operazioni di backup. Oppure, come è stato il caso di Veeam Backup & Replication dalla versione 6.0 in poi, è possibile scorporare alcuni funzioni del programma in ruoli e server diversi: uno o più proxy server (che assomiglia come concetto ad un misto tra un agente di backup e un secondo server di backup delle soluzioni tradizionali ), il vero e proprio backup server che svolge anche funzioni di console centrale, e uno (o più) target di destinazione o repository server. In questo modo l architettura guadagna in flessibilità e scalabilità, pur garantendo una logica semplice e lineare, visto che tutta la gestione e configurazione è a partire dal server centrale. v6 Pre-v6 Veeam Backup server Esecuzione job Lettura dati Scrittura dati Backup server Administration Load balancing Proxy server Repository server Figura 4 Architettura flessibile e scalabile di Veeam Backup & Replication 6.x Da notare poi che, rispetto alle soluzioni tradizionali, l uso di più virtual appliance o di ruoli separati non richiede licenze aggiuntive. Anzi, in generale il licensing è decisamente più lineare e semplice visto che di norma, va a contare solo il numero di processori fisici degli host di virtualizzazione. In conclusione, una soluzione come Veeam Backup & Replication coniuga i vantaggi delle soluzioni native per la virtualizzazione con quelli dei software tradizionali di backup: semplicità del prodotto (ma non a scapito della funzionalità) con scalabilità assicurata, architettura agentless e specifica per il mondo virtuale, unico backup a livello immagine con restore granulare semplice. 12

13 Aspetti da considerare nei backup Lavorare con la sorgente dei dati In questa parte si considerano e descrivono brevemente i diversi aspetti tecnici legati alla sorgente dei dati e a come il software di backup può attingere. Modalità agent-less Come già descritto i programmi tradizionali nella forma centralizzata utilizzano opportuni agenti (o client) per mettere in comunicazione il server di backup con i sistemi da proteggere. Il problema è che spesso questi agenti comportano un impatto sulle prestazioni del sistema protetto (sia in termini di memoria che di processore, ma anche della rete) oltre che poter comportare problemi di compatibilità oltre che di gestibilità legata al deployment e/o aggiornamento degli agenti. In particolare le attività di gestione degli agenti possono richiedere riavvi dei sistemi (soprattutto in ambito Windows) che va contro le esigenze di uptime elevati e ai crescenti requisiti nella continuità di servizio (non a caso anche VMware ha cambiato la funzionalità di aggiornamento delle VMware Tools che a partire da vsphere 5.1 in molti casi non richiede più riavvii). Per contro i programmi che gestiscono il backup di ambienti virtuali possono lavorare con le funzioni dell hypervisor o con un agente installato sull hypervisor (come ad esempio le soluzioni che lavorano con Microsoft Hyper-V) oppure sfruttandone le relative API (come è normalmente il caso delle soluzioni di backup per VMware vsphere). In entrambi i casi non è necessario installare un agente nelle macchine virtuali poiché le funzioni di backup vengono gestite in offload dallo strato di virtualizzazione. Questo ottimizza le risorse necessarie a svolgere i backup: si pensi all impatto che avrebbero i diversi agenti installati in decine e decine di macchine virtuali su un singolo host. Modalità Network-free (o LAN-free ) Tipicamente i dati viaggiano dalla sorgente al sistema di backup attraverso la rete (dedicata o condivisa). Ma se i dati risiedono su uno storage centralizzato questi potrebbero (in teoria) essere trasferiti direttamente dallo storage usando altri tipi di connessioni. Poiché nelle architetture di virtualizzazione lo storage condiviso è un requisito fondamentale per molte funzioni (si pensi all HA o alla distribuzione di carico) questa può diventare un interessante opportunità. Il caso forse più significativo è quello di uno storage basato su SAN FC: in questo caso è possibile realizzare server di backup fisici con relative connessioni in fibra verso lo storage e usare quella per il vero trasferimento dei dati (limitando l uso della rete locale solo per inizializzare le operazioni). In questo caso abbiamo un offload praticamente completo del backup. Un passo successivo sarebbe poi usare direttamente le snapshot a livello di SAN per lavorare su quei dati e non sulle snapshot a livello di hypervisor (come normalmente avviene). 13

14 Ottimizzazione della sorgente Il tipo di risorsa da proteggere richiede ottimizzazioni diverse e in alcuni casi persino operazioni diverse. Si pensi ad un database che potrebbe essere gestito come backup di tutti i blocchi dati che lo compongono oppure di semplice esportazione di tutte le sue tabelle e relativi oggetti. Ma nel mondo virtuale i programmi di backup partono sempre dall immagine della macchina virtuale e livelli più dettagliati e granulari a livello di file o di oggetti applicativi richiedono o l ispezione del contenuto delle immagini dei dischi virtuali o l uso di agenti in ogni sistema guest per esportare le informazioni richieste in modo esplicito. Il secondo approccio comporta sia gli svantaggi dell uso di agenti (descritti in precedenza), sia lo svantaggio del richiedere più fasi o step nelle operazioni di backup: una per il backup a livello sistema e una per il backup a livello applicativo, con conseguente spreco di risorse e duplicazione di informazioni (anche se a livelli diversi). Ci sono poi da considerare diversi aspetti caratteristici dei backup di macchine virtuali che sono legati al contenuto del disco virtuale. Il disco non necessariamente è completamente pieno e quindi trasferire i blocchi non usati non avrebbe senso (in questo casi si stanno considerando dischi thick, visto che nei dischi di tipo thin la dimensione del disco varia in funzione dell utilizzo). C è poi da considerare che i blocchi occupati nel disco virtuale non sempre corrispondono allo spazio effettivamente occupato: la cancellazione di un file non comporta la liberazione ( reclaim ) dei relativi blocchi. In questo caso le uniche opzioni sono riazzerare i blocchi a livello di guest (e poi liberarli a livello di hypervisor) oppure fare in modo che il programma di backup sia in grado di interpretare il filesystem guest e scartare le parti non utili. C è infine un ultimo aspetto da considerare sul contenuto dei dischi virtuali: non tutti i blocchi scritti sono rilevanti per un restore. È il caso, ad esempio, del contenuto dei file (o delle partizioni) di paginazione che hanno ben poca utilità nelle operazioni di ripristino e che programmi come Veeam Backup & Replication sono in grado di escludere automaticamente dai backup. Ottimizzazione del trasferimento Per minimizzare il trasferimento dei dati si possono usare tecniche derivate dal mondo tradizionale come la compressione o il trasferimento incrementale o tecniche più recenti quali la deduplica. Partendo dal trasferimento incrementale, è chiaro che non possono essere usate le funzionalità dei programmi tradizionali dove tipicamente il grado di dettaglio si fermerebbe ai file: da un operazione di backup ad un altra si avrebbe ogni volta il trasferimento completo dei file relativi ai dischi virtuali, a fronte di piccole porzioni effettivamente modificate. Il dettaglio deve arrivare a livello di singolo blocco in modo da poter gestire solo il trasferimento delle differenze. Per ambienti vsphere questa funzione è già fornita dalle API di VMware (tecnologia CBT), ma per ambienti Microsoft Hyper-V questa funzione non viene fornita di base (benché sia comunque implementabile e programmi come Veeam Backup & Replication hanno infatti sviluppato funzionalità proprietarie di tracciamento dei blocchi modificati). Compressione e deduplica (oltre che ottimizzazione della sorgente) possono aiutare a ridurre ulteriormente i dati in transito. In particolare entrambe le 14

15 tecniche possono potenzialmente essere usate sia lato sorgente (per ridurre i dati da trasferire), sia lato destinazione (per ridurre i dati da salvare). La deduplica inoltre può lavorare in-line (ossia in tempo reale ) oppure postprocess (periodicamente). Vi sono diversi algoritmi di deduplica, alcuni dei quali possono essere combinati con altre soluzioni di deduplica e/o di compressione. Consistenza dei backup Uno dei problemi legati ai backup è quanto poi siano utilizzabili e validi in fase di restore: questo non dipende solo dalla bontà delle procedure di restore (che commenteremo dopo), ma anche dalla bontà dei dati salvati. Si parla di consistenza per definire il grado di validità di questi dati. Vengono definiti diversi livelli di consistenza: crash-consistent (stessa consistenza di un sistema fisico o virtuale che viene spento in modo inatteso), file system-consistent (situazione dove almeno i file, o i metadati dei file, sono integri), e application-consistent (situazione dove i dati applicativi e/o dei servizi sono integri). I prodotti tradizionali gestiscono la consistenza usando agenti specifici che conoscono le diverse applicazioni e sono in grado di esportarne i dati in modo integro. Ma in realtà l ambiente di virtualizzazione può fornire funzioni per garantire un qualche livello di consistenza: la snapshot a livello di hypervisor è normalmente di tipo crash-consistant, ma con funzioni particolari (come la quiescenza VMware Tools) può diventare consistente a livello di file system o anche a livello applicativo (usando tecnologie proprie dei sistemi operativi come il VSS e/o script pre/post snapshot). Quindi anche un prodotto completamente agent-less è potenzialmente in grado di gestire la consistenza corretta dei backup. Veeam Backup & Replication offre nativamente la consistenza applicativa nel mondo Windows tramite VSS e la possibilità di prevedere script pre/post snapshot. Figura 5 Opzioni di quiescenza VSS e indicizzazione file system in Veeam Backup & Replication 15

16 Lavorare con la destinazione dei backup In questa parte si considerano e descrivono brevemente i diversi aspetti tecnici legati alla destinazione (o repository) per i backup, che può variare da un semplice storage a blocchi localeo condiviso, ad un fileserver o storage di tipo NAS, fino ad arrivare ad appliance specifici. Formato dei backup Il primo requisito del formato di salvataggio dei backup è che garantisca l integrità dei backup. Legato a questo requisito è quello di avere, se possibile, la massima semplicità nei file usati, nel loro numero e nel loro nome. Questo può semplificarne la gestione, permetterne l eventuale archiviazione, e magari anche la migrazione da un server di backup ad un altro. Il secondo requisito è essere in grado di ottimizzare gli spazi richiesti e da questo punto di vista si possono delineare diverse modalità di salvataggio a partire da un backup completo: Incremental: il primo file è di tipo full e tutti gli altri sono dei semplici deltafile incrementali. Incremental with synthetic full: simile al precedente, ma periodicamente viene ri-calcolato un nuovo backup full. Reversed incremental: ad ogni backup viene ri-calcolato un nuovo file full (che diventa l ultima versione) e tutti i file precedenti sono creati come deltafile incrementali. Incremental with a single synthetic full: di fatto è un misto tra l incremental e il reversed incremental, dove periodicamente viene ri-calcolato un full; prima e dopo sono tutti delta-file incrementali. Non è stato citato il formato differenziale (e le sue varianti) perché rappresentano un ottimizzazione dello spazio peggiore rispetto al caso incrementale. Inserito nel Synthetic Full Active Full Incrementale Incrementale Incrementale Incrementale Incrementale Synthetic Full Incrementale File VBK (nuovo) File VIB Blocchi invariati Blocchi incrementali GB Esecuzione job File VBK File VBK File VBK File VBK File VBK File VBK - L Archive Bit rimane invariato durante la creazione del file.vbk - Il Synthetic Full viene eseguito nel giorno specificato e modifica il file.vbk - I blocchi invariati del file.vbk precedente vengono mantenuti e vengono aggiunti i contenuti dei file.vib - Questa operazione modifica l Archive Bit Figura 6 Modalità "Incremental with Synthetic Full" di Veeam Backup & Replication 16

17 La scelta del tipo di formato può essere in funzione delle necessità di restore, di quelle di riduzione dello spazio lato target, o magari dettate dal tipo di target (ad esempio alcuni appliance di archiviazione che implementano funzioni come deduplica e compressione ottengono risultati migliori con un formato piuttosto che un altro). Deduplica lato target Come descritto in precedenza, la deduplica può agire sia a livello sorgente che a livello destinazione con finalità distinte. I programmi tradizionali, essendo nati per lavorare su tape non prevedevano la deduplica lato destinazione e generalmente hanno aggiunto questa funzionalità (nel caso di backup su disco) con l aggiunta di nuove componenti software (o delegando il compito ad altri servizi/appliance). I programmi nativi per la virtualizzazione sono invece nati quasi tutti già con funzioni di deduplica lato destinazione in modo da ottimizzare lo spazio richiesto ai file di salvataggio dei backup. Nulla vieta di implementare la deduplica con sistemi esterni, come ad esempio le nuove funzionalità di Windows Server 2012 o appliance dedicati. In questo caso però è importante capire come la deduplica a livello di programma di backup e quella esterna possono coesistere. Veeam Backup & Replication ad esempio fornisce un livello chiamato Dedupe-Friendly appositamente studiato per questi scenari. Deduplica source + target Veeam, nel suo prodotto Backup & Replication, ha sviluppato un sistema di deduplica a due fasi, sia source che target. Questo consente di minimizzare il traffico di rete durante il backup e/o la replica aspetto molto importante quando si effettuano trasferimenti su reti geografiche (WAN), spesso ad alta latenza e con limitate capacità di banda. Nella prima fase di deduplica, il proxy Veeam deduplica al livello di singolo disco virtuale in corso di elaborazione: se il blocco analizzato esiste già in un qualsiasi punto di ripristino per il job in corso, non viene trasferito nuovamente verso il repository. Nella seconda fase, il repository Veeam deduplica a livello di intero job: se il blocco analizzato esiste già in un qualsiasi altro disco di qualsiasi altra VM all interno del job in corso (quindi all interno del punto di ripristino in via di creazione), non viene salvato nuovamente su disco. Aspetti da considerare nei restore Come diminuire i tempi di restore? Una delle necessità fondamentali legate ad un attività di ripristino è che questa sia la più veloce possibile (per rispettare gli obiettivi della data protection, primo tra tutti l RTO). Questo impone una soluzione di backup con buone prestazioni di lettura, ma anche e soprattutto un buon formato di memorizzazione che richieda il minimo overhead nel recuperare le informazioni richieste. Ovviamente 17

18 funzioni come lo staging su aree temporanee possono comportare ulteriori rallentamenti indesiderati. C è poi l aspetto legato al rendere disponibile e operativo il servizio: nel caso di una macchina virtuale vuol dire ripristinarne i file, registrarli nell hypervisor ed eseguirla. Essendo i file di solito di grandi dimensioni questo spesso richiede tempo. Un alternativa interessante è quella di usare il server di backup e i dati in esso presenti per rendere operativa la macchina virtuale, usando temporaneamente uno storage locale (quello del backup server). Questa soluzione, che Veeam chiama vpower Instant VM Recovery (che poi molti altri hanno adottato), ha il grosso vantaggio di rendere subita operativa la macchina (con quindi RTO molto bassi). Per contro lo storage non è quello ottimale ma essendo in temporanea situazione di emergenza qualche compromesso potrebbe essere accettato. Successivamente con un operazione di Storage vmotion (o di Live Storage Migration se siamo su Hyper-V) è possibile riportare la macchina sullo storage desiderato senza alcuna interruzione. Per chi non dispone della licenza di VMware Storage vmotion1, Veeam ha introdotto una sua funzione simile, chiamata Quick Migration, che prevede un leggero disservizio durante lo spostamento. Verificare i restore Disporre dei backup e non controllarne la validità equivale, potenzialmente, a non avere alcun backup. Si dovrebbe partire dalla verifica del media dove è salvato il backup, ma da questo punto di vista i backup su disco rappresentano una semplificazione rispetto ai backup su tape, soprattutto perché è possibile adottare soluzioni di ridondanza che permettano di perdere almeno un disco. Poi si dovrebbe passare alla verifica dell integrità dei formati di backup o avere formati che non richiedano queste verifiche periodiche (si riveda il discorso precedente sui formati di backup). Inoltre è necessario effettuare un test di restore. Ma anche questo passo potrebbe non bastare, dato che nella maggior parte dei casi è va verificata la disponibilità di un servizio e non i dati in sé per sé. Su questo aspetto possono risultare utili tecnologie come quelle implementate da Veeam (chiamata SureBackup) per la verifica automatica dei backup: in questo caso è possibile eseguire il restore di una o più VM in un ambiente separato e verificarne il corretto funzionamento. L aspetto interessante è che questo ambiente (chiamato Virtual Lab ) si presta anche ad altri usi non strettamente legati alle attività di backup/restore, come ad esempio ambienti di test, audit, penetration test, La reportistica gioca poi un ruolo importante. Tutti i programmi di backup (e non solo quelli) generano report in vario modo, di solito via . Spesso, sommando tutti i diversi sistemi, tra allarmi, notifiche, falsi positivi queste mail di gestione possono risultare dispersive. 1 Il licensing è comunque cambiato in modo favorevole con la nuova versione vsphere

19 Diventa quindi fondamentale, specialmente in ambienti di medie e grandi dimensioni, integrare la parte di backup con la parte di monitoraggio in modo da avere un unico punto per la gestione di queste informazioni. Ad esempio, Veeam Backup & Replication si integra con Veeam ONE (nelle reciproche ultime versioni) in modo da includere il monitoraggio delle funzionalità di backup. Veeam ONE è anch esso un prodotto creato appositamente per infrastrutture virtuali, che offre una gestione completa dell ambiente grazie a monitoraggio e reportistica potenti e facili da utilizzare. La Veeam Backup Management Suite offre allarmi personalizzati sullo stato dei job di backup (con allarmi specifici sul loro esito e sulla loro durata rispetto a soglie prefissate), report sulle eventuali VM non protette e sull esito dei job di verifica del restore ( SureBackup ), nonché funzioni di capacity planning sui repository di backup che aiutano a prevedere nel tempo l occupazione delle risorse. Figura 7 Report "Protected VMs" di Veeam ONE, per Veeam Backup & Replication Restore granulari Parlando dei tempi di restore si è trattato prevalentemente il caso di ripristino di intere macchine virtuali, in molti casi tuttavia è necessario soltanto il ripristino di uno o più file all interno del sistema guest o di qualche oggetto applicativo. Quest ultimo rappresenta sicuramente una sfida: questa funzione deve essere efficace, possibilmente veloce (e magari senza bisogno di staging temporanei, che aumentano i tempi di restore e i requisiti di spazio), ma è fondamentale che sia anche semplice. E forse è proprio l ultimo l aspetto più difficile: i programmi di backup tradizionali spesso hanno procedure di ripristino a livello applicativo estremamente lente e macchinose, che richiedono conoscenze approfondite dell applicativo di cui si vogliono ripristinare gli oggetti. 19

20 Invece l operatore del ripristino dovrebbe solo concentrarsi sulla ricerca degli oggetti perduti e sul dove ripristinarli, senza perdere tempo in step intermedi. Da questo punto di vista, ritengo che la strada delineata da funzioni come Veeam Explorer for Exchange rappresenti il giusto approccio. Cloud Backup un futuro già presente Negli ultimi anni sono state introdotte sul mercato svariate offerte di Cloud Storage, ovvero spazio disco offerto come servizio da parte di Cloud Providers. Un interessante uso di questi servizi è sicuramente il backup: sempre più aziende, grandi e piccole, scelgono di memorizzare una seconda copia del proprio backup in un sito remoto, debitamente protetto con livelli di servizio (SLA) concordati e senza dover investire in locali e infrastrutture. Le spese capitali (CapEx) vengono quindi ridotte e trasformate in spese operative (OpEx), dato che i provider fatturano, di norma su base mensile, il servizio Cloud Storage sulla base di quanto effettivamente utilizzato. Le soluzioni native per la virtualizzazione avranno maggiore facilità nell integrarsi con scenari di questo tipo, abilitando il concetto di hybrid cloud : coesistenza di private cloud (infrastruttura proprietaria) e public cloud (infrastruttura condivisa erogata come servizio da un provider). Ad esempio, Veeam ha annunciato di recente il proprio prodotto Veeam Backup & Replication Cloud Edition, che consentirà di sincronizzare i propri backup verso un Cloud Storage, scegliendo tra più di 15 Cloud Providers di diversi Paesi del mondo. Saranno disponibili funzionalità di Encryption e compressione, nonché controlli sul traffico di rete. Inoltre, impostando il costo del servizio nell interfaccia del programma sarà possibile calcolare la spesa relativa al proprio Cloud Backup in tempo reale ed impostare limiti di spesa oltre i quali interrompere la sincronizzazione. Alcune soluzioni di backup tradizionali offrono una replica dei file di backup su infrastruttura cloud, ma nella maggior parte dei casi verso infrastrutture proprietarie, per le quali non esistono connettori software e delle quali non si conoscono, a priori, i livelli di servizio. Il poter scegliere tra una serie di provider che offrono servizi consolidati e standardizzati, unitamente alla flessibilità e libertà di utilizzo, è molto interessante sia dal punto di vista tecnico che economico. 20