SONiC ネットワーク OS とスイッチの分離

エグゼクティブサマリー

Microsoft は Azure 向けに SONiC を開発し、2016 年に Open Compute Project を通じて公開した。複数のハードウェアベンダーのスイッチで共通に使える Linux・コンテナ・データベース構成を生み出した。
Switch Abstraction Interface は、異なる ASIC をプログラミングするための共通語彙を SONiC に提供する。ただし、プラットフォームの機能、規模、エラー挙動、サポートは、依然としてベンダー実装とプロプライエタリな SDK に依存する。
Linux Foundation によるガバナンスは参加範囲を広げたが、Microsoft の影響力を取り除いたわけではない。技術的権限、プロジェクト資金、SAI の開発、本番サポートは、複数の機関と商業参加者の間で分担されたままである。
SONiC は、統一された適合性とセキュリティの所有権が完全に成熟する前に、シャーシシステム、エンタープライズスイッチング、AI ファブリックへと拡大している。その信頼性は、サポート対象リストの広さではなく、測定可能な挙動によって決まる。

経路は複数の引き継ぎを経てシリコンに到達する

SONiC では、BGP の経路はルーティングプロセスから直接スイッチのフォワーディングテーブルへ移動しない。FRRouting が更新を受け取り、ポリシーを適用して経路を選択する。Zebra は Forwarding Plane Manager インターフェイスを通じて転送状態を渡し、fpmsyncd がアプリケーションの意図を APPL_DB に書き込み、Switch State Service が必要なネイバー、ネクストホップ、インターフェイスを解決する。その後、リクエストは ASIC_DB を通じて直列化され、syncd が消費し、ベンダーの Switch Abstraction Interface 実装とプロプライエタリなソフトウェア開発キットによって変換され、最終的に ASIC にプログラムされる。

この連鎖が、SONiC の重要性と難しさの両方を説明している。それぞれの境界により、各コンポーネントは他のすべてのコンポーネントを直接知らなくても開発できる。ルーティングソフトウェアは共通のアプリケーションモデルに対して動作し、ハードウェアベンダーは標準のスイッチオブジェクトを自社のシリコンに必要な命令に変換する。同じ分離が、望ましい状態、報告された状態、実際の転送挙動が乖離する箇所も増やす。

従来のネットワークスイッチは、一般的に垂直統合型の製品として提供されてきた。サプライヤーはハードウェア、オペレーティングシステム、機能ロードマップ、サポート関係を組み合わせ、システム障害時には購入者が連絡する窓口を一つに絞っていた。この構成は説明責任を単純化したが、ソフトウェアの選択、自動化インターフェイス、ハードウェア調達を同じベンダーに縛り付けた。数万台の類似したスイッチを運用する大規模クラウド事業者は、その結合を受け入れるか、スタックの多くを自前で構築する必要があった。

SONiC は後者の道を選んだ。Linux をベースに使い、ネットワーク機能をソフトウェアサービスに分割し、Redis をバックエンドに持つデータベースを通じて状態を交換し、ネットワークアプリケーションの下にハードウェア抽象化層を置く。このプロジェクトはハードウェアの違いを取り除くものではなく、単一のグローバルサポート契約を提供するものでもない。スイッチサプライヤー、ODM、ASIC ファミリーが変わっても生き残れる共通ソフトウェア層を作るものであり、その下にあるプラットフォーム固有の作業を誰かが完了しサポートすることが前提となる。

経済的な約束は、ディスアグリゲーション（分離）である。事業者はハードウェア、シリコン、オペレーティングシステムのディストリビューション、統合、サポートを一つの製品として購入する代わりに、それぞれ別々に選択できる。運用上の帰結は、責任の分散である。ある機能はコミュニティリリースに存在しても、特定のプラットフォームでは利用できないか、異なる挙動を示すことがある。決定的な制約がファームウェア、ドライバー、ベンダーの SAI コード、SDK、物理パイプラインのどこにあるかによる。

Azure はフリートの問題をオープンプラットフォームに変えた

Microsoft は SONiC を公に発表する前に Azure 向けに開発した。その出自は、オープンネットワーキングの抽象的な提案ではなく、本番環境の問題だった。ハイパースケール事業者は、大規模なスイッチ群を自動化し、従来の製品サイクルよりも速くソフトウェアを変更し、複数のサプライヤーからハードウェアを調達しつつ、それぞれに完全に異なる運用モデルを維持する必要がないようにする必要がある。

Microsoft は 2016 年 3 月 9 日、SONiC を Open Compute Project に提供すると発表した。名称は Software for Open Networking in the Cloud の略である。同社は SONiC をスイッチ向けソフトウェアネットワーキングコンポーネントの集合とし、Switch Abstraction Interface（SAI）と組み合わせた。この組み合わせは不可欠だった。なぜなら、すべてのルーティング、オーケストレーション、管理アプリケーションが各シリコンベンダーのインターフェイスを直接知る必要があるなら、移植可能な上部スタックの価値は限定的だからである。

SAI は、ポート、VLAN、経路、ネクストホップ、ネイバー、アクセス制御エントリ、キュー、バッファ、トンネル、カウンターなどのオブジェクトの共通プログラミング語彙を提供した。ASIC またはプラットフォームベンダーは、自社の SDK と転送パイプラインに対してこれらのオブジェクトを実装できる。SONiC アプリケーションは、共通コード全体にプロプライエタリなハードウェア呼び出しを埋め込む代わりに、標準オブジェクトを要求できる。

Open Compute Project への参加により、オープンハードウェアとハードウェア・ソフトウェア共同設計にすでに取り組んでいたデータセンター事業者、ODM、スイッチベンダー、シリコン企業とソフトウェアが結びついた。Microsoft は実際の運用環境をもたらし、より広いグループは、プロジェクトの約束を試すために必要なハードウェアの多様性を提供した。どちらの要因も移植性を完全にしたわけではない。すべてのプラットフォームで、ブート統合、ドライバー、冷却管理、光モジュール処理、SAI 実装、SDK サポート、継続的なテストが依然として必要だった。

