Die Architektur

Die SKOOR Engine verwendet eine PostgreSQL-Datenbank zum Speichern ihrer Konfigurationsdaten sowie ihrer historischen Wert- und Verlaufsdaten. Es unterstützt die Verwendung eines Primär-/Standby- Setups zur kontinuierlichen Replikation der Datenbankinhalte. Es werden die eigenen Replikationsmethoden Server PostgreSQL verwendet, was bedeutet, dass eine exakte Kopie der Datenbank auf dem Primärserver auf dem Standby-Server aufbewahrt wird und alle Aktualisierungen der Datenbank auf dem Primärserver sofort auf den Standby-Server repliziert werden. Der Primärserver puffert die SQL-Anweisungen in einem Binärprotokoll, Server Standby- Server fordert diese Anweisungen vom Server an.

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

Die folgende Abbildung zeigt ein Beispiel für ein Standard-Replikationslayout.

Im Standardmodus 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 Server Die Dienste eranger- Server , eranger- Kollektor und eranger-report laufen NICHT auf dem Standby- Server .

Hauptmerkmale des Replikations-Setups

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

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

• Es gibt kein automatisches Failover vom Primär- zum Standby-Server . Es wurde entwickelt, um diese Entscheidung einem Menschen zu überlassen. Das Skript unterstützt jedoch einen nicht interaktiven Modus, der die Durchführung eines Failovers durch ein Skript ermöglichen würde. (Option -f ).

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

• Möglichkeit, benutzerdefinierte Skripte oder Befehle vor und/oder nach dem Umschalten der Server (Standby auf Primär und umgekehrt) auszuführen.

Anforderungen

Zum Einrichten der Datenbankreplikation ist ein zweiter SKOOR- Server mit den gleichen Leistungsspezifikationen wie der erste erforderlich. Obwohl sich dieser Standby-Computer die meiste Zeit im Standby-Modus befindet, muss er in der Lage sein, die volle Last zu tragen, wenn seine Funktion vom Standby- in den primären Modus wechselt.

Folgende Voraussetzungen müssen erfüllt sein:

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

• (Optional) Externe Kollektoren sind korrekt eingerichtet und funktionieren

  • Der Server Der Parameter _address muss auf dieselbe IP wie der Server eingestellt sein

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

• Die Server /opt/eranger/bin/eranger-Server-replication.pl ist auf Primär- , Standby- und allen Kollektoren identisch. Das bedeutet, dass auf allen beteiligten Hosts die gleiche SKOOR-Version installiert sein muss.

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

• Netzwerkkonnektivität

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

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