JP2014532921A - 高可用性クラスタにおけるスプリット・ブレイン耐性フェイルオーバ - Google Patents

Abstract

【課題】ノード間、より詳細には、対応するノードにおけるマスタ候補マシン間のフェイルオーバを提供するように同期ステート・レプリケーションをサポートする方法及びＨＡクラスタを提供する。【解決手段】ＨＡクラスタには少なくとも２台のマスタ候補（ｍ＝２）が存在し、カレント・マスタの選出は、クォーラム・マシン群からのクォーラムベースの多数決によって行われる。クォーラム・マシンの台数ｎは、少なくとも３でありかつ奇数である（ｎ≧３であり、ｎは奇数）。カレント・マスタには、カレント・マスタのローカル・クロックで測定することにより求められるカレントの期限付きリースが発行される。リースの持続期間または期間を設定する際、当該持続期間を相対的なクロック・スキューを用いて或る上限に抑制するので、フェイルオーバ・イベント中のスプリット・ブレイン状態への耐性が保証される。【選択図】図１

Description

本発明は、全体として、ネットワーク・クライアントにサービスを提供する複数のマシンから構成される高可用性（ハイ・アベイラビリティ：ＨＡ）クラスタにおける障害及びデータ損失を抑制することに関し、より詳細には、マスタ候補のプール内のクラスタ・マシン間のフェイルオーバを提供するとともに、該クラスタ・マシン間でのスプリット・ブレイン状態を回避することに関する。

今日、コンピュータ・クラスタは通常、地理的に同じ場所に配置されている。そのようなクラスタはまた、多数のノードによって構成されている。各ノードは、それに対応するサーバ、コンピュータまたは他のノードデバイス（通常は単にマシンと呼ばれる）に関連付けられている。クラスタは、記憶装置（例えば、ハードディスクまたは他の大容量記憶装置）などのリソース、及び様々な種類の周辺機器リソース（例えば、モニタまたはプリンタ）を有している。加えて、一般的なコンピュータ・クラスタのインフラは、スイッチ、ルータ、ハブなどを含む。このインフラを用いて、クライアント（例えばパーソナル・コンピュータ）は、インターネットなどの広域ネットワーク（ＷＡＮ）上でクラスタに接続し、クラスタのサービス及びリソースを利用することができる。最も一般的なサービスには、電子メールなどのリモート・アプリケーションが含まれる。

クラスタは、広域ネットワークに接続されているが、通常は、それ自体の別個のローカル・エリア・ネットワーク（ＬＡＮ）上で実行される。このローカル・ネットワークは、ノード間のプライベート接続を提供する。プライベート接続は、例えば、ノード間の通信及び他の有用な機能のために用いることができる。前記機能には、同期信号（マスタ・クロック）の分配、及び、ノードの状態を確認するためのあるいは様々なクラスタ・リソースに独立的にアクセスするためのノード間でのハートビート信号の授受が含まれる。

最近までは通常、ノード間で、クラスタ・リソース、特に大容量記憶装置（マス・ストレージ）を共有していた。しかし残念なことに、共有ストレージ・リソースは通常、クラスタにおける単一障害点を生じさせる。さらに、共有ストレージ・リソースは、クラスタ・ノードは生きているがノード間のネットワークの接続性が失われるというスプリット・ブレイン状態の影響を受けやすい。スプリット・ブレイン状態では、複数のノードが独立的に競ってクラスタ及びそのリソースの制御を引き継ごうとする。このことは、例えば２つ以上のノードが同時にファイル・システムをマウントして書き込みを行おうとする場合に、非常に有害な結果をもたらすおそれがある。

クラスタのノード群は、ノード障害に対する耐性を確保するために、協調を要する。この理由により、通常は、１つのノードが、アクティブ・ノード、リーダー・ノードまたはマスタ・ノードとして選択される。クラスタのマスタ・ノードに障害（フェイル）が発生した場合、クラスタは自動的に新たなマスタに切り替える（オーバ）。このプロセスは、フェイルオーバと呼ばれる。このフェイルオーバ・プロセスが迅速に行われ、クライアントへのサービス提供の途絶が最小限に抑えられることを確実にすることが望ましいことは明らかである。このことは、特に、多数のクライアントに対して実質的に連続したサービスを提供することを目的とする最近の「ＨＡ（ハイ・アベイラビリティ）」クラスタに当てはまる。

当然ながら、コンピュータ・クラスタの出現前に、個々のコンピュータのフォールト・トレランス（耐障害性）は既知の問題であった。具体的には、コンピュータに、冗長な中央演算処理装置（ＣＰＵ）、電源、バスなどを提供してコンピュータ間でのフェイルオーバを確保するというアイデアが、多くの文献に記載されている。例えば、米国特許第７，４４１，１５０号明細書（特許文献１）には、１次系システムと２次系システムとを用いるフォールト・トレラント・コンピュータシステムと、そのための割り込み制御方法が開示されている。

しかし残念ながら、新しいコンテキストにただ単に再適用するには、フォールト・トレラントであるコンピュータとフォールト・トレラントであるクラスタとではシステム間でのフェイルオーバに関わる問題が十分に類似していない。また一方、過去２０年間の傾向は、単一のマシンのデザインから、１つ１つの構成要素が冗長化されたメインフレームや個々のサーバではなく、個々のマシンが冗長でありかつ故障が発生してもよいような分散システムに変化してきている。

フォールト・トレランスに対しての様々な従来技術のアプローチの中から、信頼性が低いプロセッサまたはコンピュータのネットワークにおいて合意（コンセンサス）の問題を解決するための様々なプロトコルを見つけることができるであろう。合意は、参加者のグループにおいて、１つの結果、例えばネットワーク・リーダーなどについて合意を得るプロセスである。参加者、すなわち個々のコンピュータまたはプロセッサ、あるいはそれらの通信媒体に障害が発生する可能性がある場合、この問題は困難なものとなる。この問題に対処するための最も効果的な方法の１つは、参加しているコンピュータ群の中でクォーラム（定足数）投票を行ってリーダーを選出・変更することを含む。Ｐａｘｏｓプロトコルは、クォーラム投票及び必要な実行ステップについての最もよく知られた従来技術の１つである。このプロトコルの様々な顕著な特徴は、米国特許第５，２６１，０８５号明細書（特許文献２）に記載されている。

従来技術には、コンピュータ・クラスタにおいて、フェイルオーバをスピードアップし、かつサービスの途絶を最小限に抑えるための適切な同期アーキテクチャ及び同期方法についての様々な教示も含まれている。例えば、米国特許第７，１９４，６５２号明細書（特許文献３）には、或る制御プロセッサが「アクティブ」のときに別の制御プロセッサが「待機（スタンバイ）」モードに保たれる「ＨＡ」システムが教示されている。待機中のプロセッサには、アクティブなプロセッサのステート情報が、「待機画像」の形式で連続的に提供される。待機画像はアクティブ画像に同期しているので、アクティブ制御プロセッサに障害が発生した場合に、待機中のプロセッサによるアクティブ・モードへの迅速な移行が可能である。このアプローチはＨＡクラスタにおけるフェイルオーバに適しているが、特許文献３に教示されている方法及びアーキテクチャは、スプリット・ブレイン問題に対処していない。

米国特許第７，５９０，８８６号明細書（特許文献４）もまた、フォールト・トレラントなシステムにおけるデバイスの冗長性を促進する問題を扱っている。このシステムは、アクティブの役割を果たすデバイス及びスタンバイの役割を果たすデバイスを有している。フォールト・トレランスを確実にするために、コンフィギュレーション・シーケンス番号を増加させることによる定期的なアドバタイズメントが、アクティブの役割を果たすデバイス及び冗長グループのデバイスの各々の間で交換される。デバイスのステート変化は、非同期的に伝えられる。この教示は、フォールト・トレラント・システムを可能にするが、多数のノード及びリソース並びに大量のステート情報を有するＨＡクラスタには適していない。特に、クラスタ用途では、特許文献４の教示は、効率的なフェイルオーバ及びスプリット・ブレイン耐性を可能にしないであろう。

米国特許第７，９５３，８９０号明細書（特許文献５）には、新たなクラスタ協調リソースまたはクラスタ・コーディネータ・マシンへの切り替え方法が教示されている。前記コーディネータは、スプリット・ブレイン状態を防止するために、所与の時点で何のサービスを実行することができて何のサービスを実行することができないのかを判断する単一のマシンである。このアプローチにおいて、クラスタの各ノードは、新たなコーディネータ・リソースを使用することをコミットする必要がある。このことは、１以上のノードがオフラインである場合に、クラスタまたはその一部が不能になることを意味する。さらに、このアプローチは、個々のクラスタ・ノードのより低いレベルではなく、クラスタ全体のレベルで適用される。最後に、前記コーディネータは単一のマシンであるので、コーディネータがバックアップされて初めて有効なフェイルオーバが提供される。

