JP5207527B2 - 空調システムの制御方法 - Google Patents

Description

本発明は空調システムの制御方法に係り、特に仮想化技術等によりデータ処理分担の集中・分散制御が行われる情報通信機械室の冷却に好適な空調システムの制御方法に関する。

近年、ＩＣＴ機器・装置（以下、サーバと総称することがある）の省エネ対策として「仮想化技術」が注目されている。これは、多数のサーバが低い稼働率で分散処理している場合に、一部のサーバにデータ処理を集約するものであり、サーバ群の消費電力削減に大きく寄与するものである。しかしながら、集中処理の対象となるサーバについては、１ラック当たりの消費電力が１０−２０ｋＷに達することもあり、当該サーバの発熱による局所的な高温エリアの発生が問題となる。
また、最新のＩＣＴ機器・装置は、ＣＰＵ稼働率に応じて筐体内に備えたファンの回転数を制御しているが、複数の機器が同時にファン回転数を増加させた場合、空調機側の風量供給が追随できず、室内気流バランスが崩れてサーバ冷却に支障をきたすおそれがある。特に、アイルキャッピングを採用する室内においては、冷気供給不足によりコールドアイルに局所的な高温エリアが生じ、機器・装置の高温障害発生という問題が生じる。

一方、情報通信機械室（データセンタ）においては、ベース（アンビエント）空調機又は／及びスポット空調機を用いて、吸い込み空気温度又は吹き出し温度に基づいて冷房能力、風量制御を行うシステムが一般的である（例えば特許文献１）。この場合、サーバ群の稼動状況が考慮されることがないため、上記仮想化技術等、ＩＣＴ技術の進展に追随できていないのが現状である。
特開平５−２６５００号公報

このようなサーバ群の稼動負荷変化に対して、予め機械室全体を低温度に維持、又は、サーバの最大風量に合わせた風量を空調機から供給することにより対応可能ではあるが、全体として過剰冷却又は送風機動力の増大につながり、省エネ化の要請に反することになる。
本発明は、このような課題を解決するためのものであって、仮想化技術の適用によるデータ処理の集中・分散によるサーバの稼動負荷の偏在が生じても、局所的な高温領域を発生させることのない空調システムの制御方法を提供するものである。

本発明は以下の内容をその要旨とする。すなわち、本発明に係る空調システムの制御方法は、
（１）情報通信機械室内に収容されるＩＣＴ機器群を、一以上の空調機により冷却するものであって、室内に備えられた温度センサあるいは空調機で保有する温度センサで高温、低温を検知するより早く、一の空調機が分担する冷却対象ゾーンに属する一以上のＩＣＴ機器の稼動負荷情報に基づいて、当該空調機の冷房能力又は／及び風量を制御することを特徴とする。
本発明において、「ＩＣＴ機器」とは、サーバ、ストレージ、ルータ等の情報通信機器・装置をいう。
本発明において、「空調機」には、ベース（アンビエント）空調機又はスポット（局所）空調機の一方又は両方を含む。

（２）前記稼動負荷情報は、前記一以上のＩＣＴ機器へのデータ処理分担切り替え後の稼動負荷変動値を含む、ことを特徴とする。
（３）前記稼動負荷情報は、前記一以上のＩＣＴ機器へのデータ処理分担切り替えに伴う稼動負荷変動予測値を含む、ことを特徴とする。
稼動負荷変動予測値に基づいて空調機能力を制御することにより、機器の発熱前に予め室内を冷却することが可能となる。
（４）前記ＩＣＴ機器の稼動負荷情報が、前記一以上のＩＣＴ機器の消費電力情報であることを特徴とする。
（５）前記ＩＣＴ機器の稼動負荷情報が、前記一以上のＩＣＴ機器の冷却ファン風量情報であることを特徴とする。
（６）前記ＩＣＴ機器の稼動負荷情報が、前記一以上のＩＣＴ機器が備える温度センサで計測された温度情報であることを特徴とする。
「稼動負荷情報」として、機器発熱状態を把握又は予測するための直接的指標となる消費電力情報、冷却ファン風量情報、温度情報を用いることが有効である。

