リアルタイム・アナリティックスを電力系統へを適用する

筆者の現在の研究の興味は電力系統に対してITと通信(ICT)技術を応用することだ。 ICTの進歩・進展は早い。しかし、ICTだけ独立して動くわけではない。ニーズのないところに投資もついてこない。その恩恵は他の分野にも適用されその 分野の発展や進歩に貢献されるべきである。

センサー技術の発達で、スマートグリッドに付随する装置や機器に安価だが高機能のセンサーが装 着され始めている。それに従って、多くのデータ源から莫大な量のデータがリアルタイムやそうでないペースで生成され、生成されたデータは収集されて解析さ れる。この様な新たなBig Dataの特徴はスピード(velocity)、多種性(variety)、量(volume) (これを3 Vと呼ぶ)で表されるが、今までの relational databases (RDB)では処理出来ない。これが、NoSQLの誕生を招いた。最近参加した NoSQL Now 2013 コンファレンスに関して幾つかブログを書いた。

ここ
ここ
ここ

このコンファレンスでアナリティックスを売りにしている展示会社 を探したが、運よくAcunuという会社を見つけた。 Infochimps 社のJim Kascade 社長をインタビューして以来、アナリティックスの基本を研究し始めた。少しづつ研究するにつれて理解したことはアナリティクスの領域は広く、深く、所謂ア ナリティクスと一言では言えないことを理解した。今まではデータサイエンス屋さんの話が抽象的で詳細を語らないのを訝っていた。でも、今はなぜ専門家が素 人の私に詳細を語りたがらないのかよく分かった。

アナリティックス市場の変遷
Hadoop のアナリティックスはバッチ処理だ。それはそれで結構なことだ。それが向く場所もある。しかし、リアルタイムまたはストリーミング・アナリティックス　は どうだろう。この分野は今大きな注目を浴びている。電力業界では、電気の供給を絶やさないため多くのデータ源からのデータをモニターしている。責任の範囲 によるが、広い地域または狭い地域の電力の需要と供給のバランスを見る必要がある。どちらにしても、異なった生成頻度、スピードや形式のデータが非同期で 飛んでくる。一般的にデータ量が多ければ、多いほどアナリティックスの質が改善される。もちろん、アナリティックスを適用する前に、どのデータが必要か精 査するべきだ。最近のCSCによるInfochimpsによる買収がこのことを如実に語っている。

Acunuのアナリティックス
インタビューの前に数分調査をして、インタビューには45分程度費やした。インタビューにはTim Moreton (CTO) と Dai Clegg (VP marketing)の両氏が応じてくれた。


Tim Moreton氏(左)と Dai Clegg氏

インタビューの後、ブログを書くにはもっと調査　研究の必要を感じた。そのため、インタビューそのものの他、Acunuのドキュメントやその他を参考にしてかなりの時間を費やした。

差別化
全ての会社はその解はユニークであり、競合よりも良いと主張する。では、Acunuの差別化はなんだろう。

全てのアナリティックスはそれぞれユニークだ。リアルタイムの定義同様、ストリーム・　アナリティックスも人によって微妙に定義が異なる。多くの人はこの言葉で多くのことを十把一絡げにしてストリーミング・アナリティックスと使う傾向がある。　Grok Solutions社のようにストリーミング・アナリティックスを提供する会社が数社ある。差別化を精査する情報源としてAcunuのブログが役にたった。もちろん、１つのブログは１つの題目にフォーカスするため、全体を見通せる１つにまとまったホワイトペーパーが望ましい。Timと Dai によればそのうちにそのようなものを用意するとのことだ。

4つの差別化のポイントは:

1. リアルタイムのアナリティックス
2. Cube
3. Cassandra との統合と使い勝手の改善
4. ダッシュ・ボードとアーキテクチャー

リアルタイムのアナリティックス
Acunuはリアルタイム・アナリティックスが差別化の１つであるとはいわなかった。しかし、Acunuがリアルタイムをどのように定義しているのか知るのは有意義だ。Timのブログが良い情報源だ。もちろんハードリアルタイム とは異なる。Timのブログの中でDoug Cutting (Hadoop開発者で、Clouderaのchief architect)の言を引いている:

