JP2010277589A - データ・センタのバッチ・ジョブのサービスの質コントロール - Google Patents

Abstract

【課題】データ・センタのリソース割り付けを効果的に行う方法を提供する。
【解決手段】所定のバッチ・ジョブのための拡張間隔サービスの質（ＱｏＳ）仕様を決定するステップと、複数の時間スライスのうちの少なくとも第１の１つについてバッチ・ジョブのための残存データ・センタ・リソース要件を、拡張間隔ＱｏＳ仕様に少なくとも部分的に基づいて決定するステップと、バッチ・ジョブのための即時ＱｏＳ仕様を、残存データ・センタ・リソース要件に少なくとも部分的に基づいて決定するステップと、を設ける。
【選択図】図４

Description

開示されたテクノロジはデータ・センタの分野に関し、より詳細にはデータ・センタの運用に関連して実装が可能なバッチ・ジョブのためのデータ・センタのリソース割り付けの決定に関係する多様なテクニックに関する。

データ・センタは、しばしば多様なタイプのエンティティによって広範多様な目的のために使用される。電話会社、ケーブル・ネットワーク、電力会社、小売店等々のサービス・プロバイダは、一般に、自分たちの顧客のデータを「サーバ・ファーム」またはデータ・センタ内にストアし、アクセスする。この明細書の目的から「データ・センタ」は、コンピュータ・システムおよび関連する構成要素、たとえば通信およびストレージ・システムの収容に使用される施設を言う。データ・センタは、概してコンピュータ・システムだけでなく、バックアップ電源、冗長データ通信接続、空調および火災抑制等の環境コントロール、セキュリティ・システムおよびデバイス等も含む。

データ・センタの運用は、概して顧客サービス・レベルを中心に置く。たとえば、特定の顧客が、その顧客の計算またはデータ通信のために定義済みのサービスの質を有したいと望むことがある。サービスの質は、異なる顧客について異なる要件を有することができる。たとえば１人の顧客についてのサービスの質の主要測度は、遠隔アクセス時にアプリケーションがいかに速く応答するかに関係することがある。別の顧客については、サービスの質が、その顧客の加入者に提供される接続の速度または帯域幅に関係することがある。

データ・センタは、所定の顧客のために特定のサービス・レベルを提供することを、公式に取り決めたサービス・レベル合意（ＳＬＡ）の形式で確約することがある。ＳＬＡは、通常、可用性、保守性、性能、運用、請求等のレベルを指定し、またＳＬＡの違反の際における罰則を指定できることさえある。ＳＬＡは、一般に性能測定、問題管理、顧客義務、保証、災害復旧、および合意の終結を取り扱う。たとえばＳＬＡは、特定のジョブが指定の確度を伴って特定量のリソースを得ることを要求できる。またＳＬＡは、特定のジョブまたはジョブのグループに割り当てられるべきリソースの量に対して限界を指定することもできる。

「仮想化」は、概して、コンピューティング・リソースの物理特性を、ほかのシステム、アプリケーション、またはエンド・ユーザがそれらのリソースとインタラクションする方法から隠蔽するためのテクニックを言う。これは、通常、サーバ、オペレーティング・システム、アプリケーション、ストレージ・デバイス等の単一の物理リソースが、複数の論理リソースとして機能するように見せることを含む。仮想化は、また、複数の物理リソースが単一の論理リソースに見えるようにすることも含むことができる。それに加えて、１つの物理リソースが、いくらか異なる特性を伴って１つの論理リソースとして見えるようにすることも含むことができる。

仮想化は、基本的に、複数の環境にわたり、単一コンピュータまたはコンピュータのクラスタのリソースを共有することによって１つのコンピュータに複数のコンピュータのジョブを行わせることが可能である。たとえば仮想サーバおよび仮想デスクトップ等の仮想マシンは、ユーザに複数のオペレーティング・システムおよび複数のアプリケーションをホストする能力をローカルおよび遠隔場所の両方で提供可能であり、物理的および地理的制限からユーザを解放する。より効率的なハードウエア・リソースの使用に起因するエネルギの節約およびより低い資本支出に加えて、ユーザは、リソースの高い可用性、より良好なデスクトップ管理、増加した安全性、および改善された災害復旧プロセスを得ることが可能である。

