JP2013520734A - データ・センタにおける電力消費の最適化 - Google Patents

Abstract

【課題】動的な作業負荷調整によってデータ・センタの電力消費を最適化するためのシステムおよび関連する方法を提供する。
【解決手段】データ・センタの現在の作業負荷配分が、最小の電力消費量で、容認可能なレベルのサービスを提供する最適作業負荷ソリューションに移行される。最適作業負荷ソリューションに対応する電力コストおよび移行コストの合計額は、それぞれの作業負荷ソリューション候補に対応する合計額全ての間の最低値である。電力コストは、各作業負荷ソリューション候補に対するデータ・センタの最高温度およびそれに伴う冷房コストに基づいて算定される。移行コストは、データ・センタの作業負荷配分を、現在の作業負荷配分から各作業負荷ソリューション候補に移行する間に生じるパフォーマンス劣化に基づいて算定される。
【選択図】図１

Description

本発明は、データ・センタにおける電力消費を最適化することに関する。

本発明は、データ・センタ内の作業負荷配分を動的に調整することによって、データ・センタの電力消費を継続的に最適化するためのシステムおよび関連する方法を開示する。

従来型の電力消費最適化法は、デバイスの最大または銘板電力仕様を前提として、デバイスの物理的配置およびピーク温度だけに焦点を当てているが、デバイスの稼働率を考慮していないので、従来型の最適化法では、データ・センタの作業負荷に沿って動的且つ継続的に電力消費を最適化することができない。

本発明の一つの実施形態によれば、動的に作業負荷を調整することによってデータ・センタの電力消費を最適化する方法は：データ・センタからのインプットを受信するステップであって、データ・センタは少なくとも一つのデバイスを包含し、上記インプットは物理デバイス・マップおよび現行アプリケーション・マップを含み、物理デバイス・マップは、データ・センタ内の上記少なくとも一つのデバイスの三次元位置を特定し、現行アプリケーション・マップは、データ・センタのアプリケーション・プログラムが、上記少なくとも一つのデバイスにどのようにバーチャルにマップされているか、現在の作業負荷がアプリケーション・プログラムの間にどのように割り振られているかを明示している、上記受信するステップと；データ・センタに対する少なくとも一つの作業負荷ソリューション候補を生成するステップであって、上記少なくとも一つの作業負荷ソリューション候補の各作業負荷ソリューション候補は、上記少なくとも一つのデバイスへのアプリケーション・プログラムのそれぞれのバーチャル・マッピングおよびアプリケーション・プログラムの間へのそれぞれの作業負荷配分を規定する、それぞれのアプリケーション・マップを表している、上記生成するステップと；温度モデルを用いて上記各作業負荷ソリューション候補に対するそれぞれの温度プロフィールを計算するステップであって、それぞれの温度プロフィールに関連付けられたデータ・センタのそれぞれの最高温度に基づいて、上記各作業負荷ソリューション候補それぞれの電力コストが算定される、上記計算するステップと；データ・センタのパフォーマンス要求事項に対するそれぞれのパフォーマンス・プロフィールを評価するため、上記各作業負荷ソリューション候補に対するそれぞれのパフォーマンス・プロフィールを計算するステップであって、それぞれのパフォーマンス・プロフィールに基づいて、上記各作業負荷ソリューション候補それぞれの移行コストが算定される、上記計算するステップと；データ・センタの作業負荷を、現在の作業負荷配分から最適作業負荷ソリューションに動的に調整するステップであって、最適作業負荷ソリューションは、それぞれの電力コストとそれぞれの移行コストとの最低合計値を有する作業負荷ソリューション候補である、上記調整するステップと；を含む。

本発明の一つの実施形態によれば、コンピュータ・プログラム製品は、コンピュータ可読プログラム・コードを具現するコンピュータ可読メモリ・ユニットを含む。このコンピュータ可読プログラム・コードは、コンピュータ・システムのプロセッサによって実行されたとき、動的な作業負荷調整によってデータ・センタの電力消費を最適化する方法を実施する命令を包含する。

本発明の一つの実施形態によれば、コンピュータ・システムは、プロセッサとプロセッサに連結されたコンピュータ可読メモリ・ユニットとを含み、コンピュータ可読メモリ・ユニットは、プロセッサによって実行されたとき動的な作業負荷調整によってデータ・センタの電力消費を最適化する方法を実施する命令を包含する。

本発明の一つの実施形態によれば、コンピュータ・インフラストラクチャをサポートするプロセスが提供され、上記プロセスは、コンピューティング・システム中に、コンピュータ可読コードを生成、統合、ホスティング、維持、および展開することの少なくとも一つを行うための少なくとも一つのサポート・サービスを提供するステップを含み、該コードは、コンピューティング・システムと相まって、動的な作業負荷調整によってデータ・センタの電力消費を最適化する方法を実施する能力を有する。

単なる例示として、添付の図面を参照しながら本発明の実施形態を以下に説明する。

本発明の実施形態による、動的な作業負荷調整によってデータ・センタの電力消費を最適化するためのシステムを示す。 本発明の実施形態による、図１の温度プレディクタを示す。 本発明の実施形態による、動的な作業負荷調整によってデータ・センタの電力消費を最適化する方法を示すフローチャートであって、本方法は図１のシステムの電力オプチマイザによって遂行される。 本発明の実施形態による、データ・センタのデバイスの温度特性を予測する方法を表すフローチャートであり、これは電力オプチマイザの温度プレディクタによって遂行される。 本発明の実施形態による、電力オプチマイザの温度プレディクタの温度モデリング・フェーズを表すフローチャートである。 本発明の実施形態による、電力オプチマイザの温度プレディクタの温度予測フェーズを表すフローチャートである。 本発明の実施形態による、データ・センタのデバイスのパフォーマンスを予測する方法を表すフローチャートであり、これは電力オプチマイザのパフォーマンス・プレディクタによって遂行される。 本発明の実施形態による、データ・センタのデバイスの間で作業負荷を動的に調整する方法を表すフローチャートであり、これは電力オプチマイザの作業負荷アジャスタによって遂行される。 本発明の実施形態による、動的な作業負荷調整によってデータ・センタの電力消費を最適化するために用いられるコンピュータ・システムを示す。

図１は、本発明の実施形態による、動的な作業負荷調整によってデータ・センタの電力消費を最適化するためのシステム１０を示す。

システム１０は、データ・センタ１１、インプット２０、電力オプチマイザ３０、およびアウトプット８０を含む。インプット２０およびアウトプット８０はコンピュータ可読記憶媒体に格納される。コンピュータ可読記憶媒体の詳細につては、後記の図９のメモリ・デバイス９４、９５の説明を参照されたい。本明細書において、用語「電力」は、「電気」もしくは「電気エネルギ」またはその両方と互換的に用いられる。

データ・センタ１１は、物理的な部屋と、その物理的な部屋に所在し作動するハードウェアおよびソフトウェアとの集合として定義される。本明細書において、用語「ハードウェア」、「デバイス」、「設備」「機械装置」、「リソース」は互換的に用いられ、サーバ、記憶デバイス、通信デバイス、およびこれらの組み合わせなど、データ・センタ１１中の物理的機械装置の少なくとも一つを表す。データ・センタは、一般に、ウェブのホスティング、データ・ウェアハウスなどのシステム・サービスを提供するために用いられる。コンピュータ室空調装置（ＣＲＡＣ：Ｃｏｍｐｕｔｅｒ Ｒｏｏｍ Ａｉｒ Ｃｏｎｄｉｔｉｏｎｉｎｇ ｕｎｉｔ）とは、データ・センタ１１を冷房する一つ以上の冷房装置をいう。ＣＲＡＣは相当量の電力を費消し、その結果的データ・センタ１１に対する合計電力コストのかなりのパーセントを占める。データ・センタ１１内の室温は、いくつかのファクタにより場所によって異なる。

データ・センタ１１は、データ・センタ１１のさまざまなモニタリング／管理アプリケーションからのインプット２０を含む情報を集めるデータ収集インフラストラクチャ１２を含む。また、データ収集インフラストラクチャ１２は、データ・センタ１１がサービス・レベル目標（ＳＬＯ：Ｓｅｒｖｉｃｅ Ｌｅｖｅｌ Ｏｂｊｅｃｔｉｖｅｓ）を果たしているかどうかをユーザに通知するために、データ・センタ１１の使用状況情報を追跡する。ＳＬＯは、サービス・レベル契約（ＳＬＡ：ｓｅｒｖｉｃｅ ｌｅｖｅｌ ａｇｒｅｅｍｅｎｔ）の下にデータ・センタ１１によって提供されるそれぞれのサービスに対するサービス・パフォーマンスの要求レベルを定める。データ収集インフラストラクチャ１２の例には、とりわけて、ＩＢＭ（ＩＢＭ社の登録商標）のＭａｘｉｍｏ（ＩＢＭ社の登録商標）Ａｓｓｅｔ Ｍａｎａｇｅｍｅｎｔなどの従来型アセット・マネジメント・ソフトウェア、温度センサ・ネットワーク、ＩＢＭ（ＩＢＭ社の登録商標）のＴｏｔａｌＳｔｏｒａｇｅ（ＩＢＭ社の登録商標）Ｐｒｏｄｕｃｔｉｖｉｔｙ Ｃｅｎｔｅｒ（ＴＰＣ）データ収集インフラストラクチャ、およびこれらの組み合わせがあろう。（ＩＢＭ（ＩＢＭ社の登録商標）の ＭａｘｉｍｏおよびＴｏｔａｌＳｔｏｒａｇｅは、米国のインターナショナル・ビジネス・マシン・コーポレーションの登録商標である。）

