JP2015106357A

JP2015106357A - サーバ監視方法およびサーバ監視システム

Info

Publication number: JP2015106357A
Application number: JP2013249326A
Authority: JP
Inventors: 裕介桐栄; Yusuke Toei; 勲大西; Isao Onishi; 成剛松崎; Naritake Matsuzaki; 昌男稗田; Masao Hieda; 陽一郎中川; Yoichiro Nakagawa; 正一岡部; Shoichi Okabe
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2013-12-02
Filing date: 2013-12-02
Publication date: 2015-06-08
Anticipated expiration: 2033-12-02
Also published as: JP6073211B2

Abstract

【課題】クラスタ構成のサーバシステムにおける無応答障害を的確に検知可能とする。
【解決手段】クラスタ構成のサーバシステム２０が含む第１のサーバ１００において、当該第１のサーバ１００がアクセする第２のサーバ２００に対し、所定応答を要求する電文を送信し、この電文の送信時点からの経過時間を計測する処理と、電文の送信に応じて第２のサーバ２００から所定応答を受信するまでの経過時間が、第１の基準時間を越えた第１事象を電文の送信毎に監視し、当該第１事象の連続発生回数が所定基準回数を超えた場合に、第２のサーバ２００がスローダウン状態にある旨を所定端末４００に通知する処理と、電文の送信時点から、第１の基準時間以上の第２の基準時間内に、第２のサーバ２００から所定応答を受信出来なかった第２事象を電文の送信毎に監視し、当該第２事象の発生を検知した場合に、第２のサーバ２００がハングアップ状態にある旨を所定端末４００に通知する処理を実行する。
【選択図】図１

Description

本発明は、サーバ監視方法およびサーバ監視システムに関するものであり、具体的には、クラスタ構成のサーバシステムにおける無応答障害を的確に検知可能とする技術に関する。

金融機関等の運営するコンピュータシステムは、その重要性から見て、安易なシステムダウンが許容されないミッションクリティカルなシステムであることが多い。従って、そうしたコンピュータシステムにおいては、優れた耐障害性や迅速かつ的確な障害時対応が高いレベルで要求されることになる。そこで、障害発生を監視して、その後の対応を早急に行う為の各種技術が従来から提案されている。

このような技術としては、例えば以下のようなものが提案されている。すなわち、ステータスデータベースと、被監視デバイスと第１の接続を確立し、前記被監視デバイスからステータス項目を受信し、前記ステータス項目を前記ステータスデータベースに保存するステータスコレクタと、リモートデバイスとの間のインタフェースと、前記被監視デバイスと第３の接続を確立し、コマンドを前記被監視デバイスに送信するコマンドディスパッチャとを含むシステム（特許文献１参照）などである。

特表２０１０−５３７５６３号公報

一方、上述のようなコンピュータシステムにおいて、ＨＡ（High Availability）クラスタ等により各種サーバ類の現用・待機構成を組むことで、無応答障害（ハングやスローダウン）を検知することができないケースが多く生じる。こうした状況下では、障害発生検知に伴う待機ノードへの切替え動作は実行されず、そのままサービス停止につながる場合が多い。ミッションクリティカルなコンピュータシステムにおける、少なくないサービス停止の懸念は大きな問題であり、システムでの無応答障害を的確に検知し、障害発生以降の復旧作業を迅速に実施出来る環境を整えておく必要がある。

そこで本発明の目的は、クラスタ構成のサーバシステムにおける無応答障害を的確に検知可能とする技術を提供することにある。

上記課題を解決する本発明のサーバ監視方法は、クラスタ構成のサーバシステムが含む第１のサーバにおいて、当該第１のサーバがアクセする第２のサーバに対し、所定応答を要求する電文を送信し、前記電文の送信時点からの経過時間を計測する処理と、前記電文の送信に応じて前記第２のサーバから所定応答を受信するまでの経過時間が、第１の基準時間を越えた第１事象を、前記電文の送信毎に監視し、当該第１事象の連続発生回数が所定基準回数を超えた場合に、前記第２のサーバがスローダウン状態にある旨を所定端末に通知する処理と、前記電文の送信時点から、前記第１の基準時間以上の第２の基準時間内に、前記第２のサーバから所定応答を受信出来なかった第２事象を、前記電文の送信毎に監視し、当該第２事象の発生を検知した場合に、前記第２のサーバがハングアップ状態にある旨を所定端末に通知する処理と、を実行することを特徴とする。

