Bidirektionale Echtzeitsynchronisation eines großen Dateibaums zwischen zwei entfernten Linux-Servern


21

Mit großem Dateibaum meine ich ungefähr 200.000 Dateien, die ständig wachsen. Eine relativ kleine Anzahl von Dateien wird jedoch in einer bestimmten Stunde geändert.

Mit bidirektional meine ich, dass Änderungen auf beiden Servern auftreten können und auf den anderen übertragen werden müssen, sodass rsync nicht geeignet erscheint.

Mit Ferne meine ich, dass sich die Server beide in Rechenzentren befinden, aber geografisch voneinander entfernt sind. Derzeit gibt es nur 2 Server, die sich jedoch im Laufe der Zeit erweitern können.

In Echtzeit ist es in Ordnung, dass zwischen den Synchronisierungen eine kurze Wartezeit liegt, aber das Ausführen eines Cron alle 1-2 Minuten scheint nicht richtig zu sein, da sich ein sehr kleiner Teil der Dateien in einer bestimmten Stunde ändern kann, geschweige denn in einer Minute.

BEARBEITEN : Dies läuft auf VPS, so dass ich möglicherweise auf die Arten von Kernel-Level-Sachen beschränkt bin, die ich tun kann. Außerdem sind die VPS nicht ressourcenreich, weshalb ich Lösungen, die viel RAM erfordern (wie Gluster?), Scheuen würde.

Was ist der beste / am meisten akzeptierte Ansatz, um dies zu erreichen? Dies scheint ein allgemeines Bedürfnis zu sein, aber ich konnte noch keinen allgemein akzeptierten Ansatz finden, was überraschend war. (Ich suche die Sicherheit der Massen. :)

Ich bin auf lsyncd gestoßen , um eine Synchronisierung auf der Dateisystem-Änderungsstufe auszulösen. Das scheint klug, wenn auch nicht sehr häufig, und ich bin ein bisschen verwirrt von den verschiedenen lsyncd-Ansätzen. Es gibt nur die Verwendung von lsyncd mit rsync, aber es scheint, dass dies für die Bidirektionalität fragil ist, da rsync keine Vorstellung von Arbeitsspeicher hat (z. B. zu wissen, ob eine gelöschte Datei auf A auf B gelöscht werden soll oder ob es sich um eine neue Datei auf B handelt das sollte nach A) kopiert werden. lipsync scheint nur eine lsyncd + rsync-Implementierung zu sein, oder?

Dann gibt es lsyncd mit csync2 , wie folgt : https://icicimov.github.io/blog/devops/File-system-sync-with-Csync2-and-Lsyncd/ ... Ich neige zu diesem Ansatz, aber csync2 ist ein bisschen schrullig, obwohl ich es erfolgreich getestet habe. Ich bin größtenteils besorgt, dass ich nicht viele Community-Bestätigungen für diese Methode finden konnte.

Die Leute hier scheinen Unison sehr zu mögen, aber es scheint, dass es sich nicht mehr in der aktiven Entwicklung befindet und es nicht klar ist, dass es einen automatischen Trigger wie lsyncd hat.

Ich habe gesehen, wie Gluster erwähnt wurde, aber vielleicht zu viel für das, was ich brauche?

UPDATE: Letztendlich habe ich die ursprüngliche Lösung gewählt, die ich erwähnt habe: lsyncd + csync2. Es scheint ganz gut zu funktionieren, und ich mag den architektonischen Ansatz, dass die Server sehr locker verbunden sind, sodass jeder Server unabhängig von der Verbindungsqualität für sich unbegrenzt arbeiten kann.


Welche Art von Änderungen müssen Sie handhaben? EG Erstellung, Löschung, Änderung.
Sciurus

Erwarten Sie auch Konflikte? Könnte die gleiche Datei auf beiden Servern geändert werden?
Sciurus

Alle Änderungen: Erstellen, Löschen, Ändern. Konflikte können auftreten, sollten aber selten sein. Es würde mir nichts ausmachen, wenn ich einfach eine Benachrichtigung über einen Konflikt erhalte, den ich dann manuell lösen muss.
17.

Antworten:


5

DRBD im Dual-Primary- Modus mit einem Proxy ist eine Option.


Der Proxy scheint weder Open Source noch frei zu sein, oder? Ich bin mir nicht sicher, ob ich die Konsequenz verstehe, wenn kein Proxy im asynchronen Modus ist: Wenn während einer längeren Ausfallzeit kein Proxy vorhanden ist, könnte sich der [kleine?] Ausgabepuffer füllen und die Synchronisierung geht verloren. Ist es schwer, sich davon zu erholen?
Donnerstag,

Siehe meine Antwort oben. Ich glaube nicht, dass der Proxy das ist, was Sie brauchen. Auch während einer kleinen Ausfallzeit markiert das DRBD-Meta-Gerät "Dirty" -Blöcke und überträgt diese, nachdem die Verbindung wieder hergestellt wurde. Ich denke, der Hauptunterschied zwischen Proxy- und Async-Modus ist, dass der Async-Modus einen maximalen Puffer von einigen MB verwendet. Danach wird synchronisiert, bevor der Puffer erneut gefüllt wird. Der Proxy ermöglicht wahrscheinlich einen größeren Puffer (erforderlich, wenn Sie eine große Latenz haben oder lokal viel schneller schreiben können als remote).
Nils

