JP4246248B2 - クラスタシステムのコンピュータにおいて実行されるネットワークモニタ・プログラム、情報処理方法及びコンピュータ - Google Patents

Description

本発明は、クラスタシステムにおける障害対応技術に関する。

クラスタ運用ノードとクラスタ待機ノードとを含むクラスタシステムにおいて、クラスタ運用ノードで実行されているネットワークモニタは、例えばイントラネットやインターネットと接続し且つインターネット等に接続された他のコンピュータからの業務リクエストをクラスタ運用ノードに中継するネットワーク中継装置に対して、定期的に生存確認メッセージを送信するようになっている。ネットワーク中継装置とクラスタ運用ノードの間の業務ＬＡＮ（Local Area Network）が正常に機能していれば、ネットワーク中継装置は生存確認メッセージに対して応答を返すが、クラスタ運用ノード等のネットワーク・インターフェース・カード（ＮＩＣ：Network Interface Card）の故障、ネットワーク中継装置の故障等により通信障害が発生した場合は、ネットワーク中継装置から応答が返ってこなくなる。一定回数ネットワーク中継装置から応答が得られない場合、ネットワークモニタは、クラスタ運用ノードにおいて実行されているクラスタマネージャに対してネットワーク障害の発生を通知する。そうすると、クラスタ運用ノードにおけるクラスタマネージャは、クラスタ運用ノードにおいて実行されている業務アプリケーションを停止した後、ネットワークモニタに使用中の引継ＩＰアドレスを不活性化させる。次に、クラスタ待機ノードにおけるネットワークモニタがクラスタ運用ノードにおけるクラスタマネージャからの要求に応じて引継ＩＰアドレスを活性化し、クラスタ待機ノードにおける業務アプリケーションを起動することで以降の業務をクラスタ待機ノードに引き継がせる。

なお、特開平４−２９１６２８号公報には、複合サブシステム形オンラインシステムにおいて、複合サブシステムコントローラに障害が発生した場合、自動的に障害を回復するための技術が開示されている。具体的には、コントローラの障害発生を検知したコントローラモニタは、待機ジョブが存在する場合はホットスタンバイ開始を指示する。待機ジョブが存在しない場合は、コントローラ配下の全サブシステムを停止した後コントローラを起動し、最新のチェックポイントとそのチェックポイント以降にとられたジャーナル情報から、実行系のプロセッサがダウンした状況まで戻して処理を続行するものである。これにより、複合サブシステムコントローラにハード的な原因によるものではなく一時的且つタイミング的な原因による障害が発生した場合、自動的に障害を回復し処理を続行することができるとされる。但し、ネットワークにおける障害発生について対応するものではない。

上で述べた従来技術では、クラスタ待機ノードにおいてクラスタマネージャにネットワーク障害が通知された場合、それ以降当該クラスタ待機ノードは切り捨てられる、すなわち動作不能状態になる。この動作不能状態はクラスタ運用ノードのクラスタマネージャにも通知される。その後、クラスタ運用ノードにおいてクラスタマネージャにネットワーク障害が通知されると、切り換え先のノードがないとみなされ、ノード切り換えが行われなくなる。クラスタ運用ノードでは、業務アプリケーションが停止され、引継ＩＰアドレスも不活性化されるため、その時点で業務停止となってしまう。発生した障害が、クラスタ待機ノードやクラスタ運用ノードのＮＩＣ、ネットワーク中継装置等のハードウエアの故障によるものである場合、上記のような制御で問題ない。

しかし、業務ＬＡＮにおける通信量の増大によりネットワーク中継装置が高負荷状態となった場合、ネットワークモニタからの生存確認メッセージに対して、一時的に応答が返せなくなったり、応答が遅延したりする。また、ネットワーク中継装置によっては、トラフィックに優先度付けを行い、高負荷状態の場合、優先度の低いトラフィックを破棄し、優先度の高いもののみを処理するといった制御を行っているものがあり、生存確認メッセージに対する応答を返さなくなる場合がある。このように一時的に業務ＬＡＮにおいて輻輳が発生した場合、ある程度時間が経過すれば通信可能な状態に回復することが見込まれる。一方でクラスタ運用ノードとクラスタ待機ノードの双方においてネットワークモニタによりネットワーク障害の発生が検出され、クラスタマネージャに通知されると、（１）クラスタ運用ノードからクラスタ待機ノードへの切り換えが行われた直後に、クラスタ待機ノードでも障害を検出し業務アプリケーションが停止する。又は（２）クラスタ待機ノード側において障害が検出されたためクラスタ待機ノードの切捨てが行われ、ノード切り換えが行われずにクラスタ運用ノードの業務アプリケーションが停止する。

