Frage Was ist der beste Weg, um eine einzelne große Datei über eine WAN-Verbindung mit hoher Geschwindigkeit und hoher Latenz zu übertragen?


Das sieht ähnlich aus diesesaber es ist etwas anders.

Es gibt diese WAN-Verbindung zwischen zwei Firmenstandorten, und wir müssen eine einzelne sehr große Datei übertragen (Oracle Dump, ~ 160 GB).

Wir haben volle 100 Mbps Bandbreite (getestet), aber es sieht so aus, als ob eine einzelne TCP-Verbindung es aufgrund der Funktionsweise von TCP (ACKs, etc.) nicht ausschöpfen kann. Wir haben die Verbindung mit getestet iperfund die Ergebnisse ändern sich dramatisch, wenn die TCP-Fenstergröße erhöht wird: Mit den Grundeinstellungen erreichen wir einen Durchsatz von ~ 5 MBit / s, mit einem größeren WS können wir bis zu 45 MBit / s erreichen, aber nicht mehr. Die Netzwerklatenz beträgt ca. 10 ms.

Aus Neugierde haben wir iperf mit mehr als einer einzigen Verbindung betrieben, und wir haben festgestellt, dass bei vier von ihnen tatsächlich eine Geschwindigkeit von ~ 25 Mbit / s erreicht wird, wodurch die gesamte verfügbare Bandbreite aufgefüllt wird; Der Schlüssel sieht also aus, mehrere simultane Übertragungen auszuführen.

Mit FTP wird es noch schlimmer: Selbst mit optimierten TCP-Einstellungen (hohe Fenstergröße, maximale MTU, etc.) können wir nicht mehr als 20 Mbit / s bei einer einzigen Übertragung erreichen. Wir haben versucht, einige große Dateien gleichzeitig zu übertragen, und die Dinge wurden tatsächlich viel besser als bei der Übertragung eines einzigen; Aber dann wurde der Täter zum Platten-I / O, weil sehr schnell vier große Dateien aus demselben Platten-Engpass gelesen und geschrieben wurden; Außerdem scheinen wir nicht in der Lage zu sein, diese einzelne große Datei in kleinere aufzuteilen und sie dann wieder zusammenzuführen, zumindest nicht in akzeptablen Zeiten (offensichtlich können wir das Spleißen / Zusammenführen der Datei nicht mit einer Zeit vergleichbar der von übertragen es).

Die ideale Lösung wäre hier ein Multithread-Tool, das verschiedene Teile der Datei gleichzeitig übertragen kann. so wie es Peer-to-Peer-Programme wie eMule oder BitTorrent bereits tun, aber von einer einzigen Quelle zu einem einzigen Ziel. Idealerweise würde das Tool es uns ermöglichen, zu wählen, wie viele parallele Verbindungen zu verwenden sind, und natürlich die Platten-E / A optimieren, um nicht (verrückt) zwischen verschiedenen Abschnitten der Datei zu springen.

Kennt jemand solch ein Werkzeug?

Oder kann jemand eine bessere Lösung vorschlagen und / oder etwas, das wir nicht schon versucht haben?

P.S. Wir haben bereits darüber nachgedacht, dies auf Band / Disk zu sichern und es physisch an das Ziel zu senden; das wäre unsere extreme Maßnahme, wenn das WAN es nicht einfach schneidet, aber als A.S. Tanenbaum sagte: "Unterschätzen Sie niemals die Bandbreite eines Wagens voller Bänder, die über die Autobahn rasen."


21
2018-02-11 07:19


Ursprung