あまり目立たない作業がエコシステムの基盤になった。共通のルーティング、オーケストレーション、管理コードは共有でき、ハードウェアに最も近い企業がプラットフォーム固有の層を維持した。Microsoft は Azure から得たエンジニアリングと要件を提供し続けたが、他のクラウド事業者、ベンダー、インテグレーターは、単一企業の社内ロードマップだけに依存しないプロジェクトへの経路を得た。

この歴史は、現在の Microsoft の役割を理解しやすくする。同社は SONiC を創設し、中立的なガバナンスが確立されるまでに長年の運用知識を蓄積した。プロジェクトの移管はその優位性を消し去らなかった。他の企業が投資し、統治し、貢献できる枠組みを作ったのであり、創設者の本番運用経験が一夜にして代替可能になったふりをするものではない。

Linux と Redis がスイッチをモジュール化し、ステートフルにした

SONiC は通常、Linux ベースのネットワークオペレーティングシステムと説明されるが、Linux だけではそのアーキテクチャを説明できない。ホストシステムはカーネル、デバイスアクセス、基本サービスを提供する。主要なネットワーク機能は個別のコンテナで実行され、Redis をバックエンドに持つデータベースが、サービス間の調整に使われる共有状態とメッセージングインターフェイスを提供する。Switch State Service はアプリケーションの意図を SAI 操作に変換し、ハードウェア向けプロセスがそれらの操作をベンダー実装に接続する。

コンテナ構造は歴史的に、ルーティング、Link Layer Discovery Protocol、Simple Network Management Protocol、リンクアグリゲーション、プラットフォーム監視、データベース、SWSS、ASIC 同期などの機能を分離してきた。この分離はパッケージングと組織上の所有権を改善するが、すべてのケースで強力なセキュリティ境界と見なすべきではない。ネットワークサービスはホストリソースを共有し、カーネルやハードウェアとやり取りするために昇格した特権を必要とする場合がある。その価値は主に、スイッチ全体を一つの不透明なプロセスにコンパイルすることなく、コンポーネントを個別に開発・再起動・アップグレードできることにある。

Redis が共通言語を提供する。CONFIG_DB は意図された構成を含む。APPL_DB はアプリケーションレベルの転送・サービス意図をオーケストレーション層へ運ぶ。ASIC_DB はハードウェア向けプロセス用に直列化された SAI オブジェクトを表し、STATE_DB はランタイムの準備状態と依存関係を記録する。COUNTERS_DB は運用ツールとテレメトリが使うインターフェイスとハードウェア統計を保存する。

構成は、ファイル、コマンドラインツール、gNMI、REST、その他の管理ソフトウェアを通じて入力される。マネージャープロセスはその入力をアプリケーション操作に変換し、SWSS が結果の状態を消費する。orchagent は依存関係を解決して SAI リクエストを作成し、sairedis はそれらを ASIC_DB に直列化し、syncd はベンダーの SAI ライブラリと SDK を呼び出す。異なる言語で書かれ、異なるチームが保守するコンポーネントは、プライベートな呼び出しの密な網ではなく、定義された状態を通じて調整できる。

結果は分散ステートマシンである。データベースキーが古くなることも、あるライターが別のライターと競合することも、アプリケーションがハードウェアに拒否される前に意図した状態を受け入れてしまうこともある。カウンターはデータベース経路に負荷をかけ、再起動時には複数のコンテナが、スイッチが何をすべきかについて一貫したビューを再構築する必要がある。Redis は受動的な実装詳細ではない。そのスキーマ、永続性、障害挙動はシステム全体の信頼性に影響する。

モジュール性はこれらの移行をより見えるようにする。事業者はリクエストがどこまで到達したかを検査し、次のステップを所有するサービスを特定できる。ただし、可視性は正確性を保証しない。FRRouting で選択され、APPL_DB に書き込まれ、ASIC_DB に表された経路が、転送ハードウェアに存在しないこともある。システムは、管理上の受け入れと実際のパケット配信を区別できる調整、診断、トラフィックの証拠を必要とする。

SAI はプロプライエタリな境界を移動させたが、撤去はしなかった

SAI は、SONiC が複数の ASIC ファミリーにまたがっておおむね共通の上位アーキテクチャを維持できる主な理由である。orchagent は、特定ベンダーの SDK 呼び出しを含めずに、経路、ポート、ネクストホップ、アクセス制御エントリ、キュー、トンネル、カウンターを要求できる。これにより結合が減り、基盤となるスイッチサプライヤーが変わってもネットワークアプリケーションに安定したオブジェクトモデルが提供される。

このインターフェイスは、物理的に異なる ASIC を同等にすることはできない。シリコンはテーブル容量、パイプラインデザイン、バッファアーキテクチャ、サポートされるオブジェクトの組み合わせ、カウンターの意味論、テレメトリ機能、更新の原子性、トンネル処理、再起動挙動が異なる。ベンダーは SAI オブジェクトをこれらのリソースにマッピングする必要があり、多くの場合、コミュニティのメンテナーが検査できないプロプライエタリなコードと SDK を通じて行う。

したがって、2 つのプラットフォームが同じ SAI バージョンを宣伝しながら、実質的に異なる挙動を示すことがある。一方がより大きな EVPN テーブル、より複雑なアクセス制御ポリシー、またはよりウォームな再起動をサポートするかもしれない。ある機能が、以前のチップにないシリコン機能や SAI 拡張を必要とするかもしれない。共通インターフェイスは上位ソフトウェアの変更量を減らすが、規模や成果を認証するものではない。

ガバナンスの境界が技術的な境界を強化している。SONiC は 2022 年 4 月に Linux Foundation へ移管されたが、SAI は Open Compute Project の下に残った。両コミュニティは調整するが、同じ意思決定構造を共有しているわけではない。テレメトリ、AI ネットワーキング、スケールアップイーサネットの新しい要件は、SONiC アプリケーション、SAI 定義、ベンダー実装、SDK、シリコンの同時変更を必要とする場合がある。

トラブルシューティングも同じ連鎖をたどる。有効なリクエストが、共通オーケストレーションコード、ベンダーアダプター、SDK、またはハードウェア自体で失敗する可能性がある。コミュニティのメンテナーは、それを生成したプロプライエタリな層にアクセスできずに SAI エラーを見ることがあり、ハードウェアベンダーは特定のイメージと SDK の組み合わせのみをサポートすることがある。商用ディストリビューションはこの統合負担の多くを引き受けることができるが、コミュニティ SONiC は単一の普遍的エスカレーション経路を作らない。