このように、クラスタ運用ノードとクラスタ待機ノードの双方がリソース異常となるため、その後ネットワークが復旧しても、オペレータが管理コンソールから各ノードのクラスタマネージャを操作し、業務アプリケーションを再起動しなければ業務を再開することができないという問題がある。また、業務アプリケーションの再起動を行う前には、業務の停止が発生した原因を調査するためのデータ採取や、業務の再開を問題なく行うことができるかどうかを確認するための点検作業などが必要となり、時間や手間がかかるという問題もある。

このように、ネットワークにおける通信量の増大により一時的にネットワーク障害が発生した場合、ノードの切り換えを行い、業務をクラスタ運用ノードからクラスタ待機ノードに引き継いでも、業務が継続される保証はない。また、ネットワーク中継装置のファームウェアをアップデートするといった保守作業を行う際に、誤ってネットワークモニタによる監視を停止せずにネットワーク中継装置の再起動を行うといったオペレーションミスが発生した場合も、クラスタ運用ノード及びクラスタ待機ノードの両方が停止してしまい、再起動に時間や手間がかかってしまうということも生じていた。

一般に、クラスタシステムで動作するアプリケーションにおいて致命的なエラーが発生した場合におけるノード切り換え制御は、そのクラスタシステムに依存する。エラーが発生した場合、ネットワークモニタは、単に当該エラーをクラスタマネージャに通知するのみで、他のノードで業務の継続が可能であるかどうかは考慮していない。また、一般的なクラスタシステムでは、各ノードのアプリケーションの状態を参照し、既にノードが動作不能状態となっているかどうかを判断するためのインタフェース（コマンド、ＡＰＩ（Application Program Interface）など）を備えてはいるが、各ノードでエラーがほぼ同時に検出されたような場合に、他のノードで業務が継続できるかどうかを正しく判断することができない。
特開平４−２９１６２８号公報

従って、本発明の目的は、一時的なネットワーク障害が発生したような場合においても、クラスタシステム全体として可能な限り業務中断又は停止を引き起こさないようにするための障害対応技術を提供することである。

本発明に係る、クラスタシステムに含まれるコンピュータに実行される情報処理方法は、上記コンピュータへの業務リクエストを中継する中継装置から生存確認メッセージに対する応答を受信できなかった場合、上記クラスタシステムに含まれる他のコンピュータの状況データを取得するステップと、上記他のコンピュータの状況データが上記他のコンピュータのいずれかが使用可能な状態（動作不能状態とも記す）であることを示している場合、当該使用可能な状態のコンピュータが上記中継装置と通信可能か確認する確認ステップと、上記使用可能な状態のコンピュータが上記中継装置と通信可能であると確認できた場合に、クラスタマネージャに通信障害の発生を通知するステップとを含む。

このように自コンピュータだけが通信障害を検知していることが確認できた場合には、クラスタマネージャに通信障害を通知して例えばノード切り替えを行うようにする。そうすれば、クラスタ運用ノード及びクラスタ待機ノードの両方が稼働停止状態に移行して業務中断又は停止となることを防止することができる。なお、確認ステップにおける確認は、中継装置が接続されたネットワークとは別の経路を用いて行われる。

また、上記他のコンピュータの状況データが上記他のコンピュータのいずれもが使用不能な状態であることを示している場合、上記中継装置へ第２の生存確認メッセージを送信して、当該中継装置からの応答を待つステップをさらに含むようにしても良い。クラスタシステム内のいずれのコンピュータにおいても中継装置と通信不能であると確認された場合、自コンピュータを稼働不能状態に移行させると、クラスタシステム全体として業務が中断又は停止してしまうおそれがあるため、中継装置に対して再度生存確認を行うものである。そして、応答を受信できれば、一時的なネットワーク障害であったことが確認できるので、通常状態に移行する。

