JP2003514270A - コンピュータ環境におけるワークロード管理 - Google Patents

Abstract

(57)【要約】 【課題】 コンピュータ環境内で良好なワークロード管理を提供すること。 【解決手段】 コンピュータ環境の共用可能リソースの割振りが、該環境のワークロードを平衡化するために動的に調整される。ワークロードは、コンピュータ環境の複数の区画のうちの２以上の区画にわたって管理される。これらの区画は区画グループとして構成されるのが好ましい。コンピュータ環境の少なくとも１つのグループはコンピュータ環境の複数の区画を含む。共用可能リソースはグループの区画に割り当てられ、１グループとして管理される。本発明の管理は、２以上の区画のワークロード目標を平衡化するために、その２以上の区画のうちの少なくとも１つの区画の共用可能リソースの割振りを動的に調整することを含む。これの一例は、コンピュータ環境内での中央処理装置（ＣＰＵ）リソースの管理である。コンピュータ環境の区画へのＣＰＵリソースの割振りを調整する場合、その割振りは動的に調整される。この調整は、区画に関連するプロセッサ重みを修正することを含む。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】

本発明は、全般的にはコンピュータ・システム内のワークロードの管理に関し
、具体的には、区画に分割されたシステムでのワークロードの管理に関する。

【０００２】

【従来の技術】

論理分割を用いると、単一の物理計算機または中央演算処理装置複合システム
（ＣＰＣ）内で複数のシステム・イメージを確立することができる。各システム
・イメージは、別々のコンピュータ・システムであるかのように動作することが
できる。すなわち、各論理区画は、独立にリセットでき、論理区画ごとに異なる
ものとすることのできるオペレーティング・システムを初期ロードでき、異なる
入出力（Ｉ／Ｏ）装置を使用して異なるソフトウェア・プログラムと共に動作す
ることができる。

【０００３】 論理分割されたコンピュータ・システムの例は、たとえば、１９８６年１月１
４日発行の米国特許第４５６４９０３号明細書、１９８９年６月２７日発行の米
国特許第４８４３５４１号明細書、および１９９６年１０月８日発行の米国特許
第５５６４０４０号明細書に記載されている。

【０００４】 論理分割されたシステムの商業実施形態には、たとえば、プロセッサ・リソー
ス／システム管理機構（ＰＲ／ＳＭ）を備えたＩＢＭ Ｓ／３９０プロセッサが
含まれ、ＰＲ／ＳＭは、たとえば、ＩＢＭ社の出版物「Processor Resource/Sys
tems Manager Planning Guide」、ＧＡ２２−７２３６−０４、１９９９年３月
に記載されている。

【０００５】

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

論理分割されたシステムの重要な態様の１つが、そのシステムの区画内で稼動
するワークロードの管理である。たとえば、Ｓ／３９０システムでは、ワークロ
ード・マネージャを使用して、区画内および区画間でワークロードを管理する。
ワークロード・マネージャは、作業をシステムの物理リソースに移動することに
よって、ワークロードの平衡化を試みる。しかし、作業を移動するためには、リ
ロケートされる作業が必要とするデータが、移動先の位置にあることを保証する
ことが重要である。この必要が、作業の移動を制限することがしばしばである。
したがって、コンピュータ・システムにおけるワークロード管理をさらに改良す
ることが望ましい。

【０００６】

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

したがって、本発明は特許請求の範囲に記載された方法、システムおよびコン
ピュータ・プログラムを提供する。

【０００７】 １つの実施形態では、本方法は、コンピュータ環境の複数の区画のうちの２以
上の区画にまたがってワークロードを管理するステップを含み、この管理するス
テップは、これら２以上の区画のワークロード目標が平衡化されるように、２以
上の区画のうちの少なくとも１つの区画の共用可能リソースの割振りを動的に調
整するステップを含む。

【０００８】 本発明の他の実施形態では、コンピュータ環境のワークロードを管理するため
の方法は、コンピュータ環境の複数の区画のうち、共用可能リソースを並行共用
する２以上の区画にまたがってワークロードを管理するステップを含む。この管
理するステップは、２以上の区画のうちの少なくとも１つの区画の共用可能リソ
ースの割振りを動的に調整するステップを含む。

【０００９】 本発明の好ましい実施形態は、ワークロード・マネージャの指示のもとに、複
数の論理区画における共用可能リソースの動的再分配を可能にする。これらのリ
ソースは、たとえば、ＣＰＵリソース、論理プロセッサ・リソース、Ｉ／Ｏリソ
ース、コプロセッサ、チャネル・リソース、ネットワーク・アダプタ、およびメ
モリ・リソースを含む。一般に、ワークロード目標に従う物理リソースの動的調
整は、並列シスプレックス・データ共用を必要とすることなく、ワークロード・
マネージャ（ＷＬＭ）、シスプレックス、およびＰＲ／ＳＭの統合によって提供
される。

【００１０】 また、好ましい実施形態では、論理区画（ＬＰＡＲ）におけるＣＰＵリソース
のＷＬＭ動的管理、ＬＰＡＲにおける動的チャネル・パス（ＣＨＰＩＤ）管理、
チャネル・サブシステムにおけるＷＬＭベースのＩ／Ｏ優先キューイング、およ
びＬＰＡＲにおけるＷＬＭ動的メモリ管理が提供される。１つの実装例では、Ｌ
ＰＡＲグループは、優先順位に基づくリソース割振りによるリソース共用を可能
にする。

【００１１】 本発明の他の実施形態は、コンピュータ環境の複数の区画のグループを識別す
るステップを含む、コンピュータ環境の区画のグループを管理する方法を提供す
る。この方法は、さらに、グループに割り当てられる共用可能リソースを決定す
るためのステップを含み、その共用可能リソースの少なくとも一部がグループの
複数の区画に割り振られる。

【００１２】 本発明の他の実施形態は、コンピュータ環境の複数の区画を含むグループが変
更されたことを決定するステップと、この決定に応答して、グループ内でグルー
プのリソースの割振りを動的に調整するステップとを含む、コンピュータ環境の
ワークロードを管理する方法を提供する。

【００１３】 好ましい実施形態では、どのリソースが特定のグループに割り当てられるかを
決定するため、およびそのようなりソースの割振りを実行するために、グループ
のリソースがスコーピングされる。スコーピングは、次に何をなすべきかをＷＬ
Ｍが正しく判断できるように、変更可能なりソースを管理する。スコーピングは
、ソフトウェアが何をしたいかをマシンが理解することができ、ソフトウェアが
マシン構成を理解するように、リソースのサブセットがマシン上に提供されるの
を可能にする。

【００１４】 本発明の他の好ましい実施形態は、コンピュータ環境の区画へのＣＰＵリソー
スの割振りを調整すべきことを決定するステップと、その区画およびコンピュー
タ環境の他の区画にまたがって割振りを動的に調整するステップとを含む、コン
ピュータ環境内でＣＰＵリソースを管理するための方法を提供する。

【００１５】 動的に調整するステップは、少なくとも区画のワークロード目標に応答して、
コンピュータ環境の複数の区画にまたがって実行されるのが好ましい。

【００１６】 好ましい実施形態では、ワークロード・マネージャが、論理区画に関連するＣ
ＰＵプロセッサ重みを動的に調整することによって、複数の論理区画にまたがっ
てＣＰＵリソースを分配する。ＷＬＭは、たとえば、重要なワークロードを実行
している区画の重みが低すぎるために、そのワークロードが遅れたときを把握す
る。ＷＬＭは、たとえば、その区画の重みを上げ、且つ他の区画の重みを下げて
、重要なワークロードに対し追加のＣＰＵ容量を提供することにより、そのワー
クロードを援助することができる。これにより、ワークロード要件が変わったと
きに、必要な区画へＣＰＵリソースを動的に移動することができるようになる。

【００１７】 本発明は、上記の方法を実行するためのコンピュータ・プログラムも提供する
。そのようなコンピュータ・プログラムは、一般に、コンピュータ可用媒体ある
いはマシンが読み取り可能なプログラム記憶装置にエンコードされている、マシ
ンが実行可能な命令を含み、コンピュータ・システムの一部に含まれるか、また
は（たとえば、ネットワークを介する伝送によって）別途に販売される。

【００１８】 本発明は、上記の方法に対応し、且つ方法を実行するためのコンピュータ・プ
ログラムおよび適切なハードウェアを組み合わせることによって構成され得るシ
ステムも提供する。

【００１９】 上記のようなコンピュータ・プログラムおよびシステムが、本発明の方法と同
様な好ましい特徴に起因する効果を奏することは理解されよう。

【００２０】 次に、図面を参照しながら、本発明の好ましい実施形態について、例示の目的
のみで詳細に説明する。

【００２１】

【発明の実施の形態】

コンピュータ環境のリソースの割振りの動的調整によって、その環境のワーク
ロードを平衡化できるようにする、ワークロード管理機能を提供する。一例では
、コンピュータ環境に複数の論理区画が含まれ、ワークロードは、そのうちの２
以上の区画にまたがって管理される。

【００２２】 ワークロード管理機能を使用するコンピュータ環境の一実施形態を、図１を参
照して説明する。コンピュータ環境１００は、たとえば、米国ニューヨーク州ア
ーモンクのInternational Business Machines Corporationが提供するエンター
プライズ・システム・アーキテクチャー（ＥＳＡ）／３９０に基づく。ＥＳＡ／
３９０は、ＩＢＭ社の出版物、「Enterprise Systems Architecture/390 Princi
ples Of Operation」、ＩＢＭ出版番号ＳＡ２２−７２０１−０４、１９９７年
６月に記載されている。ＥＳＡ／３９０に基づくコンピュータ環境の一例が、In
ternational Business Machines Corporationが提供する9672 Parallel Enterpr
ise Serverである。

【００２３】 コンピュータ環境１００には、たとえば、１つまたは複数の中央処理装置１０
６（たとえばＣＰ１ないしＣＰ４）、１つまたは複数の論理区画１０８（たとえ
ば論理区画（ＬＰ１ないしＬＰ４））、および少なくとも１つの論理区画マネー
ジャ１１０を有する中央演算処理装置複合システム（ＣＰＣ）１０２が含まれる
。これらのそれぞれを、下で説明する。

【００２４】 中央処理装置１０６は、論理区画に割り振られる物理プロセッサ・リソースで
ある。具体的に言うと、各論理区画１０８は、１つまたは複数の論理プロセッサ
（図を明瞭にするために特に図示せず）を有し、この論理プロセッサのそれぞれ
が、その区画に割り振られた物理プロセッサである中央処理装置１０６のすべて
または共用部分を表す。特定の論理区画１０８の論理プロセッサは、その区画専
用（その結果、基礎になるプロセッサ・リソース１０６がその区画のために予約
される）とするか、別の区画と共用する（その結果、基礎になるプロセッサ・リ
ソースが、潜在的に別の区画から使用可能になる）のいずれかとすることができ
る。

【００２５】 図示の特定の例では、論理区画ＬＰ１ないしＬＰ４のそれぞれが、常駐するオ
ペレーティング・システム１１２（論理区画ごとに異なるものとすることができ
る）と１つまたは複数のアプリケーション１１４を有する別々のシステムとして
機能する。一実施形態では、オペレーティング・システム１１２は、Internatio
nal Business Machines Corporationが提供するＯＳ／３９０またはＭＶＳ／Ｅ
ＳＡオペレーティング・システムである。

【００２６】 さらに、各オペレーティング・システム（またはそのサブセット）には、区画
内および区画間でワークロードを管理するためのワークロード・マネージャ１１
６が含まれる。ワークロード・マネージャの一例が、International Business M
achines Corporationが提供するＷＬＭである。ＷＬＭは、たとえば、１９９５
年１２月５日発行の米国特許第５４７３７７３号明細書および１９９７年１０月
７日発行の米国特許第５６７５７３９号明細書に記載されている。

【００２７】 論理区画１０８は、プロセッサ１０６上で稼動するマイクロコードによって実
装される論理区画マネージャ１１０によって管理される。論理区画１０８（ＬＰ
１ないしＬＰ４）および論理区画マネージャ１１０のそれぞれには、中央処理装
置に関連する中央記憶装置のそれぞれの部分に常駐する１つまたは複数のプログ
ラムが含まれる。論理区画マネージャ１１０の一例が、ＰＲ／ＳＭである。

【００２８】 コンピュータ環境のもう１つの実施形態では、複数の中央演算処理装置複合シ
ステムが、図２に示されているように互いに結合されて、シスプレックスを形成
する。一例として、中央演算処理装置複合システム（ＣＰＣ）１０２は、たとえ
ば結合装置１２２を介して、１つまたは複数の他のＣＰＣ１２０に結合される。

【００２９】 図示の例では、ＣＰＣ１２０に、複数の論理区画１２４（たとえばＬＰ１ない
しＬＰ３）が含まれ、これらの論理区画は、論理区画マネージャ１２６によって
管理される。１つまたは複数の論理区画に、オペレーティング・システムが含ま
れ、この論理区画は、ワークロード・マネージャおよび１つまたは複数のアプリ
ケーション・プログラムを有することができる（図を明瞭にするためにこの例で
は図示せず）。さらに、ＣＰＣ１２０には、複数の中央処理装置１２８（たとえ
ばＣＰ１ないしＣＰ３）が含まれ、その中央処理装置のリソースは、複数の論理
区画の間で割り振られる。具体的に言うと、リソースは、各区画の１つまたは複
数の論理プロセッサ１３０の間で割り振られる（他の実施形態では、各ＣＰＣが
、１つまたは複数の論理区画と、１つまたは複数の中央処理装置を有することが
できる）。