したがって、SONiC はベンダー依存をより狭く、より明示的なハードウェア向け境界へと移した。これは実質的なアーキテクチャ変更である。依存関係を撤去したわけではなく、困難な障害では、最終的な回答は依然として ASIC に最も近いプロプライエタリ実装を管理する企業から得られることがある。

状態の調整はモジュール性の代償である

アプリケーションは構成を受け入れ、期待されるデータベースに書き込み、ハードウェア向け層が ASIC は要求されたオブジェクトを作成できないと発見する前に完了を報告できる。失敗が十分なコンテキストとともに連鎖を戻ってこない場合、意図された状態、アプリケーション状態、実際の転送状態は一致しなくなる。モジュールシステムはその乖離を見つけやすくするが、発生する場所も増やす。

歴史的な SONiC 設計の一部は、SAI の作成失敗や設定失敗を致命的と扱った。プロセスを停止することは、不明なハードウェア状態で継続するより安全かもしれないが、スイッチの回復を困難にすることがある。その後のエラーハンドリング作業では、ERROR_DB や、経路・ネイバーなどの選択されたオブジェクトに対するアプリケーションフィードバックを含む設計が導入された。目的は、非同期リクエストに、元のアプリケーションと管理クライアントが解釈できる永続的な結果を与えることである。

構成変更には複数の依存操作が含まれることがある。システムはネクストホップグループを作成し、メンバーを追加し、経路を更新し、古い状態を削除するかもしれない。一部のステップは後の呼び出しが失敗する前に成功し、検証と実行の間にハードウェアの利用可能リソースが変わることもある。文字通りのロールバックは不可能または危険な場合があり、システムは一貫した状態に向けて前方修正を強いられる。

ウォームリスタートは同じ問題をアップグレードとプロセス回復に持ち込む。目的は、転送状態を破棄し、すべてのトラフィックを中断することなくソフトウェアを再起動することである。新しいプロセスは、前任者が意図したもの、Redis が含むもの、ASIC が実行し続けるものを調整する必要がある。スキーマ変更、古いキー、部分的に復元された依存関係が、永続性を別の不確実性の源泉に変えることがある。

したがって、事業者には成功したコマンド応答以上のものが必要である。CONFIG_DB はリクエストが受け入れられたことを、APPL_DB は変換されたことを、ASIC_DB は SAI オブジェクトが要求されたことを確認できる。どれもパケットが意図した経路をたどっていることを証明しない。ハードウェアカウンター、外部トラフィックテスト、状態調整は、通常の保証の一部であり続ける。

このアーキテクチャは、統合システムがしばしば隠す事実を露呈する。ネットワーク構成は単一の原子的書き込みではない。異なるタイミングと障害挙動を持つコンポーネントをまたぐ一連の状態遷移である。SONiC の信頼性は、遅延、拒否、再起動、部分完了の後にこれらのコンポーネントがどれだけうまく回復するかに依存する。

シャーシシステムは規模と障害の両方を増幅する

SONiC の初期の公的なイメージは、1 つの主要転送 ASIC を持つ固定フォームファクタのデータセンタースイッチと強く結びついていた。その後、プロジェクトは高密度スイッチ、モジュラーチャーシス、複数の転送 ASIC、ファブリックデバイス、ラインカード、管理コンポーネントを持つ分散型仮想出力キュー（VOQ）システムへ拡大した。

マルチ ASIC システムは、各転送デバイスに対して Redis、SWSS、syncd、ルーティング、リンクディスカバリ、リンクアグリゲーションの個別インスタンスを実行することがある。各 ASIC は独自の SAI と SDK インスタンスを持つことができる。ソフトウェアは、どのインターフェイス、ネイバー、経路がどの名前空間に属するか、内部リンクがどのように表現されるか、状態がデバイス間でどのように移動するかを決定する必要がある。

システムが大きくなると障害ドメインが変わる。経路はある ASIC に入り、別の ASIC から出ることがあり、フロントパネルリンクは内部ファブリック経路に依存する。別々の名前空間で収集されたカウンターは、1 つの論理スイッチの一部として提示されなければならない。1 枚のラインカードが、他のカードとコントロールプレーンが稼働し続けている間に再起動する可能性があり、ソフトウェアは独立してステートフルなコンポーネントをまたいでバージョン、オブジェクト所有権、ファブリック到達可能性を調整する必要がある。

分散 VOQ アーキテクチャは、この調整をシャーシ全体または複数のスイッチインスタンスに拡張する。転送とキューイングの決定は、リモートポートとファブリック状態の共有知識に依存することがある。ラインカード交換、コントロールプレーン冗長性、部分的なファブリック障害は、すべてのコンポーネントが同時に利用可能であると仮定せずに処理されなければならない。

SONiC 202605 リリースには、限定トポロジ向けの Alpha 機能として、限定的なマルチ ASIC ウォームリブートが含まれていた。このラベルは機能の存在と同じくらい重要である。実装作業が進行中であることを確認する一方で、複雑なマルチ ASIC システムにわたる回復力のある再起動が、まだ普遍的に認定された機能ではないことを明確にする。

シャーシサポートは、SONiC の関連性を通信事業者ネットワーク、高密度クラウド、AI インフラへ拡大する。また、統合ベンダーが長年にわたって蓄積してきたプラットフォーム固有の回復ロジックを持つシステムにプロジェクトをもたらす。オープンアーキテクチャは競争できるが、テストカバレッジ、アップグレード手順、サポート義務は、ASIC 数の増加だけよりも速く増大する。

管理が、開放性を運用可能にするかどうかを決める

共通のスイッチオペレーティングシステムは、事業者がフリート全体で構成、監視、アップグレードできる場合にのみ有用である。SONiC はコマンドラインツール、静的構成、SNMP、gNMI・YANG・REST・OpenAPI・Translib・検証フレームワークを含む作業をサポートする。利用可能な機能は依然としてリリース、データモデル、ディストリビューション、プラットフォームに依存する。

