jaki jest najszybszy i najbardziej niezawodny sposób przesyłania dużej liczby plików?

10

Próbuję przesłać około 100 000 plików o łącznej wielkości 90 GB. Obecnie używam demona rsync, ale jego szybkość 3,4 Mb / s muszę to zrobić wiele razy. Zastanawiam się, jakie mam opcje, które zmaksymalizują połączenie 100mbit przez Internet i będą bardzo niezawodne.

incognito2
źródło
2
Otrzymujesz prawie jedną trzecią swojego połączenia - to szanowane, ale nie świetne. Jak daleko leci elektron, przenoszone są pliki?
Shane Madden,
50 ms opóźnienie między dwoma serwerami.
incognito2,
5
Kiedyś zobaczyłem dużo plików hiperbolaandahalf.blogspot.com/2010/04/…
Smudge
Jeśli używasz demona rsync, nie ma w tym udziału ssh, prawda? Wyjaśnienie to prawdopodobnie infrastruktura pomiędzy hostami. Możesz spróbować netperf lub iperf lub flowgrind, aby przetestować prędkość między hostami. Jeśli ten test zapewnia wyższą prędkość transferu, powinieneś przyjrzeć się, jak rsync spowalnia pracę: wolno odczytuje operacje we / wy na serwerze, zapisuje operacje we / wy na kliencie, wiele małych plików, system plików itp.
AndreasM

Odpowiedzi:

11

Czy rozważałeś Sneakernet ? Przy dużych zestawach danych nocna wysyłka jest często szybsza i tańsza niż przesyłanie przez Internet.

ceejayoz
źródło
10
„Nigdy nie lekceważ przepustowości wozu kombi pełnego taśm pędzących po autostradzie”. - AST
voretaq7,
1
Cóż, biorąc pod uwagę przystępność cenową sprzętu gigabitowego LAN, jeśli jest to transfer LAN, czas pisania przez eSATA na jednym wrzecionie nie jest wcale taki atrakcyjny.
memnoch_proxy
10

W jaki sposób? Lub TL; DR

Najszybszy sposób znalazłem to połączenie tar, mbuffera ssh.

Na przykład:

tar zcf - bigfile.m4p | mbuffer -s 1K -m 512 | ssh otherhost "tar zxf -"

Dzięki temu osiągnąłem trwały transfer sieci lokalnej ponad 950 Mb / s na łączach 1 Gb. Zamień ścieżki w każdym poleceniu tar, aby były odpowiednie do tego, co przenosisz.

Dlaczego? mbuffer!

Największym wąskim gardłem w przesyłaniu dużych plików przez sieć jest zdecydowanie dyskowe operacje we / wy. Odpowiedź brzmi: mbufferlub buffer. Są w dużej mierze podobne, ale mbuffermają pewne zalety. Domyślny rozmiar bufora to 2 MB dla mbufferi 1 MB dla buffer. Większe bufory prawdopodobnie nigdy nie będą puste. Wybór rozmiaru bloku, który jest najniższą wspólną wielokrotnością rodzimego rozmiaru bloku zarówno w docelowym, jak i docelowym systemie plików, zapewni najlepszą wydajność.

Buforowanie jest rzeczą, która sprawia, że wszystkie różnica! Użyj go, jeśli go masz! Jeśli go nie masz, weź go! Używanie (m}?bufferplus cokolwiek jest lepsze niż cokolwiek innego. jest to niemal dosłownie panaceum na powolne przesyłanie plików w sieci.

Jeśli przenosisz wiele plików, użyj ich, taraby „połączyć” je w jeden strumień danych. Jeśli jest to pojedynczy plik, którego można użyć catlub przekierowanie we / wy. Obciążenie tarvs. catjest statystycznie nieistotne, więc zawsze używam tar(lub zfs -sendgdzie mogę), chyba że jest to już tarball . Żadne z nich nie gwarantuje otrzymania metadanych (w szczególności catnie będzie). Jeśli chcesz metadanych, zostawię to jako ćwiczenie dla ciebie.

Wreszcie użycie sshmechanizmu transportowego jest zarówno bezpieczne, jak i niesie za sobą bardzo niewiele kosztów. Ponownie, narzut sshkontra vs. ncjest statystycznie nieistotny.

