JP2006114040A - コンピュータクラスタのノードのフェールオーバー範囲 - Google Patents

Abstract

【課題】クラスタが障害の対策を取る自動的な動作をクラスタ管理者が管理する方法を提供する。
【解決手段】フェールオーバー範囲は、コンピュータクラスタ内のノードの集まりを含む。リソースグループ（アプリケーションプログラムなど）は、１つ以上のフェールオーバー範囲に関連付けられる。ノードが故障した場合、ホストされているリソースグループは、１番目の関連付けられたフェールオーバー範囲から開始して順番に、各リソースグループの関連のフェールオーバー範囲内で識別されたノードにのみフェールオーバーする。第１のフェールオーバー範囲のノードにフェールオーバーできない場合、次の関連のフェールオーバー範囲内に表されるノードに試行され、これは手動の操作を必要とする場合がある。フェールオーバー範囲は、クラスタランタイムによって自動的に管理することができる。
【選択図】図４

Description

本発明は一般に、クラスタ化されたコンピューティングノードに関し、より詳細には、アプリケーションまたはクラスタのホストノードの障害の処理に関する。

クラスタとは、サーバアプリケーションプログラムなどのリソースへのアクセスを提供する複数のノードとして構成された、１組の相互接続されたコンピュータシステムサーバである。サーバクラスタを有する１つの理由は、複数のリンクされたコンピュータシステムが、コンピュータ処理の可用性および信頼性を大幅に向上させるとともに、負荷の分散を介して、より大きな処理能力、速度、および、その他のリソースを有するようにするためである。

クラスタにおける可用性および信頼性に関して、１つのノードまたはホストされたアプリケーションが故障した場合、そのリソースは、残存している他のノードにフェールオーバーする。この場合、一般に、フェールオーバーとは、他のノードが、現在故障しているノードによってこれまでに提供されていたものに対応するホストアプリケーションを提供することを意味する。障害のタイプには、コンピュータシステムのクラッシュ、ノード間の通信リンクの切断、メンテナンスなどのための故意のシャットダウン、誤って電源または通信ケーブルを抜くなどの不慮のシャットダウンなどがある。

故障したアプリケーションが他のノードで正しく再起動するように、何らかの制御された方法で障害を処理するために、好ましいノードのリストに基づいて、リソースのグループ（それぞれがリソースグループと呼ばれ、フェールオーバーに関して単一の単位として管理される、アプリケーションプログラムなどの１つまたは複数のリソース、およびネットワーク名、ＩＰアドレスなどの関連のリソースの集まり）が好ましいノードにフェールオーバーできるようにすることを試みた。しかし、これによって、いくつかのノードが手に負えなくなる傾向にあった。というのは、多くのリソースグループは、その好ましいノードのデフォルトの構成が同じであったからである。この問題を回避するために、現在のクラスタ化技術は、複数の残存するノードが使用可能であるとき、あるリソースグループの（少なくともグループをホストすることができるノードの中の）好ましい所有者リストの構成が提供されていない場合、ノードが、故障したノードの多くのリソースグループを引き受けすぎることによって手に負えなくならないように、乱数に基づくアルゴリズムを使用して、リソースグループの宛先ノードを選択する。

コンピューティング能力／速度に関して、クラスタにおける物理的に近接したコンピューティングシステムは、一般に、非常に高速の帯域幅ネットワーク接続によってリンクされている。しかし、すべてのクラスタノードが物理的に近接しているわけではない。企業（特に大企業）は、こうした近接して相互接続されたクラスタ化ノードの２つ以上のサブセットを、比較的大きい地理的距離だけ互いに引き離すことが多いからである。この目的は障害対策であり、障害の理由がノードの実際の障害であろうと、ノードのそのサブセットと他の離れたノードとの間の送信媒体の切断であろうと、相互接続されたノードの物理的に近接したサブセット全体がまとめて故障するおそれのあるハリケーン、火災、地震などの場合でも動作するノードを、いくつか備えておくようにする。

地理的分離による障害対策の問題は、近接して相互接続されたノードの一方のサブセットと他方のサブセットとの間の通信帯域幅がサブセット内の通信帯域幅よりはるかに低いことである。その結果、クラスタ管理者の中には、必ずしもリソースグループを１つの近接して相互接続されたサブセットからもう一方に自動的にフェールオーバーさせたいわけではない（サブセット全体が故障しない限り）者もいる。というのは、低帯域幅接続が与えられている場合、１つのノードからのリソースをフェールオーバーするにも、かなりの時間および費用がかかるからである。代わりに、クラスタ管理者は、リソースグループを接近して相互接続されたノードのみにフェールオーバーさせることを好むことが多い。サブセット全体が故障した場合、一部の管理者は、その原因を推定し、可能な場合は問題（ケーブルの抜けなど）を修正し、必要に応じて、リソースグループの手動のみのフェールオーバーを行うことを好む。これは、フェールオーバーされたリソースグループを受け入れるために、他方のサブセットの何らかの再構成を必要とする場合がある。さらに別の管理者の中には、サブセット全体が故障した場合、少なくともある程度、フェールオーバーを自動にさせたい者もいる。さらに、複数のアプリケーションをホストするクラスタである統合クラスタ（consolidation cluster）を処理するとき、多くの管理者は、様々な構成要素から成るアプリケーションをホストすることができるノードの組を制限することを望む。

しかし、以前実施されていた上記のランダムフェールオーバー機構、および他の以前の機構では、管理者は、クラスタを所望の方法でフェールオーバー用に構成することはできない。実際に、ランダム機構では、リソースグループをフェールオーバーするとき、物理的に近接したノードと物理的に離れたノードとの間の区別がない。

クラスタが障害の対策を取る自動的な動作を、クラスタ管理者が管理する柔軟な方法が必要である。