クラスタレベルでのスプリット・ブレイン状態の防止を補助しながらのフェイルオーバに関してのさらなる教示は、米国特許第８，００１，４１３号明細書（特許文献６）に見ることができる。この場合、前記教示は、データセンター全体のレベルで適用される。データセンターは、該データセンターのアクティブ化を制御するデータセンタ・アクティブ化コーディネータを登録する。パッシブ／バックアップ・データセンター及び以前はアクティブであったデータセンターが同時に「サービスイン（go live）」することができないことを確実にし、それによってスプリット・ブレイン状態の防止に役立つように、タイムアウトが用いられる。特許文献６の教示は、スプリット・ブレイン状態に対処しており２つのデータセンターが同時にオンラインになることを避けることはできるが、個々のクラスタ・ノード間の自動的なフェイルオーバと、これらのクラスタ・ノード間でのスプリット・ブレイン状態の防止とを同時に行うのには適していない。

要するに、様々な有用な方法及びプロトコルが利用可能であるという事実にもかかわらず、従来技術は、ＨＡクラスタにおけるフェイルオーバを確実にし、かつスプリット・ブレイン状態を防止するための統合された効果的な方法を提供していない。

米国特許第７，４４１，１５０号明細書（特開２００６−１７８６５９） 米国特許第５，２６１，０８５号明細書 米国特許第７，１９４，６５２号明細書 米国特許第７，５９０，８８６号明細書 米国特許第７，９５３，８９０号明細書 米国特許第８，００１，４１３号明細書

本発明は、上記の問題点に鑑みてなされたものであり、本発明の目的は、ＨＡクラスタにおいてスプリット・ブレインの起こりにくいフェイルオーバを実現する統合された方法を提供することである。より正確に言えば、本発明の目的は、クォーラムベースの多数決方式と、期限付きリース（time-limited lease）とを組み合わせて、高度にフォールト・トレラントなクラスタの動作を保証することである。

本発明の別の目的は、クォーラムベースの多数決を用いる標準的なネットワーキング・プロトコル、例えば、ＰａｘｏｓプロトコルまたはＺＡＢ（ZooKeeper Atomic Broadcast）プロトコルなどを用いて、上記方法を容易に活用できることを保証することである。

本発明のさらに別の目的は、ローカル・ハードディスクに書き込まれるレガシー・アプリケーションの安全なフェイルオーバさえも可能にする同期ステート・レプリケーションを用いて、高速の、スプリット・ブレインの起こりにくいフェイルオーバを提供することである。

本発明のこれらの及び多くの他の目的及び利点は、以下の説明から明らかになるであろう。

本発明の目的及び利点は、ＨＡクラスタのノード間でのフェイルオーバを提供するようにステートを同期的にレプリケートする方法によって獲得される。ノード群には、１つ以上のネットワーク・クライアントにサービスを提供するために、適切なマシン群、例えば、コンピュータ、サーバまたは処理能力を有する他のデバイスなどが含まれる。本方法に従って、クラスタに属するマシン群の中からｍ台のマスタ候補及びｎ台のクォーラム・マシンが特定される。フェイルオーバを提供するために、少なくとも２台のマスタ候補が存在していなければならない（ｍ≧２）。意味のあるクォーラム（定足数）を保証するために、少なくとも３台のクォーラム・マシンが存在していなければならず、クォーラム・マシンの台数は奇数でなければならない（ｎ≧３であり、ｎは奇数）。

マシンが機能を共有することは可能、すなわち、マスタ候補は原理的にはクォーラム・マシンであってもよいが、マスタ候補及びクォーラム・マシンは互いに異なるマシンであることが好ましい。さらに、クォーラム・マシンは、通常は所与のクラスタ内に併置されるが、好適には互いにアイソレートして配置すべきである。

動作中、ｍ台のマスタ候補の各々は同期的に更新（アップデート）され、カレント・ステートが維持される。ステートには、マシン上で実行しているアプリケーション（コード）によって決定的に実行されることになる一連のマシン入力が含まれる。同じマシン入力から始まり同じアプリケーションを実行するマシンの出力は同じになることに留意されたい。マシン間の同期更新は、ローカル・エリア・ネットワーク上で行うことが好ましい。その一方で、提供されるサービスには、通常、広域ネットワーク上での通信が含まれることになり、ネットワーク・クライアントは広域ネットワーク上でクラスタにアクセスする。適切な広域ネットワークには、インターネットが含まれる。

本方法はさらに、ｍ台のマスタ候補の中からカレント・マスタを選出することを必要とする。選出（エレクション）は、クォーラム・マシン群の中からクォーラムベースの多数決（当分野において「クォーラムベースの多数決によるリーダー選出（quorum-based majority vote leadership election）」または「クォーラムベースの多数決による分散合意（quorum-based majority vote distributed consensus）」とも呼ばれる）によって行われる。このようにして選出されたカレント・マスタには、或る期間の、好適には約数秒または数十秒間の期限付きのカレントのリースが発行される。このリースは、カレント・マスタに属するローカル・クロック（局所時計）で測定することにより求められる。リースを保持している間、あるいは別の言い方をすればリースが終わるまで、カレント・マスタは、１つ以上のネットワーク・クライアントによって要求された１つ以上のサービスを実行する。

本発明に従って、カレントの期限付きリース（current time-limited lease）の相対的なクロック・スキューは、或る上限によって抑制（bound）される。相対的なクロック・スキューを抑制するステップは、データ補正（data corrections）間の遅延の比較から相対的なクロック・スキューを推定するステップに基づくことが好ましい。その後、これらの遅延に基づいて上限が調節される。あるいは、前記上限は、ローカル・クロックの物理的特性から決定される。クロックは、様々な因子（本明細書においては全体として物理的特性と呼ぶ）に起因して、ドリフトすることが知られている。本発明の目的のために最も適した物理的特性の中には、熱ドリフト及び発振器ドリフトが含まれる。相対的なクロック・スキューを抑制するさらに別のアプローチは、セントラル・クロックとの比較から実行することができ、セントラル・クロックは、（クラスタ内に）併置されるかまたは外付けであるかのいずれかである。

本方法に従って構成したとき、カレント・マスタに障害が発生した場合に、ｍ台のマスタ候補の中から選出された新たなマスタへのフェイルオーバがトリガされることになる。新たなマスタは、新たな期限付きリースを発行され、最大クロック・スキュー以上の期間待った後、マスタのサービスを開始する。この方法は、マスタ候補がカレント・マスタであろうとなかろうと、マスタ候補間のスプリット・ブレイン状態を効果的に防止する。障害が発生したマスタのリースに時間の制約があるという事実がその主な理由であり、さらなる理由については以下に詳細な説明において説明する。

或る好適実施形態では、本方法はさらに、ｍ台のマスタ候補の中からカレント・バックアップ・マスタを選出することにまで及ぶ。それゆえ、カレント・マスタに障害が発生した場合には、フェイルオーバよりも前に引き継ぎが決定される。今度の場合も、投票はクォーラム・マシン間におけるクォーラムベースの多数決である。カレント・マスタに障害が発生した場合、フェイルオーバはカレント・バックアップ・マスタに向かう。

いくつかの実施形態では、候補マスタ・マシンの台数ｍが動的に増加または減少される。台数ｍを増加させる際には、ＨＡクラスタに属する新たな候補マシンが特定され、同期的に更新されて、カレント・ステートが維持される。新たな候補マシンが最大限のカレント・ステートを有するに至ったら、新たな候補マシンがｍ台のマスタ候補に加えられ、台数ｍが増加される（ｍ＝ｍ＋１）。同様に、台数ｍを減少させる際には、ｍ台のマスタ候補の中から特定の候補マシンが特定され、マスタ候補群の中から除外される。台数ｍはそれに応じて減少される（ｍ＝ｍ−１）。

本発明の方法は、１つ以上のネットワーク・クライアントにレガシー・アプリケーションを供するのに特に良く適している。レガシー・アプリケーションは、ＨＡクラスタの適切なリソース群のうちの任意のリソースに存在することができる。

本発明の方法はまた、１つ以上のネットワーク・クライアントにサービスを提供するＨＡクラスタを動作させることにまで及ぶ。

本方法は、ＨＡクラスタのノード間においてスプリット・ブレイン状態を生じさせることなくフェイルオーバを提供する。上記したように、先ず、クラスタ・マシン群の中からｍ台のマスタ候補（ｍ≧２）及びｎ台のクォーラム・マシン（ｎ≧３であり奇数）が特定される。ｍ台のマスタ候補は同期的に更新されて、カレント・ステートが維持される。ｍ台のマスタ候補の中から、クォーラム・マシン間で決められるクォーラムベースの多数決により、カレント・マスタが選出される。カレント・マスタは、そのローカル・クロックによって測定されることになるカレントの期限付きリースを発行され、この期限付きリースを保持している間に、カレント・マスタは、ネットワーク・クライアントによって要求されたサービスを実行する。

期限付きリースは、相対的なクロック・スキューによって或る上限に抑制される。カレント・マスタに障害が発生したとき、カレント・マスタは新たなマスタへのフェイルオーバをトリガし、新たな期限付きリースが発行される。

本発明はまた、マシン間においてスプリット・ブレイン状態を生じさせることなくフェイルオーバを行う能力を有するＨＡクラスタに適用される。今度の場合も、クラスタに含まれるマシン群の中からｍ台のマスタ候補及びｎ台のクォーラム・マシンが特定される。ここで、ｍ≧２、ｎ≧３であり、ｎは奇数である。ローカル・ネットワークは、ｍ台のマスタ候補を同期的にレプリケートしかつ更新するために用いられる。

