JPH0916534A - 分散型プロセス処理方法およびその装置 - Google Patents
分散型プロセス処理方法およびその装置Info
- Publication number
- JPH0916534A JPH0916534A JP7164837A JP16483795A JPH0916534A JP H0916534 A JPH0916534 A JP H0916534A JP 7164837 A JP7164837 A JP 7164837A JP 16483795 A JP16483795 A JP 16483795A JP H0916534 A JPH0916534 A JP H0916534A
- Authority
- JP
- Japan
- Prior art keywords
- agent
- server
- client
- information
- task
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Landscapes
- Multi Processors (AREA)
- Complex Calculations (AREA)
- Computer And Data Communications (AREA)
Abstract
(57)【要約】
【目的】 ネットワークで結合された均一あるいは不均
一に分散構成された計算機環境において、ユーザーの投
入ジョブをサーバに効率よく分散実行処理させる。 【構成】 ユーザーの投入ジョブに係るアプリケーショ
ンプログラムのプロセス流れに対して、クライアントと
サーバプロセス間に介在するエージェントプロセスを生
成する。エージェントは、計算機に関する静的性能と動
的な負荷状況の変動などハードウェア資源に関する情報
と、計算機環境内のプログラムモジュールと随伴するデ
ータなどソフトウェア資源に関する情報とに基づいて、
クライアントプロセスより依頼された目的ジョブをサー
バプロセスに分配し実行処理させる。
一に分散構成された計算機環境において、ユーザーの投
入ジョブをサーバに効率よく分散実行処理させる。 【構成】 ユーザーの投入ジョブに係るアプリケーショ
ンプログラムのプロセス流れに対して、クライアントと
サーバプロセス間に介在するエージェントプロセスを生
成する。エージェントは、計算機に関する静的性能と動
的な負荷状況の変動などハードウェア資源に関する情報
と、計算機環境内のプログラムモジュールと随伴するデ
ータなどソフトウェア資源に関する情報とに基づいて、
クライアントプロセスより依頼された目的ジョブをサー
バプロセスに分配し実行処理させる。
Description
【0001】
【産業上の利用分野】本発明は、ネットワークで結合さ
れた分散型の計算機環境において、ユーザーにより投入
されるアプリケーションプログラムのジョブを、環境内
のハードウェア資源、およびソフトウェア資源を有効か
つ効率よく利用して実行する、分散型プロセス処理方法
およびその装置に関するものである。
れた分散型の計算機環境において、ユーザーにより投入
されるアプリケーションプログラムのジョブを、環境内
のハードウェア資源、およびソフトウェア資源を有効か
つ効率よく利用して実行する、分散型プロセス処理方法
およびその装置に関するものである。
【0002】
【従来の技術】高速大容量ネットワーク、縮小命令セッ
トCPU(RISC)などの技術の急速な進歩により、
WS(ワークステーション)など安価な計算機資源をク
ラスター状に結合して分散型処理環境を構築し、アプリ
ケーションソフトウェアを、メッセージ通信を通じてク
ライアント/サーバ方式で実行する形態を取ることによ
り、価格性能比に優れたジョブ処理が可能になってきて
いる。こうした分散化の流れは、高性能専用機であるス
ーパーコンピュータの分野にも広まり、単一ベクトルC
PU型よりも、ベクトルCPUを並列にして処理の分散
を図った高並列機や、RISCを数千に及ぶ規模にまで
並列分散した超並列機の方が主流になりつつあるが、分
散制御の基本はWSクラスターと同様にメッセージ通信
に基づくものが多い。
トCPU(RISC)などの技術の急速な進歩により、
WS(ワークステーション)など安価な計算機資源をク
ラスター状に結合して分散型処理環境を構築し、アプリ
ケーションソフトウェアを、メッセージ通信を通じてク
ライアント/サーバ方式で実行する形態を取ることによ
り、価格性能比に優れたジョブ処理が可能になってきて
いる。こうした分散化の流れは、高性能専用機であるス
ーパーコンピュータの分野にも広まり、単一ベクトルC
PU型よりも、ベクトルCPUを並列にして処理の分散
を図った高並列機や、RISCを数千に及ぶ規模にまで
並列分散した超並列機の方が主流になりつつあるが、分
散制御の基本はWSクラスターと同様にメッセージ通信
に基づくものが多い。
【0003】メッセージ通信の特徴の1つは、均一構成
の場合はもちろん、マルチベンダによるWS群をクラス
ターにする等の不均一構成の場合でも、個々のWS上の
OSの違いに拠らずに対応出来るポータビリティの良さ
である。最近では、メッセージ通信により、距離的に離
れたWSクラスター同士を結合したり、WSクラスター
とスーパーコンピュータを結合して高次の分散環境を構
築する試みも成されつつある。
の場合はもちろん、マルチベンダによるWS群をクラス
ターにする等の不均一構成の場合でも、個々のWS上の
OSの違いに拠らずに対応出来るポータビリティの良さ
である。最近では、メッセージ通信により、距離的に離
れたWSクラスター同士を結合したり、WSクラスター
とスーパーコンピュータを結合して高次の分散環境を構
築する試みも成されつつある。
【0004】メッセージ通信の手段としては、特に科学
技術計算の分野では米オークリッジ国立研のPVMが使
われることが多い。メッセージ通信をアプリケーション
ソフトウェアに実装するには、元のプログラム構造をク
ライアント側とサーバ側に適にモジュール分割し、その
間で変数、もしくは配列領域をやり取りするように、通
信専用の外部ライブラリルーチンのコール文を挿入す
る。サーバプロセスを複数生成すれば、分散並列処理と
なる。この際、クライアント側とサーバ側で通信と処理
流れの手順をつじつまを合わせてコーディングしておく
必要がある。逆に言えば、メッセージ通信の変数、配列
並びが統一され、かつ機能が同一であれば、由来の異な
るモジュールを結合することも可能であり、共有ライブ
ラリ化されている、行列対角化などの数値処理用モジュ
ールなどを自アプリケーションの中で引用利用すること
もある。
技術計算の分野では米オークリッジ国立研のPVMが使
われることが多い。メッセージ通信をアプリケーション
ソフトウェアに実装するには、元のプログラム構造をク
ライアント側とサーバ側に適にモジュール分割し、その
間で変数、もしくは配列領域をやり取りするように、通
信専用の外部ライブラリルーチンのコール文を挿入す
る。サーバプロセスを複数生成すれば、分散並列処理と
なる。この際、クライアント側とサーバ側で通信と処理
流れの手順をつじつまを合わせてコーディングしておく
必要がある。逆に言えば、メッセージ通信の変数、配列
並びが統一され、かつ機能が同一であれば、由来の異な
るモジュールを結合することも可能であり、共有ライブ
ラリ化されている、行列対角化などの数値処理用モジュ
ールなどを自アプリケーションの中で引用利用すること
もある。
【0005】アプリケーションのあるプロセスからメッ
セージ通信のためのルーチンコールがあると、個々の機
種に固有のOSとは別に存在するデーモンと呼ばれるハ
ンドラーに制御が移り、ここから実際の通信パケットの
送出と受理が行われる。アプリケーション側から見る
と、OSはデーモンから要求されたパケットを下位レベ
ルで処理するのみで、あらわには見えず、これが上述の
良好なポータビリティにつながっているのだが、黒子で
あるデーモンも、実は、単にアプリケーションにおける
クライアントプロセスとサーバプロセスの間でのメッセ
ージ通信を仲介しているだけにすぎない。
セージ通信のためのルーチンコールがあると、個々の機
種に固有のOSとは別に存在するデーモンと呼ばれるハ
ンドラーに制御が移り、ここから実際の通信パケットの
送出と受理が行われる。アプリケーション側から見る
と、OSはデーモンから要求されたパケットを下位レベ
ルで処理するのみで、あらわには見えず、これが上述の
良好なポータビリティにつながっているのだが、黒子で
あるデーモンも、実は、単にアプリケーションにおける
クライアントプロセスとサーバプロセスの間でのメッセ
ージ通信を仲介しているだけにすぎない。
【0006】従って、分散型環境として与えられた計算
機資源を有効利用出来るような高度なプロセス流れの組
立ては、煩雑ではあるがアプリケーション側で全て責任
を持ってコーディングし、実現をしなければならない。
機資源を有効利用出来るような高度なプロセス流れの組
立ては、煩雑ではあるがアプリケーション側で全て責任
を持ってコーディングし、実現をしなければならない。
【0007】
【発明が解決しようとする課題】まず、分散型環境に含
まれるハードウェア資源に関連する問題点を挙げる。
まれるハードウェア資源に関連する問題点を挙げる。
【0008】既に述べたように、従来のメッセージ通信
制御では、アプリケーション側からは機種の違いは見え
ない。しかし、例えば、あるジョブの実行のために、環
境内の全てのWSを並列化サーバプロセスのみに独占的
に従事させる場合でも、各WSのCPUの速度性能差に
ばらつきが在れば、クライアントプロセスが単純にサー
バプロセスのタスクリストを均等割りして発行すると、
最も低速なWSに律速されてしまうために高い処理効率
は得られない。
制御では、アプリケーション側からは機種の違いは見え
ない。しかし、例えば、あるジョブの実行のために、環
境内の全てのWSを並列化サーバプロセスのみに独占的
に従事させる場合でも、各WSのCPUの速度性能差に
ばらつきが在れば、クライアントプロセスが単純にサー
バプロセスのタスクリストを均等割りして発行すると、
最も低速なWSに律速されてしまうために高い処理効率
は得られない。
【0009】これを避けるには、アプリケーションジョ
ブの実行前に、WSの性能差をパラメータとしてクライ
アントプロセスに与え、それに応じてタスクの割り当て
方を変える対策が考えられるが、実際の運用環境では上
で仮定した独占的従事の条件下ではなく、複数のジョブ
が同時に投入されている非独占的な条件で、各WSの負
荷状況は動的に変化しているため、事前の静的な割り当
てでは効果的な改善は望めない。この問題は、環境内の
WSの数が増えるほど深刻化する。さらに、あるWSが
障害発生により実行中に使用不能となった場合、それが
認識され、さらに障害WSが担当していたサーバプロセ
スがきちんと代替されて処理全体の整合性が保たれなけ
ればならないが、通常のメッセージ通信制御ではデーモ
ンにその機能が無いために、クライアントプロセスまで
も継続処理不能状態に陥ってしまい、目的のアプリケー
ションジョブそのものを異常終了させざるを得なくな
る。あるいは、逆に、実行中に障害から復旧したWSが
環境内にあっても、それをサーバ用に動的に有効利用す
ることは出来ない。
ブの実行前に、WSの性能差をパラメータとしてクライ
アントプロセスに与え、それに応じてタスクの割り当て
方を変える対策が考えられるが、実際の運用環境では上
で仮定した独占的従事の条件下ではなく、複数のジョブ
が同時に投入されている非独占的な条件で、各WSの負
荷状況は動的に変化しているため、事前の静的な割り当
てでは効果的な改善は望めない。この問題は、環境内の
WSの数が増えるほど深刻化する。さらに、あるWSが
障害発生により実行中に使用不能となった場合、それが
認識され、さらに障害WSが担当していたサーバプロセ
スがきちんと代替されて処理全体の整合性が保たれなけ
ればならないが、通常のメッセージ通信制御ではデーモ
ンにその機能が無いために、クライアントプロセスまで
も継続処理不能状態に陥ってしまい、目的のアプリケー
ションジョブそのものを異常終了させざるを得なくな
る。あるいは、逆に、実行中に障害から復旧したWSが
環境内にあっても、それをサーバ用に動的に有効利用す
ることは出来ない。
【0010】つまり、従来技術ではメッセージ通信をハ
ンドルするデーモンは、分散環境内のハードウェア資源
の動的な変化に反応して、アプリケーションジョブの実
行が確実かつ最適に行われることを保証する手段を持っ
ていない。むろん、OSは個々のWSに存在している
が、ネットワークを通じて統合的にジョブ実行を動的管
理する機能は有しておらず全く無力である。
ンドルするデーモンは、分散環境内のハードウェア資源
の動的な変化に反応して、アプリケーションジョブの実
行が確実かつ最適に行われることを保証する手段を持っ
ていない。むろん、OSは個々のWSに存在している
が、ネットワークを通じて統合的にジョブ実行を動的管
理する機能は有しておらず全く無力である。
【0011】一方、アプリケーション側でハードウェア
環境の動的変化にきちんと対応するためには、システム
コールなどを用いて自らが環境情報を取得し、それに基
づいて複雑な最適制御を行うようにプログラム開発者が
コーディングしておかなくてはならないが、煩雑となる
他、分散環境の機種内訳が変わる度に修正が必要とな
り、保守性が悪化してしまう。別の方策としては、通常
行われるようにアプリケーションプログラムをクライア
ントモジュール部とサーバモジュール部に分けるだけで
はなく、これらから制御のみに専念する部分を全く別に
分離し、制御プロセスにクライアントプロセス、サーバ
プロセスの両方を管理させることも考えられる。しか
し、この方法を実現するには元のクライアント/サーバ
式のアプリケーションプログラムの大幅な修正が必要で
あり、しかも、それでもなお、管理部の構造は個々のア
プリケーションに依存して異なるので汎用性、一般性は
なく、抜本的な解決とはなり得ない。
環境の動的変化にきちんと対応するためには、システム
コールなどを用いて自らが環境情報を取得し、それに基
づいて複雑な最適制御を行うようにプログラム開発者が
コーディングしておかなくてはならないが、煩雑となる
他、分散環境の機種内訳が変わる度に修正が必要とな
り、保守性が悪化してしまう。別の方策としては、通常
行われるようにアプリケーションプログラムをクライア
ントモジュール部とサーバモジュール部に分けるだけで
はなく、これらから制御のみに専念する部分を全く別に
分離し、制御プロセスにクライアントプロセス、サーバ
プロセスの両方を管理させることも考えられる。しか
し、この方法を実現するには元のクライアント/サーバ
式のアプリケーションプログラムの大幅な修正が必要で
あり、しかも、それでもなお、管理部の構造は個々のア
プリケーションに依存して異なるので汎用性、一般性は
なく、抜本的な解決とはなり得ない。
【0012】ハードウェア資源の動的な有効利用の困難
さは、WSクラスターに限ったことではなく、メッセー
ジ通信制御による並列分散型のスーパーコンピュータに
おいてはより先鋭に表れる。例を挙げれば、CPUの数
が64で、これを4つのジョブで公平に利用しようとす
る場合、各ジョブが共に64CPUを共有して使うので
はなく、16CPUずつにあらかじめ分割し、互いにC
PU使用が重ならないように運用されることが多い。最
初の3つのジョブが終了しても、まだ実行中の4つ目の
ジョブは、最後まで最初の16CPUのまま走ることに
なる。次に投入されるべき5つ目のジョブが、64CP
Uを全て使うことを要求していれば、4つ目が終るまで
実際の投入は待たなければらない。これを、アプリケー
ション側から改善しようとしても、既述のようにコーデ
ィングが煩雑であることは疑いなく、またWSクラスタ
ーへ移植する際には、改めて修正する必要があることも
言うまでもない。
さは、WSクラスターに限ったことではなく、メッセー
ジ通信制御による並列分散型のスーパーコンピュータに
おいてはより先鋭に表れる。例を挙げれば、CPUの数
が64で、これを4つのジョブで公平に利用しようとす
る場合、各ジョブが共に64CPUを共有して使うので
はなく、16CPUずつにあらかじめ分割し、互いにC
PU使用が重ならないように運用されることが多い。最
初の3つのジョブが終了しても、まだ実行中の4つ目の
ジョブは、最後まで最初の16CPUのまま走ることに
なる。次に投入されるべき5つ目のジョブが、64CP
Uを全て使うことを要求していれば、4つ目が終るまで
実際の投入は待たなければらない。これを、アプリケー
ション側から改善しようとしても、既述のようにコーデ
ィングが煩雑であることは疑いなく、またWSクラスタ
ーへ移植する際には、改めて修正する必要があることも
言うまでもない。
【0013】また、これまで述べてきたハードウェア資
源に関する従来技術の問題点が、WSクラスター同士を
互いに接続したり、あるいはWSクラスターと並列スー
パーコンピュータを接続して構成されるより高次の分散
環境では、より一層顕在化するのは明らかである。
源に関する従来技術の問題点が、WSクラスター同士を
互いに接続したり、あるいはWSクラスターと並列スー
パーコンピュータを接続して構成されるより高次の分散
環境では、より一層顕在化するのは明らかである。
【0014】次に、ソフトウェア資源の有効利用の観点
から従来技術の問題点を挙げる。まず最初に、計算機の
特性に応じた最適なプログラムモジュールの選択利用に
関してである。例えば、前述のように、スカラー実行の
WSクラスターとベクトルCPUを1つ持つスーパーコ
ンピュータを接続した分散処理環境での、変分法の求解
を要求するユーザージョブの実行において、アプリケー
ションプログラムが、変分に関わる行列要素の構築を並
列サーバプロセスとして行うことを考える。
から従来技術の問題点を挙げる。まず最初に、計算機の
特性に応じた最適なプログラムモジュールの選択利用に
関してである。例えば、前述のように、スカラー実行の
WSクラスターとベクトルCPUを1つ持つスーパーコ
ンピュータを接続した分散処理環境での、変分法の求解
を要求するユーザージョブの実行において、アプリケー
ションプログラムが、変分に関わる行列要素の構築を並
列サーバプロセスとして行うことを考える。
【0015】一般的に、同一の数値処理を行うにも、ス
カラー実行とベクトル実行では最適なアルゴリズムは異
なり、必然的にモジュールのコードも異なる。従って、
サーバプロセスでの行列要素の構築は、WSではスカラ
ー用のモジュールで、スーパーコンピュータではベクト
ル用のモジュールで行われるべきである。しかし、現状
では、いずれかの一つのモジュールが妥協的に使われる
ことが多い。きちんと計算機の特性を活かすには、アプ
リケーションプログラムの開発者、もしくは維持管理者
が、運用計算機の構成を把握し、それに応じたモジュー
ルの指定、前述の速度差に応じた静的負荷分散の指示、
および必要なメッセージ通信などを明示的にコーディン
グすることになるが、移植性と保守性の悪さは明白であ
る。さらに、動的な環境変化に対応する制御手段までも
実装しようとすれば、その困難はいよいよ深刻である。
カラー実行とベクトル実行では最適なアルゴリズムは異
なり、必然的にモジュールのコードも異なる。従って、
サーバプロセスでの行列要素の構築は、WSではスカラ
ー用のモジュールで、スーパーコンピュータではベクト
ル用のモジュールで行われるべきである。しかし、現状
では、いずれかの一つのモジュールが妥協的に使われる
ことが多い。きちんと計算機の特性を活かすには、アプ
リケーションプログラムの開発者、もしくは維持管理者
が、運用計算機の構成を把握し、それに応じたモジュー
ルの指定、前述の速度差に応じた静的負荷分散の指示、
および必要なメッセージ通信などを明示的にコーディン
グすることになるが、移植性と保守性の悪さは明白であ
る。さらに、動的な環境変化に対応する制御手段までも
実装しようとすれば、その困難はいよいよ深刻である。
【0016】続いて、バージョンの更新に関連して問題
点を指摘する。例として、格子点データを与えることに
より数値積分を実行するモジュールが、分散計算機環境
内に共有ライブラリの一つとして置かれ、様々なアプリ
ケーションプログラムにおいてメッセージ通信を通じ
て、サーバとして引用されている状況を考え、必要な数
値データに合わせて、当該積分モジュール内において読
み参照される数値補間用テーブルのファイル名を渡す必
要があるとする。
点を指摘する。例として、格子点データを与えることに
より数値積分を実行するモジュールが、分散計算機環境
内に共有ライブラリの一つとして置かれ、様々なアプリ
ケーションプログラムにおいてメッセージ通信を通じ
て、サーバとして引用されている状況を考え、必要な数
値データに合わせて、当該積分モジュール内において読
み参照される数値補間用テーブルのファイル名を渡す必
要があるとする。
【0017】さて、このライブラリモジュールのバージ
ョンが更新され、補間テーブルのファイルも合わせて更
新されると、モジュール/テーブル間の整合性に留意し
つつ、各アプリケーションに対して対応する変更を個別
に行う必要があり、保守上、煩雑なこの変更作業をバー
ジョン更新の度に繰り返さなければならない。アプリケ
ーションの開発者、維持管理者が複数である場合、ライ
ブラリの管理者がバージョンの更新を各人に通知し、各
々が変更を行うことになるが、周知徹底される保証はな
い。
ョンが更新され、補間テーブルのファイルも合わせて更
新されると、モジュール/テーブル間の整合性に留意し
つつ、各アプリケーションに対して対応する変更を個別
に行う必要があり、保守上、煩雑なこの変更作業をバー
ジョン更新の度に繰り返さなければならない。アプリケ
ーションの開発者、維持管理者が複数である場合、ライ
ブラリの管理者がバージョンの更新を各人に通知し、各
々が変更を行うことになるが、周知徹底される保証はな
い。
【0018】上記の2例で見たように、ソフトウェア資
源の有効利用という面でも従来技術には問題がある。ま
た、先に述べたように、ハードウェア資源の有効利用に
関連しても問題があり、これら両者を共に解決する手段
が必要である。
源の有効利用という面でも従来技術には問題がある。ま
た、先に述べたように、ハードウェア資源の有効利用に
関連しても問題があり、これら両者を共に解決する手段
が必要である。
【0019】
【課題を解決するための手段】上記課題を解決するた
め、本発明は、ネットワークで結合された均一もしくは
不均一に分散構成された計算機環境におけるプロセス処
理方法において、ユーザーの投入ジョブに係るアプリケ
ーションプログラムのプロセス流れに対して、個々の計
算機に関する静的な性能と動的な負荷状況の変動などハ
ードウェア資源に関する情報と、計算機環境内のプログ
ラムモジュールと随伴するデータなどソフトウェア資源
に関する情報とを把握する単数あるいは複数のエージェ
ントプロセスを生成し、生成された前記エージェントプ
ロセスがクライアントプロセスとサーバプロセス間に介
在し、ハードウェア資源に関する情報とソフトウェア資
源に関する情報に基づいて、クライアントプロセスより
指令された目的ジョブをサーバプロセスに実行処理させ
ることを特徴とする分散型プロセス処理方法である。
め、本発明は、ネットワークで結合された均一もしくは
不均一に分散構成された計算機環境におけるプロセス処
理方法において、ユーザーの投入ジョブに係るアプリケ
ーションプログラムのプロセス流れに対して、個々の計
算機に関する静的な性能と動的な負荷状況の変動などハ
ードウェア資源に関する情報と、計算機環境内のプログ
ラムモジュールと随伴するデータなどソフトウェア資源
に関する情報とを把握する単数あるいは複数のエージェ
ントプロセスを生成し、生成された前記エージェントプ
ロセスがクライアントプロセスとサーバプロセス間に介
在し、ハードウェア資源に関する情報とソフトウェア資
源に関する情報に基づいて、クライアントプロセスより
指令された目的ジョブをサーバプロセスに実行処理させ
ることを特徴とする分散型プロセス処理方法である。
【0020】また、本発明の第2の発明は、ネットワー
クで結合された均一もしくは不均一に分散構成された計
算機環境において使用され、クライアントとサーバとエ
ージェント管理システムより構成される分散型プロセス
処理装置であって、エージェント管理システムは、クラ
イアントよりユーザーの投入ジョブに係るタスクを受け
付ける受付部と、個々の計算機に関する静的な性能と動
的な負荷状況の変動などハードウェア資源に関する情報
と、計算機環境内のプログラムモジュールと随伴するデ
ータなどソフトウェア資源に関する情報を保持する資源
情報管理部と、前記受付部からの命令に基づいてエージ
ェントプロセスを生成、消去するエージェントプロセス
操作部とから構成され、エージェントプロセス操作部に
より生成されたエージェントプロセスは、クライアント
とサーバ間に介在し、資源情報管理部より得たハードウ
ェア資源に関する情報とソフトウェア資源に関する情報
とに基づいて前記目的ジョブをサーバに実行処理させる
ことを特徴とする分散型プロセス処理装置である。
クで結合された均一もしくは不均一に分散構成された計
算機環境において使用され、クライアントとサーバとエ
ージェント管理システムより構成される分散型プロセス
処理装置であって、エージェント管理システムは、クラ
イアントよりユーザーの投入ジョブに係るタスクを受け
付ける受付部と、個々の計算機に関する静的な性能と動
的な負荷状況の変動などハードウェア資源に関する情報
と、計算機環境内のプログラムモジュールと随伴するデ
ータなどソフトウェア資源に関する情報を保持する資源
情報管理部と、前記受付部からの命令に基づいてエージ
ェントプロセスを生成、消去するエージェントプロセス
操作部とから構成され、エージェントプロセス操作部に
より生成されたエージェントプロセスは、クライアント
とサーバ間に介在し、資源情報管理部より得たハードウ
ェア資源に関する情報とソフトウェア資源に関する情報
とに基づいて前記目的ジョブをサーバに実行処理させる
ことを特徴とする分散型プロセス処理装置である。
【0021】目的ジョブの終了後は、エージェントプロ
セスはエージェント管理システムにより消去される。
セスはエージェント管理システムにより消去される。
【0022】クライアントプロセスとサーバプロセス間
に介在するためにプロセスとして生成、消去されるエー
ジェントモジュールは、ライブラリ化されてエージェン
ト管理システム内部に置かれている。
に介在するためにプロセスとして生成、消去されるエー
ジェントモジュールは、ライブラリ化されてエージェン
ト管理システム内部に置かれている。
【0023】
【実施例】以下に、本発明の一実施例を図面を参照して
説明する。
説明する。
【0024】本発明によれば、アプリケーションプログ
ラムにおける、クライアントプロセスとサーバプロセス
間でのメッセージ通信は、従来技術のように直接やり取
りされるのではなく、図1に示すように、エージェント
プロセスの中間介在によって間接的にやり取りされる。
アプリケーションの開発者、維持管理者が、エージェン
トを利用するコード変更の要点は、クライアント部とサ
ーバ部の各々のメッセージ通信の直接参照コールを、エ
ージェントを解した間接参照コールにすることである。
これらエージェント関係ルーチンのコール形式は、むろ
ん汎用性、一般性を持ち、各アプリケーションがライブ
ラリとして共通利用出来る。いずれにせよ、明記すべき
は、エージェントプロセスは、まさしく、クライアント
プロセスとサーバプロセスの間に入る代理人として振舞
うのであって、そのアプリケーションのプロセス全体を
上位から管理する形式にはなっていないということであ
る。
ラムにおける、クライアントプロセスとサーバプロセス
間でのメッセージ通信は、従来技術のように直接やり取
りされるのではなく、図1に示すように、エージェント
プロセスの中間介在によって間接的にやり取りされる。
アプリケーションの開発者、維持管理者が、エージェン
トを利用するコード変更の要点は、クライアント部とサ
ーバ部の各々のメッセージ通信の直接参照コールを、エ
ージェントを解した間接参照コールにすることである。
これらエージェント関係ルーチンのコール形式は、むろ
ん汎用性、一般性を持ち、各アプリケーションがライブ
ラリとして共通利用出来る。いずれにせよ、明記すべき
は、エージェントプロセスは、まさしく、クライアント
プロセスとサーバプロセスの間に入る代理人として振舞
うのであって、そのアプリケーションのプロセス全体を
上位から管理する形式にはなっていないということであ
る。
【0025】図2に、本発明による計算機におけるエー
ジェント管理システムの階層の概念図を示す。図2よ
り、エージェントの管理システムはOSから見ればアプ
リケーションプログラムの1つに過ぎない。従って、不
均一構成の分散環境への実装にあたっても機種の違いを
強く意識することはない。
ジェント管理システムの階層の概念図を示す。図2よ
り、エージェントの管理システムはOSから見ればアプ
リケーションプログラムの1つに過ぎない。従って、不
均一構成の分散環境への実装にあたっても機種の違いを
強く意識することはない。
【0026】エージェントプロセスを生成、消去等の管
理を行い、さらに資源情報を把握するエージェント管理
システムは、分散環境内の計算機に対して個別に置かれ
るか、適当にまとめられた計算機グループ毎に置かれ
る。図3に、エージェント管理システムの構成図を模式
的に示す。
理を行い、さらに資源情報を把握するエージェント管理
システムは、分散環境内の計算機に対して個別に置かれ
るか、適当にまとめられた計算機グループ毎に置かれ
る。図3に、エージェント管理システムの構成図を模式
的に示す。
【0027】エージェント管理システムは、6つの構成
要素3.1〜3.6より成る。外側のメッセージ通信制
御部3.1は、クライアントプロセス、サーバプロセス
間の通信の他、当該管理システムの存在する計算機のO
S、および他の計算機上のエージェント管理システムと
の通信をハンドリングする。
要素3.1〜3.6より成る。外側のメッセージ通信制
御部3.1は、クライアントプロセス、サーバプロセス
間の通信の他、当該管理システムの存在する計算機のO
S、および他の計算機上のエージェント管理システムと
の通信をハンドリングする。
【0028】エージェント管理システムの内部は5つの
要素、クライアントからのエージェント使用の宣言やタ
スク依頼を受付ける部分(受付部)3.2、依頼された
タスクをプールしておく部分(タスクプール部)3.
3、ライブラリ部分3.4の中のエージェントプログラ
ムを起動して、プロセスとして生成・活性化する、ある
いは消去・不活性化するなどエージェントプロセスに対
する操作を行う部分(エージェント操作部)3.5、お
よび資源情報の取得・保持を行っている部分(資源情報
部)3.6から構成される。
要素、クライアントからのエージェント使用の宣言やタ
スク依頼を受付ける部分(受付部)3.2、依頼された
タスクをプールしておく部分(タスクプール部)3.
3、ライブラリ部分3.4の中のエージェントプログラ
ムを起動して、プロセスとして生成・活性化する、ある
いは消去・不活性化するなどエージェントプロセスに対
する操作を行う部分(エージェント操作部)3.5、お
よび資源情報の取得・保持を行っている部分(資源情報
部)3.6から構成される。
【0029】エージェント管理システムは、C言語等の
プログラム言語で記述されている。エージェントライブ
ラリ3.4はプロセスとして活性化されている部分と、
不活性の部分とを合わせ持つが、活性化された部分がジ
ョブ実行を仲介するエージェントプロセスとして機能す
る。エージェント管理システムのそれ以外の部分、3.
1〜3.3および3.5〜3.6は常にプロセスとして
活性な状態にある。
プログラム言語で記述されている。エージェントライブ
ラリ3.4はプロセスとして活性化されている部分と、
不活性の部分とを合わせ持つが、活性化された部分がジ
ョブ実行を仲介するエージェントプロセスとして機能す
る。エージェント管理システムのそれ以外の部分、3.
1〜3.3および3.5〜3.6は常にプロセスとして
活性な状態にある。
【0030】エージェントプロセス操作部3.5による
ライブラリ3.4でのエージェントプロセスの生成・消
去のプロセス操作は、該当する標準的な関数の呼出しに
よってなされる。
ライブラリ3.4でのエージェントプロセスの生成・消
去のプロセス操作は、該当する標準的な関数の呼出しに
よってなされる。
【0031】資源情報の取得・保持部3.6で取得・保
持されるハードウェア資源情報のテーブルについては、
図4に示すように、個々の計算機のCPU速度、あるい
はCPUがスカラー型なのかベクトル型なのか、といっ
た静的な項目と、ロードアベレージに代表されるような
CPU負荷の変動、利用可能メモリー空間や作業ファイ
ル量、そして障害の状況などの動的な項目に分けること
が出来る。静的な情報は、各計算機毎にファイル上にあ
らかじめ書いて設定しておけば、資源情報の取得・保持
部3.6によって読み込まれる。動的な環境情報は、資
源情報の取得・保持部3.6からの各OSに対するシス
テムコールにより、適当な時間間隔を持って随時取得さ
れる。
持されるハードウェア資源情報のテーブルについては、
図4に示すように、個々の計算機のCPU速度、あるい
はCPUがスカラー型なのかベクトル型なのか、といっ
た静的な項目と、ロードアベレージに代表されるような
CPU負荷の変動、利用可能メモリー空間や作業ファイ
ル量、そして障害の状況などの動的な項目に分けること
が出来る。静的な情報は、各計算機毎にファイル上にあ
らかじめ書いて設定しておけば、資源情報の取得・保持
部3.6によって読み込まれる。動的な環境情報は、資
源情報の取得・保持部3.6からの各OSに対するシス
テムコールにより、適当な時間間隔を持って随時取得さ
れる。
【0032】ソフトウェア資源の情報は、図5に示すよ
うに、プログラムとデータの機能と所在、相互参照のリ
ンク、および参照の履歴などに関する項目があり、静的
なハードウェア資源の情報と同様に、ファイル上に設定
され、そこから読み込まれる。ここで、プログラム情報
については、例えば、コンパイル時に取得することが出
来る。ライブラリを更新、ないしは新規に追加する場合
は、このソフトウェア情報のテーブルファイルのみを、
その旨に合わせて変更すればよく、個別のアプリケーシ
ョン側の変更は必要ではない。また、参照履歴について
は、エージェントの使用によって逐次更新される。
うに、プログラムとデータの機能と所在、相互参照のリ
ンク、および参照の履歴などに関する項目があり、静的
なハードウェア資源の情報と同様に、ファイル上に設定
され、そこから読み込まれる。ここで、プログラム情報
については、例えば、コンパイル時に取得することが出
来る。ライブラリを更新、ないしは新規に追加する場合
は、このソフトウェア情報のテーブルファイルのみを、
その旨に合わせて変更すればよく、個別のアプリケーシ
ョン側の変更は必要ではない。また、参照履歴について
は、エージェントの使用によって逐次更新される。
【0033】図4のハードウェア資源情報のテーブル
と、図5のソフトウェア資源の情報テーブルの中身は、
CPU速度のように各計算機毎の線形のエントリを持つ
もの、ネットワーク状況のように計算機間の行列型のエ
ントリを持つもの、プログラムとデータの参照関係のよ
うに不定型のエントリを持つものなど、複雑な内部構造
を有している。
と、図5のソフトウェア資源の情報テーブルの中身は、
CPU速度のように各計算機毎の線形のエントリを持つ
もの、ネットワーク状況のように計算機間の行列型のエ
ントリを持つもの、プログラムとデータの参照関係のよ
うに不定型のエントリを持つものなど、複雑な内部構造
を有している。
【0034】ここで、並列化されていないジョブを単一
実行する場合を例に取り、エージェントを使うジョブ実
行のプロセス流れを、エージェント管理システム内部の
動作も含め、図6を用いて詳細に説明する。ここでは、
メッセージ通信のハンドリング部は省略する。
実行する場合を例に取り、エージェントを使うジョブ実
行のプロセス流れを、エージェント管理システム内部の
動作も含め、図6を用いて詳細に説明する。ここでは、
メッセージ通信のハンドリング部は省略する。
【0035】最初に、クライアントプロセス6.1がエ
ージェント管理システム内の受付け部6.2にエージェ
ント使用の宣言6.10を行うと、受付部6.2からの
要求6.11に応じてエージェントプロセス操作部6.
3によりエージェント生成メッセージ6.12が発せら
れ、エージェントライブラリを元に、当該クライアント
プロセスを認識するエージェントプロセス6.4が生成
される。
ージェント管理システム内の受付け部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にセットされる。
クを、数値データの他に、処理の手続きやサーバに関す
る情報などを文字列のスクリプトとして記述し、タスク
6.13をエージェント側受付部6.2に依頼する。依
頼されたタスクは、エージェント側受付部6.2からの
依頼タスクのセット要求6.14によりタスクプール部
6.5にセットされる。
【0037】次に、エージェントプロセス6.4は、タ
スクプール部6.5から、依頼タスクの取得要求6.1
5、取得要求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)。
スクプール部6.5から、依頼タスクの取得要求6.1
5、取得要求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を消去する。
が正常であれば、タスクプール部6.5に依頼タスクが
正常終了したことを記し(6.22)、サーバプロセス
消去要求(メッセージ)6.23を発することによりサ
ーバプロセス6.7を消去する。
【0039】続いて、エージェントプロセス6.4は依
頼タスクの実行が正常に終了された結果をクライアント
プロセス6.1に返送する(6.24)。
頼タスクの実行が正常に終了された結果をクライアント
プロセス6.1に返送する(6.24)。
【0040】クライアントプロセス6.1はエージェン
トプロセス6.4からの結果を受け取り、最後に受付部
6.2にエージェント使用の停止を宣言する(6.2
5)と、受付部6.2からのサーバプロセスの消去要求
6.26に基づき、エージェントプロセス操作部6.3
がエージェントプロセス消去要求メッセージ6.27を
発しエージェントプロセス6.4は消去される。また、
受付部6.2からの実行済タスクの消去要求メッセージ
6.28によりタスクプール部6.5から依頼タスクの
内容も消去される。なお、どのサーバが選択されたかを
履歴として保持したい場合は、サーバプロセスの正常終
了が確立した時点で、エージェントプロセス6.4が資
源情報部6.6へ書き込みの要求を出せばよい。
トプロセス6.4からの結果を受け取り、最後に受付部
6.2にエージェント使用の停止を宣言する(6.2
5)と、受付部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に含まれる。
数となる場合は、それに応じてエージェントプロセスも
複数生成されると共に、それらの調停を担う上位エージ
ェントが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に割当てら
れたタスクを送って実際に処理を行わせる。これら一連
の割当て/処理を、並列タスク制御リストが尽きるまで
繰り返す。
として図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を消去する。
ジェントプロセスが介在する。すなわち、メッセージは
計算機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次方程式の
求解ジョブを取る。この例は、また、計算機の特徴の違
いに応じたソフトウェアの選択に関するエージェントの
機能についての述解も兼ねる。
体的動作例について、まず、エージェントの導入に伴う
アプリケーションプログラムの変更を例として説明す
る。例題として、(1)式に示される連立1次方程式の
求解ジョブを取る。この例は、また、計算機の特徴の違
いに応じたソフトウェアの選択に関するエージェントの
機能についての述解も兼ねる。
【0045】
【数1】
【0046】図8、図9は、連立一次方程式の求解にお
ける従来技術によるプロセス流れを記した擬コードであ
る。図8はクライアントでのプロセス流れを、図9はサ
ーバでのプロセス流れを示している。クライアントプロ
セスでは、入力データである左辺の行列要素{Aij}と
右辺のベクトル要素{bi }を最初にセットする。解ベ
クトル要素{xi }は、これらセットされた要素データ
をメッセージ通信で送ってサーバプロセスで求められ
る。このサーバプロセスは、WSのようなスカラー型、
あるいはスーパーコンピュータのようなベクトル型かに
よって異なるモジュール、LS とLV で実行される。速
度は、もちろんベクトル版LV の方が高速であり、与え
られた分散型計算機環境でベクトルCPUの計算機が利
用出来るなら、こちらが使われるべきである。
ける従来技術によるプロセス流れを記した擬コードであ
る。図8はクライアントでのプロセス流れを、図9はサ
ーバでのプロセス流れを示している。クライアントプロ
セスでは、入力データである左辺の行列要素{Aij}と
右辺のベクトル要素{bi }を最初にセットする。解ベ
クトル要素{xi }は、これらセットされた要素データ
をメッセージ通信で送ってサーバプロセスで求められ
る。このサーバプロセスは、WSのようなスカラー型、
あるいはスーパーコンピュータのようなベクトル型かに
よって異なるモジュール、LS とLV で実行される。速
度は、もちろんベクトル版LV の方が高速であり、与え
られた分散型計算機環境でベクトルCPUの計算機が利
用出来るなら、こちらが使われるべきである。
【0047】この要請を実現するために、煩雑とはなる
が、図8よりわかるように、サーバへの求解メッセージ
送信の前にクライアント自らが分散型環境の情報を取得
し、利用可能な計算機に応じて、タスク依頼のための送
信、および結果の受信のための識別子を設定するように
コードされている。
が、図8よりわかるように、サーバへの求解メッセージ
送信の前にクライアント自らが分散型環境の情報を取得
し、利用可能な計算機に応じて、タスク依頼のための送
信、および結果の受信のための識別子を設定するように
コードされている。
【0048】さて、クライアントからサーバへ
{Aij}、{bi }のメッセージが送信されると、図9
に示すようにLS 、LV いずれかのサーバプロセスが、
クライアント送信時の識別子に応じてそれを受信し、式
(1)の求解処理を行い、あらかじめクライアントから
与えられた識別子を付けて、解データ{xi }をメッセ
ージとして返送する。そして、クライアントは、サーバ
からその求解結果を受信する。以上が従来技術によるプ
ロセス流れである。
{Aij}、{bi }のメッセージが送信されると、図9
に示すようにLS 、LV いずれかのサーバプロセスが、
クライアント送信時の識別子に応じてそれを受信し、式
(1)の求解処理を行い、あらかじめクライアントから
与えられた識別子を付けて、解データ{xi }をメッセ
ージとして返送する。そして、クライアントは、サーバ
からその求解結果を受信する。以上が従来技術によるプ
ロセス流れである。
【0049】一方、図10、図11、図12は本発明に
よるエージェントを用いる場合のプロセス流れである。
図10はクライアントでのプロセス流れを、図11はエ
ージェントでのプロセス流れを、図12はサーバでのプ
ロセス流れを示している。図10において、{Aij}と
{bi }の要素を最初にセットするところは従来の図8
と同じである。しかし、その下で、本発明によれば環境
情報と識別子に関する部分が元のクライアントコードか
らは省かれていること、メッセージ送受信のコールが全
く異なっていることに注意されたい。さて、クライアン
トプロセスがエージェント管理システムにエージェント
プロセスの使用を宣言すると、当該クライアントを認識
するエージェントプロセスが生成される。続いて、クラ
イアントは、エージェントプロセス側に、入力要素{A
ij}、{bi }の配列領域、さらに合わせて、連立1次
方程式の求解である旨の宣言、求解用モジュールLS と
LV の情報、およびモジュール選択の基準をメッセージ
として送信する。これで、エージェントプロセスに実行
の流れが移る。要素データ以外の項は、クライアントが
エージェントに対して、依頼するタスクの特徴、および
その処理方針をスクリプトとして与えることに対応して
いる。
よるエージェントを用いる場合のプロセス流れである。
図10はクライアントでのプロセス流れを、図11はエ
ージェントでのプロセス流れを、図12はサーバでのプ
ロセス流れを示している。図10において、{Aij}と
{bi }の要素を最初にセットするところは従来の図8
と同じである。しかし、その下で、本発明によれば環境
情報と識別子に関する部分が元のクライアントコードか
らは省かれていること、メッセージ送受信のコールが全
く異なっていることに注意されたい。さて、クライアン
トプロセスがエージェント管理システムにエージェント
プロセスの使用を宣言すると、当該クライアントを認識
するエージェントプロセスが生成される。続いて、クラ
イアントは、エージェントプロセス側に、入力要素{A
ij}、{bi }の配列領域、さらに合わせて、連立1次
方程式の求解である旨の宣言、求解用モジュールLS と
LV の情報、およびモジュール選択の基準をメッセージ
として送信する。これで、エージェントプロセスに実行
の流れが移る。要素データ以外の項は、クライアントが
エージェントに対して、依頼するタスクの特徴、および
その処理方針をスクリプトとして与えることに対応して
いる。
【0050】エージェントは、図11に示すように、図
5の環境情報の中の利用可能計算機のリスト、および与
えられた選択基準を元に、LS 、LV のいずれかのサー
バモジュールを選び、識別子を適に設定し、実際の求解
のために、入力要素{Aij}、{bi }のメッセージを
サーバに送る。この例の場合、モジュール選択の基準は
実行速度であるので、ベクトル機が使えれば、与えられ
た候補2つの中からLV が選ばれる。この候補挙げに係
る論理流れを図13に示す。
5の環境情報の中の利用可能計算機のリスト、および与
えられた選択基準を元に、LS 、LV のいずれかのサー
バモジュールを選び、識別子を適に設定し、実際の求解
のために、入力要素{Aij}、{bi }のメッセージを
サーバに送る。この例の場合、モジュール選択の基準は
実行速度であるので、ベクトル機が使えれば、与えられ
た候補2つの中からLV が選ばれる。この候補挙げに係
る論理流れを図13に示す。
【0051】サーバは、図12に示すようにエージェン
トからの入力要素の受信後、式(1)を解き、その後、
解要素{xi }のメッセージをエージェントに返送す
る。そして、エージェントは解を受取り、今度はクライ
アントにそれを送る。
トからの入力要素の受信後、式(1)を解き、その後、
解要素{xi }のメッセージをエージェントに返送す
る。そして、エージェントは解を受取り、今度はクライ
アントにそれを送る。
【0052】以上で、エージェントプロセスの主たる役
目は終わりで、制御は再びクライアント側に戻り、最後
に管理システムに役目終了を通知することで、エージェ
ントプロセスは消去される。この例で分かるように、エ
ージェントの介在により、クライアントとサーバの間に
直接の参照関係は無くなる。識別子によるサーバへのメ
ッセージルーティングはエージェントによって成され
る。
目は終わりで、制御は再びクライアント側に戻り、最後
に管理システムに役目終了を通知することで、エージェ
ントプロセスは消去される。この例で分かるように、エ
ージェントの介在により、クライアントとサーバの間に
直接の参照関係は無くなる。識別子によるサーバへのメ
ッセージルーティングはエージェントによって成され
る。
【0053】上の段落で行ったエージェント導入のメリ
ットを明確に示すために、元々のアプリケーション開発
者が作成したベクトル実行用のサーバモジュールLV よ
り高速な、第3者が開発したベクトル実行用のライブラ
リモジュールLT を使用する例を挙げる。
ットを明確に示すために、元々のアプリケーション開発
者が作成したベクトル実行用のサーバモジュールLV よ
り高速な、第3者が開発したベクトル実行用のライブラ
リモジュールLT を使用する例を挙げる。
【0054】LT を利用するためには、従来技術では、
当該アプリケーションの開発者、維持管理者がコードに
修正を加える必要があるが、本発明のようにエージェン
ト管理システムを用いていればその必要はない。代わり
に、分散環境の維持管理者が、元のLT のメッセージ通
信周りのみをエージェント管理用に適に修正し、LTの
特性に関する情報を図5のソフトウェア資源のテーブル
に加えておけばよい。それにより、図11、図13での
サーバモジュールの候補にLT が自動的に含まれるの
で、当該アプリケーション実行時に、ベクトルCPU機
が使えるならば、きちんと最速のLT が参照される。こ
の際、図5のテーブル中のLT についての参照履歴が更
新される。他のモジュール、例えば、超並列機用のモジ
ュールLPなどをライブラリに新たに加えることを考え
れば自明だが、この例はエージェント管理の導入によっ
てもたらされる保守性の良さを示している。なお、自開
発のサーバモジュールLS ,LV の使用に固執する場合
は、その旨を強制条件として、クライアントがエージェ
ントに渡すべきスクリプトに明記しておくことになる。
逆に、連立1次方程式の求解の旨だけを記し、モジュー
ルの指定を一切しないで済ますことも出来る。
当該アプリケーションの開発者、維持管理者がコードに
修正を加える必要があるが、本発明のようにエージェン
ト管理システムを用いていればその必要はない。代わり
に、分散環境の維持管理者が、元のLT のメッセージ通
信周りのみをエージェント管理用に適に修正し、LTの
特性に関する情報を図5のソフトウェア資源のテーブル
に加えておけばよい。それにより、図11、図13での
サーバモジュールの候補にLT が自動的に含まれるの
で、当該アプリケーション実行時に、ベクトルCPU機
が使えるならば、きちんと最速のLT が参照される。こ
の際、図5のテーブル中のLT についての参照履歴が更
新される。他のモジュール、例えば、超並列機用のモジ
ュールLPなどをライブラリに新たに加えることを考え
れば自明だが、この例はエージェント管理の導入によっ
てもたらされる保守性の良さを示している。なお、自開
発のサーバモジュールLS ,LV の使用に固執する場合
は、その旨を強制条件として、クライアントがエージェ
ントに渡すべきスクリプトに明記しておくことになる。
逆に、連立1次方程式の求解の旨だけを記し、モジュー
ルの指定を一切しないで済ますことも出来る。
【0055】サーバモジュールがファイルを扱う場合で
も、本発明のエージェント管理システムを用いれば同様
のメリットが得られる。前出の数値積分のライブラリモ
ジュールの例を再び取り上げる。積分を行うこのモジュ
ールLX を使うには、クライアント側から、当該モジュ
ール内で読み参照される補間テーブルファイルのファイ
ル名を、使用時に格子点のデータと共に与えるのだが、
それはバージョン毎に異なるために、従来技術ではバー
ジョンアップに対する保守は煩雑である。一方、本発明
のエージェントに依る場合には、クライアント側は格子
点の数値データとスクリプトを渡すだけでよい。図5の
ソフトウェア資源の情報テーブルには、プログラムと随
伴するデータに関する相互参照のリンクが在るので、エ
ージェントプロセスは、バージョンに応じたファイル名
をサーバモジュールLX に通知し、正しく処理が行われ
る。
も、本発明のエージェント管理システムを用いれば同様
のメリットが得られる。前出の数値積分のライブラリモ
ジュールの例を再び取り上げる。積分を行うこのモジュ
ールLX を使うには、クライアント側から、当該モジュ
ール内で読み参照される補間テーブルファイルのファイ
ル名を、使用時に格子点のデータと共に与えるのだが、
それはバージョン毎に異なるために、従来技術ではバー
ジョンアップに対する保守は煩雑である。一方、本発明
のエージェントに依る場合には、クライアント側は格子
点の数値データとスクリプトを渡すだけでよい。図5の
ソフトウェア資源の情報テーブルには、プログラムと随
伴するデータに関する相互参照のリンクが在るので、エ
ージェントプロセスは、バージョンに応じたファイル名
をサーバモジュールLX に通知し、正しく処理が行われ
る。
【0056】(実施例2)次に、ネットワークで結合さ
れたWSクラスターから成る分散型計算機環境におい
て、(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 とする。
字の組{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はサーバでのプロセス流れを示している。
明によるエージェントを用いた超行列積和の並列実行の
流れを擬コードで示している。図14はクライアントで
のプロセス流れを、図15は下位エージェントでのプロ
セス流れを、図16は上位エージェントでのプロセス流
れを、図17はサーバでのプロセス流れを示している。
【0061】クライアントはまず、エージェント管理シ
ステムに並列処理の使用を宣言する。これにより、M個
のサーバプロセスに応じてM個のエージェントプロセス
が生成され、これらM個のエージェントプロセスに対し
て1つの上位エージェントもクライアントプロセスのあ
るWS上に生成される。
ステムに並列処理の使用を宣言する。これにより、M個
のサーバプロセスに応じてM個のエージェントプロセス
が生成され、これらM個のエージェントプロセスに対し
て1つの上位エージェントもクライアントプロセスのあ
るWS上に生成される。
【0062】次に、サーバプロセスで共通の立ち上げ用
の初期数値データと、LQ を記述したスクリプトをエー
ジェント側に渡す。すると、管理すべきサーバプロセス
がモジュールLQ に係ることが決まり、初期データが正
しく送られる。そして、LQサーバプロセスは、この受
信を持って{Bij}の配列領域をゼロ化し、積和処理の
実行に備える。そこで、4添字の組{p,q,r,s}
に関する並列タスクの制御リストをエージェント管理シ
ステムに渡すと、上位エージェントプロセス、並列エー
ジェントプロセスの介在による並列処理が開始される。
この、制御リストはタスクプール部にセットされる。こ
こで、リストが個別に添字の値を持つ必要はなく、ある
規則に従い、パックして多次元性を1次元に簡約、つま
り単純な長さで定義しておき、サーバプロセスでの実際
の処理開始時に復元すればよい。
の初期数値データと、LQ を記述したスクリプトをエー
ジェント側に渡す。すると、管理すべきサーバプロセス
がモジュールLQ に係ることが決まり、初期データが正
しく送られる。そして、LQサーバプロセスは、この受
信を持って{Bij}の配列領域をゼロ化し、積和処理の
実行に備える。そこで、4添字の組{p,q,r,s}
に関する並列タスクの制御リストをエージェント管理シ
ステムに渡すと、上位エージェントプロセス、並列エー
ジェントプロセスの介在による並列処理が開始される。
この、制御リストはタスクプール部にセットされる。こ
こで、リストが個別に添字の値を持つ必要はなく、ある
規則に従い、パックして多次元性を1次元に簡約、つま
り単純な長さで定義しておき、サーバプロセスでの実際
の処理開始時に復元すればよい。
【0063】次に、動的負荷分散を図るための、上位エ
ージェントプロセスにおけるロジックの一例について述
べる。注意すべきは、上位エージェントによってタスク
制御リストの全長さStot.が一度にサーバ数Mで分割さ
れるのではなく、周期幅を持って繰り返し分割されるこ
とである。図18に、分割情報を含む並列タスクのテー
ブル構造を示す。最初の分割周期の長さをSini.とす
る。Sini.は、初期値としてクライアントプロセス側か
ら、エージェント管理システム側にタスクリストを渡す
際に与える。さて、第1回目の各エージェントプロセス
/サーバプロセスに対する割当ては次のように行われ
る。
ージェントプロセスにおけるロジックの一例について述
べる。注意すべきは、上位エージェントによってタスク
制御リストの全長さStot.が一度にサーバ数Mで分割さ
れるのではなく、周期幅を持って繰り返し分割されるこ
とである。図18に、分割情報を含む並列タスクのテー
ブル構造を示す。最初の分割周期の長さをSini.とす
る。Sini.は、初期値としてクライアントプロセス側か
ら、エージェント管理システム側にタスクリストを渡す
際に与える。さて、第1回目の各エージェントプロセス
/サーバプロセスに対する割当ては次のように行われ
る。
【0064】エージェントプロセスは、サーバプロセス
を生成し終わると、上位エージェントに対してタスクの
割当てを要求する。上位エージェントは、一番最初に要
求が到着した時から初期待ち時間Qini.だけ待ち、その
間に要求を出して揃ったエージェントに対して、負荷に
応じたタスクブロックの割当てを行う。ここで、既に各
WSには負荷のバラツキがあり、これによりサーバプロ
セスの生成に要する時間もまちまちとなるので、揃うエ
ージェントプロセスの数N1 はMとは限らない。初期待
ち時間Qini.も、クライアント側から、最初の分割周期
の長さSini.と共に渡す。各WSでの負荷の違いの考慮
は、以下のように行われる。
を生成し終わると、上位エージェントに対してタスクの
割当てを要求する。上位エージェントは、一番最初に要
求が到着した時から初期待ち時間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群から成る分散環境の計算能力P
1 は、(6)式と表せる。
1 は、(6)式と表せる。
【0082】
【数6】
【0083】従って、第1回目で、エージェントαが得
るタスクブロックの割当て
るタスクブロックの割当て
【0084】
【外7】
【0085】は(7)式となる。
【0086】
【数7】
【0087】{p,q,r,s}の部分割当てタスクブ
ロックを得たエージェントプロセスは、それを自分の受
持ちのLQ サーバプロセスにメッセージ送信する。サー
バは、それに従い、対応する部分の{Cpqrs ij}と{D
pqrs}をセットし、{Bij}に積和寄与を加算する。こ
こで、2組添字の{i,j}に関しては可能な全てが尽
くされる。サーバは与えられたタスクが完了すると、そ
れを示すフラグをエージェントに返送する。これでエー
ジェントプロセスに制御が戻る。受信したフラグが正常
であるならば、エージェントプロセスは、それをエージ
ェント管理システムに通知する。これにより、図18の
テーブルに、割当てタスクブロックの正常終了と担当エ
ージェントのサインが記される。これが、あるエージェ
ントプロセスにおけるループの一単位である。
ロックを得たエージェントプロセスは、それを自分の受
持ちのLQ サーバプロセスにメッセージ送信する。サー
バは、それに従い、対応する部分の{Cpqrs ij}と{D
pqrs}をセットし、{Bij}に積和寄与を加算する。こ
こで、2組添字の{i,j}に関しては可能な全てが尽
くされる。サーバは与えられたタスクが完了すると、そ
れを示すフラグをエージェントに返送する。これでエー
ジェントプロセスに制御が戻る。受信したフラグが正常
であるならば、エージェントプロセスは、それをエージ
ェント管理システムに通知する。これにより、図18の
テーブルに、割当てタスクブロックの正常終了と担当エ
ージェントのサインが記される。これが、あるエージェ
ントプロセスにおけるループの一単位である。
【0088】次に第2回目のタスク割当てだが、第1回
目の処理中にも負荷は動的に変動しているので、各サー
バプロセスで処理に要した経過時間
目の処理中にも負荷は動的に変動しているので、各サー
バプロセスで処理に要した経過時間
【0089】
【外8】
【0090】にはバラツキがあるはずで、一番最初に第
2回目のタスクの割当て要求を出すタイミングもまちま
ちである。従って、待ち時間内に揃い、割当てをもらえ
るエージェントのN2 は、必ずしも前回のN1 と同じで
はない。第1回目での経過時間のバラツキの程度は、1
つの計量として、第2回目で揃ったN2 に対する平均ε
1 ((8)式に示す)から、(9)式で示される分散σ
1 を求めて判断することができる。
2回目のタスクの割当て要求を出すタイミングもまちま
ちである。従って、待ち時間内に揃い、割当てをもらえ
るエージェントのN2 は、必ずしも前回のN1 と同じで
はない。第1回目での経過時間のバラツキの程度は、1
つの計量として、第2回目で揃ったN2 に対する平均ε
1 ((8)式に示す)から、(9)式で示される分散σ
1 を求めて判断することができる。
【0091】
【数8】
【0092】待ち時間に間に合わなかったならば、その
エージェントプロセス、およびサーバプロセスは次の回
まで待機することになる。第3回目以降の割当ても同様
である。
エージェントプロセス、およびサーバプロセスは次の回
まで待機することになる。第3回目以降の割当ても同様
である。
【0093】次に、上位エージェントプロセスによる周
期幅と待ち時間の変更・最適化のロジックについてであ
る。まず、周期に関しては、1つの目安は経過時間の分
散の変化(σ(I+1) −σ1)である。これが、正ならば
分散は大きくなる方向であるから、周期を短くして各ノ
ードの経過時間を減らす。逆に負であれば、通信頻度を
より減らすように伸ばす。伸縮は、Sini.に適当なスケ
ール因子を逐次掛けて行う。待ち時間Qini.に関して
は、揃うエージェントの数の変化が目安になる。ここ
で、集合数の変化(N(I+1) −NI )が負ならば伸ばす
必要があるのは言うまでもない。もちろん、エージェン
トの総数MとNI の関係も参考にする。Qini.に対して
も同様に、変更・最適化のためのスケーリングを行う。
期幅と待ち時間の変更・最適化のロジックについてであ
る。まず、周期に関しては、1つの目安は経過時間の分
散の変化(σ(I+1) −σ1)である。これが、正ならば
分散は大きくなる方向であるから、周期を短くして各ノ
ードの経過時間を減らす。逆に負であれば、通信頻度を
より減らすように伸ばす。伸縮は、Sini.に適当なスケ
ール因子を逐次掛けて行う。待ち時間Qini.に関して
は、揃うエージェントの数の変化が目安になる。ここ
で、集合数の変化(N(I+1) −NI )が負ならば伸ばす
必要があるのは言うまでもない。もちろん、エージェン
トの総数MとNI の関係も参考にする。Qini.に対して
も同様に、変更・最適化のためのスケーリングを行う。
【0094】上記の一連のプロセス流れが、タスクブロ
ックの長さがゼロ、すなわちリストが尽くされるまで繰
り返される。ゼロの割り当てタスクは、そのLQ サーバ
で成すべき積和処理の完了を意味する。つまり、長さゼ
ロのタスクブロックをサーバプロセスが受け取ると、エ
ージェントプロセス側に結果の送信希望のフラグが返送
され、エージェント側は、飛び出し後、サーバから不完
全生成された{Bij}要素の受信を待つこととなる。こ
うして、各エージェントプロセスは個々の受持ちサーバ
プロセスから不完全生成{Bij}を受け取ることが出
来、続けて、これらをクライアントプロセス側に転送す
れば、エージェントの役目は終わる。後は、クライアン
トが、それらループを使って受信し、全受信完了後、式
(3)に従って次々に足し合わせれば、完全な{Bij}
を得て、エージェント管理の完了を告げる。
ックの長さがゼロ、すなわちリストが尽くされるまで繰
り返される。ゼロの割り当てタスクは、そのLQ サーバ
で成すべき積和処理の完了を意味する。つまり、長さゼ
ロのタスクブロックをサーバプロセスが受け取ると、エ
ージェントプロセス側に結果の送信希望のフラグが返送
され、エージェント側は、飛び出し後、サーバから不完
全生成された{Bij}要素の受信を待つこととなる。こ
うして、各エージェントプロセスは個々の受持ちサーバ
プロセスから不完全生成{Bij}を受け取ることが出
来、続けて、これらをクライアントプロセス側に転送す
れば、エージェントの役目は終わる。後は、クライアン
トが、それらループを使って受信し、全受信完了後、式
(3)に従って次々に足し合わせれば、完全な{Bij}
を得て、エージェント管理の完了を告げる。
【0095】エージェントを用いた式(2)の超行列積
和の並列サーバプロセス実行中に、あるサーバプロセス
を実行しているWSが障害により使用不能となっても、
本発明によれば、図18のタスクテーブルには担当した
エージェントのサインが記されているので、容易にリカ
バリの手続きを取り、確実に目的ジョブを行うことが出
来る。障害の発生は、そのWS上のエージェント管理シ
ステムからの通信が途絶えることで検出される。そし
て、リカバリには、障害WSに任されていたタスクを集
め、他の生きているエージェントプロセスで再実行を行
えばよい。タイミングとしては、障害発生が起きたすぐ
後の割り当て要求時、もしくは一通りタスクリストを終
えてから、いずれでも可能である。障害による台数の
(M−1)への減少は、むろんクライアント側にも通知
される。一方、障害を受けていたWSが途中で復旧し、
その上のエージェント管理システムが立ち上がれば、再
度サーバとして利用が可能となる。この場合も、障害そ
のものによって失われたタスクは適に再実行される。ま
た、実行中に、(M+1)台目のWSを新たに追加して
も、同様にエージェント管理システムが、新たなエージ
ェントプロセスを生成するので、そのWSを取り込んで
利用することが出来る。
和の並列サーバプロセス実行中に、あるサーバプロセス
を実行しているWSが障害により使用不能となっても、
本発明によれば、図18のタスクテーブルには担当した
エージェントのサインが記されているので、容易にリカ
バリの手続きを取り、確実に目的ジョブを行うことが出
来る。障害の発生は、そのWS上のエージェント管理シ
ステムからの通信が途絶えることで検出される。そし
て、リカバリには、障害WSに任されていたタスクを集
め、他の生きているエージェントプロセスで再実行を行
えばよい。タイミングとしては、障害発生が起きたすぐ
後の割り当て要求時、もしくは一通りタスクリストを終
えてから、いずれでも可能である。障害による台数の
(M−1)への減少は、むろんクライアント側にも通知
される。一方、障害を受けていたWSが途中で復旧し、
その上のエージェント管理システムが立ち上がれば、再
度サーバとして利用が可能となる。この場合も、障害そ
のものによって失われたタスクは適に再実行される。ま
た、実行中に、(M+1)台目のWSを新たに追加して
も、同様にエージェント管理システムが、新たなエージ
ェントプロセスを生成するので、そのWSを取り込んで
利用することが出来る。
【0096】これまで述べてきた例から、本発明によれ
ば、エージェント管理システムを有するため、上記のW
SクラスターにベクトルCPUのスーパーコンピュータ
をさらに結合した分散型環境でも同様に、式(2)の超
行列積和を、動的な負荷分散を行いつつ並列実行するこ
とが容易であることがわかる。そのためには、ベクトル
実行で部分的な積和処理を行うモジュールLR を用意
し、図5のソフトウェア資源テーブルにその情報を加
え、クライアントでのエージェント呼び出しのスクリプ
トを適に変更するだけでよい。
ば、エージェント管理システムを有するため、上記のW
SクラスターにベクトルCPUのスーパーコンピュータ
をさらに結合した分散型環境でも同様に、式(2)の超
行列積和を、動的な負荷分散を行いつつ並列実行するこ
とが容易であることがわかる。そのためには、ベクトル
実行で部分的な積和処理を行うモジュールLR を用意
し、図5のソフトウェア資源テーブルにその情報を加
え、クライアントでのエージェント呼び出しのスクリプ
トを適に変更するだけでよい。
【0097】
【発明の効果】以上示したように、本発明によればエー
ジェント制御を分散型計算機環境に導入することによ
り、環境内のハードウェア資源とソフトウェア資源を有
効かつ効率よく利用して、ユーザーの投入したアプリケ
ーションジョブを最適実行することが可能である。アプ
リケーションの開発者、維持管理者にとって、エージェ
ント制御の導入に伴う修正は少なくて済む。また、環境
内の資源の開発者、維持管理者に対しても良好な保守性
をもたらす。さらに、マルチベンダにより提供されるモ
ジュールの使用費用が、そのコール回数や総CPU時間
に応じて加算されるような運用形態に対しても対応が容
易である。
ジェント制御を分散型計算機環境に導入することによ
り、環境内のハードウェア資源とソフトウェア資源を有
効かつ効率よく利用して、ユーザーの投入したアプリケ
ーションジョブを最適実行することが可能である。アプ
リケーションの開発者、維持管理者にとって、エージェ
ント制御の導入に伴う修正は少なくて済む。また、環境
内の資源の開発者、維持管理者に対しても良好な保守性
をもたらす。さらに、マルチベンダにより提供されるモ
ジュールの使用費用が、そのコール回数や総CPU時間
に応じて加算されるような運用形態に対しても対応が容
易である。
【図1】本発明によるエージェントを用いたメッセージ
通信の関係図である。
通信の関係図である。
【図2】本発明による計算機におけるエージェント管理
システムの階層を表す概念図である。
システムの階層を表す概念図である。
【図3】本発明によるエージェント管理システムの構成
要素の模式図である。
要素の模式図である。
【図4】本発明による分散型計算環境内のハードウェア
資源に関する情報の内容を示す図である。
資源に関する情報の内容を示す図である。
【図5】本発明による分散型計算環境内のソフトウェア
資源に関する情報の内容を示す図である。
資源に関する情報の内容を示す図である。
【図6】本発明による、エージェントを用いた非並列化
ジョブの実行におけるプロセス流れを示す図である。
ジョブの実行におけるプロセス流れを示す図である。
【図7】本発明による、計算機数が2の場合のエージェ
ント使用による並列実行におけるプロセスの関係を示す
模式図である。
ント使用による並列実行におけるプロセスの関係を示す
模式図である。
【図8】従来のクライアント/サーバ方式により連立1
次方程式を求解する場合の、クライアントでのプロセス
流れを擬コードで表した図である。
次方程式を求解する場合の、クライアントでのプロセス
流れを擬コードで表した図である。
【図9】従来のクライアント/サーバ方式により連立1
次方程式を求解する場合の、サーバでのプロセス流れを
擬コードで表した図である。
次方程式を求解する場合の、サーバでのプロセス流れを
擬コードで表した図である。
【図10】本発明によりエージェントを用いて連立1次
方程式を求解する実施例の、クライアントでのプロセス
流れを擬コードで表した図である。
方程式を求解する実施例の、クライアントでのプロセス
流れを擬コードで表した図である。
【図11】本発明によりエージェントを用いて連立1次
方程式を求解する実施例の、エージェントでのプロセス
流れを擬コードで表した図である。
方程式を求解する実施例の、エージェントでのプロセス
流れを擬コードで表した図である。
【図12】本発明によりエージェントを用いて連立1次
方程式を求解する実施例の、サーバでのプロセス流れを
擬コードで表した図である。
方程式を求解する実施例の、サーバでのプロセス流れを
擬コードで表した図である。
【図13】本発明によるエージェントにおけるモジュー
ル候補の蓄積を例示した図である。
ル候補の蓄積を例示した図である。
【図14】本発明によりエージェントを用いて超行列の
積和処理を並列に行う実施例のクライアントでのプロセ
ス流れを擬コードで表した図である。
積和処理を並列に行う実施例のクライアントでのプロセ
ス流れを擬コードで表した図である。
【図15】本発明によりエージェントを用いて超行列の
積和処理を並列に行う実施例のエージェントでのプロセ
ス流れを擬コードで表した図である。
積和処理を並列に行う実施例のエージェントでのプロセ
ス流れを擬コードで表した図である。
【図16】本発明によりエージェントを用いて超行列の
積和処理を並列に行う実施例の上位エージェントでのプ
ロセス流れを擬コードで表した図である。
積和処理を並列に行う実施例の上位エージェントでのプ
ロセス流れを擬コードで表した図である。
【図17】本発明によりエージェントを用いて超行列の
積和処理を並列に行う実施例のサーバでのプロセス流れ
を擬コードで表した図である。
積和処理を並列に行う実施例のサーバでのプロセス流れ
を擬コードで表した図である。
【図18】本発明によるエージェント管理システムに設
定される並列タスクリストに関するテーブルの構成要素
の模式図である。
定される並列タスクリストに関するテーブルの構成要素
の模式図である。
3.1 メッセージ通信の制御部分 3.2 クライアントからのエージェントの使用宣言や
タスク依頼を受付ける部分 3.3 依頼されたタスクをプールする部分 3.4 エージェントプロセスとして活性化され得る部
分を持つライブラリ部分 3.5 エージェントプロセスを操作する部分 3.6 分散環境内の資源情報を取得・保持する部分 6.1 クライアントプロセス 6.2 エージェント管理システムにおけるエージェン
ト使用・タスク依頼の受付け部(プロセス) 6.3 エージェントプロセスの操作部(プロセス) 6.4 生成されたエージェントプロセス 6.5 依頼タスクのプール部(プロセス) 6.6 資源情報の管理部(プロセス) 6.7 サーバプロセス 6.10 6.1から6.2へのエージェント使用の宣
言(メッセージ) 6.11 6.2から6.3へのエージェントプロセス
6.4の生成要求 6.12 6.3から6.4へのエージェントプロセス
生成操作 6.13 6.1から6.2へのタスク(メッセージ) 6.14 6.2から6.5への依頼タスクのセット要
求 6.15 6.4から6.5への依頼タスクの取得要求 6.16 6.5から6.4への6.15に対する返答 6.17 6.4から6.6への資源情報の取得要求 6.18 6.6から6.4への6.17に対する返答 6.19 6.4から6.7のサーバプロセス生成要求
(メッセージ) 6.20 6.4から6.7への実行に必要な数値デー
タの転送(メッセージ) 6.21 6.7から6.4への実行結果の返送(メッ
セージ) 6.22 6.4から6.5への正常終了の通知 6.23 6.4からサーバプロセス6.7の消去要求
(メッセージ) 6.24 6.4から6.1への結果の転送(メッセー
ジ) 6.25 6.1から6.2へのエージェント使用停止
の宣言(メッセージ) 6.26 6.2から6.3へのエージェントプロセス
6.4の消去要求 6.27 6.3から6.4へのエージェントプロセス
消去操作 6.28 6.2から6.5への実行済タスクの消去要
求 7.1 計算機1上のクライアントプロセス 7.2 計算機1上のエージェント管理システム 7.3 計算機2上のエージェント管理システム 7.4 計算機1上のエージェントプロセス 7.5 計算機2上のエージェントプロセス 7.6 7.4と7.5エージェントプロセスに対する
計算機1上の上位エージェントプロセス 7.7 7.4により生成される計算機1上のサーバプ
ロセス 7.8 7.5により生成される計算機2上のサーバプ
ロセス
タスク依頼を受付ける部分 3.3 依頼されたタスクをプールする部分 3.4 エージェントプロセスとして活性化され得る部
分を持つライブラリ部分 3.5 エージェントプロセスを操作する部分 3.6 分散環境内の資源情報を取得・保持する部分 6.1 クライアントプロセス 6.2 エージェント管理システムにおけるエージェン
ト使用・タスク依頼の受付け部(プロセス) 6.3 エージェントプロセスの操作部(プロセス) 6.4 生成されたエージェントプロセス 6.5 依頼タスクのプール部(プロセス) 6.6 資源情報の管理部(プロセス) 6.7 サーバプロセス 6.10 6.1から6.2へのエージェント使用の宣
言(メッセージ) 6.11 6.2から6.3へのエージェントプロセス
6.4の生成要求 6.12 6.3から6.4へのエージェントプロセス
生成操作 6.13 6.1から6.2へのタスク(メッセージ) 6.14 6.2から6.5への依頼タスクのセット要
求 6.15 6.4から6.5への依頼タスクの取得要求 6.16 6.5から6.4への6.15に対する返答 6.17 6.4から6.6への資源情報の取得要求 6.18 6.6から6.4への6.17に対する返答 6.19 6.4から6.7のサーバプロセス生成要求
(メッセージ) 6.20 6.4から6.7への実行に必要な数値デー
タの転送(メッセージ) 6.21 6.7から6.4への実行結果の返送(メッ
セージ) 6.22 6.4から6.5への正常終了の通知 6.23 6.4からサーバプロセス6.7の消去要求
(メッセージ) 6.24 6.4から6.1への結果の転送(メッセー
ジ) 6.25 6.1から6.2へのエージェント使用停止
の宣言(メッセージ) 6.26 6.2から6.3へのエージェントプロセス
6.4の消去要求 6.27 6.3から6.4へのエージェントプロセス
消去操作 6.28 6.2から6.5への実行済タスクの消去要
求 7.1 計算機1上のクライアントプロセス 7.2 計算機1上のエージェント管理システム 7.3 計算機2上のエージェント管理システム 7.4 計算機1上のエージェントプロセス 7.5 計算機2上のエージェントプロセス 7.6 7.4と7.5エージェントプロセスに対する
計算機1上の上位エージェントプロセス 7.7 7.4により生成される計算機1上のサーバプ
ロセス 7.8 7.5により生成される計算機2上のサーバプ
ロセス
───────────────────────────────────────────────────── フロントページの続き (72)発明者 佐野 亨 東京都港区芝五丁目7番1号 日本電気株 式会社内 (72)発明者 半田 享 東京都港区海岸三丁目9番15号 株式会社 エヌイーシー情報システムズ内 (72)発明者 山本 章紀 東京都港区海岸三丁目9番15号 株式会社 エヌイーシー情報システムズ内 (72)発明者 萬 伸一 東京都港区芝五丁目7番1号 日本電気株 式会社内
Claims (2)
- 【請求項1】ネットワークで結合された均一もしくは不
均一に分散構成された計算機環境におけるプロセス処理
方法において、ユーザーの投入ジョブに係るアプリケー
ションプログラムのプロセス流れに対して、個々の前記
計算機に関する静的な性能と動的な負荷状況の変動など
ハードウェア資源に関する情報と、前記計算機環境内の
プログラムモジュールと随伴するデータなどソフトウェ
ア資源に関する情報とを把握する単数あるいは複数のエ
ージェントプロセスを生成し、生成された前記エージェ
ントプロセスがクライアントプロセスとサーバプロセス
間に介在し、前記ハードウェア資源に関する情報と前記
ソフトウェア資源に関する情報に基づいて、前記クライ
アントプロセスより指令された前記目的ジョブを前記サ
ーバプロセスに実行処理させることを特徴とする分散型
プロセス処理方法。 - 【請求項2】ネットワークで結合された均一もしくは不
均一に分散構成された計算機環境において使用され、ク
ライアントとサーバとエージェント管理システムより構
成される分散型プロセス処理装置であって、 前記エージェント管理システムは、前記クライアントよ
りユーザーの投入ジョブに係るタスクを受け付ける受付
部と、個々の前記計算機に関する静的な性能と動的な負
荷状況の変動などハードウェア資源に関する情報と、前
記計算機環境内のプログラムモジュールと随伴するデー
タなどソフトウェア資源に関する情報を保持する資源情
報管理部と、前記受付部からの命令に基づいてエージェ
ントプロセスを生成、消去するエージェントプロセス操
作部とから構成され、 前記エージェントプロセス操作部により生成されたエー
ジェントプロセスは、前記クライアントと前記サーバ間
に介在し、前記資源情報管理部より得た前記ハードウェ
ア資源に関する情報と前記ソフトウェア資源に関する情
報とに基づいて前記目的ジョブを前記サーバに実行処理
させることを特徴とする分散型プロセス処理装置。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP7164837A JPH0916534A (ja) | 1995-06-30 | 1995-06-30 | 分散型プロセス処理方法およびその装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP7164837A JPH0916534A (ja) | 1995-06-30 | 1995-06-30 | 分散型プロセス処理方法およびその装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
JPH0916534A true JPH0916534A (ja) | 1997-01-17 |
Family
ID=15800871
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP7164837A Pending JPH0916534A (ja) | 1995-06-30 | 1995-06-30 | 分散型プロセス処理方法およびその装置 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JPH0916534A (ja) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2007072567A1 (ja) * | 2005-12-22 | 2007-06-28 | Japan Agency For Marine-Earth Science And Technology | 並列処理支援装置 |
US7386751B2 (en) | 2002-01-11 | 2008-06-10 | National Cheng Kung University | Generic service management system |
US7623460B2 (en) | 2006-05-19 | 2009-11-24 | Nec Corporation | Cluster system, load distribution method, optimization client program, and arbitration server program |
US8601166B2 (en) | 2008-05-14 | 2013-12-03 | Nec Corporation | Information processing system and information processing method for generating distribution and synchronization rules in a client/server environment based on operation environment data |
JP2017102513A (ja) * | 2015-11-30 | 2017-06-08 | 京セラドキュメントソリューションズ株式会社 | 実行制御機器、実行制御プログラムおよびタスク実行システム |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH06309259A (ja) * | 1993-04-20 | 1994-11-04 | Hitachi Ltd | クライアント/サーバシステムにおける通信方法 |
-
1995
- 1995-06-30 JP JP7164837A patent/JPH0916534A/ja active Pending
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH06309259A (ja) * | 1993-04-20 | 1994-11-04 | Hitachi Ltd | クライアント/サーバシステムにおける通信方法 |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7386751B2 (en) | 2002-01-11 | 2008-06-10 | National Cheng Kung University | Generic service management system |
WO2007072567A1 (ja) * | 2005-12-22 | 2007-06-28 | Japan Agency For Marine-Earth Science And Technology | 並列処理支援装置 |
JP4846736B2 (ja) * | 2005-12-22 | 2011-12-28 | 独立行政法人海洋研究開発機構 | 並列処理支援装置 |
US7623460B2 (en) | 2006-05-19 | 2009-11-24 | Nec Corporation | Cluster system, load distribution method, optimization client program, and arbitration server program |
US8601166B2 (en) | 2008-05-14 | 2013-12-03 | Nec Corporation | Information processing system and information processing method for generating distribution and synchronization rules in a client/server environment based on operation environment data |
JP2017102513A (ja) * | 2015-11-30 | 2017-06-08 | 京セラドキュメントソリューションズ株式会社 | 実行制御機器、実行制御プログラムおよびタスク実行システム |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US12021679B1 (en) | Cluster computing | |
Bui et al. | Work queue+ python: A framework for scalable scientific ensemble applications | |
US20030005068A1 (en) | System and method for creating a virtual supercomputer using computers working collaboratively in parallel and uses for the same | |
CN108062254B (zh) | 作业处理方法、装置、存储介质及设备 | |
KR20050001321A (ko) | 분산 구축 환경의 소프트웨어 이미지 생성 | |
Magoules et al. | JACK: an asynchronous communication kernel library for iterative algorithms | |
Basney et al. | High Throughput Monte Carlo. | |
Hamdi et al. | Dynamic load balancing of data parallel applications on a distributed network | |
Chen et al. | FATCOP: A fault tolerant Condor-PVM mixed integer programming solver | |
JPH0916534A (ja) | 分散型プロセス処理方法およびその装置 | |
Cornebize et al. | Emulating high performance linpack on a commodity server at the scale of a supercomputer | |
Bendjoudi et al. | Fth-b&b: A fault-tolerant hierarchicalbranch and bound for large scaleunreliable environments | |
Kudva et al. | DCABB: A distributed control architecture for branch and bound calculations | |
Fagg et al. | HARNESS fault tolerant MPI design, usage and performance issues | |
Moreira et al. | A system for dynamic resource allocation and data distribution | |
Linderoth et al. | Metacomputing and the master-worker paradigm | |
Ranka et al. | Static and runtime scheduling of unstructured communication | |
Keane et al. | Distributed computing for DNA analysis | |
Hunold et al. | TGrid-Grid runtime support for hierarchically structured task-parallel programs | |
Vargas et al. | Hierarchical resource management and application control in grid environments | |
Metzner et al. | Parallelism in MuPAD 1.4 | |
Cap et al. | The Parform| A High Performance Platform | |
Macharia | CLD:-A novel approach to dynamic load balancing | |
Cline et al. | Linda-lan: A controlled parallel processing environment | |
Naik | Concurrent programming using Parallel Virtual Machine. |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 19980303 |