JP2009519520A - 処理能力のリアル・タイム・ベンチマーキングに基づきソフトウェア製品の使用量を測定する方法、システムおよびコンピュータ・プログラム - Google Patents

Abstract

【課題】データ処理システム上のソフトウェア製品の使用量を測定するソリューション（３００）を提案する。
【解決手段】これに関連して、一般的なソフトウェア製品が実行される各コンピュータの処理能力を知る必要があることが多い（例えば、区別された課金単価に基づきライセンシング会計を行うために）。提案されるソリューションでは、コンピュータ上で直接、処理能力が動的に推定される。この目的のために、起動時にまたは定期的になど、低水準言語で書かれた（単一スレッドの）ベンチマーク・プログラムが実行される（３０８〜３２２）。このようにして、ベンチマーク・プログラムの測定された実行時間をその命令の既知数で割る（３２４）ことで、コンピュータの単一のマイクロプロセッサの実行率を判断することが可能である。この値に、利用可能なマイクロプロセッサの検出された（３０６；３３２）数を掛けると、コンピュータの処理能力の正確な推定がもたらされる。コンピュータの物理的詳細を認識することをまったく必要とせずに、所望の結果を得られる。これは、コンピュータが、物理ホスト・マシンに実装された論理ゲスト・マシンで構成されていると特に有利である。
【選択図】図４〜５

Description

本発明は、情報技術分野に関する。本発明は特に、データ処理システム上のソフトウェア製品の使用量を測定することに関する。

いくつかの管理アプリケーションでは、データ処理システムにおいてソフトウェア製品の使用量を測定することが最も重要である。典型的な例は、ライセンス管理インフラストラクチャから成る。これは、システム上での既知のソフトウェア製品の実行を制御するのに使用される。市販されている業務用のライセンス管理インフラストラクチャの一例は、ＩＢＭ Ｃｏｒｐｏｒａｔｉｏｎ（ＩＢＭはＩＢＭ Ｃｏｒｐｏｒａｔｉｏｎの商標）による「ＩＢＭ Ｔｉｖｏｌｉ Ｌｉｃｅｎｓｅ Ｍａｎａｇｅｒ（ＩＴＬＭ）（ＴｉｖｏｌｉはＩＢＭ Ｃｏｒｐｏｒａｔｉｏｎの登録商標）」アプリケーションに基づく。

一般的に、このようにして得られた、ソフトウェア製品の使用量についての情報は、（対応する使用条件に従った）チャージバック会計（ｃｈａｒｇｅ−ｂａｃｋ ａｃｃｏｕｎｔｉｎｇ）に利用される。これに関連して、ライセンシング戦略における最近の傾向は、例えば利用可能な（マイクロ）プロセッサの数とともに課金単価を上げるなど、ソフトウェア製品が実行されるシステムのハードウェア構成に従ってソフトウェア製品の課金単価を変化させるというものである。しかし、このモデルの制限は、価格付けの点から見るとすべてのマイクロプロセッサが同等であると想定されることである（その結果、ローエンドのシステムとハイエンドのシステムとでのソフトウェア製品の使用の間に差がなくなる）。この戦略は、ハイエンド・システムに関しては過少請求につながり、逆にローエンド・システム上（過剰請求と認識されると思われる）で同じソフトウェア製品が使用されるのを妨げる。

上述の問題を解決するために、マイクロプロセッサをそれらの処理能力に従って分類することが提案されている。このようにして、（対応する課金単価を、一般的には処理能力とともに上げて適用するために）異なるシステム上でのソフトウェア製品の使用量を区別することが可能になると思われる。

しかし、上記のメカニズムの実装は非常に難しい。実際には、まず第１に、（的確な課金単価を関連付けられるようにするために）マイクロプロセッサに重み付けをするための標準のベンチマークを確立する必要がある。さらに、既存のマイクロプロセッサの全タイプ（マイクロプロセッサの重みを伴う）のカタログが、ライセンシング・アプリケーションに利用可能でなければならない。これは、カタログを常に最新に保つという負担を与える。

いかなる場合でも、システムが実コンピュータで構成されていなければ必ず技術的な問題に直面する。例えば、システムは（物理）ホスト・マシンの論理パーティションによって実装されることもある。保持が非常に容易な（論理）ゲスト・マシンを（異なる実コンピュータを増設する必要なく）多数シミュレートできるようになるため、当該のソリューションはますますよく使われるようになっている。しかしこの状況では、システムはライセンシング・アプリケーションによって必要とされる構成情報（例えば、マイクロプロセッサの数およびタイプ）を集められないことが非常に多い。実際、設計上の意図的な選択、または環境固有の制限が原因で、この情報はゲスト・マシンに対して隠されていることもある。

本発明は独立請求項に記されているようにソリューションを提供する。本発明の有利な実施形態が従属請求項に記載されている。

原則として、本発明は、システムの処理能力を動的に測るという考えに基づく。

