ラック搭載の設計 — 電源・冷却・配線をどこまで先に決めるか

ラック設計の失敗の多くは、機材が現地に届いた後に初めて表面化する。搭載できない寸法、容量が足りない電源回路、考慮されていない発熱——これらは設計フェーズで判断を先送りにした結果であり、着手前に「固定すべき項目」と「現地で決められる項目」を明確に区別することが、構築プロジェクトを止めないための核心だ。本記事では、ラック搭載設計において何をいつ決めるかを構造的に整理し、落とし穴を先に押さえた上で実践的な判断軸を解説する。

機材が届いてからラックに収まらず作業が止まる構造

「とりあえず発注」が生む連鎖停止

機材の発注とラック搭載設計を並行で進めた結果、機材が届いた段階で搭載できないことが判明する——そういう事態は珍しくない。ある構築担当者が経験した案件では、42Uラック2本を満載で構成した後に追加されたストレージ装置のレールキットが既設サーバーの背面と干渉し、3台分の再配置を余儀なくされた。この再配置だけで2人日以上の工数が失われた。発注タイミングと設計確定タイミングのズレが、現場での連鎖停止を生む典型的な構造だ。

寸法・電源・冷却の依存関係が見落とされる理由

ラック設計に関わる項目は「寸法(U数・奥行き・重量)」「電源(容量・回路数・差込口の位置)」「冷却(気流方向・発熱量・ラック間隔)」の三軸が互いに依存している。機器の奥行きが深いと背面のケーブリングスペースが圧迫され、ケーブルが密集すると気流が乱れる。電源容量の不足はPDUの増設を招き、増設によって配線が増え、また気流に影響する。この連鎖を把握せずに各項目を個別に手配すると、現場での辻褄合わせが避けられなくなる。

設計判断の先送りが後工程に転嫁される仕組み

設計段階で見落とした1項目が、現場では複数の後続作業を止める。たとえばサーバーの搭載位置が未確定のまま配線作業を始めると、機器の追加・変更のたびにケーブルルートを引き直すことになる。工数が失われるだけでなく、「なぜそこに刺さっているのか」という記録も失われ、後の担当者が構成を追えなくなる。設計判断の先送りは技術的負債として後工程に蓄積され、運用フェーズに入った後で発覚するケースも多い。

着手前に確定させる寸法・電源と現地調整でよい項目の判断

着手前に固定すべき項目の確定基準

着手前に必ず固定しなければならない項目は、変更コストが非常に高いものに限定される。具体的には「ラックの総U数と機器のU占有計画」「電源回路の系統数と各系統の最大容量(A数)」「フロント/リア冷却か、ホットアイル/コールドアイル構成かという気流設計の方向性」が該当する。これらは後から変えようとすると機器の移設や電気工事が必要になる。一方で「ケーブル長の細部」「ラベルの印字書式」は現地でも決められる項目だ。

現地で調整してよい項目とその判断軸

現地調整を許容できる項目は「変更が1人・1時間以内に完了できるか」を基準に判断するとわかりやすい。パッチケーブルの色分け、ケーブルタイの位置、補助的なPDUの取り付け向きなどは現地で微調整しても工程全体には影響しない。逆に「別の業者が先行完了している工事に依存する項目」は後回しにできない。電気工事業者が手がける幹線工事の系統区分は、その完了前にラック設計側で仮確定しておく必要がある。

設計フェーズで「決めない」という判断をどこで使うか

すべての項目を事前確定しようとすると、現地の実態と乖離したまま設計が固まる弊害もある。床荷重の実測値、搬入動線の実寸、空調の吹き出し口位置は、現場確認後に決めた方が精度が高い。「着手前に仮決めしつつ、現地確認後に正式確定」というフェーズを設計工程に明示的に組み込むことで、後からの覆しを最小化できる。重要なのは「まだ決まっていない」という状態を設計ドキュメントに記録し、確定のトリガーと担当者名を明示しておくことだ。

設置場所の選択肢別:設計判断の裁量と制約を比較する

自社サーバールーム・データセンター貸しラック・ハウジング一括のいずれを選ぶかによって、ラック設計で自分たちが判断できる範囲が大きく変わる。どこに裁量があり、どこが外部制約になるかを把握した上で設計に入ることが重要だ。

