Perché le persone non usano semplicemente rsync per eseguire il backup degli ospiti di vmware?


12

Se sto eseguendo un moderno sistema vmware ESXi, posso inserire un file binario rsync e rsync collegato staticamente a qualsiasi destinazione su SSH.

Sto cercando di capire perché la maggior parte (tutti?) Del backup degli ospiti di vmware non viene eseguita in questo modo.

Se la VM è in esecuzione, è possibile semplicemente utilizzare 'vim-cmd vmsvc / snapshot.create' per creare un'istantanea e quindi sincronizzare nuovamente l'istantanea sull'host remoto. (c'è anche un'opzione per "sospendere" l'istantanea)

OPPURE, se si desidera un backup più affidabile, è possibile arrestare la VM e rsync con garbo sui file vmdk.

Quindi ... sembra che io sia un semplice script di shell lontano da tutti i backup che avrei mai voluto fare, semplicemente e facilmente, usando semplicemente il vecchio rsync.

Cosa mi sto perdendo qui?


1
Perché se un singolo file cambia nella VM dovrai fare il backup dell'intero vmdk?
falso

No, rsync aggiornerà un singolo file in modo efficiente con solo le modifiche dall'ultimo trasferimento. Certamente le operazioni della VM potrebbero produrre MOLTE più modifiche di quanto ti aspetti, ma non ti farà rinviare l'intero vmdk ...
user227963

A parte il fatto che non dovresti usare la shell esxi per qualcosa di diverso dalla manutenzione, il sistema operativo esxi non è fatto per funzionare in quel modo e non saresti supportato, penso che tu stia fraintendendo il concetto di un'istantanea. L'istantanea in questo caso è un delta. Quindi, se fai uno scatto e lo copi subito, sarebbe minuscolo e non contiene quasi informazioni. Stai pensando a un'istantanea dell'archiviazione back-end e sì, le persone
eseguono il

1
@Rqomey: esistono diversi tipi di "istantanee" in ESXi. Stai parlando del tipo visibile tramite il client vSphere, ma utilizzando l'API hai altre opzioni, ad esempio clone completo.
masi,

@MASI Intendi un clone invece di un'istantanea? ;)
Rqomey,

Risposte:


32
  • Perché le velocità di trasferimento dalla console ESXi sono espressamente limitate.
  • Perché questo non è scalabile in alcun modo.
  • Perché dovresti rilasciare un binario rsync compilato staticamente sull'host ESXi.
  • Perché le VM, i VMDK, i loro file ramdisk e altri componenti possono cambiare abbastanza da rendere rsync una proposta perdente ... vuoi davvero risincronizzare una VM da 200 GB che è stata riavviata e che ha cambiato un piccolo numero di file?
  • A causa dei requisiti delle risorse CPU / memoria sull'origine o sulla destinazione. Rsync non è gratuito.
  • Perché ci sono altri prodotti sul mercato, sia di terze parti che forniti da VMware. Cerca Tracking blocchi modificato .
  • Perché ESXi NON è un sistema operativo generico.

Vedi anche: Installa rsync sul server VMware ESX 4.1


1
Risposta eccezionale.
SEE

3
Non sono ... Voglio dire, è nel nome: ghettoVCB . Ci sono soluzioni migliori là fuori. Veeam, vSphere Data Protection, ecc.
ewwhite,

2
Potresti certamente usare il metodo rsync se passi a xen / kvm.
Zoredache,

9
@ user227963 Rsync è anche piuttosto inefficiente su entrambi: un gran numero di file e file di grandi dimensioni. E anche se potrebbe non dover inviare nuovamente l'intero file tramite il filo, dovrà rileggerlo allo stesso modo su sorgente e destinazione. La CBT ti aiuterà qui, ma rsync non sa nulla della CBT.
the-wabbit il

2
@ user227963 la copia dei file è semplice. Ora rendilo veloce e non un porco di risorse su file di grandi dimensioni con piccole modifiche costanti. rsync è decente ma in nessun luogo vicino alle prestazioni di qualsiasi cosa con informazioni privilegiate su quali blocchi sono cambiati.
JamesRyan,

4

Lo facevo solo qualche anno fa. (modifica: con VMWare in esecuzione su host CentOS, non ESXi, per ammissione)

Ogni notte avevo uno script che sospendeva una VM, risincronizzava i file dal disco al server di backup e quindi riavviava le VM. Ha funzionato abbastanza bene tranne ...

Rsync non funziona molto bene con un file da 2 GB.

Non è perché rsync non è brillante, ma più che ogni file vmdk da 2 GB cambia in modi molto opachi per rsync, anche piccole modifiche al filesystem incluso producono cambiamenti nel vmdk (o in tutti i vmdks per qualche motivo) di cui ho incolpato Windows, deframmentando automaticamente o comunque facendo tutte le altre cose che fanno, non importa se stai eseguendo un sistema reale, ma mostrati quando stai provando a risincronizzare una VM!

