JP2006164281A - 自動リソース管理のための利用率ゾーン - Google Patents

Abstract

【課題】 論理的に区分された環境においてリソースを自動的に監視および割り当てるためのクライアント／サーバ・モデルを提供すること。
【解決手段】 各区画には、その区画のリソース利用率を監視するクライアント・アプリケーションが含まれる。クライアント・アプリケーションはリソース利用率メトリクスを収集し、定期的にリソース状況通知をサーバ・アプリケーションに送る。サーバ・アプリケーションは、区画または外部ワークステーションのいずれかで動作する。サーバ・アプリケーションはクライアントからのリソース状況通知を待ち、これらの通知に基づいて区画を利用率ゾーンにカテゴリ化する。その後サーバは、低利用率ゾーンにある区画からのリソースを高利用率ゾーンにある区画に再割り当てする。
【選択図】 図３

Description

本発明はデータ処理に関し、特に論理的に区分されたデータ処理システムに関する。さらにとりわけ本発明は、利用率ゾーンを介して論理的に区分されたデータ処理システムにおける自動リソース管理のための方法、装置、およびプログラムを提供する。

大規模な対称型マルチプロセッサ・データ処理システムを区分し、複数のより小規模なシステムとして使用することが可能である。こうしたシステムの例には、インターナショナル・ビジネス・マシンズ・コーポレーションから市販されているＩＢＭ ｅＳｅｒｖｅｒ（登録商標）Ｐ６９０、Ｈｅｗｌｅｔｔ−Ｐａｃｋａｒｄ Ｃｏｍｐａｎｙから市販されているＤＨＰ９０００ Ｓｕｐｅｒｄｏｍｅ Ｅｎｔｅｒｐｒｉｓｅ Ｓｅｒｖｅｒ、およびＳｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃから市販されているＳｕｎ Ｆｉｒｅ（登録商標）１５Ｋサーバが含まれる。これらのシステムは、しばしば論理区分（ＬＰＡＲ）データ処理システムと呼ばれる。データ処理システム内の論理区分機能は、単一のオペレーティング・システムの複数のコピーまたは複数の異機種オペレーティング・システムを、単一のデータ処理システム・プラットフォーム上で同時に実行させることができる。オペレーティング・システム・イメージがその中で実行される区画には、プラットフォームの物理リソースの重複しないサブセットが割り当てられる。これらのプラットフォーム配分可能リソースには、割り込み管理域、システム・メモリ領域、および入力／出力（Ｉ／Ｏ）アダプタ・バス・スロットを備えた、１つまたは複数の構造的に別個のプロセッサが含まれる。区画のリソースは、プラットフォームのファームウェアによってオペレーティング・システム・イメージに対して表される。

それぞれ別個のオペレーティング・システムまたはプラットフォーム内で実行中のオペレーティング・システムのイメージは互いに保護されるため、１つの論理区画上でのソフトウェア・エラーが他のいずれの区画の正しいオペレーションにも影響を与えることはない。この保護は、各オペレーティング・システム・イメージによって直接管理されることになるプラットフォーム・リソースの互いに素な集合（ｄｉｓｊｏｉｎｔｅｄ ｓｅｔ）を割り振ることによって、および様々なイメージがそのイメージに割り振られていないいずれのリソースをも制御できないことを保証するためのメカニズムを提供することによって、提供される。さらに、オペレーティング・システムの割り振り済みリソースの制御におけるソフトウェア・エラーは、他のいずれのイメージのリソースにも影響を与えない。したがって、オペレーティング・システムのそれぞれのイメージまたはそれぞれの異なるオペレーティング・システムは、プラットフォーム内の配分可能リソースの別個の集合を直接制御する。

しばしばＬＰＡＲでは、データ処理システム・リソースが十分利用されていないかまたは過剰に利用されている。リソースの利用率を監視し、最適な利用率を提供するためにそれに応じてリソースを割り当てるには、手作業による常時管理が必要である。たとえば、ある区画が利用率１００％で１つの中央処理ユニット（ＣＰＵ）を使用して動作している場合がある。他のＣＰＵをこの区画に割り振ることによって、管理者は作業負荷を緩和するために追加のリソースを提供することができる。

しかしながら、追加のリソースをどこで入手するかも問題となる場合がある。現在すべてのリソースが他の区画に割り当てられている場合、どこからリソースを入手するか、およびそれらをどこへ割り当てるかを決めなければならない。したがって、システム管理者は各区画にログインして利用率を記録した後、利用率の統計を他のそれぞれの区画と比較しなければならない。この手作業のプロセスには時間と費用がかかる。

本発明の目的は、従来技術の欠点を認識し、論理的に区分された環境においてリソースを自動的に監視および割り当てるためのクライアント／サーバ・モデルを提供することである。

各区画には、その区画のリソース利用率を監視するクライアント・アプリケーションが含まれる。クライアント・アプリケーションはリソース利用率メトリクスを収集し、定期的にリソース状況通知をサーバ・アプリケーションに送る。サーバ・アプリケーションは、区画または外部ワークステーションのいずれかで動作する。サーバ・アプリケーションはクライアントからのリソース状況通知を待ち、これらの通知に基づいて区画を利用率ゾーンにカテゴリ化する。その後サーバは、低利用率ゾーンにある区画からのリソースを高利用率ゾーンにある区画に再割り当てする。

本発明の特徴と考えられる新規な機能は、添付の特許請求の範囲に示されている。しかしながら本発明それ自体、ならびにその好ましい使用モード、他の目的、および利点は、例示的な実施形態の以下の詳細な説明を添付の図面と共に参照することによって最もよく理解されるであろう。

