JP2013524317A - 分散コンピューティングシステムにおける電力供給の管理 - Google Patents

Abstract

いずれか所与の複数のコンピュータのうちの個別コンピュータの電力消費の徴候を集約することによってこれらの所与の複数のコンピュータが評価されるように、複数のコンピュータの電力消費を繰返し評価することによって、１つまたは複数のコンピュータが複数のコンピュータ中の電力消費を管理する。この評価により、電力を過多に消費している複数のコンピュータが識別または予測され、電力を過少に消費している複数のコンピュータが識別される。電力を過多に消費しているとして識別された第１の複数のコンピュータに、それを構成するコンピュータまたはバーチャルマシン（ＶＭ）のうちのいくつかにその計算作業負荷を低減するよう命令するメッセージが送られる。電力を過少に消費しているとして識別された第２の複数のコンピュータに、他のコンピュータにその計算作業負荷を増大させるよう命令するメッセージが送られる。

Description

本発明は、分散コンピューティングシステムにおける電力供給の管理に関する。

データセンタ、グリッド、クラウド、コンテナなどの大規模なコンピューティングインフラストラクチャ中の多数の分散した計算要素に電力を供給することはしばしば、難しい問題である。通常、コンピュータサーバ、ストレージアプライアンス、およびネットワークデバイスなどを含めた複数の電力消費要素（まとめて計算要素と呼ぶ）に、固定の電力予算または量が、静的な配線および電力バックアップインフラストラクチャを使用して分配される。これらの要素の電力消費は、静的ではなく、これらの要素上で実行されるユーザアプリケーションの動的な作業負荷またはデータアクセスパターンによってしばしば変化する。これらの変化のせいで生じる問題の１つは、他の要素に余分な容量が存在するときであっても、静的な電力分配インフラストラクチャは、電力を必要とする要素に電力を容易に再分配できない場合があることである。現在、このような変化中にシステムが動作し続けるようにするためには、システムの異なる各部分における動的な需要変動に対応できるように、かなりの量の余分な電力容量が各部分に供給される。したがって、電力供給システムのある部分では電力が十分に利用されないが、同時に電力供給システムの別の部分では電力が不足する、という場合がある。

動的な電力管理に関係する技法について以下に論じる。

米国特許出願第１２／７７４，２０３号明細書

R. Nathuji, P. England, P. Sharma, and A. Singh., "Feedback driven qos-aware power budgeting for virtualized servers", in the Fourth International Workshop on Feedback Control Implementation and Design in Computing Systems and Networks (FeBID), April 2009 A. Kansal, F. Zhao, J. Liu, N. Kothari, and A. Bhattacharya, "Virtual machine power metering and provisioning", ACM Symposium on Cloud Computing, 2010

以下の概要は、後続の詳細な記述で論じるいくつかの概念を紹介するためにのみ含めるものである。この概要は、包括的ではなく、特許請求する主題の範囲を線引きするものとはしない。特許請求する主題の範囲は、最後に提示する特許請求の範囲によって示す。

要約すると、様々な計算要素の電力消費を、オンライン方式でまたはオフライン方式と組み合わせて監視することができ、電力使用を、電力分配インフラストラクチャにわたる電力利用可能性または指定の予算と比較することができる。例えば、電力分配インフラストラクチャは、データセンタコロ（ｃｏｌｏ）（部屋）、ラック、回路、コンテナ、または個別サーバもしくはクラスタにわたる、固定の電力予算を有する場合がある。１つまたは複数の予算限界において電力予算を超過したとき（または、超過しそうなときもしくは超過すると予測されるとき）、電力予算施行を開始して、積極的に（または先を見越して）、インフラストラクチャの過負荷部分（またはそれぞれ、過負荷になると予測される部分）における電力使用を低減することができる。ユーザおよび／またはオペレータによって指定された電力管理ポリシに基づき、１つまたは複数の施行機構を使用して電力使用が制御される。このような機構は、以下のまたは他の機構を含みうる。電力使用の増加を引き起こす作業負荷のいくらかまたは全てを、電力インフラストラクチャの、電力予算を超過していない部分（例えば異なるコロ）に移行することができる。ステートレスなサービスの場合、過負荷の箇所で、アプリケーションインスタンス、またはアプリケーションインスタンスをホストするバーチャルマシン（ＶＭ）を終了することができ、後で同じサーバまたは異なるサーバ上で、新しいインスタンスまたはこれらをホストするＶＭをインスタンス化することができる。このような技法は、アプリケーション状態を再現できる場合（例えば、インスタントメッセージングサービスにおいてユーザクライアントに記憶された情報を使用して）でも適用可能である。アプリケーションコンポーネント自体、またはアプリケーションコンポーネントをホストするバーチャルマシンは、移行するかまたは一時的に実行延期（例えば記憶装置にページングする）して、後で同じサーバまたは異なるサーバ上で再開することができ、過負荷部分のサーバは、シャットダウンするかまたは低電力パフォーマンス状態もしくは低電力スリープ状態に遷移させて、同様のサーバをインフラストラクチャの他の部分で開始することができる。データセンタに入来するユーザ作業負荷は、同じデータセンタまたは他のデータセンタ中の、過負荷でない部分のサーバにリダイレクトすることができる。いくつかのサーバ（例えば、優先順位または収入の低いアプリケーションを実行しているサーバ）の電力使用を、これらのサーバ上のＣＰＵプロセッサ周波数（ならびに／または、リソースの中でもとりわけ、メモリ／キャッシュ割振りおよびメモリ帯域幅）を減少させることによって、低減することができる。いくつかのアプリケーションに割り振られるＣＰＵ時間を短縮し、したがってプロセッサが低電力パフォーマンス状態または低電力スリープ状態でより多くの時間を費やすことができるようにし、それにより平均電力引込みを減少させることができる。自動化された電力アラートをユーザ、オペレータ、およびソフトウェアアプリケーションに送ることができ、ユーザ、オペレータ、およびソフトウェアアプリケーションは、その処理タイプを変更することによって応答することができ（例えば、ムービーストリーミングサーバは、ＨＤ解像度から標準鮮明度に切り換えることができる）、低減された作業負荷により、引き込まれる電力が減少する。入来したユーザ要求は、リダイレクトすることができ、作業負荷は、要因の中でもとりわけ、利用可能な電力容量、動的な電力価格付け／利用可能性、ホストする計算要素の可用性および容量、移行で被る帯域幅やレイテンシなどの移行コストに基づいて、地理的に分散したデータセンタにわたって移行することができる。展開されるソフトウェアおよびハードウェアによって提供される他の電力制御オプションを呼び出すこともできる。

