(57)【要約】【課題】簡易な構成でクラスタシステムの可用性低下を防ぐことが可能な情報処理装置、監視方法、および監視プログラムを提供する。【解決手段】情報処理装置２０１は、通常用通信路８２および監視用通信路８１を介して他の情報処理装置２０２と信号の送受信を行なうための送受信部５２，５３と、他の情報処理装置２０２を監視するための監視部５１とを備える。監視部５１は、送受信部５２，５３を制御して、監視用通信路８１を介して他の情報処理装置２０２へ監視用信号を繰り返し送信する。監視部５１は、送受信部５２，５３が他の情報処理装置２０２から監視用信号を正常に受信できない場合には、送受信部５２，５３を制御して、監視用通信路８１の代わりに通常用通信路８２を介して他の情報処理装置２０２へ監視用信号を繰り返し送信する。【選択図】図１
2011203941.tif 000002
【特許請求の範囲】
【請求項１】
通常用通信路および監視用通信路を介して接続される他の情報処理装置とともにクラスタシステムを構成するための情報処理装置であって、
前記通常用通信路および前記監視用通信路を介して前記他の情報処理装置と信号の送受信を行なうための送受信部と、
前記他の情報処理装置を監視するための監視部とを備え、
前記監視部は、前記送受信部を制御して、前記監視用通信路を介して前記他の情報処理装置へ監視用信号を繰り返し送信し、
前記監視部は、前記送受信部が前記他の情報処理装置から前記監視用信号を正常に受信できない場合には、前記送受信部を制御して、前記監視用通信路の代わりに前記通常用通信路を介して前記他の情報処理装置へ前記監視用信号を繰り返し送信する、情報処理装置。
【請求項２】
前記監視部は、前記通常用通信路を介して前記他の情報処理装置へ前記監視用信号を送信している場合において、前記監視用通信路を介した前記他の情報処理装置との通信が正常であるか否かを判断し、正常であると判断したときには、前記送受信部を制御して、前記他の情報処理装置への前記監視用信号の送信経路を前記通常用通信路から前記監視用通信路に切り戻す、請求項１に記載の情報処理装置。
【請求項３】
前記監視部は、前記通常用通信路を介して前記他の情報処理装置へ前記監視用信号を送信している場合であって、前記送受信部が、前記他の情報処理装置から前記監視用信号を正常に受信できないときには、前記クラスタシステムにおける異常を解決するための処理の開始を指示する、請求項１または２に記載の情報処理装置。
【請求項４】
通常用通信路および監視用通信路を介して接続される他の情報処理装置とともにクラスタシステムを構成するための情報処理装置における監視方法であって、
（ａ）前記監視用通信路を介して前記他の情報処理装置へ監視用信号を繰り返し送信するステップと、
（ｂ）前記他の情報処理装置から前記監視用信号を正常に受信できない場合には、前記監視用通信路の代わりに前記通常用通信路を介して前記他の情報処理装置へ前記監視用信号を繰り返し送信するステップとを含む、監視方法。
【請求項５】
通常用通信路および監視用通信路を介して接続される他の情報処理装置とともにクラスタシステムを構成するための情報処理装置における監視プログラムであって、コンピュータに、
（ａ）前記監視用通信路を介して前記他の情報処理装置へ監視用信号を繰り返し送信するステップと、
（ｂ）前記他の情報処理装置から前記監視用信号を正常に受信できない場合には、前記監視用通信路の代わりに前記通常用通信路を介して前記他の情報処理装置へ前記監視用信号を繰り返し送信するステップとを実行させる、監視プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、監視方法、および監視プログラムに関し、特に、クラスタシステムにおける情報処理装置、監視方法、および監視プログラムに関する。
【背景技術】
【０００２】
高可用クラスタシステムとは、複数台のサーバによって構成される冗長化されたシステムである。クラスタシステムでは、一方のサーバが停止した場合に、他方のサーバが業務を引き継ぐことにより、クライアントに対するサービスの継続性を高めている。各サーバは、ＬＡＮ（Local Area Network）等の通信路を介して接続されており、サーバ間でハートビートによる死活監視を互いに行なってサーバの生存状態を確認することにより、クラスタシステムの正常性を保つ。
【０００３】
ハートビート通信とは、フェイルオーバすなわち業務の引き継ぎを互いに行なう関係にある複数のサーバ間で、サーバ機能が停止していないことを示すためのハートビート（監視用信号）をやり取りすることにより、互いのサーバの死活監視を行なう技術である。ハートビート通信が行なわれている間は、相手方サーバが正常に稼働しているものと判断され、フェイルオーバは行なわれない。
【０００４】
逆に、ハートビート通信が途切れた場合には、相手方サーバがシステムダウンしたものと判断され、相手方サーバで提供されていた業務アプリケーションを自機で引き継ぐようになっている。これにより、業務アプリケーションを利用するクライアントサーバからは、クラスタシステム全体が１台のサーバのように見える。したがって、現用系サーバから待機系サーバに処理が切り替わった場合でも、クライアントは、どのサーバから業務アプリケーションサービスが提供されているかを意識することはない。
【０００５】
ここで、自機の稼働状況を何ら考慮せずにフェイルオーバを実行すると、フェイルオーバを実行するサーバ自体が高負荷となり、応答性等が低下する可能性がある。そこで、業務引き継ぎ先サーバの稼働状況に応じて、業務アプリケーションの優先度を変更するようにした技術も知られている。
【０００６】
ところで、クラスタシステムでは、スプリットブレインシンドローム（ネットワークパーティション問題）が存在する。このスプリットブレインシンドロームとは、クラスタシステムにおいて、サーバ障害またはネットワーク障害によりクラスタシステム内のノード群が分断される状態になり、１つのサービス（仮想ＩＰを含む）がクラスタシステム内のノード群で同時に起動してしまい、サービス供給の停止およびデータ破壊が生じる状態のことである。
【０００７】
クラスタシステムの一例として、たとえば、特許文献１（特開２００９−２０５３６４号公報）には、以下のような技術が開示されている。すなわち、監視対象サーバは、その状態を示す状態通知パケットを定期的に監視装置に送信する。管理サーバは、状態通知パケットがこなくなったことを検出すると、状態通知パケットがこなくなった監視対象サーバ以外の他の監視対象サーバからの状態通知パケットが受信できていれば、監視対象サーバのネットワーク構成情報に基づいて、管理サーバから、状態通知パケットがこなくなった監視対象サーバまでの複数の通信ルートを抽出する。そして、該複数の通信ルートを利用して状態通知パケットがこなくなった監視対象サーバの死活状態を確認する。
【０００８】
また、特許文献２（特開２００５−０７３２７７号公報）には、以下のような技術が開示されている。すなわち、クラスタシステムは、少なくとも１つのマルチホーム・ノードと、各ネットワーク・インタフェースのための少なくとも１つのゲートウエイによって構成される。所定の周期的間隔で、ピア・ノードおよびゲートウエイ間に、ハートビート・メッセージが送信される。いずれかのノードまたはゲートウエイによるハートビート・メッセージの損失があった場合、ネットワーク・インタフェースごとにクラスタシステムの各ノードおよびゲートウエイにＩＣＭＰ（インターネット制御メッセージ・プロトコル）エコーが発行される。ＩＣＭＰエコーに応答して、ノード損失もネットワーク損失も確認されない場合、アプリケーション・レベルのｐｉｎｇが発行され、ハートビート・メッセージが存在しないことに関連した障害が、一時的なエラー状況であるかまたはアプリケーション・ソフトウエア障害であるかが判定される。
【０００９】
また、特許文献３（特開２００２−１１６９２０号公報）には、以下のような技術が開示されている。すなわち、運用系装置および待機系装置がネットワークによって接続され、互いの状況を監視するクラスタシステムであって、運用系装置および待機系装置のそれぞれに備えられ、互いの情報のやり取りにより運用系／待機系の判断を行なうクラスタ管理手段と、運用系装置で起動されるサービスプロセス実行手段と、それぞれに備えられたクラスタ管理手段に異常がないか否かを検出する障害検出手段と、障害検出手段によって障害発生を検出したときは上記サービスプロセスの処理を停止させ、待機系装置を稼働させる手段とを含む。
【００１０】
また、特許文献４（特開２００５−１４８９２２号公報）には、以下のような技術が開示されている。すなわち、ユーザが、記憶媒体をノードに装着し、プログラムのインストールを指示すると、インストールプログラムは、フェイルオーバプログラムに対してハートビート通信の停止を要求する。ノードは、システムが正常に稼働している状態で、自発的にハートビート通信を停止させる。ノードのフェイルオーバプログラムは、ハートビート通信停止を検知するとフェイルオーバを開始し、ノードの業務サービスを引き継ぐ。ノードがフェイルオーバ実行中に、記憶媒体に記憶されているプログラムがノードにインストールされる。インストール完了後、ノードは、ノードにフェイルバック要求を送信し、業務サービスを再開する。
【００１１】
また、特許文献５（特開平０９−１０２７９２号公報）には、以下のような技術が開示されている。すなわち、ＬＡＮ間接続装置１２から監視用パケットをＷＡＮ（Wide Area Network）１上に送出し、ＬＡＮ間接続装置２２がこれを返送する。返送された監視用パケットを正常に受信できない場合、ＬＡＮ間接続装置１２はＷＡＮ１に異常が生じていると見なし、接続先をＷＡＮ１からＷＡＮ２に変更する。その後も、ＬＡＮ間接続装置１２から監視用パケットをＷＡＮ１上に送出し、ＬＡＮ間接続装置２２がこれを返送する。返送された監視用パケットを正常に受信できた場合、ＬＡＮ間接続装置１２はＷＡＮ１に異常が生じていないと見なし、接続先をＷＡＮ２からＷＡＮ１に戻す。
【先行技術文献】
【特許文献】
【００１２】
【特許文献１】特開２００９−２０５３６４号公報
【特許文献２】特開２００５−０７３２７７号公報
【特許文献３】特開２００２−１１６９２０号公報
【特許文献４】特開２００５−１４８９２２号公報
【特許文献５】特開平０９−１０２７９２号公報
【発明の概要】
【発明が解決しようとする課題】
【００１３】
特許文献１に記載の技術は、障害が発生すると死活監視のための通信路を切り替えて死活監視を継続する構成であるが、他のサーバを経由した通信路を選択する構成であるため、サーバを余分に用意する必要がある。
【００１４】
また、特許文献２に記載の技術は、ハートビート途絶時、別の通信路を用いて相手サーバと通信を行なう構成であるが、ハートビート途絶時に障害検知場所を特定することを目的としており、ハートビート途絶時にも死活監視を継続することによってシステムの可用性を向上することを目的としていない。
【００１５】
また、クラスタシステムにおけるサーバ間のすべての通信路でハートビート通信を行なう構成では、すべての通信路において常に監視用信号を送受信する必要があるため、システムの可用性が低下してしまう。
【００１６】
その一方で、クラスタシステムにおけるサーバ間の一部の通信路でハートビート通信を行なう構成では、ハートビート通信を行なう通信路がすべて断線しても、ハートビート通信を行なわない通信路は正常であり、すべての通信路が障害状態ではない場合がある。このような場合、正常な通信路が存在するにも関わらずスプリットブレインシンドローム状態となってしまい、システムの可用性が低下してしまう。
【００１７】
しかしながら、特許文献１〜特許文献５には、このような問題点を解決するための構成は開示されていない。
【００１８】
この発明は、上述の課題を解決するためになされたもので、その目的は、簡易な構成でクラスタシステムの可用性低下を防ぐことが可能な情報処理装置、監視方法、および監視プログラムを提供することである。
【課題を解決するための手段】
【００１９】
上記課題を解決するために、この発明のある局面に係わる情報処理装置は、通常用通信路および監視用通信路を介して接続される他の情報処理装置とともにクラスタシステムを構成するための情報処理装置であって、上記通常用通信路および上記監視用通信路を介して上記他の情報処理装置と信号の送受信を行なうための送受信部と、上記他の情報処理装置を監視するための監視部とを備え、上記監視部は、上記送受信部を制御して、上記監視用通信路を介して上記他の情報処理装置へ監視用信号を繰り返し送信し、上記監視部は、上記送受信部が上記他の情報処理装置から上記監視用信号を正常に受信できない場合には、上記送受信部を制御して、上記監視用通信路の代わりに上記通常用通信路を介して上記他の情報処理装置へ上記監視用信号を繰り返し送信する。
【００２０】
上記課題を解決するために、この発明のある局面に係わる監視方法は、通常用通信路および監視用通信路を介して接続される他の情報処理装置とともにクラスタシステムを構成するための情報処理装置における監視方法であって、（ａ）上記監視用通信路を介して上記他の情報処理装置へ監視用信号を繰り返し送信するステップと、（ｂ）上記他の情報処理装置から上記監視用信号を正常に受信できない場合には、上記監視用通信路の代わりに上記通常用通信路を介して上記他の情報処理装置へ上記監視用信号を繰り返し送信するステップとを含む。
【００２１】
上記課題を解決するために、この発明のある局面に係わる監視プログラムは、通常用通信路および監視用通信路を介して接続される他の情報処理装置とともにクラスタシステムを構成するための情報処理装置における監視プログラムであって、コンピュータに、（ａ）上記監視用通信路を介して上記他の情報処理装置へ監視用信号を繰り返し送信するステップと、（ｂ）上記他の情報処理装置から上記監視用信号を正常に受信できない場合には、上記監視用通信路の代わりに上記通常用通信路を介して上記他の情報処理装置へ上記監視用信号を繰り返し送信するステップとを実行させる。
【発明の効果】
【００２２】
本発明によれば、簡易な構成でクラスタシステムの可用性低下を防ぐことができる。
【図面の簡単な説明】
【００２３】
【図１】本発明の第１の実施の形態に係るクラスタシステムの構成を示す図である。
【図２】本発明の第１の実施の形態に係るサーバの概略構成図である。
【図３】本発明の第１の実施の形態に係る情報処理装置が死活監視処理を行なう際の動作手順を示すフローチャートである。
【図４】本発明の第２の実施の形態に係るクラスタシステムの構成を示す図である。
【発明を実施するための形態】
【００２４】
［概要］
本発明の実施の形態では、高可用クラスタシステムにおいて、ハートビートＬＡＮ断線時においても死活監視を継続することができる。これにより、スプリットブレインシンドローム解決処理への移行を回避することでシステムの可用性を高めることができる。
【００２５】
以下、本発明の実施の形態について図面を用いて説明する。なお、図中同一または相当部分には同一符号を付してその説明は繰り返さない。
【００２６】
＜第１の実施の形態＞
［構成および基本動作］
図１は、本発明の第１の実施の形態に係るクラスタシステムの構成を示す図である。
図１を参照して、クラスタシステム３０１は、情報処理装置の一例であるサーバ２０１および２０２を備える。サーバ２０１は、ＮＩＣ（送受信部）５２，５３を備える。サーバ２０２の構成は、たとえばサーバ２０１と同様である。
【００２７】
クラスタシステム３０１は、サーバ２０１およびサーバ２０２を備える２ノードクラスタシステムである。すなわち、サーバ２０１は、ＬＡＮ８２およびハートビートＬＡＮ８１を介して接続される他のサーバ２０２とともにクラスタシステム３０１を構成する。クラスタシステム３０１は、ＮＩＣ（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）の通信機能を有する。なお、記録媒体１１１に格納されたプログラムをサーバ２０１にインストールする形態に代えて、通信インターフェイス１０７を介して配信サーバなどからダウンロードしたプログラムをサーバ２０１にインストールしてもよい。
【００４２】
また、サーバ２０１には、必要に応じてプリンタなどの他の出力装置が接続されてもよい。
【００４３】
［制御構造］
次に、サーバ２０１における死活監視機能を提供するための制御構造について説明する。
【００４４】
図１は、本発明の第１の実施の形態に係るサーバが提供する制御構造も示している。図１に示すサーバ２０１における各ブロックは、ハードディスク１０３に格納されたプログラム（コード）などをメインメモリ１０２に展開して、ＣＰＵ１０１に実行させることで提供される。なお、図１に示すサーバ２０１の制御構造の一部もしくは全部を専用ハードウェアおよび／または配線回路によって実現してもよい。
【００４５】
図１を参照して、ＣＰＵ１０１は、ＮＩＣ５２，５３と、記憶部５４とを備える。また、ＣＰＵ１０１は、その制御構造として、監視部５１と、処理部５５とを含む。記憶部５４は、図２に示すメインメモリ１０２またはハードディスク１０３に相当する。ＮＩＣ５２，５３は、図２に示す通信インターフェイス１０７に相当する。
【００４６】
監視部５１は、死活監視部６３を含む。処理部５５は、スプリットブレインシンドローム解決処理部６４を含む。記憶部５４は、死活監視宛先情報６１と、死活監視用通信路状態情報６２とを記憶する。
【００４７】
ＣＰＵ１０１は、図１に示す各部の他に、多くのユニットによって構成されるのが一般的であるが、説明を簡単にするために、本発明に関係しないユニットについては図示していない。
【００４８】
死活監視部６３は、他のサーバ２０２を監視する。ＮＩＣ５２，５３は、ＬＡＮ８２およびハートビートＬＡＮ８１を介して他のサーバ２０２と信号の送受信を行なう。
【００４９】
［動作］
次に、本発明の第１の実施の形態に係る情報処理装置の動作について図面を用いて説明する。本発明の第１の実施の形態では、サーバ２０１を動作させることによって、本発明の第１の実施の形態に係る監視方法が実施される。よって、本発明の第１の実施の形態に係る監視方法の説明は、以下のサーバ２０１の動作説明に代える。なお、以下の説明においては、適宜図１を参照する。
【００５０】
図３は、本発明の第１の実施の形態に係る情報処理装置が死活監視処理を行なう際の動作手順を示すフローチャートである。
【００５１】
２ノードクラスタシステム３０１が存在し、サーバ２０１およびサーバ２０２が、クラスタシステム３０１において稼働するサーバである。サーバ２０１およびサーバ２０２は、死活監視の対象となるサーバに対して同様の動作を行なうため、ここではサーバ２０１の動作を代表的に説明する。また、クラスタサービスを起動した状態を処理開始状態とする。
【００５２】
図３を参照して、まず、死活監視部６３は、ハートビートＬＡＮ８１を経由したハートビート送信処理を行なう。すなわち、死活監視部６３は、ＮＩＣ５２を制御して、ハートビートＬＡＮ８１を介して他のサーバ２０２へ監視用信号（ハートビート）を繰り返し送信する。より詳細には、死活監視部６３は、監視用信号の宛先ＩＰアドレスを、死活監視宛先情報６１に記載されたネットワーク正常時に対応する宛先ＩＰアドレスとし、ハートビートＬＡＮ８１を死活監視用通信路として監視用信号を送信する（ステップＳ１）。
【００５３】
次に、死活監視部６３は、ハートビートＬＡＮ８１を経由した監視用信号の受信判定を行なう。たとえば、死活監視部６３は、ＮＩＣ５２が他のサーバ２０２から監視用信号を受信してから所定時間以内に次の監視用信号を受信したか否かを判定する。なお、死活監視部６３は、ＮＩＣ５２が他のサーバ２０２へ監視用信号を送信してから所定時間以内に他のサーバ２０２から監視用信号を受信したか否かを判定してもよい。
【００５４】
死活監視部６３は、ハートビートＬＡＮ８１を監視用通信路として死活監視を行なっている状態において、監視用信号を正常に受信した場合には、引き続きハートビートＬＡＮ８１を死活監視用通信路として次の監視用信号を送信する（ステップＳ１）。
【００５５】
一方、死活監視部６３は、監視用信号を正常に受信できなかった場合には、ハートビートＬＡＮ８１からＬＡＮ８２への監視用通信路切り替え処理を行なう。たとえば、死活監視部６３は、ＮＩＣ５２が他のサーバ２０２から監視用信号を受信してから所定時間以上次の監視用信号を受信しない場合には、ＮＩＣ５２，５３を制御して、ハートビートＬＡＮ８１の代わりにＬＡＮ８２を介して他のサーバ２０２へ監視用信号を繰り返し送信する。
【００５６】
より詳細には、ハートビートＬＡＮ８１の断線、およびサーバの高負荷状態等のため、死活監視部６３が監視用信号を正常に受信できなくなった場合には、死活監視部６３は、死活監視用通信路状態情報６２に記載されたネットワーク正常時の死活監視用通信路すなわちハートビートＬＡＮ８１の状態を、正常状態から障害状態に変更する。そして、死活監視部６３は、監視用信号の宛先ＩＰアドレスを死活監視宛先情報６１に記載されたネットワーク障害時に対応する宛先ＩＰアドレスに変更し、ＬＡＮ８２を死活監視用通信路として監視用信号を送信する（ステップＳ３）。
【００５７】
次に、死活監視部６３は、ＬＡＮ８２を経由した監視用信号の受信判定を行なう。たとえば、死活監視部６３は、ＬＡＮ８２を介して他のサーバ２０２へ監視用信号を送信している場合であって、ＮＩＣ５３が、他のサーバ２０２から監視用信号を受信してから所定時間以内に次の監視用信号を受信したか否かを判定する（ステップＳ４）。
【００５８】
死活監視部６３は、ＬＡＮ８２を死活監視用通信路として死活監視を行なっている状態において、監視用信号を正常に受信した場合には（ステップＳ４でＹＥＳ）、ネットワークの状態に応じて死活監視用通信路の切り替え処理を行なう。すなわち、死活監視部６３は、ＬＡＮ８２を介して他のサーバ２０２へ監視用信号を送信している場合において、ハートビートＬＡＮ８１を介した他のサーバ２０２との通信が正常であるか否かを判断し、正常であるときには、ＮＩＣ５２，５３を制御して、他のサーバ２０２への監視用信号の送信経路をＬＡＮ８２からハートビートＬＡＮ８１に切り戻す（ステップＳ５）。
【００５９】
より詳細には、死活監視部６３は、ハートビートＬＡＮ８１の状態が、障害状態から正常状態になった場合には（ステップＳ５でＹＥＳ）、監視用信号の宛先ＩＰアドレスを死活監視宛先情報６１に記載されたネットワーク正常時に対応する宛先ＩＰアドレスに変更し、ハートビートＬＡＮ８１を死活監視用通信路として監視用信号を送信する（ステップＳ１）。
【００６０】
一方、死活監視部６３は、ハートビートＬＡＮ８１の状態が、障害状態のままである場合には（ステップＳ５でＮＯ）、引き続き監視用信号の宛先ＩＰアドレスをネットワーク障害時に対応する宛先ＩＰアドレスとし、ＬＡＮ８２を死活監視用通信路として監視用信号を送信する（ステップＳ３）。
【００６１】
また、死活監視部６３は、ＬＡＮ８２を監視用通信路として死活監視を行なっている状態において、監視用信号を正常に受信できなかった場合には（ステップＳ４でＮＯ）、スプリットブレインシンドローム解決処理に移行する（ステップＳ６）。たとえば、死活監視部６３は、ＬＡＮ８２を介して他のサーバ２０２へ監視用信号を送信している場合であって、ＮＩＣ５３が、他のサーバ２０２から監視用信号を受信してから所定時間以上次の監視用信号を受信しないときには、クラスタシステム３０１における異常を解決するための処理の開始を指示する。
【００６２】
スプリットブレインシンドローム解決処理部６４は、死活監視部６３の指示を受けて、スプリットブレインシンドロームの解決処理を行なう（ステップＳ６）。
【００６３】
ところで、特許文献１に記載の技術は、障害が発生すると死活監視のための通信路を切り替えて死活監視を継続する構成であるが、他のサーバを経由した通信路を選択する構成であるため、サーバを余分に用意する必要がある。
【００６４】
また、特許文献２に記載の技術は、ハートビート途絶時、別の通信路を用いて相手サーバと通信を行なう構成であるが、ハートビート途絶時に障害検知場所を特定することを目的としており、ハートビート途絶時にも死活監視を継続することによってシステムの可用性を向上することを目的としていない。
【００６５】
また、クラスタシステムにおけるサーバ間のすべての通信路でハートビート通信を行なう構成では、すべての通信路において常に監視用信号を送受信する必要があるため、システムの可用性が低下してしまう。
【００６６】
その一方で、クラスタシステムにおけるサーバ間の一部の通信路でハートビート通信を行なう構成では、ハートビート通信を行なう通信路がすべて断線しても、ハートビート通信を行なわない通信路は正常であり、すべての通信路が障害状態ではない場合がある。このような場合、正常な通信路が存在するにも関わらずスプリットブレインシンドローム状態となってしまい、システムの可用性が低下してしまう。
【００６７】
これに対して、本発明の第１の実施の形態では、死活監視部６３は、ＮＩＣ５２を制御して、ハートビートＬＡＮ８１を介して他のサーバ２０２へ監視用信号を繰り返し送信する。そして、死活監視部６３は、ＮＩＣ５２が他のサーバ２０２から監視用信号を正常に受信できない場合には、ＮＩＣ５２，５３を制御して、ハートビートＬＡＮ８１の代わりにＬＡＮ８２を介して他のサーバ２０２へ監視用信号を繰り返し送信する。すなわち、本発明の第１の実施の形態では、監視用通信路においてハートビート通信が途絶えるとクラスタシステムにおけるサーバ間の別の通信路を監視用通信路として選択する。したがって、特許文献１に記載の技術と異なり、サーバを余分に用意する必要がない。また、本発明の第１の実施の形態では、特許文献２に記載の技術と異なり、ハートビート途絶時に障害検知場所を特定することを目的とはしておらず、ハートビート途絶時にも死活監視を継続することによってシステムの可用性を向上することを目的としている。
【００６８】
換言すれば、本発明の第１の実施の形態に係るクラスタシステムは、死活監視のための信号を送受信するように設定された監視用通信路およびそのような設定がされない通常用通信路を有する。そして、監視用通信路においてハートビート通信が途絶えると通常用通信路を監視用通信路として選択する。これにより、監視用通信路がすべて断線しても、通常用通信路が正常であり、全通信路が障害状態ではない場合において、正常な通信路が存在するにも関わらずスプリットブレインシンドローム状態となることを防ぐことができる。したがって、システムの可用性の低下を防ぐことができる。
【００６９】
また、ハートビートＬＡＮとそれ以外の通信路とのすべてにおける死活監視を同時には行なわないことから、死活監視パケットを流すことが本来望ましくない通信路に対して常に死活監視パケットが流れることを防ぐことができる。したがって、システムの可用性の低下を防ぐことができる。
【００７０】
本発明の第１の実施の形態では、少なくとも以下の２つの効果が得られる。すなわち、第１の効果は、ハートビートＬＡＮによる通信障害が発生してもスプリットブレインシンドロームに陥らないことである。すなわち、監視用ではない他の通信路を一時的に利用して死活監視を継続することにより、クライアントに提供するサービスと関係のないハートビートＬＡＮの障害によってクラスタシステム内のサーバ間で死活監視不能となりスプリットブレインシンドロームに陥る状況を回避することができるため、クラスタシステムの可用性を向上させることができる。
【００７１】
また、第２の効果は、ネットワークに流れる死活監視パケットを最小限に抑えられることである。すなわち、クラスタシステムの正常時はハートビートＬＡＮ以外のＬＡＮにおいて死活監視を行なうことはないため、正常時にハートビートＬＡＮ以外の通信路において死活監視パケットを流すことはないことから、クライアントに提供するサービスに対する影響を最低限に抑えることができる。
【００７２】
以上より、本発明の第１の実施の形態に係るサーバ２０１における各構成要素のうち、死活監視部６３およびＮＩＣ５２，５３からなる最小構成により、簡易な構成でクラスタシステムの可用性低下を防ぐという本発明の目的を達成することが可能となる。
【００７３】
また、本発明の第１の実施の形態では、死活監視部６３は、ＬＡＮ８２を介して他のサーバ２０２へ監視用信号を送信している場合において、ハートビートＬＡＮ８１を介した他のサーバ２０２との通信が正常であるか否かを判断し、正常であるときには、ＮＩＣ５２，５３を制御して、他のサーバ２０２への監視用信号の送信経路をＬＡＮ８２からハートビートＬＡＮ８１に切り戻す。すなわち、ハートビートＬＡＮ以外の通常用通信路において死活監視を行なっている状態において、監視用信号受信時に死活監視用通信路状態情報６２を参照してハートビートＬＡＮへの切り替え判定を行なう。そして、ハートビートＬＡＮが復旧していれば通常の死活監視処理に戻る。このような構成により、同時に複数の通信路において死活監視パケットを流すことを防ぎ、ネットワークに流れる死活監視パケットを最小限に抑えることができる。
【００７４】
また、本発明の第１の実施の形態では、死活監視部６３は、ＬＡＮ８２を介して他のサーバ２０２へ監視用信号を送信している場合であって、ＮＩＣ５３が他のサーバ２０２から監視用信号を正常に受信できないときには、クラスタシステム３０１における異常を解決するための処理の開始を指示する。このような構成により、システムの可用性をさらに高めることができる。
【００７５】
次に、本発明の他の実施の形態について図面を用いて説明する。なお、図中同一または相当部分には同一符号を付してその説明は繰り返さない。
【００７６】
＜第２の実施の形態＞
本実施の形態は、第１の実施の形態に係るクラスタシステムと比べてサーバを追加したクラスタシステムに関する。以下で説明する内容以外は第１の実施の形態に係るクラスタシステムと同様である。
【００７７】
図４は、本発明の第２の実施の形態に係るクラスタシステムの構成を示す図である。  図４を参照して、クラスタシステム３０２は、本発明の第１の実施の形態に係るクラスタシステムと比べて、さらに、サーバ２０３を備える。
【００７８】
クラスタシステム３０２は、サーバ２０１，２０２，２０３を備える３ノードクラスタシステムである。サーバ２０１，２０２，２０３がクラスタシステムにおいて稼働するサーバであり、ハートビートＬＡＮ８１およびＬＡＮ８２によって各サーバ間の通信を行なう。
【００７９】
次に、本発明の第２の実施の形態に係る情報処理装置の動作について図面を用いて説明する。本発明の第２の実施の形態では、サーバ２０１を動作させることによって、本発明の第２の実施の形態に係る監視方法が実施される。よって、本発明の第２の実施の形態に係る監視方法の説明は、以下のサーバ２０１の動作説明に代える。なお、以下の説明においては、適宜図４を参照する。
【００８０】
図３に示すフローチャートは、本発明の第２の実施の形態に係る情報処理装置が死活監視処理を行なう際の動作手順も示している。
【００８１】
再び図３を参照して、まず、死活監視部６３は、ハートビートＬＡＮ８１を経由したハートビート送信処理を行なう。すなわち、死活監視部６３は、ＮＩＣ５２を制御して、ハートビートＬＡＮ８１を介して他のサーバ２０２，２０３へ監視用信号（ハートビート）を繰り返し送信する。より詳細には、死活監視部６３は、監視用信号の宛先ＩＰアドレスを、死活監視宛先情報６１に記載されたネットワーク正常時に対応する宛先ＩＰアドレスとし、ハートビートＬＡＮ８１を死活監視用通信路として監視用信号を送信する（ステップＳ１）。
【００８２】
次に、死活監視部６３は、ハートビートＬＡＮ８１を経由した監視用信号の受信判定を行なう。たとえば、死活監視部６３は、ＮＩＣ５２が他のサーバ２０２，２０３から監視用信号を受信してから所定時間以内に次の監視用信号を受信したか否かを判定する。なお、死活監視部６３は、ＮＩＣ５２が他のサーバ２０２，２０３へ監視用信号を送信してから所定時間以内に他のサーバ２０２，２０３から監視用信号を受信したか否かを判定してもよい。
【００８３】
死活監視部６３は、ハートビートＬＡＮ８１を監視用通信路として死活監視を行なっている状態において、他のサーバ２０２，２０３の両方から監視用信号を正常に受信した場合には、引き続きハートビートＬＡＮ８１を死活監視用通信路として次の監視用信号を送信する（ステップＳ１）。
【００８４】
一方、死活監視部６３は、他のサーバ２０２，２０３の少なくともいずれかから監視用信号を正常に受信できなかった場合には、ハートビートＬＡＮ８１からＬＡＮ８２への監視用通信路切り替え処理を行なう。たとえば、死活監視部６３は、ＮＩＣ５２が他のサーバ２０２，２０３からの監視用信号を受信してから、他のサーバ２０２，２０３の少なくともいずれかから所定時間以上次の監視用信号を受信しない場合には、ＮＩＣ５２，５３を制御して、ハートビートＬＡＮ８１の代わりにＬＡＮ８２を介して他のサーバ２０２，２０３へ監視用信号を繰り返し送信する。
【００８５】
より詳細には、ハートビートＬＡＮ８１の断線、およびサーバの高負荷状態等のため、死活監視部６３が監視用信号を正常に受信できなくなった場合には、死活監視部６３は、死活監視用通信路状態情報６２に記載されたネットワーク正常時の死活監視用通信路すなわちハートビートＬＡＮ８１の状態を、正常状態から障害状態に変更する。そして、死活監視部６３は、監視用信号の宛先ＩＰアドレスを死活監視宛先情報６１に記載されたネットワーク障害時に対応する宛先ＩＰアドレスに変更し、ＬＡＮ８２を死活監視用通信路として監視用信号を送信する（ステップＳ３）。
【００８６】
次に、死活監視部６３は、ＬＡＮ８２を経由した監視用信号の受信判定を行なう。たとえば、死活監視部６３は、ＬＡＮ８２を介して他のサーバ２０２，２０３へ監視用信号を送信している場合であって、ＮＩＣ５３が、他のサーバ２０２，２０３から監視用信号を受信してから所定時間以内に次の監視用信号を受信したか否かを判定する（ステップＳ４）。
【００８７】
死活監視部６３は、ＬＡＮ８２を死活監視用通信路として死活監視を行なっている状態において、他のサーバ２０２，２０３の両方から監視用信号を正常に受信した場合には（ステップＳ４でＹＥＳ）、ネットワークの状態に応じて死活監視用通信路の切り替え処理を行なう。すなわち、死活監視部６３は、ＬＡＮ８２を介して他のサーバ２０２，２０３へ監視用信号を送信している場合において、ハートビートＬＡＮ８１を介した他のサーバ２０２，２０３との通信が正常であるか否かを判断し、正常であるときには、ＮＩＣ５２，５３を制御して、他のサーバ２０２，２０３への監視用信号の送信経路をＬＡＮ８２からハートビートＬＡＮ８１に切り戻す（ステップＳ５）。
【００８８】
より詳細には、死活監視部６３は、ハートビートＬＡＮ８１の状態が、障害状態から正常状態になった場合には（ステップＳ５でＹＥＳ）、監視用信号の宛先ＩＰアドレスを死活監視宛先情報６１に記載されたネットワーク正常時に対応する宛先ＩＰアドレスに変更し、ハートビートＬＡＮ８１を死活監視用通信路として監視用信号を送信する（ステップＳ１）。
【００８９】
一方、死活監視部６３は、ハートビートＬＡＮ８１の状態が、障害状態のままである場合には（ステップＳ５でＮＯ）、引き続き監視用信号の宛先ＩＰアドレスをネットワーク障害時に対応する宛先ＩＰアドレスとし、ＬＡＮ８２を死活監視用通信路として監視用信号を送信する（ステップＳ３）。
【００９０】
また、死活監視部６３は、ＬＡＮ８２を監視用通信路として死活監視を行なっている状態において、他のサーバ２０２，２０３の少なくともいずれかから監視用信号を正常に受信できなかった場合には（ステップＳ４でＮＯ）、スプリットブレインシンドローム解決処理に移行する（ステップＳ６）。たとえば、死活監視部６３は、ＬＡＮ８２を介して他のサーバ２０２，２０３へ監視用信号を送信している場合であって、ＮＩＣ５３が、他のサーバ２０２，２０３からの監視用信号を受信してから、他のサーバ２０２，２０３の少なくともいずれかから所定時間以上次の監視用信号を受信しないときには、クラスタシステム３０１における異常を解決するための処理の開始を指示する。
【００９１】
スプリットブレインシンドローム解決処理部６４は、死活監視部６３の指示を受けて、スプリットブレインシンドロームの解決処理を行なう（ステップＳ６）。
【００９２】
その他の構成および動作は第１の実施の形態に係るクラスタシステムと同様であるため、ここでは詳細な説明を繰り返さない。
【００９３】
したがって、本発明は、２ノード以上のサーバを備えたクラスタシステムに対して適用可能である。
【００９４】
上記実施の形態は、すべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記説明ではなく特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。
【００９５】
［付記１］
通常用通信路および監視用通信路を介して接続される他の情報処理装置とともにクラスタシステムを構成するための情報処理装置における監視方法であって、
（ａ）前記監視用通信路を介して前記他の情報処理装置へ監視用信号を繰り返し送信するステップと、
（ｂ）前記他の情報処理装置から前記監視用信号を正常に受信できない場合には、前記監視用通信路の代わりに前記通常用通信路を介して前記他の情報処理装置へ前記監視用信号を繰り返し送信するステップとを含む、監視方法。
【００９６】
［付記２］
前記監視方法は、さらに、
前記通常用通信路を介して前記他の情報処理装置へ前記監視用信号を送信している場合において、前記監視用通信路を介した前記他の情報処理装置との通信が正常であるか否かを判断し、正常であると判断したときには、前記他の情報処理装置への前記監視用信号の送信経路を前記通常用通信路から前記監視用通信路に切り戻すステップを含む、付記１に記載の監視方法。
【００９７】
［付記３］
前記監視方法は、さらに、
前記通常用通信路を介して前記他の情報処理装置へ前記監視用信号を送信している場合であって、前記送受信部が、前記他の情報処理装置から前記監視用信号を正常に受信できないときには、前記クラスタシステムにおける異常を解決するための処理の開始を指示するステップを含む、付記１または２に記載の監視方法。
【００９８】
［付記４］
通常用通信路および監視用通信路を介して接続される他の情報処理装置とともにクラスタシステムを構成するための情報処理装置における監視プログラムであって、コンピュータに、
（ａ）前記監視用通信路を介して前記他の情報処理装置へ監視用信号を繰り返し送信するステップと、
（ｂ）前記他の情報処理装置から前記監視用信号を正常に受信できない場合には、前記監視用通信路の代わりに前記通常用通信路を介して前記他の情報処理装置へ前記監視用信号を繰り返し送信するステップとを実行させる、監視プログラム。
【００９９】
［付記５］
前記監視プログラムは、さらに、コンピュータに、
前記通常用通信路を介して前記他の情報処理装置へ前記監視用信号を送信している場合において、前記監視用通信路を介した前記他の情報処理装置との通信が正常であるか否かを判断し、正常であると判断したときには、前記他の情報処理装置への前記監視用信号の送信経路を前記通常用通信路から前記監視用通信路に切り戻すステップを実行させる、付記４に記載の監視プログラム。
【０１００】
［付記６］
前記監視プログラムは、さらに、コンピュータに、
前記通常用通信路を介して前記他の情報処理装置へ前記監視用信号を送信している場合であって、前記送受信部が、前記他の情報処理装置から前記監視用信号を正常に受信できないときには、前記クラスタシステムにおける異常を解決するための処理の開始を指示するステップを実行させる、付記４または５に記載の監視プログラム。
【産業上の利用可能性】
【０１０１】
本発明によれば、簡易な構成でクラスタシステムの可用性低下を防ぐことができる。したがって、本発明は、産業上の利用可能性を有している。
【符号の説明】
【０１０２】
５１  監視部
５２，５３  ＮＩＣ（送受信部）
５４  記憶部
５５  処理部
６１  死活監視宛先情報
６２  死活監視用通信路状態情報
６３  死活監視部
６４  スプリットブレインシンドローム解決処理部
８１  ハートビートＬＡＮ
８２  ＬＡＮ
１０１  ＣＰＵ
１０２  メインメモリ
１０３  ハードディスク
１０４  入力インターフェイス
１０５  表示コントローラ
１０６  データリーダ／ライタ
１０７  通信インターフェイス
１２１  バス
２０１，２０２，２０３  サーバ
３０１  クラスタシステム
【図１】
2011203941.tif 000003
【図２】
2011203941.tif 000004
【図３】
2011203941.tif 000005
【図４】
2011203941.tif 000006