JP4695705B2 - クラスタシステムおよびノード切り替え方法 - Google Patents

Description

本発明は、複数の情報処理装置（ノード）を用いて構成されたクラスタシステムと、クラスタシステムにおいて異常が検知されたときのノード切り替え方法に関する。

複数の業務サーバにより構成される従来のクラスタシステムにおいては、一般に、ハートビート信号によるノード異常検知方法が採用されている。この方法では、各業務サーバから他の業務サーバに対して、専用のインタコネクトＬＡＮ（Local Area Network）経由でハートビートパケットを送出し、特定の業務サーバから一定時間応答パケットを受信しない場合に、その業務サーバの異常を検知する。

しかしながら、ハートビート信号によるノード異常検知方法には、次のような問題がある。
（１）誤検知
クラスタシステムにおいて、業務処理そのものは正常に実行されていても、オペレーティングシステム（ＯＳ）の部分的異常等により、ハートビート信号が正常に送受信されない場合がある。この場合、業務とは直接関係がないシステム状態の異常が検知され、実際には業務処理を継続可能な状況でも、ノード切り替えが発生してしまう。
（２）検知時間
ハートビート信号によるノード異常検知には、相当の検知時間が必要である。そこで、検知時間を短くするためにタイマを短く設定すると、上記（１）の誤検知を助長することになる。したがって、不要なノード切り替えが発生するリスクが高まる。

下記の特許文献１は、ノード内の障害発生を監視するサービスプロセッサを用いることで、処理の継続が可能か否かを判断するクラスタシステムに関し、特許文献２は、各ノードに搭載されたエージェントが管理サーバと通信することで、管理サーバがノード情報を一括管理するクラスタシステムに関する。
特開平０９−０３４８５２号公報 特開２００４−３３４５３４号公報

本発明の課題は、クラスタシステムにおいて業務処理を継続可能な場合に、不要なノード切り替えの発生を防止することである。
本発明の第１のクラスタシステムは、クライアントノード装置および複数のサーバノード装置を含む。上記複数のサーバノード装置のうち第１のサーバノード装置に異常が発生したとき、クライアントノード装置は、第２のサーバノード装置に対して異常検知情報を送信する。

第２のサーバノード装置は、異常検知情報を受信したとき、第１のサーバノード装置に対して生存確認要求を送信し、第１のサーバノード装置から生存確認応答を受信しなければ、第１のサーバノード装置に異常が発生したものと判断して、業務処理を行うサーバノード装置の切り替え制御を開始する。

このようなクラスタシステムによれば、クライアントノード装置が検知した第１のサーバノード装置の異常を、別のノード装置である第２のサーバノード装置が確認した後に、切り替え制御が開始される。したがって、サーバノード装置の異常を確実に検証することができ、不要なノード切り替えを抑止することができる。

本発明の第２のクラスタシステムは、複数のクライアントノード装置および複数のサーバノード装置を含む。上記複数のクライアントノード装置の各々は、上記複数のサーバノード装置のうち第１のサーバノード装置に対して業務処理要求を送信し、第１のサーバノード装置から業務処理応答を受信しなければ、第２のサーバノード装置に対して異常検知情報を送信する。

第２のサーバノード装置は、２つ以上のクライアントノード装置から異常検知情報を受信したときに、第１のサーバノード装置に異常が発生したものと判断して、業務処理を行うサーバノード装置の切り替え制御を開始する。

このようなクラスタシステムによれば、業務処理要求に対する応答の有無に基づいて第１のサーバノード装置の異常が検知されるため、直接的に、業務の継続ができない状態を検知することができる。また、複数のクライアントノード装置により第１のサーバノード装置の異常が検知された後に、切り替え制御が開始されるため、サーバノード装置の異常を確実に検証することができ、不要なノード切り替えを抑止することができる。

クライアントノード装置は、例えば、後述するクライアントノードＣＮ１またはＣＮ２に対応し、第１のサーバノード装置は、例えば、ノードＮ１に対応し、第２のサーバノード装置は、例えば、ノードＮ２〜Ｎｍに対応する。

クラスタシステムと構成情報を示す図である。 クラスタシステムにおける処理のフローチャートである。 業務起動時の処理を示す図である。 業務運用時のフェイルオーバ制御を示す図である。 スケールアウトによる構成情報の変更を示す図である。 スケールアウトによるクラスタシステムの変更を示す図である。 クライアントノードを含むクラスタシステムの構成図である。 ノードＮ１で異常が発生した場合のシーケンスを示す図である。 クライアントノードＣＮ１で異常が発生した場合のシーケンスを示す図である。 第１のタイマ管理テーブルを示す図である。 第２のタイマ管理テーブルを示す図である。 異常ノードリストを示す図である。 業務パケットを示す図である。 業務応答パケットを示す図である。 生存確認パケットを示す図である。 生存確認応答パケットを示す図である。 ノード異常検知パケットを示す図である。 ノード異常検知処理のフローチャートである。 ノード異常判定処理のフローチャートである。 クラスタシステムにおける複数の業務グループを示す図である。 ノード異常確定リストを示す図である。 切り替え処理のフローチャートである。 業務グループ単位の切り替えを示す図である。 業務グループ単位の切り替え処理のフローチャートである。 ノード単位の切り替えを示す図である。 ノード単位の切り替え処理のフローチャートである。 情報処理装置の構成図である。 プログラムおよびデータの提供方法を示す図である。

