JP4505763B2 - ノードクラスタの管理 - Google Patents

Description

本発明は、ノードクラスタの管理に関する。

クラスタは、データ及び他のシステム資源を共有することができる相互接続された処理デバイスのグループであり、たとえば、コンピュータ又はサーバのグループである。クラスタの各デバイスは、ノード又はクラスタメンバーとも呼ばれ、１つ又は２つ以上の共有アプリケーションを実行するように構成することができ、その結果、これらのアプリケーションに関して、複数のノードのネットワークは、単一ノードのネットワークよりも信頼性が増加している。クラスタマネージャは、クラスタが可能な最大範囲まで動作できる状態を維持すると共に、共有データの完全性を危険にさらす可能性のある状況を防止することを確実にする目的で、クラスタを制御するのに使用され、そのインスタンスは、各クラスタメンバー上で実行される。

単一インスタンスクラスタアプリケーションは、一時に１つのクラスタメンバー上しか実行されない。このタイプのアプリケーションの可用性を高くするために、クラスタマネージャは、現在のメンバーがアプリケーションをもはや実行できない場合に、別のクラスタメンバー上でアプリケーションを開始するためのメカニズムを提供する。マルチインスタンスアプリケーションは、同時に複数のクラスタメンバー上で実行することができる。マルチインスタンスアプリケーションは、その名の通り、１つのクラスタメンバーの故障が、他のメンバー上で実行されているアプリケーションのインスタンスに影響を与えないので、高い可用性を有する。

既知のクラスタ配置に関する１つの問題は、たとえばノード間通信リンクの故障によってクラスタパーティションが行われると、ノードの複数のサブグループが形成される可能性があり、各サブグループが、元のクラスタと同じ外部識別情報を有する新しいクラスタの再形成を試みることである。これは、たとえば、２つ以上のサブグループが同じ単一インスタンスアプリケーションの実行を試みると、共有データの完全性にとって深刻な結果を有する可能性がある。

データ完全性を保証するために、どのサブグループが新しいクラスタを形成するのかを決定して、残りのサブグループがクラスタを形成するのを防止する投票方式を動作させるクラスタマネージャが開発されている。各サブグループに票が割り当てられ、票はサブグループのノードの個数に基づいている。新しいクラスタを形成するために必要な票数は、取得「定足数」（obtaining "quorum"）と呼ばれ、一般に、最大のサブグループ（複数可）しかクラスタを再形成することができないように、利用可能な元の票の少なくとも半分であることが必要とされる。「スプリットブレイン」シナリオと呼ばれる、２つのサブグループが等しい票を有する状況をうまく処理するために、調停デバイスが設けられる。調停デバイスの一例は、クラスタのすべてのノードに接続されたクォーラムサーバである。クォーラムサーバは、１票を有する仮想クラスタメンバーとして機能する。したがって、２つの等しいサイズのサブグループへのクラスタパーティションに続いて、クォーラムサーバは、自身の票をそれらのサブグループの一方に割り当て、それによって、そのサブグループは、定足数を達成してクラスタを再形成することが可能になる一方、他方のグループは、定足数を与えられず、クラスタを開始することができない。

しかしながら、クォーラムサーバを有する配置であっても、クラスタがサブグループによって再形成されるようにするには、サブグループが、元のクラスタに存在していたノードの少なくとも半数で構成されることが、依然として必要とされる。これは、或るノードのグループがクラスタの残りのノード及びクォーラムサーバから分離された場合に、そのグループが、明らかに過半数のノードを有しない限りクラスタを再形成することができず、したがって、複数のサブグループが形成されることを回避することを確実にするためである。

したがって、従来のクラスタ配置では、たとえば、１つ又は２つ以上の故障の結果として、クラスタが３つ以上のサブグループにパーティショニングされる場合といった、クラスタの存続が必要でない場合に、クラスタの存続が妨げられる可能性がある。したがって、従来のシステムでは、データ完全性を維持するために、高いクラスタ可用性が妥協される場合がある。

本発明は、上述した背景からなされたものであって、ノードクラスタの管理のための方法およびシステムを提供することを目的とする。

