Funktionsprinzip

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

Es existiert immer genau ein aktiver Node Controller in einem Cluster/Verbund. 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. 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).

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.

Es muss einmalig (beim Start) ein gültiger Betriebszustand mit Node Controller und Working Node(s) erreicht sein, weil Working Nodes ihr Setup beim Start vom Node Controller erhalten.

Wird die Verbindung eines beliebigen Working Nodes zum Node Controller unterbrochen, wird der Failover ausgelöst. Hinweis: Siehe Heartbeat interval beim Parameter addNode und Parameter externalURL.

Einrichtung des Load-Balancing-Services

Um die Failover-Funktionalität zu verwenden, müssen Sie den Load-Balancing-Service aktivieren. Dazu sind Anpassungen in den folgenden Konfigurationsdateien notwendig.

Anpassung der Konfigurationsdatei ./etc/factory.xml auf allen Nodes des Clusters

Auf allen Nodes (Node Controller und Working Nodes) muss der LoadBalanceService (siehe unten) in der Konfigurationsdatei ./etc/factory.xml aktiviert werden. Wichtiger Hinweis: Der Eintrag muss vor dem StartupService (siehe unten) eingefügt werden, da sonst nicht auf das Failover zugegriffen werden kann.

./etc/factory.xml

<?xml version="1.0"  encoding="ISO-8859-1"?>
<!DOCTYPE Configure PUBLIC
 "-//Lobster//DTD Configure 1.0//EN"
 "http://www.lobster.de/dtd/configure_1_1.dtd">
 
<Configure class="com.ebd.hub.services.ServiceFactory">
    <!-- set a unique id for this factory - needed for cluster and load balance -->
    <Set name="id">factoryID</Set>
	
    .
    .
    .
 
    <!-- service for lb/ha cluster -->
    <Call name="addService">
        <Arg>com.ebd.hub.services.ha.LoadBalanceService</Arg>
        <Arg>etc/loadbalance.xml</Arg>
    </Call>
 
	.
	.
	.
 
    <!-- service to start applications... -->
    <Call name="addService">
        <Arg>com.ebd.hub.services.startup.StartupService</Arg>
        <Arg>etc/startup.xml</Arg>
    </Call>

Parameter	Beschreibung
id	Wird für die Identifizierung und das Laden der Konfiguration benötigt. Wichtiger Hinweis: Muss einzigartig in einem Cluster sein.

Anpassung der Konfigurationsdatei ./etc/loadbalance.xml auf allen Nodes des Clusters

Auf allen Nodes (Node Controller und Working Nodes) muss die Datei ./etc/loadbalance.xml (bzw. die Datei, die in der Konfigurationsdatei ./etc/factory.xml für den LoadBalanceService angegeben wurde) vorhanden sein und angepasst werden.

Auf allen Nodes wird die gleiche Datei verwendet, d. h. Sie müssen diese nur einmal erstellen/anpassen und können diese dann einfach auf alle bestehenden Nodes kopieren.

./etc/loadbalance.xml

<?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE Configure PUBLIC "-//Lobster//DTD Configure 1.0//EN"
 "http://www.lobster.de/dtd/configure_1_1.dtd">
