JP3910539B2 - 準備処理を取り入れたクラスタード・コンピュータ・システムにおけるリソース・アクション - Google Patents

Description

本発明は一般にクラスタード・コンピュータ・システムに関し、より詳細には、クラスタード・コンピュータ・システムにおけるリソース・アクションの処理に関する。

「クラスタリング」とは一般に、複数のコンピュータまたはノードが共にネットワークを形成し協調的にコンピュータ・タスクを実行するコンピュータ・システム編成のことをいう。コンピュータ・クラスタの重要な特徴は、クラスタ内のすべてのノードが単一システムのイメージを提示すること、すなわち、ユーザからは、クラスタ内のノードが全体として単一のコンピュータまたはエンティティに見えることである。

クラスタリングは、高いパフォーマンスおよび信頼性が重視される比較的大規模なマルチユーザ・コンピュータ・システムでよく利用される。例えば、クラスタリングを用いて冗長性や耐障害性を提供することにより、クラスタ内のいずれかのノードが障害を起した場合、そのノードが実行していた処理をクラスタ内の別のノードで処理できるようになる。また、複数ノードで並列処理を行えば、単一コンピュータで処理するよりも多数のタスクを処理できるので、全体的なパフォーマンスを向上させるためにクラスタリングが利用される。また、タスクをノード間に公平に分配して個々のノードが過負荷に陥るのを防ぎ、それによってシステム全体のパフォーマンスを最大にするために、負荷バランシングがしばしば利用できる。クラスタリングの具体的な適用例の１つに、例えば、データベースやストレージ装置などの共用リソースに対するマルチユーザ・アクセスの実現がある。複数ノードで比較的多数のユーザからのアクセス要求を処理でき、クラスタ内のどの所与ノードに障害が起きても、一般にユーザは共用リソースを利用し続けられるからである。

クラスタは一般に、個々のノード内で「ジョブ」または「プロセス」を実行することによって、コンピュータ・タスクを処理する。異なるノードで実行されているジョブが、互いに連携してコンピュータ・タスクを処理する場合もある。そのような連携ジョブは、一般に相互通信が可能であり、通常「グループ」として知られる論理エンティティを用いてクラスタ内で管理される。グループには通常、何らかの形式の識別子が割り当てられ、グループ内の各ジョブには、グループ内のメンバであることを示すその識別子が付けられる。クラスタ管理用の処理の多くもまた、クラスタ制御グループとしばしば呼ばれる連携ジョブのグループを用いて処理される。

グループ内のメンバ・ジョブは一般に、順序付けられたメッセージに基づく方式を用いて相互通信を行う。この方式では、グループ・メンバ間で送信したメッセージの具体的な順序を維持管理する。こうすることで、すべてのメンバは、他のすべてのメンバが参照するのと同じ順序で、他のメンバが送信したメッセージを参照でき、ノード間の同期が確保される。グループのメンバに処理の実行を求める要求は、しばしば「プロトコル」と呼ばれ、グループのメンバは、一般に１つまたは複数のプロトコルを使用して連携を取りながらタスクを実行する。

クラスタード・コンピュータ・システムでは、システムの可用性を最大化することが非常に重視される。そのため、このようなシステムでは、自動エラー検出や自動エラー復旧がきわめて望ましい属性となる。潜在的なエラー発生源の１つに、メモリ・アドレス範囲や入出力（Ｉ／Ｏ）装置など、クラスタード・コンピュータ・システムの管理および運用に使用される何らかのリソースの消失がある。

特に、高い信頼性が求められるシステム・クリティカルなアプリケーションの場合、リソースの管理、特に消失したリソースの復旧によって、それらのリソースを使用するアプリケーションの信頼性を著しく向上させることができる。状況によっては、クラスタ内のノードやその他のエンティティ間でリソースの移転が行われるが、リソースが消失する危険性が最も高まるのはしばしばこうした移転の最中である。２つのエンティティが同一のリソースを所有する問題を回避するため、一般にクラスタード・コンピュータ・システムでは、リソースの移転に先立って、リソース提供側のエンティティが所有権を解放することが必要とされる。したがって、リソースの所有権を解放する提供側エンティティとリソースの所有権を獲得する他のエンティティとの間で障害が発生した場合、リソースが失われることがあり得る。

多くのクラスタード・コンピュータ・システムにおいては、消失リソースを復旧することにより、そうしたリソースを他のエンティティが使用できるようにすることが非常に望ましい。しかし、従来のシステムでは、消失リソースを復旧するための信頼性のあるいかなる方式も提供されなかった。さらに、エンティティ間またはエンティティ・タイプ間でのリソース移転など、その他のタイプのリソース関連アクションも、類似の危険性をもたらすことがある。例えば、仮想アドレス範囲などのリソースの場合、異なるエンティティ間または異なるエンティティ・タイプ間で、リソースをシフトできれば望ましいことがある。

したがって、当技術分野では、クラスタード・コンピュータ・システム内のリソース上でリソース・アクションを実行するための方式、特に、リソース衝突や他の潜在的なエラーの危険性を低下させながら有効にリソースを管理するための方式が強く求められている。

したがって、本発明は第１の態様として、複数のリソースとその複数のリソースを所有するように構成された複数のクラスタ・エンティティとを含むタイプのクラスタード・コンピュータ・システムにおいて、リソース・アクションを実行する方法を提供する。この方法は、クラスタード・コンピュータ・システムの準備処理の最中にアクティブであるクラスタ・エンティティは、クラスタ構成パラメータの変更を受け入れ、クラスタード・コンピュータ・システムの準備処理の最中に非アクティブであるクラスタ・エンティティは、クラスタ構成パラメータの変更を受け入れないように、クラスタード・コンピュータ・システム内の複数のクラスタ・エンティティに関係付けられた少なくとも１つのクラスタ構成パラメータを変更することにより、リソース・アクションの実行に先立ち、クラスタード・コンピュータ・システムの準備処理を行い、それによって、そのような非アクティブ・クラスタ・エンティティが後でクラスタード・コンピュータ・システム中に受け入れられないようにするステップを含む。

好ましくは、複数のクラスタ・エンティティは、複数のクラスタ・ノードを含む。

好ましくは、クラスタ構成パラメータは、複数のクラスタ・ノードの各々に格納されたクラスタ識別子を含む。

好ましくは、複数のクラスタ・エンティティは、複数のクラスタ・オブジェクトを含む。

好ましくは、クラスタ構成パラメータは、複数のクラスタ・オブジェクトの各々に関係付けられたオブジェクト識別子と所有権移転カウントとを含む。

好ましくは、第１の態様の方法は、クラスタード・コンピュータ・システムの準備処理を行った後にリソース・アクションを実行するステップをさらに含む。

好ましくは、リソース・アクションを実行するステップは、リソース復旧処理を実行するステップを含む。

好ましくは、リソース・アクションは、仮想アドレス範囲、クラスタ・オブジェクト数、直接アクセス・ストレージ装置（ＤＡＳＤ）数、およびこれらの組合せからなる群から選択されるリソースの復旧を含む。

好ましくは、複数のクラスタ・エンティティは、複数のノードと複数のノードに存在する複数のクラスタ・オブジェクトとを含み、リソース復旧アクションを実行するステップが、（ａ）クラスタード・コンピュータ・システム内の複数のノードに問い合せて、複数のリソースの中のどれに所有者があるか判断するステップと、（ｂ）所有者のないリソースの所有権を複数のノードの中の第１のノードに移転させるステップとを含む。