モデル駆動管理は、外部リクエストを Redis ベースの構成システムに変換することを意図している。YANG モデルは有効な構造を定義し、CVL と関連コンポーネントは不正な入力を拒否できる。Translib とサービスコンポーネントは API 操作を SONiC テーブルにマッピングし、コントローラーが内部データベースを直接操作する代わりにサポートされたインターフェイスを通じて作業できるようにする。

スキーマ検証は、要求されたサービスが許可されていること、別の変更と互換性があること、ASIC の残りリソースでサポート可能であることを証明できない。文書化された設計はまた、一般的なロックやロールバックなしの compare-and-swap 操作について説明していた。したがって、アプリケーション開発者は、管理層が普遍的なトランザクションを提供すると仮定する代わりに、所有権、並行性、補償を定義する必要がある。

OpenConfig と gNMI は、コンポーネントを含めることと運用機能を完成させることの違いを示す。SONiC 202605 は sonic-gnmi 0.1 を含んだが、OpenConfig YANG のダイヤルアウトテレメトリは Alpha のままであった。有用なサポート表明は、モデル、パス、読み取りまたは書き込み操作、テレメトリモード、リリース、ベンダーディストリビューションを特定しなければならない。スイッチが OpenConfig をサポートするという広い主張は情報が少なすぎる。

レガシーインターフェイスも引き続き必要である。SNMP はスイッチを既存の監視システムに接続し、LLDP はネイバー情報を提供し、プラットフォームサービスはファン、温度、電源、光モジュールを公開する。BMC と Redfish の作業は帯域外ライフサイクル機能に対応するが、202605 リリースの関連ワークフローのいくつかも Alpha ステータスを保持した。

エンタープライズスイッチングは、別の管理期待をもたらす。SONiC は、イメージを構築し、認定ラボを運営し、ハードウェアベンダーと直接関係を維持できるハイパースケール環境向けに設計された。キャンパスネットワークとアクセスネットワークには、Power over Ethernet、スパニングツリー、802.1X 入場制御、予測可能なエンドポイント管理などの機能が必要であり、多くの場合、クラウド規模のエンジニアリング能力を持たないチームによって運用される。

PoE とエンタープライズネットワーキングサービスをカバーする PENS working group は、そのギャップを埋める試みの一つである。他のグループは、管理、プラットフォーム OS、BMC 統合、仮想データプレーン、ドキュメントに対応する。それらの存在は活発な作業を示すが、均一な成熟度を示すものではない。エンタープライズ採用は、設計と実装から、リリースへの包含、ハードウェア認定、サポートされた商用提供へ機能を移すことに依存する。

商用ディストリビューションは、この境界で特に重要になる。テストされた管理面、アップグレードポリシー、ハードウェアマトリクス、サポートプロセスを上流コンポーネントの周りに提供できる。コミュニティ SONiC は共通ベースを供給する。事業者は依然として、スイッチで実際に実行されているイメージのライフサイクルを所有する当事者を必要とする。

Foundation という名称はプロジェクトと指定基金を指す

「SONiC Foundation」という名称は、独自の法定理事会、従業員、会計を持つ独立法人組織を示唆することがある。利用可能なガバナンス記録は、より重層的な説明を支持する。SONiC Foundation は Linux Foundation がホストする技術プロジェクトおよびコミュニティであり、一方で、独立して設立された SONiC Foundation 企業や独立した非営利法人は、提供された証拠では特定されなかった。

関連する構造である SONiC Fund は、Linux Foundation の Directed Fund（指定基金）である。技術プロジェクトを支援するために資金を調達し支出する。その Governing Board（運営委員会）は会員、予算、アウトリーチ、ポリシー、潜在的な適合性プログラムを監督する。Technical Steering Committee（技術運営委員会）は技術方向性を扱い、より広い構造内に代表されるが、技術と財務の権限は別個のままである。

この分離は、会員資格が導入や技術的支配の代用になることを防ぐ。企業は本番で SONiC を実行せずに Directed Fund に参加できる。Governing Board の議席がすべての設計議論を決定するわけではなく、コントリビューターは Premier メンバーシップを購入せずにソフトウェアに影響を与えることができる。Linux Foundation はプロジェクト資金とマークを管理し、コードの権利は関連するライセンスとコントリビューターの著作権によって支配される。

SAI は、Open Compute Project のイニシアチブであり続けるため、さらなる制度的境界を追加する。SONiC プロジェクトは共通のオペレーティングソフトウェアを開発し、Directed Fund はその作業に資金を供給し促進し、OCP は SAI と関連ハードウェア活動をホストし、ベンダーや事業者は結果のコンポーネントをスイッチと商用サポートと統合する。Dell Enterprise SONiC や他のディストリビューションは、Foundation を従来のソフトウェアベンダーに変えるのではなく、コミュニティプロジェクトの下流に位置する。

この構成は、決定と責任がどこにあるかを特定する。ワーキンググループと TSC が機能を形成し、Directed Fund 憲章が会費を管理し、OCP 参加者が SAI オブジェクトやバージョンを開発する。本番障害では、プロプライエタリな SDK チームや最終イメージを認定したサプライヤーが必要になることもある。すべての層を単一の Foundation として扱うと、事業者が管理しなければならない境界が隠されることになる。

中立的なガバナンスは Microsoft の影響力を消し去っていない

Linux Foundation は 2022 年 4 月 14 日に SONiC の移管を発表した。その時点で、プロジェクトは単一のクラウド企業の社内スタックという外観を超えて成長していた。中立的な枠組みは、Microsoft がホストするガバナンスへの依存をためらう可能性のある企業に、共有メンバーシップ、資金、選挙、ブランディング、技術参加を提供した。

発表では、SONiC はすでに数百万ポートと 100 以上のスイッチモデルで稼働し、50 以上のパートナーがいると述べられた。これらは独立した国勢調査ではなく、プロジェクトと創設者の主張である。それでも、この移管が新しい実験の孵化ではなく、展開済みプラットフォームの制度化として提示されたことを示している。

