JP2023104302A - クラスタシステム、復旧方法 - Google Patents

Abstract

【課題】管理モジュールに障害が発生した際に人手を介することなく復旧するクラスタシステムを提供する。【解決手段】クラスタシステムは複数のノードを含む。ノードの夫々は複数のクラスタを含み、クラスタシステムに含まれる全ての管理モジュールである総管理モジュールのうち１つの管理モジュールが代表管理モジュールに設定され、夫々のクラスタにおいて、１つの管理モジュールがマスタ管理モジュールに設定され、他の管理モジュールがスタンバイ管理モジュールに設定される。管理モジュールの夫々は、他の管理モジュールにおける障害の発生を監視し、何れかの障害監視部により代表管理モジュールにおける障害が検出されると、何れかの非代表管理モジュールを新たな代表管理モジュールとするフェイルオーバ制御部と、何れかの障害監視部により障害が検出された管理モジュールにおいて、障害監視部及びフェイルオーバ制御部を復旧するリカバリ部とを備える。【選択図】図１

Description

本発明は、クラスタシステム、および復旧方法に関する。

大規模システムを実現する手法として、複数の装置を連携して動作させる構成が知られている。特許文献１には、管理プロセッサと、複数の主プロセッサと、を含み、前記複数の主プロセッサは、それぞれ、ホストからのＩ／Ｏ要求に応じたＩ／Ｏ処理を含む主機能処理を実行する期間と、管理指示を実行する期間とを、交互に切り替え、前記管理プロセッサは、前記複数の主プロセッサに対して送信済みで未完了の管理指示と前記未完了の管理指示の送信先主プロセッサとを関連付ける情報を、管理し、前記複数の主プロセッサの前記未完了の管理指示に基づいて、次の管理指示を送信する送信先主プロセッサを前記複数の主プロセッサから選択し、前記送信先主プロセッサに対して前記次の管理指示を送信する、ストレージシステムが開示されている。

特開２０１９－５３５８７号公報

特許文献１に記載されている発明では、障害の発生に対応できない。

本発明の第１の態様によるクラスタシステムは、複数のノードを含むクラスタシステムであって、前記ノードのそれぞれは複数のクラスタを含み、前記クラスタのそれぞれは当該クラスタシステムを管理する管理モジュール、および演算システムを構成する演算モジュールを含み、当該クラスタシステムに含まれる全ての管理モジュールである総管理モジュールのうち１つの前記管理モジュールが代表管理モジュールに設定され、それぞれの前記クラスタにおいて、１つの前記管理モジュールがマスタ管理モジュールに設定され、他の前記管理モジュールがスタンバイ管理モジュールに設定され、前記管理モジュールのそれぞれは、他の前記管理モジュールにおける障害の発生を監視する障害監視部と、いずれかの前記障害監視部により前記代表管理モジュールにおける障害が検出されると、前記総管理モジュールから前記代表管理モジュールを除いた非代表管理モジュールに含まれるいずれかの前記管理モジュールを新たな前記代表管理モジュールとするフェイルオーバ制御部と、いずれかの前記障害監視部により障害が検出された前記管理モジュールにおいて、前記障害監視部および前記フェイルオーバ制御部を復旧するリカバリ部と、を備える。
本発明の第２の態様による復旧方法は、複数のノードを含むクラスタシステムが実行する復旧方法であって、前記ノードのそれぞれは複数のクラスタを含み、前記クラスタのそれぞれは当該クラスタシステムを管理する管理モジュール、および演算システムを構成するストレージモジュールを含み、当該クラスタシステムに含まれる全ての管理モジュールである総管理モジュールのうち１つの前記管理モジュールが代表管理モジュールに設定され、それぞれの前記クラスタにおいて、１つの前記管理モジュールがマスタ管理モジュールに設定され、他の前記管理モジュールがスタンバイ管理モジュールに設定され、前記管理モジュールのそれぞれが、他の前記管理モジュールにおける障害の発生を監視する障害監視処理を行うことと、いずれかの前記管理モジュールにおける前記障害監視処理により前記代表管理モジュールにおける障害が検出されると、前記総管理モジュールから前記代表管理モジュールを除いた非代表管理モジュールに含まれるいずれかの前記管理モジュールを新たな前記代表管理モジュールとするフェイルオーバ処理を行うことと、いずれかの前記管理モジュールにおける前記障害監視処理により障害が検出された前記管理モジュールにおいて、前記障害監視処理および前記フェイルオーバ処理を実現するプログラムを復旧するリカバリ処理を行うことと、を含む。

本発明によれば、管理モジュールに障害が発生した際に人手を介することなく復旧できる。