仮想マシンは、所定のコンピュータ・システム内における広範多様な目的に役立つ。たとえば仮想マシンを使用して、そのコンピュータ・システムへの同時アクセスを複数のユーザに提供できる。各ユーザは、異なる仮想マシン内でアプリケーションを実行することができ、仮想マシンは、コンピュータ・システム・ハードウエア上における実行についてスケジュールすることができる。以前は別々のコンピュータ・システム上で実行されていたタスクを、仮想マシンを使用して、たとえば各タスクを１つの仮想マシンに割り当て、それらの仮想マシンをより少ないコンピュータ・システム上において実行することによって併合することができる。仮想マシンは、また、増加した可用性の提供に使用することもできる。たとえばコンピュータ・システムが故障した場合に、そのコンピュータ・システム上の仮想マシン内で実行していたタスクを別のコンピュータ・システム上の類似した仮想マシンに転送することができる。

仮想サーバの使用は、その仮想サーバによって提供されるサービスの消費者に対して透過的な、ほかの物理サーバまたはリソースへの処理タスクの移行を可能にするが、それにおいては消費者を、ユーザ、プロセス、別のコンピュータ等とすることができる。「消費者」は、通常、電力コントロール・システム内の処理またはサービスを使用する任意のエンティティである。これは、サービス・レベル合意に従ってデータ・センタがサービスを提供する識別済みエンティティである「顧客」と対比される。性能レベルは、概して顧客によって追跡される。

仮想サーバは、物理サーバと大きく異なる。仮想サーバは、通常、それにアクセスするエンティティに単一サーバであるように見えるが、実際は物理サーバのパーティションまたはサブセットとなることがある。またそれが単一サーバとして見えるが、実際にはいくつかの物理サーバからなるということもある。仮想サーバは、上で論じたとおりの仮想化プロセスを通じて作られる。

したがって所定のデータ・センタにおいて、仮想化は、仮想サーバ等の複数の仮想マシンがデータ・センタ内の同じ物理マシン（１つまたは複数）のＣＰＵ、メモリ、ディスク、ネットワーク・リソース等の物理リソースを共有することを可能にする。各仮想マシンは、通常、所定の仮想マシンのためにどの程度の物理リソースが予約されるべきであるかを決定する対応するリソース要件の仕様を有する。

データ・センタのリソース割り付けを効果的に行う方法を提供することを目的とする。

本発明は、マシン・コントロール可能な方法であって、所定のバッチ・ジョブのための拡張間隔サービスの質（ＱｏＳ）仕様を決定するステップと、複数の時間スライスのうちの少なくとも第１の１つについて前記バッチ・ジョブのための残存データ・センタ・リソース要件を、前記拡張間隔ＱｏＳ仕様に少なくとも部分的に基づいて決定するステップと、前記バッチ・ジョブのための即時ＱｏＳ仕様を、前記残存データ・センタ・リソース要件に少なくとも部分的に基づいて決定するステップと、を含むマシン・コントロール可能な方法である。

さらに、前記複数の時間スライスのうちの少なくとも第２の１つについて前記即時ＱｏＳ仕様を、前記バッチ・ジョブの進捗に少なくとも部分的に基づいて決定するステップを包含し、それにおいて前記複数の時間スライスのうちの前記第２の１つは、前記複数の時間スライスのうちの前記第１の１つの後であり、かつ前記バッチ・ジョブの完了時の前に生ずるマシン・コントロール可能な方法としてもよい。

前記拡張間隔ＱｏＳ仕様を決定するステップは、失敗の許容確度ｑの決定を包含するマシン・コントロール可能な方法としてもよい。

前記即時ＱｏＳ仕様を決定するステップは、データ・センタ・リソース予約Ｓの決定を含むマシン・コントロール可能な方法としてもよい。

データ・センタのリソース割り付けを効果的に行う方法を提供することができる。

開示されたテクノロジの実施態様に従って、コントローラおよびそれぞれが仮想マシンを有する複数の物理デバイスを有するデータ・センタ・アーキテクチャの例を図解した説明図である。 データ・センタ管理インターフェース、顧客登録モジュール、バッチ・ジョブＱｏＳコントロール・モジュール、リソース最適化モジュール、顧客費用決定モジュール、運用センタ、およびリソース利用モデル更新モジュールを有するデータ・センタ最適化システムの例を図解した説明図である。 いずれも統計的リソース・パッキング・モジュールによって扱われるトランザクショナル・ジョブおよびバッチ・ジョブとの使用に適した図２のデータ・センタ最適化システム等のデータ・センタ最適化システムのサブシステムの例を図解した説明図である。 開示されたテクノロジの実施態様に従って、たとえばバッチＱｏＳコントロール・モジュールを介したバッチ・ジョブＱｏＳコントロール・アルゴリズムの実装に関係する方法の例を図解したフローチャートである。 開示されたテクノロジの実施態様に従って３０の時間スライスの期間にわたりバッチ・ジョブのためにデータ・センタ・リソース予約Ｓを調整する第１の例を図解したグラフである。 開示されたテクノロジの実施態様に従って３０の時間スライスの期間にわたりバッチ・ジョブのためにデータ・センタ・リソース予約Ｓを調整する第２の例を図解したグラフである。

