JP5208337B2 - クライアント管理ツールにおいてポーリングエージェントを実装するコンピュータシステムおよび方法 - Google Patents

Description

本発明は、一般に、コンピュータソフトウェアに関するものであり、具体的には、コンピュータシステムのクライアント管理製品に関するものである。

一般に、容量計画製品などのクライアント管理製品を利用して、特に、ネットワーク内で特定の機能専用の複数のマシンを利用する大規模な企業向け構成で１つまたは複数のクライアントマシンを前向きに監視することが望ましい。たとえば、容量計画製品では、いつ既存のサーバーシステムがハードウェアの限界に到達するか超えるかを判別できる。それに対し、サイズ設定製品は、容量計画製品とは異なり、新しいコンピュータシステムを作成するのに必要なハードウェアへの投資の決定という作業が必要である。その他のクライアント管理製品（つまり、パフォーマンス監視製品）を使用して、コンピュータネットワークおよびシステムのパフォーマンスを監視する。このようなパフォーマンス監視製品は、パフォーマンスしきい値のリアルタイム監視機能を備える。

発明が解決しようとする課題

従来、容量計画製品およびパフォーマンス監視製品は、個別に実装されている。しかし、これらの製品は同時実行するので、ネットワーク上にかなりのレベルの管理トラフィックが発生することがある。さらに、システム管理者は２つの異なるクライアントデータ収集プログラムを監視しなければならない。これは、特に両方がクライアントからの同じデータを利用してその機能を実装している場合には不効率である。そこで、容量計画およびパフォーマンス監視機能を１つのクライアント管理製品に組み込み、より効率的にシステム資源を活用するようにする必要がある。

既存のクライアント管理製品はときには、ポーリングエージェントを使用して、コンピュータネットワークおよびそのコンポーネントからデータを収集することがある。与えられた間隔で多数のネットワークマシンからのクライアントデータ（たとえば、容量計画またはパフォーマンス監視データ）のデータ要求を発行する中央ポーリングエージェントを用意するという方法がある。また、ネットワークマシン上に常駐し、与えられた類似の間隔で中央データベースにクライアントデータを送信する役目を持つ多数の常駐ポーリングエージェントを用意する方法もある。それぞれのクライアント上でポーリングソフトウェアのロードと保守をシステム管理者側で行わなくてよいため、中央ポーリングエージェントを好むネットワーク管理者もいる。容量計画データの集まりに関するネットワークトラフィックの量を低減できることから常駐ポーリングエージェントを好むネットワーク管理者もいる。現在、ネットワーク管理者は通常、１つのポーリングエージェント構成を実施するが、構成を管理ニーズの変更に合わせて変更することはできない。両方のアプローチに対する要求があれば、ネットワーク管理者などのユーザーが中央ポーリング機能や常駐ポーリング機能などの複数のポーリング機能またはモードから選択できるクライアント管理製品に対する要求がある。

容量計画データなどのクライアント管理データは、さまざまなシステムコンポーネントを伴う多数の測定を実行して指定クライアントについて得る。オペレーティングシステムによっては、さまざまなシステムパラメータを測定し、送信する機能を備えるものもある。たとえば、管理情報のアクセスおよび共有のためのＷｅｂベース企業管理（ＷＢＥＭ）標準化形式をサポートするオペレーティングシステムベンダーがある。イベントが発生するごとに、あるいは測定間隔が得られた後、増分されるストアされている値であるカウンタを使用して、個々のマシン上のメモリ使用度またはＣＰＵ（中央処理装置）使用度を測定し、リンクの利用度または「ビジータイム」を監視することが多い。カウンタからの履歴情報は、パフォーマンスのボトルネック（広範なディスクキュー長など）の識別、ピーク使用期間の検出、および将来の使用度の予測など、さまざまな目的に使用することができる。測定では通常、複数のカウンタやそのようなその他のデバイスをグループ化したり、選択したりする必要がある。

従来、クライアント側でどの測定結果を出力すべきかを識別する監視プロセスによりアクティブな測定が開始する。ただし、いったん開始すると、非アクティブにして、修正を行い、その後再度アクティブにしない限り、測定を修正することはできない。このため、クライアント管理データの収集に不連続が生じ、その結果、測定が非アクティブになっている間、貴重な情報が失われる可能性がある。さらに、修正を完了するために、かなりのユーザー介入が必要になることがある。そのため、非アクティブにせずにアクティブな測定を修正できるクライアント管理製品が必要である。

別のクライアント管理製品を使用して、容量計画データおよびパフォーマンス監視データを収集してきたため、アクティブな測定から得られたデータは通常、最初にクライアントのキャッシュまたは他のローカルメモリにストアせずに、中央にある別のデータベースに転送される。容量計画データは、あまり頻繁に収集されず、クライアントのキャッシュを消費したり、他のデータで上書きされるため、通常は、キャッシュされない。パフォーマンス監視データは、頻繁に監視すべき重要なデータであるため、通常キャッシュされない。しかし、パフォーマンスデータはローカルにストアされ、一定期間にわたって平均がとられる場合、多数のデータ点に基づくので、より正確な容量計画データが得られる。したがって、中央のロケーションにより正確な容量計画データを送るように、パフォーマンスデータをローカルにストアし、一定期間にわたって平均をとるクライアント管理製品が必要である。

多くのサービストランザクションは、コンピュータまたはデータベースサービスのプロバイダとそれらのサービスのユーザとの間の契約である「サービスレベルアグリーメント」（ＳＬＡ）に基づいている。ＳＬＡは、保証されている最小レベルのサービスを規定し、通常、ある種のトランザクションに対する最大応答時間という形をとる。潜在的違反を予期した対策をとらないと、ＳＬＡに違反する可能性がある。そこで、容量計画製品を利用して、ＳＬＡに関してシステムニーズを予想することができる。

ＳＬＡの他に、サービストランザクションは他の時間制約を受ける可能性があり、たとえば、予め時間制約に対応できるかどうかを決定するためサービス連鎖において応答時間を監視すると都合がよい。「サービス連鎖（ｓｅｒｖｉｃｅ ｃｈａｉｎ）」はトランザクションまたはサービスの処理で使用する資源の集まりである。監視にはリアルタイムという要件があるため、別のパフォーマンス監視製品も利用する必要がある。同時実行される２つのクライアント管理製品にはかなりの不備が関わるため、関係する特定のシステム資源を識別し、監視することにより、コンピュータシステムの個別サービストランザクションの複数の態様を監視できるクライアント管理製品が必要になることは明白である。

容量計画およびパフォーマンス監視データをアーカイブすることが多くの場合望ましい。アーカイブにはかなりのメモリが要求されるが、かなりの資源を費やして、最初の場所でデータを収集しており、また費用のかかるアップグレードを正当化する詳細な履歴データに基づいて予測分析やレポートを作成するうえでアーカイブされたデータは貴重な場合がある。従来、容量計画データのアーカイブはクライアント管理ツール自体では実行できない。その代わりに、クライアント管理ツールの外部のソフトウェアアプリケーションを利用して実行しなければならず、また通常はデータベース専門家の知識技術を必要とする、従来のアーカイブ方式を使用する必要がある。そのため、容量計画などのクライアント管理機能と、データベース専門家を必要としないアーカイブ機能の両方を実行するクライアント管理製品が必要である。

一般に、従来の管理ツール（たとえば、容量計画またはパフォーマンス監視ツール）は、１つまたは複数のクライアントから収集したデータをデータベースファイルにストアする。ただし、選択した管理ツールと、管理ツールの提供者によっては、さまざまなデータベース列見出しの下で編成することができ、これは多くの場合、その性質上専用となる。たとえば、第１のデータベースファイルに「マシン名」という列見出しがあり、サーバーの特定の素性を表し、第２のデータベースファイルでは「コンピュータ名」という列見出しを使用して、それと同じ情報を表すことができる。そのため、異なる管理ツールおよび／または異なるツール提供者によって収集されたデータは、データスキーマに不整合があるため互換性がない場合がある。したがって、すでに収集されている管理データの読み込みおよび／または変換が可能な管理ツールが必要である。