好ましくは、クラスタード・コンピュータ・システムの準備処理を行うステップは、クラスタ構成パラメータの変更に先立ち、クラスタード・コンピュータ・システム上でロックを獲得するステップを含む。

好ましくは、第１の態様の方法は、リソース・アクションを実行した後にロックを解除するステップをさらに含む。

好ましくは、クラスタ構成パラメータは、値の対を含み、クラスタ構成パラメータを変更するステップが値の対の中の各値を順次に変更するステップを含む。

好ましくは、クラスタード・コンピュータ・システムの準備処理を行うステップは、クラスタ・プロトコルを開始するステップを含む。

好ましくは、クラスタード・コンピュータ・システムの準備処理を行うステップは、リソース・アクションがその上で実行されるリソースを所有できる消失クラスタ・エンティティを検出するステップを含む。

本発明は、（ａ）メモリと、（ｂ）複数のリソースと、（ｃ）メモリに存在し、複数のリソースを所有するように構成された複数のクラスタ・エンティティと、（ｄ）少なくともクラスタード・コンピュータ・システム内の複数のリソースのサブセット上でリソース・アクションを実行するように構成され、クラスタード・コンピュータ・システムの準備処理の最中にアクティブであるクラスタ・エンティティは、クラスタ構成パラメータの変更を受け入れ、クラスタード・コンピュータ・システムの準備処理の最中に非アクティブであるクラスタ・エンティティは、クラスタ構成パラメータの変更を受け入れないように、クラスタード・コンピュータ・システム内の複数のクラスタ・エンティティに関係付けられた少なくとも１つのクラスタ構成パラメータを変更することにより、リソース・アクションの実行に先立ち、クラスタード・コンピュータ・システムの準備処理を行い、それによって、そのような非アクティブ・クラスタ・エンティティが後でクラスタード・コンピュータ・システム中に受け入れられないようにするプログラムとを含む装置を提供する。

好ましくは、複数のクラスタ・エンティティは、複数のクラスタ・ノードと複数のクラスタ・オブジェクトとを含む。

好ましくは、クラスタ構成パラメータは、複数のクラスタ・ノードの各々に格納されたクラスタ識別子と、複数のクラスタ・オブジェクトの各々に関係付けられたオブジェクト識別子と所有権移転カウントとを含む。

好ましくは、プログラムは、クラスタード・コンピュータ・システム内の複数のノードに問い合せて、複数のリソースの中のどれに所有者があるかを判断し、所有者のないリソースの所有権を複数のノードの中の第１のノードに移転させることにより、リソース復旧アクションを実行するように構成される。

好ましくは、プログラムは、仮想アドレス範囲、クラスタ・オブジェクト数、直接アクセス・ストレージ装置（ＤＡＳＤ）数、およびこれらの組合せからなる群から選択されるリソースでリソース復旧処理を実行することにより、リソース・アクションを実行するように構成される。

好ましくは、プログラムはさらに、クラスタ構成パラメータの変更に先立ちクラスタード・コンピュータ・システム上でロックを獲得し、リソース・アクション実行の後でロックを開放することにより、クラスタード・コンピュータ・システムの準備処理を行うように構成される。

好ましくは、クラスタ構成パラメータは値の対を含み、プログラムは値の対の中の各値を順次に変更することにより、クラスタ構成パラメータを変更するように構成される。

好ましくは、プログラムはさらに、クラスタ・プロトコルを開始することにより、クラスタード・コンピュータ・システムの準備処理を行うように構成される。

好ましくは、プログラムはさらに、リソース・アクションがその上で実行されるリソースを所有できる消失クラスタ・エンティティを検出することにより、クラスタード・コンピュータ・システムの準備処理を行うように構成される。

本発明は第２の態様として、（ａ）互いにネットワークを介して結合された複数のノードと、（ｂ）複数のリソースと、（ｃ）複数のリソースを所有するように構成された複数のクラスタ・エンティティと、（ｄ）複数のノードの中の第１のノードに常駐するプログラムであって、少なくとも複数のリソースのサブセット上でリソース・アクションを実行するように構成され、クラスタード・コンピュータ・システムの準備処理の最中にアクティブであったクラスタ・エンティティは、クラスタ構成パラメータの変更を受け入れ、クラスタード・コンピュータ・システムの準備処理の最中に非アクティブであったクラスタ・エンティティは、クラスタ構成パラメータの変更を受け入れないように、複数のクラスタ・エンティティに関係付けられた少なくとも１つのクラスタ構成パラメータを変更することにより、リソース・アクションの実行に先立ち、クラスタード・コンピュータ・システムの準備処理を行い、それによって、そのような非アクティブ・クラスタ・エンティティが後でクラスタード・コンピュータ・システム中に受け入れられないようにするプログラムとを含むクラスタード・コンピュータ・システムを提供する。

本発明は第３の態様において、コンピュータ・システムにロードされ実行されたときに、第１の態様による方法のすべてのステップを実行するためのコンピュータ・プログラム・コードを含むコンピュータ・プログラムを提供する。

第３の態様の好ましい特徴は、第１の態様の好ましいステップに対応するステップを実行するためのコンピュータ・プログラム・コード要素を含む。

好ましくは、本発明は、（ａ）複数のリソースと複数のリソースを所有するように構成された複数のクラスタ・エンティティとを含むタイプのクラスタード・コンピュータ・システム内でリソース・アクションを実行するように構成され、クラスタード・コンピュータ・システムの準備処理の最中にアクティブであるクラスタ・エンティティは、クラスタ構成パラメータの変更を受け入れ、クラスタード・コンピュータ・システムの準備処理の最中に非アクティブであるクラスタ・エンティティは、クラスタ構成パラメータの変更を受け入れないように、クラスタード・コンピュータ・システム内の複数のクラスタ・エンティティに関係付けられた少なくとも１つのクラスタ構成パラメータを変更することにより、リソース・アクションの実行に先立ち、クラスタード・コンピュータ・システムの準備処理を行い、それによって、そのような非アクティブ・クラスタ・エンティティが後でクラスタード・コンピュータ・システム中に受け入れられないようにするプログラムと、（ｂ）そのプログラムを搬送する信号搬送媒体とを含むプログラム製品を提供する。

好ましくは、信号搬送媒体は、記録可能媒体と伝送媒体の少なくとも一方を含む。

実施形態は好ましくは、複数のノードと複数のノードの少なくとも一部に存在する複数のクラスタ・オブジェクトとを含むタイプのクラスタード・コンピュータ・システム内のリソース上でリソース・アクションを実行するための方法であって、複数のノードおよび複数のクラスタ・オブジェクトは各々がリソースを所有でき、（ａ）複数のノードの中の各アクティブ・ノードでロックを獲得するステップと、（ｂ）複数のノードの中の各アクティブ・ノード用のノード構成パラメータを変更することで、複数のノードの中の非アクティブ・ノードが後でクラスタード・コンピュータ・システム中に受け入れられないようにするステップと、（ｃ）リソースを所有できる各アクティブ・クラスタ・オブジェクト上のオブジェクト構成パラメータを変更することで、リソースを所有できる非アクティブ・クラスタ・オブジェクトが後でクラスタード・コンピュータ・システム中に受け入れられないようにするとともに、非アクティブ・ノードがアクティブ・クラスタ・オブジェクトを受け取らないようにするステップと、（ｄ）ロックを獲得し、ノードおよびオブジェクト構成パラメータを変更した後、リソース上でリソース・アクションを実行するステップと、（ｅ）リソース・アクションを実行した後、各アクティブ・ノード上でロックを解除するステップとを含む方法を提供する。

