コンテンツにスキップ

アーキテクチャ

SONiC の内部実装を 1 枚で押さえるなら、左から CLI / gNMI / 制御プレーン daemon、中央に Redis DB 群、右に syncd と SAI/ASIC を置く絵になる。各機能章で *Orch、*syncd、*mgrd のように出てくる名前は、この絵のどこに座るかで役割が決まる。

flowchart LR
    subgraph IN[設定・制御の入口]
      CLI[CLI / sonic-cfggen]
      GNMI[gNMI / REST / Mgmt Framework]
      FRR[FRR bgpd/zebra]
    end

    subgraph CTL[制御プレーン daemon]
      CFGD[bgpcfgd / *cfgd]
      MGRD[portmgrd / vlanmgrd / *mgrd]
      SYNCAPP[fpmsyncd / portsyncd / teamsyncd]
    end

    subgraph REDIS[Redis DB 群]
      CDB[(CONFIG_DB)]
      APP[(APPL_DB)]
      STDB[(STATE_DB)]
      CTRDB[(COUNTERS_DB)]
      ASICDB[(ASIC_DB)]
      ERRDB[(ERROR_DB)]
    end

    subgraph ORC[orchagent]
      ORCH[sub-Orch 群]
    end

    subgraph DPL[データプレーン適用]
      SD[syncd]
      SAI[SAI lib]
      ASIC[ASIC / NPU]
    end

    CLI --> CDB
    GNMI --> CDB
    FRR --> SYNCAPP
    CDB --> CFGD --> APP
    CDB --> MGRD --> APP
    SYNCAPP --> APP
    APP --> ORCH
    CDB --> ORCH
    ORCH --> ASICDB
    ORCH --> STDB
    ASICDB --> SD --> SAI --> ASIC
    SAI -.failure.-> SD --> ERRDB
    SD --> STDB
    SD --> CTRDB

DB ごとの責務

CONFIG_DB は永続化された設定の唯一の source of truth である。APPL_DB は制御プレーンが「ASIC にこうしたい」と書く intent の場で、各機能の *_TABLE がここに置かれる。STATE_DB は実際の状態と監視ヒントで、syncd や各 daemon が書き込む。COUNTERS_DB は ASIC から取得した counter の集計先で、flexcounter 群が更新する。ASIC_DB は SAI object を Redis 表現に落としたもので、orchagent が書き、syncd が読む。ERROR_DB は SAI 失敗を APP 側に伝えるためのチャネルである。

スキーマの一次ソースは swss-schema（APPL_DB / STATE_DB の中心スキーマ参照） を読む。

ProducerStateTable と非同期化

APPL_DB と ASIC_DB は、書き手と読み手が別プロセスに分かれる。Redis に直に SET するのではなく、ProducerStateTable / ConsumerStateTable を介して「key の変更通知」を queue として渡す。これにより読み手側は変更分だけを取り出して処理できる。ZMQ ベースに置き換える設計は ZMQ ProducerStateTable / ConsumerStateTable 設計 を読む。

ASIC_DB 側は sairedis が非同期に消費し、SAI 呼び出しに変換する。SAI 呼び出しの結果は完了通知や ERROR_DB を介して orchagent に戻る。これが「orchagent が ASIC_DB に書いたら、すぐ ASIC に入っているとは限らない」根拠である。

syncd と SAI の境界

syncd は ASIC_DB を消費し、SAI API を呼ぶ唯一の場所である。ベンダごとの SAI 実装は libsai に隠れ、syncd と orchagent はベンダ非依存に保たれる。SAI 失敗は syncd で観測され、handleSaiSetStatus/handleSaiCreateStatus 系の virtual で処理される。fatal なものは crash、recoverable なものは ERROR_DB / STATE_DB 経由で上位に通知する設計である。詳細は SAI 失敗ハンドリング と Error Handling Framework を読む。

機能章はこの絵のどこを使うか

機能章 主に使う部分
BGP FRR → fpmsyncd → APPL_DB（ROUTE_TABLE/NHG）→ RouteOrch → ASIC_DB
L2 VLAN LAG CONFIG_DB → vlanmgrd/portmgrd → APPL_DB → PortsOrch/VlanOrch → ASIC_DB
ACL CoPP Mirror CONFIG_DB → AclOrch → ASIC_DB（ACL_TABLE/ENTRY/COUNTER）
VRF / ECMP APPL_DB（NEXT_HOP_GROUP_TABLE） → NhgOrch → ASIC_DB

機能章での具体的な経路は各章のアーキテクチャを参照する。共通の「ProducerStateTable」「ASIC_DB」「ERROR_DB」の動きはここに戻ってくる。

関連ページ