特に、本発明の態様は、データ処理システム上のソフトウェア製品の使用量を測定する方法を提案する。この方法は、システム上の一連の所定のソフトウェア製品それぞれの実行を示す実行インデックス（それらの実行期間など）を測るステップから開始する。続いて、対応する実行インデックスおよびシステムの処理能力に従って、各ソフトウェア製品の使用量が判断される。この目的のために、ベンチマーク・プログラムがシステム上で実行される。ベンチマーク・プログラムは所定数の命令を実行する。方法は、ベンチマーク・プログラムの実行時間の指標を判断することによって継続する。次に、実行時間および命令の数に従って処理能力を計算できる。

本発明の実施形態では、ベンチマーク・プログラム（割り込み不可）の開始時間および終了時間を記録し、次にそれらの差を計算することによってその実行時間が判断される。

別の実施形態では、対応するプロセスに対してシステムのプロセッサにより費やされた時間を読み出す（オペレーティング・システムからなど）ことによって同じ結果が得られる。

一般的に、ベンチマーク・プログラムは低水準言語（例えばアセンブラなど）で書かれている。

システムが起動されたときにベンチマーク・プログラムの実行を開始するという選択が推奨される。

提案されるソリューションがマイクロプロセッサ・システムに実装されると、ベンチマーク・プログラム（単一スレッド）によって判断された処理能力にプロセッサの数が乗じられる。

これに関連して、このソリューションをさらに改善する方法は、プロセッサの数の変化が検出されたときだけに処理能力を再計算することである。

提案されるソリューションは、複数の（論理）ゲスト・マシンを実装している（物理）ホスト・マシンに適用されると有利である（この場合、すべての動作は単一のゲスト・マシン上で行われる）。

本発明の別の態様は、方法を実行するコンピュータ・プログラムを提案する。

本発明のさらなる態様は、付随するシステムを提案する。

単に非制限的な指示の目的で与えられており添付の図面と併せて読まれる、以下の発明を実施するための最良の形態を参照すれば、発明そのもの、ならびにそのさらなる特徴および利点をよく理解できる。

特に図１を参照すると、分散型アーキテクチャを有するデータ処理システム１００が表されている。システム１００は、選択されたソフトウェア製品（アプリケーション・プログラムなど）の使用量を測定できるようにするライセンス管理インフラストラクチャ（例えば、上述のＩＴＬＭに基づく）を実装している。システム１００は、１つ以上の独立した機関を含み（図には１つだけ示されている）、これらは完全に分離し、互いに異なっている。機関内には、１つ以上の部門が定義されている。

各部門は、ランタイム・サーバ１０５によって形成されており、ランタイム・サーバ１０５は、対応する一連の実行サーバ（またはノード）１１０上の割り当て済みのソフトウェア製品の使用量を直接制御する。実行サーバ１１０は、物理ホスト・マシン１１５上に実装されている論理ゲスト・マシンで構成されていてもよい。各ホスト・マシン１１５（ＩＢＭ Ｃｏｒｐｏｒａｔｉｏｎによる「ｚＳｅｒｉｅｓ（ＩＢＭ Ｃｏｒｐｏｒａｔｉｏｎの商標）、「ＡＳ／４００（ＩＢＭ Ｃｏｒｐｏｒａｔｉｏｎの商標）」または「Ｐｏｗｅｒ５（ＩＢＭ Ｃｏｒｐｏｒａｔｉｏｎの商標）」タイプのものなど）は、１つ以上の実行サーバ１１０をサポートする（例えば、対応する論理パーティションを用いて）。ランタイム・サーバ１０５と、部門のすべての実行サーバ１１０とは、ネットワーク１２０（例えばＬＡＮ）を介して通信する。

異なるランタイム・サーバ１０５は、機関全体の在庫、調達および会計情報の中央管理点を実装する単一の管理サーバ１２５に報告を行う。ランタイム・サーバ１０５および管理サーバ１２５は、別のネットワーク１３０（例えば、インターネットに基づく仮想プライベート・ネットワーク、すなわちＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ））に接続されている。

ここで図２について検討すると、上記のシステムの一般的なコンピュータ（ランタイム・サーバ、実行サーバのホスト・マシン、または管理サーバ）が１５０で示されている。コンピュータ１５０は、システム・バス１５３（システム内のコンピュータ１５０の実際の機能に従って適切に調整された構造を有する）に並列に接続されているいくつかのユニットによって形成されている。詳しくは、１つ以上の（マイクロ）プロセッサ（μＰ：ｍｉｃｒｏｐｒｏｃｅｓｓｏｒ）１５６が、コンピュータ１５０の動作を制御する。ＲＡＭ１５９は、マイクロプロセッサ１５６によってワーキング・メモリとして直接使用され、ＲＯＭ１６２は、コンピュータ１５０のブートストラップのための基本コードを格納している。いくつかの周辺ユニットが、ローカル・バス１６５の周りに（それぞれのインターフェースを用いて）集められている。特に、大容量記憶装置は１つ以上のハード・ディスク１６８と、ＣＤ−ＲＯＭ１７４を読み取るためのドライブ１７１とで構成されている。さらに、コンピュータ１５０は、入力ユニット１７７（例えばキーボードおよびマウス）および出力ユニット１８０（例えばモニタおよびプリンタ）を含む。コンピュータ１５０をシステムに接続するためにアダプタ１８３が使用されている。ブリッジ・ユニット１８６は、システム・バス１５３とローカル・バス１６５とを結びつけている。各マイクロプロセッサ１５６およびブリッジ・ユニット１８６は、情報伝送のためにシステム・バス１５３へのアクセスをリクエストするマスタ・エージェントとして動作することができる。アービタ１８９は、システム・バス１５３に対する相互排除でのアクセス承諾を管理する。

