JP2008172592A - クラスタシステム、コンピュータおよびその異常検出方法 - Google Patents

Abstract

【課題】コンピュータの異常検出に伴うクラスタシステムのサービス中断時間を短縮する。
【解決手段】コンピュータ異常監視部５１は、相手方コンピュータから送信される生存パケットを常時監視し、相手方コンピュータの異常を検出する。通信監視部５２は、通信機器３０から返信される応答パケットを常時受信し、所定時間当たりの応答パケットの受信数をカウントする。運転モード管理部５３は、コンピュータ異常監視部５１が相手方コンピュータの異常を検出すると、直ちに、通信監視部５２から所定時間当たりの応答パケットの受信数を取得し、その受信数が所定の閾値以上のときには、相手方コンピュータに実際に異常があると判定し、さらに、そのときの自らの運転モードが待機状態であったときには、その運転モードを実行状態に更新し、サービスアプリケーション１４を起動する。
【選択図】図１

Description

本発明は、クラスタシステム、ならびに、そのクラスタシステムに用いられるコンピュータおよびその異常検出方法に関する。

一般に、クラスタシステムとは、複数のコンピュータにより所定のサービスを提供するように構成されたシステムをいう。クラスタシステムにおいては、１つのコンピュータに動作不能などの異常が発生しても、他のコンピュータによってそのサービスを継続して提供することができる。

一般に、クラスタシステムを構成するそれぞれのコンピュータは、他のコンピュータに対して、自らが動作している証として、いわゆる、ハートビートメッセージを、所定の時間間隔で繰り返しネットワークに送信する。そこで、他のコンピュータによりハートビートメッセージが受信されなくなった場合には、そのハートビートメッセージの送信元のコンピュータは、異常な状態になり、動作していないと判定される。

しかしながら、コンピュータがハートビートメッセージを受信しなくなる状況は、他にもある。コンピュータは、自らに接続されたネットワークに障害があった場合にも、ハートビートメッセージを受信することができない。すなわち、あるコンピュータがハートビートメッセージを受信しなくなったときには、その原因は、ハートビートメッセージ送信元のコンピュータに実際に異常が発生した場合と、ネットワークに障害が生じた場合と、の２つの場合があることになる。従って、ハートビートメッセージだけに頼ったコンピュータの異常判定では、これら２つの場合を区別することができない。

すなわち、ハートビートメッセージを送受信することにより、その送受信の相手方コンピュータの異常を検出するときには、相手方コンピュータが正常であっても、通信障害のために相手方コンピュータが異常と判定される場合がある。その場合において、異常を検出したコンピュータが相手側コンピュータの機能をバックアップするために待機していたコンピュータであったようなときには、異常を検出したコンピュータは、相手方コンピュータが実行しているサービスを、相手方コンピュータに代わって実行しようとする。そうすると、同じサービスが２つのコンピュータによって重複または競合して実行されることになり、それはそれで、また、別の異常を生じることになる。

そこで、このような異常を回避するために、例えば、特許文献１に開示されたクラスタシステムでは、そのクラスタシステムを構成する複数のコンピュータ間で排他制御してアクセスされる共有ディスクが設けられている。そして、そのクラスタシステムのそれぞれのコンピュータは、ハートビートメッセージの送受信により、相手方コンピュータの異常を検出したときには、さらに、その共有ディスクの占有権を獲得するためのコマンドを発し、その占有権を獲得することができたときのみ、所定のサービスを実行するとしている。従って、共有ディスクの占有権を獲得したコンピュータだけが、所定のサービスを実行するので、所定のサービスが重複または競合して実行されることはない。

また、特許文献２に開示されたクラスタシステムにおいては、相互のコンピュータをつなぐネットワークにさらにゲートウエイが接続されている。そして、そのクラスタシステムのそれぞれのコンピュータは、ハートビートメッセージの送受信により、相手方コンピュータの異常を検出したときには、さらに、ゲートウエイに対してＩＣＭＰ（Internet Control Message Protocol）のエコーメッセージを送信し、そのエコーが戻ってくるか否かにより、相手方コンピュータに実際に生じた異常か、または、ネットワークの通信障害か、を判定するとしている。

以上、特許文献１や特許文献２に開示されたクラスタシステムによれば、そのクラスタシステムを構成するそれぞれのコンピュータは、ハートビートメッセージを送受信する相手方コンピュータに実際に生じた異常と、ネットワークの通信障害とを区別して判定することができる。
特許３５７３０９２号公報 特開２００５−７３２７７号公報

しかしながら、特許文献１や特許文献２に開示されたクラスタシステムにおいては、ハートビートメッセージが受信されなくなったことにより相手方コンピュータの異常を検出した後、他の手段により、相手方コンピュータに実際に生じた異常か、または、ネットワークの通信障害であるか、を判別する処理を実行している。従って、相手方コンピュータに実際に異常が生じた場合には、その異常を検出するのに要する時間は、ハートビートメッセージによる異常検出時間に、さらに、ネットワークの通信障害であるか否かを判別するための処理時間が加算されることになる。

従って、特許文献１や特許文献２に開示されたクラスタシステムの異常検出方法によれば、異常検出に要する時間が長くなってしまう。これは、相手方コンピュータに実際に異常があった場合には、そのコンピュータが実行していたサービスを他のコンピュータが実行するように切り替えるときには、その切り替える処理のために生じるサービスの中断時間が長くなることを意味する。

以上の従来技術の問題点に鑑み、本発明の目的は、クラスタシステムを構成するコンピュータに実際に発生した異常を検出する時間を短縮するとともに、それに伴うサービスの中断時間を短縮することにある。

以上の従来技術の問題点を解決するために、本発明では、クラスタシステムを、所定のサービスアプリケーションを実行している稼働コンピュータと、その稼働コンピュータにネットワークを介して接続され、所定のサービスアプリケーションを実行可能な状態で待機しているスペアコンピュータと、を含むように構成した。

そして、稼働コンピュータおよびスペアコンピュータのそれぞれは、動作開始後、ネットワークを介して接続された相手方コンピュータに対し、自らが動作していることを示す生存パケットを所定の時間間隔で繰り返し送信するとともに、相手方コンピュータから送信される生存パケットの受信を監視し、所定時間内に所定数に達する生存パケットを受信しなかったとき、それを相手方コンピュータの異常として検出するコンピュータ異常監視部と、動作開始後、ネットワーク上の通信機器に対して所定の時間間隔で繰り返し通信監視パケットを送信するとともに、その応答として通信機器から送信される応答パケットを受信して、その応答パケットの所定時間当たりの受信数をカウントする通信監視部と、を備えるようにした。

