(57)【要約】実施形態は、第１及び第２のコンピューティングノードを含むコンピューティングノードのグループに対応する第１の電力メトリック（例えばメモリモジュール温度）を決定するステップと；決定された第１の電力メトリックに応じて、コンピューティングタスクを第３のコンピューティングノードに分散（例えば負荷バランシング）させるステップと；を含み、第３のコンピューティングノードが、第１及び第２のコンピューティングノードとはリモートに配置される。第１の電力メトリックは、コンピューティングノードのグループに対して特有であり、第１及び第２のコンピューティングノードのいずれかには特有ではない。そのような実施形態は、電力消費のようなコンピューティングノードグループの挙動の知識を利用して、コンピューティングノードグループにおける電力消費をより効率的に管理することができる。この「電力調整」は、「シリコンレベル」（例えばサーバのような個々のコンピューティングノード）及び／又は大きなグループレベル（例えばデータセンタ）で得られるデータに依拠し得る。他の実施形態も本明細書で説明される。
2015537309.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも１つのプロセッサによって実行される方法であって、
第１及び第２のコンピューティングノードを含むコンピューティングノードのグループに対応する第１の電力メトリックを決定するステップと、
前記決定された第１の電力メトリックに応じて、コンピューティングタスクを、前記第１及び第２のコンピューティングノードには分散せずに、第３のコンピューティングノードに分散させるステップと、
を含み、
前記第３のコンピューティングノードは、前記第１及び第２のコンピューティングノードとはリモートに配置される、方法。
【請求項２】
前記第１及び第２のコンピューティングノードは、前記第３のコンピューティングノードを含まないコンピュータクラスタ内に含まれる、
請求項１に記載の方法。
【請求項３】
前記第１の電力メトリックは、前記コンピューティングノードのグループに対して特有であり、前記第１及び第２のコンピューティングノードのいずれかには特有ではない、
請求項１に記載の方法。
【請求項４】
前記第１の電力メトリックは、温度、電圧、電流、実行される命令カウント、メモリアクセス、書き込みカウント、読み取りカウント、サービスの品質（ＱＯＳ）、キャッシュミス、データ転送レート、エラーレート、サービス応答時間、信号対雑音比及び周波数応答、のうちの１つに対応する、
請求項３に記載の方法。
【請求項５】
前記第１の電力メトリックは、前記第１のコンピューティングノードに対応する温度と、前記第２のコンピューティングノードに対応する別の温度とに基づく温度を含む、
請求項４に記載の方法。
【請求項６】
前記第１の電力メトリックは、（ａ）前記第１のコンピューティングノードに特有であるが、前記第２のコンピューティングノードには特有でない電力メトリックと、（ｂ）前記第２のコンピューティングノードに特有であるが、前記第１のコンピューティングノードには特有でない追加の電力メトリックとの双方に基づく、
請求項３に記載の方法。
【請求項７】
前記第１のコンピューティングノードに特有の電力メトリックを、前記第２のコンピューティングノードから受け取るステップと、
前記第２のコンピューティングノードに特有の電力メトリックを、前記第２のコンピューティングノードから受け取るステップと、
を含む、請求項６に記載の方法。
【請求項８】
前記第１のコンピューティングノードに特有の電力メトリックを決定したことに応答して、前記第１のコンピューティングノードから前記第３のコンピューティングノードへコンピューティングワークロードをシフトするステップ、
を含む、請求項７に記載の方法。
【請求項９】
前記コンピューティングノードのグループに非特有の履歴電力メトリックを決定するステップと、
前記履歴電力メトリックに基づいて前記第１の電力メトリックを分析するステップと、
前記履歴電力メトリックに基づいて前記第１の電力メトリックを分析したことに応答して、前記コンピューティングタスクを前記第３のコンピューティングノードに分散させるステップと、
を含む、請求項３に記載の方法。
【請求項１０】
前記第１の電力メトリックに基づいて、前記コンピューティングノードのグループに非特有の履歴電力メトリックを決定するステップ、
を含む、請求項３に記載の方法。
【請求項１１】
前記履歴電力メトリックは、前記第１、第２及び第３のコンピューティングノードそれぞれからの電力メトリックデータに基づく、
請求項１０に記載の方法。
【請求項１２】
前記コンピューティングタスクを、前記第１及び第２のコンピューティングノードには分散せずに、前記第３のコンピューティングノードに分散させるステップは、前記決定された第１の電力メトリックに応じて、前記第１、第２及び第３のコンピューティングノードの間でコンピューティングタスクを負荷バランシングすることを含む、
請求項３に記載の方法。
【請求項１３】
前記第１のコンピューティングノードは、前記第２のコンピューティングノードに含まれる第２のサーバとは別個であり、かつ該第２のサーバに含まれない、第１のサーバを含む、
請求項３に記載の方法。
【請求項１４】
前記決定された第１の電力メトリックに応じて、前記第１及び第２のコンピューティングノードの一方から前記第３のコンピューティングノードへコンピューティングワークロードをシフトするステップを含み、当該コンピューティングワークロードをシフトするステップは、前記コンピューティングタスクを前記第３のコンピューティングノードに分散させることを含む、
請求項３に記載の方法。
【請求項１５】
前記コンピューティングノードのグループに非特有の履歴電力メトリックに基づいて、前記第１の電力メトリックを分析するステップと、
前記履歴電力メトリックに基づいて前記第１の電力メトリックを分析したことに応答して、前記コンピューティングタスクを前記第３のコンピューティングノードに分散させるステップと、
を含む、請求項３に記載の方法。
【請求項１６】
請求項１乃至１５のいずれかを実行するための手段を備える装置。
【請求項１７】
コンピューティングデバイスにおいて実行されたことに応答して、該コンピューティングデバイスに請求項１乃至１５のいずれかに記載の方法を実行させる複数の命令を備える、少なくとも１つのマシン読取可能媒体。
【請求項１８】
少なくとも１つのメモリと；
前記メモリに結合されて、
第１及び第２のコンピューティングノードを含むコンピューティングノードのグループに対応する第１の電力メトリックを決定するステップと、
前記決定された第１の電力メトリックに応じて、コンピューティングタスクを、前記第１及び第２のコンピューティングノードには分散せずに、第３のコンピューティングノードに分散させるステップであって、前記第３のコンピューティングノードが前記第１及び第２のコンピューティングノードとはリモートに配置される、ステップと、
を含む動作を実行する、少なくとも１つのプロセッサと；
を備える、装置。
【請求項１９】
前記コンピューティングタスクは、前記第１のコンピューティングノードに向けられるが、前記決定された第１の電力メトリックに応答して前記第３のコンピューティングノードへルート変更される、
請求項１８に記載の装置。
【請求項２０】
前記第１の電力メトリックは、前記コンピューティングノードのグループに対して特有であり、前記第１及び第２のコンピューティングノードのいずれかには特有ではない、
請求項１８に記載の装置。
【発明の詳細な説明】
【背景技術】
【０００１】
電力効率は、単一のコンピューティングノード（例えば携帯電話、スマートフォン、タブレット、ウルトラブック（登録商標）、ノートブック、ラップトップ、デスクトップ、サーバ）のオペレータ並びにコンピューティングノードグループ（例えばデータセンタ、クラウドコンピューティングオペレーション及び／又はサーバのような多数のコンピューティングノードを備えるコンピューティングクラスタのオペレーション）のオペレータにとって重要である。
【発明の概要】
【０００２】
従来の電力効率モニタリングシステムは、サーバ内に含まれる単一のプロセッサの個々のコアにより経験されるコンピューティング負荷といった、「低いレベル」に集中している。
【図面の簡単な説明】
【０００３】
本発明の実施形態の特徴及び利点は、添付の特許請求の範囲、１つ又は複数の例示の実施形態についての以下の詳細な説明並びに対応する図面から明らかとなるであろう。
【図１】テレメトリシステム及び分析クラウドモジュールを備える本発明の実施形態を示す図である。
【図２】テレメトリシステムを備える本発明の実施形態を示す図である。
【図３】分析クラウドモジュールを備える本発明の実施形態を示す図である。
【図４】分析クラウドモジュールを備える本発明の実施形態を示す図である。
【図５】分析クラウドモジュールを備える本発明の実施形態を示す図である。
【図６】本発明の実施形態で使用するためのシステムを示す図である。
【図７】本発明の実施形態における方法を示す図である。
【図８】本発明の実施形態における負荷分散のためのシステムを示す図である。
【発明を実施するための形態】
【０００４】
以下の説明では、様々な具体的詳細が説明されるが、本発明の実施形態は、これらの具体的詳細を用いることなく実施されてもよい。周知の回路、構造又は技術は、本説明の理解を曖昧にするのを避けるため詳細には示されていない。「実施形態」又は「様々な実施形態」及び同様の語は、説明される実施形態が特定の特徴、構造又は特性を含み得ることを示すが、必ずしも全ての実施形態がそのよう特定の特徴、構造又は特性を含んでいない。一部の実施形態は、他の実施形態について説明される特徴の一部又は全てを有してもよく、あるいは全く有していないこともある。「第１」、「第２」、「第３」等という用語は、共通の対象物を説明し、言及されている類似の対象物の異なるインスタンスを示す。そのような形容詞は、説明される対象物が、時間的に、空間的に、ランク的に又は任意の他の方法により所与の順序でなければならないことを示唆するものではない。「接続される」という用語は、複数の要素が相互に直接物理的に接触するか電気的に接触することを示すことがあり、「結合される」という用語は、複数の要素が相互に協働するか対話することを示すことがあるが、これらの要素は、直接物理的又は電気的に接触していてもよく、接触していなくてもよい。また、類似又は同じ符号を用いて、異なる図の同じ又は類似の部分を指示することがあるが、このようにすることは、同様又は同じ符号を有する全ての図が単一又は同一の実施形態を構成することを意味するものではない。
【０００５】
実施形態は、電力消費のようなコンピューティングノードグループの挙動の知識を用いて、コンピューティングストラテジを改善するシステムを含む。例えば（単一のコンピューティングノードの挙動とは反対に）コンピューティングノードグループの挙動に基づいて、実施形態は、利用可能なコンピューティングリソースを効率的に使用するため、コンピューティングタスクを、コンピューティングノードのネットワーク内に含まれる特定のコンピューティングノードに送る（例えばリダイレクトするか、負荷バランシングする）（が、そのネットワーク内の他のコンピューティングノードには送らない）ことを決定することができる。これは、「シリコンレベル」（例えばサーバのような個々のコンピューティングノード）及び／又は大きなグループレベル（例えばデータセンタ）で得られるデータに依拠する「電力調整（power  tuning）」を要する。電力調整は、例えばコンピュータ負荷バランシングにより電力消費を幾つかのコンピューティングノードの間で分散させることに関連する。
【０００６】
実施形態は、分析用のクラウドベースのモジュール（しばしば「分析クラウドモジュール」又は「クラウドモジュール」と呼ばれる）を含み、このクラウドベースのモジュールにおいて、コンピューティングノード（例えばデータセンタ内のサーバ）の動作データ（例えば電力効率、計算負荷分散及び／又は集中等）がプロファイルされ、格納される。動作データに基づいて、クラウドモジュールは、電力又は動作の最適化スキームを構築し、関連するフィードバックをコンピューティングノード（例えばサーバ、タブレット、モバイルコンピューティングユニット）に提供することができる。この最適化は、負荷バランシングに関するが、これだけに限定されない。ユーザは、グラフィカルユーザインタフェース（ＧＵＩ）を介して特定のノードの電力消費履歴、ピーク電力消費、データ転送レート等を見ることができる。ユーザは次いで、特定のノードの電力効率を、他の類似のノードについての履歴メトリックから収集される業界データ（industry  data）と比較することができる。
【０００７】
サーバラック、１つのデータセンタ、複数のデータセンタ等について電力効率を最適化するために、実施形態は、個々のノードの電力挙動データの主要な態様のトラックを続ける。このデータは収集されて格納される。データを「連続して」収集し、かつ／又は長い期間にわたって収集し、個々のコンピューティングノードの電力消費パターン並びにより大きなコンピューティングノードグループのより「マクロ」なビューを決定するのに分析され得る、データセットを構築することができる。データセットはその後、電力の効率的最適化を助長するのに使用され得るパターン／関係を見つけるために、検査（例えば「マイニング」）され得る。
【０００８】
実施形態は、電力データをプロファイルし、そのデータを分析して電力メトリック（測定の単位）を取得し、次いでこれらのメトリックに基づいて、１つ又は多くのコンピューティングノードについて電力消費を最適化する。コンピューティングノードは、遠くの距離にわたって広く分散され得るが、本明細書で説明されるプロファイル、分析及び最適化のいずれか又は全てを処理するクラウドモジュールにより、管理され得る。
【０００９】
一実施形態は、テレメトリシステムを含み、このテレメトリシステムは分析クラウドモジュールに結合してもよく、結合しなくてもよい。例えば図１は、コンピューティングノードグループ１０５、１０６、１０７をそれぞれ含むデータセンタ１０１、１０２、１０３を含む。データセンタは、１個、１０個、２０個、３０個又はそれ以上のコンピューティングノード（例えばサーバ）といった、少数又は多数のコンピューティングデバイスを含んでよい。したがって、コンピューティングノードグループ１０５、１０６、１０７は、単一のコンピューティングノード（例えばサーバ、スマートフォン、タブレット）、複数のコンピューティングノードの大きなグループ（例えば２０又はそれ以上のサーバ）あるいは上述のグループより多くの又は少ない何らかの他の数を含み得る。
【００１０】
データセンタ１０１、１０２、１０３はそれぞれ、テレメトリシステム１１０、１１１、１１２を介して分析クラウドモジュール１２０に結合する。分析クラウドモジュール１２０は、テレメトリシステム１１０、１１１、１１２からの入力を分析する。分析クラウドモジュール１２０は、リアルタイムモニタリングモジュール１３０のような様々なモジュールを含んでよい。リアルタイムモニタリングモジュール１３０は、システム１０１、１０２、１０３のリアルタイムモニタリングを提供する。分析クラウドモジュール１２０は履歴モジュール１３１を含んでもよく、履歴モジュール１３１は、システム１０１、１０２、１０３の性能をログ記録し、かつシステム１０１、１０２、１０３及び／又は他のシステムから収集した履歴情報を含み得る。上記の他のシステムは、システム１０１、１０２、１０３と積極的にネットワーク化されてもよく、ネットワーク化されていなくてもよい。分析クラウドモジュール１２０は、分析オーバービューモジュール１３２を含んでもよく、この分析オーバービューモジュール１３２は、モジュール１３０及び／又は１３１からの入力を収集し、最適化提案１３３（例えば負荷バランシング又はシステム構成に関するコンピュータ命令又はコマンド）のような出力を、システム１０１、１０２、１０３及び／又は他のシステムといったシステムに提供する。
【００１１】
図１のコンポーネント間（例えばデータセンタ１０１とクラウドモジュール１２０との間）の接続インフラストラクチャは、例えばＴＣＰ／ＩＰネットワーク、企業内ネットワーク、公衆インターネット等に基づくものであってよい。
【００１２】
図２は、テレメトリシステムを備える本発明の実施形態を示す。テレメトリシステムは、例えば図６のシステム６００（下述）において具現化されてよい。テレメトリシステム２１０は、電力挙動データのようなデータを、コンピューティングノードの様々なコンポーネントから取得することができる。例えばテレメトリシステム２１０は、温度、キャッシュミス及び／又はチャネルアクセスに関するデータをメモリ２２１から受け取ることがある。テレメトリシステム２１０は、温度、変換索引バッファ（ＴＬＢ：translation  lookaside  buffer）ミス及び／又は実行される命令又は動作に関するデータをプロセッサ２２５から受け取ってもよい。テレメトリシステム２１０は、インタラプト、デバイスアクセス、データ転送レート及び／又は応答レートに関するデータを入出力（Ｉ／Ｏ）バス２３０から受け取ってもよい。
【００１３】
テレメトリシステム２１０は、例えば温度、電流引き込み（current  drawn,）及び／又は電圧レベルに関するデータを、プラットフォームセンサ２３５から受け取ってもよい。一実施形態において、テレメトリシステム２１０は、テレメトリデータを、センサ２３５内に含まれる分散型の物理センサ及び論理センサのセットからキャプチャしてもよい。物理センサは、分散型温度センサ（例えばサーミスタ）、電圧メータ（例えば電圧計）、電流メータ（例えば電流計又はマイクロ電流計）、信頼性インジケータ（例えばＴＬＢミス用のカウンタ）、動作カウンタ、秒／分ごとの回転（revolution）を含む。論理センサは、例えばデータ転送レート、エラーレート、サービス応答時間、信号対雑音比及び周波数応答といった、オペレーティングシステムメトリックとサービス品質（ＳＯＣ）メトリックを含む。
【００１４】
テレメトリシステム２１０は、収集したデータを「データコレクタ」メモリ２１１に格納し得る。実行モジュール２１２は、メモリ２１１内に格納されたデータを実行するための制御ロジックを含み得る。図６に関してより深く検討される制御ロジックを含み得る実行モジュール２１２は、コンポーネント２２１、２２５、２３０、２３５又は他のコンピューティングノード若しくはコンピューティングノードグループからの他のコンポーネントからの、リアルタイムモニタリング値、データログ、履歴傾向及び／又はリアルタイムデータと履歴データとの間の比較を提供し得る。しかしながら、別の実施形態では、実行モジュール２１２は、生のデータを分析クラウドモジュール２２０に提供してもよく、その後、分析クラウドモジュール２２０がコンポーネント２２１、２２５、２３０、２３５又は他のコンピューティングノード若しくはコンピューティングノードグループからの他のコンポーネントからの、リアルタイムモニタリング値、データログ、履歴傾向及び／又はリアルタイムデータと履歴データとの間の比較を提供する。分析クラウドモジュール２２０は、このデータを受けて、最適化提案２４０をテレメトリシステム２１０に提供し得る。そのような提案は、コンピューティングジョブを、コンピューティングノードのグループのうちの１つのサーバから、コンピューティングノードの同じグループ内又はコンピューティングノードの別のグループ内の別のサーバへシフトすることであり得る。これらの提案は、コンピュータ命令の形式で作成され得るが、実装及び／又は考慮事項のために、コンポーネント２２１、２２５、２３０、２３５とは別個のコンピューティングノードハードウェア及び／又はソフトウェア２４５に、並びに／あるいはコンポーネント２２１、２２５、２３０、２３５に渡されることがある。
【００１５】
テレメトリシステム２１０は、データを、単一のサーバ、サーバラック又はサーバのグループを含む可能性がある１つ又は複数のコンピューティングノードから（積極的又は受動的に）取得し得る。特に、テレメトリシステム２１０は、データをコンポーネント２２１、２２５、２３０、２３５から受動的に受け取ってもよく、あるいはこの情報について、例えばコンポーネント２２１、２２５、２３０、２３５にポーリングしてもよい。
【００１６】
複数のテレメトリシステムが、図１のデータセンタ１０１、１０２、１０３とクラウドモジュール１２０との間に含まれるシステム１１０、１１１、１１２のような、複数のコンピューティングノードをトラックするのに必要とされることがある。しかしながら、物理的な位置及び分布は変えられる。本明細書で使用されるとき、モジュールという用語は、任意のハードウェア、ソフトウェア、ファームウェア又はその組み合わせを指す。多くの場合。別個のものとして図示されているモジュール境界は一般に変化するものであり、潜在的に重複する。例えば第１及び第２のモジュールは、幾つかの独立のハードウェア、ソフトウェア又はファームウェアを潜在的に保持しつつ、ハードウェア、ソフトウェア、ファームウェア又はその組み合わせを共有することがある。モジュールは、同じウェハ、基板、チップセット上に含まれてもよく、幾つかの基板、短距離又は長距離にわたるパッケージにわたって分散されてもよい。したがって、システム１１０、１１１、１１２は別個にそれぞれ、別個にそれぞれデータセンタ１０１、１０２、１０３内に配置されてよく、これらのデータセンタ自体が相互にリモートに配置される。しかしながら、システム１１０、１１１、１１２は別個にそれぞれ、データセンタ１０１、１０２、１０３とクラウドモジュール１２０との間であってよい（ただし、データセンタ１０１、１０２、１０３内には配置されない）。システム１１０、１１１、１１２は別個にそれぞれ、クラウドモジュール１２０内に含まれてもよい（コンポーネント１１０、１１１、１１２、１２０を含む破線のブロック１４０を参照されたい）。更に他の実施形態では、システム１１０、１１１、１１２は単一のパッケージに含まれ、共通のハードウェア及びソフトウェアを使用し、クラウドモジュール１２０、データセンタ１０１、１０２、１０３又はこれらの間若しくはこれらに結合される任意のポイントのいずれかに含まれてよい。クラウドモジュール１２０自体は、データセンタ１０１、１０２、１０３のうちの１つ又はグループ１０５、１０６、１０７内に含まれるコンピューティングノードのいずれかに配置され得る。
【００１７】
図３は、分析クラウドモジュールを備える本発明の実施形態を示す。分析クラウドモジュール３２０は、直接又は間接的に（例えばテレメトリシステムを介して）コンピュータノードグループ３０５、３０６、３０７に結合される。コンピュータノードグループ３０５、３０６、３０７は、例えばプロセッサとメモリの温度、Ｉ／Ｏトラフィック及びＴＬＢミス等をクラウドモジュール３２０に提供することができる。コンピューティングノードグループ３０５は、例えば単一のコンピューティングノードを含んでもよく、多くのコンピューティングノードを含んでもよい。一実施形態において、分析クラウドモジュール３２０は、コンピュータノードグループ３０５、３０６、３０７から直接受け取るか、あるいはコンピュータノードグループ３０５、３０６、３０７からテレメトリシステムを介して間接的に受け取ったこのデータを格納し、トラックし、分析することができる。このデータは、１つのコンピューティングノードに特有のものであってよく、複数のコンピューティングノードにより一般的に関連するもの（例えばコンピューティングノードのグループ全体にわたって配置されるメモリモジュールにより引き込まれる平均電流）であってもよい。
【００１８】
上述のように、クラウドモジュール３２０は、（例えば負荷バランシングに関する）最適化提案（例えばコマンド）３４０を、テレメトリシステム３１０、並びに／あるいはオペレーティングシステム（ＯＳ）及びデータセンタ管理ハードウェア及び／又はソフトウェア３４１に提供することがある。テレメトリシステムは、提案３４０に照らして電力効率を最適化するようコンピューティングシステムノードのソフトウェア及び／又はハードウェアを設定するエージェントとして機能し得る。提案３４０はその後、コンピューティングノードグループ３０５、３０６、３０７に通信され、クラウドモジュール３２０にデータを提供しないコンピューティングノードグループ３０８にも通信され得る。
【００１９】
本発明の実施形態は、サーバのような参加コンピューティングノードから、そのノードが実行しているソフトウェアに関わらず、電力挙動データを集約する。例えば温度に関して、このデータは、ソースを示すヘッダと、温度測定値を示すペイロードとを有する一般的な通信パッケージで提供されてもよい。したがって、クラウドモジュール３２０は、大量の電力利用及び一般的なコンピューティングノードの動作データを収集する。これらのデータを、次いで、（以下で更に検討される）データマイニングモジュールにより処理して、サーバのグループ、１のデータセンタ又は複数のデータセンタ間における電力消費パターンを分析して見つけることができる。したがって、システム３００は、電力効率を、任意の単一の演算ノード並びに任意のコンピューティングノードのラック、１つ又は複数のコンピューティングノードグループについて、あるいは全体的な対象物としてデータセンタについてさえも、電力効率を調査して調整し、対応するエネルギ効率を最適化する。
【００２０】
一実施形態は、変化する分析粒度レベルを提供することができる。例えば単一の実施形態は、例えば単一のコンピューティングノードの単一のメモリモジュール用のカウントを読み、書き、アクティブ化することのように、細かい粒度で低レベルのシリコン電力挙動を提供することがある。この種の詳細なデータは、電力分析クラウドモジュール３２０に伝達されてもよい。クラウドモジュール３２０は、グラフィカルユーザインタフェース（ＧＵＩ）ダッシュボードを提供することができ、このＧＵＩダッシュボードから、ユーザは、リアルタイム電力消費、レジスタカウンタ、電力メータ値等を含むリアルタイム電力挙動を、様々な粒度で、単一のマシン（低レベル）、コンピューティングノードのラック全体（中程度のレベル）並びに／あるいは１つ又は複数のデータセンタにおけるマシンの一部又は全体（高レベル）からモニタリングすることができる。クラウドモジュール３２０は、モニタリングする全ての単一のコンピューティングノードの電力利用履歴を格納してよく、また、利用についての視覚的表現を提供して、様々な時間範囲において、選択されたコンピューティングノードについての電力データのユーザレビューを助ける。したがって、実施形態は、ユーザが、「低レベル」（例えば個々のサーバ）から「高レベル」（例えばデータセンタ）までのものを見ることを可能にする。
【００２１】
データマイニングモジュール３２１は、既知のデータマイニング技術を用いる実施形態において、特定のノードの生産性が低い時の時刻といった関連性を決定できるようにする（例えば恐らくは、大気環境が温かく、問題となっているノードの効率に悪影響を与える時の時期及び時刻を相関させる）。データマイニングモジュール３２１は、単一の参加ノードをモニタリングして、そのノードについて（及びモジュール３２１がモニタリングする多くの他のノードについて）集約された大量の電力挙動データを取得し、モジュール３２１がモニタリングするノードについて履歴プロファイルを生成することができる。これらのプロファイルは、特定のプロセッサの平均温度がＸであることを示すことがあり、これは、そのプロセッサの製造業者によって提案されている温度よりもかなり高い。この蓄積されたデータを用いて、クラウドモジュール１２０は、特定のプロセッサが、Ｘと比べてか高すぎる温度で実行していると決定し、続いて演算負荷をそのプロセッサから他のコンピューティングリソースへ分岐させることができる。
【００２２】
クラウドモジュール３２０は、例えばデータセンタの全体的な電力消費量を、業界標準（例えばグループ３０５、３０６、３０７に特有ではない標準）と、あるいはクラウドモジュール３２０によって収集又はインポートされる履歴データ（例えばグループ３０５、３０６、３０７に特有の履歴データ、あるいは他のグループに加えて、グループ３０５、３０６、３０７に少なくとも基づく履歴データ）とより良く比較する方法のような、情報を提供してもよい。クラウドモジュール３２０は、したがって、例えばサーバが（例えば標準以下のデータレートの伝送を提供する）ボトルネックであり、これらのボトルネックが生じる時間における、電力消費履歴、ピーク電力値、ピーク電力消費時間を分析することができる。
【００２３】
図４は、分析クラウドモジュールを含む本発明の実施形態を示す。図４は、コンピューティングノードのグループ４０１を考慮しており、したがって、（単一のコンピューティングノードに関する）図２よりも粒度レベルが高く、（コンピューティングノードの幾つかのグループに関する）図３の粒度レベルよりも低い。システム４００は、データマイニングモジュール４２１を備えるクラウドモジュール４２０を含み、データマイニングモジュール４２１は、コンピューティングノード４０５、４０６、４０７（例えばサーバ）に結合されて、メモリ最適化提案／コマンド４４０をテレメトリシステム４１０に提供する。メモリ最適化提案／コマンド４４０は次いで、グループ４０１及び／又は別のコンピューティングノード４０８に通信される。テレメトリシステムは、図４のように配置されてもよく、あるいはノード４０５、４０６、４０７のうちのいずれかと、クラウドモジュール４２０との間に配置されてもよい。
【００２４】
一実施形態において、コンピューティングノード４０５、４０６、４０７がそれぞれ、メモリアクセスデータ、メモリ電力消費データ等をクラウドモジュール４２０に提供し、クラウドモジュール４２０は次いで、メモリアクセスパターン及び電力消費データを分析することにより、メモリ電力消費及び全体的なメモリ性能を最適化することができる。参加サーバからの大きなスケールのデータは、電力分析クラウドモジュールがスキーマを構築し、かつメモリ構成、アクセスパターン及び電力消費の間の相関性を見つけて最適化提案を提供すること（例えばどのメモリ管理スキームが、特定のタイプの演算負荷に最も良く機能するかを決定すること）を可能にする。最適化提案は、次いでテレメトリシステム４１０に送信され、テレメトリシステム４１０は、これに応じて、サーバノード４０５、４０６及び／又は４０７のハードウェア及び／又はソフトウェアを構成する。
【００２５】
図５は、分析クラウドモジュールを備える本発明の実施形態を示す。図５は、図５における粒度に関して、例えばサーバのような単一のコンピューティングノードの低レベルの分析に関する図２と類似する。システム５００は、データマイニングモジュール５２１を備えるクラウドモジュール５２０を含み、クラウドモジュール５２０は、サーバ５０５に結合されて、電力最適化提案／コマンド５４０をテレメトリシステム５１０に提供する。テレメトリシステム５１０は、一実施形態では、サーバ５０５とクラウドモジュール５２０との間に配置され得る。クラウドモジュール５２０は、サーバ５０５及び／又は別のコンピューティングノード５０８のための最適化提案を、そのサーバからの様々な論理及び／又は物理メトリックを相関させることにより提供する。論理メトリックは、例えばメモリ利用、プロセッサ利用／ワークロード、規定されるプロセスの数及び実行されるスレッドの数を含む。物理メトリックは、例えばプロセッサの温度、メモリ又は任意の他のコンポーネントの温度、ネットワークアクティビティのためのデータ転送レート、ＴＬＢミス等を含む。このプロセスは、クラウドモジュール５２０に関連する残りのコンピューティングノード（図５には図示せず）において実装されてよい。
【００２６】
実施形態は、多くの異なるシステムタイプで実装されてもよい。ここで図６を参照すると、本発明の実施形態に係るシステムのブロック図が示されている。システム６００を使用して、例えばテレメトリシステム１１０、分析クラウドモジュール１２０、データセンタ１０１、サーバグループ１０５内の任意のサーバあるいはクラウドモジュール１２０を介して分析及び／又は管理される任意のコンピューティングノード（例えばラップトップ、携帯電話、スマートフォン、モバイルコンピューティングノード、ウルトラブック（登録商標）、デスクトップ、ノートブック、パーソナルデジタルアシスタント）を実装することができる。マイクロプロセッサシステム６００は、ポイントツーポイント相互接続システムであり、ポイントツーポイント相互接続６５０を介して結合される第１のプロセッサ６７０と第２のプロセッサ６８０を含む。プロセッサ６７０及び６８０はそれぞれ、マルチコアプロセッサであってよい。「プロセッサ」という用語は、レジスタ及び／又はメモリからの電子データを処理して、その電子データをレジスタ及び／又はメモリ内に格納可能な他の電子データに変換する、任意のデバイス又はデバイスの一部を指すことがある。第１のプロセッサ６７０は、メモリコントローラハブ（ＭＣＨ）及びポイントツーポイント（Ｐ−Ｐ）インタフェースを含み得る。同様に、第２のプロセッサ６８０は、ＭＣＨ及びＰ−Ｐインタフェースを含み得る、ＭＣＨは、これらのプロセッサをそれぞれのメモリ、すなわちメモリ６３２とメモリ６３４に結合してよく、これらのメモリは、それぞれのプロセッサに対してローカルに取り付けられるメインメモリ（例えば動的ランダムアクセスメモリ（ＤＲＡＭ））の一部であってよい。第１のプロセッサ６７０及び第２のプロセッサ６８０は、それぞれＰ−Ｐ相互接続を介してチップセット６９０に結合され得る。チップセット６９０はＰ−Ｐインタフェースを含み得る。さらに、チップセット６９０は、インタフェースを介して第１のバス６１６に結合されてよい。様々なＩ／Ｏデバイス６１４が、バスブリッジ６１８とともに第１のバス６１６に結合されてよく、バスブリッジ６１８が第１のバス６１６を第２のバス６２０に結合する。様々なデバイスが、第２のバス６２０に結合されてよく、そのようなデバイスには、例えばキーボード／マウス６２２、通信デバイス６２６及びディスクドライブや大容量記憶デバイスといったデータ記憶ユニット６２８が含まれ、一実施形態において、データ記憶ユニット６２８はコード６３０を含んでもよい。コードは、メモリ６２８、６３２、６３４、システム６００にネットワーク経由で結合されるメモリを含め、１つ又は複数のメモリ内に含まれ得る。さらに、オーディオＩ／Ｏ６２４も第２のバス６２０に結合され得る。
【００２７】
諸実施形態は、コードとして実装されてよく、命令を実行するようシステムをプログラムするのに使用することができる命令を格納する記憶媒体上に格納され得る。記憶媒体は、フロッピー（登録商標）ディスク、光ディスク、半導体ドライブ（ＳＳＤ）、コンパクトディスク読み取り専用メモリ（ＣＤ−ＲＯＭ）、コンパクトディスク書き換え可能媒体（ＣＤ−ＲＷ）及び磁気光学ディスクを含む任意のタイプのディスクと、動的ＲＡＭ（ＤＲＡＭ）、静的ＲＡＭ（ＳＲＡＭ）、ＥＰＲＯＭ、フラッシュメモリ、ＥＥＰＲＯＭ、磁気若しくは光カード又は電気的命令を格納するのに適した任意の他のタイプの媒体といったＲＯＭやＲＡＭのような半導体デバイスを含み得るが、これらに限定されない。
【００２８】
本発明の実施形態は、ここでは命令、関数、プロシージャ、データ構造、アプリケーションプログラム、構成設定及びコード等のようなデータに関連して説明されてもよい。データがマシンによってアクセスされると、マシンは本明細書で更に詳細に説明されるように、タスクを実行し、抽象データ型を定義し、低レベルのハードウェアコンテキストを確立し、かつ／又は他の動作を実行することにより応答することができる。データは、揮発性及び／又は不揮発性データストレージに格納され得る。「コード」又は「プログラム」という用語は、アプリケーション、ドライバ、プロセス、ルーチン、メソッド、モジュール及びサブプログラムを含め、広い範囲のコンポーネント及び構造体を包含しており、またこの用語は、処理システムによって実行されると所望の１つ又は複数の動作を実行する命令の任意の集合を指すこともある。加えて、代替的な実施形態は、開示される動作の全てよりも少ない動作を使用する処理と、追加の動作を使用する処理と、同じ動作を異なる順序で使用する処理と、本明細書で開示される個々の動作を組み合わせるか、細分又は他の方法で変更する処理を含んでもよい。一実施形態において、制御ロジックという用語の使用は、トランジスタ、レジスタ又はプログラム可能な論理デバイス（６３５）のような他のハードウェアのようなハードウェアを含む。しかしながら、別の実施形態では、ロジックはソフトウェアコード（６３１）を含む。そのようなロジックは、ファームウェア又はマイクロコード（６３６）のようにハードウェアに統合され得る。プロセッサ又はコントローラは、本技術分野で公知の多様な制御ロジックのうちのいずれかを表すように意図された制御ロジックを含んでよく、したがって、マイクロプロセッサ、マイクロコントローラ、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）、プログラマブル論理デバイス（ＰＬＤ）等としてより良好に実装され得る。
【００２９】
図７は、本発明の実施形態における方法を含む。ブロック７０５は、第１のコンピューティングノードに特有であるが、第２のコンピューティングノードには特有ではない、第１の電力メトリックを決定することを含む。ブロック７１０は、第２のコンピューティングノードに特有であるが、第１のコンピューティングノードには特有ではない、第２の電力メトリックを決定することを含む。第１の及び第２の電力メトリックは、例えば温度、電圧、電流、実行された命令カウント、メモリアクセス、書き込みカウント、読み取りカウント、ＱＯＳ、キャッシュミス、データ転送レート、エラーレート、サービス応答時間、信号対雑音比及び周波数応答等のうちの１つ又は複数に対応し得る。第１及び第２の電力メトリックは、同じメトリックの異なるインスタンスに対応してもよく（例えば双方が、第１及び第２のコンピューティングノード内にそれぞれ含まれるメモリによって引き込まれる電流に対応してもよい）、あるいは異なるメトリックに対処してもよい（例えば第１のメトリックが、第１のコンピューティングノード内のメモリの温度に対応し、第２のメトリックが、第２のコンピューティングノードのメモリによって引き込まれる電流に対応してもよい）。これは、「低レベル」又は低い粒度の分析を構成し得る。というのも、これは、特定のコンピューティングノード又はコンピューティングノードの一部に関することだからである。一実施形態において、クラウド分析モジュールは、第１及び第２の電力メトリックを、リモートに配置された第１及び第２のコンピューティングノード（又はこれらのノードに対応するテレメトリシステム）からこれらの値を単純に受け取ることにより決定してもよい。他の実施形態において、値を決定することは、クラウドモジュールがその値を実際に決定することを含むことがある（例えばクラウドモジュールに通信される抵抗データに基づいて、電流レベルを決定する）。
【００３０】
ブロック７２０において、クラウドモジュールは、第１及び第２のコンピューティングノードを含むコンピューティングノードのグループに対応する、グループ電力メトリックを決定することができる。例えば第１及び第２のコンピューティングノードの双方が単一のサーバラックに含まれることがある。各コンピューティングノード（この例ではサーバとすることができる）がメモリを有する。第１及び第２の電力メトリックはそれぞれ、そのラック内に１つ又は複数のサーバ内に含まれる第１及び第２のメモリについての平均メモリアクセス／分を備え得る。グループ電力メトリックは、これらの値の双方に基づく平均メモリアクセス／分を含み得る。したがって、グループメトリックは、低い粒度の第１及び第２のメトリックに基づくが、第１又は第２のコンピューティングノードのいずれかに対して特有なものではない。グループメトリックは、任意の１つの特定のノードよりも高い粒度の分析を有する。
【００３１】
ブロック７２５は任意であり、この任意性を示すために破線で示されている。ブロック７２５において、分析クラウドモジュールは、グループ電力メトリックをプロファイルデータと比較することができる。例えばプロファイルデータは、特定のアクセス数／分を経験しているメモリモジュールについて引き込まれるべき平均電流レベルを含み得る。このプロファイルデータは、分析クラウドモジュールによってリモートデータベースから受け取られることがある。しかしながら、分析クラウドモジュールは、代わりに、第１及び第２のコンピューティングデバイスから並びに／あるいは第１及び第２のコンピューティングデバイスと同じグループ内に含まれるか又は含まれないこともある他のコンピューティングノードからのデータの履歴的蓄積に基づいて、プロファイルデータを決定してもよい。グループ電力メトリックは、例えば第１及び第２のコンピューティングノード内のメモリモジュールによって引き込まれている平均電流レベルを含むことがある。
【００３２】
ブロック７３０において、決定されたグループ電力メトリックに応じて、コンピューティングタスクを、第１及び第２のコンピューティングデバイスには分散させずに、第３のコンピューティングノードに分散することを含むことができる。これは例えば負荷バランシングを伴うことがある。例えばコンピューティングノードグループのために引き込まれている平均電流が、プロファイル値をｘ％（例えば１５％）より多く超えており、その電流平均がｙ分（例えば５分）より長く維持されていると決定すると、分析クラウドモジュールは、第１の電力メトリック及び／又はグループ電力メトリックを決定したことに応答して、コンピューティングワークロードを、第１のコンピューティングノードから第３のコンピューティングノードにシフトしてよい。ワークロード（例えば命令）は、当初は（例えば中央コントローラの決定、負荷分散についてのスタンディングインストラクション等に基づいて）第１のコンピューティングデバイスに向けられていたが、第１の電力メトリック、グループ電力メトリック等の分析に基づいて再配向された。
【００３３】
ブロック７１５は、第１及び／又は第２のコンピューティングノードから収集したデータに基づいて履歴プロファイルを構成することを含んでよい。プロファイルは、１つ又は複数の分析クラウドモジュールに通信され得る。１つ又は複数のクラウドモジュールは、次いでこのプロファイル情報を用いて、例えば電力の保護に関する提案を作成することができる（例えばブロック７２５を参照されたい）。
【００３４】
第１のコンピューティングノードは、第２のコンピューティングノードに含まれる第２のサーバとは別個であり、かつ第２のサーバ内には含まれない、第１のサーバを含み得る。第１及び第２のコンピューティングノードは、第３のコンピューティングノードを含まないコンピュータクラスタ内に含まれ得る。コンピュータクラスタは、クラスタ内に含まれるか又は含まれないコンピューティングノードによって多くの点で単一のシステムとして見られるよう一緒に動作する、緩く接続されたコンピュータのセットで構成されてよい。
【００３５】
本発明の一実施形態における負荷バランシングのための処理を、ここで詳細に検討する。上述のように、負荷バランシングのストラテジは、分析クラウド（例えばクラウド１２０）において決定され、命令として様々なコンピューティングノードへ通信され得る（ブロック１３３）。一実施形態において、負荷バランシングは、ジョブや負荷（まとめてワークロードを含む）のスケジューリング又はマイグレートをガイドする特定の制約を満たしつつ、複数のコンピューティングノードにわたってワークロードを分散させることに関する。これらの制約は、コンピューティングノードインフラストラクチャ（例えばサーバインフラストラクチャ）の効率的な動作のための境界条件をガイドする実行可能な限界（viable  limit）を部分的に又は十分に定義する。例えばワークロードは、サービス目標を満たすのに必要な電力要件を最小限にしつつも、そのワークロード／演算ノードの組み合わせがサービス目標（例えばクエリの応答時間）を満たすように特定のコンピューティングノードに配置され得る。しかしながら、多数のコンピューティングノードの中で適切な１つのコンピューティングノード（例えばサーバ）又は複数のコンピューティングノード（例えばサーバラック又はサーバクラスタ）を識別することは、（以下で説明される）「ＮＰ完全問題」である。一実施形態は、グローバル最適化方程式（global  optimization  equation）を使用して、その候補の解の適合性の評価を通して候補の解を検証する。
【００３６】
一側面として、計算量のセオリーにおいて、ＮＰ（非決定性多項式時間）は基本的な複雑性クラス（fundamental  complexity  class）である。ＮＰは、全ての決定問題のセットである。その問題について、回答が「はい（ｙｅｓ）」である全てのインスタンスが、その回答が実際に「はい」であるという事実について効率的に検証可能な証拠を有する。より正確には、これらの証拠は、決定性チューリング機械（deterministic  Turing  machine）により多項式時間内に検証可能であり得る。ＮＰはＮＰ完全問題を含み、（これらの問題は、多項式時間では検証され得るが）これらの問題を解くための多項式時間アルゴリズムは知られていない。
【００３７】
一実施形態において、Ａｎは、１つのノードの平均エネルギ消費であり、Ｂは、ノードのクラスタの平均電力消費である。負荷分散の目標が、ノード間におけるエネルギ割り当ての分散（variance）を低減することである場合、応答時間のようなサービスレベル目標（ＳＬＯ）を維持し、かつコンピューティングノードグループ又はクラスタの極限電力（Ｐｍａｘ）を観察するが、一実施形態では、以下のことを実装することができる：
【数１】
2015537309.tif 000003
【００３８】
式［１］〜［７］において、実施形態は、平均電力消費An(t)、応答時間Rn(t)をノード内の個々のコンポーネントの利用に基づいて予測する適合性関数を使用する。式の係数は、大きなサンプリング期間にわたるトレーニングのセットを使用してトレーニングされる。式がトレーニングされると、実施形態はマシン学習技術を使用し、（例えばコンピューティングノードの利用の増分的増加及び／又はあるコンピューティングノードから別のコンピューティングノードへの十分な又は部分的にマイグレートされる）追加の演算負荷がクラスタのシステム内に任意の数のノードに適用されるというシナリオをシミュレートすることによって適合性関数を予測する。
【００３９】
図８は、本発明の実施形態における負荷分散のためのシステムを含む。ＣＰＵ８２５は、１つ又は複数のコンピューティングノードの１つ又は複数のプロセッサからのデータ（例えば引き込まれた電流、処理された命令）を含み、メモリ８２１は、１つ又は複数のコンピューティングノードの１つ又は複数のメモリモジュールからのデータ（例えばメモリアクセス）を含み、そしてＩＯ８３０は、１つ又は複数のコンピューティングノードの１つ又は複数のＩＯユニットからのデータ（例えばＩＯトラフィック）を含む。ＩＯは、上記の式［１］〜［７］には現れてはいないが図８には含まれており、どのようにして実施形態がデータのいずれの１つのセットにも制限されないかを図示している。
【００４０】
ブロック８９０において、これらのデータは、分散低減（variance  reduction）を受ける。一実施形態において、ブロック８９０は、コンポーネント（ＣＰＵ８２５、メモリ８２１、ＩＯ８３０、ハードディスクドライブ（ＨＤＤ）等）の入力変数のための重みを、（１）出力値に最も相関され；（２）不連続性を生じ、出力値における閾値効果（threshold  effects）に寄与し；（３）双方の変数が分析された出力変数に（同一でない場合）非常に類似する方法で影響を与えるよう別の変数との高い程度の線形相関を有するときに、取り除かれる：入力変数を識別した後に選択する。選択された変数は、破棄された変数の係数を用いる。
【００４１】
ブロック８９０において、入力センサ／性能データは、変数低減（variable  reduction）を受ける。変数低減の目的は、システムのモデルの傾斜係数を分析及び比較するのを助けることであり、この場合、最大絶対値の傾斜係数に関連するコンポーネントの入力変数が、最上位（most  significant）と見なされる。大きな傾斜係数は、結果として出力変数では非常に大きな変化となる、入力変数の非常に小さな変化に対して、高い感度を示す。一実施形態は、データポイントのサンプリング枠をシフトさせることによって作成される、連続モデルを抽出する。各モデルは、サンプリングされたデータを連続モデルと共有する。これは、多次元の非線形モデルを、一連の線形モデルに変換する際の助けとなる。
【００４２】
ブロック８９１において、重みが適用される。各変数（Ucpu、Umemといったテレメトリコンポーネント）に、その変数の重要性に応じて割り当てられる重みが存在する。これらの重みは、式［５］及び式［６］では示されていないが、一実施形態では追加されてよい。変数の重要性は、その変数における変化に基づいて出力の感度を評価することにより推定される。トレーニングセットにおける非線形性を回避するために、一実施形態は、サンプルの定数（モデリング枠）によりトレーニングデータのサンプルセットの少ない割合をスライドさせることで重み（感度のファクタ）を評価する。このようにして、実施形態は、複数のサンプルを収集して、複数のモデリング枠を通して取得された重みを平均化する。
【００４３】
ブロック８９６は、所与の出力について変数の感度を評価するためである。言い換えると、ブロック８９６は、モデルを一旦トレーニングした後は必要とされないトレーニング基準（reference）として使用され得る。例えばブロック８９６は、電力推定の場合の電力メータを含み得る。
【００４４】
ブロック８９２では、複素変数が、電力推定値（８９７）を決定するために更なる変数が係数８９４とともに適用されるブロック８９３に照らして、決定される。ブロック８９２では、これらの複素変数は、入力（８９０）からの個々の変数の重み付けされた合計である。関数f1、f2では、複素変数はUdeviceによって表される。これらの変数は、出力（電力、ＳＬＯ等）に対するコンポーネント特有の寄与について低減された式を表す。
【００４５】
ブロック８９３は、複素変数（Udevice）を使用することにより線形又は非線形関数で形成されるモデル方程式を表す。図８で使用されるモデル方程式は、aX＋bXY＋cYZ＋dZ＋K＝出力［電力又はＳＬＯ］である。この方程式は関数f1、f2を表すこともでき、この場合、各方程式は複素変数の利用（Udevice）を表す
ブロック８９４は、係数ａ、ｂ、ｃ、ｄ、Ｋを含み、これらの係数は、ブロック８９６によって与えられる基準（測定された）出力及びトレーニングデータセットを使用して、回帰関数（図８の場合は、遺伝的アルゴリズム）の結果として評価される。トレーニングデータセットは、複素変数の値Ｘ、Ｙ、Ｚと、所与の期間の間に８９６によって与えられる、測定された出力を含む。
【００４６】
所与のモデルについての電力推定値は、演算負荷をどのノードに（及びどのくらいの割合を所与のノードに）バランスさせるべきかに関する提案（例えば図１のブロック１３３）を導出することができる。例えば最も低い電力推定値の負荷バランシングスキームが実装され得る。
【００４７】
テレメトリユニットを通して抽出されるデータ（図８のブロック８９６を参照されたい）は、幾つかのタスクを達成することができる。第１に、このデータを使用して、モデル方程式（例えば式［１］〜［７］）が、期待される結果から逸脱する電力推定を生じる場合に、これらのモデル方程式を修正することができる。一実施形態は、回帰分析（例えばサポートベクトルマシン）を使用して、モデルに対する動的な修正を実行し得る。第２に、システムが動的システムであり（図８のブロック８９５を介して決定されるように）要求の変化を示すので、上記のデータを使用して適合性関数（式［４］）を再計算することができる。この結果、ソース／ターゲットノードのセット間における負荷のマイグレーションが生じることになる。第３に、上記データを、電力消費、応答時間、スループット等の視覚的表現に使用してもよい。第４に、上記データは、ワークロードの属性を識別するのを助けることができ、このため、実施形態は、ワークロードの配置に役立つようにリソースの特性及び挙動を識別することができる。これらの属性は、例えば動作の段階、平均及びピーク利用及び／又は他のワークロードとの相互互換性（例えばキャッシュスラッシング、リソース競合）に関するものであってよい。これらの属性により、実施形態は、システムにおける既存の負荷との互換性並びに必要とされるリソースの利用可能性を識別することができる。
【００４８】
他の基準（例えば熱変化、キャッシュミス挙動）を、他のブロック（データセンタ内の環境センサ）に加えて、ブロック８２５、８２１、８３０のいずれかに追加してもよい。
【００４９】
実施形態は、少なくとも１つのプロセッサによって実行される方法を含み、この方法は、第１及び第２のコンピューティングノードを含むコンピューティングノードのグループに対応する第１の電力メトリックを決定するステップと；決定された第１の電力メトリックに応じて、コンピューティングタスクを、第１及び第２のコンピューティングノードには分散せずに、第３のコンピューティングノードに分散させるステップと；を含み、第３のコンピューティングノードは、第１及び第２のコンピューティングノードとはリモートに配置される。実施形態において、第１及び第２のコンピューティングノードは、第３のコンピューティングノードを含まないコンピュータクラスタ内に含まれる。実施形態において、第１の電力メトリックは、コンピューティングノードのグループに対して特有であり、第１及び第２のコンピューティングノードのいずれかには特有ではない。実施形態において、第１の電力メトリックは、温度、電圧、電流、実行される命令カウント、メモリアクセス、書き込みカウント、読み取りカウント、サービスの品質（ＱＯＳ）、キャッシュミス、データ転送レート、エラーレート、サービス応答時間、信号対雑音比及び周波数応答、のうちの１つに対応する。実施形態において、第１の電力メトリックは、第１のコンピューティングノードに対応する温度と、第２のコンピューティングノードに対応する別の温度とに基づく温度を含む。一実施形態において、第１の電力メトリックは、（ａ）第１のコンピューティングノードに特有であるが、第２のコンピューティングノードには特有でない電力メトリックと、（ｂ）第２のコンピューティングノードに特有であるが、第１のコンピューティングノードには特有でない追加の電力メトリックとの双方に基づく。実施形態は、第１のコンピューティングノードに特有の電力メトリックを、第２のコンピューティングノードから受け取るステップと；第２のコンピューティングノードに特有の電力メトリックを第２のコンピューティングノードから受け取るステップとを含む。実施形態は、第１のコンピューティングノードに特有の電力メトリックを決定したことに応答して、第１のコンピューティングノードから第３のコンピューティングノードへコンピューティングワークロードをシフトするステップを含む。実施形態は、コンピューティングノードのグループに非特有の履歴電力メトリックを決定するステップと；履歴電力メトリックに基づいて第１の電力メトリックを分析するステップと；履歴電力メトリックに基づいて第１の電力メトリックを分析したことに応答して、コンピューティングタスクを第３のコンピューティングノードに分散させるステップとを含む。実施形態は、第１の電力メトリックに基づいて、コンピューティングノードのグループに非特有の履歴電力メトリックを決定するステップを含む。実施形態において、履歴電力メトリックは、第１、第２及び第３のコンピューティングノードそれぞれからの電力メトリックデータに基づく。実施形態において、コンピューティングタスクを、第１及び第２のコンピューティングノードには分散せずに、第３のコンピューティングノードに分散させるステップは、決定された第１の電力メトリックに応じて、第１、第２及び第３のコンピューティングノードの間でコンピューティングタスクを負荷バランシングすることを含む。実施形態において、第１のコンピューティングノードは、第２のコンピューティングノードに含まれる第２のサーバとは別個であり、かつ該第２のサーバに含まれない、第１のサーバを含む。実施形態は、決定した第１の電力メトリックに応じて、第１及び第２のコンピューティングノードの一方から第３のコンピューティングノードへコンピューティングワークロードをシフトするステップを含み、当該コンピューティングワークロードをシフトするステップは、コンピューティングタスクを第３のコンピューティングノードに分散させることを含む。実施形態は、コンピューティングノードのグループに非特有の履歴電力メトリックに基づいて、第１の電力メトリックを分析するステップと；履歴電力メトリックに基づいて第１の電力メトリックを分析したことに応答して、コンピューティングタスクを第３のコンピューティングノードに分散させるステップとを含む。
【００５０】
実施形態は装置を含み、この装置は：少なくとも１つのメモリと；メモリに結合され、動作を実行する少なくとも１つのプロセッサと；を備え、上記動作は、第１及び第２のコンピューティングノードを含むコンピューティングノードのグループに対応する第１の電力メトリックを決定するステップと；決定された第１の電力メトリックに応じて、コンピューティングタスクを、第１及び第２のコンピューティングノードには分散せずに、第３のコンピューティングノードに分散させるステップと；を含み、第３のコンピューティングノードは、第１及び第２のコンピューティングノードとはリモートに配置される。実施形態において、コンピューティングタスクは、第１のコンピューティングノードに向けられるが、決定された第１の電力メトリックに応答して第３のコンピューティングノードへルート変更（reroute）される。実施形態において、第１の電力メトリックは、コンピューティングノードのグループに対して特有であり、第１及び第２のコンピューティングノードのいずれかには特有ではない。
【００５１】
本発明は、限られた数の実施形態に関連して説明されているが、当業者は、この実施形態から様々な修正及び変形を認識するであろう。添付の特許請求の範囲は、そのような修正及び変形が本発明の真の精神及び範囲内にある限りにおいて、これらの全ての修正及び変形を包含するように意図される。
【図１】
2015537309.tif 000004
【図２】
2015537309.tif 000005
【図３】
2015537309.tif 000006
【図４】
2015537309.tif 000007
【図５】
2015537309.tif 000008
【図６】
2015537309.tif 000009
【図７】
2015537309.tif 000010
【図８】
2015537309.tif 000011
【国際調査報告】
2015537309.tif 000012
2015537309.tif 000013