以下、図面を参照しながら、本発明を実施するための最良の形態を詳細に説明する。
図１は、本実施形態のクラスタシステムの構成例を示している。このクラスタシステムは、構成管理サーバ１０１およびノード（サーバ）Ｎ１〜Ｎ６を備える。このうち、クラスタシステムとして切り替え制御の対象となる複数のノードは、ノードグループとして管理され、ノードグループを複数用意することで、システムの能力増強が実現される。この例では、ノードＮ１〜Ｎ３はノードグループＸに属し、ノードＮ４〜Ｎ６はノードグループＹに属する。

１つの業務処理を構成する業務プロセス等の複数の要素は、業務グループとして管理され、１つのノード上で複数の業務グループを実行することができる。また、１つの業務グループは、複数のノードで実行することができ、そのうち１つのノードがプライマリサーバとして動作し、他のノードはセカンダリサーバとして動作する。

切り替え制御の際に参照される構成情報１０２は、設定時には構成管理サーバ１０１に保持されるが、業務処理の起動指示とともに、各ノードグループに配布される。構成情報１０２には、各ノードグループを構成する複数のノードの情報と、各業務グループの各実行単位の状態（Ａｃｔｉｖｅ／Ｓｔａｎｄｂｙ１／Ｓｔａｎｄｂｙ２）が設定されている。

Ａｃｔｉｖｅは、業務クライアントからの要求を受けて、実際に業務処理を行う状態を示し、Ｓｔａｎｄｂｙ１およびＳｔａｎｄｂｙ２は、Ａｃｔｉｖｅ状態の実行単位が異常となった場合に、それぞれ第１優先度および第２優先度で業務処理を受け持つ待機状態を示している。したがって、ノードグループは、互いに切り替えられるＡｃｔｉｖｅ状態、Ｓｔａｎｄｂｙ１状態、およびＳｔａｎｄｂｙ２状態の実行単位が存在する、複数のノードを表している。

ノードグループＸには、業務Ａ〜Ｃの処理を担当する３つの業務グループが割り当てられており、このうち、業務Ａの業務グループでは、ノードＮ１、Ｎ２、およびＮ３の状態がそれぞれＡｃｔｉｖｅ、Ｓｔａｎｄｂｙ１、およびＳｔａｎｄｂｙ２に設定されている。業務Ｂの業務グループでは、ノードＮ１、Ｎ２、およびＮ３の状態がそれぞれＳｔａｎｄｂｙ２、Ａｃｔｉｖｅ、およびＳｔａｎｄｂｙ１に設定され、業務Ｃの業務グループでは、ノードＮ１、Ｎ２、およびＮ３の状態がそれぞれＳｔａｎｄｂｙ１、Ｓｔａｎｄｂｙ２、およびＡｃｔｉｖｅに設定されている。

ノードグループＹには、業務Ｄ〜Ｆの処理を担当する３つの業務グループが割り当てられており、このうち、業務Ｄの業務グループでは、ノードＮ４、Ｎ５、およびＮ６の状態がそれぞれＡｃｔｉｖｅ、Ｓｔａｎｄｂｙ１、およびＳｔａｎｄｂｙ２に設定されている。業務Ｅの業務グループでは、ノードＮ４、Ｎ５、およびＮ６の状態がそれぞれＳｔａｎｄｂｙ２、Ａｃｔｉｖｅ、およびＳｔａｎｄｂｙ１に設定され、業務Ｆの業務グループでは、ノードＮ４、Ｎ５、およびＮ６の状態がそれぞれＳｔａｎｄｂｙ１、Ｓｔａｎｄｂｙ２、およびＡｃｔｉｖｅに設定されている。

ノードグループＸおよびＹに配布された構成情報１０２は、構成情報１１１〜１１６としてノードＮ１〜Ｎ６にそれぞれ保持される。ノードＮ１〜Ｎ３は、業務Ａ〜Ｃの業務グループにおける各実行単位の状態を管理するクラスタ制御１１７を行い、ノードＮ４〜Ｎ６は、業務Ｄ〜Ｆの業務グループにおける各実行単位の状態を管理するクラスタ制御１１８を行う。

図２は、図１のクラスタシステムにおける処理のフローチャートである。まず、業務起動時において、構成管理サーバ１０１は、あらかじめ設定された構成情報１０２を参照して、ノードグループおよび業務グループの構成を認識し（ステップ２０１）、業務処理の起動指示とともに、構成情報１０２を各ノードグループの各ノードに配布する（ステップ２０２）。

ノードＮ１〜Ｎ６は、配布された構成情報１０２を構成情報１１１〜１１６としてそれぞれ格納し、その構成情報１１１〜１１６を参照して、各業務の処理を起動する（ステップ２０３）。そして、業務運用中に異常を検知すると、各ノードグループは、保持している構成情報に従って切り替え制御を実行する（ステップ２０４）。