図３に移ると、上記のシステム上で実行されている主要ソフトウェア・コンポーネントが、参照２００を用いてまとめて示されている。情報（プログラムおよびデータ）は一般的にハード・ディスク上に格納されており、プログラムの実行中、各コンピュータのワーキング・メモリに（少なくとも部分的に）ロードされる。プログラムは初めに、例えばＣＤ−ＲＯＭからハード・ディスクにインストールされる。

一般的なホスト・マシン１１５について特に検討すると、マネジャ２０５は、そのハードウェア構成を制御する。この目的のために、ハードウェア・マネジャ２０５はユーザ・インターフェースを提供し、これは、ハードウェア・リソースの追加、削除、セットアップおよび同様のことなどの処理に利用可能なハードウェア・リソース（マイクロプロセッサ、ワーキング・メモリ、大容量記憶装置、周辺ユニットなど）を定義するのに使用される。一般的に、ホスト・マシン１１５のハードウェア構成における変更はいずれもマシンの再起動（コールド・チェンジ（ｃｏｌｄ ｃｈａｎｇｅ））を必要とする。なお、ホスト・マシン１１５はウォーム・チェンジ（ｗａｒｍ ｃｈａｎｇｅ）もサポートすることもあり、その場合は、その動作を停止することなくハードウェア構成が更新される。これは、例えば、ホスト・マシン１１５がキャパシティ・オン・デマンド（ＣｏＤ：Ｃａｐａｃｉｔｙ ｏｎ Ｄｅｍａｎｄ）オプションで購入されている場合にあり得る。この場合は、ホスト・マシン１１５には、その標準的な使用に必要とされるよりも多くのハードウェア・リソース（および特にマイクロプロセッサ）が含まれる。マイクロプロセッサのサブセットは永続的に利用可能である一方、残る余分のマイクロプロセッサは、それらが実際に必要なときにのみオン・デマンドで有効化される（ワークロードのピークを受けて数時間など）。ＣｏＤオプションをサポートしている市販製品は、ＩＢＭ Ｃｏｒｐｏｒａｔｉｏｎによる、「ｚＳｅｒｉｅｓ」、「ＡＳ／４００」および「Ｐｏｗｅｒ５」コンピュータである。

仮想化レイヤ２１０は複数のゲスト・マシンをシミュレートし、これは、ホスト・マシン１１５上で実行される種々の実行サーバ１１０を実装する。具体的には、仮想化レイヤ２１０は、ホスト・マシン１１５を複数の論理パーティション（ＬＰＡＲｓ：Ｌｏｇｉｃａｌ Ｐａｒｔｉｔｉｏｎｓ）に分ける。各論理パーティションは、ホスト・マシン１１５のハードウェア・リソースのサブセットで構成され、別々のコンピュータとして独立して動作する。一般的に、ホスト・マシン１０５がＣｏＤオプションを実装すると、ハードウェア・マネジャ２０５は、各論理パーティションに対し、所定の最大数まで動的にマイクロプロセッサを割り当てる。例えば、ホスト・マシン１１５が８つのマイクロプロセッサおよび４つの論理パーティションを含めば、最大２つのマイクロプロセッサを各論理パーティションに割り当てることが可能である（言うまでもなく、総数の８に達するまで）。論理パーティション化をサポートする市販製品の例は、ＩＢＭ Ｃｏｒｐｏｒａｔｉｏｎによる「ｚＳｅｒｉｅｓ」および「ＡＳ／４００」コンピュータである。

ここで、ホスト・マシン１１５上に定義されている一般的な実行サーバ１１０を参照すると、ゲスト・オペレーティング・システム２１５（ＩＢＭ Ｃｏｒｐｏｒａｔｉｏｎによる「ｚＯＳ」、または「Ｌｉｎｕｘ（Ｒ）」など）が、そのソフトウェア・プラットフォームを定義しており、その上で他の任意のプログラムを実行できる。上で指摘したように、オペレーティング・システム２１５は実コンピュータにインストールされているかのように機能する（仮想化レイヤ２１０によってシミュレートされながら）。

１つ以上のソフトウェア製品２２０が実行サーバ１１０上にインストールされている。ライセンシング・エージェント２２５が、実行サーバ１１０上で実行されているソフトウェア製品２２０を検出する。この目的のために、ライセンシング・エージェント２２５は、ランタイム・サーバ１０５からダウンロードされるソフトウェア・カタログ２３０ｃのローカル・コピーにアクセスする（例えば、定期的に、またはその任意の変更時に）。ソフトウェア・カタログ２３０ｃは、機関内の測定対象の既知のソフトウェア製品をすべて特定している。各ソフトウェア製品は、１つ以上の実行可能モジュールにより定義される署名によって識別され、このモジュールは、実行中にソフトウェア製品の使用を示す。一般的に、各実行可能モジュールは、ソフトウェア・カタログ２３０ｃ内で複数の属性（その名前、サイズおよびチェックサムなど）を用いて特定される。

