JP2007528557A - スケラブルなソフトウェアをベースにしたクォーラムアーキテクチャ - Google Patents

Abstract

コンピュータのクラスタは、通常、1台以上のコンピュータまたはそれらの関連する構成要素の故障から回復しなければならないアプリケーションにおいて、共用データストア等の共用リソースへのアクセスを調整するために、クォーラム、つまり合意を確立するためのソフトウェア方法を確立する。単一のクォーラムをクラスタ全体に関連付ける従来の技術はクラスタのサイズを少数台のコンピュータに制限する固有のオーバヘッドを有する。本発明は、コンピュータのクラスタの動作を調整するためにクォーラム機構を実現するためのスケラブルなソフトウェアをベースにしたアーキテクチャを備える。従来の技術と対照的に、本発明は全体としてクラスタから分離され、クラスタのメンバーシップの指定された部分集合に及ぶ、クォーラムオブジェクトと呼ばれるソフトウェア構成物の中にクォーラムを有利にカプセル化する。クラスタのメンバーシップ全体で分散される複数のクォーラムオブジェクトを利用することによって、クラスタは区分化されたデータベース管理システム等の、スケラブルな処理作業付加を処理する多数のコンピュータに均一にスケールできる。本発明の一つの実施形態を実現するソフトウェア方法が詳細に説明される。

Description

（関連出願の相互参照）
本願は、２００４年3月９日に出願された仮特許出願、出願番号第６０／５５１４２５号の利点を受ける権利がある。

本発明は、ノードがクラスタのリソースについて責任を負うことができるようになる前にノードの十分なクォーラムを必要とすることに関連付けられる方法に関する。

データを記憶し、取り出すためのコンピュータシステムは、ともにデータベース管理システムつまりＤＢＭＳとして一般的に知られているものを形成する、図１に示されるようなデータマネージャと呼ばれる、物理データストア（記憶装置）とソフトウェアサービスからなる。ＤＢＭＳがコンピュータの故障を切り抜け、そのクライアントにサービスを提供し続けることが望ましい。このようなＤＢＭＳは高可用性ＤＢＭＳと呼ぶことができる。（なお、この高可用性という用語はコンピュータの文献の中ではさまざまな定義を有し、この定義は本書の目的のために使用される。）ＤＢＭＳを高可用性にするための周知の方法は、クラスタと呼ばれる複数の協同するコンピュータを利用することである。データマネージャはあるコンピュータで実行し、故障が発生した場合は別のコンピュータで再起動される。データは（記憶領域ネットワーク上のディスクアレイ等の）単一の共用物理媒体を使用すること、１つ以上のコンピュータのローカルストアにデータの同一のコピーを保存し、コンピュータ間で必要に応じて変更を複製することのどちらかによってコンピュータによって共用される。これらの２つのクラスタアーキテクチャは図２と図３にそれぞれ示される。これらの図では、データマネージャはクラスタ内のホスト０で実行する。図４と図５はそれぞれ、ホスト０の故障後のこれらのクラスタを示す。クラスタが、故障の前にホスト０で実行していたデータマネージャに代わるためにホスト１で新しいデータマネージャを起動したことに留意する。図５では、ホスト１のストア（ローカルストア１）がホスト０のデータマネージャのためのレプリカストアとして働き、以後、ホスト０の故障後には一次ストアホスト１のデータマネージャとなる。ホスト２のストア（ローカルストア２）は、ホスト１のデータマネージャのためのレプリカストアである。

データストアの完全性を維持するために、（ホストとも呼ばれている）さまざまなコンピュータ上で実行しているデータマネージャは、単一のデータマネージャだけがデータストアを更新するように、それらのアクションを適切に調整することが肝要である。そうでなければ、データストアに対する更新は上書きされ、失われることがあるであろう。例えば、共用されるデータストアを使用するＤＢＭＳが、ネットワーク化されたクライアントコンピュータからＵ１、Ｕ２、Ｕ３及びＵ４とラベルが付けられる、４回の順次的な更新を処理する図６の例を考慮する。データマネージャは最初にホスト０で実行し、更新Ｕ１とＵ２を無事に完了する。ホスト０は更新Ｕ３を受信後、一時的にホスト１と通信せず、短期間で更新Ｕ３を完了しない処理遅延を被る。ホスト１はホスト０の故障としてこの遅延を監視し、更新の該処理を引き継ぐ新しいデータマネージャを起動することにより回復する。ホスト１のデータマネージャが（クライアントがリトライした後に）Ｕ３を、次にＵ４を完了する。この時点で、ホスト０は正常な動作を再開し、更新Ｕ３を完了する。更新Ｕ３は順序が狂って（つまりＵ４の後に）完了されるため、更新Ｕ４は失われ、データストアは破壊される。多くの場合スプリットブレインと呼ばれるこの望ましくない動作は、故障を検出し、故障から回復した際にホスト０とホスト１がそれらのアクションを適切に調整できないことから生じる。図７は、複製されたデータストアを使用するＤＢＭＳとの類似したシナリオを示し、データストアのレプリカが食い違うようになり、したがって破壊する。ホスト０は、正常な動作を再開した後で、そのローカルストアにＵ３を記憶し、Ｕ３をローカルストア１に複製する。これはローカルストア１の中の更新Ｕ４を上書きし、更新Ｕ４は失われる。

