3.2.1 OpenTP1のリモートプロシジャコール通信
OpenTP1のライブラリ関数を使ったRPCについて説明します。
- 〈この項の構成〉
(1) サービスの要求方法
クライアントUAP(SUP,MHP,SPP)では,サービス要求に必要な項目をdc_rpc_call関数に設定してサーバUAP(SPP)にサービスを要求します。サーバUAPは,複数のサービスを実行できます。サービスとは,RPCで呼び出す処理単位であり,各サーバUAPがクライアントUAPに提供する機能です。また,一つのサーバUAPが提供するサービスの集まりをサービスグループといいます。
クライアントUAPは,dc_rpc_call関数にサービスグループ名およびサービス名を指定して,サーバUAPにサービスを要求します。ネームサービスでサーバUAPがあるノードのネットワークアドレスとサービス名を管理しているので,ネットワーク上のどのノードにサーバUAPがあるかをクライアントUAPで意識する必要はありません。
(2) リモートプロシジャコールの形態
RPCは,応答を受け取るかどうかで,応答型RPCと非応答型RPCに分類されます。RPCの種類を次の図に示します。
RPCの形態別の処理概要を次の図に示します。
(a) 同期応答型RPC
サービスを要求してから,応答が返ってくるのを待つRPCです。応答が返るまでの待ち時間を監視します。最大応答待ち時間を過ぎた場合,サービス要求はエラーリターンします。最大応答待ち時間は,システム共通定義,またはユーザサービス定義で指定します。
(b) 非同期応答型RPC
サービスを要求してから,応答が返ってくるのを待たないで,処理を続けるRPCです。応答を受信する関数(dc_rpc_poll_any_replies関数)を使って,応答を受信します。応答を受信する関数は,応答を受信するまで待ちます。この関数に設定した応答待ち時間を過ぎた場合,関数はエラーリターンします。
(3) リモートプロシジャコールの連鎖(連鎖RPC)
サーバUAPの実行プロセスは,マルチサーバ(同じサーバUAPを複数のプロセスで同時に起動する機能)の場合,サービスが要求されるたびに起動されます。一つのクライアントUAPから同じサービスグループを2回以上呼び出したとき,そのサービスグループのサーバUAPが以前と同じプロセスで実行されるとは限りません。ただし,同期応答型RPCで,かつ同じサービスグループに属するサービスを2回以上要求する場合に限り,そのサービスを以前と同じプロセスで実行させることができます。これを連鎖RPCといいます。連鎖RPCでサービスを要求すると,マルチサーバのサーバUAPでも前回のRPCと同じプロセスで実行されるため,トランザクション処理に必要なプロセスを最小限にできます。UAPのプロセスはサービスグループごとに確保されるため,同じサービスグループに属していれば,異なるサービスに対しても一つのプロセスでサービスを実行できます。
通常のRPCと連鎖RPCの比較を次の図に示します。
連鎖RPCの処理は,トランザクションとしてもトランザクションとしなくても実行できます。トランザクションとして連鎖RPCを実行する場合は,一つのグローバルトランザクションとして処理されます。
連鎖RPCは,クライアントUAPのプロセス単位で保証されます。同じグローバルトランザクション内でも,クライアントUAPが異なれば,複数回呼び出されたサービスが同じプロセスで起動されることは保証されません。
(a) 連鎖RPCの時間監視
連鎖RPCの処理中に通信障害などで次のサービス要求を受け取れない場合,SPPがプロセスを確保したままになってしまうことがあります。これを防ぐため,連鎖RPCで実行しているSPPでは,応答を返してから次のサービス要求,または連鎖RPCの終了要求が来るまでの時間(最大時間間隔)を監視しています。連鎖RPC間隔監視時間は,ユーザサービス定義のwatch_next_chain_timeオペランドに指定します。この監視時間を過ぎても次のサービス要求,または連鎖RPCの終了要求が来ない場合は,OpenTP1はクライアントUAPで障害が起こったものと見なして,該当するSPPのプロセスを異常終了させます。
(4) リモートプロシジャコールの送信データの圧縮
LANのネットワークの負荷を軽減するため,RPCでやり取りするデータを圧縮できます。データを圧縮する場合は,システム定義に次に示す値を指定します。
-
TP1/Server Baseの場合
システム共通定義のrpc_datacompオペランドにYを指定します。
-
TP1/Clientの場合
クライアント環境定義にデータの圧縮を指定します。
クライアント側のシステムがデータの圧縮を指定している場合は,rpc_datacompオペランドの指定に関係なく,サーバのOpenTP1が自動的に圧縮データを復元して処理します。その後再び圧縮してクライアントへ応答を返します。
送信データの圧縮でネットワークの負荷が軽減できても,ノード内のデータ圧縮と復元の処理が原因で通信時間が長くなってしまう場合があります。送信データの圧縮を指定するかどうかは,業務内容や通信形態に応じて判断してください。
(5) 大規模な分散システムでのサービスの要求方法
(a) ドメインネームシステムの概要
WANを介したネットワークシステムや,部門間を接続する全社システムなどの大規模な分散システムでは,名前の検索に時間が掛かり,システム名の管理に手間が掛かります。大規模な分散システムでリモートプロシジャコールを使う場合,ドメインネームシステムを構築することで,これらの問題を改善できます。
ドメインネームシステムを構築すると,システム全体を管理しないで,ドメインとして構成したグループごとに管理できます。ドメインは,小規模システムや,各部門のシステムに該当します。ドメインは,自ドメインだけを意識して管理するため,システム全体のサービスの名前などを管理する手間が省けます。
ドメインの概要を次の図に示します。
- (説明)
-
ほかのドメインにあるサービスを利用するには,dc_rpc_call関数の引数にドメイン名を付けます。
ドメインsysにあるクライアントから,ドメイン名(siteA.soft.hitachi)を付けてサービスを要求すると,ドメインhitachi,soft,siteAの順で問い合わせます。
(b) サービスの要求方法
サービスの要求方法を次に示します。
「サービスグループ名とサービス名」の指定
通常,サービスを要求するには,dc_rpc_call関数で「サービスグループ名とサービス名」を指定します。
大規模な分散システムの場合,dc_rpc_call関数での「サービスグループ名とサービス名」の指定では,ドメイン間のサービスを利用できません。
「サービスグループ名+ドメイン名とサービス名」の指定
大規模な分散システムでドメイン間のサービスを利用する場合,dc_rpc_call関数で「サービスグループ名+ドメイン名とサービス名」を指定します。
dc_rpc_call関数のサービスグループ名にこのドメイン名を付けると,ドメインの窓口のスケジュールサービスにサービス要求が渡ります。ドメインの窓口となるスケジュールサービスを,ドメイン代表スケジュールサービスと呼びます。ドメイン代表スケジュールサービスがドメインを構成するサーバのサーバUAPにスケジュールします。
このため,指定したドメインにあるサーバUAPにスケジュールされ,ほかのドメインにあるサーバUAPにスケジュールされることはありません。また,ドメイン代表スケジュールサービスだけ意識するため,ネームサービスですべてのノードのネットワークアドレスを管理する必要がありません。
なお,サーバUAPをソケット受信型サーバとした場合は,dc_rpc_call関数のサービスグループ名にドメイン名は付けられません。ソケット受信型サーバについては,「3.4.1 SPPのスケジュール」を参照してください。
サービス要求先の位置の指定
dc_rpc_call関数が位置透過であるのに対して,サービスを要求するサーバの位置をユーザが認識して,dc_rpc_call_to関数で特定のサービスを利用できます。サービス要求先の位置を指定する方法について次に示します。
-
「ホスト名称」指定
ネットワーク管理上の/etc/hostsファイル,またはDNSなどでIPアドレスとマッピングできるホスト名を指定することによって,利用するサービスが存在しているマシンを指定する方法です。
指定したホスト内のOpenTP1のシステム共通定義のname_portの指定値は,dc_rpc_call_to関数を発行したOpenTP1のシステム共通定義のname_portの指定値と同じであることが前提です。
-
「ノード識別子」指定
システム共通定義のnode_idで指定したノード識別子を指定することによって,OpenTP1システムを指定する方法です。
指定したノード識別子に対応するサービス要求先のOpenTP1ノードのホスト名がグローバルドメイン内にあることが前提です。
ここでのグローバルドメインとは,次のノード名の集合を指します。
-
システム共通定義のname_domain_file_useオペランドにNを指定している場合
システム共通定義のall_nodeオペランド,all_node_exオペランドで指定したノード名の集合です。
-
システム共通定義のname_domain_file_useオペランドにYを指定している場合
ドメイン定義ファイルに指定したノード名の集合です。なお,ドメイン定義ファイルの格納場所は,次のとおりです。
all_nodeのドメイン定義ファイル
$DCCONFPATH/dcnamndディレクトリ下
all_node_exのドメイン定義ファイル
$DCCONFPATH/dcnamndexディレクトリ下
-
-
「ホスト名称+ポート番号」指定
次の値を指定することでサービス要求先を特定します。
-
/etc/hostsにファイル,またはDNSなどでIPアドレスとマッピングできるホスト名
-
上記で指定したホストに存在するOpenTP1システムの,システム共通定義のname_portに指定したネームサービスのポート番号
このとき,サービス要求先のname_portオペランドに指定した値と,サービス要求元のname_portオペランドに指定した値は同じでなくてもかまいません。
-
なお,この機能は,TP1/Extension 1をインストールしていることが前提です。TP1/Extension 1をインストールしていない場合の動作は保証できませんので,ご了承ください。
(c) 大規模な分散システムでの環境設定
ドメインを構成するノードは,システム共通定義のall_nodeオペランドに指定したノードです。
ドメイン代表スケジュールサービスは,ドメイン代表スケジュールサービスがあるホスト名をnamdomainsetupコマンドで登録します。そして,「/etc/services」に,ドメイン代表スケジュールサービスのポート番号と,サービス名「OpenTP1scd」を指定します。
ドメインネームシステムを使う場合,サーバシステムの起動時に各ノードのアドレスを問い合わせるため,システムの起動完了までに時間が掛かる場合があります。このような場合には,あらかじめシステム共通定義のdomain_masters_addrオペランドにドメイン名とホスト名を,domain_masters_portオペランドにドメイン代表スケジュールサービスのポート番号を指定しておきます。この指定をしておくと,サーバ起動時に各ノードのアドレスを問い合わせる時間を削減できます。
(6) ネームサービスを使わないサービスの要求方法
通常のRPCでは,各ノードのネームサービスが管理している,サーバUAPのサービス情報を使って通信しています。各ノードのネームサービスは,目的のサーバUAPがネットワーク上のどのノードにあるかを,サービス情報を交換することで管理しています。多数のノードを接続した大規模システムでは,ネームサービスによるサービス情報のやり取りが,ネットワークに負荷をかける場合があります。
定義ファイルにサービス情報を定義しておくことで,ネームサービスを使わずにRPCができます。ネームサービスへサービス情報を問い合わせないため,ネットワークに掛かる負荷を軽減できます。
ユーザはユーザサービスネットワーク定義ファイルにサーバUAPのサービスグループ名とサービス情報(ホスト名とポート番号)を定義します。また,dc_rpc_call関数発行時にネームサービスを使うか,定義ファイルのサービス情報を使うかを,ユーザサービス定義のrpc_destination_modeオペランドで指定します。ユーザサービス定義で定義ファイルのサービス情報を使うと指定されたUAPからdc_rpc_call関数が呼び出されると,OpenTP1はユーザサービスネットワーク定義ファイルを参照します。サーバUAPの情報が定義されていれば定義情報を基に,定義されていなければネームサービスを使ってサーバUAPを呼び出します。なお,ユーザサービスネットワーク定義に指定するサーバUAPは,ユーザサービス定義でreceive_from=queueが指定されたUAP(キュー受信型サーバ)でなければいけません。
ユーザサービスネットワーク定義ファイルのサービス情報(ホスト名)を複数指定した場合,指定したサービス情報からランダムにサービス要求先が選択され,サービス要求が送信されます。サービス要求が成功すると,UAP内で以降に呼び出す同じサービスグループ名へのdc_rpc_callは,障害が発生するまで同じホストにサービス要求の送信を継続します。
なお,dcsvgdef定義コマンドの-tオプションであて先再選択間隔に値を指定し,次に示す時間があて先再選択間隔に指定した時間を超えていた場合,再度ランダムにサービス要求先を選択しサービス要求を送信します。
-
UAP内で同じサービスグループ名へのdc_rpc_callを呼び出し時に,サービス要求の送信を継続しているホストとの,初回から今回のサービス要求までの経過時間