また、本発明のサーバ監視システムは、クラスタ構成のサーバシステムが含む第１のサーバにおいて、当該第１のサーバがアクセする第２のサーバに対し、所定応答を要求する電文を送信し、前記電文の送信時点からの経過時間を計測する処理と、前記電文の送信に応じて前記第２のサーバから所定応答を受信するまでの経過時間が、第１の基準時間を越えた第１事象を、前記電文の送信毎に監視し、当該第１事象の連続発生回数が所定基準回数を超えた場合に、前記第２のサーバがスローダウン状態にある旨を所定端末に通知する処理と、前記電文の送信時点から、前記第１の基準時間以上の第２の基準時間内に、前記第２のサーバから所定応答を受信出来なかった第２事象を、前記電文の送信毎に監視し、当該第２事象の発生を検知した場合に、前記第２のサーバがハングアップ状態にある旨を所定端末に通知する処理を実行する演算装置を備える構成とする、ことを特徴とする。

本発明によれば、クラスタ構成のサーバシステムにおける無応答障害を的確に検知することが可能となる。

本実施形態のサーバ監視システムを含むネットワーク構成図である。本実施形態におけるＡＰサーバのハードウェア構成例を示す図である。本実施形態におけるＤＢサーバのハードウェア構成例を示す図である。本実施形態における監視コンソールのハードウェア構成例を示す図である。本実施形態のヘルスチェック用テーブルの構成例を示す図である。本実施形態におけるサーバ監視方法の処理手順例を示すフロー図である。本実施形態における監視概念例を示す説明図である。

−−−システム構成−−−
以下に本発明の実施形態について図面を用いて詳細に説明する。図１は、本実施形態のサーバ監視システム１０を含むネットワーク構成図である。図１に示すサーバ監視システム１０は、クラスタ構成のサーバシステム２０における無応答障害を的確に検知可能とするコンピュータシステムである。本実施形態において想定するクラスタ構成のサーバシステム２０としては、一例として金融機関で運用されている基幹システムを想定する。従って、本実施形態のサーバ監視システム１０は、金融機関における基幹システムにおける無応答障害の監視を行うシステムとなる。勿論、サーバ監視システム１０における無応答障害の監視対象は金融機関におけるシステムに限定されず、他業界における各種のサーバシステム（クラスタ構成）に適用可能である。

図１に例示するサーバシステム２０は、金融機関の顧客端末等と接続された外部ネットワーク１２０に、ファイヤウォール２１を介して接続されている。また、サーバシステム２０は、上述のファイヤウォール２１を経て顧客端末から受けた処理要求を、負荷分散装置３００にてＡＰサーバ１００に向けて振り分け処理する。当該サーバシステム２０におけるサーバ装置のクラスタ構成は、上述の負荷分散装置３００による処理要求振り分け先となる２台のＡＰサーバ１００Ａ、１００Ｂと、これらＡＰサーバ１００Ａ、１００Ｂと対応付けされ、ＡＰサーバ１００Ａ、１００Ｂらによるデータの取得や書込の対象となる１台のＤＢサーバ２００とが、現用系と待機系の２系統備わっている構成となる。待機系のＡＰサーバ１００として、参考のためにＡＰサーバ１００Ｃ、１００Ｄも図１にて示している。

なお、図１における２台のＡＰサーバ１００Ａ、１００Ｂは本発明における第１のサーバに対応する。以降の説明において、これら２台のＡＰサーバ１００Ａ、１００Ｂを区別せず、第１のサーバとして説明を行う場合にはＡＰサーバ１００と示すものとする。また、ＤＢサーバ２００は本発明における第２のサーバに対応する。本実施形態では、１台のＤＢサーバ２００に対し、２台のＡＰサーバ１００Ａ、１００Ｂが対応付いた構成を例示したが、この構成に限定されず、１台のＤＢサーバ２００に対し、３台以上のＡＰサーバ１００Ａ、１００Ｂが対応付いた構成であっても、特段の変更無く本実施形態のサーバ監視方法を適用可能である。