本発明の一形態は、ノードのクラスタを管理する方法であって、前記クラスタはノードの複数のグループを含み、前記ノードはそれぞれ票に関連付けられ、前記複数のグループはそれぞれ調停デバイスと通信し、前記調停デバイスは、前記クラスタのノードの個数に応じた複数の票に関連付けられ、前記方法は、前記複数のグループのそれぞれについて、そのグループに関連付けられている前記票に、前記調停デバイスに関連付けられている前記票を加えることと、前記ノードの前記複数のグループのいずれが最大票数を有するかを判断することと、前記最大票数を有するグループを前記クラスタとして機能するように選任することとを含む。

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

図１を参照すると、本発明によるクラスタ１は、相互接続された第１のネットワークハブ３ａ及び第２のネットワークハブ３ｂを介して相互接続された第１のサーバ２ａ、第２のサーバ２ｂ、第３のサーバ２ｃ、及び第４のサーバ２ｄを含む。これらのサーバは、本明細書ではノード又はクラスタメンバーとも呼ばれる。第１のサーバ２ａ及び第２のサーバ２ｂは、第１のハブ３ａに接続され、第３のサーバ２ｃ及び第４のサーバ２ｄは、第２のハブ３ｂに接続されている。第１のネットワークハブ３ａ及び第２のネットワークハブ３ｂは、通信リンク３ｃを介して相互接続されている。各ノード２ａ、２ｂ、２ｃ、２ｄは、それらノードのハブ３ａ、３ｂへの接続を可能にするための各ネットワークアダプタ４ａ、４ｂ、４ｃ、４ｄと、共有ストレージバス５に接続するためのポート（図示せず）とを備える。共有ストレージバス５には、クォーラムディスク６が接続されている。ノード２ａ〜２ｄは、各通信リンク７ａ〜７ｄを介してそれらの各ハブ３ａ、３ｂに接続されている。

本例では、ポートは、小規模コンピュータシステムインターフェース（ＳＣＳＩ）ポートであり、共有ストレージバス５は、サーバ２ａ〜２ｄとクォーラムディスク６との間のＳＣＳＩ接続を提供する。クォーラムディスクは、本例では、ハードウェアベースの安価なディスクの冗長アレイ（ＲＡＩＤ）である。ただし、たとえばファイバチャネルベースのディスクを含む、他のストレージを使用することができ、たとえば、ソフトウェアベースのＲＡＩＤシステム又はＳＣＳＩプロトコルを処理できる任意のハードディスクドライブを使用することができる。

ＳＣＳＩプロトコルは、ホストシステムに対するＳＣＳＩインターフェースの故障及びデータパスの故障等の異なる種類の接続故障を区別できるセンスキーを提供する。

第１のサーバ２ａ、第２のサーバ２ｂ、第３のサーバ２ｃ、第４のサーバ２ｄは、それらの各機能を遂行するのに必要なハードウェア、オペレーティングシステムソフトウェア、及びアプリケーションソフトウェアのすべてを有する従来の市販のサーバであることが理解されよう。

第１のサーバ２ａ、第２のサーバ２ｂ、第３のサーバ２ｃ、及び第４のサーバ２ｄのそれぞれは、自身のメモリに、クラスタ１を制御するためのクラスタマネージャアプリケーションのインスタンス８ａ〜８ｄを記憶している。

クラスタマネージャが、クラスタが存続できるか否かを判断し、クラスタを再形成できるサブグループ間を調停する投票方式は、或るクラスタによって獲得された現在の票Ｃがそのクラスタについて定義された定足数票Ｑ以上であることを必要とする。本例では、クラスタの各ノードには、１ノード票が割り当てられる。ノード票の総数Ｖｎは、クラスタのノードの個数Ｎに等しくされる。クォーラムディスクには、Ｎ−１票Ｖｑが割り当てられる。したがって、或る特定のクラスタについて予測票Ｅは、

となる。定足数票Ｑは、

として定義される。ここで、関数「round_down」は、端数が切り捨てられて最も近い整数にされた結果を返す。

したがって、クォーラムディスクにアクセスできる単一のノードであっても、他のＮ−１個のノードがダウンしている場合に、定足数を達成してクラスタを形成することができる。その理由は、Ｑ＝Ｎ及びクォーラムディスク票Ｖｑ＝Ｎ−１であり、その結果、現在の票Ｃ＝１＋（Ｎ−１）＝Ｎであり、これは、必要な定足数に等しいからである。

