JP2002049601A - コンピューティング環境のクラスタを自動的に構成するための方法、システム、およびプログラム製品 - Google Patents

Abstract

(57)【要約】 （修正有） 【課題】 コンピューティング環境のクラスタを自動的
に構成する。 【解決手段】 グローバル・データ記憶域を提供するシ
ステム・レジストリと、クラスタ化環境のノード上にロ
ーカルにデータを記憶し、システム・レジストリ内でグ
ローバルにデータを記憶する構成マネージャと、クラス
タの通信経路の状況を提供するための活性コンポーネン
トと、クラスタ化環境の１つまたは複数の他のコンポー
ネントにサービスを提供するグループ・サービス・コン
ポーネントと、クラスタ化環境の１つまたは複数のリソ
ース・コントローラと通信するリソース管理コンポーネ
ントとを含む。各コンポーネントは、その環境の１つま
たは複数の他のコンポーネントに対する１つまたは複数
のデータ依存関係または機能依存関係あるいはその両方
を有する。コンポーネント間の関係は、データ依存関係
および機能依存関係が非周期グラフを形成する（依存関
係の循環が回避される）ように作成される。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、一般に分散コンピ
ューティング環境に関し、特に、分散コンピューティン
グ環境の複数ノードからなる１つまたは複数のクラスタ
を管理することに関する。

【０００２】

【従来の技術】分散システムは、システムに対して高ス
ループットの作業あるいは連続的またはほぼ連続的な可
用性を必要とする状況を含む、様々な状況で使用する高
可用性のスケーラブル・システムである。

【０００３】リソースを共用する能力を有する分散シス
テムはクラスタと呼ばれる。１つのクラスタは、リソー
スを共用し、互いに共同してシステム・タスクを実行す
る複数のオペレーティング・システム・インスタンスを
含む。現在、様々なクラスタ・システム（ＩＢＭが提供
するＲＳ／６０００ＳＰシステムなど）が存在するが、
依然として既存のクラスタ・システムに対してさらに機
能強化を図ることが望ましい。たとえば、クラスタ・シ
ステムの管理を容易にするための機能強化が望ましい。

【０００４】

【発明が解決しようとする課題】コンピューティング環
境のクラスタを自動的に構成するための方法、システム
およびプログラムを提供することにある。

【０００５】

【課題を解決するための手段】コンピューティング環境
のクラスタを自動的に構成する方法を提供することによ
り、従来技術の欠点が克服され、追加の利点が得られ
る。この方法は、たとえば、コンピューティング環境の
クラスタに追加すべきノードにより、そのクラスタの１
つまたは複数のリソースの構成データの取得を開始する
ことと、そのクラスタのシステム・レジストリ・コンポ
ーネントにその構成データを記憶することと、その構成
データが更新されたことをそのシステム・レジストリ・
コンポーネントにより１つまたは複数の他のクラスタ・
コンポーネントに通知することを含む。

【０００６】上記で要約した方法に対応するシステムお
よびコンピュータ・プログラムについても本明細書に記
載し、本明細書で請求する。

【０００７】本発明の技法により、追加の特徴および利
点が実現される。本発明のその他の実施形態および態様
については、本明細書で詳述し、請求する本発明の一部
と見なす。

【０００８】

【発明の実施の形態】本発明の１つまたは複数の態様に
よれば、オペレーティング・システムの１つまたは複数
のコピーを使用する分散コンピューティング環境が管理
される。オペレーティング・システムの各コピーは、そ
れが１組のリソース（たとえば、プロセッサ、ネットワ
ーク・インタフェース、ファイル、ファイル・システ
ム、記憶装置、周辺装置など）にアクセスできるように
構成される。このアクセスは、排他的なものにするか、
またはオペレーティング・システムの他のコピーと共用
することができる。リソースを共用する場合、オペレー
ティング・システムの個別コピーは共同し、それが管理
するシステム・リソースを共用する。リソースを共用す
るために、オペレーティング・システムのコピーは、リ
ソースの保全性が保持されるように、そのアクセスにつ
いて折衝する。たとえば、記憶装置の所与のセグメント
に複数のデータ・ブロックを書き込む必要があるオペレ
ーティング・システムの２つのコピーはそのセグメント
へのアクセスについて折衝するが、さもなければ、書込
み動作の順序により書込み中のデータの保全性が損なわ
れる恐れがある。

【０００９】本発明の諸態様を組み込み使用する分散コ
ンピューティング環境の一例を図１に示し、本明細書で
説明する。分散コンピューティング環境１００は、たと
えば、複数のＬＡＮゲート１０４により互いに結合され
た複数のフレーム１０２を含む。フレーム１０２および
ＬＡＮゲート１０４については以下に詳述する。

【００１０】一例の分散コンピューティング環境１００
は８個のフレームを含み、そのそれぞれは複数の処理ノ
ード１０６を含む。ある事例では、各フレームは１６個
の処理ノード（それぞれが１つまたは複数のプロセッサ
を有する）を含む。各処理ノードはたとえば、ＵＮＩＸ
（登録商標）ベースのオペレーティング・システムであ
るＡＩＸを実行するＲＩＳＣ／６０００コンピュータで
ある。１つのフレーム内の各処理ノードは、たとえば内
部ＬＡＮ接続により、そのフレームの他の処理ノードに
結合される。その上、各フレームはＬＡＮゲート１０４
により他のフレームに結合される。

【００１１】例として、各ＬＡＮゲート１０４は、ＲＩ
ＳＣ／６０００コンピュータ、ＬＡＮへのコンピュータ
・ネットワーク接続、またはネットワーク・ルータのい
ずれかを含む。しかし、これらは例にすぎない。他のタ
イプのＬＡＮゲートが存在すること、ならびに他のメカ
ニズムを使用してフレームを互いに結合できることは、
当業者にとって明らかになるだろう。

【００１２】図１の分散コンピューティング環境は一例
にすぎない。９個以上または７個以下のフレームあるい
はフレームあたり１７個以上または１５個以下のノード
を備えることは可能である。さらに、処理ノードはＡＩ
Ｘを実行するＲＩＳＣ／６０００コンピュータである必
要はない。処理ノードの一部または全部は、異なるタイ
プのコンピュータまたは異なるオペレーティング・シス
テムあるいはその両方を含むことができる。さらに、そ
の環境のノードまたはオペレーティング・システムのう
ちの１つまたは複数がその環境の他のノードまたはオペ
レーティング・システムとは異なる異種環境が本発明の
諸態様を含み使用することもできる。このような異種環
境のノードは、本明細書に記載するように、互いに共同
し、リソースを共用するという点で相互動作する。さら
に、本発明の諸態様は単一コンピュータ・システム内で
使用することもできる。これらの変形形態はいずれも、
ここで請求する本発明の一部と見なされる。

【００１３】リソースを共用する能力を有する分散コン
ピューティング環境をクラスタと呼ぶ。特に、１つのコ
ンピューティング環境は１つまたは複数のクラスタを含
むことができる。たとえば、図２に示すように、コンピ
ューティング環境２００は、クラスタＡ ２０２とクラ
スタＢ ２０４という２つのクラスタを含む。各クラス
タは１つまたは複数のノード２０６を含み、そのノード
はリソースを共用し、互いに共同してシステム・タスク
を実行する。各ノードはオペレーティング・システムの
個別コピーを含む。

【００１４】特定のクラスタに対するノードのメンバシ
ップを検討する際に２通りの態様が存在する。一方の態
様は、そのクラスタの静的構成に関するものである。こ
の態様はノード定義と呼ばれる（図３を参照）。あるノ
ードをクラスタに対して定義すると、そのクラスタ内の
他のノードはこのノードを認識する。ノードは、正常な
ノード定義動作（以下に詳述する）後にクラスタに対し
て定義される。逆に、ノード削除動作後に、ノードはク
ラスタに対して定義解除される。

【００１５】ノードの静的態様は、クラスタ・メンバシ
ップと呼ばれる動的（またはランタイム）属性とは異な
る。クラスタ・メンバシップとは、ノードが定義され、
作動可能（すなわち、オンライン）であるときにそのノ
ードがクラスタのメンバであると見なされることを意味
する。ここで、作動可能という用語は、そのノードがそ
のクラスタの他のメンバによって機能ノード、すなわ
ち、活性タスクと呼ばれる基本機能を実行可能なノード
として知覚されることをほのめかす。一例として、１つ
のノードは１組の活性タスクを連続的に実行し、一定の
間隔でクラスタの他メンバにハートビート・メッセージ
を送信することにより、そのノードがこのようなタスク
を実行できることを他のノードに報告する。

【００１６】クラスタ・メンバシップは、任意の時点で
そのクラスタの一体部分として機能しているノードのリ
ストと見なすことができる。このリストはすべてのノー
ドにとって使用可能なものであり、本発明の一態様で
は、クラスタ・アーキテクチャにより、無共用分散シス
テムでも任意の時点ですべてのノードが同じメンバシッ
プ・リストにアクセスできることが保証される。（無共
用分散システムとは、そのノードがディスクまたはメモ
リなどの共用物理リソースを一切持たないシステムであ
る。）このようなシステムで特定のデータの同一ビュー
を維持するために、高度な同期プロトコルを使用する。
というのは、アトミック・トランザクションですべての
ノードにそのデータを分散しなければならないからであ
る。

【００１７】メンバシップ・リストに対してノードを追
加するかまたはノードを削除するために、特定のプロト
コルを使用する。たとえば、メンバシップ・リストにノ
ードを追加するプロセスはノード加入プロセスと呼ばれ
る。逆に、ノード離脱プロセスにより、メンバシップ・
リストからノードを削除する。あるノードがクラスタ・
メンバシップにリストされない場合、そのノードはすで
にクラスタを離脱している。

【００１８】各クラスタは、複数のコンポーネントを含
むクラスタ・アーキテクチャによって管理される。各コ
ンポーネントは、本明細書で詳述するように、そのクラ
スタの１つまたは複数のノード上で１つまたは複数の対
応プロセスを実行する。そのコンポーネントが複数のノ
ード上で複数のプロセスを実行する場合、そのアーキテ
クチャはこれらのノード間に分散される。しかし、分散
アーキテクチャは一例にすぎない。本発明の１つまたは
複数の態様を単一または非分散システムで使用すること
ができる。

【００１９】一例では、クラスタ・アーキテクチャのコ
ンポーネントは、クラスタ・システムを構成し、ノード
がクラスタに加入するかまたはクラスタを離脱するとき
に発生するクラスタ構成データベース（後述する）の同
期を調整するために使用する分散構成マネージャ（ＤＣ
Ｍ）４００（図４）と、クラスタ構成データベース内に
記憶されたデータを供給する１つまたは複数のプロセス
を含むシステム・レジストリ・サーバ・サブシステム４
０２と、クラスタのメンバ間の通信経路の可用性に関す
る情報を提供するクラスタ・メンバシップ・リストを維
持する活性サブシステム４０４と、他のクラスタ・プロ
セスが論理グループを形成し、整合性のあるグループ状
態およびプロセス・メンバシップを維持できる機構を提
供するグループ・サービス・サブシステム４０６と、ク
ラスタ・リソースのアクセスおよび制御を管理する機構
であり、それによりクラスタ・クライアントがクラスタ
・リソースの状態および構成を監視できる機構も提供す
るリソース・マネージャ・サブシステム４０８とを含
む。

【００２０】一実施形態では、図４に示すように、各コ
ンポーネントが複数のノード４１０間に分散される。す
なわち、各コンポーネントは、複数のノード上で１つの
プロセスを実行している。たとえば、ＤＣＭ４００は図
示した３つのノード上で１つのＤＣＭプロセス４１２を
実行している。他のコンポーネントについても同じこと
が当てはまり、それぞれについては以下に詳述する。

【００２１】分散構成マネージャ（ＤＣＭ）サブシステ
ム４００は、そのクラスタの一部として構成すべき各ノ
ード上で、分散構成マネージャ・デーモン（ＤＣＭＤ）
４１２と呼ばれるコンピュータ・プログラムのコピーを
提供する。ＤＣＭＤは、クラスタのブートストラップ・
エージェントである。このため、ＤＣＭＤプロセスは、
適切なクラスタ構成により他のクラスタ・コンポーネン
トを始動することを担当する。また、ＤＣＭＤは、１つ
のノードをあるクラスタから他のクラスタに移動する場
合など、適切なときに他のクラスタ・コンポーネントを
停止するプロセスでもある。ＤＣＭＤ自体は、そのノー
ドのベース・オペレーティング・システムによってブー
トストラッピングされ、この例ではオペレーティング・
システムによって直接ブートストラッピングすべき唯一
のクラスタ・コンポーネントである。

