ネットワーク設定の抽象化とコンテナルータを用いた検証環境の立ち上げ支援

保守や拡張作業で本番環境に何らかの変更を加えるとき、事前に別環境で検証したいと考えます。 しかしネットワークの場合においては、検証環境を準備するためのコストが大きく、運用速度のボトルネックになります。 そこで私たちはコンテナルータやオープンソースソフトウェアを組み合わせて、本番環境を検証環境として再現するシステムを作成しました。 システムの中で重要なネットワーク設定の変換と移植については、あらかじめトポロジを抽象化し解決しました。 これにより数分オーダといった短時間で検証環境を用意できるようになりました。

本セッションではシステムの概要と、ネットワーク設定の抽象化を用いた設定の変換について説明します。 また、そもそも検証環境に求められる要件はいくつかの側面があるため、検証環境はどのような要件を満たすべきかについても議論したいです。

Transcript

1. © NTT Communications Corporation All Rights Reserved. 1 ネットワーク設定の抽象化と コンテナルータを用いた検証環境の立ち上げ支援 田島 照久 teruhisa.tajima@ntt.com NTT Communications / Innovation Center 2023/03/24 NTT Tech Conference 2023
2. © NTT Communications Corporation All Rights Reserved. 2 ネットワーク設定の抽象化と コンテナルータを用いた検証環境の立ち上げ支援 の 要点3つ 1. 検証環境を早く立ち上げることでNWの運用を速くしたい 2. コンテナの設定に必要な変換ロジックを抽象化で解決 3. システムを作って実際にやってみた
3. © NTT Communications Corporation All Rights Reserved. 3 検証環境の用途は多岐：NTT Com 全社検証網の例 ◼ 足回りとしての回線 ⚫ 社内の何らかの案件の検証環境につかう ⚫ 拠点AのXXと拠点BのYYを接続したい=まさにキャリアネットワーク ◼ ネットワーク・クラウド・セキュリティ技術の検証 ⚫ Segment Routing, 伝送, Private Cloud, etc. ◼ 技術者育成・習熟環境
4. © NTT Communications Corporation All Rights Reserved. 4 ここが遅い？ ならば早いものを用意する 今回対象とする検証環境：本番環境の変更に向けた試行錯誤 本番環境 検証環境 XXを作りたい 検証環境を 立ち上げよう 試行錯誤 しよう 結果を 反映しよう
5. © NTT Communications Corporation All Rights Reserved. 5 今回の「検証環境」に求めるもの 実現できる事の事前確認 ＋ 本番デプロイのイテレーションを早く 1. 素早く立てられること ⚫ やってみないとわからない、を早期に解決する 2. 環境全体が検証できること ⚫ 本番と検証の違いは・・・の学習コストを下げる 3. 機能を絞って検証すること ⚫ 単体・統合のレイヤごとに検証を分割する 1 2 2 3
6. © NTT Communications Corporation All Rights Reserved. 6 なぜこの問題が重要なのか ◼ NW特有の事情 ハードウェアがベース ⚫ 可搬性が無い ⚫ 再現範囲を絞ってでも 仮想でスケールさせる必要あり ◼ 例えばWebアプリの場合 既に同じスタックで動作 ⚫ コンテナ技術等でそもそも本番と検 証の間に可搬性がある 本番環境 検証環境 本番環境 検証環境 （仮想）
7. © NTT Communications Corporation All Rights Reserved. 7 仮想環境立ち上げへのアプローチ：コンテナルータ 1. 素早く立てられること ⚫ コンテナルータを用いて環境作成することで時間短縮 2. 環境全体が検証できること ⚫ 軽量なルータで収容効率アップ ⚫ 仮想化レイヤーでスケールアウト 3. 機能を絞って検証すること ⚫ L3以上のルーティングに絞る ⚫ L2以下の挙動はエミュレーションしにくい → 可搬性が無い既存configをどうやって適用するのか
8. © NTT Communications Corporation All Rights Reserved. 8 問題の整理 右向き → • 検証環境を作るときに必要 • 環境に合わせて読み替える  左向き • 検証内容を適用するときに必要 • 元の環境のパラメタを補足する Hardware Container 本番環境と検証環境で アーキテクチャ・OS・Configいずれも異なる 本番環境 検証環境 直接置き換えすると、変換の組み合わせの多さや アドホックさがネックになる🤔
9. © NTT Communications Corporation All Rights Reserved. 9 翻訳に使用するモデルデータ ◼ 本来configには意図があるはず＝意味を解釈して変換すべき ⚫ 言語間の翻訳と同じ ◼ Configに依存しないモデルを経由 ⚫ 決定論的（not 確率論的）に変換する ⚫ 入出力「言語」が複数になっても変換テーブルが爆発しない Hardware Container 本番環境 検証環境 モデル データ NWの構造を抽象化 • 各レイヤのトポロジを グラフとして表現する 各環境へ翻訳 • 各環境の文法をテンプレ エンジンで生成する
10. © NTT Communications Corporation All Rights Reserved. 10 モデル化の功罪 Hardware Container 本番環境 検証環境 モデル データ diffが取れる → そこから意図を読み取れる → configのsuggestionができる Configパースが難しい （パーサのバグなど） → 何らかの確認が必要
11. © NTT Communications Corporation All Rights Reserved. 11 ここまでのまとめ：解決できそうなこと・できないこと ◼ 本番環境へ早くリリースするために、検証環境の立ち上げを早くする ⚫ もちろんそのほかにもボトルネックは多い ◼ コンテナを使って検証NWを作る ⚫ 早い＋スケールする ◼ 全体の設計にフォーカスする ⚫ L3以上 ⚫ 特定の機種の検証は棲み分け ◼ モデルを介して翻訳する ⚫ モデルに表現できない物は捨てられる
12. © NTT Communications Corporation All Rights Reserved. 12 システムを作って、いくつか検証環境を立ち上げてみた ◼ デモ用のNW ⚫ 6ノード＋9セグメント ◼ Com検証網NW ⚫ マルチベンダ ⚫ 12ノード＋12セグメント ⚫ OSPF部分だけを対象 サーバ移転 RegionC-RT1上で OSPFの経路再配布 設定ミスにより、 移転後の経路が 広報されない！
13. © NTT Communications Corporation All Rights Reserved. 13 変換の仕組み：モデルのデータ構造 ◼ 各レイヤをグラフとして表現したデータ（RFC 8345） ⚫ L1/L2/L3/OSPFそれぞれのレイヤごとにノードとエッジを持つ ⚫ レイヤ間の関係性をノードの参照・被参照で表現する Layer3 • L3(IPv4)のトポロジ • インターフェースや IP設定から構成される • L1/L2の冗長化は1つの Point-to-MultiPoint Node (Segment)とし て集約される OSPF (Area 0) • OSPF neighbor の トポロジ • L3情報とOSPF設定を 基に neighbor を判定 RFC 8345, A YANG Data Model for Network Topologies, https://datatracker.ietf.org/doc/rfc8345/ モデル データ
14. © NTT Communications Corporation All Rights Reserved. 14 変換の仕組み：名前空間の変換 ◼ それぞれの環境用にモデルデータを読み替え、相互に変換可能にする ⚫ 変換テーブルの自動作成 ⚫ ユニークに採番し 順方向・逆方向に対応 Hardware Container 本番環境 検証環境 モデル データ node: original: regiona-rt1 clab: regiona-rt1 iflist: - original: ge-0/0/0.0 clab: eth1.0 ifDescr: to_Seg-192.168.0.0-30_Ethernet1 - original: ge-0/0/1.0 clab: eth2.0 ifDescr: to_Seg-172.16.0.0-30_Ethernet1 original clab
15. © NTT Communications Corporation All Rights Reserved. 15 ここで補遺：正しく翻訳できているのかは確かめられる ◼ 検証環境で何も変更せず入力と出力を比較 ⚫ 何も変更していないので変更が無ければ 翻訳が正しいと言える ◼ 設定(config)ではなく状態(status)を比較 ⚫ 例えばRIB(routing table)の差が無い確認 ⚫ ただしそれなりに面倒 diff show xxx & diff 課題はこれ↓
16. © NTT Communications Corporation All Rights Reserved. 16 実際に環境を立ててみた ◼ 数分レベルで起動可能 デモ用NW NTT Com検証網 NW 規模 6ノード＋ 9セグメント 12ノード＋ 12セグメント コンテナルータ cRPD cRPD ピークCPU使用率 40% 42% メモリ使用量 2GB 2GB 起動までの合計時間 107sec 139sec （内）本番からモデル生成 14sec 14sec （内）仮想用config生成 93sec 125sec 仮想からモデル生成 41sec 43sec 実行環境はCPU Xeon Silver 4216 (16C/32T) + Mem 64GiB + Ubuntu 22.04 共通コンポーネントの使用量の 方が大きく、この規模だと差が 出ないレベルにスケールする config生成のansible+j2 templateの処理が支配的でさら なる高速化は可能
17. © NTT Communications Corporation All Rights Reserved. 17 やってみて詰まったところ・変換時の諸問題 ◼ インターフェースの命名規則 ⚫ 人間は理解可能だが、正確なマッチングを取るには泥臭い正規表現が必要 ⚫ lo0  lo.0  lo0.0 とか TenGigE  HundredGigabitEthernet とか ◼ 機能差分 ⚫ ルーティングプロトコルのprocess-idという概念の有無 ◼ L1特有の話 ⚫ 実世界のconfigには伝送装置などさらに複雑なレイヤ ◼ 各種実装作り込みハードル ⚫ Configパーサ(Batfish)のバグ解消 ⚫ Container-labのLinux Bridgeが本用途に不向きでOvSの導入 ⚫ management IFの扱い
18. © NTT Communications Corporation All Rights Reserved. 18 今後の発展 ◼ 1回起動するところはできた 次は「効率的に」複数回まわすところ ◼ コンテナルータとしての選択肢が乏しくOSS (VyOS) 対応へ 現状はcRPDというプロプライエタリに依存 ◼ 翻訳の中身の拡充 OSPFで動くことはわかったので、より複雑なBGPへ拡張中 ？ !
19. © NTT Communications Corporation All Rights Reserved. 19 まとめ 1. 検証環境を早く立ち上げることでNWの運用を速くしたい 2. コンテナの設定に必要な変換ロジックを抽象化で解決 3. システムを作って実際にやってみた 本PJは沖縄オープンラボラトリでのTIS株式会社・ビッグローブ株式会 社との協同検証PJとして実施中です 実際にシステムの動作様子などはデモ動画があります https://youtu.be/xRxpsly1kls