インプット２０は、電力オプチマイザ３０がアウトプット８０を生成するため用いる諸ファクタを表している。インプット２０は、物理デバイス・マップ２１、デバイス温度プロフィール２２、デバイス設定２３、およびアプリケーション・マップ２４を含む。

物理デバイス・マップ２１は、データ・センタ１１の全デバイスの物理的レイアウト／配置を三次元（３Ｄ）座標（ｘ，ｙ，ｚ）形式で表現する。この３Ｄ座標は、データ・センタ１１内のラックに垂直にスタックされた各デバイスを正確に位置確認するために必要である。物理デバイス・マップ２１によって表現されたデータ・センタ１１中のデバイスの物理的レイアウトは、データ・センタ１１の熱力学および作動温度に影響与え、結果的に、データ・センタ１１の温度制御のために費消される電力の量に影響する。

デバイス温度プロフィール２２は、データ・センタ１１の各デバイスそれぞれの吸気口で測定された温度の集合を表す。デバイス温度プロフィール２２は、それぞれ３ＤマトリックスＴ（ｘ，ｙ，ｚ）＝ｔで表現され、ｔはデバイス（ｘ，ｙ，ｚ）の吸気口の温度を表す。

デバイス設定２３は、データ・センタ１１の各デバイスの設定を表す。本発明の一つの実施形態において、デバイス設定２３は、｛ＩＤ，ＴＥＭＰ｝を含み、このＩＤは、各デバイスがサーバまたは記憶デバイスかどうかを示す識別子であり、ＴＥＭＰは、各デバイスの、（ｉｄｌｅ（遊休中），ｂｕｓｙ（稼働中））から成るディスクリート表現の利用レベルに対するデバイスのそれぞれの温度である。デバイスが第一利用レベル「ｉｄｌｅ」にある場合、そのデバイスは基準温度にある。デバイスが第二利用レベル「ｂｕｓｙ」にある場合、そのデバイスはピーク温度にある。

アプリケーション・マップ２４は、アプリケーションがどのようにサーバおよび記憶デバイスにバーチャルにマップされているか、アプリケーションの作業負荷がどのようにデータ・センタ１１のデバイスの間に配分されているかに関する情報を表す。アプリケーション・マップ２４は、バーチャル・マシン（ＶＭ：ｖｉｒｔｕａｌ ｍａｃｈｉｎｅ）マップともいわれる。アプリケーション・マップ２４は、デバイスの使用状況を、合計アプリケーション作業負荷の関数として表現する。アプリケーション設定もしくは配置またはその両方の変更にともなって、マッピングの値が修正される。

電力オプチマイザ３０は、データ・センタ１１からインプット２０を取得し、最適化アプリケーション・マップ８１および予測電力節減量８２を含むアウトプット８０を生成する。電力オプチマイザ３０は、作業負荷ソリューション候補ジェネレータ３５、モデル・ジェネレータ４０および作業負荷アジャスタ７０を含む。電力オプチマイザ３０によって遂行されるステップについては、後記の図３の説明を参照されたい。

作業負荷ソリューション候補ジェネレータ３５は、少なくとも一つの作業負荷ソリューション候補、Ｘ_{ｃａｎｄｉｄａｔｅ}を生成し、これは、ある作業負荷のセットの、サーバおよび記憶装置のある組み合わせへのマッピングを示している。全ての作業負荷ソリューション候補に対し、この作業負荷のセットが当てはめられ、サーバおよび記憶装置を含むリソースの個別的な組み合わせに対してそれぞれのマッピングが作成される。電力オプチマイザ３０は、これらの作業負荷ソリューション候補を評価し、アウトプット８０の作業負荷配分を生成する。

モデル・ジェネレータ４０は、データ・センタ１１からインプット２０を取得し、予測モデルを生成する。これら予測モデルは、温度モデル、デバイス電力モデル、およびデバイス・パフォーマンス・モデルを含む。各予測モデルは、電力オプチマイザ３０が、各予測モデルに対する所定のパラメータのセットからそれぞれの予測結果を計算するため用いるコンピュータ実行可能算式のセットとして保管される。モデル・ジェネレータ４０は、インプット２０のデバイス設定２３およびアプリケーション・マップ２４を使って、デバイス電力モデルおよびデバイス・パフォーマンス・モデルを生成する。モデル・ジェネレータ４０は、温度プレディクタ５０およびパフォーマンス・プレディクタ６０を含む。

温度プレディクタ５０は、データ・センタ１１の温度を動的に予測する数学モデルである温度モデルを生成する。温度モデル中に取り入れられる温度ファクタの例には、とりわけ、それぞれのデバイスの吸気口温度などがあり得る。デバイス温度プロフィール２２中の最高のデバイス吸気口温度に基づいて、データ・センタ１１中の冷房ユニットの動作設定、冷房ユニットの作動効率、および結果として、データ・センタ１１を冷房するために費消される冷房コストおよび電力が算定される。各デバイスの吸気口温度は、とりわけ、物理デバイス・マップ２１に表されるデータ・センタ１１中のデバイスの物理的レイアウト、デバイス設定２３、アプリケーション・マップ２４に表される作業負荷配分に影響される。温度プレディクタ５０のコンポーネントについては後記の図２の説明を、温度プレディクタ５０によって遂行されるステップについては後記の図４の説明を参照されたい。

パフォーマンス・プレディクタ６０は、インプットとして、モデル・ジェネレータ４０によって生成されたデバイス・パフォーマンス・モデル、および作業負荷ソリューション候補ジェネレータ３５によって生成された作業負荷ソリューション候補群を取得する。パフォーマンス・プレディクタ６０は、各作業負荷ソリューション候補それぞれの予期されるパフォーマンスを含むアウトプットを生成する。パフォーマンス・プレディクタ６０によって遂行されるステップについては、後記の図７の説明を参照されたい。

作業負荷アジャスタ７０は、予測モデルおよび移行コスト・モデルを用いて、各作業負荷ソリューション候補それぞれのパフォーマンス、電力消費、および温度を評価し、最適化アプリケーション・マップ８１および予測電力節減量８２を含むアウトプット８０を生成する。最適化アプリケーション・マップ８１は、データ・センタ１１の電力消費を最適化する少なくとも一つの作業負荷配分を表現する。予測電力節減量８２は、最適化アプリケーション・マップ８１の各々のインスタンスにそれぞれ関連付けられた低減される電力消費の複数の量である。

作業負荷アジャスタ７０において、移行コスト・モデルは、パフォーマンス／電力／稼働率のトレードオフを捕捉し、現在の作業負荷配分から選定された作業負荷ソリューション候補への移行におけるパフォーマンスの低下を定量化し、データ・センタ１１のパフォーマンス要求事項を満たし、且つ最小の電力量を費消する作業負荷配分を見出す。本明細書において、用語「最適化」とは、データ・センタ１１のバーチャル化された設備の間で作業負荷を動的に調整し、同じレベルのサービスを提供しながら熱の生成をより少なくし、結果としてデータ・センタ１１における温度制御に必要な電力量を低減することを意味する。作業負荷アジャスタ７０によって遂行されるステップについては、後記の図８の説明を参照されたい。

図２は、本発明の実施形態による、上記の図１の温度プレディクタ５０を示す。

温度プレディクタは、データ・センタからの物理デバイス・マップ、デバイス設定、およびアプリケーション・マップから、少なくとも一つのサンプル・データを生成する。上記少なくとも一つのサンプル・データの第一ペア・サンプル・データ（Ｐ１，Ｆ１）は、第一サンプル電力プロフィールＰ１および第一サンプル・フロー・プロフィールＦ１を含む。第一サンプル電力プロフィールＰ１は、データ・センタの個別デバイス群による電力消費量を含む、データ・センタの電力消費のサンプル・インスタンスを表す。第一サンプル・フロー・プロフィールＦ１は、データ・センタのデバイスの使用状況に基づく、データ・センタ内のサンプル熱フローを表す。第一ペア・サンプル・データ（Ｐ１，Ｆ１）は、熱力学をシミュレートする目的のためそれぞれ現実的な値の範囲で、ランダムに生成される。

計算流体力学（ＣＦＤ：ｃｏｍｐｕｔａｔｉｏｎａｌ ｆｌｕｉｄ ｄｙｎａｍｉｃｓ）シミュレータ５１は、インプットとして複数のサンプル・データ・ペア（Ｐｎ，Ｆｎ）を取り、サンプル・データ（Ｐｎ，Ｆｎ）の各ペアに対応する、複数のサンプル温度プロフィールＴｎを生成する。第一サンプル温度プロフィールＴ１は、データ・センタの電力消費および熱フローが第一サンプル・データ・ペア（Ｐ１，Ｆ１）によって与えられる場合の、データ・センタにおける個別デバイスのシミュレートされた吸気口温度のセットを表す。各サンプル温度プロフィールは、データ・センタからのインプットのデバイス温度プロフィールと同じ様式で表現され、その温度は、デバイス温度プロフィールにあるようなデータ・センタからの実際に測定された温度の代わりに、ＣＦＤシミュレータ５１によってシミュレートされている。ＣＦＤシミュレータ５１は、複数のサンプル・データ・ペアを用い、サンプル・データの各ペアにそれぞれ対応する複数の温度プロフィールをシミュレートし、熱力学モデル設定に十分な大きさのデータ・セットを生成する。