図２は、クラスタ１の現在の票Ｃの数に変化が検出された後に、本発明によるクラスタマネージャによって遂行されるステップを示すフロー図である。

一般的には、ノード及びクォーラムディスクは、全体のオペレーションの参加エンティティである。参加エンティティ間では、クラスタの健全性を判断するメッセージの定期的交換が行われる。或るエンティティからのメッセージが受信できなくなった後に、クラスタの再構築が行われる。この全体のプロセスの一部として、クラスタサブグループの現在の状態が判断され、これに基づいて、さまざまなサブグループの中から１つの機能するクラスタを作成する適切な決定が行われる。

クラスタ１の各ノード２ａ〜２ｄは、ノード２ａ〜２ｄ間で送信される一連のハートビートメッセージと、ノード２ａ〜２ｄによってクォーラムディスク６に記憶されたフラグ及び他の情報とを介して、クラスタの他のノードの個数及びステータスを絶えず監視する。したがって、各ノードは、予測票Ｅの数を求めることができ、したがって、定足数票Ｑを求めることができ、さらに、クラスタ１の現在の票Ｃを求めることができる。

また、クォーラムディスク６は、ノード２ａ〜２ｄによって提供される、クラスタ１の予測票Ｅの数及び現在の票Ｃの数も記憶し、それらのノードがこれらの値に確実に同意できるようにする。

予測票Ｅの数は、クォーラムディスクが故障していることが確実に判断されない限り変更されない。

したがって、各ノード２ａ〜２ｄは、そのノード上で実行されているクラスタマネージャの制御の下、現在の票Ｃの数の減少が発生する時を求めることができる（ステップｓ１０１）。この減少は故障を示すものである。この場合、クラスタの活動は一時停止され、クラスタの再構築手順がトリガされる（ステップｓ１０２）。

故障のタイプには主に２つのタイプがある。第１のタイプは、たとえば、ノードのカーネルのハング若しくは完全なカーネル故障、又は、任意の個数の他のクラスタ通信故障、ハードウェア故障、若しくはソフトウェア故障の結果としてのリンク又はノードの故障を含む。

たとえば、図１に示すシステムでは、故障は、第１のネットワークハブ３ａと第２のネットワークハブ３ｂとを相互接続する通信リンク３ｃの故障の場合がある。この故障の結果、クラスタ１は、第１のサーバ２ａ及び第２のサーバ２ｂを含む第１のサブグループと、第３のサーバ２ｃ及び第４のサーバ２ｄを含む第２のサブグループとにパーティショニングされる。

別の例として、故障は、第２のハブ３ｂと第４のノード２ｄとの間のリンク７ｄの故障の場合がある。この故障の結果、クラスタ１は、第１のサーバ２ａ、第２のサーバ２ｂ、及び第３のサーバ２ｃを含む第１のサブグループと、第４のサーバ２ｄのみを含む第２のサブグループとにパーティショニングされる。

これらの代替的な例は、以下でさらに詳細に検討することにする。

第２の主なタイプの故障は、クォーラムディスクの故障である。この故障は、さらに２つのサブタイプを有する。第１のサブタイプでは、クォーラムディスクが故障したことが確実に判明している。第２のサブタイプでは、クォーラムディスクの明らかな故障はあるが、クォーラムディスクが故障したことが確実に判明していない。たとえば、クォーラムディスクへのリンク５が故障している場合である。

サブグループ３０の各ノード２ａ〜２ｄとクォーラムディスク６との間のＳＣＳＩ接続５のおかげで、各ノード２ａ〜２ｄは、クォーラムディスク６が故障しているか否かを判断することができ、あるいは、クォーラムディスク６との通信パス５が故障しているか否かを判断することができる。図２のフローチャートに戻って、まず、クォーラムディスク６が故障しているか否かが判断される（ステップＳ１０３）。クォーラムディスク６が故障していない場合、クォーラムディスクとの通信パス５が故障しているか否かが判断される（ステップＳ１０４）。