【００２２】ＤＣＭＤは、各ノードのローカル記憶域内
にあって、１つまたは複数のクラスタ構成に関連するフ
ァイルの集合を維持する。このローカル構成データに加
え、ＤＣＭＤは、グローバル構成データもサーバ・リポ
ジトリに記憶する。このクラスタ構成データについては
以下に詳述する。

【００２３】システム・レジストリ・コンポーネント４
０２は、グローバル・データ記憶の機能を提供する。こ
れは、可用性が高く、一例では、システム・レジストリ
・プロセス４１４（図４）として複数のノード間で複製
される。しかし、一実施形態では、図５に示すように、
あるクラスタのすべてのノード上にシステム・レジスト
リが複製されるわけではない。図５に示すように、ノー
ド（すなわち、オペレーティング・システム・インスタ
ンス）１、２、３はシステム・レジストリ・プロセス５
００を含むが、ノード４〜８は含まない。しかし、この
特定の例のノードはいずれも他のコア・クラスタ・プロ
セス（たとえば、ＤＣＭプロセス、活性プロセス、グル
ープ・サービス・プロセス、リソース・マネージャ・プ
ロセス）を含む。ノード４〜８はレジストリ・クライア
ント・ノードと見なされ、ノード１〜３はレジストリ・
サーバ・ノードと見なされる。というのは、レジストリ
機能がこれらのノード上で実行されるからである。

【００２４】活性コンポーネント４０４（図４）は、通
信アダプタの状況と、そのクラスタ内のノード間の通信
経路の可用性を提供する。各ノードは、１つまたは複数
の通信アダプタを介して通信ネットワーク５０２（図５
に示すもの）に接続される。このようなアダプタのいず
れかが故障し、クラスタ・ノードを相互接続するネット
ワーク内の１つまたは複数の通信経路に影響する可能性
もある。活性コンポーネントはそのクラスタの１つまた
は複数のノード内でプロセスを実行するが、そのプロセ
スは各ノード内の各通信アダプタからハートビートとい
う定期検証メッセージを送信する。ノード内の活性プロ
セスの集合は各アダプタの可用性に関する部分的な知識
に関するメッセージを交換し、これらのメッセージによ
り活性システムは、クラスタ・システム内の各通信アダ
プタの状態と、任意の２つのアダプタ間の通信経路の可
用性についても論理的に推論することができる。

【００２５】グループ・サービス・コンポーネント４０
６は、他のコンポーネントに対して総称メンバシップ・
サービスを提供する。このようなサービスとしては、ア
トミック・ブロードキャストとも呼ばれる２フェーズ・
コミット・プロトコルを実行するための機構を含む。こ
れは、あるグループのメンバがそのグループのメンバシ
ップを制御し、グループ状態を維持できるようにする機
構も含む。

【００２６】リソース管理コンポーネント４０８は、コ
ア・クラスタ・サービス（たとえば、ＤＣＭ、システム
・レジストリ、活性、グループ・サービスおよびリソー
ス・マネージャ）の一部ではない他のクラスタ・サービ
スへの基本通信層を提供する。これらのサービスは、後
述するように追加のリソース・コントローラのカテゴリ
に分類される。一例では、この通信プロトコルはオブジ
ェクト指向のものである。したがって、リソース管理コ
ンポーネントによって制御すべきリソース・コントロー
ラは、それが制御するリソース・オブジェクトを定義す
るリソース記述ファイルをリソース管理コンポーネント
に提供する。この定義は、１組の属性またはデータ・フ
ィールドならびに各リソース・コントローラがサポート
する１組の機能によって行われる。

【００２７】クラスタ・アーキテクチャの各コンポーネ
ントは、そのアーキテクチャの１つまたは複数の他のコ
ンポーネントに対する１つまたは複数のデータ依存関係
または機能依存関係あるいはその両方を有し、それは様
々なコンポーネント間の関係（すなわち、コンポーネン
ト間関係）を定義するものである。このような関係は、
本発明の一態様により、データ依存関係および機能依存
関係が非周期グラフを形成する（すなわち、依存関係の
循環が回避される）ように設計されている。

【００２８】各コンポーネントのデータ依存関係の一例
を図６に図示し、以下に詳述する。 （Ａ）システム・レジストリ： システム・レジストリ
は、クラスタの他のコンポーネントに対していかなるデ
ータ依存関係６００も持っておらず、これはシステム・
レジストリの固有の特性である。システム・レジストリ
自体は、その構成データをすべて記憶することができ
る。システム・レジストリ・コンポーネントは、依存関
係グラフ内のリーフとして使用でき、その結果、いかな
る循環関係も回避できるように設計されている。システ
ム・レジストリは、可用性が高くなるようにそれ自体の
構成データを記憶する能力を有する。また、システム・
レジストリは、トランザクション論理を使用して要求が
伝播される複製データ・リポジトリとして設計されてい
る。 （Ｂ）分散構成マネージャ（ＤＣＭ）： ＤＣＭコンポ
ーネントは、すべてのノード上でローカルにコア・クラ
スタ構成データのローカル・バージョンを記憶する能力
ならびにシステム・レジストリにグローバル・データを
記憶する能力を有する。一例では、ローカル構成データ
の少なくとも一部分はグローバル・データと整合性のあ
るものでなければならない。しかし、場合によっては、
ＤＣＭサブシステムによって記憶されたローカル構成デ
ータがシステム・レジストリ・サブシステムにグローバ
ルに記憶されたデータにより順序が乱れる可能性も考え
られる。これは、たとえば、そのノードが一例としてメ
ンテナンスのためにクラスタから切断されている間に更
新を逸した場合に発生することになる。 たとえば、ノードは誤動作し、修理のために送られる場
合がある。その間、クラスタ化システムのシステム管理
者は、損傷したノードを定義解除し、したがって、ノー
ド定義解除動作によりその定義をグローバル・レジスト
リから削除することを決定することができる。損傷した
ノードが修理され、クラスタに再接続されると、それは
クラスタに対して定義解除されているので、もはやクラ
スタ・リソースを共用できなくなるはずである。それに
もかかわらず、最近修理したノード内のローカル・クラ
スタ構成は時代遅れになっており、依然としてそのノー
ドをクラスタに対して定義済みのものとして示す。この
ような場合を削除するため、他のすべてのクラスタ・コ
ンポーネント用のブートストラップ・エージェントであ
るＤＣＭＤデーモンは、ノード加入プロセスを開始する
前にローカル・クラスタ定義の妥当性をチェックする。
これにより、システム・レジストリ・コンポーネントに
対するＤＣＭＤデーモンのデータ依存関係６０２が作成
される。 （Ｃ）残りのコア・クラスタ・コンポーネント（活性、
グループ・サービス、およびリソース管理）は、ＤＣＭ
によって記憶されたローカル・クラスタ構成を使用する
ので、分散構成マネージャ・コンポーネントに対して共
通のデータ依存関係６０４を有する。たとえば、ローカ
ル・クラスタ構成は、このアーキテクチャ内のクラスタ
・コンポーネントが使用する、レジスタ・サーバ・プロ
セスを実行するノードのリストならびにノード名および
番号などのブートストラップ情報を含む。システム・レ
ジストリ・コンポーネント自体を除き、他のコンポーネ
ントは、レジストリ・サーバに接続し、後述するグロー
バル・クラスタ構成を検索するために、そのノード・リ
ストを使用する。 （Ｄ）システム・レジストリ自体を除き、すべてのコン
ポーネントは、グローバル・クラスタ構成に対するデー
タ依存関係を有する。

【００２９】各コンポーネントの機能依存関係の一例を
図７に図示し、以下に詳述する。 （Ａ）分散構成マネージャ（ＤＣＭ）： ＤＣＭは、シ
ステム・レジストリ・コンポーネントによって提供され
るグローバル記憶機能の可用性に依存する（参照番号７
００を参照）。 （Ｂ）システム・レジストリ： システム・レジストリ
は、グループ・サービス・コンポーネントに対する機能
依存関係７０２を有する。この依存関係は、書込み動作
を伝播するために、システム・レジストリがグループ・
サービス・コンポーネントのメンバシップ・サービスを
使用することによって発生する。グローバル・クラスタ
構成データはレジストリ・サーバ・ノードとして機能す
る各ノード内で複製されるので、それに対する修正は複
製書込み動作を必要とする。このような書込み動作中に
は、複製の１つが故障し、複製動作の分散回復のための
論理を実現することが望ましくなる恐れがある。グルー
プ・サービス・コンポーネントによって提供されるメン
バシップ・サービスは、このような分散回復論理の一例
を含む。しかし、グループ・サービス・コンポーネント
に対する機能依存関係は書込み動作のみに影響する。シ
ステム・レジストリ・コンポーネントは、読取りタイプ
の動作の場合にグループ・サービス・コンポーネントに
対する依存関係を一切持たない。したがって、システム
・レジストリ・コンポーネントは、ＤＣＭＤコンポーネ
ントによってブートストラッピングした後、その初期設
定の第１のフェーズ（以下に詳述する）を完了すること
ができる。このフェーズが完了した後、システム・レジ
ストリは、クラスタ構成データベースの最も最近更新し
たコピーをすでに検索しており、他のコンポーネントが
クラスタ構成データを読み取れるようにすることができ
る。次に、これにより、グループ・サービス・コンポー
ネントはそれ自体の初期設定を完了することができ、そ
れにより、後述するようにシステム・レジストリ・コン
ポーネントがその初期設定の第２のフェーズを続行する
ことを可能にする。 （Ｃ）活性コンポーネント： 活性コンポーネントは、
ＤＣＭＤによってブートストラッピングされ（参照番号
７０４を参照）、活性サブシステムの構成をレジストリ
に記憶する（参照番号７０５を参照）。これは、他のコ
ンポーネントに対する他の機能依存関係を一切持ってい
ない。 （Ｄ）グループ・サービス・コンポーネント： グルー
プ・サービス・コンポーネントはＤＣＭＤによってブー
トストラッピングされる（７０６）。これは、クラスタ
内のノード間の通信経路の可用性を知る必要があるの
で、活性コンポーネントに対する機能依存関係（７０
８）も有する。 （Ｅ）リソース・マネージャ・コンポーネント： リソ
ース・マネージャ・コンポーネントはＤＣＭＤによって
ブートストラッピングされる（７１０）。これは、グル
ープ・サービス・コンポーネントによってエクスポート
されるグループ・メンバシップ機能に対する依存関係
（７１２）も有する。これは、その構成データベースの
バージョン番号を決定するためにメンバシップ機能を使
用する。 また、追加のリソース・マネージャも、ＤＣＭに対する
機能依存関係（７１４）ならびにリソース・マネージャ
・コンポーネントに対する機能依存関係（７１６）を有
する。

【００３０】コンポーネントのデータ依存関係または機
能依存関係あるいはその両方は、クラスタ化技法のブー
トストラップ・プロセス中に満足される。一例では、ク
ラスタ・ブートストラップ・プロセス中に依存関係を満
足するために、特定のシーケンスのイベントおよびメッ
セージを使用する。このシーケンスの一例については図
８に示し、本明細書で説明する。

【００３１】ステップ０でブートストラップ・シーケン
スを開始する。クラスタ・アーキテクチャは、たとえ
ば、オペレーティング・システムによって開始されるソ
フトウェアの層として設計されている。基本オペレーテ
ィング・システム・ブートストラップ・プロセス後に、
オペレーティング・システムは、分散構成マネージャ・
プロセスを始動することによりクラスタ・ソフトウェア
をブートストラッピングする。次に、ＤＣＭＤデーモン
を始動し、オペレーティング・システム・インスタンス
の存続期間にわたってそれを実行する。

【００３２】前述したように、ＤＣＭは、（一例とし
て）各ノードのローカル記憶域に記憶された１組のデー
タ構造を維持する。このデータ構造としては、たとえ
ば、クラスタ・データ構造９００（図９）、ノード定義
データ構造９０２（図１０）、レジストリ・サーバ・ノ
ード・データ構造９０４（図１１）を含み、そのそれぞ
れについては後述する。

