実行中のユーザサーバに対して，さらにサービス要求が来た場合でも，ユーザサーバの処理を新しい別のプロセスで実行できます。このように，一つのユーザサーバの処理を，別のプロセスで並行して実行する機能をマルチサーバといいます。

マルチサーバを使えるのは，スケジュールキューを使うSPP（キュー受信型サーバ），およびMHPです。ソケット受信型サーバの場合はマルチサーバを使えません。ソケット受信型サーバには，使うプロセスは一つだけと，ユーザサービス定義で指定してください。

ユーザサービス定義でマルチサーバを指定したUAPのプロセスを，OpenTP1の稼働中にいつも確保しておくことも，動的に確保することもできます。いつも確保されているプロセスを常駐プロセスといいます。また，稼働中には確保されていなくて，必要に応じて起動されるプロセスを非常駐プロセスといいます。

マルチサーバを使う場合，使うプロセスの最大値をユーザサービス定義で設定しておきます。常駐プロセスを複数個指定していれば，指定した数だけ並行してプロセスが起動されます。また，非常駐プロセスを複数個指定していれば，指定した数だけ動的にプロセスが起動されます。

プロセスを非常駐プロセスと設定しておくと，OpenTP1システム内のメモリ領域を効率良く使えます。また，プロセスを常駐プロセスと設定しておくと，そのユーザサーバの処理は非常駐プロセスに比べて速くなります。

システムのメモリに空きがない場合，非常駐プロセスは稼働中の非常駐プロセスが終了してから実行されます。

プロセスを常駐とするか非常駐とするかは，ユーザサービス定義でユーザサーバの起動プロセス数を事前に指定しておきます。

スケジュールキューにあるサービスの要求数に応じて，非常駐プロセスの数を増やしたり減らしたりする機能をマルチサーバ負荷バランス機能といいます。

非常駐プロセスをいつ起動するかは，ユーザサービス定義のbalance_countオペランドに指定する値で決まります。（balance_countオペランドに指定した値　×　起動中のプロセス）の数を超えてサービス要求が滞留したときに，OpenTP1は非常駐プロセスを起動します。スケジュールキューに滞留しているサービス要求の数が（balance_countオペランドに指定した値　×　起動中のプロセス）の数以下になると，OpenTP1は非常駐プロセスを終了させます。

常駐/非常駐プロセスによるマルチサーバの概要を次の図に示します。

図3-51　常駐/非常駐プロセスによるマルチサーバの概要

一つ一つのユーザサーバには，ユーザサービス定義でスケジュールの優先度（スケジュールプライオリティ）を付けることができます。優先度が高いユーザサーバの非常駐プロセスは，ほかの非常駐プロセスに比べて優先的にスケジュールされます。

スケジュールの優先度の概要を次の図に示します。

図3-52　スケジュールの優先度の概要

非常駐プロセスを使用する場合，一つのサービス要求ごとに実行プロセスを起動し直すことができます。この機能を，非常駐UAPプロセスのリフレッシュ機能といいます。この機能を使用することで，リエントラント構造ではないUAPの実行もできるようになります。この機能は，非常駐プロセスだけで構成されるUAPの場合に使用できます。

この機能を使用するためには，ユーザサービス定義またはユーザサービスデフォルト定義に，scd_refresh_processオペランドを指定します。また，この機能は1プロセスが処理するサービス要求数（ユーザサービス定義のbalance_countオペランドの指定値）が0の場合にだけ使用できます。

非常駐UAPプロセスのリフレッシュ機能の詳細については，マニュアル「OpenTP1 プログラム作成の手引」を参照してください。

SPPに要求されたサービスの処理に多くのプロセスが必要な場合，他ノードにある同じサービスグループ名のSPPに処理を分担できます。この機能をノード間負荷バランス機能といいます。ノード間負荷バランス機能を使用するためには，負荷分散の前提として次の条件を満たしている必要があります。