前記で分かるように、さまざまなクラスタホスト上で実行しているデータマネージャ間での不適切な調整は更新の損失につながることがある。この問題は、通常、更新要求を処理する厳密に１つのアクティブデータマネージャがあることを保証することによって解決される。この場合、データマネージャは、別のデータマネージャが実行している間予想外に動作を再開することはできない。データマネージャを実行する等のクラスタのアクションを調整するために単一のクラスタホストを指定するプロセスは最初に、クォーラムと呼ばれる実行中のクラスタホストの一意の部分集合を確立し、次にこの部分集合の中でクォーラムリーダーと呼ばれる単一のホストを選ぶことによって達成できる。クォーラムは、相互に通信できるクラスタ内のホストのグループを包含する。複数のこのようなグループが通信故障のために存在する場合があり、クォーラムを確立するための方法は、単一のクォーラムが形成されることを保証する。クォーラムの外部のクラスタホストは作業負荷の処理に参加しない。一意のクォーラムリーダーは、データマネージャを実行するためにクォーラムの中で特定のホストを指定するので、そのデータストアが破壊され、損失された更新になることはない。

単に高可用性ＤＢＭＳを構築すること以上に、大きなかつ拡大する処理負荷を処理するために、ＤＢＭＳの性能をスケール（拡大縮小）することがきわめて望ましい。ＤＢＭＳをスケールするための周知の技法は、ＤＢＭＳのデータストアを、それぞれがその関連するストアを処理する高可用性データマネージャを備える複数のより小さいストアに区分化する。（クォーラムリーダーによって選択されるような）クラスタ内のさまざまなホストで区分を実行することによって、ＤＢＭＳの総合的な性能はクラスタメンバーシップのサイズに従って上昇する。非常に大きなＤＢＭＳ処理負荷を処理するためには、大きなクラスタ（例えば６４以上のホスト）が必要とされる可能性がある。したがって、大きなクラスタを収容するためにクォーラムスケールを確立するための方法が必要である。

なお、高可用性システムにおける複数のコンピュータによる共用リソースへのアクセスを調整するためには一般的にはクォーラムが有効である。ＤＢＭＳ内のデータストアに加えて、これらのリソースは共用メモリシステム、周辺装置、及び（船舶の操舵装置の舵用の油圧アクチュエータ等の）外部コントローラを含むことがある。

コンピュータのクラスタ全体でクォーラムを確立するために従来の技術で考案されてきた複数の方法がある。共用データストアを使用するとき、トークンがストア内（例えばディスク上）に保持され、厳密に１つのクラスタホストによって確保される。これは共用ストアクォーラムプロトコルと呼ばれる。他のホストは、トークンを保持していない間はデータマネージャを実行しない。複製されたデータストアを使用するときには、クラスタホストは、クォーラムリーダーを選択するための過半数ホストクォーラムプロトコルと呼ばれるプロトコルを使用できる。このプロトコルは、最初に通信ホストの集合がすべてのクラスタホストの過半数に相当することを証明し、次に、クォーラムリーダーの役割をし、データマネージャを実行するためのある特定のホスト（例えば最低のホスト識別子が設定されたホスト）を選択する。ホストの過半数が存在していることを確認することによって、クラスタホストの２つの通信していないサブグループは独立したクォーラムを同時に形成することはできない。非常に重要な場合である２つのホストがあるクラスタでは、これらの２つのホストが通信できないときにはクォーラムを形成することはできない。この状況では、他のホストが故障したのか、あるいは単に通信できないのかを判断することはできず、前述されたスプリットブレインの問題を回避するためにクォーラムは形成されない。

