(57)【要約】【課題】クラスタシステムにおいて、スプリットブレインが発生した際の不要なサービス停止を防ぐ。【解決手段】クラスタシステム３０１は、サービスを１または複数のクライアントＣＴ１〜ＣＴｎに提供し、かつハートビート通信路５０を介してハートビート信号を互いに送受信するための複数のクラスタサーバ１５１，１５２と、クォーラムを有するクォーラムサーバ２０１とを備える。クラスタサーバ１５１，１５２は、他のクラスタサーバからハートビート信号を正常に受信できない場合には、クォーラムを確保するための確保要求をクォーラムサーバ２０１へ送信し、クォーラムサーバ２０１は、クラスタサーバから確保要求を受信してから所定時間内に他のクラスタサーバから確保要求を受信したときには、確保要求に対する成功通知を複数のクラスタサーバ１５１，１５２へ送信する。【選択図】図１
2012173996.tif 000002
【特許請求の範囲】
【請求項１】
サービスを１または複数のクライアントに提供し、かつハートビート通信路を介してハートビート信号を互いに送受信するための複数のクラスタサーバと、
クォーラムを有するクォーラムサーバとを備えるクラスタシステムであって、
前記クラスタサーバは、他の前記クラスタサーバから前記ハートビート信号を正常に受信できない場合には、前記クォーラムを確保するための確保要求を前記クォーラムサーバへ送信し、
前記クォーラムサーバは、前記クラスタサーバから前記確保要求を受信してから所定時間内に他の前記クラスタサーバから前記確保要求を受信したときには、前記確保要求に対する成功通知を前記複数のクラスタサーバへ送信する、クラスタシステム。
【請求項２】
前記クラスタサーバは、他の前記クラスタサーバが提供するサービスの情報を有し、
前記クォーラムサーバは、前記確保要求に対する成功通知を前記複数のクラスタサーバへ送信する前に、前記複数のクラスタサーバが他の前記クラスタサーバのサービスを引き継がないように前記複数のクラスタサーバの前記情報を書き換える、請求項１に記載のクラスタシステム。
【請求項３】
前記クォーラムサーバは、先に到着した前記確保要求を送信した前記クラスタサーバが、前記クォーラムを真に確保したことを記憶する、請求項１または２に記載のクラスタシステム。
【請求項４】
前記クォーラムサーバは、前記情報を書き換える際に、前記クォーラムを真に確保した前記クラスタサーバが有する前記情報において、他の前記クラスタサーバが提供するサービスをダミーサービスに書き換える、請求項３に記載のクラスタシステム。
【請求項５】
サービスを１または複数のクライアントに提供し、かつハートビート通信路を介してハートビート信号を互いに送受信するための複数のクラスタサーバと、
クォーラムを有するクォーラムサーバとを備えるクラスタシステムにおけるクラスタ管理方法であって、
前記クラスタサーバが、他の前記クラスタサーバから前記ハートビート信号を正常に受信できない場合には、前記クォーラムを確保するための確保要求を前記クォーラムサーバへ送信するステップと、
前記クォーラムサーバが、前記クラスタサーバから前記確保要求を受信してから所定時間内に他の前記クラスタサーバから前記確保要求を受信したときには、前記確保要求に対する成功通知を前記複数のクラスタサーバへ送信するステップとを含む、クラスタ管理方法。
【請求項６】
サービスを１または複数のクライアントに提供し、かつハートビート通信路を介してハートビート信号を互いに送受信するための複数のクラスタサーバと、
クォーラムを有するクォーラムサーバとを備えるクラスタシステムにおいて用いられるクラスタ管理プログラムであって、コンピュータに、
前記クラスタサーバが、他の前記クラスタサーバから前記ハートビート信号を正常に受信できない場合には、前記クォーラムを確保するための確保要求を前記クォーラムサーバへ送信するステップと、
前記クォーラムサーバが、前記クラスタサーバから前記確保要求を受信してから所定時間内に他の前記クラスタサーバから前記確保要求を受信したときには、前記確保要求に対する成功通知を前記複数のクラスタサーバへ送信するステップとを実行させるための、クラスタ管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クラスタシステム、クラスタ管理方法、およびクラスタ管理プログラムに関し、特に、スプリットブレイン対策を行なうクラスタシステム、クラスタ管理方法、およびクラスタ管理プログラムに関する。
【背景技術】
【０００２】
従来、サーバの障害時に、当該サーバがクライアントに提供していたサービスを別のサーバで継続することを可能とする技術として、クラスタシステムがある。
【０００３】
このようなクラスタシステムでは、当該クラスタシステムを構成する複数のサーバが相互にハートビートと呼ばれる通信を行なうことにより、障害が発生したノードすなわちサーバを検知するのが一般的である。
【０００４】
ハートビート通信とは、フェールオーバーすなわち業務の引き継ぎを互いに行なう関係にある複数のサーバ間で、サーバ機能が停止していないことを示すためのハートビートをやり取りすることにより、互いのサーバの死活監視を行なう技術である。ハートビート通信が行なわれている間は、相手方サーバが正常に稼働しているものと判断され、フェールオーバーは行なわれない。
【０００５】
逆に、ハートビート通信が途切れた場合には、相手方サーバがシステムダウンしたものと判断され、相手方サーバで提供されていた業務アプリケーション等のサービスを自機で引き継ぐ。これにより、サービスを利用するクライアントからは、クラスタシステム全体が１台のサーバのように見える。したがって、現用系サーバから待機系サーバに処理が切り替わった場合でも、クライアントは、どのサーバからサービスが提供されているかを意識することはない。
【０００６】
しかしながら、ハートビート通信のための通信経路の障害により、クラスタシステムを構成する複数のサーバが孤立すると、当該複数のサーバで同じサービスが開始され、データが破壊されるといった、クラスタとして不整合な状態が発生する。このような状態は、スプリットブレインと呼ばれている。
【０００７】
このスプリットブレインを回避するため、定足数（クォーラム：quorum）を用いた多数決方式が知られている。この多数決方式では、クラスタを再構成するためには、５０％より多くのクォーラムを確保する必要がある。
【０００８】
たとえば２ノードで構成されるクラスタでは、クォーラムを各サーバに１つずつ、かつ共有ディスクに１つ保持し、スプリットブレインが発生した場合に、タイブレーク処理として各サーバが共有ディスク上のクォーラムの確保を試みる。クォーラムを先に確保したサーバは過半数（２／３）のクォーラムを持つため、正規のクラスタとして再構成される。すなわち、当該サーバは、他方のサーバ上で動作中のサービスを引き継ぐ。共有ディスク上のクォーラムを確保できなかったサーバは、自身のクォーラム（１／３）を確保するのみであり、過半数を確保できないため、パニックを行なって動作を停止する。
【０００９】
なお、Oracle社 SunCluster 3.2 Release Note for Solaris OS Sun Cluster Quorum Server［online］、［平成23年2月1日検索］、インターネット〈URL：http://docs.sun.com/app/docs/doc/819-6611/gcvsc?a=view〉（非特許文献１）に開示されているように、商用ＵＮＩＸ（登録商標）環境では、共有ディスクの代わりに、クラスタに属していないノードにクォーラムを保持する方法を提供しているクラスタ製品がある。このような技術では、物理的なディスク書き込みが発生しないため、生き残るサーバを高速に決定できる他、ディスク依存した機能を用いなくてもソフトウェアだけで制御できるメリットがある。
【００１０】
また、特開２００６−４８４７７号公報（特許文献１）には、以下のような技術が開示されている。すなわち、クラスタシステムを構成する２つのサーバ（ノード）間の通信が不通になると、それぞれのノードでは、ノード制御部で、割当て時間とその優先度に関する定義情報に基づき、次の割当て時間の開始時刻を算出する。そして、算出された開始時刻まで、所定のサービス処理の起動を遅延させる。そして、割当て時間の開始時刻になると、サービス処理を起動し、割当て時間内にサービスが実行できれば、サービス処理を継続し、サービスが実行できなければ、動作を停止する。
【００１１】
また、特開２００９−２２３５１９号公報（特許文献２）には、以下のような技術が開示されている。すなわち、各ノードのクラスタ管理部は、相互にハートビート通信を行なうことでノード障害を検出する。すると各重み付け処理部は、ノードのサービスの開始に関する状態をチェックし、そのチェックされた状態に応じて、共有ストレージ装置に格納されている重み情報中のノード自身の重みを更新する。各ノードのタイブレーカ機構は、更新された重み情報の示す重みに基づいてノード自身の優先順位が最も高いかを判定し、最も優先順位が高い場合にノード自身をマスタノードとして選択する。
【先行技術文献】
【非特許文献】
【００１２】
【非特許文献１】Oracle社 SunCluster 3.2 Release Note for Solaris OS Sun Cluster Quorum Server［online］、［平成23年2月1日検索］、インターネット〈URL：http://docs.sun.com/app/docs/doc/819-6611/gcvsc?a=view〉
【特許文献】
【００１３】
【特許文献１】特開２００６−４８４７７号公報
【特許文献２】特開２００９−２２３５１９号公報
【発明の概要】
【発明が解決しようとする課題】
【００１４】
クォーラムを過半数確保できなかったサーバ上で動作していたサービスは、クォーラムを過半数確保できたサーバ上で動作するよう再構成される。このため、異なるサーバでサービスの提供を継続させることは可能であるが、この動作により一時的にサービス停止が発生する。
【００１５】
また、データベースのように起動前に復旧処理等を行なうことで整合性を確認する必要のあるサービスも多いため、クラスタのサービスを起動させる際は、サービス提供までに少なからず時間およびコストがかかる。
【００１６】
クラスタノードすなわちサーバ間のハートビートが途切れる原因としては、サーバ自身またはクラスタ管理コンポーネントがハングまたはスローダウンした場合、およびサーバは問題ないがハートビート用の通信経路に障害が発生した場合の２通り考えられる。前者の場合はやむを得ないが、後者の場合には、サーバは正常に動作できるにも関わらず、無駄にサービスの一時停止が発生してしまう。
【００１７】
すなわち、クラスタシステムにおいてスプリットブレインが発生した際に、従来の方法では、クラスタシステムの整合性を保つため、一方のクラスタノード（サーバ）が稼動し、もう一方のクラスタノード（サーバ）が停止するような動作を行なわせる。このため、停止させるサーバ上でサービスの提供が行なわれており、当該サーバが正常に動作できる場合でも、稼動させるサーバ上でサービスを再起動する必要があり、一時的にサービスの停止が発生してしまうという問題点があった。
【００１８】
ここで、ハートビート用の通信経路は、信頼性を向上させるため多重化されることも多い。しかしながら、コストおよびサーバ構成の制限などで多重化できない場合、ならびに通信経路の一部が多重化されない場合もあり、通信経路の単一障害によりハートビートが途切れる可能性がある。たとえば、１つの物理ＮＩＣ（Network Interface Card）の複数のポートを使わざるを得ない環境、および経路上のネットワーク装置を共有せざるを得ない環境では、通信経路の一部が多重化されない。
【００１９】
特許文献１および特許文献２に記載の技術は、いずれもハートビート通信経路障害によるスプリットブレインが発生した場合に、サービスが起動できる正常なサーバを選択し、より正常なノードでサービスを起動させる方法である。
【００２０】
これらの方法では、正常なノードでサービスが動作できる状態でも、優先度またはより信頼性のあるサーバにサービスがフェールオーバーされてしまう可能性があり、無駄にサービスの停止および再起動が発生する可能性がある。
【００２１】
この発明は、上述の課題を解決するためになされたもので、その目的は、クラスタシステムにおいて、スプリットブレインが発生した際の不要なサービス停止を防ぐことが可能なクラスタシステム、クラスタ管理方法、およびクラスタ管理プログラムを提供することである。
【課題を解決するための手段】
【００２２】
上記課題を解決するために、この発明のある局面に係わるクラスタシステムは、サービスを１または複数のクライアントに提供し、かつハートビート通信路を介してハートビート信号を互いに送受信するための複数のクラスタサーバと、クォーラムを有するクォーラムサーバとを備えるクラスタシステムであって、上記クラスタサーバは、他の上記クラスタサーバから上記ハートビート信号を正常に受信できない場合には、上記クォーラムを確保するための確保要求を上記クォーラムサーバへ送信し、上記クォーラムサーバは、上記クラスタサーバから上記確保要求を受信してから所定時間内に他の上記クラスタサーバから上記確保要求を受信したときには、上記確保要求に対する成功通知を上記複数のクラスタサーバへ送信する。
【００２３】
上記課題を解決するために、この発明のある局面に係わるクラスタ管理方法は、サービスを１または複数のクライアントに提供し、かつハートビート通信路を介してハートビート信号を互いに送受信するための複数のクラスタサーバと、クォーラムを有するクォーラムサーバとを備えるクラスタシステムにおけるクラスタ管理方法であって、上記クラスタサーバが、他の上記クラスタサーバから上記ハートビート信号を正常に受信できない場合には、上記クォーラムを確保するための確保要求を上記クォーラムサーバへ送信するステップと、上記クォーラムサーバが、上記クラスタサーバから上記確保要求を受信してから所定時間内に他の上記クラスタサーバから上記確保要求を受信したときには、上記確保要求に対する成功通知を上記複数のクラスタサーバへ送信するステップとを含む。
【００２４】
上記課題を解決するために、この発明のある局面に係わるクラスタ管理プログラムは、サービスを１または複数のクライアントに提供し、かつハートビート通信路を介してハートビート信号を互いに送受信するための複数のクラスタサーバと、クォーラムを有するクォーラムサーバとを備えるクラスタシステムにおいて用いられるクラスタ管理プログラムであって、コンピュータに、上記クラスタサーバが、他の上記クラスタサーバから上記ハートビート信号を正常に受信できない場合には、上記クォーラムを確保するための確保要求を上記クォーラムサーバへ送信するステップと、上記クォーラムサーバが、上記クラスタサーバから上記確保要求を受信してから所定時間内に他の上記クラスタサーバから上記確保要求を受信したときには、上記確保要求に対する成功通知を上記複数のクラスタサーバへ送信するステップとを実行させるプログラムである。
【発明の効果】
【００２５】
本発明によれば、クラスタシステムにおいて、スプリットブレインが発生した際の不要なサービス停止を防ぐことができる。
【図面の簡単な説明】
【００２６】
【図１】本発明の実施の形態に係るクラスタシステムの構成を示す図である。
【図２】本発明の実施の形態に係るクォーラムサーバの概略構成図である。
【図３】本発明の実施の形態に係るクラスタシステムにおいて、構成情報で管理している主な情報を示す図である。
【図４】本発明の実施の形態に係るクォーラムサーバがシステム管理処理を行なう際の動作手順を示すフローチャートである。
【図５】本発明の実施の形態に係るクォーラムサーバがシステム管理処理を行なう際の動作手順を示すフローチャートである。
【図６】本発明の実施の形態に係るクラスタシステムにおける各サーバのサービス管理テーブルの変更例を示す図である。
【図７】本発明の実施の形態に係るクラスタシステムの状態を示す図である。
【図８】本発明の実施の形態に係るクラスタシステムの状態を示す図である。
【図９】本発明の実施の形態に係るクラスタシステムの状態を示す図である。
【発明を実施するための形態】
【００２７】
以下、本発明の実施の形態について図面を用いて説明する。なお、図中同一または相当部分には同一符号を付してその説明は繰り返さない。
【００２８】
［構成および基本動作］
図１は、本発明の実施の形態に係るクラスタシステムの構成を示す図である。
【００２９】
図１を参照して、クラスタシステム３０１は、情報処理装置の一例であるサーバ（クラスタサーバ）１５１，１５２と、情報処理装置の一例であるクォーラムサーバ２０１と、共有ストレージ装置４０と、サービス提供用通信路６０とを備える。サーバ１５１は、クラスタ管理部１１と、サービス管理部１２と、構成情報１３とを含む。サーバ１５２は、クラスタ管理部２１と、サービス管理部２２と、構成情報２３とを含む。
【００３０】
クラスタシステム３０１は、たとえばサーバ１５１，１５２を備える２ノードクラスタシステムである。なお、クラスタシステム３０１は３つ以上のサーバを備える構成であってもよい。以下、クラスタシステム３０１においてサービスを提供するサーバ群をクラスタと称する。サーバ１５１，１５２の各々は、クラスタを構成するクラスタノードに該当する。
【００３１】
サーバ１５１，１５２は、サービスをクライアントＣＴ１〜ＣＴｎ（ｎは１以上の整数）に提供し、かつハートビート通信路５０を介してハートビート信号を互いに送受信する。
【００３２】
より詳細には、共有ストレージ装置４０は、サーバ１５１およびサーバ１５２からアクセス可能である。
【００３３】
サーバ１５１およびサーバ１５２は、互いの死活確認（ハートビート）用のハートビート通信路５０によって接続されている。サーバ１５１およびサーバ１５２は、互いの死活監視を行なうために、ハートビート通信路５０を使用してハートビート信号を定期的に送受信しあう。
【００３４】
また、サーバ１５１およびサーバ１５２は、クライアントＣＴ１〜ＣＴｎにサービスを提供するためのサービス提供用通信路６０に接続されており、この通信路上にクォーラムサーバ２０１が配置される。
【００３５】
本発明の実施の形態に係る情報処理装置であるクォーラムサーバ２０１およびサーバ１５１，１５２は、典型的には、汎用的なアーキテクチャを有するコンピュータを基本構造としており、予めインストールされたプログラムを実行することで、後述するような各種機能を提供する。一般的に、このようなプログラムは、フレキシブルディスク（Flexible Disk）およびＣＤ−ＲＯＭ（Compact Disk Read Only Memory）などの記録媒体に格納されて、あるいはネットワークなどを介して流通する。
【００３６】
本発明の実施の形態に係るプログラムは、ＯＳ等の他のプログラムの一部に組み込まれて提供されるものであってもよい。この場合でも、本発明の実施の形態に係るプログラム自体は、上記のような組み込み先の他のプログラムが有するモジュールを含んでおらず、当該他のプログラムと協働して処理が実行される。すなわち、本発明の実施の形態に係るプログラムとしては、このような他のプログラムに組み込まれた形態であってもよい。
【００３７】
なお、代替的に、プログラムの実行により提供される機能の一部もしくは全部を専用のハードウェア回路として実装してもよい。
【００３８】
図２は、本発明の実施の形態に係るクォーラムサーバの概略構成図である。サーバ１５１，１５２の構成は、たとえばクォーラムサーバ２０１と同様である。
【００３９】
図２を参照して、クォーラムサーバ２０１は、演算処理部であるＣＰＵ（Central Processing Unit）１０１と、メインメモリ１０２と、ハードディスク１０３と、入力インタフェース１０４と、表示コントローラ１０５と、データリーダ／ライタ１０６と、通信インタフェース１０７とを備える。これらの各部は、バス１２１を介して、互いにデータ通信可能に接続される。
【００４０】
ＣＰＵ１０１は、ハードディスク１０３に格納されたプログラム（コード）をメインメモリ１０２に展開し、これらを所定順序で実行することにより、各種の演算を実施する。メインメモリ１０２は、典型的には、ＤＲＡＭ（Dynamic Random Access Memory）などの揮発性の記憶装置であり、ハードディスク１０３から読み出されたプログラムに加えて、各種の演算処理結果を示すデータなどを保持する。また、ハードディスク１０３は不揮発性の磁気記憶装置であり、ＣＰＵ１０１で実行されるプログラムに加えて、各種設定値などが格納される。このハードディスク１０３にインストールされるプログラムは、後述するように、記録媒体１１１に格納された状態で流通する。なお、ハードディスク１０３に加えて、あるいはハードディスク１０３に代えて、フラッシュメモリなどの半導体記憶装置を採用してもよい。
【００４１】
入力インタフェース１０４は、ＣＰＵ１０１とキーボード１０８、マウス１０９および図示しないタッチパネルなどの入力部との間のデータ伝送を仲介する。すなわち、入力インタフェース１０４は、ユーザが入力部を操作することで与えられる操作指令などの外部からの入力を受付ける。
【００４２】
表示コントローラ１０５は、表示部の典型例であるディスプレイ１１０と接続され、ディスプレイ１１０での表示を制御する。すなわち、表示コントローラ１０５は、ＣＰＵ１０１による画像処理の結果などをユーザに対して表示する。ディスプレイ１１０は、たとえばＬＣＤ（Liquid Crystal Display）またはＣＲＴ（Cathode Ray Tube）である。
【００４３】
データリーダ／ライタ１０６は、ＣＰＵ１０１と記録媒体１１１の間のデータ伝送を仲介する。すなわち、記録媒体１１１は、クォーラムサーバ２０１で実行されるプログラムなどが格納された状態で流通し、データリーダ／ライタ１０６は、この記録媒体１１１からプログラムを読み出す。また、データリーダ／ライタ１０６は、ＣＰＵ１０１の内部指令に応答して、クォーラムサーバ２０１における処理結果などを記録媒体１１１へ書き込む。なお、記録媒体１１１は、たとえば、ＣＦ（Compact Flash）およびＳＤ（Secure Digital）などの汎用的な半導体記憶デバイス、フレキシブルディスク（Flexible Disk）などの磁気記憶媒体、またはＣＤ−ＲＯＭ（Compact Disk Read Only Memory）などの光学記憶媒体である。
【００４４】
通信インタフェース１０７は、ＣＰＵ１０１と他のパーソナルコンピュータおよびサーバ装置などの間のデータ伝送を仲介する。通信インタフェース１０７は、典型的には、イーサネット（登録商標）またはＵＳＢ（Universal Serial Bus）の通信機能を有する。なお、記録媒体１１１に格納されたプログラムをクォーラムサーバ２０１にインストールする形態に代えて、通信インタフェース１０７を介して配信サーバなどからダウンロードしたプログラムをクォーラムサーバ２０１にインストールしてもよい。
【００４５】
また、クォーラムサーバ２０１には、必要に応じてプリンタなどの他の出力装置が接続されてもよい。
【００４６】
［制御構造］
次に、クォーラムサーバ２０１における死活監視機能を提供するための制御構造について説明する。
【００４７】
図１は、本発明の実施の形態に係る各サーバが提供する制御構造も示している。図１に示すクォーラムサーバ２０１およびサーバ１５１，１５２における各ブロックは、ハードディスク１０３に格納されたプログラム（コード）などをメインメモリ１０２に展開して、ＣＰＵ１０１に実行させることで提供される。なお、図１に示すクォーラムサーバ２０１およびサーバ１５１，１５２の制御構造の一部もしくは全部を専用ハードウェアおよび／または配線回路によって実現してもよい。
【００４８】
図１を参照して、クォーラムサーバ２０１は、その制御構造として、タイブレーカ部３２を備える。サーバ１５１は、その制御構造として、クラスタ管理部１１と、サービス管理部１２とを備える。サーバ１５２は、その制御構造として、クラスタ管理部２１と、サービス管理部２２とを備える。また、クォーラムサーバ２０１は、クォーラム記憶域３１を備える。サーバ１５１は、クラスタ構成情報１３を備える。サーバ１５２は、クラスタ構成情報２３を備える。
【００４９】
クォーラムサーバ２０１において、クォーラム記憶域３１は、ロック機能を提供する。また、タイブレーカ部３２は、各サーバからのクォーラム確保要求を調停する。
【００５０】
タイブレーカ部３２は、クラスタシステム３０１におけるクラスタを構成するサーバ１５１およびサーバ１５２からクォーラム確保要求（以下、確保要求とも称する。）を受信すると、クォーラム記憶域３１においてクォーラム（ロック）が取得されていることを他のサーバが認識できるようにマークを行なう。
【００５１】
また、タイブレーカ部３２は、クォーラム（ロック）が未確保の状態であった場合には、確保要求を送信したサーバにクォーラム確保成功通知（以下、成功通知とも称する。）を返す。一方、タイブレーカ部３２は、他のサーバがクォーラム確保済みでクォーラムが確保できなかった場合には、確保要求を送信したサーバにクォーラム確保失敗通知（以下、失敗通知とも称する。）を返す。通常、複数のサーバからクォーラムサーバ２０１にほぼ同時に確保要求が届いた場合には、先に届いた確保要求を送信したサーバがクォーラムを確保し、後から届いた確保要求を送信したサーバはクォーラム確保に失敗する。
【００５２】
クォーラムサーバ２０１では、従来技術のようにあるサーバから確保要求を受け取ってもすぐにクォーラムを確保するのではなく、許容時間内で他のサーバからの確保要求を待ち合わせる。クォーラムサーバ２０１では、許容時間内に複数のサーバから確保要求があった場合には、各サーバ上でサービスが重複して起動されないように制御を行った上で、先に届いた確保要求を送信したサーバにクォーラムを取得させ、他の各サーバに成功通知を返す。
【００５３】
サーバ１５１，１５２は、クラスタを管理する機能として、クラスタ管理部１１，２１と、サービス管理部１２，２２と、クラスタの各種情報を記録する記憶域であるクラスタ構成情報１３，２３とをそれぞれ備える。
【００５４】
クラスタ管理部１１，２１は、クラスタの状態を監視し、クラスタ構成情報（以下、構成情報とも称する。）１３，２３をそれぞれ管理する。クラスタ管理部１１，２１は、ハートビート通信路５０経由で他サーバにおけるクラスタ管理部２１，１１とハートビート信号をそれぞれ送受信することにより、死活確認を行なう。
【００５５】
また、クラスタ管理部１１，２１は、構成情報１３，２３の管理をそれぞれ担い、クラスタ内で起動中のサーバ間で同一の構成情報を保持する。また、クラスタ管理部１１，２１は、クラスタ内のサーバが起動してメンバとして加わった場合、およびハートビートが途切れた場合にクラスタを再構成する役割を担う。ここで、クラスタの再構成とは、クラスタ内のメンバの状態を変更し、サービスを適切なサーバで再起動することである。
【００５６】
また、各サーバのクラスタ管理部１１，２１は、クォーラムを１つずつ保持する。クォーラムサーバ２０１上に１つのクォーラムが存在するため、クラスタシステム３０１では合計３つのクォーラムが存在する。
【００５７】
クラスタ管理部１１，２１は、ハートビート信号が途切れた場合には、クォーラムサーバ２０１のクォーラムの取得を試みる。
【００５８】
クラスタ管理部１１，２１は、クォーラムサーバ２０１から成功通知を受けた場合には、システムの過半数（２／３）以上のクォーラムを確保したことから、自身を正規のクラスタとして再構成する、すなわち、他サーバのサービスを引き継ぐ。
【００５９】
一方、クラスタ管理部１１，２１は、クォーラムサーバ２０１から失敗通知を受けた場合には、保持するクォーラムが、自身のクォーラム（１／３）のみであり過半数に満たないことから、自身の動作を停止（パニック）させる。
【００６０】
また、クラスタ管理部１１，２１は、サーバ起動時にもクォーラムサーバ２０１に確保要求を行い、過半数のクォーラムを得る必要がある。
【００６１】
クラスタ管理部１１，２１がクォーラムサーバ２０１のクォーラム確保に失敗した場合には、クォーラムサーバ２０１のクォーラムを確保しているサーバの起動を待ち合わせる必要があり、その後に起動が許可される。その際、クォーラムサーバ２０１のクォーラムを確保しているサーバの構成情報の同期（コピー）が行なわれる。構成情報１３，２３の同期がとれると、クラスタ管理部１１，２１は、クォーラムサーバ２０１のクォーラムの解放を行なう。
【００６２】
サービス管理部１２，２２は、それぞれ、クラスタ管理部１１，２１と連携し、構成情報１３，２３に基づいてサービスの起動、停止および監視を制御する。
【００６３】
図３は、本発明の実施の形態に係るクラスタシステムにおいて、構成情報で管理している主な情報を示す図である。
【００６４】
図３を参照して、構成情報は、たとえば、クラスタに参加しているサーバおよびその状態を保持するクラスタメンバテーブル９０と、サービスの構成要素、サービスの状態、および当該サービスが動作しているサーバを保持するサービス管理テーブル９１とを有する。
【００６５】
サービスの構成要素は、一般的には、主要要素であるアプリケーション名、そのアプリケーションが使用するディスク領域（以下、ＬＵＮとも称する。）、およびクライアントからの要求を待ち受けるための仮想ＩＰアドレス（以下、ＶＩＰとも称する。）で構成される。アプリケーションがディスクおよびネットワーク機能を必要としない場合には、ＬＵＮおよびＶＩＰをサービスの構成要素から外すことも可能である。
【００６６】
［動作］
次に、本発明の実施の形態に係る情報処理装置の動作について図面を用いて説明する。本発明の実施の形態では、クォーラムサーバ２０１およびサーバ１５１，１５２を動作させることによって、本発明の実施の形態に係るクラスタ管理方法が実施される。よって、本発明の実施の形態に係るクラスタ管理方法の説明は、以下のクォーラムサーバ２０１およびサーバ１５１，１５２の動作説明に代える。なお、以下の説明においては、適宜図１を参照する。
【００６７】
図１に示すように、サーバ１５１上でサービス１が動作し、かつサーバ１５２上でサービス２が動作している状態で、ハートビート通信路５０上のハートビートが途切れると、サーバ１５１およびサーバ１５２におけるクラスタ管理部１１，２１は、ハートビートが断絶したことを検出する。そして、クラスタ管理部１１，２１は、過半数のクォーラムを確保するために、クォーラムサーバ２０１に確保要求を発行する。
【００６８】
すなわち、サーバ１５１，１５２は、他のサーバからハートビート信号を正常に受信できない場合には、クォーラムを確保するための確保要求をクォーラムサーバ２０１へ送信する。
【００６９】
クォーラムサーバ２０１は、サーバ１５１，１５２から確保要求を受信してから所定時間内に他のサーバから確保要求を受信したときには、確保要求に対する成功通知をサーバ１５１，１５２へ送信する。
【００７０】
また、サーバ１５１，１５２は、他のサーバが提供するサービスの情報を含む構成情報を有する。
【００７１】
クォーラムサーバ２０１は、確保要求に対する成功通知をサーバ１５１，１５２へ送信する前に、サーバ１５１，１５２が他のサーバのサービスを引き継がないようにサーバ１５１，１５２の構成情報を書き換える。
【００７２】
また、クォーラムサーバ２０１は、先に到着した確保要求を送信したサーバが、クォーラムを真に確保したことを記憶する。
【００７３】
また、クォーラムサーバ２０１は、構成情報を書き換える際に、クォーラムを真に確保したサーバが有する構成情報において、他のサーバが提供するサービスをダミーサービスに書き換える。
【００７４】
より詳細には、クラスタを構成するサーバ１５１およびサーバ１５２でそれぞれサービス１およびサービス２が動作している状態において、サーバ１５１およびサーバ１５２間のハートビート信号が途切れた場合に、各サーバは、クォーラムサーバ２０１のクォーラムの確保を試みる。クォーラムサーバ２０１におけるタイブレーカ部３２は、クォーラムサーバ２０１にサーバ１５１およびサーバ１５２から確保要求が許容時間内に届いた場合には、両サーバともサービスの稼動が可能とみなす。そして、タイブレーカ部３２は、クラスタの整合性が損なわれないように排他制御を行なわせた上で、サーバ１５１およびサーバ１５２へクォーラムが確保できた旨を通知し、両方のサーバ上で動作中のサービスを継続動作させる。
【００７５】
具体的には、クォーラムサーバ２０１におけるタイブレーカ部３２は、以下の図４および図５に示すフローチャートに基づいて調停を行なう。なお、ここでは、先にサーバ１５１からの確保要求がクォーラムサーバ２０１に届いた場合について説明する。
【００７６】
図４および図５は、本発明の実施の形態に係るクォーラムサーバがシステム管理処理を行なう際の動作手順を示すフローチャートである。
【００７７】
図４および図５を参照して、タイブレーカ部３２は、サーバ１５１から確保要求が届くと（ステップＡ１）、許容時間内でサーバ１５２からの確保要求を待ち合わせる（ステップＡ２）。
【００７８】
次に、タイブレーカ部３２は、許容時間内にサーバ１５２から確保要求を受けると、サーバ１５２に対してハートビート用のＮＩＣを閉塞させる依頼を行なう（ステップＡ３）。タイブレーカ部３２は、たとえば、リモートシェルを用いてハートビート用のＮＩＣをソフトウェア的にオフラインにする。これにより、ハートビートの通信路障害が間欠障害であった場合等に、図４および図５に示すフローチャートの処理が実行されている間に再度ハートビートが再開され、整合性に矛盾をきたすことを防ぐことができる。
【００７９】
次に、タイブレーカ部３２は、サーバ１５２におけるハートビート用ＮＩＣを閉塞した後、サーバ１５１におけるクラスタ管理部１１に対してサーバ１５１の構成情報１３の変更を依頼する。この依頼の内容は、サービス管理テーブル９１において、サーバ１５２上で動作しているサービス２をダミーサービス、すなわちＬＵＮおよびＶＩＰを構成せず、定期的に単純に簡単な計算を行なうアプリケーションのみの構成に差し替えるものである（ステップＡ５）。
【００８０】
次に、依頼を受けたサーバ１５１におけるクラスタ管理部１１は、構成情報１３のサービス管理テーブル９１を変更する（ステップＡ６）。
【００８１】
図６は、本発明の実施の形態に係るクラスタシステムにおける各サーバのサービス管理テーブルの変更例を示す図である。
【００８２】
図６を参照して、サーバ１５１におけるサービス管理テーブル９１において、サーバ１５２上で動作しているサービス２がダミーサービスに変更され、サービス管理テーブル９１ａのようになる。
【００８３】
このようにサービス管理テーブル９１を変更することにより、後述するステップＡ１０までたどり着いた場合において、サーバ１５２において動作中のサービス２が使用するＬＵＮおよびＶＩＰ等のリソースと競合が発生することを防ぐことができる。なお、ダミーサービスを起動させるように変更することにより、ステップＡ１０以降のシステム運用、または事後解析時にダミーサービス等の稼動状況を認識できるようになる。
【００８４】
次に、タイブレーカ部３２は、サーバ１５１の構成情報１３の変更後、サーバ１５２に対して構成情報２３の変更を依頼する（ステップＡ７）。この依頼の内容は、サービス管理テーブル９１において、自身のサーバ以外で動作中のサービスの情報を削除するものである。
【００８５】
次に、依頼を受けたサーバ１５２におけるクラスタ管理部２１は、自身の構成情報２３のサービス管理テーブル９１を変更する。
【００８６】
図６を参照して、サーバ１５２におけるサービス管理テーブル９１において、サーバ１５２以外で動作中のサービス１が削除され、サービス管理テーブル９１ｂのようになる。
【００８７】
このようにサービス管理テーブル９１を変更することにより、後述するステップＡ１０までたどり着いた場合において、サーバ１５１において動作中のサービス１が使用するＬＵＮおよびＶＩＰ等のリソースと競合が発生することを防ぐことができる。また、ステップＡ１０までたどり着いた場合には、サーバ１５２に対して、擬似的に自身が生き残るべきクラスタであると認識させて動作を継続させるが、それ以降、サーバ１５２の構成情報は正式な情報として利用されない。このため、サーバ１５２に対して自身以外のサービスの情報を削除させる。
【００８８】
次に、サーバ１５２の構成情報２３の変更後、サーバ１５１は、クォーラムサーバ２０１のクォーラムを確保（ロック）する（ステップＡ９）。
【００８９】
次に、タイブレーカ部３２は、サーバ１５１およびサーバ１５２の両方に対して成功通知を発行する。（ステップＡ１０）。
【００９０】
次に、サーバ１５１におけるクラスタ管理部１１は、成功通知を受けて、構成情報１３のクラスタメンバテーブル９０におけるサーバ１５２の状態をオフラインに変更し、サービス管理部１２に対してサーバ１５２上で動作しているサービスの起動を指示する。ここで、サーバ１５１では、ステップＡ５において構成情報１３を変更していることから、実際にはサービス２ではなくダミーサービスが起動する。
【００９１】
また、サーバ１５２におけるクラスタ管理部２１は、成功通知を受けて、構成情報２３のクラスタメンバテーブル９０におけるサーバ１５１の状態をオフラインに変更し、サービス管理部２２に対してサーバ１５１上で動作しているサービスの起動を指示する。ここで、ステップＡ７においてサービス管理テーブル９１におけるサーバ１５１上で動作しているサービスの情報は削除されていることから、実際には何も起動されない。
【００９２】
図７は、本発明の実施の形態に係るクラスタシステムの状態を示す図である。
【００９３】
ステップＡ１０までたどり着いた場合には、クラスタシステム３０１は、図７に示すような状態となる。このステップＡ１０までの処理において、動作中のサービス１および２の停止、ならびに再起動が発生しないことから、サーバ１５１上のサービス１およびサーバ１５２上のサービス２は稼動したままである。このため、各クライアントにおいてサービス提供可能な状態が継続される。
【００９４】
ステップＡ１０の処理が実行された後、クォーラムサーバ２０１におけるタイブレーカ部３２は、サーバ１５２におけるクラスタ管理部２１の死活監視を行なう。
【００９５】
タイブレーカ部３２は、サーバ１５２がサーバ停止等を行った場合には、サーバ１５２の応答が無くなることを検知し、サーバ１５１におけるクラスタ管理部１１に対してダミーサービスを一旦オフラインにさせる。そして、タイブレーカ部３２は、クラスタ管理部１１に対して、ステップＡ５で変更する前のサービス管理テーブル９１に差し替えさせる、すなわちダミーサービスをサービス２に変更させた上で、サーバ１５１においてサービス２を起動させる。
【００９６】
なお、ステップＡ１０を実行した後で、サーバの停止および起動等によりクラスタの再構成が必要となった場合には、正規のクラスタ構成情報として、先に確保要求を送信したサーバ１５１の構成情報１３が採用される。
【００９７】
この場合、ステップＡ９において、クォーラムサーバ２０１のクォーラム記憶域３１はサーバ１５１がロックしており、サーバ１５１は過半数のクォーラムを得ることができるため、サーバ１５１は単独で再起動が可能である。一方、サーバ１５２は、過半数のクォーラムを確保できないため単独での再起動できない。
【００９８】
また、サーバ１５２の再起動時にはサーバ１５１が起動している必要があり、再起動の際、サーバ１５２の構成情報２３は、サーバ１５１の持つ正式な構成情報１３と同期（一致）がとられる。この同期がとられて初めて、サーバ１５２をクラスタとして起動することができる。両方のサーバで構成情報の整合がとられると、クォーラムサーバ２０１上のクォーラム記憶域３１から、サーバ１５１が確保しているクォーラムロックが削除される。
【００９９】
次に、図４および図５に示すフローチャートにおいて、処理が正常に行なわれなかった場合の処理について説明する。
【０１００】
タイブレーカ部３２は、ステップＡ１０まで辿りつかない場合には、ハートビート通信路５０の障害ではなく、サーバ１５１，１５２のいずれかがハングおよびスローダウン等、動作不能な状態になったと判断し、適切なサーバでサービスを引き継ぐように、以下の動作を行なう。
【０１０１】
タイブレーカ部３２は、許容時間内にサーバ１５２からの確保要求が届かない場合には（ステップＡ２でＮＯ）、サーバ１５２は動作不能であるとみなす。そして、タイブレーカ部３２は、サーバ１５１によるクォーラム確保（ステップＡ２１）後、サーバ１５１に成功通知を発行する（ステップＡ２２）。
【０１０２】
サーバ１５１におけるクラスタ管理部１１は、成功通知を受けて、構成情報１３のクラスタメンバテーブル９０におけるサーバ１５２の状態をオフラインに変更し、サーバ１５２上で動作しているサービス２の起動を試みる。
【０１０３】
また、タイブレーカ部３２は、サーバ１５２におけるハートビート用ＮＩＣの閉塞に失敗した場合には（ステップＡ４でＮＯ）、サーバ１５２は動作不能であるとみなす。そして、タイブレーカ部３２は、サーバ１５１によるクォーラム確保（ステップＡ４１）後、サーバ１５１に成功通知を発行し、サーバ１５２に失敗通知を発行する（ステップＡ４２）。
【０１０４】
サーバ１５１におけるクラスタ管理部１１は、成功通知を受けて、構成情報１３のクラスタメンバテーブル９０におけるサーバ１５２の状態をオフラインに変更し、サーバ１５２上で動作しているサービス２の起動を試みる。
【０１０５】
一方、サーバ１５２におけるクラスタ管理部２１は、失敗通知を受けて、クォーラムが過半数に満たないことから、自身の動作停止（パニック）を試みる。
【０１０６】
また、タイブレーカ部３２は、サーバ１５１の構成情報変更に失敗した場合には（ステップＡ６でＮＯ）、サーバ１５１は動作不能であるとみなす。そして、タイブレーカ部３２は、サーバ１５２にサービス１を引き継がせるため、ステップＡ３において閉塞させたサーバ１５２におけるハートビート用のＮＩＣ閉塞を解除する（ステップＡ６１）。
【０１０７】
そして、タイブレーカ部３２は、サーバ１５２によるクォーラム確保（ステップＡ６２）後、サーバ１５２にクォーラム確保成功の通知を発行し、サーバ１５１に確保失敗の通知を発行する（ステップＡ６３）。
【０１０８】
サーバ１５２におけるクラスタ管理部２１は、成功通知を受けて、構成情報２３のクラスタメンバテーブル９０におけるサーバ１５１の状態をオフラインに変更し、サービス管理部２２に対してサーバ１５１上で動作しているサービス１の起動を依頼する。
【０１０９】
一方、サーバ１５１におけるクラスタ管理部１１は、失敗通知を受けて、クォーラムが過半数に満たないことから、自身をパニックさせる。
【０１１０】
また、タイブレーカ部３２は、サーバ１５２の構成情報変更に失敗した場合には（ステップＡ８でＮＯ）、サーバ１５２は動作不能であるとみなす。そして、タイブレーカ部３２は、サーバ１５１でサービス２を引き継がせるため、ステップＡ５において変更したサーバ１５１の構成情報１３を元に戻す（ステップＡ８１）。
【０１１１】
そして、タイブレーカ部３２は、サーバ１５１によるクォーラム確保（ステップＡ４１）後、サーバ１５１に成功通知を発行し、サーバ１５２に失敗通知を発行する（ステップＡ４２）。
【０１１２】
サーバ１５１におけるクラスタ管理部１１は、成功通知を受けて、構成情報１３のクラスタメンバテーブル９０におけるサーバ１５２の状態をオフラインに変更し、サーバ１５２上で動作しているサービス２の起動を試みる。
【０１１３】
一方、サーバ１５２におけるクラスタ管理部２１は、失敗通知を受けて、クォーラムが過半数に満たないことから、自身のパニックを試みる。
【０１１４】
次に、本発明の実施の形態に係るクラスタシステムの他の動作例について説明する。すなわち、クラスタシステム３０１においてすべてのサービス１およびサービス２の両方がサーバ１５１上で起動しており、サーバ１５２上で起動しているサービスが無い状態においてハートビートが途切れた場合の動作について、２つのパターンを以下に説明する。
【０１１５】
［パターン１］
タイブレーカ部３２は、クォーラムサーバ２０１へサーバ１５１から先に確保要求があり、許容時間内にサーバ１５２からも確保要求があった場合には、図４および図５に示すフローチャートに従い、以下のように動作する。
【０１１６】
タイブレーカ部３２は、サーバ１５２に対してハートビート用のＮＩＣを閉塞させる要求を発行する（ステップＡ３）。
【０１１７】
次に、タイブレーカ部３２は、サーバ１５１におけるクラスタ管理部１１に対してサーバ１５１の構成情報１３の変更を依頼する（ステップＡ５）。
【０１１８】
クラスタ管理部１１は、この依頼を受けて、構成情報１３のサービス管理テーブル９１において、サーバ１５２上で動作しているサービスをダミーサービスに変更する。ただし、サーバ１５２上で動作しているサービスは存在しないため、サーバ１５１のサービス管理テーブル９１に変更は発生しない。
【０１１９】
次に、クラスタ管理部１１は、サーバ１５２におけるクラスタ管理部２１に対して構成情報２３の変更を依頼する（ステップＡ７）。
【０１２０】
サーバ１５２におけるクラスタ管理部２１は、この依頼を受けて、自身のサーバ以外で動作中のサービスを構成情報から削除する。サーバ１５２上で動作中のサービスは無いため、サーバ１５２上のサービス管理テーブル９１は空になる。
【０１２１】
次に、タイブレーカ部３２は、サーバ１５１がクォーラムサーバ２０１のクォーラムを確保した（ステップＡ９）後、サーバ１５１およびサーバ１５２の両方に成功通知を発行する。（ステップＡ１０）。
【０１２２】
サーバ１５１におけるクラスタ管理部１１は、成功通知を受けて、構成情報１３のクラスタメンバテーブル９０におけるサーバ１５２の状態をオフラインに変更し、サービス管理部１２に対してサーバ１５２上で動作しているサービスの起動を試みる。ただし、サーバ１５２上で動作しているサービスは無いため、何もサービスは起動されない。
【０１２３】
また、サーバ１５２におけるクラスタ管理部２１は、成功通知を受けて、構成情報２３のクラスタメンバテーブル９０におけるサーバ１５１の状態をオフラインに変更し、サービス管理部２２に対してサーバ１５１上で動作しているサービスの起動を試みる。ただし、ステップＡ７において、サーバ１５１上で動作しているサービスはサービス管理テーブル９１から削除されているため、何のサービスも起動されない。
【０１２４】
図８は、本発明の実施の形態に係るクラスタシステムの状態を示す図である。
【０１２５】
ステップＡ１０までたどり着いた場合には、クラスタシステム３０１は、図８に示すような状態となる。このステップＡ１０までの処理において、動作中のサービス１および２の停止、ならびに再起動が発生しないことから、サーバ１５１上のサービス１およびサーバ１５２上のサービス２は、稼動したままである。このため、各クライアントにおいてサービス提供可能な状態が継続される。
【０１２６】
［パターン２］
タイブレーカ部３２は、クォーラムサーバ２０１にサーバ１５２から先に確保要求があり、許容時間内にサーバ１５１からも確保要求があった場合には、図４および図５に示すフローチャートに従い、以下のように動作する。
【０１２７】
タイブレーカ部３２は、サーバ１５１に対してハートビート用のＮＩＣを閉塞させる要求を発行する（ステップＡ３）。
【０１２８】
次に、タイブレーカ部３２は、サーバ１５２におけるクラスタ管理部２１に対してサーバ１５２の構成情報２３の変更を依頼する（ステップＡ５）。
【０１２９】
クラスタ管理部２１は、この依頼を受けて、構成情報２３のサービス管理テーブル９１において、サーバ１５１上で動作しているサービス１およびサービス２をダミーサービスに変更する。
【０１３０】
次に、タイブレーカ部３２は、サーバ１５１におけるクラスタ管理部１１に対して構成情報１３の変更を依頼する（ステップＡ７）。クラスタ管理部１１は、自身のサーバ以外で動作中のサービスを構成情報１３から削除する。ただし、サーバ１５２上で動作しているサービスは存在しないため、サーバ１５１におけるサービス管理テーブル９１に変更は発生しない。
【０１３１】
次に、タイブレーカ部３２は、サーバ１５２がクォーラムサーバ２０１のクォーラムを確保した（ステップＡ９）後、サーバ１５１およびサーバ１５２の両方に成功通知を発行する。（ステップＡ１０）。
【０１３２】
サーバ１５１におけるクラスタ管理部１１は、成功通知を受けて、構成情報１３のクラスタメンバテーブル９０におけるサーバ１５２の状態をオフラインに変更し、サービス管理部１２に対してサーバ１５２上で動作しているサービスの起動を依頼する。ただし、サーバ１５２上で動作しているサービスは無いため、何もサービスは起動されない。
【０１３３】
また、サーバ１５２におけるクラスタ管理部２１は、成功通知を受けて、構成情報２３のクラスタメンバテーブル９０におけるサーバ１５１の状態をオフラインに変更し、サービス管理部２２に対してサーバ１５１上で動作しているサービスの起動を依頼する。
【０１３４】
ここで、ステップＡ５において構成情報２３におけるサーバ１５１上で動作しているサービス１およびサービス２の情報を変更しているため、実際にはサービス１およびサービス２が起動されず、ダミーサービスが起動される。
【０１３５】
図９は、本発明の実施の形態に係るクラスタシステムの状態を示す図である。
【０１３６】
ステップＡ１０までたどり着いた場合には、クラスタシステム３０１は、図９に示すような状態となる。このステップＡ１０までの処理において、動作中のサービス１および２の停止、ならびに再起動が発生しないことから、サーバ１５１上のサービス１およびサーバ１５２上のサービス２は、稼動したままである。このため、各クライアントにおいてサービス提供可能な状態が継続される。
【０１３７】
ところで、特許文献１および特許文献２に記載の技術では、正常なノードでサービスが動作できる状態でも、優先度またはより信頼性のあるサーバにサービスがフェールオーバーされてしまう可能性があり、無駄にサービスの停止および再起動が発生する可能性がある。
【０１３８】
これに対して、本発明の実施の形態に係るクラスタシステムでは、サーバ１５１，１５２は、他のサーバからハートビート信号を正常に受信できない場合には、クォーラムを確保するための確保要求をクォーラムサーバ２０１へ送信する。そして、クォーラムサーバ２０１は、サーバ１５１，１５２から確保要求を受信してから所定時間内に他のサーバから確保要求を受信したときには、確保要求に対する成功通知をサーバ１５１，１５２へ送信する。
【０１３９】
すなわち、タイブレーカ部３２は、スプリットブレインが発生した際、許容時間内に複数のサーバからのクォーラム確保要求が行なわれた場合には、ハートビート通信路障害と判断する。そして、タイブレーカ部３２は、擬似的に複数のサーバにクォーラム確保成功の通知を行い、スプリットブレイン状態のまま複数のサーバおよび複数のサービスを継続稼動させる。
【０１４０】
このような構成により、クラスタシステムにおけるスプリットブレイン発生時の不要なサービス停止を防止することができる。すなわち、クラスタシステムでサーバ間のハートビート通信が不通となった場合に、サービスについて不必要なフェールオーバーを発生させず、サービスを継続稼動させることができる。
【０１４１】
すなわち、本発明の実施の形態に係るクラスタシステムにおける各構成要素のうち、クォーラムサーバ２０１およびサーバ１５１，１５２からなる最小構成により、クラスタシステムにおいて、スプリットブレインが発生した際の不要なサービス停止を防ぐ、という本発明の目的を達成することが可能となる。
【０１４２】
また、本発明の実施の形態に係るクラスタシステムでは、サーバ１５１，１５２は、他のサーバが提供するサービスの情報を有する。そして、クォーラムサーバ２０１は、確保要求に対する成功通知をサーバ１５１，１５２へ送信する前に、サーバ１５１，１５２が他のサーバのサービスを引き継がないようにサーバ１５１，１５２の上記情報を書き換える。
【０１４３】
すなわち、スプリットブレイン発生時に各サーバからクォーラム確保要求が遅延なく行なわれる場合には、各サーバ上でサービス継続可能と判断する。そして、他サーバ上で動作中のサービスを起動しないように構成情報の変更を行った上で、擬似的に各サーバへクォーラム確保の成功を通知することで、スプリットブレイン状態のまま各サーバを動作させる。
【０１４４】
このように、サーバによるクラスタ再構成の前に、各サーバで互いにクラスタの構成情報の変更を行なうことにより、スプリットブレイン状態でサービスを動作させる際の、リソースの重複およびデータ破壊が発生を防ぐことができる。
【０１４５】
また、本発明の実施の形態に係るクラスタシステムでは、クォーラムサーバ２０１は、先に到着した確保要求を送信したサーバが、クォーラムを真に確保したことを記憶する。
【０１４６】
このように、クォーラムサーバ上のクォーラムロックを、正規のクラスタ情報を保持するサーバに確保させることにより、スプリットブレイン状態で動作させるにあたり、正規のクラスタ情報を保持するサーバを判別することができる。
【０１４７】
また、本発明の実施の形態に係るクラスタシステムでは、クォーラムサーバ２０１は、情報を書き換える際に、クォーラムを真に確保したサーバが有する情報において、他のサーバが提供するサービスをダミーサービスに書き換える。
【０１４８】
このように、スプリットブレイン発生時にクラスタの構成情報を変更する際に、正規のクラスタ情報を保持するサーバ上でダミーサービスが起動するように構成情報を変更することにより、後の運用および事後解析時にログ等でダミーサービス等の稼動状況を認識することができる。
【０１４９】
上記実施の形態は、すべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記説明ではなく特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。
【０１５０】
［付記１］
サービスを１または複数のクライアントに提供し、かつハートビート通信路を介してハートビート信号を互いに送受信するための複数のクラスタサーバと、
クォーラムを有するクォーラムサーバとを備えるクラスタシステムであって、
前記クラスタサーバは、他の前記クラスタサーバから前記ハートビート信号を正常に受信できない場合には、前記クォーラムを確保するための確保要求を前記クォーラムサーバへ送信し、
前記クォーラムサーバは、前記クラスタサーバから前記確保要求を受信してから所定時間内に他の前記クラスタサーバから前記確保要求を受信したときには、前記確保要求に対する成功通知を前記複数のクラスタサーバへ送信する、クラスタシステム。
【０１５１】
［付記２］
前記クラスタサーバは、他の前記クラスタサーバが提供するサービスの情報を有し、
前記クォーラムサーバは、前記確保要求に対する成功通知を前記複数のクラスタサーバへ送信する前に、前記複数のクラスタサーバが他の前記クラスタサーバのサービスを引き継がないように前記複数のクラスタサーバの前記情報を書き換える、付記１に記載のクラスタシステム。
【０１５２】
［付記３］
前記クォーラムサーバは、先に到着した前記確保要求を送信した前記クラスタサーバが、前記クォーラムを真に確保したことを記憶する、付記１または２に記載のクラスタシステム。
【０１５３】
［付記４］
前記クォーラムサーバは、前記情報を書き換える際に、前記クォーラムを真に確保した前記クラスタサーバが有する前記情報において、他の前記クラスタサーバが提供するサービスをダミーサービスに書き換える、付記３に記載のクラスタシステム。
【０１５４】
［付記５］
サービスを１または複数のクライアントに提供し、かつハートビート通信路を介してハートビート信号を互いに送受信するための複数のクラスタサーバと、
クォーラムを有するクォーラムサーバとを備えるクラスタシステムにおけるクラスタ管理方法であって、
前記クラスタサーバが、他の前記クラスタサーバから前記ハートビート信号を正常に受信できない場合には、前記クォーラムを確保するための確保要求を前記クォーラムサーバへ送信するステップと、
前記クォーラムサーバが、前記クラスタサーバから前記確保要求を受信してから所定時間内に他の前記クラスタサーバから前記確保要求を受信したときには、前記確保要求に対する成功通知を前記複数のクラスタサーバへ送信するステップとを含む、クラスタ管理方法。
【０１５５】
［付記６］
前記クラスタサーバは、他の前記クラスタサーバが提供するサービスの情報を有し、
前記クラスタ管理方法は、さらに、
前記クォーラムサーバが、前記確保要求に対する成功通知を前記複数のクラスタサーバへ送信する前に、前記複数のクラスタサーバが他の前記クラスタサーバのサービスを引き継がないように前記複数のクラスタサーバの前記情報を書き換えるステップを含む、付記５に記載のクラスタ管理方法。
【０１５６】
［付記７］
前記クラスタ管理方法は、さらに、
前記クォーラムサーバが、先に到着した前記確保要求を送信した前記クラスタサーバが前記クォーラムを真に確保したことを記憶するステップを含む、付記５または６に記載のクラスタ管理方法。
【０１５７】
［付記８］
前記複数のクラスタサーバの前記情報を書き換えるステップにおいては、前記クォーラムサーバは、前記クォーラムを真に確保した前記クラスタサーバが有する前記情報において、他の前記クラスタサーバが提供するサービスをダミーサービスに書き換える、付記７に記載のクラスタ管理方法。
【０１５８】
［付記９］
サービスを１または複数のクライアントに提供し、かつハートビート通信路を介してハートビート信号を互いに送受信するための複数のクラスタサーバと、
クォーラムを有するクォーラムサーバとを備えるクラスタシステムにおいて用いられるクラスタ管理プログラムであって、コンピュータに、
前記クラスタサーバが、他の前記クラスタサーバから前記ハートビート信号を正常に受信できない場合には、前記クォーラムを確保するための確保要求を前記クォーラムサーバへ送信するステップと、
前記クォーラムサーバが、前記クラスタサーバから前記確保要求を受信してから所定時間内に他の前記クラスタサーバから前記確保要求を受信したときには、前記確保要求に対する成功通知を前記複数のクラスタサーバへ送信するステップとを実行させるための、クラスタ管理プログラム。
【０１５９】
［付記１０］
前記クラスタサーバは、他の前記クラスタサーバが提供するサービスの情報を有し、
前記クラスタ管理プログラムは、さらに、コンピュータに、
前記クォーラムサーバが、前記確保要求に対する成功通知を前記複数のクラスタサーバへ送信する前に、前記複数のクラスタサーバが他の前記クラスタサーバのサービスを引き継がないように前記複数のクラスタサーバの前記情報を書き換えるステップを実行させる、付記９に記載のクラスタ管理プログラム。
【０１６０】
［付記１１］
前記クラスタ管理プログラムは、さらに、コンピュータに、
前記クォーラムサーバが、先に到着した前記確保要求を送信した前記クラスタサーバが前記クォーラムを真に確保したことを記憶するステップを実行させる、付記９または１０に記載のクラスタ管理プログラム。
【０１６１】
［付記１２］
前記複数のクラスタサーバの前記情報を書き換えるステップにおいては、前記クォーラムサーバは、前記クォーラムを真に確保した前記クラスタサーバが有する前記情報において、他の前記クラスタサーバが提供するサービスをダミーサービスに書き換える、付記１１に記載のクラスタ管理プログラム。
【産業上の利用可能性】
【０１６２】
本発明によれば、複数のサーバを構成要素とするクラスタシステムにおいて、ネットワーク障害などにより各サーバ間が分断された場合において、不要なサービス停止を防ぐことができる。したがって、本発明は、産業上の利用可能性を有している。
【符号の説明】
【０１６３】
１１  クラスタ管理部
１２  サービス管理部
１３  、構成情報
２１  クラスタ管理部
２２  サービス管理部
２３  構成情報
４０  共有ストレージ装置
５０  ハートビート通信路
６０  サービス提供用通信路
９０  クラスタメンバテーブル
９１  サービス管理テーブル
１０１  ＣＰＵ
１０２  メインメモリ
１０３  ハードディスク
１０４  入力インタフェース
１０５  表示コントローラ
１０６  データリーダ／ライタ
１０７  通信インタフェース
１２１  バス
１５１，１５２  サーバ（クラスタサーバ）
２０１  クォーラムサーバ
３０１  クラスタシステム
【図１】
2012173996.tif 000003
【図２】
2012173996.tif 000004
【図３】
2012173996.tif 000005
【図４】
2012173996.tif 000006
【図５】
2012173996.tif 000007
【図６】
2012173996.tif 000008
【図７】
2012173996.tif 000009
【図８】
2012173996.tif 000010
【図９】
2012173996.tif 000011