ネットワーク構成をソフトウェアで動的に設定・変更できる「Software-Defined Network(SDN)」。いま注目を集めているのはなぜか? そのメリットや標準化の動向などを解説する。
「Software-Defined Network(以下SDN)」とは、ネットワークの構成、機能、性能などをソフトウェアの操作だけで動的に設定、変更できるネットワーク、あるいはそのためのコンセプトを指す。
これまでのネットワークでは、例えばネットワークにサーバを追加する際、あるいは1つのネットワークを複数に分割する際や、アプリケーションごとのQoSを設定する際などには、ケーブルの接続をやり直したり、1つ1つのルータやスイッチごとにネットワーク管理者が設定をしなければならなかった。
しかしネットワーク上に仮想サーバが多数存在するようになり、しかもそれが動的に生成、消滅し、ときにライブ・マイグレーションによってネットワーク内を移動するようになると、そのたびにネットワーク管理者がネットワーク機器をいちいち設定する必要があるのではとても実用的な運用にならない。そこで、ネットワークのあらゆる構成や機能をソフトウェアだけで設定できるようにすることを目指すSDNが急速に注目され始めた。
SDNが注目され始めたもう1つの理由が、「OpenFlow」と呼ばれるネットワーク標準の登場だ。OpenFlowはスイッチの動作を定義するとともに、そのスイッチを制御するためのプロトコルも定義している。これまでネットワーク機器を制御するためのプロトコルやAPIはベンダ固有のものしかなく、それがマルチ・ベンダ環境でのネットワーク構成を自動化する上での障害になっていた。各ベンダがOpenFlowに対応した機器をリリースすることで、標準プロトコルによって統合的にネットワーク機器の設定が可能になるとの考えが広まった。
SDNが実現すれば、例えばあるWebアプリケーションのために「ここにルータを置いて経路情報を設定し、ファイアウォールを設置してその下にロード・バランサを設置してアルゴリズムを設定し、その下にサーバを5台接続する」というネットワーク構成を実現するのに、ケーブルやネットワーク機器に触る必要がなくなる。すべて管理用ソフトウェアで設計、設定し、ボタンを押せばたちまちネットワークが構成され、そこに仮想化されたサーバが接続されていくだろう。
ネットワークはこれまで、いったん構築するとほとんど変更されないスタティックなものと考えられてきた。しかしSDNが実現されれば、ソフトウェアから簡単かつすぐに追加変更が可能になる。そうなればトラフィックの状況に合わせて動的にネットワーク構成が変化したり、アプリケーションの要求に合わせてネットワークの動作が変わったり、あるいは組織に合わせてネットワークが分割されたり統合されたりと、ネットワーク構成はよりダイナミックなものにできる。
SDNは、いわゆるネットワーク仮想化も実現する。サーバ仮想化が、物理サーバの上に複数の仮想サーバを作り出すのと同じように、物理的なネットワークの上に仮想化された異なる機能や構成を備えた複数のネットワークを作り出せる(ただし、ネットワーク仮想化が常にSDNによって実現されるわけではなく、それ以外の技術によっても実現される)。
仮想化やクラウドの時代になり、サーバを調達するという行為は「物理的なサーバを発注・購入すること」から、必要な構成をメニューから選択して管理画面からボタンを押し、仮想化されたサーバを起動することへと変わろうとしている。ネットワークもこれと同様に、ネットワークを構成するという行為が物理的にケーブルで必要なネットワーク機器をつないで設定を行うことから、管理画面で必要な構成を選択し、ボタンを押すことへと変わろうとしている。これがSDNへと向かう流れだ。
SDNを実現する技術として筆頭に上がるのが「OpenFlow」だ。OpenFlow対応の管理ソフトウェアがあれば、OpenFlow対応のネットワーク機器やソフトウェア・スイッチ、ソフトウェア・ルータなどをまとめて制御できる。
では今後、あらゆるネットワーク機器やソフトウェアがOpenFlowに対応することでSDNが実現されるのだろうか? おそらくそうはならない。あらゆるネットワーク機器がOpenFlowに対応することは現実的に考えにくい。例えばネットワーク機器最大手のシスコシステムズは独自のSDN戦略を進めており、OpenFlow対応には積極的ではない。
SDNの実現に向けた標準化で最近もう1つ注目が集まっているのが「Northbound API」だ。一般にSDNでは、ネットワーク構成や機能を集中的に制御するソフトウェア「SDNコントローラ」が存在する。OpenFlowがこのSDNコントローラとスイッチやルータの間のプロトコルを標準化したものであるのに対し、Northbound APIはSDNコントローラもしくはその上位レイヤにおいて、ネットワーク構成や機能を制御するためのAPIを指す。
Northbound API経由でネットワークを制御できるようになれば、SDNコントローラから下はOpenFlowだろうがベンダ独自の管理機能だろうがどうでもよくなる。マルチ・ベンダ環境下でSDNを標準化する手段としてNorthbound APIの標準化の行方が注目されているのだ。
ただしNorthbound APIについては標準化団体が設立されたわけでも、有力な標準候補があるわけでもない。CloudStackやOpenStackのようなクラウド基盤ソフトウェア*1が比較的有力とみられているが、まだNorthbound APIが標準化されるかどうかも分からない状況だ*2。
しかしネットワーク業界の誰もがSDNへ向かう動きが後戻りすることはないと考えている。しばらくはSDNを実現するさまざまな技術や実装が登場し、それが少しずつ収束していくことになるだろう。
*1 CloudStackもOpenStackも、クラウド・サービスを提供するための基盤システムを構築するためのソフトウェアの一種である。どちらもオープン・ソースで、多くの商用サービスに採用されている。
*2 【2013/04/16編集部追記】本稿公開後、「OpenDaylight」というSDNのためのオープン・ソース・ソフトウェア開発プロジェクトが発足した。SDNコントローラなどの開発のほか、Northbound APIなどの標準化も行われるとのことだ。OpenDaylight発足の詳細は「SDNのオープンソースプロジェクト、OpenDaylightが発足」(Master of IP Networksフォーラム)を参照していただきたい。
Copyright© Digital Advantage Corp. All Rights Reserved.