4-31

ネットワークSDN（ネットワーク仮想化）の動向

2伊勢 幸一3●株式会社データホテル 執行役員 CTA

OpenFlow 以外に定義を拡大して注目される。大手企業によるベンチャーの買収も活発に。クラウドコントローラーとの統合が進められる。

45■これまでの経緯

者の間で評価と検証、そして議論が巻き起こった。

おそらく風説に過ぎないとは思うが、SDN とさらに、2011 年 2 月に OpenFlow スイッチ仕様

いう単語は OpenFlow 開発の中心人物であるス

1.1 が公開された直後、NEC が世界初の Open-タンフォード大学のニック・マキューン（NickFlow 対応スイッチ機器をリリースした。同時にMcKeown）氏に対し、ネットワーク技術に疎いグーグルやフェイスブック、マイクロソフト、ド記者が取材した時に生まれたそうだ。その記者がイツテレコム、ベライゾン、ヤフーなどの企業にOpenFlow についての解釈を「つまり OpenFlow

よって、OpenFlow の開発と標準化、そして新しとは Software Deﬁned Network ということですいアプローチである Software-deﬁned Network-か？」と聞き返したところ、ニック氏が半ば呆れing の利活用を推進する団体として ONF（Openて「そうだ」と答えてしまったからであるとされNetworking Foundation）が設立された。ている。

ニック氏がワークショップを開催した当時、

し か し 、そ の 後 ニ ッ ク 氏 も そ の 表 現 を 気 にそもそも SDN とは OpenFlow スイッチの動作を入ったのだろう。2009 年 8 月に彼が中心となり

OpenFlow コントローラーのソフトウェアプログ

米国スタンフォード大学で「Software-deﬁnedラムで制御することを示していた。その後 ONF

Networking（以後 SDN）and OpenFlow」といはその解釈を拡大し、データプレーンの方式に拘うキャンパストライアルワークショップを開催

わらず、SDN とはソフトウェアでプログラミンし、ここで SDN という単語が始めて公式に用いグ可能なネットワークアーキテクチャーを指すられた。OpenFlow の仕様策定や実装の開発はと定義した。それまで OpenFlow と SDN はほぼ2007 年頃から始まっていたが、このトライア同じ意味で論じられていたが、この新しい定義

ルワークショップの直後である 2009 年 11 月にによって、OpenFlow は技術仕様であり SDN はOpenFlow スイッチ仕様 1.0 が公開されることとアーキテクチャーであるという棲み分けがなさなる。

れたのである。

以後、OpenFlow と SDN はネットワーク関係者の注目を集め、さまざまな団体やベンダー、利用

196

第4部

製品・技術動向■ SDN コンポーネント

ネットワークサービスへのアクセスを提供する

SDN コンポーネントは、ネットワークを利用コントロール層で構成される。アプリケーショするアプリケーション層、ネットワーク機器やンがネットワークサービスを利用するためのイインターフェース、ケーブルなどのネットワーンターフェースを Northbound API と、ネットクデバイスであるインフラストラクチャ層、そワークデバイスがコントローラーに対してサーしてアプリケーションとインフラストラクチャビスを提供するインターフェースを Southbound

間をデカップリングし、両者に対して透過的なと API と呼ぶ（資料 4-3-3）。

1

23

資料 4-3-3 SDN アーキテクチャーコンポーネント

45

出典：筆者作成

OpenFlow の場合、OpenFlow プロトコル、おアクセスするシステムコールが Southbound API

よびスイッチとコントローラー間の通信ソフであり、ユーザが Vyatta を操作するコマンドがトウェアが Southbound API である。ONF では

Northbound API に相当する。

Northbound API を議論するグループを結成してはいるが、本稿執筆時点で OpenFlow の仕様にNorthbound API は含まれていない。

■ SDN の導入状況
SDN が OpenFlow だけを対象としているかぎ

また、Linux OS が提供する仮想ブリッジ機り、その適用対象は、通信路の形成だけをビジネ

能を Vyatta などのソフトウェアルーターで制御スとし、OpenFlow で構築したネットワークと旧する場合、Vyatta が SDN コントローラーであ来のネットワークで提供するサービスを完全にり、Linux の仮想ブリッジがネットワークデバ別々のネットワークサービスとして提供できるイスである。そして Vyatta が実行する Linux の通信キャリアの広域ネットワークに限定される。

brctl コマンドや、仮想ネットワークデバイスをしかし、コンピューティングリソースの提供を第4部

製品・技術動向

197

1

2

目的としたデータセンターでは、データセンター理ネットワーク、すなわちスイッチやルーターで棟を丸々新築する場合でもないかぎり、ネット構成された VLAN ではなく、ソフトウェア的にワーク基盤全体を OpenFlow スイッチに入れ替テナント別のネットワークドメインを定義できえることは考えられない。また、既存ネットワー

る SDN 仮想ネットワークが、この環境を支えるクと OpenFlow ネットワークが混在する環境でネットワーク基盤としてフィットするのだ。

同じ顧客のサーバーシステムを運用することは

3

45

非常にリスクが高く、また顧客も望んではいない■ SDN 業界の動向だろう。このように、旧来の SDN はネットワー

SDN の 主 要 な プ レ イ ヤ ー と し て は 、ま ず 、

ク接続ではなくコンピューティングリソースをOpenFlow プ ロ ト コ ル の 開 発 と Open vSwitch

主たる商材としている事業者への適用性が低く、の実装を手がけた旧ニシラ（Nicira）を買収し通信キャリア以外の事業者にとって SDN は研究たヴィエムウェアや、世界で最初に OpenFlow

検証以上の興味を引くことはなかった。

スイッチハードウェア製品をリリースした NEC、

