JP2011505784A - データセンタのための電力効率測定 - Google Patents

Abstract

データセンタの電力効率の管理方法は、データセンタ内の複数の場所で初期電力測定を行なうステップと、初期電力測定に基づいてデータセンタの効率モデルを確立するステップと、効率モデルを用いてベンチマーク性能レベルを確立するステップと、継続電力測定を行なうステップと、継続電力測定の結果をベンチマーク性能レベルと比較するステップとを含む。電力効率を管理するおよび電力効率をモデル化する他の方法ならびにシステムがさらに開示される。

Description

開示の背景
この発明は、該して、データセンタの電気効率を改善するための方法およびシステムに関する。

データセンタのある局面については十分に計画がなされるが、データセンタ電気効率を計画または管理することはまずない。その結果、残念なことにほとんどのデータセンタは、相当の量の電気を浪費している。したがって、データセンタ効率を計画、測定およびモデル化することによってデータセンタの電気効率を改善することが望ましい。効率を改善すると、ユーザは、電力消費を削減できるだけでなく、ＩＴ電力密度を高めて、所与の場所により多くのＩＴ機器を導入できるようになる。

開示の概要
この開示の少なくともいくつかの実施例は、データセンタ効率の測定、評価および改善に関する。

この開示に少なくとも１つの局面は、データセンタの電力効率の管理方法に関する。１つの実施例において、この方法は、データセンタ内の複数の場所で初期電力測定を行なうステップと、初期電力測定に基づいてデータセンタの効率モデルを確立するステップと、効率モデルを用いてベンチマーク性能レベルを確立するステップと、継続電力測定を行なうステップと、継続電力測定の結果をベンチマーク性能レベルと比較するステップとを含む。

この方法において、継続電力測定を行なうステップは、プロセッサベースのデータセンタ管理システムを測定機器とともに用いるステップと含んでもよい。この方法は、さらに、継続電力測定の結果がベンチマーク性能レベルと指定量よりも大きく異なる場合、警告を出すステップを含んでもよい。効率モデルを確立するステップは、効率モデルを確立するためにデータセンタの所在地に関連した気候に関するデータを用いるステップを含んでもよい。別の実施例において、効率モジュールを確立するステップは、データセンタで用いられる、電力を引き込む装置を特定するステップと、各装置について、その装置の電力入力の定格容量および使用可能容量のうち１つを選択するステップと、各装置に対して、その装置が固定損失、比例損失、あるいは二乗法則損失、またはそれらの組合せとして寄与しているのかどうかを決定するステップとを含んでもよい。もう１つの実施例において、効率モジュールを確立するステップは、さらに、データセンタ損失を得るために装置の電力損失を集約するステップおよび／またはサブシステムの電力損失を集約するステップを含んでもよい。

この開示の別の局面は、データセンタの電力効率を管理するためのデータセンタ管理システムに関し、このデータセンタ管理システムは、データセンタ内の複数の場所での初期電力測定に関連するデータを受信し、初期電力測定に関するデータに基づいてデータセンタの効率モデルを確立し、効率モデルを用いてベンチマーク性能レベルを確立し、継続電力測定に関するデータを受信し、継続電力測定の結果をベンチマーク性能レベルと比較するようにプログラムされた少なくとも１つのプロセッサを有するデータセンタマネージャを含む。

このシステムにおいて、継続電力測定を行なうことは、電力測定装置と少なくとも１つのネットワークで通信することを含む。１つの実施例において、少なくとも１つのプロセッサは、継続電力測定の結果がベンチマーク性能レベルと指定量よりも大きく異なる場合、警告を発するようにプログラムされている。効率モデルを確立することは、効率モデルを確立するためにデータセンタの所在地に関連した気候に関するデータを用いることを含んでもよい。

この開示のもう１つの局面は、データセンタの電力効率のモデル化方法に関し、この方法は、データセンタへの電力入力を測定するステップと、データセンタにある電力負荷を測定するステップと、データセンタにある冷却負荷を測定するステップとを含む。

この方法において、１つの実施例において、電力負荷を測定するステップは、ＵＰＳおよびＰＤＵの負荷を測定するステップを含む。別の実施例において、データセンタにある冷却負荷を測定するステップは、ＣＲＡＨ、ＣＲＡＣ、ファン、チラーユニット、換気ユニット、冷却塔、およびポンプのうち少なくとも１つによって発生される負荷を測定するステップを含む。この方法は、データセンタの環境条件を測定するステップを含んでもよい。

さらに別の局面は、データセンタの電力効率のモデル化方法に関し、この方法は、データセンタで用いられる電力を引き込む装置を特定するステップと、各装置について、その装置の電力入力の定格容量および利用可能容量のうち１つを選択するステップと、各装置について、その装置が固定損失、比例損失、もしくは二乗法則損失、またはそれらの組合せとして寄与するのかどうかを決定するステップを含む。

この方法の実施例は、さらに、データセンタ損失を得るために装置の電力損失を集約するステップおよび／またはサブシステムの電力損失を集約するステップを含んでもよい。装置は、電力関連装置および冷却関連装置として特徴付けられてもよい。この方法は、さらに、装置から以外の損失の原因を特定するステップと、統計データから損失量を予測するステップとを含んでもよい。特定の実施例において、この方法は、さらに、データセンタ構成の大多数を含むデータセンタ一覧（catalog）を提供するステップを含み、このデータセンタ一覧は、例示的な電力構成の電力一覧と例示的な冷却構成の冷却一覧とを有し、この方法は、さらに、データセンタ構成を作成するために電力一覧と冷却一覧とを組合せるステップを含む。この方法は、さらに、モデル中の循環依存のための計算を簡易化するステップを含む。

別の局面は、データセンタの電力効率をモデル化するためのデータセンタ管理システムに関し、このシステムは、少なくとも１つのプロセッサを有するデータセンタマネージャを含み、このプロセッサは、データセンタで用いられる、電力を引き込む装置を特定し、各装置について、その装置の電力入力の定格容量および使用可能容量のうち１つを選択し、各装置について、その装置が固定損失、比例損失、もしくは二乗法則則損失、またはそれらの組合せとして寄与するのかどうかを決定するようにプログラムされている。

このシステムにおいて、少なくとも１つのプロセッサは、サブシステム損失を得るために、装置の電力損失を集約するおよび／またはデータセンタ損失を得ためにサブシステムの電力損失を集約するようにプログラムされている。

この開示のもう１つの局面は、命令を含む命令シーケンスを記憶したコンピュータで読取り可能な媒体に関し、この命令は、プロセッサに、データセンターで用いられる、電力を引き込む装置を特定させ、各装置について、その装置の電力入力の定格容量および使用可能容量のうち１つを選択させ、各装置について、その装置が固定損失、比例損失、もしくは二乗法則則損失、またはそれらの組合せとして寄与するのかどうかを決定させる。

図面の簡単な説明
添付の図面は、一定の縮尺に従って描くことを意図していない。図中、さまざまな図面に示される各同一またはほぼ同一の構成要素は、類似の数字によって表わされている。はっきりさせるために、すべての構成要素がすべての図中で標識付けされているとは限らない。

典型的なデータセンタにおける電力フローを示す図である。 データセンタ効率をＩＴ負荷の関数として示すグラフである。 データセンタ効率をＩＴ負荷の関数として示し、モジュール設計と非モジュール設計とを比較するグラフである。 データセンタ効率を屋外温度の関数として示すグラフである。 データセンタ効率を曜日の関数として示す図である。 データセンタ効率を２つの異なるデータセンタについてのＩＴ負荷を特定して示すグラフである。 負荷および損失のエネルギフローを示すデータセンタ効率モデルの図である。 データセンタ電気効率アセスメント例の図である。 ＩＴ負荷を供給しているデータセンタの電力配分システム例の図である。 例示的なデータセンタ設計の枠組みの図である。 既知のデータセンタの電力一覧エントリの図である。 既知のデータセンタの冷却一覧エントリの図である。 一覧エントリ「電力１Ａ」を備えたデータセンタについての電力システム単線エネルギフローの図である。 一覧エントリ「冷却２Ｂ」を備えたデータセンタについての冷却システム単線エネルギフローの図である。 一覧エントリ「電力１Ａ、冷却２Ｂ」を備えたデータセンタについてのモデル評価フロー見本の図である。 図１３に示された図の一部を循環エネルギフローを強調して示す図である。 図１５Ｂとは異なる種類の装置についてエネルギフローとモデル評価との関係を示す図である。 図１５Ａとは異なる種類の装置についてエネルギフローとモデル評価との関係を示す図である。 この発明のさまざまな実施例がその上で実施されてもよい汎用コンピュータシステムを示す図である。 汎用コンピュータシステムの記憶装置を示す図である。 汎用コンピュータシステムのネットワークを描く図である。

詳細な説明
この開示の実施例は、以下の説明に記載されるまたは図面に示される構成要素の構築および配置の詳細に限定されない。この開示の実施例は、さまざまに実施または実行されることができる。また、この明細書中に用いられる語法や用語は、説明のためのものであり、限定するものであると考えられるべきでない。この明細書中における「含む」、「備える」、または「有する」、「含有する」、「伴う」、およびそれらの変化形の使用は、その後に挙げられた項目およびその均等物ならびに追加の項目を包含することを意図されている。

１ＭＷの可用性の高いデータセンタは、その耐用期間にわたって２０，０００，０００ドル相当の電気を消費し得る。顧客によっては、電気費用のほうがＩＴハードウェア費用よりも高いことが示唆されている。加えて、多くの企業は、その現行の業務の炭素消費について考慮し始めている。効率は、類似のデータセンタ間で大幅に異なり、ほとんどの設備の実際の効率は、実用的に達成可能なクラス最高値をかなり下回る。

ほとんどのデータセンタは、データセンタの電気効率を考慮することなく設計および構築されている。特定の施設の性能に関するデータなしに電気的非効率の問題を制御することは困難である。加えて、たとえデータが利用可能であったとしても、そのデータを評価する技術がない。データセンタ設計者および管理者は、特定の施設の性能を他の類似の施設の性能との比較またはベンチマークする仕方を知らない。そのような設計者および管理者は、彼らの設備に対して彼らが期待すべきであった設計された通りの値と実際のデータとを彼らが比較することを可能にする情報を入手することができない。

加えて、顧客は、効率データを持っておらず、たとえ持っていたとしても、そのような顧客はその扱い方を知らない。この問題を解決するために、この開示の実施例は、以下を達成する：データセンタ効率を記述するための標準言語の開発、データセンタ効率を測定するための標準方法の開発、データセンタ効率を指定するための標準方法の開発、データセンタ効率を分析し、非効率への寄与因子を決定するための標準方法の開発、効率に関するベンチマーキングデータ、および提案された改善点または代替設計をアセスメントする効率モデル化ツールの開発。

データセンタインフラ効率（Data Center Infrastructure Efficiency：ＤＣｉＥ）、電力利用効率（Power Utilization Effectiveness：ＰＵＥ）およびサイト電力オーバーヘッド乗数（Site-Power Overhead Multiplier：Ｓｉｔｅ−ＰＯＭ）を含めて、データセンタ効率のために数多くの異なる関連する測定基準が提案および検討されている。データセンタインフラ効率（ＤＣｉＥ）は、データセンタの効率を決定するための評価基準としてこの明細書中において主に用いられる。データセンタの電気効率は、データセンタに供給された全電力のうち最終的に情報技術（Information Technology）装置に供給される部分として表わされる。効率の値は、この場合０から１の間になり、以下の方程式によって表わされてもよい。

全体電力消費は、データセンタの電力効率およびＩＴ負荷の大きさによって、

