Sehr große Ordnerstrukturen synchronisieren


14

Wir haben eine Ordnerstruktur in unserem Intranet, die ungefähr 800.000 Dateien enthält, die in ungefähr 4.000 Ordner aufgeteilt sind. Wir müssen dies mit einer kleinen Gruppe von Maschinen in unseren DMZs synchronisieren. Die Tiefe der Struktur ist sehr flach (sie übersteigt niemals zwei Ebenen).

Die meisten Dateien ändern sich nie, jeden Tag gibt es ein paar tausend aktualisierte Dateien und 1-2 tausend neue Dateien. Bei den Daten handelt es sich um historische Berichtsdaten, die dort aufbewahrt werden, wo die Quelldaten gelöscht wurden (dh es handelt sich um abgeschlossene Berichte, für die die Quelldaten so alt sind, dass wir sie archivieren und löschen). Eine einmalige Synchronisierung pro Tag ist ausreichend, da dies in einem angemessenen Zeitraum erfolgen kann. Berichte werden über Nacht generiert und wir synchronisieren als Erstes morgens als geplante Aufgabe.

Da sich so wenige Dateien regelmäßig ändern, können wir natürlich von inkrementellen Kopien erheblich profitieren. Wir haben Rsync ausprobiert, aber es kann bis zu acht bis zwölf Stunden dauern, bis der Vorgang "Dateiliste erstellen" abgeschlossen ist. Es ist klar, dass wir schnell wachsen, wozu rsync fähig ist (der 12-Stunden-Zeitrahmen ist viel zu lang).

Wir haben ein anderes Tool namens RepliWeb verwendet, um die Strukturen zu synchronisieren, und es kann eine inkrementelle Übertragung in etwa 45 Minuten durchführen. Es scheint jedoch, dass wir das Limit überschritten haben. Dateien werden als Löschvorgänge angezeigt, wenn dies nicht der Fall ist (möglicherweise ist eine interne Speicherstruktur erschöpft, wir sind uns nicht sicher).

Hat jemand anderes ein großes Synchronisationsprojekt dieser Art erlebt? Gibt es etwas, das entwickelt wurde, um massive Dateistrukturen wie diese für die Synchronisation zu handhaben?


Haben Sie versucht, die Arbeit auf mehrere Instanzen von rsync aufzuteilen, die gleichzeitig ausgeführt werden? Ich habe kein wirklich gutes Bild von der Verzeichnisstruktur, aber Sie könnten es nach Verzeichnisnamen oder Dateinamen aufteilen.
Kupplung

Wir hatten darüber nachgedacht, aber bei einer so flachen Struktur ist es schwierig, gute Trennlinien zu finden, um die Arbeit aufzuteilen. Kompliziert wird dies durch die Tatsache, dass die Ordner größtenteils sehr ähnlich benannt sind (es gibt eine Namenskonvention, nach der die meisten Ordner mit demselben Anfangssatz von 6 Zeichen beginnen).
MightyE

Haben Sie jemals eine gute Lösung gefunden, Dave? Ich erwäge lsyncd für eine Richt mit 65535 Unter dirs, von denen jeder könnte 65 ^ 16 Dateien.
Mike Diehn

1
@MikeDiehn Ich habe noch nie ein Werkzeug gefunden, mit dem ich total zufrieden war. Wir haben dieses proprietäre RepliWeb-Tool, um den Fehler zu beheben, bei dem Dateien als Löschvorgänge angesehen wurden. Dies war eine übergelaufene interne Struktur. Ich habe diesen Job vor Jahren verlassen, ich gehe davon aus, dass sie das immer noch verwenden. Wenn Ihre Verzeichnisse für Ihre Zwecke angemessen verteilt sind, können Sie sich für eine Lösung von Ryan entscheiden. Es werden keine Löschvorgänge auf oberster Ebene bemerkt, aber 65535 Unterverzeichnisse legen mir nahe, dass Sie diese wahrscheinlich nicht haben.
MightyE

Antworten:


9

Wenn Sie den vom Dateisystem zuletzt geänderten Zeitstempeln vertrauen können, können Sie die Dinge beschleunigen, indem Sie Rsync mit dem UNIX / Linux-Dienstprogramm 'find' kombinieren. 'find' kann eine Liste aller Dateien zusammenstellen, die die letzten Änderungen des letzten Tages aufweisen, und dann NUR diese verkürzte Liste von Dateien / Verzeichnissen an Rsync leiten. Dies ist viel schneller, als wenn Rsync die Metadaten jeder einzelnen Datei auf dem Absender mit dem Remote-Server vergleicht.

