JP2007531091A - リソースを監視するための方法、装置及びコンピュータ・プログラム - Google Patents

Abstract

【課題】 リソースを監視するための方法、装置及びコンピュータ・プログラムを提供すること。
【解決手段】 複合リソース・モデルを表わし、管理するための機構及びモデルが提供される。リソース・モニタがリソースに配置される場合には、リソース・モニタは、監視下にあるリソースがクラスタ、グリッド又は他の複合構成の一部であることを示す情報を走査する。次に、リソース・モニタは、複合構成であることを理由に、リソースについての監視情報を異なる形で報告するべきかどうかを判断する。リソースについての監視情報を異なる形で報告する場合には、リソース・モニタは、複合リソース・モデルを反映するように報告フォーマットを変更する。次に、リソース・マネジャは監視情報を受け取り、この情報を個々のリソースに適用して、複合リソースについての監視情報を集約することができる。
【選択図】 図１

Description

本発明は、データ処理システムに関し、より具体的には、ネットワーク・データ処理システムにおけるリソースの監視に関する。

リソースを提供するプロセスは非常に複雑になることがあり、数多くの異なる側面で異なることがある。リソースの種類の各々について、提供プロセスは異なるものとなる。モニタは、他のリソースについての情報を提供するリソースである。例えば、モニタを用いて、スイッチが有効であるかどうかを判断することができる。サーバは、モニタを用いて、サーバ・リソースが使い果たされたかどうか判断することができる。計測モニタをリソース上に配置して、請求書作成システムが、作成され収集されたモニタ・データを使用できるようにすることができる。

リソース・モデルは、システム及びアプリケーションに、良好な監視能力及測定基準を与える。しかしながら、リソース・モデルは、モニタが個別で別個のシステム上で動作しているという仮定に基づいている。多くの場合、コンピュータは、クラスタ又はグリッドに集約される。クラスタリングとは、協働する２つ又はそれ以上のコンピュータ・システムを用いることを指す。「クラスタ」という用語は、一般的に、互いにリンクされて、可変的な作業負荷に対処する、又は、１つが故障した場合に動作の継続を提供する複数のサーバのことを指す。

個々のコンピュータ、並びに、コンピュータのクラスタは、グリッドに属することができる。事実、多くの場合、グリッドはクラスタのクラスタとして考えられている。グリッド・コンピューティングは、複数の機械が１つの大きなスーパーコンピュータとして機能するように、ネットワーク全体にわたって中央演算処理ユニット（ＣＰＵ）リソースを共有することである。ピア・ツー・ピア・コンピューティング又は分散コンピューティングとも呼ばれるグリッド・コンピューティングは、いずれかの機械のＣＰＵに未使用容量がある場合、それを、要求される処理ジョブの全体に割り振ることを可能にする。

大企業では、いずれの時点においても、何百又は何千ものデスクトップ機械がアイドル状態で置かれている可能性がある。ＣＰＵは、ユーザが画面を読んでいて、機械と対話していない場合でも、アイドル状態であると考えられることがある。他のコンピューティング・リソースは、一日の様々な時間にアイドル状態であるとすることができる。例えば、データベース・サーバのクラスタ又はそのサブセットは、例えば真夜中等の営業時間外においては、使用されていないとすることができる。好適例として、ニューヨーク・シティの営業時間のピーク時には、インドではほとんどの人が就寝中であると思われる。従って、一日のうちのいずれの時間においても、使用されていない処理サイクルがあり、これらを大きな計算問題のために用いることができるであろう。

コンピュータ又はアプリケーション等のリソースがクラスタ又はグリッドに集約されている場合には、監視されるリソースは、協働的な環境の一部となっており、そのようなものとして扱われる必要があるため、リソース・モニタにより報告される情報の性質は、異なる手法で解釈されることになる。例えば、４つのプロセッサをもつマルチプロセッシング・システムにおいて、このマルチプロセッシング・システムがクラスタ内の４つのサーバのうちの１つであり、各々のサーバが４つのプロセッサをもつマルチプロセッシング・システムである場合に、あるプロセッサが故障したと仮定する。プロセッサの故障がリソース・モニタにより報告されるとき、個々のサーバではなくクラスタについて考えると、この情報の意味は非常に異なるものとなる。個々のコンピュータにとっては、プロセッサの故障は、ＣＰＵリソースの４分の１の故障を表わすが、しかしながら、クラスタにとっては、プロセッサの故障は、ＣＰＵリソースの１６分の１の故障を表わすに過ぎない。