に従って制御されてもよい。
あるＩＴ負荷が与えられると、電力消費を最小化するという目標を達成するために、データセンタインフラ効率を最大化しなくてはならない。

もしもデータセンタが効率１００％であったならば、データセンタに供給される電力のすべては、ＩＴ負荷に達するであろう。これは理想の場合である。実際のデータセンタにおいては、ＩＴ負荷以外の装置による電気エネルギの消費のしかたが多数あることがあり、この装置には、変圧器、ＵＰＳ、電力配線、ファン、空調装置、ポンプ、加湿器、および照明が含まれるがこれに限定されない。これらの装置の中には、ＵＰＳおよび変圧器のようにＩＴ負荷と直列のものもあり、照明およびファンのように、ＩＴ負荷と並列なものもある。いずれにしても、データセンタに給電している事実上すべての電力は、最終的に廃熱になる。例示的なデータセンタにおいて、どこを電力および熱パワーが流れるかを示す図を、図１に示す。

図１にモデル化されたデータセンタは、典型的な高可用性二重電力経路データセンタであり、Ｎ＋１個のＣＲＡＣユニットを備え、設計容量の３０％の典型的な値で動作している。なお、この例において、ＩＴ負荷に実際に供給されるのは、データセンタに給電している電力の半分よりもはるかに少ない。この例におけるデータセンタは、効率３０％であると考えてもよい。

データセンタにある電力機器および冷却機器は、各装置について電気効率に関するデータを提供する製造業者によって、これら機器の損失により特徴付けられる。電力機器の場合、効率は、典型的に百分率で表わされる。冷却機器の場合、効率は、性能係数として表わしてもよく、この性能係数は、空調装置によって取除かれた熱パワーと入力電力との比である。照明電力は、単純一定損失として表わされてもよい。たとえば、６０ワットの電球は、６０ワットの熱を発生させ、ＩＴ負荷に電力を供給しないため、０％効率である。

データセンタ効率性能は、典型的に、単一の数字で表わすことはできない。任意の所与の瞬間に、データセンタは、その電力効率測定に対する単一の数値を有する。この数値は、電力、冷却および照明システムの固有の電力消費特性ならびにその時点でのＩＴ負荷の値の結果である。しかしながら、データセンタにおいて、効率は時間とともに変動するものである。なぜならば、ＩＴ負荷は、時間とともに変動し、屋外条件は時間とともに変動し、データセンタの冷却モードは、時間とともに変化し得るためである。これらの要素のすべては、データセンタ効率に影響を与え、その結果、データセンタ効率は常に変化している。データセンタ効率の特定の１回限りの測定は、「スナップショット」に過ぎず、将来の性能を予測するために用いることはできない。データセンタ効率の単一の測定値は、本質的に不正確であり、ベンチマーキングまたは効率管理の基準として用いることは困難または不可能である。

データセンタ効率の変動は、ＩＴ負荷、屋外条件、および冷却運転モードの関数としての効率のグラフによってよりよく理解、説明されることがある。図２には、典型的なデータセンタの効率がＩＴ負荷とともにどのように変動するかが示されている。データセンタにある電力機器および冷却機器の固定設備は、図２に示される形態の効率曲線を有し、効率は軽負荷で低下し、ＩＴ負荷がゼロのときゼロである。図２に特定されるこの曲線は、データセンタ効率の改善を理解するための基本原理を説明している。具体的には、示されるように、データセンタ効率を改善する２つの基本的な方法がある。１つの方法は、データセンタ効率曲線を上昇させることである。別の方法は、動作点を効率曲線のより効率的な部分に移動させることである。

図２において、ＩＴ負荷を上昇させると、動作点が好ましい方向に移動される。また、電力および冷却容量を（規模適正化または拡張可能なアーキテクチャを通じて）削減しても、同じ効果がある。施設の規模を適正化することの利点は、図３に示されており、この図は、電力および冷却容量が負荷が増加するにつれて増分として加えられているデータセンタの曲線効率である。両方の場合において、電力機器の効率と冷却機器の効率とは、同一である。図３において、典型的なデータセンタ効率曲線は、５つの同一のモジュールから作られたデータセンタの効率曲線と比較されており、このデータセンタでは、モジュールがその容量が必要なときにのみ追加され、オンにされる。

図３には、全負荷で、モジュールシステムは効率利点を有さないことが示されている。しかしながら、軽負荷で、インストールされたモジュールは、その定格負荷のより高い割合で動作し、効率に著しい利益がある。この曲線から、我々は、なぜモジュール式のスケーリング可能な電力および冷却インフラは、その動作寿命のかなりの部分の負荷がその極限設計値を下回る（かなり下回ることもある）データセンタの効率を改善する最も効果的な方法の１つであるのかを理解することができる。

データセンタの屋外条件は、時間とともに変動し、データセンタ効率に影響を与えるさらなる要素である。図４には、典型的なデータセンタの効率が屋外気温とともにどのように変動するかが示されている。（なお、ｘ軸の選択として適切であるのは、周囲温度ではなく、いわゆる「湿球温度」または「露点温度」であってもよく、用いられる排熱システムの種類による。）典型的なデータセンタの効率は、温度が上昇するにつれて低下する。なぜなら、排熱システムがデータセンタの熱を処理する際に消費する電力が増加するためである。加えて、効率は、屋外の熱がデータセンタ内に侵入し、処理しなければならない追加の熱負荷となる結果、低下する。図４の点状の曲線は、冷却システムが「節約」運転モードを有した場合、低温でどのように効率が改善する可能性があるかを表わしている。明らかに、特にデータセンタに節約冷却モードが装備されている場合、効率は屋外温度とともに変動する。

実際のデータセンタにおいて、効率は、ＩＴ負荷および温度が変化するとき変化する。図５には、データセンタの効率が、以下の異なる３つの要素の影響で１週間の間にどのように変動する可能性があるかが示されている：ＩＴ負荷および屋外温度の１日の間の振幅によって起こる１日の間の変動、天候によって起こる日ごとの変動、および週末におけるＩＴ負荷の低下。

日ごとの変動は急激ではないものの、そのような変動は、特定の、１回限りの測定の有用性を深刻に低下させることがある。予期される日ごとの効率の変動のために、たとえ特定の効率測定を極めて精密に行ったとしても、その電力消費の予測、効率改善活動の影響の測定、および傾向分析の実行における精度は悪いことがある。

データセンタ効率の負荷に伴う変動は、別の重要な影響を、効率データをどのように解釈するべきかに与える。図６に比較される２つのデータセンタの例を考える。第１のデータセンタでは、４７％の効率測定が得られる。第２のデータセンタでは、５０％の効率測定が得られる。第２のデータセンタの効率測定のほうが良いので、第２のデータセンタが根本的により優れた設計の「環境によりやさしい（greener）」データセンタであるとするのが妥当なように思われる。しかしながら、この２つのデータセンタをより詳しく考える。具体的には、図６には、第１のデータセンタは、測定された効率が低いにもかかわらず、効率曲線が大幅に高いことが示されている。仕様の見地から、第１のデータセンタは、おそらく大幅に効率の高い電力および冷却機器ならびに最適化された空気流設計を用いている。しかしながら、ＩＴ負荷の第１のデータセンタにおける割合が第２のものよりも低いため、第１のデータセンタは、効率曲線の非効率な部分で動作している。

よって、一見したところでは、図６においてどちらの設計が優れているのかを決定することは難しい。技術者は、第１のデータセンタの固有設計効率のほうが優れていると決定するかもしれない。しかしながら、実業家は、このデータセンタの規模決定が悪かったことにより、すべての技術的な効率利点が消されてしまったと決定するかもしれない。どちらの「設計」がより良いかについての決定は、適切な規模決定が設計の一部と考えられるかどうかによる。（なお、第１のデータセンタの優れた技術性能は、この場合、図３において前に説明されたように、モジュール式のスケーリング可能な実現化例が用いられていたならば実現されたかもしれない。）
特定の実施例において、データセンタの単一の測定によって得られた効率評定など、単一の数値を用いてデータセンタの効率を表わす、という概念は、上記に概説された目標を達成しないため、根本的に効果がないことがある。そのような表現は、ベンチマーキングのために有効ではないことがあり、傾向を示すためおよび効率改善の機会についてのそれに基づいて行動することができる洞察を与えるためにも有効ではない。

少なくとも１つの実施例は、測定値を用いて、目標のうち少なくともいくつかを達成する。以下により詳細に説明されるように、特定のデータセンタの働きを正確に表わし、かつ入力としてＩＴ負荷、屋外天候統計値、時刻電力料金などを受けるモデルを、データセンタエネルギ管理プログラムにおいて効果的に用いてもよい。測定時の条件に対するデータのみを提供する、実際に動作しているデータセンタの測定とは異なり、モデルは、モデルに入力された任意の入力条件に対してデータを提供することができる。たとえば、モデルは、ＩＴ負荷が定格負荷の一部でしかないときでさえも、全負荷でのデータセンタの効率の期待値を提供し得る。２つの異なるデータセンタのモデルに同じ入力条件を入力することで、意味のある比較が可能になる。さらにそのうえ、データセンタを構築する前でさえモデルを作成することができるので、データセンタの性能を事前に予測することが可能になる。

以下は、データセンタ効率を測定、記録することによっては得ることができない、モデルが提供する利点のうちいくつかである：データセンタの設計案の効率性能を事前に正確に予測する能力、動作中のデータセンタの効率性能を異なるＩＴ負荷についてなど測定することが非実用的な条件について高い精度で見積る能力、全回路の電力消費を測定することが実用的でない部分的な情報しかない状況についてデータセンタの効率性能を高い精度で見積る能力、さまざまな屋外条件についてデータセンタの効率を高い精度で見積り、経時効率平均の見積りを可能にする能力、データセンタ電力、冷却および照明システムの中の特定の装置がデータセンタの非効率に与えている寄与を特定し、定量化する能力、予期された効率パラメータの範囲外で動作しているデータセンタサブシステムを特定する能力、および異なるデータセンタのモデルをベンチマークし、比較する能力。

ある動作点におけるデータセンタ効率の単一の測定は情報を与えてくれるが、上記に列挙された能力なしにはそれに基づいて行動できないことがある。このため、モデルを採用して、効率管理のためのプロセスおよびシステムを作成することがある。非効率の原因について理解することを可能にするのはモデルである。したがって、データセンタ効率測定の目的は、モデルのパラメータを確立することである。

よって、データセンタ効率の測定の目的は、そのデータセンタの正確なモデルの作成に寄与する情報を得ることであってもよい。それに基づいて行動することができるデータセンタ効率に関する情報を提供するのはモデルであり、測定ではない。

データセンタ効率のモデル化の利点は貴重であるものの、特定のデータセンタにのデータセンタ効率モデルを開発し、運用することが実現可能であり、実用的であるのかどうかという疑問が残る。この疑問に対する答えは、モデルに必要な精度の程度による。この開示の実施例を用いて、上記に概説された効率管理の目標を得るのに十分な精度のモデルを作成、運用することができ、そのようなモデルを、データセンタを管理するために用いられる標準的なソフトウェアツールに組込むことができる。

図７Ａには、実用的なデータセンタ効率モデルのエネルギフロー図が示されており、データセンタインフラ電力消費（損失）がＩＴ負荷および屋外条件によってどのように決定されて、電力、冷却および照明システム内のエネルギフローを上昇させているかが示されている。データセンタ内の各装置種類（ＵＰＳ、ＣＲＡＨなど）は、負荷を入力として受け、装置構成および固有の効率特性に従った電力消費（損失）を発生させる。