図３は、業務Ａの起動時の処理を示している。ノードグループＸは、時刻Ｔ１において、構成情報１１１〜１１３に従ってＳｔａｎｄｂｙ処理を行う。これにより、ノードＮ１〜Ｎ３上の業務Ａの実行単位に相当する業務プロセス３０１〜３０３が、それぞれＡｃｔｉｖｅ、Ｓｔａｎｄｂｙ１、およびＳｔａｎｄｂｙ２に設定される。そして、時刻Ｔ２において、ノードＮ１は、Ａｃｔｉｖｅ状態の業務プロセス３０１のＯｎｌｉｎｅ処理を行い、業務Ａの運用を開始する。

その後、ノードＮ１にて異常が発生すると、図４に示すように、ノードグループＸは、フェイルオーバ制御を行って、業務Ａの運用を業務プロセス３０１から業務プロセス３０２に切り替える。

このとき、構成情報１１１〜１１３における、業務プロセス３０１の状態は、ＡｃｔｉｖｅからＤｏｗｎに変更され、業務プロセス３０２の状態は、Ｓｔａｎｄｂｙ１からＡｃｔｉｖｅに変更される。さらに、ノードＮ１上の業務ＢおよびＣの業務プロセスの状態も、Ｄｏｗｎに変更される。Ｄｏｗｎは、ノード故障状態を表す。

このように、業務運用中のノードグループの状態は、そのノードグループ内の構成情報に記録されて管理される。このため、運用中に構成管理サーバ１０１が異常等によりダウンした後も、ノードグループ内で切り替え制御を実行することができ、高信頼性を維持した業務運用が継続される。

ところで、クラスタシステムにおいては、業務Ａの運用中における処理量の増加に伴って、システムを構成するノードの数を増やすスケールアウトが行われる場合がある。この場合、構成管理サーバ１０１の構成情報１０２は、例えば、図５に示すように変更される。その結果、クラスタシステムの構成は、図６に示すように変更される。

変更された構成情報では、業務Ａが業務Ａ１と業務Ａ２に分割され、業務Ａ１およびＢの業務グループが、元のノードグループＸに割り当てられ、業務Ａ２およびＣの業務グループが、新たなノードグループＺに割り当てられている。

業務Ａ１の業務グループでは、ノードＮ１、Ｎ２、およびＮ３の状態がそれぞれＡｃｔｉｖｅ、Ｓｔａｎｄｂｙ１、およびＳｔａｎｄｂｙ２に設定され、業務Ｂの業務グループでは、ノードＮ１、Ｎ２、およびＮ３の状態がそれぞれＳｔａｎｄｂｙ２、Ａｃｔｉｖｅ、およびＳｔａｎｄｂｙ１に設定されている。

また、業務Ａ２の業務グループでは、ノードＮ４、Ｎ５、およびＮ６の状態がそれぞれＡｃｔｉｖｅ、Ｓｔａｎｄｂｙ１、およびＳｔａｎｄｂｙ２に設定され、業務Ｃの業務グループでは、ノードＮ４、Ｎ５、およびＮ６の状態がそれぞれＳｔａｎｄｂｙ２、Ａｃｔｉｖｅ、およびＳｔａｎｄｂｙ１に設定されている。

このように、ノードグループのノード数を増やす代わりに、新たなノードグループを追加すれば、各ノードグループ内におけるクラスタ制御の対象ノード数は、スケールアウト前と同じになる。したがって、クラスタ制御の処理量が増加することはなく、切り替え時間もスケールアウト前と変わらないという利点がある。

次に、図７から図１９までを参照しながら、クラスタシステムにおけるノード異常判定方法について説明する。
図７は、業務処理を依頼するクライアントノードを含む、クラスタシステムの構成例を示している。このクラスタシステムは、クライアントノード（業務クライアント）ＣＮ１、ＣＮ２、およびノード（業務サーバ）Ｎ１〜Ｎｍを備え、これらのノードは、通信ネットワーク７０１により互いに接続されている。不図示の構成管理サーバは、通信ネットワーク７０１上に設けられる。

ノードＮ１〜Ｎｍには、業務グループ７０２が割り当てられており、このうち、ノードＮ１の状態はＡｃｔｉｖｅに設定され、ノードＮ２〜Ｎｍの状態は、それぞれＳｔａｎｄｂｙ１〜Ｓｔａｎｄｂｙ（ｍ−１）に設定されている。

クライアントノードＣＮ１およびＣＮ２上の業務プロセス７１１および７１２は、それぞれ通信ネットワーク７０１を介して、業務処理を要求する業務パケットをノードＮ１〜Ｎｍに送信する。そして、その都度、ノードＮ１〜Ｎｍからの応答を確認することにより、業務グループ単位でノード異常を検知する。

このとき、クライアントノードＣＮ１がノードＮｉ（ｉ＝１〜ｍ）の異常を検知した時点でノード異常と判定すると、クライアントノードＣＮ１内の異常とノードＮｉ内の異常とを区別することができない。そこで、図８および図９に示すように、複数のノードが異常を検知した時点で、ノード異常と判定することにする。

図８は、ノードＮ１で異常が発生した場合のシーケンスを示している。クライアントノードＣＮ１は、業務パケットをノードＮ１〜Ｎｍに送信し（手順８０１）、業務応答パケット（Ａｃｋ）が返信されたか否かをチェックする（手順８０２）。ここで、一定時間内にノードＮ１からの業務応答パケットを受信しなければ、ノードＮ１が異常と判断し、ノード異常検知パケットをノードＮ２〜Ｎｍに送信する（手順８０３）。

