よくわかるIT新発見　第3回　技術レポート　「OpenDaylightの検証結果から見る、SDNの勘所」

2014年01月07日更新

OpenDaylightの検証結果から見るSDNの勘所をCTCのエンジニアが解説

今回は、エンジニア向けの技術検証レポートです。
サーバの仮想化とともにコンピューティングリソースの提供が高速化されてきている今、ネットワークはどのように変化しているのか、最近注目されている「OpenDaylight」の検証結果から見てみたいと思います。

ネットワーク設定に要する時間が課題

サーバに必要なネットワークの設定は、未だにほとんどの企業・事業者において手作業で行っているのが現状です。作業完了までに数日～数週間の時間を要するため、ネットワークの設計や設定にかかる時間がそのままユーザーが求めるITシステム全体の準備に必要なリードタイムとなっていることが多く、ユーザーのリクエストに対して柔軟かつ迅速なITリソースの提供が実現できないでいます。

SDI (Software Defined Infrastructure) におけるSDNとOpenDaylightの位置づけ

SDIにおけるSDNとOpenDaylightの位置づけ

CTCでは、より柔軟かつ迅速に制御可能な次世代ITインフラとして「SDI(Software Defined Infrastructure)」というコンセンプトを提唱しており、その実現に必要な機能を階層別に分類しています。この中の１カテゴリーであるSDNは、OpenStack等に代表されるオーケストレーションツールからAPIでコントロールされる位置づけとなっており、そのSDNを実現し得るツールの一つとして、主要なネットワークベンダーが参加する標準化団体によってリリースされた「OpenDaylight」が存在します。
OpenDaylightは、業界から期待が寄せられるOpenFlow技術をベースとしたオープンソースのSDNコントローラーであり、誰でも無償で利用・改変を行うことができます。

一般的にSDNコントローラーでは、外部プログラムから指示を受けて処理を実行するためのNorthbound APIと、各ネットワーク機器をコントロールするためのSouthbound APIが提供されます。オーケストレーションツールからOpenDaylightのNorthbound APIを呼び出すことで各ネットワーク機器へのコマンド入力が不要になるとともに、設定の追加や変更を自動化することによる迅速なプロビジョニングが可能となるため、特にクラウド事業者から大きな期待が寄せられています。

Northbound APIの機能検証を実施

今回の技術検証レポートでは、「ユーザーが必要とするプロビジョニングの自動化」の視点から、外部アプリケーションによって呼び出されるOpenDaylight のNorthbound APIが「正常かつ機能的に使える」ものであるか検証を行いました。一つひとつの結果については触れませんが、検証環境と手法をご紹介するとともに、結果のサマリーと所感・考察をお届けします。

なお、今回の検証ではOpenDaylight正式版のリリース前であったことからベータ版（M4相当のビルド）を利用しており、正式リリース版では検証結果が異なったり、機能が増えている可能性があることをご承知おきください。

OpenDaylight REST APIに関して

REST APIは以下のものが用意されています。（2013年12月2日現在）

APIカテゴリー	説明
Topology REST APIs	ノード間トポロジーの操作
Host Tracker REST APIs	スイッチに接続されたホスト（端末）情報の参照
Flow Programmer REST APIs	OpenFlow のフローエントリーの直接操作
Static Routing REST APIs	静的ルート設定の操作（IPルーティング）
Subnets REST APIs	IPサブネットの設定
Statistics REST APIs	各種統計情報の参照
Switch Manager REST APIs	スイッチデバイス情報の参照・操作
User Manager REST APIs	ユーザーの参照・操作
Container Manager REST APIs	コンテナの操作
Connection Manager REST APIs	コネクションの確認
Bridge Domain REST APIs	ドキュメント記載なし
Neutron ML2 / Network Configuration APIs	OpenStack Neutron対応API

検証環境図

OpenDaylight 検証環境

VMware上の仮想環境で技術検証を行いました。

OpenDaylight検証機器のスペック

分類	製品名	バージョン	数量
Ethernetスイッチ	Cisco Catalyst3750X	Version 15.0(2)SE2	1
サーバ	DL360G7QC CPU:Xenon E5640 2.67G x 2 Memory: 44G NIC Onboard GE 4Port	-	1
OS（ハイパーバイザ）	VMWare ESXi 5.1	Version 5.1	1
OS (OpenDaylightコントローラVM)	Ubuntu 12.04	Version 12.04	1
OS (Open vSwitch VM)	Ubuntu 12.04	Version 12.04 Open vSwitch 1.4.0	2