サポート・ベクトル・マシン（ＳＶＭ：ｓｕｐｐｏｒｔ ｖｅｃｔｏｒ ｍａｃｈｉｎｅ）ラーナー５２は、生成済みのサンプル・データ（Ｐｎ，Ｆｎ）と生成済みのサンプル・データＴｎに対応するシミュレート・サンプル温度プロフィールとから、温度モデル５３を生成する。サンプル・データの全ペアおよび対応するサンプル温度プロフィールは、包括的にＳＶＭラーナー５２に対するトレーニング・データといわれる。温度モデル５３は、ＳＶＭラーナー５２によるトレーニング・データからの学習に沿って、データ・センタの電力消費および全体的な熱フローが、データ・センタ中の個別デバイスの吸気口温度にどのように影響するかを公式化する。

実際データのペア（Ｐ，Ｆ）は、電力プロフィールＰおよび対応するフロー・プロフィールＦを含む。電力プロフィールＰは、データ・センタの個別デバイスから測定された電力消費量を含む、データ・センタの電力消費の実際のインスタンスを表す。フロー・プロフィールＦは、電力プロフィールＰに対応する、データ・センタのデバイス群の使用状況によって定まる、データ・センタ内で測定される熱フローの実際のインスタンスを表す。

サポート・ベクトル・マシン（ＳＶＭ）プレディクタ５４は、温度モデル５３を実際のデータ（Ｐ，Ｆ）ペアに適用し、データ・センタの電力消費および熱フローが実際のデータ（Ｐ，Ｆ）ペアで表されるとき、温度モデル５３から予測されるデータ・センタの個別デバイスのそれぞれの吸入口温度を表現する温度プロフィールＴを生成する。

図３は、本発明の実施形態による、動的な作業負荷調整によってデータ・センタの電力消費を最適化する方法を示すフローチャートであって、本方法は上記の図１のシステムの電力オプチマイザによって遂行される。

ステップ３００において、電力オプチマイザは、データ・センタからインプットを受信し、モデル・ジェネレータを使って少なくとも一つのデバイス電力モデルおよび少なくとも一つのデバイス・パフォーマンス・モデルを生成する。データ・センタから収集されたインプットは、上記の図１で説明したように、物理デバイス・マップ、デバイス温度プロフィール、デバイス設定、およびアプリケーション・マップを含む。モデル・ジェネレータは、インプットのデバイス設定およびアプリケーション・マップを使い、電力モデリングに対する従来型の方法を用いて、上記少なくとも一つのデバイス電力モデルを生成する。また、モデル・ジェネレータは、パフォーマンス・モデリングに対する従来型の方法に基づいて、各デバイス種類に対し上記少なくとも一つのデバイス・パフォーマンス・モデルを生成する。インプットのデバイス設定およびアプリケーション・マップによって表される特定のプラットフォーム中のデバイス・パフォーマンス・モデルの使用については、後記の図７のパフォーマンス・プレディクタの説明を参照されたい。次いで、電力オプチマイザはステップ３１０に進む。

本発明の一つの実施形態において、モデル・ジェネレータは、コンピューティング・デバイスの電力モデルおよび記憶デバイスの電力モデルを含む２つのデバイス電力モデルを生成する。本明細書において、用語「利用率」はデバイスが取り扱える最高作業負荷に対する現在の作業負荷の比率をいう。デバイスの利用率には、その率の範囲に応じて｛ｉｄｌｅ，ｂｕｓｙ｝から選定された値を持たせることができる。コンピューティング・デバイスの電力モデルは、主として計算を遂行するコンピューティング・デバイスの利用率に応じたコンピューティング・デバイスの電力消費を表現する。コンピューティング・デバイスの例には、とりわけて、サーバなどが挙げられる。コンピューティング・デバイスの利用率が「ｉｄｌｅ」のときのコンピューティング・デバイスの電力消費が１００であれば、コンピューティング・デバイス電力モデルは、コンピューティング・デバイスが「ｂｕｓｙ」のときのコンピューティング・デバイスの電力消費を１３０〜１４０の範囲の数値によって定量化する。記憶デバイスの電力モデルは、主としてデータ・オペレーションを遂行する記憶デバイスの利用率に応じた記憶デバイスの電力消費を表現する。記憶デバイスの例には、とりわけて、ディスク・アレイなどが挙げられる。記憶デバイスが「ｉｄｌｅ」のときの記憶デバイスの電力消費が１００であれば、記憶デバイス電力モデルは、記憶デバイスが「ｂｕｓｙ」のときの記憶デバイスの電力消費を１１０〜１３０の範囲の数値によって定量化する。

同じ実施形態において、各デバイス電力モデルは、それぞれのデバイスが「ｉｄｌｅ」のときの電力消費を表す静的な値と、それぞれのデバイスがオペレーションを遂行しているとき、すなわち、それぞれのデバイスが「ｂｕｓｙ」であり、それぞれのデバイスの利用率によってリニアに変化しているときの電力消費を表す第二の変数とを含む、少なくとも２つのコンポーネントを有する。

ステップ３１０で、電力オプチマイザは、作業負荷ソリューション候補ジェネレータを使って、現在の作業負荷の配分に対する作業負荷のセットを複数の異なったデバイス設定にマップする、作業負荷ソリューション候補群を生成する。プラットフォームで利用可能な、異なった数のサーバ／記憶装置ペアの可能な全ての組み合わせが、作業負荷ソリューション候補のデバイス設定として採用される。また、作業負荷ソリューション候補ジェネレータは、領域知識に基づいて、ヒューリスティック／ベストプラクティスなデバイス設定を用いて、作業負荷ソリューション候補を生成する。これら作業負荷ソリューション候補は、温度プレディクタおよびパフォーマンス・プレディクタが利用可能な状態にされる。次いで、電力オプチマイザはステップ３２０および３３０に進み、これらスのテップは同時に実行される。

ステップ３２０において、電力オプチマイザは温度プレディクタを実行する。温度プレディクタは、物理デバイス・マップ、デバイス温度ファイル、およびデバイス電力モデルのインプットを得て、各作業負荷ソリューション候補に対し、それぞれのデータ・センタ温度プロフィールを生成する。温度プレディクタの詳細については後記の図４の説明を参照されたい。次いで電力オプチマイザはステップ３４０に進む。

ステップ３３０で、電力オプチマイザはパフォーマンス・プレディクタを実行する。パフォーマンス・プレディクタは、デバイス・パフォーマンス・モデルを生成し、パフォーマンス予測算式、および各作業負荷ソリューション候補に対するそれぞれの予測パフォーマンスを生成する。パフォーマンス・プレディクタの詳細については後記の図７の説明を参照されたい。次いで電力オプチマイザはステップ３４０に進む。

ステップ３４０において、電力オプチマイザは、作業負荷アジャスタを実行する。作業負荷アジャスタは、各作業負荷ソリューション候補に対する、それぞれのデータ・センタ温度プロフィールおよびそれぞれの予測パフォーマンスを得て、少なくとも一つの最適化作業負荷配分およびそれぞれの最適化作業負荷配分に対応する電力節減量を含むアウトプットを生成する。作業負荷アジャスタの詳細については後記の図８の説明を参照されたい。次いで電力オプチマイザはステップ３５０に進む。

ステップ３５０で、電力オプチマイザは、作業負荷アジャスタによって生成されたアウトプットを格納し、ユーザに送信する。このユーザは、とりわけて、データ・センタの管理者などであり得る。ユーザは、続いて、このアウトプットを用いて、とりわけて、作業負荷配分を調整し、データ・センタの現在ステータスを反映したインプットを含めてデータ・センタの情報を更新する。次いで、電力オプチマイザが終了する。

図４は、本発明の実施形態による、データ・センタのデバイスの温度特性を予測する方法を表すフローチャートであり、これは電力オプチマイザの温度プレディクタによって遂行される。

温度プレディクタは２つのフェーズで動作する。ステップ５００において、温度プレディクタは、電力オプチマイザのための温度モデルが既に生成されているかどうかを判定する。温度プレディクタがまだ温度モデルが存在しないと判定した場合、温度プレディクタは、ステップ５１０に進み、トレーニング・サンプルから温度モデルを生成する第一フェーズから開始する。温度プレディクタが既に温度モデルは存在すると判定した場合、温度プレディクタは、ステップ５５０に進み、上記のステップ３１０からの作業負荷ソリューション候補に対する温度を予測する第二フェーズから開始する。

ステップ５１０で、温度プレディクタは、温度モデリング・フェーズといわれる第一フェーズのオペレーションを遂行する。温度モデリング・フェーズの詳細については後記の図５の説明を参照されたい。

ステップ５５０において、温度プレディクタは、温度予測フェーズといわれる第二フェーズのオペレーションを遂行する。温度予測フェーズの詳細については後記の図６の説明を参照されたい。

図５は、本発明の実施形態による、電力オプチマイザの温度プレディクタの温度モデリング・フェーズを表すフローチャートである。