• 一つのLANの中で，複数のノードに同一のサービスを提供するユーザサーバが起動されていること。
• 各OpenTP1ノードが，システム共通定義のall_nodeオペランドに自分以外のノードを定義することによって，お互いのOpenTP1ノードで起動されているユーザサーバの情報（ネーム情報）をやり取りしていること。

サービス要求は，任意に選ばれたノードのユーザサーバに渡されます。さらに，OpenTP1では，スケジュールするノードのサーバ情報を参照して，スケジュール性能が低くなっているノードは選ばれにくいように制御しています。そのため，自ノードにユーザサーバがあり，スケジュールできる状態でも，自ノードのユーザサーバに渡されるとは限りません。自ノードのユーザサーバを優先するには，スケジュールサービス定義のscd_this_node_firstオペランドにYを指定します。これによって，自ノードのユーザサーバのスケジュール性能が低いときだけ，ほかのノードのユーザサーバにスケジュールできます。

ノード間負荷バランス機能は，ノード間でユーザサーバの動作条件が同じであることを前提としています。選択されるノードによって次に示す条件が大きく異なる場合は，ノード間負荷バランス機能に不適当な環境ですので，同じ名前のサービスグループを複数のノードに配置しないでください。

• 公衆回線の回線料金などの運用コスト
• 回線速度
• 回線品質
• ノードの単体性能

ユーザサーバにスケジュールするときに参照するサーバ情報は，各ノードから通知されます。同じサービスグループ名のSPPが複数のノードにないシステムでは，サーバ情報を通知する必要がなく，むだな通信となります。特に，公衆回線を使用する場合，不要な回線料金が課金されます。したがって，同じサービスグループ名が複数のノードにないシステムでは，すべてのノードのスケジュールサービス定義のscd_announce_server_statusオペランドにNを指定して，サーバ情報の通知を抑止してください。

ノード間で負荷分散するSPPは，キュー受信型サーバでもソケット受信型サーバでもかまいません。ただし，ソケット受信型サーバの場合は，OpenTP1のスケジュール性能を参照する制御はしていません。

ノード間負荷バランス機能で負荷を分散できるノードの数は，最大128です。

ノード間負荷バランス機能の概要を次の図に示します。

図3-53　ノード間負荷バランス機能の概要

サービス要求は各ノードの負荷レベルに応じて，スケジュールされます。次に示す負荷レベルがあります。

• LEVEL0
  小さい負荷です。通常，サービス要求はLEVEL0またはLEVEL1のノードにスケジュールされます。
  
• LEVEL1
  やや大きい負荷です。障害などによる再スケジュール時には，サービス要求はLEVEL1のノードにスケジュールされにくくなります。ただし，再スケジュール時にLEVEL1またはLEVEL2のノードしかない場合は，それらのノードにスケジュールされます。
  
• LEVEL2
  大きい負荷です。通常，サービス要求はLEVEL2のノードにスケジュールされません。ただし，LEVEL2のノードしかない場合は，LEVEL2のノードにスケジュールされます。
  

各ノードの負荷レベルは，負荷監視インタバルごとに監視されます。その際，今回の負荷レベルは，前回の負荷レベル，キューイング数，サービス要求滞留数，およびサーバ処理率によって決定されます。

負荷レベルの決定条件について次の表に示します。

表3-11　負荷レベルの決定条件

前回の負荷レベル	キューイング数：Q	サービス要求滞留数：q	サーバ処理率：X	今回の負荷レベル
LEVEL0	Q ≧ 1	−	X ＜ 50	LEVEL1
LEVEL1	Q ≧ 1	−	75 ≦ X	LEVEL0
			50 ≦ X ＜ 75	LEVEL1
			X ＜ 50	LEVEL2
LEVEL2	−	q ＝ 0	−	LEVEL0
		q ≧ 1		LEVEL2

（凡例）

−：無視します。

キューイング数

負荷監視インタバル間にスケジュールキューにキューイングされたサービス要求数です。

