VMware vSphere Hypervisor (ESXi 5) con ghettoVCB via nfs

[Andrea Breda]

Ciao a tutti,

ho da poco attivato due server ESXi 5 free nel quale gireranno alcune virtual machine. Come soluzione per i backup ho scelto ghettoVCB con un mount non persistente di una risorsa nfs che arriva da un server AIX.

Il problema che è sorto sono i tempi di backup. In prima battuta volevo eseguire il salvataggio in modalità offline (poweroff prima della clonazione) ma purtroppo non ho così tanto tempo disponibile per lasciare le vm spente. Ho quindi deciso di passare alla modalità snapshot anche se questo mi obbliga ad usare la script ghettoVCB-restore.sh per ricreare il disco (corretto vero???).

I tempi che ottengo sono i seguenti:

2012-03-06 08:14:37 -- info: CONFIG - VERSION = 2011_11_19_1

2012-03-06 08:14:37 -- info: CONFIG - GHETTOVCB_PID = 370838

2012-03-06 08:14:37 -- info: CONFIG - VM_BACKUP_VOLUME = /vmfs/volumes/backup/ESX01

2012-03-06 08:14:37 -- info: CONFIG - ENABLE_NON_PERSISTENT_NFS = 1

2012-03-06 08:14:37 -- info: CONFIG - UNMOUNT_NFS = 1

2012-03-06 08:14:37 -- info: CONFIG - NFS_SERVER = 10.10.10.10

2012-03-06 08:14:37 -- info: CONFIG - NFS_MOUNT = /img_vmware

2012-03-06 08:14:37 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 1

2012-03-06 08:14:37 -- info: CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2012-03-06_08-14-36

2012-03-06 08:14:37 -- info: CONFIG - DISK_BACKUP_FORMAT = thin

2012-03-06 08:14:37 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 0

2012-03-06 08:14:37 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0

2012-03-06 08:14:37 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 3

2012-03-06 08:14:37 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5

2012-03-06 08:14:37 -- info: CONFIG - SNAPSHOT_TIMEOUT = 15

2012-03-06 08:14:37 -- info: CONFIG - LOG_LEVEL = info

2012-03-06 08:14:37 -- info: CONFIG - BACKUP_LOG_OUTPUT = /opt/ghettoVCB/esx01bk.log

2012-03-06 08:14:37 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 0

2012-03-06 08:14:37 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0

2012-03-06 08:14:37 -- info: CONFIG - VMDK_FILES_TO_BACKUP = all

2012-03-06 08:14:37 -- info: CONFIG - EMAIL_LOG = 0

2012-03-06 08:14:37 -- info:

2012-03-06 08:14:40 -- info: Initiate backup for SRVPROVA

2012-03-06 08:14:40 -- info: Creating Snapshot "ghettoVCB-snapshot-2012-03-06" for SRVPROVA

Destination disk format: VMFS thin-provisioned

Cloning disk '/vmfs/volumes/datastore1/ SRVPROVA / SRVPROVA .vmdk'...

Clone: 96% done.

2012-03-06 09:39:41 -- info: Removing snapshot from  SRVPROVA ...

2012-03-06 09:39:41 -- info: Backup Duration: 85.02 Minutes

2012-03-06 09:39:41 -- info: Successfully completed backup for SRVPROVA !

Ho anche provato a clonare su una cartella locale del datastore ma alla fine, tra clonazione e trasferimento via sftp non è che miglioro di tanto.

Come da log sia il vmdk della virtual machine che quello di destinazione (clonazione o snapshot) sono in formato thin-provision! Potrebbe essere anche questo un problema?

Avete qualche dritta da darmi?

Grazie 1000

[ldelloca]

Ciao,

di per sè il tempo speso non è impossibile, bisognerebbe sapere effettivamente quanto è grande questo disco thin.

Fosse stato ESXi 4.x il problema sarebbe quasi sicuramente stato ESXi stesso, nella 4.x la velocità di connessione della console da cui estrarre il backup, ma con la 5.0 effettivamente questa cosa in parte è stata risolta.