ステップ５２０において、温度プレディクタは、インプットからの物理デバイス・マップ、デバイス温度プロフィール、およびモデル・ジェネレータからのデータ・センタの電力モデルを読み取る。物理デバイス・マップおよびデバイス温度プロフィールは、インプットから電力オプチマイザが利用できるようになっている。データ・センタの電力モデルは、電力プロフィールと組み合わせたそれぞれのデバイスの使用状況を考慮に入れた、シミュレーションまたは解析的アプローチに基づいている。電力モデルは、データ・センタのさまざまなデバイスによってそれぞれのデバイスの電力モデルに従って費消される電力を表す、データ・センタに対する三次元マトリックスとして定義される。ステップ５２０の後、温度プレディクタはステップ５３０に進む。

ステップ５３０において、温度プレディクタは、それぞれサンプル・データのペアに対応する、サンプル電力プロフィール、およびサンプル・フロー・プロフィール、およびサンプル吸気口温度プロフィールを包含するサンプル・ペアのデータを含む、トレーニング・サンプルを生成する。温度プレディクタは、サンプリングによって複数のサンプル・データ・ペア（電力プロフィールＰｎ，フロー・プロフィールＦｎ）を最初に生成し、次いで、従来型の計算流体力学（ＣＦＤ）シミュレータを使い、サンプル電力プロフィールおよびサンプル・フロー・プロフィールをシミュレートすることによって、対応するサンプル吸気口温度プロフィールを生成する。各サンプル電力プロフィールは、データ・センタのそれぞれの電力消費を表現する。このそれぞれの電力消費は、データ・センタの各デバイスにより生成される熱の量として表すことができる。各サンプル・フロー・プロフィールは、データ・センタの各デバイス中のファンそれぞれの流量を表す。これらトレーニング・サンプルはステップ５４０で利用できるようにされる。次いで、温度プレディクタはステップ５４０に進む。

本発明の一つの実施形態において、温度プレディクタは、ＦｌｏＶＥＮＴ（Ｒ）計算流体力学（ＣＦＤ）シミュレータを用いて、サンプル電力プロフィールおよびサンプル・フロー・プロフィールから、サンプル吸気口温度プロフィールを生成する。（ＦｌｏＶＥＮＴは、米国のＭｅｎｔｏｒ Ｇｒａｐｈｉｃｓ Ｃｏｒｐｏｒａｔｉｏｎの登録商標である。）

ステップ５４０において、温度プレディクタは、ステップ５３０で生成されたトレーニング・サンプルに対しマシン学習プロセスを適用して、温度モデルを生成する。この温度モデルは、データ・センタ中の全デバイスのシミュレートされた総体的な温度挙動を示す。この温度モデルは、電力プロフィールおよびフロー・プロフィール中のパラメータを吸気口温度プロフィール中の各吸気口温度にマップする、関数のセットとして表される。次いで、温度プレディクタは、温度プレディクタの第二フェーズに対する上記の図４のステップ５５０に進む。

本発明の一つの実施形態において、ステップ５３０のマシン学習プロセスは、前述のＦｌｏＶＥＮＴ（Ｒ）シミュレーションを使って導出された、大きなデータ・セットからの温度モデルの数学関数を展開するサポート・ベクトル・マシン（ＳＶＭ：Ｓｕｐｐｏｒｔ Ｖｅｃｔｏｒ Ｍａｃｈｉｎｅ）ラーナーである。

図６は、本発明の実施形態による、電力オプチマイザの温度プレディクタの温度予測フェーズを表すフローチャートである。

ステップ５６０で、温度プレディクタは、上記の図３ステップ３１０で生成された作業負荷ソリューション候補を受信する。次いで、温度プレディクタはステップ５７０に進む。

ステップ５７０において、温度プレディクタは、上記のステップ５１０で生成された温度モデルに従い、サポート・ベクトル・マシン（ＳＶＭ）プレディクタを使って、作業負荷ソリューション候補に対するデータ・センタの温度プロフィールを計算する。サポート・ベクトル・マシンは、分類および回帰のため使われる、関連する管理方式の従来型学習方法のセットであり、これは、入力データをｎ次元空間のベクトルの２つのデータ・セットと見なし、このｎ次元空間に、分離超平面が２つのデータ・セットの間のマージンを最大化するように該分離超平面を構築する。温度プレディクタは、データ・センタの温度プロフィールを、物理リソースのマッピングへのアプリケーションもしくはバーチャル・マシンまたはその両方の関数として公式化し、温度プレディクタは、作業負荷ソリューション候補のデータ・センタのデバイスに対する作業負荷値および物理デバイス・マップから、データ・センタの温度プロフィールを計算する。次いで、温度プレディクタは終了し、電力オプチマイザは上記の図３のステップ３４０の作業負荷アジャスタに進む。

図７は、本発明の実施形態による、データ・センタのデバイスのパフォーマンスを予測する方法を表すフローチャートであり、これは電力オプチマイザのパフォーマンス・プレディクタによって遂行される。

ステップ６１０において、パフォーマンス・プレディクタは、ステップ３００で生成されたデバイス・パフォーマンス・モデル、並びにデータ・センタのデバイス設定およびアプリケーション・マップを含む、パフォーマンス特性に関するインプットを読み取る。デバイス設定およびアプリケーション・マップは、プラットフォーム上のアプリケーションのパフォーマンスに影響するものであり、プラットフォーム上のアプリケーションのパフォーマンス予測モデルを生成するために用いられる。プラットフォームは、少なくとも一つのサーバおよび少なくとも一つの記憶デバイスを包含する。本明細書では、用語「サーバ」は、用語「コンピュータ・デバイス」と互換的に使われる。デバイス設定は、プラットフォーム中の諸デバイスがどのように設定されているかを表し、アプリケーション・マップは、アプリケーションの作業負荷がプラットフォーム上にどのように配分されているかを表す。プラットフォームの各コンポーネント・デバイスは、上記の図３のステップ３００で生成されたそれぞれのデバイス・パフォーマンス・モデルに対応する。次いで、パフォーマンス・プレディクタはステップ６２０に進む。

ステップ６２０において、パフォーマンス・プレディクタは、パフォーマンス予測モデルを構築し、これは、プラットフォームのパフォーマンス特性のインプットおよびデバイス・パフォーマンス・モデルから導出される。パフォーマンス予測モデルは、プラットフォームのパフォーマンス特性インプットの変動値に適用が可能である。例えば、プラットフォームのデバイス設定が（２サーバ，２記憶装置）である場合、このデバイス設定からのパフォーマンス予測モデルを利用して、このプラットフォームの全ての可能なデバイス設定、とりわけて、（１サーバ，１記憶装置）、（１サーバ，２記憶装置）、（２サーバ，１記憶装置）、および（２サーバ，２記憶装置）のパフォーマンスが予測される。電力オプチマイザは、上記の図３のステップ３１０で生成された各作業負荷ソリューション候補の評価にこのパフォーマンス予測モデルを用いる。各電力最適化ソリューション候補の評価の詳細については、後記の図８の説明を参照されたい。次いで、パフォーマンス・プレディクタはステップ６３０に進む。

後記の式１〜式４の本発明のパフォーマンス予測モデルは、データ・センタのパフォーマンスを予測するに際して、作業負荷の実行速度ともいわれる作業負荷特性を以下のように考慮に入れている。

上式のＩＰＳ（Ｗ）は作業負荷Ｗの秒あたりの命令数（Ｉｎｓｔｒｕｃｔｉｏｎｓ Ｐｅｒ Ｓｅｃｏｎｄ）を表し、ｆｒｅｑｕｅｎｃｙはデバイスの動作周波数を示し、ＣＰＩ（Ｗ）は作業負荷Ｗの命令当たりのサイクル数（Ｃｙｃｌｅｓ Ｐｅｒ Ｉｎｓｔｒｕｃｔｉｏｎ）を表し、ＣＰＩ_ｃｏｒｅは、キャッシュを含めプロセッサのコアで費やされる命令当たりのサイクル数を表し、ＣＰＩ_{ｍｅｍｏｒｙ}はメモリ・アクセスに費やされる命令当たりのサイクル数を表す。ＩＰＳ（Ｗ）で計測されるパフォーマンスは、サービス・レベル契約（ＳＬＡ）で定められる測定指標である。プラットフォームが設定され、それぞれのデバイスに対するデバイス動作周波数が定まれば、ＣＰＩ（Ｗ）によってＩＰＳ（Ｗ）が算定される。

ＣＰＩ_ｃｏｒｅは、プロセッサの動作周波数からは独立しているが、ＣＰＩ_{ｍｅｍｏｒｙ}は以下のようにメモリ・デバイス動作周波数の影響を受ける。
ＣＰＩ_ｃｏｒｅ＝ＣＰＩ（ｆ_１）（Ｗ）＝ＣＰＩ_ｃｏｒｅ（ｆ_１）＋ＭＰＩ×Ｍ_{ｌａｔｅｎｃｙ}×ＢＦ（ｆ_１） ［式３］
ＣＰＩ_{ｍｅｍｏｒｙ}＝ＣＰＩ（ｆ_２）（Ｗ）＝ＣＰＩ_ｃｏｒｅ（ｆ_１）＋ＭＰＩ×Ｍ_{ｌａｔｅｎｃｙ}×（ｆ_２／ｆ_１）×ＢＦ（ｆ_１） ［式４］
上式のｆ_１はサーバの第一動作周波数であり、ｆ_２は記憶デバイスの第二動作周波数であり、ＭＰＩは命令当たりのメモリ・アクセスの回数を示し、Ｍ_{ｌａｔｅｎｃｙ}は、メモリ・アクセスのためのメモリ・アドレスの発行からメモリ・アドレスのデータが利用可能になるまでの経過時間であるメモリ待ち時間であり、ＢＦは、メモリ・アクセスおよびコア処理における並列処理を定量化したブロック因子であり、メモリの単一ブロック内の固定サイズのレコードの数を表す。

