米国特許情報 | 欧州特許情報 | 国際公開(PCT)情報 | Google の米国特許検索
 
     特許分類
A 農業
B 衣類
C 家具
D 医学
E スポ−ツ;娯楽
F 加工処理操作
G 机上付属具
H 装飾
I 車両
J 包装;運搬
L 化学;冶金
M 繊維;紙;印刷
N 固定構造物
O 機械工学
P 武器
Q 照明
R 測定; 光学
S 写真;映画
T 計算機;電気通信
U 核技術
V 電気素子
W 発電
X 楽器;音響


  ホーム -> 計算機;電気通信 -> 株式会社エヌイーシー情報システムズ

発明の名称 分散型プロセス処理方法およびその装置
発行国 日本国特許庁(JP)
公報種別 公開特許公報(A)
公開番号 特開平9−16534
公開日 平成9年(1997)1月17日
出願番号 特願平7−164837
出願日 平成7年(1995)6月30日
代理人 【弁理士】
【氏名又は名称】京本 直樹 (外2名)
発明者 望月 祐志 / 平原 幸男 / 佐野 亨 / 半田 享 / 山本 章紀 / 萬 伸一
要約 目的
ネットワークで結合された均一あるいは不均一に分散構成された計算機環境において、ユーザーの投入ジョブをサーバに効率よく分散実行処理させる。