このような実施形態の方法は、リソースを所有できるすべてのクラスタ・オブジェクトがアクティブであるかどうか判断するステップをさらに含むこともできる。

本発明の実施形態は、装置、クラスタード・コンピュータ・システム、プログラム製品、および独自な準備処理を用いる方法を提供することにより、従来技術に付随する問題に対処する。この準備処理は、ノードやクラスタ・オブジェクトなどの消失または非アクティブ・クラスタ・エンティティがリソース・アクションの後で、クラスタード・コンピュータ・システムに再び加入しないように効果的に「ロックアウト」するリソース・アクションに関する。こうすることによって、非アクティブ・クラスタ・エンティティが再びアクティブとなり、クラスタード・コンピュータ・システム内の他のクラスタ・エンティティに移転されたかもしれないリソースを利用しようと試みる、リソース衝突を潜在的に生み出す危険性を最小限に抑える。

例示の実施形態において、準備処理は、クラスタード・コンピュータ・システム内の複数のエンティティに関係付けられた１つまたは複数のクラスタ構成パラメータの変更を含み、それによって、準備処理の最中にアクティブであるクラスタ・エンティティは変更を受け入れ、準備処理の最中に非アクティブであるクラスタ・エンティティは変更を受け入れないようになる。さらに、例示の実施形態においては一般に、先に非アクティブであったクラスタ・エンティティがアクティブになろうと試みたり、クラスタリングに再び加入しようと試みたりすると、そのようなエンティティ用の不正または失効クラスタ構成パラメータが検出され、それによって、そのようなクラスタ・エンティティがクラスタード・コンピュータ・システム中に受け入れられないよう効果的に阻止する。

本発明による様々な実施形態でも、様々なノードに関係付けられたノード構成パラメータの変更および様々なクラスタ・オブジェクトに関係付けられたオブジェクト構成パラメータの変更に先立つ、クラスタード・コンピュータ・システム内の各ノード上でのロックの獲得が取り入れられている。変更が完了したときロックは解除され、当該リソースを所有できる非アクティブ・ノードまたはクラスタ・オブジェクトあるいはその両方が後でクラスタード・コンピュータ・システム中に受け入れられないようにする。

次に本発明の好ましい実施形態を、添付の図面を参照し、例としてのみ説明する。

以下、本明細書で説明する実施形態では、リソース・アクションの実行に関連する準備処理を利用して、システム内でリソースの所有権が変更された後、消失または非アクティブ・クラスタ・エンティティをクラスタード・コンピュータ・システムに受け入れないよう効果的に「ロックアウト」する。影響を受けるタイプのクラスタ・エンティティに関係付けられた１つまたは複数のクラスタ構成パラメータを、準備処理の最中に変更し、そのようなクラスタ・エンティティの中のアクティブ・インスタンスのみが、変更を受け入れるようにする。そのようなクラスタ・エンティティの中の非アクティブ・インスタンスは、変更を受け入れないようにし、それにより、それらの非アクティブ・クラスタ・エンティティがその後、アクティブになろうと試みたり、クラスタリングに再加入しようと試みたりしても、無効パラメータのため失敗するようにする。

本明細書においてリソースとは一般に、処理タスクを実行するために必要とされるある種の実体または「もの」のことであり、そのようなものは限られた数だけ存在し、そのようなものが利用されるためにはそれが「所有」される必要がある。クラスタ・エンティティとは一般に、クラスタリングで利用される論理ソフトウェア構成体のことであり、リソースを「所有」すること、すなわち、処理の中でリソースを利用または管理あるいはその両方を行うことができる。

例示の実施形態では、例えば、クラスタ・エンティティは、クラスタ・ノード（すなわち、マルチノード・クラスタにおいて「ノード」として機能する、個々のコンピュータ・システムまたはそれらのシステム内に存在する論理パーティション、あるいはその両方）またはクラスタ・オブジェクト（すなわち、クラスタリングへの加入またはクラスタ管理の支援、あるいはその両方を行う、クラスタード・コンピュータ・システム内の論理エンティティ）、あるいはその両方を含むことができる。例えば、以下、本明細書で論じる実施形態では、クラスタ・オブジェクトは、直接アクセス・ストレージ装置（ＤＡＳＤ）など、単一の論理装置として集団で管理されアクセスされる１組またはグループの入出力（Ｉ／Ｏ）装置を表すことができる。

さらに、例示の実施形態では、仮想アドレスまたは仮想アドレス範囲、および入出力（Ｉ／Ｏ）装置その他のリソースを、本明細書で説明する方式によって管理する。より具体的には、そのようなリソースを一般に、識別子によって表し、リソースを所有するには、ある特定の識別子と特定のクラスタ・エンティティとを関係付ける。したがって、例えば、仮想メモリ空間内のアドレス範囲は、範囲の境界アドレスによって表すことができ、ＤＡＳＤなどのＩ／Ｏ装置は、そのような装置に関係付けられた一意の識別子または番号によって表すことができる。さらに、例示の実施形態では、クラスタ・オブジェクトは、他のリソースを所有できるクラスタ・オブジェクトそれ自体が一般に、クラスタ・ノードに所有される限りにおいて、クラスタ・エンティティおよびリソースの両方であると考えてよい。そのような例では、クラスタ・オブジェクトは、所有者であるクラスタ・ノードに関係付けられた、オブジェクト識別子など一意の識別子によって表すことができる。

クラスタ構成パラメータは、クラスタ・ノードやクラスタ・オブジェクトなどのクラスタ・エンティティに関係付けて維持管理される任意のデータを表すことができ、クラスタ・エンティティの特定のインスタンスがリソース・アクション以前にアクティブであったかどうか検出するために使用することができる。単にエラーを通知するため、またはエンティティがクラスタに再加入することを防止するため、あるいはその両方のために、クラスタ構成パラメータのステータスを検出してもよい。あるいは、クラスタ・エンティティにクラスタへの再加入を許可する前に、リソースを適切に解放させる復旧処理を実行するために、検出パラメータを使用することもできる。

例示の実施形態では、例えば、クラスタ・ノードと関係付けて使用されるクラスタ構成パラメータは、クラスタ識別子（ＣＩＤ）であり、これは、クラスタの特定インスタンス内のアクティブ・ノードすべてが共有する共通「トークン」または一意の識別子として使用される。次に、クラスタに加入しようと試みる特定ノード用のＣＩＤを検証するために、クラスタ内のクラスタ管理ソフトウェアが必要とされる。これがないと、クラスタ・ノードは、クラスタへの加入を拒否され阻止される。一般にＣＩＤは、認可されたノードのみにクラスタへの加入を許可するためのセキュリティ機構として、リソース管理の外部で使用される。したがって、通常は、本明細書で説明する機能を実施するために、クラスタード・コンピュータ・システム内のノード管理ルーチンを変更する必要はない。

クラスタ・オブジェクトの場合、使用されるクラスタ構成パラメータは、各クラスタ・オブジェクト内で維持管理される、所有権移転カウント（ＯＴＣ）などのオブジェクト構成パラメータであり、これをクラスタ・オブジェクト識別子と関係付けて選択的に使用することができる。

本発明の好ましい実施形態によれば、非アクティブ・クラスタ・エンティティのクラスタへの再加入を阻止するために、他のパラメータも使用できることを理解されたい。さらに、リソースのタイプによっては、あるタイプのエンティティのみがそれを所有し得、本明細書で論じる準備処理が、処理対象の特定タイプのリソースと関係するあるタイプのエンティティにのみ影響を及ぼし得ることを理解されたい。したがって、本発明の実施形態は、本明細書で説明する特定の実施形態に限定されるものではない。

