JP4339763B2

JP4339763B2 - フェイルオーバ方法及び計算機システム

Info

Publication number: JP4339763B2
Application number: JP2004259403A
Authority: JP
Inventors: 信之雑賀
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2004-09-07
Filing date: 2004-09-07
Publication date: 2009-10-07
Anticipated expiration: 2024-09-07
Also published as: US20060050629A1; JP2006079161A; US7428210B2

Description

本発明は、複数のノードを備えた計算機システムにおいて、障害の発生したノードの処理を引き継ぐ技術に関する。

複数の計算機（ノード）を論理的に一つの計算機として機能させるクラスタ技術が知られており、例えば、複数のサーバを一つのサーバとして機能させるクラスタサーバが知られている。

このクラスタサーバでは、一つの計算機に障害が発生すると、他の計算機が障害が発生した計算機の処理を引き継いで、サービスを続行するフェイルオーバ処理を行うものが知られている（例えば、特許文献１）。これは、フェイルオーバにより処理を引き継いだ後に自身の負荷が高くなると、他の計算機に処理を依頼するものである。
特開２００３−２５６３９９号

しかし、上記従来の技術では、フェイルオーバにより処理を引き継いだ計算機（ノード）は、自身の負荷が高くなるまで他の計算機（ノード）に処理を依頼しないため、処理能力に余裕のある他の計算機を利用することができず、負荷が偏った状態が継続するという問題がある。

また、上記従来例では、処理の引き継ぎを多段で行うものの、複数のノードで処理の引き継ぎを行う際に、一つのリソースをどのように引き継ぐかという思想はない。このため、一つのノードに障害が発生して複数のノードで処理を引き継ぐ多段フェイルオーバを行う場合では、一つのリソースを複数のノードで引き継ごうとするリソースの競合が発生する可能性がある。

そこで本発明は、上記問題点に鑑みてなされたもので、フェイルオーバ後の複数の計算機の負荷を均一にすることを目的とし、さらに、リソースの競合を防ぐことを目的とする。

本発明は、複数のノードからなるクラスタを有し、複数のノードのいずれかに障害が発生したときに、障害の発生したノードの処理を他のノードへ引き継ぐフェイルオーバ方法であって、前記複数のノードのいずれかに障害が発生したときに、障害の発生したノードの処理を他のノードへ引き継ぐ引き継ぎ情報を、複数のノードで共有する記憶装置に予め格納する。複数のノードは相互に稼動状態を監視し、障害の発生を検知したときには、障害が発生したノードを除くクラスタ内の各ノードが、前記共有記憶装置から引き継ぎ情報を読み込んで、障害のパターンと引き継ぎ情報に基づいて障害が発生したノードの処理を引き継ぐ。前記引き継ぎ情報は、各ノードの処理毎に引き継ぐ回数の上限が設定され、また、現在の引き継ぎ回数と前記引き継ぐ回数の上限に基づいて選択された他のノードに引き継ぐ処理が含まれる。

したがって、本発明は、フェイルオーバ時の引継ぎ対象を分割して、複数のノードに対して、分散してフェイルオーバを行うことで、フェイルオーバ後の複数のノード間の負荷の偏りを抑えることができる。

また、多段フェイルオーバになった場合には、引き継ぐリソースを絞り込むことで、負荷増加を抑えることができる。

また、フェイルオーバでの引継ぎ処理で、複数のノードが１つのリソースを引き継ごうとするリソースの競合が発生せず、なおかつフェイルオーバまたはフェイルバックを並列的に行うことができるので、引き継ぎまたは回復を高速かつ正確に行うことができる。

以下、本発明の一実施形態を添付図面に基づいて説明する。

図１は、本発明を適用する計算機システムの全体的な構成を示すブロック図で、図２は計算機システムのソフトウェア構成を示すブロック図である。

図１において、クラスタ１００を構成する複数のノード１〜４は、それぞれサーバ２０、３０、４０、５０より構成され、ネットワーク５を介して接続されたクライアントコンピュータ８０からは単一のサーバとして認識される。

ネットワーク５には、クラスタ１００を管理する管理サーバ１０が接続される。この管理サーバ１０は、後述するように、クラスタ１００の構成や各種設定情報を管理するもので、管理者などにより運用される。

管理サーバ（管理ノード）１０は、ＣＰＵ１１、メモリ１２、データ転送コントローラ１３、ネットワークインターフェース１４及びストレージ用のインターフェース１５が設けられている。そして、ネットワークインターフェース１４を介して管理サーバ１０がネットワーク５に接続される。また、インターフェース１５を介してＣＰＵ１１などが設定情報などを格納するディスク装置１６にアクセスを行うことができる。なお、メモリ１２にデータキャッシュ（図示省略）を設けても良く、あるいは、データキャッシュをデータ転送コントローラ１３側に設けても良い。

メモリ１２には制御プログラム（図３参照）がロードされており、ＣＰＵ１１が制御プログラムを呼び出して実行することによって後述する各種処理が行われる。

データ転送コントローラ１３は、ＣＰＵ１１、ネットワークインターフェース１４、ストレージインターフェース１５及びメモリ１２の間でデータを転送する。

クラスタ１００を構成するノード１〜４は、相互に接続されており、所定のサービスを並列的に提供し、いずれかのノードに障害が発生するとフェイルオーバ処理を行って他のノードへサービスを引き継ぎ、また、障害から復旧するとフェイルバック処理を行って、他のノードからサービスを引き継ぐものである。なお、本実施形態では、クラスタ１００はファイルの共有サービスを提供する場合について説明する。

まず、ノード１のサーバ２０には、ＣＰＵ２１、メモリ２２、データ転送コントローラ２３、ネットワークインターフェース２４及びストレージ用のインターフェース２５が設けられている。

そして、ネットワークインターフェース２４を介してサーバ２０がネットワーク５に接続される。また、インターフェース２５を介してＣＰＵ２１などがファイルを格納するディスク装置１６にアクセスを行う。さらに、インターフェース２５は、サーバ２０の外部に設けられて、他のノード（サーバ）と共有する共有ストレージ装置６に接続され、各ノード間で情報の共有を行う。

なお、メモリ２２にデータキャッシュ（図示省略）を設けても良く、あるいは、データキャッシュをデータ転送コントローラ２３側に設けても良い。

メモリ２２には制御プログラム（図４参照）がロードされており、ＣＰＵ２１が制御プログラムを呼び出して実行することによって後述する各種処理が行われる。

データ転送コントローラ２３は、ＣＰＵ２１、ネットワークインターフェース２４、ストレージインターフェース２５及びメモリ２２の間でデータを転送する。

ノード２のサーバ３０もノード１のサーバ２０と同様に構成され、ＣＰＵ３１、メモリ３２、データ転送コントローラ３３、ネットワークインターフェース３４及びストレージ用のインターフェース３５が設けられ、ネットワークインターフェース３４はネットワーク５に接続され、インターフェース３５はディスク装置３６と共有ストレージ装置６に接続される。

メモリ３２にはノード１のサーバ２０と同様の制御プログラム（図４参照）がロードされており、ＣＰＵ３１が制御プログラムを呼び出して実行することによって後述する各種処理が行われる。

