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.

Anmerkung:

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.
Anmerkung: Die Reaktion der einzelnen Manager ist abhängig von der Einstellung der Startart in der Console (siehe Managerverwaltung). Data-, Archiv-, Event- und Redu-Manager sind defaultmäßig mit der Startart "immer" belegt und dürfen für eine ordnungsgemäße Funktion im Redundanzfall nicht verändert werden!
Anmerkung: Wenn bei einem redundanten Projekt die Redundanzpartner die Verbindung zueinander verlieren, werden beide WinCC OA-Projekte aktiv. Wenn die Verbindung wiederhergestellt wird, wird das Projekt mit dem höheren Fehlerstatus beendet und recovered (neu gestartet). Verwenden Sie den Config-Eintrag [calcstate] useOfflineErrorstateInfo, um auch den max. Offline-Fehlerstatus bei der Fehlerstatusberechnung zu berücksichtigen.
Anmerkung: Mit dem Config-Eintrag [redu] firstActiveChangeInterval kann die erste Redundanzumschaltung nach einem Verbindungsfehler (z.B. Switch-Fehler) um die angegebene Zeit verzögert werden.

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.

VORSICHT: Alle statistischen Funktionen mit einem Berechnungsintervall größer als die normale Projektstartzeit müssen mit der Option aus dem Archiv initialisieren konfiguriert werden, um korrekte Werte nach einem Neustart eines Servers zu erhalten.
Anmerkung: UI-Manager, die direkt auf dem Server gestartet werden, müssen eine fixe Managernummer erhalten (z.B. "-num 2") . Fixe Managernummer verhindern, dass im Falle eines Ausfalls und einer erneuten Wiederaufnahme der Verbindung, Probleme mit abgesetzten UIs entstehen.

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.