「コマンドを発して終わるまで、十分座って待てる時間で、終わるまでコーヒーを飲みに行くとか、一晩待たなければならないというものではない。それがリアルタイムだ。」

Acunuのリアルタイムは「API real time」」と呼ばれ、Timの説明では：

Acunu の「API real time」　は運用インテリジェンスとモニタリングのためのものだ。結果はインターアクティブに戻ってくる。大体WebページへのリフレッシュやAPI コールに掛かる通常の遅延程度だ。ストリーミング・アナリティックスは 増加し続け、また持続する。その時点の結果は最新のものだ。それだけではなく、最新のデータは現在までのデータと共にクエリ・解析することができる。 そのため、傾向(trend)、エクセプション、比較などがすぐに検出することができる。

Cube
Acunuの Cube はTimのブログに記述されており、online analytical processing (OLAP) cubeに似通っている。しかし、差異はこのように説明されている。

Acunuのcubeは非常に似通っているが、以下が異なる。新たなデータが到着するたびにインクリメンタルに コンピュートされているので、全てを全部初めからコンピュートしなくても、一度に処理する量は少なくて済む。

Lambda アーキテクチャーでは、 Nathan Marz はアプリとそれがアクセスするデータの間にプリ・コンピュートされたビューを配置した。プリ・コンピュートされたビューがあれば、その時点までに収集され て解析されたデータと共に新たに到着したデータを解析できる。cubeはある時点まで収集されたマルティ次元のデータにある数式を適用した結果を格納して いる。例えば、単に地域毎や時間毎(週、月、年)で売れた商品の個数の合計などだ。ある時点までの結果は既に存在しているので、新たに到着したデータ(最 近の商品の売り上げ個数) は単に加算され、情報が更新される。必要なクエリに応じて、複数のcubes (ビュー)を定義することができる。以下にこの様子を示す。


処理前のデータがいかにリアルタイムで処理されるか。(出典: Tim MoretonのNoSQL Now 2013コンファレンスでのプリゼンより)

注意
これは、Lambda アーキテクチャを実装する１つの方法で、他にも実装の方法はある。しかし、これはこのアーキテクチャーを理解する上で、具体的な例なので理解に役立つ。

Cassandra のインテグレーション
TimはCassandraをデータベースを選んだ理由を以下のように述べた:

Cassandra はスケーらビリティ、性能、複数のデータセンター間サポート、マルティ・マスターアーキテクチャー(no single point of failure)に秀でている。

しかし、彼は続けた:

例外なく殆どのカスタマーはこのシステムを学ぶ際一番困難なのは、Cassandra のデータ・モデリングだ。
…
も ともとのAPIは, Cassandra クエリ言語(CQL)を使ったとしても、非常に簡単過ぎて、本当に非常に簡単なビルディング・ブロックを提供するだけだ。開発者はデータを読み込むスキー マを作成することが必要だ。もし、新らたな機能のために新らたなデータの読み込みが必要となると、それを変更するのは非常に困難だ。

筆 者はCassandra のユーザーでも開発者でもないので、専門的なコメントはできない。しかし、筆者の理解は以下のようだ。一般的にオープンソースの解はオープンであり、柔軟 に対応でき、無料(ライセンスの条件に従う限り)で素晴らしい。問題は使い勝手とサポートの欠如だ。確かに、役に立つコミュニティがあって色々と質問する ことが可能だ。しかし、これを企業のビジネス用に使用するのは、必ずしも容易ではない。そのため、オープンソースの解にはビジネス版が必要なのだ。 Cassandraの場合は, Datastax社がビジネス版をサポートともに提供している。

筆 者の理解では、AcunuはCassandra の上にAcunu クエリ言語 (AQL)を含む層を乗せて、使い勝手をあげている。オープンソースのため、Cassandraには複数の版が存在するが、Acunu は主なものはサポートしている。更に、Apache コミュニティとも密接に連携をしており、アップデートやアップグレードをCassandraのプロジェクトに提供している。