さらに、従来の管理ツールはいずれも、容量計画およびパフォーマンス監視の両方に対して使用されないため、収集されたデータはログファイルと呼ばれる可変長のファイルに保存され、その長さはいったん測定が終了すると調整も追加もできない。たとえば、Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎでは、ＰＥＲＦＭＯＮというパフォーマンス監視機能をＷｉｎｄｏｗｓ ＮＴオペレーティングシステムに備えている。通常、ＰＥＲＦＭＯＮは収集されたデータは、Ｍｉｃｒｏｓｏｆｔ製品に固有のＥＸＣＥＬスプレッドシート形式で保存することができる。しかし、いったんＰＥＲＦＭＯＮ測定が停止すると、同じ測定基準を再度アクティブにすることで、同じ名前を持つ第２のログファイルの作成が起動する。現在、追加管理データをオリジナルファイルにストアするため２つの独立のファイルの内容を第３のファイルに保存する方法はない。したがって、同じ測定ファイルに複数の測定データをストアできる管理ツールが必要である。

従来の容量計画機能の欠点としては他に、ユーザインタフェース（ＵＩ）に対し高度な訓練を受けたシステムアドミニストレータやシステム管理者が必要であるという点があげられる。たとえば、多くの従来のＵＩでは、ユーザは一般により難しいコマンドベースのインタフェースに依存し、グラフィック形式でシステムを操作することができない。さらに、ＵＩは一般に、管理システムの単一の機能を実行するために複数のスクリーンインタフェースを必要とする。従来のＵＩのこうした態様により、システムアドミニストレータの訓練を増やす必要があり、そのため容量計画機能と関連するコストが増大する。したがって、システムアドミニストレータに対する訓練が少なくてすむため、製品と関連するコストが低減されるより直観的なＵＩを持つ容量計画製品も必要になる。

課題を解決するための手段

一般的に述べると、本発明は、複数のコンピュータシステムオブジェクトからデータを収集する１つまたは複数のポーリングエージェントを実装するコンピュータシステムにおける一方法を提供する。この方法により、ユーザは複数のポーリング機能のうちの１つを選択するよう求められる。ユーザーの選択が届くと、少なくとも１つのポーリングエージェントが選択されているポーリング機能に対応して実行される。

本発明の他の態様において、複数のオブジェクトを管理するコンピュータシステムを提供する。システムには、中央マネージャと、中央マネージャと通信している複数のオブジェクトのうちの第１のものが含まれる。さらに、システムは、複数のオブジェクトからデータを収集するためのポーリングエージェントも含む。ポーリングエージェントは、コンピュータシステムが第１のポーリングモードで動作するときに第１のオブジェクト上に常駐し、ポーリングエージェントは、コンピュータシステムが第２のポーリングモードで動作するときに中央マネージャ上に常駐する。

さらに本発明の他の態様において、複数のオブジェクトを管理するコンピュータシステムを提供する。システムには、コンピュータシステムを集中管理する手段と、中央管理手段と通信している複数のオブジェクトのうちの第１のものが含まれる。さらに、システムは、複数のオブジェクトからデータを収集するための手段も含む。収集手段は、コンピュータシステムが第１のポーリングモードで動作するときに第１のオブジェクト上に常駐し、収集手段は、コンピュータシステムが第２のポーリングモードで動作するときに中央マネージャ上に常駐する。

クライアント管理ツールにおいてさまざまなポーリングエージェント機能を実行する方法とシステムを提供する。中央マネージャにおけるユーザは、多数のコンピュータオブジェクトからクライアント管理データを収集するため中央ポーリング機能または常駐ポーリング機能のいずれかを選択するよう求められる。さらに、本発明のポーリングエージェント機能は、重要データと非重要データとを区別することができ、またデータの適切な送信間隔を決定できる。

添付図面を参照しながら本発明について以下の段落で説明する。

図１は、本発明を実施できる適当なコンピュータシステム環境の例を示している。この計算システム環境は、適当な計算環境の一例にすぎず、本発明の使用または機能の範囲に関する限定を示唆するものではない。この計算環境は例のオペレーティング環境で示されているコンポーネントのいずれかまたは組合せに関して従属している、あるいは必要であるとは解釈すべきではない。

本発明は、他の多数の汎用または専用の計算システム環境または構成でも動作する。本発明で使用するのに適していると思われるよく知られている計算システム、環境および／または構成の例として、限定はしないが、パーソナルコンピュータ、サーバコンピュータ、携帯またはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、プログラム可能民生用電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記システムまたはデバイスを含む分散計算環境などがある。

本発明は、コンピュータによって実行されるプログラムモジュールなどの一般的文脈において説明できる。一般に、プログラムモジュールには、特定のタスクを実行する、あるいは特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。本発明は、さらに、通信ネットワークを介してリンクされているリモート処理デバイスによってタスクが実行される分散コンピューティング環境で実用することもできる。分散コンピューティング環境では、プログラムモジュールをメモリ記憶デバイスを含むローカルとリモートの両方のコンピュータ記憶媒体に配置できる。

図１では、本発明を実施する例示のシステムに、コンピュータ２０の形の汎用計算デバイスが含まれる。コンピュータ２０のコンポーネントは、限定はしないが、処理ユニット２２、システムメモリ２４、およびシステムメモリを備えるさまざまなシステムコンポーネントを処理ユニット２２に結合するシステムバス２６を備える。システムバス２６には、さまざまなバスアーキテクチャを使用するメモリバスまたはメモリコントローラ、周辺機器バス、およびローカルバスを含む数種類のバス構造がある。例では、限定はしないが、前記アーキテクチャに、Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＩＳＡ）バス、Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＭＣＡ）バス、Ｅｎｈａｎｃｅｄ ＩＳＡ（ＥＩＳＡ）バス、 Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ（ＶＥＳＡ）ローカルバス、およびＭｅｚｚａｎｉｎｅバスとも呼ばれるＰｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）バスがある。

コンピュータ２０は通常、多数のコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータ２０によってアクセス可能な利用可能な媒体でよく、揮発性および不揮発性媒体、取外し可能および取外し不可能媒体がある。例として、コンピュータ可読媒体はコンピュータ記憶媒体と通信媒体を含むことができるが、これには限定されない。コンピュータ記憶媒体には、揮発性と不揮発性の両方の取外し可能および取外し不可能媒体が備えられ、コンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータなどの情報の記憶用の方法または技術で実装されている。コンピュータ記憶媒体には、限定はしないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたはその他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、またはその他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置またはその他の磁気記憶デバイス、または目的の情報のストアに使用でき、コンピュータ２０によってアクセスできる他の媒体がある。通信媒体は通常、コンピュータ可読命令、データ構造、プログラムモジュールまたはその他のデータをキャリア波やその他の搬送メカニズムなどのモジュール式データ信号で具現化し、情報配送媒体を含む。「変調データ信号」という用語は、情報を信号で符号化する方法でその特性の１つまたは複数を設定または変更した信号を意味する。例として、これには限らないが、通信媒体は有線ネットワークまたは直接有線接続などの有線媒体および音響、ＲＦ、赤外線、およびその他の無線媒体などの無線媒体を含む。上記の任意の組合せも、コンピュータ可読媒体の範囲に含めるべきである。