本発明は、従来技術の欠点を認識し、複合リソース・モデルを表わし、管理するための機構及びモデルを提供する。リソース・モニタがリソースに配置される場合には、リソース・モニタは、監視下にあるリソースがクラスタ、グリッド又は他の複合構成の一部であることを示す情報を走査する。次に、リソース・モニタは、複合構成であることを理由に、リソースについての監視情報を異なる形で報告するべきかどうかを判断する。リソースについての監視情報を異なる形で報告する場合には、リソース・モニタは、複合リソース・モデルを反映するように報告フォーマットを変更する。次に、リソース・マネジャは監視情報を受け取り、この情報を個々のリソースに適用して、複合リソースについての監視情報を集約することができる。

第１の態様によれば、監視されるリソースの監視方法であって、監視されるリソースが複合リソースの一部であるかどうかを判断するステップと、監視されるリソースを複合リソースと関連付けるステップと、監視されるリソース及び複合リソースについての監視情報を報告するように監視情報の報告フォーマットを変更するステップと、を含む方法が提供される。

複合リソースは、クラスタ及びグリッドの１つであることが好ましい。この方法は、リソース・マネジャにおいて監視情報を受け取るステップと、複合リソースについての監視情報を集約するステップとを更に含むことがより好ましい。監視されるリソースを複合リソースと関連付けるステップは、監視されるリソースについての入力項目をリソース・データ構造に作成するステップを含むことが更に好ましい。

好ましい実施形態においては、リソース・データ構造はリソース・テーブルである。監視されるリソースを複合リソースと関連付けるステップは、リソース・データ構造における入力項目を、複合リソース・データ構造における入力項目とリンクさせるステップを更に含むことが好ましい。複合リソース・データ構造は、クラスタ・データ構造及びグリッド・データ構造の１つであることがより好ましい。

複合リソースはクラスタであり、監視されるリソースを複合リソースと関連付けるステップは、リソース・データ構造における入力項目を、クラスタ・データ構造における入力項目とリンクさせるステップを更に含むことが好ましい。この方法は、クラスタがグリッドの一部であるかどうかを判断するステップと、クラスタをグリッドと関連付けるステップとを更に含むことがより好ましい。クラスタをグリッドと関連付けるステップは、クラスタ・データ構造における入力項目を、グリッド・データ構造における入力項目とリンクさせるステップを含むことが更に好ましい。

好ましい実施形態においては、監視されるリソースが複合リソースの一部であるかどうかを判断するステップは、複合リソースのためにロードされたファイル、リソースのオペレーティング・システムに組み合わされたフック、及び、複合リソースのために実行されているプロセスの少なくとも１つを識別するステップを含む。

第２の態様によれば、本発明は、監視されるリソースの監視装置であって、監視されるリソースが複合リソースの一部であるかどうかを判断するための判断手段と、監視されるリソースを複合リソースと関連付けるための関連付け手段と、監視されるリソース及び複合リソースについての監視情報を報告するように監視情報の報告フォーマットを変更するための変更手段とを含む装置を提供する。

第３の態様によれば、本発明は、コンピュータ上で実行されたとき、上述の方法の全てのステップを実行するようにされたプログラム・コード手段を含むコンピュータ・プログラムを提供する。

ここで、本発明を、一例に過ぎないものとして、図面に示す好ましい実施形態を参照して説明する。

本発明は、リソース・コンピュータのグリッド内にある二次リソースの相互承認のための方法、装置及びコンピュータ・プログラムを提供する。データ処理装置は、複数のコンピューティング装置が本発明の種々の態様を実行するように使用される、分散データ処理システムとすることができる。従って、以下の図１乃至図３は、本発明を実施することができるデータ処理環境の例示的な図として提供される。図１乃至図３は例示的なものに過ぎず、本発明を実施することができる環境に関して、何らかの制限を明示的に又は黙示的に認めることを意図するものではないということが認識されるべきである。本発明の範囲から逸脱することなく、示される環境に対する多くの変更を行うことができる。

ここで図を参照すると、図１は、本発明の例示的な態様を実施することができるデータ処理システムのネットワークの図形表示を示す。ネットワーク・データ処理システム１００は、本発明を実施することができるコンピュータのネットワークである。ネットワーク・データ処理システム１００はネットワーク１０２を含み、このネットワーク１０２は、ネットワーク・データ処理システム１００内で互いに接続される種々の装置及びコンピュータ間の通信リンクを提供するのに用いられる媒体である。ネットワーク１０２は、有線通信リンク、無線通信リンク又は光ファイバ・ケーブル等の接続を含むことができる。