ノード３のサーバ４０、ノード４のサーバ５０もノード１のサーバ２０と同様に構成され、ＣＰＵ４１、５１、メモリ４２、５２、データ転送コントローラ４３、５３、ネットワークインターフェース４４、５４及びストレージ用のインターフェース４５、５５が設けられ、ネットワークインターフェース４４、５４はネットワーク５に接続され、インターフェース４５、５４はディスク装置４６、５６と共有ストレージ装置６に接続される。

クラスタ１００に設けられた共有ストレージ装置６は、各サーバ２０〜５０から物理的に独立したストレージ装置で構成しても良いし、各サーバ２０〜５０（以下、ノード１〜４）で相互に参照及び更新可能な共有論理ディスクで構成しても良い。

図２は、管理サーバ１０とクラスタ１００のでそれぞれ実行される制御プログラムの機能ブロックを示す。

管理サーバ１０では、ＯＳ１０１上で引き継ぎ情報作成機能１１０が実行される。この引き継ぎ情報作成機能１１０は、クラスタ１００の各ノード１〜４を監視し、この監視結果と予め設定した設定情報１１１に基づいてフェイルオーバを行う際の引き継ぎ情報を作成し、クラスタ１００の共有ストレージ装置６に格納する。管理サーバ１０が作成した引き継ぎ情報は共有ストレージ装置６上で各ノード１〜４で参照可能となる。

ノード１〜４では、ＯＳ２１０がファイル共有機能をクライアントコンピュータ８０へ提供し、ＯＳ２１０上ではフェイルオーバ機能（処理）２２０が実行される。フェイルオーバ機能２２０は、一つのノードが障害などにより停止すると、他のノードが共有ストレージ装置６上の引き継ぎ情報を参照して、停止したノードが提供していたサービス（ファイル共有サービス）を各ノードの負荷が均等になるように引き継ぎを行うフェイルオーバ処理と、提供していたノードが復旧したときには、他のノードが引き継いでいたサービスを元のノードへ引き継ぐフェイルバック処理とを含む。

各ノード１〜４のディスク装置２６〜５６には、それぞれ異なる内容のデータが格納され、クライアントコンピュータ８０にファイル共有サービスを提供する。各ディスク装置２６〜５６には、後述するように、ノード１〜４毎に複数のファイルシステムが格納され、各ファイルシステムにデータが格納される。

図３は、管理サーバ１０で実行される引き継ぎ情報作成機能１１０の詳細な構成を示し、引き継ぎ情報作成機能１１０は状態別引き継ぎ情報作成処理１１２を含む。この状態別引き継ぎ情報作成処理１１２は、後述するように、ノード１〜４の状態を監視し、停止したノードの状態に応じて他のノードへ引き継ぐ処理を決定するものである。

図４は、ノード１〜４で実行されるフェイルオーバ機能２２０の詳細な構成を示す。フェイルオーバ機能２２０は、各ノード１〜４の状態を監視するクラスタ状態監視処理２２１と、他のノードに状態を問い合わせる状態確認要求処理２２２と、停止した他のノードが提供するサービスを引き継ぐフェイルオーバ処理２２３と、引き継いでいたサービスを復旧した元のノードへ引き継ぐフェイルバック処理２２４とから構成される。

＜全体的な処理の概要＞
次に、管理サーバ１０及び各ノード１〜４で行われる処理の概要について以下に説明する。

まず、管理サーバ１０は、各ノード１〜４からフェイルオーバに関連するリソース（ファイルシステムやネットワークに関するもの）の情報を収集し、さらに管理者が入力した設定情報１１１（引継ぎ回数の上限、ノード番号、ノード毎のＩＰアドレス等）を管理サーバ１０のメモリやディスク装置に格納する（図２のＳＡ）。

管理サーバ１０で収集／入力された情報に基づき、管理サーバ１０上では、多段フェイルオーバ時に引き継がれるリソースと各ノード１〜４のキャパシティを検証する。この検証が完了した後、引き継ぎに関する情報（状態別引き継ぎ情報）を出力し、各ノード１〜４で共有可能な共有ストレージ装置６に格納する（図２のＳＢ）。

各ノード１〜４で実行されるフェイルオーバ機能２２０は、各ノード１〜４を互いに監視し、停止したノードや復旧したノードがあれば、引継ぎに関する定義情報（状態別引き継ぎ情報）に基づいて、フェイルオーバ／フェイルバックを自動的に行う（図２のＳＣ）。なお、各ノード１〜４が行う相互の監視は、各ノード１〜４が共有ストレージ装置６を定期的に更新しているかどうかで稼動状態を確認する。

＜状態別引き継ぎ情報作成処理１１２の概要＞
次に、管理サーバ１０の引き継ぎ情報作成機能１１０で行われる状態別引き継ぎ情報作成処理１１２の概要について以下に説明する。

｛ＳＴＥＰ１｝
管理サーバ１０は、各ノード１〜４のサービス（ファイル共有）の負荷を計るため、図５で示すように、各ノード１〜４が提供しているファイルシステム毎の利用者数を集計し、ファイルシステム名に対応する利用者数（current_usr_num）をノード１〜４毎にまとめたファイルシステム利用者数リストを作成する。このリストは、管理サーバ１０のメモリ１２やディスク装置１６あるいは共有ストレージ装置６に格納する。

ファイルシステム毎の利用者数（クライアント数）は、各ノードからアクセスログを取得し、ファイルシステム毎にアクセスユーザ数をカウントする。

｛ＳＴＥＰ２｝
管理サーバ１０は、管理者などのユーザが設定した設定情報１１１から、各ノード１〜４のファイルシステム毎のフェイルオーバ時の引き継ぎ回数（上限値）を読み込む。引き継ぎ回数は、図６で示すように、各ノード１〜４に設けたファイルシステム名に対応する引き継ぎ回数の上限が設定され、「３」はフェイルオーバを３回まで行うことを示し、「０」はフェイルオーバを禁止することを示す。

なお、ファイルシステム毎のフェイルオーバ時引き継ぎ回数は、管理者などが予め設定したものである。また、図６のリストは引き継ぎ回数リストとして共有ストレージ装置６に格納される。

この引き継ぎ回数リストにより、フェイルオーバを行った回数に応じて、他のノードに引き継ぐファイルシステムを選択する。つまり、フェイルオーバの回数が増加すると、引き継ぎ先のノードは減少するため、引き継ぎ可能なリソースを減少させることで、多段フェイルオーバを行ってサービスの続行を継続することができる。

ここでは、ファイルシステム毎のフェイルオーバ時引き継ぎ回数を予め設定した例を示したが、上記ＳＴＥＰ１で求めたファイルシステム毎の利用者数と予め設定したしきい値を比較して自動的に引き継ぎ回数を決定するようにしても良い。

例えば、
利用者数＞１００人 → 引き継ぎ回数＝３
５０＜利用者数≦１００ → 引き継ぎ回数＝２
１０＜利用者数≦５０ → 引き継ぎ回数＝１
利用者数≦１０ → 引き継ぎ回数＝０
のように決定する。

すなわち、利用者数や利用頻度の高いファイルシステムの引き継ぎ回数の上限を高くし、利用者数が少なく、あるいは利用頻度が低いファイルシステムについては引き継ぎ回数の上限を低く設定する。

｛ＳＴＥＰ３｝
次に、管理サーバ１０は、設定した設定情報１１１からノード１〜４毎の最大利用者数（ユーザ数）を取得する。この最大利用者数は、各ノード１〜４の処理能力などの要件に基づいて管理者などが予め設定したものであり、図７で示すように、各ノード１〜４へ同時に接続可能な利用者数を示す。なお、図７は、ノードの番号と、各ノードに設定された最大利用者数のテーブルである。

