Cloudn \ 技術ブログ tech blog

クラウド・エヌの活用方法についてご紹介していきます。
Cloudn Information

前の記事・次の記事

沖縄オープンラボラトリで取り組んだOpenDaylightプロジェクトのご紹介

ブログ記事

今回は技術ブログ番外編として、NTTコミュニケーションズでクラウド関連の研究に取り組むチームのご紹介をさせていただきます!

ハイサイ(こんにちは)、NTTコミュニケーションズ/沖縄オープンラボラトリの丸山です。
私はクラウド/SDN技術の研究を行っている沖縄オープンラボラトリ(以下、OOL)で働いています。

OOLは2013年5月にNEC、イイガ、NTTcomの3社で設立された一般社団法人です。今年度で3期目となり、いまでは会員も45を超え、多くの方々に支えられながら日々研究活動を行っています。また、研究活動以外にもSDNやOpenStackの普及促進にも貢献しており、今年で3回目となる国際会議「OkinawaOpenDays」も12月に開催が決定しました。詳細を順次アップしていきますので、こちらもご覧になっていただければ幸いです。

今回は丸山がOOLで2014年度に行ったプロジェクトの一つである、OpenDaylightを使ったマルチネットワーク連携について紹介させていただきます。

1. OpenDaylightって?

OpenDaylightについて説明をする前に、まずはSDNコントローラについて説明をします。
SDNコントローラとは、ネットワークを構成する各要素を統合して管理するソフトウェアやアプライアンスを指す言葉で、SDNコントローラから各要素を管理/制御するためのプロトコルが「OpenFlow」となります。実現可能な技術としては、パケットの転送処理、VPN、帯域制御(QoS)、ネットワーク仮想化、ロードバランスなどがあり、利用者は環境に合わせた機能のみを対象の物理/仮想OpenFlow対応スイッチに実装する事が可能となっています。現在広く利用されている、または開発が続けられているSDNコントローラとして、Ryu、POX、そして今回ご紹介するOpenDaylightなどがあります。

OpenDaylightとは、Linux Foundation Collaborative Projectの1つであり、オープンソースのSDNコントローラプラットフォームです。SDNコントローラではなくプラットフォームとして公開してある理由は、コントローラ、インタフェース、プロトコルといった多様な実装のコンポーネントをプラグインとして、他のコンポーネントの動作を止めることなく追加削除することが可能なためです。そのため、拡張性に優れ、開発をスムーズに行うことができるのが特徴となっています。
OpenDaylightは2014年2月に1stバージョンである「Hydrogen」がリリースされ、現バージョンの「Helium」では、開発に参画しているベンダ数が40を超え、SDNのプラットフォームとして高い注目を浴びていることもあり、今後のSDN技術において重要なコンポーネントになると考えます。
また、OpenDaylightは機能をProjectという単位で表現しており、複数のProjectで構成されます。以下にProjectコンポーネントのアーキテクチャ(図1)を載せておきます。

図1

図1 アーキテクチャ図

2. OOLで取り組んだマルチネットワーク連携プロジェクトとは?

OOLでは、SDNコントローラへの取り組みとしてレガシーネットワーク(Layer2ネットワーク、広域ネットワーク)、OpenFlowネットワークなどの複数のネットワーク技術を連携させ、統合した1つのEnd-to-End(以下、E2E)ネットワークの実現を目指しています。
このE2Eネットワークを実現するにあたり、昨今SDNコントローラのプラットフォームとして高い注目を浴びているOpenDaylightを利用したいと考えています。
数あるSDNコントローラからOpenDaylightを選んだ背景としては、OpenDaylightが広範なネットワーク技術をサポートしていることがあります。複数のネットワーク技術を統合するために、他のSDNコントローラで実現しようとすると、サポートするネットワークプロトコル(SouthBoundProtocolとも呼ばれる)も少なく(OpenFlow、OVSDB、NetConfなど)あらゆるネットワーク機器を制御するために種類の違う複数のSDNコントローラを連携させる必要があり、それらのSDNコントローラを一元管理するのは困難かつ非常に大きな手間がかかることが考えられます。
しかし、OpenDaylightのSDNコントローラは私達が知りうるほぼ全てのネットワーク機器を制御するためのネットワークプロトコルをサポートしているため、OpenDaylightのみで複数ネットワークが制御できるので、管理が簡単になるのは大きなメリットと考えます。
この理由より、OOLではOpenDaylightを活用し、Proof Of Concept(以下、POC)を通じて統合したE2Eネットワークの技術検証を行うことにしました。

ただ、最初から全てを検証するのではなく、昨年度はOpenFlow、BGP、SNMPを選定し、これらのプロトコルを連携させたPOCを実施することにより、実現性を評価することを目標とし、検証を実施しました。これらのプロトコルをサポートするProjectとして、OpenFlowはVTN Project、BGPはBGPCEP Project、SNMPはSNMP4SDN Projectが対応します。ソフトウェアアーキテクチャを図2で示すと以下の赤枠のモジュールが該当します。また、今回の記事ではOpenFlowとSNMPの連携検証実験を中心にご紹介します。

図2

図2 アーキテクチャ図