判断項目 自社サーバールーム データセンター貸しラック ハウジング一括
ラック選定・配置 完全自由(自社調達) DC指定ラックを使用、配置はDCと協議 DC側が提案・管理
電源系統・容量 電気工事を自社で発注・設計 系統数・A数はDCとの契約で上限が決まる ハウジング仕様に従う
冷却・空調 自社で空調機器を導入・制御 DC共用空調に依存。列内冷却追加は要交渉 DC側が管理。高密度は別途要件定義が必要
配線・ケーブル管理 自社ルールで設計可能 DC側の配線規則(ケーブルトレイ等)に従う DC管理。変更のたびに手続きが発生
将来拡張の自由度 高い(スペース次第) ラック数・電力の追加は契約変更が必要 低い。事前の要件定義の精度が鍵
設計判断のリードタイム 工事発注まで自社判断で可 DC側の承認・調整が入る工程がある 提案〜仕様合意に数週間必要なことが多い

ハウジングを選択する場合、DC側との仕様合意が設計の起点になるため、自社側の設計着手前に電源・冷却の要件をまとめた要件定義書をDC側に渡す工程を早めに組み込む必要がある。

電源系統の冗長と容量をどう見積もるか

回路冗長の設計パターンと選択基準

電源系統の冗長設計は「A系統+B系統の2系統給電」が基本だが、すべての機器に冗長電源ユニットが搭載されているとは限らない。サーバーは多くの場合2電源ユニットを持つが、スイッチや古いストレージは1電源のケースがある。1電源機器は切り替えSTS(Static Transfer Switch)や二重化PDUで補う構成になるが、STSを採用すると設置スペースと発熱が増す。どこまで冗長化するかは、機器の停止許容時間(RTO)と照らした設計判断であり、「全台冗長」を無条件の前提にしない方が実態に即している。

容量見積もりに「定格」ではなく「運用値」を使う理由

電源容量の見積もりで陥りやすい誤りは、各機器の定格最大電力を単純に合算することだ。20台のサーバーが定格1,000Wであっても常時フル稼働することはなく、実際の運用値は定格の40〜70%程度に収まることが多い。設計では定格合計を上限として使いつつ、回路の常用容量を「回路定格の80%まで」に抑えるのが安全基準の目安だ。20A回路であれば16Aまでを常用範囲とし、PDUのアンペアモニタリングで運用中に継続確認する体制をセットで設計する。

PDUの選定と系統割り当ての判断

PDUの選定では「差込口の数」「モニタリング機能の有無」「縦置き/横置きの向き」が主な判断軸になる。モニタリング機能なしのシンプルなPDUはコストが低いが、回路の消費電力を個別に追えないため容量超過の兆候を事前に検知できない。ラックあたりのサーバー台数が10台を超える環境では、アウトレット個別のモニタリングができるスマートPDUが現実的な選択肢になる。A系・B系への接続先割り当ては、同一機器の2電源が同じ系統に偏らないよう、搭載前に一覧表で確認する工程を設ける。

配線・ラベル・搭載位置を後から追える形にする決め方

ラベル体系を設計フェーズで決める理由

ラベルの書式を現場作業中に各担当者が個別に決めると、「SW-01-P01」「Core-SW_Port1」「スイッチ1番ポート」が混在した状態になる。後から別の担当者が作業する際、これらが同一ポートを指しているかを追うだけで時間が消える。ラベル体系(機器種別コード・ラック番号・Uポジション・接続先)は設計フェーズで統一書式を決め、関係する全担当者に共有した上で作業を開始する。書式の決定自体は30分程度あれば終わる作業だが、後回しにされやすい筆頭項目でもある。

ケーブルルートと収容位置の記録形式

配線の記録は「何が刺さっているか」ではなく「なぜそのルートで刺さっているか」まで残せる形式にする。ケーブルの長さを0.5m・1m・2mの3種類に絞って統一すると、後から長さを見るだけでおおよそのルートが推測できる。ラックの搭載位置は「ラック図(ラックレイアウト図)」として作成し、変更のたびにバージョン管理する。作業指示書とラック図が常に同期している状態を維持することが、後任者への引き継ぎコストを下げる最も直接的な手段だ。

変更が入ったときに追える構造にする

構築後に機器の追加・入れ替えが発生したとき、設計ドキュメントが更新されないまま実態だけが変わっていくパターンが最も追跡コストを上げる。このドキュメント乖離を防ぐには、変更作業のフローの中にドキュメント更新を必須ステップとして組み込む設計が必要だ。変更チケットにラック図の更新を含める、あるいは構成管理ツールで物理構成を管理するか——どちらを選ぶかは規模次第だが、「作業完了≠ドキュメント更新完了」という分離を許容しない運用ルールを設計時点で決めておくことが重要だ。

