05.11.2012 Views

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

SHOW MORE
SHOW LESS

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-

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!