ノード異常検知パケットを受信したノードＮ２〜Ｎｍは、業務パケットの一種である生存確認パケットをノードＮ１に送信する（手順８０４）。そして、一定時間内にノードＮ１からの生存確認応答パケットを受信しなければ、ノードＮ１が異常と判断し、切り替え制御を開始する（手順８０５）。

このように、ノードＮ２〜Ｎｍは、自身を含めて２つ以上のノードがノードＮ１の異常を検知した場合に、ノードＮ１が異常であると判定する。具体的には、クライアントノードＣＮ１からノードＮ１の異常を示すノード異常検知パケットを受信した後に、ノードＮ１の異常を確認した場合、または、別のクライアントノードＣＮ２からノードＮ１の異常を示すノード異常検知パケットをさらに受信した場合である。

図９は、クライアントノードＣＮ１で異常が発生した場合のシーケンスを示している。クライアントノードＣＮ１は、業務パケットをノードＮ１〜Ｎｍに送信し（手順９０１）、業務応答パケットが返信されたか否かをチェックする（手順９０２）。ここで、クライアントノードＣＮ１のスローダウンにより、一定時間内にノードＮ１からの業務応答パケットを処理できない場合、誤ってノードＮ１が異常と判断し、ノード異常検知パケットをノードＮ２〜Ｎｍに送信する（手順９０３）。

ノード異常検知パケットを受信したノードＮ２〜Ｎｍは、生存確認パケットをノードＮ１に送信する（手順９０４）。そして、一定時間内にノードＮ１からの生存確認応答パケットを受信するので、ノードＮ１が正常と判断し、切り替え制御は開始しない（手順９０５）。

次に、クライアントノードＣＮ２は、業務パケットをノードＮ１〜Ｎｍに送信し（手順９０６）、ノードＮ１〜Ｎｍから業務応答パケットを受信する（手順９０７）。こうして、クライアントノードＣＮ２から業務運用を継続することができる。

このようなノード異常判定方法によれば、従来のハートビート信号によるノード異常検知方法と比較して、次のような利点がある。
（１）誤検知
異常検出の仕組みを業務パケットと兼用することにより、より直接的かつ正確に、業務を継続できない状態を検知できる。
（２）検知時間
一定時間内（例えば３秒以内）に業務パケットの処理が行われなければ、その宛先ノードを異常とみなすことにすれば、ユーザにとってより納得性のあるノード異常検知時間を設定することができる。

図１０は、クライアントノードＣＮ１およびＣＮ２に設けられるタイマ管理テーブルを示している。このタイマ管理テーブルには、業務グループＩＤ毎に、業務応答パケットの受信を管理するタイマＴＭＲ１の情報が記録される。この例では、業務Ａの業務グループに対して、５秒のタイマ値が設定されており、業務Ｂの業務グループに対してはタイマが設定されていない。

図１１は、ノードＮ１〜Ｎｍに設けられるタイマ管理テーブルを示している。このタイマ管理テーブルには、業務グループＩＤ毎に、生存確認応答パケットの受信を管理するタイマＴＭＲ２の情報が記録される。この例では、業務Ａの業務グループに対して、５秒のタイマ値が設定されており、業務Ｂの業務グループに対してはタイマが設定されていない。

図１０および図１１のタイマ管理テーブルに設定されたタイマ値は、一定間隔でデクリメントされる。
図１２は、ノードＮ１〜Ｎｍに設けられる異常ノードリストを示している。この異常ノードリストには、業務グループＩＤ、異常ノードＩＤ、および検知元クライアントノードＩＤの組み合わせが記録される。この例では、業務Ａの業務グループに対して、ノードＮ１が異常ノードとして記録され、クライアントノードＣＮ１が検知元クライアントノードとして記録されている。

図１３および図１４は、それぞれ業務パケットおよび業務応答パケットのフォーマットを示している。図１３の業務パケットは、パケットＩＤ、業務グループＩＤ、シーケンス番号、データ、および送信元ノードＩＤからなり、図１４の業務応答パケットは、応答を示すパケットＩＤ、業務グループＩＤ、シーケンス番号、および応答ノードＩＤからなる。

図１５および図１６は、それぞれ生存確認パケットおよび生存確認応答パケットのフォーマットを示している。図１５の生存確認パケットは、生存確認を示すパケットＩＤ、業務グループＩＤ、シーケンス番号、および確認要求元ノードＩＤからなり、図１６の生存確認応答パケットは、生存確認応答を示すパケットＩＤ、業務グループＩＤ、シーケンス番号、および応答ノードＩＤからなる。

図１７は、ノード異常検知パケットのフォーマットを示している。図１７のノード異常検知パケットは、ノード異常検知を示すパケットＩＤ、業務グループＩＤ、シーケンス番号、検知元ノードＩＤ、および異常ノードＩＤからなる。

図１８は、クライアントノードにおけるノード異常検知処理のフローチャートである。この処理は、業務グループＩＤに基づいて業務グループ単位で行われる。
クライアントノードは、まず、処理対象の業務グループに対するタイマＴＭＲ１のタイマ値をタイマ管理テーブルに設定し（ステップ１８０１）、ノードＮ１〜Ｎｍに対して業務パケットを送信する（ステップ１８０２）。そして、業務応答パケットの受信待ち処理を行い（ステップ１８０３）、ノードＮ１〜Ｎｍのすべてから業務応答パケットを受信したか否かをチェックする（ステップ１８０４）。

