Najlepszy sposób na skopiowanie milionów plików między 2 serwerami

Mam w przybliżeniu 5 milionów małych (5-30k) plików w jednym katalogu, które chciałbym skopiować na inny komputer w tej samej sieci gigabitowej. Próbowałem użyć rsync, ale spowolniłoby to indeksowanie po kilku godzinach działania. Zakładam, że rsync musi za każdym razem sprawdzać plik źródłowy i docelowy?

Moją drugą myślą byłoby użycie scp, ale chciałem uzyskać opinię z zewnątrz, aby sprawdzić, czy jest lepszy sposób. Dzięki!

Coś takiego powinno działać dobrze:

tar c some/dir | gzip - |  ssh host2 tar xz

Być może pomiń gzip i flagę „z” do rozpakowywania, ponieważ jesteś w sieci gigabit.

Jestem pewien, że posiadanie wszystkich PIĘCIU MILIONÓW plików w jednym katalogu spowoduje wiele problemów. Nie dziwię się, że rsync nie poradził sobie z tym z wdziękiem - jest to dość „wyjątkowa” sytuacja. Jeśli możesz znaleźć sposób na uporządkowanie plików w jakąś strukturę katalogów, jestem pewien, że standardowe narzędzia do synchronizacji, takie jak rsync, byłyby znacznie bardziej responsywne.

Jednak tylko po to, aby udzielić rzeczywistych porad - być może jednym z rozwiązań byłoby tymczasowe fizyczne przeniesienie dysku na komputer docelowy, aby można było wykonać kopię plików na rzeczywistym serwerze (nie przez sieć). Następnie przenieś dysk z powrotem i użyj rsync, aby zachować aktualność.

Aby skopiować miliony plików za pomocą przełącznika gigabitowego (w zaufanym środowisku), możesz również użyć kombinacji netcat (or nc)i tar, jak już zasugerował użytkownik 55286. Spowoduje to przesłanie strumieniowe wszystkich plików jako jednego dużego pliku (patrz Szybka kopia pliku - Linux! (39 GB) ).

# requires netcat on both servers
nc -l -p 2342 | tar -C /target/dir -xzf -   # destination box
tar -cz /source/dir | nc Target_Box 2342    # source box

W katalogu mieliśmy około 1 miliona plików (pliki o wartości około 4 lat).

I użyliśmy robocopy do przeniesienia plików do katalogu RRRR / MM (około 35-45,000 plików miesięcznie) .. umieściliśmy skrypt robocopy w pliku .bat takim jak ten:

ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20081101 /MINAGE:20081201 /MOV H:\Cs\out\fix H:\BCK_REPORT\2008\11
ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20081201 /MINAGE:20090101 /MOV H:\Cs\out\fix H:\BCK_REPORT\2008\12
ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20090101 /MINAGE:20090201 /MOV H:\Cs\out\fix H:\BCK_REPORT\2009\01
ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20090201 /MINAGE:20090301 /MOV H:\Cs\out\fix H:\BCK_REPORT\2009\02

krótkie notatki .. /ns /nc /nfl /npaby uniknąć rozdęcia pliku dziennika dodatkowymi informacjami, /log+...należy zapisać informacje podsumowujące w pliku dziennika.

/minage and /maxage is to copy files modified with in that date range. 

więc na przykład pliki zmodyfikowane> = 01 / Nov / 2008 (włącznie) do plików zmodyfikowanych <01 / Dec / 2008 (nie obejmuje)

ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20081101 /MINAGE:20081201 /MOV H:\Cs\out\fix H:\BCK_REPORT\2008\11

/mov przenieść pliki

następnie pojawia się katalog źródłowy

następnie pojawia się katalog docelowy (katalogi będą tworzone w locie, gdy jest to wymagane).

Przeniesienie trwało około 40–60 minut w ciągu 1 miesiąca (około 35–45,000 plików). Szacujemy, że przeniesienie zajmuje około 12 godzin lub mniej.