パフォーマンス・プレディクタは、上記の式１〜式４のパフォーマンス予測モデルを用い、いろいろなメモリの種類、キャッシュ・サイズなどで構成されるさまざまなプラットフォームに対する作業負荷の挙動を予測する。従来型のパフォーマンス・モデルは、同じような均質に計算バウンドされた作業負荷を、異なるクロック速度、異なるメモリ・サイズおよびキャッシュ・サイズの個別的なプロセッサを含むさまざまなシステム設定上でどのように実行するかに焦点が置かれている。

また、パフォーマンス・プレディクタは、デバイスの作業負荷および動作周波数に加えて、インプットのデバイス設定によって提供される、それぞれのサーバ・システムに対して異なる種類の記憶デバイスが組み合わされた、それぞれのアーキテクチャ上の細部が異なる複数の個別的サーバ・システムにも対応する。パフォーマンス・プレディクタは、限定された数のサーバ・アーキテクチャを選択し、それぞれのサーバ・アーキテクチャを上記の式１〜式４のパフォーマンス予測モデルに適用する。選択されたそれぞれのサーバ・アーキテクチャは、複数のサーバを有し得る。異種のサーバおよび記憶デバイスの組み合わせに対するパフォーマンス予測モデルは次の式で表される。

上式のＩＰＳ（Ｗ）（ｓ，ｄ_ｉ）は、固定サーバ設定ｓおよび第ｉの記憶デバイス設定ｄ_ｉを備えるプラットフォームにおける、作業負荷Ｗに対する秒当たりの命令数を示し、ＣＰＩ（Ｗ）（ｓ，ｄ_ｉ）は、固定サーバ設定ｓおよび第ｉの記憶デバイス設定ｄ_ｉを備えるプラットフォームにおける、作業負荷Ｗに対する命令当たりのサイクル数を示し、ｓ_{ｆｒｅｑｕｅｎｃｙ}は、固定サーバ設定ｓ中に表されているサーバの第三動作周波数を示す。

式２Ａにおいて、ＣＰＩ（Ｗ）は、作業負荷Ｗに対する命令当たりのサイクル数を表し、これは、プラットフォーム中の全記憶デバイス設定に対し、固定サーバ設定ｓおよび第ｉ記憶デバイス設定ｄ_ｉを用いて設定されたプラットフォームにおけるＣＰＩ_{ｓｅｒｖｅｒ}およびＣＰＩ_{ｓｔｏｒａｇｅ}の和として算定される。ＣＰＩ_{ｓｅｒｖｅｒ}は、ディスクへのアクセスなくして、作業負荷Ｗをメモリから全て実行できた場合の、プラットフォーム中のサーバによって費やされるサイクル数を表す。ＣＰＩ_{ｓｅｒｖｅｒ}は、システム周波数および記憶装置設定から独立した一切の作業負荷に対する命令当たりのサイクル数ＣＰＩ_{ｓｅｒｖｅｒ}を示す。ＣＰＩ_{ｓｔｏｒａｇｅ}は、プラットフォーム中の記憶デバイスによって費やされたサイクル数を表す。ＣＰＩ_{ｓｔｏｒａｇｅ}は、作業負荷を処理するためのサイクル数、ＣＰＩ（Ｗ）への記憶装置の特性の影響を表す。ＣＰＩ_{ｓｔｏｒａｇｅ}として挙げられる記憶装置の特性には、とりわけ、待ち時間、処理容量、ディスクのブロック因子において測定される並列処理などがあろう。パフォーマンス・プレディクタは、最初に各種の作業負荷に対するＣＰＩ_{ｓｔｏｒａｇｅ}を特性設定し、異なる記憶装置設定を有する同じサーバ上の、同じ作業負荷Ｗのパフォーマンスを予測する。

本発明の一つの実施形態において、サーバによって費消されるサイクル数および記憶デバイスに費消されるサイクル数は以下のように公式化される。
ＣＰＩ_{ｓｅｒｖｅｒ}（ｓ，ｄ_ｉ）＝ＣＰＩ_{ｓｅｒｖｅｒ}（ｓ） ［式３Ａ］
ＣＰＩ_{ｓｔｏｒａｇｅ}（ｓ，ｄ_ｉ）＝ＤＩＯＰＩ×Ａｖｇ（ＬＵＮ_{ｌａｔｅｎｃｙ}（ｄ_ｉ）（Ｗ））×ＤＢＦ ［式４Ａ］
上式のＤＩＯＰＩは、命令当たりのディスク入力／出力の回数を示し、Ａｖｇ（ＬＵＮ_{ｌａｔｅｎｃｙ}（ｄ_ｉ）（Ｗ））は、作業負荷Ｗに対する第ｉ記憶デバイス設定ｄ_ｉ中のそれぞれの論理ボリューム・ユニットの待ち時間の平均を示す。それぞれの論理ボリューム・ユニットの待ち時間（ＬＵＮ_{ｌａｔｅｎｃｙ}）は、記憶装置設定パラメータおよび作業負荷の特性の関数である。記憶装置設定パラメータの例には、とりわけて、構成ディスクの待ち時間、構成ディスクの数、構成ディスクのランダム／シーケンシャルな処理容量、キャッシュ・サイズなどがあろう。作業負荷の特性の例には、とりわけて、ランダム性、連続性、キャッシュ・ヒット率などがあり得る。ＬＵＮ_{ｌａｔｅｎｃｙ}は、プラットフォームのパフォーマンスに影響する主要設定パラメータであり、パフォーマンス・プレディクタによってＬＵＮ_{ｌａｔｅｎｃｙ}の回帰モデルが用いられる。

本発明の別の実施形態において、ステップ６１０および６２０を、モデル・ジェネレータによって遂行することができる。同じ実施形態において、パフォーマンス・プレディクタは、インプットとして、モデル・ジェネレータによって生成された少なくとも一つのパフォーマンス予測モデルを取得し、以下のステップ６３０で説明するように、データ・センタの予期されるパフォーマンス値を生成する。

ステップ６３０において、パフォーマンス・プレディクタは、それぞれのプラットフォーム設定に関連する各作業負荷ソリューション候補それぞれのパフォーマンスを予測する。パフォーマンス・プレディクタは、パフォーマンス予測モデルを、インプットのパフォーマンス特性、作業負荷ソリューション候補、および各作業負荷ソリューション候補それぞれのプラットフォーム設定に適用する。予測されたパフォーマンスは、秒当たりの命令数（ＩＰＳ）などに定量化される。次いでパフォーマンス・プレディクタはステップ６４０に進む。

ステップ６４０で、パフォーマンス・プレディクタは、全ての作業負荷ソリューション候補に対し予測されたパフォーマンスをメモリ・デバイスに格納し、作業負荷アジャスタが利用できるようにする。次いで、パフォーマンス・プレディクタは終了し、電力オプチマイザは、上記の図３のステップ３４０へと続く。

図８は、本発明の実施形態による、データ・センタのデバイスの間で作業負荷を動的に調整する方法を表すフローチャートであり、これは電力オプチマイザの作業負荷アジャスタによって遂行される。

ステップ７１０において、作業負荷アジャスタは、パフォーマンス・プレディクタからの、全ての作業負荷ソリューション候補に対する予測パフォーマンスを読み取る。作業負荷アジャスタはステップ７２０に進む。

ステップ７２０で、作業負荷アジャスタは上記の図３のステップ３１０で生成された各作業負荷ソリューション候補の電力コスト、および各作業負荷ソリューション候補に対する、現在の作業負荷配分Ｘ_{ｃｕｒｒｅｎｔ}からの移行コストを見積もる。次いで作業負荷アジャスタはアテープ７３０に進む。

作業負荷ソリューション候補Ｘ_{ｃａｎｄｉｄａｔｅ}の電力コストは、作業負荷ソリューション候補Ｘ_{ｃａｎｄｉｄａｔｅ}中の全コンポーネント・デバイスのコンポーネント・レベルでの電力使用量の累積、および作業負荷ソリューション候補Ｘ_{ｃａｎｄｉｄａｔｅ}に対し予測される冷房コストの和として計算される。すなわち、
ＰｏｗｅｒＣｏｓｔ（電力コスト）（Ｘ_{ｃａｎｄｉｄａｔｅ}）＝ＴｏｔａｌＣｏｍｐｏｎｅｎｔＰｏｗｅｒＵｓａｇｅ（合計コンポーネント電力使用量）（Ｘ_{ｃａｎｄｉｄａｔｅ}）＋ＣｏｏｌｉｎｇＣｏｓｔ（冷房コスト）（Ｘ_{ｃａｎｄｉｄａｔｅ}）
上式のＴｏｔａｌＣｏｍｐｏｎｅｎｔＰｏｗｅｒＵｓａｇｅ（Ｘ_{ｃａｎｄｉｄａｔｅ}）は、それぞれのデバイス電力モデルに従って作業負荷ソリューション候補Ｘ_{ｃａｎｄｉｄａｔｅ}中に採用されたデバイスの利用率レベルに基づいた、作業負荷ソリューション候補Ｘ_{ｃａｎｄｉｄａｔｅ}の全コンポーネントの電力使用量の合計であり、ＣｏｏｌｉｎｇＣｏｓｔ（Ｘ_{ｃａｎｄｉｄａｔｅ}）は、上記の図４の温度プレディクタによる作業負荷ソリューション候補Ｘ_{ｃａｎｄｉｄａｔｅ}に対するデータ・センタの予測最高温度から計算される。