検証方法

REST APIによるフロー追加の例

curlを使用してAPIの所定のURLにPOST、DELETE、GETを行い、値および画面を確認しました。
Flow Programmer REST APIs であれば、次のURLにアクセスを行います。 /controller/nb/v2/flowprogrammer/{containerName}

図は、Flow Programmer REST APIsを使用して、フローを追加した例です。

REST APIによるフロー追加の確認画面

API検証に関する所感

主にオーケストレーターからコールされるAPIは、フローの定義や、トポロジーの表示等の基本的なものは実装されています。ただし、抽象化されたAPIが必要なオーケストレーターに対応するには、オーケストレーター層でプログラミングを行うか、さらにコントローラーにAPIを追加する作業（Java APIを使用したプログラミング）が必要です。例えば、サーバと接続するためには冗長化された物理リンクの制御が必要（LACP等）ですが、現状これらの実装はありません。実装を行いたい場合は、新たにユーザー自身が実装するか、OpenFlowスイッチ側で仮想化された物理リンクをOpenFlowコントローラー側に見せる実装が必要であり、いくつかのOpenFlowスイッチがこのような実装を行っています。
また、VXLAN等のトンネル技術の実装もありません。こちらもOpenFlowコントローラー側ではなくOpenFlowスイッチ側の実装に依存します（例：Open vSwitch実装）。

OpenFlowで柔軟に出来るといわれたことですが、OpenFlowコントローラーの実装ではなく、OpenFlowスイッチの実装に依存することは抑えておいたほうが良いと思われます。

REST APIもJava APIも基本的な機能は押さえていますが、SDIの定義に基づき商用アプリケーションに対応するためには、かなりのコーディング量が必要と考えられます。

REST API検証

実際にOpenDaylightのREST APIをコールして所定の設定および確認が出来るかの検証を行った結果、両者ともに出来ることが確認できました。ただし、現在も開発中の段階であるため、ドキュメントの不備、未定義と思われる機能がありました。

考察

OpenDaylight OpenFlowコントローラーはOpenFlow Switchをコントロールする基本的な機能を十分持っているものの、SDIの概念からみると、少なくとも現段階では、商用ネットワーク環境を構築するためのNorthbound APIに関する機能が足りないと思われます。

まとめ　～OpenFlowは世界を救う？

オープンな仕様のOpenFlowコントローラーであるOpenDaylightのリリースは、SDN分野に大きな一石を投じることになるでしょう。それでは、やはりSDNはOpenFlowで決まりなのかと言えば、必ずしもそうとは言えません。OpenFlowはあくまでもSouthboundを定義したプロトコルの一つです。

ユーザーにとって大切なのはプロトコルそのものではなく、システムによって、ユーザーがどれだけ以下のようなメリットを享受できるのかであると考えます。

増大するエンドユーザーからのニーズに対する「迅速かつ正確なデプロイ」
複雑化したネットワークシステムの「運用負荷の軽減」
ユーザーニーズと運用負荷の高まりに伴う「運用コストの削減」

そのためにも、オーケストレーション側から見て、よりNorthbound APIが抽象化されているSDNコントローラーが望ましく、その実装度合いがより重要なポイントとなります。そうでなければ、要件を満たすアプリケーションの実装において時間や工数ばかり膨らんでしまうことに加え、コントローラーのバージョンが変わるたびに手を入れる範囲も大きくなり、結果的に当初の目的を果たせなくなる可能性があります。

これから2014年にかけて、メジャーなネットワークベンダーから独自の実装によってSDNを実現した製品が続々とリリースされる予定です。それらの中にはOpenFlowをベースとしないものも多く含まれますが、各社の製品に共通しているところは、ネットワークが持つ機能の抽象化に力を入れており、外部からAPIを使って容易に制御できるようにしているということです。Northbound APIの実装がしっかりとした作りになっていれば、運用の自動化の実現がより現実味を帯びるでしょう。

CTCではSDIへの取組みの一環として、SDNについても各分野におけるユーザーニーズを継続的に調査し、流行りの言葉だけに流されない適切なソリューションをご提案できるよう努めてまいります。また、今後ベンダーからリリースされるSDN製品についても検証を行い、引き続き、皆様に有益となり得る情報を発信していく予定です。