<Configure class="com.ebd.hub.services.ha.LoadBalanceService">
         
    <!-- If loadbalance should be enabled -->
    <Set name="enableLoadbalance">true</Set>
     
    <!-- If failover should be enabled -->
    <Set name="enableFailover">true</Set>
 
    <Set type="int" name="controllerRequestSize">10</Set>
	<Set type="long" name="controllerThreshold">5000</Set>        
 
	<!-- Should nodes try to reconnect after lost connection, interval in seconds -->
    <Set name="reconnectInterval">1</Set>
     
    <!-- Should a failover be done by shutting down the node controller -->
    <Set name="failoverAtShutdown">false</Set>
     
    <!-- Configure when emails should be send -->
    <Set name="emailByLogoff">false</Set>
    <Set name="emailByLogin">false</Set>
    <Set name="emailByLostConnection">false</Set>
     
    <!-- Add more recipients to inform via email -->
    <!-- <Call name="addEmail"><Arg></Arg></Call> -->
 
    <!-- Use external proxy service instead of externalUrl -->
    <!-- <Call name="setProxySettings">
        <Arg>localhost</Arg>
        <Arg type="long">500</Arg>
        <Arg type="long">100</Arg>
        <Arg type="int">9006</Arg>
    </Call> -->
     
    <!-- Behaviour like old externalUrl -->
    <Call name="setExternalUrl">
        <Arg>https://www.google.de</Arg>
        <!-- Timeout for Http-Request -->
        <Arg type="int">1000</Arg>
    </Call>
     
    <!-- Own node information -->
    <Call name="addNode">
        <!-- Nodename (has to be unique in cluster) -->
        <Arg>FactoryID</Arg>
        <!-- Hostname (DNS, IPv4, IPv6) -->
        <Arg>ip-address</Arg>
        <!-- Retries before removing node from cluster -->
        <Arg type="int">3</Arg>
        <!-- Timeout for a read in ms -->
        <Arg type="long">300</Arg>
        <!-- Heartbeat intervall to nodes in ms -->
        <Arg type="long">100</Arg>
        <!-- Port for failover handling -->
        <Arg type="int">2320</Arg>
        <!-- Preferred role in cluster (MASTER, SLAVE) -->
        <Arg>MASTER</Arg>
        <!-- Message port for load balancing -->
        <Arg type="int">8020</Arg>
    </Call>
 
    <!-- Own node information -->
    <Call name="addNode">
        <!-- Nodename (has to be unique in cluster) -->
        <Arg>FactoryID2</Arg>
        <!-- Hostname (DNS, IPv4, IPv6) -->
        <Arg>ip-address</Arg>
        <!-- Retries before removing node from cluster -->
        <Arg type="int">3</Arg>
        <!-- Timeout for a read in ms -->
        <Arg type="long">300</Arg>
        <!-- Heartbeat intervall to nodes in ms -->
        <Arg type="long">100</Arg>
        <!-- Port for failover handling -->
        <Arg type="int">2320</Arg>
        <!-- Preferred role in cluster (MASTER, SLAVE) -->
        <Arg>SLAVE</Arg>
        <!-- Message port for load balancing -->
        <Arg type="int">8020</Arg>
    </Call>
 
</Configure>

