コンテンツにスキップ

gNMI / OpenConfig の発展トピック

gNMI / gNOI / Translib / Transformer の基本パスを押さえた後は、telemetry の規模拡張、認証境界 (gNSI)、新しい RPC への対応が次の論点になる。

発展トピック

  • gNMI dial-out (publish to collector): 通常の gNMI Subscribe は server-driven だが、規模が増えると collector 側で多数の subscription を維持するコストが高い。dial-out では target 側から collector に push する構成で、scale 上有利。telemetry docker と外部 collector の組合せが議題。
  • OpenConfig wildcard subscribe: /interfaces/interface[name=*]/state/counters のような wildcard query で per-port stream を一括取得する用途。Sample interval と server CPU 負荷のトレードオフがある。
  • gNOI による OS upgrade: gnoi.os.Install / Activate で SONiC イメージを集中投入する運用。warm/fast reboot との組み合わせで in-service upgrade を実現する。
  • gNSI による証明書 / authz の管理: gnsi.certz / gnsi.authz で gNMI の TLS 証明書と RBAC ポリシーを動的に更新する。controller 側で証明書ローテーションを行うと SONiC 側はサービス停止なしで更新できる。
  • Transformer の自前 callback 追加: 既存 OpenConfig path に対応する CONFIG_DB が無いとき、Go callback (transformer/xfmr) を書いて変換ルールを足す。プラグイン的に拡張できる。
  • SAI Redis streaming (低レベル): gNMI 経由ではなく、COUNTERS_DB を直接 streaming する場合の挙動。debug 用途で redis-cli psubscribe でリアルタイム counter を見る。

既知の制約と回避方法

  • subscription scale limit: target あたりの concurrent stream 数には実用上の上限があり、過剰登録で telemetry docker が CPU 100% になる例がある。collector を複数にして load を分割する。
  • OpenConfig path と SONiC schema のミスマッチ: SONiC 固有機能 (Dual-ToR mux、warm-reboot state) は OpenConfig path に対応が無く、sonic-mgmt-common の vendor-augmented YANG で表現される。
  • gNMI Set の atomicity: 単一 SetRequest 内の複数 update は SONiC 側で完全 atomic とは限らない。CONFIG_DB の partial commit で transient 状態が見える可能性。
  • 証明書回転中の reconnect: controller が証明書を更新した後、client 側 dial を一度切る必要がある場合がある。gNSI による hot swap が対応していれば回避可能。

将来計画 / ロードマップ

  • gNxI suite (gNMI / gNOI / gNSI / gRIBI) は OpenConfig コミュニティで継続拡張中。SONiC 側は sonic-gnmi の依存ライブラリ更新で取り込む。
  • gRIBI を経由した RIB 直接注入が議論されており、controller 側で経路を直接 push する用途で SDN ベース fabric の管理が変わる可能性。
  • OpenConfig の network-instance / VRF モデルの SONiC 対応は段階的で、未対応 path には vendor augment が並走する。

関連 RFC / 仕様書

upstream 開発の最新動向

  • sonic-gnmi repo で gNSI authz と certz 取り込み、TLS 認証経路のリファクタが継続。
  • sonic-mgmt-common (Translib / Transformer) で OpenConfig path カバレッジ拡張 PR が頻繁。Routing / BGP / VRF / QoS の path 追加が主軸。
  • Telemetry docker の memory footprint 改善と subscription scale 上限緩和の PR が継続。collector 側 (gnmic、gnxi) も community 主導でツール成熟が進む。

ハンドオフ

dial-out と scale 設計の詳細

gNMI dial-out (publish to collector) は server-driven Subscribe の補完で、target 側が active TCP connection を保ち、自分から push する。collector 側で session 数を減らせるため、数千台の fabric では運用負荷が下がる。SONiC の telemetry docker は dial-out 用の goroutine を spawn し、DIALOUT_CLIENT テーブルから dest list を読む。再接続 backoff、QoS DSCP marking、TCP keepalive はチューニング対象になる。collector 側 (gnmic, gnxi) の prometheus exporter と組み合わせると metrics pipeline が完成する。

