# SONiC管理フレームワーク SONiC管理フレームワーク(SONiC Management Framework)は、AT&Tが通信サービスのプロビジョニングや管理の自動化に用いていたSDNコントローラー(OpenDaylightの拡張版であるLighty.io)とSONiCを統合するためBroadcomが開発を進め、その後コミュニティ版へアップストリームされた機能である。以後、DellによるCLIの提供など複数の企業により拡張が続けられている。設定の検証・適用・表示やステート情報の取得を、SONiCの機能全体に共通する方法で提供する。(Source: [[@2025__Gihyo__実践SONiC入門 - Chapter 8 SONiCの内部構造：ステートの流れとモジュール連携]] ch.8 §8.9) ## 特徴とアーキテクチャ - NBI(ノースバウンドインターフェース)で扱うオブジェクトを業界標準のYANGモデル(OpenConfig, IETF, IEEE等)で記述する。SONiC独自のYANGモデルにも対応し、モデル間の変換は変換ライブラリ(TransLib)が担う。 - モジュール間でやり取りするデータはConfig Validation Library(CVL)を用いて構文(syntax)・意味(semantic)を検証する。 - RESTサーバーのコードはOpenAPIを使用し自動生成する。 - Redisデータベースへのアクセス(トランザクション)にはCheck-and-Set(CAS)方式を用い、ロックやロールバックには対応しない。SONiC管理フレームワークとCLI(Click)を併用する際は、この特性への注意が必要になる。 構成モジュールは、機能追加・変更時に利用する「ビルドタイム・モジュール」(Pyangコンパイラ、OpenAPIジェネレータ、YGOTジェネレータ)と、起動後に動作する「ランタイム・モジュール」(RESTクライアントSDK、RESTサーバー、gNMIサーバー、TransLib、CVL、Non-DBデータプロバイダー)の2つに分類される。(Source: ch.8 §8.9.1) ## 提供するAPIとランタイムの流れ 提供されるAPIはREST API(主に設定に利用)とgNMI API(主にテレメトリー等の情報取得に利用。gNMIでの設定対応も拡張中)の2種類である。SONiCのREST API定義はブラウザで`https://<sonicのIPアドレス>/ui`にアクセスすると「SONiC REST API explorer」(OpenAPI/Swaggerベース)として参照できる。(Source: ch.8 §8.9.2) ランタイムでは、①RESTサーバーがYANGモデルをもとにした要求を受け取り変換ライブラリ(TransLib)へ渡す、②TransLibがJSON形式のYGOT構造体を共通Appモジュールへ渡す、③共通AppモジュールがDBアクセスモジュール経由でデータベースにアクセスする、④CVLがYANGから生成されたRedis ABNFスキーマを用い構文・意味を検証する、⑤返信は逆のパスを通りSONiCモデルからNBIモデルへ変換されクライアントへ返る、という5段階でリクエストが処理される。(Source: ch.8 §8.9.4) APIを追加する際はYANGモデルまたはOpenAPIスペックのいずれかでオブジェクトを定義する。YANGモデルを用いる場合、Pyangコンパイラ・OpenAPIジェネレータ・YGOTジェネレータにより同一モデルからOpenAPIスペック・REST SDK・REST サーバースタブ・Go-bindオブジェクトを一貫して生成できる利点がある。OpenConfig/IETFなど業界標準モデルを用いる場合はSAI側との差分(deviation)や、AppモジュールがYANGオブジェクトとDBオブジェクトを変換するためのYANGアノテーションファイルが別途必要になる。(Source: ch.8 §8.9.3) ## CLI(Klish)との関係 CLIのユーザーインターフェース部分は、Cisco風の階層的CLIフレームワークであるKlish(Kommand Line Interface Shell、`Clish`のフォーク)で実装され、Redisデータベース等の操作はSONiC管理フレームワークが提供するREST APIを介して行う。ランタイムはCLI→Klish→アクショナー(Actioner。REST要求のBODYを生成)→RESTサーバー→レンダラー(Renderer。JSON応答をJinjaテンプレートでフォーマット)→Klishという経路をたどる。コミュニティ版SONiC.202405時点ではKlishベースCLIの機能は限定的で、商用版と比較して設定・参照可能な項目が少ない。(Source: ch.8 §8.8.3) ## FRR管理フレームワーク SONiC管理フレームワークの拡張機能として、FRRの設定管理を統合するFRR管理フレームワークがある。`frrcfgd`モジュールがCONFIG_DBを通じてFRRを制御することで、RESTCONF・gNMI・CLIといった共通インターフェースやOpenConfigモデルでの設定管理、BGP以外のプロトコル対応を可能にする。CONFIG_DBが設定情報のSSOTであるため、設定変更・設定情報の参照・状態や統計情報の参照は、それぞれ異なるモジュール連携経路をたどる(設定参照はCONFIG_DBから直接、状態参照はSTATE_DBを介さずfrrcfgdがFRR(vtysh)から直接取得)。詳細は[[FRRouting (FRR)]]を参照。(Source: ch.8 §8.9.5) ## 関連 - 実体: [[SONiC]] / [[FRRouting (FRR)]] - 概念: [[データベースを介した疎結合なモジュール連携]] - ソース: [[@2025__Gihyo__実践SONiC入門 - Chapter 8 SONiCの内部構造：ステートの流れとモジュール連携]] ## 出典 - 海老澤健太郎, 『実践SONiC入門』, 技術評論社, 2025, 第8章 §8.8.3, §8.9〜§8.9.5.