本発明は、利用率ゾーンを介して論理的に区分されたデータ処理システムにおける自動リソース管理のための方法、装置、およびプログラムを提供する。データ処理デバイスは、スタンドアロン型コンピューティング・デバイスとするか、または本発明の様々な態様を実行するために複数のコンピューティング・デバイスが利用される分散型データ処理システムとすることができる。したがって、以下の図１および２は本発明が実施可能なデータ処理環境の例示的な図として提供される。図１および２は単なる例であって、本発明が実施可能な環境に関していかなる制限をも断言または示唆する意図のないことを理解されたい。記載された環境に対する多くの修正が、本発明の趣旨および範囲を逸脱することなく実行可能である。

次に図面、特に図１を参照すると、本発明が実施可能なデータ処理システムのブロック図が示されている。データ処理システム１００は、システム・バス１０６に接続された複数のプロセッサ１０１、１０２、１０３、および１０４を含む対称型マルチプロセッサ（ＳＭＰ）とすることができる。たとえばデータ処理システム１００は、ネットワーク内のサーバとして実装される、ニューヨーク州アーモンクのインターナショナル・ビジネス・マシンズ・コーポレーションの製品であるＩＢＭ ｅＳｅｒｖｅｒ（登録商標）システムとすることができる。さらにシステム・バス１０６には、複数のローカル・メモリ１６０〜１６３へのインターフェースを提供するメモリ・コントローラ／キャッシュ１０８も接続される。Ｉ／Ｏバス・ブリッジ１１０がシステム・バス１０６に接続され、Ｉ／Ｏバス１１２へのインターフェースを提供する。メモリ・コントローラ／キャッシュ１０８およびＩ／Ｏバス・ブリッジ１１０は、図に示されるように一体型とすることができる。

データ処理システム１００は論理区分（ＬＰＡＲ）データ処理システムである。したがってデータ処理システム１００は、同時に実行される複数の異機種のオペレーティング・システム（または単一のオペレーティング・システムの複数のインスタンス）を有することができる。これら複数のオペレーティング・システムは、それぞれがその中で実行される任意数のソフトウェア・プログラムを有することができる。データ処理システム１００は論理的に区分されているため、様々なＰＣＩ Ｉ／Ｏアダプタ１２０〜１２１、１２８〜１２９、および１３６、グラフィックス・アダプタ１４８、ならびにハード・ディスク・アダプタ１４９を様々な論理区画に割り当てることができる。このケースでは、グラフィックス・アダプタ１４８はディスプレイ・デバイス（図示せず）用の接続を提供し、ハード・ディスク・アダプタ１４９はハード・ディスク１５０を制御するための接続を提供する。

したがって、たとえばデータ処理システム１００が３つの論理区画Ｐ１、Ｐ２、およびＰ３に分けられるものと想定する。この３つの区画のうちの１つに、ＰＣＩ Ｉ／Ｏアダプタ１２０〜１２１、１２８〜１２９、１３６、グラフィックス・アダプタ１４８、ハード・ディスク・アダプタ１４９のそれぞれ、ホスト・プロセッサ１０１〜１０４のそれぞれ、およびローカル・メモリ１６０〜１６３からのメモリが割り当てられる。これらの例では、メモリ１６０〜１６３はデュアル・インライン・メモリ・モジュール（ＤＩＭＭ）の形を取ることができる。通常、ＤＩＭＭはＤＩＭＭごとに区画に割り当てられない。その代わりに、区画にはプラットフォームによって見られるメモリ全体のうちの一部が与えられることになる。たとえば、プロセッサ１０１、ローカル・メモリ１６０〜１６３からのメモリの何らかの部分、ならびにＩ／Ｏアダプタ１２０、１２８、および１２９を論理区画１に割り当て、プロセッサ１０２〜１０３、ローカル・メモリ１６０〜１６３からのメモリの何らかの部分、ならびにＰＣＩ Ｉ／Ｏアダプタ１２１および１３６を論理区画２に割り当て、プロセッサ１０４、ローカル・メモリ１６０〜１６３からのメモリの何らかの部分、グラフィックス・アダプタ１４８、ならびにハード・ディスク・アダプタ１４９を論理区画３に割り当てることができる。

データ処理システム１００内で実行中の各オペレーティング・システムは、異なる論理区画に割り当てられる。したがって、データ処理システム１００内で実行中の各オペレーティング・システムは、その論理区画内にあるＩ／Ｏユニットにしかアクセスできない。したがって、たとえばＡｄｖａｎｃｅｄ Ｉｎｔｅｒａｃｔｉｖｅ Ｅｘｅｃｕｔｉｖｅ（ＡＩＸ（登録商標））オペレーティング・システムの第１のインスタンスが区画Ｐ１内で実行し、ＡＩＸ（登録商標）オペレーティング・システムの第２のインスタンス（イメージ）が区画Ｐ２内で実行し、Ｗｉｎｄｏｗｓ ＸＰ（登録商標）オペレーティング・システムが論理区画Ｐ３内で動作することが可能である。Ｗｉｎｄｏｗｓ ＸＰ（登録商標）はワシントン州レドモンドのＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎの製品および商標である。

Ｉ／Ｏバス１１２に接続されたＰｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）ホスト・ブリッジ１１４は、ＰＣＩローカル・バス１１５へのインターフェースを提供する。いくつかのＰＣＩ入力／出力アダプタ１２０〜１２１を、ＰＣＩ対ＰＣＩブリッジ１１６、ＰＣＩバス１１８、ＰＣＩバス１１９、Ｉ／Ｏスロット１７０、およびＩ／Ｏスロット１７１を介してＰＣＩバス１１５に接続することができる。ＰＣＩ対ＰＣＩブリッジ１１６は、ＰＣＩバス１１８およびＰＣＩバス１１９へのインターフェースを提供する。ＰＣＩ Ｉ／Ｏアダプタ１２０および１２１は、それぞれＩ／Ｏスロット１７０および１７１内に配置される。典型的なＰＣＩバスのインプリメンテーションでは、４つから８つまでのＩ／Ｏアダプタ（すなわち、アドイン・コネクタ用の拡張スロット）をサポートする。各ＰＣＩ Ｉ／Ｏアダプタ１２０〜１２１は、データ処理システム１００と、たとえばデータ処理システム１００に対するクライアントである他のネットワーク・コンピュータなどの入力／出力デバイスとの間に、インターフェースを提供する。

