Failover-Konzept
Beim Failover-Konzept geht es darum die Ausfallsicherheit des Node Controllers zu gewährleisten. Wird die Verbindung eines Nodes zum Node Controller unterbrochen, weil dieser ausfällt, wird der nächste verfügbare Node zum Node Controller und alle restlichen Nodes verbinden sich mit dem neuen Node Controller. Ist der ursprüngliche Node Controller wieder verfügbar, wird dieser zu einem normalen Node.
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> </New> </Arg></Call>Die Bedeutung der Parameter ist dabei die folgende.
|
port |
Der Port, über den die "Ping"-Messages ausgetauscht werden. |
|
heartbeat |
Legt die Periode der Ping-Sequenz in Millisekunden fest. |
|
externalURL |
Muss eine erreichbare HTTP(S)-URL sein, mit der die Maschinen überprüfen können, ob sie selber vom Netz getrennt sind oder der Node Controller. |
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 (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:8020WorkNode1=192.168.132.55:8020NodeContr2=192.168.132.54:8020NodeContr1=192.168.132.53:8020WorkNode3=192.168.132.57:8020Grundsä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.