｛ＳＴＥＰ４｝
管理サーバ１０は、各ノード１〜４の稼動状態に基づいて、クラスタ１００の状態を設定する。ここでは、図８で示すように、４つのノード１〜４の稼動／停止を全てのパターンについて検討する。ここでは、４ビットのビット列でクラスタ１００の状態を示す例について説明する。

後述するように、共有ストレージ装置６の更新状況に基づいて各ノード１〜４の稼動状態を判定する。そして、稼働中のノードに「０」をセットし、停止中のノードに「１」をセットする。

ここで、４ビットのビット列を（ｂ１、ｂ２、ｂ３、ｂ４）とすると、ｂ１がノード１の状態を示し、ｂ２がノード２の状態を、ｂ３がノード３の状態を、ｂ４がノード４の状態をそれぞれ示す。

そして、４つのノード１〜４が全て稼動している状態は、ビット列＝（０、０、０、０）であり、この状態を０段目（フェイルオーバが０段の意味）とし、この状態名を図８で示すようにＳ０とする。

次に、４つのノードのうちひとつが停止している状態を１段目とする。この１段目では、４通りのパターンがあり、ノード１が停止している状態名をＳ８、ノード２が停止している状態名をＳ４、ノード３が停止している状態名をＳ２、ノード４が停止している状態名をＳ１とする。ここで、状態名は、ビット列を１０進化した値に基づくものである。

次に、４つのノードのうち２つが停止している状態を２段目とする。この２段目では、６通りのパターンがあり、ノード１、ノード４が停止している状態名をＳ９、ノード１、ノード３が停止している状態名をＳ１０、ノード１、ノード２が停止している状態名をＳ１２、ノード２、ノード４が停止している状態名をＳ５、ノード２、ノード３が停止している状態名をＳ６、ノード３、ノード４が停止している状態名をＳ３とする。

同様に、４つのノードのうち３つが停止している状態を３段目とする。この４段目では、４通りのパターンがあり、ノード１、ノード２、ノード３が停止している状態名をＳ１４、ノード１、ノード２、ノード４が停止している状態名をＳ１３、ノード１、ノード３、ノード４が停止している状態名をＳ１１、ノード２、ノード３、ノード４が停止している状態名をＳ７とする。

最後に、４つのノード１〜４が全て停止している状態を４段目とする。

以上のように、クラスタ１００の状態を０〜４段目で示し、各ノード１〜４の具体的な状態を状態名とビット列で示したクラスタ状態リストを図８のように作成し、共有ストレージ装置６に格納する。すなわち、クラスタ状態リストは、クラスタ１００で発生しうる各ノード１〜４の全ての障害発生パターンを示したものである。

ここで、ノード１が停止した場合を例にして説明する。

いま、クラスタ１００が図５で示す状態でサービスを提供しているときに、ノード１が停止すると、図８のクラスタ状態リストにおいて１段目のＳ８となり、図６の引き継ぎ回数リストから、引き継ぎ回数＝３、２のファイルシステム名ｆｓ１１、ｆｓ１２、ｆｓ１３を他のノード２〜４へ引き継ぐ（割り当てる）ことになる。このフェイルオーバ処理の結果、引き継ぎ回数リストは、全てのファイルシステムについて引き継ぎ回数を１ずつ減算し、図９のようになる。

ここで、引き継がれるファイルシステムの利用者数は、図５より、
ｆｓ１１１００
ｆｓ１２８０
ｆｓ１３６０
であり、引き継ぐノード２〜４の利用者数と最大利用者数は、図５、図７より、
ノード２利用者数＝２９５最大利用者数＝４００
ノード３利用者数＝２４８最大利用者数＝３５０
ノード４利用者数＝１２５最大利用者数＝４００
となる。

（リソースの割当）
ｆｓ１１〜１３をノード２〜４に割り当てる方法の一例としては、ノード２〜ノード４の空きユーザ数（最大利用者数−利用者数）が大きい順に、ｆｓ１１〜ｆｓ１３の利用者数が大きいものから割当てる。

まず、各ノード２〜４の空きユーザ数は、
ノード２＝１１５
ノード３＝１０２
ノード４＝２７５
であるので、空きユーザ数の大きい順にソートを行うと、ノード４、２、３となる。そして、引き継ぐファイルシステムを大きい順にソートすると、ｆｓ１１、１２、１３となる。

したがって、図１０で示すように、ｆｓ１１をノード４に割り当て、ｆｓ１２をノード２に、ｆｓ１３をノード３に割り当てる。この結果、各ノード２〜４には利用者数の偏りを抑制して、引き継ぐリソースを割り当てることができる。

なお、上記割り当てに際しては、ノード２〜４の空きユーザ数が最大利用者数の１０％以上となるように制限を設けても良い。この制限を設けることで、各ファイルシステムのデータの増加に対応することができる。

また、割当に失敗したときには、引き継ぎ回数や最大利用者数を見直して、再度ＳＴＥＰ１からやり直す。

また、上記の割り当ては、状態名Ｓ１のときについて説明したが、状態名Ｓ２〜Ｓ１４についても、同様にファイルシステムの割り当てを検証する。

｛ＳＴＥＰ５｝
上記ＳＴＥＰ４の結果、状態名Ｓ０〜Ｓ１４について、図１１で示すような、リソースの引き継ぎリストを得ることができる。

このリソース引き継ぎリストは、全てのノード１〜４が稼動している状態Ｓ０から一つのノードのみが稼動している状態名Ｓ１４までのそれぞれについて、各ノードに割り当てるリソース（ファイルシステム）が各ノード１〜４に許容された最大値（最大利用者数）を超えない範囲で、割り当てた場合をフェイルオーバまたはフェイルバックが発生する以前に作成したものである。

そして、上記ＳＴＥＰ４の例のように、ノード１が停止して状態名Ｓ０からＳ８に移行する場合には、図中Ｓ８のようにノード２〜４にｆｓ１１〜１３が割り当てることが記載される。

｛ＳＴＥＰ６｝
以上のＳＴＥＰ４、５で作成した図１１のリソース引き継ぎリストを、共有ストレージ装置６に格納する。

｛ＳＴＥＰ７｝
次に、リソースの割り当てが完了すると、フェイルオーバ時のアドレス（例えば、ＩＰアドレス）の引き継ぎ状態を作成する。

例えば、上記の例のように、ノード１が停止した状態名Ｓ８では、ノード１のＩＰアドレスを他のノード２〜４に割り当てる。

あるいは、２つのノードが停止する場合、例えば、状態名Ｓ５のようにノード２、４が停止してノード１、３が引き継ぐ場合、以下のようにする。

まず、現在のクラスタ１００の状態から稼動しているノード及びその個数と、停止しているノード及びその個数を取得する。そして、稼動しているノードのリストを図１２のようにノードリスト・アライブとして、稼動しているノードを列記したリストを作成する。

同様に、停止しているノードのリストを図１３のようにノードリスト・ダウンとして、停止しているノードを列記したリストを作成する。

次に、ノードリスト・アライブ内の各ノードに対して、リストの上位から順に、１個ずつノードリスト・ダウン内のノードのＩＰアドレスを割り当てていく。