Penso che il meccanismo rsync per rilevare le modifiche non funzioni molto bene su un file da 2 GB, mentre abbastanza spesso ha saltato blocchi di avvio di vmdk, una volta che ha iniziato a trovare una differenza avrebbe semplicemente copiato il resto del file. Non so se questo è un problema con rsync che non è in grado di rilevare una porzione spostata di dati binari, o con una mancanza di memoria nel box sorgente, o se il vmdk è appena stato aggiornato. Non importa perché il risultato è stato lo stesso: la maggior parte dei vmdk è stata copiata.

Alla fine ho semplicemente copiato tutti i file modificati e li ho sovrascritti, usando ancora rsync. Ho anche avuto prestazioni migliori semplicemente sovrascrivendo il file di backup invece di consentire a rsync di copiare e sostituire ciò che era lì.

Neanche il nostro server di backup è stato il più veloce ed è arrivato al punto in cui durante la notte non è stato abbastanza lungo per eseguire il backup di tutte le VM in esecuzione.

Tuttavia, quando è stato necessario ripristinare una macchina virtuale, è stato davvero facile e ha funzionato magnificamente.


Ok, è molto utile. So un po 'su come funziona rsync e posso dirti che non ha nulla a che fare con la dimensione del file - ma quello che stai descrivendo è che molto più del file cambia di quanto ti aspetti che ... ad esempio, esegui la VM per un giorno e fai solo alcune piccole cose con essa, quindi la interrompi ... ma il file vmdk è cambiato del 30-40% (anche se hai fatto molto poco). Quindi rsync farebbe bene, ha solo molto lavoro da fare ... più di quanto ti aspettassi. Grazie!
user227963,

1
Ma poi ... la domanda che solleva ... come lo fanno gli strumenti "professionali"? Che tipo di magia stanno facendo che è in qualche modo più ottimale di ciò che farebbe rsync (o scp o persino cp)? Alla fine, hai un ambiente unix (la console ESXi) e vuoi spostare un file dentro o fuori da esso ... quali segreti potrebbero esserci?
user227963,

@ user227963 Gli strumenti professionali sfruttano funzionalità come il rilevamento dei blocchi modificati o hanno accesso ad altre API vSphere o ESXi.
ewwhite,

2

La risincronizzazione di un singolo file non è una soluzione di backup,

cosa fai quando è successo qualcosa alla VM e i file sono stati cancellati, ma hai notato questo solo dopo che il tuo rsync è stato eseguito di nuovo? Ora avrai sovrascritto il buon 'backup' dei tuoi file con l'immagine cattiva.

Se si desidera eseguire il backup, è necessario conservare le versioni precedenti da qualche parte o le differenze. Rsync copierà solo le differenze per te, ma non memorizzerà solo le differenze, ma sovrascriverà il file precedente.

Potrebbero esserci opzioni per te qui, con rsync e un filesystem copy-on-write con informazioni sulla versione, che in effetti memorizzerà le differenze ogni volta che lo script rsync viene eseguito. Questa soluzione inizia a diventare un po 'più complicata, quindi è per questo che le persone ricorrono a soluzioni di lavoro conosciute imho.


C'è sicuramente molta più complessità qui coinvolta di quanto pensassi inizialmente, ma quello che stai citando non è un problema. Sicuramente se avessi eseguito rsync alla cieca più e più volte potresti avere problemi, come suggerisci, ma ci sono molti modi semplici per clonare / ruotare i backup creati da rsync (anche quelli a file singolo) ... quel problema è stato risolto a lungo tempo fa, per fortuna.
user227963

0

Non c'è alcun motivo per cui non è possibile utilizzare Rsync in un server ESXi. Offriamo una versione compilata staticamente qui https://33hops.com/rsync-for-vmware-vsphere-esxi.html che funziona molto bene. Ci sono informazioni su come compilare anche il tuo.

Tuttavia, chiunque sia disposto a utilizzarlo deve tenere conto del fatto che Rsync e il suo algoritmo Delta non sono stati pensati per eseguire il backup di file sparsi di lunghezza fissa fissa, come i dischi rigidi della VM, ma per sincronizzare file di dimensioni variabili di dimensioni inferiori. Quindi funziona, ma ci vuole molto tempo e CPU per calcolare i dati diff. In effetti è solo un modo per scambiare larghezza di banda con la CPU. In ogni caso, è ancora abbastanza praticabile, specialmente se i tuoi dischi virtuali sono nell'ordine di alcune decine di gigabyte.

Ho pubblicato un post completo sull'argomento qui, descrivendo in dettaglio tutti i pro e i contro https://33hops.com/blog_xsibackup-rsync-considerations.html

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.