Was ist der schnellste Weg, um riesige Datenmengen zwischen zwei Computern zu senden? [geschlossen]

111

Dies ist eine Situation, in der ich mich häufig befinde:

  • Ich habe einen Quellserver mit einer 320-GB-Festplatte und 16 GB RAM (die genauen Spezifikationen sind hier verfügbar). Da dies jedoch ein Problem ist, auf das ich auch auf anderen Computern häufig stoße, würde ich es vorziehen, wenn die Antwort auf einem beliebigen Computer ausgeführt wird "vernünftiger" Linux-Rechner)
  • Ich habe einen Backup-Server mit mehreren Terabyte Festplattenspeicher ( genaue Angaben hier , siehe Haftungsausschluss oben)

Ich möchte 320 GB Daten vom Quellserver auf den Zielserver übertragen (insbesondere die Daten von /dev/sda).

  1. Die beiden Computer befinden sich physisch nebeneinander, sodass ich Kabel zwischen ihnen verlegen kann.
  2. Ich bin in einem LAN und verwende einen neuen Router , was bedeutet, dass meine Netzwerkgeschwindigkeit "ideal" 1000 MBit betragen sollte, oder?
  3. Sicherheit ist kein Thema. Ich bin in einem lokalen Netzwerk und vertraue allen Computern im Netzwerk, einschließlich des Routers.
  4. (Optional) Ich benötige nicht unbedingt eine signierte Prüfsumme der Daten, aber die grundlegende Fehlerprüfung (z. B. verworfene Pakete oder ein unlesbares Laufwerk) sollte erkannt werden, anstatt einfach in der Ausgabe zu verschwinden.

Ich habe online nach dieser Frage gesucht und mehrere Befehle getestet. Das, was am häufigsten auftaucht, ist folgendes:

ssh [email protected] 'dd bs=16M if=/dev/sda | gzip' > backup_sda.gz

Dieser Befehl hat sich als zu langsam erwiesen (er lief eine Stunde lang und hatte nur etwa 80 GB Datenvolumen). Es dauerte ungefähr 1 Minute und 22 Sekunden, bis das 1 GB-Testpaket doppelt so schnell war, wenn es nicht komprimiert wurde. Die Ergebnisse könnten auch durch die Tatsache verzerrt worden sein, dass die übertragene Datei weniger RAM als das Quellsystem beansprucht.

Außerdem (und dies wurde an 1 GB-Testobjekten getestet) treten Probleme auf, wenn ich den gzipBefehl und verwende dd. Die resultierende Datei hat eine andere Prüfsumme, wenn sie auf dem Ziel extrahiert wird, als wenn sie direkt weitergeleitet wird. Ich versuche immer noch herauszufinden, warum das passiert.

IQAndreas
quelle
54
Vergessen Sie nicht, Sneakernet
Gwillie
4
Möchten Sie /dev/sdaals Bild oder nur die Dateien übertragen. Warum ist rsync keine Option? Wird /dev/sdamontiert, während Sie dded?
Jodka Lemon
15
Ihre Leistungsdaten (1GB / 80sec, 80GB / 1h) stimmen genau mit den Daten überein, die wir auf 100MBit erwarten sollten. Überprüfen Sie Ihre Hardware. ... und Gerrit hat recht, 320 GB mögen groß sein, aber "massive Datenmengen" wecken falsche Erwartungen.
Blafasel
8
"Unterschätzen Sie niemals die Bandbreite eines Güterzuges voller Festplatten." .. Fragen Sie nach Durchsatz, Latenz oder einer Mischung aus beidem?
Keshlam
8
Ein Freund von mir hat immer gesagt: "Unterschätze niemals die Bandbreite eines Haufens von Festplatten auf einem LKW".
AMADANON Inc.

Antworten:

139

Da sich die Server physisch nebeneinander befinden und Sie in den Kommentaren angegeben haben, dass Sie physischen Zugriff auf sie haben, ist es am schnellsten , die Festplatte aus dem ersten Computer herauszunehmen, in den zweiten Computer zu verschieben und die Dateien zu übertragen über die SATA-Verbindung.

BlueRaja - Danny Pflughoeft
quelle
15
+1: Die Übertragung über physische Medien scheint der schnellste Weg zu sein, auch wenn dies bedeutet, dass Sie von irgendwoher eine große externe Festplatte herunterladen. Es ist ungefähr £ 40, und Sie haben wahrscheinlich schon so viel Zeit damit verbracht,
Deworde
3
Ich stimme dieser Idee überhaupt nicht zu, wenn man in einem Gigabit-Netzwerk die volle Geschwindigkeit erreicht. Das Testen über NFS / SMB über einen Zyxel Gigabit-Switch zwischen einem HP Gen 7-Mikroserver und einem Pentium G630-Computer ermöglicht eine Übertragung von ca. 100 MB / s. (Bis ich die Außenkante der Laufwerksplatten verlasse.) Ich denke also, dass dies in weniger als 3 Stunden realistisch wäre. Wenn Sie keine SSDs oder extrem leistungsfähige Laufwerke / Speicher verwenden, können 2 Kopien meines Erachtens keinen Durchsatz von 100 MB / s erzielen. Daher muss jeder Kopiervorgang 200 MB / s betragen, um die Gewinnschwelle zu erreichen.
Phizes
3
@Phizes: Natürlich kopieren Sie nicht auf eine temporäre. Das war eine schlechte Idee von Deword, nicht wovon alle anderen reden. Um das Quelllaufwerk mit dem Zielcomputer zu verbinden, müssen Sie SATA-> SATA mit dd(oder eine Kopie des Dateisystembaums) verwenden.
Peter Cordes
10
"Unterschätzen Sie niemals die Bandbreite eines Lastwagens voller Festplatten. Eine verdammt große Latenz"
Kevin
3
@ Kevin: Ja, mein Punkt war, dass eine direkte Kopie zwischen Festplatten auf demselben Computer mindestens so schnell ist wie jede andere mögliche Methode. Ich habe reale Bandbreitennummern genannt, um zu bestätigen, dass es für das alte Laufwerk des OP in Ordnung ist, über GigE hinauszugehen, aber ein Engpass für neue Laufwerke. (Ein Fall, in dem beide Laufwerke in einem Computer nicht die beste Option sind, ist, wenn separate Computer ihren RAM zum Zwischenspeichern der Metadaten der Quelle und des Ziels verwenden, z. B. für die Synchronisierung von Milliarden von Dateien.)
Peter Cordes,
69

netcat ist ideal für Situationen wie diese, in denen Sicherheit keine Rolle spielt:

# on destination machine, create listener on port 9999
nc -l 9999 > /path/to/outfile

# on source machine, send to destination:9999
nc destination_host_or_ip 9999 < /dev/sda
# or dd if=/dev/sda | nc destination_host_or_ip 9999

Wenn Sie ddGNU Coreutils verwenden, können Sie es SIGUSR1an den Prozess senden und es wird Fortschritt an stderr ausgeben. ddVerwenden Sie für BSD SIGINFO.

