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

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

View Slide

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

View Slide

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

View Slide

規模と精度のトレードオフ
ハードウェアベース VMベースコンテナベース
概要実環境と同じハードをそろえて
検証環境を作る
実環境機器と同一OSの
VM(VNF)をそろえて検証環境を
作る
軽量なコンテナ(CNF)を使用す
る(OS等は実環境と異なる)
スケール
(リソース量)
×
モノをそろえるのが難しい
△
必要数VMの計算機リソースの確
保, 仕様によりポート数等の制
約あるVMも
◎
CNFはかなり軽量
構築の早さ構築・立ち上げに時間がかかる
(数時間~日単位)
ソフトウェアがそろっていれば
それなりにはやい(数十分~時間
単位)
ソフトウェアがそろっていれば
はやい(分~十分単位)
再現可能な
範囲
◎
L1-から上
ハードウェア機能、
ベンダ固有機能も可
〇
L2/L3から上
使用するソフトウェアで対応す
る範囲
△
L3から上
共通するプロトコルの動作中心
Config
変更の多さ
ほぼそのまま(同一) 一部修正あり(インタフェース名
等の修正がある)
書き換え・書き戻しが必要(ホス
ト名とパラメータ以外は大幅に
変わる)
◼ 4
精度
実環境との機能的な
ギャップがどれくら
いあるか?
規模
実環境との構造的な
ギャップがどれくら
いあるか?

View Slide

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

View Slide

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

View Slide

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

View Slide

アプローチ: 同等な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
As-is
To-be
Multilayer Topology Data
Converter
(convert table)
静的
検査
L3到達性
シミュレーション
L1 topology
(Given)
L1 topology
Direct
operation
Direct
operation
モデルベース差分
Cisco
Juniper
Arista
① ②
③
④
差分
Config
生成
Config Topology Data Config
Original
as-is config
(Given)
Juniper cRPD
Arista cEOS
Open vSwitch
可視化

View Slide

Demo
◼ 10

View Slide

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

View Slide

シナリオ
① As-Is (現状) モデル作成
② As-Is 仮想環境作成
②' 仮想環境上での検証
③ To-Be (理想) モデル作成
④ To-Be 実環境への適用
◼ 12
”モデル"
L1-L3+OSPF
Topology Data
As
is
To
be
Original Emulated
① ②
④ ③
②'

View Slide

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

①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

View Slide

②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:
①同様
実環境(Original)をコンテナベース環境(Emulated)で再現するため、NWの構造(アーキテクチャ)を変える:
• 使用しているツール・トポロジが変わる(L3以上のみ再現する) ➡ インタフェース名などの識別子を変換する ➡ "名前空間" の変換
• 異なる "名前空間" のトポロジデータは直接比較できない
Converter
Output:
ContainerLab用
コンフィグ
Output/Input:
トポロジ情報(json)
As
is
To
be
Original Emulated

View Slide

◼ 16
!!
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
サーバ移転に伴う経路制御の変更
➡ 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

③To-Be (理想) モデル作成
◼ 18
Output
(Emulated/to-be)
Container
Process:
①同様
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

$ 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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

関連資料
• 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

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

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

tjmtrhs

More Decks by tjmtrhs

Other Decks in Technology

Featured

Transcript