そして、稼働コンピュータおよびスペアコンピュータのそれぞれは、コンピュータ異常監視手段により相手方コンピュータの異常を検出したときには、通信監視手段から所定時間当たりの応答パケットの受信数を取得し、その受信数に基づき、前記検出した相手方コンピュータの異常が、相手方コンピュータに実際に生じた異常であるのか、または、ネットワークの通信障害により生じた見かけの異常であるのか、を区別して判定するようにした。

以上、本発明によれば、コンピュータ異常監視手段により相手方コンピュータの異常を検出したとき、別途カウントしている通信機器からの応答パケットの受信数に基づき、その異常が相手方コンピュータに実際に生じた異常であるのか、または、ネットワークの通信障害により生じた見かけの異常であるのかを、直ちに区別して判定することが可能である。従って、従来技術に比べ、相手方コンピュータに実際に生じた異常を検出する時間を大幅に短縮することができる。

本発明によれば、クラスタシステムを構成するコンピュータに実際に生じた異常を検出する時間を短縮することができ、さらに、それに伴うサービス中断時間を短縮することができる。

以下、本発明の実施形態について、図面を参照して詳細に説明する。

＜第１の実施形態＞
図１は、本発明の第１の実施形態に係るクラスタシステムの構成の例を示した図である。図１において、クラスタシステム１は、コンピュータ１０として２台のコンピュータ１０−１，１０−２を含み、いわゆるホットスペアと呼ばれる高信頼コンピュータシステムを構成している。すなわち、コンピュータ１０−１は、稼働コンピュータであり、通常状態では、クライアントに対し所定のサービスを提供している。また、コンピュータ１０−２は、スペアコンピュータであり、通常状態では、クライアントに対するサービスは提供していないが、コンピュータ１０−１の異常を監視し、コンピュータ１０−１に動作不能などの異常が発生したことを検出した場合には、コンピュータ１０−１が提供していたサービスを肩代わりしてクライアントに提供する。

ここで、２台のコンピュータ１０−１，１０−２は、それぞれがネットワーク２０に接続され、ネットワーク２０を介して相互に情報通信を行う。このとき、ネットワーク２０の形態は、例えば、ＩＰ（Internet Protocol）ネットワークであるが、必ずしもそれに限定されることはなく、相互の情報通信が可能なネットワークであれば、どのようなネットワークであってもよい。

また、ネットワーク２０には、コンピュータ１０−１，１０−２から独立して動作する通信機器３０が接続される。なお、ここでいう通信機器３０は、ＩＰアドレスを有し、コンピュータ１０−１，１０−２から送信される診断用パケットに対して、応答パケットを送信できる機器であればよい。従って、ネットワーク２０への接続機能を有するパーソナルコンピュータは、通信機器３０になり得る。また、図示を省略しているが、ネットワーク２０は、クラスタシステム１の外部に伸び、クライアントのコンピュータ（以下、単に「クライアント」という）に接続されている。

クラスタシステム１を構成するコンピュータ１０は、それを構成するハードウエアとして、図示しないＣＰＵ（Central Processing Unit）と記憶装置とを少なくとも含む。ここで、記憶装置は、ＲＡＭ（Random Access Memory）などのいわゆるメモリと、補助記憶としてのハードディスク装置などによって構成される。そして、その記憶装置には、ＣＰＵが実行すべきプログラムが記憶されるほか、そのプログラムを実行するに際し必要な情報がテーブルやファイルなどの形で記憶される。

また、図１に示すように、コンピュータ１０は、その機能ブロックとして、ネットワークドライバ１１、オペレーティングシステム１２、クラスタ管理システム１３、サービスアプリケーション１４などを含む。これらの機能ブロック１１，１２，１３，１４の機能は、前記ＣＰＵが記憶装置に記憶されている所定のプログラムを実行することによって実現される。ただし、ネットワークドライバ１１は、ＣＰＵが所定のプログラムを実行して実現される機能のほかに、通信専用の制御回路やインタフェース回路によって実現される機能を含む。

コンピュータ１０においては、オペレーティングシステム１２の管理の下に、ネットワークドライバ１１とクラスタ管理システム１３とが動作し、さらに、クラスタ管理システム１３の管理の下に、サービスアプリケーション１４が動作する。なお、図１の例においては、コンピュータ１０−１は稼働コンピュータであり、そのサービスアプリケーション１４は実行されている実行状態にある。また、他方のコンピュータ１０−２はスペアコンピュータであり、そのサービスアプリケーション１４は実行されていないが、いつでも実行可能な待機状態にある。

また、コンピュータ１０においては、クラスタ管理システム１３が動作し、そのクラスタ管理システム１３によって相手方コンピュータ１０の異常を監視するとともに、サービスアプリケーション１４の動作モード（運転モード）を管理・制御する。これらの機能を実現するために、クラスタ管理システム１３は、コンピュータ異常監視部５１、通信監視部５２および運転モード管理部５３を備える。

ここで、コンピュータ異常監視部５１は、ネットワーク２０を介して、相手方コンピュータ１０から送信されるハートビートメッセージ（以下、本明細書では「生存パケット」という）の受信状況を監視することによって、相手方コンピュータ１０の異常を検出する。また、通信監視部５２は、ネットワーク２０を介して通信機器３０に対し応答を要求する診断用パケット（以下、本明細書では「通信監視パケット」という）を送信し、その応答を監視することによって、ネットワーク２０における通信障害を監視する。また、運転モード管理部５３は、コンピュータ異常監視部５１から相手方コンピュータ１０の異常を検出した旨の検出通知を受けたとき、通信監視部５２におけるネットワーク２０の通信障害の監視状況を参照して、その検出された相手方コンピュータ１０の異常が、相手方コンピュータ１０に実際に生じた異常であるのか、または、ネットワーク２０の通信障害により生じた見かけの異常であるのか、を区別して判定する。

続いて、図１を参照して、クラスタ管理システム１３を構成するコンピュータ異常監視部５１、通信監視部５２および運転モード管理部５３の動作について詳しく説明する。

