La TempesTa perfeTTa: è iL momenTo deLL'open source - Magirus
La TempesTa perfeTTa: è iL momenTo deLL'open source - Magirus
La TempesTa perfeTTa: è iL momenTo deLL'open source - Magirus
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
4<br />
Virtualisation<br />
Backup di nuova generazione per<br />
le infrastrutture virtuali<br />
Alessandro Perilli<br />
Industry Analyst,<br />
Founder of virtualization.info<br />
Alessandro Perilli <strong>è</strong> un analista indipendente<br />
specializzato sul mercato della virtualizzazione.<br />
Nel 2003 ha fondato il sito virtualization.<br />
info (http://www.virtualization.info) che oggi<br />
rappresenta uno dei principali punti di riferimento<br />
del settore.<br />
Alessandro analizza le attività di oltre centocinquanta<br />
vendor, dai leader di mercato alle<br />
startup emergenti, i nuovi trend di mercato e<br />
le sfide tecnologiche che l’adozione della virtualizzazione<br />
comporta.<br />
Alessandro spesso opera come advisor per<br />
multinazionali, solution provider e società di<br />
venture capital in Europa e Nord America.<br />
alessandro.perilli@virtualization.info<br />
Attualità<br />
Eseguire il backup dei dati in un data center<br />
virtuale non <strong>è</strong> mai stata un’operazione<br />
banale. Adottare un prodotto tradizionale,<br />
pensato e sviluppato per i server fisici, <strong>è</strong><br />
decisamente inefficiente e a volte nemmeno<br />
possibile.<br />
L’approccio più semplice, e a volte apparentemente<br />
più economico, al problema<br />
infatti consiste nell’installazione di un<br />
agente di backup all’interno di ogni macchina<br />
virtuale che si vuole proteggere.<br />
Questa scelta però comporta vari problemi.<br />
Innanzitutto installare molteplici agenti<br />
rappresenta uno spreco inutile di risorse<br />
fisiche del virtualization host. Lo stesso<br />
componente software viene replicato tante<br />
volte quante sono le macchine virtuali<br />
(VM), e ogni istanza ha bisogno di RAM e<br />
spazio disco. Certo, stiamo parlando di un<br />
quantitativo esiguo per agente, ma moltiplicato<br />
per dieci, quindici o venti VM,<br />
diventa un ammontare considerevole che<br />
potrebbe altrimenti essere usato per creare<br />
una VM in più.<br />
Il secondo problema consiste nel fatto che<br />
gli agenti operano in maniera indipendente<br />
e possono eseguire il backup delle macchine<br />
virtuali tutti contemporaneamente.<br />
Questo ovviamente può avere un impatto<br />
significativo sulle prestazioni del virtualization<br />
host, può impegnare una parte<br />
notevole della banda di rete a disposizione,<br />
e può allungare notevolmente i tempi<br />
di backup.<br />
Ci sono degli accorgimenti per ridurre<br />
questi effetti: dotare ogni VM di una virtual<br />
NIC in più, assegnare questa vNIC<br />
ad una scheda di rete fisica dedicata al<br />
solo backup, e schedulare accuratamente<br />
il backup di ogni VM in maniera che<br />
non si sovrapponga agli altri. Ma questa<br />
soluzione non scala: ogni volta che si crea<br />
una nuova VM in un certo host, la schedulazione<br />
dei backup per quell’host deve<br />
essere completamente rivista. Inoltre la<br />
finestra di backup può variare significativamente<br />
in base a come cambia la dimensione<br />
del disco virtuale di ogni VM, e giacch<strong>è</strong><br />
questo cambiamento non <strong>è</strong> facilmente<br />
predicibile, <strong>è</strong> difficilissimo schedulare dei<br />
backup che non si sovrappongano.<br />
Dulcis in fundo, c’<strong>è</strong> il rischio concreto<br />
che lo scenario descritto sin qui non sia<br />
contemplato da un certo produttore. Non<br />
tutti i vendor infatti dichiarano di supportare<br />
l’esecuzione dei loro agenti di backup<br />
all’interno di macchine virtuali. E se si <strong>è</strong><br />
fuori supporto, o si rinuncia al prodotto,<br />
o si <strong>è</strong> pronti a replicare lo scenario su una<br />
macchia fisica prima di chiamare l’assistenza<br />
tecnica in caso di problemi.<br />
E’ chiaro che sarebbe molto più efficiente<br />
avere un singolo agente che operasse<br />
al livello dell’hypervisor, eseguendo il<br />
backup di molteplici VM con un consumo<br />
molto più ridotto di risorse. Ed <strong>è</strong> precisamente<br />
su questo che vendor come Vizioncore,<br />
Veeam e VMware si sono focalizzati<br />
finora. Purtroppo però anche questo<br />
approccio implica una serie di problematiche<br />
da tenere in considerazione.<br />
<strong>La</strong> prima generazione di prodotti per il<br />
backup di data center virtuali richiedeva<br />
che le VM fossero temporaneamente spente<br />
prima di effettuare l’operazione. Questo<br />
perch<strong>è</strong> l’attività di backup di un sistema<br />
operativo in esecuzione necessita di speciali<br />
accorgimenti per manipolare i file che<br />
sono in uso da una certa applicazione.<br />
Ovviamente questa opzione <strong>è</strong> accettabile<br />
solo se si sta parlando di VM che non<br />
contengono alcun servizio critico e dove<br />
<strong>è</strong> quindi accettabile avere downtime di<br />
qualche minuto o ora. Ma anche qui,<br />
la soluzione non scala affatto giacch<strong>è</strong> <strong>è</strong><br />
l’amministratore che deve manualmente<br />
spegnere al momento opportuno le VM su<br />
cui eseguire il backup e riaccenderle appena<br />
questo <strong>è</strong> terminato.<br />
Attraverso l’impiego di tecniche diverse,<br />
già usate dai prodotti di backup tradi-