また、各ＡＰサーバ１００Ａ、１００Ｂには、金融機関のシステム担当者等が用いる監視コンソール４００が接続され、本実施形態におけるサーバ監視方法の処理結果について、この監視コンソール４００に出力されるものとする。

続いて、本実施形態のサーバ監視システム１０を構成する各装置について、そのハードウェア構成の例について説明する。図２は本実施形態におけるＡＰサーバ１００のハードウェア構成例を示す図である。上述したるＡＰサーバ１００のハードウェア構成は以下の如くとなる。ＡＰサーバ１００は、ハードディスクドライブなど適宜な不揮発性記憶装置で構成される記憶装置１０１、ＲＡＭなど揮発性記憶装置で構成されるメモリ１０３、記憶装置１０１に保持されるプログラム１０２をメモリ１０３に読み出すなどして実行し装置自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なうＣＰＵなどの演算装置１０４、内部ネットワーク１３０と接続し他装置（負荷分散装置３００やＤＢサーバ２００）との通信処理を担う通信装置１０５、を備える。

なお、記憶装置１０１内には、情報処理装置として当然備えるべきＯＳ（図示せず。以下同様）の他、本実施形態のサーバ監視システム１０におけるＡＰサーバ１００として必要な機能を実装するプログラム１０２が少なくとも記憶されている。本実施形態においては、ＡＰサーバ１００がこのプログラム１０２を実行することで、ヘルスチェックシェル１１０が実装される。ヘルスチェックシェル１１０は、各ＡＰサーバ１００Ａ、１００Ｂに常駐し、本実施形態におけるサーバ監視システム１０の主たる機能を実現するシェルである。このヘルスチェックシェル１１０は、常駐中のＡＰサーバ１００に応じた単純な値のみ要求するごくシンプルなＳＱＬ文を発行し、それに応じてＤＢサーバ２００から得た応答結果を、ＡＰサーバ１００上の所定の監視アプリケーション１５０（ＳＮＭＰによるネットワーク監視の情報を使ってアプリケーションやシステムの情報を総合的に収集する既存のもの）に提供し、この監視アプリケーション１５０を介して上述の監視コンソール４００に、無応答障害に関する情報を提示させるものとなる。

次にＤＢサーバ２００におけるハードウェア構成例について説明する。図３は本実施形態におけるＤＢサーバ２００のハードウェア構成例を示す図である。ＤＢサーバ２００は、上述のＡＰサーバ１００と同様に、一般的なサーバ装置としての構成を備えると共に、ＤＢサーバ２００間で共有のヘルスチェック用テーブル２２５を、その記憶装置２０１において保持している。このヘルスチェック用テーブル２２５は、ＡＰサーバ１００について所定値を対応付けたテーブルとなる。ヘルスチェック用テーブル２２５の詳細については後述する。

次に、監視コンソール４００のハードウェア構成例について説明する。図４は本実施形態における監視コンソール４００のハードウェア構成例を示す図である。監視コンソール４００は、上述のＡＰサーバ１００やＤＢサーバ２００等における一般的な情報処理装置としてのハードウェア構成の他に、金融機関におけるシステム担当者等、所定ユーザからのキー入力や音声入力を受け付ける入力装置４０５、ＡＰサーバ１００のヘルスチェックシェル１１０からの通知を表示するディスプレイ等の出力装置４０６を備えている。

続いて、本実施形態のサーバ監視システム１０が備える機能について説明する。上述したように、以下に説明する機能は、例えばサーバ監視システム１０を成す適宜な情報処理装置が備えるプログラムを実行することで実装される機能と言える。本実施形態の場合、例えばＡＰサーバ１００におけるヘルスチェックシェル１１０が主導し、ＤＢサーバ２００や監視コンソール４００が協働する機能となる。サーバ監視システム１０として、ＡＰサーバ１００のみを想定する場合、ヘルスチェックシェル１１０での機能がサーバ監視システム１０の機能となり、サーバ監視システム１０として、ＡＰサーバ１００に加えて、ＤＢサーバ２００や監視コンソール４００も含めた構成を想定する場合、ヘルスチェックシェル１１０とＤＢサーバ２００および監視コンソール４００での機能がサーバ監視システム１０の機能となる。