追加のＰＣＩホスト・ブリッジ１２２は、追加のＰＣＩバス１２３用のインターフェースを提供する。ＰＣＩバス１２３は複数のＰＣＩ Ｉ／Ｏアダプタ１２８〜１２９に接続される。ＰＣＩ Ｉ／Ｏアダプタ１２８〜１２９は、ＰＣＩ対ＰＣＩブリッジ１２４、ＰＣＩバス１２６、ＰＣＩバス１２７、Ｉ／Ｏスロット１７２、およびＩ／Ｏスロット１７３を介して、ＰＣＩバス１２３に接続することができる。ＰＣＩ対ＰＣＩブリッジ１２４はＰＣＩバス１２６およびＰＣＩバス１２７へのインターフェースを提供する。ＰＣＩ Ｉ／Ｏアダプタ１２８および１２９は、それぞれＩ／Ｏスロット１７２および１７３内に配置される。この形では、たとえばモデムまたはネットワーク・アダプタなどの追加のＩ／Ｏデバイスを、各ＰＣＩ Ｉ／Ｏアダプタ１２８〜１２９を介してサポートすることができる。この形では、データ処理システム１００を複数のネットワーク・コンピュータに接続することができる。

Ｉ／Ｏスロット１７４に挿入されたメモリ・マップ・グラフィックス・アダプタ１４８を、ＰＣＩバス１４４、ＰＣＩ対ＰＣＩブリッジ１４２、ＰＣＩバス１４１、およびＰＣＩホスト・ブリッジを介してＩ／Ｏバス１１２に接続することができる。ハード・ディスク・アダプタ１４９は、ＰＣＩバス１４５に接続されるＩ／Ｏスロット１７５内に配置することができる。次にこのバスがＰＣＩ対ＰＣＩブリッジ１４２に接続され、ＰＣＩバス１４１によってＰＣＩホスト・ブリッジ１４０に接続される。

ＰＣＩホスト・ブリッジ１３０は、Ｉ／Ｏバス１１２に接続するためのインターフェースをＰＣＩバス１３１に提供する。ＰＣＩ Ｉ／Ｏアダプタ１３６はＩ／Ｏスロット１７６に接続され、これがＰＣＩバス１３３によってＰＣＩ対ＰＣＩブリッジ１３２に接続される。ＰＣＩ対ＰＣＩブリッジ１３２はＰＣＩバス１３１に接続される。このＰＣＩバスは、ＰＣＩホスト・ブリッジ１３０をサービス・プロセッサ・メールボックス・インターフェースおよびＩＳＡバス・アクセス・パススルー論理１９４ならびにＰＣＩ対ＰＣＩバス１３２にも接続する。サービス・プロセッサ・メールボックス・インターフェースおよびＩＳＡバス・アクセス・パススルー論理１９４は、ＰＣＩ／ＩＳＡブリッジ１９３宛のＰＣＩアクセスを転送する。ＮＶＲＡＭストレージ１９２はＩＳＡバス１９６に接続される。サービス・プロセッサ１３５は、そのローカルＰＣＩバス１９５を介してサービス・プロセッサ・メールボックス・インターフェースおよびＩＳＡバス・アクセス・パススルー論理１９４に結合される。サービス・プロセッサ１３５は、複数のＪＴＡＧ／Ｉ^２Ｃバス１３４を介して、プロセッサ１０１〜１０４にも接続される。ＪＴＡＧ／Ｉ^２Ｃバス１３４は、ＪＴＡＧ／スキャン・バス（ＩＥＥＥ １１４９．１を参照のこと）およびＰｈｉｌｌｉｐｓ Ｉ^２Ｃバスの組み合わせである。しかしながら別の方法として、ＪＴＡＧ／Ｉ^２Ｃバス１３４をＰｈｉｌｌｉｐｓ Ｉ^２Ｃバスのみ、またはＪＴＡＧ／スキャン・バスのみに置き換えることも可能である。ホスト・プロセッサ１０１、１０２、１０３、および１０４のすべてのＳＰ−ＡＴＴＮ信号は、サービス・プロセッサの割り込み入力信号にまとめて接続される。サービス・プロセッサ１３５はそれ自体のローカル・メモリ１９１を有し、ハードウェアＯＰパネル１９０へのアクセスを有する。

データ処理システム１００に最初に電源が投入された際、サービス・プロセッサ１３５はＪＴＡＧ／Ｉ^２Ｃバス１３４を使用してシステム（ホスト）プロセッサ１０１〜１０４、メモリ・コントローラ／キャッシュ１０８、およびＩ／Ｏブリッジ１１０に問い合わせる。このステップが完了すると、サービス・プロセッサ１３５はデータ処理システム１００のインベントリおよびトポロジを理解する。サービス・プロセッサ１３５は、ホスト・プロセッサ１０１〜１０４、メモリ・コントローラ／キャッシュ１０８、およびＩ／Ｏブリッジ１１０に問い合わせることによって見つけられたすべての要素に対して、組み込み自己テスト（ＢＩＳＴ）、基本検証テスト（ＢＡＴ）、およびメモリ・テストも実行する。ＢＩＳＴ、ＢＡＴ、およびメモリ・テスト時に検出された障害に関するエラー情報があれば、サービス・プロセッサ１３５によって収集および報告される。