次に図面（複数の図面にわたり同一番号は同一部分を示す）を参照すると、図１には、ネットワーク構造５を介して互いに接続された複数のノード４を含む、クラスタード・コンピュータ・システム２が示されている。本発明の好ましい実施形態によれば、クラスタード・コンピュータ・システムで一般に利用されるネットワーク・トポロジ、例えば、高速ポイント・ツー・ポイント・バスまたはリンク、ローカル・エリア・ネットワーク、ワイド・エリア・ネットワーク、インターネットなどの公共ネットワーク、およびそれらの組合せを、任意の数だけ使用することができる。さらに、個々のノード４は、当技術分野で周知なように、他のノードと物理的に近い場所に配置してもよく、他のノードから地理的に離れていてもよい。

一般にクラスタード・コンピュータ・システムには、Ｉ／Ｏ装置７などの、１つまたは複数のＩ／Ｏ装置も組み込まれ、それらと個々のノードをネットワーク構造５を介して相互接続することができる。さらに、場合によっては、ネットワーク構造５を介した装置７へのアクセスを、ネットワーク構造と直接結合された装置７の代りに、中間ノードによって管理してもよい。様々なＩ／Ｏ装置、例えば、ＤＡＳＤ、ワークステーション、ストレージ・コントローラ、ワークステーション・コントローラ、ネットワーク・アダプタ、プリンタ、ディスプレイなどが企図されている。

本発明の好ましい実施形態によれば、複数のクラスタ・エンティティが、クラスタード・コンピュータ・システム２に存在している。例として、複数のノード４（またノードＡ〜Ｅとして別々に示す）が示されている。したがって、本明細書でクラスタＩＤ（ＣＩＤ）７と呼ばれるクラスタ構成パラメータは、各ノード内で維持管理される。複数のクラスタ・オブジェクト８（例示的な数のオブジェクトをＯ１〜Ｏ４として別々に示す）も図１に示されており、その各々はクラスタ構成パラメータ（図１に図示せず）を含んでいる。

上述した様々なクラスタ・エンティティは、複数のリソース９を管理および利用するように構成される。図１では、例示的な数のそのようなリソースをリソースＲ１〜Ｒ５として別々に指定する。上述したクラスタ・エンティティがそのようなリソースを所有および管理する方式を、以下、図３〜図８に関して詳細に説明する。

次に図２に移ると、クラスタード・コンピュータ・システム２内のノード４の１つの例示的なハードウェア構成が示されている。ノード４は一般に、ネットワーク・サーバ、ミッドレンジ・コンピュータ、メインフレーム・コンピュータ、例えば、インターナショナル・ビジネス・マシーンズ・コーポレーションから市販のＡＳ／４００またはｉＳｅｒｉｅｓミッドレンジ・コンピュータ・システムなど、複数のマルチユーザ・コンピュータのいくつかを表す。しかし、他のコンピュータおよびデータ処理システム、例えば、ワークステーション、デスクトップ・コンピュータ、ポータブル・コンピュータその他などの、スタンドアロンまたはシングルユーザ・コンピュータでも、または他のプログラム可能電子装置（例えば、組込みコントローラその他）でも、本発明の実施形態を実施できることを理解されたい。

ノード４は一般に、キャッシュ・システム１６内に配置された１または複数レベルのキャッシュ・メモリを介して主記憶装置１４に結合された、１つまたは複数のシステム・プロセッサ１２を含む。さらに、主記憶装置１４は、システム入出力（Ｉ／Ｏ）バス１８、および複数のインタフェース装置、例えば、１つまたは複数の外部ネットワーク（例えば、ネットワーク２６）、１つまたは複数のワークステーション２８、または直接アクセス・ストレージ装置（ＤＡＳＤ）３０など１つまたは複数のストレージ装置、あるいはそれらのいくつかへの外部アクセスをそれぞれ提供する、入出力アダプタ２０、ワークステーション・コントローラ２２、ストレージ・コントローラ２４を介して、複数のタイプの外部装置に結合される。代替方法では、任意の数の別のコンピュータ・アーキテクチャを使用してよい。

ＡＳ／４００環境で本明細書に記載のクラスタリング機能を実施するため、クラスタ内の各ノードは一般に、システム・ライセンス内部コード（ＳＬＩＣ）３２に分割されるシステム・プログラム・コードと、マシン・インタフェース３４と、オペレーティング・システム３６とを含む。その各々は主記憶装置１４に存在するものとして示されているが、それらは一般に、当技術分野で周知の仮想メモリ管理システムを実際に使用する主記憶装置に選択的にページインされ、またページアウトされる。タスクは、基本的なシステム・プログラム・コードを利用してタスクを実行する１つまたは複数のジョブまたはアプリケーション３８によって、ユーザに代って実行される。

ＳＬＩＣ３２の一部は一般に、ストレージ管理ブロック４０で表される管理メモリおよび外部ストレージに割り当てられる。さらに、クラスタリング環境で利用される場合、ノード４は一般に、ノード上のクラスタリング関連処理を管理するための、クラスタリング・リソース・サービス４２と呼ばれるクラスタリング・インフラストラクチャを実行する。さらに、クラスタリングでは、ジョブ３８の１つであり、クラスタ管理グループに加入して、ノードの代りにクラスタリング機能の管理を支援する、クラスタ制御（ＣＴＬ）ジョブの実行が必要になることがある。本明細書に記載するリソース管理機能の多くが実施されるのは、これらのプログラム内においてである。

しかし、本明細書で説明する機能は、ノード４内の他レイヤのソフトウェアで実施することができ、この機能は、クラスタード・コンピュータ・システム２内の他のプログラム、コンピュータ、またはコンポーネントの間に割り当てることができることを理解されたい。特に非ＡＳ／４００環境では、システム・プログラム・コードもクラスタリング・インフラストラクチャも、プログラム・コードの他レイヤで実施できる。さらに、他のクラスタリング環境では一般に、クラスタリング・インフラストラクチャおよびクラスタ制御グループと類似の機能を利用する。したがって、本発明の実施形態は、本明細書で説明する特定のソフトウェアによる実施に限定されるものではない。

以下、本明細書の議論では、上述のリソース管理機能を実施するために利用される特定のルーチンに焦点を当てる。本発明の実施形態を実施するために実行されるルーチンも、オペレーティング・システムの一部として実施されるにしても、あるいは特定のアプリケーション、コンポーネント、プログラム、オブジェクト、モジュール、命令シーケンスとして実施されるにしても、本明細書では「コンピュータ・プログラム」または単に「プログラム」と呼ぶ。コンピュータ・プログラムは一般に、様々な時にコンピュータ内の様々なメモリおよびストレージ装置に置かれる１つまたは複数の命令を含み、コンピュータ内の１つまたは複数のプロセッサに読み込まれ実行されたとき、本発明の様々な態様を実施するステップまたは要素を実行するのに必要なステップをそのコンピュータに実行させる。さらに、本明細書では、十分な機能を有するコンピュータおよびコンピュータ・システムを想定して、本発明の実施形態をこれまで説明し今後も説明するが、本発明の様々な実施形態が様々な形態のプログラム製品として配布でき、その配布を実際に実施するのに用いられる特定のタイプの信号搬送媒体とは無関係に、等しく本発明が適用できることは、当業者であれば理解されるであろう。信号搬送媒体の例としては、とりわけ揮発性および不揮発性メモリ装置、フロッピその他の着脱可能ディスク、ハードディスク・ドライブ、光ディスク（例えば、ＣＤ−ＲＯＭ、ＤＶＤなど）などの記録可能型媒体、ならびにデジタルおよびアナログ通信リンクなどの伝送型媒体が挙げられるが、それだけに限定されるものではない。