クラスタホストが前記方法でクォーラムを形成するためには、それらは最初にクラスタのメンバーシップ、つまりクラスタを形成するために協同するクラスタの集合を決定しなければならない。各ホストは、メンバーシップリストと呼ばれる、クラスタ集合と呼ばれるクラスタ内のホストのそのビューを列挙するリストを維持し、他のホストがグループに加わったまたはグループを離れたことを検出するとリストを修正する。ホストは自発的にグループを離れることができる、あるいはホストは故障を被り、他のホストと通信するのをやめた後に、不本意ながらも離れる。クラスタのメンバーシップのインプリメンテーションは、必要な場合にクォーラムを確立し直すことができるようにクラスタ集合の中の変化を迅速に検出する必要がある。過半数のホストクォーラムの場合、考えられる最大のクラスタメンバーシップについてすべてのホストが過去に一致したに違いなく、クラスタホストが新規に追加される、あるいは恒久的にクラスタから削除されるたびにこの一致が確立し直されなければならない。

高可用性ＤＭＢＳの性能をスケールするために、周知の技法がＤＢＭＳのデータストアを、これらのサブストアの各部を処理するデータマネージャを備える複数のさらに小さいストアに区分化する。（クォーラムリーダーによって選択されるような）クラスタ内のさまざまなホストで区分を実行することにより、ＤＢＭＳの総合的な性能はクラスタメンバーシップに応じて上昇する。

クォーラムを確立するための前述された方法は、多くのクラスタホストがある大きなクラスタには良くスケールしない。共用ストアプロトコルでは、トークンを保持するための共用データストアの使用は、クラスタ集合が大きくなるにつれてストアのトークンを争うための遅延が増加するのに伴いボトルネックとなる。過半数ホストプロトコルは、ホストの過半数が存在することを証明し、恒久的なメンバーシップの変化が発生した後に一致を確立し直すためにかなりの通信オーバヘッドを必要とする。このオーバヘッドは、クラスタ集合のサイズが拡大するにつれて急速に上昇する。また、過半数ホストクォーラム方法は、それが奇数のクラスタ集合サイズを必要とするために正常にスケールしない。これらの及び他の理由から、高可用性ＤＢＭＳクラスタは、通常相対的に少ない数のクラスタホスト（例えば２つから８つのホスト）を有する。

該スケーリングの問題を解決するために、大きなＤＢＭＳクラスタは、通常、サブクラスタと呼ばれる複数の独立したクラスタを集めることによって構築される。例えば、図８は、２つのサブクラスタから構成される４つのホストのあるクラスタを示している。サブクラスタのクラスタはスーパークラスタと呼ばれる。クラスタのクォーラムをスケールする問題を回避する一方で、この手法はいくつかの点で全体的な設計を複雑にする。各クラスタホストは、サブクラスタ内のあるメンバーシップと、スーパークラスタ内のもう１つのメンバーシップという２つのメンバーシップに参加することが必要となる。スーパークラスタの高可用性を保つためには、各サブクラスタ内で高可用性を実現するための機構がスーパークラスタのために複製されなければならない。クラスタホストは厳密に１つのサブクラスタに参加しなければならず、それらのリソースを処理負荷をバランスするためにサブクラスタの間で共用することはできない。

本発明は、（データベースのパーティション等の）複数の共用リソースに対するアクセスを制御するために、コンピュータクラスタ内の（ホストと呼ばれる）複数のコンピュータのアクションを調整する。これは、それぞれがクォーラムオブジェクトと呼ばれる別個の論理構成物として実現される複数の独立したクォーラムアルゴリズムを利用することにより達成される。各クォーラムオブジェクトは、複数の共用リソースの内の１つへのアクセスを制御する。クラスタ内のホストの２つ以上が各クォーラムオブジェクトのメンバーとして割り当てられる。任意のホストは、クォーラムオブジェクトが重複するメンバーシップを有するように複数のクォーラムオブジェクトのメンバーであってよい。新しいクォーラムオブジェクトは共用リソースごとに必要に応じて作成されてよく、その後そのリソースを管理するために使用される、クラスタ内のホストの部分集合に割り当てられてよい。このようにして、コンピュータクラスタは（ａ）すべてのホストの単一クォーラムがすべての共用リソースを管理すること、または（ｂ）新しいサブクラスタが追加されること（つまり、複数の新しいホストが排他的にそのクォーラムに割り当てられる新しいクォーラム）のどちらかを必要とすることによる代わりに、単一のホストを追加することによってスケールできる。

