JPH09511858A - Ｏｓｉエージェントにおける要求の並列実行 - Google Patents

Abstract

(57)【要約】 本発明は、複数の共通管理情報プロトコル（ＣＭＩＰ）要求を同時に処理するため、主スレッドと各主スレッド内のサブスレッドとを提供することにより、開放型システム間相互接続（ＯＳＩ）接続におけるＣＭＩＰ要求の実行を編成する方法に関する。簡潔に述べると、入りＣＭＩＰ要求を実行するために主スレッドを順次開始し、主スレッドが、特定の管理対象オブジェクトが使用可能か、すなわちロックされていないかどうかを検査し、それをロックし、この管理対象オブジェクトにおけるＣＭＩＰ要求を処理するためにサブスレッドを開始する。これにより、主スレッドは別のサブスレッドを開始することができ、したがって複数のＣＭＩＰ要求の並列実行が可能になる。

Description

【発明の詳細な説明】 ＯＳＩエージェントにおける要求の並列実行 本発明は、開放型システム間相互接続（ＯＳＩ）環境における共通管理情報プ ロトコル（ＣＭＩＰ）要求の処理に関し、詳細には、複数の要求が同時に受け取 られたまたは保留中のときに、いわゆるＯＳＩエージェントにおいて前記ＣＭＩ Ｐ要求を実行することに関する。 背景 ＯＳＩ（開放型システム間相互接続）システム管理は、記憶装置、データベー ス、遠隔通信用交換機、通信リンクなどの資源に関わる情報をやりとりするため に、ＯＳＩ環境内及びＯＳＩプロトコル標準内でそれらの資源を監視、制御、調 整するための機構を提供する標準である。 ＯＳＩ管理標準では、資源の標準化されたアクセスを提供するアプリケーショ ン・エンティティを「エージェント」、管理機能を実行するアプリケーション・ エンティティを「マネージャ」と定義している。資源は、標準化された「管理対 象オブジェクト・クラス」を使って表され、クラスの各インスタント化体が「管 理対象オブジェクト・インスタンス」と呼ばれる。例えば、１つの管理対象オブ ジェクト・クラスは一般的に定義されたタイプのディスク装置であり、そのタイ プの個々のディスク装置かそれぞれこのクラスの１つのインスタンスとなる。こ のようなシステムにおける様々な動作は、「共通管理情報プロトコル」、略して ＣＭＩＰによって支配される。 マネージャ・アプリケーションは、ＣＭＩＳ（共通管理情報サービス）サービ ス要求をＣＭＩＰプロトコルを使ってネットワークを介してエージェントに送る ことにより、そのエージェントに含まれる管理対象オブジェクトに対して管理動 作を実行する。このようなサービス要求には、以下の動作が含まれる。ｃｒｅａ ｔｅ、ｄｅｌｅｔｅ、ｓｅｔ、ｇｅｔ、ａｃｔｉｏｎ、ｃａｎｃｅｌ−ｇｅｔ。 エージェントはやはりＣＭＩＰプロトコルを使って応答と事象をマネージャに戻 す。通信ネットワーク１の他にＯＳＩマネージャ２、エージェント・カーネル４ を伴うＯＳＩエージェント３、管理対象オブジェクト・インスタンス５−ａ、５ −ｂ、５−ｉ、５−ｎ、アクセスすべき資源６−ａ、６−ｂ及びＣＭＩＰプロト コル・メッセージの流れを含めて、このようなＯＳＩ環境の構成を一般的に図１ に示す。 ＯＳＩシステム管理標準ならびに関連するＣＭＩＰプロトコル及びＣＭＩＳサ ービスは、下記の刊行物に記載されている。 − ISO/IEC 10040，Information Technology-Open Systems Interconnection（ 情報技術−開放型システム間相互接続）‐Systems Management Overview（シス テム管理の概要）， 1991． − ISO/IEC 9595，Information Technology-Open Systems Interconnection（ 情報技術−開放型システム間相互接続）‐Common Management Information Serv ice Definition（共通管理情報サービスの定義），1991． − ISO/IEC 9596，Information Technology-Open Systems Interconnection（ 情報技術−開放型システム間相互接続）‐Common Management Information Prot ocol Definition（共通管理情報プロトコルの定義），1991． − ISO/IEC 10165-1，Information Technology-Open Systems Interconnection （情報技術−開放型システム間相互接続）‐Structure of Management Informat ion-Part 1：Management Information Model（管理情報の構造−第１部：管理情 報のモデル），1992． − ISO/IEC 10165-2，Information Technology-Open Systems Interconnection （情報技術−開放型システム間相互接続）‐Structure of Management Informat ion-Definition of Management Information（管理情報の構造−管理情報の定義 ），1992． − ISO/IEC 10165-4，Information Technology-Open Systees Interconnection （情報技術−開放型システム間相互接続）‐Guidelines for the Definition of Management Objects（管理対象オブジェクトの定義のための指針），1992． 多数のマネージャがあるエージェントに同時に接続することができ、各マネー ジャがそれぞれエージェントにＣＭＩＰ要求を非同期的に送ることができる。そ の結果、以下の問題が生じる。 ＯＳＩエージェントは複数のソースから複数のＣＭＩＰ要求を受け取ることが できる。これらの要求のいくつかは処理時間が長くかかる。その典型的な例は、 管理対象オブジェクト・インスタンスへのＣＭＩＰ「ｇｅｔ」要求であり、資源 アクセス（接続確立、応答待機、機能クローズ）を生じる可能性がある。したが って、ＣＭＩＰ要求の順次処理は長い遅延を生じ、したがって性能が低下する可 能性がある。 要求の処理及び資源のアクセスを編成する際に何らかの助けとなるのは「スレ ッド」を使用することである。スレッドとは、あるプロセス内部の単一の制御流 れであり、各スロットがそれ自体のスレッド識別子（ＩＤ）と制御流れをサポー トするために必要な資源を有する。この状況において「ｍｕｔｅｘ（相互排除） 」と呼ばれる機能が準備されており、これは複数のスレッドが共用データに対す るアクセスを直列化することができる。スレッドはｍｕｔｅｘをロックすること ができ、したがってその同じスレッドがそのｍｕｔｅｘをロック解除するまでそ の所有者とする。 スレッドの説明及び定義は下記の刊行物に出ている。 − Ａ．ビレル（Birrel）、「An Introduction to Programming with Threads 」、Systems Programming with Modu la-3、Ｇ．ネルソン（Nelson）編、Prentice Hall，1991，pp.88-118 − Draft Standard for Information Technology（情報技術規格案）−Portabl e Operating System Interface（ポータブル・オペレーティング・システム・イ ンタフェース）（POSIX）-Part 1: Systems Application Program Interface（ 第１部：システム・アプリケーション・プログラム・インタフェース）(API)，A mendment 2: Threads Extension（修正２：スレッド拡張）IEEE，October 1993 − 米国特許第5 247 676号「RPC Based Computer System Using Transparent C allback and Assoclated Method」この特許は、第１の発呼スレッドと第２の被 呼スレッドとヘルパ・スレッドを開示している。しかし、この特許はコンピュー タ・システム内の遠隔手順呼出し（ＲＰＣ）及びコールバックに関するもので、 ＯＳＩ環境における複数のＣＭＩＰ要求を処理する問題は扱っていない。 従来技術で提示されたスレッドとｍｕｔｅｘ機能を利用すると、アクセスの直 列化が可能になるが、それ自体は、複数のＣＭＩＰ要求を受け取り、資源にアク セスしなければならないとき、遅延が長くなり、性能が低下する可能性があると いう上記の問題を解決するものではない。 発明の目的 したがって、本発明の一目的は、不当な遅延なしにエージ ェントによって多数のＣＭＩＰ要求が処理できる、ＣＭＩＰ要求の実行方法を考 案することである。 もう一つの目的は、スレッドを使用し、かつオブジェクトをロックすると相互 排除のために長い遅延が生じるときに引き起こされる欠点を回避する、ＣＭＩＰ 要求の実行方法を提供することである。 上記のその他の目的は、請求の範囲で定義する方法によって達成される。 次に添付の図面を参照しながら本発明の実施形態について説明する。 図面のリスト 第１図は、少なくとも１つのマネージャと、少なくとも１つのエージェント及 び管理対象オブジェクトと、資源と、マネージャとエージェントの間のＣＭＩＰ プロトコル流れとを含むＯＳＩ環境を表す概略図である。 第２図は、スレッド及びサブスレッド内の動作を示す、本発明による方法の流 れ図である。 第３図は、本発明がその中で使用されるＯＳＩエージェントの様々な相互作用 を示す概略ブロック図である。 第４図は、本発明がその中で使用されるＯＳＩシステムの特定の実施例のブロ ック図である。 第５図は、複数のサブスレッドの相互作用、直列にエージェント内のスレッド が使用するサブスレッド・テーブルの実 施例を示す概略図である。 詳細な説明 発明の基礎 次に第２図及び第３図に関して本発明の詳細を説明する。第２図は、ＣＭＩＰ 要求を処理する際にＯＳＩエージェントで実施される動作を示す流れ図であり、 第３図はＣＭＩＰ要求を処理するためのＯＳＩエージェントの様々な部分の相互 作用を示す図である。 本発明の要点は次の通りである。各エージェントは「主スレッド」を有し、こ れは常に活動状態でメッセージ・ディスパッチ機能を実行する。主スレッドは、 ネットワークからメッセージを読み取り、その主スレッド用に提供された内部要 求待ち行列からメッセージ（があれば）を取り出す。エージェント内で実行され る各ＣＭＩＰ要求ごとに別々のサブスレッドが開始される。複数のサブスレッド からある管理対象オブジェクト・インスタンスへのアクセスを防止するため、各 管理対象オブジェクト・インスタンスはそれぞれロックを有する。オブジェクト ・インスタンスは、当該のＣＭＩＰ要求が実行されている限り、１つのサブスレ ッドについてロックされ、処理が完了するとロック解除される。以下及び請求の 範囲では、「オブジェクト」の語は、「管理対象オブジェクト・インスタンス」 を指すものとする。 エージェント内で下記の手順が実行される。（第２図参照） Ａ．主スレッド用基本手順 １．待ち行列中にメッセージがあるかどうか検査する。内部要求待ち行列中の 各メッセージごとに、下記の手順Ｂを実行する。待機中のメッセージがない場合 は、ステップ２に進む。 ２．ネットワークからのＣＭＩＰ要求を待つ。メッセージを受け取ると下記の 手順Ｂを実行し、次いでステップ１に戻る。 Ｂ．主スレッド用要求処理手順 １．要求がＣＭＩＰ Ｃｒｅａｔｅの場合、ステップ３に進む。そうでない場 合は、宛先オブジェクトがロックされているかどうか検査する。オブジェクトが ロックされていない場合は、ステップ２に進む。ロックされている場合は、メッ セージを内部要求待ち行列に入れ（手順Ａに戻）る。 注：最後のステップで、以前に内部要求待ち行列から取り出されたメッセージ が待ち行列に戻され、あるいはネットワークから新たに受け取ったメッセージが 新たにその待ち行列に入れられる。 ２．オブジェクトをロックする。 ３．サブスレッドを開始する。 ４．手順Ａに戻る。 Ｃ．サブスレッド用手順 １．サブスレッドと、それが働きかけているオブジェクトをスレッド・マネー ジャに登録する。 ２．要求を処理する。 ３．要求がＣＭＩＰ要求でない場合、主スレッドにオブジェクトをロックする 。 ４．サブスレッドを終了し、それをスレッド・マネージャから登録解除する。 第３図には、１つのＯＳＩエージェント用の様々な部分とそれらの相互関係を 示す。入力８上で受け取った通信ネットワークからのＣＭＩＰ要求、または要求 待ち行列９に一時的に格納されていたＣＭＩＰ要求を処理するために主スレッド ７が設けられている。ＣＭＩＰ要求は、管理対象オブジェクト１０−１．．．１ ０−ｉ．．．１０−ｎで処理され、これらのオブジェクトは資源（記憶装置、交 換機など）に接続されている。主スレッド７はオブジェクト・テーブル１１を維 持し、この中に管理対象オブジェクトが登録される。 第３図のブロック図を見るとわかるように、活動サブスレッドと、各スレッド でロックされたがまだロック解除（解放）されていないオブジェクトとを追跡す るために「スレッド・マネージャ」１２が各ＯＳＩエージェント中に設けられる 。このために「スレッド情報テーブル」１３が維持されるが、このテーブルは、 各活動スレッドごとに、そのスレッドがロックしたオブジェクトをリストする。 これによって、サブスレッドが既にそれ自体ロックされているオブジェクトをロ ックしようと試みるのを防止することもできる。（詳細については、後節「多重 スレッド処理」をも参照のこと）。 各オブジェクトのロック状況が、第３図に示した「オブジェクト・テーブル」 １１に維持される。このテーブルは、エージェント中に存在するすべてのオブジ ェクトのリストを含んでいる。テーブル中の各オブジェクト・エントリごとに、 そのオブジェクトのロック状況（ロック済み／ロック解除）が示される。あるオ ブジェクトが作成されたとき、オブジェクト・テーブルに新しいエントリが追加 される。同様に、あるオブジェクトがエントリから削除されたとき、オブジェク ト・テーブル中の対応するエントリも削除される。 要求がＣＭＩＰ Ｃｒｅａｔｅであるときに管理対象オブジェクトをロックし ない理由は、単にＣｒｅａｔｅ要求があるオブジェクトに向けられるものではな く、エージェントにオブジェクトを作成するように指令するものだからである。 オブジェクトの作成後、他のＣＭＩＰ動作をこのオブジェクトに送ることができ 、これらの動作に対してそのオブジェクトはロックされることになる。 ＯＳＩシステム管理の例 次に、本発明の応用例の一つの具体例を第４図に関して説明する。この実施例 の目的は、２台のディスク・ドライブを管理しなければならないというＯＳＩシ ステム管理の簡単なケースを例示することである。この実施例では、ディスク・ ドライブが「知能的」である、すなわちそれぞれがコマンドに応じてその内容の 整合性を検査する処理能力を備えていると仮定する。第４図にこのシステムの構 成を示す。この構成 は、ＯＳＩマネージャ１４と、ＯＳＩエージェント１５及び管理対象オブジェク ト１６、１７と、資源としてディスク・ドライブ１８、１９（ディスク−１とデ ィスク−２）を含んでいる。ＯＳＩの必要に応じて、ディスク・ドライブを表す またはモデル化するためのオブジェクト・クラスが定義される。ＯＳＩフォーマ リズム（ＧＤＭＯとＡＳＮ．１）を使って、オブジェクト・クラス（ディスク） を次のようにして定義することができる。（不要な細部は省略）。 disk MANAGED OBJECT CLASS DERIVED FROM top； ... ATTRIBUTES checkdisk GET-REPLACE ... ...,,, REGISTEREDAS｛1 3 18 0 2 4 5 1｝； checkdisk ATTRIBUTE WITH ATTRIBUTE SYNTAX INTEGER； BEHAVIOUR checkdiskBehaviour BEHAVIOUR DEFINED AS "１に設定されたときは、ディスク整合性検査をして、次いでその値を 走査されたバイト数に設定する" REGISTERED AS｛1 3 18 02 4 6 1｝． この場合、２つのディスク・ドライブ、ディスク−１とディスク−２はＯＳＩ エージェント内で「ディスク」管理対象オブジェクト・クラスの２つのインスタ ンスによって表される。「ディスク」インスタンスの属性「ｃｈｅｃｋｄｉｓｋ 」が１の値に設定されたとき、整合性検査動作を開始させるコマンドが実際のデ ィスク・ドライブに送られる。このコマンドは検査が済むと完了し、走査された バイト数を返す。言い換えれば、その属性に対するＯＳＩ設定動作は、整合性検 査の完了後に始めて完了し、走査バイト数を「設定」値として返す。 この例では、ＯＳＩマネージャ１４は単一の「スコープ済み」ＣＭＩＰ Ｓｅ ｔ要求を、スコープ内の「ディスク」管理対象オブジェクト・クラスの各インス タンスにおける「ｃｈｅｃｋｄｉｓｋ」属性の値を１に設定せよとの命令と共に エージェント１５に送る。エージェントは、スコープ内に含まれるインスタンス のセット（この例では２個のインスタンスがある）を決定し、選択された各イン スタンス１６、１７について、設定要求を発行し、各要求を新しいサブスレッド 上で開始する。（開始前に、エージェントの主スレッドが、そのスレッドがロッ クされているかそれともロック解除されているかを検査する。）この手法により 、両方の要求を並列に処理することが可能になる。すなわち、コマンドをディス ク−１ １８に送ってもエージェントはブロックされず、したがってディスク− ２ １９への要求も送ることができる。同時に、ディスク−１とディスク−２が それぞれの整合性検査を受けている間に、エージェントが他の照会に応答するた めに使用できる。この動作が完了するまで、ディスク−１とディスク−２を表す 管理対象オブジェクト・インスタンスはロックされており、これらのインスタン スに対する新しいＣＭＩＰ動作は開始できない。 ディスク−１とディスク−２がそれぞれその整合性検査を完了すると、そのセ ットに対する応答が（ｃｈｅｃｋｄｉｓｋ属性の新しい値を含めて）元のスコー プ済み要求に対する応答として、エージェント１５を介して、マネージャ１４に 戻される。この場合、ＳＭＩＰ設定要求により、ＯＳＩの要求通り３つの応答が ＯＳＩマネージャに戻される。リンクされた２つの応答（それぞれが各ディスク ・インスタンス中の設定属性の値を含む）と、応答の終りを示す空セット応答で ある。 多重スレッド処理の例 第５図に、複数のサブスレッドが動作しており、１つのサブスレッドがその実 行中に別のオブジェクトにアクセスまたはそれを使用しなければならないという 例を示す。第５図は、この例で使用されるＯＳＩエージェントの構成図である、 以前に作成された３つの管理対象オブジェクト・インスタンス Ｉ１（２０）、Ｉ２（２１）、Ｉ３（２２）を含んでいる。１つまたは複数のＯ ＳＩマネージャからの要求がエージェントの入力２３に到着し、到着した順に順 次主スレッド２４に引き渡される。これらのメッセージを主スレッドが一時に１ つずつ読む。 各インスタンスのロック／ロック解除装置はオブジェクト・テーブル２５に保 管される。このテーブルは、エージェント内で活動状態のどのスレッドからもア クセス可能である。ロックされた管理対象オブジェクト・インスタンスは、それ をロックしたスレッドのみがロック解除できることに留意されたい。 第５図において、インスタンスＩ１の実施形態からのコード・セグメント２６ が示されている。このセグメントは、Ｉ１に対して行われたある要求の処理中に 実行されるものと仮定する。このコード例は、 − インスタンスＩ２にアクセスする（アクセスのためにそれをロックしようと 試みる）。 − 必要とされる操作を実行する。 − 完了するとインスタンスＩ２を解放（ロック解除）する。 今説明している特定の例では、２つの要求をエージェントが順に受け取る。最 初の要求ＯＰ１はインスタンスＩ１宛であり、第２の要求ＯＰ２はＩ２宛である 。下記のステップが実行される。 − 主スレッドがＯＰ１を受け取る。 − Ｉ１がロックされているかどうか検査する。ロックされていない。 − Ｉ１をロックする。ＯＰ１を処理するためサブスレッド２７を開始する。（ サブスレッドＡ） − 主スレッド２４がＯＰ２を受け取る。 − Ｉ２がロックされているかどうか検査する。ロックされていない。 − Ｉ２をロックする。ＯＰ２を処理するためサブスレッド２８を開始する。（ サブスレッドＢ） − サブスレッドＡが第５図に示したコード・セグメントに入る。Ｉ２にアクセ ス（ロック）しようと試みるが、対Ｉ２は既にロックされている。サブスレッド Ａは（一般的に）ブロックされる。 − サブスレッドＢがＯＰ２の処理を完了する。主スレッド２４に、Ｉ２を解放 するよう依頼して終了する。 − 主スレッド２４がＩ２をロック解除する。 − このときサブスレッドＡは次に進むことができる（基礎システムがサブスレ ッドＡをブロック解除する。Ｉ２はこのときサブスレッドＡのためにロックされ ている）。 − コード・セグメントの終わりに。サブスレッドＡがＩ２を解放（ロック解除 ）する。 − サブスレッドＡがＯＰ１の処理を完了する。主スレッド２４にＩ１を解放す るよう依頼し、終了する。 − 主スレッド２４がＩ１をロック解除する。 この例では、異なる管理対象オブジェクト・インスタンスに作用する場合、複 数の要求が別々のサブスレッドによって同時に処理できることが明らかになる。 しかし、このロックにより、任意の管理対象オブジェクト・インスタンス上で複 数のサブスレッドが動作することは妨げられる。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 パーカー、デヴィッド、ウイリアム イギリス国サーレイ、サルフォード、セン ト ジョージズ・ロード “リンドセル" （番地なし)