以下本明細書で説明する様々なプログラムが、本発明の具体的な実施形態においてそれらのプログラムを実施する適用分野に基づいて区別できることは理解できよう。しかし、以下で用いられる特定のプログラムに関連する用語は、便宜上使用するにすぎず、したがって、そのような用語が区別または暗示しあるいはその両方を行う特定の適用分野のみでの使用に本発明が限定されるものでないことを理解されたい。

次に上述したリソース管理機能の例示的な実施形態に話を移すと、上述のシステムで、リソース復旧またはリソースの所有権移転などのリソース・アクションが正確かつ完全であることを保証するには、４つの条件を満足すべきであることがわかる。

・すべてのクラスタ・ノードが、存在して（present）いなければならず、リソース・アクションの実行中に非アクティブなまたは消失中のクラスタ・ノードを、後でクラスタ中に受け入れることはできない。

・クラスタ・ノード間でのリソース移転を、リソース・アクションと並行して行うことはできない。

・特定のリソースを所有することのできるすべてのクラスタ・オブジェクトが、存在していなければならず、リソース・アクションの実行中に非アクティブなまたは消失中のクラスタ・オブジェクトを、後でクラスタ・ノード中に受け入れることはできない。

・クラスタ・ノードとクラスタ・オブジェクトとの間でのリソース移転を、リソース・アクションと並行して行うことはできない。

以下、本明細書で説明する実施形態では、これらの条件を満足させるため、リソース・アクションに関連し、その前に行われる独自の準備処理を用いて、以下の処理を実行する。

・すべてのクラスタ・ノードがアクティブであることを保証するために、すべてのクラスタ・ノードを直列化（serialize）し、また、リソースの移転を防止し、ノードがクラスタから離脱またはクラスタへ加入するのを防止し、クラスタ・オブジェクトの生成または削除を防止するために、各クラスタ・ノード上でロックを獲得する。妥当な時間内にロックを獲得できない場合、準備処理は失敗し、リソース・アクションの実行は阻止される。

・クラスタ・ノードを互いに結び付けている一意的な識別子を変更し、それによって、非アクティブなクラスタ・ノードを後で、クラスタ中に受け入れられなくする。

・特定のリソースを所有できるすべてのクラスタ・オブジェクトが存在していることを保証する。さもなければ、準備処理は失敗する。

・そのようなすべてのクラスタ・オブジェクト用の構成データ（例えば、クラスタ・オブジェクト識別子）を変更し、それによって、非アクティブなクラスタ・オブジェクトを後で、クラスタ中に受け入れられなくし、非アクティブなノードが後で、アクティブなクラスタ・オブジェクトを受け入れられなくする。

次に図３には、本発明の好ましい実施形態によるリソース管理に関連する、例示的な１組のクラスタ・エンティティが、それらの各エンティティ内で維持管理される関連するデータ構造と共に示されている。例えば、各々が構成データ５０を含む１対のノード４が示されており、構成データは、クラスタＩＤ（ＣＩＤ）５２と既知のオブジェクトＩＤ用の表またはリスト５４とを含む。オブジェクトＩＤは、クラスタード・コンピュータ・システム内に存在することが知られている様々なクラスタ・オブジェクトに関係付けられたハンドルまたはトークンを表す。さらに、各ノード４は一般に、例えば、仮想アドレス範囲、オブジェクト番号、ＤＡＳＤユニット番号を含めて、所有するリソースのリスト５６を維持管理する。例示の実施形態では、オブジェクトは、それぞれ一意にオブジェクトを識別する識別子と番号を含む。しかし、他の実施形態では、各オブジェクトを識別するために、単一の一意な識別子を使用してもよい。

図３にはまた、構成データ６０と所有者のあるリソースのリストまたは表６２とを含む、例示的なクラスタ・オブジェクト８も示されている。構成データは、例えば、クラスタ・オブジェクトに関係付けられたオブジェクトＩＤ６４と、そのオブジェクト用の所有権移転カウント（ＯＴＣ）６６を含む。さらに、そのクラスタ・オブジェクトに関係付けられた所有リソースには、様々な仮想アドレス範囲や、そのクラスタ・オブジェクト用のオブジェクト番号が含まれ得る。クラスタ・オブジェクトは、例えば、ＡＳ／４００ベースのクラスタード・コンピュータ・システムに結合されたＩ／Ｏタワー内で実装される、１つまたは複数のＤＡＳＤユニットを表す。したがって、例えば、クラスタ・オブジェクトは論理的に、複数の入出力アダプタ（ＩＯＡ）や、１つまたは複数の入出力プロセッサ（ＩＯＰ）を含めて、１つまたは複数のＤＡＳＤユニットに対するインタフェース・チェーン内の様々な階層の装置を表すことができる。さらに、所有リソースには、クラスタ・オブジェクトが所有する１つまたは複数のＤＡＳＤユニットの識別が含まれ得る。

例示の実施形態では、各ノード４について追跡（track）されるクラスタ構成パラメータは、ＣＩＤ５２であり、各クラスタ・オブジェクトについて追跡されるクラスタ・パラメータは、オブジェクトＩＤ６４と一般に各リソース・アクションの最中に変更されるＯＴＣ６６との組合せである。

次に図４には、本発明の好ましい実施形態によるリソース・アクションを実施するための例示的なルーチン７０が示されている。先に論じたように、リソース・アクションには一般に、例えば、アクション準備ルーチン７２によって実行される先行するアクション準備処理が含まれる。ルーチン７２は、処理が正常に実行されたかどうかを示す結果を返す。正常に実行されなかった場合、リソース・アクションは、制御をブロック７４から、ブロック７６に渡し、その結果、エラーが返されて早々に終了する。しかし、アクション準備が正常に実行された場合、ブロック７４は制御をブロック７８に渡して、望ましいリソース・アクションが実行される。

ある実施形態では、１回の準備処理に続いて、複数のリソース・アクションを実行するのが望ましいこともある。例えば、任意選択のルーチン８２で表されるように、１つまたは複数の追加のリソース・アクションを実行するのが望ましいかもしれない。さらに、後続のリソース・アクションを実行する前に、任意選択のブロック８０で表されるように、先行するリソース・アクションの結果を問い合せるのが望ましいかもしれない。準備アクションが正常に実行されたかにかかわらず、また１つまたは複数のリソース・アクションが試みられたかにかかわらず、準備アクションの結果としてクラスタード・コンピュータ・システムに設定されたロックを解除するために、一般にアクション終了ルーチン８４が実行される。アクション終了ルーチン８４が完了すると、ブロック８６に示すように、適切な結果が呼出し元ルーチンに返される。以下でより詳細に論じるルーチンの進行次第で、この結果はエラーまたはエラー無しを示すことができる。

図５には、アクション準備ルーチン７２がより詳細に示されている。ルーチン７２は一般に、リソース・アクションの実行が必要であると判断された場合に、クラスタード・コンピュータ・システム内のノードによって呼び出される。例えば、リソース消失または特定のノード上でのリソース減少の検出に応答して、クラスタード・コンピュータ・システム内のそのノードが、リソース・アクションを起動することができる。