コンピュータ異常監視部５１は、自らのコンピュータの動作開始後、ネットワーク２０を介して相手方コンピュータ１０へ、生存パケットを所定の時間間隔で繰り返して送信するとともに、相手方コンピュータ１０から同様に送信される生存パケットの受信状況を監視する。そして、所定時間内に所定数に達する生存パケットを受信しなかった場合には、相手方コンピュータ１０の異常を検出したと判断して、その旨を運転モード管理部５３へ通知する（本明細書では、この通知を、「検出通知」と呼ぶ）。ただし、コンピュータ異常監視部５１によるこの判断は、必ずしも、相手方コンピュータ１０に実際に異常が生じていることを意味するものではない。

なお、相手方コンピュータ１０に実際に生じる異常とは、その相手方コンピュータ１０が生存パケットを送信できない状態にあることをいい、このときには、少なくともサービスアプリケーション１４を実行することができない状態にあり、クライアント側からはそのコンピュータは停止しているように見える。

通信監視部５２は、コンピュータ異常監視部５１の動作と並行して、自らのコンピュータの動作開始後、常時、ネットワーク２０を介して通信機器３０へ、通信監視パケットを所定の時間間隔で繰り返して送信するとともに、それに応答して通信機器３０から送信される応答パケットの受信状況を監視する。すなわち、通信監視部５２は、通信機器３０から送信された応答パケットの所定時間当たりの受信数をカウントし、運転モード管理部５３からの要求に応じて、そのカウント数を運転モード管理部５３へ報告する。

運転モード管理部５３は、コンピュータ異常監視部５１から相手方コンピュータ１０の異常を検出した旨の検出通知を受けた場合には、通信監視部５２における応答パケットの所定時間当たりの受信数に基づき、そのカウント数が所定数以上であったときには、相手方コンピュータ１０に実際に異常が生じていると判定し、そのカウント数が所定数に達していなかったときには、ネットワーク２０に通信障害が発生していると判定する。

すなわち、運転モード管理部５３が前記検出通知を受けた時点で、通信監視部５２が通信機器３０から所定時間当たり所定数以上の応答パケットを受信していたときには、ネットワーク２０に通信障害がないことを意味しているので、運転モード管理部５３は、コンピュータ異常監視部５１によって検出された相手方コンピュータ１０の異常が相手方コンピュータ１０に実際に生じた異常によるものであると判定する。一方、運転モード管理部５３が前記検出通知を受けた時点で、通信監視部５２が通信機器３０から所定時間当たり所定数以上の応答パケットを受信していなかったときには、ネットワーク２０に通信障害があることを意味しているので、運転モード管理部５３は、コンピュータ異常監視部５１によって検出された相手方コンピュータ１０の異常がその通信障害によって発生した見かけの異常であると判定する。

以上のようにして、運転モード管理部５３は、相手方コンピュータ１０に実際に生じた異常とネットワーク２０の通信障害とを区別して検出することができる。

次に、運転モード管理部５３は、相手方コンピュータ１０に実際に生じた異常を検出した場合には、自身のコンピュータ１０のサービスアプリケーション１４の運転モードをチェックし、その運転モードが停止または待機状態であったときには、その運転モードを実行状態に遷移させる。すなわち、運転モード管理部５３は、サービスアプリケーション１４の実行を起動し、相手方コンピュータ１０に代わって自身のコンピュータ１０がサービスアプリケーション１４を実行する。

なお、以上の説明において、コンピュータ異常監視部５１は、所定時間内に所定数に達する生存パケットを受信しなかったとき、相手方コンピュータ１０の異常と判定し、また、運転モード管理部５３は、通信監視部５２が所定時間内に所定数に達する応答パケットを受信しなかったとき、通信障害と判定している。すなわち、コンピュータ異常監視部５１にしても、運転モード管理部５３にしても、受信すべき生存パケットまたは応答パケットをすべて受信したときのみを正常であると判定するのではなく、受信したパケット数が所定の閾値以上の場合には、相手方コンピュータ１０またはネットワーク２０には障害がないと判定している。

このようにある閾値を用いて障害の有無を判定するようにしたのは、ネットワーク２０などでしばしば発生する通信の間欠障害の影響を回避できるようにしたからである。ここで、通信の間欠障害とは、電磁的なノイズなどにより一時的に通信が不能になる障害をいう。すなわち、通信の間欠障害の場合には、通信は一時的に不能になるが、すぐに回復する。しかしながら、通信の間欠障害が発生すると、生存パケットであれ応答パケットであれ、その送受信に失敗することが多い。従って、その分、所定時間内の生存パケットまたは応答パケットの受信数は減少する。そこで、コンピュータ異常監視部５１または運転モード管理部５３は、あらかじめ所定の閾値を設定し、生存パケットまたは応答パケットの減少数がその閾値に達しなかった場合には、通信の間欠障害が発生したものと判定する。つまり、その場合には、ネットワーク２０には通信障害が発生していないと判断する。

続いて、図２〜図１０を用いて、以上に説明したクラスタ管理システム１３の動作を実現する処理フローについて詳細に説明する。

まず、図２〜図５を用い、コンピュータ異常監視部５１が実行する処理の内容について説明する。コンピュータ異常監視部５１が実行する処理には、生存パケット送信処理、パケット受信処理およびコンピュータ異常検出処理が含まれる。

なお、これらの処理フローの動作は、コンピュータ１０に含まれるＣＰＵ（図１に図示せず）によって実行される。従って、その動作の主語はＣＰＵとすべきであるが、本明細書では、慣用に従い、その動作の主語を、当該処理の実行によって実現される機能ブロックによって表記する。ちなみに、以下の図２〜図５の説明においては、コンピュータ異常監視部５１が動作の主語となる。なお、後記する図６〜図１０の説明においても、その主語を同様に表記する。

図２は、コンピュータ異常監視部５１における生存パケット送信処理の処理フローの例を示した図である。生存パケット送信処理は、自らのコンピュータ１０が動作していることを示す生存パケットを相手方コンピュータ１０に送信する処理である。従って、生存パケットは、いわゆるハートビートメッセージに相当する。この生存パケット送信処理は、電源投入などによりコンピュータ１０が初期化されたときに起動される。