示される例では、サーバ、その他のコンピューティング装置がネットワーク１０２に接続される。更に、クライアント１０４、１０６及び１０８がネットワーク１０２に接続される。これらのクライアント１０４、１０６及び１０８は、例えば、パーソナル・コンピュータ又はネットワーク・コンピュータとすることができる。企業は、ネットワークに接続される多数のコンピューティング装置を有することができる。例えば、サーバ１１２は第１のサービスを提供することができ、サーバ１１４は第２のサービスを提供し、サーバ１１６は第３のサービスを提供する。例えば、サーバ１１２を会計サーバとすることができ、サーバ１１４をウェブ・サーバとすることができ、サーバ１１６をデータベース・サーバとすることができる。示される例では、サーバ１１２、１１４、１１６は、クライアント１０４、１０６、１０８にデータ、サービス、又はアプリケーションを提供する。プリンタ１１８を、ネットワーク・データ処理システム内の特定の装置により用いるために設けることができる。例えば、プリンタ１１８に、請求書作成サーバのために請求明細を印刷する役割、ネットワーク内の特定のクライアントに印刷出力を与える役割、又は、プログラム開発のためにダンプ記録を生成する役割を割り当てることができる。

サーバ１１２、１１４、１１６のグループは複合構成と呼ぶことができ、例えばクラスタ及びグリッドを含むことができる。クラスタリングとは、協働する２つ又はそれ以上のコンピュータ・システムを用いることを指す。「クラスタ」という用語は、一般的に、互いにリンクされて、可変的な作業負荷に対処する、又は、１つが故障した場合に動作の継続を提供する複数のサーバのことを指す。クラスタ内のリソースは、負荷均衡化及び障害耐性のためのフェイルオーバー作用を提供するクラスタ・ソフトウェアを用いて管理される。サーバ等のクラスタ内のリソースの数は、用途又は実施に応じて変えることができる。

同様に、サーバ、その他のコンピューティング装置が、ネットワーク１０２に接続されるネットワーク１５２に接続される。クライアント１５４、１５６は、ネットワーク１５２に接続される。これらのクライアント１５４、１５６は、例えば、パーソナル・コンピュータ又はネットワーク・コンピュータとすることができる。サーバ１５８は、クライアント１５４、１５６に特定のサービスを提供することができる。例えば、サーバ１５８は、医療用イメージング等の計算集中タスクを実行することができる。示される例では、サーバ１５８は、クライアント１５４、１５６にデータ、サービス又はアプリケーションを提供する。ネットワーク・データ処理システム１００は、図示されない付加的なサーバ、クライアント、その他の装置を含むことができる。

更に、ネットワーク・データ処理システム１００内の種々のリソースは、コンピューティング・システムのグリッドの一部とすることができる。グリッド・コンピューティングは、複数の機械が１つの大きなスーパーコンピュータとして機能するように、ネットワーク全体にわたって中央演算処理ユニット（ＣＰＵ）リソースを共有することである。ピア・ツー・ピア・コンピューティング又は分散コンピューティングとも呼ばれるグリッド・コンピューティングは、いずれかの機械のＣＰＵに未使用容量がある場合、それを、要求される処理ジョブの全体に割り振ることを可能にする。

グリッドは、クライアント・コンピュータとサーバ・コンピュータ及びコンピュータのクラスタの組み合わせで形成することができる。事実、多くの場合、グリッドは、クラスタのクラスタと呼ばれる。使用されていないリソースをもつどのようなコンピュータ・システムも、ネットワーク・データ処理システム１００を通してグリッド・ジョブを受け入れるように構成することができる。グリッド内のグリッド・コンピュータは世界中を領域とするものであり、例えば、限定的ではないが、私的ネットワーク、ダイアルアップ接続、インターネット専用接続、ゲートウェイ・サービス等によりネットワーク１０２に接続することができる。グリッド内のリソースは、「グリドルウェア」とも呼ばれるグリッド・エンジンを用いて管理され、このグリッド・エンジンは、グリッド・ジョブの提示及び受け取り、並びに、リソース間の認証を管理する。

示される例では、ネットワーク・データ処理システム１００は、相互通信のために、伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）のプロトコル一式を用いる、ネットワーク及びゲートウェイの世界的な集合をもつインターネットである。インターネットの心臓部は、主要なノードすなわちホスト・コンピュータ間の高速データ通信ラインのバックボーンであり、これは、データ及びメッセージを送る、何千もの商業用、政府機関用、教育用、その他のコンピュータ・システムにより構成される。また、当然のことながら、ネットワーク・データ処理システム１００は、例えばイントラネット、ローカル・エリア・ネットワーク（ＬＡＮ）又はワイド・エリア・ネットワーク（ＷＡＮ）等の多数の異なる種類のネットワークとして実施することもできる。図１は、例示的なものであることを意図し、本発明の構造的な制限を意図するものではない。