検出された故障がタイプ１である場合、換言すれば、クォーラムディスクの故障もクォーラムパスの故障もない場合、これは、クォーラムディスク６との通信の故障ではなく、クラスタ１のノードの数の変化の結果として、現在のクラスタ票Ｃが変化していることを示すものである。

図３は、１つ又は２つ以上の故障が発生したシステムの一般的な場合を示す図である。システムは、複数のサブグループ１０ａ〜１０ｎにパーティショニングされ、各サブグループは、複数のノード１１ａ〜１１ｎ、１２ａ〜１２ｎ、及び１３ａ〜１３ｎをそれぞれ有する。これらのノードのすべては、別個にクォーラムディスク６と通信を続ける。この場合、ノード１１ａ〜１１ｎの第１のグループ上で実行されているクラスタマネージャは、複数のサブグループへのクラスタパーティションが起こっている可能性があると判断し、したがって、どのサブグループ１０ａ〜１０ｎがクラスタ１を再形成すべきであるのかを判断するために調停が必要とされると判断する。第１のサブグループのノード１１ａ〜１１ｎ上で実行されているクラスタマネージャアプリケーションは、共に、それらノードのサブグループ１０ａの或るノードを、そのサブグループ１０ａのグループリーダとして選任するか、又は、グループリーダが事前に選任されている場合には、どのノードが現在のグループリーダであるのかを判断する（ステップ１０６）。たとえば、故障を検出したノードがグループリーダになる。

他のサブグループにおいても対応するステップが行われ、各サブグループ１０ａ〜１０ｎのグループリーダは、そのサブグループに割り当てられた現在の票Ｃをクォーラムディスク６上に公表し（ステップＳ１０７）、クォーラムディスク６上で他のサブグループにより公表された結果をチェックし（ステップＳ１０８）、それらサブグループのそれぞれの現在の票Ｃが、そのサブグループがクラスタを形成するのに十分であるか否かを判断する（ステップＳ１０９）。十分である場合、そのサブグループは、クラスタの活動を再開し（ステップＳ１１０）、プロセスがステップＳ１０１から再び開始される。他方、サブグループ１０ａ〜１０ｎが、クラスタステータスを獲得できない場合、サブグループ３０のノード１１ａ〜１１ｎは、定足数が獲得されるようになるまで、すべてのクラスタ活動の一時停止を継続する（ステップＳ１０５）。クォーラムディスクパスの故障が、ステップｓ１０４で検出された場合、１つ又は２つ以上のサブグループ１１ａ〜１１ｎは、クォーラム票Ｖｑをもはや有しない。この場合、クォーラムディスク６はまだ動作可能であるので、残りのサブグループの１つは、まだクラスタステータスを獲得できる場合がある。この場合、クォーラムディスクパスの故障による影響を受けるノードは、たとえばパスの修復が実行されるとすぐに、定足数を達成できるまで、一時停止の状態を維持する（ステップＳ１０５）。

クラスタステータスが獲得されているか否かを判断するための手順（ステップｓ１０９）を、図４を参照してより詳細に説明し、上述したリンクの故障の例を示す図５及び図６を参照してさらに例示する。

上記で言及した第１の例を図５に示す。図５では、リンク３ｃの故障の結果として、２つのサブグループ３０、３１が、それぞれ、クォーラムディスクとの通信を維持している。この場合、ノード２ａ及び２ｃがグループリーダとして指名されたものと仮定すると、各サブグループのグループリーダノードのクラスタマネージャ８ａ、８ｃは、一時的に、クォーラムディスク票Ｖｑを、クォーラムディスク上に公表されている各サブグループの票に加える（ステップｓ１２０）。

この場合、通信故障前のクラスタ１のノードの個数Ｎは４であり、したがって、予測クラスタ票Ｅは７（ＮにＶｑをプラスしたもの）である。ここで、クォーラムディスクには３票（Ｖｑ）が割り当てられ、定足数票Ｑの数は４である。通信故障前の現在の票Ｃ（ノード票＋クォーラムディスク票）は７であり、通信故障後には、第１のサブグループ及び第２のサブグループのそれぞれの現在の票Ｃは５に減少する。