ここで、各ＡＰサーバ１００に常駐しているヘルスチェックシェル１１０は、常駐先のＡＰサーバ１００がアクセスするＤＢサーバ２００（単に常駐先のＡＰサーバ１００が通信できるＤＢサーバ２００である）に対し、所定応答を要求する電文を例えば６０秒間隔で送信し、各電文の送信時点からの経過時間を計測する機能を備えている。

また、上述の各ヘルスチェックシェル１１０は、上述の電文の送信に応じてＤＢサーバ２００から所定応答を受信するまでの経過時間が、例えば２秒（第１の基準時間）を越えた第１事象を、上述の電文の送信毎に監視し、当該第１事象の連続発生回数が例えば２回（所定基準回数）を超えた場合に、該当ＤＢサーバ２００がスローダウン状態にある旨を、監視コンソール４００に通知する機能を備えている。

また、各ヘルスチェックシェル１１０は、上述の電文の送信時点から、例えば３５秒（第２の基準時間）以内に、ＤＢサーバ２００から所定応答を受信出来なかった第２事象を、上述の電文の送信毎に監視し、当該第２事象の発生を検知した場合に、該当ＤＢサーバ２００がハングアップ状態にある旨を監視コンソール４００に通知する機能を備えている。

また、各ヘルスチェックシェル１１０は、上述のＤＢサーバ２００に対して例えば６０秒間隔で送信する電文として、当該ヘルスチェックシェル１１０が常駐するＡＰサーバ１００に対応した所定値を応答すべく要求する電文を送信する機能を備えている。この電文は、サーバ間の通信プロトコルに応じたフォーマットにおいて、好適には該当ＡＰサーバ１００のＩＤ（識別情報）のみ含んでいる。ここで応答を要求する所定値は、各ＡＰサーバ１００Ａ、１００Ｂごとに予め決められている１桁の数値である。

この場合のＤＢサーバ２００は、記憶装置２０１におけるヘルスチェック用テーブル２２５において、各ＡＰサーバ１００Ａ、１００ＢのＩＤと、該当ＡＰサーバ１００Ａ、１００Ｂを示す１桁の数値との対応関係を規定している（図５参照）。そのため、ＤＢサーバ２００は、ヘルスチェックシェル１１０から送信されてきた上述の電文を受信した場合、該当電文が示す該当ＡＰサーバ１００Ａ、１００Ｂ（ヘルスチェックシェル１１０の常駐先）の識別情報を、ヘルスチェック用テーブル２２５に照合し、ヘルスチェックシェル１１０の常駐先であるＡＰサーバ１００に対応した１桁の数値を特定して、これを応答として該当ＡＰサーバ１００のヘルスチェックシェル１１０に返信する機能を備えている。

一方、ＡＰサーバ１００のヘルスチェックシェル１１０から、上述のスローダウン状態やハングアップ状態に関する通知を受信する監視コンソール４００は、各ヘルスチェックシェル１１０、すなわち各ＡＰサーバ１００Ａ、１００Ｂからこうしたスローダウン状態ないしハングアップ状態に関する通知を受信した際、１台のＤＢサーバ２００に関して該当ＤＢサーバ２００に対応付けされた全てのＡＰサーバ１００Ａ、１００Ｂのヘルスチェックシェル１１０から、スローダウン状態にある旨ないしハングアップ状態にある旨の通知を受けた場合、該当ＤＢサーバ２００にスローダウン状態ないしハングアップ状態が生じている旨を出力装置４０６に表示する機能を備えている。

また、監視コンソール４００は、１台のＤＢサーバ２００に関して該当ＤＢサーバ２００に対応付けされた一部のＡＰサーバ１００ＡまたはＡＰサーバ１００Ｂからのみ、スローダウン状態にある旨ないしハングアップ状態にある旨の通知を受けた場合、この通知を送信してこなかったＡＰサーバ１００にスローダウン状態ないしハングアップ状態が生じている旨を出力装置４０６に表示する機能を備えている。