【００３０】 結合装置１２２（別名、構造化外部ストレージ（ＳＥＳ）プロセッサ）は、中
央演算処理装置複合システムによってアクセス可能な記憶装置を含み、ＣＰＣ内
のプログラムによって要求される動作を実行する。結合装置は、共用リソース再
分配決定を行う際に使用される状態情報の共用のために本発明のさまざまな態様
によって使用される（一実施形態では、各中央演算処理装置複合システムが、複
数の結合装置に結合される）。結合装置の動作の諸態様は、１９９４年５月３１
日発行の米国特許第５３１７７３９号明細書、１９９６年１０月１日発行の米国
特許第５５６１８０９号明細書、および１９９８年１月６日発行の米国特許第５
７０６４３２号明細書、ならびにこれらの米国特許明細書で参照されている特許
および特許出願などの参考文献に詳細に記載されている。

【００３１】 一実施形態では、１つまたは複数の中央処理装置が、少なくとも１つのチャネ
ル・サブシステムに結合され、このチャネル・サブシステムは、入出力装置との
通信に使用される。たとえば、中央処理装置２００（図３）は、主記憶装置２０
２および少なくとも１つのチャネル・サブシステム２０４に結合される。チャネ
ル・サブシステム２０４は、さらに、１つまたは複数の制御装置２０６に結合さ
れる。制御装置は、１つまたは複数の入出力装置２０８に結合される。

【００３２】 チャネル・サブシステムは、入出力装置と主記憶装置の間の情報の流れを指示
する。チャネル・サブシステムは、中央処理装置を、入出力装置と直接に通信す
るという作業から解放し、入出力処理と並列にデータ処理を進行できるようにす
る。チャネル・サブシステムは、入出力装置２０８との間の情報の流れを管理す
る際の通信リンクとして、１つまたは複数のチャネル・パス２１４を使用する。

【００３３】 各チャネル・パス２１４には、たとえば、チャネル・サブシステム２０４のチ
ャネル２１０、制御装置２０６、およびチャネルと制御装置の間のリンク２１２
が含まれる。他の実施形態では、チャネル・パスが、複数のチャネル、制御装置
またはリンクを有することができる。さらに、もう１つの例では、チャネル・パ
スの一部として、１つまたは複数の動的交換機を有することも可能である。動的
交換機は、チャネルおよび制御装置に結合され、交換機に付加されるリンクの任
意の２つを物理的に相互接続する能力を提供する。チャネル・サブシステムに関
するさらなる詳細は、１９９６年６月１１日発行の米国特許第５５２６４８４号
明細書に記載されている。

【００３４】 本発明の好ましい実施形態では、さまざまな物理リソースが、１つまたは複数
のワークロード・マネージャの指示の下で、コンピュータ環境の論理区画の間で
動的に再分配される。この動的再分配は、アプリケーション・サブシステムにと
って透過的である。例として、再分配される物理リソースには、ＣＰＵリソース
、論理プロセッサ・リソース、入出力リソース、コプロセッサ、チャネル・リソ
ース、ネットワーク・アダプタ、およびメモリ・リソースが含まれる。一例とし
て、コプロセッサは、特定の機能をサービスする、ＣＰＣ内のマイクロプロセッ
サ（ＣＰＵ以外の）である。コプロセッサの例には、たとえば、チャネル・サブ
システム、ネットワーク・アダプタ・カード、および暗号コプロセッサが含まれ
る。上記の物理リソースは、例として提供されるものにすぎない。他の共用可能
リソースも再分配することができる。

【００３５】 リソースの動的再分配を容易にするために、一実施形態では、論理区画が、グ
ループの区画の間でリソースを共用するためにグループ化される。各グループの
サイズは、１区画からｎ区画まで変更できる。（一実施形態では、１つまたは複
数のグループに１つまたは複数の区画が含まれるが、コンピュータ環境のすべて
の区画よりは少ない。）具体的に言うと、各グループには、たとえば、計算機の
独立のドメインで稼動する１つまたは複数のオペレーティング・システム・イメ
ージが含まれ、これらのドメインは、ワークロードおよびリソースを分配するた
めに共通のワークロード・マネージャ機能によって管理される。一例では、これ
らのドメインは、論理分割モードで稼動する論理区画であり、オペレーティング
・システムは、論理区画内で稼動するＯＳ／３９０である。グループの論理区画
は、システム（たとえばＣＰＣ）もしくはシスプレックスの区画のサブセット、
システムもしくはシスプレックス全体、または、異なるシスプレックス（たとえ
ば単一のＣＰＣ上の）もしくは異なるシステムの区画とすることができる。

【００３６】 中央演算処理装置複合システムの２つの論理区画グループ（またはクラスタ）
の一実施形態を、図４に示す。図からわかるように、それぞれに１つまたは複数
の論理区画が含まれる、論理区画グループＡ３００および論理区画グループＢ３
０２がある。論理区画のグループ化によって、リソース割振り（たとえば、優先
順位に基づくリソース割振り）を介するグループの区画の間でのリソース共用が
可能になる。

【００３７】 例として、共用されるリソースには、ＣＰＵリソース、入出力リソース、およ
びメモリならびに、コプロセッサまたは他の、計算機が提供することのできる共
用可能リソースが含まれる。特定の論理区画グループは、特定の計算機のすべて
のリソースへのアクセス権を有する場合とそうでない場合がある。実際に、複数
の論理区画グループを、単一の計算機上で同時に動作するように定義することが
できる。各論理区画グループを効率的に管理するために、特定の論理区画グルー
プを構成するリソースは、効果的にそのグループにスコーピングされる。

【００３８】 スコーピングには、各グループに割振り可能であるリソースの識別が含まれる
。具体的に言うと、スコープによって、どのリソースがそのグループに制限され
、そのグループのために管理可能であるかが定義される。論理区画グループを構
成する論理区画は、リソースのコンテナとみなすことができる。これらのコンテ
ナは、論理区画から使用可能なリソースの総セットの境界内に存在する。一例で
は、これは、特定のＣＰＣ上で使用可能なリソースの総セットである。

【００３９】 特定の論理区画グループ（たとえば論理区画グループＡ）を構成する論理区画
には、共用可能な総リソースのうちの特定の部分が割り当てられる。たとえば、
共用可能リソースがＣＰＵリソースであると仮定する。共用ＣＰＵリソースにつ
いて、論理区画グループＡに含まれる論理区画には、中央演算処理装置複合シス
テムの総ＣＰＵリソースのうちの特定の部分が割り当てられる。これらのリソー
スは、特定のグループ内の論理区画ならびに、潜在的に、他の論理区画グループ
内の論理区画およびどの論理区画グループにも含まれない論理区画によって共用
されている。したがって、グループ内でのリソース移動（たとえば、論理区画グ
ループ内の１区画からそのグループ内の別の区画へ）に関する決定を行おうとす
るワークロード・マネージャは、グループを構成するリソースの理解ならびに、
より大きいコンテナ（たとえばＣＰＣ）に含まれるものの理解を有する必要があ
る。ワークロード・リソース管理に関する決定を行うのに使用される測定フィー
ドバック（たとえば、結合装置に記憶された状態情報）は、上記のように顧客が
定義したコンテナを理解するのに十分なものでなければならない。

【００４０】 この理解が確立された後に、ワークロード・マネージャが指示する、所与のグ
ループの論理区画でのリソース割振りに対する変更は、通常は、コンテナ・サイ
ズ（すなわち、論理区画グループに割り振られるリソース）を一定に保つ形で行
われる。たとえば、管理されるリソースがＣＰＵリソースであると仮定し、さら
に、各論理区画に、優先順位を示すＣＰＵ処理重みが割り当てられると仮定する
。ＣＰＵ相対重みを管理するために、所与のグループ内の論理区画の相対重みの
合計が、たとえばワークロード・マネージャを介する、指示された変更の前と後
で一定にならなければならない。これによって、顧客が指定した、グループおよ
び計算機上に存在する他の論理区画へのリソースの割振りが維持される。

【００４１】 上記にもかかわらず、いくつかの場合に、リソースが指定された所有者によっ
て使用されていない時に、区画のグループが、定義されたコンテナより多いリソ
ースを使用することが望ましく、可能である場合がある。しかし、リソースの競
合が発生すると同時に、リソースは、定義されたコンテナのサイズ（たとえば、
この例では処理重み）に従って、ＬＰＡＲマネージャによって管理される。しか
し、そのコンテナを超えてグループを拡張することを許可してはならない場合も
ありえる。これは、スコーピングに関してもありえる。他のリソースは、リソー
スの使用の正確なイメージを得るために、単一のグループに完全にスコーピング
される必要がある可能性がある。この形での制限によって、所与のグループの外
部の論理区画がそのリソースにアクセスできなくなる。

【００４２】 上記に加えて、論理区画グループ内のリソースの可用性に対する外部変更の影
響にも考慮を払う。たとえば、ユーザが、なんらかの外部手段を介して（ワーク
ロード・マネージャの指示の下ではなく）リソースの割振りを変更する可能性が
ある。これは、ある計算機での実際のワークロードの変化、またはグループ間も
しくは他の論理区画間のビジネス優先順位のシフトが原因で行われる可能性があ
る。これらの変更が行われる時には、これらの変更は、ワークロード・マネージ
ャによって理解されなければならず、これらの変更の影響は、合理的に分配され
なければならない。変更は、論理区画がグループに追加または除去される時、グ
ループの外部の他の論理区画が追加または除去される時、または、単に外部手段
を介して処理重みの変更が行われる時に、発生する可能性がある。これらの外部
変更が実行される時には、コンテナのサイズが変更される可能性があり、ワーク
ロード・マネージャは、その新しいサイズのコンテナのマネージャになる。

【００４３】 グループの特定の論理区画に属するリソースが外部から変更される時には、グ
ループ内のリソースの再分配が必要になる可能性がある。たとえば、論理区画が
グループから除去される時には、その論理区画に関連する処理重みが、そのグル
ープから除去される。その論理区画について現在ワークロード・マネージャが割
り当てている重みが、除去される論理区画の重み（すなわち、最初に論理区画に
関連する処理重み）より大きい場合には、これらの重みの間の差が、そのグルー
プ内の他の論理区画に追加される。これは、たとえば、グループ内の他の論理区
画での重みの既存の分配に比例して行われる。論理区画について現在ワークロー
ド・マネージャが割り当てている重みが、論理区画の初期重みより小さい場合に
は、これらの重みの間の差が、グループ内の他の論理区画から減算される。やは
り、これは、一例として、他の論理区画の重みの割り当てに比例して行われる。

【００４４】 上で説明したように、グループは、グループに割り当てられたリソースおよび
変更を許可されたリソースへのハンドルを得るためにスコーピングされ、その結
果、ワークロード・マネージャは、次に何を行うかに関して正しい決定を行える
ようになる。スコーピングによって、グループが識別され、プログラムが理解で
きる情報がプログラムに供給される。グループが変更される時には、リソースは
、その変更を満足するために動的に調整される。

【００４５】 一実施形態では、リソースごとに別々のグループ（クラスタ）を設けることが
できる。たとえば、論理区画グループＡをＣＰＵリソースに関するものとし、論
理区画グループＢを入出力リソースに関するものとすることができる。しかし、
他の実施形態では、１つの論理区画グループを、リソースのサブセットまたはす
べてに関するものとすることも可能である。

【００４６】 ＬＰＡＲグループ・スコープを確立するために、一例では、論理区画が、１つ
または複数の区画のグループに対してそれ自体を識別する。グループへの加入に
関連する論理の一実施形態を、図５を参照して説明する。たとえば、論理区画グ
ループに加入するために、論理区画で稼動するオペレーティング・システム（た
とえばＯＳ／３９０）は、その論理区画がその一部になろうとするＬＰＡＲグル
ープがどれであるかをＬＰＡＲマネージャに示す（ステップ４００）。一例とし
て、命令を使用して、ＬＰＡＲグループ名をＬＰＡＲマネージャに渡す。オペレ
ーティング・システムは、ＬＰＡＲグループ内で管理されるリソースのタイプご
とに名前を指定する。したがって、他のリソースがある場合には（問合せ４０２
）、他の名前を指定する。たとえば、あるグループ名が、ＣＰＵリソースについ
て与えられ、もう１つの名前が、入出力リソースについて与えられる。望むなら
ば、各リソース・タイプについて同一のＬＰＡＲグループ名を指定することがで
きる。

【００４７】 このＯＳ／３９０による宣言によって、計算機上で新しいＬＰＡＲグループが
確立される（論理区画がその名前を使用する最初の論理区画である場合）か、こ
の論理区画がそのリソース・タイプに関する同一の名前の既存のＬＰＡＲグルー
プに加入することになるかのいずれかになる。たとえば、グループ名が指定され
た（ステップ４０４）（図６）後に、それが新しい名前であるかどうかに関する
判定を行なう（問合せ４０６）。そうである場合には、新しいグループを作成す
る（ステップ４０８）。そうでない場合には、既存のグループに加入する（ステ
ップ４１０）。その後、リソースをグループにスコーピングする（ステップ４１
２）。

【００４８】 具体的に言うと、ＬＰＡＲグループにバインドされるグループ・タイプのリソ
ースは、ＬＰＡＲグループ内で稼動するＷＬＭがそうする必要があると判定した
場合に、その時に、その論理区画が使用するために使用可能にされる。スコーピ
ングを必要とするＬＰＡＲグループの特定のタイプのリソースには、少なくとも
２つの変形すなわち、追加リソースおよび固定リソースが含まれる。

