Prześlij 15 TB małych plików

Archiwizuję dane z jednego serwera na drugi. Początkowo zacząłem rsyncpracę. Utworzenie listy plików zajęło tylko 2 tygodnie dla zaledwie 5 TB danych i kolejny tydzień na przesłanie 1 TB danych.

Potem musiałem zabić to zadanie, ponieważ potrzebowaliśmy trochę czasu na nowym serwerze.

Uzgodniono, że będziemy go przyspieszać, ponieważ prawdopodobnie nie będziemy musieli ponownie uzyskiwać do niego dostępu. Myślałem o podzieleniu go na 500 GB. Po tartym miałem zamiar to skopiować ssh. Używałem tari pigzale wciąż jest zbyt powolny.

Czy jest na to lepszy sposób? Myślę, że oba serwery są na Redhat. Stary serwer to Ext4, a nowy to XFS.

Rozmiary plików wahają się od kilku kb do kilku mb, a 5 TB zawiera 24 miliony plików JPEG. Więc zgaduję około 60-80 milionów na 15 TB.

edycja: Po kilku dniach gry z rsync, nc, tar, mbuffer i pigz. Wąskim gardłem będzie dyskowe we / wy. Ponieważ dane są rozłożone na 500 dyskach SAS i około 250 milionach plików JPEG. Jednak teraz dowiedziałem się o tych wszystkich fajnych narzędziach, których mogę używać w przyszłości.

Miałem bardzo dobre wyniki przy użyciu tar, pigz(równoległy gzip) i nc.

Maszyna źródłowa:

tar -cf - -C /path/of/small/files . | pigz | nc -l 9876

Maszyna docelowa:

Wyciągać:

nc source_machine_ip 9876 | pigz -d | tar -xf - -C /put/stuff/here

Aby zachować archiwum:

nc source_machine_ip 9876 > smallstuff.tar.gz

Jeśli chcesz zobaczyć szybkość transferu tylko przez rury pvpo pigz -d!

Trzymałbym się rozwiązania rsync. Nowoczesne (3.0.0+) rsync używa przyrostowej listy plików, więc nie musi budować pełnej listy przed przesłaniem. Ponowne uruchomienie nie będzie wymagać ponownego wykonania całego transferu w przypadku problemów. Podział transferu na katalog najwyższego lub drugiego poziomu jeszcze bardziej go zoptymalizuje. (Chciałbym użyć rsync -a -Pi dodać, --compressjeśli twoja sieć jest wolniejsza niż dyski).

Skonfiguruj VPN (jeśli jest to Internet), utwórz dysk wirtualny o jakimś formacie na zdalnym serwerze (make ext4), zamontuj go na serwerze zdalnym, a następnie zamontuj go na serwerze lokalnym (używając protokołu na poziomie bloku, takiego jak iSCSI ) i użyj polecenia dd lub innego narzędzia na poziomie bloku, aby wykonać transfer. Następnie możesz skopiować pliki z dysku wirtualnego na dysk rzeczywisty (XFS) według własnego uznania.

Dwa powody:

1. Brak obciążenia systemu plików, który jest głównym winowajcą wydajności
2. Bez szukania, patrzysz na sekwencyjny odczyt / zapis po obu stronach

Jeśli stary serwer jest wycofywany z eksploatacji, a pliki mogą znajdować się w trybie offline przez kilka minut, często najszybsze jest wyciągnięcie dysków ze starego urządzenia i podłączenie ich do nowego serwera, zamontowanie ich (teraz online) i skopiowanie plików na nowe serwery dyski macierzyste.

Użyj mbuffer, a jeśli jest w bezpiecznej sieci, możesz uniknąć kroku szyfrowania.

(Wiele różnych odpowiedzi może działać. Oto kolejna.)

Wygeneruj listę plików za pomocą find -type f(powinno to zakończyć się za kilka godzin), podziel ją na małe porcje i przenieś każdą porcję za pomocą rsync --files-from=....

Czy rozważałeś Sneakernet? Dzięki temu mam na myśli przeniesienie wszystkiego na ten sam dysk, a następnie fizyczne przeniesienie tego dysku.

około miesiąc temu Samsung zaprezentował dysk 16 TB (technicznie 15.36 TB), który jest również dyskiem SSD: http://www.theverge.com/2015/8/14/9153083/samsung-worlds-largest-hard -drive-16tb

Myślę, że ten dysk prawie by to zrobił. Nadal będziesz musiał skopiować wszystkie pliki, ale ponieważ nie masz opóźnień w sieci i prawdopodobnie możesz użyć SATA lub podobnie szybkiej techniki, powinno to być znacznie szybsze.

Jeśli jest jakaś szansa na uzyskanie wysokiego wskaźnika sukcesu podczas deduplikacji, użyłbym czegoś takiego jak borgbackup lub Attic.

Jeśli nie, sprawdź rozwiązanie netcat + tar + pbzip2 , dostosuj opcje kompresji zgodnie ze sprzętem - sprawdź, jakie jest wąskie gardło (procesor? Sieć? IO?). Pbzip2 ładnie rozciągałby się na wszystkie procesory, zapewniając lepszą wydajność.

Używasz RedHat Linux, więc nie miałoby to zastosowania, ale jako kolejna opcja:

Odniosłem wielki sukces, używając ZFS do przechowywania milionów plików, ponieważ i-węzły nie stanowią problemu.

Jeśli była to opcja dla ciebie, możesz zrobić migawki i użyć ZFS do wysyłania aktualizacji przyrostowych. Odniosłem wiele sukcesów, używając tej metody do przesyłania i archiwizowania danych.

ZFS jest przede wszystkim systemem plików Solaris, ale można go znaleźć w illumos (rozwidlenie open source Sun's OpenSolaris). Wiem, że przy odrobinie szczęścia można było używać ZFS pod BSD i Linuksem (używając FUSE?) - ale nie mam doświadczenia w próbowaniu tego.

Uruchom rsyncdemona na maszynie docelowej. Przyspieszy to znacznie proces transferu.

Możesz to zrobić za pomocą tar i ssh, w następujący sposób:

tar zcf - <your files> | ssh <destination host> "cat > <your_file>.tar.gz"

Lub jeśli chcesz zachować pojedyncze pliki:

tar zcf - <your files> | ssh <destination host> "tar zxf -"