ＢＩＳＴ、ＢＡＴ、およびメモリ・テスト時に障害があることが見つけられた要素を取り除いた後に、依然としてシステム・リソースの有意／有効な構成が可能である場合、データ処理システム１００はローカル（ホスト）メモリ１６０〜１６３への実行可能コードのロードを続行することができる。次にサービス・プロセッサ１３５は、ローカル・メモリ１６０〜１６３にロードされたコードを実行するために、ホスト・プロセッサ１０１〜１０４を解放する。ホスト・プロセッサ１０１〜１０４がデータ処理システム１００内のそれぞれのオペレーティング・システムからのコードを実行している間、サービス・プロセッサ１３５はエラーの監視および報告モードに入る。サービス・プロセッサ１３５によって監視される項目のタイプには、たとえば冷却ファンの速度および動作、温度センサ、電源レギュレータ、ならびに、プロセッサ１０１〜１０４、ローカル・メモリ１６０〜１６３、およびＩ／Ｏブリッジ１１０によって報告された回復可能および回復不能なエラーが含まれる。

サービス・プロセッサ１３５は、データ処理システム１００内で監視されるすべての項目に関するエラー情報を保存および報告する責務を負う。サービス・プロセッサ１３５は、エラーのタイプおよび定義されたしきい値に基づいて対応策も講じる。たとえばサービス・プロセッサ１３５は、プロセッサのキャッシュ・メモリ上での過剰な回復可能エラーに気付き、これがハードの障害の前兆であると判断することができる。この判断に基づいて、サービス・プロセッサ１３５は、現在実行中のセッションおよび将来の初期プログラム・ロード（ＩＰＬ）時に構成解除の対象としてそのリソースをマークすることができる。ＩＰＬは、時に「ブート」または「ブートストラップ」とも呼ばれる。

データ処理システム１００は、市販されている様々なコンピュータ・システムを使用してインプリメントすることができる。たとえばデータ処理システム１００は、インターナショナル・ビジネス・マシンズ・コーポレーションから市販されているＩＢＭ ｅＳｅｒｖｅｒ（登録商標）ｉＳｅｒｉｅｓ（登録商標）Ｍｏｄｅｌ８４０システムを使用してインプリメント可能である。こうしたシステムは、同じくインターナショナル・ビジネス・マシンズ・コーポレーションから市販されているＯＳ／４００（登録商標）を使用した論理区画化をサポートすることができる。

当業者であれば、図１に示されたハードウェアが変更可能であることを理解されよう。たとえば、示されたハードウェアに加えて、またはこれに代えて、光ディスク・ドライブなどの他の周辺デバイスも使用することができる。示された例は、本発明に関して構造上の制限を示唆することを意味するものではない。

次に図２を参照すると、本発明が実施可能な例示的な論理区分プラットフォームのブロック図が示されている。論理区分プラットフォーム２００内のハードウェアは、たとえば図１のデータ処理システム１００としてインプリメントすることができる。論理区分プラットフォーム２００には、区分ハードウェア２３０、オペレーティング・システム２０２、２０４、２０６、２０８、およびハイパーバイザ２１０が含まれる。オペレーティング・システム２０２、２０４、２０６、および２０８は、プラットフォーム２００上で同時に実行中の、単一のオペレーティング・システムの複数のコピーまたは複数の異機種のオペレーティング・システムとすることができる。これらのオペレーティング・システムは、ＯＳ／４００（登録商標）オペレーティング・システムを使用してインプリメント可能であり、ハイパーバイザとインターフェースするように設計される。オペレーティング・システム２０２、２０４、２０６、および２０８は、それぞれ区画２０３、２０５、２０７、および２０９内に配置される。

さらに、これらの区画にはファームウェア・ローダ２１１、２１３、２１５、および２１７も含まれる。ファームウェア・ローダ２１１、２１３、２１５、および２１７は、たとえばインターナショナル・ビジネス・マシンズ・コーポレーションから市販されているＩＥＥＥ−１２７５ Ｓｔａｎｄａｒｄ Ｏｐｅｎ Ｆｉｒｍｗａｒｅおよびランタイム分離ソフトウェア（ＲＴＡＳ）を使用してインプリメント可能である。区画２０３、２０５、２０７、および２０９がインスタンス化された場合、ハイパーバイザの区画マネージャはオープン・ファームウェアのコピーを各区画にロードする。その後、区画に関連付けまたは割り当てられたプロセッサが、区画ファームウェアを実行するために区画のメモリにディスパッチされる。

区分ハードウェア２３０は、複数のプロセッサ２３２〜２３８、複数のシステム・メモリ・ユニット２４０〜２４６、複数の入力／出力（Ｉ／Ｏ）アダプタ２４８〜２６２、およびストレージ・ユニット２７０を含む。区分ハードウェア２３０は、区画内のエラー処理などの様々なサービスを提供するために使用可能なサービス・プロセッサ２９０も含む。プロセッサ２３２〜２３８、メモリ・ユニット２４０〜２４６、ＮＶＲＡＭストレージ２９８、およびＩ／Ｏアダプタ２４８〜２６２のそれぞれを、論理区分プラットフォーム２００内の複数の区画のうちの１つに割り当てることが可能であり、そのそれぞれがオペレーティング・システム２０２、２０４、２０６、および２０８のうちの１つに対応する。

ハイパーバイザ・ファームウェア２１０は、論理区分プラットフォーム２００の区画化を作成および強制するために、区画２０３、２０５、２０７、および２０９に対していくつかの機能およびサービスを実行する。ハイパーバイザ２１０は、基礎となるハードウェアと同一のファームウェア実施仮想マシンである。ハイパーバイザ・ソフトウェアはインターナショナル・ビジネス・マシンズ・コーポレーションから市販されている。ファームウェアとは、たとえば読み取り専用メモリ（ＲＯＭ）、プログラマブルＲＯＭ（ＰＲＯＭ）、消去可能プログラマブルＲＯＭ（ＥＰＲＯＭ）、電気的消去可能プログラマブルＲＯＭ（ＥＥＰＲＯＭ）、および不揮発性ランダム・アクセス・メモリ（不揮発性ＲＡＭ）などの電力なしでそのコンテンツを保持するメモリ・チップに格納される「ソフトウェア」である。したがってハイパーバイザ２１０は、論理区分プラットフォーム２００のすべてのハードウェア・リソースを仮想化することによって、独立したＯＳイメージ２０２、２０４、２０６、および２０８を同時に実行させることができる。

