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

Description

【０００１】
【発明の属する技術分野】
本発明は、全般的にはコンピュータ・システム内のワークロードの管理に関し、具体的には、区画に分割されたシステムでのワークロードの管理に関する。
【０００２】
【従来の技術】
論理分割を用いると、単一の物理計算機または中央演算処理装置複合システム（ＣＰＣ）内で複数のシステム・イメージを確立することができる。各システム・イメージは、別々のコンピュータ・システムであるかのように動作することができる。すなわち、各論理区画は、独立にリセットでき、論理区画ごとに異なるものとすることのできるオペレーティング・システムを初期ロードでき、異なる入出力（Ｉ／Ｏ）装置を使用して異なるソフトウェア・プログラムと共に動作することができる。
【０００３】
論理分割されたコンピュータ・システムの例は、たとえば、１９８６年１月１４日発行の米国特許第４５６４９０３号明細書、１９８９年６月２７日発行の米国特許第４８４３５４１号明細書、および１９９６年１０月８日発行の米国特許第５５６４０４０号明細書に記載されている。
【０００４】
論理分割されたシステムの商業実施形態には、たとえば、プロセッサ・リソース／システム管理機構（ＰＲ／ＳＭ）を備えたＩＢＭ Ｓ／３９０プロセッサが含まれ、ＰＲ／ＳＭは、たとえば、ＩＢＭ社の出版物「Processor Resource/Systems Manager Planning Guide」、ＧＡ２２−７２３６−０４、１９９９年３月に記載されている。
【０００５】
【発明が解決しようとする課題】
論理分割されたシステムの重要な態様の１つが、そのシステムの区画内で稼動するワークロードの管理である。たとえば、Ｓ／３９０システムでは、ワークロード・マネージャを使用して、区画内および区画間でワークロードを管理する。ワークロード・マネージャは、作業をシステムの物理リソースに移動することによって、ワークロードの平衡化を試みる。しかし、作業を移動するためには、リロケートされる作業が必要とするデータが、移動先の位置にあることを保証することが重要である。この必要が、作業の移動を制限することがしばしばである。したがって、コンピュータ・システムにおけるワークロード管理をさらに改良することが望ましい。
【０００６】
【課題を解決するための手段】
したがって、本発明は特許請求の範囲に記載された方法、システムおよびコンピュータ・プログラムを提供する。
【０００７】
１つの実施形態では、本方法は、コンピュータ環境の複数の区画のうちの２以上の区画にまたがってワークロードを管理するステップを含み、この管理するステップは、これら２以上の区画のワークロード目標が平衡化されるように、２以上の区画のうちの少なくとも１つの区画の共用可能リソースの割振りを動的に調整するステップを含む。
【０００８】
本発明の他の実施形態では、コンピュータ環境のワークロードを管理するための方法は、コンピュータ環境の複数の区画のうち、共用可能リソースを並行共用する２以上の区画にまたがってワークロードを管理するステップを含む。この管理するステップは、２以上の区画のうちの少なくとも１つの区画の共用可能リソースの割振りを動的に調整するステップを含む。
【０００９】
本発明の好ましい実施形態は、ワークロード・マネージャの指示のもとに、複数の論理区画における共用可能リソースの動的再分配を可能にする。これらのリソースは、たとえば、ＣＰＵリソース、論理プロセッサ・リソース、Ｉ／Ｏリソース、コプロセッサ、チャネル・リソース、ネットワーク・アダプタ、およびメモリ・リソースを含む。一般に、ワークロード目標に従う物理リソースの動的調整は、並列シスプレックス・データ共用を必要とすることなく、ワークロード・マネージャ（ＷＬＭ）、シスプレックス、およびＰＲ／ＳＭの統合によって提供される。
【００１０】
また、好ましい実施形態では、論理区画（ＬＰＡＲ）におけるＣＰＵリソースのＷＬＭ動的管理、ＬＰＡＲにおける動的チャネル・パス（ＣＨＰＩＤ）管理、チャネル・サブシステムにおけるＷＬＭベースのＩ／Ｏ優先キューイング、およびＬＰＡＲにおけるＷＬＭ動的メモリ管理が提供される。１つの実装例では、ＬＰＡＲグループは、優先順位に基づくリソース割振りによるリソース共用を可能にする。
【００１１】
本発明の他の実施形態は、コンピュータ環境の複数の区画のグループを識別するステップを含む、コンピュータ環境の区画のグループを管理する方法を提供する。この方法は、さらに、グループに割り当てられる共用可能リソースを決定するためのステップを含み、その共用可能リソースの少なくとも一部がグループの複数の区画に割り振られる。
【００１２】
本発明の他の実施形態は、コンピュータ環境の複数の区画を含むグループが変更されたことを決定するステップと、この決定に応答して、グループ内でグループのリソースの割振りを動的に調整するステップとを含む、コンピュータ環境のワークロードを管理する方法を提供する。
【００１３】
好ましい実施形態では、どのリソースが特定のグループに割り当てられるかを決定するため、およびそのようなりソースの割振りを実行するために、グループのリソースがスコーピングされる。スコーピングは、次に何をなすべきかをＷＬＭが正しく判断できるように、変更可能なりソースを管理する。スコーピングは、ソフトウェアが何をしたいかをマシンが理解することができ、ソフトウェアがマシン構成を理解するように、リソースのサブセットがマシン上に提供されるのを可能にする。
【００１４】
本発明の他の好ましい実施形態は、コンピュータ環境の区画へのＣＰＵリソースの割振りを調整すべきことを決定するステップと、その区画およびコンピュータ環境の他の区画にまたがって割振りを動的に調整するステップとを含む、コンピュータ環境内でＣＰＵリソースを管理するための方法を提供する。
【００１５】
動的に調整するステップは、少なくとも区画のワークロード目標に応答して、コンピュータ環境の複数の区画にまたがって実行されるのが好ましい。
【００１６】
好ましい実施形態では、ワークロード・マネージャが、論理区画に関連するＣＰＵプロセッサ重みを動的に調整することによって、複数の論理区画にまたがってＣＰＵリソースを分配する。ＷＬＭは、たとえば、重要なワークロードを実行している区画の重みが低すぎるために、そのワークロードが遅れたときを把握する。ＷＬＭは、たとえば、その区画の重みを上げ、且つ他の区画の重みを下げて、重要なワークロードに対し追加のＣＰＵ容量を提供することにより、そのワークロードを援助することができる。これにより、ワークロード要件が変わったときに、必要な区画へＣＰＵリソースを動的に移動することができるようになる。
【００１７】
本発明は、上記の方法を実行するためのコンピュータ・プログラムも提供する。そのようなコンピュータ・プログラムは、一般に、コンピュータ可用媒体あるいはマシンが読み取り可能なプログラム記憶装置にエンコードされている、マシンが実行可能な命令を含み、コンピュータ・システムの一部に含まれるか、または（たとえば、ネットワークを介する伝送によって）別途に販売される。
【００１８】
本発明は、上記の方法に対応し、且つ方法を実行するためのコンピュータ・プログラムおよび適切なハードウェアを組み合わせることによって構成され得るシステムも提供する。
【００１９】
上記のようなコンピュータ・プログラムおよびシステムが、本発明の方法と同様な好ましい特徴に起因する効果を奏することは理解されよう。
【００２０】
次に、図面を参照しながら、本発明の好ましい実施形態について、例示の目的のみで詳細に説明する。
【００２１】
【発明の実施の形態】
コンピュータ環境のリソースの割振りの動的調整によって、その環境のワークロードを平衡化できるようにする、ワークロード管理機能を提供する。一例では、コンピュータ環境に複数の論理区画が含まれ、ワークロードは、そのうちの２以上の区画にまたがって管理される。
【００２２】
ワークロード管理機能を使用するコンピュータ環境の一実施形態を、図１を参照して説明する。コンピュータ環境１００は、たとえば、米国ニューヨーク州アーモンクのInternational Business Machines Corporationが提供するエンタープライズ・システム・アーキテクチャー（ＥＳＡ）／３９０に基づく。ＥＳＡ／３９０は、ＩＢＭ社の出版物、「Enterprise Systems Architecture/390 Principles Of Operation」、ＩＢＭ出版番号ＳＡ２２−７２０１−０４、１９９７年６月に記載されている。ＥＳＡ／３９０に基づくコンピュータ環境の一例が、International Business Machines Corporationが提供する9672 Parallel Enterprise Serverである。
【００２３】
コンピュータ環境１００には、たとえば、１つまたは複数の中央処理装置１０６（たとえばＣＰ１ないしＣＰ４）、１つまたは複数の論理区画１０８（たとえば論理区画（ＬＰ１ないしＬＰ４））、および少なくとも１つの論理区画マネージャ１１０を有する中央演算処理装置複合システム（ＣＰＣ）１０２が含まれる。これらのそれぞれを、下で説明する。
【００２４】
中央処理装置１０６は、論理区画に割り振られる物理プロセッサ・リソースである。具体的に言うと、各論理区画１０８は、１つまたは複数の論理プロセッサ（図を明瞭にするために特に図示せず）を有し、この論理プロセッサのそれぞれが、その区画に割り振られた物理プロセッサである中央処理装置１０６のすべてまたは共用部分を表す。特定の論理区画１０８の論理プロセッサは、その区画専用（その結果、基礎になるプロセッサ・リソース１０６がその区画のために予約される）とするか、別の区画と共用する（その結果、基礎になるプロセッサ・リソースが、潜在的に別の区画から使用可能になる）のいずれかとすることができる。
【００２５】
図示の特定の例では、論理区画ＬＰ１ないしＬＰ４のそれぞれが、常駐するオペレーティング・システム１１２（論理区画ごとに異なるものとすることができる）と１つまたは複数のアプリケーション１１４を有する別々のシステムとして機能する。一実施形態では、オペレーティング・システム１１２は、International Business Machines Corporationが提供するＯＳ／３９０またはＭＶＳ／ＥＳＡオペレーティング・システムである。
【００２６】
さらに、各オペレーティング・システム（またはそのサブセット）には、区画内および区画間でワークロードを管理するためのワークロード・マネージャ１１６が含まれる。ワークロード・マネージャの一例が、International Business Machines Corporationが提供するＷＬＭである。ＷＬＭは、たとえば、１９９５年１２月５日発行の米国特許第５４７３７７３号明細書および１９９７年１０月７日発行の米国特許第５６７５７３９号明細書に記載されている。
【００２７】
論理区画１０８は、プロセッサ１０６上で稼動するマイクロコードによって実装される論理区画マネージャ１１０によって管理される。論理区画１０８（ＬＰ１ないしＬＰ４）および論理区画マネージャ１１０のそれぞれには、中央処理装置に関連する中央記憶装置のそれぞれの部分に常駐する１つまたは複数のプログラムが含まれる。論理区画マネージャ１１０の一例が、ＰＲ／ＳＭである。
【００２８】
コンピュータ環境のもう１つの実施形態では、複数の中央演算処理装置複合システムが、図２に示されているように互いに結合されて、シスプレックスを形成する。一例として、中央演算処理装置複合システム（ＣＰＣ）１０２は、たとえば結合装置１２２を介して、１つまたは複数の他のＣＰＣ１２０に結合される。
【００２９】
図示の例では、ＣＰＣ１２０に、複数の論理区画１２４（たとえばＬＰ１ないしＬＰ３）が含まれ、これらの論理区画は、論理区画マネージャ１２６によって管理される。１つまたは複数の論理区画に、オペレーティング・システムが含まれ、この論理区画は、ワークロード・マネージャおよび１つまたは複数のアプリケーション・プログラムを有することができる（図を明瞭にするためにこの例では図示せず）。さらに、ＣＰＣ１２０には、複数の中央処理装置１２８（たとえばＣＰ１ないしＣＰ３）が含まれ、その中央処理装置のリソースは、複数の論理区画の間で割り振られる。具体的に言うと、リソースは、各区画の１つまたは複数の論理プロセッサ１３０の間で割り振られる（他の実施形態では、各ＣＰＣが、１つまたは複数の論理区画と、１つまたは複数の中央処理装置を有することができる）。
【００３０】
結合装置１２２（別名、構造化外部ストレージ（ＳＥＳ）プロセッサ）は、中央演算処理装置複合システムによってアクセス可能な記憶装置を含み、ＣＰＣ内のプログラムによって要求される動作を実行する。結合装置は、共用リソース再分配決定を行う際に使用される状態情報の共用のために本発明のさまざまな態様によって使用される（一実施形態では、各中央演算処理装置複合システムが、複数の結合装置に結合される）。結合装置の動作の諸態様は、１９９４年５月３１日発行の米国特許第５３１７７３９号明細書、１９９６年１０月１日発行の米国特許第５５６１８０９号明細書、および１９９８年１月６日発行の米国特許第５７０６４３２号明細書、ならびにこれらの米国特許明細書で参照されている特許および特許出願などの参考文献に詳細に記載されている。
【００３１】
一実施形態では、１つまたは複数の中央処理装置が、少なくとも１つのチャネル・サブシステムに結合され、このチャネル・サブシステムは、入出力装置との通信に使用される。たとえば、中央処理装置２００（図３）は、主記憶装置２０２および少なくとも１つのチャネル・サブシステム２０４に結合される。チャネル・サブシステム２０４は、さらに、１つまたは複数の制御装置２０６に結合される。制御装置は、１つまたは複数の入出力装置２０８に結合される。
【００３２】
チャネル・サブシステムは、入出力装置と主記憶装置の間の情報の流れを指示する。チャネル・サブシステムは、中央処理装置を、入出力装置と直接に通信するという作業から解放し、入出力処理と並列にデータ処理を進行できるようにする。チャネル・サブシステムは、入出力装置２０８との間の情報の流れを管理する際の通信リンクとして、１つまたは複数のチャネル・パス２１４を使用する。
【００３３】
各チャネル・パス２１４には、たとえば、チャネル・サブシステム２０４のチャネル２１０、制御装置２０６、およびチャネルと制御装置の間のリンク２１２が含まれる。他の実施形態では、チャネル・パスが、複数のチャネル、制御装置またはリンクを有することができる。さらに、もう１つの例では、チャネル・パスの一部として、１つまたは複数の動的交換機を有することも可能である。動的交換機は、チャネルおよび制御装置に結合され、交換機に付加されるリンクの任意の２つを物理的に相互接続する能力を提供する。チャネル・サブシステムに関するさらなる詳細は、１９９６年６月１１日発行の米国特許第５５２６４８４号明細書に記載されている。
【００３４】
本発明の好ましい実施形態では、さまざまな物理リソースが、１つまたは複数のワークロード・マネージャの指示の下で、コンピュータ環境の論理区画の間で動的に再分配される。この動的再分配は、アプリケーション・サブシステムにとって透過的である。例として、再分配される物理リソースには、ＣＰＵリソース、論理プロセッサ・リソース、入出力リソース、コプロセッサ、チャネル・リソース、ネットワーク・アダプタ、およびメモリ・リソースが含まれる。一例として、コプロセッサは、特定の機能をサービスする、ＣＰＣ内のマイクロプロセッサ（ＣＰＵ以外の）である。コプロセッサの例には、たとえば、チャネル・サブシステム、ネットワーク・アダプタ・カード、および暗号コプロセッサが含まれる。上記の物理リソースは、例として提供されるものにすぎない。他の共用可能リソースも再分配することができる。
【００３５】
リソースの動的再分配を容易にするために、一実施形態では、論理区画が、グループの区画の間でリソースを共用するためにグループ化される。各グループのサイズは、１区画からｎ区画まで変更できる。（一実施形態では、１つまたは複数のグループに１つまたは複数の区画が含まれるが、コンピュータ環境のすべての区画よりは少ない。）具体的に言うと、各グループには、たとえば、計算機の独立のドメインで稼動する１つまたは複数のオペレーティング・システム・イメージが含まれ、これらのドメインは、ワークロードおよびリソースを分配するために共通のワークロード・マネージャ機能によって管理される。一例では、これらのドメインは、論理分割モードで稼動する論理区画であり、オペレーティング・システムは、論理区画内で稼動するＯＳ／３９０である。グループの論理区画は、システム（たとえばＣＰＣ）もしくはシスプレックスの区画のサブセット、システムもしくはシスプレックス全体、または、異なるシスプレックス（たとえば単一のＣＰＣ上の）もしくは異なるシステムの区画とすることができる。
【００３６】
中央演算処理装置複合システムの２つの論理区画グループ（またはクラスタ）の一実施形態を、図４に示す。図からわかるように、それぞれに１つまたは複数の論理区画が含まれる、論理区画グループＡ３００および論理区画グループＢ３０２がある。論理区画のグループ化によって、リソース割振り（たとえば、優先順位に基づくリソース割振り）を介するグループの区画の間でのリソース共用が可能になる。
【００３７】
例として、共用されるリソースには、ＣＰＵリソース、入出力リソース、およびメモリならびに、コプロセッサまたは他の、計算機が提供することのできる共用可能リソースが含まれる。特定の論理区画グループは、特定の計算機のすべてのリソースへのアクセス権を有する場合とそうでない場合がある。実際に、複数の論理区画グループを、単一の計算機上で同時に動作するように定義することができる。各論理区画グループを効率的に管理するために、特定の論理区画グループを構成するリソースは、効果的にそのグループにスコーピングされる。
【００３８】
スコーピングには、各グループに割振り可能であるリソースの識別が含まれる。具体的に言うと、スコープによって、どのリソースがそのグループに制限され、そのグループのために管理可能であるかが定義される。論理区画グループを構成する論理区画は、リソースのコンテナとみなすことができる。これらのコンテナは、論理区画から使用可能なリソースの総セットの境界内に存在する。一例では、これは、特定のＣＰＣ上で使用可能なリソースの総セットである。
【００３９】
特定の論理区画グループ（たとえば論理区画グループＡ）を構成する論理区画には、共用可能な総リソースのうちの特定の部分が割り当てられる。たとえば、共用可能リソースがＣＰＵリソースであると仮定する。共用ＣＰＵリソースについて、論理区画グループＡに含まれる論理区画には、中央演算処理装置複合システムの総ＣＰＵリソースのうちの特定の部分が割り当てられる。これらのリソースは、特定のグループ内の論理区画ならびに、潜在的に、他の論理区画グループ内の論理区画およびどの論理区画グループにも含まれない論理区画によって共用されている。したがって、グループ内でのリソース移動（たとえば、論理区画グループ内の１区画からそのグループ内の別の区画へ）に関する決定を行おうとするワークロード・マネージャは、グループを構成するリソースの理解ならびに、より大きいコンテナ（たとえばＣＰＣ）に含まれるものの理解を有する必要がある。ワークロード・リソース管理に関する決定を行うのに使用される測定フィードバック（たとえば、結合装置に記憶された状態情報）は、上記のように顧客が定義したコンテナを理解するのに十分なものでなければならない。
【００４０】
この理解が確立された後に、ワークロード・マネージャが指示する、所与のグループの論理区画でのリソース割振りに対する変更は、通常は、コンテナ・サイズ（すなわち、論理区画グループに割り振られるリソース）を一定に保つ形で行われる。たとえば、管理されるリソースがＣＰＵリソースであると仮定し、さらに、各論理区画に、優先順位を示すＣＰＵ処理重みが割り当てられると仮定する。ＣＰＵ相対重みを管理するために、所与のグループ内の論理区画の相対重みの合計が、たとえばワークロード・マネージャを介する、指示された変更の前と後で一定にならなければならない。これによって、顧客が指定した、グループおよび計算機上に存在する他の論理区画へのリソースの割振りが維持される。
【００４１】
上記にもかかわらず、いくつかの場合に、リソースが指定された所有者によって使用されていない時に、区画のグループが、定義されたコンテナより多いリソースを使用することが望ましく、可能である場合がある。しかし、リソースの競合が発生すると同時に、リソースは、定義されたコンテナのサイズ（たとえば、この例では処理重み）に従って、ＬＰＡＲマネージャによって管理される。しかし、そのコンテナを超えてグループを拡張することを許可してはならない場合もありえる。これは、スコーピングに関してもありえる。他のリソースは、リソースの使用の正確なイメージを得るために、単一のグループに完全にスコーピングされる必要がある可能性がある。この形での制限によって、所与のグループの外部の論理区画がそのリソースにアクセスできなくなる。
【００４２】
上記に加えて、論理区画グループ内のリソースの可用性に対する外部変更の影響にも考慮を払う。たとえば、ユーザが、なんらかの外部手段を介して（ワークロード・マネージャの指示の下ではなく）リソースの割振りを変更する可能性がある。これは、ある計算機での実際のワークロードの変化、またはグループ間もしくは他の論理区画間のビジネス優先順位のシフトが原因で行われる可能性がある。これらの変更が行われる時には、これらの変更は、ワークロード・マネージャによって理解されなければならず、これらの変更の影響は、合理的に分配されなければならない。変更は、論理区画がグループに追加または除去される時、グループの外部の他の論理区画が追加または除去される時、または、単に外部手段を介して処理重みの変更が行われる時に、発生する可能性がある。これらの外部変更が実行される時には、コンテナのサイズが変更される可能性があり、ワークロード・マネージャは、その新しいサイズのコンテナのマネージャになる。
【００４３】
グループの特定の論理区画に属するリソースが外部から変更される時には、グループ内のリソースの再分配が必要になる可能性がある。たとえば、論理区画がグループから除去される時には、その論理区画に関連する処理重みが、そのグループから除去される。その論理区画について現在ワークロード・マネージャが割り当てている重みが、除去される論理区画の重み（すなわち、最初に論理区画に関連する処理重み）より大きい場合には、これらの重みの間の差が、そのグループ内の他の論理区画に追加される。これは、たとえば、グループ内の他の論理区画での重みの既存の分配に比例して行われる。論理区画について現在ワークロード・マネージャが割り当てている重みが、論理区画の初期重みより小さい場合には、これらの重みの間の差が、グループ内の他の論理区画から減算される。やはり、これは、一例として、他の論理区画の重みの割り当てに比例して行われる。
【００４４】
上で説明したように、グループは、グループに割り当てられたリソースおよび変更を許可されたリソースへのハンドルを得るためにスコーピングされ、その結果、ワークロード・マネージャは、次に何を行うかに関して正しい決定を行えるようになる。スコーピングによって、グループが識別され、プログラムが理解できる情報がプログラムに供給される。グループが変更される時には、リソースは、その変更を満足するために動的に調整される。
【００４５】
一実施形態では、リソースごとに別々のグループ（クラスタ）を設けることができる。たとえば、論理区画グループＡをＣＰＵリソースに関するものとし、論理区画グループＢを入出力リソースに関するものとすることができる。しかし、他の実施形態では、１つの論理区画グループを、リソースのサブセットまたはすべてに関するものとすることも可能である。
【００４６】
ＬＰＡＲグループ・スコープを確立するために、一例では、論理区画が、１つまたは複数の区画のグループに対してそれ自体を識別する。グループへの加入に関連する論理の一実施形態を、図５を参照して説明する。たとえば、論理区画グループに加入するために、論理区画で稼動するオペレーティング・システム（たとえばＯＳ／３９０）は、その論理区画がその一部になろうとするＬＰＡＲグループがどれであるかをＬＰＡＲマネージャに示す（ステップ４００）。一例として、命令を使用して、ＬＰＡＲグループ名をＬＰＡＲマネージャに渡す。オペレーティング・システムは、ＬＰＡＲグループ内で管理されるリソースのタイプごとに名前を指定する。したがって、他のリソースがある場合には（問合せ４０２）、他の名前を指定する。たとえば、あるグループ名が、ＣＰＵリソースについて与えられ、もう１つの名前が、入出力リソースについて与えられる。望むならば、各リソース・タイプについて同一のＬＰＡＲグループ名を指定することができる。
【００４７】
このＯＳ／３９０による宣言によって、計算機上で新しいＬＰＡＲグループが確立される（論理区画がその名前を使用する最初の論理区画である場合）か、この論理区画がそのリソース・タイプに関する同一の名前の既存のＬＰＡＲグループに加入することになるかのいずれかになる。たとえば、グループ名が指定された（ステップ４０４）（図６）後に、それが新しい名前であるかどうかに関する判定を行なう（問合せ４０６）。そうである場合には、新しいグループを作成する（ステップ４０８）。そうでない場合には、既存のグループに加入する（ステップ４１０）。その後、リソースをグループにスコーピングする（ステップ４１２）。
【００４８】
具体的に言うと、ＬＰＡＲグループにバインドされるグループ・タイプのリソースは、ＬＰＡＲグループ内で稼動するＷＬＭがそうする必要があると判定した場合に、その時に、その論理区画が使用するために使用可能にされる。スコーピングを必要とするＬＰＡＲグループの特定のタイプのリソースには、少なくとも２つの変形すなわち、追加リソースおよび固定リソースが含まれる。
【００４９】
追加リソース：いくつかの場合に、ＬＰＡＲグループへの加入によって、本質的に、論理区画が加入したばかりのＬＰＡＲグループにリソースが追加される。この一例が、ＣＰＵ処理重みであり、これは、たとえば、顧客によって、ハードウェア・コンソールで論理区画に割り当てられる。論理区画の現在の（使用中の）処理重みは、論理区画が活動化される時に、この顧客が割り当てた重みから初期設定される。論理区画がＣＰＵリソースに関するＬＰＡＲグループに加入する時には、その論理区画に顧客が割り当てた処理重みが、ＬＰＡＲグループ内での使用のために使用可能な総処理重みの一部になり、したがって、ＷＬＭによってＬＰＡＲグループ内で再割り当てすることが可能になる。ＬＰＡＲグループに加入したばかりの論理区画は、寄与が行われたばかりのＬＰＡＲグループ・リソースのより大きい組を使用する潜在能力を有する。
【００５０】
固定リソース：いくつかの場合に、リソースの組が、特定のＬＰＡＲグループに属するものとして事前に定義される。この一例が、管理対象（浮動）チャネル・パスである。管理対象チャネル・パスとは、ワークロード目標を達成するのを助けるためにそのリソースを再割り当てすることができるチャネル・パスである。特定のＬＰＡＲグループによる使用のための管理対象チャネル・パスの組は、最初は、チャネル・パス（ＣＨＰＩＤ）をＬＰＡＲグループに関連付ける入出力構成定義処理を介して定義される。論理区画は、このＬＰＡＲグループに加入する時に、このチャネル・パスの組へのアクセスを許可される。論理区画自体は、このリソース・プールに全く寄与しない（このリソースのプールは、やはり動的に変更することができるが、要点は、論理区画がＬＰＡＲグループに加入し、離脱する際にリソースが論理区画と共に移動しないことである）。
【００５１】
ＬＰＡＲスコープも、リソースのタイプに応じてリソースに対して異なる形で実施することができる。
【００５２】
追加リソース：ＬＰＡＲグループ内のオペレーティング・システムは、そのＬＰＡＲグループのこのタイプのリソースの完全な組を問い合わせることができる。一例として、ＣＰＵ処理重みの場合、これは、命令を介して達成される。オペレーティング・システムは、ＬＰＡＲグループ内のこのリソース・タイプの組全体、グループ内の論理区画へのリソースの割振り、および現在の計算機上で使用可能なリソース・プールの完全なサイズを知る。これらの構成要素のすべてが、全物理リソースのうちのどれだけが論理区画に割り振られるかを理解するのに使用される。その後、オペレーティング・システムは、ＬＰＡＲグループ内の論理区画への割振りを更新して、グループ内のリソースを再割当てする。オペレーティング・システムは、一例では、ＬＰＡＲグループに割り振られるリソースの総量を変更することを許可されない。ＬＰＡＲマネージャは、ＬＰＡＲグループのすべての部分が、更新で考慮され、ＬＰＡＲグループの外部の論理区画がそのリソースに影響を受けないようにすることによって、これを実施する。
【００５３】
固定リソース：ＬＰＡＲグループ内のオペレーティング・システムは、このタイプのリソースについて、そのＬＰＡＲグループに関連するリソースの組を問い合わせる。たとえば、管理対象チャネル・パスについて、特定のＬＰＡＲグループについて定義された管理対象チャネル・パスのリストを、命令を介してＬＰＡＲマネージャから取り出すことができる。ＬＰＡＲマネージャは、これらのリソースのスクリーニングも行って、これらが正しいＬＰＡＲグループによってのみ使用されるようにする。管理対象チャネルの場合、これは、管理対象チャネル・パスを、その管理対象チャネル・パスについて定義された名前と一致するＬＰＡＲグループ名を宣言した論理区画に対してオンラインに構成することだけが許可されることを意味する。
【００５４】
ＬＰＡＲグループの一部である論理区画が、システム・リセット、再ＩＰＬ、または非活動化される時には、その論理区画が１つまたは複数のＬＰＡＲグループに関して有した所属のすべてが除去される。グループからの論理区画の除去に関連する論理の一実施形態を、図７を参照して説明する。リセットの一部として、論理区画マネージャは、宣言されたＬＰＡＲ区画グループ名を論理区画から除去する（ステップ５００）。次に、リソースに応じて（問合せ５０２）、その論理区画のＬＰＡＲグループ・リソース割振り解除を完了するための１つまたは複数の他の処置を実行する。
【００５５】
リソースが追加リソースの場合には、以下が行われる。このような、論理区画がＬＰＡＲグループに加入した時にＬＰＡＲグループに追加されたリソースは、ＬＰＡＲグループから除去される（ステップ５０４）。これには、このタイプのリソースの、ＬＰＡＲグループの残りのメンバへの現在の割振りの調整が含まれる場合がある。たとえば、処理重みの場合、グループを離脱する論理区画の初期処理重みが、ＬＰＡＲグループのスコープから除去される。ＷＬＭが、論理区画の現在の処理重みを変更している場合には、調整を行う必要がある。論理区画の現在の処理重みが、その初期処理重みより大きい場合には、この２つの間の差が、残りのＬＰＡＲグループ・メンバに、その現在の処理重みに比例して再分配される。論理区画の現在の処理重みが、その初期処理重みより小さい場合には、この２つの間の差が、残りのＬＰＡＲグループ・メンバから、その現在の処理重みに比例して除去される。この調整の結果として、結果のＬＰＡＲグループに対する処理重みコンテナの内容が再確立される。
【００５６】
その一方で、リソースが固定リソースの場合には、以下が行われる。このようなリソースは、リセットされる論理区画の構成から単純に除去される（ステップ５０６）。たとえば、管理対象チャネル・パスの場合、チャネル・パスは、リセットされる論理区画から構成解除される。これによって、ＬＰＡＲグループのメンバだけが、ＬＰＡＲグループのリソースにアクセスできることが、もう一度再確立される。
【００５７】
ＬＰＡＲグループ環境内のＷＬＭによって管理されるリソースの一部が、グループ・スコーピングの必要を有しない場合があることにも留意されたい。そのようなリソースの一例が、論理区画のためにオンラインになる論理中央処理装置（ＣＰ）の数である。ＬＰＡＲグループ内の特定の論理区画の効果的な挙動は、その論理区画に対してオンラインである論理ＣＰの数によって大きく影響される可能性がある。論理区画が定義することのできるまたはオンラインである論理ＣＰの数は、その論理区画がＬＰＡＲグループに含まれるか否かに無関係に論理区画の特性であり、したがって、このリソースは、実際にはリソースのより大きいプールの一部にはならない。しかし、ＬＰＡＲグループでのその効果は、それによって、別のＬＰＡＲグループ・メンバに対してあるＬＰＡＲグループ・メンバ内で効果的に動作させることができるワークロードのタイプを変更できることである。
【００５８】
一例では、複数の論理区画の間で共用されるリソースが、ＣＰＵリソースである。ＯＳ／３９０ワークロード・マネージャは、論理区画に関連する１つまたは複数の相対プロセッサ重みを動的に調整することによって、論理区画の間でＣＰＵリソースを再分配する。ＷＬＭは、重要なワークロードが稼動する区画の重みが低すぎるので重要なワークロードが遅延される時を理解する。ＷＬＭは、この区画の重みを引き上げ、別の区画の重みを引き下げることによってこのワークロードを助けることができ、これによって、追加のＣＰＵ容量が重要なワークロードに与えられる。ＣＰＵリソースは、ワークロード要件が変化する際に、必要な区画に動的に移動される。
【００５９】
一実施形態では、論理区画重みのＷＬＭ管理のスコープが、論理区画グループである。一例として、ＷＬＭは、論理区画重みを調整するが、グループ内の区画の重みの合計を一定に維持する。合計を一定に維持することによって、グループに割り振られる総ＣＰＵリソースが、同一の物理コンピュータ上の他の独立のグループに対して相対的に同一に保たれる。したがって、ＷＬＭは、ある区画の重みを引き上げる時に、同一のグループ内の別の区画の重みを下げる。
【００６０】
論理区画重みの管理は、ＷＬＭの目標指向リソース割振り技法に対する機能強化であり、これは、たとえば、１９９５年１２月５日発行の米国特許第５４７３７７３号明細書および１９９７年１０月７日発行の米国特許第５６７５７３９号明細書に記載されている。
【００６１】
上記の特許明細書に記載されているように、ＷＬＭは、ＣＰＵディスパッチ優先順位を調整することによって、論理区画内のＣＰＵリソースの割振りを制御する。ＣＰＵディスパッチ優先順位は、サービス・クラス・レベルで作業に割り当てられる。しかし、ディスパッチ優先順位の調整がサービス・クラスを助けない、さまざまな状況がある。たとえば、
１）サービス・クラスが、単独で、すでに非システム作業に許可される最高のＣＰＵディスパッチ優先順位である。
２）サービス・クラスを助けるためのＣＰＵディスパッチ優先順位の変更が、それ以上の重要性を有する他のサービス・クラスに及ぼす負の影響が大きすぎる。
【００６２】
したがって、ＷＬＭは、サービス・クラスが、ＣＰＵ遅延に起因してその目標を失いつつあり、それをＣＰＵ優先順位の調節によって助けることができないことを見つけた時に、ＷＬＭは、失敗しつつあるサービス・クラスに関連する区画の重みの調節を検討する。
【００６３】
ＷＬＭが追加リソースの割振りを検討するサービス・クラスを、レシーバ・サービス・クラスと呼ぶ。ＷＬＭは、上に示した理由のどれかのために助けることができない、所与の区画でのＣＰＵ遅延に起因して目標を失いつつあるレシーバ・サービス・クラスを見つけた時に、ＷＬＭは、その区画の重みを引き上げることを検討する。レシーバ・サービス・クラスを助けるために区画の重みを引き上げることができるかどうかを判定するためにＷＬＭが従う論理の一実施形態を、図８を参照して下で説明する。
【００６４】
１．区画の重みを増やすことがレシーバ・クラスに及ぼす影響を見積もる（ステップ６００）。区画の重みを増やすと、その区画のＣＰＵ容量が増える。レシーバ・クラスでの作業のＣＰＵ需要は、一定と仮定されるので、区画のＣＰＵ容量を増やすと、レシーバ・サービス・クラスが必要とする、この容量の百分率が減る。レシーバ・サービス・クラスに対する利益の見積もりは、レシーバ・サービス・クラスと、システム需要に対する他の作業の両方の、使用可能なＣＰＵ容量の百分率のこの減少に基づく。
【００６５】
２．その重みを減らされる候補になる、論理区画グループ内の別の区画を見つける（ステップ６０２）。この区画を、候補ドナー区画と称する。候補ドナー区画は、たとえば、区画の重みを下げることによって、最も重要さの少ない作業が影響を受ける可能性が高い区画を探すことによって、選択される。
【００６６】
３．その重みを下げられる候補ドナー区画で稼動する作業を有するすべてのサービス・クラスに対する影響を見積もる（ステップ６０４）。候補ドナー区画の重みを減らすことによって、候補ドナー区画のＣＰＵ容量が減る。このＣＰＵ容量の減少は、候補ドナーの容量の百分率としての、候補ドナーで稼動する作業を有するサービス・クラスのＣＰＵ需要が増えることを意味する。候補ドナーの重みを減らすことの負の影響の見積もりは、これらのサービス・クラスが必要とする使用可能ＣＰＵ容量の百分率のこの減少に基づく。
【００６７】
４．この重みの変更が正味の値を有するかどうかを判定する（問合せ６０６）。すなわち、レシーバ・サービス・クラスに対する利益が、候補ドナー区画の作業に対する負の影響を上回るかどうかを、関係するサービス・クラスの目標および重要性に基づいて判定する。
【００６８】
５．重みの調節が正味の値を有する場合には、提案された区画の重みに対する変更を実施する（ステップ６０８）。正味の値がない場合には、ほかに候補ドナー区画があるかどうかに関する判定を行う（問合せ６１０）。そうである場合には、もう１つの候補ドナー区画を選択し（ステップ６１２）、処理はステップ３（ステップ６０４）で続行する。ほかに候補ドナー区画がない場合には、処理を終了する（ステップ６１４）。
【００６９】
ある区画で稼動するＷＬＭが、別の区画で稼動する作業に対する区画重み変更の効果の見積もりを行えるようにするために、各区画は、グループ内の各論理区画に関する性能データを含む共用データ構造へのアクセス権を有する。この区画レベルの性能データには、たとえば以下が含まれる。
・サービス・クラスによって区画で実行される作業のＣＰＵ要件
・各サービス・クラスが、その目標に向かってその区画上でどの程度良好に動作しているか
・区画のＣＰＵディスパッチ優先順位によるＣＰＵ使用量
【００７０】
ＯＳ／３９０システムに実装した本発明の好ましい実施形態では、この共用データ構造が、結合装置内で作成され、維持される。しかし、メッセージ交換または共用ディスクなどの他のデータ共用手法を使用して、このデータ構造を実装することができる。
【００７１】
上で説明したのは、コンピュータ環境のＣＰＵリソースを動的に再分配する能力である。リソースは、一例として、論理区画重みを動的に調整することによって、論理区画の間で再分配される。
【００７２】
コンピュータ環境のＣＰＵリソースの動的調整のほかに、本発明のもう１つの態様では、論理プロセッサ・リソースも動的に調整することができる。
【００７３】
論理区画は、１つまたは複数の論理プロセッサと共に構成され、それらの論理プロセッサは、中央演算処理装置複合システムの物理中央処理装置上で、作業を実行するためにディスパッチされる。区画がそれに割り当てられたＣＰＵ容量を消費できるようにするために、十分な論理プロセッサを論理区画に構成しなければならない。たとえば、１０個のＣＰＵを有するＣＰＣ上で稼動する論理区画Ａの場合を検討する。ワークロード・マネージャが、論理区画ＡにＣＰＣの容量の５０％を割り当てる場合、論理区画Ａは、少なくとも５つの論理プロセッサをそれに構成されることを必要とする（５つの論理プロセッサは、ＣＰＵのうちの５つすなわちＣＰＣの容量の５０％で稼動することができる）。論理区画Ａに、その後、ＣＰＣの容量の９５％が割り当てられた場合、論理区画Ａは、１０個の論理プロセッサを有するように構成されるはずである。ＷＬＭは、静的に定義された論理プロセッサ構成を用いて論理区画Ａに割り当てられた容量を動的に調整することができるので、すべての可能な容量割当てを収めるために、１０個の論理プロセッサが論理区画Ａに構成される。しかし、論理区画Ａに、たとえばＣＰＣの容量の２０％だけが割り当てられる場合には、静的に定義された論理プロセッサから次の２つ問題が生じる。１）１０個の論理プロセッサのそれぞれが、平均して、物理ＣＰＵの容量の０．２の比率で物理ＣＰＵリソースを消費することしかできない（１０個のＣＰＵの２０％を１０個の論理プロセッサによって分割すると、１論理プロセッサあたり０．２ＣＰＵになる）。これは、スループットが単一のタスクによってゲーティングされるワークロードを厳しく制限する可能性がある。というのは、その単一のタスクを、物理ＣＰＵの容量の０．２倍で実行することしかできなくなるからである。これは、ショート・エンジン効果と呼ばれることがある。２）２つの論理プロセッサだけが必要な時に１０個の論理プロセッサを管理しなければならない時に、ソフトウェアおよびハードウェアの効率が大きく低下する。
【００７４】
上記の欠陥に対処するために、論理区画の構成は、本発明の一態様によれば、静的に定義されるのではなく、動的に調整される。一例では、区画を管理し、動的調整を行うのは、ＷＬＭである。ＷＬＭは、コンピュータ環境（またはＬＰＡＲグループ内）の各論理区画についてこれを行うことができる。論理プロセッサの構成の動的調整に関連する論理の一実施形態を、図９を参照して説明する。
【００７５】
最初、論理区画を、ワークロード・マネージャによって論理区画に割り当てられた容量（または、実際に使用されている容量の方が大きい場合にはその容量）を消費できるようにするのに必要な最小の個数の論理プロセッサを用いて構成する（ステップ７００）。論理区画の容量割り当て（または容量使用量）が変化する際に（問合せ７０２）、評価を行って、論理区画に構成される論理プロセッサの数を変更しなければならないかどうかを判定する（ステップ７０４）。一例では、論理区画に構成される論理プロセッサの数は、論理区画に割り当てられた（または論理区画によって消費される）ＣＰＣ容量を提供するのに必要な物理ＣＰＵの数に近いままになる。したがって、各論理プロセッサは、物理ＣＰＵの容量に近い状態で実行され、管理される論理プロセッサの数が、最小になる。
【００７６】
論理構成を変更するかどうかの評価を行うために、一例では次の式を使用する。
Ｌ＝floor［max（Ｗ，Ｕ）×Ｐ＋１．５］（ただし、Ｌの最大値＝Ｐ）
ここで、Ｌ＝論理区画に構成される論理プロセッサの数、Ｗ＝論理区画に割り当てられるＣＰＣ容量の百分率、Ｕ＝論理区画によって現在使用されているＣＰＣ容量の百分率、Ｐ＝ＣＰＣ上の物理ＣＰＵの数である（ステップ７０５）。
【００７７】
Ｌは、たとえば定期的で頻繁なインターバル（たとえば１０秒ごと）に、Ｐ、Ｗ、およびＵの現在の値に基づいて、ワークロード・マネージャによって評価される。閾値を使用して、論理区画のＬの実際の値（Ｌ−ａｃｔ）を上げるか下げるかしなければならないかどうかを判定する。新たに計算されたＬの値（Ｌ−ｃａｌｃ）が、Ｌ−ａｃｔの現在の値より高い場合（問合せ７０６）、Ｌ−ａｃｔをＬ−ｃａｌｃまで引き上げる（ステップ７０８）。そうでない場合に、Ｌ−ｃａｌｃがＬ−ａｃｔより２つ以上小さい値である場合（問合せ７１０）、Ｌ−ａｃｔにＬ−ｃａｌｃ−１をセットする（ステップ７１２）。Ｌ−ｃａｌｃが、Ｌ−ａｃｔと等しいか、Ｌ−ａｃｔより１つだけ小さい場合には、論理区画のＬ−ａｃｔの値の変更は行われない（ステップ７１４）。これらの閾値の使用を介して、ワークロードのすばやく高まる容量需要に応答しながらも、小さいワークロード変動に起因するＬ−ａｃｔの無用な変更が回避される。
【００７８】
もう１つの例示として、次の例を検討する。Ｐ＝１０、Ｗ＝Ｕ＝２４％と仮定する。論理プロセッサの静的構成では、Ｗが９０％を超えて増加する場合を扱うために、Ｌ（静的）＝１０が必要になろう。しかし、本発明の好ましい実施形態によれば、Ｌ（動的）＝floor［max（．２４，．２４）×１０＋１．５］＝３である。したがって、この例では、Ｌ（静的）では、単一のタスクが物理ＣＰＵの０．２４で実行されるように制約されるが、Ｌ（動的）では、単一のタスクが、物理ＣＰＵの０．８０で実行されることが可能であり、これによって、単一タスク性能によってゲーティングされるワークロードのスループットの２３３％の向上がもたらされる。さらに、この例では、Ｌ（静的）に必要な１０個の論理プロセッサではなく、３つの論理プロセッサだけが管理されるので、ソフトウェアおよびハードウェアの効率が大幅に改善される。
【００７９】
コンピュータ環境の、管理されるもう１つの共用可能リソースは、入出力リソースなどの非同期リソースである。具体的に言うと、コプロセッサ（たとえばチャネル・サブシステム）内の入出力動作または入出力要求が管理される。この管理には、優先順位の高い入出力動作がすばやく処理される、優先順位の高い入出力動作がチャネルのより多くの帯域幅を割り当てられる、などの入出力動作の優先順位付けが含まれる。
【００８０】
現在の大規模多重プログラミング・コンピュータ・システムでは、付加された入出力装置の読取、書込、および制御のための入出力動作などの長時間稼動する処理の開始および実行は、通常は、複数の独立に動作する計算要素（図１０参照）の使用によって達成される。たとえば、中央処理装置８００内で実行中のプログラムは、付加された装置８０４との入出力動作を要求することができる。しかし、付加された装置との入出力動作の実際の開始および実行は、通常はチャネル・サブシステム８０２と呼ばれる、１つまたは複数の別々に独立して実行する協働プロセッサによって実行される。一般に、非同期入出力処理方法は、比較的長時間稼動する入出力装置の実行と並列に他の作業のために中央処理装置を最適化し効率的に使用するために使用される。すなわち、そうしなければ付加された入出力装置にアクセスし、読み書きするために必要になるはずの総プロセッサ・オーバーヘッド、処理時間、およびプロセッサ待ち時間を最小にするためである。そのような方法は、大規模多重プログラミング・システムで他のプロセッサ作業の実行と入出力動作との、最大のオーバーラップまたは実行の並列性を達成するように設計される。
【００８１】
そのような非同期入出力処理システムでは、中央処理装置が、Ｓ／３９０ ＳＴＡＲＴ ＳＵＢＣＨＡＮＮＥＬ命令などの入出力命令の使用によってプログラムが要求した入出力動作の実行を開始する。そのような命令は、通常は、次の２つの責任を負う。
１．チャネル・サブシステムの入出力作業キューに入出力動作要求をエンキュー（追加）し、
２．入出力作業キューを処理するために非同期に実行中のチャネル・サブシステムにシグナルを送る。
【００８２】
その後、中央処理装置は、他の作業／命令を実行することができ、入出力装置との要求された入出力動作の実際の実行に直接にはかかわらない。
【００８３】
１）上の処理の非同期な性質、２）中央処理装置とチャネル・サブシステム・プロセッサの独立動作、３）中央処理装置の実行速度と比較して相対的に長い、入出力動作の実行時間、および４）装置をチャネル・サブシステムに接続するチャネル・パスなどのチャネル・サブシステム・リソースの一部またはすべてが、入出力動作がプログラムによって要求された時に他の動作の実行で使用中である可能性があるという事実に起因して、複数の入出力要求が、チャネル・サブシステム入出力作業キューに同時にエンキューされる可能性が非常に高い。すなわち、ＳＴＡＲＴ ＳＵＢＣＨＡＮＮＥＬ命令は、チャネル・サブシステムが要求された入出力動作を実行する能力より高い速度で中央処理装置によって実行され、これによって、保留入出力動作要求のＮレベルの深さの入出力作業キューが継続的に引き起こされる。
【００８４】
保留入出力要求を処理するために、チャネル・サブシステムを構成するマイクロプロセッサは、それぞれの入出力作業キューを検査し（図１０参照）、１つまたは複数の入出力要求をこれらのキューからデキューし、それぞれの入出力装置に関するデキューされた入出力要求の開始を試みる。この活動の発端は、チャネル・サブシステム内の問題のマイクロプロセッサおよび作業キューに応じて変化する。たとえば、中央処理装置と対話するチャネル・サブシステム入出力プロセッサは、他の作業の実行に使用中でない時に周期的に、１つまたは複数の中央処理装置ＳＴＡＲＴ ＳＵＢＣＨＡＮＮＥＬ信号の結果として、または両方の組合せの結果として、この処理を開始するかも知れない。
【００８５】
チャネル・サブシステムのさまざまな作業キューの一例を、図１０を参照して説明する。前に述べたように、入出力要求は、たとえばＳＴＡＲＴ ＳＵＢＣＨＡＮＮＥＬ命令によって、入出力プロセッサ作業キュー８０６にエンキューされる。その後、入出力要求は、入出力プロセッサ８０８によって、入出力プロセッサ作業キューからデキューされる。入出力プロセッサ作業キューからデキューされた要求は、入出力プロセッサによって、チャネル・プロセッサ作業キュー８１０にエンキューされる。その後、これらの要求は、チャネル・プロセッサ８１２によってデキューされ、制御装置作業キュー８１４にエンキューされる。チャネル・プロセッサは、制御装置作業キューから要求をデキューして、チャネル・パスを介して制御装置へ、最終的には入出力装置へ送る。
【００８６】
現在、Ｓ／３９０プロダクト・ファミリーのシステム内では、チャネル・サブシステムのデキュー処理および作業初期設定処理は、先入れ先出し法（ＦＩＦＯ）に基づいて実行される。この処理は、論理的に実施が最も単純であり、スループットの最適化を目的とし、過去には、保留作業キューの平均深さが比較的浅く、入出力作業保留時間が比較的短い持続時間にとどまる（すなわち、さまざまな入出力作業キューの保留入出力要求の平均数が、重要性の高いプログラムまたは実時間依存型プログラムに関連する入出力動作の総入出力応答時間を大幅に引き延ばさない）ならば、さまざまな非同期処理要素の間の作業転送のために許容される戦略であった。
【００８７】
しかし、クリティカルな作業または時間依存の作業の適時な処理に関するユーザの需要をサポートするためにアプリケーション／プログラム優先順位付け機能を提供するオペレーティング・システムでは、保留入出力要求に関するＦＩＦＯ処理戦略は、ＦＩＦＯ作業キューの平均深さが増えるにつれて、ますます許容されなくなる。たとえば、ＩＢＭ Enterprise Storage Serverと共に使用される並列アクセス・ボリュームでは、チャネル・サブシステムの平均キュー深さが増える。これは、通常は、重要性が低いか時間依存型でない入出力要求が、ＦＩＦＯ作業キュー上でより重要な要求の前にキューに置かれる可能性があり、したがって、よりクリティカルな入出力要求の前に開始されることになるという事実に起因する。頻繁に、クリティカルでない作業は、長時間にわたってリソースを束縛する入出力を実行し、より重要な作業が遭遇する遅延が増える。これは、通常は、より重要な入出力要求の遅延の可能性が高まることをもたらす。
【００８８】
入出力保留時間とも称する遅延時間（総リアルタイム遅延または中央処理装置の速度と比較した時の相対時間遅れのいずれかとすることができる）の増加は、チャネル・サブシステムおよび付加された装置が、クリティカルな入出力要求の適時の完了に影響しない入出力実行の速度を維持する能力がないこと（言い換えると、重要性の高いプログラムまたは時間依存型プログラムの実行時間の許容不能な延長をもたらさない実行速度を維持する能力がないこと）に起因することがしばしばである。上で述べたように、クリティカルな入出力要求に関する総入出力応答時間の許容不能な延長の確率は、ＦＩＦＯ作業処理方法が使用される時に、一般に高まる。この遅延の確率は、中央処理装置の速度および数が、付加される入出力装置および、装置が付加されるチャネル・パスなどの他の必要なチャネル・サブシステム要素の速度の向上より高い割合で向上する際に、さらに大きくなる。一般に、入出力速度の向上の割合に対する中央処理装置の速度の向上の割合の不一致は、現在の大規模システム環境で増大を続け、その結果、クリティカルな作業のキューイング遅延およびより大きい入出力応答時間（リアルタイムまたは相対時間のいずれか）の確率がますます高まる。
【００８９】
例として、チャネル・サブシステムでのキューイング遅延に起因する、重要性の高い入出力動作および時間依存型入出力動作の長い入出力応答時間の頻度を最小にするために、優先順位処理技法を定義して、１つまたは複数のチャネル・サブシステム保留入出力作業キューを処理する。
【００９０】
２つの独立に実行されるプロセッサまたはプロセスの間の優先順位処理技法の実施の例には、以下が含まれる。
１．エンキュー・プロセッサ（またはプロセス）が、プログラム指定の（たとえばＷＬＭによる）優先順位番号に基づく優先順位シーケンシング技法を使用して、チャネル・サブシステム入出力作業キュー（処理の段階に依存する特定のキュー）に入出力要求を追加する。チャネル・サブシステムは、その後、ＦＩＦＩ技法を使用して、作業キューから最初の最も優先順位の高い入出力要求を除去する。または、
２．エンキュー・プロセッサ（またはプロセス）が、ＦＩＦＯエンキュー技法を使用して、入出力作業キューの最下部に入出力要求を追加する。チャネル・サブシステムは、優先順位選択技法を使用して、その後、作業キューのすべての入出力要求要素を探索し、最も高いプログラム指定の優先順位番号を有する入出力要求を除去し、処理する。
【００９１】
ＦＩＦＯエンキュー技法（技法２）では、必要な命令が少なく、したがって、中央処理装置が、入出力要求スケジューリング処理をよりすばやく完了することができる。これによって、中央処理装置は、よりすばやく他の作業を実行できるようになる。チャネル・サブシステムを構成するさまざまなマイクロプロセッサの間のエンキュー／デキュー処理について、選択すべき技法は、通常は、参加するプロセッサのどれが、その処理容量および適時性の要件に関して最も制約されるかに依存する。すなわち、エンキュー・プロセッサが最も制約される場合には、第２の技法を選択する。デキュー・プロセッサが最も制約される場合には、通常は第１の技法を選択する。
【００９２】
これらの技法のどちらを使用するかに無関係に、その結果は、チャネル・サブシステムが、到着時刻またはＦＩＦＯ方法ではなく、優先順位付け方法に基づく保留入出力要求の開始および実行を優先することである。
【００９３】
さらに、一実施形態では、使用されるエンキュー技法および選択技法に無関係に、処理される要求の優先順位付けや選択に、さまざまな判断基準が使用される。一例では、この判断基準に以下が含まれる。
【００９４】
１．各異なる番号が独自の優先順位レベルに対応する、プログラム指定の優先順位番号に基づく保留入出力要求の選択。たとえば、連続する独自の番号の範囲を設け、数の範囲全体が、優先順位の区別を必要とする別個の作業カテゴリの総数以上になるようにする。たとえば、システムが、通常のＳ／３９０システムで可能であるように、Ｎ個の異なるオペレーティング・システムを同時に実行する能力を有する場合には、チャネル・サブシステム優先順位技法は、Ｎ個以上の別個の優先順位レベルを提供しなければならない。最低のレベルから最高のレベルまでまたはその逆の各優先順位レベルは、０からＮ−１までの範囲の独自の数によって表されるはずである。
【００９５】
２．優先順位に無関係にすべてのエンキューされた要求に「フェアネス」も適用する技法を使用する、保留入出力要求の優先順位選択。これは、通常は、たとえば、長時間にわたってチャネル・サブシステムに不相応に多数の高い優先順位の要求が提示されることに起因して発生する可能性がある、低い優先順位の要求が長時間にわたって処理されない確率を最低にするために所望される。フェアネス選択は、他の考慮点に応じて、同一の優先順位の保留要求に適用することもできる。たとえば、まだ選択されていない他の同一優先順位の要求と共に、すでにデキューされ、開始に失敗し、複数回再キューイングされた保留要求にフェアネスを提供することである。このような技法を、図１１を参照して説明する。この技法では、保留要求の複数の異なるカテゴリに、優先順位とフェアネスの両方を適用する。
【００９６】
３．下記に関する外部ユーザ／オペレータの制御
１．優先順位処理技法のグローバルな使用可能化／使用不能化。この制御は、優先順位技法が不要であるか、非類型的なプログラム実行環境に適当に対応することができない場合に、保留要求のＦＩＦＯ処理を強制するために必要になる場合がある。
２．複数の論理区画の並列実行を提供するシステムの場合の、所与の論理区画に関連する入出力要求の「デフォルト」優先順位値をユーザが指定できるようにする外部制御。これは、論理区画内で実行中のオペレーティング・システムが、その入出力要求の優先順位値を指定するように設計されていないが、それでも、入出力優先順位付けを指定する他の論理区画内で実行中の他のオペレーティング・システムと成功裡に競合しなければならない時に使用される。
３．複数の論理区画の並列実行を提供するシステムの場合の、チャネル・サブシステムによって供給される値の組全体からの、各論理区画の優先順位値のサブセット最小最大範囲をユーザが指定できるようにするための外部制御。この制御は、別々の論理区画内で実行中の複数のオペレーティング・システムが、入出力優先順位を独立に、それを使用する他の区画の知識なしに使用する時に使用される。すなわち、各使用する区画によって開始される要求の優先順位に基づく分離を可能にするための制御である。
【００９７】
上の項目３．２および３．３について、一実施形態では、中央処理装置が、論理区画内で実行中のプログラムのユーザ指定のデフォルト優先順位値またはユーザ指定の最大／最小許容優先順位を、その区画で動作するプログラムに透過的な形で、暗黙のうちに割り当てる。Ｓ／３９０システムでは、これは、論理区画マネージャ（ハイパーバイザ）および中央処理装置のＳＴＡＲＴ ＳＵＢＣＨＡＮＮＥＬ命令によって共同で達成することができる。
【００９８】
論理区画内で動作するプログラムが、入出力動作を開始するためにＳＴＡＲＴ ＳＵＢＣＨＡＮＮＥＬを実行する時には、中央処理装置でのＳＴＡＲＴ ＳＵＢＣＨＡＮＮＥＬ命令の解釈実行で、暗黙のうちに、解釈実行開始（ＳＩＥ）状態記述（ＳＤ）テーブルから、デフォルト優先順位番号および最小／最大許容優先順位番号の両方が獲得される。このテーブルは、論理区画ハイパーバイザが区画を実行状態にするためにＳＩＥ命令を実行する時に、その論理区画ハイパーバイザによって、中央処理装置内に作成され、ロードされる。その後、ＳＴＡＲＴ ＳＵＢＣＨＡＮＮＥＬの解釈実行では、ＳＩＥ状態記述テーブルのデフォルト優先順位値および最小／最大優先順位値を使用して、論理区画内で動作するプログラムによる関与なしで、適当な優先順位値を入出力要求に暗黙のうちにセットする。
【００９９】
優先順位値が、論理区画内で実行中のプログラムによって指定されない時には、ＳＴＡＲＴ ＳＵＢＣＨＡＮＮＥＬの解釈で、ユーザ指定のデフォルト優先順位値が入出力要求に割り当てられる。論理区画内で実行中のプログラムが、ＳＴＡＲＴ ＳＵＢＣＨＡＮＮＥＬを実行する時に優先順位番号を指定する時には、ＳＴＡＲＴ ＳＵＢＣＨＡＮＮＥＬの解釈実行で、プログラム指定の優先順位値を、状態記述テーブル内のハイパーバイザ指定の最小／最大優先順位値と比較する。プログラム指定の優先順位が、ハイパーバイザ指定の最小値より小さい時には、状態記述テーブルからの最小値によって、暗黙のうちにプログラム指定の値を置換する。プログラム指定の優先順位値が、ハイパーバイザ指定の最大優先順位を超える時には、状態記述テーブルからの最大優先順位値によって、プログラム指定の値を置換する。
【０１００】
上記の判断基準のうちの０個以上を使用して、優先順位選択技法を導出することができる。上記の判断基準の少なくともいくつかを使用する、処理される要求を選択するための技法の一実施形態を、図１１を参照して説明する。
【０１０１】
最初、保留作業キューにアクセスする（ステップ９００）。たとえば、入出力プロセッサ作業キュー、チャネル・プロセッサ作業キュー、または制御装置作業キューのいずれかにアクセスする。その後、デキューされた保留要求のカウントを１つ増分する（たとえば、ＤＱＣＯＵＮＴ＝ＤＱＣＯＵＮＴ＋１）（ステップ９０２）。
【０１０２】
その後、保留要求のどのカテゴリを処理するかに関する判定を行う（ステップ９０４）。一例では、選択されるカテゴリは、（ＤＱＣｏｕｎｔ ＭＯＤＵＬＵＳ カテゴリ数）に等しい。したがって、この例では４つのカテゴリがあるので、選択されるカテゴリは、ＤＱＣｏｕｎｔ ＭＯＤＵＬＵＳ ４に等しい。結果が０の場合には、任意の優先順位の最初の要求をデキューする（ステップ９０６）。しかし、選択されるカテゴリが１の場合には、前にデキューされていない最高優先順位の最初の要求を選択する（ステップ９０８）。さらに、選択されるカテゴリが２の場合には、前にデキューされ、開始に成功しなかった最高の優先順位の最初の要求を選択する（ステップ９１０）。しかし、結果が３の場合には、前にデキューされていない任意の優先順位の最初の要求を選択する（ステップ９１２）。その後、選択された要求をデキューし、処理する（ステップ９１４）。
【０１０３】
上で詳細に説明したのは、コプロセッサ内の非同期要求のための優先順位付け機構である。入出力要求およびチャネル・サブシステムを参照して例を説明したが、これらは例にすぎない。本手法は、他の非同期要求およびコプロセッサに同等に適用可能である。さらに、上に記載の例は、キューイングに関連して説明したが、同様の優先順位付け機構を使用して、複数の動作を同時に実行できるチャネル上のリソース（たとえば帯域幅）の割り当てを調整することができ、これによって、すべてを同等に実行するのではなく、優先順位の高い動作により多くのチャネル・リソースを与えることができる。
【０１０４】
さらに、本明細書に記載のさまざまな例は、論理分割されたシステムに関連して説明されるが、入出力優先順位機能は、論理区画を有しないかサポートしないシステム内で使用可能である。
【０１０５】
さらなる利点として、人間の介入なしに使用可能なチャネル・リソースを必要な場所に移動するか、余分のチャネル・リソースを除去するために、コンピュータ環境の入出力構成（たとえばチャネル・パス構成）を動的に変更することができる。これによって、入出力を構成するのに必要な技術が減り、総合的なシステム可用性が強化され、導入されたチャネルの利用度が最大になり、使用可能入出力容量を分配するのにワークロードの相対優先順位が使用される。一実施形態では、「最良」の変更を決定するために、変更を行う前に１つまたは複数の要因を調べる。この要因には、たとえば、応答時間または入出力速度に対する影響、特定のワークロード目標を達成するための応答時間に対する影響、宛先ポートが使用中であるかどうか、結果の可用性特性（たとえば、共通の単一障害点がないパスの追加）、および結果の入出力構成の複雑さ（またはエントロピ）が含まれる。
【０１０６】
入出力構成の動的調整に関連する論理の一実施形態を、図１２ないし１７を参照して詳細に説明する。最初、基本平衡化処理は、たとえばコンピュータ環境のワークロード・マネージャ構成要素によって、定期的にスケジューリングされる時間間隔の開始時、たとえば１０秒ごとに呼び出される。基本平衡化処理の機能は、サブシステム（たとえば論理制御装置）（浮動（すなわち管理対象）チャネルを定義されている）にまたがって均等に入出力速度を継続的に平衡化し、好ましくは共通の単一障害点のない、複数のパスを介してすべての装置にアクセスできるようにし、ハードウェア障害の後にサブシステムの再平衡化を行うことである。この処理には、データ収集（図１２のステップ１０００）および平衡検査（ステップ１００２）という２つの構成要素が含まれる。データ収集は、環境の各論理区画内（環境が論理分割されると仮定する。論理分割されていない場合には、各システム内）で各インターバルに１回実行され、平衡検査は、グループ化されたＬＰＡＲ（やはりグループ化を仮定する）ごとにインターバルごとに１回だけ実行される。
【０１０７】
この処理のデータ収集部分の直列化は、どのシステムでもＷＬＭだけがインターバルごとに１回基本平衡化技法を呼び出すという事実によって得られる。さらに、収集した情報を更新する時には、バージョン番号検査が使用される。たとえば、結合装置内に記憶された制御ブロックを直列化して、収集された情報を更新する。これらの制御ブロックによって、グループ・レベルのデータ収集が可能になり、これによって、同一ＣＰＣ上のグループのメンバにまたがるチャネルの管理が可能になる。
【０１０８】
平衡検査を直列化するために、特にその目的のためのグループ・スコープを有する直列化を使用する。通常、平衡化がデータ収集の直後に呼び出される時には、グループ単位の直列化が要求される。直列化が得られる場合には、平衡検査が進行し、そうでない場合には、平衡検査が、グループ化されたＬＰＡＲ内ですでに行われつつあり、このインターバル中にもう一度実行する必要はない。
【０１０９】
図１２のデータ収集処理を、図１３を参照してさらに説明する。一実施形態では、定義されたサブシステム（たとえば論理制御装置）ごとに、測定データを収集し、更新する（ステップ１１００）。測定データには、たとえば、接続時間、保留時間、サブシステム使用中、装置使用中、宛先ポート使用中時間、および宛先ポート使用中カウントが含まれる。更新された測定データは、結合装置などの共用メモリ内の制御ブロックと共に、プロセッサ・メモリ内の制御ブロックに記憶される。
【０１１０】
測定データの更新の後に、各サブシステムのデフォルト目標入出力速度を計算する（ステップ１１０２）。この入出力速度は、追加のチャネル帯域幅が必要または望まれるかどうかを示す。一例として、デフォルト目標入出力速度は、接続時間によって重みを付けられる。この計算を実行するために、一例では、以下のステップが行われる。ＤＣＭによって管理されるサブシステムごとに、前のインターバル中にそのサブシステムが与えた接続時間の量と共に、現在の速度または実際の速度を得る。その後、入出力速度に接続時間を乗じて、結果を得る。サブシステムの結果を足し合わせて、合計を得る。接続時間によって重みを付けられたデフォルト目標入出力速度を決定するために、この合計を総接続時間で割る。
【０１１１】
図１２に戻って、データ収集を実行した後に、本明細書に記載されているように、平衡検査を実行する（ステップ１００２）。平衡検査に関連する論理の一実施形態を、図１４を参照して説明する。最初、平衡検査をこの瞬間に実行しなければならないかどうかを判定するために、直列化を実行する（問合せ１２００）。グループ単位の直列化を得る試みが不成功の場合には、平衡検査論理は実行されない（ステップ１２０２）。しかし、直列化が得られる場合には、目標範囲から外れているサブシステムを探す（ステップ１２０４）。
【０１１２】
たとえば、すべてのサブシステムについて実際の入出力速度を得、平均をとる（一例では、動的ＣＨＰＩＤ管理（ＤＣＭ）によって管理されるサブシステムだけが、この平均に含まれる）。平均を判定した後に、範囲を作成する。一例では、範囲は、たとえば、平均値の±５％である。その後、各サブシステムの目標入出力速度を、目標範囲と比較する。目標入出力速度が指定されていない場合には、デフォルト目標入出力速度を使用する。この比較の結果として、２つのリストが作成される（ステップ１２０６）。一方のリストには、目標範囲を超えるサブシステムが含まれ、もう一方には、目標を達成しないサブシステムが含まれる。どの場合でも、最近（たとえば過去１０秒以内）に変更されたサブシステムは、リストから排除される。
【０１１３】
その後、達成されない目標のリストをソートする（ステップ１２０８）。一例では、ＷＬＭを使用してこのリストをソートする。というのは、ＷＬＭが、どのサブシステムが最も重要であるかを決定する位置にあるからである。したがって、ＷＬＭは、ＷＬＭがサービスを望む順序でサブシステムを並べる。
【０１１４】
リストをソートした後に、リストの１つまたは複数のサブシステムが、たとえば利用度の低いサブシステムから過度に利用されているサブシステムへ容量をシフトすることによって、サービスされる（ステップ１２１０）。割り当てられた時間内でサービスできる数のサブシステムが調整される。
【０１１５】
容量の調整に関連する論理の一実施形態を、図１５および図１６を参照して説明する。最初、リストからサブシステムを選択する（ステップ１３００、図１５）。一例では、選択されるのは、リストの最初のサブシステムである。その後、問題が宛先ポート使用中であるかどうかに関する判定を行う（問合せ１３０２）。具体的に言うと、競合（たとえば宛先ポート使用中時間）が高いかどうかに関する判定を行い、そうである場合には、それに接続されるさまざまなインターフェースに関してそれが変動するかどうかを判定する。宛先ポート使用中がすべてのインターフェースで高い場合には、これは、別のチャネル・パスを追加する必要があることを意味する。しかし、１つのインターフェースだけで高い場合には、チャネル・パスを別のインターフェースに移動する（ステップ１３０４）。したがって、既存のパスが、過度な宛先ポート使用中時間を有するインターフェースから別のインターフェースに移動され、処理は変更の実施（ステップ１３０６、図１６）に続行する。変更を実施する方法の例が、１９９３年１０月発行の米国特許第５２５７３７９号明細書、１９９３年１０月発行の米国特許第５２５７３６８号明細書、および１９９３年６月発行の米国特許第５２２０６５４号明細書に記載されている。
【０１１６】
変更を実施した後に、目標範囲内にない他のサブシステムがあるかどうかに関する判定を行う（問合せ１３０８）。ない場合には、不平衡訂正の処理が完了する。しかし、他のサブシステムが範囲内にない場合には、この処理は、ステップ１３００「リストの次のサブシステムを選択する」（図１５）に継続する。
【０１１７】
問合せ１３０２に戻って、問題が競合に起因するものでない場合には、処理は、本明細書で説明するように続行される。
【０１１８】
具体的に言うと、一例では、サブシステムに追加することが可能なチャネル・パスを判定する（ステップ１３１０）。この判定には、物理トポロジ内での、その特定のサブシステムに到達することができるすべてのチャネルの検査と、各チャネルについてのそのサブシステムに到達することが可能な経路（パス）の判定が含まれる。パスは、チャネルおよびサブシステムを接続すると共に、その両方を含むハードウェア要素を通る接続順列である。これらのパスのすべて（または、望むならばサブセット）が、可能なパスに含まれる。
【０１１９】
同様に、除去が可能なパスに関する判定を行う（ステップ１３１２）。一例として、同一チャネル上に複数のサブシステムがある場合に、共用するサブシステムに接続されたパスの１つが、除去の候補とみなされる。
【０１２０】
その後、変更によってどのサブシステムが影響を受けるかに関する判定を行う（ステップ１３１４）。さらに、変更される構成の複雑さを示すエントロピ・インデックスも、下で説明するように判定する。
【０１２１】
影響を受けるサブシステムの判定に関連する論理の一実施形態を、図１７を参照して説明する。最初、サブシステムのサブシステム制御ブロック（ＳＳＣＢ）リストおよびチャネルのＣＨＰＩＤリストを、後の使用のためにクリアする（ステップ１４００）。その後、チャネル・パスＩＤを、提案されたチャネルに関連する判断選択ブロック（ＤＳＢ）から取り出し、ＣＨＰＩＤリストに追加する（ステップ１４０２）。具体的に言うと、各パスは、判断選択ブロックを関連付けられている。判断選択ブロックとは、たとえばチャネル・パスのＩＤ（ＣＨＰＩＤ）、チャネル・パスに関連する論理制御装置を示すサブシステム制御ブロック（ＳＳＣＢ）ポインタ、および影響を受けるＳＳＣＢの配列を含む、さまざまな情報を含む制御ブロックである。各ＳＳＣＢには、サブシステムに接続されたチャネルのすべてが含まれる。
【０１２２】
その後、援助されるＳＳＣＢに関連するすべてのＣＨＰＩＤも、ＣＨＰＩＤリストに追加する（ステップ１４０４）。具体的に言うと、ＳＳＣＢポインタを、援助されるＳＳＣＢを示すＤＳＢから取り出す。その後、ＳＳＣＢのＣＨＰＩＤのすべてを、ＣＨＰＩＤリストに追加する。
【０１２３】
その後、リスト内のＣＨＰＩＤのそれぞれについて、チャネル・パスに関連するＳＳＣＢを、ＳＳＣＢリストに追加する（ステップ１４０６）。一例では、この情報は、各ＣＨＰＩＤに接続されたＳＳＣＢを示すチャネル・パス・テーブルから得られる。
【０１２４】
その後、ＳＳＣＢがリストに追加されたかどうかに関する判定を行う（問合せ１４０８）。そうである場合には、リスト内のＳＳＣＢのそれぞれについて、ステップ１４０４に関して上で説明したように、まだＣＨＰＩＤリストに含まれていないＣＨＰＩＤを追加する（ステップ１４１０）。
【０１２５】
その後、リストに追加されたＣＨＰＩＤがあったかどうかに関するもう１つの判定を行う（問合せ１４１２）。リストに追加された他のＣＨＰＩＤがあった場合には、処理はステップ１４０６で継続される。しかし、リストに追加されたＳＳＣＢもＣＨＰＩＤもない場合には（問合せ１４０８および１４１２）、リストのＳＳＣＢのそれぞれについて、ＤＳＢ配列要素を作成する（ステップ１４１４）。すなわち、ＳＳＣＢのそれぞれを、影響を受けるＳＳＣＢの配列に追加する。さらに、配列要素のそれぞれを、実際の入出力速度、目標入出力速度、目標入出力速度と実際の入出力速度の間の現在のデルタ、およびＳＳＣＢポインタを用いて更新する（ステップ１４１６）。
【０１２６】
図１５に戻って、上記に加えて、各パスの可用性インデックスを計算する（ステップ１３１６）。一例では、可用性インデックスは、提案されたパスがサブシステムへの既存のパスと共通して有する単一障害点の個数を示す数である。チャネル・パスを追加する場合には、単一障害点を有しないことが望まれる。チャネル・パスを削除する場合には、通常は、最も多くの単一障害点を有するパスが選択される。
【０１２７】
その後、影響を受けるシステムに対する影響を見積もる（ステップ１３１８）。具体的に言うと、一例では、各サブシステムに対する現在の負荷を調べて、変更を行った場合にそれがどれほど異なるかを判定する。この情報を使用して、最適のオプションを選択する（ステップ１３２０）。最適のオプションを選択するために、たとえば下記を含むさまざまな要因を検討することができる。
・どのオプションでサブシステムが目標の最も近くに移動されるか
・どのオプションが最良の可用性をもたらすか
・どのオプションが最良の対称性（最小のエントロピ）をもたらすか
・このオプションでパスの総数が２未満に減るか
・このオプションは、明示的な目標のどれかに違反するか（ＷＬＭは、デフォルト目標の代わりに使用される明示的目標を供給することができる）
・このオプションは、アーキテクチャ的制限のどれかに違反するか
・このオプションは、インストールによって定義される構成に違反するか
・このオプションは、現在使用不能なリソースの使用を試みるか
【０１２８】
特定の例では、最初、どの状況の下でも実施できない判断選択ブロック（ＤＳＢ）を排除する。これには、たとえば、アーキテクチャ的制限に違反するもの、パスの総数が２未満に減るもの、インストールによって定義される構成に違反するもの（たとえば、定義で許容される最大個数を超える浮動チャネル・パスを使用するもの）、および現在使用不能なリソースの使用を試みるもの（たとえば、使用不能にされたポートの使用を試みるもの）が含まれる。（この機能は、処理のより早い段階に移動し、その結果、可用性インデックスおよびサブシステムに対する影響の見積もりが、絶対に選択できないＤＳＢについて計算されないようにすることができる。）
【０１２９】
現在サブシステムへのパスが１つだけ存在する場合（おそらくはシステム始動のすぐ後または障害の後）、最良の可用性インデックスを有するパスを選択する。複数のパスが同等の可用性インデックスを有する場合には、目標サブシステムを目標入出力速度目標内に移動する最も低いエントロピ・インデックスを有するパスを選択する。複数存在する場合には、その見積もられたデルタの合計（ＤＳＢからの「Σ見積もられたデルタ」）が最小であるパスを選択する。
【０１３０】
現在サブシステムへのパスが複数存在する場合には、最良の可用性インデックスを有するＤＳＢの組を見つける。その組から、目標サブシステムを目標入出力速度の許容範囲内にする、最も低いエントロピ・インデックスを有するオプションを探す。複数存在する場合には、その見積もられたデルタの合計（ＤＳＢからの「Σ見積もられたデルタ」）が最小であるパスを選択する。
【０１３１】
そのようなオプションが存在しない場合には、次によい可用性インデックスを有するパスの組を見つけ、再度試みる。
【０１３２】
どのオプションでもサブシステムを許容範囲内にすることができない場合には、可用性インデックスおよびエントロピ・インデックスを考慮せずに、サブシステムを目標に最も近づけるものを選択する。（上で説明した最適オプション選択のための技法は、一例にすぎない。さまざまな追加、削除、および変更を行うことができる。さらに、他の適当な技法を使用して、最適オプションを選択することができる。）
【０１３３】
最適オプションの選択を試みた後に、明示的目標を有するサブシステムに影響せずに新しい目標を達成できるかどうかに関する判定を行う（問合せ１３２２）。言い換えると、最適オプションが、ＷＬＭによって設定された明示的目標を有するサブシステムに負の影響を及ぼすかどうかを判定する。そうである場合には、ワークロード・マネージャを呼び出して、適当なパスを選択する（ステップ１３２４）。具体的に言うと、ワークロード・マネージャは、パスを選択し、ドナーの新しい目標を選択する。
【０１３４】
その後、または、明示的目標を有するサブシステムに負の影響を及ぼさずに新しい目標を達成できる場合に、変更を実施し（ステップ１３０６）、処理は、目標範囲内にない他のサブシステムが存在するかどうかの判定（問合せ１３０８）に継続する。
【０１３５】
上で述べたように、ＷＬＭは、明示的入出力速度目標を設定することができ、これは、デフォルト平均入出力速度目標の代わりに使用される。一実施形態では、サービス・クラスがその目標を満たさないことをＷＬＭが見つけた時に、ＷＬＭが明示的目標を設定する。明示的サブシステム入出力速度目標の設定に関連する論理の一実施形態を、図１８を参照して説明する。
【０１３６】
最初、入出力が最大の遅延を引き起こしているかどうかを判定する（問合せ１５００）。そうでない場合には、ここでの目的に照らして、処理が完了する。しかし、入出力が最大の遅延を引き起こしている場合には、入出力優先順位調整を試みる（ステップ１５０２）。その後、サービス・クラスがその目標を満たしているかどうかに関する判定を行う（問合せ１５０４）。サービス・クラスがその目標を満たしている場合には、処理が完了する。しかし、サービス・クラスが、まだその目標を満たしていない場合には、そのサービス・クラスによって使用されており、低い入出力速度を有するサブシステムを探す（ステップ１５０６）。突きとめられた１つまたは複数のサブシステムについて、新しいサブシステム入出力速度目標を設定する。一例では、定義済みの量だけ現在の目標を増やし、サブシステムに対する影響を見積もることによって、サブシステム入出力速度目標が設定される。影響が十分である（たとえば、レシーバ値を超える）場合には、処理が完了する。そうでない場合には、目標をもう一度増やし、この処理を繰り返す。
【０１３７】
上で詳細に説明したのは、入出力構成の動的調整を提供する動的ＣＨＰＩＤ管理（ＤＣＭ）である。ＤＣＭは、ＷＬＭに有利に統合され、これによって、ワークロードおよび目標の理解を用いて判断を行えるようになる。さらに、ＤＣＭを用いると、複数の区画（たとえば区画のグループの区画）にまたがるチャネルの管理が可能になる。これによって、必要な場所へのリソースの追加、および余分なリソースの除去が可能になる。
【０１３８】
上で説明したように、動的ＣＨＰＩＤ管理（ＤＣＭ）を用いて、サブシステムに追加（またはそれから除去）される「最適の」チャネルが選択される。これを行うために、たとえば結果の入出力構成の複雑さ（またはエントロピ）を含む、１つまたは複数の属性が試験される。
【０１３９】
エントロピの増加は、入出力構成を過度に複雑にし、ＤＣＭの処理の過度な時間、影響を受けるサブシステムの過剰な数に起因する不正確な結果、性能報告の複雑さ、および問題判別の複雑さをもたらす。したがって、本発明の好ましい実施形態では、異なる選択肢の相対エントロピを判定し、その結果、構成をどのように調整するかの選択を行う時に、入出力速度および可用性などの他の検討点と共に、相対エントロピを検討できるようにする機能が提供される。
【０１４０】
相対エントロピを判定する際には、エントロピ・インデックスを計算する。たとえば、パスを追加する場合には、エントロピ・インデックスは、結果の構成のチャネル数およびサブシステム数の合計になる。さらに、パスを削除する場合には、エントロピ・インデックスは、パスが削除された後に目標サブシステムに相互接続されているチャネルおよびサブシステムの組を反映する。これには、もはやその組に含まれないチャネルおよびサブシステムは含まれない。
【０１４１】
各オプションのエントロピの度合を計算するために、判断が実施されると仮定して、一緒に接続されるチャネルおよびサブシステムの数を使用する。エントロピ技法の基本的な前提の１つが、複数の提案されたトポロジの間の比較と、どのトポロジがより対称であるか、またはより少ないエントロピを有するかの判定とを可能にするインデックスを計算することである。これの目的は、大規模な相互接続されたトポロジを避けることである。このようなトポロジは、入出力速度技法の精度を下げ、過度に複雑なトポロジに起因して、事後に性能問題を分析することを困難にすると思われる。
【０１４２】
エントロピ判定技法の一実施形態をさまざまな例で説明する。たとえば、図１９は、２つのサブシステム１６０４に接続された２つのチャネル１６０２を含む構成１６００の一例を示す図である。サブシステム２２は、追加リソースを必要とする場合に、少なくとも２つの場所からそれを得ることができる。サブシステム２２は、チャネル１またはチャネル３のいずれかからそれを受け取ることができる。サブシステム２２がチャネル３からそれを得る場合、結果の構成は、３つのチャネルと２つのサブシステムを有する（図２０）。これによって、この構成に５（３＋２）のエントロピ・インデックスが与えられる。しかし、サブシステム２２が、チャネル１から追加リソースを受け取る場合（図２１）、結果の構成は、元々有したもの以上のチャネルもサブシステムも有しておらず、結果のエントロピ・インデックスは２になる。この例では、第２のオプションが最小のエントロピを有する。
【０１４３】
もう１つの例を検討する。図２２に示された例では、サブシステム２３が、追加リソースを必要としている。それは、チャネル２またはチャネル４から得ることができる。チャネル２が使用される場合（図２３）、結果のエントロピ・インデックスは５になる（すなわち、１つの構成で３つのチャネルが２つのサブシステムに相互接続されている。チャネル４は、接続されていないのでカウントされない）。チャネル４が使用される場合（図２４）、結果のインデックスは３になる。したがって、第２のオプションが最小のエントロピを有する。
【０１４４】
次に、構成が分割される場合を検討して、これがエントロピにどのように影響するかを見てみる。
【０１４５】
図２５を参照すると、サブシステム２３が、過度の容量を有する場合に、チャネル２またはチャネル３を除去することができる。チャネル２を除去する場合（図２６）、構成が分割され、両方の構成のエントロピ・インデックスが下がる。チャネル３を除去する場合（図２７）、まだ１つの構成が存在するが、エントロピ・インデックスは元のインデックスより低い。一実施形態では、構成を２つに分割するという判断は、２つのより複雑でないネットワークをもたらし、よりよい選択肢であると思われる。
【０１４６】
削除の際に、既存の構成（図２８）のインデックスならびに考慮中のサブシステムを含む提案された構成（図２９の右側）のインデックスが既知である場合には、もう一方の構成（図２９の左側）のインデックスは、減算によって計算することができる。この例では、もう一方の構成のインデックスは、２に等しい（４−３＝１かつ２−１＝１、したがって１＋１＝２）。図３０のように、サブシステムまたはチャネルの数についての減算結果が０になる場合には、エントロピは、構成を分割せずに減らされている。（たとえば、２サブシステム−２サブシステム＝０。）一実施形態では、分割が好ましい。
【０１４７】
次の例では、サブシステム２３が、過剰なリソースを有する（図３１）。チャネル２またはチャネル３を除去することができる。チャネル３を除去する場合（図３２）、結果のエントロピ・インデックスは７になる。チャネル２を除去する場合（図３３）、構成が２つの構成に分割され、考慮中の構成（サブシステム２３を有する構成）は、５のエントロピ・インデックスを有し、結果の第２の構成は、３のエントロピ・インデックスを有する。一実施形態では、構成の分割が好ましい。
【０１４８】
次に、結果のエントロピ値ではなく、削除の際に分割を探すことだけが望まれる場合を判定するための例を検討する。
【０１４９】
図３４に示された例では、サブシステム２３が、多すぎる帯域幅を有する。チャネル２またはチャネル４のいずれかを除去することができる。チャネル２を除去する場合（図３５）、新しいエントロピ・インデックス６が得られ、残りの第２の構成のエントロピ・インデックスは３である。チャネル４を除去する場合（図３６）、新しいエントロピ・インデックス５が得られ、残りの第２の構成のエントロピ・インデックスは４である。５および４のエントロピ・インデックスを有する構成が、よりよい選択肢である。したがって、一実施形態では、分割の種類が重要である。
【０１５０】
図３７に示された例では、サブシステム２３が、追加リソースを必要としている。サブシステム２１をチャネル２から除去し（図３８）、サブシステム２３にチャネル２のすべてのリソースを与えることができ、また、サブシステム２５をチャネル４から除去し（図３９）、サブシステム２３にチャネル４のすべてのリソースを与えることができる。
【０１５１】
サブシステム２１をチャネル２から除去する場合、結果のエントロピ・インデックスは７であり、結果の第２の構成のエントロピ・インデックスは２である。サブシステム２５をチャネル４から除去する場合、結果のエントロピ・インデックスは６であり、残りの第２の構成は３である。一実施形態では、分割が均等により近いので、第２の選択肢がより良いと思われる。
【０１５２】
どのオプションが２等分（すなわち「均等」）により近いかを計算するために、新しいエントロピ・インデックスと結果の第２の構成のエントロピ・インデックスとの間で、チャネルおよびサブシステムの数の差を判定する。この例では、第１の選択肢は、７および２のエントロピ・インデックスをもたらすので、差は５である（すなわち、対称インデックス）。第２の選択肢は、６および３のエントロピ・インデックスをもたらすので、差は３である。より少ない差を有する選択肢が、この実施形態では最良の選択肢である。
【０１５３】
結論を出すと、一実施形態では、サブシステムを目標入出力速度に近づけないオプションが、排除される。さらに、エントロピ・インデックスが、結果の構成で相互接続されているチャネルおよびサブシステムの総数を加算することによって計算される。エントロピ・インデックスが変化しない場合には、その変更は対称である。最低のエントロピ・インデックスを有する構成が、通常は選択される。より高いエントロピ・インデックスを有する構成を選択することを意味する場合であっても、８つを超えるチャネルを有する構成を選択することは回避すべきである。代替案がない場合には、８つを超えるチャネルを有する構成を選択し、うまくいけば、次のインターバルにこの構成が分割されることになる。
【０１５４】
上記の実施形態の変形形態を、入出力構成に関連して説明してきたが、ここで述べた機能は、ストレージ・エリア・ネットワークその他のネットワークに同等に適用可能である。
【０１５５】
上で説明したのは、コンピュータ環境のリソースを管理するためのさまざまな機構である。物理共用可能リソースが、コンピュータ環境の論理区画にまたがって管理される。論理区画はグループ化され、たとえば優先順位に基づくリソース割振りによるリソース共用を可能にする。このリソース共用には、たとえば、ＬＰＡＲにまたがるＣＰＵリソースの動的管理、ＬＰＡＲにまたがる動的ＣＨＰＩＤ管理、チャネル・サブシステム内の入出力優先順位キューイング、およびＬＰＡＲにまたがるメモリの動的管理が含まれる。
【０１５６】
一例では、システムのワークロード・マネージャが、少なくとも部分的にこの管理の責任を負う。共用可能リソースは、アプリケーションのサブシステムにとって透過的なワークロード・マネージャ指示の下で、ＬＰＡＲにまたがって動的に再分配される。リソースは、モニタリング活動および顧客の目標に基づいて、必要な区画に供給される。さらに、たとえばＷＬＭ、シスプレックス、およびＰＲ／ＳＭ統合を介する、ワークロード目標による物理リソースの動的調整は、並列シスプレックス・データ共用を必要とせずに実行される。
【０１５７】
上で説明した実施形態では、さまざまなコンピュータ環境およびシステムを説明した。これらは、例にすぎず、本発明の範囲を制限する目的のものではない。同様に、本明細書で示した流れ図は、例示にすぎない。これらの図またはステップ（または動作）に対する多数の変形形態があり得る。たとえば、ステップを適宜異なる順序で実行することができ、ステップを追加、削除、または変更することができる。
【図面の簡単な説明】
【図１】 コンピュータ環境の一例を示す図である。
【図２】 コンピュータ環境のもう１つの実施形態を示す図である。
【図３】 コンピュータ環境の追加構成要素を示す図である。
【図４】 論理区画グループの一例を示す図である。
【図５】 グループに加入する区画に関連する論理の一例を示す図である。
【図６】 グループに加入する区画に関連する論理の一例を示す図である。
【図７】 グループからの区画の除去に関連する論理の一実施形態を示す図である。
【図８】 区画のレシーバ・サービス・クラスを助けるための、区画の重みを増やすことができるかどうかの判定に関連する論理の一実施形態を示す図である。
【図９】 論理プロセッサの構成の動的調整に関連する論理の一実施形態を示す図である。
【図１０】 チャネル・サブシステムの一実施形態を示す図である。
【図１１】 入出力動作の選択に関連する論理の一実施形態を示す図である。
【図１２】 入出力構成を調整しなければならないかどうかの判定に関連する論理の一実施形態を示す図である。
【図１３】 図１２のデータ収集に関連する論理の一実施形態を示す図である。
【図１４】 図１２の平衡検査に関連する論理の一実施形態を示す図である。
【図１５】 入出力構成の不平衡の訂正に関連する論理の一実施形態を示す図である。
【図１６】 入出力構成の不平衡の訂正に関連する論理の一実施形態を示す図である。
【図１７】 影響を受けるサブシステムの判定に関連する論理の一実施形態を示す図である。
【図１８】 明示的入出力速度目標の設定に関連する論理の一実施形態を示す図である。
【図１９】 エントロピ判定に使用される入出力構成の一例を示す図である。
【図２０】 エントロピ判定に使用される入出力構成の一例を示す図である。
【図２１】 エントロピ判定に使用される入出力構成の一例を示す図である。
【図２２】 エントロピ判定に使用される入出力構成の一例を示す図である。
【図２３】 エントロピ判定に使用される入出力構成の一例を示す図である。
【図２４】 エントロピ判定に使用される入出力構成の一例を示す図である。
【図２５】 エントロピ判定に使用される入出力構成の一例を示す図である。
【図２６】 エントロピ判定に使用される入出力構成の一例を示す図である。
【図２７】 エントロピ判定に使用される入出力構成の一例を示す図である。
【図２８】 エントロピ判定に使用される入出力構成の一例を示す図である。
【図２９】 エントロピ判定に使用される入出力構成の一例を示す図である。
【図３０】 エントロピ判定に使用される入出力構成の一例を示す図である。
【図３１】 エントロピ判定に使用される入出力構成の一例を示す図である。
【図３２】 エントロピ判定に使用される入出力構成の一例を示す図である。
【図３３】 エントロピ判定に使用される入出力構成の一例を示す図である。
【図３４】 エントロピ判定に使用される入出力構成の一例を示す図である。
【図３５】 エントロピ判定に使用される入出力構成の一例を示す図である。
【図３６】 エントロピ判定に使用される入出力構成の一例を示す図である。
【図３７】 エントロピ判定に使用される入出力構成の一例を示す図である。
【図３８】 エントロピ判定に使用される入出力構成の一例を示す図である。
【図３９】 エントロピ判定に使用される入出力構成の一例を示す図である。

Claims (2)

1. コンピュータ環境のワークロードを管理するシステムであって、
   前記コンピュータ環境の１つまたは複数の論理区画を含むグループが論理区画の加入または削除によって変更されたことを決定する手段と、
   前記決定に応答して、前記グループ内で前記グループのリソースの割振りを動的に調整する手段とを含み、
   前記動的に調整する手段は、前記論理区画の加入の場合には、該加入により増加したリソースを前記グループ内で再分配し、前記論理区画の削除の場合には、該削除により減少したリソースを前記グループ内で再分配する、
   システム。
2. 前記リソースがＣＰＵ処理重みであり、前記動的に調整する手段は、前記グループから論理区画が削除されるときに、該論理区画の現在の処理重みと初期処理重みとの差に基づいて前記グループ内でＣＰＵ処理重みを再分配する、請求項１に記載のシステム。

Images