Conta però che usi comunque un backup via service console, che non è il massimo della velocità.

Servirebbero altre info: storage locale e remoto, tipo di controller, rete, dimensione del thin disk...

Ciao,

Luca.

[Andrea Breda]

Ciao Luca,

ti ringrazio per la risposta. Provo a ricapitolarti un pò le caratteristiche:

- Il datastore locale è composto da un raid 5 con quattro dischi SAS a 10K da 146GB.

- Il server ESXi è montato su un HP Proliant DL380G5 con schede ethernet Broadcom NetXtreme II BCM5708 1000Base-T

- Il datastore remoto di backup è composto da dischi Ultra320 SCSI da 73.4GB (un volume group fatto su AIX ed esportato via nfs)

- La scheda di rete del server nfs è sempre una 1000 ethenet

- Lo switch di rete è un blade (rimarchiato ibm) da 10 gigabit

- Per il mount nfs ho creato un nuovo virtual switch collegato alla rete di backend e quindi non usato dalle virtual machine o dalla management console

- La dimensione del thin disk è di 25GB.

:smileywink: lo seguo già da un pò il tuo blog!

Andrea

[ldelloca]

:smileyhappy:

Ho fatto due conti, stiamo parlando fondamentalmente di 5 mbit/s. Questi sono i valori che di solito si avevano sulla management console di ESXi free 4.

Non mi è chiaro però come è montato l'NFS, e da chi. GhettoVCB dove viene eseguito?

Luca.

[Andrea Breda]

Allora! ghettoVCB.sh viene lanciato via ssh dall'nfs server che come ti dicevo monta AIX. Quindi alla fine gira in locale sulla shell di ESXi.

Idem per quanto riguarda il mount dell'nfs che viene montato dall script con il comando "/bin/vim-cmd hostsvc/datastore/nas_create". Quindi, anche in questo caso, da esx.

Ho comunque fatto una prova eseguendo slo snapshot in locale invece del datastore nfs.

In questo caso la macchina ha un disco thin con l'effettiva occupazione di 5Gb e come vedi comunque ci impiega molto tempo.

A questo punto mi viene da pensare che il collo di bottiglia siano proprio i dischi interni del server HP.

Potrebbe essere secondo te un problema del server? Intendo firmware del controller, bios macchina ecc...

Io ho installato l'esxi 5 free scaricato da vmware e non quello di HP (come da tuo consiglio sul blog). Non ho però installato i bundle hp "hp-esxi5.0uX-bundle-1.1-37" e "hp-nmi-esxi5.0-bundle-2.0-11" ma da come ho capito non dovrebbero incidere sulle performance. Sbaglio?

Grazie ancora

2012-03-06 10:36:14 -- info: ============================== ESX02 LOG START ==============================

2012-03-06 10:36:14 -- info: CONFIG - VERSION = 2011_11_19_1

2012-03-06 10:36:14 -- info: CONFIG - GHETTOVCB_PID = 382152

2012-03-06 10:36:14 -- info: CONFIG - VM_BACKUP_VOLUME = /vmfs/volumes/datastore1/backup

2012-03-06 10:36:14 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 1

2012-03-06 10:36:14 -- info: CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2012-03-06_10-36-14

2012-03-06 10:36:14 -- info: CONFIG - DISK_BACKUP_FORMAT = thin

2012-03-06 10:36:14 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 0

2012-03-06 10:36:14 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0

2012-03-06 10:36:14 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 3

2012-03-06 10:36:14 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5

2012-03-06 10:36:14 -- info: CONFIG - SNAPSHOT_TIMEOUT = 15

2012-03-06 10:36:14 -- info: CONFIG - LOG_LEVEL = info

2012-03-06 10:36:14 -- info: CONFIG - BACKUP_LOG_OUTPUT = /opt/ghettoVCB/esx02bk.log