クラスタシステムの全体構成図 管理表の一例を示す図 代表モジュールに障害が発生した際の概要処理を示すタイムチャート 代表モジュールに障害が発生した際の詳細処理を示すタイムチャート 代表モジュールに障害が発生した際の詳細処理を示すタイムチャート クラスタシステムにおける障害検出時の処理を示すフローチャート

―第１の実施の形態―
以下、図１～図６を参照して、本発明にかかるクラスタシステムの第１の実施の形態を説明する。

図１は、クラスタシステム１の全体構成図である。クラスタシステム１は、ネットワーク９を介してストレージシステムを提供する。クラスタシステム１は、第１ノード１１と、第２ノード１２とを備える。第１ノード１１の構成と、第２ノード１２の構成とは略同一である。第１ノード１１は、第１クラスタ２１と、第２クラスタ２２とを含む。第２ノード１２は、第３クラスタ２３と、第４クラスタ２４とを備える。第１クラスタ２１、第２クラスタ２２、第３クラスタ２３、および第４クラスタ２４の構成は略同一である。そのため以下では、主に第１クラスタ２１の構成および動作を説明する。

クラスタシステム１はさらに、クラスタシステム１とネットワーク９とを接続する第１接続部２および第２接続部３を備える。第１接続部２および第２接続部３はハブ、たとえばスイッチングハブである。第１接続部２は、ネットワーク９と、第１クラスタ２１と、第３クラスタ２３と、第２接続部３とを接続する。第２接続部３は、ネットワーク９と、第２クラスタ２２と、第４クラスタ２４と、第１接続部２とを接続する。

第１クラスタ２１は、ポート２１１と、ハブ２１２と、ストレージモジュール２１３と、第１管理モジュール２１４とを備える。ポート２１１は、第１接続部２およびハブ２１２と接続される。ポート２１１はたとえば複数の接続ポートを備えるネットワークインターフェースカードであり、少なくとも第１接続部２と接続されるポートにおいて、ネットワーク上の識別子、たとえばＩＰアドレスを任意に設定できる。このポートに設定すべきＩＰアドレスは、ハブ２１２を介して第１管理モジュール２１４から指定される。このポートのＩＰアドレスは、ネットワーク９からのアクセスに用いられるので、以下では「外向きのＩＰアドレス」とも呼ぶ。

ハブ２１２は、たとえばスイッチングハブである。ハブ２１２は、ポート２１１と、ストレージモジュール２１３と、第１管理モジュール２１４と、第２クラスタ２２のハブとを接続する。ストレージモジュール２１３は、他のクラスタのストレージモジュールとともにストレージシステムを構成する。このストレージシステムは、高速で堅牢なストレージを提供する。たとえば、外部から入力されたデータのハッシュを算出し、入力されたデータとハッシュを１または複数のストレージモジュールに格納する。ストレージモジュール２１３は、少なくともプロセッサと記憶装置とを備える。

第１管理モジュール２１４は、オペレーティングシステム（以下、「ＯＳ」と呼ぶ）と、ＯＳ上で動作するソフトウエアと、ＯＳから独立して動作するソフトウエアとを備える。障害監視部４２およびフェイルオーバ制御部４３はＯＳ上で動作するソフトウエアにより実現され、リカバリ部４４はＯＳから独立して動作するソフトウエアにより実現される。第１管理モジュール２１４は、少なくともプロセッサと記憶装置とを備える。第１管理モジュール２１４が動作することを原因として、ストレージモジュール２１３の性能が低下することを防止するために、第１管理モジュール２１４とストレージモジュール２１３とはリソースを共有しない。少なくとも、第１管理モジュール２１４が備えるプロセッサと、ストレージモジュール２１３が備えるプロセッサとは、物理的に異なるものである。

第１管理モジュール２１４は、管理表４１と、障害監視部４２と、フェイルオーバ制御部４３と、リカバリ部４４とを備える。管理表４１は記憶装置に格納される情報である。管理表４１は、いずれかの管理モジュールにより書き換えられると、他の管理モジュールに書き換えられた情報が伝達される。そのため本実施の形態では、いずれの管理モジュールも同一の管理表４１を有するとみなす。

障害監視部４２は、同一ノード内の全クラスタを監視して障害発生を検出する。障害監視部４２はたとえば、第１管理モジュール２１４に備えられるプロセッサが、不図示のＲＯＭに格納されたプログラムを不図示のＲＡＭに展開して実行することにより実現される。障害監視部４２は、監視には公知の様々な手法を用いることができる。たとえば障害監視部４２は、一定時間ごとに他の管理モジュールと通信を行い、あらかじめ定めた時間以内に応答がない場合に障害が発生したと判断する。

