先日, とある飲み屋で「OpenFlow って何？」と聞かれた際に, 『SDN を実現する一手法』とか『スイッチをプログラマブルに制御する手法』といった辞書的な説明しかその場でできなかった時, 自分の未熟さを痛感しました.
その分野に精通するという事は, 相手に平易な言葉で容易に理解させる事も含んでいると思うので, この場で先日の屈辱を晴らしたいと思います.
『OpenFlow の本質とは？』
NEC の OpenFlow 事業の大物. 岩田氏曰く OpenFlowの本質は「プログラマブルであること」 だそうです.
ここでの話は, OpenFlow での L2 から L4 までのプログラマブル制御により, ヘテロジニアスなネットワークを柔軟かつフレキシブルに設計できるという内容です.
OpenFlow の出発点となった, ネットワーク系のトップカンファレンスの ACM SIGCOMM で発表された論文 においても, オープンプラットフォームにおけるプログラマブルなネットワーク制御という内容が強調されています.
『仕組みや動作はわかったから. じゃあ OpenFlow で一体なにが (実現) できるの？』『既存ネットワークとの決定的な違いは何なの？』という単純な問いに, 長らく簡潔な答えを見出せずにいました.
”ネットワークをプログラマブル制御できる” という命題において「何ができるのか？」という問いは, 「C で何が作れるの？」という問いにほぼ置き換えて考えられるので, 明確な答えを出すのは難しいですが.
プログラミングという手段で, ネットワーク制御の目的のいくつかに的を絞って考えると, 答えは出そうです.
改めて「OpenFlow とは何か？」
僕が考える『ネットワークが OpenFlow である必然性』は次の３つです.
(1) 仮想ネットワークの構築
(2) トラフィックの分散
(3) ネットワークの集中管理
まず, 仮想ネットワークについて.
OpenFlow では, ネットワークに接続する全ての端末をフラットな L2 のセグメントにぶら下がっているものとして扱えます.
またルーティングテーブルにしろ NetFilter にしろ, プロトコルスタックを意識した構造になっていますが. OpenFlow は L2 から L4 までのヘッダ情報を同時に扱えるので, 任意の L3, L4 の仮想論理ネットワークを仮想的に構築でき, そしてこれらをプログラマブルに制御できます.
またトラフィックの分散と, 集中制御を同時に実現できるのが OpenFlow です.
「”分散” と “集中” を同時にって何言うとるんや？」と思われるかもしれませんが. OpenFlow ではデータが流れる経路 (Data Plane) と, OpenFlow スイッチを制御するための経路 (Control Plane) が仕様上完全に分離されているので, 集中制御をしつつトラフィックの分散が実現できます.
ここで本題の OpenFlow v1.1 について.
さて書こうか…と思ったら, 既に内容的に優れている上に日本語で書かれているドキュメントがありました.
OpenFlow ver1.1およびver1.2の追加機能と活用例
これに補足する形で書くと.
OpenFlow v1.1 において取り立てて注目すべき, 特にすさまじい (と個人的に思える) 機能が “グループ” です.
リンク先のページでも書かれているように OpenFlow v1.1 から登場したグループの機能において (スイッチでリンクの死活管理機能がスイッチによってサポートされている場合に限られますが) ネットワーク障害を想定したフロールールの記述も可能になり, コントローラ側でリンクや機器の死活管理処理を記述しなくても, 障害が発生したケースだけを想定すればいいので, より簡単に堅牢なネットワークの設計ができます.
また同じくグループの select タイプの処理によって, v1.0 ではコントローラにパケットを運ばないと実現できなかったロードバランサのような機能も, スイッチ側だけで実現できるようになっています.
さらに同じメカニズムで, 物理的に並列に這わせたリンクを仮想的に一つのパスとして扱い, 回線能力以上のスループットと冗長性を上げる link aggregation (UNIX では bonding と呼ばれている) 処理を実現できます.
OpenFlow v1.1 によって, 制御の自由度や柔軟性はグッと上がりました. また, これまでコントローラ側で行わなければできなかった事も, スイッチに適切なフローを定義してやればスイッチ単体で実現できてしまうので, パフォーマンスも格段に上がることが期待できます.
ただこれを実現できるまともな環境が無いのが, 現時点での悲しいところです. もちろん全く環境がないわけではありません. Stanford Reference Switch として知られる OpenFlow スイッチのソフトウェア実装では, 早くから OpenFlow v1.1 に対応されているので実験的な事はこれを使ってできるのですが. これ自体がユーザランドのプログラムなので, スイッチがボトルネックになる懸念があります.
また, NOX にしろ Floodlight にしろ Trema にしろ 現時点での最新版において各コントローラが OpenFlow v1.1 に対応してないので, そもそも v1.1 機能は使えません.
先日 GNU/Linux のメインラインにマージされた頼みの OpenVSwitch の最新版 (v1.4.1) もまだ OpenFlow v1.0 ベースです.
しかし 前回 紹介したように, OpenFlow 1.1 及び 1.2 対応は OVS コミュニティにおいて進められているようなので, スイッチ／コントローラ双方における OpenFlow v1.1 完全サポート版の登場が待ち遠しいです.
最近のコメント