はじめに

前回は、昨今注目されているネットワーク制御技術「OpenFlow」の動向や基本動作、仮想化が抱える課題について説明しました。今回は、より進んだOpenFlowの活用方法について説明します。

OpenFlowによるパケット制御方式

OpenFlowはネットワークの動作をプログラムで制御できます。具体的に言えば、OpenFlowを利用すると、パケット[1]の任意の部分を書き換えて、パケットを任意のノードに転送[2]できます。

パケットのどこを書き換え、どこに転送するか（以後「パケットの制御方法」と表記します）は、すべてOpenFlowコントローラが決定します。OpenFlowスイッチはOpenFlowコントローラから指示を受けて動作します。OpenFlowスイッチが独自の判断で動作することは基本的にありません。未知のパケットを受信した場合、OpenFlowスイッチはOpenFlowコントローラにパケットの制御方法について問い合わせをします。

OpenFlowには3種類のパケット制御方法があります。まずは、その3種類の制御方式についてそれぞれ説明します。

制御方式1

制御方式1（図1）は、OpenFlowの最も基本的な制御パターンです。この制御方式は次のように動作します。

• （1）サーバ1はサーバ2に対してパケットを送信する
• （2）OpenFlowスイッチはサーバ1からパケットを受け取り、受信したパケットに対応する制御ルール[3]を自身が保持していないか確認する
• （3）受信したパケットに対応する制御ルールを保持している場合、OpenFlowスイッチは制御ルールに従ってパケットを書き換え、転送を行う
• （4）OpenFlowスイッチから転送されたパケットがサーバ2に届く

制御方式1では、パケットの任意の個所を書き換えることはできません。書き換え可能な個所は、OpenFlowバージョン1.0の場合はヘッダフィールドに設定可能な12種類になります（詳細は前回を参照ください⁠）⁠。

制御方式2

制御方式2（図2）は、OpenFlowを用いてネットワークを構築した直後によく発生するパターンです。この制御方式は以下のように動作します。

• （1）サーバ1はサーバ2に対してパケットを送信する
• （2）OpenFlowスイッチはサーバ1からパケットを受け取り、受信したパケットに対応する制御ルールを自身が保持していないか確認する
• （3）受信したパケットに対応する制御ルールを保持していない場合、OpenFlowスイッチは受信したパケットをバッファに一時保存し、OpenFlowコントローラにパケットの制御方法を問い合わせる
• （4）OpenFlowコントローラは、OpenFlowスイッチが受信したパケットに関する情報を受け[4]⁠、パケットの制御方法を決定する
• （5）OpenFlowコントローラは、OpenFlowスイッチにパケットの制御方法を指示する。同時に、OpenFlowスイッチに制御ルールを書き込む
• （6）OpenFlowスイッチはOpenFlowコントローラの指示に従い、OpenFlowスイッチのバッファに一時保存されているパケットを書き換え、サーバ2にパケットを転送する

上記の処理を行うと、OpenFlowスイッチに制御ルールが書き込まれます。その状態で再びサーバ1から同様のパケットを受信すると、今度はOpenFlowスイッチに制御ルールが書き込まれているため、OpenFlowスイッチはOpenFlowコントローラに問い合わせることなく、制御方式1と同じ要領でパケットを転送します。制御方式2ではOpenFlowスイッチでパケットを書き換えるため、パケットを書き換えることができる個所は制御方式1と同様に12種類になります。

制御方式3

制御方式3（図3）は制御方式2の応用になります。この制御方式は次のように動作します（⁠（⁠1⁠）⁠～（⁠4）は制御方式2と同様です⁠）⁠。

• （5）OpenFlowコントローラは必要に応じてOpenFlowスイッチから受信したパケットを書き換え、書き換えたパケットを転送するようOpenFlowスイッチに指示する（書き換えられたパケットにOpenFlowヘッダを付加したパケットがOpenFlow コントローラからOpenFlowスイッチに送信される）
• （6）OpenFlowスイッチはOpenFlowコントローラの指示に従い、OpenFlowコントローラから受信したパケットをサーバ2（厳密には、転送先はOpenFlowコントローラが指示する）へ転送する

制御方式3はOpenFlow スイッチに制御ルールを書き込みません。よって、サーバ1から同様のパケットを受信した場合、OpenFlowスイッチはパケットの制御方法がわからないため、前回と同様にOpenFlowコントローラにパケットの制御方法を問い合わせます。

また、制御方式3はサーバ側でパケットの書き換えを行います。よって、この制御方式ではパケットのあらゆる場所を書き換え可能です。さらに、場合によってはパケットを新規に生成し、サーバ1から送信されたパケットとはまったく異なるパケットをサーバ2に届けることも可能です。

OpenFlowで実現できるアーキテクチャ

続いて、OpenFlowで実現できるアーキテクチャを説明します。