OpenConfig wildcard subscribe は /interfaces/interface[name=*]/state/counters のような path で per-port stream を一括取得するが、sample interval を 1s で全 port 投入すると server CPU が 100% に達する例がある。対策は (1) STREAM モードを SAMPLE に絞る、(2) heartbeat interval を 30s 以上に広げる、(3) collector を分割して target を pin する、の 3 通り。

gNOI / gNSI の運用境界

gNOI OS の Install / Activate / Verify は SONiC の sonic-installer を内側で呼ぶ。Install は image を /host/image-<ver>/ に展開、Activate は next-boot を切り替える。warm/fast reboot と組み合わせるなら、Activate 直後に gNOI System.Reboot を WARM mode で呼ぶ。失敗した場合の rollback は Activate で前 image を指定するだけで再起動を要するため、運用 runbook 側で plan B を持つ。

gNSI certz は TLS 証明書を hot-swap する RPC で、gnmi-server が listen socket を rebuild せずに新 cert を採用する。controller 側で短命証明書 (24h) を回転させる構成が想定されている。authz は RBAC ポリシー (gRPC method × role × user) を JSON で push し、mgmt-framework の AAA 層に反映する。pathz は path 単位のアクセス制御で、SONiC では実装途中。

Transformer 拡張と native YANG

OpenConfig path の SONiC 未対応領域に対しては、sonic-mgmt-common (Translib / Transformer) に Go callback (xfmr) を追加することで CONFIG_DB マッピングを足せる。transformer/xfmr/*.go の init() で XlateFuncBind に register する流れで、key xfmr / field xfmr / subtree xfmr の 3 種類がある。vendor augmented YANG は sonic-mgmt-common/models/yang/extensions/ に置かれ、OpenConfig deviation よりも自由度が高い。

既知の制約と回避方法

  • subscription scale limit: target あたりの concurrent stream 数には実用上の上限があり、過剰登録で telemetry docker が CPU 100% になる例がある。collector を複数にして load を分割する。
  • OpenConfig path と SONiC schema のミスマッチ: SONiC 固有機能 (Dual-ToR mux、warm-reboot state) は OpenConfig path に対応が無く、sonic-mgmt-common の vendor-augmented YANG で表現される。
  • gNMI Set の atomicity: 単一 SetRequest 内の複数 update は SONiC 側で完全 atomic とは限らない。CONFIG_DB の partial commit で transient 状態が見える可能性。replace 操作は model-based-replace-delete-in-mgmt-framework-transformer の HLD 通り、サブツリー単位での差し替えになり、orchagent 側で transient な flap を観察することがある。
  • 証明書回転中の reconnect: controller が証明書を更新した後、client 側 dial を一度切る必要がある場合がある。gNSI による hot swap が対応していれば回避可能。
  • master arbitration: 複数 controller が同時に Set を出すと last-writer-wins になるため、gnmi-master-arbitration の MasterArbitration 拡張を有効化して election token を交換する。

将来計画 / ロードマップ

  • gNxI suite (gNMI / gNOI / gNSI / gRIBI) は OpenConfig コミュニティで継続拡張中。SONiC 側は sonic-gnmi の依存ライブラリ更新で取り込む。
  • gRIBI を経由した RIB 直接注入が議論されており、controller 側で経路を直接 push する用途で SDN ベース fabric の管理が変わる可能性。SONiC では gribi-server の prototype が議論段階。
  • OpenConfig の network-instance / VRF モデルの SONiC 対応は段階的で、未対応 path には vendor augment が並走する。
  • save-on-set (Set 直後に CONFIG_DB を config_db.json へ persist) は long-running deployment では default ON が望ましいが、scale 時の I/O コストがあり opt-in 設計が継続。

関連 RFC / 仕様書

upstream 開発の最新動向

  • sonic-gnmi repo で gNSI authz と certz 取り込み、TLS 認証経路のリファクタが継続。
  • sonic-mgmt-common (Translib / Transformer) で OpenConfig path カバレッジ拡張 PR が頻繁。Routing / BGP / VRF / QoS の path 追加が主軸。
  • Telemetry docker の memory footprint 改善と subscription scale 上限緩和の PR が継続。collector 側 (gnmic、gnxi) も community 主導でツール成熟が進む。
  • SmartSwitch 向け gNMI feedback design (smart-switch-gnmi-feedback-design) が DPU 側 telemetry を含めて議論中。

関連ページ