Redundanz

Wird in WinCC OA ein Projekt auf zwei redundanten Servern betrieben, die eine gemeinsame Datenbank nutzen, müssen die beiden RDB Manager einen Redu-Abgleich durchführen. Ein Redu-Abgleich hat zur Aufgabe, die Datenströme beider RDB Manager (aktiver und passiver) in die Datenbank zu schreiben ohne dabei Konflikte auszulösen oder Daten doppelt zu schreiben.

Aufgaben aktiver/passiver RDB Manager

Die Datenströme im Hauptspeicher bzw. auf der lokalen Festplatte (BufferToDisk Funktionalität) des aktiven und des passiven RDB Managers sind identisch. Unterschiede zwischen den beiden RDB Managern ergeben sich aus den Aufgaben und Befugnissen, welche Ihnen im Folgenden zusammengeführt werden.

Aktiver RDB Manager

Der aktive RDB Manager ist immer jener, dessen Server die Führungsposition besitzt. Bei einem RDB Redundanz-Ausgleich ist er für die folgenden Prozesse verantwortlich:

  1. Puffert alle Datenströme des aktiven Servers im Hauptspeicher bzw. auch auf der Festplatte (BufferToDisk Funktionalität).

  2. Im Gegensatz zu passiven RDB Manager, hat nur der aktive RDB Manager die Befugnis gepufferte Datenblöcke in die Datenbank zu schreiben.

  3. Nach jeden geschriebenen Datenblock, setzt der aktive RDB Manager die Stempel DPZeit und DPName aus dem Inhalt des letzten Blockeintrages eines Blocks auf die internen Datenpunkte _RDBArchive.writingStatus.lastWrite und _RDBArchive.writingStatus.lastDp.

Passiver RDB Manager

Der passive RDB Manager ist immer jener, dessen Server die Hot-Standby Funktionalität aufweist. Bei einem RDB Redundanz-Ausgleich ist er für die folgenden Prozesse verantwortlich:

  1. Puffert alle Datenströme des passiven Servers im Hauptspeicher bzw. auch auf der Festplatte (BufferToDisk Funktionalität).

  2. Liest die vom aktiven RDB Manager gesetzten Stempel (DPName und DPZeit) aus dem internen Datenpunkten _RDBArchive.writingStatus.lastDp und _RDBArchive.writingStatus.lastWrite und vergleicht sie mit den Werten in seinem Datenstrom. Kommt es zu einer Übereinstimmung der beiden Stempel-Paare, so werden alle Datenblöcke gelöscht, die im Datenstrom vor dem übereinstimmenden Eintrag liegen.

Anmerkung:

Damit die vom aktiven RDB Manager in die DB geschriebenen Datenblöcke erfolgreich aus dem Datenstrom des passiven RDB Managers gelöscht werden können, sind in der Config-Datei config.redu folgende Einträge erforderlich: fwdDp = "_RDBArchive.writingStatus.lastWrite" /für den aktiven Server fwdDp = "_RDBArchive_2.writingStatus.lastWrite" /für den passiven Server

Anmerkung:

Während zu schnellen Redundanz-Wechsel kann es passieren, dass der RDB Manager einfriert, wenn die Netzwerkverbindung während eines Abrufs vom Oracle Server unterbrochen wird. Falls die Netzwerkverbindung für einen längeren Zeitraum unterbrochen wird, wird Oracle SQL *NET dies erkennen sobald der "KeepAliveTime" Registry-Eintrag kleiner ist als der Zeitraum des Verbindungsverlustes. Wenn die Verbindung vor der im Eintrag "KeepAliveTime" eingegebenen Zeit wieder hergestellt werden kann, wird der RDB Manager einfrieren. Lösung: Führen Sie einen manuellen Redundanz-Wechsel durch und starten Sie den eingefrorenen RDB Manager erneut. Beachten Sie, dass es sich dabei um einen Oracle Fehler und nicht WinCC OA Fehler handelt.

Beispiel

Der aktive und der passive RDB Manager erhalten den gleichen Datenstrom. Da die Blockbildung bei beiden Managern asynchron verläuft, werden die Daten zu unterschiedlich großen Blöcken zusammengefasst (siehe Abbildung). In diesem Beispiel wird Ihnen die Zusammenarbeit des aktiven und des passiven RDB Managers einzeln veranschaulicht.

Abbildung 1. Unterschiedliche Zusammenfassung des Datenstroms zu Blöcken

Aktiver RDB Manager

Einzelne Daten werden verarbeitet, ohne jegliche Interaktion des passiven RDB Managers.

  1. Die Daten (Befehle, Änderungen, etc.) werden zu Datenblöcken zusammengefasst und im Hauptspeicher bzw. auch auf der Festplatte (aktive BufferToDisk Funktionalität) gepuffert.

  2. Die Blöcke werden von dort aus abgearbeitet und in die Datenbank geschrieben.

  3. Sobald ein kompletter Datenblock in die DB geschrieben wurde, werden die Inhalte des letzten Eintrags des Blocks (z.B. im Datenblock 11 hat der letzte Eintrag den Inhalt "DPName 30, DPZeit 30") auf die internen Datenpunkte _RDBArchive.writingStatus.lastDp und _RDBArchive.writingStatus.lastWrite gesetzt.

  4. Nach dem gleichen Schema werden nacheinander alle Blöcke in die DB geschrieben.

Passiver RDB Manager

Einzelne Daten werden verarbeitet, ohne jegliche Interaktion des aktiven RDB Managers.

  1. Die Daten (mit Befehlen, Änderungen, etc.) werden zu Datenblöcken zusammengefasst und im Hauptspeicher bzw. auch auf der Festplatte (aktive BufferToDisk Funktionalität) gepuffert.

  2. Die vom aktiven RDB Manager gesetzten Stempel in den internen Datenpunkten, werden ausgelesen (in diesem Beispiel "DPName 30" und "DPZeit 30").

  3. Der passive RDB Manager vergleicht das ausgelesene Stempel-Paar mit den Inhalten all seiner Datenblöcke.

  4. Wird das Paar in einem Block gefunden (eindeutig identifiziert durch DpName und DPTime), werden alle älteren Blöcke des Datenstroms gelöscht (im Beispiel Datenblock 5), da es sich dabei um Daten handelt, die bereits vom aktiven RDB Manager in die DB geschrieben wurden.

  5. Wird das Paar nicht gefunden, bleiben alle Datenblöcke erhalten.

Ausfall eines Servers

Bei Ausfall des aktiven Servers übernimmt der passive Server automatisch seine Aufgaben und Befugnisse. Der passive Server (jetzt aktiv) schreibt in die Datenbank und setzt nun die Stempel DPName und DPZeit auf die internen Datenpunkte. Das Risiko, dass jüngere Stempel durch die älteren, die im Hauptspeicher des passiven Servers vor dem Ausfall gepuffert wurden, überschrieben und somit dann doppelt in die Datenbank vorhanden sind, wird durch die Löschfunktion des Servers, als der sich noch im passiven Zustand befand, vermieden.

Wird ein ausgefallener Server (aktiv oder passiv) wieder hochgefahren, werden die auf der Festplatte gepufferten Datenblöcke markiert (Zeitstempel) und unabhängig vom Serverstatus in die Datenbank geschrieben. Auf diese Weise bleibt der Aufwand für das Kopieren der Daten von einem auf den anderen Server erspart. Nachdem alle markierten Datenblöcke in die DB geschrieben wurden, werden die Befugnisse des Schreibens und des Stempelns dem passiven Server entnommen und der aktive ist wieder alleine für diese Prozesse zuständig.