以下、付随する特徴の多くを、添付の図面と共に考察される後続の詳細な記述に関して説明する。

この記述は、後続の詳細な記述を添付の図面に鑑みて読めば、よりよく理解されるであろう。図面では、同じ参照番号を使用して、付随する記述における同じ部分を示す。

コンピューティングインフラストラクチャのための電力分配システムを示す図である。 コンピューティングインフラストラクチャを示す図である。 エネルギー施行モジュール（ＥＥＭ）機能を実現するための２つのモジュールを示す図である。 ラックにわたる電力消費を管理するための一実装形態を示す図である。 管理システムによって実施される例示的な電力管理プロセスを示す図である。

電力分配の概観
図１に、コンピューティングインフラストラクチャのための電力分配システム１００を示す。ほとんどのデータセンタやサーバファームなどは、いくぶん固定された電力供給システムを有する。すなわち、電力は、電力供給元または電源１０２から、最終的に電力を消費する計算デバイス１０４に、距離に伴って減少する固定の分量で提供される。電力供給元または電源は、様々な回路に分配される電力の量を変更することがわかっているが、所与の時点で、供給は固定されているものとして考察のために仮定することができ、または、分配を動的に変更する能力は限定されているか不便である場合がある。例えば、配線、変圧器、スイッチなどにおける電力損失を無視した場合、電力は、ソース１０２から、減少する固定量１０６、１０８、１１０、１１２で、分配ポイント１１４（例えば近隣、キャンパス、変電所など）、回路１ １１６、回路３ １１８、様々なデバイス１０４へと提供することができる。計算要素またはデバイス１０４は、サーバ、スイッチ、ルータ、データ記憶デバイス（例えばテープバンク）、コンテナ、コンピュータブレードなどのためのラックなど、コンピューティング要素とすることができる。

データセンタ、コンピューティングクラウド、または他のタイプの協調的な計算インフラストラクチャが、図１に示すような電力分配システム１００に依拠する場合がある。例えばサーバのクラスタを使用して、包括的なサービス／アプリケーションホスティングを顧客に提供することができる。多くの場合、いずれか所与の時点で実行される様々なタイプのホストされるアプリケーション、ならびにその作業負荷は、予測することまたは事前に知ることが難しい場合のある形で変動する可能性がある。エラー条件、ネットワークまたはサーバの障害、ホストされるアプリケーション／サービスに対する外部からの需要の増加、および他の多くの要因が、予測できない急な計算負荷の増大を引き起こすことがあり、したがって、個別のサーバ、サーバのクラスタ、スーパーコンピュータ、さらにはデータセンタ全体（これらは物理的に遠く離れているが、ネットワークを介して統合されて、一貫した一様なホスティングサービスを提供することができる）の電力消費を増加させることがある。同様に、計算作業負荷が低いと、電力供給インフラストラクチャの別の部分で、消費されない余分な電力が生み出されることがある。