2012-03-06 10:36:14 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 0

2012-03-06 10:36:14 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0

2012-03-06 10:36:14 -- info: CONFIG - VMDK_FILES_TO_BACKUP = all

2012-03-06 10:36:14 -- info: CONFIG - EMAIL_LOG = 0

2012-03-06 10:36:14 -- info:

2012-03-06 10:36:18 -- info: Initiate backup for SRVPROVA

2012-03-06 10:36:18 -- info: Creating Snapshot "ghettoVCB-snapshot-2012-03-06" for SRVPROVA

Destination disk format: VMFS thin-provisioned

Cloning disk '/vmfs/volumes/datastore1/SRVPROVA/SRVPROVA.vmdk'...

2012-03-06 10:51:02 -- info: Removing snapshot from SAPCONSOLEX ...

2012-03-06 10:51:02 -- info: Backup Duration: 14.73 Minutes

2012-03-06 10:51:02 -- info: Successfully completed backup for  SRVPROVA!

[ldelloca]

A rivedere la lista dell'hardware il collo di bottiglia potrebbe essere lo store della macchina AIX, i dischi Ultra320 non sono nuovissimi immagino.

Riguardo i moduli aggiuntivi per HP, no servono solo per fare monitoraggio e gestione dei server.

Luca.

[Andrea Breda]

Ok, questi posso anche cambiarli andando su una SAN.

Mi sembra comunque strano che lo snapshot sul datastore locale ci metti così tanto!

[ldelloca]

Frena, gli 85 minuti sono il tempo in cui Ghetto fa tutto il backup, non la sola snapshot.

Vedi la snapshot nell'activity di vCenter o dell'ESXi, e dura qualche secondo.

Luca.

[Andrea Breda]

Si, scusa. Intendevo per fare l'intera clonazione del disco.

Nell'ultima prova con 5GB di disco ci ha impiegato 14 minuti per la clonazione.

A questo punto secondo te non mi conviene stopppare le virtual machine ed eseguire un semplice sftp per poi salvarla su nastro?

Inoltre, se posso... non mi è chiaro perchè, eseguendo il backup di tipo snapshot sono costretto ad utilizzare il ghettoVCB-restore.sh per poter ripristinare la virtual machine :smileyconfused:

[Andrea Breda]

Luca, avanzi una birra! Ho provato a fare il backup su datastore nfs utilizzando dischi di uno storage su SAN!

Il tempo per la clonazione della virtual machine da 5GB è stato di 3 minuti.

Questa notte provo a far girare un backup completo offline e ti faccio sapere il risultato.

[ldelloca]

Mi fa piacere. :smileyhappy:

Per la birra, la sera prima del prossimo VMUG del 5 Aprile organizzeremo una vBeer nei dintorni di Sirmione, presentati con 10 euro :smileywink:

Ciao,

Luca.

[Andrea Breda]

:smileylaugh: mi piacerebbe tanto esserci!

[Andrea Breda]

Dopo una settimana posso dire che Luca aveva ragione ed il problema era solo da imputare ai dischi dell'NFS Server.

Colgo però l'occasione per fare un'altra domanda in merito al backup.

Considerando che tutte le mie macchine virtuali hanno il vmdk di tipo thin e che lo spazio che mi occorre sull'nfs server deve essere pari al totale di tutti i miei vmdk (per l'estensione massima assegnata), ho qualche possibilità di ridurre l'estensione massima per limitare lo spazio occupato sul datastore di backup?

Ad esempio ho alcune vm a cui è assegnato un disco da 40GB ma che in realtà occupa solo 8/9GB. Vorrei quindi ridurre l'estensione massima a 20GB per avere un file più piccolo sul datastore nfs di backup. Purtroppo il Converter è lentissimo per tale operazione! Ho qualche altra opzione?

[ldelloca]

Lo shrink dei vmdk da vSphere non è possibile, temo che il converter sia la tua unica soluzione se devi effettuare questa modifica.

Luca.