多数のOpenFlowスイッチを管理可能

ここまでは説明の都合上、OpenFlowスイッチが1つの場合を例に挙げて説明しましたが、実際は1つのOpenFlowコントローラで複数のOpenFlowスイッチを管理可能です。OpenFlowスイッチでのパケット書き換えは、複数存在するOpenFlowスイッチのどれで行ってもかまいません。また、パケットの転送経路が複数存在する場合は、どの経路でパケットを転送してもかまいません。すべてはOpenFlowコントローラが自由に決定できます。

OpenFlowルータの実現

OpenFlowを利用すると、パケットの任意の場所を書き換えて任意のサーバに転送できると説明しましたが、これは具体的にどのような意味があるのでしょうか。図4は、サーバ1から送信されたパケットがルータにより書き換えられる様子を示しています。ルータはL3装置なので、パケットがルータを通過すると、送信元MACアドレスと送信先MACアドレスが書き換えられます。

続いて図5を見てください。これはOpenFlowスイッチがパケットのMACアドレスを書き換えている例です。図5にはOpenFlow スイッチしか存在せず、ルータはどこにもありません。しかし、OpenFlowスイッチ上で、あたかもルータを通過したかのようにパケットを書き換えると、OpenFlowスイッチしか存在しないにもかかわらず、ネットワーク上にルータが存在するかのように動作させることができます。

仮想ルータという表現は人によりイメージが異なると思いますが、一般的には仮想マシンにルータソフトをインストールしたものをイメージされると思います。仮想マシンで実現する仮想ルータは仮想マシンとして動作しているだけであり、本質的には物理的なルータ装置と違いはありません。しかし、OpenFlowにより実現される仮想ルータは仮想マシンで実現される仮想ルータとは根本的に異なります。OpenFlowにより実現される仮想ルータは実体がなく、OpenFlowスイッチにルータとして動作する制御ルールが書き込まれているだけです。OpenFlowスイッチが故障した場合は、故障したスイッチに格納されていた制御ルールと同様のルールを他のOpenFlowスイッチに書き込むだけで、問題なくOpenFlowスイッチの故障から復旧できます。OpenFlowの世界では、すべてのOpenFlowスイッチが仮想ルータとして動作可能なのです。

筆者が所属するNTTデータでは、OpenFlowにより実現される仮想ルータを、仮想マシンで実現されるルータと区別して「OpenFlowルータ」と呼んでいます。

ファイアウォールとロードバランサ

OpenFlowでルータを実現できると、今度はファイアウォールやロードバランサが実現できないか気になると思います。結論から言えば、実現可能です。

ファイアウォールは、OpenFlowスイッチが特定の制御ルールにマッチするパケットを受信したときにパケットを破棄するように制御ルールを書き込むことで実現できます。OpenFlowスイッチに制御ルールを書き込むことでファイアウォールを実現する場合は、先月号で説明した12種類の条件によるフィルタリングが可能です。また、制御方式3を用いてファイアウォールを実現する場合はパケットの任意の場所でフィルタリングが可能なので、理論上はフィルタリング機能に制限はありません。

ロードバランサも実現可能ですが、ファイアウォールほど簡単ではありません。ロードバランサはパケットの送信先IPアドレスの値を書き換えることで実現できますが[5]⁠、パケットの振り分け先が複数存在する場合、毎回異なる値で送信先IPアドレスを書き換える必要があります。OpenFlowスイッチに制御ルールを書き込む方式でロードバランサを実現すると、パケットの同じ個所を同じ値でしか書き換えることができません。よって、OpenFlowでロードバランサを実現するには、制御方式3を用いてサーバ側でパケットを書き換える必要があります。

上限のないVLAN数とVRF数

仮想化を用いたシステムは、1つの共通基盤上で複数のシステムが動作します[6]⁠。各システムは通常、VLAN（Virtual LAN）を用いて分離されます。また、コアルータに接続されている各システムをVRF（Virtual Routing and Forwarding）で分離する場合もあります。

VLAN数やVRF数が上限に達してしまうと、それ以上システムの規模を拡大するのが難しくなります。この問題もOpenFlowを用いれば簡単に解決できます。OpenFlowはVLANなどを用いてネットワークを分離する必要がありません。異なるシステム間の通信についてはすべてパケットを破棄するように、OpenFlowスイッチに制御ルールを投入するだけです。

そればかりか、OpenFlowでは共通基盤上で動作する各システムで同じVLAN IDを利用できます。たとえば、システムA で「VLAN ID=10」を利用し、システムBでも「VLAN ID=10」を利用することが可能です。

故障に強く、拡張も容易