図１は、開示されたテクノロジの実施態様に従ってデータ・センタ・アーキテクチャ１００の例を図解している。この例においては、データ・センタ・アーキテクチャ１００が、サーバ等の複数の物理デバイス１０２を含む。各物理デバイス１０２は、特定のサービスを提供することが可能な、クワッド、デュアル、またはシングルコアのコンピューティング・システム等の実際のマシンである。その種の物理デバイス１０２の例は、一般に、通信サーバ、データベース・サーバ、アプリケーション・サーバ等を含む。各物理デバイス１０２は、その上で動作している仮想サーバ等の少なくとも１つの仮想マシン１０４を有するとして図示されている。この例においては、仮想マシン１０４がオペレーティング・システムの最上位で動作するアプリケーションを含む。

この例において仮想マシン１０４は、サービス／電力コントローラ等の低レベル・モジュール１０８が、仮想マシンのリソース所要および物理デバイス１０２のリソースに部分的に基づいて仮想マシン内の処理タスクを物理デバイス１０２に課することを可能にする。低レベル・モジュール１０８は、コントローラまたはスケジューラと呼ばれることもある。コントローラ１０８は、仮想マシンの処理をスケジュールすることが可能であるか、またはコントローラ１０８は、仮想マシン内において実行されることになる個別のタスクをスケジュールすることが可能である。ここで使用する場合の用語『ジョブ』は、概して仮想マシンまたはスケジュールされているタスクを言う。

例においては、コントローラ１０８が単一のコントローラとして示されているが、当業者は、コントローラ１０８が実際にいくつかのコンピュータ、処理コア等にわたって分散され得ることを認識するであろう。コントローラ１０８は、物理デバイス１０２の間でジョブを移行し、かつ物理デバイス１０２の電力消費を調整することができる。中央コントローラ１０８に加えて、個別の物理デバイス１０２のうちの１つまたは複数が局部コントローラ１０６を有することがある。物理デバイス１０２が、この例ではサーバとして図解されているが、電源、ストレージ・アレイまたはそのほかのタイプのストレージ、テープ・デッキ等といったそのほかのタイプのデバイスを含めることができる。

中央コントローラ１０８は、データ・ライン１１０に結合することができる。データ・センタの機能は、概して何らかの種類のデータ処理を中心に置いており、コントローラは、データ・ラインと同じ電力分配構造内に単に存在するだけのこともあり、または電力コントローラがデータ・ラインの運用を監視するかまたは影響を及ぼすこともある。同様に、電力コントローラが電力ライン１１２と同じ電力構造内に単に存在するだけのこともあり、またはコントローラ１０８が電力ライン１１２を伴ったより能動的な役割につくこともある。電力ライン１１２は、概して送電線路、変換器、変圧器、および電力スイッチを含む『グリッド』とも呼ばれる局地的電力インフラストラクチャから到来する。

図２は、開示されたテクノロジの実施態様に従ったデータ・センタ最適化システム２００の例を図解する。例においてデータ・センタ最適化システム２００は、データ・センタ管理インターフェース２０２、データ・センタ顧客登録モジュール２０４、データ・センタ・リソース最適化モジュール２０６、およびデータ・センタ顧客費用決定モジュール２０８を含む。データ・センタ最適化システム２００は、たとえば物理デバイスのグループ等の運用センタ２１０、およびデータ・センタ・リソース利用モデル更新モジュール２１２も含む。この例では、データ・センタ最適化システム２００が、バッチ・ジョブＱｏＳコントロール・モジュール２１４も含む。

この例においては、データ・センタ顧客登録モジュール２０４を使用し、データ・センタ顧客固有のデータ・センタのサービス・レベル合意（ＳＬＡ）の実行を容易にすること、およびその顧客のためのデータ・センタ・リソース利用モデルを確立することによって、それぞれの新しいデータ・センタ顧客を登録することが可能である。データ・センタ・リソース利用モデルは、顧客によって要求されるデータ・センタのリソースの定量化を含むことができる。たとえばデータ・センタ顧客登録モジュール２０４は、データ・センタ顧客に、メモリ、ディスク空間、およびＣＰＵ帯域幅等のそれぞれの特定のデータ・センタ・リソースをどの程度、その顧客が要求したいのかについて問い合わせを行うことができる。データ・センタ最適化システム２００は、その後、その顧客についてのデータ・センタ顧客プロファイルを作成し、その顧客についてのＳＬＡおよびデータ・センタ・リソース利用モデル両方をデータ・センタ顧客プロファイルの部分としてストアすることができる。

