Wie überträgt man eine einzelne große Datei am besten über eine schnelle WAN-Verbindung mit hoher Latenzzeit?


21

Das sieht im Zusammenhang dieser ein , aber es ist etwas anders.

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

Wir haben die volle Bandbreite von 100 Mbit / s (getestet), aber es sieht so aus, als ob eine einzelne TCP-Verbindung aufgrund der Funktionsweise von TCP (ACKs usw.) nicht ausreichen kann. Wir haben die Verbindung mit iperf getestet , und die Ergebnisse ändern sich dramatisch, wenn die TCP-Fenstergröße erhöht wird: Mit Basiseinstellungen erhalten 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 Neugier haben wir iperf über mehr als eine einzige Verbindung betrieben und festgestellt, dass sie bei vier Verbindungen tatsächlich eine Geschwindigkeit von jeweils ~ 25 Mbit / s erreichen und damit die gesamte verfügbare Bandbreite ausfüllen. Der Schlüssel scheint also darin zu liegen, mehrere Übertragungen gleichzeitig auszuführen.

Bei FTP wird es noch schlimmer: Selbst bei optimierten TCP-Einstellungen (hohe Fenstergröße, maximale MTU usw.) können wir mit einer einzigen Übertragung nicht mehr als 20 Mbit / s erreichen. Wir haben versucht, einige große Dateien gleichzeitig per FTP zu übertragen. Aber dann wurde der Täter zu Platten-E / A, weil er sehr bald vier große Dateien mit denselben Plattenengpässen liest und schreibt. Außerdem scheinen wir nicht in der Lage zu sein, diese einzelne große Datei in kleinere zu teilen und sie dann wieder zusammenzuführen, zumindest nicht in akzeptablen Zeiten (offensichtlich können wir das Zusammenfügen / Zusammenführen der Datei nicht in einer Zeit aufwenden, die mit der von vergleichbar ist übertragen).

Die ideale Lösung wäre hier ein Multithread-Tool, mit dem verschiedene Teile der Datei gleichzeitig übertragen werden können. Ähnlich wie bei Peer-to-Peer-Programmen wie eMule oder BitTorrent, jedoch von einer einzelnen Quelle zu einem einzelnen Ziel. Im Idealfall können wir mit dem Tool auswählen, wie viele parallele Verbindungen verwendet werden sollen, und natürlich die Datenträger-E / A optimieren, um nicht (zu) verrückt zwischen verschiedenen Abschnitten der Datei zu springen.

Kennt jemand ein solches Tool?

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

PS: Wir haben bereits darüber nachgedacht, diese Daten auf Band / Festplatte zu sichern und sie physisch an das Ziel zu senden. Das wäre unser extremes Maß, wenn WAN es einfach nicht schafft, aber wie AS Tanenbaum sagte: "Unterschätzen Sie niemals die Bandbreite eines Kombis voller Bänder, die die Autobahn entlang rasen."


1
Ist die Zeit, die aus Neugier benötigt wird, wirklich so kritisch? Würde sich eine Sättigung der Verbindung für die Dauer einer 160-Gbit-Übertragung nicht auf den Rest Ihres Netzwerks auswirken?
Bryan

6
Ich erinnere mich, dass ich einem Kunden im Jahr 1999 einige DLT-Autoloader und ein paar hundert Patronen geliefert habe. Wir haben die Rohkapazität meines Autos mit ca. 200 darin geladenen DLT IV-Patronen (je 35 GB Rohkapazität) auf ca. 6,3 TB berechnet. Ich fuhr in ungefähr 55 Minuten von unserem Büro zum Kundenstandort, was dem "Evan in einer Geo-Metro, der wie verrückt die Interstate runterfährt", einen effektiven Durchsatz von ungefähr 118 GB / min bescherte. Guter Durchsatz, aber die Latenz war ein Killer ...> smile <
Evan Anderson

