NGA-Redundanz

VORSICHT: Dieses Szenario ist nur für InfluxDB® und PostgreSQL® verfügbar.

Redundanz mit duplizierten, von NGA verwalteten Datenbankinstanzen:

Im Falle von Datenbanken, die nicht redundanzfähig sind, kümmert sich NextGen Archiver um die Hauptredundanz-Use cases.

  • Die passive DB wird synchron mit der Aktiven gehalten
  • Wechsel zwischen redundanten Partnern
  • DB-Synchronisierung nach dem Neustart des passiven Systems
  • Inklusive Datenbank/Verbindungsstatus im allgemeinen "System health (Status)".
Abbildung 1. NGA-Redundanz Architektur

Die Basisidee, um dies zu realisieren, ist es zwei identische Backends für jeden redundanten Knoten zu verwenden. Eines ist mit der lokalen Datenbank verbunden, das zweite mit der Datenbank des redundanten Partners. Der aktive Server schreibt auf beide Backends. Der passive Server buffert die Datenblöcke bis sie erfolgreich in die Datenbanken geschrieben werden. Danach verwirft er die Daten.

Im Falle eines redundanten Systems, sendet das NGA-Frontend Daten zusätzlich zu dem Backend ("Backend 2" im Bild oberhalb), das die Daten auf den anderen Server schreibt. Nach einem Wechsel, beginnt der vorher passive Server die existierenden Puffer in die lokale und abgesetzte Datenbanken zu schreiben ( die Daten, welche der vorher aktive Server noch nicht in die Datenbanken geschrieben hat) .

Wenn der andere Server (oder mindestens die Datenbank) nicht erreicht werden kann, buffert das Backend, der die Daten schreibt. Um eine längere Zeitspanne in einer redundanten Umgebung abzudecken, muss die Bufferingmethode entsprechend gesetzt werden (Buffer to disk) - siehe Konfiguration - Frontend.

Nachdem Neustart des passiven Servers /der Datenbank, erkennt der aktive Server die Verfügbarkeit der Datenbank und schreibt die gebufferten Daten (Recovery). Das passive System wird jeglichen lokal gespeicherten Puffer automatisch löschen, wenn Daten von dem aktiven Server geschrieben wurden.

Alle Leseanforderungen für historische Werte /Alarme (dpGetPeriod, dpGetAsynch, alertGetPeriod, dpQuery) von User Interfaces werden an das aktive System durch den Event-Manager geleitet. Control-Manager müssen mit dem Kommendozeilenparameter "-connectToRedundantHosts" gestartet werden, um automatisch an den aktiven Host geroutet zu werden. Das ist Standardverhalten der WinCC OA -Redundanz.

Abbildung 2. WinCC OA-System Übersichtspanel für ein NGA-Projekt

Der NextGen Archiver wird auch im Systemübersicht-Panel angezeigt.

Wenn ein Projekt, das NGA verwendet, erstellt wird, wird das Standard-Backend ("PostgreSQL®") auf beiden redundanten Knoten angezeigt und die Fehlergewichtung beinhaltet den NGA-Manager (anstatt Value Archiv- oder RDB-Manager). Die Gewichtung wird anhand der Backend-Verbindung zur Datenbank (schlecht = keine Datenbankverbindung) berechnet.

Anmerkung:

Split-Betrieb steht für redundante NGA-Projekte nicht zur Verfügung. Split-Betrieb ist im Panel nicht deaktiviert. Verwenden Sie daher den Split-Mode nicht in redundanten Projekten.

Weitere Hinweise zur Sicherheit von PostgreSQL®-Datenbanken finden Sie im Kapitel PostgreSQL®-Hinweise.