図１に図解されているデータ・センタ・アーキテクチャ１００等の共有リソース・システムにおいては、サービスの質仕様に従ってデータ・センタ・リソースの使用を慎重に管理することによって同一のデータ・センタ・リソースを伴う複数のジョブを供することが可能である。たとえばデータ・センタ・リソース・プールへの複数ジョブ（または仮想マシン）の統計的パッキングのためのテクニックを、その種のテクニックが、たとえばジョブが必要とするリソースを受けないことになるという許容リスクを指定する仕様等のサービスの質仕様の使用に関係するところに実装することができる。その種のテクニックは、ジョブがサービスの質の多様性を有するとき、かなりのデータ・センタ・リソースを節約することができる。特に、よりリスク耐性のあるジョブは、偶発的な予約として捨て去られる可能性があり、よりリスクを嫌うジョブのデータ・センタ・リソース予約を共有できる。

この例においては、データ・センタ・リソース最適化モジュール２０６が、たとえば所定の顧客のための初期（たとえば最適）データ・センタ・リソース割り付けを、その顧客のＳＬＡおよびデータ・センタ・リソース利用モデルに基づいて決定し、その後そのデータ・センタ・リソース割り付けを、実行のために運用センタ２１０に割り当てることができる。データ・センタ・リソース割り付けの決定においてデータ・センタ・リソース最適化モジュール２０６は、メモリおよび処理等のリソースを特定の顧客に提供するといったサービスを行うデータ・センタに対する費用を決定（たとえば評価）することが可能なデータ・センタ顧客費用決定モジュール２０８とインタラクションすることができる。特定の実施態様においては、データ・センタ・リソース最適化モジュール２０６が、データ・センタ顧客費用決定モジュール２０８に特定のデータ・センタ顧客またはデータ・センタ顧客のグループについてのデータ・センタ顧客費用の決定のための要求を送ることができる。

顧客費用決定モジュール２０８が顧客またはグループについてのデータ・センタ顧客費用を決定すると、データ・センタ顧客費用決定モジュール２０８は、そのデータ・センタ顧客費用をデータ・センタ・リソース最適化モジュール２０６に提供できる。データ・センタ・リソース最適化モジュール２０６は、その後そのデータ・センタ顧客費用に基づいてデータ・センタ・リソース割り付けを生成し、そのデータ・センタ・リソース割り付けを、実行のために運用センタ２１０に割り当てることができる。

データ・センタ・リソース利用モデル更新モジュール２１２は、運用センタ２１０を監視することができる。運用センタ２１０の監視に基づいて、データ・センタ・リソース利用モデル更新モジュール２１２は、データ・センタ顧客登録モジュール２０４に推奨を提供できる。たとえばデータ・センタ・リソース利用モデル更新モジュール２１２は、データ・センタ顧客登録モジュール２０４が特定の顧客についてのデータ・センタ顧客プロファイルを、特定の時間期間にわたるその顧客の運用センタ２１０の利用を前提に修正することを推奨できる。代替実施態様においては、データ・センタ・リソース利用モデル更新モジュール２１２が、データ・センタ顧客プロファイルを直接修正すること、または新しく作成したデータ・センタ顧客プロファイルを提供してその顧客についての既存のデータ・センタ顧客プロファイルと置き換えることのいずれも可能である。

バッチ・サービスの質（ＱｏＳ）コントロール・モジュール２１４をバッチ・ジョブのために使用することが可能である。これはスケジューリングおよび実行する間のサービスの特定の優先度というより、指定された時間までの完了が要求される傾向にあるという点でむしろ独特な属性を有する傾向がある。バッチ・ジョブのためのデータ・センタ・リソース割り付けに関係する状況においては、データ・センタ・リソース予約を各時間スライスに対して行うことが可能であるが、要求をかなり緩和することができる。言い替えると、バッチ・ジョブは、概して柔軟なジョブであり、時間スライスの終了までに高い確度を伴ってそれらのジョブが終了されることを除けば、毎時間スライス・ベースの質の要件が低い。

