5-3ネットワーク

1SDN/NFV におけるネットワーク仮想化技術の動向
2伊勢 幸一3●テコラス株式会社

標準化や推進団体の動きは一段落。インフラ事業者での SDN 導入は期待ほどではないが、ベアメタルで必要に。キャリアの NFV でも SDN が求められる。

456

2013 年以前に比べて 2014 年には、仮想ネットも 一 段 落 し た 。Open Network Foundation とワークや SDN に関して注目すべきアナウンスやOpenDaylight はそれぞれ、OpenFlow の標準化と大きな変化はそれほど見当たらなかった。これはSDN 標準 API の実装を粛々と実行している。加えSDN 関連業界のトーンが落ちたということではなて欧州電気通信標準化機構 ETSI に、キャリア系

く、むしろある程度 SDN 周辺技術や導入意義、問NFV の標準化を図る ISG（Industry Specification

題課題などが議論されつくし、広く認知され、各Group）が新たに設置された。

所に浸透したからと見たほうがよい。

ユーザー事例では、データセンター事業者やキャ今回で第 3 回を迎えたイベント「SDN Japan

リア事業者に代表される IT 関連企業だけではなく、2014」では、SDN 関連技術や実装、製品、ソリュー医療や流通、金融、鉄道など非 IT 企業への SDN 導ションの紹介だけではなく、導入事例や応用事例、入実績なども散見されている。しかし、事例が増ユーザー事例の発表が増えた。これは、仮想ネッ

えてきたとはいえ、2013 年以前のカンファレンス

トワークと SDN のステータスが、発案、実装、検では提供者側のプレゼンテーション一色だったの証、から導入、運用のフェーズにシフトし始めたが、わずかではあっても利用実績が現れたということを意味する。

程度であり、あくまで仮想ネットワークと SDN がま た 、か つ て 仮 想 ネ ッ ト ワ ー ク 時 代 の デ ーコンピューティングシステムを構成する一つの要タプレーンとして、フロードライブを採用した素技術に加えられたということに過ぎない。現在

OpenFlow だけに焦点が当てられ、SDN と言えば稼働中のデータセンターやクラウド IaaS システム

OpenFlow であるというほどの存在であった。それでは多くの場合、VLAN や LAG といったレガシーもある程度コモディティ化し、VXLAN や NVGRE、な仮想化技術が利用され、SDN ではなくオープン

IEEE 802.1q VLAN、IEEE 802.1ax（ad）LAG とソースやオペレータによる自作のツールによって同様に、OpenFlow は仮想データプレーンを実現

辛うじて半自動化し、運用されている。

する一つの選択肢でしかないという立ち位置に落■インフラ事業者動向

ち着いたようである。
ま た 標 準 化 や 推 進 団 体 の 乱 立 、合 従 連 衡

246

第 5 部 製品・技術動向

元々仮想ネットワーク技術は、仮想コンピューティングインスタンスをオンデマンドで提供する

ろか運用設計に加え運用学習、コントローラ保守

クラウドサービスにおいて、マルチテナントクラという追加作業が発生し、運用負担を増加させる

スタをハードウェアリソースから分離独立してデ結果ともなりかねない。

プロイするための手段として提案された。そして、

また、現在提案されている SDN は、そのデータその仮想ネットワークを形成するアーキテクチャプレーンとして物理的なネットワーク機器ではなとして SDN が提案された。

く、ハイパーバイザ上の仮想ネットワークを対象したがって、仮想ネットワークと SDN が対象ととしており、仮想レイヤーを介してハードウェアするビジネスは、データセンターやホスティング、をドライブする。そのため、パフォーマンス的なクラウド IaaS 事業者などのインフラ事業者であっオーバーヘッドを少なからず内包することになる。

た。しかし実際の所、SDN ソリューション提供者

SDN ソリューションに期待することは、自社が期待していたほど、これらインフラ事業者へのサービスの品質向上とコスト削減であるが、デー導入ラッシュは発生しなかった。

タセンターなどのインフラ事業者が SDN 導入に躊