Kurz gesagt, der folgende Befehl führt Rsync NUR für die Liste der Dateien und Verzeichnisse aus, die sich in den letzten 24 Stunden geändert haben: (Rsync prüft KEINE anderen Dateien / Verzeichnisse.)

find /local/data/path/ -mindepth 1 -ctime -0 -print0 | xargs -0 -n 1 -I {} -- rsync -a {} remote.host:/remote/data/path/.

Falls Sie mit dem Befehl 'find' nicht vertraut sind, durchsucht er einen bestimmten Verzeichnis-Teilbaum nach Dateien und / oder Verzeichnissen, die den von Ihnen angegebenen Kriterien entsprechen. Zum Beispiel dieser Befehl:

find . -name '\.svn' -type d -ctime -0 -print

startet im aktuellen Verzeichnis (".") und durchsucht alle Unterverzeichnisse nach:

  • beliebige Verzeichnisse ("-type d"),
  • benannt ".svn" ("-name '.svn'"),
  • mit Metadaten, die in den letzten 24 Stunden geändert wurden ("-ctime -0").

Es wird der vollständige Pfadname ("-print") aller Elemente ausgegeben, die diesen Kriterien in der Standardausgabe entsprechen. Die Optionen '-name', '-type' und '-ctime' heißen "tests" und die Option '-print' heißt "action". Die Manpage für 'find' enthält eine vollständige Liste der Tests und Aktionen.

Wenn Sie wirklich clever sein möchten, können Sie den 'find'-Befehl' -cnewer'-Test anstelle von '-ctime' verwenden, um diesen Prozess fehlertoleranter und flexibler zu gestalten. '-cnewer' testet, ob für jede Datei / jedes Verzeichnis in der Struktur die Metadaten vor kurzem geändert wurden, als für eine Referenzdatei. Verwenden Sie 'touch', um die Referenzdatei des nächsten Laufs zu Beginn jedes Laufs zu erstellen, direkt vor dem Befehl 'find ... | Befehl rsync ... 'wird ausgeführt. Hier ist die grundlegende Implementierung:

#!/bin/sh
curr_ref_file=`ls /var/run/last_rsync_run.*`
next_ref_file="/var/run/last_rsync_run.$RANDOM"
touch $next_ref_file
find /local/data/path/ -mindepth 1 -cnewer $curr_ref_file -print0 | xargs -0 -n 1 -I {} -- rsync -a {} remote.host:/remote/data/path/.
rm -f $curr_ref_file

Dieses Skript erkennt automatisch, wann es zuletzt ausgeführt wurde, und überträgt nur Dateien, die seit dem letzten Ausführen geändert wurden. Dies ist zwar komplizierter, schützt Sie jedoch vor Situationen, in denen Sie den Job aufgrund von Ausfallzeiten oder anderen Fehlern möglicherweise länger als 24 Stunden nicht ausgeführt haben.


Dies ist eine äußerst clevere Lösung! Ich denke du meinst es touch $next_ref_fileam Ende? Wir sind jedoch nicht in der Lage, mit gelöschten Pfaden umzugehen (selbst diese statischen Archivberichte werden mit der Zeit so alt, dass sie archiviert und gelöscht werden). Das könnte aber kein Show Stopper sein.
MightyE

Ich stelle jedoch fest, dass gerade find . -ctime 0in dieser Verzeichnisstruktur ziemlich langsam ist ( ich warte immer noch darauf, bis der Vorgang abgeschlossen ist, um seine Zeit zu melden). Das entmutigt mich ein bisschen, weil es so aussieht, als wäre dies eine ziemlich einfache Operation, die wahrscheinlich die Messlatte für die schnellste setzt, die wir für diesen Job erwarten können. Es kann vorkommen, dass die Festplatten-E / A hier der begrenzende Faktor ist.
MightyE

