Frage Übertragen Sie 15 TB von kleinen Dateien


Ich archiviere Daten von einem Server zum anderen. Anfangs habe ich angefangen rsync Job. Es dauerte 2 Wochen, um die Dateiliste nur für 5 TB Daten und eine weitere Woche für die Übertragung von 1 TB Daten zu erstellen.

Dann musste ich den Job abbrechen, da wir etwas Zeit auf dem neuen Server brauchen.

Es wurde vereinbart, dass wir es tarieren werden, da wir wahrscheinlich nicht mehr darauf zugreifen müssen. Ich dachte daran, es in 500-GB-Stücke zu brechen. Nachdem ich tar Dann würde ich es durchspielen ssh. Ich benutzte tar und pigz aber es ist immer noch zu langsam.

Gibt es einen besseren Weg, es zu tun? Ich denke beide Server sind auf Redhat. Der alte Server ist Ext4 und der neue ist XFS.

Dateigrößen reichen von wenigen kb bis zu wenigen mb und es gibt 24 Millionen JPEG in 5 TB. Also ich denke ungefähr 60-80 Millionen für 15TB.

edit: Nach dem Spielen mit rsync, nc, tar, mbuffer und pigz für ein paar Tage. Der Engpass wird die Datenträger-IO sein. Da die Daten über 500 SAS-Festplatten und rund 250 Millionen JPEGs verteilt sind. Aber jetzt habe ich von all diesen netten Werkzeugen erfahren, die ich in Zukunft verwenden kann.


73
2017-09-09 15:23


Ursprung


mögliches Duplikat von Linux zu Linux, 10 TB Übertragung? - D34DM347
Eine Option besteht darin, die komprimierten TAR-Dateien auf einem externen Laufwerk zu erstellen und auf das neue System zu übertragen. Die zusätzliche Festplatte beschleunigt das Erstellen der TAR-Dateien (wird nicht auf vorhandene Festplatten im System geschrieben, möglicherweise beim Versuch, 15 TB von ihnen zu lesen) und bindet den neuen Server nicht. - Brian
Gibt es einen besseren Weg, es zu tun? - Ja, Windows Server 2012 R2 DFS-Replikation würde das in ungefähr 10 Stunden vorbereiten. Und es würde die Änderungen synchronisieren und nach dem Neustart wieder aufnehmen. - TessellatingHeckler
@TesselingHeckler: Sie schlagen also vor, dass OP vor der Archivierung von Redhat zu Windows migriert? - Thomas Weller
@ThomasWeller Sie fragten: "Gibt es einen besseren Weg?", Und da ist es. Ich mache keine Empfehlung, dass sie den besseren Weg nutzen. Sie können Befehle in einer Pipe verwenden, die die Unterbrechung nicht wiederherstellen können, den Dateiinhalt nicht überprüfen, den Kopierstatus nicht melden können, zuvor kopierte Blöcke nicht verwenden können, um das Kopieren von Teilen von Dateien zu vermeiden, hat keine impliziten unterstützt das Kopieren mit niedriger Priorität, kann nicht angehalten werden, hat keine Erwähnung des Kopierens von ACLs und benötigt jemanden, der angemeldet bleibt, um ihn auszuführen. Jeder, der mitgeht, könnte jedoch interessiert sein - oder aufgefordert werden, "x tut das unter Linux" zu sagen. - TessellatingHeckler


Antworten:


Ich hatte sehr gute Ergebnisse mit tar, pigz (parallel gzip) und nc.

Quellmaschine:

tar -cf - -C /path/of/small/files . | pigz | nc -l 9876

Zielmaschine:

Extrahieren:

nc source_machine_ip 9876 | pigz -d | tar -xf - -C /put/stuff/here

Archiv aufbewahren:

nc source_machine_ip 9876 > smallstuff.tar.gz

Wenn Sie die Übertragungsrate sehen möchten, leiten Sie einfach durch pv nach dem pigz -d!


62
2017-09-09 16:29



Zu Ihrer Information, Sie können ersetzen pigz mit gzip oder entfernen Sie es ganz, aber die Geschwindigkeit wird deutlich langsamer sein. - h0tw1r3
Wie kann dies akzeptiert werden, wenn OP es bereits versucht hat? tar und pigz? Ich verstehe nicht ... - Thomas Weller
@ThomasWeller wo hast du das er es versucht hat pigz? Aus der Frage sieht es so aus, als ob er es nur versucht hat rsync so weit, und war in Anbetracht verwenden tar um die Daten zu teilen und zu bündeln. Vor allem, wenn er das nicht benutzt hat -z/--compress Option für rsync, pigz könnte theoretisch erheblich helfen. - Doktor J
@ThomasWeller ja tatsaechlich habe ich schon versucht tar und potz aber nicht nc. Ich habe ssh benutzt, also hat es viel mehr Overhead hinzugefügt. - lbanz
@lbanz das heißt das einfach tar produziert nicht schnell genug Daten für pigz um viel CPU für die Komprimierung zu verwenden. Das Lesen vieler kleiner Dateien beinhaltet viel mehr Systemaufrufe, viel mehr Festplattensuchen und viel mehr Kernel-Overhead als das Lesen der gleichen Anzahl von Bytes mit größeren Dateien, und es sieht so aus, als ob Sie auf einer fundamentalen Ebene nur einen Engpaß haben. - hobbs


Ich würde bei der rsync-Lösung bleiben. Modern (3.0.0+) rsync verwendet eine inkrementelle Dateiliste, sodass vor der Übertragung keine vollständige Liste erstellt werden muss. Wenn Sie es neu starten, müssen Sie die gesamte Übertragung nicht erneut durchführen, wenn Probleme auftreten. Durch die Aufteilung der Übertragung nach Top- oder Second-Level-Verzeichnis wird dies noch weiter optimiert. (Ich würde verwenden rsync -a -P und hinzufügen --compress wenn Ihr Netzwerk langsamer ist als Ihre Laufwerke.)