作業負荷ソリューション候補Ｘ_{ｃａｎｄｉｄａｔｅ}の、現在の作業負荷配分Ｘ_{ｃｕｒｒｅｎｔ}からの移行コストは、作業負荷ソリューション候補Ｘ_{ｃａｎｄｉｄａｔｅ}の作業負荷の特性にそれぞれの移行コスト・モデル、および作業負荷ソリューション候補Ｘ_{ｃａｎｄｉｄａｔｅ}中に用いられるデバイスに対するデバイス電力モデルから計算される。移行コストは、デバイス電力モデルおよびデバイス・パフォーマンス・モデルに基づいて、現在の作業負荷配分Ｘ_{ｃｕｒｒｅｎｔ}から作業負荷ソリューション候補Ｘ_{ｃａｎｄｉｄａｔｅ}への移行の間のサービスのパフォーマンス劣化もしくは喪失またはその両方を定量化する。作業負荷特性は、とりわけて、移行の間のパフォーマンス劣化の許容レベルを定めるサービス・レベル目標（ＳＬＯ）要求事項、稼働率、および作業負荷のパフォーマンス要求事項などとすることができる。作業負荷特性は、関与するさまざまな種類の作業負荷およびアプリケーションに対する個別的パフォーマンス要求事項が反映して決められる。

本発明の一つの実施形態において、データ・センタのプロダクション・システムにおけるより高いパフォーマンス要求事項によって、作業負荷移行はさらに厳しく制限される。完全に近い稼働率要求事項に起因して、プロダクション・システムのあるアプリケーションが、移行中のパフォーマンス劣化を許容しないことがある。

ステップ７３０において、作業負荷アジャスタは、各作業負荷ソリューション候補に対する全体的コストを計算する。次いで、作業負荷アジャスタはステップ７４０に進む。

作業負荷ソリューション候補Ｘ_{ｃａｎｄｉｄａｔｅ}の全体的コストは、作業負荷ソリューション候補Ｘ_{ｃａｎｄｉｄａｔｅ}の電力コストと、作業負荷ソリューション候補Ｘ_{ｃａｎｄｉｄａｔｅ}の移行コストとの和である。すなわち、
ＯｖｅｒａｌｌＣｏｓｔ（全体的コスト）（Ｘ_{ｃａｎｄｉｄａｔｅ}） ＝ ＰｏｗｅｒＣｏｓｔ（電力コスト）（Ｘ_{ｃａｎｄｉｄａｔｅ}）＋ＭｉｇｒａｔｉｏｎＣｏｓｔ（移行コスト）（Ｘ_{ｃａｎｄｉｄａｔｅ}）。

ステップ７４０において、作業負荷アジャスタは、全作業負荷ソリューション候補の中で最小の全体的コストを有する、最適作業負荷ソリューションＸ_{ｏｐｔｉｍａｌ}を選定する。別の実施形態において、最適作業負荷ソリューションＸ_{ｏｐｔｉｍａｌ}は、サービス・レベル目標（ＳＬＯ）要求事項の詳細事項に基づいて、移行の間のパフォーマンス劣化を最小化するために、最小の移行コストに基づいて選定される。次いで、作業負荷アジャスタはステップ７５０に進む。

ステップ７５０で、作業負荷アジャスタは、最適作業負荷ソリューションから最適化アプリケーション・マップを、さらに最適化アプリケーション・マップに対する予測電力節減量生成する。次いで、作業負荷アジャスタは終了し、電力オプチマイザは、上記の図３のステップ３５０に続く。

図９は、本発明の実施形態による、動的な作業負荷調整によってデータ・センタの電力消費を最適化するために用いられるコンピュータ・システムを示す。

コンピュータ・システム９０は、プロセッサ９１と、プロセッサ９１に連結された入力デバイス９２と、プロセッサ９１に連結された出力デバイス９３と、各々がプロセッサ９１に連結されたメモリ・デバイス９４および９５を包含するコンピュータ可読メモリ・ユニットとを含む。入力デバイス９２は、とりわけて、キーボード、マウス、キーパッド、タッチ・スクリーン、音声認識デバイス、センサ、ネットワーク・インタフェース・カード（ＮＩＣ：ｎｅｔｗｏｒｋ ｉｎｔｅｒｆａｃｅ ｃａｒｄ）、ボイス／ビデオ・オーバー・インターネット・プロトコル（ＶＯＩＰ：Ｖｏｉｃｅ／ｖｉｄｅｏ ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アダプタ、無線アダプタ、電話アダプタ、専用回線アダプタなどにすることができる。出力デバイス９３には、とりわけて、プリンタ、プロッタ、コンピュータ・スクリーン、磁気テープ、着脱式ハード・ディスク、フレキシブル・ディスク、ＮＩＣ、ＶＯＩＰアダプタ、無線アダプタ、電話アダプタ、専用回線アダプタ、音声もしくは映像またはその両方の信号ジェネレータ、発光ダイオード（ＬＥＤ：ｌｉｇｈｔ ｅｍｉｔｔｉｎｇ ｄｉｏｄｅ）などがあろう。メモリ・デバイス９４および９５は、とりわけて、キャッシュ、ダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ：ｄｙｎａｍｉｃ ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、読み取り専用メモリ（ＲＯＭ：ｒｅａｄ−ｏｎｌｙ ｍｅｍｏｒｙ）、ハード・ディスク、フレキシブル・ディスク、磁気テープ、コンパクト・ディスク（ＣＤ：ｃｏｍｐａｃｔ ｄｉｓｋ）またはディジタル・ビデオ・ディスク（ＤＶＤ：ｄｉｇｉｔａｌ ｖｉｄｅｏ ｄｉｓｋ）などの光学式記憶装置にすることができる。メモリ・デバイス９５は、コンピュータ実行可能命令を含むコンピュータ・プログラム・コードである、コンピュータ・コード９７を包含する。コンピュータ・コード９７は、とりわけて、本発明による、動的な作業負荷調整によってデータ・センタの電力消費を最適化するため用いられるアルゴリズムを含む。プロセッサ９１は、コンピュータ・コード９７を実行する。メモリ・デバイス９４は、入力データ９６を包含する。入力データ９６は、コンピュータ・コード９７が必要とするインプットを含む。出力デバイス９３は、コンピュータ・コード９７からのアウトプットを表示する。メモリ・デバイス９４および９５のいずれかまたは両方（あるいは、図９に示されていない一つ以上の追加のメモリ・デバイス）は、中に具現されたコンピュータ可読プログラム・コードを有する、もしくは中に格納された他のデータを有する、またはその両方を有するコンピュータ可読記憶媒体（またはコンピュータ可用記憶媒体、またはプログラム記憶デバイス）として用いることができ、このコンピュータ可読プログラム・コードはコンピュータ・コード９７を含む。一般に、コンピュータ・システム９０のコンピュータ・プログラム製品（あるいは製造品）には、上記のコンピュータ可読記憶媒体（または上記のプログラム記憶デバイス）を含めることができる。

サービス・プロバイダは、本発明の任意のコンポーネントの展開、管理、サービスなどを実施し、本発明の、動的な作業負荷調整によってデータ・センタの電力消費を最適化するためのプロセスに関するコンピューティング・インフラストラクチャの展開または統合を提供することができる。しかして、本発明は、コンピューティング・システム（例コンピューティング・システム９０）中にコンピュータ可読コードを統合し、ホスティングし、維持し、展開するステップを含む、コンピュータ・インフラストラクチャをサポートするためのプロセスを開示し、上記コードは、コンピューティング・システムと相まって、動的な作業負荷調整によってデータ・センタの電力消費を最適化する方法を遂行する能力を有する。

別の実施形態において、本発明は、本発明のプロセス・ステップを、予約申し込み、広告、もしくは料金ベースまたはこれらの組み合わせで実施する方法を提供する。すなわち、ソリューション・インテグレータなどのサービス・プロバイダは、本発明の動的な作業負荷調整によってデータ・センタの電力消費を最適化するためのプロセスの生成、維持、サポートなどを売り出すことができる。この場合、サービス・プロバイダは、一人以上の顧客に対し、本発明のプロセス・ステップを遂行する、コンピュータ・インフラストラクチャの生成、維持、サポートなどを行うことができる。サービス・プロバイダは、見返りとして、予約申し込みもしくは自由契約またはその両方の下で顧客（群）から支払いを受けることができ、もしくはサービス・プロバイダは、一人以上の第三者に対するコンテント広告の販売に対する支払いを受けることができ、またはこれらの両方の支払いを受けることができる。