Parameter	Beschreibung
enableLoadbalance	Aktiviert das Load Balancing (und damit die Verteilung von Jobs).
enableFailover	Aktiviert das Failover (also die Übernahme der Rolle des Node Controller durch einen Working Node bei Verlust des aktuellen Node Controllers).
controllerRequestSize	Bevor eine Verteilung überhaupt stattfindet, kann man optional eine Anzahl von Jobs hinterlegen, die über den Node Controller abgearbeitet werden. Bei 0 wird sofort an verfügbare Working Nodes abdelegiert, mit z. B. 10 wird erst ab dem 11. aktiven, gleichzeitig laufenden Job abdelegiert. Siehe auch controllerThreshold.
controllerThreshold	Man kann controllerRequestSize noch weiter einschränken, indem man die durchschnittliche Laufzeit (der Statistik) hinzunimmt und z. B. mit 5000 nur Jobs mit einer Laufzeit kleiner 5000 ms in Betracht zieht. Hinweis: Dies kann zur Laufzeit im Control Center geändert werden!
reconnectInterval	Sollte eine Verbindung (Channel) zwischen zwei Nodes verloren gehen, versucht der Service, im angegeben Intervall (in Sekunden) diese wiederherzustellen (Self-healing). Hinweis: Alle Nodes (Node Controller und Working Nodes) sind mit allen anderen Nodes verbunden. Dabei gibt es zwischen zwei Nodes jeweils zwei Channels. Ein einzelner ausgefallener Channel führt dabei noch nicht zu einem Failover. Hinweis: Wir empfehlen das reconnectInterval auf die nächsthöhere Sekunde relativ zum Timeout zu setzen.
failoverAtShutdown	Legt fest, ob ein Failover ausgelöst werden soll, wenn ein Node Controller regulär heruntergefahren wird.
emailByLogoff	Legt fest, ob eine E-Mail versendet wird, wenn sich ein Node aus einem anderen Node ausloggt. Achtung: Führt zu einem erhöhtem E-Mail-Verkehr. Loggt sich ein Node aus einem bestehenden Verbund von drei Nodes aus, werden drei E-Mails versendet.
emailByLogin	Legt fest, ob eine E-Mail versendet wird, wenn sich ein Node in einen anderen Node einloggt. Achtung: Führt zu einem erhöhtem E-Mail-Verkehr. Loggt sich ein Node in einen bestehenden Verbund von drei Nodes ein, werden drei E-Mails versendet.
emailByLostConnection	Legt fest, ob eine E-Mail versendet wird, wenn die Verbindung zu einem Node abbricht. Achtung: Führt zu einem erhöhtem E-Mail-Verkehr. Bricht die Verbindung zu einem Node in einem Verbund ab, werden drei E-Mails versendet.
addEmail	Es können weitere E-Mail-Adressen hinzugefügt werden, die bei emailByLogoff, emailByLogin und emailByLostConnection benachrichtigt werden. Die Standard-E-Mail-Adresse wird aus der Konfigurationsdatei ./etc/startup.xml entnommen.
setExternalUrl	Wenn diese Einstellung gesetzt ist, wird beim Verlust des Node Controllers eine Prüfung auf die angegebene URL durchgeführt. Ist diese zu erreichen, nimmt der Working Node bei der Bestimmung des neuen Node Controllers teil ( Raft-Consensus-Algorithmus ). Wenn nicht, fährt sich der Working Node herunter. Des weiteren wird geprüft, ob andere Working Nodes erreichbar sind. Sollten diese erreichbar sein und noch den aktuellen Node Controller anpingen können, fährt sich der Working Node herunter. Hinweis: Siehe auch Parameter setProxySettings .
setProxySettings	Wird ein externer Proxy konfiguriert, dann wird die externe URL nicht verwendet. Mit einem externen Proxy kann ein Split Brain verhindert werden, er ist aber auch einen Single Point of Failure. Bitte wenden Sie sich an support@lobster.de für weitere Informationen oder eine Einrichtung. Hinweis: Wird keiner der Parameter setExternalUrl und setProxySettings verwendet, wird lediglich eine Erreichbarkeitsprüfung zwischen den Nodes durchgeführt und mit einem Failover oder einem Herunterfahren reagiert.
addNode	Für jeden im Cluster enthaltenen Node (Node Controller und Working Nodes) muss ein Eintrag erstellt werden. Argumente: Nodename Hier muss der Wert des Parameters id in der Konfigurationsdatei ./etc/factory.xml des Nodes verwendet werden. Hostname URL oder IP des Nodes. Retries Anzahl der Heartbeat-Ping-Versuche, bevor der Failover ausgelöst wird. Timeout Die Wartezeit nach einem Heartbeat-Ping in Millisekunden. Heartbeat interval Das Heartbeat-Ping-Intervall in Millisekunden. Siehe auch Timeout und Retries. Failover port Der Port für den Failover-Mechanismus. Default: 2320 Preferred role Verwenden Sie den Wert MASTER für einen Node Controller und SLAVE für einen Working Node. In einem Cluster darf es nur einen Master geben. Die Anzahl der Slaves ist unbeschränkt. Message port for loadbalancing Der Port für den Load-Balancing-Mechanismus. Default: 8020

SAP-RequestListener deaktivieren

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

Ausfall des primären DMZ-Servers

Siehe Abschnitt DMZ-Verbund‌.