【００４９】 追加リソース：いくつかの場合に、ＬＰＡＲグループへの加入によって、本質
的に、論理区画が加入したばかりのＬＰＡＲグループにリソースが追加される。
この一例が、ＣＰＵ処理重みであり、これは、たとえば、顧客によって、ハード
ウェア・コンソールで論理区画に割り当てられる。論理区画の現在の（使用中の
）処理重みは、論理区画が活動化される時に、この顧客が割り当てた重みから初
期設定される。論理区画がＣＰＵリソースに関するＬＰＡＲグループに加入する
時には、その論理区画に顧客が割り当てた処理重みが、ＬＰＡＲグループ内での
使用のために使用可能な総処理重みの一部になり、したがって、ＷＬＭによって
ＬＰＡＲグループ内で再割り当てすることが可能になる。ＬＰＡＲグループに加
入したばかりの論理区画は、寄与が行われたばかりのＬＰＡＲグループ・リソー
スのより大きい組を使用する潜在能力を有する。

【００５０】 固定リソース：いくつかの場合に、リソースの組が、特定のＬＰＡＲグループ
に属するものとして事前に定義される。この一例が、管理対象（浮動）チャネル
・パスである。管理対象チャネル・パスとは、ワークロード目標を達成するのを
助けるためにそのリソースを再割り当てすることができるチャネル・パスである
。特定のＬＰＡＲグループによる使用のための管理対象チャネル・パスの組は、
最初は、チャネル・パス（ＣＨＰＩＤ）をＬＰＡＲグループに関連付ける入出力
構成定義処理を介して定義される。論理区画は、このＬＰＡＲグループに加入す
る時に、このチャネル・パスの組へのアクセスを許可される。論理区画自体は、
このリソース・プールに全く寄与しない（このリソースのプールは、やはり動的
に変更することができるが、要点は、論理区画がＬＰＡＲグループに加入し、離
脱する際にリソースが論理区画と共に移動しないことである）。

【００５１】 ＬＰＡＲスコープも、リソースのタイプに応じてリソースに対して異なる形で
実施することができる。

【００５２】 追加リソース：ＬＰＡＲグループ内のオペレーティング・システムは、そのＬ
ＰＡＲグループのこのタイプのリソースの完全な組を問い合わせることができる
。一例として、ＣＰＵ処理重みの場合、これは、命令を介して達成される。オペ
レーティング・システムは、ＬＰＡＲグループ内のこのリソース・タイプの組全
体、グループ内の論理区画へのリソースの割振り、および現在の計算機上で使用
可能なリソース・プールの完全なサイズを知る。これらの構成要素のすべてが、
全物理リソースのうちのどれだけが論理区画に割り振られるかを理解するのに使
用される。その後、オペレーティング・システムは、ＬＰＡＲグループ内の論理
区画への割振りを更新して、グループ内のリソースを再割当てする。オペレーテ
ィング・システムは、一例では、ＬＰＡＲグループに割り振られるリソースの総
量を変更することを許可されない。ＬＰＡＲマネージャは、ＬＰＡＲグループの
すべての部分が、更新で考慮され、ＬＰＡＲグループの外部の論理区画がそのリ
ソースに影響を受けないようにすることによって、これを実施する。

【００５３】 固定リソース：ＬＰＡＲグループ内のオペレーティング・システムは、このタ
イプのリソースについて、そのＬＰＡＲグループに関連するリソースの組を問い
合わせる。たとえば、管理対象チャネル・パスについて、特定のＬＰＡＲグルー
プについて定義された管理対象チャネル・パスのリストを、命令を介してＬＰＡ
Ｒマネージャから取り出すことができる。ＬＰＡＲマネージャは、これらのリソ
ースのスクリーニングも行って、これらが正しいＬＰＡＲグループによってのみ
使用されるようにする。管理対象チャネルの場合、これは、管理対象チャネル・
パスを、その管理対象チャネル・パスについて定義された名前と一致するＬＰＡ
Ｒグループ名を宣言した論理区画に対してオンラインに構成することだけが許可
されることを意味する。

【００５４】 ＬＰＡＲグループの一部である論理区画が、システム・リセット、再ＩＰＬ、
または非活動化される時には、その論理区画が１つまたは複数のＬＰＡＲグルー
プに関して有した所属のすべてが除去される。グループからの論理区画の除去に
関連する論理の一実施形態を、図７を参照して説明する。リセットの一部として
、論理区画マネージャは、宣言されたＬＰＡＲ区画グループ名を論理区画から除
去する（ステップ５００）。次に、リソースに応じて（問合せ５０２）、その論
理区画のＬＰＡＲグループ・リソース割振り解除を完了するための１つまたは複
数の他の処置を実行する。

【００５５】 リソースが追加リソースの場合には、以下が行われる。このような、論理区画
がＬＰＡＲグループに加入した時にＬＰＡＲグループに追加されたリソースは、
ＬＰＡＲグループから除去される（ステップ５０４）。これには、このタイプの
リソースの、ＬＰＡＲグループの残りのメンバへの現在の割振りの調整が含まれ
る場合がある。たとえば、処理重みの場合、グループを離脱する論理区画の初期
処理重みが、ＬＰＡＲグループのスコープから除去される。ＷＬＭが、論理区画
の現在の処理重みを変更している場合には、調整を行う必要がある。論理区画の
現在の処理重みが、その初期処理重みより大きい場合には、この２つの間の差が
、残りのＬＰＡＲグループ・メンバに、その現在の処理重みに比例して再分配さ
れる。論理区画の現在の処理重みが、その初期処理重みより小さい場合には、こ
の２つの間の差が、残りのＬＰＡＲグループ・メンバから、その現在の処理重み
に比例して除去される。この調整の結果として、結果のＬＰＡＲグループに対す
る処理重みコンテナの内容が再確立される。

【００５６】 その一方で、リソースが固定リソースの場合には、以下が行われる。このよう
なリソースは、リセットされる論理区画の構成から単純に除去される（ステップ
５０６）。たとえば、管理対象チャネル・パスの場合、チャネル・パスは、リセ
ットされる論理区画から構成解除される。これによって、ＬＰＡＲグループのメ
ンバだけが、ＬＰＡＲグループのリソースにアクセスできることが、もう一度再
確立される。

【００５７】 ＬＰＡＲグループ環境内のＷＬＭによって管理されるリソースの一部が、グル
ープ・スコーピングの必要を有しない場合があることにも留意されたい。そのよ
うなリソースの一例が、論理区画のためにオンラインになる論理中央処理装置（
ＣＰ）の数である。ＬＰＡＲグループ内の特定の論理区画の効果的な挙動は、そ
の論理区画に対してオンラインである論理ＣＰの数によって大きく影響される可
能性がある。論理区画が定義することのできるまたはオンラインである論理ＣＰ
の数は、その論理区画がＬＰＡＲグループに含まれるか否かに無関係に論理区画
の特性であり、したがって、このリソースは、実際にはリソースのより大きいプ
ールの一部にはならない。しかし、ＬＰＡＲグループでのその効果は、それによ
って、別のＬＰＡＲグループ・メンバに対してあるＬＰＡＲグループ・メンバ内
で効果的に動作させることができるワークロードのタイプを変更できることであ
る。

【００５８】 一例では、複数の論理区画の間で共用されるリソースが、ＣＰＵリソースであ
る。ＯＳ／３９０ワークロード・マネージャは、論理区画に関連する１つまたは
複数の相対プロセッサ重みを動的に調整することによって、論理区画の間でＣＰ
Ｕリソースを再分配する。ＷＬＭは、重要なワークロードが稼動する区画の重み
が低すぎるので重要なワークロードが遅延される時を理解する。ＷＬＭは、この
区画の重みを引き上げ、別の区画の重みを引き下げることによってこのワークロ
ードを助けることができ、これによって、追加のＣＰＵ容量が重要なワークロー
ドに与えられる。ＣＰＵリソースは、ワークロード要件が変化する際に、必要な
区画に動的に移動される。

【００５９】 一実施形態では、論理区画重みのＷＬＭ管理のスコープが、論理区画グループ
である。一例として、ＷＬＭは、論理区画重みを調整するが、グループ内の区画
の重みの合計を一定に維持する。合計を一定に維持することによって、グループ
に割り振られる総ＣＰＵリソースが、同一の物理コンピュータ上の他の独立のグ
ループに対して相対的に同一に保たれる。したがって、ＷＬＭは、ある区画の重
みを引き上げる時に、同一のグループ内の別の区画の重みを下げる。

【００６０】 論理区画重みの管理は、ＷＬＭの目標指向リソース割振り技法に対する機能強
化であり、これは、たとえば、１９９５年１２月５日発行の米国特許第５４７３
７７３号明細書および１９９７年１０月７日発行の米国特許第５６７５７３９号
明細書に記載されている。

【００６１】 上記の特許明細書に記載されているように、ＷＬＭは、ＣＰＵディスパッチ優
先順位を調整することによって、論理区画内のＣＰＵリソースの割振りを制御す
る。ＣＰＵディスパッチ優先順位は、サービス・クラス・レベルで作業に割り当
てられる。しかし、ディスパッチ優先順位の調整がサービス・クラスを助けない
、さまざまな状況がある。たとえば、 １）サービス・クラスが、単独で、すでに非システム作業に許可される最高の
ＣＰＵディスパッチ優先順位である。 ２）サービス・クラスを助けるためのＣＰＵディスパッチ優先順位の変更が、
それ以上の重要性を有する他のサービス・クラスに及ぼす負の影響が大きすぎる
。

【００６２】 したがって、ＷＬＭは、サービス・クラスが、ＣＰＵ遅延に起因してその目標
を失いつつあり、それをＣＰＵ優先順位の調節によって助けることができないこ
とを見つけた時に、ＷＬＭは、失敗しつつあるサービス・クラスに関連する区画
の重みの調節を検討する。

【００６３】 ＷＬＭが追加リソースの割振りを検討するサービス・クラスを、レシーバ・サ
ービス・クラスと呼ぶ。ＷＬＭは、上に示した理由のどれかのために助けること
ができない、所与の区画でのＣＰＵ遅延に起因して目標を失いつつあるレシーバ
・サービス・クラスを見つけた時に、ＷＬＭは、その区画の重みを引き上げるこ
とを検討する。レシーバ・サービス・クラスを助けるために区画の重みを引き上
げることができるかどうかを判定するためにＷＬＭが従う論理の一実施形態を、
図８を参照して下で説明する。

【００６４】 １．区画の重みを増やすことがレシーバ・クラスに及ぼす影響を見積もる（ス
テップ６００）。区画の重みを増やすと、その区画のＣＰＵ容量が増える。レシ
ーバ・クラスでの作業のＣＰＵ需要は、一定と仮定されるので、区画のＣＰＵ容
量を増やすと、レシーバ・サービス・クラスが必要とする、この容量の百分率が
減る。レシーバ・サービス・クラスに対する利益の見積もりは、レシーバ・サー
ビス・クラスと、システム需要に対する他の作業の両方の、使用可能なＣＰＵ容
量の百分率のこの減少に基づく。

【００６５】 ２．その重みを減らされる候補になる、論理区画グループ内の別の区画を見つ
ける（ステップ６０２）。この区画を、候補ドナー区画と称する。候補ドナー区
画は、たとえば、区画の重みを下げることによって、最も重要さの少ない作業が
影響を受ける可能性が高い区画を探すことによって、選択される。

【００６６】 ３．その重みを下げられる候補ドナー区画で稼動する作業を有するすべてのサ
ービス・クラスに対する影響を見積もる（ステップ６０４）。候補ドナー区画の
重みを減らすことによって、候補ドナー区画のＣＰＵ容量が減る。このＣＰＵ容
量の減少は、候補ドナーの容量の百分率としての、候補ドナーで稼動する作業を
有するサービス・クラスのＣＰＵ需要が増えることを意味する。候補ドナーの重
みを減らすことの負の影響の見積もりは、これらのサービス・クラスが必要とす
る使用可能ＣＰＵ容量の百分率のこの減少に基づく。

【００６７】 ４．この重みの変更が正味の値を有するかどうかを判定する（問合せ６０６）
。すなわち、レシーバ・サービス・クラスに対する利益が、候補ドナー区画の作
業に対する負の影響を上回るかどうかを、関係するサービス・クラスの目標およ
び重要性に基づいて判定する。

【００６８】 ５．重みの調節が正味の値を有する場合には、提案された区画の重みに対する
変更を実施する（ステップ６０８）。正味の値がない場合には、ほかに候補ドナ
ー区画があるかどうかに関する判定を行う（問合せ６１０）。そうである場合に
は、もう１つの候補ドナー区画を選択し（ステップ６１２）、処理はステップ３
（ステップ６０４）で続行する。ほかに候補ドナー区画がない場合には、処理を
終了する（ステップ６１４）。

【００６９】 ある区画で稼動するＷＬＭが、別の区画で稼動する作業に対する区画重み変更
の効果の見積もりを行えるようにするために、各区画は、グループ内の各論理区
画に関する性能データを含む共用データ構造へのアクセス権を有する。この区画
レベルの性能データには、たとえば以下が含まれる。 ・サービス・クラスによって区画で実行される作業のＣＰＵ要件 ・各サービス・クラスが、その目標に向かってその区画上でどの程度良好に動
作しているか ・区画のＣＰＵディスパッチ優先順位によるＣＰＵ使用量

【００７０】 ＯＳ／３９０システムに実装した本発明の好ましい実施形態では、この共用デ
ータ構造が、結合装置内で作成され、維持される。しかし、メッセージ交換また
は共用ディスクなどの他のデータ共用手法を使用して、このデータ構造を実装す
ることができる。