【００３３】クラスタ・データ構造９００は、たとえ
ば、クラスタ名９０６と固有クラスタ識別子９０８を含
む。一例では、固有識別子をキー・フィールド（固有フ
ィールド）として使用する。クラスタ・データ構造内の
キー・フィールドは、同じクラスタ名でラベルを付け替
えられないようにオペレーティング・システムの個別イ
ンスタンスを保護する。クラスタは、人間の管理者によ
って作成される場合が多く、多数のプロセッサの構成プ
ロセス中に同一名で容易にラベルを付けられる可能性が
ある。さらに、本明細書に記載するクラスタ構成インフ
ラストラクチャは、非常に動的なものであり、したがっ
て、クラスタの作成および削除を可能にするものであ
る。クラスタは、分散システムのニーズに応じて動的に
作成し破壊することができる。固有識別子は、後述する
クラスタ定義動作によってクラスタが作成されたときに
生成される。この特徴により、クラスタ名の再利用の検
出が可能になる。たとえば、Ａというラベルが付いたク
ラスタを作成し、削除し、もう一度作成した場合、固有
識別子フィールドが別個のものになるので、Ａに関する
この２通りの定義のデータ構造は異なるものになるだろ
う。

【００３４】さらに、クラスタ定義データ構造内の固有
識別子は他のクラスタ・リソースのマッピングのルート
にある。このシステムでは、クラスタ・データ構造用の
固有識別子はクラスタ・リソース内のラベルの接頭部に
ある。固有識別子マッピングと本明細書に記載するアー
キテクチャの使用により、クラスタ構成の間違った想定
のもとにクラスタ・リソースがクライアントによってア
クセスされるのを防止する。

【００３５】ノード定義データ構造９０２は、たとえ
ば、ノード番号９１０と、人間の管理者にとってノード
識別をより容易にするために便利なものとして使用する
が、いずれのクラスタ・リソース・マネージャもノード
の構成にアクセスする手段として使用しないノード名９
１２と、ノードの定義を識別する固有ノード識別子９１
４とを含む。固有識別子は、特定のオペレーティング・
システム・インスタンスに関連する。この識別子は、あ
るノードがクラスタに対して定義されるたびに生成され
る。この固有識別子により、同じ名前を持つ２つのノー
ド間の区別、ならびにすでにクラスタに対して定義さ
れ、定義解除され、その後、同じ名前でもう一度定義さ
れた（再定義された）ノードとの区別が可能になる。

【００３６】レジストリ・サーバ・ノード・データ構造
９０４は、クラスタに対して定義されるレジストリ・サ
ーバ・ノードのリストを含む。一例では、このデータ構
造は、レジストリ・サーバの順序付きリスト９１６と、
１次レジストリ・サーバの表示９１８とを含む。このリ
ストは、後述するように、システムのグローバル構成デ
ータを読み取るためにシステム・レジストリ・プロセス
へのアクセスを希望する他のクラスタ・コンポーネント
によって検索される。

【００３７】上記のローカル・データ構造に加え、各ク
ラスタ・コンポーネントはローカル記憶域データ構造を
維持し、各コンポーネントはローカル・ノードに関連す
る情報を記憶するための予約空間である。ローカル・デ
ータ構成の一例を図１２に示し、以下に説明する。

【００３８】ただし、図１２に示すデータ構造はＵＮＩ
Ｘ（登録商標）オペレーティング・システムにおける本
発明の具体的な実施例から導出されたものであるが、他
のオペレーティング・システムにおける同様の実施例も
可能であり、本発明の精神から逸脱するものではないこ
とに留意されたい。

【００３９】ローカル記憶域データ・フィールドの一例
について以下に説明する。 １．「/」（１０００）は、オペレーティング・システ
ム内のルート・ファイル・システムを示す。 ２．「/var」（１００２）は、オペレーティング・シス
テム拡張機能に関連するデータが記憶されるファイル・
システムである。 ３．クラスタ論理は、「/var/ct」（１００４）にロー
カル構成情報を記憶する。 ４．「/var/ct/dcm」ディレクトリ（１００６）は分散
構成マネージャ・コンポーネントによって所有される。
この例では、ＤＣＭコンポーネントは、他のクラスタ・
コンポーネントとしてクラスタＩＤ以下のディレクトリ
にそれを記憶するのとは対照的に、それ自体のデータを
記憶するためにより上位レベルのディレクトリを有する
唯一のコンポーネントである。これは、この特定の例で
は、ＤＣＭが、１つのノードを複数のクラスタに定義で
きることを認識している唯一のクラスタ・コンポーネン
トであるからである。 ５．「/var/ct/dcm/configuration」ディレクトリ（１
００８）には、ＤＣＭはそのノードを定義する対象とな
るクラスタのリストを記憶する。また、ＤＣＭは、その
ノードが現在属しているクラスタのＩＤもこのディレク
トリに記憶する。このＩＤは、ローカル構成データをど
こから読み取るべきかを決定するために他のクラスタ・
コンポーネントが使用する。 ６．「/var/ct/dcm/logs」ディレクトリ（１０１０）に
は、ＤＣＭコンポーネントは、監査機構として使用す
る、そのランタイム・ログを記憶する。 ７．ノードを定義する対象となるクラスタごとに、ＤＣ
Ｍは、「/var/ct」の下に「/var/ct/cluster_ID」とい
うラベルが付いたディレクトリ（１０１２）を作成する
が、「cluster_ID」というリテラルは以下に説明するよ
うに固有クラスタ識別子によって置換される。このディ
レクトリの下にＤＣＭは他に４つのディレクトリも作成
し、そこには他のクラスタ・コンポーネントがそれぞれ
のランタイム・ロック１０１４、ランタイム・ログ１０
１６、ランタイム・コア情報１０１８、構成データ１０
２０を記憶することができる。

【００４０】ローカル構成データに加え、ＤＣＭは、グ
ローバル構成データも記憶する。サーバ・リポジトリに
記憶されるグローバル構成データとしては、たとえば、
クラスタ定義データ構造のコピーならびにノード定義デ
ータ構造のコピーを含む。クラスタ・データ構造および
ノード定義データ構造のフィールドの値は、あるノード
がそのクラスタに対して定義されたときに設定され、依
然として整合性のあるものでなければならない。処理中
にローカル・データ構造のデータ・フィールドはグロー
バル・データ構造のデータ・フィールドと比較される。
この比較により何らかの差が得られた場合、これは、ノ
ード定義がそのクラスタではもはや有効ではないことを
示す可能性がある。

【００４１】図８に戻ると、ＤＣＭＤプロセスを開始し
た後、ＤＣＭＤプロセスはシステム・レジストリ・プロ
セスを開始し、レジストリ・サーバ・ノードとして構成
されたノードを始動する（ステップ１）。このステップ
は、システム・レジストリ・コンポーネントのブートス
トラップ要件を満足するものである。

【００４２】ステップ２〜４でＤＣＭＤデーモンは、た
とえば、そのクラスタのすべてのノード内の活性コンポ
ーネント、グループ・サービス・コンポーネント、リソ
ース・マネージャ・コンポーネントを始動する。

【００４３】次にステップ５でシステム・レジストリ・
サブシステムはその初期設定の第１のフェーズを実行す
る。特にこのサブシステムは、最も最近使用可能になっ
たグローバル構成データベースのコピーを検索する手順
を実行する。このフェーズ中、ＤＣＭＤによってブート
ストラッピングされたシステム・レジストリ・プロセス
は、グローバル構成データベースの実現番号を含むメッ
セージを交換する。次にシステム・レジストリ・コンポ
ーネントは、最高の実現番号を有する構成データベース
のコピーを選択する。このようなコピーは、後述するよ
うにコンポーネントの初期設定の第２のフェーズを続行
することができる。

【００４４】初期設定の第１のフェーズの完了後、シス
テム・レジストリ・コンポーネントにより他のコンポー
ネントは読取りタイプの動作を発行することができ、そ
れにより他のコア・クラスタ・コンポーネントはそれぞ
れの初期設定を完了することができる。すなわち、第１
の初期設定フェーズが完了した後、システム・レジスト
リ・サブシステムは、他のクラスタ・コンポーネントに
グローバル・クラスタ構成データを供給できるようにな
る。システム・レジストリ・コンポーネントにより、他
のコンポーネントはグローバル構成データを読み取るこ
とができるが、グローバル構成に修正を加えることはで
きない。これは、グローバル構成データに対する修正が
書込み動作によって行われるからであり、システム・レ
ジストリ・コンポーネントが書込み動作を実行するため
にグループ・メンバシップ機能に対する依存関係を有す
るからである。このため、グローバル・クラスタ構成デ
ータを修正する動作は、後述するようにシステム・レジ
ストリ初期設定の第２のフェーズが完了するのを待つ必
要がある。

【００４５】ステップ６でＤＣＭＤは、システム・レジ
ストリからグローバル・クラスタ構成データを読み取る
ことができる。したがって、ステップ７でＤＣＭＤは、
それが各ノードに記憶するローカル構成がシステム・レ
ジストリに記憶されたグローバル・クラスタ構成と整合
性のあるものであるかどうかを検証することができる。
ＤＣＭＤコンポーネントはこの時点でもグローバル・ク
ラスタ構成に変更を加えることができない。というの
は、システム・レジストリはまだ動作を書き込むことが
できないからである。それにもかかわらず、ＤＣＭＤ
は、ローカル構成がグローバル・クラスタ構成と整合性
のあるものであるかどうかを判定し、次にクラスタ・ブ
ートストラップ・プロセスを続行し、最終的に他の依存
関係を満足することになる他のコンポーネントを始動す
ることができ、次にシステム・レジストリはその初期設
定の第２のフェーズを完了することができ、書込み可能
状態になる。

【００４６】ステップ８で活性コンポーネントはグロー
バル構成データを読み取るはずである。しかし、そのコ
ンポーネントはまず、システム・レジストリ・サーバの
位置を把握し、情報がローカル・クラスタ構成内にある
ことを把握する必要がある。したがって、活性コンポー
ネントは、この情報を検索するためにＤＣＭＤへの呼出
しを行う。

【００４７】ステップ９では、前のステップと同様の手
順でグループ・サービス・コンポーネントがＤＣＭＤコ
ンポーネントからローカル・クラスタ構成データも検索
する。

【００４８】ステップ１０で活性サブシステムは、シス
テム・レジストリ・サーバからグローバル構成データを
読み取ることにより、グローバル構成データに対するそ
の依存関係を満足する。さらにステップ１１で活性コン
ポーネントは、すでにその依存関係をすべて履行してい
るので、その初期設定を終結し、他のクラスタ・コンポ
ーネントがその活性機能を使用できるようにすることが
できる。

【００４９】ステップ１２でグループ・サービス・コン
ポーネントはシステム・レジストリからグローバル構成
データを読み取ることもできる。次にグループ・サービ
ス・コンポーネントは、ステップ１３に示すように、活
性コンポーネントからの活性機能を使用することができ
る。

【００５０】ステップ１４でグループ・サービス・コン
ポーネントは、その初期設定を完了し、他のクラスタ・
コンポーネントがグループ・メンバシップ機能を使用で
きるようにすることができる。

【００５１】ステップ１５でシステム・レジストリ・コ
ンポーネントはそのメンバシップ・サービスの要件を満
足し、それによりシステム・レジストリは初期設定手順
の第２のフェーズを実行できるようになる。このフェー
ズでは、第１のフェーズで決定したようにより低い実現
番号を有するグローバル構成データベースのコピーが、
グループ・サービス・コンポーネントによって提供され
るメンバシップ・サービスを使用して更新される。これ
により、システム・レジストリ・コンポーネントは、そ
の初期設定の第２のフェーズを終了することができ、グ
ローバル・クラスタ構成に照らし合わせて書込み動作を
発行することができる。

【００５２】ステップ１６でシステム・レジストリ・コ
ンポーネントは、その初期設定の第２のフェーズを終結
する。このフェーズが完了した後、システム・レジスト
リ・コンポーネントは、複製書込み動作を実行するため
にメンバシップ・サービスを使用することができ、した
がって、他のクラスタ・コンポーネントがそれぞれのグ
ローバル・クラスタ構成データベースに修正を加えるこ
とができるようになる。

【００５３】ステップ１７でリソース・マネージャ・コ
ンポーネントは、ＤＣＭＤコンポーネントからローカル
構成データを検索する。リソース・マネージャ・コンポ
ーネントは、システム・レジストリからグローバル構成
データを読み取り、それに対して所望の修正を加える
（ステップ１８）。

【００５４】さらに、ステップ１９でリソース・マネー
ジャ・コンポーネントは、グループ・サービス・コンポ
ーネントのメンバ・サービスを使用して、その公正デー
タベースのバージョン番号を決定する。その時点でリソ
ース・マネージャ・コンポーネントは、そのデータおよ
び機能要件がすべて履行されており、その初期設定を完
了している（ステップ２０）。したがって、リソース・
マネージャ・コンポーネントは、他の構成済みリソース
・コントローラをブートストラッピングすることができ
る（ステップ２１）。