様々な区画のオペレーションは、ハードウェア管理コンソール２８０などのハードウェア管理コンソールを介して制御することができる。ハードウェア管理コンソール２８０は独立したデータ処理システムであり、システム管理者は様々な区画へのリソースの再割り振りを含む様々な機能をここから実行することができる。

しばしばＬＰＡＲでは、データ処理システム・リソースが十分利用されていないかまたは過剰に利用されている。リソースの利用率を監視し、最適な利用率を提供するためにそれに応じてリソースを割り当てるには、手作業による常時管理が必要である。たとえば、区画２０３が利用率１００％でプロセッサ２３２のみを使用して動作している場合がある。他のプロセッサをこの区画に割り振ることによって、管理者は作業負荷を緩和するために追加のリソースを提供することができる。

しかしながら、追加のリソースをどこで入手するかも問題となる場合がある。現在すべてのリソースが他の区画に割り当てられている場合、どこからリソースを入手するか、およびそれらをどこへ割り当てるかを決めなければならない。したがって、システム管理者は各区画にログインして利用率を記録した後、利用率の統計を他のそれぞれの区画と比較しなければならない。この手作業のプロセスには時間と費用がかかる。

本発明は、論理的に区分された環境においてリソースを自動的に監視および割り当てるためのクライアント／サーバ・モデルを提供する。各区画には、その区画のリソース利用率を監視するクライアント・アプリケーションが含まれる。クライアント・アプリケーションはリソース利用率メトリクスを収集し、定期的にリソース状況通知をサーバ・アプリケーションに送る。サーバ・アプリケーションは、区画または外部ワークステーションのいずれかで動作する。サーバ・アプリケーションはクライアントからのリソース状況通知を待ち、これらの通知に基づいて区画を利用率ゾーンにカテゴリ化する。その後サーバは、低利用率ゾーンにある区画からのリソースを高利用率ゾーンにある区画に再割り当てする。

図３は、本発明の例示的実施形態に従った、論理的に区分されたデータ処理システム内での動的なリソース管理システムを示すブロック図である。ハイパーバイザ３６０は、論理区画３１０、３２０、３３０、および３４０のすべてのハードウェア・リソースを仮想化することにより、独立したＯＳイメージの同時実行を可能にする。監視クライアント３１２、３２２、３３２、３４２は、それぞれ区画３１０、３２０、３３０、および３４０上で動作する。サーバ３５０は、区画３１０、３２０、３３０、３４０、データ処理システム内の他の区画（図示せず）、または図２のハードウェア・システム・コンソール２８０などの外部端末のうちの１つで動作することができる。

サーバ・アプリケーション３５０は、システム管理者として動作する。ポリシー・ファイル３５２は、監視する区画および区画に適用されることになる利用率ゾーンのしきい値を記述する。これらのしきい値がリソース使用の状態を決定する。通信セッションはそれぞれの区画と確立される。サーバ３５０および監視クライアント３１２、３２２、３３２、３４２は、たとえばリソース監視および制御（ＲＭＣ）クラスとすることができる。ＲＭＣクラスには既知のタイプがあるが、ＬＰＡＲ環境での自動および動的なリソース割り振り用に特殊なクラスを導出することができる。接続時に、サーバ３５０は監視するしきい値を区画に送信することが可能であり、これらのしきい値は各監視クライアント・インスタンスで設定される。

監視クライアント３１２などの監視クライアントがリソース状況通知イベントを生成すると、サーバ３５０はこのイベントに基づいて適切なゾーンを表すリンク・リスト内でこの区画をソートする。リンク・リストは、実際のリソース利用率メトリクスによってソートされる。特定の例のように、高ゾーンは降順でソートされ、中ゾーンは降順でソートされ、低ゾーンは昇順でソートされる。

区画が高ゾーンまたは低ゾーンのいずれかのリストに配置された場合、サーバ３５０はリソースが再割り振り可能かどうかをチェックする。区画が高ゾーン・リストにある場合、サーバ３５０はリソースが低区画から高区画へと移動可能かどうかをチェックする。リソースが割り振り／割り振り解除されると、問題の２つの区画はそれぞれのリストから除去される。このプロセスは、高ゾーン・リストまたは低ゾーン・リストが空になるまで繰り返される。

区画がすでに１つのゾーン内にあり、サーバ３５０がその区画を別のゾーンに配置するというイベント（通知）を受け取ると、サーバ３５０は第１にその区画を現在のゾーン・リストから除去し、次にその区画を適切な利用率ゾーン・リストに配置する。区画がすでに１つのゾーン内にあり、サーバがその区画を同じゾーン内に配置するというイベントを受け取ると、サーバ３５０はその区画の新しい利用率メトリクスを使用してリストを再ソートする。

監視クライアント３１２などの各クライアントは、区画３１０などの区画で動作する。監視クライアント３１２、３２２、３３２、３４２は、たとえば、本発明の例示的態様に従って利用率ゾーンを使用した自動リソース管理を含むように修正される、ＲＭＣリソース・クラスとすることができる。たとえば監視クライアント３１２は、ＣＰＵ使用率、メモリ使用率、Ｉ／Ｏアダプタ使用率などのリソース利用率メトリクスを定期的に収集する。たとえば監視クライアント３１２は、たとえば１０秒ごとにそれ自体をウェイクアップしてリソース利用率メトリクスを収集する。監視間隔は、インプリメンテーションに基づいて選択することができる。

収集された利用率メトリクス、およびポリシー・ファイル３５２に定義されるようにサーバ３５０から受け取ったしきい値に基づいて、監視クライアントは区画の現在の状態をサーバに通知する。利用率が低しきい値よりも低い場合、監視クライアントはサーバ３５０に対して区画からリソースを除去するように要求する。他方で、利用率が高しきい値よりも高い場合、監視クライアントはサーバ３５０に対して区画にさらにリソースを割り当てるように要求する。利用率が低しきい値と高しきい値の間にある場合、監視クライアントは区画に対する現在の割り振りが十分である旨報告する。