本発明は添付図面と関連してさらに説明される。

本項では最初に本発明と説明し、次にその論理的根拠及び利点を説明する。

クォーラムを実現するための従来の技術は、単一のクォーラムをクラスタ全体に関連付け、この方法はクラスタのサイズを少数のコンピュータに制限する固有のオーバヘッドを有する。このスケーリングの問題を解決するために複数の独立したサブクラスタを使用すると、全体的なアーキテクチャに新たな複雑さと不撓性が加わる。対照的に、本発明は、クラスタのメンバーシップの指定された部分集合で実行する、クォーラムオブジェクトと呼ばれる新しいソフトウェア構成物を定義する。クォーラムオブジェクトはクォーラムのインプリメンテーションを全体としてのクラスタへの適用から分離する。代わりに、クラスタはクォーラムオブジェクトのホストをつとめるためのコンピュータリソースの一様なプールとなり、クォーラムオブジェクトはクラスタのホストの部分集合に渡るクォーラムのインプリメンテーションをカプセル化する。クラスタのメンバーシップ全体で分散される複数のクォーラムオブジェクトを利用することにより、クラスタは区分化されたデータベース管理システム等の大きな処理作業負荷を処理する多数のコンピュータに均一にスケールできる。

各クォーラムオブジェクトはそれ自体のクォーラムを確立し、それが実行するコンピュータの中でクォーラムリーダーを指定する。一実施形態では、クォーラムオブジェクトは、それがマッピングされる先のクラスタホストのそれぞれで実行するＱＯローカルマネージャと呼ばれる分散ソフトウェアプログラムとして実現される。ソフトウェアプログラムの「インスタンス」は各ホストで実行し、これらのプログラムはメッセージを交換することによって通信する。例えば、図９は２つのクォーラムオブジェクトのある４ホストクラスタを示す。クォーラムオブジェクト０はホスト０、１、及び２にマッピングされ、クォーラムオブジェクト１はホスト１、２及び３にマッピングされる。各クォーラムオブジェクトは別々のホストで実行し、他のホストでそれらのコンパニオンマネージャと通信する３つのＱＯローカルマネージャを備える。

クォーラムオブジェクトは共用記憶クォーラムまたは過半数ホストクォーラムのどちらかを実現する。これらのクォーラムを実現するためのアルゴリズムは従来の技術である。共用記憶クォーラムの場合、各クォーラムオブジェクトは別の共用ストアにアクセスし、すべてのデータストアは、クラスタホストが接続される記憶領域ネットワークに接続される。例えば、図１０は、２つのクォーラムオブジェクトと２つの共用ストアがある４ホストクラスタを示している。この例では、クォーラムオブジェクト０はデータストア０にマッピングされ、クォーラムオブジェクト１はデータストア１にマッピングできるであろう。図９に示されているように過半数ホストクォーラムの場合、クォーラムオブジェクトは、それがマッピングされる先のホスト上のローカルデータストアを使用し、クラスタホスト間の記憶領域ネットワークは必要とされない。なお、クォーラムオブジェクトを使用すると、過半数のホストクォーラムオブジェクト各々だけが奇数のホストを必要とするため、過半数ホストクォーラムの集合のためのクラスタメンバーシップが、図９に示されているように偶数のホストを有することができる。クォーラムオブジェクトは、優れた負荷バランスを達成するために必要に応じて重複するホストに単独でマッピングできる。