図２に示すように、コンピュータ異常監視部５１は、まず、自身のコンピュータ１０が有する初期化情報設定ファイルから、生存パケットの送信先となる相手方コンピュータ１０のＩＰアドレスを読み込み（ステップＳ０１）、さらに、その初期化情報設定ファイルから送信間隔時間を読み込む（ステップＳ０２）。ここで、送信間隔時間は、生存パケットを送信する所定の時間間隔である。

ここで、初期化情報設定ファイルは、クラスタシステム１の構造または特性を決定するようなデータを記憶するファイルであり、そのデータは、所定の取り決めなどに従って、例えば、システム構築時にシステム設計者などによって設定される。初期化情報設定ファイルは、生存パケット送信処理だけでなく、後記する他の処理においても参照する。

次に、コンピュータ異常監視部５１は、ステップＳ０１で読み込んだＩＰアドレスを有するコンピュータに向けて、生存パケットを送信する（ステップＳ０３）。その後、ステップＳ０２で読み込んだ送信間隔時間が経過するのを待ち（ステップＳ０４）、その時間が経過すると、再び、生存パケットを送信する（ステップＳ０３）。このようにして、コンピュータ異常監視部５１は、コンピュータ１０が動作している限り、所定の時間間隔で繰り返して生存パケットを送信し続ける。

図３は、コンピュータ異常監視部５１における生存パケット管理テーブルの構成の例を示した図である。図３に示すように、生存パケット管理テーブルは、クラスタ番号、ポート番号、パケットカウンタのデータなどを記憶する。

ここで、クラスタ番号は、クラスタシステム１において、相互に動作の異常を監視し合うコンピュータ１０の組（以下、クラスタという）を識別する番号である。なお、図１の例では、クラスタシステム１を構成するコンピュータ１０は２つしかないので、クラスタシステム１を構成するコンピュータ１０の組（クラスタ）は１つしかない。

ポート番号は、ネットワーク２０に対する受信ポートの識別番号であり、パケットカウンタは、このポート番号に対応付けられて管理される。通常、この受信ポートは、動作の異常を監視し合う相手方コンピュータ１０に対応するように設けられる。なお、図３には、ポート番号が２つある例が示されているが、図１の構成のクラスタシステム１においては、動作の異常を監視し合う相手方コンピュータ１０が１つしかないので、ポート番号も１つだけでよい。

パケットカウンタは、ポート番号に対応して設けられ、そのポート番号を有する受信ポートによって受信される生存パケットの受信数をカウントする。なお、パケットカウンタのカウント処理は、次に示すパケット受信処理によって行われる。

図４は、コンピュータ異常監視部５１におけるパケット受信処理の処理フローの例を示した図である。ここで、パケット受信処理は、相手方コンピュータ１０から送信されるパケットを受信する処理である。このパケット受信処理は、電源投入などによりコンピュータ１０が初期化されたときに起動される。なお、パケット受信処理の受信対象のパケットは、相手方コンピュータ１０から送信される生存パケットおよび起動パケット（後記する運転モード管理処理によって送信されるパケット）である。

図４に示すように、コンピュータ異常監視部５１は、まず、初期化情報設定ファイルから、当該コンピュータ１０が属するクラスタのクラスタ番号を読み込み（ステップＳ１１）、さらに、生存パケットを送信する相手方コンピュータ１０に対応して設けられた受信ポートのポート番号を読み込む（ステップＳ１２）。

次に、コンピュータ異常監視部５１は、相手方コンピュータ１０からパケットが送信されるのを待ち、その送信されたパケットを受信すると（ステップＳ１３）、受信したパケットが生存パケットであるか否かを判定する（ステップＳ１４）。そして、その受信したパケットが生存パケットであったときには（ステップＳ１４でＹｅｓ）、コンピュータ異常監視部５１は、生存パケット管理テーブルにおいて、そのパケットを受信した受信ポートのポート番号に対応付けられたパケットカウンタの値に１を加算する（ステップＳ１５）。

また、受信したパケットが起動パケットであったときには（ステップＳ１４でＮｏ）、コンピュータ異常監視部５１は、起動通知を運転モード管理部５３へ送信し（ステップＳ１６）、さらに、そのとき運転モード管理テーブルを起動パケット送信元のコンピュータへ送信する（ステップＳ１７）。なお、起動通知は、相手方コンピュータ１０から起動パケットを受信したことを知らせる情報である。また、運転モード管理テーブルは、自らのコンピュータの運転モードを少なくとも記憶したテーブルであり、その詳細については、図９を用いて、別途、説明する。

コンピュータ異常監視部５１は、ステップＳ１５またはステップＳ１７を実行すると、ステップＳ１３へ戻り、相手方コンピュータ１０からパケットが送信されるのを待ち、繰り返して、その送信されたパケットを受信する（ステップＳ１３）。コンピュータ異常監視部５１は、このようにして相手方コンピュータ１０から送信されるパケットを受信する（ステップＳ１３）たびに、引き続きステップＳ１４〜ステップＳ１７を実行する。

図５は、コンピュータ異常監視部５１におけるコンピュータ異常検出処理の処理フローの例を示した図である。ここで、コンピュータ異常検出処理は、相手方コンピュータ１０から送信される生存パケットを受信しなくなったことを検出することにより、相手方コンピュータ１０の異常を判定する処理である。ただし、このコンピュータ異常検出処理は、相手方コンピュータ１０に実際に異常があることまでを判定するものではない。なお、このコンピュータ異常検出処理は、電源投入などによりコンピュータ１０が初期化されたときに起動される。

図５に示すように、コンピュータ異常監視部５１は、まず、初期化情報設定ファイルから、当該クラスタのクラスタ番号を読み込み（ステップＳ２１）、さらに、相手方コンピュータ１０の異常を判定する周期となる判定間隔時間を読み込む（ステップＳ２２）。

コンピュータ異常監視部５１は、ステップＳ２２で読み込んだ判定間隔時間の経過を待ち（ステップＳ２３）、その時間が経過すると、相手方コンピュータ１０から送信される生存パケットの受信異常の有無を判定する（ステップＳ２４）。このとき、コンピュータ異常監視部５１は、生存パケット管理テーブルのパケットカウンタを参照し、そのカウント数が前記判定間隔時間内に受信すべき生存パケット数に達しているか否かを判定し、その数に達していたときには、受信正常と判定し、その数に達していなかったときには、受信異常と判定する。なお、この受信異常は、相手方コンピュータ１０の異常（ネットワーク２０の障害による見かけの異常を含む）を意味する。