図２を参照すると、図１のサーバ１１４等のサーバとして実施することができるデータ処理システムのブロック図が、本発明の例示的な実施形態により示されている。データ処理システム２００は、システム・バス２０６に接続された複数のプロセッサ２０２及び２０４を含む、対称型マルチ・プロセッサ（ＳＭＰ）システムとすることができる。或いは、これに代わって、単一のプロセッサ・システムを採用することができる。また、システム・バス２０６には、ローカル・メモリ２０９に対するインターフェースを提供するメモリ・コントローラ／キャッシュ２０８が接続される。Ｉ／Ｏバス・ブリッジ２１０は、システム・バス２０６に接続され、Ｉ／Ｏバス２１２に対するインターフェースを提供する。メモリ・コントローラ／キャッシュ２０８及びＩ／Ｏバス・ブリッジ２１０は、示されるように統合することができる。

Ｉ／Ｏバス２１２に接続される周辺機器相互接続（ＰＣＩ）バス・ブリッジ２１４は、ＰＣＩローカル・バス２１６に対するインターフェースを提供する。多数のモデムを、ＰＣＩローカル・バス２１６に接続することができる。典型的なＰＣＩバスの実施は、４つのＰＣＩ拡張スロット又は増設コネクタに対応する。図１のクライアント１０８乃至１１２に対する通信リンクは、増設コネクタによりＰＣＩローカル・バス２１６に接続されるモデム２１８及びネットワーク・アダプタ２２０によって提供することができる。

付加的なＰＣＩバス・ブリッジ２２２及び２２４は、付加的なＰＣＩローカル・バス２２６及び２２８にインターフェースを提供し、それにより付加的なモデム又はネットワーク・アダプタをサポートすることができる。このようにして、データ処理システム２００は、複数のネットワーク・コンピュータへの接続を可能にする。また、メモリ・マップ・グラフィックス・アダプタ２３０及びハード・ディスク２３２を、直接的に又は間接的に、示されるようにＩ／Ｏバス２１２に接続することもできる。

当業者は、図２に示すハードウェアを変更できることを認識するであろう。例えば、光ディスク・ドライブ及び同様なもの等の他の周辺装置もまた、示されているハードウェアに加えて、或いはその代わりに用いることができる。示される例は、本発明に対する構造的な制限を暗示することを意味するものではない。

図２に示すデータ処理システムは、例えば、アドバンスド対話式エグゼクティブ（ＡＩＸ）オペレーティング・システム又はＬＩＮＵＸオペレーティング・システムを実行するＩＢＭ ｅＳｅｒｖｅｒ ｐＳｅｒｉｅｓシステムとすることができる。（ＩＢＭ、ｅ−ｓｅｒｖｅｒ、ｐＳｅｒｉｅｓ及びＡＩＸは、インターナショナル・ビジネス・マシーンズ・コーポレーションの商標である。Ｌｉｎｕｘは、米国、その他の国々、又はその両方におけるＬｉｎｕｓ Ｔｏｒｖａｌｄｓの商標である。）

ここで図３を参照すると、本発明の例示的な態様を実施することができる、データ処理システムのブロック図が示されている。データ処理システム３００は、図１のクライアント１０８等のコンピュータの例であり、これは、本発明のプロセスを実施するコード又は命令を配置することができる。示される例では、データ処理システム３００は、ノース・ブリッジ及びメモリ・コントローラ・ハブ（ＭＣＨ）３０８、及び、サウス・ブリッジ及び入力／出力（Ｉ／Ｏ）コントローラ・ハブ（ＩＣＨ）３１０を含むハブ・アーキテクチャを採用する。プロセッサ３０２、メイン・メモリ３０４及びグラフィックス・プロセッサ３１８は、ＭＣＨ３０８に接続される。グラフィックス・プロセッサ３１８は、例えば、高速グラフィックス・ポート（ＡＧＰ）により、ＭＣＨに接続することができる。

示される例では、ローカル・エリア・ネットワーク（ＬＡＮ）アダプタ３１２、音声アダプタ３１６、キーボード及びマウス・アダプタ３２０、モデム３２２、読み取り専用メモリ（ＲＯＭ）３２４、ハード・ディスク・ドライブ（ＨＤＤ）３２６、ＣＤ−ＲＯＭドライバ３３０、ユニバーサル・シリアル・バス（ＵＳＢ）ポート、その他の通信ポート３３２、及びＰＣＩ／ＰＣＩｅ装置３３４を、ＩＣＨ３１０に接続することができる。ＰＣＩ／ＰＣＩｅ装置は、例えば、イーサネット・アダプタ、増設カード、ノートブック型コンピュータのためのＰＣカード等を含む。ＰＣＩはカードバス・コントローラを使用するが、ＰＣＩｅはこれを使用しない。ＲＯＭ３２４は、例えば、フラッシュ・バイナリ入力／出力システム（ＢＩＯＳ）とすることができる。ハード・ディスク・ドライブ３２６及びＣＤ−ＲＯＭドライブ３３０は、例えば、インテグレーティッド・ドライブ・エレクトロニクス（ＩＤＥ）又はシリアル・アドバンスド・テクノロジー・アタッチメント（ＳＡＴＡ）インターフェースを用いることができる。スーパーＩ／Ｏ（ＳＩＯ）装置３３６をＩＣＨ３１０に接続することができる。