サーバ３５０は、図２のハードウェア・システム・コンソール２８０などの管理コンソール上で動作することができる。この場合サーバ３５０は、リソースの割り振りおよび割り振り解除をハイパーバイザ３６０に要求する。代替の実施形態では、サーバ３５０は論理的に区分されたデータ処理システム内の区画上で動作する。この場合、サーバ３５０はリソースの割り振りおよび割り振り解除を管理コンソール（図示せず）を介してハイパーバイザ３６０に要求する。

低しきい値および高しきい値は、インプリメンテーションに基づいて選択することができる。たとえば低しきい値を４０％に設定し、高しきい値を９０％に設定することができる。しかしながら、ＬＰＡＲデータ処理システムの特定の条件は、リソース割り振りにおいてより一層のバランスを達成するようにしきい値を修正しなければならない旨を指示することができる。言い換えれば、区画の大部分がそれらの時間の大部分を中ゾーンで費やすことを保証するように、低しきい値および高しきい値を設定しなければならない。管理者は、たとえばこのバランスを達成しようとする試みるためにいつでも、図２のハードウェア・システム・コンソール２８０でユーザ・インターフェースを介してポリシー３５２を修正することができる。

図４〜６は、本発明の例示的実施形態に従った利用率ゾーンに基づいてリンク・リストにソートされる区画の例を示す図である。サーバ・アプリケーションは、監視されることになる区画の監視クライアントからリソース状況通知を受け取る。その後サーバは、区画を利用率ゾーンにカテゴリ化し、各利用率ゾーンについてリンク・リストを形成する。図４〜６に示される例では、高ゾーン、中ゾーン、および低ゾーンの３つの利用率ゾーンがある。しかしながら、インプリメンテーションに応じてこれよりも多いかまたは少ない利用率ゾーンを使用することもできる。たとえば、あるタイム・スライスで各区画が他よりも多くのリソースを受け取ることができる公平性ポリシーを実施するために、２つのゾーンを使用してリソースを区画に動的に割り振ることができる。他の例として、最低ゾーンから最高ゾーンまで思い切ったリソース割り振りを実行できるように、５つのゾーンをインプリメントすることもできる。

図４では、区画Ａおよび区画Ｃが高ゾーンにあり、これはそれらのリソース利用率が高しきい値を上回っていることを意味する。高ゾーンのリンク・リストは降順にソートされるため、区画Ａのリソース利用率は区画Ｃのリソース利用率よりも高い。また区画Ｂおよび区画Ｅが低ゾーンにあり、これはそれらのリソース利用率が低しきい値を下回っていることを意味する。低ゾーンのリンク・リストは昇順にソートされるため、区画Ｂのリソース利用率は区画Ｅのリソース利用率よりも低い。区画Ｄは中利用率ゾーンにあり、これはそのリソース利用率が低しきい値と高しきい値の間にあることを意味する。

区画Ｂは最低のリソース利用率を有し、区画Ａは最高のリソース利用率を有するため、サーバ・アプリケーションは区画Ｂからリソースを割り振り解除し、それらを区画Ａに割り当てるように試みる。次にサーバは、低ゾーンのリンク・リストから区画Ｂを除去し、高ゾーンのリンク・リストから区画Ａを除去する。同様に、サーバは区画Ｅからリソースを割り振り解除し、それらを区画Ｃに割り当てるように試みる。その後サーバは、低ゾーンのリンク・リストから区画Ｅを除去し、高ゾーンのリンク・リストから区画Ｃを除去する。

次にリソース利用率メトリクスが収集されると、サーバは図５に示されるように区画Ｃが中ゾーンにある旨の通知を受け取る。すなわち、区画Ｃのリソース利用率は低しきい値と高しきい値の間にある。中ゾーンのリンク・リストは降順にソートされるため、区画Ｃのリソース利用率は区画Ｄのリソース利用率よりも高い。この例では集められた利用率メトリクスに基づいて、区画Ｂおよび区画Ｅは低利用率ゾーンに残る。

区画Ｂは最低のリソース利用率を有し、区画Ａは最高のリソース利用率を有するため、サーバ・アプリケーションは区画Ｂからリソースを割り振り解除し、それらを区画Ａに割り当てるように試みる。その後サーバは、低ゾーンのリンク・リストから区画Ｂを除去し、高ゾーンのリンク・リストから区画Ａを除去する。その後、次にリソース利用率メトリクスが収集されると、サーバは図６に示されるようにここでは区画Ａおよび区画Ｅが中ゾーンにある旨の通知を受け取る。高ゾーンのリンク・リストは空であるため、割り振り／割り振り解除は必要ない。

図７は、本発明の例示的実施形態に従った、監視クライアントのオペレーションを示す流れ図である。オペレーションが開始され、クライアントはサーバ・アプリケーションからしきい値を受け取って初期化する（ブロック５０２）。次に、終了条件が存在するかどうかが判別される（ブロック５０４）。たとえば区画が供給解除（ｄｅｐｒｏｖｉｓｉｏｎ）された場合、またはデータ処理システムがシャットダウンした場合に、終了条件が存在する可能性がある。終了条件が存在した場合、オペレーションは終了する。

ブロック５０４で終了条件が存在しない場合、ウェイクアップするかどうかが決定され、統計値が集められる（ブロック５０６）。この決定は、たとえば監視間隔が満了したかどうかを判別することによって行われる。監視間隔はブロック５０２の初期化で設定すること、およびサーバのポリシーによって定義することが可能である。監視クライアントは、たとえばリソースが不十分であることによるエラー条件などの他のイベントに応答してウェイクする場合もある。ブロック５０６で監視クライアントがウェイクしない場合、オペレーションはブロック５０４に戻り、終了条件が存在するかどうかを判別する。

