Ieri ho partecipato ad un breve corso che illustrava le potenzialità di VMware ESX Server (stupendo prodotto se si ha un ced affollato). Ad un certo punto durante una domanda su come fare copie “a caldo” delle immagini VDMX il relatore ha detto semplicemente che, oltre alle soluzioni “commerciali” (e molto costose), si può semplicemente sfruttare nella macchina virtuale il RAID software di che tutti i sistemi operativi di ultima generazione offrono.
Il principio è molto semplice, nella configurazione della macchina virtuale aggiungo due HD, uno avrà il file che punterà nel nostro server dove gira ESX o Vmware Server, e l’altro su una directory di una macchina remota (montata ad esempio in NFS).
A questo punto all’interno del sistema virtuale configureremo il RAID 1 software tra i due harddisk e ci ritroveremo con una sorta di copia a caldo sempre aggiornata. Se poi vogliamo esagerare possiamo montare un terzo hd virtuale e su questo salvare i backup incrementali dei dati della macchina virtuale.
Ovviamente il tutto era spiegato per l’ESX Server, ma anche su un normale VMware server freeware il ragionamento funziona benissimo e permette di avere un pochino più di sicurezza per chi vuole virtualizzare non avendo a disposizione grossi fondi da investire.
Sempre a riguardo VMware vi consiglio anche un giro qui dove sono presenti una dozzina di macchine virtuali preconfigurate e scaricabili via bittorrent.
ciuaz
8 replies on “VMware, ridondanza e backup”
Però forse con una copia a caldo si intende avere anche una copia statica (da poter ripristinare in caso di disastri non solo hardware ;-) il raid 1 non fa niente di più che proteggerci da un guasto del disco.
Hai mai provato Xen? La versione open source è un prodotto meno immediato da utilizzare di vmware server free, ma sicuramente con prestazioni e flessibilità nettamente superiori e con un hardware abbastanza recente puoi installare qualsiasi sistema operativo guest.
In questo caso per fare delle vere copie a caldo puoi usare gli snapshot lvm più un semplice dd.
ciao
si ma essendo i due “dischi virtuali” su dischi fisici diversi in caso di failure hw di uno dei due il sistema continua a funzionare indipendentemente.
Se poi metti copia della configuazione della macchina virtuale su un paio di server differenti e fai in modo che una parta appena l’altra muore hai risolto anche il problema di disastri un pochino maggiori.
XEN (per ora) non lo considero perchè è troppo OS dependant. Io voglio migrare la macchina virtuale da un sistema all’altro senza dover avere troppe preoccupazioni, e con vmware * mi basta copiare i file vmdx
Per quanto riguarda le snapshot le puoi fare anche con vmware, ma non rappresentano i dati “istantanei” che magari potrebbero essere utili per lavorare.
ah, già… il tutto è presupponendo che il FS utilizzato sia “serio” e non perda dati e consistenza ad un “qualsiasi riavvio brutale” ;)
Allora se ho ben capito per “copia a caldo” si intendeva un vero e proprio mirroring del disco virtuale, esattamente il RAID 1.
Ma ho ancora qualche dubbio sull’idea di “copia a caldo” e sulla soluzione proposta. Con questa il mirror lo fa il sistema guest e la macchina ospitante (come si chiama con la terminologia vmware?) si ritrova due file vmdx da mettere su 2 dischi diversi. Ma se il file vmdx lo mettevo direttamente su un disco già mirrorato (in hardware o in software dal sistema ospitante) cosa ci perdevo? La seconda copia del file ce l’ho lo stesso, solo che è gestita in modo trasparente. Mettere il mirror sulla macchina guest mi sembra un aumento di complessità, sicuramente piccolo ma se non da benefici a che serve … Mi sfugge qualcosa?
Forse l’unico caso dove può avere senso è per piccole situazioni di test (quindi niente ESX del quale si discuteva nel corso) quando vmware server free gira su windows XP (niente RAID 1 in software) e non dispongo di hardware che possa fare RAID 1.
bo, mi sembra tanto inutile il discorso, mi viene il dubbio che ancora non ho capito cosa intendesse lo spettatore con quella domanda al relatore. O forse non aveva le idee chiare nemmeno lui ;-)
per copia a caldo (su sistemi windows) si intende la copia dei dati anche durante transazioni sw (ad esempio se usi lotus domino non puoi fare il backup dei file se prima non interrompi il servizio).
il discorso è che non ho un RAID hardware su cui salvare il mio sistema, inoltre voglio poter accedere all’eventuale macchina virtuale anche se il sistema HOST schiatta.
E questo lo faccio salvando il secondo HD virtuale dentro una directory remota (e NON sulla stessa macchina). E facendo ripartire il servizio vmware da un’altra macchina se quello originale muore.
cioè PC1 ha 1 macchina virtuale A con i dischi HD1 e HD2 in mirror sw.
il disco HD2 è nell’immagine vmdx presente su PC2.
Se muore PC1 posso far ripartire la macchina virtuale A da PC2 in quanto ha il disco di mirror ed il file di configurazione.
più chiaro?
In questa soluzione vedo due grandi difficoltà (la seconda è da approfondire):
1) RAID software su ambienti virtuali
2) RAID software su ambienti virtuali e su macchine distinte
1) In un ambiente virtuale si paga tantissimo (anche il 500%) per il context switch (UNIX) e una
gestione RAID a livello software credo diventi molto onerosa dal punto di vista computazionale.
2) Non conosco come funzioni esattamente il mirroring di un disco, ma immagino che le funzioni
di sincronizzazione dei dati siano in qualche modo anche funzione del tempo.
Il fatto che in un ambiente virtuale anche il tempo trascorso è virtuale (la sincronizzazione
con il hwclock non avviene ad ogni time slice) mi lascia pensare che possano verificarsi
facilmente delle inconsistenze o degli overload di sincronizzazione, ma ammetto che bisognerebbe approfondire meglio la questione.
J
Adesso ho capito cosa intendi. Grazie della pazienza :-D .
Però come soluzione mi sa veramente di troppo poco affidabile e efficente, mettere il file su un filesystem di rete mi lascia un po’ perplesso, comunque se fai qualche prova facci sapere che ne viene fuori.
A naso, ma solo a naso, mi sembra improponibile in produzione. Già il RAID1 software è la madre della lentezza, figurati virtualizzato e con una delle unità residente su hardware remoto, via ethernet.
Spero di sbagliarmi, comunque.
ho fatto un paio di test banali (spostamento file, esecuzione programmi di produttività personale, creazione iso e masterizzazione) con schede eth Gigabit su switch Gigabit ed alla fine a parte durante la fase di scrittura massiccia, soprattutto nello spostamento ISO da 600Mb, (dove avevo un rallentamento del 20-25% rispetto alla mancanza di raid) non si sentiva un granchè il problema di lentezza (ricordo che in lettura il RAID 1 è il più veloce).
Ovviamente dovrei testare in produzione con servizi come SQL Server o simili, ma dubito che ne avrò il tempo in questo periodo…
In sostanza direi che per una macchina virtuale dove le scritture sono limitate e si alloca molta ram, per evitare scomodi swap della memoria su filesystem, potrebbe *quasi* andare bene come soluzione.
Accortezze nella configurazione che ho seguito:
macchina host (fedora 7)
– scheda eth Gb
– 2 Gb di ram
– 2 hd raid 0 hw
– mount di una directory remota su server 2003 con raid 5 e scheda eth Gigabit
macchina virtuale (win xp pro)
– 3 hd virtuali (1 con lo swap di sistema e la directory di trash sulla macchina host, e gli altri 2 in raid)
– 1 disco su fedora (primario)
– 1 disco su win2k3
– 1Gb di ram shared con la macchina host