さらに、上記使用可能状態のコンピュータのいずれもが中継装置と通信不能であると確認された場合、中継装置へ第２の生存確認メッセージを送信して、中継装置からの応答を待つステップをさらに含むようにしても良い。使用可能状態のコンピュータのいずれもが中継装置と通信不能ということは、自コンピュータを稼働不能状態に移行させてノードの切り換えを行っても、クラスタシステム全体として業務を継続実施することはできないので、中継装置に再度生存確認を行って、一時的なネットワーク障害であるかを確認するものである。そして、応答を受信できれば、通常状態に移行する。

上で述べた情報処理方法をコンピュータに実行させるためのネットワークモニタ・プログラムを作成することができ、このネットワークモニタ・プログラムは、例えばフレキシブルディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークなどを介してデジタル信号として配信される場合もある。尚、中間的な処理結果はメモリ等の記憶装置に一時保管される。

図１は、本発明の実施の形態における機能ブロック図である。 図２は、ネットワークモニタの処理フローを示す図である。 図３は、コンピュータ装置の機能ブロック図である。

図１に本発明の一実施の形態における機能ブロック図を示す。インターネット又はイントラネットであるネットワーク１には、ルータやスイッチなどのネットワーク中継装置３及び９などが接続されている。ネットワーク中継装置３は、ネットワーク１と業務用ＬＡＮ（Local Area Network）１９とを接続する接続機器であって、業務用ＬＡＮ１９を介して、業務処理を通常実行するコンピュータであるクラスタ運用ノード５と、クラスタ運用ノード５において障害が発生した場合にクラスタ運用ノード５の業務処理を引き継ぐコンピュータであるクラスタ待機ノード７と接続されている。ここではクラスタ運用ノード５とクラスタ待機ノード７との２つのコンピュータでクラスタシステムが構成される例が示されているが、３台以上のコンピュータによりクラスタシステムが構成されるようにしても良い。クラスタ運用ノード５とクラスタ待機ノード７とは、プライベートＬＡＮ１７で各々が接続されている。プライベートＬＡＮ１７では、以下で述べる引継ＩＰアドレスとは異なるＩＰアドレスが各ノードに付与されており、このＩＰアドレスを用いて通信することができる。また、クラスタシステムの管理者が操作する管理用コンソール１５は、管理用ＬＡＮ２３を介してクラスタ運用ノード５とクラスタ待機ノード７と接続されている。さらに、ネットワーク中継装置９は、ネットワーク１と業務用ＬＡＮ２１とを接続する接続機器であって、業務用ＬＡＮ２１を介してリモートノード１１及び１３と接続されている。

クラスタ運用ノード５は、クラスタシステム上で動作するアプリケーション・プログラムであって引継ＩＰアドレスを使用して通信を行う業務アプリケーション５１と、ネットワークモニタ５２と、クラスタマネージャ５３と、ノード状態格納部５４と、引継アドレス格納部５５とを含む。クラスタ運用ノード５において、業務アプリケーション５１とネットワークモニタ５２とクラスタマネージャ５３とが起動されている。また、クラスタ運用ノード５は、引継アドレス格納部５５に格納されている引継アドレスを用いて、ネットワーク１及びネットワーク中継装置３を介して他のコンピュータと通信する。

一方、クラスタ待機ノード７は、業務アプリケーション７１と、ネットワークモニタ７２と、クラスタマネージャ７３と、ノード状態格納部７４と、引継アドレス格納部７５とを含む。なお、待機系なので、クラスタ待機ノード７では、ネットワークモニタ７２及びクラスタマネージャ７３のみが起動されている。また、引継アドレス格納部７５には、引継アドレスが格納されているが不活性化されているか、引継アドレスが格納されていない。

クラスタマネージャ５３及び７３は、互いにプライベートＬＡＮ１７を介して通信を行って、クラスタシステム上で動作するアプリケーションの切替えを制御すると共に、クラスタシステムを構成するノードの状態をノード状態格納部５４又は７４に格納するようになっている。ネットワークモニタ５２及び７２は、クラスタシステム上の各ノードで実行されるアプリケーション・プログラムであって、業務用ＬＡＮ１９の通信状態を監視し、通信障害を検出した場合には、クラスタマネージャ５３又は７３に通知を行う。また、クラスタマネージャ５３又は７３からの指示により、引継ＩＰアドレスの活性化又は不活性化を行う。