図２に、コンピューティングインフラストラクチャを示す。この例示的なインフラストラクチャは、２つのデータセンタ１００を有する。考察のために、データセンタ１００は、計算要素またはデバイス１０４を収容するため、およびおそらくはそれらに電力、冷却、人間のオペレータのアクセスなどを提供するための、いずれかの任意のユニットと考えることができる。分散管理システム１３０が、ホストにおけるアプリケーションのリソース使用についての測定値、クラウドホスティングプラットフォームの種々のランタイムプロパティおよび特性、ならびに／または、任意のホストグループについての総計測定値（例えば、メモリ使用、ＣＰＵ利用、アクティブなプロセス／スレッド、ネットワーク接続、ネットワーク帯域幅使用、電力消費、ディスクドライブアクティビティ、メモリ障害、キャッシュヒット率など）を得る能力を有する。使用できる様々な技法の１つに関する追加の記述については、参照により本明細書に組み込まれる、特許文献１を参照されたい。

電力監視および管理
データセンタ１００は、様々なコンピューティングデバイス１０４を含んでよい。コンピューティングデバイス１０４は、様々なアプリケーション１３４の供給をデバイスが受けられるようにするアプリケーションホスティングソフトウェア１３２を備えてよく、アプリケーション１３４は通常、ネットワークを介して、データにアクセスすることになり、データをその外部ユーザに提供することを含めてデータを提供することになる。コンピューティングデバイス１０４はまた、データベースをホストし、ＤＮＳまたはウェブサービスを提供し、ロードバランサまたは他の特殊化されたインフラストラクチャタイプのソフトウェアを提供することができる。コンピューティングデバイス１０４はまた、監視コンポーネント１３５を有することができ、監視コンポーネント１３５は、メトリックおよびプロパティの中でもとりわけ、性能、リソース使用、可用性、電力消費、およびネットワーク統計を、管理システム１３０に提供する。コンピューティングデバイス１０４の監視コンポーネント１３５は、協働してピアツーピアネットワークを形成して、大域的状態の総計ビューを計算することができ、または、自動化された分析および意思決定（後で論じる）、集約、共有、相関推論などのために、集中サーバもしくは複数の論理的に集中化されたサーバにデータを収集するのを可能にすることができる。ホスティングソフトウェア１３２は監視コンポーネント１３５を管理するのに好都合なので、監視コンポーネント１３５は、ホスティングソフトウェア１３２内にあるものとして示されている。しかし、監視コンポーネントは、ホスティングソフトウェア１３２によって管理される必要はない。監視コンポーネント１３５は、ホスティングソフトウェア１３２とは別個で離れていてもよく、または、監視コンポーネント１３５は、いくつかのコンピューティングデバイス１０４上ではホスティングソフトウェア１３２によって扱われ、他のコンピューティングデバイス１０４上では自律的であってもよい。

データセンタ１００はまた、管理および組織のユニット、例えば、クラスタ１３６、サブクラスタ１３８、建物１４０、コンテナ、コロ、およびその他を有してよい。様々な組織ユニットが、様々な固定電力量１０６、１０８、１１０、１１２に対応する場合がある。管理システム１３０は、個別のデバイス、および／またはクラスタ、および／またはサブクラスタ、および／または回路など、様々なレベルの組織の電力使用に関する情報を得る。管理システム１３０は、デバイス１０４の使用レベルを得て、ラック、クラスタ、コンテナ、コロなどの組織ユニットの使用レベル、ならびに、ホストされるアプリケーションおよびＶＭ（バーチャルマシン）の性能、サービスレベルアグリーメント（ＳＬＡ）、および優先順位などを導出することができる。管理システム１３０は、どの組織ユニットの電力が余分および／または不足かを決定することができる。次いで管理システム１３０は、電力消費を低減および／または増大させることになるアクションをとるよう、様々なデバイス１０４に命令する（例えば、ネットワークメッセージを介して、または直接にコンソール端末を介して）ことができる。例えば、管理システム１３０は、アプリケーション１４２を移行、終了、減速などするよう、デバイス１０４にメッセージを送信することができる。移行の場合は、アプリケーション１４２を、別のデバイス１０４上の余分な利用可能電力を有する電力ユニット上で、移動（またはアクティブ化、加速）などすることができる。同じプロセスを、他の多くのアプリケーション、バーチャルマシン（ＶＭ）などについても実施することができる。正味の効果としては、問題の電力ユニット上の電力消費が低減され、他の電力ユニット上の電力消費が増大することになるが、両方のユニットの電力使用は、それらの指定の電力予算以内となる。同じプロセスを、複数の電力ユニットについて実施して、それらのランタイム電力使用がそれらの指定の電力予算を超過しないことを確実にすることができる。

一実施形態では、バーチャルマシンを使用して、サーバまたはデバイス１０４上の計算負荷（したがって電力消費）を管理システム１３０によって統制することができる。管理システムは、バーチャルマシン全体を移行すること、バーチャルマシンに利用可能な計算リソースを、例えばそれらの優先順位、収入クラス、利用に基づいて減少／増加させる（例えば、仮想ＣＰＵ速度、仮想メモリ、キャッシュ割振り、メモリ帯域幅割振りなどを増加／減少させる）こと、バーチャルマシンの実行を一時的に延期して後で同じサーバまたは異なるサーバ上で再開すること、またはそうでない場合は、バーチャルマシンを操作または再構成して、データセンタ１００やクラウドインフラストラクチャなどにわたる現在の電力割振りに適合するように計算負荷を調整することができる。別の実施形態では、管理システム１３０は、クラウドコンピューティングインフラストラクチャが、現在の電力使用に従って、同じデータセンタまたは異なるデータセンタ中でホストされる異なるサーバにユーザ要求をルーティングするようにすることができる。