システムメモリ２４は、読取り専用メモリ（ＲＯＭ）２８およびランダムアクセスメモリ（ＲＡＭ）３０などの揮発性および／または不揮発性メモリの形態のコンピュータ記憶媒体を含む。起動時などにコンピュータ２０内の要素間の情報伝送を助ける基本ルーチンを含む基本入出力システム３２（ＢＩＯＳ）は通常、ＲＯＭ２８にストアされる。ＲＡＭ３０は、通常、処理ユニット２２に即座にアクセス可能および／または現在操作されているデータやプログラムモジュールを含む。例として、これに限らないが、図１はオペレーティングシステム４６、アプリケーションプログラム４８、その他のプログラムモジュール５０、およびプログラムデータ５２を示している。

コンピュータ２０はさらに、その他の取外し可能／取外し不可能、揮発性／不揮発性コンピュータ記憶媒体も含むことができる。例でのみ、図１は、取外し不可能不揮発性磁気媒体への読み書きを行うハードディスクドライブ３４、取外し可能不揮発性磁気ディスク３８への読み書きを行う磁気ディスクドライブ３６、およびＣＤ−ＲＯＭまたはその他の光媒体などの取外し可能不揮発性光ディスク４２への読み書きを行う光ディスクドライブ４０を示す。例示のオペレーティング環境で使用できるその他の取外し可能／取外し不可能揮発性／不揮発性コンピュータ記憶媒体には、限定はしないが磁気テープカセット、フラッシュメモリカード、デジタルビデオディスク、デジタルビデオテープ、ベルヌーイカートリッジ、半導体ＲＡＭ、半導体ＲＯＭなどがある。ハードディスクドライブ３４、磁気ディスクドライブ３６、および光ディスクドライブ４０は、通常、Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ（ＳＣＳＩ）４４によってシステムバス２６に接続される。それとは別に、ハードディスクドライブ３４、磁気ディスクドライブ３６、および光ディスクドライブ４０は、ハードディスクドライブインタフェース、磁気ディスクドライブインタフェース、および光ドライブインタフェースによってそれぞれシステムバス２６に接続できる。

上で述べた、図１に示されているドライブおよび関連コンピュータ記憶媒体は、コンピュータ２０用のコンピュータ可読命令、データ構造、プログラムモジュール、およびその他のデータのストアを準備する。図１では、たとえば、ハードディスクドライブ３４はオペレーティングシステム４６、アプリケーションプログラム４８、その他のプログラムモジュール５０、およびプログラムデータ５２として示されている。これらのコンポーネントは、オペレーティングシステム４６、アプリケーションプログラム４８、その他のプログラムモジュール５０、およびプログラムデータ５２と同じであっても、異なっていてもよいことに留意されたい。ユーザは、キーボード５４および、一般にマウス、トラックボール、タッチパッドと呼ばれているポインティングデバイス５６などの入力デバイスを使用してコンピュータ２０にコマンドおよび情報を入力できる。その他の入力デバイス（図には示されていない）としては、マイク、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナなどがある。これらの入力デバイスやその他の入力デバイスは、システムバスに結合されているユーザ入力インタフェース５８またはシリアルポートインタフェース６０を介して処理ユニット２２に接続されることが多いが、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）などの他のインタフェースおよびバス構造で接続することもできる。モニタ６１やその他のタイプの表示デバイスも、ビデオアダプタ６２などのインタフェースを介してシステムバス２６に接続される。モニタ６１の他に、コンピュータには、出力周辺機器インタフェースを介して接続可能な、スピーカやプリンタなどの他の周辺出力デバイスもある。

コンピュータ２０は、リモートコンピュータ６４などの１つまたは複数のコンピュータへの論理接続を使用してネットワーク環境で動作することもできる。リモートコンピュータ６４は、パソコン、サーバ、ルータ、ネットワークＰＣ、ピアデバイスまたはその他の共通ネットワークノードでよく、通常は、コンピュータ２０に関係する上述の要素の多くまたはすべてを含むが、メモリ記憶デバイスのみは図１に示されている。図１に示されている論理接続は、ローカルエリアネットワーク（ＬＡＮ）６６とワイドエリアネットワーク（ＷＡＮ）６８を含むが、他のネットワークを含んでいてもよい。このようなネットワーキング環境は、事務所、企業規模のコンピュータネットワーク、イントラネットおよびインターネットではよくある。

ＬＡＮネットワーキング環境で使用する場合は、コンピュータ２０はネットワークインタフェースまたはアダプタ７０を介してＬＡＮ６６に接続される。ＷＡＮネットワーキング環境で使用する場合は、コンピュータ２０は通常、モデム７２またはインターネットなどのＷＡＮ６８上で通信を確立するためのその他の手段を含む。モデム７２は、内蔵でも外付けでもよいが、シリアルポートインタフェース６０またはその他の適切なメカニズムを介してシステムバス２６に接続できる。ネットワーク環境では、コンピュータ２０またはその一部に関して述べたプログラムモジュールは、リモートメモリ記憶装置にストアできる。例として、これに限らないが、図１はメモリデバイス６４に常駐するようなリモートアプリケーションプログラム４８を示している。図のネットワーク接続は例示のものであり、コンピュータ間の通信リンクを確立するその他の手段も使用できることは明白であろう。

コンピュータ２０の他の内部コンポーネントの多くは図に示されていないが、当業者であればそのようなコンポーネントおよび相互接続が良く知られていることは明白であろう。したがって、本発明に関してコンピュータ２０の内部構造の詳細を開示する必要はない。

当業者であれば、オペレーティングシステム４６、アプリケーションプログラム４８、およびデータ５２などのプログラムモジュールがメモリ記憶デバイスの１つを介してコンピュータ２０に供給され、ＲＯＭ２８、ＲＡＭ３０、ハードディスクドライブ３４、磁気ディスクドライブ３６、または光ディスクドライブ４０を含むことができることは理解できるであろう。ハードディスクドライブ３４を使用して、オペレーティングシステム４６およびアプリケーションプログラム４８を含む、データ５２およびプログラムをストアするのが好ましい。

コンピュータ２０をオンまたはリセットしたときに、ＲＯＭ２８にストアされているＢＩＯＳ３２により、処理ユニット２２に命令が送られ、ハードディスクドライブ３４からＲＡＭ３０にオペレーティングシステムがロードされる。オペレーティングシステム４６がＲＡＭ３０にロードされると、処理ユニット２２はオペレーティングシステムコードを実行し、オペレーティングシステム４６のユーザインタフェースと関連する表示要素をモニタ６１に表示する。ユーザがアプリケーションプログラム４８を開くと、プログラムコードおよび関連データがハードディスクドライブ３４から読み込まれ、ＲＡＭ３０にストアされる。

図２の例示のコンピュータシステム８０は複数の対応する通信リンクを介して複数のクライアント８４、８６、８８、および９０に接続されている中央マネージャ８２を備える。クライアント８４〜９０のそれぞれは、クライアントと中央マネージャ８２との通信インタフェースであり、好ましくは管理情報のアクセスポイントであるポーリングインタフェース（ＰＩ）９１を有する。さらに、ＰＩ ９１はクライアントデータを処理し要求する追加コンポーネントを含むことができる。中央マネージャ８２は、管理マシン９２、コンソール９４、データベース９６、および中央ポーリングエージェント９８を含む。図２に別に示されているが、エージェント９８は代わりに、マシン９２、コンソール９４、またはデータベース９６に常駐することもできる。

クライアント８４〜９０はより大規模な企業ネットワーク内の専用機能を備えるサーバであるのが好ましい。このようなネットワーク１００を図３に示した。ネットワーク１００では、クライアントマネージャ８２は活動スクリーン１０２に接続され、またＷｅｂサーバ１０４にも接続されている。次に、Ｗｅｂサーバ１０４はクライアントサーバ１０６、アプリケーションサーバ１０８、およびデータベースサーバ１１０に接続される。アプリケーションサーバ１０８およびデータベースサーバ１１０も互いに通信している。当業者であれば理解できるように、本発明では、クライアント８４〜９０（図２）は多目的サーバ、異なるネットワークからのサーバおよび／または非サーバコンピュータを含むことを考慮している。

