Beim Failover-Konzept geht es darum die Ausfallsicherheit des Node Controllers zu gewährleisten.

Wird die Verbindung eines beliebigen Working Nodes zum Node Controller unterbrochen, wird der Failover ausgelöst. Hinweis: Siehe auch Abschnitt Reguläres Herunterfahren des Node Controllers unten.

Kann dieser Working Node die externalURL (siehe Parameter unten) noch erreichen, dann wird er zum neuen Node Controller und alle restlichen Working Nodes verbinden sich mit ihm, nachdem der neue Node Controller sie über seine neue Rolle informiert.

Kann dieser Working Node die externalURL nicht erreichen, dann wird der nächste Node in der Rangordnung zum neuen Node Controller.

Konfiguration

Jede Lobster_data-Instanz kennt sowohl die Internet-Adresse, als auch die Failover-Priorität aller anderen Lobster_data-Instanzen. Damit ist gewährleistet, dass sich im Failover-Fall jede Instanz autark neu organisieren kann. Diese Information wird beim Start einer Lobster_data-Instanz aus den Konfigurationsdateien ./etc/startup.xml und ./etc/admin/datawizard/lb_nodes.properties gelesen. Der relevante Inhalt dieser Dateien wird vom Node Controller an die Working Nodes bei der Anmeldung im Verbund repliziert (d. h. man muss nur die Dateien auf dem Node Controller pflegen).

Datei startup.xml

Zur Aktivierung muss der folgende Eintrag in der Konfigurationsdatei ./etc/startup.xml vorhanden sein.

<Call name="enableFailOver">
    <Arg>
        <New class="com.ebd.hub.datawizard.app.loadbalance.failover.Configuration">
            <Set name="port">2320</Set>
            <Set name="heartbeat">500</Set>
            <Set name="externalURL">https://www.google.de</Set>
			<Set name="maxPingRetry">5</Set>
			<Set name="timeout">1200</Set>
        </New>
   </Arg>
</Call>

Die Bedeutung der Parameter ist dabei die folgende. Es wird ein regelmäßiger Ping (heartbeat) von den Working Nodes an den Node Controller ausgeführt. Kommt es dabei zu einem Fehler, wird nochmal eine bestimmte Anzahl von Pings (maxPingRetry) mit einer bestimmten Wartezeit (timeout) dazwischen ausgeführt. Schlagen auch diese Pings fehl, wird der Failover ausgelöst.

Parameter	Beschreibung
port	Der Port, über den die "Ping"-Messages ausgetauscht werden.
heartbeat	Legt die Frequenz der Pings in Millisekunden fest.
externalURL	Muss eine erreichbare HTTP(S)-URL sein, mit der die Working Nodes überprüfen können, ob sie selber vom Netz getrennt sind oder der Node Controller. Ein Working Node kann nur zum neuen Node Controller werden, wenn er die externalURL erreichen kann.
maxPingRetry	Anzahl der weiteren Ping-Versuche nach einem Ping-Fehler, bis bei weiteren Misserfolgen der Failover ausgelöst wird. Default: 3.
timeout	Die Wartezeit, die für die Ping-Versuche nach einem Ping-Fehler (maxPingRetry) verwendet wird statt der normalen Ping-Frequenz (heartbeat).

Datei lb_nodes.properties

Die Konfigurationsdatei ./etc/admin/datawizard/lb_nodes.properties beinhaltet die jeweiligen Host-Adresse und den Message-Service-Port der am Load Balancing beteiligten Lobster_data-Instanzen (Working Nodes und Node Controller). Der Key ist der Name der Instanz, wie er in der jeweiligen Konfigurationsdatei ./etc/factory.xml im Element "id" angegeben ist. Hinweis: Siehe auch Abschnitt Aufbau einer Properties-Datei (beachten Sie den Backslash vor dem Doppelpunkt in folgender Beispiel-Datei).

# define all working nodes by IP:Port that are licensed - must be the factory name as key
#
# e.g.
WorkNode2=192.168.132.56:8020
WorkNode1=192.168.132.55:8020
NodeContr2=192.168.132.54:8020
NodeContr1=192.168.132.53:8020
WorkNode3=192.168.132.57:8020

Grundsätzliche Zusammenhänge

Es existiert immer genau ein aktiver Node Controller.
Die Anzahl von Working Nodes ist unbegrenzt und kann jederzeit verändert werden.
Jeder Working Node (per Lizenz und Konfiguration) kann prinzipiell sowohl im Working-Modus, als auch im Controller-Modus sein. Die Modi können im laufenden Betrieb wechseln.
Node Controller (per Lizenz und Konfiguration) können nur im Controller-Modus sein.
Immer der letzte Node Controller, der online geht, wird zum aktiven Node Controller. Alte Node Controller beenden sich, außer sie waren per Lizenz und Konfiguration vorher ein Working Node. In diesem Fall wechselt die Instanz zum Working Node und fährt nicht herunter.
Ein Wechsel des Node-Betriebsmodus kann selbständig aufgrund eines erkannten Failovers erfolgen, oder vom Benutzer explizit initiiert werden (im Control Center oder per HTTP).
Es muss einmalig (beim Start) ein gültiger Betriebszustand mit Node Controller und Working Node(s) erreicht sein, weil autarke Working Nodes ihr Setup beim Start vom Node Controller erhalten.

SAP-RequestListener deaktivieren

Siehe Abschnitt SAP-RequestListener in Load-Balance-Failover.

Ausfall des primären DMZ-Servers

Siehe Abschnitt DMZ-Verbund‌.

Reguläres Herunterfahren des Node Controllers

Wenn Sie selbst den Node Controller regulär herunterfahren, wird im Normalfall ein Signal an die Working Nodes geschickt, damit diese das Herunterfahren nicht als Ausfall werten.

Möchten Sie aber, dass dieses Signal nicht geschickt wird und somit ein Failover ausgelöst wird, dann können Sie im Installationsverzeichnis des Node Controllers die Datei nc_suppress_shutdown anlegen.

Diese Datei wird nicht gelöscht. Zudem funktioniert diese Datei nur auf dem konfigurierten Node Controller und nicht auf einem Working Node, der die Node-Controller-Rolle übernommen hat.