Korzystanie z systemu Windows Server 2003.

Wszystkie rzeczy są rejestrowane w pliku dziennika ... Czas rozpoczęcia, czas zakończenia i liczba skopiowanych plików.

Robocopy uratował dzień.

Wiesz, dodałem -1 do rozwiązania smoły, ale - w zależności od środowiska - pojawia się jeszcze jeden pomysł. Możesz pomyśleć o użyciu dd (1) . Problem prędkości związany z czymś takim jest taki, że potrzeba wielu ruchów głową, aby otworzyć i zamknąć plik, co będziesz robił pięć milionów razy. Aby mieć pewność, że są one przypisywane przypadkowo, możesz zamiast tego je dodać, co zmniejszy liczbę ruchów głowy pięciokrotnie lub więcej.

W tej chwili wolę używać lz4 jako najszybszego narzędzia kompresji. Opcja SSH -c arcfour128 używa szybszego algorytmu szyfrowania niż domyślny. [1]

Transfer katalogu wygląda więc tak:

tar -c folder | lz4 -c | ssh -carcfour128 somehost 'lz4 -d | tar -x > folder'

Zauważ, że w Debianie polecenie lz4 to lz4c, a w CentOS to lz4.

Robocopy jest świetny do takich rzeczy. Spróbuje ponownie po przekroczeniu limitu czasu sieci, a także pozwala ustawić opóźnienie między pakietami, aby teraz zamoczyć potok.

[Edytować]

Pamiętaj, że jest to aplikacja tylko dla systemu Windows.

Wiem, że to może być głupie - ale czy pomyślałeś o skopiowaniu ich na dysk zewnętrzny i przeniesieniu na inny serwer? To może być najskuteczniejsze i najprostsze rozwiązanie.

Obecnie badamy ten problem. Musimy przenieść około 18 milionów małych plików - łącznie około 200 GB. Osiągnęliśmy najlepszą wydajność przy użyciu zwykłego starego XCopy, ale wciąż trwało to DŁUGO. Około 3 dni od jednego serwera do drugiego, około 2 tygodnie na dysk zewnętrzny!

W innym procesie musieliśmy zduplikować serwer. Dokonano tego za pomocą Acronis. Zajęło to około 3 godzin !!!

Będziemy to badać jeszcze trochę. Powyższa sugestia dd prawdopodobnie zapewni podobne wyniki.

Już mnóstwo dobrych sugestii, ale chciałem dodać Beyond Compare . Niedawno przesłałem około 750 000 plików między 5 KB a 20 MB z jednego serwera na drugi za pomocą przełącznika gigabitowego. To wcale nie miało czknięcia. To prawda, że ​​zajęło to trochę czasu, ale oczekiwałbym tego przy tak dużej ilości danych.

Zobaczyłbym, jak działa zip-> kopiowanie-> rozpakowanie

lub czymkolwiek jest twój ulubiony system kompresji / archiwizacji.

Spakuj je do jednego pliku przed skopiowaniem, a następnie rozpakuj je ponownie po skopiowaniu.

W podobnej sytuacji próbowałem użyć tar do grupowania plików. Napisałem mały skrypt, który przekazuje dane wyjściowe polecenia tar bezpośrednio do komputera docelowego bezpośrednio do odbierającego procesu tar, który rozdziela pliki.

Metoda tar prawie podwoiła szybkość transferu w porównaniu do scp lub rsync (YMMV).

Oto komendy tar. Pamiętaj, że musisz włączyć polecenia r, tworząc pliki .rhosts w katalogach domowych każdego komputera (usuń je po zakończeniu kopiowania - są to często występujące problemy z bezpieczeństwem). Zauważ też, że jak zwykle HP-UX jest niezręczny - podczas gdy reszta świata używa polecenia „rsh” do polecenia powłoki zdalnej, HP-UX używa „remsh”. „rsh” to rodzaj ograniczonej powłoki w języku HP.

