コンテンツにスキップ

Reboot / Upgrade の発展トピック

warm / fast / cold reboot の基本パスを押さえた後は、収束時間を縮める「express reboot」、multi-ASIC / chassis 級の同期、in-service upgrade との組合せが論点になる。

ハンドオフ

発展トピック

  • Express reboot: warm reboot のさらに先にある「ASIC を温存したまま OS だけ swap する」設計。fast-reboot-flow-improvements と express-reboot HLD を組み合わせて、SAI 状態の export / import と syncd の handover を最小ダウンタイムで行う。
  • System-wide warm reboot: 単一 SONiC instance ではなく、複数 ASIC / chassis 全体を 1 回の手順で warm reboot する。multi-asic-warm-reboot と組み合わせて line card 順序や Supervisor のロールを設計する。
  • gNOI 駆動 upgrade: gnoi.os.Install / Activate で controller から SONiC イメージを投入し、warm/fast reboot を制御 plane から発火。手動 ssh 不要化と監査ログ統合が利点。
  • graceful drain & restore: reboot 前に BGP / BFD を drain し、ECMP から外れた状態で reboot する手順。config bgp shutdown all / reliable-tsa と組合せて切替の transient を避ける。
  • Warm reboot 中の orch 状態: warm-restart 対応 daemon (bgpd, swssconfig, syncd, teamd, lldpd 等) の WARM_RESTART_TABLE ステートマシン。reconciliation timeout の管理が要点。
  • 2-stage reboot: kernel kexec → SONiC 初期化 → 経路収束、を時系列で計測し、各 stage の wall clock を切り分けると改善ポイントが見える。

Express reboot の内部設計

Express reboot は warm reboot の延長で、SAI 状態と data plane を保持したまま control plane だけ swap する。鍵となるのは (1) syncd の SAI object handle dump と新 image の syncd での再 attach、(2) orchagent の internal cache を APPL_STATE_DB 経由でリビルド、(3) bgpd の GR/LLGR による経路再学習を上位 plane 側でブロックしない、という 3 つの同期点。期待ダウンタイムは < 1 秒 (data plane forward 停止時間) であり、warm reboot (数秒〜十数秒) より大幅に短い。

実装の依存は ASIC SDK 側の sai_switch_attribute_t::SAI_SWITCH_ATTR_FAST_API_ENABLE と、SDK が持つ shared memory hand-off API。これに対応していない platform では express reboot は不可。

graceful drain & TSA 連携

reboot 前に BGP / BFD を drain する手順は reliable-tsa (Traffic Shift Away) HLD で形式化されている。config bgp shutdown all だけでは ECMP から外れるまでに peer 側の hold timer 切れを待つため、graceful-shutdown community (RFC 8326) を付与して即時 deprefer させる流れが推奨される。drain 後の reboot で transient を最小化できる。

逆に reboot 後の reliable-tso (Traffic Shift Over) は、forwarding が確立してから順に peer に announce 再開する。SONiC では BGP_DEVICE_GLOBAL.tsa_enabled を切り替えるだけで template 経由で route-map 適用される設計。

既知の制約と回避方法

  • Warm reboot 中の経路 stale: BGP graceful restart が機能しないと FIB が古いまま残り、収束後にループや誤転送が起こる。FRR 側 GR / LLGR 設定と peer 側互換を必ず確認する。
  • Fast reboot で counter リセット: fast reboot は ASIC reset を伴うため、COUNTERS_DB の累積値が 0 に戻る。telemetry collector 側で counter rollover として誤検出する事例がある。
  • Express reboot の platform 依存: SAI capability に依存し、対応 ASIC が限られる。実機サポート状況を sonic-platform 配下の sai profile / platform docs と照合する。
  • Multi-ASIC reboot の順序: Supervisor → Line card の順を間違えると Chassis DB の整合が崩れる。config chassis modules shutdown / startup の順序を厳守する。

将来計画 / ロードマップ

  • Express reboot の community 対応拡大と SAI attribute 標準化が継続テーマ。
  • gNOI / gNSI 経由の upgrade orchestration が enterprise 運用で標準化方向。手動手順の自動化と監査トレースの統合が論点。
  • Smart switch / DASH 構成 (13) では DPU 側の独立した reboot 経路が追加され、NPU と DPU の協調 reboot の設計が future work。

関連 RFC / 仕様書

upstream 開発の最新動向

  • sonic-buildimage で fast-reboot / warm-reboot script の logging / status report 改善 PR が継続。stage ごとの elapsed time 出力で運用デバッグが容易になる。
  • sonic-swss の orch 群で warm restart reconciliation のタイムアウトと race condition 修正 PR が定期的に入る。
  • DASH / SmartSwitch 関連で DPU 独立 reboot のサポート議論が進行中。NPU 側 reboot との同期がどこまで required かは scenario ごとに分岐。

トラブルシュート観点

  • warm reboot 後に経路が一部欠落するときは、WARM_RESTART_TABLE|<daemon> の state が reconciled まで到達したかを確認する。bgp daemon が restored 止まりだと FRR の GR 受信側で遅延しているサイン。
  • syncd handover で失敗する場合、/var/log/syslog の syncd: brcm_sai/mlnx_sai 等 SAI vendor log と、syncd.sh の elapsed time を点検する。config save 前 / 後の CONFIG_DB.json 差分も復旧時に役立つ。
  • gNOI Install/Activate の失敗時は sonic-installer list で image slot を確認し、必要なら sonic-installer set-default <prev> で前 image に戻して reboot。

検証パスとラボ要件

  • VS lab で warm reboot を再現するときは、docker exec swss supervisorctl restart all ではなく sonic-installer 経由の本物 warm reboot path を pretest_warm_reboot.sh で実行する。orchagent reconciliation 動作が VS でも観察可能。
  • chassis 級は sonic-mgmt の chassis_reboot test suite が CHASSIS_APP_DB の module_state 遷移を assertion している。

関連ページ (追補)

関連ページ