バッチ・ジョブＱｏＳコントロール・モジュール２１４は、ここに述べられているテクニックを実装し、一方ではより高い優先度のタスクの混合の中においてデータ・センタ・リソースを最適化しつつ、たとえば確率論的なリソース要件またはデッドライン完了仕様を満たすことによってバッチ・ジョブのための上首尾の完了の時間を実質的に保証することが可能である。その種のテクニックは、バッチ・ジョブが短期リスク耐性となり、かつその結果としてそれによって要求されるデータ・センタ・リソースのレベルが下がるように、しかも同時に、そのバッチ・ジョブが高いＱｏＳ仕様を伴ってデッドライン等の長期目的を満たすことを可能にするように、ＱｏＳ共有リソース・システムにおけるバッチ・ジョブの統合を伴うことが可能である。

特定の実施態様は、ＱｏＳ仕様に基づくバッチ・ジョブのためのコントロール・アルゴリズムの実装を含むことができる。ここで使用されるとき、ＱｏＳ仕様は、バッチ・ジョブの完了のために必要とされるデータ・センタ・リソースおよびそのバッチ・ジョブの上首尾の提供における何らかの不確実性を見込む要素の指定を含むことができる。いくつかの実施態様においては、必要とされるリソースをＱｏＳ仕様が指定せず、むしろ、実行時のすべてのバッチ・ジョブの所要の上首尾の提供のために許容される不確実性を指定する。

ここで使用されるとき、ＱｏＳ仕様は、一般にＳＬＡに類似であり、いくつかの実施態様においては同じになることがある。しかしながら、ＳＬＡが概してより顧客に近く、また顧客のアプリケーションに関係する点からサービスを記述できることに対して、ＱｏＳが概してよりデータ・センタ・リソース最適化に近く、１つまたは複数のデータ・センタ・リソースの点からサービスを記述できることから別々の用語が使用される。ＱｏＳ仕様がＳＬＡと異なる実施態様においては、部分的にＳＬＡに基づいてＱｏＳ仕様を導出することを含む段階があり得る。バッチ・コントロール運用の場合には、ここで使用されるところの用語『即時』および『拡張間隔』ＱｏＳ仕様を互いに識別することも可能である。

コントロール・アルゴリズムを使用して、バッチ・ジョブにとってより自然な『拡張間隔』ＱｏＳ仕様を達成するために、統計的パッキング・アルゴリズムに頻繁に提供される『即時』ＱｏＳ仕様の操作を進めることが可能である。特定の実施態様においては、統計的パッキング・アルゴリズムの実装からのデータ・センタ顧客費用フィードバックが、図２に図解されているとおり、２つの最適化アルゴリズムの連接を提供できる（すなわち、バッチ・ジョブＱｏＳコントロール・モジュール２１４が、フィードバックをデータ・センタ顧客費用決定モジュール２０８から受け取る）。

いずれも統計的リソース・パッキング・モジュール３０８によって扱われるトランザクショナル・ジョブ３０２をはじめバッチ・ジョブ３０４との使用に適した（図２のデータ・センタ最適化システム２００等の）データ・センタ最適化システムのサブシステム３００の例を示している図３に図解されているとおり、開示されたテクノロジの実施態様は、データ・センタ・アーキテクチャ内に、バッチ・ジョブＱｏＳ問題をデータ・センタ・リソース最適化要素（たとえば、統計的パッキング・アルゴリズムの実装）から分離する層を実質的に差し込む。しかしながらバッチ・ジョブ３０４は、バッチ・ジョブＱｏＳコントロール・モジュール３０６により実装されるところのバッチ・ジョブＱｏＳコントロール・アルゴリズムによって最初に扱われる。

特定の実施態様においては、バッチ・ジョブＱｏＳコントロール・アルゴリズムが、バッチ・ジョブの『拡張間隔』ＱｏＳ仕様を、拡張間隔のためのジョブのリソース・モデルとともに採用し、個別の時間スライスに適用されることになるそのバッチ・ジョブのための一連の『即時』ＱｏＳ仕様を適応的に作り出すことが可能である。これらの『即時』ＱｏＳ仕様は、通常、『拡張間隔』ＱｏＳよりはるかに柔軟となり、したがって効果的な統計的パッキングを容易にすることになる。システムのアーキテクチャ内に差し込まれる層は、『拡張間隔』ＱｏＳ仕様を直接最適化する必要性から統計的パッキング・アルゴリズムを好適に解放し、むしろこの場合には、これらの『拡張間隔』ＱｏＳ仕様を『即時』ＱｏＳ仕様に翻訳する、より高いレベルのコントロールの層が存在し、それが統計的パッキング・アルゴリズムの実装への入力（およびそれの動作）を有意に単純化する。