【００５５】追加のリソース・コントローラは、ＤＣＭ
Ｄコンポーネントからローカル・クラスタ構成を読み取
り（ステップ２２）、システム・レジストリからグロー
バル・クラスタ構成を読み取る（ステップ２３）。さら
に、これらのコントローラは所望の修正を実行する。ス
テップ２４で追加のリソース・コントローラはそれぞれ
の初期設定を終結する。

【００５６】上記のブートストラップ・プロセスの実行
後、すべてのクラスタ・コンポーネントは完全に使用可
能になり、コンポーネントのデータおよび機能要件はす
べて履行される。

【００５７】クラスタを管理するため、本発明の少なく
とも一態様により様々な定義動作を使用する。このよう
な動作としてはたとえば以下のものを含む。 （Ａ）新しいクラスタ定義を作成するクラスタ定義動
作。特に、この動作が発行されるノードにローカル・ク
ラスタ構成を記憶するために新しいクラスタ識別子と新
しいローカル記憶域が作成される。この新しいローカル
記憶域は、ディレクトリ・パス内の新しいクラスタ識別
子を有するディレクトリに置かれる。また、この動作
は、新しいグローバル記憶域も作成する。ＤＣＭコンポ
ーネントは、この動作が発行されるノードをレジストリ
・サーバ・ノードとする。また、このプロセスでＤＣＭ
コンポーネントは、システム・レジストリ・プロセスを
ブートストラッピングし、前述のように本明細書で定義
するグローバル・クラスタ・データ構造を作成する。 （Ｂ）クラスタ定義解除動作は、クラスタ定義を消去す
るために使用する。この動作は、クラスタの一部になる
よう定義されたすべてのノード内のローカル・クラスタ
定義を消去する。また、これは、システム・レジストリ
・コンポーネントによって管理されるグローバル・クラ
スタ記憶域のすべてのコピーも消去する。 （Ｃ）クラスタ修正動作は、クラスタ定義の属性を修正
するために使用する。修正可能な属性の１つはクラスタ
名である。この属性は、クラスタ・コンポーネントが内
部で使用しないので修正することができる。むしろ、ク
ラスタの識別に内部で使用するのはクラスタＩＤであ
る。 （Ｄ）ノード定義動作は、クラスタに対してノードを定
義するために使用する。クラスタはクラスタ定義動作に
よってすでに確立されている。新しいローカル記憶域は
新たに定義したノード内に作成される。また、グローバ
ル記憶域に記憶されるクラスタ定義も新しいノード定義
によって更新される。 （Ｅ）ノード定義解除動作は、ノードの定義をグローバ
ル・クラスタ構成およびグローバル記憶域から消去する
ために使用する。また、この動作は、特定のクラスタの
ノードの定義に関連する、そのノード内のローカル記憶
域も消去する。 （Ｆ）レジストリ・サーバ・ノード定義動作は、クラス
タ内の特定のノードをレジストリ・サーバ・ノードとし
て定義する。この動作後、ＤＣＭコンポーネントはその
ノードをレジストリ・サーバ・ノードとして識別し、必
要であるかまたは望ましいかあるいはその両方の場合に
ノード内でレジストリ・サーバ・プロセスをブートスト
ラッピングする。 （Ｇ）レジストリ・サーバ・ノード定義解除は、レジス
トリ・サーバ・ノードとしてのノード定義を除去する動
作である。この動作後、システム・レジストリ・プロセ
スはもはやそのノード上でブートストラッピングされな
くなる。 （Ｈ）ノード修正動作は、グローバル・クラスタ構成な
らびにローカル記憶域内の両方でノード定義の属性を変
更する。変更可能なノード構成の属性の１つは、ノード
の名前である。

【００５８】様々な定義動作に加え、様々な制御動作を
使用して、クラスタ、ノード、レジストリ・サーバを管
理する。このような動作としてはたとえば以下のものを
含む。 （Ａ）オンライン・クラスタ動作は、クラスタに対して
定義されることが分かっている他のすべてのノードへの
接触を試みるためにノード内でプロセスを開始し、それ
らのノードがオンラインに移行することを要求する。 （Ｂ）オフライン・クラスタ動作は、クラスタに対して
定義されることが分かっている他のすべてのノードに接
触し、それらのノードがオフラインに移行することを要
求する。 （Ｃ）オンライン・ノード（加入）動作は、ノードをオ
ンラインで特定のクラスタに移動するようＤＣＭプロセ
スに要求する。この要求により、ＤＣＭコンポーネント
はクラスタ・ブートストラップ手順で前述したアクショ
ン・シーケンスを開始することになる。 （Ｄ）オフライン・ノード動作は、オフラインになるよ
う特定のノードに要求する。この動作は、ノード上で動
作している他のすべてのクラスタ・コンポーネントを停
止するようＤＣＭコンポーネントに要求する。 （Ｅ）オンライン・レジストリ・サーバ動作は、特定の
ノードでシステム・レジストリ・プロセスをブートスト
ラッピングするようＤＣＭコンポーネントに要求する。 （Ｆ）オフライン・レジストリ・サーバ動作は、特定の
ノードでシステム・レジストリ・プロセスを停止するよ
うＤＣＭコンポーネントに要求する。

【００５９】クラスタを管理するために、上記の定義お
よび制御動作のそれぞれを使用することができる。これ
らの動作の１つまたは複数については以下に詳述する。

【００６０】本明細書に記載するように、本発明の一態
様のクラスタ・アーキテクチャは、オペレーティング・
システム・インスタンス（すなわち、ノード）がクラス
タに対して定義されたときに生成される固有識別子を使
用する。固有識別子は、クラスタ・システムの実施例に
とって意味のあるものになるように生成される（図１３
を参照）。たとえば、単一オペレーティング・システム
・コンピュータ１１００の場合、ある事例では、システ
ムのマザー・ボード内の読取り専用メモリ（ＲＯＭ）に
記憶された番号から固有識別子が導出される。

【００６１】複数オペレーティング・システム・コンピ
ュータ１１０２の場合、オペレーティング・システム・
インスタンスは、既知の固有識別子生成技法を使用し
て、そのノードが定義されたときに固有識別子を生成す
るだけの可能性がある。

【００６２】さらに、区別された１つのハードウェアを
有するコンピューティング装置１１０４の場合、オペレ
ーティング・システムのアイデンティティはその単一ハ
ードウェアから導出される。このような実施例は、許可
ユーザの識別にスマート・カードを使用する装置内な
ど、様々な応用例では意味のあるものである。

【００６３】この識別子は、ローカル構成記憶域ならび
にグローバル構成データベースの両方に記憶される。両
方のタイプの記憶域を使用するので、いずれかに理由
（たとえば、メンテナンス手順）によりデータの順序が
乱れる場合にデータを調整するために、本発明の一態様
により１組の規則が提供される。たとえば、順序が乱れ
たデータがノードの識別子である場合、その識別子を調
整するために１組の規則が提供される。この特定の例に
ついては以下に詳述する。しかし、他の不整合データを
調整するために同様の規則を使用することを理解された
い。

【００６４】分散クラスタ・システムは１組のマシンで
あり、そのそれぞれは別々の時期に通信ネットワークか
ら切断することができるので、オペレーティング・シス
テムの１つのインスタンスは、それが所与のクラスタの
１つのノードとして定義されたときに識別される。しか
し、オペレーティング・システムのそのインスタンスは
電源異常またはメンテナンス動作のために停止する可能
性があり、それが所与のクラスタのメンバとして定義さ
れている場合にそれ自体をそうであると理解することが
できるはずである。したがって、ノードがクラスタに加
入するたびに、それは、ローカル記憶域内の固有識別子
がそのノード用のグローバル識別子と一致するかどうか
をチェックする。

【００６５】特に、一実施形態では、基本オペレーティ
ング・システムの基本ブートストラップ・プロセス中に
オペレーティング・システムによって固有識別子が読み
取られる。次に基本オペレーティング・システムは、ク
ラスタ・ブートストラップ・シーケンスの開始時に分散
構成マネージャに固有識別子を渡す。次に分散構成マネ
ージャは、クラスタに対してそれが定義されたときにグ
ローバル記憶域１１０６とローカル記憶域１１０８の両
方にこの固有識別子を記憶する。分散構成マネージャ
は、クラスタにノードを加入する動作を実行するたび
に、固有識別子の３通りのインスタンス（すなわち、ブ
ートストラップ・シーケンスの際にオペレーティング・
システムが渡す識別子であって、ここでオリジナル・コ
ピーと呼ぶ識別子（ＵＩＤ）１１１０、ローカルで記憶
した（キャッシュした）コピー１１０８、グローバルで
記憶したコピー１１０６）の妥当性をチェックする。

【００６６】ノードがクラスタに加入するプロセス中
に、この３つの識別子を以下のように比較する。 １）オリジナル識別子をローカル識別子と比較する。 ２）ローカル識別子をグローバル識別子と比較する。

【００６７】この比較により、以下に示す４通りの結果
が得られる可能性がある。

【００６８】

【表１】

【００６９】次に分散構成マネージャは、たとえば、上
記のシナリオのそれぞれに応じて以下のアクションを採
用する。 シナリオ１： この場合、３つの識別子はすべて同じで
あり、したがって、ノード定義は正しいものである。こ
れは通常ケースである。他の３通りのケースは、メンテ
ナンス動作など、ノード定義に影響する動作の結果とし
て存在するだけである。 シナリオ２： この場合、オリジナル識別子はローカル
識別子と等しいが、ローカル識別子はグローバル識別子
と同じではない。これは、ノードがクラスタに接続され
ていない間にノード定義を削除したときに発生する。ノ
ードはクラスタに接続されていないので、ノード削除プ
ロセスに関与することができない。したがって、ノード
が削除されたという趣旨で、ローカル・データ構造の更
新は行われない。ノード上でのメンテナンスが終了し、
ノードが再加入しようと試みると、そのノードはそれ自
体の削除を通知し、したがって、そのノードが特定のク
ラスタから削除されたという趣旨で、ローカル・データ
定義をクリーンアップできるようになる。 シナリオ３： この場合、オリジナル識別子はローカル
識別子と一致せず、ローカル識別子はグローバル識別子
と一致する。したがって、オリジナル識別子は、たとえ
ば、メンテナンス動作時に置き換えられている。これ
は、置き換えなければならないハードウェア・リソース
からオリジナル識別子が得られたときに発生する。この
ようなリソースの例は、それぞれの固有識別子が読取り
専用メモリ（ＲＯＭ）に記憶されているマザー・ボード
およびスマート・カードである。オリジナル識別子が記
憶されているハードウェアを置換することが必要になる
かまたは望ましくなる場合、クラスタ論理は、このケー
スをシナリオ２および４のような間違った定義とは区別
しなければならない。この場合、ローカル識別子とグロ
ーバル識別子は一致しており、ノード定義が依然として
クラスタ内で有効であることを示す。したがって、実行
するアクションは、オリジナル識別子が置き換えられた
という趣旨で、ノード定義を訂正することになる。した
がって、分散構成マネージャは、新しいオリジナル識別
子と一致するようにローカル識別子とグローバル識別子
を両方とも変更する。 シナリオ４： この場合、オリジナル・ノード識別子は
ローカル識別子と一致せず、ローカル識別子はグローバ
ル識別子と一致しない。したがって、このノードには２
回のメンテナンス動作が行われている。これは、ノード
がクラスタから切断されている間にグローバル構成から
削除されており、オリジナル識別子も置き換えられてい
る。このケースは上記のシナリオ２に類似している。と
いうのは、グローバル構成がローカル記憶域に最後にキ
ャッシュされた値と一致しないことが決定要因になるか
らである。したがって、実行するアクションは、ノード
がクラスタから削除されたという趣旨で、ローカル・デ
ータ定義をクリーンアップすることになる。

【００７０】一実施形態では、シナリオ３などの所与の
シナリオで分散クラスタ・マネージャはオリジナル識別
子の自動訂正を実行することができるが、これはそのク
ラスタを識別する固有ハードウェアがメンテナンス動作
で置き換えられた場合に所望の効果である。この特徴に
より、たとえば、前のカードを紛失した場合に他のスマ
ート・カードを使用できるようになるだろう。分散構成
マネージャは、グローバル・データベースで値を調べる
ことにより、クラスタに対して前に定義されたマシンを
識別することができる。しかし、シナリオ４に例示する
ように、事前にクラスタに対して定義されていないマシ
ンで新しいカードを使用することはできないだろう。こ
の特徴も所望のものである。というのは、クラスタ定義
動作は、クラスタに対して定義すべきマシンが実行しな
ければならない明示動作であるからである。