データセンタの効率モデルを、既存のデータセンタに対して作成することができ、または電力、冷却および照明装置の特性がわかっている場合、データセンタを構築する前でさえデータセンタの効率モデルを作成することができる。モデルが正確に設計を表わすならば、その提供するデータは、同様に正確であるだろう。照明、ＵＰＳおよび変圧器などのいくつかの種類の装置の電気的性能は、非常に一定で予測可能なものであるが、モデルの精度を失わせる、ポンプおよび空調装置などの装置の施工完了時の性能に関する多くの不確定要素がある。この場合、測定が役立つことができる。

これまで述べたことにより、再現性の悪さや提供される手引きの欠如のため、データセンタ効率の測定値を周期的にとることの有用性は限られていることが説明された。代わりに、効率管理は、２つの異なる目標を持った以下の２種類の測定を用いて実施例において行なわれてもよい：
初期測定…データセンタ効率モデルを較正し、現状の性能とあるべき性能とを確立し、潜在的な効率改善機会を特定する。初期測定は、典型的に、全体的な効率測定に加えて、個々の電力サブシステムおよび冷却サブシステムに関する測定を必要とする。
継続測定…モデルと比較して、予期せぬ非効率の警告を発し、改善点を定量化する。継続測定は、周期的なサンプリングまたは連続計測によって行なわれてもよい。
初期測定および継続測定に対する推奨事項を以下に説明する。

データセンタの効率が最初に測定されるとき、それは、専門家による全体効率アセスメントの一部であるべきである。効率測定を行なうことに加えて、データセンタ効率アセスメントは、典型的に、施工完了時の構成の分析と効率改善に関する推奨事項とを提供する。理想的には、アセスメントは、その成果物のうち１つとしてデータセンタのモデルを提供すべきである。図７Ｂには、データセンタ効率アセスメントのための作業明細例が示されている。効率アセスメント中に収集されるデータは、数学的効率モデルが較正されるのに十分なサブシステムの測定値を含むべきである。

一旦初期効率測定値を用いてデータセンタモデルを較正すれば、予想年間平均効率などのベンチマーク性能を確立するか、または業界比較ベンチマークのために確立されたものなどの他の基準ＩＴ負荷および屋外条件での効率を確立するために、このモデルを直ちに用いてもよい。

データセンタ効率を測定し、効率モデルを較正した後、継続測定を行なって、効率改善点を定量化し、望ましくない効率損失を通知するべきである。測定された効率の値が元の測定された値から変化することがわかったとき、これはＩＴ負荷または天候の変動によるものであり得ることを我々は既に示した。モデルは、ＩＴ負荷および天候の影響を補正し、見つかった効率変動がこれらの影響によるものであるのか、または根底をなすデータセンタインフラの実際の変更により引き起こされたのかを明らかにすることができる。

効率の継続測定は、年に２回（たとえば夏に１度、冬に１度のように６ヶ月間隔を空けて）など、周期的に行なうことができ、または連続リアルタイム測定システムを導入することができる。

特定の動作点でのデータセンタ効率を測定するために、データセンタへの合計入力電力および合計ＩＴ負荷が測定される。施設がデータセンタ専用のものである場合、入力電力は、建物への商用幹線接続（utility mains connection）で測定することができる。負荷が単一の巨大なＩＴ負荷装置であった場合、ＩＴ負荷電力は、装置の商用幹線接続での単一の電力測定である。この場合、２つの測定値しか必要でない。残念ながら、この理想的な状態はけっして達成されない。ほとんどのデータセンタは、データセンタに加えて他の負荷を備えた多目的建物の一部である。典型的なデータセンタは、多くは別々の電気回路を備えたおそらく数千のＩＴ装置の集まりから作られている。

正確またはほぼ正確な測定を確実にするために、電源から電力を引き込んで合計データセンタ負荷を構成するすべての装置を、他の非データセンタ負荷とは別途計測し、その入力電力を合計する。さらにそのうえ、合計ＩＴ負荷を得るために、すべてのＩＴ装置を別々に計測し、その入力電力を合計する。たとえば１ＭＷデータセンタにおいて、これは数千の同時電力測定を必要とし得、これは技術上および実用上の難題であろう。このため、データセンタオペレータの中には、効率測定は実用的でないと結論を出した者もいる。幸運なことに、複雑な計測および時間のかかる測定は、不要である。なぜならば、少数の統合された測定点の使用とシステムのモデルとの組合せは、十分な精度の効率測定を提供することを実証することができるためである。

実際の測定をモデルを用いてどのように劇的に簡易化することができるかの例として、ＩＴ負荷の測定の場合を考える。図８には、ＵＰＳから供給される電力配分装置（ＰＤＵ）から電力を提供されている多数のＩＴ負荷の典型的な状況が示されている。

実際のＩＴ負荷を得るためには、数千の測定であり得るがあらゆるＩＴ負荷を供給しているすべての分岐回路を測定し、合計するべきである。代わりに、ＵＰＳの出力での電力を測定する場合、問題は単一の測定へと劇的に簡易化される。しかしながら、ＩＴ負荷にＰＤＵによって消費される電力（ＰＤＵ損失）を加えた和を測定することにより誤差が引き起こされる。この誤差は、データセンタによって２％から２０％であり得、これは非常に著しい。しかしながら、ＰＤＵは、モデルにおいて非常に正確に特徴付けることができ、モデルは、ＵＰＳ出力電力が与えられると、ＰＤＵ損失を高い精度で演算することができる。モデルは、ＰＤＵ損失をＵＰＳ出力電力から引いて、著しい誤差のないＩＴ負荷を得ることができる。このようにして、モデルにより、我々が数千に及ぶ可能性のある測定を単一の測定に減らすことが可能になる。

モデルを用いて大量の情報を少数の測定から得る技術を１回限りの測定に対して用いることができ、この技術を連続的で永続的な効率監視システムの一部として用いることによって連続効率監視の費用を劇的に削減することもできる。

継続効率測定のための電力測定点の数は、典型的に、初期測定のために用いられる測定点よりも少ない。継続測定は、最も経時変化しやすく、かつ電力消費への最大の寄与因子である回路に焦点を当てる必要がある。たとえば、装置の中には、変圧器など、各変圧器を最初に測定することは価値があるが、その継続的な電力寄与はモデルによって高い精度で演算することができるものがある。一般的に、継続測定に必要な測定点は、初期測定の半分である。これにより、継続測定点は恒久的に設置された電力計器測定によって監視され、初期測定に必要な追加的な点は可搬式計測を用いて測定するという計測戦略が示唆される。

どの回路を初期測定し、どの回路を継続的に測定するべきかは、専門的なデータセンタ効率アセスメントの重要な要素であることがある。

データセンタ効率は、電力測定値に基づいて計算された数値であってもよい。電力測定値は、以下の種類の機器から得てもよい。（１）可搬式電力測定機器（たとえばワシントン州エバレットのフルーク社製３相電力品質分析キットFluke（登録商標）435）、（２）恒久的に設置された電力測定機器（たとえばテネシー州ラバーグのシュナイダー・エレクトリック社−電力管理事業部製Power Logic PM700電力メータ）、（３）冷却機器および電力機器に恒久的に設置された組み込み型電力測定機能（たとえばロードアイランド州ウェストキングストンのアメリカン・パワー・コンバージョン社製APC Symmetra（登録商標）UPS）。

データセンタは、効率について恒常的に計測されてもよく、または効率は、可搬式計測を用いて周期的に監査されてもよい。いずれの場合も、測定される電力回路は、前項で説明されたように最初に特定される。データセンタにある数千の回路のすべてにおける電力フローを測定する必要はない。電力回路の小さなサブセットにおける電力フローを測定することによって、効率を非常に正確に演算することができる。効率測定戦略は、以下の要素からなる：恒久的な測定か周期的／可搬式測定かの決定、適切な測定点の特定、効率データを報告するためのシステムの確立。

効率測定計測は恒久的に設置されてもよく、または測定は資格を有するサービス担当者が可搬式計器を用いて行なってもよい。好ましい解決法は、多数の要素に依存し、各アプローチの利点は、多数ある。異なるアプローチの比較例は、表１にまとめられている。

恒久的計測により、著しい利点を提供する連続リアルタイム効率データが提供される。周期的監査と比較したときの恒久的計測の１つの利点は、通電中の電力回路を可搬式機器で測定しようとする人がいないことである。人が通電中の回路で測定を行なおうとするときはいつでも、過失およびダウンタイムの危険性がある。恒久的な計測の不利点は、特に設備の改修について、最初の費用がより高いことである。したがって、特に耐用年数に近づいている既存のデータセンタについて、可搬式計測を用いた周期的監査は、より低費用である。

ＵＰＳなど電力装置および冷却装置の中には、既に電力測定性能が組込まれているものもある。この組込まれた性能の精度が十分な場合、影響を受ける回路上で追加の測定計測を用いる必要がなくなる。

計測が恒久的であっても可搬式であっても、適切な電力測定点が選択されなければならない。データセンタにある数千の回路すべてを測定する必要はない。目標は、必要な精度を備えたモデルを構築するのに必要なデータを提供する最も少ない回路を測定することである。既存のデータセンタについては、この問題は、建物がどのように配線されたかに関する実際問題によって複雑化されることがある。さらにそのうえ、冷却塔など回路または装置の中には、測定されるデータセンタ外の負荷と意図的に共有されていて、データセンタに関する消費を直接測定することを不可能にしているものもある。したがって、計測測量点選択は、特定の設備のためにカスタマイズすることが必要になることがある。

先に述べたように、電気効率は計測によって直接は測定されず、追加の計算が必要となることがある。さらにそのうえ、データセンタの効率曲線を提供するためには、測定値がデータセンタの効率モデルとともに用いられることが必要である。

周期的な監査については、データセンタの効率曲線は、この明細書中に説明される原理を用いて計算されてもよい。恒久的な計測については、効率のリアルタイム計算が可能で好まれてもよい。この機能は、電力および冷却容量管理システムによって提供されるべきであり、このシステムは、データセンタのモデルを既に含んでいる。適切に実現化されると、電気効率傾向を報告することができ、警告を範囲外条件に基づいて発することができる。さらにそのうえ、効果的なシステムは、非効率の原因を診断し、是正処置を示唆する能力を提供するであろう。

示されるように、測定は、モデルとともに用いられるとき最も有用である。このため、モデル化は、効率管理の決定的に重要な局面であり、モデルのデータ要求がデータセンタ内の電力フローの測定に対する要件を確立する。

データセンタ効率を管理するために、初期電力測を行って、モデルおよび基準条件を確立し、電力フローを周期的にか、継続的に連続してかのいずれかで監視して、効率傾向、非効率条件、改善の機会についての情報を提供する。

典型的なデータセンタ内には数千の電力フローがある。効率を測定および管理するためにこれらのフローのすべてを測定することは不要であることが分析により示されている。適切なモデル化と電力装置および冷却装置についての情報と組合せると、精度の高い効率管理システムを少数の測量のみで作成することが可能である。

効率を管理するためには、ユーザは、リアルタイム計器測定のためにデータセンタ内の適切な電力フローを恒久的に計測する選択肢を有し、またはユーザは、可搬式計器を用いて電力フローの周期的監査を行なうことができる。新規データセンタについては、恒久的計測が適切である。既存のデータセンタについては、限定的な恒久的計測と周期的監査とを混ぜることが推奨される。

特定の実施例において、データセンタのためのエネルギ管理システムのモデルが説明される。エネルギ管理の最も単純な概念は、エネルギ測定および傾向などのデータ分析に基づく。測定は、確かにエネルギ管理の重要な要素であるものの、エネルギ管理システムの有用な利点のほとんどは、モデルによって提供されなければならない。測定は、将来の条件かでの性能を予想するために用いることはできず、改善機会に関する手引きを提供することはできない。