ノードリスト・ダウンのノードが余ったら、ノードリスト・アライブの先頭のノードに戻って再びリストの上位から順にノードリスト・ダウンのノードのＩＰアドレスを割り当てていく。

上記状態名Ｓ５の場合、図１２、図１３から、
ノード１：ノード２のＩＰアドレス
ノード３：ノード４のＩＰアドレス
をそれぞれ割り当てる。

以上の処理を状態名Ｓ１〜Ｓ１４についてそれぞれ行って、状態名Ｓ０〜Ｓ１４について、フェイルオーバ時のアドレスの引き継ぎリストを図１４のように作成し、このアドレス引き継ぎリストを共有ストレージ装置６に格納する。

以上のＳＴＥＰ１〜７が状態別引き継ぎ情報作成処理１１２の概要であり、この処理を所定の周期（例えば、数秒おきなど）で実行することにより、共有ストレージ装置６上には、最新の引き継ぎ回数リスト、クラスタ状態リスト、リソースの引き継ぎリスト、アドレス引き継ぎリストが更新されるのである。なお、クラスタ状態リスト、リソースの引き継ぎリスト、アドレス引き継ぎリストが状態別引き継ぎ情報を構成する。

＜クラスタ状態監視処理２２１の概要＞
各ノード１〜４で実行される、フェイルオーバ機能２２０を構成するクラスタ状態監視処理２２１の概要について、説明する。

各ノード１〜４は、共有ストレージ装置６に設定された確認テーブル（図１５参照）を所定の周期（監視間隔、例えば３０秒ないし１分）で参照し、他のノードが定期的に確認テーブルを更新しているかどうかを相互に監視する。

また、他ノードから状態確認通知を受信した場合も監視を行う。

確認テーブルの更新間隔が予め設定した設定値（障害判定時間、例えば１０分）よりも大きくなった場合は、該当するノードで障害が発生していると判断する。各ノードは、自身以外の各ノードに関して稼動／停止の判定を行い、クラスタの状態（Ｓ０〜Ｓ１４）を特定する。また、自身が生きていること通知するため、共有ストレージ装置６の確認テーブルで自身のノードに該当する領域を更新する。この更新は、図１５で示すように、タイムスタンプと状態（稼動／停止（ダウン））を書き込むことで行われる。

共有ストレージ装置６の確認テーブルを各ノード１〜４が参照することにより、各ノードはクラスタ１００の状態を特定し、前回特定した状態と最新の状態を比較し、状態の変化を検知した場合、ノード障害発生か障害ノード回復かを判断し（図８のビット列のビット数の増減で判定する）、フェイルオーバ処理またはフェイルバック処理中でなければ、ビット数の増大（オンビットの増大）でフェイルオーバ処理を起動し、ビット数の減少（オンビットの減少）でフェイルバック処理を起動する。

＜フェイルオーバ処理２２３の概要＞
各ノード１〜４で実行される、フェイルオーバ機能２２０を構成するフェイルオーバ処理２２３の概要について、説明する。

｛Ｓｔｅｐ１｝マスタ／スレーブの決定
フェイルオーバ時にマスタとなるノードを決定するため、共有ストレージ装置６上の確認テーブルを参照して、自身のノード番号（例：ＮｏｄｅＸ）が最も小さい場合、自身がマスタとなり、そうでない場合はスレーブとなる。

｛Ｓｔｅｐ２−マスタ｝
自ノードがマスタの場合には、停止しているノードに対して、シャットダウン要求を行い、ノードを停止する。その後、後述の状態確認要求処理２２２を呼び出し、他のノードに引き継ぎ状態を確認する。

そして、管理サーバ１０が更新した共有ストレージ装置６上の状態別引き継ぎ情報から解放すべきリソースと、引き継ぐべきリソースを取得し、解放すべきリソースを解放した後にリソースの引継ぎを行う。

｛Ｓｔｅｐ２−スレーブ｝
自ノードがスレーブの場合には、マスタとなったノードから状態確認要求を受けて、フェイルオーバ処理を再開する。

以上の処理により共有ストレージ装置６上の状態別引き継ぎ情報に基づいてフェイルオーバ処理が行われる。

すなわち、管理サーバ１０は、所定の周期で状態別引き継ぎ情報作成処理１１２を実行し、クラスタ１００の稼働中に共有ストレージ装置６上へ状態別引き継ぎ情報を更新しておく。そして、各ノード１〜４は、いずれかのノードが停止すると、管理サーバ１０が作成した状態別引き継ぎ情報に基づいて、リソースとアドレスの引き継ぎを行うのである。

したがって、フェイルオーバ時に各ノード１〜４は、引き継ぎに関して割り当ての調停等の演算を行う必要がなく、極めて高速にフェイルオーバ処理を完了することができる。また、状態別引き継ぎ情報は、フェイルオーバを行う必要のある全ての状態について、管理サーバ１０が予め作成し、検証したものであるため、引き継ぐリソースがノード間で大きく偏るのを防止し、各ノード１〜４の負荷が均一になるよう調整できる。

＜フェイルバック処理２２４の概要＞
各ノード１〜４で実行される、フェイルオーバ機能２２０を構成するフェイルバック処理２２４の概要について、説明する。

｛Ｓｔｅｐ１｝マスタ／スレーブの決定
フェイルバック時にマスタとなるノードを決定するため、共有ストレージ装置６上の確認テーブルを参照して、自身のノード番号（例：ＮｏｄｅＸ）が最も小さい場合、自身がマスタとなり、そうでない場合は、スレーブとなる。

｛Ｓｔｅｐ２−マスタ｝
自ノードがマスタの場合には、稼働中の他のノードに対して後述の状態確認要求処理２２２を呼び出し、他のノードに引き継ぎ状態を確認する。

そして、管理サーバ１０が更新した共有ストレージ装置６上の状態別引き継ぎ情報から解放すべきリソースと引き継ぐべきリソースを取得し、解放すべきリソースを解放後にリソースの引継ぎを行う。

｛Ｓｔｅｐ２−スレーブ｝
自ノードがスレーブの場合には、マスタとなったノードから状態確認要求を受けて、フェイルバック処理を再開する。

フェイルバック処理の場合も、上記フェイルオーバ処理と同様に、各ノード１〜４は、引き継ぎに関して割り当ての調停等の演算を行う必要がなく、共有ストレージ装置６上へ状態別引き継ぎ情報を参照するだけでよいので、極めて高速にフェイルバック処理を完了することができる。

＜状態確認要求処理２２２の概要＞
各ノード１〜４で実行される、フェイルオーバ機能２２０を構成する状態確認要求処理２２２の概要について、説明する。

この処理は、スレーブのノードに対して、マスタのノードが認識している状態（Ｓ０〜Ｓ１４）を送信する。そして、全てのスレーブから応答を受信し、全ノードで状態が一致していることを確認する処理である。

以上、管理サーバ１０の引き継ぎ情報作成機能１１０と、各ノード１〜４のフェイルオーバ機能２２０の各処理の概要について説明した。

次に、各処理の詳細な動作について、フローチャートを参照しながら以下に説明する。

＜状態別引き継ぎ情報作成処理１１２の詳細＞
管理サーバ１０の引き継ぎ情報作成機能１１０で行われる状態別引き継ぎ情報作成処理１１２の詳細な処理内容について、図１６のフローチャートを参照しながら以下に説明する。このフローチャートは、所定の周期（例えば、数秒）で実行されるものである。