ブロック５０６で監視クライアントがウェイクした場合、監視クライアントはリソース利用率メトリクスを収集し（ブロック５０８）、リソース状況を決定し（ブロック５１０）、リソース状況通知をサーバに送る（ブロック５１２）。その後、オペレーションはブロック５０４に戻り、終了条件が存在するかどうかを判別する。

図８は本発明の例示的実施形態に従った監視およびリソース管理サーバのオペレーションを示す流れ図である。オペレーションが開始され、サーバはポリシー・ファイルを読み取って初期化する（ブロック６０２）。前述のように、ポリシー・ファイルはどの区画を監視するか、利用率ゾーンのしきい値、監視間隔、ならびにリソースを監視および管理するために使用される他の情報を定義することができる。その後、サーバはしきい値を監視クライアントに送る（ブロック６０４）。

次に、終了条件が存在するかどうかが判別される（ブロック６０６）。たとえばデータ処理システムがシャットダウンした場合、終了条件が存在する可能性がある。終了条件が存在した場合、オペレーションは終了する。ブロック６０６で終了条件が存在しない場合、サーバは１つまたは複数のリソース状況通知が受け取られたかどうかを判別する（ブロック６０８）。リソース状況通知を受け取っていない場合、オペレーションはブロック６０６に戻り、終了条件が存在するかどうかを判別する。

ブロック６０８でリソース状況通知が受け取られた場合、サーバは区画を利用率ゾーンに分ける（ブロック６１０）。その後サーバは、各利用率ゾーンについてリンク・リストを形成し（ブロック６１２）、各リンク・リストをソートする（ブロック６１４）。次に、高ゾーンが空であるかどうかが判別される（ブロック６１６）。高ゾーン・リストが空である場合、リソースの再割り振りは不要であり、オペレーションはブロック６０６に戻って終了条件が存在するかどうかが判別される。

ブロック６１６で高ゾーン・リストが空でない場合、低ゾーン・リストが空であるかどうかが判別される（ブロック６１８）。低ゾーン・リストが空である場合、高ゾーン・リスト内の区画に再割り振りする未使用リソースはないため、オペレーションはブロック６０６に戻り、終了条件が存在するかどうかが判別される。

ブロック６１８で低ゾーン・リストが空でない場合、サーバは低ゾーン内で利用率が最低の区画から高ゾーン内で利用率が最高の区画にリソースを再割り振りする（ブロック６２０）。次に、サーバはこれらの区画をそれぞれのリストから除去し（ブロック６２２）、オペレーションはブロック６１６おおび６１８に戻り、高ゾーン・リストまたは低ゾーン・リストが空であるかどうかを判別する。その後サーバは、高ゾーン・リストまたは低ゾーン・リストのいずれかが空になるまで、低ゾーン・リスト内の区画から高ゾーン・リスト内の区画へのリソースの再割り振りを続ける。

このようにして本発明は、論理的に区分された環境でリソースを自動的に監視および割り当てるためのクライアント／サーバ・モデルを提供することによって、従来技術の欠点を解決する。各区画には、その区画のリソース利用率を監視するクライアント・アプリケーションが含まれる。クライアント・アプリケーションはリソース利用率メトリクスを収集し、定期的にリソース状況通知をサーバ・アプリケーションに送る。サーバ・アプリケーションは、区画または外部ワークステーションのいずれかで動作する。サーバ・アプリケーションはクライアントからのリソース状況通知を待ち、これらの通知に基づいて区画を利用率ゾーンにカテゴリ化する。その後サーバは、低利用率ゾーンにある区画からのリソースを高利用率ゾーンにある区画に再割り当てする。

本発明のクライアント／サーバ・モデルは、管理者による手作業の介入なしに、リソースの自動管理および動的割り振りを可能にする。したがって管理者は、自分の貴重な時間を他の作業に費やすことができる。さらに、区画がより頻繁に監視され、リソースがより高度に割り振られるため、データ処理システムはより効率よく実行できるようになり、サービス・レベルの取り決めをさらに満たすものとなる。

以上、本発明について完全に機能するデータ処理システムとの関連において説明してきたが、当業者であれば、本発明のプロセスが命令のコンピュータ読み取り可能媒体の形および様々な形で配布可能であること、ならびに本発明が配布を実行するために実際に使用される特定のタイプの信号伝達媒体に関係なく等しく適用されることを理解されるであろう。コンピュータ読み取り可能媒体の例には、フロッピィ・ディスク、ハード・ディスク・ドライブ、ＲＡＭ、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭなどの書き込み可能タイプの媒体、ならびに、デジタルおよびアナログの通信リンク、たとえば無線周波および光波伝送などの伝送形態を使用する有線または無線の通信リンクなどの伝送タイプの媒体が含まれる。コンピュータ読み取り可能媒体は、特定のデータ処理システムで実際に使用するために復号される符号化フォーマットの形を取ることができる。

本発明の説明は例示および説明の目的で提示してきたものであって、本発明の開示された形を網羅するかまたはこれに限定することを意図するものではない。通常の当業者であれば、多くの修正および変形が明らかとなろう。実施形態は、本発明の原理、実際の応用例を最も良く説明するため、および他の通常の当業者が企図された特定の使用に適するような様々な修正を伴う様々な実施形態に関して本発明を理解できるようにするために、選択および説明されたものである。

本発明が実施可能なデータ処理システムを示すブロック図である。 本発明が実施可能な例示的論理区分プラットフォームを示すブロック図である。 本発明の例示的実施形態に従った、論理的に区分されたデータ処理システム内での動的なリソース管理システムを示すブロック図である。 本発明の例示的実施形態に従った、利用率ゾーンに基づいてリンク・リストにソートされる区画の例を示す図である。 本発明の例示的実施形態に従った、利用率ゾーンに基づいてリンク・リストにソートされる区画の例を示す図である。 本発明の例示的実施形態に従った、利用率ゾーンに基づいてリンク・リストにソートされる区画の例を示す図である。 本発明の例示的実施形態に従った、監視クライアントのオペレーションを示す流れ図である。 本発明の例示的実施形態に従った監視およびリソース管理サーバのオペレーションを示す流れ図である。