データセンタインフラ効率（ＤＣｉＥ）をモデルを用いず直接測定によって測定することは可能であるかもしれないが、測定時のデータセンタの条件以外の任意の条件でのＤＣｉＥを決定することは不可能である。モデルは、測定値に文脈および意味を提供してもよく、データセンタおよびそのサブシステムの性能を他のデータセンタと比較することを可能にしてもよい。モデルを用いて、数秒で高い精度で年間ＤＣｉＥを予想してもよく、これは通常データ収集に１年かかるであろうタスクである。たとえば、実際の変化または仮定的な変化から生じる翌年のＤＣｉＥの変化を正確に予想することができる。これは、モデルなしには不可能であろう。モデルは、実際的制約により実際に測定することができないデータセンタ内の箇所での電力フローを高い精度で見積もることさえしてもよい。一般的に、システムの機能性および価値のほとんどは、モデルによるものである。

１つの実施例において、モデルはデータセンタのエネルギ消費のコンピュータシミュレーションである。モデルは、エネルギフロー従属関係および相互接続のすべてと、さまざまな電力装置および冷却装置のモデルとを含む。モデルを用いるシミュレーションは、屋外温度、ＩＴ負荷およびオペレータ設定などの入力を受け、データセンタにある全回路における全エネルギフローを決定することができる。

モデルは、エネルギフローを扱うように構成されており、このエネルギフローは、ワイヤを流れる電力の形態であってもよく、または水配管を通って、または空気を通って流れる熱であってもよい。これらのエネルギフローのすべてが、モデルにおいて考慮されてもよい。エネルギは、データセンタにおける全プロセスにおいて一定に保たれてもよい。ＩＴ負荷のように、デバイスの中には電気エネルギを消費し、熱を発するものもある。変圧器やＵＰＳのように、装置の中には電気的エネルギを望ましくない副産物としての熱生成（損失）を伴って変換するものもある。空調装置にように、装置の中には、電気エネルギおよびポンプ熱を消費するものもある。（ＩＴ負荷を含めて）システム全体としてのデータセンタは、電気エネルギを消費し、屋外に排出される熱を生じる。

データセンタはほぼそれぞれ異なっており、異なる数の異なる装置を異なる構成で用いている。装置自体は、典型的に、一貫性がなく不完全な性能仕様を有する。したがって、データセンタはそれぞれ異なるモデルを有するように思われる。結果として、特定のデータセンタのモデルの作成は、相当の調査およびカスタムプログラミングを伴う非常に複雑な難題のように思われるであろう。しかしながら、系統化されたアプローチを用いて、任意のデータセンタのモデルを簡単に作成するための単純な枠組みを開発することができる。

１つの実施例において、モデルは、以下の３つのモデルレベルを階層的に含んでもよい。（１）データセンタレベル、（２）サブシステムレベル、（３）装置レベル。データセンタレベルで、単一のエンティティとしてのデータセンタ全体を作成してもよい。ＩＴ負荷容量およびＩＴ負荷の関数としての損失を示してもよい。また、負荷の関数としてのＤＣｉＥを表わしてもよい。サブシステムレベルで、ＵＰＳ、空調機（air handler）、チラーなど、データセンタシステム全体を構成している多数のサブシステムを、各サブシステムが特徴的な容量および特徴的な損失パラメータを示している状態で表わしてもよい。装置レベルで、空調機サブシステムを構成する別々の空調機装置のグループなど、各サブシステムを構成する種類の１つ以上の装置を表わしてもよい。

モデルは階層であるため、モデル化方法の１つの局面は、どのように装置がサブシステムへと集約されているか、およびどのようにサブシステムが最終データセンタモデルへと集約されているかである。この集約は、以下により詳細に説明される。

モデル、その方法およびその規則を説明するために、モデルを以下の要素に分解してもよい：装置特性のモデル、装置を標準化されたサブシステムへと集約する方法、サブシステムをデータセンタ全体へと集約する方法。これらの要素の各々を順に考え、次に一体化されたモデルを説明する。

エネルギを処理する、データセンタにあるどの装置も、モデルで表わしてもよい。この明細書中で説明されるモデルのある実施例については、各装置をモデルで表わしてもよく、これにより完全なシミュレーションに必要な演算が簡易化され、モデル中の循環依存のための計算を回避するまたは劇的に簡易化することができる。基礎装置モデルは、データセンタ内のＵＰＳ、ＰＤＵ、空調装置などのエネルギを使用する構成要素のエネルギ使用のモデルを含んでもよい。各装置は、ワットで表わされる「負荷」と呼ばれる一次入力を有すると考えてもよく、５つのモデルパラメータを有すると考えてもよい：構成要素容量は、２つのパラメータを用いてモデル化してもよい：公称負荷定格容量、およびシステムの設計制約に基づいた使用可能な定格容量。構成要素の電力消費は、３つの損失パラメータを用いてモデル化してもよい：固定損失、負荷に比例する損失、および負荷の二乗に比例する損失。これらのパラメータを、公称定格容量に対する百分率で表わしてもよい。装置モデルはワットでの負荷を入力として規定され、エネルギ消費速度を出力として生成する。

多くの装置について、使用可能容量は、公称容量と等しくないであろう。これは、装置の動作条件、設計構築手法（engineering practice）、またはユーザ方針によることがある。たとえば、使用可能容量は、装置が高高度でまたは高い屋外温度で動作しているために公称容量よりも少ないことがある。ほとんどの場合、使用可能容量は、公称容量よりも少ないものである。さらにそのうえ、装置の使用可能容量は、特定のデータセンタの設計および方針に影響を受け、その一方で装置の公称容量は、固定されており、設備とは独立している。したがって、装置の使用可能容量を特定のデータセンタについて計算しなくてはならず、他の４つの装置モデルパラメータは、装置製造業者が提供することができる。使用可能容量に影響を与えることがある要素のまとめは表２に示されている。

先に述べたように、装置の公称容量と使用可能容量との間には相当の差があり得る。たとえば、冷却塔は特定の屋外条件およびフロー条件下では１ＭＷの公称定格を有するかもしれないが、予期される最悪の場合の高温条件のため定格をたった６００ＫＷに下げる必要があるかもしれず、データセンタのポンプおよび配管の特定の技術的設計の限界により５００ＫＷにさらに定格を下げることを伴うかもしれない。定格は、さらに、８０％負荷定格方針の対象になることがあり、その結果、この１ＭＷ冷却塔の最終的な使用可能定格負荷は、たった４００ＫＷである。

装置の中には、データセンタに冗長配置で構成されているものもあってもよい。この構成は、使用可能なデータセンタ容量を制限することがあるが、システム設計の特徴であり装置の特徴ではない。このモデルにおいて、冗長性のデータセンタ容量への影響をモデル階層の装置レベルではなくサブシステムレベルで捉えてもよい。したがって、装置の冗長構成による容量の損失は、装置の使用可能容量の計算において考慮されないことがある。冗長性の使用可能容量への影響は、以下で装置の集約について述べる間に述べられ。

モデルの１つの実施例において、装置の電力消費は、公称容量に対する装置の負荷に基づいてもよく、所与のワット負荷に対して、損失は、使用可能容量の影響を受けなくてもよい。したがって、所与の負荷に対する装置、サブシステム、またはさらにデータセンタの効率を決定するために、使用可能な容量パラメータを必要とせずに公称定格容量が必要とされる。しかしながら、装置の使用可能容量は、サブシステムの使用可能な容量を直接決定し、その結果、データセンタの使用可能容量に影響を与える。使用可能な容量データは、容量分析を行なうときまたは効率をデータセンタ容量の関数として報告するときに必要となる。

装置の中には、オペレータ設定、地上モード変更、または屋外条件に伴って変動する損失因子を有するものもあってもよい。これらの場合、損失係数は、これらの条件に依存する式として表わされる。たとえば、チラー比例損失因子は、屋外温度に関連して変動することがあり、冷却塔ファンの固定損失は、自動化されたステージコントローラに基づいた段階的な増加を有することがある。これらの例外的な場合は、モデルの少数のパラメータにしか影響を与えない。しかしながら、完全なモデルは、これらの場合も組込むべきであり、以下には、これらの場合をモデル案で取扱う方法が説明される。

たとえば空調装置のように、装置の中には、多数の運転モードを有するものもあることがあり、各モードに関連付けられた効率は異なる。たとえば、空調システムの中には、屋外温度が低い期間のための「節約」モードを有するものがあり、システム効率は、著しく高められる。そのような装置は、この明細書中で説明された単純な３パラメータ損失モデル（固定損失、比例損失および二乗法則損失）に基づいた単一の効率曲線を用いてモデル化することはできない。マルチモード装置の効率モデルを確立するためには、異なる技術を用いてもよい。

異なる運転モード間で切換わる装置の性能を、「状態平均化法（state-space averaging）」と呼ばれる手法を用いて、長期にわたって予想することができる。この手法は、さまざまなモードに費やす時間の相対量を予想することによって、次にシステムの出力の加重平均を生成することによって達成されてもよい。この技術は、効率計算および損失計算に容易に適用される。

この明細書中に説明される効率モデルを多運転モードを有する装置とともに用いるためには、固定損失、比例損失、および二乗法則損失をまず各運転モードに対して決定しなければならない。次に、長期にわたる全体損失寄与は、各モードにおける損失をそのモードで費やされる時間の予期される割合で乗算することによって演算される。たとえば、２つのモードを備えたシステムの完全な記述は、３つの効率曲線を必要とするであろう：モード１における効率曲線、モード２における効率曲線、および各モードで費やされる時間の規定の仮定量を所与として、予想全体効率曲線。

その損失特性が他の変数に依存する装置をさらに予測してもよい。負荷の関数としての損失モデルは、負荷およびシステム設計が装置電力消費に影響を与える唯一の入力であると仮定している。システム設計は、損失係数および設置された装置容量に影響を及ぼすことがあり得、負荷は、３つの損失パラメータによって損失と関連付けられている（固定パラメータ、比例パラメータ、および二乗法則パラメータ）。この損失負荷計算は、ＵＰＳなどのいくつかの装置種類に対しては、現実的な仮定である。しかしながら、チラーなどの他の装置については、電力消費は、屋外温度などの他の動作条件によって影響を受けることがある。

データセンタについて、装置の電力消費に影響を与え得る、負荷以外の以下の重要な入力を特定してもよい：屋外温度、屋外湿度、オペレータ設定（冷水設定点、バルブ設定など）、および劣化条件（フィルタ詰まりなど）。これらの要素に、装置損失パラメータに影響を与えさせることによって、これらの要素をモデルに組込んでもよい。たとえば、チラーの比例損失は、屋外温度に伴って変動するかもしれず、またはポンプの固定損失は、水フィルタの詰まりに伴って変動するかもしれない。各場合において、損失係数を上記の一覧からの１つ以上の変数を含む式として表わしてもよい。

このアプローチは、統計入力を用いてデータセンタをパラメータモデル化することも可能にする。たとえば、屋外温度を、所与の立地について度数−日数の値域（bin）などの統計形式で提供してもよい。この統計的データをモデルに適用して、ある立地での長期性能を予め予測することができる。モデルの性能例として、既存のデータセンタでチラーに改善が提案されている場合を考える。チラー案のパラメータデータを提供することによって、モデルを用いて、季節的天候変化の影響を考慮に入れて来年の年間節減を予想することができる。実際、ある立地での天候の影響を含めて、データセンタの年間効率は、そのデータセンタを構築する前でさえ高い精度で予測することができる。

