ハードウェア上級 #6 データセンターの冷却とラック — 電気は結局熱になる

ハードウェア上級 #5 でデータセンターの電力の流れをたどり、ひとつの事実に行き着きました。サーバーに入った電力はほぼすべて熱になって出ていきます。1kW を消費するサーバーは 1kW の電気ヒーターでもあります。だから冷却は電力の鏡です。電力設計が同じエネルギーをどう入れるかの問題なら、冷却設計はそのエネルギーをどう抜き出すかの問題で、両者の容量は結局同じ数字でなければなりません。今回はサーバー 1 台の気流から出発し、ラック、アイル (通路) の設計、液体冷却、温度の運用基準まで、熱が抜けていく道をたどっていきます。

サーバー冷却の基本 — 前から吸って後ろへ吐く #

ラックマウントサーバーの気流は一方向です。前面から冷たい空気を吸い込み、CPU とメモリのヒートシンクを通過させたあと、背面から熱い空気を吐き出します。前面吸気・背面排気です。単純に見えますが、この約束がデータセンター冷却全体の出発点です。すべての機器が同じ方向に風を流すという前提があって初めて、後で出てくるアイル設計が成立するからです。

サーバールームに初めて入った人が驚くのは騒音です。1U サーバーがとりわけうるさいのには物理的な理由があります。高さ 44mm に収まるファンは直径 40mm 程度の小型のものだけで、小さなファンで密集したヒートシンクを突き抜ける静圧を作るには 1 万 RPM を超える回転数が必要です。デスクトップの 120mm ファンが 1,500RPM 前後で回るのと比べると、1U サーバーの轟音は故障ではなく設計の結果です。ファンが消費する電力も無視できず、高密度サーバーでは全消費電力の 10% 前後がファンの取り分という場合もあります。

ホットアイルとコールドアイル — 混ざると効率が崩れる #

サーバーが一方向に風を流すなら、ラックの配置で冷気と熱気を分離できます。ラックの列を互いに向かい合わせて立てる方式です。前面同士が向かい合う通路には冷気だけが供給され (コールドアイル)、背面同士が向かい合う通路には熱い排気だけが集まります (ホットアイル)。

 ホットアイル(排気)   コールドアイル(吸気)   ホットアイル(排気)
   ↑↑↑↑               ↓↓↓↓               ↑↑↑↑
 [ラック背面]        [ラック前面]        [ラック背面]
 [ラック ←熱]      [熱→ ラック ←熱]      [熱→ ラック]

この分離が崩れるパターンは 2 つです。

• 再循環 — ホットアイルの熱い排気がラックの上や横を回り込んでコールドアイルへ流れ込み、サーバーが熱い空気を再び吸ってしまうケースです。吸気温度が上がり、機器の過熱に直結します。
• バイパス — コールドアイルの冷気がサーバーを通過せず、そのままホットアイルへ抜けてしまうケースです。機器は安全ですが、冷房エネルギーを空中に捨てているようなものです。

この 2 つを物理的に遮断するのがコンテインメントです。通路の端に扉を付け、上を天井パネルで覆い、コールドアイルかホットアイルの片方を完全に密閉された部屋にします。冷気側を閉じ込めればコールドアイルコンテインメント、熱気側を閉じ込めればホットアイルコンテインメントです。どちらでも核心は同じです。冷気と熱気がサーバーの内部以外では出会う道がないようにすることです。

気流のディテール — ブランクパネルとケーブル #

コンテインメントまでやったのに特定のサーバーだけ熱いなら、犯人はたいてい小さな隙間です。

• 空き U スロット — ラックに機器がまばらに収まっていると、空いた段がホットアイルからコールドアイルへ通じる穴になります。背面側の熱い空気が空きスロットから逆流し、すぐ上のサーバーの吸気に入り込みます。空きスロットを塞ぐブランクパネルは数百円程度のプラスチック板ですが、ラック内の再循環を断つもっとも安い部品です。
• 背面のケーブルの束 — 整理されていないケーブルの束がサーバー背面を覆うと、排気が塞がれて内部温度が上がり、ファンはさらに速く回って電力をさらに使います。
• 床タイルの位置 — 床下空調 (二重床) 方式なら、冷気は有孔タイルから上がってきます。有孔タイルがコールドアイル以外の場所に敷かれていると、その分がすべてバイパスです。

冷却問題のかなりの部分は、冷凍機の容量ではなくこうした気流のディテールから生まれます。供給する冷気の総量は足りているのに、肝心のサーバーの前まで届かないケースです。

ラック密度 — 空冷の限界線 #

ラック 1 本が消費する電力、つまり kW/rack が冷却方式を決めます。空気は熱容量の小さな媒体なので、密度が上がるほど同じ熱を抜くのに必要な風量が急激に増えます。

