OpenTP1 Version 7 TP1/Client User's Guide TP1/Client/W, TP1/Client/P

[Contents][Index][Back][Next]

2.3.6 Inter-node load-balancing facility

OpenTP1 has the inter-node load-balancing facility that distributes the load across nodes so that the RPC-based requests do not concentrate on a specific node.

To use the inter-node load-balancing facility, a load-balancing environment must satisfy the following conditions:

This subsection explains the related definitions, processing, and RPC handling of the client side and the server side when using the inter-node load-balancing facility.

Organization of this subsection
(1) Server-centric load balancing
(2) Client-centric load balancing by using the load information from the server
(3) Operations when the load-balancing facility is used with other facilities

(1) Server-centric load balancing

The schedule service of TP1/Server distributes the load to the nodes that can execute more efficiently according to the schedule status of the nodes.

(a) Definition on the client side

Specify dcscddirect=Y in the client environment definition. By this specification, the clients request the load-balancing from the schedule service of TP1/Server. Therefore, the OpenTP1 node containing the governing schedule service must be defined on the client side.

The OpenTP1 nodes request scheduling in the order in which they are specified in the dchost operand. To make the OpenTP1 nodes request scheduling at random, you must also add dchostselect=Y in the definition.

(b) Definition on the server side

On the server side, configure either of the following settings:

(2) Client-centric load balancing by using the load information from the server

To use this feature, define the following:

With this specification, the client acquires the server's load level from the server to determine the OpenTP1 node from which the client requests a service. The client then executes an RPC.

The client asks the name service of TP1/Server, which functions as a gateway for clients, for the information about the service. The client then temporarily stores the service information, including the server load level, in a cache area whose size is specified in the DCCACHE operand in the client environment definition.

If the applicable service information exists in the cache area when the client executes the RPC, the client does not ask the name service of TP1/Server that is used as a gateway for service information.

Since clients manage the cache using the Least Recently Used (LRU) method, service information is deleted starting from the least referenced information when the cache areas run short. Also, service information that has exceeded its effective period specified in the DCCLTCACHETIM operand in the client environment definition is deleted from the cache areas when RPCs are executed. When this happens, the clients ask the name service for service information.

When you increase the value specified for the DCCACHE operand in the client environment definition, a large amount of service information can be stored. This reduces the number of communications with the TP1/Server name service that is used as a gateway. However, since service information is retrieved from many cache areas, more overhead is required.

When you decrease the value specified for the DCCACHE operand in the client environment definition, the information about the services provided by applicable SPP on multiple nodes may exceed the cache areas. In such a case, even if you re-execute an RPC from the client, the RPC-based request is not sent to the SPP on the node whose service information is not stored in a cache area.

When you decrease the value specified for the DCCLTCACHETIM operand in the client environment definition, old service information is immediately deleted and the client asks the TP1/Server name service that is used as a gateway for new service information. Since new service information is always stored in the cache areas, RPC-based requests can be distributed in accordance with the load of the servers. However, the number of communications with the name service increases and the overhead for rewriting the cache areas also increases.

When you increase the value specified for the DCCLTCACHETIM operand in the client environment definition, the number of communications with the TP1/Server name service that is used as a gateway can be reduced. However, the reaction to status changes of SPPs is delayed, and RPC-based requests may be sent to an inactive SPP. In this case, TP1/Client deletes the applicable service information from the cache areas before you send an RPC-based request to another SPP. Then, TP1/Client sends a request to the TP1/Server name service that is used as a gateway to delete the applicable service information.

In a multi-node server configuration with 129 or more servers, when nam_service_extend=1 is specified in the name service definition for the TP1/Server that is used as a gateway, specify DCCLTNAMEXTEND=1 in the client environment definition. By doing so, you can increase the maximum number of service information items that a client can acquire at a time from the name service, from 128 to 512.

(3) Operations when the load-balancing facility is used with other facilities

Table 2-1 shows the operations when the load-balancing facility is used with other facilities.

Table 2-1 Operations when the load-balancing facility is used with other facilities

Condition Operation
When a permanent connection is used in the client The CUP executing process on the server side issues RPCs on the node to which a permanent connection is established. In this case, the load-balancing facility operates in the same way as in (2)(b) above.
When the transaction control API is used in the client The alternate transaction-executing process on the server side issues RPCs. In this case, the load-balancing facility operates in the same way as in (2)(b) above.
When the remote API facility is used The RAP-processing server on the server side issues RPCs. In this case, the load-balancing facility operates in the same way as in (2)(b) above.