これらの他の変数によって影響を受ける装置については、この明細書中で説明された５パラメータモデルを、追加のパラメータを加えることによって拡張してもよい。なお、モデルに相当の影響を与える追加のパラメータを有する装置は、いくつかしかない。以下の表は、分かっている追加パラメータの一覧である。

装置のモデルを確立するパラメータに加えて、装置は、モデルにとって重要な他の属性を有することがある。パラメータと異なる属性は、データセンタ全体モデルにおいて装置を分類し組織化するために用いられる。以下は、装置がその数学的パラメータに加えて有する属性である。
装置種別…どの装置も、予め定義された種別一覧からある標準種別であると特定されてもよい。たとえば、装置種別は、加湿器、ポンプ、ＵＰＳ、遮断器パネル、ワイヤなどとして特定されてもよい。この識別は、標準モデルの開発を容易にし、かつ異なるデータセンタを下は装置レベルまで比較することを可能にするために用いられてもよい。
装置サブシステム帰属関係…どの装置も、予め定義された一覧からサブシステムに割当てられてもよい。これは、標準階層モデルおよびサブシステムベンチマークを容易にするためである。
装置負荷割当…どの装置の電力消費も、３つの種類−ＩＴ負荷電力、インフラ電力、または含まれないもの、のうち１つに割当てられてもよい。

これらの分類は、予め定義された規則に基づくべきであり、データセンタ効率を演算するときに用いられる。

データセンタ効率の計算は、装置負荷割当ての影響を受けやすいことがあり、多くの公に報告されたデータセンタ効率数値は、一貫した装置負荷割当てに基づいていないことがある。たとえば、効率計算のために、ネットワークオペレーションセンタの電力消費は、ＩＴ負荷として分類されることもあれば、インフラとして分類されることもあり、計算に含まれないこともある。これらの割当ては、演算された効率結果に相当の変動を生み出すであろう。したがって、装置負荷割当ては、業界ベンチマークを可能にするために均一であるべきである。

いくつかの種別の装置については、パラメータのすべてに意味があるわけではないが、標準５パラメータ装置モデルを依然として適用することができる。たとえば、照明の場合、照明とＩＴ負荷との間にはっきりとした関係はない。この装置種別を比例損失および二乗法則損失をゼロに設定することで他の電力装置または冷却装置のように扱うことによって、容量を無限大に設定することによって、ならびに照明負荷を合計システムＩＴ定格負荷で除算したものと等しい固定損失パラメータを演算することによって、依然としてこの装置種別に対応することができる。

特定の実施例においてデータセンタは、サブシステムから構成されることがあり、これらのサブシステムは、装置から構成されることがある。データセンタ全体の特性は、データセンタ内に含まれた装置の特性から生じる。したがって、データセンタ全体をモデル化するためには、データセンタを構成する装置の特性を集約しなくてはならない。先に述べたように、サブシステムのおよびデータセンタシステム全体のモデルを、以下の原理に従って、個々の構成要素のモデルの数学的統合によって作成することができる。具体的には、装置をサブシステムへと集約してもよく、サブシステムをデータセンタ全体へと集約してもよい。合計データセンタの損失は、サブシステムの損失の和であり、これは次に各サブシステムを構成する装置の損失の和である。装置およびその関連するサブシステムの損失を、各装置の実際の負荷をその定格負荷の一部としてまず特定することによって演算してもよい。次に、各負荷からもたらされる固定損失、比例損失および二乗法則損失を計算し、次に加え合わせる。固定損失は、負荷に伴って変動せず、比例損失は負荷に伴って変動し、二乗法則損失は、負荷の二乗に伴って変動する。

ＵＰＳなどの２つの同一の装置を、負荷が装置間にわたって等しく共有されるサブシステムに統合するとき、統合されたサブシステムのサブシステム損失パラメータ（固定、比例、および二乗法則）は、元の装置と同じである。ＵＰＳなどの２つの同一の装置を、負荷が装置間で等しく共有されないサブシステムに統合するとき、統合されたサブシステムのサブシステム損失パラメータのうち２つ、固定および比例損失パラメータは、依然として元の装置と同じである。統合されたサブシステムの第３の損失パラメータ、すなわち二乗法則損失パラメータは、装置間の負荷の変動に関連付けられた量だけ元の装置パラメータと異なるであろう。しかしながら、元の装置の二乗法則損失パラメータをほとんどすべての実際的場合において用いてもよく、誤差は非常に小さいことが示すことができる。この性質は、ＵＰＳまたは空調機などの多数の装置間の負荷のバランスについての詳細な情報なしに、モデルを統合することを可能にする。

特定のサブシステム上の負荷は、データセンターのエネルギフローモデルによって決定することができる。それは、ＩＴ負荷と同じでないことが多い。たとえば、空調機負荷は、典型的に、ＩＴ負荷に加えてＵＰＳ、加湿器、および照明などの他の熱を発生させる負荷からなる。

異なるサブシステム上の負荷を決定するエネルギフローモデルは、異なるデータセンタ設計間で異なることがある。たとえば、データセンタの中には、ＵＰＳが電力をＩＴ負荷に加えて空調機に電力を提供することがあるものもあり、ＵＰＳがＩＴ負荷のみに電力を供給することがあるデータセンタもある。別の例において、１つのデータセンタにおいて、開閉装置がその熱が空調装置負荷を生み出す屋内にあることがあり、別のデータセンタにおいては、開閉装置が屋外にあることがある。

先に述べたように、データセンタは、装置で構成され、サブシステムという中間概念を階層に導入することは不要であることがある。しかしながら、サブシステムを考慮する対処は、非常に有用であることがあり、モデル案に含まれることがある。特に、サブシステムを含めることにより２つの利点が提供されることがある。第１に、サブシステムを考慮することにより、装置が標準化されたグループに系統化され、これにより異なるデータセンタサブシステムについてデータセンタ間でベンチマークすることが可能になる。第２に、関連する種別の装置からのデータを集約する点が便利である。これは、数百の電力装置および冷却装置があるかもしれない大きなデータセンタにおいて、特に有用であることがある。

サブシステムの概念は、全データセンタにわたってサブシステムの名称および定義が標準化されている場合、最も有用であることがある。サブシステム種別の中には業界にわたって一般的に認識されるものもあるものの、境界は曖昧であり、いかなる規格によっても十分に定義されていない。共通定義または言語を得るためには、もし業界規格が登場すれば定義は将来再マッピングされる必要があるかもしれないことを理解したうえで、サブシステム定義を確立してもよい。例示的な定義を表４に示す。

定義の一覧は、たとえば「空調装置」と呼ばれるサブシステムがポンプ、冷却塔などのさまざまなサブシステムを定義することに代えて定義される場合、相当簡易化されてもよい。装置に対して別々のサブシステムを定義することには少なくとも２つの利点がある。第１の利点は、実際の設備からのデータは、さまざまな冷却装置種別について著しいかつ変動量の大きい非効率があるかもしれないことを示し、装置に対して別々のサブシステム種別を作成することによって、これによりこれらのサブシステムの業界ベンチマークが可能になり、そのためユーザが彼らの冷却システムが業界標準と比較してどのように性能を発揮しているのかをよりよく理解することができる点である。第２の利点は、多くのシステムにおいて、冷却塔およびポンプなど冷却装置の中には他の非データセンタ負荷と共有されているものもあり、それらを空調機から分離することにより、共有されたサブシステムをより効果的にモデル化することが可能になる点である。

モデルは、関連付けられた種別の装置を集約して、以下においてサブシステムと称される単一のオブジェクトにする。つまり、モデルは、システムが１つのＵＰＳサブシステムと、１つの発電機サブシステムと、１つのＣＲＡＣサブシステムなどから構成されると考える。しかしながら、実際のデータセンタにおいては、各サブシステムは、多数の装置から構成されることがある。たとえば、１ＭＷデータセンタには、３つの並列の５００ｋＷ ＵＰＳが設置されていることがあり、１５個の９０ｋＷ ＣＲＡＣユニットが設置されていることがある。エネルギ管理およびベンチマーキングのために、我々のエネルギ管理システムは、各サブシステムを単一のエンティティとして扱う。したがって、実際の装置を集約する方法が必要とされることがある。

特定の実施例において、多数の装置を集約してモデル中のサブシステムにすることを、以下の方法を用いて達成してもよい。（１）集約サブシステム公称定格は、ＫＷでの装置公称電力定格の和である。（２）集約サブシステム使用可能定格電力は、ＫＷでの装置使用可能定格電力の和をサブシステム内の装置冗長性に対して調整したものである。（３）サブシステムに対する集約無負荷、比例および二乗法則損失因子は、装置が同じ場合、個々の装置の対応する損失因子と同じである。

集約サブシステム定格電力を考えるとき、装置が二重経路システムに構成されている場合、サブシステム使用可能容量は、装置使用可能容量の半分しかない。装置がＮ＋１個の構成に構成されている場合、サブシステム使用可能容量は、装置使用可能容量の和のＮ／（Ｎ＋１）倍である。サブシステムがＮ＋１個のおよび二重経路両方の冗長性のために構成されている場合、サブシステム使用可能容量は、装置使用可能容量の和のＮ／（Ｎ＋１）倍の２分の１である。「リング」設計または「キャッチャ」設計などの他の特殊化された冗長性選択肢は、検査によって推定されるサブシステム使用可能容量を有することができる。集約された装置が同じでない場合、集約損失因子は、装置損失因子の加重平均を各装置が表わす合計使用可能容量の割合で重み付けしたものである。

加重平均を決定するために、各損失因子は、その因子を示している装置によって表わされる合計ＰＵの割合に従った平均計算において重み付けされる。ほとんどのデータセンタについては、サブシステム内で単一の種別の装置しか用いられていないので、加重平均は不要である。たとえば、実質的にすべての場合において、ＵＰＳの並列なグループは、同じ製品モデルである。加重平均法は、サブシステム内で装置が混ざっている場合にのみ必要とされる。

冗長性構成は、データセンタレベルでではなく、各サブシステムに対して別々に取扱われる。実際のデータセンタの、異なる装置種別への冗長性の適用は、非常に異なることがある。たとえば、データセンタは、２Ｎ個のＵＰＳと、Ｎ＋１個のポンプと、非冗長性冷却塔とを有することがある。多くの他の冗長性組合せが実際のデータセンタにおいて見られてもよい。各装置について別々に冗長性に取り組むことによって、モデルは、単純だが柔軟性の高いものであり得る。サブシステム内で冗長性に取り組むことによって、データセンタサブシステムの相互接続を考えるとき、冗長性は、変数として除去されてもよいことによって、サブシステムをデータセンタに組込むときの構成選択肢の数の削減を可能にする。モデルが各サブシステムで許容する冗長性の種別は、Ｎ、Ｎ＋１、Ｎ＋２、２Ｎ、および２Ｎ＋１である。なお、冗長性値は負荷を受けている装置種別に対してしか意味がなく、したがって照明または補助設備のようなサブシステムに対しては適用されないことが留意されるべきである。

ＵＰＳ以外の空調装置などの他の装置については、使用可能容量と公称容量との間により大きな食い違いがあることがある。これらの容量考慮事項は、５パラメータ装置モデルにおいて理解される。しかしながら、装置を組み合わせてデータセンタシステムにするとき、定格容量および定格負荷を記述することに注意が払われなくてはならない。データセンタ負荷定格容量を定義するとき、他の等価な用語、たとえば「データセンタ定格電力」「データセンタ定格負荷」または「データセンタｋＷ容量」を用いてもよい。１つの実施例で、この容量定格をデータセンタがサポートするよう設計され構築されるＩＴ負荷の最大値として定義してもよい。データセンタ負荷容量を定義するとき、いくつかの問題が扱われるべきである。たとえば、データセンタは、２ＭＷのＩＴ負荷電力容量を有するが、冷却容量は１ＭＷしかないことがある。異なる見方から、これを人々は２ＭＷデータセンタか１ＭＷデータセンタかのいずれかとして見るかもしれない。しかしながら、この実施例の目的のために、ＩＴ負荷のサブシステム限界がデータセンタ定格負荷を確立する。この例において、データセンタ定格は１ＭＷであるだろう。

