JP2008511903A - ヘルス・モニタリング技術およびアプリケーション・サーバの制御 - Google Patents

Abstract

【課題】 アプリケーション・サーバの性能および可用性を改善する技術を提供する。
【解決手段】 一態様において、ひとつまたは複数のアプリケーション・サーバのヘルス・モニタリングを行う方法は、以下のステップを含む。まず、ひとつまたは複数のヘルス・クラスを指定する。このひとつまたは複数のヘルス・クラスはそれぞれ、上記ひとつまたは複数のアプリケーション・サーバのひとつまたは複数のヘルス・ポリシーを規定するものである。そして、このひとつまたは複数のヘルス・ポリシーのうちの少なくともひとつを監視する。ひとつまたは複数のヘルス・ポリシーの侵害があれば、これを検出する。
【選択図】図１

Description

本発明は、アプリケーション・サーバの性能および可用性の改善、特に、アプリケーション・サーバのヘルス・モニタリング技術に関する。

アプリケーション・サーバ環境では、ホスト・アプリケーションの非効率的な設計に起因する機能不良等のさまざまな不具合が起こりやすい。その典型的な不具合としては、メモリ・リーク、デッドロック、一貫性のないステート／ユーザエラー等が含まれる。これらの欠陥は、アプリケーションの当面の性能および可用性、もしくは性能または可用性に対して悪影響を及ぼすものとなる。ほとんどの場合は、管理者が適当な機器を用いてこれらの状況を検出することができ、管理者は、不具合を修正するための最善の方策を決定する。

各状況においては、アプリケーション・サーバおよびそのホスト・アプリケーションの再起動等、非侵襲的なソフトウェア再構成から、より抜本的な手法に及ぶ特定の修正措置が必要となる。後者は、「ソフトウェア若化」としても知られており、メモリ・リークおよびデッドロックを含む多くのソフトウェア不具合の修復に一般的に利用される（例えば、非特許文献１参照。本明細書中に参考として開示内容を援用）。また、システムは、当面の障害を示唆する測定結果に基づいてソフトウェアを選択的に若化させることができる（例えば、特許文献１参照。本明細書中に参考として開示内容を援用）。このシステムがクラスタの一部である場合は、アプリケーションが要求する若化によって生じる作業負荷を、別のクラスタ・メンバーで対応可能であるか否かの判定が行われる。その場合、システムはクラスタ・マネージャとのやりとりを行って、別のノードでアプリケーションのインスタンスを開始することができる。

Ｗｉｎｄｏｗｓ ＮＴ（登録商標）クラスタ・システム等のクラスタ・システムにおいては、クラスタ上で未修正のまま動作しているアプリケーションに対して障害検出が行われる（例えば、非特許文献２参照。本明細書中に参考として開示内容を援用）。また、アプリケーションの起動、停止、および障害監視を可能とするアプリケーション固有のクラスタ・インターフェース層を設けることもできる。例えば、アプリケーションが正しく機能しているか否かを判定する際の指標となるアプリケーション要求をモニタに含めてもよい。

クラスタ・システムにおける障害検出および障害復帰のための拡張可能な基盤については、例えば、特許文献２に記載されている（本明細書中に参考として開示内容を援用）。ハートビートを用いた基本的な障害検出（例えば、特定のネットワーク上で停止または稼動された監視ノード）は、ユーザ定義モニタによる増強で特定のサブシステムにおける障害検出を行うとともに、ユーザ定義の復帰プログラムによる増強で検出障害からの復帰を行う。また、同時に使用不可となるノードの数がひとつだけとなるようにクラスタのアップグレードを行う「ローリング・アップグレード」については、例えば、非特許文献３に記載されている（本明細書中に参考として開示内容を援用）。
米国特許第６，６２９，２６６号「Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ｔｒａｎｓｐａｒｅｎｔ Ｓｙｍｐｔｏｍ−Ｂａｓｅｄ Ｓｅｌｅｃｔｉｖｅ Ｓｏｆｔｗａｒｅ Ｒｅｊｕｖｅｎａｔｉｏｎ」Ｒ．Ｅ．ハーパー（Ｒ．Ｅ．Ｈａｒｐｅｒ）ら 米国特許第５，８０５，７８５号「Ｍｅｔｈｏｄ ｆｏｒ Ｍｏｎｉｔｏｒｉｎｇ ａｎｄ Ｒｅｃｏｖｅｒｙ ｏｆ Ｓｕｂｓｙｓｔｅｍｓ ｉｎ ａ Ｄｉｓｔｒｉｂｕｔｅｄ／Ｃｌｕｓｔｅｒｅｄ Ｓｙｓｔｅｍ」Ｄ．ディアス（Ｄ．Ｄｉａｓ）ら Ｙ．ホアン（Ｙ．Ｈｕａｎｇ）ら、Ｓｏｆｔｗａｒｅ Ｒｅｊｕｖｅｎａｔｉｏｎ： Ａｎａｌｙｓｉｓ， Ｍｏｄｕｌｅ ａｎｄ Ａｐｐｌｉｃａｔｉｏｎｓ、ＩＥＥＥ第２５回無停止型コンピュータに関する国際シンポジウム、３８１−３９０ページ（１９９５年） Ｒ．ガマシュ（Ｒ．Ｇａｍａｃｈｅ）ら、Ｗｉｎｄｏｗｓ ＮＴ Ｃｌｕｓｔｅｒｉｎｇ Ｓｅｒｖｉｃｅ、ＩＥＥＥコンピュータ、５５−６２ページ（１９９８年８月） Ｅ．Ａ．ブルーアー（Ｅ．Ａ．Ｂｒｅｗｅｒ）ら、Ｌｅｓｓｏｎｓ ｆｒｏｍ Ｇｉａｎｔ−Ｓｃａｌｅ Ｓｅｒｖｉｃｅｓ、ＩＥＥＥインターネット・コンピューティング、４６−５５ページ（２００１年７月／８月）

