(57)【要約】【課題】ノードクラスタの管理のための方法を提供する。【解決手段】ノードのクラスタを管理する方法であって、前記クラスタはノードの複数のグループを含み、前記ノードはそれぞれ票に関連付けられ、前記複数のグループはそれぞれ調停デバイスと通信し、前記調停デバイスは、前記クラスタのノードの個数に応じた複数の票に関連付けられ、前記方法は、前記複数のグループのそれぞれについて、そのグループに関連付けられている前記票に、前記調停デバイスに関連付けられている前記票を加えることと、前記ノードの前記複数のグループのいずれが最大票数を有するかを判断することと、前記最大票数を有するグループを前記クラスタとして機能するように選任することとを含む方法。【選択図】図１
2008192139.tif 000002
【特許請求の範囲】
【請求項１】
ノードのクラスタを管理する方法であって、前記クラスタはノードの複数のグループを含み、前記ノードはそれぞれ票に関連付けられ、前記複数のグループはそれぞれ調停デバイスと通信し、前記調停デバイスは、前記クラスタのノードの個数に応じた複数の票に関連付けられ、前記方法は、
前記複数のグループのそれぞれについて、そのグループに関連付けられている前記票に、前記調停デバイスに関連付けられている前記票を加えることと、
前記ノードの前記複数のグループのいずれが最大票数を有するかを判断することと、
前記最大票数を有するグループを前記クラスタとして機能するように選任することと
を含む方法。
【請求項２】
２つ以上のグループが、前記最大票数を有する前記グループを構成する場合に、前記２つ以上のグループのうちの１つを前記クラスタとして機能するように選択することをさらに含む
請求項１に記載の方法。
【請求項３】
前記ノードのグループのいずれが前記最大票数を有するかを判断する前記動作は、所定の定足数を満たすか又は超えるグループについて実行される
請求項１又は２に記載の方法。
【請求項４】
前記所定の定足数はＮであり、ここで、Ｎは、前記クラスタのノードの総数である
請求項３に記載の方法。
【請求項５】
前記ノードはそれぞれ、１票に関連付けられ、前記調停デバイスは、Ｎ−１票に関連付けられ、ここで、Ｎは、前記クラスタのノードの前記総数である
請求項１〜４のいずれか１項に記載の方法。
【請求項６】
ノードのクラスタを管理する方法であって、前記クラスタの少なくとも１つのノードが、前記クラスタの形成においてノード間の衝突を解決することに使用するための調停デバイスに通信パスを介して接続可能であり、前記方法は、
前記少なくとも１つのノードと前記調停デバイスとの間の通信の故障を検出することと、
前記故障が、前記調停デバイスの故障であるのか、又は前記通信パスの故障であるのかを判断することと
を含む方法。
【請求項７】
前記故障が、前記通信パスの故障である場合に、前記故障の結果として形成されたノードのサブグループのそれぞれに関連付けられている票の数が所定のしきい値に達しているか否かを判断することをさらに含む
請求項６に記載の方法。
【請求項８】
前記数が前記所定のしきい値に達していないとき、前記ノードの前記サブグループの前記少なくとも１つのノードの１つ又は２つ以上の活動を一時停止すること
を含む
請求項７に記載の方法。
【請求項９】
前記調停デバイスにアクセスできないノードの前記サブグループに関連付けられている前記票の数は、前記調停デバイスに関連付けられている票を含まない
請求項７又は８に記載の方法。
【請求項１０】
前記調停デバイスにアクセスできるノードの前記サブグループに関連付けられている前記票の数は、前記調停デバイスに関連付けられている票を含む
請求項７〜９のいずれか１項に記載の方法。
【請求項１１】
前記クラスタは、前記調停デバイスに関連付けられている値を含むしきい値に関連付けられ、前記方法は、
前記故障が前記調停デバイスの故障であるとの判断に応答して、前記調停デバイスに関連付けられている前記値を除外することによって前記しきい値を調整すること
を含む
請求項６〜１０のいずれか１項に記載の方法。
【請求項１２】
前記故障後に、前記クラスタのノードの個数を求めることと、
前記故障後に、前記クラスタのノードの前記求められた個数に応じた値を前記クラスタに割り当てることと、
前記割り当てられた値を前記調整されたしきい値と比較することと
をさらに含む
請求項１１に記載の方法。
【請求項１３】
前記割り当てられた値が前記調整されたしきい値以上である場合に、前記クラスタのオペレーションを再開すること
をさらに含む
請求項１２に記載の方法。
【請求項１４】
前記調停デバイスが動作可能になった場合に、前記しきい値を調整し、前記調停デバイスに関連付けられている前記値を考慮することを含む
請求項１１〜１３のいずれか１項に記載の方法。
【請求項１５】
前記調停デバイスは、クォーラムディスクを備え、前記しきい値は、前記クラスタを形成するのに必要なノードの個数を求める定足数値を含む
請求項１１〜１４のいずれか１項に記載の方法。
【請求項１６】
前記故障の結果、前記クラスタは複数のサブグループにパーティショニングされ、前記複数のサブグループのそれぞれは前記調停デバイスと通信する
請求項６〜１５のいずれか１項に記載の方法。
【請求項１７】
前記サブグループの前記ノードの１つは、前記サブグループの前記現在の票が前記サブグループのすべてに対してアクセス可能になるように、前記現在の票を前記調停デバイスへ送信する
請求項１６に記載の方法。
【請求項１８】
前記複数のサブグループのそれぞれは、自身が前記クラスタとして動作すべきか否かを、他のサブグループの前記現在の票から判断する
請求項１７に記載のノードの方法。
【請求項１９】
前記クォーラムディスクに関連付けられている票を、前記複数のサブグループのそれぞれに関連付けられている前記票に加え、前記複数のサブグループのいずれが前記クラスタとして動作するのかを判断することを含む
請求項１８に記載の方法。
【請求項２０】
ノードのクラスタを管理するシステムであって、前記クラスタはノードの複数のグループを含み、前記ノードはそれぞれ票に関連付けられ、前記システムは調停デバイスをさらに備え、前記調停デバイスは、前記クラスタのノードの個数に応じた複数の票に関連付けられ、前記ノードはそれぞれクラスタマネージャにさらに関連付けられ、前記複数のグループのそれぞれの前記クラスタマネージャのうちの１つは、
そのグループが前記調停デバイスと通信している場合には、そのグループが、前記調停デバイスの前記票を含めて、最大票数を有するか否かを判断し、
前記調停デバイスが動作しているが、そのグループが前記調停デバイスと通信していない場合には、そのグループが、前記定足数を調整することなく前記定足数を満たすか否かを判断し、
前記調停デバイスが動作していない場合には、そのグループが、前記定足数を調整した後に前記定足数を満たすか否かを判断する
ように動作可能であるシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ノードクラスタの管理に関する。
【背景技術】
【０００２】
クラスタは、データ及び他のシステム資源を共有することができる相互接続された処理デバイスのグループであり、たとえば、コンピュータ又はサーバのグループである。クラスタの各デバイスは、ノード又はクラスタメンバーとも呼ばれ、１つ又は２つ以上の共有アプリケーションを実行するように構成することができ、その結果、これらのアプリケーションに関して、複数のノードのネットワークは、単一ノードのネットワークよりも信頼性が増加している。クラスタマネージャは、クラスタが可能な最大範囲まで動作できる状態を維持すると共に、共有データの完全性を危険にさらす可能性のある状況を防止することを確実にする目的で、クラスタを制御するのに使用され、そのインスタンスは、各クラスタメンバー上で実行される。
【０００３】
単一インスタンスクラスタアプリケーションは、一時に１つのクラスタメンバー上しか実行されない。このタイプのアプリケーションの可用性を高くするために、クラスタマネージャは、現在のメンバーがアプリケーションをもはや実行できない場合に、別のクラスタメンバー上でアプリケーションを開始するためのメカニズムを提供する。マルチインスタンスアプリケーションは、同時に複数のクラスタメンバー上で実行することができる。マルチインスタンスアプリケーションは、その名の通り、１つのクラスタメンバーの故障が、他のメンバー上で実行されているアプリケーションのインスタンスに影響を与えないので、高い可用性を有する。
【０００４】
既知のクラスタ配置に関する１つの問題は、たとえばノード間通信リンクの故障によってクラスタパーティションが行われると、ノードの複数のサブグループが形成される可能性があり、各サブグループが、元のクラスタと同じ外部識別情報を有する新しいクラスタの再形成を試みることである。これは、たとえば、２つ以上のサブグループが同じ単一インスタンスアプリケーションの実行を試みると、共有データの完全性にとって深刻な結果を有する可能性がある。
【０００５】
データ完全性を保証するために、どのサブグループが新しいクラスタを形成するのかを決定して、残りのサブグループがクラスタを形成するのを防止する投票方式を動作させるクラスタマネージャが開発されている。各サブグループに票が割り当てられ、票はサブグループのノードの個数に基づいている。新しいクラスタを形成するために必要な票数は、取得「定足数」（obtaining "quorum"）と呼ばれ、一般に、最大のサブグループ（複数可）しかクラスタを再形成することができないように、利用可能な元の票の少なくとも半分であることが必要とされる。「スプリットブレイン」シナリオと呼ばれる、２つのサブグループが等しい票を有する状況をうまく処理するために、調停デバイスが設けられる。調停デバイスの一例は、クラスタのすべてのノードに接続されたクォーラムサーバである。クォーラムサーバは、１票を有する仮想クラスタメンバーとして機能する。したがって、２つの等しいサイズのサブグループへのクラスタパーティションに続いて、クォーラムサーバは、自身の票をそれらのサブグループの一方に割り当て、それによって、そのサブグループは、定足数を達成してクラスタを再形成することが可能になる一方、他方のグループは、定足数を与えられず、クラスタを開始することができない。
【０００６】
しかしながら、クォーラムサーバを有する配置であっても、クラスタがサブグループによって再形成されるようにするには、サブグループが、元のクラスタに存在していたノードの少なくとも半数で構成されることが、依然として必要とされる。これは、或るノードのグループがクラスタの残りのノード及びクォーラムサーバから分離された場合に、そのグループが、明らかに過半数のノードを有しない限りクラスタを再形成することができず、したがって、複数のサブグループが形成されることを回避することを確実にするためである。
【０００７】
したがって、従来のクラスタ配置では、たとえば、１つ又は２つ以上の故障の結果として、クラスタが３つ以上のサブグループにパーティショニングされる場合といった、クラスタの存続が必要でない場合に、クラスタの存続が妨げられる可能性がある。したがって、従来のシステムでは、データ完全性を維持するために、高いクラスタ可用性が妥協される場合がある。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
本発明は、上述した背景からなされたものであって、ノードクラスタの管理のための方法およびシステムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明の一形態は、ノードのクラスタを管理する方法であって、前記クラスタはノードの複数のグループを含み、前記ノードはそれぞれ票に関連付けられ、前記複数のグループはそれぞれ調停デバイスと通信し、前記調停デバイスは、前記クラスタのノードの個数に応じた複数の票に関連付けられ、前記方法は、前記複数のグループのそれぞれについて、そのグループに関連付けられている前記票に、前記調停デバイスに関連付けられている前記票を加えることと、前記ノードの前記複数のグループのいずれが最大票数を有するかを判断することと、前記最大票数を有するグループを前記クラスタとして機能するように選任することとを含む。
【００１０】
次に、この発明の実施形態を、添付図面を参照して、例として説明することにする。
【発明を実施するための最良の形態】
【００１１】
図１を参照すると、本発明によるクラスタ１は、相互接続された第１のネットワークハブ３ａ及び第２のネットワークハブ３ｂを介して相互接続された第１のサーバ２ａ、第２のサーバ２ｂ、第３のサーバ２ｃ、及び第４のサーバ２ｄを含む。これらのサーバは、本明細書ではノード又はクラスタメンバーとも呼ばれる。第１のサーバ２ａ及び第２のサーバ２ｂは、第１のハブ３ａに接続され、第３のサーバ２ｃ及び第４のサーバ２ｄは、第２のハブ３ｂに接続されている。第１のネットワークハブ３ａ及び第２のネットワークハブ３ｂは、通信リンク３ｃを介して相互接続されている。各ノード２ａ、２ｂ、２ｃ、２ｄは、それらノードのハブ３ａ、３ｂへの接続を可能にするための各ネットワークアダプタ４ａ、４ｂ、４ｃ、４ｄと、共有ストレージバス５に接続するためのポート（図示せず）とを備える。共有ストレージバス５には、クォーラムディスク６が接続されている。ノード２ａ〜２ｄは、各通信リンク７ａ〜７ｄを介してそれらの各ハブ３ａ、３ｂに接続されている。
【００１２】
本例では、ポートは、小規模コンピュータシステムインターフェース（ＳＣＳＩ）ポートであり、共有ストレージバス５は、サーバ２ａ〜２ｄとクォーラムディスク６との間のＳＣＳＩ接続を提供する。クォーラムディスクは、本例では、ハードウェアベースの安価なディスクの冗長アレイ（ＲＡＩＤ）である。ただし、たとえばファイバチャネルベースのディスクを含む、他のストレージを使用することができ、たとえば、ソフトウェアベースのＲＡＩＤシステム又はＳＣＳＩプロトコルを処理できる任意のハードディスクドライブを使用することができる。
【００１３】
ＳＣＳＩプロトコルは、ホストシステムに対するＳＣＳＩインターフェースの故障及びデータパスの故障等の異なる種類の接続故障を区別できるセンスキーを提供する。
【００１４】
第１のサーバ２ａ、第２のサーバ２ｂ、第３のサーバ２ｃ、第４のサーバ２ｄは、それらの各機能を遂行するのに必要なハードウェア、オペレーティングシステムソフトウェア、及びアプリケーションソフトウェアのすべてを有する従来の市販のサーバであることが理解されよう。
【００１５】
第１のサーバ２ａ、第２のサーバ２ｂ、第３のサーバ２ｃ、及び第４のサーバ２ｄのそれぞれは、自身のメモリに、クラスタ１を制御するためのクラスタマネージャアプリケーションのインスタンス８ａ〜８ｄを記憶している。
【００１６】
クラスタマネージャが、クラスタが存続できるか否かを判断し、クラスタを再形成できるサブグループ間を調停する投票方式は、或るクラスタによって獲得された現在の票Ｃがそのクラスタについて定義された定足数票Ｑ以上であることを必要とする。本例では、クラスタの各ノードには、１ノード票が割り当てられる。ノード票の総数Ｖｎは、クラスタのノードの個数Ｎに等しくされる。クォーラムディスクには、Ｎ−１票Ｖｑが割り当てられる。したがって、或る特定のクラスタについて予測票Ｅは、
【００１７】
【数１】
2008192139.tif 000003
【００１８】
となる。定足数票Ｑは、
【００１９】
【数２】
2008192139.tif 000004
【００２０】
として定義される。ここで、関数「round_down」は、端数が切り捨てられて最も近い整数にされた結果を返す。
【００２１】
したがって、クォーラムディスクにアクセスできる単一のノードであっても、他のＮ−１個のノードがダウンしている場合に、定足数を達成してクラスタを形成することができる。その理由は、Ｑ＝Ｎ及びクォーラムディスク票Ｖｑ＝Ｎ−１であり、その結果、現在の票Ｃ＝１＋（Ｎ−１）＝Ｎであり、これは、必要な定足数に等しいからである。
【００２２】
図２は、クラスタ１の現在の票Ｃの数に変化が検出された後に、本発明によるクラスタマネージャによって遂行されるステップを示すフロー図である。
【００２３】
一般的には、ノード及びクォーラムディスクは、全体のオペレーションの参加エンティティである。参加エンティティ間では、クラスタの健全性を判断するメッセージの定期的交換が行われる。或るエンティティからのメッセージが受信できなくなった後に、クラスタの再構築が行われる。この全体のプロセスの一部として、クラスタサブグループの現在の状態が判断され、これに基づいて、さまざまなサブグループの中から１つの機能するクラスタを作成する適切な決定が行われる。
【００２４】
クラスタ１の各ノード２ａ〜２ｄは、ノード２ａ〜２ｄ間で送信される一連のハートビートメッセージと、ノード２ａ〜２ｄによってクォーラムディスク６に記憶されたフラグ及び他の情報とを介して、クラスタの他のノードの個数及びステータスを絶えず監視する。したがって、各ノードは、予測票Ｅの数を求めることができ、したがって、定足数票Ｑを求めることができ、さらに、クラスタ１の現在の票Ｃを求めることができる。
【００２５】
また、クォーラムディスク６は、ノード２ａ〜２ｄによって提供される、クラスタ１の予測票Ｅの数及び現在の票Ｃの数も記憶し、それらのノードがこれらの値に確実に同意できるようにする。
【００２６】
予測票Ｅの数は、クォーラムディスクが故障していることが確実に判断されない限り変更されない。
【００２７】
したがって、各ノード２ａ〜２ｄは、そのノード上で実行されているクラスタマネージャの制御の下、現在の票Ｃの数の減少が発生する時を求めることができる（ステップｓ１０１）。この減少は故障を示すものである。この場合、クラスタの活動は一時停止され、クラスタの再構築手順がトリガされる（ステップｓ１０２）。
【００２８】
故障のタイプには主に２つのタイプがある。第１のタイプは、たとえば、ノードのカーネルのハング若しくは完全なカーネル故障、又は、任意の個数の他のクラスタ通信故障、ハードウェア故障、若しくはソフトウェア故障の結果としてのリンク又はノードの故障を含む。
【００２９】
たとえば、図１に示すシステムでは、故障は、第１のネットワークハブ３ａと第２のネットワークハブ３ｂとを相互接続する通信リンク３ｃの故障の場合がある。この故障の結果、クラスタ１は、第１のサーバ２ａ及び第２のサーバ２ｂを含む第１のサブグループと、第３のサーバ２ｃ及び第４のサーバ２ｄを含む第２のサブグループとにパーティショニングされる。
【００３０】
別の例として、故障は、第２のハブ３ｂと第４のノード２ｄとの間のリンク７ｄの故障の場合がある。この故障の結果、クラスタ１は、第１のサーバ２ａ、第２のサーバ２ｂ、及び第３のサーバ２ｃを含む第１のサブグループと、第４のサーバ２ｄのみを含む第２のサブグループとにパーティショニングされる。
【００３１】
これらの代替的な例は、以下でさらに詳細に検討することにする。
【００３２】
第２の主なタイプの故障は、クォーラムディスクの故障である。この故障は、さらに２つのサブタイプを有する。第１のサブタイプでは、クォーラムディスクが故障したことが確実に判明している。第２のサブタイプでは、クォーラムディスクの明らかな故障はあるが、クォーラムディスクが故障したことが確実に判明していない。たとえば、クォーラムディスクへのリンク５が故障している場合である。
【００３３】
サブグループ３０の各ノード２ａ〜２ｄとクォーラムディスク６との間のＳＣＳＩ接続５のおかげで、各ノード２ａ〜２ｄは、クォーラムディスク６が故障しているか否かを判断することができ、あるいは、クォーラムディスク６との通信パス５が故障しているか否かを判断することができる。図２のフローチャートに戻って、まず、クォーラムディスク６が故障しているか否かが判断される（ステップＳ１０３）。クォーラムディスク６が故障していない場合、クォーラムディスクとの通信パス５が故障しているか否かが判断される（ステップＳ１０４）。
【００３４】
検出された故障がタイプ１である場合、換言すれば、クォーラムディスクの故障もクォーラムパスの故障もない場合、これは、クォーラムディスク６との通信の故障ではなく、クラスタ１のノードの数の変化の結果として、現在のクラスタ票Ｃが変化していることを示すものである。
【００３５】
図３は、１つ又は２つ以上の故障が発生したシステムの一般的な場合を示す図である。システムは、複数のサブグループ１０ａ〜１０ｎにパーティショニングされ、各サブグループは、複数のノード１１ａ〜１１ｎ、１２ａ〜１２ｎ、及び１３ａ〜１３ｎをそれぞれ有する。これらのノードのすべては、別個にクォーラムディスク６と通信を続ける。この場合、ノード１１ａ〜１１ｎの第１のグループ上で実行されているクラスタマネージャは、複数のサブグループへのクラスタパーティションが起こっている可能性があると判断し、したがって、どのサブグループ１０ａ〜１０ｎがクラスタ１を再形成すべきであるのかを判断するために調停が必要とされると判断する。第１のサブグループのノード１１ａ〜１１ｎ上で実行されているクラスタマネージャアプリケーションは、共に、それらノードのサブグループ１０ａの或るノードを、そのサブグループ１０ａのグループリーダとして選任するか、又は、グループリーダが事前に選任されている場合には、どのノードが現在のグループリーダであるのかを判断する（ステップ１０６）。たとえば、故障を検出したノードがグループリーダになる。
【００３６】
他のサブグループにおいても対応するステップが行われ、各サブグループ１０ａ〜１０ｎのグループリーダは、そのサブグループに割り当てられた現在の票Ｃをクォーラムディスク６上に公表し（ステップＳ１０７）、クォーラムディスク６上で他のサブグループにより公表された結果をチェックし（ステップＳ１０８）、それらサブグループのそれぞれの現在の票Ｃが、そのサブグループがクラスタを形成するのに十分であるか否かを判断する（ステップＳ１０９）。十分である場合、そのサブグループは、クラスタの活動を再開し（ステップＳ１１０）、プロセスがステップＳ１０１から再び開始される。他方、サブグループ１０ａ〜１０ｎが、クラスタステータスを獲得できない場合、サブグループ３０のノード１１ａ〜１１ｎは、定足数が獲得されるようになるまで、すべてのクラスタ活動の一時停止を継続する（ステップＳ１０５）。クォーラムディスクパスの故障が、ステップｓ１０４で検出された場合、１つ又は２つ以上のサブグループ１１ａ〜１１ｎは、クォーラム票Ｖｑをもはや有しない。この場合、クォーラムディスク６はまだ動作可能であるので、残りのサブグループの１つは、まだクラスタステータスを獲得できる場合がある。この場合、クォーラムディスクパスの故障による影響を受けるノードは、たとえばパスの修復が実行されるとすぐに、定足数を達成できるまで、一時停止の状態を維持する（ステップＳ１０５）。
【００３７】
クラスタステータスが獲得されているか否かを判断するための手順（ステップｓ１０９）を、図４を参照してより詳細に説明し、上述したリンクの故障の例を示す図５及び図６を参照してさらに例示する。
【００３８】
上記で言及した第１の例を図５に示す。図５では、リンク３ｃの故障の結果として、２つのサブグループ３０、３１が、それぞれ、クォーラムディスクとの通信を維持している。この場合、ノード２ａ及び２ｃがグループリーダとして指名されたものと仮定すると、各サブグループのグループリーダノードのクラスタマネージャ８ａ、８ｃは、一時的に、クォーラムディスク票Ｖｑを、クォーラムディスク上に公表されている各サブグループの票に加える（ステップｓ１２０）。
【００３９】
この場合、通信故障前のクラスタ１のノードの個数Ｎは４であり、したがって、予測クラスタ票Ｅは７（ＮにＶｑをプラスしたもの）である。ここで、クォーラムディスクには３票（Ｖｑ）が割り当てられ、定足数票Ｑの数は４である。通信故障前の現在の票Ｃ（ノード票＋クォーラムディスク票）は７であり、通信故障後には、第１のサブグループ及び第２のサブグループのそれぞれの現在の票Ｃは５に減少する。
【００４０】
その結果、この例では、クォーラムディスク票を各サブグループのノード票の合計に加えた結果、各グループの票は合計５票になる。各サブグループのクラスタマネージャは、この票の数が定足数票Ｑを超えるか否かを判断する（ステップｓ１２１）。超えない場合には、そのサブグループは、クラスタを形成することができない（図２のステップｓ１０５）。超える場合には、各サブグループのクラスタマネージャは、その票の数を、他のサブグループの票の数と比較する（ステップｓ１２２）。各サブグループのクラスタマネージャは、他のどのサブグループよりも多くの票を有する場合には、クラスタを形成し（ステップｓ１２３）、クラスタの活動を再開する（ステップｓ１１０）。各サブグループのクラスタマネージャが有する票が、別のサブグループよりも少ない場合には、ノードは一時停止の状態を維持する（図２のステップｓ１０５）。
【００４１】
各サブグループのクラスタマネージャは、別のサブグループと同じ票の数（この数は最も大きな票の数である）を有する場合には、自身のアルゴリズムに基づいて、どのグループを選択するかを決定し、このグループを選択し（ステップｓ１２４）、クラスタの活動を再開する（ステップｓ１１０）。１つの簡単なアルゴリズムは、最初に公表したサブグループが選択されるものである。
【００４２】
しかしながら、この選択を行うのに、他のアルゴリズムを使用することもできる。
【００４３】
図５に示す例では、双方のサブグループが定足数票Ｑの数を超える。また、双方のサブグループは、等しい票を有する。その結果、これらのサブグループのいずれも、クラスタを形成するように選択することができる。
【００４４】
図６に示す第２の例に上記アルゴリズムを適用すると、一方のサブグループ４０は３つのノードを有する一方、他方のサブグループ４１は１つのノードしか有しない。同じ手順が上述のように適用され、３票が第１のサブグループに加えられ、３票が第２のサブグループに加えられ、それぞれ定足数が与えられる。しかしながら、第２のサブグループに４票（１ノード票＋Ｖｑ）しか有しないのとは対照的に、第１のサブグループは、合計６票（３つのノード票＋Ｖｑ）を有する。その結果、第１ノードサブグループはクラスタを形成する一方、第２のサブグループはシャットダウンする。
【００４５】
図７は、第１ノードサブグループ５０とクォーラムディスク６との間にパス故障がある第３の例を示している。図２を参照すると、この例では、現在の票の変化が検出された後、ステップｓ１０４において、クォーラムパスの故障があるものと判断される。グループリーダが、サブグループごとに再び選任され（ステップｓ１１６）、各サブグループのクラスタマネージャは、現在の票がクォーラムと等しいか、又はクォーラムを超えるか否かを判断する（ステップｓ１１７）。クォーラムディスクの故障ではなく、クォーラムディスクパスの故障しかないので、サブグループのうちの１つは、定足数を獲得してクラスタを形成できる可能性がある。したがって、予測票又は定足数票を調整する必要はない。
【００４６】
この例では、定足数は４であり、第１のサブグループ５０の現在の票は、ノード票のみ、すなわち３票を含む。これは、必要とされる定足数よりも少なく、その結果、第１のサブグループ５０は、クラスタを形成することができず、第１のサブグループのノードは、一時停止の状態を維持する（ステップｓ１０５）。第１のサブグループは、たとえクォーラムディスクとの通信がもはやなかったとしても、元のクラスタからのノードのすべてを保持する場合にはクラスタを形成することができる。
【００４７】
単一のノードを含む第２のサブグループ５１の場合、現在の票は、単一のノード票及び３票のクォーラムディスク票を含み、合計４票を含む。したがって、現在の票は、必要とされる定足数を満たす。したがって、この単一のノードは、クラスタを形成することができる。
【００４８】
図１及び図２を再び参照して、ステップＳ１０３において、クォーラムディスクの故障が検出された場合、これは、たとえクラスタ１がパーティショニングされても、他のサブグループにはクォーラムディスク票Ｖｑが割り当てられないことを第１のサブグループのクラスタマネージャに示す。したがって、予測票Ｅ及び定足数票Ｑは、クォーラムディスク票Ｖｑがもはや利用可能でないことを考慮するように調整される（ステップＳ１１１）。したがって、予測票Ｅは、
【００４９】
【数３】
2008192139.tif 000005
【００５０】
となり、定足数票Ｑは、
【００５１】
【数４】
2008192139.tif 000006
【００５２】
となる。
【００５３】
次に、サブグループにおいて利用可能な現在の票Ｃが定足数票Ｑ以上であるか否かが判断される（ステップＳ１１２）。そうである場合、クラスタの活動を再開することができる（ステップＳ１１３）。そうでない場合、現在の票が、クラスタ１が定足数を有するのに十分となるまで、クラスタの活動は一時停止を継続する。本例では、クラスタの活動は一時停止を継続する。
【００５４】
たとえば、システムオペレータによる障害のあるクォーラムディスク６の修復又は取り替えの結果として、（ステップＳ１１４で判断されるように）クォーラムディスク６が再び動作すると、票調整プロセスがクラスタマネージャによって行われ、クォーラムディスク票Ｖｑを含むように予測票Ｅの数及び定足数票Ｑの数が増加される（ステップＳ１１５）。
【００５５】
プロセスは、その後、ステップＳ１０１から再び開始される。
【００５６】
したがって、本発明の実施形態は、調停デバイスとの通信の故障の原因を求めることができる方法を提供する。その原因に応じて、ノードのサブグループがクラスタを再構築しようとすることを可能にする手順が適用され、これによって、選択されたサブグループが、自身がクラスタを形成する唯一のサブグループであることを知ってクラスタを確実に形成できるようになるだけでなく、単一のノードしか含まないサブグループが適切な状況でクラスタを形成することも可能になる。
【図面の簡単な説明】
【００５７】
【図１】本発明の一実施形態によるクラスタ配置を示す図である。
【図２】この発明の実施形態によるクラスタマネージャによって遂行される手順を示すフロー図である。
【図３】１つ又は２つ以上の故障によって複数のクラスタサブグループの形成が引き起こされた後のクラスタ配置を示す図である。
【図４】クラスタステータスが獲得されているか否かを判断するための手順の態様をより詳細に示すフロー図である。
【図５】リンクの故障によって等しい個数のノードを有する２つのサブグループの作成が引き起こされた後の図１のクラスタ配置を示す図である。
【図６】リンクの故障によって等しくない個数のノードを有する２つのサブグループの作成が引き起こされた後の図１のクラスタ配置を示す図である。
【図７】リンクの故障によって等しくない個数のノードを有する２つのサブグループの作成が引き起こされ、且つ、第１のサブグループがクォーラムディスクへのリンクの故障を受けた後の図１のクラスタ配置を示す図である。
【符号の説明】
【００５８】
１・・・クラスタ
２ａ・・・サーバ
２ｂ・・・サーバ
２ｃ・・・サーバ
２ｄ・・・サーバ
３ａ・・・ハブ
３ｂ・・・ハブ
４ａ・・・ネットワークアダプタ
４ｂ・・・ネットワークアダプタ
４ｃ・・・ネットワークアダプタ
４ｄ・・・ネットワークアダプタ
５・・・共有ストレージバス
６・・・クォーラムディスク
７ａ・・・通信リンク
７ｂ・・・通信リンク
７ｃ・・・通信リンク
７ｄ・・・通信リンク
８ａ・・・クラスタマネージャ
８ｂ・・・クラスタマネージャ
８ｃ・・・クラスタマネージャ
８ｄ・・・クラスタマネージャ
１０ａ−ｎ・・・サブグループ
１１ａ−ｎ・・・ノード
１２ａ−ｎ・・・ノード
１３ａ−ｎ・・・ノード
３０・・・サブグループ
３１・・・サブグループ
４０・・・サブグループ
４１・・・サブグループ
５０・・・サブグループ
５１・・・サブグループ
【図１】
2008192139.tif 000007
【図２】
2008192139.tif 000008
【図３】
2008192139.tif 000009
【図４】
2008192139.tif 000010
【図５】
2008192139.tif 000011
【図６】
2008192139.tif 000012
【図７】
2008192139.tif 000013
【外国語明細書】
Managing a Node Cluster
Background
A cluster is a group of interconnected processing devices, for instance a group of computers or servers, which can share data and other system resources. Each device in the cluster, also referred to as a node or a cluster member, can be configured to run one or more shared applications, resulting in a network of nodes that has increased reliability over single-node networks with respect to these applications. A cluster manager, instances of which run on each cluster member, is used to control the cluster, with the aim of ensuring that the cluster remains operational to the largest extent possible whilst preventing situations that could jeopardise the integrity of shared data.
Single-instance cluster applications run on only one cluster member at a time. To make this type of application highly available, the cluster manager provides a mechanism for starting the application on another cluster member in the event that the current member can no longer run the application. Multi-instance applications can run on multiple cluster members at the same time. A multi-instance application, by definition, is highly available because the failure of one cluster member does not affect the instances of the application running on other members.
One problem with known cluster arrangements is that, when a cluster partition occurs, for instance due to inter-node communication link failures, multiple sub-groups of nodes can be formed, each attempting to reform a new cluster having the same external identity as the original cluster. This can have serious consequences for the integrity of shared data, for instance when more than one sub-group attempts to run the same single-instance application.
In order to ensure data integrity, cluster managers have been developed that operate a voting scheme to determine which sub-group will form the new cluster and to prevent the remaining sub-groups from forming clusters. Votes are allocated to each sub-group and are based on the number of nodes in the sub-group. The number of votes required for forming the new cluster, referred to as obtaining 'quorum', is generally required to be at least half of the original votes available, such that the cluster can be reformed only by the largest sub-group(s). To cope with the situation in which two sub-groups have equal votes, referred to as the 'split-brain' scenario, an arbitration device is provided, an example of which is a quorum server, connected to all nodes in the cluster. The quorum server acts as a virtual cluster member having one vote. Therefore, following a cluster partition into two equally-sized sub-groups, the quorum server allocates its vote to one of the sub-groups, allowing that sub-group to achieve quorum and reform the cluster, while the other group is denied quorum and cannot start a cluster.
However, even in arrangements having a quorum server, for the cluster to be reformed by a sub-group, it is still required that the sub-group is made up of at least half of the nodes that were present in the original cluster. This is to ensure that, in the case that a group of nodes becomes separated from the remaining nodes in the cluster as well as the quorum server, it cannot reform the cluster unless it has a clear majority of the nodes, thus avoiding multiple sub-groups from being formed.
Accordingly, in conventional cluster arrangements, the cluster can be prevented from continuing in cases where this is not necessary, for instance in the case that the cluster is partitioned, as a result of one or more failures, into more than two sub-groups. Therefore, in conventional systems, high cluster availability may be compromised to preserve data integrity.
Brief Description of the Drawings
Embodiments of the invention will now be described by way of example with reference to the accompanying drawings, in which:
Figure 1 illustrates a cluster arrangement according to an embodiment of the present invention;
Figure 2 is a flow diagram illustrating the procedure performed by the cluster
manager according to embodiments of the invention;
Figure 3 illustrates a cluster arrangement after one or more failures has caused the formation of a plurality of cluster sub-groups;
Figure 4 is a flow diagram illustrating aspects of the procedure of Figure 3 in more detail;
Figure 5 illustrates the cluster arrangement of Figure 1 after failure of a link has caused the creation of two subgroups having an equal number of nodes;
Figure 6 illustrates the cluster arrangement of Figure 1 after failure of a link has caused the creation of two subgroups having an unequal number of nodes; and
Figure 7 illustrates the cluster arrangement of Figure 1 after failure of a link has caused the creation of two subgroups having an unequal number of nodes and the first subgroup has suffered a link failure to the quorum disk.
Detailed Description
Referring to Figure 1, a cluster 1 according to the present invention includes first, second, third and fourth servers, 2a, 2b, 2c, 2d, also referred to herein as nodes or cluster members, interconnected via first and second interconnected network hubs 3a, 3b. The first and second servers 2a, 2b are connected to the first hub 3a and the third and fourth servers 2c, 2d are connected to the second hub 3b. The first and second network hubs 3a, 3b are interconnected via a communication link 3c. Each node 2a, 2b, 2c, 2d comprises a respective network adaptor 4a, 4b, 4c, 4d for enabling connection of the nodes to the hubs 3a, 3b and a port (not shown) for connecting to a shared storage bus 5 to which a quorum disk 6 is connected. The nodes 2a - d are connected to their respective hubs 3a, 3b via respective communication links 7a - d.
In the present example, the ports are small computer system interface (SCSI) ports and the shared storage bus 5 provides a SCSI connection between the servers 2a-d and the quorum disk 6. The quorum disk is, in the present example, a hardware based Redundant Array of Inexpensive Disks (RAID), although other storage could be used, for instance software based RAID systems or any hard disk drive that can process the SCSI protocol, including, for example, Fibre Channel based disks.
The SCSI protocol provides for sense keys that can distinguish between different kinds of connection failure, such as SCSI to host system interface failure and data path failure.
It will be understood that the first, second, third and fourth servers 2a, 2b, 2c, 2d are conventional commercially available servers having all of the hardware, operating system software and application software required to perform their respective functions.
Each of the first, second, third and fourth servers 2a, 2b, 2c, 2d have stored in their memory an instance of a cluster manager application 8a - d for controlling the cluster 1.
The voting scheme by which the cluster manager determines whether a cluster can continue and by which it arbitrates between sub-groups capable of reforming the cluster requires the current votes C attained by a cluster to be greater than or equal to the quorum votes Q defined for the cluster. In the present example, each node in the cluster is allocated one node vote, making the total number of node votes, Vn, equal to the number of nodes, N, in the cluster. The quorum disk is allocated N-1 votes, Vq. The expected votes E for a particular cluster therefore becomes:
2008192139.tif 000014
Quorum votes Q are defined as
2008192139.tif 000015
where the function 'round_down' returns the result rounded down to the nearest integer.
Therefore, even a single node having access to the quorum disk can achieve quorum and form the cluster where the other N-1 nodes are down, since Q=N and the quorum disk vote Vq =N-1, so current votes C = 1 + (N-1) = N, which equals the required quorum.
Figure 2 is a flow diagram illustrating the steps performed by the cluster manager according to the present invention following a detected change in the number of current votes C in the cluster 1.
In general terms, the nodes and the quorum disk are participating entities in overall operations. There is a periodic exchange of messages between the participating entities which determines the health of the cluster. After a failure to receive a message from an entity, a cluster rebuild takes place. As part of this overall process, the current state of the cluster sub-groups is determined and based upon this appropriate decisions are taken to make one working cluster out of the various sub-groups.
Each node 2a - 2d in the cluster 1 continually monitors the number and status of other nodes in the cluster via a series of heartbeat messages sent between the nodes 2a - 2d and via flags and other information stored by the nodes 2a - 2d on the quorum disk 6. Each node can therefore determine the number of expected votes E and accordingly the quorum votes Q, as well as the current votes C in the cluster 1.
The quorum disk 6 also stores the number of expected votes E and current votes C in the cluster 1, provided by the nodes 2a - 2d, such that the nodes can ensure that they agree on these values.
The expected number of votes E is not altered unless it is reliably determined that the quorum disk has failed.
Each node 2a - 2d, under the control of the cluster manager running on the node, can therefore determine when a reduction in the number of current votes C occurs, indicating a failure (step s101). In this event, cluster activity is suspended and the cluster rebuild procedure is triggered (step s102).
There are two main types of failure. The first type includes failure of a link or node, for example as a result of a kernel hang or complete kernel failure in a node or any number of other cluster communication, hardware or software failures.
For example, in the system illustrated in Figure 1, the failure may be a failure in the communications link 3c interconnecting the first and second network hubs 3a, 3b, resulting in a partition of the cluster 1 into a first sub-group comprising the first and second servers 2a, 2b and a second sub-group comprising the third and fourth servers 2c, 2d.
As another example, it may be failure of the link 7d between the second hub 3b and the fourth node 2d, resulting in a partition of the cluster 1 into a first sub-group comprising the first, second and third servers 2a, 2b, 2c and a second sub-group comprising just the fourth server 2d.
These alternative examples will be considered in further detail below.
The second main type of failure is quorum disk failure, which has two further subtypes. In the first subtype, the quorum disk is reliably known to have failed. In the second subtype, there is an apparent quorum disk failure, but it is not reliably known that the quorum disk has failed - for example, a link 5 to the quorum disk fails.
By virtue of the SCSI connection 5 between each node 2a - d in the sub-group 30 and the quorum disk 6, each node 2a - d can determine whether the quorum disk 6 has failed or, alternatively, whether the communication path 5 with the quorum disk 6 has failed. Returning to the flowchart of Figure 2, it is firstly determined whether the quorum disk 6 has failed (step S103). If the quorum disk 6 has not failed, it is then determined whether the communication path 5 with the quorum disk has failed (step S104).
In the event that the failure detected is of type 1, in other words that there is neither a quorum disk nor a quorum path failure, then this indicates that the current cluster votes C have changed as a result of a change in the number of nodes in the cluster 1, rather than a failure in communications with the quorum disk 6.
Figure 3 is a diagram illustrating the general case of a system in which one or more failures have occurred, partitioning the system into a number of subgroups 10a - n, each subgroup having a plurality of nodes 11a - n, 12a - n and 13a - n respectively, all of which continue to be separately in communication with the quorum disk 6. In this case, the cluster manager running on the first group of nodes 11a - n determines that a cluster partition into multiple subgroups may have occurred and therefore arbitration is required to determine which subgroup 10a - n should reform the cluster 1. The cluster manager applications running on the nodes 11a - n in the first subgroup together assign a node in their sub-group 10a as the group leader of the subgroup 10a or determine which node is the current group leader if a group leader has been previously assigned (step 106). For example, the node that detected the failure becomes the group leader.
Corresponding steps are taken in the other subgroups and the group leader for each subgroup 10a - n publishes the current votes C allocated to that sub-group on the quorum disk (step S107), checks the results published by other sub-groups on the quorum disk 6 (step S108) and determines whether their respective current votes C are enough for the sub-group to form the cluster (step S109). If so, the sub-group resumes cluster activities (step S110) and the process is restarted from step S101. If, on the other hand, a subgroup 10a - n cannot attain cluster status, the nodes 11a - n in the sub-group 30 continue to suspend all cluster activities until such a time as quorum can be attained (step S105). If a quorum disk path failure is detected at step s104, then one or more subgroups 11a - n would no longer have the quorum vote Vq. In this case, since the quorum disk 6 is still operational, one of the remaining subgroups may still be able to attain cluster status. In this case, the nodes affected by the quorum disk path failure would remain suspended until they can achieve quorum (step S105), for example once a path repair has been effected.
The procedure for determining if cluster status has been attained (step s109) is explained in more detail with reference to Figure 4, and is further illustrated with reference to Figures 5 and 6, illustrating the examples of link failure mentioned above.
The first example referred to above is illustrated in Figure 5, where as a result of failure of link 3c, two subgroups 30, 31 remain, each in communication with the quorum disk. In this case, assuming nodes 2a and 2c are nominated as group leaders, the cluster managers 8a, 8c of the group leader nodes of each subgroup temporarily add the quorum disk votes Vq to the votes of each subgroup as published on the quorum disk (step s120).
In this case, the number of nodes N in the cluster 1 before the communication failure was 4 and therefore the expected cluster votes, E, is 7 (N plus Vq), where the quorum disk is assigned 3 votes (Vq) and the number of quorum votes Q is 4. The current votes C (node votes + quorum disk votes) before the communication failure was 7, and after the communication failure the current votes C for each of the first and second sub-groups is reduced to 5.
So in this example, adding the quorum disk votes to the sum of the node votes for each subgroup results in a total of 5 votes for each group. The cluster manager for each subgroup determines whether this number of votes exceeds the quorum votes Q (step s121). If it does not, the subgroup cannot form the cluster (step s105 in Figure 2). If it does, then the cluster manager for each subgroup compares the number of votes with those for the other subgroups (step s122). If it has more votes than any other subgroup, it forms the cluster (step s123) and resumes cluster activity (step s110). If it has less votes than another subgroup, the nodes remain suspended (step s105 in Figure 2).
If it has the same number of votes as another subgroup (this being the highest number of votes), it decides based upon its algorithm which group to select and selects this group (step s124) and resumes cluster activity (step s110). One simple algorithm is that the subgroup which first published is selected.
However, other algorithms may also be used to perform this selection.
In the example illustrated in Figure 5, the number of quorum votes Q is exceeded by both subgroups. Both subgroups also have equal votes, so either of these subgroups can be selected to form the cluster.
Applying the above algorithm to the second example illustrated in Figure 6, one subgroup 40 has three nodes while the other 41 has only one node. The same procedure applies as above, with 3 votes being added to the first subgroup and three to the second subgroup, giving each a quorum. However, the first subgroup has a total of 6 votes (3 node votes + Vq) as opposed to only 4 for the second subgroup (1 node vote +Vq), so the first subgroup forms the cluster while the second subgroup shuts down.
Figure 7 illustrates a third example in which there is a path failure between the first subgroup 50 and the quorum disk 6. In this example, referring to Figure 2, following detection of a change in current votes, it is determined at step s104 that there is a quorum path failure. A group leader is again assigned for each subgroup (step s116) and the cluster manager for each subgroup determines whether the current votes equal or exceed the quorum (step s117). Since there has only been a quorum disk path failure as opposed to a quorum disk failure, it is possible that one of the subgroups can attain quorum and form the cluster. There is therefore no need to adjust the expected or quorum votes.
In this example, the quorum is 4, and the current votes for the first subgroup 50 comprise the node votes only, namely 3 votes. This is less than the required quorum so the first subgroup 50 cannot form the cluster and its nodes remain suspended (step s105). The first subgroup could form the cluster in the event that it retained all of the nodes from the original cluster, even if it was no longer in communication with the quorum disk.
For the second subgroup 51, comprising a single node, the current votes comprise a single node vote and the quorum disk vote of 3, totalling four and therefore meeting the required quorum. The single node can therefore form the cluster.
Referring again to Figures 1 and 2, if, at step S103, quorum disk failure was detected, this indicates to the cluster manager of the first subgroup that, even if the cluster 1 is partitioned, other sub-groups would not be allocated the quorum disk votes Vq. The expected votes E and quorum votes Q are therefore adjusted to take account of the fact that the quorum disk vote Vq will no longer be available (step S111). Accordingly, the expected votes, E, becomes
2008192139.tif 000016
and quorum votes, Q, become
2008192139.tif 000017
.
It is then determined whether the current votes C available in the sub-group are equal to or greater than the quorum votes Q (step S112). If so, cluster activity can be resumed (step S113). Otherwise, cluster activity continues to be suspended until the current votes are enough for the cluster 1 to have quorum, which it does in the present example.
Once the quorum disk 6 is again operational, for instance as a result of repair or replacement of a faulty quorum disk 6 by a system operator (as determined at step S114), a vote adjust-up process is performed by the cluster manager to increase the number of expected votes E and quorum votes Q to include the quorum disk vote Vq (step S115).
The process is then be restarted from step S101.
Embodiments of the present invention therefore provide a method by which the cause of a failure in communications with an arbitration device can be determined. Depending on the cause, procedures are applied that enable subgroups of nodes to seek to rebuild the cluster, ensuring not only that a selected subgroup can form a cluster knowing that it will be the only subgroup forming the cluster, but also allowing a subgroup comprising only a single node to form the cluster in the appropriate circumstances.
Claims
1.     A method of managing a cluster of nodes, the cluster comprising a plurality of groups of nodes, each node being associated with a vote, wherein each group is in communication with an arbitration device, the arbitration device being associated with a number of votes dependent on the number of nodes in the cluster, the method comprising:
for each group, adding the votes associated with the arbitration device to the votes associated with the group;
determining which of the groups of nodes has the greatest number of votes; and
assigning the group with the greatest number of votes to function as the cluster.
2.    A method according to claim 1, wherein in the event that more than one group comprises the group having the greatest number of votes, selecting one of the groups to function as the cluster.
3.    A method according to claim 1 or 2, wherein the act of determining which of the groups of nodes has the greatest number of votes is carried out for groups that that meet or exceed a predetermined quorum.
4.    A method according to claim 3, wherein the predetermined quorum in N, where N is the total number of nodes in the cluster.
5.    A method according to any one of the preceding claims, wherein each node is associated with one vote and the arbitration device is associated with N-1 votes, where N is the total number of nodes in the cluster.
6.    A method of managing a cluster of nodes, at least one node in the cluster being connectable, via a communications path, to an arbitration device for use in resolving conflicts between nodes in the formation of the cluster, the method comprising:
detecting a failure in communications between the at least one node and the arbitration device; and
determining whether the failure is a failure of the arbitration device or a failure in the communications path.
7.    A method according to claim 6, further comprising, in the event that the failure is a failure in the communication path, determining whether the number of votes associated with each subgroup of nodes formed as a result of the failure reaches a predetermined threshold.
8.    A method according to claim 7, comprising suspending one or more activities of the at least one node in the subgroup of nodes when the number does not reach the predetermined threshold.
9.    A method according to claim 7 or 8, wherein the number of votes associated with a subgroup of nodes that cannot access the arbitration device does not include votes associated with the arbitration device.
10.    A method according to claim 7, 8 or 9, wherein the number of votes associated with a subgroup of nodes that can access the arbitration device includes votes associated with the arbitration device.
11.    A method according to any one of claims 6 to 10, wherein the cluster is associated with a threshold that includes a value associated with the arbitration device, the method comprising:
in response to a determination that the failure is a failure of the arbitration device,
adjusting the threshold by omitting the value associated with the arbitration device.
12.    A method according to claim 11, further comprising
determining a number of nodes in the cluster after the failure;
allocating to the cluster a value dependent on the determined number of nodes in the cluster after the failure; and
comparing the allocated value with the adjusted threshold.
13.    A method according to claim 12, further comprising:
resuming operation of the cluster if the allocated value is greater than or equal to the adjusted threshold.
14.    A method according to any one of claims 11 to 13, comprising adjusting the threshold to take account of the value associated with the arbitration device in the event that the arbitration device becomes operational.
15.    A method according to any one of claims 11 to 14, wherein the arbitration device comprises a quorum disk and the threshold comprises a quorum value that determines the number of nodes required to form a cluster.
16.    A method according to any one of claims 6 to 15, comprising determining that the failure results in the cluster being partitioned into a plurality of subgroups, each of the subgroups being in communication with the arbitration device.
17.    A method according to claim 16, wherein one of the nodes in a subgroup sends the current votes for the subgroup to the arbitration device so that the current votes are accessible to all of the subgroups.
18.    A method according to claim 17, wherein each of the subgroups determines from the current votes for the other subgroups whether it should operate as the cluster.
19.    A method according to claim 18, comprising adding votes associated with the quorum disk to the votes associated with each of the subgroups to determine which of the subgroups is to operate as the cluster.
20.    A system for managing a cluster of nodes, the cluster comprising a plurality of groups of nodes, each node being associated with a vote, the system further comprising an arbitration device, the arbitration device being associated with a number of votes dependent on the number of nodes in the cluster, each node further being associated with a cluster manager, one of the cluster managers for each group being operable:
if the group is in communication with the arbitration device, to determine whether the group has the greatest number of votes, including the votes of the arbitration device;
if the arbitration device is operative, but the group is not in communication with the arbitration device, to determine whether the group meets the quorum without adjusting the quorum; and
if the arbitration device is not operative, to determine whether the group meets the quorum after adjusting the quorum.
Abstract
Managing a Node Cluster
A system for managing a cluster of nodes, the cluster comprising a plurality of groups of nodes, each node being associated with a vote, the system further comprising an arbitration device, the arbitration device being associated with a number of votes dependent on the number of nodes in the cluster, each node further being associated with a cluster manager, one of the cluster managers for each group being operable: if the group is in communication with the arbitration device, to determine whether the group has the greatest number of votes, including the votes of the arbitration device;     if the arbitration device is operative, but the group is not in communication with the arbitration device, to determine whether the group meets the quorum without adjusting the quorum; and if the arbitration device is not operative, to determine whether the group meets the quorum after adjusting the quorum.
2008192139.tif 000018
2008192139.tif 000019
2008192139.tif 000020
2008192139.tif 000021
2008192139.tif 000022
2008192139.tif 000023
2008192139.tif 000024