Open daylightバージョンアップ対応

OpenDaylightアプリケーションの
バージョンアップ対応について
Acroquest Technology 株式会社
飯田樹生

目次
1. プロジェクトの背景と目的
2. OpenDaylightとは
3. 取り組んだ課題
4. アプリのパッケージング方式の変更
5. アプリで使用するAPIの見直し
6. まとめ
Copyright © Acroquest Technology Co., Ltd. All rights reserved.
2

１．プロジェクトの背景と目的
• とあるベアメタルクラウドに携わる
ことになり、OpenDaylight
Lithiumを用いてOpenFlowスイッ
チをコントロールし、ネットワークを
制御することになった
• しかしOpenDaylightは変化が激
しく、使用しているAPIが非推奨に
なる、アプリのパッケージングの
方式が変わるなど、最新版の
Berylliumへの対応が求められる
3
※本資料の内容は2016年9月時点の情報に基づいています。

２．OpenDaylightとは
• OSSのSDNコントローラプラットフォーム
• 2013年4月にLinux Foundationによって
プロジェクトが発足し、2014年2月に最初のバージョン
であるHydrogenが、2016年4月に最新版のBeryllium
がリリースされた
• 主要なSDN関連ベンダがプロジェクトに参加しており、
製品のベースとして利用されるようになってきているが、
ドキュメントなどの情報が少なく、アプリ開発までのハー
ドルはまだまだ高い
• リポジトリが頻繁に変更されるので、今までビルドできていた
ものが急にできなくなることもある
4

5
SAL（Service Abstraction Layer）
と呼ばれるフレームワークを持っており、
様々な機能の追加が可能
https://www.opendaylight.org/odlbe
• OpenDaylightのアーキテクチャは以下の通り

• SALの中でもMD-SAL（Model-Driven SAL）での実装
が主流となっている
• MD-SALではツリー状のデータモデルを中心とし、デー
タの更新や取得、変更の通知、RPC（Remote
Procedure Call）の実行などによって処理が行われる
6

３．取り組んだ課題
• Beryllium対応で以下の課題に取り組んだ
① アプリのパッケージング方式の変更
今までOSGi Bundleとして作成していたものをKaraf
Featureに変更する
② アプリで使用するAPIの見直し
MD-SALについて、バージョンアップによって変更されたAPI
があるので、主に通知の受信について改めて見直す
7

４．アプリのパッケージング方式の変更
• OSGi BundleからKaraf Featureへ変更するに際し、プ
ロジェクトの構成を見直す
• 従来は、データモデルの定義を行う「model」と、実際に
アプリを実装する「impl」に分けるのが一般的だった
8
Project
│
├─model
│ └─src/main/yang
│ └─sample-model.yang
│
└─impl
└─src/main/java
├─Activator.java
└─SampleApp.java
データモデルをYANGで定義する
（Javaのエンティティクラスが自動
生成される）
アプリを起動するActivatorと、実
際の処理を行うクラスを実装する

• 従来の実装のイメージ
9
YANGモデル
エンティティ
クラス等
自動生成
Activator
Consumer
or Provider
独自
アプリケーション
起動
使用、実現
実装箇所
他にアプリケーシ
ョンの起動順序
の制御等も考慮
する必要がある。
implの範囲
modelの範囲

• Karaf Featureでは従来に加え、「config」、「feature」、
「distribution」を作成する
10
Project
├─application
│ ├─model
│ ├─impl
│ │ └─src/main/yang
│ │ └─sample-app.yang
│ └─config
│ └─src/main/resources/initial
│ └─51-sample-app.xml
├─feature
│ └─src/main/resources
│ └─features.xml
└─distribution
├─karaf-branding
│ └─src/main/resources/org/apache/karaf/branding
│ └─branding.properties
└─opendaylight-karaf
アプリケーション自体も
YANGで記述し、その起動
設定をxmlで定義する
アプリのKaraf Featureを作成する
アプリを含んだOpenDaylightを作成する

• 今回の実装のイメージ
11
YANGモデル
エンティティ
クラス等
自動生成
Module
独自
起動
使用、実現
実装箇所
YANGモデル
自動生成
modelの範囲
implの範囲
configの範囲
の管理をconfig
が担当する