簡単に言えば、本発明は、クラスタの識別されたノードのサブセットをそれぞれ含むフェールオーバー範囲（failover scopes）が画定され、リソースグループを１つまたは複数のフェールオーバー範囲の順序付きリストに関連付けることができるシステムおよび方法を対象とする。フェールオーバーが行われるとき、各リソースグループは、そのフェールオーバー範囲内に列挙されている残存しているノードに自動的にフェールオーバーする。成功するまで、順序に基づいて、次のフェールオーバー範囲内の任意のノードにフェールオーバーを試行する前に、まず、現在アクティブなフェールオーバー範囲内の各ノードにフェールオーバーが試行される。

第１のフェールオーバー範囲内のノードが（例えば何も残存していないなど）フェールオーバーを受け入れることができない場合、故障がなくなるまで、その次のフェールオーバー範囲内に列挙されているノードに自動的にフェールオーバーするようにリソースグループを設定することができる。管理者に、別のフェールオーバー範囲のノードへのこうした自動的なフェールオーバーを防ぐ能力を与えるために、その次に列挙されているフェールオーバー範囲への自動フェールオーバーを防ぐ手動設定（手動／自動フラグなど）が設定される。リソースグループに関連付けられているフェールオーバー範囲の対ごとにこうしたフラグが１つ存在（例えば、３つのフェールオーバー範囲に対して２つのフラグがあり、１つは第１のフェールオーバー範囲から第２のフェールオーバー範囲への手動または自動の遷移を設定するもの、１つは第２のフェールオーバー範囲から第３のフェールオーバー範囲への手動または自動の遷移を設定するものなど）していても、リソースグループ全体についてこうしたフラグが１つ存在していてもよい。フラグは、デフォルトでは手動であり、管理者によって個々に設定したり、クラスタ全体のリソースグループに対してまとめて設定したりすることができる。

フェールオーバー範囲は、サイトと呼ばれる地理ごとに引き離されたノードのサブセットそれぞれに設定することができる。各サイトは一般に、クラスタの１つのサブセットを構成する、近接して（比較的高帯域幅）相互接続されたノードを含む。しかし、フェールオーバー範囲は、１つのサイトに正確に対応している必要はなく、したがってフェールオーバー範囲は、複数のサイトにまたがっていてもよい。

あるいは、フェールオーバー範囲は、例えば、２つ以上のノードを有するサイト内の１つのノードなど、サイトのいくつかのサブセットのみを含むように定義することができる。これによって管理者は、例えば、様々な構成要素から成るアプリケーションプログラムなど、任意のリソースグループをホストすることができる１組のノードを制限することができる。

ノードがサイトに追加されると、新しいノードは、ノードをクラスタに追加するよう求めるセットアッププログラムを実行することの一環として、自動的に認識される。クラスタソフトウェアがそのように構成されている場合、距離の検出に基づく自動プロセスは、サイトに対応するフェールオーバー範囲にそのノードを追加することができる。このように、管理者は、新しいノードのためにフェールオーバー範囲を更新する必要はない。しかし、自動プロセスが新しいノードをフェールオーバー範囲に関連付けるか、管理者が新しいノードを１つの（または複数の）フェールオーバー範囲に手動で追加するかに関係なく、そのフェールオーバー範囲に関連付けられているリソースグループは、比較的多数である可能性があり、新しいノード上で稼働させることができるように設定する必要はない。

他の利点は、以下の詳細な説明を図面と併せ読めば明らかになる。

（例示的動作環境）
図１は、本発明を実施できる適切なコンピューティングシステム環境１００の例を示す。コンピューティングシステム環境１００は、適切なコンピューティング環境の一例にすぎず、本発明の使用または機能の範囲に関する限定を示唆するものではない。また、コンピューティング環境１００を、動作環境１００の例に示した構成要素のいずれか１つ、またはその組合せに関連する任意の依存性または必要条件を有しているものと解釈すべきではない。

本発明は、他の多くの汎用または専用コンピューティングシステム環境または構成で動作可能である。本発明との使用に適し得るよく知られているコンピューティングシステム、環境、および／または構成の例には、それだけには限定されないが、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドまたはラップトップ装置、タブレット装置、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能家庭用電化製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記の任意のシステムまたは装置を含む分散コンピューティング環境などがある。

本発明は、コンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能命令の一般的な文脈で説明することができる。一般にプログラムモジュールは、特定のタスクを実行する、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、構成要素、データ構造などを含む。また、本発明は、タスクが通信ネットワークによってリンクされているリモート処理装置によって実行される分散コンピューティング環境でも実施することができる。分散コンピューティング環境では、プログラムモジュールを、メモリ記憶装置を含むローカルおよび／またはリモートのコンピュータ記憶媒体に置くことができる。

図１を参照すると、本発明を実施するシステムの例は、汎用コンピューティング装置をコンピュータ１１０の形で含んでいる。コンピュータ１１０の構成要素は、それだけには限定されないが、処理ユニット１２０、システムメモリ１３０、およびシステムメモリを含む様々なシステム構成要素を処理ユニット１２０に結合するシステムバス１２１を含み得る。システムバス１２１は、様々なバスアーキテクチャのうちの任意のものを使用するメモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含むいくつかのタイプのバス構造のうちどんなものでもよい。こうしたアーキテクチャには、それだけには限定されないが一例として、ＩＳＡ（Industry Standard Architecture）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、拡張ＩＳＡ（ＥＩＳＡ）バス、ＶＥＳＡ（Video Electronics Standards Association）ローカルバス、およびメザニンバスとしても知られているＰＣＩ（Peripheral Component Interconnect）バスなどがある。

