2.2.5 ノード間負荷バランス機能
OpenTP1では，RPCによる要求が特定のノードに集中しないようにノード間で負荷を分散する機能があります。これをノード間負荷バランス機能といいます。
ノード間負荷バランス機能を使用するためには，負荷分散の前提として次の条件を満たしている必要があります。
-
複数のノードに同一のサービスを提供するユーザサーバが起動されていること。
-
各OpenTP1ノードはシステム共通定義のall_nodeオペランドに自分以外のノードを定義して，お互いのOpenTP1ノードで起動されているユーザサーバの情報（ネーム情報）をやり取りしていること。
ここでは，OpenTP1のノード間負荷バランス機能を使用する場合のTP1/Client/J側，TP1/Server側の関連する定義，処理，およびRPCの処理を説明します。
(1) サーバ側の判断で負荷分散を行う場合
TP1/Serverのスケジュールサービスが，ノードのスケジュール状態に応じて，より効率的に処理できるノードへ負荷を分散させます。
(a) TP1/Client/J側の定義
TP1/Client/J側の定義で必要な設定はありません。
(b) TP1/Server側の定義
TP1/Server側の定義では，次の設定をする必要があります。
-
スケジュールサービス定義に次のオペランドを指定または省略する。
scd_this_node_first = N （デフォルト）
scd_announce_server_status = Y （デフォルト）
(2) サーバからの負荷情報からクライアント側で判断する場合
サーバから得たサーバの負荷レベルを基に，サービス要求を行うクライアントがOpenTP1ノードを決めてRPCを実行します。
(a) TP1/Client/J側の定義
TP1/Client/J環境定義で次の設定をする必要があります。
-
dcnamuse=Y
-
dccltloadbalance=Y
(b) TP1/Server側の定義
TP1/Server側の定義では，次の設定をする必要があります。
-
スケジュールサービス定義に次のオペランドを指定または省略する。
scd_announce_server_status=Y（デフォルト値）
(3) RPC種別による動作の違い
(a) リモートAPI機能を組み合わせた場合
サーバ側の判断で負荷分散を行います。
(b) スケジューラダイレクト機能を組み合わせた場合
スケジューラダイレクト機能を使用したRPCでは，スケジュールを依頼するOpenTP1ノードが複数ある場合，dchostオペランドに指定された順番にスケジュールを依頼します。RPCごとにサービス要求先スケジューラをラウンドロビン方式で分散させる場合は，TP1/Client/J環境定義にdcscdhostchange=Yを指定します。
最初のRPCでのサービス要求時に，サービス要求先スケジューラをランダムに選択するには，TP1/Client/J環境定義にdchostselect=Yを指定します。
(c) ネームサービスを使用したRPCを組み合わせた場合
ネームサービスを使用したRPCでは，窓口となるTP1/Serverのネームサービスにサービス情報を問い合わせ，ネームサービスからの応答メッセージを基にサービス要求先スケジューラを決定します。
RPCごとにサービス要求先スケジューラを分散させる場合は，TP1/Client/J環境定義にdccltloadbalance=Yを指定します。これによって，TP1/Client/Jは，ネームサーバから複数のサービス要求先スケジューラの情報を取得し，負荷レベルが最も低いサービス要求先スケジューラの情報をキャッシュに格納します。
キャッシュに格納されるサービス要求先スケジューラの情報は，1つだけではなく，複数の場合もあります。
キャッシュに格納されたサービス要求先スケジューラの情報が複数ある場合，最初のサービス要求先スケジューラは，ランダムに選択されます。RPCでのサービス要求が2度目以降の場合は，サービス要求先スケジューラの情報を取得するためにキャッシュを参照し，RPCごとにラウンドロビン方式でサービス要求先スケジューラを切り替え，分散させます。
クライアントからのRPC実行時に，このキャッシュ領域中に該当するサービス情報が存在する場合には，窓口となるTP1/Serverのネームサービスに対してサービス情報の問い合わせを行いません。クライアントではLRU（Least Recently Used）方式でキャッシュを管理しているため，キャッシュ領域が不足した場合には参照されていないサービス情報から順に削除します。また，TP1/Client/J環境定義のdccltcachetimオペランドに指定した有効時間が過ぎたサービス情報は，RPC実行時にキャッシュ領域から削除され，ネームサービスに対してサービス情報を問い合わせます。
- 注意事項
-
-
TP1/Client/J環境定義のdccacheオペランドの指定値を大きくすると，多くのサービス情報を格納でき，窓口となるTP1/Serverのネームサービスとの通信回数を削減できます。ただし，多くのキャッシュ領域中からサービス情報を検索するのでオーバヘッドが掛かります。
-
TP1/Client/J環境定義のdccltcachetimオペランドの指定値を小さくすると，古いサービス情報はただちに削除され，窓口となるTP1/Serverのネームサービスに新しいサービス情報を問い合わせます。この場合，常に最新のサービス情報をキャッシュ領域に保持できるため，サーバの負荷に応じてRPC要求を振り分けられます。ただし，ネームサービスとの通信回数が増え，また，キャッシュ領域の書き換え処理にもオーバヘッドが掛かります。
-
TP1/Client/J環境定義のdccltcachetimオペランドの指定値を大きくすると，窓口となるTP1/Serverのネームサービスとの通信回数を削減できます。ただし，SPPの状態変化への対応が遅れるため，SPPが停止したノードのスケジューラに対してRPC要求を実行してしまうことがあります。
-
(d) 通信先を指定したRPCを組み合わせた場合の動作
通信先を指定したRPCを使用した場合，ノード間負荷バランス機能は使用できません。