本発明の好ましい実施形態は、複数のポーリングエージェント構成から選択する機能など、従来のクライアント管理製品にない多くの機能を含んでいる。初期化した後、ユーザコンソール９４は利用可能なポーリングエージェント構成を示す一組のメニューエントリを取り出して、表示する。図１２に示されているように、ユーザはグラフィカルユーザインタフェースを介して、容量計画データを収集する２つまたは３つ以上のポーリング機能またはモードのいずれかを選択するよう求められる。中央ポーリングモードおよび常駐ポーリングモードは両方ともユーザに提示されるのが好ましい。他の使用可能なポーリングエージェント構成として、中央ポーリングエージェントと１つまたは複数の常駐ポーリングエージェントを伴う中央ポーリングモードと常駐ポーリングモードの組合せがある。この後者の構成は、ネットワークでの管理トラフィックのバランスをとるのに有用な場合がある。

ユーザーの選択が届くと、本発明では選択されているポーリング機能に従って少なくとも１つのポーリングエージェントが実行される。中央ポーリング機能は通常、単一のポーリングエージェントのみが関わるが、常駐ポーリング機能では多くの場合、複数のポーリングエージェントをコンピュータシステム内の別々のマシンまたはオブジェクトに常駐させる。本発明は、デフォルトの選択としてポーリング機能の１つを指定することができる（たとえば、プリセットされた時間内にユーザ選択を受信しない場合）。

中央ポーリング構成が選択されると、中央ポーリング機能（ＣＰ）９８はそれぞれのリンク上でＰＩと通信する。ＣＰ９８は必要なデータ型と通信時期をＰＩ９１に通信する。その後、ＣＰ９８はＰＩ９１からリンクを介してデータを受信する。ただし、常駐ポーリング構成では、ＰＩ９１は中央マネージャ８２から初期ポーリング機能を受信し、必要なデータ型とそのデータの送信時期を決定する。常駐ＰＩ９１は中央データベース９６にデータを送信するのが好ましい。一般に、単一ポーリング構成（中央または常駐）のコンピュータシステムの動作は、従来通りであり、前記動作の詳細については本発明と異なる場合を除きここでは説明しない。

ユーザが最初に複数のポーリング構成を選択できるようにすることに加えて、本発明はポーリング構成を変更できるという便利な特徴がある。たとえば、中央ポーリング構成でのクライアント管理セッションは、単に、クライアント管理セッションを再初期化し、他の構成を選択するだけで、常駐ポーリング構成に変換できる。さらに、本発明は、同時実行クライアント管理セッションをサポートし、特に、１つまたは複数の共通マシンで、異なるエージェント構成を有することができる。

本発明では、ＷＢＥＭインタフェースコンポーネントを使用して管理データを収集するのが好ましい。ＷＢＥＭイニシアティブは、企業計算環境の管理を統一するために開発された一組の管理およびインターネット標準技術に基づいており、一組の標準ベースの管理ツールを使用して、ＣＩＭ（Ｃｏｍｍｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｍｏｄｅｌ）やＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）などの新しい技術を活用できる。本発明で使用できるＷＢＥＭ準拠インタフェースの一例として、Ｍｉｃｒｏｓｏｆｔ ＣｏｒｐｏｒａｔｉｏｎのＷｉｎｄｏｗｓ Ｍａｎａｇｅｍｅｎｔ Ｉｎｓｔｒｕｍｅｎｔａｔｉｏｎ（ＷＭＩ）がある。ただし、本発明とともに他のインタフェースを使用できることも理解されるであろう。いかなる場合も、ポーリングエージェントはそれぞれのクライアントに、ポリシーなどの管理テンプレートを発行し、特定のシステムオブジェクトとそれらのオブジェクトに関して実行する測定を識別する。さらに、それぞれのクライアントは異なるクライアント管理機能について複数のポリシーを受信できる。管理マシン９２のオペレーティングシステムのポリシーエンジンは、システム８０のポリシーを生成するのが好ましい。

図７に示されているように、ポリシー１５０には、ポリシー名コンポーネント１５２、ポリシーからオブジェクトを明示するコンポーネント１５４、およびプロパティコンポーネント１５６を含むのが好ましい。ポリシー１５０のプロパティコンポーネント１５６は、図８−９に示されているようなデータ構造とすることができる。最初に図８を見ると、データ構造１５６に収集名フィールド１５８、レポートタイトルフィールド１６０、レポート日付フィールド１６２、レポート開始時刻フィールド１６４、レポート停止日付フィールド１６６、およびレポート長フィールド１６８が含まれているのが好ましい。さらに、図９に示されているように、データ構造１５６は曜日フィールド１７０、レポートタイプフィールド１７２、優先度フィールド１７４、マシン名フィールド１７６、および収集データベースフィールド１７８を含む。

従来の容量計画製品とは異なり、本発明の好ましい実施形態では、容量計画ポリシーを発行することにより容量計画データを取得する。代表的な容量計画ポリシーでは、ＣＰＵ利用度の測定、キュー長の測定、および入出力操作のカウントにサーバ８４−９０などのマシンが必要と思われる。この情報は、通常、高い優先度情報ではないため時間単位または日単位で収集される。図１３は、ユーザが新しいポリシー測定を作成しクライアント管理マシンに対し発行することができる好ましいグラフィカルユーザインタフェースを示している。

同様に、本発明は、パフォーマンス監視ポリシーを発行することによりパフォーマンス監視データを取得する。容量計画ポリシーの場合のように、パフォーマンス監視ポリシーにより、特定のオブジェクトと、それらのオブジェクトと関連して実行する測定を識別する。ただし、パフォーマンス監視ポリシーは通常、異なる目的に対して異なる情報を求めるという点で容量計画ポリシーと異なる。たとえば、一方のパフォーマンス監視ポリシーでは、ＣＰＵ利用度が３分間に５０％を超える場合のみサーバ８４−９０（図２）がデータを送信する必要がある。ポリシーに違反がなければ、そのポリシーに対する応答としてデータが送信されることはない。ただし、パフォーマンス監視ポリシーの違反は通常、重要度が高く、即座に報告すべきである。

図６は、本発明と関連して使用するのに適しているクライアント１４０のいくつかの内部コンポーネントの図である。サーバ８４−９０のように、クライアント１４０は常駐ポーリングモードで常駐ポーリングエージェントとして機能し、中央ポーリングモードで中央ポーリングエージェントと通信するポーリングインタフェース９１を有する。クライアント１４０は、オブジェクト報告コンポーネント１４４、通信インタフェース１４６、および複数のデータプロバイダ１４８に接続されている管理インタフェース１４２も含む。インタフェース１４２はＭｉｃｒｏｓｏｆｔ ＣｏｒｐｏｒａｔｉｏｎのＷＩＮＤＯＷＳ ２０００オペレーティングシステムであるのが好ましく、レポーティングコンポーネント１４４はデータハンドラであるのが好ましく、通信インタフェース１４６はＭｉｃｒｏｓｏｆｔ ＣｏｒｐｏｒａｔｉｏｎのＡＣＴＩＶＥ ＤＩＲＥＣＴＯＲＹなどのディレクトリであるのが好ましい。ただし、本発明は他のオペレーティングシステム（ＵＮＩＸなど）および他のディレクトリサービス（Ｎｏｖｅｌｌ Ｎｅｔｗａｒｅなど）でも実装できることは理解されるであろう。データプロバイダ１５０は、クライアント１４０のパフォーマンスを測定するのに一般に使用されるカウンタおよび／またはトレースログを含むのが好ましい。