ダッシュボードとアーキテクチャ
可視化(visualization)はBig Data を処理・理解するのには必須だ。また、Cassandra のデータベースとインタフェースするのにも役立つ。Acunuのアーキテクチャを以下に示す。


Acunuのアナリティクスのアーキテクチャ (出典: Tim Moretonの NoSQL Now 2013でのプリゼンより)

Acunu のアナリティクスは複数のデータ・ストリームを同時に受け取ることができる。ストリームはHTTP の他、Flume または Stormで処理できる。

Acunuの今後
Tim とDai によると、現在のアナリティクスの機能は基本的なもので、境界を越えた値の検知とかあるデータの加算値を入手することはできる。もっと、複雑なアナリティ クスの機能が望まれる。例えば、予測。その様な予測機能があれば、電力系統を安定させて信頼性高く運営できる。

最終コメント
Acunu 社のようなベンダーがストリーミング・リアルタイム　アナリティクスの製品を提供していることは頼もしい。それぞれのアナリティクスはたくさんの異なった コンポーネントがそれぞれ特異な方法で結合されている。今後この市場はどうなるのだろうか。今のように多くの会社がばらばらに製品を提供するのだろうか。 それとも、多くの会社が統廃合されていくのだろうか。現在のアナリティクスの会社はSNSやエンタープライズの市場への適用からスマートグリッドのように 新らたな分野へと進出しようとしている。

データセンターに於けるソフトウエア定義の電力とは--その１

この題目はITと電力との接点にあたり、とても興味深い。ITは完全に電力に依存してお り、IT屋であっても電力を意識することが必要となってきた。 しかし、逆にITが電力をコントロールできるようになれば、非常に興味深く素晴らしい。この２回のブログの１回目はデーターセンタにおける電力の問題につ いて述べる。それには電力の価格についての議論も含む。またこれは、２回目のソフトウエア定義の電力の実装に対する準備も兼ねている。ソフトウエア定義の 電力を用いれば、データセンターに於ける諸問題を解決できるのだろうか。

電力不足の問題
データセンターでは電力問題が増加している。典型的な問題は電力不足だ。電力不足が起こるのは以下のような場合だ。

1. 電力会社に十分な電力供給能力がない。
2. 自分の電力システムのコンフィギュレーションが規定されており、容易に改善して電力容量を増加できない。

１ の場合に関しては、更に２つの場合が考えられる。まず自分の立地地域で電力需要が増加して電力会社が十分な電力供給が出来ない場合だ。この場合、電力会社 は送電システム、変電所を含む配電網を改善して整備しなければならない。これには、多額の費用と時間が必要である。更に、電力会社は大抵の場合は十分な電 力供給能力があるが、一時的に需要が増大するとき、例えばピーク時間帯などだ。

２の場合に関しては、自分のデータセンターに与えられてい る電力は制限されおり、それを越えた電力を消費は出来ない。データセンターの電力容量やコンフィギュレーションは固定されており、実際にこれを変更しなけ ればならない。この変更は自分のデータセンターに限らないことが通常だ。データセンターに電力を提供する電力会社はそれに属する変電所やトランスなどを含 めた配電網を整備する必要がある。場合によっては、送電網も改善する必要がある。この改善のの費用は当然データセンター側にも跳ね返る。

更 に言うと、自分のデータセンターの電力コンフィギュレーションはデータセンター全体だけではなく、そのそれぞれのセクションでも同じだ。あるセクションに もっとIT装置をを追加したいとする。しかし、そのセクションに十分な電力が割り当てられていないと、そのPDUのブレーカーが飛んで電気が落ちてしま う。 ラックに十分なスペースがあっても、IT装置の追加はできない。つまり、使用不可能なスペースが生じることになる。この場合、装置場所を考慮する必要があ る。そして、装置を移動する場合それぞれの装置をシャットダウン、 電源を落とし、電源やネットワークの回線を外し、移動して、再び電源とネットワークの回線を接続し、電源を入れて、ブートしなければならない。これは面倒 なプロセスであり、ダウンタイムが生じて、ビジネスにも影響する。 もちろん、複数の装置を移動させる にはデータセンター全体の電力状況を把握して最良のICT装置のレイアウトを考えなければならない。これはなかなか困難なプロセスだ。