図４は、開示されたテクノロジの実施態様に従って、たとえばバッチ・ジョブＱｏＳコントロール・モジュールを介したバッチ・ジョブＱｏＳコントロール・アルゴリズムの実装に関係する方法４００の例を図解したフローチャートである。この例においては、共有データ・センタ・リソース・システムが、時間スライス（たとえば、毎３分時）内にデータ・センタ・リソースを予約し、かつトランザクショナル・ジョブおよびバッチ・ジョブの両方を提供するが、それにおいて各ジョブは、その時間スライス内にそのジョブが必要とするデータ・センタ・リソースが提供されないことになる許容失敗確度ｐを含むことができる即時ＱｏＳ仕様を有する。たとえば上で述べたような統計的パッキング・アルゴリズムの実装は、ジョブのグループのための低減されたデータ・センタ・リソース要件に到達するために、ジョブのデータ・センタ・リソース所要の確度およびモデルを含む即時ＱｏＳ仕様を好適に結合することができる。

たとえば毎時間スライスの許容提供不足の確度ｐを指定することは、トランザクショナル・ジョブについては自然なＱｏＳ問題となり得るが、それが、より長い時間期間よりは終了時における完了が問題となり得るバッチ・ジョブと直接関係しない。その種のジョブのために、開示されたテクノロジは、『拡張間隔』ＱｏＳと呼ぶことができる、それらのバッチ・ジョブ用の異なる種類のＱｏＳ仕様が存在するという仮定を伴うことができる。１つの例示的な実施態様においては、拡張間隔ＱｏＳ仕様が、たとえばｎ時間スライスの後の時間区間の終了までにそのジョブが完了されないことになる許容失敗確度ｑを含むことができる。

ステップ４０２においては、バッチ・ジョブＱｏＳコントロール・アルゴリズムの実装（たとえば、図２のバッチ・ジョブＱｏＳコントロール・モジュール２１４または図３のバッチ・ジョブＱｏＳコントロール・モジュール３０６によって実装されるところのもの）が、あらかじめわかる所定のバッチ・ジョブの合計のデータ・センタ・リソース所要（たとえば、データ・センタ・リソース需要）がＴであることが既知であり、そのバッチ・ジョブのデッドライン（たとえば、バッチ・ジョブの完了のための）がｎ時間スライス内であり、かつ拡張間隔ＱｏＳ内における許容失敗がｑであるとの決定を最初に伴う。例示の目的のため、Ｔが、そのバッチ・ジョブによって必要とされる合計の計算リソースを表すと考えることができる。当業者は理解することになろうが、Ｔがディスク帯域幅またはネットワーク帯域幅等のそのほかのリソース所要も表すことが可能であるか、またはそれをバッチ・ジョブによってすべて必要とされるいくつかのリソース・タイプのベクトルとすることが可能である。

ステップ４０４においてはバッチ・ジョブＱｏＳコントロール・アルゴリズムの実装が、ｐとともに即時間隔ＱｏＳ内に提出されるべき、次の時間スライスのための初期データ・センタ・リソース予約Ｓを決定することが可能であり、これは、たとえばパッキングを容易にするためにｑよりはるかに大きく選択される入力パラメータである。例においては、その後バッチ・ジョブＱｏＳコントロール・モジュールが、各時間スライスについてのデータ・センタ・リソース予約Ｓを、次式に従って、失敗がｍまたはそれより少ないとする確度が、要求される成功レート（１‐ｑ）より大きいかまたは等しくなるような最少失敗数ｍを見つけることによって決定できる。

ステップ４０８においては、バッチ・ジョブＱｏＳコントロール・アルゴリズムの実装が、その時間スライスについての最終データ・センタ・リソース割り付けＳを、バッチ・ジョブがｍの失敗を伴うことはあっても完了するように、次式に従って決定できる。

したがってこの例においては、バッチ・ジョブＱｏＳコントロール・アルゴリズムの実装が、先行する時間スライスの中で何らかの進捗がなされたことを反映する残存リソース要件Ｔの新しい値に基づき、データ・センタ・リソース予約Ｓの決定を時間スライスごとに反復することができる。ステップ４０８においては、バッチ・ジョブＱｏＳコントロール・モジュールが、オプションとしてバッチ・ジョブの進捗に基づいてデータ・センタ・リソース予約Ｓを調整することができる。たとえば特定時間スライスの間にバッチ・ジョブがデータ・センタ・リソースの獲得に多数の失敗を積み重ねている場合に、バッチ・ジョブＱｏＳコントロール・モジュールは、そのバッチ・ジョブの完了を保証するために（たとえば、ジョブのデッドラインに応じて）データ・センタ・リソース予約Ｓを増加することが可能である。代替として、各時間スライスにわたってバッチ・ジョブが進捗している状況においては、バッチ・ジョブＱｏＳコントロール・モジュールが、データ・センタ・リソース予約Ｓを減少することが可能である。