図９は、コンピュータ・システム９０を、ハードウェアおよびソフトウェアの特定の構成として示しているが、当業者なら承知しているであろうように、上記の目的のために、図９の特定のコンピュータ・システム９０に加え、ハードウェアおよびソフトウェアの任意の構成を用いることができる。例えば、メモリ・デバイス９４および９５は、別個のメモリ・デバイスでなく、単一のメモリ・デバイスの部分とすることができる。

当業者ならよく理解するであろうように、本発明は、システム、方法、またはコンピュータ・プログラム製品として具現することができる。従って、本発明は、全体がハードウェアの実施形態、全体がソフトウェアの実施形態（ファームウエア、常駐ソフトウェア、マイクロコードなどを含む）、あるいは、一般に本明細書では全て「回路」、「モジュール」、または「システム」といわれる、ソフトウェアおよびハードウェア態様を組み合わせた実施形態の形を取ることができる。さらに、本発明は、媒体中に具現されたコンピュータ可用プログラム・コードを有する任意の有形表現媒体中に具体化されたコンピュータ・プログラム製品の形を取ることもできる。

一つ以上のコンピュータ可用またはコンピュータ可読媒体（群）９４、９５の任意の組み合わせを用いることができる。コンピュータ可用媒体またはコンピュータ可読媒体という用語は、コンピュータ可用／可読記憶媒体９４、９５を総称する。コンピュータ可用またはコンピュータ可読媒体９４、９５は、例えば、以下に限らないが、電子的、磁気的、光学的、電磁気的、赤外的な、または半導体の、システム、装置、デバイス、あるいはこれらの任意の適切な組み合わせとすることができる。コンピュータ可読媒体９４、９５のさらに具体的な例（非包括的リスト）には、一つ以上の配線を有する電気接続、携帯型コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ：ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、読み取り専用メモリ（ＲＯＭ）、消去可能プログラム可能読み取り専用メモリ（ＥＰＲＯＭ（ｅｒａｓａｂｌｅ ｐｒｏｇｒａｍｍａｂｌｅ ｒｅａｄ−ｏｎｌｙ ｍｅｍｏｒｙ）またはフラッシュ・メモリ）、光ファイバ、携帯型コンパクト・ディスク読み取り専用メモリ（ＣＤ−ＲＯＭ：ｃｏｍｐａｃｔ ｄｉｓｋ ｒｅａｄ−ｏｎｌｙ ｍｅｍｏｒｙ）、光記憶デバイス、磁気記憶デバイス、またはこれらの任意の適切な組み合わせが含まれよう。なお、コンピュータ可用またはコンピュータ可読媒体９４、９５を、紙または他の適切な媒体としてその上にプログラムを印刷することさえできよう。その紙または他の媒体を例えば光学スキャンしてプログラムを電子的に捕捉し、次いで、必要に応じ、適切な仕方でコンパイル、解釈、または別途に処理し、その後でコンピュータ・メモリに格納することができる。本文書の文脈において、コンピュータ可用またはコンピュータ可読媒体９４、９５は、命令を実行するシステム、装置、またはデバイスによってまたはこれらに関連させて使用するためのプログラムを、包含または格納できる任意の媒体とすることができる。

本発明のオペレーションを実行するためのコンピュータ・コード９７は、Ｊａｖａ（Ｒ）、Ｓｍａｌｌｔａｌｋ（Ｒ）、Ｃ＋＋などのオブジェクト指向プログラミング言語、および、“Ｃ”プログラミング言語または類似のプログラミング言語などの従来式手続き型プログラミング言語を含め、一つ以上のプログラミング言語の任意の組み合せで記述することができる。コンピュータ・コード９７は、全体をユーザのコンピュータで、一部をユーザのコンピュータで、スタンドアロン・ソフトウェア・パッケージとして実行することができ、一部をユーザのコンピュータで他の部分を遠隔コンピュータで、または全体を遠隔のコンピュータまたはサーバで実行することができる。後者のシナリオでは、ローカル・エリア・ネットワーク（ＬＡＮ：ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）または広域ネットワーク（ＷＡＮ：ｗｉｄｅ ａｒｅａ ｎｅｔｗｏｒｋ）を含む任意の種類のネットワークを介して、遠隔コンピュータをユーザのコンピュータに接続することができ、あるいは（例えばインターネット・サービス・プロバイダを使いインターネットを介し）外部のコンピュータへの接続を行うことができる。

本発明の実施形態による方法、装置（システム）およびコンピュータ・プログラム製品のフローチャート説明図もしくはブロック図またはその両方を参照しながら本発明を説明してきた。フローチャート説明図もしくはブロック図またはその両方の各ブロック、および、フローチャート説明図もしくはブロック図またはその両方中のブロックの組み合せは、コンピュータ・プログラム命令によって実行可能であることが理解されよう。本明細書において、用語「コンピュータ・プログラム命令」は、用語「コンピュータ・コード９７」と置き換えが可能である。これらのコンピュータ・プログラム命令を、汎用コンピュータ、特殊用途コンピュータ、またはマシンを形成する他のプログラム可能データ処理装置のプロセッサに供給し、コンピュータまたは他のプログラム可能データ処理装置のプロセッサを介して実行されるこれらの命令が、フローチャートもしくはブロック図またはその両方のブロックまたはブロック群中に規定された機能群／処理群を実施するための手段を生成するようにすることができる。

また、これらのコンピュータ・プログラム命令を、コンピュータ、または他のプログラム可能データ処理装置に対し特定の仕方で機能するよう命令できるコンピュータ可読媒体９４、９５に格納し、そのコンピュータ可読媒体に格納された命令が、フローチャートもしくはブロック図またはその両方のブロックまたはブロック群中に規定された機能／処理を実施する命令手段を包含する製造品を形成するようにすることができる。

同様に、コンピュータ・プログラム命令を、コンピュータ、または他のプログラム可能データ処理装置にロードして、これらコンピュータ、または他のプログラム可能装置上で一連のオペレーション・ステップを実行させてコンピュータ実行のプロセスを生成し、これらコンピュータまたは他のプログラム可能装置で実行されるこれらの命令が、フローチャートもしくはブロック図またはその両方のブロックまたはブロック群中に規定された機能群／処理群を実施するためのプロセスを提供するようにすることもできる。

図中のフローチャートおよびブロック図は、本発明のさまざまな実施形態による、システム、方法、およびコンピュータ・プログラム製品の可能な実装のアーキテクチャ、機能、およびオペレーションを例示している。この点に関し、フローチャートまたはブロック図中の各ブロックは、所定の論理機能（群）を実行するための一つ以上の実行可能命令を含む、モジュール、セグメント、またはコードの部分を表し得る。また、一部の別の実装においては、ブロック中に記載された機能が、図に記載された順序を外れて行われることがあり得ることに留意すべきである。例えば、連続して示された２つのブロックが、実際にはほぼ同時に実行されることがあり、関与する機能によっては、時には、これらブロックが逆の順序で実行されることもあり得る。さらに、ブロック図もしくはフローチャート説明図またはその両方の各ブロック、およびブロック図もしくはフローチャート説明図またはその両方中のブロックの組み合わせは、特定の機能または処理を実施する、特殊用途のハードウェア・ベースのシステム、または特殊用途のハードウェアとコンピュータ命令との組み合わせによって実施可能なことにも留意すべきである。

請求項中の全ての手段プラス機能またはステッププラス機能のエレメントの、対応する構造、材料、処置および均等物は、具体的に請求された他の請求エレメントと組み合わせて機能を遂行するための、一切の構造、材料または処置を包含することが意図されている。本発明の記述は、例示および説明目的で提示されたもので、網羅的であること、または本発明を開示した形態に限定することは意図されていない。当業者には、本発明の範囲および精神から逸脱することのない多くの修改および変形が明白であろう。本実施形態は、本発明の原理および実際的な応用を最善に説明し、他の当業者が、意図する特定の用途に適したさまざまな修改を加えたさまざまな実施形態のため、本発明を理解できるようにするため、選択し説明されたものである。

Claims (8)

1. 動的な作業負荷調整によってデータ・センタの電力消費を最適化する方法であって、前記方法は、
   コンピュータ・システムのプロセッサが、前記データ・センタからのインプットを受信するステップであって、前記データ・センタは少なくとも一つのデバイスを包含し、前記インプットは物理デバイス・マップおよび現行アプリケーション・マップを含み、前記物理デバイス・マップは、前記データ・センタ内の前記少なくとも一つのデバイスの三次元位置を特定し、前記現行アプリケーション・マップは、前記データ・センタのアプリケーション・プログラムが、前記少なくとも一つのデバイスにどのようにバーチャルにマップされているか、現在の作業負荷が前記アプリケーション・プログラムの間にどのように割り振られているかを明示している、前記受信するステップと、
   前記プロセッサが前記データ・センタに対する少なくとも一つの作業負荷ソリューション候補を生成するステップであって、前記少なくとも一つの作業負荷ソリューション候補の各作業負荷ソリューション候補は、前記少なくとも一つのデバイスへの前記アプリケーション・プログラムのそれぞれのバーチャル・マッピングおよび前記アプリケーション・プログラムの間へのそれぞれの作業負荷配分を規定する、それぞれのアプリケーション・マップを表している、前記生成するステップと、
   前記プロセッサが温度モデルを用いて前記各作業負荷ソリューション候補に対するそれぞれの温度プロフィールを計算するステップであって、前記それぞれの温度プロフィールに関連付けられた前記データ・センタのそれぞれの最高温度に基づいて、前記各作業負荷ソリューション候補それぞれの電力コストが算定される、前記計算するステップと、
   前記プロセッサが前記データ・センタのパフォーマンス要求事項に対するそれぞれのパフォーマンス・プロフィールを評価するため、前記各作業負荷ソリューション候補に対する前記それぞれのパフォーマンス・プロフィールを計算するステップであって、前記それぞれのパフォーマンス・プロフィールに基づいて、前記各作業負荷ソリューション候補それぞれの移行コストが算定される、前記計算するステップと、
   前記プロセッサが前記データ・センタの作業負荷を、前記現在の作業負荷配分から最適作業負荷ソリューションに動的に調整するステップであって、前記最適作業負荷ソリューションは、前記それぞれの電力コストと前記それぞれの移行コストとの最低合計値を有する作業負荷ソリューション候補である、前記調整するステップと、
   を含む方法。