Ｓ２０１〜Ｓ２１０では、上記ＳＴＥＰ１で述べたように、管理サーバ１０が各ノード１〜４のファイルシステム毎の利用者数を取得する処理である。

まず、Ｓ２０１では、ノードを特定する変数ｋを１に初期化する。そして、Ｓ２０２で管理サーバ１０は、変数ｋで指示されるノード（ｋ）に接続する。

次に、Ｓ２０３では各ノードのファイルシステムを特定する変数ｌを１に初期化する。そして、Ｓ２０４で管理サーバ１０は、変数ｉで指示されるファイルシステム（ｉ）を指定し、Ｓ２０５でファイルシステム（ｌ）の名称と利用者数をノード（ｋ）から取得する。ノード（ｋ）は、アクセスログからファイルシステム毎にアクセスユーザ数をカウントし、ファイルシステム名と現在の利用者数を管理サーバ１０に通知する。なお、変数ｌはノード（ｋ）内のファイルシステムの先頭などから順次スキャンするための変数である。

Ｓ２０６では、管理サーバ１０がノード（ｋ）から取得したファイルシステム名と現在の利用者数をメモリ１２等に出力する。

そして、Ｓ２０７ではノード（ｋ）の最後のファイルシステムに達したか否かを判定する。最後でない場合にはＳ２１０へ進んで変数ｌをインクリメントした後Ｓ２０４へ進んで、次のファイルシステムについて利用者数を取得する。

一方、最後のファイルシステムに達した場合は、Ｓ２０８へ進んでクラスタ１００の最後のノードに達したか否かを判定する。最後のノードでない場合には、Ｓ２０９に進んで、変数ｋをインクリメントした後Ｓ２０２へ戻って、次のノード（ｋ）についてファイルシステムを調査する。

最後のノードに達した場合には、Ｓ２１１へ進む。

この時点で、全ノード１〜４の全ファイルシステムについて、ファイルシステム名と現在の利用者数を取得したので、管理サーバ１０のメモリ１２上には、図５で示したようなファイルシステム利用者数リストが作成され、現在クラスタ１００が提供しているリソースの一覧が作成される。

上記Ｓ２０１〜Ｓ２１０の処理で、ファイルシステム利用者数リストを作成した後には、Ｓ２１１以降でクラスタ１００の状態Ｓ０〜Ｓ１４に応じたフェイルオーバ時の引き継ぎ情報の作成を行う。

Ｓ２１１では、設定情報１１１に基づく各ノード１〜４の引き継ぎ回数リスト（図６参照）を読み込み、また、設定情報１１１から各ノード１〜４毎の最大利用者数（図７参照）を読み込む。なお、引き継ぎ回数リストは、初回の処理で設定情報１１１から読み込んだ値を共有ストレージ装置６に書き込み、その後、フェイルオーバやフェイルバックに応じて更新するものである。

次に、Ｓ２１２でクラスタ１００の状態Ｓ０〜Ｓ１４を設定する変数ｘを０に初期化する。

Ｓ２１３では、上記ＳＴＥＰ４及び図８で示したように、状態Ｓ（ｘ）の場合に引き継ぎ先となるノードを取得し、Ｓ２１４では上記引き継ぎ回数リストとファイルシステム利用者数リストから、引き継ぎ先のノード毎のファイルシステム名と利用者数を取得する。

Ｓ２１５では、上記Ｓ２１１で読み込んだ設定情報１１１から引き継ぎ先ノード毎の最大利用者数を取得する。

そして、Ｓ２１６では、状態Ｓ（ｘ）の引き継ぎ情報を、上記ＳＴＥＰ４、５で示したように作成する。なお、この処理については、後に詳述する。

Ｓ２１７では、上記Ｓ２１６の引き継ぎ情報作成処理でエラーが発生したか否かを判定し、エラーがあればＳ２２３へ進んで、管理サーバ１０へエラーが生じたことを通知する。

エラーがなければ、Ｓ２１８に進んで、予め設定した最後の状態Ｓ（ｘ）となったか否かを判定する。本実施形態では、ｘ＝１４が最後の状態となる。最後の状態でない場合には、Ｓ２２２へ進んで変数ｘをインクリメント（１を加算）した後、Ｓ２１３に戻って次の状態Ｓ（ｘ）について引き継ぎ情報を作成する。

全ての状態Ｓ（ｘ）について引き継ぎ情報が作成されたＳ２１８では、上記図１１で示したように、状態Ｓ（ｘ）を状態名とし、引き継ぎ先ノード毎に引き継ぐファイルシステム名を記載したリソース引き継ぎリストを共有ストレージ装置６に出力（更新）する。

次に、Ｓ２２０では上記ＳＴＥＰ７で示したように、各状態Ｓ（ｘ）毎にＩＰアドレスの引き継ぎ情報を作成し、Ｓ２２１では上記図１４で示したように、状態Ｓ（ｘ）を状態名とし、引き継ぎ先ノード毎に引き継ぐＩＰアドレスを記載したアドレス引き継ぎリストを共有ストレージ装置６に出力（更新）する。

以上の処理により、管理サーバ１０は、所定の周期で各ノード１〜４の負荷（利用者数）を検出し、フェイルオーバが生じた場合の引き継ぎ情報を、負荷に応じて配分するリソース及びアドレスのリストとして共有ストレージ装置６に出力し、更新する。

｛状態Ｓ（ｘ）別リソース引き継ぎ情報作成処理｝
次に、上記Ｓ２１６で行われる状態Ｓ（ｘ）毎のリソース引き継ぎ情報の作成処理について、図１７のサブルーチンを参照しながら詳述する。

Ｓ３１では、上記Ｓ２１４で取得した引き継ぎ先のノードのファイルシステム名と利用者数から、現在のノードの利用者数をcurrent_userとして求める。また、上記Ｓ２１１で取得した最大利用者数をmax_userに設定する。

そして、各ノード毎に空きユーザ数を、max_user−current_userとして演算する。

図７で示したクラスタ１００のノードのテーブルをメモリ１２などに読み込んで、テーブルnodeとし、求めた空きユーザ数の大きい順で、ノード番号をソートする。

次に、Ｓ３２では、上記図５のファイルシステム利用者数リストをメモリ１２などに読み込んで、テーブルfilesystemとして、上記Ｓ２１３で取得したノード毎のファイルシステムと利用者数から、利用者数（user_num）の大きい順位ファイルシステム名をソートする。

Ｓ３３以降は、ループ処理により現在の状態Ｓ（ｘ）のリソース引き継ぎ情報を作成する。

まず、Ｓ３３ではループカウンタｉを０にセットして、所定値ｍまでループを行う。なお、所定値ｍは各ノード毎のファイルシステム数などに設定される。

Ｓ３４では、現在の状態Ｓ（ｘ）で引き継ぎ先となるノード数をｎとして、変数ｊを、
ｊ＝（ｉｍｏｄｎ）＋１
として演算する。なお、ｍｏｄはｉ／ｎの余りを求める演算子である。

この演算の結果、ループカウンタｉの増加に応じて、変数ｊは０〜ｎの間で循環する。

Ｓ３５では、変数ｊでノードを指定し（node[ｊ]）、ノードの利用者数current_userに、ループカウンタｉで指し示すファイルシステム名（filesystem[ｉ]）のユーザ数（user_num）を加算する。