共用ストアまたは過半数ホストクォーラムのどちらかの場合、クォーラムオブジェクトは、それがマッピングされる各クラスタホストに、そのホストがクォーラムリーダーであるかどうかを知らせるソフトウェア方法を実現する。この方法は、クォーラムオブジェクト内の各ＱＯローカルマネージャによって実現され、ＱＯローカルマネージャはそのユーザに一貫性のある結果を配信するために協同する。一実施形態では、ＱＯローカルマネージャは、ローカルホストがクォーラムオブジェクトの一意のクォーラムリーダーであるかどうかを示すブール値（つまり、ＴＲＵＥ（真）またはＦＡＬＳＥ（偽））を戻すソフトウェア関数Ｉｓ＿ｑｕｏｒｕｍ＿ｌｅａｄｅｒを実現できる。クォーラムオブジェクトがクォーラムを確立した場合、クォーラムオブジェクトのＱＯローカルマネージャの内の厳密に１つだけがＴＲＵＥを戻す。それ以外の場合、すべてのＱＯローカルマネージャはＦＡＬＳＥを戻す。図１１は、クォーラムオブジェクト０のクォーラムリーダーの役割をするホスト１のある過半数ホストクォーラムのためのＩｓ＿ｑｕｏｒｕｍ＿ｌｅａｄｅｒによって戻される値の例を示す。クォーラムリーダーの役割をするクラスタホストが故障すると、クォーラムオブジェクトはクォーラムを確立し直そうと試み、その後、この関数が呼び出されると別のホストのＱＯローカルマネージャがＴＲＵＥを戻すのを開始する。なお、ＱＯローカルマネージャが、それがクォーラムリーダーになるか、あるいはクォーラムリーダーとしての役割をするのをやめるときに、非同期イベントを生成するようインプリメントされる。

クォーラムオブジェクトは、クォーラムを実現し、ホスト故障の場合に所望される高可用性を提供するのに十分であるホストのクラスタの数にマッピングされる。例えば、共用ストアクォーラムは（図１０に示されているように）単一のホスト故障から回復するために２つのホストだけを必要とする。過半数ホストクォーラムは（図９に示されているように）単一のホスト故障から回復するために３つのホストを必要とし、その結果それは１つのホストが故障した後に２つのホストの過半数を保持できる。クォーラムオブジェクトは、ホスト故障に対するその許容値を高めるために必要に応じて追加のホストにマッピングできる。

本明細書では以後外部マッピング実施形態と呼ばれる一実施形態では、クラスタホストへのクォーラムオブジェクトのマッピングは、マッピングエージェントと呼ばれる外部ソフトウェア関数により達成される。このエージェントは、クォーラムオブジェクトをどのクラスタホストにマッピングするのかを判断するために根本的なクラスタメンバーシップを利用し、それらの選択されたホストでクォーラムオブジェクトのためのＱＯローカルマネージャを作成する。クォーラムオブジェクトがマッピングされるホストが故障すると、クラスタメンバーシップは、すべての生き残っていえるホスト上のマッピングエージェントとクォーラムオブジェクトのＱＯローカルマネージャの両方に知らせる。クォーラムオブジェクトはクォーラムがまだ存在するのかどうかを判断し、相応して各クラスタホストのＱＯローカルマネージャの中のＩｓ＿ｑｕｏｒｕｍ＿ｌｅａｄｅｒの値を調整する。故障したホストが恒久的にクラスタから外されると、マッピングエージェントは、新しい代替ホストにクォーラムオブジェクトをマッピングし直すことができる。作業負荷のバランスを取り戻すために、再マッピング中にクォーラムを一時停止することがあるが、クォーラムオブジェクトにホストの新しい集合にマッピングし直すように命令することもできる。クォーラムオブジェクトは再マッピング後にクォーラムを確立し直すことの詳細をカプセル化する。

以後自己組織実施形態と呼ばれる別の実施形態は、各ホストが構造の中でその隣接するホストを決定できるように、すべてのクラスタホストがｎ次元アレイのような規則正しい構造に編成されるクラスタメンバーシップを構築するための根本的な方法の使用に依存する。この実施形態では、外部マッピングエージェントは、最初に、単一ホスト上で、ＱＯローカルマネージャをこのホスト上に作成させるクォーラムオブジェクトを作成する。クォーラムを確立するために、この結果として生じるＱＯローカルマネージャは、次にそれらのホスト上にＱＯローカルマネージャを作成することによって、隣接するホストをクラスタメンバーシップからクォーラムオブジェクトに追加する。例えば、３つのホストに及ぶことになる過半数ホストクォーラムオブジェクトは、図１２に示されているように２つの最も近い近傍系をオブジェクトに追加する。隣接するホストが恒久的に故障し、別のクラスタホストで置換される場合は、クォーラムオブジェクトは、図１３に示されるように新しい近傍系にＱＯローカルマネージャを自動的に作成するであろう。なお、３ホストクォーラムオブジェクトを使用すると、１つのホストが故障した後も過半数ホストクォーラムが失われないことが保証される。同様に、マッピングエージェントは、クォーラムオブジェクトにその初期のＱＯローカルマネージャを別のホストに移動するように命令することによって作業負荷目的のために、クォーラムオブジェクトを別のクラスタホストに移動できる。この場合、ＱＯローカルマネージャは必要に応じて隣接するホストにそのコンパニオンマネージャを移動させ、それからクォーラムを確立し直す。

