サイト内検索
サイト内検索を閉じる

ネットワークのモデルベース検査と障害シミュレーションによる運用高度化への挑戦

はじめに

TISは2021年8月から一般社団法人 沖縄オープンラボラトリModel Driven NW Devops Projectに参加して活動してきました。現在プロジェクトにはTIS株式会社・NTTコミュニケーションズ株式会社・ビッグローブ株式会社のメンバが参加しています。詳細は後述しますが、このプロジェクトではトポロジをはじめとするネットワークの構成情報を中心にした設計・構築・運用プロセスの検討とPoCの実施・評価に取り組んでいます。今回はこの半年間で得られた成果を各社のリレー形式で紹介していきたいと思います。この記事は3番目の記事です。

  1. 前編: BIGLOBE「モデルベースなネットワーク自動化への挑戦~検証環境の構築と装置のコンフィグ自動取得
  2. 中編: NTTコミュニケーションズ「ネットワークをモデルとして抽象化しオペレーションを高度化するチャレンジ
  3. 後編: TIS(本記事)

プロジェクトのねらい

既存の(オンプレミスの)ネットワーク運用では、ネットワークの変更にかかるレビュー・テスト・動作検証が複雑でリードタイムが長くなってしまうという課題があります。その要因の1つに、ネットワークを操作するためには相互に接続しているノード間の関係性を把握し、複数のノードで整合性を取らなければいけないことがあげられるでしょう。ネットワーク担当者には、構成図・設計書・個々の機器コンフィグ等を見ながら、関係する複数のノード~ネットワーク全体の動きを想像する複雑な検討(”脳内シミュレーション”)が求められてしまいます。

当然そういった検討には人による違い(属人性)や限界があります。ネットワーク全体の動作をレビューや机上検討だけで予想しきることは難しく、検証環境で実際に試してみる必要が出てきます。ところが、ハードウェアアプライアンスで構成されたネットワークでは、本番環境と同等の環境を用意することは難しく、結果として「やってみないとわからない」「やってみてで初めて気づいた」というリスクをつぶしきれません。

そこで、このプロジェクトでは既存の環境(Brown Field)を対象に、ネットワークの構成情報やノード間の関係性を抽出・モデル化して自動化可能な範囲をひろげること、既存の運用を補完して課題に合せて小さく始めて積み上げるアプローチを検討しています。

そして、将来的にはターゲット(既存のネットワーク)に対して、以下の事項ができるようになることを目指しています。

  • 既存環境の構成情報を抽出して、モデルデータとして組み立てる
  • モデルデータを基にした、システムの構成や状態の可視化、時間変化のトラッキング(構成変化差分の取得)
  • モデルデータを基にした、これまで人が見ていたレビューやチェック、設計ポリシとの適合性検査などの実装
  • モデルデータを基にした、仮想の検証環境を自動構築、検証環境内での機能検証、リハーサルやトレーニング、自動テストの実行

こうしたことが実現できると、本番環境での作業の前に、モデルベースの検査(実機を使わないノード間設定の整合性やポリシチェックなどのテスト自動化)、仮想環境での実際の動作検証などが自動化できるようになります。システムの設計や特性に合わせた検査・テスト・検証の実装を積み重ねることにより、短時間に高精度のトライアルをくりかえして、「やってみて初めて気づいた」障害発生のリスクを減少させることをねらっています。

ネットワークの静的な構成検査と障害シミュレーション

ネットワーク機器から情報を取得し、モデルを作成し、そのモデルを用いて各種試験を行うために大きく次の3ステップを設定しています。

  1. NW装置のコンフィグを自動定期取得するステップ
  2. コンフィグからL1/L2/L3に分けてモデルデータを作成するステップ
  3. モデルデータを評価するステップ

本記事では、3.モデルデータを評価するステップについて扱います(下図右側の点線枠部分)。実際にどのようなテストを行って「やってみて初めて気づいた」を防止できるのか、具体例を紹介します。ステップ1-2についてはそれぞれビッグローブさん、NTTコミュニケーションズさんの記事をご確認ください。