その結果、この例では、クォーラムディスク票を各サブグループのノード票の合計に加えた結果、各グループの票は合計５票になる。各サブグループのクラスタマネージャは、この票の数が定足数票Ｑを超えるか否かを判断する（ステップｓ１２１）。超えない場合には、そのサブグループは、クラスタを形成することができない（図２のステップｓ１０５）。超える場合には、各サブグループのクラスタマネージャは、その票の数を、他のサブグループの票の数と比較する（ステップｓ１２２）。各サブグループのクラスタマネージャは、他のどのサブグループよりも多くの票を有する場合には、クラスタを形成し（ステップｓ１２３）、クラスタの活動を再開する（ステップｓ１１０）。各サブグループのクラスタマネージャが有する票が、別のサブグループよりも少ない場合には、ノードは一時停止の状態を維持する（図２のステップｓ１０５）。

各サブグループのクラスタマネージャは、別のサブグループと同じ票の数（この数は最も大きな票の数である）を有する場合には、自身のアルゴリズムに基づいて、どのグループを選択するかを決定し、このグループを選択し（ステップｓ１２４）、クラスタの活動を再開する（ステップｓ１１０）。１つの簡単なアルゴリズムは、最初に公表したサブグループが選択されるものである。

しかしながら、この選択を行うのに、他のアルゴリズムを使用することもできる。

図５に示す例では、双方のサブグループが定足数票Ｑの数を超える。また、双方のサブグループは、等しい票を有する。その結果、これらのサブグループのいずれも、クラスタを形成するように選択することができる。

図６に示す第２の例に上記アルゴリズムを適用すると、一方のサブグループ４０は３つのノードを有する一方、他方のサブグループ４１は１つのノードしか有しない。同じ手順が上述のように適用され、３票が第１のサブグループに加えられ、３票が第２のサブグループに加えられ、それぞれ定足数が与えられる。しかしながら、第２のサブグループに４票（１ノード票＋Ｖｑ）しか有しないのとは対照的に、第１のサブグループは、合計６票（３つのノード票＋Ｖｑ）を有する。その結果、第１ノードサブグループはクラスタを形成する一方、第２のサブグループはシャットダウンする。

図７は、第１ノードサブグループ５０とクォーラムディスク６との間にパス故障がある第３の例を示している。図２を参照すると、この例では、現在の票の変化が検出された後、ステップｓ１０４において、クォーラムパスの故障があるものと判断される。グループリーダが、サブグループごとに再び選任され（ステップｓ１１６）、各サブグループのクラスタマネージャは、現在の票がクォーラムと等しいか、又はクォーラムを超えるか否かを判断する（ステップｓ１１７）。クォーラムディスクの故障ではなく、クォーラムディスクパスの故障しかないので、サブグループのうちの１つは、定足数を獲得してクラスタを形成できる可能性がある。したがって、予測票又は定足数票を調整する必要はない。

この例では、定足数は４であり、第１のサブグループ５０の現在の票は、ノード票のみ、すなわち３票を含む。これは、必要とされる定足数よりも少なく、その結果、第１のサブグループ５０は、クラスタを形成することができず、第１のサブグループのノードは、一時停止の状態を維持する（ステップｓ１０５）。第１のサブグループは、たとえクォーラムディスクとの通信がもはやなかったとしても、元のクラスタからのノードのすべてを保持する場合にはクラスタを形成することができる。

単一のノードを含む第２のサブグループ５１の場合、現在の票は、単一のノード票及び３票のクォーラムディスク票を含み、合計４票を含む。したがって、現在の票は、必要とされる定足数を満たす。したがって、この単一のノードは、クラスタを形成することができる。

図１及び図２を再び参照して、ステップＳ１０３において、クォーラムディスクの故障が検出された場合、これは、たとえクラスタ１がパーティショニングされても、他のサブグループにはクォーラムディスク票Ｖｑが割り当てられないことを第１のサブグループのクラスタマネージャに示す。したがって、予測票Ｅ及び定足数票Ｑは、クォーラムディスク票Ｖｑがもはや利用可能でないことを考慮するように調整される（ステップＳ１１１）。したがって、予測票Ｅは、

となり、定足数票Ｑは、

となる。