ルーチン７２はブロック１００から開始し、ノードが適切なクラスタリング環境にあるかどうかなど様々なチェックを行い、環境が準備処理を行うのに有効かどうか判断する。有効でなければ、ブロック１００は制御をブロック１０２に渡して、エラー状態が返され、リソース・アクションは終了する。

その他の場合は、ブロック１００は制御をブロック１０４に渡して、ローカル・サンドボックスを生成し、したがってノード上でのローカル・ロックを獲得する。この文脈におけるサンドボックスとは、ノード用のワークスペースを生成し、ノードの動作を直列化するソフトウェア・オブジェクトのことである。一般に、１つのノード上では所与の時間に、１つのサンドボックスしか実行できず、さらに、サンドボックス内でのクラスタに対する変更は、サンドボックスの終了時にそれらの変更がクラスタに対して確定する前に、コミットし完了しなければならない。サンドボックスが生成されるとその結果、クラスタ・オブジェクトを生成または削除できず、リソースの所有権を変更できず、ノードをクラスタード・コンピュータ・システムに（ローカル・ノードから見て）追加できず、また削除できない範囲で、ノードが直列化されることになる。しかし、本発明の好ましい実施形態によるローカル・ノードの動作を直列化するために、他の形態のロックまたはセマフォを利用することができることを理解されたい。

ブロック１０４が完了すると、ブロック１０６で、ローカル・サンドボックスの生成が成功したかどうか判断が行われる。成功しなかった場合、制御はブロック１０２に渡されて、ルーチン７２は終了する。成功した場合、制御はブロック１０８に渡されて、ローカル・ノードがスタンドアロン・モードであるか、クラスタリングに加入していないかどうかが状況に応じて判断される。スタンドアロン・モードの場合、制御はブロック１１０に渡されて、スタンドアロン準備処理が実行され、次にブロック１１２に渡されて、その準備処理の結果が返される。スタンドアロン準備処理は、例えば、ノード上で構成されているすべてのクラスタ・オブジェクトが所有されアクティブであることを検証し、消失クラスタ・オブジェクトをロックアウトするように必要に応じてクラスタ・オブジェクト構成データを更新することにより、実施することができる。一般にスタンドアロン構成では、クラスタリング環境準備に関連して以下本明細書で説明するノード関連の機能の多くは、省略することができるが、クラスタリング環境の他のノードが削除されたためにノードがスタンドアロン・モードになった場合など、環境によっては、同様の機能を利用するのが望ましいこともある。

ブロック１０８に話を戻すと、ノードがスタンドアロン・モードでない場合、制御はブロック１１４に渡されて、準備処理が既存のクラスタ・プロトコル内で実行されているかどうか判断が行われる。具体的には、リソース・アクションは、クラスタ・プロトコル内で、あるいはクラスタ・プロトコルから切り離して実行することができ、複数のリソース・アクションを単一のクラスタ・プロトコル内で実行することができる。例示の実施形態では、ノードが互いに通信して、準備アクションおよびリソース・アクションを確実に完了させられるように、クラスタ・プロトコルはリソース・アクションの前に起動しなければならない。したがって、クラスタ・プロトコルがまだ確立（establish）されていない場合、ブロック１１４は制御をブロック１１６に渡して、クラスタ・プロトコルを開始し、ノード間の通信を開始する。ブロック１１８は次に、プロトコル開始の試みが成功したかどうか判断する。成功しなかった場合、ブロック１１８はアクション終了ルーチン８４（以下で論じる）または同様の機能を有する他のルーチンを呼び出し、それによって、エラーが生成され、そのエラーが準備処理の結果として返される。

しかし、クラスタ・プロトコル開始の試みが成功した場合は、制御はブロック１１８からブロック１２０に渡されて、他のノード上でサンドボックスを開始させ、したがって他の各ノード上でロックを獲得する。さらに、ブロック１１４に話を戻すと、クラスタ・プロトコルがすでに存在している場合は、制御は直接ブロック１２０に渡される。

他の各ノード内でサンドボックスを開始することにより、各ローカル・ノード上でローカル・サンドボックスが生成される。一般に、他の各ノードがサンドボックスを生成し、適切な応答を返すのを待つために、第１のノード内で何らかの遅延が利用される。定められた時間内に適切な応答が返されなかった場合、ブロック１２２は準備処理が失敗したと判断し、したがって制御をアクション終了ルーチン８４に渡して、準備処理を終了させる。さらに、あるノードがアクティブでないのに、サンドボックスを開始させるためのメッセージが送られた場合、そのノードは適切な時間内に応答を返さないので、準備処理は失敗する。したがって、他のノード上でサンドボックスを開始させる処理により、システム上のすべての既知ノードがアクティブかどうか効果的な判断が行える。

サンドボックスの生成が成功した場合、制御はブロック１２２からブロック１２４に渡されて、他のノードに対し消失クラスタ・オブジェクトについての問合せを行う。例示の実施形態では、他の各ノードに問合せを送って、既知の各オブジェクト（図３の既知オブジェクトＩＤのリスト５４に格納されている）に所有者があるかどうか判断することにより、ブロック１２４を実施する。ブロック１２６は次に、消失オブジェクト（所有者がいないオブジェクト）が存在するかどうか判断する。消失オブジェクトが存在する場合、制御はルーチン８４に渡され、準備処理は終了する。そうでない場合は、制御はブロック１２８に渡されて、各クラスタ・ノード用の構成パラメータを更新するＣＩＤ変更ルーチンが実施される。

例示の実施形態では、他のノード上でのサンドボックスの開始、および消失オブジェクトについての問合せその他の処理は、リソース・アクションに伴って開始されるクラスタ・プロトコルによって、順序付けられたメッセージを用いて実施される。したがって、例えば、他のノード上でサンドボックスを開始させるための要求は、各ノードに送信されるメッセージの形をとり、各ノードは、各ノード上でサンドボックスが正常に開始されたかどうか通知するために応答メッセージを送り返す。同様に、消失クラスタ・オブジェクトについての問合せも、当該クラスタ・オブジェクトを識別するために各ノードに送信されるメッセージの形をとる。各ノードは次にメッセージに応答して、そのノードがそのオブジェクトを所有しているかどうか通知する。したがって、オブジェクトの所有権を通知して来ないメッセージを応答ノードから受信することよってのみ、消失オブジェクトを検出することができる。

ＣＩＤ変更ルーチン１２８は、各アクティブ・ノードに関係付けられたクラスタ識別子は変更し、非アクティブ・ノードでは同様に更新せず、それによって、非アクティブ・ノードが準備処理の後でクラスタリングに加わることを阻止するために用いられる。

ルーチン１２８は結果を返し、その結果はブロック１３０で照会される。変更が正常に実行されなかった場合、ルーチン８４が呼び出され、準備処理は失敗する。変更が正常に実行された場合、制御はブロック１３２に渡され、非アクティブなクラスタ・オブジェクトがクラスタに再加入することをロックアウトするために、様々な当該クラスタ・オブジェクト用のクラスタ・オブジェクト・パラメータが変更される。特定のタイプのリソース上で特定のタイプのリソース・アクションに関連して準備処理が実行された場合、そのタイプ（例えば、仮想アドレス範囲か、ＤＡＳＤユニット番号）のリソースを所有するクラスタ・オブジェクトのみが変更可能であることを理解されたい。クラスタ・オブジェクト・パラメータの変更には一般に、オブジェクトを所有するノードやすべての追加ノードへのメッセージ送信が含まれ、各ノードは、そのノードに固有のオブジェクト構成パラメータのデータを更新できる。しかし、クラスタ・オブジェクトを所有するノードはさらに、そのクラスタ・オブジェクトに固有の情報を変更する。