20
2017-09-09 18:44



Ich benutze rsync 2.6.8 auf dem alten Server. Da es sich um eine dieser Boxen handelt, dürfen wir nichts installieren oder aktualisieren, wie vom Hersteller angegeben, oder es erlischt die Garantie. Ich könnte es aktualisieren und sehen, ob es schneller ist. - lbanz
Suchen Sie eine statisch verknüpfte rsync-Binärdatei (oder erstellen Sie sie), und führen Sie sie einfach von zu Hause aus aus. Hoffentlich ruiniert das keine Garantie. - Fox


Richten Sie ein VPN ein (wenn es Internet ist), erstellen Sie ein virtuelles Laufwerk eines Formats auf dem entfernten Server (machen Sie es ext4), mounten Sie es auf dem entfernten Server, dann mounten Sie das auf dem lokalen Server (mithilfe eines Protokolls auf Blockebene wie iSCSI) und verwenden Sie dd oder ein anderes Tool auf Blockebene, um die Übertragung durchzuführen. Sie können dann die Dateien vom virtuellen Laufwerk auf das echte (XFS) Laufwerk kopieren.

Zwei Gründe:

  1. Kein Dateisystem-Overhead, der die Hauptleistungstäter ist
  2. Keine Suche, Sie suchen sequenzielles Lesen / Schreiben auf beiden Seiten

15
2017-09-09 16:17



Das Dateisystem umgehen ist gut. Das Kopieren von Block-Level eines Read-Write-eingehängten Dateisystems ist eine wirklich schlechte Idee. Unmount oder mount zuerst schreibgeschützt. - JB.
Eine 15-TB-Kopie zu haben, ist auch nervig. Das bedeutet, dass der neue Server mindestens 30 benötigt. - Arthur Kay
Wenn der Server LVM verwendet, könnte man einen schreibgeschützten Snapshot des Dateisystems erstellen und stattdessen kopieren. Speicherplatz-Overhead nur für die Änderungen im Dateisystem, die beim Lesen des Snapshots auftreten. - liori


Wenn der alte Server außer Betrieb genommen wird und die Dateien für einige Minuten offline sein können, ist es oft am schnellsten, die Laufwerke einfach aus der alten Box zu ziehen und auf den neuen Server zu übertragen, sie zu mounten (jetzt wieder online) und die Dateien zu kopieren auf den neuen Servern native Festplatten.


9
2017-09-10 03:14



Es ist ungefähr 1PB von 2TB Laufwerke, also ist es viel zu viel. - lbanz


Verwenden Sie mbuffer und wenn es in einem sicheren Netzwerk ist, können Sie den Verschlüsselungsschritt vermeiden.


3
2017-09-09 15:39





(Viele verschiedene Antworten können funktionieren. Hier ist ein anderer.)

Erzeuge die Dateiliste mit find -type f (Dies sollte in ein paar Stunden abgeschlossen sein), teilen Sie es in kleine Stücke und übertragen Sie jedes Stück mit rsync --files-from=....


3
2017-09-10 23:34





Hast du über Sneakernet nachgedacht? Damit meine ich, alles auf ein und dasselbe Laufwerk zu übertragen und dieses Laufwerk dann physisch zu verschieben.

Vor einem Monat hat Samsung eine 16-TB-Festplatte (technisch gesehen: 15,36 TB) vorgestellt, die ebenfalls eine SSD ist: http://www.theverge.com/2015/8/14/9153083/samsung-worlds-largest-hard-drive-16tb

Ich denke, diese Fahrt würde dafür fast ausreichen. Sie müssten immer noch alle Dateien kopieren, aber da Sie keine Netzwerklatenz haben und wahrscheinlich SATA oder eine ähnlich schnelle Technik verwenden können, sollte es ziemlich viel schneller sein.


3
2017-09-12 17:56





Wenn es eine Chance gibt, hohe Erfolgsquote bei der Deduplizierung zu erhalten, würde ich etwas wie verwenden Borgbackup oder Dachboden.

Wenn nicht, überprüfen Sie das netcat + tar +pbzip2 Lösung, passen Sie die Komprimierungsoptionen entsprechend Ihrer Hardware an - prüfen Sie, was der Engpass ist (CPU? Netzwerk? IO?). Das pbzip2 würde sich gut über alle CPUs erstrecken und eine bessere Leistung bieten.


2
2017-09-09 20:38



lzma (xz) dekomprimiert schneller als bzip2 und funktioniert bei den meisten Eingaben gut. Unglücklicherweise, xzDie Multithread-Option ist noch nicht implementiert. - Peter Cordes
Normalerweise benötigt die Komprimierungsstufe mehr Leistung als die Dekomprimierung. Wenn also die CPU der limitierende Faktor ist, würde pbzip2 zu einer besseren Gesamtleistung führen. Die Dekomprimierung sollte den Prozess nicht beeinflussen, wenn beide Maschinen ähnlich sind. - neutrinus
Ja, mein Punkt war, es ist eine Schande, dass es kein Single-Stream-Multi-Thread-LZMA gibt. Obwohl für diesen Anwendungsfall die Übertragung von ganzen Dateisystemen von Daten, pigz wäre wahrscheinlich. sei der langsamste Kompressor, den du verwenden möchtest. Oder auch lz4. (Da ist ein lz4mt Multi-Threaded-für-Single-Stream verfügbar. Es fädelt nicht sehr effizient (erzeugt sehr oft neue Threads), aber es wird eine solide Beschleunigung) - Peter Cordes