Synchronizacja bardzo dużych struktur folderów

14

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?

backup rsync synchronization unison MightyE
źródło
Czy próbowałeś podzielić pracę na kilka instancji rsync działających w tym samym czasie? Nie mam dobrego obrazu struktury katalogów, ale możesz podzielić ją według nazwy katalogu lub nazwy pliku.
Sprzęgło
Myśleliśmy o tym, ale przy tak płaskiej strukturze trudno jest znaleźć dobre linie podziału, na których można by podzielić pracę. Komplikuje to fakt, że foldery są w większości bardzo podobnie nazywane (istnieje konwencja nazewnictwa, która sprawia, że ​​większość folderów zaczyna się od tego samego początkowego zestawu 6 znaków).
MightyE,
Czy kiedykolwiek znalazłeś dobre rozwiązanie, Dave? Rozważam lsyncd dla katalogu z podkatalogami 65535, z których każdy może mieć 65 ^ 16 plików.
Mike Diehn
1
@MikeDiehn Nigdy nie znalazłem narzędzia, z którego byłem całkowicie zadowolony. Dostaliśmy to autorskie narzędzie RepliWeb do naprawy błędu polegającego na tym, że widzieli pliki jako usunięcia, których nie było, była to przepełniona struktura wewnętrzna. Opuściłem tę pracę wiele lat temu, zakładam, że nadal z niej korzystają. Jeśli twoje katalogi są rozsądnie dystrybuowane, możesz wybrać rozwiązanie Ryana. Nie zauważy usuwania najwyższego poziomu, ale podkatalogi 65535 sugerują mi, że prawdopodobnie ich nie masz.
MightyE

Odpowiedzi:

9

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.

Ryan B. Lynch
źródło
To niezwykle sprytne rozwiązanie! Myślę, że masz na myśli touch $next_ref_filena końcu? Nie pozostawia nam to jednak możliwości radzenia sobie z usuniętymi ścieżkami (nawet te statyczne raporty archiwalne w końcu się zestarzeją, aby zostały zarchiwizowane i usunięte). To może nie być jednak przerywnik programu.
MightyE
Przekonałem się jednak, że nawet find . -ctime 0ta struktura katalogów jest dość powolna (wciąż czekam na jej ukończenie, aby zgłosić swój czas). To trochę mnie zniechęca, ponieważ wygląda na to, że może to być operacja na niskim poziomie, która prawdopodobnie wyznacza granicę najszybszej możliwej do wykonania pracy. Może się zdarzyć, że czynnikiem ograniczającym będzie we / wy dysku.
MightyE
Jeśli chodzi o ten skryptlet, tak, popełniłem błąd. Miałem na myśli uruchomienie „touch” na „next_ref_file” (NIE „curr_ref_file”) tuż przed uruchomieniem „find ... | polecenie rsync ... ”. (Naprawię odpowiedź.)
Ryan B. Lynch
3
Co do powolnego polecenia „znajdź”: jakiego systemu plików używasz? Jeśli używasz Ext3, możesz rozważyć dwa ulepszenia FS: 1) Uruchom „tune2fs -O katalog_dir <DEVICE_NODE>”, aby włączyć funkcję „dir_index” Ext3, aby przyspieszyć dostęp do katalogów z dużą liczbą plików. 2) Uruchom „mount -o remount, noatime, nodiratime”, aby wyłączyć aktualizacje czasu dostępu, co ogólnie przyspiesza czytanie. 'dumpe2fs -h <DEVICE_NODE> | grep dir_index ”informuje, czy„ dir_index ”jest już włączony (w niektórych dystrybucjach jest to ustawienie domyślne), a„ mount | grep <DEVICE_NODE> ”informuje o aktualizacjach czasu dostępu.
Ryan B. Lynch
Niestety jest to NTFS - Windows 2003 Server używa Cygwin jako polecenia find. Zapamiętam te opcje dostrajania (doskonała rada) dla ext3 na wypadek, gdybyśmy kiedykolwiek natrafili na coś podobnego w jednym z naszych klastrów Debiana.
MightyE,
7

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.

Dave Cheney
źródło
Próbuję Unison. Działa od około 2 godzin na etapie „Szukam zmian” i na podstawie plików, nad którymi obecnie pracuje, wygląda na to, że jest w połowie ukończony (więc może 4 godziny przed rozpoczęciem przesyłania). Wygląda na to, że będzie lepszy niż rsync, ale nadal poza naszym pożądanym oknem operacyjnym.
MightyE
2
Przy pierwszym utworzeniu indeksu po obu stronach czasy odbudowywania są podobne do rsync, ponieważ ma on mieszać każdy plik. Po wykonaniu tej czynności unison używa ostatniej modyfikacji katalogu do zidentyfikowania zmiany pliku i musi jedynie przeskanować ten plik w poszukiwaniu zmian.
Dave Cheney
Niestety padłem ofiarą nadmiernie gorliwego administratora Operations, który wymusił zakończenie sesji przed budowaniem katalogu (ograniczamy liczbę jednoczesnych logowań do serwerów produkcyjnych). Straciłem postępy w tworzeniu początkowego katalogu, więc muszę zacząć od nowa. Dam ci znać, jak to idzie.
MightyE
Teraz zajmuje około 2 godzin od utworzenia katalogu początkowego w celu wyszukania zmian. Jestem dość zaskoczony, ile pamięci RAM używa do tego Unison. W naszej kolekcji plików serwer źródłowy używa 635M, a klient zdalny używa 366M. Zsynchronizowanie kilku komputerów w klastrze byłoby dość dużym obciążeniem, szczególnie dla serwera źródłowego!
MightyE,
1
Czy potrafisz uporządkować swoje dane w sposób ułatwiający identyfikację danych, które ostatnio zmieniłeś? Czy to znaczy, przechowywanie go w formacie rok / miesiąc / dzień / ...?
Dave Cheney
2

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.

Chris Thorpe
źródło
Próbowaliśmy z flagą -z i bez. Wydaje się, że nie miało to wpływu na czas wykonywania „listy plików budowlanych”.
MightyE
2

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.

ryand32
źródło