Konfiguration des Lobster_data-Node-Controllers
Konfigurationsdatei ./etc/startup.xml
Wie im Kapitel "Allgemeines" bereits beschrieben, dient der Node Controller zur Verteilung der Aufgaben. Die Verteilung kann auf Basis zweier Verfahren erfolgen: "round robin" oder durch Lastfaktor. Bei "round robin" werden an alle vorhandenen Lobster_data-Nodes abwechselnd neue Konvertierungsaufgaben verteilt. Bei Benutzung des Lastfaktors geschieht dies auf Grund der Auslastung der einzelnen Lobster_data-Nodes - diese wird intern durch das Datenvolumen, die anstehenden Aufgaben und verfügbaren Working-Threads berechnet. Kann kein Lobster_data-Node ermittelt werden, übernimmt der Node Controller die Aufgabe selber (weil z. B. noch gar kein Node verfügbar ist).
(1) Um überhaupt ein Load Balance-System zu erhalten, muss bei
<Call name="enableLoadBalance"><Arg type="boolean">true</Arg></Call>der Wert auf true gesetzt werden.
(2) Soll "round robin" verwendet werden, steht in
<Call name="useLoadInformation"><Arg type="boolean">False</Arg></Call>ein false, bei true wird der Lastfaktor zur Ermittlung herangezogen.
(3) Bevor eine Verteilung überhaupt stattfindet, kann man optional eine Anzahl von Jobs hinterlegen, die über den Node Controller abgearbeitet werden. Bei
<Set name="requestSize">0</Set>wird sofort an verfügbare Lobster_data-Nodes abdelegiert, mit z. B.
<Set name="requestSize">10</Set>wird erst ab dem 11. aktiven, gleichzeitig laufenden Job abdelegiert. Man kann dies noch weiter einschränken, indem man die durchschnittliche Laufzeit (der Statistik) hinzunimmt und z. B. mit
<Set name="statisticThreshold">5000</Set>nur Jobs mit einer Laufzeit kleiner 5000 ms in Betracht zieht. Hinweis: Dies kann zur Laufzeit im Control Center geändert werden!
Optional
(a) Werden zwei DMZ-Server betrieben - oder - ein zweiter Node Controller steht als Cold-Standby-System zur Verfügung, kann mit
<Set name="informDMZOfNewPeer">True</Set>bestimmt werden, das beim Starten des Node Controllers die DMZ auf die neu gestartete Instanz verweist. In diesem Fall werden noch alle offenen Übertragungen an den neuen Node Controller umgeleitet.
(b) Ist das ./conf-Verzeichnis nicht gemountet, können alle Veränderungen in ./conf und ./etc/admin/datawizard durch den Node Controller an die aktiven Clients weitergeleitet werden. Hierzu muss
<Set name="replicateFiles">True</Set>eingestellt sein. Mit
<Set name="replicateAdminFiles">True</Set>können alternativ nur Dateien unter ./etc/admin/datawizard repliziert werden.
(c) Tragen Sie alle Mitglieder des Load-Balance-Verbunds in der Konfigurationsdatei ./etc/admin/dazawizard/lb_nodes.properties ein (Format ist immer factory-id=IP-oder-Hostname:Port-MessageService). Diese Datei wird automatisch an alle Mitglieder verteilt und muss nur auf dem Node Controller gepflegt werden. Ist eine gültige Konfigurationsdatei vorhanden, werden alle dort hinterlegten (aktiven) Nodes informiert, das der soeben gestartet Node Controller als "aktiver" gilt und die Nodes schwenken auf ihn um.
(d) Wird Lastfaktor statt "round-robin" verwendet, und ist die Hardware der Nodes unterschiedlich, so kann z. B. mit
<Set name="performanceFacfor">1.3</Set>pro Node ein Korrekturfaktor hinterlegt werden, der einen Wert > 1 haben muss (dieser Wert wird mit dem akt. Lastfaktor multipliziert). Beispiel: Nehmen wir an wir hätten einen Working Node mit leistungsfähiger Hardware und einen anderen Working Node mit weniger leistungsfähiger Hardware und für beide Working Nodes wurde (ohne Berücksichtigung des Performancefaktors) der gleiche Lastfaktor berechnet. Nun geben wir dem Working Node mit der weniger leistungsfähigeren Hardware einen Performancefaktor von 1.3, womit dessen Lastfaktor multipliziert wird, d. h. er hat nun einen höheren Lastfaktor und neue Last würde deshalb an den Working Node mit der leistungsfähigeren Hardware verteilt werden.
Damit ist die Konfiguration des/der Node Controller(s) abgeschlossen.