クォーラムベースの多数決プロトコルは、ｎ台のクォーラム・マシンによって、ｍ台のマスタ候補の中からカレント・マスタを選出するために実行される。さらに、カレント・マスタにカレントの期限付きリースを発行するための機構が設けられる。カレントの期限付きリースは、カレント・マスタに属するローカル・クロックで測定することにより求められる。カレントの期限付きリースの相対的なクロック・スキューは、物理パラメータを用いて或る上限に抑制される。

カレント・マスタに障害が発生した場合、新たなマスタへのフェイルオーバがトリガされ、新たなマスタには新たな期限付きリースが発行される。相対的なクロック・スキューから決定される上限を有する期限付きリースを用いることにより、スプリット・ブレイン状態が回避される。そのような状況は、マシン間の接続が失われるなどの障害状態中に、互いに異なるマスタ候補が、当該マスタ候補がカレント・マスタであると仮定したときに発生し得る。

クォーラムベースの多数決プロトコルは、様々な方法で実行することができる。例えば、ＨＡクラスタにおいてＰａｘｏｓプロトコルまたはＺｏｏＫｅｅｐｅｒクラスタ管理を採用することができる。さらに、本発明に従うＨＡクラスタは、ドメイン名などの過失による上書きに特に敏感なデータにサービスを提供するのに特によく適している。それゆえ、マスタ候補がネーム・ノード・マスタ候補であるときに、本発明が有利に適用される。

クラスタは、様々なコンフィギュレーション及びアーキテクチャを実装し得る。さらに、ノードは、リソース群がクラスタ全体にわたって分布しているストレージ・システムを利用することが好ましい。例えば、ストレージ・システムは、多数のブロック・ストレージ・デバイス、例えばハードディスク・ドライブで構成される。

本発明について、その好適実施形態を含めて、以下の詳細な説明において添付の図面を参照しながら詳細に説明する。

本発明の主な特徴を示す、ＨＡクラスタを含むネットワーキング・システムの図。 図１のＨＡクラスタに含まれるクォーラム・マシンのプールの詳細図。 図１のＨＡクラスタに含まれるマスタ候補のプールの詳細図。 本発明に従い相対的なクロック・スキューによって抑制された期限付きリースの働きを示すタイミング図。 本発明に従う別のＨＡクラスタであって、相対的なクロック・スキューから決定される始終端を有する期限付きリース及びクォーラムベースの多数決をデプロイするＨＡクラスタの図。

初めに図１のハイレベル図を参照することにより、本発明が最も良く理解されるであろう。この図は、ネットワーキング・システム１００を示しており、ここで、ネットワーク・クライアント１０２ａ、１０２ｂがＨＡクラスタ１０４に接続されている。明確にするために、図１には２台のクライアント１０２ａ、１０２ｂしか示していない。しかし、当然のことながら、クラスタ１０４は通常、多数の（例えば、約数千、数万またはそれ以上の）クライアントをサポートする。

ネットワーキング・システム１００には、広域ネットワーク１０６すなわちＷＡＮ、例えばインターネット及び／またはさらに他の単数または複数の広域ネットワークが含まれる。ＷＡＮ１０６は、ＨＡクラスタ１０４にデプロイされたサービスが提供される場所において、クライアント１０２ａ、１０２ｂにアクセス可能であることが重要である。クライアント１０２ａ、１０２ｂ間の物理接続１０８ａ、１０８ｂ及びＷＡＮ１０６は、有線、無線、光導波路などを含む任意の適切な技術によって達成することができる。ＷＡＮ１０６は、ネットワーク間インタフェース１１０（好適には超ハイスループットなパイプ）を介してクラスタ１０４に接続されている。

クラスタ１０４は、複数のノード１１２ａ、１１２ｂ、・・・、１１２ｑを有するが、明確にするために、そのうちのいくつかのみを図１に明示的に示す。通常、クラスタ１０４のノード１１２ａ〜１１２ｑは、地理的に同じ場所に配置（併置）され、さらには同じ建物内に収容されてもよい。さらに、ノード１１２ａ〜１１２ｑは、ローカル・エリア・ネットワーク１１６すなわちＬＡＮのライン１１４ａ〜ｄによって相互接続されている。それゆえ、ノード１１２ａ〜１１２ｑは、ＷＡＮ１０６ではなくＬＡＮ１１６上で互いに「プライベートに」通信することができる。

各ノード１１２ａ〜１１２ｑには、対応するプロセッサ、サーバ、コンピュータまたは処理能力を有する他のデバイス（ここでは、全体として、マシン１１８ａ〜１１８ｑと呼ぶ）が含まれる。加えて、各ノード１１２ａ〜１１２ｑには、それに関連して、一連のリソース１２０ａ〜１２０ｑ、１２２ａ〜１２２ｑ、１２４ａ〜１２４ｑが含まれる。省略記号によって示されているように、明示的に符号を付したリソースを超えた追加リソースが各ノード１１２ａ〜１１２ｑに存在することができる。視覚的な明瞭さのために、図１には全てのマシン１１８ａ〜ｑ及び全てのリソース１２０ａ〜ｑ、１２２ａ〜ｑ、１２４ａ〜ｑを明示的に表示してはいない。

当然のことながら、指定されたリソース１２０ａ〜ｑ、１２２ａ〜ｑ、１２４ａ〜ｑ及び明示的に符号を付されていない任意の追加のリソースは、任意の許容される方法で配分することができる。例えば、任意の所与のノードにおけるリソースは、１つ以上の他のノードにおけるリソースと同じであってもよいし、部分的に異なっていてもよい。実際に、リソースは、完全にクラスタ１０４の特定のノードに固有のものである場合すらある。例示的なリソース１２０ａ〜ｑ、１２２ａ〜ｑ及び１２４ａ〜ｑには、プリンタ、モニタ、特定用途向けプロセッサ、ブロック・ストレージ・デバイス、例えばハード・ドライブ・デバイス（例えば、パラレルまたはシリアル、例えばＳＡＴＡ）、フラッシュ・ドライブ及び任意の他のクラスタ・リソースなどが含まれる。実際に、任意の物理的または論理的構成要素であって、オンライン及びオフラインで持ち込まれ、クラスタ１０４内で管理され、１回にノード１１２ａ〜ｑのうちのたった１つのノードによってホストされることができる構成要素を、一連のリソース１２０ａ〜ｑ、１２２ａ〜ｑ及び１２４ａ〜ｑの中から代表させることができる。

本発明に従って、クラスタ１０４に属するマシン１１８ａ〜ｑの中でｍ台のマスタ候補が特定される。具体的には、図１に示した実施形態において、２台のマシン１１８ａ及び１１８ｂがマスタ候補として特定される。よって、この場合には台数ｍは２であり（ｍ＝２）、本発明によるマスタ候補の最小許容台数に相当する。

一点鎖線で描かれたボックス１２６は、マスタ候補のプールを指定する。マスタ候補１１８ａ、１１８ｂは、プール１２６に属する。省略記号は、マシン１１８ｃ〜ｑの中から選択された追加のマスタ候補をプール１２６に入れることができることを示している。つまり、ｍ≧２である限り常に、プール１２６を動的に拡張または縮小させることができる。さらに、プール１２６に含まれるマスタ候補の台数ｍには理論上の上限はない。実際には、以下で詳細に説明する理由で、全てのマスタ候補をカレント・マスタのカレント・ステートで更新された状態にしておくために全てのマスタ候補間で書き込みを同期的にレプリケートすることが必要になる。それゆえ、マスタ候補が４台（ｍ＝４）より多いコンフィギュレーションの使用は、システムの可用性を比例して向上させることなく書き込み待ち時間を著しく増加させることになる。

点線で描かれたボックス１２８は、クォーラム・マシンのプールを指定する。クォーラム・マシンもまた、クラスタ１０４に属するマシン１１８ａ〜ｑの中から特定される。本実施形態では、プール１２８に含まれるクォーラム・マシンの台数ｎは３である（ｎ＝３）。具体的には、マシン１１８ｏ、１１８ｐ及び１１８ｑがプール１２８に含まれる。省略記号は、プール１２８に追加のクォーラム・マシンを含めることができることを示している。しかし、本発明によると、台数ｎは常に少なくとも３かつ奇数でなければならない（ｎ≧３であり、ｎは奇数）。このことは、同時に２台のマシンによってプール１２８を拡張または縮小することだけができることを意味している。ｎを奇数にしておく理由は、プール１２８を２つの小グループ（サブセット）に分けたときに常に一方の小グループが確実にマシンの過半数を占めることになるようにするためである。

マシン１１８ａ〜ｑが機能を共有することは可能、すなわち、マスタ候補は原理的にはクォーラム・マシンであってもよいが、マスタ候補及びクォーラム・マシンは互いに異なることが好ましい。換言すれば、マスタ候補（すなわち、本実施形態においてはマシン１１８ａ、１１８ｂ）のプール１２６及びクォーラム・マシン（すなわち、本実施形態においてはマシン１１８ｏ、１１８ｐ、１１８ｑ）のプール１２８は、いかなるマシンも共有していない。さらに別の言い方をすれば、プール１２６及び１２８は、重なり合っていない。

