(57)【要約】【課題】  スプリット・ブレイン状況を発生させる可能性がある障害に対処できる方法を提供すること。【解決手段】  具体的に言えば、たとえ共用リソースの所有者がスプリット・ブレイン状況の対象となる可能性があっても、共用リソースの安全な管理がサポートされる。さらに本発明は、クラスタの一部のメンバが再構成中に到達できないという事実にもかかわらず、クラスタ構成を更新できるようにするものである。本発明によって課された方針は、開始されたすべてのノードが作業構成として常に最新の構成を使用すること、またはそれが不可能であれば、構成の潜在的な非整合性について管理者に警告することを保証するものである。【選択図】      図９   
2004342079.tif 000002
【特許請求の範囲】
【請求項１】
Ｎ個のノードＳ１からＳＮを有するクラスタを初期化するための方法であって、
クラスタを形成するためにＮ個のノードＳ１からＳＮを選択するステップと、
現在のタイムスタンプを有するクラスタ構成ファイルに前記選択情報を格納するステップであって、これによって前記クラスタ構成ファイルを前記ノードＳ１からＳＮのそれぞれでローカルに使用することができるステップと、
前記ノードＳ１からＳＮのマジョリティが前記クラスタ構成ファイルにアクセス可能であるか否かを検査するステップとを含み、
マジョリティがアクセス可能な場合は、クラスタ・セット・アップが首尾よく実行されたことを伝えるメッセージが生成され、
マジョリティがアクセス可能でない場合は、構成の取消しが試行され、クラスタの構成が不整合であることを伝えるメッセージが生成される方法。
【請求項２】
前記クラスタ構成ファイルに選択情報を格納するステップは、
前記クラスタ構成ファイルをすべてのノードＳ１からＳＮに送るステップをさらに含む、請求項１に記載の方法。
【請求項３】
前記クラスタ構成ファイルに選択情報を格納するステップは、
前記クラスタ構成ファイルをすべてのノードがアクセス可能な分散ファイル・システム上に格納するステップをさらに含む、請求項１に記載の方法。
【請求項４】
複数のノードを有するコンピュータ・クラスタ内でノードを開始するための方法であって、
最新のクラスタ構成ファイルを検索するステップと、
最新のクラスタ構成ファイルが見つかった場合は、前記開始される予定のノードが前記クラスタ構成で定義されたクラスタのメンバであるか否かを判定するステップと、
メンバである場合は、前記ノードを前記クラスタのノードとして前記最新のクラスタ構成で開始するステップと、
最新のクラスタ構成ファイルが見つけられないか、または開始される予定の前記ノードが最新のクラスタ構成の一部ではない場合は、エラー・メッセージを生成するステップとを含む方法。
【請求項５】
前記最新のクラスタ構成ファイルを検索するステップは、
第１に、ローカルにアクセス可能なクラスタ構成ファイルを、作業構成として使用するステップと、
作業構成にリストアップされたすべてのノードに接触し、それらのローカル・クラスタ定義ファイルを要求するステップと、
接触されたノードのうちの１つから受け取ったクラスタ定義ファイルが、作業構成内のものよりも新しいバージョンであった場合、より新しいバージョンが作業構成となり、最後のステップを再度反復することによってこれを実行するステップと、
接触されたノードのうちの１つから受け取ったクラスタ定義ファイルの中に、作業構成内のものよりも新しいバージョンがない場合、前記作業構成が最新の構成となり、前記反復を停止するステップとをさらに含む、請求項４に記載の方法。
【請求項６】
前記接触されたノードのうちいくつがクラスタ定義ファイルを有するかを決定するステップをさらに
作業定義内の前記ノードのうち少なくとも半数がクラスタ定義を有する場合、前記作業定義は最新のクラスタ構成であり、
さもなければ前記最新の定義は未知のままである、請求項５に記載の方法。
【請求項７】
アクティブ・サブクラスタにｊノードのセットを追加するための方法であって、Ｎは構成済みクラスタのサイズであり、ｋはアクティブ・サブクラスタのサイズであって、
２ｋ＜＝Ｎまたはｊ＞２ｋ−Ｎの条件が真であるか否かを判定するステップと、
真であれば、要求されたオペレーションがクラスタ構成の不整合を発生させる原因になることを伝えるエラー・メッセージを生成するステップとを含む方法。
【請求項８】
１つまたは複数のノードが到達できない場合、追加される予定のノードへの接続をチェックするステップをさらに含む、請求項７に記載の方法。
【請求項９】
前記接続チェックの結果に従って、追加される予定のノード・セットを調整するステップをさらに含む、請求項８に記載の方法。
【請求項１０】
クラスタにノードを安全に追加できると判定された後、新しい構成をアクティブ・サブクラスタ内のすべてのノードに伝播するステップをさらに含む、請求項７または９に記載の方法。
【請求項１１】
追加された新しいノードを含む前記新しいクラスタ構成をオフライン・ノードにコピーするステップをさらに含む、請求項１０に記載の方法。
【請求項１２】
首尾よく追加されたノードのリストを戻すステップをさらに含む、請求項１１に記載の方法。
【請求項１３】
クラスタ構成からｊノードのセットを除去するための方法であって、Ｎは構成済みクラスタのサイズであり、ｋはアクティブ・サブクラスタのサイズであって、
２ｋ＜Ｎの条件が真であるか否かを判定するステップと、
真であれば、要求されたオペレーションがクラスタ構成の不整合を発生させる原因になることを伝えるエラー・メッセージを生成するステップとを含む方法。
【請求項１４】
管理者が潜在的なエラー・メッセージを明示的に無視して続行できるようにする、請求項１３に記載の方法。
【請求項１５】
１つまたは複数のノードが到達できない場合、除去される予定のノードへの接続をチェックするステップと、
前記接続チェックの結果に従って、除去される予定のノード・セットを調整するステップをさらに含む、請求項１３または１４に記載の方法。
【請求項１６】
要求されたノードをクラスタから安全に除去できると判定された後、除去される予定のすべてのノードから構成を除去するステップをさらに含む、請求項１４または１５に記載の方法。
【請求項１７】
前記構成を除去するステップが首尾よく実行されず、２ｋ＝Ｎが真の場合、要求されたオペレーションがクラスタ構成の不整合を発生させる原因になることを伝えるエラー・メッセージを生成するステップをさらに含む、請求項１６に記載の方法。
【請求項１８】
管理者が潜在的なエラー・メッセージを明示的に無視して続行できるようにする、請求項１７に記載の方法。
【請求項１９】
除去される予定のノードから構成を除去することができた場合、アクティブ・サブクラスタ内のすべてのノードに新しい構成を伝播するステップをさらに含む、請求項１６から１８のうちのいずれか一項に記載の方法。
【請求項２０】
前記新しいクラスタ構成をオフライン・ノードにコピーするステップをさらに含む、請求項１９に記載の方法。
【請求項２１】
首尾よく除去されたノードのリストを戻すステップをさらに含む、請求項２０に記載の方法。
【請求項２２】
クラスタへの他の構成の更新を導入するための方法であって、Ｎは構成済みクラスタのサイズであり、ｋはアクティブ・サブクラスタのサイズであって、
２ｋ＜＝Ｎが真であるか否かを判定するステップと、
真であれば、要求されたオペレーションがクラスタ構成の不整合を発生させる原因になることをユーザに伝えるエラー・メッセージが生成するステップとを含む方法。
【請求項２３】
要求された構成の更新が安全に導入できる場合、アクティブ・サブクラスタ内のすべてのノードに新しいクラスタ構成を伝播するステップをさらに含む、請求項２２に記載の方法。
【請求項２４】
前記新しいクラスタ構成をオフライン・ノードにコピーするステップをさらに含む、請求項２３に記載の方法。
【請求項２５】
要求されたクラスタ構成の修正が首尾よく適用されたノードのリストを戻すステップをさらに含む、請求項２４に記載の方法。
【請求項２６】
複数のノードおよびタイブレーカを有するクラスタを各ノードに関連付けられた状態を決定することによって操作するための方法であって、Ｎは構成済みクラスタのサイズであり、ｋはアクティブ・サブクラスタのサイズであって、
Ｎおよびｋに関する値を取り出すステップと、
２ｋ＜Ｎの条件が真である場合、
前記ノードが前記タイブレーカを予約したか否かを判定し、予約した場合は前記タイブレーカが解除されるステップと、
前記状態をｎｏ＿ｑｕｏｒｕｍに設定するステップと、
前記ノードがオンラインのクリティカル・リソースを有する場合は、リソース保護方法をトリガするステップとを含む方法。
【請求項２７】
２ｋ＝Ｎの条件が真である場合、
前記状態をｑｕｏｒｕｍ＿ｐｅｎｄｉｎｇに設定するステップと、前記タイブレーカの予約を要求するステップとをさらに含む、請求項２６に記載の方法。
【請求項２８】
前記タイブレーカの予約が首尾よく実行された場合は、ｉｎ＿ｑｕｏｒｕｍに変更するステップをさらに含む、請求項２７に記載の方法。
【請求項２９】
前記タイブレーカの予約が首尾よく実行されなかった場合は、前記状態をｎｏ＿ｑｕｏｒｕｍに変更するステップと、
前記ノードがオンラインのクリティカル・リソースを有する場合は、リソース保護方法をトリガするステップとをさらに含む、請求項２８に記載の方法。
【請求項３０】
２ｋ＞Ｎの条件が真である場合、
前記ノードが前記タイブレーカを予約したか否かを判定し、予約した場合は前記タイブレーカが解除されるステップと、
前記状態をｉｎ＿ｑｕｏｒｕｍに設定するステップとをさらに含む、請求項２９に記載の方法。
【請求項３１】
コンピュータ・クラスタのノード・オペレーション中の誤動作を決定するための方法であって、前記ノードは、１つのデッド・マン・スイッチ（ＤＭＳ）と、少なくとも第１および第２のインフラストラクチャ・レベルを有するものであり、
前記第１のインフラストラクチャ・レベルが、前記第１のインフラストラクチャ・レベルを監視できるように前記ＤＭＳを定期的に更新するステップと、
前記第１のインフラストラクチャ・レベルが前記第２のインフラストラクチャ・レベルを監視するステップと、
前記第１のインフラストラクチャ・レベルが前記第２のインフラストラクチャ・レベルの監視中に誤動作を検出した場合、前記ＤＭＳの更新を中止するステップとを含む方法。
【請求項３２】
前記第２のインフラストラクチャ・レベルでの誤動作の検出は、
前記第１のインフラストラクチャ・レベルから前記第２のインフラストラクチャ・レベルに通知メッセージを送るステップと、
前記第２のインフラストラクチャ・レベルが前記第１のインフラストラクチャ上で機能を呼び出すのを待機するステップと、
前記第１のインフラストラクチャ・レベルが前記第１のインフラストラクチャ・レベルからの機能呼出しを受け取るのに失敗した場合、前記第２のインフラストラクチャ・レベルでの誤動作を宣言するステップとを含む、請求項３１に記載の方法。
【請求項３３】
前記ノードはさらに第３のインフラストラクチャ・レベルを含み、
前記第２のインフラストラクチャ・レベルが前記第３のインフラストラクチャ・レベルを監視するステップと、
前記第２のインフラストラクチャ・レベルが前記第３のインフラストラクチャ・レベルの監視中に誤動作を検出した場合、前記第１のインフラストラクチャ・レベルに通知するステップとをさらに含む、請求項３２に記載の方法。
【請求項３４】
前記方法をクリティカル・リソースがオンラインであるノード上でのみ実行するステップと、
オンラインのクリティカル・リソースがないノード上では前記方法を使用不能にするステップとをさらに含む、請求項３１または３２に記載の方法。
【請求項３５】
請求項１から３４のいずれか一項に従って動作するＮ個のノードＳ１からＳＮを有するコンピュータ・クラスタ。
【請求項３６】
請求項１から３４のいずれか一項に従って方法を実行するように適合されたコンピュータ・システム。
【請求項３７】
コンピュータ使用可能媒体上に格納されたコンピュータ・プログラムであって、請求項１から３４のいずれか一項に従ってコンピュータに方法を実行させるためのコンピュータ読取り可能プログラム手段を含む、コンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般にコンピュータ・クラスタに関する。具体的に言えば、本発明は高いアベイラビリティのクラスタを操作するための方法およびシステムに関する。
【背景技術】
【０００２】
本発明は、ある種の障害状況において、クラスタの構成要素に障害が発生したのかどうか、またはその構成要素への通信リンクに障害が発生したのかどうかを判定することが、不可能ではないが困難であるという事実に対処する、クラスタリング技法に関する。こうした状況は、時に「スプリット・ブレイン状況」と呼ばれるが、これは、こうした障害がクラスタ構成要素の様々なセットがクラスタの仕事を引き継ごうとする状況につながる可能性があるためである。後者の状況は、たとえば複数の構成要素が共用データを所有しようとした場合に、有害となる可能性がある。
【０００３】
この種の問題に対処するために、ロック（予約／解除）保護ディスク上にデータを格納すること、３ノード・クラスタにおいて多数決原理を使用すること、または相互の「shoot the other node in the head」方式など、これまで様々な保護機構が提案されてきた。しかし、これらの解決策はすべて、特殊な適用範囲、特殊なハードウェアの可用性、または特定のクラスタ・トポロジ、固定されたクラスタ構成のいずれかに、強度に制限されている。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
このことを根幹として、本発明の目的は、高いアベイラビリティのコンピュータ・クラスタを安全に操作するための方法およびシステムを提供することである。
【課題を解決するための手段】
【０００５】
上記の目的は、独立した特許請求の範囲に記載された方法およびシステムによって達成される。本発明の他の有利な実施形態は従属項に記載されており、以下の説明で教示される。
【０００６】
本発明は、スプリット・ブレイン状況を発生させる可能性のある障害に対処できるものである。具体的に言えば、たとえ共用リソースの所有者がスプリット・ブレイン状況の対象となる可能性があっても、共用リソースの安全な管理がサポートされる。さらに本発明は、クラスタの一部のメンバが再構成中に到達できないという事実にもかかわらず、クラスタ構成を更新できるようにするものである。本発明によって課された方針は、開始されたすべてのノードが作業構成として常に最新の構成を使用すること、またはそれが不可能であれば、構成の潜在的な非整合性について管理者に警告することを保証するものである。
【０００７】
共用リソースの制御は、接続されたどのサブクラスタがクリティカル・リソースを担当しているかを判定するために、さらに多数決原理（現在のクラスタは定義済みクラスタに対して大多数のノードを有している）を使用する定数に基づいている。互角の状況 (tie situation) では、この決定を得るためにタイブレーカを調べることができる。タイブレーカとは、競争において勝者は多くとも１人だけとする機構（ＨＷサポートによって可能）のことである。定数を有さないサブクラスタの場合、ノードの停止またはリブートを強制することができる、リソース保護機構が提供される。こうしたリソース保護機構は、「クリティカル」であると指定されたリソースを実際に保有しているノード上でのみ使用される。
【０００８】
クラスタの（再）構成に関して、（クラスタへのノードの追加、クラスタからのノードの除去、およびノードの開始などの）一定のオペレーションに、最大数の障害を許容する数値引数が課せられるが、その定義済みノードの半数のみが到達可能であれば、依然としてクラスタを開始することができる。
【０００９】
さらに本発明は、接続が再度確立された後に２つのサブクラスタをマージする必要が生じる可能性のある、一時ネットワーク障害に対処する方法も示す。
【００１０】
本発明の上記ならびに追加の目的、特徴、および利点は、以下の詳細な説明で明らかになろう。
【００１１】
本発明の新しい特徴については、添付の特許請求の範囲に記載される。ただし、本発明それ自体、ならびに好ましい使用方法、他の目的、およびその利点は、添付の図面と共に読んだときに例示的な実施形態の以下の詳細な説明を参照することによって、最も良く理解されるであろう。
【発明を実施するための最良の形態】
【００１２】
図１を参照すると、クラスタ１００を形成するハードウェア構成要素を示す構成図が示されている。クラスタ１００は、１０１から１０５までの５つのノードを含む。１０１から１０５の各ノードは、オペレーティング・システムをホストするコンテナを形成する。こうしたコンテナは、専用ハードウェア、すなわちオペレーティング・システムにつき１つのデータ処理システムによって、または、１つの同じコンピュータ・システム上で複数の独立したオペレーティング・システムを動作させることができる仮想データ処理システムによって、形成することができる。さらに、１０１から１０５の各ノードには、それぞれ２つのネットワーク・アダプタ１１０、１１１、および１１２、１１３、および１１４、１１５、および１１６、１１７、および１１８、１１９が備えられる。１０１から１０５の各ノードの一方のネットワーク・アダプタ１１０、１１２、１１４、１１６、および１１８は、第１のネットワーク１２０に接続され、他方のネットワーク・アダプタ１１１、１１３、１１５、１１７、および１１９は、第２のネットワーク１２２に接続される。
【００１３】
本発明に従ったシステムおよび方法を実施するには、１つのノードにつき１つの各ネットワーク・アダプタおよび１つのネットワークで十分であることが認められる。ただし、本発明の主な目標のうちの１つが高いアベイラビリティであるため、冗長ネットワークが提供される。あるいは、ネットワークは専用の目的を有することが可能であり、たとえば、第１のネットワーク１２０をノード間でサービス・メッセージを交換するために単独で使用し、第２のネットワーク１２２をノードの到達可能性を監視するためのハートビート・ネットワークとして使用することができる。
【００１４】
第１のノード１０１は、第１のノードのローカルなリソース、ここではローカル・ディスク１２４に接続される。これに対して、第５のノード１０５は何らかの通信リンクを介して、ローカル・リソース、すなわちローカル・ディスク１２６に接続される。各ノードがローカル・ディスクを有してもよいことが認められる。
【００１５】
１０１から１０５の５つのノードそれぞれへの通信リンクを有する、１つの共用リソース、ここでは共用ディスク１２８が提供される。共用ディスクは、以下でより詳細に説明するように、クリティカル・リソースを形成することができる。共用リソースは、クラスタ内のすべてのノードのサブセット間でのみ共用可能であることが認められる。
【００１６】
すべてのノードがアクセス可能な通常のオペレーションにおける他の目的は、タイブレーカ１３０である。タイブレーカは、排他的ロック機構を実施するものであり、すなわち、タイブレーカ１３０上では予約および解除オペレーションが実施され、一度に多くても１つのシステムがタイブレーカを予約可能であり、タイブレーカを予約した最後のシステムのみがタイブレーカを首尾よく解除することができる。エラー状況の場合、タイブレーカへのアクセスは、オペレーションのプロービングを介して妥当性を検査することができる。この場合、冗長予約が許可される。タイブレーカは、ＥＣＫＤ  ＤＡＳＤ（ＩＢＭのExtended Count Key Data Direct Access Storage Device／拡張カウント・キー・データ直接アクセス記憶装置）予約／解除、ＳＣＳＩ−２（SmallComputer System Interface／小型コンピュータ・システム・インターフェース）予約／解除、ＳＣＳＩ−３（Small Computer System Interface／小型コンピュータ・システム・インターフェース）永続予約／解除、ＡＰＩ（Application Programming Interface／アプリケーション・プログラミング・インターフェース）またはＣＬＩ（コマンド・ライン・インターフェース）ベース方式、ＳＴＯＮＩＴＨを介した相互「シュートアウト」（ＨＡハートビート・オープン・ソース・プロジェクトからのShoot The Other Node In The Head）として、あるいはテストまたは奇数サイズのクラスタ時にのみ有利に使用可能である常時障害擬似タイブレーカとしても、実施可能である。
【００１７】
図２を参照すると、実際のクラスタ・スプリットに直面しているクラスタ２００の構成図が示されている。クラスタ２００が構成されており、すなわち、クラスタの潜在的なメンバとなるノードのセットを定義することによってオペレーションに備えられており、２０１から２０５までの５つのノードおよび１つのクリティカル・リソース２１０を含む。有害なオペレーション、たとえばデータの整合性を破壊するオペレーションを避けるために同時アクセスを調整する必要がある場合、リソースは「クリティカル」である。図示されたクラスタ２００は、ノード２０１、２０２、および２０３からなる第１のアクティブ・サブクラスタ２１２、ならびに残りのノード２０４および２０５からなる第２のアクティブ・サブクラスタ２１４に分けられる。
【００１８】
初期には、すべてのノードが冗長通信ネットワーク２２０を介して相互に通信可能であった。ただし、提示されたクラスタ２００の例では、冗長ネットワーク２２０は記号２２４によって示されるように誤動作する。その結果、通信はそれぞれ、第１のアクティブ・サブクラスタ２１２の中および第２のアクティブ・サブクラスタ２１４の中でのみ可能となり、第１のアクティブ・サブクラスタ２１２から第２のアクティブ・サブクラスタ２１４へ、またはその逆へは、通信を渡すことができない。
【００１９】
この状況では、クリティカル・リソース２１０に関するデータの整合性を保証することができないため、クリティカル・リソース２１０を所有できるのは、１つのアクティブ・サブクラスタのみである。
【００２０】
次に、同様の厳しい状況について、図３を参照しながら説明する。いわゆる潜在的なクラスタ・スプリットを有するクラスタ３００の構成図が示されている。図１のクラスタ２００に相応して、クラスタ３００が構成されており、すなわち、クラスタの潜在的なメンバとなるノードのセットを定義することによってオペレーションに備えられており、３０１から３０５までの５つのノードおよび１つのクリティカル・リソース３１０を含む。図示されたクラスタ３００は、ノード３０１、３０２、および３０３からなる１つのアクティブ・サブクラスタ３１２のみを獲得している。その結果、冗長通信ネットワーク３２０が立ち上げられて稼動中であっても、アクティブ・サブクラスタ３１２のいずれかのノードと、残りのノード３０４および３０５のうちのいずれかとの間では通信することができない。
【００２１】
アクティブ・サブクラスタの見地からすると、図３に示された潜在的なクラスタ・スプリットと、図２に示された実際のクラスタ・スプリットとは同じに見える、すなわち、ノード３０１から３０３とノード２０１から２０３は、それぞれ、実際のクラスタ・スプリットと潜在的なクラスタ・スプリットとを区別することができない。したがって、実際のクラスタ・スプリット中に実行された、および／または潜在的なクラスタ・スプリット中に実行されたクラスタ構成の変更が、クラスタ構成の非整合性につながる可能性がある。どちらの場合も、１つのアクティブ・サブクラスタのノードのみがクリティカル・リソース３１０へのアクセス権を得ることを保証する必要がある。
【００２２】
図４を参照すると、各ノード４００内で実施されるクラスタのソフトウェア・スタックを示す、詳細な構成図が示されている。前述のようにノードは、
すなわち、たとえばリソース割振り、低レベルのハードウェア・インターフェース、セキュリティなどを担当する、オペレーティング・システムの必須部分である、オペレーティング・システム・カーネル４０２を含む、オペレーティング・システムを実行するためのコンテナを提供する。好ましいことに、オペレーティング・システム（ＯＳ）カーネル４０２には、いわゆるデッド・マン・スイッチ（ＤＭＳ）４０４が備えられている。デッド・マン・スイッチ４０４は、ノードの付添いがなくなると、クリティカル・リソースへの未調整アクセスを避けるためにノードを自動的に停止させる、予防機構である。デッド・マン・スイッチは、たとえばＡＩＸ−ＤＭＳ（ＩＢＭ  Corporation）またはＬｉｎｕｘ  ＳｏｆｔＤｏｇによって実現することができる。
【００２３】
ＯＳカーネル４０２の上には、トポロジ・サービス（ＴＳ）４０６が提供される。トポロジ・サービス４０６は、それらが実行中のノードと他のノードとの間の物理的な接続を監視する。その実行中に、ノードは、何らかの物理通信リンク（図示せず）を介して到達可能なノードに関する情報を集める。ＲＳＣＴトポロジ・サービス（ＩＢＭのReliable Scalable Clustering Technologyトポロジ・サービス）またはＨＡハートビート（オープン・ソースハイアベイラビリティプロジェクト）が、トポロジ・サービスを実施することができる。
【００２４】
次のレイヤは、プロセスの論理クラスタを作成することが可能であり、グループ調整サービスを含む、グループ・サービス（ＧＳ）４０８によって形成される。ＲＳＣＴグループ・サービスは、グループ・サービスの実施を提供する。
【００２５】
１つ上のレイヤには、アダプタ、ファイル・システム、ＩＰアドレス、およびプロセスなどのリソースを制御する、リソース管理サービス（ＲＭＳ）４１０がある。ＲＭＳは、ＲＳＣＴ  ＲＭＣ＆ＲＭｇｒ（ＩＢＭのＲＳＣＴ  Resource Management and Control & Resource Managers）、ＣＩＭ  ＣＩＭＯＮ（Common Information Model）によって形成することができる。
【００２６】
次のレイヤは、アクティブ・ノードのサブクラスタを表し、構成および定数サービスを提供する責務を負う、クラスタ・サービス（ＣＳ）４１２によって形成されるものであり、これについては以下でより詳細に説明する。ＲＳＣＴ  ＣｏｎｆｉｇＲＭ（ＩＢＭのＲＳＣＴ  Configuration Resource Manager）は、クラスタ・サービスの機能を実施する。
【００２７】
これらのレイヤはすべて、実際に、ＧＰＦＳ、Ｌｉｎｕｘ用のＳＡ、Ｌｉｆｅｋｅｅｐｅｒ、Ｆａｉｌｓａｆｅなどの、複数のノードを介して配布される、その上でクラスタ・アプリケーション（ＣＡ）４１４が動作可能な、クラスタ・インフラストラクチャを形成する。
【００２８】
図５を参照すると、第１のノード５０１および第２のノード５０２のソフトウェア・レイヤおよびハードウェア・レイヤ、ならびにそれらの到達可能性および潜在的な障害ポイントを示す構成図が示されている。各ノードには、図４を参照しながら説明したような様々なレイヤ、すなわち、ＤＭＳ  ５０５、５０６を含むＯＳカーネル５０３、５０４、ＴＳレイヤ５０７、５０８、ＧＳレイヤ５０９、５１０、ＲＭＳレイヤ５１１、５１２、ＣＳレイヤ５１３、５１４、およびＣＡレイヤ５１５、５１６が含まれる。各ノード５０１、５０２は、それぞれのネットワーク・アダプタ５２１、５２２に接続され、次にこれらがノード間の物理通信リンク５２５に接続される。
【００２９】
トポロジ・サービス５０７、５０８は、ネットワーク・アダプタ５２１、５２２によって提供される物理通信リンクのオペレーションを監視する。グループ・サービスは、ノードの論理クラスタ（ライン５２６）およびクラスタ・アプリケーションの論理クラスタ（ライン５２７）を確立および監視する。
【００３０】
クラスタのオペレーション中は、ノードの到達可能性障害のいくつかの可能性が存在し、正しい処置を開始するためにすべて検出する必要がある。ＣＡ障害は、ＧＳによって提供された情報に基づいて、異なるノード上のリモートＣＡインスタンスによって観察および処理される。ＣＡ障害は、クラスタ構成内で現在到達可能なノードおよび／または変更に関する情報を必要とする、すべてのローカル・サービスおよびアプリケーションによって観側される。リモート・ノードのＣＳレイヤは、ＧＳによって提供された情報に基づき、これをノード障害として観側する。
【００３１】
ＧＳが障害を起こした場合、すべてのローカルＣＡおよびＣＳがこれを観側することになる。リモートＧＳは、この障害を論理ノード障害として観側する。
【００３２】
ＴＳが障害を起こした場合、ローカルＧＳはこれを致命的なエラーまたはノードの分離として観側することになる。リモートＴＳは、これをノードの到達可能性障害として観側する。ＯＳカーネルの障害が原因でノードが障害を起こした場合、ノードのすべてのネットワーク・アダプタが障害を起こした場合、または２つのノード間のすべてのネットワーク自体が障害を起こした場合にも、同様のことが生じる。観側された障害に関する情報は、ＴＳからＧＳへ、ならびにＧＳからＣＳ、ＲＭＳ、およびＣＡへ、それぞれ伝播されることになる。
【００３３】
図６を参照すると、クラスタ全体にわたるリソース管理サービスの機能を示した、第１のノード６０１および第２のノード６０２の構成図が示されている。各ノードには、図４を参照しながら説明したような様々なレイヤ、すなわちネットワーク・アダプタ６０４、６０４、ＯＳカーネル６０５、６０６、ＴＳレイヤ６０７、６０８、ＧＳレイヤ６０９、６１０、ＲＭＳレイヤ６１１、６１２、ＣＳレイヤ６１３、６１４、およびＣＡレイヤ６１５、６１６が含まれる。各ノード６０１、６０２は、ノード間の物理通信リンクを提供するそれぞれのネットワーク・アダプタ６0３、６０４に接続される。
【００３４】
各ノード上でのリソース管理サービス（ＲＭＳ）６１１、６１２の協働が、第１のノード６０１および第２のノード６０２のＲＭＳ  ６１１、６１２を囲むライン６２０で示されたクラスタ全体にわたるリソース管理サービスを形成する。クラスタ全体にわたるＲＭＳは、ファイル・システム６２５、６２６、ＩＰアドレス６２７、６２８、ユーザ・スペース・プロセス６２９、６３０、およびネットワーク・アダプタ６０３、６０４などの、複数のリソースを、それぞれ矢印で示されるように、管理、すなわち起動、停止、監視する。実際のクラスタの状態および構成とクラスタ全体にわたるリソース管理とを協働させるために、クラスタ全体にわたるＲＭＳは、それぞれ矢印で示されるように、クラスタ・サービスからのクラスタの状態を調べる。クラスタ全体にわたるリソース管理に使用される追加情報は、複数のリソースそれぞれに割り当てられたリソース属性６４０から６４７までから導出される。属性は、リソースが開始される環境、リソースのオペレーション状態、またはリソースがクリティカルであるか否か、に関する情報を提供することができる。
【００３５】
図７を参照すると、構成済みクラスタ７０２のオペレーションを示すコンピュータ・システム７００の構成図が示されている。コンピュータ・システム７００は、７１１から７１７までの７つのノードを含む。すべてのノードは、通信ネットワーク７２０を介して相互に通信することができる。７１１から７１６までの６つのノードは、クラスタの潜在的メンバであるものと定義されるため、これらのノードが構成済みクラスタ７０２を形成する。構成済みクラスタを形成する７１１から７１６までのノードのうちの１つ、すなわちノード７１６は、シャットダウンされたかまたは障害によるどちらかの理由でオフラインとなっている。この状態が原因で、ノード７１６はアクティブ・サブクラスタに加わることができない。
【００３６】
残りのノード７１１から７１５まではオンライン、すなわち立ち上げられて稼動中であり、２つの分離されたアクティブ・サブクラスタ、すなわち第１および第２のアクティブ・サブクラスタ７２４、７２６を形成する。３つのノード、すなわちノード７１１から７１３は第１のアクティブ・サブクラスタ７２４を形成し、２つのノード、すなわちノード７１４および７１５は第２のアクティブ・サブクラスタ７２６を形成する。２つのアクティブ・サブクラスタの分離は、記号７３０によって示されるノード７１３と７１４の間の完全なネットワーク障害が原因となって生じたものである。概して、アクティブ・サブクラスタは、互いに通信可能であり、共通クラスタに属していることを相互に認識している、構成済みクラスタ内のオンライン・ノードのセットによって形成される。
【００３７】
「Ｎ」は、構成済みクラスタのサイズを示すものであり、この場合Ｎ＝６である。「ｋ」は、対象となるアクティブ・サブクラスタのサイズを示すものである。図７では、第１のアクティブ・サブクラスタ７２４のサイズはｋ＝３であり、第２のアクティブ・サブクラスタ７２６のサイズはｋ＝２である。
【００３８】
アクティブ・サブクラスタについて言及する場合、「マジョリティ」、「タイ」、「マイノリティ」というプロパティが定義される。２ｋ＞Ｎが真であればアクティブ・サブクラスタはマジョリティであり、２ｋ＝Ｎが真であればアクティブ・サブクラスタはタイであり、２ｋ＜Ｎが真であればアクティブ・サブクラスタはマイノリティである。図７では、第１のアクティブ・サブクラスタ７２４はタイであり、第２のアクティブ・サブクラスタ７２６はマイノリティである。
【００３９】
クラスタを安全に動作させるために、本発明はいくつかの構成要素を導入しており、これはＣＳ、ＲＭＳ、ＧＳ、および／またはＴＳとして実施可能である。提供された構成要素は、たとえノードまたはネットワークが障害を起こした場合であっても、クラスタを動作させるための安全な方法を実施する。
【００４０】
図８を参照すると、クラスタ構成要素間での情報の流れを示す流れ図が示されている。第１の構成要素８００は、構成定数を決定する。構成定数を使用すると、たとえノードまたはネットワークが障害を起こしても、整合性のある方法でクラスタ構成を更新することができる。好ましいことに、この構成要素はクラスタ・サービスの一部として実施される。
【００４１】
構成要素８０２は、構成定数８００の情報を使用して、構成の更新が許容可能であるかどうかを判定する。他方で構成定数８００は、構成定数を決定するために、１つまたは複数のノードに格納された現在の構成に関する情報が必要である。
【００４２】
構成要素８０２の情報に基づいて、次の構成要素８０４がオペレーション定数を生成する。オペレーション定数は、クリティカル・リソースが実行可能であるか否かを判定する。好ましいことに、この構成要素もクラスタ・サービスの一部として実施される。
【００４３】
クリティカル・リソース・オペレーション構成要素８０６は、クリティカル・リソースを決定し、オペレーション定数に従ってそのオペレーションを制約する。好ましいことに、この構成要素はリソース管理サービスの一部として実施される。クリティカル・リソース保護構成要素８０８は、オペレーション定数が失われた場合にクリティカル・リソースを障害から保護するように構成される。好ましいことに、この構成要素は、それぞれ他のユニットからの情報を必要とする可能性のある、ＣＳ、ＲＭＳ、ＧＳ、およびＴＳのユニットのうちの１つの一部として実施される。
【００４４】
最終的に、オペレーション定数およびクリティカル・リソースを保存しているクラスタをマージおよびスプリットするための方法を実現する、クラスタ・マージ構成要素８１０が提供される。好ましいことに、この構成要素はグループ・サービスの一部である。以上、それぞれの構成要素について簡単な概要を述べたが、次に構成要素の詳細なオペレーションについて説明する。
【００４５】
構成定数構成要素は、たとえ構成済みクラスタのすべてのノードが単一のアクティブ・クラスタまたはサブクラスタを形成するわけではない場合であっても、クラスタ定義の整合性を保つ方法で、クラスタ構成を有利に更新することができる。クラスタ構成は、構成済みクラスタのあらゆるノード上に格納する必要のある、構成済みクラスタ（および任意の属性）の記述である。ファイル内に格納可能なクラスタ構成には、少なくとも、構成済みクラスタに属するすべてのノードのリストおよびこの構成のコピーの最新の更新のタイムスタンプに関する情報が含まれる。
【００４６】
目標を達成するために、構成定数構成要素は、以下のオペレーション、すなわち初期クラスタのセットアップ（構成）、ノードまたはノード・セットの開始、構成済みクラスタへのノードの追加、構成済みクラスタからのノードの除去、および他の構成の更新を実行するように構成されるものであって、これらのオペレーションについて以下で詳細に論じる。クラスタ構成の整合性は、これらのオペレーションのみを使用して（定数の無効化オプションなしで）クラスタ構成の初期化および修正を行う場合に限り、保証することができる。
【００４７】
本発明によれば、クラスタを初期化するために以下の方法が実行される。第１に、クラスタを形成するためにＮ個のノードＳ１からＳＮが選択される。この情報は、現在のタイムスタンプを有するクラスタ構成ファイルに格納される。クラスタ構成ファイルは、ノードＳ１からＳＮのそれぞれでローカルに使用可能である。好ましいことに、クラスタ構成ファイルはすべてのノードＳ１からＳＮに送られ、そこに格納される。あるいはクラスタ構成ファイルは、すべてのノードがアクセス可能な分散／共用ファイル・システム上に格納される。次に、ノードＳ１からＳＮのうちのマジョリティがクラスタ構成ファイルにアクセス可能であるか否かが検査される。マジョリティがアクセス可能であれば、クラスタのユーザまたは管理者に、クラスタのセットアップが首尾よく完了したことを知らせるメッセージが生成される。マジョリティがアクセス可能でなければ、構成の取消しが試行され、クラスタの構成が不整合である可能性のあることをユーザに伝えるメッセージが生成される。
【００４８】
本発明によれば、ノードを開始するために以下の方法が実行される。第１に、最新のクラスタ構成ファイルが検索される。最新のクラスタ構成ファイルが見つかると、開始される予定のノードがクラスタ構成内に定義されたクラスタのメンバであるか否かが判定される。メンバであれば、ノードはそのクラスタのノードとして最新のクラスタ構成で開始される。最新のクラスタ構成ファイルが見つけられないか、または開始される予定のノードが最新のクラスタ構成の一部ではない場合、ノードは開始されずにそれぞれのエラー・メッセージが生成される。
【００４９】
最新のクラスタ構成ファイル検索の第１のステップは、以下で説明するように実行される。第１に、ローカルにアクセス可能なクラスタ構成ファイルが、作業構成として使用され、当面は最新のクラスタ構成ファイルとみなされる。次に、作業構成にリストアップされたすべてのノードが接触され、それらのローカル・クラスタ定義ファイルを要求する。接触されたノードのうちの１つから受け取ったクラスタ定義ファイルが、作業構成内のものよりも新しいバージョンであった場合、より新しいバージョンが作業構成となる。これらのステップは、作業構成がそれ以上変更されなくなるまで繰り返される。その後、接触されたノードのうちいくつが、作業構成と同じ（おそらく旧型の）クラスタ定義ファイルを有するかが決定される。作業定義内のノードのうち少なくとも半数がクラスタ定義を有する場合、作業定義は最新のクラスタ構成であり、さもなければ最新の定義は未知のままである。
【００５０】
本発明によれば、アクティブ・サブクラスタにｊノードのセットを追加するために以下の方法が実行され、ここでＮは構成済みクラスタのサイズであり、ｋはアクティブ・サブクラスタのサイズである。アクティブ・サブクラスタ内のノードがこの方法を実行することが認められる。
【００５１】
ｊノードのセットを構成済みクラスタに追加する要求が発行されると、以下の条件が満たされているか否かが判定される。すなわち、２ｋ＜＝Ｎまたはｊ＞２ｋ−Ｎであれば、要求されたオペレーションがクラスタ構成の不整合を発生させる原因になることをユーザに伝える、エラー・メッセージが生成される。言い換えれば、アクティブ・サブクラスタ内のノード数が構成済みクラスタ内のノード数の半分またはそれより少ない場合、あるいは追加される予定のノード数によって新しいクラスタ内でアクティブ・サブクラスタが少なくともノードの半数を提供しないことになる場合、新しいノードの追加は許可されない。
【００５２】
オプションで、追加される予定のノードへの接続がこの時点でチェックされ、１つまたは複数のノードが到達できない場合、接続チェックの結果に従って、追加される予定のノード・セットを調整することができる。
【００５３】
クラスタにノードを安全に追加できると判定された後、新しい構成は、トランザクション的に、すなわち安全な自動的に調整される方法で、アクティブ・サブクラスタ内のすべてのノードに伝播される。さらに、クラスタ構成の変更についてオペレーション定数に通知される。
【００５４】
次に、追加された新しいノードを含み、新しいクラスタ構成がオフライン・ノード（すなわち、アクティブ・サブクラスタ内にないノード）にコピーされる。最終的に、首尾よく追加されたノードのリストが戻される。
【００５５】
本発明によれば、クラスタ構成からｊノードのセットを除去するために以下の方法が実行され、ここでＮは構成済みクラスタのサイズであり、ｋはアクティブ・サブクラスタのサイズである。アクティブ・サブクラスタ内のノードがこの方法を実行し、除去されるノードはオフラインでなければならないことが認められる。
【００５６】
ｊノードのセットを構成済みクラスタから除去する要求が発行されると、以下の条件が満たされているか否かが判定される。すなわち、２ｋ＜Ｎであれば、要求されたオペレーションがクラスタ構成の不整合を発生させる原因になることをユーザに伝える、エラー・メッセージが生成される。言い換えれば、アクティブ・サブクラスタ内のノード数が構成済みクラスタ内のノード数の半分より少ない場合、ノードの除去は許可されない。
【００５７】
オプションで、除去される予定のノードへの接続がこの時点でチェックされ、１つまたは複数のノードが到達できない場合、接続チェックの結果に従って、除去される予定のノード・セットを調整することができる。
【００５８】
要求されたノードがクラスタから安全に除去できると判定された後、除去される予定のすべてのノードから構成が除去される。このステップが首尾よく実行されず、２ｋ＝Ｎが真の場合、要求されたオペレーションがクラスタ構成の不整合を発生させる原因になることをユーザに伝えるために、エラー・メッセージが戻される。
【００５９】
除去される予定のノードから構成が除去できた場合、新しい構成はアクティブ・サブクラスタ内のすべてのノードにトランザクション的に伝播される。さらに、クラスタ構成の変更についてオペレーション定数に通知される。
【００６０】
次に、新しいクラスタ構成が、クラスタ内に残っているオフライン・ノードにコピーされる。最終的に、首尾よく除去されたノードのリストが戻される。
【００６１】
本発明によれば、他の構成の更新を導入するために以下の方法が実行され、ここでＮは構成済みクラスタのサイズであり、ｋはアクティブ・サブクラスタのサイズである。アクティブ・サブクラスタ内のノードがこの方法を実行することが認められる。
【００６２】
他の構成を更新する要求が発行されると、以下の条件が満たされているか否かが判定される。すなわち、２ｋ＜＝Ｎであれば、要求されたオペレーションがクラスタ構成の不整合を発生させる原因になることをユーザに伝える、エラー・メッセージが生成される。言い換えれば、アクティブ・サブクラスタ内のノード数が構成済みクラスタ内のノード数の半分より少ない場合、他の構成変更の導入は許可されない。
【００６３】
構成の要求された更新が安全に導入できると判定された後、新しいクラスタ構成はアクティブ・サブクラスタ内のすべてのノードにトランザクション的に伝播される。その後、新しいクラスタ構成がオフライン・ノードにコピーされる。最終的に、要求されたクラスタ構成への修正が首尾よく実行されたノードのリストが戻される。
【００６４】
本発明によれば、ノードを除去するための定数が上書き可能であり、ノードを開始するための定数が上書き可能であり、クラスタの管理者は新しいクラスタ定義の提供が可能である。少なくともクラスタの半分が障害を起こしたかまたは到達していない障害状況を解決するために、構成定数の上書きが必要となる場合がある。定数の無効化は、結果としてクラスタ定義の整合性を保つという保証を失うことになる。
【００６５】
次に、オペレーション定数（ＯｐＱｕｏｒｕｍ）構成要素のオペレーションについて、詳細に説明する。一般に、各オンライン・ノードから以下の情報、すなわち構成済みクラスタのサイズＮ、ノードのあるアクティブ・クラスタのサイズｋ、およびノード上でクリティカル・リソースが実行中であるか否か、にアクセスすることができる。したがって、オペレーション定数構成要素は、構成済みクラスタのサイズＮの変更に関する情報、ノードのあるアクティブ・サブクラスタのサイズｋの変更に関する、およびクリティカル・リソースについての変更に関する情報を受け取るように構成される。好ましいことに、グループ・サービスはアクティブ・サブクラスタ内のノードに関する情報を提供し、リソース管理サービスはクリティカル・リソースに関する情報を提供する。
【００６６】
本発明によれば、オペレーション定数構成要素は、以下のサービス、すなわちタイブレーカ（サイズが一様なクラスタ構成にのみ必要）、好ましくはグループ・サービスによって提供されるトランザクション・サポート、およびグループ・リーダシップにアクセスすることができる。グループ・リーダシップは、グループ・リーダを有する各アクティブ・サブクラスタによって特徴付けられ、サブクラスタ構成のいずれかの変更時に再評価されるものであって、好ましくはグループ・サービスによって提供される。
【００６７】
さらに、オペレーション定数構成要素は、ノード上で観察されるオペレーション定数の状態を提供する。状態は、ｉｎ＿ｑｕｏｒｕｍ、ｑｕｏｒｕｍ＿ｐｅｎｄｉｎｇ、およびｎｏ＿ｑｕｏｒｕｍの値のうちの１つであってよい。
【００６８】
本発明によれば、オペレーション定数構成要素は、ノードをオンラインにした直後に状態が決定され、構成済みクラスタが変更されるごとおよびノードのあるアクティブ・サブクラスタが変更されるごとに再評価されるという方法に従って、状態を決定する。初期時には、状態はｎｏ＿ｑｕｏｒｕｍである。第１に、Ｎの値、すなわち構成済みクラスタのサイズ、およびｋ、すなわちアクティブ・サブクラスタのサイズが取り出される。次に、２ｋ＜Ｎ、２ｋ＝Ｎ、または２ｋ＞Ｎの条件のうちのどれが真であるかが判定される。
【００６９】
２ｋ＜Ｎが真の場合、ノードがタイブレーカを予約したか否かが判定され、予約した場合はタイブレーカが解除される。さらに、状態はｎｏ＿ｑｕｏｒｕｍに設定され、ノードがオンラインのクリティカル・リソースを有する場合はリソース保護機能がトリガされる。
【００７０】
条件２ｋ＝Ｎが真の場合、ＯｐＱｕｏｒｕｍ状態はｑｕｏｒｕｍ＿ｐｅｎｄｉｎｇに設定され、タイブレーカの予約が要求される。タイブレーカの予約が首尾よく行われると、次にＯｐＱｕｏｒｕｍ状態はｉｎ＿ｑｕｏｒｕｍに変更され、さもなければ予約が未決定の場合は、上記のＮおよびｋの値を取得するステップを続行するか、あるいはクラスタ構成またはアクティブ・サブクラスタ・サイズの変更によりこの方法が非同期に開始された場合は戻る。
【００７１】
タイブレーカの予約が首尾よく行われない場合、次にＯｐＱｕｏｒｕｍ状態はｎｏ＿ｑｕｏｒｕｍに設定され、ノードがオンラインのクリティカル・リソースを有する場合は、リソース保護機能がトリガされる。ノードがアクティブな（またはオンラインの）クリティカル・リソースを有さない場合、ＯｐＱｕｏｒｕｍ状態はｑｕｏｒｕｍ＿ｐｅｎｄｉｎｇに設定され、ノードはタイブレーカの予約を定期的に試行することになる。
【００７２】
条件２ｋ＞Ｎが真の場合、ノードがタイブレーカを予約したか否かが判定され、予約した場合は、タイブレーカが解除される。さらに、ＯｐＱｕｏｒｕｍ状態はｉｎ＿ｑｕｏｒｕｍに設定される。
【００７３】
ノード開始直後（クラスタに統合される結果として）、およびクラスタ構成またはノードがその一部である現在のサブクラスタのいずれかの変更が生じると必ず、ＯｐＱｕｏｒｕｍを計算するための方法が呼び出されることが認められる。
【００７４】
本発明によれば、タイブレーカは以下の機能、すなわち初期化、ロック、アンロック、およびハートビートを提供するように構成される。
【００７５】
タイブレーカ初期化機能またはタイブレーカ・プロービング機能は、ノード上のタイブレーカを初期化することができる。タイブレーカのロックは、多くとも１つのノードがタイブレーカを首尾よくロック（予約）できる機能を提供する。タイブレーカが永続的である場合、すなわち状態としてロックされているかまたはされていないという事実を維持する場合、ロックを所有しないノードはロックされたタイブレーカをアンロックすることはできない。アンロック・オペレーションは、タイブレーカを首尾よくロックした最後のノードのみがタイブレーカを首尾よくアンロック（解除）できる機能を提供する。ソフトウェア・インターフェースまたはＳＴＯＮＩＴＨベースのタイブレーカなどの非永続的なタイブレーカの場合、このオペレーションは、ＮＯＰ（オペレーションなし）、すなわちエンプティ機能として実施することができる。
【００７６】
ハートビート・タイブレーカ機能は、ＴＢを反復的にロックできるようにするものである。タイブレーカの永続性が保証できない場合、これが有利に実施される。一例として、バスがリセットされた場合、ある種のディスク・ロックが失われる可能性がある。
【００７７】
タイブレーカの初期化、タイブレーカのロック、およびタイブレーカのアンロックの実施は、使用されるタイブレーカの種類に応じて異なる場合がある。好ましいことに、タイブレーカはそれぞれのインスタンスを備えたオブジェクト指向クラスとして実施される。
【００７８】
本発明によれば、タイブレーカの予約は以下の方法に従って実行される。第１に、タイブレーカがすでに初期化されているかどうかが判定される。初期化されている場合、その後のアクションが実行できる。初期化されていない場合、初期化機能が実行される。ノードがｑｕｏｒｕｍ＿ｐｅｎｄｉｎｇの間に構成済みクラスタまたはアクティブ・サブクラスタのサイズが変更されるか、タイブレーカについて競い合っている場合、タイブレーカが未決定であることを伝えるメッセージが戻される。
【００７９】
タイブレーカが初期化され、タイブレーカを予約するように要求しているノードがアクティブ・サブクラスタ内のグループ・リーダである場合、（タイブレーカを事前に解除することにおける障害により）このノードによってタイブレーカが予約されているか否かが判定される。予約されている場合、タイブレーカを解除しようとする潜在的なスレッドを停止する。予約されていない場合、タイブレーカをロックする。いずれの場合も、結果はアクティブ・サブクラスタのすべてのノードに同報通信される。タイブレーカが非永続タイプである場合、ハートビートが開始される。
【００８０】
タイブレーカが初期化され、タイブレーカを予約するように要求しているノードがアクティブ・サブクラスタ内のグループ・リーダでない場合、グループ・リーダの結果を待つ。ノードがｑｕｏｒｕｍ＿ｐｅｎｄｉｎｇの間に構成済みクラスタまたはアクティブ・サブクラスタのサイズが変更されるか、タイブレーカについて競い合っている場合、未決定の、そうでなければグループ・リーダの結果を戻す。
【００８１】
本発明によれば、タイブレーカを解除するために以下の方法が実行される。タイブレーカが非永続タイプである場合、タイブレーカのハートビートを停止する。
【００８２】
次に、それぞれの機能を初期化することによってタイブレーカをアンロックする。タイブレーカのアンロックに障害が発生すると、ノードは、タイブレーカの実行の他のスレッドから非同期でアンロックを反復的に試行することになる。結果は戻される。
【００８３】
本発明によれば、以下の方法で定義されるように、永続的なタイブレーカのハートビートが実行される。第１にタイブレーカがロックされ、事前に定義された時間だけ待機した後、タイブレーカのロックが反復される。これらのステップは、タイブレーカがロックを維持しなければならない限り、実行される。
【００８４】
以上、本発明に従ったノードの環境、構成要素、異なる機構、および状態について説明した。次に、図９を参照しながら、特定ノードのオペレーション定数状態の変更について概説する。単一ノードの様々なオペレーション状態を示す状態図が示されている。状態図は、水平に３つの部分に分割され、点線９０２、９０３で分けられている。状況、すなわちノードが「マジョリティ」、「マイノリティ」を有するかまたは「タイ」であるアクティブ・サブクラスタの一部であるかどうかの事実に応じて、上部（ライン９０２より上）、下部（ライン９０３より下）、または中間部（ライン９０２とライン９０３の間）にそれぞれ対処する必要がある。各状況で、状態ごと（ブロック９０５から９１０）に例示されたように、タイブレーカをロックまたはアンロックすることができる。アクティブ・サブクラスタの一部であるノードがタイである場合、他の状態、すなわち定数保留状態（ブロック９１５）がある。
【００８５】
点線の矢印９２１から９３０は、状況、すなわち「マジョリティ」、「マイノリティ」、または「タイ」が、それぞれのアクティブ・サブクラスタのサイズまたは定義されたクラスタのサイズの変更によって変化したときの、状態の変化を示す。
【００８６】
実線の矢印９３５から９３８は、それぞれのソース状態がアクティブなときにいつでも開始される状態の移行を示すものであり、たとえばノードがタイブレーカをロックし、マジョリティを有するアクティブ・サブクラスタの一部である場合（ブロック９０５）、ノードは即時にタイブレーカを解除する（移行９３５）。タイブレーカがいったんアンロックされると、ターゲット状態９０６に達する。それに対応して、移行９３８で示されるように、状態９０９は状態９１０に変化する。ノードがタイブレーカをロックできるか否かに応じて、定数保留状態９１５から、状態９０７（移行９３６を介する）または状態９０８（移行９３７を介する）のいずれかに達する。
【００８７】
クリティカル・リソースの問題に戻る。一般にリソースは、たとえば、リソースが開始できる場所、オペレーション状況（オンラインまたはオフライン）、およびリソースを開始／停止／監視する方法など、属性を各リソースに関連付けるリソース・マネージャ（ＲＭ）によって管理される。
【００８８】
本発明によれば、ブール属性「ｉｓ＿ｃｒｉｔｉｃａｌ」が各リソースに関連付けられ、リソースがクリティカルの場合は属性がＴｒｕｅであり、リソースがクリティカルでない場合はＦａｌｓｅである。複数の独立したノード（ここで独立とは、ノードが相互に通信できないことを意味する）がどんな障害も発生させることなくリソースをオンラインに維持できる場合、属性「ｉｓ＿ｃｒｉｔｉｃａｌ」はＦａｌｓｅに設定される。その他すべての場合、属性「ｉｓ＿ｃｒｉｔｉｃａｌ」はＴｒｕｅに設定されなければならない。
【００８９】
好ましいことに、属性はＲＭＳ構成要素内で、リソースに応じて特定の値、すなわちＴｒｕｅまたはＦａｌｓｅに事前に設定される。あるいは、リソース・クラスごと、またはリソースごとに構成可能である。デフォルトの値として、ｉｓ＿ｃｒｉｔｉｃａｌ＝ｔｒｕｅを使用することが安全であると認められる。さらに、オンライン・ノードの場合、クリティカル・リソースなしで実行可能でなければならない。好ましいことに、各ノードでは、ＲＭＳ構成要素またはＣＳ構成要素が、属性ｉｓ＿ｃｒｉｔｉｃａｌをＴｒｕｅに設定したノード上でのオンライン・リソースのカウンタの実行を維持する。以下のオペレーション、すなわち、リソースの開始、リソースの停止、属性ｉｓ＿ｃｒｉｔｉｃａｌの変更、およびリソース障害検出は、ｉｓ＿ｃｒｉｔｉｃａｌ属性の影響を受ける。
【００９０】
本発明によれば、オンラインの各ノード上では、オンライン・クリティカル・リソース・カウント（ＯＣＲＣ）が維持される。ＯＣＲＣは、オンラインであり、ｉｓ＿ｃｒｉｔｉｃａｌ属性をＴｒｕｅに設定している、リソースの数をカウントするものであって、それぞれのノード上で実行されている。好ましいことに、ＯＣＲＣはクラスタ・サービス（ＣＳ）の一部として実施される。クラスタ・サービスは、すべてのリソース管理アプリケーションに応答して、具体的に言えばリソース管理サービス（ＲＭＳ）に応答して、ＯＣＲＣを増分および減分するように構成される。さらにＯＣＲＣは、任意の他のクラスタ・ソフトウェア（構成要素）が使用できるものである。
【００９１】
ＯＣＲＣは、以下の方法に従って操作される。ＯＣＲＣが０に下がると必ず、そのノードでのリソース保護は使用不能となり、ＯＣＲＣが正の数（＞＝１）に変わると必ず、そのノードでのリソース保護は使用可能となる。有利なことに、クリティカル・リソースが特定ノード上で実行されているときは必ず、これによってリソース保護が保証される。
【００９２】
本発明によれば、リソースは、以下の条件が真に保たれているときはいつでも、ノードＳ上で開始される。リソースは、属性ｉｓ＿ｃｒｉｔｉｃａｌがＴｒｕｅに設定された場合、ＯｐＱｕｏｒｕｍが「ｑｕｏｒｕｍ＿ｐｅｎｄｉｎｇ」状態に達するまで待機する。ＯｐＱｕｏｒｕｍが「ｎｏ＿ｑｕｏｒｕｍ」に設定された場合、障害（理由：ｎｏ＿ｑｕｏｒｕｍ）に関してユーザに通知するエラー・メッセージが戻される。ノードＳ上でＯＣＲＣが増分されると（上述のように、これでトリガ可能である）、ノードＳ上でリソース開始方法が呼び出される。
【００９３】
それに対応して、ノードＳ上でリソース停止方法が呼び出されると、ノードＳ上のリソースは停止される。リソースの属性ｉｓ＿ｃｒｉｔｉｃａｌがＴｒｕｅに設定されると、Ｓ上でＯＣＲＣが減分される（上述のように、これでリソース保護の使用不能がトリガ可能である）。
【００９４】
ノード上でリソース障害が検出されると、すなわち、リソース監視がノードＳ上でリソース障害を検出すると、リソースの属性ｉｓ＿ｃｒｉｔｉｃａｌがＴｒｕｅに設定されている場合は、ＯＣＲＣが減分され、これによって上述のようにオペレーションをトリガすることができる。
【００９５】
本発明によれば、初期化時およびリソースＲに関するｉｓ＿ｃｒｉｔｉｃａｌの値を変更するたびに、属性ｉｓ＿ｃｒｉｔｉｃａｌ変更方法が呼び出される。（新しい）値が偽である場合、Ｒがオンラインであるアクティブ・サブクラスタ内のすべてのノードで、それらノードそれぞれのオンラインＲの様々なインスタンスによってＯＣＲＣが減分される。（新しい）値が真である場合、すなわち、ＲがオンラインであるすべてのノードのＯｐＱｕｏｒｕｍがｉｎ＿ｑｕｏｒｕｍである場合、それらすべてのノードで、それらノードそれぞれのオンラインＲの様々なインスタンスによってＯＣＲＣが増分され、さもなければ（ｉｎ＿ｑｕｏｒｕｍでないという理由で）障害メッセージが戻される。
【００９６】
明示的なＲＭＳレイヤを使用しないクラスタ・ソフトウェアは、ＲＭＳと同じ方法でリソース開始／停止／障害検出を使用して管理する（クリティカル）リソースを保護することが可能であり、管理されているリソースがクリティカルであるか否かの知識をソフトウェア内でハードコード化することができる。
【００９７】
有利なことに、リソース保護は、ノードが属しているアクティブ・サブクラスタがｎｏ＿ｑｕｏｒｕｍに等しいＯｐＱｕｏｒｕｍを有する場合に、ノード上でオンラインであるクリティカル・リソースがどんな障害も起こさないように保護するものであって、この場合にリソース保護方法が処理される。ノードが「ハング」、すなわち応答しない場合、またはクラスタ・インフラストラクチャが誤動作した場合、以下のようにシステムの自己監視を使用することができる。
【００９８】
リソース保護機構を実施するためには、以下のオペレーションが必要である。その第１がリソース保護トリガである。リソース保護トリガ・オペレーションは、以下の機能のうちの１つであってよい。
システムの異常停止
システムの正常停止
システムの再起動（正常停止後）
システムの再起動（異常停止後）
実行せず（すなわちリソース保護を他の構成要素に任せる）
リソース保護をトリガするために上記機能のうちのいずれを実際に使用するかは、管理者が構成することができる。好ましくは、製品システムでは「異常停止のトリガ」または「異常停止後のシステムの再起動」が使用されるはずであり、テスト目的には他の方法が使用できる。第２に、ＤＭＳを活動化することによって、リソース保護を使用可能にするオペレーションがある。第３に、ＤＭＳを非活動化することによって、リソース保護を使用不能にするオペレーションがある。
【００９９】
図１０を参照すると、システムの自己監視の依存性を示す流れ図が示されている。本発明によれば、各ノード上にある１つのデッド・マン・スイッチ１０００（ＤＭＳ）が、そのノードのクラスタ・インフラストラクチャ全体を監視する。クラスタ・インフラストラクチャ・レベル１（ブロック１００２）は、ＤＭＳ  １０００を直接更新する。アクティブＤＭＳは、定期的にタイマを更新する必要があり、そうでなければカーネル・オペレーションを停止する。提示された概念に従って、監視された結果は高レベルのクラスタ・インフラストラクチャから低レベルのそれへと伝播される。言い換えれば、クラスタ・インフラストラクチャ・レベル１（ブロック１００２）はクラスタ・インフラストラクチャ・レベル２（ブロック１００４）の健全性を監視し、クラスタ・インフラストラクチャ・レベル２（ブロック１００４）はクラスタ・インフラストラクチャ・レベル３（ブロック１００６）の健全性を監視する。通常、クラスタ・インフラストラクチャ・レベル１はトポロジ・サービス（ＴＳ）となり、レベル２はグループ・サービス（ＧＳ）を提供し、レベル３はクラスタ・サービス（ＣＳ）を提供する。この概念は３つのクラスタ・インフラストラクチャ・レベルに限定されるものでないことが認められる。このスタック監視方式は、単一のアプリケーション（クライアント）のみを監視することのできるＤＭＳ実施の使用を可能にするものである。したがって、任意のレベルからのクラスタ・インフラストラクチャ構成要素に欠陥があるかまたはハングすると、信号の伝播を監視できなくなるため、ＤＭＳをトリガし、これがカーネル・オペレーションを停止することになる。
【０１００】
トポロジ・サービス構成要素（ＴＳ）は、ＤＭＳに直接アクセスするレイヤである。トポロジ・サービス構成要素に遮断または障害が生じると、結果としてカーネル・タイマがトリガされ、ノードは停止する。グループ・サービス構成要素（ＧＳ）はＤＭＳに直接アクセスしないが、その代わりに、それ自体をトポロジ・サービス構成要素に監視させるように設定する。すでにトポロジ・サービス構成要素のクライアント・プログラムであるグループ・サービス構成要素は、所与のトポロジ・サービス構成要素のクライアント機能を呼び出すことによって、トポロジ・サービス構成要素によって監視される。グループ・サービス構成要素がタイムリーにクライアント機能を呼び出せなかった場合、トポロジ・サービス構成要素の内部タイマを満了させることができる。トポロジ・サービス構成要素が実行するアクションは、特定のリソース保護方法に基づいてノード上でのクラスタの実行を終了することである。グループ・サービス構成要素には、トポロジ・サービス構成要素によって渡されたノード・イベントを処理する間の厳しいリアルタイム要件のみがあるため、グループ・サービス構成要素は、トポロジ・サービス構成要素からノード・イベントを獲得した後に、タイムリーな方法で新しい機能を呼び出すだけでよい。
【０１０１】
したがってトポロジ・サービス構成要素の内部タイマは、トポロジ・サービス構成要素が任意のノード到達可能性イベントをグループ・サービス構成要素に送信する直前にのみ設定される。後者は、ノード到達可能性イベントがその処理を完了するとすぐに、新しいクライアント機能を呼び出すことによって、イベントに反応する必要がある。
【０１０２】
クラスタ・サービス構成要素はグループ・サービス構成要素のクライアントであり、グループ・サービス構成要素は、クラスタ・サービス構成要素のピア・デーモンがデータを交換し、回復アクションを調整できるようにするための、グループ調整サポートを提供する。グループ・サービス構成要素は、クラスタ・サービス構成要素の遮断／終了に関する監視にも使用される。終了は、グループ・サービス構成要素とそのクライアント・プログラムとの間の通信に使用される、Ｕｎｉｘ−Ｄｏｍａｉｎソケットを監視することによって検出される。遮断は、グループ・サービス構成要素のクライアント・ライブラリにクラスタ・サービス構成要素内のコールバック機能を呼び出させる、「応答性チェック」機構によって検出される。コールバック機能がタイムリーな方法で戻れない場合、その結果としてグループ・サービス構成要素のデーモンは、クラスタ・サービス構成要素内の遮断を検出する。どちらの場合も、グループ・サービス構成要素は終了によって反応し、その結果、トポロジ・サービス構成要素がリソース保護方法を呼び出すことになる。
【０１０３】
前述の監視チェーンは、有利なことに、任意の基礎となるサブシステムが遮断されるかまたは障害を起こした場合、リソース保護方法が適用され、これによってクリティカル・リソースが解除されることを保証するものである。
【０１０４】
次に、図１１から図１５を参照しながら、本発明に従ったクラスタのオペレーションについて説明する。すべての図は、１１０５から１１０９までの５つのノードおよびネットワーク１１１０を含む、同じ構成済みクラスタ１１０２を示している。ただし、アクティブ・サブクラスタおよびそれらのオペレーション・モードは図によって異なる。
【０１０５】
図１１を参照すると、ノード１１０７と１１０８との間でネットワーク１１１０が破損したことによるクラスタ・スプリット状況を有する、構成済みクラスタ１１０２の構成図が示されている。ネットワーク・スプリットは、ノード１１０５から１１０７までを含む第１のアクティブ・サブクラスタ１１１６と、ノード１１０８および１１０９を含む第２のアクティブ・サブクラスタ１１１８を作成する。
【０１０６】
図１２を参照すると、ノード１１０７と１１０８の間の接続が再確立された構成済みクラスタ１１０２の構成図が示されている。ただし、依然として２つのアクティブ・クラスタ１１１６および１１１８がある。本発明によれば、第１に、２つのアクティブ・サブクラスタのうちの１つが、マージが開始される前に分解される。２つのアクティブ・サブクラスタのうちのどちらを分解するかは、以下の規則セットに従って決定される。
・タイブレーカを有するマジョリティまたはタイとなることにより、１つのサブクラスタのみがＯｐＱｕｏｒｕｍを有する場合、定数を持たないサブクラスタを分解する
・サブクラスタ定義が異なる場合、古いクラスタ定義を有するサブクラスタを分解する
・１つのサブクラスタのみがクリティカル・リソースを実行する場合、クリティカル・リソースを実行しないサブクラスタを分解する
・サブクラスタのサイズが異なる場合、小さい方のサブクラスタを分解する
さもなければ
・ 任意の（たとえば最も小さなオンライン・ノード番号を有するもの）サブクラスタを分解する
上記規則は、優先順位の高いものから低いものへと順に並べられている。
【０１０７】
図１３を見るとわかるように、第２のアクティブ・サブクラスタを分解するように選択された。マージ段階１、すなわち１つのサブクラスタを分解する段階にあるクラスタの構成図が示されている。ここでは、初期の第１のアクティブ・サブクラスタ１１１６と、それぞれノード１１０８および１１０９を含む２つの新しいアクティブ・サブクラスタ１１２０および１１２２がある。
【０１０８】
次に図１４を参照すると、マージ段階２、すなわち第１のノード接合段階にあるクラスタの構成図が示されている。分解されたクラスタのノードが、分解されていないアクティブ・サブクラスタのクラスタ構成を採用しながら、分解されていないクラスタに１つずつ接合する。これで、第１のアクティブ・サブクラスタ１１１６はノード１１０５から１１０８までを含むことになる。
【０１０９】
図１５を参照すると、マージ段階３、すなわちアクティブ・サブクラスタ１１２２を形成している第２のノードが第１のアクティブ・サブクラスタ１１１６に接合する段階にある、クラスタの構成図が示されている。最終的に、第１のアクティブ・サブクラスタ１１１６は、ノード１１０５から１１０９までを含むことになる。
【０１１０】
図１６〜図２０を参照すると、構成定数の例を示した構成図が示されている。図１６は、４つのノード１２０１から１２０４がネットワーク１２０６を介して接続されている状況を示す図である。ｔ０の時点で、ネットワークは正常であり、ノード１２０１および１２０２がアップ、ノード１２０３および１２０４はダウンである。定義Ｃｔ０を使用してクラスタが構成されている。Ｃｔ０にはノード１２０１および１２０２が含まれる。したがって、ノード１２０１および１２０２がクラスタ１２０８を構築する。
【０１１１】
ｔ１の時点で、ノード１２０３および１２０４がクラスタに追加される。ｔ２の時点で、ノードの追加は、ノード１２０１および１２０２のクラスタ定義がノード１２０１から１２０４を含むＣｔ２に更新された地点に達する。ｔ３の時点で、ネットワーク障害がノード１２０４を残りのクラスタから分離させる。
【０１１２】
図１６には、ｔ４の時点での状況も示されている。ノード追加オペレーションがいったん完了すると、ノード１２０１から１２０３がアップであり、クラスタを形成する。ノード１２０１から１２０３はそれぞれ、クラスタ定義Ｃｔ２を有する。ノードＳ４はダウンであり、クラスタ定義を持たない。
【０１１３】
図１７は、４つの異なる時点ｔ０、ｔ２、ｔ５、およびｔ６での２つのノード１２１１および１２１２を示す図である。ｔ０の時点では、それぞれの構成ｃｔ０には単一のノード１２１１を含み、クラスタ１２１５を形成している。ｔ１の時点でノード１２１２がクラスタに追加され、図１７のｔ２に示されるように、ノード１２１１および１２１２を含む新しいクラスタ定義ｃｔ１が各ノードに提示されている。
【０１１４】
その後、ｔ３の時点で、ノード１２１１は停止される。次にｔ４の時点で、ネットワーク１２１８にネットワーク障害が発生する。ここでノード１２１１および１２１１はどちらもダウンとなるが、図１７のｔ５に示されるように、どちらのノードのクラスタ構成も最新である。ｔ６の時点で、ノード１２１２が開始される。
【０１１５】
図１８は、２つの異なる時点ｔ４およびｔ６での、６つのノード１２３１から１２３６を示す図である。すべてのノードはネットワーク１２３８に接続され、このネットワークはノード１２３４と１２３５の間でネットワーク障害を経験する。ノード１２３１は前の時点ｔ１で最新であった構成ｃｔ０を取得、ノード１２３３から１２３５はｔ２の時点で最新であった構成ｃｔ２を取得、さらにノード１２３６はｔ１の時点で最新であった構成ｃｔ１を取得している。
【０１１６】
構成ｃｔ０はノード１２３１および１２３３から１２３６を含み、構成ｃｔ１はノード１２３１から１２３６を含み、実際の、すなわち最も新しい構成ｃｔ２はノード１２３１から１２３５を含む。
【０１１７】
ｔ５の時点でクラスタが開始され、図１８のｔ６に示されるようにすべての到達可能ノード１２３１〜１２３４が正しい構成を有する。
【０１１８】
図１９は、異なるノードが異なるクラスタ定義を有することになるためのイベントを示す図である。４つのノード１２４１から１２４４はネットワーク１２４５を介して接続される。ｔ０の時点で、ノード１２４１から１２４４で構成されたクラスタが定義される。一致したクラスタ定義Ｃｔ０がノード１２４１から１２４４に格納される。ノード１２４１から１２４３がアップ、ノード１２４４はダウンである。ネットワーク障害により、ノード１２４４はクラスタの残りのノードから分離される。ｔ１の時点で、ノード１２４１が停止される。ｔ２の時点で、ノード１２４１はクラスタから首尾よく除去され、これによってｔ３の時点で以下の状況が発生する。ノード１２４１はクラスタ定義を持たない。ノード１２４２、１２４３は、ノード１２４２から１２４４で構成される新しいクラスタ定義Ｃｔ２を有する。ノード１２４４は依然としてクラスタ定義Ｃｔ０を有する。ｔ４の時点で、クラスタ全体が停止される。ｔ５の時点でネットワークが修復され、ｔ６の時点ですべてのノードがダウンとなり、ノード１２４１は定義を有さず、ノード１２４２、１２４３は定義Ｃｔ２を有し、ノード１２４４は定義Ｃｔ０を有することになる。
【０１１９】
ｔ６の後、ノードが接続されれば、以下のサブクラスタを開始することができる。
｛１２４２、１２４３｝または
｛１２４２、１２４４｝または
｛１２４３、１２４４｝または
｛１２４２、１２４３、１２４４｝
開始されたすべてのノードは、構成Ｃｔ２を使用することになる。１２４１が開始されることは決してない。
【０１２０】
図２０は、図１９の例を延長したものである。ｔ７の時点で、１２４１および１２４２と１２４３および１２４４とを分離するネットワーク・エラーが発生する。ｔ８の時点でクラスタが開始される。その結果、ｔ９の時点に示された状況が発生し、１２４３および１２４４はアップである。１２４３および１２４４は、どちらも定義Ｃｔ２を有する。１２４１および１２４２はダウンである。１２４２は定義Ｃｔ２を有する。１２４１は定義を有さない。
【０１２１】
図２１〜図２３を参照すると、クリティカル・リソースを備えた２ノード・クラスタに関するオペレーション定数の例を示す構成図が示されている。２ノード・クラスタ１３００は、ネットワーク１３０５によって接続された２つのノード１３０１および１３０２からなる。ノード１３０１および１３０２は、タイブレーカ１３０７（！）およびクリティカル・リソースＣＲへのアクセスを有する。
【０１２２】
図２１は、ノード１３０１および１３０２がどちらもダウンであり、これらのノード間のネットワークが破壊されている、初期の状況を示す図である。図２２は、クラスタを開始した後の状況を示しており、１３０１はオンライン（タイの状況）であって、タイブレーカを予約しており、ＣＲにアクセスすることができる。したがって、１３０１のみで構成されるサブクラスタは、オペレーション定数状態ｉｎ＿ｑｕｏｒｕｍを有する。ノード１３０２はダウンである。
【０１２３】
図２３は、１３０２がクラスタ定義を有する場合の、ノード１３０２を開始した後の状況を示す図であり、１３０２はオンラインであるがタイブレーカの予約には失敗した。ノード１３０２はＣＲにアクセスできない。ノード１３０２のみで構成されるサブクラスタは、オペレーション定数状態ｎｏ＿ｑｕｏｒｕｍを有する。
【０１２４】
図２４〜図２６を参照すると、クリティカル・リソースを備えた５ノード・クラスタに関するオペレーション定数の例を示す構成図が示されている。ノード１４０１から１４０５は、ネットワークによって接続される。ノード１４０１から１４０５は、構成済みクラスタを形成する。ノード１４０２および１４０３はクリティカル・リソースＣＲ１への潜在的アクセスを有する。ノード１４０３から１４０５は、他のクリティカル・リソースＣＲ２への潜在的アクセスを有する。
【０１２５】
図２４は、ノード１４０１から１４０５がアップであって、オペレーション定数状態ｉｎ＿ｑｕｏｒｕｍのアクティブ・サブクラスタを形成する、初期の状況を示す図である。ノード１４０２はＣＲ１にアクセスし（実線）、１４０４はＣＲ２にアクセスする（実線）。
【０１２６】
図２５は、ノード１４０１から１４０３と１４０４から１４０５とを分離する、ネットワーク障害後の状況を示す図である。ここでノード１４０１から１４０３は１つのアクティブ・サブクラスタを形成し、ノード１４０４および１４０５は他のアクティブ・サブクラスタを形成するものであって、どちらのアクティブ・サブクラスタのオペレーション定数状態も再計算する必要がある。
【０１２７】
図２６は、オペレーション定数の決定結果を示す図である。ノード１４０１から１４０３で構成されるアクティブ・サブクラスタは、状態ｉｎ＿ｑｕｏｒｕｍを有する。ノード１４０２はＣＲ１へのアクセスを続行する。ノード１４０４および１４０５で構成されるサブクラスタは、ｎｏ＿ｑｕｏｒｕｍを有する。スプリット以前に、１４０４はオンラインでＣＲ２を有していたため、１４０４は停止される。ノード１４０５は、オンラインのクリティカル・リソースを有さないため、実行を継続することができる。
【０１２８】
この状況の後、ノード１４０３は（たとえば、ノード１４０４の仕事を引き継ぐために）ＣＲ２にアクセスできるが、ノード１４０５はＣＲ２にアクセスできない。
【０１２９】
本発明は、ハードウェア、ソフトウェア、またはハードウェアとソフトウェアの組合せで実現可能である。どんな種類のコンピュータ・システム、または本明細書に記載された方法を実施するように適合された他の装置でも好適である。ハードウェアとソフトウェアの典型的な組合せは、ロードされ実行されたときに本明細書に記載された方法を実行するようにコンピュータ・システムを制御するコンピュータ・プログラムを備えた、汎用コンピュータ・システムであってよい。本発明は、本明細書に記載された方法の実施を可能にするすべての機能を含み、コンピュータ・システムにロードされたときにこれらの方法を実施することのできる、コンピュータ・プログラム製品に組み込むことも可能である。
【０１３０】
本コンテキストでのコンピュータ・プログラム手段またはコンピュータ・プログラムとは、直接、あるいはａ）他の言語、コード、または表記法への変換、およびｂ）異なる材料形式での再作成のいずれかまたは両方の後に、情報処理機能を有するシステムに特定の機能を実行させることを意図した、任意の言語、コード、または表記法での命令セットの任意の表現式を意味するものである。
【０１３１】
まとめとして、本発明の構成に関して以下の事項を開示する。
【０１３２】
（１）Ｎ個のノードＳ１からＳＮを有するクラスタを初期化するための方法であって、
クラスタを形成するためにＮ個のノードＳ１からＳＮを選択するステップと、
現在のタイムスタンプを有するクラスタ構成ファイルに前記選択情報を格納するステップであって、これによって前記クラスタ構成ファイルを前記ノードＳ１からＳＮのそれぞれでローカルに使用することができるステップと、
前記ノードＳ１からＳＮのマジョリティが前記クラスタ構成ファイルにアクセス可能であるか否かを検査するステップとを含み、
マジョリティがアクセス可能な場合は、クラスタ・セット・アップが首尾よく実行されたことを伝えるメッセージが生成され、
マジョリティがアクセス可能でない場合は、構成の取消しが試行され、クラスタの構成が不整合であることを伝えるメッセージが生成される方法。
（２）前記クラスタ構成ファイルに選択情報を格納するステップは、
前記クラスタ構成ファイルをすべてのノードＳ１からＳＮに送るステップをさらに含む、請求項１に記載の方法。
（３）前記クラスタ構成ファイルに選択情報を格納するステップは、
前記クラスタ構成ファイルをすべてのノードがアクセス可能な分散ファイル・システム上に格納するステップをさらに含む、請求項１に記載の方法。
（４）複数のノードを有するコンピュータ・クラスタ内でノードを開始するための方法であって、
最新のクラスタ構成ファイルを検索するステップと、
最新のクラスタ構成ファイルが見つかった場合は、前記開始される予定のノードが前記クラスタ構成で定義されたクラスタのメンバであるか否かを判定するステップと、
メンバである場合は、前記ノードを前記クラスタのノードとして前記最新のクラスタ構成で開始するステップと、
最新のクラスタ構成ファイルが見つけられないか、または開始される予定の前記ノードが最新のクラスタ構成の一部ではない場合は、エラー・メッセージを生成するステップとを含む方法。
（５）前記最新のクラスタ構成ファイルを検索するステップは、
第１に、ローカルにアクセス可能なクラスタ構成ファイルを、作業構成として使用するステップと、
作業構成にリストアップされたすべてのノードに接触し、それらのローカル・クラスタ定義ファイルを要求するステップと、
接触されたノードのうちの１つから受け取ったクラスタ定義ファイルが、作業構成内のものよりも新しいバージョンであった場合、より新しいバージョンが作業構成となり、最後のステップを再度反復することによってこれを実行するステップと、
接触されたノードのうちの１つから受け取ったクラスタ定義ファイルの中に、作業構成内のものよりも新しいバージョンがない場合、前記作業構成が最新の構成となり、前記反復を停止するステップとをさらに含む、請求項４に記載の方法。
（６）前記接触されたノードのうちいくつがクラスタ定義ファイルを有するかを決定するステップをさらに
作業定義内の前記ノードのうち少なくとも半数がクラスタ定義を有する場合、前記作業定義は最新のクラスタ構成であり、
さもなければ前記最新の定義は未知のままである、請求項５に記載の方法。
（７）アクティブ・サブクラスタにｊノードのセットを追加するための方法であって、Ｎは構成済みクラスタのサイズであり、ｋはアクティブ・サブクラスタのサイズであって、
２ｋ＜＝Ｎまたはｊ＞２ｋ−Ｎの条件が真であるか否かを判定するステップと、
真であれば、要求されたオペレーションがクラスタ構成の不整合を発生させる原因になることを伝えるエラー・メッセージを生成するステップとを含む方法。
（８）１つまたは複数のノードが到達できない場合、追加される予定のノードへの接続をチェックするステップをさらに含む、請求項７に記載の方法。
（９）前記接続チェックの結果に従って、追加される予定のノード・セットを調整するステップをさらに含む、請求項８に記載の方法。
（１０）クラスタにノードを安全に追加できると判定された後、新しい構成をアクティブ・サブクラスタ内のすべてのノードに伝播するステップをさらに含む、請求項７または９に記載の方法。
（１１）追加された新しいノードを含む前記新しいクラスタ構成をオフライン・ノードにコピーするステップをさらに含む、請求項１０に記載の方法。
（１２）首尾よく追加されたノードのリストを戻すステップをさらに含む、請求項１１に記載の方法。
（１３）クラスタ構成からｊノードのセットを除去するための方法であって、Ｎは構成済みクラスタのサイズであり、ｋはアクティブ・サブクラスタのサイズであって、
２ｋ＜Ｎの条件が真であるか否かを判定するステップと、
真であれば、要求されたオペレーションがクラスタ構成の不整合を発生させる原因になることを伝えるエラー・メッセージを生成するステップとを含む方法。
（１４）管理者が潜在的なエラー・メッセージを明示的に無視して続行できるようにする、請求項１３に記載の方法。
（１５）１つまたは複数のノードが到達できない場合、除去される予定のノードへの接続をチェックするステップと、
前記接続チェックの結果に従って、除去される予定のノード・セットを調整するステップをさらに含む、請求項１３または１４に記載の方法。
（１６）要求されたノードをクラスタから安全に除去できると判定された後、除去される予定のすべてのノードから構成を除去するステップをさらに含む、請求項１４または１５に記載の方法。
（１７）前記構成を除去するステップが首尾よく実行されず、２ｋ＝Ｎが真の場合、要求されたオペレーションがクラスタ構成の不整合を発生させる原因になることを伝えるエラー・メッセージを生成するステップをさらに含む、請求項１６に記載の方法。
（１８）管理者が潜在的なエラー・メッセージを明示的に無視して続行できるようにする、請求項１７に記載の方法。
（１９）除去される予定のノードから構成を除去することができた場合、アクティブ・サブクラスタ内のすべてのノードに新しい構成を伝播するステップをさらに含む、請求項１６から１８のうちのいずれか一項に記載の方法。
（２０）前記新しいクラスタ構成をオフライン・ノードにコピーするステップをさらに含む、請求項１９に記載の方法。
（２１）首尾よく除去されたノードのリストを戻すステップをさらに含む、請求項２０に記載の方法。
（２２）クラスタへの他の構成の更新を導入するための方法であって、Ｎは構成済みクラスタのサイズであり、ｋはアクティブ・サブクラスタのサイズであって、
２ｋ＜＝Ｎが真であるか否かを判定するステップと、
真であれば、要求されたオペレーションがクラスタ構成の不整合を発生させる原因になることをユーザに伝えるエラー・メッセージが生成するステップとを含む方法。
（２３）要求された構成の更新が安全に導入できる場合、アクティブ・サブクラスタ内のすべてのノードに新しいクラスタ構成を伝播するステップをさらに含む、請求項２２に記載の方法。
（２４）前記新しいクラスタ構成をオフライン・ノードにコピーするステップをさらに含む、請求項２３に記載の方法。
（２５）要求されたクラスタ構成の修正が首尾よく適用されたノードのリストを戻すステップをさらに含む、請求項２４に記載の方法。
（２６）複数のノードおよびタイブレーカを有するクラスタを各ノードに関連付けられた状態を決定することによって操作するための方法であって、Ｎは構成済みクラスタのサイズであり、ｋはアクティブ・サブクラスタのサイズであって、
Ｎおよびｋに関する値を取り出すステップと、
２ｋ＜Ｎの条件が真である場合、
前記ノードが前記タイブレーカを予約したか否かを判定し、予約した場合は前記タイブレーカが解除されるステップと、
前記状態をｎｏ＿ｑｕｏｒｕｍに設定するステップと、
前記ノードがオンラインのクリティカル・リソースを有する場合は、リソース保護方法をトリガするステップとを含む方法。
（２７）２ｋ＝Ｎの条件が真である場合、
前記状態をｑｕｏｒｕｍ＿ｐｅｎｄｉｎｇに設定するステップと、前記タイブレーカの予約を要求するステップとをさらに含む、請求項２６に記載の方法。
（２８）前記タイブレーカの予約が首尾よく実行された場合は、ｉｎ＿ｑｕｏｒｕｍに変更するステップをさらに含む、請求項２７に記載の方法。
（２９）前記タイブレーカの予約が首尾よく実行されなかった場合は、前記状態をｎｏ＿ｑｕｏｒｕｍに変更するステップと、
前記ノードがオンラインのクリティカル・リソースを有する場合は、リソース保護方法をトリガするステップとをさらに含む、請求項２８に記載の方法。
（３０）２ｋ＞Ｎの条件が真である場合、
前記ノードが前記タイブレーカを予約したか否かを判定し、予約した場合は前記タイブレーカが解除されるステップと、
前記状態をｉｎ＿ｑｕｏｒｕｍに設定するステップとをさらに含む、請求項２９に記載の方法。
（３１）コンピュータ・クラスタのノード・オペレーション中の誤動作を決定するための方法であって、前記ノードは、１つのデッド・マン・スイッチ（ＤＭＳ）と、少なくとも第１および第２のインフラストラクチャ・レベルを有するものであり、
前記第１のインフラストラクチャ・レベルが、前記第１のインフラストラクチャ・レベルを監視できるように前記ＤＭＳを定期的に更新するステップと、
前記第１のインフラストラクチャ・レベルが前記第２のインフラストラクチャ・レベルを監視するステップと、
前記第１のインフラストラクチャ・レベルが前記第２のインフラストラクチャ・レベルの監視中に誤動作を検出した場合、前記ＤＭＳの更新を中止するステップとを含む方法。
（３２）前記第２のインフラストラクチャ・レベルでの誤動作の検出は、
前記第１のインフラストラクチャ・レベルから前記第２のインフラストラクチャ・レベルに通知メッセージを送るステップと、
前記第２のインフラストラクチャ・レベルが前記第１のインフラストラクチャ上で機能を呼び出すのを待機するステップと、
前記第１のインフラストラクチャ・レベルが前記第１のインフラストラクチャ・レベルからの機能呼出しを受け取るのに失敗した場合、前記第２のインフラストラクチャ・レベルでの誤動作を宣言するステップとを含む、請求項３１に記載の方法。
（３３）前記ノードはさらに第３のインフラストラクチャ・レベルを含み、
前記第２のインフラストラクチャ・レベルが前記第３のインフラストラクチャ・レベルを監視するステップと、
前記第２のインフラストラクチャ・レベルが前記第３のインフラストラクチャ・レベルの監視中に誤動作を検出した場合、前記第１のインフラストラクチャ・レベルに通知するステップとをさらに含む、請求項３２に記載の方法。
（３４）前記方法をクリティカル・リソースがオンラインであるノード上でのみ実行するステップと、
オンラインのクリティカル・リソースがないノード上では前記方法を使用不能にするステップとをさらに含む、請求項３１または３２に記載の方法。
（３５）請求項１から３４のいずれか一項に従って動作するＮ個のノードＳ１からＳＮを有するコンピュータ・クラスタ。
（３６）請求項１から３４のいずれか一項に従って方法を実行するように適合されたコンピュータ・システム。
（３７）コンピュータ使用可能媒体上に格納されたコンピュータ・プログラムであって、請求項１から３４のいずれか一項に従ってコンピュータに方法を実行させるためのコンピュータ読取り可能プログラム手段を含む、コンピュータ・プログラム。
【図面の簡単な説明】
【０１３３】
【図１】クラスタを形成するハードウェア構成要素を示す構成図である。
【図２】実際のクラスタ・スプリットを経験しているクラスタを示す構成図である。
【図３】潜在的なクラスタ・スプリットを有するクラスタを示す構成図である。
【図４】各ノードで実施されるクラスタのソフトウェア・スタックを示す、詳細な構成図である。
【図５】第１ノードおよび第２ノードのソフトウェア・レイヤおよびハードウェア・レイヤ、ならびにそれらの到達可能性および潜在的な障害ポイントを示す構成図である。
【図６】クラスタ全体にわたるリソース管理サービスの機能を示した、第１ノードおよび第２ノードを示す構成図である。
【図７】構成済みクラスタのオペレーションを示した、コンピュータ・システムを示す構成図である。
【図８】クラスタ構成要素間での情報の流れを示す流れ図である。
【図９】単一ノードの様々なオペレーション状態を示す状態図である。
【図１０】システムの自己監視の依存性を示す流れ図である。
【図１１】クラスタ・スプリット状況を有するクラスタを示す構成図である。
【図１２】接続が再度確立されたクラスタを示す構成図である。
【図１３】マージ段階１、すなわちサブクラスタの分解段階にあるクラスタを示す構成図である。
【図１４】マージ段階２、すなわち第１ノードの接合段階にあるクラスタを示す構成図である。
【図１５】マージ段階３、すなわち第２ノードの接合段階にあるクラスタを示す構成図である。
【図１６】構成定数の例を示す構成図である。
【図１７】構成定数の例を示す構成図である。
【図１８】構成定数の例を示す構成図である。
【図１９】構成定数の例を示す構成図である。
【図２０】構成定数の例を示す構成図である。
【図２１】クリティカル・リソースを備えた２ノード・クラスタに関するオペレーション定数の一例を示す構成図である。
【図２２】クリティカル・リソースを備えた２ノード・クラスタに関するオペレーション定数の一例を示す構成図である。
【図２３】クリティカル・リソースを備えた２ノード・クラスタに関するオペレーション定数の一例を示す構成図である。
【図２４】クリティカル・リソースを備えた５ノード・クラスタに関するオペレーション定数の一例を示す構成図である。
【図２５】クリティカル・リソースを備えた５ノード・クラスタに関するオペレーション定数の一例を示す構成図である。
【図２６】クリティカル・リソースを備えた５ノード・クラスタに関するオペレーション定数の一例を示す構成図である。
【符号の説明】
【０１３４】
９０５    ＴＢロック
９０６    ＴＢアンロック
９０７    ＴＢロック
９０８    ＴＢアンロック
９０９    ＴＢロック
９１０    ＴＢアンロック
９１５    定数保留
【図１】
2004342079.tif 000003
【図２】
2004342079.tif 000004
【図３】
2004342079.tif 000005
【図４】
2004342079.tif 000006
【図５】
2004342079.tif 000007
【図６】
2004342079.tif 000008
【図７】
2004342079.tif 000009
【図８】
2004342079.tif 000010
【図９】
2004342079.tif 000011
【図１０】
2004342079.tif 000012
【図１１】
2004342079.tif 000013
【図１２】
2004342079.tif 000014
【図１３】
2004342079.tif 000015
【図１４】
2004342079.tif 000016
【図１５】
2004342079.tif 000017
【図１６】
2004342079.tif 000018
【図１７】
2004342079.tif 000019
【図１８】
2004342079.tif 000020
【図１９】
2004342079.tif 000021
【図２０】
2004342079.tif 000022
【図２１】
2004342079.tif 000023
【図２２】
2004342079.tif 000024
【図２３】
2004342079.tif 000025
【図２４】
2004342079.tif 000026
【図２５】
2004342079.tif 000027
【図２６】
2004342079.tif 000028