Synchronizacja bardzo dużych struktur folderów

W naszym intranecie mamy strukturę folderów, która zawiera około 800 000 plików podzielonych na około 4 000 folderów. Musimy zsynchronizować to z małym klastrem maszyn w naszych strefach DMZ. Głębokość konstrukcji jest bardzo płytka (nigdy nie przekracza dwóch poziomów głębokości).

Większość plików nigdy się nie zmienia, każdego dnia aktualizuje się kilka tysięcy plików i 1-2 tysiące nowych plików. Dane to historyczne dane sprawozdawcze utrzymywane tam, gdzie dane źródłowe zostały usunięte (tj. Są to sfinalizowane raporty, dla których dane źródłowe są wystarczająco stare, aby je zarchiwizować i usunąć). Synchronizacja raz dziennie jest wystarczająca, biorąc pod uwagę, że może to nastąpić w rozsądnych ramach czasowych. Raporty są generowane z dnia na dzień, a pierwszą rzeczą synchronizujemy rano jako zaplanowane zadanie.

Oczywiście, ponieważ tak niewiele plików zmienia się regularnie, możemy znacznie skorzystać z kopii przyrostowej. Wypróbowaliśmy Rsync, ale wykonanie operacji „budowania listy plików” może potrwać od ośmiu do dwunastu godzin . Oczywiste jest, że szybko przerastamy możliwości rsync (ramy czasowe 12 godzin są o wiele za długie).

Do synchronizacji struktur używaliśmy innego narzędzia o nazwie RepliWeb, które może wykonać przyrostowy transfer w około 45 minut. Wydaje się jednak, że przekroczyliśmy limit. Zaczął widzieć, że pliki są usuwane, gdy nie są (być może niektóre struktury pamięci wewnętrznej zostały wyczerpane, nie jesteśmy pewni).

Czy ktoś jeszcze wpadł na tego rodzaju projekt synchronizacji na dużą skalę? Czy istnieje coś zaprojektowanego do obsługi takich ogromnych struktur plików w celu synchronizacji?

Jeśli możesz zaufać znacznikom czasu ostatniej modyfikacji systemu plików, możesz przyspieszyć, łącząc Rsync z narzędziem „znajdź” UNIX / Linux. „find” może zebrać listę wszystkich plików, które pokazują czasy ostatniej modyfikacji w ciągu ostatniego dnia, a następnie przesłać TYLKO tę skróconą listę plików / katalogów do Rsync. Jest to o wiele szybsze niż porównywanie metadanych każdego pliku nadawcy przez Rsync ze zdalnym serwerem.

Krótko mówiąc, następujące polecenie uruchomi Rsync TYLKO na liście plików i katalogów, które zmieniły się w ciągu ostatnich 24 godzin: (Rsync NIE będzie zadawał sobie trudu, aby sprawdzić inne pliki / katalogi).

find /local/data/path/ -mindepth 1 -ctime -0 -print0 | xargs -0 -n 1 -I {} -- rsync -a {} remote.host:/remote/data/path/.

Jeśli nie jesteś zaznajomiony z poleceniem „znajdź”, powtarza się ono w określonym poddrzewie katalogu, szukając plików i / lub katalogów, które spełniają dowolne określone kryteria. Na przykład to polecenie:

find . -name '\.svn' -type d -ctime -0 -print

rozpocznie się w bieżącym katalogu („.”) i przejrzy wszystkie podkatalogi, szukając:

• dowolne katalogi („-type d”),
• o nazwie „.svn” („-name” .svn ”),
• z metadanymi zmodyfikowanymi w ciągu ostatnich 24 godzin („-ctime -0”).

Wyświetla pełną nazwę ścieżki („-print”) dowolnego elementu spełniającego te kryteria na standardowym wyjściu. Opcje „-name”, „-type” i „-ctime” są nazywane „testami”, a opcja „-print” nazywana jest „akcją”. Strona podręcznika „find” zawiera pełną listę testów i działań.

Jeśli chcesz być naprawdę sprytny, możesz użyć testu „znajdź” polecenia „find” zamiast „-ctime”, aby uczynić ten proces bardziej odpornym na błędy i elastycznym. Opcja „-cnewer” sprawdza, czy każdy plik / katalog w drzewie ma zmodyfikowane metadane ostatnio niż jakiś plik referencyjny. Użyj „touch”, aby utworzyć plik referencyjny NEXT uruchomienia na początku każdego uruchomienia, tuż przed „find ... | Wykonuje się polecenie rsync ... '. Oto podstawowe wdrożenie:

#!/bin/sh
curr_ref_file=`ls /var/run/last_rsync_run.*`
next_ref_file="/var/run/last_rsync_run.$RANDOM"
touch $next_ref_file
find /local/data/path/ -mindepth 1 -cnewer $curr_ref_file -print0 | xargs -0 -n 1 -I {} -- rsync -a {} remote.host:/remote/data/path/.
rm -f $curr_ref_file

Ten skrypt automatycznie wie, kiedy był ostatnio uruchamiany i przesyła tylko pliki zmodyfikowane od ostatniego uruchomienia. Jest to bardziej skomplikowane, ale chroni przed sytuacjami, w których mógłbyś nie wykonywać zadania przez ponad 24 godziny, z powodu przestoju lub innego błędu.

Wypróbuj unison , został on specjalnie zaprojektowany, aby rozwiązać ten problem, przechowując listy zmian (budowanie listy plików), lokalnie na każdym serwerze, przyspieszając czas obliczania delty i zmniejszając ilość przesyłaną później przez drut.

http://oss.linbit.com/csync2/ jest przeznaczony do tego rodzaju rzeczy, spróbuję.

Jeśli używasz przełącznika -z na rsync, spróbuj uruchomić go bez niego. Z jakiegoś powodu widziałem, że przyspiesza to nawet początkowe wyliczanie plików.

Usunięcie polecenia -z z komendy rsync, która nie jest kompresją, spowodowało, że „lista plików do odbioru” poszła o wiele szybciej i musieliśmy przenieść około 500 GB. Wcześniej zajęło dzień z przełącznikiem -z.