Nei sistemi VMware oramai si sono affermati i backup di tipo image-based, ovvero quelli che prevedono il salvataggio dei blocchi dei file disco VMDK della virtual machine, piuttosto che salvare i files contenuti nel Guest OS attraverso agenti. Attraverso l’uso di CBT, dalla versione 4.0 in avanti è possibile identificare i blocchi modificati rispetto alla precedente esecuzione del backup, ed estrarre unicamente questi. Questo permette l’esecuzione di backup incrementali che occupano pochissimo spazio e riducono i tempi di esecuzione.
Il funzionamento di CBT e la sua interazione col file system del Guest OS pone tuttavia qualche problema nell’ottimizzazione di questi incrementali.
Vediamolo con un esempio: ipotizziamo una Virtual Machine Windows 2008 R2 che agisce come file server. Il disco VMDK è stato formattato in NTFS con un block size di default di 4KB, e contiene migliaia di file. Un utente modifica un file da 12 kb e le modifiche vengono salvate sul disco. Questo file è quindi composto da 3 clusters NTFS, ma a causa della frammentazione del file system, questi tre blocchi potrebbero essere salvati su tre blocchi VMFS differenti:
In questo caso quindi una semplice modifica di 12 KB a un file si traduce in una modifica di 3 MB sui blocchi VMFS del virtual disk. In questi casi, un software di backup classico con un agent a bordo rileverebbe la modifica del singolo file, mentre un backup image-based salverà tutti i 3 MB modificati.
Se da un lato queste problematiche sono insite nel funzionamento di CBT (che per contro offre una miriade di vantaggi…), è possibile ottimizzare questa situazione per limitare il numero di CBT modificati.
Le due attività che potete effettuare sono:
– defrag dei dischi dal sistema operativo guest. Questa operazione riorganizza tutti i clusters all’interno del disco e ottimizza quindi il riempimento dei blocchi CBT, andando ad utilizzarne il numero minimo possibile. Dato che moltissimi blocchi CBT verrebbero interessati da questa attività e marcati come modificati, è bene farlo unicamente prima di un full backup; prima di un incrementale vorrebbe dire avere un backup grande quasi quanto il full.
– sdelete: questo tool cancella i clusters non più utilizzati e li riempie di 0. Oltre ad essere un ottimo strumento per la cancellazione sicura dei files, è ottimo anche per svuotare i blocchi non contenenti più dati e ottimizzare lo spazio disco. E’ assolutamente da NON fare su dischi in Thin Provisioning, dove sdelete finirebbe per riempire tutto lo spazio inizialmente assegnato rendendo il disco thick e facendo quindi perdere i vantaggi del thin.
Schedulare uno script che effettui queste due operazioni prima di un full backup può portare a notevoli miglioramenti in termini di spazio disco occupato e velocità di realizzazione del backup stesso.
Domanda fatta per curiosita’.
Se io abilito il TRIM per le SSD posso migliorare le performance del backup via CBT? Teoricamente (ma qui mi fermo per ignoranza in materia) se il sistema operativo dice che un’area non e’ piu’ utilizzata, questa non dovrebbe piu’ essere considerata. Certamente il TRIM non risolve il problema dei file piccoli, ma oramai di file di 12k non ce ne sono quasi piu’ nella userland
Giusto per riferimento e per chiarire di cosa sto parlando, sotto Windows si usa il comando “fsutil behavior query disabledeletenotify” per vedere se e’ abilitato il TRIM e sotto Linux si mette l’opzione “discard” in fstab
Ciao Luigi,
per quello che so e che ho letto in giro, TRIM è un comando SATA mentre ESXi utilizza sempre comandi SCSI per comunicare col sottosistema dischi; di fatto TRIM non è disponibile per ESXi.
Inoltre CBT è pensato proprio per evitare di dover usare soluzioni simili: avendo un metabase (il file .ctk) dove segno dei codici progressivi dei vari blocchi, qualunque software compatibile chiede via API al server ESXi quali blocchi sono stati modificati rispetto al timestamp X, un pò come fa Active Directory con gli USN in fase di replica.
Ciao.
Ciao,
potrebbe andare bene lo script di questo sito??
http://www.yellow-bricks.com/2008/01/04/vmware-consolidated-backup-and-deleted-files/
Ciao,
lo script che indichi usa sdelete, che appunto indico anche io nell’articolo. Per il resto si riferisce a VCB in un periodo oltretutto in cui non c’era vSphere 4, e quindi il CBT.
Ciao,
Luca.