Hinweise und Einschränkungen

Drittes verteiltes System

Es ist zwar möglich, ein Disaster Recovery System mit einem dritten verteilten System zu verbinden, jedoch werden auf diesem dritten System keine Daten oder Dateien abgeglichen.

Systemnamen

Wenn der Systemname eines Redundanz-Paares (PSS bzw. SSS) verwendet wird (z.B.: Datenpunktgruppen, AES-Konfigurationen, etc.), funktionieren diese Einstellungen für das zweite Redundanz-Paar nicht. Daher sind alle Einstellungen, welche die Disaster Recovery Systeme betreffen, ohne Systemnamen vorzunehmen.

Ausfall eines Redundanz-Paares in einem verteilten System

Ein verteiltes System zur Disaster Recovery Redundanz kann nur Daten von einem Redundanz-Paar verwenden. Wenn das Redundanz-Paar ausfällt, werden die Daten vom zweiten Redundanz-Paar nicht automatisch verwendet, da dies einen anderen Systemnamen hat.

Löschen von Datenpunkt-Configs

Der Abgleich der Parametrierung inkludiert nicht das Löschen von Datenpunkt-Configs. Anstatt ein Datenpunkt-Config zu löschen, sollte es deaktiviert werden. Wenn dies nicht möglich ist (z.B.: bei Datenpunktfunktionen) muss es manuell auf beiden Systemen (PSS und SSS) gelöscht werden.

Alarmfarben und -ebenen nach Wiederinbetriebnahme eines Systems

Es besteht die Möglichkeit, dass, wenn ein System nach einem Komplettausfall wieder in Betrieb genommen wird, Analogdatenpunkte mit Meldebehandlung am PSS und SSS unterschiedliche Alarmfarben bzw. Alarmebenen besitzen. Dies tritt auf, wenn zum Beispiel ein Analogwert eine Alarmklasse mit 3 Meldebereichen besitzt (z.B.: Alarm, Warnung, keine Meldung) und der Wert des Datenpunktes die Grenze der höchsten Ebene überschreitet, den Alarm auslöst und anschließend wieder unterschreitet, während das System sich immer noch im Auffallzustand befindet. Nimmt nun dass ausgefallene System den Betrieb wieder auf, steht die Meldung auf diesem System nur als Warnung an, während am anderen System die Meldung noch immer als Alarm ansteht, da das System das Überschreiten der Alarmgrenze nicht wahrnehmen konnte. Nach der Quittierung des Alarms zeigen jedoch beide Systeme wieder den gleichen Alarmstatus an.

Multiinstanzalarme

Da zurzeit der Parametrierabgleich für Multiinstanzalarme nicht unterstützt wird, muss die Datenpunktparameterierung händisch auf beiden Systemen durchgeführt werden.
Quittieren wird nicht übertragen bei SELECT ALERT SINGLE (Alarm, der zur letzten Änderung der Meldebehandlung führte (bei dpQueryConnectSingle()). Siehe auch Beispiel zum Setzen einer Meldebehandlung für Multiinstanzalarme für CTRL-Funktionsaufrufe.

Abgleich der historischen Daten nach Verbindungsunterbrechung

Der Abgleich der historischen Daten (z.B. nach Verbindungsunterbrechung zwischen PSS und SSS oder Systemausfall vom SSS) wird nicht automatisch durchgeführt, sondern muss vom Benutzer im entsprechenden Panel manuell angestoßen werden.

Fehlermeldung nach Quittierung eines Alarmes

Wenn ein Alarm durch die automatische Abgleichsfunktion des Disaster Recovery Systems quittiert wird (Abgleich von z.B. PSS und SSS), erscheint eine Warnmeldung im Logviewer. Diese Meldung hat jedoch keinen negativen Effekt und kann daher ignoriert werden. Zum Beispiel:

WCCILevent (0), 2008.05.21 10:11:17.616, PARAM,WARNING, 23,
Setting/modifying attributes failed, DP: System2:dp:_alert_hdl.._ack, MAN: (SYS:
1 Ctrl -num 4 CONN: 1)

Parametrierabgleich der RDB-Verdichtungsparametrierung

Der Parametrierabgleich der RDB-Verdichtungsparametrierung ist nur über das ASCII-Import/Export-Panel der RDB-Verdichtung möglich (siehe ASCII Import und Export einer RDB-Verdichtungsparametrierung).

Synchronisation von internen Datenpunkten

Interne Datenpunkte werden standardmäßig nicht synchronisiert. Sollte eine Synchronisierung erforderlich sein, so muss diese mittels der Wizard-Parametrierung konfiguriert werden.

Abgleich der Alarmkommentare

Kommentare in einem DRS-System werden wie folgt synchronisiert:

Kommentare werden vom aktiven System auf das passive System synchronisiert. Alarmkommentare werden nur dann übertragen, wenn auch der Alarmstatus übertragen wird.
Kommentare werden nicht vom passiven auf das aktive System synchronisiert
Sollte bei Eintragen eines Kommentars am aktiven System das passive System temporär nicht verfügbar sein, werden die Kommentare nachsynchronisert, wenn das passive System wieder verfügbar ist.
Ein historischer Alarm kann auch kommentiert werden.

Einschränkungen

Alarmkommentare werden nur bei identischen Alarmen übertragen
Alarmkommentare werden historisch abgeglichen
Unter Umständen kann es vorkommen, dass es keine Verbindung zwischen DRS-Partnern gibt. In diesem Fall kann ein Alarmkommentar verloren gehen, dadie Daten am PSS (Primary Server System)mit den aktuellen Daten des SSS (Secondary Server System) synchronisiert werden.
Synchronisationsrichtung (aktiv -> passiv) ist identisch mit der Synchronisationsrichtung der Alarmstati (Quittierungen).
Wenn Sie die Autologin-Funktionalität in DRS benötigen, müssen Sie Ihre eigene disRecSystem_client_RenewDRSAutoLogin-Funktion implementieren. Wenn Sie das distRecSystem_client.ctl-Skript in Ihrem Projekt editiert haben, muss die Version von 3.17 auf eine höhere Version aktualisiert werden oder die Änderungen in Ihr Skript gemerged werden da das inkludierte Skript login_internal.ctc nicht in 3.17 existiert.