(57)【要約】【課題】監視対象サーバで障害が発生した場合に、固定的な優先順位に因らずに、複数の障害通知サーバの中から当該障害発生を通知する障害通知サーバを選択することである。【解決手段】本発明による障害通知方式では、少なくとも一つの監視対象サーバ１３〜１５と、前記監視対象サーバ１３〜１５を監視する複数の障害通知サーバ１０〜１２とを具備する。さらに、ある監視対象サーバで障害が発生した場合に、当該障害発生を通知する障害通知サーバを選択するための指標となる所定の評価値を求めて、評価が最も高い障害通知サーバを、前記障害発生を通知する障害通知サーバと判定する評価値判定部を具備する。【選択図】図１
2008257288.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも一つの監視対象サーバと、
前記監視対象サーバを監視する複数の障害通知サーバと、
前記複数の障害通知サーバにおける全部の障害通知サーバに、又は、前記複数の障害通知サーバにおける一部の障害通知サーバに、若しくは、前記複数の障害通知サーバとは別のコンピュータに設けられ、ある監視対象サーバで障害が発生した場合に、当該障害発生を通知する障害通知サーバを選択するための指標となる所定の評価値を求めて、評価が最も高い障害通知サーバを、前記障害発生を通知する障害通知サーバと判定する評価値判定部と
を具備する障害通知方式。
【請求項２】
前記少なくとも一つの監視対象サーバと、前記複数の障害通知サーバとで共用される共有リソースの使用状況を記録する共有リソース管理テーブルを更に具備し、
前記評価値判定部は、
前記所定の評価値を、前記使用状況に基づいて求める
請求項１記載の障害通知方式。
【請求項３】
前記複数の障害通知サーバにおける負荷状況を記録する負荷率テーブルを更に具備し、
前記評価値判定部は、
前記所定の評価値を、前記使用状況に予め決められた第一の演算を施した第一の値と、前記負荷状況に予め決められた第二の演算を施した第二の値とに基づいて求める
請求項２記載の障害通知方式。
【請求項４】
一つ又は二以上の他の障害通知サーバがある場合には、当該他の障害通知サーバと共に、少なくとも一つの監視対象サーバを監視し、ある監視対象サーバで障害が発生したときには、当該障害発生を通知する障害通知サーバが、自サーバであるか否かを判定する障害通知サーバであって、
ある監視対象サーバで障害が発生した場合に、当該障害発生を通知する障害通知サーバを選択するための指標となる所定の評価値を求めて、自サーバの評価が最も高い場合に、自サーバが前記障害発生を通知する障害通知サーバであると判定する評価値判定部
を具備する障害通知サーバ。
【請求項５】
前記少なくとも一つの監視対象サーバと、前記一つ又は二以上の他の障害通知サーバと、自サーバとで共用される共有リソースの使用状況を記録する共有リソース管理テーブルと、
前記一つ又は二以上の他の障害通知サーバ及び自サーバにおける各負荷状況を記録する負荷率テーブルとを更に具備し、
前記評価値判定部は、
前記所定の評価値を、前記使用状況に予め決められた第一の演算を施した第一の値と、前記負荷状況に予め決められた第二の演算を施した第二の値とに基づいて求める
請求項４記載の障害通知サーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、障害通知方式、障害通知サーバに関する。
【背景技術】
【０００２】
監視対象サーバを監視し、障害を検出したときに、障害通知を行う障害通知サーバが存在する。従来、複数の障害通知サーバで監視対象サーバを監視する場合、障害通知サーバに優先順位を付与し、この優先順位を固定していた。優先順位が最も高い障害通知サーバがダウンした時には、次点の障害通知サーバが、障害通知を行う役割りを引き継ぐという方式がとられていた。
【０００３】
この方式では、最優先の障害通知サーバが活きているものの、負荷が極めて高い状態であると、死活監視にはかろうじて”活き”と応答するために、次点サーバが障害通知作業を引き継ぐことは無い。しかし、監視対象サーバに障害が発生し、最優先の障害通知サーバに障害通知作業の負荷が加わると、障害通知作業が遅延して障害発生時から大幅に遅れて障害通知が届く恐れがあった。また、最悪の場合には、障害通知中に、最優先の障害通知サーバがダウンしてしまうという恐れがあった。
【０００４】
また、障害通知サーバと、監視対象サーバとで、ディスク装置等のリソースを共有している場合がある。このとき、監視対象サーバで障害が発生すると、リソースの共有に起因して、監視対象サーバの障害が障害通知サーバへと波及してしまい、障害通知作業中に、障害通知サーバの動作が停止するなどの支障が生じる問題があった。
【０００５】
特開２００１−２９０６７６号公報には、「通報方式」の発明が記載されている。この発明は、複数の被監視装置とこれらを監視する複数の監視装置とを含むシステムにおける通報方式である。前記被監視装置においては、通報先リスト取得手段は、予め決められた通報要因が発生した際の通報先を保持する通報先リストを第１の通報先の監視装置に要求して取得する。通報を実行する手段は、前記通報要因が発生した際に前記通報先リストを参照して通報を実行する。前記監視装置においては、通報先リスト提供手段は、前記通報先リストの取得要求を受けると、自身で保持する通報先リストの先頭に第１の通報先として自身のアドレスを追加してこれを前記被監視装置へ提供する。
【０００６】
特開２００３−５１８２２号公報には、「ネットワーク監視システム」の発明が記載されている。このネットワーク監視システムでは、複数の監視装置が、ネットワークを介して複数の被監視装置を監視する。
【０００７】
であって、前記被監視装置においては、被監視制御手段は、前記複数の監視装置の中から、監視を任せる監視装置を決定する。監視情報送信手段は、前記被監視制御手段により決定された監視装置に、前記ネットワークを介して監視情報をヘルスチェック信号により送信する。前記監視装置においては、監視情報データベースは、前記監視情報送信手段により送信された監視情報を記憶する。監視情報蓄積手段は、前記監視情報データベースに前記監視情報送信手段により送信された監視情報を蓄積する。監視状態管理データベースは、前記被監視装置の監視の開始と終了と該被監視装置の状態とを記憶する。監視制御手段は、前記監視情報送信手段により送信された監視情報により、前記監視状態管理データベースを逐次制御して前記被監視装置の状態を管理する。
【０００８】
特開２００５−９９９６６号公報には、「業務システム分散監視方法」の発明が記載されている。この業務システム分散監視方法は、複数の業務システムの稼動監視を複数の端末で行う。該複数の端末ユーザを監視対象となる業務システム毎にグループ分けする。該ユーザグループを対象システムの管理者グループとして設定する。前記ユーザの端末に稼動監視プログラムを備える。端末画面に稼動状況を表示する手段を備える。該表示により稼動状況を監視する。
【０００９】
【特許文献１】特開２００１−２９０６７６号公報
【特許文献２】特開２００３−５１８２２号公報
【特許文献３】特開２００５−９９９６６号公報
【発明の開示】
【発明が解決しようとする課題】
【００１０】
本発明の課題は、監視対象サーバで障害が発生した場合に、固定的な優先順位に因らずに、複数の障害通知サーバの中から当該障害発生を通知する障害通知サーバを選択することである。本発明の他の課題は、当該障害発生を通知するのに最も適した障害通知サーバを選択することである。
【課題を解決するための手段】
【００１１】
以下に、［発明を実施するための最良の形態］で使用される番号・符号を用いて、［課題を解決するための手段］を説明する。これらの番号・符号は、［特許請求の範囲］の記載と［発明を実施するための最良の形態］との対応関係を明らかにするために括弧付きで付加されたものである。ただし、それらの番号・符号を、［特許請求の範囲］に記載されている発明の技術的範囲の解釈に用いてはならない。
【００１２】
本発明による障害通知方式においては、少なくとも一つの監視対象サーバ（１３〜１５）を有する。複数の障害通知サーバ（１０〜１２）は、前記監視対象サーバ（１３〜１５）を監視する。評価値判定部（２２）は、前記複数の障害通知サーバ（１０〜１２）における全部の障害通知サーバに、又は、前記複数の障害通知サーバ（１０〜１２）における一部の障害通知サーバに、若しくは、前記複数の障害通知サーバ（１０〜１２）とは別のコンピュータに設けられる。この評価値判定部（２２）は、ある監視対象サーバ（１３〜１５）で障害が発生した場合に、当該障害発生を通知する障害通知サーバを選択するための指標となる所定の評価値を求めて、評価が最も高い障害通知サーバを、前記障害発生を通知する障害通知サーバと判定する。
【００１３】
本発明による障害通知方式においては、前記少なくとも一つの監視対象サーバ（１３〜１５）と、前記複数の障害通知サーバ（１０〜１２）とで共用される共有リソース（３０，３１）の使用状況を記録する共有リソース管理テーブル（２０）を更に具備する。前記評価値判定部（２２）は、前記所定の評価値を、前記使用状況に基づいて求める。本発明による障害通知方式においては、前記複数の障害通知サーバ（１０〜１２）における負荷状況を記録する負荷率テーブル（２１）を更に具備する。前記評価値判定部（２２）は、前記所定の評価値を、前記使用状況に予め決められた第一の演算を施した第一の値と、前記負荷状況に予め決められた第二の演算を施した第二の値とに基づいて求める。
【００１４】
本発明による障害通知サーバ（１０）は、一つ又は二以上の他の障害通知サーバ（１１，１２）がある場合には、当該他の障害通知サーバ（１１，１２）と共に、少なくとも一つの監視対象サーバ（１３〜１５）を監視し、ある監視対象サーバ（１３）で障害が発生したときには、当該障害発生を通知する障害通知サーバが、自サーバであるか否かを判定する。評価値判定部（２２）は、ある監視対象サーバ（１３）で障害が発生した場合に、当該障害発生を通知する障害通知サーバを選択するための指標となる所定の評価値を求めて、自サーバの評価が最も高い場合に、自サーバが前記障害発生を通知する障害通知サーバであると判定する。
【００１５】
本発明による障害通知サーバにおいては、前記少なくとも一つの監視対象サーバ（１３〜１５）と、前記一つ又は二以上の他の障害通知サーバ（１１，１２）と、自サーバ（１０）とで共用される共有リソース（３０，３１）の使用状況を記録する共有リソース管理テーブル（２０）と、前記一つ又は二以上の他の障害通知サーバ（１１，１２）及び自サーバ（１０）における各負荷状況を記録する負荷率テーブル（２１）とを更に具備する。前記評価値判定部（２２）は、前記所定の評価値を、前記使用状況に予め決められた第一の演算を施した第一の値と、前記負荷状況に予め決められた第二の演算を施した第二の値とに基づいて求める。
【発明の効果】
【００１６】
本発明によれば、監視対象サーバで障害が発生した場合に、固定的な優先順位に因らずに、複数の障害通知サーバの中から当該障害発生を通知する障害通知サーバを選択することができる。また、当該障害発生を通知するのに最も適した障害通知サーバを選択することができる。
【発明を実施するための最良の形態】
【００１７】
図１を参照すると、本実施の形態におけるサーバ群が示されている。図１において、サーバ群は、ブロックで明示されている障害通知サーバ１０〜１２と、その他の多数の障害通知サーバと、ブロックで明示されている監視対象サーバ１３〜１５と、その他の多数の監視対象サーバとを含む。説明を簡素化するために、以下、サーバ１０〜１５のみが存在するものとする。すなわち、障害通知サーバ１０は、障害通知サーバ１１，１２と相互に接続されると共に、監視対象サーバ１３〜１５に接続されている。障害通知サーバ１１は、障害通知サーバ１０，１２と相互に接続されると共に、監視対象サーバ１３〜１５に接続されている。障害通知サーバ１２は、障害通知サーバ１０，１１と相互に接続されると共に、監視対象サーバ１３〜１５に接続されている。
【００１８】
図２に、障害通知サーバ１０のブロック説明図を示す。図２では、障害通知サーバ１０のみを図示しているが、その他の障害通知サーバ１１，１２も同様のブロック構成を有している。図示するように、障害通知サーバ１０は、共有リソース管理テーブル２０と、負荷率テーブル２１と、評価値判定部２２と、障害情報採取部２３とを含んで構成されている。
【００１９】
共有リソース管理テーブル２０は、サーバ１０〜１５が共用する共有リソースの使用状況を記録する。監視対象サーバ１３〜１５は、共有リソースの使用状況に変更が生じた場合には、障害通知サーバ１０〜１２に通知する。該通知を受ける障害通知サーバ１０は、共有リソース管理テーブル２０の内容を更新する。
【００２０】
負荷率テーブル２１は、障害通知サーバ１０〜１２の負荷率を記録する。障害通知サーバ１１，１２は、一定時間ごとに、そのＣＰＵ／メモリ／ディスク等の負荷率を、障害通知サーバ１０に通知する。他障害通知サーバ１１，１２から負荷率情報を通知されると、障害通知サーバ１０は、自サーバ１０の負荷率を負荷率テーブル２１に記録すると共に、当該通知された他障害通知サーバ１１，１２の負荷率を負荷率テーブル２１に記録する。
【００２１】
評価値判定部２２は、いずれかの監視対象サーバ１３〜１５で障害が発生した場合に、全障害通知サーバ１０〜１２の評価値を算出して、自障害通知サーバ１０の評価が、全障害通知サーバ１０〜１２の中で最高であるかどうかを判定する。評価値は、リソースの共有状況、および、負荷率に基づいて計算される。ここで、リソースの共有状況は、障害が発生した監視対象サーバと、各障害通知サーバ１０〜１２との間のリソースの共有状況であり、共有リソース管理テーブル２０を参照することにより得られるものである。また、負荷率は、負荷率テーブル２１を参照することにより得られるものである。評価値判定部２２は、リソースの共有状況、および、負荷率に基づき、予め決められた重み付けにより、評価値を算出する。
【００２２】
障害情報採取部２３は、自障害通知サーバ１０の評価が全障害通知サーバ１０〜１２の中で最高であった場合に、障害が発生した監視対象サーバより障害情報を採取して、当該障害の発生をサーバ管理者に通知する。
【００２３】
図３〜５に、具体的な実施の形態を示す。図１では、サーバ間は個別に接続が行われているように示したが、これは例えばＬＡＮ（Local  Area  Network）といった接続形態も可能である。図３では、ＬＡＮ接続が行われている。図３を参照すると、ＬＡＮ５０によって、障害通知サーバ１０〜１２と、監視対象サーバ１３〜１５とが相互に接続されている。また、図３には、二つの共有リソース３０，３１が図示されている。図中、点線で示されるように、障害通知サーバ１０は、二つの共有リソース３０，３１を使用している。また、障害通知サーバ１１は共有リソース３１のみを、監視対象サーバ１３は、二つの共有リソース３０，３１を使用している。障害通知サーバ１２と、二つの監視対象サーバ１４，１５とは、共有リソース３０，３１を使用していない。
【００２４】
図４は、共有リソース管理テーブル２０の詳細説明図である。図４において、共有リソース管理テーブル２０は、縦軸に各共有リソース、横軸に各サーバを並べた表形式で表現されている。サーバがある共有リソースを使用している場合には、該当する欄に“１”をセットし、使用していない場合には、“０”をセットする。セットすべき値は、“１”、“０”以外を用いてももちろん構わない。図４では、共有リソース３０は、サーバ１０と、サーバ１３とによって共有され、共有リソース３１は、サーバ１０と、サーバ１１と、サーバ１３とによって共有されていることがわかる。
【００２５】
図５は、負荷率テーブル２１の詳細説明図である。図示するように、負荷率テーブル２１は、各障害通知サーバ１０〜１２の負荷率を保持している。図５において、障害通知サーバ１０は、２０％の負荷率で稼動している。また、障害通知サーバ１１は、３０％の負荷率で、障害通知サーバ１２は、６０％の負荷率で稼動している。
【００２６】
次に、図３〜５に示した具体的な実施の形態における障害通知サーバ１０の動作について説明する。障害通知サーバ１０は、他の障害通知サーバ１１，１２と共に、監視対象サーバ１３〜１５が出力しているログ情報を常時監視する。そして、監視対象サーバ１３〜１５の障害発生の有無をチェックする。ここで、監視対象サーバ１３で障害が発生したとする。この監視対象サーバ１３の障害は、障害通知サーバ１０にて検出される。障害通知サーバ１０の評価値判定部２２は、共有リソース管理テーブル２０を参照して、監視対象サーバ１３と各障害通知サーバ１０〜１２との間で共有されているリソースの数を取得する。同時に、評価値判定部２２は、負荷率テーブル２１を参照して、各障害通知サーバ１０〜１２の負荷率を取得する。そして、予め決められた重み付けにより、全障害通知サーバ１０〜１２の評価値を算出する。
【００２７】
図４に示すように、監視対象サーバ１３と、障害通知サーバ１０との共有リソース数は、”２”である。また、監視対象サーバ１３と、障害通知サーバ１１との共有リソース数は、”１”であり、監視対象サーバ１３と、障害通知サーバ１２との共有リソース数は、”０”である。また、図５に示すように、障害通知サーバ１０の負荷率は２０％であり、障害通知サーバ１１の負荷率は３０％であり、障害通知サーバ１２の負荷率は６０％である。ここで、共有リソース数の重み付けを、”１．５”とし、負荷率の重み付けを”０．１”とする。
【００２８】
このとき、障害通知サーバ１０の評価値判定部２２は、以下のように各障害通知サーバ１０〜１２の評価値を算出する。
【００２９】
障害通知サーバ１０  ：  ２×１．５＋２０×０．１＝５
障害通知サーバ１１  ：  １×１．５＋３０×０．１＝４．５
障害通知サーバ１２  ：  ０×１．５＋６０×０．１＝６
【００３０】
評価値判定部２２は、算出された評価値がもっとも小さなものに対して最高の評価を与える。最も小さい評価値は、”４．５”であるから、最高の評価を有する障害通知サーバは、障害通知サーバ１１となる。従って、障害通知サーバ１０の障害情報採取部２３は、監視対象サーバ１３から障害情報を採取すること、及び、サーバ管理者へ監視対象サーバ１３の障害を通知することを行わない。
【００３１】
障害通知サーバ１１においても、評価値判定部が、同様に、各障害通知サーバ１０〜１２の評価値を計算している。この計算の結果、障害通知を行うサーバは、自サーバ１１であると判定している。評価が最も高い障害通知サーバ１１においては、障害情報採取部が、障害が発生した監視対象サーバ１３より障害情報を採取し、サーバ管理者へと通知する。図１に示したようなイメージにより、障害通知サーバ１１から、障害通知が行なわれる。
【００３２】
上記実施の形態では、全ての障害通知サーバが、共有リソース管理テーブル、負荷率テーブル、及び、評価値判定部を持つとした。しかし、一つの障害通知サーバのみが、共有リソース管理テーブル、負荷率テーブル、及び、評価値判定部を持つこととし、その他の障害通知サーバは、共有リソース管理テーブル、負荷率テーブル、及び、評価値判定部を持たないこととすることもできる。いずれかの監視対象サーバで障害が発生した場合には、前記一つの障害通知サーバの評価値判定部が、全ての障害通知サーバの評価値を求めて、最も高い評価を有する障害通知サーバに対して、その旨を通知しても良い。
【００３３】
さらに、全ての障害通知サーバが、共有リソース管理テーブル、負荷率テーブル、及び、評価値判定部を持たないこととし、別途、これらを有する選択サーバを設けることもできる。いずれかの監視対象サーバで障害が発生した場合には、各障害通知サーバが、選択サーバに問い合わせを行う。選択サーバの評価値判定部は、共有リソース管理テーブル及び負荷率テーブルを参照し、全ての障害通知サーバの評価値を求める。そして、問い合わせをした障害通知サーバが最も高い評価を有する障害通知サーバであるか否かを返答するようにしても良い。
【００３４】
以上説明したように、本実施の形態によれば、障害発生情報をスムーズに管理者へ通知できる障害通知サーバを選択することができる。その理由は、各障害通知サーバの負荷状態と、サーバ群の構成情報から得られるサーバ間のリソースの共有状況とを、それぞれ重み付けして求めた評価値によって、障害発生通知を行うサーバを決定しているためである。
【図面の簡単な説明】
【００３５】
【図１】図１は、本実施の形態におけるサーバ群を示す図である。
【図２】図２は、障害通知サーバ１０のブロック説明図である。
【図３】図３は、ＬＡＮ接続が行われている具体的な実施の形態を示す図である。
【図４】図４は、共有リソース管理テーブル２０の詳細説明図である。
【図５】図５は、負荷率テーブル２１の詳細説明図である。
【符号の説明】
【００３６】
１０〜１２  障害通知サーバ
１３〜１５  監視対象サーバ
２０  共有リソース管理テーブル
２１  負荷率テーブル
２２  評価値判定部
２３  障害情報採取部
３０，３１  共有リソース
５０  ＬＡＮ
【図１】
2008257288.tif 000003
【図２】
2008257288.tif 000004
【図３】
2008257288.tif 000005
【図４】
2008257288.tif 000006
【図５】
2008257288.tif 000007