Come si sincronizzano file sparsi di grandi dimensioni (immagini del disco VM) tra macchine?

22

Esiste un comando, come rsync, che può sincronizzare file enormi, sparsi, da un server Linux a un altro?

È molto importante che il file di destinazione rimanga scarso. Potrebbe essere più lungo (ma non più grande) dell'unità che lo contiene. Solo i blocchi modificati devono essere inviati attraverso il filo.

Ho provato rsync, ma non ho avuto gioia. https://groups.google.com/forum/#!topic/mailing.unix.rsync/lPOScZgFE9M

Se scrivo un programma per farlo, sto solo reinventando la ruota? http://www.finalcog.com/synchronise-block-devices

Grazie,

Chris.

linux rsync kvm-virtualization

— fadedbee
fonte

rsync è estremamente inefficiente con file di grandi dimensioni. Anche con --inplace leggerà prima l'intero file sull'host di destinazione e POI inizierà a leggere il file sull'host locale e trasferirà le differenze (basta eseguire dstat o simili mentre si esegue rsync e osservare)

— ndemou

21

rsync --ignore-existing --sparse ...

Per creare nuovi file in modalità sparsa

Seguito da

rsync --inplace ...

Per aggiornare tutti i file esistenti (inclusi quelli sparsi precedentemente creati) sul posto.

— Steve P
fonte

3

Inverti per avere rsync --existing --inplacee poi rsync --ignore-existing --sparseper avere uno speedup di sincronizzazione

— Mike

2

Qualcuno può spiegare il commento di Mikes e come ciò dovrebbe accelerare la sincronizzazione?

— Preexo,

Penso che Mike significhi il primo cambio sul posto e quindi l'aggiunta di nuovi, in modo che i nuovi non debbano essere - al posto di nuovo a causa della differenza di tempo tra la prima e la seconda chiamata. È vero solo se si risincronizza direttamente dall'archivio dati e le VM sono in esecuzione. A meno che non significhi qualcos'altro?

— Yuan,

Sono d'accordo con Yuan. Il secondo comando di Steves risincronizzerà di nuovo i nuovi file, puoi proteggerlo usando la sequenza di comandi Mikes.

— falstaff

rsync è estremamente inefficiente con file di grandi dimensioni. Vedi il mio commento sulla domanda.

— ndemou,

5

Rsync trasferisce solo le modifiche a ciascun file e con --inplace dovrebbe solo riscrivere i blocchi modificati senza ricreare il file. Dalla loro pagina delle caratteristiche .

rsync è un programma di trasferimento file per sistemi Unix. rsync utilizza l '"algoritmo rsync" che fornisce un metodo molto veloce per sincronizzare i file remoti. Lo fa inviando solo le differenze nei file attraverso il collegamento, senza richiedere che entrambi i set di file siano presenti in precedenza su una delle estremità del collegamento.

L'uso di --inplace dovrebbe funzionare per te. Questo ti mostrerà i progressi, comprimerà il trasferimento (al livello di compressione predefinito), trasferirà il contenuto della directory di archiviazione locale in modo ricorsivo (la prima barra finale conta), apporta le modifiche ai file in atto e usa ssh per il trasporto.

rsync -v -z -r --inplace --progress -e ssh /path/to/local/storage/ \
user@remote.machine:/path/to/remote/storage/

Uso spesso anche la bandiera -a che fa alcune altre cose. È equivalente a -rlptgoD Lascerò il comportamento esatto per te per cercare nella pagina man.

— reconbot
fonte

1

'-S' è per i file sparsi, non per 'tagliare lunghe file'. Dalla pagina man: -S, --sparse gestisce i file sparsi in modo efficiente. Ci proverò, grazie.

— fadedbee,

Grazie, l'ho risolto: stavo uscendo da qualcosa che è stato detto nel link che hai dato.

— Riconnettere il

No, sfortunatamente questo non risolve il problema. Si fa la sincronizzazione del file, ma si scopre il file sparse in fondo in un file non-sparse. Sto usando ssh / rsync fornito con Ubuntu 9.04.

— fadedbee,

Il mio commento sopra era errato. Il problema era che rsync crea file non sparsi nella sua prima copia. --Inplace rsync funziona correttamente, a condizione che il file di destinazione esista già e sia lungo (non grande) come il file di origine. Ora ho una soluzione, ma mi richiede di verificare se ogni file esiste già sul server di destinazione. Se lo fa, faccio un --inplace, in caso contrario, uso --sparse. Questo non è l'ideale, ma funziona.

— fadedbee,

rsync è estremamente inefficiente con file di grandi dimensioni. Vedi il mio commento sulla domanda

— ndemou,

4

Ho finito per scrivere software per fare questo:

http://www.virtsync.com

Questo è un software commerciale che costa $ 49 per server fisico.

Ora posso replicare un file sparso da 50 GB (che ha 3 GB di contenuto) in meno di 3 minuti attraverso la banda larga residenziale.

chris@server:~$ time virtsync -v /var/lib/libvirt/images/vsws.img backup.barricane.com:/home/chris/
syncing /var/lib/libvirt/images/vsws.img to backup.barricane.com:/home/chris/vsws.img (dot = 1 GiB)
[........>.........................................]
done - 53687091200 bytes compared, 4096 bytes transferred.

