近年、ソフトウェアやハードウェアなどのリソースをネットワーク経由で利用する形態である「クラウドコンピューティング」が流行っている。クラウドコンピューティングには、SaaS（Software as a Service）やPaaS（Platform as a Service）、IaaS（Infrastructure as a Service）などの「パブリッククラウド」や、企業毎に自社のデータセンタ上でサーバ仮想化技術を使用して、社内の部門に対して仮想サーバの貸し出しサービスを行う「プライベートクラウド」などが存在するが、複数の企業のプライベートクラウドを物理的に同じインフラ上で実現することでコスト削減を実現する「仮想プライベートクラウド」が注目されてきている。仮想プライベートクライドでは、サーバの論理分割だけでなく、ネットワークの論理分割を行い、各社のプライベートクラウド間のセキュリティを確保する必要がある。本稿では、この論理分割を実現するための新しいネットワーク技術であるOpenFlowの概要について説明する。

 　現在は、各社が自社のデータセンタに独自にプライベートクラウドを構築している。この状態では、サーバの集約効果はあるものの、コスト削減効果は限定的であった。このため、サーバだけでなく、データセンタやネットワークも他社と共有することでコストを削減する「仮想プライベートクラウド」が注目されている（図1）。

図1： 仮想プライベートクラウドの仕組みとメリット

 　1台の物理サーバを複数の企業が共同利用するためには、サーバ仮想化技術を利用するが、ネットワークを複数の企業が共同利用するためには、VLAN（Virtual Local Area Network）などのネットワーク仮想化技術が必要となる。
 　この仮想プライベートクラウド環境においては、いくつかの問題が指摘されている。ひとつは、VLANなどの設定が複雑になることである。ネットワーク機器を論理的に分割するためには、レイヤ2スイッチであればVLAN、レイヤ3スイッチであればVRF（Virtual Routing and Forwarding）、ファイアウォールやロードバランサであれば仮想ファイアウォールや仮想ロードバランサ（名称はベンダによって異なる可能性がある）などの技術が存在するが、仮想プライベートクラウドを利用する企業が増える度に、それぞれのネットワーク機器にこれらの仮想化のための設定を行う必要がある。仮想化の設定は複雑になるため、設計・設定ミスが増加することが予想されるだけでなく、他社が利用中のネットワークの設定を変更する際の設定ミスの影響が、各社毎にネットワークを構築している場合と比較して大きいという問題がある。また、物理ネットワーク構成と論理ネットワーク構成が大きく異なるため、各社のネットワークがどのようになっているか把握することが難しいという問題がある。
 　2つ目は、VMwareのVMotionや、XenのXenMotionのような、仮想化環境特有の「ライブマイグレーション」への対応である（図2）。これは、仮想サーバが、サービスを停止することなく物理サーバを超えて移動することができるというものであり、プライベートクラウドのように、ネットワーク全体が同じVLANに所属していれば問題ないが、仮想プライベートクラウドでは、各社毎に異なるVLANを使用するため、移動先の物理サーバ内の仮想スイッチや、その物理サーバまでのスイッチのVLANの設定をライブマイグレーションにあわせて変更する必要がある。このVLANの設定変更は、仮想スイッチのみであればVLANの設定を自動的に修正するような製品も存在するが、ネットワーク全体のVLANの設定を自動的に変更できる製品は本稿執筆時点ではほとんど存在しない。このため、ライブマイグレーション時には、ネットワークの設定は手動で行わなければならない場合が多く、仮想化のメリットを最大限に享受することができないという問題がある。

図2： ライブマイグレーション時のネットワーク設定の変更

OpenFlowの概要
 　OpenFlowとは、2008年より、スタンフォード大学を中心とした「OpenFlowスイッチングコンソーシアム」が提唱している次世代ネットワーク制御技術である（http://www.openflowswitch.org/）。OpenFlowでは、スイッチのパケットを転送する「データプレーン」と、ルーティングの計算などを行う「コントロールプレーン」を分離しており、12情報（入力スイッチポート、VLANID、送信元/宛先MACアドレス、送信元/宛先IPアドレス、プロトコル、送信元/宛先ポートなど）による「フロー」をベースに経路制御を行う。OpenFlowプロトコル1.0が2009年12月31日にリリースされており、現在、OpenFlowプロトコル1.1の仕様を策定中である。
 　OpenFlowを活用することにより、データの流れを柔軟に制御することができるようになるだけでなく、標準化されたプロトコルにより、マルチベンダ環境でも一元制御が可能となる。

 　OpenFlowは、図3のように、「OpenFlowスイッチ」、「OpenFlowコントローラ」、「OpenFlowプロトコル」の3つから構成される。