いずれかのノードから業務応答パケットを受信していなければ、タイマ管理テーブルを参照して、タイマＴＭＲ１が経過したか（タイマ値が０になったか）否かをチェックし（ステップ１８０５）、タイマＴＭＲ１が経過していなければ、ステップ１８０３以降の処理を繰り返す。

タイマＴＭＲ１が経過していれば、業務応答パケットの返信がなかったノードを異常とみなし、それ以外のノードにノード異常検知パケットを送信して（ステップ１８０６）、ステップ１８０１以降の処理を繰り返す。ステップ１８０４において、すべてのノードから業務応答パケットを受信すれば、すべてのノードを正常とみなして、ステップ１８０１以降の処理を繰り返す。

図１９は、ノードＮｉのクラスタ制御部によるノード異常判定処理のフローチャートである。この処理も、業務グループＩＤに基づいて業務グループ単位で行われる。
クラスタ制御部は、まず、パケット受信待ち処理を行い（ステップ１９０１）、ノード異常検知パケットを受信したか否かをチェックする（ステップ１９０２）。

ノード異常検知パケットを受信すると、その業務グループに対するタイマＴＭＲ２のタイマ値をタイマ管理テーブルに設定し、業務グループＩＤ、異常ノードＩＤ、および検知元クライアントノードＩＤを、異常ノードリストに記録する（ステップ１９０４）。そして、異常ノードに対して生存確認パケットを送信する（ステップ１９０５）。この時点では、まだクライアントノード内の異常である可能性があるため、切り替え処理は行われない。

ステップ１９０２において、ノード異常検知パケットを受信しなければ、応答処理を行い（ステップ１９０３）、ステップ１９０１以降の処理を繰り返す。この応答処理では、業務パケット（生存確認パケットを含む）を受信したか否かをチェックし、業務パケットを受信していれば、業務応答パケットまたは生存確認応答パケットを返信する。

ステップ１９０５において生存確認パケットを送信した後、パケット受信待ち処理を行い（ステップ１９０６）、業務パケットを受信したか否かをチェックする（ステップ１９０７）。業務パケットを受信していれば、ステップ１９０３と同様の応答処理を行い、ステップ１９０６以降の処理を繰り返す。

業務パケットを受信していなければ、次に、異常ノードリストを参照しながら、別の検知元ノードから、同じ業務グループＩＤおよび異常ノードＩＤを有するノード異常検知パケットを受信したか否かをチェックする（ステップ１９０９）。

そのようなノード異常検知パケットを受信した時点で、２つのクライアントノードにより同じノードの異常が検知されたことが分かる。そこで、その異常ノードＩＤに対応するノード異常を確定し、切り替え処理を行って（ステップ１９１２）、ステップ１９０１以降の処理を繰り返す。ステップ１９１２では、ノード単位の切り替え処理または業務グループ単位の切り替え処理が行われる。

ノード異常検知パケットを受信していなければ、次に、生存確認応答パケットを受信したか否かをチェックする（ステップ１９１０）。生存確認応答パケットを受信すれば、生存確認パケットの宛先ノードを正常とみなし、ステップ１９０１以降の処理を繰り返す。

生存確認応答パケットを受信していなければ、タイマ管理テーブルを参照して、タイマＴＭＲ２が経過したか否かをチェックし（ステップ１９１１）、タイマＴＭＲ２が経過していなければ、ステップ１９０６以降の処理を繰り返す。

タイマＴＭＲ２が経過していれば、生存確認パケットの宛先ノードを異常とみなし、その時点で、クライアントノードとノードＮｉにより同じノードの異常が検知されたことが分かる。そこで、そのノード異常を確定し、切り替え処理を行って（ステップ１９１２）、ステップ１９０１以降の処理を繰り返す。

ところで、上述したようなノード異常判定方法では、ノードＮ１の異常が発生すると、業務グループ単位でノード異常検知パケットが送信され、業務グループ単位で生存確認処理（生存確認パケットおよび生存確認応答パケットの送受信）が行われる。

したがって、図２０に示すように、２つの業務グループ２００１および２００２に対するクラスタ制御２００３が行われている場合、ノードＮ１の異常に伴って、両方の業務グループについて重複してノード異常検知パケットが送信される。このため、クラスタ制御２００３では、ノードＮ１と他のノードＮ２〜Ｎｍの間で、重複して生存確認処理を行う必要がある。

この場合、運用中の業務グループの数に比例して、生存確認処理に要する時間が増加してしまう。特に、ＯＳレイヤの異常等が発生した場合、そのノード上のすべての業務グループについて異常が検出されるため、業務グループの数だけ重複して生存確認処理を行うことになり、効率が悪い。

そこで、同じノード上の２つ以上の業務グループについてノード異常が確定された場合には、ノード自身の異常とみなしてノード単位の切り替えを実行するのが望ましい。この切り替え方法によれば、一旦、ノード単位で切り替えを実行した後は、他の業務グループについての生存確認処理および切り替え処理が抑止されることになる。したがって、複数の業務グループを有するクラスタシステムにおいても、業務グループの数に関わらず、高速に切り替え処理を行うことができる。

