図1●OpenFlowを利用したデモ用ネットワークの構成例
図1●OpenFlowを利用したデモ用ネットワークの構成例
2011年10月にNTTデータがICT関連のイベント「ITpro EXPO 2011」で披露したデモンストレーションのネットワーク構成図。物理サーバーではXenServer 5.6 SP2が稼働している。
[画像のクリックで拡大表示]

 今回は、OpenFlowコントローラーとOpenFlowスイッチを使ってどんなことができるのかを、2011年10月にNTTデータが国内の展示会で披露した相互接続デモから探っていこう(図1)。一つは「ネットワークを論理的に分割し、二つの企業のネットワークを構成する」、もう一つは「OpenFlowスイッチの一つが保守のため停止した際、自動的にう回経路に切り替える」というデモだ

 こうした運用を従来のプロトコルやネットワーク機器で実行する場合、設定に手間がかかった。それは一つひとつのスイッチが経路計算や経路制御の機能を持っているためだ。接続すると設定に応じてスイッチ同士で自動的に情報を交換し、自律的に経路を決める。スイッチ同士の設定や、同じネットワーク内の複数のプロトコルの設定がかみ合わなかったりするとトラブルが起こってしまう。

 OpenFlowなら、OpenFlowコントローラーが経路計算と経路制御を一手に引き受けている。OpenFlowスイッチは、OpenFlowコントローラーから指示された経路だけを使う。つまり、スイッチを物理的に接続しただけでは使える経路はない状態だ。フローエントリーが書き込まれて、初めて経路が“開通”する。

 そのため従来のスイッチでは接続前に1台ずつ施していたプロトコルなどの設定が必要ないうえ、複数のプロトコルの整合性を気にしなくてもよい。極端な言い方をすれば、冗長化プロトコルも必要ない。デモの構成を見ると、4台の物理スイッチをメッシュ状に接続しており、ケーブルがループになっているのがわかる。この状態でスパニング・ツリー・プロトコル(STP)を使わなくても、ブロードキャストストームのような問題は起こらない。

くねくねした経路が可能

図2●OpenFlowを利用したデモの例
図2●OpenFlowを利用したデモの例
展示会場で実演された保守作業時の経路切り替えデモを示した。このほかのデモとして、ライブマイグレーション時の仮想マシンの移動に合わせて、ネットワーク構成を自動的に変えるデモなどが実演された。
[画像のクリックで拡大表示]

 このデモで使われているOpenFlowコントローラーは、前回の図4で紹介したパターン2でフローエントリーを書き込む。つまり、今まで受信したことがないフレームを受信したタイミングで、OpenFlowスイッチがOpenFlowコントローラーから適切なフローエントリーをもらって経路が決まる。例えば「パソコンA→ファイアウォール→ロードバランサー→Webサーバー2」の順でフレームを流すように指示すれば、通常のネットワークでは見られない、くねくねした経路が実現できるのが面白い(図2の上)。

 このOpenFlowコントローラーはNTTデータの「Hinemos」という管理ソフトウエアと連携して動く。ユーザーがHinemosの管理画面上で機器をメンテナンスモードに指定すると、OpenFlowコントローラーにその情報が伝わる。OpenFlowコントローラーは指定されたOpenFlowスイッチをう回するように、ほかのOpenFlowスイッチにフローテーブルの書き換えを指示する(図2下)。

 こうすると経路が切り替わり、メンテナンス対象のOpenFlowスイッチをう回するようになる。スイッチ一つひとつに設定を施すのに比べ、大幅に手間が省けるのがわかる。