詳述すると、管理システム１３０は、様々な電力消費ユニット（例えばコロ、コンテナ、ラック、個別サーバ）ごとの電力上限または限度を有することができ、この場合、電力上限は、仮想化されたクラウド環境で施行される。これにより、ホストされるアプリケーションまたはＶＭの総計ピーク電力消費が指定の電力予算を超過するという、電力の申込み超過を可能にすることができ、これにより電力供給コストが削減される。いくつかの市販のサーバまたはデバイス１０４は、電力計測／上限設定機能をハードウェア中で提供し、動的電圧周波数スケーリング（ＤＶＦＳ）を使用した電力予算を施行する方法が利用可能である。しかし、複数の分散されたまたは仮想化されたアプリケーションが物理的サーバを共有するときは、電力上限をサーバ全体に対して施行すると、そのサーバ上の全ての実行中ＶＭの性能に影響する。このことは、アプリケーションのうちの１つだけにおける過大な負荷のせいで、複数のアプリケーションの性能に影響することがある。さらに、これらの電力関連の側面は、電力ポリシに組み入れられている場合がある。電力ポリシは、種々の時刻における、または種々のユーザ需要および作業負荷の間における種々のサーバコンポーネント（またはグループ）上の電力消費の特性など、アプリケーション挙動の望ましい特徴を指定するかまたは特徴付ける場合があることに留意されたい。電力関連ポリシの例については、特許文献１の図４を参照されたい。ポリシに関する関連の考察も参照されたい。

電力ポリシを個別のアプリケーションまたはＶＭごとに指定できるようにすることにより、電力消費をアプリケーション単位またはＶＭ単位で統制することが可能であろう。物理的サーバがその電力上限を超過したとき、いずれかのサーバまたはデバイス１０４上で実行されるエネルギー施行モジュール（Ｅｎｅｒｇｙ Ｅｎｆｏｒｃｅｍｅｎｔ Ｍｏｄｕｌｅ）（管理システム１３０の一実施形態またはコンポーネント）が上限を施行することができるが、これは、ユーザによって指定されたポリシに従って、アクションの中でもとりわけ、個別のアプリケーションまたはＶＭに対するリソース割振りを選択的に抑制すること、実行中のＶＭのサブセットの実行を一時的に延期して後で同じサーバまたは異なるサーバ上で再開すること、ＶＭを終了して後で同じサーバまたは異なるサーバ上で新しいアプリケーションインスタンスをホストする新しいＶＭをインスタンス化すること（ステートレスなサービスの場合、また、アプリケーション状態の再現をサポートするステートフルなサービスの場合でも）によって、施行することができる。例えば、あるユーザポリシは、まず、優先順位の低いアプリケーションに対するＶＭについて上限を設け、このようなアクションが電力上限に見合うのに不十分な場合は、次いで、より優先順位の高いＶＭを抑制することを必要とする場合がある。

ＥＥＭを使用して、共有クラウドインフラストラクチャ中で、優先順位を意識したエネルギーアカウンティングおよび施行を実現することができる。クラウドサーバが、作業負荷が動的に変化する高優先順位の対話式アプリケーションからのＶＭ、ならびに、ウェブクローリング、データ複製、科学的作業負荷、およびＤｒｙａｄＬＩＮＱ／Ｍａｐ−Ｒｅｄｕｃｅジョブなどのバックグラウンドタスクを実施する低優先順位のＶＭをホストすると仮定する。全てのアプリケーションからのＶＭを、ＶＭ配置制約に基づいてクラウドサーバにわたって分散させることができる。ＥＥＭは、使用される全てのサーバに対する電力上限を監視する。電力上限を超過していることをＥＥＭが検出したとき、または近い将来に電力上限を超過する可能性が高いことをＥＥＭが予測したとき、ＥＥＭは、指定の施行ポリシに従って上限を施行する。ＥＥＭにおける電力上限施行に関する以下の例示的なポリシ「優先順位の低いバックグラウンドＶＭについてＣＰＵ割振りを低減し、それでも電力消費を指定の電力予算内にするのに不十分な場合にのみ、優先順位の高いＶＭに対してリソースを抑制する」を考えてみる。このポリシに従えば、サーバのラックに電力を供給する回路ブレーカが容量に近いとき、ＥＥＭは、サーバ全体を抑制するのではなく（これは、これらのサーバ上で実行されている優先順位の高いＶＭを抑制することを含意する）、まず、ラック内のサーバ上の優先順位の低いＶＭを選択して電力使用を低減することになる。

