Czy ktoś osiągnął prawdziwą synchronizację różnicową z rsync w ESXi?

Zaskocz mnie później, że używam konsoli serwisowej do robienia czegokolwiek w ESXi ...

Mam działający plik binarny rsync (v3.0.4), którego mogę używać w ESXi 4.1U1. Zwykle używam rsync nad cp podczas kopiowania maszyn wirtualnych lub kopii zapasowych z jednego lokalnego magazynu danych do innego lokalnego magazynu danych. Użyłem rsync do skopiowania danych z jednego urządzenia ESXi do drugiego, ale dotyczyło to tylko małych plików.

Próbuję teraz wykonać prawdziwe różnicowe synchronizacje kopii zapasowych wykonanych przez ghettoVCB między moją główną maszyną ESXi a drugą. Ale nawet gdy robię to lokalnie (jeden magazyn danych do drugiego magazynu danych na tym samym komputerze ESXi) rsync wydaje się kopiować pliki w całości. Mam dwa pliki VMDK o wielkości 80 GB, a rsync nadal zajmuje od 1 do 2 godzin, ale VMDK nie rośnie tak bardzo codziennie.

Poniżej znajduje się polecenie rsync, które wykonuję. Kopiuję lokalnie, ponieważ ostatecznie te pliki zostaną skopiowane do magazynu danych utworzonego z jednostki LUN w systemie zdalnym. To nie jest rsync, który będzie obsługiwany przez demona rsync w systemie zdalnym.

rsync -avPSI VMBACKUP_2011-06-10_02-27-56/* VMBACKUP_2011-06-01_06-37-11/ --stats --itemize-changes --existing --modify-window=2 --no-whole-file
sending incremental file list
>f..t...... VM-flat.vmdk
 42949672960 100%   15.06MB/s    0:45:20 (xfer#1, to-check=5/6)
>f..t...... VM.vmdk
         556 100%    4.24kB/s    0:00:00 (xfer#2, to-check=4/6)
>f..t...... VM.vmx
        3327 100%   25.19kB/s    0:00:00 (xfer#3, to-check=3/6)
>f..t...... VM_1-flat.vmdk
 42949672960 100%   12.19MB/s    0:56:01 (xfer#4, to-check=2/6)
>f..t...... VM_1.vmdk
         558 100%    2.51kB/s    0:00:00 (xfer#5, to-check=1/6)
>f..t...... STATUS.ok
          30 100%    0.02kB/s    0:00:01 (xfer#6, to-check=0/6)

Number of files: 6
Number of files transferred: 6
Total file size: 85899350391 bytes
Total transferred file size: 85899350391 bytes
Literal data: 2429682778 bytes
Matched data: 83469667613 bytes
File list size: 129
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 2432530094
Total bytes received: 5243054

sent 2432530094 bytes  received 5243054 bytes  295648.92 bytes/sec
total size is 85899350391  speedup is 35.24

Czy to dlatego, że sam ESXi dokonuje tak wielu zmian w VMDK, że jeśli chodzi o rsync, cały plik musi zostać ponownie przesłany?

Czy ktoś faktycznie osiągnął rzeczywistą synchronizację różnic z ESXi?

Wygląda na to, że przesłałeś tylko 2 GB zmian przyrostowych. Pamiętaj, że rsync nadal musi odczytać jeden plik i zsumować go, aby mógł odczytać 80 GB danych. Sprawdź statystyki serwera podczas rsync. Czy jesteś związany procesorem lub IO podczas operacji? Jak szybko można odczytać plik 80 GB z dysku? To będzie blisko twojego absolutnego minimalnego czasu transferu.

Warto również zauważyć, że rsync tworzy kopię pliku podczas przesyłania, a następnie przenosi plik końcowy na miejsce w operacji atomowej. Możesz to zobaczyć, widząc podobną nazwę pliku z losowym sufiksem podczas przesyłania w katalogu docelowym. Oznacza to, że musisz odczytać 160 GB danych (80 GB dla każdego źródła i miejsca docelowego) i zapisać 80 GB po stronie docelowej. Czy przejrzałeś opcję --inplace? Tutaj może być korzystne.

Krótko mówiąc, możesz mieć tylko 2 GB zmian, ale rsync wykonuje DUŻO pracy. Prawdopodobnie jesteś związany IO, ponieważ całe czytanie i pisanie na tym samym dysku mogłoby spowodować wiele sporów i spowolnienia.

Ten wątek jest bardzo stary, ale niech ktoś mu pomoże.

Ponieważ ESX blokuje system plików przy każdym zapisie nowych bloków, wydajność nie jest tak duża, z Opcją - w miejscu możesz uzyskać lepsze wyniki, ale pamiętaj, że jeśli anulujesz synchronizację, plik nie będzie spójny więcej. Jeśli chodzi o spójność, rsync otwartego pliku może być niespójny w jakikolwiek sposób -> lepiej użyć migawki przed rsync.

Z pozdrowieniami Marc

Wygląda na to, że wykonujesz kopię lokalną z lokalną rsync. W takim przypadku domyślnym zachowaniem rsyncjest wyłączenie algorytmu transferu delta i wykonywanie transferu „całego pliku”. Uzasadnieniem tego domyślnego zachowania jest to, że transfery lokalne do lokalnych przy użyciu algorytmu delta-xfer byłyby zwykle wolniejsze niż zwykłe kopiowanie całych plików, ponieważ algorytm delta wymaga znacznie więcej awarii procesora niż kopiowanie całych plików.

Jeśli uważasz, że kopia lokalna-lokalna skorzystałaby na użyciu algorytmu delta-xfer, możesz zmusić ją rsyncdo użycia, określając opcję --no-W(lub --no-whole-file).