室内又は空調機内の温度センサにより、間接的にＩＣＴ機器の発熱状態を検知して機器を冷却する従来の空調方法と比較して、本発明は直接、発熱状態を把握又は予測して冷却する方法であるため、より迅速な制御が可能となり、機器・装置の高温障害のリスクを回避できる。

以下、本発明に係る空調システムの制御方法の実施形態について、図１乃至１０を参照してさらに詳細に説明する。重複説明を避けるため、各図において同一構成には同一符号を用いて示している。なお、本発明の範囲は特許請求の範囲記載のものであって、以下の実施形態に限定されないことはいうまでもない。

（第一の実施形態）
本実施形態は、サーバ側データ処理分担切り替えに伴う各サーバの消費電力変化をフィードバックして、該当するスポット空調機の冷房能力を制御（ＦＢ制御）するものである。
図１は、本発明の一実施形態に係る空調システム１の全体構成を示す図である。図２は、ラック型空調機5-1の冷却対象ゾーンＺ１の詳細構成を示す図である。図３は、第一の実施形態における空調制御フローを示す図である。

図１を参照して、空調システム１は、情報通信機械室２内に収容され、ラック列６を構成する複数のサーバラック（以下、ラック）４を、アンビエント空調機である空調機３及び、各ラック列６に配設されるスポット空調機であるラック型空調機5-1乃至5-4により冷却するシステムである。

空調機３は、いずれも不図示の蒸発器、送風機等を備えた室内ユニット３ａと、圧縮機、凝縮器等を備えた室外ユニット３ｂと、を主要構成とし、室内ユニット３ａ内に吸い込んだ機械室内空気を、冷凍サイクル運転で発生させた冷熱と熱交換器させて冷却し、送風機により二重床空間２ａ（図２参照）を介して室内に供給する。
図２をも参照して、ラック列６は、横一列に並んだ同一モジュールの複数のサーバラック４により構成されている。ラック４内には複数のサーバ４ａが積層されており、各サーバ４ａはそれぞれ冷却ファン４ｂを備えている。これにより、ラック全体として前面から冷気を吸込み、機器内部を冷却したのち高温空気を背面から排気するように構成されている。

各ラック４は、隣接する列の吸気面と吸気面、排気面と排気面が対向するように配置されており、これにより、吸気面側にはコールドアイル９が、排気面側にはホットアイル１０が形成されている。コールドアイル９床面の開口部２ｃには穴あきパネル２ｄが敷設されており、空調機３から供給される冷気をコールドアイル９に吹き出すように構成されている。
各ラック列６において、内部発熱の大きなサーバを格納するラック近傍には、スポット空調機としてラック型空調機5-1乃至5-4が配置されている。各ラック型空調機はラック４と同一モジュール、かつ、吸排気方向が各ラック４とは逆向きに置かれている。すなわち、ホットアイル空間の高温排気を吸込み、コールドアイル側に冷却空気を吹き出すように配置されている。

ラック型空調機5-1は、蒸発器５ｅ、送風機５ｂ、制御部５ｄを主要構成として備えた室内機５ａと、いずれも不図示の圧縮機、凝縮器を主要構成として備えた室外機（図示せず）と、これらを接続する冷媒配管５ｃを備えている。制御部５ｄは、圧縮機周波数及び送風機５ｂ回転数により冷房出力を演算して、空調機制御装置８に出力するように構成されている。空調機5-2乃至5-4についても同一に構成されている。なお、圧縮機については室内機側に配設する形態であってもよい。
左側コールドアイル９内には、ラック型空調機5-1、5-2がそれぞれ分担する冷却対象ゾーンＺ１、Ｚ２が設定されている。各ラック型空調機は、分担する制御対象空間内において冷熱・風量収支バランスを維持するように冷気を供給する。ゾーンＺ１を例にとると、床面から供給されるアンビエント空調機３の冷房出力Ｗａは一定であり、一方、ラック型空調機5-1の冷房能力Ｗｓは、後述するようにゾーン内サーバ群の消費電力に対応して可変に設定されている。

