Per i fortunati possessori di un cluster VMware basato su Virtual Infrastrucure 3 è possibile che non sia un problema dotarsi del necessario per effettuare i backup attraverso VCB e una macchina windows. C'è chi, come me, preferisce però affidarsi al software di backup già in uso (Bacula), non acquistare una nuova licenza Windows e impazzire dietro allo strano modo con cui VCB pensa di fare i backup.
Per questo motivo ho affrontato un problema abbastanza complesso: come fare i backup attraverso Bacula di un sistema basato su VI3, avendo in mano qualcosa di consistente su cui fare affidamento.
Da qui sono nati questi tre script:
Gli approcci possibili al problema sono due, io ho ovviamente testato
il primo per poi approdare al secondo. Concettualmente fare il backup
di una macchina VMware accesa è abbastanza semplice, perché lo stesso
VCB non fa niente di diverso da questo: effettua uno snapshot
consistente (quindi chiedendo alla VM di effettuare il quiescent dei
dati su disco), eventualmente converte il disco per essere esportato su
una macchina VMFS e lo trasferisce sul media di backup. VCB ha il
vantaggio di poter fare questa operazione senza passare dalla rete
degli ESX ma attingendo ai dati direttamente sulla SAN FC (e penso
anche iSCSI). Noi no, possiamo solo passare dalla rete e utilizzando
come "ponte" una macchina ESX a scelta, magari solitamente più scarica
delle altre.
Lo script vm-bacula quindi pretende che sul nodo director siano
installare le VMware API per poter interagire con il virtualcenter,
effettua lo snapshot della VM e poi, in un primo approccio, contatta il
nodo che sta facendo girare la VM e ne preleva i dati attraverso il
file daemon residente. Tutto questo funziona molto bene, ma quando ci
si trova a fare il restore di una VM bisogna ricordarsi qual'è il
server da cui è stato effettuato il restore più recente, una pazzia.
Meglio allora scegliere un nodo, decidere che i backup si fanno tramite
esso, definirlo come "vmware-fd" in bacula ed installare gli script di
cui sopra e il file daemon di bacula (versione 2.2 per RHEL3,
disponibile tranquillamente tra gli rpm ufficiali). La differenza
rispetto all'approccio del "mi connetto al server che sta facendo
girare questa VM" è che le altre macchine ESX non hanno il permesso di
leggere il file VMDK che a noi serve, anche se si tratta di un file
congelato (la VM sta scrivendo sullo snapshot) e siamo in un filesystem
clustered.
Per questo motivo gli script vm-bacula-before (che lo crea) e
vm-bacula-after (che lo distrugge) vengono fatti girare sul server ESX
per creare una copia del disco virtuale con i vmkfstools in una
subdirectory backup della VM; questo significa che sullo storage sarà
sempre necessario avere spazio disco per poter effettuare la
'clonazione' di una macchina.
Lato director è necessario far girare periodicamente lo script di
generazione della configurazione di bacula, che comprenderà Jobs e
Fileset di tutte le VM esistenti (nella prima versione non è possibile
generare job differenziati per fare il backup solo di alcune VM); i
jobs faranno riferimento ad un oggetto Client che andrà configurato
manualmente e sarà uguale per tutti i backup (ad esempio "vmware-fd").
Lo script vm-bacula si usa come segue:
perl /opt/bacula/vm-bacula --server MyVIServer --username bacula
--password passworddifficile --pool VMware --storage FileStorage
--schedule OnlySunday --action filesets --client vmware-fd
>/etc/bacula/vmware-files.conf
perl /opt/bacula/vm-bacula --server MyVIServer --username bacula
--password passworddifficile --pool VMware --storage FileStorage
--schedule OnlySunday --action jobs --client vmware-fd
>/etc/bacula/vmware-jobs.conf
echo reload | /usr/bin/bconsole
Come si può vedere è utile creare un utente di VirtualCenter dedicato a
Bacula e che abbia i diritti di Creazione e Cancellazione degli
snapshot. Questo tipo di ruolo non è presente ma è facile crearlo ed
assegnarlo all'intero datacenter.