ライセンシング・エージェント２２５は、実行サーバ１１０上で現在実行中のソフトウェア製品２２０のリスト（認識されていない未知のソフトウェア製品についての入手可能な情報を含む）をソフトウェア・モニタ２３５に供給する。ソフトウェア・モニタ２３５は、ランタイム表２４０にアクセスする。ランタイム表は、実行サーバ１１０上で使われているソフトウェア製品２２０のスナップショットを提供する。このようにして、ソフトウェア・モニタ２３５は、（動作の最後の反復以後に）開始または停止されたソフトウェア製品２２０を判断することができる。そのようにして得られた情報（対応するタイム・スタンプを伴う）はソフトウェア・ログ２４５に追加され、同時にそれに応じてランタイム表２４０が更新される。

本発明の実施形態によるソリューションでは、ベンチマーク・プログラム２５０が、実行サーバ１１０の処理能力を動的に測る。以下で詳しく説明されるとおり、この目的のために、ベンチマーク・プログラム２５０が実行されて、その実行時間が測られる。ベンチマーク・プログラム２５０は所定数の命令を実行する。例えば、この結果は、基本的な命令（例えば算術演算）を一定回数反復すること（ループを用いてなど）によって得られる。したがって、実行サーバ１１０の処理能力をその稼働率に従って推定することが可能であり、稼働率は、ベンチマーク・プログラム２５０の測定された実行時間を既知の命令の数で割って計算される。

提案されるソリューションは、実行サーバ１１０の処理能力の判断を大きくはかどらせる。具体的には、いかなるカタログを保持する必要もなく所望の結果がリアルタイムで得られる。さらに、必要な情報が動的に収集され、その結果、実行サーバ１１０の実際の処理能力の正確な状況が常に提供される。

いかなる場合でも、発明されたソリューションは、実行サーバ１１０の処理能力の測定をそれらの物理的詳細から切り離す。さらに具体的には、この技術は、実行サーバ１１０の実際の構造を認識することをまったく必要としない。したがって、実行サーバ１１０のハードウェア構成についての情報（それらのマイクロプロセッサのタイプなど）を読み出す必要はない。実行サーバ１１０が実コンピュータで構成されていなければ、それらのハードウェア構成についての情報を収集することは（不可能ではないにせよ）非常に困難である可能性があり、その場合にこの利点を明らかに、はっきりと理解できる。したがって、提案されるソリューションは、実行サーバ１１０の実装に関係なく普遍的に適用できる。

ベンチマーク・プログラム２５０は、低水準言語（アセンブラまたは機械語など）で書かれていることが好ましい。低水準言語は、コンピュータのマイクロプロセッサによって実行可能な動作に対応する基礎的な命令セットのみをサポートする。機械語では、命令は、マイクロプロセッサの動作を直接制御するのに使用可能なビット・パターン（機械コード）で構成される。一方、アセンブラ言語では、読み書きがさらに容易な簡略記号（アセンブラによって対応する機械コードに変換される）を用いて同じ命令が表される。低水準言語は、より豊富な命令セットを人間用のフォーマット（ｈｕｍａｎ ｆｏｒｍａｔ）でサポートする高水準言語とは異なる。それらの実行には、（例えば、コンパイラによって静的に、またはインタプリタによって動的に）当該の命令が対応する機械コードのストリームに変換されなければならない。コンパイラまたはインタプリタは、実コンピュータ、またはその実際の実装を隠している仮想マシンに対して機械コードを生成するとよい（Ｊａｖａ（登録商標） Ｒｕｎ Ｔｉｍｅ Ｅｎｖｉｒｏｎｍｅｎｔによってサポートされているバイトコードなど）。低水準言語でベンチマーク・プログラム２５０を書くという選択によって、異種の実行サーバ１１０上で得られる結果が必ず優れた均一性を有することになるが、これは、コンパイラまたはインタプリタによりもたらされ得る差異が避けられるためである。

さらに、上記のマルチプロセッサ環境（実行サーバ１１０が２つ以上のマイクロプロセッサを含み得る）では、ベンチマーク・プログラム２５０は単一スレッドでなければならない。結果として、ベンチマーク・プログラム２５０は、その稼働率を正確に推定するために、常に単一のマイクロプロセッサ上で実行される。この場合、実行サーバ１１０の総処理能力は、その（等しい）マイクロプロセッサの数をそのようにして得られた結果に掛けることによって得られる。

この目的のために、ベンチマーク・プログラム２５０は、特定のアプリケーション・プログラム・インターフェース（ＡＰＩ：Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）を介してオペレーティング・システム２１５と連動する。ベンチマーク・プログラム２５０は、実行サーバ１１０の推定処理能力を（対応するタイム・スタンプと共に）ハードウェア・ログ２５５に追加する。