空調システム１の制御系統は、ＩＣＴ機器管理サーバ（以下、管理サーバという）７ｂ、空調機制御装置８、及びこれら両者の連携をとって統合的に制御する統合制御サーバ７ａを主要構成として備えている。管理サーバ７ｂは、ホストサーバ（図示せず）から指令されるデータ処理を、仮想化技術を適用して各サーバに分配するとともに、後述するように各サーバの稼働負荷情報（ＣＰＵ稼働率情報、消費電力情報、ファン回転数情報等）を、統合制御サーバ７ａを介して空調機制御装置８に送信するように構成されている。
空調機制御装置８は、統合制御サーバ７ａを介して管理サーバ７ｂから送信される稼働負荷情報に基づいて、空調機5-1乃至5-4の制御部に対して冷房能力制御を指示するように構成されている。

空調システム１は以上のように構成されており、次に図３をも参照してＣＰＵ稼働率変化に基づいて行われる、ラック型空調機5-1のＦＢ制御フローについて説明する。
管理サーバ７ｂは、所定のタイムスパンごとに各サーバの現在ＣＰＵ稼働率を把握する（Ｓ１０１）。次いで、次タイムスパンについて、全体のデータ処理能力を最大にするか、あるいは全体の消費電力を最小とする最適データ処理分担を演算し（Ｓ１０２）、各サーバに対して分担データ処理を指令する（Ｓ１０３）。さらに、切替後の指令に基づく各サーバの消費電力実績値を把握し（Ｓ１０４）、ゾーンＺ１での総消費電力（この値は、ゾーンＺ１内サーバ群発熱量とみなし得る）を演算する。次いで、ゾーン単位の消費電力実績値（Ｗｔ）情報を、統合制御サーバ７ａを介して空調機制御装置８に送信する（Ｓ１０５）。

一方、空調機制御装置８側では、ラック型空調機5-1は初期状態において圧縮機周波数、送風機風量ともデフォルト値で運転されている（Ｓ１２１）。また、吸い込み空気温度（又は吹き出し空気温度）に基づいてフィードバック制御を行っている。そして、Ｓ１０４のゾーン単位の消費電力情報が送信されると、現時点におけるゾーンＺ１のアンビエント空調機３及びラック型空調機5-1の合計冷房出力Ｗｐ（＝Ｗａ＋Ｗｓ）を演算する（Ｓ１２２）。次いで、ゾーンＺ１内サーバ群の消費電力値（発熱量）Ｗｔと、現時点における合計冷房出力Ｗｐと、を比較する（Ｓ１２３、Ｓ１２４）。Ｗｔ＞Ｗｐ＋αのときは空調機5-1の圧縮機周波数又は／及びファン風量を１段階アップして冷房出力を上げる（Ｓ１２５）。Ｗｔ＜Ｗｐ−αのときは圧縮機周波数又は／及びファン風量を１段階ダウンして冷房出力を下げる（Ｓ１２６）。なお、αはチャタリング回避のためのディファレンシャルである。
以上の制御をデータ処理分担切り替えごとに行うことにより、消費電力が上昇したサーバ周辺を速やかに冷却することができる。

なお、本実施形態では、消費電力情報に基づいてラック型空調機の冷房出力を調整する例を示したが、アンビエント空調機３の冷房出力を調整する形態としてもよい。
また、ＣＰＵ稼働率と消費電力の関係が明らかになっていれば、ＣＰＵ稼働率に基づいて空調機の冷房出力を調整する形態でもよい。
また、管理サーバ７ｂがゾーン単位の消費電力を演算して、統合制御サーバ７ａを介して空調機制御装置８に送信する例を示したが、管理サーバ７ｂから送られる各ＩＣＴ機器の消費電力情報に基づいて、統合制御サーバ７ａがゾーン単位の消費電力を演算する形態でもよい。さらに、管理サーバ７ｂから統合制御サーバ７ａを介して送信される各ＩＣＴ機器の消費電力情報に基づいて、空調機制御装置８側でゾーン単位の消費電力を演算する形態としてもよい。