リモートノード１１及び１３は、業務アプリケーション１１ａ又は１３ａを実行し、クラスタシステムのクラスタ運用ノード５、場合によってはクラスタ待機ノード７に対して業務リクエストを送信して、クラスタ運用ノード５又はクラスタ待機ノード７から応答を受信する。業務アプリケーション１１ａ又は１３ａは、例えばウェブ（Ｗｅｂ）ブラウザであってもよい。

本実施の形態では、ネットワークモニタ５２及び７２の構成のみを変更することによって、業務用ＬＡＮ１９に一時的に障害が発生した場合に、クラスタシステム全体が業務中断又は中止状態に陥るのを防止することを目的とする。すなわち、業務アプリケーション５１及び７１、クラスタマネージャ５３及び７３、ノード状態格納部５４及び７４、並びに引継アドレス格納部５５及び７５については、従来と変わらないものとする。

そこで図２を用いてネットワークモニタ５２及び７２の動作を説明する。なお、本実施の形態では、クラスタ運用ノード５におけるネットワークモニタ５２も、クラスタ待機ノード７におけるネットワークモニタ７２も、その動作は変わらない。

まず、ネットワークモニタ（５２及び７２。以下省略。）は、業務用ＬＡＮ１９に接続されたネットワーク中継装置３に対して生存確認メッセージを送信する（ステップＳ１）。生存確認メッセージには、ＴＣＰ／ＩＰプロトコルの１つであるＩＣＭＰ（Internet Control Message Protocol）を使用することができる。例えば、ICMP Echo Requestメッセージを生存確認メッセージとして送信すればよい。

そして、ネットワークモニタは、第１の所定時間以内にネットワーク中継装置３から応答を受信したか判断する（ステップＳ３）。もし、第１の所定時間以内にネットワーク中継装置３から応答を受信した場合には、特に問題はないので、第２の所定時間スリープし（ステップＳ５）、その後ステップＳ１に戻る。

一方、第１の所定時間以内にネットワーク中継装置３から応答を受信していない場合には、所定回数（例えば５回）以上連続して応答がないか判断する（ステップＳ７）。図２では示していないが、例えばステップＳ３とステップＳ７の間にカウンタを１インクリメントするステップを実行し、ステップＳ３とステップＳ５の間に当該カウンタの値をクリアするステップを実行すればよい。もし、応答を受信しない回数が所定回数に達していない場合にはステップＳ５に移行する。一方、応答を受信していない回数が所定回数に達した場合には、以下で再度生存確認メッセージをカウントする必要があるのでカウンタをクリアした後、自ノードのクラスタマネージャ５３又は７３に他のノードの状態を問い合わせる（ステップＳ９）。これに対してクラスタマネージャ５３又は７３は、ノード状態格納部５４又は７４に格納されている他のノード状態（稼働状態／動作不能状態など）に関するデータを読み出し、ネットワークモニタに出力する。ネットワークモニタは、クラスタマネージャ５３又は７３から他のノード状態に関するデータを受け取ると、他のノード全てが動作不能状態となっているか判断する（ステップＳ１１）。

もし、クラスタシステムを構成する他のノード全てが動作不能状態となっている場合には、自ノードが動作不能となるとクラスタシステム全体が動作不能で業務停止又は中断ということになるので、ステップＳ１７に移行して、再度、業務用ＬＡＮ１９に接続されたネットワーク中継装置３に対して生存確認メッセージを送信する。そして、ネットワークモニタは、第１の所定時間以内にネットワーク中継装置３から応答を受信したか判断する（ステップＳ１９）。もし、第１の所定時間以内にネットワーク中継装置３から応答を受信した場合には、一時的に障害が発生したが現在は復旧したということであるから、特にクラスタマネージャ５３又は７３に通知する必要はない。従って、クラスタマネージャ５３又は７３への通信障害通知を中止して（ステップＳ２３）、ステップＳ５に移行する。すなわち、通常の監視状態に戻る。このように一時的にネットワーク障害が発生した場合には、無駄に動作不能状態に移行することが無くなる。