実際に使用しているNW機器コンフィグ・物理トポロジ情報をもとに、設定変更後の動作や障害発生時の動作を模擬(シミュレーション)することによって、実機を使わなくてもより早期により高精度の試行錯誤ができます。これにより、「実際にやってみないとわからない」「やってみて初めて気づいた」リスクを減らしていくことができると考えています。

静的な構成検査

ネットワークの設定変更をした時に、加えた変更によって各レイヤ(L1-L3)の構成をどう変える(変わる)か、構成図やコンフィグファイルをもとにチェックすることはよく行われています。ここではNW機器のL1-L3の情報(VLAN設定やIPアドレス設定)をもとにトポロジデータを組み立てられていることを前提にしています(ステップ1-2)。それをもとに、構成図やコンフィグを基に人がチェックしていた以下のようなことを実装してみました。

  • 各レイヤで連結されているノード群の抽出
    • トポロジデータを作る段階で、例えばVLAN設定のミスマッチなどがあると、連結されるべきノード間が分離した状態になることがあります(設定ミスの調査)
    • リンク障害の模擬(具体例は次節)で連結しているノード群が変化した場合、障害が発生したリンクは単一障害点と考えられます(単一障害点の検出)
    • 連結されているノード群にループになっている部分があるかどうかも検討ポイントになります(ループ検出)
  • L3のアドレス設定ミス・アドレス設計ポリシチェック
    • 1つのL2セグメントに対して複数のIPアドレスブロック(prefix)が設定されている(typo, 設定ミス等を想定)
    • 1つのIPアドレスブロックが複数のL2セグメントで使用されているなど、NW設計上おかしな状況の検出(IPアドレス重複…設定ミスのほか、単一障害点での障害発生で本来つながっているセグメントが2つに分割されてしまうケースなども)

障害シミュレーション

ネットワークの構造に着目して、ネットワーク的な不整合の発見、設計ポリシから見た問題点の検出などをできたとしても、実際にはNW機器間が動的に持つ状態や動作による問題が起きることがあります。代表的な例として、動的経路制御プロトコルを使用していているケースが考えられます。動的経路制御プロトコルを使ってNW機器間が相互に経路情報を交換している環境では、各経路制御プロトコルによって、それぞれのノードがどんな経路情報を持つかを考える必要があります。また、そのうえで障害が発生した際に問題なく代替経路が利用可能になっているのかの検討も必要です。

こうした経路情報交換の動作や障害テストを検証環境で試せるとよいのですが、多数のノードを用意することが難しかったり、用意できたとしても環境準備や設定・手動での障害時動作検証にどうしても時間がかかったりします。本プロジェクトでは、ここにBatfishというOSSのツールを適用してみました。BatfishはNW機器コンフィグをもとにL3のネットワークシミュレーションを行うことができます。

まず、オリジナル(正常時)のコンフィグスナップショットを用意します。次に、オリジナルのスナップショットから、物理リンクがどこか1つ停止した状態のスナップショット(単一の物理リンク障害が発生したテストケース)を、オリジナルが持つ全物理リンク分生成します。

シミュレーションの前に、まず静的な構成チェックを行います。前節であげたネットワーク構成上の特徴がどう変化したか、スコア化して確認してみましょう。この「スコア」は、連結されているノード群(”クラスタ”の個数)、設計ポリシ上おかしなL2セグメント-IPプレフィクス対応、ループ有無の変化等に対して、重みをかけて数値化したものです。スコアの高いテストケースはネットワーク的に大きな変化があると考えられます。下図が実行例ですが、障害シミュレーションで見ている単一物理リンク障害が単一障害点となっているなど、ネットワーク構成上の大きな違いがあると、この時点で大きなスコアを持つテストケースとして出てきます。実行例では21点が9ケースあり、単一障害点の有無などをまずこの9ケースについて確認していく必要があります(詳細は割愛)。