なお、以上の説明において、判定間隔時間は、生存パケットの送信間隔時間よりも、例えば、１桁ほど大きい値が設定されているものとする。また、パケットカウンタの値は、ステップＳ２４において参照された直後に、ゼロクリアされるものとする。

コンピュータ異常監視部５１は、ステップＳ２４の判定において受信異常があったと判定したときには（ステップＳ２５でＹｅｓ）、相手方コンピュータ１０の異常を検出したことを示す検出通知を運転モード管理部５３へ送信し（ステップＳ２６）、再度、判定間隔時間の経過を待つ（ステップＳ２３）。一方、ステップＳ２４の判定において受信異常がなかったと判定したときには（ステップＳ２５でＮｏ）、そのままステップＳ２３へ戻り、再度、判定間隔時間の経過を待つ（ステップＳ２３）。

なお、ステップＳ２４の判定において、生存パケット管理テーブルに複数のパケットカウンタが設定されていた場合には、そのそれぞれについて受信異常の有無を判定し、受信異常と判定されたパケットカウンタに対応するポート番号のポートに接続されたコンピュータが異常であると判定する。

続いて、図６〜図８を用い、通信監視部５２が実行する処理の内容について説明する。通信監視部５２が実行する処理には、通信監視パケット送信処理、通信監視パケット受信処理およびカウンタ値取得インタフェースが含まれる。

図６は、通信監視部５２における通信監視パケット送信処理の処理フローの例を示した図である。通信監視パケット送信処理は、応答パケットを要求する通信監視パケットを、ネットワーク２０を介して通信機器３０へ送信する処理である。この通信監視パケット送信処理は、電源投入などによりコンピュータ１０が初期化されたときに起動される。

図６に示すように、通信監視部５２は、まず、初期化情報設定ファイルから、通信監視パケットの送信先となる通信機器３０のＩＰアドレスを読み込み（ステップＳ３１）、さらに、送信間隔時間を読み込む（ステップＳ３２）。ここで、送信間隔時間は、通信監視パケットを送信する所定の時間間隔である。

次に、通信監視部５２は、ステップＳ３１で読み込んだＩＰアドレスを有する通信機器３０に向けて、通信監視パケットを送信する（ステップＳ３３）。その後、ステップＳ３２で読み込んだ送信間隔時間が経過するのを待ち（ステップＳ３４）、その時間が経過すると、再び、通信監視パケットを送信する（ステップＳ３３）。このようにして、通信監視部５２は、コンピュータ１０が動作している限り、前記送信間隔時間を周期として繰り返し通信監視パケットを送信し続ける。

図７は、通信監視部５２における通信監視パケット受信処理の処理フローの例を示した図である。ここで、通信監視パケット受信処理は、通信機器３０から送信される応答パケットを受信する処理である。ここで、応答パケットは、通信監視パケット送信処理によって送信された通信監視パケットを受信した通信機器３０が、通信監視パケット受信の応答として送信するパケットである。

図７に示すように、通信監視部５２は、通信機器３０から送信された応答パケットを受信するたびに（ステップＳ４１）、記憶装置の所定の作業領域に設けられた通信監視カウンタの値に１を加算する（ステップＳ４２）処理を繰り返す。このようにステップＳ４１およびステップＳ４２を繰り返すことにより、通信監視部５２は、応答パケットの受信数をカウントする。

図８は、通信監視部５２におけるカウンタ値取得インタフェースの処理フローの例を示した図である。ここで、カウンタ値取得インタフェースは、通信監視部５２の外部の処理（例えば、運転モード管理部５３に含まれる処理）から通信監視カウンタの値を取得するための処理であり、外部の処理からの呼び出しに応じて実行される。

図８に示すように、通信監視部５２は、外部の処理によりカウンタ値取得インタフェースが呼び出されると、記憶装置の所定の作業領域から通信監視カウンタのカウンタ値を読み取り（ステップＳ５１）、その読み取ったカウンタ値を呼び出し元の外部の処理へ返す（ステップＳ５２）。

続いて、図９および図１０を用い、運転モード管理部５３が実行する運転モード管理処理の内容について説明する。ここで、図９は、運転モード管理部５３における運転モード管理テーブルの構成の例を示した図、図１０は、運転モード管理部５３における運転モード管理処理の処理フローの例を示した図である。なお、この運転モード管理処理は、電源投入などによりコンピュータ１０が初期化されたときに起動される。

図９に示すように、運転モード管理テーブルは、クラスタ番号、コンピュータ番号、運転モードのデータなどを記憶する。ここで、クラスタ番号は、クラスタシステム１において相互に動作の異常を監視し合うコンピュータ１０の組を識別する番号である。また、コンピュータ番号は、クラスタシステム１を構成するコンピュータ１０を識別する番号である。また、運転モードは、コンピュータ番号に対応付けられたデータであり、そのコンピュータ番号を有するコンピュータのサービスアプリケーション１４の動作状態を表す。

なお、サービスアプリケーション１４の運転モードとして、実行状態、待機状態、停止状態の３つの動作状態がある。すなわち、実行状態は、コンピュータ１０がサービスアプリケーション１４を実行している状態をいい、待機状態は、サービスアプリケーション１４を実行していないが、コンピュータ１０が稼働中であり、いつでもサービスアプリケーション１４を実行することが可能な状態をいう。また、停止状態は、実行状態でも待機状態でもない状態をいう。なお、電源が投入されていないコンピュータ１０は、停止状態にあり、また、電源が投入された後であっても、次の図１０において説明する起動パケットを送信する以前は、停止状態にあるものとする。

図１０に示すように、運転モード管理部５３は、まず、初期化情報設定ファイルから、当該コンピュータ１０が属するクラスタのクラスタ番号、通信の間欠障害の判定に用いる閾値を読み込む（ステップＳ６０）。続いて、運転モード管理部５３は、クラスタを構成する相手方コンピュータ１０に対して起動パケットを送信し（ステップＳ６１）、その応答として相手方コンピュータ１０から送信される運転モード管理テーブルを取得する（ステップＳ６２）。なお、起動パケットは、自身のコンピュータに電源が投入されるなどして、いつでも動作できる状態であることを他のコンピュータに知らせるパケットである。