フェイルオーバ制御部４３は、代表管理モジュールの切り替えを行う。すなわちフェイルオーバ制御部４３は、ある非代表管理モジュールを代表管理モジュールに切り替える。ただしフェイルオーバ制御部４３は単独で動作するのではなく、後述するように複数の管理モジュールのフェイルオーバ制御部４３が協調して動作する。またフェイルオーバ制御部４３は、同一の管理モジュール内の障害監視部４２が非代表管理モジュールの障害を検出すると、障害が検出された管理モジュールに対してＯＳリカバリコマンドを発行する。

リカバリ部４４は、管理モジュールのＯＳから独立して動作するソフトウエアである。リカバリ部４４は、外部からＯＳリカバリコマンドが発行されると動作を開始する。リカバリ部４４は、不図示の記憶部に格納されているＯＳイメージを展開することで、管理モジュールのＯＳおよび障害監視部４２やフェイルオーバ制御部４３を実現するソフトウエアを初期状態に戻すリカバリ処理を行う。さらにリカバリ部４４は、ＯＳリカバリコマンドの後に受信するシステムコンフィグ情報を用いてＯＳやソフトウエアのコンフィグ設定を行う。

各クラスタに含まれる管理モジュールは、実行可能な機能に差異はないが、それぞれのタイミングにおいては特定の１つのみがストレージシステムを統括する代表管理モジュールとなる。以下では、代表管理モジュール以外の管理モジュールを便宜的に「非代表管理モジュール」と呼ぶ。後述するように代表管理モジュールは変更されうるので、どの管理モジュールが代表管理モジュールまたは非代表管理モジュールであるかは、一概に定まらない。

代表管理モジュールは、内蔵される代表機能を有効化した管理モジュールであり、外部からの動作指令を受信してストレージシステムを統括する。本実施の形態では、通信により外部からの動作指令を受信するので、代表管理モジュールの通信における識別子、たとえばＩＰアドレスは、あらかじめ定められた特別な値を用いる。ただしここで言う「特別」とは、ブロードキャストアドレスのようなＩＰアドレスの特殊性ではなく、事前に定められている、または代表管理モジュールの識別子として知られている、という観点で特別であるにすぎない。代表管理モジュールによるストレージシステムの統括には公知の様々な形態が含まれうる。たとえば代表管理モジュールは、外部からの動作指令に基づきストレージシステムの構成を変更する。

代表管理モジュールはストレージシステムを統括するので、代表管理モジュールが動作を停止するとストレージシステムの動作に支障が生じる。そのためクラスタシステム１では、代表管理モジュールに障害が検出されると、自動でフェイルオーバ処理が行われる。このフェイルオーバ処理は、代表管理モジュールに障害が検出されたタイミングにおける非代表管理モジュールが、代表管理モジュールに切り替わる処理である。そのためクラスタシステム１では、代表管理モジュールに障害が発生しても人手を介することなくストレージシステムの稼働を継続できる。

それぞれのクラスタにおいて、１つの管理モジュールがマスタ管理モジュールに設定され、他の管理モジュールがスタンバイ管理モジュールに設定される。マスタ管理モジュールとスタンバイ管理モジュールにハードウエア構成の差異はない。本実施の形態におけるマスタ管理モジュールとスタンバイ管理モジュールの相違点は、代表管理モジュールとなりうるか否かである。後述するように、マスタ管理モジュールとスタンバイ管理モジュールとが入れ替わることもある。

クラスタシステム１に含まれる複数のストレージモジュール２１３において、他のストレージに動作を指示する「統括ストレージモジュール」と、統括ストレージモジュールから指示を受ける「非統括ストレージモジュール」とに分類されてもよい。この場合に、統括ストレージモジュールとマスタ管理モジュールとは同一のクラスタに含まれてもよいし、統括ストレージモジュールとマスタ管理モジュールが異なるクラスタに含まれてもよい。

いずれかのストレージモジュールに障害が発生した際には、同一のクラスタ内に含まれる管理モジュールがそのストレージモジュールを復旧させてもよいし、他のクラスタに含まれる管理モジュールやストレージモジュールが復旧させてもよい。

図２は管理表４１の一例を示す図である。管理表４１には、各モジュールの情報、具体的には、格納されるノード、マスタおよびスタンバイのいずれか、代表であるか否か、およびＩＰアドレスの組み合わせが格納される。管理表４１は複数のレコードから構成され、各レコードはモジュール番号４１１、ノード番号４１２、状態４１３、代表フラグ４１４、およびＩＰアドレス４１５のフィールドを有する。モジュール番号４１１は、管理モジュールの番号である。ノード番号４１２は、管理モジュールが属するノードの番号である。状態４１３は、管理モジュールの状態を表し、たとえば「マスタ」、「スタンバイ」、「停止中」のいずれかである。代表フラグ４１４は、「１」が代表であることを示し、「０」が代表ではないことを示す。

