Redundanz-Architektur

WinCC OA kann im redundanten Modus laufen, in dem zwei Server ("der linke" und "der rechte" im folgenden Kontext) verwendet werden und der Ausfall eines dieser Systeme mit dem anderen system kompensiert wird. Einer der Server ist immer der aktive, der Daten an die Peripherie sendet und auf dem die User Interfaces laufen. Der zweite Server ist der passive, der eine Kopie des Statuses des aktiven Servers speichert.

Dieses Kapitel beschreibt die Redundanz in der NGA-Umgebung. Für Information über die allgemeine Redundanz, siehe Kapitel Grundlagen Redundanz.

Der wichtigste Aspekt der NGA-Redundanz ist es den Verlust von historischen Daten aufgrund von nicht redundanter Hardware oder Softwarefehler zu vermeiden. Die Implementierung wurde realisiert, um einzelne Fehler zu bewältigen aber nicht für mehrere parallele Fehler (z.B. Crash des Harddisks auf beiden Servern). Ein weiterer Aspekt der NGA-Redundanz ist es einen historischen Lesezugang für abgesetzte User Interfaces anzubieten, auch dann, wenn einer der redundanten Knoten oder eine der Datenbanken abstürzt (wenn die Datenbank redundant ist und auf einem separaten Server liegt).

Es gibt auch eine Spezialoption der Redundanz namens "Splitbetrieb" in dem beide Server aktiv sind und wenn der Splitbetrieb beendet wird, einer der Server aktiv bleibt und der zweite neu gestartet wird und Recovery durchgeführt wird (Standard WinCC OA-Redundanzfunktion, wenn das Serverprojekt neu gestartet wird). Diese Option wird derzeit nicht für den NextGen Archiver unterstützt.

Jeder redundante Server hat einen Fehlerstatus (einen so genannten "Health state"), der normalerweise identisch auf beiden Servern sein sollte. Wenn nicht, wird der Server mit dem besseren "Health state" aktiv. Dies verursacht möglicherweise einen Wechsel zwischen dem aktiven und dem passiven Server. Wurde ein Server gestoppt, muss dieser beim nächsten Neustart mit dem aktiven Server synchronisiert werden damit er den gleichen "Health state" hat (Datenpunktwerte, Alarmzustände etc.), wie der gerade laufende Server. Diese Prozedur heißt Recovery.

Um ein existierendes NGA-basiertes Projekt zu einem redundanten Projekt zu konvertieren, müssen, zusätzlich zu den nicht NGA-basierten Schritten (siehe Grundlagen Redundanz), die Front- und Backends zur Redundanz konvertiert werden.

Die Konvertierung passiert über die "Datenbank ist redundanzfähig"-Checkbox (Registerkarte "Profil" im NGA Datenbank Engineering).

Um NexGen Archiver zu verwenden, gibt es zwei unterschiedliche Schema - abhängig von der Redundanzunterstützung der verwendeten Datenbank, sind folgende Schema möglich:

• Wenn die Datenbank nicht redundanzfähig ist (z.B. die Open Source-Version der InfluxDB®), muss die Datenbank auf zwei Knoten, die unabhängig von einander sind, laufen.
• Wenn die Datenbank redundanzfähig ist (z.B. PostgreSQL®, MS SQL®), können beide NGA-Instanzen mit der allgemeinen Datenbankinstanz, welche die Redundanzoperationen (Wechsel, recovery) ausführt, sprechen.