2026 年 5 月 5 日に修正された Directed Fund 憲章では、Premier メンバーが Governing Board の代表を指名できる。General メンバーは、その規模に応じて一つのクラスとして代表を選出し、Associate メンバーは理事会の議席を得ない。理事会は、増員されない限り通常 19 人の投票代表に上限があり、定足数は 50%、定足数が存在する場合の通常の決定は単純過半数で行われ、ただしコンセンサスが優先される。

Premier メンバーの Directed Fund 年間会費は 10 万米ドルで、必要な Linux Foundation 法人会員とは別である。General メンバーの会費は、従業員 499 人以下の組織で 1,000 米ドル、従業員 5,000 人以上の組織で 20,000 米ドルの範囲である。承認された Associate メンバーは基金会費なしで参加する。Linux Foundation は、年間総収入の最初の 100 万米ドルに 9%、それを超える部分に 6% の一般管理費を適用する。

これらの数字は資金メカニズムを説明するが、プロジェクトの実際の予算は開示しない。公開された年間基金収入、支出、準備金、プログラム別配分は特定されなかった。Governing Board 会議は、理事会が別段決定しない限りデフォルトで非公開であり、技術リポジトリとワーキンググループは、テスト、イベント、アウトリーチ、インフラを支える財務上の選択よりも可視性が高い。

現金は貢献モデルの一部にすぎない。Microsoft、クラウド事業者、シリコン企業、スイッチベンダー、インテグレーターは、エンジニアリング、プラットフォーム移植、SAI 実装、ラボ、継続的インテグレーション能力、ドキュメント、リリース作業を提供する。これらの貢献の価値は単一の財務総額として公開されておらず、プロジェクトは企業チームが優先順位を変えると影響を受ける状態が続く。

Microsoft は、現在のリーダーシップの最も目に見える集中を占めている。調査時点で、Dave Maltz が Governing Board の議長、Xin Liu が Outreach Committee の議長、Guohan Lu が Technical Steering Committee の議長を務めていた。Microsoft はまた、プロジェクトの創設者、Premier メンバー、積極的なコントリビューター、主要な本番運用事業者でもあった。

より広いガバナンスは真に複数企業によるものである。Governing Board の代表には、Alibaba Cloud、Arista、Broadcom、Celestica、Cisco、Dell、Google、Marvell、Nokia、NVIDIA、PLVision、Upscale AI、Nexthop AI などが含まれてきた。2026 年の TSC 選挙では、Microsoft、Google、Broadcom、NVIDIA、Alibaba Cloud、Cisco、Dell、Marvell と独立所属に関連する 1 人の議長と 8 人の投票メンバーが選出された。

形式的な投票がすべての技術的権限を捉えるわけではない。プロジェクトは実力主義モデルを説明し、紛争解決のためにコンポーネントまたはプロジェクトレベルでの「博愛主義的独裁」の要素を認めている。深い運用知識を持つメンテナーとエンジニアは、財務ガバナンスが分離されたままであっても、他の参加者が彼らのレビューに依存するため、結果に影響を与えることができる。

Microsoft の優位性は、リーダーシップの地位と Azure からの運用知識の組み合わせにある。障害、アップグレード、規模限界は、公開設計文書がめったに捉えない知識を生み出す。したがって、中立ガバナンスの試練は、Microsoft の優先順位が変わった場合に、他の組織が困難なサブシステムを所有し、設計選択に異議を唱え、リリースを維持できるかどうかである。理事会の多様性は枠組みを提供する。貢献の集中とメンテナー所有権は、より強力な証拠を提供するだろう。

リリースはベースラインを定義するのであって、認定製品ではない

SONiC 202605 は、現代のネットワークオペレーティングシステムがどれだけのソフトウェアを統合するかを示している。このリリースは Debian 13 Trixie、6.12.41 SONiC カーネル、SAI 1.18.1、FRR 10.5.4、Redis 8.0.2、Docker 28.2.1、Python 3.13.5 を使用した。また、リンクディスカバリ、アグリゲーション、SNMP、DHCP、ルーティングアドバタイズメント、テレメトリ、プラットフォームパッケージもまとめており、そのセキュリティとライフサイクルは単一のスケジュールで動かない。

依存関係リストはブランチレベルのベースラインを確立する。すべてのスイッチが同一のバイナリを実行するという意味ではない。プラットフォームイメージにはベンダーのカーネルモジュール、SAI ライブラリ、SDK、ファームウェア、ドライバー、構成が含まれ、商用ディストリビューションにはコミュニティブランチにないパッチが含まれることがある。

したがって、品質ラベルが不可欠である。202605 リリースは、OpenConfig YANG ダイヤルアウトテレメトリ、限定的なマルチ ASIC ウォームリブート、BMC Redfish ワークフロー、自己暗号化ドライブのパスワード操作、テレメトリ VRF バインディング、イベント・アラームフレームワークを Alpha として分類した。ユーザーはそれらの実装を評価できるが、リリースに含まれることは、リストされたすべてのプラットフォームでの安定した挙動の約束ではない。

テストは ASIC、スイッチ、トポロジ、機能、ブランチ、アップグレードパスの組み合わせをカバーしなければならない。公開 sonic-mgmt の条件には、プラットフォーム固有のスキップと期待される失敗が含まれる。スキップは、サポートされていない機能、テストの制限、既知の問題、無関係なケースを示すことがあるため、自動的に製品欠陥として扱うべきではない。それでも、より広いパターンは「SONiC をサポートする」という表現が調達には広すぎる理由を示している。

意味のあるプラットフォーム表明は、ハードウェア、ASIC、イメージプロバイダー、SONiC リリース、SAI 実装、SDK、テスト済み機能、サポート所有者を特定する。ある固定スイッチでのウォームリブートは、分散シャーシについてはほとんど語らない。ある ASIC でのアクセス制御スケールは別の ASIC に移せず、コミュニティイメージの gNMI パスは商用ディストリビューションが提供するインターフェイスと異なることがある。

コミュニティは共通リリースとテストフレームワークを公開できるが、本番の説明責任は事業者と最終イメージを認定した当事者に属する。Directed Fund 憲章は適合性プログラムを認めているが、現在のプラットフォームにわたって同等な合否結果を示す包括的な独立マトリクスは特定されなかった。そのような証拠が存在するまで、リリースは共通コードを中心とした統合契約であり、そこから構築されたシステムの普遍的な認証ではない。

