Jaki jest najlepszy sposób na przesłanie pojedynczego dużego pliku za pomocą szybkiego łącza WAN o dużym opóźnieniu?

21

Wygląda na związany z tym , ale jest nieco inny.

Istnieje łącze WAN między dwiema witrynami firmy i musimy przenieść pojedynczy bardzo duży plik (zrzut Oracle, ~ 160 GB).

Mamy pełną przepustowość 100 Mb / s (przetestowane), ale wygląda na to, że pojedyncze połączenie TCP po prostu nie może tego zwiększyć ze względu na to, jak działa TCP (ACK itp.). Przetestowaliśmy łącze z iperf , a wyniki zmieniają się dramatycznie podczas zwiększania rozmiaru okna TCP: przy ustawieniach podstawowych uzyskujemy przepustowość ~ 5 Mb / s, przy większym WS możemy uzyskać do ~ 45 Mb / s, ale nie więcej. Opóźnienie sieci wynosi około 10 ms.

Z ciekawości uruchomiliśmy iperf, używając więcej niż jednego połączenia, i stwierdziliśmy, że kiedy uruchomimy cztery z nich, rzeczywiście osiągną prędkość ~ 25 Mb / s, wypełniając całą dostępną przepustowość; więc kluczem jest uruchomienie wielu jednoczesnych przelewów.

W przypadku FTP sytuacja się pogarsza: nawet przy zoptymalizowanych ustawieniach TCP (wysoki rozmiar okna, maks. MTU itp.) Nie możemy uzyskać więcej niż 20 Mb / s na jednym transferze. Próbowaliśmy jednocześnie przesłać trochę dużych plików na serwer FTP i rzeczywiście stało się o wiele lepiej niż przy przesyłaniu jednego; ale potem sprawca stał się dyskowym We / Wy, ponieważ bardzo szybko odczytuje i zapisuje cztery duże pliki z tych samych wąskich gardeł dysku; ponadto nie wydaje się, abyśmy mogli podzielić ten pojedynczy duży plik na mniejsze, a następnie scalić go z powrotem, przynajmniej w nieodpowiednich czasach (oczywiście nie możemy spędzić na składaniu / scalaniu pliku w czasie porównywalnym z czasem przenoszenie).

Idealnym rozwiązaniem byłoby tu narzędzie wielowątkowe, które mogłoby przenosić różne fragmenty pliku w tym samym czasie; coś w rodzaju programów typu peer-to-peer, takich jak eMule lub BitTorrent, ale już z jednego źródła do jednego miejsca docelowego. Idealnie, narzędzie to pozwoliłoby nam wybrać liczbę równoległych połączeń do użycia i oczywiście zoptymalizować dyskowe operacje wejścia / wyjścia, aby nie przeskakiwały (zbyt) szalenie między różnymi sekcjami pliku.

Czy ktoś wie o takim narzędziu?

A może ktoś może zaproponować lepsze rozwiązanie i / lub coś, czego jeszcze nie próbowaliśmy?

PS Już myśleliśmy o utworzeniu kopii zapasowej na taśmie / dysku i fizycznym wysłaniu jej do miejsca docelowego; byłby to nasz ekstremalny środek, gdyby WAN po prostu tego nie przerwał, ale, jak powiedział AS Tanenbaum: „Nigdy nie lekceważ przepustowości wozu kombi pełnego taśm pędzących po autostradzie”.