ライセンシング・エージェント２２５は、ソフトウェア・ログ２４５およびハードウェア・ログ２５５の両方にアクセスする。ライセンシング・エージェント２２５は、上記のソフトウェア実行情報をソフトウェア・ログ２４５（すなわち、任意のソフトウェア製品２２０の開始時間または停止時間あるいはその両方）から抽出し、上記のハードウェア容量情報をハードウェア・ログ２５５（すなわち、処理能力）から抽出する。この情報は次に、ランタイム・サーバ１０５へ（実行サーバ１１０の識別子と共に）伝送される。

ここでランタイム・サーバ１０５について検討すると、ライセンシング・マネジャ２６０は、部門内のすべての実行サーバ１１０のソフトウェア実行情報およびハードウェア容量情報を受信する。ライセンシング・マネジャ２６０は、情報の種々の断片を、（グローバル）部門ログ２６５に保存し、管理サーバ（図示せず）にアップロードする。さらに加えて、ライセンシング・マネジャ２６０は、ソフトウェア・カタログ（２３０ｍで示されている）の主要コピーを同じ管理サーバからダウンロードする（例えば、定期的に、またはその任意の変更時に）。

一般的に、管理サーバは受信された情報を利用レポートに集約する。利用レポートは、実行サーバ１１０上で所定期間中（最終日など）に実行されたソフトウェア製品を一覧表にする。利用レポートは、各ソフトウェア製品に関して、異なる処理能力を有する実行サーバ１１０上（すなわち、異なる実行サーバ１１０上、または経時的に異なるハードウェア構成を有する同じ実行サーバ１１０上、あるいはその両方）での、あらゆる実行期間の長さを特定する。例えば、利用レポートは特定のソフトウェア製品が或る実行サーバ１１０上でローエンドのマイクロプロセッサを１つ用いて２時間、或る実行サーバ１１０上でハイエンドのマイクロプロセッサを１つ用いて１時間、および同じ実行サーバ１１０上であるが今度はハイエンドのマイクロプロセッサを２つ用いて３時間実行していたことを示すこともある。一般的に、利用レポートはさらに、その機関の実行サーバ１１０上で起こったあらゆる特異なイベント（未知のソフトウェア製品の使用など）を指摘する。

この情報は、既知のソフトウェア製品のあらゆる利用に関して所定のライセンス料を（それらの使用要件によって特定されているとおり、異なる処理能力に対する所定の料金に従って）課金するために使用されるとよい。例えば、上述の状況では、実行サーバ１１０上でローエンドのマイクロプロセッサを１つ用いてソフトウェア製品を使用すると毎時間小額が課金されることになり、他の実行サーバ１１０上でハイエンドのマイクロプロセッサを１つ用いて使用すると毎時間より多くの額が課金されることになり、同じ実行サーバ１００上でハイエンドのマイクロプロセッサを２つ用いて使用すると毎時間さらに多くの額が課金されることになる。図４〜５を参照すると、（所望のソフトウェア製品の使用量を測定する）上記のシステムに実装できる例示的なプロセスの論理フローが、方法３００を用いて表されている。方法３００は、一般的な実行サーバのスイム・レーン（ｓｗｉｍ−ｌａｎｅ）内の、開始の黒丸３０２で始まる。プロセスは、実行サーバが作動するとすぐにブロック３０４に入る。この段階で、実行サーバの処理能力を推定するためにライセンシング・エージェントが呼び出される。この目的のために、ライセンシング・エージェントはブロック３０６で、（オペレーティング・システムの対応するＡＰＩを用いて）実行サーバが利用可能なマイクロプロセッサの数を検出する。

次に、ライセンシング・エージェントはベンチマーク・プログラムを実行して、その実行時間を判断する。この結果は、２つの異なる方法で得られることが可能である。これらは、同期化バー（ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ ｂａｒ）３０８において二者択一のブランチに分岐するアクティビティのフローによって表されている。具体的には、或る実装はブロック３１０−３１６によって形成されたブランチの実行を伴う一方、別の実装は、ブロック３１８−３２０によって形成されたブランチの実行を伴う。２つのブランチは、さらなる同期化バー３２２においてつながっている。

ここでブロック３１０について検討すると、（オペレーティング・システムの対応するＡＰＩを用いて）システム・クロックがサンプリングおよび記録される。次に、ベンチマーク・プログラムがブロック３１２で開始される。ベンチマーク・プログラムの実行が終了する（ブロック３１４）とすぐに、再度システム・クロックがサンプリングおよび記録される。ブロック３１６へ移動して、最初のシステム・クロック（その開始時間を示す）を２番目のシステム・クロック（その終了時間を示す）から引くことによって、ベンチマーク・プログラムの実行時間が計算される。ブランチは同期化バー３２２で終了する。この場合、ベンチマーク・プログラムは割り込み不可でなければならない。すなわち、（割り当てられている）マイクロプロセッサ上でのその実行を、違うリクエストにサービスを提供するために一時停止することはできない。結果として、ベンチマーク・プログラムは、他のどのソフトウェア・プログラムとも競合せずにマイクロプロセッサを独占的に使用する。さらに、ベンチマーク・プログラムは、比較的多数の命令（例えば少なくとも数百、好適には数千）を実行しなくてはならない。結果として、その開始時間および終了時間を記録するために費やされる時間は、ベンチマーク・プログラムの実行時間に対して無視できる（したがって、その判断の正確さに悪影響は及ぼさない）。上記の実装は非常に容易であり、普遍的に適用できる。