ルーチン１３２は同様に結果を返し、その結果はブロック１３４で照会される。変更処理が正常に実行されなかった場合、アクションを終わらせ、準備処理を終了させるため、制御はルーチン８４に渡される。変更処理が正常に実行された場合、ブロック１３６に表すように、「エラー無し」状態を返すことにより、正常終了が通知される。

クラスタ構成パラメータの変更は、パラメータに関係付けられた単一の値を単に変更することによって実行することができ、一般に、その変更が関連するすべてのクラスタ・エンティティに確実に伝わるように、順序付けられたメッセージが利用される。別の方法では、各クラスタ構成パラメータ用の、現在の値と「なる（to become）」値とを表す複数の値を利用するのが望ましいかもしれない。パラメータを変更する場合、最初に「なる」値が新しい値に変更され、次に正規のコピーが新しい値に変更される。したがって、プロセスがある箇所で失敗したとしても、すべてのノードは依然、少なくとも一方の値でマッチさせることができる。

値の対を用いてクラスタＩＤまたはクラスタ・オブジェクト・パラメータを変更するのに使用することができる例示的なルーチンが、図６のＩＤ変更ルーチン１４０により示されている。「ＩＤ」の参照は、変更される個々のクラスタ構成パラメータ次第で、クラスタＩＤまたはクラスタード・オブジェクト・パラメータのいずれかの参照でよいことを理解されたい。

ルーチン１４０はブロック１４２から開始され、各ノードに格納されている現在のＩＤ対の値について問い合せる。一般にブロック１４２は、順序付けられたメッセージを用いて実施され、各ノードは、要求に応答して特定のパラメータの現在の値で応答する。

ブロック１４４は次に、第１の値が同期しているか、すなわち、各ノードに同一の第１の値が格納されているかどうか判断する。同期していない場合、制御はブロック１４６に渡されて、各ノード上の第１の値は、ルーチン１４０が実行されているノードによって選択された任意の値に設定される。設定処理もまた、順序付けられたメッセージによって実行され、その結果、各ノードが値の更新に成功したかを確認するため、適切な応答メッセージを待つ。したがって、ブロック１４８は、第１の値が正常に更新されたかどうか判断し、エラーが検出された場合、制御はブロック１５０に渡されて、ルーチン１４０を終了させ、エラー状態を返す。エラーが検出されなかった場合、ブロック１４８は制御をブロック１５２に渡して、第２の値が同期しているかどうか判断される。また、ブロック１４４で第１の値が同期していると判断された場合、制御は直接ブロック１５２に渡される。

第２の値が同期していない場合、制御はブロック１５４に渡されて、ブロック１４６で第１の値が設定されたのと同じ方式で、第２の値が設定される。次にブロック１５６で、設定処理が成功したがどうか判断が行われ、エラーが検出された場合、制御がブロック１５０に渡される。エラーが検出されなかった場合、ブロック１５６は制御をブロック１５８に渡して、新しいＩＤ対の値が、値を元の状態からインクリメントするなどして生成される。別の方式では、変更がすべてのノードに伝えられるのであれば、各値について任意の数を選択することもできる。また、ブロック１５２に話を戻し、第２の値が同期している場合、制御はブロック１５８に直接渡される。

新しいパラメータ値が生成されると、制御はブロック１６０に渡されて、第１の値が変更される。ブロック１４６での場合と同様に、第１の値の変更は順序付けられたメッセージによって実行され、続いてブロック１６２で、第１の値が正常に変更されたかどうか判断が行われる。正常に変更されなかった場合、制御はブロック１５０に渡されて、エラーが返される。正常に変更された場合、制御はブロック１６４に渡されて、上で論じたのと同じ方式で、第２の値が変更される。その結果次第で、制御がブロック１６６からブロック１５０に渡されて、エラーが返されることもあれば、ブロック１６８に渡されて、エラー無し状態が返され、したがって変更が正常終了したことが通知されることもある。

次に図４に戻ると、アクション準備が完了し、正常終了が返された場合、望ましいリソース・アクションが実行される。上で論じたように、複数の異なるリソース・アクションが企図されている。例えば、図７には、特定タイプのリソースの消失が検出されるなどしたのに応答して、特定タイプのリソースを復旧するために実行することができる、例示的なリソース復旧ルーチン１８０が示されている。

ルーチン１８０はブロック１８２から開始され、どのリソースが他のノードに所有され、どのリソースがそれら他のノードに所有されているクラスタ・オブジェクトに所有されているか判断するために、すべてのノードに問合せを行う。ブロック１８２は本質的に、システム内の既存リソースの登録簿を調べることに相当する。一般に、そのような登録簿は、様々なノードへの複数の問合せを生成し、その問合せに対して生成された適切な応答を受け取ることから構成される。結果として、ブロック１８２は、所有されているリソースのリストまたは表を生成する。

ブロック１８２が完了すると、ブロック１８４で、問合せが成功したかどうか、所有リソースの有効な表が生成できたかどうか判断する。これらに成功しなかった場合、制御はブロック１８６に渡されて、ルーチン１８０は終了し、エラー状態が返される。成功した場合は、制御はブロック１８８に渡されて、所有リソースとシステム内の既知のリソースとを比較する。この比較によって、所有者のないリソースのリストが生成され、その結果、消失リソースの所有権を獲得して消失リソースを復旧するために、ブロック１９０が実行される。これらの所有者のないリソースは、どのクラスタ・エンティティによる所有権もないために消失したので、これらのリソースのことも消失リソースとよぶ。

開始ノードによって、消失リソースの復旧が行われ、消失リソースの獲得が主張されると、制御はブロック１９２に渡されて、ルーチンは終了し、エラー無し状態が返される。これにより、リソース復旧は完了する。

本発明の好ましい実施形態により、様々なタイプのリソースの復旧が行えることを理解されたい。例えば、仮想アドレス範囲、クラスタ・オブジェクト、ＤＡＳＤユニットを別々に復旧できるようサポートするのが望ましいことがある。

他の形態のリソース・アクションをサポートするのが望ましいことがある。例えば、仮想アドレス空間内で「境界移動」をサポートするのが望ましいことがある。例示の実施形態では、例えば、仮想アドレスを、クラスタ・ノードとクラスタ・オブジェクトにそれぞれ割り当てられた２つの範囲に分割することができる。仮想アドレスは異なるノードおよびオブジェクトに割り当てられるので、メモリ空間を、仮想アドレス空間の各終端から２つの区画の境界に向かって消費していくことができる。クラスタ・ノードまたはクラスタ・オブジェクトがそれぞれの区画内の利用可能な空間をすべて使用してしまった場合、境界を移動させ、満杯になった区画に追加のメモリ空間を割り当てるのが望ましいことがある。さらに、仮想アドレスは各ノード上でローカルに利用されるので、例示の実施形態では、ノードに割り当てられた区画で、各ノード内で仮想アドレスの再利用が可能である。しかし、様々なノードがクラスタ・オブジェクトを所有できるので、オブジェクトに割り当てられた各仮想アドレスは、一意でなければならない。したがって、境界移動処理を実行するには、境界の移動が、消失アドレス範囲がある区画内で、使用されている仮想アドレスの衝突を発生させないことを確認するために、各ノードに問合せを行わなければならない。

再び図４に戻ると、様々なリソース・アクションの実行が完了したとき、アクション終了ルーチン８４が呼び出されて、リソース・アクションのプロセスを完了させる。また、図５に示すように、ルーチン８４は、準備処理中の、ローカル・ノード上でローカル・サンドボックスを獲得した後の任意の時点でも呼び出される。