real    2m47.201s
user    0m48.821s
sys     0m43.915s

— fadedbee
fonte

4

TBH, il momento in cui è possibile sincronizzare è abbastanza insignificante perché ovviamente dipende dalla quantità di dati modificati. Ciò che sarebbe più preciso da dire è che ci vogliono 3 minuti per capire quali blocchi sono cambiati, e anche quella velocità probabilmente dipende dall'I / O del disco e dai cicli CPU disponibili.

— Reality Extractor

6

Dovresti rivelare che si tratta di un software commerciale che costa $ 98 o più per la funzionalità di rete.

— Reid

Grazie per averci indicato un software che ha funzionato bene per te, che le persone possono ora considerare e utilizzare o non utilizzare come necessario. Non grazie per le altre due persone per il contributo niente di nuovo.

— Florian Heigl,

3

Dai un'occhiata a Zumastor Linux Storage Project che implementa il backup "snapshot" usando "rsync" binario tramite lo ddsnapstrumento.

Dalla pagina man:

ddsnap fornisce la replica del dispositivo a blocchi data una funzione di istantanea a livello di blocco in grado di contenere in modo efficiente più istantanee simultanee. ddsnap può generare un elenco di blocchi di istantanee che differiscono tra due istantanee, quindi inviare tale differenza sul filo. Su un server downstream, scrivere i dati aggiornati su un dispositivo di blocco snapshot.

— rkthkr
fonte

2

lvmsync fa questo.

Ecco una trascrizione d'uso . Crea un'istantanea LVM sull'origine, trasferisce la partizione logica. È possibile trasferire gli aggiornamenti incrementali delle modifiche dalla creazione dell'istantanea tutte le volte che lo si desidera.

— Tobu
fonte

L'ho provato, ma non funziona e l'autore non è disposto a supportarlo

— user1007727

1

@ user1007727 non sei disposto a supportare o non sei disposto a supportare gratuitamente?

— fadedbee,

Ho usato lvmsync in passato, ha funzionato ma non è un software "prod grade" imo. :-)

— Florian Heigl,

1

La replica dell'intero file system potrebbe essere una soluzione? DRBD? http://www.drbd.org/

— James C
fonte

Non penso che drbd sia una buona soluzione qui, ma l'idea di rsyncing - al posto dell'intero fs, piuttosto che dei file di immagine del disco, è interessante. Non sono sicuro che rsync lo permetta - lo proverò e riporterò indietro ...

— fadedbee,

1

Forse un po 'strano qui, ma ho scoperto di recente che NFS gestisce così bene.

Quindi esporti una directory su una macchina, poi la monti sull'altra e copi semplicemente i file con utility di base come cp. (Alcune utility vecchie / antiche possono avere problemi con i file sparsi.)

Ho trovato rsyncparticolarmente inefficiente nel trasferimento di file sparsi.

— cstamas
fonte

1

Per sincronizzare file di grandi dimensioni o dispositivi a blocchi con differenze da basse a moderate, puoi fare una semplice copia o usare bdsync , rsync non è assolutamente adatto per questo caso particolare *.

bdsyncha funzionato per me, sembra abbastanza maturo, la sua storia di bug è incoraggiante (piccoli problemi, pronta risoluzione). Nei miei test la sua velocità era vicina al massimo teorico che potresti ottenere ** (ovvero puoi sincronizzare il tempo necessario per leggere il file). Finalmente è open source e non costa nulla.

bdsynclegge i file da entrambi gli host e scambia somme di controllo per confrontarli e rilevare le differenze. Tutti questi allo stesso tempo . Alla fine crea un file patch compresso sull'host di origine. Quindi si sposta quel file sull'host di destinazione ed si esegue bdsync una seconda volta per patchare il file di destinazione.

Quando lo si utilizza su un collegamento piuttosto veloce (ad es. Ethernet 100Mbit) e per file con piccole differenze (come spesso accade sui dischi VM) si riduce il tempo di sincronizzazione con il tempo necessario per leggere il file. Su un collegamento lento hai bisogno di un po 'più di tempo perché devi copiare le modifiche compresse da un host all'altro (sembra che puoi risparmiare tempo usando un bel trucco ma non hai ancora testato).

*: rsync è estremamente inefficiente con file di grandi dimensioni. Anche con --inplace leggerà prima l'intero file sull'host di destinazione, AFTERWARDS inizierà a leggere il file sull'host di origine e infine trasferirà le differenze (basta eseguire dstat o simili mentre si esegue rsync e osservare). Il risultato è che anche per file con piccole differenze ci vuole circa il doppio del tempo necessario per leggere il file per sincronizzarlo.

**: Partendo dal presupposto che non hai altro modo per dire quali parti dei file sono cambiate. Le snapshot LVM utilizzano bitmap per registrare i blocchi modificati in modo che possano essere estremamente più veloci (il file Leggimi di lvmsync ha più informazioni).

— ndemou
fonte

0

Non sono a conoscenza di una tale utility, solo delle chiamate di sistema che possono gestirla, quindi se scrivi una tale utility, potrebbe essere piuttosto utile.

quello che puoi effettivamente fare è usare qemu-img convert per copiare i file, ma funzionerà solo se FS di destinazione supporta file sparsi

— dyasny
fonte