コンピュータ１１０は、一般に様々なコンピュータ読み取り可能記憶媒体を含む。コンピュータ読み取り可能記憶媒体は、コンピュータ１１０からアクセスできる使用可能な任意の媒体とすることができ、揮発性および不揮発性の媒体、取外し可能と取外し不可能の媒体を含む。コンピュータ読み取り可能記憶媒体は、それだけには限定されないが一例として、コンピュータ記憶媒体および通信媒体を含み得る。コンピュータ記憶媒体には、コンピュータ読み取り可能命令、データ構造、プログラムモジュール、その他のデータなど、情報を記憶するための任意の方法または技術で実施される揮発性および不揮発性の取外し可能と取外し不可能の媒体がある。コンピュータ記憶媒体には、それだけには限定されないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたはその他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）またはその他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置またはその他の磁気記憶装置、または所望の情報の格納に使用でき、コンピュータ１１０からアクセスできるその他の任意の媒体などがある。通信媒体は一般に、コンピュータ読み取り可能命令、データ構造、プログラムモジュール、またはその他のデータを搬送波またはその他の移送機構などの被変調データ信号に組み込む。これには任意の情報配送媒体がある。「被変調データ信号」という用語は、信号に情報を符号化するように１つまたは複数のその特性が設定または変更された信号を意味する。通信媒体には、それだけには限定されないが一例として、有線ネットワーク、直接配線された接続などの有線媒体、および音響、無線周波数、赤外線、その他の無線媒体などの無線媒体がある。また、上記のどんな組合せでもコンピュータ読み取り可能記憶媒体の範囲内に含まれるものとする。

システムメモリ１３０は、読み取り専用メモリ（ＲＯＭ）１３１やランダムアクセスメモリ（ＲＡＭ）１３２など、揮発性および／または不揮発性メモリの形のコンピュータ記憶媒体を含む。基本入出力システム１３３（ＢＩＯＳ）は、例えば起動中など、コンピュータ１１０内の要素間での情報の転送を助ける基本ルーチンを含み、一般にＲＯＭ１３１に格納されている。ＲＡＭ１３２は一般に、処理ユニット１２０から直接アクセス可能な、および／または処理ユニット１２０が現在処理しているデータおよび／またはプログラムモジュールを含む。図１は、それだけには限定されないが一例として、オペレーティングシステム１３４、アプリケーションプログラム１３５、その他のプログラムモジュール１３６、およびプログラムデータ１３７を示している。

コンピュータ１１０は、その他の取外し可能／取外し不可能、揮発性／不揮発性コンピュータ記憶媒体を含むこともできる。一例にすぎないが、図１は、取外し不可能な不揮発性磁気媒体から読み取り、あるいはそこに書き込むハードディスクドライブ１４１、取外し可能な不揮発性磁気ディスク１５２から読み取り、あるいはそこに書き込む磁気ディスクドライブ１５１、およびＣＤ−ＲＯＭやその他の光媒体など、取外し可能な不揮発性光ディスク１５６から読み取り、あるいはそこに書き込む光ディスクドライブ１５５を示している。例示的動作環境で使用できるその他の取外し可能／取外し不可能、揮発性／不揮発性コンピュータ記憶媒体には、それだけには限定されないが、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、半導体ＲＡＭ、半導体ＲＯＭなどがある。ハードディスクドライブ１４１は一般に、インターフェース１４０などの取外し不可能なメモリインターフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は一般に、インターフェース１５０などの取外し可能なメモリインターフェースによってシステムバス１２１に接続される。

上述し、図１に示したドライブおよびその関連のコンピュータ記憶媒体は、コンピュータ読み取り可能命令、データ構造、プログラムモジュール、およびその他のデータの記憶領域をコンピュータ１１０に提供する。図１では例えば、ハードディスクドライブ１４１は、オペレーティングシステム１４４、アプリケーションプログラム１４５、その他のプログラムモジュール１４６、およびプログラムデータ１４７を記憶するものとして示されている。これらの構成要素は、オペレーティングシステム１３４、アプリケーションプログラム１３５、その他のプログラムモジュール１３６、およびプログラムデータ１３７と同じであっても、異なっていてもよいことに留意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、その他のプログラムモジュール１４６、およびプログラムデータ１４７は少なくとも異なるコピーであることを示すために、本明細書ではそれらに異なる番号を付している。ユーザは、タブレットまたは電子デジタイザ１６４などの入力装置、マイクロフォン１６３、キーボード１６２、および一般にマウス、トラックボール、またはタッチパッドと呼ばれるポインティング装置１６１などの入力装置を介して、コマンドおよび情報をコンピュータ１１０に入力することができる。図１には示していないが、その他の入力装置には、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、スキャナなどがある。これらおよびその他の入力装置は、しばしばシステムバスに結合されているユーザ入力インターフェース１６０を介して処理ユニット１２０に接続されるが、パラレルポート、ゲームポート、ユニバーサルシリアルバス（ＵＳＢ）などその他のインターフェースおよびバス構造で接続してもよい。モニタ１９１またはその他のタイプの表示装置もまた、ビデオインターフェース１９０などのインターフェースを介してシステムバス１２１に接続される。モニタ１９１は、タッチ画面パネルなどに一体化することもできる。モニタおよび／またはタッチ画面パネルは、タブレット型パーソナルコンピュータなど、コンピューティング装置１１０が組み込まれるハウジングに物理的に結合することができることに注意されたい。さらに、コンピューティング装置１１０などのコンピュータは、出力周辺インターフェース１９４などを介して接続できるスピーカ１９５、プリンタ１９６などのその他の周辺出力装置を含むこともできる。

コンピュータ１１０は、リモートコンピュータ１８０などの１つまたは複数のリモートコンピュータへの論理接続を使用して、ネットワーク化された環境で動作することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置、またはその他の一般のネットワークノードでよく、一般にコンピュータ１１０に関連して上述した多くまたはすべての要素を含むが、図１にはメモリ記憶装置１８１のみを示している。図１に示した論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１および広域ネットワーク（ＷＡＮ）１７３を含むが、他のネットワークを含んでいてもよい。こうしたネットワーキング環境は、オフィス、企業規模のコンピュータネットワーク、イントラネット、およびインターネットではごく一般的である。