構成
ユーザーの投入ジョブに係るアプリケーションプログラムのプロセス流れに対して、クライアントとサーバプロセス間に介在するエージェントプロセスを生成する。エージェントは、計算機に関する静的性能と動的な負荷状況の変動などハードウェア資源に関する情報と、計算機環境内のプログラムモジュールと随伴するデータなどソフトウェア資源に関する情報とに基づいて、クライアントプロセスより依頼された目的ジョブをサーバプロセスに分配し実行処理させる。
特許請求の範囲
【請求項1】ネットワークで結合された均一もしくは不均一に分散構成された計算機環境におけるプロセス処理方法において、ユーザーの投入ジョブに係るアプリケーションプログラムのプロセス流れに対して、個々の前記計算機に関する静的な性能と動的な負荷状況の変動などハードウェア資源に関する情報と、前記計算機環境内のプログラムモジュールと随伴するデータなどソフトウェア資源に関する情報とを把握する単数あるいは複数のエージェントプロセスを生成し、生成された前記エージェントプロセスがクライアントプロセスとサーバプロセス間に介在し、前記ハードウェア資源に関する情報と前記ソフトウェア資源に関する情報に基づいて、前記クライアントプロセスより指令された前記目的ジョブを前記サーバプロセスに実行処理させることを特徴とする分散型プロセス処理方法。
【請求項2】ネットワークで結合された均一もしくは不均一に分散構成された計算機環境において使用され、クライアントとサーバとエージェント管理システムより構成される分散型プロセス処理装置であって、前記エージェント管理システムは、前記クライアントよりユーザーの投入ジョブに係るタスクを受け付ける受付部と、個々の前記計算機に関する静的な性能と動的な負荷状況の変動などハードウェア資源に関する情報と、前記計算機環境内のプログラムモジュールと随伴するデータなどソフトウェア資源に関する情報を保持する資源情報管理部と、前記受付部からの命令に基づいてエージェントプロセスを生成、消去するエージェントプロセス操作部とから構成され、前記エージェントプロセス操作部により生成されたエージェントプロセスは、前記クライアントと前記サーバ間に介在し、前記資源情報管理部より得た前記ハードウェア資源に関する情報と前記ソフトウェア資源に関する情報とに基づいて前記目的ジョブを前記サーバに実行処理させることを特徴とする分散型プロセス処理装置。
発明の詳細な説明
【0001】
【産業上の利用分野】本発明は、ネットワークで結合された分散型の計算機環境において、ユーザーにより投入されるアプリケーションプログラムのジョブを、環境内のハードウェア資源、およびソフトウェア資源を有効かつ効率よく利用して実行する、分散型プロセス処理方法およびその装置に関するものである。
【0002】
【従来の技術】高速大容量ネットワーク、縮小命令セットCPU(RISC)などの技術の急速な進歩により、WS(ワークステーション)など安価な計算機資源をクラスター状に結合して分散型処理環境を構築し、アプリケーションソフトウェアを、メッセージ通信を通じてクライアント/サーバ方式で実行する形態を取ることにより、価格性能比に優れたジョブ処理が可能になってきている。こうした分散化の流れは、高性能専用機であるスーパーコンピュータの分野にも広まり、単一ベクトルCPU型よりも、ベクトルCPUを並列にして処理の分散を図った高並列機や、RISCを数千に及ぶ規模にまで並列分散した超並列機の方が主流になりつつあるが、分散制御の基本はWSクラスターと同様にメッセージ通信に基づくものが多い。
【0003】メッセージ通信の特徴の1つは、均一構成の場合はもちろん、マルチベンダによるWS群をクラスターにする等の不均一構成の場合でも、個々のWS上のOSの違いに拠らずに対応出来るポータビリティの良さである。最近では、メッセージ通信により、距離的に離れたWSクラスター同士を結合したり、WSクラスターとスーパーコンピュータを結合して高次の分散環境を構築する試みも成されつつある。
【0004】メッセージ通信の手段としては、特に科学技術計算の分野では米オークリッジ国立研のPVMが使われることが多い。メッセージ通信をアプリケーションソフトウェアに実装するには、元のプログラム構造をクライアント側とサーバ側に適にモジュール分割し、その間で変数、もしくは配列領域をやり取りするように、通信専用の外部ライブラリルーチンのコール文を挿入する。サーバプロセスを複数生成すれば、分散並列処理となる。この際、クライアント側とサーバ側で通信と処理流れの手順をつじつまを合わせてコーディングしておく必要がある。逆に言えば、メッセージ通信の変数、配列並びが統一され、かつ機能が同一であれば、由来の異なるモジュールを結合することも可能であり、共有ライブラリ化されている、行列対角化などの数値処理用モジュールなどを自アプリケーションの中で引用利用することもある。
【0005】アプリケーションのあるプロセスからメッセージ通信のためのルーチンコールがあると、個々の機種に固有のOSとは別に存在するデーモンと呼ばれるハンドラーに制御が移り、ここから実際の通信パケットの送出と受理が行われる。アプリケーション側から見ると、OSはデーモンから要求されたパケットを下位レベルで処理するのみで、あらわには見えず、これが上述の良好なポータビリティにつながっているのだが、黒子であるデーモンも、実は、単にアプリケーションにおけるクライアントプロセスとサーバプロセスの間でのメッセージ通信を仲介しているだけにすぎない。
【0006】従って、分散型環境として与えられた計算機資源を有効利用出来るような高度なプロセス流れの組立ては、煩雑ではあるがアプリケーション側で全て責任を持ってコーディングし、実現をしなければならない。
【0007】
【発明が解決しようとする課題】まず、分散型環境に含まれるハードウェア資源に関連する問題点を挙げる。
【0008】既に述べたように、従来のメッセージ通信制御では、アプリケーション側からは機種の違いは見えない。しかし、例えば、あるジョブの実行のために、環境内の全てのWSを並列化サーバプロセスのみに独占的に従事させる場合でも、各WSのCPUの速度性能差にばらつきが在れば、クライアントプロセスが単純にサーバプロセスのタスクリストを均等割りして発行すると、最も低速なWSに律速されてしまうために高い処理効率は得られない。
【0009】これを避けるには、アプリケーションジョブの実行前に、WSの性能差をパラメータとしてクライアントプロセスに与え、それに応じてタスクの割り当て方を変える対策が考えられるが、実際の運用環境では上で仮定した独占的従事の条件下ではなく、複数のジョブが同時に投入されている非独占的な条件で、各WSの負荷状況は動的に変化しているため、事前の静的な割り当てでは効果的な改善は望めない。この問題は、環境内のWSの数が増えるほど深刻化する。さらに、あるWSが障害発生により実行中に使用不能となった場合、それが認識され、さらに障害WSが担当していたサーバプロセスがきちんと代替されて処理全体の整合性が保たれなければならないが、通常のメッセージ通信制御ではデーモンにその機能が無いために、クライアントプロセスまでも継続処理不能状態に陥ってしまい、目的のアプリケーションジョブそのものを異常終了させざるを得なくなる。あるいは、逆に、実行中に障害から復旧したWSが環境内にあっても、それをサーバ用に動的に有効利用することは出来ない。
【0010】つまり、従来技術ではメッセージ通信をハンドルするデーモンは、分散環境内のハードウェア資源の動的な変化に反応して、アプリケーションジョブの実行が確実かつ最適に行われることを保証する手段を持っていない。むろん、OSは個々のWSに存在しているが、ネットワークを通じて統合的にジョブ実行を動的管理する機能は有しておらず全く無力である。
【0011】一方、アプリケーション側でハードウェア環境の動的変化にきちんと対応するためには、システムコールなどを用いて自らが環境情報を取得し、それに基づいて複雑な最適制御を行うようにプログラム開発者がコーディングしておかなくてはならないが、煩雑となる他、分散環境の機種内訳が変わる度に修正が必要となり、保守性が悪化してしまう。別の方策としては、通常行われるようにアプリケーションプログラムをクライアントモジュール部とサーバモジュール部に分けるだけではなく、これらから制御のみに専念する部分を全く別に分離し、制御プロセスにクライアントプロセス、サーバプロセスの両方を管理させることも考えられる。しかし、この方法を実現するには元のクライアント/サーバ式のアプリケーションプログラムの大幅な修正が必要であり、しかも、それでもなお、管理部の構造は個々のアプリケーションに依存して異なるので汎用性、一般性はなく、抜本的な解決とはなり得ない。
【0012】ハードウェア資源の動的な有効利用の困難さは、WSクラスターに限ったことではなく、メッセージ通信制御による並列分散型のスーパーコンピュータにおいてはより先鋭に表れる。例を挙げれば、CPUの数が64で、これを4つのジョブで公平に利用しようとする場合、各ジョブが共に64CPUを共有して使うのではなく、16CPUずつにあらかじめ分割し、互いにCPU使用が重ならないように運用されることが多い。最初の3つのジョブが終了しても、まだ実行中の4つ目のジョブは、最後まで最初の16CPUのまま走ることになる。次に投入されるべき5つ目のジョブが、64CPUを全て使うことを要求していれば、4つ目が終るまで実際の投入は待たなければらない。これを、アプリケーション側から改善しようとしても、既述のようにコーディングが煩雑であることは疑いなく、またWSクラスターへ移植する際には、改めて修正する必要があることも言うまでもない。
【0013】また、これまで述べてきたハードウェア資源に関する従来技術の問題点が、WSクラスター同士を互いに接続したり、あるいはWSクラスターと並列スーパーコンピュータを接続して構成されるより高次の分散環境では、より一層顕在化するのは明らかである。
【0014】次に、ソフトウェア資源の有効利用の観点から従来技術の問題点を挙げる。まず最初に、計算機の特性に応じた最適なプログラムモジュールの選択利用に関してである。例えば、前述のように、スカラー実行のWSクラスターとベクトルCPUを1つ持つスーパーコンピュータを接続した分散処理環境での、変分法の求解を要求するユーザージョブの実行において、アプリケーションプログラムが、変分に関わる行列要素の構築を並列サーバプロセスとして行うことを考える。
【0015】一般的に、同一の数値処理を行うにも、スカラー実行とベクトル実行では最適なアルゴリズムは異なり、必然的にモジュールのコードも異なる。従って、サーバプロセスでの行列要素の構築は、WSではスカラー用のモジュールで、スーパーコンピュータではベクトル用のモジュールで行われるべきである。しかし、現状では、いずれかの一つのモジュールが妥協的に使われることが多い。きちんと計算機の特性を活かすには、アプリケーションプログラムの開発者、もしくは維持管理者が、運用計算機の構成を把握し、それに応じたモジュールの指定、前述の速度差に応じた静的負荷分散の指示、および必要なメッセージ通信などを明示的にコーディングすることになるが、移植性と保守性の悪さは明白である。さらに、動的な環境変化に対応する制御手段までも実装しようとすれば、その困難はいよいよ深刻である。
【0016】続いて、バージョンの更新に関連して問題点を指摘する。例として、格子点データを与えることにより数値積分を実行するモジュールが、分散計算機環境内に共有ライブラリの一つとして置かれ、様々なアプリケーションプログラムにおいてメッセージ通信を通じて、サーバとして引用されている状況を考え、必要な数値データに合わせて、当該積分モジュール内において読み参照される数値補間用テーブルのファイル名を渡す必要があるとする。
【0017】さて、このライブラリモジュールのバージョンが更新され、補間テーブルのファイルも合わせて更新されると、モジュール/テーブル間の整合性に留意しつつ、各アプリケーションに対して対応する変更を個別に行う必要があり、保守上、煩雑なこの変更作業をバージョン更新の度に繰り返さなければならない。アプリケーションの開発者、維持管理者が複数である場合、ライブラリの管理者がバージョンの更新を各人に通知し、各々が変更を行うことになるが、周知徹底される保証はない。
【0018】上記の2例で見たように、ソフトウェア資源の有効利用という面でも従来技術には問題がある。また、先に述べたように、ハードウェア資源の有効利用に関連しても問題があり、これら両者を共に解決する手段が必要である。
【0019】
【課題を解決するための手段】上記課題を解決するため、本発明は、ネットワークで結合された均一もしくは不均一に分散構成された計算機環境におけるプロセス処理方法において、ユーザーの投入ジョブに係るアプリケーションプログラムのプロセス流れに対して、個々の計算機に関する静的な性能と動的な負荷状況の変動などハードウェア資源に関する情報と、計算機環境内のプログラムモジュールと随伴するデータなどソフトウェア資源に関する情報とを把握する単数あるいは複数のエージェントプロセスを生成し、生成された前記エージェントプロセスがクライアントプロセスとサーバプロセス間に介在し、ハードウェア資源に関する情報とソフトウェア資源に関する情報に基づいて、クライアントプロセスより指令された目的ジョブをサーバプロセスに実行処理させることを特徴とする分散型プロセス処理方法である。
【0020】また、本発明の第2の発明は、ネットワークで結合された均一もしくは不均一に分散構成された計算機環境において使用され、クライアントとサーバとエージェント管理システムより構成される分散型プロセス処理装置であって、エージェント管理システムは、クライアントよりユーザーの投入ジョブに係るタスクを受け付ける受付部と、個々の計算機に関する静的な性能と動的な負荷状況の変動などハードウェア資源に関する情報と、計算機環境内のプログラムモジュールと随伴するデータなどソフトウェア資源に関する情報を保持する資源情報管理部と、前記受付部からの命令に基づいてエージェントプロセスを生成、消去するエージェントプロセス操作部とから構成され、エージェントプロセス操作部により生成されたエージェントプロセスは、クライアントとサーバ間に介在し、資源情報管理部より得たハードウェア資源に関する情報とソフトウェア資源に関する情報とに基づいて前記目的ジョブをサーバに実行処理させることを特徴とする分散型プロセス処理装置である。
【0021】目的ジョブの終了後は、エージェントプロセスはエージェント管理システムにより消去される。
【0022】クライアントプロセスとサーバプロセス間に介在するためにプロセスとして生成、消去されるエージェントモジュールは、ライブラリ化されてエージェント管理システム内部に置かれている。
【0023】
【実施例】以下に、本発明の一実施例を図面を参照して説明する。
【0024】本発明によれば、アプリケーションプログラムにおける、クライアントプロセスとサーバプロセス間でのメッセージ通信は、従来技術のように直接やり取りされるのではなく、図1に示すように、エージェントプロセスの中間介在によって間接的にやり取りされる。アプリケーションの開発者、維持管理者が、エージェントを利用するコード変更の要点は、クライアント部とサーバ部の各々のメッセージ通信の直接参照コールを、エージェントを解した間接参照コールにすることである。これらエージェント関係ルーチンのコール形式は、むろん汎用性、一般性を持ち、各アプリケーションがライブラリとして共通利用出来る。いずれにせよ、明記すべきは、エージェントプロセスは、まさしく、クライアントプロセスとサーバプロセスの間に入る代理人として振舞うのであって、そのアプリケーションのプロセス全体を上位から管理する形式にはなっていないということである。
【0025】図2に、本発明による計算機におけるエージェント管理システムの階層の概念図を示す。図2より、エージェントの管理システムはOSから見ればアプリケーションプログラムの1つに過ぎない。従って、不均一構成の分散環境への実装にあたっても機種の違いを強く意識することはない。
【0026】エージェントプロセスを生成、消去等の管理を行い、さらに資源情報を把握するエージェント管理システムは、分散環境内の計算機に対して個別に置かれるか、適当にまとめられた計算機グループ毎に置かれる。図3に、エージェント管理システムの構成図を模式的に示す。
【0027】エージェント管理システムは、6つの構成要素3.1〜3.6より成る。外側のメッセージ通信制御部3.1は、クライアントプロセス、サーバプロセス間の通信の他、当該管理システムの存在する計算機のOS、および他の計算機上のエージェント管理システムとの通信をハンドリングする。
【0028】エージェント管理システムの内部は5つの要素、クライアントからのエージェント使用の宣言やタスク依頼を受付ける部分(受付部)3.2、依頼されたタスクをプールしておく部分(タスクプール部)3.3、ライブラリ部分3.4の中のエージェントプログラムを起動して、プロセスとして生成・活性化する、あるいは消去・不活性化するなどエージェントプロセスに対する操作を行う部分(エージェント操作部)3.5、および資源情報の取得・保持を行っている部分(資源情報部)3.6から構成される。
【0029】エージェント管理システムは、C言語等のプログラム言語で記述されている。エージェントライブラリ3.4はプロセスとして活性化されている部分と、不活性の部分とを合わせ持つが、活性化された部分がジョブ実行を仲介するエージェントプロセスとして機能する。エージェント管理システムのそれ以外の部分、3.1〜3.3および3.5〜3.6は常にプロセスとして活性な状態にある。
【0030】エージェントプロセス操作部3.5によるライブラリ3.4でのエージェントプロセスの生成・消去のプロセス操作は、該当する標準的な関数の呼出しによってなされる。
【0031】資源情報の取得・保持部3.6で取得・保持されるハードウェア資源情報のテーブルについては、図4に示すように、個々の計算機のCPU速度、あるいはCPUがスカラー型なのかベクトル型なのか、といった静的な項目と、ロードアベレージに代表されるようなCPU負荷の変動、利用可能メモリー空間や作業ファイル量、そして障害の状況などの動的な項目に分けることが出来る。静的な情報は、各計算機毎にファイル上にあらかじめ書いて設定しておけば、資源情報の取得・保持部3.6によって読み込まれる。動的な環境情報は、資源情報の取得・保持部3.6からの各OSに対するシステムコールにより、適当な時間間隔を持って随時取得される。
【0032】ソフトウェア資源の情報は、図5に示すように、プログラムとデータの機能と所在、相互参照のリンク、および参照の履歴などに関する項目があり、静的なハードウェア資源の情報と同様に、ファイル上に設定され、そこから読み込まれる。ここで、プログラム情報については、例えば、コンパイル時に取得することが出来る。ライブラリを更新、ないしは新規に追加する場合は、このソフトウェア情報のテーブルファイルのみを、その旨に合わせて変更すればよく、個別のアプリケーション側の変更は必要ではない。また、参照履歴については、エージェントの使用によって逐次更新される。
【0033】図4のハードウェア資源情報のテーブルと、図5のソフトウェア資源の情報テーブルの中身は、CPU速度のように各計算機毎の線形のエントリを持つもの、ネットワーク状況のように計算機間の行列型のエントリを持つもの、プログラムとデータの参照関係のように不定型のエントリを持つものなど、複雑な内部構造を有している。
【0034】ここで、並列化されていないジョブを単一実行する場合を例に取り、エージェントを使うジョブ実行のプロセス流れを、エージェント管理システム内部の動作も含め、図6を用いて詳細に説明する。ここでは、メッセージ通信のハンドリング部は省略する。
【0035】最初に、クライアントプロセス6.1がエージェント管理システム内の受付け部6.2にエージェント使用の宣言6.10を行うと、受付部6.2からの要求6.11に応じてエージェントプロセス操作部6.3によりエージェント生成メッセージ6.12が発せられ、エージェントライブラリを元に、当該クライアントプロセスを認識するエージェントプロセス6.4が生成される。
【0036】次に、クライアントプロセス6.1はタスクを、数値データの他に、処理の手続きやサーバに関する情報などを文字列のスクリプトとして記述し、タスク6.13をエージェント側受付部6.2に依頼する。依頼されたタスクは、エージェント側受付部6.2からの依頼タスクのセット要求6.14によりタスクプール部6.5にセットされる。
【0037】次に、エージェントプロセス6.4は、タスクプール部6.5から、依頼タスクの取得要求6.15、取得要求6.15の返答6.16によりタスクを読み出し、その内訳に基づいて、ハードウェア・ソフトウェア資源情報の管理部6.6から必要な情報を資源情報の取得要求6.17と、その返答6.18により得る。そして、エージェントプロセス6.4は、それらの資源を最適に利用出来るようにサーバを選択し、サーバプロセスの起動・生成要求6.19を発し、それによりサーバプロセス6.7を起動・生成させる。続いてエージェントプロセス6.4は、タスクの数値データをサーバプロセス6.7に送り(6.20)、サーバプロセス6.7に実際の処理を行わせ、実行結果をエージェントプロセス6.4に戻させる(6.21)。
【0038】エージェントプロセス6.4は、実行結果が正常であれば、タスクプール部6.5に依頼タスクが正常終了したことを記し(6.22)、サーバプロセス消去要求(メッセージ)6.23を発することによりサーバプロセス6.7を消去する。
【0039】続いて、エージェントプロセス6.4は依頼タスクの実行が正常に終了された結果をクライアントプロセス6.1に返送する(6.24)。
【0040】クライアントプロセス6.1はエージェントプロセス6.4からの結果を受け取り、最後に受付部6.2にエージェント使用の停止を宣言する(6.25)と、受付部6.2からのサーバプロセスの消去要求6.26に基づき、エージェントプロセス操作部6.3がエージェントプロセス消去要求メッセージ6.27を発しエージェントプロセス6.4は消去される。また、受付部6.2からの実行済タスクの消去要求メッセージ6.28によりタスクプール部6.5から依頼タスクの内容も消去される。なお、どのサーバが選択されたかを履歴として保持したい場合は、サーバプロセスの正常終了が確立した時点で、エージェントプロセス6.4が資源情報部6.6へ書き込みの要求を出せばよい。
【0041】並列実行、すなわち、サーバプロセスが複数となる場合は、それに応じてエージェントプロセスも複数生成されると共に、それらの調停を担う上位エージェントが1つ生成され、動的な負荷分散が行われながら処理が行われる。上位エージェントも、図3のエージェントプロセスとして活性化され得る部分を持つライブラリ部3.4に含まれる。
【0042】並列実行に係るプロセスを、計算機数を2として図7に例示的に示す。計算機1の上にあるクライアントプロセス7.1は、同じく計算機1上のエージェント管理システム7.2に並列実行の旨を宣言すると、この宣言が計算機2の管理システム7.3にも伝えられ、計算機1の上にエージェントプロセス7.4が、計算機2の上にエージェントプロセス7.5が生成され、合わせて上位エージェント7.6が計算機1の上に生成される。次に、クライアントプロセス7.1から計算機1のエージェント管理システム7.2へ使用するサーバモジュールがスクリプトにより指定されると、エージェントプロセス7.4がサーバプロセス7.7を、計算機2のエージェントプロセス7.5がサーバプロセス7.8を生成する。そこで、クライアントプロセス7.1が並列タスクの制御のリストをエージェント管理システム7.2に渡すと実行が開始される。このリストはエージェント管理システム7.2内のタスクプール部に置かれるが、アクセスはエージェントプロセス7.4と7.5の上位エージェントプロセスである7.6のみが許される。上位エージェントプロセス7.6は、制御リストの全体の長さを適当な周期幅を持って繰り返しブロックに分割する。このブロックが、さらに計算機の負荷状況に応じて分けられるが、これはエージェントプロセスの7.4と7.5が上位エージェントプロセス7.6に要求を出すことで行われる。要求を出された上位エージェントプロセス7.6は、エージェント管理システム7.2内のハードウェア資源のテーブルから、計算機1の負荷状況を、計算機2のエージェント管理システム7.3から同様に計算機2の負荷状況を得て、それらに応じてブロックを分割して、エージェントプロセス7.4と7.5に割当てる。計算機1のエージェントプロセス7.4はサーバプロセス7.7に、計算機2のエージェントプロセス7.5はサーバプロセス7.8に割当てられたタスクを送って実際に処理を行わせる。これら一連の割当て/処理を、並列タスク制御リストが尽きるまで繰り返す。
【0043】並列サーバプロセス間で必要な通信もエージェントプロセスが介在する。すなわち、メッセージは計算機1上のサーバプロセス7.7→計算機1上のエージェントプロセス7.4→計算機2上のエージェントプロセス7.5→計算機2上のサーバプロセス7.8へ、またその逆方向へと、エージェントプロセスを介して伝えられる。並列処理が正常に終了すれば、計算機1上のサーバプロセス7.7はエージェントプロセス7.4に、計算機2上のサーバプロセス7.8はエージェントプロセス7.5によって消去され、さらに続けてクライアントプロセス7.1からの停止宣言により計算機1上のエージェント管理システム7.2はエージェントプロセス7.4を、計算機2上のエージェント管理システム7.3はエージェントプロセス7.5を消去する。
【0044】(実施例1)次に本発明を用いた場合の具体的動作例について、まず、エージェントの導入に伴うアプリケーションプログラムの変更を例として説明する。例題として、(1)式に示される連立1次方程式の求解ジョブを取る。この例は、また、計算機の特徴の違いに応じたソフトウェアの選択に関するエージェントの機能についての述解も兼ねる。
【0045】
【数1】

