Da quando Microsoft ha introdotto le funzioni VSS, è diventata buona norma utilizzare queste librerie per garantire un backup consistente degli applicativi che le supportano.
Veeam effettua i backup senza l’uso di agent permanenti nelle virtual machine, tuttavia in caso si voglia realizzare un backup tramite VSS, Veeam provvede a installare (e poi rimuovere a backup ultimato) un piccolo agent sulla VM Windows al fine di coordinare le operazioni VSS stesse. Solitamente, questa attività viene effettuata collegandosi attraverso la rete alla virtual machine oggetto del backup.
Ma cosa succede se per qualsiasi motivo il server Veeam e la virtual machine risiedono su due reti differenti, o non hanno possibilità di comunicare tra loro? Ad esempio un webserver IIS posizionato in una rete DMZ che non può essere raggiunta proveniendo dalla rete in cui si trova il Veeam server?
E’ in queste occasioni che è possibile apprezzare le librerie VIX di VMware, e l’uso che Veeam ne ha fatto. Ho trovato questo articolo piuttosto datato, del 2008, che spiega tuttavia in modo splendido cosa permettono di fare queste librerie. Fondamentalmente, di interagire con il sistema operativo guest di un virtual machine passando dall’hypervisor che la ospita, senza necessità di alcuna connettività di rete. Tra le operazioni che è possibile effettuare, abbiamo la copia di files, l’avvio e arresto di servizi, e l’esecuzione di programmi nella guest VM.
Veeam ha usufruito di queste librerie per permettere la realizzazione di backup VSS, anche quando la VM non è raggiungibile via rete. Per mostrarvi il funzionamento, ho realizzato un piccolo test nel mio lab, consistente in una VM Windows 2008 R2 che non possiede nessuna scheda di rete:
Ho quindi configurato un rapido job di backup con Veeam, senza impostare nessun parametro particolare se non l’uso delle librerie VSS, per vedere cosa accadeva:
Il backup è “seplicemente” andato a buon fine. In realtà, Veeam prova in prima istanza a collegarsi come sempre via RPC, ma siccome la VM non possiede nessun indirizzo IP, il tentativo fallisce, e passa automaticamente alla modalità VIX. Possiamo apprezzare questo funzionameno visualizzando il log (ho copiato unicamente i passaggi rilevanti):
[24.06.2013 14:00:20] <01> Info [VssGAConn('vix-test')] Initializing VSS guest agent connection.
[24.06.2013 14:00:20] <01> Error Failed to connect to guest agent: unable to obtain guest IP address. at Veeam.Backup.VssProvider.CVssGAConnection.ConnectViaRpc
[24.06.2013 14:00:20] <01> Error at Veeam.Backup.VssProvider.CVssGAConnection.CreateEx
[24.06.2013 14:00:20] <01> Info [VssGAConn] Connecting to guest via vix, hostIp '10.2.50.111', postPort '443', hostUser 'SKUNKWORKS\administrator', vmVmx '[qnap259] vix-test/vix-test.vmx', vmUser 'vix-test\administrator'
[24.06.2013 14:00:20] Info Connecting to host [10.2.50.111] over VIX library. Login: [SKUNKWORKS\administrator].
[24.06.2013 14:00:26] Info Temporary file [C:\Users\ADMINI~1\AppData\Local\Temp\vmware161] created.
[24.06.2013 14:00:26] Info Copying files form host [C:\Program Files\Veeam\Backup and Replication\VSS\VeeamGuestAgents\VeeamVixProxy.exe] to guest [C:\Users\ADMINI~1\AppData\Local\Temp\vmware161].
[24.06.2013 14:00:27] Info Connecting to host [10.2.50.111] over VIX library. Login: [SKUNKWORKS\administrator].. Ok.
[24.06.2013 14:00:27] Info Enter CVeeamVssGAInstaller::GetGateState
[24.06.2013 14:00:28] Info Temporary file [C:\Users\ADMINI~1\AppData\Local\Temp\vmware185] created.
[24.06.2013 14:00:28] Info Running program [C:\Users\ADMINI~1\AppData\Local\Temp\vmware161 -func GetServiceState -out "C:\Users\ADMINI~1\AppData\Local\Temp\vmware185" -svcname "VeeamVssSupport"].
[24.06.2013 14:00:30] Info Copying files form guest [C:\Users\ADMINI~1\AppData\Local\Temp\vmware185] to host [C:\Windows\TEMP\ifd4720.tmp].
[24.06.2013 14:00:31] Info Deleting file [C:\Users\ADMINI~1\AppData\Local\Temp\vmware185] in guest.
[24.06.2013 14:00:32] Info Leave CVeeamVssGAInstaller::GetGateState
[24.06.2013 14:00:32] <01> Info VssGAConn('vix-test')] Agent state: 'EVeeamVssNotInstalled'.
[24.06.2013 14:00:32] <01> Info [VssGAConn('vix-test')] Installing agent.
[24.06.2013 14:00:32] Info Enter CVeeamVssGAInstaller::Install
[24.06.2013 14:00:32] Info Installing agent.
Come possiamo vedere, in seguito all’impossibilità di collegarsi via RPC, Veeam si collega a vCenter (10.2.50.111) e da qui accede alla VM via VIX, sfruttando le stesse credenziali specificate nel job “vix-test\administrator”, essendo la VM non unita al dominio “SKUNKWORKS”. La connessione VIX va a buon fine, e da qui Veeam è in grado di installare il suo agent temporaneo sulla VM.
Affascinante vero?
Se volete rimuovere anche l’errore iniziale, e recuperare alcuni secondi di attività, è possibile a partire da Veeam Backup & Replication v6.1 patch 1 (build 6.1.0.205) invertire l’ordine di connessione VSS, facendo in modo che Veeam tenti per prima la connessione VIX. Come farlo è spiegato nelle release notes della build stessa:
Added new registry value that reverses the sequence of application-aware processing, making jobs try network-less processing mode before network one.
HKEY_LOCAL_MACHINE\SOFTWARE\VeeaM\Veeam Backup and Replication
DWORD: InverseVssProtocolOrder
Value = 1
To disable (default behavior), value is 0 (false)
Dopo aver quindi impostato la chiave di registro come indicato, ho eseguito nuovamente il job di backup:
La prima cosa che possiamo subito notare, è che “Preparing guest for hot backup” dura 15 secondi invece dei precedenti 21, segno che qualcosa è effettivamente cmabiato. Ma, come prima, si può apprezzare la modifica dal log dettagliato:
[24.06.2013 14:39:16] <01> Info [VssGAConn('vix-test')] Initializing VSS guest agent connection.
[24.06.2013 14:39:17] <01> Info [VssGAConn] Connecting to guest via vix, hostIp '10.2.50.111', postPort '443', hostUser 'SKUNKWORKS\administrator', vmVmx '[qnap259] vix-test/vix-test.vmx', vmUser 'vix-test\administrator'
[24.06.2013 14:39:17] Info Connecting to host [10.2.50.111] over VIX library. Login: [SKUNKWORKS\administrator].
[24.06.2013 14:39:24] Info Temporary file [C:\Users\ADMINI~1\AppData\Local\Temp\vmware175] created.
[24.06.2013 14:39:24] Info Copying files form host [C:\Program Files\Veeam\Backup and Replication\VSS\VeeamGuestAgents\VeeamVixProxy.exe] to guest [C:\Users\ADMINI~1\AppData\Local\Temp\vmware175].
[24.06.2013 14:39:25] Info Connecting to host [10.2.50.111] over VIX library. Login: [SKUNKWORKS\administrator].. Ok.
[24.06.2013 14:39:26] Info Temporary file [C:\Users\ADMINI~1\AppData\Local\Temp\vmware215] created.
[24.06.2013 14:39:26] Info Running program [C:\Users\ADMINI~1\AppData\Local\Temp\vmware175 -func GetServiceState -out "C:\Users\ADMINI~1\AppData\Local\Temp\vmware215" -svcname "VeeamVssSupport"].
[24.06.2013 14:39:28] Info Copying files form guest [C:\Users\ADMINI~1\AppData\Local\Temp\vmware215] to host [C:\Windows\TEMP\ifd6AC3.tmp].
[24.06.2013 14:39:29] Info Deleting file [C:\Users\ADMINI~1\AppData\Local\Temp\vmware215] in guest.
[24.06.2013 14:39:30] Info Leave CVeeamVssGAInstaller::GetGateState
[24.06.2013 14:39:30] <01> Info VssGAConn('vix-test')] Agent state: 'EVeeamVssNotInstalled'.
[24.06.2013 14:39:30] <01> Info [VssGAConn('vix-test')] Installing agent.
Vediamo come in questo caso, Veeam effettua subito la connessione sfruttando le librerie VIX, senza prima tentare la connessione via rete.
Se quindi avete numerose virtual machines non raggiungibili via rete, valutate l’opportunità di configurare Veeam per usare le librerie VIX come prima modalità di backup.