Ich habe die Aufgabe, zwei CentOS 7-Server zu erstellen, auf denen nicht nur die Datenbanken, sondern auch Dateien repliziert werden. Jetzt ist mein Problem, dass es wahrscheinlich Hunderttausende, wenn nicht Millionen von Dateien mit einer Vielzahl von Größen von einigen KBytes bis ~1 GByte geben wird.
Ich habe gelesen über
- Inschrift
- Abonnieren
- Git-Anhang
- ChironFS
Jetzt möchte ich Sie nach Ihren Erfahrungen mit diesen Programmen fragen, wenn Sie sie bereits verwendet haben oder derzeit verwenden. Wie ist die Leistung bei Dateiänderungen in Bezug auf Kopien und Löschungen? Ich habe große Angst davor, rsync zu verwenden, da es meiner Erfahrung nach bei vielen kleinen Dateien nicht sehr schnell ist und ich es daher nicht wirklich für eine Echtzeit-Dateireplikation verwenden kann. Oder liege ich falsch? Bitte beweisen Sie mir das Gegenteil. :)
Oder brauche ich vielleicht einen 3. und 4. Server als Dateiserver? Wenn ja, bleibt die Frage: Wie repliziere ich die Dateien in Echtzeit zwischen den beiden Servern?
Prost!
Antwort1
Wenn sich Ihre Server im selben LAN befinden, ist ein Cluster-Dateisystem (z. B. GlusterFS) oder eine gemeinsam genutzte Speicherlösung (z. B. über NFS) die bessere Wahl.
Wenn sich Ihre Server an verschiedenen Standorten befinden und nur über eine WAN-Verbindung verfügen, funktioniert die obige Lösung nicht gut. In diesem Fall undwenn Sie nur eine Einwegreplikation benötigen(d. h. vom aktiven zum Backup-Server) lsyncdist eine gute Lösung. Eine weitere Lösung ist csync2. Schließlich besteht eine weitere Möglichkeit darin, zu verwenden DRBD + DRBD Proxy(bitte beachten Sie, dass die Proxy-Komponente ein kommerzielles Plugin ist).
Wenn Ihre Server nur über eine WAN-Verbindung verfügen undSie benötigen eine bidirektionale Replikation(d. h.: beide Server sind gleichzeitig aktiv), gibt es im Grunde kein Patentrezept. Ich werde einige Möglichkeiten auflisten, aber ich bin weit davon entfernt, ein ähnliches Setup zu empfehlen:
unisonmit seinem Echtzeit-Pluginpsync, das ich genau zur Lösung eines ähnlichen Problems geschrieben habe (aber bitte beachten Sie, dass es seine eigenen Eigenheiten hat, und ich bietekeine Unterstützungdafür)syncthingmit seinem Echtzeit-Plugin (das allerdings erhebliche Einschränkungen hat, da es weder ACLs noch den Eigentümer/die Gruppe der Datei speichert)
Antwort2
Ich verwende das ZFS-Dateisystem und nutze seine Replikation auf Blockebene mithilfe des ZFS-Sende-/Empfangsframeworks.
Ich verwende ein praktisches Skript namenssynoidum eine regelmäßige Synchronisierung der Dateisysteme in Intervallen von 15 Sekunden bis stündlich oder täglich durchzuführen, je nach Bedarf.
Die Replikation auf Blockebene ist für den von Ihnen erwähnten Datensatz sauberer und genauer als rsync.
Antwort3
Meiner Erfahrung nach bieten verteilte Dateisysteme einfache Replikationsmechanismen für Anwendungen. Allerdings leiden sie unter schlechter Leistung, insbesondere wenn Verzeichnisse sehr groß werden und zu viele kleine Dateien enthalten. Dies ist zu erwarten, da sie mit Sperren/gemeinsamem Zugriff von mehreren Standorten/Rechnern aus umgehen müssen.
Rsync-ähnliche Methoden ermöglichen in manchen Fällen eine akzeptable Replikation mit etwas Verzögerung. Sie beeinträchtigen die Anwendungsleistung beim Lesen/Schreiben replizierter Ordner nicht.
Ich denke, eine bessere Lösung ist es, gemeinsam genutzten Speicher bereitzustellen (sofern erschwinglich), auf den von einem Server aus zugegriffen werden kann. Ein weiterer Standby-Server ist bereit, den freigegebenen Ordner bereitzustellen, wenn der erste ausfällt. Es besteht keine Notwendigkeit, Daten zwischen Servern zu replizieren.
Antwort4
Danke für die Ideen. Ich habe sie alle überprüft und getestet und bleibe bei lsyncd.
Gründe dafür:
- Extrem einfache Installation
- Extrem einfache Einrichtung
- Unterstützt sowohl unidirektionale als auch bidirektionale Replikation