【0046】図8、図9は、連立一次方程式の求解における従来技術によるプロセス流れを記した擬コードである。図8はクライアントでのプロセス流れを、図9はサーバでのプロセス流れを示している。クライアントプロセスでは、入力データである左辺の行列要素{Aij}と右辺のベクトル要素{bi }を最初にセットする。解ベクトル要素{xi }は、これらセットされた要素データをメッセージ通信で送ってサーバプロセスで求められる。このサーバプロセスは、WSのようなスカラー型、あるいはスーパーコンピュータのようなベクトル型かによって異なるモジュール、LS とLV で実行される。速度は、もちろんベクトル版LV の方が高速であり、与えられた分散型計算機環境でベクトルCPUの計算機が利用出来るなら、こちらが使われるべきである。
【0047】この要請を実現するために、煩雑とはなるが、図8よりわかるように、サーバへの求解メッセージ送信の前にクライアント自らが分散型環境の情報を取得し、利用可能な計算機に応じて、タスク依頼のための送信、および結果の受信のための識別子を設定するようにコードされている。
【0048】さて、クライアントからサーバへ{Aij}、{bi }のメッセージが送信されると、図9に示すようにLS 、LV いずれかのサーバプロセスが、クライアント送信時の識別子に応じてそれを受信し、式(1)の求解処理を行い、あらかじめクライアントから与えられた識別子を付けて、解データ{xi }をメッセージとして返送する。そして、クライアントは、サーバからその求解結果を受信する。以上が従来技術によるプロセス流れである。
【0049】一方、図10、図11、図12は本発明によるエージェントを用いる場合のプロセス流れである。図10はクライアントでのプロセス流れを、図11はエージェントでのプロセス流れを、図12はサーバでのプロセス流れを示している。図10において、{Aij}と{bi }の要素を最初にセットするところは従来の図8と同じである。しかし、その下で、本発明によれば環境情報と識別子に関する部分が元のクライアントコードからは省かれていること、メッセージ送受信のコールが全く異なっていることに注意されたい。さて、クライアントプロセスがエージェント管理システムにエージェントプロセスの使用を宣言すると、当該クライアントを認識するエージェントプロセスが生成される。続いて、クライアントは、エージェントプロセス側に、入力要素{Aij}、{bi }の配列領域、さらに合わせて、連立1次方程式の求解である旨の宣言、求解用モジュールLS とLV の情報、およびモジュール選択の基準をメッセージとして送信する。これで、エージェントプロセスに実行の流れが移る。要素データ以外の項は、クライアントがエージェントに対して、依頼するタスクの特徴、およびその処理方針をスクリプトとして与えることに対応している。
【0050】エージェントは、図11に示すように、図5の環境情報の中の利用可能計算機のリスト、および与えられた選択基準を元に、LS 、LV のいずれかのサーバモジュールを選び、識別子を適に設定し、実際の求解のために、入力要素{Aij}、{bi }のメッセージをサーバに送る。この例の場合、モジュール選択の基準は実行速度であるので、ベクトル機が使えれば、与えられた候補2つの中からLV が選ばれる。この候補挙げに係る論理流れを図13に示す。
【0051】サーバは、図12に示すようにエージェントからの入力要素の受信後、式(1)を解き、その後、解要素{xi }のメッセージをエージェントに返送する。そして、エージェントは解を受取り、今度はクライアントにそれを送る。
【0052】以上で、エージェントプロセスの主たる役目は終わりで、制御は再びクライアント側に戻り、最後に管理システムに役目終了を通知することで、エージェントプロセスは消去される。この例で分かるように、エージェントの介在により、クライアントとサーバの間に直接の参照関係は無くなる。識別子によるサーバへのメッセージルーティングはエージェントによって成される。
【0053】上の段落で行ったエージェント導入のメリットを明確に示すために、元々のアプリケーション開発者が作成したベクトル実行用のサーバモジュールLV より高速な、第3者が開発したベクトル実行用のライブラリモジュールLT を使用する例を挙げる。
【0054】LT を利用するためには、従来技術では、当該アプリケーションの開発者、維持管理者がコードに修正を加える必要があるが、本発明のようにエージェント管理システムを用いていればその必要はない。代わりに、分散環境の維持管理者が、元のLT のメッセージ通信周りのみをエージェント管理用に適に修正し、LTの特性に関する情報を図5のソフトウェア資源のテーブルに加えておけばよい。それにより、図11、図13でのサーバモジュールの候補にLT が自動的に含まれるので、当該アプリケーション実行時に、ベクトルCPU機が使えるならば、きちんと最速のLT が参照される。この際、図5のテーブル中のLT についての参照履歴が更新される。他のモジュール、例えば、超並列機用のモジュールLPなどをライブラリに新たに加えることを考えれば自明だが、この例はエージェント管理の導入によってもたらされる保守性の良さを示している。なお、自開発のサーバモジュールLS ,LV の使用に固執する場合は、その旨を強制条件として、クライアントがエージェントに渡すべきスクリプトに明記しておくことになる。逆に、連立1次方程式の求解の旨だけを記し、モジュールの指定を一切しないで済ますことも出来る。
【0055】サーバモジュールがファイルを扱う場合でも、本発明のエージェント管理システムを用いれば同様のメリットが得られる。前出の数値積分のライブラリモジュールの例を再び取り上げる。積分を行うこのモジュールLX を使うには、クライアント側から、当該モジュール内で読み参照される補間テーブルファイルのファイル名を、使用時に格子点のデータと共に与えるのだが、それはバージョン毎に異なるために、従来技術ではバージョンアップに対する保守は煩雑である。一方、本発明のエージェントに依る場合には、クライアント側は格子点の数値データとスクリプトを渡すだけでよい。図5のソフトウェア資源の情報テーブルには、プログラムと随伴するデータに関する相互参照のリンクが在るので、エージェントプロセスは、バージョンに応じたファイル名をサーバモジュールLX に通知し、正しく処理が行われる。
【0056】(実施例2)次に、ネットワークで結合されたWSクラスターから成る分散型計算機環境において、(2)式に示す超行列の積和演算を並列サーバプロセスで処理するジョブ例を取りあげ、負荷分散について、本発明のエージェントがいかに機能するかを述べる。
【0057】
【数2】

