Odwrotne multipleksowanie w celu przyspieszenia transferu plików

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.

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:[email protected]/directory" 

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

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://[email protected]/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

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>).

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.

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.

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 &

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ć.

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 :)

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.

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 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 [email protected] 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 .