ところが、Southbound API が OpenFlow だけ

OpenFlow コントローラーを提供するビッグ・ス

ではなく、あらゆるネットワークデバイスを網羅

イッチ・ネットワークス（Big Switch Networks）

するとなると事情が変わってくる。つまり、デーなどの OpenFlow 勢がある。それに加え、SDNタセンターやホスティング事業者が OpenFlowをソフトウェアパッケージとして提供するストスイッチを新たに調達しなくとも、イーサネッラトスフィア、ミドクラ、あくしゅなどの国産勢

トや IP ネットワークといった既存の物理ネットと、シスコシステムズ、ジュニパーネットワークワークシステム上で柔軟な仮想ネットワークト

ス、ブロケードコミュニケーションズなどのネッポロジーを形成できることは、サーバーやストトワーク機器ベンダーなどがある。また、大手企

レージ、ミドルウェアといった彼らのビジネスリ業による SDN ベンチャーの買収も活発であり、ソースをさらに効率的に運用できる可能性をも前述のヴィエムウェアはニシラを買収し、ブロたらす。このデータプレーンフリーなアーキテ

ケードコミュニケーションズはソフトウェアルークチャーに、まずクラウドサービスを提供するターであるビヤッタ（Vyatta）を、シスコシステ

IaaS 事業者や IaaS ソリューションプロバイダー

ムズはヴイサイダー（vCider）を買収し、ジュニが飛びついた。

パーネットワークスはコントレイルシステムズ

クラウド IaaS サービスにとって、同じ物理ネッ
トワークとサーバー上に異なる顧客のテナント（Contrail Systems）を買収して、それぞれ SDNマーケットにおける体制を整えつつある。

システムを共存させる場合、個々のテナントネッ

さ ら に SDN の Northbound お よ び South-

トワークセグメントを物理的もしくは論理的にbound API の 標 準 化 と オ ー プ ン な 実 装 を 開 発

分離し、双方のセキュリティを確保する必要がす る こ と を 目 的 と し て 、Linux Foundation がある。従来、IEEE802.1Q VLAN によって論理OpenDaylight プロジェクトを発足した。この的に分離はしていたが、VLAN ID の上限問題やプロジェクトにはシスコシステムズ、ジュニパー

VLAN を切り直す作業がほとんど手動による変ネットワークス、ブロケードコミュニケーション

更であったため、敏速なテナントセグメントの形ズの他、ヴィエムウェア、マイクロソフト、レッ成要求に対応することが難しかった。そこで、物ドハットなどの OS、仮想化ハイパーバイザー

198第4部

製品・技術動向ベンダーも参加している。これは、ONF による分野へと拡大していかなければならない。そのSDN の定義通り、対象とするデータプレーンがためにも、OpenStack や CloudStack、ヴィエムOpenFlow スイッチだけではなく、彼らが提供すウェアの vCenter などの、クラウド IaaS 基盤コるさまざまなネットワークデバイスを網羅するントローラーとのインターフェースを提供してアーキテクチャーであることへの証でもある。

いく必要があり、Northbound API の重要性が高1

2

まっている（資料 4-3-4）。そして、SDN は単に■今後の課題ソフトウェアによるプログラマブルネットワー

今まで SDN ソリューション各社は OpenFlow

クのアーキテクチャーとしてではなく、仮想マシを主体とした通信キャリアへの提案と導入に終ンやストレージ、アプリケーションといったコン始していたが、今後はその適用範囲をデータセピューティングリソースにネットワークサービンターやホスティング、クラウド IaaS 事業者とスを提供するプラットフォームへと進化していいったコンピューティングリソースを提供する

くことであろう。

45

資料 4-3-4 クラウド基盤と SDN

出典：筆者作成

実際に、現在も SDN とクラウドコントロー

3事業者への導入に苦労している。

ラ ー と の 統 合 化 が 盛 ん に 実 施 さ れ 、各 社 と もなぜならば、現状の SDN ソリューションは、仮

vCenter や OpenStack との連携運用をサポート

想ネットワークやネットワークファンクションする機能を開発し提供してきた。しかし、それを、サーバー上で動作する KVM や Xen、vSphere

らのソリューションは主にクラウド IaaS 事業者といった仮想化ハイパーバイザーを介して仮想マへの適用に留まり、いまだ、どの SDN プロバイシンインスタンスへ提供する方式だからである。

ダーもデータセンターやホスティングといったクラウド IaaS 事業者は基本的に仮想環境上でコ

第4部

製品・技術動向

199

1

ンピューティングリソースを提供するため問題はないが、一般的なデータセンターやホスティング事業者では、仮想マシンでのサービス提供よ2

りも、ベアメタルサーバー（物理サーバー）でのサービスの方が圧倒的に多い。したがって、仮想環境でしか機能を提供することのできない SDN

3ソリューションを導入する意味があまりない。
今後、データセンターやホスティングマーケッ
トに SDN を提供していくためには、仮想環境だ4けではなく、ベアメタル環境に対しても仮想ネットワークやファンクションを提供する機能が望まれてくるだろう。事実、2013 年 5 月にステル

5

スモードを解いたプラムグリッド（PLUMgrid）
社は、ハイパーバイザーだけではなく、ベアメタルサーバーに対してもプログラマブルなネットワークサービスを提供する機能を実装し、現在パートナーであるデータセンター企業との共同検証を実施している。OpenDaylight で開発中のSouthbound API の標準化とオープンソース化も同じことを目的としており、今まで SDN で制御することが難しかった物理ネットワークデバイスやベアメタルサーバー、ストレージをサポートしていくことが、今後の SDN において重要なポイントとなっていく。

200

第4部

製品・技術動向