次に、運転モード管理部５３は、相手方コンピュータ１０から取得した運転モード管理テーブルに基づき、自身のコンピュータの初期運転モードを設定する（ステップＳ６３）。このとき、運転モード管理部５３は、前記取得した運転モード管理テーブルを参照して、自身が属するクラスタのコンピュータで、実行状態のコンピュータが存在しないときには、自らの運転モードを実行モードに設定し、実行状態のコンピュータが存在したときには、自らの運転モードを待機モードに設定する。

運転モード管理部５３は、ステップＳ６３で運転モードを実行状態に設定したときには（ステップＳ６４でＹｅｓ）、サービスアプリケーション１４の処理としてあらかじめ実行するように設定されたアプリケーションを起動し（ステップＳ６５）、コンピュータ異常監視部５１から送信される通知を待つ（ステップＳ６６）。また、ステップＳ６３で運転モードを実行状態以外に設定したときには（ステップＳ６４でＮｏ）、ステップＳ６５を実行せずに、そのままコンピュータ異常監視部５１からの通知を待つ（ステップＳ６６）。なお、ここでいう通知とは、図５のステップＳ２６で送信される検出通知、または、図４のステップＳ１６で送信される起動通知である。

運転モード管理部５３は、ステップＳ６６の通知待ちの状態で、コンピュータ異常監視部５１から検出通知でない通知、つまり、起動通知を受けたときには（ステップＳ６７でＮｏ）、その起動通知に含まれる起動パケット送信元コンピュータのコンピュータ番号に対応する運転モードを待機状態に設定し（ステップＳ６８）、ステップＳ６６へ戻り、次の通知を待つ。

また、運転モード管理部５３は、ステップＳ６６の通知待ちの状態で、コンピュータ異常監視部５１から相手方コンピュータ１０の異常を示す検出通知を受けたときには（ステップＳ６７でＹｅｓ）、通信監視部５２からカウンタ通信インタフェース（図８参照）を介して通信監視カウンタの値を取得する（ステップＳ６９）。そして、その取得したカウンタ値がステップＳ６０で取得した通信の間欠障害の閾値以上であるか否かを判定する（ステップＳ７０）。

その判定の結果、通信監視カウンタのカウンタ値が前記の閾値に達していなかったときには（ステップＳ７０でＮｏ）、所定時間内に通信監視パケットに応答する応答パケットの数が少なかったことを意味するので、運転モード管理部５３は、ネットワーク２０に間欠障害でない固定的な通信障害が生じたものと判断し、その通信障害に係るログを収集する（ステップＳ７１）。そして、その場合には、相手方コンピュータ１０は正常に動作していると判断し、運転モード管理テーブルなどを更新することはせず、そのままステップＳ６６へ戻り、次の通知を待つ。

一方、通信監視カウンタのカウンタ値が閾値以上であったときには（ステップＳ７０でＹｅｓ）、運転モード管理部５３は、ネットワーク２０に通信障害はないか、あったとしても間欠障害であった判断する。この場合には、相手方コンピュータ１０の異常が検出され、ネットワーク２０には通信障害がないことになるので、相手方コンピュータ１０には実際に異常が生じていたことになる。従って、運転モード管理部５３は、運転モード管理テーブルを更新する必要があり、自らおよび相手方コンピュータ１０の運転モードを更新する（ステップＳ７２）。

このとき、相手方コンピュータ１０の運転モードが待機状態であったときには、運転モード管理部５３は、モード管理テーブルでその運転モードを停止状態に更新するだけでよい。一方、相手方コンピュータ１０の運転モードが実行状態であったときには、運転モード管理部５３は、モード管理テーブルで相手方コンピュータ１０の運転モードを停止状態に更新するとともに、自身のコンピュータの運転モードを実行状態に更新する。

そこで、運転モード管理部５３は、自身のコンピュータの運転モードを実行状態に更新したときには（ステップＳ７３でＹｅｓ）、待機状態にあったサービスアプリケーション１４を起動し（ステップＳ７４）、ステップＳ６６へ戻り、次の通知を待つ。また、自身のコンピュータの運転モードを実行状態に更新しなかったときには（ステップＳ７３でＮｏ）、そのままステップＳ６６へ戻り、次の通知を待つ。

なお、図１０の運転モード管理処理の説明において、通信監視カウンタは、所定時間当たりに受信する応答メッセージの数をカウントするカウンタであるが、それを最も簡単に実現するには、図３のパケットカウンタをゼロクリアするとき併せて通信監視カウンタをゼロクリアすることが必要である。そして、通信監視カウンタをゼロクリアするに際しては、そのときの通信監視カウンタの値を記憶装置の所定の作業領域に記憶するものとし、通信監視部５２は、カウンタ値取得インタフェース（図８参照）を実行したとき、ステップＳ５２では、そのカウンタ値として、その所定の作業領域に記憶された値を返すものとする。

以上、第１の実施形態によれば、クラスタシステム１を構成するコンピュータ１０は、相手方コンピュータ１０の異常とネットワーク２０の通信障害とを区別して検出することができる。しかも、相手方コンピュータ１０の異常を検出するための生存パケットのパケットカウンタと、ネットワーク２０の通信障害を検出するための通信監視カウンタは、並行して動作するので、コンピュータ異常監視部５１が相手方コンピュータ１０の異常を検出したときには、運転モード管理部５３は、直ちに、通信監視カウンタを参照することにより、ネットワーク２０に通信障害があるか否かを判定することができる。従って、本実施形態によれば、相手方コンピュータ１０の異常とネットワーク２０の通信障害とを区別する処理時間を、従来技術に比べ大幅に短縮することができる。

＜第１の実施形態の変形例＞
次に、第１の実施形態の変形例について説明する。第１の実施形態においては、クラスタシステム１は、２つのコンピュータ１０−１，１０−２によって構成されているものとしたが、その変形例では、クラスタシステムは、３つ以上のコンピュータによって構成されているものとする。

まず、そのクラスタシステムは、ｎ台（ｎは、２以上の整数）の稼働コンピュータ１０−１と１台のスペアコンピュータ１０−２とによって構成されているとする。この場合には、ｎ台の稼働コンピュータ１０−１それぞれについてスペアコンピュータ１０−２とのペア（組）を構成し、そのそれぞれを１つのクラスタとする。このとき、スペアコンピュータ１０−２は、そのそれぞれのクラスタで重複して用いられることになるが、そのそれぞれのクラスタは、図１に示したクラスタシステム１と同じ構成になる。従って、そのそれぞれのクラスタのコンピュータ１０の構成および機能は、第１の実施形態の場合と同じにすることができる。

