OpenFlowによるコンフィグ可能なL2のデモ

2011/6/17-1

ShowNetでOpenFlowを利用したデモが行われていました。デモは、NECの「UNIVERGE PFシリーズ」を利用しています。

OpenFlowは、従来のL2スイッチのようにMACアドレスやVLAN TAGを使ってスイッチングを行うのではなく、各パケット(もしくはフレーム)が持つMACアドレス・VLAN TAG・IPアドレス・TCP/UDPのポート番号というような「フロー」と呼ばれる情報(OpenFlow仕様では「タプル」とよぶ)を使ってスイッチングを行い、経路を柔軟に設定できるようにする標準化規格です。 OpenFlowは、スタンフォード大学が中心となり標準化が進められており、NECは当初から標準化に参加しているメンバーです。

参考: OpenFlow

プログラマブルフロースイッチ

OpenFlowでは、コントローラと呼ばれるサーバがネットワーク上のスイッチのフォワーディングテーブル設定を行う中央集権モデルです(*)。スイッチは、コントローラから入力される情報を反映するという単純な機能を実現することに徹しています。そのため、各スイッチはSTP(Spanning Tree Protocol)などの冗長化プロトコルを利用しません。

さらに、特定のMACアドレスを持つパケットを破棄したり、ブロードキャストパケットを制限するなどの細かい制御も可能です。特定のフィールドをフォワーディングの判断に利用しないなどの設定も可能であるため、全く同じIPアドレスを持つ複数の機器を同じ物理セグメント内に設置しつつ外部と通信させることも出来てしまいます。

割と「何でもアリ」に近い柔軟さがNECの「UNIVERGE PFシリーズ」によるOpenFlowの特徴なのかも知れません。

(*) コントローラをスイッチごとに配置することで中央集権モデルによるSPOF(Single Point of Failure)を回避するモデルも検討されているようです。

Interop Tokyo 2011でのデモ

Interop Tokyo 2011 ShowNetでは、6ホールにData Center Boothが構築されました。 Data Center Boothでは、仮想東京DCと仮想大阪DCというネットワークが構築され、それらは一度バックボーンネットワークを通るように設定されました。これは、東京と大阪という地理的に分散したデータセンターを「仮想的に一つのデータセンター」として運用するというコンセプトをデモするためです。

仮想東京DCと仮想大阪DC間は、ShowNetバックボーンを通じてL3で接続されています。その間をVPLS(virtual private LAN service)で接続しつつ、PBB(Provider Backbone Bridges)を利用して同一セグメント内でFDB(Forwarding DB)に登録されるMACアドレス数が爆発しないように設計されています。

このうようなVPLS+PBBで構築された広域イーサネット仮想データセンター上で、NECのOpenFlow対応スイッチ「UNIVERGE PFシリーズ」を利用して「１つの仮想データセンター運用」をイメージしたネットワークを構築したデモを行われました。

3拠点デモ

このデモンストレーションでは3拠点の物理的に離れたネットワークに、4つの仮想ネットワークを割付け、それぞれ仮想ネットワークでは同じネットワークアドレスを使った構築をしています。 1つ目の拠点がNECブース内に設置された「仮想本社」です。その他の2拠点は、6ホールのData Center Booth内にある仮想東京DCと仮想大阪DCです。これらを統合したものを仮想データセンターネットワークとしてデモが行われていました。

デモは以下のようなものです。

1) 東日本は東京DC、西日本は大阪DCにアクセス（宛先は同じアドレス、送信元による振り分け）

2) 東京DCから大阪DCへのサーバリソースの移動（同じサーバセグメント内での移動）

3) 東京DCから大阪DCへのシステムの移設（ロードバランサの仮想IPをポーリングして稼働監視、返信がなかったら切り替え）

4) 東京DCの災害時の、大阪DCへの切り替え

こうした切り替えは、既存のネットワーク技術でもレイヤごとに個々に設定していけば可能でしたが、これをコントローラから一括して設定したところが今回のデモの肝であるようです。

OpenFlowって面白いよね。でも、、、、

今回のデモは非常に面白いのですが、個人的な感想としては、OpenFlowの解説で良く表現されている「フロー単位」の制御とは多少違うところで進化が進んでいる気がします。

今回のデモは、フロー単位で何かをしているわけではなく、フロー単位でスイッチングが可能にするために構築したOpenFlowの柔軟な仕組みを利用して、特殊なスイッチング経路を組める事を示したものといえそうです。言い換えると、OpenFlowの名前の中にもある「フロー」であることよりも、実現するにあたっての「Programmable Networks」が肝になりつつある気がします。

スイッチングの全てをプログラマブルにするという思想そのものは、無茶に聞こえる部分がありつつも、現時点で様々な場所で運用されている方法を考えるとうなづける点もあります。現時点では、各スイッチは自律的に動作することを前提に設計されていますが、全体として「想定通り」の動作になるように自律的な動作を計算しながら設置と設定が行われます。そういう意味で，OpenFlowはSTPの挙動に一喜一憂するような現状に対するアンチテーゼなのかも知れません。

OpenFlowの本来の特徴である部分も「何かありそう」な気もします。 L2レベルでL4情報を利用してスイッチングを行えるので、激しくレイヤーバイオレーションをしているのですが、可能性の片鱗は強く感じます。でも、実際に「何するの？」という話になると「でも、それって○○でも出来るし、製品としては××があるよね」という状況になっているのが現状な気もします。たとえば、フローだけをどうにか制御するという意味ではフロールータという分野がありますし。

「これだ！」というユースケースが登場すれば化ける可能性もありそうなネタだと思った今日この頃です。