ＩＰアドレス４１５は、管理モジュールの外部向きのＩＰアドレスである。たとえば図２に示す例の最上段は、モジュール番号が「１」である第１管理モジュール２１４は、第１ノード１１に属しており、マスタ、かつ代表であり、ポート２１１における第１接続部２と接続される側のＩＰアドレスが「１９２．１６８．０．１」であることが示されている。管理モジュールのＩＰアドレスは、代表管理モジュールに付される特別なＩＰアドレスと、それ以外の通常のＩＰアドレスに区分される。換言すると、代表管理モジュールのＩＰアドレスは、あらかじめ定めた特別なＩＰアドレス、本実施の形態では「１９２．１６８．０．１」に設定される。

代表管理モジュールが変更されると、換言するとある管理モジュールが代表管理モジュールから非代表管理モジュールに変更されると、その管理モジュールのＩＰアドレスは、前述の特別なＩＰアドレスから特別でないＩＰアドレスに変更される。この、特別でないＩＰアドレスは、たとえば管理モジュールごとにあらかじめ定められる。この場合には、たとえば第１管理モジュール２１４のＩＰアドレスは「１９２．１６８．０．１」および「１９２．１６８．０．１１」のいずれかをとり、第２管理モジュール２２４のＩＰアドレスは「１９２．１６８．０．１」および「１９２．１６８．０．１２」のいずれかをとる。また第３管理モジュール２３４のＩＰアドレスは「１９２．１６８．０．１」および「１９２．１６８．０．１３」のいずれかをとり、第４管理モジュール２４４のＩＰアドレスは「１９２．１６８．０．１」および「１９２．１６８．０．１４」のいずれかをとる。

図３は、代表モジュールに障害が発生した際の概要処理を示すタイムチャートである。図３では図示上方から図示下方に向かって時間が経過している。第１管理モジュール２１４と第２管理モジュール２２４は相互に監視をしており（Ｓ１０１）、第３管理モジュール２３４と第４管理モジュール２４４は相互に監視をしている（Ｓ１０２）。第１管理モジュール２１４に障害が発生すると、第２管理モジュール２２４がこれを検出し（Ｓ１０３）、自らが第１ノード１１のマスタとして動作を開始する（Ｓ１０４）。障害を検出した第２管理モジュール２２４はさらに、他ノードのマスタ管理モジュール、すなわち第３管理モジュール２３４に代表モジュールの障害発生を通知する（Ｓ１０５）。この通知を受けた第３管理モジュール２３４は、代表機能の起動（Ｓ１０６）と、ＩＰアドレスの変更（Ｓ１０７）を行う。このＩＰアドレスの変更対象は、外部向きのＩＰアドレスである。次に第３管理モジュール２３４は、代表モジュールのフェイルオーバ完了通知を第２管理モジュール２２４に送信する（Ｓ１０８）。

この通知を受けた第２管理モジュール２２４は、障害が発生した第１管理モジュール２１４にＯＳリカバリコマンドを発行する（Ｓ１０９）。このコマンドを受信した第１管理モジュール２１４は、ＯＳのリカバリを行い（Ｓ１１０）、リカバリ完了通知を第２管理モジュール２２４に送信する（Ｓ１１１）。リカバリ完了通知を受信した第２管理モジュール２２４は、システムコンフィグ情報を第１管理モジュール２１４に送信する（Ｓ１１２）。これを受信した第１管理モジュール２１４は、コンフィグ設定を行い（Ｓ１１３）、管理表４１における第１管理モジュール２１４の状態を「スタンバイ」に変更して設定完了（Ｓ１１４）となる。最後に第１管理モジュール２１４は、第２管理モジュール２２４に完了通知を送信する（Ｓ１１５）。この通知を受けた第２管理モジュール２２４は、新たな代表モジュールである第３管理モジュール２３４に対して、第１管理モジュール２１４の復旧通知を送信する（Ｓ１１６）。この通知を受けた第３管理モジュール２３４は、書き換えた管理表４１を他の管理モジュールに配布して（Ｓ１１７）、図３に示す処理を終了する。

図４および図５は、代表モジュールに障害が発生した際の詳細処理を示すタイムチャートである。換言すると図４および図５は、図３の詳細を示す図である。図４および図４のそれぞれでは、図示上方から図示下方に向かって時間が経過しており、さらに、図４の最下部よりも図５の最上部の方が後の時刻である。また図４および図５では、それぞれの管理モジュールが備えるリカバリ部４４、フェイルオーバ制御部４３、および管理表４１の動作および変化を記載している。以下では、図３と同一の処理には同一のステップ番号を付与し、図４および図５に特有の処理は新たなステップ番号を付与して説明する。

