SDNとSDS――ネットワーク／ストレージの「Software Defined化」動向

OpenFlowから始まったSDN

　SDNにつながるネットワークの改革として最初に進展したのは、SDNのコントローラ／データプレーンインタフェース（またはサウスバウンドインタフェース）の一種である「Open Flow」の開発だ（図1）。もともとOpenFlowはアカデミックな研究としてプロジェクトがスタートし、現在は非営利団体であるOpen Networking Foundation（ONF）が仕様策定・開発を進めている。現行バージョンは2013年10月にリリースされた1.4である。

図1：SDNの基本アーキテクチャ。OpenFlowはコントローラ／データプレーンに分類される（出典：米Open Networking Foundation）

　現在のネットワークではIP（Internet Protocol）に基づく、いわゆるIPネットワークが主流となっているため、ネットワーク機器の設計や運用管理手法もすべてIPネットワークのアーキテクチャの影響を色濃く受けている。具体的には、IPは分散型の自律システムとして設計されているため、ルータやスイッチといったパケットの転送を直接担う機器も分散型の自律システムとして動作するのが基本だ。

　つまり、外部からの指示や命令を受けて動作するのではなく、ネットワークの構成情報を個別に保持し、どのように動作すべきかを自律的に判断するのが基本となっている。このことは当然メリットとデメリットの両方を生んでいる。メリットは耐障害性にすぐれた面があることで、ネットワークの構成が変更された場合など、個々の機器がその変更をそれぞれ独自に検知して新しい構成に合わせて自身の動作を変更するようなことも可能だ。

　逆に、企業内LANなどで大規模な構成変更を行うような場合には一元的な運用管理ができず、個々の機器に対して個別に設定作業を行う、という作業を機器の台数分だけ繰り返さざるをえないような煩雑さも生んでいる。しかも、機器ごとの設定や運用のやり方はベンダーごとにまちまちなので、マルチベンダー環境ではさまざまな異なる手法を学ぶ負担があるし、結果としてベンダーロックインにつながることも珍しくない。

　OpenFlowではこうしたネットワークの状況を踏まえ、中央からの指示で各ルータの動作を制御できるシステムの開発を目指した。中核的なアイデアとなったのは、既存のルータの動作をパケットの転送動作を行うデータプレーンと、データプレーンを制御するコントローラプレーンとに論理的に分割した上でコントローラプレーンを外部に抽出して独立した「OpenFlowコントローラ」とし、ネットワーク内のすべてのOpenFlowスイッチに対して中央集権的な制御を行うかたちにしたことだ。

　この結果、運用管理者はOpenFlowコントローラだけを対象に運用管理作業を行えるようになった。加えて、従来のアドレスに基づいた固定的なルーティングではなく多彩な情報に基づいてきめ細かく宛先制御が可能な「フロー」ベースのルーティングを導入することで、ネットワークの物理的な配線を変更することなしにパケットの通過経路を動的に変更できるような自由度も獲得されている。

柔軟な構成変更を可能にするOpenFlow

　OpenFlowの開発の取り組みはサーバー側での仮想化の発展とは独立して、ネットワーク側の問題解決のためのアプローチとして進められてきた経緯がある。だが、実際にはサーバー仮想化と組み合わせて活用することでサーバー仮想化のスピード感に追従する柔軟なネットワークを構築することができる。

　例えば、SDN/OpenFlowの活用方法としてよく指摘されるのが仮想サーバーのライブマイグレーションへの対応だ。仮想サーバーを稼働中の状態で別の物理サーバーに移動させるライブマイグレーションでは、物理サーバーが切り替わることでネットワーク設定の問題が生じる可能性がある。仮想サーバーが移動しても、物理サーバーが同時に移動するわけではないし、ネットワークのケーブリングも変更されないのだから、ネットワーク的には仮想サーバーの移動の前後で異なる場所への通信となるところをソフトウェア的に調整して問題が生じないようにしているわけだ。通信が断絶しないよう、ライブマイグレーションに関わる物理サーバーが同一のL2ネットワークに所属していなくてはならないといった制約も、ネットワーク面から見た変化を最小限にとどめるために必要なものだった。

　一方、OpenFlowでフロー制御を行う場合、例えばサーバー仮想化ソフトがライブマイグレーションに関する情報をOpenFlowコントローラに提供することで、ネットワーク側が仮想サーバーの移動状況を正しく理解し、移動先に向けてパケットを転送することが可能になる（図2）。OpenFlowによるフロー制御では、パケット自体が何も変わることなしにパケットが通過する経路や最終的に到達する宛先まで、すべてを動的に変更することができるためだ。OpenFlowがSDNの具体的な実装手法として注目を集めてきたのは、まさにこうした動的で柔軟な構成変更を迅速に実行可能な機能を備えているからであろう。

図2：仮想サーバーのライブマイグレーションを解決するSDN/OpenFlow（出典：IIJ）

ホップバイホップ型の特性