pv ist noch hilfreicher, wenn es darum geht, den Fortschritt während des Kopierens zu melden:

# on destination
nc -l 9999 | pv > /path/to/outfile

# on source
pv /dev/sda | nc destination_host_or_ip 9999
# or dd if=/dev/sda | pv | nc destination_host_or_ip 9999
Zackse
quelle
2
Für das zweite Beispiel ist ddauch erforderlich, oder kann pv/ ncbehandeln /dev/sdaganz gut auf eigene Faust? (Ich habe festgestellt, dass einige Befehle beim Versuch, bestimmte Dateien wie diese oder Dateien mit 0x00Bytes zu lesen,
ausgelöst werden.
5
@ user1794469 Hilft die Komprimierung? Ich denke, das Netzwerk ist nicht dort, wo der Engpass ist.
IQAndreas
17
Vergessen Sie nicht, dass in bashone > /dev/tcp/IP- /Port- und < /dev/tcp/IP- /Port- Umleitungen verwendet werden können, anstatt von bzw. zu Netcat zu leiten.
Incnis Mrsi
5
Gute Antwort. Gigabit-Ethernet ist häufig schneller als die Festplattengeschwindigkeit, daher ist die Komprimierung nutzlos. Um mehrere Dateien zu übertragen, beachten Sie tar cv sourcedir | pv | nc dest_host_or_ip 9999und cd destdir ; nc -l 9999 | pv | tar xv. Viele Variationen sind möglich. Sie möchten z. B. .tar.gzlieber eine Zielseite als Kopien behalten . Wenn Sie Verzeichnis zu Verzeichnis kopieren, können Sie aus Sicherheitsgründen anschließend eine rsync-Operation ausführen, z. B. von dest rsync --inplace -avP [email protected]:/path/to/source/. /path/to/destination/., um sicherzustellen , dass alle Dateien tatsächlich exakte Kopien sind.
Stéphane Gourichon
3
Anstatt IPv4 zu verwenden, können Sie mit IPv6 einen besseren Durchsatz erzielen, da die Nutzlast größer ist. Sie konfigurieren es nicht einmal, wenn die Maschinen IPv6-fähig sind, haben sie wahrscheinlich bereits eine IPv6-Link-Local-Adresse
David Costa
33
  1. Sie verwenden schnelle Kompression.

    • Unabhängig von Ihrem Übertragungsmedium - insbesondere für Netzwerk oder USB - arbeiten Sie mit Datenbursts für Lese-, Cache- und Schreibvorgänge, die nicht genau synchron sind.
    • Wenn Sie neben der Festplattenfirmware, den Festplattencaches und den Kernel- / RAM-Caches auch die CPUs des Systems verwenden können, um die pro Burst ausgetauschte Datenmenge zu konzentrieren , sollten Sie dies tun .
    • Jeder Komprimierungsalgorithmus verarbeitet spärliche Eingabeläufe automatisch so schnell wie möglich, aber es gibt nur sehr wenige, die den Rest bei Netzwerkdurchsätzen verarbeiten.
    • lz4 ist Ihre beste Wahl hier:

      LZ4 ist ein sehr schneller verlustfreier Komprimierungsalgorithmus mit einer Komprimierungsgeschwindigkeit von 400 MB / s pro Kern, der mit einer Multi-Core-CPU skaliert werden kann. Es verfügt außerdem über einen extrem schnellen Decoder mit einer Geschwindigkeit von mehreren GB / s pro Kern, der in der Regel die RAM-Geschwindigkeitsbeschränkungen bei Mehrkernsystemen erreicht.

  2. Am besten nicht unnötig suchen.

    • Dies kann schwierig zu beurteilen sein.
    • Wenn auf dem Gerät, von dem Sie kopieren, viel freier Speicherplatz vorhanden ist und das Gerät nicht kürzlich auf Null gesetzt wurde, aber alle Quelldateisysteme kopiert werden sollen, lohnt es sich wahrscheinlich, dies zuerst zu tun so etwas wie:

      </dev/zero tee >empty empty1 empty2; sync; rm empty*
    • Aber das hängt davon ab, auf welcher Ebene Sie die Quelle lesen sollten. Es ist normalerweise wünschenswert, das Gerät von Anfang bis Ende aus seiner /dev/some_diskGerätedatei zu lesen , da beim Lesen auf Dateisystemebene im Allgemeinen nicht sequentiell auf der Festplatte hin und her gesucht wird. Und so sollte Ihr Lesebefehl etwa so lauten:

      </dev/source_device lz4 | ...
    • Wenn Ihr Quelldateisystem jedoch nicht vollständig übertragen werden soll, ist das Lesen auf Dateisystemebene ziemlich unvermeidlich, und Sie sollten Ihre Eingabeinhalte in einem Stream zusammenfassen. paxist in der Regel die beste und einfachste Lösung in diesem Fall, aber Sie könnten auch mksquashfsdarüber nachdenken.

      pax -r /source/tree[12] | lz4 | ...
      mksquashfs /source/tree[12] /dev/fd/1 -comp lz4 | ...
      
  3. Sie nicht verschlüsseln mit ssh.

    • Das Hinzufügen eines zusätzlichen Verschlüsselungsaufwands zu einem vertrauenswürdigen Medium ist nicht erforderlich und kann die Geschwindigkeit von dauerhaften Übertragungen erheblich beeinträchtigen, da die gelesenen Daten zweimal gelesen werden müssen .
    • Der PRNG benötigt die gelesenen Daten oder zumindest einen Teil davon, um die Zufälligkeit aufrechtzuerhalten.
    • Und natürlich müssen Sie auch die Daten übertragen.
    • Sie müssen auch den Verschlüsselungs-Overhead selbst übertragen - das bedeutet mehr Arbeit für weniger Daten, die pro Burst übertragen werden .
    • Und so sollten Sie netcat( oder, wie ich es vorziehen würde, das nmapleistungsfähigere Projektncat ) für eine einfache Netzwerkkopie verwenden, wie an anderer Stelle vorgeschlagen wurde:

      ###  on tgt machine...
      nc -l 9999 > out.lz4
      ###  then on src machine...
      ... lz4 | nc tgt.local 9999
      
mikeserv
quelle
1
Fantastische Antwort. Ein kleinerer grammatikalischer Punkt - "Verringern der Datenmenge, die pro Burst ausgetauscht werden muss" - Ich denke, Sie verwenden die Komprimierung, um die Informationsdichte zu erhöhen, da die "Bursts" eine feste Breite haben und daher die Menge der ausgetauschten Daten konstant bleibt Die pro Burst übertragenen Informationen können jedoch variieren.
Engineer Dollery
@EngineerDollery - ja, das war doof. Ich denke, es ist besser,
mikeserv
@IQAndreas - Ich würde diese Antwort ernsthaft in Betracht ziehen. Persönlich benutze ich pigz und die Geschwindigkeitserhöhung ist erstaunlich . Die Parallelität ist ein großer Gewinn; CPUs sind viel schneller als jeder andere Teil der Datenpipeline, daher bezweifle ich, dass die parallele Komprimierung Sie verlangsamen wird (gzip ist nicht parallelisierbar). Möglicherweise ist dies so schnell, dass es keinen Anreiz gibt, mit Festplatten zu jonglieren. Es würde mich nicht wundern, wenn dieser Vorgang insgesamt schneller ist (einschließlich der Auslagerungszeit). Sie können Benchmarks mit und ohne Komprimierung erstellen. In jedem Fall sollte entweder die Diskswap-Antwort von BlueRaja oder diese Antwort Ihre akzeptierte Antwort sein.
Mike S
Schnelle Komprimierung ist ein ausgezeichneter Rat. Es ist jedoch zu beachten, dass dies nur dann hilfreich ist, wenn die Daten einigermaßen komprimierbar sind, was beispielsweise bedeutet, dass sie nicht bereits in einem komprimierten Format vorliegen dürfen.
Walter Tross
@WalterTross - Es hilft, wenn eine Eingabe unabhängig vom Verhältnis komprimierbar ist, solange der Komprimierungsjob den Übertragungsjob übertrifft. Auf einem modernen Vier-Kern-System sollte ein lz4Job auch bei weit geöffnetem GIGe problemlos möglich sein, und USB 2.0 hat keine Chance. Außerdem lz4sollte es nur funktionieren, wenn es sollte - es ist teilweise so schnell, weil es weiß, wann eine Komprimierung versucht werden sollte und wann nicht. Und wenn es sich um eine Gerätedatei handelt, die übertragen wird, können selbst vorkomprimierte Eingaben ohnehin etwas komprimiert werden, wenn das Quelldateisystem fragmentiert ist.
mikeserv
25

Es gibt verschiedene Einschränkungen, die die Übertragungsgeschwindigkeit einschränken können.

  1. Ein 1-Gbit / s-Pipe ist mit einem inhärenten Netzwerkoverhead verbunden. Normalerweise reduziert dies den IST-Durchsatz auf 900 Mbit / s oder weniger. Dann muss man bedenken, dass dies bidirektionaler Verkehr ist und man mit deutlich weniger als 900Mbps Down rechnen sollte.

  2. Auch wenn Sie einen "neuen Router" verwenden, sind Sie sicher, dass der Router 1 Gbit / s unterstützt? Nicht alle neuen Router unterstützen 1 Gbit / s. Wenn es sich nicht um einen Unternehmensrouter handelt, geht möglicherweise zusätzliche Übertragungsbandbreite verloren, da der Router ineffizient ist. Basierend auf dem, was ich unten gefunden habe, sieht es so aus, als würden Sie über 100 Mbit / s erreichen.

  3. Möglicherweise ist das Netzwerk anderer Geräte, die Ihr Netzwerk gemeinsam nutzen, überlastet. Haben Sie versucht, ein direkt angeschlossenes Kabel zu verwenden, wie Sie sagten, dass Sie dies können?

  4. Wie viel Festplatten-IO verwenden Sie? Wahrscheinlich werden Sie nicht durch das Netzwerk, sondern durch das Festplattenlaufwerk eingeschränkt. Die meisten Festplatten mit 7200 U / min erreichen nur etwa 40 MB / s. Benutzt du überhaupt eine Razzia? Verwenden Sie SSDs? Was verwenden Sie auf der Remote-Seite?

Ich empfehle die Verwendung von rsync, wenn dies für Sicherungen erneut ausgeführt werden soll. Sie können auch scp, ftp (s) oder http mit einem Downloader wie filezilla am anderen Ende verwenden, da dadurch ssh / http / https / ftp-Verbindungen parallelisiert werden. Dies kann die Bandbreite erhöhen, da sich die anderen Lösungen über eine einzelne Pipe befinden. Ein einzelnes Pipe / Thread ist immer noch durch die Tatsache begrenzt, dass es ein einzelnes Thread ist, was bedeutet, dass es sogar CPU-gebunden sein kann.

Mit rsync reduzieren Sie die Komplexität Ihrer Lösung erheblich und ermöglichen Komprimierung, Beibehaltung von Berechtigungen und teilweise Übertragung. Es gibt mehrere andere Gründe, aber es ist im Allgemeinen die bevorzugte Sicherungsmethode (oder führt die Sicherungssysteme aus) von großen Unternehmen. Commvault verwendet tatsächlich rsync unter seiner Software als Übermittlungsmechanismus für Sicherungen.

Basierend auf Ihrem Beispiel von 80 GB / h erhalten Sie ungefähr 177 Mbit / s (22,2 Mbit / s). Ich glaube, Sie könnten dies mit rsync auf einer dedizierten Ethernet-Leitung zwischen den beiden Boxen leicht verdoppeln, da ich es in meinen eigenen Tests mit rsync über Gigabit geschafft habe.

Khrystoph
quelle
12
+1 für rsync. Es ist möglicherweise nicht schneller, wenn Sie es zum ersten Mal ausführen, aber es wird sicherlich für alle nachfolgenden Zeiten sein.
Skrrp
4
> Die meisten Festplatten mit 7200 U / min erreichen nur etwa 40 MB / s. IME ist es wahrscheinlicher, dass mit einem modernen Laufwerk mehr als 100 MB / s sequenziell angezeigt werden (und dies schließt ~ 5-KB- Laufwerke ein). Dies könnte jedoch eine ältere Festplatte sein.
Bob,
2
@Bob: Die modernen können immer noch nur 5400 Rundspuren pro Minute lesen. Diese Festplatten sind immer noch schnell, da jede Spur mehr als ein Megabyte enthält. Das bedeutet, dass sie auch ziemlich große Festplatten sind. Eine kleine 320-GB-Festplatte kann nicht zu viele Kilobyte pro Spur aufnehmen, was ihre Geschwindigkeit notwendigerweise einschränkt.
MSalters
1
40 MB / s sind definitiv sehr pessimistisch für sequentielles Lesen für alle Laufwerke, die im letzten Jahrzehnt hergestellt wurden. Aktuelle Laufwerke mit 7200 U / min können laut Bob 100 MB / s überschreiten.
Hobbs
3
Gigabit-Ethernet ist 1000 Mbit / s Vollduplex . Sie erhalten 1000 Mbit / s (oder, wie Sie sagen, ungefähr 900 Mbit / s in der Realität) in jede Richtung . Zweitens: Festplatten erreichen jetzt routinemäßig 100 MB / s. 40 MB / s sind langsam, es sei denn, es handelt sich um ein zehn Jahre altes Laufwerk.
Derobert
16

Damit beschäftigen wir uns regelmäßig.

Die beiden wichtigsten Methoden, die wir verwenden, sind:

  1. SATA / eSATA / Sneakernet
  2. Direkte NFS-Einbindung, dann lokal cpoderrsync

Die erste hängt davon ab, ob das Laufwerk physisch verlagert werden kann. Dies ist nicht immer der Fall.

Der zweite funktioniert überraschend gut. Im Allgemeinen können wir eine 1-Gbit / s-Verbindung mit direkten NFS-Mounts recht einfach ausschöpfen. Mit scp, dd over ssh oder ähnlichem kommt man nicht in die Nähe (oft wird eine Höchstgeschwindigkeit von verdächtig nahe an 100 mpbs erreicht). Sogar auf sehr schnellen Multicore-Prozessoren wird der maximale Kryptodurchsatz eines der Kerne auf dem langsamsten der beiden Computer beeinträchtigt, was im Vergleich zu Voll-CPU- oder Rsync-Vorgängen auf einem unverschlüsselten Netzwerk-Mount bedrückend langsam ist. Gelegentlich stoßen Sie für eine Weile an eine Iops-Wand und bleiben bei ca. 53 MB / s anstatt der typischen ~ 110 MB / s hängen. Dies ist jedoch normalerweise nur von kurzer Dauer, es sei denn, die Quelle oder das Ziel ist tatsächlichein einzelnes Laufwerk, dann könnten Sie durch die anhaltende Rate des Laufwerks selbst begrenzt werden (die aus zufälligen Gründen genug variiert, die Sie nicht wissen, bis Sie es tatsächlich versuchen) - meh.

Das Einrichten von NFS kann ein wenig ärgerlich sein, wenn es auf einer unbekannten Distribution läuft, aber im Allgemeinen war es der schnellste Weg, die Rohre so vollständig wie möglich zu füllen. Als ich das letzte Mal mehr als 10 Gbit / s gemacht habe, habe ich nie herausgefunden, ob die Verbindung voll war, da die Übertragung vor meiner Rückkehr von einem Kaffee vorbei war. Es kann also sein, dass Sie dort ein natürliches Limit erreicht haben. Wenn sich zwischen der Quelle und dem Ziel ein paar Netzwerkgeräte befinden, kann es zu geringfügigen Verzögerungen oder Schluckauf aufgrund des Netzwerk-Slinky-Effekts kommen. Im Allgemeinen funktioniert dies jedoch im gesamten Büro (ohne Datenverkehr) oder von einem Ende des Rechenzentrums bis die andere (es sei denn, Sie haben eine Art Filterung / Inspektion, die intern stattfindet. In diesem Fall sind alle Wetten deaktiviert ).

BEARBEITEN

Ich bemerkte etwas Geschwätz über Kompression ... Sie nicht die Verbindung komprimieren. Es wird Sie genauso verlangsamen wie eine Kryptoschicht. Der Engpass ist immer ein einzelner Kern, wenn Sie die Verbindung komprimieren (und Sie werden den Bus dieses Kerns nicht einmal besonders gut ausnutzen). Das Langsamste, was Sie in Ihrer Situation tun können, ist die Verwendung eines verschlüsselten, komprimierten Kanals zwischen zwei Computern, die auf einer Verbindung mit 1 Gbit / s oder höher nebeneinander sitzen.

ZUKÜNFTIGER BEWEIS

Diese Empfehlung gilt ab Mitte 2015. Dies wird mit ziemlicher Sicherheit noch viele Jahre nicht mehr der Fall sein. Nehmen Sie also alles mit einem Körnchen Salz, und wenn Sie sich dieser Aufgabe regelmäßig stellen, probieren Sie verschiedene Methoden mit tatsächlichen Lasten aus, anstatt sich vorzustellen, dass Sie alles erreichen, was den theoretischen Optimalwerten oder sogar den beobachteten Kompressions- / Kryptodurchsatzraten entspricht, die für Dinge wie das Internet typisch sind Verkehr, viel davon ist textuelles (protip: Bulk - Transfer in der Regel hauptsächlich aus Bildern besteht, Audio, Video, Datenbankdateien, Binärcode, office - Dateiformate usw. , die sind bereits komprimiertauf ihre eigene Art und Weise und profitieren nur sehr wenig davon, wenn Sie eine weitere Komprimierungsroutine durchlaufen, deren Komprimierungsblockgröße fast garantiert nicht mit Ihren bereits komprimierten Binärdaten übereinstimmt ...).

Ich stelle mir vor, dass Konzepte wie SCTP in Zukunft an einen interessanteren Ort gebracht werden, an dem gebondete Verbindungen (oder durch das Spektrum intern gebondete kanalisierte Glasfaserverbindungen) typisch sind und jeder Kanal einen von den anderen unabhängigen Datenstrom empfangen kann stream kann parallel komprimiert / verschlüsselt werden usw. usw. das wäre wunderbar! Aber das ist heute im Jahr 2015 nicht der Fall, und obwohl das Fantasieren und Theoretisieren nett ist, haben die meisten von uns keine benutzerdefinierten Speichercluster in einer Kryokammer, die Daten direkt in die Innereien eines Blue Gene / Q einspeisen und so Antworten für Watson generieren. Das ist einfach nicht die Realität. Wir haben auch keine Zeit, unsere Datennutzlast eingehend zu analysieren, um herauszufinden, ob Komprimierung eine gute Idee ist oder nicht - die Übertragung selbst wäre beendet, bevor wir unsere Analyse abgeschlossen haben.

Aber...

Die Zeiten ändern sich und meine Empfehlung gegen Komprimierung und Verschlüsselung wird nicht gelten. Ich würde es wirklich lieben, wenn dieser Rat im typischen Fall sehr bald aufgehoben würde. Es würde mein Leben leichter machen.

zxq9
quelle
1
@jofel Nur wenn die Netzwerkgeschwindigkeit langsamer ist als der Komprimierungsdurchsatz des Prozessors - was bei Verbindungen mit 1 gpbs oder höher niemals der Fall ist. Im typischen Fall ist das Netzwerk der Engpass, und die Komprimierung beschleunigt die Dinge effektiv. Dies ist jedoch nicht der Fall, den das OP beschreibt.
zxq9
2
lz4ist schnell genug, um GigE nicht zu einem Engpass zu machen, aber je nachdem, was Sie mit der Kopie machen möchten, müssen Sie sie möglicherweise unkomprimiert lassen. lzop ist auch ziemlich schnell. Bei meinem i5-2500k Sandybridge (3,8 GHz) ist der lz4 < /dev/raid0 | pv -a > /dev/nullEingang mit ~ 180 MB / s und der Ausgang mit ~ 105 MB / s genau das Richtige für GigE. Das Dekomprimieren auf der Empfangsseite ist für die CPU noch einfacher.
Peter Cordes
1
Außerdem ist 3,8 GHz ein gutes Stück schneller als die meisten Serverprozessoren (oder viele Business-Grade-Systeme, wie ich sie zumindest gewohnt bin). In Rechenzentren ist es üblicher, viel höhere Kernzahlen bei viel niedrigeren Taktraten zu beobachten. Die Parallelisierung von Übertragungslasten war lange Zeit kein Problem , daher bleiben wir in den meisten Fällen bei der maximalen Geschwindigkeit eines einzelnen Kerns - aber ich gehe davon aus, dass sich dies jetzt ändern wird, da die Taktraten im Allgemeinen maximal sind, die Netzwerkgeschwindigkeiten jedoch immer noch a betragen Es ist noch ein langer Weg, bis sie ihr Maximum erreicht haben.
zxq9
2
Ich stimme Ihren Kommentaren zur Komprimierung überhaupt nicht zu. Dies hängt vollständig von der Komprimierbarkeit der Daten ab. Wenn Sie eine Komprimierungsrate von 99,9% erreichen könnten, wäre es dumm, dies nicht zu tun - warum 100 GB übertragen, wenn Sie mit der Übertragung von 100 MB davonkommen können? Ich schlage nicht vor, dass diese Komprimierungsstufe für diese Frage der Fall ist, sondern zeige nur, dass dies von Fall zu Fall zu prüfen ist und dass es keine absoluten Regeln gibt.
Engineer Dollery
1
@EngineerDollery Dies spielt nicht in Bulk - Transfer aus überhaupt in der realen Welt. Ich mache das fast jeden Tag und habe eine Vielzahl von Methoden und Einstellungen getestet. Im Allgemeinen sind große Mengen an unbekannten Datenübertragungen (alles, wofür Sie keine Zeit haben, Komprimierungstests durchzuführen - was in der Praxis bedeutet, dass fast alles in einem Rechenzentrum, einer Unternehmensinfrastruktur, einem kleinen Unternehmensserver oder einem Heimnetzwerk vorhanden ist) sehr umfangreich schneller über eine Verbindung mit 1 Gbit / s oder höher. Probieren Sie es aus. Text eignet sich in der Regel am besten für die Komprimierung. Text umfasst einen winzigen Bruchteil einer typischen Massenübertragungsnutzlast.
zxq9
6

Ein nützliches Tool, das ich in der Vergangenheit verwendet habe, ist bbcp. Wie hier zu sehen: https://www.slac.stanford.edu/~abh/bbcp/ .

Siehe auch http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm

Ich habe mit diesem Tool sehr schnelle Übertragungsgeschwindigkeiten gehabt.

Dunkles Herz
quelle
1
Der zweite Link dieser Antwort erklärt, wie Sie die Kernel-Parameter optimieren, um höhere Geschwindigkeiten zu erreichen. Der Autor dort hat 800 Megabyte pro Sekunde in einem 10G-Link und einige Dinge scheinen auf 1Gbps-Links anwendbar zu sein.
Stéphane Gourichon
5

Wenn Sie einen ersten Durchgang erhalten (über das Kabel / Sneakernet / was auch immer), können Sie rsyncmit bestimmten Optionen nachsehen , die nachfolgende Übertragungen erheblich beschleunigen können. Ein sehr guter Weg wäre:

rsync -varzP sourceFiles destination

Folgende Optionen stehen zur Verfügung: Ausführlich, Archivierungsmodus, Rekursiv, Komprimieren, Teilweiser Fortschritt

Hopfender Hase
quelle
2
Rsync ist zuverlässiger als Netcat, aber Archivierung impliziert rekursiv, sodass das r redundant ist.
Tanath,
Auch -zkann incrediby langsam abhängig von Ihrer CPU und welche Daten Sie verarbeiten. Beim Deaktivieren der Komprimierung sind Übertragungen von 30 MB / s auf 125 MB / s aufgetreten.
Lindhe
4

Es wurde darauf bestanden, dass das Originalplakat in Kommentaren zu Zackses Antwort enthalten ist, obwohl ich nicht sicher bin, ob es unter normalen Umständen das schnellste ist.

bashhat eine spezielle Umleitungssyntax:
Für die Ausgabe:      > /dev/tcp/IP- /Port
Für die Eingabe:       < /dev/tcp/IP- /Port
IP- Verbot kann entweder eine IP- Adresse mit gepunkteten Dezimalstellen oder ein Hostname sein; port ban kann entweder eine Dezimalzahl oder ein Portname von sein /etc/services.

Es gibt kein aktuelles /dev/tcp/Verzeichnis. Es ist ein spezieller syntaktischer Kludge, der befiehlt bash, einen TCP-Socket zu erstellen, ihn mit dem angegebenen Ziel zu verbinden und dann das Gleiche wie bei einer normalen Dateiumleitung zu tun (nämlich den entsprechenden Standard-Stream mit dup2 (2) durch den Socket zu ersetzen).

Somit kann man Daten von ddoder taran der Quellmaschine direkt über TCP streamen . Oder umgekehrt, um Daten tardirekt über TCP zu oder zu etwas Ähnlichem zu streamen . In jedem Fall entfällt ein überflüssiger Netcat.

Hinweise zu Netcat

Die Syntax zwischen klassischem Netcat und GNU Netcat ist inkonsistent . Ich werde die klassische Syntax verwenden, an die ich gewöhnt bin. Ersetzen Sie -lpdurch -lfür GNU Netcat.

Ich bin mir auch nicht sicher, ob GNU Netcat den -qWechsel akzeptiert .

Übertragen eines Disk-Image

(In Anlehnung an Zackses Antwort.)
Am Bestimmungsort:

nc -lp 9999 >disk_image

An der Quelle:

dd if=/dev/sda >/dev/tcp/destination/9999
 

Erstellen eines tar.gz-Archivs mit tar

Am Bestimmungsort:

nc -lp 9999 >backup.tgz

An der Quelle:

tar cz files or directories to be transferred >/dev/tcp/destination/9999

Ersetzen Sie .tgzmit .tbzund czmit cj, um ein bzip2komprimiertes Archiv zu erhalten.

Übertragung mit sofortiger Erweiterung in das Dateisystem

Auch mit tar.
Am Bestimmungsort:

cd backups
tar x </dev/tcp/destination/9999

An der Quelle:

tar c files or directories to be transferred |nc -q 1 -lp 9999

Es wird ohne funktionieren -q 1, aber Netcat wird stecken bleiben, wenn die Daten beendet sind. Siehe tar (1) zur Erläuterung der Syntax und der Einschränkungen von tar. Wenn es viele Dateien mit hoher Redundanz (niedriger Entropie) gibt, kann eine Komprimierung (z. B. czund xzanstelle von cund x) versucht werden. Wenn es sich jedoch um typische Dateien handelt und das Netzwerk schnell genug ist, würde dies den Prozess nur verlangsamen. Weitere Informationen zur Komprimierung finden Sie in der Antwort von mikeserv.

Alternativer Stil (das Ziel hört den Port ab)

Am Bestimmungsort:

cd backups
nc -lp 9999 |tar x

An der Quelle:

tar c files or directories to be transferred >/dev/tcp/destination/9999
Incnis Mrsi
quelle
bash kann anscheinend nicht auf einen Socket "lauschen", um zu warten und eine Datei zu erhalten: unix.stackexchange.com/questions/49936/… Sie müssten also für mindestens die Hälfte der Verbindung etwas anderes verwenden ...
Rogerdpack
3

Probieren Sie die Vorschläge zu Direktverbindungen und zur Vermeidung verschlüsselter Protokolle wie ssh aus. Wenn Sie dennoch jede Leistung herausholen möchten, lesen Sie auf dieser Website https://fasterdata.es.net/host-tuning/linux/, um Ratschläge zur Optimierung Ihrer TCP-Fenster zu erhalten.

Brandon Xavier
quelle
2

Ich würde dieses Skript verwenden, das ich geschrieben habe und das das socatPaket benötigt.

Auf dem Quellcomputer:

tarnet -d wherefilesaretosend pass=none 12345 .

Auf dem Zielcomputer:

tarnet -d wherefilesaretogo pass=none sourceip/12345

Wenn das vbufPaket (Debian, Ubuntu) vorhanden ist, zeigt der Dateisender einen Datenfortschritt an. Der Dateiempfänger zeigt an, welche Dateien empfangen werden. Die Option pass = kann verwendet werden, wenn die Daten möglicherweise verfügbar gemacht werden (langsamer).

Bearbeiten:

Verwenden Sie die -nOption, um die Komprimierung zu deaktivieren, wenn die CPU ein Flaschenhals ist.

Skaperen
quelle
2

Wenn das Budget nicht das Hauptproblem ist, können Sie versuchen, die Laufwerke mit einem Intel Xeon E5 12-Core- "Laufwerksanschluss" zu verbinden. Dieser Connector ist normalerweise so leistungsfähig, dass Sie sogar Ihre aktuelle Serversoftware darauf ausführen können. Von beiden Servern!

Dies mag nach einer unterhaltsamen Antwort aussehen, aber Sie sollten sich wirklich überlegen, warum Sie die Daten zwischen Servern verschieben und ob eine große mit gemeinsam genutztem Speicher und Speicher möglicherweise sinnvoller ist.

Sie sind sich nicht sicher über die aktuellen Spezifikationen, aber die langsame Übertragung kann durch die Festplattengeschwindigkeit und nicht durch das Netzwerk begrenzt sein?

user133111
quelle
1

Wenn Sie sich nur für Backups interessieren und nicht für eine byteweise Kopie der Festplatte, dann würde ich backupPC empfehlen. http://backuppc.sourceforge.net/faq/BackupPC.html Die Einrichtung ist etwas mühsam, geht aber sehr schnell.

Meine anfängliche Übertragungszeit für ca. 500 g Daten betrug ca. 3 Stunden. Nachfolgende Sicherungen erfolgen in ca. 20 Sekunden.

Wenn Sie nicht an Backups interessiert sind, aber versuchen, Dinge zu synchronisieren, ist rsync oder unisono besser für Sie geeignet.

Eine byteweise Kopie einer Festplatte ist normalerweise eine schreckliche Idee für Sicherungszwecke (keine inkrementellen Änderungen, keine Platzersparnis, das Laufwerk kann nicht verwendet werden, Sie müssen den "leeren Speicherplatz" sichern und Sie müssen den Müll sichern (wie eine 16-G-Auslagerungsdatei oder 200-G-Core-Dumps oder Ähnliches.) Mit rsync (oder backuppc oder Ähnliches) können Sie rechtzeitig "Snapshots" erstellen, um zu "wie Ihr Dateisystem vor 30 Minuten aussah" zu gelangen sehr wenig Aufwand.

Das heißt, wenn Sie wirklich eine Byte für Byte-Kopie übertragen möchten, liegt Ihr Problem in der Übertragung und nicht im Abrufen von Daten vom Laufwerk. Ohne 400 GB RAM wird die Übertragung von 320 GB-Dateien sehr lange dauern. Die Verwendung von Protokollen, die nicht verschlüsselt sind, ist eine Option, aber egal was passiert, Sie müssen nur dort sitzen und mehrere Stunden warten (über das Netzwerk).

coteyr
quelle
1
Wie beschleunigen 400 G RAM die Datenübertragung?
Skaperen
Ich bin mir nicht sicher, ob das die Absicht war, aber ich habe gelesen, dass es eine Weile dauern wird, bis ein Medium langsamer als RAM zu RAM übertragen wird, anstatt 400 GB RAM zu kaufen und die Übertragung von Festplatte zu Festplatte schneller wird.
MichaelS
Ja, RAM wird für Sie puffern, und es wird schneller scheinen. Sie können eine HD-zu-HD-Übertragung mit vollständig gepuffertem RAM durchführen, was sehr schnell zu sein scheint. Es wird auch eine Weile dauern, um auf die Festplatte zu spülen, aber HD zu RAM zu RAM zu HD ist schneller als HD zu HD. (Denken Sie daran, dass Sie ohnehin HD zu RAM zu RAM zu HD machen müssen, aber wenn Sie weniger als Ihre gesamte Übertragungsgröße an RAM haben, müssen Sie in Segmenten "spülen".)
coteyr
Eine andere Möglichkeit ist, das gesamte Quelllaufwerk zu komprimieren oder sogar nur zu senden, um es in den RAM einzulesen. Wenn es nicht auf einmal passt, muss es ein Segment lesen, senden, Segment verwerfen, suchen, Segment lesen usw. Wenn es auf einmal passt, muss es nur alle auf einmal lesen. Gleich am Ziel.
Coteyr
1
HD zu RAM zu RAM zu HD ist schneller als HD zu HD Wie kann es schneller sein?
AL
1

Unabhängig vom Programm habe ich normalerweise festgestellt, dass das "Abrufen" von Dateien über ein Netzwerk schneller ist als das "Abrufen". Das heißt, die Anmeldung am Zielcomputer und das Ausführen eines Lesevorgangs sind schneller als die Anmeldung am Quellcomputer und das Ausführen eines Schreibvorgangs.

Beachten Sie außerdem Folgendes, wenn Sie ein Zwischenlaufwerk verwenden möchten: Besorgen Sie sich ein externes Laufwerk (entweder als Paket oder als separates Laufwerk, das an eine Dockingstation angeschlossen ist), das eSATA anstelle von USB verwendet. Installieren Sie dann auf jedem der beiden Computer entweder eine Karte mit einem eSATA-Anschluss oder besorgen Sie sich ein einfaches Adapterkabel, das einen der internen SATA-Anschlüsse mit einem externen eSATA-Anschluss verbindet. Schließen Sie dann das Laufwerk an den Quellcomputer an, schalten Sie das Laufwerk ein und warten Sie, bis es automatisch bereitgestellt wird. Dann kopieren; Sie schreiben mit der gleichen Geschwindigkeit wie auf ein internes Laufwerk. Hängen Sie dann das Laufwerk aus, fahren Sie es herunter, schließen Sie es an den anderen Computer an, fahren Sie es hoch, warten Sie auf eine automatische Bereitstellung und lesen Sie.

Mike Ciaraldi
quelle
2
Können Sie Einzelheiten zum "Abrufen" von Dateien angeben? Welche Dienstprogramme verwenden Sie und können Sie ein Beispiel bereitstellen, das diesen Effekt zeigt?
STW
Ich bin nicht sicher, ob dies eine vollständigere Antwort sein wird, aber stellen Sie sich das folgende Szenario vor: Angenommen, Sie haben zwei Computer, foo und bar, und Sie möchten Daten von foo nach bar kopieren. (1) Sie melden sich bei foo an und mounten dann das Laufwerk, das physisch an bar angeschlossen ist. Dann kopieren Sie von der Festplatte von foo in das remote gemountete Verzeichnis (das sich physisch in der Leiste befindet). Ich nannte dies das Übertragen der Daten auf den anderen Computer. (2) Vergleichen Sie dies mit der anderen Methode zum Kopieren derselben Daten. Melden Sie sich bei bar an, hängen Sie das an foo angehängte Verzeichnis fern und lesen Sie von foo auf das Laufwerk von bar. Das zieht.
Mike Ciaraldi
Dieses Kopieren kann mit dem Linux-Befehl cp über einen GUI-Dateimanager oder auf eine andere Art und Weise durchgeführt werden. Ich denke, das Ziehen ist schneller, da das Schreiben langsamer als das Lesen ist und mehr Entscheidungen über das Schreiben auf die Zieldiskette auf demselben Computer getroffen werden, an den das Laufwerk angeschlossen ist, sodass weniger Overhead entsteht. Aber vielleicht ist dies bei moderneren Systemen nicht mehr der Fall.
Mike Ciaraldi
1

Ich werde empfehlen, dass Sie sich NIC-Teaming ansehen. Dies beinhaltet die Verwendung mehrerer Netzwerkverbindungen, die parallel ausgeführt werden. Angenommen, Sie benötigen wirklich mehr als 1 GB Transfer und 10 GB sind unerschwinglich. Die Bereitstellung von 2 GB durch NIC-Teaming ist jedoch mit geringen Kosten verbunden, und Ihre Computer verfügen möglicherweise bereits über zusätzliche Ports.

Byron Jones
quelle
Wenn Sie sich auf LACP (Link Aggregation Control Protocol) beziehen, wird sich die Geschwindigkeit nicht erhöhen. Es bot Redundanz und die Möglichkeit, mehr gleichzeitige Verbindungen zu bedienen, führte jedoch nicht zu einer Geschwindigkeitssteigerung für diese Art der Übertragung.
STW,
@STW: Es ist eine Switch-Unterstützung erforderlich, um zwei Verbindungen zu einem Computer zu einer 2-GBit-Verbindung zusammenzufassen. Dies ist jedoch möglich. Dies ist jedoch nur hilfreich, wenn beide Computer über eine 2-GBit-Verbindung zum Switch verfügen. Wenn Sie über zwei Kabel mit NIC <-> NIC ohne Switch verfügen, sollte dies ebenfalls funktionieren, ist aber nicht sehr nützlich (es sei denn, Sie haben eine dritte NIC auf einem Computer, um die Verbindung zum Internet aufrechtzuerhalten).
Peter Cordes
Gibt es einen bestimmten Namen für diese Funktion in Switches?
STW
Es gibt verschiedene Varianten von NIC-Teaming, EtherChannel usw. STW ist für bestimmte Konfigurationen geeignet, dies hilft nicht, für einige Konfigurationen jedoch. Es kommt darauf an, ob der verbundene Kanal die Leistung für einen einzelnen IP-Socket beschleunigt oder nicht. Sie müssen die Einzelheiten untersuchen, um festzustellen, ob dies für Sie eine praktikable Lösung ist.
Byron Jones
802.3ad ist der offene Standard, nach dem Sie bei Ihren Switches suchen würden. Als schnellen Hack können Sie jedoch zusätzliche Netzwerkkarten an das Netzwerk anschließen und ihnen die entsprechenden IP-Adressen in separaten Subnetzen im privaten Adressraum zuweisen. (Host 1 Port a & Host 2 Port a erhalten ein Subnetz, Host 1 Port b und Host 2 Port b erhalten ein anderes Subnetz). Führen Sie dann einfach zwei parallele Jobs aus, um die Übertragung durchzuführen. Dies ist viel einfacher als das Erlernen der
Vor- und Nachteile
1

FWIW, ich habe das immer benutzt:

tar -cpf - <source path> | ssh user@destserver "cd /; tar xf -"

Bei dieser Methode werden die Datei- / Ordnerberechtigungen zwischen den Computern beibehalten (vorausgesetzt, auf beiden Computern sind dieselben Benutzer / Gruppen vorhanden). )

Gerade getestet zwischen zwei ausgelasteten Servern und verwaltet ~ 14GB in 216s (ca. 64MB / s) - könnte besser zwischen dedizierten Maschinen und / oder Komprimierung tun ... YMMV

$ date; tar -cpf - Installers | ssh elvis "cd /home/elvis/tst; tar xf -"; date
Wed Sep  9 15:23:37 EDT 2015
Wed Sep  9 15:27:13 EDT 2015

$ du -s Installers
14211072   Installers
ttstooge
quelle
1

Wenn Sie keine forensische Untersuchung des Dateisystems durchführen möchten, verwenden Sie ein Speicherauszugs- / Wiederherstellungsprogramm für Ihr Dateisystem, um zu vermeiden, dass der freie Speicherplatz kopiert wird, den der FS nicht verwendet. Je nachdem, über welches Dateisystem Sie verfügen, werden in der Regel alle Metadaten beibehalten , einschließlich ctime. Die Inode-Nummern können sich jedoch je nach Dateisystem ändern (xfs, ext4, ufs ...).

Das Wiederherstellungsziel kann eine Datei auf dem Zielsystem sein.

Wenn Sie ein vollständiges Festplatten-Image mit der Partitionstabelle möchten, können Sie dddie Partitionstabelle / bootloader / stuff, aber dann xfsdumpdie Partitionen als erstes 1 MB der Festplatte abrufen.

Ich kann Ihrem Info-Dump nicht entnehmen, über welches Dateisystem Sie tatsächlich verfügen. Wenn es BSD UFS ist, dann denke ich, dass ein Dump / Restore-Programm hat. Wenn es sich um ZFS handelt, also IDK, könnte es etwas geben.

Im Allgemeinen ist das vollständige Kopieren von Datenträgern zu langsam, außer für Wiederherstellungssituationen. Auf diese Weise können Sie auch keine inkrementellen Sicherungen durchführen.

Peter Cordes
quelle
1

Sie können die Systeme auch so einrichten, dass sie einen gemeinsam genutzten Speicher haben!

Ich denke, dass diese nebeneinander sind, und Sie werden dies wahrscheinlich immer wieder tun ....

user133526
quelle
1

Wie wäre es mit einem Ethernet-Crossover-Kabel? Anstatt sich auf drahtlose Geschwindigkeiten zu verlassen, können Sie nur die verkabelte Geschwindigkeit Ihrer Netzwerkkarte verwenden.

Hier ist eine ähnliche Frage mit einigen Beispielen für diese Art von Lösung.

Anscheinend wird heutzutage nur ein typisches Ethernet-Kabel ausreichen. Offensichtlich ist die Übertragung umso schneller, je besser Ihre Netzwerkkarte ist.

Zusammenfassend lässt sich festhalten, dass eine Netzwerkeinrichtung nur statische IP-Adressen für Ihren Server und Ihren Sicherungscomputer mit einer Subnetzmaske von 255.255.255.0 festlegen muss

Viel Glück!

Bearbeiten:

@Khrystoph hat dies in seiner Antwort angesprochen


quelle
Wie werden die Geschwindigkeitsraten verbessert? Kannst du mir bitte deine Antwort erklären?
AL
1
Dies würde möglicherweise die Geschwindigkeit verbessern, da Sie sich keine Sorgen darüber machen müssen, dass das Zwischennetz Sie verlangsamt. In Bezug auf "typische" vs "Crossover" -Ethernetkabel wird 1 GB-Ethernet bei Bedarf automatisch gekreuzt. HP Ethernet-Switches tun dies bei 100 MB. Andere Marken im Allgemeinen nicht, und Sie benötigen eine Frequenzweiche, wenn Sie bei 100 MB stecken.
Dan Pritts
1

Einige Leute empfehlen, dass Sie ssh überspringen, weil die Verschlüsselung Sie verlangsamen wird. Moderne CPUs sind zwar mit 1 GB schnell genug, aber OpenSSH hat Probleme mit seiner internen Windows-Implementierung, die Sie drastisch verlangsamen können.

Wenn Sie dies mit ssh tun möchten, schauen Sie sich HPN SSH an . Es löst die Fensterprobleme und fügt Multithread-Verschlüsselung hinzu. Leider müssen Sie ssh sowohl auf dem Client als auch auf dem Server neu erstellen.

Dan Pritts
quelle
0

OK Ich habe versucht, diese Frage für zwei Computer mit "sehr großen Rohren" (10 GBe) zu beantworten, die "nahe" beieinander liegen.

Das Problem, auf das Sie hier stoßen, ist: Die meisten Komprimierungsprobleme treten bei der CPU auf, da die Pipes so groß sind.

Leistung zum Übertragen von 10 GB-Dateien (6-GB-Netzwerkverbindung [Linode], nicht komprimierbare Daten):

$  time bbcp 10G root@$dest_ip:/dev/null
0m16.5s 

iperf:

server: $ iperf3 -s -F /dev/null
client:
$ time iperf3 -c $dest_ip -F 10G -t 20 # -t needs to be greater than time to transfer complete file
0m13.44s
(30% cpu)

netcat (1.187 openbsd):

server: $ nc -l 1234 > /dev/null
client: $ time nc $dest_ip 1234 -q 0 < 10G 
0m13.311s
(58% cpu)

scp:

$ time /usr/local/bin/scp 10G root@$dest_ip:/dev/null
1m31.616s
scp with hpn ssh patch (scp -- hpn patch on client only, so not a good test possibly): 
1m32.707s

socat:

server:
$ socat -u TCP-LISTEN:9876,reuseaddr OPEN:/dev/null,creat,trunc
client:
$ time socat -u FILE:10G TCP:$dest_ip:9876
0m15.989s

Und zwei Boxen auf 10 Gbe, etwas ältere Versionen von Netcat (CentOs 6.7), 10 GB Datei:

nc: 0m18.706s (100% cpu, v1.84, no -q option
iperf3: 0m10.013s (100% cpu, but can go up to at least 20Gbe with 100% cpu so not sure it matters)
socat: 0m10.293s (88% cpu, possibly maxed out)

In einer Instanz verwendete netcat also weniger CPU, in der anderen Socat, also YMMV.

Wenn netcat keine "-N -q 0" -Option hat, kann es abgeschnittene Dateien übertragen, seien Sie vorsichtig ... andere Optionen wie "-w 10" können ebenfalls zu abgeschnittenen Dateien führen.

In fast allen diesen Fällen wird die CPU ausgelastet, nicht das Netzwerk. scpDie maximale Geschwindigkeit liegt bei ca. 230 MB / s. Bei 100% iger Auslastung wird ein Kern fixiert.

Iperf3 erstellt leider beschädigte Dateien. Einige Versionen von Netcat scheinen nicht die gesamte Datei zu übertragen, sehr seltsam. Besonders ältere Versionen davon.

Verschiedene Beschwörungsformeln von "gzip als Pipe zu Netcat" oder "mbuffer" schienen auch die CPU mit dem gzip oder mbuffer zu maximieren, führten also nicht zu einer schnelleren Übertragung mit so großen Pipes. lz4 könnte helfen. Außerdem führten einige der von mir versuchten gzip-Pipe-Dateien zu fehlerhaften Übertragungen für sehr große Dateien (> 4 GB).

Eine andere Sache, die besonders für höhere Latenz (?) Funktionieren könnte, ist die Einstellung der TCP-Einstellungen. Hier ist eine Anleitung, in der empfohlene Werte erwähnt werden:

http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm und https://fasterdata.es.net/host-tuning/linux/ (aus einer anderen Antwort) möglicherweise IRQ-Einstellungen: https://fasterdata.es .net / Host-Tuning / 100g-Tuning /

Vorschläge von Linode, fügen Sie zu /etc/sysctl.conf hinzu:

net.core.rmem_max = 268435456 
net.core.wmem_max = 268435456 
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728
net.core.netdev_max_backlog = 250000
net.ipv4.tcp_no_metrics_save = 1
net.core.default_qdisc = fq 

Außerdem möchten sie, dass Sie Folgendes ausführen:

 /sbin/ifconfig eth0 txqueuelen 10000 

Es lohnt sich, nach dem Optimieren noch einmal nachzusehen, um sicherzustellen, dass Änderungen auch keinen Schaden anrichten.

Es kann sich auch lohnen, die Fenstergröße anzupassen: https://iperf.fr/iperf-doc.php#tuningtcp

Bei langsamen (er) Verbindungen kann die Komprimierung jedoch definitiv helfen. Wenn Sie große Pipes haben, hilft eine sehr schnelle Komprimierung möglicherweise bei leicht komprimierbaren Daten, haben es aber nicht ausprobiert.

Die Standardantwort für das "Synchronisieren von Festplatten" besteht darin, die Dateien zu synchronisieren, wobei eine Übertragung nach Möglichkeit vermieden wird.

Eine andere Option: benutze "parallel scp" (irgendwie oder anders), dann werden mehr Kerne verwendet ...

Rogerdpack
quelle