ＬＡＮネットワーキング環境で使用する場合、コンピュータ１１０は、ネットワークインターフェースまたはアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境で使用する場合、コンピュータ１１０は一般に、モデム１７２、またはインターネットなどＷＡＮ１７３を介して通信を確立するその他の手段を含む。モデム１７２は、内蔵のものでも外付けのものでもよく、ユーザ入力インターフェース１６０またはその他の適切な機構を介してシステムバス１２１に接続することができる。ネットワーク化された環境では、コンピュータ１１０に関連して示したプログラムモジュール、またはその一部をリモートメモリ記憶装置に格納することができる。図１は、それだけには限定されないが一例として、リモートアプリケーションプログラム１８５をメモリ装置１８１上に存在するものとして示している。図示したネットワーク接続は例であり、コンピュータ間の通信リンクを確立するその他の手段を使用してもよいことは理解されよう。

（フェールオーバー範囲）
本発明は一般に、（例えばコンピュータノードの障害による）リソースグループのフェールオーバーが、管理者によって予め決定されている方法で処理されるシステムおよび方法を対象としている。理解されるように、本発明を実施する多数の方法が実行可能であり、本明細書では代替の一部のみを説明する。例えば、本発明は、簡単なリストの形式で保持されているフェールオーバー範囲情報に基づいて、リソースグループがどのノードにフェールオーバーされるかを決定するリーダーとして動作する、クラスタノードを参照して以下に説明するが、その他の機構を実施することもできる。例えば、ノードがリソースグループを得ようとすることは、フェールオーバー範囲のデータは１つの要因にすぎず、実行可能な代替である。したがって、本発明は、本明細書で使用されているフェールオーバー範囲の任意の特定の例に限定されず、むしろフェールオーバーの概念を、一般にコンピュータ処理において利益および利点をもたらす様々な方法で使用することができる。

図２を参照すると、クラスタ２０２内のノードＮ１〜Ｎ８の構成を示しており、これらのノードは、「西」サイト２０４および「東」サイト２０６という、２つの地理的サイトに分けられている。一般的に、サイト内において、ノード間の通信媒体（ノードＮ１〜Ｎ４およびＮ５〜Ｎ８を接続する斜めの実線として示している）は、ノードＮ４とＮ５との間の破線などの、異なるサイトのノード間の接続に比べて非常に高帯域幅である。例えば、サイト内のノードは、高速ネットワーク接続を介して接続することができ、離れたサイトのノードは、インターネット上で仮想プライベートネットワークを介して接続することができる。一般に、一方のサイトはもう一方のサイトから地理的に離れているが、ノード間の実際の物理的な距離に関係なく、帯域幅の問題などのその他の要因に基づいて、サイトを定義することが有用であり得る。

本発明の一態様によれば、ノードＮ１〜Ｎ４の一方の組に第１のフェールオーバー範囲（ＦＳ１）２０８が定義され、ノードＮ５〜Ｎ８のもう一方の組に第２のフェールオーバー範囲（ＦＳ２）２１０が定義される。どのノードがどのフェールオーバー範囲に属するかに関する定義は、管理者または自動プロセス（後述）によって行うことができる。図２の例で、ノード識別に関して、フェールオーバー範囲２０８および２１０は、それぞれサイト２０４および２０６に正確に対応する。しかし、図５および図６を参照して後述するように、これは必要条件ではなく、実際は、フェールオーバー範囲は複数のサイトにまたがっていてもよく、および／またはフェールオーバー範囲は１つのサイトのすべてのノードより少ないノードを含んでいてもよい（これが一般的であり得る）。

一般に、各リソースグループは、少なくとも１つのフェールオーバー範囲に関連付けられる。図３は、図２のフェールオーバー範囲ＦＳ１およびＦＳ２のノード識別を示しており、各フェールオーバー範囲識別は、例えばデータ構造３０２で保持されているものなどの、そのフェールオーバー範囲に属するノード識別のリストを有する。また、別のデータ構造３０４に保持されているものなどの、それらの関連するフェールオーバー範囲を列挙している１組のリソースグループ識別子ＲＧ１〜ＲＧｎの例も示されている。

本発明の一態様によれば、リソースグループは、その関連するフェールオーバー範囲に列挙されたノードに、フェールオーバーされるだけである。一実装形態では、リソースグループは、フェールオーバー範囲と関連がある必要はない。その場合、リソースグループをクラスタ内の任意のノードにフェールオーバーすることができる（その他の問題のためにそのノードがリソースグループを受け入れることができる限り）。（例えばクラスタの非常に強力なノード上でしか稼働させることができない多消費型プログラムなどで）リソースグループがフェールオーバーされるのを防ぐために、リソースグループを、単一のノードのみを含むフェールオーバー範囲に関連付けることができる。そのノードが故障すると、リソースグループをフェールオーバーするその他のノードがなく、自動化再起動プロセスまたは管理者は、ノードを再起動させ、および／またはそのリソースグループのためにフェールオーバー範囲を再構成する必要がある。リソースグループが稼働しているノード（例えばノードＸ）を含まないフェールオーバー範囲を有することは（起こりそうにはないが）可能であり、次いで別のノード（例えばノードＹ）へのフェールオーバーを行うことができるが、管理者が手動で操作しない限り、後でそれが前に稼働していたノード（ノードＸ）へは戻らないことに留意されたい。これによって、管理者または起動プロセスは、フェールオーバー範囲に列挙されていなかったノード上でリソースグループを開始する必要がある。