Claims (1)

1. 【特許請求の範囲】 １．少なくとも１つのＯＳＩマネージャと、 前記いずれかのＯＳＩマネージヤから発行されるＣＭＩＰ（共通管理情報プロト コル）要求を実行する、管理対象オブジェクトと、 それぞれ複数の管理対象オブジェクトへのアクセスを提供するＯＳＩエージェ ントと を含むＯＳＩ（開放型システム間相互接続）システムにおいて、 ＣＭＩＰ要求の実行を編成する方法であって、 ＣＭＩＰ要求の実行を順次開始するため、各ＯＳＩエージェントに主スレッド を提供するステップと、 ＯＳＩエージェントが受け取ったＣＭＩＰ要求について、前記ＣＭＩＰ要求に よってアドレスされる管理対象オブジェクトがロックされているかどうか前記主 スレッドによって検査し、その管理対象オブジェクトがロックされていない場合 は、 前記管理対象オブジェクトをロックするステップと、 前記ＣＭＩＰ要求を処理するためにサブスレッドを開始するステップとを含み 、 前記サブスレッド開始ステップが、 前記サブスレッドと前記管理対象オブジェクトを登録するステップと、 前記ＣＭＩＰ要求を処理するステップと、 前記ＣＭＩＰ要求の処理が完了したとき、前記オブジェクトをロック解除する ステップとを含み、 複数のＣＭＩＰ要求が同時サブスレッドによって並列に実行できることを特徴 とする方法。 ２．前記主スレッドによって開始されたサブスレッドを管理するために、各ＯＳ Ｉエージェント内にスレッド・マネージャを提供するステップを含み、 前記スレッド・マネージャが、各活動サブスレッド及びそのスレッドのために ロックされている任意の管理対象オブジェクトを登録するテーブルを維持する ことを特徴とする、請求項１に記載の方法。 ３．各ＯＳＩエージェント内に主スレッドのための要求待ち行列を設けるステッ プと、 それぞれのＯＳＩエージェントが受け取った任意のＣＭＩＰ要求が直ちに処理 できないとき、その要求を前記要求待ち行列に格納するステップと を含むことを特徴とする、請求項１に記載の方法。 ４．主スレッドがＣＭＩＰ要求を処理するとき、前記ＣＭＩＰ要求によってアド レスされる管理対象オブジェクトがロックされていることを検出した場合に、当 該ＣＭＩＰ要求を前記要求待ち行列中に戻すステップをさらに含むことを特徴と する、請求項３に記載の方法。 ５．前記ＣＭＩＰ要求がＧｅｔコマンド、Ｓｅｔコマンド、 Ｃｒｅａｔｅコマンド、Ｄｅｌｅｔｅコマンド、Ａｃｔｉｏｎコマンド、Ｃａｎ ｃｅｌ−Ｇｅｔコマンドを含み、 ＣＭＩＰ要求がＣｒｅａｔｅコマンド型のものである場合、Ｃｒｅａｔｅ要求 を実行するため、主スレッドが、中間の検査ステップとロック・ステップなしで 、サブスレッドを直ちに開始することを特徴とする、請求項１に記載の方法。 ６．最初にサブスレッド自体によってアドレスされそれ自体のためにロックされ た管理対象オブジェクト以外の管理対象オブジェクトにサブスレッドがアクセス しなければならないとき、 前記他の管理対象オブジェクトがロックされているかどうか当該サブスレッド によって検査し、それがまだロックされていない場合、 前記他の管理対象オブジェクトを当該サブスレッドによってロックするステッ プと、 前記他の管理対象オブジェクト内で必要な操作を実行するステップと、 前記他の管理対象オブジェクトを当該サブスレッドによってロック解除するス テップと を含む、請求項１に記載の方法。