Die Architektur

Die SKOOR Engine verwendet eine PostgreSQL-Datenbank, um ihre Konfigurationsdaten sowie ihre historischen Werte und Verlaufsdaten zu speichern. Sie unterstützt die Verwendung eines Primär-/Standby- Setups, um den Datenbankinhalt kontinuierlich zu replizieren. Dabei werden PostgreSQLs eigene Replikationsmethoden verwendet, was bedeutet, dass eine exakte Kopie der Datenbank auf dem Primärserver auf dem Standby gespeichert wird und alle Aktualisierungen der Datenbank auf Server Primärserver sofort auf den Standby repliziert werden. Der Primärserver puffert die SQL-Anweisungen in einem Binärprotokoll, der Standby- Server fordert diese Anweisungen vom Server Server .

Dies gewährleistet kurze Ausfallzeiten bei Hardwarefehlern. Es schützt jedoch NICHT vor Pilotfehlern wie fehlerhaften Löschanweisungen, die sofort mit dem Standby synchronisiert werden. Die Replikation ersetzt keine regelmäßigen Backups.

Die folgende Abbildung zeigt ein Beispiel für ein Standardreplikationslayout.

Im Standardbetrieb trägt der Primärserver die gesamte Last, alle Benutzeranfragen werden vom Apache-Webserver auf dem Primärserver beantwortet, Messdaten werden von den Kollektoren an den aktuellen Primärserver geliefert und in der Datenbank gespeichert. Die Dienste eranger- Server , eranger- Kollektor und eranger-Report laufen NICHT auf dem Standby Server Server .

Hauptmerkmale des Replikations-Setups

• Die Replikation kann sogar mit externen SKOOR- Kollektoren durchgeführt werden.

• Wenn zuvor eine Replikation durchgeführt wurde, ist ein großer Teil der Datenbankdateien wahrscheinlich bereits synchron. Das Skript überträgt KEINE alten Tabellen, die bereits synchron sind. Dies spart Netzwerkbandbreite, wenn eine Neuinitialisierung durchgeführt werden muss.

• Es gibt kein automatisches Failover vom Primär- zum Standby-Server . Diese Entscheidung wurde so konzipiert, dass sie einem Menschen überlassen bleibt. Das Skript unterstützt jedoch einen nicht-interaktiven Modus, der ein Failover durch ein Skript ermöglichen würde. (Option -f).

• Möglichkeit, das Primärsystem vom Standby aus zu überwachen (unabhängig von SKOOR) und eine E-Mail zu senden, sobald festgestellt wird, dass die SKOOR- Engine auf dem aktuellen Primärsystem nicht mehr läuft.

• Möglichkeit zum Ausführen benutzerdefinierter Skripte oder Befehle vor und/oder nach dem Umschalten der Server (Standby zu Primär und umgekehrt).

Anforderungen

Zum Einrichten der Datenbankreplikation wird ein zweiter SKOOR- Server mit denselben Leistungsspezifikationen wie der erste benötigt. Obwohl dieser Standby-Server die meiste Zeit im Standby-Modus ist, muss er in der Lage sein, die volle Last zu tragen, wenn seine Funktion vom Standby- zum Primär-Server wechselt.

Folgende Voraussetzungen müssen erfüllt sein:

• Auf dem Primär- und Standby-Server ist die gleiche Version von SKOOR installiert.

• (Optional) Externe Kollektoren sind korrekt eingerichtet und funktionieren

  • Der Server Der Parameter _address muss auf die gleiche IP-Adresse wie der primäre Server eingestellt werden.

  • Kollektoren die das HTTP-Protokoll verwenden, können nicht automatisch umgeschaltet werden

• Die Datei /opt/eranger/bin/ Server ist auf dem Primär- , Standby- und allen Kollektoren identisch. Dies bedeutet, dass auf allen beteiligten Hosts dieselbe SKOOR-Version installiert sein muss.

• Die Datei /etc/opt/eranger/eranger-replication.cfg ist korrekt konfiguriert und ist auf dem Primär-, Standby- und allen Kollektoren identisch.

• Netzwerkkonnektivität

  • TCP-Port 22 (SSH) vom Primär zum Standby , umgekehrt und vom Primär und Standby zu allen externen Kollektoren .

  • TCP-Port 50001 (SKOOR Kollektor -Datenübermittlung) von allen externen Kollektoren zum Primär- und Standby-Server .