【0058】上式に係るタスク制御リストとしては2添字の組{i,j}よりも4添字の組{p,q,r,s}の方がはるかに長く、また、{Cpqrs}と{Dpqrs}は一時的な作業データ要素であって、後で参照されないので、4添字の組{p,q,r,s}をタスクの制御パラメータとして並列サーバプロセスが駆動される。サーバプロセス間での通信は、この例では発生しない。{Bij}要素は、各サーバプロセスにおいては不完全生成されることになるので、最終的に正しい値を得るには、(3)式に示すように、並列プロセスの終了後、サーバ数について和を取る必要がある。なお、WSの総台数はM個、並列サーバプロセスとエージェントプロセスの数もM個、サーバモジュール名はLQ とする。
【0059】
【数3】

【0060】図14、図15、図16、図17は、本発明によるエージェントを用いた超行列積和の並列実行の流れを擬コードで示している。図14はクライアントでのプロセス流れを、図15は下位エージェントでのプロセス流れを、図16は上位エージェントでのプロセス流れを、図17はサーバでのプロセス流れを示している。
【0061】クライアントはまず、エージェント管理システムに並列処理の使用を宣言する。これにより、M個のサーバプロセスに応じてM個のエージェントプロセスが生成され、これらM個のエージェントプロセスに対して1つの上位エージェントもクライアントプロセスのあるWS上に生成される。
【0062】次に、サーバプロセスで共通の立ち上げ用の初期数値データと、LQ を記述したスクリプトをエージェント側に渡す。すると、管理すべきサーバプロセスがモジュールLQ に係ることが決まり、初期データが正しく送られる。そして、LQサーバプロセスは、この受信を持って{Bij}の配列領域をゼロ化し、積和処理の実行に備える。そこで、4添字の組{p,q,r,s}に関する並列タスクの制御リストをエージェント管理システムに渡すと、上位エージェントプロセス、並列エージェントプロセスの介在による並列処理が開始される。この、制御リストはタスクプール部にセットされる。ここで、リストが個別に添字の値を持つ必要はなく、ある規則に従い、パックして多次元性を1次元に簡約、つまり単純な長さで定義しておき、サーバプロセスでの実際の処理開始時に復元すればよい。
【0063】次に、動的負荷分散を図るための、上位エージェントプロセスにおけるロジックの一例について述べる。注意すべきは、上位エージェントによってタスク制御リストの全長さStot.が一度にサーバ数Mで分割されるのではなく、周期幅を持って繰り返し分割されることである。図18に、分割情報を含む並列タスクのテーブル構造を示す。最初の分割周期の長さをSini.とする。Sini.は、初期値としてクライアントプロセス側から、エージェント管理システム側にタスクリストを渡す際に与える。さて、第1回目の各エージェントプロセス/サーバプロセスに対する割当ては次のように行われる。
【0064】エージェントプロセスは、サーバプロセスを生成し終わると、上位エージェントに対してタスクの割当てを要求する。上位エージェントは、一番最初に要求が到着した時から初期待ち時間Qini.だけ待ち、その間に要求を出して揃ったエージェントに対して、負荷に応じたタスクブロックの割当てを行う。ここで、既に各WSには負荷のバラツキがあり、これによりサーバプロセスの生成に要する時間もまちまちとなるので、揃うエージェントプロセスの数N1 はMとは限らない。初期待ち時間Qini.も、クライアント側から、最初の分割周期の長さSini.と共に渡す。各WSでの負荷の違いの考慮は、以下のように行われる。
【0065】あるエージェントが存在するWSのロードアベレージ値の最大値(静的)を【0066】
【外1】