アプリケーション・サーバの障害検出および若化における近年の進展にもかかわらず、効率的かつ効果的なアプリケーション・サーバ環境の監視技術および発生したエラーへの対処技術の改善が必要となっている。

本発明は、アプリケーション・サーバの性能および可用性を改善する技術を提供する。本発明の一態様において、ひとつまたは複数のアプリケーション・サーバのヘルス・モニタリングを行う方法は、以下のステップを含む。まず、ひとつまたは複数のヘルス・クラスを指定する。このひとつまたは複数のヘルス・クラスはそれぞれ、上記ひとつまたは複数のアプリケーション・サーバのひとつまたは複数のヘルス・ポリシーを規定するものである。そして、このひとつまたは複数のヘルス・ポリシーのうちの少なくともひとつを監視する。ひとつまたは複数のヘルス・ポリシーの侵害があれば、これを検出する。

本発明は、以下の詳細な説明と図面を参照することによって、より完全に理解されるとともに、本発明のその他の特徴および利点についても明らかとなる。

図１は、アプリケーション・サーバのヘルス・モニタリングを行うシステム１００の一例を示す図である。本明細書中で用いる「ヘルス」という用語は、システムの全体的な保全性および性能を意味しており、システムのサーバに適用されたひとつまたは複数のヘルス・クラスによって規定される。システム１００は、マネージャ１０２、ポリシー・データベース１０４、ヘルス・コントローラ１０６、応答マネージャ１０８、ヘルス・センサ１１０、ユーザ・アプリケーション１１２、１１４、１１６、およびシステム管理エージェント１１８を含む。ヘルス・センサ１１０、ユーザ・アプリケーション１１２、１１４、１１６、およびシステム管理エージェント１１８は、システム１００のアプリケーション・サーバを構成する。例示的な一実施形態において、システム１００は、それぞれＪ２ＥＥアプリケーションをホスティングするひとつまたは複数のアプリケーション・サーバを有する。

本発明の例示的な一実施形態によれば、システム１００は、アプリケーション・サーバのヘルス・モニタリングにおいて、ヘルスに関する特定の不具合の検出および応答、もしくは検出または応答を含む手順を実行するように構成されている。すなわち、ステップ１において、マネージャ１０２は、まず初めにヘルス・クラスを指定する。以下に詳述するように、所与のヘルス・クラスは、ルールに基づく記述を使用して、アプリケーション・サーバのひとつまたは複数のヘルス・モニタリング・ポリシーを規定することができる。ステップ２においては、例えばポリシー・データベース１０４に対して、上記指定されたヘルス・クラスの設定が格納される。

ステップ３においては、アプリケーション・サーバのヘルス・モニタリングを行うために、任意のヘルス・センサが設定される。すなわち、ヘルス・ポリシーは、監視する動作環境の属性、ヘルス例外等のポリシー侵害を引き起こす特定の境界ヘルス条件、または侵害を引き起こした条件を修正するための動作、もしくはそれらの組み合わせを指定する。したがって、ステップ４においては、ヘルス・ポリシーの監視が行われる。ヘルス・ポリシーの監視では、まずステップ５ａのように、例えばポリシー・データベース１０４からヘルス・ポリシーを読み出し、ヘルス・ポリシーの侵害が検出された場合には、ステップ５ｂのように修正措置を開始する。修正措置の一例としては、ステップ６のようにアプリケーション・サーバの再起動を実施することが含まれるが、これには限定されない。

例えばヘルス・ポリシー侵害等のヘルス例外を引き起こす条件（トリガ条件）は、例えばヘルス・センサ１１０で観測されたセンサ・データ等のデータに対する一般的な属性値アサーションと考えることができる。すなわち、このトリガ条件は、単純な等価条件あるいは複数のセンサ・データに対する複雑な処理演算のいずれかとなり得る（例えば、例示的な一実施形態において、約６０分間に約１０パーセントの閾値越え（ｔｈｒｅｓｈｏｌｄ ｃｒｏｓｓｉｎｇ）が観測された場合は、エラー条件が検出される）。例えばポリシー・データベース１０４に対するセンサ・データの処理としては、統計関数の適用、システム・イベントの順序付け（一部または全体）に対するアサーションの適用、および範囲指定（観測中のシステム各部を包含または除外）が含まれるが、これらには限定されない。

特定のシステムのヘルス・ポリシーは、ポリシー仕様言語で記述され、ヘルス・コントローラ１０６等のヘルス・コントローラに渡される。ヘルス・コントローラ１０６は、システムの通常動作時におけるヘルス・ポリシーの実施を担うものである。ヘルス・コントローラ１０６は、ヘルス・ポリシーをポリシー・データベース１０４（ローカル・リポジトリ）に格納し、当該マネージド・システムにおける然るべきヘルス・センサ１１０の設定を行って、関連するシステム・データを取得する。設定するヘルス・センサ１１０および使用するパラメータの識別は、ヘルス・ポリシー自体に記述するか、あるいはコンパイル処理の後にヘルス・ポリシー仕様から自動的に取得することができる。

システム動作時、ヘルス・コントローラ１０６は一定期間ごとにヘルス・センサ１１０からデータを収集し、必要なデータ統合および統計処理を行って、例えばポリシー・データベース１０４に格納されたヘルス・ポリシーとのデータ照合を行う。ここで、ヘルス侵害が検出された場合は、その侵害に対する応答が発せられる。この応答では、例えばサービスが維持されるようにシステム１００の再設定と調整を行う。

図２は、アプリケーション・サーバ環境２００の一例を示す図である。アプリケーション・サーバ環境２００は、ネットワーク相互接続２０８を介して接続されたノード２０２、２０４、および２０６を含む。本発明の例示的な一実施形態によれば、各ノード２０２、２０４、および２０６は、それぞれが実行する機能の種類に応じたアプリケーション・サーバ・ソフトウェアのコピーを有している。

アプリケーション・サーバ環境２００は、一例として以下のような種類のノードを含む。ノード２０２は、アプリケーション・サーバ環境の他の部分に対する管理機能の実行を担う管理ノードを構成する。ノード２０４および２０６は、アプリケーション・サーバ・ノードを構成する。本明細書の記載によれば、アプリケーション・サーバ環境２００は、複数のアプリケーション・サーバ・ノードを含む。各アプリケーション・サーバ・ノードは、ひとつまたは複数のアプリケーション・サーバ・インスタンスをホスティングすることができる。そして、各アプリケーション・サーバ・インスタンスは、ゼロまたは複数の企業アプリケーション・モジュール（本明細書では「アプリケーション」とも称する）をホスティングすることができる。

図３は、アプリケーション・サーバおよびクラスタを含むコンピュータ・システム３００の一例を示す図である。すなわち、コンピュータ・システム３００は、アプリケーション・サーバ・ノード３０２および３０４を含む。アプリケーション・サーバ・ノード３０２は、アプリケーション・サーバ・インスタンス３０６および３０８をホスティングする。そして、アプリケーション・サーバ・インスタンス３０６がアプリケーション３１２および３１４をホスティングし、プリケーション・サーバ・インスタンス３０８は、アプリケーション３１６および３１８をホスティングする。アプリケーション・サーバ・ノード３０４は、アプリケーション・サーバ・インスタンス３１０をホスティングする。アプリケーション・サーバ・インスタンス３１０は、アプリケーション３２０および３２２をホスティングする。アプリケーション・サーバ・インスタンス３０８および３１０は、クラスタ３２４を形成する。

コンピュータ・システム３００の環境では、以下に示すアプリケーション・サーバ・インスタンスのグループ分けが可能となる。アプリケーション・サーバ・インスタンス３０６等の「シングルトン（ｓｉｎｇｌｅｔｏｎ）」なアプリケーション・サーバ・インスタンスは、他のプリケーション・サーバ・インスタンスとは独立に動作するとともに、アプリケーションの単一のコピーを有する。アプリケーション・サーバ・インスタンス３０８および３１０等の「クラスタ化」されたアプリケーション・サーバ・インスタンス（「クラスタ」）は、アプリケーション・サーバ・インスタンスの複数のコピーをひとつまたは複数のノード上で動作させる。クラスタは、さらに静的クラスタと動的クラスタに区別することができる。具体的には、動的クラスタにおける動作中のアプリケーション・サーバ・インスタンス数がランタイムで判定されるとともに、アプリケーションに対する観測要求に基づくものであるのに対して、静的クラスタでは、サーバ数が構成により設定される。

図１の説明に関連して上述したように、ヘルス・コントローラ１０６等のヘルス・コントローラは、アプリケーション・サーバ・インスタンスのヘルス・ステータスの監視を担うものである。ヘルス・コントローラの動作には、設定フェーズおよびランタイム・フェーズという２つの側面が存在する。設定フェーズでは、ヘルス・ポリシーの規定が行われる。図４は、ヘルス・ポリシーを規定するシステム４００の一例を示す図である。

すなわち、図４に示す通り、アドミニストレータ４０２は、アドミニストレータ・コンソール４０４を用いて多数のヘルス・クラス４０６を規定する。各ヘルス・クラス４０６は、一連のターゲット（例えば、ひとつまたは複数のヘルス・クラスのメンバー）およびそのターゲットに適用されるヘルス・ポリシーを有する。このターゲットとヘルス・ポリシーは、動的に変更可能である。また、ヘルス・ポリシーは、監視対象となるひとつまたは複数のヘルス条件、実施する修正措置、および応答モードを含む。この情報は、ポリシー・データベース１０４の一部となってヘルス・コントローラ１０６に格納され、コントローラが各ヘルス・クラスを監視する。

図５は、ヘルス・クラスの一例を示す図である。すなわち、ヘルス・クラス４０６は、ターゲット５０２、５０４、５０６、ならびにヘルス条件、応答モード、および応答をそれぞれ表すヘルス・ポリシー５０８、５１０、５１２を含む構成となっている。ターゲット５０２、５０４、５０６等のヘルス・クラス・ターゲットは、ひとつまたは複数の個別のアプリケーション・サーバ（Ｓ）、クラスタ、または動的クラスタ（ＤＣ）を含む構成が可能である。クラスタまたは動的クラスタをターゲットに指定した場合、ヘルス・クラスは、ヘルス・クラスの作成後に追加されたそのクラスタまたは動的クラスタアプリケーション・サーバを含めて、そのクラスタまたは動的クラスタのメンバーであるすべてのアプリケーション・サーバに自動的に適合する。また、ヘルス・クラス・ターゲットは、管理ドメインのすべてのノードを含む構成が可能である。ヘルス・クラス・ターゲットが管理ドメインのすべてのノードを含むインスタンスでは、ヘルス・クラスは単一のターゲットのみを有するとともに、ヘルス・クラスの作成後に追加された任意のアプリケーション・サーバに自動的に適合することになる。

ヘルス条件は、ハードウェアおよびソフトウェア、もしくはハードウェアまたはソフトウェアにおけるエラー状態であって、現在の機能不良または予想される機能不良を示す。ヘルス条件の例としては、非常に高いメモリ使用量または高い割合で内部サーバ・エラーに直結する要求が含まれるが、これらには限定されない。従来のシステムでは、これらの条件について、オペレータがアプリケーション・サーバ環境の動作中にシステムを監視し、不具合が検出された場合には、修正措置を施すようになっている。本技術では、そのような不具合に対する完全に自動化された応答方法を提供する。

本発明の例示的な一実施形態によれば、ひとつまたは複数の以下のようなヘルス条件、すなわち、アプリケーション・サーバの経時（例えば、起動からの時間）、実施作業（例えば、発行要求数）、当面のリソース不具合を示唆するメモリの使用パターン、および内部サーバ・エラー（デッドロック等）を示唆する異常に長い要求応答時間の監視が行われるが、これらには限定されない。

ヘルス・クラスは、ヘルス条件５０８等の厳密にひとつのヘルス条件を監視する。ヘルス条件自体は、メモリ・ヒープ・サイズおよび要求応答時間を含むひとつまたは複数の低レベル・ヘルス・パラメータに関連付けられているが、これらには限定されない。ヘルス・クラスは、検出を行うため、これらの低レベル・ヘルス・パラメータに対して所望の境界を指定する。低レベル・ヘルス・パラメータは、一定期間ごとに評価され、侵害が検出された場合は、当該ヘルス条件が呼び出される。そして、ヘルス・コントローラが、ヘルス・クラスによって指定された修正措置を施す。

応答モード５１０等の応答モードは、ヘルス条件５０８等の検出されたヘルス条件が存在する場合のシステムの応答方法を規定する。本実施形態では、応答モードを用いて、以下３つの考え得る方法のうちのひとつ、すなわち、（１）検出限定（条件の検出により診断メッセージを生成）、（２）監視応答（修正措置の提案と併せてメッセージをアドミニストレータに送信）、または（３）自動応答（修正措置の実行に対して即座に、当該条件への応答をスケジューリング）により修正措置を施す。

図６は、検出限定応答の一例を示す図である。図６に示す検出限定応答６００においては、ひとつまたは複数のヘルス条件６０２がヘルス・コントローラ１０６によって検出・収集され、ログ・エントリ６０４が生成される。

図７は、監視応答の一例を示す図である。図７に示す監視応答７００においては、アクティビティ・エンジン７０２等のアクティビティ・エンジンに要求を受け渡すヘルス・コントローラ１０６によって、ひとつまたは複数のヘルス条件６０２が検出・収集される。アクティビティ・エンジン７０２は、管理者の注意を要する実施可能なメッセージをアプリケーション・サーバ環境内から受信するとともに、その受信の認識および修正措置の承認、もしくは受信の認識または修正措置の承認といった選択肢を与える構成要素である。そして、アクティビティ・エンジン７０２は、ユーザに対して修正措置の承認を要求する等、応答確認のための要求７０４を生成する。応答が確認された場合は、応答７０６が実行に移される。一方、応答が確認されない場合は、上述の検出限定応答と同様に、ログ・エントリ６０４が生成される。