以上のそれぞれの場合について言えることは、電力需要の増加が恒常的ウであれば、変更することは正当化されるが、それが稀にしか起こらないのであれば、正当化するのは困難だ。

データセンターでの電力料金
現 在は電力料金はデータセンターでは大きな問題となっている。IT屋だからと言って電力の問題を無視することはできなくなった。 データセンターでの電力料金は複雑で地域毎に異なる。更に、電力料金は様々な要素があり、それぞれの契約は独自なもので一般的な議論は困難だ。しかし、こ のブログのために詳細な議論は簡略化する。実際にはそれぞれのデータセンターの状況や、地域、電力会社によってかなり異なる。

大手のビジネスと産業の消費者用の料金体系には、大抵の電力料金は以下を含む:

*接続費 – 配電網に接続するため
*エネルギー費 –　消費されたエネルギーに対して (単位kWh)
*デマンド費または最大需要電力 – 最大の需要電力に対する料金 (単位kW)

接続費
一般的に多くの電力を必要とすると、電力会社は変電所を含む配電網を整備する必要がある。例えば50MWの電力が必要な場合は20MWの場合に比較して高い接続費を課せられる。

エネルギー費
エ ネルギー費はどれだけの電力を消費したかによって科せられる料金のことだ。これは消費者としてはよく知っている料金だ。使えば使うだけ料金が高くなる。北 と中央カリフォルニア州に電力を提供しているPG&E社の地域では、データセンターのように大量の電力を消費する消費者には、時間によって変化す る料金体系が科せられている。kWあたりの値段は一日のうち時間によって変化する。一般的に午後に一番高くなる。その上、一年のうち何日かはピーク日とい うものが決められており、その日は更に高い料金が上乗せされる。

デマンド費
PG&E社によるとデマンド値は:

住 宅用でない多くの料金はデマンド費を含む。デマンドは１ヶ月の料金サイクルの間で１５分（または短い場合は５分）の間に消費れた最大の電力の計測値であ り、kWで表される。大きなデマンドは通常装置の立ち上がり時に見られる。全ての装置を一度に立ち上げずに分けて立ち上げることで、デマンド費を小さく抑 えることができる。

負荷が変動し、時々突出すると高いデマンド値が科せられる。 出来るだけ、負荷による需要を平坦にすることが肝要だ。

データセンターで電力料金を削減するにはどうすれば良いのだろうか。例えば、以下のような方策を採用することだ。

*適切な電力容量を設計し計画する。
*高騰するデマンド費を避けるため出来るだけ負荷の変動を防ぎ一律の負荷分布にする。
*ピーク時やピーク日の料金に注意を払う。

上 は当然のことの様だが、適正な電力容量を決定するのは容易なことではない。一般に将来の拡張を考慮して余裕を持たして設定し、大きく設定しがちである。ま た、多くのデータセンターはミッション・クリティカルであるため、ピーク時でも停止せず運転する必要がある。また、負荷をできるだけ上下なしに配分するこ とは容易ではない。

いつ電力をコントロールするのか
電力は一旦発電されると大量に貯蔵でき ず、すぐに消費されなければならない。言い換えれば、電力は供給を制御できないので、需要を制御するしかない。これはデータセンターでも同じことだ。制御 とは負荷による需要を軽減することである。ではいつ負荷を軽減すれば良いのだろうか。それは、電力料金が高くなったとき、または電力が不足している時だ。 それに使われるのがデマンド・リスポンスだ。PG&E社はデマンド・リスポンスを次のように説明している:

PG&E 社のデマンド・リスポンスは消費者が需要のピーク時にエネルギー負荷を軽減することができるようにしたプログラムである。 大抵のPG&E社の デマンド・リスポンスは需要のピーク時に負荷軽減のための経済的な誘因を与えるという側面も持っている。