次に、サブグループにおいて利用可能な現在の票Ｃが定足数票Ｑ以上であるか否かが判断される（ステップＳ１１２）。そうである場合、クラスタの活動を再開することができる（ステップＳ１１３）。そうでない場合、現在の票が、クラスタ１が定足数を有するのに十分となるまで、クラスタの活動は一時停止を継続する。本例では、クラスタの活動は一時停止を継続する。

たとえば、システムオペレータによる障害のあるクォーラムディスク６の修復又は取り替えの結果として、（ステップＳ１１４で判断されるように）クォーラムディスク６が再び動作すると、票調整プロセスがクラスタマネージャによって行われ、クォーラムディスク票Ｖｑを含むように予測票Ｅの数及び定足数票Ｑの数が増加される（ステップＳ１１５）。

プロセスは、その後、ステップＳ１０１から再び開始される。

したがって、本発明の実施形態は、調停デバイスとの通信の故障の原因を求めることができる方法を提供する。その原因に応じて、ノードのサブグループがクラスタを再構築しようとすることを可能にする手順が適用され、これによって、選択されたサブグループが、自身がクラスタを形成する唯一のサブグループであることを知ってクラスタを確実に形成できるようになるだけでなく、単一のノードしか含まないサブグループが適切な状況でクラスタを形成することも可能になる。

本発明の一実施形態によるクラスタ配置を示す図である。 この発明の実施形態によるクラスタマネージャによって遂行される手順を示すフロー図である。 １つ又は２つ以上の故障によって複数のクラスタサブグループの形成が引き起こされた後のクラスタ配置を示す図である。 クラスタステータスが獲得されているか否かを判断するための手順の態様をより詳細に示すフロー図である。 リンクの故障によって等しい個数のノードを有する２つのサブグループの作成が引き起こされた後の図１のクラスタ配置を示す図である。 リンクの故障によって等しくない個数のノードを有する２つのサブグループの作成が引き起こされた後の図１のクラスタ配置を示す図である。 リンクの故障によって等しくない個数のノードを有する２つのサブグループの作成が引き起こされ、且つ、第１のサブグループがクォーラムディスクへのリンクの故障を受けた後の図１のクラスタ配置を示す図である。

符号の説明

１・・・クラスタ
２ａ・・・サーバ
２ｂ・・・サーバ
２ｃ・・・サーバ
２ｄ・・・サーバ
３ａ・・・ハブ
３ｂ・・・ハブ
４ａ・・・ネットワークアダプタ
４ｂ・・・ネットワークアダプタ
４ｃ・・・ネットワークアダプタ
４ｄ・・・ネットワークアダプタ
５・・・共有ストレージバス
６・・・クォーラムディスク
７ａ・・・通信リンク
７ｂ・・・通信リンク
７ｃ・・・通信リンク
７ｄ・・・通信リンク
８ａ・・・クラスタマネージャ
８ｂ・・・クラスタマネージャ
８ｃ・・・クラスタマネージャ
８ｄ・・・クラスタマネージャ
１０ａ−ｎ・・・サブグループ
１１ａ−ｎ・・・ノード
１２ａ−ｎ・・・ノード
１３ａ−ｎ・・・ノード
３０・・・サブグループ
３１・・・サブグループ
４０・・・サブグループ
４１・・・サブグループ
５０・・・サブグループ
５１・・・サブグループ

Claims (12)

1. ノードのクラスタを管理する方法であって、前記クラスタの少なくとも１つのノードが、前記クラスタの形成においてノード間の衝突を解決することに使用するための調停デバイスに通信パスを介して接続可能であり、前記方法は、
   前記少なくとも１つのノードと前記調停デバイスとの間の通信の故障を検出することと、
   前記故障が前記通信パスの故障であるのか否かを判断することと、
   前記故障が前記通信パスの故障である場合に、前記故障の結果として形成されたノードのサブグループのそれぞれに関連付けられている票の数が所定のしきい値に達しているか否かを判断すること
   を含み、
   前記調停デバイスにアクセスできないノードの前記サブグループに関連付けられている前記票の数は、前記調停デバイスに関連付けられている票を含まず、
   前記調停デバイスにアクセスできるノードの前記サブグループに関連付けられている前記票の数は、前記調停デバイスに関連付けられている票を含む
   方法。
