液冷のネットワークスイッチでは、冷却液を流す仕組みに加えて、漏れたときに誰が気づき、どこを止めるかも設計する必要があります。通信を制御する主CPUを停止したあとも、監視や遠隔操作の経路を残せるかが大切になります。
2026年8月のOCP APAC SummitでGuohan Lu氏（Microsoft）とRyan Torres氏（Nexthop AI）が紹介したのは、機器の状態監視と遠隔管理を担うBMC（Baseboard Management Controller）でSONiCを動かす構成です。液漏れの程度や検知した場所に応じて、通知、主系の電源停止、ラック側との連携を分けています。［1］
簡単にまとめると？
- SONiC BMCは主CPUと監視・管理を分け、主系を止めた後も液漏れへの対応経路を残す設計です。
- 漏れの重大度や場所に応じて、通知、主系の停止、ラック側や担当者との連携を使い分けます。
- 発表は対応構成と展開計画を示すもので、停止のしきい値や全機種への対応、無停止運用を保証していません。
主CPUを止めても、監視する側を残す
BMCは、主CPUとは別の管理用プロセッサーです。資料では、主CPUの動作状態によらずBMCを動かし、液漏れセンサーを監視する設計が示されています。ここでいう常時監視は、主系と監視系の動作を分ける考え方であり、機器への給電が失われても動き続けるという意味ではありません。［1］
スイッチ側の要件には、BMCから主系の電源を入れ直せること、BMC自身の再起動が主CPU側へ影響しないこと、管理ポートをBMCへ接続することが挙げられています。BMCと主CPUの間には、USBを使ったEthernetの管理通信経路を設けます。通信を転送する回路と、それを外側から管理する回路を分ける構成です。［1］
軽微な漏れと重大な漏れで、対応を分ける
漏れを検知したら、すべて同じ動作にするわけではありません。資料は、異なる重大度のセンサーを複数備えることに加え、センサー自身が正常かを確認すること、検知後の対応方針を決めることを要件にしています。［1］
スイッチ内の軽微な漏れの例では、BMCがSyslogというログ通知を送り、担当者が機器を点検します。この図には、主系の自動停止は示されていません。一方、重大な漏れの例では、通知とともにスイッチの主系を電源停止し、担当者が隔離と点検に向かう流れです。［1］
重大な漏れの図には、リンク切断を検知したあとに通信を別経路へ移す動作も描かれています。ただし、これは発表が示す対応の構成例です。通信の切り替え時間や、切り替え先の容量、無停止で運用できることを実証した数値は示されていません。［1］
ラック側の異常も、同じ管理経路へつなぐ
漏れがスイッチ内ではなく、ラック側で見つかる場合もあります。資料の構成では、ラック全体を管理するラックマネージャーとBMCが、機器管理用の標準インターフェースRedfishで連携します。ラック側の異常を、スイッチを止める判断へつなげるためです。［1］
ラック側の液漏れの例では、ラックマネージャーからBMCへ通知と停止要求が送られます。BMCは、運用操作を伝えるgNOIを使って主系へ正常な終了処理を求め、代替手段として主系の電源停止も備えます。同時に担当者へ知らせ、ラックの隔離と点検につなげます。［1］
図1では、左側のラックマネージャーから中央のBMCへ、漏れの通知と停止要求が送られています。BMCから右側の主CPUへ向かう赤い経路は、gNOIによる正常な終了処理と、代替手段としての電源停止です。下部には担当者によるラックの隔離・点検と、リンク切断後の通信切り替えも並んでいます。機器の停止だけで完結せず、人とネットワーク側の対応までつなぐ構成です。
Guohan Lu（Microsoft）、Ryan Torres（Nexthop AI）「SONiC BMC for Liquid-Cooled Switches」、2026年8月、p.20。講演資料［1］。
図は横にスクロールできます。図の画像を開く
この設計でそろえようとしているのは、センサーの検知から、人への通知、機器の停止までの受け渡しです。軽微と重大を分ける具体的なしきい値や、終了処理をどれだけ待つかは、今回のスライドには示されていません。図の流れと、個々の設備で決める運用条件を分けて読む必要があります。
BMCでもSONiCを使う理由
SONiCはネットワークスイッチ向けのOSです。BMC側でも同じソフトウェア基盤を使う狙いは、コンテナの管理、ソフトウェア更新、脆弱性への対応といった運用方法をそろえることにあります。ただし、主系とまったく同じ機能をBMCへ載せるわけではありません。［1］
BMC側では、データベースや監視情報を扱う機能の一部を動かし、パケット転送用ASICを制御するsyncdやswssは動かしません。機器を監視するpmonコンテナには、液漏れやラックマネージャーの指示に応じて電源を制御するbmcctldを追加し、Redfish用のコンテナも設けます。BMCが引き受けるのは、通信を転送する主系を管理する役割です。［1］
初期対応と、これからの機種展開を分ける
資料が示すBMCのハードウェア要件は、ARM64、4GBのDDR5メモリー、8GB以上のeMMCストレージ、セキュアブートなどです。ソフトウェアの使用量としては、イメージ750MB、ディスク1.5GB、メモリー1GB未満が記載されています。後者は紹介された構成の使用量であり、搭載メモリーの要件を1GB未満へ置き換えるものではありません。［1］
初期実装の範囲も具体的です。ロードマップの「202605」には、BMC向けチップであるAST2720のA1／A2対応と、sonic-aspeed-arm64.binという専用イメージ、Redfishが挙げられています。一方、空冷・液冷の最初のプラットフォーム対応は「202611」の項目です。これは2026年8月の発表時点の計画で、あらゆるBMCや液冷スイッチがすでに対応しているという説明ではありません。［1］
液冷を運用へ入れるには、冷やす能力とともに、異常を見つけたあとに動く仕組みが必要です。SONiC BMCの取り組みは、主系から分けた監視と管理を土台に、漏れの重大度や場所に応じた対応を組み立てるものです。対応機種と運用条件を確かめながら、設備側とネットワーク側の管理をつなぐ設計として見ることができます。
共同発表者が所属するMicrosoftの事業全体は、cyclewaveの企業解説にまとめています。
BMC向け半導体を手がけるASPEEDの事業は、cyclewaveの企業解説で紹介しています。
参考資料
［1］Guohan Lu（Microsoft）、Ryan Torres（Nexthop AI）「SONiC BMC for Liquid-Cooled Switches」。2026年8月の公開スライド、全25ページ。7–14ページ：BMCの要件とSONiCの構成、15–20ページ：軽微・重大・ラック側の液漏れへの対応例、21–22ページ：使用量とロードマップ。本文は公開スライドに基づき、録画は未視聴です。
［2］Open Compute Project「2026 OCP APAC Summit」。開催日、登壇者、公式公開資料の一覧。