まずステップＳ１０１およびＳ１０２では、それぞれの障害監視部４２が相互に管理モジュールを監視する。続くステップＳ１０３では第２管理モジュール２２４の障害監視部４２が第１管理モジュール２１４における障害を検出する。すると、第２管理モジュール２２４の障害監視部４２は、同じ第２管理モジュール２２４のフェイルオーバ制御部４３に障害の発生を通知する（Ｓ３０１）。第２管理モジュール２２４のフェイルオーバ制御部４３は、障害が検出された第１管理モジュール２１４のフェイルオーバ制御部４３に停止指示を出し（Ｓ３０２）、これを受けた第１管理モジュール２１４のフェイルオーバ制御部４３は第１管理モジュール２１４の機能停止処理を行い、第１管理モジュール２１４のＩＰアドレス変更処理を行う（Ｓ３０４）。このＩＰアドレス変更処理では、第１管理モジュール２１４の外向きのＩＰアドレスが、代表用の特別なＩＰアドレス、たとえば「１９２．１６８．０．１」から特別ではないＩＰアドレス、たとえば「１９２．１６８．０．１１」に変更される。

第２管理モジュール２２４のフェイルオーバ制御部４３は、前述した第１管理モジュール２１４への停止指示（Ｓ３０２）の後にマスタ機能を起動し（Ｓ１０４）、第３管理モジュール２３４のフェイルオーバ制御部４３にフェイルオーバ通知を送信する（Ｓ１０５）。これを受信した第３管理モジュール２３４のフェイルオーバ制御部４３は、代表機能を起動し（Ｓ１０６）、第３管理モジュール２３４のＩＰアドレス変更処理を行う（Ｓ１０７）。このＩＰアドレス変更処理では、第３管理モジュール２３４の外向きのＩＰアドレスが、特別でないＩＰアドレス、たとえば「１９２．１６８．０．１３」から代表用の特別なＩＰアドレス、たとえば「１９２．１６８．０．１」に変更される。

次にフェイルオーバ制御部４３は、ロール状態の更新、すなわち管理表４１の書き換えを行う（Ｓ３０５）。具体的には、代表フラグ＿を第１管理モジュール２１４から第３管理モジュール２３４に変更し、第１管理モジュール２１４および第３管理モジュール２３４のＩＰアドレスを変更し、第１管理モジュール２１４の状態を「停止中」に変更し、第２管理モジュール２２４の状態を「マスタ」に変更する。次に第３管理モジュール２３４のフェイルオーバ制御部４３は、第２管理モジュール２２４にフェイルオーバ完了通知を送信し（Ｓ１０８）、第４管理モジュール２４４にも同様にフェイルオーバ完了通知を送信する（Ｓ３０６）。

フェイルオーバ完了通知を受信した第２管理モジュール２２４のフェイルオーバ制御部４３は、ロール状態の更新、すなわち管理表４１の更新を第３管理モジュール２３４と同様に行う（Ｓ３０７）。フェイルオーバ完了通知を受信した第４管理モジュール２４４のフェイルオーバ制御部４３は、ロール状態の更新、すなわち管理表４１の更新を第３管理モジュール２３４と同様に行う（Ｓ３０８）。なお第２管理モジュール２２４および第４管理モジュール２４４は、フェイルオーバ完了通知の送信元が新たな代表管理モジュールであるとみなして管理表４１を更新する。図５に進んで説明を続ける。
次に第２管理モジュール２２４のフェイルオーバ制御部４３は、障害が発生した第１管理モジュール２１４にＯＳリカバリコマンドを発行する（Ｓ１０９）。このコマンドを受信した第１管理モジュール２１４のリカバリ部４４は、ＯＳのリカバリを行い（Ｓ１１０）、リカバリ完了通知を第２管理モジュール２２４に送信する（Ｓ１１１）。リカバリ完了通知を受信した第２管理モジュール２２４は、システムコンフィグ情報を第１管理モジュール２１４に送信する（Ｓ１１２）。これを受信した第１管理モジュール２１４は、コンフィグ設定を行い（Ｓ１１３）、ロール情報の更新、すなわち管理表４１における第１管理モジュール２１４の状態の「スタンバイ」への変更を行う（Ｓ１１４）。最後に第１管理モジュール２１４は、第２管理モジュール２２４に完了通知を送信する（Ｓ１１５）。

この通知を受信した第２管理モジュール２２４のフェイルオーバ制御部４３は、第３管理モジュール２３４および第４管理モジュール２４４に対して、第１管理モジュール２１４の復旧通知を送信する（Ｓ１１６、Ｓ３１１）。この通知を受けた第３管理モジュール２３４のフェイルオーバ制御部４３は、ロール情報の更新、すなわち管理表４１における第１管理モジュール２１４の状態の「スタンバイ」への変更を行う。第４管理モジュール２４４のフェイルオーバ制御部４３も同様に、ロール情報の更新、すなわち管理表４１における第１管理モジュール２１４の状態の「スタンバイ」への変更を行い、図４および図５に示す処理を終了する。