Ｓ３６では、指定したノード（node[ｊ]）にファイルシステム名（filesystem[ｉ]）を追加したリストnode[ｊ].listに追加する。このリストnode[ｊ].listは、図１１のリソース引き継ぎリストのノード番号とファイルシステム名の部分に相当するもので、管理サーバ１０のメモリ１２などに設定される。

Ｓ３７では、変数ｊが引き継ぎ先のノード数に相当する値ｎに達したか否かを判定し、達していなければＳ３９に進み、達していればＳ３８へ進んで、テーブルnode[ｊ]を再び空きユーザ数の大きい順でソートする。

Ｓ３９では、ループカウンタｉが所定の最大値ｍに達したか否かを判定し、ｉ＜ｍの場合には、Ｓ３３へ戻ってｉ＝ｉ＋１として次のノードについてファイルシステム名の設定を行う。ｉ＝ｍの場合には、Ｓ４０に進んで、各ノードの利用者数が図７で設定された最大利用者数を超えていないかを判定する。超えていなければ、Ｓ４１で現在の状態Ｓ（ｘ）における引き継ぎ先のノード毎に、ファイルシステム名割り当てたリストnode[ｊ].listをメモリ１２などに出力する。

一方、各ノードの利用者数が最大利用者数を超えている場合には、Ｓ４２で上記図１６のＳ２２３でエラー通知を行うためのエラー処理を行う。

以上のサブルーチンにより、ノードを収容可能な空きユーザ数（最大利用ユーザ数−既に利用しているユーザ数）が大きい順でソートする。そして、引き継ぐリソース（ファイルシステム）を利用ユーザ数の大きい順でソートする。

ソートした順序で、各ノードにファイルシステムを１個ずつ割当て、各ノードの利用ユーザ数を更新する。

そして、未割当てのファイルシステムがなくなるまでファイルシステムの割り当てを行って、各ノードの利用者数と最大利用者数を比較し、全てが最大利用ユーザ数に納まっているか、または許容範囲（例えば、最大利用ユーザ数×２０％など）に収まっていれば、この割当てを状態別引継ぎ情報へ出力する。そうでなければ、処理を中断して、入力情報（引継ぎ回数設定情報や最大利用者数）などを見直して、再実行する。

｛状態Ｓ（ｘ）別リソース引き継ぎ情報作成処理｝
次に、上記Ｓ２２０で行われる状態Ｓ（ｘ）毎のアドレス引き継ぎ情報の作成処理について、図１８のサブルーチンを参照しながら詳述する。

Ｓ５１では、状態Ｓ１〜Ｓ１４（ｘ＝１〜１４）のそれぞれについて、稼動しているノードを集計し、図１２のNode_list_alive（図中alive_list）を作成する。

Ｓ５２では、状態Ｓ１〜Ｓ１４（ｘ＝１〜１４）のそれぞれについて、停止しているノードを集計し、図１３のNode_list_down（図中down_list）を作成する。

Ｓ５３では、上記作成したNode_list_aliveとNode_list_downをメモリ１２などに出力する。

Ｓ５４では、Node_list_downのノードの総数をｙにセットし、Ｓ５５で変数Ｚを１に初期化する。

Ｓ５６では、変数ｚが指し示すNode_list_downから順次ノード番号を読み込み、Ｓ５７でノード番号に対応するＩＰアドレスを設定情報１１１から取得する。

次に、Ｓ５８では、変数ｚが指し示すNode_list_aliveから順次ノード番号を読み込み、Ｓ５９では上記Ｓ５７で取得したＩＰアドレスを変数ｚが指し示すNode_list_aliveのノード番号に割り当てる。

Ｓ６０では、Node_list_downの最後に到達したかを判定し、到達していなければＳ６１で変数ｚをインクリメントしてＳ５６に戻り、Node_list_downに記載されたノードのＩＰアドレスを、Node_list_aliveに記載されたノードの先頭から順次割り当てる。

以上のサブルーチンにより、図１４に示すアドレスの引き継ぎリストが作成される。

＜クラスタ状態監視処理２２１の詳細＞
各ノード１〜４のフェイルオーバ機能２２０で行われるクラスタ状態監視処理２２１の詳細な処理内容について、図１９のフローチャートを参照しながら以下に説明する。このフローチャートは、時分割処理などにより繰り返して実行されるものである。

Ｓ７０では、現在の状態を示す変数Ｓ及び前回の状態を示す変数Ｓ＿oldを０にリセットすると共に、カウンタｉを１に設定する。

Ｓ７１では、現在時刻をＯＳ２１０などから取得し、共有ストレージ装置６の確認テーブルから自ノードのタイムスタンプを取得する。また、管理サーバ１０の設定情報１１１から監視間隔及び障害判定時間を取得する。

Ｓ７２では、自ノードのタイムスタンプに所定の監視間隔（例えば、３０秒〜１分）を加算した値よりも、現在時刻の方が大きいか否かを判定する。現在時刻＞タイムスタンプ＋監視間隔の場合はＳ７５に進み、現在時刻≦タイムスタンプ＋監視間隔の場合はＳ７３に進む。

Ｓ７３では、他のノードから状態確認通知を受信したか否かを判定し、受信した場合にはＳ７４で自ノードをスレーブに設定する。受信しない場合にはＳ７１に戻って、監視間隔が経過するか、他ノードから状態確認要求を受信するまで待機するループを繰り返す。

Ｓ７５では、カウンタｉに応じたノード（ｉ）のタイムスタンプを共有ストレージ装置６の確認テーブルから取得する。

Ｓ７６では、現在時刻から取得したタイムスタンプを差し引いた値が、障害判定時間を超えているか否かを判定する。現在時刻−タイムスタンプ＞障害判定時間の場合には、このノード（ｉ）に障害が発生している疑いがあるのでＳ７７に進んで、変数Ｓを更新する。現在時刻−タイムスタンプ≦障害判定時間の場合は、正常に稼動していると判定できるため、Ｓ７８に進む。

Ｓ７７では、上記図８のビット列に対応するクラスタ状態を示す変数Ｓを、
Ｓ＝Ｓ＋（２＾（ノード数−ノード番号））
として更新する。この演算により、障害の生じたノードに対応するビットがオン（＝１）に変更される。

Ｓ７８では、カウンタｉをインクリメントして、Ｓ７９でカウンタｉがクラスタ１００のノードの総数を超えたか否かを判定し、超えていなければＳ７５に戻って次のノードを監視し、超えていれば全ノードを監視したので、Ｓ６０に進む。

Ｓ６０では、クラスタ１００の状態を示すＳが前回値Ｓ＿oldから変化しているかを判定する。

Ｓ＝Ｓ＿oldの場合には、各ノードに変化がないのでＳ８８で変数Ｓを０に戻してからＳ８９で共有ストレージ装置６上の確認テーブルにおいて、自ノードのタイムスタンプを現在時刻で更新する。

一方、Ｓ≠Ｓ＿oldの場合には、Ｓ８１に進んでクラスタ１００の状態の変化を検出する。すなわち、現在の状態を示す変数Ｓで、オンとなっているビットの数（停止しているノード数）から前回の状態を示す変数Ｓ＝Ｓ＿oldで、オンとなっているビットの数を差し引いた変化量ΔＳを求める。