AI ファブリックは共通層にとって最も厳しい試練である

大規模 GPU クラスターは、データセンターネットワークへの要求を変えている。分散トレーニングは、長時間続く同期フロー、低いトラフィックエントロピー、マイクロバースト、最も遅い参加者によって制限される性能を生み出すことがある。事業者は、高帯域幅、迅速な障害収束、高密度のネイバー・セッション規模、正確な輻輳証拠、新しいスイッチシリコンに依存する可能性のある機能を必要とする。

2026 年 7 月の SONiC Foundation の記事で、Microsoft の Guohan Lu と Broadcom の Mehak Mahajan は、Microsoft の Fairwater アーキテクチャと、2025.11 リリースまでに利用可能とされる 4 つの機能、すなわちより高い BGP スケール、SRv6 に基づく送信元選択型トラフィック分散、パケットトリミング、高頻度ストリーミングテレメトリについて説明した。同じ記事は、最大 512,000 個の GPU をサポートすることを意図したマルチプレーン・マルチレール設計について説明した。これらはプロジェクトおよび実務者の主張であり、全数が同時に稼働しているという独立監査済みの証拠ではない。

BGP の作業は、関連設計でスイッチあたり 512 セッション、約 1,000 経路、512 ネクストホップをサポートすると説明された。FRR 10 と約 20 のターゲットパッチが、データプレーン収束を 100 ミリ秒未満にすると言われた。記事は完全なトポロジ、パーセンタイル分布、ハードウェア仕様、独立して再現可能な方法を提供しなかったため、この数字は SONiC の普遍的な性能保証ではなく、報告されたアーキテクチャに属する。

SRv6 と uSID は、少数の非常に大きなフローによって生み出される限られたエントロピーに対処する。エンドポイントが選択する経路は、従来のハッシュよりも意図的にトラフィックを分散できるが、このメカニズムには互換性のあるエンドポイントまたは NIC、適切な ASIC パーシング、テーブル容量、ルーティングサポート、障害回復が必要である。オペレーティングシステムの機能は、調整されたスタックの一部としてのみ機能する。

パケットトリミングは、破棄されたパケットから短いヘッダーを保存し、宛先が損失をより速く検出できるように転送する。Foundation の記事は、現在の 512 ポートハードウェアで、最大 18 の入力ポートからのトリミングされたヘッダーが 1 つの出力ポートを通じて排出できるハードウェア固有のケースを説明した。結果は ASIC とトラフィックパターンに依存し、すべての SONiC プラットフォームまたはエンドポイントがこのメカニズムをサポートすることを示すものではない。

高頻度テレメトリは、より遅いポーリングで見逃されるイベントを捕捉することを意図している。説明された経路は、ASIC IPFIX カウンターエクスポート、Counter SyncD、COUNTERS_DB、およびオンスイッチ分析または Prometheus・InfluxDB などのシステムへの OpenTelemetry エクスポートを使用する。この設計は、Redis とテレメトリ処理を AI ファブリックのフィードバックループの中に置き、運用価値と性能負担の両方を増やす。

メンバーシップも同じ方向に従った。Upscale AI は 2026 年 2 月に Premier メンバーになった。Supranett は 7 月 28 日に Premier レベルで参加し、Exaware、TeraHop、Infrawaves は General メンバーになった。Nexthop AI や他の AI ネットワーキング企業もガバナンスまたはワーキンググループの役割を保持している。メンバーシップは投資と意図を示すが、導入を示すものではない。ただし、企業が共通プラットフォームに解決を期待する問題を特定する。

スケールアップイーサネットは、歴史的に専用インターコネクトを使用してきたアクセラレータシステムに SONiC を近づける。Scale-Up Ethernet working group は、OCP E-SUN と整合した作業を含む新しい要件を、リンクレベル再送、クレジットベースのフロー制御、適応型フローハッシュ、スケールアップパケットヘッダー、より大きなエンドポイントファブリックをカバーする実装に変換することを意図している。

機会は大きい。成熟した実装は、1 つのオープンネットワーク OS 環境が大規模スケールアウトファブリックと新興スケールアップイーサネット市場の一部にサービスを提供できるようにするかもしれない。事業者は AI ネットワークのより多くの部分で管理、テレメトリ、プラットフォームの実践を再利用できる。

調査時点で、この作業は完成した普遍的な標準または広範な展開に達していなかった。要件は依然として進化しており、ベンダーは拡張を通じて必須機能を公開する可能性があり、変更は SONiC、SAI、エンドポイントソフトウェア、NIC、ファームウェア、シリコンをまたがなければならなかった。SONiC がより専門的なアクセラレータ挙動に近づくにつれて、正確なハードウェア意味論がより重要になる。共通層は拡大するかもしれないが、その下のプロプライエタリな境界はより重要になる。

セキュリティはプラットフォームが本番稼働した後に正式化された

SONiC イメージは、Debian、Linux カーネル、コンテナランタイム、Redis、FRRouting、管理サービス、LLDP、SNMP、DHCP コンポーネント、Python パッケージ、プラットフォームドライバー、ベンダー SAI ライブラリ、プロプライエタリ SDK、ファームウェア、ビルドインフラを組み合わせる。これらの層のいずれかの脆弱性がスイッチまたはその管理プレーンに影響を与える可能性があり、修正の責任は複数のプロジェクトとサプライヤーに分割されることがある。

公開された Security Working Group（セキュリティワーキンググループ）は 2026 年 6 月に承認された。その範囲には、ソフトウェア部品表（SBOM）、Vulnerability Exploitability eXchange（VEX）情報、依存関係の衛生、静的・動的分析、ファジング、ペネトレーションテスト、サプライチェーンセキュリティ、ハードニング、セキュアまたは測定されたブートが含まれた。Nexthop AI の Brad House が議長、Microsoft の Qi Luo が共同議長として特定された。

設立文書は、かなりの量のセキュリティ作業が以前は十分に明確な所有権を欠いていたことを認めた。セキュリティが存在しなかったわけではない。上流プロジェクト、メンテナー、ベンダーが脆弱性を処理し、報告プロセスも存在した。認められたのは、統合システム全体にわたる責任が、プラットフォームの本番利用に見合う目に見える公開ワークストリームに組織化されていなかったことである。