本発明の好ましい実施形態はまた、容量計画データとパフォーマンス監視データの両方を単一の収集機能で収集する機能を含むのが好ましい。従来、パフォーマンス監視データは容量計画製品よりも、Ｍｉｃｒｏｓｏｆｔ ＣｏｒｐｏｒａｔｉｏｎのＷＩＮＤＯＷＳ ＮＴやＷＩＮＤＯＷＳ ２０００オペレーティングシステムに実装されているＰＥＲＦＯＲＭＡＮＣＥ ＭＯＮＩＴＯＲプログラム、または他のパフォーマンス監視プログラムなどの別の製品によって収集されている。これら２種類の製品の収集機能を統合することにより効率を高めることができる。たとえば、管理トラフィックの量を減らすのに、本発明の統合された容量計画機能／パフォーマンス監視機能を使用する。さらに、クライアントごとに１つのポーリングエージェント／ポーリングインタフェースを監視するだけでよいため、メモリ利用度、プロセッサ利用度、およびオペレータ訓練などの、システム資源の負担が軽減される。

統合された容量計画機能／パフォーマンス機能に対する管理ノード１３０を図５に示す。ノード１３０は、要求コンポーネント１３２、容量計画コンポーネント１３４、およびパフォーマンス監視コンポーネント１３６を含む。

容量計画データおよびパフォーマンス監視データは通常同じ頻度では収集されないが、容量計画データとパフォーマンス監視データの収集を統合する方法は多数考えられる。次の容量計画間隔が終了するまでパフォーマンス監視データ（通常は、容量計画データよりも収集頻度が高い）をクライアントの常駐メモリのキャッシュ部分にストアしておき、その後両方の種類のデータをそのときにそれぞれのデータベースに送信するという方法がある。図１０に関して以下に説明するように、キャッシュされたパフォーマンス監視データは、テーブルまたは指定キャッシュ領域のいずれかにストアできる。

容量計画データおよびパフォーマンス監視データの収集を統合する方法として他に、パフォーマンス監視間隔ごとにパフォーマンス監視データをキャッシュと中央データベースの両方に送信するという方法もある。いずれの場合も、キャッシュされているパフォーマンス監視データの平均をとってから、中央データベースに送信できる。他の収集方法を、ポリシー違反の発生に結びつけたり、有効な特定のポリシーに関係する他のイベントの発生に結びつけることもできる。

本発明では、複数のクライアント管理機能を同じコンポーネント（たとえば、ポーリングエージェント）で実行できるため、コンポーネントにより処理されたクライアント管理データに処理のため異なる優先度を割り当てることができる。たとえば、クライアント管理データが容量計画データであれば、これは通常１時間ごとまたは毎日収集されるが、クライアントマネージャが短時間内にデータを受信する必要は最小限である。他方、クライアント管理データがパフォーマンス監視データであれば、これは通常数秒ごとに収集されるため、クライアントマネージャが短時間内にデータを受信する必要は大幅に高まる。従来の容量計画製品は、高いネットワーク利用度の期間中に低優先度の容量計画データを送信するためネットワークトラフィックを無駄に混雑させることがある。

本発明の他の態様では、ポーリングエージェントは高いネットワーク利用度のときに低優先度データの送信を制限することができる。たとえば、常駐ポーリング構成では、クライアントのポーリングエージェントは容量計画データとパフォーマンス監視データの両方をクライアントから受信し、データをクライアントマネージャに送信する間隔が予め設定されている。ただし、送信するデータが容量計画データであれば、ポーリングエージェントはネットワーク利用度の現在レベルを調べる。ネットワーク利用度がしきい値レベルを超えている場合、ポーリングエージェントはネットワーク利用度が許容レベルに達するか、予め設定されている時間になるまで容量計画データを送信しない。それとは対照的に、データがパフォーマンス監視データであれば、ポーリングエージェントはネットワーク利用度に関係なくより高い優先度のデータをクライアントマネージャに送信する。したがって、本発明では、クライアント管理システムを使用すると、ネットワークの負担をさらに軽減できる。

本発明ではまた、ユーザはその測定を必要とするオリジナルの測定テンプレート、つまりポリシーを単に変更するだけで、非アクティブにすることなくアクティブな測定を効果的に変更できる。さまざまな目的でネットワーク全体で比較的多数の測定が行われるとすると（たとえば、オペレーティングシステムの測定）、ポリシーで指定されているアクティブな測定は単に利用可能なアクティブ測定のサブセットに過ぎない。そのため、測定作業を中断することなくポリシーを変更できる。たとえば、特定のマシンのＣＰＵ利用度が５０％を超えたらポリシーで通知を要求することができる。ポリシーを後で修正し、５分間にＣＰＵ利用度が４０％を超えたときのみ通知が行われるようにした場合、測定自体は中断されない。同様に、そのマシンのＣＰＵ利用度の参照を削除することによりポリシーを修正することもできるが、測定はそれでも非アクティブにされない。それ以降、ポリシーを修正して、マシンのＣＰＵ利用度があるしきい値を超えた場合にもう一度通知を要求するようにできる。その結果、基本の測定は、新規ポリシーの送信や既存ポリシーの変更の影響を受けない。図１４では、ユーザが同じまたは類似のグラフィカルユーザインタフェースを使用してアクティブな測定を編集する。従来の容量計画機能はこの機能を備えていない。

本発明には他に、クライアントの場所でパフォーマンスデータをキャッシュし、選択された期間について平均をとり、より正確な容量計画データを取得するという特徴もある。例示のコンピュータシステム１８０が図１０に示されており、バス１９２上で複数のプロセッサ１８４、１８６、１８８、および１９０に結合されたクライアントメモリ１８２を備える。ただし、本発明はメモリと１つまたは複数のプロセッサを備えるコンピュータシステムであればどのようなものにでも実装できることは理解されるであろう。図１０に示されているクライアントメモリ１８２は、キャッシュ１９４を備え、１つまたは複数のテーブル１９６および収集エージェント１９８を備える。

本発明の好ましい実施形態によれば、パフォーマンスデータは選択された間隔でエージェント１９８により収集きれ、一定期間、キャッシュ１９４にストアされる。通常、パフォーマンス監視データは、比較的短い間隔（たとえば、数秒）で収集され、容量計画データは、比較的長い間隔（たとえば、１時間ごと、毎日）で収集される。本発明では、パフォーマンスデータは、容量計画の通常収集間隔よりも短いが、パフォーマンス監視の通常収集間隔よりも長い期間（たとえば、１時間）の間キャッシュするのが好ましい。その後、キャッシュされているデータをその期間について平均し、中央データベースに転送する。平均されたパフォーマンスデータからかなり多くのデータ点が得られるが、これは容量計画データには普通である。たとえば、パフォーマンス監視の収集間隔が３秒で、そのデータの平均が１時間ごとにとられる場合、時間平均は１２００のデータ点に基づくことになる。対照的に、容量計画の時間収集間隔では単一のデータ点に基づいてデータを出力する。当業者であれば、上述の特定の間隔は例示のものにすぎず、実際の間隔は設定可能であることを理解できるであろう。

引き続き図１０を参照すると、本発明のキャッシュ機能は少なくとも２通りの方法で実装できることがわかる。エージェント１９８により収集されたパフォーマンスデータは、管理データを含むように定義されているキャッシュ１９４のある領域に書き込むことができる（つまり、テーブル以外の領域）。それとは別に、キャッシュ１９４のブロックが特定の１つの機能に単独で割り当てられない場合、パフォーマンスデータをキャッシュ内の可変位置にストアできる１つまたは複数のテーブル１９６に書き込むことによりキャッシュ収集プロセスをシミュレートできる。データがキャッシュ領域に書き込まれている場合は、キャッシュにテーブルを置く必要はない。当業者であれば、１つまたは複数のクライアントが代わりに、パフォーマンスデータをリモートキャッシュ（たとえば、図２の管理マシン９２）に転送し、そこでデータをストアして、平均をとり、その後、中央収集位置（たとえば、図２のデータベース９６）に転送できることは理解できるであろう。