あるいは、従来どおり、ベンチマーク・プログラムがブロック３１８で起動される。この場合、ベンチマーク・プログラムは他のあらゆるソフトウェア・プログラムのように（実行サーバのマイクロプロセッサの使用に関してそれらと競合しながら）実行される。方法３００は、ベンチマーク・プログラムの実行が終了するとすぐにブロック３２０へ続く。この段階で、ライセンシング・エージェントは、ベンチマーク・プログラムの実行に使用されたプロセスのプロセッサ時間（オペレーティング・システムによって記録されている）を読み出す。この結果は、例えば、オペレーティング・システムの対応するＡＰＩを呼び出すことによって、または専用ログ（「ｚ／ＯＳ」のＳＭＦレコードなど）にアクセスすることによって得られる。なお、プロセッサ時間は、マイクロプロセッサが一様に他のプロセスにもサービスを提供していた間の相当する経過時間を除外して、そのプロセスに対して関連のマイクロプロセッサにより実際に費やされた時間を示す。このブランチも同じく同期化バー３２２で終了する。この場合、実行時間を非常に正確に計算できる。

いずれの場合も、プロセスはここでブロック３２４へ続く。この段階で、ベンチマーク・プログラムの測定された実行時間（一般的には秒で表される）が、その（既知の）命令の数で割られる。これは、実行サーバの一般的なマイクロプロセッサの（推定）稼働率をもたらす（命令／秒で表される）。ブロック３２６へ進み、そのようにして得られた稼働率にそのマイクロプロセッサの数を掛けることによって、実行サーバの総処理能力が計算される。ライセンシング・エージェントは、ブロック３２８で、この情報を（対応するタイム・スタンプと共に）ハードウェア・ログに追加する。

実行サーバの起動時にベンチマーク・プログラムを実行するという選択は、サーバ上で実際のビジネス・ワークロードがアクティブになる前にそれが必ず完了するようにする。これは、実行サーバのパフォーマンスに対するこの動作の影響を最小化する（特に、ベンチマーク・プログラムが割り込み不可であり、その結果マイクロプロセッサ全体を独占的に使用する場合）。

さらに、またはこの代わりに、所定のタイムアウトが終了するとすぐに（例えば１０〜６０分ごとに）、プロセスはブロック３３０からブロック３３２へ移る。この段階で、ライセンシング・エージェントは、実行サーバのマイクロプロセッサの数を再度検出する。ここで、ブロック３３４でテストが行われて、（動作の最後の反復以後に）マイクロプロセッサの数が変化したかどうかが判断される。変化していれば、（マイクロプロセッサの新たな数およびそれらの既知の稼働率に従って）実行サーバの処理能力を再計算するために、アクティビティのフローはブロック３２６へ続く。この特長によって、たとえ付随するハードウェア構成がその動作を停止することなく更新可能な場合でも、実行サーバの処理能力を追跡することが可能になる。なお、この動作を任意の変化が検出されるのに応答してのみ実行するという選択をすることで、実行サーバのパフォーマンスに対する影響を許容範囲に保つことになる。

いかなる場合でも、動作が終了すると、方法３００はブロック３２８からブロック３３６へ移る。マイクロプロセッサの数が変化していないときも、ブロック３３４から直接同じ点に達する。別のタイムアウトが終了するとすぐに（例えば１〜１０分ごとに）、ライセンシング・エージェントは、ブロック３３８で、（オペレーティング・システムの対応するＡＰＩを用いて）実行サーバ上のアクティブなプロセスのリストを読み出す。次に、各プロセスのループが実行される（初めのものから開始して）。ループはブロック３４０で始まり、ここではライセンシング・エージェントが、対応する実行可能モジュール（オペレーティング・システムから返される名前によって識別される）にアクセスし、その結果、モジュールのさらなる属性（すなわち、問題の例ではサイズおよびチェックサム）が読み出される。ブロック３４２へと続いて、ライセンシング・エージェントは、実行可能モジュールのサイズおよびチェックサムと、その名前に関してソフトウェア・カタログ内で特定されているもの（もしあれば）とを比較する。実行可能モジュールの属性がソフトウェア・カタログ内のエントリと一致すれば（決定ブロック３４４）、対応するソフトウェア製品がブロック３４６で識別される。逆に、ブロック３４８では、ソフトウェア製品は未知と設定される（実行可能モジュールの名前など、あらゆる利用可能情報が保存される）。いずれの場合でも、このようにして得られた情報は、ブロック３５０で、実行サーバ上で現在実行中のソフトウェア製品のリストに追加される。次に、ブロック３５２でテストが行われ、すべてのプロセスが分析されたかどうかが判断される。されていなければ、方法はブロック３４０へ戻り、次のプロセスに対して同じ動作を繰り返す。逆に、ループが終了されるとブロック３５４に入る。この段階で、ソフトウェア・モニタは、（動作の最後の反復以後に）開始または停止されたソフトウェア製品を検出するために、（ライセンシング・エージェントから受信された）実行中のソフトウェア製品のリストと、ランタイム表の内容とを比較する。ブロック３５６へと続いて、このようにして得られた情報が（対応するタイム・スタンプと共に）ソフトウェア・ログに追加され、ランタイム表がそれに応じて更新される。