図６は、クラスタシステム１における障害検出時の処理を示すフローチャートである。これまでに説明した図３との相関とともに各ステップの処理を説明する。まずステップＳ４０１において、各管理モジュールの障害監視部４２が障害を検出する。いずれの障害監視部４２においても障害が検出されない場合にはステップＳ４０２にとどまる。本ステップは、図３におけるステップＳ１０１～Ｓ１０３に相当する。続くステップＳ４０２では、障害を検出した障害監視部４２は障害発生が代表管理モジュールであるか否かを判断し、代表管理モジュールに障害が発生したと判断する場合はステップＳ４０３に進み、代表管理モジュール以外に障害が発生したと判断する場合はステップＳ４０６に進む。

ステップＳ４０３では、障害を検出した障害監視部４２は、管理表４１を参照して他のノードにおけるマスタの管理モジュールに障害発生を通知する。本ステップは、図３におけるステップＳ１０５に相当する。続くステップＳ４０４では、ステップＳ４０３において通知を受けた管理モジュールが代表機能を起動し、続くステップＳ４０５においてＩＰアドレスを変更してステップＳ４０６に進む。ステップＳ４０４～Ｓ４０５の処理は、図３におけるステップＳ１０６～Ｓ１０７の処理に相当する。

ステップＳ４０６では、障害を検出した障害監視部４２と同一の管理モジュール内のフェイルオーバ制御部４３がＯＳリカバリコマンドを発行することにより、障害が発生した管理モジュールにおけるリカバリ部４４がＯＳのリカバリ処理を行う。本ステップは、図３におけるステップＳ１１０に相当する。続くステップＳ４０７では、障害を検出した障害監視部４２と同一の管理モジュール内のフェイルオーバ制御部４３が、障害が発生した管理モジュールにコンフィグ情報を転送する。本ステップは、図３におけるステップＳ１１２に相当する。続くステップＳ４０８では、障害が発生した管理モジュールのリカバリ部４４が、受信したコンフィグ情報を用いてコンフィグ設定を行い、図６に示す処理を終了する。本ステップは、図３におけるステップＳ１１４に相当する。

なお、ステップＳ４０８の処理が完了すると図６に示す処理は完了するが、再びステップＳ４０１から処理が開始される。ステップＳ４０３～Ｓ４０５の処理は「フェイルオーバ処理」と呼ぶことができ、ステップＳ４０６～Ｓ４０８の処理は「自動復旧処理」と呼ぶことができる。

上述した第１の実施の形態によれば、次の作用効果が得られる。
（１）クラスタシステム１は、複数のノード、すなわち第１ノード１１および第２ノード１２を含む。ノードのそれぞれは複数のクラスタを含む。クラスタのそれぞれはクラスタシステム１を管理する管理モジュール、およびストレージシステムを構成するストレージモジュールを含む。クラスタシステム１に含まれる全ての管理モジュールである総管理モジュールのうち１つの管理モジュールが代表管理モジュールに設定される。それぞれのクラスタにおいて、１つの管理モジュールがマスタ管理モジュールに設定され、他の管理モジュールがスタンバイ管理モジュールに設定される。本実施の形態では１つのノードに２つのクラスタが含まれるので、いずれの管理モジュールにも障害が発生していない状態では、各ノードにマスタ管理モジュールとスタンバイ管理モジュールが１つずつ設定される。管理モジュールのそれぞれは、他の管理モジュールにおける障害の発生を監視する障害監視部４２と、いずれかの障害監視部４２により代表管理モジュールにおける障害が検出されると、いずれかの非代表管理モジュールを新たな代表管理モジュールとするフェイルオーバ制御部４３と、いずれかの障害監視部により障害が検出された管理モジュールにおいて、障害監視部およびフェイルオーバ制御部を復旧するリカバリ部４４と、を備える。そのため、管理モジュールに障害が発生した際に人手を介することなく復旧できる。

たとえば、複数のノードとネットワークで接続され、管理モジュールを統括する統括管理装置を別途設けることでも、いずれかの管理モジュールに障害が発生した際に人手を介することなく復旧することもできる。しかしその場合には各ノードを構成するハードウエア以外に、さらに別のハードウエアである統括管理装置が必要となるため、ハードウエア費用、設置費用、および運営費用の面でデメリットがある。これに対して本実施の形態では、クラスタ内の管理モジュールが他の管理モジュールを復旧させるので、これらのデメリットがない。