電力ポリシの施行
図３に、エネルギー施行モジュール（ＥＥＭ）機能を実現するための２つのモジュールを示す。電力モニタ１６０モジュールが電力使用を監視し、優先順位ベースの電力アロケータ（ＰＰＡ）１６２モジュールが電力ポリシを施行する。図３にはまた、アプリケーション１６３、ユーザポリシ仕様１６４、およびアプリケーションモニタ１６６も示すが、これらはそれぞれ、特許文献１に記載されている。電力モニタ１６０に関して、ハードウェアベースの電力測定設備がサーバ上またはデバイス１０４上で利用可能な場合は、このような設備を電力モニタ１６０に使用することができる。いくつかのサーバは、このような内臓の電力計測ハードウェアを有するが、このようなハードウェアが利用可能でない場合は、他の技法を使用することができる。例えば、ＷａｔｔｓＵｐ ＰＲＯ ＥＳ電力メータを使用して、サーバ電力を測定することができる。このような場合、電力メータのための直列化プロトコルドライバをアプリケーションモニタ１６６にインタフェースして、電力データにアクセスすることができる。アプリケーションモニタ１６６は、集約、相関、および分析などのために、電力データを他のモニタまたは管理モジュールに転送することができる。

ＰＰＡ１６２に関して、方法の中でもとりわけ、サーバ上のＶＭに割り振られるＣＰＵ時間または部分を変更することによって、電力上限を施行することができる。一実施形態では、プロセッサ時間の抑制自体でも十分な場合がある。というのは、プロセッサは通常、小さいフォームファクタのサーバの総電力消費の大部分に貢献するからである。追加でまたは別法として、例えば、プロセスごと、アプリケーションごと、またはＶＭごとの抑制を実施することもできる。割り振られるＣＰＵ時間が短縮されるのに伴い、サーバのプロセッサは、低電力／パフォーマンス状態でより多くの時間を費やし、それにより電力使用を低減する。一実施形態では、Ｗｉｎｄｏｗｓ（登録商標） Ｈｙｐｅｒ−Ｖを仮想化に使用することができる。他のシステムでは、Ｘｅｎ ＶＭＭなど、同様の機能が利用可能である。どのようにＨｙｐｅｒ−Ｖを修正してＣＰＵ時間割振りを変更するかに関する追加の詳細については、非特許文献を参照されたい（例えば、非特許文献１参照）。

複数のＶＭをホストする個別サーバごとのプロセッサ時間抑制は、そのサーバの電力上限に対処するが、電力はまた、複数のサーバにわたって管理される場合もある。データセンタ中では、複数のサーバが、同じクラウドサービス（例えば、ＨＴＴＰフロントエンドとアプリケーション中間段とデータベースバックエンドとを含む、多段ウェブおよびｅコマースアプリケーション）を実行している場合がある。したがって、１つのサーバを抑制すると、このサーバがクラウドサービスのボトルネックになることがあり、それによりサービス全体の性能が劣化することがある。さらに、複数のサーバが、共通の電力供給を共有し、これらのサーバの電力供給の容量に基づいて筐体レベル（例えばラック、コンテナ）で総電力消費の限度を有する場合がある。したがって、データセンタ中で電力管理を筐体レベルで実施する必要がある場合がある。この機能を可能にするためには、単純な大域的電力制御ポリシを実現することができる。

電力管理の例
図４に、ラックにわたる電力消費を管理するための一実装形態を示す。ラック以外の任意の電力管理ユニット、例えば建物、回路、コンテナ、コロ、無停電電源装置などを使用してよいことに留意されたい。図４に示すように、電力モニタ１６０（例えば電力メータ）が、ラック１８８にわたる全てのサーバ１８０の総電力消費を測定し、これらの値を管理システム１３０に送る。管理システム１３０は、構成の中でもとりわけ、協働するエージェントのネットワーク、アプリケーションモニタプログラム、または、指定の管理サーバ上で実行されるプログラムとすることができる。管理システム１３０はまた、各サーバ１８０上で実行される個別のＶＭ１８６の電力使用を収集する。ＶＭごとの電力使用は、電力モニタ１６０を使用して、例えば各サーバ１８０上のルートハイパーバイザ中で実行されるＪｏｕｌｅｍｅｔｅｒ（例えば、非特許文献２参照）を使用して、計算することができる。ラック、例えばラック１ １８８の電力消費が所定の電力予算よりも高いことを管理システム１３０が検出すると、管理システム１３０は、他のラック（ラック２ １９２など）上の、サーバの電力予算未満で動作している十分に利用されていないサーバ１９０への移行のために、ラック１８８上の電力利用の最も高い必要数のＶＭ１８６を選択し（電力予算に見合うように）、この決定を示すメッセージを、作動に向けてリソースマネージャ１９４に送る。十分に利用されていないサーバが、移行されるＶＭをホストするのに利用可能でない場合、または、移行コストがそれらの利益よりも高くつく場合は、例えば、ＶＭの実行を一時的に延期して、後で再開することができる。この例示的な電力ポリシは、単純だが、ＶＭの移行中にＶＭの性能を低下させることができる。