クォーラム・マシン１１８ｏ、１１８ｐ、１１８ｑは、通常はクラスタ１０４内に併置されるが、好適には互いにアイソレートして配置すべきである。換言すれば、既に述べたように通常はクラスタ１０４の全てのマシン１１８ａ〜ｑは同じ建物内にあるので、クォーラム・マシン１１８ｏ〜ｑをアイソレートするための手段が好適実施形態において与えられるべきである。これらの手段は、図１において明示的に示されていない。通常は、適切にアイソレートされた環境であれば、クォーラム・マシン１１８ｏ〜ｑは、別々のネットワーク・スイッチを用い、同じ電源を共有しない。

本発明に従って、マスタ候補１１８ａ、１１８ｂのステートは、破線で描かれた矢印１３０によって示されているように、同期的に更新される。この目的のために、ＬＡＮ１１６のライン１１４ａによって提供されるマスタ候補１１８ａ、１１８ｂ間の相互接続が用いられることが好ましい。換言すれば、マスタ候補として特定されるマシン１１８ａ、１１８ｂ間の同期更新は、ＷＡＮ１０６あるいは他のネットワークまたは接続ではなく、ＬＡＮ１１６上で行うことが好ましい。

非同期更新では、ノード１１２ａ、１１２ｂに存在するマスタ候補１１８ａ、１１８ｂ間に協調はない。対照的に、同期更新は、更新が完了するまでマスタ候補１１８ａ、１１８ｂにそれらの過去の出力を利用可能にするように要求する。従って、同期更新においては、カレント・ステート（カレント・ステート・ベクトルとも呼ばれる）及び次のステート（次のステート・ベクトルとも呼ばれる）の両方をストアすることが必要である。ステートまたはステート・ベクトルには、マシン１１８ａまたは１１８ｂ上で実行しているアプリケーション（コード）によって決定的に実行されることになる一連のマシン入力が含まれる。その理由は、同じマシン入力から始まり同じアプリケーションを実行するどのマシンの出力も同じになるからである。それゆえ、マシン１１８ａ、１１８ｂにストアされている入力及び出力ステート・ベクトルが同一であることを保証することにより、障害が発生した場合に高いレベルの安全性が提供される。

本発明の目的のために、マスタ候補１１８ａ、１１８ｂ間の同期更新中にストアされた最新すなわち最後のステート・ベクトルをカレント・ステートと呼ぶ。カレント・ステートを不揮発性媒体（磁気ハード・ドライブ、フラッシュ・ドライブ、テープ）にストアすることにより、全てのマスタ候補１１８ａ、１１８ｂに影響を及ぼす電源異常が発生した場合に耐久性を与えることができる。カレント・ステートをストアするために用いられる実際のリソースは、当業者が理解するように選択の幅が広いので、図面にはっきりと示してはいない。リソース１２０ａ〜ｑ、１２２ａ〜ｑ及び１２４ａ〜ｑの中のいずれもが、カレント・ステートをストアするための不揮発性媒体であり得ることにも留意されたい。さらに、このレプリケートされたカレント・ステートが揮発性メモリに完全にストアされる高可用性アーキテクチャを設計することが可能である。しかし、そのような設計では、電源異常によってカレント・ステート情報が失われることがあり得る。

クラスタ１０４はまた、セントラル・クロック１３２へのアクセスを有する。セントラル・クロック１３２は、クラスタ１０４に属するローカル・デバイスであるか、またはリモート・デバイスであり得る。好適実施形態では、セントラル・クロック１３２はローカルであり、クラスタ１０４に属する。例えば、セントラル・クロック１３２は、クラスタ１０４の特定のノード１１２に存在し得る。さらに、好適実施形態では、クロック１３２は、外部標準、例えば原子時計または他の何らかの標準時間基準に基づいてクロックの時刻を定期的に調節する。

ＨＡクラスタ１０４を含むネットワーキング・システム１００は、ネットワーク・クライアント１０２ａ、１０２ｂに各種のサービスを提供するのによく適している。各種サービスは、多種多様な用途、例えば、電子メール、金融取引、ドメイン・ネーム・サーバ（ＤＮＳ）及び他のメタデータ・サービスとのやりとり、さらには、ネットワーキング・システム１００上で提供することができるレガシー・アプリケーションを含み得る。これらのサービスの一部は、障害に非常に敏感である。とりわけ、クライアント１０２ａ、１０２ｂの動作または他のイベントが過失による例えばＤＮＳ入力のデータの上書きを招く障害が、回避されることになる。

ところで、上記の種類の障害を防止するためにＨＡクラスタを管理するマスタを置くことは公知である。マスタは、全ての要求、特にクラスタにおいて任意のステートを更新する要求（例えば、書き込みを含む任意の要求）を処理することによって、クラスタを監督する。マスタは、要求がどのように処理されるかについての合意を保証するように、処理、コミット、クラスタの残りへのブロードキャストを行う。そのようなマスタベースの階層的アプローチは、過失による上書きによるデータの破損及び他の障害を防止するのに役立つ。

マスタベースのクラスタ管理の実行は、適切なブロードキャスト・プロトコル（例えば、アトミック・ブロードキャスト・プロトコル）とともにＺｏｏＫｅｅｐｅｒなどの管理ソフトウェアによって具体化される。そのようなクラスタ管理ソフトウェアに関するさらなる情報は、Patrick Hunt, et al., "ZooKeeper: Wait-free coordination for Internet-scale systems", Proceedings of the 2010 USENIX Annual Technical Conference (ATC) , June 24, Boston MA, pgs. 1-14 を参照されたい。適切なブロードキャスト・プロトコルに関する先行技術は、例えば、Benjamin Reed et al., "A simple totally ordered broadcast protocol", Proceedings of the 2008 Workshop on Large Scale Distributed Systems and Middleware (LADIS) , September 15, Yorktown, NY. に記載されている。

加えて、マスタを監視しなければならないことも知られている。カレント・マスタに障害が発生した場合、適格なマシンの中から新たなマスタが選出されなければならない。そのような選出のための多くのプロトコルが当業者に知られている。それらのうちで最もロバストなもののいくつかには、クォーラムベースの多数決が含まれる。レスリー・ランポートにより最初に提唱されたクォーラムベースの多数決のための公知のプロトコルは、Ｐａｘｏｓプロトコルと呼ばれており、フリー百科事典ウィキペディアの「Ｐａｘｏｓ（コンピュータサイエンス）」という項目及び Lamport L., "Paxos Made Simple", ACM SIGACT News 32, 4 (2001), pp. 18-25 において説明されている。

従来のマスタベースのクラスタ管理方法では、適切なブロードキャスト・プロトコル及びマスタの選出におけるクォーラムベースの多数決は、明らかに障害の数を制限するのに役立つ。しかし、障害が発生したカレント・マスタから新たなマスタへの自動的な移行（自動切り替え）のプロセスすなわちフェイルオーバにおいて、尚も障害が発生する。そのような障害は、通常、フェイルオーバ中に生じるスプリット・ブレイン状態に起因する。この状況において、２つ以上のクラスタ・マシンはマスタとして働くことができ、過失によるデータの上書きなどの障害を発生させ得る。

本発明に従って、ＨＡクラスタ１０４は、スプリット・ブレイン状態を生じさせることなくフェイルオーバをサポートするように設計される。この目標を達成するための第１のステップは、プール１２６に含まれるｍ台のマスタ候補１１８ａ、１１８ｂの中からカレント・マスタを選出するステップを含む。カレント・マスタを選出するステップは、プール１２８を構成するクォーラム・マシン１１８ｏ、１１８ｐ、１１８ｑによって行われる。

図２は、ＨＡクラスタ１０４に含まれるクォーラム・マシン１１８ｏ〜ｑのプール１２８のより詳細な図である。上記のように、省略記号はプール１２８が３つ以上のクォーラム・マシン１１８ｏ〜ｑ（ｎ≧３であり、ｎは奇数）を含むことができることを示しているが、説明はｎ＝３の場合について行う。選出は、プール１２８のクォーラム・マシン１１８ｏ〜ｑの中からクォーラムベースの多数決（当分野において、「クォーラムベースの多数決によるリーダー選出」または「クォーラムベースの多数決による分散合意」とも呼ばれる）によって行われる。ｎは奇数なので、多数決は常に保証される。

図３は、クォーラム・マシン１１８ｏ〜ｑが投票を行うマスタ候補１１８ａ、１１８ｂのプール１２６のより詳細な図である。この場合もやはり、省略記号が示すように、プール１２６は、２つ以上のマスタ候補１１８ａ、１１８ｂ（ｍ≧２）を含むことができるが、状況を簡単にしておくために、説明はｍ＝２の場合について行う。

クラスタ１０４を動作させるために、クォーラム・マシン１１８ｏ〜ｑはカレント・マスタを選出する。図示されている事例では、クォーラムベースの多数決によってマシン１１８ａがカレント・マスタとして選出される。マシン１１８ｏ〜ｐは、図２において対応するハッチング部分によって示されているように、マシン１１８ａの多数決を占めていた。同様に、図３の対応するハッチング部分は、マシン１１８ａがカレント・マスタであることを示している。実際のクォーラムベースの多数決プロトコルは、当分野で公知であり、ここでは説明しない。対応する教示に関しては、Ｐａｘｏｓプロトコルの説明（前掲）をいま一度参照されたい。