ブロック３５８で、別のタイムアウトが終了するとすぐに（例えば６〜２４時間ごとに）、プロセスはブロック３６０に入る。この段階で、ライセンシング・マネジャは、（ソフトウェア・ログから）ソフトウェア実行情報を、（ハードウェア・ログから）ハードウェア容量情報を抽出する。続いてこの情報は、（実行サーバの識別子と共に）ランタイム・サーバへ伝送される。それに応答して、ランタイム・サーバはブロック３６２で、受信された情報を部門ログに保存する。

ブロック３６４で別のタイムアウトが終了するのに応答して（例えば毎日の終わりに）、ブロック３６６で、ライセンシング・マネジャは部門ログ内の利用可能な情報を管理サーバにアップロードする。管理サーバのスイム・レーンに移り、受信された情報を集約することによって、新たな利用レポートをブロック３６８で生成できる。このようにして得られた利用レポートは、次にブロック３７０で（例えば適切なライセンス料を課金するために）分析される。次に、方法は白／黒の停止の同心円３７２で終了する。

当然ながら、ローカルな特有の要件を満たすために、当業者は上述のソリューションに数多くの修正および変更を加えてもよい。特に、本発明は、その好適な実施形態（単数または複数）を参照してある程度詳細に説明されたが、当然のことながら、形態および細部における種々の省略、代用および変更、ならびに他の実施形態があり得る。さらに、本発明の開示されている任意の実施形態に関連して説明された特定の構成要素または方法ステップあるいはその両方は、全般的な設計上の選択の問題として、他の任意の実施形態に組み込まれてもよいことが明確に意図されている。

例えば、システムが異なるアーキテクチャを有するかまたは等価なユニットを含む場合も、同様の考慮事項が当てはまる。さらに、各コンピュータは、別の構造を有することも、または同様の構成要素（実行中の大容量メモリへのアクセスを減らすためにプログラムまたはその一部を一時的に格納するキャッシュ・メモリなど）を含むこともある。いずれの場合でも、コンピュータを任意のコード実行エンティティ（ＰＤＡ、移動電話、および同様のものなど）と交換することが可能である。

本発明の実装が、いかなる特定のライセンシング・アプリケーションにも、または実行サーバ上で実行中のソフトウェア製品を識別する技術にも、あるいはその両方にも限定されないということは、容易に分かるはずである。例えば、任意の新たなソフトウェア製品（または、電子ブックなど、任意の等価なデジタル・コード化された製品）の呼び出しを、対応するプロセスの開始を傍受すること（例えば、カーネル・フッキング技術を使用して）によって検出することが可能である。同じく、ソフトウェア製品の呼び出しの数（対応する実行期間の長さの代わりに）、またはより一般的にはそれらの実行を示すその他任意のインデックスを測ることも可能である。さらに、利用可能な情報は、単に、適用される使用条件への準拠を確認するためにでも、またはより一般的にはどのような管理目的のためにでも使用され得る。

ベンチマーク・プログラムの実行時間（および続いて処理能力）を判断する提案されたアルゴリズムは、単なる例である。例えば、ベンチマーク・プログラムによるすべての動作の直接的な実装が妨げられることはない。代わりに、独立して処理能力を推定してそれをランタイム・サーバへ伝送する明確なエージェントを有することが可能である。

本発明の原理から逸脱せずに、ベンチマーク・プログラムが他の任意の命令を（たとえ異なる言語で書かれていても）実行することもできる。

あるいは、実行サーバの起動時のみにベンチマーク・プログラムを開始することが可能である（例えば、ウォーム・チェンジが不可能なとき）。反対に、実行サーバの起動時のベンチマーク・プログラムの開始は、そのハードウェア構成が継続的に監視されていれば無効にされてもよい。いかなる場合でも、ベンチマーク・プログラムの実行に関する種々のスケジューリング・ポリシーは本発明の範囲内にある（例えば、単に定期的になど）。

提案されたソリューションは、いくつかの論理パーティションに分けられたマルチプロセッサ・コンピュータ用に特に設計されているが、これは制限的に解釈されてはならない。例えば、単一のマイクロプロセッサを備えたコンピュータ上に同じソリューションを適用することが妨げられることはない。さらに、本発明によるソリューションは、仮想マシン上、またはより一般的に物理ホスト・マシン上に実装された他の任意の論理ゲスト・マシンで使用されるのに適している。いかなる場合でも、仮想化レイヤを備えていない実コンピュータ上に同じ技術を等しく適用できる。