（第二の実施形態）
次に、図４を参照して本発明の第二の実施形態について説明する。本実施形態が第一の実施形態と異なる点は、第一の実施形態がＦＢ制御、すなわち、データ処理分担切り替え後の各サーバの消費電力変化に対応して、該当空調機の冷房能力を制御するのに対して、本実施形態はフィードフォワード（ＦＦ）制御、すなわち、切り替えによる各サーバの消費電力変化を予測して、事前に該当空調機の冷房能力を制御することである。

本実施形態の構成は第一の実施形態と同一であるので、重複説明を省略する。図４は、本実施形態の空調制御フローを示す図である。Ｓ２０１、Ｓ２０２については、上述の実施形態のＳ１０１、Ｓ１０２と同一である。次いで、次タイムスパンについて、各サーバへの分配処理量に基づいて消費電力予測値を演算し（Ｓ２０３）、統合制御サーバ７ａを介してゾーン単位の消費電力予測値（Ｗtf）を空調機制御装置８に送信する（Ｓ２０４）。引き続き、各サーバに対して割り当て分のデータ処理を指令する（Ｓ２０５）。

一方、空調機制御装置８側では、ラック型空調機5-1は初期状態では圧縮機周波数、送風機風量ともデフォルト値で運転されている（Ｓ２２１）。Ｓ２０４のゾーン単位の消費電力予測値（Ｗｔｆ）が送信されると、現時点におけるゾーンＺ１のアンビエント空調機３及びラック型空調機5-1の合計冷房出力Ｗｐ（＝Ｗａ＋Ｗｓ）を演算する（Ｓ２２２）。次いで、次タイムスパンにおける消費電力（発熱量に該当）予測値（Ｗtf）と、現時点における冷房出力合計Ｗｐとを比較する（Ｓ２２３、Ｓ２２４）。Ｗtf＞Ｗｐ＋αのときは空調機5-1の圧縮機周波数又は／及びファン風量を１段階アップして冷房出力を上げる（Ｓ２２５）。Ｗtf＜Ｗｐ−αのときは冷房出力過多であるが、常に安全側に制御するため以下の制御を行う。まず、冷房出力を１段階ダウンしたときの冷房出力（Ｗｐ（-））を演算し（Ｓ２２６）、次いでＷtfとＷｐ（-）とを比較する（Ｓ２２７）。Ｗｐ（-）≧Ｗtfであれば（Ｓ２２７においてＹＥＳ）、空調機5-1の冷房能力を１段階ダウンする（Ｓ２２８）。Ｗｐ（-）＜Ｗtfのときは（Ｓ２２７においてＮＯ）、フィードバック制御を続ける。
以上の制御をデータ処理分担切り替えのタイミングで行うことにより、消費電力が上昇するサーバ周辺を発熱前に予冷することが可能となる。

（第三の実施形態）
次に、本発明の他の実施形態について説明する。本実施形態が上述の各実施形態と異なる点は、消費電力変化に基づくのではなく、各サーバのファン回転数（風量）変化をフィードバックして、該当スポット空調機の供給風量を制御することである。本発明の構成は第一の実施形態と同一であるので、重複説明を省略する。
図５は、ゾーンＺ１における風量バランスを示す図である。図６は、本実施形態
の実施形態の空調制御フローを示す図である。