静的な構成チェックで問題が見つからなければ、ネットワークシミュレーションに入ります。それぞれのスナップショットに対してサーバ間のL3通信テスト(traceroute)をシミュレーションします。このシミュレーションは、各障害発生時スナップショット(何かリンクが落ちている構成)を読み込ませたBatfishに対して、tracerouteクエリを発行することで実行され、L3で到達できるかどうかと中継したノードのリスト(Hops)が出力されます。

こうしたクエリを組み込んで、各障害時スナップショットに対するL3通信テストスクリプトを実装します。テストを実行すると、各スナップショットに対して複数のサーバ間通信(traceroute)を実行し、テスト結果を出力します。テスト結果を検索するとトラブルが起きているテストケース(ここではNo.19)があることがわかります。

問題のあるテストケース(No.19)について、ネットワーク構成を確認してみます。下の図で赤いリンクはもとの構成から削除されたリンクです(2つのモデルデータ : オリジナルと、No.19テストケースの構成情報を比較して、モデルベースの差分情報を可視化しています)。L3の構成を見ると代替経路がありそうに見えますが、シミュレーション結果によると代替経路は選択されておらず、通信障害が発生していました。

そこで、各ノードの持つ状態(経路情報)を調査します。検証環境があれば実機でも調査できますが、今回はシミュレーションしているので、シミュレータ(Batfish)中の状態を調査していきます。

シミュレータ中でノードの持つ経路情報を見ると、OSPFの問題に見えます。機器コンフィグも確認すると、下の図のようにCEルータ間のOSPF設定が抜けていたために、障害発生時にOSPFエリアから片方のルータが独立した状態になってしまうことが原因だとわかりました。

あとは、判明した設定ミスを修正したコンフィグを作って(それをオリジナルとして)、同様のテスト・障害シミュレーションをくりかえし、問題がなくなったことを確認するだけです。

まとめ

ネットワークのモデルデータをつかった静的な構成検査と障害シミュレーションについて紹介しました。構成検査では、対象システムの設計ポリシに合わせたノード間の関係性に関する各種チェック事項を実装することができます。また、障害シミュレーションでは、(やれることはまだ限定されているものの)実際に環境を組んでみないとわかりにくかった「実際の動作」上の問題を発見できる可能性があります。

こうした検査・テストは、実環境から取得したネットワーク機器コンフィグと物理トポロジ情報を基に処理されており、実機(ネットワーク機器)を使わずに机上で実行することができます。一般的に、検証環境は本番環境よりも制限された環境になりますし、実機を使ったオペレーションはどうしても試行錯誤に時間がかかってしまいます。モデルベースに・机上でこうしたテストが実施できるようになると、これまで人手で確認やレビューしていた複雑なチェックを自動化したり、やってみて初めて気付いていた問題点を早期に発見・修正できるようになると考えています。

このプロジェクトでは、こうした取り組みを通じて、どうしても複雑になっていくネットワーク運用のなかで、運用をより高度にかえていく範囲を拡大したいと思っています。冒頭に紹介したとおり、この取り組みは沖縄オープンラボのプロジェクトとして活動しており、会社や業種の垣根を越えて課題や知識、アイディアを持ち寄り、ネットワークの運用にかかわる人のための課題解決を目指しています。こうした活動に興味のある方は沖縄オープンラボラトリまでご連絡ください。

PAGE TOP

サービスに関する資料をご希望の方は、フォームに必要事項を入力いただき、ご送信ください。

資料を請求する

お問い合わせ
各種お問い合わせページ
お問い合わせフォーム
サービスに関するお問い合わせ
お電話
0800-600-9810
携帯電話
050-5816-9805
受付時間 9:00~12:00 13:00~17:00(土・日・祝日を除く)

更新日時:2024年3月25日 16時44分