(57)【要約】【課題】  プロセスのストール検出の確実性を向上させる。【解決手段】  本発明の一実施形態の監視サーバは、プロセスの処理を待ち合わせるトランザクションの停止通知を受信すると、前記プロセスに通信要求をして前記プロセスのストールを検知する監視ＡＰを備える。【選択図】      図１
2009064378.tif 000002
【特許請求の範囲】
【請求項１】
プロセスの処理を待ち合わせるトランザクションの停止通知を受信すると、前記プロセスに通信要求をして前記プロセスのストールを検知する監視ＡＰを、備える監視サーバ。
【請求項２】
前記トランザクションの生成および停止監視を行う業務ＡＰから前記停止監視に基づいた前記停止通知を受信する前記監視ＡＰを備える請求項１の監視サーバ。
【請求項３】
前記プロセスと前記業務ＡＰを備える請求項２の監視サーバ。
【請求項４】
相互に共有する共用ＤＢを各々備える複数の監視サーバから構成される監視システム内の監視サーバであって、
前記プロセスは、自監視サーバで実行される前記トランザクションの依頼を受けて、他監視サーバの前記共用ＤＢ内のデータの占有を行う資源管理プロセスであり、前記トランザクションは前記占有を待ち合わせる請求項３の監視サーバ。
【請求項５】
前記監視ＡＰは、自監視サーバの共有ＤＢに監視アクセスを行う請求項４の監視サーバ。
【請求項６】
前記業務ＡＰと、相互に共有する共用ＤＢと、自ＤＢサーバで実行される前記トランザクションの依頼を受けて、他ＤＢサーバの前記共用ＤＢ内のデータの占有を行う資源管理プロセスを各々備え、前記トランザクションは前記占有を待ち合わせる複数のＤＢサーバと、
請求項２の監視サーバと、から構成される監視システム。
【請求項７】
相互に共有する共用ＤＢと、自ＤＢサーバで実行される前記トランザクションの依頼を受けて、他ＤＢサーバの前記共用ＤＢ内のデータの占有を行う資源管理プロセスを各々備え、前記トランザクションは前記占有を待ち合わせる複数のＤＢサーバと、
前記業務ＡＰを備える請求項２の監視サーバと、から構成される監視システム。
【請求項８】
コンピュータに、
プロセスの処理を待ち合わせるトランザクションの停止通知を受信すると、前記プロセスに通信要求をして前記プロセスのストールを検知する監視処理を実行させる監視プログラム。
【請求項９】
前記コンピュータに、
前記トランザクションの生成および停止監視、並びに、前記停止監視に基づいた前記停止通知の送信をする業務処理を実行させる請求項８の監視プログラム。
【請求項１０】
相互に共有する共用ＤＢと前記プロセスを各々備える複数のコンピュータから構成され、前記プロセスは、自コンピュータで実行される前記トランザクションの依頼を受けて、他コンピュータの前記共用ＤＢ内のデータの占有を行う資源管理プロセスであるコンピュータに、前記監視処理と業務処理を実行させ、前記トランザクションに前記占有を待ち合わせさせる請求項９の監視プログラム。
【請求項１１】
前記コンピュータに、
前記監視処理で、自コンピュータの共有ＤＢに監視アクセスを行わせる請求項１０の監視プログラム。
【請求項１２】
コンピュータが、
プロセスの処理を待ち合わせるトランザクションの停止通知を受信すると、前記プロセスに通信要求をして前記プロセスのストールを検知する監視行程を有する監視方法。
【請求項１３】
前記コンピュータが、
前記トランザクションの生成および停止監視、並びに、前記停止監視に基づいた前記停止通知の送信をする業務行程を有する請求項１２の監視方法。
【請求項１４】
相互に共有する共用ＤＢと前記プロセスを各々備える複数のコンピュータから構成され、前記プロセスは、自コンピュータで実行される前記トランザクションの依頼を受けて、他コンピュータの前記共用ＤＢ内のデータの占有を行う資源管理プロセスであるコンピュータが行う、前記監視行程と前記業務行程を有する請求項１３の監視方法。
【請求項１５】
前記コンピュータが、
前記監視行程で、自コンピュータの共有ＤＢに監視アクセスを行う請求項１４の監視方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、監視システム、監視サーバ、監視プログラム、および監視方法に関する。
【背景技術】
【０００２】
特許文献１には、ＡＰ（アプリケーションプログラム）の発する生存信号に基づいてＡＰの生存監視を行う監視モニタが記載されている。
【０００３】
特許文献２には、ＡＰが送信する生存通知に基づいてＡＰの生存監視を行う実行監視プログラムが記載されている。
【０００４】
特許文献３には、データベースを分割管理している情報処理装置に障害が発生した場合に、影響を局所化する技術が記載されている。
【０００５】
【特許文献１】特開２００１−１０１０３３号公報
【特許文献２】特開２００３−３０００４号公報
【特許文献３】特開２００７−２５７８５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
上述の特許文献記載の技術は、プロセスによる処理を待ち合わせるトランザクションの停止通知を受信して、前記プロセスと通信して前記プロセスのストール（動作不能）を検知するものではない。したがって、プロセスのストール検出の確実性が低いという課題がある。本発明の目的は、この課題を解決する為の監視システム、監視サーバ、監視プログラム、および監視方法を提供することにある。
【課題を解決するための手段】
【０００７】
本発明の一実施形態の監視サーバは、プロセスの処理を待ち合わせるトランザクションの停止通知を受信すると、前記プロセスに通信要求をして前記プロセスのストールを検知する監視ＡＰを備える。
【０００８】
本発明の一実施形態の監視プログラムは、コンピュータに、プロセスの処理を待ち合わせるトランザクションの停止通知を受信すると、前記プロセスに通信要求をして前記プロセスのストールを検知する監視処理を実行させる。
【０００９】
本発明の一実施形態の監視方法は、コンピュータが、プロセスの処理を待ち合わせるトランザクションの停止通知を受信すると、前記プロセスに通信要求をして前記プロセスのストールを検知する監視行程を有する。
【発明の効果】
【００１０】
本発明は、プロセスのストール検出の確実性を向上させる。
【発明を実施するための最良の形態】
【００１１】
図１は、本発明の第１の実施形態を示す。
【００１２】
本実施形態の監視システム０１は、通常複数台の監視サーバ１０と各監視サーバ１０に対応した共用ＤＢ３０（共用データベース）とからなるクラスタシステムである。各監視サーバ１０はノードと呼ばれる。また、各監視サーバ１０は対応する共用ＤＢ３０のオーナーとも呼ばれる。
【００１３】
各監視サーバ１０は、監視システム０１内の全ての共用ＤＢ３０内のデータにアクセス可能である。即ち、共用ＤＢ３０は全ての監視サーバ１０から相互に共有されるシェアード・エブリシング（Shared Everything）型のデータベースを構成する。
【００１４】
このデータベースはリレーショナル型データベース（ＲＤＢＭＳ）であっても良いし、他のタイプのデータベースであっても良い。
【００１５】
監視サーバ１０は、監視ＡＰ１１（監視アプリケーションプログラム）、業務ＡＰ１２（業務アプリケーションプログラム）、トランザクション１３、業務ジャーナル１４および、ＤＢＭＳ２０（Data Base Management System）を包含する。ＤＢＭＳ２０は、資源管理プロセス２１およびノード内ロック部２２を包含する。
【００１６】
本実施形態に於いて、監視ＡＰ１１、業務ＡＰ１２とトランザクション１３は、コンピュータである監視サーバ１０のプロセッサーが、記憶域に格納されているプログラムを読み込んで実行することで機能する。同等な機能が、ハードウェアで実現されてもよい。
【００１７】
業務ＡＰ１２は、共用ＤＢ３０内のデータをアクセスするトランザクション１３を生成する。トランザクション１３は、ＤＢＭＳ２０に当該データの占有、アクセス、占有解除を依頼し、その終了を待ち合わせる。トランザクション１３は、例えば、業務ＡＰ１２とは別のプロセスとして動作し、業務ＡＰ１２とは非同期に動作する。
【００１８】
なお、プロセスとは、監視サーバ１０内の実行単位をいう。プロセスは、タスクとも呼ばれる。
【００１９】
アクセスの対象となるデータを格納する共用ＤＢ３０のオーナー（今後、データのオーナーと略記する）が自ノードである場合は、ＤＢＭＳ２０の内部において、ノード内ロック部２２が当該データの占有と占有解除を行う。
【００２０】
ここで、自ノードとは、トランザクション１３からのデータの占有、アクセスの依頼を受けたＤＢＭＳ２０を包含する監視サーバ１０をいう。他ノードとは、監視システム０１を構成する自ノード以外の監視サーバ１０をいう。
【００２１】
アクセスの対象となるデータのオーナーが他ノードである場合は、資源管理プロセス２１が、当該データの占有と占有解除を、当該他ノードの資源管理プロセス２１を経由して行う。即ち、自ノードの資源管理プロセス２１は当該データのオーナーである他ノードの資源管理プロセス２１に当該データの占有・占有解除依頼のメッセージを送信する。当該メッセージを受信した他ノードの資源管理プロセス２１は、当該他ノードのノード内ロック部２２を用いて、当該データの占有・占有解除を行う。
【００２２】
データのオーナーが他ノードの場合の、データの占有・占有解除処理は、市販のシェアード・エブリシング型データベースシステムに於いて、グローバルエンキュー処理などと称して実装されているものである。資源管理プロセス２１が、他ノードがオーナーであるデータの占有と占有解除を行う限り、その詳細な仕組みは上述に限定されない。
【００２３】
データのオーナーが他ノードである場合、トランザクション１３は、ＤＢＭＳ２０に当該データの占有を依頼した後、資源管理プロセス２１による占有を待ち合わせる。自ノードまたは他ノードの資源管理プロセス２１がストールするとトランザクション１３もその処理が停止されたままとなる。本実施形態の監視サーバ１０は、この資源管理プロセス２１のストールを直接的に検出する。
【００２４】
これまでデータベースシステム内での上記ストールを検知する為には、監視プログラムから監視の為の単純なＳＱＬ（System Query Language）文、例えば、データベースのどこかに配置した監視表の一列を更新するＳＱＬ文を発行していた。しかしながら、シェアード・エブリシング型のデータベースでは、データの所在によってデータアクセス時の占有が、資源管理プロセス２１を経由するのか否か、また経由してもどの他ノードの資源管理プロセス２１を経由するのかが変動する。ストールが検出できるか否かは監視表の所在に依存することになり、ストールの検出が確実に出来ないという課題があった。
【００２５】
さらに、他ノードがオーナーとなるデータをアクセスしても資源管理プロセス２１を経由したデータ占有を行わないタイミング、例えば、当該データがＤＢＭＳ２０が管理する監視サーバ１０のメモリ上にキャッシュされているタイミング、も存在する。このことが、上記課題をより大きなものとしていた。
【００２６】
本実施形態の監視ＡＰ１１は、資源管理プロセス２１による資源占有を待ち合わせるトランザクション１３の停止通知を業務ＡＰ１２から受信すると、資源管理プロセス２１と通信してそのストールを直接的に検知する。
【００２７】
図２乃至図４は、監視サーバ１０が行うこの検知の仕組みを示す。
【００２８】
図２は、業務ＡＰ１２のフローチャートである。業務ＡＰ１２は共用ＤＢ３０をアクセスするトランザクション１３を生成して、その終了を待ち合わせる（S21）。トランザクション１３の生成はＳＱＬ文の発行などにより行う。
【００２９】
トランザクション１３が終了すれば（S22でY）業務ＡＰ１２は次の処理を行う。所定時間が経過してもトランザクション１３が終了しない（S23でY）と、業務ＡＰ１２は監視ＡＰ１１にトランザクション１３の停止通知を送信する（S24）。その後、業務ＡＰ１２は監視ＡＰ１１が送信する監視結果報告を待ち合わせる（S25）。
【００３０】
監視ＡＰ１１の監視結果報告が資源管理プロセス２１の正常（ストールしていない）を示す（S26でY）場合は、業務ＡＰ１２は、監視時間をリセットして再度トランザクション１３の終了を待ち合わせる。監視ＡＰ１１の監視結果報告が資源管理プロセス２１のストールを示す（S26でＮ）場合は、業務ＡＰ１２は異常終了する（S27）。
【００３１】
業務ＡＰ１２が異常終了する代わりに、アクセス対象データのオーナーのノードをダウンさせても良い。この場合、ＤＢＭＳ２０が、指定されたデータのオーナーのノードを監視ＡＰ１１に通知する。
【００３２】
図３は、図２で業務ＡＰ１２から生成されたトランザクション１３のフローチャートである。トランザクション１３は、共用ＤＢ３０に格納されているデータにアクセスするためにデータの占有をＤＢＭＳ２０に依頼し、その終了を待ち合わせる（S31）。アクセスは更新を含むものとする。当該データのオーナーが他ノードであれば、トランザクション１３は自ノードの資源管理プロセス２１のみならず、当該他ノードの資源管理プロセス２１による処理をも併せて待ち合わせることになる。
【００３３】
データを占有した後、トランザクション１３は、データの更新などをして（S32）、ＤＢＭＳ２０を介してデータの占有解除を行う（S33）。データの占有解除に於いても、データのオーナーが他ノードであれば、トランザクション１３は自ノードおよび当該他ノードの資源管理プロセス２１による処理を待ち合わせることになる。
【００３４】
データへのアクセスを終えたトランザクション１３は、終了を業務ＡＰ１２に報告して（S34）終了する。業務ＡＰ１２は、この終了の報告を図２のS21で待ち合わせている。
【００３５】
図４は、監視ＡＰ１１のフローチャートである。本実施形態の監視ＡＰ１１は起動されると、業務ＡＰ１２からのトランザクション１３の停止通知の受信を待ち合わせる（S41でN）。当該停止通知は、業務ＡＰ１２が、図２のS24で送信するものである。
【００３６】
当該停止通知を受信する（S41でY）と監視ＡＰ１１は、資源管理プロセス２１に対して通信要求をする（S42）。かかる通信要求は、例えば、プロセス間通信機能を使って行われる。監視サーバ１０がＵＮＩＸ（登録商標）システムであれば、ｐｓ（process status）コマンド等である。
【００３７】
この場合、資源管理プロセス２１のプロセス識別子は、監視ＡＰ１１が予め記憶しているものとする。プロセス識別子が、監視サーバ１０の所定の記憶域に記憶されていて、監視ＡＰ１１がその記憶域を参照して得るようにしても良い。
【００３８】
当該通信が成功すれば（S43でY）、監視ＡＰ１１は、業務ＡＰ１２に資源管理プロセス２１の正常を示す監視結果報告を送信する（S44）。当該通信が失敗すれば（S43でN）、監視ＡＰ１１は、業務ＡＰ１２に資源管理プロセス２１のストールを示す監視結果報告を送信する（S45）。業務ＡＰ１２は、この監視報告を図２のＳ２５で待ち合わせている。
【００３９】
なお、上記通信の成功・失敗は、プロセス間通信機能の戻り値／例外発生で判定する場合もあるし、時間監視で判定する場合もある。また、失敗時には、監視ＡＰ１１は、通信要求を数回再試行しても良い。
【００４０】
さらに、業務ＡＰ１２と監視ＡＰ１１とが、トランザクション１３の停止通知をメッセージとして送受信する代わりに、業務ジャーナル１４を利用しても良い。業務ＡＰ１２は、通常運転記録として、トランザクション１３の生成・終了を含むイベントの発生を業務ジャーナル１４に出力する。監視ＡＰ１１が、この業務ジャーナル１４を定期的に参照して、トランザクション１３が終了しないことを検知（即ち、停止通知を受信）しても良い。
【００４１】
本実施形態の監視サーバ１０は、以下に記載する効果を奏する。
【００４２】
第１の効果は、シェアード・エブリシング型のデータベースに於いて、ノード間共用資源管理に起因するトランザクション１３のストールをより直接的に、また、確実に検出できることである。その理由は、トランザクション１３の停止検出を契機に、監視ＡＰ１１が資源管理プロセス２１に通信要求を出すことで、資源管理プロセス２１の死活を直接検知するからである。
【００４３】
第２の効果は、ノード間共用資源管理に起因するトランザクション１３のストールを早期に検出できることである。その理由は、上述したように当該ストールを確実に検出できるからである。単純なＳＱＬ文を発行することによる検知は、状況によって当該ストールを検知できる場合とできない場合が発生する結果、検知が遅れたり、検知できなかったりする。一方、本実施形態の監視サーバ１０は、より確実に検出する。
【００４４】
本実施形態の監視サーバ１０において、ストール監視対象となるのは資源管理プロセス２１に限定されない。
【００４５】
トランザクション１３が、他のプロセスによる処理を待ち合わせる場合は、そのプロセスをストールの監視対象とすることが出来る。この場合、監視ＡＰ１１は、当該他のプロセスのプロセス識別子を予め記憶している等の必要がある。そのような他のプロセス例としては、通信管理プロセス、遠隔ファイルアクセスプロセス等がある。
【００４６】
図５は、本発明の第２の実施形態における監視ＡＰ１１のフローチャートを示す。第２の実施形態の監視サーバ１０は、第１の実施形態の監視に加え、監視の為の単純なＳＱＬ文の定期的な発行という監視手法を併用する。
【００４７】
本実施形態に於ける監視ＡＰ１１は、第１の実施形態における全ての処理（図４）を実施する（S51乃至S55）。それに加え、S51でＮであると本実施形態の監視ＡＰ１１は、一定時間が経過するたびに（S56でY）、監視のための簡単なＳＱＬ文の発行（監視アクセス）をする（S57）。
【００４８】
このＳＱＬ文は、各監視ＡＰ１１を実行する監視サーバ１０（自監視サーバ１０）が備える共用ＤＢ３０に格納された監視表を更新するものである。このようなＳＱＬ文の発行は、ＤＢＭＳ２０の全体障害の検出を可能にする。
【００４９】
当該ＳＱＬ文が正常に終了すれば（S58でY）、監視ＡＰ１１は監視を継続する。当該ＳＱＬ文が異常終了すれば（S58でＮ）、監視ＡＰ１１は所定の異常処理を行う（S59）。異常処理とは、例えば、自監視サーバ１０のノードダウンである。
【００５０】
本実施形態に於いて、業務ＡＰ１２やトランザクション１３は、第１の実施形態と変わらない。
【００５１】
本実施形態では、業務ＡＰ１２が異常を発生して機能しなくなったときでも、ＤＢＭＳ２０の監視を実行しうる。監視ＡＰ１１が、業務ＡＰ１２に依存せずに、監視用のＳＱＬ文を発行するからである。
【００５２】
以上の説明は、監視ＡＰ１１、業務ＡＰ１２、トランザクション１３およびＤＢＭＳ２０が全て監視サーバ１０に設けられていることを前提としていた。しかし、本発明の監視システム０１は、本構成に限られない。
【００５３】
図６は、第３の実施形態の監視システム０１を示す。本実施形態の監視システム０１は、業務ＡＰ１２、トランザクション１３、ＤＢＭＳ２０と相互に共用する共用ＤＢ３０を各々備えた複数のＤＢサーバ４０と、監視ＡＰ１１を備えた監視サーバ１０で構成される。
【００５４】
この場合、監視ＡＰ１１はＤＢサーバ４０毎に設けても良い。または、一つの監視ＡＰ１１が、全ＤＢサーバ４０を監視しても良い。
【００５５】
本実施形態の監視システム０１は、全体の統一的運用が容易となる。また、各ＤＢサーバ４０の負荷が軽減される。その理由は、監視ＡＰ１１を独立した監視サーバ１０で実行させるからである。
【００５６】
さらには、第４の実施形態では、監視システム０１は、ＤＢＭＳ２０、トランザクション１３、相互に共用する共用ＤＢ３０を各々備えた複数のＤＢサーバ４０と、業務ＡＰ１２と監視ＡＰ１１を備えた監視サーバ１０とで構成されている。図７は、この第４の実施形態の監視システム０１を示す。
【００５７】
この場合、業務ＡＰ１２はＤＢサーバ４０毎に設けても良い。または、一つの業務ＡＰ１２が、全ＤＢサーバ４０に対してトランザクション１３を生成しても良い。
【００５８】
この実施形態では、監視サーバ１０に包含される業務ＡＰ１２は、アクセス対象データのオーナーとなるＤＢサーバ４０内にトランザクション１３を生成することが望ましい。他ノードのデータ占有が少ない方が占有処理のオーバーヘッドが軽減されるからである。この生成は、ＲＰＣ（Remote Procedure Call）などを利用して実現できる。
【００５９】
本実施形態の監視システム０１では、各ＤＢサーバ４０の負荷が第３の実施形態よりさらに軽減される。その理由は、業務ＡＰ１２も、独立した監視サーバ１０で実行させるからである。
【００６０】
さらに、第５の実施形態として、監視システム０１内に、監視ＡＰ１１を備える監視サーバ１０と業務ＡＰ１２を備えるＡＰサーバ５０が別々に設けられていても良い（図８参照）。
【００６１】
本実施形態の監視システム０１は、監視サーバ１０および各ＤＢサーバ４０の両者の負荷が軽減される。その理由は、業務ＡＰ１２を独立したＡＰサーバ５０で実行させるからである。
【００６２】
これらの第３乃至第５の実施形態では、ユーザは、監視ＡＰ１１、業務ＡＰ１２、ＤＢＭＳ２０、トランザクション１３の負荷に応じた最適な監視システム０１を構成できる。各々の機能のサーバ間分散がなされるからである。
【００６３】
本発明の最も特徴的な点は、監視サーバ１０が、監視ＡＰ１１を備え、当該監視ＡＰ１１がプロセスによる処理を待ち合わせるトランザクション１３の停止通知を受信して、当該プロセスと通信してそのプロセスのストールを検知することにある（図９参照）。
【図面の簡単な説明】
【００６４】
【図１】監視システムの全体構成を示す図である。
【図２】業務ＡＰのフローチャートである。
【図３】トランザクションのフローチャートである。
【図４】監視ＡＰのフローチャートである。
【図５】第２の実施形態の監視ＡＰのフローチャートである。
【図６】第３の実施形態の監視システムの全体構成を示す図である。
【図７】第４の実施形態の監視システムの全体構成を示す図である。
【図８】第５の実施形態の監視システムの全体構成を示す図である。
【図９】監視サーバの特徴的構成を示す図である。
【符号の説明】
【００６５】
０１    監視システム
１０    監視サーバ
１１    監視ＡＰ
１２    業務ＡＰ
１３    トランザクション
１４    業務ジャーナル
２０    ＤＢＭＳ
２１    資源管理プロセス
２２    ノード内ロック部
３０    共用ＤＢ
４０    ＤＢサーバ
５０    ＡＰサーバ
【図１】
2009064378.tif 000003
【図２】
2009064378.tif 000004
【図３】
2009064378.tif 000005
【図４】
2009064378.tif 000006
【図５】
2009064378.tif 000007
【図６】
2009064378.tif 000008
【図７】
2009064378.tif 000009
【図８】
2009064378.tif 000010
【図９】
2009064378.tif 000011