【００７１】 上で説明したのは、コンピュータ環境のＣＰＵリソースを動的に再分配する能
力である。リソースは、一例として、論理区画重みを動的に調整することによっ
て、論理区画の間で再分配される。

【００７２】 コンピュータ環境のＣＰＵリソースの動的調整のほかに、本発明のもう１つの
態様では、論理プロセッサ・リソースも動的に調整することができる。

【００７３】 論理区画は、１つまたは複数の論理プロセッサと共に構成され、それらの論理
プロセッサは、中央演算処理装置複合システムの物理中央処理装置上で、作業を
実行するためにディスパッチされる。区画がそれに割り当てられたＣＰＵ容量を
消費できるようにするために、十分な論理プロセッサを論理区画に構成しなけれ
ばならない。たとえば、１０個のＣＰＵを有するＣＰＣ上で稼動する論理区画Ａ
の場合を検討する。ワークロード・マネージャが、論理区画ＡにＣＰＣの容量の
５０％を割り当てる場合、論理区画Ａは、少なくとも５つの論理プロセッサをそ
れに構成されることを必要とする（５つの論理プロセッサは、ＣＰＵのうちの５
つすなわちＣＰＣの容量の５０％で稼動することができる）。論理区画Ａに、そ
の後、ＣＰＣの容量の９５％が割り当てられた場合、論理区画Ａは、１０個の論
理プロセッサを有するように構成されるはずである。ＷＬＭは、静的に定義され
た論理プロセッサ構成を用いて論理区画Ａに割り当てられた容量を動的に調整す
ることができるので、すべての可能な容量割当てを収めるために、１０個の論理
プロセッサが論理区画Ａに構成される。しかし、論理区画Ａに、たとえばＣＰＣ
の容量の２０％だけが割り当てられる場合には、静的に定義された論理プロセッ
サから次の２つ問題が生じる。１）１０個の論理プロセッサのそれぞれが、平均
して、物理ＣＰＵの容量の０．２の比率で物理ＣＰＵリソースを消費することし
かできない（１０個のＣＰＵの２０％を１０個の論理プロセッサによって分割す
ると、１論理プロセッサあたり０．２ＣＰＵになる）。これは、スループットが
単一のタスクによってゲーティングされるワークロードを厳しく制限する可能性
がある。というのは、その単一のタスクを、物理ＣＰＵの容量の０．２倍で実行
することしかできなくなるからである。これは、ショート・エンジン効果と呼ば
れることがある。２）２つの論理プロセッサだけが必要な時に１０個の論理プロ
セッサを管理しなければならない時に、ソフトウェアおよびハードウェアの効率
が大きく低下する。

【００７４】 上記の欠陥に対処するために、論理区画の構成は、本発明の一態様によれば、
静的に定義されるのではなく、動的に調整される。一例では、区画を管理し、動
的調整を行うのは、ＷＬＭである。ＷＬＭは、コンピュータ環境（またはＬＰＡ
Ｒグループ内）の各論理区画についてこれを行うことができる。論理プロセッサ
の構成の動的調整に関連する論理の一実施形態を、図９を参照して説明する。

【００７５】 最初、論理区画を、ワークロード・マネージャによって論理区画に割り当てら
れた容量（または、実際に使用されている容量の方が大きい場合にはその容量）
を消費できるようにするのに必要な最小の個数の論理プロセッサを用いて構成す
る（ステップ７００）。論理区画の容量割り当て（または容量使用量）が変化す
る際に（問合せ７０２）、評価を行って、論理区画に構成される論理プロセッサ
の数を変更しなければならないかどうかを判定する（ステップ７０４）。一例で
は、論理区画に構成される論理プロセッサの数は、論理区画に割り当てられた（
または論理区画によって消費される）ＣＰＣ容量を提供するのに必要な物理ＣＰ
Ｕの数に近いままになる。したがって、各論理プロセッサは、物理ＣＰＵの容量
に近い状態で実行され、管理される論理プロセッサの数が、最小になる。

【００７６】 論理構成を変更するかどうかの評価を行うために、一例では次の式を使用する
。 Ｌ＝floor［max（Ｗ，Ｕ）×Ｐ＋１．５］（ただし、Ｌの最大値＝Ｐ） ここで、Ｌ＝論理区画に構成される論理プロセッサの数、Ｗ＝論理区画に割り
当てられるＣＰＣ容量の百分率、Ｕ＝論理区画によって現在使用されているＣＰ
Ｃ容量の百分率、Ｐ＝ＣＰＣ上の物理ＣＰＵの数である（ステップ７０５）。

【００７７】 Ｌは、たとえば定期的で頻繁なインターバル（たとえば１０秒ごと）に、Ｐ、
Ｗ、およびＵの現在の値に基づいて、ワークロード・マネージャによって評価さ
れる。閾値を使用して、論理区画のＬの実際の値（Ｌ−ａｃｔ）を上げるか下げ
るかしなければならないかどうかを判定する。新たに計算されたＬの値（Ｌ−ｃ
ａｌｃ）が、Ｌ−ａｃｔの現在の値より高い場合（問合せ７０６）、Ｌ−ａｃｔ
をＬ−ｃａｌｃまで引き上げる（ステップ７０８）。そうでない場合に、Ｌ−ｃ
ａｌｃがＬ−ａｃｔより２つ以上小さい値である場合（問合せ７１０）、Ｌ−ａ
ｃｔにＬ−ｃａｌｃ−１をセットする（ステップ７１２）。Ｌ−ｃａｌｃが、Ｌ
−ａｃｔと等しいか、Ｌ−ａｃｔより１つだけ小さい場合には、論理区画のＬ−
ａｃｔの値の変更は行われない（ステップ７１４）。これらの閾値の使用を介し
て、ワークロードのすばやく高まる容量需要に応答しながらも、小さいワークロ
ード変動に起因するＬ−ａｃｔの無用な変更が回避される。

【００７８】 もう１つの例示として、次の例を検討する。Ｐ＝１０、Ｗ＝Ｕ＝２４％と仮定
する。論理プロセッサの静的構成では、Ｗが９０％を超えて増加する場合を扱う
ために、Ｌ（静的）＝１０が必要になろう。しかし、本発明の好ましい実施形態
によれば、Ｌ（動的）＝floor［max（．２４，．２４）×１０＋１．５］＝３で
ある。したがって、この例では、Ｌ（静的）では、単一のタスクが物理ＣＰＵの
０．２４で実行されるように制約されるが、Ｌ（動的）では、単一のタスクが、
物理ＣＰＵの０．８０で実行されることが可能であり、これによって、単一タス
ク性能によってゲーティングされるワークロードのスループットの２３３％の向
上がもたらされる。さらに、この例では、Ｌ（静的）に必要な１０個の論理プロ
セッサではなく、３つの論理プロセッサだけが管理されるので、ソフトウェアお
よびハードウェアの効率が大幅に改善される。

【００７９】 コンピュータ環境の、管理されるもう１つの共用可能リソースは、入出力リソ
ースなどの非同期リソースである。具体的に言うと、コプロセッサ（たとえばチ
ャネル・サブシステム）内の入出力動作または入出力要求が管理される。この管
理には、優先順位の高い入出力動作がすばやく処理される、優先順位の高い入出
力動作がチャネルのより多くの帯域幅を割り当てられる、などの入出力動作の優
先順位付けが含まれる。

【００８０】 現在の大規模多重プログラミング・コンピュータ・システムでは、付加された
入出力装置の読取、書込、および制御のための入出力動作などの長時間稼動する
処理の開始および実行は、通常は、複数の独立に動作する計算要素（図１０参照
）の使用によって達成される。たとえば、中央処理装置８００内で実行中のプロ
グラムは、付加された装置８０４との入出力動作を要求することができる。しか
し、付加された装置との入出力動作の実際の開始および実行は、通常はチャネル
・サブシステム８０２と呼ばれる、１つまたは複数の別々に独立して実行する協
働プロセッサによって実行される。一般に、非同期入出力処理方法は、比較的長
時間稼動する入出力装置の実行と並列に他の作業のために中央処理装置を最適化
し効率的に使用するために使用される。すなわち、そうしなければ付加された入
出力装置にアクセスし、読み書きするために必要になるはずの総プロセッサ・オ
ーバーヘッド、処理時間、およびプロセッサ待ち時間を最小にするためである。
そのような方法は、大規模多重プログラミング・システムで他のプロセッサ作業
の実行と入出力動作との、最大のオーバーラップまたは実行の並列性を達成する
ように設計される。

【００８１】 そのような非同期入出力処理システムでは、中央処理装置が、Ｓ／３９０ Ｓ
ＴＡＲＴ ＳＵＢＣＨＡＮＮＥＬ命令などの入出力命令の使用によってプログラ
ムが要求した入出力動作の実行を開始する。そのような命令は、通常は、次の２
つの責任を負う。 １．チャネル・サブシステムの入出力作業キューに入出力動作要求をエンキュ
ー（追加）し、 ２．入出力作業キューを処理するために非同期に実行中のチャネル・サブシス
テムにシグナルを送る。

【００８２】 その後、中央処理装置は、他の作業／命令を実行することができ、入出力装置
との要求された入出力動作の実際の実行に直接にはかかわらない。

【００８３】 １）上の処理の非同期な性質、２）中央処理装置とチャネル・サブシステム・
プロセッサの独立動作、３）中央処理装置の実行速度と比較して相対的に長い、
入出力動作の実行時間、および４）装置をチャネル・サブシステムに接続するチ
ャネル・パスなどのチャネル・サブシステム・リソースの一部またはすべてが、
入出力動作がプログラムによって要求された時に他の動作の実行で使用中である
可能性があるという事実に起因して、複数の入出力要求が、チャネル・サブシス
テム入出力作業キューに同時にエンキューされる可能性が非常に高い。すなわち
、ＳＴＡＲＴ ＳＵＢＣＨＡＮＮＥＬ命令は、チャネル・サブシステムが要求さ
れた入出力動作を実行する能力より高い速度で中央処理装置によって実行され、
これによって、保留入出力動作要求のＮレベルの深さの入出力作業キューが継続
的に引き起こされる。

【００８４】 保留入出力要求を処理するために、チャネル・サブシステムを構成するマイク
ロプロセッサは、それぞれの入出力作業キューを検査し（図１０参照）、１つま
たは複数の入出力要求をこれらのキューからデキューし、それぞれの入出力装置
に関するデキューされた入出力要求の開始を試みる。この活動の発端は、チャネ
ル・サブシステム内の問題のマイクロプロセッサおよび作業キューに応じて変化
する。たとえば、中央処理装置と対話するチャネル・サブシステム入出力プロセ
ッサは、他の作業の実行に使用中でない時に周期的に、１つまたは複数の中央処
理装置ＳＴＡＲＴ ＳＵＢＣＨＡＮＮＥＬ信号の結果として、または両方の組合
せの結果として、この処理を開始するかも知れない。

【００８５】 チャネル・サブシステムのさまざまな作業キューの一例を、図１０を参照して
説明する。前に述べたように、入出力要求は、たとえばＳＴＡＲＴ ＳＵＢＣＨ
ＡＮＮＥＬ命令によって、入出力プロセッサ作業キュー８０６にエンキューされ
る。その後、入出力要求は、入出力プロセッサ８０８によって、入出力プロセッ
サ作業キューからデキューされる。入出力プロセッサ作業キューからデキューさ
れた要求は、入出力プロセッサによって、チャネル・プロセッサ作業キュー８１
０にエンキューされる。その後、これらの要求は、チャネル・プロセッサ８１２
によってデキューされ、制御装置作業キュー８１４にエンキューされる。チャネ
ル・プロセッサは、制御装置作業キューから要求をデキューして、チャネル・パ
スを介して制御装置へ、最終的には入出力装置へ送る。

【００８６】 現在、Ｓ／３９０プロダクト・ファミリーのシステム内では、チャネル・サブ
システムのデキュー処理および作業初期設定処理は、先入れ先出し法（ＦＩＦＯ
）に基づいて実行される。この処理は、論理的に実施が最も単純であり、スルー
プットの最適化を目的とし、過去には、保留作業キューの平均深さが比較的浅く
、入出力作業保留時間が比較的短い持続時間にとどまる（すなわち、さまざまな
入出力作業キューの保留入出力要求の平均数が、重要性の高いプログラムまたは
実時間依存型プログラムに関連する入出力動作の総入出力応答時間を大幅に引き
延ばさない）ならば、さまざまな非同期処理要素の間の作業転送のために許容さ
れる戦略であった。

【００８７】 しかし、クリティカルな作業または時間依存の作業の適時な処理に関するユー
ザの需要をサポートするためにアプリケーション／プログラム優先順位付け機能
を提供するオペレーティング・システムでは、保留入出力要求に関するＦＩＦＯ
処理戦略は、ＦＩＦＯ作業キューの平均深さが増えるにつれて、ますます許容さ
れなくなる。たとえば、ＩＢＭ Enterprise Storage Serverと共に使用される並
列アクセス・ボリュームでは、チャネル・サブシステムの平均キュー深さが増え
る。これは、通常は、重要性が低いか時間依存型でない入出力要求が、ＦＩＦＯ
作業キュー上でより重要な要求の前にキューに置かれる可能性があり、したがっ
て、よりクリティカルな入出力要求の前に開始されることになるという事実に起
因する。頻繁に、クリティカルでない作業は、長時間にわたってリソースを束縛
する入出力を実行し、より重要な作業が遭遇する遅延が増える。これは、通常は
、より重要な入出力要求の遅延の可能性が高まることをもたらす。