図８には、アクション終了ルーチン８４がより詳細に示されている。ルーチン８４はブロック２００から開始され、ローカル・ノードがスタンドアロン・モードで動作しているかどうか判断する。スタンドアロン・モードでない場合、制御はブロック２０２に渡され、一般にノード上のローカル・サンドボックスを終了させるためのメッセージを各ノードに送信することにより、他のノード上のサンドボックスを終了させる。次にブロック２０４で、リソース・アクションが別のクラスタ・プロトコル内でネストしているかどうか判断が行われる。最初、リソース・アクションはネストしていないものと想定され、制御がブロック２０６に渡されて、クラスタ・プロトコルを終了させ、次にブロック２０８に渡されて、ノード上のローカル・サンドボックスを終了させる。次に、処理結果が返され、ルーチン８４はブロック２１０で終了する。

ブロック２００および２０４に話を戻すと、ノードがスタンドアロン・モードで動作している場合、またはリソース・アクションが別のクラスタ・プロトコル内でネストしている場合、中間のブロックは省略され、制御はブロック２０８に直接渡されて、ノード上のローカル・サンドボックスを終了させる。

本発明の好ましい実施形態による、クラスタード・コンピュータ・システムのブロック図である。 図１のクラスタード・コンピュータ・システム内にあるノードのブロック図である。 図１のクラスタード・コンピュータ・システム内にある例示的なクラスタ・エンティティのブロック図である。 図１のクラスタード・コンピュータ・システムによって実行されるリソース・アクション・ルーチンのプログラムの流れを示すフローチャートである。 図４に示したアクション準備ルーチンのプログラムの流れを示すフローチャートである。 図５の準備ルーチンでクラスタ構成パラメータを変更するのに適したＩＤ変更ルーチンのプログラムの流れを示すフローチャートである。 図４のリソース・アクション・ルーチンによって実行され、例示的なリソース管理処理を実施する、リソース復旧ルーチンのプログラムの流れを示すフローチャートである。 図４および図５に示したアクション終了ルーチンのプログラムの流れを示すフローチャートである。

Claims (9)

1. 複数のリソースと、前記複数のリソースを所有するように構成された複数のクラスタ・エンティティとを含むタイプのクラスタード・コンピュータ・システム内で、リソース・アクションを実行する方法であって、前記複数のクラスタ・エンティティが、複数のノードと、前記複数のノード上に存在する複数のクラスタ・オブジェクトとを含み、前記方法は、コンピュータに対して、
   前記リソース・アクションを実行する前に、前記クラスタード・コンピュータ・システム上でロックを獲得するステップと、
   前記クラスタード・コンピュータ・システム内の前記複数のクラスタ・エンティティに関係付けられ、リストに登録されるとともに、前記ノード用の構成パラメータとして使用される少なくとも１つのクラスタ構成パラメータを変更することにより、前記クラスタード・コンピュータ・システムの準備処理を行うステップと、
   他のノードと通信してロックの準備が完了したか否かを判断するステップと、
   前記クラスタード・コンピュータ・システムの準備処理を行った後で、リソース・アクションを実行するステップであって、前記リソース・アクションを実行するステップが、
   （ａ）前記クラスタード・コンピュータ・システム内の前記複数のノードに問合せを行って、複数のリソースのいずれが所有されているか判断するステップと、
   （ｂ）所有されていないリソースの所有権を前記複数のノード中の第１のノードに移転させるステップとを実行させ、
   前記準備処理を実行するステップにより、前記クラスタード・コンピュータ・システムの準備処理の最中にアクティブであるクラスタ・エンティティは、前記クラスタ構成パラメータの変更を受け入れ、前記クラスタード・コンピュータ・システムの準備処理の最中に非アクティブであるクラスタ・エンティティは、前記クラスタ構成パラメータの変更を受け入れず、前記非アクティブ・クラスタ・エンティティが前記準備処理による前記クラスタ構成パラメータの変更の後に前記クラスタード・コンピュータ・システム中に受け入れられるのを阻止し、さらに
   前記リソース・アクションを実行した後で、前記ロックを解除するステップを含む、方法。
2. 前記クラスタ構成パラメータが、前記複数のノードの各々に格納されたクラスタ識別子と、オブジェクト識別子と、前記複数のクラスタ・オブジェクトの各々に関係付けられた所有権移転カウントとを含む、請求項１に記載の方法。
3. 前記リソース・アクションは、リソース復旧である、請求項１または２のいずれか１項に記載の方法。
4. 前記リソース・アクションは、仮想アドレス範囲、オブジェクト番号、ＤＡＳＤユニット番号から選択されるリソースの復旧を含む、請求項１または２のいずれか１項に記載の方法。
5. （ａ）ネットワークを介して互いに結合された複数のノードと、
   （ｂ）複数のリソースと、
   （ｃ）前記複数のリソースを所有するように構成された複数のクラスタ・エンティティであって、複数のクラスタ・ノードおよび複数のクラスタ・オブジェクトを含む複数のクラスタ・エンティティと、を含み、
   前記リソース・アクションを実行する前に、前記クラスタード・コンピュータ・システム上でロックを獲得する手段と、
   前記クラスタード・コンピュータ・システム内の前記複数のクラスタ・エンティティに関係付けられ、リストに登録されるとともに、前記ノード用の構成パラメータとして使用される少なくとも１つのクラスタ構成パラメータを変更することにより、前記クラスタード・コンピュータ・システムの準備処理を行う手段と、
   他のノードと通信してロックの準備が完了したか否かを判断する手段と、
   前記クラスタード・コンピュータ・システムの準備処理を行った後で、リソース・アクションを実行する手段とを含み、
   前記リソース・アクションを実行する手段は、
   前記クラスタード・コンピュータ・システム内の前記複数のノードに問合せを行って、複数のリソースのいずれが所有されているか判断する手段と、
   所有されていないリソースの所有権を前記複数のノード中の第１のノードに移転させる手段とを含み、
   前記準備処理を実行する手段は、前記クラスタード・コンピュータ・システムの準備処理の最中にアクティブであるクラスタ・エンティティは、前記クラスタ構成パラメータの変更を受け入れ、前記クラスタード・コンピュータ・システムの準備処理の最中に非アクティブであるクラスタ・エンティティは、前記クラスタ構成パラメータの変更を受け入れず、前記非アクティブ・クラスタ・エンティティが前記準備処理による前記クラスタ構成パラメータの変更の後に前記クラスタード・コンピュータ・システム中に受け入れられるのを阻止し、さらに、
   前記リソース・アクションを実行した後で、前記ロックを解除する手段を含む、コンピュータ・システム。
6. 前記クラスタ構成パラメータが、前記複数のノードの各々に格納されたクラスタ識別子と、オブジェクト識別子と、前記複数のクラスタ・オブジェクトの各々に関係付けられた所有権移転カウントとを含む、請求項５に記載のシステム。
7. 前記リソース・アクションは、リソース復旧である、請求項５または６のいずれか１項に記載のシステム。
8. 前記リソース・アクションは、仮想アドレス範囲、オブジェクト番号、ＤＡＳＤユニット番号から選択されるリソースの復旧を含む、請求項５または６のいずれか１項に記載のシステム。
9. コンピュータ・システムにロードされ実行されたときに、請求項１〜４のいずれか１項に記載の方法を実行させるコンピュータ実行可能なコンピュータ・コードを含む、コンピュータ・プログラム。

Images