• OpenFlowスイッチ
  フローテーブルを見てパケットを転送する機能と、OpenFlowのメッセージを交換する機能のみを持ったスイッチ。物理スイッチと仮想スイッチがある。
• OpenFlowコントローラ
  OpenFlowスイッチで構成されるネットワーク全体のルーティングの計算を行い、各OpenFlowスイッチのフローテーブルを作成する。
• OpenFlowプロトコル
  OpenFlowコントローラとOpenFlowスイッチの間のメッセージを交換するためのプロトコル。主に、OpenFlowコントローラで生成されたフローテーブルをOpenFlowスイッチに伝えたり、OpenFlowスイッチの情報をOpenFlowコントローラに伝えるために利用される。プロトコルはOpenFlowスイッチングコンソーシアムによって標準化されているため、マルチベンダ対応が可能である。

図3： OpenFlowのアーキテクチャ

 　フローテーブルは、以下のレイヤ1からレイヤ4までの12の情報により識別される「フロー」と、そのフローに対する「アクション」で構成される。アクションは、Forward、Enqueue、Drop、Modifyの4種類が定義されている。

• レイヤ1情報

- 　送信スイッチポート番号

• レイヤ2情報

- 　送信元MACアドレス
- 　宛先MACアドレス
- 　イーサタイプ
- 　VLANID
- 　VLANプライオリティ

• レイヤ3情報

- 　送信元IPアドレス
- 　宛先IPアドレス
- 　プロトコル番号
- 　ToS（Type of Service）

• レイヤ4情報

- 　送信元ポート番号
- 　宛先ポート番号

 　ネットワークの論理分割の方法としてVLANをはじめとする従来技術を使用する場合は、宛先IPアドレスをもとにルーティングを行うため、図4のように、レイヤ3スイッチ、ファイアウォール、ロードバランサ、レイヤ2スイッチ、サーバなどを垂直に並べる方法が取られた。しかし、企業によっては、ファイアウォールを必要としない場合や、ロードバランサを使用しない場合などが考えられる。OpenFowを使用すると、図5のように、同じ物理構成でありながら、異なる論理構成のネットワークを構築することができるようになる。

図4： 従来技術による論理分割のイメージ

図5： OpenFlowによる論理分割のイメージ

 　仮想プライベートクラウドを実現する方式として、既存技術であるVLANとOpenFlowを活用する場合の比較を表1に示す。OpenFlowでは、レイヤ2までの情報として、VLANID以外に入力スイッチポートや送信元/宛先MACアドレスを利用できるというメリットがある。このため、VLANIDに依存しない論理分割が可能である。特に、仮想サーバのMACアドレスを宛先とするフローを定義しておくことで、ライブマイグレーションに自動的に追随することができる。

表1： 既存技術（VLAN）とOpenFlowとの比較

 　現在、オープンソース・ソフトウェアの仮想スイッチ「Open vSwitch」、同じくオープンソース・ソフトウェアのOpenFlowコントローラ「NOX」、Citrixからリリースされている「XenServer 5.6 Feature Pack 1」の仮想スイッチがOpenFlowプロトコル1.0に対応している。また、NEC、Cisco Systems、Juniper Networks、Hewlett-Packard（HP）、Arista Networksなどのネットワーク機器ベンダがOpenFlowスイッチのプロトタイプを開発している。

 　現在、OpenFlowスイッチングコンソーシアムにて、OpenFlow 1.0の仕様が公開中であり、OpenFlow 1.1の仕様について議論しているところである。そして、NEC、HP、Juniperなどのネットワーク機器各社がOpenFlowスイッチのプロトタイプの開発をしているところであり、仮想スイッチのOpen vSwitchやCitrixのXenServerは、標準でOpenFlowに対応している。
 　OpenFlowは、ネットワークの論理分割が容易かつ柔軟にできるという点や、フローを細かく定義することで、レイヤ4レベルのファイアウォールと同等の機能をインフラ自体で提供することが可能というセキュリティ上のメリットがあり、仮想プライベートクラウドにおいて、標準の技術となる可能性がある。

以上