Was das Scriptlet betrifft, habe ich einen Fehler gemacht. Ich meinte 'touch' auf 'next_ref_file' (NICHT 'curr_ref_file') ausführen, bevor 'find ... | Befehl rsync ... '. (Ich werde meine Antwort
Ryan B. Lynch

3
Zum langsamen Befehl 'find': Welches Dateisystem verwenden Sie? Wenn Sie Ext3 verwenden, sollten Sie zwei FS-Optimierungen in Betracht ziehen: 1) Führen Sie 'tune2fs -O dir_index <DEVICE_NODE>' aus, um die 'dir_index'-Funktion von Ext3 zu aktivieren und den Zugriff auf Verzeichnisse mit großer Dateizahl zu beschleunigen. 2) Führen Sie "mount -o remount, noatime, nodiratime" aus, um die Aktualisierung der Zugriffszeit zu deaktivieren, wodurch das Lesen im Allgemeinen beschleunigt wird. 'dumpe2fs -h <DEVICE_NODE> | grep dir_index 'teilt Ihnen mit, ob' dir_index 'bereits aktiviert ist (in einigen Distributionen ist dies die Standardeinstellung) und' mount | grep <DEVICE_NODE> 'informiert Sie über Aktualisierungen der Zugriffszeit.
Ryan B. Lynch

Leider ist es NTFS - Windows 2003 Server, das Cygwin für den Befehl find verwendet. Ich werde mich an diese Tuning-Optionen (exzellente Ratschläge) für ext3 erinnern, falls wir auf einem unserer Debian-Cluster jemals auf etwas Ähnliches stoßen sollten.
MightyE

7

Versuchen Sie unisono , es wurde speziell entwickelt, um dieses Problem zu lösen, indem die Änderungslisten (Building File List) lokal auf jedem Server gespeichert werden, wodurch die Zeit für die Berechnung des Deltas und die Reduzierung des Betrags, der anschließend über die Leitung gesendet wird, verkürzt wird.


Ich versuche es mit Unison. In der Phase "Auf der Suche nach Änderungen" ist der Vorgang nun etwa 2 Stunden lang ausgeführt worden, und basierend auf den Dateien, an denen er derzeit arbeitet, sieht es so aus, als wäre er etwa zur Hälfte abgeschlossen (also insgesamt 4 Stunden, bevor die Übertragung beginnt). Es sieht so aus, als wäre es besser als rsync, aber immer noch außerhalb unseres gewünschten Betriebsfensters.
MightyE

2
Wenn Sie zum ersten Mal einen Index auf beiden Seiten erstellen, sind die Neuerstellungszeiten ähnlich wie bei rsync, da jede Datei mit einem Hash versehen werden muss. Sobald dies erledigt ist, verwendet unison die letzte Änderungszeit des Verzeichnisses, um festzustellen, wann sich eine Datei geändert hat, und muss diese Datei nur noch nach Änderungen durchsuchen.
Dave Cheney

Leider war ich das Opfer eines eifrigen Operations-Administrators, der meine Sitzung zwang, bevor der Katalog fertiggestellt war (wir begrenzen die Anzahl gleichzeitiger Anmeldungen auf Produktionsserver). Ich habe die Fortschritte bei der Erstellung des ersten Katalogs verloren und muss von vorne beginnen. Ich werde dich wissen lassen, wie es geht.
MightyE

Es dauert ungefähr 2 Stunden, bis der erste Katalog erstellt wurde, um nach Änderungen zu suchen. Ich bin ziemlich überrascht, wie viel RAM Unison dafür verwendet. Für unsere Dateisammlung verwendet der Quellserver 635M und der Remote-Client 366M. Das Synchronisieren mehrerer Maschinen in einem Cluster wäre besonders für den Quellserver ein ziemlich großer Aufwand!
MightyE

1
Können Sie Ihre Daten so strukturieren, dass Sie die Daten, die sich in letzter Zeit geändert haben, leicht identifizieren können? Dh im Format Jahr / Monat / Tag / ... speichern?
Dave Cheney


2

Wenn Sie den Schalter -z bei rsync verwenden, versuchen Sie, ihn ohne auszuführen. Aus irgendeinem Grund habe ich gesehen, dass dies sogar die anfängliche Aufzählung von Dateien beschleunigt.


Wir haben es mit und ohne -z versucht. Es schien keinen Einfluss auf die Ausführungsdauer der "Building File List" zu haben.
MightyE

2

Wenn Sie -z aus dem Befehl rsync entfernen, bei dem es sich nicht um eine Komprimierung handelt, wurde die Liste der empfangenen Dateien um ein Vielfaches schneller, und wir mussten etwa 500 GB übertragen. Davor dauerte es einen Tag mit dem Schalter -z.

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.