networking bandwidth tcp file-transfer Massimo
źródło
1
Z ciekawości, czy czas, który zajmuje naprawdę tak krytyczny? Ponadto, czy nasycenie łącza na czas transferu 160 Gb nie miałoby wpływu na resztę twojej sieci?
Bryan
6
Pamiętam, jak dostarczyłem kilka autoloaderów DLT i kilkaset nabojów do klienta w '99. Obliczyliśmy surową pojemność mojego samochodu z około 200 wkładami DLT IV załadowanymi do niego (po 35 GB każdej pojemności) na około 6,3 TB. Pojechałem z naszego biura do siedziby klienta w około 55 minut, dzięki czemu mechanizm „Evan w Geo Metro jeździ jak szalony międzystanowy” efektywną przepustowością około 118 GB / min. Dobra przepustowość, ale opóźnienie było zabójcze ...> uśmiech <
Evan Anderson
Bryan: tak, czas ma krytyczne znaczenie (zajmuje około DWÓCH GODZIN przy standardowych FTP i standardowych ustawieniach sieci) i nie, nie będzie problemu z nasyceniem łącza, ponieważ transfer zostanie zaplanowany w czasie wolnym od pracy.
Massimo
Evan: dokładnie to miałem na myśli ;-)
Massimo
Miałem do czynienia z podobną sytuacją z ~ 200 GB SQL .bak, z wyjątkiem tego, że jedynym sposobem na uzyskanie nasycenia łącza WAN jest FTP. Skończyło się na użyciu 7-zip z zerową kompresją, aby podzielić go na 512 MB. Czasy „kompresji” i „dekompresji” były dość krótkie; w sumie znacznie lepiej niż przerzucanie nośników fizycznych w całym kraju. (Witryny znajdują się na przeciwległych wybrzeżach USA)
Adrien

Odpowiedzi:

15

Wyszukiwanie „przesyłania plików z dużym opóźnieniem” przynosi wiele interesujących trafień. Jest to oczywisty problem, na który włożyli się zarówno społeczność CompSci, jak i społeczność komercyjna.

Kilka ofert komercyjnych, które wydają się pasować do rachunku:

  • FileCatalyst ma produkty, które mogą przesyłać strumieniowo dane w sieciach o dużych opóźnieniach, wykorzystując UDP lub wiele strumieni TCP. Mają też wiele innych funkcji (kompresja w locie, transfery delta itp.).

  • Fasp file transfer „technologia” z Aspera wydaje pasowały do tego, co szukasz, jak również.