このようにしてクォーラムベースの多数決によって選出されたカレント・マスタ１１８ａに、カレントの期限付きリース１３４ａが発行される。リース１３４ａは、図３においてカレント・マスタ１１８ａに属するローカル・クロック１３６ａ上で期間の境界を画定する矢印によって概略的に示されている。実際には、リース１３４ａは、ローカル・クロック１３６ａで測定することにより求めるように設計される。リース１３４ａは、約数秒または数十秒間であることが好ましい。図３に示した例では、リース１３４ａの持続期間は約４０秒間である。

期限付きリース１３４ａの持続期間は、カレント・マスタ１１８ａに現実に障害が発生したことを検出するための時間と、フェイルオーバ・イベントのコストとの間の合理的なトレードオフとして選択される。リース１３４ａの持続期間が非常に少ないすなわち短い時間である場合には、カレント・マスタ１１８ａに障害が発生したと誤って判定し、必要のないときにフェイルオーバを開始またはトリガする可能性がある。リース１３４ａの持続期間が非常に多いすなわち長い時間である場合には、不必要なフェイルオーバを開始またはトリガする可能性は低いが、正真正銘のカレント・マスタ１１８ａの障害を検出するために必要な時間が長くなることがある。期限付きリース１３４ａの適切な持続期間の決定は、利用可能なマスタのコスト及び下層においてフェイルオーバ動作を行うのに掛かる時間に大きく依存している。実際面では、既に同期的にレプリケートされたカレント・ステートの合理的なサイズ（メガバイトまたはギガバイトオーダー）に関して、効果的なバランスがとれるのは数秒または数十秒間である。

カレント・マスタ１１８ａがリース１３４ａを保持している間に、マスタ候補１１８ｂもマスタ候補１１８ｂのローカル・クロック１３６ｂ上で同じリースを測定する。しかし、以下でより詳細に説明するように、クロック１３６ａ、１３６ｂは通常は同期されておらず、同一周波数で動いていない。それゆえ、クロック１３６ａによって測定されるリース１３４ａの持続期間は、リース１３６ａｂと表され、ローカル・クロック１３６ａによって測定されるリース１３４ａの持続期間とは固有時または絶対時間が異なり得る。

カレント・マスタ１１８ａは、リース１３４ａを保持している間にマスタとして働く権限を与えられている。換言すれば、自身のローカル・クロック１３６ａによって測定されるリース１３４ａが未経過である間に、カレント・マスタ１１８ａは、クライアント１０２ａ、１０２ｂによって要求された１つ以上のサービスを提供または実行する権限を有する。これらのサービスには、通常、書き込み要求の実行が含まれる。

カレント・マスタ１１８ａとして働いている間、そのステートまたはステート・ベクトルは、矢印１３０によって示されているように、他方のマスタ候補１１８ｂに同期的にレプリケートされる。実際には、マスタ候補のプール１２６に含まれる任意のマシン１１８は、マスタ候補と考えられるためには、カレント・マスタ１１８ａのカレント・ステートを同期的にレプリケートしなければならない。これにより、ステップ毎に、マスタ候補１１８ｂ及びプール１２６に含まれる任意の他のマスタ候補を更新して、カレント・マスタ１１８ａのカレント・ステートを維持することが確実になる。同期更新は、ＬＡＮ１１６上で、より詳細にはライン１１４ａを介して行われる。

フェイルオーバ中のスプリット・ブレイン状態を回避するために、カレントの期限付きリース１３４ａの相対的なクロック・スキューは、或る上限によって抑制される。具体的には、期限付きリース１３４ａは、期間Δｔに追加の余裕時間εを加えた期間に等しくなるように設定される。これにより、リース１３４ａは、図３に示されているように、最大でΔｔ＋εの上限を有する期間に効果的に抑制される。εに用いられる実際の値は、ローカル・クロック１３６ａ及び１３６ｂの相対的なクロック・スキューに基づく。

新たなマスタには新たな期限付きリースが発行され、最大クロック・スキュー以上の期間待った後、マスタのサービスを開始する。

εの決定の仕方を理解するために、先ず、クロック・スキューを理解しなければならない。全てのクラスタ・ノード１１２ａ〜ｑ並びにルータ（図示せず）及びクライアント１０２ａ、１０２ｂは、ローカル・クロックを有している。そのようなクロックは、当業者に公知のハードウェア及びソフトウェア・コンポーネントから製作される。この事例では、本願出願人は、マスタ候補１１８ａ、１１８ｂのローカル・クロック１３６ａ、１３６ｂ及びそれらのクロック・スキューに関心を持っている。

ローカル・クロック１３６ａ、１３６ｂは各々、公称周波数でティックする（時を刻む）水晶発振器と、ティック数を数えるカウンタとを有する。これらのクロック・コンポーネントは、当業者に公知であり明らかであるので、図示していない。その構造に起因して、ローカル・クロック１３６ａ、１３６ｂの実際の周波数は、環境因子、例えば、温度、湿度及び液晶の種類などによって決まる。それは、クロック１３６ａ、１３６ｂによって記録される単位固有時当たりのティック数にドリフト（ずれ）を生じさせるような、カウンタによって記録される実際の周波数の変動である。このドリフトは、クロック・スキューと呼ばれる。

環境因子及び可変プロセッサ負荷（温度に直接影響を与える）を変えると、クロック１３６ａ、１３６ｂのクロック・スキューが動的に変化する。クロック・スキューの動的変化がもたらす直接的な結果として、ローカル・クロック１３６ａ、１３６ｂから送信されるクロック信号は、互いに異なる時間に異なる構成要素に到達する。

リモート・クロックの正確なクロック・スキューを直接測定することは不可能であることに留意しなければならない。その結果として、マスタ候補１１８ａは、マスタ候補１１８ｂのローカル・クロック１３６ｂのクロック・スキューを直接測定することができず、逆の場合も同じである。

幸いなことに、εの値を決定するために、クロック１３６ａ、１３６ｂ間の相対的なクロック・スキューをリモートから推定することができる。そのような推定は、例えば環境因子及びカレント・マスタ１１８ａ及びマスタ候補１１８ｂへの処理負荷の変更に起因するような、相対的なクロック・スキューの動的変化が説明されるように、マスタ候補１１８ａ、１１８ｂによって、クラスタ１０４のスタートアップより前に周期的に行われることが好ましい。

本発明の好適実施形態では、相対的なクロック・スキューは、データ補正間の遅延の比較から推定される。これは、ネットワークタイム・プロトコル（ＮＴＰ）などの適切なアルゴリズムを用いて行われることが好ましい。このプロトコルは、マシン間でテスト・パケットを送信し、ネットワーク伝送遅延をキャンセルした後に相対的なクロック・スキューを推定する。

ローカル・クロック１３４ａ、１３４ｂ間の相対的なクロック・スキューが決定されたら、εの値を割り当てることができる。εの値は、データ補正間の遅延の比較において推定された相対的なクロック・スキューの最大量として選択されることが好ましい。あるいは、εの値を設定するために、複数の推定値に対して統計的アルゴリズムを用いることができる。これは、支配的な一連の環境因子及び処理負荷に関して統計的に有意な数の推定値が利用可能であるときに実行可能である。これらの条件下で、ローカル・クロック１３４ａ、１３４ｂ間の相対的なクロック・スキューの平均推定値から幾つかの標準偏差でεを設定することができる。当業者は、障害への耐性を備えたクラスタ１０４に、クライアント１０２ａ、１０２ｂに提供するアプリケーションの種類をどのようにして与える必要があるかに基づいて、標準偏差の正確な数を調節することができることが分かるであろう。

時間の経過とともに、ローカル・クロック１３４ａ、１３４ｂのクロック・スキュー及びクラスタ・ノード１１２に属する他のクロックのスキューが蓄積する傾向がある。これらのスキューにより、クラスタ１０４では、ノード群１１２に実に様々なローカル時間が記録されることになる。これらの時間差を解消するために、クラスタ・ノード群１１２は、自身のクロックを、固有時または絶対時間を測定するセントラル・クロック１３２に同期させることができる。しかし、本発明は、相対的なクロック・スキューに依存するので、ノード群１１２、特にマスタ候補１１８ａ、１１８ｂのノード１１２ａ、１１２ｂの、同一絶対時間への同期には依存しない。そのおかげで、高品質のローカル・クロックを含まない低コストのマシン１１８をクラスタ１０４にデプロイすることができる。

図４は、タイミング図であって、最大でΔｔ＋εの期間に抑制されたカレント・マスタ１１８ａの上記の期限付きリース１３２ａが如何にしてスプリット・ブレイン状態を防止するかを示している。図４の図から、カレント・マスタ１１８ａ及びマスタ候補１１８ｂのローカル・クロック１３６ａ、１３６ｂは、絶対時間において同期されていないことは明白である。実際に、セントラル・クロック１３２によって記録される絶対初期時間（absolute initial time）ｔ_０ｃは、マスタ候補１１８ｂのローカル・クロック１３６ｂによって記録される初期時間ｔ_０ｂの後に存在する。その一方で、カレント・マスタ１３６ａのローカル・クロック１３６ａによって記録される初期時間ｔ_０ａは、セントラル・クロック１３２の絶対初期時間ｔ_０ｃの後に存在する。