オペレーティング・システムは、プロセッサ３０２上で実行され、図３のデータ処理システム内の種々の構成要素を調整し、かつこれらの制御を与えるように用いられる。オペレーティング・システムは、ＷＩＮＤＯＷＳ ＸＰオペレーティング・システム等の市販のオペレーティング・システムとすることができる（Ｍｉｃｒｏｓｏｆｔ、Ｗｉｎｄｏｗｓ、Ｗｉｎｄｏｗｓ ＮＴ、及びＷｉｎｄｏｗｓのロゴは、米国、その他の国々又はその両方におけるマイクロソフト・コーポレーションの商標である）。ＪＡＶＡプログラミング言語等の、オブジェクト指向プログラミング・システム（Ｊａｖａ及びＪａｖａを基礎とする全ての商標は、米国、その他の国々又はその両方におけるサン・マイクロシステムズ社の商標である）は、オペレーティング・システムとの組み合わせで実行され、データ処理システム３００上で実行されているＪａｖａのプログラム又はアプリケーションからオペレーティング・システムへの呼び出しを行うようにすることができる。オペレーティング・システム、オブジェクト指向プログラミング・システム、及び、アプリケーション又はプログラムに対する命令は、ハード・ディスク・ドライブ３２６等の格納装置に配置され、プロセッサ３０２による実行のために、メイン・メモリ３０４にロードすることができる。本発明のプロセスは、コンピュータにより実施される命令を用いてプロセッサ３０２によって実行され、この命令は、例えば、メイン・メモリ３０４、メモリ３２４等のメモリに、或いは、１つ又はそれ以上の周辺装置３２６及び３３０に配置することができる。

当業者は、図３のハードウェアは実施に応じて変更できることを認識するであろう。フラッシュ・メモリ、等価な不揮発性メモリ、或いは、光ディスク・ドライブ及び同様なもの等の他の内部ハードウェア又は周辺装置を、図３に示すハードウェアに加えて又はその代わりに用いることができる。また、本発明のプロセスは、マルチプロセッサ・データ処理システムに適用することができる。データ処理システム３００は、また、ＰＤＡという形態をとることに加えて、タブレット・コンピュータ又はラップトップ・コンピュータとすることができる。

図４は、本発明の例示的な実施形態による、リソース監視構成のブロック図である。リソース４１０は、クラスタ・ソフトウェア４１２、グリッド・エンジン４１４及びオペレーティング・システム４１８を含む。リソース４１０は、例えば、限定的ではないが、図１のサーバ１１２の１つのようなサーバとすることができる。リソース・モニタ４１６は、管理者コンピュータ４２０における管理者によりリソース４１０に配置される。

管理者コンピュータ４２０は、リソース・マネジャ４２２とオペレーティング・システム４２８とを含む。リソース・マネジャ４２２は、モニタ４１６と通信し、図１のネットワーク・データ処理システム１００等のネットワーク内のリソース・モニタからモニタ情報を受け取って管理する。管理者コンピュータ４２０は、例えば、限定的ではないが、図１のクライアント１０４等のクライアントとすることができる。

本発明の例示的な実施形態によれば、リソース・モニタ４１６は、監視下にあるリソースがクラスタ、グリッド又は他の複合構成の一部であることを示す情報を走査する。リソース・モニタ４１６は、クラスタ・ソフトウェア４１２又はグリッド・エンジン４１４のためにロードされた特定のファイル、オペレーティング・システム４１８に組み合わされたフック、及び、クラスタ・ソフトウェア４１２又はグリッド・エンジン４１４のために実行されているプロセスを走査することができる。

次に、リソース・モニタは、複合構成であることを理由に、リソースについての監視情報を異なる形で報告するべきかどうかを判断する。リソース・モニタ４１６及び／又はリソース・マネジャ４２２は、どのリソースがどのクラスタに属し、どのリソースがどのグリッドに属し、及び／又は、どのクラスタがどのグリッドに属するかを示すテーブル又はマッピングを保持することができる。モニタ情報がリソース・マネジャ４２２に戻される場合には、リソース・モニタ４１６は、監視情報を異なる形で報告するべきかどうかを判断するために、リソースのルックアップを行うことができる。例示的なルックアップ・データ構造を、図５に関して以下に説明する。

リソースについての監視情報を異なる形で報告する場合には、リソース・モニタ４１６は、監視情報を集約し、複合リソース・モデルを反映するように、報告フォーマットを変更する。次に、リソース・マネジャ４２２は、監視情報を受け取り、この情報を個々のリソース及び複合リソースに適用することができる。