• 「config」では「Config Subsystem」と呼ばれる管理機
能に従い、アプリ自体のYANGモジュール化とその設
定を定義する
12
module sample-app {
...
augment "/config:modules/config:module/config:configuration" {
case sample-app {
when "/config:modules/config:module/config:type = ‘sample-app'";
container data-broker { ... }
container rpc-registry { ... }
container notification-service { ... }
<modules xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
<module>
<type xmlns:prefix="urn:jp:co:acroquest:odl:sample:sample-app">prefix:sample-app</type>
<name>sample-app</name>
<data-broker> ... </data-broker>
<rpc-registry> ... </rpc-registry>
<notification-service> ... </notification-service>
sample-app.yang
51-sample-app.xml
sample-appという名前のアプリが起動した時、
3つのインスタンスをインジェクトする
xmlにも同様の定義を記述する
（xmlファイルの先頭の数字はアプリの起動順序
を表す）

• ビルドするとModuleクラス（Activatorに相当）とその
Factoryクラスが生成されるので、Moduleの
createInstanceメソッドにアプリの起動処理を実装する
（必要なインスタンスを取得してアプリのインスタンスを
生成するだけ）
13
public class SampleAppModule extends
jp.co.acroquest.odl.sample.impl.AbstractSampleAppModule {
...
@Override
public java.lang.AutoClosable createInstance() {
DataBroker dataBroker = getDataBrokerDependency();
RpcProviderRegistry rpcProviderRegistry = getRpcRegistryDependency();
NotificationProviderService notification = getNotificationServiceDependency();
SampleApp sampleApp = new SampleApp(dataBroker, rpcProviderRegistry, notification);

• 各種設定で記述していたオブジェクトの概要は以下の
通り
• いずれも、アプリが使用しない場合は設定や実装を省
略可能
14
オブジェクト名説明
DataBroker MD-SALデータストアへアクセスするために必要
RpcProviderRegistry RPCの登録や、他のアプリが提供するRPCを利用
するために必要
NotificationProviderService 通知を発行または受信するために必要

• プロジェクトをビルドすると、作成したアプリケーションの
Featureを含んだOpenDaylight Beryllium本体が
「distribution」に生成される
（動作に必要なFeatureやBundleが全て含まれている
ので、オフライン環境でもそのまま使用可能）
• アプリケーションのKar（Karaf Feature）ファイルを作成
し、既存のOpenDaylightに機能を追加する方法もある
が、私が試した限りではLithiumとBerylliumでは動作し
ないので非推奨（中のファイルが展開されない）
15

５．アプリで使用するAPIの見直し
• 作成したアプリケーションに特定のListenerを継承し、メ
ソッドをオーバーライドすることによって、様々な通知を
受け取ることができるようになる
• バージョンアップによって変更されたAPIがあるので、見
直しを行った
16
独自
Listener ListenerListener

17
Listener メソッド説明
OpenDaylight
InventoryListener
onNodeUpdated /
Removed
スイッチ（Node）の登録/削除のイベ
ントを受け取る
onNodeConnectorUpdated /
Removed
ポート（NodeConnector）の登録/削
除のイベントを受け取る
PacketProcessing
Listener
onPacketReceived コントローラが受信したパケットの情
報を受け取る
DataChange
Listener
onDataChanged データモデル中のデータの変更の通
知を受け取る
• 今回検証したListenerは以下の通り

18
新しいスイッチやポートの登録：
OpenDaylight
InventoryListener
パケットの受信：
PacketProcessing
Listener
データモデルのデータの変化：
DataChangeListener
• 検知するイベントとListenerの例を以下に示す

６．まとめ
• OpenDaylightのアプリの開発はまだまだハードルが高
い
• 1から作るよりは既存のプロジェクトをベースにした方が
良い
• アプリを開発する時には、Config Subsystemを用いて
「model（モデル）」と「impl（実装）」と「config（管理）」の
3つを作成する
• バージョンアップの際には既存のAPIにも修正が入って
いる可能性があるので、動作を確認する
• リポジトリも頻繁に変更されるので、ビルドエラーが起き
たら疑ってみる
19

20
今後もOpenDaylightの最新情報を追いかけていきます！
Infrastructures Evolution

Open daylightバージョンアップ対応

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Open daylightバージョンアップ対応

Semelhante a Open daylightバージョンアップ対応 (20)

Open daylightバージョンアップ対応