プール１２８のクォーラム・マシン１１８ｏ〜ｑによるクォーラムベースの多数決は、図２を参照して上記したように、選出期間Δｔ_ｅ中に行われる。明確にするために、選出期間Δｔ_ｅは、マスタ候補１１８ａのローカル・クロック１３６ａの時系列上にのみ記録されている。選出期間Δｔ_ｅの終了時、すなわちローカル・クロック１３６ａ上に示されている時間ｔ_１ａにおいて、候補マシン１１８ａがクラスタ１０４のカレント・マスタに選出される。この時間は、マスタ候補１１８ｂのローカル・クロック１３６ｂ上の時間ｔ_１ｂ及びセントラル・クロック１３２上の時間ｔ_１ｃにそれぞれ対応している。

ローカル・クロック１３６ａ上の時間ｔ_１ａにおいて、カレント・マスタ１１８ａは、ローカル・クロック１３６ａの相対的なクロック・スキューによって抑制された期限付きリース１３４ａを受信する。前述したようにデータ補正間の遅延を比較したときに得られた最大値ε＝ε_ａを選択することによって、クロック１３６ａとクロック１３６ｂとの相対的なクロック・スキューの最大値に基づいて或る上限が設定される。それゆえ、カレントの期限付きリース１３４ａは上限によって最大でΔｔ＋εの期間に抑制される。本発明に従って、カレント・マスタ１１８ａは、自身のローカル・クロック１３６ａによって測定された期間Δｔの間、依然としてクラスタ１０４のマスタのままであると推定することができる。

ところで、カレント・マスタ１１８ａのローカル・クロック１３６ａにおいて、期間Δｔ＋εはｔ_１ａから時間ｔ_２ａまで持続することになる。しかし、スプリット・ブレイン状態を回避するために、カレント・マスタ１１８ａは、期間Δｔの後、期限付きリース１３４ａの期間ε_ａ中に、マスタ候補１１８ｂがクラスタ１０４の制御をめぐって争うことができるように既に準備されていなければならない。例えば、このことは、潜在的に無意識のうちに、リース１３４ａ中にカレント・マスタ１１８ａに障害が発生した場合に起こり得る。

ところで、本発明に従って構成されたクラスタ１０４において、カレント・マスタ１１８ａに障害が発生した場合、プール１２６に含まれる利用可能なマスタ候補群の中から選出される新たなマスタへのフェイルオーバがトリガされることになる。この実施形態では、ｍ＝２であるので、フェイルオーバのために利用可能な他のマスタ候補はマスタ候補１１８ｂの１つしかないことに留意されたい。

図４に示したように、カレント・マスタ１１８ａの障害は、自身のローカル・クロック１３６ａに記録される時間ｔ_２ａよりも前の時間ｔ_ｆａにおいて発生する。障害は、カレント・マスタ１１８ａとＬＡＮ１１６との間における失われた接続、意図的な接続解除または故障（非信頼性または非有用性を含む）に起因するものであり得る。実際には、カレント・マスタ１１８ａは、クラスタ１０４との関連において自身の障害に気付かないことすらある。

従って、期間Δｔが終わるまで、カレント・マスタ１１８ａは、期限付きリース１３４ａを測定して求め続け、かつマスタとしての役目を果たし続けることになる。

その一方で、マスタ候補１１８ｂはまた、カレント・マスタ１１８ａに割り当てられたリース１３４ａの期間Δｔ＋ε_ａを測定して求めしている。しかし、マスタ候補１１８ｂは、期間Δｔ＋ε_ａを測定して求めるために自身のローカル・クロック１３６ｂを用いている。マスタ候補１１８ｂは、そのローカル・クロック１３６ｂに従って、時間ｔ_１ｂからｔ_２ｂまでの期間１３４ａｂの間持続する間、期間Δｔ＋ε_ａを記録することになる。期間１３４ａｂが期間１３４ａに等しくないことは明らかである。当然ながら、この期間の差は、前述したように、ローカル・クロック１３６ａ、１３６ｂ間の相対的なクロック・スキューに起因する。

マスタ候補１１８ｂは、相対的なクロック・スキューに起因して、決定した期間Δｔが、カレント・マスタ１１８ａで測定することにより求めた期間Δｔとは異なり得ることを知っている。このため、マスタ候補１１８ｂは、自身のクロック１３６ｂによって記録される追加時間ε_ａの間待つ。換言すれば、マスタ候補１１８ｂは、相対的なクロック・スキューに起因して、カレント・マスタ１１８ａがマスタ候補１１８ｂのローカル・クロック１３６ｂ上の時間ｔ_２ｂまで尚もマスタとして働いている可能性があることを仮定する。それゆえ、本発明に従って、マスタ候補１１８ｂは、時間ｔ_２ｂの後まで、新たなマスタになろうとしないように指示されている。

ここで、マスタ候補１１８ｂのローカル・クロック１３６ｂによるｔ_ｆｂとｔ_２ｂの間の期間１３６ａｂにおいて、クラスタ１０４はマスタを有しない。このようにして生じるマスタ不在期間１３８は、図４においてハッチング部分を用いて指定されている。上記したように、期限付きリース１３４ａの持続期間を設定するときに、トレードオフにおいて、クラスタ１０４のクライアント１０２ａ、１０２ｂが容認することを厭わないマスタ不在期間１３８の長さを考慮する必要があることは明らかである。

マスタ候補１１８ｂのローカル・クロック１３６ｂ上のｔ_２ｂにおいて、障害が発生したマスタ１１８ａからのフェイルオーバ１４０がトリガされ、マスタ候補１１８ｂが新たなマスタになる。クロック１３６ｂはクロック１３６ａよりも高速で動いていることに留意されたい。それゆえ、期間１３４ａｂの終わりの時間ｔ_２ｂは、実際には、障害が発生したカレント・マスタ１１８ａのクロック１３６ａ上で時間１３４ａが完全に終了するよりも僅かに前にある。しかし、ε_ａの値は、クロック１３６ａ、１３６ｂ間の最大可能な所与の相対的なクロック・スキューになるように選択されたので、新たなマスタ１１８ｂのローカル・クロック１３６ｂ上の時間ｔ_２ｂにおいて、障害が発生したマスタ１１８ａが尚もクラスタ１０４のマスタとして働こうと試みている可能性は、実質的に全くない。つまり、上記したように、カレント・マスタ１１８ａは、新たなマスタ１１８ｂのローカル・クロック１３６ｂ上で時間ｔ_２ｂよりも前に支障なく終わる持続期間Δｔの後に、マスタであると見なすことをやめる。よって、本発明に従って、スプリット・ブレイン状態が効果的に回避される。

フェイルオーバが行われると、新たなマスタ１１８ｂに新たな期限付きリース１３４ｂが発行される。新たなリース１３４ｂは、持続期間Δｔ＋εに設定され、このとき、ローカル・クロック１３６ａ、１３６ｂ間で推定された最大の相対的なクロック・スキューに基づいて、特定値ε＝ε_ｂである。この場合もやはり、前述したように、データ補正間の遅延の推定に基づいてεを計算することが好ましい。相対的なクロック・スキューの値は一般に時間の関数として変化することになるので、図４に示したようにε_ａ及びε_ｂは互いに異なり得ることに留意されたい。

セントラル・クロック１３２との同期の欠如がフェイルオーバを妨げず、スプリット・ブレイン状態を回避する理由を知るためのさらに別の方法は、セントラル・クロック１３２が感知する上記のアクティビティを調べることによる。その観点から、時間ｔ_１ｃにおいてカレント・マスタ１１８ａに期限付きリース１３４ａが発行される。セントラル・クロック１３２によって測定されるリース１３４ａの持続期間もやはり、マスタ候補１１８ｂのローカル・クロック１３６ｂによって記録される期間１３４ａｂとは異なる。すなわち、セントラル・クロック１３２によって測定されるリース１３４ａの持続期間は、１３４ａｃである。

持続期間１３４ａｃは、１３４ａｂよりもさらに短い。しかし、そのことは問題にはならない。というのも、マスタ候補１１８ｂは、ローカル・クロック１３６ｂ上の時間ｔ_２ｂまで支配権を握らないためである。この時間は、セントラル・クロック１３２上の時間ｔ_２ｃに対応する。ε値の適切な選択によりクロック１３６ａ、１３６ｂ間の相対的なクロック・スキューを或る上限に抑制した結果、セントラル・クロック１３２によって記録される合間の期間Δｔ_ｉｃ中にスプリット・ブレイン状態はないことに留意されたい。

あるいは、期限付きリース１３４ａ、１３４ｂの上限は、ローカル・クロック１３６ａ、１３６ｂの物理的特性から決定される。上記したように、クロック１３６ａ、１３６ｂは、様々な環境因子、例えば温度及び湿度並びに液晶または発振器特性に起因してドリフトする。環境因子及び発振器特性を合わせて、本明細書において物理的特性と呼ぶことにする。本発明の目的のための最も適した物理的特性のうちのいくつかには、熱ドリフト及び発振器ドリフトが含まれる。