この種のＳの閉ループ・コントロールは、いくつかの点において保守的であると考えることができる。第１に、バッチ・ジョブＱｏＳコントロール・モジュールは、特定の時間スライス内で即時ＱｏＳが失敗するときはＴにおける進捗がまったくなされていないと仮定して計画しており、実際に、バッチ・ジョブに提供されている部分的なデータ・センタ・リソースに関係する即時ＱｏＳの失敗がしばしば存在することになろう。第２に、Ｓを動的に修正することによってバッチ・ジョブＱｏＳコントロール・モジュールは、失敗の実際の確度を、Ｓの単一計算を用いる開ループ実行について概して正確である、上で論じた式によって予測されるところの確度より下に減少させることができる。

不確実なＴを含む例示的な実施態様

上で論じた実施態様は、ＱｏＳコントロール・モジュールの動作に先行してＴが既知であるという仮定を含んでいた。しかしながら概して、開示されたテクノロジの実装は、Ｔについての確率論的モデルを含む。したがってバッチ・ジョブＱｏＳコントロール・アルゴリズムを拡張し、Ｔに不確実性が存在する場合であっても『拡張間隔』ＱｏＳを達成することができる。たとえばＴの可能値の分布が決定可能であれば、システムは、その分布に照らしてどのようなＳがあるべきかを決定することが可能である。

Ｔに対するフィードバックを含む例示的な実施態様

特定の実施態様においては、バッチ・ジョブを、その進捗の動的な評価を提供するべく組み立てることが可能であり、そこから残存するＴの評価が計算できるか、またはその組み立てがバッチ・ジョブの実行に従って残存するＴの直接評価を提供することができる。その種の実施態様においては、そのようにＳの動的な計算の中に情報を含めることができる。

より精密なＳの計算を含む例示的な実施態様

上で論じた実施態様においては、ＱｏＳコントロール計画が、Ｓの計算が各時間スライスで反復される場合であっても概して残りの時間スライスにわたってＳが一定のままであるということを（保守的に）仮定している。しかしながらＳについての計画がＳに対する将来の閉ループ調整を考慮に入れると、さらに良好な性能を達成することが可能である。当業者は認識することになろうが、失敗の確度に等価の閉ループは、必ずしも閉じた形式である必要はなく、むしろ動的なプログラミングを介して計算が可能である。これは、都合よく、バッチ・ジョブＱｏＳコントロール・アルゴリズムの実装がわずかに保守的でなくなることを（たとえば、Ｓが以前の結果に属する情報に基づいて再調整されるという知識から）可能にし、それによってさらに多くのデータ・センタ・リソースを節約することができる。

Ｓおよびｐ両方の操作を含む例示的な実施態様

上で論じた実施態様においては、即時ＱｏＳ仕様が一定のｐを含み、Ｓに対する動的調整を行ってバッチ・ジョブが、それの拡張間隔ＱｏＳに従って完了されることを保証していた。代替実施態様は、変動するｐを即時ＱｏＳ内に含むことができる。たとえばシステムは、より大きなｐ（すなわち許容される失敗）を許しつつ、より多くのＳを各時間スライス内に割り付ける（すなわち、より大きなＳを求める）ことができる。その種の実装は、したがって、即時ＱｏＳ仕様のための解のパラメータ化されたファミリ（ｐ，Ｓ）の生成に使用することが可能である。これはいくつかの点で有利となり得る。

たとえば、バッチ・ジョブがそれの拡張間隔の終了に近づくに従って、バッチ・ジョブＱｏＳコントロール・モジュールは、Ｓを増加してジョブが完了することを保証できる。特定の時間スライスにおいて利用可能な（または使用可能な）データ・センタ・リソースの量に上限が存在する場合には、解のパラメータ化されたファミリが、そのジョブの完了の保証に求められるＳのサイズを制限するｐの減少を容易にすることが可能である。また、統計的パッキング・モジュールが（ｐ，Ｓ）に基づく原価計算を提供する場合には、バッチ・ジョブＱｏＳコントロール・モジュールが、解のパラメータ化されたファミリの中で（ｐ，Ｓ）の選択を最適化できる。統計的パッキング・モジュールからＱｏＳバッチ・コントロール・モジュールへのその種の『価格信号』は、好適に、これら２つのモジュールが良好な合併された最適化を達成することを、より複雑な組み合わせ最適化問題の解決を必要とすることなく可能にすることができる。

