Macchine virtuali VMware e perdita di dati

Le virtual machine VMware sono straordinarie, senza alcun dubbio; diffusissime in ambiente aziendale consentono ai sistemisti una gestione degli ambienti operativi semplice e veloce oltre garantire tempi di disaster recovery ridottissimi.

VMware e ESX / GSX server

Le virtual machine basate su VMware trovano il loro scenario operativo ideale nei server dedicati VMware ESX e GSX sistemi operativi proprietari, dove le macchine possono essere create e gestite dall'esterno con i prodotti VMware .

I server VMware utilizzano per la memorizzazione dei file delle proprie virtual machine VMFS, un file system basato su binary tree molto simile a HFS+.

Il file system VMFS, il cui sorgente è privato anche se esistono alcuni porting per sistemi posix è relativamente semplificato e non lascia scampo in caso di perdita di dati.

Una cancellazione di una macchina virtuale commessa per errore o un problema al file system vmfs e siete a piedi.

Come vengono memorizzate le virtual machine nei server VMware

I file .vmdk ( oltre i vmx vmem e gli altri) che contengono i dati della virtual machine vengono ovviamente salvati nel file system vmfs, secondo i criteri di allocazione del file system VMware , che soprattutto nei casi di thin provisioning genera livello di frammentazione elevato.

Se i files .vmdk sono frammentati (e questo accade nella maggior parte dei casi), di fronte a qualsiasi problema sul server o sui dischi che ci auguriamo siano almeno in raid 5 il rischio di perdita di dati è elevatissimo.

E quando si ferma un server VMware si fermano tutte le macchine virtuali in esercizio.

Se il file system vmfs dovesse aver problemi o aver subito un'alterazione, come una cancellazione di una macchina virtuale, o un problema interno, è importante sapere che recuperare i dati potrebbe non essere possibile neanche per il miglior specialista di data recovery.

Un caso di perdita di dati da server esx

Un nostro cliente ha configurato un server esx su un volume fisico da 1TB.

Il sistemista ha creato una macchina virtuale con due hard disk .vmdk, uno da 300 GB e uno da 700 GB in modalità thin provisioning.

Il disco secondario, che era dedicato alla condivisione file degli utenti è cresciuto saturando lo spazio disponibile.

Risultato: Server ESX fermo.

Evitare il thin provisioning SEMPRE

Utilizzare il sistema di thin provisioning in un ambiente di esercizio non ha alcun senso.

Se decidete di assegnare 100 GB ad un disco virtuale utilizzate dischi in modalità tick provisioning e preallocazione.

In tal maniera, non solo eviterete i problemi verificatisi nell'esempio sopra ma in caso di disastro dei sistemi di backup che avrete certamente predisposto, in ultima istanza uno specialista di data recovery potrebbe recuperare i dischi flat come settori contigui sul volume fisico.

Disconnessione logica dei file DELTA

Un problema tipico di VMware, è la perdita di sincronizzazione del file principale del disco virtuale ( flat.vmdk ) con i suoi COWD file o delta file.

Accade spessissimo infatti che improvvisamente la macchina virtuale non contenga più i dati aggiornati ma quelli di molti mesi prima, quelli contenuti nel file flat originale.

Come risincronizzare in file delta con il file flat

Il problema evidenziato si puo' verificare per diversi motivi, uno dei quali una corruzione del file .vmdk del disco virtuale.

Il merging del file delta.vmdk sul flat.vmdk può sembrare un'operazione di routine con le utility integrate nel server ESX ma non è così.

Un metodo efficace per il merging dei file .vmdk è trattare i virtual disks fuori del sistema esx in un ambiente linux dove è possibile utilizzare le utility integrate in qemu per la conversione dei dischi virtuali.

Nota operativa:

Se intendete procedere ad una conversione e un merging dei token .vmdk è importante fare attenzione al file system dove i file .vmdk sono salvati.

Abbiamo notato che dischi virtuali salvati su file system ntfs durante la conversione cross in ambiente Linux con qemu producevano un overhead tale da portare il processore al 100% di impegno rendendo il processo di conversione lentissimo.
Se intendete eseguire tale operazione su sistemi linux vi raccomandiamo il salvataggio dei file .vmdk su file system ext4 o xfs.

VmWare e Knowledge Base

Esistono centinaia di post nella knowledge di VMware, su come affrontare i mille problemi che potrebbero verificarsi, ma in tutti i casi che abbiamo affrontato non abbiamo mai trovato una soluzione che funzionasse di fronte ad un reale problema.

La verità sulle Virtual Machine

Fin quando una virtual machine è in esercizio in un ambiente senza problemi è certamente una soluzione eccellente ai molti problemi di gestione sistemistica degli ambienti operativi.
L'idea in un ambiente small / medium business è semplice:

Acquistare un unico server con raid 5

Creare tante vm per ogni servizio specifico, voip server, exchange server, file server e proxy server.

E Tutti vissero felici e contenti.

E' evidente che questo è un vero e proprio abuso tecnico, in quanto chi dovesse ricorrere a tale tipo di semplificazione per indole semplificherebbe anche le procedure di backup.

Un nas con batch di backup nelle virtual machine=Dati Sicuri.

Lo scenario disegnato potrebbe far sorridere, ma oggi è la scelta più venduta dai consulenti informatici, soluzione semplice, facile gestione, poco spazio occupato, poca energia consumata.

E' certamente la scelta più semplice, ignorando completamente qualsiasi possibilità di perdita di dati, e non considerando che inserire tutto il core business funzionale e operativo di una organizzazione in un'unica posizione, rappresenta un rischio potenziale enorme.

Mentre dovrebbe esistere una utility presente nei server VMware per tale scopo in tutti i test eseguiti per risolvere questo problema, merging vmdk delta file.