そのような別の実施形態では、期限付きリースの上限は、マスタ候補間の選択された物理的特性または幾つかの特性の相違により、持続期間Δｔに相対的なクロック・スキューの最大量を加えた値に等しくすることができる。当業者に知られている方法で効果的に推定することができるが故に最も適切な物理的特性は、ローカル・クロックの熱ドリフト及び／または発振器ドリフトである。

物理的特性を用いて相対的なクロック・スキューを抑制する場合、εの値は単に、観測されるスキューのこの最大量に設定されることが好ましい。期限付きリースの期間を得るために、前述同様に、期間Δｔにεが加えられる。当然ながら、スプリット・ブレイン状態の可能性をさらに低くするために、εの値を控えめにさらに大きく設定することができる。しかし、εを非常に大きな値に設定すると、フェイルオーバより前のマスタ不在期間１３８の持続期間を増加させることになるので、クラスタ１０４の性能に影響を与えることになる。従って、既に述べたように、εの値の選択は、クラスタ１０４の所望の性能と比較考量するべきである。

相対的なクロック・スキューを抑制するさらに別のアプローチを、セントラル・クロック１３２との比較から実行することができる。セントラル・クロック１３２を利用する実施形態では、後者はローカル・クロック１３６ａ、１３６ｂよりも遥かに信頼性が高いことが保証されなければならない。このことは、セントラル・クロック１３２を適切な制御された環境におくことによって、及び／または原子時計などの外部標準を用いてセントラル・クロック１３２を頻繁に調整することによって、行うことができる。

マスタを選出するために期限付きリース及びクォーラムベースの多数決を実行するのに合わせて、クラスタ１０４は、様々なクロック・リース及びあらゆる種類の他のセーフガードを用いることもできる。明らかに、本発明と、分散システム及びＨＡクラスタにおいて用いられる他のセーフガード及びプロトコルとの間で対立がないことは、非常に有利である。本発明の方法とともに、本発明に従ってクラスタにおいて実装することができる例示的なクロック・リース及び対応する手順に関しては、Mike Burrows, "The Chubby lock service for loosely-coupled distributed systems", Google Inc., OSDI 2006 を参照されたい。

図５は、本発明に従う別のＨＡクラスタ２００の図である。クラスタ２００は、複数のマシン２０２ａ〜ｚを有する。それらのうち、５台のマシン２０２ａ〜ｅは、クォーラム・マシン・プール２０４に属するクォーラム・マシンである。それに相当するものとして、台数ｎは５であり（ｎ＝５）、それゆえに適正に３よりも大きく、かつ奇数である。３台のマシン、すなわち２０２ｓ〜ｕは、マスタ候補プール２０６に属するマスタ候補である。従って、台数ｍは３であり（ｍ＝３）、それゆえに、要求される通り、２よりも大きい。

クラスタ２００は、カレント・マスタに、上記した方法で相対的なクロック・スキューから決定された始終端（bounds）を有する期限付きリースをデプロイする。加えて、クォーラム・マシン２０２ａ〜ｅは、好適には互いにアイソレートされており、プール２０６からのクォーラムベースの多数決によりカレント・マスタを選択する。この事例では、プール２０４によって選出されるカレント・マスタはマシン２０２ｕである。

これまでに説明した実施形態とは対照的に、マスタ候補２０２ｓ〜ｕの数は３（ｍ＝３）であり、従って、フェイルオーバのための明らかな新たなマスタ候補は存在しない。この場合、安全のために、フェイルオーバ・イベントの前に、カレント・マスタ２０２ｔに加えてカレント・バックアップ・マスタを選出することが好ましい。この選出は、プール２０４のクォーラム・マシン２０２ａ〜ｅの中から、カレント・マスタ２０２ｕの選出で用いたのと同じクォーラムベースの多数決プロトコルを用いて行われる。

当然ながら、カレント・マスタ２０２ｕは、既にカレント・マスタとして選出されているので、バックアップ・マスタの投票の対象ではない。この事例では、クォーラム・マシン２０２ａ〜ｅはバックアップ・マスタとしてマシン２０２ｔを選出する。

このようにバックアップ・マスタ２０２ｔが潜在的フェイルオーバよりも前に既に選出されているので、カレント・マスタ２０２ｕに障害が発生したときに、クラスタ２００はプール２０４のクォーラム・マシン２０２ａ〜ｅの固有の動作に依存しなくてもよい。このように、選出をフェイルオーバ中に行う必要はない。カレント・マスタ２０２ｕに障害が発生した場合、引き継ぎはフェイルオーバより前に決定され、フェイルオーバをトリガするような障害イベント中に生じ得る潜在的な曖昧さが回避される。

いくつかの実施形態では、候補マシン２０２ｓ〜ｕの台数ｍを動的に増減することができる。このことは、クラスタ２００からマシン２０２を除外したりクラスタ２００にマシン２０２を追加したりするときに有用であろう。他の事例においては、マシン２０２の責務及び責任が再調整されるときに必要とされるであろう。

台数ｍを増加させる際には、クラスタ２００に属する新たな候補マシン２０２ｈを特定し、矢印２０８によって示されているように、同期的に更新して、カレント・マスタ２０２ｕのカレント・ステートを維持する。カレント・ステートで更新したら、新たな候補マシン２０２ｈを、プール２０６に含まれるｍ台のマスタ候補２０２ｓ〜ｕに追加し、台数ｍが増加する（ｍ＝ｍ＋１すなわちｍ＝４）。しかし、上記したように、可能なサービス時間遅延に起因して、４（ｍ＝４）を超えてプール２０６を拡張することは望ましくないであろう。

同様に、台数ｍを減少させる際には、マスタ候補２０２ｓ〜ｕの中から特定の候補マシン、例えばマシン２０２ｓを特定し、プール２０６から除外する。台数ｍはそれに応じて減少する（ｍ＝ｍ−１すなわちｍ＝２）。マシン２０２ｓは除外時にカレント・マスタでもバックアップ・マスタでもないので、マシン２０２ｓの除外はいつでも行うことができる。マシン２０２ｓがプール２０６から除外されたら、マシン２０２ｓをカレント・ステートで同期的に更新する必要はなくなる。

本発明の方法は、ネットワーク・クライアントにアプリケーション２１０などのレガシー・アプリケーションを供するのに特に良く適している。レガシー・アプリケーション２１０は、ＨＡクラスタの適切なリソースのうちの任意のもの、例えばマシン２０２ｇのリソース２１２ｇなどに存在することができる。

レガシー・アプリケーション２１０は、Ｌｉｎｕｘ（登録商標）カーネルで動作する分散複製型ブロック・デバイス（Distributed Replicated Block Device）などのネットワーク・ブロック・デバイスを用いて必要なステート・レプリケーションをトランスペアレントに行うことによって最も良くサポートされる。レガシー・アプリケーション２１０は、マスタ候補２０２ｓ〜ｕのリモート・ハード・ドライブへのアプリケーション・ディスクの書き込みをトランスペアレントにかつ同期的にレプリケートするようなネットワーク・ブロック・デバイスによって裏付けられるディレクトリ内のディスクへのステートの書き込みを行う。ブロック・デバイスは、固定サイズの複数バイトのチャンクにおいて読み出し及び書き込み操作をサポートする任意のデバイス（磁気ハード・ドライブ、フラッシュ・ドライブなど）のコンピュータ・オペレーティング・システムを抽象化したものである。ネットワーク・ブロック・デバイスは、任意のブロック書き込み操作をローカル・ブロック・デバイス及び１つ以上のリモート・ブロック・デバイスへ同期的に転送する。

フェイルオーバ・イベントが発生したとき、新たなマスタは、以前のマスタのローカル・ブロック・デバイスの正確な複製（write-for-write replica）であるローカル・ブロック・デバイスをマウントすることができ、最大クロック・スキュー時間の経過を待ち、プール２０６の他の残りのマスタ候補への全てのブロック書き込みをレプリケートするようにネットワーク・ブロック・デバイス・レイヤ（層）を構成した後、レガシー・サービス（アプリケーション２１０のサービス）を開始することができる。

本発明は、全てのファイル・システムのメタデータを管理する単一マスタサービスのための高可用性自動フェイルオーバのための機構を提供するので、Hadoop分散ファイル・システムなどの大規模な単一マスタ分散システムに特に有用である。大規模分散システムでは、マスタ・マシンは１台であるが、全データをストアするスレーブ・マシンは数十ないし数千台存在する。マスタのデータが消失した場合には、全てのデータが役に立たない状態にされ、マスタとコンタクトをとることができない場合には、全てのデータがアクセス不能になる。高可用性フェイルオーバをトランスペアレントに行うためのシステムを設けることで、これらの両方の欠点に対応する。

追加的な効果として、本発明は特に、ブロック・デバイス書き込みにより（例えば、ファイルにステートをストアするなどして）ステートを持続するレガシー・システムに適用可能である。多くのサービス、例えばケルベロス（Kerberos）や全てのファイルと関連付けられた（file-backed）リレーショナル・データベース（例えば、PostgreSQL）は、この説明に当てはまる。本発明によって、データの損失なく、同期したトランスペアレントなフェイルオーバを提供する環境においてそのようなサービスをサポートすることができ、単一マシンのレガシー・サービスをハイ・アベイラブルなサービスに変えることができる。