この表を試験台に載せたのが AI サーバーです。GPU を 8 枚積んだサーバー 1 台が 10kW 前後を消費するため、数台積むだけでラックが空冷の限界領域に入ります。GB200 NVL72 のようにラック 1 本が 100kW を超える構成は、最初から液体冷却を前提に設計されます。液体冷却が新しい技術だからではなく、密度が空気という媒体の物理的限界を超えたからです。

液体冷却 — D2C と液浸 #

水は同じ体積の空気より数千倍多くの熱を運びます。この差を使う方式は大きく 2 つに分かれます。

• D2C (ダイレクト・トゥ・チップ) — CPU と GPU の上にヒートシンクの代わりにコールドプレートを載せ、その中に冷却水を流します。ラックや列の単位に設置された CDU (冷却水分配装置) が循環と熱交換を受け持ちます。チップが出す熱の 70〜80% を液体が持っていき、メモリや電源部など残りは引き続き空気が受け持つハイブリッド構造です。既存のフロアに段階的に導入できるため、現在の AI インフラの主流です。
• 液浸冷却 — サーバー全体を電気を通さない冷却油に浸します。ファンが完全になくなり、すべての発熱部品が液体に直接触れるため、熱回収率がもっとも高い方式です。ただし専用のタンクとメンテナンス手順が必要で、サーバーを取り出す作業からして従来の運用とは別物になります。

運用者の観点では、液体冷却は配管、漏水検知、冷却水の水質管理という新しい運用項目をデータセンターに持ち込むことでもあります。空冷の時代にはなかった障害シナリオが生まれる分、導入は密度が強制するときに必要な範囲で行われるのが普通です。

温度基準 — 冷やすほど良いわけではない #

サーバールームは冷たいほど安全だと考えがちですが、現代のデータセンターの運用基準は逆方向に動いてきました。ASHRAE の推奨範囲はサーバー吸気基準で 18〜27°C です。20 年前の冷蔵庫のようなサーバールームよりはるかに高い温度です。

理由は第 5 編で見た PUE にあります。吸気温度の基準を 1 度上げると冷凍機が働くべき時間が減り、外気が十分に冷たい日には冷凍機なしで外の空気で冷やすフリークーリング運転が可能になります。冷却に使う電力が減れば、同じ IT 負荷で PUE が下がります。必要以上に冷たく冷やすのは安全マージンではなく電気料金です。

もちろんタダではありません。吸気温度を上げるほど、冷却障害が起きたときに機器が限界温度に達するまでの猶予時間が短くなります。基準温度は結局、冷却電力と障害時に持ちこたえる時間のあいだのトレードオフで、ASHRAE の推奨範囲はそのバランス点として業界が合意した区間です。

ラックとフロア — 重量、動線、手が入るスペース #

最後はラックそのものの設計ディテールです。標準 19 インチ、42U ラックという規格は同じでも、その中を何で埋めるかによってフロア設計が変わります。

• 重量荷重 — サーバーをぎっしり詰めた 42U ラックは 1 トン近く、あるいはそれ以上になります。二重床の単位面積あたりの設計荷重を超えるとラックを埋められないため、高密度ラックは配置の前に床荷重の検討が先です。液体冷却ラックは冷却水とマニホールドの重さが加わってさらに重くなります。
• ケーブルの動線 — 電力ケーブルとネットワークケーブルは経路を分離し、サーバーをレールで引き出すときに切れないように余裕の長さ (サービスループ) を持たせます。排気を塞がない整理がそのまま冷却性能です。
• メンテナンススペース — サーバーは前面のレールで引き出すため、ラックの前には機器の奥行き分の通路が必要です。背面にもケーブルと PDU の作業のためのスペースが必要です。通路の幅は無駄ではなく、障害時の復旧速度を決める設計要素です。

まとめ #

今回つかんだ絵です。

• サーバーに入った電力はほぼすべて熱になるため、冷却容量は電力容量の鏡です。出発点は前面吸気・背面排気という気流の約束です。
• ホットアイル・コールドアイルの分離とコンテインメントの目的はひとつです。冷気と熱気がサーバー内部以外では出会えないようにすることです。ブランクパネルやケーブル整理といったディテールがその分離を完成させます。
• ラック密度が上がると空冷は限界にぶつかり、AI サーバーの密度は D2C と液浸という液体冷却への転換を強制しています。
• 温度基準は冷たいほど良いのではなく、冷却電力 (PUE) と障害時の猶予時間のトレードオフで、ASHRAE の推奨範囲 18〜27°C がその合意点です。
• 重量荷重、ケーブルの動線、メンテナンススペースといったラック・フロアのディテールまでが冷却設計の一部です。

次回 — ファームウェア・BMC とライフサイクル #

次の記事「ハードウェア上級 #7 ファームウェア・BMC とライフサイクル」はシリーズの最終編です。OS の下でサーバーを守るもう 1 台のコンピュータである BMC、IPMI と Redfish による遠隔管理、ファームウェア更新の運用手順、そして導入から廃棄までサーバー 1 台のライフサイクルを整理して、シリーズを締めくくります。