SDNの理想と現実――ネットワーク運用でのSDNの現実的な活用法を考える：SDNで始めるネットワークの運用改善（1）（2/4 ページ）

[村木暢哉（TIS），＠IT]

SDNの理想と現実

　では、現状はどうでしょうか。根底にある「ネットワークをソフトウェアで動的に構成、制御する」という考え方は同じですが、現在SDNは文脈によってさまざまな形で解釈されます。

　例えば、既存のさまざまな設定制御方式が利用可能なLinuxベースのネットワークOSが稼働するホワイトボックススイッチや、最近の機器が持つREST API、NETCONFなどの機械処理に適したインタフェース、あるいは従来のCLIの対話自動化やAPIへの変換手法を利用することで、ネットワーク機器を自動構成し、ネットワーク運用を自動化する方法があります（図3）。このケースでは、サーバだけでなくネットワーク機器にも設定を反映できるようなツール、フレームワークが活用されます。

図3　SDNの例1

　一方で、異種のプロトコルや機器が混在したネットワーク環境を、さまざまなAPIでプログラミング可能にし、ネットワークサービスを迅速・柔軟に構成できる仕組みそのものを指す場合もあります（図4）。

図4　SDNの例2

　このようにSDNは、多くのプレイヤーが唱える概念が混ざり合い、幅広い意味を持つようになっています。そのため技術に関しても、OpenFlowに限らず、従来使われている堅牢なプロトコルを利用したものや、ベンダー独自のプロトコルによって実現するものが数多く存在します。

　また、アーキテクチャも集中管理に限りません。例えば、後述するネットワーク仮想化では、分散制御アーキテクチャを採用しつつ、分散した各エッジでOpenFlowやその他の手法によって仮想ネットワークを構成するプロダクトも多く見受けられます。

　このような、装置とそれを扱うプロトコルを抽象化して一元管理し、外部からAPIで制御を受け付け、ソフトウェアとして実装・搭載されるサービスによってネットワークを動的にコントロールするオープンソースのプラットフォームとしては、「OpenDaylight」があります（図5）。

図5　OpenDaylightのアーキテクチャ（転載元：https://www.opendaylight.org/platform-overview/）

　また、従来のネットワークは自律分散型であると同時に、ネットワーク管理システム（NMS）や装置管理システム（EMS）がベンダー装置と対になっていることもありました。特に設定制御に関しては「ベンダーごとにインタフェースが統一されていない」「APIが備わっている機種もその機能性が不十分である」といった理由から、統一的な制御が難しく、今でも運用改善上よく見られる大きな課題となっています。

　こうした設定制御に関するベンダーロックインは、OpenFlowのようなオープン標準の技術を使うことで回避できると考えられていました（図6）。

図6　SDN製品（ソリューション）適用の理想

　ところが、実際にはOpenFlowを使ってはいても仕様の充足度がベンダーごとに異なるために同一コントローラーでの制御が難しく、同一ネットワーク内での混在が難しい装置があります。そのため、当初考えられていたような柔軟な構成を取ることができず、再びロックインが発生し得る状況が発生しています（図7）。

図7　SDN製品（ソリューション）適用の現実

　また、現在のSDN製品の中には、同一ベンダーの機器や、独自プロトコルを解釈できる機器でそろえた基盤でのみ真価を発揮するものもあります。もちろん、こうしたSDN製品が企業の状況にうまく適合し、メリットを発揮できるのであればそれに越したことはありません。上手に活用できれば、ネットワークの構築や運用の改善においても劇的な効果が得られるでしょう。

　しかしながら、装置の調達においては、「目的に合致するか」「備える特徴・インタフェースが機能・非機能要求を満たすか」「予算に収まるか」「サポートはどうか」「既存のネットワークにどのように組み入れるのか」といったさまざまな観点から選定を行う必要があり、単純に同一ベンダーでそろえるということは、一般的に難しくなります。

　こうした状況を受け各ベンダーも、他ベンダーやオープンソースのソフトウェアスイッチとの相互接続性を示すなどさまざまな取り組みを行ってはいますが、複数ベンダーの機器が混在しやすい状況を単一ベンダーの製品で完全にカバーするのは困難であり、ネットワークによってはSDN製品の恩恵を十分に受けられない可能性が高くなっているのが実情なのです。