動作不能なマスタ作業負荷管理プロセスを代替するシステムおよび方法
【課題】作業負荷管理機能により、コンピューティング資源をより効率的に使用可能とする。
【解決手段】本発明にかかる方法は、複数のコンピューティング区画内の各作業負荷管理プロセスを実行し、少なくともプロセッサ資源を複数のコンピューティング区画内で実行されるアプリケーションに割り振り、作業負荷管理プロセスからの追加資源受け取り要求に応答して、プロセッサ資源を複数のコンピューティング区画に再割り振りし、マスタ作業負荷管理プロセスの動作を他の作業負荷管理プロセスにより監視し、他の作業負荷管理プロセスにより、マスタ作業負荷管理プロセスが動作不能になったときを検出し、検出することに応答して、他の作業負荷管理プロセスにより代替マスタ作業負荷管理プロセスを選択する。
【解決手段】本発明にかかる方法は、複数のコンピューティング区画内の各作業負荷管理プロセスを実行し、少なくともプロセッサ資源を複数のコンピューティング区画内で実行されるアプリケーションに割り振り、作業負荷管理プロセスからの追加資源受け取り要求に応答して、プロセッサ資源を複数のコンピューティング区画に再割り振りし、マスタ作業負荷管理プロセスの動作を他の作業負荷管理プロセスにより監視し、他の作業負荷管理プロセスにより、マスタ作業負荷管理プロセスが動作不能になったときを検出し、検出することに応答して、他の作業負荷管理プロセスにより代替マスタ作業負荷管理プロセスを選択する。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願）
本願は、同時係属中であり、本願と同じ譲受人に譲渡された米国特許出願第１０／２０６，５９４号、名称「DYNAMIC MANAGEMENT OF VIRTUAL PARTITION COMPUTER WORKLOADS THROUGH SERVICE LEVEL OPTIMIZATION」、２００２年７月２６日出願に関連する。
【０００２】
本願は、包括的には動作不能なマスタ作業負荷管理プロセスの代替に関する。
【背景技術】
【０００３】
多くの企業が、組織内でのコンピュータ数およびアプリケーション数の劇的な増加を経験した。
企業内のビジネスグループが新規アプリケーションを配備する場合には通常、１つまたは複数の専用サーバプラットフォームが新規アプリケーションをホストするために追加される。
このタイプの環境は、時に「ワンアプリケーションパーボックス（one-app-per-box）」と呼ばれることがある。
デジタル化されるビジネスプロセスが多くなるにつれて、「ワンアプリケーションパーボックス」環境は過度な数のサーバプラットフォームに繋がる。
その結果として、サーバプラットフォームの管理コストが大幅に上昇する。
さらに、サーバプラットフォーム資源が実際に使用される時間の割合（利用率）はかなり低くなり得る。
【０００４】
こういった問題に対処するために、多くの企業は複数のアプリケーションを共通サーバプラットフォームに統合して、プラットフォーム数を削減するとともに、システムの利用率を上げている。
このような統合が行われる場合には、複数のアプリケーション間のプラットフォームの資源の調整が適切である。
たとえば、サポートされるアプリケーションの各種スレッドによるプロセッサ資源へのアクセスを制御するスケジューリングメカニズムを提供することが望ましい。
スケジューリングメカニズムによっては（たとえば、「作業負荷管理」機能）、プロセスのスケジューリングを制御するために分け前、規則、優先度、サービスレベル目標等の一式を提供するものがある。
【０００５】
作業負荷管理の一例には、共有資源ドメインに複数の仮想パーティションを作成することが挙げられる。
各種資源（プロセッサ、メモリ、入出力（Ｉ／Ｏ）資源等）が通常、各仮想パーティションに割り当てられる。
また、各オペレーティングシステムを各仮想パーティション内で実行することができる。
関連するアプリケーションの各グループを各仮想パーティション内で実行することができる。
仮想パーティションの構成は、各仮想パーティションのアプリケーション群間で或る程度の区分けを提供する。
さらに、作業負荷管理プロセスを各仮想パーティション内で実行して、仮想パーティション内の資源へのアクセスを制御することができる。
具体的には、特定の仮想パーティション内で、作業負荷管理プロセスは、仮想パーティションに割り当てられたグループのアプリケーション間でのプロセッサ資源へのアクセスをスケジュールすることができる。
【０００６】
仮想パーティション内の作業負荷管理に加えて、資源を仮想パーティション間に再割り振りすることによって別のレベルの資源管理が行われる。
具体的には、仮想パーティション内の作業負荷管理プロセスにより、サービスレベル目標をアプリケーショングループで満たすことができないと判断される場合、作業負荷管理プロセスは、「大域的」作業負荷管理プロセスからの資源の追加を要求することができる。
規則、分け前、優先度、サービスレベル目標等に基づいて、大域的作業負荷管理プロセスは、別の仮想パーティションから要求を行っているパーティションに資源をシフトすることができる。
たとえば、他のパーティションに過剰資源がある場合、そういった資源を、要求を行っている仮想パーティションに再割り当てすることができる。
作業負荷管理機能の使用により、コンピューティング資源に関連する利用率を向上させることが可能になる。
したがって、作業負荷管理機能により、コンピューティング資源をより効率的に使用することが可能になる。
【発明の開示】
【課題を解決するための手段】
【０００７】
一実施形態において、方法は、複数のコンピューティング区画内の各作業負荷管理プロセスを実行することであって、それによって少なくともプロセッサ資源を複数のコンピューティング区画内で実行されるアプリケーションに割り振る、実行すること、マスタ作業負荷管理プロセスを選択することであって、それにより、作業負荷管理プロセスからの追加資源受け取り要求に応答して、プロセッサ資源を複数のコンピューティング区画に再割り振りする、選択すること、マスタ作業負荷管理プロセスの動作を他の作業負荷管理プロセスにより監視すること、他の作業負荷管理プロセスにより、マスタ作業負荷管理プロセスが動作不能になったときを検出すること、検出することに応答して、他の作業負荷管理プロセスにより代替マスタ作業負荷管理プロセスを選択すること、とを含む。
【発明を実施するための最良の形態】
【０００８】
既知の作業負荷管理機能は、従来技術によるコンピューティング環境と比較して多くの利点を提供するが、既知の作業負荷管理機能にはいくつかの制約がある。
具体的には、大域的作業負荷管理プロセスに影響するシステム故障が発生した場合、仮想パーティション間の資源の共有が停止することになる。
したがって、資源の利用率は、システムリセットが管理者の介入に従って行われるまで、実現可能な利用率よりも低くなり得る。
【０００９】
代表的ないくつかの実施形態では、コンピューティングパーティションまたはノード（コンピューティング資源および関連するソフトウェアの区分けされたドメイン）がクラスタ編成に構成される。
各作業負荷管理プロセスは「マスタ」プロセスとして選択されて、その他のノードの作業負荷管理プロセスに応答して資源を各メンバノードに再割り振りする。
【００１０】
クラスタの動作中、「ハートビート」を使用して、マスタ作業負荷管理プロセスが適宜機能していることを通信する。
たとえば、明示的な信号をマスタ作業負荷管理プロセスからその他の各作業負荷管理プロセスに通信することができる。
その他の作業負荷管理プロセスが信号を受け取っている限り、動作は通常通りに続いている。
【００１１】
しかし、信号を受け取らない場合、各非マスタ作業負荷管理プロセスは、マスタプロセスと通信することができないことにより非メンバ状態になる。
一実施形態では、その他のすべてのプロセスが非メンバ状態になると、プロセスは代替マスタプロセスを選び、コンピューティングパーティション間での資源の再割り振りを引き継ぐ。
次いで、選ばれなかったプロセスはメンバ状態になり、新たに選ばれたマスタ作業負荷管理プロセスに応答する。
【００１２】
これより図面を参照して、図１に、代表的な一実施形態による作業負荷管理機能を含むコンピューティングシステム１００を示す。
システム１００は、複数の仮想パーティション１０１−１〜１０１−Ｎまたは他の適したコンピューティング区画を含む。
仮想パーティション１０１は、サーバプラットフォーム資源の保護ドメインである。
サーバプラットフォームの選択されたプロセッサ１０２およびメモリ１０３の特定の部分をパーティション１０１−１〜１０１−Ｎに割り振ることができる。
パーティション１０１は、ネットワークインタフェース１０４および入出力（ＩＯ）インタフェース１０５等の資源を共有することができる。
適したキューイングおよびスケジューリングメカニズム（図示せず）を使用して、例としてネットワークインタフェース１０４およびＩＯインタフェース１０５へのアクセスを割り振ることができる。
代表的な一実施形態について仮想パーティションを使用するものとして説明するが、任意の適したコンピューティング環境を使用して実施形態を実施することができる。
具体的には、割り振る対象となる少なくとも１つの資源を有する任意のコンピュータシステムが、実施形態を参照していずれのソフトウェアプロセスが資源へのアクセスを受け取るのかを判断することができる。
【００１３】
各オペレーティングシステム１０６を実行して、各パーティション１０１内の処理を制御することができる。
各アプリケーション１０７またはアプリケーションセットがパーティション１０１−１〜１０１−Ｎ内で実行される。
アプリケーション１０７は、たとえば、企業エンティティの各種ビジネス単位のビジネスプロセスに対応することができる。
パーティションの使用により、多くの利点が可能になる。
たとえば、ソフトウェアエラーまたは故障が任意のパーティション１０１内で発生した場合、そのパーティション１０１のみが影響を受け、その他のパーティション１０１は中断せずに処理を続ける。
【００１４】
一実施形態では、パーティション１０１−１〜１０１−Ｎ内において、パフォーマンスモニタ１０８がアプリケーション１０７に関連する動作を監視するソフトウェアプロセスである。
たとえば、パフォーマンスモニタ１０８は、選択されたタイプのトランザクションの実行に必要な時間長を調べることができる。
これに加えて、またはこれに代えて、パフォーマンスモニタ１０８は、パーティション１０１−１〜１０１−Ｎに関連するアプリケーション１０７によるプロセッサ、Ｉ／Ｏ周辺機器、ネットワークインタフェース、または他の資源に関連する利用率を監視することができる。
パフォーマンスモニタ１０８によって集められたパフォーマンス測度は、大域的作業負荷マネージャ（ｇＷＬＭ）１０９に通信される。
【００１５】
一実施形態では、ｇＷＬＭ１０９は、パフォーマンス測度を使用し、ポリシーデータ１１０に従って資源をパーティション１０１−１〜１０１−Ｎ内に動的に割り振るソフトウェアプロセスである。
ポリシーデータは、サービスレベル目標（ＳＬＯ）（すなわち、所望の動作目標）を特定することができる。
たとえば、ＳＬＯは、特定のタイプのデータベーストランザクションを完了する所望の時間長が１ミリ秒に等しくなるように指定するように規定することができる。
別法として、ＳＬＯは、資源の利用率が８５％未満に維持されるように規定することができる。
ｇＷＬＭ１０９の１つが、所与のパーティション１０１内の割り振りを通して各ＳＬＯ（複数可）を満たすことができない場合、ｇＷＬＭ１０９は追加資源を得るための要求を通信することができる。
【００１６】
いくつかの代表的な実施形態は、ｇＷＬＭ１０９の中から、マスタ作業負荷プロセスとしてさらに機能する１つを選択する。
マスタ作業負荷管理プロセスは、その他のｇＷＬＭ１０９からの要求を受け取り、パーティション１０１間の資源の割り振りを動的に制御する。
パーティション間の資源の再割り振りはまた、ポリシーデータ１０１により規定されるように行うこともできる。
たとえば、プロセッサまたはプロセッサセットを或るパーティション１０１から外して、別のパーティション１０１に割り当て、ＳＬＯの未達成に対処することができる。
一実施形態では、ＳＬＯは、各層が相対優先度を有するいくつかの目標層を使用して符号化することもできる。
マスタｇＷＬＭ１０９は、現在のパフォーマンスデータから可能な限り最高のＳＬＯ層を実現するようにシステム資源を割り振る。
資源の再割り振りは、アイドル資源の再割り振りおよび／またはより低優先度のアプリケーションからの使用資源の再割り振りを含み得る。
メモリ、記憶資源、ネットワーキング資源、オペレーティングシステム資源等の任意の適した資源をこのようにして割り当てることができる。
【００１７】
パーティション１０１の１つの中で作業負荷プロセスを選択することに加えて、いくつかの代表的な実施形態では、作業負荷プロセスまたは関連するパーティション１０１内の他の任意の関連プロセスが故障した後でも引き続き資源を再割り振りすることができる。
具体的には、いくつかの代表的な実施形態は、マスタ作業負荷管理プロセスの動作を監視する。
各非マスタ管理作業負荷プロセスにより、マスタ作業負荷管理プロセスが動作不能になったことが検出される場合、非マスタ作業負荷管理プロセスは、代替マスタ作業負荷管理プロセスを選択することによって自律的に再編成する。
【００１８】
図２に、代表的な一実施形態による作業負荷管理プロセスに関連する動作のフローチャートを示す。
フローチャートは、コンピュータ実行可能コードまたはソフトウェアを使用して実施することができる。
ステップ２０１において、複数の作業負荷管理プロセスが、複数のコンピューティング区画（たとえば、仮想パーティション）内で実行される。
作業負荷管理プロセスは、割り振りポリシーに従って区画内のアプリケーションへの資源の割り振りを動的に調整する。
資源には、プロセッサ、メモリ、ネットワーキング資源、ＩＯ資源等が含まれ得る。
【００１９】
ステップ２０２において、作業負荷管理プロセスがクラスタに編成され、複数の作業負荷管理プロセスのうちの１つが、マスタプロセスとして選択される。
初期マスタプロセスは、デフォルトに、ランダムに、または任意の適した方法で選択することができる。
クラスタ識別子もこの時点で生成することができる。
マスタプロセスは、各種パーティションへの資源の割り振りを動的に管理する。
たとえば、非マスタ作業負荷管理プロセスは、追加資源要求、パフォーマンスデータ、および／または他の適した情報をマスタ作業負荷プロセスに通信することができる。
これに応答して、マスタ作業負荷管理プロセスは、資源をパーティション間でシフトすることができる。
資源をシフトする判断は、所定のポリシーデータ、現在の作業負荷データ（たとえば、利用率データ）等に従って行うことができる。
【００２０】
ステップ２０３において、マスタ作業負荷管理プロセスの動作が、その他の作業負荷管理プロセスによって監視される。
この目的のために、明示的な信号をマスタ作業負荷プロセスからその他の作業負荷管理プロセスに通信することができる。
別法として、他の目的で使用されるメソッド呼び出しをこの目的のために監視することができる。
たとえば、一実施形態では、マスタ作業負荷プロセスは、その他の作業負荷管理プロセスに関連するメソッドを呼び出して、再割り振り判断に関連するデータを得ることができる。
各メソッド（複数可）が呼び出されない場合、これは、マスタ作業負荷管理プロセスが動作不能になったことを暗示し得る。
別の実施形態では、その他の作業負荷管理プロセスは、マスタ作業負荷管理プロセスに関連するメソッドを周期的に呼び出すことができる。
例外が発生するか、または応答を受け取らない場合、これもまた作業負荷管理プロセスが動作不能になったことを暗示し得る。
【００２１】
ステップ２０４において、論理的な比較が行われ、マスタ作業負荷管理プロセスが動作不能になったか否かが判断される。
たとえば、マスタ作業負荷管理プロセスの関連動作の検出に関連するタイマを保持することができる。
タイマを使用して、一般的なネットワークまたは他のシステムの障害とマスタ作業負荷管理プロセスの故障とを区別することができる。
論理的な比較により、マスタ作業負荷管理プロセスが動作可能であると判断される場合、プロセスの流れはステップ２０３に戻る。
論理的な比較により、マスタ作業負荷管理プロセスが動作不能であると判断される場合、プロセスの流れはステップ２０５に進む。
【００２２】
ステップ２０５において、作業負荷管理プロセスは新しい作業負荷管理プロセスを選択する。
この選択は、所定数またはすべての作業負荷管理プロセスがマスタプロセスの故障を検出した後で行うことができる。
選択プロセスは、残りのプロセスの「選出」を含むことができる。
たとえば、各作業負荷管理プロセスは互いに「投票コール」メッセージを通信して、プロセスが適切な状態に遷移し、代替プロセスを選択する準備が整ったことを保証することができる。
管理プロセスが適切な状態であると判断された後、プロセスは各自の代替プロセス選出を通信することができる。
この選択は、任意の適した、予め定められた方式（たとえば、最も低い識別子を有する作業負荷管理プロセスを選択し得る）に従って行うことができる。
プロセス同士で合意がなされると、プロセスフローはステップ２０６に進む。
【００２３】
ステップ２０６において、選出された作業負荷管理プロセスが、コンピューティング区画間での資源の再割り振りを引き継ぐ。
また、新しいクラスタ識別子をこのステップにおいて生成することができる。
クラスタ識別子を使用して、前の作業負荷管理プロセスが再割り振り動作を行おうとすることを防ぐことができる。
具体的には、前の作業負荷管理プロセスは、一時的なシステム故障により動作不能になった場合もある。
リカバリした後、前の作業負荷管理プロセスは資源を再割り振りしようとする恐れがある。
メソッド呼び出しがパーティション間への資源の再割り振りに使用される場合、クラスタ識別子をメソッドの引数として渡すことができる。
呼び出されたメソッドは、クラスタ識別子を認証して、前のマスタ作業負荷管理プロセスが現在の動作に干渉するのを防ぐことができる。
【００２４】
ステップ２０６から、プロセスはステップ２０３に戻り、さらなる作業負荷管理動作が続けられる。
別の実施形態では、前のマスタ作業負荷管理プロセスのパーティションに関連する動作が再確立される場合、前の管理プロセスは新規のクラスタにメンバ管理プロセスとして再び参加することができる。
【００２５】
いくつかの代表的な実施形態は多くの利点を提供することができる。
具体的には、アプリケーション要求に応答して、資源をコンピューティング区画間に効率的に転送することができる。
さらに、いくつかの代表的な実施形態は、ソフトウェア故障、部分的なネットワーク中断、または他のシステム故障に対して堅牢である。
具体的には、各作業負荷管理プロセスが区画間への資源の割り振りを行うことが可能であるため、代替マスタプロセスを選択することにより、システムリセットを行う必要なく資源を転送することが可能である。
【図面の簡単な説明】
【００２６】
【図１】代表的な一実施形態によるコンピューティングシステムを示す。
【図２】代表的な一実施形態によるフローチャートを示す。
【符号の説明】
【００２７】
１０３・・・メモリ，
１０４・・・ネットワークインタフェース，
１０５・・・ＩＯインタフェース，
１１０・・・ポリシーデータ，
【技術分野】
【０００１】
（関連出願）
本願は、同時係属中であり、本願と同じ譲受人に譲渡された米国特許出願第１０／２０６，５９４号、名称「DYNAMIC MANAGEMENT OF VIRTUAL PARTITION COMPUTER WORKLOADS THROUGH SERVICE LEVEL OPTIMIZATION」、２００２年７月２６日出願に関連する。
【０００２】
本願は、包括的には動作不能なマスタ作業負荷管理プロセスの代替に関する。
【背景技術】
【０００３】
多くの企業が、組織内でのコンピュータ数およびアプリケーション数の劇的な増加を経験した。
企業内のビジネスグループが新規アプリケーションを配備する場合には通常、１つまたは複数の専用サーバプラットフォームが新規アプリケーションをホストするために追加される。
このタイプの環境は、時に「ワンアプリケーションパーボックス（one-app-per-box）」と呼ばれることがある。
デジタル化されるビジネスプロセスが多くなるにつれて、「ワンアプリケーションパーボックス」環境は過度な数のサーバプラットフォームに繋がる。
その結果として、サーバプラットフォームの管理コストが大幅に上昇する。
さらに、サーバプラットフォーム資源が実際に使用される時間の割合（利用率）はかなり低くなり得る。
【０００４】
こういった問題に対処するために、多くの企業は複数のアプリケーションを共通サーバプラットフォームに統合して、プラットフォーム数を削減するとともに、システムの利用率を上げている。
このような統合が行われる場合には、複数のアプリケーション間のプラットフォームの資源の調整が適切である。
たとえば、サポートされるアプリケーションの各種スレッドによるプロセッサ資源へのアクセスを制御するスケジューリングメカニズムを提供することが望ましい。
スケジューリングメカニズムによっては（たとえば、「作業負荷管理」機能）、プロセスのスケジューリングを制御するために分け前、規則、優先度、サービスレベル目標等の一式を提供するものがある。
【０００５】
作業負荷管理の一例には、共有資源ドメインに複数の仮想パーティションを作成することが挙げられる。
各種資源（プロセッサ、メモリ、入出力（Ｉ／Ｏ）資源等）が通常、各仮想パーティションに割り当てられる。
また、各オペレーティングシステムを各仮想パーティション内で実行することができる。
関連するアプリケーションの各グループを各仮想パーティション内で実行することができる。
仮想パーティションの構成は、各仮想パーティションのアプリケーション群間で或る程度の区分けを提供する。
さらに、作業負荷管理プロセスを各仮想パーティション内で実行して、仮想パーティション内の資源へのアクセスを制御することができる。
具体的には、特定の仮想パーティション内で、作業負荷管理プロセスは、仮想パーティションに割り当てられたグループのアプリケーション間でのプロセッサ資源へのアクセスをスケジュールすることができる。
【０００６】
仮想パーティション内の作業負荷管理に加えて、資源を仮想パーティション間に再割り振りすることによって別のレベルの資源管理が行われる。
具体的には、仮想パーティション内の作業負荷管理プロセスにより、サービスレベル目標をアプリケーショングループで満たすことができないと判断される場合、作業負荷管理プロセスは、「大域的」作業負荷管理プロセスからの資源の追加を要求することができる。
規則、分け前、優先度、サービスレベル目標等に基づいて、大域的作業負荷管理プロセスは、別の仮想パーティションから要求を行っているパーティションに資源をシフトすることができる。
たとえば、他のパーティションに過剰資源がある場合、そういった資源を、要求を行っている仮想パーティションに再割り当てすることができる。
作業負荷管理機能の使用により、コンピューティング資源に関連する利用率を向上させることが可能になる。
したがって、作業負荷管理機能により、コンピューティング資源をより効率的に使用することが可能になる。
【発明の開示】
【課題を解決するための手段】
【０００７】
一実施形態において、方法は、複数のコンピューティング区画内の各作業負荷管理プロセスを実行することであって、それによって少なくともプロセッサ資源を複数のコンピューティング区画内で実行されるアプリケーションに割り振る、実行すること、マスタ作業負荷管理プロセスを選択することであって、それにより、作業負荷管理プロセスからの追加資源受け取り要求に応答して、プロセッサ資源を複数のコンピューティング区画に再割り振りする、選択すること、マスタ作業負荷管理プロセスの動作を他の作業負荷管理プロセスにより監視すること、他の作業負荷管理プロセスにより、マスタ作業負荷管理プロセスが動作不能になったときを検出すること、検出することに応答して、他の作業負荷管理プロセスにより代替マスタ作業負荷管理プロセスを選択すること、とを含む。
【発明を実施するための最良の形態】
【０００８】
既知の作業負荷管理機能は、従来技術によるコンピューティング環境と比較して多くの利点を提供するが、既知の作業負荷管理機能にはいくつかの制約がある。
具体的には、大域的作業負荷管理プロセスに影響するシステム故障が発生した場合、仮想パーティション間の資源の共有が停止することになる。
したがって、資源の利用率は、システムリセットが管理者の介入に従って行われるまで、実現可能な利用率よりも低くなり得る。
【０００９】
代表的ないくつかの実施形態では、コンピューティングパーティションまたはノード（コンピューティング資源および関連するソフトウェアの区分けされたドメイン）がクラスタ編成に構成される。
各作業負荷管理プロセスは「マスタ」プロセスとして選択されて、その他のノードの作業負荷管理プロセスに応答して資源を各メンバノードに再割り振りする。
【００１０】
クラスタの動作中、「ハートビート」を使用して、マスタ作業負荷管理プロセスが適宜機能していることを通信する。
たとえば、明示的な信号をマスタ作業負荷管理プロセスからその他の各作業負荷管理プロセスに通信することができる。
その他の作業負荷管理プロセスが信号を受け取っている限り、動作は通常通りに続いている。
【００１１】
しかし、信号を受け取らない場合、各非マスタ作業負荷管理プロセスは、マスタプロセスと通信することができないことにより非メンバ状態になる。
一実施形態では、その他のすべてのプロセスが非メンバ状態になると、プロセスは代替マスタプロセスを選び、コンピューティングパーティション間での資源の再割り振りを引き継ぐ。
次いで、選ばれなかったプロセスはメンバ状態になり、新たに選ばれたマスタ作業負荷管理プロセスに応答する。
【００１２】
これより図面を参照して、図１に、代表的な一実施形態による作業負荷管理機能を含むコンピューティングシステム１００を示す。
システム１００は、複数の仮想パーティション１０１−１〜１０１−Ｎまたは他の適したコンピューティング区画を含む。
仮想パーティション１０１は、サーバプラットフォーム資源の保護ドメインである。
サーバプラットフォームの選択されたプロセッサ１０２およびメモリ１０３の特定の部分をパーティション１０１−１〜１０１−Ｎに割り振ることができる。
パーティション１０１は、ネットワークインタフェース１０４および入出力（ＩＯ）インタフェース１０５等の資源を共有することができる。
適したキューイングおよびスケジューリングメカニズム（図示せず）を使用して、例としてネットワークインタフェース１０４およびＩＯインタフェース１０５へのアクセスを割り振ることができる。
代表的な一実施形態について仮想パーティションを使用するものとして説明するが、任意の適したコンピューティング環境を使用して実施形態を実施することができる。
具体的には、割り振る対象となる少なくとも１つの資源を有する任意のコンピュータシステムが、実施形態を参照していずれのソフトウェアプロセスが資源へのアクセスを受け取るのかを判断することができる。
【００１３】
各オペレーティングシステム１０６を実行して、各パーティション１０１内の処理を制御することができる。
各アプリケーション１０７またはアプリケーションセットがパーティション１０１−１〜１０１−Ｎ内で実行される。
アプリケーション１０７は、たとえば、企業エンティティの各種ビジネス単位のビジネスプロセスに対応することができる。
パーティションの使用により、多くの利点が可能になる。
たとえば、ソフトウェアエラーまたは故障が任意のパーティション１０１内で発生した場合、そのパーティション１０１のみが影響を受け、その他のパーティション１０１は中断せずに処理を続ける。
【００１４】
一実施形態では、パーティション１０１−１〜１０１−Ｎ内において、パフォーマンスモニタ１０８がアプリケーション１０７に関連する動作を監視するソフトウェアプロセスである。
たとえば、パフォーマンスモニタ１０８は、選択されたタイプのトランザクションの実行に必要な時間長を調べることができる。
これに加えて、またはこれに代えて、パフォーマンスモニタ１０８は、パーティション１０１−１〜１０１−Ｎに関連するアプリケーション１０７によるプロセッサ、Ｉ／Ｏ周辺機器、ネットワークインタフェース、または他の資源に関連する利用率を監視することができる。
パフォーマンスモニタ１０８によって集められたパフォーマンス測度は、大域的作業負荷マネージャ（ｇＷＬＭ）１０９に通信される。
【００１５】
一実施形態では、ｇＷＬＭ１０９は、パフォーマンス測度を使用し、ポリシーデータ１１０に従って資源をパーティション１０１−１〜１０１−Ｎ内に動的に割り振るソフトウェアプロセスである。
ポリシーデータは、サービスレベル目標（ＳＬＯ）（すなわち、所望の動作目標）を特定することができる。
たとえば、ＳＬＯは、特定のタイプのデータベーストランザクションを完了する所望の時間長が１ミリ秒に等しくなるように指定するように規定することができる。
別法として、ＳＬＯは、資源の利用率が８５％未満に維持されるように規定することができる。
ｇＷＬＭ１０９の１つが、所与のパーティション１０１内の割り振りを通して各ＳＬＯ（複数可）を満たすことができない場合、ｇＷＬＭ１０９は追加資源を得るための要求を通信することができる。
【００１６】
いくつかの代表的な実施形態は、ｇＷＬＭ１０９の中から、マスタ作業負荷プロセスとしてさらに機能する１つを選択する。
マスタ作業負荷管理プロセスは、その他のｇＷＬＭ１０９からの要求を受け取り、パーティション１０１間の資源の割り振りを動的に制御する。
パーティション間の資源の再割り振りはまた、ポリシーデータ１０１により規定されるように行うこともできる。
たとえば、プロセッサまたはプロセッサセットを或るパーティション１０１から外して、別のパーティション１０１に割り当て、ＳＬＯの未達成に対処することができる。
一実施形態では、ＳＬＯは、各層が相対優先度を有するいくつかの目標層を使用して符号化することもできる。
マスタｇＷＬＭ１０９は、現在のパフォーマンスデータから可能な限り最高のＳＬＯ層を実現するようにシステム資源を割り振る。
資源の再割り振りは、アイドル資源の再割り振りおよび／またはより低優先度のアプリケーションからの使用資源の再割り振りを含み得る。
メモリ、記憶資源、ネットワーキング資源、オペレーティングシステム資源等の任意の適した資源をこのようにして割り当てることができる。
【００１７】
パーティション１０１の１つの中で作業負荷プロセスを選択することに加えて、いくつかの代表的な実施形態では、作業負荷プロセスまたは関連するパーティション１０１内の他の任意の関連プロセスが故障した後でも引き続き資源を再割り振りすることができる。
具体的には、いくつかの代表的な実施形態は、マスタ作業負荷管理プロセスの動作を監視する。
各非マスタ管理作業負荷プロセスにより、マスタ作業負荷管理プロセスが動作不能になったことが検出される場合、非マスタ作業負荷管理プロセスは、代替マスタ作業負荷管理プロセスを選択することによって自律的に再編成する。
【００１８】
図２に、代表的な一実施形態による作業負荷管理プロセスに関連する動作のフローチャートを示す。
フローチャートは、コンピュータ実行可能コードまたはソフトウェアを使用して実施することができる。
ステップ２０１において、複数の作業負荷管理プロセスが、複数のコンピューティング区画（たとえば、仮想パーティション）内で実行される。
作業負荷管理プロセスは、割り振りポリシーに従って区画内のアプリケーションへの資源の割り振りを動的に調整する。
資源には、プロセッサ、メモリ、ネットワーキング資源、ＩＯ資源等が含まれ得る。
【００１９】
ステップ２０２において、作業負荷管理プロセスがクラスタに編成され、複数の作業負荷管理プロセスのうちの１つが、マスタプロセスとして選択される。
初期マスタプロセスは、デフォルトに、ランダムに、または任意の適した方法で選択することができる。
クラスタ識別子もこの時点で生成することができる。
マスタプロセスは、各種パーティションへの資源の割り振りを動的に管理する。
たとえば、非マスタ作業負荷管理プロセスは、追加資源要求、パフォーマンスデータ、および／または他の適した情報をマスタ作業負荷プロセスに通信することができる。
これに応答して、マスタ作業負荷管理プロセスは、資源をパーティション間でシフトすることができる。
資源をシフトする判断は、所定のポリシーデータ、現在の作業負荷データ（たとえば、利用率データ）等に従って行うことができる。
【００２０】
ステップ２０３において、マスタ作業負荷管理プロセスの動作が、その他の作業負荷管理プロセスによって監視される。
この目的のために、明示的な信号をマスタ作業負荷プロセスからその他の作業負荷管理プロセスに通信することができる。
別法として、他の目的で使用されるメソッド呼び出しをこの目的のために監視することができる。
たとえば、一実施形態では、マスタ作業負荷プロセスは、その他の作業負荷管理プロセスに関連するメソッドを呼び出して、再割り振り判断に関連するデータを得ることができる。
各メソッド（複数可）が呼び出されない場合、これは、マスタ作業負荷管理プロセスが動作不能になったことを暗示し得る。
別の実施形態では、その他の作業負荷管理プロセスは、マスタ作業負荷管理プロセスに関連するメソッドを周期的に呼び出すことができる。
例外が発生するか、または応答を受け取らない場合、これもまた作業負荷管理プロセスが動作不能になったことを暗示し得る。
【００２１】
ステップ２０４において、論理的な比較が行われ、マスタ作業負荷管理プロセスが動作不能になったか否かが判断される。
たとえば、マスタ作業負荷管理プロセスの関連動作の検出に関連するタイマを保持することができる。
タイマを使用して、一般的なネットワークまたは他のシステムの障害とマスタ作業負荷管理プロセスの故障とを区別することができる。
論理的な比較により、マスタ作業負荷管理プロセスが動作可能であると判断される場合、プロセスの流れはステップ２０３に戻る。
論理的な比較により、マスタ作業負荷管理プロセスが動作不能であると判断される場合、プロセスの流れはステップ２０５に進む。
【００２２】
ステップ２０５において、作業負荷管理プロセスは新しい作業負荷管理プロセスを選択する。
この選択は、所定数またはすべての作業負荷管理プロセスがマスタプロセスの故障を検出した後で行うことができる。
選択プロセスは、残りのプロセスの「選出」を含むことができる。
たとえば、各作業負荷管理プロセスは互いに「投票コール」メッセージを通信して、プロセスが適切な状態に遷移し、代替プロセスを選択する準備が整ったことを保証することができる。
管理プロセスが適切な状態であると判断された後、プロセスは各自の代替プロセス選出を通信することができる。
この選択は、任意の適した、予め定められた方式（たとえば、最も低い識別子を有する作業負荷管理プロセスを選択し得る）に従って行うことができる。
プロセス同士で合意がなされると、プロセスフローはステップ２０６に進む。
【００２３】
ステップ２０６において、選出された作業負荷管理プロセスが、コンピューティング区画間での資源の再割り振りを引き継ぐ。
また、新しいクラスタ識別子をこのステップにおいて生成することができる。
クラスタ識別子を使用して、前の作業負荷管理プロセスが再割り振り動作を行おうとすることを防ぐことができる。
具体的には、前の作業負荷管理プロセスは、一時的なシステム故障により動作不能になった場合もある。
リカバリした後、前の作業負荷管理プロセスは資源を再割り振りしようとする恐れがある。
メソッド呼び出しがパーティション間への資源の再割り振りに使用される場合、クラスタ識別子をメソッドの引数として渡すことができる。
呼び出されたメソッドは、クラスタ識別子を認証して、前のマスタ作業負荷管理プロセスが現在の動作に干渉するのを防ぐことができる。
【００２４】
ステップ２０６から、プロセスはステップ２０３に戻り、さらなる作業負荷管理動作が続けられる。
別の実施形態では、前のマスタ作業負荷管理プロセスのパーティションに関連する動作が再確立される場合、前の管理プロセスは新規のクラスタにメンバ管理プロセスとして再び参加することができる。
【００２５】
いくつかの代表的な実施形態は多くの利点を提供することができる。
具体的には、アプリケーション要求に応答して、資源をコンピューティング区画間に効率的に転送することができる。
さらに、いくつかの代表的な実施形態は、ソフトウェア故障、部分的なネットワーク中断、または他のシステム故障に対して堅牢である。
具体的には、各作業負荷管理プロセスが区画間への資源の割り振りを行うことが可能であるため、代替マスタプロセスを選択することにより、システムリセットを行う必要なく資源を転送することが可能である。
【図面の簡単な説明】
【００２６】
【図１】代表的な一実施形態によるコンピューティングシステムを示す。
【図２】代表的な一実施形態によるフローチャートを示す。
【符号の説明】
【００２７】
１０３・・・メモリ，
１０４・・・ネットワークインタフェース，
１０５・・・ＩＯインタフェース，
１１０・・・ポリシーデータ，
【特許請求の範囲】
【請求項１】
複数のコンピューティング区画内の各作業負荷管理プロセスを実行すること（２０１）であって、それによって少なくともプロセッサ資源を前記複数のコンピューティング区画内で実行されるアプリケーションに割り振ることと、
マスタ作業負荷管理プロセスを選択することであって、それにより、前記作業負荷管理プロセスからの追加資源受け取り要求に応答して、プロセッサ資源を前記複数のコンピューティング区画に再割り振りすることと、
前記マスタ作業負荷管理プロセスの動作を他の作業負荷管理プロセスにより監視すること（２０３）と、
前記他の作業負荷管理プロセスにより、前記マスタ作業負荷管理プロセスが動作不能になったときを検出すること（２０４）と、
該検出することに応答して、前記他の作業負荷管理プロセスにより代替マスタ作業負荷管理プロセスを選択すること（２０５）と
を含む方法。
【請求項２】
前記監視することは、
前記マスタ作業負荷管理プロセスが前記他の作業負荷管理プロセスにメソッド呼び出しを行うか否かを判断すること
を含む
請求項１に記載の方法。
【請求項３】
前記メソッド呼び出しは、前記マスタ作業負荷管理プロセスが行うべき再割り振り判断に関連する情報を得るためのメソッド呼び出しである
請求項２に記載の方法。
【請求項４】
前記監視することは、
前記マスタ作業負荷管理プロセスがメソッド呼び出しへの応答に失敗するか否かを判断すること
を含む
請求項１に記載の方法。
【請求項５】
前記マスタ作業負荷管理プロセスの最後に検出された動作に関連するタイマを作動させること
をさらに含む請求項１に記載の方法。
【請求項６】
前記他の作業負荷管理プロセスのそれぞれは、前記検出することに応答して非メンバ状態に遷移する
請求項１に記載の方法。
【請求項７】
前記他の作業負荷管理プロセスのそれぞれは互いに通信して、該他の作業負荷管理プロセスのそれぞれが、前記代替を選択することを行う前に前記非メンバ状態になったか否かを判断する
請求項６に記載の方法。
【請求項８】
前記前のマスタ作業負荷管理プロセスの動作を再確立することと、
前記代替を選択することが行われた後、前記前のマスタ作業負荷管理プロセスが処理資源の再割り振りに関連する動作を行おうとするときに例外を発生させることと、
前記前のマスタ作業負荷管理プロセスが、前記他の作業負荷管理プロセスにメンバプロセスとして加わることと
をさらに含む請求項１に記載の方法。
【請求項９】
現在のマスタ作業負荷管理プロセスを識別する識別子を生成すること
をさらに含む請求項１に記載の方法。
【請求項１０】
前記現在のマスタ作業負荷管理プロセスは、前記複数のコンピューティング区画間に資源の割り振りを行うメソッドに前記識別子を渡す
請求項９に記載の方法。
【請求項１】
複数のコンピューティング区画内の各作業負荷管理プロセスを実行すること（２０１）であって、それによって少なくともプロセッサ資源を前記複数のコンピューティング区画内で実行されるアプリケーションに割り振ることと、
マスタ作業負荷管理プロセスを選択することであって、それにより、前記作業負荷管理プロセスからの追加資源受け取り要求に応答して、プロセッサ資源を前記複数のコンピューティング区画に再割り振りすることと、
前記マスタ作業負荷管理プロセスの動作を他の作業負荷管理プロセスにより監視すること（２０３）と、
前記他の作業負荷管理プロセスにより、前記マスタ作業負荷管理プロセスが動作不能になったときを検出すること（２０４）と、
該検出することに応答して、前記他の作業負荷管理プロセスにより代替マスタ作業負荷管理プロセスを選択すること（２０５）と
を含む方法。
【請求項２】
前記監視することは、
前記マスタ作業負荷管理プロセスが前記他の作業負荷管理プロセスにメソッド呼び出しを行うか否かを判断すること
を含む
請求項１に記載の方法。
【請求項３】
前記メソッド呼び出しは、前記マスタ作業負荷管理プロセスが行うべき再割り振り判断に関連する情報を得るためのメソッド呼び出しである
請求項２に記載の方法。
【請求項４】
前記監視することは、
前記マスタ作業負荷管理プロセスがメソッド呼び出しへの応答に失敗するか否かを判断すること
を含む
請求項１に記載の方法。
【請求項５】
前記マスタ作業負荷管理プロセスの最後に検出された動作に関連するタイマを作動させること
をさらに含む請求項１に記載の方法。
【請求項６】
前記他の作業負荷管理プロセスのそれぞれは、前記検出することに応答して非メンバ状態に遷移する
請求項１に記載の方法。
【請求項７】
前記他の作業負荷管理プロセスのそれぞれは互いに通信して、該他の作業負荷管理プロセスのそれぞれが、前記代替を選択することを行う前に前記非メンバ状態になったか否かを判断する
請求項６に記載の方法。
【請求項８】
前記前のマスタ作業負荷管理プロセスの動作を再確立することと、
前記代替を選択することが行われた後、前記前のマスタ作業負荷管理プロセスが処理資源の再割り振りに関連する動作を行おうとするときに例外を発生させることと、
前記前のマスタ作業負荷管理プロセスが、前記他の作業負荷管理プロセスにメンバプロセスとして加わることと
をさらに含む請求項１に記載の方法。
【請求項９】
現在のマスタ作業負荷管理プロセスを識別する識別子を生成すること
をさらに含む請求項１に記載の方法。
【請求項１０】
前記現在のマスタ作業負荷管理プロセスは、前記複数のコンピューティング区画間に資源の割り振りを行うメソッドに前記識別子を渡す
請求項９に記載の方法。
【図１】
【図２】
【図２】
【公開番号】特開２００６−１７８９６９（Ｐ２００６−１７８９６９Ａ）
【公開日】平成１８年７月６日（２００６．７．６）
【国際特許分類】
【出願番号】特願２００５−３６１７６４（Ｐ２００５−３６１７６４）
【出願日】平成１７年１２月１５日（２００５．１２．１５）
【出願人】（５０３００３８５４）ヒューレット−パッカード デベロップメント カンパニー エル．ピー． (1,145)
【Ｆターム（参考）】
【公開日】平成１８年７月６日（２００６．７．６）
【国際特許分類】
【出願日】平成１７年１２月１５日（２００５．１２．１５）
【出願人】（５０３００３８５４）ヒューレット−パッカード デベロップメント カンパニー エル．ピー． (1,145)
【Ｆターム（参考）】
[ Back to top ]