【００８８】 入出力保留時間とも称する遅延時間（総リアルタイム遅延または中央処理装置
の速度と比較した時の相対時間遅れのいずれかとすることができる）の増加は、
チャネル・サブシステムおよび付加された装置が、クリティカルな入出力要求の
適時の完了に影響しない入出力実行の速度を維持する能力がないこと（言い換え
ると、重要性の高いプログラムまたは時間依存型プログラムの実行時間の許容不
能な延長をもたらさない実行速度を維持する能力がないこと）に起因することが
しばしばである。上で述べたように、クリティカルな入出力要求に関する総入出
力応答時間の許容不能な延長の確率は、ＦＩＦＯ作業処理方法が使用される時に
、一般に高まる。この遅延の確率は、中央処理装置の速度および数が、付加され
る入出力装置および、装置が付加されるチャネル・パスなどの他の必要なチャネ
ル・サブシステム要素の速度の向上より高い割合で向上する際に、さらに大きく
なる。一般に、入出力速度の向上の割合に対する中央処理装置の速度の向上の割
合の不一致は、現在の大規模システム環境で増大を続け、その結果、クリティカ
ルな作業のキューイング遅延およびより大きい入出力応答時間（リアルタイムま
たは相対時間のいずれか）の確率がますます高まる。

【００８９】 例として、チャネル・サブシステムでのキューイング遅延に起因する、重要性
の高い入出力動作および時間依存型入出力動作の長い入出力応答時間の頻度を最
小にするために、優先順位処理技法を定義して、１つまたは複数のチャネル・サ
ブシステム保留入出力作業キューを処理する。

【００９０】 ２つの独立に実行されるプロセッサまたはプロセスの間の優先順位処理技法の
実施の例には、以下が含まれる。 １．エンキュー・プロセッサ（またはプロセス）が、プログラム指定の（たと
えばＷＬＭによる）優先順位番号に基づく優先順位シーケンシング技法を使用し
て、チャネル・サブシステム入出力作業キュー（処理の段階に依存する特定のキ
ュー）に入出力要求を追加する。チャネル・サブシステムは、その後、ＦＩＦＩ
技法を使用して、作業キューから最初の最も優先順位の高い入出力要求を除去す
る。または、 ２．エンキュー・プロセッサ（またはプロセス）が、ＦＩＦＯエンキュー技法
を使用して、入出力作業キューの最下部に入出力要求を追加する。チャネル・サ
ブシステムは、優先順位選択技法を使用して、その後、作業キューのすべての入
出力要求要素を探索し、最も高いプログラム指定の優先順位番号を有する入出力
要求を除去し、処理する。

【００９１】 ＦＩＦＯエンキュー技法（技法２）では、必要な命令が少なく、したがって、
中央処理装置が、入出力要求スケジューリング処理をよりすばやく完了すること
ができる。これによって、中央処理装置は、よりすばやく他の作業を実行できる
ようになる。チャネル・サブシステムを構成するさまざまなマイクロプロセッサ
の間のエンキュー／デキュー処理について、選択すべき技法は、通常は、参加す
るプロセッサのどれが、その処理容量および適時性の要件に関して最も制約され
るかに依存する。すなわち、エンキュー・プロセッサが最も制約される場合には
、第２の技法を選択する。デキュー・プロセッサが最も制約される場合には、通
常は第１の技法を選択する。

【００９２】 これらの技法のどちらを使用するかに無関係に、その結果は、チャネル・サブ
システムが、到着時刻またはＦＩＦＯ方法ではなく、優先順位付け方法に基づく
保留入出力要求の開始および実行を優先することである。

【００９３】 さらに、一実施形態では、使用されるエンキュー技法および選択技法に無関係
に、処理される要求の優先順位付けや選択に、さまざまな判断基準が使用される
。一例では、この判断基準に以下が含まれる。

【００９４】 １．各異なる番号が独自の優先順位レベルに対応する、プログラム指定の優先
順位番号に基づく保留入出力要求の選択。たとえば、連続する独自の番号の範囲
を設け、数の範囲全体が、優先順位の区別を必要とする別個の作業カテゴリの総
数以上になるようにする。たとえば、システムが、通常のＳ／３９０システムで
可能であるように、Ｎ個の異なるオペレーティング・システムを同時に実行する
能力を有する場合には、チャネル・サブシステム優先順位技法は、Ｎ個以上の別
個の優先順位レベルを提供しなければならない。最低のレベルから最高のレベル
までまたはその逆の各優先順位レベルは、０からＮ−１までの範囲の独自の数に
よって表されるはずである。

【００９５】 ２．優先順位に無関係にすべてのエンキューされた要求に「フェアネス」も適
用する技法を使用する、保留入出力要求の優先順位選択。これは、通常は、たと
えば、長時間にわたってチャネル・サブシステムに不相応に多数の高い優先順位
の要求が提示されることに起因して発生する可能性がある、低い優先順位の要求
が長時間にわたって処理されない確率を最低にするために所望される。フェアネ
ス選択は、他の考慮点に応じて、同一の優先順位の保留要求に適用することもで
きる。たとえば、まだ選択されていない他の同一優先順位の要求と共に、すでに
デキューされ、開始に失敗し、複数回再キューイングされた保留要求にフェアネ
スを提供することである。このような技法を、図１１を参照して説明する。この
技法では、保留要求の複数の異なるカテゴリに、優先順位とフェアネスの両方を
適用する。

【００９６】 ３．下記に関する外部ユーザ／オペレータの制御 １．優先順位処理技法のグローバルな使用可能化／使用不能化。この制御は
、優先順位技法が不要であるか、非類型的なプログラム実行環境に適当に対応す
ることができない場合に、保留要求のＦＩＦＯ処理を強制するために必要になる
場合がある。 ２．複数の論理区画の並列実行を提供するシステムの場合の、所与の論理区
画に関連する入出力要求の「デフォルト」優先順位値をユーザが指定できるよう
にする外部制御。これは、論理区画内で実行中のオペレーティング・システムが
、その入出力要求の優先順位値を指定するように設計されていないが、それでも
、入出力優先順位付けを指定する他の論理区画内で実行中の他のオペレーティン
グ・システムと成功裡に競合しなければならない時に使用される。 ３．複数の論理区画の並列実行を提供するシステムの場合の、チャネル・サ
ブシステムによって供給される値の組全体からの、各論理区画の優先順位値のサ
ブセット最小最大範囲をユーザが指定できるようにするための外部制御。この制
御は、別々の論理区画内で実行中の複数のオペレーティング・システムが、入出
力優先順位を独立に、それを使用する他の区画の知識なしに使用する時に使用さ
れる。すなわち、各使用する区画によって開始される要求の優先順位に基づく分
離を可能にするための制御である。

【００９７】 上の項目３．２および３．３について、一実施形態では、中央処理装置が、論
理区画内で実行中のプログラムのユーザ指定のデフォルト優先順位値またはユー
ザ指定の最大／最小許容優先順位を、その区画で動作するプログラムに透過的な
形で、暗黙のうちに割り当てる。Ｓ／３９０システムでは、これは、論理区画マ
ネージャ（ハイパーバイザ）および中央処理装置のＳＴＡＲＴ ＳＵＢＣＨＡＮ
ＮＥＬ命令によって共同で達成することができる。

【００９８】 論理区画内で動作するプログラムが、入出力動作を開始するためにＳＴＡＲＴ
ＳＵＢＣＨＡＮＮＥＬを実行する時には、中央処理装置でのＳＴＡＲＴ ＳＵ
ＢＣＨＡＮＮＥＬ命令の解釈実行で、暗黙のうちに、解釈実行開始（ＳＩＥ）状
態記述（ＳＤ）テーブルから、デフォルト優先順位番号および最小／最大許容優
先順位番号の両方が獲得される。このテーブルは、論理区画ハイパーバイザが区
画を実行状態にするためにＳＩＥ命令を実行する時に、その論理区画ハイパーバ
イザによって、中央処理装置内に作成され、ロードされる。その後、ＳＴＡＲＴ
ＳＵＢＣＨＡＮＮＥＬの解釈実行では、ＳＩＥ状態記述テーブルのデフォルト
優先順位値および最小／最大優先順位値を使用して、論理区画内で動作するプロ
グラムによる関与なしで、適当な優先順位値を入出力要求に暗黙のうちにセット
する。

【００９９】 優先順位値が、論理区画内で実行中のプログラムによって指定されない時には
、ＳＴＡＲＴ ＳＵＢＣＨＡＮＮＥＬの解釈で、ユーザ指定のデフォルト優先順
位値が入出力要求に割り当てられる。論理区画内で実行中のプログラムが、ＳＴ
ＡＲＴ ＳＵＢＣＨＡＮＮＥＬを実行する時に優先順位番号を指定する時には、
ＳＴＡＲＴ ＳＵＢＣＨＡＮＮＥＬの解釈実行で、プログラム指定の優先順位値
を、状態記述テーブル内のハイパーバイザ指定の最小／最大優先順位値と比較す
る。プログラム指定の優先順位が、ハイパーバイザ指定の最小値より小さい時に
は、状態記述テーブルからの最小値によって、暗黙のうちにプログラム指定の値
を置換する。プログラム指定の優先順位値が、ハイパーバイザ指定の最大優先順
位を超える時には、状態記述テーブルからの最大優先順位値によって、プログラ
ム指定の値を置換する。

【０１００】 上記の判断基準のうちの０個以上を使用して、優先順位選択技法を導出するこ
とができる。上記の判断基準の少なくともいくつかを使用する、処理される要求
を選択するための技法の一実施形態を、図１１を参照して説明する。

【０１０１】 最初、保留作業キューにアクセスする（ステップ９００）。たとえば、入出力
プロセッサ作業キュー、チャネル・プロセッサ作業キュー、または制御装置作業
キューのいずれかにアクセスする。その後、デキューされた保留要求のカウント
を１つ増分する（たとえば、ＤＱＣＯＵＮＴ＝ＤＱＣＯＵＮＴ＋１）（ステップ
９０２）。

【０１０２】 その後、保留要求のどのカテゴリを処理するかに関する判定を行う（ステップ
９０４）。一例では、選択されるカテゴリは、（ＤＱＣｏｕｎｔ ＭＯＤＵＬＵ
Ｓ カテゴリ数）に等しい。したがって、この例では４つのカテゴリがあるので
、選択されるカテゴリは、ＤＱＣｏｕｎｔ ＭＯＤＵＬＵＳ ４に等しい。結果
が０の場合には、任意の優先順位の最初の要求をデキューする（ステップ９０６
）。しかし、選択されるカテゴリが１の場合には、前にデキューされていない最
高優先順位の最初の要求を選択する（ステップ９０８）。さらに、選択されるカ
テゴリが２の場合には、前にデキューされ、開始に成功しなかった最高の優先順
位の最初の要求を選択する（ステップ９１０）。しかし、結果が３の場合には、
前にデキューされていない任意の優先順位の最初の要求を選択する（ステップ９
１２）。その後、選択された要求をデキューし、処理する（ステップ９１４）。

【０１０３】 上で詳細に説明したのは、コプロセッサ内の非同期要求のための優先順位付け
機構である。入出力要求およびチャネル・サブシステムを参照して例を説明した
が、これらは例にすぎない。本手法は、他の非同期要求およびコプロセッサに同
等に適用可能である。さらに、上に記載の例は、キューイングに関連して説明し
たが、同様の優先順位付け機構を使用して、複数の動作を同時に実行できるチャ
ネル上のリソース（たとえば帯域幅）の割り当てを調整することができ、これに
よって、すべてを同等に実行するのではなく、優先順位の高い動作により多くの
チャネル・リソースを与えることができる。

【０１０４】 さらに、本明細書に記載のさまざまな例は、論理分割されたシステムに関連し
て説明されるが、入出力優先順位機能は、論理区画を有しないかサポートしない
システム内で使用可能である。

【０１０５】 さらなる利点として、人間の介入なしに使用可能なチャネル・リソースを必要
な場所に移動するか、余分のチャネル・リソースを除去するために、コンピュー
タ環境の入出力構成（たとえばチャネル・パス構成）を動的に変更することがで
きる。これによって、入出力を構成するのに必要な技術が減り、総合的なシステ
ム可用性が強化され、導入されたチャネルの利用度が最大になり、使用可能入出
力容量を分配するのにワークロードの相対優先順位が使用される。一実施形態で
は、「最良」の変更を決定するために、変更を行う前に１つまたは複数の要因を
調べる。この要因には、たとえば、応答時間または入出力速度に対する影響、特
定のワークロード目標を達成するための応答時間に対する影響、宛先ポートが使
用中であるかどうか、結果の可用性特性（たとえば、共通の単一障害点がないパ
スの追加）、および結果の入出力構成の複雑さ（またはエントロピ）が含まれる
。

【０１０６】 入出力構成の動的調整に関連する論理の一実施形態を、図１２ないし１７を参
照して詳細に説明する。最初、基本平衡化処理は、たとえばコンピュータ環境の
ワークロード・マネージャ構成要素によって、定期的にスケジューリングされる
時間間隔の開始時、たとえば１０秒ごとに呼び出される。基本平衡化処理の機能
は、サブシステム（たとえば論理制御装置）（浮動（すなわち管理対象）チャネ
ルを定義されている）にまたがって均等に入出力速度を継続的に平衡化し、好ま
しくは共通の単一障害点のない、複数のパスを介してすべての装置にアクセスで
きるようにし、ハードウェア障害の後にサブシステムの再平衡化を行うことであ
る。この処理には、データ収集（図１２のステップ１０００）および平衡検査（
ステップ１００２）という２つの構成要素が含まれる。データ収集は、環境の各
論理区画内（環境が論理分割されると仮定する。論理分割されていない場合には
、各システム内）で各インターバルに１回実行され、平衡検査は、グループ化さ
れたＬＰＡＲ（やはりグループ化を仮定する）ごとにインターバルごとに１回だ
け実行される。