また、監視コンソール４００は、１台のＤＢサーバ２００に関して該当ＤＢサーバ２００に対応付けされた全てのＡＰサーバ１００から、スローダウン状態にある旨ないしハングアップ状態にある旨の通知を受けた場合、ＤＢサーバ２００にスローダウン状態ないしハングアップ状態が生じている旨と、ＤＢサーバ２００へのログイン処理を実行して状態確認を行うべく促すメッセージを出力装置４０６に表示する機能を備えている。

−−−処理手順例−−−
以下、本実施形態におけるサーバ監視方法の実際手順について図に基づき説明する。以下で説明するサーバ監視方法に対応する各種動作は、サーバ監視システム１０が含む各ＡＰサーバ１００Ａ、１００Ｂにおける各ヘルスチェックシェル１１０によって実現される。そして、このヘルスチェックシェル１１０は、以下に説明される各種の動作を行うためのコードから構成されている。

図６は、本実施形態におけるサーバ監視方法の処理手順例を示すフロー図であり、図７は本実施形態における監視概念例を示す説明図である。ここではまず、各ＡＰサーバ１００に常駐しているヘルスチェックシェル１１０が、常駐先のＡＰサーバ１００がアクセするＤＢサーバ２００（単に常駐先のＡＰサーバ１００が通信できるＤＢサーバ２００である）に対し、所定応答を要求する電文を例えば６０秒間隔で送信し、各電文の送信時点からの経過時間を計測する（ｓ１００）。上述の電文は、サーバ間の通信プロトコルに応じたフォーマットにおいて、該当ヘルスチェックシェル１１０の常駐先であるＡＰサーバ１００のＩＤ（識別情報）のみ含んでおり、該当ヘルスチェックシェル１１０が常駐するＡＰサーバ１００に対応した１桁の数値のみを応答すべく要求する電文である。

次に上述の各ヘルスチェックシェル１１０は、上述の電文の送信に応じてＤＢサーバ２００から、常駐先のＡＰサーバ１００に対応した１桁の数値（所定応答）を受信するまでの経過時間が、例えば２秒を越えた第１事象を、上述の電文の送信毎に監視し、その発生回数をカウントする（ｓ１０１）。このカウントの結果、上述の第１事象の連続発生回数が、例えば２回を超えて３回に達した場合（ｓ１０２：Ｙ）、該当ヘルスチェックシェル１１０は、該当ＤＢサーバ２００がスローダウン状態にある旨を、監視コンソール４００に通知する（ｓ１０３）。なお、上述のカウントにより、第１事象を例えば連続２回までカウントしたが、次の電文送信では例えば２秒以内の応答がＤＢサーバ２００からあった場合、ヘルスチェックシェル１１０は、それまでカウントしていた「２回」のカウント値（ＡＰサーバ１００のメモリ１０３等で保持）をクリアし、再び連続回数が「０回」である時点から第１事象の連続発生回数をカウントし始める。

また、ヘルスチェックシェル１１０は、上述の電文の送信時点から、例えば３５秒以内に、該当ＤＢサーバ２００から、上述した１桁の数値を受信出来なかった第２事象を、上述の電文の送信毎に監視し、当該第２事象の発生を検知した場合（ｓ１０４：Ｙ）、該当ＤＢサーバ２００がハングアップ状態にある旨を監視コンソール４００に通知する（ｓ１０５）。こうした本実施形態における監視概念は図７にて示す通りである。

一方、監視コンソール４００は、ＡＰサーバ１００のヘルスチェックシェル１１０から、上述のスローダウン状態やハングアップ状態に関する通知を受信し（ｓ１０６）、受信した通知がスローダウン状態とハングアップ状態のいずれであるか判定する（ｓ１０７）。受信した通知がスローダウン状態に関するものであった場合（ｓ１０７：スローダウン）、監視コンソール４００は、更に、１台のＤＢサーバ２００に関して該当ＤＢサーバ２００に対応付けされた全てのＡＰサーバ１００すなわちＡＰサーバ１００Ａ及びＡＰサーバ１００Ｂの各ヘルスチェックシェル１１０から、スローダウン状態にある旨の通知を受けたか判定する（ｓ１０８）。

監視コンソール４００は、１台のＤＢサーバ２００に対応付けされた全てのＡＰサーバ１００すなわちＡＰサーバ１００Ａ及びＡＰサーバ１００Ｂの各ヘルスチェックシェル１１０から、スローダウン状態にある旨の通知を受けたと判定した場合（ｓ１０８：全部）、該当ＤＢサーバ２００にスローダウン状態が生じている旨を、出力装置４０６に表示する（ｓ１０９）。