プログラム（本発明の各実施形態を実装するのに使用されるとよいもの）が異なる方法で構築されたとしても、または追加のモジュールもしくは機能が提供されたとしても、同様の注意事項が当てはまる。同じく、メモリの構造は他のタイプであってもよく、または等価なエンティティと交換されてもよい（必ずしも物理記憶媒体で構成されていなくてもよい）。さらに、提案されているソリューションは、等価な方法（同様のステップまたは追加のステップを、たとえ異なる順序でも有する）を用いて実装されるのに適している。いかなる場合でも、プログラムは、外部もしくは常駐のソフトウェア、ファームウェアまたはマイクロコード（オブジェクト・コードかまたはソース・コードで）など、任意のデータ処理システムによってかまたはそれと関連して使用されるのに適した任意の形態であればよい。さらに、プログラムはコンピュータが使える任意の媒体上に提供されればよい。媒体は、プログラムを含むこと、格納すること、伝達すること、伝播させること、または転送することに適した任意の構成要素とすることができる。かかる媒体の例は、固定ディスク（この場合プログラムはプリインストール可能）、取り外し可能ディスク、テープ、カード、ワイヤ、ファイバ、無線接続、ネットワーク、放送波および同様のものなどである。例えば、媒体は、電子、磁気、光学、電磁気、赤外線または半導体のタイプであってもよい。

いかなる場合でも、本発明によるソリューションは、ハードウェア構造（例えば、半導体材料のチップに統合されている）を用いて、またはソフトウェアとハードウェアとの組み合わせを用いて行われるのに適している。

本発明の実施形態によるソリューションを適用できるデータ処理システムの概略ブロック図である。 システムの例示的なコンピュータの機能ブロックである。 本発明の実施形態によるソリューションを実践するのに使用できる主要ソフトウェア・コンポーネントを表している。 本発明の実施形態によるソリューションの実装に関するアクティビティのフローを表す図である。 本発明の実施形態によるソリューションの実装に関するアクティビティのフローを表す図である。

Claims (10)

1. データ処理システム上のソフトウェア製品の使用量を測定する方法（３００）であって、前記方法は、
   前記システム上の一連の所定ソフトウェア製品それぞれの実行を示す実行インデックスを測るステップ（３３６〜３５６）と、
   各ソフトウェア製品の使用量を、対応する実行インデックスと、前記システムの処理能力とに従って判断するステップ（３５８〜３７０）と、
   を含み、
   所定数の命令を実行するベンチマーク・プログラムを前記システム上で実行するステップ（３１２；３１８）と、
   前記ベンチマーク・プログラムの実行時間の指標を判断するステップ（３１０、３１４〜３１６；３２０）と、
   前記処理能力を、前記実行時間および命令の前記数に従って計算するステップ（３２４）と、
   を特徴とする、方法。
2. 前記ベンチマーク・プログラムは割り込み不可であり、前記実行時間の前記指標を判断する前記ステップ（３１０、３１４〜３１６）は、
   前記ベンチマーク・プログラムの開始時間を記録すること（３１０）と、
   前記ベンチマーク・プログラムの終了時間を記録すること（３１４）と、
   前記終了時間と前記開始時間との間の差に従って前記実行時間を計算すること（３１６）と、
   を含む、請求項１に記載の方法（３００）。
3. 前記システム上で完了された各プロセスに対して前記システムのプロセッサにより費やされたプロセッサ時間が記録され、前記実行時間の前記指標を判断する前記ステップ（３２０）は、
   前記ベンチマーク・プログラムを実行するために使用されたベンチマーク・プロセスの前記プロセッサ時間に従って前記実行時間を決めること（３２０）
   を含む、請求項１に記載の方法（３００）。
4. 前記ベンチマーク・プログラムは低水準言語の一連の命令で構成されている、請求項１〜３いずれかに記載の方法（３００）。
5. 前記システムの起動に応答して前記ベンチマーク・プログラムの前記実行を開始するステップ（３０４）
   をさらに含む、請求項１〜４いずれかに記載の方法（３００）。
6. 前記システムは１よりも多い数のプロセッサを含み、前記ベンチマーク・プログラムは前記プロセッサのうちの１つで実行されるようになっており、前記方法は、
   プロセッサの前記数を判断するステップ（３０６；３３２）と、
   プロセッサの前記数に基づく倍数因子に従って前記処理能力を更新するステップ（３２６）と、
   をさらに含む、請求項１〜５いずれかに記載の方法（３００）。
7. プロセッサの前記数の変化を検出するステップ（３３０〜３３２）と、
   前記変化の前記検出に応答して、前記処理能力の前記更新を実行するステップ（３３４）と、
   をさらに含む、請求項６に記載の方法（３００）。
8. 前記システムは、複数の論理ゲスト・マシンを実装している物理ホスト・マシンで構成されており、前記ベンチマーク・プログラムを実行する前記ステップ（３１２；３１８）と、前記実行時間の前記指標を判断する前記ステップ（３１０、３１４〜３１６；３２０）と、前記処理能力を計算する前記ステップ（３２４）とは、前記ゲスト・マシンのうち選択されたマシンで行われる、請求項１〜７いずれかに記載の方法（３００）。
9. データ処理システム（１００）上で実行されると請求項１〜８いずれかの方法（３００）を実行するコンピュータ・プログラム（２００）。
10. 請求項１〜８いずれかに記載の方法（３００）の前記ステップを実行する手段（２００）を含むシステム（１００）。

Images