符号の説明

３１０ 区画
３１２ 監視クライアント
３２０ 区画
３２２ 監視クライアント
３３０ 区画
３３２ 監視クライアント
３４０ 区画
３４２ 監視クライアント
３５０ サーバ
３５２ ポリシー・ファイル
３６０ ハイパーバイザ

Claims (20)

1. 論理的に区分されたデータ処理システムにおいてリソースを管理する方法であって、
   区画からリソース利用率状況情報を受け取ることと、
   前記区画を利用率ゾーンにカテゴリ化することと、
   低利用率ゾーンの低利用率区画から高利用率ゾーンの高利用率区画にリソースを動的に再割り振りすることと、
   を含む前記方法。
2. リソース利用率状況情報を受け取ることが、所与の区画で動作中の監視クライアント・アプリケーションからリソース利用率状況通知を受け取ることを含む、請求項１に記載の方法。
3. 前記リソース利用率状況通知が前記所与の区画の利用率ゾーンを識別する、請求項２に記載の方法。
4. 前記区画を利用率ゾーンにカテゴリ化することが、
   各利用率ゾーンについてリストを形成することと、
   前記リストを各利用率ゾーンについてソートすることと、
   を含む、請求項３に記載の方法。
5. 低利用率ゾーンの低利用率区画から高利用率ゾーンの高利用率区画へのリソースの動的な再割り振り後に、前記低利用率区画を前記低利用率ゾーンのリストから除去し、前記高利用率区画を前記高利用率ゾーンのリストから除去することをさらに有する、請求項４に記載の方法。
6. 前記リソースの再割り振りを、前記高利用率ゾーンの前記リストまたは前記低利用率ゾーンの前記リストのいずれかが空になるまで繰り返すことをさらに有する、請求項５に記載の方法。
7. 前記利用率ゾーンが、低利用率ゾーン、中利用率ゾーン、および高利用率ゾーンを含む、請求項１に記載の方法。
8. 前記方法が、ハードウェア管理コンソールおよび前記論理的に区分されたデータ処理システム内の区画のうちの１つで動作中のサーバ・アプリケーションによって実行される、請求項１に記載の方法。
9. 論理的に区分されたデータ処理システム内の区画で動作中の複数の監視クライアント・アプリケーションと、
   サーバ・アプリケーションと、
   ハイパーバイザとを含み、
   論理的に区分されたデータ処理システムにおいてリソースを管理する装置であって、
   各監視クライアント・アプリケーションが、そのそれぞれの区画についてのリソース利用率統計値を収集し、そのそれぞれの区画についての利用率ゾーンを識別し、前記利用率ゾーンの通知をサーバ・アプリケーションに送り、
   前記サーバ・アプリケーションが各監視クライアント・アプリケーションから利用率ゾーン通知を受け取り、前記区画を利用率ゾーンにカテゴリ化し、低利用率ゾーンの低利用率区画から高利用率ゾーンの高利用率区画にリソースを動的に再割り振りする、
   前記装置。
10. 前記サーバ・アプリケーションが、各利用率ゾーンについてのリストを形成することおよび各利用率ゾーンについての前記リストをソートすることによって、前記区画を利用率ゾーンにカテゴリ化する、請求項９に記載の装置。
11. 前記サーバ・アプリケーションが、低利用率ゾーンの低利用率区画から高利用率ゾーンの高利用率区画へのリソースの動的な再割り振り後に、前記低利用率区画を前記低利用率ゾーンのリストから除去し、前記高利用率区画を前記高利用率ゾーンのリストから除去する、請求項１０に記載の装置。
12. 前記サーバ・アプリケーションが、前記リソースの再割り振りを、前記高利用率ゾーンの前記リストまたは前記低利用率ゾーンの前記リストのいずれかが空になるまで繰り返す、請求項１１に記載の装置。
13. 前記利用率ゾーンが、低利用率ゾーン、中利用率ゾーン、および高利用率ゾーンを含む、請求項９に記載の装置。
14. 前記サーバ・アプリケーションが、ハードウェア管理コンソールおよび前記論理的に区分されたデータ処理システム内の区画のうちの１つで動作する、請求項９に記載の装置。
15. 論理的に区分されたデータ処理システムにおいてリソースを管理するためのコンピュータ・プログラムであって、
    コンピュータに、
    区画からリソース利用率状況情報を受け取る機能と、
    前記区画を利用率ゾーンにカテゴリ化する機能と、
    低利用率ゾーンの低利用率区画から高利用率ゾーンの高利用率区画にリソースを動的に再割り振りする機能と、
    を実現させる前記プログラム。
16. リソース利用率状況情報を受け取る機能が、所与の区画で動作中の監視クライアント・アプリケーションからリソース利用率状況通知を受け取る機能を含む、請求項１５に記載のコンピュータ・プログラム。
17. 前記リソース利用率状況通知が前記所与の区画の利用率ゾーンを識別する、請求項１６に記載のコンピュータ・プログラム。
18. 前記区画を利用率ゾーンにカテゴリ化する機能が、
    各利用率ゾーンについてリストを形成する機能と、
    前記リストを各利用率ゾーンについてソートする機能と、
    を含む、請求項１７に記載のコンピュータ・プログラム。
19. 低利用率ゾーンの低利用率区画から高利用率ゾーンの高利用率区画へのリソースの動的な再割り振り後に、前記低利用率区画を前記低利用率ゾーンのリストから除去し、前記高利用率区画を前記高利用率ゾーンのリストから除去する機能をさらに含む、請求項１８に記載のコンピュータ・プログラム。
20. 前記リソースの再割り振りを、前記高利用率ゾーンの前記リストまたは前記低利用率ゾーンの前記リストのいずれかが空になるまで繰り返す機能をさらに含む、請求項１９に記載のコンピュータ・プログラム。

Images