一方、第１の所定時間以内にネットワーク中継装置３から応答を受信しない場合には、再度所定回数以上応答がないか判断する（ステップＳ２１）。応答を受信しない回数が所定回数に達していない場合にはステップＳ２５に移行し、第３の所定時間スリープして、ステップＳ９に戻る。上でも述べたが、例えばステップＳ１９とステップＳ２１の間でカウンタを１インクリメントし、ステップＳ１９とステップＳ２３の間でカウンタの値をクリアするようにしても良い。所定回数以上応答がない場合には、長期に渡るネットワーク障害であると考えられるので、端子Ａを介してステップＳ２７に移行する。但し、所定回数をステップＳ７における所定回数とは異なる値として、例えば無限ループのようにする場合もある。すなわち実質的にステップＳ２７に移行しないようする場合もある。また、クラスタ待機ノード７とクラスタ運用ノード５では、所定回数を変えても良い。例えば、クラスタ運用ノード５の方の回数を多くするようにしても良い。

また、ステップＳ１１で動作可能な他のノードが存在する場合には、当該他のノードに対し、当該他のノードからネットワーク中継装置３との通信が可能であるか確認する（ステップＳ１３）。この確認の方法としては、プライベートＬＡＮ１７を介して他のノードにおいて実行されているネットワークモニタに、例えばネットワーク中継装置３宛に生存確認メッセージを送信するように依頼する方法と、プライベートＬＡＮ１７を介して他のノードをリモートプロシージャコールなどを用いて直接制御し、例えばネットワーク中継装置３宛に生存確認メッセージを送信させる方法とが存在する。前者の方法であれば他のノードのネットワークモニタから確認結果を受信し、後者の方法であれば自身で確認結果を得ることができる。

そして、ネットワーク中継装置３と通信を行うことができた、すなわちネットワーク中継装置３から応答を受信することができた他のノードが存在するか判断する（ステップＳ１５）。ネットワーク中継装置３と通信を行うことができた他のノードが存在する場合には、自ノードに障害が発生しているか又はネットワーク中継装置３の自ノードと接続するポートに障害が発生している可能性があるので、ステップＳ２７に移行する。

一方、ネットワーク中継装置３と通信を行うことができた他のノードが存在しない場合には、ネットワーク中継装置３の障害なのか、一時的なネットワークの輻輳が発生しているのかを判断できないので、とりあえずステップＳ１７に移行する。

ステップＳ２７では、通信可能な他のノードが存在するため、自ノードに関連する障害が発生していると判断できる場合（ステップＳ１５：Ｙｅｓルート）、又は長期に渡りネットワークに障害が発生していると判断される場合（ステップＳ２１：Ｙｅｓルート）、自ノードのクラスタマネージャに通信障害発生を通知する。

クラスタマネージャは、ネットワークモニタから通信障害が通知されると、通常の動作を行う。すなわち、クラスタ運用ノード５のネットワークモニタ５２が通信障害発生をクラスタマネージャ５３に通知した場合には、（１）クラスタ運用ノード５の業務アプリケーション５１を停止し、（２）クラスタ運用ノード５のネットワークモニタ５２に引継ＩＰアドレスの不活性化を要求し、ネットワークモニタ５２が引継ＩＰアドレスを不活性化させ、（３）クラスタ待機ノード７のネットワークモニタ７２に引継ＩＰアドレスの活性化を要求し（例えば引継ＩＰアドレスを含む活性化要求を送信）、ネットワークモニタ７２が引継ＩＰアドレスの活性化を行い（例えば、引継ＩＰアドレス格納部７５に格納し、業務用ＬＡＮ１９におけるＩＰアドレスとして設定）、（４）クラスタ待機ノード７の業務アプリケーション７１を起動する。

一方、クラスタ待機ノード７のネットワークモニタ７２が通信障害発生をクラスタマネージャ７３に通知した場合には、ノードの状態を動作不能状態として他のノードのクラスタマネージャに通知する。