図５は、本発明の例示的な実施形態による、複合リソース・モデルのためのルックアップ・データ構造例を示す。リソース・テーブル５１０は、リソースを複合構成と関連付ける。リソースは、示される例では、インターネット・プロトコル（ＩＰ）アドレス等のアドレスを用いて識別される。また、他の識別規則を、特定の実施に応じて用いることができる。例えば、リソースは、命名規則により識別することができる。

図５に示す例では、リソース・テーブル５１０は、「アドレス」列と「クラスタ／グリッド」列とを含む。「クラスタ／グリッド」列は、リソースがクラスタ又はグリッドに属するかどうかを識別し、かつ、リソースが属するクラスタ又はグリッドの識別を含む。例えば、図５の特定の例に示すように、アドレスが１９２．１６８．１．１０１のリソースはクラスタ＿１というクラスタに属し、アドレスが１９２．１６８．１．１１９のリソースはクラスタ＿２というクラスタに属する。この例では、アドレスが１９２．１６８．１．１１８のリソースはどのクラスタ又はグリッドにも属さないが、しかしながら、アドレスが１９２．１６８．１．１２１のリソースはグリッド＿２というグリッドに属する。

クラスタ・テーブル５２０は、クラスタを、それらが割り当てられた機能と関連付ける。図５に示す例では、クラスタ・テーブル５２０は、「クラスタ」列と「機能」列とを含む。示される例では、「クラスタ」列は名前でクラスタを識別するが、しかしながら、他の識別規則を特定の実施に応じて用いることができる。「機能」列は、リソースのクラスタに割り当てられた機能又は役割を識別する。例えば、クラスタ＿１は「ＨＴＴＰサーバ」という役割を割り当てられ、クラスタ＿２は「請求書作成」という役割を割り当てられ、クラスタ＿３は「データベース」という役割を割り当てられている。

更に、クラスタ・テーブル５２０は「グリッド」列を含むことができる。「グリッド」列は、クラスタがグリッドに属するかどうかを識別し、かつ、クラスタが属するグリッドの識別を含む。例えば、図５の特定の例に示すように、クラスタ＿１はグリッド＿１というグリッドに属し、クラスタ＿３はグリッド＿２というグリッドに属する。リソース・テーブル５１０の「クラスタ／グリッド」列の値は、クラスタ・テーブル５２０又はグリッド・テーブル５３０の入力項目を指し示すことができる。同様に、クラスタ・テーブル５２０の「グリッド」列の値は、グリッド・テーブル５３０の入力項目を指し示すことができる。この例では、グリッド・テーブル５３０は、グリッド名のリストを提供するに過ぎないが、しかしながら、グリッド・テーブル５３０は、本発明の範囲内の付加的な情報を含むことができる。

図６は、本発明の例示的な実施形態による、複合リソースをもつネットワーク環境におけるリソース・モニタ配置の動作を示すフローチャートである。プロセスが開始し、モニタをリソースに配置する（ブロック６０２）。次に、プロセスは、リソースがクラスタの一部であることを示す情報を走査する（ブロック６０４）。リソースがクラスタの一部であるかどうかについて判断がなされる（ブロック６０６）。

リソースがクラスタの一部である場合には、プロセスは、リソースをクラスタと関連付ける（ブロック６０８）。関連付けは、例えば、リソース・テーブル内に入力項目を作成することにより行うことができる。次いで、プロセスは、リソースがグリッドの一部であることを示す情報を走査する（ブロック６１０）。ブロック６０６において、リソースがクラスタの一部ではない場合には、プロセスは、直接、ブロック６１０に続き、リソースがグリッドの一部であることを示す情報を走査する。

リソースがグリッドの一部であるかどうかについて判断がなされる（ブロック６１２）。リソースがグリッドの一部である場合には、プロセスは、リソースをグリッドと関連付ける（ブロック６１４）。関連付けは、例えば、リソース・テーブル内に入力項目を作成することにより行うことができる。次いで、プロセスが終了する。ブロック６１２において、リソースがグリッドの一部ではない場合には、プロセスは終了する。

図７は、本発明の例示的な実施形態による、リソース・モニタの動作を示すフローチャートである。プロセスが開始し、リソースについての監視情報を受け取る（ブロック７０２）。このステップは、リソースにおけるリソース・モニタによって実行することができる。リソースがクラスタと関連付けられているかどうかについて判断がなされる（ブロック７０４）。リソース・モニタはリソース・テーブルをコンパイルすることができ、又は、リソース・マネジャからリソース・テーブルを受け取ることができる。リソース・テーブルは、ネットワーク環境の中で、リソースをクラスタ及び／又はグリッドにマップすることができる。

