(57)【特許請求の範囲】
【請求項１】
クラスタを構成する複数の被障害監視ノードと、ユーザ端末からのリクエストを前記各被障害監視ノードに対して分配する負荷分散装置と、前記複数の被障害監視ノードの中から異常の発生しているノードを検出するための障害監視ノードとから構成されるクラスタ障害推定システムにおいて、
前記複数の被障害監視ノードは、それぞれ、当該被障害監視ノードの資源の利用状況を示す内部情報を詳細情報として取得する詳細情報取得手段を有し、
前記障害監視ノードは、
前記詳細情報を格納するための詳細情報格納手段と、
前記詳細情報取得手段から送られてきた詳細情報を前記詳細情報格納手段に格納する詳細情報管理手段と、
前記複数の被障害監視ノードのうち、リクエストの分配を停止する被障害監視ノードを選定するリクエスト停止ノード選択手段と、
前記リクエスト停止ノード選択手段において選定された被障害監視ノードの詳細情報を前記詳細情報格納手段から取得し、取得した該詳細情報を用いて、複数の被障害監視ノードの中から資源の利用状況が他の被障害監視ノードとは異なるパターンを示す被障害監視ノードを算出する希少ノード計算手段と、
前記希少ノード計算手段によって計算された計算結果を用いて、異常状態にある被詳細監視ノードを検出するクラスタ障害推定手段と、
前記クラスタ障害推定手段により異常が発生していると判定された被障害ノードをネットワークから切り離すノード切離し手段とを有し、
前記負荷分散装置は、
前記リクエスト停止ノード選択手段において選定された被障害監視ノードに対するリクエストの分配を停止するリクエスト停止手段を有することを特徴とするクラスタ障害推定システム。
【請求項２】
前記障害監視ノードは、
前記クラスタ障害推定手段において異常の発生している被障害監視ノードが検出されなかった場合、前記詳細情報格納部に格納されている詳細情報に基づいて前記複数の被障害監視ノードが過負荷状態であるか否かを判定し、該複数の被障害監視ノードが過負荷状態であると判定した場合、前記複数の被障害監視ノードの詳細情報取得手段に対して、詳細情報の取得を一時的に停止するように命令するクラスタ状態観察手段をさらに有する請求項１記載のクラスタ障害推定システム。
【請求項３】
前記障害監視ノードは、
前記希少ノード計算手段によって使用される計算方法を変更するための希少ノード計算手段設定部と、
前記希少ノード計算手段によって使用された計算方法および、計算途中で利用された計算因数を表示する計算および計算因数表示部と、
前記クラスタ障害推定手段で用いられる推定基準を変更するための推定基準設定手段と、をさらに有する請求項１記載のクラスタ障害推定システム。
【請求項４】
前記複数の被障害監視ノードは、それぞれ、
当該複数の被障害監視ノードで実行されているアプリケーションの情報を取得して送信するアプリケーション実行状態取得手段をさらに有し、
前記障害監視ノードは、
前記アプリケーション実行状態取得手段から送られてきた情報に基づいて、実行されているアプリケーションの状態が同様なノード群のリストを前記リクエスト停止ノード選択手段に通知するアプリケーション実行状態観察手段をさらに有する請求項１から３のいずれか１項記載のクラスタ障害推定システム。
【請求項５】
前記障害監視ノードは、
前記クラスタ障害推定手段により異常ノードと判定されたノードの中で、実際に障害のあった被障害監視ノードと、障害はなく、誤検知であったノードを分別する異常ノード診断手段と、
前記異常ノード診断手段の出力結果を用いて、前記クラスタ障害推定手段におけるクラスタ障害推定に用いられる推定基準を自動的に変更する推定結果補正手段と、
前記推定結果補正手段における補正情報を格納するための補正情報格納部と、をさらに有する請求項１記載のクラスタ障害推定システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クラスタを構成する複数のノードと、ユーザ端末からのリクエストを各ノードに対して分配する負荷分散装置とから構成されるクラスタシステムにおいて、複数のノードの中から異常の発生しているノードを判定するためのクラスタ障害推定システムに関する。
【背景技術】
【０００２】
近年、コンピュータシステムが様々なサービスの提供のために使用されるようになってきている。そのため、これらのコンピュータシステムの一部の装置に不具合が発生した場合でもシステムダウンすることがないことが要求される。このような要求を満たすため、クラスタ（cluster）システムが利用されている。
【０００３】
クラスタとは、複数の計算機をＬＡＮなどのネットワークによって結合し、一つの大規模な計算機として利用する計算機の利用形態を指す。クラスタシステムで利用される個々の計算機は、ノードと呼ばれる。クラスタシステムでは、ユーザからのリクエストを複数のノードに分散させて処理を行う。
【０００４】
図９に従来のクラスタシステムの構築例を示す。図９に示される従来のクラスタシステムでは、各ノード５６1〜５６NがＬＡＮ５によって接続されることにより、クラスタが構成されている。さらに、クラスタには負荷分散装置５４が接続され、負荷分散装置５４は、ユーザ端末（以下、単にユーザと称する。）１からのリクエスト２を受け取り、そのリクエスト２を各ノード５６1〜５６Nに分配する。リクエストの例としては、ＷＥＢリクエストなどがある。各ノード５６1〜５６Nはリクエスト２の処理結果をレスポンス３として、負荷分散装置５４を経由して、ユーザ１に返却する。クラスタシステムは、パーソナルコンピュータやワークステーションなど、安価な計算機を構成要素としているため、スーパーコンピュータなどの大型計算機と同じ性能を安価に実現することができる。
【０００５】
このようなクラスタシステムでは、複数のノードによりクラスタが構成されるが、このクラスタを構成する複数のノード中のあるノードにウィルス感染等の障害が発生した場合、他のノードへの影響を防ぐために障害が発生したノードをネットワークから切り離す等の処理が必要となる。
【０００６】
このような目的のため、複数のノードを有するクラスタシステムにおいて、クラスタを構成する複数のノードの中から異常の発生しているノードを判定するクラスタ障害推定システムが用いられる。
【０００７】
従来のクラスタ障害推定システムの一例が、特許文献１に記載されている。この特許文献１に記載された従来のクラスタ障害推定システムでは、図１０に示されるように、複数のパーソナルコンピュータ７６がＬＡＮ５によって接続されており、遮断部７１と、ウィルス判定部７２とにより障害の発生したノードの判定および遮断が行われる。
【０００８】
パーソナルコンピュータ７６は、それぞれ、ウィルス監視部６１、監視条件定義ファイル６２、事前登録部６３、測定データファイル６４、資源６５から構成されている。また、この資源６５は、ネットワークリソース６５１、ＣＰＵリソース６５２、入出力リソース（Ｉ／Ｏリソース）６５３とから構成されている。
【０００９】
このような構成を有する従来のクラスタ障害推定システムは下記のように動作する。
【００１０】
すなわち、ユーザは、事前登録部６３によって、監視条件定義ファイル６２に監視条件を入力する。監視条件とは、「ＣＰＵ使用率５０％」というように、監視する資源と閾値の組を表したものである。測定データファイル６４には、ネットワークリソース６５１、ＣＰＵリソース６５２、入出力リソース６５３など各種資源（リソース）６５の使用状況が保存される。ウィルス監視部６１は、測定データファイル６４に格納された測定データが、監視条件定義ファイル６３に登録された監視条件に抵触するかどうかを監視する。測定データが監視条件に抵触した場合、ウィルス監視部６１は、ユーザに対して警告メッセージを出力したり、遮断部７１に対して、当該パーソナルコンピュータ７６をネットワークから切離すよう命令を出す。ウィルス判定部７２は、パーソナルコンピュータ７６から送られてくる定期信号を監視し、定期信号の到着状況を把握することによって、当該パーソナルコンピュータ７６に障害が発生しているかどうかを監視する。
【００１１】
このように、図１０に示した従来の障害推定システムでは、ウィルス監視部６１が、資源６５の使用が急激に増加して監視条件に抵触した場合にウィルスに感染したと判定し、遮断部７１によりウィルスに感染したパーソナルコンピュータ７６をネットワークから遮断するようにしている。
【００１２】
しかし、この図１０に示した従来の障害推定システムでは、ウィルスに感染しているかどうかの監視条件として、使用されている資源量が閾値を超えているかという条件を用いているため、過負荷状態と障害の発生とを区別することができない。そのため、過負荷状態を障害として誤検出してしまう可能性がある。つまり、このような従来のクラスタ障害の推定システムでは、ユーザからの処理要求の増加によりノードが過負荷状態に陥った場合に、例えそのノードが正常な場合であってもウィルスに感染していると誤検出してしまう恐れがある。
【００１３】
さらに、この図１０に示した従来の障害推定システムでは、パーソナルコンピュータ７６という個々のノードが独立して障害を監視している。そのため、例えば、登録された閾値以上のリソースを利用するアプリケーションが実行されると、アプリケーションを実行したことによって、当該ノードはウィルスに感染したものとして、遮断部７１によってネットワークから切離されてしまう。
【００１４】
つまり、何の障害が発生していない場合でも、正常な計算機の振る舞いを障害として誤検出してしまう場合がある。単体のアプリケーションに関わらず、複数のアプリケーションを組み合わせて実行することによって、閾値を超えてしまうような状況は用意に想定できる。
【特許文献１】特開２００５−２５６７９号公報
【発明の開示】
【発明が解決しようとする課題】
【００１５】
上述した従来のクラスタ障害推定システムでは、サーバが過負荷状態になると障害が発生しているものと誤検出してしまったり、正常な計算機の振る舞いを障害として誤検出してしまうことであるという問題点を有していた。
【００１６】
本発明の目的は、複数のノードを有するクラスタシステムにおいて、クラスタを構成する複数のノードの中から異常の発生しているノードのみを正確に検出することができるクラスタ障害推定システムを提供することにある。
【課題を解決するための手段】
【００１７】
上記目的を達成するために、本発明は、クラスタを構成する複数の被障害監視ノードと、ユーザ端末からのリクエストを前記各被障害監視ノードに対して分配する負荷分散装置と、前記複数の被障害監視ノードの中から異常の発生しているノードを検出するための障害監視ノードとから構成されるクラスタ障害推定システムにおいて、
前記複数の被障害監視ノードは、それぞれ、当該被障害監視ノードの資源の利用状況を示す内部情報を詳細情報として取得する詳細情報取得手段を有し、
前記障害監視ノードは、
前記詳細情報を格納するための詳細情報格納手段と、
前記詳細情報取得手段から送られてきた詳細情報を前記詳細情報格納手段に格納する詳細情報管理手段と、
前記複数の被障害監視ノードのうち、リクエストの分配を停止する被障害監視ノードを選定するリクエスト停止ノード選択手段と、
前記リクエスト停止ノード選択手段において選定された被障害監視ノードの詳細情報を前記詳細情報格納手段から取得し、取得した該詳細情報を用いて、複数の被障害監視ノードの中から資源の利用状況が他の被障害監視ノードとは異なるパターンを示す被障害監視ノードを算出する希少ノード計算手段と、
前記希少ノード計算手段によって計算された計算結果を用いて、異常状態にある被詳細監視ノードを検出するクラスタ障害推定手段と、
前記クラスタ障害推定手段により異常が発生していると判定された被障害ノードをネットワークから切り離すノード切離し手段とを有し、
前記負荷分散装置は、
前記リクエスト停止ノード選択手段において選定された被障害監視ノードに対するリクエストの分配を停止するリクエスト停止手段を有することを特徴とする。
【００１８】
本発明によれば、リクエスト停止ノード選択手段により選択された被障害監視ノードへのリクエスト配信を停止して、資源の利用状況を示す詳細情報を取得するようにしているので、リクエストによる過負荷状態においても定常状態での障害判定が行われる。そのため、過負荷状態においても、異常の発生しているノードのみを抽出することができ、計算機の正常な振る舞いを障害として検出することを防ぐことができる。
【００１９】
また、本発明では、リクエストの配信を停止したすべての被障害監視ノードの詳細情報を用いて、他のノードとは資源利用パターンが異なる希少ノードを判定しているために、資源利用の閾値に依存せずに、一定数のノード集合から希少な資源の利用状況を示すノードを異常ノードとして検出することができる。
【発明の効果】
【００２０】
以上説明したように、本発明によれば、下記のような効果を得ることができる。
（１）クラスタを構成する各ノードへのリクエスト分配を一旦停止し、ノードの定常的な状態で資源の利用状況を取得するようにしているので、リクエストの急激な増加による過負荷の影響を受けずに障害を検出することができる。言い換えると、クラスタが過負荷状態に陥っている状態でも、異常の発生しているノードを発見することができる。
（２）各ノードの資源利用パターンから、希な資源利用状況のノードを障害の発生したノードと判定するようにしているので、異常の発生しているノードのみを正確に検出することができる。
【発明を実施するための最良の形態】
【００２１】
次に、本発明の実施の形態について図面を参照して詳細に説明する。
【００２２】
（第１の実施形態）
図１は本発明の第１の実施形態のクラスタ障害推定システムの構成を示すブロック図である。
【００２３】
本実施形態のクラスタ障害推定システムは、図１に示されるように、負荷分散装置４と、被障害監視ノード６と、障害監視ノード８とから構成される。ここでは、説明を簡単に説明するためにクラスタを構成する被障害監視ノード６は１つしか示していないが、実際には複数の被障害監視ノード６が存在する。
【００２４】
障害監視ノード８は、クラスタ内に設置された障害の監視を担当するノードであるが、ある被障害監視ノード６に含まれていても良い。また、負荷分散装置４には、リクエスト停止手段４１が含まれる。さらに、被障害監視ノード６には、詳細情報取得手段６６が含まれる。
【００２５】
そして、障害監視ノード８には、リクエスト停止ノード選択手段８１と、詳細情報管理手段８２と、詳細情報格納部８３と、希少ノード計算手段８４と、クラスタ障害推定手段８５と、クラスタ状態観察手段８７と、ノード切離し手段８６とが含まれる。被障害監視ノード６は図９に示したクラスタシステムおけるノード５６1〜５６Nに該当する。
【００２６】
負荷分散装置４は、ユーザ端末からのリクエストを、各被障害監視ノード６に対して負荷が分散されるように分配する。被障害監視ノード６は、負荷分散装置４から配信されたリクエストに対する処理を行っている。
【００２７】
本実施形態のクラスタ障害推定システムでは、複数の被障害監視ノード６のうちから障害発生の有無を判定する被障害監視ノード６を選定して、選定された被障害監視ノード６に対してリクエストの配信を停止してから障害検出を行う。
【００２８】
リクエスト停止ノード選択手段８１は、クラスタを構成する複数の被障害監視ノード６のうち、リクエストの分配を停止するノード台数を決定し、台数分の被障害監視ノード６をクラスタの中から選定する。台数の決定と被障害監視ノード６の選定は、ランダムで選択したり、設定ファイルに具体的な数値などを記入しておく、もしくはそれらの組み合わせが考えられる。他には、満足すべきレスポンス時間に応じて、台数を決定する方法がある。
【００２９】
リクエスト停止ノード選択手段８１は、リクエストの分配を停止する被障害監視ノード６を選択した後に、負荷分散装置４内のリクエスト停止手段４１に対して選択した被障害監視ノード６のリストと個々の被障害監視ノード６に対するリクエストの分配停止時間を送付する。さらに、リクエスト停止ノード選択手段８１は、希少ノード計算手段８４に対して、リクエストの配信を停止した時刻と、再開時刻を通知する。ここでは、障害監視ノード８と負荷分散装置４は時間の同期が保たれているものとするが、仮に、時間の同期が取れていない場合は、実際に負荷分散装置４がリクエストの分配を停止した時刻を知るために、リクエスト停止手段４１からリクエスト停止ノード選択手段８１に対してリクエストの分配を停止した時刻を送信する。リクエストの分配を再開する時刻は、リクエストの分配を停止した時刻にリクエストの分配停止時間を加算することにより求めることができるので、リクエスト停止手段４１からリクエスト停止ノード選択手段８１に対してリクエストの配信を再開する時刻を送信しなくてもよい。
【００３０】
リクエスト停止手段４１は、リクエスト停止ノード選択手段８１から送られてきた被障害監視ノード６のリストとリクエスト分配停止時間を基に、リストに掲載されている被障害監視ノード６へのリクエストの分配を一定時間停止する。
【００３１】
詳細情報管理手段８２は、被障害監視ノード６中の詳細情報取得手段６６から定期的に送られてくる詳細情報を受け取って、詳細情報格納部８３に格納する。詳細情報を受け取って格納するという詳細情報管理手段８２の処理は、上記、リクエスト停止ノード選択手段８１、リクエスト停止手段４１の処理とは独立して実行される。すなわち、詳細情報管理手段８２は、リクエスト停止ノード選択手段８１の動作に関わらず、定期的に詳細情報取得手段６６から詳細情報を受け取っている。
【００３２】
詳細情報取得手段６６は、被障害監視ノード６の資源の利用状況を示す内部情報を、この内部情報を取得した時刻情報とともに定期的に詳細情報管理手段８２に詳細情報として送信する。ここで内部情報とは、ＣＰＵ使用率や、メモリ使用率、ネットワーク帯域使用量などの内部状態を表す情報である。
【００３３】
希少ノード計算手段は８４、リクエスト停止ノード選択手段８１から、リクエストの配信を停止したノード名と停止した時刻を受け取っている。希少ノード計算手段８４は、この情報を用いて、詳細情報管理手段８２を介して、上記情報に該当する被障害監視ノード６の詳細情報を詳細情報格納部８３から取得する。そして、希少ノード計算手段８４は、取得した詳細情報を用いて、複数の被障害監視ノード６の中から資源の利用状況が他の被障害監視ノード６とは異なるパターンを示す被障害監視ノード６を算出する。希少ノード計算手段８４は、被障害監視ノード６の資源利用パターンに対して順位づけをできる計算手法なら、中央値や平均値、偏差値など、どのような計算を用いてもよい。
【００３４】
ここで、中央値を用いて、被障害監視ノード６からＣＰＵ使用率を取得したときの希少ノードの計算手法を例示する。中央値とは、Ｎ個のデータを小さいほうから並べたときに、中央にくる値のことを指す。被障害監視ノードＡ、Ｂ、Ｃが存在し、それぞれのＣＰＵ使用率が１０％、２０％、６０％という場合は、中央値は、２０％となり、そこからの偏差はそれぞれ、１０％、０％、４０％となる。この場合、希少ノードはＣＰＵ使用率が６０％のノードＣとみなすことができるが、希少ノード計算手段８４は、４０％の偏差を「異常なパターン」かどうか判断せず、希少パターンの判定をするための計算のみを行う。希少ノード計算手段８４は、計算結果をクラスタ障害推定手段８５に渡す。例における計算結果とは、中央値（２０％）と、そこからの偏差（１０％，０％，４０％）の組である。
【００３５】
クラスタ障害推定手段８５は、希少ノード計算手段８４によって計算された計算結果を用いて、異常状態にあるノードを検出する。異常状態の判定には、推定基準表を用いる。図２に推定基準表の例を示す。推定基準表には、資源名と推定基準が記述されている。クラスタ障害推定手段８５は、推定基準に該当するもの（推定基準によって真値がかえされるもの）を正常とみなし、推定基準に該当しないもの（推定基準によって偽値がかえされるもの）を異常とみなす。例では、ＣＰＵ使用率の偏差の組が（１０％，０％，４０％）となっており、推定基準に照らし合わせると、異常ノードはノードＣと断定することができる。異常がみられるノードに対しては、ノード切離し手段８６を実行し、どのノードにも異常が見られない場合は、クラスタ状態観察手段８７を実行する。
【００３６】
クラスタ状態観察手段８７は、クラスタ障害推定手段８５において異常の発生している被障害監視ノード６が検出されなかった場合、詳細情報管理手段８２を介して詳細情報格納部８３に格納されている詳細情報を取得する。そして、クラスタ状態観察手段８７は、取得した詳細情報に基づいて複数の被障害監視ノード６が過負荷状態であるか否かを判定し、複数の被障害監視ノード６が過負荷状態であると判定した場合、詳細情報取得手段６６に対して、詳細情報の取得を一時的に停止するように命令する。なお、詳細情報の取得を停止させる期間は任意である。
【００３７】
ノード切り離し手段８６は、クラスタ障害推定手段８５により異常状態にあると判断されたノードをネットワークから切り離す。
【００３８】
次に、図３のフローチャートを参照して本実施の形態の全体の動作について詳細に説明する。
【００３９】
まず、リクエスト停止ノード選択手段８１は、リクエストの分配を停止するノードを選択し（ステップ１０１）、リクエスト停止手段４１は、選択されたノードに対するリクエストの分配を停止する（ステップ１０２）。次に、希少ノード計算手段８４は、詳細情報格納部８３から詳細情報管理手段８２を経由して、リクエストの分配を停止したノードの詳細情報を取得する（ステップ１０３）。このとき、取得に必要な入力情報は、ノード名と時刻である。詳細情報取得手段６６は、詳細情報管理手段８２に対して定期的に詳細情報を送信している。詳細情報取得手段６６のこの一連の処理は、図３のフローチャートとは独立した処理である。
【００４０】
希少ノード計算手段８４は、詳細情報格納部８３から詳細情報を取り出し、希少ノードを計算する（ステップ１０４）。クラスタ障害推定手段８５は、希少ノード計算手段８４の計算結果を推定基準表と比較することにより異常ノードを推定する（ステップ１０５）。異常ノードが発見された場合（ステップ１０６のＹＥＳ）、ノード切離し手段８６は、異常ノードをネットワークから切離して（ステップ１０７）処理を終了する。異常ノードが発見されなければ（ステップ１０８のＮＯ）、クラスタ状態観察手段８７は、クラスタ障害推定手段８５を実行した時点での詳細情報を詳細情報格納部８３から詳細情報管理手段８２を経由して取得し（ステップ１０８）、クラスタが過負荷状態であれば（ステップ１０９のＹＥＳ）、詳細情報取得手段６６に対して、詳細情報の取得を一時停止するように命令する（ステップ１１０）。過負荷の判定で取得する詳細情報は、どの被障害監視ノード６のものを用いてもよい。なぜなら、クラスタ障害推定手段８５によって、どのノードの資源利用パターンも稀なものはなく、すべてのノードの資源利用パターンが同じであるからである。
【００４１】
本実施形態のクラスタ障害推定システムでは、リクエスト停止ノード選択手段８１により選択された被障害監視ノード６へのリクエスト配信を停止して、詳細情報を取得するようにしているので、リクエストによる過負荷状態においても定常状態での障害判定が行われる。そのため、過負荷状態においても、異常の発生しているノードのみを抽出することができ、計算機の正常な振る舞いを障害として検出することを防ぐことができる。
【００４２】
また、本実施形態のクラスタ障害推定システムでは、リクエストの配信を停止したすべての被障害監視ノード６の詳細情報を用いて、他のノードとは資源利用パターンが異なる希少ノードを判定しているために、資源利用の閾値に依存せずに、一定数のノード集合から希少な資源の利用状況を示すノードを異常ノードとして検出することができる。
【００４３】
各ノードの資源利用パターンの差異から障害が発生しているノードを検出することにより誤検出を不正で異常が発生しているノードのみを正確に検出することができる理由を以下に説明する。
【００４４】
クラスタは、上述したように、ＷＥＢリクエストを処理するために利用されることが多い。ウェブショッピングなど、単一のサイトに到着するＷＥＢリクエストは、商品の表示、商品の選択、購入手続きなど、単調な処理の繰り返しであり、リクエスト毎に、リクエストの処理時間や、ユーザに対する送信情報の内容が大幅に変化することはほとんどない。さらに、クラスタは、負荷分散を効率よく行うために、均一な性能を持つノードを構成要素として使用する。
【００４５】
このように、均一な性能を持つノードが同一処理を繰り返す環境では、各ノードは、同じような資源の利用パターンを示す。同じ処理を行う、同じ性能を持つノードの中で、異質な資源の利用パターンを示すノードが存在するとすれば、そのノードには、何らかの異常があると言わざるを得ない。その結果、各ノードの資源利用状況を比較することによって、異常の発生しているノードのみを抽出し、計算機の正常な振る舞いを障害として誤検知してしまうことを防ぐことができる。
【００４６】
そして、本実施形態のクラスタ障害推定システムでは、障害が発生していると判定されたノードを、ノード切離し手段８６によりネットワークから切離す。また、どのノードの資源利用パターンからも著しい違いは見つけられなかった場合は、異常ノードはなく、すべてのノードが正常に動作しているものとみなす。すべてが正常に動作している場合は、クラスタ状態観察手段８７が、被障害監視ノード６からの詳細情報を再度確認し、クラスタが過負荷であるならば、クラスタの負荷を軽減させるために、詳細情報の取得を一時停止させる。
【００４７】
（第１の実施形態における変形例１）
リクエスト停止手段４１は、負荷分散装置４に設置される他、各被障害監視ノード内に設置してもよい。そのような場合は、リクエスト停止ノード選択手段８１から「リクエストの拒否命令」が各被障害監視ノード６上のリクエスト停止手段に送られてくる。被障害監視ノード６へ負荷分散装置４から送られてくるリクエストは、まずリクエスト停止手段４１によって受け取られる。そして、リクエストの拒否命令をリクエスト停止手段４１が受け取っている場合は、リクエストを処理せず、そのまま放棄する。こうすることによって、負荷分散装置４においてリクエストの分配を停止することと同じ効果を生む。
【００４８】
（第１の実施形態における変形例２）
クラスタ状態観察手段８７を含まない第１の実施形態も構築可能である。このような場合、図３に示されるステップ１０８〜１１０のステップが無くなり、異常ノードが発見されなかった場合は、そのまま処理を終了する。
【００４９】
（第１の実施形態における変形例３）
詳細情報管理手段８２、詳細情報取得手段６６は、図３に示される本実施形態の動作に関連せず、定期的に詳細情報の送受信を行うが、定期的に詳細情報の送受信を行わない手法も存在する。すなわち、リクエスト停止ノード選択手段８１によって、リクエストの分配を停止する被障害監視ノード６を決定した後に、それらの被障害監視ノード６の詳細情報のみを詳細情報取得手段６６から取得する手法である。この方法を用いても、上記で説明した手法をもちいても、効果は変わらない。
【００５０】
（第２の実施形態）
次に、本発明の第２の実施形態のクラスタ障害推定システムについて図面を参照して詳細に説明する。
【００５１】
本発明の第２の実施形態のクラスタ障害推定システムの構成を図４に示す。図４において、図１中の構成要素と同一の構成要素には同一の符号を付し、説明を省略するものとする。
【００５２】
本実施形態のクラスタ障害推定システムは、図４に示されるように、図１に示した第１の実施形態のクラスタ障害推定システムの構成に対して、障害監視ノード８が障害監視ノード２８に置き換えられた構成となっている。
【００５３】
また、本実施形態における障害監視ノード２８は、図１に示した障害監視ノード８に対して、計算および計算因数表示部８９、希少ノード計算手段設定部９０、推定基準設定手段８８が新たに設けられた構成となっている。本発明の第２の実施形態では、希少ノード計算手段８４における計算手法および、クラスタ障害推定手段８５における障害推定基準を動的に変えるための仕組みを提供する。
【００５４】
希少ノード計算手段設定部９０は、希少ノード計算手段８４によって使用される計算方法を変更するための機能を提供する。希少ノード計算手段設定部９０には、現在利用できる計算方法の一覧が表示される。ユーザは、表示された計算方法の一覧から、利用する計算方法を選択する。
【００５５】
計算および計算因数表示部８９は、希少ノード計算手段８４によって使用された計算方法ならびに、計算途中で利用された計算因数（数値）を表示する。計算および計算因数表示部８９は、希少ノード計算手段８４によって利用される個々の計算方法にメタ情報を付加し、その内容を表示する。メタ情報の付加には、ＸＭＬ（eXtensible Markup Language）などの構造化言語を用いるとよい。また、計算および計算因数表示部８９は、計算方法を表示する際に計算途中の情報が必要であれば、計算途中の結果も合わせて表示する。図５に、上記ＣＰＵ使用率の例に対する計算および計算因数表示部８９の表示結果を示す。まず表の最上段に方式名が表示される。次に、計算途中で使用した中央値および、最後に差分の計算方法が表示されている。
【００５６】
推定基準設定手段８８は、クラスタ障害推定手段８５で用いられる推定基準を動的に変更する機能を提供する。ユーザは、計算および計算因数表示部８９によって表示された情報を基に、推定に用いる資源名および推定基準を入力する。推定基準は、希少ノード計算手段８４の計算結果を入力とし、真偽値を出力する計算方法ならどのようなものでも構わない。
【００５７】
本実施形態のクラスタ障害推定システムにより、利用される環境によって、異常ノードを検出するための計算方法、推定基準を動的に変更することができ、異常ノードの検出精度を高めることができる。
【００５８】
（第３の実施形態）
次に、本発明の第３の実施形態のクラスタ障害推定システムについて図面を参照して詳細に説明する。
【００５９】
本発明の第３の実施形態のクラスタ障害推定システムは、障害の有無を調査する被障害監視ノードを選択する際に、実行されているアプリケーションが等しいノードを選択するための機能を付加したものである。
【００６０】
上記で説明した第１および第２の実施形態では、各被障害監視ノードで実行されているアプリケーションの資源の利用パターンを比較し、稀なパターンを持つノードを検出することを特徴の一つとしている。しかし、個々の被障害監視ノードで実行されているアプリケーションが異なっていると、その資源利用パターンも異なる結果を示し、異常パターンの検出が困難となる。よって、本発明の第３の実施形態では、被障害監視ノード上で実行されているアプリケーションの数、種類ともに等しいノードを選択することにより、異常パターンの検出を、第１および第２の実施形態と比較して高めることができる。
【００６１】
本発明の第３の実施形態のクラスタ障害推定システムの構成を図６に示す。図６において、図１中の構成要素と同一の構成要素には同一の符号を付し、説明を省略するものとする。
【００６２】
本実施形態のクラスタ障害推定システムは、図６に示されるように、図１に示した第１の実施形態のクラスタ障害推定システムの構成に対して、障害監視ノード８が障害監視ノード３８に置き換えられ、被障害監視ノード６が被障害監視ノード３６に置き換えられた構成となっている。
【００６３】
本実施形態における障害監視ノード３８は、図１に示した第１の実施形態における障害監視ノード８に対して、アプリケーション実行状態観察手段９１が新たに設けられた構成となっている。
【００６４】
また、本実施形態における被障害監視ノード３６は、図１に示した第１の実施形態における被障害監視ノード６に対して、アプリケーション実行状態取得手段９２が新たに設けられた構成となっている。
【００６５】
アプリケーション実行状態取得手段９２は、アプリケーション実行状態観察手段９１に対して、個々の被障害監視ノード３６上で実行されているアプリケーションの情報を通知する。ここで、アプリケーション実行状態取得手段９２は、実行されているアプリケーション名を最小の情報としてアプリケーション実行状態観察手段９１に通知する。通知間隔は、任意である。アプリケーション実行状態観察手段９１からの要求に応じて送信してもよい。アプリケーション名の取得には、ＵＮＩＸ上であればＰＳコマンドのように既存の手法が利用できる。
【００６６】
アプリケーション実行状態観察手段９１は、アプリケーション実行状態取得手段９２から送られてくる情報に基づいて、被障害監視ノード３６上で実行されているアプリケーションの状態が同様なノード群のリストをリクエスト停止ノード選択手段９１に送信する。具体的には、アプリケーション実行状態観察手段９１は、アプリケーション実行状態取得手段９２から送られてくる情報に基づいて、実行されているアプリケーションの種類、数ができるだけ等しいノードを抽出し、抽出したノードのリストを、リクエスト停止ノード選択手段８１に通知する。アプリケーション実行状態取得手段９２から送られてくる最小の情報は、当該ノード上で実行されているアプリケーション名のリストである。
【００６７】
リクエスト停止ノード選択手段８１は、それらアプリケーション実行状態取得手段９２から送られてくるアプリケーション名のリストを比較して、同種類であり、かつ同数のアプリケーションを実行しているノードを選択する。一方、同種類かつ同数のアプリケーションを実行しているノードが見つからなかった場合は、リクエスト停止ノード選択手段８１は、各ノードの共通点を抽出し、共通となるアプリケーション以外にどれだけ違うアプリケーションを実行しているかをランク付けし、ランク順にノードを選択するようにしてもよい。
【００６８】
例として、ノードＡ（ａ，ｂ，ｃ，ｄ）、ノードＢ（ａ，ｂ，ｃ，ｄ）、ノードＣ（ａ，ｂ，ｃ，ｅ，ｆ）が存在した場合を考える。括弧内の英小文字はアプリケーション名である。この場合、共通アプリケーションは（ａ，ｂ，ｃ）となり、それぞれ、共通アプリケーション以外に実行しているアプリケーションの数は、ノードＡが１、ノードＢが１、ノードＣが２となる。リクエストの配信を停止するノードを２つ選択する場合は、ノードＡとノードＢのリストがリクエスト停止ノード選択手段８１への入力として渡される。例で示した手法にかかわらず、被障害監視ノード３６上で実行されているアプリケーションの種類、数が等しいノードを抽出できる手段があれば、どのような手法を用いてもよい。
【００６９】
本実施形態では、図１に示した第１の実施形態のクラスタ障害推定システムに対して適用した場合を用いて説明しているが、図４に示した第２の実施形態のクラスタ障害推定システムに対しても同様に適用することができるものである。
【００７０】
本実施形態のクラスタ障害推定システムによれば、実行アプリケーションの違いに基づく各被障害監視ノード３６における資源利用パターンの違いを抑制することができ、異常ノードの検出精度を高めることができる。
【００７１】
（第４の実施形態）
次に、本発明の第４の実施形態のクラスタ障害推定システムについて図面を参照して詳細に説明する。
【００７２】
本発明の第４の実施形態のクラスタ障害推定システムの構成を図７に示す。図７において、図１中の構成要素と同一の構成要素には同一の符号を付し、説明を省略するものとする。
【００７３】
本実施形態のクラスタ障害推定システムは、図７に示されるように、図１に示した第１の実施形態のクラスタ障害推定システムの構成に対して、障害監視ノード８が障害監視ノード４８に置き換えられた構成となっている。
【００７４】
本実施形態における障害監視ノード４８は、図１に示した第１の実施形態における障害監視ノード８に対して、異常ノード診断手段９３、推定結果補正手段９６、推定基準設定手段８８、異常ノード入力手段９４、補正情報格納部９５が新たに設けられた構成となっている。
【００７５】
異常ノード診断手段９３は、クラスタ障害推定手段８５によって検出された異常ノードのうち、実際に障害のあったノードを分別する。被障害監視ノード６において、実際に障害があったかどうかの判断は、既存の手法を用いる。すなわち、ウィルスチェッカーなど、既存の障害診断プログラムである。異常ノード診断手段９３で用いられるプログラムは、クラスタ障害推定手段８５の出力である被障害監視ノード６のリストを入力とし、障害が発生している被障害監視ノード６と、発生していないノードのリストを分別して出力とするものなら、どのようなプログラムを用いてもよい。
【００７６】
推定結果補正手段９６は、異常ノード診断手段９３の出力結果を用いて、クラスタ障害推定に用いられる推定基準を自動的に変更する。異常ノード診断手段９３は、障害が発生している被障害監視ノード６と、障害が発生していない被障害監視ノード６を分別してリストとして出力する。そのリストから、検出されたすべての異常ノード中の実際に障害が発生していた被障害監視ノード６の割合を算出し、その割合に従って推定基準を変更する。中央値を用いた希少ノードの計算における推定結果補正手段９６の利用方法を例示する。
【００７７】
ここに、ノードＡ（１０）、ノードＢ（１０）、ノードＣ（１０）、ノードＤ（２０）、ノードＥ（４０）、ノードＦ（５０）が存在している場合を考える。括弧内の数字はＣＰＵ使用率である。まず、中央値は、ＣＰＵの利用率を昇順にソートした場合、真ん中のノードＣ（１０）とノードＤ（２０）の値の平均を取って１５となる。次に、各ノードにおける中央値からの差は、ノードＡ（５）、ノードＢ（５）、ノードＣ（０）、ノードＤ（５）、ノードＥ（２５）、ノードＦ（３５）となる。カッコ内の数値が中央値からの差であり、絶対値で表している。例示におけるここまでの処理が希少ノード計算手段８４による算出結果である。
【００７８】
次にクラスタ障害推定手段８５によって、異常ノードを検出する。クラスタ障害推定手段８５における推定基準として図２で示した推定基準表を利用すると、「ＣＰＵ使用率を入力として利用した場合は、中央値からの差が１０以下を正常」としている。先ほど計算した結果を照らし合わせると、クラスタ障害推定手段８５によって検出される異常ノードは、ノードＥとノードＦとなる。
【００７９】
ここで、異常ノード診断手段９３が、ノードＦに本当の障害が発生していると診断した場合を考える。このような場合は、障害ノードが、ノードＦ、非障害ノードがノードＥとなり、実際に障害の発生している割合は５０％（全異常ノード２、障害ノード１）となる。このことから、全異常ノードの中央値からの差を昇順にソート（２５，３５）し、先頭から５０％のノード中において、中央値からの最大差を持つノードはノードＥとなり、その偏差は２５となる。
【００８０】
この偏差２５を、希少ノード計算手段８４で計算した中央値に足して、足した値を補正値とする。この補正値を使って、希少ノード計算手段８４とクラスタ障害推定手段８５を実行すると、例で示した６台のノード中で、異常ノードとして検出されるのは、ノードＦだけであり、異常ノードの検出精度が高められたと言える。
【００８１】
異常ノード入力手段９４は、異常ノード診断手段９３において、障害の発生している被障害監視ノード６と発生していない被障害監視ノード６が分別困難な場合に、ユーザによる入力を可能とする機能を提供する。異常ノード入力手段９４は、第４の実施形態における必須機能ではない。
【００８２】
本発明は、各被障害監視ノード６における資源の利用パターンを比較することによって、資源の利用パターンが他のノードとは異なる「稀」なパターンを示すノードを異常ノードとみなしている。本発明で検出される異常ノードが、既知のウィルスであれば、ウィルスチェッカーなど、既存の方法で障害発生の正誤を判定することができるが、未知のウィルスなど、今までに無かった障害を異常ノードとして検出した場合には、既存のウィルスチェッカーや、その他の異常ノード診断手段９３によって、障害の有無を確認することが出来ない場合がある。そのような場合には、ユーザによって異常ノードの検査を行い、異常ノード入力手段９４を利用して、検査結果を入力できるようにする。
【００８３】
補正情報格納部９５は、推定結果補正手段９６によって計算された補正値を格納するために利用される。補正値格納部９５は、リクエスト停止ノードと補正値を一つの組として保存する。図８に補正情報格納部９５の例を示す。クラスタ障害推定手段８５が、同じノードリストを使って、クラスタ障害を推定する場合は、補正情報格納部９５に格納されている補正値を用いて推定する。
【００８４】
本実施形態のクラスタ障害推定システムは、クラスタ障害推定手段８５により、異常ノードと判定されたノードの中で、実際に障害のあった被障害監視ノードと、障害はなく、誤検知であった被障害監視ノードを分別し、異常ノードの全検出結果中における誤検知の割合によって、推定基準表に含まれる推定基準を自動的に調節する機能を提供する。これによって、異常ノードの検出回数を重ねる度に、検出精度を自動的に向上させることができる。
【図面の簡単な説明】
【００８５】
【図１】本発明における第１の発明を実施するための最良の形態の構成を示すブロック図である。
【図２】本発明における第１の発明を実施する際に利用される推定基準表を表す図である。
【図３】本発明における第１の発明を実施するための最良の形態の動作を示す流れ図である。
【図４】第２の発明を実施するための最良の形態の構成を示すブロック図である。
【図５】第２の発明を実施する際に利用される計算および計算因数表示部８９を示す図である。
【図６】第３の発明を実施するための最良の形態の構成を示すブロック図である。
【図７】第４の発明を実施するための最良の形態の構成を示すブロック図である。
【図８】第４の発明を実施する際に利用される補正情報格納部９５を示す図である。
【図９】従来技術を用いて構築された、一般的なクラスタ構成図である。
【図１０】本発明に関連する従来特許を説明するブロック図である。
【符号の説明】
【００８６】
１    ユーザ（端末）
２    リクエスト
３    レスポンス
４    負荷分散装置
５    ＬＡＮ
６    被障害監視ノード
８    障害監視ノード
３６    被障害監視ノード
３８    障害監視ノード
４１    リクエスト停止手段
４８    障害監視ノード
５４    負荷分散装置
５６1〜５６N    ノード
６１    ウィルス監視部
６２    監視条件定義ファイル
６３    事前登録部
６４    測定データファイル
６５    資源
６６    詳細情報取得手段
７１    遮断部
７２    ウィルス判定部
７６    パーソナルコンピュータ
８１    リクエスト停止ノード選択手段
８２    詳細情報管理手段
８３    詳細情報格納部
８４    希少ノード計算手段
８５    クラスタ障害推定手段
８６    ノード切離し手段
８７    クラスタ状態観察手段
８８    推定基準設定手段
８９    計算および計算因数表示部
９０    希少ノード計算手段設定部
９１    アプリケーション実行状態観察手段
９２    アプリケーション実行状態取得手段
９３    異常ノード診断手段
９４    異常ノード入力手段
９５    補正情報格納部
９６    推定結果補正手段
１０１〜１１０    ステップ
６５１    ネットワークリソース
６５２    ＣＰＵリソース
６５３    入出力リソース
８５１    推定基準表
【図１】
0004725724.tif 000002
【図２】
0004725724.tif 000003
【図３】
0004725724.tif 000004
【図４】
0004725724.tif 000005
【図５】
0004725724.tif 000006
【図６】
0004725724.tif 000007
【図７】
0004725724.tif 000008
【図８】
0004725724.tif 000009
【図９】
0004725724.tif 000010
【図１０】
0004725724.tif 000011