(57)【要約】      （修正有）【課題】クラスタシステムが複数に分断された際に、分断されたクラスタシステムでサーバの台数が多いクラスタシステムが立ち上がるようにする。【解決手段】クラスタシステムを構成するサーバ１〜３であって、ハートビート送受信部と、ハートビートメッセージの送受信の失敗の回数を計測するハートビート監視部と、失敗の回数が所定のしきい値を超えた場合に前記クラスタシステムが分断されたと判別するクラスタ管理部と、クラスタシステムの分断を判別した場合、当該サーバが属する分断後の自クラスタシステムのサーバ台数を取得するクラスタ情報管理部と、サーバ台数をストレージ４に書き込むとともに、分断後の他クラスタシステムのサーバ台数を取得するストレージアクセス部と、を備え、クラスタ管理部は、分断後の複数のクラスタシステムの中でサーバ台数が最大のクラスタシステムを選択する。【選択図】図１
2015158787.tif 000002
【特許請求の範囲】
【請求項１】
クラスタシステムを構成するサーバであって、
ハートビートメッセージの送受信を行うハートビート送受信部と、
前記ハートビートメッセージの送受信の失敗の回数を計測するハートビート監視部と、
前記失敗の回数が所定のしきい値を超えた場合に前記クラスタシステムが分断されたと判別するクラスタ管理部と、
前記クラスタシステムの分断を判別した場合、当該サーバが属する分断後の自クラスタシステムのサーバ台数を取得するクラスタ情報管理部と、
前記サーバ台数をストレージに書き込むとともに、前記ストレージから分断後の他クラスタシステムのサーバ台数を取得するストレージアクセス部と、を備え、
前記クラスタ管理部は、分断後の複数のクラスタシステムの中でサーバ台数が最大のクラスタシステムを選択すること
を特徴とするサーバ。
【請求項２】
請求項１記載のサーバであって、
前記ハートビート送受信部は、前記クラスタシステムの分断の判別後、当該サーバの優先度に基づいて設定された時間の経過後にハートビートメッセージを他のサーバに送信すること
を特徴とするサーバ。
【請求項３】
請求項１または２記載のサーバであって、
前記クラスタ管理部は、前記クラスタシステムの分断の判別後、当該サーバの優先度に基づいて設定された時間内に、他のサーバからハートビートメッセージを受信しない場合、当該サーバは分断後の自クラスタシステム内での代表サーバであると判別すること
を特徴とするサーバ。
【請求項４】
請求項３記載のサーバであって、
前記クラスタ管理部が当該サーバを前記代表サーバであると判別した場合、前記ストレージアクセス部は、当該サーバの優先度に応じたタイミングで前記ストレージにアクセスすること
を特徴とするサーバ。
【請求項５】
請求項１から４記載のいずれか一項に記載のサーバであって、
前記クラスタ情報管理部は、前記ハートビート送受信部が送信するハートビートメッセージの応答を用いて分断後の自クラスタシステム内のサーバ台数を取得すること
を特徴とするサーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のサーバで構成されるクラスタシステムにおいて、当該クラスタシステムが複数に分断された場合に新たなクラスタシステムを再構築する技術に関する。
【背景技術】
【０００２】
最近のサーバアーキテクチャは、複数のサーバを連結し1台のサーバのようにみせるクラスタシステムを構築している。クラスタシステムを構築することでサーバやネットワークの故障に対して、システムを停止することがなくサービスを提供できる。クラスタシステムは、複数のサーバをセットとしてアプリケーションを実行することにより、システム負荷を分散できる。クラスタシステムは、アプリケーションを実行する運用系のサーバと、運用系サーバの故障またはネットワークの故障時にアプリケーションの実行を引き継ぐ待機系サーバと、運用系サーバのデータを保持するストレージとから構成される。運用系サーバと待機系サーバの台数はそれぞれ複数台準備されている。クラスタシステムについては、非特許文献１に記載されている。
【０００３】
運用系サーバが停止したことを待機系サーバが検知するには、ハートビートメッセージの技術が利用されている。待機系サーバは運用系サーバからのハートビートメッセージが届かなかった場合に、運用系サーバが故障等によりシステムダウンしたと判断する。そして、待機系サーバが、それまで運用系サーバにより行われていたアプリケーションの実行を引き継ぐ。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】貞苅昌史、他３名、「全順序性を考慮した多ノードクラスタリングの実装方式案と考察」、社団法人  電子情報通信学会、信学技報、2006年7月
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ネットワーク異常によりクラスタシステムが分断されて、分断されたネットワーク毎に所属するサーバでクラスタを再構築し、サーバの台数が過半数以上となるクラスタシステムが構成された場合、サーバの台数が過半数以上となるクラスタシステムが運用系として動作し、サーバの台数が過半数以下となるクラスタシステムは待機系として動作する方式が開発されている。しかしながら、上記方式において、ネットワークの多重障害によりクラスタシステムが複数分断されて全てのクラスタシステムが過半数以下となった場合に、分断された各クラスタシステムの中でどのクラスタシステムが運用系として動作する（立ち上がる）かが判断できない。この場合、以下の２つの方式が提案されている。
【０００６】
第1のロックディスク方式は、ハートビートメッセージの不達を検知後、ネットワーク異常と判断したサーバの中で、ストレージへ先にアクセスできたサーバを運用系とする方式である。
【０００７】
第２のクォーラムサーバ方式は、ハートビートメッセージの不達を検知後、ネットワーク異常と判断したサーバがクォーラムサーバへアクセスし、クォーラムサーバが最適なサーバを判断して運用系サーバを決定する方式である。
【０００８】
ロックディスク方式を適用した場合には、ストレージへ先にアクセスしたクラスタシステムを運用系とするため、クラスタシステムの台数に関係なく運用系が決定される。そのため、クラスタシステムの台数が少ないクラスタシステムが運用系として動作した場合、運用系となったクラスタシステムでサーバの故障・異常の発生時に切り替え先の待機系のサーバの台数を十分に確保されないという課題がある。
【０００９】
クォーラムサーバ方式を適用した場合には、全てのサーバを一元的に管理することができるが、クォーラムサーバへアクセスできない場合、運用系のクラスタシステムを判断することができなくなるためサービスを継続できなくなる。
【００１０】
本発明は、上記の事情に鑑みなされたもので、本発明の目的は、ネットワーク異常などによりクラスタが複数に分断された際に、分断されたクラスタでサーバの台数が多いクラスタが立ち上がるようにすることにある。
【課題を解決するための手段】
【００１１】
上記の課題を解決するため、本発明は、クラスタシステムを構成するサーバであって、ハートビートメッセージの送受信を行うハートビート送受信部と、前記ハートビートメッセージの送受信の失敗の回数を計測するハートビート監視部と、前記失敗の回数が所定のしきい値を超えた場合に前記クラスタシステムが分断されたと判別するクラスタ管理部と、前記クラスタシステムの分断を判別した場合、当該サーバが属する分断後の自クラスタのサーバ台数を取得するクラスタ情報管理部と、前記サーバ台数をストレージに書き込むとともに、前記ストレージから分断後の他クラスタのサーバ台数を取得するストレージアクセス部と、を備え、前記クラスタ管理部は、分断後の複数のクラスタの中でサーバ台数が最大のクラスタを選択する。
【００１２】
前記サーバにおいて、前記ハートビート送受信部は、前記クラスタシステムの分断の判別後、当該サーバの優先度に基づいて設定された時間の経過後にハートビートメッセージを他のサーバに送信することとしてもよい。
【００１３】
前記サーバにおいて、前記クラスタ管理部は、前記クラスタシステムの分断の判別後、当該サーバの優先度に基づいて設定された時間内に、他のサーバからハートビートメッセージを受信しない場合、当該サーバは分断後の自クラスタ内での代表サーバであると判別することとしてもよい。
【００１４】
前記サーバにおいて、前記クラスタ管理部が当該サーバを前記代表サーバであると判別した場合、前記ストレージアクセス部は、当該サーバの優先度に応じたタイミングで前記ストレージにアクセスすることとしてもよい。
【００１５】
前記サーバにおいて、前記クラスタ情報管理部は、前記ハートビート送受信部が送信するハートビートメッセージの応答を用いて分断後の自クラスタ内のサーバ台数を取得することとしてもよい。
【発明の効果】
【００１６】
本発明によれば、ネットワーク異常などによりクラスタが複数に分断された際に、サーバ間のハートビートメッセージを利用して、各クラスタ内のサーバ台数を把握し、分断されたクラスタでサーバの台数が多いクラスタが立ち上がるようにすることができる。
【図面の簡単な説明】
【００１７】
【図１】本発明の実施の形態におけるクラスタシステムの構成図である。
【図２】サーバのクラスタ切替部のブロック図である。
【図３】ストレージのクラスタ情報管理部のブロック図である。
【図４】サーバのハートビート疎通管理テーブルの一例である。
【図５】ストレージの運用系サーバ管理テーブルの一例である。
【図６】ストレージのサーバ台数管理テーブルの一例である。
【図７】代表サーバのクラスタシステムが分断された後の処理フローである。
【図８】代表サーバ以外のサーバのクラスタシステムが分断された後の処理フローである。
【発明を実施するための形態】
【００１８】
以下、本発明の実施の形態について図面を参照して説明する。
【００１９】
図１は、本実施の形態のクラスタシステムの構成図である。クラスタシステムは、複数のサーバ１〜３と、ストレージ４とを備える。図示するクラスタシステムは、便宜上、サーバＡ１、サーバＢ２、サーバＣ３の３つのサーバを示しているが、クラスタシステムのサーバの数は３つに限定されるものではない。各サーバ１〜３は、サーバまたはネットワークの状態に応じて、運用系サーバまたは待機系サーバに柔軟に変更される。
【００２０】
各サーバ１〜３は、サービス提供用のネットワーク５およびストレージ４へのアクセス用のネットワーク６と接続され、各ネットワーク５、６と通信可能となっている。また、各サーバ１〜３は、他の全てのサーバとハートビートメッセージを送受信するためのハートビート監視経路７と接続され、他の全てのサーバと通信可能となっている。サービス提供用のネットワーク５、ストレージへのアクセス用のネットワーク６およびハートビートの監視経路７は、それぞれ別の通信経路となり、ハートビート監視経路７が不通になったとしても、サービス提供のネットワーク５とストレージへのアクセス用のネットワーク６とは通信可能である。
【００２１】
図２は、各サーバ１〜３（運用系サーバおよび待機系サーバ）がそれぞれ備えるクラスタ切替部１０のブロック図である。ハートビートメッセージの通信が不可となった際に、運用系サーバから待機系サーバへ業務を引き継げるように、運用系サーバと待機系サーバとは、同じ機能を有するクラスタ切替部１０を備える。
【００２２】
なお、本実施形態の各サーバ１〜３は、それぞれ異なる優先度があらかじめ設定されているものとする。例えば、図１に示す例では、サーバＡ１が優先度：１（高い）、サーバＢ２が優先度：２、サーバＣ３が優先度：３（低い）が設定されているものとする。
【００２３】
図示するクラスタ切替部１０は、ハートビート監視部１１と、ハートビート送受信部１２と、クラスタ管理部１３と、クラスタ情報管理部１４と、ストレージアクセス部１５とを備える。
【００２４】
ハートビート監視部１１は、ハートビートメッセージの送信または受信を監視し、ハートビートメッセージの送受信の失敗の回数を計測する。また、ハートビート監視部１１は、ハートビート送受信部１２へハートビートメッセージの送信指示を行う。
【００２５】
ハートビート送受信部１２は、他のサーバとの間でハートビートメッセージの送受信を行うとともに、ハートビートメッセージの送信または受信の失敗をハートビート監視部１１へ通知する。また、ハートビート送受信部１２は、クラスタシステムの分断が判別された後、ハートビート監視部１１の指示に従って、当該サーバの優先度に基づいて設定された時間の経過後にハートビートメッセージを他のサーバに送信する。
【００２６】
クラスタ管理部１３は、ハートビート監視部１１が計測した失敗の回数が所定のしきい値を超えた場合にクラスタシステムが分断されたと判別する。また、クラスタ管理部１３は、分断後の複数のクラスタの中でサーバ台数が最大のクラスタを選択する。また、クラスタ管理部１３は、クラスタシステムの分断の判別後、当該サーバの優先度に基づいて設定された時間内に、他のサーバからハートビートメッセージを受信しない場合、当該サーバは分断後の自クラスタシステム内での代表サーバであると判別する。
【００２７】
クラスタ情報管理部１４は、クラスタシステムが分断したと判別された場合、当該サーバが属する分断後の自クラスタシステムのサーバ台数を取得する。具体的には、クラスタ情報管理部１４は、ハートビート送受信部１２が送信するハートビートメッセージの応答を用いて分断後の自クラスタシステム内のサーバ台数を取得する
ストレージアクセス部１５は、ストレージ４へのアクセスを管理する。具体的には、ストレージアクセス部１５は、分断後の自クラスタシステムのサーバ台数をストレージ４に書き込むとともに、ストレージ４から分断後の他クラスタシステムのサーバ台数を取得する。また、ストレージアクセス部１５は、クラスタ管理部１３が当該サーバを代表サーバであると判別した場合、当該サーバの優先度に応じたタイミングでストレージ４にアクセスする。
【００２８】
図３は、ハートビート監視部１１が管理するハートビート疎通管理テーブル１１１の一例を示す図である。ハートビート疎通管理テーブル１１１は、サーバ毎に、サーバ名と、ハートビートメッセージを送信する代表サーバか否かを示す代表サーバフラグと、ハートビートメッセージの送信の可否（成功または失敗）が設定されるハートビート２送信と、ハートビートメッセージの受信の可否が設定されるハートビート受信とを備える。
【００２９】
図３（ａ）は、ハートビートメッセージを送信する代表サーバのハートビート疎通管理テーブル１１１の例である。図３（ｂ）は、代表サーバから送信されるハートビートメッセージを受信する代表サーバ以外のサーバのハートビート疎通管理テーブル１１１の例である。
【００３０】
図４は、ストレージ４が備えるクラスタ情報管理部４０のブロック図である。図示するクラスタ情報管理部４０は、排他制御管理部４１と、データ管理部４２とを備える。排他制御管理部４１は、クラスタシステムを構成する複数のサーバから当該ストレージ４に同時にアクセスされてストレージ４のデータ破壊を生じさせないようにするための排他制御を行う。データ管理部４２は、運用系サーバ管理テーブル４３と、サーバ台数管理テーブル４４とを備え、これらのテーブル４３、４４を管理する。
【００３１】
図５は、運用系サーバ管理テーブル４３の一例を示す図である。運用系サーバ管理テーブル４３は、クラスタシステム内の各サーバについて運用系として動作しているのか、待機系として動作しているのかを管理するためのテーブルである。図示する運用系サーバ管理テーブル４３は、サーバ毎に、サーバ名と、運用系の状態か待機系の状態かを示す運用系フラグとが対応付けて記憶されている。
【００３２】
図６は、サーバ台数管理テーブル４４の一例を示す図である。サーバ台数管理テーブル４４は、当該ストレージ４のクラスタ情報に関するデータを保持する。図示するサーバ台数管理テーブル４４は、クラスタシステム内で動作している代表サーバ毎に、代表サーバ名と、クラスタシステム内で動作しているサーバ台数と、運用系サーバとして動作していたサーバ台数と、クラスタシステム内の各サーバ名とを備える。
【００３３】
上記説明した、本実施形態のサーバ１〜３は、例えば、ＣＰＵと、メモリと、ハードディスク等の外部記憶装置などを備えた汎用的なコンピュータシステムを用いることができる。このコンピュータシステムにおいて、ＣＰＵがメモリ上にロードされたサーバ１〜３用のプログラムを実行することにより、サーバ１〜３の各機能が実現される。また、サーバ１〜３用のプログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ−ＲＯＭなどのコンピュータ読取り可能な記録媒体に記憶することも、ネットワークを介して配信することもできる。
【００３４】
次に、本実施形態の処理について説明する。
【００３５】
図７は、ハートビートメッセージを送信する代表サーバの処理フローである。
【００３６】
代表サーバのハートビート送受信部１２は、ハートビートメッセージをクラスタシステム内の代表サーバ以外の他の全てのサーバに送信している。図７の処理は、代表サーバのハートビート送受信部１２が、少なくとも１つの他のサーバに対するハートビートメッセージの疎通が不可（送信失敗）となったことを検知することにより開始される。
【００３７】
ハートビート送受信部１２は、ハートビートの疎通不可（送信失敗）を検知すると、疎通不可となった他のサーバに関する情報（例えば、サーバ名、サーバＩＤなど）をハートビート監視部１１に通知する。ハートビート監視部１１は、ハートビートメッセージの疎通不可の回数をカウントしている。ハートビート監視部１１は、疎通不可の情報を受け付けると、ハートビート疎通管理テーブル１１１の疎通不可となったサーバの情報を更新する。例えば、サーバＢの疎通不可が初めて通知された場合、ハートビート監視部１１は、図３（ａ）のサーバＢのハートビート送信を「成功」から「失敗」に更新し、失敗の回数に１を設定する。また、次に、サーバＢの疎通不可が通知された場合、ハートビート監視部１１は、失敗の回数をカウントアップして２に更新する。
【００３８】
ハートビート監視部１１は、ハートビート疎通管理テーブル１１１のいずれかのサーバの疎通不可（失敗）の回数が所定の閾値を超える場合（Ｓ１１：ＹＥＳ）、クラスタ管理部１３に通知する。クラスタ管理部１３は、疎通不可（失敗）の回数が所定の閾値を超えた場合、クラスタシステムが分断されたと判別する（Ｓ１２）。すなわち、クラスタ管理部１３は、疎通不可（失敗）の回数を用いてクラスタシステムが分断されたか否かを判別する。なお、疎通不可の回数が閾値以下の場合、クラスタシステムが分断されていないとして、処理を終了する。
【００３９】
ハートビート監視部１１は、クラスタシステムが分断されたとの判別後、当該サーバの優先度に応じて設定された所定時間の経過後に、ハートビート送受信部１２にハートビートメッセージを他の全てのサーバに送信するよう指示する。優先度と所定時間との関係は、優先度が高いほど所定時間が短くなるように設定する。各サーバが優先度に応じて、ハートビートメッセージを送信することにより、各サーバがストレージへアクセスするタイミングを異ならせ、ストレージへの同時アクセスを回避し、同時アクセスによるストレージ破壊を防止することができる。
【００４０】
なお、図７の処理におけるサーバは代表サーバであり、最も高い優先度が設定され、したがって所定時間も他のサーバより短く設定されているため、ハートビートメッセージを他のサーバより早く送信し、これ以降も、代表サーバとして動作する。
【００４１】
クラスタ情報管理部１４は、クラスタシステムの分断後に、当該代表サーバが属する分断後のクラスタシステムのサーバの台数を取得する。すなわち、クラスタ情報管理部１４は、ハートビート送受信部１２が送信したハートビートメッセージに対する応答が返ってきたサーバ（送信成功）の台数およびサーバ名を取得する。
【００４２】
クラスタ管理部１３は、クラスタ情報管理部１４が取得した分断後のクラスタシステムのサーバ台数が、分断前の元のクラスタシステムのサーバ台数の過半数以上か過半数以下かを判別する（Ｓ１３）。応答が返ってきたサーバ台数が過半数以上の場合（Ｓ１３：ＹＥＳ）、クラスタ管理部１３は、当該代表サーバと疎通可能なクラスタシステムを、運用系サーバのクラスタシステムであると判別する（Ｓ１４）。そして、クラスタ管理部１３は、業務を継続可能な運用系サーバの台数を算出し、現在のクラスタシステムにおいて運用系サーバの数が不足する場合は、必要な運用系サーバの台数を確保するために、旧待機系サーバとして動作していたサーバに対して運用系サーバとして起動する指示を送信する（Ｓ１５）。
【００４３】
そして、クラスタ管理部１３は、ストレージ４の運用系サーバ管理テーブル４３の更新指示をストレージアクセス部１５に指示する（Ｓ１６）。すなわち、クラスタ管理部１３は、この時点で運用系サーバとして動作しているサーバの運用系フラグを「運用系」に更新することを指示する。ストレージアクセス部１５は、クラスタ管理部１３の指示を受け付けて、ストレージ４にアクセスし、運用系サーバ管理テーブル４３を更新する。
【００４４】
一方、応答が返ってきたサーバ台数が過半数以下の場合（Ｓ１３：ＮＯ）、クラスタ管理部１３は、当該代表サーバと疎通可能なサーバのクラスタシステムを、待機系サーバのクラスタシステムであると判別し（Ｓ１７）、当該クラスタシステム内で運用系サーバとして動作していた各サーバへ、待機系サーバとして動作する旨の変更指示を送信する（Ｓ１８）。
【００４５】
そして、ストレージアクセス部１５は、ストレージ４へ排他制御解放指示を送信し（Ｓ１９）、クラスタ情報管理部１４が取得した当該分断後のクラスタシステム内のサーバ台数およびサーバ名をサーバ台数管理テーブル４４へ書き込む（Ｓ２０）。また、ストレージアクセス部１５は、当該分断後のクラスタシステム内で、旧運用系サーバとして動作していたサーバ台数をサーバ台数管理テーブル４４へ書き込む。
【００４６】
その際、ストレージアクセス部１５は、サーバ台数管理テーブル４４を参照して、当該代表サーバ以外の他の代表サーバのクラスタシステム内サーバ台数と、運用系サーバとして動作していたサーバ台数とを取得し、クラスタ管理部１３に送出する。
【００４７】
クラスタ管理部１３は、自身のクラスタシステム内のサーバ台数と、他の代表サーバのクラスタシステム内のサーバ台数とを比較し、自身のクラスタシステム内のサーバ台数が最も多い場合はＡＣＴフラグを設定する。なお、一番優先度が高いサーバ(代表サーバ)は、ストレージ４へのアクセスが最初に行われるため（すなわち、他の代表サーバのクラスタシステム内のサーバ台数はまだ書き込まれていないため）、必ずＡＣＴフラグをたてることになる。ここで、ＡＣＴフラグを立てない場合は、Ｓ２６に進み、当該クラスタシステムを待機系サーバのクラスタシステムであると判別し、処理を終了する。
【００４８】
ＡＣＴフラグをたてた代表サーバのストレージアクセス部１５は、一定時間後（他の分断されたクラスタシステムの代表サーバがストレージ４への書き込み終了後）に、ストレージ４内のサーバ台数管理テーブル４４を参照し、当該代表サーバ以外の他の代表サーバのクラスタシステム内サーバ台数と、運用系サーバとして動作していたサーバ台数とを取得し、クラスタ管理部１３に送出する（Ｓ２１）。
【００４９】
クラスタ管理部１３は、自身のクラスタシステムのサーバ台数が、全クラスタシステムの中で最も多い場合は（Ｓ２２：ＹＥＳ）、当該クラスタシステムを運用系サーバのクラスタシステムと判断し、ストレージ４へのアクセスをストレージアクセス部１５に指示する（Ｓ２３）。ストレージアクセス部１５は、ストレージ４へ排他制御指示を送信する。また、クラスタ管理部１３は、業務を継続できる運用系サーバの台数を算出し、旧待機系サーバとして動作していたサーバへ業務の継続可能な台数分を運用系サーバで起動する指示を送信する（Ｓ２４）。
【００５０】
そして、クラスタ管理部１３は、ストレージ４の運用系サーバ管理テーブル４３の更新指示をストレージアクセス部１５に指示する（Ｓ２５）。すなわち、クラスタ管理部１３は、この時点で運用系サーバとして動作しているサーバの運用系フラグを「運用系」に更新することを指示する。ストレージアクセス部１５は、クラスタ管理部１３の指示を受け付けて、ストレージ４にアクセスし、運用系サーバ管理テーブル４３を更新する。
【００５１】
なお、Ｓ２２で、自身のクラスタシステムのサーバ台数が全クラスタシステムの中で最も多い場合であって、同数のサーバ台数の他のクラスタシステムが存在する場合、サーバ台数管理テーブル４４の運用系サーバとして動作していたサーバ台数が多い方のクラスタシステムを運用系サーバのクラスタシステムと判別する。
【００５２】
一方、自身のクラスタシステムのサーバ台数が全クラスタシステムの中で最多でない場合（Ｓ２２：ＮＯ）、クラスタ管理部１３は、当該クラスタシステムを待機系サーバと判断し（Ｓ２６）、処理を終了する。
【００５３】
図８は、ハートビートメッセージを受信する代表サーバ以外のサーバの処理フローである。
【００５４】
代表サーバ以外のハートビート送受信部１２は、ハートビートメッセージを代表サーバから受信している。図８の処理は、代表サーバ以外のサーバのハートビート送受信部１２が、ハートビートメッセージの疎通が不可（受信失敗）となったことを検知することにより開始される。
【００５５】
ハートビート送受信部１２は、ハートビートの疎通不可（受信失敗）を検知すると、疎通不可となったことをハートビート監視部１１に通知する。ハートビート監視部１１は、ハートビート疎通管理テーブル１１１を更新する。例えば、疎通不可が初めて通知された場合、ハートビート監視部１１は、図３（ｂ）のサーバＡのハートビート送信を「成功」から「失敗」に更新し、失敗の回数に１を設定する。また、次に、疎通不可が通知された場合、ハートビート監視部１１は、失敗の回数をカウントアップして２に更新する。
【００５６】
ハートビート監視部１１は、疎通不可（失敗）の回数が所定の閾値を超える場合（Ｓ３１：ＹＥＳ）、クラスタ管理部１３に通知する。クラスタ管理部１３は、疎通不可（失敗）の回数が所定の閾値を超えた場合、クラスタシステムが分断されたと判別する（Ｓ３２）。すなわち、クラスタ管理部１３は、疎通不可（失敗）の回数を用いてクラスタシステムが分断されたか否かを判別する。なお、疎通不可の回数が閾値以下の場合、クラスタシステムが分断されていないとして、処理を終了する。
【００５７】
ハートビート監視部１１は、クラスタシステムが分断されたとの判別後、当該サーバの優先度に応じて設定された所定時間の経過後に、ハートビート送受信部１２にハートビートメッセージを他の全てのサーバに送信するよう指示する。優先度と所定時間との関係は、優先度が高いほど所定時間が短くなるように設定され、各サーバが優先度に応じて、ハートビートメッセージを送信することにより、各サーバがストレージへアクセスするタイミングを異ならせ、ストレージへの同時アクセスを回避し、同時アクセスによるストレージ破壊を防止する。
【００５８】
しかしながら、優先度に応じて設定された所定時間が経過する前に、ハートビート送受信部１２が他のサーバからハートビートメッセージを受信した場合（Ｓ３３：ＹＥＳ）、クラスタ管理部１３は、当該サーバは代表サーバではないと判断して処理を終了する。すなわち、ハートビートメッセージを送信する前に他のサーバからハートビートメッセージを受信した場合、自身のサーバより優先度の高いサーバが代表サーバとして動作していることを検知し、処理を終了する。
【００５９】
一方、ハートビートメッセージを前記所定時間内に受信しない場合（Ｓ３３：ＮＯ）、すなわち、当該サーバより優先度の高いサーバが分断後のクラスタシステム内に存在しない場合、クラスタ管理部１３は、当該サーバは代表サーバであると判断する。この場合、ハートビート監視部１１は、クラスタシステムが分断されたことを判別後（Ｓ３２）、優先度に応じて設定された所定時間の経過後に、ハートビート送受信部１２にハートビートメッセージを他のサーバに送信するよう指示する。ハートビート送受信部１２は、ハートビート監視部１１の指示を受け付けて、ハートビートメッセージを他の全てのサーバに送信する。以降のＳ３４からＳ４７の代表サーバとしての動作は、図７のＳ１３からＳ２６の処理フローと同様であるため、ここでは説明を省略する。
【００６０】
以上説明した本実施形態では、ネットワーク異常などによりクラスタシステムが複数に分断された際に、ハートビートのメッセージが疎通できるサーバ台数をストレージのサーバ台数管理テーブルに書き込むとともに、サーバ台数管理テーブルを参照することで、分断された複数のクラスタシステムの中でサーバの台数が一番多いクラスタシステムを選択する。これにより、ネットワークの異常によりクラスタシステムが複数に分断された後でも、分断されたクラスタシステムの中でサーバ台数が一番多いクラスタシステムを選択できる利点がある。すなわち、分断されたクラスタシステムでサーバの台数が多いクラスタシステムが立ち上がるようにできる。
【００６１】
また、本実施形態では、各サーバにそれぞれ異なる優先度を設定し、その優先度に応じてハートビートメッセージを送信する間隔を変更し、その優先度に応じて各サーバがストレージへアクセスするタイミングを変更させる。すなわち、各サーバが優先度に応じて設定された所定時間の経過後にハートビートメッセージを送信することにより、各サーバがストレージへアクセスするタイミングを異ならせ、ストレージへの同時アクセスを回避し、これにより、ストレージの同時アクセスによるストレージ破壊を防止することができる。
【００６２】
また、本実施形態では、調停役のようなクォーラムサーバをクラスタシステムと別に備えることなく、クラスタシステムが複数に分断された場合に新たなクラスタシステムを再構築することができる。
【００６３】
なお、本発明は上記実施形態に限定されるものではなく、特許請求の範囲内において、種々変更・応用が可能である。
【符号の説明】
【００６４】
１、２、３：サーバ
１０  ：クラスタ切替部
１１  ：ハートビート監視部
１２  ：ハートビート送受信部
１３  ：クラスタ管理部
１４  ：クラスタ情報管理部
１５  ：ストレージアクセス部
４    ：ストレージ
４０  ：クラスタ情報管理部
４１  ：排他制御部
４２  ：データ管理部
４３  ：運用系サーバ管理テーブル
４４  ：サーバ台数管理テーブル
５    ：サービス提供用ネットワーク
６    ：ストレージアクセス用ネットワーク
７    ：ハートビート監視経路
【図１】
2015158787.tif 000003
【図２】
2015158787.tif 000004
【図３】
2015158787.tif 000005
【図４】
2015158787.tif 000006
【図５】
2015158787.tif 000007
【図６】
2015158787.tif 000008
【図７】
2015158787.tif 000009
【図８】
2015158787.tif 000010