（論理的根拠及び利点）
異なるホストまたは重複するホストにマッピングされる複数のクォーラムオブジェクトを使用することによって、処理負荷の管理（例えば、区分化されたＤＢＭＳ内のデータ区分）がクラスタホストの大きなプール全体で均一に拡散できる（多くの負荷バランシング技法が周知であり、クラスタホストの集合全体でクォーラムオブジェクトを負荷分散するための特定の方法はここでは説明されていない）。クォーラムオブジェクトはデータストアの各区分を管理し、作業負荷はクォーラムオブジェクトがマッピングされるクラスタホスト全体で負荷調整される。クォーラムオブジェクトは、処理負荷のバランスを動的に取り戻すために必要に応じてクラスタホストの間で移動できる。クォーラムオブジェクトの使用は、それにより単一の一様なクラスタメンバーシップ全体で区分化されたデータストアのクォーラムをベースにした管理をスケールする問題を解決する。スーパークラスタの使用を回避することによって、それは、各ホストが、ホスト故障を検出するための冗長な機構を組み込む２つの別個のクラスタメンバーシップに参加する必要を排除する。クォーラムホストは任意のクラスタホストにマッピングできるため、それは負荷バランスに対するさらに細かな制御も可能にする。

（本発明の一実施形態のためのソフトウェア方法）
以下のソフトウェア方法は、本発明の一実施形態がどのように実現できるのかを示す。これらの方法は３つのクラスタホストに及ぶ過半数ホストのアルゴリズムを使用して自己組織クォーラムオブジェクトを実現する（３つのクラスタホストを使用することにより、利用されるクォーラムリーダーを決定するための単純なマスタ／スレーブアルゴリズムが可能になる）。前述されたように、この実施形態は、各ホストが線形アレイ内でその隣接するホストを決定できるように、すべてのクラスタホストが一次元アレイに編成される根本的なクラスタメンバーシップの使用に依存する。クラスタメンバーシップが、隣接するホストの追加、離脱、及び故障を検出し、報告するために、各クラスタホストの中で必要な機構を組み込むことが仮定される。例えば、クラスタメンバーシップアルゴリズムは、通常、ホスト故障を検出するために周期的な「心臓鼓動」メッセージ交換を利用する。ソフトウェア方法は、これらの方法の複数のインスタンスがメッセージを送信することによって通信できるように、クラスタホスト間の信頼できるメッセージパス機構も利用する。

（ＱＯローカルマネージャをクォーラムオブジェクトに追加する方法）
外部マッピングエージェントは、当初、所望されるクラスタホスト上でそのＱＯローカルマネージャを起動することによりクォーラムオブジェクトを作成する。このインプリメンテーションでは、このクラスタホストは、いったんクォーラムが確立された後にクォーラムリーダーとしての役割をする。マスタマネージャと呼ばれる初期のＱＯローカルマネージャは、図１４に示されるソフトウェア方法を実行する。それは、クラスタメンバーシップに隣接するホストが存在すると判断した後に、クォーラムオブジェクトのためにスレーブマネージャを作成する、隣接するホストの実行時システムにマネージャ作成メッセージを送信することによって、スレーブマネージャと呼ばれるＱＯローカルマネージャを隣接するホスト上で起動する。スレーブマネージャは、起動したことを示すために作成応答メッセージを送信する。このメッセージを受信すると、マスタマネージャはクォーラムリーダーになり、Ｉｓ＿ｑｕｏｒｕｍ＿ｌｅａｄｅｒ関数に対する応答をＴＲＵＥに設定する。マスタマネージャが別の隣接するホストが存在すると判断すると（それは、ホストがただちに使用可能ではない場合にはクラスタメンバーシップからの通知を待機する必要がある場合がある）、それは他の隣接するホスト上で第２のスレーブマネージャを起動するためにこのプロセスを繰り返す。３つのＱＯローカルマネージャを使用することにより、１つのホストが予想外に故障した場合にもホストの過半数がいるクォーラムを維持できる。