デマ ンド・リスポンスはデータセンターにはあまりなじみのないものだった。と言うのは、データセンターはミッション・クリティカルと考えられて何があっても停 止されないと思われて来たからだ。しかしながら、研究用やテスト用のデータセンターの負荷は軽減することが可能であろう。

その２で実際にどのようにしてソフトウエア定義の電力を実装できるのか、その１つを示そう。

このブログの電力料金に関しては、Power Assure社のPeter Maltbaek氏に色々と助言を頂いた。

NoSQL Now 2013で学んだこと

最近San Joseで開催されたNoSQL conferenceに 参加した。チュートリアル１つと基調講演２つに参加して、更にアナリティックスの会社１社をインタビューした。 筆者の現在のNoSQLへの興味は、スマートグリッドに搭載された多くのセンサーから発せられたBig Dataを解析して電力系統の信頼性を高め、安定度を増加するためのアナリティックスの技術だ。



チュートリアル
このブログではチュートリアルの部分のみを取り上げる。去年のコンファレンスでは「 NoSQL 101」というチュートリアルに参加した。今年は「 Introduction to the Hadoop Ecosystem」というチュートリアルに参加した。このチュートリアルではSciSpike社のVladimir Bacvanski氏がHadoopの仕組みとそのecosystemについて述べた。





Hadoop はBig Data と同義語としてよく使われ、様々なところで述べられている。しかし、簡単な説明ではなかなかその本質に迫ることはできない。筆者はそれぞれの新分野をかな り理解できるまでには、片っ端から簡単であろうが詳細であろうが情報を乱読することにしている。どの分野でも同じことだが、技術的な言葉とその本質には大 きなギャップがある。筆者のブログは簡単な説明と詳細な説明との間に位置するようにしている。

チュートリアルで提示されたものの大部分は 既知であったが、知識の反復や所々にあいた穴を補充するには非常に役にたった。これで、Hadoop がなにでどういう立ち位置かを理解した気がする。このチュートリアルはお薦めだ。チュートリアルの中身をすべて網羅するわけにはいかないので、筆者がラン ダムに選択した項目を取り上げる。

* Big Data のソースはトランスアクション (ビジネス・システム), ドキュメント (テキスト、イメージ、音声、ビデオ), ソーシャル・メディア (Twitter, Facebook, ブログ)と 装置や機器に取り付けられたセンサーなどだ。センサーは特に興味深い。センサーの技術進歩により、以前は出来なかったデータ収集がスマートグリッドから入 手できるようになった。多くの異なった形式のデータが生成されしかも非同期で異なったスピードでどんどん飛んでくる。筆者の興味はこういったデータをいか に集め、集合し、統合解析し、有益な情報を引き出し、電力系統を最適化に利用することだ。
* Big Dataの３つのVはvolume(量), variety(種類)とvelocity(スピード)だ。他のVは veracity (真実性)とviability(実行可能性)だ。
* HadoopはMapReduce と Hadoop distributed file system (HDFS)から成り立っている。
* MapReduce はHDFSのファイルシステムの上で実行される。
* MapReduce では入力データは細か分割され(map)、それぞれクラスターの多くのノードに分散される。それぞれのノードでデータは処理され、集合・併合されて全体と してはデータのサイズは縮小される(reduce)。こういった処理は自動化されており、ユーザーが手動でなにかしなければならないということではない。
* 新しい考え方は「プロセスをデータに持って行く」であり、現在までの「データをプロセスに持って行く」からの大きなパラダイムの変化である。
* Hadoopに関するその他のコンポーネントに関しても簡単に触れる。Hive はデータ・ウエアハウスのインフラだ。HiveQL (クエリ言語)も含む。



* Pig は大きなデータセットを解析するプラットフォームだ。データアナリシスを行うプログラムを表現するハイ・レベル言語から成り立ち、そういったプログラムを 評価するインフラも含む。Pigの顕著な特徴はその構造が並列化に適しており、そのため非常に大きなデータセットを扱えることだ。