以上のような処理を実施することにより、業務ＬＡＮ１９の通信負荷の一時的な増大や保守作業時におけるオペレーションミスによる不要なノード切り替え、クラスタ待機ノード７の動作不能状態への移行が抑制される。一方、特定のノードにおいてのみ障害が発生していることも確認できるので、そのような障害発生時には従来通りノードの切り換え又は動作不能状態への移行が速やかに行われる。

さらに、他の全てのノードが動作不能状態で通信障害が発生した場合、他のノード復旧を待ち合わせた上で業務の引継ぎを行ったり、ネットワーク障害の復旧を待ち合わせて業務を再開したりすることが可能となる。

以上本発明の一実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、プライベートＬＡＮ１７に、例えばデータベースを接続させてクラスタシステムにおいて共用するようにしてもよい。また、ステップＳ２１においてステップＳ２７へ移行するタイミングについては、様々な調整が可能である。

なお、上で述べたクラスタ運用ノード５、クラスタ待機ノード７、管理用コンソール１５、リモートノード１１及び１３は、コンピュータ装置であって、図３に示すように、メモリ２５０１（記憶部）とＣＰＵ２５０３（処理部）とハードディスク・ドライブ（ＨＤＤ）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。必要に応じてＣＰＵ２５０３は、表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ２５０１に格納され、必要があればＨＤＤ２５０５に格納される。本発明の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及び必要なアプリケーション・プログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。

Claims (5)

1. クラスタシステムに含まれるコンピュータで動作するネットワークモニタ・プログラムであって、
   前記コンピュータへの業務リクエストを中継する中継装置から生存確認メッセージに対する応答を受信できなかった場合、前記クラスタシステムに含まれる他のコンピュータの状況データを取得するステップと、
   前記他のコンピュータの状況データが前記他のコンピュータのいずれかが使用可能な状態であることを示している場合、当該使用可能な状態のコンピュータが前記中継装置と通信可能か確認するステップと、
   前記使用可能な状態のコンピュータが前記中継装置と通信可能であると確認できた場合に、クラスタマネージャに通信障害の発生を通知するステップと、
   を上記コンピュータに実行させるためのネットワークモニタ・プログラム。
2. 前記他のコンピュータの状況データが前記他のコンピュータのいずれもが使用不能な状態であることを示している場合、前記中継装置へ第２の生存確認メッセージを送信して、前記中継装置からの応答を待つステップ、
   をさらに実行させるための請求項１記載のネットワークモニタ・プログラム。
3. 前記使用可能状態のコンピュータのいずれもが前記中継装置と通信不能であると確認された場合、前記中継装置へ第２の生存確認メッセージを送信して、前記中継装置からの応答を待つステップ、
   をさらに実行させるための請求項１記載のネットワークモニタ・プログラム。
4. クラスタシステムに含まれるコンピュータに実行される情報処理方法であって、
   前記コンピュータへの業務リクエストを中継する中継装置から生存確認メッセージに対する応答を受信できなかった場合、前記クラスタシステムに含まれる他のコンピュータの状況データを取得するステップと、
   前記他のコンピュータの状況データが前記他のコンピュータのいずれかが使用可能な状態であることを示している場合、当該使用可能な状態のコンピュータが前記中継装置と通信可能か確認するステップと、
   前記使用可能な状態のコンピュータが前記中継装置と通信可能であると確認できた場合に、クラスタマネージャに通信障害の発生を通知するステップと、
   を含む情報処理方法。
5. クラスタシステムに含まれるコンピュータであって、
   ネットワークモニタと、
   クラスタマネージャと、
   を有し、
   前記ネットワークモニタが、
   前記コンピュータへの業務リクエストを中継する中継装置から生存確認メッセージに対する応答を受信できなかった場合、前記クラスタシステムに含まれる他のコンピュータの状況データを取得する手段と、
   前記他のコンピュータの状況データが前記他のコンピュータのいずれかが使用可能な状態であることを示している場合、当該使用可能な状態のコンピュータが前記中継装置と通信可能か確認する手段と、
   前記使用可能な状態のコンピュータが前記中継装置と通信可能であると確認できた場合に、前記クラスタマネージャに通信障害の発生を通知する手段と、
   を有するコンピュータ。

Images