【0067】、この第1回目の割当て時のロードアベレージ値(動的)を【0068】
【外2】

【0069】とすると、利用可能度【0070】
【外3】

【0071】は(4)式で与えられる。
【0072】
【数4】

【0073】一方、そのWSの速度を【0074】
【外4】

【0075】とすると、割当て時の利用可能な速度【0076】
【外5】

【0077】は(5)式のように表される。
【0078】
【数5】

【0079】得られた【0080】
【外6】

【0081】よりWS群から成る分散環境の計算能力P1 は、(6)式と表せる。
【0082】
【数6】

【0083】従って、第1回目で、エージェントαが得るタスクブロックの割当て【0084】
【外7】

【0085】は(7)式となる。
【0086】
【数7】

【0087】{p,q,r,s}の部分割当てタスクブロックを得たエージェントプロセスは、それを自分の受持ちのLQ サーバプロセスにメッセージ送信する。サーバは、それに従い、対応する部分の{Cpqrsij}と{Dpqrs}をセットし、{Bij}に積和寄与を加算する。ここで、2組添字の{i,j}に関しては可能な全てが尽くされる。サーバは与えられたタスクが完了すると、それを示すフラグをエージェントに返送する。これでエージェントプロセスに制御が戻る。受信したフラグが正常であるならば、エージェントプロセスは、それをエージェント管理システムに通知する。これにより、図18のテーブルに、割当てタスクブロックの正常終了と担当エージェントのサインが記される。これが、あるエージェントプロセスにおけるループの一単位である。
【0088】次に第2回目のタスク割当てだが、第1回目の処理中にも負荷は動的に変動しているので、各サーバプロセスで処理に要した経過時間【0089】
【外8】