box1> cd source_directory; tar cf - . | remsh box2 "cd target_directory; tar xf - "

Pierwsze polecenie tar tworzy plik o nazwie „-”, który jest specjalnym tokenem oznaczającym w tym przypadku „standardowe wyjście”. Utworzone archiwum zawiera wszystkie pliki w bieżącym katalogu (.) Oraz wszystkie podkatalogi (domyślnie tar jest rekurencyjny). Ten plik archiwum jest przesyłany do komendy remsh, która wysyła go do komputera box2. W polu 2 najpierw przechodzę do właściwego katalogu odbiorczego, a następnie wypakowuję przychodzące pliki z „-” lub „standardowego wejścia”.

Miałem 6 z tych poleceń tar działających jednocześnie, aby upewnić się, że łącze sieciowe jest nasycone danymi, chociaż podejrzewam, że dostęp do dysku mógł być czynnikiem ograniczającym.

Obejdź system plików.

Czy jesteś w stanie odmontować tę partycję, na której znajdują się na niej pliki, lub zamontować ją tylko do odczytu? Zrób to, a następnie coś takiego:

dd if=/dev/PARTITION | ssh username@host "dd of=diskimage.bin"

Następnie można zamontować diskimage.binjako urządzenie sprzężenia zwrotnego po stronie docelowej i skopiować pliki z niego do rzeczywistego docelowego systemu plików lub użyć odpowiednich narzędzi, aby połączyć go z powrotem w pustą partycję po stronie docelowej (niebezpieczne, ale prawdopodobnie możliwe , chociaż nigdy tego nie zrobiłem).

Jeśli jesteś naprawdę odważny, możesz ddto zrobić bezpośrednio z powrotem na partycję po stronie docelowej. Nie polecam tego.

możesz wypróbować następujące (może być w partiach plików)

• tar pakiet plików
• zgzipuj je
• kopiuj używając scp, jeśli to możliwe
• gunzip
• rozpakować pliki

Jak sugeruje sth, możesz spróbować tar nad ssh.

Jeśli nie potrzebujesz szyfrowania (pierwotnie używałeś rsync, ale nie wspomniałeś, że to rsync + ssh), możesz spróbować tar przez netcat, aby uniknąć narzutu ssh.

Oczywiście możesz także skrócić czas, używając gzip lub innej metody kompresji.

Jest jeszcze coś do rozważenia. Spróbuj tego:

• Utwórz dysk VHD o dynamicznym rozmiarze
• Zamontuj go, prawdopodobnie jako katalog
• Ustaw atrybut „kompresuj cały dysk”

Dzięki temu nie ma narzutu związanego z iteracją lub kompresją katalogu, ponieważ dokonano tego w momencie zapisywania plików. Do przeniesienia jest tylko jeden plik - VHD.

W systemie Windows domyślny rozmiar pakietu TCP jest większy, na przykład 16348. Oznacza to mniejszy narzut nagłówka IP.

Jedną z rzeczy, na które wpadłem, jest to, że najlepiej jest utrzymywać rozmiary plików poniżej 100 Mb dla transferu sieciowego lub USB. Używam do tego Rar.exe - do dzielenia plików.

Działa jak mistrz. Jest to odpowiednik „dd” w systemie Linux. Koncepcja montowania skompresowanego systemu plików w katalogu jest również normalna w systemie Linux, więc obowiązuje ta sama logika. Należy upewnić się, że wszystkie pliki są zamknięte przed rozpoczęciem operacji, podobnie jak w przypadku innych metod.

Ma to tę dodatkową zaletę, że umożliwia umieszczenie limitu rozmiaru w folderze. Jeśli VHD ma ustalony rozmiar, przekroczenie tego limitu nie spowoduje awarii serwera, tylko spowoduje błąd podczas tworzenia lub zapisywania pliku.

Dysk VHD sformatowany jako NTFS może również obsługiwać miliony plików w folderze.