本発明がクライアント管理ツール内にアーカイブ機能を備え、それにより、単にアーカイブのため容量計画機能を終了したり起動したりする時間のかかる単調な作業をなくすことができるというのは重要なことである。そのため、ユーザインタフェースは簡素化され、アーカイブ機能を組み込んでいるので、日常作業に対しデータベースの専門家は必要ない。図１５−１７は、クライアント管理ツール内でデータをアーカイブするためのグラフィカルユーザインタフェースのスクリーンショットである。図１５に示されているように、ユーザは新しいパフォーマンスアーカイブを作成するか、アーカイブされたデータを復元するか、またはアーカイブされたファイルを削除する機会が与えられる場合がある。図１６−１７では、グラフィカルユーザインタフェースを使用することで、ユーザはアーカイブされるデータの量を指定できる（たとえば、１年ブロック内のすべてのデータ）。

次に図１１には、例のコンピュータシステム２００が示されており、入出力チャネルを介してディスク制御２０４に結合されている入出力制御２０２が含まれている。複数のディスクドライブ２０６、２０８、２１０、および２１２がバスを介してディスク制御２０４に接続されている。図１１には４つのディスク２０６−２１０が示されているが、システム２００は、本発明の目的のためディスクをいくつでも備えることができる。図１１のディスク構成を利用して、パフォーマンスデータをアーカイブするのが好ましい。たとえば、単一のパフォーマンスアーカイブファイルをディスク２０６などの個別ディスクにのみストアできる。さらに、同じパフォーマンスアーカイブファイルのミラーコピーを冗長性のためディスク２１２などの他のディスクにストアすることもできる。それとは別に、パフォーマンスアーカイブファイルを２つまたは３つ以上のコンポーネントに分けて、別々にストアすることもできる。たとえば、パフォーマンスアーカイブファイルを４つのコンポーネントに分けて、ディスク２０６−２１２のそれぞれにコンポーネントの１つが含まれるようにできる。

本発明の他の特長として、既存の管理データのデータベースから読み込んだり、変換したりする機能がある。本発明では、管理ツールやプロバイダに関係なく将来のクライアント管理を行いやすくする管理データをストアするための標準化されたスキーマが作成され、その際に、Ｍｉｃｒｏｓｏｆｔ ＣｏｒｐｏｒａｔｉｏｎのＳＱＬ Ｓｅｒｖｅｒ Ｄａｔａｂａｓｅ形式などの好ましい３テーブル構成を利用する。それにより、標準化されたスキーマに従って収集されストアされている将来のすべてのデータはさまざまな管理ツールから可読になる。ただし、すでに収集され、標準化された形式と異なる形式でストアされているデータは、読取り不可能になり、かつ／またはマネージャは標準化された形式でストアされている新しいデータを追加できなくなる。そこで、本発明では、既存の管理データベースファイルを読み込み、かつ／または変換する２つの実施形態を利用する。

第１の実施形態において、本発明は、ＳＱＬ Ｓｅｒｖｅｒ Ｄａｔａ Ｔｒａｎｓｆｏｒｍａｔｉｏｎ Ｓｅｒｖｉｃｅ（ＤＴＳ）などのフィルタを利用し、各種の既存形式を受け付け、自動的にこれを標準化形式に変換する。フィルタは、１つまたは複数の既存形式で保存されている既存データベースファイルを受け付けて、これを標準化スキーマに変換する。たとえば、従来のクライアント管理ツールには、Ｍｉｃｒｏｓｏｆｔ ＣｏｒｐｏｒａｔｉｏｎのＥＸＣＥＬスプレッドシート形式などのスプレッドシート形式でクライアント管理データを収集し、定義済みデータの列見出しでストアするものがある。それにより、定義済みデータ形式を受け付けるように設定されているフィルタは、ＥＸＣＥＬファイルを読み込んで、標準化形式に変換する。容易にわかるように、フィルタによって受け付けられる他のタイプの既存データベースファイル構成も本発明の範囲内にあると考えられる。

第２の実施形態において、本発明は、Ｍｉｃｒｏｓｏｆｔ ＶＢスクリプトなどのスクリプト作成可能言語を利用する管理ツールの変換エンジンを備え、ユーザがこれを利用して、既存データベースファイルにより使用されるスキーマの標準化スキーマに対する相関を指定できる。この実施形態において、本発明は、データベースファイルを変換しないが、むしろ、スクリプト相関を利用して既存データベースファイル上のデータを特定する。たとえば、既存データベースファイル内の第１の列では、「マシン名」フィールドを使用してサーバを識別する。ただし、標準化スキーマでは、対応するフィールドは「ＳｅｒｖｅｒＮａｍｅ」と呼ばれる。そこで、既存データベースファイルを読み込ませるため、ユーザはスクリプト作成可能言語を介して、これらのフィールドが同等であり、管理ツールは管理プロセスにより「ＳｅｒｖｅｒＮａｍｅ」フィールド内のデータを呼び出すよう求められたときに「マシン名」フィールドの下を探すことを知っていることを知らせる。図１８は、本発明に基づき相関スクリプトをユーザに入力させるための好ましいユーザインタフェースのスクリーンショットである。容易にわかるように、他のグラフィカルユーザインタフェースも本発明の範囲内にあると考えられる。

次のスクリプトは本発明による変換エンジンへのユーザ入力を示している。

ＳＥＬＥＣＴ ＊ ｆｒｏｍ ＰＥＲＦＴＡＢＬＥ ＷＨＥＲＥ ＭＡＣＨＩＮＥ＿ＮＡＭＥ ＝
″ＤＢ００″ ＯＲ ＭＥＡＳＵＲＥＭＥＮＴ＿ＮＡＭＥ ＝
″ＤＡＴＡＢＡＳＥ＿ＭＡＣＨＩＮＥ＿ＭＥＡＳＵＲＥＭＥＮＴ″
この例では、スクリプトは、変換エンジンで「ＰＥＲＦＴＡＢＬＥ」という名前のデータベースファイルから「ＤＢ００」の「ＭＡＣＨＩＮＥ＿ＮＡＭＥ」または「ＤＡＴＡＢＡＳＥ＿ＭＡＣＨＩＮＥ＿ＭＥＡＳＵＲＥＭＥＮＴ」の「ＭＥＡＳＵＲＥＭＥＮＴ＿ＮＡＭＥ」という列見出しの下にあるプロパティを持つすべてのデータを選択することを指示している。容易にわかるように、他の入力モデルも本発明の範囲内にあると考えられる。

他の特長では、本発明は既存データベースファイルにリンクし拡張する機能を含む。ログファイルなどのデータベースファイルでは、ファイルの終わり（ＥＯＦ）標識を使用して、測定データファイルからの終わりを示す。一般に、これらのログファイルは専用目的で指定され（たとえば、容量計画またはパフォーマンス監視）、一般には管理ツールデータベースファイルを拡張できないという不備とはみなされない。ただし、本発明では収集された管理データをパフォーマンス監視と容量計画の両方に使用できるため、本発明では、収集しさまざまな目的のために利用する管理データが増えたときにファイルを拡張する。