いずれにしても、フェールオーバーされるべきリソースグループが複数のフェールオーバー範囲に関連付けられている場合、フェールオーバーを試行するフェールオーバー範囲の順序がある。例えば、図３のデータ構造３０４を参照すると、リソースグループＲＧ１は、図２の第１のフェールオーバー範囲（ＦＳ１）２０８内のノードに最初にフェールオーバーするように設定され、そのフェールオーバー範囲内のノードがどれもフェールオーバーを処理できない場合のみ、第２のフェールオーバー範囲（ＦＳ２）２１０内のノードへのフェールオーバーが試行される。言い換えれば、優先順位は複数のフェールオーバー範囲にわたって維持される。一代替では、フェールオーバー範囲の全ノードが故障した場合、現在の負荷、リソースグループをホストする能力、帯域幅、およびその他の測定基準など、順序以外の何らかの基準に基づいて、そのグループに関連付けられている別のフェールオーバー範囲から別のノードを選択することができる。リソースグループがフェールオーバーされるノード自体が故障した場合、フェールオーバーマネージャは、まず、（その範囲内のすべてのノードが故障している可能性はあるが）そのフェールオーバー範囲内のその他のノードへ、そのグループのフェールオーバーを試行することに留意されたい。

範囲内のフェールオーバーが自動であり、（一般に高可用性レベルを維持する目的のため）、しかし、第２の範囲にフェールオーバーする前に、フラグ（図３で「手動」または「自動」と表すが、最小単一ビットしか必要としない値）は、複数のフェールオーバー範囲にわたる所与のリソースグループについて、フェールオーバーが手動であるか自動であるかを制御することに留意されたい。つまり、フラグが手動に設定されている場合、リソースグループをオンラインで残存するフェールオーバー範囲上に持って行くために、手動の操作が必要となる。さらに、複数のフェールオーバー範囲は順序付けられているが、フェールオーバー範囲内のノードのリストは、順序付ける必要はないことに留意されたい。代わりに、ノードを無作為に、または、負荷平衡化基準に基づくなど、その他の適切な方法で選択することができる。しかし、管理者は、例えばノードの順序に従って選択し、次いで順序ごとに異なるフェールオーバー範囲を持つことなどによって、フェールオーバー範囲内の所望のノードの順序を設定することができる。例えば、順序付けられたノード選択がアクティブの場合、ＦＳ１は、図３において、Ｎ１、Ｎ４、Ｎ３、Ｎ２と順序付けられるように示されており、新しいフェールオーバー範囲ＦＳ１３（図示せず）は、同じノードＮ２、Ｎ３、Ｎ４、Ｎ１で定義することができる。次いで管理者は、１つのリソースグループをＦＳ１に関連付け、別のリソースグループをＦＳ１３に関連付けることができ、それによってリソースグループは一般に、異なるノードにフェールオーバーするが、依然として同じサブセットのノード内でフェールオーバーする。一般に、ユーザは、グループの好ましいリストを設定する必要はない。というのは、内部で、クラスタノードは無作為の順序で好ましいリスト内に列挙されるからである。そのグループ内のリソースをホストすることができないノードは、このリストから取り除かれる。しかし、ユーザは、グループの配置をより制御したい場合、グループの好ましいリストを特定の順序に設定することができる。

フェールオーバーは一般に、図４に示した構成要素を介して動作する。図４には、図２のクラスタ２０２が少し異なる様式で示されており、複数のノードのうちの２つ（Ｎ４およびＮ５）は、主にフェールオーバーに使用される、内部構成要素およびデータ構造の一部を示す。その他のノードＮ１〜Ｎ３およびＮ６〜Ｎ８も同様の構成要素およびデータ構造を有しているが、これらの内部項目は、個別には示されていないことに留意されたい。さらに、斜線でノードＮ２を消すことによって示すように、ノードＮ２は故障し、そのため、ノードＮ２のリソースグループをフェールオーバーする必要があるとみなす。リソースグループが故障し、したがって、そのノードが依然として動作している場合でも、リソースグループがフェールオーバーされる可能性があることに留意されたい。例えば、リソースグループは、テストのためなど、故意にフェールオーバーをもたらすことによって、別のノードに移動される場合がある。

ノードが故障したとき、クラスタ内の各ノードは障害のことを知っている。例えば、ノードの障害を検出する方法は、故障したノードが正規のｐｉｎｇメッセージへの応答を停止すること、または定期的なハートビートメッセージを送出しないことである。こうした情報が定期的にクラスタのノードに伝えられるので、残存するノードは障害について知っている。

一実装形態で、ノードのうちの１つは、フェールオーバーを制御するリーダーノードである（リーダーノードが故障した場合、別のノードが新しいノードとして継承するため、少なくとも１つの健全なノードがクラスタ内にあるとき、常にリーダーノードが存在することに留意されたい）。リーダーノードは、各リソースグループが確実にフェールオーバーし、フェールオーバー動作がまずそのリソースグループについてのフェールオーバー範囲の順序に従って試行されるように、フェールオーバー動作を制御する（または別のノードの制御に任せる）。このために、各ノードは、フェールオーバー範囲、およびリソースグループとフェールオーバー範囲との関連付けを保持するデータ構造とともに、フェールオーバーマネージャ（リソース制御マネージャとも呼ばれる）を有する。フェールオーバーマネージャは、リソースグループのフェールオーバーを、フェールオーバー範囲の順に、リソースグループの関連のフェールオーバー範囲内に含まれているノードに制限するよう動作する。図４の例では、ノードＮ４の場合、フェールオーバーマネージャは４０８₄とラベル付けされており、フェールオーバー範囲データ構造は３０２₄、リソースグループとフェールオーバー範囲との関連付けのデータ構造（resource groups-to-failover scopes associations data structure）は３０４₄であり、ノード５についても同様の項目が下付文字「５」でラベル付けされている。図４には示していないが、「リソースマネージャ」は、リソースのホスト環境を提供することができ、その場合、フェールオーバーマネージャは、適切なリソースマネージャを介して、リソースを対象とする制御順序を提供することに留意されたい。