性能に対する影響を最小限に抑えるために、代替ポリシの１つは、最初に、電力容量の過負荷を有するラックから、バックグラウンドタスク（例えば、ウェブ検索のためのインデックスの計算、マップ−リデュースジョブ、科学的作業負荷、ＤｒｙａｄＬｉｎＱ／Ｍａｐ−Ｒｅｄｕｃｅジョブなど）を処理しているＶＭ１８６を、電力予算未満のラック上でホストされている十分に利用されていないサーバに移行する（またはこのＶＭ１８６に最も高い優先順位を割り当てる）ことになり、これでもまだ電力過負荷のラックに対する電力上限に見合わない場合は、このポリシは、フォアグラウンドタスクを処理しているＶＭを移行し、移行に向けた最も低い処理優先順位を対話式ＶＭに割り当てることができる。さらに、要素の中でもとりわけ、電力利用、優先順位、収入クラス、およびユーザ対話性（例えば性能に対するＳＬＡペナルティ）を組み合わせることに基づく、ハイブリッド方式を使用して、ラックにわたる電力予算に見合うように移行に向けてＶＭの優先順位を付けることができる。このようなポリシの２つの例は、以下のとおりである。移行に向けてＶＭに優先順位を割り当てる第１のハイブリッド例示的ポリシは、電力消費がより高いＶＭにより高い優先順位を割り当て、２つのＶＭが同じ電力使用を有する場合は、性能への影響に対するＳＬＡペナルティがより低いＶＭを優先することになる。第２のハイブリッド例示的ポリシは、性能劣化に対するＳＬＡペナルティが最低であるＶＭにより高い優先順位を割り当て、２つのＶＭについて性能に対するＳＬＡペナルティが同じである場合は、電力消費がより高いＶＭを選択することになる。上記と同様、十分に利用されていないサーバが、移行されるＶＭをホストするのに利用可能でない場合、または、移行コストがそれらの利益よりも高くつく場合は、ポリシの中でもとりわけ、ＶＭの実行を一時的に延期して、後で同じサーバまたは異なるサーバ上でＶＭを再開することができる。

図５に、管理システム１３０によって実施される例示的な電力管理プロセスを示す。電力測定値が、繰返し受け取られる（２２０）。測定値は繰返し使用されて、電力消費を低減する必要のある電力インフラストラクチャが識別される（２２２）。次いで、識別された（２２２）電力インフラストラクチャに対応する候補計算要素（例えばアプリケーション、ＶＭ、ＣＰＵ、サーバ）が、移行のための、または他の電力低減アクションの実行のための潜在的候補として識別される（２２４）。計算要素は、ユーザおよび／またはオペレータによって書かれた電力使用／施行ポリシに基づいて識別することができる（２２４）。識別された（２２４）計算要素を抑制すると他のどこかの計算の代償的な増加が必要になりうる実施形態では、プロセスは、識別された（２２４）計算要素を再割振りする（２２８）先として適したインフラストラクチャを識別する（２２６）ことを含んでよい。例えば、電力管理ポリシは、優先的に計算負荷を増大させることになる計算要素、例えば電力容量が十分に利用されていない計算要素の、条件または特性を提供する場合がある。さらに電力測定値が受け取られた後、プロセスは任意選択で、識別されたインフラストラクチャの電力消費が十分に低減されたかどうか決定することができる（２３０）。低減されていない場合は、追加のアクションをとることができる（２３２）。他のプロセスを使用して、電力平衡を達成することもできる。一実施形態では、電力割振りとＳＬＡ性能とを組み合わせることができ、アプリケーション性能がＳＬＡを満たしていない場合は、より多くの電力を割り振ることができ、または電力が低減されるのを防止することができる。