（２）管理モジュールのそれぞれには通信用の識別子が設定される。代表管理モジュールにはあらかじめ定められた特別な識別子、たとえば「１９２．１６８．０．１」のＩＰアドレスが設定される。フェイルオーバ制御部４３は、新たな代表管理モジュールに前述の特別な識別子を設定する。そのため、代表管理モジュールが変更されても、ストレージシステムとしての指示を外部から受け取ることができる。

（３）管理モジュールおよびストレージモジュールは異なる物理プロセッサにより実現される。そのため、リカバリ処理などにより管理モジュールの処理が増大しても、ストレージシステムへの影響が生じない。

（４）障害監視部４２は、同一ノード内の他の管理モジュールを監視する。障害監視部４２は、代表管理モジュールにおける障害を検出すると、図４に示したように他のノードにおけるマスタ管理モジュールにおけるフェイルオーバ制御部４３に通知して、当該マスタ管理モジュールを新たな代表管理モジュールにさせる。そのため、管理表４１の記載に基づき新たな代表管理モジュールを決定できる。

（５）管理モジュールのそれぞれは、オペレーティングシステムを搭載する。フェイルオーバ制御部４３および障害監視部４２はオペレーティングシステム上で動作し、リカバリ部４４はオペレーティングシステムから独立して動作する。リカバリ部４４は、同一クラスタ内の管理モジュールにおけるオペレーティングシステムを復旧する。そのため、フェイルオーバ制御部４３および障害監視部４２はＯＳ上で動作する高級言語を用いた作成およびデバッグが可能であり、開発が容易となる。

（変形例１）
上述した実施の形態では、障害を検出した第２管理モジュール２２４において動作するフェイルオーバ制御部４３が第３管理モジュール２３４および第４管理モジュール２４４に復旧通知を送信し、これを契機として第３管理モジュール２３４および第４管理モジュール２４４において管理表４１が更新された。しかし第２管理モジュール２２４のフェイルオーバ制御部４３は、第４管理モジュール２４４には通知を行わず、第３管理モジュール２３４から第４管理モジュール２４４に通知を送信してもよい。

（変形例２）
上述した実施の形態では、障害を検出した第２管理モジュール２２４が管理表４１を参照し、他のノードにおけるマスタ管理モジュール、すなわち第３管理モジュール２３４に障害を通知して、その通知を受けた第３管理モジュール２３４が新たな代表管理モジュールとなった。しかし、障害を検出した管理モジュールは、自らが新たな代表管理モジュールとなってもよい。また、クラスタシステム１に３以上のノードが含まれる場合は、各ノードに優先順位をあらかじめ定めて、障害を検出した管理モジュールは動作中の優先順位が最も高いノードの代表管理モジュールに障害を通知してもよい。

（変形例３）
上述した実施の形態では、通信用の識別子にＩＰアドレスを用いる例を説明した。しかし通信の識別子はＩＰアドレスに限定されず、公知の様々な識別子、たとえばＭＡＣアドレスを用いることができる。また、通信にインターネットプロトコルを用いることは必須の構成ではなく、ＣＡＮ（登録商標）、ＬＩＮ、ＦｌｅｘＲａｙなどの通信プロトコルを用いてもよい。

（変形例４）
上述した実施の形態では、管理モジュールおよびストレージモジュールは異なる物理プロセッサにより実現された。しかし、管理モジュールおよびストレージモジュールが同一の物理プロセッサにより実現されてもよい。また、管理モジュールがＯＳを搭載しなくてもよいし、障害監視部４２、フェイルオーバ制御部４３、およびリカバリ部４４の少なくとも１つが書き換え可能な論理回路、たとえばＦＰＧＡ（Field Programmable Gate Array）により実現されてもよい。障害監視部４２およびフェイルオーバ制御部４３のいずれかがＦＰＧＡにより実現される場合には、リカバリ部４４は不図示の記憶部からコンフィグレーション情報をＦＰＧＡに書き込むことにより障害監視部４２およびフェイルオーバ制御部４３を復旧する。

（変形例５）
上述した実施の形態では、各クラスタには管理モジュールとストレージモジュールが含まれた。しかし、ストレージモジュールの代わりに任意の演算を行う演算モジュールが含まれてもよい。演算モジュールは、演算を行うことが必須の条件であり不揮発性の記憶装置が含まれることは必須の構成要件ではない。ただし、ストレージモジュールも演算モジュールの一種と言える。

上述した各実施の形態および変形例において、機能ブロックの構成は一例に過ぎない。別々の機能ブロックとして示したいくつかの機能構成を一体に構成してもよいし、１つの機能ブロック図で表した構成を２以上の機能に分割してもよい。また各機能ブロックが有する機能の一部を他の機能ブロックが備える構成としてもよい。

