Jak synchronizować ogromne rzadkie pliki (obrazy dysków VM) między komputerami?

Czy istnieje polecenie, takie jak rsync, które może synchronizować ogromne, rzadkie pliki z jednego serwera linux na inny?

Bardzo ważne jest, aby plik docelowy pozostał rzadki. Może być dłuższy (ale nie większy) niż dysk, który go zawiera. Tylko zmienione bloki powinny być przesyłane w poprzek drutu.

Próbowałem rsync, ale nie miałem radości. https://groups.google.com/forum/#!topic/mailing.unix.rsync/lPOScZgFE9M

Jeśli napiszę program, aby to zrobić, czy po prostu odkrywam koło? http://www.finalcog.com/synchronise-block-devices

Dzięki,

Chris.

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

Aby utworzyć nowe pliki w trybie rzadkim

Śledzony przez

rsync --inplace ...

Aby zaktualizować wszystkie istniejące pliki (w tym wcześniej utworzone rzadkie) na miejscu.

Rsync przenosi zmiany tylko do każdego pliku, a przy pomocy --inplace powinien przepisać tylko te bloki, które uległy zmianie, bez odtwarzania pliku. Ze strony ich funkcji .

rsync to program do przesyłania plików dla systemów Unix. rsync używa „algorytmu rsync”, który zapewnia bardzo szybką metodę synchronizacji zdalnych plików. Robi to, wysyłając tylko różnice w plikach w łączu, bez wymagania wcześniejszego obecności obu zestawów plików na jednym z końców łącza.

Używanie --inplace powinno działać dla Ciebie. To pokaże ci postępy, skompresuj transfer (na domyślnym poziomie kompresji), rekursywnie przenieś zawartość lokalnego katalogu pamięci (ten pierwszy ukośnik ma znaczenie), dokonaj zmian w plikach i użyj ssh do transportu.

rsync -v -z -r --inplace --progress -e ssh /path/to/local/storage/ \
[email protected]:/path/to/remote/storage/ 

Często używam również flagi -a, która robi jeszcze kilka rzeczy. Jest to odpowiednik opcji -rlptgoD Zostawię dokładne zachowanie, abyś mógł zajrzeć na stronę podręcznika.

Skończyłem pisać oprogramowanie, aby to zrobić:

http://www.virtsync.com

To oprogramowanie komercyjne kosztuje 49 USD za serwer fizyczny.

Mogę teraz replikować rzadki plik 50 GB (który zawiera 3 GB zawartości) w niecałe 3 minuty na szerokopasmowym łączu mieszkaniowym.

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 

Spójrz na Zumastor Linux Storage Project, który implementuje tworzenie kopii zapasowej „migawki” za pomocą narzędzia binarnego „rsync” za pomocą ddsnapnarzędzia.

Ze strony podręcznika:

ddsnap zapewnia replikację urządzenia blokowego, biorąc pod uwagę funkcję migawki na poziomie bloku, zdolną do efektywnego przechowywania wielu jednoczesnych migawek. ddsnap może wygenerować listę porcji migawek, które różnią się między dwiema migawkami, a następnie przesłać tę różnicę przewodowo. Na dalszym serwerze zapisz zaktualizowane dane w migawkowym urządzeniu blokowym.

Lvmsync to robi.

Oto zapis użycia . Tworzy migawkę LVM na źródle, przenosi partycję logiczną. Możesz przesyłać przyrostowe aktualizacje zmian od momentu utworzenia migawki tak często, jak chcesz.

Czy replikacja całego systemu plików może być rozwiązaniem? DRBD? http://www.drbd.org/

Może tutaj trochę dziwne, ale ostatnio dowiedziałem się, że NFS dobrze sobie z tym radzi.

Więc eksportujesz katalog na jednym komputerze, a następnie montujesz go na drugim i po prostu kopiujesz pliki za pomocą podstawowych narzędzi, takich jak cp. (Niektóre stare / starożytne narzędzia mogą mieć problem z rzadkimi plikami).

Stwierdziłem, że jest rsyncszczególnie nieefektywny w przesyłaniu rzadkich plików.

Aby zsynchronizować duże pliki lub urządzenia blokowe o małych do średnich różnicach, możesz wykonać zwykłą kopię lub użyć bdsync , rsync absolutnie nie nadaje się do tego konkretnego przypadku *.

bdsyncpracował dla mnie, wydaje się wystarczająco dojrzały, jego historia błędów jest zachęcająca (drobne problemy, szybkie rozwiązanie). W moich testach jego prędkość była bliska teoretycznego maksimum, jakie można uzyskać ** (tzn. Można zsynchronizować czas potrzebny na odczyt pliku). Wreszcie jest open source i nic nie kosztuje.

bdsyncodczytuje pliki z obu hostów i wymienia sumy kontrolne, aby je porównać i wykryć różnice. Wszystko to jednocześnie . W końcu tworzy skompresowany plik łaty na hoście źródłowym. Następnie przenieś ten plik do hosta docelowego i uruchom bdsync po raz drugi, aby załatać plik docelowy.

W przypadku korzystania z dość szybkiego łącza (np. 100 Mb / s Ethernet) i plików z małymi różnicami (jak to najczęściej ma miejsce na dyskach VM), skraca czas synchronizacji do czasu potrzebnego do odczytania pliku. W przypadku powolnego linku potrzebujesz trochę więcej czasu, ponieważ musisz skopiować skompresowane zmiany z jednego hosta na drugi (wydaje się, że możesz zaoszczędzić czas stosując dobrą sztuczkę, ale nie przetestowałem).

*: rsync jest bardzo nieefektywny w przypadku dużych plików. Nawet z opcją --inplace najpierw najpierw odczyta cały plik na hoście docelowym, PO ZATRZYMANIU zacznie czytać plik na hoście źródłowym i w końcu prześle różnice (po prostu uruchom dstat lub podobny podczas rsync i obserwuj). Powoduje to, że nawet w przypadku plików z niewielkimi różnicami potrzeba około dwukrotnie więcej czasu na odczytanie pliku w celu jego synchronizacji.

**: Przy założeniu, że nie ma innego sposobu, aby powiedzieć, które części plików uległy zmianie. Migawki LVM używają map bitowych do rejestrowania zmienionych bloków, dzięki czemu mogą być one wyjątkowo szybsze ( plik Readme lvmsync zawiera więcej informacji).

Nie znam takiego narzędzia, tylko wywołania systemowe, które mogą go obsłużyć, więc jeśli napiszesz takie narzędzie, może być raczej pomocne.

co faktycznie możesz zrobić, to użyć qemu-img convert do skopiowania plików, ale zadziała to tylko wtedy, gdy docelowy FS obsługuje rzadkie pliki