bahamat
źródło
Używanie SSH jako transportu czasami wiąże się z narzutami związanymi z szyfrowaniem. Zobacz: Kopiowanie plików między komputerami z systemem Linux z silnym uwierzytelnianiem bez szyfrowania
ewwhite
2
W razie potrzeby możesz użyć szybszych mechanizmów szyfrowania. Ale niekoniecznie musisz przesyłać to ssh. Wolę ustawić porty -O i -I na mbufferze po obu stronach. Mimo że są to teraz dwa polecenia, pomijasz szyfrowanie i maksymalizujesz przepustowość sieci, buforując oba końce. Przesyłam strumień smoły w tar -cf - .|mbuffer -m128k -s 256M -I 9090 & mbuffer -m128k -s 256M -O host:9090 | tar -xf -
rozdzielczości 720+
2
@memnoch_proxy: To dobra sugestia (którą głosowałem), ale w dzisiejszych czasach, gdy NSA nawet wykorzystuje prywatne linie danych między centrami danych (np. Google i Yahoo) za pomocą szyfrowania, IMO, zawsze jest dobrym nawykiem . Używanie sshsprawia, że ​​to proste. Korzystanie stunnel, socatlub opensslteż działa, ale są one bardziej skomplikowane, aby skonfigurować dla prostych transferów.
bahamat
1
@bahamat dziękuję za ponowne spojrzenie na pytanie. Moja sugestia wydaje się właściwa tylko wtedy, gdy transfer może nastąpić przez VPN. Do transferu internetowego z pewnością użyłbym również ssh.
memnoch_proxy
8

Wspominasz o „rsync”, więc zakładam, że używasz Linuksa:

Dlaczego nie tworzysz pliku tar lub tar.gz? Czas transferu sieciowego jednego dużego pliku jest szybszy niż wielu małych. Możesz go nawet skompresować, jeśli chcesz ...

Smoła bez kompresji:

Na serwerze źródłowym:

tar -cf file.tar /path/to/files/

Następnie na końcu odbierającym:

cd /path/to/files/
tar -xf /path/to/file.tar

Smoła z kompresją:

Na serwerze źródłowym:

tar -czf file.tar.gz /path/to/files/

Następnie na końcu odbierającym:

cd /path/to/files/
tar -xzf /path/to/file.tar.gz

Po prostu użyłbyś rsync do faktycznego przesłania plików (tar | tar.gz).

Soviero
źródło
tylko jeśli było dostępne miejsce do przechowywania archiwum.
Tebe
5

Można spróbować tari sshtrik opisany tutaj :

tar cvzf - /wwwdata | ssh [email protected] "dd of=/backup/wwwdata.tar.gz"

powinno to być możliwe do ponownego zapisu do następujących czynności :

tar cvzf - /wwwdata | ssh [email protected] "tar xvf -"

Jednak stracisz --partialcechy rsynctego procesu. Jeśli pliki nie zmieniają się bardzo często, warto zainwestować w powolny inicjał rsync, ponieważ w przyszłości będzie on działać znacznie szybciej.

królikarnia
źródło
2

Możesz użyć różnych opcji kompresji rsync.

-z, --compress              compress file data during the transfer
     --compress-level=NUM    explicitly set compression level
     --skip-compress=LIST    skip compressing files with suffix in LIST

współczynnik kompresji plików binarnych jest bardzo niski, więc można je pomijać przy użyciu opcji --skip-compress np. iso, już zarchiwizowanych i skompresowanych plików archiwalnych itp.

Sachin Divekar
źródło
-6

Jestem wielkim fanem SFTP. Używam SFTP do przesyłania multimediów z mojego głównego komputera na mój serwer. Dostaję dobre prędkości przez LAN.

SFTP jest niezawodny, dałbym temu szansę, ponieważ jest łatwy w konfiguracji, aw niektórych przypadkach może być szybszy.

Tillman32
źródło
5
FTP musi umrzeć. Jest niezaszyfrowany, nie radzi sobie dobrze z zakłóceniami, a istnieje co najmniej pół tuzina realnych alternatyw, które nie są do końca ssące.
MDMarra,
1
Słyszałeś kiedyś o SFTP?
Tillman32,
8
Tak masz Nie jest w żaden sposób związany z protokołem FTP w niczym innym, jak nazwą i faktem, że przenosi pliki.
MDMarra,
5
FTP jest również niewiarygodnie niewiarygodny podczas przechodzenia przez zapory ogniowe (datuje się to od czasu przed zaporami ogniowymi, gdy klient otwiera losowy port, aby zaakceptować połączenia zwrotne, było fajne, a hackery pasywnego i rozszerzonego pasywnego FTP do obejścia tego ograniczenia jest po prostu takie: Hackery)
voretaq7