「OpenFlow」編──その実力以上に期待されてしまった救世主：大原雄介の「最新ネットワークキーワード」【第2回】（2/2 ページ）

[大原雄介，著]

スイッチのためのOpenFlowだったが

　ならば、ルールを外部から制御すればハードウェアはそのままで動作を変更できるようにすれば、ネットワーク機器の構成が自由自在になる。VLAN Tagの設定をいちいち個別のスイッチにアクセスして行う必要はなく、外部でまとめてVLAN Tagを設定して流し込めば、即座に新しい設定に基づくVLANスイッチとして稼働する。

　もっと言えば、L2用のルールをロードすればL2スイッチだが、これをL3用に入れ替えればL3スイッチになるわけで、同様にロードバランサーにもファイアウォールにも化けることになる。例えばルーター内部を三段構成にして、平常時は稼働と待機の二重系としておき、どれか1台が故障したら直ちに待機中の機材と入れ替えるなどはお手の物だし、仮にDDoS攻撃などを受けた場合に社内のサーバーを守るためにロードバランサーとファイアウォールを入れ替えることも、この仕組みでは簡単に可能になる。

　こうした発想に基づいて開発したのがOpenFlowだ。OpenFlowではネットワーク機器の機能を「Control Plane」と「Data Plane」に分離した。Control Planeはルールを格納するデータベースで、Data Planeは、ルール以外の全ての機能を収容する。この制御のためには専用のAPIと、これに対応したOpenFlowプロトコルも用意しており、これを利用することで異なる機器メーカーであってもOpenFlowに対応していれば同じ枠組みで制御や構成変更ができる。

ここに出てくる6種類のスイッチは全てData Planeの機能を持つ機器となる。これ以外にControl Planeの機能を持つ機器を追加して全体の構成を制御する《クリックで拡大》

　これが特定の閉じた規格であれば普及しないが、OpenFlowは、2009年にスタンフォード大を中心に設立した「OpenFlow Swicth Consortium」が標準化を取りまとめて公開している。2011年からは多くのネットワーク関連ベンダーや団体が集まって設立した「Open Network Foundation」がこのOpenFlowの標準化や普及の作業を担っている。仕様は公開しているので、これを利用してOpenFlow対応機材が構築できる。

　しかし、これで問題は全て解決できるほど話は簡単ではない。まず、OpenFlowが対象にしている機器は基本的にスイッチだ。一部の例外はあるにせよ、ルーターやサーバなどはOpenFlowの管理対象外だ（これは、どこまでをルーターとかサーバと呼ぶか、という問題でもあるが）。また、サーバの仮想化機能などとの連携機能もOpenFlowそのものにはない。OpenFlowは、スイッチ管理に関しては便利な技術だが、もっと広範な守備範囲をユーザーは希望している。

　こうした動向に応えるべく登場したのが「SDN」（Software Defined Network）だ。SDNの解説は機会を改めるが、OpenFlowはSDNを実現する重要な手段といえる。実はSDNの定義は曖昧（このあたりは三木氏の記事「【技術動向】SDNはなぜ誤解されるのか」が分かりやすい）だが、一般にはサーバを含めたネットワークインフラ全体を定義する技法であり、その中でスイッチなどの制御を担うのがOpenFlowという理解が一番オーソドックスといえるだろう。次回はその辺りを含めて、SDNを紹介する予定だ。

併せて読みたいお勧め記事

OpenFlowの誤解を知る

• 【技術動向】OpenFlowはなぜ誤解されるのか
• 【技術動向】OpenFlowに対する4つの誤解を検証する