Odwrotne multipleksowanie w celu przyspieszenia transferu plików


19

Wysłałem dużą ilość danych z jednej maszyny na drugą. Jeśli wyślę z rsync (lub inną metodą), będzie on działał ze stałą prędkością 320 kb / s. Jeśli zainicjuję dwa lub trzy transfery naraz, każdy przejdzie w 320, a jeśli zrobię cztery naraz, maksymalnie wykorzystają link.

Muszę być w stanie wysyłać dane tak szybko, jak to możliwe, więc potrzebuję narzędzia, które może wykonywać odwrotne multipleksowanie z przesyłaniem plików. Potrzebuję ogólnego rozwiązania, więc uruchamianie podziału na maszynie źródłowej i łączenie ich na drugim końcu nie jest praktyczne. Potrzebuję tego do działania w sposób zautomatyzowany.

Czy istnieje narzędzie, które to robi, czy też muszę tworzyć własne? Nadawcą jest CentOS, odbiorcą jest FreeBSD.

Odpowiedzi:


29

Dowód, że wszystko się sumuje - przedstawiam „świętego Graala” zdalnych poleceń lustrzanych. Dzięki davr za lftpsugestię.

lftp -c "mirror --use-pget-n=10 --verbose sftp://username:password@server.com/directory" 

Powyższe będzie rekurencyjnie odzwierciedlało zdalny katalog, dzieląc każdy plik na 10 wątków podczas przesyłania!


lftpjest świetne, ale nie jestem w stanie zmusić go do zrobienia wieloczęściowego podczas pobierania. Używam mirror --use-pget-n=20 -R- ale wygląda na to, że --use-pget-ndziała tylko podczas pobierania.
Dan

PS, -P20działa, aby przesłać wiele plików, ale nie mogę podzielić wielu plików na części.
Dan

1
lftp nie obsługuje przesyłania segmentowanego / wieloczęściowego. Aby rozpocząć, musisz zainicjować transfer ze strony docelowej pget -n.
apraetor,

Pamiętaj, mirrorjest dwukierunkowy; pgetargument dotyczy tylko pliki są pobierane.
apraetor,

10

Istnieje kilka narzędzi, które mogą działać.

  • LFTP - obsługuje FTP, HTTP i SFTP. Obsługuje wiele połączeń do pobrania jednego pliku. Zakładając, że chcesz przenieść plik z remoteServer do localServer, zainstaluj LFTP na localServer i uruchom:

    lftp -e 'pget -n 4 sftp://userName@remoteServer.com/some/dir/file.ext'

    „-N 4” to liczba połączeń używanych równolegle.

  • Istnieje wiele narzędzi przyspieszających pobieranie, ale ogólnie obsługują one tylko HTTP lub FTP, których nie trzeba konfigurować na zdalnym serwerze. Niektóre przykłady to Axel , aria2 i ProZilla


8

Jeśli używasz kilku i dużych plików lftp -e 'mirror --parallel=2 --use-pget-n=10 <remote_dir> <local_dir>' <ftp_server>: pobierzesz 2 pliki z każdym plikiem podzielonym na 10 segmentów, z łącznymi połączeniami 20 ftp do <ftp_server>;

Jeśli masz dużą liczbę małych plików, użyj lftp -e 'mirror --parallel=100 <remote_dir> <local_dir>' <ftp_server>: pobierzesz 100 plików równolegle bez segmentacji. Łącznie zostanie otwartych 100 połączeń. Może to spowodować wyrzucenie dostępnych klientów na serwerze lub zablokowanie niektórych serwerów.

Możesz użyć, --continueaby wznowić zadanie :) i -Ropcję przesyłania zamiast pobierania (następnie przełączanie kolejności argumentów na <local_dir> <remote_dir>).


1
literówka w parametrze: --use-pget-n zamiast --use-pget-m. Próbowałem edytować, ale moja edycja była krótka.
Tony

2

Być może będziesz w stanie dostosować ustawienia TCP, aby uniknąć tego problemu, w zależności od tego, co powoduje limit 320KB / s na połączenie. Domyślam się, że nie jest to wyraźne ograniczenie szybkości połączenia przez ISP. Istnieją dwa prawdopodobne czynniki odpowiedzialne za dławienie:

  1. Niektóre połączenia między tymi dwoma maszynami są nasycone i upuszczają pakiety.
  2. Okna TCP są nasycone, ponieważ iloczyn opóźnienia pasma jest zbyt duży.

W pierwszym przypadku każde połączenie TCP skutecznie konkurowałoby na równi w standardowej kontroli przeciążenia TCP. Można to również poprawić, zmieniając algorytmy kontroli przeciążenia lub zmniejszając wielkość wycofania.