図７に示す例示的な実施形態によれば、応答は、エラー条件が観測されたアプリケーション・サーバの再起動に限定される。この処理は、ソフトウェア若化としても知られている。しかし、システムのアーキテクチャは、単に若化措置には限定されず、いかなる種類の自動または監視修正措置にも対応可能である。

図８は、自動応答の一例を示す図である。図８に示す自動応答８００においては、上述の検出限定応答および監視応答と同様に、ひとつまたは複数のヘルス条件６０２がヘルス・コントローラ１０６によって検出・収集される。そして自動応答８０２が開始される。

ヘルス・コントローラ動作のランタイム・フェーズに関しては、上述の図４におけるヘルス・コントローラ１０６等のヘルス・コントローラが、上述の図５におけるヘルス・クラス４０６等の規定された各ヘルス・クラスを読み出し、上述の図５におけるヘルス・クラスのターゲット５０２、５０４、および５０６等のターゲットごとにヘルス・サブシステムを構成する。ヘルス・サブシステムは、ヘルス・クラスに指定されたヘルス条件の監視を担う高レベルの構成概念である。

ヘルス・サブシステムは、簡単なアプリケーション・プログラム・インターフェース（ＡＰＩ）をヘルス・コントローラに与えることによってヘルス・データ集合の低レベル部分の詳細を隠すことにより、ヘルス条件が当該ヘルス・クラスに対して侵害されたか否かを判定する。そして、ヘルス・サブシステムは、ひとつまたは複数の低レベル・センサを設定して、必要なヘルス・データを取得する。

図９は、ヘルス・サブシステム構成の一例を示す図である。図９において、ヘルス・サブシステム９００は、ヘルス・クラスＡ９０２およびヘルス・クラスＢ９０４を実装するように構成されている。

ヘルス・コントローラ１０６は、ヘルス・クラスＡ９０２のターゲットに対して、経時サブシステム９０６のインスタンスを作成する。そして、経時サブシステム９０６は、所望の境界（例えば、最大許容経時）を有する経時センサ９１０を設定する。同様に、ヘルス・クラスＢ９０４のターゲットごとにメモリ・サブシステム９０８を設定して、誤ったメモリの使用パターンを検出する必要がある。そして、メモリ・サブシステム９０８は、メモリ・ヒープ・サイズ・センサ９１２、ヒープ増加率センサ９１４、およびメモリ・リーク・センサ９１６を初期化する。これらのセンサは、オペレーティング・システムまたはアプリケーション・サーバ環境を通して利用可能な機器を用いてメモリ・ヒープ・サイズ、ヒープ増加率、およびメモリ・リーク等の量を継続的に計算する。センサ９１２、９１４、または９１６のいずれかに対して設定された境界条件が侵害された場合は、メモリ・サブシステム９０８がフラグを立てることにより、ヘルス・クラスに指定された応答（例えば、アプリケーション・サーバの再起動）が後で呼び出される。

図１０は、ヘルス・サブシステムのランタイム動作１０００の一例を示す図である。具体的には、センサ１００４および１００６等のヘルス・センサに対して、ヘルス・サブシステム１００２が境界ヘルス条件の侵害の有無を一定期間ごとに確認する。単一のセンサに関わる条件の場合は、ヘルス・センサに対してトリガ条件のアサーション（ｉｓＴｒｉｇｇｅｒｅｄ）を実行することにより、サブシステムにて侵害の有無を確認することができる。複数のセンサに関わる条件の場合は、サブシステムにおいて、多数のヘルス・センサを侵害の発生に対するトリガ状態とするか、または、センサに対してデータのポーリングを行い、当該条件が侵害されているか否かを判定する。

いったん設定を行えば、各ヘルス・センサは独立して動作し、アプリケーション・サーバ環境１００８に特有の通信機構を用いて、ターゲットから一定期間ごとにヘルス関連データを収集する。取得したヘルス関連データは、ヘルス・クラスに指定された境界パラメータに対する確認が行われる。

ヘルス・センサの境界ヘルス条件の例としては、最大許容サーバ経時（例えば、最大約４８時間まで）、最大実施作業（例えば、最大約１００，０００要求まで）、最大ヒープ・サイズ（例えば、最大約２００メガバイトまで）、および最大許容応答時間（例えば、約９５パーセントの入力要求に対して最大約５秒まで）が含まれるが、これらには限定されない。

図１１は、ヘルス・センサ動作の一例を示す図である。図１１において、境界ヘルス条件１１０４は、ヘルス・センサ１１０２により確認される。境界ヘルス条件の侵害が検出された場合は、センサにフラグ（トリガ）１１０６が立ち、低レベルのヘルス・データ１１０８が収集される。一方、境界ヘルス条件の侵害が検出されない場合は、低レベル・ヘルス・データ１１０８の収集のみが行われる。

ヘルス・コントローラは、そのサブシステムに対して、一定期間ごとにポーリングを行い、そして、サブシステムはセンサを確認する。サーバのサブシステムがヘルス状態に無いと判定された場合は、ヘルス・モニタが応答を開始する。この処理は、設定されたすべてのサブシステムおよびセンサに対して行われる。