SDN ソリューションが顧客対象としている従来躇する理由は、それらを両方とも享受できないの型のデータセンターやホスティング事業者では、たではないかという懸念からである。SDN の導入ととえクラウドサービスに参入したとしても、AWS浸透を妨げているのは、これら新たに発生する運（Amazon Web Services）やマイクロソフト Azure用設計、開発、学習、保守作業の発生であり、これのように完全に仮想環境に閉じ、かつ独立した新らを誰が負担するのかということが問題である。

12

3

4

5

規サービスとして提供しているわけではない。以前から提供している専用サーバーや共用サーバー、

6■ベアメタル動向

レンタルサーバー、オンプレミスなどさまざまなしかし、インフラ事業者にとって SDN が全く不サービスの中の一つとして提供している。そのた必要であるというわけでもない。昨年のインターめ、ネットワーク全域を単一の SDN アーキテク

ネット白書で予想したように、2014 年はクラウドチャで運用するのは困難であり、またその必要性基盤におけるベアメタルサーバー（物理サーバー）もない。の利用方法が議論の中心であった。

たとえ新規で他のサービスから完全に独立した仮想インスタンスとエンドポイントオーバーレクラウドサービスを展開するとしても、SDN ソ

イネットワークによるマルチテナント環境は、すでリューションは、従来のネットワーク機器のように数々の実装とユースケースがある。一方、よりに調達し、設置し、設定するだけで導入が完了するコンピューティングリソースを必要とするヘビーわけではない。SDN の導入には、新たな運用設計ユーザーにとって、仮想マシンではなくベアメタが必要となり、その設計を実現するため API を用ルマシンを利用したいという要望がある。特にスいてコントローラを開発し、検証しなければならタートアップに成功し、ある程度の利用者数を確ない。また、サービスの追加や変更に伴い、SDN保したアプリケーションサービスプロバイダーは、コントローラのプログラムもアップデートする必コンピューティング基盤の柔軟性や即時性よりも、要がある。さらに、運用担当者にとって、従来と常に最高の性能を優先するようになる。自動的に異なるアーキテクチャとオペレーションは学習コプログラムのインタプリターや OS 以外のレイヤーストが高い。つまり、運用コストを削減するどこの介在を歓迎するものではなく、経済的に許容で第 5 部 製品・技術動向

247

12

きるならばベアメタルサーバーを望むのは当然でNetwork Install Environment）をサポートするホあろう。

ワイトボックススイッチがリリースされている。そベアメタルサーバーをコンピューティングとしして、expect や Ansible などの、ssh や NETCONFて提供する場合に問題となるのが、TOR（Top Ofのラッパーユーティリティを使い、SDN コントローRack）スイッチ上でのセキュリティである。

ラからベアメタルスイッチを直接、動的にコンフィ

ベアメタルサーバーをユーザーに提供する場合、3

4

5

そのサーバーのルート特権は利用者側に提供され実際、これらを利用するとしてもスイッチをコる。そのサーバーで不容易に DHCP サーバーなどンフィグレーションするドライバーを開発する必を起動されると、他のテナントのサーバーがブー要がある。しかし、レガシーな CLI コマンドによトするときに、本来与えられるべき IP アドレスとるコンフィグレーション経験があれば、比較的直は異なるアドレスが割り当てられてしまう。

感的にモジュールを記述できることから、前述のまた IPMI ポートが他テナントのサーバーと同じような新たな API フレームワークによる SDN ほどスイッチに接続されていると、他のテナントユー学習コストが高くない。そのため、現状、インフザーから勝手にサーバーを再起動されたり、サーラエンジニアには歓迎され、活用されている。

バーの状態をモニターされたりすることになる。
したがってベアメタルサーバーを提供するため

6

グレーションすることが可能になっている。

■キャリアでの SDN 利活用には、そのデプロイのタイミングでスイッチ側にこれらネットワーク仮想化技術や SDN などは、テナント単位に分離された LAN セグメントを形成

元々、仮想インスタンスをオンデマンドでデプロする必要がある。そして、これらをクラウドコンイし利用者に提供するという、クラウドサービストローラ上のオペレーションと連動するために、の拡大化に伴って発生した需要を元にしている。

SDN が必要なのだ。

しかし、実際には前述したようなさまざまな理由

これまで議論されているネットワーク仮想化技
術はサーバー上で動作する仮想化ハイパーバイザにより、インフラ事業者にとって中々受け入れ難い状況ではある。