他方、１台のＤＢサーバ２００に対応付けされたＡＰサーバ１００のうち一部のもののみ、例えばＡＰサーバ１００Ａのヘルスチェックシェル１１０のみから、スローダウン状態にある旨の通知を受けたと判定した場合（ｓ１０８：一部）、該当ＡＰサーバ１００Ａにスローダウン状態が生じている旨を、出力装置４０６に表示する（ｓ１１０）。

また、上述のステップｓ１０７において、受信した通知がハングアップ状態に関するものであった場合（ｓ１０７：ハングアップ）、監視コンソール４００は、更に、１台のＤＢサーバ２００に関して該当ＤＢサーバ２００に対応付けされた全てのＡＰサーバ１００すなわちＡＰサーバ１００Ａ及びＡＰサーバ１００Ｂの各ヘルスチェックシェル１１０から、ハングアップ状態にある旨の通知を受けたか判定する（ｓ１１１）。

監視コンソール４００は、１台のＤＢサーバ２００に対応付けされたＡＰサーバ１００のうち一部のもののみ、例えばＡＰサーバ１００Ａのヘルスチェックシェル１１０のみから、ハングアップ状態にある旨の通知を受けたと判定した場合（ｓ１１１：一部）、該当ＡＰサーバ１００Ａにハングアップ状態が生じている旨を、出力装置４０６に表示する（ｓ１１２）。

他方、１台のＤＢサーバ２００に関して該当ＤＢサーバ２００に対応付けされた全てのＡＰサーバ１００すなわちＡＰサーバ１００Ａ及びＡＰサーバ１００Ｂの各ヘルスチェックシェル１１０から、ハングアップ状態にある旨の通知を受けたと判定した場合（ｓ１１１：全部）、監視コンソール４００は、該当ＤＢサーバ２００へのログイン処理を実行して状態確認を行うべく促すメッセージを出力装置４０６に表示し（ｓ１１３）、処理を終了する。

こうした処理を監視コンソール４００にて行えば、クラスタ構成のサーバシステム２０において、いずれのサーバにおいて無応答障害が生じているのか、障害発生元を切り分けて、ユーザに提示することができる。このユーザは障害発生元と障害内容を確実に認識出来るため、それに引き続き行うべき障害対応を精度良く迅速に実行しやすくなる。また、ＤＢサーバ２００でのハングアップに際しては、基本的にはログイン処理の可否を確かめることで、該当サーバにおけるどのＤＢコントローラで障害が疑われるか判断することになるが、こうした対応をユーザに対して促すことが出来る。そのためユーザは、行うべき障害対応を具体的に認識し、迅速に実行しやすくなる。

以上、本発明を実施するための最良の形態などについて具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。

こうした本実施形態によれば、クラスタ構成のサーバシステムにおける無応答障害を的確に検知することが可能となる。

本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態のサーバ監視システムの前記第１のサーバにおいて、前記第２のサーバに対する前記電文として、当該第１のサーバに対応した所定値を応答すべく要求する電文を送信し、前記第２のサーバにおいて、前記第１のサーバについて所定値を対応付けたテーブルを記憶装置にて保持しており、前記電文を前記第１のサーバから受信した場合、該当電文が示す前記第１のサーバの識別情報を前記テーブルに照合し、前記第１のサーバに対応した所定値を特定して、当該所定値を応答として前記第１のサーバに返信する処理を実行する、としてもよい。

これによれば、スローダウンやハングアップといった無応答障害を監視するにあたり、しばしばそうした障害の原因となる処理データ量過大の事態に加担することなく、固定的で単純なデータ構造のテーブルから単に値を１つ得て返すのみといった極めて低負荷の処理で、迅速かつ的確なサーバ監視を行うことが出来る。

