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 zur kontinuierlichen Replikation der Datenbankinhalte. Es werden die PostgreSQL-eigenen Replikationsmethoden verwendet, was bedeutet, dass eine exakte Kopie der Datenbank auf dem primären Server auf dem Standby-Server gehalten wird und alle Aktualisierungen der Datenbank auf dem primären Server sofort auf den Standby-Server repliziert werden. Der primäre Server puffert die SQL-Anweisungen in einem binären Protokoll, der Standby-Server fordert diese Anweisungen vom Server an.

Dies gewährleistet kurze Ausfallzeiten im Falle von Hardwareausfällen. Allerdings schützt es NICHT vor Pilotfehlern wie fehlerhaften Löschanweisungen, die sofort mit dem Standby-Server synchronisiert werden. Die Replikation ersetzt keine regelmäßigen Backups.

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

Im Standardmodus trägt der primäre Server die gesamte Last, alle Benutzeranfragen werden vom Apache Webserver auf dem primären Server beantwortet , Messdaten werden von den Kollektoren an den aktuellen primären Server geliefert und in der Datenbank gespeichert. Die Dienste eranger-server, eranger-collector und eranger-report laufen NICHT auf dem Standby Server.

Hauptmerkmale des Replikationsaufbaus

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

• Wenn zuvor eine Replikation durchgeführt wurde, ist wahrscheinlich ein großer Teil der Datenbankdateien bereits synchronisiert. Das Skript wird alte Tabellen, die bereits synchronisiert sind, NICHT übertragen. Dies spart Netzwerkbandbreite, wenn eine Neuinitialisierung durchgeführt werden muss.

• Es gibt kein automatisches Failover von der Primär- zur Standby-Datenbank. Das Skript wurde so konzipiert, dass diese Entscheidung einem Menschen überlassen wird. Das Skript unterstützt jedoch einen nicht-interaktiven Modus, der es ermöglicht, ein Failover durch ein Skript auszulösen. (Option -f ).

• Möglichkeit zur Überwachung des Primärsystems vom Standby-System aus (unabhängig von SKOOR), wobei eine E-Mail gesendet wird, sobald festgestellt wird, dass die SKOOR Engine auf dem aktuellen Primärsystem nicht mehr läuft.

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

Anforderungen

Um die Datenbankreplikation einzurichten, ist ein zweiter SKOOR Server erforderlich, der die gleichen Leistungsmerkmale wie der erste hat. Obwohl sich dieser Standby-Server die meiste Zeit im Standby-Modus befinden wird, 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 dem primären und dem Standby-System ist dieselbe Version von SKOOR installiert.

• (Optional) externe Kollektoren sind korrekt eingerichtet und funktionieren

  • Der Parameter server<n>_address muss auf die gleiche IP wie der primäre Server eingestellt 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ären, dem 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 ist auf dem primären, dem Standby- und allen Kollektoren identisch.

• Netzwerkkonnektivität

  • TCP-Port 22 (ssh) von primär zu standby und umgekehrt sowie von primär und standby zu allen externen Kollektoren.

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