サービス要求滞留数

負荷監視時にスケジュールキューに滞留しているサービス要求数です。

サーバ処理率

次に示す計算式から算出される処理率です。

サーバ処理率＝（サービス処理数／（キューイング数＋サービス要求滞留数））×100

サービス処理数は，負荷監視インタバル間で処理したサービス要求数です。

負荷レベルに変更があった場合は，各ノードのネームサービスにサーバ情報が通知され，サーバ情報が更新されます。また，ユーザサービス定義のloadlevel_messageオペランドを使用すると，負荷レベルの変更を通知するメッセージを出力できます。

ノード間負荷バランス機能を使用する場合のTP1/Server Base側，TP1/Client側の関連する定義と処理，およびRPCの処理を説明します。

(a)　サーバ側の判断で負荷分散を行う場合

TP1/Server Baseのスケジュールサービスが，ノードのスケジュール状態に応じて，より効率的に処理できるノードへ負荷を分散させます。

サーバ（TP1/Server Base）側の定義

TP1/Server Baseの定義では，次のどちらかの設定をする必要があります。

• スケジュールサービス定義のオペランドに次の設定をする。
  set scd_this_node_first = N （デフォルト）
  set scd_announce_server_status = Y （デフォルト）
  
• スケジュールサービス定義を省略する。

クライアント（TP1/Client）側の定義

クライアント環境定義に「dcscddirect=Y（TP1/Client/Pの場合）」を定義します。

これによって，TP1/Clientは，TP1/Server Baseのスケジュールサービスに負荷分散を依頼するため，TP1/Clientの定義でどのOpenTP1ノードのスケジュールサービスに判断を依頼するかを指定します。

この場合，スケジュールを依頼するOpenTP1ノードは，dchostオペランドに指定された順番にスケジュールを依頼します。dchostオペランドに書かれた順番ではなく，スケジュールを依頼するOpenTP1ノードをランダムに指定したい場合は，さらに「dchostselect=Y（TP1/Client/Pの場合）」を追加して定義する必要があります。

(b)　サーバからの負荷情報からクライアント側で判断する場合

●クライアントがTP1/Clientのとき

サーバ（TP1/Server Base）側の定義

TP1/Server Baseの定義では，次のどちらかの設定をする必要があります。

• スケジュールサービス定義のオペランドに次の設定をする。
  set scd_this_node_first = N （デフォルト）
  set scd_announce_server_status = Y （デフォルト）
  
• スケジュールサービス定義を省略する。

クライアント（TP1/Client）側の定義

クライアント環境定義で「dccltloadbalance = Y（TP1/Client/Pの場合）」を定義します。

これによって，TP1/Server Baseから得たサーバの負荷レベルを基に，TP1/Clientでサービス要求を行うOpenTP1ノードを決めてからRPCを行います。

この場合，dccltcachetimで指定された時間（秒）だけ，サーバの負荷レベルを含む情報を一時的にdccacheオペランドで指定された大きさの領域に保持します。つまり，dccltcachetimオペランドで指定した値を短くすることで，より新しいサーバの負荷レベルに基づいてRPCの要求先が決まるということになります。

その反面，負荷レベルの取得のために，頻繁にTP1/Server Baseのネームサービスとの通信が発生することを考慮する必要があります。

●サーバ，クライアントともTP1/Server Baseのとき

サーバ側，およびクライアント側の両方に，次のどちらかの設定をする必要があります。

• スケジュールサービス定義のオペランドに次の設定をする。
  set scd_this_node_first = N （デフォルト）
  set scd_announce_server_status = Y （デフォルト）
  
• スケジュールサービス定義を省略する。

この形態では，TP1/Server Baseはこれから要求を出そうとしているサーバの負荷レベルをすでに知っているので，最初から負荷レベルが低いノードに対してRPCを行います。この要求を受け取った時点で，スケジュールサービスは，負荷レベルの評価による転送はしないで，自ノードで要求を処理できる状態であれば，自ノードで処理します。サーバが閉塞している場合，または自ノードのサーバの負荷レベルがLEVEL2で，他ノードに自ノードより負荷レベルの低いサーバがある場合だけ，ほかのノードに対して処理要求を転送します。