たとえば、これは、パフォーマンス監視データをログファイルに書き込むときに、本発明のパフォーマンス監視コンポーネントで利用される。特定の収集プロセスの完了後、ＥＯＦ指示子をファイルの終わりに付けて、読み込む管理データがもうないことを示す。ただし、より多くのパフォーマンス監視データが収集されたら、データは容量計画目的にも使用されるので、同じログファイルに追加すると好ましい。本発明は、着信データを受け付けて、ファイルのＥＯＦを新しいデータの終わりに再配置する。それにより、ログファイルが拡張される。

本発明の他の態様によれば、既存ログファイルの拡張は標準化形式でフォーマットされているログファイルで機能するのが好ましい。それにより、ログファイルに書き込まれる新しい管理データは標準化スキーマに応じて編成するのが好ましい。データ内の整合性を保持するために、データベースファイル内の管理データをスキーマに従ってストアし、新しいデータを追加できるようにするのが好ましい。

図４は、サービストランザクションを実行するため例のサービス連鎖１２０における本発明の応用を示している。サービス連鎖１２０は、複数のサービス連鎖コンポーネント１２２、１２４、１２６および１２８を含む。クライアントマネージャ８２は、コンポーネント１２２−１２８のパフォーマンスを監視するためにサービス連鎖１２０と通信している。図４に示されているサービス連鎖はＭ１からＭ４までの一連のマシンとして示されているが、サービス連鎖１２０は注目しているサービストランザクションと関連するハードウェアおよび／またはソフトウェアコンポーネントの任意の組合せで構成できる。

本発明では容量計画機能とパフォーマンス監視機能の両方を実装するのが好ましいため、クライアントマネージャ８２がいずれかの機能を宛先とするポリシーをコンポーネント１２２−１２８に発行できる。たとえば、第１のポリシーはシステムパフォーマンスを推定し、システムがサービスレベルアグリーメント（ＳＬＡ）に違反する可能性があるかどうかを判別する容量計画機能を実装できる。第２のポリシーでは、しきい値を超えたことをリアルタイムで検出することによりパフォーマンス監視機能を実装できる。そこで、本発明のクライアント管理製品により、従来の製品よりも完全なサービス連鎖の管理を実施できる。

本発明の他の実施形態も、図面を含む本明細書を検討した後関連する技術分野の当業者にとっては明白なことであろう。さまざまなコンピュータシステムおよびコンポーネントが図１−１８に示されておりまた仕様にも記述されているが、本発明に関して使用するのに適しているものの例にすぎない。したがって、本発明の範囲は、上記の説明ではなくむしろ添付の請求項で定義される。

発明の効果

以上説明したように、本発明によれば、クライアント管理ツールにおいてさまざまなポーリングエージェント機能を実行する方法とシステムが提供される。

本発明の実施に使用するのに適しているコンピュータシステム環境のブロック図である。 本発明の好ましい実施形態の実施に適している複数のクライアントおよび中央マネージャを含むコンピュータシステムのブロック図である。 本発明を実施するための例示のＷｅｂベースのコンピュータシステムのブロック図である。 本発明と関連して使用するのに適しているサービス連鎖のブロック図である。 容量計画機能の収集機能がパフォーマンスモニタの収集機能と統合されている本発明の好ましい実施形態の構成要素を示すブロック図である。 本発明と関連して使用するのに適しているポーリングインタフェースとサーバ管理インタフェースとの交互作用を示すブロック図である。 本発明の好ましい実施形態により発行されるポリシーの構成要素を示すブロック図である。 図７のポリシーの特性構成要素のデータ構造のブロック図である。 図７のポリシーの特性構成要素のデータ構造のブロック図である。 本発明の好ましい実施形態によるクライアントパフォーマンスデータをローカルにストアするキャッシュを備えるコンピュータシステム例のブロック図である。 本発明の好ましい実施形態によるパフォーマンスデータをアーカイブする例示のコンピュータシステムを示すブロック図である。 本発明の好ましい実施形態による複数の使用可能なポーリング構成からユーザに選択させるためのグラフィカルユーザインタフェースのスクリーンショットを示す図である。 本発明の好ましい実施形態による新しいポリシー測定を作成するためのグラフィカルユーザインタフェースのスクリーンショットを示す図である。 本発明の好ましい実施形態によるアクティブなポリシー測定を編集するためのグラフィカルユーザインタフェースのスクリーンショットを示す図である。 本発明の好ましい実施形態による１つまたは複数のすでに収集されている管理データファイルをアーカイブするためのグラフィカルユーザインタフェースのスクリーンショットを示す図である。 本発明の好ましい実施形態による新しいパフォーマンスアーカイブを作成するためのグラフィカルユーザインタフェースのスクリーンショットを示す図である。 本発明の好ましい実施形態による新しいパフォーマンスアーカイブを作成するためのグラフィカルユーザインタフェースのスクリーンショットを示す図である。 本発明の好ましい実施形態による変換エンジンのスクリプト作成相関（ｓｃｒｉｐｔｅｄ ｃｏｒｒｅｌａｔｉｏｎ）を入力するためのグラフィカルユーザインタフェースのスクリーンショットを示す図である。

２０ コンピュータ
２２ 処理ユニット
２４ システムメモリ
２６ システムバス
２８ 読取り専用メモリ（ＲＯＭ）
３０ ランダムアクセスメモリ（ＲＡＭ）
３２ 基本入出力システム（ＢＩＯＳ）
３４ ハードディスクドライブ
３６ 磁気ディスクドライブ
３８ 取外し可能不揮発性磁気ディスク
４０ 光ディスクドライブ
４２ 取外し可能不揮発性光ディスク
４４ Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ（ＳＣＳＩ）
４６ オペレーティングシステム
４８ アプリケーションプログラム
５０ プログラムモジュール
５２ プログラムデータ
５４ キーボード
５６ ポインティングデバイス
５８ ユーザ入力インタフェース
６０ シリアルポートインタフェース
６１ モニタ
６２ ビデオアダプタ
６４ リモートコンピュータ
６６ ローカルエリアネットワーク（ＬＡＮ）
６８ ワイドエリアネットワーク（ＷＡＮ）
７２ モデム
８０ コンピュータシステム
８２ 中央マネージャ
８４、８６、８８、９０ クライアント
９１ ポーリングインタフェース（ＰＩ）
９２ 管理マシン
９４ コンソール
９６ データベース
９８ 中央ポーリングエージェント
１００ ネットワーク
１０２ 活動スクリーン
１０４ Ｗｅｂサーバ
１０６ クライアントサーバ
１０８ アプリケーションサーバ
１１０ データベースサーバ
１２０ サービス連鎖
１２２、１２４、１２６、１２８ サービス連鎖コンポーネント
１３０ 管理ノード
１３２ 要求コンポーネント
１３４ 容量計画コンポーネント
１３６ パフォーマンス監視コンポーネント
１４０ クライアント
１４２ 管理インタフェース
１４４ オブジェクト報告コンポーネント
１４６ 通信インタフェース
１４８ 複数のデータプロバイダ
１５０ ポリシー
１５２ ポリシー名コンポーネント
１５４ ポリシーからオブジェクトを明示するコンポーネント
１５６ プロパティコンポーネント
１５８ 収集名フィールド
１６０ レポートタイトルフィールド
１６２ レポート日付フィールド
１６４ レポート開始時刻フィールド
１６６ レポート停止日付フィールド
１６８ レポート長フィールド１６８
１７０ 曜日フィールド
１７２ レポートタイプフィールド
１７４ 優先度フィールド
１７６ マシン名フィールド
１７８ 収集データベースフィールド
１８２ クライアントメモリ
１８４、１８６、１８８、１９０ プロセッサ
１８０ コンピュータシステム
１９２ バス
１９４ キャッシュ
１９６ テーブル
１９８ 収集エージェント
２００ コンピュータシステム
２０２ 入出力制御
２０４ ディスク制御
２０６、２０７、２０８、２０９、２１０ ディスク

Claims (15)

