Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

tjmtrhs
December 15, 2022

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

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

tjmtrhs

December 15, 2022
Tweet

More Decks by tjmtrhs

Other Decks in Technology

Transcript

  1. モデルを基に本番環境を再現して
    事前に検証可能にする運用サイクル
    ◼ 1
    TIS株式会社 萩原
    NTTコミュニケーションズ株式会社 田島
    ビッグローブ株式会社 滝口・川口・前野
    Okinawa Open Laboratory
    Model Driven Network DevOps Project
    https://www.okinawaopenlabs.org/mdnd
    © 2022 Okinawa Open Laboratory

    View Slide

  2. 課題
    • NWの構成変更で "やってみないとわからない" がなくならない
    • なぜ?
    • 本番環境と全く同じ機材・規模で「完全な検証環境」を用意するのは
    困難
    • 検証環境として再現する範囲が変わった時点で100%の再現にはならない
    • 検証環境には、規模と精度のトレードオフがある
    • 結果として、"システム全体の動作" を事前に検証するのが難しい
    ◼ 2
    "やってみないとわからない" 不確実さを減らすための方法は?
    © 2022 Okinawa Open Laboratory

    View Slide

  3. 目的とアプローチ
    • ターゲット = 既存のネットワーク (Brown field)
    • コンフィグと設定シートで管理されているNW
    • 不確実さを減らすために?
    • 検証環境の規模と精度のトレードオフ
    ➡ 制約の異なるコンテナベースのNWをつかう : "規模"の再現
    • 既存環境の構成情報をモデル化して、同等のネットワークを再現する
    ◼ 3
    従来は難しかった規模(ノード数)のNWを再現して
    "システム全体の動き" を "実際にやって確認" できるようにする
    © 2022 Okinawa Open Laboratory

    View Slide

  4. 規模と精度のトレードオフ
    ハードウェアベース VMベース コンテナベース
    概要 実環境と同じハードをそろえて
    検証環境を作る
    実環境機器と同一OSの
    VM(VNF)をそろえて検証環境を
    作る
    軽量なコンテナ(CNF)を使用す
    る(OS等は実環境と異なる)
    スケール
    (リソース量)
    ×
    モノをそろえるのが難しい

    必要数VMの計算機リソースの確
    保, 仕様によりポート数等の制
    約あるVMも

    CNFはかなり軽量
    構築の早さ 構築・立ち上げに時間がかかる
    (数時間~日単位)
    ソフトウェアがそろっていれば
    それなりにはやい(数十分~時間
    単位)
    ソフトウェアがそろっていれば
    はやい(分~十分単位)
    再現可能な
    範囲

    L1-から上
    ハードウェア機能、
    ベンダ固有機能も可

    L2/L3から上
    使用するソフトウェアで対応す
    る範囲

    L3から上
    共通するプロトコルの動作中心
    Config
    変更の多さ
    ほぼそのまま(同一) 一部修正あり(インタフェース名
    等の修正がある)
    書き換え・書き戻しが必要(ホス
    ト名とパラメータ以外は大幅に
    変わる)
    ◼ 4
    精度
    実環境との機能的な
    ギャップがどれくら
    いあるか?
    規模
    実環境との構造的な
    ギャップがどれくら
    いあるか?
    © 2022 Okinawa Open Laboratory

    View Slide

  5. 規模と精度のトレードオフ
    • 理想…本番環境と同一ハード・同一規模の検証環境
    • コスト的に無理
    • 従来 : 本番環境とある程度同一(連続)的に作れる方法
    • 同じハードを使う
    • 同じソフト(OS; VMベース)を使う
    • ある程度コンフィグ等を流用できるが必要なリソース
    量が多くノード数(サイズ)を拡大しにくい
    • "システム全体の動き" を見たい
    = ノード数(環境サイズ)を拡大したい
    • 軽量なコンテナの利用
    • (現状)コンフィグ等を大幅に書き換える必要がある
    • 大幅に書き換える : そのままだと実環境にフィード
    バックできない
    • 何をもって「同等」のNWと考えるか?
    ◼ 5
    すべて
    書き換え
    一部修正
    ほぼ
    変更なし
    構築の
    早さ
    Config
    変更の多さ

    オーダー
    時間
    オーダー

    オーダー
    アーキテクチャを
    変えて
    全体を再現
    コンテナ
    ベース
    VM
    ベース
    ハードウェア
    ベース
    既存のConfigが
    流用できる範囲
    本プロジェクトの
    ターゲット
    Protocol
    Software
    Hardware
    リソースあたりの
    再現可能ノード数
    再現対象
    © 2022 Okinawa Open Laboratory

    View Slide

  6. アプローチ
    • 実環境の構成情報を抽出してモデル化する
    • ベンダ非依存
    • マルチレイヤ: 複数レイヤ間の関係性をもつ
    • 今回は L1-L3+OSPF
    • 各レイヤでのトポロジ + ノード/インタフェースの属性データ
    • モデルデータを基にした処理の実装
    • 抽出した構成情報を基にした環境構築の自動化 (検証環境の構築)
    • 変更前後のモデルベース差分取得と変更点に対する処理
    ◼ 6
    "システム全体の動き"を再現するために、
    実環境と同等なNWをコンテナベースで再現する
    © 2022 Okinawa Open Laboratory

    View Slide

  7. アプローチ: 基本パターン
    ◼ 7
    As
    is
    To
    be
    Model
    Diff
    Hardware
    Config Topology Data
    モデルデータによる validation
    • ノード間整合性チェック(静的検査)
    • L3 reachability simulation (Batfish)
    • L1リンク障害トポロジパターン生成
    問題を発見してモデルを修正する
    → 実環境へのフィードバック


    © 2022 Okinawa Open Laboratory

    View Slide

  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




    View Slide

  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
    可視化

    View Slide

  10. Demo
    ◼ 10
    © 2022 Okinawa Open Laboratory

    View Slide

  11. © 2022 Okinawa Open Laboratory
    シナリオ
    • 一部のセグメント移転(移動)
    • 移転に伴うネットワークの経路制御変更
    • OSPFの経路再配布での設定ミス
    • 移転後サーバの通信トラブル
    • 従来だと…
    • 異なるトポロジ・縮小したNWでの検証
    • 検証に含まれなかった箇所・パターンは不
    確実なままのこってしまう
    ◼ 11
    "システム全体の動き"の問題を発見できるか?
    どれくらいのコスト(リソース)で可能か?
    サーバ移転
    サーバ移転に伴う
    経路制御
    ➡ OSPFが自動的に変更さ
    れたセグメントへの経路
    を配布してくれるはず…?

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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.

    View Slide

  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

    View Slide

  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:
    差分コンフィグ

    View Slide

  20. © 2022 Okinawa Open Laboratory
    まとめ
    ◼ 20

    View Slide

  21. モデル化とコンテナによる再現
    • 規模と精度のトレードオフの選択
    • コンテナベース ➡ 規模: "システム全体" の動作検証
    • リソース(ハードウェア・ソフトウェア)制約が小さい
    • 試行錯誤の容易さ…構築・検証・破棄のサイクルが高速 (分オーダー)
    • モデル化
    • 実環境(Config)を起点に ➡ 人によるコンフィグの翻訳の排除
    • 実環境と L3/OSPF 観点で同等なNW構成の自動生成
    • フィードバックサイクル
    • モデルベース差分と差分コンフィグ生成
    ◼ 21
    従来は難しかった規模(ノード数)のNWを再現して
    "システム全体の動き" を "実際にやって確認" できるようにする
    © 2022 Okinawa Open Laboratory

    View Slide

  22. 注意点・課題点
    • 「トポロジデータ」を考えたときの属性情報の定義
    • 機器単体を設定するためのデータ定義
    (Yang/OpenConfig) と、トポロジ/ノード間関係定義
    を基にしたデータ定義では、情報の持ち方・考え方が
    変化する。
    • ノード間の関係性から作れる設定はあるが、処理の都
    合上「ノード単体」に埋め込んでしまった方が楽なこ
    ともある。
    • 運用知識と技術知識の両立
    • 既存環境から正しいデータが必ず抽出できるとは限ら
    ない (確認が必要)
    • 実際の設計や運用の知識がないと、得られたデータの
    正しさを確認できない
    • 構成情報の応用(活用)を考えたときに、どんなデータ
    定義になっていると効率が良いか?
    • 管理(management)アクセスの変化とその設定
    • コンテナベースなので直接ノード操作可能
    • 管理アクセス側の設定が抜けると思いがけない動作に
    つながる
    • "名前空間"問題
    • Original/Emulatedでのインタフェース名やトポロジ
    読み替えのオーバーヘッドが発生する。
    • Batfish依存問題
    • 一部 parser 未対応の機能の取り扱い
    • OVS非対応…Emulated環境のL2をどう取り扱うか
    • 境界定義
    • 外部サービス・外部環境とのインタラクションのモデ
    ル化
    ◼ 22
    © 2022 Okinawa Open Laboratory

    View Slide

  23. 発展
    • NW検証のコンテナ化: クラウド系運用プラクティスのとりこみ
    • CI (Continuous Integration), 自動テスト
    • Kubernetes などのプラットフォームをベースにした展開?
    • 対応可能なレイヤ/プロトコルの拡張(モデル拡張)
    • IPv6, BGP
    • End-to-End Flow の取り扱い
    • L4(FW/NAT)? TE?
    • モデルを中心にした既存システムのオペレーション
    • 起点を「既存環境Config」から「モデルデータ」に
    • 宣言的アプローチへのシフト
    ◼ 23
    © 2022 Okinawa Open Laboratory

    View Slide

  24. © 2022 Okinawa Open Laboratory
    将来像
    ◼ 24
    platform
    interface
    実機
    ハードウェア製品
    VM
    ソフトウェア製品
    コンテナ
    ソフトウェア製品
    k8s等のオーケストレータ
    UI
    必要なデータの選択
    可視化・操作
    検査
    システム構成要素の
    関係性を踏まえた
    Validation
    シミュレーション
    実機がなくても
    可能なテスト
    宣言的なシステム運用
    CI/自動テストなど
    ソフトウェア開発やクラウド開発の
    ベストプラクティスのとりこみ
    デプロイ前のテストと予測可能性
    静的な検査・動的なテスト
    練習・トレーニング・育成
    システムの”モデル”を核とした運用プロセス
    CI
    自動テスト
    システム
    構成データ

    View Slide

  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

    View Slide