JP3870174B2 - 遠隔的にアクセス可能な資源を管理するための方法 - Google Patents

Description

本発明は、多重ノード分散データ処理システム（以下「分散システム」とも称する）に係る。より詳細には、本発明は、遠隔ノード上に複数の多様な資源が存在することに起因して、その状態が、変化するか、未知であるか、またはよく定義されていないという状況を導くことがある場合に、当該資源を管理するための機構に係る。さらに詳細には、本発明は、指定された資源の状態が分散システムにわたって整合性のある態様で提供されるように、プロキシ資源マネージャおよびプロキシ資源エージェントを使用することにより、当該資源に関連する資源生成番号、タイムスタンプまたは他の順序付け可能な標識の維持および報告を協働的に調整するための方法に係る。
【０００２】
【従来の技術】
分散システムでは、多くの物理または論理エンティティは、ノードの全体にわたって配置されている。これらのエンティティが資源である場合、当該資源の使用は、他のノードによって、または他のノードから求められることがある。しかし、分散システムには、異なるノード上に存在している広範囲の種々の資源に関して、かなり不均質な構造を呈するという性質がある。システムの構成および使用における最大限の柔軟性を提供するために、しばしば遠隔ノードに対してアクセスがなされる。これらの遠隔ノードは、そこに存在する資源に対する所望のレベルのサポートを含んでもよいし、含まなくてもよい。それにもかかわらず、これらの資源の状態は、ノード上で実行しているプログラムのための重要な情報を含んでおり、これらのノードは、事実上、より拡張レベルの資源管理のための所望のインフラストラクチャのサポートを含んでいる。
【０００３】
本明細書では、これらの遠隔エンティティは、「資源」と呼ばれる。本明細書では、この「資源」という用語は、広範囲のソフトウェアおよびハードウェア・エンティティを参照するように、非常に広い意味で使用される。資源の例には、「ノード１４上のイーサネット（登録商標）デバイス eth0」、「顧客」と呼ばれるデータベース表、「インターネットプロトコル（ＩＰ）アドレス 9.117.7.21」などがある。各資源は、この資源の特性を定義する、少なくとも１つの属性を有している。さらに、属性の幾つかは、資源状態を通して反映されている。１例として、イーサネット・デバイスは、「name」（たとえば、eth0）、「OpState」（たとえば、Up、Down、Failed、Idle、Busy、Waiting、Off line ）、その「address」（たとえば、9.117.7.21）などの属性を含んでいる。したがって、「name」、「OpState」および「address」は、資源属性と呼ばれる。資源属性の多くは、動的である。すなわち、これらの資源属性は、分散システム内の他のノードにはしばしば知られていない種々の理由で、資源状態の変化が頻繁に発生するという事実を反映している。たとえば、前述のイーサネット・デバイスの場合、「Opstate」は、動的属性として類別される。
【０００４】
多数のこれらの遠隔資源が、分散システムの幾つかの他の構成要素（たとえば、システム管理ツールまたはエンド・ユーザ・アプリケーション）にそのサービスを提供することをしばしば必要とするので、これらの遠隔資源を監視および制御する必要がある。本明細書では、この機能を実施するシステムは、一般に、資源管理インフラストラクチャ（ＲＭＩ）と呼ばれる。動作中、ＲＭＩは、前述の資源が（ＲＭＩを実行中の）同じノード内に含まれているか、または当該ノードに制約されているものと「仮定」する。しかし、ソフトウェア、ハードウェアまたはアーキテクチャ上の制限があるので、ＲＭＩの障害発生時に、この資源は、前述の同じノード上で使用可能であると仮定される。このことは、幾つかの分散システムが異なるタイプのノードを有し、これらのノードが前述の資源およびＲＭＩを含んでいても、含んでいなくても、該当することになる。
【０００５】
本発明は、「プロキシ資源マネージャ」（ＰｘＲＭ）および「プロキシ資源エージェント」（ＰｘＲＡ）の概念を通して、遠隔ノード上に存在する遠隔的にアクセス可能な資源を、監視および制御するための機構を提案する。プロキシ資源マネージャは、（資源管理サポートの適切なレベルを有する）ＲＭＩを実行中のローカル・ノード上に位置し、遠隔ノード上に提供されるプロキシ資源エージェントと通信する。
【０００６】
前述の「プロキシ資源マネージャ／プロキシ資源エージェント」機構は、遠隔資源の制御および監視をサポートするが、この機構は、幾つかの制約を有する。すなわち、この機構は、それ自体によって、前述の動的属性（たとえば、資源の「up/down」状態など）の幾つかに関する、整合したレベルの情報を常に提供することはできない。たとえば、この欠陥がノード上で発生することがあるのは、当該ノード上のプロキシ資源マネージャが、ノード障害のために再始動される場合である。指示されたインフラストラクチャは、この資源マネージャが再始動した場合でさえ、資源の属性を、「障害あり（failed）」、「未知（unknown）」のいずれかとして報告することがある。というのは、この再始動したプロキシ資源マネージャは、以前の資源状態を「知る」ことはないばかりか、プロキシ資源マネージャの障害の間に、この資源が「up」または「down」のいずれかであったかも「知る」ことはないからである。さらに、指示されたインフラストラクチャの下で動作しているプロキシ資源マネージャは、このプロキシ資源マネージャおよびプロキシ資源エージェントが切断され且つその後に再接続される場合は、正しい属性値を提供できないことがある。したがって、本発明は、プロキシ資源マネージャの障害時または再始動時にさえ、永続的で且つ整合性のある、属性および状態情報を提供するための、より安全でより信頼できる方法を提供する。この目標は、プロキシ資源エージェント内で、「資源生成番号」を使用することにより、少なくとも部分的に達成することができる。このことは、以下の詳細な説明において、より完全に説明されている。
【０００７】
本発明は、以下に例示した多数の利点を提供する。
（１）遠隔ノード上に位置する資源は、より信頼できる形で監視および制御されること。
（２）使用されている方法は、インフラストラクチャ・コードの再書き込み無しに、既存のＲＭＩを依然として使用できること。
（３）本発明は、ノード障害が存在するか、プロキシ資源マネージャが１回以上再始動されるか、またはプロキシ資源マネージャとプロキシ資源エージェントとの間の接続に障害がある場合でさえ、資源属性を整合性のある態様で監視するための手段を提供すること。また、本発明の方法は、（ＰｘＲＡを実行する）遠隔ノードに所要の作業を委託することによって、クラスタ・システム内の非常に多くの資源を扱うための手段を提供する。
【０００８】
【発明が解決しようとする課題】
従って、本発明の目的は、分散データ処理システムにおいて、遠隔ノード上の資源を管理する方法を提供することである。
【０００９】
本発明の他の目的は、多重ノードの分散データ処理システムを通して、資源状態の整合性のある標識を提供することである。
【００１０】
本発明の他の目的は、遠隔ノード上に、複雑な資源管理インフラストラクチャおよびそのためのコードを提供するという必要性を、回避することである。
【００１１】
本発明の他の目的は、分散データ処理システム内の計算資源およびその他の資源の信頼性と使用可能性を高めることである。
【００１２】
本発明の他の目的は、分散データ処理システム内のノード障害および通信障害からの一層良好な回復を提供することである。
【００１３】
本発明の他の目的は、分散データ処理システム内の遠隔ノード上に位置する資源の監視および制御を改善することである。
【００１４】
本発明の他の目的は、遠隔資源を制御するために、プロキシ資源マネージャ／プロキシ資源エージェント機構の使用を促進すること、具体的には、分散システムの全体にわたって資源特性の整合性を保証するために、資源生成番号（または同様の標識）を使用することである。
【００１５】
本発明の他の目的は、多様な資源を、できるだけ多くの時間に、システムの全体にわたって、できるだけ広範囲に利用できるようにする、分散データ処理システムにおいて使用するための制御機能および監視機能を提供することである。
【００１６】
本発明の前記目的は、本発明の様々な実施形態によって達成されるが、このことは、前記目的のいずれかまたは全てが、本発明の最も一般的な実施形態またはその特定の実施形態において、本質的特徴として、個別にまたは集合的に存在することを暗示するものではない。
【００１７】
【課題を解決するための手段】
本発明の好ましい実施形態によれば、多重ノード分散データ処理システムにおいて、遠隔的にアクセス可能な資源を管理するための方法が提供される。分散データ処理システムの第１のノード上で、プロキシ資源マネージャを実行する。第１のノードは、永続的記憶装置に結合され、この永続的記憶装置上には、順次資源生成ＩＤ（資源生成番号）を保持する表が維持され、この順次資源生成ＩＤは遠隔的にアクセス可能なノード上にある資源と関連付けられ、その遠隔ノードは、資源管理インフラストラクチャを含んでいても、含んでいなくてもよい。プロキシ資源マネージャは、遠隔ノード上で実行中のプロキシ資源エージェントと通信する。このプロキシ資源エージェントは、その内部に、遠隔ノード上にある資源に関係する属性情報または状態情報をさらに含む、前述の表のローカル・バージョンを維持している。また、この後者の表は、資源のための状態標識とともに、資源に関連付けられた、順次資源生成ＩＤのローカルに生成されたバージョンも含んでいる。永続的記憶装置内に記憶された順次資源生成ＩＤは、第１のノードが（たとえばノード障害後に）再始動したときに、増分される。これに対し、遠隔的に記憶された順次資源生成ＩＤのローカル・バージョンは、資源状態が変化するときに、増分される。この資源のための、永続的記憶装置内に記憶された順次資源生成ＩＤとそのローカル・バージョンは、分散システム中のノード間の整合性を保証するために、所望時に、比較される。
【００１８】
本発明の主題は、特許請求の範囲に明示されている。しかし、本発明の構成、実施方法、更なる目的および利点は、添付の図面に関係する以下の詳細な説明を参照することにより最もよく理解されよう。
【００１９】
【発明の実施の形態】
図１は、本発明の構造および動作を示す。具体的には、ノード１００は、資源管理インフラストラクチャ（ＲＭＩ）１９０と呼ばれる、既存レベルを含んでいるのがわかる。ノード１００上には、ＲＭＩ１９０と通信する、プロキシ資源マネージャ（ＰｘＲＭ）１５０も含まれる。プロキシ資源マネージャ１５０は、表１６５を作成するとともに、この表１６５を（ノード１００に直接的に結合されているか、または他のノードを介してノード１００に間接的に結合されている）永続的記憶装置１６０上に維持する。表１６５は、資源生成番号（ＲＧＮ１、ＲＧＮ２・・・）と、複数の遠隔資源（Ｒｅｓ１、Ｒｅｓ２、・・・）との間の関連を提供する。これらの遠隔資源は、資源＃１（Ｒｅｓ１、参照番号２０１）、資源＃２（Ｒｅｓ２、参照番号２０２）、・・・、資源＃Ｍ（ＲｅｓＭ、参照番号２０９）として、遠隔ノード２００上に存在する。遠隔ノード２００は、ノード１００上に提供されているＲＭＩ１９０のような資源管理機能を、含んでもよいし、含まなくてもよい。しかし、本発明の利点は、この機能が、ノード２００などの遠隔ノードで必要ではないことである。図１は、図を見やすくし、理解しやすくする目的で、ローカル・ノード１００および１つの遠隔ノード２００のみを示すことに、留意されたい。実際には、通常は複数の遠隔ノードが存在し、これらの遠隔ノードは、所与の時間に、分散システムを形成するノードの組に接続されたり、または当該ノードの組から切り離すことができる。同様に、複数のローカル・ノードがあってもよい。資源の使用可能性および状態に関係する、ローカル・ノードと遠隔ノードとの間の通信は、プロキシ資源マネージャ１５０と遠隔ノード２００上に常駐するプロキシ資源エージェント（ＰｘＲＡ）２５０との間で行われる。プロキシ資源エージェント２５０は、複数の資源を管理および制御する。これらの資源の性質は、その範囲がポートからファイル、デバイスにまで及んでいるという点で、非常に異なっているのが普通である。プロキシ資源エージェント２５０は、表２６５を作成および維持する。遠隔ノード２００上の複数の資源Ｒｅｓ１（参照番号２０１）〜ＲｅｓＭ（参照番号２０９）の各々ごとに、プロキシ資源エージェント２５０は、表２６５のエントリを提供する。各資源エントリごとに、資源生成番号（ＲＧＮ１、ＲＧＮ２、・・・、ＲＧＮｍ）、または他の標識も提供される。この標識のためのより詳細な説明は、以下に記述する。さらに、表２６５内には、リストされている各資源ごとに、属性値または状態値も提供される。一方、表１６５は、資源生成番号（ＲＧＮ）と資源との間の関連のみしか保持していない。プロキシ資源エージェント２５０は、表２６５が適時に更新されることを保証するために、遠隔資源と対話する。
【００２０】
本発明の好ましい実施形態では、プロキシ資源マネージャ１５０は、資源管理のために、既存のソフトウェア・インフラストラクチャと対話するように設計されている。本発明の好ましい実施形態は、（前身はＲＳ／６０００シリーズと呼ばれていた）ＩＢＭ pSeries データ処理システム上で、実現されている。これらのシステムは、ＲＭＣ（Resource Management and Control)サブシステムを含む、ＲＳＣＴ（Reliable Scalable Cluster Technology）を含んでいる。ＲＳＣＴ／ＲＭＣインフラストラクチャは、１つのＲＭＣサブシステムおよび１つ以上のノード上に位置する複数の資源マネージャから成る。ＲＭＣサブシステムは、システムまたはクラスタ内の諸資源を管理および操作するためのフレームワークを提供する。このフレームワークは、クラスタの任意のノード上のプロセスが、当該クラスタ内の全ての場所に位置する、１つ以上の資源に対して動作を実行することを可能にする。
【００２１】
クライアント・プログラムは、実行されるべき動作を指定するとともに、ＲＭＣＡＰＩと呼ばれるプログラミング・インタフェースを介して適用されなければならない資源を指定する。これは、前述の pSeries データ処理システム上に、既に存在している構成要素である。次いで、ＲＭＣサブシステムは、操作されるべき資源を含んでいる１つ以上のノードを決定し、要求された動作をこれらのノードへ伝送し、これらの資源に対して要求された動作を実行するために、これらのノード上の適切なコードを呼び出す。要求された動作を実行するために呼び出されるコードは、資源マネージャと呼ばれるプロセス内に含まれる。
【００２２】
本明細書では、資源マネージャとは、資源タイプのアブストラクションを１つ以上の特定タイプの資源用のコールおよびコマンドにマップする、プロセスを意味する。資源マネージャは、その資源が存在するクラスタの全てのノード上で実行することができる。種々のノード上で実行中の資源管理プロセスのインスタンスは、前述のコールおよびコマンドのためのマッピングおよび翻訳を提供するために、協調して動作する。資源管理インフラストラクチャを含んでいないノード上に位置する遠隔資源を監視および制御するために、本発明は、（ＲＭＩサポートを有する）ＲＭＩノード１００上に位置するプロキシ資源マネージャ（ＰｘＲＭ）１５０を使用する。そのピア・エージェントであるプロキシ資源エージェント（ＰｘＲＡ）２５０は、遠隔ノード２００上に位置する。プロキシ資源マネージャ１５０は、資源マネージャであって、ＲＭＣサブシステムおよびプロキシ資源エージェント２５０の両方に接続される。プロキシ資源マネージャ１５０によって監視されるのは、プロキシ資源エージェント２５０から提供される資源表記である。プロキシ資源エージェント２５０は、幾つかの形式を取ることができる。たとえば、プロキシ資源エージェント２５０は、中間プロセスでもよく、サービス・ルーチンでもよい。その機能は、資源２０１〜２０９を追跡し、変化をプロキシ資源マネージャ１５０に報告することである。
【００２３】
資源２０１〜２０９のための永続的で且つ整合性のある属性値を提供するために、プロキシ資源マネージャ１５０は、それ自体が再始動した後でさえ、プロキシ資源エージェント２５０の状態を追跡する。このような活動を処理するために、資源生成番号（ＲＧＮ）と呼ばれる標識が導入される。遠隔ノード２００上の各資源は、資源生成番号を有する。この資源生成番号は、適当な時点に変更され（以下を参照）、プロキシ資源マネージャ１５０が資源属性の現在の状態を「知る」ことができるように、プロキシ資源マネージャ１５０およびプロキシ資源エージェント２５０の両方によって追跡される。
【００２４】
資源生成番号は、資源ごとに、時間的に一意のものである。換言すると、２つの資源生成番号は、それらが異なる時点に生成された場合は、互いに異なっている。この特性は、資源生成番号が変化したか否かを決定する際に、状態の曖昧さがないことを保証する。したがって、資源生成番号は、タイムスタンプのようにできるだけ簡単なものであることが好ましい。しかし、この資源生成番号は、一般に、そのために定義された順序関係を有することのできる、任意の標識を含んでもよいことに留意されたい。整数およびタイムスタンプ（日付およびタイムスタンプを含んでいる）は、このような標識のうち最も簡単で且 つ容易に実現できるものであることは明らかである。したがって、本明細書における「資源生成番号」という標識は、１つ以上の数表現の形式に制限されるように解釈すべきではないことに留意されたい。さらに、本明細書で資源生成番号が増分するように示してある場合、その増分量は必ずしも正の数である必要はない。すなわち、資源生成番号の順序付けまたは更新方向は、任意の特定方向に制限されない。順序および比較可能という性質は、資源生成番号にとって望ましい特性である。タイムスタンプは、好ましい実施形態において、単に使用されているに過ぎない。
【００２５】
以下の記述は、所望のケースにおいて、本発明がどのように動作するかを示したものである。図１は、本発明の種々の構成要素間の関係および対話を示す、概略図である。以下の記述は、種々の動作状況および条件の下で、これらの構成要素の動作を説明する。
【００２６】
プロキシ資源エージェントの開始（遠隔ノード）
各資源に対する資源生成番号は、資源がアクティブとなるときは常に、各資源ごとに生成される。可能であれば、各資源は、遠隔ノード２００上に、それ自体の資源生成番号を維持するための責任を負うことが好ましい。さらに、（プロキシ資源エージェント２５０を含む）遠隔ノード２００がブートするときには、新しい資源生成番号が生成される。どちらの場合でも、新しい資源生成番号が、遠隔ノード２００上の全ての資源に対して割り当てられる。この資源生成番号は、プロキシ資源エージェント２５０の動作によって、他のノードへ提供される。このプロセスは、プロキシ資源マネージャ１５０が、遠隔ノード２００の障害および遠隔ノード２００における障害を検出できることを保証する。新しい資源生成番号が生成されるときは、プロキシ資源エージェント２５０は、表２６５内のエントリを維持することによって、この事実を追跡する。このため、プロキシ資源エージェント２５０は、資源を監視することが可能であり、それにより、プロキシ資源マネージャ１５０からプロキシ資源エージェント２５０に送られた、資源に関係する要求にサービスすることが可能になる。
【００２７】
遠隔ノードにおける資源ダウン
もし、プロキシ資源エージェント２５０が依然として動作している間に、遠隔ノード２００上の資源自体がダウンすれば、プロキシ資源エージェント２５０は、単にその OpState を変化させる。
【００２８】
遠隔ノードにおける資源回復
前述の「プロキシ資源エージェントの開始」の項で説明したように、資源のために新しい資源生成番号が割り当てられる。このステップを実行する理由は、以下の通りである。もし、新しい資源生成番号が生成されず、そしてプロキシ資源マネージャ１５０がダウンしている間に、遠隔ノード２００上の資源がダウンし、その後に回復すれば、遠隔ノード２００上のこの資源生成番号は、プロキシ資源マネージャ１５０が回復した後でさえも、同じ番号のままに留まることになる。その場合、プロキシ資源マネージャ１５０は、この資源が稼働中であったと見なすことになろう。しかし、このことは正しくない。したがって、新しい資源生成番号を生成することになる。
【００２９】
プロキシ資源エージェントのサービス（遠隔ノード）
もし、プロキシ資源エージェント２５０が、プロキシ資源マネージャ１５０から接続要求を受信すれば、プロキシ資源エージェント２５０は、最初にプロキシ資源マネージャ１５０に現在の資源生成番号を送信することによって応答し、次いで、資源の属性の現在値を送信する。そうすることによって、この両方を、同期のためにチェックできる。プロキシ資源マネージャ１５０とプロキシ資源エージェント２５０との間のセッション（接続）が確立された後、プロキシ資源エージェント２５０は、プロキシ資源マネージャ１５０に、変更された属性値のみを送信する。この接続が中断される場合は、プロキシ資源エージ ェント２５０は、プロキシ資源マネージャ１５０に変更情報を送信することを停止する。
【００３０】
プロキシ資源マネージャの始動（ローカル・ノード）、またはプロキシ資源エージェントへのプロキシ資源マネージャの再接続
ノード１００上のプロキシ資源マネージャ１５０が始動するとき、または遠隔ノード２５０上のプロキシ資源エージェント２５０に再接続するとき、プロキシ資源マネージャ１５０は、最初に、ローカルの永続的記憶装置１６０上に維持された表１６５から、資源生成番号を読み取る。この資源生成番号は、プロキシ資源エージェント２５０から通信された最後の時点で、プロキシ資源マネージャ１５０に知られた最後の資源生成番号である。もし、これが、プロキシ資源マネージャ１５０の最初の始動であれば、ローカルの資源生成番号は、ヌル（またはゼロ）に設定される。その後、プロキシ資源マネージャ１５０は、遠隔ノード２００上のプロキシ資源エージェント２５０との接触を試みる。成功する場合、プロキシ資源マネージャ１５０は、プロキシ資源エージェント２５０から各資源ごとに現在の資源生成番号を受信し、２つの資源生成番号（ローカルの資源生成番号および新たに受信した資源生成番号）を比較する。もし、これらの資源生成番号が互いに異なっていれば、プロキシ資源エージェント２５０が再始動したことが決定されるか、またはプロキシ資源マネージャ１５０が非アクティブであった間に、遠隔ノード２００上の資源がダウンしたかもしくはこの資源に障害が発生したことが決定され、従って、この関連する資源は、down_or_failed（または down_or_failed がサポートされていない場合は stale（失効））とマークされる。一方、これらの資源生成番号が同じ場合は、プロキシ資源エージェント２５０が稼働中であり、従って、資源の状態が依然として有効であると決定される。
【００３１】
新しい資源生成番号を受信した後、この資源生成番号は、永続的記憶装置１６０に記憶される。もし、プロキシ資源マネージャ１５０とプロキシ資源エージェント２５０との接続が成功しなければ、プロキシ資源マネージャ１５０は、所定の期間、たとえば１０秒の間、待機する。しかし、この期間の値は重要ではなく、実装に依存する。この期間の値が影響するのは、遠隔ノード２００の準備ができておらず、しかも遠隔ノード２００が再接続を再び試みるというケースにおける、一番最初の初期接続の後であるに過ぎない。この待機期間が３秒ほどの短いものであっても、重大ではない。前述の接続後、プロキシ資源マネージャ１５０は、遠隔ノード２００から変更された資源属性値を受信し、ローカルの資源属性を更新する。これらの更新済みの資源属性は、ＲＭＩインフラストラクチャ１９０を介してアプリケーションへ報告される。もし、プロキシ資源マネージャ１５０が、プロキシ資源エージェント２５０からの切断を検出すれば、プロキシ資源マネージャ１５０は、前述のように、再接続を試みる。このステップは、どの資源属性も変更しないことに留意されたい。また、新しい資源生成番号が受信されたときは常に、この資源生成番号が永続的記憶装置１６０内に記憶されることに留意されたい。このようにして、ボトムの資源、プロキシ資源エージェント２５０、またはプロキシ資源マネージャ１５０のどの障害も、整合性のある属性値を提供することによって、適切に扱われることになる。
【００３２】
図２は、本発明に特に有用な環境を示す。図２に示されている環境は、本質的には、図１に示すシステムを複数個並列に接続したものである。ＲＭＩサポートを有する複数のノードとともに、ＲＭＩサポートを有していない遠隔ノードがあるということは、プロキシ資源マネージャ１５０．１〜１５０．ｎおよびプロキシ資源エージェント２５０．１〜２５０．ｎの使用を通して、使用可能性が強化される複数の資源があることを意味する。図２に示されたシステムは、ＲＭＩサポート（１９０．１〜１９０．ｎ）を有する多数のＲＭＩノード（１００．１〜１００．ｎ）と、各ＲＭＩノード（１００．１〜１００．ｎ）に接続された１つの遠隔ノードを含んでいる。多数の特殊資源（計算ノード２１１．１〜２１９．ｎ）は、遠隔ノード２００．１〜２００．ｎを介して、監視される。このようなデータ処理システムは、本発明に従って、各ＲＭＩノード上にプロキシ資源マネージャを配置するとともに、各遠隔ノード上にプロキシ資源エージェントを配置することにより、拡張される。プロキシ資源エージェントは、図示のように、計算ノード２１１．１〜２１９．ｎを含む、関連資源を維持する。各遠隔ノード２００．１〜２００．ｎは、それに接続された計算ノード２１１．１〜２１９．ｎを監視し、当該遠隔ノードに接続された資源および計算ノードのための、プロキシ資源エージェントとして働く。
【図面の簡単な説明】
【図１】 本発明が使用される環境とあわせて、本発明の構成要素の位置および構成要素間の対話を示す、概略図である。
【図２】 図１と同様であるが、本発明の有用性がより完全に実現される、より複雑で拡張された環境内で、本発明およびその構成要素の存在および使用をより具体的に示す、概略図である。