ワーキンググループはそのタスクを完了しない。成熟したプログラムには、最新の SBOM、来歴記録、脆弱性トリアージ、署名付きまたは再現可能なビルド、パッチポリシー、非公開開示の処理、バックポート、プラットフォーム固有のアドバイザリが必要である。プロプライエタリな SAI ライブラリ、SDK、ファームウェアは、コミュニティがソースを検査できず、リリーススケジュールを制御できないため、上流の見方を複雑にする。

管理サービスは特に精査に値する。gNMI、REST、SSH、SNMP は特権制御または情報を公開し、証明書管理、役割設計、監査、シークレット処理、ネットワーク分離を必要とする。コンテナはパッケージングを改善するが、ホストリソースを共有し昇格した機能を必要とする場合、自動的に強力なセキュリティ境界を作るわけではない。オーケストレーションまたはデータベース経路の侵害は、多くの転送オブジェクトに影響を与える可能性がある。

商用ベンダーは、製品に異なる組み合わせとサポートポリシーが含まれるため、独自のアドバイザリを発行する。Dell Enterprise SONiC の脆弱性を、すべてのコミュニティイメージに自動的に一般化すべきではない。事業者は、上流プロジェクトページがスイッチ内のすべてのプロプライエタリコンポーネントをカバーすると想定することもできない。

Security Working Group は、プロジェクト成熟度の最も明確な試練の一つになった。SONiC は、オープンコラボレーションがルーティング、データベース、ハードウェア抽象化を統合できることを示した。次に、同じ制度的モデルが、最も敏感な層がすべてオープンではないサプライチェーン全体に所有権を割り当てられることを示さなければならない。

オープンソースはサポートコストを移すのであって、なくすのではない

コミュニティ SONiC は、ソースコード、アーキテクチャ、リリース、ワーキンググループ、共有テストフレームワークを供給する。普遍的な本番サービスレベル合意を提供するわけではない。コミュニティプロジェクトを使用する事業者は、ハードウェア認定、イメージ構築、アップグレード、セキュリティバックポート、インシデント対応、ASIC またはプラットフォームサプライヤーとの関係について責任を割り当てなければならない。

ハイパースケーラーは、スタックの制御がディスアグリゲーションを追求した理由であるため、その負担を受け入れるかもしれない。彼らは Linux、ルーティング、リリースエンジニアリング、ハードウェアチームを維持し、認定ラボを運営し、シリコンサプライヤーと直接交渉できる。彼らの運用モデルは、ソフトウェアの独立性を実質的な内部エンジニアリングコミットメントに変換する。

多くの企業とサービスプロバイダーは、サプライヤーに統合リスクの多くを吸収してもらう必要がある。Dell は認定ハードウェアと商用サポートを備えた Enterprise SONiC を提供する。Nokia は選択されたプラットフォームでコミュニティ SONiC イメージとサポートを提供し、他のスイッチベンダー、ODM、インテグレーターは独自の組み合わせをパッケージ化する。これらの提供はより明確なエスカレーション経路を確立できるが、パッチ、管理機能、ハードウェアカバレッジ、リリースタイミングで分岐する可能性がある。

商用層は、ライフサイクル作業と責任が販売される場所である。クラウド事業者は調達の柔軟性を得る。スイッチ・シリコンベンダーはシステムを販売し、ディストリビューターはサブスクリプションとサポートを販売し、インテグレーターはエンジニアリングを販売する。顧客は一つの垂直統合サプライヤーへの依存を減らせるかもしれない。Directed Fund 自体には、株式株主、企業評価額、公開された単独利益はない。

参加者は共通層の周りで協力しながら、その上と下で競争する。Arista、Cisco、Dell、Nokia、NVIDIA は、異なる製品を販売しながら同じプロジェクトに貢献できる。クラウド事業者は共通インターフェイスをサポートしながらハードウェアサプライヤーと積極的に交渉でき、ASIC 企業は SONiC が自社のシリコンを統合しやすくする一方で機能と性能の差別化を維持することで利益を得る。

共通層は、参加者が共通の挙動を受け入れる場合にのみ重複作業を減らす。プライベートな SAI 実装、下流パッチ、ベンダー拡張は、製品が SONiC という名前を共有していても移植性を弱める可能性がある。企業は、エコシステムを維持するのに十分な貢献をしながら、自社の提供物を販売するのに十分な違いを維持するインセンティブを持つ。

会費は財務参加を可視化するが、エンジニアリングがおそらくより大きな通貨である。10 万米ドルの Premier 会費は基金にとって重要であり、専門チームやハードウェアラボを維持するコストのそばでは小さい。長年の実装とテストを提供する組織は、憲章が支払いと技術的受け入れを形式的に分離していても、運用現実を通じて結果を形成できる。

公開された基金予算がないため、現金の優先順位がどのように選ばれるかの分析は限られる。財務の透明性が高まれば、事業者は表明された優先順位をセキュリティ、テスト、ドキュメント、継続的インテグレーション、適合性への支出と比較できるようになる。Security Working Group の創設は、大規模で潤沢なリソースを持つメンバーがエコシステムに存在する場合でも、重要な領域の所有権が不十分なままであり得ることを示している。

購入者は「SONiC ベース」をデューデリジェンスの出発点と見なすべきであり、結論ではない。ブランチ、SAI バージョン、SDK、ファームウェア、イメージ所有者、認定機能、セキュリティポリシー、サポート経路を知る必要がある。また、イメージを再現できるかどうか、コミュニティ、ベンダー、ハードウェアのリリーススケジュールが分岐したときに何が起こるかを知る必要がある。

ディスアグリゲーションは、それらの境界が見えたままである場合にのみ選択肢を生む。そうでなければ、事業者はベンダーロックインを、カスタムイメージ、単一のインテグレーター、または他の場所で維持できない SDK ビルドへの依存に置き換えることができる。オープンアーキテクチャは代替を可能にする。サポート契約と内部エンジニアリングが、それらが使用可能なままであるかどうかを決定する。

展開は実質的だが、比較可能性は依然として弱い