Ｓ８２では、変化量ΔＳが０より大きければ、停止したノードが増加したのでフェイルオーバ処理を行う必要があるのでＳ８３に進み、変化量ΔＳが０より小さければ、停止したノードが減少（復旧）したのでフェイルバック処理を行う必要があるのでＳ８５に進む。

Ｓ８３では、現在フェイルオーバ処理中またはフェイルバック処理中であるか否かを判定し、いずれかの処理を行っている場合には、フェイルオーバ処理を行わずにＳ８７へ進み、どちらの処理も行っていない場合には、Ｓ８４でフェイルオーバ処理を起動する。なお、フェイルオーバ処理またはフェイルバック処理中の判定は、自ノードがスレーブの場合、他のノードに問い合わせて処理中であるか否かを取得する。

Ｓ８４では、後述するようにフェイルオーバ処理を実施し、Ｓ８７に進む。

Ｓ８５では、現在フェイルオーバ処理中またはフェイルバック処理中であるか否かを判定し、いずれかの処理を行っている場合には、フェイルバック処理を行わずにＳ８７へ進み、どちらの処理も行っていない場合には、Ｓ８６でフェイルバック処理を起動する。Ｓ８６では、後述するようにフェイルバック処理を実施し、Ｓ８７に進む。

Ｓ８７では、前回値Ｓ＿oldを現在の状態Ｓで更新し、Ｓ８８に進む。

このように、各ノード１〜４では、共有ストレージ装置６上の確認テーブルから読み込んだタイムスタンプに基づいて他ノードの稼動／停止を監視し、変数Ｓのビット列の変化があったときには、フェイルオーバ処理またはフェイルバック処理を実施する。ただし、既にフェイルオーバ処理またはフェイルバック処理が実施されている場合には、前回値Ｓ＿oldの更新のみを行う。

＜フェイルオーバ処理２２３の詳細＞
各ノード１〜４のフェイルオーバ機能２２０で行われるフェイルオーバ処理２２３の詳細な処理内容について、図２０のフローチャートを参照しながら以下に説明する。このフローチャートは、上記図１９のＳ８４で起動されるもので、クラスタ状態監視処理２２１とは別のプロセスで起動されるものである。なお、この図２０の処理を上記Ｓ８４のサブルーチンとすることも可能である。

Ｓ９１では、自ノードがマスターとスレーブのいずれであるかを判定する。マスターであればＳ９２へ進み、スレーブであればＳ９４に進む。

Ｓ９２では、停止していると判定されたノードにシャットダウンを要求する。その後、Ｓ９３では、他のノード（自ノードを除く引き継ぎ先のノード）に状態確認要求を行う。

その後、Ｓ９４では、共有ストレージ装置６上の状態別引き継ぎ情報からリソース引き継ぎリスト及びアドレス引き継ぎリストを読み込む。読み込んだリストと現在の状態（上記図１９の変数Ｓ）から解放するリソースと引き継ぐリソースを決定する。

そして、Ｓ９５では、上記Ｓ９４で決定したリソースを解放し、次いで、Ｓ９６でリソースを引き継ぐ（ファイルシステムのマウントなど）とともに、ＩＰアドレスを引き継いで処理を終了する。

このように、フェイルオーバ処理では、現在の状態Ｓが分かれば、この状態Ｓに応じたリソース引き継ぎリストとアドレス引き継ぎリストを読み込むだけで、リソースとＩＰアドレスの引き継ぎを決定でき、極めて高速にフェイルオーバ処理を行うことができる。

また、フェイルオーバ処理は、引き継ぐノードで並列的に行われるので、さらに高速な処理を実現することができる。

＜フェイルバック処理２２４の詳細＞
各ノード１〜４のフェイルオーバ機能２２０で行われるフェイルバック処理２２４の詳細な処理内容について、図２１のフローチャートを参照しながら以下に説明する。このフローチャートは、上記図１９のＳ８５で起動されるもので、クラスタ状態監視処理２２１とは別のプロセスで起動されるものである。なお、この図２１の処理を上記Ｓ８５のサブルーチンとすることも可能である。

Ｓ１０１では、自ノードがマスターとスレーブのいずれであるかを判定する。マスターであればＳ１０２へ進み、スレーブであればＳ１０３に進む。

Ｓ１０２では、他のノード（自ノードを除く引き継ぎ先のノード）に状態確認要求を行う。

その後、Ｓ１０３では、共有ストレージ装置６上の状態別引き継ぎ情報からリソース引き継ぎリスト及びアドレス引き継ぎリストを読み込む。読み込んだリストと現在の状態Ｓから引き継ぐリソースと解放するリソースを決定する。

そして、Ｓ１０４では、上記Ｓ１０３で決定したリソースを解放し、次いで、Ｓ１０４でリソースを引き継ぐ（ファイルシステムのマウントなど）とともに、ＩＰアドレスの引き継ぎを行って処理を終了する。

このように、フェイルバック処理の場合も、フェイルオーバ処理と同様に、現在の状態Ｓが分かれば、この状態Ｓに応じたリソース引き継ぎリストとアドレス引き継ぎリストを読み込むだけで、リソース（処理）とＩＰアドレスの引き継ぎを決定でき、極めて高速にフェイルバック処理を行うことができる。

また、フェイルバック処理は、引き継ぐノードで並列的に行われるので、さらに高速な処理を実現することができる。

＜状態確認要求処理２２２の詳細＞
各ノード１〜４のフェイルオーバ機能２２０で行われる状態確認要求処理２２２の詳細な処理内容について、図２２のフローチャートを参照しながら以下に説明する。このフローチャートは、上記図２０のＳ９３または図２１のＳ１０２で起動されるもので、クラスタ状態監視処理２２１とは別のプロセスで起動されるものである。なお、この図２２の処理を上記Ｓ９３またはＳ１０２のサブルーチンとすることも可能である。

Ｓ１１１では、送付先のノード１〜４のＩＰアドレスを、管理サーバ１０の設定情報１１１から取得する。Ｓ１１２では、送信するメッセージを作成し、Ｓ１１３では、このメッセージを送信する。

以上のように、管理サーバ１０とクラスタ１００の各ノード１〜４では、共有ストレージ装置６上で確認テーブル、状態別引き継ぎ情報を共有することで、フェイルオーバやフェイルバック処理を迅速に行うことができる。そして、状態別引き継ぎ情報は、フェイルオーバやフェイルバック処理が発生する以前に、管理サーバ１０によって定期的に更新されているので、フェイルオーバ時の演算処理を大幅に低減して処理の高速化を図ることができる。

また、状態別引き継ぎ情報は、管理サーバ１０が各ノード１〜４の負荷に応じて引き継ぐリソースを決定し、検証を行っているため、フェイルオーバ処理後に、ノード１〜４間で負荷が偏るのを防ぐことが可能となって、クラスタ１００のリソースを効率よく利用することが可能となる。

＜変形例１＞
上記実施形態において、各ノード１〜４のいずれかがマスターとなってフェイルオーバ処理を行う例を示したが、図２３で示すように、管理サーバ１０にフェイルオーバ機能２２０を搭載し、管理サーバ１０が常にマスターとして動作し、各ノード１〜４が常にスレーブとして動作させる構成も可能である。この場合、例えば、管理サーバ１０にノード番号として、０を与えれば、管理サーバ１０によるクラスタノード監視体制をとることができる。