図５を参照して、Ｓ３０１−Ｓ３０３については、上述の実施形態のＳ１０１−Ｓ１０３と同一である。次いで、管理サーバ７ｂは切替後の指令に基づく各サーバのファン回転数実績値（ｇｉ）を把握し（Ｓ３０４）、統合制御サーバ７ａを介してこれを空調機制御装置８に送信する（Ｓ３０５）。
一方、図６をも参照して、空調機制御装置８側では、初期状態においてラック型空調機5-1の送風機５ｂは、デフォルト風量で運転されている（Ｓ３２１）。Ｓ３０２のファン回転数情報を受信すると、各サーバのファン風量を積算してゾーンＺ１の総風量（Ｇｔ＝Σｇｉ）を演算する（Ｓ３２２）。さらに、アンビエント空調機３及びラック型空調機5-1の合計風量Ｇｐ（＝Ｇａ＋Ｇｓ）を演算する（Ｓ３２３）。次いで、両者を比較する（Ｓ３２４）。Ｇｐ＞Ｇｔ＋βのときは冷気供給不足によりサーバ冷却に支障ありと判定して、空調機5-1のファン風量を１段階アップする（Ｓ３２５）。Ｇｐ＜Ｇｔ−βのときは冷気供給過多であるため、空調機5-1のファン風量を１段階ダウンする（Ｓ１２６）。なお、βはチャタリング回避のためのディファレンシャルである。
以上の制御をデータ処理分担の切替タイミングで行うことにより、ファン回転数が増加したサーバ周辺の冷気供給量を速やかに増加させることができる。

（第四の実施形態）
さらに図７を参照して、他の実施形態について説明する。本実施形態が第三の実施形態と異なる点は、各サーバのファン回転数（風量）変化に対応して該当空調機の供給風量を制御するのではなく、データ処理分担切替に伴う各サーバのファン回転数変化を予測して、事前に該当空調機の供給風量を制御することである。
図７を参照して、Ｓ４０１、Ｓ４０２については、上述の実施形態のＳ３０１、Ｓ３０２と同一である。次いで、管理サーバ７ｂは分担切替後の各サーバの消費電力予測値を演算し、さらにこれに対応するファン回転数予測値（ｇif）を求めて（Ｓ４０３）、その情報を統合制御サーバ７ａを介して空調機制御装置８に送信する（Ｓ４０４）。引き続き、各サーバに対して割り当て分のデータ処理を指令する（Ｓ４０５）。

一方、空調機制御装置８側では、ラック型空調機5-1の送風機５ｂは、初期状態においてデフォルト風量で運転されている（Ｓ４２１）。Ｓ４０５のファン回転数予測値情報を受信すると、各サーバのファン風量を積算してゾーンＺ１の総風量（Ｇtf＝Σｇif）を演算する。さらに、アンビエント空調機３及びラック型空調機5-1の合計風量Ｇｐ（＝Ｇａ＋Ｇｓ）を演算する（Ｓ４２２）。次いで、両者を比較する（Ｓ４２３）。Ｇｐ＞Ｇtf＋βのときは冷気供給不足によりサーバ冷却に支障ありとして、空調機5-1のファン風量を１段階アップする（Ｓ４２５）。Ｇｓ＜Ｇtf−βのときは冷気供給過多であるが、常に安全側に維持するため以下の制御を行う。まず、ファン風量を１段階ダウンしたときの風量（Ｇｐ（-））を演算し（Ｓ４２６）、次いでＧtfとＧｐ（-）とを比較する（Ｓ４２７）。Ｇｐ（-）≧Ｇtfであれば（Ｓ４２７においてＹＥＳ）、空調機5-1のファン風量を１段階ダウンする（Ｓ４２８）。Ｇｐ（-）＜Ｇtfのときは（Ｓ４２７においてＮＯ）、フィードバック制御を続ける。
以上の制御をデータ処理分担切り替えに先行して行うことにより、稼働率が上昇する冷却対象ゾーンの風量不足を事前に回避することが可能となる。

（第五の実施形態）
さらに、本発明の他の実施形態について説明する。図８、９を参照して、本実施形態に係る空調システム２０が上述の各実施形態と異なる点は、各ゾーンＺ１〜Ｚ４の二重床開口部２２に配設される穴あきパネル２３が、それぞれ床パネルファン21-1〜21-4を備えていることである。その他の構成については各実施形態と同一であるので、説明を省略する。
次に図１０を参照して、空調システム２０の風量制御方法について説明する。管理サーバ７ｂの分担切替に伴う各サーバのファン風量変化をフィードバックして、ラック型空調機の風量を制御する点については、第三の実施形態と同様である。さらに本実施形態では、必要に応じて床パネルファンを運転して風量制御する点が異なる。