上記の教示を考慮して、当業者は、本発明の趣旨から逸脱することなしに、本発明の装置及び方法を、本明細書に記載されている以外にも多様な方法で具現化することができることを認識するであろう。従って、本発明の範囲は、添付の特許請求の範囲及びそれと法的に等価なものを考慮して判断されなければならない。

Claims (23)

1. 少なくとも１台のネットワーク・クライアントにサービスを提供する高可用性クラスタのマシン群を含むノード間においてフェイルオーバを提供するべくステートを同期的にレプリケートする方法であって、
   ａ）前記マシン群の中からｍ台（ｍは少なくとも２である）のマスタ候補を特定するステップと、
   ｂ）前記マシン群の中からｎ台（ｎは少なくとも３でありかつ奇数である）のクォーラム・マシンを特定するステップと、
   ｃ）前記ｍ台のマスタ候補の各々を同期的に更新してカレント・ステートを維持するステップと、
   ｄ）前記クォーラム・マシン群からのクォーラムベースの多数決によって、前記ｍ台のマスタ候補からカレント・マスタを選出するステップと、
   ｅ）前記カレント・マスタに対して、該カレント・マスタに属するローカル・クロックで測定することにより求められるカレントの期限付きリースを発行し、前記カレント・マスタが、前記カレントの期限付きリースを保持している間に、前記少なくとも１台のネットワーク・クライアントによって要求されたサービスを実行するステップと、
   ｆ）前記カレントの期限付きリースの相対的なクロック・スキューを或る上限に抑制するステップとを含み、
   前記カレント・マスタに障害が発生した場合に、前記ｍ台のマスタ候補の中から新たなマスタへのフェイルオーバをトリガし、前記新たなマスタに対して新たな期限付きリースを発行し、それによって前記マスタ候補間のスプリット・ブレイン状態を防止するようにしたことを特徴とする方法。
2. 前記ｎ台のクォーラム・マシンからのクォーラムベースの多数決によって、前記ｍ台のマスタ候補からカレント・バックアップ・マスタを選出するステップをさらに含むことを特徴とする請求項１に記載の方法。
3. 前記新たなマスタが前記カレント・バックアップ・マスタであり、前記フェイルオーバが前記カレント・バックアップ・マスタへのフェイルオーバであることを特徴とする請求項２に記載の方法。
4. 前記相対的なクロック・スキューを抑制する前記ステップが、
   ａ）データ補正間の遅延を比較することによって前記相対的なクロック・スキューを推定するステップと、
   ｂ）前記データ補正間の前記遅延に基づいて前記上限を調節するステップとを含むことを特徴とする請求項１に記載の方法。
5. 前記上限が、前記ローカル・クロックの物理的特性から決定されることを特徴とする請求項１に記載の方法。
6. 前記物理的特性が、熱ドリフト及び発振器ドリフトからなる群から選択されることを特徴とする請求項５に記載の方法。
7. 前記上限が、セントラル・クロックとの比較から決定されることを特徴とする請求項１に記載の方法。
8. 前記カレントの期限付きリースが、数秒または数十秒間であることを特徴とする請求項１に記載の方法。
9. 前記ｍ台のマスタ候補を動的に拡張するステップをさらに含み、該ステップが、
   ａ）前記高可用性クラスタに属する新たな候補マシンを特定するステップと、
   ｂ）前記新たな候補マシンを同期的に更新してカレント・ステートを維持するステップと、
   ｃ）前記新たな候補マシンを前記ｍ台のマスタ候補に加えて前記台数ｍを増加させるステップとを含むことを特徴とする請求項１に記載の方法。
10. 前記マスタ候補のプールを動的に縮小するステップをさらに含み、該ステップが、
    ａ）前記ｍ台のマスタ候補の中から所定の候補マシンを特定するステップと、
    ｂ）前記所定の候補マシンを前記ｍ台のマスタ候補から除外して前記台数ｍを減少させるステップとを含むことを特徴とする請求項１に記載の方法。
11. 前記サービスが、前記高可用性クラスタのリソースから前記少なくとも１台のネットワーク・クライアントに提供されるレガシー・アプリケーションを含むことを特徴とする請求項１に記載の方法。
12. 前記同期的に更新するステップが、ローカル・エリア・ネットワーク上で行われ、
    前記サービスが、広域ネットワーク上での通信を含むことを特徴とする請求項１に記載の方法。
13. 前記ｍ台のマスタ候補及び前記ｎ台のクォーラム・マシンが、互いに異なるマシンを含むことを特徴とする請求項１に記載の方法。
14. 前記ｎ台のクォーラム・マシンを互いにアイソレートするステップをさらに含むことを特徴とする請求項１３に記載の方法。
15. 少なくとも１台のネットワーク・クライアントにサービスを提供する高可用性クラスタを、前記高可用性クラスタのマシン群を含むノード間においてスプリット・ブレイン状態を生じさせることなくフェイルオーバを提供するべく動作させる方法であって、
    ａ）前記マシン群の中からｍ台（ｍは少なくとも２である）のマスタ候補を特定するステップと、
    ｂ）前記マシン群の中からｎ台（ｎは少なくとも３でありかつ奇数である）のクォーラム・マシンを特定するステップと、
    ｃ）前記ｍ台のマスタ候補の各々を同期的に更新して、カレント・ステートを維持するステップと、
    ｄ）前記クォーラム・マシン群からのクォーラムベースの多数決によって、前記ｍ台のマスタ候補からカレント・マスタを選出するステップと、
    ｅ）前記カレント・マスタに対して、該カレント・マスタに属するローカル・クロックで測定することにより求められるカレントの期限付きリースを発行し、前記カレント・マスタが、前記カレントの期限付きリースを保持している間に、前記少なくとも１台のネットワーク・クライアントによって要求されたサービスを実行するステップと、
    ｆ）前記カレントの期限付きリースの相対的なクロック・スキューを或る上限に抑制するステップとを含み、
    前記カレント・マスタに障害が発生した場合に、前記ｍ台のマスタ候補の中から新たなマスタへのフェイルオーバをトリガし、前記新たなマスタに対して新たな期限付きリースを発行し、それによって前記マスタ候補間のスプリット・ブレイン状態を防止するようにしたことを特徴とする方法。
16. 前記ｍ台のマスタ候補からカレント・バックアップ・マスタを選出するステップをさらに含むことを特徴とする請求項１５に記載の方法。
17. 前記新たなマスタが前記カレント・バックアップ・マスタであり、前記フェイルオーバが前記カレント・バックアップ・マスタへのフェイルオーバであることを特徴とする請求項１６に記載の方法。
18. 前記相対的なクロック・スキューを抑制する前記ステップが、データ補正間の遅延、前記ローカル・クロックの物理的特性、前記ローカル・クロック及びセントラル・クロック間のドリフトからなる群の中からから選択された物理パラメータから決定される調節を含むことを特徴とする請求項１５に記載の方法。
19. マシン群を含むノード間においてスプリット・ブレイン状態を生じさせることなくフェイルオーバを行う能力を有する高可用性クラスタであって、
    ａ）前記マシン群の中から特定されたｍ台（ｍは少なくとも２である）のマスタ候補と、
    ｂ）前記マシン群の中から特定されたｎ台（ｎは少なくとも３でありかつ奇数である）のクォーラム・マシンと、
    ｂ）前記ｍ台のマスタ候補の中からステートを同期的にレプリケートしかつ更新してカレント・ステートを維持するためのローカル・エリア・ネットワークと、
    ｃ）前記ｍ台のマスタ候補の中からカレント・マスタを選出するための、前記クォーラム・マシン群からのクォーラムベースの多数決プロトコルと、
    ｄ）前記カレント・マスタに対して、該カレント・マスタに属するローカル・クロックで測定することにより求められるカレントの期限付きリースを発行するための機構と、
    ｅ）前記カレントの期限付きリースの相対的なクロック・スキューを或る上限に抑制するための物理パラメータとを含み、
    前記カレント・マスタに障害が発生した場合に、前記ｍ台のマスタ候補の中から新たなマスタへのフェイルオーバをトリガし、前記新たなマスタに対して新たな期限付きリースを発行し、それによって前記マスタ候補間のスプリット・ブレイン状態を防止するようにしたことを特徴とする高可用性クラスタ。
20. 前記クォーラムベースの多数決プロトコルがＰａｘｏｓであることを特徴とする請求項１９に記載の高可用性クラスタ。
21. 前記マスタ候補が、ネーム・ノード・マスタ候補であることを特徴とする請求項１９に記載の高可用性クラスタ。
22. 前記物理パラメータが、データ補正間の遅延、前記ローカル・クロックの物理的特性、前記ローカル・クロック及びセントラル・クロック間のドリフトからなる群から選択されたものであることを特徴とする請求項１９に記載の高可用性クラスタ。
23. 前記ノードが、ブロック・ストレージ・デバイスを備えた分散型ストレージ・システムを含むことを特徴とする請求項１９に記載の高可用性クラスタ。

Images