Bryan: Ja, die Zeit ist kritisch (es dauert ungefähr 20 Stunden mit Standard-FTP- und Standard-Netzwerkeinstellungen), und nein, es wird kein Problem bei der Sättigung der Verbindung geben, da die Übertragung außerhalb der Arbeitszeit geplant wird.
Massimo

Evan: Genau das habe ich gemeint ;-)
Massimo

Ich habe mit einer ähnlichen Situation zu tun gehabt, mit ~ 200 GB SQL .bak, mit der Ausnahme, dass die einzige Möglichkeit, die WAN-Verbindung zum Sättigen zu bringen, FTP ist. Am Ende habe ich 7-zip ohne Komprimierung verwendet, um es in 512-MB-Blöcke aufzuteilen. "Komprimierungs" - und "Dekomprimierungs" -Zeiten waren angenehm kurz; Alles in allem viel besser als physische Medien im ganzen Land zu schaufeln. (Die Standorte befinden sich an gegenüberliegenden Küsten der USA)
Adrien

Antworten:


15

Die Suche nach "Dateitransfer mit hoher Latenz" bringt viele interessante Treffer. Dies ist eindeutig ein Problem, mit dem sich sowohl die CompSci-Community als auch die kommerzielle Community befasst haben.

Einige kommerzielle Angebote, die in die Rechnung passen:

  • FileCatalyst bietet Produkte, die Daten über Netzwerke mit hoher Latenz streamen können, entweder mit UDP oder mit mehreren TCP-Streams. Sie haben auch viele andere Funktionen (schnelle Komprimierung, Delta-Übertragungen usw.).

  • Die " FASP- Technologie" für den Dateitransfer von Aspera scheint genau das zu sein, wonach Sie suchen.

In der Open-Source-Welt sieht das uftp- Projekt vielversprechend aus. Sie brauchen nicht besonders die Multicast-Funktionen, 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 senden (aufschäumen, ausspülen, wiederholen). klingt so, als würde es tun, was Sie brauchen, da der Empfänger erst nach Abschluss der Dateiübertragung ACK'ing (oder NAK'ing) ausführt. Vorausgesetzt, das Netzwerk ist nur latent und nicht verlustbehaftet, kann dies auch das tun, was Sie benötigen.


uftp sieht wirklich vielversprechend aus, ich konnte 30 Mbit / s zwischen zwei Desktop-Computern erzielen (die bei der Festplattenleistung definitiv nicht so gut sind). Ich werde es bald auf den "echten" Servern testen. Ich konnte aufgrund eines Fehlers im Registrierungsformular keine FileCatalyst-Demo-Lizenz erhalten (es wird immer wieder darauf hingewiesen, dass die Anforderungsnummer bereits verwendet wurde), und fasp bietet sie einfach nicht an.
Massimo

60 Mbit / s zwischen zwei Computern mit geeigneten Festplatten und großem Empfangspuffer. Groß!
Massimo

Ich liebe freie / Open Source Software! > smile <Ich werde es auf jeden Fall mit ein paar Sachen versuchen, die ich mache. Ich frage mich, wie das in einer Linux-basierten Multicast-Disk-Imaging-Lösung funktionieren würde, die ich vor ein paar Jahren mit "udpcast" zusammengestellt habe.
Evan Anderson

Vor einiger Zeit fragte ich serverfault.com/questions/173358/multicast-file-transfers. Schließlich kam ich zu dem Schluss, dass uftp und mrsync die Werkzeuge der Wahl waren. Bitte schreiben Sie dort in die Kommentare, 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

2
Als ich mit UFTP, UDT und Tsunami UDP arbeitete, hatte UFTP die schlechteste Leistung von allen dreien. Natürlich ist es wahrscheinlich das ausgereifteste Protokoll. UDT stellt nur ein einfaches Übertragungsprotokoll zur Verfügung und wurde als Bibliothek für die Entwicklung benutzerdefinierter Software entwickelt. Der Autor von Tsunami hat uns tatsächlich auf UDT hingewiesen, da Tsunami in letzter Zeit aus Zeitgründen nicht aktiv entwickelt wurde.
Thomas Owens