2. 前記数が前記所定のしきい値に達していないとき、前記ノードの前記サブグループの前記少なくとも１つのノードの１つ又は２つ以上の活動を一時停止すること
   を含む
   請求項１に記載の方法。
3. ノードのクラスタを管理する方法であって、前記クラスタの少なくとも１つのノードが、前記クラスタの形成においてノード間の衝突を解決することに使用するための調停デバイスに通信パスを介して接続可能であり、前記クラスタは、前記調停デバイスに関連付けられている値を含むしきい値に関連付けられ、前記方法は、
   前記少なくとも１つのノードと前記調停デバイスとの間の通信の故障を検出することと、
   前記故障が前記調停デバイスの故障であるのか否かを判断することと、
   前記故障が前記調停デバイスの故障であるとの判断に応答して、前記調停デバイスに関連付けられている前記値を除外することによって前記しきい値を調整することと
   を含む方法。
4. 前記故障後に、前記クラスタのノードの個数を求めることと、
   前記故障後に、前記クラスタのノードの前記求められた個数に応じた値を前記クラスタに割り当てることと、
   前記割り当てられた値を前記調整されたしきい値と比較することと
   をさらに含む
   請求項３に記載の方法。
5. 前記割り当てられた値が前記調整されたしきい値以上である場合に、前記クラスタのオペレーションを再開すること
   をさらに含む
   請求項４に記載の方法。
6. 前記調停デバイスが動作可能になった場合に、前記しきい値を調整し、前記調停デバイスに関連付けられている前記値を考慮することを含む
   請求項３〜５のいずれか１項に記載の方法。
7. 前記調停デバイスは、クォーラムディスクを備え、前記しきい値は、前記クラスタを形成するのに必要なノードの個数を求める定足数値を含む
   請求項３〜６のいずれか１項に記載の方法。
8. 前記故障の結果、前記クラスタは複数のサブグループにパーティショニングされ、前記複数のサブグループのそれぞれは前記調停デバイスと通信する
   請求項１〜７のいずれか１項に記載の方法。
9. 前記サブグループの前記ノードの１つは、前記サブグループの前記現在の票が前記サブグループのすべてに対してアクセス可能になるように、前記現在の票を前記調停デバイスへ送信する
   請求項８に記載の方法。
10. 前記複数のサブグループのそれぞれは、自身が前記クラスタとして動作すべきか否かを、他のサブグループの前記現在の票から判断する
    請求項９に記載のノードの方法。
11. 前記クォーラムディスクに関連付けられている票を、前記複数のサブグループのそれぞれに関連付けられている前記票に加え、前記複数のサブグループのいずれが前記クラスタとして動作するのかを判断することを含む
    請求項１０に記載の方法。
12. ノードのクラスタを管理するシステムであって、前記クラスタはノードの複数のグループを含み、前記ノードはそれぞれ票に関連付けられ、前記システムは調停デバイスをさらに備え、前記調停デバイスは、前記クラスタのノードの個数に応じた複数の票に関連付けられ、前記ノードはそれぞれクラスタマネージャにさらに関連付けられ、前記複数のグループのそれぞれの前記クラスタマネージャのうちの１つは、
    そのグループが前記調停デバイスと通信している場合には、そのグループが、前記調停デバイスの前記票を含めて、最大票数を有するか否かを判断する第１の判断手段と、
    前記調停デバイスが動作しているが、そのグループが前記調停デバイスと通信していない場合には、そのグループが、前記定足数を調整することなく前記定足数を満たすか否かを判断する第２の判断手段であって、前記調停デバイスにアクセスできないグループに関連付けられている前記票の数は、前記調停デバイスに関連付けられている票を含まず、前記調停デバイスにアクセスできるノードの前記サブグループに関連付けられている前記票の数は、前記調停デバイスに関連付けられている票を含む、第２の判断手段と、
    前記調停デバイスが動作していない場合には、前記調停デバイスに関連付けられている前記票を除外することによって前記定足数を調整し、前記定足数を調整した後に、そのグループが、前記定足数を満たすか否かを判断する第３の判断手段と
    を有するシステム。

Images