モデルを基に本番環境を再現して事前に検証可能にする運用サイクル

運用業務では、システムの変更の前にあらかじめ動作確認が必要になります。しかしリソースなどの制約で十分な検証環境を構築することが難しい場合があります。
我々は既存のネットワークの構成情報をモデル化し、そこからコンテナベースの検証環境を再構成できるようにしました。本発表ではそのシステムの概要と、不確実性を減らす運用業務の流れを提案します。

Transcript

1. モデルを基に本番環境を再現して 事前に検証可能にする運用サイクル ◼ 1 TIS株式会社 萩原 NTTコミュニケーションズ株式会社 田島 ビッグローブ株式会社 滝口・川口・前野 Okinawa Open Laboratory Model Driven Network DevOps Project https://www.okinawaopenlabs.org/mdnd © 2022 Okinawa Open Laboratory
2. 課題 • NWの構成変更で "やってみないとわからない" がなくならない • なぜ? • 本番環境と全く同じ機材・規模で「完全な検証環境」を用意するのは 困難 • 検証環境として再現する範囲が変わった時点で100%の再現にはならない • 検証環境には、規模と精度のトレードオフがある • 結果として、"システム全体の動作" を事前に検証するのが難しい ◼ 2 "やってみないとわからない" 不確実さを減らすための方法は? © 2022 Okinawa Open Laboratory
3. 目的とアプローチ • ターゲット = 既存のネットワーク (Brown field) • コンフィグと設定シートで管理されているNW • 不確実さを減らすために? • 検証環境の規模と精度のトレードオフ ➡ 制約の異なるコンテナベースのNWをつかう : "規模"の再現 • 既存環境の構成情報をモデル化して、同等のネットワークを再現する ◼ 3 従来は難しかった規模(ノード数)のNWを再現して "システム全体の動き" を "実際にやって確認" できるようにする © 2022 Okinawa Open Laboratory
4. 規模と精度のトレードオフ ハードウェアベース VMベース コンテナベース 概要 実環境と同じハードをそろえて 検証環境を作る 実環境機器と同一OSの VM(VNF)をそろえて検証環境を 作る 軽量なコンテナ(CNF)を使用す る(OS等は実環境と異なる) スケール (リソース量) × モノをそろえるのが難しい △ 必要数VMの計算機リソースの確 保, 仕様によりポート数等の制 約あるVMも ◎ CNFはかなり軽量 構築の早さ 構築・立ち上げに時間がかかる (数時間~日単位) ソフトウェアがそろっていれば それなりにはやい(数十分~時間 単位) ソフトウェアがそろっていれば はやい(分~十分単位) 再現可能な 範囲 ◎ L1-から上 ハードウェア機能、 ベンダ固有機能も可 〇 L2/L3から上 使用するソフトウェアで対応す る範囲 △ L3から上 共通するプロトコルの動作中心 Config 変更の多さ ほぼそのまま(同一) 一部修正あり(インタフェース名 等の修正がある) 書き換え・書き戻しが必要(ホス ト名とパラメータ以外は大幅に 変わる) ◼ 4 精度 実環境との機能的な ギャップがどれくら いあるか? 規模 実環境との構造的な ギャップがどれくら いあるか? © 2022 Okinawa Open Laboratory
5. 規模と精度のトレードオフ • 理想…本番環境と同一ハード・同一規模の検証環境 • コスト的に無理 • 従来 : 本番環境とある程度同一(連続)的に作れる方法 • 同じハードを使う • 同じソフト(OS; VMベース)を使う • ある程度コンフィグ等を流用できるが必要なリソース 量が多くノード数(サイズ)を拡大しにくい • "システム全体の動き" を見たい = ノード数(環境サイズ)を拡大したい • 軽量なコンテナの利用 • (現状)コンフィグ等を大幅に書き換える必要がある • 大幅に書き換える : そのままだと実環境にフィード バックできない • 何をもって「同等」のNWと考えるか? ◼ 5 すべて 書き換え 一部修正 ほぼ 変更なし 構築の 早さ Config 変更の多さ 分 オーダー 時間 オーダー 日 オーダー アーキテクチャを 変えて 全体を再現 コンテナ ベース VM ベース ハードウェア ベース 既存のConfigが 流用できる範囲 本プロジェクトの ターゲット Protocol Software Hardware リソースあたりの 再現可能ノード数 再現対象 © 2022 Okinawa Open Laboratory
6. アプローチ • 実環境の構成情報を抽出してモデル化する • ベンダ非依存 • マルチレイヤ: 複数レイヤ間の関係性をもつ • 今回は L1-L3+OSPF • 各レイヤでのトポロジ + ノード/インタフェースの属性データ • モデルデータを基にした処理の実装 • 抽出した構成情報を基にした環境構築の自動化 (検証環境の構築) • 変更前後のモデルベース差分取得と変更点に対する処理 ◼ 6 "システム全体の動き"を再現するために、 実環境と同等なNWをコンテナベースで再現する © 2022 Okinawa Open Laboratory
7. アプローチ: 基本パターン ◼ 7 As is To be Model Diff Hardware Config Topology Data モデルデータによる validation • ノード間整合性チェック(静的検査) • L3 reachability simulation (Batfish) • L1リンク障害トポロジパターン生成 問題を発見してモデルを修正する → 実環境へのフィードバック ① ② © 2022 Okinawa Open Laboratory
8. © 2022 Okinawa Open Laboratory アプローチ: 同等なNWの再現 ◼ 8 ？ !! As is To be Original Env. Emulated Env. "やってみないとわからない" 実際にやって確認する Model Diff Model Diff Convert Convert Hardware Container Config Topology Data Config ① ④ ② ③
9. © 2022 Okinawa Open Laboratory システム構成 ◼ 9 As-is To-be Multilayer Topology Data Converter (convert table) 静的 検査 L3到達性 シミュレーション L1 topology (Given) L1 topology Direct operation Direct operation モデルベース差分 Cisco Juniper Arista ① ② ③ ④ 差分 Config 生成 Original Env. Emulated Env. Config Topology Data Config Original as-is config (Given) Juniper cRPD Arista cEOS Open vSwitch 可視化
10. Demo ◼ 10 © 2022 Okinawa Open Laboratory
11. © 2022 Okinawa Open Laboratory シナリオ • 一部のセグメント移転(移動) • 移転に伴うネットワークの経路制御変更 • OSPFの経路再配布での設定ミス • 移転後サーバの通信トラブル • 従来だと… • 異なるトポロジ・縮小したNWでの検証 • 検証に含まれなかった箇所・パターンは不 確実なままのこってしまう ◼ 11 "システム全体の動き"の問題を発見できるか? どれくらいのコスト(リソース)で可能か? サーバ移転 サーバ移転に伴う 経路制御 ➡ OSPFが自動的に変更さ れたセグメントへの経路 を配布してくれるはず…?
12. シナリオ ① As-Is (現状) モデル作成 ② As-Is 仮想環境作成 ②' 仮想環境上での検証 ③ To-Be (理想) モデル作成 ④ To-Be 実環境への適用 ◼ 12 ”モデル" L1-L3+OSPF Topology Data As is To be Original Emulated ① ② ④ ③ ②' © 2022 Okinawa Open Laboratory
13. © 2022 Okinawa Open Laboratory Original Env. ①As-Is (現状) モデル作成 ◼ 13 Input: NW機器設定ファイル 現状使っているもの (original/as-is) Input: 物理トポロジ情報(json) Process: Batfish+自製ツール L1-L3+OSPF設定情報の抽出と 各レイヤのトポロジ・ ノード属性データの組み立て Output: マルチレイヤのトポロジデータ(RFC8345) 各レイヤ内およびレイヤ間の ノード関係性+ノード属性情報 (original/as-is) 可視化 Hardware デモでは Interface description から自動生成 Descr 変換 As is To be Original Emulated
14. ①As-Is (現状) モデル作成 ◼ 14 Original/as-is Topology data L1-L3 + OSPF トポロジ情報や ノード・インタフェースの 属性情報を持つ Layer3 • L3(IPv4)のトポロジ • L1-L2の情報を基に、L1/L2の冗 長化は1つのP2MP Node (Segment)として集約される OSPF (Area 0) • OSPF neighbor のトポロジ • L3情報+OSPFプロセス/インタ フェース設定を基に neighbor を判定 As is To be Original Emulated © 2022 Okinawa Open Laboratory
15. © 2022 Okinawa Open Laboratory ②As-Is 仮想環境作成 ◼ 15 Input: トポロジデータ (original/as-is) Output トポロジデータ (Emulated/as-is) Process: "名前空間"の変換 Process: コンテナ用 コンフィグ生成 Output/Input: コンテナ(CNF)用コンフィグ (emulated/as-is) Process: cLabコンフィグ生成 データ生成 Outputを使って Emulated env を 構築・起動する (ContainerLab) Container Process: Batfish+自製ツール ①同様 Original Env. Emulated Env. 実環境(Original)をコンテナベース環境(Emulated)で再現するため、NWの構造(アーキテクチャ)を変える: • 使用しているツール・トポロジが変わる(L3以上のみ再現する) ➡ インタフェース名などの識別子を変換する ➡ "名前空間" の変換 • 異なる "名前空間" のトポロジデータは直接比較できない Converter Output: ContainerLab用 コンフィグ Output/Input: トポロジ情報(json) As is To be Original Emulated
16. © 2022 Okinawa Open Laboratory ②' 仮想環境上での検証 ◼ 16 !! Original Env. Emulated Env. L1/L2トポロジ、 使用するソフトウェアは異なるが L3-OSPF観点で見ると 現状 (as-is) と 同等のネットワーク "システム全体の動き"の問題を発見できるか? どれくらいのコスト(リソース)で可能か? As-is To-be "システム全体の"動作確認・問題探索 • OSPFの状態確認 • 最終的なルーティングテーブルの確認 • L3 reachabilityチェック(ping/traceroute) 問題の修正 "システム全体の"動作の再確認 今回のデモ: 1-2分程度で検証可能になる (約10ノード) 1台のサーバ(16C/32T, Mem64GB)でも数十ノード規模のNWを分オーダーで構築可能 Hardware Container As is To be Original Emulated
17. ②' 仮想環境上での検証 ◼ 17 サーバ移転に伴う経路制御の変更 ➡ OSPF再配布設定の修正 configure set policy-options policy-statement ospf-redistribute from protocol direct set policy-options policy-statement ospf-redistribute from protocol static set policy-options policy-statement ospf-redistribute then accept set protocols ospf export ospf-redistribute 動的経路制御や 経路再配布などの動作は、 構成・状況によって変化するため 正確に予測したり 事前に問題に気付くには 知識や経験が必要 !! "システム全体"を再現し、 動作を検証することで 問題を発見・対処し 不確実さを減らす サーバへの通信トラブル発見 原因調査 As is To be Original Emulated root@regionb-svr01:/# traceroute 192.168.100.10 traceroute to 192.168.100.10 (192.168.100.10), 30 hops max, 60 byte packets 1 192.168.254.1 (192.168.254.1) 4.540 ms 3.914 ms 4.254 ms 2 192.168.1.1 (192.168.1.1) 5.653 ms 4.949 ms 5.266 ms 3 172.16.0.1 (172.16.0.1) 6.726 ms 6.818 ms 6.645 ms 4 192.168.0.2 (192.168.0.2) 8.979 ms 9.168 ms 8.845 ms 5 192.168.0.2 (192.168.0.2) 3069.192 ms !H 3069.168 ms !H 3069.147 ms !H サーバへの通信 ping 196.168.100.10 移転サーバ 192.168.100.10 ノードは すべて コンテナ Emulated Env.
18. © 2022 Okinawa Open Laboratory ③To-Be (理想) モデル作成 ◼ 18 Output トポロジデータ (Emulated/to-be) Container Process: Batfish+自製ツール ①同様 Emulated Env. Input: トポロジ情報(json) Config 保存 修正後 (to-be) Output/Input: コンテナ(CNF)用コンフィグ (emulated/to-be) 処理対象にするコンフィグが 異なる(as-is/to-be)だけで ②と同様 As is To be Original Emulated
19. © 2022 Okinawa Open Laboratory $ bash demo_step4.sh [ regionc-rt1, router ospf 65000 redistribute connected metric 1 metric-type 2 ] [ regionc-rt1, router ospf 65000 redistribute static metric 1 metric-type 2 ] Original Env. ④To-Be 実環境への適用 ◼ 19 Emulated Env. 同じ"名前空間"であれば 新旧(as-is/to-be)の比較(diff)ができる Input: トポロジデータ (to-be) Input: トポロジデータ (as-is) Process: Model diff Process: 差分情報の埋め込み Process: 差分コンフィグ生成 Output: トポロジデータ (差分情報) 可視化 実環境 (original env) への フィードバック ➡ 既存の運用方針に従う As is To be Original Emulated Hardware Output: 差分コンフィグ
20. © 2022 Okinawa Open Laboratory まとめ ◼ 20
21. モデル化とコンテナによる再現 • 規模と精度のトレードオフの選択 • コンテナベース ➡ 規模: "システム全体" の動作検証 • リソース(ハードウェア・ソフトウェア)制約が小さい • 試行錯誤の容易さ…構築・検証・破棄のサイクルが高速 (分オーダー) • モデル化 • 実環境(Config)を起点に ➡ 人によるコンフィグの翻訳の排除 • 実環境と L3/OSPF 観点で同等なNW構成の自動生成 • フィードバックサイクル • モデルベース差分と差分コンフィグ生成 ◼ 21 従来は難しかった規模(ノード数)のNWを再現して "システム全体の動き" を "実際にやって確認" できるようにする © 2022 Okinawa Open Laboratory
22. 注意点・課題点 • 「トポロジデータ」を考えたときの属性情報の定義 • 機器単体を設定するためのデータ定義 (Yang/OpenConfig) と、トポロジ/ノード間関係定義 を基にしたデータ定義では、情報の持ち方・考え方が 変化する。 • ノード間の関係性から作れる設定はあるが、処理の都 合上「ノード単体」に埋め込んでしまった方が楽なこ ともある。 • 運用知識と技術知識の両立 • 既存環境から正しいデータが必ず抽出できるとは限ら ない (確認が必要) • 実際の設計や運用の知識がないと、得られたデータの 正しさを確認できない • 構成情報の応用(活用)を考えたときに、どんなデータ 定義になっていると効率が良いか? • 管理(management)アクセスの変化とその設定 • コンテナベースなので直接ノード操作可能 • 管理アクセス側の設定が抜けると思いがけない動作に つながる • "名前空間"問題 • Original/Emulatedでのインタフェース名やトポロジ 読み替えのオーバーヘッドが発生する。 • Batfish依存問題 • 一部 parser 未対応の機能の取り扱い • OVS非対応…Emulated環境のL2をどう取り扱うか • 境界定義 • 外部サービス・外部環境とのインタラクションのモデ ル化 ◼ 22 © 2022 Okinawa Open Laboratory
23. 発展 • NW検証のコンテナ化: クラウド系運用プラクティスのとりこみ • CI (Continuous Integration), 自動テスト • Kubernetes などのプラットフォームをベースにした展開? • 対応可能なレイヤ/プロトコルの拡張(モデル拡張) • IPv6, BGP • End-to-End Flow の取り扱い • L4(FW/NAT)? TE? • モデルを中心にした既存システムのオペレーション • 起点を「既存環境Config」から「モデルデータ」に • 宣言的アプローチへのシフト ◼ 23 © 2022 Okinawa Open Laboratory
24. © 2022 Okinawa Open Laboratory 将来像 ◼ 24 platform interface 実機 ハードウェア製品 VM ソフトウェア製品 コンテナ ソフトウェア製品 k8s等のオーケストレータ UI 必要なデータの選択 可視化・操作 検査 システム構成要素の 関係性を踏まえた Validation シミュレーション 実機がなくても 可能なテスト 宣言的なシステム運用 CI/自動テストなど ソフトウェア開発やクラウド開発の ベストプラクティスのとりこみ デプロイ前のテストと予測可能性 静的な検査・動的なテスト 練習・トレーニング・育成 システムの”モデル”を核とした運用プロセス CI 自動テスト システム 構成データ
25. 関連資料 • Project Information • Model Driven Network DevOps | 沖縄オープンラボラトリ https://www.okinawaopenlabs.org/mdnd • NWのモデルベース検査と障害シミュレーションのデモンストレーション - YouTube https://youtu.be/wu9IWRbiKKU • ool-mddo – Github https://github.com/ool-mddo • NW運用におけるモデル定義とReconciliation Loopへの挑戦 - Speaker Deck https://speakerdeck.com/tjmtrhs/nwyun-yong-niokerumoderuding-yi-toreconciliation-loophefalsetiao-zhan • NTT Tech Conference 2022 https://ntt-developers.github.io/ntt-tech-conference/2022/ • 沖縄オープンラボラトリ Model Driven Network DevOps (MDDO) Project の紹介 https://enog.jp/wordpress/wp-content/uploads/2022/06/20220610_enog74_takiguchi.pdf • ENOG74 Meeting https://enog.jp/archives/2572 • 機器設定ファイルからのトポロジモデル抽出による机上検査を含めたネットワーク設計支援システム https://ken.ieice.org/ken/paper/20220708FCkR/ • 電子情報通信学会 ICM研究会 (2022/7月) https://ken.ieice.org/ken/program/index.php?tgs_regid=2999890161ea46d8a46d7d0ab86457b95ea553f8b858d0678bf9a3535b 3e8b1d&tgid=IEICE-ICM © 2022 Okinawa Open Laboratory ◼ 25