【００７１】クラスタ・システムのメンバとしてノード
を確実に定義し、クラスタを加入するためのデータ整合
性の維持に関する詳細について、以下に説明する。

【００７２】ローカル構成とグローバル・クラスタ構成
データベースの両方に変更が加えられ、両方のリポジト
リのデータが整合性を維持しなければならないので、ノ
ード定義動作などの動作はアトミック方式で実行される
（すなわち、その動作は完了まで実行されるかまたは打
ち切られる）。動作が打ち切られる場合、両方のリポジ
トリのデータは、クラスタ化アーキテクチャと整合性の
ある状態に復帰される。これは、１つのノードを何回も
定義し定義解除できることと、定義解除動作が行われた
ときにそのノードをクラスタから切断できることを考慮
に入れたものである。

【００７３】クラスタに対するノード定義の整合性を執
行するために、ノード定義動作は、そのノード自体をノ
ード定義プロトコルに関与させる。この動作中にそのノ
ードの固有識別子はノード番号に関連付けられるが、こ
のノード番号もそのノードが定義される特定のクラスタ
に固有のものである。しかし、ノード番号はすべてのク
ラスタにわたって固有であるわけではない。したがっ
て、複数ノードのプールを複数クラスタ配置（後述す
る）に使用する場合、各クラスタで同じ番号または異な
る番号を付けて１つのノードを定義する場合も考えられ
る。しかし、この実施形態では、１つのノードは任意の
特定の時点で１つのクラスタのみでオンライン（アクテ
ィブ）になることができる。

【００７４】ノード番号識別子は、それによってクラス
タに対してノードを把握させる内部識別子である。ノー
ド定義プロセスは、一例では、所与のノード番号が、当
初は特定の固有識別子で定義されたオペレーティング・
システムの１つのインスタンスに関連するように保証す
るものである。ノード定義プロセスの詳細については、
図１４および図１５に示す例に関連して説明する。

【００７５】図１４を参照すると、ノード定義プロセス
に関与するプロセス（たとえば、コンピュータ・プログ
ラム）として、レジストリ・サーバとして定義されるク
ラスタ１２０４の１つまたは複数のノード１２０２内に
位置するシステム・レジストリ・サーバ・プロセス１２
００（図１４）と、ノード定義要求１２０８が発行され
るノードまたはその動作の経路指定先になるノードで動
作する分散構成マネージャ１２０６（すなわち、メンバ
ＤＣＭプロセス）と、クラスタに追加されるノードで動
作する分散構成マネージャ１２１０（すなわち、非メン
バＤＣＭ）という３つのプロセスが存在する。図１５に
関連して後述するように、この３つのプロセスは定義プ
ロトコルに関与する。

【００７６】ステップ１では、ノード定義要求がメンバ
ＤＣＭプロセスに渡される。一例では、定義すべきノー
ドのノード（たとえば、ＩＰ）アドレスが要求とともに
渡される。任意選択のパラメータとして、固有ノード識
別子、ノード番号、ノード名も渡すことができる。明示
的に設定されていない場合、固有識別子、ノード番号、
ノード名の値はメンバＤＣＭプロセスによって生成され
る。

【００７７】ステップ１で得られたノード・アドレス
は、非メンバＤＣＭプロセスに接触するためにメンバＤ
ＣＭが使用する（ステップ２）。このメッセージでメン
バＤＣＭプロセスは非メンバＤＣＭプロセスにクラスタ
識別子を渡す。

【００７８】ステップ３で非メンバＤＣＭプロセスは、
その要求を受け取り、受け取ったクラスタ識別子で識別
されるクラスタのメンバとして定義される。非メンバＤ
ＣＭは、それが固有クラスタ識別子によってすでに識別
されたローカル構成を一切持っていないことをチェック
する。（前述のシナリオの中には、そのノードが古い定
義を有する可能性があるものもある。）非メンバＤＣＭ
は、ホスト・オペレーティング・システムによって渡さ
れたそれ自体の固有識別子でこの要求に応答する。ま
た、これは、そのクラスタＩＤに関する前の定義がロー
カル記憶域で見つかったかどうかを示す状況コードもこ
の応答に含める。

【００７９】メンバＤＣＭは、非メンバＤＣＭノードの
固有識別子を含む応答を非メンバＤＣＭから受け取る
（ステップ４）。メンバＤＣＭは、この値を保管し、ノ
ード識別子がグローバル記憶域で報告されたかどうかを
チェックする（ステップ５）。たとえば、メンバＤＣＭ
は、システム・レジストリ・プロセスに対してルックア
ップ要求を行って、その特定の固有識別子で定義された
ノードをクラスタ内で見つける。システム・レジストリ
は、ステップ４で渡された固有ノード識別子に対応する
可能なノード定義を含むメッセージまたはこのような定
義がまったく存在しないことを示す戻りコードで応答す
る（ステップ６）。

【００８０】ステップ７でメンバＤＣＭは前述のメッセ
ージを受け取る。このような定義が見つかった場合、メ
ンバＤＣＭは、この定義が非メンバＤＣＭによって報告
されたものと同じであるかどうかをチェックする。これ
らの定義が同一である場合、非メンバ・ノードがそのク
ラスタに対してすでに定義されている（このノード定義
要求は誤って発行されたものであり、この場合の「非メ
ンバ」というラベルは適切ではない）という趣旨のメッ
セージがノード定義要求側に返送される。これらの定義
が同一ではない場合、ローカル定義とグローバル定義が
ともに削除され、ノード定義プロセスが続行される。残
る可能性として、非メンバ・ノードはグローバル・クラ
スタ構成で見つけることができないローカル定義を報告
する。この場合、定義が一致しない場合と同様に、非メ
ンバＤＣＭは前の定義を消去するよう要求される。

【００８１】ステップ８でメンバＤＣＭは、当初はステ
ップ１で与えられるノード・アドレスと、固有ノード識
別子、ノード番号、ノード名をシステム・レジストリに
渡し、新しいノード用の項目を作成するようシステム・
レジストリに要求する。システム・レジストリは、グロ
ーバル・クラスタ構成に対して前述の項目をコミット
し、動作の成功を通知するメッセージをメンバＤＣＭに
返送する（ステップ９）。

【００８２】ステップ１０でメンバＤＣＭは上記のメッ
セージを受け取る。動作が成功しなかった場合、ノード
定義プロセスは打ち切られ、プロセスが失敗したという
メッセージがノード定義の要求側に返送される。成功し
た場合、プロセスは続行される。次にメンバＤＣＭは、
ローカル記憶域に対して新しいノード定義をコミット
し、適切であれば前の定義を消去するよう非メンバＤＣ
Ｍに要求する（ステップ１１）。

【００８３】ステップ１２で非メンバＤＣＭは、前述の
要求を実行し、要求された動作の成功を通知するメッセ
ージをメンバＤＣＭに返送する。メンバＤＣＭはこのメ
ッセージを受け取る（ステップ１３）。非メンバＤＣＭ
によって報告される結果が失敗である場合、メンバＤＣ
Ｍは定義動作を打ち切り、ノード定義動作の要求側に失
敗を報告する。メンバＤＣＭは、ステップ８で作成され
たグローバル記憶域内の定義を消去する試みも行う。失
敗ではない場合、プロセスは続行される。

【００８４】メンバＤＣＭプロセスはノード定義動作を
正常に完了しており、次に、動作の成功を示すメッセー
ジを要求側に返す（ステップ１４）。

【００８５】クラスタに対してノードを定義した後、た
とえば、本発明の自動クラスタ構成技法を使用すること
により、システム管理者の側で追加のアクションを行う
必要なしに、そのノードをクラスタに挿入（加入）する
ことができる。この技法は、たとえば、ノード定義の直
後またはオンライン・ノード要求を発行したときに開始
することができる。

【００８６】自動クラスタ構成技法の一実施形態につい
て図１６および図１７に関連して説明する。具体的に
は、図１６はこの技法で使用する様々なプロセスの一例
を示し、図１７はプロセス間のメッセージ・フローの一
例を示す。

【００８７】図１６を参照すると、たとえば、オンライ
ン・ノード要求１４００によりクラスタに対して新しい
ノードを構成するアクションは、新しいノード１４０４
上のＤＣＭプロセス１４０２によって調整される。これ
は、それが初めてクラスタに加入するまで、クラスタ内
の他のプロセスはそのノードの構成に関する知識がない
からである。

【００８８】ノード定義の時点では、新しいノードとク
ラスタとの間で最小量のデータしか交換されない（図１
７、ステップ１）。交換されるデータは、新しいノード
の固有識別子の保証に関するものであり、レジストリ・
サーバのリスト１４０６をシードするためのものでもあ
る。ローカル識別子／ノード番号の対は、グローバル・
リポジトリの識別子／ノードの対と比較される。この比
較が成功すると、加入を続行することができる。

【００８９】クラスタに加入するよう新しいノードに要
求すると（図１７、ステップ２）、新しいノード上のＤ
ＣＭプロセスは、新しいノード内のリソース・マネージ
ャ１４０８に対して（図１７、ステップ３）、リソース
・コントローラ１４１０にメッセージを送り（図１７、
ステップ４）それぞれの構成をシステム・レジストリ１
４１２に書き込むよう要求する。このプロセスはノード
がクラスタに加入するたびに繰り返され、このプロセス
によりノード構成の自動更新も可能になる。

【００９０】したがって、リソース・コントローラはそ
れらが制御するリソース（たとえば、ハードウェア）用
の構成によりシステム・レジストリを更新し（図１７、
ステップ５）、更新が完了したことを新しいノード上の
リソース・マネージャに通知する（図１７、ステップ
６）。次にリソース・マネージャ・プロセスは、それに
登録されたリソース・コントローラに関するこの動作の
完了状況を受け取ったときにＤＣＭに通知する（図１
７、ステップ８）。

【００９１】新しいノード上のＤＣＭプロセスは、更新
が完了したという通知をリソース・マネージャから受け
取り（図１７、ステップ９）、加入プロセスを続行す
る。

【００９２】並列アクションで、クラスタ１４１６上の
システム・レジストリ・プロセス１４１４は、構成が更
新されたという趣旨でイベント加入者が受け取ることが
できるイベントを送る（図１７、ステップ７）。初めて
クラスタにノードを追加する場合、このイベントによ
り、他のクラスタ・コンポーネントが新しいノードをク
ラスタ・メンバとして理解することが可能になる。

【００９３】上記の手順により、システム管理者からの
情報を必要とせずに、ノードはそれ自体をクラスタのメ
ンバとして構成することができる。管理者は、一例で
は、ノード定義手順用のノード・アドレスのみを供給す
る。ノード定義手順中にレジストリ・サーバのリストが
新しいノードにシードされる。クラスタに加入するよう
新しいノードに要求すると、そのノードはレジストリ・
サーバのリストを使用して作業システム・レジストリ・
プロセスを見つける。次に、新しいノード上のリソース
・コントローラは、それが制御するリソースの構成を発
見し、この情報をグローバル・クラスタ構成データベー
スに書き込むよう要求される。（リソース・コントロー
ラは、特定のリソースに関して書き込まれ、それぞれの
構成を発見する方法を把握しているプロセスである。）
有利なことに、この動作は新しいノードによって開始さ
れ、この情報を手動で提供することをシステム管理者に
要求しない。

【００９４】一例では、そのノードの構成がグローバル
・リポジトリと整合性のあるものであることを保証する
ために、ノードがクラスタに加入するたびに上記の手順
が繰り返される。たとえば、この手順により、システム
管理者はクラスタからノードを切断し、新しい通信アダ
プタなどの何らかのハードウェアを追加し、ノード構成
に変更を加え、ノードがクラスタからオフラインになっ
ていた間に行われたいずれの変更もクラスタに通知する
必要なしにそれをクラスタに再接続することができる。

【００９５】本発明の少なくとも一態様によれば、コン
ピューティング環境はそこに定義された１つまたは複数
のクラスタを有することができる。たとえば、コンピュ
ーティング環境１６００（図１８）は、クラスタＡ １
６０２とクラスタＢ １６０４とを含む。それぞれのク
ラスタはそれに対して定義された１つまたは複数のノー
ド１６０６を有する。さらに、図１８に示すように、１
つまたは複数のノードを両方のクラスタに対して定義す
ることもできる。