容易に理解できるように、本発明のフェールオーバー範囲を含む様々な実施形態を実施することができる。例えば、一実装形態で、フェールオーバーマネージャは、リソースグループに関連付けられているフェールオーバー範囲が決して交わらず、すなわち、分離されているようにするようにルールを実施することができる。あるいは、これがフェールオーバーマネージャによって実施されない場合、フェールオーバーマネージャが構成に基づいて決定するため、これは許可され、動作する。さらに、フェールオーバーマネージャは、まず、可能な場合は自動で、または管理者からの何らかの入力で、リソースグループをホストするノードの能力を決定することができる。例えば、候補ノードがリソースグループのバイナリコードのコピーを含んでいるかどうかに基づいて、自動決定を行うことができる。リソースグループに対応するアプリケーションは、クラスタのあるノードにおいてはインストールすることができるが、他のノードではインストールできないことがあることに留意されたい。例えば、ユーザ入力は、アプリケーションがノードのサブセットに関連付けられている何らかの特別な能力（マルチプロセッサのサポートなど）を使用する必要があるかどうかを決定するのに必要であり得る。

フェールオーバー範囲は、例えばクラスタランタイムがサポートするＡＰＩを呼び出すことによって、手動で作成することができる。その結果、図５および図６を参照して後述するように、フェールオーバー範囲は、必ずしもサイトを表す必要はない。フェールオーバー範囲を使用して、アプリケーションがフェールオーバーすることができるノードの島を定義することができる。

サイトを表すフェールオーバー範囲は、自動的に作成することができる。というのは、基礎を成すネットワーキングインフラストラクチャは、ノード間の距離について何らかの概念を有しているからである。通信時間に基づいて距離を測定する、既知のアルゴリズムを距離検出に使用することができることに留意されたい。クラスタソフトウェアがそのように構成された場合、距離検出に基づいた自動プロセスは、ノードを、サイトに対応するフェールオーバー範囲に追加することができる。このために、図４には、新しいノードがクラスタに追加されたときに自動的に認識する構成要素４２０₄（または４２０₅）を示しており、こうした構成要素は、新しいノードを追加するときに実行されるセットアッププログラムである。このように、管理者は、新しいノードのために、サイトをマッチさせるフェールオーバー範囲のいずれにおいても、フェールオーバー範囲を更新する必要はない。しかし、自動プロセスが新しいノードをフェールオーバー範囲に関連付けるか、または管理者が新しいノードを１つの（または複数の）フェールオーバー範囲に手動で追加するかに関係なく、そのフェールオーバー範囲に関連付けられているリソースグループは、比較的多数である可能性があり、新しいノード上で稼働することができるように変更する必要はない。

図２〜図４の例に示すように、クラスタは、それぞれのサイトがノードの集まりを含む、複数のサイト（時としてジオクラスタ（geocluster）とも呼ぶ）から成る。この例のように、こうしたクラスタ内のリソースグループのために構成されたフェールオーバー範囲は、しばしばサイトレベルの境界に沿って定義され、実際にはこのように使用されるようである。しかし、本発明の実装形態は、フェールオーバー範囲がサイトにまたがることを抑制しない。

さらに、図５のクラスタ５０２に示すように、フェールオーバー範囲５１６（例えば第４のフェールオーバー範囲ＦＳ４など）は、サイトのノードのサブセットのみを含み、例えばサイト５０４のノードＮ２、Ｎ３およびＮ４だけが、フェールオーバー範囲ＦＳ４において識別される。図６のデータ構造６０４からわかるように、ノードＮ１へのリソースグループＲＧ２のフェールオーバーの試行は行われない。というのは、ＲＧ２は、ノードＮ１を含んでいないフェールオーバー範囲ＦＳ４、およびフェールオーバー範囲ＦＳ２に関連付けられているからである。

図６にさらに示すように、手動または自動のフラグは、必ずしもリソースグループごとではなく、代わりに各リソースグループ内のフェールオーバー範囲の対ごととすることができる。したがって、例えば、リソースグループＲＧ５は、手動操作によりフェールオーバー範囲ＦＳ１からＦＳ２にフェールオーバーし、次いで必要に応じて、フェールオーバー範囲ＦＳ２内に適した、または残存するノードが見つからないという理由で、第２の手動フラグにより、フェールオーバー範囲ＦＳ２からＦＳ３へ再度手動でフェールオーバーする。これに対して、リソースグループＲＧ７は、手動操作によりフェールオーバー範囲ＦＳ１からＦＳ２にフェールオーバーするが、次いで、必要に応じて、フェールオーバー範囲ＦＳ２内に適した、または残存するノードが見つからないという理由で、第２のフラグが自動を指定していることにより、フェールオーバー範囲ＦＳ２からＦＳ３に自動的にフェールオーバーする。これによって、（例えばクラスタにおいて何かが明らかに誤っているという理由で）二度目に手動を選択すべきか、または、（例えば交わったサイトのフェールオーバーの出費を負担するのでまったく重要ではないという理由で）別のフェールオーバー範囲内の別のノードを見つけるかを選択する、追加の柔軟性が管理者に与えられる。代替の実装形態は、リソースグループを、２つのフェールオーバー範囲のみに限定するか、または、３つ以上のフェールオーバー範囲が許容される場合、３つ以上のフェールオーバー範囲がそのリソースグループに関連付けられているとしても、リソースグループ全体について１つのフラグのみに限定することができることに留意されたい。

上記の詳細な説明からわかるように、クラスタが故障の対策を取る自動動作をクラスタ管理者が管理するための柔軟な方法を提供する方法およびシステムが提供される。管理者は、例えば地理的サイトに基づいて、リソースグループがフェールオーバーし得るクラスタノードのサブセットを指定することができる。