なお、この変形例の場合には、スペアコンピュータ１０−２は、ｎ台の稼働コンピュータ１０−１を相手に、相手方コンピュータ１０の異常を監視することになる。従って、その処理負荷は大きくなるが、スペアコンピュータ１０−２は、待機状態にあり、サービスアプリケーション１４を実行していないので、その処理負荷が問題になることはない。また、スペアコンピュータ１０−２の異常は、ｎ台の稼働コンピュータ１０−１によって重複して検出されることになるが、スペアコンピュータ１０−２の異常が重複して検出されても、稼働コンピュータ１０−１におけるサービスアプリケーション１４の実行状態には影響がないので、特に問題になることはない。

なお、スペアコンピュータ１０−２の異常を監視するために、ｎ台の稼働コンピュータ１０−１すべてを用いる必要はなく、ｎ台の稼働コンピュータ１０−１のうちの１台だけによってスペアコンピュータ１０−２の異常を監視するようにしてもよい。それを実現するには、ｎ−１台の稼働コンピュータ１０−１において、そのコンピュータ異常監視部５１および通信監視部５２の機能を休止させればよい。この場合には、スペアコンピュータ１０−２の異常が重複して検出されることはない。

また、この変形例の場合には、２台のコンピュータ１０−１，１０−２のペアで構成したクラスタそれぞれがすべて通信機器３０を備えている必要はない。通信機器３０は、全体のネットワークに１つあればよい。さらには、ペアを組んだコンピュータ１０−１，１０−２以外のコンピュータを通信機器３０として利用することもできる。その場合には、通信機器３０として特別なものとして設ける必要はない。

続いて、ｎ台の稼働コンピュータ１０−１とｍ台（ｍは、２以上でｎ以下の整数）のスペアコンピュータ１０−２とで構成されたクラスタシステムを考える。このようなクラスタシステムは、適宜、ｎ_ｉ台（ただし、ｎ＝Σｎ_ｉ，ｉ＝１，…，ｍ）の稼働コンピュータ１０−１と１台のスペアコンピュータ１０−２とで構成されたｍ個のクラスタシステムに分割することができる。従って、この場合にも、そのクラスタシステムを構成するコンピュータ１０の構成および機能は、前記した第１の実施形態の場合と同じにすることができる。

＜第２の実施形態＞
図１１は、本発明の第２の実施形態に係るクラスタシステムの構成の例を示した図である。図１１に示すように、クラスタシステム１Ａの構成は、図１の第１の実施形態のクラスタシステム１とほとんど同じ構成であるが、次のような相違がある。

クラスタシステム１Ａを構成するコンピュータ１０Ａとして２つのコンピュータ１０Ａ−１，１０Ａ−２は、それぞれ独立した２つのネットワーク２０ａ，２０ｂにより接続されている。また、通信機器３０は、２つのネットワーク２０ａ，２０ｂそれぞれに接続されている。また、以上の接続関係に対応するように、クラスタ管理システム１３Ａは、２つのコンピュータ異常監視部５１ａ，５１ｂを備える。このとき、ネットワーク２０ａを介して、コンピュータ異常監視部５１ａ同士で生存パケットの送受信を行い、また、ネットワーク２０ｂを介して、コンピュータ異常監視部５１ｂ同士で、生存パケットの送受信を行う。

以上のようにクラスタシステム１Ａでは、ネットワーク２０ａ，２０ｂとコンピュータ異常監視部５１ａ，５１ｂとが２重化されているので、相手方コンピュータ１０Ａの異常を、より高信頼度で検出することができる。

なお、以上の構成において、２つのネットワーク２０ａ，２０ｂが同時に障害を起こすことがない相互に独立したネットワークである場合には、通信機器３０はなくてもよい。すなわち、２つのコンピュータ異常監視部５１ａ，５１ｂの両方で相手方コンピュータ１０Ａの異常を検出したときには、相手方コンピュータ１０Ａに実際に異常が生じていると判定することができる。また、２つのコンピュータ異常監視部５１ａ，５１ｂの一方だけで相手方コンピュータ１０Ａの異常を検出したときには、一方のネットワーク２０ａまたは２０ｂの通信障害であり、相手方コンピュータ１０Ａは正常に動作していると判定することができる。

第１の実施形態に係るクラスタシステムの構成の例を示した図。 コンピュータ異常監視部における生存パケット送信処理の処理フローの例を示した図。 コンピュータ異常監視部における生存パケット管理テーブルの構成の例を示した図。 コンピュータ異常監視部におけるパケット受信処理の処理フローの例を示した図。 コンピュータ異常監視部におけるコンピュータ異常検出処理の処理フローの例を示した図。 通信監視部における通信監視パケット送信処理の処理フローの例を示した図。 通信監視部における通信監視パケット受信処理の処理フローの例を示した図。 通信監視部におけるカウンタ値取得インタフェースの処理フローの例を示した図。 運転モード管理部における運転モード管理テーブルの構成の例を示した図。 運転モード管理部における運転モード管理処理の処理フローの例を示した図。 本発明の第２の実施形態に係るクラスタシステムの構成の例を示した図。

符号の説明

１，１Ａ クラスタシステム
１０，１０Ａ コンピュータ
１１ ネットワークドライバ
１２ オペレーティングシステム
１３，１３Ａ クラスタ管理システム
１４ サービスアプリケーション
２０，２０ａ，２０ｂ ネットワーク
３０ 通信機器
５１，５１ａ，５１ｂ コンピュータ異常監視部
５２ 通信監視部
５３ 運転モード管理部

Claims (9)

