Unix-Server-Spiegelungslösung

Unix-Server-Spiegelungslösung

Wir haben drei Server mit Ubuntu Server 10.04 und die Lastverteilung zwischen ihnen erfolgt über DNS. Wir verwenden Django, nginx zur Bereitstellung von Inhalten und PostgresQL als Datenbank.

Für PostgresQL gibt es einige Spiegelungslösungen, aber was ist die beste Möglichkeit, unsere statischen Dateien mithilfe des „Drei-Master“-Schemas zu spiegeln?

Ich schätze, dass die einfache rsync-Verfahrensweise weder skalierbar noch leicht zu warten wäre.

Antwort1

Solange sich die Dateien nicht oft ändern und immer synchronisiert werden müssen, warum nicht rsync? Stellen Sie einfach sicher, dass Sie einen Masterserver haben, auf dem Sie die Dateien bearbeiten. Das erleichtert die Synchronisierung.

Ansonsten könnte ein vernetztes Dateisystem wie NFS funktionieren, oder Sie implementieren etwas wieDRBDum die Dateien immer synchron zu halten.

Antwort2

Es gibt zahlreiche andere Lösungen (afs, unionfs ...), aber rsync funktioniert überraschend gut für die Einwegreplikation und verfügt über eine Selbstheilung – und ist skalierbar, solange Sie Pfade für die Replikation definiert haben (ein einzelner Master reicht für bis zu etwa 5 Slaves aus, darüber hinaus gibt es wahrscheinlich gute Gründe, auf eine mehrstufige Replikation umzusteigen).

Das einzige Problem ist der Zeitpunkt der Replikation. Da Sie Round-Robin-DNS verwenden, haben Sie bereits Serveraffinität. Sie werden also nicht das Problem haben, dass ein Benutzer Server A aktualisiert und die Aktualisierungen dann nicht sehen kann, weil er Server B betrachtet. Verzögerungen bei der Codeverbreitung können jedoch bei Bereitstellungen zu Problemen führen (insbesondere, wenn Ihr Code von DDL-Änderungen an einer gemeinsamen Datenbank abhängig ist).

Wenn Sie unbedingt eine bidirektionale Replikation benötigen (versuchen Sie, dies wenn möglich zu vermeiden), dann wäre ein Echtzeit-Replikationssystem besser geeignet.

Wenn Sie rsync derzeit manuell bzw. über Cron ausführen, könnten Sie inotify verwenden, um rsync bei Dateiänderungen so auszuführen, dass die Verzögerung sehr kurz wird.

C.

Antwort3

Wenn Code in der Produktion eingesetzt wird, sollte er gleichzeitig auf allen Servern eingesetzt werden. Wenn diese Aktion richtig kontrolliert wird, sollte sie als Teil Ihrer Kontrollen gespiegelt werden und eine Technologielösung ist unnötig. Nicht alle Verwaltungslösungen basieren auf Technologie.

OpenEFSist ein Tool, das sowohl Änderungskontrolle als auch Bereitstellungen ermöglicht, was für Sie hilfreich sein könnte. Ich habe vieles davon selbst implementiert, aber für jemanden ohne Grundkenntnisse wäre es ein guter Anfang.

Für statische Server, die nicht in den Bereich der Änderungskontrolle fallen, habe ich rsync in der Vergangenheit als geeignete Lösung empfunden. Normalerweise ist bei Servern, die in diese Kategorie fallen, die Skalierung wahrscheinlich kein Problem, aber wenn doch, dannNFSoderAFSins Spiel kommen könnten.

verwandte Informationen