W drugim przypadku utrata pakietów nie jest ograniczona. Dodanie dodatkowych połączeń jest prostym sposobem na zwiększenie całkowitego rozmiaru okna. Jeśli możesz ręcznie zwiększyć rozmiary okien, problem zniknie. (Może to wymagać skalowania okna TCP, jeśli opóźnienie połączenia jest wystarczająco duże).

Możesz powiedzieć w przybliżeniu, jak duże powinno być okno, mnożąc czas pingowania w obie strony przez całkowitą prędkość połączenia. 1280KB / s potrzebuje 1280 (1311 dla 1024 = 1K) bajtów na milisekundę w obie strony. Bufor 64K zostanie maksymalny przy opóźnieniu około 50 ms, co jest dość typowe. Bufor 16 K nasycałby wówczas około 320 KB / s.


1

Jaka jest struktura twoich danych? Kilka dużych plików? Kilka dużych katalogów? Możesz odradzać wiele instancji rsync w określonych gałęziach drzewa katalogów.

Wszystko zależy od struktury danych źródłowych. Istnieje mnóstwo narzędzi uniksowych do krojenia, kostkowania i ponownego składania plików.


Dane arbitralne. Czasami jest to duży katalog, a czasem pojedynczy plik.
ZimmyDubZongyZongDubby

1

Jeśli możesz skonfigurować logowanie ssh bez hasła, spowoduje to otwarcie 4 równoczesnych połączeń scp (-n) z każdym połączeniem obsługującym 4 pliki (-L):

odnaleźć . -typ f | xargs -L 4 -n 4 /tmp/scp.sh użytkownik @ host: ścieżka

Plik /tmp/scp.sh:

#!/bin/bash

#Display the help page
function showHelp()
{
    echo "Usage: $0 <destination> <file1 [file2 ... ]>"
}

#No arguments?
if [ -z "$1" ] || [ -z "$2" ]; then
    showHelp
    exit 1
fi

#Display help?
if [ "$1" = "--help" ] || [ "$1" = "-h" ]; then
    showHelp
    exit 0
fi

#Programs and options
SCP='scp'
SCP_OPTS='-B'
DESTINATION="$1";shift;

#Check other parameters
if [ -z "$DESTINATION" ]; then
    showHelp
    exit 1
fi

echo "$@"

#Run scp in the background with the remaining parameters.
$SCP $SCP_OPTS $@ $DESTINATION &

0

Spróbuj posortować wszystkie pliki na i-węzle (find / mydir -type f -print | xargs ls -i | sort -n) i przenieś je np. Cpio przez ssh. Spowoduje to maksymalne wykorzystanie dysku i spowoduje wąskie gardło w sieci. Szybciej niż to, że trudno przejść, gdy przechodzisz przez sieć.


to wręcz podstępne :)
warren

Nie mogę zagwarantować, że wszystkie systemy plików skorzystają na tym, zależy to od sposobu rozmieszczenia i-węzłów.
Jimmy Hedman

Wąskie gardło polega na tym, że każde połączenie TCP jest ograniczone do 320 KB / s. Chcę wysyłać pliki w równoległych połączeniach TCP, aby uzyskać 320 * NumConnection do limitu sieci (około 1200 KB / s). Sortowanie według i-węzła nie osiąga tego.
ZimmyDubZongyZongDubby

Co ogranicza prędkość TCP? Router między maszynami?
Jimmy Hedman,

Mój dostawca usług internetowych. Neutralność sieci? HA!
ZimmyDubZongyZongDubby

0

Znam narzędzie, które może przesyłać pliki w porcjach. Narzędzie nazywa się pakietem / portem „rtorrent”, który jest dostępny na obu hostach;) Klienci BitTorrent często rezerwują miejsce na dysku przed transferem, a fragmenty są zapisywane bezpośrednio z gniazd na dysk. Dodatkowo będziesz mógł przeglądać stany WSZYSTKICH przelewów na ładnym ekranie ncurses.

Możesz tworzyć proste skrypty bash, aby zautomatyzować tworzenie pliku „* .torrent” i ssh polecenie do zdalnego komputera, aby go pobrać. Wygląda to trochę brzydko, ale nie sądzę, że znajdziesz jakieś proste rozwiązanie bez rozwijania :)


1
Jeśli w przesyłaniu plików biorą udział tylko dwa komputery, jak torrent może pomóc? Idea torrenta to rój seederów udostępniających dane klientowi żądającemu.
DaveParillo,