Linux Foundation の 2022 年の移管発表は、SONiC が数百万ポートと 100 以上のスイッチモデルで稼働していると述べた。2024 年 4 月、Foundation は 520 以上の組織から 4,250 人のコントリビューターと年間コミュニティ成長 20% を報告した。ガバナンスの経歴には、Alibaba が 10 万台近くの SONiC ベースのスイッチ、ゲートウェイ、ルーターを運用していると書かれていた。

各数字は規模を示すが、どれも独立した監査済み国勢調査ではない。コントリビューター総数には歴史的な参加者が含まれることがあり、サポート対象モデルは本番量が少ないことがあり、Foundation メンバーシップは展開を証明しない。公的な主張は異なる単位を説明しており、単一の信頼できる市場シェアに組み合わせることはできない。

名前が挙げられたケースは、使用のより確かな証拠を提供する。Microsoft は SONiC を開発し、Azure で運用している。Alibaba、eBay、EPFL は Linux Foundation への移管を支持し、自社の使用を説明した。Orange は 2024 年に約 90 台のスイッチの初期本番展開と拡大の意向を報告し、Foundation 資料は後に SAKURAONE、Tokyo-1、Rakuten、インドの決済展開を強調した。Dell と Nokia は選択されたハードウェアに結びついたサポート製品を提供している。

この証拠は、SONiC を実験的なラボプロジェクトと説明することを拒否するのに十分以上である。本番起源、アクティブなリポジトリ、複数のシリコン・ハードウェアパートナー、商用ディストリビューション、名前が挙げられた事業者展開がある。依然として得られないのは、アクティブなシステム、サポートされた機能セット、プラットフォーム間の比較可能な挙動の一貫した尺度である。

この制限は、SONiC がエンタープライズネットワークと AI ファブリックに拡大するにつれて、より重要になる。ポート数の合計はカテゴリーの信頼を提供し、プラットフォームレベルの証拠が特定の展開がサポート可能かどうかを決定する。事業者は、リリース、ASIC、イメージ、機能マトリクス、アップグレード記録、インシデント履歴、責任あるサプライヤーを必要とする。

SONiC は、カスタムハイパースケールソフトウェアと垂直統合された商用ネットワーク製品の間に位置する。Arista EOS、Cisco NX-OS、Junos、Nokia SR Linux は、単一のサポート製品関係を持つ成熟したシステムを提供する。NVIDIA Cumulus Linux は別の商用 Linux ベースのアプローチを提供する。Dell Enterprise SONiC とサポートされた Nokia 提供は SONiC ベースを商業化し、DENT、FBOSS、Open Network Linux、Stratum、Linux switchdev は隣接するオープンまたは事業者開発アーキテクチャを代表する。

SONiC の利点は、単一の Linux、コンテナ、Redis、SWSS、SAI モデルの周りにある共有エコシステムの規模である。事業者は共通コードを検査・変更し、複数のハードウェア経路から選択し、自動化の一部をサプライヤー間で再利用できる。欠点は、その自由によって生み出される統合マトリクスである。性能とサポートは、層がどれだけうまく再組み立てされたかに依存する。

AI ネットワーキングは、購入者が大量のスイッチを購入しながら新しい機能を迅速に要求するため、賭け金を引き上げる。共通オペレーティングシステムは、システム・シリコンベンダー間の重複統合を減らすことができる。同じ緊急性が、1 つの展開を解決しながら移植性を弱める拡張を促すことがある。SONiC の市場ポジションは、そのインターフェイスが、互換性のない実装上の名目上の抽象化にならずに、ペースを維持できるかどうかに依存する。

境界は見えている。説明責任はまだ証明されなければならない

SONiC は、クラウド事業者の内部アーキテクチャを共有ソフトウェアプラットフォームに変えることで、ネットワークスイッチングを変えた。Linux、コンテナ、Redis が共通の運用プレーンを作った。SWSS はアプリケーションの意図をハードウェア操作から分離し、SAI は複数の ASIC ファミリーに共通のオブジェクトモデルを与えた。Linux Foundation のガバナンスは、競合企業がソフトウェアに資金を提供し開発できる、より中立的な構造を提供した。

このプロジェクトはスイッチを交換可能にしていない。リストされたすべてのプラットフォームを認定するわけでも、プロプライエタリな SDK を撤去するわけでも、単一のサポート体験を提供するわけでもない。コミュニティリリースには Alpha 機能が含まれることがあり、共有 SAI バージョンは異なる容量、エラー挙動、再起動特性を隠すことができる。セキュリティ調整は、上流プロジェクトが所有も閲覧もできないコンポーネントを制御できない。

それらの限界は、プロジェクトの本当の貢献を明らかにする。ディスアグリゲーション以前は、ハードウェアとソフトウェアの境界は主に単一のサプライヤーの中にあった。SONiC はその多くを明示的で議論可能にし、事業者がどの機能が共通で、どれがプラットフォーム固有で、どの当事者が最終システムの責任を受け入れたかを特定できるようにした。

次のフェーズは、プラットフォームが拡大するにつれてその境界が一貫性を保てるかどうかを試す。AI スケールアウトファブリックは迅速な収束と高頻度テレメトリを要求する。スケールアップイーサネットはアクセラレータシステムに近づき、マルチ ASIC シャーシは状態の複雑さを増し、エンタープライズ作業はユーザーベースを広げ、セキュリティガバナンスは大規模な混合ソースサプライチェーンにまたがらなければならない。

SONiC は、スイッチオペレーティングシステムの大きく価値ある部分を単一サプライヤーのハードウェアスタックから分離した。転送をシリコンから分離したわけではなく、どのソフトウェアアーキテクチャもそれはできない。相互運用性は依然として SAI 実装、SDK、ドライバー、ファームウェア、光モジュール、認定、サポートに依存する。

したがって、観察可能な試練は、どれだけ多くの製品が SONiC という名前を持つかではない。異なるプラットフォームが比較可能な挙動を示せるか、セキュリティと保守の所有権が企業の変化を生き残るか、事業者が別の文書化されていない依存関係の周りに運用モデルを再構築せずにサポートされたシステム間を移動できるかである。

SONiC とスイッチソフトウェアの未完の分離

なぜ重要か