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

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

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

Transcript

1. © NTT Communications Corporation All Rights Reserved. 1
   ネットワーク設定の抽象化と
   コンテナルータを用いた検証環境の立ち上げ支援
   田島 照久
   teruhisa.tajima@ntt.com
   NTT Communications / Innovation Center
   2023/03/24 NTT Tech Conference 2023
   

   View Slide

2. © NTT Communications Corporation All Rights Reserved. 2
   ネットワーク設定の抽象化と
   コンテナルータを用いた検証環境の立ち上げ支援
   の
   要点3つ
   1. 検証環境を早く立ち上げることでNWの運用を速くしたい
   2. コンテナの設定に必要な変換ロジックを抽象化で解決
   3. システムを作って実際にやってみた
   

   View Slide

3. © NTT Communications Corporation All Rights Reserved. 3
   検証環境の用途は多岐：NTT Com 全社検証網の例
   ◼ 足回りとしての回線
   ⚫ 社内の何らかの案件の検証環境につかう
   ⚫ 拠点AのXXと拠点BのYYを接続したい=まさにキャリアネットワーク
   ◼ ネットワーク・クラウド・セキュリティ技術の検証
   ⚫ Segment Routing, 伝送, Private Cloud, etc.
   ◼ 技術者育成・習熟環境
   

   View Slide

4. © NTT Communications Corporation All Rights Reserved. 4
   ここが遅い？
   ならば早いものを用意する
   今回対象とする検証環境：本番環境の変更に向けた試行錯誤
   本番環境 検証環境
   XXを作りたい
   検証環境を
   立ち上げよう
   試行錯誤
   しよう
   結果を
   反映しよう
   

   View Slide

5. © NTT Communications Corporation All Rights Reserved. 5
   今回の「検証環境」に求めるもの
   実現できる事の事前確認 ＋ 本番デプロイのイテレーションを早く
   1. 素早く立てられること
   ⚫ やってみないとわからない、を早期に解決する
   2. 環境全体が検証できること
   ⚫ 本番と検証の違いは・・・の学習コストを下げる
   3. 機能を絞って検証すること
   ⚫ 単体・統合のレイヤごとに検証を分割する
   1
   2
   2
   3
   

   View Slide

6. © NTT Communications Corporation All Rights Reserved. 6
   なぜこの問題が重要なのか
   ◼ NW特有の事情
   ハードウェアがベース
   ⚫ 可搬性が無い
   ⚫ 再現範囲を絞ってでも
   仮想でスケールさせる必要あり
   ◼ 例えばWebアプリの場合
   既に同じスタックで動作
   ⚫ コンテナ技術等でそもそも本番と検
   証の間に可搬性がある
   本番環境 検証環境
   本番環境
   検証環境
   （仮想）
   

   View Slide

7. © NTT Communications Corporation All Rights Reserved. 7
   仮想環境立ち上げへのアプローチ：コンテナルータ
   1. 素早く立てられること
   ⚫ コンテナルータを用いて環境作成することで時間短縮
   2. 環境全体が検証できること
   ⚫ 軽量なルータで収容効率アップ
   ⚫ 仮想化レイヤーでスケールアウト
   3. 機能を絞って検証すること
   ⚫ L3以上のルーティングに絞る
   ⚫ L2以下の挙動はエミュレーションしにくい
   → 可搬性が無い既存configをどうやって適用するのか
   

   View Slide

8. © NTT Communications Corporation All Rights Reserved. 8
   問題の整理
   右向き →
   • 検証環境を作るときに必要
   • 環境に合わせて読み替える
    左向き
   • 検証内容を適用するときに必要
   • 元の環境のパラメタを補足する
   Hardware Container
   本番環境と検証環境で
   アーキテクチャ・OS・Configいずれも異なる
   本番環境 検証環境
   直接置き換えすると、変換の組み合わせの多さや
   アドホックさがネックになる🤔
   

   View Slide