　OpenFlowを中核に据えたネットワーク仮想化アーキテクチャをホップバイホップ（Hop by Hop）型と呼ぶことがある。このアーキテクチャでは、ネットワークを構成するすべてのスイッチはOpenFlow対応のOpenFlowスイッチでなくてはならない。つまり、既存のネットワークから段階的に変更していくのではなく、あるタイミングでホップバイホップ型のネットワークを一気に構成する形にならざるをえない。そのうえで、従来のIPネットワークとの相互接続を実現していくというのが現実的な移行プランとなる。

　ハードウェアの対応として、ONFで当初想定していたのは、現在の高機能化したルータ／スイッチからコントロールプレーンを分離することでシンプルなデータプレーンのみを処理する安価な機器に置き換えるというものだったようだ。だが実際には既存のネットワーク機器ベンダーは従来製品に追加機能としてOpenFlow対応をさらに加えるかたちで製品化したものが主流となっている。プロトコルとしてのOpenFlowはすでに事実上の標準として広く支持されているため、最近ではOpenFlow対応の製品のほうがむしろ多い。そのため、段階的にリプレースを進めていけば、数年後には自社で運用するすべてのスイッチが自然にOpenFlow対応製品となることもありえる。その意味でOpenFlow対応は着実に進んでいると言えよう。

　上述した状況のため、ホップバイホップ型ネットワークの利用例はごく限定的な場面にとどまっている。トラフィックをきめ細かく制御できるため、大容量回線を運用するキャリアなどでは有効な技術であり、バックボーンネットワークなどですでにOpenFlowが実用レベルで使われ始めているという話も聞く。だが、データセンターの内部LANレベルではメリットがあまりないというのが現状だ。

　そのため、企業ユーザーや中規模のデータセンター事業者などでは、ホップバイホップ型よりも後述するオーバーレイ型ネットワーク仮想化のほうが、よりメリットを引き出しやすいと言える（図3）。

図3：ホップバイホップ方式とトンネル（オーバーレイ）方式（出典：NEC）

ベンダー各社が力を注ぐOpenDaylight

　一時はSDNの代名詞的な扱いもされたOpenFlowだが、SDNを巡る最新トレンドの中で見ると、存在感はさほどのものではない。上述したように、今日さまざまなベンダーのソフトウェアやネットワーク機器にOpenFlowプロトコルが組み込まれているが、一種の“部品”としての利用が主であり、あまり前面に押し出されることがないからだ。これは、ONFが開発方針としてユーザー主導を重視しており、既存のネットワーク機器ベンダーが主導的な役割を果たすことがないような組織作りが行われていることも影響している。ユーザー視点からネットワーク機器ベンダーに注文をつけていくといったスタンスだ。

　一方で、ネットワーク機器ベンダー各社は2013年より、Linux Foundationのオープンソースプロジェクトである「OpenDaylight（ODL）」の開発に参加し、SDNのためのプラットフォームと位置づけるようになった。ODLはその機能の一部としてOpenFlowプロトコルを組み込んでおり、さらにネットワーク機器ベンダー各社の独自開発のソフトウェアを組み込めるような構造となっている。ベンダー側が自社製品の中核として採用しやすいこともあって最近はOpenFlowよりも存在感が高くなっている。

データセンターでの活用例

　データセンターの具体的な環境で考えてみよう。例えばレンタルサーバーのサービスで、ユーザーから数台のサーバーをレンタルしこれらを相互接続して独立したLANを構築したいというニーズがあったとする。ここで、オーバーレイ型ネットワーク仮想化でこのサーバー群を相互接続すれば、実際に通信に利用する物理層のネットワークは他のサーバーと共用されていても、このサーバー群が送受信するパケットは外部のサーバーからは完全に隠蔽され、当該のオーバーレイに接続されているサーバー以外からはまったく見えないという環境を作り出せる。

　しかも、物理的なケーブリングの変更などは必要なく、相互接続されるサーバー群の所在にもほとんど制約がない。同一ラック内に収まっていないと、といった条件はなく、IPリーチャブルでありさえすればどこにあっても問題ないという柔軟性も得られる。物理的な設定作業が不要ということで、ユーザーがセルフサービスポータルを介して自身で設定すれば数分程度で希望の環境が手に入る、というサービスを実現することが可能だ。

　当初のSDNは、こうしたシナリオを実現するのに不可欠の要素と考えられ、逆に言えばSDNを必要とするのはこうした迅速な展開や構成変更を行いたいユーザーと考えられていた。

迅速／即時性ニーズの実情

　しかし実態は少々異なっていたようだ。上述のようなニーズに応えるためにSDNが必須の要素かと言えば必ずしもそうではない。そうした需要がある程度見込めるなら、最初からそうした構成のサーバー群を用意しておき、希望するユーザーにそのサーバー群を割り当てる方法でも対応は可能だ。ユーザーがセルフサービスポータルを使ってオンデマンドで環境構築を行うからといって、データセンター側も同じようにオンデマンドで環境を作り出す必要があるとはかぎらない。採算性さえ確保できるなら、事前に環境を用意し、必要に応じて適時人手で新しい環境を作って追加でプールしておくというやり方でもよいわけだ。

