Ausfallverhalten und Umschaltkriterien
Für die Überwachung des Redundanzstatus (aktiv/passiv) ist der Redu-Manager auf beiden Rechnern verantwortlich. Der Redu-Manager wird vor den projektspezifischen Managern (Treiber, CTRL Manager, etc.) gestartet. Die Fehlerstati in beiden Systemen werden ebenfalls von diesem Manager überwacht. Die Fehlerfälle werden im Systemübersichtspanel mit einer Gewichtung parametriert (siehe Panel Systemübersicht bei Redundanz). Der Fehlerstatus wird bei der Initialisierung festgestellt und dann laufend aktualisiert (optimal ist Status 0). Die Parametrierung der Überwachung kann für alle Manager, TCP-Verbindungen, ausgewählte Datenpunktelemente, Arbeitsspeicher und Festplattenkapazität erfolgen.
Für den Aktiv/Passiv-Zustand in einem redundanten System (passiver Rechner wird aktiv, aktiver Rechner passiv) gelten folgende Prioritäten:
-
Priorität 1: Rechnerausfall:
Komplettausfall eines Rechners oder keine der beiden redundanten Netzwerkverbindungen besteht. Bei einem Komplettausfall der redundanten Netzwerkverbindung ist keine Umschaltung der Führung mehr möglich. In diesem Fall werden beide Server aktiv.
-
Priorität 2: Händisch erzwungene Führung (Aktiv setzen):
Damit ist es möglich, trotz einer der untergeordneten Prioritäten auf einen Rechner umzuschalten, sofern dies hard- und softwaremäßig noch möglich ist. Diese Priorität gilt als Umschaltung der Führung. Mit Hilfe der Umschaltung der Führung wird das gewünschte System sofort aktiv gesetzt. Dies ist unabhängig vom Fehlerstatus.
-
Priorität 3: Unterschiedlicher Fehlerstatus:
Kommunikationsausfälle von Managern, Ausfall von Hardware- oder Software- Komponenten. Es wird auf den Rechner mit dem geringeren Fehlerstatus umgeschaltet.
-
Priorität 4: Bestimmen der Vorzugslage:
Damit ist es möglich, händisch den gerade im Führungsbetrieb befindlichen Rechner umzuschalten. Diese Umschaltung wirkt sich aber nur dann aus, wenn beide Rechner fehlerfrei oder mit gleichem Fehlerstatus laufen.
Nach einer Umschaltung (Aktiv/Passiv) im Redundanzbetrieb, wird auch automatisch eine Generalabfrage vom Treiber angestoßen!
Wenn eines (oder mehrere) der oben genannten Umschaltkriterien erfüllt sind und eine automatische Umschaltung vorgenommen wird, wird die Betriebskontrolle an den Redundanzpartner mit dem kleineren Fehlerstatus übertragen. Die Daten dieses aktiven Servers werden in den UIs dargestellt. Das passive System führt laufend den Abgleich der Prozessdaten durch.
Die Redundanz arbeitet selbständig und ist nicht von Benutzereingaben und -reaktionen abhängig. Dennoch werden bestimmte Vorgaben vom Benutzer (siehe Prio. 2 und 4 oben) akzeptiert. Händische, durch den Benutzer hervorgerufene Umschaltungen, müssen im Systemübersichtspanel vorgenommen werden.
Beim Ausfall bestimmter Manager werden folgende Reaktionen ausgelöst:
- Kompletter Neustart des Projektes und Recovery wird bei einem Ausfall von , Data-,
Archiv-, Event- oder Redu-Manager durchgeführt. Anmerkung: Der Ausfall des Archivmanagers gilt nur für Wertearchive. Wenn ein NGA- oder ein RDB-Manager ausfällt, wird ein Projekt nicht neu gestartet.
- Alle anderen Manager haben je nach Konfiguration in der Console einen Neustart des Managers bzw. keine Reaktion zur Folge.
Wenn die Verbindung der Data-Manager zueinander während der Wiederherstellung der Datenbank in der Hochlaufphase eines Servers ausfällt, wird das startende Projekt gestoppt und neu gestartet.
Wurde das Recovery der Datenbank bereits abgeschlossen, fährt das Projekt weiter hoch und wird automatisch nach Ablauf von passiveRecoveryTimeout (Event) aktiv.
UI-Manager, die direkt auf den Servern gestartet werden, müssen eine definierte Managernummer verwenden. Diese muss niedriger sind als die über den Konfigurationseintrag [general] lowestAutoManNumUI festgelegte Defaultnummer.
Ist die Managernummer nicht gesetzt, startet die Benutzeroberfläche z.B. mit der Nummer 8 auf dem Server 1. Verliert dieser Server 1 die Netzwerkverbindung, hat der Server 2 die Verbindung zum UI mit der Nummer 8 verloren und gibt diese Nummer wieder frei. Wird auf einem Client ein neues UI gestartet, wird diesem vom Server 2 die Nummer 8 zugewiesen (Server 1 ist über das Netzwerk nicht erreichbar). Bauen die Server die Verbindung wieder auf, kann das Client UI mit der Nummer 8 keine Verbindung zum Server 1 aufbauen. Die UI Nummer 8 wird bereits vom lokalen UI am Server 1 verwendet.