上述した変形例は、それぞれ組み合わせてもよい。上記では、種々の実施の形態および変形例を説明したが、本発明はこれらの内容に限定されるものではない。本発明の技術的思想の範囲内で考えられるその他の態様も本発明の範囲内に含まれる。

１…クラスタシステム
４１…管理表
４２…障害監視部
４３…フェイルオーバ制御部
４４…リカバリ部
２１３…ストレージモジュール
２１４…第１管理モジュール
２２４…第２管理モジュール
２３４…第３管理モジュール
２４４…第４管理モジュール

Claims (7)

1. 複数のノードを含むクラスタシステムであって、
   前記ノードのそれぞれは複数のクラスタを含み、
   前記クラスタのそれぞれは当該クラスタシステムを管理する管理モジュール、および演算システムを構成する演算モジュールを含み、
   当該クラスタシステムに含まれる全ての管理モジュールである総管理モジュールのうち１つの前記管理モジュールが代表管理モジュールに設定され、
   それぞれの前記クラスタにおいて、１つの前記管理モジュールがマスタ管理モジュールに設定され、他の前記管理モジュールがスタンバイ管理モジュールに設定され、
   前記管理モジュールのそれぞれは、
   他の前記管理モジュールにおける障害の発生を監視する障害監視部と、
   いずれかの前記障害監視部により前記代表管理モジュールにおける障害が検出されると、前記総管理モジュールから前記代表管理モジュールを除いた非代表管理モジュールに含まれるいずれかの前記管理モジュールを新たな前記代表管理モジュールとするフェイルオーバ制御部と、
   いずれかの前記障害監視部により障害が検出された前記管理モジュールにおいて、前記障害監視部および前記フェイルオーバ制御部を復旧するリカバリ部と、を備える、クラスタシステム。
2. 請求項１に記載のクラスタシステムにおいて、
   前記管理モジュールのそれぞれには通信用の識別子が設定され、
   前記代表管理モジュールにはあらかじめ定められた特別な識別子が設定され、
   前記フェイルオーバ制御部は、新たな前記代表管理モジュールに前記特別な識別子を設定する、クラスタシステム。
3. 請求項１に記載のクラスタシステムにおいて、
   前記管理モジュールおよび前記演算モジュールは異なる物理プロセッサを用いて実現される、クラスタシステム。
4. 請求項１に記載のクラスタシステムにおいて、
   前記障害監視部は、同一ノード内の他の管理モジュールを監視し、
   前記障害監視部は、前記代表管理モジュールにおける障害を検出すると、他の前記ノードにおける前記マスタ管理モジュールにおける前記フェイルオーバ制御部に通知して、当該マスタ管理モジュールを新たな前記代表管理モジュールにさせる、クラスタシステム。
5. 請求項１に記載のクラスタシステムにおいて、
   前記管理モジュールのそれぞれは、オペレーティングシステムを搭載し、
   前記フェイルオーバ制御部および前記障害監視部は前記オペレーティングシステム上で動作し、前記リカバリ部は前記オペレーティングシステムから独立して動作し、
   前記リカバリ部はさらに、前記オペレーティングシステムを復旧する、クラスタシステム。
6. 請求項１に記載のクラスタシステムにおいて、
   前記演算モジュールは、記憶装置および前記記憶装置に記録される情報に関する演算を実行する演算器を含み、
   前記演算システムは、情報の記録および情報の読み出しを行うストレージシステムである、クラスタシステム。
7. 複数のノードを含むクラスタシステムが実行する復旧方法であって、
   前記ノードのそれぞれは複数のクラスタを含み、
   前記クラスタのそれぞれは当該クラスタシステムを管理する管理モジュール、および演算システムを構成するストレージモジュールを含み、
   当該クラスタシステムに含まれる全ての管理モジュールである総管理モジュールのうち１つの前記管理モジュールが代表管理モジュールに設定され、
   それぞれの前記クラスタにおいて、１つの前記管理モジュールがマスタ管理モジュールに設定され、他の前記管理モジュールがスタンバイ管理モジュールに設定され、
   前記管理モジュールのそれぞれが、
   他の前記管理モジュールにおける障害の発生を監視する障害監視処理を行うことと、
   いずれかの前記管理モジュールにおける前記障害監視処理により前記代表管理モジュールにおける障害が検出されると、前記総管理モジュールから前記代表管理モジュールを除いた非代表管理モジュールに含まれるいずれかの前記管理モジュールを新たな前記代表管理モジュールとするフェイルオーバ処理を行うことと、
   いずれかの前記管理モジュールにおける前記障害監視処理により障害が検出された前記管理モジュールにおいて、前記障害監視処理および前記フェイルオーバ処理を実現するプログラムを復旧するリカバリ処理を行うことと、を含む、復旧方法。
   
   

Images