Architektur

The SKOOR Engine uses a PostgreSQL database to store its configuration data as well as its historical values and history data. It supports the use of a primary/standby configuration to continuously replicate the database contents. Es kommen die PostgreSQL-eigenen Replikationsmethoden zum Einsatz, was bedeutet, dass auf dem Standby-Server eine exakte Kopie der Datenbank vom Primärserver vorgehalten wird und alle Änderungen an der Datenbank auf dem Primärserver sofort auf den Standby-Server repliziert werden. Der Primärserver puffert die SQL-Anweisungen in einem Binärprotokoll, der Standby-Server fordert diese Anweisungen vom Server an.

Dies gewährleistet kurze Ausfallzeiten im Falle von Hardwareausfällen. Es schützt jedoch NICHT vor Bedienungsfehlern wie fehlerhaften Löschanweisungen, die sofort auf den Standby-Server synchronisiert werden. Die Replikation ersetzt keine regelmäßigen 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 übermittelt und in der Datenbank gespeichert. Die Dienste „eranger-server“, „eranger-collector“ und „eranger-report“ laufen NICHT auf dem Standby-Server.

Hauptmerkmale der Replikationskonfiguration

• Die Replikation kann auch mit externen SKOOR Collectors implementiert werden.

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

• Es gibt kein automatisches Failover vom Primär- zum Standby-Server. Das System wurde so konzipiert, dass diese Entscheidung einem Menschen überlassen bleibt. Das Skript unterstützt jedoch einen nicht-interaktiven Modus, der die Durchführung eines Failovers durch ein Skript ermöglicht (Option -f).

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

• Möglichkeit, benutzerdefinierte Skripte oder Befehle vor und/oder nach dem Wechsel der Serverfunktionen (vom Standby-Server zum Primärserver und umgekehrt) auszuführen.

Anforderungen

Zur Einrichtung der Datenbankreplikation ist ein zweiter SKOOR Server mit denselben Leistungsspezifikationen wie der erste erforderlich. Obwohl sich dieser Standby-Server die meiste Zeit im Standby-Modus befindet, muss er in der Lage sein, die volle Last zu tragen, wenn seine Funktion von Standby auf Primär wechselt.

Die folgenden Voraussetzungen müssen erfüllt sein:

• Auf Primär- und Standby-Server ist dieselbe SKOOR-Version installiert.

• (Optionale) externe Kollektoren sind korrekt eingerichtet und funktionieren

  • Der Parameter „server<N>_address“ muss auf dieselbe IP-Adresse wie die des Primärservers gesetzt sein.

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

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

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

• Netzwerkverbindung

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

  • TCP-Port 50001 (SKOOR Collector-Datenübertragung) von allen externen Collectoren zum Primär- und Standby-Server.