(57)【特許請求の範囲】
【請求項１】
３以上のクラスタ・コンピュータ・システムを含むマルチクラスタ化コンピ
ュータ・システムであって、
各クラスタ・コンピュータ・システムは単一のノードからなり、
クラスタ・サービスによって管理されている各ノードが、
当該ノード上でオンライン状態にされる資源であって、ミラー化され又はマルチポート化されたローカルディスク、共用ディスク及びアプリケーションの少なくとも１つを含む、前記資源と、
予め定められた２つのノード間の自動フェールオーバ機能を有する第１の手段であって、前記自動フェールオーバ機能は、ノードが故障した場合において、該故障したノードに含まれる資源を故障したノード以外のノード上でオンライン状態にする機能を有し、前記自動フェールオーバ機能を第２の手段から呼び出すためのインターフェース手段を備える、前記第１の手段と、
前記第１の手段を、前記インターフェース手段を介して制御する第２の手段であって、
ノードの状態をモニタし、故障が発生すると、クラスタ・コンピュータ・システム上で回復処理を開始する事象アダプタと、
ノードに含まれる各資源について、ノードの状態、資源に好適なノードのリスト、及びフェールオーバに関する所定の指針にもとづき、フェールオーバ先のノードを計算する回復サービス手段と
をさらに含む、前記第２の手段と
を含み、
ここで、ノードが故障することに応じて、
前記第２の手段は、
前記故障したノードに含まれる各資源について、フェールオーバ先のノードを計算し、及び、
前記計算によって特定されたノードに含まれる前記第２の手段は、
前記インターフェース手段を介して、前記故障したノードに含まれる前記資源を自ノード上でオンライン状態にし、
これにより、予め定められた２つのノード間の前記自動フェールオーバ機能が、前記３つ以上のノードから選択されたノードへの自動フェールオーバ機能へと拡張されていることを特徴とする、前記マルチクラスタ化コンピュータ・システム。
【請求項２】
前記第２の手段が前記資源を管理するためのクラスタ・マネージャ手段をさらに含む、請求項１記載のマルチクラスタ化コンピュータ・システム。
【請求項３】
前記第１の手段が、ハートビートを送信して、予め定められた２つの前記ノード間の通信を管理する手段をさらに含み、
前記第２の手段が、ハートビートを送信してノード間の通信を管理するトポロジ・サービス手段をさらに含む場合には、前記第１の手段のハートビートは無視される、請求項１または２記載のマルチクラスタ化コンピュータ・システム。
【請求項４】
前記第２の手段が、各資源の状態をチェックして、当該資源が既に或るノード上でオンライン状態である場合には、他のノードでオンライン状態にされるのを阻止する手段をさらに含み、これにより、故障したノードが再始動される際に、故障前の状態に戻そうとして発生する資源競合が防止される、請求項１〜３のいずれか１項記載のマルチクラスタ化コンピュータ・システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は一般に分散データ処理システムに関し、特に分散データ処理システム内のサーバ・システムを管理する方法及び装置に関する。より詳細には、本発明はクラスタ化コンピュータ・システムを管理する方法及び装置に関する。
【０００２】
【従来の技術】
クラスタ化コンピュータ・システムは、相互接続された全コンピュータの集合を含み、単一の統一化されたコンピュータ資源として使用される並列または分散システムのタイプである。前記定義内の用語"全コンピュータ"は、スタンドアロンの使用可能なコンピュータを構成する要素、すなわち１つ以上のプロセッサ、受け入れ可能な量のメモリ、入出力機構、及びオペレーティング・システムの通常の組み合わせを示すように意味される。クラスタと従来の分散システムとの間の別の違いはパーツ間の関係に関わる。最新の分散システムは、ピア・ツー・ピアの基礎となる通信層を使用する。真性の階層または他の構造は存在せず、単に通信エンティティの平坦なリストである。しかしながら、より高いレベルの抽象化では、それらはクライアント−サーバ・パラダイムに編成される。これはシステム複雑化の貴重な低減をもたらす。クラスタは一般にピア・ツー・ピア関係を有する。
【０００３】
クラスタ化の普及を説明するための３つの技術的傾向が存在する。第１に、マイクロプロセッサが益々高速化しつつある。マイクロプロセッサが高速になるほど、大規模な並列システムの重要性は低減する。適度に高速な結果を達成するために、スーパ・コンピュータまたは数千個のマイクロプロセッサの集合体を使用することは、もはや必要でない。クラスタ化コンピュータ・システムの普及を増加させた第２の傾向は、コンピュータ間の高速通信の増加である。クラスタ・コンピュータ・システムは、"クラスタ"とも呼ばれる。ファイバ・チャネル規格（ＦＣＳ）、非同期式伝送モード（ＡＴＭ）、スケーラブル・コヒーレント相互接続（ＳＣＩ）、及び交換ギガビット・イーサネットなどの標準化通信機構の導入は、コンピュータ間帯域幅を１０Ｍビット／秒から数百Ｍバイト／秒に、更には数ギガバイト／秒にさえ向上させる。最後に、分散コンピュータのための標準ツールが開発された。分散コンピュータの要件は、マシンのクラスタの管理に適応化され得るソフトウェア・ツールの集合をもたらした。インターネット通信プロトコル組（ＴＣＰ／ＩＰ及びＵＤＰ／ＩＰと呼ばれる）などのあるものは、遍在する業界標準として一般的となった。イントラネット、インターネット及びワールド・ワイド・ウェブなどの基盤上で構築された高レベル機構も、同様に遍在的となりつつある。更に、マルチセンス管理のための他のツール・セットが一般的となった。一緒に、これらはクラスタ・ソフトウェアを作成するために活用するのに有効な基盤である。
【０００４】
これらの３つの技術的傾向に加え、コンピュータ・クラスタのための成長しつつある市場が存在する。本質的に、市場は高信頼性のコンピュータを求めている。換言すると、コンピュータ・ネットワークは"高可用性（high availability）"を有さねばならない。例えば、コンピュータがウェブ・サイトを運営するために使用される場合、その利用は必ずしも正規の仕事時間に制限されない。換言すると、コンピュータは１年を通じて毎日２４時間アクセスされ得る。修復のためにシャットダウンするための安全な時間は存在しない。代わりに、クラスタ化コンピュータ・システムが有用である。なぜなら、クラスタ内のあるコンピュータがシャットダウンしても、それが修復されるまで、クラスタ内の他のコンピュータがその責任を引き受けるからである。ユーザに示されるまたは検出されるダウン時間は存在しない。
【０００５】
企業は同様に別の理由により、"高可用性"を必要とする。例えば、企業間イントラネットの利用は、企業と下請け会社またはベンダとを接続する。イントラネットのファイル・サーバがダウンすると、複数の会社による業務が強く影響を受ける。企業がモバイル労働力人口を有する場合、その労働力人口は情報及びメッセージをダウンロードするために、オフィスに接続できなければならない。オフィスのサーバがダウンすると、その労働力人口の有効性が減少する。
【０００６】
コンピュータ・システムは、単ポイント故障（single point of failure）の置換可能部品が存在しなければ、高可用性であり、全体的に何か別の物が壊れる前に壊れた部品を修復できれば、十分に信頼性がある。高可用性を達成するためにクラスタ内で使用される基本技術は、フェールオーバである。その概念は十分に単純である。すなわち、あるコンピュータ（Ａ）が別のコンピュータ（Ｂ）を監視し、Ｂが死ぬと、ＡはＢの作業を引き継ぐ。従って、フェールオーバは、あるノードから別のノードへの"資源"の移動を含む。ノードはコンピュータのための別の用語である。多くの異なる種類の物事、すなわち物理ディスク所有権、論理ディスク・ボリューム、ＩＰアドレス、アプリケーション・プロセス、サブシステム、プリント・キュー、共用データ・システムにおけるクラスタ全体に渡るロックの収集などが潜在的に関連する。
【０００７】
資源は互いに依存し合う。この関係は問題となる。なぜなら、例えばあるノードが使用するデータが別のノードに移動されるとき、アプリケーションをあるノードに移動することを支援しないからである。実際、必要なディスク・ボリュームが実装される前に、アプリケーションが開始される場合、あるノードはそれらの両方を同一のノードに移動することさえ支援しない。
【０００８】
ＩＢＭ  ＨＡＣＭＰ及びマイクロソフト"Wolfpack"（マイクロソフト社の商標）などの最新のクラスタ・システムでは、資源関係情報がクラスタ全体に渡るデータ・ファイル内に保持される。互いに依存し合う資源は資源グループとして編成され、階層としてそのデータ・ファイル内に記憶される。資源グループはフェールオーバの基本ユニットである。
【０００９】
図１を参照すると、本発明が実装され得る分散データ処理システムの絵表現が示される。
【００１０】
分散データ処理システム１００は、本発明が実装され得るコンピュータのネットワークである。分散データ処理システム１００は１つ以上の公衆網１０１を含み、これは分散データ処理システム１００内で接続される様々な装置、クライアント・コンピュータ、及びサーバ・コンピュータ間の通信リンクを提供するために使用される媒体である。公衆網１０１は、トークン・リング、イーサネット、１００Ｍｂイーサネット、ギガビット・イーサネット、ＦＤＤＩリング、ＡＴＭ、及び高速交換機などの永久接続、或いは電話接続を通じ形成される一時接続を含み得る。クライアント・コンピュータ１３０及び１３１は、サーバ・コンピュータ１１０、１１１、１１２及び１１３と、公衆網１０１を介して通信する。
【００１１】
分散データ処理システム１００は任意的に、それ自身の専用通信ネットワーク１０２を有する。専用通信ネットワーク１０２上の通信は、多数の手段を通じて実行され、それらには公衆網１０１のような標準ネットワーク、共用メモリ、共用ディスクまたはその他の手段が含まれる。図示の例では、複数のサーバ１１０、１１１、１１２及び１１３が、公衆網１０１及び専用ネットワーク１０２の両方を通じて接続される。これらのサーバは専用ネットワーク１０２を利用し、通信オーバヘッドを低減する。こうしたオーバヘッドは、互いのハートビート（heartbeat）、メンバシップ及びｎフェーズ・コミット・プロトコルに起因する。
【００１２】
図示の例では、全てのサーバが、ユーザ・アプリケーション・データを記憶するために使用される共用ディスク記憶装置１２４、好適には高信頼性のＲＡＩＤ（Redundant Array of Independent Disks）装置に接続される。サーバが故障しても、共用ディスク区分及び論理ディスク・ボリュームが別のノードにフェールオーバされ、データが使用可能であり続ける点でデータは高可用性である。共用ディスク相互接続はＳＣＳＩ（Small Computer System Interface）バス、ファイバ・チャネル、またはＩＢＭ  ＳＳＡ（Serial Storage Architecture）などである。或いは、各サーバ・マシンがローカル・データ記憶装置１２０、１２１、１２２及び１２３を有し得る。図１は１例に過ぎず、本発明のプロセスにおけるアーキテクチャ的な制限を意図するものではない。
【００１３】
図２を参照すると、マイクロソフト・クラスタ・サービス（ＭＳＣＳ）を使用するクラスタ・コンピュータ・システム２００が、ＮＴサーバ・ベースのアプリケーションのために、高可用性を提供するために設計される。初期ＭＳＣＳは２ノード２０２、２０４及び共用ディスク２０８のクラスタにおいて、フェールオーバ機能をサポートする。
【００１４】
各ＭＳＣＳクラスタは１つまたは２つのノードを含む。各ノードは、マイクロソフト・クラスタ・サービスのそれ自身のコピーを実行する。各ノードはまた、マイクロソフト・クラスタ・サービスと対話する１つ以上のリソース・モニタを有する。これらのモニタはマイクロソフト・クラスタ・サービスに、個々の資源の状態について"通知"する。必要に応じてリソース・モニタはリソースＤＬＬを使用し、個々の資源を操作する。資源が故障すると、マイクロソフト・クラスタ・サービスは、資源再始動ポリシ、資源グループ・フェールオーバ・ポリシ及びクラスタ・ステータスに従い、故障した資源をローカル・ノード上で再始動するか、資源グループを他のノードに移動する。
【００１５】
ＭＳＣＳクラスタ内の２つのノードは、互いにハートビートする（２０６）。一方のノードが故障すると、すなわちハートビート信号を他のノードに送信できなくなると、全てのその資源グループが残りのノード上で再始動される。クラスタ・ノードがブートされるとき、事象プロセッサの制御の下で、クラスタ・サービスが自動的に開始される。事象プロセッサは、事象を他のコンポーネントにディスパッチするその正規の役割に加え、初期化を実行し、次にメンバシップ・マネージャとも呼ばれるノード・マネージャに、クラスタに加わるように、またはクラスタを生成するように告げる。
【００１６】
ノード・マネージャの正規のジョブは、他のノード・マネージャとのハートビート交換を通じて、クラスタ・メンバシップの状態の一貫したビューを生成することである。ノード・マネージャは、クラスタ構成データベースの自身のコピー内に保持される情報から、それらが誰であるかを知る。このデータベースのコピーは、実際にはウィンドウズＮＴレジストリの一部であり、異なって更新される。ノード・マネージャは最初に、他のノードに連絡しようとし、それが成功すると、クラスタに加わろうとして、認証（パスワード、クラスタ名、自身の識別など）を提供する。既存のクラスタが存在し、何らかの理由で、新たなノードの加入の試みが拒絶される場合、そのノード及びそのノード上に配置されるクラスタ・サービスがシャットダウンされる。
【００１７】
しかしながら、ノードの加入要求に誰も応答しない場合、ノード・マネージャは新たなクラスタを始動しようとする。そのために、ノード・マネージャは定数資源（quorum resource）と呼ばれる特殊な資源を使用し、これは構成データベース内の全ての資源のように指定される。あらゆるクラスタ内には、正に１つの定数が存在する。それは実際にはディスクであり、その場合、ディスクをミラー化するか、或いは故障許容にする以外に、冗長アダプタ接続によりマルチポート化することが非常に好ましい。なぜなら、そうでないとディスクはクラスタにとって単ポイント故障となるからである。定数資源として使用される装置は、次の３つの属性を有するどのようなものであってもよい。すなわち、データを（故障に渡り）永続的に記憶でき、他のクラスタ・ノードがそれに達することができ、他の全てのノードを除外して、あるノードにより捕らえられる。ＳＣＳＩ及び、ＳＳＡ及びＦＣ−ＡＬなどの他のディスク・プロトコルは、正にこのオペレーションを可能にする。
【００１８】
定数資源は実際上、クラスタの大域制御ロックである。定数資源を成功裡に捕らえたノードはクラスタを固有に定義する。他のノードはクラスタの一部になるために、そのノードと一緒にならなければならない。これは区分化されたクラスタの問題を阻む。内部クラスタ通信が故障し、クラスタを互いに通信できない２つの部分に分断する可能性がある。定数資源を制御するノードはクラスタであり、他のクラスタは存在しない。
【００１９】
一旦ノードがクラスタに加入するか、クラスタを形成すると、ノードは次に、それが切り離されていた間のあらゆる変化を反映するように、その構成データベースを更新する。構成データベース・マネージャがこれを実行できる。なぜなら、勿論、そのデータベースの変化は全てのノードに渡り、一貫してトランザクションのセマンティックス（意味）に従わねばならいからであり、この場合、全ての変化のログが定数装置上に記憶される。定数装置のログを処理後、新たなノードが資源を獲得し始める。これらはディスク、ＩＰ名、ネットワーク名、アプリケーション、或いはオフラインまたはオンラインの何か他のものである。これらは全て、それらの実行に適したノード、それらが実行され得るノード（一部は適切なディスクまたはネットワークに接続できないかもしれない）、お互いの関係、及びそれらに関する別のあらゆることと一緒に構成データベース内にリストされる。資源は通常、資源グループに形成され、資源グループとして管理される。例えばＩＰアドレス、ファイル共有（ファイル・システムの共有可能単位）、及び論理ボリュームが、ネットワーク・ファイル・システムをクライアントに提供する資源グループの主要要素である。従属性が追跡され、いずれの資源も複数の資源グループの一部とはなり得ない。従って、２つのアプリケーションによる資源の共有は、これらの２つのアプリケーションが同一の資源グループ内にない限り、禁止される。
【００２０】
新たなノードのフェールオーバ・マネージャは、新たなノードに移動（フェールオーバ）すべき資源を突き止めるために呼び出される。それは資源の好適なノードのような情報を使用し、他のノードのフェールオーバ・マネージャと折衝することによりこれを実行する。それらが共同決定に至ると、他のノードからこのノードに移動すべきあらゆる資源グループが、そのノード上でオフライン化され、それが終了すると、資源マネージャが新たなノード上でそれらをオンライン化する。
【００２１】
データベース・ソフトウェアのあらゆる主要ベンダは、複数のＮＴサーバに渡り動作するそれらのデータベースのバージョンを有する。ＩＢＭ  ＤＢ２拡張企業版（Extended Enterprise Edition）は、３２個のノード上で実行する。ＩＢＭ  ＰＣカンパニは、オラクル（Oracle）並列サーバを実行する６ノードＰＣサーバ・システムを出荷した。これらの大規模なクラスタのための満足のいくシステム・クラスタ化ソフトウェアが存在しない。
【００２２】
６ノード・オラクル並列サーバ・システムでは、これらの６ノードが共通のディスク記憶装置を共有する。オラクルはそれ自身のクラスタ化フィーチャを使用し、資源を管理し、ロード平衡化及び故障回復を実行する。それらのクラスタ上で自身のアプリケーション・ソフトウェアを実行する顧客は、彼らのアプリケーションを高可用性にするために、システム・クラスタ化フィーチャを必要とする。
【００２３】
図３を参照すると、ＤＢ２は一般に非共用アーキテクチャ２１０を使用し、各ノード２１２はそれ自身のデータ記憶装置２１４を有する。データベースは区分化され、データベース要求は並列処理のために全てのノードに分散される。高可用性を実現するために、ＤＢ２はシステム・クラスタ化からフェールオーバ機能を使用する。ＭＳＣＳは２つのノードだけしかサポートしないので、ＤＢ２は図示のように、各ノード２１２にスタンバイ・ノード２１６を割当てなければならないか、図４に示されるように、各ＭＳＣＳノード対間で相互フェールオーバを可能にする。換言すると、２つのノード２１２、２１２ａが２つのデータ記憶装置２１４、２１４ａに相互に接続される。前者はシステムのコストを２倍にし、後者はノード故障の場合に性能劣化を被る。データベース・アクセスは全てのノードに分散され、並列に処理されるので、ＤＢ２インスタンス及びフェールオーバ化インスタンスの両方を実行するノードは性能障害となる。換言すると、ノード２１２ａが故障すると、ノード２１２がその責任を引き受け、両方のデータ記憶装置上のデータをアクセスするが、そのタスクを並列に実行する。
【００２４】
【発明が解決しようとする課題】
従って、クラスタ・コンピュータ・システムを管理する改善された方法及びシステムを有することが有利である。こうした改善は、多くのノードのグループから選択された、あるノードから別のノードへのフェールオーバをサポートすべきである。
【００２５】
【課題を解決するための手段】
本発明は、クラスタ化コンピュータ・システムを管理する方法及び装置を提供するもので、"クラスタ"とも呼ばれる多数のクラスタ・コンピュータ・システムを管理する機構を提供することにより、クラスタ化を非常に大規模なクラスタに拡張する。特に、本発明は、多数のクラスタ・コンピュータ・システム内のあるクラスタ・コンピュータ・システムの再始動の開始を検出する。クラスタ・コンピュータ・システムの再始動の開始は、クラスタ・コンピュータ・システムを選択状態において再始動させる。更に、このクラスタ・コンピュータ・システムは１つ以上の資源を含む。再始動されるクラスタ・コンピュータ・システム内の１つ以上の資源が、現在クラスタ・コンピュータ・システム内の別のクラスタ・コンピュータ・システムにおいて動作中であるとの決定に応じて、これらの資源の再始動が阻止される。
【００２６】
【発明の実施の形態】
本発明は大規模クラスタを管理するためのマイクロソフト・クラスタ・マネージャ機能を拡張するが、その他の点では使い易さの特性を保存する。本願では、"マルチクラスタ"は、２つ以上のクラスタ・コンピュータ・システムのクラスタを指す。
【００２７】
更に、本クラスタ・システムは、２つ以上のノードの大規模クラスタ内の任意の２つのノード間の資源グループ・フェールオーバをサポートする。本システムはまた、故障事象に際してクラスタ全体に渡り、アプリケーション状態情報を保存する。また、本システムは現在使用可能なクラスタ・コンピュータ・システム製品の変更実装を要求しない。例えば、ＭＳＣＳに関しては、本発明の機構は本システムの環境で実行するために、マイクロソフト及びアプリケーション・ベンダに、彼らの現クラスタリング・コードの変更を要求しない。代わりに、本システムは、ＭＳＣＳクラスタＡＰＩ  ＤＬＬとバイナリ互換のＭＳＣＳクラスタＡＰＩ  ＤＬＬの実行を提供する。
【００２８】
マルチクラスタは通常、２対以上のクラスタを含む。本発明は、複数のＭＳＣＳクラスタを内部に有するクラスタを構成できる、クラスタ・マネージャを提供する。マルチクラスタ内の資源は、クラスタ・サービスの監視下で、各個々のクラスタにより管理される。マイクロソフト資源ＡＰＩ及びマイクロソフト・クラスタ・アドミニストレータ拡張ＡＰＩを変更する必要はない。クラスタ・マネージャは、ＭＳＣＳの変更無しに、ＭＳＣＳのために開発される任意のクラスタ・アドミニストレータ拡張ＤＬＬを使用できる。
【００２９】
アプリケーションは、それらがＭＳＣＳのために拡張されるか否かに関わらず、本発明のシステム・クラスタ化フィーチャを容易に利用できる。１対のノード間の相互フェールオーバの代わりに、本発明は大規模クラスタ内の任意の２つのノード間のアプリケーション・フェールオーバを可能にする。本発明は、クラスタが１対のノードまたは１つのノードを有するＭＳＣＳクラスタを追加することにより、そのサイズを成長させることを可能にする。本発明が３ノード・クラスタをサポートできる事実は、２ノード・クラスタ上の任務に厳格なアプリケーションの可用性を更に改善したい多くの顧客にとって、非常に魅力的である。
【００３０】
ＭＳＣＳを使用するＤＢ２拡張企業版などのアプリケーションは、マルチクラスタ・システムのクラスタ化フィーチャを容易に利用できる。ＤＢ２／ＥＥＥは、図４に関連して前述したように、ノードを対に分割することにより、ＭＳＣＳフィーチャを利用し、各ノード対の間の相互フェールオーバを可能にする。本発明はＮウェイ・フェールオーバをサポートすることにより、ＤＢ２可用性を改善するか、１つのスタンバイ・ノードを有するＮ＋１モデルをサポートすることによりＤＢ２性能特性を改善する。単ノード故障のほとんどの一般的事象では、故障ノード上のＤＢ２／ＥＥＥインスタンスがスタンバイ・ノード上で再始動され、Ｎ＋１モードにおいて同一の性能を維持する。システム管理ポリシ及び回復サービスが高級言語により表現され、アプリケーション・ベンダからの特殊な要求に合うように容易に変更され得る。例えば、このことはＤＢ２／ＥＥＥがＭＳＣＳクラスタとよりも、マルチクラスタと一緒に統合されることを可能にする。
【００３１】
本発明は任意のクラスタ・サービス・プログラム上で使用され得ることが理解されなければならない。図示の例は、マルチクラスタ内のＭＳＣＳクラスタを示すが、本発明のプロセス、機構及び命令は、全てのタイプのクラスタの管理に適用され得る。本発明はその特定の製品上での使用に制限されるものではない。例えば、本発明は異種のマルチクラスタにも適用され得る。
【００３２】
図５を参照すると、本発明が実装され得る分散データ処理システムの絵図が示される。図５、図７及び図８に示されるソフトウェア３００は、図６に示されるハードウェア上で実装され得る。ここで示されるマルチクラスタ・ソフトウェアのプロセスは、より大きなサイズに容易に拡大され得る。例えば、図６は８ノード構成を示し、各ノード３５０はディスク制御装置３６０により、記憶要素３４０に接続される。図５のクラスタ・サービス３０４は、この８ノード・クラスタ内の任意の２つのノード間のフェールオーバを可能にする。用語"クラスタ・サービス"は、ここでは本発明により提供されるサービスを指すために使用される。クラスタ・サービス３０４などのクラスタ・サービスは、ＭＳＣＳクラスタなどのクラスタを制御するために使用される。これは前述のオラクル・クラスタまたはＤＢ２クラスタの両方において使用され得る。７つのノードのいずれかが故障した場合、ＤＢ２インスタンスが８ノード上で再始動され、システムの性能が変更無く維持される。これはＮ＋１フェールオーバ・モデルと呼ばれる。他の構成もサポートされる。例えば、各ノードが活動ＤＢ２インスタンスを実行し、他の７つのノードのバックアップ用であることにより、信頼性を最大化する。ＭＳＣＳは図示の例では、単ノードの資源管理を実行するために使用される。マイクロソフトは、ウィンドウズＮＴ内のその資源管理ＡＰＩを外部のベンダと共用しないので、他のベンダが資源管理を実行するための容易な方法が存在しない。一部のベンダは彼ら自身のデバイス・ドライバ及びＴＣＰ／ＩＰプロトコル・スタックを実装した。その結果、ＭＳＣＳクラスタＡＰＩ及び資源ＡＰＩとの非互換性が生じる。本発明はＭＳＣＳを使用し、単ノード上で資源を管理するものであり、従って内部ＮＴ  ＡＰＩを知る必要がない。再度、マイクロソフト・クラスタ製品を参照すると、本発明は決してその製品上での使用に制限されるものではなく、任意のクラスタ・サービス・プログラム上で使用され得るものである。
【００３３】
図５を参照すると、クラスタ・サービス３０４はＭＳＣＳ３０６を制御し、資源及び資源グループをノード３５０上でオンラインまたはオフライン化する。クラスタ・サービス３０４は、異なるノード３５０及び３５０ａ上に配置されるそれぞれＭＳＣＳ３０６及び３０６ａを制御するように示される。クラスタ・サービス３０４はＭＳＣＳ３０６に、アプリケーション３７０を含む資源グループをオフライン化するように指示し、次にＭＳＣＳ３０６ａにその資源グループをオンライン化するように指示する。クラスタ・サービス３０４はクラスタ・ノード・メンバシップ、ハートビート、ノード間通信を管理し、また全ての８ノードに対して、クラスタ構成データベースの一貫性を維持する責任がある。クラスタ・サービスはまた、事象通知及び処理の責任がある。クラスタ・マネージャ３０２はグラフィカル・ユーザ・インタフェース（ＧＵＩ）を提供する。
【００３４】
クラスタ・サービス３０４はこの例では、本来ＭＳＣＳとバイナリ互換である。マルチクラスタ内で任意のアプリケーションを実行するために、そのアプリケーションがＭＳＣＳクラスタ内で実行可能であれば、変更は要求されない。クラスタ・サービスが全てのＭＳＣＳクラスタＡＰＩ、資源ＡＰＩ、及びアドミニストレータ拡張ＡＰＩをサポートする。
【００３５】
図７及び図８を参照すると、マルチクラスタ内において、各ノードがクラスタ・サービスのコピーを実行する。ノード３５０がブートされるとき、クラスタ・サービス３０４が自動的に開始される。次に、ＭＳＣＳクラスタ・サービス３０６が、クラスタ・サービス３０４により開始される。この文献では、マルチクラスタ内のこれらのＭＳＣＳクラスタをＭＳＣＳサブクラスタと呼ぶ。マルチクラスタ構成データベース内の構成情報は、各ＭＳＣＳサブクラスタ内の情報のスーパセットである。全ての資源及び資源グループが、マルチクラスタ構成データベース内、及び適切なＭＳＣＳサブクラスタ内で定義される。ＭＳＣＳサブクラスタ・サービスが開始されるとき、デフォルト指定のクラスタ・グループを除く全ての資源及び資源グループがオフライン状態にされる。新たなノード上のクラスタ・サービス３０４が、ＣＳＱＬサービス・グループ３１５を通じて他の全てのノード上のクラスタ・サービス・インスタンスと共同して、そのノード上で開始されるべき資源グループを決定する。クラスタ・サービス３０４は次に、ＭＳＣＳクラスタ・サービスＡＰＩを呼び出し、それらの資源グループをオンライン状態にする。
【００３６】
各ＭＳＣＳサブクラスタは、１対のノードまたは単ノードを含む。単ノードＭＳＣＳサブクラスタの場合、ＭＳＣＳ定数資源はローカル定数資源として構成され、これは定数資源がそのノードのローカル・ディスクであることを意味する。これは１ＭＳＣＳサブクラスタ当たりの共用ディスクを節約すると思われるので、好適な構成である。
【００３７】
例えばＭＳＣＳなどの一部のクラスタ・サーバは、クラスタが最後に終了された時点の資源及び資源グループの状態を記憶する点で、固有のフィーチャを有する。ノードが再始動されるとき、ＭＳＣＳクラスタ・サービスはそれらの資源及び資源グループを以前の状態にする。資源及び資源グループをオンラインまたはオフライン状態にするかの決定は、マルチクラスタ・サービスにより行われる。ＭＳＣＳサブクラスタ（またはそのＭＳＣＳサブクラスタを実行するノード）が故障した場合、クラスタ・サービスが、そのノード上で実行されていたそれらの資源及び資源グループをいずれか他のＭＳＣＳサブクラスタ上で再始動する。故障ノード及び対応するＭＳＣＳサブクラスタが再始動され、マルチクラスタに再加入するとき、新たなノード及び新たなＭＳＣＳサブクラスタがそれらの資源及び資源グループをオンライン状態にしようとすると資源競合が発生する。この問題を解決するために、クラスタ・サービスは"隠れ"資源をあらゆる資源グループ内に追加し、この隠れ資源を、その資源グループ内の他の全ての資源の従属資源にする。隠れ資源は、マルチクラスタ構成データベース内のその資源グループの状態をチェックし、資源グループが既に別のＭＳＣＳサブクラスタ上で実行されている場合、始動を控える。
【００３８】
クラスタ・サービスは、高可用性システムにおいて現在使用可能なクラスタ・サービスのクラスタ化フィーチャを、３ノード以上に拡張し、現在使用可能なクラスタ・サービスとのバイナリ互換性を保存する。図７及び図８を参照すると、本システムのクラスタ化ソフトウェア３００は、２つの主要部分、すなわちクラスタ・マネージャ３０２及びクラスタ・サービス３０４から成る。クラスタ・マネージャ３０２は、クラスタ３０６のグループ内の全ての資源を管理し、単一クラスタのイメージをそのユーザに提供するように設計される。クラスタ・マネージャ３０２は、情報技術（ＩＴ）管理者が慣れている容易に使用可能なインタフェースを提供する。クラスタ・マネージャ３０２は、管理者がクラスタ内の高可用資源の大規模で複雑な集合を、効率的且つ効果的に管理することを可能にする。
【００３９】
クラスタ・サービス３０４は、クラスタ内の各コンピュータ３５０上で実行されるミドルウェア層であり、図示の例では、常駐マイクロソフト・ウィンドウズＮＴサーバまたは他の好適なサーバ上で実行される、実行可能コード及びライブラリのセットを含む。クラスタ・サービス３０４は相互作用するサブシステムの集合を含む。これらのサブシステムはトポロジ・サービス３０８、グループ・サービス３１０、クラスタ・コーディネータ（図示せず）、ＣＳＱＬサービス３１４、事象アダプタ３１０、回復サービス３１６、及びクラスタＡＰＩ３１８である。
【００４０】
クラスタ・コーディネータは、クラスタ・サービス３０４の始動、停止及び再始動のための機構を提供する。クラスタ内の各コンピュータ上にクラスタ・コーディネータが存在するが、それらは互いに通信することはなく、それぞれの範囲はそれが実行されるコンピュータに制限される。クラスタ・コーディネータは最初に始動される必要があるコンポーネントである。クラスタ・コーディネータは次に、他のサービスを次の順序で開始する。すなわち、スタンドアロン・モードにおけるＣＳＱＬサービス３１４、トポロジ・サービス３０８、グループ・サービス３０８、クラスタ・モードにおけるＣＳＱＬサービス３１４、回復サービス３１６、マイクロソフト・クラスタ・サービス（ＭＳＣＳ）事象アダプタ、ＭＳＣＳ、及びグループ・サービス事象アダプタ（ＧＳＥＡ）の順である。更に、クラスタ・コーディネータは、他の各々のサービスをモニタし、故障の場合、他の全てのサービス及びユーザ・アプリケーションを終了し、マルチクラスタ・クラスタ・サービスを再始動する。
【００４１】
トポロジ・サービス３０８は、活動状態であり適切に実行されているノードを判断するために使用される、ハートビートと呼ばれる特殊メッセージを送信する。各ノードはその隣接ノードのハートビートをチェックする。クラスタの構成及び代替経路の知識から、トポロジ・サービス３０８は、ハートビートの喪失がアダプタ故障またはノード故障を表すか否かを判断できる。マルチクラスタ全体に渡るトポロジ・サービス・ハートビートを支持することにより、ＭＳＣＳのノード間ハートビートは無視される。トポロジ・サービスは、どのノードが他のどのノードから到達可能かに関する情報を保持し、この情報が確実なメッセージング機能を生成するために使用される。
【００４２】
グループ・サービス３１０は、クラスタ内の同一のまたは異なるマシン上のプロセスを含むプロセス・グループの形成を可能にする。プロセスはプロバイダまたはサブスクライバとして、グループに加入できる。プロバイダは、後述するように、グループにおけるプロトコル・アクションに参加し、サブスクライバは、グループの状態またはメンバシップ（プロバイダのリスト）の変更を知らされる。グループ・サービス３１０は、プロセス・グループに対するプロセスの加入及び脱退の通知をサポートする。グループ・サービス３１０はまた、クラスタ内の全てのノードのステータスを獲得するために加入できるホスト・グループをサポートする。このステータスは、トポロジ・サービスにより保持されるノード・ステータス情報に一致するビューである。
【００４３】
マルチクラスタ内の全てのＭＳＣＳサブクラスタは、好適には単ノード・クラスタとして構成される。グループ・サービスは、ノード・アップ及びノード・ダウン事象をモニタするために使用される。
【００４４】
グループ・サービスはまた、次の機構、すなわちクラスタを認識するアプリケーションが故障状況及び再統合状況を取り扱う機構を提供する。これらの機構は確実なメッセージング機構、すなわちプロセス加入、（自発的及び非自発的な）プロセス脱退、プロセス追放、グループ状態変化、及びプロバイダ同報メッセージのための、アトミック同報及びｎフレーズ・コミット・プロトコルの上に生成される。
【００４５】
グループ・サービス３１０は、次のようにクラスタの区分化を処理する。すなわち、グループ・サービス３１０は、区分化されたクラスタが一緒に到来したことを認識すると、より少ない数のクラスタ・マシンを有する区分の一部である全てのグループに分解通知を生成する。両方の区分が等しい数のクラスタ・マシンを有する場合、それらの１つが分解されるように選択される。
【００４６】
ＣＳＱＬサービス３１４は、構成及びステータス情報を含むデータベースのためのサポートを提供する。これはスタンドアロン・モード及びクラスタ・モードの両方において機能できる。各データベースは持続分散資源であり、これはグループ・サービス３１０の使用を通じて、コヒーレントであり高可用性であることを保証される。各データベースは全てのノードに渡り複製され、ディスクにチェックポイントされるので変化がマルチクラスタ・クラスタ・サービスのリブートに渡って獲得される。ＣＳＱＬサービス３１４は、各ノードがデータの同一のコピーを有することを保証する。ＣＳＱＬサービスはまた、リブートに渡って持続しないが、全てのノード上で一貫するデータの一時タイプをサポートする。クラスタ・サービス３０４の再始動後、一時データはそれらのスタートアップ値に初期化される。ＣＳＱＬサービス３１４は、データベースに対して成された変化の通知をサポートする。各データベースは３つ組により、すなわちデータベースが最後に変更された時を示すタイムスタンプ、変更を提案したノードのＩＤ、及びＣＲＣチェックサムによりマークされる。タイムスタンプは、クラスタ全体に渡り単調に増加する論理時刻である。ＣＳＱＬサービス３１４は、データベース競合解消プロトコル（ＤＣＲＰ）を実行し、クラスタ再始動に際して、最も最新のレプリカを決定する。ノードはクラスタに再加入するとき、各置換データベースの既存のバージョンのバックアップを形成後、そのレプリカをクラスタのバージョンにより置換する。クラスタ構成データベースの変更は、ＣＳＱＬがスタンドアロン・モードからクラスタ・モードに遷移した後だけ許可される。クラスタ・モードに入る条件については、以下で詳述する。ＣＳＱＬサービスは、ローカル及び遠隔クライアント接続の両方をサポートする。
【００４７】
事象アダプタ３１２はサブシステムの状態をモニタし、故障状態が発生したとき、事象を生成する。事象は、クラスタ範囲ＣＳＱＬ構成データベース内に事象テーブルとして実装される分散事象キュー内に挿入される。クラスタ内には４つの事象アダプタ、すなわちＭＳＣＳサブシステムをモニタするＭＳＣＳ事象アダプタ、ノード及びネットワーク・インタフェース故障をモニタするグループ・サービス事象アダプタ、ユーザ要求をマルチクラスタ事象に変換するクラスタＡＰＩ事象アダプタ、及びネットワーク区分をモニタする区分阻止事象アダプタが存在する。
【００４８】
グループ・サービス事象アダプタ（ＧＳＥＡ）３１０は分散サブシステムである。各ＧＳＥＡはＧＳＥＡグループ・サービス・グループ３１１にプロバイダとして加入する。ＧＳＥＡはグループ・サービスから脱退（LEAVE）及び故障脱退（FAILURE LEAVE）通知を受信し、それらをマルチクラスタ事象に変換する。ＧＳＥＡが自発的にまたは故障によりグループから脱退するとき、ＧＳＥＡはグループとして、正に１つの事象を事象キューに挿入する。
【００４９】
マイクロソフト・クラスタ・サービス事象アダプタ（ＭＳＣＳＥＡ）３１２は、ＭＳＣＳ通知を現クラスタ・マネージャにより認識可能な事象に変換する。各ノード上で実行されるＭＳＣＳＥＡの１つのインスタンスが存在する。各ＭＳＣＳＥＡは、ローカル・ノード上でのみ実行されるＭＳＣＳ資源グループ及びＭＳＣＳ資源をモニタするために使用される。マルチクラスタ内のＭＳＣＳサブクラスタが単ノード・クラスタとして構成される場合、ＭＳＣＳハートビート機構は実際上無効にされる。ネットワーク・インタフェース故障及びノード故障は、トポロジ及びグループ・サービス・サブシステム３０８により検出される。
【００５０】
回復サービス３１６は、規則ベースのオブジェクト指向、且つトランザクション事象処理サブシステムである。事象処理は、新たな事象がクラスタ範囲ＣＳＱＬデータベース内のクラスタ全体事象テーブル内に挿入されるとき、トリガされる。回復サービスはＣＳＱＬ機能を拡張し、活動的なオブジェクト指向ＳＱＬ文処理能力をＣＳＱＬサブシステムに追加する。メソッドは活動ＳＱＬ言語により表現される。特に、次のＳＱＬ式活動ＳＱＬ文、すなわちCREATE TRIGGER、EVALUATE、EXECUTE、CONTINUE、CREATE MACRO及びLOAD DLLが導入される。CREATE TRIGGER文は、指定テーブル上のトリガをＣＳＱＬに登録する。新たな行（事象）が指定テーブル内に挿入されるとき、ＣＳＱＬは対応する事象処理規則を呼び出す。規則はＳＱＬ及び前述の活動ＳＱＬ文により表現される。EVALUATE文はSELECT文に非常に類似する。データのセットを選択する代わりに、EVALUATE文は規則のセットを選択し、それらの規則を評価する。同一のEVALUATE文により選択され、処理されるＳＱＬ及び活動ＳＱＬ文は、同一のトランザクションの一部である。EXECUTE文は、ユーザ定義ファンクション、外部プログラム、コマンド・ファイルまたはシェル・スクリプト・ファイルのいずれかを呼び出すことにより、物理システム状態を変更する。CONTINUE文は分散ＣＳＱＬサーバの間で、事象処理を同期させる。特に、CONTINUE文はCONTINUE文のポイントまで、ＣＳＱＬデータベースを同期させる。事象処理がトリガされる度に、複数のCONTINUE文が存在し得る。CREATE MACRO文は、任意のＳＱＬ文内で呼び出され得る指定マクロを定義する。マクロはＳＱＬ文内で使用され得るデータ値を返却する。LOAD DLLは、指定された動的リンク・ライブラリ（ＤＬＬ）をＳＣＱＬに動的にロードする。ＤＬＬ初期化コードの間、これはＤＬＬ内のそれらのユーザ定義ファンクションをＣＳＱＬに登録する。ユーザ定義ファンクションはEXECUTE文内で呼び出されるか、他のＳＱＬ文内に埋め込まれる。ユーザ定義ファンクションは、一般に使用される機能を提供することにより、またはＣＳＱＬサーバの外部の物理エンティティ上でアクションを開始することにより、ＳＱＬ言語を拡張する。例えば、ユーザ定義ファンクションは、ＭＳＣＳ資源管理機能を制御するために使用される。
【００５１】
マルチクラスタにおけるクラスタ・サービスの１実施例が示されるが、他の機構もクラスタ・サービスを提供するために使用され得る。例えば、ＣＳＱＬプログラミング・インタフェースはＳＱＬ文を受け取る。他のタイプのプログラミング・インタフェースまたはデータ記憶装置、或いはデータ登録機構も使用され得る。こうした実施例では、機構がマルチクラスタ内のクラスタに渡り、データの一貫性を提供し、リブートの間に様々なノードに対してデータの一貫性を提供し、またクラスタに入る新たなノードに対してデータの同期を提供する。更に、図示の例で述べられる回復サービスはＣＳＱＬの拡張であるが、こうした拡張は本発明の好適な実施例に従えば、必要でない。
【００５２】
マルチクラスタＡＰＩ３１８は、特定のＭＳＣＳクラスタへのアクセスではなしに、全体として、マルチクラスタへのアクセスを提供する。これは大規模ではあるが、その他の点では、マイクロソフト・クラスタＡＰＩの機能と機能的に同一のクラスタを扱うことができる。マルチクラスタＡＰＩ３１８は、クラスタ・マネージャ３０２の他に、クラスタを認識する他のアプリケーションにより使用されるように意図される。マルチクラスタＡＰＩ内のファンクションと、マイクロソフト・クラスタＡＰＩのファンクションとの間には、１対１の対応が存在する。２つのクラスタＡＰＩ間の類似性は、アプリケーション・ベンダがマルチクラスタ化フィーチャを利用することを支援し、将来的に２ノード・マイクロソフト・クラスタよりも大規模なものに移行することを可能にすることである。マルチクラスタＡＰＩ  ＤＬＬは、ＭＳＣＳクラスタＡＰＩ  ＤＬＬすなわちclusapi.dllとバイナリ互換である。クラスタＡＰＩファンクションの照会タイプは、直接マルチクラスタＡＰＩ  ＤＬＬにより扱われる。状態変化を生じるクラスタＡＰＩファンクションは、回復サービスにより扱われる事象に変換される。マルチクラスタＡＰＩ  ＤＬＬはＣＳＱＬ通知を使用し、事象処理の結果を待機した。マルチクラスタＡＰＩ  ＤＬＬは、周知の仮想ＩＰアドレスを介して、ＣＳＱＬサービスと通信する。要するに、クラスタ・サービス３０４は、アプリケーション・プログラムによりＮＴクラスタ・レジストリに記憶される状態情報が、アプリケーションがクラスタ内の別のノードにフェールオーバするとき、使用可能となるように保証する。クラスタ・サービス３０４は、システム構成を調査し、システムが導入及びシステム・クラスタ化フィーチャのために、適切に構成されたことを確認するユーティリティを提供する。クラスタは最初に始動されるとき、それに従い構成される。クラスタ・サービス３０４に伴い、クラスタ・マネージャ３０２がクラスタ及びそこに含まれるＭＳＣＳクラスタを構成、管理及びモニタする。複数のＭＳＣＳサブクラスタ及びマルチクラスタ・クラスタ・サービスの導入プロセスを簡略化するための、他のユーティリティも開発され得る。
【００５３】
クラスタ・サービス・サブシステムは、クラスタ・コーディネータ・サブシステムにより開始される。クラスタ・コーディネータは、ＮＴサービスとして実装され、スタートアップ時に自動的に開始される。クラスタ・コーディネータは次に、他の全てのクラスタ・サービス・サブシステムを次の順序で開始する。すなわち、スタンドアロン・モードにおけるＣＳＱＬサービス、トポロジ・サービス、グループ・サービス、クラスタ・モードにおけるＣＳＱＬサービス、回復サービス、ＭＳＣＳ事象アダプタ、ＭＳＣＳ、及びグループ・サービス事象アダプタの順である。
【００５４】
ＣＳＱＬサービスは当初、スタンドアロン・モードで開始される。トポロジ・サービス及びグループ・サービスは、それらの構成情報をＣＳＱＬデータベースから検索する。グループ・サービスが発生後、ＣＳＱＬサービスがＣＳＱＬサービス・グループ３１５を形成し、データベース競合解消プロトコル（ＤＣＲＰ）を実行し、クラスタ構成データベースの内容を同期させる。第１のＣＳＱＬサーバがグループを形成し、ＣＳＱＬサービス・グループをビディング（BIDDING）状態にセットし、他のＣＳＱＬサーバがグループに加入するのを待機するためのタイマを始動する。ビディング状態のグループに加入するＣＳＱＬサーバもまた、他が加入するのを待機するためのタイマを始動する。タイマ値はクラスタ構成データベース内で定義され、ノード間で異なり得る。タイマ値の不一致は、当初異なるノードにより使用される異なるバージョンのクラスタ構成データベースに起因する。第１のタイマが満了すると、ＣＳＱＬサーバがグループ・サービスｎフェーズ・プロトコルを用いて、そのクラスタ構成データベースのタイムスタンプをグループに同報する。他のＣＳＱＬサーバは、それらのタイムスタンプが受信されたタイムスタンプよりも最近のものである場合、それらのタイムスタンプを同報する。複数のＣＳＱＬサーバがそれらのタイムスタンプを送出するとき、グループ・サービスにより１つが任意に選択され、次のフェーズでグループに同報される。ＣＳＱＬサーバは、自身のタイムスタンプが受信タイムスタンプよりも好適である場合に限り、自身のタイム・スタンプを送出する。ＣＳＱＬサーバは第１のフェーズにおいてだけ、たとえ自身のタイプスタンプが受信タイムスタンプよりも古くても、自身のタイムスタンプを送出し、他のＣＳＱＬサーバに自身が異なるバージョンを有することを知らせるべきである。最終的に、プロトコルは終了する。全てのＣＳＱＬサーバが同一のタイムスタンプを有するか、それらが全て最も最新のバージョンに同意する。全てのタイムスタンプが同一でない場合、最後にタイムスタンプを送出するＣＳＱＬサーバが、そのデータベースを他の全てのＣＳＱＬサーバに同報する。ＣＳＱＬサーバは、最新のバージョンにより置換されるデータベースのバックアップ・コピーを形成すべきである。ＣＳＱＬサーバはクラスタ構成データベースを同期させた後、ＣＳＱＬサービス・グループの状態を実行（RUNNING）状態にセットする。レプリカが新たなバージョンにより置換されたＣＳＱＬサーバは、クラスタ・サービスの再始動を開始する。実行中のＣＳＱＬサービス・グループに加入するＣＳＱＬサーバは、そのレプリカを保管し、それをそのタイムスタンプ値に関係なしに、クラスタ・バージョンにより置換しなければならない。新たなバージョンが、現在他のサブシステムにより使用されている既存のタイムスタンプと異なるタイムスタンプを有する場合、ＣＳＱＬサーバはクラスタ・サービスの再始動を開始する。
【００５５】
ＣＳＱＬタイムスタンプは３つ組、すなわちクラスタ全体に渡り単調増加する数、データベースを最後に変更したノードのノードＩＤ、及びＣＲＣチェックサムである。
【００５６】
一旦ＣＳＱＬサービスが実行状態になると、事象キューを含むクラスタ構成データベースが、全てのノード上で一貫性を示す。ＣＳＱＬサーバは、成功裡に実行中ＣＳＱＬサービス・グループに加入するとき、クラスタ・モードにあると言われる。次に、回復サービス、ＭＳＣＳ、ＭＳＣＳ事象アダプタ（ＭＳＣＳＥＡ）、及びグループ・サービス事象アダプタ（ＧＳＥＡ）が開始される。グループ・サービス加入プロトコルの処理において、ＧＳＥＡはＧＳＥＡグループ・サービス・グループに加入し、このノードに対するコンピュータ・アップ指示（BRING_COMPUTER_UP）事象を、クラスタ全体事象キューに追加する。マルチクラスタ資源グループが最初にオフライン状態となる。コンピュータ・アップ指示事象の処理の間、回復サービスが、任意の資源グループがオンライン状態にされるべきか否かを判断する。
【００５７】
データベース競合解消プロトコル（ＤＣＲＰ）アルゴリズムは次のように要約される。すなわち、１）ＣＳＱＬサーバが、データベースの名前及びタイムスタンプを含むデータベース・オープン要求を、ＣＳＱＬサービス・グループに同報し、２）異なるタイムスタンプを有する各ＣＳＱＬサーバは継続（CONTINUE）を採決し、そのタイムスタンプを第１フェーズにおいて同報し、データベース複製を強制しなければならず、３）自身の同報を受信するＣＳＱＬサーバは、第１フェーズにおいて承認（APPROVE）を採決しなければならず、４）受信タイムスタンプと同一のタイムスタンプを有するＣＳＱＬサーバは、承認を採決しなければならず、５）続く各フェーズにおいて、受信タイムスタンプよりも最近のタイムスタンプを有するＣＳＱＬサーバは、そのタイムスタンプを同報し、継続を採決しなければならず、６）自身のタイムスタンプを受信するＣＳＱＬサーバは、継続を採決しなければならず、７）同一のまたはより早期のタイムスタンプを有するＣＳＱＬサーバは、承認を採決しなければならず、８）フェーズ内にメッセージが送信されなかった場合、タイムスタンプを最後に送信したサーバが、そのデータベース・バージョンを他のサーバに複製しなければならない。サーバは常にそのレプリカを置換する前に、そのバックアップ・コピーを形成する。
【００５８】
図７及び図８を参照すると、マルチクラスタ・システムのスタートアップ・シーケンスが示される。最初に、クラスタ・コーディネータがＮＴスタートアップの間に、ＮＴサービスとして開始される。クラスタ・コーディネータは開始し、他のマルチクラスタ・サブシステムをモニタする。次に、ＣＳＱＬサービス３１４がスタンドアロン・モードで開始される。次に、トポロジ・サービス３０８が開始される。次に、グループ・サービス３１０が開始される。次に、ＣＳＱＬサービスがＣＳＱＬサービス・グループ３１５を形成または加入する。ＣＳＱＬサービスはデータベース競合解消プロトコルを実行し、クラスタ・モードに入る。次に、全てのクラスタ範囲データベースが最新となる。特に、事象キューが最新となる。回復サービス３１６が開始され、回復サービス・デーモンが、ＭＳＣＳ事象アダプタ３１２及びグループ・サービス事象アダプタ３１０の両方をこの順序で開始する。グループ・サービス事象アダプタ（ＧＳＥＡ）３１０が開始される。ＧＳＥＡはＧＳＥＡグループを形成または加入し、それがノード故障事象をモニタする。次に、回復サービス・デーモンが、ローカル・ノードのためにコンピュータ・アップ指示事象を挿入する。回復サービスはこのノードのために、コンピュータ・アップ指示事象を処理する。ＭＳＣＳサブシステム３０６が開始され、次にＭＳＣＳ事象アダプタ３１２によりモニタされる。資源割当てポリシ及びシステム・ステータスに応じて資源グループが開始されるか、この新たなノードに移動される。
【００５９】
本発明の別の主要フィーチャは、クラスタ定数条件を含む。どの資源グループも次の定数条件の１つが満足されない限り、オンライン状態にされない。クラスタ・サービスは、ＨＡＣＭＰで使用されるのと同一の過半数定数技法を採用する。クラスタ・サービスは、グループ・サービスにより提供される接続情報を用い、過半数定数条件を決定する。更に、ノードが接続情報を共用ディスク・パスまたは他のメソッドを介して受け渡し、スプリット・ブレイン問題を回避する。ネットワークがサービスされ、クラスタが複数の区分に分割されるとき、クラスタ・サービスは複数区分内で同時に、１つの資源グループを開始しないように保証しなければならない。これは共用ディスク上のアプリケーション・データに腐敗を生じ得る。ディスク・パス上で渡される接続情報は、各区分が他の区分のサイズに関して学習することを支援し、従ってデータ腐敗を阻止する。資源グループは、次の条件が満足される場合、オンライ状態にされるべきである。すなわち、１）区分が過半数定数を有する場合、すなわちクラスタ構成データベース内で定義される全てのノードの半分以上がクラスタに加入し、その区分内に存在する場合、２）区分がクラスタ構成データベース内で定義されるノードの正に半分を有し、同一サイズの他の区分が存在しない場合、或いは３）区分がクラスタ構成データベース内で定義されるノードの正に半分を有し、別の区分がノードの他の半分を含み、最小のノードＩＤが前者の区分内に存在する場合である。
【００６０】
全てのクラスタ・サービス・サブシステムを始動後、クラスタ・コーディネータが各サブシステムのステータスをもニタする。任意のサブシステムが異常終了すると、クラスタ・コーディネータはノードをシャットダウンし、他のサブシステム同様、それ自身を再始動する。任意のサブシステムの故障に際して、ノードをシャットダウンすることは、クラスタ・サービスの故障に際して、ユーザ・アプリケーションが実行を継続しないように保証する。
【００６１】
区分が回復するとき、グループ・サービスは、１つの区分を除き、全ての区分内のグループを解消する。それらの区分内のグループ・サービス・デーモンが終了される。結果的に、それらのノードがクラスタ・コーディネータによりシャットダウンされ、再始動される。回復サービスのシャットダウン・プロシージャは、全ての資源グループがオフラインであることを確認しなければならない。
【００６２】
図８を参照すると、本発明のコンポーネント・サポートが示される。クラスタ・サービス３０４はＭＳＣＳ３０６を使用し、ノード内のクラスタ資源を管理する。最初に、資源グループがクラスタ構成データベース内で定義され、必要に応じてＭＳＣＳサブクラスタ内で定義される。資源管理ポリシは、ＭＳＣＳ資源管理振舞いをまねるように設計される。資源グループがＭＳＣＳサブクラスタ内で定義されるとき、再始動フラグが常にディセーブルされ、再始動がＭＳＣＳによってではなしに、事象処理サブシステムにより決定される。ＭＳＣＳサブクラスタ内で定義される資源グループは、それが単ノード・クラスタか否かに関わらず、好適なノード・リスト内に高々１つのノードを有する。従って、ＭＳＣＳ自動フェールオーバ機構がディセーブルされる。クラスタ・サービスは、オンラインのあらゆる資源グループのステータスをモニタする。資源または資源グループ故障が発生すると、ＭＳＣＳ事象アダプタ３１２が対応する事象を事象キュー内に挿入する。ＣＳＱＬサービス３１４は、その事象のために事象処理をトリガする。１つだけのＣＳＱＬインスタンスが事象処理を開始する。各ＣＳＱＬインスタンスが、ローカル・ノード上だけの単ノードＭＳＣＳサブクラスタを含む資源を管理する。事象処理は複数の故障を扱えるように設計される。
【００６３】
図９乃至図１１、図１２及び図１３を参照すると、本発明の別の態様は事象処理を含む。図１２に関し、テーブル５００は、２つのｃｈルーチン、すなわちコンピュータ・アップ指示及びノード・アップを示す、２つのエンティティ５０２及び５０４を示す。エントリ５０２では、セクション５０６内のアクションが、図９のステップ４０４に対応する。エントリ５０４では、セクション５０８、５１０及び５１２が、それぞれステップ４０８、４１０及び４１４に対応するアクションを含む。クラスタ・サービス内で定義される事象は、コンピュータ・アップ指示（BRING_COMPUTER_UP）、コンピュータ・ダウン指示（BRING_COMPUTER_DOWN）、資源グループ・オンライン指示（BRING_RESOURCE_GROUP_ONLINE）、資源グループ・オフライン指示（BRING_RESOURCE_GROUP_OFFLINE）、及び資源グループ移動（MOVE_RESOURCE_GROUP）などを含む。コンピュータがクラスタに加入するとき、"コンピュータ・アップ指示"事象が事象キュー内に挿入される。コンピュータ・アップ指示事象を処理するために、クラスタ・サービスが次のことを実行する。すなわち、１）定数が存在するか否かをチェックし、２）存在する場合、任意の資源グループが新たなコンピュータ上に持ち込まれるべきか否かをチェックする。一部の資源グループはある他のコンピュータ上でオンラインかも知れない。それらの資源グループは、最初にオフライン状態にされるべきである。次に、クラスタ・サービスが、オフライン状態のそれらの資源グループを、新たなコンピュータ上でオンライン化すべきである。
【００６４】
全ての構成情報、ステータス情報、資源管理ポリシ、及び規則が、クラスタ範囲データベースすなわちescluster.cfgに記憶される。コンピュータ"hilltop"がクラスタに加入するとしよう。hilltopに対するコンピュータ・ダウン指示事象が、事象キュー内に挿入され、これがＣＳＱＬをトリガして事象処理を実行し、事象に関する情報をカプセル化する実行時環境が生成され、ＣＳＱＬが次の文、すなわちEVALUATE action from ch_routine where ch_routine="BRING_COMPUTER_UP"を処理する。
【００６５】
前記文は、escluster.cfgデータベース内のch_routineテーブルのBRING_COMPUTER_UP行内の文が処理されるべきことを指定する。BRING_COMPUTER_UPと呼ばれるch_routine内で取られるアクションが、テーブル５００のエントリ５０２に示される。
【００６６】
ch_resource_groupテーブル６００が図１３で定義される。このテーブルはテーブルの１行を示す。各エントリは１カラムである。$_failback_node()は、指定された資源グループが指定フェールバック・ポリシにもとづき実行されているべきノードを返却するマクロであり、新たなノードがクラスタに再加入する事実を仮定する。$_resource_group_online()及び$_resource_group_offline()はユーザ定義ファンクションであり、ＭＳＣＳクラスタＡＰＩファンクション呼び出しを使用し、指定資源グループを指定コンピュータ・ノード上でオフライン化及びオンライン化する。"EVALUATE action from ch_routine where ch_routine="BRING_COMPUTER_UP""の処理の結果、次の文すなわち"evaluate markup_action from computers where computer+$_get_event_node();evaluate action from ch_routines where $_has_quorum90 and ch_routine=NODE_UP"が選択され、処理される。
【００６７】
NODE_UPと呼ばれるch_routineに対して取られるアクションが、図１２のテーブル５００のエントリ５０４に示される。第２のEVALUATE文の処理の結果、次の３つの文が検索され、次に処理される。
evaluate failback_action from ch_resource_groups where current_node<>next_node;
evaluate release_action from ch_resource_groups where current_node<>next node;
evaluate acquire_action from ch_resource_groups where current_node=""and next_node=$_get_event_node();
【００６８】
これらの３つのEVALUATE文は各々、ch_resource_groupテーブル内で、探索条件に合う全てのch_resource_group行（オブジェクト）を探索する。ch_resource_group行（オブジェクト）が見い出されると、指定アクションがそのオブジェクトに適用される。failback_actionは次の単一文を含む。
"update ch_resource_groups set next_node=$_failback_node() where ch_resource_group=this ch_resource_group";
【００６９】
前記更新文では、マクロfailback_node()が処理され、これは新たなノードが丁度クラスタに加入したと仮定して、指定資源グループを実行するのに最も好適なノードを返却する。更新文は返却ノード名をnext_node列に記憶する。マクロ名は"$_"を接頭部とし、解析を単純化する。
【００７０】
ch_resource_groupオブジェクトのcurrent_node列は、ch_resource_groupが実行されているカレント・ノードを示す。カレント・ノードが次のノードと異なる場合、release_actionはこのch_resource_groupに対して処理される。この場合、次の文が処理される。
execute $_resource_group_offline();
【００７１】
resource_group_offline()はユーザ定義ファンクションであり、ＭＳＣＳ  OfflineResourceGroup()ファンクションを呼び出し、示された資源グループをオフライン状態にする。ユーザ定義ファンクションは"$_"を接頭語とし、解析を単純化する。
【００７２】
最後に、acqire_actionは、どこにおいても実行されておらず、新たなノード上で実行されるべき全てのch_resource_groupオブジェクトに対して、新たなノード上で検索され、処理される。acquire_actionは１文を含む。
execute $_resource_group_online();
【００７３】
resource_group_online()もユーザ定義ファンクションであり、ＭＳＣＳ  OnlineResourceGroup()ファンクションを呼び出し、示された資源グループをオンライン状態にする。
【００７４】
クラスタ・サービスはまた事象シミュレーションをサポートする。回復サービスが呼び出され、事象をシミュレートするとき、それは最初にクラスタ構成データベースのクローンを生成する。事象シミュレーションは構成データベースの専用コピー上で実行され、従って、オリジナル構成データベースは影響されない。シミュレーションの間、EXECUTE文が物理資源の状態を実際に変更する。
【００７５】
図９は、ノードがクラスタに加入したいときに、クラスタ・サービスにより実行されるメソッド４００を示す。最初に、ノードがクラスタに加入する（ステップ４０２）。定数が存在するか否かが判断される（ステップ４０４）。存在しない場合、メソッドは復帰する（ステップ４０６）。定数が存在する場合、あらゆる資源グループに対して続くループが実行される（ステップ４０５）。最初に、任意の資源グループが新たなノードにフェールバックされるべきか否かが問い合わされる（ステップ４０８）。肯定の場合、各こうした資源グループに対して、システムは対応するＭＳＣＳサブクラスタを獲得し、指定資源グループのオフライン化を実行する（ステップ４１０）。全てのノードを同期するために、継続（CONTINUE）が実行される（ステップ４１８）。新たなノード上のＭＳＣＳサブクラスタが、指定資源グループをオンライン状態にする（ステップ４１４）。次に、更に資源グループが存在するか否かが確認される（ステップ４１２）。存在しない場合、システムは終了する（ステップ４１６）。それ以外では、メソッドがステップ４０５に戻る。
【００７６】
図１０は、資源グループをあるノードから別のノードに移動するメソッド４３０のフロー図を示す。あらゆるノードがノード・ステータス、資源グループに好適なノード・リスト、及びフェールオーバ・ポリシにもとづき、資源グループを実行するための次善のノードを計算する（ステップ４３４）。或いは、ユーザが単に次のノードを指定する。次に、システムは、カレント・ノードが次のノードに等しくないか否かを問い合わせる（ステップ４３６）。等しくない場合、システムは終了する（ステップ４３８）。等しい場合、システムはカレント・ノード上でＭＳＣＳサブクラスタを獲得し、指定資源グループをオフライン化する（ステップ４４０）。プロセスは次に継続する（ステップ４４２）。このステップの間、システムはその事象処理を同期させる。その後、システムは次のノード上のＭＳＣＳクラスタを獲得し、指定資源グループをオンライン状態にする（ステップ４４４）。最後に、システムは終了する（ステップ４４６）。
【００７７】
図１１は、ノード故障４５２が発生するとき、クラスタ・サービスにより実行される一般メソッドを示す。このメソッドは資源故障及び資源グループ故障事象にも当てはまる。グループ・サービス事象アダプタがひとまとめに、正に１つのノード・ダウン事象を事象キューに挿入する（ステップ４５４）。ノード・ダウン事象処理がトリガされる（ステップ４５６）。次に、故障ノード上で実行されていたあらゆる資源グループに対して次のステップが適用される（ステップ４５８）。最初に、回復サービスがフェールオーバのための次のノードを計算する（ステップ４６０）。次に、自身のノード（MY_NODE）が次のノード（NEXT_NODE）に等しいか否かが判断される（ステップ４６２）。等しくない場合、システムは更に資源グループが存在するか否かをチェックする（ステップ４６６）。等しい場合、システムはＭＳＣＳサブクラスタを獲得し、指定資源グループをオンライン化する（ステップ４６４）。もはや資源グループが使用可能でなくなると、システムは終了する（ステップ４６８）。更に使用可能な場合、システムはステップ４５８にループして戻る。
【００７８】
本発明はＭＳＣＳサブクラスタを使用するように述べられてきたが、これは本発明の１実施例に過ぎないことを理解することが重要である。例えば、この同一のシステムが、ＩＢＭのＨＡＣＭＰまたはサンマイクロシステムズ社のUltra Enterprise Cluster HAサーバ上で構成され、これらのクラスタ・システムを管理できる。更に、本発明の装置、プロセス及び命令が、異種のクラスタ・システムにも適用され得る。例えば本発明は、ＭＳＣＳを用いて管理されるクラスタ、及びUltra Enterprise Cluster HAサーバを使用するクラスタを含む、マルチクラスタ・システムを管理するように適用され得る。更に、本発明のプロセスは、ＳＭＰサーバなどの複数のプロセッサ・コンピュータの管理にも適用され得る。
【００７９】
本発明は完全機能型データ処理システムの状況において述べられてきたが、当業者であれば、本発明のプロセスが、命令のコンピュータ読取り可能媒体の形態、及び様々な形態で配布可能であり、本発明が実際に配布を実施するために使用される特定タイプの信号担持媒体に関係なく、同様に当てはまることが理解できよう。コンピュータ読取り可能媒体の例には、フロッピー・ディスク、ハード・ディスク・ドライブ、ＲＡＭ、ＣＤ−ＲＯＭなどの記録式タイプの媒体、及びデジタル及びアナログ通信リンクなどの伝送タイプの媒体が含まれる。
【００８０】
まとめとして、本発明の構成に関して以下の事項を開示する。
【００８１】
（１）少なくとも１つのノードを有するクラスタ化コンピュータ・システムを管理する方法であって、
ａ）前記少なくとも１つのノード及び少なくとも１つの共用資源を含むマルチクラスタを確立するステップと、
ｂ）クラスタ・サービス・プログラムにより、前記少なくとも１つのノードを管理するステップと、
ｃ）フェールオーバ事象後に、前記システムを初期状態に復帰させるステップと
を含む、方法。
（２）前記クラスタ・サービス・プログラムが、前記少なくとも１つのノード内の資源ＡＰＩを用いて管理する、前記（１）記載の方法。
（３）ステップａ）が、各々が少なくとも１つのノードを含む、少なくとも２つのクラスタのマルチクラスタを確立するステップを含む、前記（１）記載の方法。
（４）ステップａ）が少なくとも３つのノードのマルククラスタを確立するステップを含む、前記（１）記載の方法。
（５）前記マルチクラスタ内の第１のノードと任意の他のノードとの間で、フェールオーバするステップを含む、前記（１）記載の方法。
（６）クラスタ全体に渡るデータ・ファイルを更新するステップを含む、前記（５）記載の方法。
（７）ステップｂ）が、前記少なくとも１つのノードがブートされるとき、第１のクラスタ・サービス・プログラムを自動的に開始するステップを含む、前記（１）記載の方法。
（８）前記第１のクラスタ・サービス・プログラムを開始後、前記少なくとも１つのノード上に常駐する第２のクラスタ・サービス・プログラムを開始するステップを含む、前記（７）記載の方法。
（９）前記第１及び第２のクラスタ・サービス・プログラムがバイナリ互換である、前記（８）記載の方法。
（１０）ステップｂ）がクラスタ・ノード・メンバシップ・データベースを管理するステップを含む、前記（１）記載の方法。
（１１）ステップｂ）が、前記マルチクラスタ内の前記少なくとも１つのノードと、任意の他のノード間で送信されるハートビート信号を管理するステップを含む、前記（１）記載の方法。
（１２）ステップｂ）が、前記マルチクラスタ内の前記少なくとも１つのノードと、任意の他のノード間のノード間通信を管理するステップを含む、前記（１）記載の方法。
（１３）単一クラスタのイメージをクラスタ・マネージャに提供するステップを含む、前記（１）記載の方法。
（１４）ステップｂ）がマルチクラスタ定数資源をローカル定数資源として構成するステップを含む、前記（１）記載の方法。
（１５）ステップｃ）がノードを再始動し、前記共用資源を初期状態にするステップを含む、前記（１）記載の方法。
（１６）ステップｃ）が、前記共用資源の前記初期状態を記憶するステップを含む、前記（１）記載の方法。
（１７）ステップｂ）が前記共用資源の制御の競合に応答して、前記共用資源を制御しようとする故障ノードを再始動しないステップを含む、前記（１）記載の方法。
（１８）隠れ資源を各ノード上の資源グループに追加するステップを含む、前記（１７）記載の方法。
（１９）前記隠れ資源を前記資源グループ内の任意の他の資源に従属させる、前記（１８）記載の方法。
（２０）複数のパスを有するメソッドを実行するデータ処理システムであって、前記データ処理システムが固有マシン・コードを実行するものにおいて、
ａ）前記少なくとも１つのノード及び少なくとも１つの共用資源を含むマルチクラスタを確立する手段と、
ｂ）クラスタ・サービス・プログラムにより、前記少なくとも１つのノードを管理する手段と、
ｃ）フェールオーバ事象後に、前記システムを初期状態に復帰させる手段と
を含む、データ処理システム。
（２１）前記クラスタ・サービス・プログラムが、前記少なくとも１つのノード内の資源ＡＰＩを用いて管理する、前記（２０）記載のデータ処理システム。
（２２）手段ａ）が、各々が少なくとも１つのノードを含む、少なくとも２つのクラスタのマルチクラスタを確立する手段を含む、前記（２０）記載のデータ処理システム。
（２３）手段ａ）が少なくとも３つのノードのマルククラスタを確立する手段を含む、前記（２０）記載のデータ処理システム。
（２４）ｄ）前記マルチクラスタ内の第１のノードと任意の他のノードとの間で、フェールオーバする手段を含む、前記（２０）記載のデータ処理システム。
（２５）手段ｃ）がクラスタ全体に渡るデータ・ファイルを更新する手段を含む、前記（１８）記載のデータ処理システム。
（２６）手段ｂ）が、前記少なくとも１つのノードがブートされるとき、第１のクラスタ・サービス・プログラムを自動的に開始する手段を含む、前記（２０）記載のデータ処理システム。
（２７）前記第１のクラスタ・サービス・プログラムを開始後、前記少なくとも１つのノード上に常駐する第２のクラスタ・サービス・プログラムを開始する手段を含む、前記（２６）記載のデータ処理システム。
（２８）手段ｂ）が、前記マルチクラスタ内の前記少なくとも１つのノードと、任意の他のノード間で送信されるハートビート信号を管理する手段を含む、前記（２０）記載のデータ処理システム。
（２９）手段ｂ）が、前記マルチクラスタ内の前記少なくとも１つのノードと、任意の他のノード間のノード間通信を管理する手段を含む、前記（２０）記載のデータ処理システム。
（３０）単一クラスタのイメージをクラスタ・マネージャに提供する手段を含む、前記（２０）記載のデータ処理システム。
（３１）手段ｃ）が、前記共用資源の前記初期状態を記憶する手段を含む、前記（２０）記載のデータ処理システム。
（３２）手段ｂ）が前記共用資源の制御の競合に応答して、前記共用資源を制御しようとする故障ノードを再始動しない手段を含む、前記（２０）記載のデータ処理システム。
（３３）隠れ資源を各ノード上の資源グループに追加する手段を含む、前記（２０）記載のデータ処理システム。
（３４）データ処理システムにおいてメソッドを実行するコンピュータ・プログラム製品であって、
ａ）前記少なくとも１つのノード及び少なくとも１つの共用資源を含むマルチクラスタを確立する第１の命令と、
ｂ）クラスタ・サービス・プログラムにより、前記少なくとも１つのノードを管理する第２の命令と、
ｃ）フェールオーバ事象後に、前記システムを初期状態に復帰させる第３の命令と
を含む、コンピュータ・プログラム製品。
（３５）ｄ）前記マルチクラスタ内の第１のノードと任意の他のノードとの間で、フェールオーバする第４の命令を含む、前記（３４）記載のコンピュータ・プログラム製品。
（３６）前記第２の命令がクラスタ・ノード・メンバシップ・データベースを管理する命令を含む、前記（３４）記載のコンピュータ・プログラム製品。
（３７）前記第２の命令が、前記マルチクラスタ内の前記少なくとも１つのノードと、任意の他のノード間で送信されるハートビート信号を管理する命令を含む、前記（３４）記載のコンピュータ・プログラム製品。
（３８）前記第２の命令が、前記マルチクラスタ内の前記少なくとも１つのノードと、任意の他のノード間のノード間通信を管理する命令を含む、前記（３４）記載のコンピュータ・プログラム製品。
（３９）少なくとも１つのノードを有するクラスタ化コンピュータ・システムを管理する方法であって、
ａ）前記少なくとも１つのノード及び少なくとも１つの共用資源を含むマルチクラスタを確立するステップと、
ｂ）クラスタ・サービス・プログラムにより、前記少なくとも１つのノードを管理するステップであって、前記クラスタ・サービス・プログラムが、前記少なくとも１つのノード内の資源ＡＰＩを用いて管理し、前記マルチクラスタ内の前記少なくとも１つのノードと、任意の他のノード間で送信されるハートビート信号を管理するステップを含み、
ｃ）前記マルチクラスタ内の第１のノードと任意の他のノードとの間で、フェールオーバするステップと、
ｄ）クラスタ全体に渡るデータ・ファイルを更新するステップと、
ｅ）フェールオーバ事象後に、前記システムを初期状態に復帰させるステップと
を含む、方法。
（４０）ステップａ）が、各々が少なくとも１つのノードを含む、少なくとも２つのクラスタのマルチクラスタを確立するステップを含む、前記（３９）記載の方法。
（４１）ステップｂ）が、前記少なくとも１つのノードがブートされるとき、第１のクラスタ・サービス・プログラムを自動的に開始するステップを含む、前記（３９）記載の方法。
（４２）ステップｂ）が、前記マルチクラスタ内の前記少なくとも１つのノードと、任意の他のノード間のノード間通信を管理するステップを含む、前記（３９）記載の方法。
（４３）単一クラスタのイメージをクラスタ・マネージャに提供するステップを含む、前記（３９）記載の方法。
（４４）ステップｃ）が、前記共用資源の前記初期状態を記憶するステップを含む、前記（３９）記載の方法。
（４５）ステップｂ）が前記共用資源の制御の競合に応答して、前記共用資源を制御しようとする故障ノードを再始動しないステップを含む、前記（３９）記載の方法。
（４６）分散データ処理システムにおいて、複数のクラスタ・コンピュータ・システムを管理する方法であって、
前記複数のクラスタ・コンピュータ・システム内のあるクラスタ・コンピュータ・システムの再始動の開始を検出するステップであって、前記クラスタ・コンピュータ・システムが選択状態において再始動し、資源を含み、
前記資源が現在、前記複数のクラスタ・コンピュータ・システム内の別のクラスタ・コンピュータ・システム内で動作中であるとの判断に応答して、前記クラスタ・コンピュータ・システムにおける前記資源の再始動を阻止するステップと
を含む、方法。
（４７）前記資源が共用ファイル・システムである、前記（４６）記載の方法。
（４８）複数のクラスタ・コンピュータ・システムを有する分散データ処理システムであって、
前記複数のクラスタ・コンピュータ・システム内のあるクラスタ・コンピュータ・システムの再始動の開始を検出する検出手段であって、前記クラスタ・コンピュータ・システムが選択状態において再始動し、資源を含み、
前記資源が現在、前記複数のクラスタ・コンピュータ・システム内の別のクラスタ・コンピュータ・システム内で動作中であるとの判断に応答して、前記クラスタ・コンピュータ・システムにおける前記資源の再始動を阻止する阻止手段と
を含む、分散データ処理システム。
【図面の簡単な説明】
【図１】本発明が実装され得る分散データ処理システムの絵図である。
【図２】マイクロソフト"Wolfpack"製品及びその制限を示す図である。
【図３】マイクロソフト"Wolfpack"製品及びその制限を示す図である。
【図４】マイクロソフト"Wolfpack"製品及びその制限を示す図である。
【図５】本発明及びＭＳＣＳクラスタなどの複数のクラスタに渡るその実装を示す図である。
【図６】本発明及びＭＳＣＳクラスタなどの複数のクラスタに渡るその実装を示す図である。
【図７】本発明及びＭＳＣＳクラスタなどの複数のクラスタに渡るその実装を示す図である。
【図８】本発明及びＭＳＣＳクラスタなどの複数のクラスタに渡るその実装を示す図である。
【図９】複数のクラスタを制御するために本発明により使用される基礎となる方法のフロー図である。
【図１０】複数のクラスタを制御するために本発明により使用される基礎となる方法のフロー図である。
【図１１】複数のクラスタを制御するために本発明により使用される基礎となる方法のフロー図である。
【図１２】本発明と共に使用される構成、ステータス、及び事象処理規則を含むＳＱＬテーブルを示す図である。
【図１３】本発明と共に使用される構成、ステータス、及び事象処理規則を含むＳＱＬテーブルを示す図である。
【符号の説明】
１１０、１１１、１１２、１１３  サーバ・コンピュータ
１３０、１３１  クライアント・コンピュータ
１２０、１２１、１２２、１２３  ローカル・データ記憶装置
１２４、２０８  共用ディスク記憶装置
２０２、２０４、２１２、３５０  ノード
２１４、３４０  データ記憶装置
２１６  スタンバイ・ノード
３００  ソフトウェア
３０２  クラスタ・マネージャ
３０４  クラスタ・サービス
３０６、３０６ａ  ＭＳＣＳ
３０８  トポロジ・サービス
３１０  グループ・サービス事象アダプタ（ＧＳＥＡ）
３１１  ＧＳＥＡグループ・サービス・グループ
３１２  マイクロソフト・クラスタ・サービス事象アダプタ（ＭＳＣＳＥＡ）
３１４  ＣＳＱＬサービス
３１５  ＣＳＱＬサービス・グループ
３１６  回復サービス
３１８  クラスタＡＰＩ
３６０  ディスク制御装置
３７０  アプリケーション
４５２  ノード故障
５００  テーブル
５０２、５０４  エンティティ
５０６、５０８、５１０、５１２  セクション
６００  ch_resource_groupテーブル
【図１】
0004307673.tif 000002
【図２】
0004307673.tif 000003
【図３】
0004307673.tif 000004
【図４】
0004307673.tif 000005
【図５】
0004307673.tif 000006
【図６】
0004307673.tif 000007
【図７】
0004307673.tif 000008
【図８】
0004307673.tif 000009
【図９】
0004307673.tif 000010
【図１０】
0004307673.tif 000011
【図１１】
0004307673.tif 000012
【図１２】
0004307673.tif 000013
【図１３】
0004307673.tif 000014