1. 所定のサービスアプリケーションを実行している稼働コンピュータと、その稼働コンピュータにネットワークを介して接続され、前記所定のサービスアプリケーションを実行可能な状態で待機しているスペアコンピュータと、を含んで構成されたクラスタシステムであって、
   前記稼働コンピュータおよび前記スペアコンピュータのそれぞれは、
   動作開始後、前記ネットワークを介して接続された相手方コンピュータに対し、自らが動作していることを示す生存パケットを所定の時間間隔で繰り返し送信するとともに、前記相手方コンピュータから送信される生存パケットの受信を監視し、所定時間内に所定数に達する前記生存パケットを受信しなかったとき、それを前記相手方コンピュータの異常として検出するコンピュータ異常監視手段と、
   動作開始後、前記通信機器に対して所定の時間間隔で繰り返し通信監視パケットを送信するとともに、その応答として前記ネットワークに接続された通信機器から送信される応答パケットを受信して、その応答パケットの所定時間当たりの受信数をカウントする通信監視手段と、
   を備え、
   前記コンピュータ異常監視手段により前記相手方コンピュータの異常を検出したときには、前記通信監視手段から前記所定時間当たりの応答パケットの受信数を取得し、その受信数に基づき、前記検出した相手方コンピュータの異常が、前記相手方コンピュータに実際に生じた異常であるのか、または、前記ネットワークの通信障害により生じた見かけの異常であるのか、を区別して判定すること
   を特徴とするクラスタシステム。
2. 前記稼働コンピュータおよび前記スペアコンピュータのそれぞれは、
   前記検出した相手方コンピュータの異常を区別して判定する場合、前記通信監視部から取得した前記所定時間当たりの応答パケットの受信数が所定の閾値以上であったとき、相手方コンピュータに実際に生じた異常であると判定し、前記応答パケットの受信数が前記所定の閾値に達していなかったとき、前記ネットワークの通信障害により生じた見かけの異常であると判定すること
   を特徴とする請求項１に記載のクラスタシステム。
3. 前記スペアコンピュータは、
   前記検出した相手方コンピュータの異常が前記相手方コンピュータに実際に生じた異常であると判定したときには、さらに、前記相手方コンピュータが実行していた前記サービスアプリケーションを、前記相手方コンピュータに代わって自らが実行すること
   を特徴とする請求項１または請求項２に記載のクラスタシステム。
4. 所定のサービスアプリケーションを実行している稼働コンピュータと、その稼働コンピュータにネットワークを介して接続され、前記所定のサービスアプリケーションを実行可能な状態で待機しているスペアコンピュータと、を含んで構成されたクラスタシステムに用いられるコンピュータであって、
   動作開始後、前記ネットワークを介して接続された相手方コンピュータに対し、自らが動作していることを示す生存パケットを所定の時間間隔で繰り返し送信するとともに、前記相手方コンピュータから送信される生存パケットの受信を監視し、所定時間内に所定数に達する前記生存パケットを受信しなかったとき、それを前記相手方コンピュータの異常として検出するコンピュータ異常監視手段と、
   動作開始後、前記通信機器に対して所定の時間間隔で繰り返し通信監視パケットを送信するとともに、その応答として前記ネットワークに接続された通信機器から送信される応答パケットを受信して、その応答パケットの所定時間当たりの受信数をカウントする通信監視手段と、
   を備え、
   前記コンピュータ異常監視手段により前記相手方コンピュータの異常を検出したときには、前記通信監視手段から前記所定時間当たりの応答パケットの受信数を取得し、その受信数に基づき、前記検出した相手方コンピュータの異常が、前記相手方コンピュータに実際に生じた異常であるのか、または、前記ネットワークの通信障害により生じた見かけの異常であるのか、を区別して判定すること
   を特徴とするコンピュータ。
5. 前記検出した相手方コンピュータの異常を区別して判定する場合、前記通信監視部から取得した前記所定時間当たりの応答パケットの受信数が所定の閾値以上であったとき、相手方コンピュータに実際に生じた異常であると判定し、前記応答パケットの受信数が前記所定の閾値に達していなかったとき、前記ネットワークの通信障害により生じた見かけの異常であると判定すること
   を特徴とする請求項４に記載のコンピュータ。
6. 前記検出した相手方コンピュータの異常が前記相手方コンピュータに実際に生じた異常であると判定したときに、自らがスペアコンピュータとして動作していた場合には、さらに、前記相手方コンピュータが実行していた前記サービスアプリケーションを、前記相手方コンピュータに代わって実行すること
   を特徴とする請求項４または請求項５に記載のコンピュータ。
7. 所定のサービスアプリケーションを実行している稼働コンピュータと、その稼働コンピュータにネットワークを介して接続され、前記所定のサービスアプリケーションを実行可能な状態で待機しているスペアコンピュータと、を含んで構成されたクラスタシステムにおける異常検出方法あって、
   前記稼働コンピュータおよび前記スペアコンピュータのそれぞれは、
   動作開始後、前記ネットワークを介して接続された相手方コンピュータに対し、自らが動作していることを示す生存パケットを所定の時間間隔で繰り返し送信するとともに、前記相手方コンピュータから送信される生存パケットの受信を監視し、
   さらに、動作開始後、前記通信機器に対して所定の時間間隔で繰り返し通信監視パケットを送信するとともに、その応答として前記ネットワークに接続された通信機器から送信される応答パケットを受信して、その応答パケットの所定時間当たりの受信数をカウントし、
   前記相手方コンピュータから送信される生存パケットを所定時間内に所定数に達する前記生存パケットを受信しなかったときには、それを前記相手方コンピュータの異常として検出すると、前記カウント中の所定時間当たりの応答パケットの受信数に基づき、前記検出した相手方コンピュータの異常が、前記相手方コンピュータに実際に生じた異常であるのか、または、前記ネットワークの通信障害により生じた見かけの異常であるのか、を区別して判定すること
   を特徴とする異常検出方法。
8. 前記稼働コンピュータおよび前記スペアコンピュータのそれぞれは、
   前記検出した相手方コンピュータの異常を区別して判定する場合、前記カウント中の所定時間当たりの応答パケットの受信数が所定の閾値以上であったとき、相手方コンピュータに実際に生じた異常であると判定し、前記応答パケットの受信数が前記所定の閾値に達していなかったとき、前記ネットワークの通信障害により生じた見かけの異常であると判定すること
   を特徴とする請求項７に記載の異常検出方法。
9. 前記スペアコンピュータは、
   前記検出した相手方コンピュータの異常が前記相手方コンピュータに実際に生じた異常であると判定したときには、さらに、前記相手方コンピュータが実行していた前記サービスアプリケーションを、前記相手方コンピュータに代わって自らが実行すること
   を特徴とする請求項７または請求項８に記載の異常検出方法。

Images