この場合、ノードＮ１〜Ｎｍには、上述したタイマ管理テーブルと異常ノードリスト以外に、図２１に示すようなノード異常確定リストが設けられる。このノード異常確定リストには、業務グループ単位の切り替え処理が実行されたときに、その業務グループＩＤと異常ノードＩＤの組み合わせが記録される。この例では、業務Ａの業務グループに対して、ノードＮ１が異常ノードとして記録されている。

クライアントノードにおけるノード異常検知処理と、ノードＮｉのクラスタ制御部によるノード異常判定処理は、それぞれ図１８と図１９に示したものと同様である。ただし、図１９のステップ１９１２においては、図２２に示すような切り替え処理が行われる。

ノードＮｉのクラスタ制御部は、まず、構成情報を参照して、ノードＮｉが属するノードグループに複数の業務グループが登録されているか否かをチェックする（ステップ２２０１）。そして、単一の業務グループしか登録されていなければ、業務グループ単位の切り替えを実行し（ステップ２２０５）、その業務グループＩＤと異常ノードＩＤをノード異常確定リストに記録する（ステップ２２０６）。ステップ２２０５においては、異常ノードのクラスタ制御部に対して、業務グループ単位のＯｆｆｌｉｎｅ切り替え指示を送信する。

ステップ２２０１において、複数の業務グループが登録されていれば、次に、異常ノードリストとノード異常確定リストを参照して、以前に同じノードで業務グループの異常が発生しているか否かをチェックする（ステップ２２０２）。

異常ノードリストの異常ノードＩＤがノード異常確定リストに記録されていなければ、新たなノードで異常が発生したことが分かる。そこで、業務グループ単位の切り替えを実行し（ステップ２２０５）、その業務グループＩＤと異常ノードＩＤをノード異常確定リストに記録する（ステップ２２０６）。

ステップ２２０２において、異常ノードリストの異常ノードＩＤがノード異常確定リストに記録されていれば、以前に同じノードで異常が発生していることが分かる。そこで、次に、以前に発生した異常と同じ業務グループの異常が発生しているか否かをチェックする（ステップ２２０３）。

同じ異常ノードＩＤに関して、異常ノードリストの業務グループＩＤとノード異常確定リストの業務グループＩＤがすべて同じであれば、同じ業務グループの異常であることが分かる。この場合、単一の業務グループの異常であり、既に業務グループ単位の切り替えが実行されているため、切り替えを実行することなく処理を終了する。

ステップ２２０３において、同じ業務グループの異常でなければ、同じノード上の複数の異なる業務グループについてノード異常が確定されたため、ノード単位の切り替えを実行する（ステップ２２０４）。これにより、そのノード上のすべての業務グループの切り替えが一括して行われる。

次に、図２３に示すクラスタシステムにおける業務グループ単位の切り替えについて説明する。このクラスタシステムでは、ノードＮ１〜Ｎ３のクラスタ制御部２３２１〜２３２３により、業務グループ２３０１についてノード異常判定処理が行われる。ここでは、ノードＮ１、Ｎ２、およびＮ３の業務プロセス２３１１、２３１２、および２３１３が、それぞれＡｃｔｉｖｅ、Ｓｔａｎｄｂｙ１、およびＳｔａｎｄｂｙ２に設定されている。

クラスタ制御部２３２２および２３２３は、業務グループ２３０１の運用中にノードＮ１の業務プロセスの異常を検出すると、図２２のステップ２２０５において、業務グループ単位のＯｆｆｌｉｎｅ切り替え指示をクラスタ制御部２３２１に送信する。この場合、クラスタ制御部２３２１および２３２２は、図２４に示すような切り替え処理を行う。

クラスタ制御部２３２１は、まず、当該業務のＯｆｆｌｉｎｅ処理を行い（ステップ２４０１）、構成情報において、業務プロセス２３１１の状態をＡｃｔｉｖｅからＦａｕｌｔに変更する（ステップ２４０２）。Ｆａｕｌｔは、業務グループ故障状態を表す。なお、各業務プロセスの状態の変更は、クラスタ制御部２３２１〜２３２３により、ノードＮ１〜Ｎ３のすべての構成情報に反映されるものとする。

次に、構成情報を参照して切替先ノードを決定し、そのノードのクラスタ制御部にＯｎｌｉｎｅ切り替え指示を送信して（ステップ２４０３）、状態通知待ち処理を行う（ステップ２４０４）。ここでは、Ｓｔａｎｄｂｙ１に設定された業務プロセス２３１２を有するノードＮ２が切替先ノードに決定され、クラスタ制御部２３２２に対して切り替え指示が送信される。

クラスタ制御部２３２２は、切り替え指示に従って当該業務のＯｎｌｉｎｅ処理を行い（ステップ２４１１）、処理が成功したか否かをチェックする（ステップ２４１２）。成功すれば、構成情報において、業務プロセス２３１２の状態をＳｔａｎｄｂｙ１からＡｃｔｉｖｅに変更し（ステップ２４１３）、失敗すれば、その状態をＳｔａｎｄｂｙ１からＦａｕｌｔに変更する（ステップ２４１４）。そして、変更後の状態をクラスタ制御部２３２１に通知する（ステップ２４１５）。

