OpenFlow製品は大きく2タイプ、「ホップバイホップ型」「オーバーレイ型」

　商用製品としての世界初のOpenFlow対応コントローラーとスイッチ製品は、NECが2011年3月に販売開始した「UNIVERGE PFシリーズ」である。UNIVERGE PFシリーズは、OpenFlow対応機器のみでネットワークを構成する「ホップバイホップ型」に分類される（図1）。OpenFlowスイッチのみで構成されるネットワークをOpenFlowコントローラーで制御することにより、柔軟な経路制御などを実現する。

図1：ホップバイホップ型のOpenFlow製品の構成例

　その後、米Nicira Networksなどが「オーバーレイ型（ネットワークハイパーバイザー型）」に分類される製品を発表した（図2）。これは、ホップバイホップ型のように全てのネットワーク機器をOpenFlowスイッチに変更するのではなく、サーバの論理スイッチやエッジスイッチのみをOpenFlowプロトコルで管理する仕組みを採用する。スイッチ間にトンネルを張ることで論理的なネットワークを構成するのが特徴だ。

図2：オーバーレイ型（ネットワークハイパーバイザー型）のOpenFlow製品の構成例

　オーバーレイ型は特にデータセンター環境で注目されており、VLAN数の上限に縛られず、ネットワークに柔軟性を持たせることが可能である。さらに、トンネル技術を用いることで、既存のレイヤー3環境を超えたレイヤー2ネットワークの延伸が可能だ。また、クラウド基盤管理ツールなどとの連携により、仮想マシンの生成や移動などに連動したネットワークも実現できる。

　ホップバイホップ型とオーバーレイ型は、どう使い分ければよいのだろうか。OpenFlowが使用できない既存ネットワークとの親和性を重視する場合はオーバーレイ型の製品を選択し、新たにネットワークを構築してデータパスを細かく制御したい場合はホップバイホップ型の製品を選択するのが基本的な選定姿勢となる。今後は両方の機能をカバーする製品の登場も予定されているため、ベンダーの動向には常に注意を向ける必要があるだろう。

OpenFlow導入時の注意点

　OpenFlowを実装した商用製品は、登場から1年程度しか経過していない。OpenFlow自体も標準化が始まったばかりであり、導入時にはさまざまな注意点がある。代表例である3点を見ていこう。

注意点1：ベンダー独自実装と相互運用性

　先に述べたように、OpenFlowで標準化されているのは基本的な仕様のみである。OpenFlowの標準化を進めるOpen Networking Foundation（ONF）は、標準化では必要最低限の定義をするという考えだ。このため、OpenFlowにはベンダー独自の機能拡張の余地が残されている。つまり、独自拡張の実装方法次第では、特定ベンダーの製品でしか利用できない機能が登場する可能性がある。

　また、現状ではOpenFlowプロトコルの最初の正式版である「OpenFlow v1.0」のみに対応している製品が多くを占めている点も無視できない（現時点での最新版はOpenFlow v1.3）。製品選定の際には、異なるバージョンに対する対応状況にも注意が必要だ。なお、ONFはOpenFlow仕様の相互接続性を検証するため、OpenFlowのテスト仕様である「OF-Test」を策定中である。OF-Testや対応検証装置の成熟により、相互接続性の向上が期待される。

注意点2：リソースの拡張性

　従来のネットワーク機器の場合、ルータであればIPアドレス、スイッチであればMACアドレスを基に転送先を特定する。だがOpenFlowスイッチの場合は、制御ルールと実施すべき処理の定義をまとめた「フローエントリー」を基にパケットを処理する。パケット処理の際、トラフィックの複数レイヤーにまたがったマッチングをするため、フローエントリーの集合である「フローテーブル」には多くの情報が保持される。

　OpenFlowをサポートしている製品であってもフローテーブルを十分に保持できない可能性があるため、機器選定の際はリソースの拡張性についても注意を払う必要がある。ただし、マッチ条件にワイルドカードを指定することなどにより、保持するフローテーブル数を少なくすることは可能だ。いずれにしても、フローテーブルについて使用用途や規模に合わせたポリシーを検討することが必要である。

注意点3：コントローラーへの負荷やリスクの集中化

　OpenFlowでは、OpenFlowコントローラーが経路情報やスイッチに対する設定を一元的に管理する。このため、OpenFlowコントローラーが高負荷状態になる可能性がある。OpenFlowコントローラーに発生した障害は全てのスイッチに伝搬するため、影響範囲は大きくなる。

　他にも、マッチテーブルに該当しないパケットをスイッチが受け取った場合、そのパケットに対する処理をOpenFlowコントローラーへ問い合わせるときに遅延が発生する。スイッチからOpenFlowコントローラーへの問い合わせが集中した場合、OpenFlowコントローラーが経路情報を各スイッチに伝える必要があるためにパケットの遅延も懸念される。

　こうした懸念については、OpenFlowコントローラーの冗長化や分散化に加え、経路情報を事前にスイッチへ設定しておくといった対策が提案されている。しかし、今までのネットワーク運用とは異なるノウハウが必要になるため、効率的なトラブル解決方法について事前に十分検討する必要があるだろう。

図：OpenFlowコントローラーにおける負荷やリスクの集中

OpenFlowと既存ネットワーク技術をどう使い分ける？

　OpenFlowにはさまざまな期待が寄せられている。だが、期待する内容は本当にOpenFlowを選択しなければ実現できないのかどうか、他の技術でも実現できるのかどうかについては検討しておく必要があるだろう。

　OpenFlowは、それぞれの製品が独自に持っている設定を変更するのではなく、トラフィックを転送するフローテーブルを変更するため、個別の製品設定を意識せず、プログラムで制御できるという利点がある。だが、OpenFlowの機能をどのように活用するかはベンダーや実装者によって大きく異なる。OpenFlowの機能をどのような目的で使用したいか、目的に合わせて検討する必要がある。

　例えば、OpenFlow製品を導入することでネットワーク運用負荷を軽減したいのであれば、どのような運用負荷を軽減したいのかについて熟慮する必要があるだろう。

　運用の自動化が重要なテーマであれば、ネットワークベンダーが提供している開発環境やスクリプトなどで独自機能を実装する方法もあるし、プロビジョニングツールが提供するAPIを利用するという選択肢もある。装置設定の一元化や動的な変更を実現したいなら、「NETCONF」「SNMP」といった既存のネットワーク制御の仕組みに加え、ベンダーが提供する独自技術を利用することも可能だ。

　実現したいと考えていることは従来の技術や製品では本当に不可能なのかどうか、OpenFlowを使用した製品が本当に適しているのかどうか、という判断基準を持つことが大切だ。

オープンな枠組みがOpenFlowの課題解決を加速

　OpenFlowの大きな特徴は、ONFというオープンな枠組みでさまざまな企業やベンダーが標準化に関わり、エコシステムを形成していることだ。ONFがOpenFlowの技術開発を主導することで、オープン性を保ちつつベンダー間の連携が加速されていくであろう。今後も多くのオープンソースや商用製品の登場によって、ネットワークに対する新しいアイデアや使い方が提案され、課題解決のイノベーションが加速することが期待される。

　OpenFlowは、現時点では課題も多く、商用製品の選択肢も限られている。ただし、OpenFlowが持つさまざまな機能は、ネットワークの新たな価値として役立つことは間違いない。今後もさまざまな製品やユースケースが登場することを期待したい。