* HBase はHDFSの上のコラム・ベースのデータベースだ。



* Zookeeper は分散をコーディネートするサービスを提供する。


* その他に HCatalogはHive の一部でPig, Hiveと MapReduceの整合性を提供する。 SqoopはHadoopの自動インポート・エクスポートを提供し、 Flumeは大量のログ・データを収集、集合し移動させる。



* Hadoopを使用したアナリティックスは原則としてリアル・タイムではなくてバッチ・モードだ。 スマートグリッドでは収集され送信されるデータはリアル・タイム及びリアル・タイムでないものを同時に含む。リアルタイムで到着するデータを処理すること は最近は注目が集まっている。ストリーミング処理でデーターを取得して、アナリティクスを適用することが必要となる。以下のストリーミング処理プログラム が主なものだ。

- Apache S4 (オープン・ソース)
- Esper (オープン・ソース)
- IBM InfoSphere Streams
- Twitter Storm
- Walmart Labs MUPD8



チュー トリアルに出たからって終わったわけではなく、もっと学ぶことが多い。良いことは、NoSQLやアナリティクスの技術を提供する会社はSNSやビジネス・ トランスアクション以外にも適用範囲を広げようとしている。スマート・グリッドは電力、通信とITを融合するものだ。こういった新たに出現するICT の技術はもっとスマートグリッドに適用されるだろうし、そのおかげでＩＣＴの市場も増大する。

データセンターの冷却はソフトウエア定義できるのか

最近ソフトウエア定義されるデータセンターが注目を浴びている。データセンターは周知のようにICTとファシリティの装置で成り立っている。しかし、現在のソフトウエア定義されるデータセンターにはファシリティの装置は含まれない。しかし、幾らICTの装置やそのレイアウトをソフトウエアで定義しても、その装置を問題なく動作させるためには、適度な冷却と電力が必要である。つまり、冷却と電力もソフトウエア定義されないと本当の意味ではデータセンターをソフトウエアで定義したことにはならない。このブログでは、冷却のソフトウエア定義に関して述べる。


冷却のソフトウエア定義を謳っているベンダーはあまり多くない。と言うか、筆者は一社しか知らない。それは、Vigilent社だ。早速知り合いのVigilent社のAlex Fielding氏に話を聞いた。

Alex Fielding氏


Vigilent社
非常に簡単に言うと、Vigilent社はデータセンター・インフラ管理(DCIM)のツールを提供するベンダーである。市場調査会社のGartnerはDCIMツールをを以下の様に定義している。　


データセンターの効率やエネルギー消費をモニター、計測、管理または制御する全てのIT関係の装置（サーバー、ストレッジ、ネットワークなど）やファシリティのインフラの要素（PDUやCRACなど）を含む。


Vigilent社の業務内容
Vigilent はDCIM のベンダーでデータセンターの冷却を管理する。非常に分かり易い。周知のようにデータセンターの運用は大部分はファシリティの人々によってなされる。IT関係の人たちはお客さんとして見られることが多い。しかも、なかなか要求の多い客だと思われがちだ。過去には何回もITとファシリティを統合し、データセンターを効率良く運用しようとする試みがなされた。幾分かの成功例はあるものの、統合管理というのはITとファシリティのどちらにも受け入れにくい提案の様だ。Fielding氏 によれば Vigilentの業績が良いのは２つの理由がある。１つはデータセンターの運用に大きな影響を与える部分を改善するからだ、つまり効率の高い冷却方法だ。40% から50% の冷却に必要な電力消費に影響を与えることができる。つまり、必要な所に必要な量の冷却を提供するのだ。だから、非常に恩恵が見えやすい。何かしなかればならないのはファシリティ側だけで、IT側のサーバーなどのIT機器にはタッチしない。しかし、そのおかげでIT側の人を巻き込む必要もなく、サーバーなどの装置に触れることもないが、IT装置を安定して問題なく運転することができる。ファシリティの人たちは簡単に理解でき、すぐに恩恵が見られるものであれば、非常に受け入れやすいという分けだ。その上、実際のインストレーションから数日でエネルギー効率の改善が見られるとFielding氏は続けた。