結び
要約すると、様々な計算要素の電力消費を監視することができ、電力使用を、電力分配インフラストラクチャにわたる電力利用可能性または指定の予算と比較することができる。例えば、電力分配インフラストラクチャは、データセンタコロ（部屋）、ラック、回路、コンテナ、または個別サーバもしくはクラスタにわたる、固定の電力予算を有する場合がある。１つまたは複数の予算限界において電力予算を超過したとき（または、超過しそうなときもしくは超過すると予測されるとき）、電力予算施行を開始して、インフラストラクチャの過負荷部分における電力使用を積極的に低減することができる。ユーザおよび／またはオペレータによって指定された電力管理ポリシに基づき、１つまたは複数の施行機構を使用して電力使用が制御される。このような機構は、以下のまたは他の機構を含みうる。電力使用の増加を引き起こす、作業負荷およびアプリケーション、またはこれらの作業負荷を処理するＶＭの、いくらかまたは全てを、電力インフラストラクチャの、電力予算を超過していない部分に移行することができる。バーチャルマシンは、移行することができ、過負荷部分のアプリケーションインスタンスまたはサーバは、シャットダウンして、同様のアプリケーションインスタンスまたはサーバをインフラストラクチャの他の部分で開始することができる。データセンタに入来するユーザからの要求、ならびに実行中の作業負荷は、同じデータセンタまたは他のデータセンタ中の、過負荷でない部分のサーバにリダイレクトするかまたは移行することができる。いくつかのサーバ（例えば、優先順位または収入の低いアプリケーションを実行しているサーバ）の電力使用を、これらのサーバ上のＣＰＵプロセッサ周波数（または、リソースの中でもとりわけ、アプリケーションごともしくはＶＭごとの、メモリ／キャッシュ／メモリ帯域幅の割振り）を減少させることによって、低減することができる。いくつかのアプリケーションに割り振られるＣＰＵ時間を短縮し、したがってプロセッサが低電力パフォーマンス状態または低電力スリープ状態でより多くの時間を費やすことができるようにし、それにより平均電力引込みを減少させることができる。自動化された電力アラートをユーザ、オペレータ、およびソフトウェアアプリケーションに送ることができ、ユーザ、オペレータ、およびソフトウェアアプリケーションは、その処理タイプを変更することによって応答することができ（例えば、ムービーストリーミングサーバは、ＨＤ解像度から標準鮮明度に切り換えることができる）、低減された作業負荷により、引き込まれる電力が減少する。作業負荷は、要因の中でもとりわけ、利用可能な電力容量、動的な電力価格付け／利用可能性、ホストする計算要素の可用性および容量、移行で被る帯域幅やレイテンシなどの移行コストに基づいて、地理的に分散したデータセンタにわたって移行することができる。展開されるソフトウェアおよびハードウェアによって提供される他の電力制御オプションを呼び出すこともできる。

以上に論じた実施形態および特徴は、揮発性または不揮発性のコンピュータ可読媒体またはデバイス可読媒体に記憶された情報の形で実現することができる。これは、光学記憶装置（例えばＣＤ−ＲＯＭ）、磁気媒体、フラッシュＲＯＭ、または、素早くアクセス可能なディジタル情報を記憶する任意の現行もしくは将来の手段などの媒体を、少なくとも含むと見なされる。記憶された情報は、機械実行可能命令（例えばコンパイルされた実行可能バイナリコード）、ソースコード、バイトコード、または、上に論じた様々な実施形態をコンピューティングデバイスが実施するのを可能にするかもしくは実施するよう構成するのに使用できるいずれか他の情報の形とすることができる。これもまた、実施形態を実施するプログラムの実行中にＣＰＵ命令などの情報を記憶するＲＡＭおよび／または仮想メモリなどの揮発性メモリ、ならびに、プログラムまたは実行ファイルがロードされ実行されるのを可能にする情報を記憶する不揮発性媒体を、少なくとも含むと見なされる。実施形態および特徴は、ポータブルデバイス、ワークステーション、サーバ、モバイルワイヤレスデバイスなどを含めた、任意のタイプのコンピューティングデバイス上で実施することができる。

Claims (15)

1. 複数のサーバコンピュータおよび／またはアプリケーションおよび／またはバーチャルマシン（ＶＭ）から電力測定値を受け取るステップであって、前記電力測定値は、前記サーバコンピュータの、または前記個別アプリケーションの、または前記アプリケーションをホストする前記ＶＭの、電力消費の測定値を含み、前記サーバコンピュータは、前記サーバコンピュータ外部の対応する電力インフラストラクチャユニットから電力を受け取る、ステップと、
   前記電力測定値を評価して、前記電力インフラストラクチャユニットのうちの１つが電力使用の低減を必要とするかどうか判定するステップと、
   電力低減の必要があると判定するのに応答して、前記電力インフラストラクチャユニットから電力を受け取る１つまたは複数のサーバコンピュータに１つまたは複数のメッセージを送るステップであって、前記メッセージは前記１つまたは複数のサーバコンピュータ上における計算の低減を引き起こす、ステップと
   を含むことを特徴とする、コンピュータによって実施される方法。