2. 前記動的に調整するステップは、
   前記各作業負荷ソリューション候補それぞれの全体的コストを見積もるステップであって、前記それぞれの全体的コストは、前記それぞれの電力コストおよび前記それぞれの移行コストの和であり、前記それぞれの電力コストは、前記各作業負荷ソリューション候補を用いて前記データ・センタの動作温度以内のサービス行う際に前記データ・センタによって費消される電力量から計算され、前記それぞれの移行コストは、前記データ・センタの前記作業負荷を前記現在の作業負荷配分から前記各作業負荷ソリューション候補に調整する間のパフォーマンス劣化から計算される、前記見積もるステップと、
   前記少なくとも一つの作業負荷ソリューション候補から最適作業負荷ソリューションを選定するステップであって、前記最適作業負荷ソリューションは、前記見積もりステップにおいて最低の全体的コストを有する、前記選定するステップと、
   前記最適作業負荷ソリューションを、展開のため前記コンピュータ・システムに転送するステップと、
   を含む、請求項１に記載の方法。
3. 前記それぞれの温度プロフィールを前記計算するステップは、
   前記データ・センタの前記温度モデルが利用可能でないことを判定するステップであって、前記温度モデルが、前記受信されたインプットから前記データ・センタの現在の温度プロフィールを計算することを可能にする、前記判定するステップと、
   前記データ・センタの前記物理デバイス・マップ、デバイス温度プロフィールおよびデバイス設定から、前記データ・センタの前記温度モデルを生成するステップであって、前記デバイス温度プロフィールは、前記データ・センタの前記少なくとも一つのデバイスの各デバイスそれぞれの吸気口で測定されたそれぞれの温度を表し、前記デバイス温度プロフィールの各デバイス温度プロフィールは、前記デバイス設定の各デバイス設定に関連付けられており、前記各デバイス設定は前記各デバイスそれぞれの識別子、およびｉｄｌｅおよびｂｕｓｙから成る群から選定された、前記各デバイスそれぞれの動作ステータスを含む、前記生成するステップと、
   前記温度モデルを前記各作業負荷ソリューション候補に適用して前記それぞれの温度プロフィールを生成するステップと、
   を含む、請求項１に記載の方法。
4. 前記それぞれのパフォーマンス・プロフィールを前記計算するステップは、
   秒あたり命令数で、作業負荷Ｗの実行速度を算定するパフォーマンス予測モデルを生成するステップであって、前記速度はＩＰＳ（Ｉｎｓｔｒｕｃｔｉｏｎｓ Ｐｅｒ Ｓｅｃｏｎｄ）（Ｗ）として表記され、前記速度は、
   

   

   として計算され、式中ｆｒｅｑｕｅｎｃｙは前記少なくとも一つのデバイスの動作周波数を示し、ＣＰＩ（Ｃｙｃｌｅｓ Ｐｅｒ Ｉｎｓｔｒｕｃｔｉｏｎ）（Ｗ）は前記作業負荷Ｗの命令当たりのサイクル数を表しており、ＣＰＩ_ｃｏｒｅは前記デバイスのコア内で命令の実行に費やされる命令当たりのサイクル数を表し、ＣＰＩ_ｃｏｒｅは、ＣＰＩ_ｃｏｒｅ（ｆ_１）＋ＭＰＩ×Ｍ_{ｌａｔｅｎｃｙ}×ＢＦ（ｆ_１）として計算され、式中ＣＰＩ_{ｍｅｍｏｒｙ}は前記命令を実行するため前記デバイスのメモリにアクセスする際に費やされる命令当たりのサイクル数を表し、ＣＰＩ_{ｍｅｍｏｒｙ}は、ＣＰＩ_ｃｏｒｅ（ｆ_１）＋ＭＰＩ×Ｍ_{ｌａｔｅｎｃｙ}×（ｆ_２／ｆ_１）×ＢＦ（ｆ_１）として計算され、ｆ_１は前記コアの第一動作周波数であり、ｆ_２は前記メモリの第二周波数であり、ＭＰＩは命令当たりのメモリ・アクセスの回数であり、Ｍ_{ｌａｔｅｎｃｙ}はメモリの待ち時間であり、ＢＦはブロック因子である、前記生成するステップと、
   前記パフォーマンス予測モデルを前記各作業負荷ソリューション候補に適用して前記それぞれのパフォーマンス・プロフィールを生成するステップと、
   を含む、請求項１に記載の方法。
5. 前記それぞれのパフォーマンス・プロフィールを前記計算するステップは、
   サーバ設定ｓおよび第ｉ記憶デバイス設定ｄｉを有するプラットフォーム上で、作業負荷Ｗの実行速度を秒あたりの命令数で算定するパフォーマンス予測モデルを生成するステップであって、前記速度はＩＰＳ（Ｗ）（ｓ，ｄ_ｉ）として表記され、前記速度は、
   

   

   として計算され、式中ｓ_{ｆｒｅｑｕｅｎｃｙ}は前記サーバ設定ｓ中に表されるサーバの動作周波数を示し、ＣＰＩ（Ｗ）は前記プラットフォーム中の前記作業負荷Ｗに対する命令当たりのサイクル数を表しており、Σ_ｉＣＰＩ（Ｗ）（ｓ，ｄ_ｉ）＝Σ_ｉ（ＣＰＩ_{ｓｅｒｖｅｒ}（ｓ，ｄ_ｉ）＋ＣＰＩ_{ｓｔｏｒａｇｅ}（ｓ，ｄ_ｉ））であり、ＣＰＩ_{ｓｅｒｖｅｒ}（ｓ，ｄ_ｉ）は、前記作業負荷Ｗが、ディスクへの一切のアクセスなくして全てメモリから実行されたとき、前記プラットフォームにおいてサーバによって費消されたサイクルの第一数を表し、ＣＰＩ_{ｓｅｒｖｅｒ}（ｓ，ｄ_ｉ）はＣＰＩ_{ｓｅｒｖｅｒ}（ｓ）として計算され、ＣＰＩ_{ｓｔｏｒａｇｅ}（ｓ，ｄ_ｉ）は，前記プラットフォームにおいて前記作業負荷Ｗが実行される際に、前記プラットフォーム中の記憶デバイスによって費消されるサイクルの第二数を表し、ＣＰＩ_{ｓｔｏｒａｇｅ}（ｓ，ｄ_ｉ）は，ＤＩＯＰＩ×Ａｖｇ（ＬＵＮ_{ｌａｔｅｎｃｙ}（ｄ_ｉ）（Ｗ））×ＤＢＦとして計算され、ＤＩＯＰＩは、命令当たりのディスク入力／出力の回数を示し、Ａｖｇ（ＬＵＮ_{ｌａｔｅｎｃｙ}（ｄ_ｉ）（Ｗ））は、前記作業負荷Ｗに対する前記第ｉ記憶デバイス設定ｄ_ｉ中のそれぞれの論理ボリューム・ユニットの待ち時間の平均を示し、ＤＢＦはディスク・ブロック因子である、前記生成するステップと、
   前記パフォーマンス予測モデルを前記各作業負荷ソリューション候補に適用して前記それぞれのパフォーマンス・プロフィールを生成するステップと、
   を含む、請求項１に記載の方法。
6. 内部に具現されたコンピュータ可読プログラム・コードを有するコンピュータ可読記憶媒体を含むコンピュータ・プログラム製品であって、前記コンピュータ可読プログラム・コードは、コンピュータに実行されたとき、請求項１〜５のいずれかに記載の、動的な作業負荷調整によってデータ・センタの電力消費を最適化する前記方法を遂行する命令を包含する、
   コンピュータ・プログラム製品。
7. プロセッサと前記プロセッサに連結されたコンピュータ可読のメモリ・ユニットとを含むコンピュータ・システムであって、前記コンピュータ可読メモリ・ユニットは、前記プロセッサに実行されたとき、請求項１〜５のいずれかに記載の、動的な作業負荷調整によってデータ・センタの電力消費を最適化する前記方法を実施する命令を包含する、コンピュータ・システム。
8. コンピュータ・インフラストラクチャをサポートするプロセスであって、前記プロセスは、コンピューティング・システム中に、コンピュータ可読コードを生成、統合、ホスティング、維持、および展開することの少なくとも一つを行うための少なくとも一つのサポート・サービスを提供するステップを含み、前記コードは、前記コンピューティング・システムと相まって、請求項１〜５のいずれかに記載の、動的な作業負荷調整によってデータ・センタの電力消費を最適化する前記方法を遂行する能力を有する、プロセス。

Images