To use the inter-node load balancing facility, the following conditions must be satisfied:

• A user server providing the same service to multiple nodes must be active.
• Each OpenTP1 node must have the other nodes defined for the all_node operand of the system common definition so that the OpenTP1 nodes can exchange the information (name information) of the user servers operating on the nodes among them.

Note

Inter-node load balancing can be achieved when the user server operates similarly for all nodes. If the conditions listed below vary greatly among the selected nodes, inter-node load balancing may be difficult. For this reason, do not place service groups with the same name on multiple nodes.

• Communication costs such as the line fees for public lines
• Line speed
• Line quality
• Node performance

There are the following two operation modes for using the inter-node load balancing facility:

Mode where the server side determines how to perform load balancing

The scheduler on the server side (TP1/Server Base) transfers a request to the least loaded node for processing.

Mode where the client side determines how to perform load balancing based on the load information from the server

In this mode, the processing varies depending on the program used for the client.

• TP1/Client/P or TP1/Client/W is used for the client.
  The client side (TP1/Client/P or TP1/Client/W) determines to which OpenTP1 node the service request should be directed based on the information of the server load level acquired from the server, and then performs an RPC.
  
• TP1/Server Base is used for the client.
  The client side (TP1/Server Base) already knows the load level of the server which is going to issue a request. Therefore it performs an RPC to the least loaded node from the start. Upon receiving a request, the scheduler does not perform a transfer based on the load level. The scheduler instead performs the processing within its local node if the request can be processed within the local node. The scheduler transfers the request to another node only if the server is blocked, or if the server of the local node has a load level of LEVEL2 and another node has a server with a lower load level.
  

To use the inter-node load balancing facility, specify the following definitions:

Table 3-6 Definitions for using inter-node load balancing

Operation mode for inter-node load balancing	Type	Definition
Load balancing determined on the server side	Server (TP1/Server Base)	Schedule service definition: set scd_this_node_first=N (default)set scd_announce_server_status=Y (default)
	Client (TP1/Client/P, TP1/Client/W)	Client environment definition: dcscddirect=Y (for TP1/Client/P) dchostselect=Y (only when you want to change the schedule request randomly)
Load balancing determined on the client side (when using TP1/Client/P, TP1/Client/W for the client)	Server (TP1/Server Base)	Schedule service definition: scd_this_node_first=N (default) scd_announce_server_status=Y (default)
	Client (TP1/Client/P, TP1/Client/W)	Client environment definition: dccltloadbalance=Ydccltcachetim=xx (seconds)
Load balancing determined on the client side (when using TP1/Server Base for the client)	Server (TP1/Server Base)	Schedule service definition: scd_this_node_first=N (default) scd_announce_server_status=Y (default)
	Client (TP1/Server Base)

When scd_announce_server_status=Y is specified in the schedule service definition, OpenTP1 notifies all the nodes of the server's load status at specified intervals (of 30 seconds or more). OpenTP1 selects a node according to the server's load status and schedules the execution of the service request.

When scd_announce_server_status=N" is specified, the server's load status is not reported to the other nodes. OpenTP1 randomly selects a node and schedules the server.

For all the nodes in the distributed environment, the specification of the scd_announce_server_status operand must be same. If the specification differs, the load is concentrated upon particular nodes.

When both of the following conditions apply, specify scd_announce_server_status=N:

• The same service group does not exist on multiple nodes.
• Less communication is preferred because a high cost communication line is being used or for some other reason.

In this case, inter-node load balance is unnecessary. Therefore, the server's load status does not need to be reported to the other nodes. When scd_announce_server_status=Y is specified, a line is used to report the server's load status. When a server is activated at only one node, specify scd_announce_server_status=N to suppress reporting the server's load status.

The inter-node balancing does not always schedule the processing to the local node even when the server is placed at the local node.

When the requested server is placed at the local node, to give that server the precedence of scheduling, specify scd_this_node_first=Y in the schedule service definition. If the requested server is not placed at the local node, if the request cannot be scheduled to the server at the local node due to overload or shutdown, the request is scheduled to another node.

This operation is effective when less inter-node communication is required.

The following table shows the combinations of the scd_announce_server_status and scd_this_node_first operands.

Table 3-7 Combinations of scd_announce_server_status and scd_this_node_first operands

Operand		scd_announce_server_status
		Y	N
scd_this_node_first	Y	Reports the server's load status to the other nodes. The load between nodes is balanced but the server at the local node has precedence.	Does not report the server's load status to the other nodes. The request is scheduled to the server of a randomly selected node. When the server is at the local node and the request can be scheduled to it, the request is scheduled to the local node.
	N	Reports the server's load status to the other nodes. The load between nodes is balanced. The request is scheduled to the node of the least-loaded schedulable server.	Does not report the server's load status to the other nodes. The request is scheduled to the server of a randomly selected node. The request may not be scheduled to the server of the local node even when the requested server is at the local node.

The following table shows the operations when the inter-node load balancing facility is used with other facilities.

Table 3-8 Operations of inter-node load balancing facility used with other facilities

When using	Operation mode of inter-node balancing facility	Operation
Permanent connection by TP1/Client	The server side determines how to perform load balancing. The client side determines how to perform load balancing (TP1/Client/P or TP1/Client/W is used for the client).	The CUP execution process of TP1/Server Base performs an RPC in the node that established the permanent connection. This is the same operation as in the case when the client side determines how to perform load balancing (TP1/Server Base is used for the client).
Transaction control API by TP1/Client	The server side determines how to perform load balancing. The client side determines how to perform load balancing (TP1/Client/P or TP1/Client/W is used for the client).	The transaction delegated execution process of TP1/Server Base performs an RPC. This is the same operation as in the case when the client side determines how to perform load balancing (TP1/Server Base is used for the client).
Remote API facility	The server side determines how to perform load balancing. The client side determines how to perform load balancing (TP1/Client/P or TP1/Client/W is used for the client). The client side determines how to perform load balancing (TP1/Server Base is used for the client).	The RAP-processing server of TP1/Server Base actually performs an RPC. This is the same operation as in the case when the client side determines how to perform load balancing (TP1/Server Base is used for the client).

You can specify the following as the extended facilities for distributing the load between nodes:

• Specifying the rate of schedules made to LEVEL0 nodes
  By specifying the schedule_rate operand in the schedule service definition, you can make schedules to LEVEL0 load level nodes with priorities defined.
  
• Specifying the load check interval
  By specifying the loadcheck_interval operand in the user service definition and the user service default definition, you can specify how often to check the load for each service group.
  
• Specifying the threshold of load levels
  By specifying the levelup_queue_count operand and the leveldown_queue_count operand in the user service definition and the user service default definition, you can specify the threshold (number of remaining server requests) that determines the load level for each service group.
  
• Specifying the number of retries to be made if a communication error occurs
  By specifying the scd_retry_of_comm_error operand in the schedule service definition, you can retry scheduling to nodes other than the failed node even if a communication error occurs while service requests are scheduled.
  If you do not make this specification, no re-scheduling is performed and an error is returned if a communication error occurs.
  To use this facility, TP1/Extension 1 needs to be installed beforehand. If TP1/Extension 1 is not installed, the operation is not guaranteed.