Ｓ５０１〜Ｓ５０５及びＳ５２１〜Ｓ５２４については、第三の実施形態（図３）におけるＳ３０１〜Ｓ３０５及びＳ３２１〜Ｓ３２４と同様である。なお、Ｓ５２１において、床パネルファン21-1、21-4は共に運転停止状態にある。
Ｓ５２４においてＧｐ＜Ｇｔ−βのときは、冷気供給過多であるため空調機5-1のファン風量を１段階ダウンする（Ｓ５２８）。一方、Ｇｐ＞Ｇｔ＋βのときは冷気供給不足であり、冷気供給を増加させる必要がある。この場合、空調機5-1の送風機５ｂが既に最大風量に達しているか否かを判定する（Ｓ５２５）。最大風量に至っていないときは、風量をさらに１段階アップして冷気供給量を増加させる（Ｓ５２６）。既に最大風量に至っているときは、二重床空間からの冷気供給量を増加させるため、床パネルファン21-1の運転を開始する（Ｓ５２７）。この間、床パネルファン21-4は停止状態であるため、アンビエント空調機３から二重床空間を介して冷却対象ゾーンＺ１、Ｚ４に供給される冷気量を比較すると、Ｇａ（１）＞Ｇａ（４）となる。
以上のように、床パネルファンを用いることにより、アンビエント空調機から各ゾーンに供給される風量のバランスを適宜変化させることができる。これにより、特定の冷却対象ゾーンについてスポット空調機の風量増加のみでは不足する場合であっても、さらに供給風量を増加させることが可能となる。

なお、本実施形態では、床パネルファンの運転について風量一定（ＯＮ−ＯＦＦ）の例を示したが、必要風量に対応して可変とする形態としてもよい。
また、データ処理分担切替に伴う各サーバファン風量変化をフィードバックして、空調機側風量を制御する形態としたが、第四の実施形態に対応するフィードフォワード制御の形態とすることもできる。

本発明は、熱源、冷媒、空調方式、建築構造等の種類を問わず、ＩＣＴ機器・装置を収容する機械室等の空調システムに広く適用可能である。

第一の実施形態に係る空調システム１の全体構成を示す図である。 ラック型空調機5-1の冷却対象ゾーンＺ１の詳細構成を示す図である。 第一の実施形態の空調制御フローを示す図である。 第二の実施形態の空調制御フローを示す図である。 第三の実施形態の冷却対象ゾーンＺ１における風量バランスを示す図である。 第三の実施形態の空調制御フローを示す図である。 第四の実施形態の空調制御フローを示す図である。 第五の実施形態に係る空調システム２０の全体構成を示す図である。 空調システム２０の断面構成を示す図である。 第五の実施形態の空調制御フローを示す図である。

符号の説明

１、２０・・・・空調システム
２・・・・情報通信機械室
２ａ・・・二重床空間
２ｄ、２３・・・穴あきパネル
３・・・・アンビエント空調機
４・・・・サーバラック
４ａ・・・サーバ
４ｂ・・・冷却ファン
５−１〜５−４・・・・ラック型空調機
６・・・・ラック列
７ａ・・・統合制御サーバ
７ｂ・・・ＩＣＴ機器管理サーバ
８・・・・空調機制御装置
９・・・・コールドアイル
１０・・・ホットアイル
２１−１〜２１−４・・・床パネルファン

Claims (1)

1. 情報通信機械室内に収容されるＩＣＴ機器群を、一以上の空調機により冷却する空調システムの制御方法であって、
   一の空調機が分担する冷却対象ゾーンに属する一以上のＩＣＴ機器の稼動負荷情報に基づいて、当該空調機の冷房能力又は風量の一方又は両方を制御するものであり、
   前記稼動負荷情報は、前記一以上のＩＣＴ機器へのデータ処理分担切り替えに伴う稼動負荷変動予測値を含む、
   ことを特徴とする空調システムの制御方法。
   

Images