　そういう事情からなのか、迅速な展開／構成変更の必要性が強調され始めてからも、特にオーバーレイ型ネットワーク仮想化市場が急拡大したという感触はない。いくつかのサービス事業者に聞いてみたところ、実際のところ、そこまで迅速な展開や構成変更を要求するユーザーもさほど多くなく、既存のサービス体制で特に問題は感じていない向きが大半だった。一部の仮想化インフラベンダーが強調するほどの強いニーズが存在していたわけではないようだ。ビジネスの内容上、迅速／即時のシステム展開や構成変更を必要としているユーザーももちろん存在するが、全体から見ればごく一部の特別なニーズとして存在するレベルにとどまるものだと見てよいだろう。

仮想アプライアンスを軸にSDNをサービス化

　では、なぜここにきてSDNをサービス化する動きが顕著になってきているのか。それはもちろんユーザーニーズに応えての動きには違いないのだが、そのニーズは当初想定されていたような迅速化とは少し異なっている。

　例えば、オーバーレイ型ネットワーク仮想化では、既設の物理ネットワーク上にトンネリングで仮想ネットワークを重ね合わせるため、同じ仮想ネットワークに所属しているサーバー以外はパケットの内容を知ることはできない。このことがセキュリティを担保し、論理的なネットワーク分割を実現する根本理由となっているわけだが、逆に言えば同じオーバーレイ型ネットワーク仮想化ソフトウェアを実行できるサーバー以外のネットワーク機器等は仮想ネットワークに参加することができず、パケットの内容に応じた処理を行うこともできない。

　要は、各種の侵入検知／防御のためのIDS/IPSやファイアウォール、ウイルス検知や情報漏洩対策など、さまざまなセキュリティアプライアンスやロードバランサなどのネットワーク機器などが仮想ネットワーク上で利用できなくなってしまうということだ。

　とはいえ、こうしたネットワーク機能は今や必要不可欠であり、仮想ネットワークでは使えない、で済む話ではない。そこで、仮想アプライアンスを軸にこうした機能をオーバーレイ型ネットワーク仮想化プラットフォーム側で準備するという対応が行われている。既存のネットワーク機器ベンダー側でも製品を仮想アプライアンスの形態で提供する動きが活発化しており、仮想サーバーを追加するのとまったく同様のプロセスで任意のネットワークアプライアンスを仮想ネットワーク内部で利用できるような環境整備が急速に進展しているところだ。

　こうした動きは、当初、オーバーレイ型ネットワーク仮想化では既存のネットワーク機器が持っていた各種機能がうまく利用できないという問題に対する解決策として実装され始めた。現在では単なる問題解決という位置づけを越え、「仮想ネットワーク環境であればさまざまな仮想ネットワークアプライアンスを自由に使え、迅速な環境構築が可能になる」という従来の物理ベースのネットワーク環境では得られない新しい魅力としてアピールするレベルになってきた。現在ネットワーク事業者が進めるSDNのサービスメニュー化の流れの中核にあるのが実はこうした仮想アプライアンスの活用だ。

　従来のレンタルサーバーのサービスメニューにも、必要なネットワーク機器を組み込んだLAN型のサービスは存在していたが、あらかじめデータセンター側が用意した機器の中から選ぶ場合でも実際の接続作業を等を終えてシステムが利用可能になるまでには数時間～数日程度の時間を要するのが普通だった。

　一方、SDNをうたうサービスでは、ユーザーがセルフサービスポータルを使ってネットワークの構成を指定し、必要なネットワーク機能（仮想アプライアンス）を選択すれば数分程度で新たなネットワークが稼働開始する、というレベルまでの時間短縮が可能になる。迅速なネットワークの構成変更という包括的なニーズよりも、必要なネットワーク機能を自在に組み合わせる、といういわば“仮想アプライアンスの迅速な展開”にこそ実際のユーザーのニーズが存在していた、ということになるだろうか。

　もちろん、ネットワーク事業者ではSDNのメニューの一環として利用可能な帯域幅の動的な変更なども加えている。こうした変更は従来なら必要な書式を準備したうえで事業者に申請し、数営業日待ってようやく実現する、といった作業だったが、これもセルフサービスポータルで指定すれば数分～ 1時間程度で即座に実施できる、というレベルになりつつある。これが現在のSDNに対するユーザーニーズの中核的な部分であるようだ。まずは大規模なネットワークサービス事業者の取り組みが先行しているが、こうしたニーズはいずれさまざまなデータセンターのLAN環境にも波及してくることが予想される。

　本格的な普及の前夜に当たる状況、と言われ続けて数年が経過し、結局いつまで経っても夜が明けない、というやや悲観的な見方が目立つようになっていたSDNだが、ここにきてようやく具体的なサービスとして活用するための提供方法が見えてきたというところだろう。