図５は、開示されたテクノロジの実施態様に従って３０の時間スライスの期間にわたりバッチ・ジョブのためにデータ・センタ・リソース予約Ｓを調整する第１の例を図解したグラフ５００である。この例において、各点は、対応する時間スライスについての（すなわち、ｘ軸に沿った）バッチ・ジョブのためのデータ・センタ・リソース割り付けＳを表す。実線はバッチ・ジョブの進捗を表し、１番目の時間スライスにおけるデータ・センタ・リソース所要が合計のデータ・センタ・リソース所要Ｔである。バッチ・ジョブが進捗するに従って、データ・センタ・リソース割り付けＳが、バッチ・ジョブによってなされた進捗に応答して調整される。この例においては、データ・センタ・リソース割り付けＳが、バッチ・ジョブがそれの完了のデッドラインに近づいていることから２０番目の時間スライスの当たりで顕著に増加しているが、データ・センタ・リソース割り付けＳの調整なしでは、デッドラインを満足する充分な進捗がなされない。

図６は、開示されたテクノロジの実施態様に従って３０の時間スライスの期間にわたりバッチ・ジョブのためにデータ・センタ・リソース予約Ｓを調整する第２の例を図解したグラフ６００である。図５の場合と同じく、図６のグラフ６００の各点は、対応する時間スライスについての（すなわち、ｘ軸に沿った）バッチ・ジョブのためのデータ・センタ・リソース割り付けＳを表す。バッチ・ジョブが進捗するに従って、データ・センタ・リソース割り付けＳが、バッチ・ジョブによってなされた進捗に応答して調整される。この例においては、データ・センタ・リソース割り付けＳがバッチ・ジョブの実行全体の間にわたって極めて一定に保たれており、特に５番目と１０番目の間の時間スライスでバッチ・ジョブに有意の進捗があると見られる。

１００ データ・センタ・アーキテクチャ、１０２ 物理デバイス、１０４ 仮想マシン、１０６ 局部コントローラ、１０８ 低レベル・モジュール，中央コントローラ、１１０ データ・ライン、１１２ 電力ライン、２００ データ・センタ最適化システム
、２０２ データ・センタ管理インターフェース、２０４ データ・センタ顧客登録モジュール、２０６ データ・センタ・リソース最適化モジュール、２０８ データ・センタ費用決定モジュール，データ・センタ顧客費用決定モジュール、２１０ 運用センタ
、２１２ データ・センタ・リソース利用モデル更新モジュール、２１４ バッチ・ジョブＱｏＳコントロール・モジュール、３０２ トランザクショナル・ジョブ、３０４ バッチ・ジョブ、３０６ バッチ・ジョブＱｏＳコントロール・モジュール、３０８ 統計的リソース・パッキング・モジュール。

Claims (4)

1. マシン・コントロール可能な方法であって、
   所定のバッチ・ジョブのための拡張間隔サービスの質（ＱｏＳ）仕様を決定するステップと、
   複数の時間スライスのうちの少なくとも第１の１つについて前記バッチ・ジョブのための残存データ・センタ・リソース要件を、前記拡張間隔ＱｏＳ仕様に少なくとも部分的に基づいて決定するステップと、
   前記バッチ・ジョブのための即時ＱｏＳ仕様を、前記残存データ・センタ・リソース要件に少なくとも部分的に基づいて決定するステップと、
   を含むマシン・コントロール可能な方法。
2. さらに、前記複数の時間スライスのうちの少なくとも第２の１つについて前記即時ＱｏＳ仕様を、前記バッチ・ジョブの進捗に少なくとも部分的に基づいて決定するステップを包含し、それにおいて前記複数の時間スライスのうちの前記第２の１つは、前記複数の時間スライスのうちの前記第１の１つの後であり、かつ前記バッチ・ジョブの完了時の前に生ずる、請求項１に記載のマシン・コントロール可能な方法。
3. 前記拡張間隔ＱｏＳ仕様を決定するステップは、失敗の許容確度ｑの決定を包含する、請求項１に記載のマシン・コントロール可能な方法。
4. 前記即時ＱｏＳ仕様を決定するステップは、データ・センタ・リソース予約Ｓの決定を含む、請求項１に記載のマシン・コントロール可能な方法。

Images