Quantum Sea

タグ: SONiC

  • MicrosoftとNexthop AIが示すSONiC BMC、液冷漏れの監視と停止

    MicrosoftとNexthop AIが示すSONiC BMC、液冷漏れの監視と停止

    液冷のネットワークスイッチでは、冷却液を流す仕組みに加えて、漏れたときに誰が気づき、どこを止めるかも設計する必要があります。通信を制御する主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による正常な終了処理と、代替手段としての電源停止です。下部には担当者によるラックの隔離・点検と、リンク切断後の通信切り替えも並んでいます。機器の停止だけで完結せず、人とネットワーク側の対応までつなぐ構成です。

    ラックマネージャーがRedfishでBMCへ漏れを通知し停止を要求する構成図。BMCは主CPUへgNOIによる終了処理を求め、代替として主系の電源を切る。Syslog通知を受けた担当者のラック隔離・点検と、リンク切断後の通信切り替えも示す。具体的なしきい値・待ち時間は記載されていない。
    図1　ラック側の漏れを検知したあとの通知と停止経路（原図引用）
    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の企業解説にまとめています。

    Microsoftの企業解説を読む

    BMC向け半導体を手がけるASPEEDの事業は、cyclewaveの企業解説で紹介しています。

    ASPEEDの企業解説を読む

    参考資料

    ［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」。開催日、登壇者、公式公開資料の一覧。

  • MicrosoftとBroadcomが示すSONiCの混雑対策、経路制御と早い通知を組み合わせる

    MicrosoftとBroadcomが示すSONiCの混雑対策、経路制御と早い通知を組み合わせる

    GPUの計算が速くても、通信の一部が遅れると、AIの処理全体を終えるまでの時間が延びます。大きなデータが短時間に集中する場面では、回線の速さに加えて、どの経路を通り、混雑をどれほど早く知れるかが大切になります。

    2026年8月のOCP APAC SummitでMicrosoftとBroadcomが紹介したのは、ネットワークスイッチを動かすソフトウェアSONiCを、AI向けの大規模な通信基盤へ対応させる取り組みです。経路情報を扱うBGPの拡張から、送信元が経路を指定するSRv6、混雑を早く伝えるパケットトリミング、細かな統計収集までをつなげて見ていきます。［1・2］

    簡単にまとめると？

    • SONiCでは、AI通信に合わせて経路制御、混雑の通知、細かな観測を組み合わせます。
    • パケットトリミングは混雑時のパケットを短くし、再送と送信速度の調整へつなげます。
    • 発表された機能が使えるかは、ASICやNIC、ソフトウェアの実装によって異なります。

    少数の大きな通信が、同じ経路へ重なる

    発表が対象とするAIの学習通信には、少数の大きなフロー、短時間に通信が集中するバースト、遅い側の通信時間であるテールレイテンシーへの敏感さという特徴があります。経路の振り分けに使える通信の違いも少なく、大きなフローが同じリンクへ重なると、混雑しやすくなります。［2］

    等しいコストの経路へ通信を振り分けるECMPでも、このような条件では負荷がうまく分散しないと説明されています。経路が複数あることと、実際の通信が均等に流れることは別の問題です。資料の課題設定は、こうしたAI通信の性質を前提にしています。［2］

    接続が増えれば、BGPにも処理能力が要る

    資料では、1ポートあたり100Gbps、スイッチ全体で51.2Tbpsの構成を、複数のネットワーク面へ分けて導入したとしています。接続先が増えると、経路情報を交換するBGPの接続数も増えます。多数のポートを備えるハードウェアを用意すると同時に、それを制御するソフトウェアも拡張する必要があります。［2］

    そこで示されたのが、経路制御ソフトウェアFRRを10.0.1へ更新し、約20件のパッチを加えるSONiCの改善です。512のBGPセッション、約1,000の経路、次の転送先である512のネクストホップを扱う構成が紹介されています。単一ポートの切断・復帰に関する発表結果は、データ転送の停止が0.1秒未満、経路情報の収束が約5秒です。異なる二つの時間を、同じ「復旧時間」としてまとめないことが大切です。［2］

    SRv6で、送信元から通る経路を指定する

    通信の経路選択には、IPv6を使うセグメントルーティングのSRv6が挙げられています。資料の構成では、送信元のネットワークインターフェースカード（NIC）が、経路を表す短い識別子uSIDの列をパケットへ入れます。途中のスイッチが順に処理し、宛先のNICが受け取る仕組みです。［2］

    これにより、送信元が指定した経路をたどらせます。資料では、識別子の列が合わない場合はパケットを破棄する、厳密なソースルーティングを説明しています。経路を指定する仕組みそのものが混雑を自動で解決するわけではなく、どの経路を選ぶかと、途中で起きた混雑へどう応えるかを組み合わせる設計です。［2］

    パケットを短くして、混雑の知らせを先へ送る

    パケットトリミングは、混雑時に対象のパケットを短くし、宛先へ送る仕組みです。受信側のNICは、正常に受け取れなかったことを伝えるNACKを送信元へ返します。送信元は、その知らせを受けてパケットを再送し、送る速度を落とします。大きなデータを運び続ける代わりに、小さくしたパケットを早い通知につなげます。［2］

    資料の図では、通信の種類やヘッダー、サイズでトリミングの対象を選び、通常のデータ用とは別に、優先度の高い待ち行列と専用バッファーへ入れています。多数の送信元から一か所へ通信が集中するインキャストに対応するため、短くしたパケットをためる領域の容量も検討項目です。［2］

    発表では、優先度ごとに通信を一時停止するPFCや、パケットに混雑を知らせる印を付けるECNだけでは、このバースト性の高い通信に十分すばやく対応しにくいと説明しています。特にPFCの停止が周囲へ広がると、処理完了までの時間が延びる点を挙げています。PFCやECNがあらゆるネットワークで使えないという意味ではなく、ここで想定する通信に、より早いフィードバックを求める議論です。［2］

    ミリ秒単位の観測を、運用のデータへつなぐ

    短い混雑を調べるには、観測の間隔も細かくする必要があります。そこで紹介された高頻度ストリーミングテレメトリー（HFST）は、スイッチの統計をミリ秒単位で収集するための仕組みです。ASICがIPFIX形式で計測情報を送り、SONiC側のCounter Syncdが受け取って読み解きます。［2］

    受信した情報は、登録済みのIPFIXテンプレートに従って解析します。対応するテンプレートがなければ、そのメッセージは破棄されます。得られたカウンターは手元のデータベースへ保存でき、OpenTelemetry形式へ変換して収集・処理の仕組みへ渡すこともできます。細かく測るだけでなく、正しく解釈して保存するところまでを一つの経路として考えています。［2］

    実装の報告と、次に取り組む範囲を分けて読む

    発表は、BGPの拡張結果と、SRv6・トリミング・テレメトリーの設計を並べて紹介しています。設計資料へのリンクもありますが、これだけで、すべてのSONiC製品や導入先に同じ機能がそろっているとは判断できません。利用するASICやNIC、ソフトウェアの実装を合わせて見る必要があります。［2］

    今後の取り組みとしては、アクセラレーター同士を密に結ぶスケールアップ向けEthernetも挙げられています。今回の大規模なスケールアウト網を支える改善と、その先の検討範囲は分けて捉えたいところです。経路を制御し、混雑を早く伝え、その状態を細かく観測する。SONiCの役割は、この三つをハードウェアと運用の間でつなぐことにあります。［2］

    MicrosoftとBroadcomについて

    発表に登壇したMicrosoftとBroadcomの事業全体は、cyclewaveの企業解説で紹介しています。

    cyclewaveでMicrosoftの企業解説を読む
    cyclewaveでBroadcomの企業解説を読む

    参考資料

    2026年8月の発表資料をもとに構成。性能値と課題は、資料で示された構成・通信条件に関する説明です。

    1. Open Compute Project「2026 OCP APAC Summit」 — 公式イベント・発表資料一覧。
    2. Microsoft・Broadcom「How SONiC Powers the World’s Largest AI Infrastructure」 — Guohan Lu、Mehak Mahajan。pp.4〜11：AI通信、BGP、SRv6、パケットトリミング、HFST。pp.12〜14：設計資料と今後の取り組み。
  • GoogleとBroadcomのSONiC仮想検証、実機が届く前に不具合を探す

    GoogleとBroadcomのSONiC仮想検証、実機が届く前に不具合を探す

    新しいネットワークスイッチを使うには、チップだけでなく、それを動かすソフトウェアも準備する必要があります。ところが実機が届くまで検証を始められないと、不具合の発見も後ろへずれてしまいます。

    この待ち時間を減らすために、GoogleとBroadcomが紹介したのが、Alpine Virtual Switch（AVS）とTH6向けBCMSIMを組み合わせる検証環境です。ネットワークOSのSONiCと、スイッチチップの動作モデルをつなぎ、実機の到着前からソフトウェアの組み合わせを確かめます。講演では、Googleが最初のTH6実機サンプルを受け取る前に、約40件の異なる問題を特定して解決したと報告しています。［1］

    簡単にまとめると？

    • AVSとTH6 BCMSIMをつなぎ、実機が届く前からSONiCとスイッチのソフトウェアを検証します。
    • 動作モデルの細かさと設定を検証目的に合わせ、ソフトウェア間の不整合を早く見つける設計です。
    • 仮想環境での検証は、実機の発熱・電力・信号品質まで再現した証拠ではありません。

    実機の数に、検証の数を縛られないようにする

    講演が挙げる課題は、スイッチが高価で、開発者と自動テストが同じ試験設備を共有しやすいことです。接続できる台数が限られれば、大きなネットワーク構成も試しにくくなります。新しいチップでは、そもそも実機がまだ用意できない段階から、ソフトウェアの開発が進みます。［1］

    AVSは、SONiCのソフトウェア群をコンテナ化し、パケットを転送するデータプレーンの実装を差し替えられる仮想スイッチです。複数のAVSをつなぐ際には、Kubernetes上でネットワークを再現するKNE（Kubernetes Network Emulation）を使う「Aktive」が配置を受け持ちます。1台の動作と、複数台を結んだ構成を、段階を分けて検証できる形です。［1］

    何を再現するかで、モデルを選ぶ

    仮想スイッチといっても、実機のどこまでをソフトウェアで表すかは同じではありません。資料は、AVSに組み合わせる選択肢を三つの層に分けています。［1］

    • VPPは、高速なソフトウェアのパケット処理エンジンです。チップや、その制御用SDKのモデルは持ちません。
    • Luciusは、SAI（Switch Abstraction Interface）の層でスイッチの動作を表します。SAIは、SONiC側からスイッチを制御するための共通インターフェースで、LuciusはSONiCの機能を素早く確かめる用途に位置づけられています。
    • BCMSIMは、チップ内部の制御情報を読み書きするレジスターの動作まで扱うデバイスモデルです。その上で、実機向けのBroadcom SDKとSAIを動かします。

    SDKは、ソフトウェアからチップを扱うためのライブラリーなどをまとめたものです。BCMSIMを使うと、SONiCの機能だけでなく、SAI、SDK、チップの動作モデルへと続く組み合わせを確認できます。検証したい層に応じて、処理の速さや規模と、モデルが扱う詳細さを選ぶ考え方です。資料には、この三方式を同じ条件で測った性能比較は示されていません。［1］

    仮想ポートをつなぎ、実機と設定をそろえる

    今回の構成では、TH6の動作モデルと仮想ネットワークインターフェースの間に「BCMSIM vBridge」を置きます。モデル側と外側で使うメッセージを橋渡しし、パケットの送受信や、リンクが切れて戻る変化をやり取りします。CPU向けのパケットには別の仲介層があり、ポートごとの統計も観測します。［1］

    もう一つ大切なのが、AVSと実機側の設定をそろえることです。資料では、SONiCのconfig_db.jsonやBroadcomのbcmsim-config.ymlを例に挙げています。同じ問題を仮想環境で追いたくても、設定が違えば、動作の違いがどこから来たのか切り分けにくくなります。モデルを用意するだけでなく、再現に必要な条件を合わせるところまでが検証環境の設計です。［1］

    約40件の問題を、最初の実機より前に解決

    講演で報告された約40件は、SAI・SDKとネットワークOSの設定に関する問題です。Googleが最初のTH6実機サンプルを受け取る前に特定・解決した件数であり、チップの物理的な欠陥を40件見つけた、という意味ではありません。［1］

    こうした検証は、コードを取り込む前の自動テストにも組み込めます。資料では、クラウド上で数時間ごと、または重要度に応じて毎晩、AVSとTH6 BCMSIMを使う自動処理を走らせる取り組みを説明しています。変更のたびに実機の順番を待たず、ソフトウェアの不整合を早めに見つける狙いです。［1］

    GoogleのAVS環境をBroadcom側の仮想マシンで立ち上げる試みも、単発の実験として報告されています。同じ環境を共有し続けられれば、問題を説明し直す往復を減らせる可能性があります。ただし、継続運用による短縮効果は、今回の資料では測定結果として示されていません。［1］

    仮想環境で前倒しできる範囲を、はっきりさせる

    BCMSIMは、資料ではASICの「デジタルツイン」と呼ばれています。ここで示されているのは、チップの動作モデルを使い、設計からSDK、SAI、SONiCへと検証をつなぐ仕組みです。実機の発熱、電力、信号品質、実効的な転送性能まで、すべて同じように再現できることを示すものではありません。［1］

    検証のうち、実機を待たずに進められる部分を増やす。実機が届いたら、物理環境でしか確かめられない部分に向き合う。AVSとBCMSIMの組み合わせは、その順序を組み直し、ソフトウェアの問題を早い段階で減らしておくための取り組みです。

    発表に登場する企業を知る

    Broadcomの半導体・基盤ソフト事業と、Googleの親会社Alphabetの事業全体は、cyclewaveの企業解説にまとめています。

    Broadcomの企業解説を読む
    Alphabetの企業解説を読む

    参考資料

    ［1］Google・Broadcom「Accelerate fabric validation with Alpine VS and BCMSIM」。2026 OCP APAC Summitの公開スライド。3–5ページ：検証設備の課題とAVS・Aktive、7–11ページ：モデルの層と接続・設定、12–14ページ：適用例と報告結果。公式一覧では「Accelerate cloud scale validation with AVS and TH6 BCMSIM」として掲載。

    ［2］Open Compute Project「2026 OCP APAC Summit」。開催日・登壇者・公開資料の案内。記事は公開スライドをもとに構成しています。