NGA-Redundanz

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)".

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 WinCC OA-Server schreibt auf beide Backends. Der passive WinCC OA-Server buffert die Datenblöcke bis sie erfolgreich in die Datenbanken geschrieben werden. Danach verwirft er die Daten.

In diesem Szenario sind die beiden Datenbanken völlig unabhängig voneinander. Sie sind nicht Teil eines Clusters und beide werden vom aktiven WinCC OA-Server beschrieben. Daher werden diese Datenbanken konsistent gehalten, indem dieselben Daten in beide geschrieben werden.

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 WinCC OA-Server die existierenden Puffer in die lokale und abgesetzte Datenbanken zu schreiben ( die Daten, welche der vorher aktive WinCC OA-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 WinCC OA-Servers /der Datenbank, erkennt der aktive WinCC OA-Server die Verfügbarkeit der Datenbank und schreibt die gebufferten Daten (Recovery). Das passive WinCC OA-System wird jeglichen lokal gespeicherten Puffer automatisch löschen, wenn Daten von dem aktiven WinCC OA-Server geschrieben wurden.

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

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. Die Gewichtung wird anhand der Backend-Verbindung zur Datenbank (schlecht = keine Datenbankverbindung) berechnet.