(57)【要約】【課題】複数のサーバから構成される相互監視システムにおいて、障害発生時に、障害ログが失われてしまうという事態が発生しないようにする。【解決手段】各サーバ10A,10B,20A,20Bは、他のサーバに対して定期的に状態確認要求を送信し、この状態確認要求に応答して上記他サーバから状態確認応答が返信されたか否かに基づいて、上記他サーバの死活を判定する死活監視部を備える。更に、各サーバ10A,10B,20A,20Bは、自サーバに発生した障害を検出して他サーバに対して障害発生通知を送信し、上記他サーバからの障害発生通知を受信することにより上記他サーバに対してログ要求を送信し、ログ要求を受信することにより要求元のサーバに対して自サーバのログを送信し、ログを受信することにより、このログを記憶部に記録するイベント監視部を備える。【選択図】図１
2012168907.tif 000002
【特許請求の範囲】
【請求項１】
複数のサーバが、それぞれ、
自サーバに発生した障害を検出して前記他サーバに対して障害発生通知を送信し、前記他サーバからの障害発生通知を受信することにより前記他サーバに対してログ要求を送信し、ログ要求を受信することにより要求元のサーバに対して自サーバのログを送信し、ログを受信することにより、該ログを記憶部に記録するイベント監視部を備えることを特徴とする相互監視システム。
【請求項２】
請求項１記載の相互監視システムにおいて、
前記イベント監視部は、ログを受信することにより、該ログに基づいて障害の復旧方法を求め、該求めた復旧方法を管理端末装置へ送信することを特徴とする相互監視システム。
【請求項３】
請求項２記載の相互監視システムにおいて、
前記複数のサーバは、それぞれ、障害の種別を示す障害ＩＤと、該障害ＩＤによって示される種別の障害を復旧するための復旧方法とが関連付けて記録された復旧方法記憶部を備え、
前記ログは、発生した障害の種別を示す障害ＩＤを含み、
前記イベント監視部は、ログに含まれている障害ＩＤと関連付けて記録されている復旧方法を前記復旧方法記憶部から検索して前記管理端末装置へ送信することを特徴とする相互監視システム。
【請求項４】
請求項１，２または３記載の相互監視システムにおいて、
前記複数のサーバは、データベースを管理する２重化された第１および第２のデータベースサーバと、クライアントからの処理要求を前記第１および第２のデータベースサーバを利用して処理する２重化された第１および第２のアプリケーションサーバであり、
前記第１および第２のデータベースサーバ上のイベント監視部と、前記第１および第２のアプリケーションサーバ上のイベント監視部は、他サーバ上のイベント監視部からの障害発生通知を受信した場合、自イベント監視部を搭載しているサーバの種別が前記障害発生通知の送信元のサーバの種別と異なり、且つ、自イベント監視部を搭載しているサーバが予備系である場合、前記障害発生通知の送信元のサーバに対して、ログ要求を送信することを特徴とする相互監視システム。
【請求項５】
請求項４記載の相互監視システムにおいて、
前記第１および第２のデータベースサーバと前記第１および第２のアプリケーションサーバは、自サーバを除いた他サーバに対して、定期的に状態確認要求を送信し、該状態確認要求に応答して前記他サーバから状態確認応答が返信されたか否かに基づいて、前記他サーバの死活を判定すると共に、前記他サーバから送られてきた状態確認要求に応答して状態確認応答を返信する死活監視部を備え、
前記第１および第２のデータベースサーバ上のイベント監視部は、それぞれ、自イベント監視部を搭載しているデータベースサーバがマウント状態になった場合、他サーバに対してマウント状態通知を送信し、自イベント監視部が搭載されているデータベースサーバが運用状態になった場合、他サーバに対して運用状態通知を送信し、
前記第１および第２のデータベース上の死活監視部と前記第１および第２のアプリケーションサーバ上の死活監視部は、他サーバからマウント状態通知が送られてきた後、前記他サーバから運用場外通知が送られてくるまでの間は、前記他サーバに対する状態確認要求に応答して状態確認要求が返信されなくとも、前記他サーバが正常であると判定することを特徴とする相互監視システム。
【請求項６】
複数のサーバから構成される相互監視システムの構成要素となるサーバであって、
自サーバに発生した障害を検出して前記他サーバに対して障害発生通知を送信し、前記他サーバからの障害発生通知を受信することにより前記他サーバに対してログ要求を送信し、ログ要求を受信することにより要求元のサーバに対して自サーバのログを送信し、ログを受信することにより、該ログを記憶部に記録するイベント監視部を備えることを特徴とするサーバ。
【請求項７】
複数のサーバが、それぞれ、
自サーバに発生した障害を検出して前記他サーバに対して障害発生通知を送信し、前記他サーバからの障害発生通知を受信することにより前記他サーバに対してログ要求を送信し、ログ要求を受信することにより要求元のサーバに対して自サーバのログを送信し、ログを受信することにより、該ログを記憶部に記録することを特徴とする相互監視方法。
【請求項８】
複数のサーバから構成される相互監視システムの構成要素となるサーバをコンピュータによって実現するためのプログラムであって、
前記コンピュータを、
自サーバに発生した障害を検出して前記他サーバに対して障害発生通知を送信し、前記他サーバからの障害発生通知を受信することにより前記他サーバに対してログ要求を送信し、ログ要求を受信することにより要求元のサーバに対して自サーバのログを送信し、ログを受信することにより、該ログを記憶部に記録するイベント監視部として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバが他のサーバの状態を監視する相互監視システムに関する。
【背景技術】
【０００２】
サーバの状態を監視する際に、特別な監視用サーバを設けることなく、サーバ同士が他のサーバの状態を監視するということは、従来から行われている（例えば、特許文献１，２参照）
【０００３】
特許文献１に記載されている技術は、売上管理用サーバ及びクレジット管理用サーバが、両サーバからアクセス可能な記憶領域に、一定時間毎に、自サーバの現在時刻を書き込むと共に、相手サーバが書き込んだ時刻を読み出し、相手サーバの今回の書き込み時刻が前回の書き込み時刻から変化しているか否かに基づいて、相手サーバに障害が発生しているか否かを判定するというものである。
【０００４】
また、特許文献２に記載されている技術は、データベースサーバ内の障害監視タスクが一定時間毎にアプリケーションサーバに対して動作状態通知要求を送信し、アプリケーションサーバ内の動作通知タスクが上記要求に応答して動作状態通知をデータベースサーバへ返却し、データベースサーバ内の障害監視タスクが、アプリケーションサーバからの応答に基づいて、アプリケーションサーバに障害が発生しているか否かを判定するというものである。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開平１１−９６０３１号公報
【特許文献２】特開平１１−１１０３２５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
上述した特許文献１，２に記載されている技術によれば、特別な監視用サーバを設けることなく、相手サーバを監視することができる。しかしながら、特許文献１，２に記載されている技術は、一定時間毎に、他サーバに障害が発生しているか否かを判定するものであるので、障害発生から障害検出までに時間がかかってしまう場合がある。そして、障害発生から障害検出までに時間がかかると、障害復旧を迅速に行うために必要になる、障害発生時のログ情報が失われてしまう場合があるという問題がある。つまり、ログ情報を記録しておくログ記憶部には、容量的な制限があり、ログ記憶部が満杯になった場合には、再び、先頭番地からログ情報を記録する等の処置がとられるため、障害発生時のログ情報が、その後に発生したログ情報によって上書きされ、消えてしまう場合があるという問題がある。
【０００７】
[発明の目的]
そこで、本発明の目的は、障害復旧を迅速に行うために必要になる、障害発生時のログ情報が失われてしまう場合があるという課題を解決した相互監視システムを提供することにある。
【課題を解決するための手段】
【０００８】
本発明にかかる第１の相互監視システムは、
複数のサーバが、それぞれ、
自サーバに発生した障害を検出して前記他サーバに対して障害発生通知を送信し、前記他サーバからの障害発生通知を受信することにより前記他サーバに対してログ要求を送信し、ログ要求を受信することにより要求元のサーバに対して自サーバのログを送信し、ログを受信することにより、該ログを記憶部に記録するイベント監視部を備える。
【０００９】
本発明にかかるサーバは、
複数のサーバから構成される相互監視システムの構成要素となるサーバであって、
自サーバに発生した障害を検出して前記他サーバに対して障害発生通知を送信し、前記他サーバからの障害発生通知を受信することにより前記他サーバに対してログ要求を送信し、ログ要求を受信することにより要求元のサーバに対して自サーバのログを送信し、ログを受信することにより、該ログを記憶部に記録するイベント監視部を備える。
【００１０】
本発明にかかる相互監視方法は、
複数のサーバが、それぞれ、
自サーバに発生した障害を検出して前記他サーバに対して障害発生通知を送信し、前記他サーバからの障害発生通知を受信することにより前記他サーバに対してログ要求を送信し、ログ要求を受信することにより要求元のサーバに対して自サーバのログを送信し、ログを受信することにより、該ログを記憶部に記録する。
【００１１】
本発明にかかるプログラムは、
複数のサーバから構成される相互監視システムの構成要素となるサーバをコンピュータによって実現するためのプログラムであって、
前記コンピュータを、
自サーバに発生した障害を検出して前記他サーバに対して障害発生通知を送信し、前記他サーバからの障害発生通知を受信することにより前記他サーバに対してログ要求を送信し、ログ要求を受信することにより要求元のサーバに対して自サーバのログを送信し、ログを受信することにより、該ログを記憶部に記録するイベント監視部として機能させる。
【発明の効果】
【００１２】
本発明によれば、障害復旧を迅速に行うために必要となる、障害発生時のログ情報を残すことができる可能性を高いものにすることができるという効果を得ることができる。
【図面の簡単な説明】
【００１３】
【図１】本発明にかかる相互監視システムの第１の実施の形態の構成例を示すブロック図である。
【図２】アプリケーションサーバ10Aの構成例を示すブロック図である。
【図３】状態記憶部141の内容例を示す図である。
【図４】復旧方法記憶部142の内容例を示す図である。
【図５】データベースサーバ20Aの構成例を示すブロック図である。
【図６】死活監視部の処理例を示すフローチャートである。
【図７】データベースサーバ20Bが待機系になっているときに、データベースサーバ20Aにおいて障害が発生した時の処理を説明するためのシーケンス図の前半部分である。
【図８】データベースサーバ20Bが待機系になっているときに、データベースサーバ20Aにおいて障害が発生した時の処理を説明するためのシーケンス図の後半部分である。
【図９】イベント監視部の処理例を示すフローチャートである。
【図１０】図８、図９の処理が行われることにより、状態記憶部の内容が変化する様子を示した図である。
【図１１】データベースサーバ20Bが障害中になっているときに、データベースサーバ20Aにおいて障害が発生した時の処理を説明するためのシーケンス図の前半部分である。
【図１２】データベースサーバ20Bが障害中になっているときに、データベースサーバ20Aにおいて障害が発生した時の処理を説明するためのシーケンス図の後半部分である。
【図１３】図１１、図１２の処理が行われることにより、状態記憶部の内容が変化する様子を示した図である。
【図１４】運用系と待機系とを切り替える際の処理を示すシーケンス図である。
【図１５】一方のサーバが障害中であるときに、データベース切り替えコマンドを入力した際の処理を示すシーケンス図である。
【発明を実施するための形態】
【００１４】
次に、図面を参照して本発明の実施の形態について説明する。
【００１５】
[本発明の第１の実施の形態]
図１を参照すると、本発明にかかる相互監視システムの第１の実施の形態は、プライマリ・サイト側に配置されたアプリケーションサーバ10A、データベースサーバ20A、ルータ等の装置群30A、管理端末装置40Aおよびパーソナルコンピュータ等からなるクライアント群50Aと、スタンバイ・サイト側に配置されたアプリケーションサーバ10B、データベースサーバ20B、ルータ等の装置群30B、管理端末装置40Bおよびパーソナルコンピュータ等からなるクライアント群50Bとから構成され、プライマリ・サイトとスタンバイ・サイトとは同一サブネットのネットワークNで接続されている。
【００１６】
運用系のアプリケーションサーバ10Aは、クライアントからの処理要求を、運用系のデータベースサーバ20Aを利用して処理し、処理結果を要求元に返す一般的な機能の他に、定期的に他のサーバ10B,20A,20Bの死活を監視する機能や、自サーバで障害が発生した際、他のサーバ10B,20A,20Bに対して障害発生通知を送信する機能を有する。
【００１７】
図２を参照すると、アプリケーションサーバ10Aは、送受信部11と、アプリケーション処理部12と、サーバ状態監視プロセス13と、ディスク装置などの記憶装置14とから構成されている。
【００１８】
記憶装置14には、状態記憶部141と、復旧方法記憶部142と、ログ記憶部143とが設けられている。
【００１９】
状態記憶部141には、各サーバ10A,10B,20A,20Bの状態が、INT（初期状態）、ACT（運用系）、SBY（待機系）、FLT（障害中）の何れであるかを示す情報が記録される。図３は、状態記憶部141の内容例を示す図であり、同図の例は、アプリケーションサーバ10Aおよびデータベースサーバ20Aが運用系で、アプリケーションサーバ10Bおよびデータベースサーバ20Bが待機系であることを示している。
【００２０】
復旧方法記憶部142には、障害の種類を示す障害IDに関連付けて、その障害の復旧方法が記録されている。図４は、復旧方法記憶部142の内容例を示す図であり、同図の例は、障害IDが「ID00000001」の障害の復旧方法が「xxxxx。」であること等を示している。
【００２１】
ログ記憶部143には、障害ログ情報などのログ情報が記録される。ログ情報には、発生したイベントの種類を示すイベントID（障害に関するイベントIDを障害IDと記す場合がある）が含まれる。
【００２２】
送受信部11は、ネットワークNを介して他のサーバ等との間でデータをやり取りする機能を有する。
【００２３】
アプリケーション処理部１２は、クライアントから送られてくる処理要求を受け付け、この処理要求によって要求されている処理を、運用系のデータベースサーバ20Aを利用して処理し、処理結果を要求元に返す機能を有する。
【００２４】
サーバ状態監視プロセス13は、他のサーバ10B,20A,20Bの状態を監視するプロセスであり、死活監視部131と、イベント監視部132とを備えている。
【００２５】
死活監視部131は、定期的に他のサーバ10B,20A,20Bに対して状態確認要求を送信し、これに応答して状態確認応答が返信されてきたか否かに基づいて、サーバ10B,20A,20Bに障害が発生しているか否かを判定する機能や、他のサーバ10B,20A,20Bから送られてきた状態確認要求に応答して、状態確認応答を返信する機能を有する。
【００２６】
イベント監視部132は、自サーバ10Aに障害が発生したことを検出した場合、他のサーバ10B,20A,20Bに対して障害発生通知を送信する機能や、他のサーバ10B,20A,20Bから障害発生通知が送られてきた場合、その送信元のサーバに対してログ要求を送信する機能や、ログ要求に応答して他のサーバ10B,20A,20Bから送られてきたログ情報と復旧方法記憶部142の内容とに基づいて、障害の復旧方法を求め、求めた復旧方法を管理端末装置40A,40Bへ送信する機能や、他のサーバ10B,20A,20Bから送られてくるログ要求に応答してログ記憶部143からログ情報を読み出して要求元に送信する機能などを有する。ここで、イベント監視部132で検出できる障害は、ポート障害、ミドルウェア障害、ソフトウェア障害、アプリケーション障害などである。
【００２７】
なお、待機系のアプリケーションサーバ10Bも、アプリケーションサーバ10Aと同様の構成を備えている。また、アプリケーションサーバ10Aは、コンピュータによって実現可能であり、コンピュータによって実現する場合は、次のようにする。コンピュータをアプリケーションサーバ10Aとして機能させるためのプログラムを記録したディスク、半導体メモリ、その他の記録媒体を用意し、コンピュータに上記プログラムを読み取らせる。コンピュータは、読み取ったプログラムに従って自身の動作を制御することにより、アプリケーション処理部12、死活監視部131、及び、イベント監視部132を実現する。
【００２８】
運用系のデータベースサーバ20Aは、データベースを管理する一般的な機能の他に、定期的に他のサーバ10A,10B,20Bの死活を監視する機能や、自サーバ20Aにおいて障害が発生した際、他のサーバ10A,10B,20Bに対して障害発生通知を送信する機能などを有している。
【００２９】
図５を参照すると、データベースサーバ20Aは、送受信部21と、データベース処理部22と、サーバ状態監視プロセス23と、ディスク装置などの記憶装置24とを備えている。
【００３０】
記憶装置24は、状態記憶部241と、復旧方法記憶部242と、ログ記憶部243と、データ記憶部244とが設けられている。
【００３１】
状態記憶部241には、各サーバ10A,10B,20A,20Bの状態を示す情報が記録される。復旧方法記憶部242には、障害の種類を示す障害IDに関連付けて、その障害を復旧するための復旧方法が記録されている。ログ情報記憶部243には、障害ログなどのログ情報が記録される。データ記憶部244には、アプリケーションサーバ10Aから依頼された処理を行うために必要なデータが記録されている。
【００３２】
送受信部21は、ネットワークNを介して他のサーバなどとの間で、データを送受信する機能を有する。
【００３３】
データベース処理部22は、アプリケーションサーバ10Aから依頼された処理を、データ記憶部244に記録されているデータを利用して行い、処理結果をアプリケーションサーバ10Aに返す機能を有する。
【００３４】
サーバ状態監視プロセス23は、他のサーバ10A,10B,20Bの状態を監視するプロセスであり、死活監視部231と、イベント監視部232とを備えている。
【００３５】
死活監視部231は、定期的に他のサーバ10A,10B,20Bに対して状態確認要求を送信し、この要求に応答して状態確認応答が戻ってきたか否かに基づいて、他のサーバ10A,10B,20Bに障害が発生しているか否かを判定する機能や、他のサーバ10A,10B,20Bから送られてきた状態確認要求に応答して、状態確認応答を返信する機能を有する。
【００３６】
イベント監視部232は、自サーバ20Aに障害が発生したことを検出した場合、他のサーバ10A,10B,20Bに対して障害発生通知を送信する機能や、他のサーバ10A,10B,20Bから障害発生通知が送られてきた場合、その送信元のサーバ10A,10B,20Bに対してログ要求を送信する機能や、ログ要求に応答して送られてきたログ情報と復旧方法記憶部242の内容とに基づいて、障害の復旧方法を求め、求めた復旧方法を管理端末装置40A,40Bに送信する機能や、他のサーバ10A,10B,20Bから送られてくるログ要求に応答してログ記憶部243に記録されているログ情報を要求元に送信する機能などを有する。
【００３７】
なお、待機系のデータベースサーバ20Bもデータベース20Aと同様の機能を有する。また、データベースサーバ20Aは、コンピュータによって実現可能であり、コンピュータによって実現する場合は、例えば、次のようにする。コンピュータをデータベースサーバ20Aとして機能させるためのプログラムを記録したディスク、半導体メモリ、その他の記録媒体を用意し、コンピュータに上記プログラムを読み取らせる。コンピュータは、読み取ったプログラムに従って自身の動作を制御することにより、自コンピュータ上に、データベース処理部22、死活監視部232、及び、イベント監視部232を実現する。
【００３８】
[第１の実施の形態の動作の説明]
次に、本実施の形態の動作について、図面を参照して詳細に説明する。
【００３９】
先ず、図６のフローチャートを参照して、アプリケーションサーバ10A内の死活監視部131の動作について説明する。
【００４０】
アプリケーションサーバ10A内の死活監視部131は、一定時間が経過する毎に（ステップＳ61がYESとなる毎に）、次のような処理を行う。
【００４１】
先ず、他のサーバ10B,20A,20Bの内の１つのサーバ（例えば、データベースサーバ20Aとする）に対して、状態確認要求を送信し、状態確認応答が返信されるのを待つ（ステップＳ62、Ｓ63）。データベースサーバ20Aが正常動作している場合には、状態確認要求を受信した、データベースサーバ20A内の死活監視部131がアプリケーションサーバ10Aに対して状態確認応答を送信するが、データベースサーバ20Aにディスク障害や電源障害などの障害が発生している場合には、アプリケーションサーバ10Aに対して状態確認応答が送信されない。尚、状態確認要求としては、Pingを利用することができる。
【００４２】
そして、一定時間以内に、データベースサーバ20Aから状態確認応答が戻ってきた場合（ステップＳ63がYES）は、データベースサーバ20Aは正常であると判断し、次のサーバ（例えば、アプリケーションサーバ10B）に対して状態確認要求を送信し、上記サーバからの応答を待つ（ステップＳ62、Ｓ63）。
【００４３】
これに対して、一定時間以内に、データベースサーバ20Aから状態確認応答が送られてこなかった場合（ステップＳ63がNO）は、データベースサーバ20Aに障害が発生したと判断し、障害処理を実行する（ステップＳ65）。このステップＳ65の障害処理では、例えば、データベースサーバ20Aに障害が発生したことを管理端末装置40A,40Bに送信する処理や、状態記憶部141に記録されている、データベースサーバ20Aの状態情報を障害中（FLT）に変更する処理や、予備系のデータベースサーバ20Bを運用系にするための処理などを行う。障害処理が完了すると、次のサーバ（例えば、アプリケーションサーバ10B）に対して状態確認要求を送信し、上記サーバ10Bからの応答を待つ（ステップＳ62、Ｓ63）。
【００４４】
以上の処理を全てのサーバに対して行うと（ステップＳ64がYESとなると）、アプリケーションサーバ10A内の死活監視部131は、一定時間が経過するのを待ち（ステップＳ61）、再び前述したステップＳ62〜Ｓ65の処理を行う。
【００４５】
次に、図７及び図８のシーケンス図と、図９のフローチャートとを参照して、運用系のデータベースサーバ20A内のイベント監視部132が障害を検出した場合の動作について説明する。
【００４６】
図７に示すように、データベースサーバ20A,20Bがそれぞれ運用系、待機系となっているときに、データベースサーバ20Aで障害が発生し、それをデータベースサーバ20A内のイベント監視部132が検出した場合の動作について説明する。尚、アプリケーションサーバ10A,10Bは、それぞれ運用系、待機系になっているとする。また、以下の説明では、アプリケーションサーバ10A,10B内のイベント監視部132をイベント監視部132A,132Bと記し、データベースサーバ20A,20B内のイベント監視部をイベント監視部232A,232Bと記す場合がある。
【００４７】
イベント監視部232Aは、自サーバ20Aでソフトウェア障害、ミドルウェア障害などが発生したことを検出すると（ステップＳ71）、他のサーバ内のイベント監視部132A,132B,232Aに対して障害発生通知を送信すると共に、自サーバ内の状態記憶部241を更新し、自サーバ20Aの状態を障害中に更新する（ステップＳ72，Ｓ73）。障害発生を通知する際には、trap等を利用することができる。
【００４８】
イベント監視部132A,132B,232Aは、データベースサーバ20Aからの障害発生通知を受信すると、図９のフローチャートに示すように、自サーバ内の状態記憶部141,241を更新し、データベースサーバ20Aの状態を障害中に更新する（ステップＳ91）。これにより、各サーバ内の状態記憶部141,241の内容は、図３に示すものから図１０（Ａ）に示すものに変更される。
【００４９】
その後、各イベント監視部132A,132B,232Aは、それぞれ自サーバ内の状態記憶部141,241の内容を参照し、予め定められている規則に基づいて、自サーバが障害解析を担当するサーバとなるか否かを判定する（ステップＳ92）。ここで、予め定められている規則は、複数のサーバの中から１台のサーバを選択するための規則であり、例えば、障害の発生したサーバとは種類の異なるサーバの、予備系のサーバが最も優先的に選択されるような規則を使用することができる。今、この規則に従って障害解析処理を実施するサーバを決定するようにすると、予備系のアプリケーションサーバ10Bが障害処理を担当することになる。
【００５０】
アプリケーションサーバ10B内のイベント監視部132Bは、自サーバが障害解析処理を担当すると判断すると（ステップＳ92がYES）、障害発生通知の通知元のデータベースサーバ20Aに対してログ要求を送信する（図７のステップＳ74、図９のステップＳ93）。これにより、データベースサーバ20A内のイベント監視部232Aは、ログ記憶部143からログ情報を読み出し、読み出したログ情報を要求元のアプリケーションサーバ10Bに対して送信する（ステップＳ75）。
【００５１】
アプリケーションサーバ10B内のイベント監視部132Bは、データベースサーバ20Aからのログ情報を受信すると、それを記憶装置14に記録し、更に、ログ情報を解析して障害の復旧方法を求め、求めた復旧方法を管理端末装置40A,40Bへ送信する（図７のステップＳ76、図９のステップＳ94,Ｓ95）。管理端末装置40A,40Bでは、送られてきた復旧方法を表示部に表示する。ここで、障害の復旧方法の求め方を説明すると、次のようになる。先ず、受信したログ情報に含まれているログIDの１つに注目し、注目したログIDと同じ障害IDが復旧方法記憶部142に記録されているか調べる。そして、記録されている場合は、記録されている障害IDと、それに対応する復旧方法とを保持し、その後、次のログIDに注目し、前述した処理と同様の処理を行う。これに対して、記録されていない場合は、直ちに次にログIDに注目し、前述した処理と同様の処理を行う。そして、全てのログIDについて処理が完了すると、保持している障害IDと復旧方法との対を管理端末装置40A,40Bへ送信する。
【００５２】
その後、イベント監視部132Bは、障害発生通知に対する処理が正常終了したことを示す状態通知応答を、データベースサーバ20Aに返す（図８のステップＳ801）。これにより、データベースサーバ20Aは、ダウンする（ステップＳ802）。一方、イベント監視部132Bは、状態記憶部141を参照して、障害発生通知の通知元ではない方のデータベースサーバ20Bの状態が待機系となっているか否かを調べ、待機系になっている場合は、切り替え可能と判定する（図８のステップＳ803、図９のステップＳ97）。この例の場合、図１０（Ａ）に示すように、データベースサーバ20Bの状態は待機系（SBY）になっているので、切り替え可能と判断し（ステップＳ97がYES）、切り替え処理を行う（ステップＳ98）。
【００５３】
切り替え処理においては、先ず、イベント監視部132Bは、管理端末装置40A,40Bに対して切り替え開始を通知し（ステップＳ804）、その後、待機系のデータベースサーバ20Bに対して、状態設定要求を送信し、データベースサーバ20Bの状態を運用系にすることを要求する（ステップＳ805）。この通知を受けると、データベースサーバ20Bは、データ適用処理を行う（ステップＳ806）。データ適用処理では、データベースサーバ20A,20Bを最後に同期させた時点から、データベースサーバ20Aに障害が発生した時点までに、データベースサーバ20Aにおいて行われた更新処理をデータベースサーバ20Bに反映させるための処理である。
【００５４】
データベースサーバ20B内のイベント監視部232Bは、データ適用処理が完了すると、自サーバ内の状態記憶部241の内容を図１０（Ｂ）に示すものに変更してデータベースサーバ20Bが運用系になったことを表示する共に、他のサーバ10A,10B,20Aに対して状態が運用系（ACT）に設定されたことを示す状態設定応答を送信する（ステップＳ807）。これにより、各サーバ10A,10B,20A内のイベント監視部132A,132B,232Aは、状態記憶部141,241の内容を図１０（Ｂ）に示すものに変更する。
【００５５】
その後、アプリケーションサーバ10B内のイベント監視部132Bは、管理端末装置40A,40Bに対して、データベースサーバ20Bを運用系に切り替えるための切り替え処理が完了したことを示す切り替え完了通知を送信する（ステップＳ809）。
【００５６】
その後、管理者などが管理端末装置40A,40Bの表示部に表示された復旧方法に基づいて、データベースサーバ20Aに発生した障害を復旧し、データベースサーバ20Aを起動すると、データベースサーバ20A内のイベント監視部232Aは、他のサーバ10A,10B,20Bに対して、自サーバ20Aの状態が初期状態（INT）になったことを通知すると共に、状態記憶部241の内容を図１０（Ｃ）に示すものに変更し、自サーバが初期状態になったことを表示する（ステップＳ810,S811）。
【００５７】
一方、データベースサーバ20Aからの通知を受けた他のサーバ10A,10B,20B内のイベント監視部132A,132B,232Bは、状態記憶部141,241の内容を図１０（Ｃ）に示すものに変更してデータベースサーバ20Aが初期状態になったことを表示し、その後、データベースサーバ20Aに対して、状態記憶部141,241の書き替えに成功したことを示す状態通知応答を返す（ステップＳ812、Ｓ813）。
【００５８】
その後、アプリケーションサーバ10B内のイベント監視部132Bは、初期状態になったデータベースサーバ20Aに対して、状態設定要求を送信し、その状態を待機系にすることを要求する（ステップＳ815）。
【００５９】
この要求に応答して、データベースサーバ20A内のイベント監視部232Aは、状態記憶部241の内容を図１０（Ｄ）に示すものに変更し、自サーバ20Aが待機系になったことを表示すると共に、他のサーバ10A,10B,20Bに対して、自サーバ20Aが待機系になったことを通知する（ステップＳ816〜Ｓ818）。これにより、サーバ10A,10B,20Bは、状態記憶部の内容を図１０（Ｄ）に示すものに変更する。
【００６０】
その後、データベースサーバ20Aは、他のサーバ10A,10B,20Bに対して障害復旧を通知する（ステップＳ819、Ｓ820）。尚、データベースサーバ20Aは、障害発生後のサーバであるため、システムに組み込むためには、運用者によるサーバ確認作業が必要である。
【００６１】
次に、図９のフローチャート及び図１１、図１２のシーケンス図を参照し、二重障害が発生した際の動作について説明する。
【００６２】
今、図１１に示すように、データベースサーバ20A,20Bがそれぞれ運用系、障害中のときに、データベースサーバ20Aにおいて障害が発生したとする。このときの各サーバ内の状態記憶部141,241の内容は、図１３（Ａ）に示すものになっている。
【００６３】
データベースサーバ20A内のイベント発生部232Aは、データベースサーバ20Aに発生したソフトウェア障害、ミドルウェア障害などを検出すると、他のサーバに対して障害発生通知を送信すると共に、自サーバ20A内の状態記憶部241の内容を図１３（Ｂ）に示すものに変更し、自サーバ20Aが障害中であることを表示する（ステップＳ112、Ｓ113）。
【００６４】
各サーバ10A,10B,20B内のイベント監視部132,232は、データベースサーバ20Aからの障害発生通知を受信すると、図９のステップＳ91の処理を行い、自サーバ内の状態記憶部141,241の内容を図１３（Ｂ）に示す内容とし、データベースサーバ20Aが障害中であることを表示する。その次のステップＳ92では、自サーバが障害解析処理を担当するサーバであるか否かを判定する。前述した規則に従って障害解析処理を担当するサーバを決定するようにすると、アプリケーションサーバ10Bが障害解析処理を担当することになる。
【００６５】
その後、アプリケーションサーバ10B内のイベント監視部132が前述したステップＳ93〜Ｓ96、Ｓ72〜76と同様の処理を行い、障害の復旧方法を管理端末装置40A,40Bへ送信する（ステップＳ112〜Ｓ116）。
【００６６】
その後、アプリケーションサーバ10B内のイベント監視部132Bが、障害発生通知に対する処理が正常終了したことを示す状態通知応答を、データベースサーバ20Aに返す（図１２のステップＳ1201）。これにより、データベースサーバ20Aは、ダウンする（ステップＳ1202）。一方、イベント監視部132Bは、状態記憶部141を参照して、障害発生通知の通知元ではない方のデータベースサーバ20Bの状態が待機系となっているか否かを調べ、待機系になっている場合は、切り替え可能と判定する（図１２のステップＳ1203、図９のステップＳ97）。この例の場合、図１３（Ｂ）に示すように、データベースサーバ20Bの状態は障害中（FLT）になっているので、切り替え不可能と判断し（ステップＳ97がNO）、切り替え失敗通知を管理端末装置40A,40Bへ送信する（図９のステップＳ99、図１２のステップＳ1204）。
【００６７】
その後、管理者などが管理端末装置40A,40Bの表示部に表示された復旧方法に基づいて、データベースサーバ20Aに発生した障害を復旧し、データベースサーバ20Aを起動すると、データベースサーバ20A内のイベント監視部232Aは、他のサーバ10A,10B,20Bに対して、自サーバ20Aの状態が初期状態（INT）になったことを通知すると共に、状態記憶部241の内容を図１３（Ｃ）に示すものに変更し、自サーバ20Aが初期状態になったことを表示する（ステップＳ1205,Ｓ1206）。
【００６８】
一方、データベースサーバ20Aからの通知を受けた他のサーバ10A,10B,20B内のイベント監視部132A,132B,232Bは、状態記憶部141,241の内容を図１０（Ｃ）に示すものに変更してデータベースサーバ20Aが初期状態になったことを表示し、その後、データベースサーバ20Aに対して、状態記憶部141,241の書き替えに成功したことを示す状態通知応答を返す（ステップＳ1207、Ｓ1208）。
【００６９】
その後、アプリケーションサーバ10B内のイベント監視部132Bは、初期状態になったデータベースサーバ20Aに対して、状態設定要求を送信し、その状態を待機系にすることを要求する（ステップＳ1209）。
【００７０】
この要求に応答して、データベースサーバ20A内のイベント監視部232Aは、状態記憶部241の内容を図１３（Ｄ）に示すものに変更し、自サーバ2Aが待機系になったことを表示すると共に、他のサーバ10A,10B,20Bに対して、自サーバ2Aが待機系になったことを通知する（ステップＳ1210〜Ｓ1212）。
【００７１】
その後、データベースサーバ20Aは、他のサーバ10A,10B,20Bに対して障害復旧を通知する（ステップＳ1213、Ｓ1214）。尚、データベースサーバ20Aは、障害発生後のサーバであるため、システムに組み込むためには、運用者によるサーバ確認作業が必要である。
【００７２】
次に、図１４のシーケンス図を参照して、運用系、待機系の切り替え処理について説明する。今、図１４に示すように、データベース20A,20Bがそれぞれ待機系、運用系となっているときに、データベース20A,20Bをそれぞれ運用系、待機系に変更する場合の動作を説明する。
【００７３】
運用系、待機系の切り替えを行う場合、管理者などはアプリケーションサーバ（例えば、アプリケーションサーバ10A）にデータベース切り替えコマンドを入力する（ステップＳ1401）。これにより、イベント監視部132は、自サーバ内の状態記憶部141を参照し、データベースサーバの内の一方が運用系、他方が待機系になっているか否かを判定することにより、切り替え可能か否かを判定する（ステップＳ1402）。この場合、データベースサーバ20A,20Bは、それぞれ待機系、運用系となっているので、切り替え可能と判断する。
【００７４】
そして、切り替え可能と判定すると、イベント監視部132は、管理端末装置40A,40Bに対して切り替え開始を通知し（ステップＳ1403）、その後、データベースサーバ20A,20Bのそれぞれに対して、その状態を運用系、待機系に変更することを要求する状態設定要求を送信する（ステップＳ1404、Ｓ1405）。
【００７５】
この通知を受けたデータベースサーバ20A,20B内のイベント監視手段232A,232Bは、データ適用処理を行う（ステップＳ1406,Ｓ1407）。そして、データ適用処理が完了すると、イベント監視手段232A,232Bは、それぞれアプリケーションサーバ10Aに対して状態設定が正常終了したことを示す状態設定応答を返す（ステップＳ1408、Ｓ1409）。これにより、アプリケーションサーバ10A内のイベント監視部132Aは、状態記憶部141に記録されているデータベースサーバ20A,20Bの状態をそれぞれ運用系、待機系に変更する。
【００７６】
更に、データベースサーバ20Aは、アプリケーションサーバ10Bおよびデータベースサーバ20Bに対して、自サーバ20Aが運用系に変更されたことを通知し、データベースサーバ20Bは、アプリケーションサーバ10Bおよびデータベースサーバ20Aに対して、自サーバ20Bが待機系に変更されたことを通知する（ステップＳ1408〜Ｓ1412）。その後、アプリケーションサーバ10Aは、管理端末装置40A,40Bに対してデータベースサーバの状態変更が完了したことを通知する（ステップＳ1412）。
【００７７】
次に、図１５のシーケンス図を参照して、データベースサーバ10A,10Bの状態がそれぞれ障害中、運用系のときに、データベース切り替えコマンドを入力した場合の動作について説明する。
【００７８】
図１６に示すように、管理者などがアプリケーションサーバ（例えば、アプリケーションサーバ10A）にデータベース切り替えコマンドを入力すると（ステップＳ151）、アプリケーションサーバ10A内のイベント監視部132Aは、データベースサーバ20A,20Bの状態を切り替えることができるか否かを判定する（ステップＳ152）。この判定は、前述したように、データベースサーバ20A,20Bの内の一方が運用系、他方が待機系になっているか否かに基づいて行う。この場合、データベースサーバ20A,20Bは、それぞれ障害中、運用系であるので、イベント監視部132Aは、切り替え不可能と判定し、管理端末装置40A,40Bに対して切り替え失敗を通知する（ステップＳ163）。
【００７９】
[第１の実施の形態の効果]
本実施の形態によれば、障害復旧を迅速に行うために必要となる、障害発生時のログ情報を残すことができる可能性を高いものにすることができるという効果を得ることができる。その理由は、各サーバ10A,10B,20A,20Bが、それぞれ、自サーバに発生した障害を検出して他のサーバに対して障害発生通知を送信し、上記他のサーバからの障害発生通知を受信することにより上記他のサーバに対してログ要求を送信し、ログ要求を受信することにより要求元のサーバに対して自サーバのログを送信し、ログを受信することにより、受信したログを記憶部に記録するイベント監視部132,232を備えているからである。
【００８０】
また、本実施の形態によれば、管理者などが容易に障害の復旧方法を知ることができるという効果を得ることもできる。その理由は、障害IDと復旧方法とが関連付けて記録された復旧方法記憶部を備え、イベント監視部は、ログ情報に含まれている障害IDに関連付けて記録されている復旧方法を復旧方法記憶部から検索して管理端末装置へ送信するようにしているからである。
【００８１】
[本発明の第２の実施の形態]
次に、本発明の第２の実施の形態について説明する。本実施の形態は、データベースサーバがマウント状態のときに、アプリケーションサーバの死活監視部が誤ってデータベースサーバに障害が発生したと判定しないようにしたことを特徴とする。
【００８２】
データベースサーバがマウント状態のときには、運用系、待機系のデータベースサーバ間でデータを同期させるために通信だけが行われ、アプリケーションサーバとの間の通信は切断されてしまう。このため、データベースサーバがマウント状態のときに、アプリケーションサーバの死活監視部がデータベースサーバに対して状態確認要求を送信しても、状態確認応答は戻って来ず、アプリケーションサーバはデータベースサーバに障害が発生したと判定してしまう。
【００８３】
そこで、本実施の形態では、第１の実施の形態におけるデータベースサーバ20A,20B上のイベント監視部232およびアプリケーションサーバ10A,10B上の死活監視部132に次のような機能を付加することにより、上記した問題を解決した。
【００８４】
第１の実施の形態では、データベースサーバ20A,20B上の死活監視部232は、自サーバ20A,20Bに障害が発生したときだけ、他のサーバに障害検出通知を送信するようにしたが、本実施の形態では、自サーバ20A,20Bの状態がマウント状態、運用状態に切り替わったとき、マウント状態通知、運用状態通知をアプリケーションサーバ10A,10Bに送信する。
【００８５】
また、第１の実施の形態では、アプリケーションサーバのイベント監視部132では、状態確認要求に応答して状態確認応答が戻って来なかった場合は、データベースサーバに障害が発生したと判断したが、本実施の形態では、データベースサーバ20A,20Bからマウント状態通知が送られてきてから運用状態通知が送られてくるまでの間は、データベースサーバ20A,20Bに対して送信した状態確認要求に応答して状態確認通知が戻ってこなくとも、データベースサーバ20A,20Bは正常であると判定する。
【００８６】
[第２の実施の形態の効果]
本実施の形態によれば、データベースサーバがマウント状態の時に、アプリケーションサーバが誤ってデータベースサーバに障害が発生したと判定しないようにすることができる。その理由は、データベースサーバ内のイベント監視部は、自サーバの状態がマウント状態、運用状態に変化した場合、アプリケーションサーバに対してマウント状態通知、運上状態通知を送信し、アプリケーションサーバの死活監視部では、マウント状態情報を受信してから運用状態情報を受信するまでの間は、状態確認要求に対する応答がデータベースサーバから戻って来なくとも、データベースが正常であると判定するようにしているからである。
【符号の説明】
【００８７】
10A,10B・・・アプリケーションサーバ
11・・・送受信部
12・・・アプリケーション処理部
13・・・サーバ状態監視プロセス
131・・・死活監視部
132・・・イベント監視部
14・・・記憶装置
141・・・状態記憶部
142・・・復旧方法記憶部
143・・・ログ記憶部
20A,20B・・・データベースサーバ
21・・・送受信部
22・・・データベース処理部
23・・・サーバ状態監視プロセス
231・・・死活監視部
232・・・イベント監視部
24・・・記憶装置
241・・・状態記憶部
242・・・復旧方法記憶部
243・・・ログ記憶部
244・・・データ記憶部
30A,30B・・・装置群
40A,40B・・・管理端末装置
50A,50B・・・クライアント群
【図１】
2012168907.tif 000003
【図２】
2012168907.tif 000004
【図３】
2012168907.tif 000005
【図４】
2012168907.tif 000006
【図５】
2012168907.tif 000007
【図６】
2012168907.tif 000008
【図７】
2012168907.tif 000009
【図８】
2012168907.tif 000010
【図９】
2012168907.tif 000011
【図１０】
2012168907.tif 000012
【図１１】
2012168907.tif 000013
【図１２】
2012168907.tif 000014
【図１３】
2012168907.tif 000015
【図１４】
2012168907.tif 000016
【図１５】
2012168907.tif 000017