リソースがクラスタと関連付けられている場合には、監視情報をクラスタに対して異なる形で報告するべきかどうかについての判断がなされる（ブロック７０６）。監視情報を異なる形で報告する場合には、プロセスは、報告フォーマットをクラスタ報告のために変更する（ブロック７０８）。次いで、クラスタがグリッドと関連付けられているかどうかについて判断がなされる（ブロック７１０）。ブロック７０６において、監視情報を異なる形で報告しない場合には、プロセスは、直接、ブロック７１０に続いて、クラスタがグリッドと関連付けられているかどうかを判断する。

クラスタがグリッドと関連付けられている場合には、監視情報をグリッドに対して異なる形で報告するかどうかについての判断がなされる（ブロック７１２）。監視情報を異なる形で報告する場合には、プロセスは、報告フォーマットをグリッド報告のために変更する（ブロック７１４）。次いで、プロセスは、リソースについての監視情報を報告し（ブロック７１８）、終了する。ブロック７１２において、監視情報を異なる形で報告しない場合には、プロセスは、直接、ブロック７１８に続いて、監視情報を報告する。

ブロック７１０において、クラスタがグリッドと関連付けられていない場合、又は、ブロック７０４において、リソースがクラスタと関連付けられていない場合には、リソースがグリッドと関連付けられているかどうかについて判断がなされる（ブロック７１６）。リソースがグリッドと関連付けられている場合には、プロセスは、ブロック７１２に続いて、監視情報をグリッドに対して異なる形で報告するかどうかについての判断がなされる（ブロック７１２）。ブロック７１６において、リソースがグリッドと関連付けられていない場合には、プロセスは、直接、ブロック７１８に続いて、リソースについての監視情報を報告する。次いで、プロセスは終了する。

図８は、本発明の例示的な実施形態による、リソース管理の動作を示すフローチャートである。プロセスが開始し、リソースについての監視情報を受け取る（ブロック８０２）。このステップは、管理者コンピュータ又はワークステーションにおいて、リソース・マネジャによって実行することができる。次に、プロセスは、例えば測定基準等のクラスタについての監視情報を集約する（ブロック８０４）。次に、プロセスは、グリッドについての監視情報を集約する（ブロック８０６）。次いで、プロセスは終了する。

従って、本発明の例示的な態様は、複合リソース・モデルを表わし、管理するための機構及びモデルを提供する。リソース・モニタは、リソースについての監視情報を、複合構成であることを理由に、異なる形で報告するべきかどうかを判断する。リソースについての監視情報を異なる形で報告する場合には、リソース・モニタは、複合リソース・モデルを反映するように、報告フォーマットを変更する。次に、リソース・マネジャは監視情報を受け取り、この情報を個々のリソースに適用して、複合リソースについての監視情報を集約することができる。次に、リソース・マネジャは、この集約された監視情報に基づいて、リソース管理の決定を行うことができる。

本発明は、完全に機能するデータ処理システムに関連して説明されたが、当業者であれば、本発明のプロセスは、コンピュータ可読媒体の命令形態及び種々の形態で配布できること、及び、本発明は、配布を行うために実際に用いられる信号保持媒体の特定形態に関係なく、等しく適用できるものと認識するであろうという点は重要なことである。コンピュータ可読媒体の例は、フロッピー・ディスク、ハード・ディスク・ドライブ、ＲＡＭ、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ等の書き込み可能媒体、及び、デジタル通信リンク及びアナログ通信リンク、例えばラジオ周波数及び光波伝送等の伝送形態といった伝送形態を用いる有線通信リンク又は無線通信リンク等の伝送型媒体を含む。コンピュータ可読媒体は、特定のデータ処理システムにおいて実際に用いるために復号化される、符号化フォーマットの形態をとることができる。

本発明の説明は、例示及び説明の目的で提示されるものであり、包括的であること、又は、本発明を開示される形態に限定することを意図するものではない。多くの変更及び変形が当業者には明らかであろう。実施形態は、本発明の原理、実用的な用途を最適に説明するために、また、他の当業者が、意図する特定の用途に適したように種々の修正を行って種々の形態で実施する場合に本発明を理解できるように、選択され、説明されたものである。

本発明の例示的な態様を実施することができる、データ処理システムのネットワークの図形表示を示す。 本発明の例示的な実施形態による、サーバとして実施することができるデータ処理システムのブロック図である。 本発明の例示的な態様を実施することができる、データ処理システムのブロック図である。 本発明の例示的な実施形態による、リソース監視構成のブロック図である。 本発明の例示的な実施形態による、複合リソース・モデルのための例示的なルックアップ・データ構造を示す。 本発明の例示的な実施形態による、複合リソースをもつネットワーク環境におけるリソース・モニタ配置の動作を示すフローチャートである。 本発明の例示的な実施形態による、リソース・モニタの動作を示すフローチャートである。 本発明の例示的な実施形態による、リソース管理の動作を示すフローチャートである。