（故障したＱＯローカルマネージャから回復するための方法）
図１５は、そのスレーブマネージャを実行している１つ以上のクラスタホストの故障後にマスタマネージャによって実行されるアルゴリズムを示す。クラスタメンバーシップは、クラスタホストが故障するとマスタマネージャに通知する。マスタマネージャのホストを隔離する通信故障が、すべてのリモートホストの故障にみせかけられることに留意する。両方のスレーブマネージャが失敗すると、マスタマネージャは、クォーラムが失われたので、Ｉｓ＿ｑｕｏｒｕｍ＿ｌｅａｄｅｒ関数に対する応答をＦＡＬＳＥに設定する。マスタマネージャが実際に通信故障によってだけ隔離される場合には、スレーブマネージャは２つのホストのクォーラムを別個に形成する。次に、マスタマネージャは、スレーブマネージャを実行しているホストが回復したことをクラスタマネージャが通知するまで待機する。マスタマネージャはそれぞれの回復したスレーブマネージャにマスタアサートメッセージを送信し、応答を待機する。このメッセージは、クォーラムが存在する場合、スレーブマネージャにそれらのクォーラムを放棄するように示唆する。第１のスレーブマネージャがマスタマネージャに応答した後、マスタマネージャは再びクォーラムリーダーになり、Ｉｓ＿ｑｕｏｒｕｍ＿ｌｅａｄｅｒ関数に対する応答をＴＲＵＥに設定する。スレーブマネージャのホストが恒久的に故障した場合、マスタマネージャは代替ホスト上で新しいスレーブマネージャを作成できる（これを行うための方法は図１５に説明されていない）。

図１６は、マスタマネージャを実行するクラスタホストの故障の後にスレーブマネージャにより実行されるアルゴリズムを示す。マスタマネージャの場合と同様に、クラスタメンバーシップは、クラスタホストが故障するとスレーブマネージャに通知し、スレーブマネージャのホストを隔離する通信故障はすべてのリモートホストの故障にみせかけられることがある。スレーブマネージャは、別のスレーブマネージャが実行中である、マスタマネージャの他の隣接するクラスタホストにプローブ要求メッセージを送信することによってクォーラムを確立し直そうとする。スレーブマネージャは、クラスタメンバーシップからこれらの隣接するホストの識別子を決定する。スレーブマネージャが、他のスレーブマネージャがクラスタホストに初期にマッピングされるまたは再マッピングする間に故障が発生する可能性があるために他のスレーブマネージャの存在及び場所を認識していない可能性があることに留意する。このクォーラムオブジェクトのための別のスレーブマネージャがプローブ要求メッセージを受け取ると、自身を識別する応答を返す。両方のスレーブマネージャがこの要求／応答交換を実行した後に、相互のアイデンティティを決定し、例えば、ネットワークアドレスがより低いホストを選択することによって、所定のアルゴリズムを使用してクォーラムリーダーを選択できる。一方のスレーブマネージャがクォーラムリーダーになり、Ｉｓ＿ｑｕｏｒｕｍ＿ｌｅａｄｅｒ関数に対する応答をＴＲＵＥに設定し、マスタマネージャの故障後にクォーラムを確立し直す。マスタマネージャが後に回復すると、クォーラムリーダーにその制御権を放棄させ、Ｉｓ＿ｑｕｏｒｕｍ＿ｌｅａｄｅｒ関数に対する応答をＦＡＬＳＥにリセットさせるアサートマスタメッセージを両方のスレーブマネージャに送信する。スレーブマネージャはマスタマネージャに応答し、マスタマネージャは次にクォーラムリーダーを引き継ぐ。マスタマネージャのホストが恒久的に故障した場合、クォーラムリーダーとしての役割をするスレーブマネージャはマスタマネージャを引き継ぎ、代替ホスト上に新しいスレーブマネージャを作成することができる（これを行うための方法は図１６に説明されていない）。

したがって、本発明はその特定の実施形態を述べると説明されているが、本発明はそれに制限されない。詳細の変更は本発明の精神及び範囲の中で加えられてよく、前記精神及び範囲は幅広く解釈されるべきであり、これに添付されるクレームの特徴によって以外制限されるべきではない。

