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

拠点間ネットワークでの "利用者視点の" ネットワークテストシステム適用 / ENOG50-N...

拠点間ネットワークでの "利用者視点の" ネットワークテストシステム適用 / ENOG50-NWTestSys

ENOG50 Meeting 開催のお知らせ – Echigo Network Operators' Group
http://enog.jp/archives/1865

m.hagiwara

May 20, 2018
Tweet

More Decks by m.hagiwara

Other Decks in Technology

Transcript

  1. おさらい 2 Fy2016 Fy2017 ENOG45 2017/06/23 ENOG50 2018/05/18 物理構成操作を含めた ネットワーク受け入れテスト

    自動化の試み ENOG45 Meeting を開催しました http://enog.jp/archives/1671 実際に使ってみよう! ローカル環境での検証
  2. サービス提供のボトルネック? サーバ/アプリ ネットワーク 設定 各種プロビジョナ普及 プロビジョナ発展中 テスト ⚫ テストコード/xSpec ⚫

    各種テストツール ⚫ CI/CDサービス ⚫ 出張 ⚫ 人海戦術 ⚫ 温かみのある手作業 5 NWテストの自動化によりボトルネック解消
  3. NWのテストは自動化が進まない ◼物理機器の各種作業が必要 ◼設置場所が遠隔地 ◼物理配線の変更 ◼複数機器にまたがる操作手順 ◼テスト対象の組み合わせ爆発 7 ユースケースによる 「受け入れテスト」 (ソフトウェア開発の知見を拝借)

    NWは繋がるもの 届きさえすれば中の設定は画一的 テストも1つに着目、ツールも色々 NWは繋げるもの 色々な機器の整合性を取る必要がある… テスト? 現地の人手作業…
  4. NWのテスト? ◼電子工作のテスト ◼ネットワークのテスト 8 テスト対象 NW Test Scenario Electronic boards

    tests http://www.astrosurf.com/audine/English/cisup2.htm テストの操作手順を記述 指示を受けて 計測するシステム “Probe”を 動的に接続
  5. NWテスト自動化のしくみ(TesterSet) 9 L3SW FW1 (Act) FW2 (Pasv) L2SW1 L2SW2 OFS1

    OVS テスト用 ノード Test Scenario (Cucumber) NetTester テスト対象NW “Probe” “回線切断”を OpenFlowで実装
  6. PoC状況設定 11 発注者 要件定義 NW基本設計 NW詳細設計 構築 構築指示 納品 受入テスト

    実施 受入テスト 作成 構築担当者 ヨーヨーダイン社 要件定義で合意したとおりに、 発注者の業務が行えるような NWが構築されているか? (「ヨーヨーダイン社」「タジマックス通信工業社」は架空の企業名です) タジマックス通信工業社
  7. PC テスト対象NW(論理) 12 内部LAN SSL VPN DNS 資産 管理 テスト

    環境 PC PC 10.10.10.0/24 外部LAN 203.0.1.113.0/29 Internet 198.51.100.94 内部LAN 192.168.1.0/24 タジマックス通信工業社 ヨーヨーダイン社 タジマックス社はVPNで 接続して共同開発を行う DMZ 10.10.0.0/24 PC PC PC NAT https://www.jitec.ipa.go.jp/1_04hanni_sukiru/mon dai_kaitou_2013h25_2/2013h25a_nw_pm1_qs.pdf 平成25年度 ネットワークスペシャリスト試験の問題を もとに、架空の中小企業ネットワークとして設定 (「ヨーヨーダイン社」「タジマックス通信工業社」は架 空の企業名です)
  8. ふるまい=テストシナリオ例 13 Feature: リモート開発環境への安定したアクセス タジマックス通信工業社の社員として ヨーヨーダイン社内の開発環境に安定してアクセスしたい なぜならリモート作業を日常的に行うから Scenario: リンク障害発生でもリモート接続が切れない Given

    ヨーヨーダイン社のDMZ内部のVPNサーバ And タジマックス工業のPCをVPNクライアントに And ヨーヨーダイン社のサーバにVPN経由でリモートアクセスして作業 When “FW1” と “L2SW1” 間にリンク障害が発生 Then リモート接続が切れていない https://github.com/net-tester/examples/blob/feature/ood_demo/features/tcp_fw1_l2sw1_linkdown.feature
  9. テスト用ノード生成と配置 14 L3SW FW1 (Act) FW2 (Pasv) L2SW1 L2SW2 OFS1

    OVS vpn_server 10.10.0.11/24 port 9 port 2 OpenFlow Switchを Patch Panel として制御する "patch panel" 設定 (テスト用ノードの配置設定)
  10. テスト対象NWの物理構成操作 15 L3SW FW1 (Act) FW2 (Pasv) L2SW1 L2SW2 OFS1

    OVS port 15 port 14 vpn_server tajimax_pc FW状態(Act/Pasv)変化 FW1-L2SW1間 リンクダウン/リンクアップ操作 PoCでは単純なup/downのみ。 OpenFlowルールで設定入れ ることも原理的には可能
  11. ねらい 18 適用前 繋げて! 設定うまくで きてる?? 終わったよ ちゃんと つながるか 確かめないと

    … ? どこが悪い のだろう… 適用後 うまく つながらない んだけど!! 繋げて! 全パターン テストしたから 確実 終わったよ 安心して使える 利用者 運用者 利用者 運用者
  12. コンポーネント疎結合化と役割分担 22 Test Scenario (Cucumber) テスト対象NW tcp/3000 (REST API) テストシナリオ

    実行API テストシナリオ 実行サーバ NetTester (拠点B) NetTester (拠点A) NetTester (拠点D) NetTester (拠点C) “Controller” (Stateful) “Worker” (Stateless)
  13. 他システムとの連携 ◼NorthBoundとしてのテストシナリオ実行のサービス化 ◼テストシナリオを実行するAPI層を提供 ◼テスト自体を提供するサービスとして疎結合化 24 Test Scenario (Cucumber) テスト対象NW tcp/3000

    (REST API) 他システム REST API テストシナリオ 実行API テストシナリオ 実行サーバ NetTester (拠点B) NetTester (拠点A) NetTester (拠点D) NetTester (拠点C)
  14. テストシナリオ 実行サーバ 動作の全体像 25 25 NetTester Server 1 OFS (Pica8)

    テスト対象 ネットワーク (利用者セグメント) tcp/3000 (REST API) テストシステム用 セグメント Operator (テスト実行者) ssh (CLI) 拠点1 各拠点 操作シナリオ 記述 (RubyCucumber) OFS (OVS) Test Nodes (NetNS) TestNode起動 コマンド実行 パッチ実行 Trema起動 NetTester Server N …… TestNode起動 コマンド実行 拠点N テストコマンドによる TestNode間の トラフィック テストシナリオ実行 Test Scenario 他システム REST API
  15. テストシナリオ 実行サーバ 見え方 26 26 テスト対象 ネットワーク (利用者セグメント) Operator (テスト実行者)

    ssh (CLI) 拠点1 各拠点 操作シナリオ 記述 (RubyCucumber) Test Nodes …… 拠点N Test Scenario 他システム REST API Test Nodes
  16. テスト設定 ◼Target → VPLS網 ◼ユーザ視点で見るとL2 ◼テストに必要なパラメータ ◼ユーザに払い出すL2内でのテスト用ノードのIP/MAC ◼パラメータポリシ ◼今回はあえて固定 ◼

    IP: 利用者が使うアドレスと被らないIPを拠点ごとに確保 ◼ MAC: 固定 ◼Teardown問題, 障害リスクの最小化 ◼ 稼働中機器の状態変更をは最低限におさえる → テスタ側はテスト対象の状態をなるべく変えない 27
  17. 1. テストシナリオ実行要求 28 28 Test Scenario NetTester Server 1 OFS

    (Pica8) テスト対象 ネットワーク (SOで作成した 利用者セグメント) テストシナリオ 実行サーバ tcp/3000 (REST API) テストシステム用 セグメント Operator (テスト実行者) ssh (CLI) 拠点1 各拠点 操作シナリオ 記述 (RubyCucumber) NetTester Server N …… 拠点N 拠点:1…N テスト内容:ping テストシナリオ実行
  18. 2. 各拠点を初期化 29 29 Test Scenario NetTester Server 1 OFS

    (Pica8) テスト対象 ネットワーク (SOで作成した 利用者セグメント) テストシナリオ 実行サーバ tcp/3000 (REST API) テストシステム用 セグメント Operator (テスト実行者) 拠点1 各拠点 操作シナリオ 記述 (RubyCucumber) OFS (OVS) NetTester Server N …… 拠点N 各拠点初期化 NetTester等 コンポーネントの初期化 初期化 Trema起動
  19. 3. 各拠点にノード作成 30 30 Test Scenario NetTester Server 1 OFS

    (Pica8) テスト対象 ネットワーク (SOで作成した 利用者セグメント) テストシナリオ 実行サーバ tcp/3000 (REST API) テストシステム用 セグメント Operator (テスト実行者) 拠点1 各拠点 操作シナリオ 記述 (RubyCucumber) OFS (OVS) Test Nodes (NetNS) NetTester Server N …… 拠点N ノード作成・ テスト対象NWへ接続 拠点1にAAを作成 拠点1にBBを作成 拠点NにXXを作成 拠点NにYYを作成 TestNode起動 TestNode起動 パッチ実行
  20. 4. 各拠点でコマンド実行 31 31 Test Scenario NetTester Server 1 OFS

    (Pica8) テスト対象 ネットワーク (SOで作成した 利用者セグメント) テストシナリオ 実行サーバ tcp/3000 (REST API) テストシステム用 セグメント Operator (テスト実行者) 拠点1 各拠点 操作シナリオ 記述 (RubyCucumber) OFS (OVS) Test Nodes (NetNS) NetTester Server N …… 拠点N 拠点1のAAで 「ping XX」を実行 拠点1のBBで 「ping YY」を実行 各ノードでコマンド実行 コマンド実行 コマンド実行 テストコマンドによる TestNode間の トラフィック
  21. 5. 各拠点からコマンド実行結果を回収 32 32 Test Scenario NetTester Server 1 OFS

    (Pica8) テスト対象 ネットワーク (SOで作成した 利用者セグメント) テストシナリオ 実行サーバ tcp/3000 (REST API) テストシステム用 セグメント Operator (テスト実行者) 拠点1 各拠点 操作シナリオ 記述 (RubyCucumber) OFS (OVS) Test Nodes (NetNS) NetTester Server N …… 実行結果回収 拠点N AAのログ回収 BBのログ回収 保存してあった 実行結果を送信
  22. 6. テスト成否を判断 33 33 Test Scenario NetTester Server 1 OFS

    (Pica8) テスト対象 ネットワーク (SOで作成した 利用者セグメント) テストシナリオ 実行サーバ tcp/3000 (REST API) テストシステム用 セグメント Operator (テスト実行者) 拠点1 各拠点 操作シナリオ 記述 (RubyCucumber) OFS (OVS) Test Nodes (NetNS) テスト実行 結果 NetTester Server N …… 拠点N シナリオに設定された 要件表と比較 差分が無ければ テスト成功
  23. 7. 結果をもとに続行/中止を判断 34 34 Test Scenario NetTester Server 1 OFS

    (Pica8) テスト対象 ネットワーク (SOで作成した 利用者セグメント) テストシナリオ 実行サーバ tcp/3000 (REST API) テストシステム用 セグメント Operator (テスト実行者) 拠点1 各拠点 操作シナリオ 記述 (RubyCucumber) OFS (OVS) Test Nodes (NetNS) NetTester Server N …… 拠点N テストが成功たから 設定は完了 or 失敗したから 設定見直そう
  24. テストにかかるコスト? 35 繋げて! 設定しよう 終わらない… ◼テストをしなかった場合 ◼ 暗黙的にユーザが負担 ◼ 問題発生時に信頼度の低下

    ・利用開始までのリードタイム悪化 ◼ 作業時のミス対策などのコスト増加 ◼人海戦術のテストをした場合 ◼ カバレッジとテスト時間のバランス ◼ 現地作業員のアサイン・出張 ◼ テスト失敗したときの再実施コスト大 テスト NWテスト自動化で解消 テスト要るの? 作業コスト増えるだけじゃない?
  25. 参照 (NetTester) ◼NetTesterリポジトリ https://github.com/net-tester ◼net-tester : NetTester本体 ◼scenario-api : シナリオ実行APIサーバ

    ◼multisite-examples : 多拠点対応シナリオサンプル ◼デモ動画 https://youtu.be/DhKutgqYdSw https://youtu.be/C7z3aaWgsf4 42
  26. テスト自動化とこれまでの取り組み 43 テスト対象 NW(トポロジ)の操作 テスト対象 NW機器の設定 テスト対象サーバ (サービス)の設定 テスト用ノードの 作成・テスト実行

    テスト用ノードを 対象NWへ接続 テストのための多様なトラフィック生成、 トラフィックの送受信 テストの結果判定 複数ノードの同時制御(client/server etc) 物理・論理構成に対するテストパターンの網羅 必要なテストトラフィックを 必要なポイントで入出力させるための仕組み 物理トポロジのソフトウェアによる操作 障害模擬・物理経路の系切替試験実行 NW機器インタフェース(CLI/REST/NETCONF…) による機器コンフィグレーション、機器状態取得 テスト対象の物理・論理リソース、 サービスの設定・セットアップ ユースケースから各種作業へ分解 テスト全体のオーケストレータ Test Scenario (Cucumber) 済 済 済 済 実際の業務へ適用できる段階 PJ外 PJ外
  27. インフラ構築・運用プロセスの展望 44 変更 自動テスト リリース 本番 環境 検証 環境 運用者

    機械的に解釈 できる 構成管理 要 件 テストパス後 設定反映 自動構成 自動テスト ソフトウェアによるインフラの継続的なテスト、サービスデリバリ OFS NetTester 変更後の テスト シナリオ