La TempesTa perfeTTa: è iL momenTo deLL'open source - Magirus

More documents

Recommendations

Info

4 Virtualisation Backup di nuova generazione per le infrastrutture virtuali Alessandro Perilli Industry Analyst, Founder of virtualization.info Alessandro Perilli è un analista indipendente specializzato sul mercato della virtualizzazione. Nel 2003 ha fondato il sito virtualization. info (http://www.virtualization.info) che oggi rappresenta uno dei principali punti di riferimento del settore. Alessandro analizza le attività di oltre centocinquanta vendor, dai leader di mercato alle startup emergenti, i nuovi trend di mercato e le sfide tecnologiche che l’adozione della virtualizzazione comporta. Alessandro spesso opera come advisor per multinazionali, solution provider e società di venture capital in Europa e Nord America. alessandro.perilli@virtualization.info Attualità Eseguire il backup dei dati in un data center virtuale non è mai stata un’operazione banale. Adottare un prodotto tradizionale, pensato e sviluppato per i server fisici, è decisamente inefficiente e a volte nemmeno possibile. L’approccio più semplice, e a volte apparentemente più economico, al problema infatti consiste nell’installazione di un agente di backup all’interno di ogni macchina virtuale che si vuole proteggere. Questa scelta però comporta vari problemi. Innanzitutto installare molteplici agenti rappresenta uno spreco inutile di risorse fisiche del virtualization host. Lo stesso componente software viene replicato tante volte quante sono le macchine virtuali (VM), e ogni istanza ha bisogno di RAM e spazio disco. Certo, stiamo parlando di un quantitativo esiguo per agente, ma moltiplicato per dieci, quindici o venti VM, diventa un ammontare considerevole che potrebbe altrimenti essere usato per creare una VM in più. Il secondo problema consiste nel fatto che gli agenti operano in maniera indipendente e possono eseguire il backup delle macchine virtuali tutti contemporaneamente. Questo ovviamente può avere un impatto significativo sulle prestazioni del virtualization host, può impegnare una parte notevole della banda di rete a disposizione, e può allungare notevolmente i tempi di backup. Ci sono degli accorgimenti per ridurre questi effetti: dotare ogni VM di una virtual NIC in più, assegnare questa vNIC ad una scheda di rete fisica dedicata al solo backup, e schedulare accuratamente il backup di ogni VM in maniera che non si sovrapponga agli altri. Ma questa soluzione non scala: ogni volta che si crea una nuova VM in un certo host, la schedulazione dei backup per quell’host deve essere completamente rivista. Inoltre la finestra di backup può variare significativamente in base a come cambia la dimensione del disco virtuale di ogni VM, e giacchè questo cambiamento non è facilmente predicibile, è difficilissimo schedulare dei backup che non si sovrappongano. Dulcis in fundo, c’è il rischio concreto che lo scenario descritto sin qui non sia contemplato da un certo produttore. Non tutti i vendor infatti dichiarano di supportare l’esecuzione dei loro agenti di backup all’interno di macchine virtuali. E se si è fuori supporto, o si rinuncia al prodotto, o si è pronti a replicare lo scenario su una macchia fisica prima di chiamare l’assistenza tecnica in caso di problemi. E’ chiaro che sarebbe molto più efficiente avere un singolo agente che operasse al livello dell’hypervisor, eseguendo il backup di molteplici VM con un consumo molto più ridotto di risorse. Ed è precisamente su questo che vendor come Vizioncore, Veeam e VMware si sono focalizzati finora. Purtroppo però anche questo approccio implica una serie di problematiche da tenere in considerazione. La prima generazione di prodotti per il backup di data center virtuali richiedeva che le VM fossero temporaneamente spente prima di effettuare l’operazione. Questo perchè l’attività di backup di un sistema operativo in esecuzione necessita di speciali accorgimenti per manipolare i file che sono in uso da una certa applicazione. Ovviamente questa opzione è accettabile solo se si sta parlando di VM che non contengono alcun servizio critico e dove è quindi accettabile avere downtime di qualche minuto o ora. Ma anche qui, la soluzione non scala affatto giacchè è l’amministratore che deve manualmente spegnere al momento opportuno le VM su cui eseguire il backup e riaccenderle appena questo è terminato. Attraverso l’impiego di tecniche diverse, già usate dai prodotti di backup tradi-
– Segue zionali, come l’uso del Volume Shadow Service (VSS), sviluppato da Microsoft, è stato possibile arrivare ad offrire, anche per i data center virtuali, il cosiddetto live backup: l’amministratore non è costretto a spegnere alcuna VM e la soluzione di backup lavora, attraverso un singolo agente, in assoluta trasparenza. E’ qui che ci siamo fermati in termini di evoluzione tecnologica. L’uso del Volume Shadow Service è una soluzione ancora tutt’altro che ottimale. Innanzittutto il VSS è disponibile solo per i sistemi operativi Windows. Ma quel che è peggio è che la presenza di tale servizio da sola non basta per garantire un live backup integro: le applicazioni all’interno della VM infatti devono supportarlo, e permettere all’agente di sfruttarlo per eseguire il backup dei file in uso. VSS è supportato da molti meno ISV di quanto ci si auspicherebbe ed in più questa tecnologia in generale non garantisce mai che il sistema operativo venga ripristinato correttamente al 100%. In un live backup infatti, è pur sempre vero che l’ambiente viene salvato mentre determinate condizioni sono vere (la virtual RAM è popolata da certi valori, ci sono dei dati in transito sulla virtual NIC, ecc.) e riattivato quando queste condizioni non sono più vere. Così non c’è modo di verificare se l’operazione di restore ripristina un sistema operativo perfettamente funzionante o no finchè non si esegue davvero. Il problema è che sono pochissime le aziende che eseguono verifiche periodiche degli archivi di backup, sia perchè l’attività richiede tempo e uomini a disposizione, sia perchè essa necessita di una infrastruttura di test dove eseguire i restore da validare. Quelle poche aziende che si cimentano, devono comunque accontentarsi di test a campione, che sono solo marginalmente utili. Per risolvere questo problema, entrano in gioco tecniche di backup di nuova generazione che stanno per arrivare sul mercato e che finalmente cominciano a sfruttare i vantaggi della virtualizzazione in maniera innovativa. Entro la fine di quest’anno infatti avremo dei nuovi prodotti che eseguono il live backup delle VM e ne testano immediatamente il restore, in maniera automatica e senza operare su un campione limitato. L’idea è piuttosto semplice. Dato un live backup appena eseguito, il prodotto mappa l’archivio relativo nel data center virtuale come se fosse una nuova unità di storage. Dall’archivio mappato estrae la VM che intende verificare e ne esegue il suo restore nell’infrastruttura virtuale di produzione, seguendo l’iter standard di disaster recovery. Ovviamente, per evitare di modificare lo stato dell’ambiente nell’archivio, il virtual hard disk della VM rimane in sola lettura, e tutto quello che accade durante il restore viene salvato in un cosiddetto disco delta che poi verrà eliminato. Allo stesso modo, la macchina virtuale di backup viene ripristinata in una rete virtuale completamente isolata, per evitare che il suo indirizzamento IP entri in conflitto con quello della corrispondente VM di produzione, e per evitare di generare traffico nella rete. Completato il ripristino, il prodotto di backup esegue un ciclo di verifiche sul corretto funzionamento dell’ambiente, e poi lancia uno o più script definiti dall’amministratore per verificare altri dettagli specifici del sistema. Qui l’amministratore può richiedere il controllo di qualunque aspetto di una o più applicazioni o del guest OS stesso, dallo stato dei servizi alla presenza di certe variabili in file temporanei. Attualità Una volta completata l’operazione di verifica, e generato un rapporto che sarà inviato all’amministratore, la macchina virtuale di backup viene spenta, il suo disco delta distrutto, e l’archivio rimosso dalle unità di storage disponibili nell’infrastruttura virtuale. L’intero ciclo di verifica, per quanto necessiti di risorse dedicate, è certamente più semplice e veloce da eseguire rispetto al controllo manuale dei restore in ambienti di test dedicati, e può essere attivato per ogni singolo backup. Per quanto possibile, replicare queste operazioni in una infrastruttura fisica sarebbe molto più complesso, lungo e costoso. Grazie alla virtualizzazione (e all’automazione) invece la verifica dei restore non solo diventa tecnicamente ed economicamente possibile, ma anche altamente desiderabile. Presto nei nostri data center. Virtualisation 5
Page 1 and 2: Innovation in IT Distribution Techn
Page 3: Cari lettori, ho il piacere di apri
Page 7 and 8: Avocent Corporation leader a livell
Page 9 and 10: - Segue Consolidamento e virtualizz
Page 11 and 12: Red Hat è lieta di invitarLa all
Page 13 and 14: - Segue hanno acquistato la licenza
Page 15 and 16: Fuori, la solidità della tecnologi
Page 17 and 18: - Segue geografico degli ambienti s
Page 19 and 20: Attualità Tecnologie: Clienti, DlP
Page 21 and 22: Redazionale Juniper Networks dà vi
Page 23 and 24: Rischi normativi per le aziende der
Page 25 and 26: Case Study AuSl di Piacenza si affi
Page 27 and 28: - Segue D: Come si sono evolute le
Page 29 and 30: Professional Services uno sguardo s
Page 31 and 32: l’offerta prodotti e servizi di M

La TempesTa perfeTTa: è iL momenTo deLL'open source - Magirus

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?