特に重要なことは、ヘルス・コントローラのランタイム特性である。動作中のアプリケーション・サーバ環境では、設定は絶え間なく変化する。例えば、ノードの追加および削除、もしくは追加または削除が行われ、ノードに対するアプリケーション・サーバ・インスタンスの組み込みおよび削除、もしくは組み込みまたは削除が行われ、クラスタのメンバー構成の変更が行われる。

選択した構成要素からの設定イベントを「リスニング」して適切に応答することにより、トポロジ・マネージャ等のヘルス・コントローラの構成要素を用いてアプリケーション・サーバ環境の観測を行うことができる。例えば、新しいヘルス・クラスが作成されると、ヘルス・コントローラは、多数のサブシステムおよびセンサを作成して、クラス・ターゲットからデータを取得する。また、ヘルス・クラスが削除された場合は、ヘルス・コントローラによって対応するヘルス・サブシステムが無効化されるとともに、対応するターゲットからのヘルス・パラメータの観測が停止される。さらに、ヘルス・クラスに新しいターゲットが追加された場合は、そのサーバに対して然るべきヘルス・サブシステムが設定されるとともに、観測中のヘルス・サブシステムのリストに追加される。また、ヘルス・クラスからターゲットが削除された場合は、対応するヘルス・サブシステムが無効化される。そして、ターゲットのメンバー構成が変更となった場合（例えば、クラスタ・システムの場合に当てはまる）は、然るべきヘルス・サブシステムの追加および削除、もしくは追加または削除が行われる。

ヘルス・クラスのターゲットは、サーバまたはサーバ群により構成可能であるため、同じヘルス条件を監視する複数のヘルス・クラスを異なるレベルでサーバ上に作成することができる。例えば、クラスタの経時を監視するヘルス・クラスＡを、経時がある値Ｙを超えた場合に再起動を行う命令とともに作成することができる。また、ヘルス・クラスＡのクラスタのメンバーであるサーバの経時を監視する別のクラスＢを、経時がある別の値Ｘを超えた場合に再起動を行う命令とともに作成することができる。この場合、両ヘルス・クラスは矛盾することになる。ヘルス・コントローラは、そのような矛盾を検出し、優先順位規則を用いて適用するヘルス・クラスを判定する。本明細書の記載によれば、同じ種類の条件（例えば、経時または作業）、修正措置、および応答モードを有する複数のヘルス・クラスが所与のサーバに対して規定されている場合に矛盾が生じる。

矛盾が生じると、ヘルス・コントローラは、範囲最小のヘルス・クラスを適用する。例示的な実施形態においては、単一サーバが範囲最小となり、クラスタおよび管理ドメインがこれに続く。また、ユーザが同じ範囲で矛盾するクラスを規定することが回避される。例えば、この規定に係る矛盾の無い条件は、メモリ条件の侵害に関する通知を送出する管理ドメインのヘルス・クラス、およびメモリ条件の侵害時にサーバを自動的に再起動するクラスタのヘルス・クラスである。これら両ヘルス・クラスが応答として自動的に再起動を行う場合は、両クラスが矛盾するため、クラスタのヘルス・クラスがクラスタのサーバに適用されることになる。

ヘルス・コントローラは、そのランタイム挙動を支配する一連の設定パラメータに従って動作する。この設定パラメータとしては、制御周期の長さ（例えば、ヘルス・サブシステムの連続するポーリングの時間周期）、再起動タイムアウト（例えば、再起動の発生に対する最大許容時間。タイムアウトを過ぎると、再起動は失敗と見なされて、ヘルス・コントローラが動作を再試行する）、サーバの再起動回数の最大値（例えば、サーバの再起動に失敗した試行回数の最大値。この後、エラーが記録される）、最小再起動間隔（例えば、サーバを再起動する連続した試行間の最小時間。これにより、不必要に頻発する再起動が防止される）、および再起動制約時間（例えば、ピーク業務時間等の再起動が禁止される時間周期のリスト）が含まれるが、これらには限定されない。

再起動タイムアウト、サーバの再起動回数の最大値、最小再起動間隔、および再起動制約時間のパラメータは、サーバの再起動応答の挙動を制御する。しかし、クラスタ・サーバ用としては、動作中のインスタンスを少なくともひとつ常に保持するのが好ましく、動的クラスタ用としてはユーザ指定の最小数のインスタンスを常に保持するのが好ましい。

図１２は、ひとつまたは複数のアプリケーション・サーバのヘルス・モニタリングを行うシステムの一例を示す図である。装置１２２０は、媒体１２２７と情報のやりとりをするコンピュータ・システム１２２１を含む。コンピュータ・システム１２２１は、プロセッサ１２２２、ネットワーク・インターフェース１２２５、メモリ１２２３、メディア・インターフェース１２２６、および付加的なディスプレイ１２２４を含む。ネットワーク・インターフェース１２２５は、コンピュータ・システム１２２１とネットワークとの接続を可能にする一方、メディア・インターフェース１２２６は、コンピュータ・システム１２２１とデジタル多用途ディスク（ＤＶＤ）またはハードディスク・ドライブ等の媒体１２２７との情報のやりとりを可能にする。