別の例は、電気幹線接続から２ＭＷの電力を取っていることがあるデータセンタである。これを２ＭＷデータセンタと見る見方もあるかもしれない。しかしながら、データセンタ定格は、ＩＴ負荷容量の視点から定義されることがあり、２ＭＷの幹線電力を取っているデータセンタは、典型的に、１ＭＷ未満のＩＴ負荷しか提供していない。また、特定の時点での幹線負荷（mains draw）からは、データセンタの最終的な容量について何も明らかにならない。

さらに別の例は、１ＭＷの定格電力容量と、１ＭＷよりもはるかに大きい冷却容量を有することがあるデータセンタである。しかしながら、システム設計または方針は、１５％の安全域を規定していることがある。したがってこのデータセンタは、１ＭＷの８５％または使用可能容量のうち８５０ｋＷのためにしか設計されていない。このデータセンタの負荷定格容量は、したがって８５０ｋＷである。

もう１つの例は、５ＭＷのために設計されたが機器がすべては設置されなかったデータセンタである。単一の１ＭＷ ＵＰＳしか設置されておらず、他の４つの１ＭＷ ＵＰＳの設置は、延期されていてもよい。この場合、目下施工完了時のデータセンタは、定格容量が１ＭＷしかなく、したがって、効率分析のための定格負荷は、１ＭＷである。このデータセンタは、簡単に５ＭＷにアップグレードすることができるが、５ＭＷデータセンタではない。

データセンタモデルにおいて用いられてよい概念は、電力および負荷を定格ＩＴ負荷に対する百分率として表わすものであってもよい。このようにして、モデルを「規格化」してもよく、さまざまな演算は、簡易化され、ＫＷ容量から独立したものにされる。データセンタの定格ＩＴ負荷は、１００％または「単位あたり１」と定義され、単位あたり定格で負荷および容量を表わしてもよい。たとえば、２ＭＷ公称定格ＵＰＳが設置されている１ＭＷ定格負荷データセンタは、定格単位あたり２．０ＵＰＳであると言われるであろう。

各サブシステムの電力定格を集約することは、ＩＴ負荷と同じであるように思われるかもしれない。つまり、１ＭＷ定格データセンタは、１ＭＷのＵＰＳと、１ＭＷのＰＤＵと、１ＭＷのＣＲＡＣと、１ＭＷのチラーなどとを有するべきであるように思われる。しかしながら、ほとんどの用途において、これは事実ではない。実際には、サブシステム電力定格は、多くの場合、ＩＴ負荷よりもはるかに大きいことがわかることがある。これは、実例で最もよく説明することができる概念である。表５には、典型的なデータセンタサブシステムおよびそのＰＵ定格の一般的な範囲が示されている。

表５に示されるように、多くのサブシステムの公称規模決定はデータセンタのＩＴ負荷定格よりもはるかに大きいことがある。多くのデータセンタは、定格負荷の一部でしかない実際の負荷で動作しているため、実際のデータセンタ中のデータセンタサブシステムは、その公称定格のわずかな部分でしか動作していないことがある。たとえば、定格１ＭＷのデータセンタに２ＭＷのＰＤＵが設置されているが、３００ｋＷまたはその定格負荷の３０％でしか実行されていない場合、ＰＤＵサブシステムは、０．２×０．３またはその公称定格の６％でしか動作していない。装置はその公称電力を下回って運転されることがあるというこの一般的な発見は、固定損失が多くの実際のデータセンタにおけるデータセンタ損失への支配的な寄与因子になることがあることを意味する。

この明細書中において説明される集約方法は、サブシステム種別内の全装置が負荷を均等に共有するという条件下で、数学的に正確であると示されてもよい。装置種別の中には、ＵＰＳなど、この条件が典型的に満たされることがあるものもあるものの、装置種別の中には、ＰＤＵなど、同じデータセンタ内の異なるＰＤＵユニットを通って流れる電力は相当変動するため、この条件を満たさないものもある。したがって、集約モデルは、電力フローがサブシステム中の装置間でバランスが取れているときの結合装置の正確な表現でしかない。しかしながら、エネルギフローのバランスが取れていないときでさえもモデルは固定損失および比例損失に関連する損失に対して常に正確であることが示されてもよい。誤差のすべては、二乗法則損失項に含まれる。ほぼすべての実際のデータセンタシステムについて、集約された二乗法則項によって起こる誤差は、非常に小さい。誤差は、エネルギフローがサブシステム種別内の装置間でバランスが取れている場合、ゼロである。誤差は、二乗法則損失項が他の損失項と比較して小さい場合、非常に小さい。誤差は、負荷がＰＵシステム定格と比較して小さい場合非常に小さい。なぜならば、二乗法則損失は、負荷の二乗に伴って低下するためである。したがって、集約モデルは、装置を1つ残らず含むモデルと比較すると、非常に小さい誤差に寄与し、典型的には、ＤＣｉＥにおいて０．５％よりもはるかに少ない。したがって、この明細書中で開示されるエネルギ管理システムは、各サブシステムに対して集約モデルを採用してもよいが、集約によって起こる可能性のある誤差を定量化することを考慮しなくてはならない。

一旦標準化されたサブシステムのパラメータが確立されると、サブシステムを組合せて、データセンタ全体のモデルを得てもよい。データセンタ全体モデルを用いて、サブシステム動作条件を確立するために、どのような熱負荷または電気的負荷がさまざまなサブシステムに印加されるのかを決定してもよい。次に、モデルは、モデル化されるデータセンタに適合するようにサブシステムの電気エネルギ消費を結合してもよい。

実質的にすべてのデータセンタは、サブシステムがどのように相互接続されるかに関して、わずかな変形だけで、基本標準アーキテクチャに従ってもよい。たとえば、ＩＴ負荷は、ＰＤＵから電力を供給されてもよく、ＰＤＵは、ＵＰＳによって電力を供給されており、ＵＰＳは、開閉装置によって供給されている、などである。冗長性がどのようにおよびどこに存在するかなどのデータセンタ間の差異のほとんどは、サブシステムがどのように相互接続されているかではなく、サブシステムがどのように装置から構成されているかに関する。標準サブシステムの一覧を所与として、理想的な目標は、すべての代替的なデータセンタ構成の網羅的な一覧を作ることであるだろう。このようにして、あらゆる種類のデータセンタの別々のモデルを、予め構築し、試験してもよい。

１つの実施例において、別々のデータセンタ設計を記述するための枠組みが、図９の１００に一般的に示されている。示されるように、２つの主電力バス１０２、１０４および２つの主熱バス１０６、１０８が特定される。一次電力バス１０２は、開閉装置および分電盤電気供給であってもよく、電力バス１０４は、ＵＰＳ出力であってもよい。モデル中の標準サブシステムは、これらのバスのうち一方または他方から電力を供給される。屋内熱バス１０６は、屋内で排出されたすべての熱を含み、屋外熱バス１０８は、熱を屋外へ排出する場所を表わす。各装置は、熱バスのうち１つに行かなくてはならない熱を生み出す。データセンタシステムは、２つの主要なグループのサブシステムに分けてもよく、電力システム１１０と冷却システム１１２とである。示されるように、電力システム１１２は、電力をＩＴ負荷１１４に供給する。これから、２つの一覧−電力システム一覧および冷却システム一覧を作成してもよい。単一のデータセンタ一覧を有するのではなく、記述を電力システムと冷却システムに対して別々のエントリに分けることにより、一覧エントリの数はおよそ５分の１に削減されることがある。さらに、２つの一覧を提供することにより、電力組合せと冷却組合せとのさまざまな相互作用を取扱う複雑さが削減されるばかりでなく、将来のデータセンタ電力構成および冷却構成の追加が簡易化されてもよい。

データセンタの例示的な標準電力一覧は、図１０の１２０に一般的に示されている。一覧１２０には、データセンタ電力一覧には異なる一覧エントリは６つしかないことが示されている。表中の各列が一覧エントリである。標準電力サブシステムは、行に列挙されている。ある一覧エントリに対して、各電力サブシステムは、商用電力、一次電力、限界電力に接続されていてもよく、または存在しなくともよい。上記の一覧１２０は、既知のデータセンタを表わす。冗長性はサブシステムモデル内で取扱われ、モデルのこのレベルには表われない。

データセンタの例示的な標準冷却一覧を図１１の１３０に一般的に示す。一覧１３０には、データセンタ冷却一覧における２３個の異なる一覧エントリが示されている。電力一覧からの６つのエントリと組合せると、任意のデータセンタを説明するために２９個の一覧エントリを得る。これらの一覧は、新しいサブシステム種別またはトポロジが導入される場合、簡単に拡張可能である。

この一覧を用いてデータセンターを記述するためには、電力システムエントリおよび冷却システムエントリを指定するだけでよい。たとえば、「電力システム種別１Ａ、冷却システム種別２Ｂ」として記述される例示的なデータセンタを考えるとき、図１０および図１１からの表、図１２Ａおよび図１２Ｂに示されるこのデータセンタの単線エネルギフロー図を用いる。図１２Ａには、電力システム単線エネルギフローが説明されており、１４０に一般的に示されている示されている。図１２Ｂには、冷却システム単線エネルギフローが説明されており、１５０に一般的に示されている。図１２Ａの図の例におけるエネルギフローの値は、ＩＴ負荷要求および屋外条件から始まり、これらは、データセンタサブシステムを通るエネルギフローの複雑なプロセスを引起し、このプロセスは、最終的に商用幹線（utility mains）での電気需要および屋外への熱フローをもたらす。需要から始まり供給まで戻って進むこのエネルギのフローは、エネルギが幹線供給からデータセンタを通って流れるという一般的な概念と逆向きに最初は思われる。エネルギが商用幹線（mains utility）によって供給されることは事実であるが、使用されるエネルギの量は、電源によって決定されるのではなく、需要から確立される。データセンタの場合、需要はＩＴ負荷から始まり、この需要は電力装置および冷却装置での需要を引起し、この需要は次にそれら装置による電気需要を引起し、これらの電気需要は滝のように落ち、最終的に足し合わさって、データセンタによって用いられるエネルギの量を確立する。

図１２Ｂに示されるように、図には、屋内熱寄与因子ブロックが「侵入」として示されている。このブロックは、データセンタサブシステムではないが、データセンターの屋内と屋外との間の熱の漏れを表わし、全データセンターにおいて存在する。侵入は、屋内と屋外との間の温度差によって駆動される熱フローとしてモデル化されており、空調システムにかかる熱負荷を加えるまたは減じる。

データセンタの中には、均一または単一の設計を有さず、区域によって変動する基本設計を有するものもある。たとえば、データセンタを部屋単位冷却を受ける区域と列単位冷却を受ける別の区域とを有するように構成してもよい。別の例は、冷水とＤＸ冷却ユニットとの混成によってデータセンタが冷却されるようにデータセンタを構成することであってもよい。報告するために、これらの区域を分離して、たとえば異なる区域の効率性能を比較することが望ましいことがある。この場合、区域を、エネルギ管理システムの観点から別々のデータセンターのように扱い、次にデータを集約して合計値を得てもよい。エネルギ管理システムソフトウェアは、複合設計に対応するように設計されていてもよく、またはソフトウェアの別々のインスタンスを動作させ、次に集約機能を用いて、データを結合してもよい。