【００９６】各クラスタは、それに関連する１つまたは
複数のレジストリ・サーバを有する。たとえば、クラス
タＡはレジストリ・サーバ１６０８を有し、クラスタＢ
はレジストリ・サーバ１６１０を有する。レジストリ・
サーバ１６０８は１つまたは複数のサーバ・ノード１６
１２を含む。同様に、レジストリ・サーバ１６１０は１
つまたは複数のサーバ・ノード１６１４を含む。１組の
レジストリ・サーバのサーバ・ノードのうちの１つまた
は複数は、他の１組のレジストリ・サーバの１つまたは
複数のノードとオーバラップすることができる。

【００９７】本発明の他の態様では、あるクラスタから
他のクラスタへノードを迅速に移動することができる。
この能力により、あるクラスタが所与の瞬間に経験する
作業負荷間でノードをシフトすることが可能になる。た
とえば、ウェブ・サービングおよびデータベース・サー
ビスなど、２通りのアプリケーションに使用するノード
のプールを有する企業について検討する。この企業は、
本発明のクラスタ化技法を使用すれば、それぞれが１つ
のアプリケーション専用である２つのクラスタ、すなわ
ちクラスタＡとクラスタＢを定義することができるだろ
う。次に、このようなアプリケーションでの作業負荷は
時刻に応じて変動し、日中はウェブ・サービングの方が
アクティブであり、夜間はデータベース・サービスの方
がアクティブであると想定する。この企業は、クラスタ
Ｂの負荷の方が大きいときにクラスタＡからいくつかの
ノードをクラスタＢに移動し、逆も同様に行いたいと希
望するだろう。

【００９８】従来のクラスタ化システムでは、システム
管理者は、まず、クラスタＡでノードをオフラインに移
行し、次にそのノードをクラスタＡで定義解除し、次に
それをクラスタＢに対して定義し（通常、多大な手動構
成を必要とする）、その後、クラスタＢでそのノードを
オンラインに移行しなければならないだろう。従来のシ
ステムは、手動介入を必要とし、非常に時間のかかるも
のである。作業負荷平衡アプリケーションについて検討
する場合、ノードを移動するプロセスに費やす時間は非
常に重要なものである。というのは、通常、作業負荷
は、この例のように夜間と日中だけでなく、ものの数分
で変化する非常に動的な尺度だからである。したがっ
て、作業負荷平衡アプリケーションで価値を有するため
に、あるクラスタから他のクラスタへノードを移動する
動作は非常に高速になる。

【００９９】したがって、本発明の一態様によれば、ク
ラスタ定義のオーバラップを可能にすることにより、あ
るクラスタから他のクラスタへノードを急速に移動す
る。すなわち、１つのノードは、複数のクラスタに対し
て定義することができるが、一実施形態では特定の時点
で単一クラスタ内のみでアクティブになる。

【０１００】１つのノードがクラスタに対して定義され
ると、ＤＣＭは、そのノードが定義されたクラスタに関
するローカル構成を保持するための特殊記憶域を作成す
る。ＤＣＭコンポーネントはローカル・クラスタ構成を
このローカル記憶域に記憶する。ローカル・クラスタ構
成に記憶される値の中には、たとえば、特定のクラスタ
のクラスタ名、クラスタＩＤ、ノード名、ノードＩＤ、
レジストリ・サーバのリストがある。他の例としては、
ＤＣＭは、ローカル記憶域内に以下の２つのフィールド
も保持する。すなわち、そのノードが現在オンラインに
なっているクラスタの識別子（ＩＤ）を含む現行クラス
タ・ポインタと、ノードの移動先であるクラスタのＩＤ
を含むターゲット・クラスタ・ポインタである。

【０１０１】これらのポインタの値は、ノードをあるク
ラスタから他のクラスタへ移動する動作中のみ異なるも
のになる。ノードを所与のクラスタ内へ移動できるよう
にするために、そのクラスタ用の少なくとも１つのレジ
ストリ・サーバ・ノードはオンラインでなければならな
い。ノードを移動するために、ＤＣＭは、ノードの加入
先として想定されたクラスタを指し示すためにターゲッ
ト・クラスタ・ポインタを移動し、次に移動中のノード
内で動作する他のクラスタ・コンポーネントにリフレッ
シュ信号を送る。あるコンポーネントは、このリフレッ
シュ信号を受け取ると、その構成をリフレッシュし、す
なわち、その構成をグローバル・クラスタ・リポジトリ
から読み取る。そのリポジトリに到達するために、その
コンポーネントは、特定のクラスタに対して定義された
レジストリ・サーバのリストを検索する。移動中のノー
ド内のレジストリ・サーバのリストを検索するプロセス
では、以下に詳述するように、どのリストを使用するか
を決定するために、ターゲット・クラスタ・ポインタを
使用する。

【０１０２】あるクラスタから他のクラスタへ移動する
ノードに関連する論理の一実施形態について、図１９お
よび図２０に関連して以下に説明する。図１９の点線矢
印は、クラスタＡの構成に対するシステム・コンポーネ
ントの事前接続を示す（ローカルとグローバルの両
方）。移動プロセス中、これらの矢印は、クラスタＢの
構成を指し示す実線矢印で置き換えられる。

【０１０３】ステップ１（図２０）で、他のクラスタへ
ノードを移動するための要求１７００（図１９）は、移
動すべきノード上のＤＣＭプロセス１７０２に送られ
る。ＤＣＭプロセスは、ノードを移動するための要求を
受け取り（図２０、ステップ２）、それがノードの移動
先であるクラスタのクラスタＩＤを含むようにターゲッ
ト・クラスタ・ポインタ１７０４の値を変更する。移動
中のノード上のＤＣＭプロセスは、そのノード上で動作
する他のクラスタ・コンポーネント１７０６にリフレッ
シュ・メッセージを送る（図２０、ステップ３）。

【０１０４】他のクラスタ・コンポーネントは、グロー
バル・クラスタ構成１７１０を読み取れるようにレジス
トリ・サーバのリスト１７０８を検索する（図２０、ス
テップ４）。このリストは、ターゲット・クラスタ・ポ
インタに記憶されたクラスタＩＤを特定のクラスタ用の
レジストリ・サーバのリストに関連付けるマッピングを
使用して検索される。次に、他のクラスタ・コンポーネ
ントは、前のステップで受け取ったレジストリ・サーバ
のリストにリストされたレジストリ・サーバを使用し
て、グローバル・レジストリに記憶されたそれぞれの具
体的な構成を要求する（図２０、ステップ５）。

【０１０５】このレジストリ・サーバは、移動中のノー
ド内の他のクラスタ・コンポーネントに対してターゲッ
ト・クラスタ内のそれぞれの役割に関するそれぞれの適
切な構成を提供する（図２０、ステップ６）。移動中の
ノード上の他のクラスタ・コンポーネントは、それらが
移動動作を完了し、ターゲット・クラスタ内でオンライ
ンになっていることをＤＣＭプロセスに通知する（図２
０、ステップ７）。

【０１０６】次にＤＣＭは、そのノードが他のクラスタ
へ正常に移動されたことを反映するために現行クラスタ
の値を変更する（図２０、ステップ８）。そうではな
く、いずれかのクラスタ・コンポーネントがリフレッシ
ュ動作の実行に失敗した場合、ＤＣＭは、そのノードを
現行クラスタ・ポインタの前の値に戻し、ターゲット・
クラスタ・ポインタの値も復旧し、リフレッシュ・メッ
セージを再発行し、移動の効果を効果的に取り消す。そ
の後、ＤＣＭプロセスは、動作の結果を移動動作の要求
側に通知する（図２０、ステップ９）。

【０１０７】すべてのコンポーネントがリフレッシュ動
作を終了し、クラスタＢで正常にオンラインになってい
ることをＤＣＭに報告すると、現行クラスタ・ポインタ
はクラスタＢを指し示すように移動する。そのノードが
何らかの理由でクラスタＢに加入できない場合、そのノ
ードは現行クラスタ・ポインタに指名されたクラスタに
復帰する。

【０１０８】上記の手順により、あるクラスタから他の
クラスタへノードを非常に迅速に移動することが可能に
なる。このような高速移動が可能になる理由は、このア
ーキテクチャにより１つのノードを複数のクラスタに定
義できることによる。

【０１０９】クラスタ・アーキテクチャの様々なコンポ
ーネントは、メッセージを送受信し、いたるところでシ
ステム通信トラフィックを引き起こす。「システム通
信」という用語は、クラスタ化システム内で動作するア
プリケーションによって生成されるトラフィックである
サービス・トラフィックとは対照的に、クラスタ化論理
自体によって生成されるネットワーク・トラフィックを
参照するために本明細書で使用する。たとえば、システ
ム・トラフィックは、すべてのノード上の対等機能に定
期検証メッセージを送る活性サブシステムによって生成
されるネットワーク・トラフィックを含む。他の例とし
ては、他のコンポーネントにそのクラスタのグローバル
構成を送るシステム・レジストリ・コンポーネントによ
って生成されるネットワーク・トラフィックを含む。ク
ラスタ・システムの典型的な配置では、複数の相互接続
ネットワークを使用し、その結果、ノード間に複数の通
信経路が作成される。したがって、システム内で動作す
る他のアプリケーションに干渉しないように、システム
・トラフィックを特定の通信経路に制限できる機構をシ
ステム管理者に提供することが望ましい。

【０１１０】本発明の一態様によれば、クラスタ化論理
によって生成されるネットワーク・トラフィックを制御
するために、クラスタ・アーキテクチャはネットワーク
・オブジェクトを定義する。システム・トラフィックを
生成する各クラスタ・コンポーネントは、このようなト
ラフィックに使用すべきネットワーク・オブジェクトに
関するプリファレンスを指定する。たとえば、１つのク
ラスタは１つまたは複数のネットワークを含むことがで
き、各ネットワークは１つまたは複数のサブネットワー
クを含み、各サブネットワークは１つまたは複数のノー
ドを含む。

【０１１１】前述のように、ノードはノード定義動作に
よってクラスタに対して定義される。同様に、サブネッ
トワーク・オブジェクトはサブネットワーク定義動作に
よって定義される。サブネットワークは、そのノード・
アドレスが既存のサブネットワーク・オブジェクトにマ
ッピングされていないクラスタ内で新しい通信アダプタ
が発見されたという通知を受け取った場合に、ＤＣＭプ
ロセスによって暗黙のうちに定義することができる。さ
らに、サブネットワーク定義解除動作はグローバル・ク
ラスタ構成からサブネットワーク定義を削除し、サブネ
ットワーク修正動作はサブネットワーク定義の属性を修
正する。修正可能な属性としては、たとえば、サブネッ
トワーク名ならびにサブネットワークがマッピングされ
るネットワーク定義を含む。

【０１１２】同様に、ネットワーク定義動作は１つまた
は複数のサブネットワーク定義にマッピングされるネッ
トワーク定義を作成し、ネットワーク定義解除動作はグ
ローバル・クラスタ・データベースからネットワーク定
義を消去する。さらに、ネットワーク修正動作は、ネッ
トワーク定義の属性を修正するために使用する。変更可
能な属性の１つは、たとえば、ネットワーク名である。

【０１１３】各ノード、サブネットワーク、ネットワー
クは、後述するように、少なくとも１つの対応データ構
造によって定義される。これらのデータ構造は、たとえ
ば、グローバル・リポジトリに記憶される。

【０１１４】一実施形態では、各ノードは１つまたは複
数のノード・アドレス定義データ構造によって表され
る。一例のノード・アドレス定義データ構造１９００
（図２１）は、ノード・アドレス・データ定義の１次キ
ー・フィールドとして使用し、本明細書で説明するよう
にノード・アドレス・オブジェクトが作成されたときに
生成される固有識別子１９０２と、そのノードに到達す
るために使用するノード・インタフェースのノード・ア
ドレスを含むノード・アドレス１９０４（以下に詳述す
る）と、クラスタ・システムの特定のサブネットワーク
にノード・アドレスをマッピングするために使用するサ
ブネットワーク・マスク１９０６と、フィールド１９０
４内のノード・アドレスに関連するノードの番号を含む
ノード番号１９０８とを含む。

