"サービスを1または複数のクライアントに提供し、かつハートビート通信路を介してハートビート信号を互いに送受信するための複数のクラスタサーバと、クォーラムを有するクォーラムサーバとを備えるクラスタシステムであって、前記クラスタサーバは、他の前記クラスタサーバから前記ハートビート信号を正常に受信できない場合には、前記クォーラムを確保するための確保要求を前記クォーラムサーバへ送信し、前記クォーラムサーバは、前記クラスタサーバから前記確保要求を受信してから所定時間内に他の前記クラスタサーバから前記確保要求を受信したときには、前記確保要求に対する成功通知を前記複数のクラスタサーバへ送信する、クラスタシステム。前記クラスタサーバは、他の前記クラスタサーバが提供するサービスの情報を有し、前記クォーラムサーバは、前記確保要求に対する成功通知を前記複数のクラスタサーバへ送信する前に、前記複数のクラスタサーバが他の前記クラスタサーバのサービスを引き継がないように前記複数のクラスタサーバの前記情報を書き換える、請求項1に記載のクラスタシステム。前記クォーラムサーバは、先に到着した前記確保要求を送信した前記クラスタサーバが、前記クォーラムを真に確保したことを記憶する、請求項1または2に記載のクラスタシステム。前記クォーラムサーバは、前記情報を書き換える際に、前記クォーラムを真に確保した前記クラスタサーバが有する前記情報において、他の前記クラスタサーバが提供するサービスをダミーサービスに書き換える、請求項3に記載のクラスタシステム。サービスを1または複数のクライアントに提供し、かつハートビート通信路を介してハートビート信号を互いに送受信するための複数のクラスタサーバと、クォーラムを有するクォーラムサーバとを備えるクラスタシステムにおけるクラスタ管理方法であって、前記クラスタサーバが、他の前記クラスタサーバから前記ハートビート信号を正常に受信できない場合には、前記クォーラムを確保するための確保要求を前記クォーラムサーバへ送信するステップと、前記クォーラムサーバが、前記クラスタサーバから前記確保要求を受信してから所定時間内に他の前記クラスタサーバから前記確保要求を受信したときには、前記確保要求に対する成功通知を前記複数のクラスタサーバへ送信するステップとを含む、クラスタ管理方法。サービスを1または複数のクライアントに提供し、かつハートビート通信路を介してハートビート信号を互いに送受信するための複数のクラスタサーバと、クォーラムを有するクォーラムサーバとを備えるクラスタシステムにおいて用いられるクラスタ管理プログラムであって、コンピュータに、前記クラスタサーバが、他の前記クラスタサーバから前記ハートビート信号を正常に受信できない場合には、前記クォーラムを確保するための確保要求を前記クォーラムサーバへ送信するステップと、前記クォーラムサーバが、前記クラスタサーバから前記確保要求を受信してから所定時間内に他の前記クラスタサーバから前記確保要求を受信したときには、前記確保要求に対する成功通知を前記複数のクラスタサーバへ送信するステップとを実行させるための、クラスタ管理プログラム。クォーラムを過半数確保できなかったサーバ上で動作していたサービスは、クォーラムを過半数確保できたサーバ上で動作するよう再構成される。このため、異なるサーバでサービスの提供を継続させることは可能であるが、この動作により一時的にサービス停止が発生する。また、データベースのように起動前に復旧処理等を行なうことで整合性を確認する必要のあるサービスも多いため、クラスタのサービスを起動させる際は、サービス提供までに少なからず時間およびコストがかかる。クラスタノードすなわちサーバ間のハートビートが途切れる原因としては、サーバ自身またはクラスタ管理コンポーネントがハングまたはスローダウンした場合、およびサーバは問題ないがハートビート用の通信経路に障害が発生した場合の2通り考えられる。前者の場合はやむを得ないが、後者の場合には、サーバは正常に動作できるにも関わらず、無駄にサービスの一時停止が発生してしまう。すなわち、クラスタシステムにおいてスプリットブレインが発生した際に、従来の方法では、クラスタシステムの整合性を保つため、一方のクラスタノードサーバが稼動し、もう一方のクラスタノードサーバが停止するような動作を行なわせる。このため、停止させるサーバ上でサービスの提供が行なわれており、当該サーバが正常に動作できる場合でも、稼動させるサーバ上でサービスを再起動する必要があり、一時的にサービスの停止が発生してしまうという問題点があった。ここで、ハートビート用の通信経路は、信頼性を向上させるため多重化されることも多い。しかしながら、コストおよびサーバ構成の制限などで多重化できない場合、ならびに通信経路の一部が多重化されない場合もあり、通信経路の単一障害によりハートビートが途切れる可能性がある。たとえば、1つの物理NICNetworkInterfaceCardの複数のポートを使わざるを得ない環境、および経路上のネットワーク装置を共有せざるを得ない環境では、通信経路の一部が多重化されない。特許文献1および特許文献2に記載の技術は、いずれもハートビート通信経路障害によるスプリットブレインが発生した場合に、サービスが起動できる正常なサーバを選択し、より正常なノードでサービスを起動させる方法である。これらの方法では、正常なノードでサービスが動作できる状態でも、優先度またはより信頼性のあるサーバにサービスがフェールオーバーされてしまう可能性があり、無駄にサービスの停止および再起動が発生する可能性がある。この発明は、上述の課題を解決するためになされたもので、その目的は、クラスタシステムにおいて、スプリットブレインが発生した際の不要なサービス停止を防ぐことが可能なクラスタシステム、クラスタ管理方法、およびクラスタ管理プログラムを提供することである。上記課題を解決するために、この発明のある局面に係わるクラスタシステムは、サービスを1または複数のクライアントに提供し、かつハートビート通信路を介してハートビート信号を互いに送受信するための複数のクラスタサーバと、クォーラムを有するクォーラムサーバとを備えるクラスタシステムであって、上記クラスタサーバは、他の上記クラスタサーバから上記ハートビート信号を正常に受信できない場合には、上記クォーラムを確保するための確保要求を上記クォーラムサーバへ送信し、上記クォーラムサーバは、上記クラスタサーバから上記確保要求を受信してから所定時間内に他の上記クラスタサーバから上記確保要求を受信したときには、上記確保要求に対する成功通知を上記複数のクラスタサーバへ送信する。上記課題を解決するために、この発明のある局面に係わるクラスタ管理方法は、サービスを1または複数のクライアントに提供し、かつハートビート通信路を介してハートビート信号を互いに送受信するための複数のクラスタサーバと、クォーラムを有するクォーラムサーバとを備えるクラスタシステムにおけるクラスタ管理方法であって、上記クラスタサーバが、他の上記クラスタサーバから上記ハートビート信号を正常に受信できない場合には、上記クォーラムを確保するための確保要求を上記クォーラムサーバへ送信するステップと、上記クォーラムサーバが、上記クラスタサーバから上記確保要求を受信してから所定時間内に他の上記クラスタサーバから上記確保要求を受信したときには、上記確保要求に対する成功通知を上記複数のクラスタサーバへ送信するステップとを含む。上記課題を解決するために、この発明のある局面に係わるクラスタ管理プログラムは、サービスを1または複数のクライアントに提供し、かつハートビート通信路を介してハートビート信号を互いに送受信するための複数のクラスタサーバと、クォーラムを有するクォーラムサーバとを備えるクラスタシステムにおいて用いられるクラスタ管理プログラムであって、コンピュータに、上記クラスタサーバが、他の上記クラスタサーバから上記ハートビート信号を正常に受信できない場合には、上記クォーラムを確保するための確保要求を上記クォーラムサーバへ送信するステップと、上記クォーラムサーバが、上記クラスタサーバから上記確保要求を受信してから所定時間内に他の上記クラスタサーバから上記確保要求を受信したときには、上記確保要求に対する成功通知を上記複数のクラスタサーバへ送信するステップとを実行させるプログラムである。本発明によれば、クラスタシステムにおいて、スプリットブレインが発生した際の不要なサービス停止を防ぐことができる。以下、本発明の実施の形態について図面を用いて説明する。なお、図中同一または相当部分には同一符号を付してその説明は繰り返さない。[構成および基本動作]図1は、本発明の実施の形態に係るクラスタシステムの構成を示す図である。図1を参照して、クラスタシステム301は、情報処理装置の一例であるサーバクラスタサーバ151,152と、情報処理装置の一例であるクォーラムサーバ201と、共有ストレージ装置40と、サービス提供用通信路60とを備える。サーバ151は、クラスタ管理部11と、サービス管理部12と、構成情報13とを含む。サーバ152は、クラスタ管理部21と、サービス管理部22と、構成情報23とを含む。クラスタシステム301は、たとえばサーバ151,152を備える2ノードクラスタシステムである。なお、クラスタシステム301は3つ以上のサーバを備える構成であってもよい。以下、クラスタシステム301においてサービスを提供するサーバ群をクラスタと称する。サーバ151,152の各々は、クラスタを構成するクラスタノードに該当する。サーバ151,152は、サービスをクライアントCT1~CTnnは1以上の整数に提供し、かつハートビート通信路50を介してハートビート信号を互いに送受信する。より詳細には、共有ストレージ装置40は、サーバ151およびサーバ152からアクセス可能である。サーバ151およびサーバ152は、互いの死活確認ハートビート用のハートビート通信路50によって接続されている。サーバ151およびサーバ152は、互いの死活監視を行なうために、ハートビート通信路50を使用してハートビート信号を定期的に送受信しあう。また、サーバ151およびサーバ152は、クライアントCT1~CTnにサービスを提供するためのサービス提供用通信路60に接続されており、この通信路上にクォーラムサーバ201が配置される。本発明の実施の形態に係る情報処理装置であるクォーラムサーバ201およびサーバ151,152は、典型的には、汎用的なアーキテクチャを有するコンピュータを基本構造としており、予めインストールされたプログラムを実行することで、後述するような各種機能を提供する。一般的に、このようなプログラムは、フレキシブルディスクFlexibleDiskおよびCD-ROMCompactDiskReadOnlyMemoryなどの記録媒体に格納されて、あるいはネットワークなどを介して流通する。本発明の実施の形態に係るプログラムは、OS等の他のプログラムの一部に組み込まれて提供されるものであってもよい。この場合でも、本発明の実施の形態に係るプログラム自体は、上記のような組み込み先の他のプログラムが有するモジュールを含んでおらず、当該他のプログラムと協働して処理が実行される。すなわち、本発明の実施の形態に係るプログラムとしては、このような他のプログラムに組み込まれた形態であってもよい。なお、代替的に、プログラムの実行により提供される機能の一部もしくは全部を専用のハードウェア回路として実装してもよい。図2は、本発明の実施の形態に係るクォーラムサーバの概略構成図である。サーバ151,152の構成は、たとえばクォーラムサーバ201と同様である。図2を参照して、クォーラムサーバ201は、演算処理部であるCPUCentralProcessingUnit101と、メインメモリ102と、ハードディスク103と、入力インタフェース104と、表示コントローラ105と、データリーダ/ライタ106と、通信インタフェース107とを備える。これらの各部は、バス121を介して、互いにデータ通信可能に接続される。CPU101は、ハードディスク103に格納されたプログラムコードをメインメモリ102に展開し、これらを所定順序で実行することにより、各種の演算を実施する。メインメモリ102は、典型的には、DRAMDynamicRandomAccessMemoryなどの揮発性の記憶装置であり、ハードディスク103から読み出されたプログラムに加えて、各種の演算処理結果を示すデータなどを保持する。また、ハードディスク103は不揮発性の磁気記憶装置であり、CPU101で実行されるプログラムに加えて、各種設定値などが格納される。このハードディスク103にインストールされるプログラムは、後述するように、記録媒体111に格納された状態で流通する。なお、ハードディスク103に加えて、あるいはハードディスク103に代えて、フラッシュメモリなどの半導体記憶装置を採用してもよい。入力インタフェース104は、CPU101とキーボード108、マウス109および図示しないタッチパネルなどの入力部との間のデータ伝送を仲介する。すなわち、入力インタフェース104は、ユーザが入力部を操作することで与えられる操作指令などの外部からの入力を受付ける。表示コントローラ105は、表示部の典型例であるディスプレイ110と接続され、ディスプレイ110での表示を制御する。すなわち、表示コントローラ105は、CPU101による画像処理の結果などをユーザに対して表示する。ディスプレイ110は、たとえばLCDLiquidCrystalDisplayまたはCRTCathodeRayTubeである。データリーダ/ライタ106は、CPU101と記録媒体111の間のデータ伝送を仲介する。すなわち、記録媒体111は、クォーラムサーバ201で実行されるプログラムなどが格納された状態で流通し、データリーダ/ライタ106は、この記録媒体111からプログラムを読み出す。また、データリーダ/ライタ106は、CPU101の内部指令に応答して、クォーラムサーバ201における処理結果などを記録媒体111へ書き込む。なお、記録媒体111は、たとえば、CFCompactFlashおよびSDSecureDigitalなどの汎用的な半導体記憶デバイス、フレキシブルディスクFlexibleDiskなどの磁気記憶媒体、またはCD-ROMCompactDiskReadOnlyMemoryなどの光学記憶媒体である。通信インタフェース107は、CPU101と他のパーソナルコンピュータおよびサーバ装置などの間のデータ伝送を仲介する。通信インタフェース107は、典型的には、イーサネット登録商標またはUSBUniversalSerialBusの通信機能を有する。なお、記録媒体111に格納されたプログラムをクォーラムサーバ201にインストールする形態に代えて、通信インタフェース107を介して配信サーバなどからダウンロードしたプログラムをクォーラムサーバ201にインストールしてもよい。また、クォーラムサーバ201には、必要に応じてプリンタなどの他の出力装置が接続されてもよい。[制御構造]次に、クォーラムサーバ201における死活監視機能を提供するための制御構造について説明する。図1は、本発明の実施の形態に係る各サーバが提供する制御構造も示している。図1に示すクォーラムサーバ201およびサーバ151,152における各ブロックは、ハードディスク103に格納されたプログラムコードなどをメインメモリ102に展開して、CPU101に実行させることで提供される。なお、図1に示すクォーラムサーバ201およびサーバ151,152の制御構造の一部もしくは全部を専用ハードウェアおよび/または配線回路によって実現してもよい。図1を参照して、クォーラムサーバ201は、その制御構造として、タイブレーカ部32を備える。サーバ151は、その制御構造として、クラスタ管理部11と、サービス管理部12とを備える。サーバ152は、その制御構造として、クラスタ管理部21と、サービス管理部22とを備える。また、クォーラムサーバ201は、クォーラム記憶域31を備える。サーバ151は、クラスタ構成情報13を備える。サーバ152は、クラスタ構成情報23を備える。クォーラムサーバ201において、クォーラム記憶域31は、ロック機能を提供する。また、タイブレーカ部32は、各サーバからのクォーラム確保要求を調停する。タイブレーカ部32は、クラスタシステム301におけるクラスタを構成するサーバ151およびサーバ152からクォーラム確保要求以下、確保要求とも称する。を受信すると、クォーラム記憶域31においてクォーラムロックが取得されていることを他のサーバが認識できるようにマークを行なう。また、タイブレーカ部32は、クォーラムロックが未確保の状態であった場合には、確保要求を送信したサーバにクォーラム確保成功通知以下、成功通知とも称する。を返す。一方、タイブレーカ部32は、他のサーバがクォーラム確保済みでクォーラムが確保できなかった場合には、確保要求を送信したサーバにクォーラム確保失敗通知以下、失敗通知とも称する。を返す。通常、複数のサーバからクォーラムサーバ201にほぼ同時に確保要求が届いた場合には、先に届いた確保要求を送信したサーバがクォーラムを確保し、後から届いた確保要求を送信したサーバはクォーラム確保に失敗する。クォーラムサーバ201では、従来技術のようにあるサーバから確保要求を受け取ってもすぐにクォーラムを確保するのではなく、許容時間内で他のサーバからの確保要求を待ち合わせる。クォーラムサーバ201では、許容時間内に複数のサーバから確保要求があった場合には、各サーバ上でサービスが重複して起動されないように制御を行った上で、先に届いた確保要求を送信したサーバにクォーラムを取得させ、他の各サーバに成功通知を返す。サーバ151,152は、クラスタを管理する機能として、クラスタ管理部11,21と、サービス管理部12,22と、クラスタの各種情報を記録する記憶域であるクラスタ構成情報13,23とをそれぞれ備える。クラスタ管理部11,21は、クラスタの状態を監視し、クラスタ構成情報以下、構成情報とも称する。13,23をそれぞれ管理する。クラスタ管理部11,21は、ハートビート通信路50経由で他サーバにおけるクラスタ管理部21,11とハートビート信号をそれぞれ送受信することにより、死活確認を行なう。また、クラスタ管理部11,21は、構成情報13,23の管理をそれぞれ担い、クラスタ内で起動中のサーバ間で同一の構成情報を保持する。また、クラスタ管理部11,21は、クラスタ内のサーバが起動してメンバとして加わった場合、およびハートビートが途切れた場合にクラスタを再構成する役割を担う。ここで、クラスタの再構成とは、クラスタ内のメンバの状態を変更し、サービスを適切なサーバで再起動することである。また、各サーバのクラスタ管理部11,21は、クォーラムを1つずつ保持する。クォーラムサーバ201上に1つのクォーラムが存在するため、クラスタシステム301では合計3つのクォーラムが存在する。クラスタ管理部11,21は、ハートビート信号が途切れた場合には、クォーラムサーバ201のクォーラムの取得を試みる。クラスタ管理部11,21は、クォーラムサーバ201から成功通知を受けた場合には、システムの過半数2/3以上のクォーラムを確保したことから、自身を正規のクラスタとして再構成する、すなわち、他サーバのサービスを引き継ぐ。一方、クラスタ管理部11,21は、クォーラムサーバ201から失敗通知を受けた場合には、保持するクォーラムが、自身のクォーラム1/3のみであり過半数に満たないことから、自身の動作を停止パニックさせる。また、クラスタ管理部11,21は、サーバ起動時にもクォーラムサーバ201に確保要求を行い、過半数のクォーラムを得る必要がある。クラスタ管理部11,21がクォーラムサーバ201のクォーラム確保に失敗した場合には、クォーラムサーバ201のクォーラムを確保しているサーバの起動を待ち合わせる必要があり、その後に起動が許可される。その際、クォーラムサーバ201のクォーラムを確保しているサーバの構成情報の同期コピーが行なわれる。構成情報13,23の同期がとれると、クラスタ管理部11,21は、クォーラムサーバ201のクォーラムの解放を行なう。サービス管理部12,22は、それぞれ、クラスタ管理部11,21と連携し、構成情報13,23に基づいてサービスの起動、停止および監視を制御する。図3は、本発明の実施の形態に係るクラスタシステムにおいて、構成情報で管理している主な情報を示す図である。図3を参照して、構成情報は、たとえば、クラスタに参加しているサーバおよびその状態を保持するクラスタメンバテーブル90と、サービスの構成要素、サービスの状態、および当該サービスが動作しているサーバを保持するサービス管理テーブル91とを有する。サービスの構成要素は、一般的には、主要要素であるアプリケーション名、そのアプリケーションが使用するディスク領域以下、LUNとも称する。、およびクライアントからの要求を待ち受けるための仮想IPアドレス以下、VIPとも称する。で構成される。アプリケーションがディスクおよびネットワーク機能を必要としない場合には、LUNおよびVIPをサービスの構成要素から外すことも可能である。[動作]次に、本発明の実施の形態に係る情報処理装置の動作について図面を用いて説明する。本発明の実施の形態では、クォーラムサーバ201およびサーバ151,152を動作させることによって、本発明の実施の形態に係るクラスタ管理方法が実施される。よって、本発明の実施の形態に係るクラスタ管理方法の説明は、以下のクォーラムサーバ201およびサーバ151,152の動作説明に代える。なお、以下の説明においては、適宜図1を参照する。図1に示すように、サーバ151上でサービス1が動作し、かつサーバ152上でサービス2が動作している状態で、ハートビート通信路50上のハートビートが途切れると、サーバ151およびサーバ152におけるクラスタ管理部11,21は、ハートビートが断絶したことを検出する。そして、クラスタ管理部11,21は、過半数のクォーラムを確保するために、クォーラムサーバ201に確保要求を発行する。すなわち、サーバ151,152は、他のサーバからハートビート信号を正常に受信できない場合には、クォーラムを確保するための確保要求をクォーラムサーバ201へ送信する。クォーラムサーバ201は、サーバ151,152から確保要求を受信してから所定時間内に他のサーバから確保要求を受信したときには、確保要求に対する成功通知をサーバ151,152へ送信する。また、サーバ151,152は、他のサーバが提供するサービスの情報を含む構成情報を有する。クォーラムサーバ201は、確保要求に対する成功通知をサーバ151,152へ送信する前に、サーバ151,152が他のサーバのサービスを引き継がないようにサーバ151,152の構成情報を書き換える。また、クォーラムサーバ201は、先に到着した確保要求を送信したサーバが、クォーラムを真に確保したことを記憶する。また、クォーラムサーバ201は、構成情報を書き換える際に、クォーラムを真に確保したサーバが有する構成情報において、他のサーバが提供するサービスをダミーサービスに書き換える。より詳細には、クラスタを構成するサーバ151およびサーバ152でそれぞれサービス1およびサービス2が動作している状態において、サーバ151およびサーバ152間のハートビート信号が途切れた場合に、各サーバは、クォーラムサーバ201のクォーラムの確保を試みる。クォーラムサーバ201におけるタイブレーカ部32は、クォーラムサーバ201にサーバ151およびサーバ152から確保要求が許容時間内に届いた場合には、両サーバともサービスの稼動が可能とみなす。そして、タイブレーカ部32は、クラスタの整合性が損なわれないように排他制御を行なわせた上で、サーバ151およびサーバ152へクォーラムが確保できた旨を通知し、両方のサーバ上で動作中のサービスを継続動作させる。具体的には、クォーラムサーバ201におけるタイブレーカ部32は、以下の図4および図5に示すフローチャートに基づいて調停を行なう。なお、ここでは、先にサーバ151からの確保要求がクォーラムサーバ201に届いた場合について説明する。図4および図5は、本発明の実施の形態に係るクォーラムサーバがシステム管理処理を行なう際の動作手順を示すフローチャートである。図4および図5を参照して、タイブレーカ部32は、サーバ151から確保要求が届くとステップA1、許容時間内でサーバ152からの確保要求を待ち合わせるステップA2。次に、タイブレーカ部32は、許容時間内にサーバ152から確保要求を受けると、サーバ152に対してハートビート用のNICを閉塞させる依頼を行なうステップA3。タイブレーカ部32は、たとえば、リモートシェルを用いてハートビート用のNICをソフトウェア的にオフラインにする。これにより、ハートビートの通信路障害が間欠障害であった場合等に、図4および図5に示すフローチャートの処理が実行されている間に再度ハートビートが再開され、整合性に矛盾をきたすことを防ぐことができる。次に、タイブレーカ部32は、サーバ152におけるハートビート用NICを閉塞した後、サーバ151におけるクラスタ管理部11に対してサーバ151の構成情報13の変更を依頼する。この依頼の内容は、サービス管理テーブル91において、サーバ152上で動作しているサービス2をダミーサービス、すなわちLUNおよびVIPを構成せず、定期的に単純に簡単な計算を行なうアプリケーションのみの構成に差し替えるものであるステップA5。次に、依頼を受けたサーバ151におけるクラスタ管理部11は、構成情報13のサービス管理テーブル91を変更するステップA6。図6は、本発明の実施の形態に係るクラスタシステムにおける各サーバのサービス管理テーブルの変更例を示す図である。図6を参照して、サーバ151におけるサービス管理テーブル91において、サーバ152上で動作しているサービス2がダミーサービスに変更され、サービス管理テーブル91aのようになる。このようにサービス管理テーブル91を変更することにより、後述するステップA10までたどり着いた場合において、サーバ152において動作中のサービス2が使用するLUNおよびVIP等のリソースと競合が発生することを防ぐことができる。なお、ダミーサービスを起動させるように変更することにより、ステップA10以降のシステム運用、または事後解析時にダミーサービス等の稼動状況を認識できるようになる。次に、タイブレーカ部32は、サーバ151の構成情報13の変更後、サーバ152に対して構成情報23の変更を依頼するステップA7。この依頼の内容は、サービス管理テーブル91において、自身のサーバ以外で動作中のサービスの情報を削除するものである。次に、依頼を受けたサーバ152におけるクラスタ管理部21は、自身の構成情報23のサービス管理テーブル91を変更する。図6を参照して、サーバ152におけるサービス管理テーブル91において、サーバ152以外で動作中のサービス1が削除され、サービス管理テーブル91bのようになる。このようにサービス管理テーブル91を変更することにより、後述するステップA10までたどり着いた場合において、サーバ151において動作中のサービス1が使用するLUNおよびVIP等のリソースと競合が発生することを防ぐことができる。また、ステップA10までたどり着いた場合には、サーバ152に対して、擬似的に自身が生き残るべきクラスタであると認識させて動作を継続させるが、それ以降、サーバ152の構成情報は正式な情報として利用されない。このため、サーバ152に対して自身以外のサービスの情報を削除させる。次に、サーバ152の構成情報23の変更後、サーバ151は、クォーラムサーバ201のクォーラムを確保ロックするステップA9。次に、タイブレーカ部32は、サーバ151およびサーバ152の両方に対して成功通知を発行する。ステップA10。次に、サーバ151におけるクラスタ管理部11は、成功通知を受けて、構成情報13のクラスタメンバテーブル90におけるサーバ152の状態をオフラインに変更し、サービス管理部12に対してサーバ152上で動作しているサービスの起動を指示する。ここで、サーバ151では、ステップA5において構成情報13を変更していることから、実際にはサービス2ではなくダミーサービスが起動する。また、サーバ152におけるクラスタ管理部21は、成功通知を受けて、構成情報23のクラスタメンバテーブル90におけるサーバ151の状態をオフラインに変更し、サービス管理部22に対してサーバ151上で動作しているサービスの起動を指示する。ここで、ステップA7においてサービス管理テーブル91におけるサーバ151上で動作しているサービスの情報は削除されていることから、実際には何も起動されない。図7は、本発明の実施の形態に係るクラスタシステムの状態を示す図である。ステップA10までたどり着いた場合には、クラスタシステム301は、図7に示すような状態となる。このステップA10までの処理において、動作中のサービス1および2の停止、ならびに再起動が発生しないことから、サーバ151上のサービス1およびサーバ152上のサービス2は稼動したままである。このため、各クライアントにおいてサービス提供可能な状態が継続される。ステップA10の処理が実行された後、クォーラムサーバ201におけるタイブレーカ部32は、サーバ152におけるクラスタ管理部21の死活監視を行なう。タイブレーカ部32は、サーバ152がサーバ停止等を行った場合には、サーバ152の応答が無くなることを検知し、サーバ151におけるクラスタ管理部11に対してダミーサービスを一旦オフラインにさせる。そして、タイブレーカ部32は、クラスタ管理部11に対して、ステップA5で変更する前のサービス管理テーブル91に差し替えさせる、すなわちダミーサービスをサービス2に変更させた上で、サーバ151においてサービス2を起動させる。なお、ステップA10を実行した後で、サーバの停止および起動等によりクラスタの再構成が必要となった場合には、正規のクラスタ構成情報として、先に確保要求を送信したサーバ151の構成情報13が採用される。この場合、ステップA9において、クォーラムサーバ201のクォーラム記憶域31はサーバ151がロックしており、サーバ151は過半数のクォーラムを得ることができるため、サーバ151は単独で再起動が可能である。一方、サーバ152は、過半数のクォーラムを確保できないため単独での再起動できない。また、サーバ152の再起動時にはサーバ151が起動している必要があり、再起動の際、サーバ152の構成情報23は、サーバ151の持つ正式な構成情報13と同期一致がとられる。この同期がとられて初めて、サーバ152をクラスタとして起動することができる。両方のサーバで構成情報の整合がとられると、クォーラムサーバ201上のクォーラム記憶域31から、サーバ151が確保しているクォーラムロックが削除される。次に、図4および図5に示すフローチャートにおいて、処理が正常に行なわれなかった場合の処理について説明する。タイブレーカ部32は、ステップA10まで辿りつかない場合には、ハートビート通信路50の障害ではなく、サーバ151,152のいずれかがハングおよびスローダウン等、動作不能な状態になったと判断し、適切なサーバでサービスを引き継ぐように、以下の動作を行なう。タイブレーカ部32は、許容時間内にサーバ152からの確保要求が届かない場合にはステップA2でNO、サーバ152は動作不能であるとみなす。そして、タイブレーカ部32は、サーバ151によるクォーラム確保ステップA21後、サーバ151に成功通知を発行するステップA22。サーバ151におけるクラスタ管理部11は、成功通知を受けて、構成情報13のクラスタメンバテーブル90におけるサーバ152の状態をオフラインに変更し、サーバ152上で動作しているサービス2の起動を試みる。また、タイブレーカ部32は、サーバ152におけるハートビート用NICの閉塞に失敗した場合にはステップA4でNO、サーバ152は動作不能であるとみなす。そして、タイブレーカ部32は、サーバ151によるクォーラム確保ステップA41後、サーバ151に成功通知を発行し、サーバ152に失敗通知を発行するステップA42。サーバ151におけるクラスタ管理部11は、成功通知を受けて、構成情報13のクラスタメンバテーブル90におけるサーバ152の状態をオフラインに変更し、サーバ152上で動作しているサービス2の起動を試みる。一方、サーバ152におけるクラスタ管理部21は、失敗通知を受けて、クォーラムが過半数に満たないことから、自身の動作停止パニックを試みる。また、タイブレーカ部32は、サーバ151の構成情報変更に失敗した場合にはステップA6でNO、サーバ151は動作不能であるとみなす。そして、タイブレーカ部32は、サーバ152にサービス1を引き継がせるため、ステップA3において閉塞させたサーバ152におけるハートビート用のNIC閉塞を解除するステップA61。そして、タイブレーカ部32は、サーバ152によるクォーラム確保ステップA62後、サーバ152にクォーラム確保成功の通知を発行し、サーバ151に確保失敗の通知を発行するステップA63。サーバ152におけるクラスタ管理部21は、成功通知を受けて、構成情報23のクラスタメンバテーブル90におけるサーバ151の状態をオフラインに変更し、サービス管理部22に対してサーバ151上で動作しているサービス1の起動を依頼する。一方、サーバ151におけるクラスタ管理部11は、失敗通知を受けて、クォーラムが過半数に満たないことから、自身をパニックさせる。また、タイブレーカ部32は、サーバ152の構成情報変更に失敗した場合にはステップA8でNO、サーバ152は動作不能であるとみなす。そして、タイブレーカ部32は、サーバ151でサービス2を引き継がせるため、ステップA5において変更したサーバ151の構成情報13を元に戻すステップA81。そして、タイブレーカ部32は、サーバ151によるクォーラム確保ステップA41後、サーバ151に成功通知を発行し、サーバ152に失敗通知を発行するステップA42。サーバ151におけるクラスタ管理部11は、成功通知を受けて、構成情報13のクラスタメンバテーブル90におけるサーバ152の状態をオフラインに変更し、サーバ152上で動作しているサービス2の起動を試みる。一方、サーバ152におけるクラスタ管理部21は、失敗通知を受けて、クォーラムが過半数に満たないことから、自身のパニックを試みる。次に、本発明の実施の形態に係るクラスタシステムの他の動作例について説明する。すなわち、クラスタシステム301においてすべてのサービス1およびサービス2の両方がサーバ151上で起動しており、サーバ152上で起動しているサービスが無い状態においてハートビートが途切れた場合の動作について、2つのパターンを以下に説明する。[パターン1]タイブレーカ部32は、クォーラムサーバ201へサーバ151から先に確保要求があり、許容時間内にサーバ152からも確保要求があった場合には、図4および図5に示すフローチャートに従い、以下のように動作する。タイブレーカ部32は、サーバ152に対してハートビート用のNICを閉塞させる要求を発行するステップA3。次に、タイブレーカ部32は、サーバ151におけるクラスタ管理部11に対してサーバ151の構成情報13の変更を依頼するステップA5。クラスタ管理部11は、この依頼を受けて、構成情報13のサービス管理テーブル91において、サーバ152上で動作しているサービスをダミーサービスに変更する。ただし、サーバ152上で動作しているサービスは存在しないため、サーバ151のサービス管理テーブル91に変更は発生しない。次に、クラスタ管理部11は、サーバ152におけるクラスタ管理部21に対して構成情報23の変更を依頼するステップA7。サーバ152におけるクラスタ管理部21は、この依頼を受けて、自身のサーバ以外で動作中のサービスを構成情報から削除する。サーバ152上で動作中のサービスは無いため、サーバ152上のサービス管理テーブル91は空になる。次に、タイブレーカ部32は、サーバ151がクォーラムサーバ201のクォーラムを確保したステップA9後、サーバ151およびサーバ152の両方に成功通知を発行する。ステップA10。サーバ151におけるクラスタ管理部11は、成功通知を受けて、構成情報13のクラスタメンバテーブル90におけるサーバ152の状態をオフラインに変更し、サービス管理部12に対してサーバ152上で動作しているサービスの起動を試みる。ただし、サーバ152上で動作しているサービスは無いため、何もサービスは起動されない。また、サーバ152におけるクラスタ管理部21は、成功通知を受けて、構成情報23のクラスタメンバテーブル90におけるサーバ151の状態をオフラインに変更し、サービス管理部22に対してサーバ151上で動作しているサービスの起動を試みる。ただし、ステップA7において、サーバ151上で動作しているサービスはサービス管理テーブル91から削除されているため、何のサービスも起動されない。図8は、本発明の実施の形態に係るクラスタシステムの状態を示す図である。ステップA10までたどり着いた場合には、クラスタシステム301は、図8に示すような状態となる。このステップA10までの処理において、動作中のサービス1および2の停止、ならびに再起動が発生しないことから、サーバ151上のサービス1およびサーバ152上のサービス2は、稼動したままである。このため、各クライアントにおいてサービス提供可能な状態が継続される。[パターン2]タイブレーカ部32は、クォーラムサーバ201にサーバ152から先に確保要求があり、許容時間内にサーバ151からも確保要求があった場合には、図4および図5に示すフローチャートに従い、以下のように動作する。タイブレーカ部32は、サーバ151に対してハートビート用のNICを閉塞させる要求を発行するステップA3。次に、タイブレーカ部32は、サーバ152におけるクラスタ管理部21に対してサーバ152の構成情報23の変更を依頼するステップA5。クラスタ管理部21は、この依頼を受けて、構成情報23のサービス管理テーブル91において、サーバ151上で動作しているサービス1およびサービス2をダミーサービスに変更する。次に、タイブレーカ部32は、サーバ151におけるクラスタ管理部11に対して構成情報13の変更を依頼するステップA7。クラスタ管理部11は、自身のサーバ以外で動作中のサービスを構成情報13から削除する。ただし、サーバ152上で動作しているサービスは存在しないため、サーバ151におけるサービス管理テーブル91に変更は発生しない。次に、タイブレーカ部32は、サーバ152がクォーラムサーバ201のクォーラムを確保したステップA9後、サーバ151およびサーバ152の両方に成功通知を発行する。ステップA10。サーバ151におけるクラスタ管理部11は、成功通知を受けて、構成情報13のクラスタメンバテーブル90におけるサーバ152の状態をオフラインに変更し、サービス管理部12に対してサーバ152上で動作しているサービスの起動を依頼する。ただし、サーバ152上で動作しているサービスは無いため、何もサービスは起動されない。また、サーバ152におけるクラスタ管理部21は、成功通知を受けて、構成情報23のクラスタメンバテーブル90におけるサーバ151の状態をオフラインに変更し、サービス管理部22に対してサーバ151上で動作しているサービスの起動を依頼する。ここで、ステップA5において構成情報23におけるサーバ151上で動作しているサービス1およびサービス2の情報を変更しているため、実際にはサービス1およびサービス2が起動されず、ダミーサービスが起動される。図9は、本発明の実施の形態に係るクラスタシステムの状態を示す図である。ステップA10までたどり着いた場合には、クラスタシステム301は、図9に示すような状態となる。このステップA10までの処理において、動作中のサービス1および2の停止、ならびに再起動が発生しないことから、サーバ151上のサービス1およびサーバ152上のサービス2は、稼動したままである。このため、各クライアントにおいてサービス提供可能な状態が継続される。ところで、特許文献1および特許文献2に記載の技術では、正常なノードでサービスが動作できる状態でも、優先度またはより信頼性のあるサーバにサービスがフェールオーバーされてしまう可能性があり、無駄にサービスの停止および再起動が発生する可能性がある。これに対して、本発明の実施の形態に係るクラスタシステムでは、サーバ151,152は、他のサーバからハートビート信号を正常に受信できない場合には、クォーラムを確保するための確保要求をクォーラムサーバ201へ送信する。そして、クォーラムサーバ201は、サーバ151,152から確保要求を受信してから所定時間内に他のサーバから確保要求を受信したときには、確保要求に対する成功通知をサーバ151,152へ送信する。すなわち、タイブレーカ部32は、スプリットブレインが発生した際、許容時間内に複数のサーバからのクォーラム確保要求が行なわれた場合には、ハートビート通信路障害と判断する。そして、タイブレーカ部32は、擬似的に複数のサーバにクォーラム確保成功の通知を行い、スプリットブレイン状態のまま複数のサーバおよび複数のサービスを継続稼動させる。このような構成により、クラスタシステムにおけるスプリットブレイン発生時の不要なサービス停止を防止することができる。すなわち、クラスタシステムでサーバ間のハートビート通信が不通となった場合に、サービスについて不必要なフェールオーバーを発生させず、サービスを継続稼動させることができる。すなわち、本発明の実施の形態に係るクラスタシステムにおける各構成要素のうち、クォーラムサーバ201およびサーバ151,152からなる最小構成により、クラスタシステムにおいて、スプリットブレインが発生した際の不要なサービス停止を防ぐ、という本発明の目的を達成することが可能となる。また、本発明の実施の形態に係るクラスタシステムでは、サーバ151,152は、他のサーバが提供するサービスの情報を有する。そして、クォーラムサーバ201は、確保要求に対する成功通知をサーバ151,152へ送信する前に、サーバ151,152が他のサーバのサービスを引き継がないようにサーバ151,152の上記情報を書き換える。すなわち、スプリットブレイン発生時に各サーバからクォーラム確保要求が遅延なく行なわれる場合には、各サーバ上でサービス継続可能と判断する。そして、他サーバ上で動作中のサービスを起動しないように構成情報の変更を行った上で、擬似的に各サーバへクォーラム確保の成功を通知することで、スプリットブレイン状態のまま各サーバを動作させる。このように、サーバによるクラスタ再構成の前に、各サーバで互いにクラスタの構成情報の変更を行なうことにより、スプリットブレイン状態でサービスを動作させる際の、リソースの重複およびデータ破壊が発生を防ぐことができる。また、本発明の実施の形態に係るクラスタシステムでは、クォーラムサーバ201は、先に到着した確保要求を送信したサーバが、クォーラムを真に確保したことを記憶する。このように、クォーラムサーバ上のクォーラムロックを、正規のクラスタ情報を保持するサーバに確保させることにより、スプリットブレイン状態で動作させるにあたり、正規のクラスタ情報を保持するサーバを判別することができる。また、本発明の実施の形態に係るクラスタシステムでは、クォーラムサーバ201は、情報を書き換える際に、クォーラムを真に確保したサーバが有する情報において、他のサーバが提供するサービスをダミーサービスに書き換える。このように、スプリットブレイン発生時にクラスタの構成情報を変更する際に、正規のクラスタ情報を保持するサーバ上でダミーサービスが起動するように構成情報を変更することにより、後の運用および事後解析時にログ等でダミーサービス等の稼動状況を認識することができる。上記実施の形態は、すべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記説明ではなく特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。[付記1]サービスを1または複数のクライアントに提供し、かつハートビート通信路を介してハートビート信号を互いに送受信するための複数のクラスタサーバと、クォーラムを有するクォーラムサーバとを備えるクラスタシステムであって、前記クラスタサーバは、他の前記クラスタサーバから前記ハートビート信号を正常に受信できない場合には、前記クォーラムを確保するための確保要求を前記クォーラムサーバへ送信し、前記クォーラムサーバは、前記クラスタサーバから前記確保要求を受信してから所定時間内に他の前記クラスタサーバから前記確保要求を受信したときには、前記確保要求に対する成功通知を前記複数のクラスタサーバへ送信する、クラスタシステム。[付記2]前記クラスタサーバは、他の前記クラスタサーバが提供するサービスの情報を有し、前記クォーラムサーバは、前記確保要求に対する成功通知を前記複数のクラスタサーバへ送信する前に、前記複数のクラスタサーバが他の前記クラスタサーバのサービスを引き継がないように前記複数のクラスタサーバの前記情報を書き換える、付記1に記載のクラスタシステム。[付記3]前記クォーラムサーバは、先に到着した前記確保要求を送信した前記クラスタサーバが、前記クォーラムを真に確保したことを記憶する、付記1または2に記載のクラスタシステム。[付記4]前記クォーラムサーバは、前記情報を書き換える際に、前記クォーラムを真に確保した前記クラスタサーバが有する前記情報において、他の前記クラスタサーバが提供するサービスをダミーサービスに書き換える、付記3に記載のクラスタシステム。[付記5]サービスを1または複数のクライアントに提供し、かつハートビート通信路を介してハートビート信号を互いに送受信するための複数のクラスタサーバと、クォーラムを有するクォーラムサーバとを備えるクラスタシステムにおけるクラスタ管理方法であって、前記クラスタサーバが、他の前記クラスタサーバから前記ハートビート信号を正常に受信できない場合には、前記クォーラムを確保するための確保要求を前記クォーラムサーバへ送信するステップと、前記クォーラムサーバが、前記クラスタサーバから前記確保要求を受信してから所定時間内に他の前記クラスタサーバから前記確保要求を受信したときには、前記確保要求に対する成功通知を前記複数のクラスタサーバへ送信するステップとを含む、クラスタ管理方法。[付記6]前記クラスタサーバは、他の前記クラスタサーバが提供するサービスの情報を有し、前記クラスタ管理方法は、さらに、前記クォーラムサーバが、前記確保要求に対する成功通知を前記複数のクラスタサーバへ送信する前に、前記複数のクラスタサーバが他の前記クラスタサーバのサービスを引き継がないように前記複数のクラスタサーバの前記情報を書き換えるステップを含む、付記5に記載のクラスタ管理方法。[付記7]前記クラスタ管理方法は、さらに、前記クォーラムサーバが、先に到着した前記確保要求を送信した前記クラスタサーバが前記クォーラムを真に確保したことを記憶するステップを含む、付記5または6に記載のクラスタ管理方法。[付記8]前記複数のクラスタサーバの前記情報を書き換えるステップにおいては、前記クォーラムサーバは、前記クォーラムを真に確保した前記クラスタサーバが有する前記情報において、他の前記クラスタサーバが提供するサービスをダミーサービスに書き換える、付記7に記載のクラスタ管理方法。[付記9]サービスを1または複数のクライアントに提供し、かつハートビート通信路を介してハートビート信号を互いに送受信するための複数のクラスタサーバと、クォーラムを有するクォーラムサーバとを備えるクラスタシステムにおいて用いられるクラスタ管理プログラムであって、コンピュータに、前記クラスタサーバが、他の前記クラスタサーバから前記ハートビート信号を正常に受信できない場合には、前記クォーラムを確保するための確保要求を前記クォーラムサーバへ送信するステップと、前記クォーラムサーバが、前記クラスタサーバから前記確保要求を受信してから所定時間内に他の前記クラスタサーバから前記確保要求を受信したときには、前記確保要求に対する成功通知を前記複数のクラスタサーバへ送信するステップとを実行させるための、クラスタ管理プログラム。[付記10]前記クラスタサーバは、他の前記クラスタサーバが提供するサービスの情報を有し、前記クラスタ管理プログラムは、さらに、コンピュータに、前記クォーラムサーバが、前記確保要求に対する成功通知を前記複数のクラスタサーバへ送信する前に、前記複数のクラスタサーバが他の前記クラスタサーバのサービスを引き継がないように前記複数のクラスタサーバの前記情報を書き換えるステップを実行させる、付記9に記載のクラスタ管理プログラム。[付記11]前記クラスタ管理プログラムは、さらに、コンピュータに、前記クォーラムサーバが、先に到着した前記確保要求を送信した前記クラスタサーバが前記クォーラムを真に確保したことを記憶するステップを実行させる、付記9または10に記載のクラスタ管理プログラム。[付記12]前記複数のクラスタサーバの前記情報を書き換えるステップにおいては、前記クォーラムサーバは、前記クォーラムを真に確保した前記クラスタサーバが有する前記情報において、他の前記クラスタサーバが提供するサービスをダミーサービスに書き換える、付記11に記載のクラスタ管理プログラム。"