3. OpenFlow-SNMP連携検証構成について

OpenFlow-SNMP連携検証構成を以下の図3〜4で示します。

図3

図3 OpenFlow-SNMP連携検証構成1

図4

図4 OpenFlow-SNMP連携検証構成2

図3及び4の構成は以下のユースケースを想定しています。
・企業内での利用
・プライベートクラウドをOpenStackで構築
・プライベートクラウドのネットワークはOpenvSwitchで構成
・オフィスネットワークはOpenFlowスイッチで構成
・オフィス内からプライベートクラウドのネットワークにLayer2で接続を行う

図3では、Layer2スイッチをSNMP4SDNからVLAN-IDを切り替えることでプライベートネットワークとオフィスネットワークの接続を制御します。
結論からお伝えしますと、最初はプライベートネットワークとオフィスネットワークをVTNからマルチテナント型ネットワークを作成しようとしましたが、残念ながらOpenFlowスイッチの物理トポロジーを検出するためのLLDP(Link Layer Discovery Protocol)をLayer2スイッチが透過せず、物理トポロジーが検出できませんでした。。。
そのため、図4のように今回はLayer2スイッチをHUBに置き換えて改めて検証を実施しました。

【評価環境】

サーバ/クライアント

Node スペック
OS CPUコア数 メモリ
OpenDaylight Controller ubuntu 14.04.1 LTS サーバ 2コア 4GByte
OpenStack Control Node ubuntu 14.04.1 LTS サーバ 4コア 8GByte
OpenStack Compute Node ubuntu 14.04.1 LTS サーバ 4コア 8Gbyte
Tenant1 Node Windows 7 2コア 4Gbyte
Tenant2 Node Windows 7 2コア 4Gbyte

 

スイッチ

Node スペック
OS CPUコア数 メモリ
OpenDaylight Controller ubuntu 14.04.1 LTS サーバ 2コア 4GByte
OpenStack Control Node ubuntu 14.04.1 LTS サーバ 4コア 8GByte
OpenStack Compute Node ubuntu 14.04.1 LTS サーバ 4コア 8Gbyte
Tenant1 Node Windows 7 2コア 4Gbyte
Tenant2 Node Windows 7 2コア 4Gbyte

4. OpenFlow-SNMP連携検証構成1について

【検証結果】

プライベートクラウドの仮想ネットワークとオフィスの物理ネットワークをVTNから制御を行いましたが、正常に動作させることができませんでした。原因としてはVTNでOpenFlowのネットワーク制御を行うためにはOpenFlowスイッチ間の物理トポロジーをOpenDaylightのSDNコントローラが知る必要がありますが、仮想ネットワークと物理ネットワーク間にSNMPと連携させるために接続したLayer2SwitchがLLDPを透過させなかったためとなっています。

【問題点・解決案】

LLDP通信を行う際に使用される宛先マルチキャストアドレスとして、OpenDaylightのSDNコントローラではフレームを透過しないアドレスが指定されています(このためLayer2Switchでフレームがフィルタリングされ、その先のOpenFlowスイッチまでフレームが届かないのでトポロジー検出が行えません)。
OpenDaylightコントローラ側にフレーム透過用のマルチキャストアドレスを指定すれば解決できそうですが、検証が必要であるため、今回は検証構成を先ほどの図4のように置き換えることにしました。

5. OpenFlow-SNMP連携検証構成2について

【検証結果】

OpenFlow-SNMP連携検証1でLayer2Switchが原因のためLLDPが透過しなかったので、Layer2SwitchをHUBに置き換えて検証を行いました。HUBに置き換えた場合、LLDPを透過し、正常に物理トポロジーを検出することができ、無事、VTNで仮想ネットワークと物理ネットワークをマルチテナント型で接続することができました。

【問題点・解決案】

仮想ネットワークはOpenStackのネットワーク・VM作成時にOpenDaylight用ML2Driverが自動でVTNの作成を行っているが、物理ネットワーク側は手動でVTNの設定を行う必要があります。OpenStack環境とそれ以外の環境を統合管理するアプリケーションが必要となります。

6. 今後の取り組み

今回のPOCではOpenFlowを使った仮想ネットワークと物理ネットワークの連携検証は実現できましたが、複数ネットワーク技術(OpenFlowとSNMP)の連携は問題が発生しました。しかし、原因がわかり、その解決策まで明らかにできたので、継続して検証を行っていきます。さらに、WANまで範囲を広げたネットワーク連携の検証を行うことでより実運用に近い環境を作りたいと考えています。

OOLでは今回ご紹介したOpenDaylightのプロジェクト以外にも様々なプロジェクトを行っていますので、またの機会に他のプロジェクトについてもご紹介できればと思っています。

※本記事の内容は、Cloudnの活用方法の一例を示したものであり、お客様の環境・構成において動作することをお約束するものではありません。 従いまして、本記事の内容によって生じたトラブルや損害についても、弊社では責任を負いかねますのでご了承ください。
また、本記事の内容に関してのサポートは行っておりませんので、予めご了承ください。

ブログフッダ

投稿日:

カテゴリ:

前の記事・次の記事

サイドニュー

カテゴリー

最近の記事

バックナンバー