Configuration of a Lobster_data Node Controller

Configuration File ./etc/startup.xml


images/download/attachments/21306067/media_1343634366712-version-4-modificationdate-1638849588643-api-v2.png


As already described in chapter 'General remarks', the node controller distributes jobs. The distribution can be based on one of two methods: The round-robin or the load factor method. The round-robin alternately delegates tasks to the existing Lobster_data nodes. The load factor method, on the other hand, uses the workload (which internally is calculated by the data volume, the tasks at hand, and the available worker threads) of the single Lobster_data nodes to determine the node to use. If no node can be determined, the node controller itself (e.g. because there is no node so far) takes the task.


(1) To set up a Load Balance System you have to insert the entry


<Call name="enableLoadBalance"><Arg type="boolean">true</Arg></Call>


in the configuration file ./etc/startup.xml.


(2) Use false if you want to use the round-robin method and true for the load factor method in the following entry.


<Call name="useLoadInformation"><Arg type="boolean">false</Arg></Call>


(3) You can set the number of jobs the node controller processes itself before it delegates jobs to Lobster_data nodes. The setting


<Set name="requestSize">0</Set>'


will immediately delegate jobs to Lobster_data nodes whereas the setting


<Set name="requestSize">10</Set>


will only start delegating jobs if the 11th job is running simultaneously. This setting can further be restricted by considering the average runtime (statistic) of a job. The setting


<Set name="statisticThreshold">5000</Set>


will only consider jobs with an average runtime less than 5000 ms. Note: This setting can be modified during runtime in the Control Center!

Optional


(a) If you use two DMZ servers or have a second node controller in a cold standby system, set the entry


<Set name="informDMZOfNewPeer">True</Set>


to true to notify the DMZ to reference to the newly started node controller. In that case, all the pending transmissions will be delegated to the new node controller.


(b) If the directory ./conf is not mounted, all changes in ./conf and ./etc/admin/datawizard can be forwarded to the active Lobster_data nodes by the node controller by setting entry


<Set name="replicateFiles">True</Set>


to true. Alternatively, setting


<Set name="replicateAdminFiles">True</Set>


only replicates the files in ./etc/admin/datawizard.


(c) Enter all nodes of the Load Balancing system in configuration file ./etc/admin/dazawizard/lb_nodes.properties (the format is always factory-id=IP-or-hostname:Port-MessageService). This file only has to be maintained on the node controller. If there is a valid configuration file, all the active Lobster_data nodes configured in this file will be notified that the started node controller is now the 'active' one and all the active Lobster_data nodes will reference to the started node controller from that moment on.


(d) If the performance factor method is used and the hardware of the Lobster_data nodes varies, the entry


<Set name="performanceFactor">1.3</Set>


can be used to compensate performance differences. The value has to be > 1 and will be used to multiply the load factor with. Example: Let's assume we have one working node with powerful hardware and another working node with less powerful hardware and the same load factor was calculated for both working nodes (without considering the performance factor). Now we give the working node with the less powerful hardware a performance factor of 1.3 and we multiply it with its load factor, i.e. it now has a higher load factor and new load would therefore be distributed to the working node with the more powerful hardware.