本発明は、様々な変更および代替の構成の余地があるが、図面にはその一部の実施形態例を示し、詳細に上述してきた。しかし、本発明を、開示した特定の形に限定する意図はなく、逆に本発明は、本発明の意図および範囲内に含まれるすべての変更、代替構造、および均等物をカバーするものであることを理解されたい。

本発明を組み込むことができるコンピュータシステムを一般的に表すブロック図である。 本発明の様々な態様による、地理的に離れた２つのサイトを含み、画定されたフェールオーバー範囲を有するクラスタ例を一般的に表すブロック図である。 本発明の様々な態様による、１つまたは複数のノードを列挙するフェールオーバー範囲、およびリソースグループおよびフェールオーバー範囲とのそれらの関連のリストを含む、図２のフェールオーバー範囲を示す図である。 本発明の様々な態様による、フェールオーバー範囲によって制御された方法で、フェールオーバーを処理するフェールオーバーマネージャをそれぞれが有するクラスタノードの例を一般的に表すブロック図である。 本発明の様々な態様による、地理的に離れた３つのサイトを含み、あるサイトのノードのサブセットを含む１つのフェールオーバー範囲を含む画定されたフェールオーバー範囲を有するクラスタの例を一般的に表すブロック図である。 本発明の様々な態様による、図５のフェールオーバー範囲、およびフェールオーバー範囲とのリソースグループの関連を示す図である。

Claims (37)

1. コンピューティング環境において、
   クラスタ内の選択されたノードに対応するフェールオーバー範囲を定義すること、
   前記フェールオーバー範囲をリソースグループに関連付けること、および、
   前記リソースグループに関連付けられている前記フェールオーバー範囲に基づいて、あるノードから別のノードに前記リソースグループをフェールオーバーすること
   を含むことを特徴とする方法。
2. 前記フェールオーバー範囲を定義することは、自動プロセスによって前記フェールオーバー範囲の少なくとも一部分を定義することを含むことを特徴とする請求項１に記載の方法。
3. 前記フェールオーバー範囲を定義することは、前記フェールオーバー範囲の少なくとも一部分に関して、管理者からの入力を受け取ることを含むことを特徴とする請求項１に記載の方法。
4. 前記フェールオーバー範囲を定義することは、前記フェールオーバー範囲の少なくとも一部分をサイトに対応するように定義することを含むことを特徴とする請求項１に記載の方法。
5. 新しいノードの追加を検出し、前記フェールオーバー範囲を前記新しいノードに対応する情報を含むように変更することをさらに含むことを特徴とする請求項１に記載の方法。
6. 少なくとも１つの他のフェールオーバー範囲を前記リソースグループに関連付けることをさらに含むことを特徴とする請求項１に記載の方法。
7. 前記リソースグループに関連付けられているフェールオーバー範囲間のノードの交わりを防ぐことをさらに含むことを特徴とする請求項１に記載の方法。
8. 前記リソースグループを任意の他のフェールオーバー範囲内のあるノードにフェールオーバーする試行が行われる前に、前記リソースグループを第１のフェールオーバー範囲内のあるノードにフェールオーバーする試行が行われるように、前記リソースグループに関連付けられているフェールオーバー範囲の順序付けを維持することをさらに含むことを特徴とする請求項６に記載の方法。
9. 前記リソースグループを第１のフェールオーバー範囲内のノードにフェールオーバーする前記試行は失敗し、前記リソースを別のフェールオーバー範囲のノードにフェールオーバーする試行の前に、手動の操作が必要であるかどうかを示すデータにアクセスすることをさらに含むことを特徴とする請求項８に記載の方法。
10. あるノードから別のノードに前記リソースグループをフェールオーバーすることは、前記フェールオーバー範囲内の複数の候補のノードの中から他のノードを選択することを含むことを特徴とする請求項１に記載の方法。
11. 複数の候補のノードの中から他のノードを選択することは、無作為な選択に基づくことを特徴とする請求項１０に記載の方法。
12. 複数の候補のノードの中から他のノードを選択することは、少なくとも１つの基準を満たすことに基づくことを特徴とする請求項１０に記載の方法。
13. 実行されると、請求項１に記載の前記方法を実行するコンピュータ実行可能命令を有することを特徴とする１つまたは複数のコンピュータ読み取り可能記憶媒体。
14. コンピューティング環境において、
    クラスタ内のノードの第１のサブセットに対応する第１のフェールオーバー範囲を定義すること、
    クラスタ内のノードの第２のサブセットに対応する第２のフェールオーバー範囲を定義すること、
    前記第１および第２のフェールオーバー範囲をリソースグループに関連付けること、および、
    前記リソースグループを前記第１のフェールオーバー範囲のあるノードから別のノードにフェールオーバーすることを試行することであって、前記第１のフェールオーバー範囲の各ノードでの前記試行が失敗した場合、前記リソースグループを前記第２のフェールオーバー範囲のノードにフェールオーバーすること
    を含むことを特徴とする方法。