また、前記クラスタ構成のサーバシステムにおいて、前記第２のサーバ１台当たりに、複数台の前記第１のサーバが対応付けされた構成となっているとする。この場合のサーバ監視システムにおける前記第１のサーバ各々は、当該第１のサーバ自身に対応付けされた前記第２のサーバに対し、前記電文を送信し、前記第２のサーバにおいて、前記第１のサーバ各々から前記電文を受信し、該当電文が示す該当第１のサーバの識別情報を前記テーブルに照合し、該当第１のサーバに対応した所定値を特定して、当該所定値を応答として該当第１のサーバに返信し、前記１のサーバ各々は、前記第１事象の連続発生回数が所定基準回数を超えた場合に、当該第１のサーバ自身に対応付けされた前記第２のサーバがスローダウン状態にある旨を所定端末に通知し、前記電文の送信時点から、前記第１の基準時間以上の第２の基準時間内に、当該第１のサーバ自身に対応付けされた前記第２のサーバから所定応答を受信出来なかった第２事象を、前記電文の送信毎に監視し、当該第２事象の発生を検知した場合に、当該第１のサーバ自身に対応付けされた前記第２のサーバがハングアップ状態にある旨を所定端末に通知し、前記所定端末において、前記第２のサーバに関して、前記スローダウン状態にある旨ないし前記ハングアップ状態にある旨の通知を前記第１のサーバから受信し、１台の前記第２のサーバに関して該当第２のサーバに対応付けされた全ての前記第１のサーバから、前記スローダウン状態にある旨ないし前記ハングアップ状態にある旨の通知を受けた場合、前記第２のサーバにスローダウン状態ないし前記ハングアップ状態が生じている旨を出力装置に表示し、１台の前記第２のサーバに関して該当第２のサーバに対応付けされた一部の前記第１のサーバからのみ、前記スローダウン状態にある旨ないし前記ハングアップ状態にある旨の通知を受けた場合、前記通知を送信してこなかった前記第１のサーバにスローダウン状態ないし前記ハングアップ状態が生じている旨を出力装置に表示する、としてもよい。

これによれば、クラスタ構成のサーバシステムにおいて、いずれのサーバにおいて無応答障害が生じているのか、障害発生元を切り分けて、ユーザ側（所定端末）に提示することができる。ユーザは障害発生元と障害内容を確実に認識出来るため、それに引き続き行うべき障害対応を精度良く迅速に実行しやすくなる。

また、上述の場合の前記所定端末において、１台の前記第２のサーバに関して該当第２のサーバに対応付けされた全ての前記第１のサーバから、前記ハングアップ状態にある旨の通知を受けた場合、前記第２のサーバに前記ハングアップ状態が生じている旨と、前記第２のサーバへのログイン処理を実行して状態確認を行うべく促すメッセージを出力装置に表示する、としてもよい。

ＤＢサーバ（第２のサーバ）でのハングアップに際しては、基本的にはログイン処理の可否を確かめることで、該当サーバにおけるどのＤＢコントローラで障害が疑われるか判断することになるが、こうした対応をユーザに対して促すことが出来る。そのためユーザは、行うべき障害対応を具体的に認識し、迅速に実行しやすくなる。

１０サーバ監視システム
２０クラスタ構成のサーバシステム
１００ＡＰサーバ（第１のサーバ）
１０１記憶装置
１０２プログラム
１０３メモリ
１０４演算装置
１０５通信装置
１１０ヘルスチェックシェル
１２０ネットワーク
２００ＤＢサーバ（第２のサーバ）
２２５ヘルスチェック用テーブル（テーブル）
３００負荷分散装置
４００監視コンソール（所定端末）

Claims