Aus Neugier, ist die Zeit wirklich so kritisch? Würden Sie den Link für die Dauer einer 160-GB-Übertragung auch nicht auf den Rest Ihres Netzwerks auswirken? - Bryan
Ich erinnere mich daran, 1999 einige DLT-Autoloader und ein paar hundert Patronen an einen Kunden ausgeliefert zu haben. Wir berechneten die Rohkapazität meines Autos mit etwa 200 DLT IV-Patronen, die darin geladen waren (jeweils 35 GB Rohkapazität) bei etwa 6,3 TB. Ich fuhr in ungefähr 55 Minuten von unserem Büro zum Kunden, um dem Backup-Transportmechanismus "Evan in einer Geo Metro, der wie verrückt fährt" einen effektiven Durchsatz von etwa 118 GB / min zu geben. Guter Durchsatz, aber die Latenz war ein Mörder ...> lächeln < - Evan Anderson
Bryan: Ja, die Zeit ist kritisch (es dauert etwa zwanzig Stunden mit Standard-FTP und Standard-Netzwerk-Einstellungen), und nein, es wird kein Problem bei der Sättigung der Verbindung sein, weil die Übertragung außerhalb der Arbeitszeit geplant wird. - Massimo
Evan: genau das meinte ich ;-) - Massimo
Ich habe mich mit einer ähnlichen Situation mit ~ 200 GB SQL .bak beschäftigt, außer dass ich nur die Möglichkeit hatte, die WAN-Verbindung zu sättigen, mit FTP. Am Ende habe ich 7-Zip mit Null-Komprimierung verwendet, um es in 512-MB-Chunks zu zerlegen. "Kompressions-" und "Dekompressions" -Zeiten waren angenehm kurz; Alles in allem viel besser, als physische Medien quer durch das Land zu schaufeln. (Die Seiten befinden sich an gegenüberliegenden Küsten der USA) - Adrien


Antworten:


Die Suche nach "high latency file transfer" bringt viele interessante Treffer. Offensichtlich ist dies ein Problem, in das sowohl die CompSci-Gemeinschaft als auch die kommerzielle Gemeinschaft eingegriffen hat.

Einige kommerzielle Angebote, die der Rechnung entsprechen:

  • Dateikatalysator hat Produkte, die Daten über Netzwerke mit hoher Latenz entweder mit UDP oder mehreren TCP-Streams streamen können. Sie haben auch viele andere Funktionen (On-The-Fly-Komprimierung, Delta-Übertragungen, etc.).

  • Das fasp File Transfer "Technologie" von Aspera scheint auch die Rechnung für das, was Sie suchen, zu passen.

In der Open-Source-Welt, der Uftp Projekt sieht vielversprechend aus. Sie benötigen nicht unbedingt ihre Multicast-Fähigkeiten, sondern die Grundidee, eine Datei an Empfänger zu senden, NAKs für verpasste Blöcke am Ende der Übertragung zu empfangen und dann die NAK-Blöcke zu sprengen (schäumen, spülen, wiederholen). klingt, als ob es tun würde, was Sie brauchen, da es kein ACK'ing (oder NAK'ing) vom Empfänger gibt, bis die Dateiübertragung einmal abgeschlossen ist. Angenommen, das Netzwerk ist nur latent und nicht verlustbehaftet, könnte es auch das tun, was Sie brauchen.


15
2018-02-11 08:01



uftp sieht wirklich vielversprechend aus, ich konnte 30 Mbps zwischen zwei Desktop-Computern erreichen (die bei der Festplattenleistung definitiv nicht so gut sind); Ich werde es bald auf den "echten" Servern testen. Ich war nicht in der Lage, eine FileCatalyst Demolizenz zu bekommen, wegen eines Fehlers im Registrierungsformular (es wird immer behauptet, dass die Anfrage Nummer bereits benutzt wurde), und fasp bietet sie einfach nicht an. - Massimo
60 Mbps zwischen zwei Computern mit geeigneten Festplatten und einem großen Empfangspuffer. Großartig! - Massimo
Ich liebe freie / Open-Source-Software! > smile <Ich werde definitiv einen Versuch mit einigen Sachen machen, die ich mache. Ich frage mich, wie es in einer Linux-basierten Multicast-Disk-Imaging-Lösung funktionieren würde, die ich vor ein paar Jahren mit "udpcast" zusammenstellte. - Evan Anderson
Vor einer Weile fragte ich serverfault.com/questions/173358/multicast-file-transfers Schließlich kam ich zu dem Schluss, dass UFTP und MRSCNY die Mittel der Wahl sind. Bitte posten Sie in den Kommentaren da drüben, wenn Sie etwas Nützliches mit Uftp machen, da ich dieses Jahr wieder das eine oder andere verwenden werde (Vorbereitung für eine Konferenz). - Jed Daniels
Als ich mit UFTP, UDT und Tsunami UDP arbeitete, hatte UFTP die schlechteste Leistung aller drei. Natürlich ist es wahrscheinlich das ausgereifteste Protokoll. UDT bietet nur ein einfaches Übertragungsprotokoll und wurde entwickelt, um als eine Bibliothek zu dienen, um kundenspezifische Software zu entwickeln und der Autor von Tsunami hat uns tatsächlich auf UDT hingewiesen, da Tsunami in letzter Zeit aus Zeitmangel nicht aktiv entwickelt wurde. - Thomas Owens


