(57)【要約】  本発明は、監視装置（ＤＦＷ）及びクラスタシステムのノード（Ｃ）の少なくとも２つのリソース（Ｍ１，Ｍ２）の監視方法に関する。優先度（Ｐ）が少なくとも２つのリソースにそれぞれ割り付けられる。監視装置（ＤＦＷ）及び方法では、監視されるべき少なくとも２つのリソース（Ｍ１，Ｍ２）のうちの１つが、そのリソースの監視検出器（Ｄ１，Ｄ２）に加えて、割り付けられた優先度（Ｐ）に従って選択される。監視検出器が構成され、リソースが、監視検出器により１回監視される。監視検出器により実行された監視の結果が、示される。割り付けられた優先度（Ｐ）による選択と１回の監視とにより、選択の結果として、ノード（Ｃ）での計算時間を削減することが可能である。
2007515727.tif 000002
【特許請求の範囲】
【請求項１】
クラスタシステムのノード（Ｃ）の少なくとも２つの監視されるべきリソース（Ｍ１，Ｍ２，ＤＢ，Ｘ）を監視する、クラスタシステムのノード（Ｃ）における監視装置（ＤＦＷ）であって、前記監視されるべきリソース（Ｍ１，Ｍ２，Ｘ，ＤＢ）には、動的優先度（Ｐ）が割り付けられ、
前記監視されるべきリソースに割り付けられた前記優先度（Ｐ）に基づいて、前記少なくとも２つのリソース（Ｍ１，Ｍ２，Ｘ，ＤＢ）から１つのリソースを選択する選択手段（ＫＥ）と、
前記監視されるべきリソース（Ｍ１，Ｍ２，Ｘ，ＤＢ）の監視形式用に構成された少なくとも１つの監視検出器（Ｄ１，Ｄ２，Ｄ３，Ｄ４）と、
前記監視検出器（Ｄ１，Ｄ２，Ｄ３，Ｄ４）を前記監視されるべきリソース（Ｒ１，Ｒ２，Ｘ，ＤＢ）に割り付ける手段（ＫＥ２）と、
前記監視検出器（Ｄ１，Ｄ２，Ｄ３，Ｄ４）による前記監視されるべきリソース（Ｒ１，Ｒ２，Ｘ，ＤＢ）の１回の監視後、前記監視検出器（Ｄ１，Ｄ２，Ｄ３，Ｄ４）の実行が終了されるように構成された、前記監視検出器（Ｄ１，Ｄ２，Ｄ３，Ｄ４）を実行する手段（ＫＥ３）と、
を備える装置。
【請求項２】
前記選択手段（ＫＥ１）は、前記少なくとも２つの監視されるべきリソース（Ｍ１，Ｍ２，Ｘ，ＤＢ）が、その割り付けられた優先度により定められる順序に配置されたリスト（Ｌ１）を有する、ことを特徴とする請求項１に記載の装置。
【請求項３】
前記監視検出器（Ｄ１，Ｄ２，Ｄ３，Ｄ４）により前記監視されるべきリソース（Ｍ１，Ｍ２，ＤＢ，Ｘ）に、前記監視検出器（Ｄ１，Ｄ２，Ｄ３，Ｄ４）による前記リソース（Ｍ１，Ｍ２，Ｘ，ＤＢ）の監視のために必要とされる平均実行時間（Ｔ）が割り付けられる、ことを特徴とする請求項１又は２に記載の装置。
【請求項４】
該監視装置（ＤＦＷ）は、監視のために必要とされる前記平均実行時間（Ｔ）を求めるように構成されている、ことを特徴とする請求項３に記載の装置。
【請求項５】
規定された継続時間（ＺＩ）が、時間間隔（Ｉ）毎に提供され、前記少なくとも１つの監視検出器（Ｄ１，Ｄ２，Ｄ３，Ｄ４）の前記平均実行時間（Ｔ）は、前記規定された継続時間（ＺＩ）より短い、ことを特徴とする請求項３又は４に記載の装置。
【請求項６】
前記少なくとも１つの監視検出器（Ｄ１，Ｄ２，Ｄ３，Ｄ４）は、自律的に実行可能なプログラムとして構成される、ことを特徴とする請求項１乃至５のいずれか１項に記載の装置。
【請求項７】
前記少なくとも１つの監視検出器（Ｄ１，Ｄ２，Ｄ３，Ｄ４）は、動的ライブラリの機能として、または、動的ライブラリ（Ｘ．ｓｏ，Ｚ．ｓｏ）として構成される、ことを特徴とする請求項１乃至５のいずれか１項に記載の装置。
【請求項８】
該監視装置（ＤＦＷ）は、前記ノード（Ｃ）で実行され、前記監視されるべきリソースから独立した処理要素（ＴＨ１）を有し、前記実行手段（ＫＥ３）は、前記監視されるべきリソースに必要とされる前記監視検出器（Ｄ１）を前記処理要素（ＴＨ１）と連結するために、構成される、ことを特徴とする請求項１乃至７のいずれか１項に記載の装置。
【請求項９】
該監視装置（ＤＦＷ）は、前記少なくとも１つの監視検出器（Ｄ１，Ｄ２，Ｄ３，Ｄ４）と結合され、前記監視検出器（Ｄ１，Ｄ２，Ｄ３，Ｄ４）の状態報知を送出するように構成された第１のインターフェース（Ｓ１）を有する、ことを特徴とする請求項１乃至８のいずれか１項に記載の装置。
【請求項１０】
該監視装置（ＤＦＷ）は、ユーザ指令の入力のために構成された第２のインターフェースを有する、ことを特徴とする請求項１乃至９のいずれか１項に記載の装置。
【請求項１１】
前記監視されるべきリソース（Ｍ１，Ｍ２）は、前記クラスタシステムの前記ノード（Ｃ）のファイルシステム内の入口ノードである、ことを特徴とする請求項１乃至１０のいずれか１項に記載の装置。
【請求項１２】
前記監視されるべきリソース（Ｘ）は、プログラム、またはデータベース（ＤＢ）、またはネットワークリンク（Ｎ１）である、ことを特徴とする請求項１乃至１０のいずれか１項に記載の装置。
【請求項１３】
該監視装置（ＤＦＷ）は、インターフェース（Ｓ１，Ｓ２）を介して、監視されるべきリソースを受け付けるように構成されている、ことを特徴とする請求項１乃至１２のいずれか１項に記載の装置。
【請求項１４】
該監視装置（ＤＦＷ）は、自律プロセスである、ことを特徴とする請求項１乃至１３のいずれか１項に記載の装置。
【請求項１５】
クラスタシステムのノード（Ｃ）の少なくとも２つのリソース（Ｍ１，Ｍ２）の監視方法であって、前記少なくとも２つのリソースに動的優先度（Ｐ）が割り付け可能であり、
（ａ）前記割り付けられた優先度（Ｐ）に基づいて、前記監視されるべき少なくとも２つのリソース（Ｍ１，Ｍ２）の１つを選択し、
（ｂ）前記監視されるべきリソース（Ｍ１，Ｍ２）の監視のために必要とされる監視検出器（Ｄ１，Ｄ２）を選択し、
（ｃ）前記選択した監視検出器（Ｄ１，Ｄ２）に前記監視されるべきリソースを割り付け、
（ｄ）前記監視検出器を実行し、前記監視検出器によるリソースの１回の監視後に終了し、
（ｅ）前記監視検出器により実行された監視結果を報知する、方法。
【請求項１６】
ステップ（ｃ）の前記割り付け処理は、前記監視されるべきリソースの前記監視検出器への変数の受け渡しにより実行される、ことを特徴とする請求項１５に記載の方法。
【請求項１７】
前記優先度（Ｐ）は、数値により構成される、ことを特徴とする請求項１５又は１６に記載の方法。
【請求項１８】
前記監視されるべきリソースの監視のための時間間隔（Ｉ）で第１継続時間（ＺＩ）が規定され、少なくとも前記ステップ（ｃ）乃至（ｅ）が、前記規定された継続時間（ＺＩ）が平均で超えられていないときのみ実行される、ことを特徴とする請求項１５乃至１７のいずれか１項に記載の方法。
【請求項１９】
前記第１継続時間（ＺＩ）は、利用可能な計算能力の百分率値により規定される、ことを特徴とする請求項１８に記載の方法。
【請求項２０】
前記監視されるべきリソース（Ｍ１，Ｍ２）がその優先度（Ｐ）の順序に配置されたリスト（Ｌ１）が、前記選択のために形成される、ことを特徴とする請求項１５乃至１９のいずれか１項に記載の方法。
【請求項２１】
監視されるべきリソースの前記優先度（Ｐ）は、前記監視されるべきリソースのいかなる監視も前記第１継続時間（ＺＩ）に実行されない場合に増加される、ことを特徴とする請求項１８乃至２０のいずれか１項に記載の方法。
【請求項２２】
監視されるべきリソースの監視のための実行時間（Ｔ）は、前記監視されるべきリソースについての前記監視検出器により割り付けられる、ことを特徴とする請求項１５乃至２１のいずれか１項に記載の方法。
【請求項２３】
監視されるべきリソースの監視のための実行時間（Ｔ）は、監視のために必要とされる前記監視検出器の実行により決定される、ことを特徴とする請求項２２に記載の方法。
【請求項２４】
ステップ（ｃ）にて前記監視検出器と連結され、ステップ（ｄ）の完了後に再度前記監視検出器から解除される、少なくとも１つの空転処理要素（ＴＨ１）が開始される、ことを特徴とする請求項１５乃至２３のいずれか１項に記載の方法。
【請求項２５】
それによってユーザが前記監視検出器によるリソースの監視を実行するインターフェース（Ｓ１）が提供される、ことを特徴とする請求項１５乃至２４のいずれか１項に記載の方法。
【請求項２６】
前記監視検出器は、動的ライブラリの機能として、または動的ライブラリとして構成される、ことを特徴とする請求項１５乃至２５のいずれか１項に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、監視検出器の管理及び制御するクラスタシステムのノードの装置に関する。また、本発明は、クラスタシステムの監視されるべき少なくとも２つのリソース用の監視検出器の制御及び管理方法に関する。
【背景技術】
【０００２】
単独のコンピュータから形成されるクラスタ内に複数のノードを有するクラスタシステムは、利用可能性が高くあるべきソフトウェア用に使用されることが多い。このために、クラスタシステムは、依存管理サービス（reliant management service）ＲＭＳとしても知られ、クラスタ上で実行している利用可能性の高いソフトウェアを監視する管理及び制御ソフトウェアを有する。ここで、利用可能性の高いソフトウェア自体は、クラスタのノードで実行されるか、または異なるノードに提供される。通常、管理ソフトウェアＲＭＳも、異なるノードに、分散化されて提供される。
【０００３】
利用可能性の高いソフトウェアまたはその一部のエラーフリーの実行が、もはや、クラスタの１つのノードで確保されないときには、管理ソフトウェアＲＭＳが、アプリケーションまたはその適切な部分を終了して、他のノードでこのアプリケーションを新規に開始する。利用可能性の高いアプリケーションまたは利用可能性の高いアプリケーションの一部の監視は、ＲＭサービスにより制御される所謂監視検出器によって実行される。リソースとして表され、リソースの状態を管理ソフトウェアＲＭＳに報知するアプリケーションの特定の部分それぞれを、これらの監視検出器が、監視する。
【０００４】
このことの一例が、クラスタシステムの一部であるノードＮ１を示す図６に見ることができる。ノードＮ１は、管理ソフトウェアとして、依存管理システムＲＭＳを有する。さらに、利用可能性の高いアプリケーションＡＰＬが、ノードＮ１で実行され、リンクＣ１を介して、メモリ管理システムＦＳと、相互にデータを交換する。アプリケーションＡＰＬを監視するために、管理ソフトウェアＲＭＳは、それぞれの監視検出器Ｄ１，Ｄ２及びＤ３を起動する。これらの検出器それぞれは、利用可能性の高いソフトウェアＡＰＬの１つの定められたリソースを監視するように特別に構成されている。例えば、検出器Ｄ３は、アプリケーションＡＰＬとデータ管理システムＦＳとの間の通信リンクＣ１を監視する。他の検出器Ｄ２は、利用可能性の高いアプリケーションＡＰＬを、これらがなお実行されているかどうかの連続した問い合わせに基づいて監視し、帰還報知を送信する。第３の検出器Ｄ１は、例えば、利用可能性の高いアプリケーションＡＰＬ用に必要とされる使用可能な一時メモリを監視する。
【０００５】
それぞれの監視検出器の連続した状態報知に基づいて、監視検出器により監視されているそれぞれのリソースの故障または他の発生している問題の際に、管理ＲＭＳは、好適な手段を講じる。そこで、例えば、管理ＲＭＳは、利用可能性の高いソフトウェアを終了して、図示しない第２のノードで新規に開始することが可能である。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
それぞれの監視検出器は、管理ソフトウェアＲＭＳにより互いに独立して起動される。しかし、それぞれの検出器が、対応する記憶領域及び計算能力を消費するので、このことは、ノードの高いシステム負荷に導く。最悪の場合、好ましくない構成またはノード内の非常に多数の監視されたリソースにより、監視検出器が、利用可能な計算能力の大部分を消費する可能性がある。その場合、実質的な使用には、過少であるので利用可能にはならない。さらに、管理ソフトウェアは、その実際の実行及びリソースの監視が現時点で必要ではない監視検出器からの状態報知を受信する。すべての帰還された状態報知の処理は、常に、計算時間を増加させ、管理ソフトウェアに不必要に負荷を与える。
【０００７】
このため、本発明の課題は、それにより監視のためのシステム負荷が目的に応じた要求に合致する一方、リソースの適切な監視を確実にする、クラスタシステムのノードの装置を提供することである。さらなる課題は、同時に低いシステム負荷で、効率的に作動する監視検出器の制御及び管理方法を提供することである。
【課題を解決するための手段】
【０００８】
これらの課題は、独立クレームの対象により解決される。
【０００９】
クラスタシステムのノードで監視されるべき少なくとも２つのリソースを監視するために、監視装置が、クラスタシステムのノードに提供される。ここで、監視されるべきリソースには、それぞれ、監視されるべきリソースの重要度の尺度を表す優先度が割り付け可能である。装置は、監視されるべきリソースに割り付けられた優先度に基づく、監視されるべき少なくとも２つのリソースから１つのリソースの選択手段を有する。さらに、装置は、監視されるべきリソースの監視形式用に構成された少なくとも１つの監視検出器を有する。最後に、装置は、監視されるべきリソースへの監視検出器の割付け手段と、監視検出器の実行手段とを有する。割付け手段は、実行された監視検出器によるリソースの１回の監視後、実行が、それによって終了または停止されるように構成されている。
【００１０】
この実施形態では、装置は、それぞれが監視されるべきリソースに対して、すなわち、詳細には、監視されるべきリソースに必要とされる監視検出器が下流に配置される上流段を形成する。詳細には、監視されるべきリソースに必要とされる監視検出器それぞれの実行は、もはや互いに独立ではなく、装置によりまとめて制御される。このため、装置を用いて、その監視が実際の時間に必要なリソースのみを常に監視することができる。さらに、監視されるべきリソースに必要とされる監視検出器が、選択処理後にのみ実行されるので、装置により、追加的に、ノードでの計算時間が削減される。
【００１１】
このとき、監視は、監視が行われた後に監視検出器の実行が再度停止されるように実行される。そのため、監視は、一回のみ実行される。もちろん、装置は、必要な場合には、監視されるべきリソースをより頻度多く選択して、このために必要とされる監視検出器を複数回実行可能である。しかし、この場合、監視検出器は、連続的に作動されず、常に、監視されるべきリソースに関する状態報知を帰還するまでの間のみ、実行される。しかし、ここで、監視検出器それ自体は、複数回の監視のために実施可能である。監視検出器の制御された計測値の場合、このことは、実際に有利である。本発明によれば、監視検出器は、複数の監視動作を実行し、そして、それぞれの計測値を表す状態報知全体を帰還する。検出器の実行は、状態報知の伝達後に終了される。
【００１２】
それぞれの優先度が少なくとも２つのリソースに付与される、クラスタシステムのノードの少なくとも２つのリソースの監視方法は、
（ａ）割り付けられた優先度に基づいて、監視されるべき少なくとも２つのリソースの１つを選択し、
（ｂ）監視されるべきリソースの監視のために必要とされる監視検出器を選択し、
（ｃ）前記監視検出器にリソース変数を割り付け、
（ｄ）前記監視検出器を起動または実行して、前記監視検出器によりリソースの監視を１回実行し、
（ｅ）前記監視検出器により実行された監視結果を報知する、
ステップを有する。
【００１３】
本発明による方法では、監視されるべきリソースの監視は、連続的ではなく、監視されるべきリソースに割り付けられた監視検出器の１回の実行によってのみ、実施される。もちろん、監視検出器それ自体は、種々の方法で、監視されるべきリソースを監視可能であり、詳細には、監視検出器が結果を帰還する前に、短い時間間隔で、複数回監視することも可能である。しかし、本発明によれば、結果または状態報知は、監視検出器の実行について１回のみ帰還される。
【００１４】
割り付けられた優先度に基づいて、監視されるべきリソースが、一の時点で、選択される。割り付けられた優先度に基づく選択が必要なときにのみ、監視検出器が実行されるので、これによって、クラスタシステムのノードでの計算時間を削減させる。詳細には、リソースと監視検出器とが組み合わされて、一体なものとしてみなされる。そのため、それぞれの検出器の独立性は、もはや、与えられない。
【００１５】
監視されるべきリソースと、このために必要とされる監視検出器とは、多様な形態である。本発明の１つの実施形態では、監視されるべきリソースは、クラスタシステムのノードのファイルシステム内の入口点により形成される。そのため、監視検出器は、監視されるべき入口点がなお有効であるかどうかを検査するように構成される。１つの有利な実施形態においては、入口点は、クラスタシステムのノードのファイルシステムに含まれるバルクメモリの第２のファイルシステムにより提供される。しかし、正当で、リソースの監視のために必要とされる監視検出器が、選択したリソースに基づいて、常に、選択される。
【００１６】
他の実施形態では、監視検出器は、利用可能なハードディスクまたは他のバルクメモリを監視するように構成される。
【００１７】
再度、本発明の他の実施形態では、監視されるべきリソースは、実行されているプログラムであり、このために必要とされる監視検出器は、実行されているプログラムがなお動作しているかどうかを検査する検出器である。監視されるべきさらなるリソースは、クラスタシステムのさらなるノードのネットワークリンクである。このために必要とされる監視検出器は、ネットワークリンクの状態を検査する検出器である。さらなる他のリソースは、監視されるべきデータベース、ノードのシステム負荷、実行されているプログラムの、またはクラスタシステムのノード内部の自在に使用可能なメモリの、プロセッサ負荷である。種々のリソースのそれぞれのタイプについて、定められた監視を実行する１つの監視検出器が、提供される。１つのリソースについて、複数の異なる監視形式が、そのため異なる監視検出器が存在する。
【００１８】
装置の改良では、選択手段は、その中において、監視されるべき少なくとも２つのリソースが、これらの優先度による所定の順序に配置されたリストを有する。このため、装置が、リストに基づいて、監視されるべきリソースを判別し、監視検出器を実行することにより、監視されるべきリソースの特に簡単な選択が可能である。さらなるリソースの追加またはリストからのリソースの除外により、リストは、特に容易に変更可能である。このとき、装置は、リストから選択されたリソースを、そのリソースを監視するのに必要とされる対応する監視検出器に、自動的に提供するように構成される。
【００１９】
この場合、監視されるべきリソースの優先度が数値から構成されることは、特に有効である。これによって、高い自由度が全体として達成され、監視されるべきリソースの優先度が容易に変更されることにより、変更に動的に対応することが可能である。
【００２０】
本発明のさらなる有利な実施形態では、時間間隔毎の所定の時間が提供される。装置は、監視検出器の平均実行時間が、所定の時間より短いように構成される。装置は、リソースを選択して、対応する監視検出器を、実行されている監視検出器の１回の実行時間全体が所定の時間に到達するまで、１回実行するように構成される。そのため、この所定の時間により、装置がリソースを監視可能な、時間間隔毎の時間領域が与えられる。言い換えれば、これにより、最大計算容量または一の時間間隔内に装置により必要とされる計算時間が規定可能である。監視検出器が、装置により開始され、管理されて、従ってもはや互いに独立ではないので、このことは可能である。
【００２１】
本発明の改良は、リソースの監視のために必要とされる第２の時間が、監視されるべきリソースに割り付けられることにより、特徴付けられる。このため、装置が、監視のために必要とされる時間を正確に判断することが可能である。好適には、装置が、監視のために必要とされる時間を決定するように構成される。このことは、適切に、監視検出器の時間測定により実行される。
【００２２】
本発明の他の実施形態では、装置は、監視検出器の１回の実行後に、監視検出器からの状態報知を送出するように構成された第１のインターフェースを有する。このため、重要な状態メッセージが、特に優先された管理及び制御装置に報知可能である。本発明の他の実施形態では、装置は、ユーザ指令を受けるように構成された第２のインターフェースを有する。このため、ユーザ側でも、監視検出器によりリソースを常時監視することが可能であることになる。このことは、特に、監視検出器からの実際の状態報知が必要とされる場合に、有利である。この装置の実施形態では、第１のまたは第２のインターフェースは、監視されるべきリソースを受け付けるように構成可能である。そのため、新規に監視されるべきリソースが装置に報知可能、または装置により監視されているリソースが監視から除外可能である。
【００２３】
好適には、装置は、クラスタシステムのノード内の自律処理として構成される。そのため、装置は、自律プログラムを形成する。監視検出器は、その報知処理の実行中に、装置の処理要素を形成する。
【００２４】
本発明の他の実施形態は、監視検出器は、自律的に実行可能なプログラムとして構成される。このプログラムは、装置による監視すべきリソースの選択後に、１回実行される。
【００２５】
本発明の１つの特に有利な実施形態では、装置は、クラスタシステムのノードで実行されるが、監視されるべきリソースとは独立した少なくとも１つの空転処理要素を有する。ここで、監視検出器の実行手段は、選択された監視されるべきリソースの監視検出器を、独立の処理要素と連結するように構成される。この実施形態は、監視検出器が、動的ライブラリの機能または動的ライブラリとして構成される場合に、特に有利である。
【００２６】
このようにして、装置は、実行時に、動的ライブラリの機能または動的ライブラリを、空転処理要素と連結し、これを開始して、監視されるべきリソースの監視を実行する。実行後に、連結は、再度解除される。このような実施形態は、特に、速度及び計算の効率が良い。監視検出器を動的ライブラリの機能または動的ライブラリとして構成することにより、特に簡単かつ柔軟な方法で、改良、変更、または誤り訂正が可能である。これによって、他のクラスタ作動システムへの移植も簡略化される。
【００２７】
本方法の１つの実施形態では、監視されるべきリソースの監視のために、第１の時間が、一の時間間隔で、決定される。監視検出器及びこれに連結された処理要素は、規定された時間を超えない間のみ実行される。このとき、本方法は、規定された時間が到達するまでの間反復可能である。そのため、その時間間隔の第１の時間により、監視のために必要とされる最大計算容量が規定される。
【００２８】
好適には、監視されるべき２つのリソースのうちの少なくとも１つが、監視されるべきリソースが、その優先度の順序で配置されたリストから選択する。１つの実施形態では、リストは、規定された時間が到達するまでの間使用される。
【００２９】
特に好適には、監視検出器によりいかなる監視も、その時間間隔での第１の時間内に実行されない場合には、監視されるべきリソースの優先度を増加する。これによって、リソースが、監視時間の不足及び低い優先度により、対応する監視検出器により決して監視されないことが防止される。
【００３０】
好適には、監視されるべきリソースに、監視検出器により監視する時間経過を示す第２の時間が割り付けられる。その代わりに、第２の時間が、監視検出器にも割り付け可能である。
【００３１】
本方法の１つの変形例では、監視のための第２の時間は、選択された監視検出器を実行することにより決定される。このことは、必要とされる継続時間が予め知られていないか、または監視のための継続時間に影響する変数が、継続した実行中に変更される場合、特に有効である。
【００３２】
本方法の１つの実施形態では、いかなる計算時間も消費せず、待機処理として示される空転処理要素が、開始される。監視検出器の選択後、監視検出器が空転処理要素と連結され、そして実行される。好適には、監視検出器は、動的ライブラリの機能または動的ライブラリとして構成される。これにより、監視検出器の空転処理要素との連結は、特に迅速でかつ効率良くされる。監視検出器による結果の報知後、連結は、再度解除され、空転処理は、再度待機して配置される。このとき、空転処理は、ノードの何らの計算時間も必要としない。その代わりに、空転処理要素は、異なる監視検出器と互いに連結可能である。空転処理要素の実施は、特に柔軟である。
【００３３】
本発明のさらなる有利な改良は、従属クレームの対象である。
【００３４】
その単独の実施形態及び変形が、必要に応じて組み合わせ可能な本発明は、図面を参照して、以下に詳細に説明される。
【発明を実施するための最良の形態】
【００３５】
最初に、図４に基づいて、本発明に係る装置が使用される環境が説明される。図４は、クラスタシステムの２つのノードＣ及びＣ２を示す。これらは、ネットワークリンクＮ１を介して相互に結合されている。複数の監視されるべきリソースを有する利用可能性の高いアプリケーションＡＰＬが、ノードＣで実行される。さらに、依存管理システムＲＭＳも、ノードＣで実行される。これは、利用可能性の高いアプリケーションＡＰＬを監視すべき管理及び制御ソフトウェアである。必要な場合には、この管理及び制御ソフトウェアは、高い利用可能性を確保するために、さらなる手段を講じる。このために、利用可能性の高いアプリケーションＡＰＬのそれぞれのリソースを監視することが必要である。
【００３６】
詳細には、リソースは、ノードＣについてのファイルシステム内の２つの入口ノードである。これらは、この実施形態で簡略なハードディスクメモリとして構成される２つの外部バルクメモリＭ１及びＭ２を有する。ハードディスクメモリＭ１は、入力点「／ｕｓｒ／ｏｐｔ」のノードＣのファイルシステムに、ハードディスクメモリＭ２は、入力点「／ｕｓｒ／ｓｈａｒｅ」に組み込まれる。その際、これらの点でファイルシステムに組み込まれているバルクメモリＭ１及びＭ２は、機能が十分であるかどうか、及び、データは読み出し及び書き込み可能かどうかを調べる必要がある。
【００３７】
さらに、利用可能性の高いアプリケーションＡＰＬは、ノードＣ２に構成されたデータベースＤＢにアクセスする。このために、ノードＣのアプリケーションＡＰＬとノードＣ２のデータベースＤＢとの間のリンクを検査する必要がある。最後に、利用可能性の高いアプリケーションＡＰＬのグラフィックユーザインターフェースについてのノードＣにおけるウィンドウマネジャーＸも、監視される。
【００３８】
本発明によれば、依存管理サービスＲＭＳと結合された上流の監視装置ＤＦＷが、これらすべてのリソースを監視するために提供される。また、監視装置ＤＦＷは、段または検出器フレームワークとしても表され、ノードＣの自律処理として構成される。検出器Ｄ１，Ｄ２，Ｄ３及びＤ４は、この装置の一部である。これらは、リソースの監視目的に対応し、監視装置ＤＦＷにより制御される。この場合に監視されるべきリソースは、依存管理サービスＲＭＳから段ＤＦＷに受け渡され、または変数として報知される。
【００３９】
図２は、本発明の監視装置ＤＦＷのより詳細なブロック図を示す。図４のようにされたそれぞれのリソースは、独立した検出器Ｄ１，Ｄ２，Ｄ３及びＤ４により監視され、しかし、これらの検出器は、管理装置ＫＥにより制御される。これらは、監視装置の検出器部分と同一であり、詳細には後述するさらなる論理ブロックを有する。
【００４０】
上流の優先装置ＤＦＷは、インターフェースＳ１を介して依存管理サービスＲＭＳと通信する目的に対応する。このため、装置は、システムＲＭＳから、監視されるべきリソースの情報を受信する管理装置ＫＥを有する。さらに、ユーザデータ及びユーザ指令は、インターフェースＳ２を介して、管理装置ＫＥに転送される。管理装置ＫＥは、それぞれの独立した検出器Ｄ１，Ｄ２，Ｄ３及びＤ４を制御及び管理する。
【００４１】
独立した検出器は、実行時間に起動される動的ライブラリＹ．ｓｏ，Ｚ．ｓｏ及びＸ．ｓｏにより構築される。ここで、動的ブロックＹ．ｓｏは、ファイルシステム内の入口点を監視するために必要である機能すべてを有する。理解されるように、２つの監視検出器Ｄ１及びＤ２は、同一のライブラリＹ．ｓｏにより構築される。しかも、この場合、監視検出器は、ライブラリＹ．ｓｏの同一の機能を示す。
【００４２】
管理装置ＫＥにより、バルクメモリＭ１及びＭ２の入口点の監視時に、動的ライブラリＹ．ｓｏの監視機能は、一組の変数とともに実行される。そのため、監視検出器Ｄ１及びＤ２は、実行時間に、同一の機能を有するが、この機能に受け渡される異なる変数を有する。検出器Ｄ１についての変数が、メモリＭ１の監視のための情報を有し、検出器Ｄ２について使用される変数が、バルクメモリＭ２の検査のために必要な情報を有する。
【００４３】
実施形態では、受け渡された一組の変数は、メモリＭ１及びＭ２のファイルシステムの入口点であり、例えば、検査されるべきアクセス権の構成である。
【００４４】
図４のノードＣとノードＣ２の間のデータベースリンクＤＢを監視するために、動的ライブラリＺ．ｓｏは、必要な機能のすべてを有する。検査が必要とされる場合には、管理装置ＫＥが、動的ライブラリＺ．ｓｏからの機能を開始する。最後の動的ライブラリＸは、グラフィックユーザインターフェース用のウィンドウマネジャーの状態を検査する監視検出器Ｄ４の機能を有する。
【００４５】
段ＤＦＷは、さらに、すべての独立した検出器について共通に使用可能な一組の機能を用意する。例えば、これは、すべての検出器について同一である、状態報知用の依存管理システムＲＭＳのインターフェースである。同時に、独立した検出器Ｄ１乃至Ｄ４の実行は、管理装置ＫＥにより制御及び管理される。そのため、監視検出器は、検出器フレームワークに完全に包摂され、もはやこれと独立ではない。
【００４６】
図１は、それ自体で種々の装置または手段を有する管理装置ＫＥの構成を詳細に説明する。図は、その監視形式が管理装置ＫＥに知られた、監視されるべきリソースＭ１，ＤＢ及びＸの第１のリストを示す。リソースは、管理サービスを有する依存管理サービスから検出器フレームワークに報知される。リストは、監視のために必要なすべての必要な情報を有する。
【００４７】
ここで、監視されるべきリソースのリストから、１つのリソース、実施例ではリソースＤＢを選択する選択装置ＫＥ１が、提供される。選択は、優先度に基づいて、行われる。しかし、追加的に、さらなる変数が、例えばこれまで消費された計算時間または監視のために必要な時間が、考慮可能である。選択手段ＫＥは、監視されるべきリソースを、リソースに基づく監視形式に好適な検出器を選択して、これに必要な変数を受け渡す割付けユニットに転送する。割付け後、図示するようにリストに配置されて、監視の用意がされたリソースＲＳ１，ＲＳ２またはＲＳ３が結果的に与えられる。
【００４８】
さらに、段ＤＦＷは、複数の処理要素ＴＨ１乃至ＴＨ６、空転している所謂スレッド（thread）を有する。したがって、スレッドは、それによってリソースの全く計算時間を必要としないが、監視を実行するように動的ライブラリからの機能と簡単に結合可能な待機処理要素である。スレッドは、それらの開始のためにいかなる追加の計算時間も使用される必要はないが、一旦開始されてその実行を待つという利点を有する。
【００４９】
リソースＲ３を検査するために、装置ＫＥ３が、空の処理要素ＴＨ２を、監視のために必要な動的ライブラリの機能と結合し、リソースＲ３について独立し、ＫＥ２により割付けられる変数を転送し、処理要素ＴＨ２を実行する。これによって、リソースの監視は、割付けられた検出器により実行される。開始、実行、停止及び同期は、この実施形態では、ＵＮＩＸ（登録商標）オペレーティングシステムについてＰＯＳＩＸ標準により実行される。監視機能の実行後、装置ＫＥ３は、再度連結を解除して、スレッドＴＨ２を新規に待機させる。そして、スレッドは、再度、さらなるリソースと連結可能である。監視検出器により生成された結果メッセージは、段ＤＦＷにより、実行後、状態メッセージとして依存管理システムＲＭＳに帰還される。装置ＫＥと処理要素ＴＨとの間で共通に使用されるデータのアクセスは、セムフォア（Semphore）で順序付けされる。
【００５０】
それぞれの処理要素またはスレッドを用いた実行により、複数の監視を同時に実行することが可能である。この場合、リソースの選択、スレッドの監視検出器との連結、各単独のスレッドの開始及び停止は、管理装置ＫＥにより制御される。並行に実行される監視の数は、時間で変更される。段ＤＦＷが追加の処理要素を開始可能であり、または必要に応じてこれらを再度終了することができるので、処理要素ＴＨ１乃至ＴＨ６の数も、時間で変更される。
【００５１】
監視されるべきリソースを段ＤＦＷに任意の時に加えるまたはこれらを除去することも可能である。リソースは、連続的ではなく、定められた時間部分の間のみ監視されるので、このことが可能である。リソースは、変更可能なリストにのみ配置される。
【００５２】
さらに、必要に応じてロードされて実行される動的ライブラリによる検出器の形成によって、高度の自由度が達成可能である。依存管理サービスＲＭＳまたは検出器フレームワークを停止または新規に開始することなく、動的ライブラリは、拡張されたライブラリにより任意の時に取替可能である。ライブラリが拡張または変更される場合、装置ＫＥは、その新規の変更をロードする。そのため、拡張、誤り訂正及び動的再構成は、任意の時に可能である。
【００５３】
クラスタシステムのノードＣにおいて利用可能性の高いアプリケーションＡＰＬのために十分な計算能力を提供するために、ノードＣのそれぞれのリソースの監視のための計算時間を制限することが必要である。さもなければ、リソースは、利用可能性の高いアプリケーションの正確な動作を確保するために十分な頻度で監視されなければならない。図３は、これらの２つの前提条件を満たす段ＤＦＷの実施例を示す。
【００５４】
第１構成ファイルＰ１では、継続時間が、段ＤＦＷがリソースを監視可能な時間間隔で判定される。時間間隔及び継続時間は、ユーザにより、予め定めることが可能である。これは、百分率値、全計算時間の例えば１５％、または絶対値、例えば１秒のうちの１００ｍｓであり得る。例えばハードウェアまたはソフトウェアに関するさらなる前提条件は、構成ファイルにより、同様に考慮可能である。
【００５５】
同時に、第２構成ファイルＰ２では、数字で表した優先度値が、監視されるべき各リソースについて、決定されて割り付けられる。これらは、管理装置のインターフェースＳ１またはＳ２を介して、段ＤＦＷに送信される。
【００５６】
実施例では、優先度値は、依存管理サービスＲＭＳにより、構成ファイルＰ２に定められる。例えば、利用可能性の高いアプリケーションＡＰＬに、例えばバルクメモリＭ１の入口点のリソースより高い優先度を割り付けることが必要である。この優先度は、監視順序を定めるために使用される。より高い優先度を有するリソースは、より低い優先度を有するリソースより、頻度多く監視されなければならない。このため、監視されるべきそれぞれのリソースは、その優先度の基づいてリストＬ１に配置される。
【００５７】
以下の表は、図４の高い利用可能性のアプリケーションＡＰＬのリソース、その割り付けられた優先度、受け渡されるべき変数、及びその後に検査が実行されなければならない時間を示す。そのため、これらは、超えてはならない最大値を規定する。表の最後列は、管理装置ＫＥにより開始された監視検出器が、対応するリソースを監視するために必要とする継続時間を示す。
【表１】
2007515727.tif 000003
【００５８】
このとき、管理装置ＫＥは、構成ファイルＰ１の設定値に基づいて、なお利用可能な時間、リソースの優先順位、各リソースの最後の検査から経過した時間、及び継続時間を調べ、これから、検査されるべきリソースを選択する。
【００５９】
選択されたリソースに対応する検出器は、図１に基づいて、なお空転している処理要素またはスレッドと連結され、変数が送信され、処理要素が実行される。監視の終了後、リンクは、再度解除され、処理要素は、新規のリンクについて使用可能である。リソースは、再度、リストＬ１に受け渡されるが、最後の検査から経過した時間、及び、場合によっては優先度も変更される。さらに、前提条件が変更されている可能性があり、より長かろうと、またはより短かろうと、監視は継続するので、監視検出器が実行に必要とした時間を定めることが有用である。
【００６０】
構成ファイルＰ１により定められた時間窓内に監視または検査できなかったリソースの場合、管理装置ＫＥまたは監視装置ＤＦＷが、優先度を増加する。これにより、検査を待機しているリソースが、低過ぎる優先度のために、決して実行されないことが防止される。
【００６１】
図５は、監視のそのような時間フローを示す。以下の表２は、Ｒ１乃至Ｒ７のリソース、依存管理システムＲＭＳから検出器フレームワークＤＦＷに受け渡されるそれぞれの最初の優先度、及び構成ファイルから取り出された実行のための継続時間を含む。
【表２】
2007515727.tif 000004
【００６２】
このとき、３秒の時間間隔のうちの４５０ｍｓ以内のみ検査を実行することが、段ＤＦＷの基準として、決定される。さらに、３の値より小さい優先度を有するリソースを、その時間間隔で、検査しないことが予定されている。このため、ノードで実行されるさらなる処理は、より多くの計算能力を有する。
【００６３】
所定時間後、図５に示されるリストＬ３が生成される。その優先度ＮＰ、その継続時間１０ｍｓを有するリソースＲ１は、それぞれ、１回のみ実行され、さらにバックグランドで継続する。これは、「非ポーリング」検出器が提供されるリソースである。この検出器が、起動されて、これと連結されたリソースの報知を待つ。「ポーリング」検出器と対照的に、問合せは、積極的には発生しない。これにより、殆どいかなる計算時間も消費されない。検出器Ｒ１は、リソースから報知を受けるとすぐに、検出器フレームワークＤＦＷにより再度終了可能である。
【００６４】
リソースＲ２は、３０ｍｓ継続して最も高い優先度５を有し、対応する監視検出器と連結されて実行される。これと並行して、検出器フレームワークＤＦＷの管理装置ＫＥは、同様に優先度５を有するリソースＲ３及びＲ４それぞれを、そのリストから、存在する１つの処理要素と連結し、監視のために、提供された動的ライブラリに受け渡されるリソースの変数の組を受け渡して、スレッドを実行する。また、優先度３を有するリソースＲ５も、時間間隔内に監視可能である。同一の優先度を有するリソースＲ６は、１００ｍｓの実行時間を有し、このため、４５０ｍｓの記載された時間間隔を超えることになる。
【００６５】
これとは逆に、リソースＲ７の監視検出器の実行時間は、５０ｍｓのみになる。しかし、リソースＲ７は、３より高い優先度を有するリソースのみを検査するという基準により、実行されない。そのため、リソースＲ１乃至Ｒ５は、３秒の時間間隔中、積極的に監視される。監視のために必要とされる全時間は、それぞれの実行継続の合計、全部で４００ｍｓである。しかし、時間間隔内で監視が実行される時間は、規定されない。このタスクは、オペレーティングシステムのスケジューラにより実行される。
【００６６】
検出器フレームワークは、平均で３秒の時間間隔で４５０ｍｓの継続時間を超えないか、または監視のために使用可能な計算時間の１５％以上を使用しないという基準のみを有する。
【００６７】
３秒後に、新規な時間間隔が開始し、段ＤＦＷが、このとき提供されたリソースについての監視検出器を新規に開始する。リソースＲ１は、なお実行されている。処理要素は、リソースＲ２の監視検出器とともに、高い優先度５に基づいて、同様に開始される。リソースＲ３は、前の時間間隔で行われた検査のために、表Ｌ４におけるリソースＲ３の優先度は、再度、最初の値３に減少される。使用可能な十分な時間のために、検出器フレームワークＤＦＷの監視装置ＫＥは、新規にリソースを空転しているスレッドと連結して、監視を実行する。
【００６８】
前の時間間隔で行われたリソースＲ４の監視のために、このとき、リソースＲ４は、再度、最初の優先度値１を有する。リソースＲ５についても同様である。時間不足により、前の時間間隔で、リソースＲ６の検査が可能ではなかったので、検出器フレームワークＤＦＷは、リソースＲ６の優先度を値４に１だけ増加させる。この場合も、これから、監視が実行される。監視のための全継続時間は、この場合、１７０ｍｓになる。
【００６９】
この実施例では、時間間隔毎に、監視されるべき１つのリソースが１回のみ開始される。しかし、例えば、４５０ｍｓの時間間隔内に、リソースＲ２を複数回検査することが可能である。さらに、この実施例では、優先度値は、最後の実行の時点とリンクされる。優先度は、リソースが監視されない各時間間隔にて、増加される。
【００７０】
リソースは、多くの場合、クラスタのメモリ内部のデータ構造により表される。これらは、動的ライブラリにより構成される監視検出器により読み出し可能である。このことは、リソースが異なるタイプの監視を有するときに、特に有効である。
【００７１】
ユーザインターフェースに対する第２インターフェースＳ２により、ノードのリソースの即時の検査のための指令を送信することが可能である。さらに、これにより、このような動的変更を実施するために、段ＤＦＷ用の構成ファイルを新規に読み出すことも可能になる。
【００７２】
装置及び本発明に係る方法により、多数の監視検出器をもはや独立して使用せず、しかしこれらを相互に依存して実行する可能性が提供される。ここで、監視検出器は、１回実行され、このとき、監視検出器自体は、その実行中、監視されるべきリソースを複数回検査することができる。そのため、リソースの複数の異なる観点を検査し、最終の状態報知全部を帰還することができる。
【００７３】
さらに、変更は、ＲＭＳのような高い利用可能性のソフトウェアまたは監視ツールを停止する必要がなく、動的に導入可能である。共通して使用される「検出器フレームワークＤＦＷ」は、共通して使用される機能により、特に効率的かつ省時間のプログラミングを可能にする。ノードに提供される計算時間は、最適に使用され、また、使用可能な計算時間の変更に動的に応答する。
【図面の簡単な説明】
【００７４】
【図１】本発明に係る装置の実施形態である。
【図２】装置の実行手段の回路図である。
【図３】模式的なフローである。
【図４】クラスタシステム内のリソースの例である。
【図５】監視されるべきリソースの時間フローである。
【図６】監視検出器を有する既知の装置である。
【符号の説明】
【００７５】
ＲＭＳ：依存管理サービス
Ｄ１，Ｄ２，Ｄ３，Ｄ４：監視検出器
ＡＰＬ：利用可能性の高いアプリケーション
Ｃ，Ｃ２：ノード
Ｎ１：ネットワーク
Ｍ１，Ｍ２：バルクメモリ
Ｓ１，Ｓ２：インターフェース
ＣＬＩ：ユーザインターフェース
ＤＦＷ：検出器フレームワーク、監視装置
ＫＥ：管理装置
ＫＥ１：選択手段
ＫＥ２：割付手段
ＫＥ３：実行手段
Ｙ．ｓｏ，Ｚ．ｓｏ，Ｘ．ｓｏ：動的ライブラリ
Ｒ１，・・・，Ｒ１１：リソースに割り付けられた検出器
Ｍ１，Ｍ２，Ｘ，ＤＢ：リソース
ＴＨ１，・・・，ＴＨ６：処理要素、スレッド
Ｔ：監視継続時間
Ｌ１：リスト
Ｐ１，Ｐ２：構成ファイル
Ｐ：優先度
Ｌ１，Ｌ３，Ｌ４：リスト
ＺＩ：継続時間
Ｉ：時間
【図１】
2007515727.tif 000005
【図２】
2007515727.tif 000006
【図３】
2007515727.tif 000007
【図４】
2007515727.tif 000008
【図５】
2007515727.tif 000009
【図６】
2007515727.tif 000010
【国際調査報告】
2007515727.tif 000011
2007515727.tif 000012
2007515727.tif 000013
2007515727.tif 000014
2007515727.tif 000015
2007515727.tif 000016