【０１１５】ノード・アドレスは、やはり固有のもので
ある２次キー・フィールドである。分散構成マネージャ
・コンポーネントでは同じノード・アドレスを有する２
つのノード・アドレスの定義は不可能なので、ノード・
アドレスは固有のものになる。本発明の諸態様の特定の
一実施例でノード間の通信手段としてインターネット・
プロトコルを使用するので、本明細書に記載する例で
は、アドレスはインターネット・プロトコル（ＩＰ）ア
ドレスである。しかし、他のどの通信プロトコルでも使
用できることは当業者には分かることである。どのイベ
ントでも、選択したプロトコルを使用して各ノードに到
達できるように、そのノードについて識別されたアドレ
スが少なくとも１つ存在するはずである。複数の通信プ
ロトコルを使用する場合、プロトコル・タイプがノード
・アドレス定義の追加フィールドになる場合もある。

【０１１６】本発明の一態様によれば、各ノード・アド
レス定義はサブネットワーク定義にマッピングされる。
サブネットワーク定義データ構造の一例について図２２
に関連して説明する。

【０１１７】一例として、サブネットワーク定義データ
構造２０００は、たとえば、サブネットワーク定義の固
有性を示す固有識別子２００２と、この特定の実施例で
はサブネットワークの接頭部を識別するノード・アドレ
スを含むサブネットワーク接頭部２００４と、サブネッ
トワーク接頭部内のいくつのビットが関連するかを示す
ビット・マスクであるサブネットワーク・マスク２００
６と、サブネットワーク定義を既存のネットワーク定義
にマッピングするネットワーク名２００８とを含む。

【０１１８】本明細書に記載する例では、サブネットワ
ーク・オブジェクトは、ＩＰプロトコルに規定されてい
る、そのコンピュータの相互接続の方法から導出され
る。たとえば、ＩＰネットワークでは、ＩＰアドレスと
サブネットワーク・マスクによってノードが構成され
る。同じサブネットワークに接続されたすべてのノード
は同じ接頭部を備えたアドレスを有するはずであり、接
頭部の長さはサブネットワーク・マスクによって決定さ
れる。ここに示す実施例では、ＩＰネットワークのこの
態様を使用してノード・アドレスをグループ単位にグル
ープ化するが、この場合、各グループは同じサブネット
ワーク内にあるすべてのノードを含む。サブネットワー
クはネットワーク定義にマッピングされており、クラス
タ・トラフィックの経路指定は、後述するように、ネッ
トワーク・オブジェクトのパラメータを修正することに
よって制御される。

【０１１９】ネットワーク定義データ構造の一例を図２
３に示す。ネットワーク定義データ構造２１００は、た
とえば、ネットワーク定義の固有性を示す固有識別子２
１０２と、サブネットワーク・オブジェクトをネットワ
ーク・オブジェクトにマッピングするために使用するネ
ットワーク名２１０４と、様々なクラスタ・サービスを
求める要求の伝送時にどのネットワークを使用するかを
決定する際に使用する値のテーブルであるサービス経路
指定テーブル２１０６とを含む。サービス経路指定テー
ブルは、たとえば、システム・トラフィックを生成する
クラスタ・コンポーネントの名前と、このようなサービ
スにそのネットワークを使用する場合の優先順位とを含
む。

【０１２０】たとえば、１つのクラスタをＡ、Ｂ、Ｃと
いう３つのネットワーク・オブジェクトによって定義す
ることができる。あるクラスタ・コンポーネントがシス
テム・レジストリからグローバル構成を読み取ることを
必要としていると仮定する。そのコンポーネントはまず
特定のクラスタに関するレジストリ・サーバのリストを
検索する。この例では、このリストは１、２、３という
ラベルが付いた３つのアドレスを含む。次にそのコンポ
ーネントは、システム管理者が設定した優先順位に応じ
てどれを使用するかを選択する。このコンポーネント
は、後述するマッピングに従い、サービス・ノード・ア
ドレス（レジストリ・サーバのリストにリストされてい
るもの）をネットワーク・オブジェクトにマッピングす
る。

【０１２１】この例では、アドレス１はネットワークＡ
にマッピングされ、アドレス２はネットワークＢにマッ
ピングされ、アドレス３はネットワークＣにマッピング
される。次に、このコンポーネントは、各ネットワーク
・オブジェクトのサービス経路指定テーブルに記憶さ
れ、それが使用する必要があるサービス（たとえば、シ
ステム・レジストリ）を参照する優先順位値を読み取
る。この値は、そのシステムに関してシステム管理者の
プリファレンスに応じてシステム管理者が設定したもの
である。この例では、システム・レジストリ優先順位の
値がネットワークＡでは３、ネットワークＢでは２、ネ
ットワークＣでは１であると想定する。最高の優先順位
番号はネットワークＡで見つかり、したがって、このコ
ンポーネントは、ネットワークＡにマッピングされるア
ドレス（上記の１）をまず使用して、システム・レジス
トリ・コンポーネントに到達しようと試みる。次に、そ
れが失敗した場合、このコンポーネントは、ネットワー
クＢにマッピングされるアドレスを使用し、最後にネッ
トワークＣにマッピングされるアドレスを使用しようと
試みる。

【０１２２】クラスタ・サービスのクライアントがある
サービス用の特定アドレスを選択する方法に関する詳細
について、図２４に示す例に関連して説明する。

【０１２３】一実施形態では、最初にクライアントは、
ステップ２２００（図２４）でサービスが存在する可能
性のあるアドレスのリストを検索する。アドレスのリス
トを検索する方法は各サービスごとに異なる。システム
・レジストリの場合、ローカル構成ファイルからレジス
トリ・サーバ・ノードのリストを検索する。他のサービ
スは、たとえばグローバル・クラスタ構成でノード・ア
ドレスのリストを公表する場合もある。

【０１２４】ノード・アドレスのリストの取得後、クラ
イアントは、グローバル・クラスタ構成に記憶されたノ
ード・アドレス定義データ構造内の各ノード・アドレス
を調べる。各アドレスごとに、クライアントは、ステッ
プ２２０２（図２４）でノード・アドレスとサブネット
ワーク・マスクの論理ＡＮＤ演算を実行し（図２５を参
照）、その結果として各アドレスごとにサブネットワー
クＩＤを取得する。

【０１２５】その後、クライアントは、ステップ２２０
４で各アドレスごとにサブネットワーク・オブジェクト
を検索し、各サブネットワーク・オブジェクトごとにス
テップ２２０６でそのサブネットワークに関連するネッ
トワーク名を検索する。

【０１２６】その後、クライアントは、ステップ２２０
８でサービス・アドレスがマッピングされる各ネットワ
ークを検索する。次にクライアントはステップ２２１０
で、各ネットワーク・オブジェクトに記憶されたサービ
ス経路指定テーブルからサービス優先順位番号を読み取
る。次にクライアントはステップ２２１２で、ネットワ
ーク・オブジェクトにシステム管理者によって設定され
た優先順位に応じてノード・アドレスのリストを順序付
ける。

【０１２７】その後、クライアントはステップ２２１４
で、優先順位の順にサービスに接触しようと試みる。

【０１２８】上記の技法は、特定のネットワークへの特
定の種類のサービスに関連するトラフィックを含むメカ
ニズムをクラスタの管理者に提供するものである。この
技法は、管理者にとって意味のあるようにネットワーク
・トラフィック制御を提供する。クライアントがこのサ
ービス用のノード・アドレスのリストを検索することに
留意されたい。このリストはサービス自体によって公表
されるので、最初は順序付けられていない。上記の例で
は、ＤＣＭコンポーネントによりそのノード・アドレス
のリストを公表するのはシステム・レジストリである。
しかし、システム・レジストリは、ネットワーク構造ま
たはシステム管理者のプリファレンスに関する知識をま
ったく持っておらず、したがって、順序付きリストを提
供することができない。したがって、システム管理者
は、上記のマッピングが示すように、サブネットワーク
・オブジェクトをネットワーク・オブジェクトに割り当
てることができる。

【０１２９】システム・マネージャが行った変更は、移
動したサブネットワークにマッピングされるすべてのア
ドレスのサービス優先順位割当てに影響する。この動作
は、他のコンポーネントによって理解されるサブネット
ワーク・テーブル内の変更に局所化される。この機構
は、それによってシステム管理者がクラスタ・システム
のすべてのコンポーネントのシステム・トラフィックを
制御できる中央制御点を提供する。

【０１３０】前述したものは、システム管理者によって
設定された優先順位に応じてサービス・アドレスのリス
トに順序付けるための一技法である。しかし、場合によ
ってはシステム管理者は、それに関する優先順位プリフ
ァレンスが存在しない、複数の同等ネットワークを使用
する場合もある。この場合、たとえば、経路指定ステッ
プまたはホップによって、クライアントへの近接順にサ
ービス・アドレスのリストを順序付けることが望まし
い。標準のＩＰプロトコルでは、特定のサブネットワー
クから送られるデータグラムは、それが経路指定されて
いない場合、その特定のサブネットワーク内のノードの
みに到達することになる。そのデータグラムが他のノー
ドに到達するためには、それは経路指定される（すなわ
ち、それは、そのデータグラムが発信されたサブネット
ワークとターゲット・ネットワークの両方あるいは他の
ルータまたはそのうちの１つがターゲット・ネットワー
クにアクセス可能な一連のルータに接続されたルータま
たはパッケージ・スイッチング・ノードを通過する）。
パッケージ・スイッチング・ノードによりパッケージを
経路指定するステップはホップと呼ぶ。パッケージ・ス
イッチング動作はターゲット・サブネットワークでのパ
ケットの受信を遅らせるので、ホップに関連してパフォ
ーマンスの損害が発生する。

【０１３１】したがって、システム管理者が特定サービ
スへのクラスタ・ネットワークの使用に関して優先順位
プリファレンスを設定しない場合、サーバからクライア
ントに経路指定する際にデータグラムが被る最小数のホ
ップに応じてリストを順序付けることが有益である。さ
らに、複数のサーバがクライアントと同等である場合
（すなわち、正確に同じ数のホップを使用して複数のサ
ーバに到達できる場合）、サービス負荷が等距離サーバ
間に等しく広がるように、各クライアントごとに異なる
ようにリストを順序付けることが有益になる。

【０１３２】以下の技法は、低距離および負荷平衡の基
準に応じてサービス・アドレスのリストを順序付ける機
構を提供するものである。この技法は、ＤＣＭが各ノー
ドにレジストリ・サーバのリストを記憶するときに（シ
ステム管理者がクラスタ・ネットワークの使用に関する
優先順位を設定していない場合）ＤＣＭが使用する。後
述するように、この技法では、クライアントからサーバ
までの距離と、作業負荷をサーバ間に等しく分散するマ
ッピングを使用する。この作業負荷分散は、各サブネッ
トワーク内のノードの総数と、各ノードの個別ノード番
号と、等距離サーバの数から導出される公式に基づくも
のである。

【０１３３】特定サービスに到達するためにクラスタ内
の特定のノードが使用すべきアドレスの順序付きリスト
を生成するために使用する論理の一実施形態について、
図２６に関連して説明する。一例では、この技法のため
の入力パラメータとして、特定サービス用のアドレスの
リストと、特定サービスのクライアントになるノードの
ノード番号と、そのノード上に存在する通信インタフェ
ース用のアドレス（ノード・アドレス）と、ホップ数に
よる他の各サーバからそのノードまでの距離とを含む。
このパラメータは標準のＩＰトレース・ルート機構を使
用して推定できることに留意されたい。

【０１３４】出力は、固有ノード番号によって識別され
る特定ノード用に調整されたサービス・アドレスの順序
付きリストになる。このリストは、最小コストに応じて
順序付けられ、等距離サーバに負荷平衡を使用する。

【０１３５】図２６を参照すると、最初にステップ２４
００で、入力リスト内のいずれかのアドレスがそのノー
ド自体に存在するノード・インタフェースに対応する場
合、これらのアドレスは結果として得られる順序付きリ
スト上にまず置かれる。この結果、同一ノード上に共存
する複数サーバを使用するプリファレンスをローカル・
クライアントが有し、その結果、可能な限り最善のパフ
ォーマンスが得られる。次にステップ２４０２で、最低
距離（ホップ数による）を備えたサーバのアドレスがリ
ストされる。

【０１３６】複数の等距離サーバ（すなわち、同じ数の
ホップを使用して到達可能なサーバ）が存在する場合、
順序付けをさらに最適化することが可能である。２つの
等距離サーバが存在する場合、クライアントの半分に一
方のサーバを最初にリストし、残り半分にもう一方のサ
ーバを最初にリストすることが有益である。これにより
クライアントの半分は一方のサーバに関するプリファレ
ンスを有し、残り半分はもう一方のサーバに関するプリ
ファレンスを有し、理想的な負荷平衡方式を達成する。
サーバが３つ存在する場合、第１の位置は３通りに分割
することができる。