15. 前記第１および第２のサブセットは交わらないことを特徴とする請求項１４に記載の方法。
16. 前記リソースグループをフェールオーバーする他の任意の試行の前に、前記第１のフェールオーバー範囲内で識別されたノードの前記第１のサブセットで前記リソースグループをフェールオーバーする前記試行が行われることを示す、順序付け情報を保持することをさらに含むことを特徴とする請求項１４に記載の方法。
17. 前記第１および第２のフェールオーバー範囲は、自動プロセスによって前記フェールオーバー範囲のうちの１つの少なくとも一部分を定義することを含むことを特徴とする請求項１４に記載の方法。
18. 前記第１および第２のフェールオーバー範囲を定義することは、前記フェールオーバー範囲のうちの１つの少なくとも一部分に関して、管理者からの入力を受け取ることを含むことを特徴とする請求項１４に記載の方法。
19. 前記第１のフェールオーバー範囲を定義することは、前記第１のフェールオーバー範囲の少なくとも一部分をサイトに対応するように定義することを含むことを特徴とする請求項１４に記載の方法。
20. 新しいノードの追加を検出し、前記第１のフェールオーバー範囲を前記新しいノードに対応する情報を含むように変更することをさらに含むことを特徴とする請求項１４に記載の方法。
21. 第３のフェールオーバー範囲を前記リソースグループに関連付けることをさらに含むことを特徴とする請求項１４に記載の方法。
22. 前記リソースグループを第１のフェールオーバー範囲内のノードにフェールオーバーする前記試行は失敗し、前記リソースを前記第２のフェールオーバー範囲のノードにフェールオーバーする前に、手動の操作が必要であるかどうかを示すデータにアクセスすることをさらに含むことを特徴とする請求項１４に記載の方法。
23. 前記データは手動の操作が必要であることを示し、前記リソースを前記第２のフェールオーバー範囲のノードにフェールオーバーする前に、手動の操作を待つことをさらに含むことを特徴とする請求項２２に記載の方法。
24. あるノードから別のノードに前記リソースグループをフェールオーバーすることは、前記フェールオーバー範囲内の複数の候補のノードの中から他のノードを選択することを含むことを特徴とする請求項１４に記載の方法。
25. 複数の候補のノードの中から他のノードを選択することは、無作為な選択に基づくことを特徴とする請求項２４に記載の方法。
26. 複数の候補のノードの中から他のノードを選択することは、少なくとも１つの基準を満たすことに基づくことを特徴とする請求項２４に記載の方法。
27. 実行されると、請求項１４に記載の前記方法を実行するコンピュータ実行可能命令を有することを特徴とする１つまたは複数のコンピュータ読み取り可能記憶媒体。
28. コンピューティング環境において、
    複数のノードと、
    リソースグループをあるノードから別のノードにフェールオーバーする必要がある場合に、前記リソースグループに関連付けられている選択されたフェールオーバー範囲を選択する前記ノードのうちの少なくとも１つで稼働する機構であって、前記選択されたフェールオーバー範囲のノードへ前記リソースグループの第１のフェールオーバーを試行する機構と
    を含むことを特徴とするシステム。
29. 複数のフェールオーバー範囲は、前記リソースグループに関連付けられており、前記機構は、前記フェールオーバー範囲の順序付けに基づいて、前記選択されたフェールオーバー範囲を選択することを特徴とする請求項２８に記載のシステム。
30. 前記機構は、前記リソースグループを前記選択されたフェールオーバー範囲にフェールオーバーせず、前記機構は、新しく選択されたフェールオーバー範囲を選択し、前記新しく選択されたフェールオーバー範囲のノードへ前記リソースグループの次のフェールオーバーを試行することを特徴とする請求項２９に記載のシステム。
31. 前記機構は、前記リソースグループを前記選択されたフェールオーバー範囲にフェールオーバーせず、前記機構は、データをチェックして、他のフェールオーバー範囲のノードに前記リソースグループをフェールオーバーする自動試行のために、前記他のフェールオーバー範囲を選択するかどうかを決定することを特徴とする請求項２９に記載のシステム。
32. 選択されたフェールオーバー範囲はサイトに対応することを特徴とする請求項２８に記載のシステム。
33. 複数の関連したデータ構造を格納する、１つまたは複数のコンピュータ読み取り可能記憶媒体であって、
    クラスタの少なくとも１つのノードを識別するノードセットにそれぞれ関連付けられている、少なくとも１つのフェールオーバー範囲の組を含む第１のデータ構造と、
    少なくとも１つのリソースグループを識別する第２のデータ構造であって、少なくとも１つの識別されたリソースグループは、前記第１のデータ構造に含まれている少なくとも１つのフェールオーバー範囲との関連を有する第２のデータ構造と
    を含み、前記第２のデータ構造で識別されたリソースグループが故障すると、前記第２のデータ構造は、関連したフェールオーバー範囲を選択されたフェールオーバー範囲として選択するためにアクセスされ、前記第１のデータ構造は、前記選択されたフェールオーバー範囲に対応する前記ノードセットを探し出すためにアクセスされ、したがって、前記リソースグループは、前記選択されたフェールオーバー範囲で識別されたノードにフェールオーバーされること
    を特徴とするコンピュータ読み取り可能記憶媒体。
34. 前記第２のデータ構造で識別された前記リソースグループは、前記第１のデータ構造に含まれる少なくとも２つのフェールオーバー範囲に関連付けられることを特徴とする請求項３３に記載のコンピュータ読み取り可能記憶媒体。
35. 前記選択されたフェールオーバー範囲以外のフェールオーバー範囲のノードへのフェールオーバーは、手動の操作を必要とするかどうかを示す、前記リソースグループに関連付けられているデータをさらに含むことを特徴とする請求項３４に記載のコンピュータ読み取り可能記憶媒体。
36. 前記第２のデータ構造で識別された前記リソースグループは、第１および第２のフェールオーバー範囲に関連付けられ、前記リソースグループは、前記第１のリソースグループが前記選択されたリソースグループであるように、前記第１および第２のフェールオーバー範囲を順序付ける情報にさらに関連付けられていることを特徴とする請求項３３に記載のコンピュータ読み取り可能記憶媒体。
37. 前記第１および第２のリソースグループは、前記第２のデータ構造において、前記識別されたリソースグループに関連付けられているリストとして保持され、前記第１および第２のフェールオーバー範囲を順序付ける前記情報は、前記リスト内の前記フェールオーバー範囲の順序付けを含むことを特徴とする請求項３６に記載のコンピュータ読み取り可能記憶媒体。
    

Images