(57)【特許請求の範囲】
【請求項１】
コンピューティング環境のクラスタを自動的に構成する方法であって、前記コンピューティング環境は１つ又は複数のクラスタを含み、前記クラスタは１つ又は複数のノードを含み、前記ノードはリソースを共用し、互いに共同してシステム・タスクを実行し、各クラスタは複数のコンポーネントを含むクラスタ・アーキテクチャによって管理され、各コンポーネントは該クラスタの１つ又は複数のノード上で複数の対応プロセスを実行し、
前記方法は、
前記コンピューティング環境のクラスタに追加されるべきノードによって、前記追加されるべきノード内の１つまたは複数のリソースの構成データの取得を開始すること、
前記クラスタ内のシステム・レジストリ・コンポーネントに前記取得された構成データを記憶すること、
前記取得された構成データの記憶に応答して、グローバル・データ記憶の機能を提供する前記システム・レジストリ・コンポーネントが更新されたことを、前記クラスタ内のシステム・レジストリ・コンポーネントによって、１つ又は複数の他のクラスタ・コンポーネントに通知すること、
を含み、
それによって、他のクラスタ・コンポーネントが前記追加されるべきノードをクラスタ・メンバとして理解することが可能になる方法。
【請求項２】
少なくとも前記通知の開始後に、メンバシップ・リストに前記追加されるべきノードを追加して、前記クラスタに前記ノードを挿入することをさらに含む、請求項１に記載の方法。
【請求項３】
コンピューティング環境のクラスタを自動的に構成するシステムであって、前記コンピューティング環境は１つ又は複数のクラスタを含み、前記クラスタは１つ又は複数のノードを含み、前記ノードはリソースを共用し、互いに共同してシステム・タスクを実行し、各クラスタは複数のコンポーネントを含むクラスタ・アーキテクチャによって管理され、各コンポーネントは該クラスタの１つ又は複数のノード上で複数の対応プロセスを実行し、
前記システムは、
前記コンピューティング環境のクラスタに追加されるべきノードによって、前記追加されるべきノード内の１つ又は複数のリソースの構成データの取得を開始するための手段と、
前記クラスタ内のシステム・レジストリ・コンポーネントに前記取得された構成データを記憶するための手段と、
前記取得された構成データの記憶に応答して、グローバル・データ記憶の機能を提供する前記システム・レジストリ・コンポーネントが更新されたことを、前記クラスタ内のシステム・レジストリ・コンポーネントによって、１つ又は複数の他のクラスタ・コンポーネントに通知するための手段と
を含み、
それによって、他のクラスタ・コンポーネントが前記追加されるべきノードをクラスタ・メンバとして理解することが可能になるシステム。
【請求項４】
少なくとも前記通知の開始後に、メンバシップ・リストに前記追加されるべきノードを追加して、前記クラスタに前記ノードを挿入するための手段をさらに含む、請求項３に記載のシステム。
【請求項５】
コンピューティング環境のクラスタを自動的に構成する方法を実行するためのプログラムであって、前記コンピューティング環境は１つ又は複数のクラスタを含み、前記クラスタは１つ又は複数のノードを含み、前記ノードはリソースを共用し、互いに共同してシステム・タスクを実行し、各クラスタは複数のコンポーネントを含むクラスタ・アーキテクチャによって管理され、各コンポーネントは該クラスタの１つ又は複数のノード上で複数の対応プロセスを実行し、
前記プログラムがコンピュータに
前記コンピューティング環境のクラスタに追加されるべきノードによって、前記追加されるべきノード内の１つ又は複数のリソースの構成データの取得を開始させること、
前記クラスタ内のシステム・レジストリ・コンポーネントに前記取得された構成データを記憶させること、
前記取得された構成データの記憶に応答して、グローバル・データ記憶の機能を提供する前記システム・レジストリ・コンポーネントが更新されたことを、前記クラスタ内のシステム・レジストリ・コンポーネントによって、１つ又は複数の他のクラスタ・コンポーネントに通知させること
を含み、
それによって、他のクラスタ・コンポーネントが前記追加されるべきノードをクラスタ・メンバとして理解することが可能になることを実現させるプログラム。
【請求項６】
少なくとも前記通知の開始後に、メンバシップ・リストに前記追加されるべきノードを追加して、前記クラスタに前記ノードを挿入する機能をさらに含む、請求項５に記載のプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、一般に分散コンピューティング環境に関し、特に、分散コンピューティング環境の複数ノードからなる１つまたは複数のクラスタを管理することに関する。
【０００２】
【従来の技術】
分散システムは、システムに対して高スループットの作業あるいは連続的またはほぼ連続的な可用性を必要とする状況を含む、様々な状況で使用する高可用性のスケーラブル・システムである。
【０００３】
リソースを共用する能力を有する分散システムはクラスタと呼ばれる。１つのクラスタは、リソースを共用し、互いに共同してシステム・タスクを実行する複数のオペレーティング・システム・インスタンスを含む。現在、様々なクラスタ・システム（ＩＢＭが提供するＲＳ／６０００ＳＰシステムなど）が存在するが、依然として既存のクラスタ・システムに対してさらに機能強化を図ることが望ましい。たとえば、クラスタ・システムの管理を容易にするための機能強化が望ましい。
【０００４】
【発明が解決しようとする課題】
コンピューティング環境のクラスタを自動的に構成するための方法、システムおよびプログラムを提供することにある。
【０００５】
【課題を解決するための手段】
コンピューティング環境のクラスタを自動的に構成する方法を提供することにより、従来技術の欠点が克服され、追加の利点が得られる。この方法は、たとえば、コンピューティング環境のクラスタに追加すべきノードにより、そのクラスタの１つまたは複数のリソースの構成データの取得を開始することと、そのクラスタのシステム・レジストリ・コンポーネントにその構成データを記憶することと、その構成データが更新されたことをそのシステム・レジストリ・コンポーネントにより１つまたは複数の他のクラスタ・コンポーネントに通知することを含む。
【０００６】
上記で要約した方法に対応するシステムおよびコンピュータ・プログラムについても本明細書に記載し、本明細書で請求する。
【０００７】
本発明の技法により、追加の特徴および利点が実現される。本発明のその他の実施形態および態様については、本明細書で詳述し、請求する本発明の一部と見なす。
【０００８】
【発明の実施の形態】
本発明の１つまたは複数の態様によれば、オペレーティング・システムの１つまたは複数のコピーを使用する分散コンピューティング環境が管理される。オペレーティング・システムの各コピーは、それが１組のリソース（たとえば、プロセッサ、ネットワーク・インタフェース、ファイル、ファイル・システム、記憶装置、周辺装置など）にアクセスできるように構成される。このアクセスは、排他的なものにするか、またはオペレーティング・システムの他のコピーと共用することができる。リソースを共用する場合、オペレーティング・システムの個別コピーは共同し、それが管理するシステム・リソースを共用する。リソースを共用するために、オペレーティング・システムのコピーは、リソースの保全性が保持されるように、そのアクセスについて折衝する。たとえば、記憶装置の所与のセグメントに複数のデータ・ブロックを書き込む必要があるオペレーティング・システムの２つのコピーはそのセグメントへのアクセスについて折衝するが、さもなければ、書込み動作の順序により書込み中のデータの保全性が損なわれる恐れがある。
【０００９】
本発明の諸態様を組み込み使用する分散コンピューティング環境の一例を図１に示し、本明細書で説明する。分散コンピューティング環境１００は、たとえば、複数のＬＡＮゲート１０４により互いに結合された複数のフレーム１０２を含む。フレーム１０２およびＬＡＮゲート１０４については以下に詳述する。
【００１０】
一例の分散コンピューティング環境１００は８個のフレームを含み、そのそれぞれは複数の処理ノード１０６を含む。ある事例では、各フレームは１６個の処理ノード（それぞれが１つまたは複数のプロセッサを有する）を含む。各処理ノードはたとえば、ＵＮＩＸ（登録商標）ベースのオペレーティング・システムであるＡＩＸを実行するＲＩＳＣ／６０００コンピュータである。１つのフレーム内の各処理ノードは、たとえば内部ＬＡＮ接続により、そのフレームの他の処理ノードに結合される。その上、各フレームはＬＡＮゲート１０４により他のフレームに結合される。
【００１１】
例として、各ＬＡＮゲート１０４は、ＲＩＳＣ／６０００コンピュータ、ＬＡＮへのコンピュータ・ネットワーク接続、またはネットワーク・ルータのいずれかを含む。しかし、これらは例にすぎない。他のタイプのＬＡＮゲートが存在すること、ならびに他のメカニズムを使用してフレームを互いに結合できることは、当業者にとって明らかになるだろう。
【００１２】
図１の分散コンピューティング環境は一例にすぎない。９個以上または７個以下のフレームあるいはフレームあたり１７個以上または１５個以下のノードを備えることは可能である。さらに、処理ノードはＡＩＸを実行するＲＩＳＣ／６０００コンピュータである必要はない。処理ノードの一部または全部は、異なるタイプのコンピュータまたは異なるオペレーティング・システムあるいはその両方を含むことができる。さらに、その環境のノードまたはオペレーティング・システムのうちの１つまたは複数がその環境の他のノードまたはオペレーティング・システムとは異なる異種環境が本発明の諸態様を含み使用することもできる。このような異種環境のノードは、本明細書に記載するように、互いに共同し、リソースを共用するという点で相互動作する。さらに、本発明の諸態様は単一コンピュータ・システム内で使用することもできる。これらの変形形態はいずれも、ここで請求する本発明の一部と見なされる。
【００１３】
リソースを共用する能力を有する分散コンピューティング環境をクラスタと呼ぶ。特に、１つのコンピューティング環境は１つまたは複数のクラスタを含むことができる。たとえば、図２に示すように、コンピューティング環境２００は、クラスタＡ  ２０２とクラスタＢ  ２０４という２つのクラスタを含む。各クラスタは１つまたは複数のノード２０６を含み、そのノードはリソースを共用し、互いに共同してシステム・タスクを実行する。各ノードはオペレーティング・システムの個別コピーを含む。
【００１４】
特定のクラスタに対するノードのメンバシップを検討する際に２通りの態様が存在する。一方の態様は、そのクラスタの静的構成に関するものである。この態様はノード定義と呼ばれる（図３を参照）。あるノードをクラスタに対して定義すると、そのクラスタ内の他のノードはこのノードを認識する。ノードは、正常なノード定義動作（以下に詳述する）後にクラスタに対して定義される。逆に、ノード削除動作後に、ノードはクラスタに対して定義解除される。
【００１５】
ノードの静的態様は、クラスタ・メンバシップと呼ばれる動的（またはランタイム）属性とは異なる。クラスタ・メンバシップとは、ノードが定義され、作動可能（すなわち、オンライン）であるときにそのノードがクラスタのメンバであると見なされることを意味する。ここで、作動可能という用語は、そのノードがそのクラスタの他のメンバによって機能ノード、すなわち、活性タスクと呼ばれる基本機能を実行可能なノードとして知覚されることをほのめかす。一例として、１つのノードは１組の活性タスクを連続的に実行し、一定の間隔でクラスタの他メンバにハートビート・メッセージを送信することにより、そのノードがこのようなタスクを実行できることを他のノードに報告する。
【００１６】
クラスタ・メンバシップは、任意の時点でそのクラスタの一体部分として機能しているノードのリストと見なすことができる。このリストはすべてのノードにとって使用可能なものであり、本発明の一態様では、クラスタ・アーキテクチャにより、無共用分散システムでも任意の時点ですべてのノードが同じメンバシップ・リストにアクセスできることが保証される。（無共用分散システムとは、そのノードがディスクまたはメモリなどの共用物理リソースを一切持たないシステムである。）このようなシステムで特定のデータの同一ビューを維持するために、高度な同期プロトコルを使用する。というのは、アトミック・トランザクションですべてのノードにそのデータを分散しなければならないからである。
【００１７】
メンバシップ・リストに対してノードを追加するかまたはノードを削除するために、特定のプロトコルを使用する。たとえば、メンバシップ・リストにノードを追加するプロセスはノード加入プロセスと呼ばれる。逆に、ノード離脱プロセスにより、メンバシップ・リストからノードを削除する。あるノードがクラスタ・メンバシップにリストされない場合、そのノードはすでにクラスタを離脱している。
【００１８】
各クラスタは、複数のコンポーネントを含むクラスタ・アーキテクチャによって管理される。各コンポーネントは、本明細書で詳述するように、そのクラスタの１つまたは複数のノード上で１つまたは複数の対応プロセスを実行する。そのコンポーネントが複数のノード上で複数のプロセスを実行する場合、そのアーキテクチャはこれらのノード間に分散される。しかし、分散アーキテクチャは一例にすぎない。本発明の１つまたは複数の態様を単一または非分散システムで使用することができる。
【００１９】
一例では、クラスタ・アーキテクチャのコンポーネントは、クラスタ・システムを構成し、ノードがクラスタに加入するかまたはクラスタを離脱するときに発生するクラスタ構成データベース（後述する）の同期を調整するために使用する分散構成マネージャ（ＤＣＭ）４００（図４）と、クラスタ構成データベース内に記憶されたデータを供給する１つまたは複数のプロセスを含むシステム・レジストリ・サーバ・サブシステム４０２と、クラスタのメンバ間の通信経路の可用性に関する情報を提供するクラスタ・メンバシップ・リストを維持する活性サブシステム４０４と、他のクラスタ・プロセスが論理グループを形成し、整合性のあるグループ状態およびプロセス・メンバシップを維持できる機構を提供するグループ・サービス・サブシステム４０６と、クラスタ・リソースのアクセスおよび制御を管理する機構であり、それによりクラスタ・クライアントがクラスタ・リソースの状態および構成を監視できる機構も提供するリソース・マネージャ・サブシステム４０８とを含む。
【００２０】
一実施形態では、図４に示すように、各コンポーネントが複数のノード４１０間に分散される。すなわち、各コンポーネントは、複数のノード上で１つのプロセスを実行している。たとえば、ＤＣＭ４００は図示した３つのノード上で１つのＤＣＭプロセス４１２を実行している。他のコンポーネントについても同じことが当てはまり、それぞれについては以下に詳述する。
【００２１】
分散構成マネージャ（ＤＣＭ）サブシステム４００は、そのクラスタの一部として構成すべき各ノード上で、分散構成マネージャ・デーモン（ＤＣＭＤ）４１２と呼ばれるコンピュータ・プログラムのコピーを提供する。ＤＣＭＤは、クラスタのブートストラップ・エージェントである。このため、ＤＣＭＤプロセスは、適切なクラスタ構成により他のクラスタ・コンポーネントを始動することを担当する。また、ＤＣＭＤは、１つのノードをあるクラスタから他のクラスタに移動する場合など、適切なときに他のクラスタ・コンポーネントを停止するプロセスでもある。ＤＣＭＤ自体は、そのノードのベース・オペレーティング・システムによってブートストラッピングされ、この例ではオペレーティング・システムによって直接ブートストラッピングすべき唯一のクラスタ・コンポーネントである。
【００２２】
ＤＣＭＤは、各ノードのローカル記憶域内にあって、１つまたは複数のクラスタ構成に関連するファイルの集合を維持する。このローカル構成データに加え、ＤＣＭＤは、グローバル構成データもサーバ・リポジトリに記憶する。このクラスタ構成データについては以下に詳述する。
【００２３】
システム・レジストリ・コンポーネント４０２は、グローバル・データ記憶の機能を提供する。これは、可用性が高く、一例では、システム・レジストリ・プロセス４１４（図４）として複数のノード間で複製される。しかし、一実施形態では、図５に示すように、あるクラスタのすべてのノード上にシステム・レジストリが複製されるわけではない。図５に示すように、ノード（すなわち、オペレーティング・システム・インスタンス）１、２、３はシステム・レジストリ・プロセス５００を含むが、ノード４〜８は含まない。しかし、この特定の例のノードはいずれも他のコア・クラスタ・プロセス（たとえば、ＤＣＭプロセス、活性プロセス、グループ・サービス・プロセス、リソース・マネージャ・プロセス）を含む。ノード４〜８はレジストリ・クライアント・ノードと見なされ、ノード１〜３はレジストリ・サーバ・ノードと見なされる。というのは、レジストリ機能がこれらのノード上で実行されるからである。
【００２４】
活性コンポーネント４０４（図４）は、通信アダプタの状況と、そのクラスタ内のノード間の通信経路の可用性を提供する。各ノードは、１つまたは複数の通信アダプタを介して通信ネットワーク５０２（図５に示すもの）に接続される。このようなアダプタのいずれかが故障し、クラスタ・ノードを相互接続するネットワーク内の１つまたは複数の通信経路に影響する可能性もある。活性コンポーネントはそのクラスタの１つまたは複数のノード内でプロセスを実行するが、そのプロセスは各ノード内の各通信アダプタからハートビートという定期検証メッセージを送信する。ノード内の活性プロセスの集合は各アダプタの可用性に関する部分的な知識に関するメッセージを交換し、これらのメッセージにより活性システムは、クラスタ・システム内の各通信アダプタの状態と、任意の２つのアダプタ間の通信経路の可用性についても論理的に推論することができる。
【００２５】
グループ・サービス・コンポーネント４０６は、他のコンポーネントに対して総称メンバシップ・サービスを提供する。このようなサービスとしては、アトミック・ブロードキャストとも呼ばれる２フェーズ・コミット・プロトコルを実行するための機構を含む。これは、あるグループのメンバがそのグループのメンバシップを制御し、グループ状態を維持できるようにする機構も含む。
【００２６】
リソース管理コンポーネント４０８は、コア・クラスタ・サービス（たとえば、ＤＣＭ、システム・レジストリ、活性、グループ・サービスおよびリソース・マネージャ）の一部ではない他のクラスタ・サービスへの基本通信層を提供する。これらのサービスは、後述するように追加のリソース・コントローラのカテゴリに分類される。一例では、この通信プロトコルはオブジェクト指向のものである。したがって、リソース管理コンポーネントによって制御すべきリソース・コントローラは、それが制御するリソース・オブジェクトを定義するリソース記述ファイルをリソース管理コンポーネントに提供する。この定義は、１組の属性またはデータ・フィールドならびに各リソース・コントローラがサポートする１組の機能によって行われる。
【００２７】
クラスタ・アーキテクチャの各コンポーネントは、そのアーキテクチャの１つまたは複数の他のコンポーネントに対する１つまたは複数のデータ依存関係または機能依存関係あるいはその両方を有し、それは様々なコンポーネント間の関係（すなわち、コンポーネント間関係）を定義するものである。このような関係は、本発明の一態様により、データ依存関係および機能依存関係が非周期グラフを形成する（すなわち、依存関係の循環が回避される）ように設計されている。
【００２８】
各コンポーネントのデータ依存関係の一例を図６に図示し、以下に詳述する。
（Ａ）システム・レジストリ：  システム・レジストリは、クラスタの他のコンポーネントに対していかなるデータ依存関係６００も持っておらず、これはシステム・レジストリの固有の特性である。システム・レジストリ自体は、その構成データをすべて記憶することができる。システム・レジストリ・コンポーネントは、依存関係グラフ内のリーフとして使用でき、その結果、いかなる循環関係も回避できるように設計されている。システム・レジストリは、可用性が高くなるようにそれ自体の構成データを記憶する能力を有する。また、システム・レジストリは、トランザクション論理を使用して要求が伝播される複製データ・リポジトリとして設計されている。
（Ｂ）分散構成マネージャ（ＤＣＭ）：  ＤＣＭコンポーネントは、すべてのノード上でローカルにコア・クラスタ構成データのローカル・バージョンを記憶する能力ならびにシステム・レジストリにグローバル・データを記憶する能力を有する。一例では、ローカル構成データの少なくとも一部分はグローバル・データと整合性のあるものでなければならない。しかし、場合によっては、ＤＣＭサブシステムによって記憶されたローカル構成データがシステム・レジストリ・サブシステムにグローバルに記憶されたデータにより順序が乱れる可能性も考えられる。これは、たとえば、そのノードが一例としてメンテナンスのためにクラスタから切断されている間に更新を逸した場合に発生することになる。
たとえば、ノードは誤動作し、修理のために送られる場合がある。その間、クラスタ化システムのシステム管理者は、損傷したノードを定義解除し、したがって、ノード定義解除動作によりその定義をグローバル・レジストリから削除することを決定することができる。損傷したノードが修理され、クラスタに再接続されると、それはクラスタに対して定義解除されているので、もはやクラスタ・リソースを共用できなくなるはずである。それにもかかわらず、最近修理したノード内のローカル・クラスタ構成は時代遅れになっており、依然としてそのノードをクラスタに対して定義済みのものとして示す。このような場合を削除するため、他のすべてのクラスタ・コンポーネント用のブートストラップ・エージェントであるＤＣＭＤデーモンは、ノード加入プロセスを開始する前にローカル・クラスタ定義の妥当性をチェックする。これにより、システム・レジストリ・コンポーネントに対するＤＣＭＤデーモンのデータ依存関係６０２が作成される。
（Ｃ）残りのコア・クラスタ・コンポーネント（活性、グループ・サービス、およびリソース管理）は、ＤＣＭによって記憶されたローカル・クラスタ構成を使用するので、分散構成マネージャ・コンポーネントに対して共通のデータ依存関係６０４を有する。たとえば、ローカル・クラスタ構成は、このアーキテクチャ内のクラスタ・コンポーネントが使用する、レジスタ・サーバ・プロセスを実行するノードのリストならびにノード名および番号などのブートストラップ情報を含む。システム・レジストリ・コンポーネント自体を除き、他のコンポーネントは、レジストリ・サーバに接続し、後述するグローバル・クラスタ構成を検索するために、そのノード・リストを使用する。
（Ｄ）システム・レジストリ自体を除き、すべてのコンポーネントは、グローバル・クラスタ構成に対するデータ依存関係を有する。
【００２９】
各コンポーネントの機能依存関係の一例を図７に図示し、以下に詳述する。
（Ａ）分散構成マネージャ（ＤＣＭ）：  ＤＣＭは、システム・レジストリ・コンポーネントによって提供されるグローバル記憶機能の可用性に依存する（参照番号７００を参照）。
（Ｂ）システム・レジストリ：  システム・レジストリは、グループ・サービス・コンポーネントに対する機能依存関係７０２を有する。この依存関係は、書込み動作を伝播するために、システム・レジストリがグループ・サービス・コンポーネントのメンバシップ・サービスを使用することによって発生する。グローバル・クラスタ構成データはレジストリ・サーバ・ノードとして機能する各ノード内で複製されるので、それに対する修正は複製書込み動作を必要とする。このような書込み動作中には、複製の１つが故障し、複製動作の分散回復のための論理を実現することが望ましくなる恐れがある。グループ・サービス・コンポーネントによって提供されるメンバシップ・サービスは、このような分散回復論理の一例を含む。
しかし、グループ・サービス・コンポーネントに対する機能依存関係は書込み動作のみに影響する。システム・レジストリ・コンポーネントは、読取りタイプの動作の場合にグループ・サービス・コンポーネントに対する依存関係を一切持たない。したがって、システム・レジストリ・コンポーネントは、ＤＣＭＤコンポーネントによってブートストラッピングした後、その初期設定の第１のフェーズ（以下に詳述する）を完了することができる。このフェーズが完了した後、システム・レジストリは、クラスタ構成データベースの最も最近更新したコピーをすでに検索しており、他のコンポーネントがクラスタ構成データを読み取れるようにすることができる。次に、これにより、グループ・サービス・コンポーネントはそれ自体の初期設定を完了することができ、それにより、後述するようにシステム・レジストリ・コンポーネントがその初期設定の第２のフェーズを続行することを可能にする。
（Ｃ）活性コンポーネント：  活性コンポーネントは、ＤＣＭＤによってブートストラッピングされ（参照番号７０４を参照）、活性サブシステムの構成をレジストリに記憶する（参照番号７０５を参照）。これは、他のコンポーネントに対する他の機能依存関係を一切持っていない。
（Ｄ）グループ・サービス・コンポーネント：  グループ・サービス・コンポーネントはＤＣＭＤによってブートストラッピングされる（７０６）。これは、クラスタ内のノード間の通信経路の可用性を知る必要があるので、活性コンポーネントに対する機能依存関係（７０８）も有する。
（Ｅ）リソース・マネージャ・コンポーネント：  リソース・マネージャ・コンポーネントはＤＣＭＤによってブートストラッピングされる（７１０）。これは、グループ・サービス・コンポーネントによってエクスポートされるグループ・メンバシップ機能に対する依存関係（７１２）も有する。これは、その構成データベースのバージョン番号を決定するためにメンバシップ機能を使用する。
また、追加のリソース・マネージャも、ＤＣＭに対する機能依存関係（７１４）ならびにリソース・マネージャ・コンポーネントに対する機能依存関係（７１６）を有する。
【００３０】
コンポーネントのデータ依存関係または機能依存関係あるいはその両方は、クラスタ化技法のブートストラップ・プロセス中に満足される。一例では、クラスタ・ブートストラップ・プロセス中に依存関係を満足するために、特定のシーケンスのイベントおよびメッセージを使用する。このシーケンスの一例については図８に示し、本明細書で説明する。
【００３１】
ステップ０でブートストラップ・シーケンスを開始する。クラスタ・アーキテクチャは、たとえば、オペレーティング・システムによって開始されるソフトウェアの層として設計されている。基本オペレーティング・システム・ブートストラップ・プロセス後に、オペレーティング・システムは、分散構成マネージャ・プロセスを始動することによりクラスタ・ソフトウェアをブートストラッピングする。次に、ＤＣＭＤデーモンを始動し、オペレーティング・システム・インスタンスの存続期間にわたってそれを実行する。
【００３２】
前述したように、ＤＣＭは、（一例として）各ノードのローカル記憶域に記憶された１組のデータ構造を維持する。このデータ構造としては、たとえば、クラスタ・データ構造９００（図９）、ノード定義データ構造９０２（図１０）、レジストリ・サーバ・ノード・データ構造９０４（図１１）を含み、そのそれぞれについては後述する。
【００３３】
クラスタ・データ構造９００は、たとえば、クラスタ名９０６と固有クラスタ識別子９０８を含む。一例では、固有識別子をキー・フィールド（固有フィールド）として使用する。クラスタ・データ構造内のキー・フィールドは、同じクラスタ名でラベルを付け替えられないようにオペレーティング・システムの個別インスタンスを保護する。クラスタは、人間の管理者によって作成される場合が多く、多数のプロセッサの構成プロセス中に同一名で容易にラベルを付けられる可能性がある。さらに、本明細書に記載するクラスタ構成インフラストラクチャは、非常に動的なものであり、したがって、クラスタの作成および削除を可能にするものである。クラスタは、分散システムのニーズに応じて動的に作成し破壊することができる。固有識別子は、後述するクラスタ定義動作によってクラスタが作成されたときに生成される。この特徴により、クラスタ名の再利用の検出が可能になる。たとえば、Ａというラベルが付いたクラスタを作成し、削除し、もう一度作成した場合、固有識別子フィールドが別個のものになるので、Ａに関するこの２通りの定義のデータ構造は異なるものになるだろう。
【００３４】
さらに、クラスタ定義データ構造内の固有識別子は他のクラスタ・リソースのマッピングのルートにある。このシステムでは、クラスタ・データ構造用の固有識別子はクラスタ・リソース内のラベルの接頭部にある。固有識別子マッピングと本明細書に記載するアーキテクチャの使用により、クラスタ構成の間違った想定のもとにクラスタ・リソースがクライアントによってアクセスされるのを防止する。
【００３５】
ノード定義データ構造９０２は、たとえば、ノード番号９１０と、人間の管理者にとってノード識別をより容易にするために便利なものとして使用するが、いずれのクラスタ・リソース・マネージャもノードの構成にアクセスする手段として使用しないノード名９１２と、ノードの定義を識別する固有ノード識別子９１４とを含む。固有識別子は、特定のオペレーティング・システム・インスタンスに関連する。この識別子は、あるノードがクラスタに対して定義されるたびに生成される。この固有識別子により、同じ名前を持つ２つのノード間の区別、ならびにすでにクラスタに対して定義され、定義解除され、その後、同じ名前でもう一度定義された（再定義された）ノードとの区別が可能になる。
【００３６】
レジストリ・サーバ・ノード・データ構造９０４は、クラスタに対して定義されるレジストリ・サーバ・ノードのリストを含む。一例では、このデータ構造は、レジストリ・サーバの順序付きリスト９１６と、１次レジストリ・サーバの表示９１８とを含む。このリストは、後述するように、システムのグローバル構成データを読み取るためにシステム・レジストリ・プロセスへのアクセスを希望する他のクラスタ・コンポーネントによって検索される。
【００３７】
上記のローカル・データ構造に加え、各クラスタ・コンポーネントはローカル記憶域データ構造を維持し、各コンポーネントはローカル・ノードに関連する情報を記憶するための予約空間である。ローカル・データ構成の一例を図１２に示し、以下に説明する。
【００３８】
ただし、図１２に示すデータ構造はＵＮＩＸ（登録商標）オペレーティング・システムにおける本発明の具体的な実施例から導出されたものであるが、他のオペレーティング・システムにおける同様の実施例も可能であり、本発明の精神から逸脱するものではないことに留意されたい。
【００３９】
ローカル記憶域データ・フィールドの一例について以下に説明する。
１．「/」（１０００）は、オペレーティング・システム内のルート・ファイル・システムを示す。
２．「/var」（１００２）は、オペレーティング・システム拡張機能に関連するデータが記憶されるファイル・システムである。
３．クラスタ論理は、「/var/ct」（１００４）にローカル構成情報を記憶する。
４．「/var/ct/dcm」ディレクトリ（１００６）は分散構成マネージャ・コンポーネントによって所有される。この例では、ＤＣＭコンポーネントは、他のクラスタ・コンポーネントとしてクラスタＩＤ以下のディレクトリにそれを記憶するのとは対照的に、それ自体のデータを記憶するためにより上位レベルのディレクトリを有する唯一のコンポーネントである。これは、この特定の例では、ＤＣＭが、１つのノードを複数のクラスタに定義できることを認識している唯一のクラスタ・コンポーネントであるからである。
５．「/var/ct/dcm/configuration」ディレクトリ（１００８）には、ＤＣＭはそのノードを定義する対象となるクラスタのリストを記憶する。また、ＤＣＭは、そのノードが現在属しているクラスタのＩＤもこのディレクトリに記憶する。このＩＤは、ローカル構成データをどこから読み取るべきかを決定するために他のクラスタ・コンポーネントが使用する。
６．「/var/ct/dcm/logs」ディレクトリ（１０１０）には、ＤＣＭコンポーネントは、監査機構として使用する、そのランタイム・ログを記憶する。
７．ノードを定義する対象となるクラスタごとに、ＤＣＭは、「/var/ct」の下に「/var/ct/cluster_ID」というラベルが付いたディレクトリ（１０１２）を作成するが、「cluster_ID」というリテラルは以下に説明するように固有クラスタ識別子によって置換される。このディレクトリの下にＤＣＭは他に４つのディレクトリも作成し、そこには他のクラスタ・コンポーネントがそれぞれのランタイム・ロック１０１４、ランタイム・ログ１０１６、ランタイム・コア情報１０１８、構成データ１０２０を記憶することができる。
【００４０】
ローカル構成データに加え、ＤＣＭは、グローバル構成データも記憶する。サーバ・リポジトリに記憶されるグローバル構成データとしては、たとえば、クラスタ定義データ構造のコピーならびにノード定義データ構造のコピーを含む。クラスタ・データ構造およびノード定義データ構造のフィールドの値は、あるノードがそのクラスタに対して定義されたときに設定され、依然として整合性のあるものでなければならない。処理中にローカル・データ構造のデータ・フィールドはグローバル・データ構造のデータ・フィールドと比較される。この比較により何らかの差が得られた場合、これは、ノード定義がそのクラスタではもはや有効ではないことを示す可能性がある。
【００４１】
図８に戻ると、ＤＣＭＤプロセスを開始した後、ＤＣＭＤプロセスはシステム・レジストリ・プロセスを開始し、レジストリ・サーバ・ノードとして構成されたノードを始動する（ステップ１）。このステップは、システム・レジストリ・コンポーネントのブートストラップ要件を満足するものである。
【００４２】
ステップ２〜４でＤＣＭＤデーモンは、たとえば、そのクラスタのすべてのノード内の活性コンポーネント、グループ・サービス・コンポーネント、リソース・マネージャ・コンポーネントを始動する。
【００４３】
次にステップ５でシステム・レジストリ・サブシステムはその初期設定の第１のフェーズを実行する。特にこのサブシステムは、最も最近使用可能になったグローバル構成データベースのコピーを検索する手順を実行する。このフェーズ中、ＤＣＭＤによってブートストラッピングされたシステム・レジストリ・プロセスは、グローバル構成データベースの実現番号を含むメッセージを交換する。次にシステム・レジストリ・コンポーネントは、最高の実現番号を有する構成データベースのコピーを選択する。このようなコピーは、後述するようにコンポーネントの初期設定の第２のフェーズを続行することができる。
【００４４】
初期設定の第１のフェーズの完了後、システム・レジストリ・コンポーネントにより他のコンポーネントは読取りタイプの動作を発行することができ、それにより他のコア・クラスタ・コンポーネントはそれぞれの初期設定を完了することができる。すなわち、第１の初期設定フェーズが完了した後、システム・レジストリ・サブシステムは、他のクラスタ・コンポーネントにグローバル・クラスタ構成データを供給できるようになる。システム・レジストリ・コンポーネントにより、他のコンポーネントはグローバル構成データを読み取ることができるが、グローバル構成に修正を加えることはできない。これは、グローバル構成データに対する修正が書込み動作によって行われるからであり、システム・レジストリ・コンポーネントが書込み動作を実行するためにグループ・メンバシップ機能に対する依存関係を有するからである。このため、グローバル・クラスタ構成データを修正する動作は、後述するようにシステム・レジストリ初期設定の第２のフェーズが完了するのを待つ必要がある。
【００４５】
ステップ６でＤＣＭＤは、システム・レジストリからグローバル・クラスタ構成データを読み取ることができる。したがって、ステップ７でＤＣＭＤは、それが各ノードに記憶するローカル構成がシステム・レジストリに記憶されたグローバル・クラスタ構成と整合性のあるものであるかどうかを検証することができる。ＤＣＭＤコンポーネントはこの時点でもグローバル・クラスタ構成に変更を加えることができない。というのは、システム・レジストリはまだ動作を書き込むことができないからである。それにもかかわらず、ＤＣＭＤは、ローカル構成がグローバル・クラスタ構成と整合性のあるものであるかどうかを判定し、次にクラスタ・ブートストラップ・プロセスを続行し、最終的に他の依存関係を満足することになる他のコンポーネントを始動することができ、次にシステム・レジストリはその初期設定の第２のフェーズを完了することができ、書込み可能状態になる。
【００４６】
ステップ８で活性コンポーネントはグローバル構成データを読み取るはずである。しかし、そのコンポーネントはまず、システム・レジストリ・サーバの位置を把握し、情報がローカル・クラスタ構成内にあることを把握する必要がある。したがって、活性コンポーネントは、この情報を検索するためにＤＣＭＤへの呼出しを行う。
【００４７】
ステップ９では、前のステップと同様の手順でグループ・サービス・コンポーネントがＤＣＭＤコンポーネントからローカル・クラスタ構成データも検索する。
【００４８】
ステップ１０で活性サブシステムは、システム・レジストリ・サーバからグローバル構成データを読み取ることにより、グローバル構成データに対するその依存関係を満足する。さらにステップ１１で活性コンポーネントは、すでにその依存関係をすべて履行しているので、その初期設定を終結し、他のクラスタ・コンポーネントがその活性機能を使用できるようにすることができる。
【００４９】
ステップ１２でグループ・サービス・コンポーネントはシステム・レジストリからグローバル構成データを読み取ることもできる。次にグループ・サービス・コンポーネントは、ステップ１３に示すように、活性コンポーネントからの活性機能を使用することができる。
【００５０】
ステップ１４でグループ・サービス・コンポーネントは、その初期設定を完了し、他のクラスタ・コンポーネントがグループ・メンバシップ機能を使用できるようにすることができる。
【００５１】
ステップ１５でシステム・レジストリ・コンポーネントはそのメンバシップ・サービスの要件を満足し、それによりシステム・レジストリは初期設定手順の第２のフェーズを実行できるようになる。このフェーズでは、第１のフェーズで決定したようにより低い実現番号を有するグローバル構成データベースのコピーが、グループ・サービス・コンポーネントによって提供されるメンバシップ・サービスを使用して更新される。これにより、システム・レジストリ・コンポーネントは、その初期設定の第２のフェーズを終了することができ、グローバル・クラスタ構成に照らし合わせて書込み動作を発行することができる。
【００５２】
ステップ１６でシステム・レジストリ・コンポーネントは、その初期設定の第２のフェーズを終結する。このフェーズが完了した後、システム・レジストリ・コンポーネントは、複製書込み動作を実行するためにメンバシップ・サービスを使用することができ、したがって、他のクラスタ・コンポーネントがそれぞれのグローバル・クラスタ構成データベースに修正を加えることができるようになる。
【００５３】
ステップ１７でリソース・マネージャ・コンポーネントは、ＤＣＭＤコンポーネントからローカル構成データを検索する。リソース・マネージャ・コンポーネントは、システム・レジストリからグローバル構成データを読み取り、それに対して所望の修正を加える（ステップ１８）。
【００５４】
さらに、ステップ１９でリソース・マネージャ・コンポーネントは、グループ・サービス・コンポーネントのメンバ・サービスを使用して、その公正データベースのバージョン番号を決定する。その時点でリソース・マネージャ・コンポーネントは、そのデータおよび機能要件がすべて履行されており、その初期設定を完了している（ステップ２０）。したがって、リソース・マネージャ・コンポーネントは、他の構成済みリソース・コントローラをブートストラッピングすることができる（ステップ２１）。
【００５５】
追加のリソース・コントローラは、ＤＣＭＤコンポーネントからローカル・クラスタ構成を読み取り（ステップ２２）、システム・レジストリからグローバル・クラスタ構成を読み取る（ステップ２３）。さらに、これらのコントローラは所望の修正を実行する。ステップ２４で追加のリソース・コントローラはそれぞれの初期設定を終結する。
【００５６】
上記のブートストラップ・プロセスの実行後、すべてのクラスタ・コンポーネントは完全に使用可能になり、コンポーネントのデータおよび機能要件はすべて履行される。
【００５７】
クラスタを管理するため、本発明の少なくとも一態様により様々な定義動作を使用する。このような動作としてはたとえば以下のものを含む。
（Ａ）新しいクラスタ定義を作成するクラスタ定義動作。特に、この動作が発行されるノードにローカル・クラスタ構成を記憶するために新しいクラスタ識別子と新しいローカル記憶域が作成される。この新しいローカル記憶域は、ディレクトリ・パス内の新しいクラスタ識別子を有するディレクトリに置かれる。また、この動作は、新しいグローバル記憶域も作成する。ＤＣＭコンポーネントは、この動作が発行されるノードをレジストリ・サーバ・ノードとする。また、このプロセスでＤＣＭコンポーネントは、システム・レジストリ・プロセスをブートストラッピングし、前述のように本明細書で定義するグローバル・クラスタ・データ構造を作成する。
（Ｂ）クラスタ定義解除動作は、クラスタ定義を消去するために使用する。この動作は、クラスタの一部になるよう定義されたすべてのノード内のローカル・クラスタ定義を消去する。また、これは、システム・レジストリ・コンポーネントによって管理されるグローバル・クラスタ記憶域のすべてのコピーも消去する。
（Ｃ）クラスタ修正動作は、クラスタ定義の属性を修正するために使用する。修正可能な属性の１つはクラスタ名である。この属性は、クラスタ・コンポーネントが内部で使用しないので修正することができる。むしろ、クラスタの識別に内部で使用するのはクラスタＩＤである。
（Ｄ）ノード定義動作は、クラスタに対してノードを定義するために使用する。クラスタはクラスタ定義動作によってすでに確立されている。新しいローカル記憶域は新たに定義したノード内に作成される。また、グローバル記憶域に記憶されるクラスタ定義も新しいノード定義によって更新される。
（Ｅ）ノード定義解除動作は、ノードの定義をグローバル・クラスタ構成およびグローバル記憶域から消去するために使用する。また、この動作は、特定のクラスタのノードの定義に関連する、そのノード内のローカル記憶域も消去する。
（Ｆ）レジストリ・サーバ・ノード定義動作は、クラスタ内の特定のノードをレジストリ・サーバ・ノードとして定義する。この動作後、ＤＣＭコンポーネントはそのノードをレジストリ・サーバ・ノードとして識別し、必要であるかまたは望ましいかあるいはその両方の場合にノード内でレジストリ・サーバ・プロセスをブートストラッピングする。
（Ｇ）レジストリ・サーバ・ノード定義解除は、レジストリ・サーバ・ノードとしてのノード定義を除去する動作である。この動作後、システム・レジストリ・プロセスはもはやそのノード上でブートストラッピングされなくなる。
（Ｈ）ノード修正動作は、グローバル・クラスタ構成ならびにローカル記憶域内の両方でノード定義の属性を変更する。変更可能なノード構成の属性の１つは、ノードの名前である。
【００５８】
様々な定義動作に加え、様々な制御動作を使用して、クラスタ、ノード、レジストリ・サーバを管理する。このような動作としてはたとえば以下のものを含む。
（Ａ）オンライン・クラスタ動作は、クラスタに対して定義されることが分かっている他のすべてのノードへの接触を試みるためにノード内でプロセスを開始し、それらのノードがオンラインに移行することを要求する。
（Ｂ）オフライン・クラスタ動作は、クラスタに対して定義されることが分かっている他のすべてのノードに接触し、それらのノードがオフラインに移行することを要求する。
（Ｃ）オンライン・ノード（加入）動作は、ノードをオンラインで特定のクラスタに移動するようＤＣＭプロセスに要求する。この要求により、ＤＣＭコンポーネントはクラスタ・ブートストラップ手順で前述したアクション・シーケンスを開始することになる。
（Ｄ）オフライン・ノード動作は、オフラインになるよう特定のノードに要求する。この動作は、ノード上で動作している他のすべてのクラスタ・コンポーネントを停止するようＤＣＭコンポーネントに要求する。
（Ｅ）オンライン・レジストリ・サーバ動作は、特定のノードでシステム・レジストリ・プロセスをブートストラッピングするようＤＣＭコンポーネントに要求する。
（Ｆ）オフライン・レジストリ・サーバ動作は、特定のノードでシステム・レジストリ・プロセスを停止するようＤＣＭコンポーネントに要求する。
【００５９】
クラスタを管理するために、上記の定義および制御動作のそれぞれを使用することができる。これらの動作の１つまたは複数については以下に詳述する。
【００６０】
本明細書に記載するように、本発明の一態様のクラスタ・アーキテクチャは、オペレーティング・システム・インスタンス（すなわち、ノード）がクラスタに対して定義されたときに生成される固有識別子を使用する。固有識別子は、クラスタ・システムの実施例にとって意味のあるものになるように生成される（図１３を参照）。たとえば、単一オペレーティング・システム・コンピュータ１１００の場合、ある事例では、システムのマザー・ボード内の読取り専用メモリ（ＲＯＭ）に記憶された番号から固有識別子が導出される。
【００６１】
複数オペレーティング・システム・コンピュータ１１０２の場合、オペレーティング・システム・インスタンスは、既知の固有識別子生成技法を使用して、そのノードが定義されたときに固有識別子を生成するだけの可能性がある。
【００６２】
さらに、区別された１つのハードウェアを有するコンピューティング装置１１０４の場合、オペレーティング・システムのアイデンティティはその単一ハードウェアから導出される。このような実施例は、許可ユーザの識別にスマート・カードを使用する装置内など、様々な応用例では意味のあるものである。
【００６３】
この識別子は、ローカル構成記憶域ならびにグローバル構成データベースの両方に記憶される。両方のタイプの記憶域を使用するので、いずれかに理由（たとえば、メンテナンス手順）によりデータの順序が乱れる場合にデータを調整するために、本発明の一態様により１組の規則が提供される。たとえば、順序が乱れたデータがノードの識別子である場合、その識別子を調整するために１組の規則が提供される。この特定の例については以下に詳述する。しかし、他の不整合データを調整するために同様の規則を使用することを理解されたい。
【００６４】
分散クラスタ・システムは１組のマシンであり、そのそれぞれは別々の時期に通信ネットワークから切断することができるので、オペレーティング・システムの１つのインスタンスは、それが所与のクラスタの１つのノードとして定義されたときに識別される。しかし、オペレーティング・システムのそのインスタンスは電源異常またはメンテナンス動作のために停止する可能性があり、それが所与のクラスタのメンバとして定義されている場合にそれ自体をそうであると理解することができるはずである。したがって、ノードがクラスタに加入するたびに、それは、ローカル記憶域内の固有識別子がそのノード用のグローバル識別子と一致するかどうかをチェックする。
【００６５】
特に、一実施形態では、基本オペレーティング・システムの基本ブートストラップ・プロセス中にオペレーティング・システムによって固有識別子が読み取られる。次に基本オペレーティング・システムは、クラスタ・ブートストラップ・シーケンスの開始時に分散構成マネージャに固有識別子を渡す。次に分散構成マネージャは、クラスタに対してそれが定義されたときにグローバル記憶域１１０６とローカル記憶域１１０８の両方にこの固有識別子を記憶する。分散構成マネージャは、クラスタにノードを加入する動作を実行するたびに、固有識別子の３通りのインスタンス（すなわち、ブートストラップ・シーケンスの際にオペレーティング・システムが渡す識別子であって、ここでオリジナル・コピーと呼ぶ識別子（ＵＩＤ）１１１０、ローカルで記憶した（キャッシュした）コピー１１０８、グローバルで記憶したコピー１１０６）の妥当性をチェックする。
【００６６】
ノードがクラスタに加入するプロセス中に、この３つの識別子を以下のように比較する。
１）オリジナル識別子をローカル識別子と比較する。
２）ローカル識別子をグローバル識別子と比較する。
【００６７】
この比較により、以下に示す４通りの結果が得られる可能性がある。
【００６８】
【表１】
0003707728.tif 000002
【００６９】
次に分散構成マネージャは、たとえば、上記のシナリオのそれぞれに応じて以下のアクションを採用する。
シナリオ１：  この場合、３つの識別子はすべて同じであり、したがって、ノード定義は正しいものである。これは通常ケースである。他の３通りのケースは、メンテナンス動作など、ノード定義に影響する動作の結果として存在するだけである。
シナリオ２：  この場合、オリジナル識別子はローカル識別子と等しいが、ローカル識別子はグローバル識別子と同じではない。これは、ノードがクラスタに接続されていない間にノード定義を削除したときに発生する。ノードはクラスタに接続されていないので、ノード削除プロセスに関与することができない。したがって、ノードが削除されたという趣旨で、ローカル・データ構造の更新は行われない。ノード上でのメンテナンスが終了し、ノードが再加入しようと試みると、そのノードはそれ自体の削除を通知し、したがって、そのノードが特定のクラスタから削除されたという趣旨で、ローカル・データ定義をクリーンアップできるようになる。
シナリオ３：  この場合、オリジナル識別子はローカル識別子と一致せず、ローカル識別子はグローバル識別子と一致する。したがって、オリジナル識別子は、たとえば、メンテナンス動作時に置き換えられている。これは、置き換えなければならないハードウェア・リソースからオリジナル識別子が得られたときに発生する。このようなリソースの例は、それぞれの固有識別子が読取り専用メモリ（ＲＯＭ）に記憶されているマザー・ボードおよびスマート・カードである。オリジナル識別子が記憶されているハードウェアを置換することが必要になるかまたは望ましくなる場合、クラスタ論理は、このケースをシナリオ２および４のような間違った定義とは区別しなければならない。この場合、ローカル識別子とグローバル識別子は一致しており、ノード定義が依然としてクラスタ内で有効であることを示す。したがって、実行するアクションは、オリジナル識別子が置き換えられたという趣旨で、ノード定義を訂正することになる。したがって、分散構成マネージャは、新しいオリジナル識別子と一致するようにローカル識別子とグローバル識別子を両方とも変更する。
シナリオ４：  この場合、オリジナル・ノード識別子はローカル識別子と一致せず、ローカル識別子はグローバル識別子と一致しない。したがって、このノードには２回のメンテナンス動作が行われている。これは、ノードがクラスタから切断されている間にグローバル構成から削除されており、オリジナル識別子も置き換えられている。このケースは上記のシナリオ２に類似している。というのは、グローバル構成がローカル記憶域に最後にキャッシュされた値と一致しないことが決定要因になるからである。したがって、実行するアクションは、ノードがクラスタから削除されたという趣旨で、ローカル・データ定義をクリーンアップすることになる。
【００７０】
一実施形態では、シナリオ３などの所与のシナリオで分散クラスタ・マネージャはオリジナル識別子の自動訂正を実行することができるが、これはそのクラスタを識別する固有ハードウェアがメンテナンス動作で置き換えられた場合に所望の効果である。この特徴により、たとえば、前のカードを紛失した場合に他のスマート・カードを使用できるようになるだろう。分散構成マネージャは、グローバル・データベースで値を調べることにより、クラスタに対して前に定義されたマシンを識別することができる。しかし、シナリオ４に例示するように、事前にクラスタに対して定義されていないマシンで新しいカードを使用することはできないだろう。この特徴も所望のものである。というのは、クラスタ定義動作は、クラスタに対して定義すべきマシンが実行しなければならない明示動作であるからである。
【００７１】
クラスタ・システムのメンバとしてノードを確実に定義し、クラスタを加入するためのデータ整合性の維持に関する詳細について、以下に説明する。
【００７２】
ローカル構成とグローバル・クラスタ構成データベースの両方に変更が加えられ、両方のリポジトリのデータが整合性を維持しなければならないので、ノード定義動作などの動作はアトミック方式で実行される（すなわち、その動作は完了まで実行されるかまたは打ち切られる）。動作が打ち切られる場合、両方のリポジトリのデータは、クラスタ化アーキテクチャと整合性のある状態に復帰される。これは、１つのノードを何回も定義し定義解除できることと、定義解除動作が行われたときにそのノードをクラスタから切断できることを考慮に入れたものである。
【００７３】
クラスタに対するノード定義の整合性を執行するために、ノード定義動作は、そのノード自体をノード定義プロトコルに関与させる。この動作中にそのノードの固有識別子はノード番号に関連付けられるが、このノード番号もそのノードが定義される特定のクラスタに固有のものである。しかし、ノード番号はすべてのクラスタにわたって固有であるわけではない。したがって、複数ノードのプールを複数クラスタ配置（後述する）に使用する場合、各クラスタで同じ番号または異なる番号を付けて１つのノードを定義する場合も考えられる。しかし、この実施形態では、１つのノードは任意の特定の時点で１つのクラスタのみでオンライン（アクティブ）になることができる。
【００７４】
ノード番号識別子は、それによってクラスタに対してノードを把握させる内部識別子である。ノード定義プロセスは、一例では、所与のノード番号が、当初は特定の固有識別子で定義されたオペレーティング・システムの１つのインスタンスに関連するように保証するものである。ノード定義プロセスの詳細については、図１４および図１５に示す例に関連して説明する。
【００７５】
図１４を参照すると、ノード定義プロセスに関与するプロセス（たとえば、コンピュータ・プログラム）として、レジストリ・サーバとして定義されるクラスタ１２０４の１つまたは複数のノード１２０２内に位置するシステム・レジストリ・サーバ・プロセス１２００（図１４）と、ノード定義要求１２０８が発行されるノードまたはその動作の経路指定先になるノードで動作する分散構成マネージャ１２０６（すなわち、メンバＤＣＭプロセス）と、クラスタに追加されるノードで動作する分散構成マネージャ１２１０（すなわち、非メンバＤＣＭ）という３つのプロセスが存在する。図１５に関連して後述するように、この３つのプロセスは定義プロトコルに関与する。
【００７６】
ステップ１では、ノード定義要求がメンバＤＣＭプロセスに渡される。一例では、定義すべきノードのノード（たとえば、ＩＰ）アドレスが要求とともに渡される。任意選択のパラメータとして、固有ノード識別子、ノード番号、ノード名も渡すことができる。明示的に設定されていない場合、固有識別子、ノード番号、ノード名の値はメンバＤＣＭプロセスによって生成される。
【００７７】
ステップ１で得られたノード・アドレスは、非メンバＤＣＭプロセスに接触するためにメンバＤＣＭが使用する（ステップ２）。このメッセージでメンバＤＣＭプロセスは非メンバＤＣＭプロセスにクラスタ識別子を渡す。
【００７８】
ステップ３で非メンバＤＣＭプロセスは、その要求を受け取り、受け取ったクラスタ識別子で識別されるクラスタのメンバとして定義される。非メンバＤＣＭは、それが固有クラスタ識別子によってすでに識別されたローカル構成を一切持っていないことをチェックする。（前述のシナリオの中には、そのノードが古い定義を有する可能性があるものもある。）非メンバＤＣＭは、ホスト・オペレーティング・システムによって渡されたそれ自体の固有識別子でこの要求に応答する。また、これは、そのクラスタＩＤに関する前の定義がローカル記憶域で見つかったかどうかを示す状況コードもこの応答に含める。
【００７９】
メンバＤＣＭは、非メンバＤＣＭノードの固有識別子を含む応答を非メンバＤＣＭから受け取る（ステップ４）。メンバＤＣＭは、この値を保管し、ノード識別子がグローバル記憶域で報告されたかどうかをチェックする（ステップ５）。たとえば、メンバＤＣＭは、システム・レジストリ・プロセスに対してルックアップ要求を行って、その特定の固有識別子で定義されたノードをクラスタ内で見つける。システム・レジストリは、ステップ４で渡された固有ノード識別子に対応する可能なノード定義を含むメッセージまたはこのような定義がまったく存在しないことを示す戻りコードで応答する（ステップ６）。
【００８０】
ステップ７でメンバＤＣＭは前述のメッセージを受け取る。このような定義が見つかった場合、メンバＤＣＭは、この定義が非メンバＤＣＭによって報告されたものと同じであるかどうかをチェックする。これらの定義が同一である場合、非メンバ・ノードがそのクラスタに対してすでに定義されている（このノード定義要求は誤って発行されたものであり、この場合の「非メンバ」というラベルは適切ではない）という趣旨のメッセージがノード定義要求側に返送される。これらの定義が同一ではない場合、ローカル定義とグローバル定義がともに削除され、ノード定義プロセスが続行される。残る可能性として、非メンバ・ノードはグローバル・クラスタ構成で見つけることができないローカル定義を報告する。この場合、定義が一致しない場合と同様に、非メンバＤＣＭは前の定義を消去するよう要求される。
【００８１】
ステップ８でメンバＤＣＭは、当初はステップ１で与えられるノード・アドレスと、固有ノード識別子、ノード番号、ノード名をシステム・レジストリに渡し、新しいノード用の項目を作成するようシステム・レジストリに要求する。システム・レジストリは、グローバル・クラスタ構成に対して前述の項目をコミットし、動作の成功を通知するメッセージをメンバＤＣＭに返送する（ステップ９）。
【００８２】
ステップ１０でメンバＤＣＭは上記のメッセージを受け取る。動作が成功しなかった場合、ノード定義プロセスは打ち切られ、プロセスが失敗したというメッセージがノード定義の要求側に返送される。成功した場合、プロセスは続行される。次にメンバＤＣＭは、ローカル記憶域に対して新しいノード定義をコミットし、適切であれば前の定義を消去するよう非メンバＤＣＭに要求する（ステップ１１）。
【００８３】
ステップ１２で非メンバＤＣＭは、前述の要求を実行し、要求された動作の成功を通知するメッセージをメンバＤＣＭに返送する。メンバＤＣＭはこのメッセージを受け取る（ステップ１３）。非メンバＤＣＭによって報告される結果が失敗である場合、メンバＤＣＭは定義動作を打ち切り、ノード定義動作の要求側に失敗を報告する。メンバＤＣＭは、ステップ８で作成されたグローバル記憶域内の定義を消去する試みも行う。失敗ではない場合、プロセスは続行される。
【００８４】
メンバＤＣＭプロセスはノード定義動作を正常に完了しており、次に、動作の成功を示すメッセージを要求側に返す（ステップ１４）。
【００８５】
クラスタに対してノードを定義した後、たとえば、本発明の自動クラスタ構成技法を使用することにより、システム管理者の側で追加のアクションを行う必要なしに、そのノードをクラスタに挿入（加入）することができる。この技法は、たとえば、ノード定義の直後またはオンライン・ノード要求を発行したときに開始することができる。
【００８６】
自動クラスタ構成技法の一実施形態について図１６および図１７に関連して説明する。具体的には、図１６はこの技法で使用する様々なプロセスの一例を示し、図１７はプロセス間のメッセージ・フローの一例を示す。
【００８７】
図１６を参照すると、たとえば、オンライン・ノード要求１４００によりクラスタに対して新しいノードを構成するアクションは、新しいノード１４０４上のＤＣＭプロセス１４０２によって調整される。これは、それが初めてクラスタに加入するまで、クラスタ内の他のプロセスはそのノードの構成に関する知識がないからである。
【００８８】
ノード定義の時点では、新しいノードとクラスタとの間で最小量のデータしか交換されない（図１７、ステップ１）。交換されるデータは、新しいノードの固有識別子の保証に関するものであり、レジストリ・サーバのリスト１４０６をシードするためのものでもある。ローカル識別子／ノード番号の対は、グローバル・リポジトリの識別子／ノードの対と比較される。この比較が成功すると、加入を続行することができる。
【００８９】
クラスタに加入するよう新しいノードに要求すると（図１７、ステップ２）、新しいノード上のＤＣＭプロセスは、新しいノード内のリソース・マネージャ１４０８に対して（図１７、ステップ３）、リソース・コントローラ１４１０にメッセージを送り（図１７、ステップ４）それぞれの構成をシステム・レジストリ１４１２に書き込むよう要求する。このプロセスはノードがクラスタに加入するたびに繰り返され、このプロセスによりノード構成の自動更新も可能になる。
【００９０】
したがって、リソース・コントローラはそれらが制御するリソース（たとえば、ハードウェア）用の構成によりシステム・レジストリを更新し（図１７、ステップ５）、更新が完了したことを新しいノード上のリソース・マネージャに通知する（図１７、ステップ６）。次にリソース・マネージャ・プロセスは、それに登録されたリソース・コントローラに関するこの動作の完了状況を受け取ったときにＤＣＭに通知する（図１７、ステップ８）。
【００９１】
新しいノード上のＤＣＭプロセスは、更新が完了したという通知をリソース・マネージャから受け取り（図１７、ステップ９）、加入プロセスを続行する。
【００９２】
並列アクションで、クラスタ１４１６上のシステム・レジストリ・プロセス１４１４は、構成が更新されたという趣旨でイベント加入者が受け取ることができるイベントを送る（図１７、ステップ７）。初めてクラスタにノードを追加する場合、このイベントにより、他のクラスタ・コンポーネントが新しいノードをクラスタ・メンバとして理解することが可能になる。
【００９３】
上記の手順により、システム管理者からの情報を必要とせずに、ノードはそれ自体をクラスタのメンバとして構成することができる。管理者は、一例では、ノード定義手順用のノード・アドレスのみを供給する。ノード定義手順中にレジストリ・サーバのリストが新しいノードにシードされる。クラスタに加入するよう新しいノードに要求すると、そのノードはレジストリ・サーバのリストを使用して作業システム・レジストリ・プロセスを見つける。次に、新しいノード上のリソース・コントローラは、それが制御するリソースの構成を発見し、この情報をグローバル・クラスタ構成データベースに書き込むよう要求される。（リソース・コントローラは、特定のリソースに関して書き込まれ、それぞれの構成を発見する方法を把握しているプロセスである。）有利なことに、この動作は新しいノードによって開始され、この情報を手動で提供することをシステム管理者に要求しない。
【００９４】
一例では、そのノードの構成がグローバル・リポジトリと整合性のあるものであることを保証するために、ノードがクラスタに加入するたびに上記の手順が繰り返される。たとえば、この手順により、システム管理者はクラスタからノードを切断し、新しい通信アダプタなどの何らかのハードウェアを追加し、ノード構成に変更を加え、ノードがクラスタからオフラインになっていた間に行われたいずれの変更もクラスタに通知する必要なしにそれをクラスタに再接続することができる。
【００９５】
本発明の少なくとも一態様によれば、コンピューティング環境はそこに定義された１つまたは複数のクラスタを有することができる。たとえば、コンピューティング環境１６００（図１８）は、クラスタＡ  １６０２とクラスタＢ  １６０４とを含む。それぞれのクラスタはそれに対して定義された１つまたは複数のノード１６０６を有する。さらに、図１８に示すように、１つまたは複数のノードを両方のクラスタに対して定義することもできる。
【００９６】
各クラスタは、それに関連する１つまたは複数のレジストリ・サーバを有する。たとえば、クラスタＡはレジストリ・サーバ１６０８を有し、クラスタＢはレジストリ・サーバ１６１０を有する。レジストリ・サーバ１６０８は１つまたは複数のサーバ・ノード１６１２を含む。同様に、レジストリ・サーバ１６１０は１つまたは複数のサーバ・ノード１６１４を含む。１組のレジストリ・サーバのサーバ・ノードのうちの１つまたは複数は、他の１組のレジストリ・サーバの１つまたは複数のノードとオーバラップすることができる。
【００９７】
本発明の他の態様では、あるクラスタから他のクラスタへノードを迅速に移動することができる。この能力により、あるクラスタが所与の瞬間に経験する作業負荷間でノードをシフトすることが可能になる。たとえば、ウェブ・サービングおよびデータベース・サービスなど、２通りのアプリケーションに使用するノードのプールを有する企業について検討する。この企業は、本発明のクラスタ化技法を使用すれば、それぞれが１つのアプリケーション専用である２つのクラスタ、すなわちクラスタＡとクラスタＢを定義することができるだろう。次に、このようなアプリケーションでの作業負荷は時刻に応じて変動し、日中はウェブ・サービングの方がアクティブであり、夜間はデータベース・サービスの方がアクティブであると想定する。この企業は、クラスタＢの負荷の方が大きいときにクラスタＡからいくつかのノードをクラスタＢに移動し、逆も同様に行いたいと希望するだろう。
【００９８】
従来のクラスタ化システムでは、システム管理者は、まず、クラスタＡでノードをオフラインに移行し、次にそのノードをクラスタＡで定義解除し、次にそれをクラスタＢに対して定義し（通常、多大な手動構成を必要とする）、その後、クラスタＢでそのノードをオンラインに移行しなければならないだろう。従来のシステムは、手動介入を必要とし、非常に時間のかかるものである。作業負荷平衡アプリケーションについて検討する場合、ノードを移動するプロセスに費やす時間は非常に重要なものである。というのは、通常、作業負荷は、この例のように夜間と日中だけでなく、ものの数分で変化する非常に動的な尺度だからである。したがって、作業負荷平衡アプリケーションで価値を有するために、あるクラスタから他のクラスタへノードを移動する動作は非常に高速になる。
【００９９】
したがって、本発明の一態様によれば、クラスタ定義のオーバラップを可能にすることにより、あるクラスタから他のクラスタへノードを急速に移動する。すなわち、１つのノードは、複数のクラスタに対して定義することができるが、一実施形態では特定の時点で単一クラスタ内のみでアクティブになる。
【０１００】
１つのノードがクラスタに対して定義されると、ＤＣＭは、そのノードが定義されたクラスタに関するローカル構成を保持するための特殊記憶域を作成する。ＤＣＭコンポーネントはローカル・クラスタ構成をこのローカル記憶域に記憶する。ローカル・クラスタ構成に記憶される値の中には、たとえば、特定のクラスタのクラスタ名、クラスタＩＤ、ノード名、ノードＩＤ、レジストリ・サーバのリストがある。他の例としては、ＤＣＭは、ローカル記憶域内に以下の２つのフィールドも保持する。すなわち、そのノードが現在オンラインになっているクラスタの識別子（ＩＤ）を含む現行クラスタ・ポインタと、ノードの移動先であるクラスタのＩＤを含むターゲット・クラスタ・ポインタである。
【０１０１】
これらのポインタの値は、ノードをあるクラスタから他のクラスタへ移動する動作中のみ異なるものになる。ノードを所与のクラスタ内へ移動できるようにするために、そのクラスタ用の少なくとも１つのレジストリ・サーバ・ノードはオンラインでなければならない。ノードを移動するために、ＤＣＭは、ノードの加入先として想定されたクラスタを指し示すためにターゲット・クラスタ・ポインタを移動し、次に移動中のノード内で動作する他のクラスタ・コンポーネントにリフレッシュ信号を送る。あるコンポーネントは、このリフレッシュ信号を受け取ると、その構成をリフレッシュし、すなわち、その構成をグローバル・クラスタ・リポジトリから読み取る。そのリポジトリに到達するために、そのコンポーネントは、特定のクラスタに対して定義されたレジストリ・サーバのリストを検索する。移動中のノード内のレジストリ・サーバのリストを検索するプロセスでは、以下に詳述するように、どのリストを使用するかを決定するために、ターゲット・クラスタ・ポインタを使用する。
【０１０２】
あるクラスタから他のクラスタへ移動するノードに関連する論理の一実施形態について、図１９および図２０に関連して以下に説明する。図１９の点線矢印は、クラスタＡの構成に対するシステム・コンポーネントの事前接続を示す（ローカルとグローバルの両方）。移動プロセス中、これらの矢印は、クラスタＢの構成を指し示す実線矢印で置き換えられる。
【０１０３】
ステップ１（図２０）で、他のクラスタへノードを移動するための要求１７００（図１９）は、移動すべきノード上のＤＣＭプロセス１７０２に送られる。ＤＣＭプロセスは、ノードを移動するための要求を受け取り（図２０、ステップ２）、それがノードの移動先であるクラスタのクラスタＩＤを含むようにターゲット・クラスタ・ポインタ１７０４の値を変更する。移動中のノード上のＤＣＭプロセスは、そのノード上で動作する他のクラスタ・コンポーネント１７０６にリフレッシュ・メッセージを送る（図２０、ステップ３）。
【０１０４】
他のクラスタ・コンポーネントは、グローバル・クラスタ構成１７１０を読み取れるようにレジストリ・サーバのリスト１７０８を検索する（図２０、ステップ４）。このリストは、ターゲット・クラスタ・ポインタに記憶されたクラスタＩＤを特定のクラスタ用のレジストリ・サーバのリストに関連付けるマッピングを使用して検索される。次に、他のクラスタ・コンポーネントは、前のステップで受け取ったレジストリ・サーバのリストにリストされたレジストリ・サーバを使用して、グローバル・レジストリに記憶されたそれぞれの具体的な構成を要求する（図２０、ステップ５）。
【０１０５】
このレジストリ・サーバは、移動中のノード内の他のクラスタ・コンポーネントに対してターゲット・クラスタ内のそれぞれの役割に関するそれぞれの適切な構成を提供する（図２０、ステップ６）。移動中のノード上の他のクラスタ・コンポーネントは、それらが移動動作を完了し、ターゲット・クラスタ内でオンラインになっていることをＤＣＭプロセスに通知する（図２０、ステップ７）。
【０１０６】
次にＤＣＭは、そのノードが他のクラスタへ正常に移動されたことを反映するために現行クラスタの値を変更する（図２０、ステップ８）。そうではなく、いずれかのクラスタ・コンポーネントがリフレッシュ動作の実行に失敗した場合、ＤＣＭは、そのノードを現行クラスタ・ポインタの前の値に戻し、ターゲット・クラスタ・ポインタの値も復旧し、リフレッシュ・メッセージを再発行し、移動の効果を効果的に取り消す。その後、ＤＣＭプロセスは、動作の結果を移動動作の要求側に通知する（図２０、ステップ９）。
【０１０７】
すべてのコンポーネントがリフレッシュ動作を終了し、クラスタＢで正常にオンラインになっていることをＤＣＭに報告すると、現行クラスタ・ポインタはクラスタＢを指し示すように移動する。そのノードが何らかの理由でクラスタＢに加入できない場合、そのノードは現行クラスタ・ポインタに指名されたクラスタに復帰する。
【０１０８】
上記の手順により、あるクラスタから他のクラスタへノードを非常に迅速に移動することが可能になる。このような高速移動が可能になる理由は、このアーキテクチャにより１つのノードを複数のクラスタに定義できることによる。
【０１０９】
クラスタ・アーキテクチャの様々なコンポーネントは、メッセージを送受信し、いたるところでシステム通信トラフィックを引き起こす。「システム通信」という用語は、クラスタ化システム内で動作するアプリケーションによって生成されるトラフィックであるサービス・トラフィックとは対照的に、クラスタ化論理自体によって生成されるネットワーク・トラフィックを参照するために本明細書で使用する。たとえば、システム・トラフィックは、すべてのノード上の対等機能に定期検証メッセージを送る活性サブシステムによって生成されるネットワーク・トラフィックを含む。他の例としては、他のコンポーネントにそのクラスタのグローバル構成を送るシステム・レジストリ・コンポーネントによって生成されるネットワーク・トラフィックを含む。クラスタ・システムの典型的な配置では、複数の相互接続ネットワークを使用し、その結果、ノード間に複数の通信経路が作成される。したがって、システム内で動作する他のアプリケーションに干渉しないように、システム・トラフィックを特定の通信経路に制限できる機構をシステム管理者に提供することが望ましい。
【０１１０】
本発明の一態様によれば、クラスタ化論理によって生成されるネットワーク・トラフィックを制御するために、クラスタ・アーキテクチャはネットワーク・オブジェクトを定義する。システム・トラフィックを生成する各クラスタ・コンポーネントは、このようなトラフィックに使用すべきネットワーク・オブジェクトに関するプリファレンスを指定する。たとえば、１つのクラスタは１つまたは複数のネットワークを含むことができ、各ネットワークは１つまたは複数のサブネットワークを含み、各サブネットワークは１つまたは複数のノードを含む。
【０１１１】
前述のように、ノードはノード定義動作によってクラスタに対して定義される。同様に、サブネットワーク・オブジェクトはサブネットワーク定義動作によって定義される。サブネットワークは、そのノード・アドレスが既存のサブネットワーク・オブジェクトにマッピングされていないクラスタ内で新しい通信アダプタが発見されたという通知を受け取った場合に、ＤＣＭプロセスによって暗黙のうちに定義することができる。さらに、サブネットワーク定義解除動作はグローバル・クラスタ構成からサブネットワーク定義を削除し、サブネットワーク修正動作はサブネットワーク定義の属性を修正する。修正可能な属性としては、たとえば、サブネットワーク名ならびにサブネットワークがマッピングされるネットワーク定義を含む。
【０１１２】
同様に、ネットワーク定義動作は１つまたは複数のサブネットワーク定義にマッピングされるネットワーク定義を作成し、ネットワーク定義解除動作はグローバル・クラスタ・データベースからネットワーク定義を消去する。さらに、ネットワーク修正動作は、ネットワーク定義の属性を修正するために使用する。変更可能な属性の１つは、たとえば、ネットワーク名である。
【０１１３】
各ノード、サブネットワーク、ネットワークは、後述するように、少なくとも１つの対応データ構造によって定義される。これらのデータ構造は、たとえば、グローバル・リポジトリに記憶される。
【０１１４】
一実施形態では、各ノードは１つまたは複数のノード・アドレス定義データ構造によって表される。一例のノード・アドレス定義データ構造１９００（図２１）は、ノード・アドレス・データ定義の１次キー・フィールドとして使用し、本明細書で説明するようにノード・アドレス・オブジェクトが作成されたときに生成される固有識別子１９０２と、そのノードに到達するために使用するノード・インタフェースのノード・アドレスを含むノード・アドレス１９０４（以下に詳述する）と、クラスタ・システムの特定のサブネットワークにノード・アドレスをマッピングするために使用するサブネットワーク・マスク１９０６と、フィールド１９０４内のノード・アドレスに関連するノードの番号を含むノード番号１９０８とを含む。
【０１１５】
ノード・アドレスは、やはり固有のものである２次キー・フィールドである。分散構成マネージャ・コンポーネントでは同じノード・アドレスを有する２つのノード・アドレスの定義は不可能なので、ノード・アドレスは固有のものになる。本発明の諸態様の特定の一実施例でノード間の通信手段としてインターネット・プロトコルを使用するので、本明細書に記載する例では、アドレスはインターネット・プロトコル（ＩＰ）アドレスである。しかし、他のどの通信プロトコルでも使用できることは当業者には分かることである。どのイベントでも、選択したプロトコルを使用して各ノードに到達できるように、そのノードについて識別されたアドレスが少なくとも１つ存在するはずである。複数の通信プロトコルを使用する場合、プロトコル・タイプがノード・アドレス定義の追加フィールドになる場合もある。
【０１１６】
本発明の一態様によれば、各ノード・アドレス定義はサブネットワーク定義にマッピングされる。サブネットワーク定義データ構造の一例について図２２に関連して説明する。
【０１１７】
一例として、サブネットワーク定義データ構造２０００は、たとえば、サブネットワーク定義の固有性を示す固有識別子２００２と、この特定の実施例ではサブネットワークの接頭部を識別するノード・アドレスを含むサブネットワーク接頭部２００４と、サブネットワーク接頭部内のいくつのビットが関連するかを示すビット・マスクであるサブネットワーク・マスク２００６と、サブネットワーク定義を既存のネットワーク定義にマッピングするネットワーク名２００８とを含む。
【０１１８】
本明細書に記載する例では、サブネットワーク・オブジェクトは、ＩＰプロトコルに規定されている、そのコンピュータの相互接続の方法から導出される。たとえば、ＩＰネットワークでは、ＩＰアドレスとサブネットワーク・マスクによってノードが構成される。同じサブネットワークに接続されたすべてのノードは同じ接頭部を備えたアドレスを有するはずであり、接頭部の長さはサブネットワーク・マスクによって決定される。ここに示す実施例では、ＩＰネットワークのこの態様を使用してノード・アドレスをグループ単位にグループ化するが、この場合、各グループは同じサブネットワーク内にあるすべてのノードを含む。サブネットワークはネットワーク定義にマッピングされており、クラスタ・トラフィックの経路指定は、後述するように、ネットワーク・オブジェクトのパラメータを修正することによって制御される。
【０１１９】
ネットワーク定義データ構造の一例を図２３に示す。ネットワーク定義データ構造２１００は、たとえば、ネットワーク定義の固有性を示す固有識別子２１０２と、サブネットワーク・オブジェクトをネットワーク・オブジェクトにマッピングするために使用するネットワーク名２１０４と、様々なクラスタ・サービスを求める要求の伝送時にどのネットワークを使用するかを決定する際に使用する値のテーブルであるサービス経路指定テーブル２１０６とを含む。サービス経路指定テーブルは、たとえば、システム・トラフィックを生成するクラスタ・コンポーネントの名前と、このようなサービスにそのネットワークを使用する場合の優先順位とを含む。
【０１２０】
たとえば、１つのクラスタをＡ、Ｂ、Ｃという３つのネットワーク・オブジェクトによって定義することができる。あるクラスタ・コンポーネントがシステム・レジストリからグローバル構成を読み取ることを必要としていると仮定する。そのコンポーネントはまず特定のクラスタに関するレジストリ・サーバのリストを検索する。この例では、このリストは１、２、３というラベルが付いた３つのアドレスを含む。次にそのコンポーネントは、システム管理者が設定した優先順位に応じてどれを使用するかを選択する。このコンポーネントは、後述するマッピングに従い、サービス・ノード・アドレス（レジストリ・サーバのリストにリストされているもの）をネットワーク・オブジェクトにマッピングする。
【０１２１】
この例では、アドレス１はネットワークＡにマッピングされ、アドレス２はネットワークＢにマッピングされ、アドレス３はネットワークＣにマッピングされる。次に、このコンポーネントは、各ネットワーク・オブジェクトのサービス経路指定テーブルに記憶され、それが使用する必要があるサービス（たとえば、システム・レジストリ）を参照する優先順位値を読み取る。この値は、そのシステムに関してシステム管理者のプリファレンスに応じてシステム管理者が設定したものである。この例では、システム・レジストリ優先順位の値がネットワークＡでは３、ネットワークＢでは２、ネットワークＣでは１であると想定する。最高の優先順位番号はネットワークＡで見つかり、したがって、このコンポーネントは、ネットワークＡにマッピングされるアドレス（上記の１）をまず使用して、システム・レジストリ・コンポーネントに到達しようと試みる。次に、それが失敗した場合、このコンポーネントは、ネットワークＢにマッピングされるアドレスを使用し、最後にネットワークＣにマッピングされるアドレスを使用しようと試みる。
【０１２２】
クラスタ・サービスのクライアントがあるサービス用の特定アドレスを選択する方法に関する詳細について、図２４に示す例に関連して説明する。
【０１２３】
一実施形態では、最初にクライアントは、ステップ２２００（図２４）でサービスが存在する可能性のあるアドレスのリストを検索する。アドレスのリストを検索する方法は各サービスごとに異なる。システム・レジストリの場合、ローカル構成ファイルからレジストリ・サーバ・ノードのリストを検索する。他のサービスは、たとえばグローバル・クラスタ構成でノード・アドレスのリストを公表する場合もある。
【０１２４】
ノード・アドレスのリストの取得後、クライアントは、グローバル・クラスタ構成に記憶されたノード・アドレス定義データ構造内の各ノード・アドレスを調べる。各アドレスごとに、クライアントは、ステップ２２０２（図２４）でノード・アドレスとサブネットワーク・マスクの論理ＡＮＤ演算を実行し（図２５を参照）、その結果として各アドレスごとにサブネットワークＩＤを取得する。
【０１２５】
その後、クライアントは、ステップ２２０４で各アドレスごとにサブネットワーク・オブジェクトを検索し、各サブネットワーク・オブジェクトごとにステップ２２０６でそのサブネットワークに関連するネットワーク名を検索する。
【０１２６】
その後、クライアントは、ステップ２２０８でサービス・アドレスがマッピングされる各ネットワークを検索する。次にクライアントはステップ２２１０で、各ネットワーク・オブジェクトに記憶されたサービス経路指定テーブルからサービス優先順位番号を読み取る。次にクライアントはステップ２２１２で、ネットワーク・オブジェクトにシステム管理者によって設定された優先順位に応じてノード・アドレスのリストを順序付ける。
【０１２７】
その後、クライアントはステップ２２１４で、優先順位の順にサービスに接触しようと試みる。
【０１２８】
上記の技法は、特定のネットワークへの特定の種類のサービスに関連するトラフィックを含むメカニズムをクラスタの管理者に提供するものである。この技法は、管理者にとって意味のあるようにネットワーク・トラフィック制御を提供する。クライアントがこのサービス用のノード・アドレスのリストを検索することに留意されたい。このリストはサービス自体によって公表されるので、最初は順序付けられていない。上記の例では、ＤＣＭコンポーネントによりそのノード・アドレスのリストを公表するのはシステム・レジストリである。しかし、システム・レジストリは、ネットワーク構造またはシステム管理者のプリファレンスに関する知識をまったく持っておらず、したがって、順序付きリストを提供することができない。したがって、システム管理者は、上記のマッピングが示すように、サブネットワーク・オブジェクトをネットワーク・オブジェクトに割り当てることができる。
【０１２９】
システム・マネージャが行った変更は、移動したサブネットワークにマッピングされるすべてのアドレスのサービス優先順位割当てに影響する。この動作は、他のコンポーネントによって理解されるサブネットワーク・テーブル内の変更に局所化される。この機構は、それによってシステム管理者がクラスタ・システムのすべてのコンポーネントのシステム・トラフィックを制御できる中央制御点を提供する。
【０１３０】
前述したものは、システム管理者によって設定された優先順位に応じてサービス・アドレスのリストに順序付けるための一技法である。しかし、場合によってはシステム管理者は、それに関する優先順位プリファレンスが存在しない、複数の同等ネットワークを使用する場合もある。この場合、たとえば、経路指定ステップまたはホップによって、クライアントへの近接順にサービス・アドレスのリストを順序付けることが望ましい。標準のＩＰプロトコルでは、特定のサブネットワークから送られるデータグラムは、それが経路指定されていない場合、その特定のサブネットワーク内のノードのみに到達することになる。そのデータグラムが他のノードに到達するためには、それは経路指定される（すなわち、それは、そのデータグラムが発信されたサブネットワークとターゲット・ネットワークの両方あるいは他のルータまたはそのうちの１つがターゲット・ネットワークにアクセス可能な一連のルータに接続されたルータまたはパッケージ・スイッチング・ノードを通過する）。パッケージ・スイッチング・ノードによりパッケージを経路指定するステップはホップと呼ぶ。パッケージ・スイッチング動作はターゲット・サブネットワークでのパケットの受信を遅らせるので、ホップに関連してパフォーマンスの損害が発生する。
【０１３１】
したがって、システム管理者が特定サービスへのクラスタ・ネットワークの使用に関して優先順位プリファレンスを設定しない場合、サーバからクライアントに経路指定する際にデータグラムが被る最小数のホップに応じてリストを順序付けることが有益である。さらに、複数のサーバがクライアントと同等である場合（すなわち、正確に同じ数のホップを使用して複数のサーバに到達できる場合）、サービス負荷が等距離サーバ間に等しく広がるように、各クライアントごとに異なるようにリストを順序付けることが有益になる。
【０１３２】
以下の技法は、低距離および負荷平衡の基準に応じてサービス・アドレスのリストを順序付ける機構を提供するものである。この技法は、ＤＣＭが各ノードにレジストリ・サーバのリストを記憶するときに（システム管理者がクラスタ・ネットワークの使用に関する優先順位を設定していない場合）ＤＣＭが使用する。後述するように、この技法では、クライアントからサーバまでの距離と、作業負荷をサーバ間に等しく分散するマッピングを使用する。この作業負荷分散は、各サブネットワーク内のノードの総数と、各ノードの個別ノード番号と、等距離サーバの数から導出される公式に基づくものである。
【０１３３】
特定サービスに到達するためにクラスタ内の特定のノードが使用すべきアドレスの順序付きリストを生成するために使用する論理の一実施形態について、図２６に関連して説明する。一例では、この技法のための入力パラメータとして、特定サービス用のアドレスのリストと、特定サービスのクライアントになるノードのノード番号と、そのノード上に存在する通信インタフェース用のアドレス（ノード・アドレス）と、ホップ数による他の各サーバからそのノードまでの距離とを含む。このパラメータは標準のＩＰトレース・ルート機構を使用して推定できることに留意されたい。
【０１３４】
出力は、固有ノード番号によって識別される特定ノード用に調整されたサービス・アドレスの順序付きリストになる。このリストは、最小コストに応じて順序付けられ、等距離サーバに負荷平衡を使用する。
【０１３５】
図２６を参照すると、最初にステップ２４００で、入力リスト内のいずれかのアドレスがそのノード自体に存在するノード・インタフェースに対応する場合、これらのアドレスは結果として得られる順序付きリスト上にまず置かれる。この結果、同一ノード上に共存する複数サーバを使用するプリファレンスをローカル・クライアントが有し、その結果、可能な限り最善のパフォーマンスが得られる。次にステップ２４０２で、最低距離（ホップ数による）を備えたサーバのアドレスがリストされる。
【０１３６】
複数の等距離サーバ（すなわち、同じ数のホップを使用して到達可能なサーバ）が存在する場合、順序付けをさらに最適化することが可能である。２つの等距離サーバが存在する場合、クライアントの半分に一方のサーバを最初にリストし、残り半分にもう一方のサーバを最初にリストすることが有益である。これによりクライアントの半分は一方のサーバに関するプリファレンスを有し、残り半分はもう一方のサーバに関するプリファレンスを有し、理想的な負荷平衡方式を達成する。サーバが３つ存在する場合、第１の位置は３通りに分割することができる。
【０１３７】
どのサーバを最初にリストするかを決定するための一技法については、ステップ２４０４で説明する。特に、最初はステップ２４０６で、１組の等距離サーバ（すなわち、同じ数のホップを有する１組のサーバ）に対して、それぞれのノード・アドレスに応じて最低から最高の順に０、１、２などのインデックスを付ける。ノード・アドレスは固有のものなので、このマッピングも固有のものになる。
【０１３８】
次にステップ２４０８で、事前定義された式を使用して等距離サーバの１つのマッピング・インデックスを計算する。特に、ｋが０から等距離サーバの数までの場合、マッピング・インデックスは[(node_number)mod(number_of_equidistant_servers)+k]mod(number_of_equidistant_servers)]に等しくなり、式中、modは、除算演算の整数剰余として定義されるモジュロ演算を意味する。
【０１３９】
マッピング・インデックスの計算後、ステップ２４１０でマッピング・インデックスの対応アドレスをリストに追加する。
【０１４０】
その後、照会２４１２で、その組内により多くの等距離サーバが存在するかどうかの判定を行う。その組内により多くの等距離サーバが存在する場合、ステップ２４０８で処理が続行される。存在しない場合、処理は照会２４１４に継続し、そこで、より多くの処理すべきサーバが入力リストに存在するかどうかの判定を行う。より多くのサーバが存在する場合、プロセスはステップ２４０２に継続する。存在しない場合、サービス・アドレスの最終順序付きリストが提供され、ステップ２４１６で手順が完了する。
【０１４１】
上記の手順を実証する一例について以下に説明する。以下の入力を想定する。
ノード番号＝５
サービス・リスト（括弧内に距離を示した象徴的なノード・アドレスを使用する）は｛１（０）、３（１）、７（１）、９（１）、１２（２）、２（２）｝を含む。
【０１４２】
順序付けを取得するために、以下のように上記の規則に従う。
１）この技法では、ノード５に関して定義されたノード・アドレス定義テーブルのいずれかを調べ、入力アドレスのいずれかがこれらのテーブルのノード・アドレス・フィールド内にあるかどうかを判定する。距離が０のアドレス１がこのノードにとってローカルであり、したがって、上記の規則１により最初にリストされることを発見する。
２）３つの等距離サーバはノード・アドレスによって順序付けられ、０→３、１→７、２→９というマッピングになる。これらのノードは規則３〜７を使用して再順序付けされる。この場合の等距離サーバの数は３であり、ノード番号は５であり、その結果、以下のようになる。
ａ）第１のサーバを選択するために、ｋ＝０として規則５を適用し、以下の結果が得られる。
[(5mod3+0)mod3]=2
この結果は上記のステップで得られたリストに対するマッピング・インデックスである。この場合、マッピング・インデックス２はサーバ・アドレス９にマッピングされる。
ｂ）第２のサーバの場合、ｋを１にして規則５を反復し、以下の結果が得られる。
[(5mod3+1)mod3]
これは[(2+1)mod3]=Oになり、サーバ３にマッピングされる。
ｃ）同様に、ｋ＝２として規則５の次の反復を行い、以下の結果が得られる。
[(5mod3+2)mod3]
これは[(2+2)mod3]=1になり、サーバ７にマッピングされる。
３）同じ手順（規則２〜５）を第２の組の等距離サーバに使用する。まず、マッピング・インデックスは０→１２、１→２というように割り当てる。この場合、等距離サーバの数は２である。
ａ）規則５の第１の反復により以下の結果が得られる。
[(5mod2+O)mod2]=1
これはサーバ２にマッピングされる。
ｂ）ｋ＝１とした第２の反復により以下の結果が得られる。
[(5mod2+1)mod2]=O
これはサーバ１２にマッピングされる。
４）最終結果は以下のようなリストになる。
｛１、９、３、７、２、１２｝
【０１４３】
出力リストは各クライアント・ノード番号ごとに異なり、その結果、各クライアントごとに平衡リストが得られることが認められる。
【０１４４】
上記に加え、ＤＣＭは順序付きリストを維持する。一例では、ＤＣＭは、新しいサービス・ノードが追加または削除されたという通知を受け取ると必ずローカル・リストをリフレッシュする。
【０１４５】
前述したものは、クラスタ化環境を管理する場合の様々な態様である。クラスタ化アーキテクチャならびにクラスタを管理するための技法も提供される。本発明の様々な技法は、単一システム、同種システム、ならびに異種システムにも適用可能である。一例として、異種環境のシステムの相互運用性を容易にするための機能が提供される。
【０１４６】
本明細書に記載した実施形態では、グローバル・データはノードから１つまたは複数のリポジトリ（グローバル記憶域）にリモートで記憶される。しかし、他の例では、各リポジトリは１つまたは複数のノードに対してローカルなものにすることができる。さらに、各リポジトリはそのリポジトリのユーザにとってリモートまたはローカルなものにすることができる。
【０１４７】
本発明は、たとえば、コンピュータで使用可能な媒体を有する製品（たとえば、１つまたは複数のコンピュータ・プログラム）に含めることができる。この媒体では、たとえば、本発明の諸機能を提供し容易にするためのコンピュータ可読プログラム・コード手段がそこで実施されている。この製品は、コンピュータ・システムの一部として含めるか、別々に販売することができる。
【０１４８】
その上、本発明の諸機能を実行するためにマシンによって実行可能な複数命令からなる少なくとも１つのプログラムを具体的に実施し、マシンによって読取り可能な少なくとも１つのプログラム記憶装置を提供することができる。
【０１４９】
ここに示した流れ図は例にすぎない。本発明の精神を逸脱せずに、これらの図またはそこに記載されたステップ（または動作）の変形形態は多数存在する可能性がある。たとえば、そのステップは異なる順序で実行することができ、ステップの追加、削除、または修正も可能である。これらの変形形態はいずれも、ここで請求する本発明の一部と見なす。
【０１５０】
好ましい実施形態について本明細書で詳しく描写し説明してきたが、本発明の精神を逸脱せずに、様々な修正、追加、置換などが可能であり、したがって、それらは特許請求の範囲に定義した本発明の範囲内であると見なされることは、当業者にとって明らかになるだろう。
【０１５１】
まとめとして、本発明の構成に関して以下の事項を開示する。
【０１５２】
（１）コンピューティング環境のクラスタを自動的に構成する方法であって、前記方法が、
前記コンピューティング環境のクラスタに追加すべきノードにより、前記クラスタの１つまたは複数のリソースの構成データの取得を開始することと、
前記クラスタのシステム・レジストリ・コンポーネントに前記構成データを記憶することと、
前記構成データが更新されたことを前記システム・レジストリ・コンポーネントにより１つまたは複数の他のクラスタ・コンポーネントに通知することを含む方法。
（２）少なくとも前記通知の開始後に、前記クラスタに前記ノードを挿入することをさらに含む、上記（１）に記載の方法。
（３）コンピューティング環境のクラスタを自動的に構成するシステムであって、前記システムが、
前記コンピューティング環境のクラスタに追加すべきノードにより、前記クラスタの１つまたは複数のリソースの構成データの取得を開始するための手段と、前記クラスタのシステム・レジストリ・コンポーネントに前記構成データを記憶するための手段と、
前記構成データが更新されたことを前記システム・レジストリ・コンポーネントにより１つまたは複数の他のクラスタ・コンポーネントに通知するための手段とを含むシステム。
（４）少なくとも前記通知の開始後に、前記クラスタに前記ノードを挿入するための手段をさらに含む、上記（３）に記載のシステム。
（５）コンピューティング環境のクラスタを自動的に構成する方法を実行するためのプログラムであって、前記プログラムがコンピュータに
前記コンピューティング環境のクラスタに追加すべきノードにより、前記クラスタの１つまたは複数のリソースの構成データの取得を開始する機能と、
前記クラスタのシステム・レジストリ・コンポーネントに前記構成データを記憶する機能と、
前記構成データが更新されたことを前記システム・レジストリ・コンポーネントにより１つまたは複数の他のクラスタ・コンポーネントに通知する機能とを実現させるプログラム。
（６）少なくとも前記通知の開始後に、前記クラスタに前記ノードを挿入する機能をさらに含む、上記（５）に記載のプログラム。
【図面の簡単な説明】
【図１】本発明の諸態様を組み込み使用するコンピューティング環境の一例を示す図である。
【図２】本発明の一態様により、複数のクラスタを有するコンピューティング環境の一実施形態を示す図である。
【図３】本発明の一態様により、クラスタのノードの状態の一実施形態を示す図である。
【図４】本発明の一態様により使用するクラスタ・アーキテクチャのコンポーネントの一実施形態を示す図である。
【図５】本発明の一態様により、その環境の全ノードの一部分にのみ図４のシステム・レジストリ・コンポーネントが位置する、クラスタ化環境の一実施形態を示す図である。
【図６】本発明の一態様により、クラスタ化アーキテクチャの様々なコンポーネントのデータ依存関係の一例を示す図である。
【図７】本発明の一態様により、クラスタ化アーキテクチャの様々なコンポーネントの機能依存関係の一例を示す図である。
【図８】本発明の一態様により、ブートストラップ・プロセスのイベントおよびメッセージ・フローのシーケンスの一実施形態を示す図である。
【図９】本発明の一態様により、クラスタ定義データ構造の一実施形態を示す図である。
【図１０】本発明の一態様により、ノード定義データ構造の一実施形態を示す図である。
【図１１】本発明の一態様により、レジストリ・サーバ・ノードのリストの一実施形態を示す図である。
【図１２】本発明の一態様により、ローカル記憶域データ・フィールドの一例を示す図である。
【図１３】本発明の一態様により、クラスタ化システムの固有ノード識別子の一実施形態を示す図である。
【図１４】本発明のノード定義プロセスに関与するプロセスの一実施形態を示す図である。
【図１５】本発明の一態様により、ノード定義プロセスのイベントおよびメッセージ・フローのシーケンスの一実施形態を示す図である。
【図１６】本発明の自動クラスタ構成技法が使用する様々なプロセスの一例を示す図である。
【図１７】本発明の自動クラスタ構成を可能にするための図１６のプロセス間のメッセージ・フローの一例を示す図である。
【図１８】本発明の一態様により、複数のクラスタに対して定義中のノードの一例を示す図である。
【図１９】本発明の一態様により、あるクラスタから他のクラスタへ移動するノードの一例を示す図である。
【図２０】本発明の一態様により、あるクラスタから他のクラスタ内へ移動するためのプロセスのイベントおよびメッセージ・フローのシーケンスの一実施形態を示す図である。
【図２１】本発明の一態様により、ノード・アドレス定義データ構造の一例を示す図である。
【図２２】本発明の一態様により、サブネットワーク定義データ構造の一例を示す図である。
【図２３】本発明の一態様により、ネットワーク定義データ構造の一態様を示す図である。
【図２４】本発明の一態様により、サービスを位置指定するための特定アドレスを選択するためにクラスタ化環境のクライアントが使用する論理の一実施形態を示す図である。
【図２５】本発明の一態様により、ノード・アドレス定義をサブネットワーク定義およびネットワーク定義にマッピングする場合の一例を示す図である。
【図２６】本発明の一態様により、特定サービスに到達するためにクラスタ内の特定のノードが使用すべきアドレスの順序付きリストを生成するために使用する論理の他の実施形態を示す図である。
【符号の説明】
４００  分散構成マネージャ・サブシステム
４０２  システム・レジストリ・サブシステム
４０４  活性サブシステム
４０６  グループ・サービス・サブシステム
４０８  リソース・マネージャ・サブシステム
４１０  オペレーティング・システム・インスタンス１プロセス空間、オペレーティング・システム・インスタンス２プロセス空間、オペレーティング・システム・インスタンス３プロセス空間
４１２  ＤＣＭプロセス
４１４  システム・レジストリ・プロセス
【図１】
0003707728.tif 000003
【図２】
0003707728.tif 000004
【図３】
0003707728.tif 000005
【図４】
0003707728.tif 000006
【図５】
0003707728.tif 000007
【図６】
0003707728.tif 000008
【図７】
0003707728.tif 000009
【図８】
0003707728.tif 000010
【図９】
0003707728.tif 000011
【図１０】
0003707728.tif 000012
【図１１】
0003707728.tif 000013
【図１２】
0003707728.tif 000014
【図１３】
0003707728.tif 000015
【図１４】
0003707728.tif 000016
【図１５】
0003707728.tif 000017
【図１６】
0003707728.tif 000018
【図１７】
0003707728.tif 000019
【図１８】
0003707728.tif 000020
【図１９】
0003707728.tif 000021
【図２０】
0003707728.tif 000022
【図２１】
0003707728.tif 000023
【図２２】
0003707728.tif 000024
【図２３】
0003707728.tif 000025
【図２４】
0003707728.tif 000026
【図２５】
0003707728.tif 000027
【図２６】
0003707728.tif 000028