クラスタ制御部２３２１は、通知された状態に基づいて、切り替えが成功したか否かをチェックする（ステップ２４０５）。その状態がＡｃｔｉｖｅであれば成功と判断し、構成情報において、業務プロセス２３１３の状態をＳｔａｎｄｂｙ２からＳｔａｎｄｂｙ１に変更する（ステップ２４０７）。

一方、通知された状態がＦａｕｌｔであれば失敗と判断する。そして、Ｓｔａｎｄｂｙ２に設定された業務プロセス２３１３を有するノードＮ３を次の切替先ノードに決定し、クラスタ制御部２３２３に対して切り替え指示を送信して、ステップ２４０４以降の処理を繰り返す。

次に、図２５に示すように、ノードＮ１が故障した場合のノード単位の切り替えについて説明する。この場合、クラスタ制御部２３２２および２３２３は、ノードＮ１の異常を検出すると、図２２のステップ２２０５において、図２６に示すような切り替え処理を行う。

クラスタ制御部２３２２および２３２３は、まず、構成情報を参照して強制停止発行元ノードを決定し、そのノードからノードＮ１に対して強制停止要求を送信する（ステップ２６０１および２６１１）。ここでは、Ｓｔａｎｄｂｙ１に設定された業務プロセス２３１２を有するノードＮ２が強制停止発行元ノードに決定され、クラスタ制御部２３２２からクラスタ制御部２３２１に対して、強制停止要求が送信される。

次に、クラスタ制御部２３２２は、構成情報において、業務プロセス２３１１の状態をＡｃｔｉｖｅからＤｏｗｎに変更する（ステップ２６０２）。そして、当該業務のＯｎｌｉｎｅ処理を行って（ステップ２６０３）、処理が成功したか否かをチェックする（ステップ２６０４）。成功すれば、構成情報において、業務プロセス２３１２の状態をＳｔａｎｄｂｙ１からＡｃｔｉｖｅに変更する（ステップ２６０５）。

一方、失敗すれば、業務プロセス２３１２の状態をＳｔａｎｄｂｙ１からＦａｕｌｔに変更し（ステップ２６０６）、業務グループ単位のＯｎｌｉｎｅ切り替え指示をクラスタ制御部２３２３に送信する（ステップ２６０７）。

クラスタ制御部２３２３は、切り替え指示に従って当該業務のＯｎｌｉｎｅ処理を行い（ステップ２６２１）、処理が成功したか否かをチェックする（ステップ２６２２）。成功すれば、構成情報において、業務プロセス２３１３の状態をＳｔａｎｄｂｙ２からＡｃｔｉｖｅに変更し（ステップ２６２３）、失敗すれば、その状態をＳｔａｎｄｂｙ２からＦａｕｌｔに変更する（ステップ２６２４）。

なお、構成管理サーバに保持された構成情報は、業務起動時の初期状態を規定しており、業務運用中の切り替え処理によって影響を受けることはない。したがって、業務グループ単位またはノード単位の切り替えによって、そのノードグループ内の構成情報は変更されるが、構成管理サーバの構成情報は変更されない。

上述した図１９のノード異常判定処理においては、２つのノードが同じノードの異常を検知した場合にそのノード異常を確定しているが、その代わりに、Ｋ個（Ｋ≧３）のノードが異常を検知した場合にノード異常を確定するようにしてもよい。

また、図２２の切り替え処理においては、同じノード上の２つの異なる業務グループについてノード異常が確定された場合にノード単位の切り替えを実行しているが、その代わりに、Ｋ個（Ｋ≧３）の業務グループについてノード異常が確定された場合にノード単位の切り替えを実行するようにしてもよい。

ところで、上述した構成管理サーバ１０１、クライアントノードＣＮ１、ＣＮ２、およびノードＮ１〜Ｎｍは、例えば、図２７に示すような情報処理装置（コンピュータ）を用いて構成される。図２７の情報処理装置は、ＣＰＵ（中央処理装置）２７０１、メモリ２７０２、外部記憶装置２７０３、およびネットワーク接続装置２７０４を備え、それらはバス２７０５により互いに接続されている。

メモリ２７０２は、例えば、ＲＯＭ（read only memory）、ＲＡＭ（random access memory）等を含み、処理に用いられるプログラムおよびデータを格納する。ＣＰＵ２７０１は、メモリ２７０２を利用してプログラムを実行することにより、上述した業務処理、クラスタ制御等を行う。

この場合、図１０および図１１のタイマ管理テーブル、図１２の異常ノードリスト、および図２１のノード異常確定リストは、制御データとしてメモリ２７０２に格納され、図２３のクラスタ制御部２３２１〜２３２３は、制御プログラムとしてメモリ２７０２に格納される。

外部記憶装置２７０３は、例えば、磁気ディスク装置、光ディスク装置、光磁気ディスク装置、テープ装置等である。情報処理装置は、この外部記憶装置２７０３に、プログラムおよびデータを格納しておき、必要に応じて、それらをメモリ２７０２にロードして使用する。

ネットワーク接続装置２７０４は、ＬＡＮ（local area network）等の通信ネットワークに接続され、通信に伴うデータ変換を行う。また、情報処理装置は、必要に応じて、プログラムおよびデータを外部の装置からネットワーク接続装置２７０４を介して受け取り、それらをメモリ２７０２にロードして使用する。