Claims (5)

1. 多重ノード分散データ処理システムにおいて、遠隔的にアクセス可能な資源を管理するための方法であって、
   （ａ）前記システムの第１のノード上でプロキシ資源マネージャを実行し、前記第１のノードに結合された永続的記憶装置内に、前記資源に関連する順次資源生成ＩＤを記憶するステップと、
   （ｂ）前記システムの少なくとも１つの他のノード上でプロキシ資源エージェントを実行し、前記資源に関連する前記順次資源生成ＩＤのローカル・バージョンを、前記資源についての状態とともに維持するステップと、
   （ｃ）前記資源の状態が変化するときに、前記プロキシ資源エージェントを介して、前記順次資源生成ＩＤの前記ローカル・バージョンを増分するとともに、当該増分された順次資源生成ＩＤのローカル・バージョンを前記プロキシ資源マネージャに送信するステップと、
   （ｄ）前記増分された順次資源生成ＩＤのローカル・バージョンを受信するときに、前記プロキシ資源マネージャを介して、当該受信した順次資源生成ＩＤのローカル・バージョンと前記永続的記憶装置から読み取られた前記順次資源生成ＩＤを比較し、前記資源の前記状態の整合性を保証するステップと、
   を含む方法。
2. 前記資源が、ポート、データベース、実行可能プログラム、記憶装置およびファイルを含むグループから選択される、請求項１に記載の方法。
3. 前記順次資源生成ＩＤが、番号である、請求項１に記載の方法。
4. 前記ステップ（ａ）〜（ｄ）が、複数の資源のために実行される、請求項１に記載の方法。
5. 他のノードが複数存在する、請求項１に記載の方法。
   【０００１】
   【発明の属する技術分野】

Images