(c)　ノード間負荷バランス機能と別の機能を組み合わせた場合の動作

ノード間負荷バランス機能と別の機能を組み合わせた場合の動作を，次の表に示します。

表3-12　ノード間負荷バランス機能と別機能を組み合わせた場合の動作

組み合わせる機能	動作
TP1/Clientで常設コネクションを使用した場合	TP1/Server BaseのCUP実行プロセスが，常設コネクションを張ったノードでRPCを行う。 (b)の「サーバ，クライアントともTP1/Server Baseのとき」と同じ動作になる。
TP1/Clientでトランザクション制御APIを使用した場合	TP1/Server BaseのトランザクショナルRPC実行プロセスがRPCを行う。 (b)の「サーバ，クライアントともTP1/Server Baseのとき」と同じ動作になる。
リモートAPI機能を使用した場合	TP1/Server BaseのrapサーバがRPCを行う。 (b)の「サーバ，クライアントともTP1/Server Baseのとき」と同じ動作になる。

ユーザは次に示す指定ができます。

• LEVEL0のノードへのスケジュール比率の指定
  スケジュールサービス定義のschedule_rateオペランドを指定することによって，LEVEL0のノードにスケジュールする比率（%）を指定できます。
  TP1/Clientのクライアント環境定義のDCSCDDIRECTオペランドにYを指定してサービス要求をする場合だけschedule_rateオペランドは有効です。
  ただし，スケジュールサービス定義のscd_this_node_firstにYを指定している場合には，自ノードに優先的にスケジュールされます。
  次にschedule_rateオペランドに80を指定した場合のスケジュールについて説明します。サービス要求数は10とします。
  
  1. スケジューラは，ネームサービスから全ノードの負荷情報を取得し，LEVEL0とLEVEL1のノード数をカウントします。
  2. 1.でカウントしたノード数をschedule_rateオペランドの指定数で重みづけして，LEVEL0のノードにスケジュールする比率を求めます。
     LEVEL0：LEVEL1 ＝ 80×3：20×2 ≒ 85：15
     
  3. 2.で求めた比率でLEVEL0のノードの一つを選択して，サービス要求をスケジュールします。
  LEVEL0のノードへのスケジュールについて次の図に示します。
  

  図3-54　LEVEL0のノードへのスケジュール

  

• 負荷監視インタバル時間の指定
  ユーザサービス定義およびユーザサービスデフォルト定義のloadcheck_intervalオペランドを指定することによって，サービスグループごとに負荷監視インタバル時間を指定できます。負荷監視時に負荷レベルの変更があった場合は，各ノードのネームサービスにサーバ情報が通知されます。そのため，負荷監視インタバルごとにサーバ情報がネットワーク上に送信される可能性がありますので，必要以上に小さい値を指定しないでください。
  loadcheck_intervalオペランドを指定しない場合の負荷監視インタバルは，30秒です。また，負荷監視の要否のチェックなどについて10秒のインタバルで実行されます。つまり，負荷監視の要否のチェックなどの3回目には，負荷監視が実行されます。
  しかし，loadcheck_intervalオペランドを指定する場合，負荷監視インタバルはオペランドの指定値となり，負荷監視の要否のチェックなどについては，10と各ユーザサーバのloadcheck_intervalオペランドの指定値との最大公約数から求めたインタバルで実行されます。例えば，SPP1のloadcheck_intervalオペランドに3を，SPP2のloadcheck_intervalオペランドに5を指定する場合，10と3と5の最大公約数の1（秒）が負荷監視の要否のチェックなどを実行するインタバルとなります。負荷監視の要否のチェックなどの3回目には，SPP1の負荷監視が実行されます。5回目には，SPP2の負荷監視が実行されます。
  そこで，システムに与える影響を少なくするために，loadcheck_intervalオペランドに指定する値は，5の倍数にすることをお勧めします。
  loadcheck_intervalオペランドに0を指定することによって，負荷監視をサービスグループ単位で抑止できます。
  