OpenFlowスイッチが故障した場合、故障したスイッチを迂回してパケットを転送するようにOpenFlowコントローラを実装することも可能です。つまり、OpenFlowの世界ではOpenFlowスイッチを適当にメッシュ状に接続するだけで簡単にスイッチの三重化や四重化が実現できます。OpenFlowスイッチの設定はOpenFlowスイッチに割り当てる管理L1ポートのIPアドレス設定のみでよく、スパニングツリーやVLANなどの煩雑な設定は一切必要ありません。

OpenFlowではリンクアグリゲーションの設定も必要ありません。誌面の都合上詳細は説明しませんが、OpenFlowを用いれば自動で複数のケーブルが接続されていることを検知し、OpenFlowスイッチに蓄積されるトラフィック統計情報を基に自動でトラフィックの平滑化を行うことが可能です。帯域が足りない場合は、スイッチ間を適当に二重、三重にケーブル接続するだけで、何の設定も必要とせずに自動的にトラフィックが平滑化されます。

システムを見える化する

OpenFlowではすべてのパケットの制御をOpenFlowコントローラが行います。それはつまり、OpenFlowコントローラから情報を収集すれば、すべてのパケットの動きを見える化できるということです。

仮想化され、故障に備えて多重化されたシステムでは、パケットがどのスイッチを経由して転送されているのか把握することが困難です。しかし、OpenFlowであればパケットの経路をGUI上に表示することも可能です。また、OpenFlowスイッチにはトラフィックなどの統計情報が随時蓄えられるため、OpenFlowコントローラで各OpenFlowスイッチの統計情報を吸い上げ、GUIで表示することも可能です。また、トラフィックが多い通信を他の通信とは異なる経路も設定できます。

新しいネットワークアーキテクチャ

OpenFlowを利用するとルータ機能やロードバランサ機能を仮想的に実現できると説明しましたが、実はDHCP機能や監視機能も実現できます。

制御方式3（図3）で説明したとおり、OpenFlowコントローラは受信したパケットのあらゆる個所を書き換えることができます。つまり、サーバから送信されたDHCPリクエストを制御方式3の要領でOpenFlowコントローラに転送し、OpenFlowコントローラからサーバに対してDHCPレスポンスを返すようにコントローラを実装すれば、OpenFlowによりDHCPサーバを実現できてしまいます。OpenFlowを用いているので、DHCPサーバを各L2セグメントに配置する必要はありません。DHCPリレーエージェントも必要ありません。共通基盤上にDHCPサーバ機能を実装したOpenFlowコントローラが1つあれば、すべてのサーバにIPアドレスを払い出すことができます。

また、OpenFlowコントローラは任意のパケットをコントローラ独自の判断でサーバに向けて送信することも可能です。つまり、Pingによる監視機能やHTTP監視機能をOpenFlowコントローラに実装できます。

これまでの仮想化技術では、ロードバランサソフトやルータソフトをインストールした仮想マシンをテナントごとに用意するのが一般的でした[7]⁠。また、「⁠ロードバランサ用の仮想マシン」「⁠ファイアウォール用の仮想マシン」のように機能ごとに仮想マシンを分離するのが一般的です。しかし、OpenFlowではロードバランサやファイアウォールのために仮想マシンを用意する必要はありません。すべては、OpenFlowスイッチによるパケット書き換えと、OpenFlowコントローラによるパケット書き換えで実現できます。

従来は各テナントのロードバランサやファイアウォールのリソースを監視し、足りなくなれば増強を行うという運用が必要でした。しかし、OpenFlowではこれまでとはまったく異なる方法でネットワーク機能を増強できます。

OpenFlowコントローラがスケールアウトされていることが前提ですが、「⁠ルータ」「⁠ファイアウォール」「⁠ロードバランサ」「⁠DHCP」「⁠監視」などのネットワークリソースが不足する場合は、図6のようにOpenFlowコントローラを追加するだけです。どのテナントのリソースが不足しているのか？ ロードバランサのリソースが不足しているのか？などと難しいことを考える必要はありません。OpenFlowコントローラのリソースを監視し、足りなくなったら、OpenFlowコントローラを追加すればよいのです。

まとめ

今回はOpenFlowのパケット制御方式を説明し、OpenFlowで実現可能な新アーキテクチャについて説明しました。OpenFlowコントローラ内部のしくみや、OpenFlowコントローラとOpenFlowスイッチ間でやりとりする情報について、まだ十分に説明できていません（連載の後半で説明する予定です⁠）⁠。また、OpenFlowコントローラにどのような機能を実装するかは各ベンダが決定することであり、本稿で示した機能のすべてが市販のOpenFlowコントローラに実装されるわけではないので注意が必要です。

OpenFlowは仮想化におけるさまざまな問題を解決します。また、まったく新しいサービスやコンセプトを実現する力も秘めています。しかし、OpenFlowの適用にまったく課題がないわけでもありません。次回は、OpenFlowが業界に与えるインパクトやクラウドへのOpenFlow適用について説明します。