2

Warum nicht das gleiche Dateisystem über NFS synchronisieren?


2
NFS ist schrecklich, nur schrecklich. Alles wäre besser als NFS
AliGibbs

2
Einer der Hauptpunkte des Multi-Server-Setups ist Failover / Redundanz. Ein Server muss also ohne den anderen weiterarbeiten können.
14.

Das hättest du dann in deiner Frage erwähnen sollen - keine Notwendigkeit, eine vernünftige Antwort abzustimmen!
Bart B

Ich habe es nicht abgelehnt - jemand anderes hat es getan. Aber ja, das hätte ich zuerst erwähnen sollen.
14.

@Bart: Nun - er hat erwähnt, dass es an zwei entfernten Standorten gleichzeitigen Zugriff gibt. Selbst wenn Sie HA-NFS einrichten, ist dies eine schlechte Lösung, da eine Seite während des NFS-Zugriffs unter Latenz leidet. Und ich habe auch nicht abgelehnt. Aber ich war lange genug NFS-Administrator, um AliGibbs zu unterstützen. : - /
Nils

2

Die Implementierung eines verteilten Dateisystems ist wahrscheinlich besser, als dies zusammen mit Tools und Skripten zu hacken, insbesondere wenn der Cluster von Servern wächst. Sie werden auch in der Lage sein, mit einem heruntergefahrenen Knoten besser umzugehen.

Ich denke nicht, dass Gluster (oder AFS) übertrieben ist.


Gluster benötigt 1GB RAM? gluster.com/community/documentation/index.php/... ... Ich bin auch auf einem VPS, so dass ich bin mir nicht sicher über Kernel - Ebene Änderungen vornehmen , dass AFS erforderlich machen könnte. Aber ich beginne zu bemerken, dass ein richtig verteiltes fs der bessere Weg ist.
Donnerstag,

Tut mir leid, dass Sie VPS-Hosts verwendet haben. Der Speicherbedarf von Servern und Clients ist nicht gering und kann erheblich ansteigen. DRBD klingt angemessener.

AFS ist der richtige Weg.
Anthony Giorgio

2

In Ihrem Fall würde ich eine Kombination aus DRBD im Dual-Primary-Modus und gfs oder ocfs empfehlen.

Der Nachteil von DRBD im Dual-Primary-Modus ist, dass es im synchronen Modus ausgeführt wird. Aber die Schreibgeschwindigkeit scheint hier nicht wichtig zu sein, oder?

Eine Alternative zu DRBD könnte ein Soft-Raid1 mit vielen (2+) iSCSI-Zielen sein - ich würde jedoch DRBD mit zwei Knoten bevorzugen.


1
Der synchrone Modus wäre schlecht - ich brauche ihn nicht und möchte die Leistung nicht beeinträchtigen, da die Server über ein WAN über Kontinente hinweg verbunden sind. Kannst du nicht Dual-Primary im Async-Modus haben?
Donnerstag,

Ich verwende derzeit DRBD 8.3.5 - dort muss man sich im Sync-Modus ("C") befinden, um in den Dual-Primary-Modus zu gelangen. Ich habe keine persönlichen Erfahrungen mit DRBD-Proxy, aber es scheint ähnlich zu sein wie Veritas Volume Replicator - aber dies ist wahrscheinlich nicht geeignet, da Sie Schreibzugriff auf beiden Seiten wünschen. Der Synchronisationsmodus auf Blockebene ist möglicherweise nicht so schlecht wie Sie denken - möglicherweise können gfs und / oder ocfs Schreibvorgänge puffern.
Nils

Ich habe gerade einen Artikel über GFS2 und OCFS2 gelesen. Davon ausgehend scheint OCFS2 einen gepufferten Dateisystemzugriff zu unterstützen. In diesem Artikel wird GFS2 empfohlen, da es älter ist. Siehe RedHat Dokumentation auf GFS2 Einzelheiten über GFS2 - es Pufferung verwendet, auch - aber Sie sollten verschiedene Verzeichnisse für gleichzeitiges Schreiben verwenden , um die beste Leistung zu bekommen.
Nils

0

Wie oben gezeigt, gibt es viele Lösungen, jede mit ihren Vor- und Nachteilen.

Ich denke, ich würde in Betracht ziehen, den gesamten Baum der Versionskontrolle zu unterstellen ( z. B. Subversion ) und in regelmäßigen Abständen in Cron-Jobs von beiden Servern einzuchecken / zu aktualisieren.


0

Nachdem ich soeben eine Suche in Bezug auf das Gleiche beendet habe, gehe ich mit Glanz davon. Ich habe jedoch keine Leistungstests durchgeführt oder gefunden.

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.