【０１０７】 この処理のデータ収集部分の直列化は、どのシステムでもＷＬＭだけがインタ
ーバルごとに１回基本平衡化技法を呼び出すという事実によって得られる。さら
に、収集した情報を更新する時には、バージョン番号検査が使用される。たとえ
ば、結合装置内に記憶された制御ブロックを直列化して、収集された情報を更新
する。これらの制御ブロックによって、グループ・レベルのデータ収集が可能に
なり、これによって、同一ＣＰＣ上のグループのメンバにまたがるチャネルの管
理が可能になる。

【０１０８】 平衡検査を直列化するために、特にその目的のためのグループ・スコープを有
する直列化を使用する。通常、平衡化がデータ収集の直後に呼び出される時には
、グループ単位の直列化が要求される。直列化が得られる場合には、平衡検査が
進行し、そうでない場合には、平衡検査が、グループ化されたＬＰＡＲ内ですで
に行われつつあり、このインターバル中にもう一度実行する必要はない。

【０１０９】 図１２のデータ収集処理を、図１３を参照してさらに説明する。一実施形態で
は、定義されたサブシステム（たとえば論理制御装置）ごとに、測定データを収
集し、更新する（ステップ１１００）。測定データには、たとえば、接続時間、
保留時間、サブシステム使用中、装置使用中、宛先ポート使用中時間、および宛
先ポート使用中カウントが含まれる。更新された測定データは、結合装置などの
共用メモリ内の制御ブロックと共に、プロセッサ・メモリ内の制御ブロックに記
憶される。

【０１１０】 測定データの更新の後に、各サブシステムのデフォルト目標入出力速度を計算
する（ステップ１１０２）。この入出力速度は、追加のチャネル帯域幅が必要ま
たは望まれるかどうかを示す。一例として、デフォルト目標入出力速度は、接続
時間によって重みを付けられる。この計算を実行するために、一例では、以下の
ステップが行われる。ＤＣＭによって管理されるサブシステムごとに、前のイン
ターバル中にそのサブシステムが与えた接続時間の量と共に、現在の速度または
実際の速度を得る。その後、入出力速度に接続時間を乗じて、結果を得る。サブ
システムの結果を足し合わせて、合計を得る。接続時間によって重みを付けられ
たデフォルト目標入出力速度を決定するために、この合計を総接続時間で割る。

【０１１１】 図１２に戻って、データ収集を実行した後に、本明細書に記載されているよう
に、平衡検査を実行する（ステップ１００２）。平衡検査に関連する論理の一実
施形態を、図１４を参照して説明する。最初、平衡検査をこの瞬間に実行しなけ
ればならないかどうかを判定するために、直列化を実行する（問合せ１２００）
。グループ単位の直列化を得る試みが不成功の場合には、平衡検査論理は実行さ
れない（ステップ１２０２）。しかし、直列化が得られる場合には、目標範囲か
ら外れているサブシステムを探す（ステップ１２０４）。

【０１１２】 たとえば、すべてのサブシステムについて実際の入出力速度を得、平均をとる
（一例では、動的ＣＨＰＩＤ管理（ＤＣＭ）によって管理されるサブシステムだ
けが、この平均に含まれる）。平均を判定した後に、範囲を作成する。一例では
、範囲は、たとえば、平均値の±５％である。その後、各サブシステムの目標入
出力速度を、目標範囲と比較する。目標入出力速度が指定されていない場合には
、デフォルト目標入出力速度を使用する。この比較の結果として、２つのリスト
が作成される（ステップ１２０６）。一方のリストには、目標範囲を超えるサブ
システムが含まれ、もう一方には、目標を達成しないサブシステムが含まれる。
どの場合でも、最近（たとえば過去１０秒以内）に変更されたサブシステムは、
リストから排除される。

【０１１３】 その後、達成されない目標のリストをソートする（ステップ１２０８）。一例
では、ＷＬＭを使用してこのリストをソートする。というのは、ＷＬＭが、どの
サブシステムが最も重要であるかを決定する位置にあるからである。したがって
、ＷＬＭは、ＷＬＭがサービスを望む順序でサブシステムを並べる。

【０１１４】 リストをソートした後に、リストの１つまたは複数のサブシステムが、たとえ
ば利用度の低いサブシステムから過度に利用されているサブシステムへ容量をシ
フトすることによって、サービスされる（ステップ１２１０）。割り当てられた
時間内でサービスできる数のサブシステムが調整される。

【０１１５】 容量の調整に関連する論理の一実施形態を、図１５および図１６を参照して説
明する。最初、リストからサブシステムを選択する（ステップ１３００、図１５
）。一例では、選択されるのは、リストの最初のサブシステムである。その後、
問題が宛先ポート使用中であるかどうかに関する判定を行う（問合せ１３０２）
。具体的に言うと、競合（たとえば宛先ポート使用中時間）が高いかどうかに関
する判定を行い、そうである場合には、それに接続されるさまざまなインターフ
ェースに関してそれが変動するかどうかを判定する。宛先ポート使用中がすべて
のインターフェースで高い場合には、これは、別のチャネル・パスを追加する必
要があることを意味する。しかし、１つのインターフェースだけで高い場合には
、チャネル・パスを別のインターフェースに移動する（ステップ１３０４）。し
たがって、既存のパスが、過度な宛先ポート使用中時間を有するインターフェー
スから別のインターフェースに移動され、処理は変更の実施（ステップ１３０６
、図１６）に続行する。変更を実施する方法の例が、１９９３年１０月発行の米
国特許第５２５７３７９号明細書、１９９３年１０月発行の米国特許第５２５７
３６８号明細書、および１９９３年６月発行の米国特許第５２２０６５４号明細
書に記載されている。

【０１１６】 変更を実施した後に、目標範囲内にない他のサブシステムがあるかどうかに関
する判定を行う（問合せ１３０８）。ない場合には、不平衡訂正の処理が完了す
る。しかし、他のサブシステムが範囲内にない場合には、この処理は、ステップ
１３００「リストの次のサブシステムを選択する」（図１５）に継続する。

【０１１７】 問合せ１３０２に戻って、問題が競合に起因するものでない場合には、処理は
、本明細書で説明するように続行される。

【０１１８】 具体的に言うと、一例では、サブシステムに追加することが可能なチャネル・
パスを判定する（ステップ１３１０）。この判定には、物理トポロジ内での、そ
の特定のサブシステムに到達することができるすべてのチャネルの検査と、各チ
ャネルについてのそのサブシステムに到達することが可能な経路（パス）の判定
が含まれる。パスは、チャネルおよびサブシステムを接続すると共に、その両方
を含むハードウェア要素を通る接続順列である。これらのパスのすべて（または
、望むならばサブセット）が、可能なパスに含まれる。

【０１１９】 同様に、除去が可能なパスに関する判定を行う（ステップ１３１２）。一例と
して、同一チャネル上に複数のサブシステムがある場合に、共用するサブシステ
ムに接続されたパスの１つが、除去の候補とみなされる。

【０１２０】 その後、変更によってどのサブシステムが影響を受けるかに関する判定を行う
（ステップ１３１４）。さらに、変更される構成の複雑さを示すエントロピ・イ
ンデックスも、下で説明するように判定する。

【０１２１】 影響を受けるサブシステムの判定に関連する論理の一実施形態を、図１７を参
照して説明する。最初、サブシステムのサブシステム制御ブロック（ＳＳＣＢ）
リストおよびチャネルのＣＨＰＩＤリストを、後の使用のためにクリアする（ス
テップ１４００）。その後、チャネル・パスＩＤを、提案されたチャネルに関連
する判断選択ブロック（ＤＳＢ）から取り出し、ＣＨＰＩＤリストに追加する（
ステップ１４０２）。具体的に言うと、各パスは、判断選択ブロックを関連付け
られている。判断選択ブロックとは、たとえばチャネル・パスのＩＤ（ＣＨＰＩ
Ｄ）、チャネル・パスに関連する論理制御装置を示すサブシステム制御ブロック
（ＳＳＣＢ）ポインタ、および影響を受けるＳＳＣＢの配列を含む、さまざまな
情報を含む制御ブロックである。各ＳＳＣＢには、サブシステムに接続されたチ
ャネルのすべてが含まれる。

【０１２２】 その後、援助されるＳＳＣＢに関連するすべてのＣＨＰＩＤも、ＣＨＰＩＤリ
ストに追加する（ステップ１４０４）。具体的に言うと、ＳＳＣＢポインタを、
援助されるＳＳＣＢを示すＤＳＢから取り出す。その後、ＳＳＣＢのＣＨＰＩＤ
のすべてを、ＣＨＰＩＤリストに追加する。

【０１２３】 その後、リスト内のＣＨＰＩＤのそれぞれについて、チャネル・パスに関連す
るＳＳＣＢを、ＳＳＣＢリストに追加する（ステップ１４０６）。一例では、こ
の情報は、各ＣＨＰＩＤに接続されたＳＳＣＢを示すチャネル・パス・テーブル
から得られる。

【０１２４】 その後、ＳＳＣＢがリストに追加されたかどうかに関する判定を行う（問合せ
１４０８）。そうである場合には、リスト内のＳＳＣＢのそれぞれについて、ス
テップ１４０４に関して上で説明したように、まだＣＨＰＩＤリストに含まれて
いないＣＨＰＩＤを追加する（ステップ１４１０）。

【０１２５】 その後、リストに追加されたＣＨＰＩＤがあったかどうかに関するもう１つの
判定を行う（問合せ１４１２）。リストに追加された他のＣＨＰＩＤがあった場
合には、処理はステップ１４０６で継続される。しかし、リストに追加されたＳ
ＳＣＢもＣＨＰＩＤもない場合には（問合せ１４０８および１４１２）、リスト
のＳＳＣＢのそれぞれについて、ＤＳＢ配列要素を作成する（ステップ１４１４
）。すなわち、ＳＳＣＢのそれぞれを、影響を受けるＳＳＣＢの配列に追加する
。さらに、配列要素のそれぞれを、実際の入出力速度、目標入出力速度、目標入
出力速度と実際の入出力速度の間の現在のデルタ、およびＳＳＣＢポインタを用
いて更新する（ステップ１４１６）。

【０１２６】 図１５に戻って、上記に加えて、各パスの可用性インデックスを計算する（ス
テップ１３１６）。一例では、可用性インデックスは、提案されたパスがサブシ
ステムへの既存のパスと共通して有する単一障害点の個数を示す数である。チャ
ネル・パスを追加する場合には、単一障害点を有しないことが望まれる。チャネ
ル・パスを削除する場合には、通常は、最も多くの単一障害点を有するパスが選
択される。

【０１２７】 その後、影響を受けるシステムに対する影響を見積もる（ステップ１３１８）
。具体的に言うと、一例では、各サブシステムに対する現在の負荷を調べて、変
更を行った場合にそれがどれほど異なるかを判定する。この情報を使用して、最
適のオプションを選択する（ステップ１３２０）。最適のオプションを選択する
ために、たとえば下記を含むさまざまな要因を検討することができる。 ・どのオプションでサブシステムが目標の最も近くに移動されるか ・どのオプションが最良の可用性をもたらすか ・どのオプションが最良の対称性（最小のエントロピ）をもたらすか ・このオプションでパスの総数が２未満に減るか ・このオプションは、明示的な目標のどれかに違反するか（ＷＬＭは、デフォ
ルト目標の代わりに使用される明示的目標を供給することができる） ・このオプションは、アーキテクチャ的制限のどれかに違反するか ・このオプションは、インストールによって定義される構成に違反するか ・このオプションは、現在使用不能なリソースの使用を試みるか

【０１２８】 特定の例では、最初、どの状況の下でも実施できない判断選択ブロック（ＤＳ
Ｂ）を排除する。これには、たとえば、アーキテクチャ的制限に違反するもの、
パスの総数が２未満に減るもの、インストールによって定義される構成に違反す
るもの（たとえば、定義で許容される最大個数を超える浮動チャネル・パスを使
用するもの）、および現在使用不能なリソースの使用を試みるもの（たとえば、
使用不能にされたポートの使用を試みるもの）が含まれる。（この機能は、処理
のより早い段階に移動し、その結果、可用性インデックスおよびサブシステムに
対する影響の見積もりが、絶対に選択できないＤＳＢについて計算されないよう
にすることができる。）

【０１２９】 現在サブシステムへのパスが１つだけ存在する場合（おそらくはシステム始動
のすぐ後または障害の後）、最良の可用性インデックスを有するパスを選択する
。複数のパスが同等の可用性インデックスを有する場合には、目標サブシステム
を目標入出力速度目標内に移動する最も低いエントロピ・インデックスを有する
パスを選択する。複数存在する場合には、その見積もられたデルタの合計（ＤＳ
Ｂからの「Σ見積もられたデルタ」）が最小であるパスを選択する。

【０１３０】 現在サブシステムへのパスが複数存在する場合には、最良の可用性インデック
スを有するＤＳＢの組を見つける。その組から、目標サブシステムを目標入出力
速度の許容範囲内にする、最も低いエントロピ・インデックスを有するオプショ
ンを探す。複数存在する場合には、その見積もられたデルタの合計（ＤＳＢから
の「Σ見積もられたデルタ」）が最小であるパスを選択する。