＜変形例２＞
上記実施形態において、各ノード１〜４は、引き継ぐノード番号が小さいノードがマスターとなる例を示したが、図２４で示すように、マスターとなった回数を示すテーブルを共有ストレージ装置６上に設け、マスターとなった回数が小さいものから順にマスターとなるようにしてもよい。この場合、ノード番号が小さいノードが繰り返しマスターになるのを防ぎ、各ノード１〜４の負荷をさらに均一にすることができる。

＜変形例３＞
上記実施形態において、各ノード１〜４が全て稼動している状態を０段目（図８参照）としたが、１段目（１つのノードが停止した状態）等を初期状態としても良い。この場合、停止中のノードをスタンバイとして、クラスタ１００の全体の負荷が上昇したときにスタンバイのノードをクラスタ１００へ加える（フェイルバック）ことで、ノードの自動拡張を行うことができる。

なお、スタンバイのノードで引き継ぎ情報作成機能１１０を実行するようにしても良い。

システムの全体的なハードウェア構成を示すブロック図。システムの全体的なソフトウェア構成を示すブロック図。管理サーバで実行されるソフトウェア構成を示すブロック図。各ノードで実行されるソフトウェア構成を示すブロック図。管理サーバによって作成される各ノード毎のファイルシステム利用者数リストの説明図。管理サーバによって作成される各ノード毎の引き継ぎ回数リストの説明図。管理サーバによって作成される各ノードの最大利用者数リストの説明図。状態名とビット列の値に応じてクラスタの状態を示すクラスタ状態リストの説明図。フェイルオーバ時の各ノード毎の引き継ぎ回数リストの説明図。フェイルオーバ時の各ノードのリソースの引き継ぎの様子を示す説明図。管理サーバによって作成される状態別のリソース引き継ぎリストの説明図。管理サーバによって作成される稼働中のノードを示すnode_list_aliveの説明図。管理サーバによって作成される停止中のノードを示すnode_list_downの説明図。管理サーバによって作成される状態別のアドレス引き継ぎリストの説明図。共有ストレージ装置上で各ノードが共有する確認テーブルの説明図。管理サーバで実行される状態別引き継ぎ情報作成処理の一例を示すフローチャート。図１６のＳ２１６で行われる状態別リソース引き継ぎ情報作成のサブルーチン。図１６のＳ２２０で行われる状態別アドレス引き継ぎ情報作成のサブルーチン。各ノードで実行されるクラスタ状態監視処理の一例を示すフローチャート。図１９のＳ８４で起動されるフェイルオーバ処理の一例を示すフローチャート。図１９のＳ８６で起動されるフェイル縛処理の一例を示すフローチャート。図２０のＳ９３、図２１のＳ１０２で起動される状態確認要求処理の一例を示すフローチャート。変形例１を示し、管理サーバで実行されるソフトウェア構成を示すブロック図。変形例２を示し、共有ストレージ装置上に配置されるマスター回数のテーブルの説明図。

符号の説明

１〜４ノード
６共有ストレージ装置
１０管理サーバ
２０〜５０サーバ
１１２状態別引き継ぎ情報作成処理
２２１クラスタ状態監視処理
２２３フェイルオーバ処理
２２４フェイルバック処理

Claims

複数のノードからなるクラスタを有し、前記複数のノードのいずれかに障害が発生したときに、障害の発生したノードの処理を他のノードへ引き継ぐフェイルオーバ方法であって、
前記複数のノードが相互に稼動状態を監視する手順と、
前記監視結果に基づいて障害の発生を検知する手順と、
前記障害が発生したことを検知したときには、前記障害が発生したノードを除くクラスタ内の各ノードが、予め共有する記憶装置に格納された障害の発生したノードの処理を他のノードへ引き継ぐ引き継ぎ情報を読み込む手順と、
前記各ノードが、前記引き継ぎ情報に基づいて障害が発生したノードの処理を引き継ぐ手順と、
前記クラスタ内の各ノードの負荷を取得する手順と、
前記取得した負荷に基づいて、前記複数のノードのいずれかに障害が発生したときの前記引き継ぎ情報を作成する手順と、
を含み、
前記引き継ぎ情報を作成する手順は、
各ノードの処理毎に引き継ぐ回数の上限を設定する手順と、
現在の引き継ぎ回数と前記引き継ぐ回数の上限に基づいて、他のノードに引き継ぐ処理を選択する手順と、を含むことを特徴とするフェイルオーバ方法。
複数のノードからなるクラスタと、
前記クラスタを管理する管理ノードと、を備えて、
前記複数のノードのいずれかに障害が発生したときに、障害の発生したノードの処理を他のノードへ引き継ぐ計算機システムにおいて、
前記クラスタ内の各ノード及び前記管理ノードに共有されて、前記複数のノードのいずれかに障害が発生したときの引き継ぎ情報を格納する共有記憶装置を備え、
前記クラスタ内の各ノードは、
他のノードの稼動状態を監視する監視部と、
前記監視結果に基づいて他のノードの障害の発生を検知する障害検知部と、
前記障害を検知したときには、前記共有記憶装置から引き継ぎ情報を取得する引き継ぎ情報取得部と、
前記引き継ぎ情報に基づいて障害が発生したノードの処理を引き継ぐフェイルオーバ部と、
前記クラスタ内の各ノードの負荷を取得する負荷取得部と、
前記取得した負荷に基づいて、前記複数のノードのいずれかに障害が発生したときの引き継ぎ情報を作成し、前記共有記憶装置に書き込む引き継ぎ情報作成部と、
を有し、
前記引き継ぎ情報作成部は、
前記各ノードの処理毎に引き継ぐ回数の上限を設定する引き継ぎ回数上限設定部と、
現在の引き継ぎ回数と前記引き継ぐ回数の上限に基づいて、他のノードに引き継ぐ処理を選択することを特徴とする計算機システム。
複数のノードからなるクラスタと、
前記クラスタを管理する管理ノードと、を備えて、
前記複数のノードのいずれかに障害が発生したときに、障害の発生したノードの処理を他のノードへ引き継ぐ計算機システムにおいて、
前記クラスタ内の各ノード及び前記管理ノードに共有されて、前記複数のノードのいずれかに障害が発生したときの引き継ぎ情報を格納する共有記憶装置を備え、
前記クラスタ内の各ノードは、
他のノードの稼動状態を監視する監視部と、
前記監視結果に基づいて他のノードの障害の発生または障害の復旧を検知する検知部と、
前記障害または復旧を検知したときには、前記共有記憶装置から引き継ぎ情報を取得する引き継ぎ情報取得部と、
前記障害が発生したときには、引き継ぎ情報に基づいて障害が発生したノードの処理を引き継ぐフェイルオーバ部と、
前記復旧が発生したときには、引き継ぎ情報に基づいて復旧したノードに処理を引き継ぐフェイルバック部と、
前記クラスタ内の各ノードの負荷を取得する負荷取得部と、
前記取得した負荷に基づいて、前記複数のノードのいずれかに障害が発生したときの引き継ぎ情報を作成し、前記共有記憶装置に書き込む引き継ぎ情報作成部と、
を有し、
前記引き継ぎ情報作成部は、
前記各ノードの処理毎に引き継ぐ回数の上限を設定する引き継ぎ回数上限設定部と、
現在の引き継ぎ回数と前記引き継ぐ回数の上限に基づいて、他のノードに引き継ぐ処理を選択することを特報とする計算機システム。