クラスタ構成のサーバシステムが含む第１のサーバにおいて、
当該第１のサーバがアクセする第２のサーバに対し、所定応答を要求する電文を送信し、前記電文の送信時点からの経過時間を計測する処理と、
前記電文の送信に応じて前記第２のサーバから所定応答を受信するまでの経過時間が、第１の基準時間を越えた第１事象を、前記電文の送信毎に監視し、当該第１事象の連続発生回数が所定基準回数を超えた場合に、前記第２のサーバがスローダウン状態にある旨を所定端末に通知する処理と、
前記電文の送信時点から、前記第１の基準時間以上の第２の基準時間内に、前記第２のサーバから所定応答を受信出来なかった第２事象を、前記電文の送信毎に監視し、当該第２事象の発生を検知した場合に、前記第２のサーバがハングアップ状態にある旨を所定端末に通知する処理と、
を実行することを特徴とするサーバ監視方法。
前記第１のサーバにおいて、
前記第２のサーバに対する前記電文として、当該第１のサーバに対応した所定値を応答すべく要求する電文を送信し、
前記第２のサーバにおいて、
前記第１のサーバについて所定値を対応付けたテーブルを記憶装置にて保持しており、
前記電文を前記第１のサーバから受信した場合、該当電文が示す前記第１のサーバの識別情報を前記テーブルに照合し、前記第１のサーバに対応した所定値を特定して、当該所定値を応答として前記第１のサーバに返信する処理を実行する、
ことを特徴とする請求項１に記載のサーバ監視方法。
前記クラスタ構成のサーバシステムにおいて、前記第２のサーバ１台当たりに、複数台の前記第１のサーバが対応付けされた構成となっており、
前記第１のサーバ各々は、
当該第１のサーバ自身に対応付けされた前記第２のサーバに対し、前記電文を送信し、
前記第２のサーバにおいて、
前記第１のサーバ各々から前記電文を受信し、該当電文が示す該当第１のサーバの識別情報を前記テーブルに照合し、該当第１のサーバに対応した所定値を特定して、当該所定値を応答として該当第１のサーバに返信し、
前記１のサーバ各々は、
前記第１事象の連続発生回数が所定基準回数を超えた場合に、当該第１のサーバ自身に対応付けされた前記第２のサーバがスローダウン状態にある旨を所定端末に通知し、
前記電文の送信時点から、前記第１の基準時間以上の第２の基準時間内に、当該第１のサーバ自身に対応付けされた前記第２のサーバから所定応答を受信出来なかった第２事象を、前記電文の送信毎に監視し、当該第２事象の発生を検知した場合に、当該第１のサーバ自身に対応付けされた前記第２のサーバがハングアップ状態にある旨を所定端末に通知し、
前記所定端末において、
前記第２のサーバに関して、前記スローダウン状態にある旨ないし前記ハングアップ状態にある旨の通知を前記第１のサーバから受信し、
１台の前記第２のサーバに関して該当第２のサーバに対応付けされた全ての前記第１のサーバから、前記スローダウン状態にある旨ないし前記ハングアップ状態にある旨の通知を受けた場合、前記第２のサーバにスローダウン状態ないし前記ハングアップ状態が生じている旨を出力装置に表示し、
１台の前記第２のサーバに関して該当第２のサーバに対応付けされた一部の前記第１のサーバからのみ、前記スローダウン状態にある旨ないし前記ハングアップ状態にある旨の通知を受けた場合、前記通知を送信してこなかった前記第１のサーバにスローダウン状態ないし前記ハングアップ状態が生じている旨を出力装置に表示する、
ことを特徴とする請求項２に記載のサーバ監視方法。
前記所定端末において、
１台の前記第２のサーバに関して該当第２のサーバに対応付けされた全ての前記第１のサーバから、前記ハングアップ状態にある旨の通知を受けた場合、前記第２のサーバに前記ハングアップ状態が生じている旨と、前記第２のサーバへのログイン処理を実行して状態確認を行うべく促すメッセージを出力装置に表示する、
ことを特徴とする請求項３に記載のサーバ監視方法。
クラスタ構成のサーバシステムが含む第１のサーバにおいて、
当該第１のサーバがアクセする第２のサーバに対し、所定応答を要求する電文を送信し、前記電文の送信時点からの経過時間を計測する処理と、
前記電文の送信に応じて前記第２のサーバから所定応答を受信するまでの経過時間が、第１の基準時間を越えた第１事象を、前記電文の送信毎に監視し、当該第１事象の連続発生回数が所定基準回数を超えた場合に、前記第２のサーバがスローダウン状態にある旨を所定端末に通知する処理と、
前記電文の送信時点から、前記第１の基準時間以上の第２の基準時間内に、前記第２のサーバから所定応答を受信出来なかった第２事象を、前記電文の送信毎に監視し、当該第２事象の発生を検知した場合に、前記第２のサーバがハングアップ状態にある旨を所定端末に通知する処理を実行する演算装置を備える構成とする、
ことを特徴とするサーバ監視システム。