Wirklich merkwürdiger Vorschlag dieses .. Richten Sie einen einfachen Webserver ein, um die Datei in Ihrem Netzwerk zu hosten (ich schlage nebenbei nginx vor), dann richten Sie am anderen Ende einen PC mit Firefox ein und installieren Sie die DownThemAll Erweiterung.

Es ist ein Download-Beschleuniger, der Chunking und Re-Assembly unterstützt.
Sie können jeden Download in 10 Stücke zerlegen, um ihn wieder zusammenzusetzen, und er macht die Dinge tatsächlich schneller!

(Vorbehalt: Ich habe es noch nie in einem so großen Format wie 160 GB probiert, aber es funktioniert gut mit ISO-Dateien mit 20 GB)


9
2018-02-11 08:23



40 Mbps zwischen den gleichen Computern. Sieht auch wirklich gut aus. - Massimo
Ersetze Firefox mit axel.alioth.debian.org und es ist nicht so schlecht von einem Vorschlag. - Justin


Das UDT Transport ist wahrscheinlich der beliebteste Transport für Kommunikation mit hoher Latenzzeit. Dies führt auf ihre andere Software namens Sektor / Kugel ein "High Performance Distributed File System und Parallel Data Processing Engine", das sich sehen lassen könnte.


7
2018-03-18 03:21



Ich arbeitete mit UDT für Übertragungen über Netzwerke mit hoher Latenz und hohem Paketverlust. UDT ist viel widerstandsfähiger gegenüber Latenz und Paketverlust als TCP-basierte Protokolle, insbesondere wenn Sie den Stausteuerungsalgorithmus ändern, um ihn an Ihre Netzwerktopographie anzupassen. - Thomas Owens
Es gibt sogar eine Version von rsync mit UDT, es heißt "UDR". github.com/LabAdvComp/UDR - Max


Meine Antwort ist ein bisschen spät, aber ich habe gerade diese Frage gefunden, während ich nach fasp suche. Während dieser Suche habe ich auch folgendes gefunden: http://tsunami-udp.sourceforge.net/ , das "Tsunami UDP Protocol".

Von ihrer Website:

Eine schnelle Benutzer-Space-Dateiübertragung   Protokoll, das TCP-Steuerung und UDP verwendet   Daten für die Übertragung über sehr hohe Geschwindigkeit   Fernnetze (≥ 1 Gbps und   sogar 10 GE), entworfen, um mehr zu bieten   Durchsatz als möglich mit TCP über   die gleichen Netzwerke. Die gleichen Netzwerke.

Was die Geschwindigkeit betrifft, erwähnt die Seite dieses Ergebnis (über eine Verbindung zwischen Helsinki, Finnland, Bonn und Deutschland über eine 1GBit-Verbindung:

Abbildung 1 - internationale Übertragung über das Internet mit durchschnittlich 800 Mbit / Sekunde

Wenn Sie einen Download-Beschleuniger verwenden möchten, werfen Sie einen Blick auf lftp, dies ist der einzige Download-Beschleuniger, der eine rekursive Spiegelung ausführen kann, soweit ich weiß.


5
2018-06-24 20:59



In dem Projekt, das ich bereits in Steve-o's Antwort erwähnt habe, haben wir UDT, Tsunami UDP und UFTP benchmarked. Wir fanden heraus, dass die Latenz einen großen Einfluss auf die Performance hatte, während der Paketverlust (im Gegensatz zur Tsunami-Dokumentation) nicht zutraf. Das Hinzufügen von 100ms Latenz zum Testnetzwerk ließ die Leistung von Tsunami von ungefähr 250 Mbits / Sekunde auf ungefähr 50 Mbits / Sekunde sinken (ich glaube, dass ich meine Zahlen und Einheiten richtig habe - es ist eine Weile her, aber es war ein riesiger Abfall). Hinzufügen von 10% Paketverlust kein Netzwerk mit minimaler Latenzzeit, andererseits verringerte sich die Leistung nur von 250 Mbits / Sekunde auf ungefähr 90 Mbits / Sekunde. - Thomas Owens


Das bbcp Dienstprogramm von der sehr relevanten Seite "Wie große Datenmengen über das Netzwerk übertragen werden" scheint die einfachste Lösung zu sein.


4
2018-06-27 12:23



Ich denke nicht, dass bbcp für hohe Latenz optimiert ist. Ich bekomme ~ 20 MB / Sek über einen transatlantischen Link im Moment mit den Standardeinstellungen. - Max