【０１３１】 そのようなオプションが存在しない場合には、次によい可用性インデックスを
有するパスの組を見つけ、再度試みる。

【０１３２】 どのオプションでもサブシステムを許容範囲内にすることができない場合には
、可用性インデックスおよびエントロピ・インデックスを考慮せずに、サブシス
テムを目標に最も近づけるものを選択する。（上で説明した最適オプション選択
のための技法は、一例にすぎない。さまざまな追加、削除、および変更を行うこ
とができる。さらに、他の適当な技法を使用して、最適オプションを選択するこ
とができる。）

【０１３３】 最適オプションの選択を試みた後に、明示的目標を有するサブシステムに影響
せずに新しい目標を達成できるかどうかに関する判定を行う（問合せ１３２２）
。言い換えると、最適オプションが、ＷＬＭによって設定された明示的目標を有
するサブシステムに負の影響を及ぼすかどうかを判定する。そうである場合には
、ワークロード・マネージャを呼び出して、適当なパスを選択する（ステップ１
３２４）。具体的に言うと、ワークロード・マネージャは、パスを選択し、ドナ
ーの新しい目標を選択する。

【０１３４】 その後、または、明示的目標を有するサブシステムに負の影響を及ぼさずに新
しい目標を達成できる場合に、変更を実施し（ステップ１３０６）、処理は、目
標範囲内にない他のサブシステムが存在するかどうかの判定（問合せ１３０８）
に継続する。

【０１３５】 上で述べたように、ＷＬＭは、明示的入出力速度目標を設定することができ、
これは、デフォルト平均入出力速度目標の代わりに使用される。一実施形態では
、サービス・クラスがその目標を満たさないことをＷＬＭが見つけた時に、ＷＬ
Ｍが明示的目標を設定する。明示的サブシステム入出力速度目標の設定に関連す
る論理の一実施形態を、図１８を参照して説明する。

【０１３６】 最初、入出力が最大の遅延を引き起こしているかどうかを判定する（問合せ１
５００）。そうでない場合には、ここでの目的に照らして、処理が完了する。し
かし、入出力が最大の遅延を引き起こしている場合には、入出力優先順位調整を
試みる（ステップ１５０２）。その後、サービス・クラスがその目標を満たして
いるかどうかに関する判定を行う（問合せ１５０４）。サービス・クラスがその
目標を満たしている場合には、処理が完了する。しかし、サービス・クラスが、
まだその目標を満たしていない場合には、そのサービス・クラスによって使用さ
れており、低い入出力速度を有するサブシステムを探す（ステップ１５０６）。
突きとめられた１つまたは複数のサブシステムについて、新しいサブシステム入
出力速度目標を設定する。一例では、定義済みの量だけ現在の目標を増やし、サ
ブシステムに対する影響を見積もることによって、サブシステム入出力速度目標
が設定される。影響が十分である（たとえば、レシーバ値を超える）場合には、
処理が完了する。そうでない場合には、目標をもう一度増やし、この処理を繰り
返す。

【０１３７】 上で詳細に説明したのは、入出力構成の動的調整を提供する動的ＣＨＰＩＤ管
理（ＤＣＭ）である。ＤＣＭは、ＷＬＭに有利に統合され、これによって、ワー
クロードおよび目標の理解を用いて判断を行えるようになる。さらに、ＤＣＭを
用いると、複数の区画（たとえば区画のグループの区画）にまたがるチャネルの
管理が可能になる。これによって、必要な場所へのリソースの追加、および余分
なリソースの除去が可能になる。

【０１３８】 上で説明したように、動的ＣＨＰＩＤ管理（ＤＣＭ）を用いて、サブシステム
に追加（またはそれから除去）される「最適の」チャネルが選択される。これを
行うために、たとえば結果の入出力構成の複雑さ（またはエントロピ）を含む、
１つまたは複数の属性が試験される。

【０１３９】 エントロピの増加は、入出力構成を過度に複雑にし、ＤＣＭの処理の過度な時
間、影響を受けるサブシステムの過剰な数に起因する不正確な結果、性能報告の
複雑さ、および問題判別の複雑さをもたらす。したがって、本発明の好ましい実
施形態では、異なる選択肢の相対エントロピを判定し、その結果、構成をどのよ
うに調整するかの選択を行う時に、入出力速度および可用性などの他の検討点と
共に、相対エントロピを検討できるようにする機能が提供される。

【０１４０】 相対エントロピを判定する際には、エントロピ・インデックスを計算する。た
とえば、パスを追加する場合には、エントロピ・インデックスは、結果の構成の
チャネル数およびサブシステム数の合計になる。さらに、パスを削除する場合に
は、エントロピ・インデックスは、パスが削除された後に目標サブシステムに相
互接続されているチャネルおよびサブシステムの組を反映する。これには、もは
やその組に含まれないチャネルおよびサブシステムは含まれない。

【０１４１】 各オプションのエントロピの度合を計算するために、判断が実施されると仮定
して、一緒に接続されるチャネルおよびサブシステムの数を使用する。エントロ
ピ技法の基本的な前提の１つが、複数の提案されたトポロジの間の比較と、どの
トポロジがより対称であるか、またはより少ないエントロピを有するかの判定と
を可能にするインデックスを計算することである。これの目的は、大規模な相互
接続されたトポロジを避けることである。このようなトポロジは、入出力速度技
法の精度を下げ、過度に複雑なトポロジに起因して、事後に性能問題を分析する
ことを困難にすると思われる。

【０１４２】 エントロピ判定技法の一実施形態をさまざまな例で説明する。たとえば、図１
９は、２つのサブシステム１６０４に接続された２つのチャネル１６０２を含む
構成１６００の一例を示す図である。サブシステム２２は、追加リソースを必要
とする場合に、少なくとも２つの場所からそれを得ることができる。サブシステ
ム２２は、チャネル１またはチャネル３のいずれかからそれを受け取ることがで
きる。サブシステム２２がチャネル３からそれを得る場合、結果の構成は、３つ
のチャネルと２つのサブシステムを有する（図２０）。これによって、この構成
に５（３＋２）のエントロピ・インデックスが与えられる。しかし、サブシステ
ム２２が、チャネル１から追加リソースを受け取る場合（図２１）、結果の構成
は、元々有したもの以上のチャネルもサブシステムも有しておらず、結果のエン
トロピ・インデックスは２になる。この例では、第２のオプションが最小のエン
トロピを有する。

【０１４３】 もう１つの例を検討する。図２２に示された例では、サブシステム２３が、追
加リソースを必要としている。それは、チャネル２またはチャネル４から得るこ
とができる。チャネル２が使用される場合（図２３）、結果のエントロピ・イン
デックスは５になる（すなわち、１つの構成で３つのチャネルが２つのサブシス
テムに相互接続されている。チャネル４は、接続されていないのでカウントされ
ない）。チャネル４が使用される場合（図２４）、結果のインデックスは３にな
る。したがって、第２のオプションが最小のエントロピを有する。

【０１４４】 次に、構成が分割される場合を検討して、これがエントロピにどのように影響
するかを見てみる。

【０１４５】 図２５を参照すると、サブシステム２３が、過度の容量を有する場合に、チャ
ネル２またはチャネル３を除去することができる。チャネル２を除去する場合（
図２６）、構成が分割され、両方の構成のエントロピ・インデックスが下がる。
チャネル３を除去する場合（図２７）、まだ１つの構成が存在するが、エントロ
ピ・インデックスは元のインデックスより低い。一実施形態では、構成を２つに
分割するという判断は、２つのより複雑でないネットワークをもたらし、よりよ
い選択肢であると思われる。

【０１４６】 削除の際に、既存の構成（図２８）のインデックスならびに考慮中のサブシス
テムを含む提案された構成（図２９の右側）のインデックスが既知である場合に
は、もう一方の構成（図２９の左側）のインデックスは、減算によって計算する
ことができる。この例では、もう一方の構成のインデックスは、２に等しい（４
−３＝１かつ２−１＝１、したがって１＋１＝２）。図３０のように、サブシス
テムまたはチャネルの数についての減算結果が０になる場合には、エントロピは
、構成を分割せずに減らされている。（たとえば、２サブシステム−２サブシス
テム＝０。）一実施形態では、分割が好ましい。

【０１４７】 次の例では、サブシステム２３が、過剰なリソースを有する（図３１）。チャ
ネル２またはチャネル３を除去することができる。チャネル３を除去する場合（
図３２）、結果のエントロピ・インデックスは７になる。チャネル２を除去する
場合（図３３）、構成が２つの構成に分割され、考慮中の構成（サブシステム２
３を有する構成）は、５のエントロピ・インデックスを有し、結果の第２の構成
は、３のエントロピ・インデックスを有する。一実施形態では、構成の分割が好
ましい。

【０１４８】 次に、結果のエントロピ値ではなく、削除の際に分割を探すことだけが望まれ
る場合を判定するための例を検討する。

【０１４９】 図３４に示された例では、サブシステム２３が、多すぎる帯域幅を有する。チ
ャネル２またはチャネル４のいずれかを除去することができる。チャネル２を除
去する場合（図３５）、新しいエントロピ・インデックス６が得られ、残りの第
２の構成のエントロピ・インデックスは３である。チャネル４を除去する場合（
図３６）、新しいエントロピ・インデックス５が得られ、残りの第２の構成のエ
ントロピ・インデックスは４である。５および４のエントロピ・インデックスを
有する構成が、よりよい選択肢である。したがって、一実施形態では、分割の種
類が重要である。

【０１５０】 図３７に示された例では、サブシステム２３が、追加リソースを必要としてい
る。サブシステム２１をチャネル２から除去し（図３８）、サブシステム２３に
チャネル２のすべてのリソースを与えることができ、また、サブシステム２５を
チャネル４から除去し（図３９）、サブシステム２３にチャネル４のすべてのリ
ソースを与えることができる。

【０１５１】 サブシステム２１をチャネル２から除去する場合、結果のエントロピ・インデ
ックスは７であり、結果の第２の構成のエントロピ・インデックスは２である。
サブシステム２５をチャネル４から除去する場合、結果のエントロピ・インデッ
クスは６であり、残りの第２の構成は３である。一実施形態では、分割が均等に
より近いので、第２の選択肢がより良いと思われる。

【０１５２】 どのオプションが２等分（すなわち「均等」）により近いかを計算するために
、新しいエントロピ・インデックスと結果の第２の構成のエントロピ・インデッ
クスとの間で、チャネルおよびサブシステムの数の差を判定する。この例では、
第１の選択肢は、７および２のエントロピ・インデックスをもたらすので、差は
５である（すなわち、対称インデックス）。第２の選択肢は、６および３のエン
トロピ・インデックスをもたらすので、差は３である。より少ない差を有する選
択肢が、この実施形態では最良の選択肢である。

【０１５３】 結論を出すと、一実施形態では、サブシステムを目標入出力速度に近づけない
オプションが、排除される。さらに、エントロピ・インデックスが、結果の構成
で相互接続されているチャネルおよびサブシステムの総数を加算することによっ
て計算される。エントロピ・インデックスが変化しない場合には、その変更は対
称である。最低のエントロピ・インデックスを有する構成が、通常は選択される
。より高いエントロピ・インデックスを有する構成を選択することを意味する場
合であっても、８つを超えるチャネルを有する構成を選択することは回避すべき
である。代替案がない場合には、８つを超えるチャネルを有する構成を選択し、
うまくいけば、次のインターバルにこの構成が分割されることになる。

【０１５４】 上記の実施形態の変形形態を、入出力構成に関連して説明してきたが、ここで
述べた機能は、ストレージ・エリア・ネットワークその他のネットワークに同等
に適用可能である。

【０１５５】 上で説明したのは、コンピュータ環境のリソースを管理するためのさまざまな
機構である。物理共用可能リソースが、コンピュータ環境の論理区画にまたがっ
て管理される。論理区画はグループ化され、たとえば優先順位に基づくリソース
割振りによるリソース共用を可能にする。このリソース共用には、たとえば、Ｌ
ＰＡＲにまたがるＣＰＵリソースの動的管理、ＬＰＡＲにまたがる動的ＣＨＰＩ
Ｄ管理、チャネル・サブシステム内の入出力優先順位キューイング、およびＬＰ
ＡＲにまたがるメモリの動的管理が含まれる。

【０１５６】 一例では、システムのワークロード・マネージャが、少なくとも部分的にこの
管理の責任を負う。共用可能リソースは、アプリケーションのサブシステムにと
って透過的なワークロード・マネージャ指示の下で、ＬＰＡＲにまたがって動的
に再分配される。リソースは、モニタリング活動および顧客の目標に基づいて、
必要な区画に供給される。さらに、たとえばＷＬＭ、シスプレックス、およびＰ
Ｒ／ＳＭ統合を介する、ワークロード目標による物理リソースの動的調整は、並
列シスプレックス・データ共用を必要とせずに実行される。

【０１５７】 上で説明した実施形態では、さまざまなコンピュータ環境およびシステムを説
明した。これらは、例にすぎず、本発明の範囲を制限する目的のものではない。
同様に、本明細書で示した流れ図は、例示にすぎない。これらの図またはステッ
プ（または動作）に対する多数の変形形態があり得る。たとえば、ステップを適
宜異なる順序で実行することができ、ステップを追加、削除、または変更するこ
とができる。

【図面の簡単な説明】

【図１】 コンピュータ環境の一例を示す図である。

【図２】 コンピュータ環境のもう１つの実施形態を示す図である。

【図３】 コンピュータ環境の追加構成要素を示す図である。

【図４】 論理区画グループの一例を示す図である。