9

Richten Sie einen einfachen Webserver ein, um die Datei in Ihrem Netzwerk zu hosten (ich schlage übrigens Nginx vor), richten Sie dann einen PC mit Firefox am anderen Ende ein und installieren Sie die DownThemAll- Erweiterung.

Es ist ein Download-Beschleuniger, der Chunking und Remontage unterstützt.
Sie können jeden Download in 10 Teile aufteilen, um ihn wieder zusammenzusetzen, und das macht die Sache tatsächlich schneller!

(Warnung: Ich habe es noch nie mit 160 GB versucht, aber es funktioniert gut mit 20 GB-ISO-Dateien)


40 Mbit / s zwischen denselben Computern. Sieht auch sehr gut aus.
Massimo

1
Ersetzen Sie Firefox durch axel.alioth.debian.org und es ist kein schlechter Vorschlag.
Justin

7

Der UDT- Transport ist wahrscheinlich der beliebteste Transport für Kommunikationen mit hoher Latenz. Dies führt zu ihrer anderen Software namens Sector / Sphere, einer "Hochleistungs-Engine für verteiltes Dateisystem und parallele Datenverarbeitung", deren Betrachtung sich lohnen könnte.


1
Ich habe mit UDT für Übertragungen über Netzwerke mit hoher Latenz und hohem Paketverlust gearbeitet. UDT ist viel widerstandsfähiger gegenüber Latenz und Paketverlust als TCP-basierte Protokolle, insbesondere wenn Sie den Algorithmus zur Überlastungskontrolle an Ihre Netzwerktopographie anpassen.
Thomas Owens

Es gibt sogar eine Version von rsync mit integriertem UDT namens "UDR". github.com/LabAdvComp/UDR
Max

5

Meine Antwort ist etwas spät, aber ich habe diese Frage gerade gefunden, als ich nach Fasp gesucht habe. Bei dieser Suche habe ich auch folgendes gefunden: http://tsunami-udp.sourceforge.net/ , das "Tsunami UDP Protocol".

Von ihrer Website:

Ein schnelles User-Space-Dateiübertragungsprotokoll, das TCP-Steuerung und UDP-Daten für die Übertragung über sehr schnelle Fernnetze (≥ 1 Gbit / s und sogar 10 GE) verwendet und so konzipiert ist, dass über dieselben Netze mehr Durchsatz als mit TCP möglich erzielt wird Netzwerke.

In Bezug auf die Geschwindigkeit wird auf der Seite auf dieses Ergebnis hingewiesen (über eine 1 GBit-Verbindung zwischen Helsinki, Finnland und Bonn, Deutschland:

Abbildung 1 - Internationale Übertragung über das Internet mit durchschnittlich 800 Mbit / s

Wenn Sie einen Download-Beschleuniger verwenden möchten, schauen Sie sich lftp an. Dies ist meines Wissens der einzige Download-Beschleuniger, der einen rekursiven Spiegel ausführen kann.


1
In dem Projekt, das ich zuvor in Steve-os Antwort kommentiert habe, haben wir UDT, Tsunami UDP und UFTP verglichen. Wir stellten fest, dass die Latenz einen großen Einfluss auf die Leistung hatte, während dies bei Paketverlusten nicht der Fall war (im Gegensatz zur Tsunami-Dokumentation). Durch Hinzufügen von 100 ms Latenz zum Testnetzwerk sank die Leistung des Tsunami von etwa 250 Mbit / s auf etwa 50 Mbit / s (ich glaube, ich habe meine Zahlen und Einheiten richtig angegeben - es ist eine Weile her, aber es war ein großer Rückgang). Das Hinzufügen von 10% Paketverlust ohne ein Netzwerk mit minimaler Latenz verringerte andererseits nur die Leistung von 250 Mbit / s auf etwa 90 Mbit / s.
Thomas Owens

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.