W świecie open source projekt uftp wygląda obiecująco. Nie potrzebujesz szczególnie jego możliwości multiemisji, ale podstawowa idea wysyłania pliku do odbiorników, odbierania NAK za brakujące bloki pod koniec przesyłania, a następnie wysadzania bloków NAK (piana, płukanie, powtarzanie) wygląda na to, że zrobi to, czego potrzebujesz, ponieważ nie ma potwierdzenia (lub NAK'owania) z odbiornika, dopóki transfer pliku nie zostanie zakończony jeden raz. Zakładając, że sieć jest po prostu ukryta i nie jest stratna, może to zrobić również to, czego potrzebujesz.

Evan Anderson
źródło
uftp wygląda naprawdę obiecująco, udało mi się osiągnąć 30 Mb / s między dwoma komputerami stacjonarnymi (które zdecydowanie nie są tak świetne pod względem wydajności dysku); Niedługo przetestuję to na „prawdziwych” serwerach. Nie byłem w stanie uzyskać licencji demonstracyjnej FileCatalyst z powodu jakiegoś błędu w formularzu rejestracyjnym (ciągle mówi, że numer żądania został już użyty), a fasp po prostu ich nie oferuje.
Massimo,
60 Mb / s między dwoma komputerami z odpowiednimi dyskami i dużym buforem odbiorczym. Świetny!
Massimo
Uwielbiam darmowe / otwarte oprogramowanie! > uśmiech <Zdecydowanie spróbuję uftp spróbować czegoś, co robię. Zastanawiam się, jak by to wyglądało w opartym na Linuksie rozwiązaniu do multiemisji obrazowania dysków, które przygotowałem kilka lat temu za pomocą „udpcast”.
Evan Anderson
jakiś czas temu zapytałem serverfault.com/questions/173358/multicast-file-transfers W końcu doszedłem do wniosku, że uftp i mrsync to wybrane narzędzia. Proszę zamieścić tam komentarze, jeśli zrobisz coś użytecznego z uftp, ponieważ w tym roku będę używał jednego lub drugiego (przygotuj się na konferencję).
Jed Daniels,
2
Kiedy pracowałem z UFTP, UDT i Tsunami UDP, UFTP miał najgorszą wydajność spośród wszystkich trzech. Oczywiście jest to prawdopodobnie najbardziej dojrzały protokół. UDT zapewnia jedynie prosty protokół przesyłania i został zaprojektowany jako biblioteka do opracowywania niestandardowego oprogramowania, a autor Tsunami faktycznie skierował nas w stronę UDT, ponieważ Tsunami nie zostało ostatnio aktywnie rozwinięte z powodu braku czasu.
Thomas Owens,
9

To naprawdę dziwna sugestia. Skonfiguruj prosty serwer sieciowy do hostowania pliku w sieci (proponuję nginx, nawiasem mówiąc), następnie skonfiguruj komputer z firefoxem na drugim końcu i zainstaluj rozszerzenie DownThemAll .

To akcelerator pobierania, który obsługuje dzielenie i ponowne składanie.
Możesz podzielić każde pobranie na 10 części w celu ponownego złożenia, a to naprawdę przyspiesza!

(zastrzeżenie: nigdy nie próbowałem tego na tak dużych jak 160 GB, ale działa dobrze z plikami ISO 20 GB)

Tom O'Connor
źródło
40 Mbps między tymi samymi komputerami. Wygląda też naprawdę dobrze.
Massimo
1
zastąp firefoxa axel.alioth.debian.org i nie jest to takie złe sugestie.
Justin
7

UDT transport jest prawdopodobnie najbardziej popularnym transportowa na wysokich komunikacji latencji. Prowadzi to do ich innego oprogramowania o nazwie Sector / Sphere, czyli „wysokowydajnego rozproszonego systemu plików i silnika przetwarzania danych równoległych”, na które warto się przyjrzeć.

Steve-o
źródło
1
Pracowałem z UDT przy transferach w sieciach o dużym opóźnieniu i dużej utracie pakietów. UDT jest znacznie bardziej odporny na opóźnienia i utratę pakietów niż protokoły oparte na TCP, zwłaszcza gdy zaczynasz zmieniać algorytm kontroli przeciążenia, aby dopasować go do topografii sieci.
Thomas Owens
Istnieje nawet wersja rsync z wbudowanym UDT, o nazwie „UDR”. github.com/LabAdvComp/UDR
Max
5

Moja odpowiedź jest nieco spóźniona, ale właśnie znalazłem to pytanie, szukając fafa. Podczas tego wyszukiwania znalazłem również: http://tsunami-udp.sourceforge.net/ , „Protokół Tsunami UDP”.

Z ich strony internetowej:

Szybki protokół przesyłania plików w przestrzeni użytkownika, który wykorzystuje dane TCP i UDP do przesyłania danych w bardzo szybkich sieciach dalekobieżnych (≥ 1 Gb / s, a nawet 10 GE), zaprojektowany w celu zapewnienia większej przepustowości niż jest to możliwe w przypadku TCP w tych samych sieciach. sieci.

Jeśli chodzi o szybkość, strona wspomina o tym wyniku (za pomocą łącza między Helsinkami, Finlandią a Bonn, Niemcy za pomocą łącza 1 GBit:

Ryc. 1 - transfer międzynarodowy przez Internet, średnio 800 Mbit / sekundę

Jeśli chcesz użyć akceleratora pobierania, spójrz na lftp, jest to jedyny akcelerator pobierania, który może zrobić rekurencyjne lustro, o ile mi wiadomo.

Jan van Haarst
źródło
1
W projekcie, który skomentowałem wcześniej w odpowiedzi Steve-o, przeprowadziliśmy testy porównawcze UDT, Tsunami UDP i UFTP. Odkryliśmy, że opóźnienie miało ogromny wpływ na wydajność, podczas gdy utrata pakietów nie (w przeciwieństwie do dokumentacji Tsunami). Dodanie 100 ms opóźnienia do sieci testowej obniżyło wydajność Tsunami z około 250 Mb / s do około 50 Mb / s (wydaje mi się, że mam prawidłowe liczby i jednostki - minęło trochę czasu, ale to był ogromny spadek). Z drugiej strony, dodanie 10% utraty pakietów bez sieci o minimalnym opóźnieniu, tylko obniżyło wydajność z 250 Mb / s do około 90 Mb / s.
Thomas Owens,