実装
Vigilentの技術を説明するのは容易だ。常にデータセンター内の冷却の必要性をモニターして計測し、本当に必要なところに動的に最少必要限の冷却を提供するということだ。サーバーやその他のIT 装置は負荷によって発熱量が異なる。データセンターの負荷は動的に時間毎や日ごとでも変化する。通常将来の拡張を見込んで、電力も冷却も過剰に準備しがちだ。IT装置は必要以上に冷却しすぎる必要はなく、冷却の必要性が軽減されれば冷却もそれに伴って調整されるべきだ。

Vigilentは正にその機能を提供する。一般的にデータセンターの冷却は冷却装置に戻ってくる熱くなった空気の温度を感知して温度調整を行う。しかし、本当に必要なのはサーバーの取り入れ口での空気の温度をモニターし温度調節をすることだ。これが行われなかったのは、以前は容易にサーバーの取り入れ口での空気の温度を測定できなかったからだ。ここ数年、サーバーやラックレベルでの温度や湿度などの環境情況をモニターし計測されるようになった。これを使用すれば、実際にモニター・計測しなければならない箇所で環境情況の情報を入手できるようになり、もっと効率の良い冷却を提供できるようになる。Vigilentは無線センサーを利用してDust Networks のメッシュ・ネットワークを利用して環境情報を収集する。常に温度などの環境情報を収集してモニターして、冷却装置を電源を入れたり、止めたり、またそのファンのスピードを調整することで、冷却量を調整することが出来る。以下の図はこの様子を示している。

Vigilentのシステムの仕組み (出典: Vigilent)


冷却の仮想化
Vigilentが最初に冷却の仮想化を言い出した。冷却の仮想化とは何だろう。あるものが仮想化されるのであれば、それを簡単さらに動的に生成、増量、除去、減量　および移動させることができる。これはサーバーの仮想化に当てはめてみると良く分かる。


冷却は:

• 生成される (冷却装置の電源をオンにする)
  
• 増量される(更に他の冷却装置の電源をオンにするまたは、ファンのスピードを増加する、チラーの温度を下げる)
  
• 除去される(冷却装置を停止を停止したり、スリープ・モードにする)
  
• 減量される(冷却装置の一部を停止したり、ファンのスピードを下げたり、チラーの温度を上げる)
  

移動はどうだろう。冷却って動的に移動できるのだろうか。実際のところ、仮想化されたサーバーも物理的に移動されるわけではない。vMotionの様にバーチャル・マシン(VM)の移動は生成、コピーと除去で実装されている。その仕組みは、新しいVM のインスタンスが移動先のサーバーに生成される、実行状態を元のVMのインスタンスからこのインスタンスにコピーする、そして最後にもとのインスタンスを除去する。この手法は冷却にも適用できる。サーバーのVMが１つのサーバーから他のサーバーに移動されると、当然移動元と移動先のサーバーに対する冷却の要求は変化する。移動元用のサーバーに対する冷却は停止されるか、冷却量を削減できる。これに反して、移動先のサーバーは冷却要求が増加して、移動先用のために新たな冷却のインスタンスを生成することで対応できる。


当然サーバーと冷却ではインスタンスの移動は全く同じではない。冷却のインスタンスはサーバーのVMの様に、移動元と移動先では全く同じコピーではない。物理的なレイアウトなどの幾つかのファクターにより、移動元と移動先では冷却量でさえ異なるかも知れない。しかし、これは移動元から移動先に動的に冷却が移動したと言えるだろう。ということで、冷却はIT機器の様に仮想化されると言う事にする。


以前に述べた電力の仮想化と共に、ソフトウエア定義されるデータセンターが新しく定義される。これによって、データセンターのコンフィギュレーションや要求をソフトウエアで定義すれば自動的にデータセンターを設計したり、最適な運用形態を自動的に生成することができる。これを敷衍すれば、ビルのエネルギー管理にも適用できるだろう。