詰め込みすぎて発熱と保守性が破綻する境界

搭載密度と廃熱の実際のトレードオフ

42Uラックに高密度なブレードサーバーやGPUサーバーを30U以上詰め込むと、1ラックあたり20kW以上の発熱が発生するケースがある。一般的なデータセンターの空調設計は1ラックあたり5〜10kW程度を想定していることが多く、それを大幅に超える構成では局所的なホットスポットが生じる。高密度搭載を選択する際は空調の供給能力を事前に確認し、必要であれば列内冷却(インロウ冷却)や背面ドア型熱交換機の採用を設計に盛り込む判断が必要になる。

保守作業スペースの確保が設計に与える影響

サーバーのレール引き出し、ケーブルの抜き差し、電源ユニットの交換——これらの保守作業は、前後のスペースが確保されていなければ現場で行き詰まる。ラックとラックの間隔が600mm未満になると、大型サーバーのレールを引き出した際に対面のラックと干渉するケースがある。ラックの背面にはケーブルを束ねるスペースが必要で、それを考慮せずに機器を奥行きギリギリまで収めると、ケーブルが押し込まれてコネクタが傷む原因になる。

将来拡張を考慮した「意図的な空きU」の取り方

ラックを100%使い切る設計は「今の最適」であっても、6か月後に機器を1台追加するだけで作業が止まるリスクをはらむ。現場では「初期搭載はラック容量の70〜80%にとどめ、残り20〜30%を拡張余白とする」という経験則が共有されている。この余白を設計に組み込むには、どのUを空けるかを「意図的な空き」として設計図に明示する必要がある。明示しないと現地作業者が「余っているから詰める」と判断して余白が失われる。

ラック設計チェックリスト

以下は、設計フェーズ・現地確認・完了確認の3フェーズに分けたチェックリストだ。すべてを一度に確定しようとするのではなく、フェーズごとに順次固めることで設計精度と現場対応の両立を図る。

設計フェーズ(着手前)

  1. ラックのU数・奥行き・耐荷重を機器仕様と照合し、搭載可能かを確認した
  2. 電源回路の系統数とA数を設備担当または施設管理に確認し、設計に反映した
  3. 冷却方式(ホットアイル/コールドアイル等)を確定し、機器の気流方向と一致しているか確認した
  4. 初期搭載をラック容量の70〜80%以内に収め、拡張余白のUを設計図に明示した
  5. ラベル体系の統一書式を決め、関係担当者に共有した
  6. 1電源機器の有無を確認し、冗長化の要否を停止許容時間(RTO)と照らして判断した
  7. PDUのモニタリング機能の要否を搭載台数と運用体制から判断した

現地確認フェーズ

  1. 搬入経路(扉幅・廊下幅・エレベーター寸法)を実測し、機器搬入に支障がないことを確認した
  2. 床荷重の制限値を施設管理から取得し、ラック満載時の重量と照合した
  3. 空調の吹き出し口・吸い込み口の位置を確認し、ラック配置と気流設計に反映した
  4. 電源コンセント(PDU接続先)の系統をA/B別に現地で確認した
  5. ラック間隔が600mm以上確保されていることを確認した

完了確認(搭載後)

  1. ラック図を実際の搭載状態に合わせて更新し、バージョン管理した
  2. 全ケーブルにラベルを付け、配線記録(接続元・接続先・ケーブル長)を作成した
  3. PDUのA/B系統割り当てを一覧表で確認し、同一機器の2電源が同系統に集中していないことを確認した
  4. PDUのアンペアモニタリングを有効にし、常用容量が回路定格の80%未満であることを確認した
  5. 「意図的な空きU」が設計図通りに確保されていることを確認した
  6. 変更発生時のドキュメント更新ルールを担当者間で合意し、記録した

▶ 手を動かして本番まで到達する

手を動かして本番まで到達しませんか

ここまでの設計判断は、読めば腹に落ちます。ですが「自分の手で本番まで通しきる自信」は、それとは別の話になります。

設計判断を実装力に変える2日間ハンズオンです。

ラック搭載・電源設計の基礎を学ぶ入門Linuxハンズオンへ →

Linuxマスターセミナー