区域を分離することが実用的でないまたは実現可能でないデータセンタについては、たとえば、同じデータセンタ内で２種類の冷却アプリケーションが用いられる。技術の混じり合った状態を、データセンタに１つ以上の一覧設計を含み、一覧設計間で熱負荷を分割することによってモデル化してもよい。熱負荷を固定ワット値を特定の冷却システムに割当てることによって、負荷の特定割合の部分を各冷却システムに割当てることによって、または異なる冷却システムにおける実際の熱フローを測定することによって配分してもよい。一般的なチラープラントを用いた列内冷却と部屋単位冷却との混成など、標準一覧エントリを共有する冷却システムの組合せについては、単一の一覧モデルを用いてもよく、列単位冷却と部屋単位冷却との組合せは、サブシステムモデルにおいて行なわれる。

この明細書中で説明されるデータセンタについてのエネルギフロー単線図を、表示されるさまざまなサブシステムの瞬間的な電力フローおよび容量利用とともにユーザに提示してもよい。理論上、この情報のすべては、実際のデータセンタのためのエネルギ監視システムにおいて直接測定および表示され得る。この場合、計算は不要である。しかしながら、このアプローチは、構築されていないデータセンタの性能または測定時の実際のデータセンタの条件以外の動作条件で動作しているデータセンタの性能を調べるためには用いることができない。このためには、モデルが必要である。また、ほとんどのデータセンタにおいて、エネルギフローおよび装置電力負荷（device power draws）のすべてを実際に計測することは不可能であり、モデルを用いて、欠けているデータを正確に見積もることができる。したがって、モデルを用いて、エネルギフロー単線図中の電力フローおよび熱フローを計算する手段が必要である。

サブシステムモデルが装置モデルから集約されるとして、電力フローおよび熱フローを得るためには、接続および計算のシーケンスが必要となることがある。先に述べたように、計算は、ＩＴ負荷から入力として始まり、商用幹線電力負荷（utility mains power draw）および屋外熱排出で出力として終わってもよい。計算のフローは、図１３のモデル評価フロー図によって説明され、図１３には、上述のデータセンタ種別「電力１Ａ、冷却２Ｂ」についてのモデル評価フロー図例が示されている。

モデルを図を用いて評価するためには、フローは、左でＩＴ負荷および屋外温度から始まる。各サブシステムモデルを、その負荷入力が利用可能になるとき評価してもよい。装置の中には、直ちに評価することができるものもあり、発電機などの負荷入力のないサブシステム、および電力配分サブシステムなどの負荷が直ちに提供されるサブシステムである。ＵＰＳサブシステムは、その負荷入力に給電している全装置が評価されるまで評価することができない（限界バス）。冷却関連のサブシステムは、合計屋内熱バスがその入力を合計することによって評価されるまで評価することができない。冷却システムは、ＣＲＡＣユニットからはじまるサブシステムによって評価され、ＣＲＡＣユニットは、次に冷水ポンプに対する負荷入力を完了する。合計屋外熱および合計電気的電源需要を、すべてのサブシステムが評価されるときに演算する。

図１４に示されるモデルは、循環エネルギフローを備えるデータセンタの例である。示されるように、限界バスは、ＵＰＳの入力に行く。次に、ＵＰＳの出力熱は、屋内熱バスに行く。次に、屋内熱バスは、ＣＲＡＨに行く。最終的に、ＣＲＡＨ電気的負荷は、限界バスに行き、ループの初めに戻る。ＣＲＡＨが一次バス上にあったならば、このループは存在しないであろう。この例における循環エネルギフローは、図１４において強調されている。循環エネルギフローの別の例は、開閉装置損失が、建物の内部にあり、ＣＲＡＨによって処理される場合である。

モデル中の循環エネルギフローを、微分方程式を解くことまたは集束解法を用いることなどの数学的技術によって解決してもよい。ほとんどの例において、すべての現実的な状況について、これは無視できるほどの誤差を引起すことがわかった。よって、単位定格システム負荷あたりの装置負荷の見積りを提供することによって、循環エネルギフローをなくしてもよく、この見積りを用いて、装置損失を見積もってもよい。真値に代えて見積りを用いることによって、計算に循環式参照がなくなる。見積り値を用いて生み出された誤差は、二次誤差であり非常に小さいため、これによって計算が抜本的に簡易化される。また、要素である循環計算の種類はわずかしかないので、見積りが必要な装置はわずかしかない。

循環エネルギフローは、一覧から選択される電力システムおよび冷却システムの性質である。循環エネルギフローを有する各一覧モデルに対して、循環を断ち切る方法が定義され、変形例としてモデルに組込まれなくてはならない。この問題は、循環エネルギフローを有する各一覧データセンタモデルに対してはっきりと解決することができる。

エネルギフロー図とモデル評価フロー図とは、関連付けられてもよいが合致しない。エネルギフロー図は、データセンタにあるサブシステムの物理的な相互接続を最もよく表わす。評価フロー図は、データセンタモデルを評価するのに用いられる演算のフローを表わす。図を比較すると、エネルギフロー図は、モデル評価フロー図と、照明および空調装置のような多くのサブシステムについて合致することが説明される。しかしながら、電力を変換する装置については、エネルギフロー図と単線図とは、図１５Ａおよび図１５Ｂに示されるように一致しない。これらの図は、２つの異なる種類の装置１７０、１８０についてエネルギフロー図とモデル評価フロー図との関係を説明する。

図１５Ａに示される単純な装置モデルは、負荷を受け、装置１７０のための電気使用を演算する。このモデルは、空調装置、ポンプ、および照明のような単一の電力接続を有する装置に対して機能する。

図１５Ｂのモデルは、たとえばＵＰＳ、ＰＤＵ、配線および変圧器などの電力を処理する装置１８０のような装置のエネルギフローモデルを表わす。この図中のより小さい内側の囲い枠内の装置モデルは、負荷入力を受け、電気使用を演算する。しかしながら、この種類の装置のための電気使用は、物理的な電気的接続に表われない。これらの種類の装置への物理的入力電力接続は、電気使用と負荷との和である。たとえば、１ＭＷの負荷を備えた１ＭＷ変圧器の電力消費（損失）は、２％または２０ｋＷであってもよい。この場合における変圧器への物理的入力電力は、１．０２ＭＷであり、出力は１ＭＷであるだろう。２０ｋＷの損失を直接測定することができる接続は変圧器上にない。エネルギ使用を得るためには、物理的に測定された入力電力と出力電力との差を、測定しなくてはならない。

エネルギ管理システムにおいて、各サブシステム種別のエネルギ使用と熱出力とを測定してもよい。この明細書中に説明される種類の装置など、場合によっては、電力計器測定装置を回路上に設置して、その装置のためのエネルギ使用を得てもよい。しかしながら、電力を変換する装置については、装置エネルギ使用を得るために測定することができる回路がなく、それに代えて、２つの物理的測定値間の差を取って、装置エネルギ使用を得なければならない。このために、実際のデータセンタに設置された物理的計測は、予期されたデータとぴったりと対応しないことがあり、何らかの演算または物理的計測点のマッピングが必要とされる。

データセンタのエネルギ使用をモデル化するための系統的方法がこの明細書中に説明されていることが認められるべきである。モデルは個々の装置の性質から始まり、次にそれらを結合して、標準化されたサブシステムにし、次にさらにサブシステムを結合して、データセンタ全体にするプロセスを提供する。

この明細書中に開示される方法およびシステムを用いて、データセンタオペレータがエネルギ使用を削減するのを助けるために、なぜデータセンタが設計どおりに性能を発揮していないのかを特定し、データセンタの将来の性能を予想し、代替的な状況下での性能を予想してもよい。

この開示の実施例に従った上記に定義された方法を、１つ以上の汎用コンピュータシステム上で実現化してもよい。たとえば、この開示のさまざまな局面を、図１６に示されるものなどの汎用コンピュータシステム４００中で実行される専用ソフトウェアとして実現化してもよい。コンピュータシステム４００は、相互接続機構４０５に接続された１つ以上の出力装置４０１と、１つ以上の入力装置４０２と、相互接続機構４０５を通して１つ以上のメモリ素子４０４に接続されたプロセッサ４０３と、相互接続機構４０５に接続された１つ以上の記憶装置４０６とを含む。出力装置４０１は、典型的に、情報を外部表示のために表示し、例には表示部およびプリンタが含まれる。入力装置４０２は、典型的に、外部情報源からの情報を受け、例にはキーボードおよびマウスが含まれる。プロセッサ４０３は、典型的に、一連の命令を行なって、データ操作をもたらす。プロセッサ４０３は、典型的に、インテル社のPentium（登録商標）、モトローラ社のPowerPC（登録商標）、SGI社のMIPS（登録商標）、サン社のUltraSPARC（登録商標）またはヒューレットパッカード社のPA-RISC（登録商標）プロセッサなどの市販のプロセッサであるが、任意の種類のプロセッサであってもよい。ディスクドライブ、メモリまたはデータを記憶するための他の装置などのメモリ素子４０４は、典型的に、コンピュータシステム４００の動作中、プログラムおよびデータを記憶するために用いられる。コンピュータシステム４００中の装置は、少なくとも１つの相互接続機構４０５によって結合されていてもよく、この相互接続機構は、たとえばデータをシステム４００内で通信する１つ以上の通信要素（たとえばバス）を含んでもよい。

図１７により詳細に示される記憶装置４０６は、典型的にコンピュータで読込み可能かつ書込み可能な不揮発性記録媒体９１１を含み、この記録媒体の中に、信号が記憶され、この信号は、プロセッサによって実行されるプログラム、またはプログラムによって処理される媒体９１１上にまたは中に記憶される情報を定義する。媒体は、たとえばディスクまたはフラッシュメモリであってもよい。典型的には、動作中、プロセッサは、データが揮発性記録媒体９１１から別のメモリ９１２に読込まれるようにし、これは、プロセッサが媒体９１１が行なうよりも早く情報にアクセスすることをを可能にする。このメモリ９１２は、典型的に、動的ランダムアクセスメモリ（ＤＲＡＭ）、静的メモリ（ＳＲＡＭ）などの揮発性ランダムアクセスメモリである。メモリ９１２は、示されるように、記憶装置４０６中に位置していても、またはメモリ素子４０４中に位置していてもよい。プロセッサ４０３は、概して、メモリ４０４、９１２内のデータを操作し、次に、データを処理が完了した後に媒体９１１にコピーする。媒体９１１とメモリ４０４、９１２との間のデータ移動を管理するための種々の機構が知られており、この開示はそれに限定されない。この開示は、特定のメモリ素子４０４または記憶装置４０６に限定されない。

コンピュータシステム４００は、特別にプログラムされた専用ハードウェアを用いて実現化してもよく、または高レベルのコンピュータプログラミング言語を用いてプログラム可能な汎用コンピュータシステムであってもよい。たとえば、コンピュータシステム４００には、携帯電話および携帯情報端末が含まれてもよい。コンピュータシステム４００は、通常、オペレーティングシステムを実行し、このオペレーティングシステムは、たとえば、マイクロソフト社から入手可能なWindows（登録商標）95、Windows 98、Windows NT、Windows 2000、Windows ME、Windows XP、Windows Vista、もしくは他のオペレーティングシステム、アップルコンピュータ社から入手可能なMAC OS System X、サンマイクロシステムズ社から入手可能なSolaris Operating System、またはさまざまな供給源から入手可能なUNIX（登録商標）オペレーティングシステム（たとえばLinux）であってもよい。多くの他のオペレーティングシステムを用いてもよく、この開示はいかなる特定の実現化例にも限定されない。たとえば、この開示の実施例は、サン社のUltra SPARCプロセッサがSolarisオペレーティングシステムを実行している状態で汎用コンピュータシステムを用いて、データセンタリソースプロバイダにネットワーク装置にアクセスすることを制限するよう命令してもよい。

