JP4267225B2 - システムに形成された論理パーティションの容量制限を強化するための方法及び装置 - Google Patents
システムに形成された論理パーティションの容量制限を強化するための方法及び装置 Download PDFInfo
- Publication number
- JP4267225B2 JP4267225B2 JP2001301690A JP2001301690A JP4267225B2 JP 4267225 B2 JP4267225 B2 JP 4267225B2 JP 2001301690 A JP2001301690 A JP 2001301690A JP 2001301690 A JP2001301690 A JP 2001301690A JP 4267225 B2 JP4267225 B2 JP 4267225B2
- Authority
- JP
- Japan
- Prior art keywords
- consumption
- logical
- partition
- logical partitions
- logical partition
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5061—Partitioning or combining of resources
- G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Debugging And Monitoring (AREA)
Description
【０００１】
【発明の属する技術分野】
論理的に分割された情報処理システムにおける容量制限を強化するための方法及び装置、特にソフトウェア・プログラム・ライセンス契約によって課された容量制限にもとづいたそのような容量制限を強化するための方法及び装置に関する。
【０００２】
【従来の技術】
上記のように、この発明は、プログラム・ライセンス契約によって課されたような容量制限を強化することに関する。本発明で扱う問題についての議論の前提として、論理的に分割されたシステムとリソース及び作業負荷管理に関する既存の方法とについて順次簡単に説明する。
【０００３】
論理的パーティション形成は、現在のＩＢＭ製Ｓ／３９０コンピュータ・ハードウェア・プラットホームの先行モデルに対して作られたコンセプトである。今日、多くのＳ／３９０ハードウェア・マシンが論理的パーティション形成（ＬＰＡＲ）モードとして知られるモードで動作する。この際、マシンの物理的リソースが分割されて論理パーティションと呼ばれる複数の論理マシンが形成される。特に、各論理パーティションは、実際の物理的マシンと動作の点で類似している論理マシンとしてパーティションで実行されるプログラミングのように見える。
【０００４】
論理的な分割によって、中央処理装置複合体（ＣＰＣ）とも呼ばれる１つの物理的な中央エレクトロニクス複合体（ＣＥＣ）の中に複数のシステム・イメージを設定することが可能となる。すなわち、各論理パーティションを個別にリセットしたり、各論理パーティション毎に異なったオペレーティング・システムによって初期化したり、異なる入出力（Ｉ／Ｏ）装置を用いて異なるソフトウェア・プログラムによって動作させたりすることができる。論理的パーティション形成は、今日一般的に使用されている。なぜなら、それによって、使用中の論理パーティションの数及び各パーティションに割り当てられた物理的システム・リソースの量を変化させる柔軟性がそのユーザに対して与えられ、ある場合においては、一方で中央処理装置複合体全体が動作を続ける。
【０００５】
論理パーティション形成コンピュータ・システムが従来技術においてよく知られており、さらに米国特許第４，５６４，９０３号（Guyette他）、米国特許第４，８４３，５４１号（Bean他）、及び米国特許第５，５６４，０４０号（Kubala）に開示されている。本明細書ではこれらの特許文献を発明の詳細な説明の一部をなすものとして援用する。論理的パーティション形成システムの市販の実施形態として、例えば本明細書において援用されるＩＢＭの出版物であるProcessor Resource/Systems Manager Planning Guide, GA22-7236-06（２０００年６月発行）に記載され、かつ特徴付けられたProcessor Resource/Systems Manager（登録商標）（ＰＲ／ＳＭ（登録商標））が挙げられる。
【０００６】
作業負荷管理は、オペレーティング・システムによって管理される作業の単位（プロセス、スレッド等）が所定の目標をどれぐらい十分に満たしているかにもとづいてシステム・リソースが提供されるクラス（サービス・クラス又は目標クラス）の中に組織化されるコンセプトである。もし再割り当てによって生ずるレシーバ・クラスのパフォーマンスの向上がドナー・クラスのパフォーマンスの低下を上回る、すなわち所定のパフォーマンス基準によって定められるような正味の効果がパフォーマンスにあるとするならば、リソースはドナー・クラスからレシーバ・クラスに再度割り当てられる。この種の作業負荷管理は、リソースの割り当てが、リソースが再割り当てされる作業単位上のその効果のみならず、リソースが取られる作業単位に対するその効果によっても決定される点で、ほとんどのオペレーティング・システムで実行された従来のリソース管理とは異なるものである。
【０００７】
この一般的形式の作業負荷管理は、以下に示すような一般に所有された特許、係属中の特許出願、及び特許以外の出版物に開示されており、これらの文献を本明細書では援用する。
【０００８】
「マルチ処理システムにおけるトランザクション・クラス応答時間目標を達成するための作業負荷管理プログラム」と題されたD.F. Ferguson他の米国特許第５，５０４，８９４号、
「２つ以上の異なる処理目標にもとづいてデータ処理システム作業負荷を管理するための装置及び方法と題されたJ. D. Aman他の米国特許第５，４７３，７７３号、
「クライアント／サーバ・データ処理システムにおけるクライアント・パフォーマンス目標にもとづくサーバ仕事負荷を管理するための装置及び方法」と題されたC. K. Eilert他の米国特許第５，５３７，５４２号、
「基準が目標指向であり、容量情報が入手可能である資格のあるクラスへ分類することに基づいた仕事要求を割り当てるシステム」と題されたJ. D. Aman他の米国特許第５，６０３，０２９号、
「複数の異なる処理目標形式に基づく分散データ処理システム仕事負荷を管理するための装置及び方法」と題されたC. K. Eilert他の１９９５年２月３日出願の米国特許出願一連番号０８／３８３，１６８号、
「マルチシステム・リソース・キャッピング」と題されたC. K. Eilert他の１９９５年２月３日出願の米国特許出願一連番号０８／３８３，０４２、
「マルチサーバ・シスプレックス環境におけるセッション要求割り当てのための装置及び付随する方法」と題されたJ. D. Aman他の１９９５年７月７日出願の米国特許出願一連番号０８／４８８，３７４、
ＭＳＶプラニング：仕事負荷管理、ＩＢＭ出版物ＧＣ２８−１７６１−００（１９９６年）、及び
ＭＳＶプログラミング：仕事負荷管理サービス、ＩＢＭ出版物ＧＣ２８−１７７３−００（１９９６年）。
【０００９】
これらの特許及び特許出願の中で、米国特許第５，５０４，８９４号及び第５，４７３，７７３号は基本的な仕事負荷管理システムを開示、米国特許第５，５３７，５４２号はクライアント／サーバ・システムに対する米国特許第５，４７３，７７３号の仕事負荷管理システムの特定用途を開示、米国特許出願一連番号０８／３８３，１６８及び０８／３８３，０４２は多重相互接続したシステムに対する米国特許第５，４７３，７７３号の仕事負荷管理システムの特定用途を開示、米国特許第５，６０３，０２９号はマルチシステム複合体（シスプレックス）における仕事要求の割り当てに関し、さらに米国特許出願一連番号０８／４８８，３７４はそのような複合体におけるセッション要求の割り当てに関する。特許とは関係ない２つの出版物は、ＩＢＭ（登録商標）のＯＳ／３９０（商標）（旧ＭＶＳ（登録商標））オペレーティング・システムにおける作業管理のインプリメンテーションについて説明している。
【００１０】
論理パーティションをひとまとめにする最近の技術は、論理パーティション管理及び仕事負荷管理の複数の態様を組み合わせるものである。本明細書で援用する同時係属出願である出願人J. P. Kubala他の米国特許出願一連番号０９／４０７，３９１（１９９９年９月２８日出願）は、動作の１つのモードにおいてＬＰ管理プログラム１０６が論理パーティション１８０をＬＰクラスタ（ＬＰＣ）又は単にクラスタとここでは呼ぶ群として管理する。クラスタは、特定のマシン１０２上の論理パーティション１８０の全て、特定のマシン１０２上のパーティション１０８のサブセット、又は異なるマシン１０２のパーティション１０８からなるものであってもよい。ＬＰ管理プログラム１０６は、全体として所定量のマシン・リソース（本発明の場合、共用ＣＰＵ容量）をクラスタに割り当ててもよい。クラスタはリソース競合が存在するとその所定量に制限されるが、競合が存在しない場合は潜在的にそのリソースをさらに多く使うことができる。
【００１１】
さらに、全体としてクラスタに対してマシン・リソースの共有を割り当てることに加えて、この動作モードでＬＰ管理プログラム１０６は、それぞれのパーティションに割り当てられた論理パーティションの重みに基づいてクラスタを構成している論理パーティション１０８間でリソースを割り当てることができる。この重みの一例として、４つの論理パーティション（ＬＰ１〜ＬＰ４）からなり、かつ４００ＭＩＰＳ（毎秒４００万命令）全ＣＰＵ容量を利用可能とするＬＰクラスタを考慮する。ＬＰ１〜Ｌ４は、クラスタ全体の重みを１００とすると、それぞれ２０、３０、４０、及び１０の重みが割り当てられていと想定する。この例では、もしＣＰＵ競合があるならば、パーティションＬＰ１〜ＬＰ４は、クラスタ容量４００ＭＩＰＳと同等の容量全体に対して、それぞれ８０ＭＩＰＳ、１２０ＭＩＰＳ、１６０ＭＩＰＳ、及び４０ＭＩＰＳの容量で動作することが可能となる。このような背景によって、本発明によって扱われた問題を論ずることができる。第１に、それはＳ／３９０等のサーバ・プラットホーム用のソフトウェアがライセンスされる方法に関係している。今日、Ｓ／３９０ソフトウェア、すなわちＩＢＭソフトウェア及びベンダ・ソフトウェアの両方の多くが該ソフトウェアが実行される物理的マシンの大きさに基づいて価格が設定されている。１つの中央処理装置（ＣＰＵ）を持つマシン（ここで「マシン」と呼ぶものは物理的マシン）は、１０個のＣＰＵを有するマシン上で実行される同一アプリケーションよりも低価格である。価格は、アプリケーションによって実際に行われる仕事量とは無関係である。
【００１２】
この価格設定スキームは、エンド・ユーザに対してソフトウェアの経費をより低くするために、最適な構成よりも少なく構築させることができる。例えば、もし新しいソフトウェア・プロダクトによって小規模の実験を開始したいならば、ユーザはソフトウェアの価格を低く抑えておくために、既存の大型のマシンで実行される代わりに、小さなマシンで新しいプロダクトを実行させる。このことは、もう１つのマシンを扱うことについての追加の管理を必要とし、既に言及した論理パーティションのクラスタ形成技術を利用するインストレーションを許さない。これらの問題は、Ｓ／３９０マシンの大きさが多くのカスタマ作業負荷よりも早く成長しているという事実によって悪化されている。
【００１３】
それを多少異なったかたちで述べるために、今日、Ｓ／３９０プラットホーム・ソフトウェアは、全マシンに対して最もよくライセンスされる。ソフトウェアが実行されるマシンの全容量（一般に、１秒間あたり数百万の命令、又はＭＩＰＳとして発現される）に基づいているほとんどのソフトウェアの価格設定によって、マシンの容量増加によってユーザのソフトウェアライセンス費用が跳ね上がる。もし、所定のプログラム製品がマシンの容量全体で使用されるならば、エンド・ユーザ又はベンダに対して、これは必ずしも良くない事柄又はモデルではない。しかし、もしプログラム製品がマシンの一部で使用されることを意図しているならば、論理パーティション内で、マシンの容量全体に対してその製品をライセンスすることは高価な仕事である。
【００１４】
Ｓ／３９０プラットホームの長所の１つは、ハードウェア・リソースを効率的に利用するために、多数の論理パーティションで多数かつ多様な作業負荷を実行する能力である。Ｓ／３９０上で新しい作業負荷（例えば、ＵＮＩＸ(R)系アプリケーション及びＷｅｂサーバ）を動かす試みは、既存のアプリケーションに並行し、かつ既にＳ／３９０に備わっているデータベースと協同して、それらの新しい作業負荷を既存のマシンに負荷することが可能であることが求められる。しかし、マシンに基づいたソフトウェア価格設定では、それらの作業負荷に対するＳ／３９０ワールドへのエントリ・コストは、代わりのプラットホームと競合するコストではない。
【００１５】
【発明が解決しようとする課題】
本発明は従来の問題点を解決し、論理的に分割された情報処理システムにおける容量制限を強化するための方法及び装置、特にソフトウェア・プログラム・ライセンス契約によって課された容量制限にもとづいたそのような容量制限を強化するための方法及び装置を提供することを目的とする。
【００１６】
【課題を解決するための手段】
本発明は、物理的マシンが複数の論理パーティションに分割され、論理パーティション管理プログラムによってプロセッサ・リソースの所定部分が各パーティションに割り当てられている情報処理システムにおけるソフトウェア・ライセンス契約管理プログラムによって課された容量制限等の容量制限を強化するための方法及び装置を検討する。各論理パーティションに対してプロセッサ・リソース制限を与えることができる。ソフトウェア・ライセンス契約管理プログラムは、各論理パーティションで実行されているプログラムが該パーティションの少なくとも容量制限でライセンスされていることを確かめる。パーティションでも実行されている作業負荷管理プログラムは、プロセッサ・リソースの実際の消費を所定の平均間隔で測定し、それを最大許容消費と比較する。もし実際の消費が最大許容消費を超えると、作業負荷管理プログラムはキャッピング・パターンを計算し、論理パーティション管理プログラムと相互作用し、計算されたキャッピング・パターンに基づくパーティションに基づいて、プロセッサ・リソースの実際の消費をキャップする。さらにキャッピングのフレキシビリティを与えるために、論理パーティション管理プログラムが全パーティション重みに加算する見かけの重みがパーティションに対して割り当てられ、パーティションがキャッピングを目的としたプロセッサ・リソースの許容共有レベルを超えたかどうかが判断される。したがって、論理パーティションは、マシン全体の容量よりも少ない強化された処理能力（それにもとづいてソフトウェアの価格が設定される）によってライセンスされたプログラムのための「コンテナ」となる。
【００１７】
マシンに基づいたスキームよりもむしろ論理パーティションに基づいた価格設定スキームによって、Ｓ／３９０上での仕事負荷に対するソフトウェアの初期投入コストが反映させるべきものはマシン全体ではなく該マシンの能力のサブセットのみである。このことによって、特に論理パーティション・クラスタが伝えることができる作業負荷平衡及び管理の利益を考慮する場合に、最小のコストでＳ／３９０マシンに対して作業負荷を加えることが可能となる。正味の結果によって、さもなければ未使用の容量をかなり有する外部ボックス上にある作業負荷を以前よりはより多くの総購入容量を持つＳ／３９０マシンに負荷することが今や可能となる。
【００１８】
本発明は、ＯＳ／３９０の作業負荷管理プログラム（ＷＬＭ）コンポーネントの能力を利用し、論理パーティションのためのＣＰＵリソースの消費をモニタする。ＷＬＭは、論理パーティションに対するいくらかの所定容量制限に対して実際のＣＰＵリソース消費を比較する。論理パーティションがその容量制限を越える場合、ＷＬＭは論理パーティションをその容量制限まで削減する。
【００１９】
好ましくは、論理パーティションの実際のモニタリングによって、ライセンスされた容量を超えて仕事負荷のピークを生じさせることが可能となる。このことは、適当な時間間隔を超えてなだらかに起伏した平均利用率を計算することによって好ましくは行われる。例えば、４時間間隔は、一時的な仕事負荷スパイクの間での容量要求を提供するのには長く、一方でシフト変化を超えて「ゲーミング」を防ぐには短すぎる。したがって、ソフトウェアは瞬間的なピーク容量よりもむしろ平均化されたピーク容量に対してライセンスされる。
【００２０】
ＷＬＭは、論理パーティションにおいてＣＰＵリソースの全消費をモニタするが、個々のプログラム・プロダクトによるリソースの使用についてはモニタしない。したがって、論理パーティション内で実行されるオペレーション・システム（例えば、ＯＳ／３９０）はライセンス及び管理された容量の一定量に対する「コンテナ」となる。ライセンスされたプログラムはそのサイズのコンテナ（少なくとも）のためにライセンスされ、さらにＷＬＭは該コンテナ・サイズが保たれるのを保証する。例えば、カスタマは各ソフトウェア・アプリケーション用にプロセッサ容量のいくらかに対するライセンス証（すなわち、証明機関によってデジタル署名された書類を買っても良い。好ましくは、ライセンス契約管理プログラムとしてここで言及される新規アプリケーションは、ＷＬＭ及びライセンスされたプログラムと通信し、何を実行させて何を実行させないかを決定する。ライセンス契約管理プログラムは、例外だと見なさなければならないようなどのような作用に対しても責任を負う。
【００２１】
コンテナ管理は、論理パーティション管理プログラムと関連してＷＬＭによって行われる。抑制機構は、もし論理パーティションが起伏平均期間をそのライセンスされた容量が超えるならば、又は超えた場合に論理パーティションにおいてキャッピングをオン及びオフするために、既に言及した同時係属出願であるJ. P. Kubala他の米国特許出願一連番号０９／４０７，３９１に記載された論理パーティション・クラスタ形成技術を利用する。論理パーティションにおける作業がアンチロック・ブレーキにかなり似たような気味悪い高い音を出して停止しないように、キャッピングは別の様式で適用及び除去される。
【００２２】
本発明では、相対的な論理パーティション重みは、キャッピングをインプリメントするために使用されるものである。論理パーティション重みの主要な目的は、ＣＰＵリソースに対する競合がある場合に論理パーティションのディスパッチを確立することである。キャッピングをオンにすることで、論理パーティションがそのようなパーティション重みによって生ずるリソースの部分を超えるのを防ぐ。
【００２３】
【発明の実施の形態】
図１は、本発明が適用される情報処理システム１００の模式図である。システム１００は、中央エレクトロニクス複合体（ＣＥＣ）又は物理的マシン１０２を有する。また、物理的マシン１０２は複数の中央処理装置（単にプロセッサ、ＣＰ、物理的ＣＰともいう）１０４を備えるもので、図１では模範的に４つのＣＰ１〜ＣＰ４が示されている。一方、図１には示されていないが、物理的マシン１０２は従来のコンピュータ・システムの他の構成要素も有するもので、該構成要素としてメモリ、直接アクセス記憶装置（ＤＡＳＤ）等の入出力（Ｉ／Ｏ）周辺機器、その他が含まれる。論理パーティション（ＬＰ）管理プログラム１０６は、物理的マシン１０２を論理パーティション（ＬＰ）１０８と呼ばれる複数の論理マシンに分割する。図１中、４つの論理パーティション（ＬＰ）１０８、すなわちＬＰ１〜ＬＰ４が模範的に示されている。各論理パーティション１０８で実行されるものはオペレーティング・システム（ＯＳ）１１０であり、仕事負荷管理プログラム（ＷＬＭ）と呼ばれる構成要素１１２と１つ以上のアプリケーション（ＡＰＰ）１１４とが含まれる。各オペレーティング・システム１１０は、システム・サービスを提供し、かつそこで実行されるアプリケーション１１４のためのリソースを管理する通常の機能を実行する。各ＷＬＭ１１２は、パーティション１０８内のリソースを種々の所定のサービス・クラス内の仕事負荷に対して割り当てることを管理する。
【００２４】
論理的観点から、各論理パーティション１０８は個々の物理的マシンとしてオペレーティング・システム１１０及びそこで実行されるアプリケーション１１４として見られる（一般に、ここで「マシン」とは特に指定されない限り物理的マシン１０２を意味する）。各論理パーティション１０８上のオペレーティング・システム１００は、個々のシステム・イメージを表すので、パーティションはここではシステム又はイメージとも言う。各論理パーティション１０８は、以下に説明するように、論理パーティション管理プログラム１０６によって特定されたマシンの物理的リソースの共有を有する。したがって、各論理パーティション１０８は、１つ以上の論理プロセッサ（個々に示してはいない）を有し、各論理プロセッサは物理的プロセッサ１０４の共有（もし該物理プロセッサがパーティション間で共有されているならば）又は物理的プロセッサ全体（もし物理プロセッサがそのパーティション専用であるならば）のいずれか一方に対応する。
【００２５】
本発明はある特定のプラットホームに限定されるものではないが、マシン１０２はＩＢＭのＳ／３９０サーバ又は後続のマシンを含むものであってもよい。一方、論理パーティション管理プログラム１０６はマシン１０２のリソース／システム管理プログラム（ＰＲ／ＳＭ）機能を有するものであってもよい。ＯＳ１１０はＩＢＭのＯＳ／３９０オペレーティング・システム又は後続のオペレーティング・システムを有するものであってもよい。
【００２６】
情報処理システム１００は、複数のパーティション１０８のうちの１つ又は別のパーティション又はマシンで実行可能なソフトウェア・アプリケーションであるライセンス契約管理プログラム１１６を有する。
【００２７】
ライセンス契約管理プログラム１１６はＷＬＭ１１２と通信して任意のパーティション１０８で利用可能な容量を理解する。ライセンスが管理されているソフトウェア・プロダクト（例えば、アプリケーション１１４）が１つのパーティション１０８で開始すると、ライセンス契約管理プログラム１１６はパーティションの容量（本発明によって管理されたように）に該プロダクトが既に開始されている同一マシン１０２上の任意の他の論理パーティション１０８の容量を加えたのと少なくとも同じだけの容量に対してプロダクトがライセンスされているかどうかを調べる。もしプロダクトがそのライセンスの範囲外であるならば、ライセンス契約管理プログラム１１６は、プログラムの開始を停止させるか例外レコードを書き込むかのいずれかを行う。ライセンス契約管理プログラム１１６は、ＷＬＭ１１２から変更容量の通知に対しても聞き耳を立てる。ライセンス契約管理プログラム１１６がそのような通知を受け取ると、実行中のプログラムがまだライセンスされた容量の範囲内であることを確認する。もしそうでなければ、ライセンス契約管理プログラム１１６は例外レコードを書き込む。
【００２８】
出願人J. P. Kubala他の同時係属出願である１９９９年９月２８日出願の米国特許出願一連番号０９／４０７，３９１（本明細書の発明の詳細な説明の一部として援用する）に記載されているように、ある動作モードにおいてＬＰ管理プログラム１０６はＬＰクラスタ（ＬＰＣ）又は単にクラスタとここで呼ぶグループとして論理パーティション１０８を管理する。１つのクラスタは、ある特定のマシン１０２上の全ての論理パーティション１０２、ある特定のマシン１０２の複数のパーティション１０８からなるサブセット、又は複数の異なるマシン１０２のパーティション１０８から構成されるものであってもよい。クラスタは、リソース競合存在下でその所定量に制限されるだろうが、競合がない状態では潜在的にそのようなリソースの追加量を使用する可能性があると思われる。
【００２９】
全体としてマシン・リソース共有をクラスタに割り当てることに加えて、ＬＰ管理プログラムはこの動作モードで各々のパーティションに割り当てられた論理パーティション重みに基づいてクラスタを構成している論理パーティション１０８間でリソースを割り当てることができる。重みの付けの一例として、４つの論理パーティション（ＬＰ１〜ＬＰ４）からなり、かつそれに対して４００ＭＩＰＳ（百万命令／秒）を使用可能とするＬＰクラスタを考える。クラスタ全体の重み１００に対してＬＰ１〜ＬＰ４がそれぞれ２０、３０、４０、及び１０の重みが割り当てられていると仮定する。この例では、もしＣＰＵ競合があるとすると、パーティションＬＰ１〜ＬＰ４は、４００ＭＩＰＳのクラスタ容量と同等の全容量に対して、それぞれ８０ＭＩＰＳ、１２０ＭＩＰＳ、１６０ＭＩＰＳ、及び４０ＭＩＰＳの容量で稼働することが可能となる。
【００３０】
既に指摘したように、パーティション重みそれ自体によって競合存在下で特定のパーティション１０８で利用可能なリソースのみが制限される。競合がない場合でもパーティションによるリソースの使用を制限するために、ＬＰ管理プログラム１０６はキャッピングとして知られている付加機能を有する。以下に説明するように、ＬＰ管理プログラムはキャッピングをパーティション１０８へ適用するもので、たとえ競合がない場合でもパーティション１０８のＣＰＵ使用量はパーティション重みによって定まる量に制限される。
【００３１】
図５は、個々のパーティション１０８を制御するために本発明の論理パーティション管理プログラム１０６によって使用された論理パーティション・パラメータ４００のいくつかを示す。これらのパラメータは、各パーティション１０８に対する一組のエントリ４０２からなり、論理パーティション重み４０４、後述する「疑似重み」４０６、同じく後述する「ソフト・キャップ」４０８、及びキャッピング・フラグ４１０を含む。論理パーティション重み４０４は、論理パーティション１０８がリソース競合存在下で資格があるマシン・リソース（この場合、ＣＰＵリソース）の相対量を特定する。ここで相対量とは、マシン１０２を構成する複数のパーティション１０８のパーティション重み全体に対するパーティション重み４０４の比に等しい。疑似重み４０６は、後述するように、本発明にもとづくキャッピング計算で使用される付加的な重みを定める。
【００３２】
ソフト・キャップ４０８は、パーティション１０８に対する最大容量を定める。ソフト・キャップ４０８の値は、論理パーティション１０８の定義の一部として定められる。ソフト・キャップ４０８の単位は、１時間あたり数百万の重みがかかっていないＣＰＵサービス単位（ＭＳＵ）である（ここでＣＰＵサービス単位は重みのかかっていないＣＰＵサービス単位のことを言う）。共有ＣＰを有し、はっきりとキャップされていないパーティション１０８に対してソフト・キャップ４０８を指定することができる。
【００３３】
ソフト・キャップ４０８は、マシン１０２上の物理的ＣＰ１０４の数に対するＭＰ因子を用いて計算されたＣＰＵサービス単位に準拠する。このことは、現在のパーティション１０８に対する論理ＣＰの数に準拠するＭＰ因子を用いるＷＬＭ１１２が行うＣＰＵサービス計算とは異なる。ＷＬＭ１１２はそれが計算するサービス単位をソフト・キャップに関連した判断のための物理的ＣＰ１０４の数に準拠したサービス単位に変換する。
【００３４】
キャッピング・フラグ４１０は、パーティション１０８についてキャッピングがオンであるかどうかを判断する。
【００３５】
本発明（以下に説明する疑似重みがない状態）でどのようにしてキャッピングが動作するかについての例として、４つの論理パーティション１０８（ＬＰ１〜ＬＰ４）を有し、かつ全ＣＰＵ容量が１０００ＭＩＰＳであるマシン１０２を検討する。各パーティション１０８は重みが２５であり、この重みによって競合存在下で各パーティションに対して２５０ＭＩＰＳが保証される。パーティションＬＰ１が４００ＭＩＰＳの容量をライセンスされたと仮定すると、もし利用可能であるならば（すなわち、他のパーティション１０８からの競合がなければ）ＬＰ１上の作業付加は４５０ＭＩＰＳを使用し、またパーティションＬＰ１はキャップが外される。もし４５０ＭＩＰＳがマシン１０２で利用可能であるならば（すなわち、他のパーティション１０８がそれ自身の重み全体を使用していない）、ＬＰ１は４００ＭＩＰＳのライセンス制限内でパーティションに対して平均使用を生ずるその重み相当量（２５０ＭＩＰＳ）での時間の２５％がキャップされなければならない。この２５％キャッピングを達成するためにこの例でＷＬＭ１１２が確立したキャッピング・パターンは、３０秒キャップした状態が続いた後、９０秒キャップが外された状態が続くパターンである。
【００３６】
図２は、ある期間にわたるＬＰ１によるＣＰＵ使用の結果として生じるキャッピング・パターン２００を示す。図に示すように、ＣＰＵ使用は、キャップされた区間２０２と、該区間２０２と交互に現れるキャップが外された区間２０４とから構成される。この例では、各々のキャップされた区間２０２は３０秒の長さであり、一方各々のキャップが外された区間２０４は９０秒の長さである。各キャップされた区間２０２では、ＬＰ１は２５０ＭＩＰＳのキャップされた容量（Ｃcapped）２０６で稼働し、一方各キャップが外された区間２０４ではＬＰ１は４５０ＭＩＰＳのキャップが外された容量（Ｃuncapped）で稼働する。この例では、キャップされた区間２０２が時間間隔全体の２５％を構成し、一方キャップが外された区間２０４は時間間隔全体の７５％を構成することから、時間間隔全体にわたる平均ＣＰＵ消費（Ｃavg）２１０は以下のように計算される。
【００３７】
【数１】
Ｃavg＝０．２５×Ｃcapped＋０．７５×Ｃuncapped ＝４００ＭＩＰＳ
【００３８】
図３は、特定のパーティション１０８について計算されたキャッピング・パターン（例えばパターン２００）を適用するためにＷＬＭ１２２が実行する手順２５０を示す。ＷＬＭは、キャッピング・フラグ２０４をセットしてキャッピングを開始するためにＬＰ管理プログラム１０６に命令を発することで、キャップがされている時間間隔２０２に対してキャッピングを適用する（ステップ２５２）。続いて、キャッピング・フラグ４１０をリセットしてキャッピングを終わらせるためにＬＰ管理プログラム１０６に対して命令を発することでキャップされていない時間間隔２０４に対してキャッピングを取り除く（ステップ２５４）。この手順２５０は、パターンに基づいてキャッピングが適用される限り繰り返される。
【００３９】
開示した実施形態では、パーティションに基づいた価格設定をサポートするという点でＷＬＭ１１２は２つの基本的な役割を持つ。
【００４０】
１． ＷＬＭ１１２は、必要に応じて潜在的ＣＰＵ容量がライセンス契約管理プログラム１１６に報告されるように、パーティション１０８で利用可能な潜在的ＣＰＵ容量を定期的に計算する。また、ＷＬＭ１１２はその容量が変化した場合にもライセンス契約管理プログラム１１６に知らせる。
【００４１】
２． ＷＬＭ１１２は、ソフト・キャップがパーティション１０８に関して設定又は変更されているかどうかを判断するために、ＬＰ管理プログラム１０６に対してポーリングを行う（対応のゼロ以外のソフト・キャップ・エントリ４０８によって示されるように）。ソフト・キャップがパーティション１０８に対して設定され、かつその４時間平均ＣＰＵ使用量がソフト・キャップを上回る場合、ＷＬＭ１１２はキャップ・パターンを計算し、パーティション１０８のキャッピングを開始する（以下に説明するように）。
【００４２】
潜在的なＣＰＵ容量の計算は、イメージの構成に依存するもので、以下の３通りの場合がある。
【００４３】
１． イメージは設定されたソフト・キャップを有する。復帰した潜在的容量の値はソフト・キャップ４０８の値である。
【００４４】
２． イメージは基本モードにあるか、もしくはキャップが外された論理パーティション１０８にあるかのいずれか一方である。復帰した潜在的容量の値は、個々のＣＰ速度、イメージ時間に利用可能なＣＰの数である。
【００４５】
３． イメージは、キャップ化論理パーティションである。復帰した潜在的容量の値は上記２の場合よりも小さく、またパーティションの現在の論理パーティション重みによって表されるＣＰＵ容量よりも小さい。
【００４６】
本発明が取り組む問題の１つは、従来の論理パーティション重みがマシン１０２上の他のパーティション１０８の重みに関連した意味のみを有することである（この議論の目的のために、ＬＰクラスタがマシン１０２全体から構成されると仮定する）。このことは、ＬＰ管理プログラム１０６からの付加機能をパーティションの重み及びマシン１０２上の他のパーティション１０８の重みに基づいて制限することなく、ソフト・キャップ値の範囲ＷＬＭ１１２が任意のパーティション１０８に対してサポートすることができることを意味する。もしソフト・キャップがパーティション重みが示す容量よりも少ない容量を示すならば、パーティション・ソフト・キャップを強化することはできない。
【００４７】
この問題の最も単純な例は、単一のパーティション１０８を持つマシン１０２である。そのパーティションの重みはマシンの容量の１００％を示すので、ソフト・キャップを使用してパーティションの容量を制限することはできない。この制限を受け入れることができないと考えられる。なぜなら、それによって論理パーティションに基づいた価格設定を用いることの複雑さが著しく増大するからである。ユーザが任意のパーティション重みを変更又は該ユーザのマシン１０２に容量を加えるたびに、パーティションの重みごとに表される容量が変化する。このことは、潜在的に、ＷＬＭ１１２及びＬＰ管理プログラム１０６によって強化することができないあるパーティション１０８に対してソフト・キャップを作り、それによってライセンス契約管理プログラム容量チェックが欠けたユーザのソフトウェア・プロダクトが得られる。
【００４８】
単一パーティション更新の場合におけるこの問題を定量化するために、単一論理パーティション１０８が４００ＭＩＰＳマシン１０２上に定められ、さらに４００ＭＩＰＳのライセンスされた容量を持つと仮定する。論理パーティション１０８は、共有プロセッサ及び１００の重みによって定められる。パーティション１０８は、加えられている将来の仕事負荷を予期する方向に定められる。この構成では、すべてが洗練されている。しかし、また将来に付加される新規の仕事負荷を予期してエンド・ユーザが自己のマシン１０２を５００ＭＩＰＳマシンに更新することを望むと仮定する。既存の論理パーティション１０８における仕事負荷は増加せず、そしてまたエンド・ユーザは増加したライセンス容量に対しての支払いを望まない。しかし、付加容量がマシン１０２に加えられるとすぐに、ＷＬＭは論理パーティションを４００ＭＩＰＳに管理することができない。なぜなら、論理パーティション１０８に対してキャップするものがないからである。キャッピングは、効率的にするために全ての重みの合計よりも低いものとなる論理パーティション重みを要求する。この場合、論理パーティションは、指定されたコンテナの大きさ４００ＭＩＰＳを実施することができないことから、例外モードであるとしてライセンス契約管理プログラム１１６に報告されなければならないと思われる。
【００４９】
この問題を解くために、ＷＬＭ１１２は現在のパーティション重みによって表される容量よりも低くパーティション１０８をキャプするための方法を必要とする。より詳しくは、ＷＬＭ１１２は、マシン１０２の残りの部分に関連した論理パーティションの重みが変化しないか（ＬＰクラスタには存在しない）、十分に変化することができないか（最小又は最大規格によって結合又はＬＰクラスタ合計によって）、又は共有ＣＰを使用している他の論理パーティションがないことから心配いらないかのいずれかである状況下で、キャッピング／重み付け計算における分母を調整することができる何かを必要とする。
【００５０】
この機能を提供するために、本発明はパーティション「疑似重み」又は価格設定管理プログラム調整重み（ＰＭＡＷ）と呼ばれるＬＰ管理プログラム１０６のための新規の制御を熟考する。各パーティション１０８は、ハードウェア命令の使用を介してＷＬＭ１１２を設定することができるそれ自身の疑似重み（図５のエントリ４０８）を有する。ある意味では、パーティションの疑似重量はそれをＬＰ管理プログラム１０６のように見せる。ダミー（又は疑似）パーティション１０８はこのパーティションのためにキャッピングがオンとなった時に存在する。それによって、パーティションの重みがマシンの重み全体よりも比率が小さくなる。この疑似重量は、ＷＬＭ１１２によってキャッピングされているパーティション１０８の優先順位を算定する場合のみ、論理パーティション重み全体に対する加算器として作用する。このことによって、ＷＬＭ１１２に対する最も高いフレキシビリティが可能となり、共有プロセッサを有する全てのＷＬＭ管理パーティション１０８がライセンスされた容量に管理されることができることを保証する。
【００５１】
どのようにＷＬＭ１１２が疑似重みを使用するかを理解するために、従来、どのようにＬＰ管理プログラム１０６がキャッピングを強制するかを見てみることが役立つ。図４は、かなり高いレベルでＬＰ管理プログラム１０６によって実行されたキャッピングの手順３００を示す。この図に関して、ＬＰ管理プログラム１０６は以下のように所定のパーティション１０８のためのキャッピングを強化する。
【００５２】
１． ＬＰ管理プログラム１０６は、全てのアクティブなパーティション１０８の重みの合計に対するパーティションの重みの比を計算する（ステップ３０２）。
【００５３】
２． ディスパッチ区間のあいだ、定期的に、ＬＰ管理プログラム１０６はこの比をパーティション１０８が使用したマシン容量の実際の割合と比較する（ステップ３０４）。
【００５４】
３． もしパーティションの実際の使用量がこの比を超えるならば（ステップ３０６）、パーティション１０８はディスパッチ区間の残りの部分でディスパッチされない（ステップ３０８）。
【００５５】
本発明によれば、ＷＬＭ１１２を現在の重みによって表される容量よりも少なくキャッピングさせるために、ＷＬＭ１１２がパーティション１０８をキャッピングした場合、ステップ１で述べた比の計算においてＬＰ管理プログラム１０６はパーティションの疑似重みをアクティブなパーティション１０８の重み全体に加える。例えば、重みが１００の単一パーティションを有する５００ＭＳＵマシンを考えた場合、もしユーザがこのパーティション１０８に対して４００ＭＳＵのソフト・キャップを設定するならば、ＷＬＭ１１２はパーティションの疑似重みを２５に設定する。設定された疑似重みを有するＷＬＭ１１２によってキャップされたパーティション１０８の重みによって表される容量を計算するための式は以下の通りである。
【００５６】
【数２】
Ｃcapped＝［パーティション重み／Σ（全アクティブ・パーティション重み＋疑似重み）×容量
即ち、Ｃcapped＝［Partition_weight／（ΣAll_active_partition_weights＋Phantom_weight）］×Capacity
と表す。
【００５７】
式中、Ｃcappedはパーティションのキャップ化容量、容量はキャップされていない場合のパーティション１０８によって潜在的に利用可能な全容量（ＭＳＵ又は他の適当な単位で）。
【００５８】
この例では、
【数３】
Ｃcapped＝１００／（１００＋２５）×５００ＭＳＵｓ＝４００ＭＳＵｓ，
【００５９】
式中、ＭＳＵは時間あたりの１００万サービス単位を示す。
【００６０】
ＷＬＭ１１２は、パーティションのソフト・キャップは、パーティションの現在の重みよりも少ない容量が少ない場合、パーティション１０８に対して疑似重みのみを設定する。そのような場合、ＷＬＭ１１２は以下の式（この式の導出について付録Ａを見よ）によってパーティションの疑似重みを計算する。
【００６１】
【数４】
疑似重み＝［（パーティション重み／ソフト・キャップ）ｘ容量］−Σ全パーティション重み
即ち、Phantom_weight＝［（Partition_weight／Soft_cap）×Capacity］−Σ All_partition_weights
と表す。
【００６２】
ＷＬＭ１１２は、１分間に１回、疑似重み計算に対する入力すべてをポーリングする。もしそれらの入力のいずれかが変化するならば、ＷＬＭ１１２はパーティションの疑似重みを再計算し、ＬＭ管理プログラム１０６に対して新規の疑似重みを供給する。
【００６３】
パーティション１０８がキャッピングをオンすることを必要とするわずかな時間を以下の式で計算することができる（この式の導出について付録Ｂを見よ）。
【００６４】
【数５】
Ｐ＝（Ｃuncapped−Ｃsoftcap）／（Ｃuncapped−Ｃcapped）
【００６５】
式中、Ｐはパーティション１０８がキャッピングを必要とする時間の端数、Ｃuncappedはキャップされていない時のパーティション１０８によって使用された平均容量、Ｃsoftcapはパーティション１０８に対するソフト・キャップの値、さらにＣcappedはキャップされている場合のパーティション１０８によって使用された平均容量である。もしパーティション１０８がキャッピングされたばかりであるなら、現在の重みによって表された容量をこの最新の値に対して使用してもよい。
【００６６】
論理パーティション１０８に対していつキャッピングをオン及びオフするかを判断するために、上記のように計算されたパーティション１０８をキャッピングすべき時間の割合を与える。ＷＬＭ１１２は、「キャップ・パターン」を生成する（図２）。好ましくは、ＷＬＭ１１２は、平均して１分間に１回よりも頻繁にパーティション１０８に対してキャッピングする論理パーティションの状態を変更すべきではない。すなわち、キャッピング状態は、１０分間に１０回よりも多く変更すべきではない。パターンは、２つの値によって表すことができる。すなわち、キャッピングをオンにすべき期間とキャッピングをオフにすべき期間である。以下の表１は、好ましい実施形態例でパーティションがキャップされるべき時間の割合全体に基づいてキャップがついている時間（Cap on time）及びキャップがはずされている時間（Cap off time）についての値を与える。値は、平均して１分間に１回を上回ることなくキャッピング状態での移行の数を保つために選択される。なお、表中、Ｐはパーティションがキャップされている時間の割合を示す。
【００６７】
【表１】
Percentage of time partition capped(P) Time cap on （秒） Time cap off （秒）
P ≦ 5% 0 常時
5% ＜ P ≦ 25% 30 90〜570
25% ＜ P ≦ 50% 60 60〜180
50% ＜ P ≦ 75% 60〜180 60
75% ＜ P ＜100% 90〜570 30
P = 100% 常時 0
【００６８】
ＷＬＭ１１２は、４時間を上回る平均ＣＰＵサービス率に基づいたソフト・キャップを実行する。パーティション１０８がキャップされるべきである時間の割合を計算するために、キャップされている間の平均ＣＰＵサービス率とキャップされていない間の平均ＣＰＵサービス率とが必要である。ここで図９を参照する。これらの平均を計算するために、ＷＬＭ１１２は項目６０２が４８個の配列を保持する（４時間のうちの５分間のインタバル数）。各項目は４つの値が含まれている。
【００６９】
６０４ パーティションがキャップされなかった場合の５分間のインタバル内で蓄積されたＣＰＵサービス。
【００７０】
６０６ パーティションがキャップされなかった５分間のインタバルにおける１０秒間のインタバル数。このインタバル数は０から３０までの範囲内であると考えられる。
【００７１】
６０８ パーティションがキャップされた場合の５分間のインタバル内で蓄積されたＣＰＵサービス。
【００７２】
６１０ パーティションがキャップされた５分間のインタバル内での１０秒間のインタバル数。このインタバル数は０から３０までの範囲内であると考えられる。
【００７３】
したがって、図６を最初に参照すると、５分毎にＷＬＭ１１２が手順５００を開始させる（図６乃至図８）。それによって、パーティション１０８がキャップされていなかった間の先行する５分間のインタバル中に蓄積されたＣＰＵサービス６０４（ステップ５０２）、パーティション１０８がキャップされていなかった間の先行する５分間のインタバルにおける１０秒間のインタバル数６０６（ステップ５０４）、パーティション１０８がキャップされていた間の先行する５分間のインタバル中に集積されたＣＰＵサービス６０８（ステップ５０６）、及びパーティションがキャップされていた間の先行する５分間のインタバルにおける１０秒間のインタバル数６１０（ステップ５０８）を決定する。これらの値６０４〜６１０が配列６００の次に利用可能な列６０２に格納される。
【００７４】
計算されたサービス・ユニットは、蓄積されたＣＰＵ時間のＬＰ管理プログラム１０６のビューに基づいている。したがって、１０秒毎にＷＬＭ１１２はＬＰ管理プログラム１０６に対して命令を送出する。この命令は各パーティションに対してデータ・テーブルを復帰させる。各パーティション１０８について、確定した論理ＣＰＵの各々に対してデータが復帰される。ＷＬＭ１１２は、ＷＬＭの特定のインスタンスが存在する論理パーティション１０８の各々の論理ＣＰＵに対する有効ディスパッチ時間を総計する。有効ディスパッチ時間の変更はＣＰＵサービス計算に対する入力として使用される。
【００７５】
パーティション１０８によって消費されたサービス・ユニットは、最初の５分間、第１の配列項目６０２に蓄積される。配列６００がひとたび満たされると、蓄積が折り返して最初の項目６０２に戻る。このようにして、アレイ６００は最後の４時間にわたって使用されたサービスを常に含む。
【００７６】
ここで図７を参照する。最後の５分間のインタバルに対して値６０４〜６１０を決定した後、ＷＬＭ１１２は、パーティションがキャップされていない場合の平均ＣＰＵサービス率（ステップ５１０）、キャップされている場合の平均ＣＰＵサービス率（ステップ５１２）、及び全平均ＣＰＵサービス率（ステップ５１４）を計算する。パーティションがキャップされていなかった場合の平均ＣＰＵサービス率（Ｃuncapped）を計算するために、ＷＬＭ１１２はパーティションがキャップされなかった場合（アレイにおける全ての値６１０の合計）の１０秒間のインタバル数で、キャップされている間に使用したサービス全体（配列６００における全ての値６０４の合計）を割る。全平均ＣＰＵサービス率を計算するために、ＷＬＭは全体の加算平均インタバルを通して使用した全サービス（配列６００における全ての値６０４及び６０６の合計）を加算平均インタバルにおける１０秒間のインタバル数（４時間加算平均インタバルで１４４０）で割る。システムが実際に４時間稼働するまで、データを有する配列項目のみが平均サービス率の計算に使用される。このことは、配列項目が４時間相当のデータを持っていない場合に計算される平均があまりにも低い値とならないようにするためである。
【００７７】
サービス・ユニット・データが蓄積される場合、計算されたサービスを調整して、ローカル・パーティションにある論理ＣＰの数に基づいたＭＰ（マルチプロセッシング）ファクタの代わりにマシン全体のＭＰファクタを反映させる。この調整は、マシン全体のＦＭファクタをパーティションのＭＰファクタに掛ける。マシン全体に対するＭＰファクタは、ＯＳ／３９０イメージに利用可能な潜在的ＣＰＵ容量の計算の一部として得られる。
【００７８】
次に、図８を参照する。それらの平均に基づいて、パーティション１０８に対するキャッピング状態で次の遷移が起こる。
【００７９】
１． もしパーティション１０８がキャップされていないで（ステップ５１６）、またその全平均ＣＰＵサービス率がソフト・キャップ（ステップ５１８）よりも高ければ、手順５００は図２に示すようなキャップ・パターンを計算し（ステップ５２０）、該パターンに基づいて図３に示す手順に従ってキャッピングを開始し（ステップ５２２）、さらに次の５分間のインタバルの終わりで繰り返されるように復帰する（ステップ５２４）。もし全平均ＣＰＵサービス率がソフト・キャップよりも高くなければ（ステップ５１８）、手順５００はキャップ・パターンを計算することなく、又はキャッピングを開始することなく復帰する（ステップ５２４）。
【００８０】
２． もしパーティション１０８がキャップされており（ステップ５１６）、またその非キャップ状態の平均ＣＰＵサービス率がソフト・キャップよりも低く（ステップ５２６）、手順５００は復帰（ステップ５２４）前にキャッピングを止める（ステップ５２８）。
【００８１】
３． もし上記条件のいずれでもなく、パーティション１０８がその時間の１００％キャップされており（ステップ５３０）、またその全ＣＰＵサービスがソフト・キャップよりも低ければ（ステップ５３２）、手順５００は同じく復帰（ステップ５２４）前にキャッピングを止める（ステップ５３４）。
【００８２】
４． もしパーティション１０８がキャップされており、また上記２つの条件のいずれでもなく、しかしキャップ状態の平均ＣＰＵサービス率６０８又はそのキャップされていない状態の平均サービス率６０４が閾値によって変化するならば（ステップ５３６）、手順５００は復帰（ステップ５２４）前にキャップ・パターンを再計算する（ステップ５３８）。
【００８３】
これらの条件のどれも起こらなければ、手順５００はキャッピングを停止することなく、又はキャッピング・パターンを再計算することなく、単に復帰する（ステップ５２４）。
【００８４】
もしパーティションがキャップされているならば、以下のイベントのためにキャップ・パターンも再計算される。
【００８５】
１． ＷＬＭ１１２はパーティションの重み４０４を変える（図５）。
【００８６】
２． ソフト・キャップ４０８が変化する（１分間に１回ポーリングされる）。
【００８７】
３． パーティションの現在の重み４０４及び疑似重み４０６によって表された容量が変化する（１分間に１回計算される）。
【００８８】
ＷＬＭ重み管理アルゴリズムは、パーティション１０８の動作を促進しようとする場合、パーティションのソフト・キャップ４０８よりも高くパーティション１０８の重み４０４を高めない。
【００８９】
１分間に１回、ＷＬＭ１１２がパーティション１０８に利用可能な全容量を計算する。もし値がその前の分から変化しているならば、ライセンス契約管理プログラム１１６に対して知らされる。論理パーティション・モードでは、上記したキャップ・パターン計算に対する入力としてＷＬＭ１１２もまた全マシン容量を計算する。
【００９０】
開示された実施形態例では、マシン１０２は基本モード（マシンがパーティション形成されていない）又は論理パーティション・モード（マシンが複数の論理パーティション１０８に分割されている）。基本モードでは、ＷＬＭ１１２はライセンス契約管理プログラム１１６に復帰できるように全マシン容量を計算する。全マシン容量を計算するために、最初にサービス・ユニット／秒／ＣＰＵが計算される。この値に対して利用可能なＣＰの総量を掛け、最終結果をＭＳＵに変換する。ここで、全マシン容量が作業の実行に対して潜在的に利用可能な全ＣＰに基づいているということである点に注意する。このことは、オンラインＣＰ及びオンラインでもたらされるＣＰが含まれる。
【００９１】
１． オンラインＣＰのカウント及びオンラインで変動するスタンドバイＣＰのカウント。これら２つのカウントの合計は利用可能なＣＰＵ全体のカウントである。
【００９２】
２． もし利用可能な全ＣＰＵカウントが現在のオンラインＣＰの数よりも多ければ、ＣＰＵ調整ファクタは利用可能な全ＣＰＵカウントに基づいて計算される。このＣＰＵ調整ファクタは、現在のＭＰファクタによって現在のＣＰＵ調整ファクタを乗じ、さらにそれを全ＣＰＵカウントのＭＰファクタによって割ることで計算される。
【００９３】
なお、ＣＰＵサービス・ユニットは、所定のプロセッサの速度に対して正規化されたプロセッサ容量の共通ユニットを表す。ＣＰＵ時間と異なり、ＣＰＵサービス・ユニットは、物理的プロセッサ速度に関係なくほぼ同一プロセッサ容量を示す。ＣＰＵ調整ファクタは、ＣＰＵ時間をＣＰＵサービス・ユニットに変換するための正規化値である。
【００９４】
３． １６，０００，０００をＣＰＵ調整ファクタによって割ることでＣＰＵ調整ファクタをサービス・ユニット／秒／ＣＰＵに変換する（これはサービス・ユニット／秒を計算するための一般式である。
【００９５】
４． １秒あたりの全マシン・サービス・ユニットを得るために、サービス・ユニット／秒／ＣＰＵを利用可能なＣＰＵ全体のカウントで乗じる。この結果をさらに３６００秒／時間で乗じ、続いて１，０００，０００で割ることで、全マシンＭＳＵ容量を得る。
【００９６】
論理パーティション・モードでは、全マシンＭＳＵ容量及びパーティションの潜在的ＭＳＵ容量の値が必要である。以下は全マシン容量を計算するためのステップである。
【００９７】
１． オンラインＣＰのカウントとオンラインで変動するＣＰのカウントとを得る。利用可能なＣＰ全体を得るために、構成及びスタンドバイＣＰのカウントを一緒に加える。
【００９８】
２． 物理的ＭＰファクタを得る。
【００９９】
３． 論理ＣＰＵ調整ファクタを物理的ＭＰファクタに対する論理ＭＰファクタの比によって乗じることで、物理的ＣＰＵ調整ファクタを計算する。
【０１００】
４． ＣＰＵサービス・ユニット／秒／ＣＰＵを計算するために、１６，０００，０００を物理的ＣＰＵ調整因子によって割る（このことはＣＰＵ調整ファクタからサービス・ユニット／秒への一般的変換法である）。ＣＰＵサービス・ユニット／秒の値を保存する。
【０１０１】
５． マシン容量を計算するために、サービス・ユニット／秒／ＣＰＵの値を上記計算した物理的ＣＰＵの数で乗ずる。得られたサービス・ユニット／秒の値を３６００秒／時間で乗じ、続いて１，０００，０００で割ることでＭＳＵに変換する。
【０１０２】
パーティションの潜在的に利用可能な容量を計算するために、ＷＬＭ１１２を以下のようにして行う。
【０１０３】
１． ソフト・キャップを有する論理パーティション：
パーティションの容量はソフト・キャップに等しい。
【０１０４】
２． ソフト・キャップ無しで、かつ明確にキャップされていない論理パーティション：
構成論理ＣＰＵのカウントをスタンドバイ論理ＣＰＵのカウントに加えることによってパーティションで利用可能な論理ＣＰＵの数を計算する。上記計算したサービス・ユニット／秒をこのパーティションで利用可能なＰＵの数で乗ずる。この結果を３６００秒／時間で乗じ、続いて１，０００，０００で割ることでＭＳＵに変換する。最大は１となる
【０１０５】
３． 明確にキャップされた論理パーティション。
パーティションの容量は上記２の計算のもの及びパーティションの重みによって表された容量よりも小さい。
【０１０６】
以上、特定の実施形態例を示し、かつそれを説明したが、特許請求の範囲によって限定される範囲内において種々の変更が可能であることを当業者は容易に理解するであろう。
【０１０７】
付録１：疑似重み式の導出
【０１０８】
疑似重みを計算する式を導き出すために、パーティションの重みが表す容量を計算するための式から開始する。我々は、パーティションの重みによって表されるようようがソフト・キャップと等しくなることを望む。
【０１０９】
【数６】
ソフト・キャップ＝［パーティション重み／（Σ全パーティション重み＋疑似重み）］×容量
即ち、Soft_cap＝［Partition_weight／（ΣAll_partition_weights＋Phantom_weight）］×Capacity
と表す。
【０１１０】
疑似重みについて解決する。
【０１１１】
【数７】
Σ全パーティション重み＋疑似重み＝（パーティション重み／ソフト・キャップ）Ｘ容量
即ち、ΣAll_partition_weights＋Phantom_weight＝(Partition_weight／Soft_cap）×Capacity
と表す。
【０１１２】
【数８】
疑似重み＝（パーティション重み／ソフト・キャップ）×容量−Σ全パーティション重み
即ち、Phantom_weight＝（Partition_weight／Soft_cap）×Capacity−ΣAll_partition_weights
と表す。
【０１１３】
付録Ｂ：キャップ割合を求める式の導出
【０１１４】
パーティションがキャップされなければならない時間の割合を計算するための式を導き出すために、時間の割合Ｐでキャップされているパーティションによって使用された平均ＣＰＵ容量を計算するための式から開始する。
【０１１５】
【数９】
Ｃavg＝Ｐ×Ｃcapped＋（１−Ｐ）×Ｃuncapped
【０１１６】
Ｐについて解決する。
【０１１７】
【数１０】
Ｃavg＝Ｐ（Ｃcapped−Ｃuncapped）＋Ｃuncapped
【０１１８】
【数１１】
Ｃavg−Ｃuncapped ＝Ｐ（Ｃcapped −Ｃuncapped）
【０１１９】
【数１２】
Ｐ＝（Ｃuncapped−Ｃavg）／（Ｃuncapped−Ｃcapped）
【０１２０】
平均ＣＰＵ容量がソフト・キャップに等しい時のＰを計算したいため、ＣavgをＣsoftcapで置き換える。
【０１２１】
【数１３】
Ｐ＝（Ｃuncapped−Ｃsoftcap）／（Ｃuncapped−Ｃcapped）
【０１２２】
まとめとして、本発明の構成に関して以下の事項を開示する。
（１）論理パーティションにある所定のシステム・リソースの実消費を決定するステップと、
前記実消費を、前記論理パーティションにある前記リソースに対する所定の許容消費と比較するステップと、
前記実消費が前記許容消費を上回る場合、前記リソースの前記実消費を前記許容消費まで減少させるステップと、
を有することを特徴とする方法。
（２）前記所定のシステム・リソースはプロセッサ・リソースであることを特徴とする上記（１）に記載の方法。
（３）複数の時間間隔にわたって前記消費を加算平均することで前記実消費を決定することを特徴とする上記（１）に記載の方法。
（４）物理的マシンが１つ以上の論理パーティションを有し、かつ前記論理パーティションの各々がマシン・リソースの所定の一部分を割り当てられている情報処理システムで、容量制限を強化するための方法であって、
前記１つ以上の論理パーティションによる前記リソースの最大許容容量を特定するステップと、
前記論理パーティションによる前記リソースの実消費を測定するステップと、
前記実消費と前記最大許容消費とを比較して前記実消費が前記最大許容消費を上回るかを決定するステップと、
もし前記実消費が前記最大許容消費を上回るならば、前記リソースの前記実消費を前記最大許容消費まで減少させるステップと、
を有することを特徴とする方法。
（５）前記論理パーティションは複数の論理パーティションからなる群から選択される１つであり、前記最大許容消費は前記複数の論理パーティションからなる群に利用可能なリソースの割合を特定することを特徴とする上記（４）に記載の方法。
（６）前記複数の論理パーティションからなる群は、前記物理的マシン上にある全ての論理パーティションから構成されることを特徴とする上記（４）に記載の方法。
（７）前記複数の論理パーティションからなる群に含まれる論理パーティションの各々は重みが割り当てられており、前記割合は前記群の前記複数のパーティションの重みの合計に対する前記論理パーティションの重みの比として定められていることを特徴とする上記（５）に記載の方法。
（８）前記論理パーティションは疑似重みも割り当てられており、該疑似重みは前記比を決定するステップで前記論理パーティションの重みの前記合計に加えられることを特徴とする上記（７）に記載の方法。
（９）前記所定のシステム・リソースはプロセッサ・リソースであることを特徴とする上記（４）に記載の方法。
（１０）前記実消費は所定の時間間隔における前記消費の回転平均として決定されることを特徴とする上記（４）に記載の方法。
（１１）マシンによって読み取り可能なプログラム記憶装置であって、上記（１）にもとづく方法のステップを実行するために前記マシンによって実行可能な複数の命令からなるプログラムを実質的に包含することを特徴とするプログラム記憶装置。
（１２）物理的マシンが１つ以上の論理パーティションを有し、かつ前記論理パーティションの各々がマシン・リソースの所定の一部分を割り当てられている情報処理システムで、容量制限を強化するための装置であって、
前記１つ以上の論理パーティションによる前記リソースの最大許容容量を特定する手段と、
前記論理パーティションによる前記リソースの実消費を測定する手段と、
前記実消費と前記最大許容消費とを比較して前記実消費が前記最大許容消費を上回るかを決定する手段と、
もし前記実消費が前記最大許容消費を上回るならば、前記リソースの前記実消費を前記最大許容消費まで減少させる手段と、
を有することを特徴とする装置。
（１３）前記論理パーティションは複数の論理パーティションからなる群から選択される１つであり、前記最大許容消費は前記複数の論理パーティションからなる群に利用可能なリソースの割合として特定することを特徴とする上記（１２）に記載の装置。
（１４）前記複数の論理パーティションからなる群に含まれる論理パーティションの各々は重みが割り当てられており、前記割合は前記群の前記複数のパーティションの重みの合計に対する前記論理パーティションの重みの比として定められていることを特徴とする上記（１３）に記載の装置。
（１５）前記論理パーティションは疑似重みも割り当てられており、該疑似重みは前記比を決定するステップで前記論理パーティションの重みの前記合計に加えられることを特徴とする上記（１４）に記載の方法。
【図面の簡単な説明】
【図１】本発明が適用される情報処理システムの概略的構成を説明するための模式図である。
【図２】本発明にもとづく方法及び装置に適用される典型的なキャッピング・パターンを説明するための図である。
【図３】キャッピング・パターンを適用するために仕事負荷管理プログラムによって実行される手順を説明するためのフローチャートである。
【図４】本発明の論理パーティション管理プログラムによて実行されるキャッピング手順を説明するためのフローチャートである。
【図５】本発明の論理パーティション管理プログラムによって使用される論理パーティション・パラメータを示すブロック図である。
【図６】キャッピングを適用すべきかどうかを判断するために本発明の仕事負荷管理プログラムによって実行される手順を説明するためのフローチャートである。
【図７】キャッピングを適用すべきかどうかを判断するために本発明の仕事負荷管理プログラムによって実行される手順を説明するためのフローチャートである。
【図８】キャッピングを適用すべきかどうかを判断するために本発明の仕事負荷管理プログラムによって実行される手順を説明するためのフローチャートである。
【図９】図６、図７、及び図８のフローチャートに示された手順を実行するために仕事負荷管理プログラムによって使用される配列を説明するための配列表である。
【符号の説明】
１０２ マシン
１０４ 物理的ＣＰ（物理的プロセッサ、中央処理装置）
１０６ 論理パーティション（ＬＰ）管理プログラム
１０８ 論理パーティション（ＬＰ１〜ＬＰ４）
１１０ オペレーティング・システム（ＯＳ）
１１２ 仕事負荷管理プログラム（ＷＬＭ）
１１４ アプリケーション
１１６ ライセンス契約管理プログラム
４００ 論理パーティション・パラメータ
４０２ エントリ
４０４ 論理パーティション重み
４０６ 疑似重み
４０８ ソフト・キャップ
４１０ キャッピング・フラグ
【発明の属する技術分野】
論理的に分割された情報処理システムにおける容量制限を強化するための方法及び装置、特にソフトウェア・プログラム・ライセンス契約によって課された容量制限にもとづいたそのような容量制限を強化するための方法及び装置に関する。
【０００２】
【従来の技術】
上記のように、この発明は、プログラム・ライセンス契約によって課されたような容量制限を強化することに関する。本発明で扱う問題についての議論の前提として、論理的に分割されたシステムとリソース及び作業負荷管理に関する既存の方法とについて順次簡単に説明する。
【０００３】
論理的パーティション形成は、現在のＩＢＭ製Ｓ／３９０コンピュータ・ハードウェア・プラットホームの先行モデルに対して作られたコンセプトである。今日、多くのＳ／３９０ハードウェア・マシンが論理的パーティション形成（ＬＰＡＲ）モードとして知られるモードで動作する。この際、マシンの物理的リソースが分割されて論理パーティションと呼ばれる複数の論理マシンが形成される。特に、各論理パーティションは、実際の物理的マシンと動作の点で類似している論理マシンとしてパーティションで実行されるプログラミングのように見える。
【０００４】
論理的な分割によって、中央処理装置複合体（ＣＰＣ）とも呼ばれる１つの物理的な中央エレクトロニクス複合体（ＣＥＣ）の中に複数のシステム・イメージを設定することが可能となる。すなわち、各論理パーティションを個別にリセットしたり、各論理パーティション毎に異なったオペレーティング・システムによって初期化したり、異なる入出力（Ｉ／Ｏ）装置を用いて異なるソフトウェア・プログラムによって動作させたりすることができる。論理的パーティション形成は、今日一般的に使用されている。なぜなら、それによって、使用中の論理パーティションの数及び各パーティションに割り当てられた物理的システム・リソースの量を変化させる柔軟性がそのユーザに対して与えられ、ある場合においては、一方で中央処理装置複合体全体が動作を続ける。
【０００５】
論理パーティション形成コンピュータ・システムが従来技術においてよく知られており、さらに米国特許第４，５６４，９０３号（Guyette他）、米国特許第４，８４３，５４１号（Bean他）、及び米国特許第５，５６４，０４０号（Kubala）に開示されている。本明細書ではこれらの特許文献を発明の詳細な説明の一部をなすものとして援用する。論理的パーティション形成システムの市販の実施形態として、例えば本明細書において援用されるＩＢＭの出版物であるProcessor Resource/Systems Manager Planning Guide, GA22-7236-06（２０００年６月発行）に記載され、かつ特徴付けられたProcessor Resource/Systems Manager（登録商標）（ＰＲ／ＳＭ（登録商標））が挙げられる。
【０００６】
作業負荷管理は、オペレーティング・システムによって管理される作業の単位（プロセス、スレッド等）が所定の目標をどれぐらい十分に満たしているかにもとづいてシステム・リソースが提供されるクラス（サービス・クラス又は目標クラス）の中に組織化されるコンセプトである。もし再割り当てによって生ずるレシーバ・クラスのパフォーマンスの向上がドナー・クラスのパフォーマンスの低下を上回る、すなわち所定のパフォーマンス基準によって定められるような正味の効果がパフォーマンスにあるとするならば、リソースはドナー・クラスからレシーバ・クラスに再度割り当てられる。この種の作業負荷管理は、リソースの割り当てが、リソースが再割り当てされる作業単位上のその効果のみならず、リソースが取られる作業単位に対するその効果によっても決定される点で、ほとんどのオペレーティング・システムで実行された従来のリソース管理とは異なるものである。
【０００７】
この一般的形式の作業負荷管理は、以下に示すような一般に所有された特許、係属中の特許出願、及び特許以外の出版物に開示されており、これらの文献を本明細書では援用する。
【０００８】
「マルチ処理システムにおけるトランザクション・クラス応答時間目標を達成するための作業負荷管理プログラム」と題されたD.F. Ferguson他の米国特許第５，５０４，８９４号、
「２つ以上の異なる処理目標にもとづいてデータ処理システム作業負荷を管理するための装置及び方法と題されたJ. D. Aman他の米国特許第５，４７３，７７３号、
「クライアント／サーバ・データ処理システムにおけるクライアント・パフォーマンス目標にもとづくサーバ仕事負荷を管理するための装置及び方法」と題されたC. K. Eilert他の米国特許第５，５３７，５４２号、
「基準が目標指向であり、容量情報が入手可能である資格のあるクラスへ分類することに基づいた仕事要求を割り当てるシステム」と題されたJ. D. Aman他の米国特許第５，６０３，０２９号、
「複数の異なる処理目標形式に基づく分散データ処理システム仕事負荷を管理するための装置及び方法」と題されたC. K. Eilert他の１９９５年２月３日出願の米国特許出願一連番号０８／３８３，１６８号、
「マルチシステム・リソース・キャッピング」と題されたC. K. Eilert他の１９９５年２月３日出願の米国特許出願一連番号０８／３８３，０４２、
「マルチサーバ・シスプレックス環境におけるセッション要求割り当てのための装置及び付随する方法」と題されたJ. D. Aman他の１９９５年７月７日出願の米国特許出願一連番号０８／４８８，３７４、
ＭＳＶプラニング：仕事負荷管理、ＩＢＭ出版物ＧＣ２８−１７６１−００（１９９６年）、及び
ＭＳＶプログラミング：仕事負荷管理サービス、ＩＢＭ出版物ＧＣ２８−１７７３−００（１９９６年）。
【０００９】
これらの特許及び特許出願の中で、米国特許第５，５０４，８９４号及び第５，４７３，７７３号は基本的な仕事負荷管理システムを開示、米国特許第５，５３７，５４２号はクライアント／サーバ・システムに対する米国特許第５，４７３，７７３号の仕事負荷管理システムの特定用途を開示、米国特許出願一連番号０８／３８３，１６８及び０８／３８３，０４２は多重相互接続したシステムに対する米国特許第５，４７３，７７３号の仕事負荷管理システムの特定用途を開示、米国特許第５，６０３，０２９号はマルチシステム複合体（シスプレックス）における仕事要求の割り当てに関し、さらに米国特許出願一連番号０８／４８８，３７４はそのような複合体におけるセッション要求の割り当てに関する。特許とは関係ない２つの出版物は、ＩＢＭ（登録商標）のＯＳ／３９０（商標）（旧ＭＶＳ（登録商標））オペレーティング・システムにおける作業管理のインプリメンテーションについて説明している。
【００１０】
論理パーティションをひとまとめにする最近の技術は、論理パーティション管理及び仕事負荷管理の複数の態様を組み合わせるものである。本明細書で援用する同時係属出願である出願人J. P. Kubala他の米国特許出願一連番号０９／４０７，３９１（１９９９年９月２８日出願）は、動作の１つのモードにおいてＬＰ管理プログラム１０６が論理パーティション１８０をＬＰクラスタ（ＬＰＣ）又は単にクラスタとここでは呼ぶ群として管理する。クラスタは、特定のマシン１０２上の論理パーティション１８０の全て、特定のマシン１０２上のパーティション１０８のサブセット、又は異なるマシン１０２のパーティション１０８からなるものであってもよい。ＬＰ管理プログラム１０６は、全体として所定量のマシン・リソース（本発明の場合、共用ＣＰＵ容量）をクラスタに割り当ててもよい。クラスタはリソース競合が存在するとその所定量に制限されるが、競合が存在しない場合は潜在的にそのリソースをさらに多く使うことができる。
【００１１】
さらに、全体としてクラスタに対してマシン・リソースの共有を割り当てることに加えて、この動作モードでＬＰ管理プログラム１０６は、それぞれのパーティションに割り当てられた論理パーティションの重みに基づいてクラスタを構成している論理パーティション１０８間でリソースを割り当てることができる。この重みの一例として、４つの論理パーティション（ＬＰ１〜ＬＰ４）からなり、かつ４００ＭＩＰＳ（毎秒４００万命令）全ＣＰＵ容量を利用可能とするＬＰクラスタを考慮する。ＬＰ１〜Ｌ４は、クラスタ全体の重みを１００とすると、それぞれ２０、３０、４０、及び１０の重みが割り当てられていと想定する。この例では、もしＣＰＵ競合があるならば、パーティションＬＰ１〜ＬＰ４は、クラスタ容量４００ＭＩＰＳと同等の容量全体に対して、それぞれ８０ＭＩＰＳ、１２０ＭＩＰＳ、１６０ＭＩＰＳ、及び４０ＭＩＰＳの容量で動作することが可能となる。このような背景によって、本発明によって扱われた問題を論ずることができる。第１に、それはＳ／３９０等のサーバ・プラットホーム用のソフトウェアがライセンスされる方法に関係している。今日、Ｓ／３９０ソフトウェア、すなわちＩＢＭソフトウェア及びベンダ・ソフトウェアの両方の多くが該ソフトウェアが実行される物理的マシンの大きさに基づいて価格が設定されている。１つの中央処理装置（ＣＰＵ）を持つマシン（ここで「マシン」と呼ぶものは物理的マシン）は、１０個のＣＰＵを有するマシン上で実行される同一アプリケーションよりも低価格である。価格は、アプリケーションによって実際に行われる仕事量とは無関係である。
【００１２】
この価格設定スキームは、エンド・ユーザに対してソフトウェアの経費をより低くするために、最適な構成よりも少なく構築させることができる。例えば、もし新しいソフトウェア・プロダクトによって小規模の実験を開始したいならば、ユーザはソフトウェアの価格を低く抑えておくために、既存の大型のマシンで実行される代わりに、小さなマシンで新しいプロダクトを実行させる。このことは、もう１つのマシンを扱うことについての追加の管理を必要とし、既に言及した論理パーティションのクラスタ形成技術を利用するインストレーションを許さない。これらの問題は、Ｓ／３９０マシンの大きさが多くのカスタマ作業負荷よりも早く成長しているという事実によって悪化されている。
【００１３】
それを多少異なったかたちで述べるために、今日、Ｓ／３９０プラットホーム・ソフトウェアは、全マシンに対して最もよくライセンスされる。ソフトウェアが実行されるマシンの全容量（一般に、１秒間あたり数百万の命令、又はＭＩＰＳとして発現される）に基づいているほとんどのソフトウェアの価格設定によって、マシンの容量増加によってユーザのソフトウェアライセンス費用が跳ね上がる。もし、所定のプログラム製品がマシンの容量全体で使用されるならば、エンド・ユーザ又はベンダに対して、これは必ずしも良くない事柄又はモデルではない。しかし、もしプログラム製品がマシンの一部で使用されることを意図しているならば、論理パーティション内で、マシンの容量全体に対してその製品をライセンスすることは高価な仕事である。
【００１４】
Ｓ／３９０プラットホームの長所の１つは、ハードウェア・リソースを効率的に利用するために、多数の論理パーティションで多数かつ多様な作業負荷を実行する能力である。Ｓ／３９０上で新しい作業負荷（例えば、ＵＮＩＸ(R)系アプリケーション及びＷｅｂサーバ）を動かす試みは、既存のアプリケーションに並行し、かつ既にＳ／３９０に備わっているデータベースと協同して、それらの新しい作業負荷を既存のマシンに負荷することが可能であることが求められる。しかし、マシンに基づいたソフトウェア価格設定では、それらの作業負荷に対するＳ／３９０ワールドへのエントリ・コストは、代わりのプラットホームと競合するコストではない。
【００１５】
【発明が解決しようとする課題】
本発明は従来の問題点を解決し、論理的に分割された情報処理システムにおける容量制限を強化するための方法及び装置、特にソフトウェア・プログラム・ライセンス契約によって課された容量制限にもとづいたそのような容量制限を強化するための方法及び装置を提供することを目的とする。
【００１６】
【課題を解決するための手段】
本発明は、物理的マシンが複数の論理パーティションに分割され、論理パーティション管理プログラムによってプロセッサ・リソースの所定部分が各パーティションに割り当てられている情報処理システムにおけるソフトウェア・ライセンス契約管理プログラムによって課された容量制限等の容量制限を強化するための方法及び装置を検討する。各論理パーティションに対してプロセッサ・リソース制限を与えることができる。ソフトウェア・ライセンス契約管理プログラムは、各論理パーティションで実行されているプログラムが該パーティションの少なくとも容量制限でライセンスされていることを確かめる。パーティションでも実行されている作業負荷管理プログラムは、プロセッサ・リソースの実際の消費を所定の平均間隔で測定し、それを最大許容消費と比較する。もし実際の消費が最大許容消費を超えると、作業負荷管理プログラムはキャッピング・パターンを計算し、論理パーティション管理プログラムと相互作用し、計算されたキャッピング・パターンに基づくパーティションに基づいて、プロセッサ・リソースの実際の消費をキャップする。さらにキャッピングのフレキシビリティを与えるために、論理パーティション管理プログラムが全パーティション重みに加算する見かけの重みがパーティションに対して割り当てられ、パーティションがキャッピングを目的としたプロセッサ・リソースの許容共有レベルを超えたかどうかが判断される。したがって、論理パーティションは、マシン全体の容量よりも少ない強化された処理能力（それにもとづいてソフトウェアの価格が設定される）によってライセンスされたプログラムのための「コンテナ」となる。
【００１７】
マシンに基づいたスキームよりもむしろ論理パーティションに基づいた価格設定スキームによって、Ｓ／３９０上での仕事負荷に対するソフトウェアの初期投入コストが反映させるべきものはマシン全体ではなく該マシンの能力のサブセットのみである。このことによって、特に論理パーティション・クラスタが伝えることができる作業負荷平衡及び管理の利益を考慮する場合に、最小のコストでＳ／３９０マシンに対して作業負荷を加えることが可能となる。正味の結果によって、さもなければ未使用の容量をかなり有する外部ボックス上にある作業負荷を以前よりはより多くの総購入容量を持つＳ／３９０マシンに負荷することが今や可能となる。
【００１８】
本発明は、ＯＳ／３９０の作業負荷管理プログラム（ＷＬＭ）コンポーネントの能力を利用し、論理パーティションのためのＣＰＵリソースの消費をモニタする。ＷＬＭは、論理パーティションに対するいくらかの所定容量制限に対して実際のＣＰＵリソース消費を比較する。論理パーティションがその容量制限を越える場合、ＷＬＭは論理パーティションをその容量制限まで削減する。
【００１９】
好ましくは、論理パーティションの実際のモニタリングによって、ライセンスされた容量を超えて仕事負荷のピークを生じさせることが可能となる。このことは、適当な時間間隔を超えてなだらかに起伏した平均利用率を計算することによって好ましくは行われる。例えば、４時間間隔は、一時的な仕事負荷スパイクの間での容量要求を提供するのには長く、一方でシフト変化を超えて「ゲーミング」を防ぐには短すぎる。したがって、ソフトウェアは瞬間的なピーク容量よりもむしろ平均化されたピーク容量に対してライセンスされる。
【００２０】
ＷＬＭは、論理パーティションにおいてＣＰＵリソースの全消費をモニタするが、個々のプログラム・プロダクトによるリソースの使用についてはモニタしない。したがって、論理パーティション内で実行されるオペレーション・システム（例えば、ＯＳ／３９０）はライセンス及び管理された容量の一定量に対する「コンテナ」となる。ライセンスされたプログラムはそのサイズのコンテナ（少なくとも）のためにライセンスされ、さらにＷＬＭは該コンテナ・サイズが保たれるのを保証する。例えば、カスタマは各ソフトウェア・アプリケーション用にプロセッサ容量のいくらかに対するライセンス証（すなわち、証明機関によってデジタル署名された書類を買っても良い。好ましくは、ライセンス契約管理プログラムとしてここで言及される新規アプリケーションは、ＷＬＭ及びライセンスされたプログラムと通信し、何を実行させて何を実行させないかを決定する。ライセンス契約管理プログラムは、例外だと見なさなければならないようなどのような作用に対しても責任を負う。
【００２１】
コンテナ管理は、論理パーティション管理プログラムと関連してＷＬＭによって行われる。抑制機構は、もし論理パーティションが起伏平均期間をそのライセンスされた容量が超えるならば、又は超えた場合に論理パーティションにおいてキャッピングをオン及びオフするために、既に言及した同時係属出願であるJ. P. Kubala他の米国特許出願一連番号０９／４０７，３９１に記載された論理パーティション・クラスタ形成技術を利用する。論理パーティションにおける作業がアンチロック・ブレーキにかなり似たような気味悪い高い音を出して停止しないように、キャッピングは別の様式で適用及び除去される。
【００２２】
本発明では、相対的な論理パーティション重みは、キャッピングをインプリメントするために使用されるものである。論理パーティション重みの主要な目的は、ＣＰＵリソースに対する競合がある場合に論理パーティションのディスパッチを確立することである。キャッピングをオンにすることで、論理パーティションがそのようなパーティション重みによって生ずるリソースの部分を超えるのを防ぐ。
【００２３】
【発明の実施の形態】
図１は、本発明が適用される情報処理システム１００の模式図である。システム１００は、中央エレクトロニクス複合体（ＣＥＣ）又は物理的マシン１０２を有する。また、物理的マシン１０２は複数の中央処理装置（単にプロセッサ、ＣＰ、物理的ＣＰともいう）１０４を備えるもので、図１では模範的に４つのＣＰ１〜ＣＰ４が示されている。一方、図１には示されていないが、物理的マシン１０２は従来のコンピュータ・システムの他の構成要素も有するもので、該構成要素としてメモリ、直接アクセス記憶装置（ＤＡＳＤ）等の入出力（Ｉ／Ｏ）周辺機器、その他が含まれる。論理パーティション（ＬＰ）管理プログラム１０６は、物理的マシン１０２を論理パーティション（ＬＰ）１０８と呼ばれる複数の論理マシンに分割する。図１中、４つの論理パーティション（ＬＰ）１０８、すなわちＬＰ１〜ＬＰ４が模範的に示されている。各論理パーティション１０８で実行されるものはオペレーティング・システム（ＯＳ）１１０であり、仕事負荷管理プログラム（ＷＬＭ）と呼ばれる構成要素１１２と１つ以上のアプリケーション（ＡＰＰ）１１４とが含まれる。各オペレーティング・システム１１０は、システム・サービスを提供し、かつそこで実行されるアプリケーション１１４のためのリソースを管理する通常の機能を実行する。各ＷＬＭ１１２は、パーティション１０８内のリソースを種々の所定のサービス・クラス内の仕事負荷に対して割り当てることを管理する。
【００２４】
論理的観点から、各論理パーティション１０８は個々の物理的マシンとしてオペレーティング・システム１１０及びそこで実行されるアプリケーション１１４として見られる（一般に、ここで「マシン」とは特に指定されない限り物理的マシン１０２を意味する）。各論理パーティション１０８上のオペレーティング・システム１００は、個々のシステム・イメージを表すので、パーティションはここではシステム又はイメージとも言う。各論理パーティション１０８は、以下に説明するように、論理パーティション管理プログラム１０６によって特定されたマシンの物理的リソースの共有を有する。したがって、各論理パーティション１０８は、１つ以上の論理プロセッサ（個々に示してはいない）を有し、各論理プロセッサは物理的プロセッサ１０４の共有（もし該物理プロセッサがパーティション間で共有されているならば）又は物理的プロセッサ全体（もし物理プロセッサがそのパーティション専用であるならば）のいずれか一方に対応する。
【００２５】
本発明はある特定のプラットホームに限定されるものではないが、マシン１０２はＩＢＭのＳ／３９０サーバ又は後続のマシンを含むものであってもよい。一方、論理パーティション管理プログラム１０６はマシン１０２のリソース／システム管理プログラム（ＰＲ／ＳＭ）機能を有するものであってもよい。ＯＳ１１０はＩＢＭのＯＳ／３９０オペレーティング・システム又は後続のオペレーティング・システムを有するものであってもよい。
【００２６】
情報処理システム１００は、複数のパーティション１０８のうちの１つ又は別のパーティション又はマシンで実行可能なソフトウェア・アプリケーションであるライセンス契約管理プログラム１１６を有する。
【００２７】
ライセンス契約管理プログラム１１６はＷＬＭ１１２と通信して任意のパーティション１０８で利用可能な容量を理解する。ライセンスが管理されているソフトウェア・プロダクト（例えば、アプリケーション１１４）が１つのパーティション１０８で開始すると、ライセンス契約管理プログラム１１６はパーティションの容量（本発明によって管理されたように）に該プロダクトが既に開始されている同一マシン１０２上の任意の他の論理パーティション１０８の容量を加えたのと少なくとも同じだけの容量に対してプロダクトがライセンスされているかどうかを調べる。もしプロダクトがそのライセンスの範囲外であるならば、ライセンス契約管理プログラム１１６は、プログラムの開始を停止させるか例外レコードを書き込むかのいずれかを行う。ライセンス契約管理プログラム１１６は、ＷＬＭ１１２から変更容量の通知に対しても聞き耳を立てる。ライセンス契約管理プログラム１１６がそのような通知を受け取ると、実行中のプログラムがまだライセンスされた容量の範囲内であることを確認する。もしそうでなければ、ライセンス契約管理プログラム１１６は例外レコードを書き込む。
【００２８】
出願人J. P. Kubala他の同時係属出願である１９９９年９月２８日出願の米国特許出願一連番号０９／４０７，３９１（本明細書の発明の詳細な説明の一部として援用する）に記載されているように、ある動作モードにおいてＬＰ管理プログラム１０６はＬＰクラスタ（ＬＰＣ）又は単にクラスタとここで呼ぶグループとして論理パーティション１０８を管理する。１つのクラスタは、ある特定のマシン１０２上の全ての論理パーティション１０２、ある特定のマシン１０２の複数のパーティション１０８からなるサブセット、又は複数の異なるマシン１０２のパーティション１０８から構成されるものであってもよい。クラスタは、リソース競合存在下でその所定量に制限されるだろうが、競合がない状態では潜在的にそのようなリソースの追加量を使用する可能性があると思われる。
【００２９】
全体としてマシン・リソース共有をクラスタに割り当てることに加えて、ＬＰ管理プログラムはこの動作モードで各々のパーティションに割り当てられた論理パーティション重みに基づいてクラスタを構成している論理パーティション１０８間でリソースを割り当てることができる。重みの付けの一例として、４つの論理パーティション（ＬＰ１〜ＬＰ４）からなり、かつそれに対して４００ＭＩＰＳ（百万命令／秒）を使用可能とするＬＰクラスタを考える。クラスタ全体の重み１００に対してＬＰ１〜ＬＰ４がそれぞれ２０、３０、４０、及び１０の重みが割り当てられていると仮定する。この例では、もしＣＰＵ競合があるとすると、パーティションＬＰ１〜ＬＰ４は、４００ＭＩＰＳのクラスタ容量と同等の全容量に対して、それぞれ８０ＭＩＰＳ、１２０ＭＩＰＳ、１６０ＭＩＰＳ、及び４０ＭＩＰＳの容量で稼働することが可能となる。
【００３０】
既に指摘したように、パーティション重みそれ自体によって競合存在下で特定のパーティション１０８で利用可能なリソースのみが制限される。競合がない場合でもパーティションによるリソースの使用を制限するために、ＬＰ管理プログラム１０６はキャッピングとして知られている付加機能を有する。以下に説明するように、ＬＰ管理プログラムはキャッピングをパーティション１０８へ適用するもので、たとえ競合がない場合でもパーティション１０８のＣＰＵ使用量はパーティション重みによって定まる量に制限される。
【００３１】
図５は、個々のパーティション１０８を制御するために本発明の論理パーティション管理プログラム１０６によって使用された論理パーティション・パラメータ４００のいくつかを示す。これらのパラメータは、各パーティション１０８に対する一組のエントリ４０２からなり、論理パーティション重み４０４、後述する「疑似重み」４０６、同じく後述する「ソフト・キャップ」４０８、及びキャッピング・フラグ４１０を含む。論理パーティション重み４０４は、論理パーティション１０８がリソース競合存在下で資格があるマシン・リソース（この場合、ＣＰＵリソース）の相対量を特定する。ここで相対量とは、マシン１０２を構成する複数のパーティション１０８のパーティション重み全体に対するパーティション重み４０４の比に等しい。疑似重み４０６は、後述するように、本発明にもとづくキャッピング計算で使用される付加的な重みを定める。
【００３２】
ソフト・キャップ４０８は、パーティション１０８に対する最大容量を定める。ソフト・キャップ４０８の値は、論理パーティション１０８の定義の一部として定められる。ソフト・キャップ４０８の単位は、１時間あたり数百万の重みがかかっていないＣＰＵサービス単位（ＭＳＵ）である（ここでＣＰＵサービス単位は重みのかかっていないＣＰＵサービス単位のことを言う）。共有ＣＰを有し、はっきりとキャップされていないパーティション１０８に対してソフト・キャップ４０８を指定することができる。
【００３３】
ソフト・キャップ４０８は、マシン１０２上の物理的ＣＰ１０４の数に対するＭＰ因子を用いて計算されたＣＰＵサービス単位に準拠する。このことは、現在のパーティション１０８に対する論理ＣＰの数に準拠するＭＰ因子を用いるＷＬＭ１１２が行うＣＰＵサービス計算とは異なる。ＷＬＭ１１２はそれが計算するサービス単位をソフト・キャップに関連した判断のための物理的ＣＰ１０４の数に準拠したサービス単位に変換する。
【００３４】
キャッピング・フラグ４１０は、パーティション１０８についてキャッピングがオンであるかどうかを判断する。
【００３５】
本発明（以下に説明する疑似重みがない状態）でどのようにしてキャッピングが動作するかについての例として、４つの論理パーティション１０８（ＬＰ１〜ＬＰ４）を有し、かつ全ＣＰＵ容量が１０００ＭＩＰＳであるマシン１０２を検討する。各パーティション１０８は重みが２５であり、この重みによって競合存在下で各パーティションに対して２５０ＭＩＰＳが保証される。パーティションＬＰ１が４００ＭＩＰＳの容量をライセンスされたと仮定すると、もし利用可能であるならば（すなわち、他のパーティション１０８からの競合がなければ）ＬＰ１上の作業付加は４５０ＭＩＰＳを使用し、またパーティションＬＰ１はキャップが外される。もし４５０ＭＩＰＳがマシン１０２で利用可能であるならば（すなわち、他のパーティション１０８がそれ自身の重み全体を使用していない）、ＬＰ１は４００ＭＩＰＳのライセンス制限内でパーティションに対して平均使用を生ずるその重み相当量（２５０ＭＩＰＳ）での時間の２５％がキャップされなければならない。この２５％キャッピングを達成するためにこの例でＷＬＭ１１２が確立したキャッピング・パターンは、３０秒キャップした状態が続いた後、９０秒キャップが外された状態が続くパターンである。
【００３６】
図２は、ある期間にわたるＬＰ１によるＣＰＵ使用の結果として生じるキャッピング・パターン２００を示す。図に示すように、ＣＰＵ使用は、キャップされた区間２０２と、該区間２０２と交互に現れるキャップが外された区間２０４とから構成される。この例では、各々のキャップされた区間２０２は３０秒の長さであり、一方各々のキャップが外された区間２０４は９０秒の長さである。各キャップされた区間２０２では、ＬＰ１は２５０ＭＩＰＳのキャップされた容量（Ｃcapped）２０６で稼働し、一方各キャップが外された区間２０４ではＬＰ１は４５０ＭＩＰＳのキャップが外された容量（Ｃuncapped）で稼働する。この例では、キャップされた区間２０２が時間間隔全体の２５％を構成し、一方キャップが外された区間２０４は時間間隔全体の７５％を構成することから、時間間隔全体にわたる平均ＣＰＵ消費（Ｃavg）２１０は以下のように計算される。
【００３７】
【数１】
Ｃavg＝０．２５×Ｃcapped＋０．７５×Ｃuncapped ＝４００ＭＩＰＳ
【００３８】
図３は、特定のパーティション１０８について計算されたキャッピング・パターン（例えばパターン２００）を適用するためにＷＬＭ１２２が実行する手順２５０を示す。ＷＬＭは、キャッピング・フラグ２０４をセットしてキャッピングを開始するためにＬＰ管理プログラム１０６に命令を発することで、キャップがされている時間間隔２０２に対してキャッピングを適用する（ステップ２５２）。続いて、キャッピング・フラグ４１０をリセットしてキャッピングを終わらせるためにＬＰ管理プログラム１０６に対して命令を発することでキャップされていない時間間隔２０４に対してキャッピングを取り除く（ステップ２５４）。この手順２５０は、パターンに基づいてキャッピングが適用される限り繰り返される。
【００３９】
開示した実施形態では、パーティションに基づいた価格設定をサポートするという点でＷＬＭ１１２は２つの基本的な役割を持つ。
【００４０】
１． ＷＬＭ１１２は、必要に応じて潜在的ＣＰＵ容量がライセンス契約管理プログラム１１６に報告されるように、パーティション１０８で利用可能な潜在的ＣＰＵ容量を定期的に計算する。また、ＷＬＭ１１２はその容量が変化した場合にもライセンス契約管理プログラム１１６に知らせる。
【００４１】
２． ＷＬＭ１１２は、ソフト・キャップがパーティション１０８に関して設定又は変更されているかどうかを判断するために、ＬＰ管理プログラム１０６に対してポーリングを行う（対応のゼロ以外のソフト・キャップ・エントリ４０８によって示されるように）。ソフト・キャップがパーティション１０８に対して設定され、かつその４時間平均ＣＰＵ使用量がソフト・キャップを上回る場合、ＷＬＭ１１２はキャップ・パターンを計算し、パーティション１０８のキャッピングを開始する（以下に説明するように）。
【００４２】
潜在的なＣＰＵ容量の計算は、イメージの構成に依存するもので、以下の３通りの場合がある。
【００４３】
１． イメージは設定されたソフト・キャップを有する。復帰した潜在的容量の値はソフト・キャップ４０８の値である。
【００４４】
２． イメージは基本モードにあるか、もしくはキャップが外された論理パーティション１０８にあるかのいずれか一方である。復帰した潜在的容量の値は、個々のＣＰ速度、イメージ時間に利用可能なＣＰの数である。
【００４５】
３． イメージは、キャップ化論理パーティションである。復帰した潜在的容量の値は上記２の場合よりも小さく、またパーティションの現在の論理パーティション重みによって表されるＣＰＵ容量よりも小さい。
【００４６】
本発明が取り組む問題の１つは、従来の論理パーティション重みがマシン１０２上の他のパーティション１０８の重みに関連した意味のみを有することである（この議論の目的のために、ＬＰクラスタがマシン１０２全体から構成されると仮定する）。このことは、ＬＰ管理プログラム１０６からの付加機能をパーティションの重み及びマシン１０２上の他のパーティション１０８の重みに基づいて制限することなく、ソフト・キャップ値の範囲ＷＬＭ１１２が任意のパーティション１０８に対してサポートすることができることを意味する。もしソフト・キャップがパーティション重みが示す容量よりも少ない容量を示すならば、パーティション・ソフト・キャップを強化することはできない。
【００４７】
この問題の最も単純な例は、単一のパーティション１０８を持つマシン１０２である。そのパーティションの重みはマシンの容量の１００％を示すので、ソフト・キャップを使用してパーティションの容量を制限することはできない。この制限を受け入れることができないと考えられる。なぜなら、それによって論理パーティションに基づいた価格設定を用いることの複雑さが著しく増大するからである。ユーザが任意のパーティション重みを変更又は該ユーザのマシン１０２に容量を加えるたびに、パーティションの重みごとに表される容量が変化する。このことは、潜在的に、ＷＬＭ１１２及びＬＰ管理プログラム１０６によって強化することができないあるパーティション１０８に対してソフト・キャップを作り、それによってライセンス契約管理プログラム容量チェックが欠けたユーザのソフトウェア・プロダクトが得られる。
【００４８】
単一パーティション更新の場合におけるこの問題を定量化するために、単一論理パーティション１０８が４００ＭＩＰＳマシン１０２上に定められ、さらに４００ＭＩＰＳのライセンスされた容量を持つと仮定する。論理パーティション１０８は、共有プロセッサ及び１００の重みによって定められる。パーティション１０８は、加えられている将来の仕事負荷を予期する方向に定められる。この構成では、すべてが洗練されている。しかし、また将来に付加される新規の仕事負荷を予期してエンド・ユーザが自己のマシン１０２を５００ＭＩＰＳマシンに更新することを望むと仮定する。既存の論理パーティション１０８における仕事負荷は増加せず、そしてまたエンド・ユーザは増加したライセンス容量に対しての支払いを望まない。しかし、付加容量がマシン１０２に加えられるとすぐに、ＷＬＭは論理パーティションを４００ＭＩＰＳに管理することができない。なぜなら、論理パーティション１０８に対してキャップするものがないからである。キャッピングは、効率的にするために全ての重みの合計よりも低いものとなる論理パーティション重みを要求する。この場合、論理パーティションは、指定されたコンテナの大きさ４００ＭＩＰＳを実施することができないことから、例外モードであるとしてライセンス契約管理プログラム１１６に報告されなければならないと思われる。
【００４９】
この問題を解くために、ＷＬＭ１１２は現在のパーティション重みによって表される容量よりも低くパーティション１０８をキャプするための方法を必要とする。より詳しくは、ＷＬＭ１１２は、マシン１０２の残りの部分に関連した論理パーティションの重みが変化しないか（ＬＰクラスタには存在しない）、十分に変化することができないか（最小又は最大規格によって結合又はＬＰクラスタ合計によって）、又は共有ＣＰを使用している他の論理パーティションがないことから心配いらないかのいずれかである状況下で、キャッピング／重み付け計算における分母を調整することができる何かを必要とする。
【００５０】
この機能を提供するために、本発明はパーティション「疑似重み」又は価格設定管理プログラム調整重み（ＰＭＡＷ）と呼ばれるＬＰ管理プログラム１０６のための新規の制御を熟考する。各パーティション１０８は、ハードウェア命令の使用を介してＷＬＭ１１２を設定することができるそれ自身の疑似重み（図５のエントリ４０８）を有する。ある意味では、パーティションの疑似重量はそれをＬＰ管理プログラム１０６のように見せる。ダミー（又は疑似）パーティション１０８はこのパーティションのためにキャッピングがオンとなった時に存在する。それによって、パーティションの重みがマシンの重み全体よりも比率が小さくなる。この疑似重量は、ＷＬＭ１１２によってキャッピングされているパーティション１０８の優先順位を算定する場合のみ、論理パーティション重み全体に対する加算器として作用する。このことによって、ＷＬＭ１１２に対する最も高いフレキシビリティが可能となり、共有プロセッサを有する全てのＷＬＭ管理パーティション１０８がライセンスされた容量に管理されることができることを保証する。
【００５１】
どのようにＷＬＭ１１２が疑似重みを使用するかを理解するために、従来、どのようにＬＰ管理プログラム１０６がキャッピングを強制するかを見てみることが役立つ。図４は、かなり高いレベルでＬＰ管理プログラム１０６によって実行されたキャッピングの手順３００を示す。この図に関して、ＬＰ管理プログラム１０６は以下のように所定のパーティション１０８のためのキャッピングを強化する。
【００５２】
１． ＬＰ管理プログラム１０６は、全てのアクティブなパーティション１０８の重みの合計に対するパーティションの重みの比を計算する（ステップ３０２）。
【００５３】
２． ディスパッチ区間のあいだ、定期的に、ＬＰ管理プログラム１０６はこの比をパーティション１０８が使用したマシン容量の実際の割合と比較する（ステップ３０４）。
【００５４】
３． もしパーティションの実際の使用量がこの比を超えるならば（ステップ３０６）、パーティション１０８はディスパッチ区間の残りの部分でディスパッチされない（ステップ３０８）。
【００５５】
本発明によれば、ＷＬＭ１１２を現在の重みによって表される容量よりも少なくキャッピングさせるために、ＷＬＭ１１２がパーティション１０８をキャッピングした場合、ステップ１で述べた比の計算においてＬＰ管理プログラム１０６はパーティションの疑似重みをアクティブなパーティション１０８の重み全体に加える。例えば、重みが１００の単一パーティションを有する５００ＭＳＵマシンを考えた場合、もしユーザがこのパーティション１０８に対して４００ＭＳＵのソフト・キャップを設定するならば、ＷＬＭ１１２はパーティションの疑似重みを２５に設定する。設定された疑似重みを有するＷＬＭ１１２によってキャップされたパーティション１０８の重みによって表される容量を計算するための式は以下の通りである。
【００５６】
【数２】
Ｃcapped＝［パーティション重み／Σ（全アクティブ・パーティション重み＋疑似重み）×容量
即ち、Ｃcapped＝［Partition_weight／（ΣAll_active_partition_weights＋Phantom_weight）］×Capacity
と表す。
【００５７】
式中、Ｃcappedはパーティションのキャップ化容量、容量はキャップされていない場合のパーティション１０８によって潜在的に利用可能な全容量（ＭＳＵ又は他の適当な単位で）。
【００５８】
この例では、
【数３】
Ｃcapped＝１００／（１００＋２５）×５００ＭＳＵｓ＝４００ＭＳＵｓ，
【００５９】
式中、ＭＳＵは時間あたりの１００万サービス単位を示す。
【００６０】
ＷＬＭ１１２は、パーティションのソフト・キャップは、パーティションの現在の重みよりも少ない容量が少ない場合、パーティション１０８に対して疑似重みのみを設定する。そのような場合、ＷＬＭ１１２は以下の式（この式の導出について付録Ａを見よ）によってパーティションの疑似重みを計算する。
【００６１】
【数４】
疑似重み＝［（パーティション重み／ソフト・キャップ）ｘ容量］−Σ全パーティション重み
即ち、Phantom_weight＝［（Partition_weight／Soft_cap）×Capacity］−Σ All_partition_weights
と表す。
【００６２】
ＷＬＭ１１２は、１分間に１回、疑似重み計算に対する入力すべてをポーリングする。もしそれらの入力のいずれかが変化するならば、ＷＬＭ１１２はパーティションの疑似重みを再計算し、ＬＭ管理プログラム１０６に対して新規の疑似重みを供給する。
【００６３】
パーティション１０８がキャッピングをオンすることを必要とするわずかな時間を以下の式で計算することができる（この式の導出について付録Ｂを見よ）。
【００６４】
【数５】
Ｐ＝（Ｃuncapped−Ｃsoftcap）／（Ｃuncapped−Ｃcapped）
【００６５】
式中、Ｐはパーティション１０８がキャッピングを必要とする時間の端数、Ｃuncappedはキャップされていない時のパーティション１０８によって使用された平均容量、Ｃsoftcapはパーティション１０８に対するソフト・キャップの値、さらにＣcappedはキャップされている場合のパーティション１０８によって使用された平均容量である。もしパーティション１０８がキャッピングされたばかりであるなら、現在の重みによって表された容量をこの最新の値に対して使用してもよい。
【００６６】
論理パーティション１０８に対していつキャッピングをオン及びオフするかを判断するために、上記のように計算されたパーティション１０８をキャッピングすべき時間の割合を与える。ＷＬＭ１１２は、「キャップ・パターン」を生成する（図２）。好ましくは、ＷＬＭ１１２は、平均して１分間に１回よりも頻繁にパーティション１０８に対してキャッピングする論理パーティションの状態を変更すべきではない。すなわち、キャッピング状態は、１０分間に１０回よりも多く変更すべきではない。パターンは、２つの値によって表すことができる。すなわち、キャッピングをオンにすべき期間とキャッピングをオフにすべき期間である。以下の表１は、好ましい実施形態例でパーティションがキャップされるべき時間の割合全体に基づいてキャップがついている時間（Cap on time）及びキャップがはずされている時間（Cap off time）についての値を与える。値は、平均して１分間に１回を上回ることなくキャッピング状態での移行の数を保つために選択される。なお、表中、Ｐはパーティションがキャップされている時間の割合を示す。
【００６７】
【表１】
Percentage of time partition capped(P) Time cap on （秒） Time cap off （秒）
P ≦ 5% 0 常時
5% ＜ P ≦ 25% 30 90〜570
25% ＜ P ≦ 50% 60 60〜180
50% ＜ P ≦ 75% 60〜180 60
75% ＜ P ＜100% 90〜570 30
P = 100% 常時 0
【００６８】
ＷＬＭ１１２は、４時間を上回る平均ＣＰＵサービス率に基づいたソフト・キャップを実行する。パーティション１０８がキャップされるべきである時間の割合を計算するために、キャップされている間の平均ＣＰＵサービス率とキャップされていない間の平均ＣＰＵサービス率とが必要である。ここで図９を参照する。これらの平均を計算するために、ＷＬＭ１１２は項目６０２が４８個の配列を保持する（４時間のうちの５分間のインタバル数）。各項目は４つの値が含まれている。
【００６９】
６０４ パーティションがキャップされなかった場合の５分間のインタバル内で蓄積されたＣＰＵサービス。
【００７０】
６０６ パーティションがキャップされなかった５分間のインタバルにおける１０秒間のインタバル数。このインタバル数は０から３０までの範囲内であると考えられる。
【００７１】
６０８ パーティションがキャップされた場合の５分間のインタバル内で蓄積されたＣＰＵサービス。
【００７２】
６１０ パーティションがキャップされた５分間のインタバル内での１０秒間のインタバル数。このインタバル数は０から３０までの範囲内であると考えられる。
【００７３】
したがって、図６を最初に参照すると、５分毎にＷＬＭ１１２が手順５００を開始させる（図６乃至図８）。それによって、パーティション１０８がキャップされていなかった間の先行する５分間のインタバル中に蓄積されたＣＰＵサービス６０４（ステップ５０２）、パーティション１０８がキャップされていなかった間の先行する５分間のインタバルにおける１０秒間のインタバル数６０６（ステップ５０４）、パーティション１０８がキャップされていた間の先行する５分間のインタバル中に集積されたＣＰＵサービス６０８（ステップ５０６）、及びパーティションがキャップされていた間の先行する５分間のインタバルにおける１０秒間のインタバル数６１０（ステップ５０８）を決定する。これらの値６０４〜６１０が配列６００の次に利用可能な列６０２に格納される。
【００７４】
計算されたサービス・ユニットは、蓄積されたＣＰＵ時間のＬＰ管理プログラム１０６のビューに基づいている。したがって、１０秒毎にＷＬＭ１１２はＬＰ管理プログラム１０６に対して命令を送出する。この命令は各パーティションに対してデータ・テーブルを復帰させる。各パーティション１０８について、確定した論理ＣＰＵの各々に対してデータが復帰される。ＷＬＭ１１２は、ＷＬＭの特定のインスタンスが存在する論理パーティション１０８の各々の論理ＣＰＵに対する有効ディスパッチ時間を総計する。有効ディスパッチ時間の変更はＣＰＵサービス計算に対する入力として使用される。
【００７５】
パーティション１０８によって消費されたサービス・ユニットは、最初の５分間、第１の配列項目６０２に蓄積される。配列６００がひとたび満たされると、蓄積が折り返して最初の項目６０２に戻る。このようにして、アレイ６００は最後の４時間にわたって使用されたサービスを常に含む。
【００７６】
ここで図７を参照する。最後の５分間のインタバルに対して値６０４〜６１０を決定した後、ＷＬＭ１１２は、パーティションがキャップされていない場合の平均ＣＰＵサービス率（ステップ５１０）、キャップされている場合の平均ＣＰＵサービス率（ステップ５１２）、及び全平均ＣＰＵサービス率（ステップ５１４）を計算する。パーティションがキャップされていなかった場合の平均ＣＰＵサービス率（Ｃuncapped）を計算するために、ＷＬＭ１１２はパーティションがキャップされなかった場合（アレイにおける全ての値６１０の合計）の１０秒間のインタバル数で、キャップされている間に使用したサービス全体（配列６００における全ての値６０４の合計）を割る。全平均ＣＰＵサービス率を計算するために、ＷＬＭは全体の加算平均インタバルを通して使用した全サービス（配列６００における全ての値６０４及び６０６の合計）を加算平均インタバルにおける１０秒間のインタバル数（４時間加算平均インタバルで１４４０）で割る。システムが実際に４時間稼働するまで、データを有する配列項目のみが平均サービス率の計算に使用される。このことは、配列項目が４時間相当のデータを持っていない場合に計算される平均があまりにも低い値とならないようにするためである。
【００７７】
サービス・ユニット・データが蓄積される場合、計算されたサービスを調整して、ローカル・パーティションにある論理ＣＰの数に基づいたＭＰ（マルチプロセッシング）ファクタの代わりにマシン全体のＭＰファクタを反映させる。この調整は、マシン全体のＦＭファクタをパーティションのＭＰファクタに掛ける。マシン全体に対するＭＰファクタは、ＯＳ／３９０イメージに利用可能な潜在的ＣＰＵ容量の計算の一部として得られる。
【００７８】
次に、図８を参照する。それらの平均に基づいて、パーティション１０８に対するキャッピング状態で次の遷移が起こる。
【００７９】
１． もしパーティション１０８がキャップされていないで（ステップ５１６）、またその全平均ＣＰＵサービス率がソフト・キャップ（ステップ５１８）よりも高ければ、手順５００は図２に示すようなキャップ・パターンを計算し（ステップ５２０）、該パターンに基づいて図３に示す手順に従ってキャッピングを開始し（ステップ５２２）、さらに次の５分間のインタバルの終わりで繰り返されるように復帰する（ステップ５２４）。もし全平均ＣＰＵサービス率がソフト・キャップよりも高くなければ（ステップ５１８）、手順５００はキャップ・パターンを計算することなく、又はキャッピングを開始することなく復帰する（ステップ５２４）。
【００８０】
２． もしパーティション１０８がキャップされており（ステップ５１６）、またその非キャップ状態の平均ＣＰＵサービス率がソフト・キャップよりも低く（ステップ５２６）、手順５００は復帰（ステップ５２４）前にキャッピングを止める（ステップ５２８）。
【００８１】
３． もし上記条件のいずれでもなく、パーティション１０８がその時間の１００％キャップされており（ステップ５３０）、またその全ＣＰＵサービスがソフト・キャップよりも低ければ（ステップ５３２）、手順５００は同じく復帰（ステップ５２４）前にキャッピングを止める（ステップ５３４）。
【００８２】
４． もしパーティション１０８がキャップされており、また上記２つの条件のいずれでもなく、しかしキャップ状態の平均ＣＰＵサービス率６０８又はそのキャップされていない状態の平均サービス率６０４が閾値によって変化するならば（ステップ５３６）、手順５００は復帰（ステップ５２４）前にキャップ・パターンを再計算する（ステップ５３８）。
【００８３】
これらの条件のどれも起こらなければ、手順５００はキャッピングを停止することなく、又はキャッピング・パターンを再計算することなく、単に復帰する（ステップ５２４）。
【００８４】
もしパーティションがキャップされているならば、以下のイベントのためにキャップ・パターンも再計算される。
【００８５】
１． ＷＬＭ１１２はパーティションの重み４０４を変える（図５）。
【００８６】
２． ソフト・キャップ４０８が変化する（１分間に１回ポーリングされる）。
【００８７】
３． パーティションの現在の重み４０４及び疑似重み４０６によって表された容量が変化する（１分間に１回計算される）。
【００８８】
ＷＬＭ重み管理アルゴリズムは、パーティション１０８の動作を促進しようとする場合、パーティションのソフト・キャップ４０８よりも高くパーティション１０８の重み４０４を高めない。
【００８９】
１分間に１回、ＷＬＭ１１２がパーティション１０８に利用可能な全容量を計算する。もし値がその前の分から変化しているならば、ライセンス契約管理プログラム１１６に対して知らされる。論理パーティション・モードでは、上記したキャップ・パターン計算に対する入力としてＷＬＭ１１２もまた全マシン容量を計算する。
【００９０】
開示された実施形態例では、マシン１０２は基本モード（マシンがパーティション形成されていない）又は論理パーティション・モード（マシンが複数の論理パーティション１０８に分割されている）。基本モードでは、ＷＬＭ１１２はライセンス契約管理プログラム１１６に復帰できるように全マシン容量を計算する。全マシン容量を計算するために、最初にサービス・ユニット／秒／ＣＰＵが計算される。この値に対して利用可能なＣＰの総量を掛け、最終結果をＭＳＵに変換する。ここで、全マシン容量が作業の実行に対して潜在的に利用可能な全ＣＰに基づいているということである点に注意する。このことは、オンラインＣＰ及びオンラインでもたらされるＣＰが含まれる。
【００９１】
１． オンラインＣＰのカウント及びオンラインで変動するスタンドバイＣＰのカウント。これら２つのカウントの合計は利用可能なＣＰＵ全体のカウントである。
【００９２】
２． もし利用可能な全ＣＰＵカウントが現在のオンラインＣＰの数よりも多ければ、ＣＰＵ調整ファクタは利用可能な全ＣＰＵカウントに基づいて計算される。このＣＰＵ調整ファクタは、現在のＭＰファクタによって現在のＣＰＵ調整ファクタを乗じ、さらにそれを全ＣＰＵカウントのＭＰファクタによって割ることで計算される。
【００９３】
なお、ＣＰＵサービス・ユニットは、所定のプロセッサの速度に対して正規化されたプロセッサ容量の共通ユニットを表す。ＣＰＵ時間と異なり、ＣＰＵサービス・ユニットは、物理的プロセッサ速度に関係なくほぼ同一プロセッサ容量を示す。ＣＰＵ調整ファクタは、ＣＰＵ時間をＣＰＵサービス・ユニットに変換するための正規化値である。
【００９４】
３． １６，０００，０００をＣＰＵ調整ファクタによって割ることでＣＰＵ調整ファクタをサービス・ユニット／秒／ＣＰＵに変換する（これはサービス・ユニット／秒を計算するための一般式である。
【００９５】
４． １秒あたりの全マシン・サービス・ユニットを得るために、サービス・ユニット／秒／ＣＰＵを利用可能なＣＰＵ全体のカウントで乗じる。この結果をさらに３６００秒／時間で乗じ、続いて１，０００，０００で割ることで、全マシンＭＳＵ容量を得る。
【００９６】
論理パーティション・モードでは、全マシンＭＳＵ容量及びパーティションの潜在的ＭＳＵ容量の値が必要である。以下は全マシン容量を計算するためのステップである。
【００９７】
１． オンラインＣＰのカウントとオンラインで変動するＣＰのカウントとを得る。利用可能なＣＰ全体を得るために、構成及びスタンドバイＣＰのカウントを一緒に加える。
【００９８】
２． 物理的ＭＰファクタを得る。
【００９９】
３． 論理ＣＰＵ調整ファクタを物理的ＭＰファクタに対する論理ＭＰファクタの比によって乗じることで、物理的ＣＰＵ調整ファクタを計算する。
【０１００】
４． ＣＰＵサービス・ユニット／秒／ＣＰＵを計算するために、１６，０００，０００を物理的ＣＰＵ調整因子によって割る（このことはＣＰＵ調整ファクタからサービス・ユニット／秒への一般的変換法である）。ＣＰＵサービス・ユニット／秒の値を保存する。
【０１０１】
５． マシン容量を計算するために、サービス・ユニット／秒／ＣＰＵの値を上記計算した物理的ＣＰＵの数で乗ずる。得られたサービス・ユニット／秒の値を３６００秒／時間で乗じ、続いて１，０００，０００で割ることでＭＳＵに変換する。
【０１０２】
パーティションの潜在的に利用可能な容量を計算するために、ＷＬＭ１１２を以下のようにして行う。
【０１０３】
１． ソフト・キャップを有する論理パーティション：
パーティションの容量はソフト・キャップに等しい。
【０１０４】
２． ソフト・キャップ無しで、かつ明確にキャップされていない論理パーティション：
構成論理ＣＰＵのカウントをスタンドバイ論理ＣＰＵのカウントに加えることによってパーティションで利用可能な論理ＣＰＵの数を計算する。上記計算したサービス・ユニット／秒をこのパーティションで利用可能なＰＵの数で乗ずる。この結果を３６００秒／時間で乗じ、続いて１，０００，０００で割ることでＭＳＵに変換する。最大は１となる
【０１０５】
３． 明確にキャップされた論理パーティション。
パーティションの容量は上記２の計算のもの及びパーティションの重みによって表された容量よりも小さい。
【０１０６】
以上、特定の実施形態例を示し、かつそれを説明したが、特許請求の範囲によって限定される範囲内において種々の変更が可能であることを当業者は容易に理解するであろう。
【０１０７】
付録１：疑似重み式の導出
【０１０８】
疑似重みを計算する式を導き出すために、パーティションの重みが表す容量を計算するための式から開始する。我々は、パーティションの重みによって表されるようようがソフト・キャップと等しくなることを望む。
【０１０９】
【数６】
ソフト・キャップ＝［パーティション重み／（Σ全パーティション重み＋疑似重み）］×容量
即ち、Soft_cap＝［Partition_weight／（ΣAll_partition_weights＋Phantom_weight）］×Capacity
と表す。
【０１１０】
疑似重みについて解決する。
【０１１１】
【数７】
Σ全パーティション重み＋疑似重み＝（パーティション重み／ソフト・キャップ）Ｘ容量
即ち、ΣAll_partition_weights＋Phantom_weight＝(Partition_weight／Soft_cap）×Capacity
と表す。
【０１１２】
【数８】
疑似重み＝（パーティション重み／ソフト・キャップ）×容量−Σ全パーティション重み
即ち、Phantom_weight＝（Partition_weight／Soft_cap）×Capacity−ΣAll_partition_weights
と表す。
【０１１３】
付録Ｂ：キャップ割合を求める式の導出
【０１１４】
パーティションがキャップされなければならない時間の割合を計算するための式を導き出すために、時間の割合Ｐでキャップされているパーティションによって使用された平均ＣＰＵ容量を計算するための式から開始する。
【０１１５】
【数９】
Ｃavg＝Ｐ×Ｃcapped＋（１−Ｐ）×Ｃuncapped
【０１１６】
Ｐについて解決する。
【０１１７】
【数１０】
Ｃavg＝Ｐ（Ｃcapped−Ｃuncapped）＋Ｃuncapped
【０１１８】
【数１１】
Ｃavg−Ｃuncapped ＝Ｐ（Ｃcapped −Ｃuncapped）
【０１１９】
【数１２】
Ｐ＝（Ｃuncapped−Ｃavg）／（Ｃuncapped−Ｃcapped）
【０１２０】
平均ＣＰＵ容量がソフト・キャップに等しい時のＰを計算したいため、ＣavgをＣsoftcapで置き換える。
【０１２１】
【数１３】
Ｐ＝（Ｃuncapped−Ｃsoftcap）／（Ｃuncapped−Ｃcapped）
【０１２２】
まとめとして、本発明の構成に関して以下の事項を開示する。
（１）論理パーティションにある所定のシステム・リソースの実消費を決定するステップと、
前記実消費を、前記論理パーティションにある前記リソースに対する所定の許容消費と比較するステップと、
前記実消費が前記許容消費を上回る場合、前記リソースの前記実消費を前記許容消費まで減少させるステップと、
を有することを特徴とする方法。
（２）前記所定のシステム・リソースはプロセッサ・リソースであることを特徴とする上記（１）に記載の方法。
（３）複数の時間間隔にわたって前記消費を加算平均することで前記実消費を決定することを特徴とする上記（１）に記載の方法。
（４）物理的マシンが１つ以上の論理パーティションを有し、かつ前記論理パーティションの各々がマシン・リソースの所定の一部分を割り当てられている情報処理システムで、容量制限を強化するための方法であって、
前記１つ以上の論理パーティションによる前記リソースの最大許容容量を特定するステップと、
前記論理パーティションによる前記リソースの実消費を測定するステップと、
前記実消費と前記最大許容消費とを比較して前記実消費が前記最大許容消費を上回るかを決定するステップと、
もし前記実消費が前記最大許容消費を上回るならば、前記リソースの前記実消費を前記最大許容消費まで減少させるステップと、
を有することを特徴とする方法。
（５）前記論理パーティションは複数の論理パーティションからなる群から選択される１つであり、前記最大許容消費は前記複数の論理パーティションからなる群に利用可能なリソースの割合を特定することを特徴とする上記（４）に記載の方法。
（６）前記複数の論理パーティションからなる群は、前記物理的マシン上にある全ての論理パーティションから構成されることを特徴とする上記（４）に記載の方法。
（７）前記複数の論理パーティションからなる群に含まれる論理パーティションの各々は重みが割り当てられており、前記割合は前記群の前記複数のパーティションの重みの合計に対する前記論理パーティションの重みの比として定められていることを特徴とする上記（５）に記載の方法。
（８）前記論理パーティションは疑似重みも割り当てられており、該疑似重みは前記比を決定するステップで前記論理パーティションの重みの前記合計に加えられることを特徴とする上記（７）に記載の方法。
（９）前記所定のシステム・リソースはプロセッサ・リソースであることを特徴とする上記（４）に記載の方法。
（１０）前記実消費は所定の時間間隔における前記消費の回転平均として決定されることを特徴とする上記（４）に記載の方法。
（１１）マシンによって読み取り可能なプログラム記憶装置であって、上記（１）にもとづく方法のステップを実行するために前記マシンによって実行可能な複数の命令からなるプログラムを実質的に包含することを特徴とするプログラム記憶装置。
（１２）物理的マシンが１つ以上の論理パーティションを有し、かつ前記論理パーティションの各々がマシン・リソースの所定の一部分を割り当てられている情報処理システムで、容量制限を強化するための装置であって、
前記１つ以上の論理パーティションによる前記リソースの最大許容容量を特定する手段と、
前記論理パーティションによる前記リソースの実消費を測定する手段と、
前記実消費と前記最大許容消費とを比較して前記実消費が前記最大許容消費を上回るかを決定する手段と、
もし前記実消費が前記最大許容消費を上回るならば、前記リソースの前記実消費を前記最大許容消費まで減少させる手段と、
を有することを特徴とする装置。
（１３）前記論理パーティションは複数の論理パーティションからなる群から選択される１つであり、前記最大許容消費は前記複数の論理パーティションからなる群に利用可能なリソースの割合として特定することを特徴とする上記（１２）に記載の装置。
（１４）前記複数の論理パーティションからなる群に含まれる論理パーティションの各々は重みが割り当てられており、前記割合は前記群の前記複数のパーティションの重みの合計に対する前記論理パーティションの重みの比として定められていることを特徴とする上記（１３）に記載の装置。
（１５）前記論理パーティションは疑似重みも割り当てられており、該疑似重みは前記比を決定するステップで前記論理パーティションの重みの前記合計に加えられることを特徴とする上記（１４）に記載の方法。
【図面の簡単な説明】
【図１】本発明が適用される情報処理システムの概略的構成を説明するための模式図である。
【図２】本発明にもとづく方法及び装置に適用される典型的なキャッピング・パターンを説明するための図である。
【図３】キャッピング・パターンを適用するために仕事負荷管理プログラムによって実行される手順を説明するためのフローチャートである。
【図４】本発明の論理パーティション管理プログラムによて実行されるキャッピング手順を説明するためのフローチャートである。
【図５】本発明の論理パーティション管理プログラムによって使用される論理パーティション・パラメータを示すブロック図である。
【図６】キャッピングを適用すべきかどうかを判断するために本発明の仕事負荷管理プログラムによって実行される手順を説明するためのフローチャートである。
【図７】キャッピングを適用すべきかどうかを判断するために本発明の仕事負荷管理プログラムによって実行される手順を説明するためのフローチャートである。
【図８】キャッピングを適用すべきかどうかを判断するために本発明の仕事負荷管理プログラムによって実行される手順を説明するためのフローチャートである。
【図９】図６、図７、及び図８のフローチャートに示された手順を実行するために仕事負荷管理プログラムによって使用される配列を説明するための配列表である。
【符号の説明】
１０２ マシン
１０４ 物理的ＣＰ（物理的プロセッサ、中央処理装置）
１０６ 論理パーティション（ＬＰ）管理プログラム
１０８ 論理パーティション（ＬＰ１〜ＬＰ４）
１１０ オペレーティング・システム（ＯＳ）
１１２ 仕事負荷管理プログラム（ＷＬＭ）
１１４ アプリケーション
１１６ ライセンス契約管理プログラム
４００ 論理パーティション・パラメータ
４０２ エントリ
４０４ 論理パーティション重み
４０６ 疑似重み
４０８ ソフト・キャップ
４１０ キャッピング・フラグ
Claims (22)
- 物理的マシンが１つ以上の論理パーティションを有し、かつ前記論理パーティションの各々がマシン・リソースの所定の一部分を割り当てられ且つその中で実行される１つ以上のソフトウェアアプリケーション及びライセンス契約プログラムと通信可能な作業負荷管理プログラムを有するところの情報処理システムにおいて、ソフトウェア・プログラム・ライセンス契約によって課された容量制限に基づく該容量制限を強化するための方法であって、前記１つ以上の論理パーティションで実行されているソフトウェアアプリケーションが該パーティションの容量制限で上記ライセンス契約されているかどうかが、前記ライセンス契約プログラムが前記作業負荷管理プログラムと通信することによって確認され、
前記方法は、
前記１つ以上の論理パーティションによる前記リソースの最大許容容量を特定するステップと、
前記論理パーティションによる前記リソースの実消費を測定するステップと、
前記実消費と前記最大許容消費とを比較して前記実消費が前記最大許容消費を上回るかを決定するステップと、
もし前記実消費が前記最大許容消費を上回るならば、前記論理パーティションに割り当てられたマシン・リソースの前記所定の一部分を減少することによって前記リソースの前記実消費を前記最大許容消費まで減少させ、それによって前記論理パーティション中で実行される１つ以上のライセンス契約されたソフトウェアアプリケーションが実行することを許すステップと
を有することを特徴とする方法。 - 前記論理パーティションは複数の論理パーティションからなる群から選択される１つであり、前記最大許容消費は前記複数の論理パーティションからなる群に利用可能なリソースの割合を特定することを特徴とする請求項１に記載の方法。
- 前記複数の論理パーティションからなる群は、前記物理的マシン上にある全ての論理パーティションから構成されることを特徴とする請求項１に記載の方法。
- 前記複数の論理パーティションからなる群に含まれる論理パーティションの各々は重みが割り当てられており、前記割合は前記群の前記複数のパーティションの重みの合計に対する前記論理パーティションの重みの比として定められていることを特徴とする請求項２に記載の方法。
- 前記論理パーティションは疑似重みも割り当てられており、該疑似重みは前記比を決定するステップで前記論理パーティションの重みの前記合計に加えられることを特徴とする請求項４に記載の方法。
- 前記所定のシステム・リソースはプロセッサ・リソースであることを特徴とする請求項１に記載の方法。
- 前記実消費は所定の時間間隔における前記消費の回転平均として決定されることを特徴とする請求項１に記載の方法。
- 物理的マシンが１つ以上の論理パーティションを有し、かつ前記論理パーティションの各々がマシン・リソースの所定の一部分を割り当てられ且つその中で実行される１つ以上のソフトウェアアプリケーション及びライセンス契約プログラムと通信可能な作業負荷管理プログラムを有するところの情報処理システムにおいて、ソフトウェア・プログラム・ライセンス契約によって課された容量制限に基づく該容量制限を強化するためのプログラムを記録したマシンによって読み取り可能なプログラム記憶装置であって、前記１つ以上の論理パーティションで実行されているソフトウェアアプリケーションが該パーティションの容量制限で上記ライセンス契約されているかどうかが、前記ライセンス契約プログラムが前記作業負荷管理プログラムと通信することによって確認され、
前記情報処理システムに、
前記１つ以上の論理パーティションによる前記リソースの最大許容容量を特定するステップと、
前記論理パーティションによる前記リソースの実消費を測定するステップと、
前記実消費と前記最大許容消費とを比較して前記実消費が前記最大許容消費を上回るかを決定するステップと、
もし前記実消費が前記最大許容消費を上回るならば、前記論理パーティションに割り当てられたマシン・リソースの前記所定の一部分を減少することによって前記リソースの前記実消費を前記最大許容消費まで減少させ、それによって前記論理パーティション中で実行される１つ以上のライセンス契約されたソフトウェアアプリケーションが実行することを許すステップと
を実行させるプログラムを記録したプログラム記憶装置。 - 物理的マシンが１つ以上の論理パーティションを有し、かつ前記論理パーティションの各々がマシン・リソースの所定の一部分を割り当てられ且つその中で実行される１つ以上のソフトウェアアプリケーション及びライセンス契約プログラムと通信可能な作業負荷管理プログラムを有するところの情報処理システムにおいて、ソフトウェア・プログラム・ライセンス契約によって課された容量制限に基づく該容量制限を強化するための装置であって、前記１つ以上の論理パーティションで実行されているソフトウェアアプリケーションが該パーティションの容量制限で上記ライセンス契約されているかどうかが、前記ライセンス契約プログラムが前記作業負荷管理プログラムと通信することによって確認され、
前記装置は、
前記１つ以上の論理パーティションによる前記リソースの最大許容容量を特定する手段と、
前記論理パーティションによる前記リソースの実消費を測定する手段と、
前記実消費と前記最大許容消費とを比較して前記実消費が前記最大許容消費を上回るかを決定する手段と、
もし前記実消費が前記最大許容消費を上回るならば、前記論理パーティションに割り当てられたマシン・リソースの前記所定の一部分を減少することによって前記リソースの前記実消費を前記最大許容消費まで減少させ、それによって前記論理パーティション中で実行される１つ以上のライセンス契約されたソフトウェアアプリケーションが実行することを許す手段と
を有することを特徴とする装置。 - 前記論理パーティションは複数の論理パーティションからなる群から選択される１つであり、前記最大許容消費は前記複数の論理パーティションからなる群に利用可能なリソースの割合として特定することを特徴とする請求項９に記載の装置。
- 前記複数の論理パーティションからなる群に含まれる論理パーティションの各々は重みが割り当てられており、前記割合は前記群の前記複数のパーティションの重みの合計に対する前記論理パーティションの重みの比として定められていることを特徴とする請求項１０に記載の装置。
- 前記論理パーティションは疑似重みも割り当てられており、該疑似重みは前記比の決定により前記論理パーティションの重みの前記合計に加えられることを特徴とする請求項１１に記載の装置。
- 物理的マシンが１つ以上の論理パーティションを含む情報処理システムであって、前記論理パーティションの各々がマシン・リソースの定義された割合に割り当てられ且つその中で実行される１つ以上のソフトウェアアプリケーション及びライセンス契約プログラムと通信可能な作業負荷管理プログラムを有するところの情報処理システムにおいて、ソフトウェア・プログラム・ライセンス契約によって課された容量制限に基づく該容量制限を強化するための方法であって、前記１つ以上の論理パーティションで実行されているソフトウェアアプリケーションが該パーティションの容量制限で上記ライセンス契約されているかどうかが、前記ライセンス契約プログラムが前記作業負荷管理プログラムと通信することによって確認され、
前記方法は、
前記１つ以上の論理パーティションのうちの１つによって前記リソースの最大のキャップされた消費を特定するステップと、
前記論理パーティションによる前記リソースの実平均消費（Cavg）を測定するステップと、
前記実平均消費と前記最大のキャップされた消費（Ccapped）よりも大きい最大平均消費（Csoftcap）とを比較して、前記実平均消費が前記最大平均消費を上回るかを決定するステップと、
もし前記実平均消費が前記最大平均消費を上回るならば、前記論理パーティションが前記最大のキャップされた消費に制限されるキャップされたモード及び前記論理パーティションが前記最大のキャップされた消費に制限されないキャップされていないモードを前記論理パーティションにおいて交互に操作することによって前記リソースの前記実平均消費を前記最大平均消費まで減少するステップであって、それによって前記論理パーティション中で実行される１つ以上のライセンス契約されたソフトウェアアプリケーションが実行することを許すステップと
を含む方法。 - 前記論理パーティションが、１以上の論理パーティションのグループの１つであり、前記最大のキャップされた消費は、論理パーティションの前記グループに利用可能な前記リソースの一部として特定される、請求項１３に記載の方法。
- 前記グループにける前記論理パーティションの各々は、重みを割り当てられ、前記一部は、前記グループにおける前記論理パーティションの重みの合計に対する前記論理パーティションの前記重みの比として定義される、請求項１４に記載の方法。
- 前記論理パーティションはまた、前記比を決める際に前記グループにおける前記論理パーティションの前記重みの前記合計に加えられる擬似重みを割り当てられる、請求項１５に記載の方法。
- 物理的マシンが１つ以上の論理パーティションを含む情報処理システムであって、前記論理パーティションの各々がマシン・リソースの定義された割合に割り当てられ且つその中で実行される１つ以上のソフトウェアアプリケーションを有するところの情報処理システムにおいて、ソフトウェア・プログラム・ライセンス契約によって課された容量制限に基づく該容量制限を強化するためのシステムであって、前記１つ以上の論理パーティションで実行されているソフトウェアアプリケーションが該パーティションの容量制限で上記ライセンス契約されているかどうかが、前記ライセンス契約プログラムが前記作業負荷管理プログラムと通信することによって確認され、
前記システムは、
前記１つ以上の論理パーティションのうちの１つによって前記リソースの最大のキャップされた消費を特定する手段と、
前記論理パーティションによる前記リソースの実平均消費（Cavg）を測定する手段と、
前記実平均消費と前記最大のキャップされた消費（Ccapped）よりも大きい最大平均消費（Csoftcap）とを比較して、前記実平均消費が前記最大平均消費を上回るかを決定する手段と、
もし前記実平均消費が前記最大平均消費を上回るならば、前記論理パーティションが前記最大のキャップされた消費に制限されるキャップされたモード及び前記論理パーティションが前記最大のキャップされた消費に制限されないキャップされていないモードを前記論理パーティションにおいて交互に操作することによって前記リソースの前記実平均消費を前記最大平均消費まで減少する手段であって、それによって前記論理パーティション中で実行される１つ以上のライセンス契約されたソフトウェアアプリケーションが実行することを許す手段と
を含むシステム。 - 前記論理パーティションが、１以上の論理パーティションのグループの１つであり、前記最大のキャップされた消費は、論理パーティションの前記グループに利用可能な前記リソースの一部として特定される、請求項１７に記載のシステム。
- 前記グループにける前記論理パーティションの各々は、重みを割り当てられ、前記一部は、前記グループにおける前記論理パーティションの重みの合計に対する前記論理パーティションの前記重みの比として定義される、請求項１８に記載のシステム。
- 前記論理パーティションはまた、前記比を決める際に前記グループにおける前記論理パーティションの前記重みの前記合計に加えられる擬似重みを割り当てられる、請求項１９に記載のシステム。
- 物理的マシンが１つ以上の論理パーティションを含む情報処理システムであって、前記論理パーティションの各々がマシン・リソースの所定の一部分を割り当てられ且つその中で実行される１つ以上のソフトウェアアプリケーションを有するところの情報処理システムにおいて、ソフトウェア・プログラム・ライセンス契約によって課された容量制限に基づく該容量制限を強化するための方法であって、前記１つ以上の論理パーティションで実行されているソフトウェアアプリケーションが該パーティションの容量制限で上記ライセンス契約されているかどうかが、前記ライセンス契約プログラムが前記作業負荷管理プログラムと通信することによって確認され、
前記方法は、
前記１つ以上の論理パーティションのうちの１つによって前記リソースの最大のキャップされた消費（Ccapped）を特定するステップであって、前記論理パーティションは、１以上の論理パーティションのグループの１つであり、前記最大のキャップされた消費は、論理パーティションの前記グループに利用可能なリソースの一部として特定され、前記グループにおける前記論理パーティションの各々は、重みを割り当てられ、前記一部は、前記グループにおける前記論理パーティションの重みの合計に対する前記論理パーティションの前記重みの比として定義され、前記論理パーティションはまた、前記比を決める際に前記グループにおける前記論理パーティションの前記重みの前記合計に加えられる擬似重みを割り当てられる、前記特定するステップと、
前記論理パーティションによる前記リソースの実平均消費（Cavg）を測定するステップと、
前記実平均消費と最大平均消費（Csoftcap）とを比較して前記実平均消費が前記最大平均消費を上回るかを決定するステップと、
もし前記実平均消費が前記最大平均消費を上回るならば、前記論理パーティションが前記最大のキャップされた消費に制限されるキャップされたモードにおける時間の少なくとも一部を前記論理パーティションにおいて操作することによって、前記リソースの前記実平均消費を前記最大平均消費まで減少するステップであって、それによって前記論理パーティション中で実行される１つ以上のライセンス契約されたソフトウェアアプリケーションが実行することを許すステップと
を含む方法。 - 物理的マシンが１つ以上の論理パーティションを含む情報処理システムであって、前記論理パーティションの各々がマシン・リソースの所定の一部分を割り当てられ且つその中で実行される１つ以上のソフトウェアアプリケーション及びライセンス契約プログラムと通信可能な作業負荷管理プログラムを有するところの情報処理システムにおいて、ソフトウェア・プログラム・ライセンス契約によって課された容量制限に基づく該容量制限を強化するためのシステムであって、前記１つ以上の論理パーティションで実行されているソフトウェアアプリケーションが該パーティションの容量制限で上記ライセンス契約されているかどうかが、前記ライセンス契約プログラムが前記作業負荷管理プログラムと通信することによって確認され、
前記システムは、
前記１つ以上の論理パーティションのうちの１つによって前記リソースの最大のキャップされた消費（Ccapped）を特定する手段であって、前記論理パーティションは、１以上の論理パーティションのグループの１つであり、前記最大のキャップされた消費は、論理パーティションの前記グループに利用可能なリソースの一部として特定され、前記グループにおける前記論理パーティションの各々は、重みを割り当てられ、前記一部は、前記グループにおける前記論理パーティションの重みの合計に対する前記論理パーティションの前記重みの比として定義され、前記論理パーティションはまた、前記比を決める際に前記グループにおける前記論理パーティションの前記重みの前記合計に加えられる擬似重みを割り当てられる、前記特定する手段と、
前記論理パーティションによる前記リソースの実平均消費（Cavg）を測定する手段と、
前記実平均消費と最大平均消費（Csoftcap）とを比較して前記実平均消費が前記最大平均消費を上回るかを決定する手段と、
もし前記実平均消費が前記最大平均消費を上回るならば、前記論理パーティションが前記最大のキャップされた消費に制限されるキャップされたモードにおける時間の少なくとも一部を前記論理パーティションにおいて操作することによって、前記リソースの前記実平均消費を前記最大平均消費まで減少する手段であって、それによって前記論理パーティション中で実行される１つ以上のライセンス契約されたソフトウェアアプリケーションが実行することを許す手段と
を含むシステム。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/677,338 US7096469B1 (en) | 2000-10-02 | 2000-10-02 | Method and apparatus for enforcing capacity limitations in a logically partitioned system |
| US09/677338 | 2000-10-02 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002182934A JP2002182934A (ja) | 2002-06-28 |
| JP4267225B2 true JP4267225B2 (ja) | 2009-05-27 |
Family
ID=24718283
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001301690A Expired - Lifetime JP4267225B2 (ja) | 2000-10-02 | 2001-09-28 | システムに形成された論理パーティションの容量制限を強化するための方法及び装置 |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US7096469B1 (ja) |
| JP (1) | JP4267225B2 (ja) |
| TW (1) | TW583540B (ja) |
Families Citing this family (91)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7526767B1 (en) * | 1998-08-28 | 2009-04-28 | Oracle International Corporation | Methods for automatic group switching according to a resource plan |
| US20050149939A1 (en) * | 2001-12-21 | 2005-07-07 | Carsten Noeske | Method and device for managing resources in a computer system |
| US7885896B2 (en) * | 2002-07-09 | 2011-02-08 | Avaya Inc. | Method for authorizing a substitute software license server |
| US7565325B2 (en) * | 2002-07-09 | 2009-07-21 | Avaya Technology Corp. | Multi-site software license balancing |
| US8041642B2 (en) | 2002-07-10 | 2011-10-18 | Avaya Inc. | Predictive software license balancing |
| US7966520B2 (en) | 2002-08-30 | 2011-06-21 | Avaya Inc. | Software licensing for spare processors |
| US7681245B2 (en) | 2002-08-30 | 2010-03-16 | Avaya Inc. | Remote feature activator feature extraction |
| US20040078339A1 (en) * | 2002-10-22 | 2004-04-22 | Goringe Christopher M. | Priority based licensing |
| US7890997B2 (en) | 2002-12-26 | 2011-02-15 | Avaya Inc. | Remote feature activation authentication file system |
| US7370212B2 (en) | 2003-02-25 | 2008-05-06 | Microsoft Corporation | Issuing a publisher use license off-line in a digital rights management (DRM) system |
| US7437556B2 (en) * | 2003-05-09 | 2008-10-14 | Sun Microsystems, Inc. | Global visibility controls for operating system partitions |
| US7461080B1 (en) | 2003-05-09 | 2008-12-02 | Sun Microsystems, Inc. | System logging within operating system partitions using log device nodes that are access points to a log driver |
| US20040226015A1 (en) * | 2003-05-09 | 2004-11-11 | Leonard Ozgur C. | Multi-level computing resource scheduling control for operating system partitions |
| US8892878B2 (en) * | 2003-05-09 | 2014-11-18 | Oracle America, Inc. | Fine-grained privileges in operating system partitions |
| US7389512B2 (en) * | 2003-05-09 | 2008-06-17 | Sun Microsystems, Inc. | Interprocess communication within operating system partitions |
| US20040226017A1 (en) * | 2003-05-09 | 2004-11-11 | Leonard Ozgur C. | Mechanism for associating resource pools with operating system partitions |
| US20040249763A1 (en) * | 2003-06-04 | 2004-12-09 | Isogon Corporation | License management for computing on demand |
| US7620950B2 (en) * | 2003-07-01 | 2009-11-17 | International Business Machines Corporation | System and method to monitor amount of usage of applications in logical partitions |
| JP4094560B2 (ja) * | 2004-01-23 | 2008-06-04 | 株式会社エヌ・ティ・ティ・データ | リソース分割サーバ及びリソース分割サーバプログラム |
| US7526421B2 (en) * | 2004-02-27 | 2009-04-28 | International Business Machines Corporation | System and method for modeling LPAR behaviors in a simulation tool |
| US7814491B1 (en) * | 2004-04-14 | 2010-10-12 | Oracle America, Inc. | Method and apparatus for managing system resources using a container model |
| US7380119B2 (en) * | 2004-04-29 | 2008-05-27 | International Business Machines Corporation | Method and system for virtualization of trusted platform modules |
| US7484091B2 (en) * | 2004-04-29 | 2009-01-27 | International Business Machines Corporation | Method and system for providing a trusted platform module in a hypervisor environment |
| US20060242406A1 (en) | 2005-04-22 | 2006-10-26 | Microsoft Corporation | Protected computing environment |
| US8024726B2 (en) * | 2004-05-28 | 2011-09-20 | International Business Machines Corporation | System for correct distribution of hypervisor work |
| US20060004667A1 (en) * | 2004-06-30 | 2006-01-05 | Microsoft Corporation | Systems and methods for collecting operating system license revenue using an emulated computing environment |
| US8275969B2 (en) * | 2004-08-05 | 2012-09-25 | Sandisk Il Ltd. | Storage with persistent user data |
| US7747851B1 (en) | 2004-09-30 | 2010-06-29 | Avaya Inc. | Certificate distribution via license files |
| US8229858B1 (en) | 2004-09-30 | 2012-07-24 | Avaya Inc. | Generation of enterprise-wide licenses in a customer environment |
| US8347078B2 (en) | 2004-10-18 | 2013-01-01 | Microsoft Corporation | Device certificate individualization |
| US8176564B2 (en) * | 2004-11-15 | 2012-05-08 | Microsoft Corporation | Special PC mode entered upon detection of undesired state |
| US8464348B2 (en) * | 2004-11-15 | 2013-06-11 | Microsoft Corporation | Isolated computing environment anchored into CPU and motherboard |
| US8336085B2 (en) | 2004-11-15 | 2012-12-18 | Microsoft Corporation | Tuning product policy using observed evidence of customer behavior |
| US8181182B1 (en) | 2004-11-16 | 2012-05-15 | Oracle America, Inc. | Resource allocation brokering in nested containers |
| US7752415B2 (en) * | 2004-12-22 | 2010-07-06 | International Business Machines Corporation | Method for controlling the capacity usage of a logically partitioned data processing system |
| US20060190522A1 (en) * | 2005-02-18 | 2006-08-24 | Mitsuhiro Nagata | Method for controlling a computer |
| US8438645B2 (en) | 2005-04-27 | 2013-05-07 | Microsoft Corporation | Secure clock with grace periods |
| US8725646B2 (en) | 2005-04-15 | 2014-05-13 | Microsoft Corporation | Output protection levels |
| US9363481B2 (en) | 2005-04-22 | 2016-06-07 | Microsoft Technology Licensing, Llc | Protected media pipeline |
| US9436804B2 (en) | 2005-04-22 | 2016-09-06 | Microsoft Technology Licensing, Llc | Establishing a unique session key using a hardware functionality scan |
| US8336054B2 (en) * | 2006-07-20 | 2012-12-18 | Hewlett-Packard Development Company, L. P. | System and method for allocating capacity of shared resources to a workload |
| US20060265758A1 (en) | 2005-05-20 | 2006-11-23 | Microsoft Corporation | Extensible media rights |
| JP4715311B2 (ja) * | 2005-06-01 | 2011-07-06 | 株式会社日立製作所 | Ｓｍｐライセンス情報を有する情報処理装置 |
| US8353046B2 (en) | 2005-06-08 | 2013-01-08 | Microsoft Corporation | System and method for delivery of a modular operating system |
| CN1937628B (zh) * | 2005-09-21 | 2010-04-07 | 国际商业机器公司 | 用于管理数据处理目标实体的方法和系统 |
| US7603671B2 (en) * | 2005-11-04 | 2009-10-13 | Sun Microsystems, Inc. | Performance management in a virtual computing environment |
| US8938473B2 (en) | 2006-02-23 | 2015-01-20 | Oracle America, Inc. | Secure windowing for labeled containers |
| US7882227B2 (en) | 2006-02-23 | 2011-02-01 | Oracle America, Inc. | Mechanism for implementing file access control across a network using labeled containers |
| US7885975B2 (en) | 2006-02-23 | 2011-02-08 | Oracle America, Inc. | Mechanism for implementing file access control using labeled containers |
| US8938554B2 (en) * | 2006-03-02 | 2015-01-20 | Oracle America, Inc. | Mechanism for enabling a network address to be shared by multiple labeled containers |
| US7797756B2 (en) * | 2006-04-18 | 2010-09-14 | Hewlett-Packard Development Company, L.P. | System and methods for managing software licenses in a variable entitlement computer system |
| JP4653697B2 (ja) * | 2006-05-29 | 2011-03-16 | 株式会社日立製作所 | 電力管理方法 |
| US8032882B2 (en) * | 2006-07-26 | 2011-10-04 | Hewlett-Packard Development Company, L.P. | System and method for controlling aggregate CPU usage by virtual machines and driver domains |
| US8782671B2 (en) * | 2006-07-26 | 2014-07-15 | Hewlett-Packard Development Company, L. P. | Systems and methods for flexibly controlling resource usage by a driver domain on behalf of a virtual machine |
| US8024738B2 (en) * | 2006-08-25 | 2011-09-20 | International Business Machines Corporation | Method and system for distributing unused processor cycles within a dispatch window |
| US8082547B1 (en) * | 2006-10-31 | 2011-12-20 | Hewlett-Packard Development Company, L.P. | Reallocating hardware resources among workloads in accordance with license rights |
| US8650296B1 (en) * | 2006-10-31 | 2014-02-11 | Hewlett-Packard Development Company, L.P. | Workload reallocation involving inter-server transfer of software license rights and intra-server transfer of hardware resources |
| JP4923990B2 (ja) * | 2006-12-04 | 2012-04-25 | 株式会社日立製作所 | フェイルオーバ方法、およびその計算機システム。 |
| JP4715758B2 (ja) * | 2007-01-30 | 2011-07-06 | 株式会社日立製作所 | 仮想計算機システムのプロセッサキャッピング方法 |
| US8386391B1 (en) * | 2007-05-01 | 2013-02-26 | Hewlett-Packard Development Company, L.P. | Resource-type weighting of use rights |
| US10452820B2 (en) * | 2007-06-26 | 2019-10-22 | International Business Machines Corporation | Thread-based software license management |
| US20090025004A1 (en) * | 2007-07-16 | 2009-01-22 | Microsoft Corporation | Scheduling by Growing and Shrinking Resource Allocation |
| US8185907B2 (en) * | 2007-08-20 | 2012-05-22 | International Business Machines Corporation | Method and system for assigning logical partitions to multiple shared processor pools |
| US20090055835A1 (en) * | 2007-08-20 | 2009-02-26 | Telefonaktiebolaget Lm Ericsson (Publ) | System and Method for Managing License Capacity in a Telecommunication Network |
| US8856332B2 (en) * | 2007-10-09 | 2014-10-07 | International Business Machines Corporation | Integrated capacity and architecture design tool |
| US8302102B2 (en) * | 2008-02-27 | 2012-10-30 | International Business Machines Corporation | System utilization through dedicated uncapped partitions |
| US9086913B2 (en) * | 2008-12-31 | 2015-07-21 | Intel Corporation | Processor extensions for execution of secure embedded containers |
| US20100212021A1 (en) * | 2009-02-18 | 2010-08-19 | Harris Technology, Llc | Decrement software |
| US8140817B2 (en) * | 2009-02-24 | 2012-03-20 | International Business Machines Corporation | Dynamic logical partition management for NUMA machines and clusters |
| JP2010267009A (ja) * | 2009-05-13 | 2010-11-25 | Canon Inc | ライセンス管理システム、ライセンス管理方法及びコンピュータプログラム |
| US11132237B2 (en) * | 2009-09-24 | 2021-09-28 | Oracle International Corporation | System and method for usage-based application licensing in a hypervisor virtual execution environment |
| US9069610B2 (en) * | 2010-10-13 | 2015-06-30 | Microsoft Technology Licensing, Llc | Compute cluster with balanced resources |
| US11151164B2 (en) * | 2013-03-13 | 2021-10-19 | International Business Machines Corporation | Replication group partitioning |
| US9781015B2 (en) | 2013-03-28 | 2017-10-03 | Hewlett Packard Enterprise Development Lp | Making memory of compute and expansion devices available for use by an operating system |
| WO2014158161A1 (en) | 2013-03-28 | 2014-10-02 | Hewlett-Packard Development Company, L.P. | Error coordination message for a blade device having a logical processor in another system firmware domain |
| JP6031212B2 (ja) * | 2013-03-28 | 2016-11-24 | ヒューレット−パッカード デベロップメント カンパニー エル．ピー．Ｈｅｗｌｅｔｔ‐Ｐａｃｋａｒｄ Ｄｅｖｅｌｏｐｍｅｎｔ Ｃｏｍｐａｎｙ， Ｌ．Ｐ． | ブレードデバイスを備えるパーティションのオペレーティングシステムによって用いられるブレードデバイスのメモリの特定 |
| US10936976B2 (en) * | 2013-09-30 | 2021-03-02 | Bmc Software, Inc. | Workload management for license cost optimization |
| US9703611B1 (en) | 2014-03-21 | 2017-07-11 | Amazon Technologies, Inc. | Isolating resources for utilization by tenants executing in multi-tenant software containers |
| US9348644B2 (en) * | 2014-10-08 | 2016-05-24 | International Business Machines Corporation | Application-level dispatcher control of application-level pseudo threads and operating system threads |
| WO2016075771A1 (ja) * | 2014-11-12 | 2016-05-19 | 株式会社日立製作所 | 計算機システムおよび計算機システムにおけるオートスケール方法 |
| US10176021B1 (en) * | 2014-11-21 | 2019-01-08 | Ca, Inc. | System and method for managing actual processing capacity usage on a mainframe computer |
| US9588795B2 (en) | 2014-11-24 | 2017-03-07 | Aspen Timber LLC | Monitoring and reporting resource allocation and usage in a virtualized environment |
| US9342372B1 (en) * | 2015-03-23 | 2016-05-17 | Bmc Software, Inc. | Dynamic workload capping |
| US9680657B2 (en) | 2015-08-31 | 2017-06-13 | Bmc Software, Inc. | Cost optimization in dynamic workload capping |
| FR3041788B1 (fr) | 2015-09-30 | 2018-02-02 | Zcost Management | Procede de controle de la capacite d'utilisation d'un systeme partitionne de traitement de donnees. |
| US10769051B2 (en) * | 2016-04-28 | 2020-09-08 | International Business Machines Corporation | Method and system to decrease measured usage license charges for diagnostic data collection |
| US10067814B2 (en) | 2016-04-28 | 2018-09-04 | International Business Machines Corporation | Method and system to decrease measured usage license charges for diagnostic data collection |
| US10108459B2 (en) * | 2016-09-12 | 2018-10-23 | Bmc Software, Inc. | System and method to dynamically allocate varying processing capacity entitlements based on workload importance |
| US11074322B1 (en) | 2017-07-17 | 2021-07-27 | Juniper Networks, Inc. | Adaptive capacity management for network licensing |
| US12026237B2 (en) * | 2019-12-11 | 2024-07-02 | The Boeing Company | Software license manager |
| US11983252B2 (en) | 2019-12-11 | 2024-05-14 | The Boeing Company | Software license manager security |
Family Cites Families (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4489386A (en) * | 1982-02-03 | 1984-12-18 | At&T Bell Laboratories | Device control system |
| US5390297A (en) | 1987-11-10 | 1995-02-14 | Auto-Trol Technology Corporation | System for controlling the number of concurrent copies of a program in a network based on the number of available licenses |
| US4937863A (en) | 1988-03-07 | 1990-06-26 | Digital Equipment Corporation | Software licensing management system |
| JPH07249010A (ja) * | 1994-03-10 | 1995-09-26 | Hitachi Ltd | ジョブスケジューラおよびジョブスケジューリング方法 |
| US5671412A (en) | 1995-07-28 | 1997-09-23 | Globetrotter Software, Incorporated | License management system for software applications |
| JP3543441B2 (ja) * | 1995-09-19 | 2004-07-14 | 株式会社日立製作所 | 大域的なリソースキャッピング方法 |
| US5758068A (en) | 1995-09-19 | 1998-05-26 | International Business Machines Corporation | Method and apparatus for software license management |
| US5754763A (en) | 1996-10-01 | 1998-05-19 | International Business Machines Corporation | Software auditing mechanism for a distributed computer enterprise environment |
| US6021438A (en) | 1997-06-18 | 2000-02-01 | Wyatt River Software, Inc. | License management system using daemons and aliasing |
| US6056786A (en) | 1997-07-11 | 2000-05-02 | International Business Machines Corp. | Technique for monitoring for license compliance for client-server software |
| US6032239A (en) * | 1997-10-15 | 2000-02-29 | Dell Usa, L.P. | System and method for updating partition mappings to logical drives in a computer memory device |
| JP3906594B2 (ja) * | 1998-01-09 | 2007-04-18 | 株式会社日立製作所 | Ｃｐｕ能力調整方法 |
| US6049789A (en) | 1998-06-24 | 2000-04-11 | Mentor Graphics Corporation | Software pay per use licensing system |
| US6438704B1 (en) * | 1999-03-25 | 2002-08-20 | International Business Machines Corporation | System and method for scheduling use of system resources among a plurality of limited users |
| US6832248B1 (en) * | 2001-05-10 | 2004-12-14 | Agami Systems, Inc. | System and method for managing usage quotas |
-
2000
- 2000-10-02 US US09/677,338 patent/US7096469B1/en not_active Expired - Lifetime
-
2001
- 2001-09-26 TW TW090123784A patent/TW583540B/zh not_active IP Right Cessation
- 2001-09-28 JP JP2001301690A patent/JP4267225B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JP2002182934A (ja) | 2002-06-28 |
| TW583540B (en) | 2004-04-11 |
| US7096469B1 (en) | 2006-08-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4267225B2 (ja) | システムに形成された論理パーティションの容量制限を強化するための方法及び装置 | |
| US11681562B2 (en) | Resource manager for managing the sharing of resources among multiple workloads in a distributed computing environment | |
| JP3944175B2 (ja) | コンピュータ・システムにおける区画間の動的プロセッサ再配分 | |
| JP4084765B2 (ja) | コンピューティングリソースを自動的に割り振る方法 | |
| JP3978199B2 (ja) | リソースの利用およびアプリケーションの性能の監視システムおよび監視方法 | |
| US7748005B2 (en) | System and method for allocating a plurality of resources between a plurality of computing domains | |
| US8261281B2 (en) | Optimizing allocation of resources on partitions of a data processing system | |
| US20180246771A1 (en) | Automated workflow selection | |
| JP4112420B2 (ja) | 重みを使用してアプリケーションにシステム資源を割当てる方法およびシステム | |
| US7140020B2 (en) | Dynamic management of virtual partition computer workloads through service level optimization | |
| US8650296B1 (en) | Workload reallocation involving inter-server transfer of software license rights and intra-server transfer of hardware resources | |
| Sharma et al. | Resource deflation: A new approach for transient resource reclamation | |
| US9081621B2 (en) | Efficient input/output-aware multi-processor virtual machine scheduling | |
| US8185907B2 (en) | Method and system for assigning logical partitions to multiple shared processor pools | |
| US7770173B2 (en) | System for dynamic processor enablement | |
| CN110597639B (zh) | Cpu分配控制方法、装置、服务器及存储介质 | |
| EP3293632B1 (en) | Dynamically varying processing capacity entitlements | |
| Hoyer et al. | Proactive dynamic resource management in virtualized data centers | |
| US9680657B2 (en) | Cost optimization in dynamic workload capping | |
| Goiri et al. | Introducing virtual execution environments for application lifecycle management and SLA-driven resource distribution within service providers | |
| Whalley et al. | Licence-aware management of virtual machines | |
| CN113918271A (zh) | 一种资源管理方法、装置、电子设备及存储介质 | |
| Li et al. | Deployment of services in a cloud subject to memory and license constraints | |
| Menasce | Allocating applications in distributed computing | |
| Talwar et al. | Resource allocation for remote desktop sessions in utility grids |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20041215 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050215 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20050512 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20050517 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050815 Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20050815 |
|
| RD12 | Notification of acceptance of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7432 Effective date: 20050815 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20050816 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20051012 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20051125 Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20051125 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20060110 |
|
| A912 | Re-examination (zenchi) completed and case transferred to appeal board |
Free format text: JAPANESE INTERMEDIATE CODE: A912 Effective date: 20060623 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20080213 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20080213 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20080218 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20080314 |
|
| RD14 | Notification of resignation of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7434 Effective date: 20081224 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090105 |
|
| RD14 | Notification of resignation of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7434 Effective date: 20090130 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090218 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4267225 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120227 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120227 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130227 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130227 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140227 Year of fee payment: 5 |