当技術分野で従来から知られているように、本明細書に記述した方法および装置は、具現化されたコンピュータ読み込み可能な符号化手段を有する、コンピュータ読み込み可能な媒体を含む製造物として流通するものであってもよい。コンピュータ読み込み可能なプログラム符号化手段は、コンピュータ・システム１２２１等のコンピュータ・システムと併せて動作することにより、ひとつまたは複数の上記方法を実行するステップの全部または一部の遂行または本明細書に記述した装置の構築が可能である。例えば、コンピュータ読み込み可能な符号は、ひとつまたは複数のアプリケーション・サーバに関して、ひとつまたは複数の指定されたヘルス・クラスにより規定されたひとつまたは複数のヘルス・ポリシーのうちの少なくともひとつを監視するステップと、このひとつまたは複数のヘルス・ポリシーの侵害があればこれを検出するステップとにより上記ひとつまたは複数のアプリケーション・サーバのヘルス・モニタリングを行う方法を実行するように構成されている。コンピュータ読み込み可能な媒体は、記録可能な媒体（例えば、フロッピ・ディスク、ハードディスク・ドライブ、ＤＶＤ等の光ディスク、またはメモリ・カード）であってもよく、あるいは伝送媒体（例えば、光ファイバを含むネットワーク、ワールドワイド・ウェブ、ケーブル、もしくは時分割多重アクセス、符号分割多重アクセス、またはその他の無線周波数チャネルを用いた無線チャネル）であってもよい。また、コンピュータ・システムとの併用に適した情報を格納可能な既知または先進の任意の媒体を用いてもよい。コンピュータ読み込み可能な符号化手段は、コンピュータによる命令およびデータの読み込みを可能とする、磁気媒体上の磁気変動またはコンパクト・ディスク表面上の高さ変動等の任意の機構である。

メモリ１２２３は、プロセッサ１２２２が本明細書に開示した方法、ステップ、および機能を実行するように構成する。メモリ１２２３は分散またはローカルのいずれかの構成となり、プロセッサ１２２２は分散または単独のいずれかの構成となり得る。また、メモリ１２２３は、電気、磁気、または光学メモリ、もしくは、これらの任意の組み合わせ、または他の種類の記憶デバイスとして実装可能である。さらに、「メモリ」という用語は、プロセッサ１２２２からアクセスしたアドレス可能な空間におけるアドレスに対する読み出しまたは書き込みを可能とする任意の情報を網羅できるように十分広く解釈するものとする。この定義によると、ネットワーク・インターフェース１２２５を通してアクセス可能なネットワーク上の情報は、プロセッサ１２２２が当該ネットワーク上から読み出すことができるため、依然としてメモリ１２２３に属する。なお、プロセッサ１２２２を構成する各分散プロセッサは、それ自身のアドレス可能なメモリ空間を有するのが一般的である。また、コンピュータ・システム１２２１の一部または全部は、特定用途向け集積回路または汎用集積回路に組み込むことができる。

付加的なビデオ・ディスプレイ１２２４は、装置１２２０のユーザとの情報のやりとりに適した任意の種類のビデオ・ディスプレイである。一般的に、ビデオ・ディスプレイ１２２４は、コンピュータ用モニタまたはその他同様のビデオ・ディスプレイである。

以上、本発明の実施形態を説明したが、本発明はそのような厳密な実施形態には限定されず、本発明の範囲または思想を逸脱することなく、当業者によりその他さまざまな変更および修正が可能であることは当然のことである。

本発明の一実施形態に係る、アプリケーション・サーバのヘルス・モニタリングを行うシステムの一例を示す図である。 本発明の一実施形態に係る、アプリケーション・サーバ環境の一例を示す図である。 本発明の一実施形態に係る、アプリケーション・サーバおよびクラスタを含むコンピュータ・システムの一例を示す図である。 本発明の一実施形態に係る、ヘルス・ポリシーを規定するシステムの一例を示す図である。 本発明の一実施形態に係る、ヘルス・クラスの一例を示す図である。 本発明の一実施形態に係る、検出限定応答の一例を示す図である。 本発明の一実施形態に係る、監視応答の一例を示す図である。 本発明の一実施形態に係る、自動応答の一例を示す図である。 本発明の一実施形態に係る、ヘルス・サブシステム構成の一例を示す図である。 本発明の一実施形態に係る、ヘルス・サブシステムのランタイム動作の一例を示す図である。 本発明の一実施形態に係る、ヘルス・センサ動作の一例を示す図である。 本発明の一実施形態に係る、ひとつまたは複数のアプリケーション・サーバのヘルス・モニタリングを行うシステムの一例を示す図である。

Claims (23)