2. 前記電力インフラストラクチャユニットから電力を受け取る複数のサーバコンピュータについての受け取られた電力測定値から総電力を計算および予測し、前記総電力に基づいて、前記複数のサーバコンピュータについて計算負荷を低減すべきであると決定することによって、電力低減を必要とする前記電力インフラストラクチャユニットが識別されることを特徴とする請求項１に記載の方法。
3. 前記決定することは電力消費ポリシを使用して実施され、前記ポリシは、望ましいまたは必須の電力使用特性を指定することを特徴とする請求項２に記載の方法。
4. 計算および／または電力の前記低減は、非アクティブ化すること、終了して再現すること、移行すること、リソースを再割振りすること、または前記１つもしくは複数のサーバコンピュータ上で実行されるバーチャルマシン（ＶＭ）に対する作業負荷を調整することによって行われ、前記非アクティブ化することは、一時的に延期または停止した後で同じサーバ上または異なるサーバ上で再開することを含み、前記終了して再現することは、過負荷の箇所のアプリケーションインスタンスが終了して、後で同じサーバ上または異なるサーバ上で新しいインスタンスが、または前記新しいインスタンスをホストするＶＭがインスタンス化され、必要ならアプリケーション状態が前記ＶＭ上で再現されることを含むことを特徴とする請求項１に記載の方法。
5. 計算および／または電力の前記低減は、周波数スケーリングなどプロセッサ電力管理ノブを使用して前記１つまたは複数のサーバコンピュータ上の１つまたは複数のＣＰＵの電力消費に影響する前記ＣＰＵの設定を変更することにより、前記ＣＰＵがより少ない電力を消費するようにすることによって行われることを特徴とする請求項１に記載の方法。
6. 前記電力消費ユニットを識別することに応答して、前記過負荷の電力インフラストラクチャユニットから電力を受け取っていない１つまたは複数のサーバコンピュータ上の計算負荷を増大させるステップをさらに含むことを特徴とする請求項１に記載の方法。
7. 計算の前記増大は、前記過負荷の電力インフラストラクチャユニットから電力を受け取っていない１つまたは複数のサーバコンピュータ上で実行される１つまたは複数のＶＭをアクティブ化または改変することによって行われることを特徴とする請求項６に記載の方法。
8. コンピューティングデバイスについての電力消費限度を定義するポリシを受け取るステップと、
   前記コンピューティングデバイスについての電力消費の測定値を受け取るステップと、
   前記コンピューティングデバイスのうちの１つについての前記測定値が前記ポリシ中の電力消費限度を超過するかまたは超過に寄与すると決定するステップと、
   前記決定するステップに応答して、前記コンピューティングデバイスのうちの１つによる電力消費の低減を引き起こすステップであって、前記コンピューティングデバイスのうちの前記１つは、前記プロセスを実施している前記コンピューティングデバイスと同じデバイスではない、ステップとを含むことを特徴とする方法。
9. 前記決定するステップにさらに応答して、前記決定されたコンピューティングデバイスに電力を供給しない電力インフラストラクチャから電力を得る１つまたは複数のコンピューティングデバイスを識別し、前記識別された１つまたは複数のコンピューティングデバイスによる電力消費の増大を引き起こすステップをさらに含むことを特徴とする請求項８に記載の方法。
10. 電力消費の増大および／または電力消費の前記低減は、ＣＰＵ周波数設定を変更すること、キャッシュ割振りを変更すること、メモリ割振りを変更すること、リソースの中でもとりわけメモリ帯域幅割振りを変更すること、アプリケーションの処理優先順位を変更すること、アプリケーションの計算負荷を増大または低減させるよう前記アプリケーションに信号を送ることのうちの１つまたは複数によって行われることを特徴とする請求項８に記載の方法。
11. 前記測定値は、前記コンピューティングデバイスのハードウェアの一部として備わる電力モニタによって提供され、かつ／または、バーチャルマシンについての電力消費を推定する前記コンピューティングデバイスのうちのいくつかの上で実行されるソフトウェアモジュールによって提供されることを特徴とする請求項８に記載の方法。
12. 複数のコンピュータ中の電力消費を管理するための、１つまたは複数のコンピュータによって実施される方法であって、
    いずれか所与の複数のコンピュータのうちの個別コンピュータの電力消費の徴候を集約することによって前記所与の複数のコンピュータが評価されるように、複数のコンピュータの電力消費を繰返し評価するステップであって、前記評価するステップは、電力を過多に消費している複数のコンピュータを識別し、電力を過少に消費している複数のコンピュータを識別する、ステップと、
    電力を過多に消費しているとして識別された第１の複数のコンピュータに応答して、前記第１の複数のコンピュータのうちのいくつかのコンピュータに、前記いくつかのコンピュータの計算作業負荷を低減するよう命令する第１のメッセージを送信するステップと、
    電力を過多に消費しているとして識別された前記第１の複数のコンピュータにさらに応答して、電力を過少に消費しているとして識別された第２の複数のコンピュータのうちの他のコンピュータに第２のメッセージを送信するステップであって、前記第２のメッセージは、前記他のコンピュータの計算作業負荷を増大させるよう前記他のコンピュータに命令する、ステップと
    を含むことを特徴とする方法。
13. 前記評価するステップは、前記コンピュータ上で実行されるソフトウェアアプリケーションによって提供される電力消費の推定値に基づくことを特徴とする請求項１２に記載の方法。
14. 前記コンピュータ上で実行される電力モニタプログラムが前記コンピュータの個別の電力消費の測定値を提供し、前記計算作業負荷は、ＣＰＵ速度を低下させること、アプリケーションプログラムを停止もしくは減速すること、バーチャルマシンの構成を改変すること、リソースを再割振りすること、またはアプリケーションを移行することによって、低減されることを特徴とする請求項１２に記載の方法。
15. 計算作業負荷の前記低減を命令するステップは、前記第１の複数のコンピュータからバーチャルマシンを移行することによって実施されることを特徴とする請求項１２に記載の方法。

Images