設定データフロー¶
SONiC の設定を読むときは、まず CONFIG_DB を起点にします。CONFIG_DB はユーザや controller が投入した意図を保持し、各 daemon がそれを購読して自分の担当する実行状態へ変換します。代表的には、*mgrd が CONFIG_DB を読み、APPL_DB に orchagent 向けのテーブルを作り、orchagent が ASIC_DB 経由で syncd / SAI へ渡します。
CONFIG_DB はどの情報を持つか¶
CONFIG_DB は単なる key-value ではなく、テーブルごとに用途が分かれます。装置全体の根本設定は DEVICE_METADATA、機能 docker の制御は FEATURE が代表です。
| テーブル | 読む場面 | 代表的な利用者 |
|---|---|---|
DEVICE_METADATA|localhost |
hostname、platform、BGP ASN、buffer model、switch type など装置単位の前提を確認する | bgpcfgd、orchagent、hostcfgd |
FEATURE|<name> |
bgp、telemetry、snmp など feature service の起動制御を見る | hostcfgd、system health |
| 機能別テーブル | VLAN、BGP、ACL、QoS など各機能の設定を見る | 各 *mgrd / *cfgd |
DEVICE_METADATA は多くの章の前提条件です。BGP、Multi-ASIC、Dual-ToR、SmartSwitch、buffer、DHCP server などの挙動がここから分岐するため、機能ページで謎の既定値が出てきたら最初に確認してください。
APPL_DB / STATE_DB / ASIC_DB の読み方¶
swss-schema は APPL_DB と STATE_DB の中心スキーマをまとめる参照ページです。APPL_DB は orchagent に対する依頼、STATE_DB は SONiC 内部の状態共有、ASIC_DB は syncd に渡す ASIC 操作に近い層です。
flowchart TB
subgraph Config
CLI[CLI / gNMI / config file]
CDB[(CONFIG_DB)]
end
subgraph Managers
MGR[portmgrd / vlanmgrd / intfmgrd / bgpcfgd / hostcfgd]
end
subgraph SWSS
ADB[(APPL_DB)]
SDB[(STATE_DB)]
OA[orchagent]
ASICDB[(ASIC_DB)]
end
subgraph ASIC
SYNC[syncd]
SAI[SAI]
HW[ASIC SDK / hardware]
end
CLI --> CDB
CDB --> MGR
MGR --> ADB
MGR --> SDB
ADB --> OA
OA --> ASICDB
ASICDB --> SYNC
SYNC --> SAI
SAI --> HW
HW --> SYNC
SYNC --> SDBこの流れで重要なのは、CONFIG_DB に正しい値があっても、APPL_DB や ASIC_DB まで届いていなければデータプレーンには反映されないことです。障害切り分けでは「設定値」「manager の投影」「orchagent の処理」「syncd / SAI の処理」を順番に見ると原因を分けやすくなります。
Redis 以外のトランスポート¶
通常の ProducerStateTable / ConsumerStateTable は Redis を使いますが、低レイテンシ用途では ZMQ ProducerStateTable / ConsumerStateTable の設計があります。ZMQ 版は既存 API 形状を保ちつつ、Redis 書き込みを optional にできます。性能は上がりますが、DB に痕跡を残さない構成では観測性が落ちるため、トラブルシュート時には対象機能が Redis 経由か ZMQ 経由かを確認します。
管理 API 側の Redis 接続¶
REST / gNMI / Management Framework 側では Redis client の作り方自体が性能と安定性に影響します。Redis Client Manager は、Go 実装の translib 周辺で DBNum ごとの共有 connection pool と transactional client を分ける設計です。設定データフローそのものではありませんが、自動化 controller から大量の Set / Get が来る環境では、管理 API 側の接続管理もボトルネックになります。