1. クライアントマネージャと、複数のクライアントマシンとを含むコンピュータシステムにおいて、前記複数のクライアントマシンからデータを収集する１つまたは複数のポーリングエージェントを実行するコンピュータシステムにおける方法であって、
   前記クライアントマネージャにおいて、複数のポーリング機能の１つを選択することをユーザに求めるステップであって、前記複数のポーリング機能は、第１のポーリング機能と、第２のポーリング機能とを含むステップと、
   前記第１のポーリング機能が選択された場合、ポーリングエージェントを前記クライアントマネージャに常駐させるステップであって、前記クライアントマネージャに常駐するポーリングエージェントは、所与の間隔で前記複数のクライアントマシンにクライアントデータの要求を発行するステップと、
   前記第２のポーリング機能が選択された場合、前記ポーリングエージェントを前記複数のクライアントのうちの第１のクライアントマシンに常駐させるステップであって、前記第１のクライアントマシンに常駐するポーリングエージェントは、所与の間隔で前記クライアントマネージャに前記クライアントデータを送信するステップと
   を含み、
   前記クライアントデータは容量計画データまたはパフォーマンス監視データを含み、
   前記クライアントデータが容量計画データである場合、前記第１のクライアントマシンに常駐するポーリングエージェントはネットワーク利用度の現在レベルを調べ、前記ネットワーク利用度がしきいレベルを超える場合に前記クライアントマネージャに前記容量計画データを送信せず、
   前記クライアントデータがパフォーマンス監視データである場合、前記第１のクライアントマシンに常駐するポーリングエージェントは、前記ネットワーク利用度に関わらず前記クライアントマネージャに前記パフォーマンス監視データを送信することを特徴とする方法。
   
2. 前記複数のポーリング機能の１つをデフォルトとして指定し、ユーザ選択が受信されない場合に前記デフォルトに対応する少なくとも１つのポーリングエージェントを実行するステップをさらに含むことを特徴とする請求項１に記載の方法。
   
3. 前記複数のクライアントマシンのうちの２つまたは３つ以上がサーバであることを特徴とする請求項１に記載の方法。
   
4. 請求項１に記載のステップを実行するためのコンピュータ実行可能命令を組み込んだことを特徴とするコンピュータ可読媒体。
   
5. プロセッサ、メモリ、およびオペレーティング環境を備えることを特徴とするコンピュータシステムであって、請求項１に記載のステップを実行するため操作可能なコンピュータシステム。
   
6. 複数のクライアントマシンを管理するコンピュータシステムであって、
   クライアントマネージャと、
   該クライアントマネージャと通信する複数のクライアントマシンのうちの第１のクライアントマシンと、
   前記複数のクライアントマシンからデータを収集するためのポーリングエージェントと
   を備え、
   前記コンピュータシステムが第１のポーリングモードで動作するときに前記ポーリングエージェントが前記第１のクライアントマシンに常駐し、該第１のクライアントマシンに常駐するポーリングエージェントは所与の間隔で前記クライアントマネージャにクライアントデータを送信し、
   前記コンピュータシステムが第２のポーリングモードで動作するときに前記ポーリングエージェントが前記クライアントマネージャに常駐し、該クライアントマネージャに常駐するポーリングエージェントは、所与の間隔で前記複数のクライアントマシンにクライアントデータの要求を発行し、
   前記クライアントデータは容量計画データまたはパフォーマンス監視データを含み、
   前記クライアントデータが容量計画データである場合、前記第１のクライアントマシンに常駐するポーリングエージェントはネットワーク利用度の現在レベルを調べ、前記ネットワーク利用度がしきいレベルを超える場合に前記クライアントマネージャに前記容量計画データを送信せず、
   前記クライアントデータがパフォーマンス監視データである場合、前記第１のクライアントマシンに常駐するポーリングエージェントは、前記ネットワーク利用度に関わらず前記クライアントマネージャに前記パフォーマンス監視データを送信することを特徴とするコンピュータシステム。
   
7. 前記コンピュータシステムが第１のポーリングモードで動作するときに前記複数のクライアントマシンのうちの第２のクライアントマシンに常駐する第２のポーリングエージェントをさらに備え、該第２のポーリングエージェントは所与の間隔で前記クライアントマネージャに前記クライアントデータを送信することを特徴とする請求項６に記載のコンピュータシステム。
   
8. 前記コンピュータシステムが第２のポーリングモードで動作するときに前記第１のクライアントマシンに常駐する第２のポーリングエージェントをさらに備え、該第２のポーリングエージェントは所与の間隔で前記クライアントマネージャに前記クライアントデータを送信することを特徴とする請求項６に記載のコンピュータシステム。
   
9. 前記クライアントマネージャは、前記ポーリングエージェントによって収集されたデータをストアするためのデータベースを含むことを特徴とする請求項６に記載のコンピュータシステム。
   
10. 前記クライアントマネージャは、複数のポーリングモードから選択するよう前記ユーザに求めるためのユーザインタフェースを含むことを特徴とする請求項６に記載のコンピュータシステム。
    
11. 複数のクライアントマシンを管理するコンピュータシステムであって、
    該コンピュータシステムを集中管理するクライアントマネージャと、
    該クライアントマネージャと通信する前記複数のクライアントマシンのうちの第１のクライアントマシンと、
    前記複数のクライアントマシンからデータを収集するポーリングエージェントと
    を備え、
    前記コンピュータシステムが第１のポーリングモードで動作するときに前記ポーリングエージェントが前記第１のクライアントマシンに常駐し、該第１のクライアントマシンに常駐するポーリングエージェントは所与の間隔で前記クライアントマネージャにクライアントデータを送信し、
    前記コンピュータシステムが第２のポーリングモードで動作するときに前記ポーリングエージェントが前記クライアントマネージャに常駐し、該クライアントマネージャに常駐するポーリングエージェントは、所与の間隔で前記複数のクライアントマシンにクライアントデータの要求を発行し、
    前記クライアントデータは容量計画データまたはパフォーマンス監視データを含み、
    前記クライアントデータが容量計画データである場合、前記第１のクライアントマシンに常駐するポーリングエージェントはネットワーク利用度の現在レベルを調べ、前記ネットワーク利用度がしきいレベルを超える場合に前記クライアントマネージャに前記容量計画データを送信せず、
    前記クライアントデータがパフォーマンス監視データである場合、前記第１のクライアントマシンに常駐するポーリングエージェントは、前記ネットワーク利用度に関わらず前記クライアントマネージャに前記パフォーマンス監視データを送信することを特徴とするコンピュータシステム。
    
12. 前記ポーリングエージェントは、前記コンピュータシステムが第１のポーリングモードで動作するときに前記複数のクライアントマシンのうちの第２のクライアントマシンに常駐する第２のポーリングエージェントを含み、該第２のポーリングエージェントは所与の間隔で前記クライアントマネージャに前記クライアントデータを送信することを特徴とする請求項１１に記載のコンピュータシステム。
    
13. 前記ポーリングエージェントは、前記コンピュータシステムが前記第２のポーリングモードで動作するときに、前記クライアントマネージャの第１のポーリングエージェントと、前記第１のクライアントマシンに常駐する第２のポーリングエージェントとを含み、該第２のポーリングエージェントは所与の間隔で前記クライアントマネージャに前記クライアントデータを送信することを特徴とする請求項１１に記載のコンピュータシステム。
    
14. 前記クライアントマネージャは、前記ポーリングエージェントによって収集されたデータをストアするためのストレージ手段を含むことを特徴とする請求項１１に記載のコンピュータシステム。
    
15. 前記クライアントマネージャは、複数のポーリングモードから選択するよう前記ユーザに求めるためのユーザインタフェース手段を含むことを特徴とする請求項１１に記載のコンピュータシステム。

Images