【０１３７】どのサーバを最初にリストするかを決定す
るための一技法については、ステップ２４０４で説明す
る。特に、最初はステップ２４０６で、１組の等距離サ
ーバ（すなわち、同じ数のホップを有する１組のサー
バ）に対して、それぞれのノード・アドレスに応じて最
低から最高の順に０、１、２などのインデックスを付け
る。ノード・アドレスは固有のものなので、このマッピ
ングも固有のものになる。

【０１３８】次にステップ２４０８で、事前定義された
式を使用して等距離サーバの１つのマッピング・インデ
ックスを計算する。特に、ｋが０から等距離サーバの数
までの場合、マッピング・インデックスは[(node_numbe
r)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 これはサーバ１２にマッピングされる。 ４）最終結果は以下のようなリストになる。 ｛１、９、３、７、２、１２｝

【０１４３】出力リストは各クライアント・ノード番号
ごとに異なり、その結果、各クライアントごとに平衡リ
ストが得られることが認められる。

【０１４４】上記に加え、ＤＣＭは順序付きリストを維
持する。一例では、ＤＣＭは、新しいサービス・ノード
が追加または削除されたという通知を受け取ると必ずロ
ーカル・リストをリフレッシュする。

【０１４５】前述したものは、クラスタ化環境を管理す
る場合の様々な態様である。クラスタ化アーキテクチャ
ならびにクラスタを管理するための技法も提供される。
本発明の様々な技法は、単一システム、同種システム、
ならびに異種システムにも適用可能である。一例とし
て、異種環境のシステムの相互運用性を容易にするため
の機能が提供される。

【０１４６】本明細書に記載した実施形態では、グロー
バル・データはノードから１つまたは複数のリポジトリ
（グローバル記憶域）にリモートで記憶される。しか
し、他の例では、各リポジトリは１つまたは複数のノー
ドに対してローカルなものにすることができる。さら
に、各リポジトリはそのリポジトリのユーザにとってリ
モートまたはローカルなものにすることができる。

【０１４７】本発明は、たとえば、コンピュータで使用
可能な媒体を有する製品（たとえば、１つまたは複数の
コンピュータ・プログラム）に含めることができる。こ
の媒体では、たとえば、本発明の諸機能を提供し容易に
するためのコンピュータ可読プログラム・コード手段が
そこで実施されている。この製品は、コンピュータ・シ
ステムの一部として含めるか、別々に販売することがで
きる。

【０１４８】その上、本発明の諸機能を実行するために
マシンによって実行可能な複数命令からなる少なくとも
１つのプログラムを具体的に実施し、マシンによって読
取り可能な少なくとも１つのプログラム記憶装置を提供
することができる。

【０１４９】ここに示した流れ図は例にすぎない。本発
明の精神を逸脱せずに、これらの図またはそこに記載さ
れたステップ（または動作）の変形形態は多数存在する
可能性がある。たとえば、そのステップは異なる順序で
実行することができ、ステップの追加、削除、または修
正も可能である。これらの変形形態はいずれも、ここで
請求する本発明の一部と見なす。

【０１５０】好ましい実施形態について本明細書で詳し
く描写し説明してきたが、本発明の精神を逸脱せずに、
様々な修正、追加、置換などが可能であり、したがっ
て、それらは特許請求の範囲に定義した本発明の範囲内
であると見なされることは、当業者にとって明らかにな
るだろう。

【０１５１】まとめとして、本発明の構成に関して以下
の事項を開示する。

【０１５２】（１）コンピューティング環境のクラスタ
を自動的に構成する方法であって、前記方法が、前記コ
ンピューティング環境のクラスタに追加すべきノードに
より、前記クラスタの１つまたは複数のリソースの構成
データの取得を開始することと、前記クラスタのシステ
ム・レジストリ・コンポーネントに前記構成データを記
憶することと、前記構成データが更新されたことを前記
システム・レジストリ・コンポーネントにより１つまた
は複数の他のクラスタ・コンポーネントに通知すること
を含む方法。 （２）少なくとも前記通知の開始後に、前記クラスタに
前記ノードを挿入することをさらに含む、上記（１）に
記載の方法。 （３）コンピューティング環境のクラスタを自動的に構
成するシステムであって、前記システムが、前記コンピ
ューティング環境のクラスタに追加すべきノードによ
り、前記クラスタの１つまたは複数のリソースの構成デ
ータの取得を開始するための手段と、前記クラスタのシ
ステム・レジストリ・コンポーネントに前記構成データ
を記憶するための手段と、前記構成データが更新された
ことを前記システム・レジストリ・コンポーネントによ
り１つまたは複数の他のクラスタ・コンポーネントに通
知するための手段とを含むシステム。 （４）少なくとも前記通知の開始後に、前記クラスタに
前記ノードを挿入するための手段をさらに含む、上記
（３）に記載のシステム。 （５）コンピューティング環境のクラスタを自動的に構
成する方法を実行するためのプログラムであって、前記
プログラムがコンピュータに前記コンピューティング環
境のクラスタに追加すべきノードにより、前記クラスタ
の１つまたは複数のリソースの構成データの取得を開始
する機能と、前記クラスタのシステム・レジストリ・コ
ンポーネントに前記構成データを記憶する機能と、前記
構成データが更新されたことを前記システム・レジスト
リ・コンポーネントにより１つまたは複数の他のクラス
タ・コンポーネントに通知する機能とを実現させるプロ
グラム。 （６）少なくとも前記通知の開始後に、前記クラスタに
前記ノードを挿入する機能をさらに含む、上記（５）に
記載のプログラム。

【図面の簡単な説明】

【図１】本発明の諸態様を組み込み使用するコンピュー
ティング環境の一例を示す図である。

【図２】本発明の一態様により、複数のクラスタを有す
るコンピューティング環境の一実施形態を示す図であ
る。

【図３】本発明の一態様により、クラスタのノードの状
態の一実施形態を示す図である。

【図４】本発明の一態様により使用するクラスタ・アー
キテクチャのコンポーネントの一実施形態を示す図であ
る。

【図５】本発明の一態様により、その環境の全ノードの
一部分にのみ図４のシステム・レジストリ・コンポーネ
ントが位置する、クラスタ化環境の一実施形態を示す図
である。

【図６】本発明の一態様により、クラスタ化アーキテク
チャの様々なコンポーネントのデータ依存関係の一例を
示す図である。

【図７】本発明の一態様により、クラスタ化アーキテク
チャの様々なコンポーネントの機能依存関係の一例を示
す図である。

【図８】本発明の一態様により、ブートストラップ・プ
ロセスのイベントおよびメッセージ・フローのシーケン
スの一実施形態を示す図である。

【図９】本発明の一態様により、クラスタ定義データ構
造の一実施形態を示す図である。

【図１０】本発明の一態様により、ノード定義データ構
造の一実施形態を示す図である。

【図１１】本発明の一態様により、レジストリ・サーバ
・ノードのリストの一実施形態を示す図である。

【図１２】本発明の一態様により、ローカル記憶域デー
タ・フィールドの一例を示す図である。

【図１３】本発明の一態様により、クラスタ化システム
の固有ノード識別子の一実施形態を示す図である。

【図１４】本発明のノード定義プロセスに関与するプロ
セスの一実施形態を示す図である。

【図１５】本発明の一態様により、ノード定義プロセス
のイベントおよびメッセージ・フローのシーケンスの一
実施形態を示す図である。

【図１６】本発明の自動クラスタ構成技法が使用する様
々なプロセスの一例を示す図である。

【図１７】本発明の自動クラスタ構成を可能にするため
の図１６のプロセス間のメッセージ・フローの一例を示
す図である。

【図１８】本発明の一態様により、複数のクラスタに対
して定義中のノードの一例を示す図である。

【図１９】本発明の一態様により、あるクラスタから他
のクラスタへ移動するノードの一例を示す図である。

【図２０】本発明の一態様により、あるクラスタから他
のクラスタ内へ移動するためのプロセスのイベントおよ
びメッセージ・フローのシーケンスの一実施形態を示す
図である。

【図２１】本発明の一態様により、ノード・アドレス定
義データ構造の一例を示す図である。

【図２２】本発明の一態様により、サブネットワーク定
義データ構造の一例を示す図である。

【図２３】本発明の一態様により、ネットワーク定義デ
ータ構造の一態様を示す図である。

【図２４】本発明の一態様により、サービスを位置指定
するための特定アドレスを選択するためにクラスタ化環
境のクライアントが使用する論理の一実施形態を示す図
である。

【図２５】本発明の一態様により、ノード・アドレス定
義をサブネットワーク定義およびネットワーク定義にマ
ッピングする場合の一例を示す図である。

【図２６】本発明の一態様により、特定サービスに到達
するためにクラスタ内の特定のノードが使用すべきアド
レスの順序付きリストを生成するために使用する論理の
他の実施形態を示す図である。

【符号の説明】

４００ 分散構成マネージャ・サブシステム ４０２ システム・レジストリ・サブシステム ４０４ 活性サブシステム ４０６ グループ・サービス・サブシステム ４０８ リソース・マネージャ・サブシステム ４１０ オペレーティング・システム・インスタンス１
プロセス空間、オペレーティング・システム・インスタ
ンス２プロセス空間、オペレーティング・システム・イ
ンスタンス３プロセス空間 ４１２ ＤＣＭプロセス ４１４ システム・レジストリ・プロセス

フロントページの続き (72)発明者 マルコス・エヌ・ノヴァエス アメリカ合衆国12533 ニューヨーク州ホ ープウェル・ジャンクション リッジ・ビ ュー・ロード 10 (72)発明者 グレゴリー・ディー・レイブ アメリカ合衆国12401 ニューヨーク州キ ングストン オークウッド・ドライブ ア ール・ディー３ (72)発明者 ジェフリー・エス・ルカシュ アメリカ合衆国12443 ニューヨーク州ハ ーリー アルタモント・ドライブ 129 (72)発明者 ロナルド・ティー・ゲーリング アメリカ合衆国78703 テキサス州オース チン エルトン・アベニュー 1907 (72)発明者 ジョージ・ソホス アメリカ合衆国07041 ニュージャージー 州ミルバーン スプリング・ストリート 25ビー Ｆターム(参考） 5B045 GG01

Claims (6)

【特許請求の範囲】
1. 【請求項１】コンピューティング環境のクラスタを自動
   的に構成する方法であって、前記方法が、 前記コンピューティング環境のクラスタに追加すべきノ
   ードにより、前記クラスタの１つまたは複数のリソース
   の構成データの取得を開始することと、 前記クラスタのシステム・レジストリ・コンポーネント
   に前記構成データを記憶することと、 前記構成データが更新されたことを前記システム・レジ
   ストリ・コンポーネントにより１つまたは複数の他のク
   ラスタ・コンポーネントに通知することを含む方法。
2. 【請求項２】少なくとも前記通知の開始後に、前記クラ
   スタに前記ノードを挿入することをさらに含む、請求項
   １に記載の方法。
3. 【請求項３】コンピューティング環境のクラスタを自動
   的に構成するシステムであって、前記システムが、 前記コンピューティング環境のクラスタに追加すべきノ
   ードにより、前記クラスタの１つまたは複数のリソース
   の構成データの取得を開始するための手段と、 前記クラスタのシステム・レジストリ・コンポーネント
   に前記構成データを記憶するための手段と、 前記構成データが更新されたことを前記システム・レジ
   ストリ・コンポーネントにより１つまたは複数の他のク
   ラスタ・コンポーネントに通知するための手段とを含む
   システム。
4. 【請求項４】少なくとも前記通知の開始後に、前記クラ
   スタに前記ノードを挿入するための手段をさらに含む、
   請求項３に記載のシステム。
5. 【請求項５】コンピューティング環境のクラスタを自動
   的に構成する方法を実行するためのプログラムであっ
   て、前記プログラムがコンピュータに前記コンピューテ
   ィング環境のクラスタに追加すべきノードにより、前記
   クラスタの１つまたは複数のリソースの構成データの取
   得を開始する機能と、 前記クラスタのシステム・レジストリ・コンポーネント
   に前記構成データを記憶する機能と、 前記構成データが更新されたことを前記システム・レジ
   ストリ・コンポーネントにより１つまたは複数の他のク
   ラスタ・コンポーネントに通知する機能とを実現させる
   プログラム。
6. 【請求項６】少なくとも前記通知の開始後に、前記クラ
   スタに前記ノードを挿入する機能をさらに含む、請求項
   ５に記載のプログラム。