【図５】 グループに加入する区画に関連する論理の一例を示す図である。

【図６】 グループに加入する区画に関連する論理の一例を示す図である。

【図７】 グループからの区画の除去に関連する論理の一実施形態を示す図である。

【図８】 区画のレシーバ・サービス・クラスを助けるための、区画の重みを増やすこと
ができるかどうかの判定に関連する論理の一実施形態を示す図である。

【図９】 論理プロセッサの構成の動的調整に関連する論理の一実施形態を示す図である
。

【図１０】 チャネル・サブシステムの一実施形態を示す図である。

【図１１】 入出力動作の選択に関連する論理の一実施形態を示す図である。

【図１２】 入出力構成を調整しなければならないかどうかの判定に関連する論理の一実施
形態を示す図である。

【図１３】 図１２のデータ収集に関連する論理の一実施形態を示す図である。

【図１４】 図１２の平衡検査に関連する論理の一実施形態を示す図である。

【図１５】 入出力構成の不平衡の訂正に関連する論理の一実施形態を示す図である。

【図１６】 入出力構成の不平衡の訂正に関連する論理の一実施形態を示す図である。

【図１７】 影響を受けるサブシステムの判定に関連する論理の一実施形態を示す図である
。

【図１８】 明示的入出力速度目標の設定に関連する論理の一実施形態を示す図である。

【図１９】 エントロピ判定に使用される入出力構成の一例を示す図である。

【図２０】 エントロピ判定に使用される入出力構成の一例を示す図である。

【図２１】 エントロピ判定に使用される入出力構成の一例を示す図である。

【図２２】 エントロピ判定に使用される入出力構成の一例を示す図である。

【図２３】 エントロピ判定に使用される入出力構成の一例を示す図である。

【図２４】 エントロピ判定に使用される入出力構成の一例を示す図である。

【図２５】 エントロピ判定に使用される入出力構成の一例を示す図である。

【図２６】 エントロピ判定に使用される入出力構成の一例を示す図である。

【図２７】 エントロピ判定に使用される入出力構成の一例を示す図である。

【図２８】 エントロピ判定に使用される入出力構成の一例を示す図である。

【図２９】 エントロピ判定に使用される入出力構成の一例を示す図である。

【図３０】 エントロピ判定に使用される入出力構成の一例を示す図である。

【図３１】 エントロピ判定に使用される入出力構成の一例を示す図である。

【図３２】 エントロピ判定に使用される入出力構成の一例を示す図である。

【図３３】 エントロピ判定に使用される入出力構成の一例を示す図である。

【図３４】 エントロピ判定に使用される入出力構成の一例を示す図である。

【図３５】 エントロピ判定に使用される入出力構成の一例を示す図である。

【図３６】 エントロピ判定に使用される入出力構成の一例を示す図である。

【図３７】 エントロピ判定に使用される入出力構成の一例を示す図である。

【図３８】 エントロピ判定に使用される入出力構成の一例を示す図である。

【図３９】 エントロピ判定に使用される入出力構成の一例を示す図である。

───────────────────────────────────────────────────── フロントページの続き (31)優先権主張番号 ０９／４０７，３９１ (32)優先日 平成11年９月28日(1999．9．28) (33)優先権主張国 米国（ＵＳ） (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＭＺ，ＳＤ，ＳＬ，ＳＺ，ＴＺ，ＵＧ ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ， ＲＵ，ＴＪ，ＴＭ)，ＡＥ，ＡＧ，ＡＬ，ＡＭ，ＡＴ， ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＢＺ，Ｃ Ａ，ＣＨ，ＣＮ，ＣＲ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＤＭ ，ＤＺ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ， ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，Ｋ Ｅ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ ，ＬＴ，ＬＵ，ＬＶ，ＭＡ，ＭＤ，ＭＧ，ＭＫ，ＭＮ， ＭＷ，ＭＸ，ＭＺ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，Ｒ Ｕ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ ，ＴＲ，ＴＴ，ＴＺ，ＵＡ，ＵＧ，ＵＺ，ＶＮ，ＹＵ， ＺＡ，ＺＷ (72)発明者 ジェフリー・ニック アメリカ合衆国12493 ニューヨーク州ウ ェスト・パーク ルート９ダブリュ 1957 (72)発明者 ピーター・ヨコム アメリカ合衆国12590 ニューヨーク州ワ ッピンガーズ・フォールズ ワイルドウッ ド 17ビー (72)発明者 キャサリン・アイラート アメリカ合衆国12590 ニューヨーク州ワ ッピンガーズ・フォールズ シャーウッ ド・ハイツ・ドライブ 34 Ｆターム(参考） 5B098 AA10 GD01 GD14 GD19 HH01 HH07 HH08

Claims (36)

【特許請求の範囲】
1. 【請求項１】 コンピュータ環境のワークロードを管理する方法であって、 前記コンピュータ環境の複数の区画のうちの２以上の区画にまたがってワーク
   ロードを管理するステップを含み、 前記管理するステップは、前記２以上の区画のうちの少なくとも１つの区画の
   共用可能リソースの割振りを動的に調整するステップを含み、前記２以上の区画
   のワークロード目標が平衡化される方法。
2. 【請求項２】 前記動的に調整するステップが、前記少なくとも１つの区画内の作業処理に対
   して透過的に実行される、請求項１に記載の方法。
3. 【請求項３】 前記共用可能リソースが、ＣＰＵリソース、論理プロセッサ・リソース、入出
   力リソース、チャネル・リソース、コプロセッサ、ネットワーク・アダプタおよ
   びメモリのうちの少なくとも１つを含む、請求項１または２に記載の方法。
4. 【請求項４】 前記動的に調整するステップが、前記共用可能リソースの少なくとも一部を１
   つの区画から少なくとも１つの他の区画へ移動するステップを含む、請求項１〜
   ３のいずれかに記載の方法。
5. 【請求項５】 前記動的に調整するステップが、前記２以上の区画の間で前記共用可能リソー
   スを優先順位に基づいて管理するステップを含む、請求項１〜４のいずれかに記
   載の方法。
6. 【請求項６】 前記動的に調整するステップが、前記２以上の区画の間で前記共用可能リソー
   スを百分率割振りに基づいて割り当てるステップを含み、前記２以上の区画のそ
   れぞれが前記共用可能リソースの一部を割り当てられる請求項１〜５のいずれか
   に記載の方法。
7. 【請求項７】 前記区画が論理区画である、請求項１〜６のいずれかに記載の方法。
8. 【請求項８】 前記動的に調整するステップが、上記コンピュータ環境の少なくとも１つのワ
   ークロード・マネージャによって少なくとも部分的に制御される、請求項１〜７
   のいずれかに記載の方法。
9. 【請求項９】 前記動的に調整するステップが、データ共用の要件なしに実行される、請求項
   １〜８のいずれかに記載の方法。
10. 【請求項１０】 コンピュータ環境のワークロードを管理する方法であって、 前記コンピュータ環境の複数の区画のグループを識別するステップと、 前記グループの割り当てるべき共用可能リソースを決定することによって前記
    区画のグループを管理するステップとを含み、前記共用可能リソースの少なくと
    も一部が前記グループの前記複数の区画に割り振られる方法。
11. 【請求項１１】 前記区画が少なくとも１つのオペレーティング・システムの１以上のインスタ
    ンスを含む、請求項１０に記載の方法。
12. 【請求項１２】 前記グループを前記区画のうちの少なくとも１つの区画によってジョインする
    ステップをさらに含む、請求項１０または１１に記載の方法。
13. 【請求項１３】 前記ジョインするステップが、前記グループに割り振り可能な前記共用可能リ
    ソースの少なくとも一部に影響を及ぼす、請求項１２に記載の方法。
14. 【請求項１４】 前記グループから１つの区画を除去するステップをさらに含む、請求項１０〜
    １３のいずれかに記載の方法。
15. 【請求項１５】 前記除去するステップが、前記グループに割り振り可能な前記共用可能リソー
    スの少なくとも一部に影響を及ぼす、請求項１４に記載の方法。
16. 【請求項１６】 前記識別するステップが、１以上の区画をそれぞれ含む複数のグループを識別
    するステップを含む、請求項１０〜１５のいずれかに記載の方法。
17. 【請求項１７】 前記グループの少なくとも１つの区画の前記共用可能リソースの少なくとも一
    部の割振りを再調整するステップをさらに含む、請求項１０〜１６のいずれかに
    記載の方法。
18. 【請求項１８】 前記グループのための前記共用可能リソースの前記少なくとも一部の合計量が
    前記再調整するステップによって影響されないようにするステップをさらに含む
    、請求項１７に記載のシステム。
19. 【請求項１９】 前記共用可能リソースを前記グループへ割振りできるようにするステップをさ
    らに含む、請求項１０〜１８のいずれかに記載のシステム。
20. 【請求項２０】 コンピュータ環境のワークロードを管理する方法であって、 前記コンピュータ環境の複数の区画を含むグループが変更されたことを決定す
    るステップと、 前記決定に応答して、前記グループ内で前記グループのリソースの割振りを動
    的に調整することによって、前記グループを管理するステップと、 を含む方法。
21. 【請求項２１】 前記前記動的に調整するステップが、前記グループ内における前記リソースの
    総割振りを維持する、請求項２０に記載の方法。
22. 【請求項２２】 前記グループのために割り振られた量を超えた前記リソースの量を前記グルー
    プによって一時的に使用するステップをさらに含む、請求項２０に記載の方法。
23. 【請求項２３】 前記リソースについて競合が存在することを決定するステップと、 使用される前記量を前記グループに割り振られた量まで再調整するステップと
    をさらに含む、請求項２２に記載の方法。
24. 【請求項２４】 コンピュータ環境内でワークロードを管理する方法であって、 前記コンピュータ環境の区画に対するＣＰＵリソースの割振りを調整すべきこ
    とを決定するステップと、 前記コンピュータ環境の前記区画および別の区画にまたがって前記割振りを動
    的に調整するステップと、 を含む方法。
25. 【請求項２５】 前記動的に調整するステップが、少なくとも前記区画のワークロード目標に応
    じて実行される、請求項２４に記載の方法。
26. 【請求項２６】 前記動的に調整するステップが、前記区画に割り当てられた第１ＣＰＵプロセ
    ッサ重みおよび前記別の区画に割り当てられた第２ＣＰＵプロセッサ重みを修正
    するステップを含む、請求項２４または２５に記載の方法。
27. 【請求項２７】 前記修正するステップが、 前記第１ＣＰＵプロセッサ重みを増加するステップと、 前記第２ＣＰＵプロセッサ重みを減少するステップと、 を含む、請求項２６に記載の方法。
28. 【請求項２８】 前記前記第１ＣＰＵプロセッサ重みの増加量および前記第２ＣＰＵプロセッサ
    重みの減少量が同じであり、前記前記第１ＣＰＵプロセッサ重みおよび前記第２
    ＣＰＵプロセッサ重みの合計が一定である、請求項２７に記載の方法。
29. 【請求項２９】 前記区画および前記別の区画が区画のグループ内にある、請求項２４〜２８の
    いずれかに記載の方法。
30. 【請求項３０】 前記区画が作業の１以上のサービス・クラスを含み、前記決定するステップが
    、 前記区画に関連するプロセッサ重みを増加することが前記１以上のサービス・
    クラスのうちの選択されたサービス・クラスに及ぼす影響を見積もるステップと
    、 前記別の区画のプロセッサ重みを減少することが前記別の区画の１以上のサー
    ビス・クラスに及ぼす影響を見積もるステップと、 前記選択されたサービス・クラスに対する利益が前記別の区画の作業に対する
    負の影響を上回るかどうかを決定するステップとを含み、 前記利益が前記負の影響を上回る場合に調整が行われる、請求項２４〜２９の
    いずれかに記載の方法。
31. 【請求項３１】 前記別の区画内で実行すべき作業の重要度に基づいて前記別の区画を選択する
    ステップをさらに含む、請求項２４〜２９のいずれかに記載の方法。
32. 【請求項３２】 請求項１〜３１のいずれかに記載の方法を実行するためのコンピュータ・プロ
    グラム。
33. 【請求項３３】 コンピュータ環境のワークロードを管理するシステムであって、 前記コンピュータ環境の複数の区画のうちの２以上の区画にまたがってワーク
    ロードを管理する手段を含み、 前記管理する手段は、前記２以上の区画のうちの少なくとも１つの区画の共用
    可能リソースの割振りを動的に調整する手段を含み、前記２以上の区画のワーク
    ロード目標が平衡化されるシステム。
34. 【請求項３４】 コンピュータ環境のワークロードを管理するシステムであって、 前記コンピュータ環境の複数の区画のグループを識別する手段と、 前記グループの割り当てるべき共用可能リソースを決定することによって前記
    区画のグループを管理する手段とを含み、前記共用可能リソースの少なくとも一
    部が前記グループの前記複数の区画に割り振られるシステム。
35. 【請求項３５】 コンピュータ環境のワークロードを管理するシステムであって、 前記コンピュータ環境の複数の区画を含むグループが変更されたことを決定す
    る手段と、 前記決定に応答して、前記グループ内で前記グループのリソースの割振りを動
    的に調整することによって、前記グループを管理する手段と、 を含むシステム。
36. 【請求項３６】 コンピュータ環境内でワークロードを管理するシステムであって、 前記コンピュータ環境の区画に対するＣＰＵリソースの割振りを調整すべきこ
    とを決定する手段と、 前記コンピュータ環境の前記区画および別の区画にわたる前記割振りを動的に
    調整する手段と、 を含むシステム。