Claims (21)

1. 監視されるリソースの監視方法であって、前記監視されるリソースが複合リソースの一部であるかどうかを判断するステップと、前記監視されるリソースを前記複合リソースと関連付けるステップと、前記監視されるリソース及び前記複合リソースについての監視情報を報告するように監視情報の報告フォーマットを変更するステップと、を含む方法。
2. リソース・マネジャにおいて前記監視情報を受け取るステップと、前記複合リソースについての前記監視情報を集約するステップとを更に含む、請求項１に記載の方法。
3. 前記監視されるリソースを前記複合リソースと関連付けるステップが、前記監視されるリソースについての入力項目をリソース・データ構造に作成するステップを含む、請求項１又は請求項２に記載の方法。
4. 前記リソース・データ構造がリソース・テーブルである、請求項３に記載の方法。
5. 前記監視されるリソースを前記複合リソースと関連付けるステップが、前記リソース・データ構造における前記入力項目を、複合リソース・データ構造における入力項目とリンクさせるステップを更に含む、請求項３又は請求項４に記載の方法。
6. 前記複合リソース・データ構造が、クラスタ・データ構造及びグリッド・データ構造の１つである、請求項５に記載の方法。
7. 前記複合リソースがクラスタであり、前記監視されるリソースを前記複合リソースと関連付けるステップが、前記リソース・データ構造における入力項目を、クラスタ・データ構造における入力項目とリンクさせるステップを更に含む、請求項３から請求項６までのいずれか１項に記載の方法。
8. 前記クラスタがグリッドの一部であるかどうかを判断するステップと、前記クラスタを前記グリッドと関連付けるステップとを更に含む、請求項７に記載の方法。
9. 前記クラスタを前記グリッドと関連付けるステップが、前記クラスタ・データ構造における前記入力項目を、グリッド・データ構造における入力項目とリンクさせるステップを含む、請求項８に記載の方法。
10. 前記監視されるリソースが複合リソースの一部であるかどうかを判断する前記ステップが、複合リソースのためにロードされたファイル、前記リソースのオペレーティング・システムに組み合わされたフック、及び、複合リソースのために実行されているプロセスの少なくとも１つを識別するステップを含む、請求項１から請求項９までのいずれか１項に記載の方法。
11. 監視されるリソースの監視装置であって、前記監視されるリソースが複合リソースの一部であるかどうかを判断するための判断手段と、前記監視されるリソースを前記複合リソースと関連付けるための関連付け手段と、前記監視されるリソース及び前記複合リソースについての監視情報を報告するように監視情報の報告フォーマットを変更するための変更手段と、を含む装置。
12. リソース・マネジャにおいて前記監視情報を受け取るための手段と、前記複合リソースについての前記監視情報を集約するための手段とを更に含む、請求項１１に記載の装置。
13. 前記関連付け手段が、監視されるリソースについての入力項目をリソース・データ構造に作成するための手段を含む、請求項１１又は請求項１２に記載の装置。
14. 前記リソース・データ構造がリソース・テーブルである、請求項１３に記載の装置。
15. 前記関連付け手段が、前記リソース・データ構造における前記入力項目を、複合リソース・データ構造における入力項目とリンクさせるためのリンク付け手段を更に含む、請求項１３又は請求項１４に記載の装置。
16. 前記複合リソース・データ構造が、クラスタ・データ構造及びグリッド・データ構造の１つである、請求項１５に記載の装置。
17. 前記複合リソースがクラスタであり、前記関連付け手段が、前記リソース・データ構造における入力項目を、クラスタ・データ構造における入力項目とリンクさせるためのリンク付け手段を更に含む、請求項１３から請求項１６までのいずれか１項に記載の装置。
18. 前記クラスタがグリッドの一部であるかどうかを判断するための判断手段と、前記クラスタを前記グリッドと関連付けるための関連付け手段とを更に含む、請求項１７に記載の装置。
19. 前記クラスタを前記グリッドと関連付けるための前記関連付け手段が、前記クラスタ・データ構造における前記入力項目を、グリッド・データ構造における入力項目とリンクさせるためのリンク付け手段を含む、請求項１８に記載の装置。
20. 前記監視されるリソースが複合リソースの一部であるかどうかを判断するための前記判断手段が、複合リソースのためにロードされたファイル、前記リソースのオペレーティング・システムに組み合わされたフック、及び、複合リソースのために実行されているプロセスの少なくとも１つを識別するための手段を含む、請求項１１から請求項１９までのいずれか１項に記載の装置。
21. コンピュータ上で実行されたとき、請求項１から請求項１０までのいずれか１項に記載の全てのステップを実行するようにされたプログラム・コード手段を含むコンピュータ・プログラム。

Images