図２８は、図２７の情報処理装置にプログラムおよびデータを提供する方法を示している。外部装置２８０１や可搬記録媒体２８０３に格納されたプログラムおよびデータは、情報処理装置２８０２のメモリ２７０２にロードされる。外部装置２８０１は、そのプログラムおよびデータを搬送する搬送信号を生成し、通信ネットワーク上の任意の伝送媒体を介して情報処理装置２８０２に送信する。ＣＰＵ２７０１は、そのデータを用いてそのプログラムを実行し、上述した業務処理、クラスタ制御等を行う。

Claims (4)

1. 複数のクライアントノード装置および複数のサーバノード装置を含むクラスタシステムであって、
   前記複数のクライアントノード装置のうちの第１のクライアントノード装置は、前記複数のサーバノード装置のうち第１のサーバノード装置に業務処理要求を送信し、前記第１のサーバノード装置から前記業務処理要求に対する業務応答を受信しない場合に、前記複数のサーバノード装置のうちの第２のサーバノード装置に対して異常検知情報を送信し、
   前記第２のサーバノード装置は、前記異常検知情報を受信したとき、前記第１のサーバノード装置に対して生存確認要求を送信し、前記生存確認応答を送信してから所定時間該第１のサーバノード装置から生存確認応答を受信しないこと、前記生存確認要求を送信してから前記所定時間経過するまでの間に前記複数のクライアントノード装置のうちの第２のクライアントノード装置からさらに異常検知情報を受信すること、のいずれの条件を満たした場合についても、該第１のサーバノード装置に異常が発生したものと判断して、業務処理を行うサーバノード装置の切り替え制御を開始する、
   ことを特徴とするクラスタシステム。
2. 複数のクライアントノード装置および複数のサーバノード装置を含むクラスタシステムにおけるノード切り替え方法であって、
   前記複数のクライアントノード装置のうちの第１のクライアントノード装置は、前記複数のサーバノード装置のうち第１のサーバノード装置に業務処理要求を送信し、前記第１のサーバノード装置から前記業務処理要求に対する業務応答を受信しない場合に、前記複数のサーバノード装置のうちの第２のサーバノード装置に対して異常検知情報を送信し、
   前記第２のサーバノード装置は、前記異常検知情報を受信したとき、前記第１のサーバノード装置に対して生存確認要求を送信し、前記生存確認応答を送信してから所定時間該第１のサーバノード装置から生存確認応答を受信しないこと、前記生存確認要求を送信してから前記所定時間経過するまでの間に前記複数のクライアントノード装置のうちの第２のクライアントノード装置からさらに異常検知情報を受信すること、のいずれの条件を満たした場合についても、該第１のサーバノード装置に異常が発生したものと判断して、業務処理を行うサーバノード装置の切り替え制御を開始する、
   ことを特徴とするノード切り替え方法。
3. クライアントノード装置および複数のサーバノード装置を含むクラスタシステムにおけるノード切り替え方法であって、
   前記複数のサーバノード装置のうち第１のサーバノード装置に異常が発生したとき、前記クライアントノード装置は、第２のサーバノード装置に対して異常検知情報を送信し、
   前記第２のサーバノード装置は、前記異常検知情報を受信したとき、前記第１のサーバノード装置に対して生存確認要求を送信し、該第１のサーバノード装置から生存確認応答を受信しなければ、該第１のサーバノード装置に異常が発生したものと判断して、業務処理を行うサーバノード装置の切り替え制御を開始し、前記第１のサーバノード装置内のアクティブ業務プロセスと他のサーバノード装置内のスタンバイ業務プロセスを含む業務グループが、該第１のサーバノード装置と他のサーバノード装置を含むノードグループにいくつ割り当てられているかをチェックし、複数の業務グループが該ノードグループに割り当てられており、かつ、該複数の業務グループのうち所定数以上の業務グループについて該第１のサーバノード装置に異常が発生したものと判断した場合は、ノード単位の切り替えを実行することを特徴とするノード切り替え方法。
4. 複数のクライアントノード装置および複数のサーバノード装置を含むクラスタシステムにおけるノード切り替え方法であって、
   前記複数のクライアントノード装置の各々は、前記複数のサーバノード装置のうち第１のサーバノード装置に対して業務処理要求を送信し、該第１のサーバノード装置から業務処理応答を受信しなければ、第２のサーバノード装置に対して異常検知情報を送信し、
   前記第２のサーバノード装置は、２つ以上のクライアントノード装置から前記異常検知情報を受信したときに、前記第１のサーバノード装置に異常が発生したものと判断して、業務処理を行うサーバノード装置の切り替え制御を開始し、前記第１のサーバノード装置内のアクティブ業務プロセスと他のサーバノード装置内のスタンバイ業務プロセスを含む業務グループが、該第１のサーバノード装置と他のサーバノード装置を含むノードグループにいくつ割り当てられているかをチェックし、複数の業務グループが該ノードグループに割り当てられており、かつ、該複数の業務グループのうち所定数以上の業務グループについて該第１のサーバノード装置に異常が発生したものと判断した場合は、ノード単位の切り替えを実行することを特徴とするノード切り替え方法。

Images