Masz rację. Ale kto powiedział, że to nie jest przydatne w przypadku jednego siewnika? ;)
kolypto

2
Jeśli klient torrenta tworzy wiele połączeń TCP za pomocą jednego peera, rozwiązałoby to problem OP. Nie wiem jednak, czy klienci torrenta naprawdę tworzą wiele połączeń TCP z pojedynczymi jednostkami równorzędnymi.
chronos z

0

FTP pobiera wiele połączeń. Jeśli możesz skonfigurować bezpieczny kanał dla FTP przez VPN lub FTP przez SSH , powinieneś być w stanie zmaksymalizować swoje łącze sieciowe. (Należy pamiętać, że specjalne wymagania są wymagane w przypadku FTP przez SSH - patrz link).

FTPS (FTP przez SSL) może również zrobić to, czego potrzebujesz.

Możesz także użyć klienta SFTP, który obsługuje wiele połączeń, ale nie jestem pewien, czy SFTP obsługuje wiele połączeń dla jednego pliku. Powinno to robić to, czego potrzebujesz przez większość czasu, ale może nie zapewnić maksymalnej przepustowości, gdy musisz przesłać tylko jeden duży plik.


Czy SFTP nie byłby o wiele łatwiejszy i równie bezpieczny (jeśli nie bardziej) bezpieczny?
Mark Renouf

1
@rob: skąd masz, że „FTP używa wielu połączeń do przesyłania plików”? Niektórzy klienci pozwalają zrobić wiele strumieni do pobrania z serwera FTP, ale nie jest z pewnością nie kombi klient FTP / serwer pozwala wielu strumieni dla przesyłania do FTP.
chronos z

@ Mark: Tak, SFTP byłby prawdopodobnie łatwiejszy i równie bezpieczny, ale nie wiem, czy obsługuje wiele połączeń do przesyłania pojedynczego pliku. Dziękuję za sugestię; Dodam to do listy.
rob

1
@chronos: Przepraszamy, nie było jasne; Sugerowałem, że ZimmyDubZongyZongDubby używa FTP do pobierania z serwera CentOS do klienta FreeBSD. Zaktualizowałem odpowiedź, aby powiedzieć „pobieranie” zamiast „transfer plików”.
rob

-1

Rozwiązanie 1: Nie jestem pewien, czy jest to praktyczne w twoim przypadku, ale możesz utworzyć archiwum łączone (na przykład plik tar podzielony na porcje lub archiwum łączone 7zip), a następnie użyć wielu instancji rsync, aby wysłać je dalej sieć i zmontuj / wyodrębnij je po drugiej stronie. Możesz napisać skrypt ogólnego przeznaczenia, którego argumentami są katalog do przesłania i liczba połączeń do użycia. Oczywistym minusem jest to, że będziesz potrzebował dwa razy więcej wolnego miejsca po obu stronach i będzie miał dodatkowy koszt archiwizacji / rozpakowywania plików na obu końcach.

Rozwiązanie 2: lepszym rozwiązaniem byłoby napisanie skryptu lub programu, który dzieli duże drzewo katalogów na poddrzewa na podstawie wielkości, a następnie skopiowanie tych poddrzewa równolegle. Może to uprościć, jeśli najpierw skopiujesz całą strukturę katalogów (bez plików).


Czy ktoś ma ochotę rozwinąć tę opinię?
rob

-1

Czy dwie maszyny działają w zaufanym środowisku? Możesz spróbować netcat . Po stronie serwera:

tar -czf - ./yourdir | nc -l 9999

a na kliencie:

nc your.server.net 9999 > yourdir.tar.gz

Możesz poprosić klienta o połączenie z tunelem ssh:

ssh -f -L 23333:127.0.0.1:9999 foo@your.server.net sleep 10; \
    nc 127.0.0.1 23333 > yourdir.tar.gz

W ten sposób można przenieść nawet całą partycję:

dd if=/dev/sda1 | gzip -9 | nc -l 9999

a na kliencie:

nc your.server.net 9999 > mysda1.img.gz

.

Uwaga

Netcat nie jest najbezpieczniejszym narzędziem transferu, ale w odpowiednim środowisku może być szybki, ponieważ ma tak niski narzut.

HowtoForge ma dobrą stronę przykładów .


To wydaje się być ogólną odpowiedzią, która nie odpowiada na jego pytanie. O ile wiem, nie widzę, jak którekolwiek z twoich rozwiązań byłoby przesyłane równolegle, nc to tylko jedno połączenie
davr

Możesz mieć rację, jednak używając nc masz kontrolę nad otwartymi portami. Możesz podać 10 000, jeśli masz na to ochotę.
DaveParillo,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.