1. ひとつまたは複数のアプリケーション・サーバのヘルス・モニタリングを行う方法であって、
   前記ひとつまたは複数のアプリケーション・サーバのひとつまたは複数のヘルス・ポリシーをそれぞれ規定する、ひとつまたは複数のヘルス・クラスを指定するステップと、
   前記ひとつまたは複数のヘルス・ポリシーのうちの少なくともひとつを監視するステップと、
   前記ひとつまたは複数のヘルス・ポリシーの侵害があればこれを検出するステップと、
   を有する方法。
2. 前記ひとつまたは複数のヘルス・クラスの設定を格納するステップをさらに有する、請求項１に記載の方法。
3. 前記指定ステップが、前記ひとつまたは複数のヘルス・クラスのひとつまたは複数のターゲットを規定するステップをさらに有する、請求項１に記載の方法。
4. 検出された前記侵害に基づいて修正措置を施すステップをさらに有する、請求項１に記載の方法。
5. 検出された前記侵害に基づいて修正措置を施すステップが、前記ひとつまたは複数のアプリケーション・サーバのうちの少なくともひとつに対する若化をさらに含む、請求項４に記載の方法。
6. 検出された前記侵害に基づいて自動的な修正措置を施すステップをさらに有する、請求項１に記載の方法。
7. 検出された前記侵害に基づいて修正措置を施すためにユーザの承認を要求するステップをさらに有する、請求項１に記載の方法。
8. 前記ひとつまたは複数のヘルス・ポリシーのうちの少なくともひとつを監視するステップが、前記ひとつまたは複数のアプリケーション・サーバのひとつまたは複数の所定の属性に対する監視を含む、請求項１に記載の方法。
9. 前記侵害を検出するステップが、ひとつまたは複数のヘルス条件に基づいた侵害の検出を含む、請求項１に記載の方法。
10. 前記侵害を検出するステップが、アプリケーション・サーバの経時、実施作業、メモリの使用パターン、および異常に長い要求応答時間からなる群から選択されるひとつまたは複数のヘルス条件に基づいた侵害の検出を含む、請求項１に記載の方法。
11. 前記ひとつまたは複数のヘルス・ポリシーをコンピュータ・システムに実装するステップをさらに有する、請求項１に記載の方法。
12. 前記ひとつまたは複数のヘルス・ポリシーをコンピュータ・システムに実装するステップがヘルス・コントローラの使用を含む、請求項１１に記載の方法。
13. 前記ひとつまたは複数のヘルス・ポリシーのうちの少なくともひとつを監視するステップが、ひとつまたは複数のヘルス・センサの使用を含む、請求項１に記載の方法。
14. 前記ひとつまたは複数のヘルス・ポリシーのうちの少なくともひとつを監視するステップが、前記ひとつまたは複数のヘルス・ポリシーを監視するように自動的に設定されたひとつまたは複数のヘルス・センサの使用を含む、請求項１に記載の方法。
15. 前記侵害を検出するステップが、診断メッセージを生成するステップをさらに有する、請求項１に記載の方法。
16. ヘルス・クラスの追加、ヘルス・クラスの削除、およびヘルス・クラスの変更のうちのひとつまたは複数を監視するために、トポロジ・マネージャを用いるステップをさらに有する、請求項１に記載の方法。
17. ターゲットの追加およびターゲットの削除のうちのひとつまたは複数を監視するために、トポロジ・マネージャを用いるステップをさらに有する、請求項１に記載の方法。
18. クラスタのメンバー構成の変更を監視するために、トポロジ・マネージャを用いるステップをさらに有する、請求項１に記載の方法。
19. 範囲最小のヘルス・クラスを選択することによってヘルス・クラス間の矛盾を解消するステップをさらに有する、請求項１に記載の方法。
20. ひとつまたは複数のアプリケーション・サーバのヘルス・モニタリングを行う装置であって、
    メモリと、
    前記メモリに結合された少なくともひとつのプロセッサであって、
    ひとつまたは複数の指定のヘルス・クラスによって規定された、前記ひとつまたは複数のアプリケーション・サーバのひとつまたは複数のヘルス・ポリシーのうちの少なくともひとつを監視する機能と、
    前記ひとつまたは複数のヘルス・ポリシーの侵害があればこれを検出する機能と、
    を備えたプロセッサと、
    を有する装置。
21. 前記少なくともひとつのプロセッサが、検出された前記侵害に基づいて修正措置を施す機能をさらに備えた、請求項２０に記載の装置。
22. ひとつまたは複数のアプリケーション・サーバのヘルス・モニタリングを行うコンピュータ・プログラムであって、コンピュータに、
    ひとつまたは複数の指定のヘルス・クラスによって規定された、前記ひとつまたは複数のアプリケーション・サーバのひとつまたは複数のヘルス・ポリシーのうちの少なくともひとつを監視するステップと、
    前記ひとつまたは複数のヘルス・ポリシーの侵害があればこれを検出するステップと、
    を実行させる、前記コンピュータ・プログラム。
23. 検出された前記侵害に基づいて修正措置を施すステップをさらに有する、請求項２２に記載のコンピュータ・プログラム。

Images