データベース管理システムの従来の技術のモデルを示す。 共用データストアのある２ホストフェイルオーバクラスタの従来の技術の例を示す。 複製されたデータストアのあるクラスタの従来の技術の例を示す。 ホストの故障及びデータマネージャのフェイルオーバの後の共用データストアのあるクラスタの従来の技術の例を示す。 ホストの故障及びデータマネージャの故障の後の複製されたデータストアのあるクラスタの従来の技術の例を示す。 ホスト０が処理及び通信の遅延から回復し、更新Ｕ３を記憶した後の共用データストアのあるクラスタの従来の技術の例を示す。 ホスト０が処理及び通信の遅延から回復し、更新Ｕ３を記憶した後の複製されたデータストアのあるクラスタの従来の技術の例を示す。 ４つのホストと２つのサブクラスタのある従来の技術の「スーパークラスタ」の例を示す。 ４つのホストと２つのクォーラムオブジェクトのあるクラスタの例を示す。 ４つのホスト、つまり２つの共用記憶クォーラムオブジェクトと記憶データネットワーク上の２つのデータストアのあるクラスタの例を示す。 クォーラムオブジェクトの中の「Ｉｓ＿Ｑｕｏｒｕｍ＿Ｌｅａｄｅｒ」ソフトウェア方法の例を示す。 隣接するホストに渡る３ホストクォーラムオブジェクトの作成で講じられるステップを示す。 クラスタホストが恒久的に故障し、新しいホストにより置換された後のスリーホストクォーラムオブジェクトの回復で講じられるステップを示す。 クォーラムオブジェクトにＱＯローカルマネージャを追加するためのソフトウェア方法を示す。 故障したスレーブマネージャから回復するためのマスタマネージャのソフトウェア方法を示す。 故障したマスタマネージャから回復するためのスレーブマネージャのソフトウェア方法を示す。

Claims (4)

1. 複数の共用リソースに対するクラスタのアクセスを制御するためにコンピュータクラスタ内で、ホストと呼ばれる複数のコンピュータのアクションを調整するための方法であって、
   ａ）それぞれが別個のクォーラムオブジェクトと呼ばれる論理構成物として実現される複数の独立したクォーラムアルゴリズムの使用を利用し、前記クォーラムオブジェクトが単一の共用リソースへのアクセスを制御することと、
   ｂ）各クォーラムオブジェクトのメンバーとなり、それにより前記共用リソースに対するアクセスを制御すべく前記クォーラムオブジェクトを使用するために前記クラスタ内で２つ以上のホストを割り当てることと、
   ｃ）前記クォーラムオブジェクトが重複するメンバーシップを有することができるように、任意のホストが複数のクォーラムオブジェクトのメンバーとなることをできるようにすることと、
   ｄ）複数の追加のホストが新しいクォーラムオブジェクトの排他的なメンバーとしてクラスタに追加されることを必要とする代わりに、必要に応じて新しいクォーラムオブジェクトを作成して前記クラスタ内のホストの部分集合に割り当てることをできるようにすることと、
   ｅ）単一のクォーラムメンバーシップのサイズを大きくすることまたはそのクォーラムに排他的に割り当てられる新しいクォーラム及び複数の新しいホストの追加を必要とすることの代わりに、単一のホストを追加することによって、それによってコンピュータクラスタのメンバーシップをスケールできるようにすることと、
   を備える方法。
2. クォーラムオブジェクトにホストを追加することをさらに含み、他のＱＯローカルマネージャとメッセージを交換することにより前記クォーラムオブジェクトのアクションへの前記ホストの参加をインプリメントするために、クォーラムオブジェクトのローカルクォーラムマネージャとして前記ホストが指定され、
   ａ）クォーラムオブジェクトのマスタローカルマネージャの使用により前記クォーラムオブジェクトのローカルクォーラムマネージャを調整し、前記クォーラムオブジェクトのアクションを実行するために、前記クォーラムオブジェクトのマスタローカルマネージャが一方のメンバーホスト上で実行し、１つ以上のスレーブクォーラムオブジェクトのローカルマネージャが他方のメンバーホスト上で実行することと、
   ｂ）ホストが前記クォーラムオブジェクトの前記メンバーシップに加わるときにクォーラムオブジェクトにＱＯローカルマネージャを追加することと、
   を備える請求項１に記載の方法。
3. 特定のクォーラムでの１つ以上のホストの故障時に新しいクォーラムオブジェクトのマスタローカルマネージャを選択することをさらに含み、前記カレントマスタローカルマネージャの前記検出された故障時に新しいクォーラムオブジェクトのマスタローカルマネージャを選択するスレーブローカルマネージャを備える請求項２に記載の方法。
4. 前記クォーラムオブジェクトのマスタローカルマネージャが、すべてのカレントスレーブローカルマネージャの前記検出された故障時にそのマスタステータスを放棄し、前記スレーブローカルマネージャの回復時にそのマスタシップをリアサートする請求項２に記載の方法。

Images