OpenFlowの管理機能を拡張する「FlowVisor」【前編】
YouTubeによるLAN混雑も回避? 「FlowVisor」の効果と課題
OpenFlowコントローラーとOpenFlowスイッチとの間のプロキシとして機能し、複数のネットワークスライスを構築可能にする「FlowVisor」。その仕組みと現状の課題を解説する。
OpenFlowをベースとするネットワーク仮想化プラットフォームである「FlowVisor」は、オープンなSoftware Defined Network(SDN)の機能をさらに高め、物理ネットワークを複数の論理ネットワークに簡単に分割することを可能にする。これにより管理者は、大まかに定義されたルールでネットワークを管理することが可能になり、多数のルータやスイッチを設定する苦労から解放される。
汎用型のハードウェアにインストールして使用するFlowVisorは、特殊なOpenFlowコントローラーであり、OpenFlowスイッチのネットワークと標準的なOpenFlowコントローラーとの間で透過的なプロキシとして機能する(OpenFlowコントローラーについては「【技術解説】OpenFlow/SDNの自在な経路制御を実現する技術」を参照)。まだ試験段階にあるFlowVisorは、コマンドライン型の管理ツールといった基本的な機能が欠落してはいるものの、米スタンフォード大学のキャンパスネットワークに導入されるなど、一部の業務環境で大規模に導入されている。
FlowVisorは、抽象化レイヤーを通じて物理ネットワークを分割する。これは、ハイパーバイザーをサーバのハードウェアとソフトウェアの間に置き、複数の仮想OSを実行できるようにするサーバ仮想化の仕組みに近い(参考:比較表で徹底解明! 各サーバ仮想化製品の特徴と違い)。FlowVisorは、帯域幅やCPU利用率、フローテーブルなどを管理する。
サーバ仮想化のハイパーバイザーが、標準のx86命令セットを利用してサーバを仮想化するのと同様、FlowVisorは標準のOpenFlow命令セットを利用してOpenFlowスイッチを管理する。OpenFlow命令セットは、パケットのヘッダテーブルに記述された特性に基づき、パケット転送方法に関するルールを設定する(OpenFlowの制御方法については「【技術解説】OpenFlow/SDNの自在な経路制御を実現する技術」を参照)。
ルールは全てフローテーブルで定義されるため、帯域幅やCPU利用率にオーバーヘッドの影響が付加される可能性は低い。ただし、フローテーブルのルールを設定するために、専用の物理コントローラーが必要になる。
ネットワークの分割によってSDNを実現
FlowVisorによるネットワークの基本要素がネットワークスライスだ。ネットワークスライスは、ネットワーク動作の範囲を規定するルールを含む、テキストベースのコンフィギュレーションファイルによって定義される。設定可能なルールとしては、「許可」「リードオンリー」「拒否」などがある。
FlowVisorを使うと、セキュアなTelnetトラフィック(デフォルトではポート992を使用)を専用のスライスへ割り当てる一方で、経営陣のIPアドレスを別のスライスへ割り当てる、といった運用ができる。そして、この2つ以外の全てのトラフィック用に3つ目のデフォルトスライスを作成したり、これらの3つのスライスを監視する障害診断用のリードオンリースライスを設定することも可能だ。
ネットワーク管理者は、こうしたスライスの動的再割り当てと個別管理ができる。例えば、YouTubeを見ている受付係が、Telnetベースのアプリケーションや経営陣が利用する帯域幅に悪影響を与えるのを防ぐことができる。
スライスの分離はFlowVisorの仮想化機能の重要な部分だが、実験的な技術であるFlowVisorにおいては、まだ進化途上の部分でもある。例えば、FlowVisorについて説明した学術論文によると、スライス間でスイッチCPUを厳密に分離することが必要だが、現時点では十分な分離は不可能である。スイッチCPUは、OpenFlowを通じて間接的に管理するしかないからだ。
こうした制約や進化途上の機能を考慮すると、FlowVisorを利用する場合、以下の5つの要素に注意する必要がある。
- 帯域幅:1つひとつのスライスは、利用可能な帯域全体に対して一定の割合を専用領域として確保しなければならない
- トポロジー:1つひとつのスライスは、物理・仮想のスイッチやルータを含むネットワークノードに対して独自の視点を備えなければならない。FlowVisorは、OpenFlowコントローラーからは通常のスイッチとして、OpenFlowスイッチからはOpenFlowコントローラーとして見えるようにする
- トラフィック:トラフィックは、上記のルールに基づいて特定のスライス(またはスライス群)に常に拘束されていなければならない
- デバイスCPU:過負荷状態にある物理スイッチは、スローパス(高速化されていない)パケットを廃棄できる。ネットワーク管理者は、OpenFlowの統計情報カウンターやルールを更新することにより、FlowVisorがCPUリソースを考慮するようにしなければならない
- 転送テーブル:転送テーブルは、物理デバイスに拘束されている場合が多い。ネットワーク管理者は、1つのスライスが特定のデバイスの転送テーブルを飽和状態にしてしまい、他のスライスのルールを廃棄させないようにしなければならない
後編は、FlowVisorの想定利用形態やリスク、今後の方向性について解説する。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
新着ホワイトペーパー PR
-
製品資料
[株式会社MatrixFlow] 「物流リソース最適化」ガイド:人員・配車・傭車を出庫依頼の確定前に決めきる -
製品資料
[株式会社キーエンス] なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは -
製品資料
[株式会社セールスフォース・ジャパン] 「CRMは設計と無関係」は本当か? PLMとの融合で実現する高速開発 -
事例
[日本ヒューレット・パッカード合同会社] AIエージェントの時代にどう備える? 「新たな働き手」を支える3要素とは -
製品資料
[日本ヒューレット・パッカード合同会社] “横並びの自動化”から脱却、AI活用で生産性と競争力を高める秘訣
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
2
法務と開発者で「言葉が通じない」問題 トヨタやソニーが語るOSS管理の真実
-
3
なぜ「Gemini 4 Argon」は出遅れたのか? Googleが狙う“逆転のシナリオ”
-
4
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
5
情シスの約8割が転職や退職を意識 調査で分かった“辞めたくなる最大の理由”
-
6
ChatGPTは“検索しまくり”でGeminiは“淡泊”? データが明かすAIの裏側
-
7
情報漏えいはなぜ繰り返されるのか 今すぐ見直すべき「境界」
-
8
「Wi-Fi 7」経由でWindowsが乗っ取られる? 最高権限奪取の恐怖
-
9
「結局使わなくなる」Microsoft 365 Copilotを半年で定着 キリンの3施策
-
10
「中堅・中小企業のネットワーク・セキュリティ運用実態」に関するアンケート
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
2
家庭用Wi-Fiルーターの業務利用は危険? 避けるべき理由と具体的な対策
-
3
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
4
財務部門がAIを最大限に活用する方法 無駄のない戦略的リーダーシップへの道
-
5
LLMが兵器化? 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
6
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
7
なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは
-
8
生成AIを開発に導入しても効果が見えない? 実証実験で分かった成果と課題
-
9
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー