(57)【要約】【課題】プロキシ・リソース・マネージャおよびエージェントの使用によって分散データ処理システム内のリモート・リソースをコントロールし、使用し、そしてモニタするという概念を拡張して、一時的あるいはより長い期間のノード障害の場合であってもリソース・カバレッジが保存され維持されるようなフェイルオーバ機能を提供する。【解決手段】リソース・ステータスの一貫した決定のためのメカニズムを提供する。リモート・リソース１３０のオペレーションを保持しながらノードのグループ１００に対するノードの参加を促進するメカニズムも提供する。障害がノード１１０または１２０のリセットをもたらした場合であっても、前にフェイルしたが現在はリカバリしたノードのコントロールへリモート・リソースの管理を戻すための追加のメカニズムも提供する。【選択図】図１
2008210412.tif 000002
【特許請求の範囲】
【請求項１】
マルチノード分散データ処理システムにおいてリモート・アクセス可能なリソースを管理する方法であって、
ノードがノードのグループに参加するための要求を処理するステップであって、前記グループについてのフェイルオーバ・カバレッジ情報を参加ノードへ提供するステップを含むステップと、
前記グループによってモニタされているリモート・リソースとして前記フェイルオーバ・カバレッジ情報によって指示されるリモート・リソースについてのステータス情報を、前記参加ノードへ提供するステップと、
を含む方法であって、前記方法はさらに、
ノードがフェイルしたこと、そして、前記フェイルしたノードがリモート・リソースを管理していたことを判別するステップと、
フェイルオーバ・グループ内のノードにおいて、前記グループ内のどのノードが前記リモート・リソースの管理を引き継ぐべきであるか選択するステップと、
前記カバレッジ情報を用いてリモート・ノード上に存在するリソースについてのステータス情報を判別し、前記リモート・ノードのプロキシ・リソース・エージェ
ントと通信して前記リソースについての現行のステータスを判別するステップと、
前記判別された現行のステータスを用いて、前記リソースの現行のマネージャとして、前記選択したノード上にプロキシ・リソース・マネージャを設定するステップと、
を含み、前記方法はさらに、
フェイルしていたノードがリカバリした場合に、
前記前にフェイルしたノードが現在は作動していることを示す情報を、前記フェイルしたノードと、ノードのフェイルオーバ・グループ内の他のノードとへ提供するステップと、
前記フェイルしたノードにおいて、リモート・リソース・カバレッジが前記他のノードによって現在処理されていることを判別するステップと、
前記前にフェイルしたが現在はリカバリしたノードの要求時に、前記他のノードから前記フェイルしたノードへ現行のカバレッジ情報を送信するステップと、
前記リモート・リソースの現行の管理を、前記他のノードから前記前にフェイルしたが現在はリカバリしたノードへ変更するステップと、
を含む方法。
【請求項２】
前記ステータス情報は、リモート・アクセス可能なリソースに関するシーケンシャルなリソース世代識別子を含み、
前記プロキシ・リソース・マネージャが前記ステータス情報を、複数のノードのそれぞれのノードに接続された永続ストレージ・デバイスにストアし、
前記リモート・アクセス可能なリソースの少なくとも１つの他のノード上でプロキシ・リソース・エージェントを実行し、前記プロキシ・リソース・エージェントが前記リソースの前記シーケンシャルなリソース世代識別子のローカル・バージョン含むステータス情報を保持し、
前記複数のノードのうちのリスタートするノードのリスタートと同時に、前記永続ストレージ・デバイスにストアされたリソース世代識別子をインクリメントするステップと、
リソース・ステータスの変更と同時に、前記プロキシ・リソース・エージェントを介して、前記ローカル・バージョンのリソース世代識別子をインクリメントするステップと、
前記リソースについて前記ローカル・バージョンのリソース世代識別子と前記永続ストレージ・デバイスにストアされたリソース世代識別子とを比較して、前記リソースの前記ステータスの一貫性を確保する
請求項１に記載の方法。
【請求項３】
前記フェイルしたノードにおいて、リモート・リソース・カバレッジが前記他のノードによって現在処理されていることを判別するステップは、グループ・メンバーシップ・リストを読み取ることによって実行される請求項１または２に記載の方法。
【請求項４】
請求項１乃至３のいずれか１項に記載の方法の各ステップをコンピュータに実行させるためのコンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、分散マルチノード・データ処理システムに関する。特に、本発明は、リモート外部データ処理ノード上の複数の様々なリソースの存在が、それらのステータスが、変化している，不明である，あるいは十分に定義されていないといういずれかの状態を引き起こす可能性がある、このような複数の様々なリソースを管理するメカニズムに関する。さらに詳細には、本発明は、管理ノードの障害に対してトレラントであり、かつ、極めて多数のノードを有するシステムにおいて特に有用であるような、リモート・ノード上のリソースのためのスケーラブル・リソース管理方法に関する。
【背景技術】
【０００２】
本発明は、“A Monitoring Method of the Remotely Accessible Resources to Providethe Persistent and Consistent Resource States”と称される先に提出された特許出願（特許出願番号１０／２２７，２５４，特許出願日２００２年８月２０日）に対する改良であり、この先の出願は、モニタ・ノードのうちの１つにおける障害の可能性に対して、分散マルチノード・データ処理システムにおいてオペレーションを継続的にモニタしコントロールする方法を提供する。システム内の他のノードへのリソース・マネージャ機能のフェイルオーバ・メカニズムを与えることによって本発明が障害に対する保護を与えるという点において、本発明は、上述した方法の機能拡張である。
【０００３】
分散システムにおいては、多くの物理的および論理的エンティティが、システム内の他のノードへ密に接続されてもよくまたは密に接続されなくてもよいリモート・ノードとして最も良く特徴づけられるノードを含むシステム内のノード中にくまなく配置される。これは、分散システムにおいて確認される典型的な特性のうちの１つである。この状況において、これらの物理的および論理的エンティティは、リソースと呼ばれる。この用語“リソース”は、ソフトウェア・エンティティおよびハードウェア・エンティティを指示するために本明細書において広く用いられる。このようなリソースの例は、ノード１４上のイーサネット（登録商標）・デバイスｅｔｈ０，データベース・テーブル“カスタマ”，ＩＰアドレス９．１１７．７．２１などを含む。これらの少数の例から判断して、用語“リソース”が、分散マルチノード・データ処理システムにおいて見られる多数の極めて異なったエンティティを指示することを意図されていることが分かる。一方、それぞれのリソースは、当該リソースの特性を少なくとも部分的に定義する少なくとも１つの属性を有する。さらに、当該属性の一部は、リソースのステータスまたは条件を通して反映される。一例として、ネットワーク・イーサネット・デバイスは、ネーム（name）（例えばｅｔｈ０），OpState（例えばUp，Down，フェイルなど）、そのアドレス（address）（例えば９．１１７．７．２１）などのような属性を典型的に含む。したがって、ネーム，OpState，およびアドレスは、リソース属性と呼ばれる。リソースのステータスを反映するリソース属性（上述のOpStateのような）は、動的属性に分類される。
【０００４】
これらのリソースは、分散データ処理システムの他のコンポーネント（例えば、システム管理ツールまたはユーザ・アプリケーションなど）へサービスを提供するので、これらのリソースは、本明細書において、“リソース・マネージャ・インフラストラクチャ”または“ＲＭＩ”と典型的に呼ばれるエンティティによってシステム・レベルでモニタされおよび／またはコントロールされる必要がある。大部分のＲＭＩは、上述したリソースとこのＲＭＩとが同一のノードに含まれるかまたは限定されるということを前提とする。しかしながら、所定のシステムが、ソフトウェア制約，ハードウェア制約および／またはアーキテクチャ制約のために、リソースおよびＲＭＩの双方を有することもあり有さないこともある異なるタイプのノードを有する場合には、同一ノードのリソースおよびＲＭＩというこの前提は当てはまらない。本明細書において用いられる用語リソース・マネージャ・インフラストラクチャは、データ処理ノードのクラスタ内部のリソースに対してモニタ，照会，変更，およびコントロール機能を実行するサブシステムを含むソフトウェア・コンポーネントのシステムを指す。これらのサブシステムは、典型的に、ノード間通信，リソースの登録などのような共通アクティビティを処理するためにクラスタ・リソース・マネージャによって用いられる共用コンポーネントを含む。ＲＭＩはまた、リソースにオペレートする方法を提供するリソース・マネージャ（ＲＭ）を含み、これらのオペレーションは、リソース状態のモニタと、リソース・コンフィグレーションおよびリソースの振る舞いのコントロールとを含む。典型的には、所定のＲＭは、一組の同種のタイプのリソースを処理する。
【０００５】
上述した先に提出した出願は、プロキシ・リソース・マネージャおよびプロキシ・リソース・エージェントの概念によって、ＲＭＩがないノード上に存在するリモート・アクセス可能なリソースをモニタしコントロールするメカニズムを提供し、さらに、当該プロキシ・リソース・マネージャがフェイルしリスタートされた後であっても永続的かつ一貫した動的属性を提供する。しかしながら、プロキシ・リソース・マネージャまたはそのノードの（比較的）永続的な障害の場合には、リモート・リソースが依然として稼働中でありアクティブであっても、リモート・リソースを継続的にモニタし、コントロールすることはできない。
【０００６】
本発明は、一貫しておりかつ永続的なリソース属性を提供することに加えて、（プロキシ・リソース・マネージャを実行する）プロキシ・ノードの障害の場合でさえ、これらのリモート・リソースをモニタしコントロールする継続的なサービスを提供する。
【０００７】
さらに、望ましくはリソース管理の対象となる分散データ処理クラスタのサイズが大規模（例えば１０００個以上のノード）である場合には、特に、大規模システム内のノードの全ての間でメッセージを交換すべきときには、フェイルオーバ・システムは適切にスケーラブルである必要もある。本発明は、フェイルオーバ・リソース管理機能を提供してノードの大規模クラスタをサポートする効率的なメカニズムを提案する。
【０００８】
本発明を用いることにより、以下の代表的な利点が提供される。
【０００９】
（１）プロキシ・リソース・マネージャ（ＰｘＲＭ）を他のノードへ透過的に移動させて、リモート・リソースを中断なしに継続的にモニタしコントロールする。
（２）フェイルしたノードが修復された場合、プロキシ・リソース・マネージャを最初にフェイルしたノードへ戻すことができる。
（３）本方法は、ロード・バランシング，リカバリ・スピード，およびノードの数の点から見て、効率的でありスケーラブルである。
（４）したがって、“A Monitoring Method of the Remotely Accessible Resources to Providethe Persistent and Consistent Resource States”と称する上述の特許出願において与えられた上述の方法と組み合わせて、リモート・リソースを本明細書において永続的にモニタし、スケーラブルで効率的な方法で、プロキシ・リソース・マネージャすなわちリソース管理インフラストラクチャ（ＲＭＩ）サブシステム，および／または他のノードを含む全ての障害に対して一貫した属性値を保持する。
【００１０】
また、特許文献１は、複数の計算機で構成されたクラスタシステムにおいて、各計算機は、計算機間で通信を行いリソースを監視制御するクラスタデーモンと、自計算機上のクラスタデーモンおよびマネージャと通信を行うエージェントと、監視結果をローカルデータとして記憶するローカルデータ記憶手段を備え、そのうち１台の計算機は、さらに各計算機上のローカルデータから収集されて、いずれの計算機からも参照可能なグローバルデータ記憶手段と、グローバルデータ記憶手段および各計算機上のエージェントと通信を行い、クラスタシステム全体の監視制御を行うマネージャを備え、各計算機上のエージェントがクラスタデーモンと通信して、その計算機上のリソースの状態を定期的に取得する監視制御を行い、マネージャはエージェントと通信してクラスタの集中監視制御を行うクラスタ制御システムを開示する。そして、マネージャやノードに障害が発生した場合、同一のマネージャを他の計算機上で再起動する旨を開示する。
【００１１】
特許文献１では、新たなノードを動的にリカバリグループに加え、または復活したノードを動的にリカバリグループに加えて、リソースの管理を元に戻すことまで開示されていない。
【００１２】
【特許文献１】特開２００４−２８０４９４号公報
【発明の開示】
【発明が解決しようとする課題】
【００１３】
本発明の目的は、様々なコンピュータ・リソースが分散データ処理システムのリモート・ノード上に存在する場合であっても、これらのコンピュータ・リソースを常に管理することである。
【００１４】
本発明の他の目的は、リモート・データ処理ノード上に位置するリソースに関するステータス情報を追跡し保持することである。
【００１５】
本発明のさらなる目的は、データ処理システムのインテリジェント自律オペレーションのためのメカニズムを提供することである。
【００１６】
また、本発明の他の目的は、ノードの障害またはノードとの通信障害が不測の事態であり、このような事態においてもなおリモート・リソース・ステータスが保持され、かつシステムのフェイルしてない部分にとって利用可能にされるメカニズムを提供することである。
【００１７】
本発明の他の目的は、分散データ処理システムにおけるフェイルオーバ機能を提供することである。
【００１８】
また、本発明の目的は、現在割り当てられているリモート・リソースの数に基づいてフェイルオーバ・グループ内のノードを選択することにより、ロード・バランシングの範囲を提供することである。リモート・リソースの数は管理のために割り当てられる。
【００１９】
本発明の他の目的は、リカバリしたフェイル・ノードが当該システム内の他のノードに対するリモート・リソース・マネージャとしての役割を回復することができるメカニズムを提供することである。
【００２０】
本発明のさらに他の目的は、分散データ処理システムの信頼性と可用性とを拡張することである。
【００２１】
最後に、この点に限定されないが、本発明の目的は、分散データ処理システムの性能と効率とを向上させ、当該システムの自律オペレーションを向上させることである。
【課題を解決するための手段】
【００２２】
本発明の第１の好適な態様によれば、マルチノード分散データ処理システムにおいてリモート・アクセス可能なリソースを管理する方法およびシステムが与えられる。プロキシ・リソース・マネージャが、当該分散システム内の複数のノード上で実行され、これらのノードのうちのそれぞれのノードに接続された永続ストレージ・デバイス内に、シーケンシャルなリソース世代番号（ＲＧＮ）（あるいは同等の識別子）がストアされる。ＲＧＮはリモート・リソースに関係する。プロキシ・リソース・エージェントが１つ以上の他の（リモート）ノード上で実行される。ＲＧＮのローカル・バージョンがリモート・ノード上で保持され、このローカル・バージョンは当該ノードに属する特定のリソースに関係する。当該システム・ノードのうちの１つのリセットまたはリスタートと同時に、ＲＧＮがインクリメントされる。ＲＧＮはまた、リソースのステータスの変更と同時にプロキシ・リソース・エージェントを介してインクリメントされる。リモートＲＧＮとシステムＲＧＮとを比較して、リモート・リソースのステータスに基づいてオペレーションの一貫性を保証する。
【００２３】
本発明の第２の好適な態様において、マルチノード分散データ処理システムにおいてリモート・アクセス可能なリソースを管理する方法が与えられる。この方法において、ノードがノードのグループに参加するための要求を処理するステップは、当該グループについてのフェイルオーバ・カバレッジ情報を参加ノードに与えるステップを含み、ここにおいてメンバーシップが求められ、（フェイルオーバ）グループによってモニタされているリモート・リソースとしてフェイルオーバ・カバレッジ情報によって指示されているリモート・リソースについてのステータス情報を参加ノードに提供する。この態様は、ノードが協働ノードのグループに参加する方法であるともみなされる。
【００２４】
本発明の第３の好適な態様において、上記で用いられたプロキシ・リソース・マネージャをフェイルしたノードからフェイルしてないノードへ効果的に移動させてオペレーションの継続性を拡張するメカニズムが与えられる。この方法において、ノードがフェイルしたこと、そして、フェイルしたノードがリモート・リソースを管理していたということを最初に判別する。事前定義されたフェイルオーバ・グループ内のノードのうちの１つにおいて、当該リモート・リソースの管理を引き継ぐべきフェイルオーバ・グループ内のノードを選択する。リモート・ノード上に存在するリソースに対して適切なステータス情報を、事前に設定されたカバレッジ情報を用いて判別する。このカバレッジ情報を用いて、リモート・ノードのプロキシ・リソース・エージェントと通信して対象リソースについての現行のステータスを判別する。リモートに配置されたリソースの現行マネージャとなるべきプロキシ・リソース・マネージャを、次に、選択されたノード上に設定する。この機能を実行するために、当該プロキシ・マネージャは、前に判別された現行のリモート・リソース・ステータスを用いる。
【００２５】
本発明の第４の好適な態様において、フェイルしたノードがリスタートされた後、あるいはそのオペレーション・ステータスが正常に復帰した後で、当該フェイルしたノードにプロキシ・リソース・マネージャを戻すためのメカニズムが与えられる。この方法において、前にフェイルしたノードが現在は作動していることを示す情報が、当該フェイルしたノードと、ノードのフェイルオーバ・グループ内の他のノードとへ提供される。これは、グループ・サービスによって提供される。次に、前にフェイルしたノードにおいて、リモート・リソース・カバレッジがフェイルオーバ・グループ内の他のノードによって現在処理されているということが判別される。前にフェイルしたノードの要求時に、現行のカバレッジ情報が、フェイルオーバ・グループ内のノードから前にフェイルしたノードへ送信される。この時点において、当該リモート・リソースの現行の管理が、当該フェイルオーバ・グループ・ノードから前にフェイルしたが現在はリカバリしたノードへ変更される。
【発明を実施するための最良の形態】
【００２６】
本発明の好適な実施形態において、ＲＳＣＴ／ＲＭＣのようなリソース管理インフラストラクチャが存在すると仮定される。ＲＳＣＴ／ＲＭＣインフラストラクチャは、リソースのモニタおよびコントロール（ＲＭＣ）のためのコンポーネントを含む。一般に、ノード上のＲＭＩは、多数のリソース・マネージャ（ＲＭ），１つのＲＭＣおよび他のＲＳＣＴサブシステム・コンポーネントとノード上の複数のリソース・マネージャを含む。ＲＳＣＴ（Reliable Scalable Cluster Technology）は本発明の譲受人によって市場で販売される公に入手可能なプログラム・プロダクトである。ＲＭＣサブシステムは、データ処理システム内部かまたはノードのクラスタ内部のリソースを管理し操作するためのフレームワークを与える。このフレームワークは、クラスタのいずれかのノード上のプロセスが、当該クラスタ内の他の場所の１つ以上のリソースに対するオペレーションを実行するのを可能にする。
【００２７】
クライアント・プログラムは、実行されるべきオペレーションを特定し、ＲＭＣＡＰＩと呼ばれるプログラミング・インターフェースを通じてクライアント・プログラムが適用される必要があるリソースを特定する。ＲＭＣサブシステムは、次に、オペレートされるべきリソースを含むノードを決定し、それらのノードへ要求されたオペレーションを送信し、それらのノード上の適切なコードを起動してリソースに対してオペレーションを実行する。起動されてオペレーションを実行するコードは、リソース・マネージャと呼ばれるプロセス内に含まれる。
【００２８】
リソース・マネージャ（図１の参照符号２００．１，２００．２，２１０．１，２１０．２，２１０．３および２１０．４を参照）は、リソース・タイプ・アブストラクション（abstraction）を１つ以上の特定のタイプのリソースについてのコールおよびコマンドへマップするプロセスである。リソース・マネージャは、自身のリソースが存在し得るクラスタの全てのノード上で実行することが可能である。様々なノード上で実行されるリソース・マネージャ・プロセスのインスタンスが協働し、上述したアブストラクションを与える。
【００２９】
ＲＭＩノードの外側に位置するリモート・リソースをモニタしコントロールするために、ＰｘＲＭと呼ばれるリソース・マネージャ（図４の参照符号３３０．ｘを参照）がＲＭＩノード（図２の参照符号１１０および１２０を参照）上に配置され、ＰｘＲＡと呼ばれるそのピア・エージェント（図５の参照符号４３０．ｘを参照）が外部エンティティ上（すなわち、非ＲＭＩノード上または図５のノード４０５．ｘのようなデバイス上）に配置される。
【００３０】
ＰｘＲＭ３３０．ｘ（図４参照）は、ＲＭＣサブシステムおよびＰｘＲＡ４３０．ｘ双方へ接続する（図１および２においてフェイルオーバ・グループ１  １００から下方へ延びる矢印によって示される）リソース・マネージャである。ＰｘＲＭ３３０．ｘによって用いられるリソースは、ＰｘＲＡからのリソースの表現（representation）である。ＰｘＲＡ４３０．ｘは、それがリソースの経過を追い、現行のＰｘＲＭへ変化を報告する限り、どのようなもの、例えば中間プロセスまたはサービス・ルーチン、であってもよい。
【００３１】
永続的かつ一貫したリソースの属性値を与えるために、ＰｘＲＭがリスタートされた後であっても、プロキシ・リソース・マネージャはＰｘＲＡからステータスを与えられる。このアクティビティを処理するために、リソース世代番号（ＲＧＮ）と呼ばれるインジケータが与えられる。リモート・ノード上のそれぞれのリソースはＲＧＮを有する。ＰｘＲＭがリソース属性の現行ステータスを知ることができるように、ＲＧＮは正確に変更され、ＰｘＲＭとそのＰｘＲＡとによって追跡される。ＲＧＮは、上述の特許出願においてより詳細に説明される。
【００３２】
ここで、ＲＧＮはそれぞれのリソースごとに時刻に関して固有であり、単調にインクリメントされる。言い換えれば、２つのＲＧＮが異なった時刻において作成された場合には、それらは異なる。この特性は、ＲＧＮが変更されたか否かを決定する際に、状態のあいまいさがないことを保証する。したがって、適切なＲＧＮは、タイム・スタンプとして簡単に実施することができる。
【００３３】
本発明は、リソース・マネージャがフェイルオーバ・グループ内で協力して共に動作するメカニズムを提供する。フェイルオーバ・グループとは、ノードが処理するよう要求され得るリソースの全てに関連する一貫したデータのセットが含まれるノードのセットである。フェイルオーバ機能を与えるために、本発明は、グループ・サービス・プロダクト（本発明の譲受人であるインターナショナル・ビジネス・マシーンズ・コーポレーションによって市場で販売されるプログラム）によって与えられるようなソフトウェア・サービスを用いる。グループ・サービスによって提供される機能を用いて、それぞれのプロキシ・リソース・マネージャは、他のプロキシ・リソース・マネージャの障害を確実に検出し、リモート・ノード間のアクションを調整する。さらに、ノードの大規模クラスタを調整するために、ノードはここで、上述したようにグループ化される。フェイルオーバは同一のフェイルオーバ・ノード・グループ内のノード間でのみ発生する。これは、効率およびスケーラビリティを与えるためだけでなく、フェイルオーバの過度の連鎖が発生するのを阻止するためにも有用である。例えば、一部のシステムにおいて、電力および多くの内部接続は、ノードの特定のグループに限定される。したがって、他のグループ内のノードへのフェイルオーバは望ましくない。例えば、複数のノードに影響を与える電源障害の場合には、同一の電源グループ内の他のノードへのフェイルオーバは無益である。ノードの同様のグループ化は、汎用コンピュータのクラスタにも適用できる。したがって、それぞれのノードは、好ましくは、グループ・サービスのフェイルオーバ・グループ指定を用いてノード・グループへ割り当てられ、ここにおいてノードのグループは“フェイルオーバ・グループ（FailoverGroup）＜＃＞”と称され、＜＃＞はノード・グループ番号を示す。
【００３４】
それぞれのＰｘＲＭはＰｘＲＡのリソースとフェイルオーバ・グループのうちの１つのメンバとを表すリソース・マネージャであることにも留意されたい。したがって、以下の説明は、特に所定のフェイルオーバ・グループにおけるアクティビティおよびリアクションに関連して、フェイルオーバがどのように実行されるかという点に主に集中する。
【００３５】
（前提）
以下の説明においては、本発明を適切な状況に位置づけ、その構造とオペレーションとの完全な理解をより適切に確保するために、所定の条件を最初に検討する。特に、以下の事項が仮定される。（１）クラスタは、リソース・マネージャ（ＲＭ）を実行する複数のノードから構成される。（２）特定のロケーション（例えばミッドプレーンまたはフレーム）におけるリソースのセットはカバレッジと呼ばれ、全システム内のリソースは複数のカバレッジに分割され、それぞれのカバレッジは固有の識別子（ＩＤ）を用いて識別される（図１の参照符号１３０．１，１３０．２，１３０．３および１３０．４を参照）。（例えば、固有のＩＤはフレーム番号であってもよい。言い換えれば、固有のＩＤはリソースをホストする特定のロケーションのセットを識別する。）（３）平易さのために、本明細書においては、それぞれのＲＭエンティティは、１つのカバレッジに対する責任を有することに限定されている。（しかしながら、本発明のより一般的な実施形態においては、実際のＲＭプロセスは、複数のカバレッジについての複数のＲＭエンティティ（すなわちスレッド）を有することができることに留意されたい。）したがって、ここでは、カバレッジの識別子は、その関連したＲＭのＩＤと交換可能に用いられる。（４）それぞれのノードは、１つ以上のカバレッジ（１３０．１〜１３０．４）も表す１つ以上のＲＭを実行することができる。（したがって、上述の項目（３）と共に項目（４）を組み合わせると、単一のノード（図１のノード１１０および１２０を参照）は、複数のＲＭ（図１の参照符号２１０．１〜２１０．４）をホストしてもよく、あるいは、インプリメンテーションに従って、複数のカバレッジをカバーする複数のスレッドを備える１つのＲＭをホストしてもよいことに留意されたい。）（５）カバレッジ（またはＲＭ），フェイルオーバ・グループ１００，およびノード（例えば図１の１１０および１２０）の間に存在するマッピング・コンフィグレーションが存在する。（このコンフィグレーションを用いて、ＲＭは、フェイルオーバのためにどのノードを使用できるかということ、そして、それぞれのノードへ最初に割り当てられるべきカバレッジはどれかということを“知る”。言い換えれば、それぞれのＲＭのランタイムの間に用いられるノードは、当該コンフィグレーション内のノードと異なってもよい。それは、また、複数のＲＭが単一ノード内に存在することを可能にする。）（６）グループ・サービス（またはマルチノード環境において同様の機能を提供するプログラム）は、フォールトトレラントで高度に可用なクラスタワイド・グループ・メンバーシップ・サービスおよび同期サービスのために用いられる。このサービスを用いて、ＲＭをホストするそれぞれのノードは、他のノードのステータスを確実に“知り”、加えて、ノードとワーキング・カバレッジとの間の現行のアクティブ・マッピング情報を保持する。
【００３６】
【表１】
2008210412.tif 000003
【００３７】
（フェイルオーバ・グループの形成）
ノード上のそれぞれのＲＭが開始されるとき、それぞれのＲＭはコンフィグレーションを読み取り、構成されたフェイルオーバ・グループに参加することを試みる。参加要求が受諾された場合、続いて、参加ＲＭがカバレッジに関して、リモート・リソース（図５および図４の上位レベルにおける４１１．ｘ，４１２．ｘ，…，４１ｍ．ｘ、同様に図４および５の符号Ｃ1 ，Ｃ2 ，…，Ｃm を参照）へのコンタクトを開始する。他の既に参加しているメンバが意図したカバレッジを既に処理しているために参加オペレーションが失敗した場合、ＲＭは当該グループにサブスクライブして当該グループのアクティビティをモニタする。参加ノードは当該グループのメンバになり、メンバがメンバーシップ・リストにリストされる。さらに、本明細書で用いられるとき、用語“サブスクライブ”は、参加ノードが、当該ノード・グループにおいて他のノードがどのような状態であるかの確認を実行するオペレーションを指す。サブスクライブの理由は、どのノードが参加しており、またはフェイルしているかをモニタするためである。
【００３８】
したがって、フェイルオーバ・グループ（例えば図１および２のフェイルオーバ・グループ１  １００）に参加するとは、ＲＭがアクティブになって意図したリソースをカバーすることを意味する。それぞれのフェイルオーバ・グループ・メンバーシップは、リソース・マネージャのリストを表すメンバＩＤのリストを含む。メンバＩＤはノード番号とグループ・サービスによって与えられる番号との組み合わせである。例えば、（図２を参照すると、フェイルオーバの前の）上述のケースは、以下のメンバーシップになる。
【００３９】
【数１】
2008210412.tif 000004
【００４０】
これを判別するために、ＲＭは、自身が属する関連フェイルオーバ・グループ１００に参加し、次に、アクティブ・ノードをリストする現行のＲＭメンバーシップを受け取る。グループ・サービスの機能により、ＲＭは、要求ノードＮ２内の他のノードによって現在処理されているカバレッジを取得し、現行のマッピング情報を更新する。一例として、新たに追加されたＲＭがノードＮ２上にあり、Cover３（図１の１３０．３）およびCover４（図１の１３０．４）のカバレッジを処理するノードがない場合には、フェイルオーバの現行メンバーシップとアクティブ・カバレッジとは以下のようになる。
【００４１】
【数２】
2008210412.tif 000005
【００４２】
意図したカバレッジが他のノードへフェイルオーバされているか否か判別した後、ＲＭは構成されたカバレッジをカバーすることを開始し、マッピング（Ｎ２，Cover３），（Ｎ２，Cover４）を現行のアクティブ・マッピングに追加する。後続のマッピングは以下の通りである。
【００４３】
【数３】
2008210412.tif 000006
【００４４】
他方、意図したカバレッジが他のノードによって既に処理されており、コンフィグレーション・ノードへ戻す要求がある場合には、ＲＭは、既にカバーしているノードすなわちＮx にコンタクトする。要求と同時に、ノードＮx は現行カバレッジ関連情報のコピーを要求ノードＮ２に送付し、現行のマッピング情報を更新する。
【００４５】
（リソースのモニタ／コントロール）
リソースのモニタおよびコントロールは、上述の特許出願（“A Monitoring Method of the Remotely Accessible Resources to Providethe Persistent and Consistent Resource States”と称された２００２年８月２３日出願の特許出願番号１０／２２７，２５４）に記載されたのと同じ方法で行われる。
【００４６】
（ＲＭの障害の検出とフェイルしたカバレッジの引き継ぎ）
ノードすなわちノードＮ１がフェイルする場合、グループ・サービスは他のノードにノードＮ１の障害について通知する。障害通知の受信と同時に、同じフェイルオーバ・グループ内の他のノードのうちの１つが当該カバレッジを引き継ぐ。ロードが同じ場合、ノードの選択はロードとノード番号とに基づく。ここで、ロードは、それぞれのノードによって処理されるように指定されたカバレッジの個数として示される。選択は、ノード間の通信を伴わずにローカルに行われてもよい。
【００４７】
上述の例（図１）において、ノードＮ２に対するロードすなわち“ロード（Ｎ２）”は２であり、ノードＮ２がカバレッジCover１およびCover２を引き継ぐ、というのは、Ｎ２のロードが、同じフェイルオーバ・グループ（フェイルオーバ・グループ１）内のノードの間で最小のロードであるからである。ノードＮ１はフェイルしたノードであるとみなされているので、ノードＮ２は現行のカバレッジ情報をノードＮ１から取得することができない。この状況において、Cover１およびCover２についての現行のカバレッジ情報は、当該カバレッジに現在責任のあるカバーＰｘＲＭにコンタクトすることによって再構成される。上述した特許出願において述べられた永続的リソース・モニタ方法を用いて、再構成が確実に行われる。
【００４８】
（フェイルしたカバレッジのリカバリ（フォールバック））
任意で、本プロセスはまた、オリジナル・ノードが使用可能になったとき、当該オリジナル・ノードへのカバレッジのフォールバックを提供する。例えば、図１において、ノードＮ１が障害の後に再び使用可能になった場合、カバレッジCover１およびCover２を以下の方法で再びノードＮ１へ戻してもよい。
【００４９】
（１）Ｎ１（１１０）が再び使用可能になったとき、グループ・サービスはこのイベントの通知をノードＮ２（１２０）とＮ１とに与える。
【００５０】
（２）Ｎ１が、“フェイルオーバ・グループの形成”において述べたようにフェイルオーバ・グループに参加を試みるとき、ノードＮ１は、グループ・サービスによって提供され保持されるグループ・メンバーシップ・リストを読み取ることにより、Ｎ１用のカバレッジがＮ２へフェイルオーバされたことを発見する。このリストは、当該グループ内のノード上に存在するＲＭ（例えば、図２に見られるように、それぞれがノード３，ノード４，ノード５およびノード６と識別されるノード上に存在するＲＭ２００．１ａ，２００．２ａ，２００．３および２００．４）を識別する。
【００５１】
（３）この状態の認識と同時に、Ｎ１は、現行のCover１およびCover２の情報を送信するようノードＮ２に対して要求を発行する。これは、グループ・サービスのメッセージング・サービスによって行われる。
【００５２】
（４）この情報の受信と同時に、ノードＮ１はCover１およびCover２についてのメンバーシップに参加し、Ｎ２はCover１およびCover２についてのメンバーシップをリリースする。
【００５３】
（５）Cover１およびCover２についてのメンバーシップの成功した変更の直後に、カバレッジはオリジナル・ノードへ戻される。
【００５４】
図３は、参照符号３１０．１〜３１０．４によって集合的に指示され、あるいは図４の符号３１０．ｘによってより一般的に指示される接続されたコンポーネント間の関係を説明する。ここで、説明の便宜のために、３１０．ｘの“ｘ”は、１〜４の範囲であると仮定することができ、３２０．ｘ，３２５．ｘ，３３０．ｘ，３４０．ｘおよび３５０．ｘについても同様であり、本明細書の他の箇所でも同様である。特に、３１０．ｘは、フェイルオーバ・グループ内のノードを指示する。これらのノードは、リモート・ノード４００．ｘ上のプロキシ・リソース・エージェント４３０．ｘと通信するプロキシ・リソース・マネージャ３３０．ｘを含む。本発明の重要な側面は、図４に示されるように、それぞれのリモート管理リソースＣi についてのエントリのテーブル３２５．ｘに関する永続メモリ３２０．ｘの保持力である。テーブル３２５．ｘは、（本図示の例において）ノード３〜５に存在するプロキシ・リソース・マネージャ（ＰｘＲＭ）３３０．ｘと、リモート・ノード４００．１〜４００．ｘ（ここでは、説明の便宜だけのためにｘは４とする）に存在するプロキシ・リソース・エージェント（ＰｘＲＡ）との間の通信の間中同期状態に保持される。リソース世代番号（ＲＧＮ）の使用によって同期が可能になる。ＲＧＮの変更と特性は本明細書の他の箇所で述べられる。テーブル３２５．ｘは、それぞれのリモート管理リソースについてのエントリを含む。ネームによってリソースを識別するエントリが存在し、自身の現在割り当てられたＲＧＮを示すエントリが存在する。リソース・ステータスを示し、（必要に応じて）リソース特定情報を示すさらなるエントリがテーブル３２５．ｘに与えられる。テーブル３２５．ｘおよび４２５．ｘ（図５参照）の構造は本質的に同一である。しかしながら、フェイルしたノードがサービスに戻るときに生じるようなＲＧＮエントリの差異が、時々存在し得る。管理ノードが自身のサポート・エントリのリストからリモート・リソースを落とすことを選ぶときに存在する差異も存在し得る。管理ノードにおいて、プロキシ・リソース・マネージャ（ＰｘＲＭ）３３０．ｘは、一貫して定義されたリソース管理インターフェース３４０．ｘを通してローカル・リソース・マネージャ３５０．ｘと通信する。また管理ノードにおいて、永続ストレージ３２０．ｘは、ディスク・ドライブ，光ディスク・ドライブ，磁気テープ・ドライブ，あるいはさらにランダム・アクセス・メモリを含むことができることに留意されたい。不揮発性の厳しい基準とは対照的に、最も重要な特徴は永続性である。
【００５５】
リモート・リソースＣ1 ，Ｃ2 ，…，Ｃm （それぞれ４１１．ｘ，４１２．ｘ，…，４１ｍ．ｘ）と共にリモート・ノード４０５．ｘを含む４００．ｘのようなリモート・ノード複合体において、プロキシ・リソース・エージェント（ＰｘＲＡ）４３０．ｘはテーブル４２５．ｘを保持する。テーブル４２５．ｘは、理想的な状況下では、ローカルに保持されるテーブル３２５．ｘの複製物である。ＰｘＲＡ４３０．ｘは、ＲＧＮエントリを伝送し、そしてそれらを比較してリモート・リソース・ステータスの一貫性を確保するためにＰｘＲＭ３３０．ｘと直接通信する。リモート・リソースＣ1，Ｃ2 ，…，Ｃm はノード・インターフェース４３５．ｘを通してノード４０５．ｘと通信する。ノード・インターフェース４３５．ｘは、また、リソースと通信するためにプロキシ・リソース・エージェントＰｘＲＡ４３０．ｘによって使用される。ノード・インターフェース４３５．ｘは、リモート・リソースと、ノード・インターフェース４３５．ｘが直接付加されたノードとの間の通信のためのメカニズムを指すことのみを意図する。これは、本発明の一部を形成するものではない。
【００５６】
たとえ図面と本明細書の説明とが、単一のフェイルオーバ・ノード・グループに関連した動作と機能とに主に傾注していても、全ての合理的な数のフェイルオーバ・グループを定義して用いることができること、そして、好ましくは、ＲＧＮ情報および関連したステータス情報をプロキシ・リソース・マネージャへ伝えるプロキシ・リソース・エージェントの使用によってリモート・ノードにおいてストアされ保持されるこのＲＧＮ情報への参照が成される限り重複するカバレッジが許容されることを、本発明は意図し、許容し、そして提案する。
【００５７】
リソース世代番号は、リソースごとに時刻に関して固有である。言い換えれば、２つのＲＧＮが異なった時刻において作成された場合にはそれらは異なる。この特性は、リソース世代番号が変化したか否か判別する際に状態のあいまいさがないことを保証する。したがって、リソース世代番号は、好ましくは、タイム・スタンプと同程度単純なものである。一方、リソース世代“番号”は、一般的には、リソース世代番号に関する定義された順序関係を有することができる印を含んでもよいことに留意されたい。整数およびタイム・スタンプ（日付とタイム・スタンプを含む）は、明らかに、このような印の最も明白で容易に実施される例である。したがって、“番号”であるＲＧＮへの本明細書における言及は、１つ以上の形態の数表現へ当該印を限定するものと解釈すべきではないことに留意されたい。また、本明細書においてＲＧＮがインクリメントされることを示す場合には、インクリメントが正の数であるという特定の要件は存在せず、印の順序付けまたは更新が特定の方向に生じなければならないという暗示も存在しないことに留意されたい。順序と比較可能性とが、当該印についての望ましい特性である。タイム・スタンプは、好適な実施例においてのみ用いられる。
【００５８】
本明細書で用いられる場合、ノードがフェイルしたことが示されるとき、これは、ノードへの通信および／またはノードからの通信がもはや生じないということ、あるいは、内部ノード問題が存在するということを意味する。通信問題によるノードの障害は、より一時的である、および／または継続期間が短い傾向がある。これらの障害は、通信アダプタに関する問題によって発生しやすい。一方、通信問題は、代わりの通信パスの識別と使用によって時に解決可能である。事実上より重大になりやすい内部ノード問題に関しては、ノードのリスタートまたはノードのリブートが多くの場合問題を解決するが、このような場合においては、ＲＧＮがゼロ（または等価）にリセットされる。これらのステータスの変化は、本発明のＰｘＲＭによって確認される。
【図面の簡単な説明】
【００５９】
【図１】本発明が用いられるオペレーティング環境と、本発明のオペレーションの全    体構造とを説明するブロック図である。
【図２】図１と同種のより詳細なブロック図であるが、典型的なオペレーションの際    に生じる本発明の様々なコンポーネントのステータスをより具体的に説明し、リモート・ノード上に保持されるデータの構造をさらに具体的に説明する。
【図３】非リモート・ノード、すなわち、ＲＭＩを含みリモート・リソースについてのプロキシ・リソース・マネージャを実行する中間ノード、において保持される情報の構造をより詳細に説明する図２の拡大部分を示す図である。
【図４】プロキシ・リソース・マネージャＰｘＲＭの役割と、システムの他の部分との対話とを説明する図２の一部の拡大部分を示す図である。
【図５】プロキシ・リソース・エージェントＰｘＲＡの役割と、分散データ処理システムのリモート部分のうちの他の部分との対話とを説明する図２の拡大部分を示す図である。
【符号の説明】
【００６０】
１００  フェイルオーバ・グループ
１１０，１２０  ＲＭＩノード
１３０．１，１３０．２，１３０．３，１３０．４  カバレッジ
２００．１，２００．２，２００．３，２００．４，２１０．１，２１０．２，２１０．３，２１０．４  リソース・マネージャ
３００．１，３００．２，３１０．１，３１０．２，３１０．３，３１０．４  ノード
４００．１，４００．２，４００．３，４００．４  リモート・ノード
３１０．ｘ  ノード
３２０．ｘ  永続メモリ
３２５．ｘ  エントリ・テーブル
３３０．ｘ  プロキシ・リソース・マネージャ
３４０．ｘ  リソース管理インターフェース
３５０．ｘ  ローカル・リソース・マネージャ
４００．ｘ  リモート・ノード
４０５．ｘ  リモート・ノード
４１１．ｘ，４１２．ｘ，４１ｍ．ｘ  リモート・リソース
４２５．ｘ  テーブル
４３０．ｘ  プロキシ・リソース・エージェント
４３５．ｘ  ノード・インターフェース__
【図１】
2008210412.tif 000007
【図２】
2008210412.tif 000008
【図３】
2008210412.tif 000009
【図４】
2008210412.tif 000010
【図５】
2008210412.tif 000011