Ich habe einen Server, der ein Verzeichnis mit ca. 7 Millionen Dateien (hauptsächlich Bilder) von seiner lokalen Festplatte an Netzwerkclients exportiert überNFS.
Ich muss der HA zuliebe ein zweites hinzufügen und es mit dem ersten synchron halten, mit so wenig Delta wie möglich zwischen den beiden.
Untersuchungen legen nahe,lsyncdoder andereinoffiziell-basierte Lösungen dafür, aber angesichts der Anzahl der Dateien, die dieinoffiziellUhren dauert eine Ewigkeit. Das Gleiche gilt fürrsync.
Andere mögliche Lösungen scheinendrdboder ClusterDateisystemewie zum BeispielcephoderAbonnieren, aber ich habe damit keine Erfahrung und weiß nicht, welches besser geeignet wäre und mit so vielen Dateien gut zurechtkäme und dabei noch eine ordentliche Leistung böte.
Beachten Sie, dass die Aktivität hauptsächlich aus Lesevorgängen und nur wenigen Schreibvorgängen besteht.
Antwort1
Ich neige dazu, eine datenunabhängige Replikation wie drbd vorzuschlagen. Die große Anzahl von Dateien führt dazu, dass alles, was auf einer höheren Ebene als „Blockspeicher“ ausgeführt wird, übermäßig viel Zeit damit verbringt, den Baum zu durchlaufen – wie Sie bei der Verwendung von rsync oder beim Erstellen von inotify-Überwachungen festgestellt haben.
Die Kurzfassung meiner persönlichen Geschichte, die das untermauert: Ich habe Ceph nicht verwendet, bin mir aber ziemlich sicher, dass dies aufgrund seiner Ähnlichkeit mit Gluster nicht zu ihrem Hauptzielmarkt gehört. Ich habe jedoch in den letzten Jahren versucht, diese Art von Lösung mit Gluster zu implementieren. Die meiste Zeit über lief es trotz mehrerer wichtiger Versionsupdates, aber ich hatte endlose Probleme. Wenn Ihr Ziel eher Redundanz als Leistung ist, ist Gluster möglicherweise keine gute Lösung. Insbesondere wenn Ihr Nutzungsmuster viele stat()-Aufrufe aufweist, funktioniert Gluster nicht wirklich gut mit der Replikation. Dies liegt daran, dass stat-Aufrufe an replizierte Volumes an alle replizierten Knoten gehen (eigentlich „Bausteine“, aber Sie werden wahrscheinlich nur einen Baustein pro Host haben). Wenn Sie beispielsweise eine 2-Wege-Replikation haben, wartet jeder stat() von einem Client auf eine Antwort von beiden Bausteinen, um sicherzustellen, dass aktuelle Daten verwendet werden. Dann haben Sie auch den FUSE-Overhead und das Fehlen von Caching, wenn Sie das native Gluster-Dateisystem für Redundanz verwenden (anstatt Gluster als Backend mit NFS als Protokoll und Automounter für Redundanz zu verwenden, was aus dem stat()-Grund immer noch Mist ist). Gluster eignet sich jedoch sehr gut für große Dateien, bei denen Sie Daten auf mehrere Server verteilen können; die Datenaufteilung und -verteilung funktioniert gut, denn dafür ist es wirklich gedacht. Und die neuere Replikation im RAID10-Stil ist leistungsfähiger als die älteren, direkt replizierten Volumes. Aber basierend auf Ihrem Nutzungsmodell würde ich davon abraten.
Bedenken Sie, dass Sie wahrscheinlich eine Möglichkeit finden müssen, Master-Wahlen zwischen den Maschinen durchzuführen oder verteilte Sperren zu implementieren. Die gemeinsam genutzten Blockgerätelösungen erfordern ein Dateisystem, das Multi-Master-fähig ist (wie GFS), oder erfordern, dass nur ein Knoten das Dateisystem schreibgeschützt mountet. Dateisysteme mögen es im Allgemeinen nicht, wenn Daten auf der Ebene des Blockgeräts darunter geändert werden. Das bedeutet, dass Ihre Clients erkennen können müssen, welcher der Master ist, und Schreibanforderungen dorthin leiten müssen. Das kann sich als sehr lästig erweisen. Wenn GFS und seine gesamte unterstützende Infrastruktur eine Option ist, könnte DRBD im Multi-Master-Modus (sie nennen es „Dual Primary“) gut funktionieren. https://www.drbd.org/en/doc/users-guide-83/s-dual-primary-modefür weitere Informationen hierzu.
Egal, welche Richtung Sie einschlagen, Sie werden wahrscheinlich feststellen, dass es immer noch ziemlich mühsam ist, dies in Echtzeit durchzuführen, ohne einem SAN-Unternehmen einfach eine Menge Geld zu geben.
Antwort2
Ich bin mit Hilfe des Proxmox VE-Setups von rsync zu Ceph gewechselt.
Jetzt verwalte ich 14 TB in einem Cluster mit Live-Replikation. Seit fast 4 Jahren.