• 負荷レベルのしきい値の指定
  ユーザサービス定義およびユーザサービスデフォルト定義のlevelup_queue_countオペランドおよびleveldown_queue_countオペランドを次に示すとおりに指定することによって，サービスグループごとにサービス要求滞留数によって負荷レベルを決定するしきい値を指定できます。
  

   
  set levelup_queue_count = U1,U2
  set leveldown_queue_count = D0,D1
   

  U1：サーバの負荷レベルがLEVEL1に上がったと判断するサービス要求滞留数
  U2：サーバの負荷レベルがLEVEL2に上がったと判断するサービス要求滞留数
  D0：サーバの負荷レベルがLEVEL0に下がったと判断するサービス要求滞留数
  D1：サーバの負荷レベルがLEVEL1に下がったと判断するサービス要求滞留数
  今回の負荷レベルは，前回の負荷レベル，およびサービス要求滞留数によって決定されます。
  負荷レベルとサービス要求滞留数について次の表に示します。
  

  表3-13　負荷レベルとサービス要求滞留数

  前回の負荷レベル	サービス要求滞留数：q	今回の負荷レベル
  LEVEL0	q ＜ U1	LEVEL0
  	U1 ≦ q ＜ U2	LEVEL1
  	U2 ≦ q	LEVEL2
  LEVEL1	q ≦ D0	LEVEL0
  	D0 ＜ q ＜ U2	LEVEL1
  	U2 ≦ q	LEVEL2
  LEVEL2	q ≦ D0	LEVEL0
  	D0 ＜ q ≦ D1	LEVEL1
  	D1 ＜ q	LEVEL2

• 通信障害時のリトライ回数の指定
  通常，サービス要求のスケジュール時に通信障害が発生すると，再スケジュールしないでエラーリターンします。
  スケジュールサービス定義のscd_retry_of_comm_errorオペランドを指定することによって，通信障害が発生したノード以外へスケジュールするリトライ回数を指定できます。
  ただし，scd_retry_of_comm_errorオペランドの指定値が，サービス要求の対象となるサービスグループが起動しているノード数を上回っている場合は，サービス要求の対象となるサービスグループが起動しているノード数をリトライ回数の上限値とします。
  0を指定した場合には，リトライしません。
  なお，この機能は，TP1/Extension 1をインストールしていることが前提です。TP1/Extension 1をインストールしていない場合の動作は保証できませんので，ご了承ください。
  

従来のスケジューラデーモン（これ以降マスタスケジューラデーモンといいます）とは別に，サービス要求受信専用デーモン（これ以降マルチスケジューラデーモンといいます）を複数プロセス起動し，サービス要求メッセージ受信処理を並行動作させることによって，受信処理の競合によるスケジューリング遅延を回避できます。この機能をマルチスケジューラ機能といいます。

マルチスケジューラ機能を使用するには，次の定義を指定する必要があります。

RPC受信側

スケジュールサービス定義　scdmulti

ユーザサービス定義　scdmulti

RPC送信側

ユーザサービス定義　multi_schedule

また，幾つかのマルチスケジューラデーモンをキュー受信型サーバごとにグループ化できます。これによって，異なるサーバ間でサービス要求メッセージの受信処理が競合するのを回避できます。マルチスケジューラデーモンをグループ化している場合，サーバ側でユーザサービス定義scdmultiを指定する必要があります。

なお，この機能は，TP1/Extension 1をインストールしていることが前提です。TP1/Extension 1をインストールしていない場合の動作は保証できませんので，ご了承ください。

マルチスケジューラ機能の概要を次の図に示します。

図3-55　マルチスケジューラ機能の概要