コンピュータシステム４００は、例として、この開示のさまざまな局面がその上で実施されてもよいコンピュータシステムの１種類として示されたが、この開示は、図１６に示されるコンピュータシステム上で実現化されるように限定されないことが理解されるべきである。この開示のさまざまな局面は、図１６に示されるものとは異なるアーキテクチャまたは構成要素を有する１つ以上のコンピュータ上で実施されてもよい。例示するために、この開示の１つの実施例は、MAC OS System Xをモトローラ社のPowerPCプロセッサで実行しているいくつかの汎用コンピュータシステムと、独自開発のハードウェアおよびオペレーティングシステムを実行しているいくつかの専用コンピュータシステムとを用いて、ネットワーク装置プロビジョニング要求を受けてもよい。

図１８に描かれえるように、システムの１つ以上の部分を、通信ネットワーク１０８に結合された１つ以上のコンピュータ（たとえばシステム１０９−１１１）に分配してもよい。通信ネットワーク１０８において用いられる物理的媒体には、たとえば物理的ケーブル配線および/または無線技術（たとえば無線周波数、赤外線など）など、この技術分野において知られている任意のものが含まれてもよい。そのうえ、各物理的媒体は、たとえばCAT 5ケーブル配線規格またはIEEE 802.11、Bluetooth（登録商標）およびZigbee（登録商標）無線規格などのようなさまざまな規格に準拠していてもよい。コンピュータシステム１０９−１１１は、汎用コンピュータシステムでもあってもよい。たとえば、この開示のさまざまな局面は、サービス（たとえばサーバ）を１つ以上のクライアントコンピュータに提供するように、または分配システムの一部として全体的なタスクを行なうように構成された１つ以上のコンピュータシステム間で分配されてもよい。より具体的には、この開示のさまざまな局面は、この開示のさまざまな実施例に従ったさまざまな機能を行なう１つ以上のサーバシステム間で分配される構成要素を含むクライアント−サーバシステム上で行なわれてもよい。これらの構成要素は、通信プロトコル（たとえばTCP/IP）を用いて通信ネットワーク（たとえばインターネット）で通信する実行可能な中間（たとえばIL）または解釈された（たとえばJava（登録商標））コードであってもよい。例示のために、１つの実施例は、ネットワーク装置プロビジョニング要求ステータス情報をＨＴＭＬ形式を解釈するブラウザを通して表示してもよく、別個のサーバ上で実行されているデータ翻訳サービスを用いてデータセンタリソースプロバイダ情報を取得してもよい。

この開示のさまざまな実施例は、Small Talk、Java、C++、Ada、またはC♯（C-Sharp）などのオブジェクト指向のプログラミング言語を用いてプログラムされてもよい。他のオブジェクト指向のプログラミング言語も用いてもよい。これに代えて、関数プログラミング言語、スクリプトプログラミング言語、および/または論理プログラミング言語を用いてもよい。この開示のさまざまな局面は、プログラムされていない環境において実現化してもよい（たとえば、ブラウザプログラムのウィンドウで見ると、グラフィカルユーザインターフェイス（GUI）の局面を表示するまたは他の機能を果たすHTML、XMLまたは他の形式で作成された文書）。この開示のさまざまな局面は、プログラムされたもしくはプログラムされていない要素として、またはそれらの任意の組合せとして実現化されてもよい。たとえば、プロビジョニング方針ユーザインターフェイスは、マイクロソフト社のWord文書を用いて実現化されてもよく、プロビジョニング要求を管理するように設計されたアプリケーションは、C++で書かれていてもよい。

この開示に従った汎用コンピュータシステムは、開示の範囲外の機能を行なってもよいことが理解されるべきである。たとえば、このシステムの局面は、既存の市販製品を用いて実現化されてもよく、たとえばワシントン州シアトルのマイクロソフト社から入手可能なSQL Serverなどのデータベース管理システム、カリフォルニア州レッドウッドショワのオラクル社製Oracle Database、スウェーデンのウプサラのMySQL社製MySQL（登録商標）、ニューヨーク州アーモンクのIBM社製WebSphere（登録商標）ミドルウェアなどである。この開示の実施例を実現化するためにSQL Serverが汎用コンピュータシステムにインストールされた場合、同一の汎用コンピュータシステムがいろいろなアプリケーションのためのデータベースをサポート可能であってもよい。

前述の開示に基づいて、この開示は、特定のコンピュータシステムプラットフォーム、プロセッサ、オペレーティングシステム、ネットワーク、または通信プロトコルに限定されないことが当業者には明らかであるべきである。この開示は、特定のアーキテクチャまたはプログラミング言語に限定されないことも明らかであるべきである。

このように説明した結果、この開示の少なくとも１つの例示的な実施例、さまざまな変形例、変更例、および改善例が、当業者には容易に思い浮かぶであろう。そのような変形例、変更例および改善例は、この開示の範囲および趣旨内であることが意図される。したがって、前述の説明は、単に例示的なものであり、限定するものであることを意図していない。この開示の境界は、以下の特許請求の範囲およびその等価物においてのみ定義される。

Claims (26)

1. データセンタの電力効率の管理方法であって、
   データセンタ内の複数の場所で初期電力測定を行なうステップと、
   前記初期電力測定に基づいてデータセンタの効率モデルを確立するステップと、
   前記効率モデルを用いてベンチマーク性能レベルを確立するステップと、
   継続電力測定を行なうステップと、
   前記継続電力測定の結果をベンチマーク性能レベルと比較するステップとを備える、方法。
2. 前記継続電力測定を行なうステップは、プロセッサベースのデータセンタ管理システムを測定機器とともに用いるステップを含む、請求項１に記載の方法。
3. 前記継続電力測定の前記結果が前記ベンチマーク性能レベルと指定量よりも大きく異なる場合、警告を発するステップをさらに備える、請求項２に記載の方法。
4. 前記効率モデルを確立するステップは、前記効率モデルを確立するためにデータセンタの所在地に関連した気候に関するデータを用いるステップを含む、請求項１に記載の方法。
5. 前記効率モジュールを確立するステップは、
   データセンタで用いられる、電力を引き込む装置を特定するステップと、
   各装置について、前記装置の電力入力の定格容量および使用可能容量のうち１つを選択するステップと、
   各装置について、前記装置が、固定損失、比例損失、あるいは二乗法則損失、またはそれらの組合せとして寄与するのかどうかを決定するステップとを含む、請求項１に記載の方法。
6. 前記効率モジュールを確立するステップは、サブシステム損失を得るために前記装置の電力損失を集約するステップをさらに含む、請求項５に記載の方法。
7. 前記効率モジュールを確立するステップは、データセンタ損失を得るために前記サブシステムの電力損失を集約するステップをさらに含む、請求項６に記載の方法。
8. データセンタの電力効率を管理するためのデータセンタ管理システムであって、
   少なくとも１つのプロセッサを有するデータセンタマネージャを備え、前記プロセッサは、
   データセンタ内の複数の場所での初期電力測定に関するデータを受信し、
   前記初期電力測定に関するデータに基づいてデータセンタの効率モデルを確立し、
   前記効率モデルを用いてベンチマーク性能レベルを確立し、
   継続電力測定に関するデータを受信し、
   前記継続電力測定の結果をベンチマーク性能レベルと比較するようにプログラムされている、データセンタ管理システム。
9. 前記継続電力測定を行なうことは、電力測定装置と少なくとも１つのネットワークで通信することを含む、請求項８に記載のデータセンタ管理システム。
10. 前記少なくとも１つのプロセッサは、前記継続電力測定の前記結果が前記ベンチマーク性能例と指定量よりも大きく異なる場合、警告を発するようにプログラムされている、請求項８に記載のデータセンタ管理システム。
11. 前記効率モデルを確立することは、前記効率モデルを確立するためにデータセンタの所在地に関連した気候に関するデータを用いることを含む、請求項８に記載のデータセンタ管理システム。
12. データセンタの電力効率のモデル化方法であって、
    データセンタへの電力入力を測定するステップと、
    データセンタにある電力負荷を測定するステップと、
    データセンタにある冷却負荷を測定するステップとを備える、方法。
13. 前記電力負荷を測定するステップは、ＵＰＳおよびＰＤＵの負荷を測定するステップを含む、請求項１２に記載の方法。
14. 前記データセンタにある冷却負荷を測定するステップは、ＣＲＡＨ、ＣＲＡＣ、ファン、チラーユニット、換気ユニット、冷却塔、およびポンプのうち少なくとも１つによって発生される負荷を測定するステップを含む、請求項１２に記載の方法。
15. データセンタの環境条件を測定するステップをさらに備える、請求項１２に記載の方法。
16. データセンタの電力効率のモデル化方法であって、
    データセンタで用いられる、電力を引き込む装置を特定するステップと、
    各装置について、前記装置の電力入力の定格容量および使用可能容量のうち１つを選択するステップと、
    各装置について、前記装置が固定損失、比例損失、もしくは二乗法則損失、またはそれらの組合せとして寄与するのかどうかを決定するステップとを備える、方法。
17. サブシステム損失を得るために前記装置の電力損失を集約するステップをさらに備える、請求項１６に記載の方法。
18. データセンタ損失を得るために前記サブシステムの電力損失を集約するステップをさらに備える、請求項１７に記載の方法。
19. 前記装置は、電力関連装置および冷却関連装置として特徴付けられる、請求項１６に記載の方法。
20. 装置から以外の損失の原因を特定するステップと、統計データから損失量を予測するステップとをさらに備える、請求項１６に記載の方法。
21. 請求項１６に記載の方法であって、
    データセンタ構成の大多数を含むデータセンタ一覧を提供するステップをさらに備え、前記データセンタ一覧は、例示的な電力構成の電力一覧と例示的な冷却構成の冷却一覧とを有し、
    データセンタ構成を作成するために前記電力一覧と前記冷却一覧とを結合するステップをさらに備える、方法。
22. 前記モデル中の循環依存のための計算を簡易化するステップをさらに備える、請求項１６に記載の方法。
23. データセンタの電力効率をモデル化するためのデータセンタ管理システムであって、
    少なくとも１つのプロセッサを有するデータセンタマネージャを備え、前記プロセッサは、
    データセンタで用いられる、電力を引き込む装置を特定し、
    各装置について、前記装置の電力入力の定格容量および使用可能容量のうち１つを選択し、
    各装置について、前記装置が固定損失、比例損失、もしくは二乗法損失、またはそれらの組合せとして寄与するかどうかを決定するようにプログラムされている、データセンタ管理システム。
24. 前記少なくとも１つのプロセッサは、サブシステム損失を得るために前記装置の電力損失を集約するようにプログラムされている、請求項２３に記載のデータセンタ管理システム。
25. 前記少なくとも１つのプロセッサは、データセンタ損失を得るために前記サブシステムの電力損失を集約するようにプログラムされている、請求項２４に記載のデータセンタ管理システム。
26. 命令を含む命令シーケンスを記憶したコンピュータで読取り可能な媒体であって、前記命令は、プロセッサに、
    データセンタで用いられる、電力を引き込む装置を特定させ、
    各装置について、前記装置の電力入力の定格容量および使用可能容量のうち１つを選択させ、
    各装置について、前記装置が固定損失、比例損失、もしくは二乗法則損失、またはそれらの組合せとして寄与するのかどうかを決定させる、コンピュータで読取り可能な媒体。

Images