上で実現されるエンドポイント型である。実際の一方でその逆に、ネットワーク接続サービスを提物理ネットワークを構成するスイッチやルーター、供しているキャリア系事業者が、ネットワーク仮想そしてベアメタルサーバーへの適用は後回しにさ化技術や SDN の有益性を見出しはじめた。その牽れていた。

引力となっているのが NFV（Network Function

シスコシステムズ社の OnePK やジュニパーネッVirtualization）である。

トワークス社の NorthStar のように、ベアメタルキャリアにおける NFV の対象は、インフラ事のスイッチやルーターをコントロールする API や業者における DHCP やロードバランサーなどではコントローラ製品も提供されてはいる。しかしそない。従来はキャリア網内やユーザー側エッジにれらはベンダー独自の実装であり、また対象とな設置されたアプライアンス製品によって提供しる機器もベンダー製品に限定され、オープン性にてきた、ファイアウォールや DPI（Deep Packet

乏しい。

Inspection）、IDS（Intrusion Detection System）、わずかに数社から、ブート時にオープンな LinuxIPS（Intrusion Prevention System）、SSL-VPN と風 OS を選択的にインストールできる ONIE（Open

いった、ネットワークに閉じた機能などを仮想サー

248

第 5 部 製品・技術動向

バー上に実装し、任意のテナントネットワークにCompute Project Japan（OCP Japan）の PoC-WG対して適用するというアーキテクチャである。と、オープンなクラウド実装を検証するオープンこれまでキャリアは、テナントごとに高価アプクラウド実証実験タスクフォース（OCDET）によライアンスを個別に調達し、それぞれを運用しなける共同実証実験では、OpenStack のベアメタルプればならなかった。そこで NFV によって、一般的ロビジョニングである Ironic と、ネットワークコなサーバー上で複数の NFV コンポーネントを実現

ントローラの Neutron、そしてキュムラスネットすることで、導入運用コストを劇的に削減できる。

ワークス（Cumulus Networks）社のベアメタル

この場合、仮想インスタンスが提供するネットスイッチとの連携運用の検証が開始された。
さらに、2014 年 11 月にマネージドサービス事ワークに対して提供する。このとき、NFV コンポー業各社により、日本 MSP 協会が発足した。日本

ネントのネットワークとユーザーのネットワーク

MSP 協会では、ベアメタルやクラウド、仮想ネッ間を、仮想ネットワークによって接続する必要がトワーク、SDN に関する運用技術の共有とガイドあるのだ。

ラインの整備策定に着手している。これらの活動

そのため、NFV のデプロイに伴って仮想ネット

は、ネットワーク仮想化技術が、実装や検証ではワークを形成する必要があり、ネットワークを物理なく運用フェーズに入り、実際のサービスで活用層から分離し形成することを可能にする仮想ネッされ始めていることを示している。

トワークと SDN が必要とされたのである。この動

しかし、インフラ事業者が仮想インスタンスからきは、ESTI NFV IGS という標準化団体による活ベアメタルへとシフトし始めたのとは逆に、キャリ動に国内キャリアが積極的に参画していることか

アではアプライアンスというベアメタルから NFVらも、今後ますます実用化や適用事例などの公表という仮想インスタンスに基盤がシフトしてきたが期待される。という事実は興味深い。歴史的に、仮想と物理（ベアメタル）、分散と集中という、相反する二種類のアーキテクチャは数年ごとに互い違いに繰り返パラダイムシフトやイノベーションとは言い難し採用されてきた。しかし、逆のアーキテクチャ

いが、2014 年の動向として、データセンターやが異なる業界で同時に主流となるという現象は、ホスティング、クラウド IaaS の事業者では、ホワ

筆者の知る限りでは稀なことである。仮想ネット

イトボックススイッチを対象とした SDN 実装が始ワークや SDN だけではなく、これら相反するアイまった。また、キャリアでは NFV の実現のためのディアやアーキテクチャが、今後どのように検証

SDN 導入が推進された。

分析され活用されていくかに注目したい。

オープンなデータセンター仕様を議論する Open

第 5 部 製品・技術動向

2

3

ワーク機能を、それを適用するユーザーのネット■まとめ1249456