注目を集めるネットワーク制御技術「OpenFlow」（後編）

使える？　使えない？　OpenFlowをめぐる賛否両論

前編に引き続きネットワーク制御技術「OpenFlow」のメリットを解説するとともに、スケーラビリティに対する懸念、それを解決するための動向を紹介する。

公開 2011年08月02日 09時00分

更新 2012年09月04日 14時59分

著者

Shamus McGillicuddy

[TechTarget]

印刷する

　前編「ソフトウェア定義型ネットワークを構築するOpenFlowで何が変わる？」では、OpenFlowの技術解説や製品動向について紹介した。後編では、引き続き技術的な側面を解説するとともに、スケーラビリティに関する課題について紹介する。

OpenFlow対応製品関連記事

OpenFlowアーキテクチャはスパニングツリーの代替となるか

　Big Switch Networksの共同創業者で販売・マーケティング担当副社長を務めるカイル・フォースター氏によると、OpenFlowをベースとするソフトウェア定義型ネットワークは、仮想化に伴う変化に対応できるだけではない。OpenFlowは、コントロールプレーンをスイッチとルータから集中コントローラーに移行させることにより、高度なマルチパス転送手法を実現するという。すなわち、スパニングツリープロトコルの制約を回避するためにTRILLやShortest Path Bridgingに依存しなくても、OpenFlowコントローラー内でマルチパスフローを定義すればいいのだ。コントローラーはネットワークの全体像を保持しているので、ループの発生を防止することができる。

　フォースター氏によると、OpenFlowコントローラーはネットワークのプログラミングも可能にするという。コントローラーのAPIを公開すれば、サードパーティー各社は、OpenFlowコントローラーを利用して高度なネットワーク機能やネットワーク上のサービスを実行するソフトウェアを開発できるようになる。例えば、OpenFlowコントローラー上で機能するロードバランサを開発している研究者もいる。「セキュリティベンダーであれば、OpenFlowコントローラーに定義されたフローを通じて個々のスイッチとルータにセキュリティポリシーを適用する仮想分散型ファイアウォールや侵入防止ソフトウェアを開発できるかもしれない」とフォースター氏は語る。

　Big Switch Networksでは、ネットワーク技術者がネットワークインフラ上にマルチテナントモデルを構築するためのソフトウェアを開発中だ。これはクラウドコンピューティング環境ではとりわけ魅力的だ。技術者はBig Switchのコントローラーを利用することにより、複数の物理スイッチ上のポートで構成される仮想スイッチ作成し、それをサーバとアプリケーションの要求に対応した固定ネットワークとしてシステム管理者に提供することができる。

　「われわれがInteropで行ったデモでは、あるスイッチのポートを2個、別のスイッチのポートを5個、さらに別のスイッチのポートを7個使い、これらを統合して1つの大きな仮想スイッチを構成するというアーキテクチャを示した」とフォースター氏は話す。「ログインした管理者に見えるのは14ポートのスイッチだけだ。これらのポートがデータセンター内の複数の異なる機器に分散しているのは見えない。管理者は1台の物理スイッチ全体を所有しているように感じるが、実際にはそのスイッチは物理ハードウェア上に分散し、隔離・セグメント化されているため、管理者が仮想スイッチをクラッシュさせるような操作をしても、その下にあるハードウェアに障害が起きることはない」

OpenFlowへの期待と現実

　OpenFlowは大きな可能性を持っているが、ベンダー各社が製品をリリースして販売するまでは、このプロトコルは基本的に「科学プロジェクト」にすぎないとGartnerのファビー氏は指摘する。複数の製品が市場に登場するのは2年後になる見込みで、本格的なエコシステムが確立するまでには、かなり時間がかかりそうだ。OpenFlowベンダー各社は現在、ソフトウェア定義型ネットワークの機能を最も必要としているクラウドコンピューティングプロバイダーに狙いを定めている。しかしスケーラビリティも懸念されている。

　無線LANアーキテクチャで活用されているコントローラーと同様、OpenFlowコントローラーもボトルネックを生み出す可能性がある。スイッチとルータが、サーバ上で動作しているコントローラーに転送決定を委ねるからだ。

　「率直に言って、OpenFlowは使い物にならないと思う」とAristaのグーレイ氏は話す。「スタンフォード大学で最も大規模なOpenFlowネットワークのフロー設定率は毎秒500フローだ。しかし現実には、毎秒100万フローが設定されるネットワークに対処する必要がある。OpenFlowがそこまでスケールアップできるかどうか疑問だ」

　しかしOpenFlowベンダー各社もスケーラビリティをめぐる懸念を十分認識しているようだ。フォースター氏によると、Big Switchではコントローラー用のクラスタリング技術を開発中だ。同社では、大規模なネットワーク上の全てのフローを処理できる1つの巨大なコントローラーを構築するのではなく、ネットワークを管理するために複数のコントローラーが協調動作するシステムを開発しているという。

　OpenFlowコントローラーを運用している環境でも、スイッチやルータは従来通り、多数の転送決定を独自に実行する。実際、OpenFlowコントローラーはスイッチやルータの転送判断に頼ることにもなる。フォースター氏によると、OpenFlowアーキテクチャ内のスイッチはダム機器（自ら決定を行わない装置）になるのではない。これらのスイッチは多数のOpenFlowルールを処理し、各種のOpenFlowアプリケーションに対応するために、より高機能になる必要があるという。「コントローラーベースの無線LAN環境のアクセスポイントは、不正アクセス検知や周波数帯域管理などのアプリケーションをサポートするために高機能化が進んでいる」と同氏は指摘する。

　多くのOpenFlow対応スイッチは今後も独自に多数の転送決定を行い、予想外のパケットフローを受け取ったときにだけコントローラーに指示を仰ぐという形になるようだ。

　「スイッチはOpenFlowコントローラーから受け取ったフローベースのルールに基づいてパケットを転送できる」とNECの業務開発ディレクター、ドン・クラーク氏は話す。「多数の仮想マシンが移動してネットワークに頻繁な変化が起きる環境では、事後処理方式で対応することになる。すなわち、ローカルスイッチ上の既存ルールに合致しないパケットを受け取ったときは、最初のパケットがコントローラーに転送される。コントローラーがこのパケットを処理した後で、新たなルールがフローテーブルに設定されるのだ」

印刷する