## 概要 さくらインターネット株式会社クラウド事業本部の黒澤潔裕氏によるJANOG57(大阪)登壇資料。マネージドHPCクラスタ「さくらONE」のネットワーク基盤において、アーキテクチャ(シャーシ型スイッチ vs Clos Topology)とネットワークOS(Arista EOS vs SONiC/Whitebox)という2軸でのマルチベンダー・マルチOS運用の実際を、選定理由・直面した課題・自動化による対処まで一気通貫で報告する。同発表者は2025年のSONiC Workshop Japan 2025([[@2025__SpeakerDeck__SONiCで構築・運用する生成AI向けパブリッククラウドネットワーク]])で「高火力」GPUクラウド基盤のSONiC構築・運用を報告しており、本資料はその知見をさくらONEの本番Clos環境でのアーキテクチャ選定にまで拡張した続編にあたる。 ## 主要メッセージ - **クラスタ規模に応じてシャーシとClosを使い分ける**(p.8): さくらONEはH100クラスタ(100サーバー、シャーシ+SONiC)、H200/B200クラスタ(50-60サーバー、シャーシ+Arista EOS)、最新B200クラスタ(約140サーバー、Clos Topology+Arista EOS)の3世代・異なるアーキテクチャ/OS組み合わせを並行運用する。72台以下はシャーシ、それ以上はClos Topologyという収容規模の閾値を設定した(p.14)。 - **GPU基盤のClos Topologyは一般的なClosの前提を満たさない**(p.16): 柔軟なスケーラビリティ(→余剰ポート確保が物理的・経済的に困難でスケールしない前提の設計を強いられる)、Control Plane分離による障害影響低減(→単一機器の瞬断でもRDMAはFailしRolling updateによるSLA維持は許されない)、N+1冗長によるコスト低減(→GPU/400G Switchは高価でN+0で使い切る必要がある)、Full bisectionのLossless構成(→スイッチ間トランシーバーとケーブルが倍増する)という4点で、一般的なClos Topologyの利点がGPU基盤では成立しにくいか反転する。それでもなお収容効率の向上が採用の最大の動機になったと結論づける。 - **ホワイトボックス(SONiC)は自由度の代償として実装力を要求する**(p.19): Arista EOSはOSSライブラリ公開・HW/SW一貫の安定性・手厚いサポートを備える一方、SONiCはGitHubでソースを読める・迅速なデリバリー・OSSを活用した実装という利点と引き換えに、運用コマンドが未熟という明確な弱点を持つ。さくらインターネットはこれをconfig差分チェック・LLDP neighbor整理・トランシーバー情報取得・ARP学習チェック・冪等性確保という5機能の内製実装(Linux/Python)で補った(p.20)。 - **config適用の冪等性はBefore/Afterで質的に変化した**(p.20): Beforeはshell scriptによるconfig commandとconfig replaceの併用で、新規コンフィグ投入のたびにContainer再生成が発生し冪等性0・通信断を招いていた。Afterは新規コンフィグをjsondiffで差分ファイル生成→Dry run(apply patch, frr-reloadによる構文チェック)→Applyの3段構成に切り替え、Container再生成なしに設定を反映できるようにした。 - **監視基盤もOSの選択によって前提から作り直しになる**(p.21): Arista EOSはCloudVisionによるZTP時Push登録・高精度監視(streamingLatency 170ms表示)を備えるのに対し、SONiCはAnsibleによるInventory管理を起点にGrafana+Prometheusを自分たちで組み上げる必要があり、Telemetryへの本格対応は残課題として明示されている。 - **スイッチ38台・約40,000行のconfigをAnsibleで自動生成**(p.25): サーバーインベントリ(NIC layout・Tenant assign)とスイッチパラメータ(Hostname・Model・OS Version・Uplink Interface)から、BGPのASN算出・Uplink neighbor設定・VRF/VNIの自動割当・全区間InterfaceのIP割り当てをAnsibleで行い、Spine/Leaf/Storage Edge計38台ぶんの約40,000行のconfigを生成する。全台セットアップは30分で完了する(p.24)。 - **GitHub Actions×containerlabによる5分CI**(p.26): PR作成→GitHub Action起動→Lint(GitHub Self Host Runner)→cEOS ContainerのDry-run&Apply(Validation・Apply test・Health check)→Approveという変更検証パイプラインを構築し、所要時間5分で構成変更を自動テストする。人手でこの規模のGPUクラスタを構築する場合との対比として、OS導入から正常性確認まで2週間を要したことも開示される(p.27)。 ## 視覚的に重要な図表 **p.9 最新クラスタの物理・論理構成** ![[_attachments/janog57-hpc-kurosawa/page-009.png]] Broadcom Tomahawk5(Arista 7060X6-64PE)によるSpine10台・Leaf20台のClos Topology。HGX B200×140サーバーをぶら下げ、Storage Edge8台・Storage Core2台と接続する。論理構成側ではVRFによる顧客A/B間の疎通遮断(×印)を明示する。 **p.15 Clos TopologyとChassis Switchの比較表** ![[_attachments/janog57-hpc-kurosawa/page-015.png]] 選択肢の多さ・収容台数(ClosはSpine追加で100台以上、Chassisはサーバー72台程度が上限)・管理対象・スペース効率・構成技術(Clos側はBGP, EVPN/VXLANの組み合わせが必要)・部品点数(Clos側は数百本単位のトランシーバーが必要)の6軸で対比する。 **p.16 一般的なClos TopologyとGPU基盤における現実の対比** ![[_attachments/janog57-hpc-kurosawa/page-016.png]] 柔軟なスケーラビリティ→スケールしない前提の設計、Control Plane分離→単一機器瞬断でもRDMA Fail、N+1冗長→N+0で使い切る必要、Full bisection→トランシーバー・ケーブル倍増という4点の反転を整理し、「それでもなお収容効率の向上が最大のモチベーションとなった」と結論づける。 **p.20 SONiC運用のための内製機能実装とconfig冪等性のBefore/After** ![[_attachments/janog57-hpc-kurosawa/page-020.png]] show|compare的な差分チェック・LLDP整理・トランシーバー情報取得・ARP学習チェック・冪等性確保の5機能一覧と、Before(config replace→Container再生成→冪等性0・通信断)からAfter(jsondiff→Dry run→Apply)への切り替えを対比する。 **p.25 最低限の情報からのConfig自動生成パイプライン** ![[_attachments/janog57-hpc-kurosawa/page-025.png]] Switch ParameterとServer inventoryをData sourceとし、BGP ASN算出・VRF/VNI自動割当・全区間IP割り当てをTransformで行い、スイッチ38台・約40,000行のconfigをOutputする一連の流れ。 **p.26 構成変更時のCIパイプライン** ![[_attachments/janog57-hpc-kurosawa/page-026.png]] PR→GitHub Action→Lint(Self Host Runner)→cEOS ContainerへのDry-run&Apply(containerlab)→Approveという6ステップで、所要時間5分の変更検証サイクルを構成する。 ## 概念・実体への接続 - [[Clos Network]] — GPU基盤特有の制約(N+0運用・Full bisectionによるケーブル倍増・rolling update不可)を、一般的なClos Networkの前提との対比で具体化する事例。 - [[べき等性]] — jsondiff→Dry run→Applyのconfig冪等性パイプラインを、SONiC Workshop Japan 2025の同一発表者による先行事例からさくらONEの本番Clos環境へ拡張する事例として補強する。 - [[オープンネットワーキング]] / [[SONiC]] — ホワイトボックス導入の「自由度の代償」を、監視基盤・運用コマンドの内製実装という具体的な運用コストとして裏付ける。 - [[SAKURAONE]] — 最新B200クラスタ(約140サーバー・約1100GPU・Clos Topology)のネットワーク詳細を提供する。 - [[黒澤潔裕]] — 発表者本人。 ## 口頭説明・補足 補助テキストとして[さくらのナレッジのレポート記事](https://knowledge.sakura.ad.jp/49945/)(2026-03-10公開、著者は同じく黒澤潔裕氏)を参照した。記事はスライド内容の要約であり、スライドで確認できない新規の数値・固有名は含まれていなかったため、本ページの主張はすべてスライド画像に遡及できる。 ## 限界・不確実点 - 音声・動画のtranscriptは取得していない(公式ページにアーカイブ配信の記載はあるが、URLは非公開)。質疑応答の内容は不明。 - p.32-33(Appendix区切り)・p.35(Aristaシャーシ構成の参照ページ、JANOG54資料へのポインタのみ)は本文が薄い区切りスライドのため図表として採録していない。 - 事前資料(`janog57-hpc-kurosawa-pre.pdf`、10ページ)は本文と重複するダイジェスト版と判断し、当日資料(36ページ)を主典拠として扱った。