9. © NTT Communications Corporation All Rights Reserved. 9
   翻訳に使用するモデルデータ
   ◼ 本来configには意図があるはず＝意味を解釈して変換すべき
   ⚫ 言語間の翻訳と同じ
   ◼ Configに依存しないモデルを経由
   ⚫ 決定論的（not 確率論的）に変換する
   ⚫ 入出力「言語」が複数になっても変換テーブルが爆発しない
   Hardware Container
   本番環境 検証環境
   モデル
   データ
   NWの構造を抽象化
   • 各レイヤのトポロジを
   グラフとして表現する
   各環境へ翻訳
   • 各環境の文法をテンプレ
   エンジンで生成する
   

   View Slide

10. © NTT Communications Corporation All Rights Reserved. 10
    モデル化の功罪
    Hardware
    Container
    本番環境 検証環境
    モデル
    データ
    diffが取れる → そこから意図を読み取れる
    → configのsuggestionができる
    Configパースが難しい
    （パーサのバグなど）
    → 何らかの確認が必要
    

    View Slide

11. © NTT Communications Corporation All Rights Reserved. 11
    ここまでのまとめ：解決できそうなこと・できないこと
    ◼ 本番環境へ早くリリースするために、検証環境の立ち上げを早くする
    ⚫ もちろんそのほかにもボトルネックは多い
    ◼ コンテナを使って検証NWを作る
    ⚫ 早い＋スケールする
    ◼ 全体の設計にフォーカスする
    ⚫ L3以上
    ⚫ 特定の機種の検証は棲み分け
    ◼ モデルを介して翻訳する
    ⚫ モデルに表現できない物は捨てられる
    

    View Slide

12. © NTT Communications Corporation All Rights Reserved. 12
    システムを作って、いくつか検証環境を立ち上げてみた
    ◼ デモ用のNW
    ⚫ 6ノード＋9セグメント
    ◼ Com検証網NW
    ⚫ マルチベンダ
    ⚫ 12ノード＋12セグメント
    ⚫ OSPF部分だけを対象
    サーバ移転
    RegionC-RT1上で
    OSPFの経路再配布
    設定ミスにより、
    移転後の経路が
    広報されない！
    

    View Slide

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/
    モデル
    データ
    

    View Slide

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
    

    View Slide

15. © NTT Communications Corporation All Rights Reserved. 15
    ここで補遺：正しく翻訳できているのかは確かめられる
    ◼ 検証環境で何も変更せず入力と出力を比較
    ⚫ 何も変更していないので変更が無ければ
    翻訳が正しいと言える
    ◼ 設定(config)ではなく状態(status)を比較
    ⚫ 例えばRIB(routing table)の差が無い確認
    ⚫ ただしそれなりに面倒
    diff
    show xxx & diff
    課題はこれ↓
    

    View Slide

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の処理が支配的でさら
    なる高速化は可能
    

    View Slide

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の扱い
    

    View Slide

18. © NTT Communications Corporation All Rights Reserved. 18
    今後の発展
    ◼ 1回起動するところはできた
    次は「効率的に」複数回まわすところ
    ◼ コンテナルータとしての選択肢が乏しくOSS (VyOS) 対応へ
    現状はcRPDというプロプライエタリに依存
    ◼ 翻訳の中身の拡充
    OSPFで動くことはわかったので、より複雑なBGPへ拡張中
    ？ !
    

    View Slide

19. © NTT Communications Corporation All Rights Reserved. 19
    まとめ
    1. 検証環境を早く立ち上げることでNWの運用を速くしたい
    2. コンテナの設定に必要な変換ロジックを抽象化で解決
    3. システムを作って実際にやってみた
    本PJは沖縄オープンラボラトリでのTIS株式会社・ビッグローブ株式会
    社との協同検証PJとして実施中です
    実際にシステムの動作様子などはデモ動画があります
    https://youtu.be/xRxpsly1kls
    

    View Slide