【0090】にはバラツキがあるはずで、一番最初に第2回目のタスクの割当て要求を出すタイミングもまちまちである。従って、待ち時間内に揃い、割当てをもらえるエージェントのN2 は、必ずしも前回のN1 と同じではない。第1回目での経過時間のバラツキの程度は、1つの計量として、第2回目で揃ったN2 に対する平均ε1 ((8)式に示す)から、(9)式で示される分散σ1 を求めて判断することができる。
【0091】
【数8】

【0092】待ち時間に間に合わなかったならば、そのエージェントプロセス、およびサーバプロセスは次の回まで待機することになる。第3回目以降の割当ても同様である。
【0093】次に、上位エージェントプロセスによる周期幅と待ち時間の変更・最適化のロジックについてである。まず、周期に関しては、1つの目安は経過時間の分散の変化(σ(I+1) −σ1)である。これが、正ならば分散は大きくなる方向であるから、周期を短くして各ノードの経過時間を減らす。逆に負であれば、通信頻度をより減らすように伸ばす。伸縮は、Sini.に適当なスケール因子を逐次掛けて行う。待ち時間Qini.に関しては、揃うエージェントの数の変化が目安になる。ここで、集合数の変化(N(I+1) −NI )が負ならば伸ばす必要があるのは言うまでもない。もちろん、エージェントの総数MとNI の関係も参考にする。Qini.に対しても同様に、変更・最適化のためのスケーリングを行う。
【0094】上記の一連のプロセス流れが、タスクブロックの長さがゼロ、すなわちリストが尽くされるまで繰り返される。ゼロの割り当てタスクは、そのLQ サーバで成すべき積和処理の完了を意味する。つまり、長さゼロのタスクブロックをサーバプロセスが受け取ると、エージェントプロセス側に結果の送信希望のフラグが返送され、エージェント側は、飛び出し後、サーバから不完全生成された{Bij}要素の受信を待つこととなる。こうして、各エージェントプロセスは個々の受持ちサーバプロセスから不完全生成{Bij}を受け取ることが出来、続けて、これらをクライアントプロセス側に転送すれば、エージェントの役目は終わる。後は、クライアントが、それらループを使って受信し、全受信完了後、式(3)に従って次々に足し合わせれば、完全な{Bij}を得て、エージェント管理の完了を告げる。
【0095】エージェントを用いた式(2)の超行列積和の並列サーバプロセス実行中に、あるサーバプロセスを実行しているWSが障害により使用不能となっても、本発明によれば、図18のタスクテーブルには担当したエージェントのサインが記されているので、容易にリカバリの手続きを取り、確実に目的ジョブを行うことが出来る。障害の発生は、そのWS上のエージェント管理システムからの通信が途絶えることで検出される。そして、リカバリには、障害WSに任されていたタスクを集め、他の生きているエージェントプロセスで再実行を行えばよい。タイミングとしては、障害発生が起きたすぐ後の割り当て要求時、もしくは一通りタスクリストを終えてから、いずれでも可能である。障害による台数の(M−1)への減少は、むろんクライアント側にも通知される。一方、障害を受けていたWSが途中で復旧し、その上のエージェント管理システムが立ち上がれば、再度サーバとして利用が可能となる。この場合も、障害そのものによって失われたタスクは適に再実行される。また、実行中に、(M+1)台目のWSを新たに追加しても、同様にエージェント管理システムが、新たなエージェントプロセスを生成するので、そのWSを取り込んで利用することが出来る。
【0096】これまで述べてきた例から、本発明によれば、エージェント管理システムを有するため、上記のWSクラスターにベクトルCPUのスーパーコンピュータをさらに結合した分散型環境でも同様に、式(2)の超行列積和を、動的な負荷分散を行いつつ並列実行することが容易であることがわかる。そのためには、ベクトル実行で部分的な積和処理を行うモジュールLR を用意し、図5のソフトウェア資源テーブルにその情報を加え、クライアントでのエージェント呼び出しのスクリプトを適に変更するだけでよい。
【0097】
【発明の効果】以上示したように、本発明によればエージェント制御を分散型計算機環境に導入することにより、環境内のハードウェア資源とソフトウェア資源を有効かつ効率よく利用して、ユーザーの投入したアプリケーションジョブを最適実行することが可能である。アプリケーションの開発者、維持管理者にとって、エージェント制御の導入に伴う修正は少なくて済む。また、環境内の資源の開発者、維持管理者に対しても良好な保守性をもたらす。さらに、マルチベンダにより提供されるモジュールの使用費用が、そのコール回数や総CPU時間に応じて加算されるような運用形態に対しても対応が容易である。




 

 


     NEWS
会社検索順位 特許の出願数の順位が発表

URL変更
平成6年
平成7年
平成8年
平成9年
平成10年
平成11年
平成12年
平成13年


 
   お問い合わせ info@patentjp.com patentjp.com   Copyright 2007-2013