JP4028674B2 - 多重システム・クラスタ内のサーバの数を制御する方法及び装置 - Google Patents
多重システム・クラスタ内のサーバの数を制御する方法及び装置 Download PDFInfo
- Publication number
- JP4028674B2 JP4028674B2 JP2000126482A JP2000126482A JP4028674B2 JP 4028674 B2 JP4028674 B2 JP 4028674B2 JP 2000126482 A JP2000126482 A JP 2000126482A JP 2000126482 A JP2000126482 A JP 2000126482A JP 4028674 B2 JP4028674 B2 JP 4028674B2
- Authority
- JP
- Japan
- Prior art keywords
- queue
- server
- work
- performance
- class
- 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
-
- 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
-
- 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/5083—Techniques for rebalancing the load in a distributed system
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/50—Indexing scheme relating to G06F9/50
- G06F2209/505—Clust
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Multi Processors (AREA)
- Small-Scale Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、第１のサービス・クラスに属する入来作業要求が、１つ以上のサーバによる処理のために、キューに配置される情報処理システムにおいて、サーバの数を制御する方法及び装置に関する。
【０００２】
【従来の技術】
使用可能なサーバへの割当てのために、入来作業要求がキューに配置されるシステムは周知である。入来作業要求が到来する頻度は、容易に制御され得ないので、こうしたキュー待機型システムにおいて、システム性能（キュー遅延などにより測定される）を制御する基本手段は、サーバの数を制御することである。従って、サービスされるキューの長さが特定の高いしきい値に達するとき、追加のサーバを始動したり、サービスされるキューの長さが特定の低いしきい値に達するとき、サーバを停止することが知られている。こうした手段は、その設計目的を達成するが、キューに待機された作業要求に加え、他の作業単位がシステム資源を競合するシステムでは不十分である。従って、たとえキューに対して追加のサーバを提供することで、そのキュー内における作業要求の性能を向上しても、こうしたサーバの提供は、システムにより処理される他の作業単位の性能を低下し得、システムの性能を全体として悪化し得る。
【０００３】
ほとんどの今日のオペレーティング・システム・ソフトウェアは、作業要求に対して指定されるエンドユーザ指向の目的に従い、サーバの数を管理し、同一のコンピュータ・システム内で実行される、独立の目標を有する他の作業を考慮する責任を負うことができない。
【０００４】
本願の出願人に権利譲渡された１９９７年３月２８日付けのJ. D. Amanらによる継続中の米国特許出願第８２８４４０号は、特定のシステムにおいて、サーバの数を制御する方法及び装置を開示し、そこでは第１のサービス・クラスに属する入来作業要求が、１つ以上のサーバによる処理のためにキューに配置される。本システムは更に、システム資源のドナー（donor）として作用する、少なくとも１つの他のサービス・クラスに割当てられる作業単位を有する。本発明によれば、性能測定が第１のサービス・クラスの他に、少なくとも１つの他のサービス・クラスに対して定義される。サーバを第１のサービス・クラスに追加する以前に、第１のサービス・クラスの性能測定に及ぼすプラスの効果だけでなく、他のサービス・クラスの性能測定に及ぼすマイナスの効果も決定される。第１のサービス・クラスの性能測定に及ぼすプラスの効果が、他のサービス・クラスの性能測定に及ぼすマイナスの効果に勝る場合に限り、サーバが第１のサービス・クラスに追加される。
【０００５】
【発明が解決しようとする課題】
この継続中の特許出願で開示される発明は、サーバを追加するか否かを決定するとき、他の作業に対する影響を考慮するが、これは単一システムの状況においてそのようにする。しかしながら、多重システム・コンプレックス（"シスプレックス（sysplex）"）では、作業要求の１つのキューが、コンプレックスに渡り複数のサーバによりサービスされる。従って、所与のキューに対して、サーバを追加するか否かだけでなく、シスプレックス全体の性能を最適化するために、サーバをどこに追加すべきかが決定され得る。
【０００６】
【課題を解決するための手段】
本発明は、情報処理システムのクラスタ内のサーバの数を制御する方法及び装置に関して、そこでは第１のサービス・クラスに属する入来作業要求が、１つ以上のサーバによる処理のためにキューに配置される。入来作業要求のあるものは、クラスタ内のサーバのサブセット上でのみ実行されるための要求を有し得る。こうした要求を有する作業要求は、それらが実行されなければならないクラスタ内のシステムのサブセットに対して、"親和性（affinity）"を有すると言われる。本発明によれば、サーバがクラスタ内の１つ以上のシステム上で始動され、キュー内の作業要求を処理する。これらのサーバを始動するシステムは、システムのクラスタの全容量を利用するように、及び作業要求の親和性要求に応じるように、更にクラスタ内のシステム上で実行されているかも知れない他の作業への影響を最小化するように選択される。新たなサーバが始動されるシステムはまた、システム資源のドナーとして作用する第２のサービス・クラスに割当てられる作業単位を有する。本発明によれば、性能測定が第１のサービス・クラス同様、第２のサービス・クラスに対しても定義される。サーバを第１のサービス・クラスに追加する以前に、第１のサービス・クラスの性能測定に及ぼすプラスの効果だけでなく、第２のサービス・クラスの性能測定に及ぼすマイナスの効果も決定される。第１のサービス・クラスの性能測定に及ぼすプラスの効果が、第２のサービス・クラスの性能測定に及ぼすマイナスの効果に勝る場合に限り、サーバが第１のサービス・クラスに追加される。
【０００７】
本発明は、複数のユーザ性能目標クラスの各々に対して、各目標クラスの性能目標にもとづき、システムのクラスタに渡るサーバの数のシステム管理を可能にする。競合する目標クラスに対して、サーバの追加または除去の影響を考慮するトレードオフが提供される。
【０００８】
【発明の実施の形態】
本発明を組み込むシステムについて述べる前準備として、作業負荷管理（本発明がそれ上で構成される）の概念に関して前置きすることが適切であろう。
【０００９】
作業負荷管理は、オペレーティング・システムにより管理される作業単位（プロセス、スレッドなど）が、クラス（サービス・クラスまたは目標クラスと呼ばれる）に編成される概念であり、クラスは予め定義された目標にどれ程よく合致するかに従い、システム資源を提供される。ドナー・クラスからレシーバ（receiver）・クラスへの資源の再割当ては、こうした再割当てから得られるレシーバ・クラスの性能の改善が、ドナー・クラスの性能の劣化に勝る場合、すなわち、予め定義された性能基準により決定される性能における、正味のプラス効果が存在する場合に実行される。このタイプの作業負荷管理は、資源の割当てが資源が再割当てされる作業単位への効果だけにより決定されるのではなく、資源が奪われる作業単位への効果によっても決定されるという点で、大部分のオペレーティング・システムにより実行される"普通の（run-of-the-mill）"資源管理とは異なる。
【００１０】
この一般的なタイプの作業負荷マネージャは、以下に挙げる特許、特許出願、及び特許以外の刊行物において開示されている。
【００１１】
D. F. Fergusonらによる米国特許出願第５５０４８９４号"Workload Manager for Achieving Transaction Class Response Time Goals in a Multiprocessing System"。
J. D. Amanらによる米国特許第５４７３７７３号"Apparatus and Method for Managing a Data Processing System Workload According to Two or More Distinct Processing Goals"。
C. K. Eilertらによる米国特許第５５３７５４２号"Apparatus and Method for Managing a Server Workload According to Client Performance Goals in a Client/Server Data Processing System"。
J. D. Amanらによる米国特許第５６０３０２９号"System of Assigning Work Requests Based on Classifying into an Eligible Class Where the Criteria Is Goal Oriented and Capacity Information is Available"。
C. K. Eilertらによる米国特許第５６７５７３９号"Apparatus and Method for Managing a Distributed Data Processing System Workload According to a Plurality of Distinct Processing Goal Types"。
１９９５年２月３日付けのC. K. Eilertらによる米国特許出願第３８３０４２号"Multi-System Resource Capping"。
１９９５年６月７日付けのJ. D. Amanらによる米国特許出願第４８８３７４号"Apparatus and Accompanying Method for Assigning Session Requests in a Multi-Server Sysplex Environment"。
１９９７年３月２８日付けのJ. D. Amanらによる米国特許出願第８２８４４０号"Method and Apparatus for Controlling the Number of Servers in a Client/Server System"。
MVS Planning：Workload Management、ＩＢＭ刊行物GC28-1761-00、１９９６年。
MVS Programming：Workload Management Services、ＩＢＭ刊行物GC28-1773-00、１９９６年。
【００１２】
前記特許及び刊行物の中で、米国特許第５５０４８９４号及び同第５４７３７７３号は、基本的な作業負荷管理システムを開示し、米国特許第５５３７５４２号は、米国特許第５４７３７７３号の作業負荷管理システムの、クライアント／サーバ・システムへの特定のアプリケーションを開示し、米国特許第５６７５７３９号及び米国特許出願第３８３０４２号は、米国特許第５４７３７７３号の作業負荷管理システムの、複数の相互接続システムへの特定のアプリケーションを開示し、米国特許第５６０３０２９号は、多重システム・コンプレックス（"シスプレックス"）における作業要求の割当てに関して、米国特許出願第４８８３７４号は、こうしたコンプレックスにおけるセッション要求の割当てに関して、前述のように、米国特許出願第８２８４４０号は、多重システム・コンプレックスの１つのシステム上でのサーバの数の制御に関する。特許以外の２つの刊行物は、ＩＢＭ（登録商標）ＯＳ／３９０（商標）（以前はＭＶＳ（登録商標））オペレーティング・システムにおける作業負荷管理の実現について述べている。
【００１３】
図１は、本発明の一般的な実施例における主要な環境及びフィーチャを示し、相互接続され、協働するコンピュータ・システム１００のクラスタ９０を含み、それらの一般的な２つが示されている。本発明の環境は、作業要求１６２のキュー１６１と、クラスタ９０に渡り分散され、作業要求をサービスするサーバ１６３のプールとを含む。本発明は、キューに待機された作業の性能目標クラスと、コンピュータ・システム１００内で競合する作業の性能目標クラスとにもとづき、サーバ１６３の数の管理を可能にする。コンピュータ・システム１００のクラスタ９０に対して１つのポリシを有することは、分散された作業負荷の単一イメージ・ビューを提供するのに役立つ。当業者であれば、任意の数のコンピュータ・システム１００、及び１つのコンピュータ・システム１００内の任意の数のこうしたキュー１６１及びサーバ１６３のグループが、本発明の趣旨及び範囲から逸れることなく使用され得ることが理解されよう。
【００１４】
コンピュータ・システム１００は分散された作業負荷を実行し、各コンピュータ・システムが、例えばＩＢＭ ＯＳ／３９０オペレーティング・システムなどの、オペレーティング・システム１０１の自身のコピーにより制御される。
【００１５】
それぞれのコンピュータ・システム１００上のオペレーティング・システム１０１の各コピーは、本願で述べられるステップを実行する。説明の中で"ローカル"・システム１００を指し示すとき、それは述べられているステップを実行しているシステム１００を意味する。一方、"リモート"・システム１００は、管理される他の全てのシステム１００を意味する。各システム１００がそれ自身を局所的（ローカル）と見なし、他の全てのシステム１００を遠隔的と見なす点に留意されたい。
【００１６】
本発明に関する改良以外は、システム１００は、継続中の米国特許出願第８２８４４０号及び米国特許第５６７５７３９号で開示されるシステムと類似である。図１に示されるように、システム１００は複数の相互接続されるシステム１００の１つであり、これらは同様に管理され、クラスタ９０（システム・コンプレックスまたはシスプレックスとも呼ばれる）を構成する。米国特許第５６７５７３９号で教示されるように、作業単位が分類される様々なサービス・クラスの性能が、特定のシステム１００に対してだけでなく、クラスタ９０全体に対しても追跡され得る。この目的のために、また後述の説明から明らかになるように、システム１００とクラスタ９０内の他のシステム１００との間で、性能結果を伝達し合う手段が提供される。
【００１７】
ディスパッチャ１０２は、オペレーティング・システム１０１の構成要素であり、次にコンピュータにより実行される作業単位を選択する。作業単位は、コンピュータ・システム１００の目的に相当する有用な作業を実行するアプリケーション・プログラムである。実行準備が整った作業単位は、アドレス空間制御ブロック（ＡＳＣＢ）・キューと呼ばれる、オペレーティング・システム・メモリ内の制御ブロックの連鎖により表される。
【００１８】
作業マネージャ１６０は、オペレーティング・システム１０１の外部の構成要素であり、これはオペレーティング・システム・サービスを用いて、１つ以上のキュー１６１を作業負荷マネージャ（ＷＬＭ）１０５に定義し、作業要求１６２をこれらのキュー上に挿入する。作業マネージャ１６０は、挿入された作業要求１６２を、クラスタ９０内の任意のシステム１００上の作業マネージャ１６０のサーバ１６３による選択のために、先入れ先出し（ＦＩＦＯ）順に保持する。作業マネージャ１６０は、サーバが、それが実行されているシステム１００と親和性を有する要求だけを選択することを保証する。
【００１９】
サーバ１６３は作業マネージャ１６０の構成要素であり、キューに待機された作業要求１６２をサービスすることができる。作業負荷マネージャ１０５がサーバ１６３を始動し、作業マネージャ１６０のキュー１６１上の作業要求１６２をサービスするとき、作業負荷マネージャ１０５は、共用データ機構１４０上に記憶されたサーバ定義を用いて、アドレス空間（すなわちプロセス）１６４を始動する。作業負荷マネージャ１０５により始動されるアドレス空間１６４は、作業負荷マネージャ１０５の指示に従い、そのアドレス空間がサービスすべき特定のキュー１６１上の要求１６２をサービスする、１つ以上のサーバ（すなわちディスパッチ可能単位またはタスク）１６３を含む。
【００２０】
図２は、コンピュータ・システム１００が接続されるネットワーク（図示せず）から、作業負荷マネージャ１０５により管理されるサーバ・アドレス空間１６４への、クライアント作業要求１６２の流れを示す。作業要求１６２はクラスタ９０内の特定のコンピュータ・システム１００に経路指定され、作業マネージャ１６０により受信される。作業要求１６２の受信に際して、作業マネージャ１６０はそれを作業負荷マネージャ（ＷＬＭ）・サービス・クラスに分類し、作業要求を作業キュー１６１に挿入する。作業キュー１６１は、クラスタ９０内の全てのコンピュータ・システム１００により共用される。すなわち、作業キュー１６１はクラスタ全体に渡るキューである。作業要求１６２は、それを実行する準備が整ったサーバが現れるまで、作業キュー１６１内で待機する。
【００２１】
新たな作業要求１６２を実行する準備が整った（アドレス空間が丁度始動されたか、タスクが前の要求の実行を終了したとき）、クラスタ９０内のあるシステム１００上のサーバ・アドレス空間１６４内のタスク１６３が、新たな作業要求のために作業マネージャ１６０を呼び出す。アドレス空間１６４がサービスしている作業キュー１６１上に作業要求１６２が存在し、その作業要求がサーバが実行されているシステム１００と親和性を有する場合、作業マネージャ１６０はその作業要求をサーバ１６３に受け渡す。それ以外では、作業マネージャ１６０は作業要求１６２が有効になるまで、サーバ１６３を延期する。
【００２２】
作業要求１６２が作業マネージャ１６０により受信されるとき、それは作業キュー１６１上に配置され、サーバ１６３が作業要求を実行するために使用可能になるのを待機する。作業要求１６２の作業マネージャ１６０、アプリケーション環境名、及びＷＬＭサービス・クラスのそれぞれの固有の組み合わせに対して、１つの作業キュー１６１が存在する。（アプリケーション環境は、類似のクライアント作業要求１６２のセットが実行されるべき環境である。ＯＳ／３９０条件では、これは作業要求を実行するために、サーバ・アドレス空間を始動するために使用されるジョブ制御言語（ＪＣＬ）プロシージャにマップされる。）特定の作業キュー１６１に対して、第１の作業要求１６２が到来するとき、キューイング構造が動的に生成される。作業キュー１６１に対して、所定時間（例えば１時間）何も活動が発生しなかった場合、構造は消去される。新たなＷＬＭポリシを活動化するなどのように、キューに待機された作業要求１６２のＷＬＭサービス・クラスを変更し得るアクションが発生する場合、作業負荷マネージャ１０５は作業マネージャ１６０にその変更を知らせ、作業マネージャ１６０は、各作業要求１６２の新たなＷＬＭサービス・クラスを反映するように、作業キュー１６１を再生する。
【００２３】
サーバ１６３を有さないシステム１００と親和性を有する作業要求１６２は、他のシステム１００上に、その作業要求のサービス・クラスの目標を満たす上で十分なサーバが存在する場合、決して実行されないといった危険性が存在する。この危険性を回避するために、作業負荷マネージャ１０５は、クラスタ９０内のどこかに、キュー１６１上の各作業要求を実行可能な少なくとも１つのサーバ１６３が存在するように保証する。図８はこの論理を示す。この論理は、クラスタ９０内の各コンピュータ・システム１００上の作業マネージャ１６０により実行される。
【００２４】
ステップ７０１で、作業マネージャ１６０が自身が所有する第１のキュー１６１を調査する。ステップ７０２で、作業マネージャ１６０が、ローカル・システム１００上にこのキュー１６１に対するサーバ１６３が存在するか否かをチェックする。サーバ１６３が存在する場合、作業マネージャ１６０は次のキュー１６１に移行する（ステップ７０８乃至７０９）。作業マネージャ１６０が、局所的にサーバ１６３を有さないキュー１６１を見い出す場合、作業マネージャ１６０は次にキュー上の各作業要求を調査し、第１の作業要求を開始する（ステップ７０３乃至７０６）。各作業要求１６２に対して、作業マネージャ１６０は、クラスタ９０内のどこかに、現作業要求を実行可能なサーバ１６３が存在するか否かをチェックする（ステップ７０４）。現作業要求を実行可能なサーバ１６３が存在する場合、作業マネージャ１６０はキュー１６１上の次の作業要求１６２に移行する（ステップ７０６）。現作業要求を実行可能なサーバ１６３が存在しない場合、作業マネージャ１６０は作業負荷マネージャ１０５を呼び出し、サーバ１６３を始動し（ステップ７０７）、次のキュー１６１に移行する（ステップ７０８乃至７０９）。作業マネージャ１６０は、作業マネージャにより所有される全てのキュー１６１が処理されるまで（ステップ７１０）、同様に継続する。
【００２５】
作業マネージャ１６０が作業負荷マネージャ１０５を呼び出すとき（ステップ７０７）、作業要求に対してサーバを始動すべき最善のシステム１００を決定するために、作業負荷マネージャ１０５は、クラスタ９０内の各システム１００に対して、各重要度にて有効なサービス、及びそのシステムに対して未使用のサービスを示す、サービス有効配列（Service Available Array）を保持する。この配列は下記のように、各重要度に対するエントリ、及び未使用のサービスに対するエントリを含む。
【００２６】
配列要素 配列要素内容
配列要素１ 重要度０にて有効なサービス
配列要素２ 重要度１にて有効なサービス
配列要素３ 重要度２にて有効なサービス
配列要素４ 重要度３にて有効なサービス
配列要素５ 重要度４にて有効なサービス
配列要素６ 重要度５にて有効なサービス
配列要素７ 重要度６にて有効なサービス
配列要素８ 未使用サービス
【００２７】
サービス有効配列は、本願の出願人に権利譲渡された、１９９７年３月２８日付けのC. K. Eilertらによる米国特許出願第８２７５２９号"Managing Processor Resources in a Multisystem Environment"でも述べられている。
【００２８】
作業負荷マネージャ１０５は、要求のサービス・クラスの重要度にて有効な最大限のサービスにより、システム１００上で新たなサーバを始動する。続くアドレス空間１６４は、作業負荷をサポートすることが要求されるときに始動される（後述のポリシ調整を参照）。好適には、アドレス空間１６４を始動する機構は、自動的にアドレス空間を始動する他の実施例における共通の問題を回避するための、幾つかのフィーチャを有する。従って、アドレス空間１６４の始動は好適には、１度に１つの始動だけが進行するように歩調を合わされる。この歩調合わせは、システム１００にアドレス空間１６４の始動が殺到することを回避する。
【００２９】
また、所定の連続的な始動失敗（例えば３度の失敗）に遭遇するとき、所与のアプリケーション環境においては、追加のアドレス空間１６４の生成を回避するための特殊論理が、好適には提供される。こうした失敗が起こり得る原因として、アプリケーション環境における、ＪＣＬプロシージャのＪＣＬエラーが考えられる。前述の特殊論理の提供は、ＪＣＬエラーが訂正されるまで、成功裡に始動しないアドレス空間を始動しようとするループに入り込むことを回避する。
【００３０】
更に、作業要求１６２を実行する間に、サーバ・アドレス空間１６４が失敗する場合、作業負荷マネージャ１０５は好適には、それを置換するための新たなアドレス空間を始動する。失敗が繰り返されると、作業負荷マネージャ１０５は、オペレータ・コマンドにより問題が解決されたことを知らされるまで、そのアプリケーション環境において、作業要求の受諾を停止する。
【００３１】
所与のサーバ・アドレス空間１６４は、たとえそれが通常、１つの作業キュー１６１だけをサービスするとしても、そのアプリケーション環境において、物理的にあらゆる作業要求１６２をサービスすることができる。好適には、サーバ・アドレス空間１６４は、もはやその作業キュー１６１をサポートする必要がないときでも、即時終了されない。代わりに、サーバ・アドレス空間１６４は、ある期間"フリー・エージェント"として待機し、同一のアプリケーション環境において、別の作業キュー１６１をサポートするために使用され得るか否かを調査する。サーバ・アドレス空間１６４が新たな作業キュー１６１にシフトされ得る場合、その作業キューに対して新たなサーバ・アドレス空間を始動するオーバヘッドが回避される。所定時間（例えば５分）内に、サーバ・アドレス空間１６４が別の作業キュー１６１により必要とされない場合、それは終了される。
【００３２】
本発明は入力としてシステム管理者により確立され、データ記憶機構１４０に記憶された性能目標１４１及びサーバ定義を受け取る。データ記憶機構１４０は、管理される各システム１００によりアクセス可能である。ここで示される性能目標には２つのタイプ、すなわち応答時間（秒）と、実行速度（％）とがある。当業者であれば、本発明の趣旨及び範囲から逸れることなく、他の目標または追加の目標が選択され得ることが理解できよう。性能目標には、各目標の相対重要度の指定が含まれる。性能目標１４１が、管理される各システム１００のオペレーティング・システム１０１の作業負荷マネージャ要素１０５により、システム内に読出される。システム管理者により確立され、指定された性能目標の各々は、各システム１００上の作業負荷マネージャ１０５に、個々の作業単位が割当てられる性能クラスを確立させる。各性能クラスがクラス・テーブル・エントリ１０６により、オペレーティング・システム１０１のメモリ内に表される。（内部表現にて）指定された目標、及び性能クラスに関する他の情報が、クラス・テーブル・エントリに記録される。クラス・テーブル・エントリに記憶される他の情報には、サーバ１６３の数１０７（制御変数）、目標クラスの相対重要度１０８（入力値）、多重システム性能指標（ＰＩ）１５１、ローカル性能指標１５２（性能測定を表す計算値）、応答時間目標１１０（入力値）、実行速度目標１１１（入力値）、サンプル・データ１１３（測定データ）、リモート応答時間履歴（１５７）（測定データ）、リモート速度履歴１５８（測定データ）、サンプル・データ履歴１２５（測定データ）、及び応答時間履歴１２６（測定データ）が含まれる。
【００３３】
オペレーティング・システム１０１はシステム資源マネージャ（ＳＲＭ）１１２を含み、これは多重システム目標駆動型制御装置（ＭＧＤＰＣ）１１４を含む。これらの構成要素は一般に、米国特許第５４７３７７３号及び同第５６７５７３９号で述べられるように動作する。しかしながら、ＭＧＤＰＣ１１４は本発明に従い、サーバ１６３の数を管理するように変更される。ＭＧＤＰＣ１１４は後述のように、目標の達成度を測定する機能、改善された性能を必要とするユーザ性能目標クラスを選択する機能、及び、関連作業単位の制御変数を変更することにより、選択されたユーザ性能目標クラスの性能を改善する機能を実行する。好適な実施例では、ＭＧＤＰＣ機能はおよそ毎１０秒ごとの周期的なタイマ満了にもとづき、周期的に実行される。ＭＧＤＰＣ機能が実行されるインタバルは、ＭＧＤＰＣインタバルまたはポリシ調整インタバルと呼ばれる。
【００３４】
ＭＧＤＰＣ１１４の動作の一般的な態様は、米国特許第５６７５７３９号で述べられるように、次のようである。ブロック１１５で、各ユーザ性能目標クラス１０６に対して、指定目標１１０または１１１を用いて、多重システム性能指標１５１及びローカル性能指標１５２が計算される。多重システム性能指標１５１は、管理される全てのシステム１００に渡る目標クラスに関連付けられる作業単位の性能を表す。ローカル性能指標１５２は、ローカル・システム１００上の目標クラスに関連付けられる作業単位の性能を表す。結果の性能指標１５１、１５２は、対応するクラス・テーブル・エントリ１０６に記録される。ユーザ性能目標の達成度を測定する方法としての性能指標の概念は周知である。例えば、前記のFergusonらによる米国特許第５５０４８９４号では、性能指標として、実際の応答時間が目標応答時間により除算されるように述べられている。
【００３５】
ブロック１１６で、ユーザ性能目標クラスが選択され、相対目標重要度１０８及び性能指標１５１、１５２の現在値の順で、性能改善度を受信する。選択されたユーザ性能目標クラスは、レシーバ（receiver）と呼ばれる。ＭＧＤＰＣ１１４はレシーバを選択するとき、最初に多重システム性能指標１５１を用いることにより、管理される全てのシステム１００に渡り作業単位が目標を満足するために、最も大きな影響を有するアクションを実行する。多重システム性能指標１５１にもとづき実行すべきアクションが存在しない場合、ローカル性能指標１５２が用いられ、ローカル・システム１００がその目標を満足するために最も有用なレシーバが選択される。
【００３６】
候補のレシーバ・クラスが決定された後、周知のように、状態サンプル１２５を用いて性能ボトルネックを構成する、そのクラスの制御変数がブロック１１７で決定される。米国特許第５６７５７３９号で述べられるように、制御変数には、保護プロセッサ記憶ターゲット（ページング遅延に影響）、スワップ保護時間（ＳＰＴ）ターゲット（スワップ遅延に影響）、多重プログラミング・レベル（ＭＰＬ）・ターゲット（ＭＰＬ遅延に影響）、及びディスパッチ優先順位（ＣＰＵ遅延に影響）などの変数が含まれる。本発明によれば、制御変数として、キュー遅延に影響を及ぼすサーバ１６３の数が含まれる。
【００３７】
図１では、サーバ１６３の数１０７が、クラス・テーブル・エントリ１０６に記憶されて示され、これは１クラス当たり、１つのキュー１６１が限度であることを意味する。しかしながら、これは単に説明の簡略化のためであり、当業者であれば、単にデータの位置を変更することにより、１クラス当たり複数のキュー１６１が独立に管理され得ることが理解できよう。基本的な必要条件は、１つのキュー１６１に対する作業要求１６２が１つの目標だけを有すること、各サーバ１６３が要求をサービスするための等しい能力を有すること、及び作業負荷マネージャ１０５からの（への）通知無しでは、サーバが２つ以上のキュー１６１上の作業をサービスすることができないことである。
【００３８】
候補の性能ボトルネックが識別された後、制御変数の潜在的な変化がブロック１１８で考慮される。ブロック１２３で、相対目標重要度１０８及び性能指標１５１、１５２の現在値にもとづき、性能低下が起こり得るユーザ性能目標クラスが選択される。従って、選択されたユーザ性能目標クラスはドナーと呼ばれる。
【００３９】
候補ドナー・クラスが選択された後、提案された変化がブロック１２４で評価される。具体的には、サーバ１６３の数１０７、及び前述され、また米国特許第５６７５７３９号でも述べられる変数を含む制御変数の各々に対して、レシーバ及びドナーの両者において、多重システム性能指標１５１及びローカル性能指標１５２の期待変化に対するネット値が評価される。提案された変化は、結果が目標に対して、ドナーに与える損害よりも多くの改善をレシーバにもたらす場合、ネット値を有する。提案された変化がネット値を有する場合、それぞれの制御変数がドナー及びレシーバの両者に対して調整される。
【００４０】
管理される各システム１００はデータ伝送機構１５５に接続され、これは各システム１００がデータ・レコードをあらゆる他のシステム１００に送信することを可能にする。ブロック１５３で、各目標クラスの最近の性能を記述するデータ・レコードが、あらゆる他のシステム１００に送信される。
【００４１】
多重システム目標駆動型性能制御装置（ＭＧＤＰＣ）機能は、周期的に実行され（好適な実施例では毎１０秒ごとに１度）、タイマ満了を介して呼び出される。ＭＧＤＰＣの機能は、性能問題の増分検出及び訂正のためのフィードバック・ループを提供し、オペレーティング・システム１０１を適応され、自己同調させる。
【００４２】
米国特許第５６７５７３９号で述べられるように、ＭＧＤＰＣインタバルの終わりに、インタバルの間の各目標クラスの性能を記述するデータ・レコードが、管理される各リモート・システム１００に送信される。応答時間目標を有する性能目標クラスに対して、このデータ・レコードは目標クラス名と、リモート応答時間履歴の行（row）に等価なエントリを有する配列とを含む。ここでリモート応答時間履歴は、最後のＭＧＤＰＣインタバルに渡る目標クラスの完了を記述する。速度目標を有する目標クラスに対して、このデータ・レコードは目標クラス名と、目標クラス内の作業が最後のＭＧＤＰＣインタバル内で実行中にサンプリングされた回数と、目標クラス内の作業が最後のＭＧＤＰＣインタバル内で、実行中または遅延中にサンプリングされた回数とを含む。本発明によれば、各システム１００が追加のデータとして、データを送信するシステム１００のサービス有効配列、各キュー１６１に対するサーバ１６３の数、及び各キュー１６１に対する遊休サーバ１６３の数を送信する。
【００４３】
ブロック１５４で、リモート・データ・レシーバがＭＧＤＰＣ１１４とは非同期に、リモート・システム１００から性能データを受信する。受信データはＭＧＤＰＣ１１４による後の処理のために、リモート性能データ履歴（１５７、１５８）に配置される。
【００４４】
図３は、解決する資源ボトルネックを選択するために、ボトルネック発見手段１１７により使用される状態データを示す。各遅延タイプに対して、性能目標クラス・テーブル・エントリ１０６が、その遅延タイプに遭遇するサンプルの数、及びＭＧＤＰＣ１１４の現呼び出しの間に、その遅延タイプが既にボトルネックとして選択されたか否かを示すフラグを含む。クロス・メモリ・ページング・タイプ遅延の場合、クラス・テーブル・エントリ１０６が、遅延に遭遇したアドレス空間の識別子を含む。
【００４５】
ボトルネック発見手段１１７の論理フローが図４に示される。解決するボトルネックの選択は、ＭＧＤＰＣ１１４の現呼び出しの間にまだ選択されておらず、最も多くのサンプルを有する遅延タイプを選択することにより実行される。遅延タイプが選択されると、フラグがセットされ、それによりボトルネック発見手段１１７が、ＭＧＤＰＣ１１４のこの呼び出しの間に再度呼び出される場合、その遅延タイプがスキップされる。
【００４６】
図４のステップ５０１では、ＣＰＵ遅延タイプが、まだ選択されていない全ての遅延タイプの中で、最も多くの遅延サンプルを有するか否かが判断される。肯定の場合、ステップ５０２で、ＣＰＵ遅延選択フラグがセットされ、ＣＰＵ遅延が次に解決されるべきボトルネックとして返却される。
【００４７】
ステップ５０３では、ＭＰＬ遅延タイプが、まだ選択されていない全ての遅延タイプの中で、最も多くの遅延サンプルを有するか否かが判断される。肯定の場合、ステップ５０４で、ＭＰＬ遅延選択フラグがセットされ、ＭＰＬ遅延が次に解決されるべきボトルネックとして返却される。
【００４８】
ステップ５０５では、スワップ遅延タイプが、まだ選択されていない全ての遅延タイプの中で、最も多くの遅延サンプルを有するか否かが判断される。肯定の場合、ステップ５０６で、スワップ遅延選択フラグがセットされ、スワップ遅延が次に解決されるべきボトルネックとして返却される。
【００４９】
ステップ５０７では、ページング遅延タイプが、まだ選択されていない全ての遅延タイプの中で、最も多くの遅延サンプルを有するか否かが判断される。肯定の場合、ステップ５０８で、ページング遅延選択フラグがセットされ、ページング遅延が次に解決されるべきボトルネックとして返却される。５つのタイプのページング遅延が存在する。ステップ５０７では、最も多くの遅延サンプルを有するタイプが突き止められ、ステップ５０８で、特定のタイプに対してフラグがセットされ、その特定のタイプが返却されれる。好適な実施例の環境（ＯＳ／３９０）において周知のように、ページング遅延のタイプには、専用領域、共通領域、クロス・メモリ、仮想入出力（ＶＩＯ）、及びハイパ空間が存在し、各々がページング遅延状況に対応する。
【００５０】
最後にステップ５０９で、キュー遅延タイプが、まだ選択されていない全ての遅延タイプの中で、最も多くの遅延サンプルを有するか否かが判断される。クラスはキュー１６１上の各作業要求に対して、ローカル・システム１００上で実行される資格のある１つのキュー遅延タイプ・サンプルを獲得する。肯定の場合、ステップ５１０で、キュー遅延選択フラグがセットされ、キュー遅延が次に解決されるべきボトルネックとして返却される。キュー遅延は、クラスタ９０内の別のシステム１００が最後のポリシ調整インタバルの間に、キュー１６１に対してサーバ１６３を始動した場合、ローカル・システム１００上では解決されない。キュー遅延はまた、候補レシーバ・クラスが準備完了の作業をスワップ・アウトした場合にも、解決されない。
【００５１】
次のセクションでは、ボトルネック発見手段１１７により選択された遅延を低減するように、制御変数を変更することにより、如何にレシーバ性能目標クラス性能が改善されるか、そして特に、レシーバにより遭遇されるキュー遅延を低減することにより、如何に性能が改善されるかについて述べる。共用キュー１６１の場合、これは２ステップ・プロセスである。第１に、ローカル・システム１００上にサーバ１６３を追加することにより、評価が行われる。この評価には、ドナー作業に対する影響が含まれる。サーバ１６３の追加において、ネット値が存在する場合、次のステップでサーバがローカル・システム１００上で始動されるべきか、或いはそれらがクラスタ９０内の別のシステム１００上で始動されるべきかが決定される。リモート・システム１００がサーバ１６３を始動するために、より好適であると思われる場合、ローカル・システム１００はそのリモート・システムにサーバを始動する機会を与えるために待機する。しかしながら、そのリモート・システム１００がサーバ１６３を始動しない場合、ローカル・システム１００が図９に関連して後述されるように、それらを始動する。
【００５２】
図５は、追加のサーバ１６３を始動することによる、性能の改善を評価する論理フローを示す。図５乃至図７は、固定手段１１８によりネット値手段１２４に提供される性能指標デルタ予測を生成するステップを示す。ステップ１４０１で、サーバ１６３の新たな数が評価のために選択される。この数は変化を価値あるものにするために、十分なレシーバ値（ステップ１４０５でチェックされる）を生成するように十分大きくなければならない。一方、この数は、追加のサーバ１６３の値が限られるように、例えばキューに待機されて実行される作業要求の総数より大きくならないように、余り大きくてはならない。次のステップは、追加のサーバ１６３が使用する追加のＣＰＵを計算する。これは作業要求により使用される平均ＣＰＵに、追加されるサーバ１６３を乗算することにより実行される。
【００５３】
ステップ１４０２で、新たな数のサーバ１６３における作業要求１６２の予測数が、図６に示されるサーバ準備完了ユーザ平均グラフから読出される。ステップ１４０３で、現予測キュー遅延が、図７に示されるキュー遅延グラフから読出される。ステップ１４０４で、ローカル性能指標デルタ及び多重システム性能指標デルタの予測値が計算される。これらの計算は以下で示される。
【００５４】
図６は、キュー準備完了ユーザ平均グラフを示す。キュー準備完了ユーザ平均グラフは、キュー１６１に対するサーバ１６３の数の変化を評価するときに、サーバ１６３に対する需要を予測するために使用される。このグラフは、作業要求１６２がバックアップを開始するポイントを示す。横座標（ｘ）値は、キュー１６１が使用可能なサーバ１６３の数である。縦座標（ｙ）値は、実行準備完了の作業要求１６２の最大数である。
【００５５】
図７は、キュー遅延グラフを表す。キュー遅延グラフは、キュー１６１に対するサーバ１６３の数を増減する値を評価するために使用される。このグラフは、キュー・サーバ１６３の数を増加することにより、如何に応答時間が改善されるか、或いはキュー・サーバ１６３の数を減少することにより、如何に応答時間が低下されるかを示す。グラフはまた、例えばデータベース・ロック競合などの、追加のサーバ１６３を追加することにより生じ得る、作業負荷マネージャ１０５により管理されない資源に対する競合を暗黙的に考慮する。こうした場合では、追加のサーバ１６３が追加されても、グラフ上のキュー遅延が減少しない。横座標値は、使用可能なサーバ１６３を有し、システム１００のクラスタ９０に渡りスワップ・インされる準備完了の作業要求１６２の割合である。縦座標値は１完了当たりのキュー遅延である。
【００５６】
サーバ１６３の数の増加に対する、シスプレックス（すなわち多重システム）性能指標（ＰＩ）デルタは、次のように計算される。ここでシスプレックス性能指標デルタが計算される理由は、キュー１６１がシスプレックス全体に渡る資源であるからである。
【００５７】
応答時間目標に対して、
（予測シスプレックスＰＩデルタ）＝（予測キュー遅延−現キュー遅延）／応答時間目標
【００５８】
速度目標に対して、
（新シスプレックス速度）＝｛cpuu＋（（cpuu／oldserver）*newserver）｝／｛non-idle＋（（qd/qreq）*（oldserver−newserver））｝
（シスプレックスＰＩデルタ）＝（現シスプレックスＰＩ−目標）／新シスプレックス速度
【００５９】
ここで
cpuuは、シスプレックスＣＰＵ使用サンプル；
oldserverは、評価される変化が実行される前のサーバ１６３の数；
newserverは、評価される変化が実行された後のサーバ１６３の数；
non-idleは、シスプレックス非遊休サンプルの総数；
qdは、シスプレックス・キュー遅延サンプル；
qreqは、キュー１６１上の作業要求１６２の数
である。
【００６０】
同様の計算が、サーバ１６３の数の減少に対する性能指標デルタを計算するために使用される。
【００６１】
ステップ１４０５で、追加のサーバ１６３の数により提供される十分なレシーバ値に対してチェックが行われる。好適には、このステップは、新たなサーバ１６３が、それらの追加を価値あるものにするために十分なＣＰＵ時間を獲得するか否かを判断するステップを含む。十分なレシーバ値が存在しない場合、制御はステップ１４０１に戻り、より多くのサーバ１６３が評価のために選択される。
【００６２】
十分なレシーバ値が存在する場合、ステップ１４０６でドナー選択手段１２３が呼び出され、レシーバ性能目標クラスのために、追加のサーバ１６３を始動するために必要な記憶装置のドナーを見い出す。
【００６３】
ドナー・クラスのために調整される制御変数は、必ずしもそのクラスに対するサーバ１６３の数１０７である必要はない。ドナー・クラスの幾つかの異なる制御変数の任意の１つ、例えばＭＰＬスロットまたは保護プロセッサ記憶装置などが、代わりにまたは追加として調整され、追加のサーバ１６３のために必要な記憶装置を提供してもよい。本発明の一部を成すものではないが、こうした制御変数の調整がドナー・クラスに与える効果を評価する方法が、米国特許第５５３７５４２号及び同第５６７５７３９号で述べられている。
【００６４】
ステップ１４０７では、ドナーから記憶装置を受け取り、レシーバ・クラスのためにサーバ１６３の数を増加するに際して、ネット値が存在することを保証するためにチェックが行われる。米国特許第５６７５７３９号で述べられるように、これは１つ以上の幾つかの異なる基準、例えば資源再割当ての後に、ドナーがその目標に合致するように予測されるか否か、レシーバが現在その目標を逸しつつあるか否か、レシーバがドナーよりも重要なクラスか否か、またはドナー及びレシーバの結合性能指標において、ネット利得が存在するか否か、すなわち、サーバをレシーバ・クラスに追加することが、レシーバ・クラスの性能指標に及ぼすプラスの効果が、ドナー・クラスの性能指標に及ぼすマイナスの効果を上回るか否かなどの基準を用いて決定される。ネット値が存在する場合、次のステップで、ローカル・システム１００が新たなサーバ１６３を始動するための（ステップ１４０８）、クラスタ９０内の最善のシステムか否かが決定される。ネット値が存在しない場合、レシーバ目標クラス・キュー遅延問題は解決され得ない（ステップ１４０９）。
【００６５】
図９は、新たなサーバ１６３を始動するクラスタ９０内の最善のシステム１００を表す、ターゲット・システムを決定するプロシージャを示す。このプロシージャは、一旦サーバの追加に対してネット値が存在し、１つ以上のサーバ１６３がレシーバ・クラスに追加されるべきことが決定されると、図５のステップ１４０８の一部として、クラスタ９０内の各システム１００により実行される。ローカル・システム１００が最初に、クラスタ９０内の任意のシステム１００が他の作業に影響すること無く、新たなサーバ１６３をサポートするための十分な遊休容量を有するか否かをチェックする（ステップ８０１）。これはクラスタ９０内の各システム１００のサービス有効配列を調査し、配列要素８において、新たなサーバ１６３をサポートするために使用可能な十分なＣＰＵサービス（未使用ＣＰＵサービス）を有するシステム１００を選択することにより実行される。複数のシステム１００が十分な未使用ＣＰＵサービスを有する場合、最も多くの未使用サービスを有するシステム１００が選択される。しかしながら、キューに待機された作業要求が存在するときに、システム１００が遊休状態のサーバを有する場合、これは多くの作業要求がそのシステム１００に対して親和性を持たないことを意味するので、この遊休状態のサーバ１６３を有するシステム１００は選択されない。
【００６６】
ローカル・システム１００は次に、サーバ１６３を始動するための、十分な遊休状態のＣＰＵ容量を有するターゲット・システム１００が見い出されたか否かをチェックする（ステップ８０２）。ターゲット・システム１００が見い出され、それがローカル・システム１００の場合（ステップ８０３）、ローカル・システム１００がサーバ１６３を局所的に始動する（ステップ８０４乃至８０５）。
【００６７】
ステップ８０３で、別のシステム１００が新たなサーバ１６３を始動するための最も多くの遊休容量を有することが見い出されると、制御はステップ８０６に移行し、ローカル・システム１００がポリシ調整インタバル（１０秒）を待機し、別のシステム１００がサーバ１６３を始動したか否かをチェックする（ステップ８０７）。別のシステム１００がサーバ１６３を始動した場合、局所的に何もアクションは実行されない（ステップ８１１）。他のシステム１００がサーバ１６３を始動しなかった場合、ローカル・システム１００は、自身が新たなサーバ１６３をサポートする十分な遊休ＣＰＵ容量を有するか否かをチェックする（ステップ８１２）。有する場合、ローカル・システム１００は局所的にサーバ１６３を始動する（ステップ８１３乃至８１４）。
【００６８】
新たなサーバ１６３をサポートするための十分な遊休ＣＰＵ容量を有するシステム１００が存在しなかった場合、或いは、十分な遊休ＣＰＵ容量を有するシステム１００が存在したが、そのシステム１００がサーバを始動しなかった場合、制御はステップ８０８に移行する。こうしたシステム１００がサーバ１６３を始動しない１つの理由は、メモリが欠乏するためである。この時点で、ドナー作業に影響を及ぼすこと無しに、新たなサーバ１６３が始動され得ないことが判明する。従って、ローカル・システム１００は、局所的なサーバ１６３の始動により、ドナー作業がその目標を逸するか否かをチェックする。ドナー作業がその目標を逸しない場合、ローカル・システム１００はサーバ１６３を局所的に始動する（ステップ８１７乃至８１８）。サーバ１６３の局所的な始動により、ドナー・クラスがその目標を逸する場合には、ローカル・システム１００はドナー作業への影響が最も小さいシステム１００を見い出す（ステップ８０９）。
【００６９】
図１０は、図９のステップ８０９で、ドナー作業への影響が最も小さいシステム１００を決定するルーチンを示す。ルーチンは最初に、ドナー・クラスの名前及びドナーの性能指標（ＰＩ）デルタを、クラスタ９０内の他のシステムに送信する（ステップ９０１）。このドナー情報を交換することにより、レシーバ・クラスに対するサーバ１６３の追加を評価している各システム１００は、他の全てのシステム１００へのサーバ追加の影響を調査する。ルーチンは次に、他のシステム１００がそれらのドナー情報を送信することを可能にするために、１ポリシ・インタバル（示される実施例では１０秒）を待機する（ステップ９０２）。ルーチンは次に、ドナー・クラスが最も低い重要度を有するシステム１００を選択し（ステップ９０３）、選択されたシステム１００を呼び出しルーチンに返却して、図９のステップ８０９を完了する（ステップ９０５）。ドナー重要度に対等なものが存在する場合（ステップ９０４）、ルーチンはドナーの性能指標（ＰＩ）デルタが最小のシステム１００を選択し（ステップ９０６）、このシステム１００を呼び出しルーチンに返却する（ステップ９０７）。
【００７０】
再度図９を参照して、ステップ８０９を完了後、ローカル・システム１００は、ドナーに対して最も小さな影響を有するとして選択されたシステム１００が、ローカル・システムであるか否かをチェックする（ステップ８１０）。そうである場合、ローカル・システム１００がサーバ１６３を局所的に始動する（ステップ８１７乃至８１８）。それ以外では、ローカル・システム１００は、別のシステム１００がサーバ１６３を始動することを可能にするために、１ポリシ・インタバル待機し（ステップ８１５）、このインタバルの終りに別のシステム１００がサーバ１６３を始動したか否かをチェックする（ステップ８１６）。別のシステム１００がサーバ１６３を始動した場合、ローカル・システム１００は何もアクションを起こさない（ステップ８１８）。他のシステム１００がサーバ１６３を始動しなかった場合、ローカル・システム１００はそれらを局所的に始動する（ステップ８１７乃至８１８）。
【００７１】
図５のステップ１４０８では、特定の環境下のキュー１６１に対して、新たなサーバ１６３を始動する要求を一時的に延期する論理が含まれる。既存の作業への不要な影響を回避するために、新たなサーバ１６３を始動する並列要求が制限される。この歩調合わせは、オペレーティング・システム１０１に、追加のサーバ１６３を始動するための多くの並列要求が殺到し、混乱することを回避する。システム管理者により提供される、データ・レポジトリ１４１内の誤った情報の検出も実行され、新たなサーバ１６３が成功裡に始動され得ない程、サーバ定義情報が不正確な場合に、無限の再試行ループを阻止する。一旦サーバ１６３が始動されると、サーバが予期せず故障した場合に、それを自動的に置換する論理も含まれる。同一のサーバ定義情報を有するが、同一の作業マネージャ１６０に対して異なるキュー１６１をサービスする遊休サーバ１６３が、キュー間で移動され得ることにより、特定のキューに対してサーバ１６３の数を増加する要求が満足され、完全に新たなサーバを始動するオーバヘッドを回避する。
【００７２】
本発明は好適には、１つ以上のハードウェア・マシン上で実行されるソフトウェア（すなわち、プログラム記憶装置上で実現される命令のマシン読出し可能プログラム）として実現される。これまで特定の実施例について述べてきたが、当業者であれば、ここで特定的に述べられた以外の他の実施例も、本発明の趣旨から逸れることなく実現され得ることが明らかであろう。また、当業者であれば、様々な等価な要素が、ここで特定的に開示された要素の代わりに代用され得ることが理解されよう。同様に、ここで開示された実施例の変更及び組み合わせも明らかであろう。例えば、各サービス・クラスに対して、ここで開示された１つのキューではなく、複数のキューが提供され得る。開示された実施例及びそれらの詳細は、本発明の実施例を教示することを意図したのものであって、本発明を制限するものではない。従って、こうした明白ではあるが、ここで開示されなかった変更及び組み合わせも、本発明の趣旨及び範囲に含まれるものと見なされる。
【００７３】
まとめとして、本発明の構成に関して以下の事項を開示する。
【００７４】
（１）情報処理システムのクラスタ内において、キュー内の各作業要求を処理可能なサーバの可用性を保証する方法であって、入来作業要求が前記キューに配置され、前記システム上の１つ以上のサーバにより処理されるものにおいて、
前記キューに対してサーバを有さない前記クラスタのサブセットだけに親和性を有する作業要求が、前記キュー内に存在するか否かを決定するステップと、
前記キューに対してサーバを有さない前記クラスタのサブセットだけに親和性を有する作業要求が、前記キュー内に存在すると決定された場合、前記作業要求が親和性を有する前記サブセット内のシステム上で、前記キューに対してサーバを始動するステップと
を含む、方法。
（２）前記決定するステップが周期的インタバルで実行される、前記（１）記載の方法。
（３）異なるサービス・クラスに割当てられる作業要求が、異なるキューに配置され、前記決定するステップが前記キューの各々に対して実行される、前記（１）記載の方法。
（４）前記決定するステップが、前記クラスタ内の各システムにより実行される、前記（１）記載の方法。
（５）前記決定するステップが、
前記キューが前記システム上にサーバを有するか否かを決定するステップと、
前記キューが前記システム上にサーバを有さない場合、前記クラスタのサブセットだけに親和性を有する作業要求が、前記キュー内に存在するか否かを決定するステップと
を含む、前記（４）記載の方法。
（６）マシンにより読出され、前記マシンにより実行されて、前記（１）記載の方法を実行する命令のプログラムを実現する、プログラム記憶装置。
（７）情報処理システムのクラスタ内において、キュー内の各作業要求を処理可能なサーバの可用性を保証する装置であって、入来作業要求が前記キューに配置され、前記システム上の１つ以上のサーバにより処理されるものにおいて、
前記キューに対してサーバを有さない前記クラスタのサブセットだけに親和性を有する作業要求が、前記キュー内に存在するか否かを決定する手段と、
前記キューに対してサーバを有さない前記クラスタのサブセットだけに親和性を有する作業要求が、前記キュー内に存在すると決定された場合、前記作業要求が親和性を有する前記サブセット内のシステム上で、前記キューに対してサーバを始動する手段と
を含む、装置。
【図面の簡単な説明】
【図１】本発明のために適応化された制御オペレーティング・システム及びシステム資源マネージャ要素を有する、コンピュータ・システムを示すシステム構造図である。
【図２】ネットワークから、本発明の作業負荷マネージャにより管理されるサーバ・アドレス空間へのクライアント作業要求の流れを示す図である。
【図３】資源ボトルネックを選択するために使用される状態データを示す図である。
【図４】ボトルネック発見機能の論理フローを示すフローチャートである。
【図５】サーバの数を増加することにより、改善された性能をアクセスするステップのフローチャートである。
【図６】キュー準備完了ユーザ平均のサンプル・グラフである。
【図７】キュー遅延のサンプル・グラフである。
【図８】クラスタ内のどこかに、キュー上の各要求を実行可能な少なくとも１つのサーバが存在することを保証するプロシージャを示す図である。
【図９】サーバを始動すべきクラスタ内の最善のシステムを決定するプロシージャを示す図である。
【図１０】ドナーへの影響が最も小さいシステムを見い出すプロシージャを示す図である。
【符号の説明】
９０ クラスタ
１００ コンピュータ・システム
１０１ オペレーティング・システム
１０２ ディスパッチャ
１０５ 作業負荷マネージャ（ＷＬＭ）
１０６ クラス・テーブル・エントリ
１０７ サーバの数
１１０ 応答時間目標
１１１ 実行速度目標
１１２ システム資源マネージャ（ＳＲＭ）
１１３ サンプル・データ
１１４ 多重システム目標駆動型制御装置（ＭＧＤＰＣ）
１１７ ボトルネック発見手段
１１８ 固定手段
１２３ ドナー選択手段
１２４ ネット値手段
１２５ サンプル・データ履歴
１２６ 応答時間履歴
１４１ 性能目標
１５１ 多重システム性能指標
１５２ ローカル性能指標
１５５ データ伝送機構
１５７ リモート応答時間履歴
１５８ リモート速度履歴
１６０ 作業マネージャ
１６１ キュー
１６２ 作業要求
１６３ サーバ
１６４ アドレス空間
【発明の属する技術分野】
本発明は、第１のサービス・クラスに属する入来作業要求が、１つ以上のサーバによる処理のために、キューに配置される情報処理システムにおいて、サーバの数を制御する方法及び装置に関する。
【０００２】
【従来の技術】
使用可能なサーバへの割当てのために、入来作業要求がキューに配置されるシステムは周知である。入来作業要求が到来する頻度は、容易に制御され得ないので、こうしたキュー待機型システムにおいて、システム性能（キュー遅延などにより測定される）を制御する基本手段は、サーバの数を制御することである。従って、サービスされるキューの長さが特定の高いしきい値に達するとき、追加のサーバを始動したり、サービスされるキューの長さが特定の低いしきい値に達するとき、サーバを停止することが知られている。こうした手段は、その設計目的を達成するが、キューに待機された作業要求に加え、他の作業単位がシステム資源を競合するシステムでは不十分である。従って、たとえキューに対して追加のサーバを提供することで、そのキュー内における作業要求の性能を向上しても、こうしたサーバの提供は、システムにより処理される他の作業単位の性能を低下し得、システムの性能を全体として悪化し得る。
【０００３】
ほとんどの今日のオペレーティング・システム・ソフトウェアは、作業要求に対して指定されるエンドユーザ指向の目的に従い、サーバの数を管理し、同一のコンピュータ・システム内で実行される、独立の目標を有する他の作業を考慮する責任を負うことができない。
【０００４】
本願の出願人に権利譲渡された１９９７年３月２８日付けのJ. D. Amanらによる継続中の米国特許出願第８２８４４０号は、特定のシステムにおいて、サーバの数を制御する方法及び装置を開示し、そこでは第１のサービス・クラスに属する入来作業要求が、１つ以上のサーバによる処理のためにキューに配置される。本システムは更に、システム資源のドナー（donor）として作用する、少なくとも１つの他のサービス・クラスに割当てられる作業単位を有する。本発明によれば、性能測定が第１のサービス・クラスの他に、少なくとも１つの他のサービス・クラスに対して定義される。サーバを第１のサービス・クラスに追加する以前に、第１のサービス・クラスの性能測定に及ぼすプラスの効果だけでなく、他のサービス・クラスの性能測定に及ぼすマイナスの効果も決定される。第１のサービス・クラスの性能測定に及ぼすプラスの効果が、他のサービス・クラスの性能測定に及ぼすマイナスの効果に勝る場合に限り、サーバが第１のサービス・クラスに追加される。
【０００５】
【発明が解決しようとする課題】
この継続中の特許出願で開示される発明は、サーバを追加するか否かを決定するとき、他の作業に対する影響を考慮するが、これは単一システムの状況においてそのようにする。しかしながら、多重システム・コンプレックス（"シスプレックス（sysplex）"）では、作業要求の１つのキューが、コンプレックスに渡り複数のサーバによりサービスされる。従って、所与のキューに対して、サーバを追加するか否かだけでなく、シスプレックス全体の性能を最適化するために、サーバをどこに追加すべきかが決定され得る。
【０００６】
【課題を解決するための手段】
本発明は、情報処理システムのクラスタ内のサーバの数を制御する方法及び装置に関して、そこでは第１のサービス・クラスに属する入来作業要求が、１つ以上のサーバによる処理のためにキューに配置される。入来作業要求のあるものは、クラスタ内のサーバのサブセット上でのみ実行されるための要求を有し得る。こうした要求を有する作業要求は、それらが実行されなければならないクラスタ内のシステムのサブセットに対して、"親和性（affinity）"を有すると言われる。本発明によれば、サーバがクラスタ内の１つ以上のシステム上で始動され、キュー内の作業要求を処理する。これらのサーバを始動するシステムは、システムのクラスタの全容量を利用するように、及び作業要求の親和性要求に応じるように、更にクラスタ内のシステム上で実行されているかも知れない他の作業への影響を最小化するように選択される。新たなサーバが始動されるシステムはまた、システム資源のドナーとして作用する第２のサービス・クラスに割当てられる作業単位を有する。本発明によれば、性能測定が第１のサービス・クラス同様、第２のサービス・クラスに対しても定義される。サーバを第１のサービス・クラスに追加する以前に、第１のサービス・クラスの性能測定に及ぼすプラスの効果だけでなく、第２のサービス・クラスの性能測定に及ぼすマイナスの効果も決定される。第１のサービス・クラスの性能測定に及ぼすプラスの効果が、第２のサービス・クラスの性能測定に及ぼすマイナスの効果に勝る場合に限り、サーバが第１のサービス・クラスに追加される。
【０００７】
本発明は、複数のユーザ性能目標クラスの各々に対して、各目標クラスの性能目標にもとづき、システムのクラスタに渡るサーバの数のシステム管理を可能にする。競合する目標クラスに対して、サーバの追加または除去の影響を考慮するトレードオフが提供される。
【０００８】
【発明の実施の形態】
本発明を組み込むシステムについて述べる前準備として、作業負荷管理（本発明がそれ上で構成される）の概念に関して前置きすることが適切であろう。
【０００９】
作業負荷管理は、オペレーティング・システムにより管理される作業単位（プロセス、スレッドなど）が、クラス（サービス・クラスまたは目標クラスと呼ばれる）に編成される概念であり、クラスは予め定義された目標にどれ程よく合致するかに従い、システム資源を提供される。ドナー・クラスからレシーバ（receiver）・クラスへの資源の再割当ては、こうした再割当てから得られるレシーバ・クラスの性能の改善が、ドナー・クラスの性能の劣化に勝る場合、すなわち、予め定義された性能基準により決定される性能における、正味のプラス効果が存在する場合に実行される。このタイプの作業負荷管理は、資源の割当てが資源が再割当てされる作業単位への効果だけにより決定されるのではなく、資源が奪われる作業単位への効果によっても決定されるという点で、大部分のオペレーティング・システムにより実行される"普通の（run-of-the-mill）"資源管理とは異なる。
【００１０】
この一般的なタイプの作業負荷マネージャは、以下に挙げる特許、特許出願、及び特許以外の刊行物において開示されている。
【００１１】
D. F. Fergusonらによる米国特許出願第５５０４８９４号"Workload Manager for Achieving Transaction Class Response Time Goals in a Multiprocessing System"。
J. D. Amanらによる米国特許第５４７３７７３号"Apparatus and Method for Managing a Data Processing System Workload According to Two or More Distinct Processing Goals"。
C. K. Eilertらによる米国特許第５５３７５４２号"Apparatus and Method for Managing a Server Workload According to Client Performance Goals in a Client/Server Data Processing System"。
J. D. Amanらによる米国特許第５６０３０２９号"System of Assigning Work Requests Based on Classifying into an Eligible Class Where the Criteria Is Goal Oriented and Capacity Information is Available"。
C. K. Eilertらによる米国特許第５６７５７３９号"Apparatus and Method for Managing a Distributed Data Processing System Workload According to a Plurality of Distinct Processing Goal Types"。
１９９５年２月３日付けのC. K. Eilertらによる米国特許出願第３８３０４２号"Multi-System Resource Capping"。
１９９５年６月７日付けのJ. D. Amanらによる米国特許出願第４８８３７４号"Apparatus and Accompanying Method for Assigning Session Requests in a Multi-Server Sysplex Environment"。
１９９７年３月２８日付けのJ. D. Amanらによる米国特許出願第８２８４４０号"Method and Apparatus for Controlling the Number of Servers in a Client/Server System"。
MVS Planning：Workload Management、ＩＢＭ刊行物GC28-1761-00、１９９６年。
MVS Programming：Workload Management Services、ＩＢＭ刊行物GC28-1773-00、１９９６年。
【００１２】
前記特許及び刊行物の中で、米国特許第５５０４８９４号及び同第５４７３７７３号は、基本的な作業負荷管理システムを開示し、米国特許第５５３７５４２号は、米国特許第５４７３７７３号の作業負荷管理システムの、クライアント／サーバ・システムへの特定のアプリケーションを開示し、米国特許第５６７５７３９号及び米国特許出願第３８３０４２号は、米国特許第５４７３７７３号の作業負荷管理システムの、複数の相互接続システムへの特定のアプリケーションを開示し、米国特許第５６０３０２９号は、多重システム・コンプレックス（"シスプレックス"）における作業要求の割当てに関して、米国特許出願第４８８３７４号は、こうしたコンプレックスにおけるセッション要求の割当てに関して、前述のように、米国特許出願第８２８４４０号は、多重システム・コンプレックスの１つのシステム上でのサーバの数の制御に関する。特許以外の２つの刊行物は、ＩＢＭ（登録商標）ＯＳ／３９０（商標）（以前はＭＶＳ（登録商標））オペレーティング・システムにおける作業負荷管理の実現について述べている。
【００１３】
図１は、本発明の一般的な実施例における主要な環境及びフィーチャを示し、相互接続され、協働するコンピュータ・システム１００のクラスタ９０を含み、それらの一般的な２つが示されている。本発明の環境は、作業要求１６２のキュー１６１と、クラスタ９０に渡り分散され、作業要求をサービスするサーバ１６３のプールとを含む。本発明は、キューに待機された作業の性能目標クラスと、コンピュータ・システム１００内で競合する作業の性能目標クラスとにもとづき、サーバ１６３の数の管理を可能にする。コンピュータ・システム１００のクラスタ９０に対して１つのポリシを有することは、分散された作業負荷の単一イメージ・ビューを提供するのに役立つ。当業者であれば、任意の数のコンピュータ・システム１００、及び１つのコンピュータ・システム１００内の任意の数のこうしたキュー１６１及びサーバ１６３のグループが、本発明の趣旨及び範囲から逸れることなく使用され得ることが理解されよう。
【００１４】
コンピュータ・システム１００は分散された作業負荷を実行し、各コンピュータ・システムが、例えばＩＢＭ ＯＳ／３９０オペレーティング・システムなどの、オペレーティング・システム１０１の自身のコピーにより制御される。
【００１５】
それぞれのコンピュータ・システム１００上のオペレーティング・システム１０１の各コピーは、本願で述べられるステップを実行する。説明の中で"ローカル"・システム１００を指し示すとき、それは述べられているステップを実行しているシステム１００を意味する。一方、"リモート"・システム１００は、管理される他の全てのシステム１００を意味する。各システム１００がそれ自身を局所的（ローカル）と見なし、他の全てのシステム１００を遠隔的と見なす点に留意されたい。
【００１６】
本発明に関する改良以外は、システム１００は、継続中の米国特許出願第８２８４４０号及び米国特許第５６７５７３９号で開示されるシステムと類似である。図１に示されるように、システム１００は複数の相互接続されるシステム１００の１つであり、これらは同様に管理され、クラスタ９０（システム・コンプレックスまたはシスプレックスとも呼ばれる）を構成する。米国特許第５６７５７３９号で教示されるように、作業単位が分類される様々なサービス・クラスの性能が、特定のシステム１００に対してだけでなく、クラスタ９０全体に対しても追跡され得る。この目的のために、また後述の説明から明らかになるように、システム１００とクラスタ９０内の他のシステム１００との間で、性能結果を伝達し合う手段が提供される。
【００１７】
ディスパッチャ１０２は、オペレーティング・システム１０１の構成要素であり、次にコンピュータにより実行される作業単位を選択する。作業単位は、コンピュータ・システム１００の目的に相当する有用な作業を実行するアプリケーション・プログラムである。実行準備が整った作業単位は、アドレス空間制御ブロック（ＡＳＣＢ）・キューと呼ばれる、オペレーティング・システム・メモリ内の制御ブロックの連鎖により表される。
【００１８】
作業マネージャ１６０は、オペレーティング・システム１０１の外部の構成要素であり、これはオペレーティング・システム・サービスを用いて、１つ以上のキュー１６１を作業負荷マネージャ（ＷＬＭ）１０５に定義し、作業要求１６２をこれらのキュー上に挿入する。作業マネージャ１６０は、挿入された作業要求１６２を、クラスタ９０内の任意のシステム１００上の作業マネージャ１６０のサーバ１６３による選択のために、先入れ先出し（ＦＩＦＯ）順に保持する。作業マネージャ１６０は、サーバが、それが実行されているシステム１００と親和性を有する要求だけを選択することを保証する。
【００１９】
サーバ１６３は作業マネージャ１６０の構成要素であり、キューに待機された作業要求１６２をサービスすることができる。作業負荷マネージャ１０５がサーバ１６３を始動し、作業マネージャ１６０のキュー１６１上の作業要求１６２をサービスするとき、作業負荷マネージャ１０５は、共用データ機構１４０上に記憶されたサーバ定義を用いて、アドレス空間（すなわちプロセス）１６４を始動する。作業負荷マネージャ１０５により始動されるアドレス空間１６４は、作業負荷マネージャ１０５の指示に従い、そのアドレス空間がサービスすべき特定のキュー１６１上の要求１６２をサービスする、１つ以上のサーバ（すなわちディスパッチ可能単位またはタスク）１６３を含む。
【００２０】
図２は、コンピュータ・システム１００が接続されるネットワーク（図示せず）から、作業負荷マネージャ１０５により管理されるサーバ・アドレス空間１６４への、クライアント作業要求１６２の流れを示す。作業要求１６２はクラスタ９０内の特定のコンピュータ・システム１００に経路指定され、作業マネージャ１６０により受信される。作業要求１６２の受信に際して、作業マネージャ１６０はそれを作業負荷マネージャ（ＷＬＭ）・サービス・クラスに分類し、作業要求を作業キュー１６１に挿入する。作業キュー１６１は、クラスタ９０内の全てのコンピュータ・システム１００により共用される。すなわち、作業キュー１６１はクラスタ全体に渡るキューである。作業要求１６２は、それを実行する準備が整ったサーバが現れるまで、作業キュー１６１内で待機する。
【００２１】
新たな作業要求１６２を実行する準備が整った（アドレス空間が丁度始動されたか、タスクが前の要求の実行を終了したとき）、クラスタ９０内のあるシステム１００上のサーバ・アドレス空間１６４内のタスク１６３が、新たな作業要求のために作業マネージャ１６０を呼び出す。アドレス空間１６４がサービスしている作業キュー１６１上に作業要求１６２が存在し、その作業要求がサーバが実行されているシステム１００と親和性を有する場合、作業マネージャ１６０はその作業要求をサーバ１６３に受け渡す。それ以外では、作業マネージャ１６０は作業要求１６２が有効になるまで、サーバ１６３を延期する。
【００２２】
作業要求１６２が作業マネージャ１６０により受信されるとき、それは作業キュー１６１上に配置され、サーバ１６３が作業要求を実行するために使用可能になるのを待機する。作業要求１６２の作業マネージャ１６０、アプリケーション環境名、及びＷＬＭサービス・クラスのそれぞれの固有の組み合わせに対して、１つの作業キュー１６１が存在する。（アプリケーション環境は、類似のクライアント作業要求１６２のセットが実行されるべき環境である。ＯＳ／３９０条件では、これは作業要求を実行するために、サーバ・アドレス空間を始動するために使用されるジョブ制御言語（ＪＣＬ）プロシージャにマップされる。）特定の作業キュー１６１に対して、第１の作業要求１６２が到来するとき、キューイング構造が動的に生成される。作業キュー１６１に対して、所定時間（例えば１時間）何も活動が発生しなかった場合、構造は消去される。新たなＷＬＭポリシを活動化するなどのように、キューに待機された作業要求１６２のＷＬＭサービス・クラスを変更し得るアクションが発生する場合、作業負荷マネージャ１０５は作業マネージャ１６０にその変更を知らせ、作業マネージャ１６０は、各作業要求１６２の新たなＷＬＭサービス・クラスを反映するように、作業キュー１６１を再生する。
【００２３】
サーバ１６３を有さないシステム１００と親和性を有する作業要求１６２は、他のシステム１００上に、その作業要求のサービス・クラスの目標を満たす上で十分なサーバが存在する場合、決して実行されないといった危険性が存在する。この危険性を回避するために、作業負荷マネージャ１０５は、クラスタ９０内のどこかに、キュー１６１上の各作業要求を実行可能な少なくとも１つのサーバ１６３が存在するように保証する。図８はこの論理を示す。この論理は、クラスタ９０内の各コンピュータ・システム１００上の作業マネージャ１６０により実行される。
【００２４】
ステップ７０１で、作業マネージャ１６０が自身が所有する第１のキュー１６１を調査する。ステップ７０２で、作業マネージャ１６０が、ローカル・システム１００上にこのキュー１６１に対するサーバ１６３が存在するか否かをチェックする。サーバ１６３が存在する場合、作業マネージャ１６０は次のキュー１６１に移行する（ステップ７０８乃至７０９）。作業マネージャ１６０が、局所的にサーバ１６３を有さないキュー１６１を見い出す場合、作業マネージャ１６０は次にキュー上の各作業要求を調査し、第１の作業要求を開始する（ステップ７０３乃至７０６）。各作業要求１６２に対して、作業マネージャ１６０は、クラスタ９０内のどこかに、現作業要求を実行可能なサーバ１６３が存在するか否かをチェックする（ステップ７０４）。現作業要求を実行可能なサーバ１６３が存在する場合、作業マネージャ１６０はキュー１６１上の次の作業要求１６２に移行する（ステップ７０６）。現作業要求を実行可能なサーバ１６３が存在しない場合、作業マネージャ１６０は作業負荷マネージャ１０５を呼び出し、サーバ１６３を始動し（ステップ７０７）、次のキュー１６１に移行する（ステップ７０８乃至７０９）。作業マネージャ１６０は、作業マネージャにより所有される全てのキュー１６１が処理されるまで（ステップ７１０）、同様に継続する。
【００２５】
作業マネージャ１６０が作業負荷マネージャ１０５を呼び出すとき（ステップ７０７）、作業要求に対してサーバを始動すべき最善のシステム１００を決定するために、作業負荷マネージャ１０５は、クラスタ９０内の各システム１００に対して、各重要度にて有効なサービス、及びそのシステムに対して未使用のサービスを示す、サービス有効配列（Service Available Array）を保持する。この配列は下記のように、各重要度に対するエントリ、及び未使用のサービスに対するエントリを含む。
【００２６】
配列要素 配列要素内容
配列要素１ 重要度０にて有効なサービス
配列要素２ 重要度１にて有効なサービス
配列要素３ 重要度２にて有効なサービス
配列要素４ 重要度３にて有効なサービス
配列要素５ 重要度４にて有効なサービス
配列要素６ 重要度５にて有効なサービス
配列要素７ 重要度６にて有効なサービス
配列要素８ 未使用サービス
【００２７】
サービス有効配列は、本願の出願人に権利譲渡された、１９９７年３月２８日付けのC. K. Eilertらによる米国特許出願第８２７５２９号"Managing Processor Resources in a Multisystem Environment"でも述べられている。
【００２８】
作業負荷マネージャ１０５は、要求のサービス・クラスの重要度にて有効な最大限のサービスにより、システム１００上で新たなサーバを始動する。続くアドレス空間１６４は、作業負荷をサポートすることが要求されるときに始動される（後述のポリシ調整を参照）。好適には、アドレス空間１６４を始動する機構は、自動的にアドレス空間を始動する他の実施例における共通の問題を回避するための、幾つかのフィーチャを有する。従って、アドレス空間１６４の始動は好適には、１度に１つの始動だけが進行するように歩調を合わされる。この歩調合わせは、システム１００にアドレス空間１６４の始動が殺到することを回避する。
【００２９】
また、所定の連続的な始動失敗（例えば３度の失敗）に遭遇するとき、所与のアプリケーション環境においては、追加のアドレス空間１６４の生成を回避するための特殊論理が、好適には提供される。こうした失敗が起こり得る原因として、アプリケーション環境における、ＪＣＬプロシージャのＪＣＬエラーが考えられる。前述の特殊論理の提供は、ＪＣＬエラーが訂正されるまで、成功裡に始動しないアドレス空間を始動しようとするループに入り込むことを回避する。
【００３０】
更に、作業要求１６２を実行する間に、サーバ・アドレス空間１６４が失敗する場合、作業負荷マネージャ１０５は好適には、それを置換するための新たなアドレス空間を始動する。失敗が繰り返されると、作業負荷マネージャ１０５は、オペレータ・コマンドにより問題が解決されたことを知らされるまで、そのアプリケーション環境において、作業要求の受諾を停止する。
【００３１】
所与のサーバ・アドレス空間１６４は、たとえそれが通常、１つの作業キュー１６１だけをサービスするとしても、そのアプリケーション環境において、物理的にあらゆる作業要求１６２をサービスすることができる。好適には、サーバ・アドレス空間１６４は、もはやその作業キュー１６１をサポートする必要がないときでも、即時終了されない。代わりに、サーバ・アドレス空間１６４は、ある期間"フリー・エージェント"として待機し、同一のアプリケーション環境において、別の作業キュー１６１をサポートするために使用され得るか否かを調査する。サーバ・アドレス空間１６４が新たな作業キュー１６１にシフトされ得る場合、その作業キューに対して新たなサーバ・アドレス空間を始動するオーバヘッドが回避される。所定時間（例えば５分）内に、サーバ・アドレス空間１６４が別の作業キュー１６１により必要とされない場合、それは終了される。
【００３２】
本発明は入力としてシステム管理者により確立され、データ記憶機構１４０に記憶された性能目標１４１及びサーバ定義を受け取る。データ記憶機構１４０は、管理される各システム１００によりアクセス可能である。ここで示される性能目標には２つのタイプ、すなわち応答時間（秒）と、実行速度（％）とがある。当業者であれば、本発明の趣旨及び範囲から逸れることなく、他の目標または追加の目標が選択され得ることが理解できよう。性能目標には、各目標の相対重要度の指定が含まれる。性能目標１４１が、管理される各システム１００のオペレーティング・システム１０１の作業負荷マネージャ要素１０５により、システム内に読出される。システム管理者により確立され、指定された性能目標の各々は、各システム１００上の作業負荷マネージャ１０５に、個々の作業単位が割当てられる性能クラスを確立させる。各性能クラスがクラス・テーブル・エントリ１０６により、オペレーティング・システム１０１のメモリ内に表される。（内部表現にて）指定された目標、及び性能クラスに関する他の情報が、クラス・テーブル・エントリに記録される。クラス・テーブル・エントリに記憶される他の情報には、サーバ１６３の数１０７（制御変数）、目標クラスの相対重要度１０８（入力値）、多重システム性能指標（ＰＩ）１５１、ローカル性能指標１５２（性能測定を表す計算値）、応答時間目標１１０（入力値）、実行速度目標１１１（入力値）、サンプル・データ１１３（測定データ）、リモート応答時間履歴（１５７）（測定データ）、リモート速度履歴１５８（測定データ）、サンプル・データ履歴１２５（測定データ）、及び応答時間履歴１２６（測定データ）が含まれる。
【００３３】
オペレーティング・システム１０１はシステム資源マネージャ（ＳＲＭ）１１２を含み、これは多重システム目標駆動型制御装置（ＭＧＤＰＣ）１１４を含む。これらの構成要素は一般に、米国特許第５４７３７７３号及び同第５６７５７３９号で述べられるように動作する。しかしながら、ＭＧＤＰＣ１１４は本発明に従い、サーバ１６３の数を管理するように変更される。ＭＧＤＰＣ１１４は後述のように、目標の達成度を測定する機能、改善された性能を必要とするユーザ性能目標クラスを選択する機能、及び、関連作業単位の制御変数を変更することにより、選択されたユーザ性能目標クラスの性能を改善する機能を実行する。好適な実施例では、ＭＧＤＰＣ機能はおよそ毎１０秒ごとの周期的なタイマ満了にもとづき、周期的に実行される。ＭＧＤＰＣ機能が実行されるインタバルは、ＭＧＤＰＣインタバルまたはポリシ調整インタバルと呼ばれる。
【００３４】
ＭＧＤＰＣ１１４の動作の一般的な態様は、米国特許第５６７５７３９号で述べられるように、次のようである。ブロック１１５で、各ユーザ性能目標クラス１０６に対して、指定目標１１０または１１１を用いて、多重システム性能指標１５１及びローカル性能指標１５２が計算される。多重システム性能指標１５１は、管理される全てのシステム１００に渡る目標クラスに関連付けられる作業単位の性能を表す。ローカル性能指標１５２は、ローカル・システム１００上の目標クラスに関連付けられる作業単位の性能を表す。結果の性能指標１５１、１５２は、対応するクラス・テーブル・エントリ１０６に記録される。ユーザ性能目標の達成度を測定する方法としての性能指標の概念は周知である。例えば、前記のFergusonらによる米国特許第５５０４８９４号では、性能指標として、実際の応答時間が目標応答時間により除算されるように述べられている。
【００３５】
ブロック１１６で、ユーザ性能目標クラスが選択され、相対目標重要度１０８及び性能指標１５１、１５２の現在値の順で、性能改善度を受信する。選択されたユーザ性能目標クラスは、レシーバ（receiver）と呼ばれる。ＭＧＤＰＣ１１４はレシーバを選択するとき、最初に多重システム性能指標１５１を用いることにより、管理される全てのシステム１００に渡り作業単位が目標を満足するために、最も大きな影響を有するアクションを実行する。多重システム性能指標１５１にもとづき実行すべきアクションが存在しない場合、ローカル性能指標１５２が用いられ、ローカル・システム１００がその目標を満足するために最も有用なレシーバが選択される。
【００３６】
候補のレシーバ・クラスが決定された後、周知のように、状態サンプル１２５を用いて性能ボトルネックを構成する、そのクラスの制御変数がブロック１１７で決定される。米国特許第５６７５７３９号で述べられるように、制御変数には、保護プロセッサ記憶ターゲット（ページング遅延に影響）、スワップ保護時間（ＳＰＴ）ターゲット（スワップ遅延に影響）、多重プログラミング・レベル（ＭＰＬ）・ターゲット（ＭＰＬ遅延に影響）、及びディスパッチ優先順位（ＣＰＵ遅延に影響）などの変数が含まれる。本発明によれば、制御変数として、キュー遅延に影響を及ぼすサーバ１６３の数が含まれる。
【００３７】
図１では、サーバ１６３の数１０７が、クラス・テーブル・エントリ１０６に記憶されて示され、これは１クラス当たり、１つのキュー１６１が限度であることを意味する。しかしながら、これは単に説明の簡略化のためであり、当業者であれば、単にデータの位置を変更することにより、１クラス当たり複数のキュー１６１が独立に管理され得ることが理解できよう。基本的な必要条件は、１つのキュー１６１に対する作業要求１６２が１つの目標だけを有すること、各サーバ１６３が要求をサービスするための等しい能力を有すること、及び作業負荷マネージャ１０５からの（への）通知無しでは、サーバが２つ以上のキュー１６１上の作業をサービスすることができないことである。
【００３８】
候補の性能ボトルネックが識別された後、制御変数の潜在的な変化がブロック１１８で考慮される。ブロック１２３で、相対目標重要度１０８及び性能指標１５１、１５２の現在値にもとづき、性能低下が起こり得るユーザ性能目標クラスが選択される。従って、選択されたユーザ性能目標クラスはドナーと呼ばれる。
【００３９】
候補ドナー・クラスが選択された後、提案された変化がブロック１２４で評価される。具体的には、サーバ１６３の数１０７、及び前述され、また米国特許第５６７５７３９号でも述べられる変数を含む制御変数の各々に対して、レシーバ及びドナーの両者において、多重システム性能指標１５１及びローカル性能指標１５２の期待変化に対するネット値が評価される。提案された変化は、結果が目標に対して、ドナーに与える損害よりも多くの改善をレシーバにもたらす場合、ネット値を有する。提案された変化がネット値を有する場合、それぞれの制御変数がドナー及びレシーバの両者に対して調整される。
【００４０】
管理される各システム１００はデータ伝送機構１５５に接続され、これは各システム１００がデータ・レコードをあらゆる他のシステム１００に送信することを可能にする。ブロック１５３で、各目標クラスの最近の性能を記述するデータ・レコードが、あらゆる他のシステム１００に送信される。
【００４１】
多重システム目標駆動型性能制御装置（ＭＧＤＰＣ）機能は、周期的に実行され（好適な実施例では毎１０秒ごとに１度）、タイマ満了を介して呼び出される。ＭＧＤＰＣの機能は、性能問題の増分検出及び訂正のためのフィードバック・ループを提供し、オペレーティング・システム１０１を適応され、自己同調させる。
【００４２】
米国特許第５６７５７３９号で述べられるように、ＭＧＤＰＣインタバルの終わりに、インタバルの間の各目標クラスの性能を記述するデータ・レコードが、管理される各リモート・システム１００に送信される。応答時間目標を有する性能目標クラスに対して、このデータ・レコードは目標クラス名と、リモート応答時間履歴の行（row）に等価なエントリを有する配列とを含む。ここでリモート応答時間履歴は、最後のＭＧＤＰＣインタバルに渡る目標クラスの完了を記述する。速度目標を有する目標クラスに対して、このデータ・レコードは目標クラス名と、目標クラス内の作業が最後のＭＧＤＰＣインタバル内で実行中にサンプリングされた回数と、目標クラス内の作業が最後のＭＧＤＰＣインタバル内で、実行中または遅延中にサンプリングされた回数とを含む。本発明によれば、各システム１００が追加のデータとして、データを送信するシステム１００のサービス有効配列、各キュー１６１に対するサーバ１６３の数、及び各キュー１６１に対する遊休サーバ１６３の数を送信する。
【００４３】
ブロック１５４で、リモート・データ・レシーバがＭＧＤＰＣ１１４とは非同期に、リモート・システム１００から性能データを受信する。受信データはＭＧＤＰＣ１１４による後の処理のために、リモート性能データ履歴（１５７、１５８）に配置される。
【００４４】
図３は、解決する資源ボトルネックを選択するために、ボトルネック発見手段１１７により使用される状態データを示す。各遅延タイプに対して、性能目標クラス・テーブル・エントリ１０６が、その遅延タイプに遭遇するサンプルの数、及びＭＧＤＰＣ１１４の現呼び出しの間に、その遅延タイプが既にボトルネックとして選択されたか否かを示すフラグを含む。クロス・メモリ・ページング・タイプ遅延の場合、クラス・テーブル・エントリ１０６が、遅延に遭遇したアドレス空間の識別子を含む。
【００４５】
ボトルネック発見手段１１７の論理フローが図４に示される。解決するボトルネックの選択は、ＭＧＤＰＣ１１４の現呼び出しの間にまだ選択されておらず、最も多くのサンプルを有する遅延タイプを選択することにより実行される。遅延タイプが選択されると、フラグがセットされ、それによりボトルネック発見手段１１７が、ＭＧＤＰＣ１１４のこの呼び出しの間に再度呼び出される場合、その遅延タイプがスキップされる。
【００４６】
図４のステップ５０１では、ＣＰＵ遅延タイプが、まだ選択されていない全ての遅延タイプの中で、最も多くの遅延サンプルを有するか否かが判断される。肯定の場合、ステップ５０２で、ＣＰＵ遅延選択フラグがセットされ、ＣＰＵ遅延が次に解決されるべきボトルネックとして返却される。
【００４７】
ステップ５０３では、ＭＰＬ遅延タイプが、まだ選択されていない全ての遅延タイプの中で、最も多くの遅延サンプルを有するか否かが判断される。肯定の場合、ステップ５０４で、ＭＰＬ遅延選択フラグがセットされ、ＭＰＬ遅延が次に解決されるべきボトルネックとして返却される。
【００４８】
ステップ５０５では、スワップ遅延タイプが、まだ選択されていない全ての遅延タイプの中で、最も多くの遅延サンプルを有するか否かが判断される。肯定の場合、ステップ５０６で、スワップ遅延選択フラグがセットされ、スワップ遅延が次に解決されるべきボトルネックとして返却される。
【００４９】
ステップ５０７では、ページング遅延タイプが、まだ選択されていない全ての遅延タイプの中で、最も多くの遅延サンプルを有するか否かが判断される。肯定の場合、ステップ５０８で、ページング遅延選択フラグがセットされ、ページング遅延が次に解決されるべきボトルネックとして返却される。５つのタイプのページング遅延が存在する。ステップ５０７では、最も多くの遅延サンプルを有するタイプが突き止められ、ステップ５０８で、特定のタイプに対してフラグがセットされ、その特定のタイプが返却されれる。好適な実施例の環境（ＯＳ／３９０）において周知のように、ページング遅延のタイプには、専用領域、共通領域、クロス・メモリ、仮想入出力（ＶＩＯ）、及びハイパ空間が存在し、各々がページング遅延状況に対応する。
【００５０】
最後にステップ５０９で、キュー遅延タイプが、まだ選択されていない全ての遅延タイプの中で、最も多くの遅延サンプルを有するか否かが判断される。クラスはキュー１６１上の各作業要求に対して、ローカル・システム１００上で実行される資格のある１つのキュー遅延タイプ・サンプルを獲得する。肯定の場合、ステップ５１０で、キュー遅延選択フラグがセットされ、キュー遅延が次に解決されるべきボトルネックとして返却される。キュー遅延は、クラスタ９０内の別のシステム１００が最後のポリシ調整インタバルの間に、キュー１６１に対してサーバ１６３を始動した場合、ローカル・システム１００上では解決されない。キュー遅延はまた、候補レシーバ・クラスが準備完了の作業をスワップ・アウトした場合にも、解決されない。
【００５１】
次のセクションでは、ボトルネック発見手段１１７により選択された遅延を低減するように、制御変数を変更することにより、如何にレシーバ性能目標クラス性能が改善されるか、そして特に、レシーバにより遭遇されるキュー遅延を低減することにより、如何に性能が改善されるかについて述べる。共用キュー１６１の場合、これは２ステップ・プロセスである。第１に、ローカル・システム１００上にサーバ１６３を追加することにより、評価が行われる。この評価には、ドナー作業に対する影響が含まれる。サーバ１６３の追加において、ネット値が存在する場合、次のステップでサーバがローカル・システム１００上で始動されるべきか、或いはそれらがクラスタ９０内の別のシステム１００上で始動されるべきかが決定される。リモート・システム１００がサーバ１６３を始動するために、より好適であると思われる場合、ローカル・システム１００はそのリモート・システムにサーバを始動する機会を与えるために待機する。しかしながら、そのリモート・システム１００がサーバ１６３を始動しない場合、ローカル・システム１００が図９に関連して後述されるように、それらを始動する。
【００５２】
図５は、追加のサーバ１６３を始動することによる、性能の改善を評価する論理フローを示す。図５乃至図７は、固定手段１１８によりネット値手段１２４に提供される性能指標デルタ予測を生成するステップを示す。ステップ１４０１で、サーバ１６３の新たな数が評価のために選択される。この数は変化を価値あるものにするために、十分なレシーバ値（ステップ１４０５でチェックされる）を生成するように十分大きくなければならない。一方、この数は、追加のサーバ１６３の値が限られるように、例えばキューに待機されて実行される作業要求の総数より大きくならないように、余り大きくてはならない。次のステップは、追加のサーバ１６３が使用する追加のＣＰＵを計算する。これは作業要求により使用される平均ＣＰＵに、追加されるサーバ１６３を乗算することにより実行される。
【００５３】
ステップ１４０２で、新たな数のサーバ１６３における作業要求１６２の予測数が、図６に示されるサーバ準備完了ユーザ平均グラフから読出される。ステップ１４０３で、現予測キュー遅延が、図７に示されるキュー遅延グラフから読出される。ステップ１４０４で、ローカル性能指標デルタ及び多重システム性能指標デルタの予測値が計算される。これらの計算は以下で示される。
【００５４】
図６は、キュー準備完了ユーザ平均グラフを示す。キュー準備完了ユーザ平均グラフは、キュー１６１に対するサーバ１６３の数の変化を評価するときに、サーバ１６３に対する需要を予測するために使用される。このグラフは、作業要求１６２がバックアップを開始するポイントを示す。横座標（ｘ）値は、キュー１６１が使用可能なサーバ１６３の数である。縦座標（ｙ）値は、実行準備完了の作業要求１６２の最大数である。
【００５５】
図７は、キュー遅延グラフを表す。キュー遅延グラフは、キュー１６１に対するサーバ１６３の数を増減する値を評価するために使用される。このグラフは、キュー・サーバ１６３の数を増加することにより、如何に応答時間が改善されるか、或いはキュー・サーバ１６３の数を減少することにより、如何に応答時間が低下されるかを示す。グラフはまた、例えばデータベース・ロック競合などの、追加のサーバ１６３を追加することにより生じ得る、作業負荷マネージャ１０５により管理されない資源に対する競合を暗黙的に考慮する。こうした場合では、追加のサーバ１６３が追加されても、グラフ上のキュー遅延が減少しない。横座標値は、使用可能なサーバ１６３を有し、システム１００のクラスタ９０に渡りスワップ・インされる準備完了の作業要求１６２の割合である。縦座標値は１完了当たりのキュー遅延である。
【００５６】
サーバ１６３の数の増加に対する、シスプレックス（すなわち多重システム）性能指標（ＰＩ）デルタは、次のように計算される。ここでシスプレックス性能指標デルタが計算される理由は、キュー１６１がシスプレックス全体に渡る資源であるからである。
【００５７】
応答時間目標に対して、
（予測シスプレックスＰＩデルタ）＝（予測キュー遅延−現キュー遅延）／応答時間目標
【００５８】
速度目標に対して、
（新シスプレックス速度）＝｛cpuu＋（（cpuu／oldserver）*newserver）｝／｛non-idle＋（（qd/qreq）*（oldserver−newserver））｝
（シスプレックスＰＩデルタ）＝（現シスプレックスＰＩ−目標）／新シスプレックス速度
【００５９】
ここで
cpuuは、シスプレックスＣＰＵ使用サンプル；
oldserverは、評価される変化が実行される前のサーバ１６３の数；
newserverは、評価される変化が実行された後のサーバ１６３の数；
non-idleは、シスプレックス非遊休サンプルの総数；
qdは、シスプレックス・キュー遅延サンプル；
qreqは、キュー１６１上の作業要求１６２の数
である。
【００６０】
同様の計算が、サーバ１６３の数の減少に対する性能指標デルタを計算するために使用される。
【００６１】
ステップ１４０５で、追加のサーバ１６３の数により提供される十分なレシーバ値に対してチェックが行われる。好適には、このステップは、新たなサーバ１６３が、それらの追加を価値あるものにするために十分なＣＰＵ時間を獲得するか否かを判断するステップを含む。十分なレシーバ値が存在しない場合、制御はステップ１４０１に戻り、より多くのサーバ１６３が評価のために選択される。
【００６２】
十分なレシーバ値が存在する場合、ステップ１４０６でドナー選択手段１２３が呼び出され、レシーバ性能目標クラスのために、追加のサーバ１６３を始動するために必要な記憶装置のドナーを見い出す。
【００６３】
ドナー・クラスのために調整される制御変数は、必ずしもそのクラスに対するサーバ１６３の数１０７である必要はない。ドナー・クラスの幾つかの異なる制御変数の任意の１つ、例えばＭＰＬスロットまたは保護プロセッサ記憶装置などが、代わりにまたは追加として調整され、追加のサーバ１６３のために必要な記憶装置を提供してもよい。本発明の一部を成すものではないが、こうした制御変数の調整がドナー・クラスに与える効果を評価する方法が、米国特許第５５３７５４２号及び同第５６７５７３９号で述べられている。
【００６４】
ステップ１４０７では、ドナーから記憶装置を受け取り、レシーバ・クラスのためにサーバ１６３の数を増加するに際して、ネット値が存在することを保証するためにチェックが行われる。米国特許第５６７５７３９号で述べられるように、これは１つ以上の幾つかの異なる基準、例えば資源再割当ての後に、ドナーがその目標に合致するように予測されるか否か、レシーバが現在その目標を逸しつつあるか否か、レシーバがドナーよりも重要なクラスか否か、またはドナー及びレシーバの結合性能指標において、ネット利得が存在するか否か、すなわち、サーバをレシーバ・クラスに追加することが、レシーバ・クラスの性能指標に及ぼすプラスの効果が、ドナー・クラスの性能指標に及ぼすマイナスの効果を上回るか否かなどの基準を用いて決定される。ネット値が存在する場合、次のステップで、ローカル・システム１００が新たなサーバ１６３を始動するための（ステップ１４０８）、クラスタ９０内の最善のシステムか否かが決定される。ネット値が存在しない場合、レシーバ目標クラス・キュー遅延問題は解決され得ない（ステップ１４０９）。
【００６５】
図９は、新たなサーバ１６３を始動するクラスタ９０内の最善のシステム１００を表す、ターゲット・システムを決定するプロシージャを示す。このプロシージャは、一旦サーバの追加に対してネット値が存在し、１つ以上のサーバ１６３がレシーバ・クラスに追加されるべきことが決定されると、図５のステップ１４０８の一部として、クラスタ９０内の各システム１００により実行される。ローカル・システム１００が最初に、クラスタ９０内の任意のシステム１００が他の作業に影響すること無く、新たなサーバ１６３をサポートするための十分な遊休容量を有するか否かをチェックする（ステップ８０１）。これはクラスタ９０内の各システム１００のサービス有効配列を調査し、配列要素８において、新たなサーバ１６３をサポートするために使用可能な十分なＣＰＵサービス（未使用ＣＰＵサービス）を有するシステム１００を選択することにより実行される。複数のシステム１００が十分な未使用ＣＰＵサービスを有する場合、最も多くの未使用サービスを有するシステム１００が選択される。しかしながら、キューに待機された作業要求が存在するときに、システム１００が遊休状態のサーバを有する場合、これは多くの作業要求がそのシステム１００に対して親和性を持たないことを意味するので、この遊休状態のサーバ１６３を有するシステム１００は選択されない。
【００６６】
ローカル・システム１００は次に、サーバ１６３を始動するための、十分な遊休状態のＣＰＵ容量を有するターゲット・システム１００が見い出されたか否かをチェックする（ステップ８０２）。ターゲット・システム１００が見い出され、それがローカル・システム１００の場合（ステップ８０３）、ローカル・システム１００がサーバ１６３を局所的に始動する（ステップ８０４乃至８０５）。
【００６７】
ステップ８０３で、別のシステム１００が新たなサーバ１６３を始動するための最も多くの遊休容量を有することが見い出されると、制御はステップ８０６に移行し、ローカル・システム１００がポリシ調整インタバル（１０秒）を待機し、別のシステム１００がサーバ１６３を始動したか否かをチェックする（ステップ８０７）。別のシステム１００がサーバ１６３を始動した場合、局所的に何もアクションは実行されない（ステップ８１１）。他のシステム１００がサーバ１６３を始動しなかった場合、ローカル・システム１００は、自身が新たなサーバ１６３をサポートする十分な遊休ＣＰＵ容量を有するか否かをチェックする（ステップ８１２）。有する場合、ローカル・システム１００は局所的にサーバ１６３を始動する（ステップ８１３乃至８１４）。
【００６８】
新たなサーバ１６３をサポートするための十分な遊休ＣＰＵ容量を有するシステム１００が存在しなかった場合、或いは、十分な遊休ＣＰＵ容量を有するシステム１００が存在したが、そのシステム１００がサーバを始動しなかった場合、制御はステップ８０８に移行する。こうしたシステム１００がサーバ１６３を始動しない１つの理由は、メモリが欠乏するためである。この時点で、ドナー作業に影響を及ぼすこと無しに、新たなサーバ１６３が始動され得ないことが判明する。従って、ローカル・システム１００は、局所的なサーバ１６３の始動により、ドナー作業がその目標を逸するか否かをチェックする。ドナー作業がその目標を逸しない場合、ローカル・システム１００はサーバ１６３を局所的に始動する（ステップ８１７乃至８１８）。サーバ１６３の局所的な始動により、ドナー・クラスがその目標を逸する場合には、ローカル・システム１００はドナー作業への影響が最も小さいシステム１００を見い出す（ステップ８０９）。
【００６９】
図１０は、図９のステップ８０９で、ドナー作業への影響が最も小さいシステム１００を決定するルーチンを示す。ルーチンは最初に、ドナー・クラスの名前及びドナーの性能指標（ＰＩ）デルタを、クラスタ９０内の他のシステムに送信する（ステップ９０１）。このドナー情報を交換することにより、レシーバ・クラスに対するサーバ１６３の追加を評価している各システム１００は、他の全てのシステム１００へのサーバ追加の影響を調査する。ルーチンは次に、他のシステム１００がそれらのドナー情報を送信することを可能にするために、１ポリシ・インタバル（示される実施例では１０秒）を待機する（ステップ９０２）。ルーチンは次に、ドナー・クラスが最も低い重要度を有するシステム１００を選択し（ステップ９０３）、選択されたシステム１００を呼び出しルーチンに返却して、図９のステップ８０９を完了する（ステップ９０５）。ドナー重要度に対等なものが存在する場合（ステップ９０４）、ルーチンはドナーの性能指標（ＰＩ）デルタが最小のシステム１００を選択し（ステップ９０６）、このシステム１００を呼び出しルーチンに返却する（ステップ９０７）。
【００７０】
再度図９を参照して、ステップ８０９を完了後、ローカル・システム１００は、ドナーに対して最も小さな影響を有するとして選択されたシステム１００が、ローカル・システムであるか否かをチェックする（ステップ８１０）。そうである場合、ローカル・システム１００がサーバ１６３を局所的に始動する（ステップ８１７乃至８１８）。それ以外では、ローカル・システム１００は、別のシステム１００がサーバ１６３を始動することを可能にするために、１ポリシ・インタバル待機し（ステップ８１５）、このインタバルの終りに別のシステム１００がサーバ１６３を始動したか否かをチェックする（ステップ８１６）。別のシステム１００がサーバ１６３を始動した場合、ローカル・システム１００は何もアクションを起こさない（ステップ８１８）。他のシステム１００がサーバ１６３を始動しなかった場合、ローカル・システム１００はそれらを局所的に始動する（ステップ８１７乃至８１８）。
【００７１】
図５のステップ１４０８では、特定の環境下のキュー１６１に対して、新たなサーバ１６３を始動する要求を一時的に延期する論理が含まれる。既存の作業への不要な影響を回避するために、新たなサーバ１６３を始動する並列要求が制限される。この歩調合わせは、オペレーティング・システム１０１に、追加のサーバ１６３を始動するための多くの並列要求が殺到し、混乱することを回避する。システム管理者により提供される、データ・レポジトリ１４１内の誤った情報の検出も実行され、新たなサーバ１６３が成功裡に始動され得ない程、サーバ定義情報が不正確な場合に、無限の再試行ループを阻止する。一旦サーバ１６３が始動されると、サーバが予期せず故障した場合に、それを自動的に置換する論理も含まれる。同一のサーバ定義情報を有するが、同一の作業マネージャ１６０に対して異なるキュー１６１をサービスする遊休サーバ１６３が、キュー間で移動され得ることにより、特定のキューに対してサーバ１６３の数を増加する要求が満足され、完全に新たなサーバを始動するオーバヘッドを回避する。
【００７２】
本発明は好適には、１つ以上のハードウェア・マシン上で実行されるソフトウェア（すなわち、プログラム記憶装置上で実現される命令のマシン読出し可能プログラム）として実現される。これまで特定の実施例について述べてきたが、当業者であれば、ここで特定的に述べられた以外の他の実施例も、本発明の趣旨から逸れることなく実現され得ることが明らかであろう。また、当業者であれば、様々な等価な要素が、ここで特定的に開示された要素の代わりに代用され得ることが理解されよう。同様に、ここで開示された実施例の変更及び組み合わせも明らかであろう。例えば、各サービス・クラスに対して、ここで開示された１つのキューではなく、複数のキューが提供され得る。開示された実施例及びそれらの詳細は、本発明の実施例を教示することを意図したのものであって、本発明を制限するものではない。従って、こうした明白ではあるが、ここで開示されなかった変更及び組み合わせも、本発明の趣旨及び範囲に含まれるものと見なされる。
【００７３】
まとめとして、本発明の構成に関して以下の事項を開示する。
【００７４】
（１）情報処理システムのクラスタ内において、キュー内の各作業要求を処理可能なサーバの可用性を保証する方法であって、入来作業要求が前記キューに配置され、前記システム上の１つ以上のサーバにより処理されるものにおいて、
前記キューに対してサーバを有さない前記クラスタのサブセットだけに親和性を有する作業要求が、前記キュー内に存在するか否かを決定するステップと、
前記キューに対してサーバを有さない前記クラスタのサブセットだけに親和性を有する作業要求が、前記キュー内に存在すると決定された場合、前記作業要求が親和性を有する前記サブセット内のシステム上で、前記キューに対してサーバを始動するステップと
を含む、方法。
（２）前記決定するステップが周期的インタバルで実行される、前記（１）記載の方法。
（３）異なるサービス・クラスに割当てられる作業要求が、異なるキューに配置され、前記決定するステップが前記キューの各々に対して実行される、前記（１）記載の方法。
（４）前記決定するステップが、前記クラスタ内の各システムにより実行される、前記（１）記載の方法。
（５）前記決定するステップが、
前記キューが前記システム上にサーバを有するか否かを決定するステップと、
前記キューが前記システム上にサーバを有さない場合、前記クラスタのサブセットだけに親和性を有する作業要求が、前記キュー内に存在するか否かを決定するステップと
を含む、前記（４）記載の方法。
（６）マシンにより読出され、前記マシンにより実行されて、前記（１）記載の方法を実行する命令のプログラムを実現する、プログラム記憶装置。
（７）情報処理システムのクラスタ内において、キュー内の各作業要求を処理可能なサーバの可用性を保証する装置であって、入来作業要求が前記キューに配置され、前記システム上の１つ以上のサーバにより処理されるものにおいて、
前記キューに対してサーバを有さない前記クラスタのサブセットだけに親和性を有する作業要求が、前記キュー内に存在するか否かを決定する手段と、
前記キューに対してサーバを有さない前記クラスタのサブセットだけに親和性を有する作業要求が、前記キュー内に存在すると決定された場合、前記作業要求が親和性を有する前記サブセット内のシステム上で、前記キューに対してサーバを始動する手段と
を含む、装置。
【図面の簡単な説明】
【図１】本発明のために適応化された制御オペレーティング・システム及びシステム資源マネージャ要素を有する、コンピュータ・システムを示すシステム構造図である。
【図２】ネットワークから、本発明の作業負荷マネージャにより管理されるサーバ・アドレス空間へのクライアント作業要求の流れを示す図である。
【図３】資源ボトルネックを選択するために使用される状態データを示す図である。
【図４】ボトルネック発見機能の論理フローを示すフローチャートである。
【図５】サーバの数を増加することにより、改善された性能をアクセスするステップのフローチャートである。
【図６】キュー準備完了ユーザ平均のサンプル・グラフである。
【図７】キュー遅延のサンプル・グラフである。
【図８】クラスタ内のどこかに、キュー上の各要求を実行可能な少なくとも１つのサーバが存在することを保証するプロシージャを示す図である。
【図９】サーバを始動すべきクラスタ内の最善のシステムを決定するプロシージャを示す図である。
【図１０】ドナーへの影響が最も小さいシステムを見い出すプロシージャを示す図である。
【符号の説明】
９０ クラスタ
１００ コンピュータ・システム
１０１ オペレーティング・システム
１０２ ディスパッチャ
１０５ 作業負荷マネージャ（ＷＬＭ）
１０６ クラス・テーブル・エントリ
１０７ サーバの数
１１０ 応答時間目標
１１１ 実行速度目標
１１２ システム資源マネージャ（ＳＲＭ）
１１３ サンプル・データ
１１４ 多重システム目標駆動型制御装置（ＭＧＤＰＣ）
１１７ ボトルネック発見手段
１１８ 固定手段
１２３ ドナー選択手段
１２４ ネット値手段
１２５ サンプル・データ履歴
１２６ 応答時間履歴
１４１ 性能目標
１５１ 多重システム性能指標
１５２ ローカル性能指標
１５５ データ伝送機構
１５７ リモート応答時間履歴
１５８ リモート速度履歴
１６０ 作業マネージャ
１６１ キュー
１６２ 作業要求
１６３ サーバ
１６４ アドレス空間
Claims (7)
- 情報処理システムのクラスタ内で、入来作業要求がキューに配置され、前記システム上の１つ以上のサーバにより処理されるものにおいて、前記キュー内の各作業要求が親和性を持たない前記クラスタのサブセット上に、前記作業要求のサービス・クラスの目標を満たす上で十分なサーバが存在する場合においてもそれぞれの前記作業要求に対するサーバの可用性を保証する方法であって、
前記キューに対してサーバを有さない前記クラスタのサブセットだけに親和性を有する作業要求が、前記キュー内に存在するか否かを決定するステップと、
前記キューに対してサーバを有さない前記クラスタのサブセットだけに親和性を有する作業要求が、前記キュー内に存在すると決定された場合、前記作業要求が親和性を有する前記サブセット内のシステム上で、前記キューに対してサーバを始動するステップと
を含む、方法。 - 前記決定するステップが周期的インタバルで実行される、請求項１記載の方法。
- 異なるサービス・クラスに割当てられる作業要求が、異なるキューに配置され、前記決定するステップが前記キューの各々に対して実行される、請求項１記載の方法。
- 前記決定するステップが、前記クラスタ内の各システムにより実行される、請求項１記載の方法。
- 前記決定するステップが、
前記キューが前記システム上にサーバを有するか否かを決定するステップと、
前記キューが前記システム上にサーバを有さない場合、前記クラスタのサブセットだけに親和性を有する作業要求が、前記キュー内に存在するか否かを決定するステップと
を含む、請求項４記載の方法。 - マシンにより読出され、前記マシンにより実行されて、請求項１記載の方法を実行する命令のプログラムを実現する、プログラム記憶装置。
- 情報処理システムのクラスタ内で、入来作業要求がキューに配置され、前記システム上の１つ以上のサーバにより処理されるものにおいて、前記キュー内の各作業要求が親和性を持たない前記クラスタのサブセット上に、前記作業要求のサービス・クラスの目標を満たす上で十分なサーバが存在する場合においてもそれぞれの前記作業要求に対するサーバの可用性を保証する装置であって、
前記キューに対してサーバを有さない前記クラスタのサブセットだけに親和性を有する作業要求が、前記キュー内に存在するか否かを決定する手段と、
前記キューに対してサーバを有さない前記クラスタのサブセットだけに親和性を有する作業要求が、前記キュー内に存在すると決定された場合、前記作業要求が親和性を有する前記サブセット内のシステム上で、前記キューに対してサーバを始動する手段と
を含む、装置。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/038,573 US6230183B1 (en) | 1998-03-11 | 1998-03-11 | Method and apparatus for controlling the number of servers in a multisystem cluster |
| US09/038573 | 1998-03-18 |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP11035205A Division JP3121584B2 (ja) | 1998-03-11 | 1999-02-15 | 多重システム・クラスタ内のサーバの数を制御する方法及び装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000353103A JP2000353103A (ja) | 2000-12-19 |
| JP4028674B2 true JP4028674B2 (ja) | 2007-12-26 |
Family
ID=21900697
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP11035205A Expired - Fee Related JP3121584B2 (ja) | 1998-03-11 | 1999-02-15 | 多重システム・クラスタ内のサーバの数を制御する方法及び装置 |
| JP2000126482A Expired - Lifetime JP4028674B2 (ja) | 1998-03-11 | 2000-04-26 | 多重システム・クラスタ内のサーバの数を制御する方法及び装置 |
Family Applications Before (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP11035205A Expired - Fee Related JP3121584B2 (ja) | 1998-03-11 | 1999-02-15 | 多重システム・クラスタ内のサーバの数を制御する方法及び装置 |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US6230183B1 (ja) |
| EP (1) | EP0942363B1 (ja) |
| JP (2) | JP3121584B2 (ja) |
| KR (1) | KR100327651B1 (ja) |
Families Citing this family (178)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB9603582D0 (en) | 1996-02-20 | 1996-04-17 | Hewlett Packard Co | Method of accessing service resource items that are for use in a telecommunications system |
| US7295669B1 (en) | 1999-01-21 | 2007-11-13 | Avaya Technology Corp. | Call center telephone and data flow connection system |
| US7200219B1 (en) | 1999-02-10 | 2007-04-03 | Avaya Technology Corp. | Dynamically allocating server resources to competing classes of work based upon achievement of service goals |
| US6560649B1 (en) * | 1999-02-10 | 2003-05-06 | Avaya Technology Corp. | Hierarchical service level remediation for competing classes based upon achievement of service level goals |
| US6587860B1 (en) * | 1999-03-31 | 2003-07-01 | International Business Machines Corporation | Apparatus and method for tracking access to data resources in a cluster environment |
| US7756830B1 (en) | 1999-03-31 | 2010-07-13 | International Business Machines Corporation | Error detection protocol |
| US6470406B1 (en) * | 1999-06-25 | 2002-10-22 | International Business Machines Corporation | Managing isochronous processes in a heterogenous work environment |
| US6732139B1 (en) * | 1999-08-16 | 2004-05-04 | International Business Machines Corporation | Method to distribute programs using remote java objects |
| US6938256B2 (en) * | 2000-01-18 | 2005-08-30 | Galactic Computing Corporation | System for balance distribution of requests across multiple servers using dynamic metrics |
| CA2328335A1 (en) * | 2000-01-24 | 2001-07-24 | Avaya Technology Corp. | Automated transaction distribution system and method allowing selection of agents by transaction initiators |
| US8195823B2 (en) | 2000-04-17 | 2012-06-05 | Circadence Corporation | Dynamic network link acceleration |
| US20110128972A1 (en) | 2000-04-17 | 2011-06-02 | Randy Thornton | Peer to peer dynamic network link acceleration |
| US7043563B2 (en) | 2000-04-17 | 2006-05-09 | Circadence Corporation | Method and system for redirection to arbitrary front-ends in a communication system |
| US8510468B2 (en) | 2000-04-17 | 2013-08-13 | Ciradence Corporation | Route aware network link acceleration |
| US8024481B2 (en) | 2000-04-17 | 2011-09-20 | Circadence Corporation | System and method for reducing traffic and congestion on distributed interactive simulation networks |
| US8898340B2 (en) | 2000-04-17 | 2014-11-25 | Circadence Corporation | Dynamic network link acceleration for network including wireless communication devices |
| US8996705B2 (en) | 2000-04-17 | 2015-03-31 | Circadence Corporation | Optimization of enhanced network links |
| US8065399B2 (en) | 2000-04-17 | 2011-11-22 | Circadence Corporation | Automated network infrastructure test and diagnostic system and method therefor |
| US7844504B1 (en) | 2000-04-27 | 2010-11-30 | Avaya Inc. | Routing based on the contents of a shopping cart |
| US7565651B1 (en) * | 2000-05-25 | 2009-07-21 | Oracle International Corporation | Parallel task scheduling system for computers |
| US8538843B2 (en) | 2000-07-17 | 2013-09-17 | Galactic Computing Corporation Bvi/Bc | Method and system for operating an E-commerce service provider |
| US6816905B1 (en) * | 2000-11-10 | 2004-11-09 | Galactic Computing Corporation Bvi/Bc | Method and system for providing dynamic hosted service management across disparate accounts/sites |
| JP2004519749A (ja) * | 2000-07-17 | 2004-07-02 | ギャラクティック・コンピューティング・コーポレイション | 離隔するアカウント／サイトを越えて動的にホストサービス管理を提供する方法及びシステム |
| US7698710B1 (en) * | 2000-10-19 | 2010-04-13 | International Business Machines Corporation | System and method to improve service in a group of servers |
| US20020078117A1 (en) * | 2000-12-19 | 2002-06-20 | Wang Baldonado Michelle Q. | System for creating efficient multi-step document conversion services |
| US7197749B2 (en) * | 2000-12-19 | 2007-03-27 | Xerox Corporation | Method and system for executing batch jobs by delegating work to independent service providers |
| JP4230673B2 (ja) * | 2001-02-22 | 2009-02-25 | 富士通株式会社 | サービス管理装置 |
| EP1239369A1 (de) | 2001-03-07 | 2002-09-11 | Siemens Aktiengesellschaft | Fehlertolerante Rechneranordnung und Verfahren zum Betrieb einer derartigen Anordnung |
| US7336779B2 (en) * | 2002-03-15 | 2008-02-26 | Avaya Technology Corp. | Topical dynamic chat |
| AU2002302464A1 (en) | 2002-03-25 | 2003-10-08 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and devices for dynamic management of a server application on a server platform |
| US20030217131A1 (en) * | 2002-05-17 | 2003-11-20 | Storage Technology Corporation | Processing distribution using instant copy |
| US7080378B1 (en) * | 2002-05-17 | 2006-07-18 | Storage Technology Corporation | Workload balancing using dynamically allocated virtual servers |
| GB0220846D0 (en) * | 2002-09-07 | 2002-10-16 | Ibm | Remote dynamic configuration of a web server to facilitate capacity on demand |
| US7107272B1 (en) | 2002-12-02 | 2006-09-12 | Storage Technology Corporation | Independent distributed metadata system and method |
| US20040128269A1 (en) * | 2002-12-27 | 2004-07-01 | Milligan Charles A. | System and method for managing data through families of inter-related metadata tables |
| JP4087271B2 (ja) * | 2003-03-19 | 2008-05-21 | 株式会社日立製作所 | 代理応答装置およびネットワークシステム |
| WO2004092971A1 (ja) * | 2003-04-14 | 2004-10-28 | Fujitsu Limited | サーバ割当制御方法 |
| US20050193113A1 (en) * | 2003-04-14 | 2005-09-01 | Fujitsu Limited | Server allocation control method |
| US7472246B2 (en) * | 2003-04-30 | 2008-12-30 | International Business Machines Corporation | Method and system for automated memory reallocating and optimization between logical partitions |
| US7478393B2 (en) * | 2003-04-30 | 2009-01-13 | International Business Machines Corporation | Method for marketing to instant messaging service users |
| US7441033B2 (en) | 2003-08-14 | 2008-10-21 | Oracle International Corporation | On demand node and server instance allocation and de-allocation |
| CN100547583C (zh) | 2003-08-14 | 2009-10-07 | 甲骨文国际公司 | 数据库的自动和动态提供的方法 |
| US7664847B2 (en) | 2003-08-14 | 2010-02-16 | Oracle International Corporation | Managing workload by service |
| US20060064400A1 (en) | 2004-09-21 | 2006-03-23 | Oracle International Corporation, A California Corporation | Methods, systems and software for identifying and managing database work |
| US8365193B2 (en) | 2003-08-14 | 2013-01-29 | Oracle International Corporation | Recoverable asynchronous message driven processing in a multi-node system |
| US7552171B2 (en) | 2003-08-14 | 2009-06-23 | Oracle International Corporation | Incremental run-time session balancing in a multi-node system |
| US7937493B2 (en) | 2003-08-14 | 2011-05-03 | Oracle International Corporation | Connection pool use of runtime load balancing service performance advisories |
| US7953860B2 (en) | 2003-08-14 | 2011-05-31 | Oracle International Corporation | Fast reorganization of connections in response to an event in a clustered computing system |
| US7873684B2 (en) | 2003-08-14 | 2011-01-18 | Oracle International Corporation | Automatic and dynamic provisioning of databases |
| US7516221B2 (en) | 2003-08-14 | 2009-04-07 | Oracle International Corporation | Hierarchical management of the dynamic allocation of resources in a multi-node system |
| US7437460B2 (en) | 2003-08-14 | 2008-10-14 | Oracle International Corporation | Service placement for enforcing performance and availability levels in a multi-node system |
| US7437459B2 (en) | 2003-08-14 | 2008-10-14 | Oracle International Corporation | Calculation of service performance grades in a multi-node environment that hosts the services |
| CA2533744C (en) * | 2003-08-14 | 2010-01-12 | Oracle International Corporation | Hierarchical management of the dynamic allocation of resources in a multi-node system |
| US8094804B2 (en) | 2003-09-26 | 2012-01-10 | Avaya Inc. | Method and apparatus for assessing the status of work waiting for service |
| US7770175B2 (en) * | 2003-09-26 | 2010-08-03 | Avaya Inc. | Method and apparatus for load balancing work on a network of servers based on the probability of being serviced within a service time goal |
| US20050071241A1 (en) * | 2003-09-26 | 2005-03-31 | Flockhart Andrew D. | Contact center resource allocation based on work bidding/auction |
| WO2005041038A1 (ja) | 2003-10-29 | 2005-05-06 | Ibm Japan, Ltd. | 情報システム、負荷制御方法、負荷制御プログラム及び記録媒体 |
| US7886055B1 (en) | 2005-04-28 | 2011-02-08 | Hewlett-Packard Development Company, L.P. | Allocating resources in a system having multiple tiers |
| US7581008B2 (en) * | 2003-11-12 | 2009-08-25 | Hewlett-Packard Development Company, L.P. | System and method for allocating server resources |
| US8457300B2 (en) | 2004-02-12 | 2013-06-04 | Avaya Inc. | Instant message contact management in a contact center |
| US7729490B2 (en) * | 2004-02-12 | 2010-06-01 | Avaya Inc. | Post-termination contact management |
| US8311974B2 (en) | 2004-02-20 | 2012-11-13 | Oracle International Corporation | Modularized extraction, transformation, and loading for a database |
| US7885401B1 (en) | 2004-03-29 | 2011-02-08 | Avaya Inc. | Method and apparatus to forecast the availability of a resource |
| US8000989B1 (en) | 2004-03-31 | 2011-08-16 | Avaya Inc. | Using true value in routing work items to resources |
| US7328265B2 (en) * | 2004-03-31 | 2008-02-05 | International Business Machines Corporation | Method and system to aggregate evaluation of at least one metric across a plurality of resources |
| US7953859B1 (en) | 2004-03-31 | 2011-05-31 | Avaya Inc. | Data model of participation in multi-channel and multi-party contacts |
| US7734032B1 (en) | 2004-03-31 | 2010-06-08 | Avaya Inc. | Contact center and method for tracking and acting on one and done customer contacts |
| US8554806B2 (en) | 2004-05-14 | 2013-10-08 | Oracle International Corporation | Cross platform transportable tablespaces |
| US7844969B2 (en) * | 2004-06-17 | 2010-11-30 | Platform Computing Corporation | Goal-oriented predictive scheduling in a grid environment |
| US7340654B2 (en) * | 2004-06-17 | 2008-03-04 | Platform Computing Corporation | Autonomic monitoring in a grid environment |
| US7861246B2 (en) * | 2004-06-17 | 2010-12-28 | Platform Computing Corporation | Job-centric scheduling in a grid environment |
| US7299231B2 (en) | 2004-07-29 | 2007-11-20 | International Business Machines Corporation | Method and system of subsetting a cluster of servers |
| JP4485428B2 (ja) * | 2004-08-02 | 2010-06-23 | 株式会社ソニー・コンピュータエンタテインメント | ネットワークシステム、管理コンピュータ、クラスタ管理方法およびコンピュータプログラム |
| US8122201B1 (en) * | 2004-09-21 | 2012-02-21 | Emc Corporation | Backup work request processing by accessing a work request of a data record stored in global memory |
| US7529724B1 (en) * | 2004-09-21 | 2009-05-05 | Emc Corporation | Servicing work requests between units of a storage device |
| US7949121B1 (en) | 2004-09-27 | 2011-05-24 | Avaya Inc. | Method and apparatus for the simultaneous delivery of multiple contacts to an agent |
| US8234141B1 (en) | 2004-09-27 | 2012-07-31 | Avaya Inc. | Dynamic work assignment strategies based on multiple aspects of agent proficiency |
| US7949123B1 (en) | 2004-09-28 | 2011-05-24 | Avaya Inc. | Wait time predictor for long shelf-life work |
| US7657021B2 (en) * | 2004-09-29 | 2010-02-02 | Avaya Inc. | Method and apparatus for global call queue in a global call center |
| JP4180638B2 (ja) * | 2004-10-28 | 2008-11-12 | 富士通株式会社 | 分析方法及び装置 |
| US7818386B2 (en) | 2004-12-30 | 2010-10-19 | Oracle International Corporation | Repeatable message streams for message queues in distributed systems |
| US7779418B2 (en) | 2004-12-30 | 2010-08-17 | Oracle International Corporation | Publisher flow control and bounded guaranteed delivery for message queues |
| US9176772B2 (en) | 2005-02-11 | 2015-11-03 | Oracle International Corporation | Suspending and resuming of sessions |
| US7817796B1 (en) | 2005-04-27 | 2010-10-19 | Avaya Inc. | Coordinating work assignments for contact center agents |
| US7809127B2 (en) | 2005-05-26 | 2010-10-05 | Avaya Inc. | Method for discovering problem agent behaviors |
| JP2006338322A (ja) * | 2005-06-02 | 2006-12-14 | Hitachi Ltd | オンラインのリソース割当て方法 |
| US7779042B1 (en) | 2005-08-08 | 2010-08-17 | Avaya Inc. | Deferred control of surrogate key generation in a distributed processing architecture |
| US7881450B1 (en) | 2005-09-15 | 2011-02-01 | Avaya Inc. | Answer on hold notification |
| US8577015B2 (en) * | 2005-09-16 | 2013-11-05 | Avaya Inc. | Method and apparatus for the automated delivery of notifications to contacts based on predicted work prioritization |
| US8116446B1 (en) | 2005-10-03 | 2012-02-14 | Avaya Inc. | Agent driven work item awareness for tuning routing engine work-assignment algorithms |
| US7822587B1 (en) | 2005-10-03 | 2010-10-26 | Avaya Inc. | Hybrid database architecture for both maintaining and relaxing type 2 data entity behavior |
| US8073129B1 (en) | 2005-10-03 | 2011-12-06 | Avaya Inc. | Work item relation awareness for agents during routing engine driven sub-optimal work assignments |
| US10572879B1 (en) | 2005-10-03 | 2020-02-25 | Avaya Inc. | Agent driven media-agnostic work item grouping and sharing over a consult medium |
| US8411843B1 (en) | 2005-10-04 | 2013-04-02 | Avaya Inc. | Next agent available notification |
| US7752230B2 (en) | 2005-10-06 | 2010-07-06 | Avaya Inc. | Data extensibility using external database tables |
| US7787609B1 (en) | 2005-10-06 | 2010-08-31 | Avaya Inc. | Prioritized service delivery based on presence and availability of interruptible enterprise resources with skills |
| US8196150B2 (en) | 2005-10-07 | 2012-06-05 | Oracle International Corporation | Event locality using queue services |
| US7526409B2 (en) | 2005-10-07 | 2009-04-28 | Oracle International Corporation | Automatic performance statistical comparison between two periods |
| US8238541B1 (en) | 2006-01-31 | 2012-08-07 | Avaya Inc. | Intent based skill-set classification for accurate, automatic determination of agent skills |
| US8737173B2 (en) | 2006-02-24 | 2014-05-27 | Avaya Inc. | Date and time dimensions for contact center reporting in arbitrary international time zones |
| US8442197B1 (en) | 2006-03-30 | 2013-05-14 | Avaya Inc. | Telephone-based user interface for participating simultaneously in more than one teleconference |
| US9785477B2 (en) * | 2006-06-05 | 2017-10-10 | International Business Machines Corporation | Providing a policy hierarchy in an enterprise data processing system |
| US7936867B1 (en) | 2006-08-15 | 2011-05-03 | Avaya Inc. | Multi-service request within a contact center |
| US8391463B1 (en) | 2006-09-01 | 2013-03-05 | Avaya Inc. | Method and apparatus for identifying related contacts |
| US8811597B1 (en) | 2006-09-07 | 2014-08-19 | Avaya Inc. | Contact center performance prediction |
| US8938063B1 (en) | 2006-09-07 | 2015-01-20 | Avaya Inc. | Contact center service monitoring and correcting |
| US8855292B1 (en) | 2006-09-08 | 2014-10-07 | Avaya Inc. | Agent-enabled queue bypass to agent |
| US7835514B1 (en) | 2006-09-18 | 2010-11-16 | Avaya Inc. | Provide a graceful transfer out of active wait treatment |
| US7747726B2 (en) * | 2006-09-20 | 2010-06-29 | International Business Machines Corporation | Method and apparatus for estimating a local performance index to measure the performance contribution of a single server in a multi-tiered environment |
| US20080077932A1 (en) * | 2006-09-25 | 2008-03-27 | International Business Machines Corporation | Mechanism for Automatically Managing the Resource Consumption of Transactional Workloads |
| US8909599B2 (en) | 2006-11-16 | 2014-12-09 | Oracle International Corporation | Efficient migration of binary XML across databases |
| US20080120164A1 (en) * | 2006-11-17 | 2008-05-22 | Avaya Technology Llc | Contact center agent work awareness algorithm |
| US20080162246A1 (en) * | 2007-01-03 | 2008-07-03 | International Business Machines Corporation | Method and system for contract based call center and/or contact center management |
| US8767944B1 (en) | 2007-01-03 | 2014-07-01 | Avaya Inc. | Mechanism for status and control communication over SIP using CODEC tunneling |
| US7958188B2 (en) * | 2007-05-04 | 2011-06-07 | International Business Machines Corporation | Transaction-initiated batch processing |
| US7747705B1 (en) | 2007-05-08 | 2010-06-29 | Avaya Inc. | Method to make a discussion forum or RSS feed a source for customer contact into a multimedia contact center that is capable of handling emails |
| US8504534B1 (en) | 2007-09-26 | 2013-08-06 | Avaya Inc. | Database structures and administration techniques for generalized localization of database items |
| US8296418B2 (en) * | 2008-01-21 | 2012-10-23 | International Business Machines Corporation | Optimized modification of a clustered computer system |
| US8856182B2 (en) | 2008-01-25 | 2014-10-07 | Avaya Inc. | Report database dependency tracing through business intelligence metadata |
| US8831206B1 (en) | 2008-05-12 | 2014-09-09 | Avaya Inc. | Automated, data-based mechanism to detect evolution of employee skills |
| US8385532B1 (en) | 2008-05-12 | 2013-02-26 | Avaya Inc. | Real-time detective |
| US8131872B2 (en) * | 2008-05-30 | 2012-03-06 | International Business Machines Corporation | Affinity-based transaction processing |
| US10375244B2 (en) * | 2008-08-06 | 2019-08-06 | Avaya Inc. | Premises enabled mobile kiosk, using customers' mobile communication device |
| US8116237B2 (en) | 2008-09-26 | 2012-02-14 | Avaya Inc. | Clearing house for publish/subscribe of status data from distributed telecommunications systems |
| KR20100035394A (ko) * | 2008-09-26 | 2010-04-05 | 삼성전자주식회사 | 멀티 프로세싱에서의 메모리 관리장치 및 그 방법 |
| US9965333B2 (en) | 2009-04-13 | 2018-05-08 | International Business Machines Corporation | Automated workload selection |
| US8621011B2 (en) * | 2009-05-12 | 2013-12-31 | Avaya Inc. | Treatment of web feeds as work assignment in a contact center |
| US8964958B2 (en) | 2009-05-20 | 2015-02-24 | Avaya Inc. | Grid-based contact center |
| US8238538B2 (en) | 2009-05-28 | 2012-08-07 | Comcast Cable Communications, Llc | Stateful home phone service |
| US8644491B2 (en) * | 2009-08-21 | 2014-02-04 | Avaya Inc. | Mechanism for multisite service state description |
| US8881729B2 (en) | 2009-09-18 | 2014-11-11 | 3M Innovative Properties Company | Horizontal flat-fold filtering face-piece respirator having indicia of symmetry |
| US8385533B2 (en) | 2009-09-21 | 2013-02-26 | Avaya Inc. | Bidding work assignment on conference/subscribe RTP clearing house |
| US8565386B2 (en) | 2009-09-29 | 2013-10-22 | Avaya Inc. | Automatic configuration of soft phones that are usable in conjunction with special-purpose endpoints |
| US9516069B2 (en) | 2009-11-17 | 2016-12-06 | Avaya Inc. | Packet headers as a trigger for automatic activation of special-purpose softphone applications |
| US9104411B2 (en) | 2009-12-16 | 2015-08-11 | Qualcomm Incorporated | System and method for controlling central processing unit power with guaranteed transient deadlines |
| US9128705B2 (en) | 2009-12-16 | 2015-09-08 | Qualcomm Incorporated | System and method for controlling central processing unit power with reduced frequency oscillations |
| US8775830B2 (en) | 2009-12-16 | 2014-07-08 | Qualcomm Incorporated | System and method for dynamically controlling a plurality of cores in a multicore central processing unit based on temperature |
| US8909962B2 (en) | 2009-12-16 | 2014-12-09 | Qualcomm Incorporated | System and method for controlling central processing unit power with guaranteed transient deadlines |
| US8650426B2 (en) * | 2009-12-16 | 2014-02-11 | Qualcomm Incorporated | System and method for controlling central processing unit power in a virtualized system |
| US9176572B2 (en) | 2009-12-16 | 2015-11-03 | Qualcomm Incorporated | System and method for controlling central processing unit power with guaranteed transient deadlines |
| US8689037B2 (en) | 2009-12-16 | 2014-04-01 | Qualcomm Incorporated | System and method for asynchronously and independently controlling core clocks in a multicore central processing unit |
| US9563250B2 (en) | 2009-12-16 | 2017-02-07 | Qualcomm Incorporated | System and method for controlling central processing unit power based on inferred workload parallelism |
| US8869160B2 (en) * | 2009-12-24 | 2014-10-21 | International Business Machines Corporation | Goal oriented performance management of workload utilizing accelerators |
| US9165086B2 (en) | 2010-01-20 | 2015-10-20 | Oracle International Corporation | Hybrid binary XML storage model for efficient XML processing |
| US8306212B2 (en) | 2010-02-19 | 2012-11-06 | Avaya Inc. | Time-based work assignments in automated contact distribution |
| GB201008819D0 (en) * | 2010-05-26 | 2010-07-14 | Zeus Technology Ltd | Apparatus for routing requests |
| JP5939740B2 (ja) | 2011-04-11 | 2016-06-22 | インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ | 動的にリソースを割り当てる方法、システム及びプログラム |
| US8675860B2 (en) | 2012-02-16 | 2014-03-18 | Avaya Inc. | Training optimizer for contact center agents |
| US8650538B2 (en) | 2012-05-01 | 2014-02-11 | Concurix Corporation | Meta garbage collection for functional code |
| US8726255B2 (en) | 2012-05-01 | 2014-05-13 | Concurix Corporation | Recompiling with generic to specific replacement |
| US9417935B2 (en) | 2012-05-01 | 2016-08-16 | Microsoft Technology Licensing, Llc | Many-core process scheduling to maximize cache usage |
| US8595743B2 (en) | 2012-05-01 | 2013-11-26 | Concurix Corporation | Network aware process scheduling |
| US8495598B2 (en) | 2012-05-01 | 2013-07-23 | Concurix Corporation | Control flow graph operating system configuration |
| US8700838B2 (en) | 2012-06-19 | 2014-04-15 | Concurix Corporation | Allocating heaps in NUMA systems |
| US9047196B2 (en) | 2012-06-19 | 2015-06-02 | Concurix Corporation | Usage aware NUMA process scheduling |
| US8707326B2 (en) | 2012-07-17 | 2014-04-22 | Concurix Corporation | Pattern matching process scheduler in message passing environment |
| US8793669B2 (en) | 2012-07-17 | 2014-07-29 | Concurix Corporation | Pattern extraction from executable code in message passing environments |
| US9575813B2 (en) | 2012-07-17 | 2017-02-21 | Microsoft Technology Licensing, Llc | Pattern matching process scheduler with upstream optimization |
| US9043788B2 (en) | 2012-08-10 | 2015-05-26 | Concurix Corporation | Experiment manager for manycore systems |
| US8656135B2 (en) | 2012-11-08 | 2014-02-18 | Concurix Corporation | Optimized memory configuration deployed prior to execution |
| US8656134B2 (en) | 2012-11-08 | 2014-02-18 | Concurix Corporation | Optimized memory configuration deployed on executing code |
| US8607018B2 (en) | 2012-11-08 | 2013-12-10 | Concurix Corporation | Memory usage configuration based on observations |
| US9665474B2 (en) | 2013-03-15 | 2017-05-30 | Microsoft Technology Licensing, Llc | Relationships derived from trace data |
| US9537742B2 (en) * | 2013-06-25 | 2017-01-03 | Microsoft Technology Licensing Llc | Automatic adjustment of application launch endpoints |
| CN106897140B (zh) * | 2015-12-21 | 2021-07-13 | 中国移动通信集团辽宁有限公司 | 一种输出调节方法、装置和系统 |
| US10540217B2 (en) | 2016-09-16 | 2020-01-21 | Oracle International Corporation | Message cache sizing |
| US10474653B2 (en) | 2016-09-30 | 2019-11-12 | Oracle International Corporation | Flexible in-memory column store placement |
| US12007941B2 (en) | 2017-09-29 | 2024-06-11 | Oracle International Corporation | Session state tracking |
| US10277524B1 (en) * | 2018-02-23 | 2019-04-30 | Capital One Services, Llc | Monitoring data streams and scaling computing resources based on the data streams |
| US10754720B2 (en) * | 2018-09-26 | 2020-08-25 | International Business Machines Corporation | Health check diagnostics of resources by instantiating workloads in disaggregated data centers |
| US10838803B2 (en) | 2018-09-26 | 2020-11-17 | International Business Machines Corporation | Resource provisioning and replacement according to a resource failure analysis in disaggregated data centers |
| US11188408B2 (en) | 2018-09-26 | 2021-11-30 | International Business Machines Corporation | Preemptive resource replacement according to failure pattern analysis in disaggregated data centers |
| US10831580B2 (en) | 2018-09-26 | 2020-11-10 | International Business Machines Corporation | Diagnostic health checking and replacement of resources in disaggregated data centers |
| US10761915B2 (en) | 2018-09-26 | 2020-09-01 | International Business Machines Corporation | Preemptive deep diagnostics and health checking of resources in disaggregated data centers |
| US11050637B2 (en) | 2018-09-26 | 2021-06-29 | International Business Machines Corporation | Resource lifecycle optimization in disaggregated data centers |
| US11936739B2 (en) | 2019-09-12 | 2024-03-19 | Oracle International Corporation | Automated reset of session state |
| US11556446B2 (en) * | 2020-09-25 | 2023-01-17 | International Business Machines Corporation | Programmatic performance anomaly detection |
| CN113746887B (zh) * | 2020-11-05 | 2024-06-18 | 北京沃东天骏信息技术有限公司 | 一种跨集群数据请求处理方法、设备及存储介质 |
Family Cites Families (26)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4468736A (en) | 1982-06-08 | 1984-08-28 | Burroughs Corporation | Mechanism for creating dependency free code for multiple processing elements |
| US5253342A (en) * | 1989-01-18 | 1993-10-12 | International Business Machines Corporation | Intermachine communication services |
| JP2967999B2 (ja) | 1989-07-06 | 1999-10-25 | 富士通株式会社 | プロセスの実行多重度制御処理装置 |
| US5170466A (en) * | 1989-10-10 | 1992-12-08 | Unisys Corporation | Storage/retrieval system for document |
| EP0422310A1 (en) | 1989-10-10 | 1991-04-17 | International Business Machines Corporation | Distributed mechanism for the fast scheduling of shared objects |
| US5283897A (en) | 1990-04-30 | 1994-02-01 | International Business Machines Corporation | Semi-dynamic load balancer for periodically reassigning new transactions of a transaction type from an overload processor to an under-utilized processor based on the predicted load thereof |
| US5504894A (en) | 1992-04-30 | 1996-04-02 | International Business Machines Corporation | Workload manager for achieving transaction class response time goals in a multiprocessing system |
| US5414845A (en) | 1992-06-26 | 1995-05-09 | International Business Machines Corporation | Network-based computer system with improved network scheduling system |
| JPH0628323A (ja) * | 1992-07-06 | 1994-02-04 | Nippon Telegr & Teleph Corp <Ntt> | プロセス実行制御方法 |
| US5675733A (en) | 1992-11-30 | 1997-10-07 | International Business Machines Corporation | Statistical analysis and display of reception status of electronic messages |
| JPH06332834A (ja) * | 1993-05-25 | 1994-12-02 | Hitachi Ltd | リモートプロシジャコール方法 |
| US5537542A (en) | 1994-04-04 | 1996-07-16 | International Business Machines Corporation | Apparatus and method for managing a server workload according to client performance goals in a client/server data processing system |
| US5473773A (en) | 1994-04-04 | 1995-12-05 | International Business Machines Corporation | Apparatus and method for managing a data processing system workload according to two or more distinct processing goals |
| EP0694837A1 (en) | 1994-07-25 | 1996-01-31 | International Business Machines Corporation | Dynamic workload balancing |
| JPH0863441A (ja) * | 1994-08-26 | 1996-03-08 | Hitachi Ltd | 並列システムの運用方法 |
| US5675739A (en) * | 1995-02-03 | 1997-10-07 | International Business Machines Corporation | Apparatus and method for managing a distributed data processing system workload according to a plurality of distinct processing goal types |
| EP0725340A3 (en) * | 1995-02-03 | 1996-10-02 | Ibm | Apparatus and method for managing the workload of a distributed data processing system by limiting the consumption of processing capacity |
| US5630133A (en) | 1995-06-07 | 1997-05-13 | Tandem Computers, Incorporated | Customer information control system and method with API start and cancel transaction functions in a loosely coupled parallel processing environment |
| US5603029A (en) * | 1995-06-07 | 1997-02-11 | International Business Machines Corporation | System of assigning work requests based on classifying into an eligible class where the criteria is goal oriented and capacity information is available |
| US6249800B1 (en) * | 1995-06-07 | 2001-06-19 | International Business Machines Corporartion | Apparatus and accompanying method for assigning session requests in a multi-server sysplex environment |
| US5666486A (en) | 1995-06-23 | 1997-09-09 | Data General Corporation | Multiprocessor cluster membership manager framework |
| JP2776338B2 (ja) | 1995-10-03 | 1998-07-16 | 日本電気株式会社 | ジョブスケジューリング方式 |
| JP3754481B2 (ja) | 1996-02-02 | 2006-03-15 | 富士通株式会社 | 複合計算機システム |
| US5784697A (en) | 1996-03-27 | 1998-07-21 | International Business Machines Corporation | Process assignment by nodal affinity in a myultiprocessor system having non-uniform memory access storage architecture |
| US5925102A (en) * | 1997-03-28 | 1999-07-20 | International Business Machines Corporation | Managing processor resources in a multisystem environment in order to provide smooth real-time data streams, while enabling other types of applications to be processed concurrently |
| US5974462A (en) * | 1997-03-28 | 1999-10-26 | International Business Machines Corporation | Method and apparatus for controlling the number of servers in a client/server system |
-
1998
- 1998-03-11 US US09/038,573 patent/US6230183B1/en not_active Expired - Lifetime
-
1999
- 1999-02-15 JP JP11035205A patent/JP3121584B2/ja not_active Expired - Fee Related
- 1999-02-22 EP EP99301244A patent/EP0942363B1/en not_active Expired - Lifetime
- 1999-03-05 KR KR1019990007317A patent/KR100327651B1/ko not_active IP Right Cessation
-
2000
- 2000-04-26 JP JP2000126482A patent/JP4028674B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| KR19990077640A (ko) | 1999-10-25 |
| JP2000353103A (ja) | 2000-12-19 |
| EP0942363A2 (en) | 1999-09-15 |
| KR100327651B1 (ko) | 2002-03-08 |
| JPH11282695A (ja) | 1999-10-15 |
| EP0942363A3 (en) | 2000-03-29 |
| US6230183B1 (en) | 2001-05-08 |
| EP0942363B1 (en) | 2011-08-31 |
| JP3121584B2 (ja) | 2001-01-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4028674B2 (ja) | 多重システム・クラスタ内のサーバの数を制御する方法及び装置 | |
| US5974462A (en) | Method and apparatus for controlling the number of servers in a client/server system | |
| US11068301B1 (en) | Application hosting in a distributed application execution system | |
| USRE44686E1 (en) | Dynamically modifying the resources of a virtual server | |
| US20180246771A1 (en) | Automated workflow selection | |
| US8959515B2 (en) | Task scheduling policy for limited memory systems | |
| US7899966B2 (en) | Methods and system for interrupt distribution in a multiprocessor system | |
| US7734676B2 (en) | Method for controlling the number of servers in a hierarchical resource environment | |
| US7877482B1 (en) | Efficient application hosting in a distributed application execution system | |
| US8078674B2 (en) | Server device operating in response to received request | |
| EP1672495B1 (en) | Grid parallel execution | |
| JP2007207219A (ja) | 計算機システムの管理方法、管理サーバ、計算機システム及びプログラム | |
| US8914582B1 (en) | Systems and methods for pinning content in cache | |
| JP2012094030A (ja) | 計算機システム及び処理制御方法 | |
| US11809218B2 (en) | Optimal dispatching of function-as-a-service in heterogeneous accelerator environments | |
| JP2007328413A (ja) | 負荷分散方法 | |
| Nicodemus et al. | Managing vertical memory elasticity in containers | |
| US5511220A (en) | Multi-user computer system with a clock driven batch dispatching mechanism | |
| CA2316643C (en) | Fair assignment of processing resources to queued requests | |
| US11520638B1 (en) | Combined active and preinitialized resource management for rapid autoscaling | |
| JP2003186686A (ja) | リソース制御装置、方法及び記憶媒体 | |
| Hui et al. | A delay scheduling strategy for dynamic load balancing schedulers | |
| Deese | Evaluating and Improving CICS Performance in MVS (Goal Mode) |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040210 |
|
| RD12 | Notification of acceptance of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7432 Effective date: 20040304 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20040305 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20041006 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050203 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20050218 |
|
| A912 | Re-examination (zenchi) completed and case transferred to appeal board |
Free format text: JAPANESE INTERMEDIATE CODE: A912 Effective date: 20050603 |
|
| RD14 | Notification of resignation of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7434 Effective date: 20070306 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070910 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20071012 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101019 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101019 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111019 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121019 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121019 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131019 Year of fee payment: 6 |
|
| EXPY | Cancellation because of completion of term |