SDNで物理ネットワークのテストを楽にする方法：SDNで始めるネットワークの運用改善（2）（2/4 ページ）

[村木暢哉（TIS），＠IT]

印刷

通知 連載「％」の新着をメールで通知

鬯ｯ�ｮ�ｽ�ｫ鬩包ｽｨ郢ｧ謇假ｽｽ�ｽ�ｽ�ｹ髫ｴ雜｣�ｽ�｢�ｽ�ｽ�ｽ�ｽ�ｽ�ｽ�ｽ�ｽPost

Shareシェア

はてなブックマーク

SharePocket Button

物理ネットワーク運用は自動化できるか？

　では、ネットワークの世界では自動化はどの程度進んでいるのでしょうか？　ネットワークの場合、仮想化環境と物理環境とで状況が大きく変わってきます。

　例えば、企業内のファイアウォールのポリシーを設定・変更するような場合に、本番環境が仮想化インフラであれば、事前に環境を複製し、テストフレームワークを使って繰り返し自動的に検証を実施することができます。

　一方、従来の物理ネットワークでは、仮想化インフラのように本番と同等の環境を作成・維持することが難しいため、テストを自動化して継続的に行うのは困難です。

　機器に対する設定自動化ツールの開発などは盛んに行われていますが、「設定自動化ツールが正しく動作するか」「設定した結果、狙い通りネットワーク全体が動作するのか」といった確認を本番環境への適用前に行うことは、前述の理由からなかなかできません。結果、時間と人手を掛けて変更内容を目視確認した上で、“一発勝負”で設定を本番環境に投入する状況になりがちです。

　また、仮に試験環境が準備できたとしても、変更時の確認試験の再実施（リグレッションテスト）が課題として立ちはだかります。そもそも機器の集合で構成されるネットワークは変更に対する試験のパターンがサーバ単体などに比べて爆発的に多くなりますから、変更の度に全てのテスト項目を実施しようとすると、非常にコストが掛かってしまうのです。

　そして残念ながら、こうした課題を解決し、物理ネットワークに関わるテストを自動化して継続的に行うための手法は、これというものが確立されていません。機器ベンダーが提供するテストツールは存在しますが、前回SDN製品の特徴で述べたのと同様に、そのソフトウェアを提供するベンダーの機器にしか対応していないなど、現実のネットワーク環境にそのまま適用するのは難しいことが多々あるのが実情です。

物理ネットワーク運用の課題

• 物理ネットワークは現地現物の操作が必要であるため、構築・変更などの作業時に人が動くしかないことが多い
• テスト用の環境をすぐに構築できず、テストの省力化・自動化の手法も確立されていないため、変更時には何重もの目視確認に頼らざるを得ない。
• そもそもネットワークは想定されるテストの組合せやパターンが非常に多いため、検証を繰り返し実施することが難しい

　一般的に、サービスは一度作ったら極力手を加えないというものではなく、運用を始めた後でも要求に答えて短いスパンでリリースを繰り返していかなければなりません。ネットワークもサービスの一部ですから、同じ考え方で変化に耐えられる運用を目指す必要があります。

　アプリケーションの変更では近年、求められる納期がどんどん短くなってきています。物理ネットワークに関しても、今は1週間以内と提示されている変更依頼の期限が、来年には3日と提示されるかもしれません。そうしたときに、現在のような「人海戦術でなんとかしのぐ」やり方は限界を迎えるでしょう。

SDNによる解決策

　それでは、どうすればこうした物理ネットワーク運用の課題を解決できるでしょうか？　その答えの1つがSDNです。

　ネットワークは、ノードの追加削除や設定変更が行われることで振る舞いが変化します。従って、“仮想的な結線”によって対象の環境を手元に作り出すことができれば、「本番と同等のテストを、テスト用環境で実施し、問題がなければ本番のノードに同じ設定を投入する」という仮想化インフラと同じような運用サイクルを、物理ネットワークでも実現できるはずです。具体的には、以下のことを行います。

1. テスト環境の構築作業（下記）を機械処理で実施可能にする
   • 機器間の結線
   • テストノードの構築
   • テストノードの機器への接続
   • 機器への設定投入
2. テストを繰り返し実施可能にする
   • 作成したテストノードからの送受信手順および結果確認手順の機械処理化
   • テスト手順の蓄積

機器間の結線

　結線を切り替える機器としては「パッチパネル」がありますが、ハードウェアパッチパネルは高価で、機械処理でテストしたい内容に合わせて結線を動的にコントロールするのもやや難しいところがあります。

　そこで、前回紹介したOpenFlowが活用できます。今実施したいのは「パケットの通り道を物理的にでも論理的にでもよいので、機械処理で自動的に構築する」ことですから、パケットのヘッダ書き換えや転送を思い通りに行えるOpenFlowはまさにうってつけというわけです。

　OpenFlowハードウェアスイッチの全てのポートに物理機器をつなぎ込むことで、テストしたい構成に合わせて結線をAPIなどで制御できるソフトウェアパッチパネルとして活用することができます。

図5　必要に応じたソフトウェアによる結線制御

テストノードの構築・接続

　では、テストノードの構築や接続に関してはどうでしょうか。ここで、前述のソフトウェアパッチパネルと併せて考えたいのが「このパッチパネルの特徴は、仮想スイッチにも適用できる」ということです。

　つまり、物理OpenFlowスイッチと仮想OpenFlowスイッチにまたがって論理的な結線を自由に制御すれば、「必要なだけテスト用の仮想マシンを起動し、仮想スイッチを経由して物理機器につなぎ込む」といったこともできるようになります。また、テスト用のノードを現地に持ち込んで現地の機器に接続するのではなく、自由な場所で環境を再現してテストを済ませることも可能になります。

図6　必要に応じたテストノードの起動とつなぎ込み

　こうした仕組みについては、2015年から沖縄オープンラボラトリの1プロジェクトとして研究が行われており、「OkinawaOpenDays」などで研究成果が発表された他、オープンソースとしてソースコードや設計資料が公開されています。

参考リンク

• OpenFlowを使ったネットワークテスト自動化システムの構築（沖縄オープンラボラトリ）
• L1patch応用NWテストシステムプロジェクト サンプルプログラム