it-swarm.com.de

Übertragen Sie 15 TB winziger Dateien

Ich archiviere Daten von einem Server auf einen anderen. Anfangs habe ich einen rsync Job gestartet. Es dauerte 2 Wochen, bis die Dateiliste nur für 5 TB Daten) und eine weitere Woche für die Übertragung von 1 TB Daten) erstellt wurde.

Dann musste ich den Job beenden, da wir auf dem neuen Server einige Ausfallzeiten benötigen.

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 zerlegen. Nachdem ich es tar hatte, wollte ich es durch ssh kopieren. Ich habe tar und pigz verwendet, aber es ist immer noch zu langsam.

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

Die Dateigrößen reichen von wenigen KB bis zu wenigen MB, und 5 TB enthalten 24 Millionen JPEGs. Ich schätze also ungefähr 60-80 Millionen für 15 TB.

edit: Nachdem du ein paar Tage mit rsync, nc, tar, mbuffer und pigz gespielt hast. Der Engpass wird die Festplatten-E/A sein. Da die Daten auf 500 SAS-Festplatten und rund 250 Millionen JPEGs) verteilt sind, habe ich jetzt alle diese Nice-Tools kennengelernt, die ich in Zukunft verwenden kann.

80
lbanz

Ich habe sehr gute Ergebnisse mit tar, pigz (paralleles gzip) und nc erzielt.

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 pv nach pigz -d!

65
h0tw1r3

Ich würde mich an die rsync-Lösung halten. Modernes (3.0.0+) rsync verwendet eine inkrementelle Dateiliste, sodass vor der Übertragung keine vollständige Liste erstellt werden muss. Ein Neustart erfordert also nicht, dass Sie bei Problemen die gesamte Übertragung erneut durchführen müssen. Durch Aufteilen der Übertragung nach Verzeichnis der obersten oder zweiten Ebene wird dies noch weiter optimiert. (Ich würde rsync -a -P Verwenden und --compress Hinzufügen, wenn Ihr Netzwerk langsamer als Ihre Laufwerke ist.)

21
Fox

Richten Sie ein VPN ein (falls das Internet vorhanden ist), erstellen Sie ein virtuelles Laufwerk in einem bestimmten Format auf dem Remote-Server (machen Sie es ext4), hängen Sie es auf dem Remote-Server an, dann mounten Sie das auf dem lokalen Server (mit ein Protokoll auf Blockebene wie iSCSI) und verwenden Sie dd oder ein anderes Tool auf Blockebene, um die Übertragung durchzuführen. Sie können die Dateien dann nach Belieben vom virtuellen Laufwerk auf das reale Laufwerk (XFS) kopieren.

Zwei Gründe:

  1. Kein Dateisystem-Overhead, der der Hauptschuldige an der Leistung ist
  2. Kein Suchen, Sie betrachten sequentielles Lesen/Schreiben auf beiden Seiten
15
Arthur Kay

Wenn der alte Server außer Betrieb genommen wird und die Dateien einige Minuten lang offline sein können, ist es oft am schnellsten, die Laufwerke einfach aus der alten Box zu ziehen und sie mit dem neuen Server zu verbinden, sie bereitzustellen (jetzt wieder online) und die Dateien zu kopieren auf die neuen Server native Festplatten.

9
Robin Hammond

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

vor ungefähr einem Monat hat Samsung ein Laufwerk mit 16 TB (technisch gesehen 15,36 TB)) vorgestellt, bei dem es sich auch um eine SSD handelt: http://www.theverge.com/2015/ 8/14/9153083/samsung-world-größte-festplatte-16tb

Ich denke, dieses Laufwerk würde genau das tun. 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 viel schneller sein.

3
Nzall

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

3
JamesRyan

(Viele verschiedene Antworten können funktionieren. Hier ist eine andere.)

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

3
pts

Sie verwenden RedHat Linux, dies würde also nicht zutreffen, aber als weitere Option:

Ich hatte großen Erfolg mit ZFS, um Millionen von Dateien zu speichern, da Inodes kein Problem darstellen.

Wenn dies eine Option für Sie wäre, könnten Sie Snapshots erstellen und zfs verwenden, um inkrementelle Updates zu senden. Ich hatte viel Erfolg mit dieser Methode, um Daten zu übertragen und zu archivieren.

ZFS ist in erster Linie ein Solaris-Dateisystem, befindet sich jedoch in den Illumos (Open Source-Fork von Suns OpenSolaris). Ich weiß, dass es auch etwas Glück gab, ZFS unter BSD und Linux (mit FUSE?) Zu verwenden - aber ich habe keine Erfahrung damit.

2
sleepyweasel

Wenn es eine Chance gibt, bei der Deduplizierung eine hohe Erfolgsquote zu erzielen, würde ich so etwas wie borgbackup oder Attic verwenden.

Wenn nicht, überprüfen Sie die Lösung netcat + tar + pbzip2 , passen Sie die Komprimierungsoptionen an Ihre Hardware an - überprü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
neutrinus

Starten Sie einen rsync -Dämon auf dem Zielcomputer. Dies beschleunigt den Übertragungsprozess erheblich.

1
Heiko Wiesner