淺談OpenDaylight的二次開發

OpenDaylight做爲一款開源SDN網絡控制器，依託於強大的社區支持以及功能特性，成爲了目前主流的SDN網絡控制器開發平臺。在比較穩定的OpenDaylight Helium版本中，已經爲開發者提供了大量的網絡管理功能與二次開發接口。可是因爲OpenDaylight架構複雜以及開發工具的多樣化，形成了二次開發思路不夠清晰的問題。本文旨在爲讀者梳理出一條比較清晰的OpenDaylight二次開發路線，下降OpenDaylight的二次開發難度。

1、 OpenDaylight架構簡析

要想清晰的看到OpenDaylight爲咱們提供了什麼，最直觀的方式就是對OpenDaylight架構圖進行梳理，如圖1：

圖1

如你們所知道的那樣，OpenDaylight的結構層次從下到上依次劃分爲數據平面（包括物理交換設備與虛擬交換設備等）、南向接口與協議插件、控制平面（包括核心控制部分與相關服務）、上層網絡應用與服務。數據平面設備的相關技術開發已經超出了OpenDaylight二次開發範疇，所以咱們的目光限定在南向協議與插件、控制器服務與上層應用的開發。整體來講，OpenDaylight的二次開發能夠分爲如下三個層面：

• 基於OpenDaylight REST APIs的上層網絡應用開發
• 基於SAL內核相關服務的控制器組件與上層網絡應用開發
• 基於SAL內核相關服務的南向協議插件開發與上層服務接口開發

固然，若是進行更具體的劃分，每一個層面還能夠劃分出更多的開發方向，可是就大的開發方向來講，主要使用以上三種開發模式。

下面簡單介紹一理圖1中的數據平面，以幫助讀者理解咱們的SDN網絡控制器功能實現的具體場景。在該圖中咱們能夠看到肯定的設備主要有實現OpenFlow功能的物理設備與承載Open vSwitch的虛擬交換設備，下面分類介紹一下：
實現OpenFlow功能的物理設備：通常爲提供多網絡接口的物理交換機，在交換機操做系統上實現對OpenFlow協議的支持，固然在混合方式交換機上能夠實現傳統的交換轉發方式。實例包括Cisco的IOS交換機操做系統，Broadcom的ICOS交換機操做系統等。

承載Open vSwitch的虛擬交換設備：此處所指的虛擬交換設備能夠是咱們在物理交換機虛擬化出的虛擬交換機，也能夠是咱們在實驗環境下搭建的模擬交換設備。比較典型的應用就是咱們在進行SDN實驗時所使用的mininet模擬網絡搭建工具，其實質就是使用Python語言對Open vSwitch的功能進行封裝，爲用戶提供網絡建立、刪除、更新與屬性控制等功能。

2、OpenDaylight的上層網絡應用及北向插件開發

對於OpenDaylight二次開發這個層面來說，通常所作的最多的是對OpenDaylight的Web可視化界面進行修改，同時進行更多的數據展現與添加功能操做控件。對於這些需求的開發，咱們須要使用的是SAL提供的基礎服務，調用他們所提供的REST APIs，或者使用SAL提供的基礎服務開發本身的服務接口，而後在上層使用各類開發語言與開發工具進行相對應功能的開發。開發框架圖如圖2所示：

圖2

1. SAL是什麼？

SAL的全稱爲Service Abstraction Layer（服務抽象層），分爲MD（Model-Driven）與AD（Application-Driven）兩種。SAL爲整個OpenDaylight項目框架提供基礎設施服務，包括了各類OpenDaylight開發須要用到的基礎功能，相似於Linux內核。AD-SAL與MD-SAL並無本質上的區別，只是API消費者與供應者之間的查詢路由方式有所區別。在AD-SAL中，並無使用YANG對相關請求與通知功能進行建模，而是直接靜態地使用了Java APIs進行路由與適配。在MD-SAL方式中，首先須要使用YANG對南向插件須要實現的功能建行功能建模，再使用YangTools與Maven生成相關Java APIs，經過對模型的查詢來動態地進行路由與適配。相關信息能夠參閱OpenDaylight的開發者手冊：
Page 51, OpenDaylight Developer Guide Helium SR2

2. 基於OpenDaylight REST APIs的上層網絡應用開發

基於OpenDaylight REST APIs進行上層網絡應用開發，是三個開發層面中相對來講最簡單的一種方式。直接調用OpenDaylight REST APIs進行開發，可使開發者屏蔽掉底層複雜的功能實現，而專一於功能的創新與開發。可是直接使用API進行開發仍舊不夠簡便，由於須要進行大量的GET/POST等操做，所以，能夠在查詢到API的基礎上，將相相似的功能用開發語言進行封裝，作出SDK，從而提高開發效率。

使用這種方式的關注點更多集中於Web可視化界面的開發，下面就幾種主流Web開發框架作一下討論：

• Python + Django：筆者目前從事的研究主要是OpenDaylight與OpenStack功能進行對接，所以更多的關注這種架構的實現。Django是一種基於MTV的Web開發框架，OpenStack的Horizon界面項目是基於這種框架進行開發的。另外，OpenStack的整個工程項目都是使用Python進行開發，所以，使用Python + Django的開發方式能夠比較好的實如今OpenStack雲平臺中加載OpenDaylight網絡管理功能與界面添加。
• LAMP：PHP是一種便捷的網絡後端開發語言，有強大的函數庫與簡潔的調用方式，若是單純基於OpenDaylight進行Web UI的開發，這種選擇不失爲一種良好的方案。
• Java Spring：Java Spring是一種基於MVC的Web開發框架，使用這種方案的優勢是OpenDaylight內核使用Java進行開發，當咱們須要開發本身的插件爲上層應用提供接口的時候，這種方式比較便於接口的對接。如圖2中的應用B所示。

下面簡單列出一些經常使用的API模塊，供讀者參考，具體API掛載點會因版本不一樣而略有差別，在此再也不列出，只介紹相關功能：

表1 OpenDaylight SAL層經常使用API模塊

以上簡單羅列了經常使用的API模塊，更多具體信息讀者能夠自行查詢相關文檔。經常使用的API掛載點通常具備以下形式：http://127.0.0.1:8080/controller/nb/v2/topology/default。同時，使用API獲取的返回數據通常爲XML/JSON形式，因此建議使用相關開發工具先進行數據解析，而後封裝爲SDK以提高開發效率。

實踐參考：https://www.sdnlab.com/11480.html

3. 基於SAL內核相關服務及北向插件的控制器組件與上層網絡應用開發

在上一小節中，咱們討論瞭如何利用OpenDaylight已有的REST APIs進行上層網絡應用的開發，這種方式能夠說是依賴於OpenDaylight平臺的外部開發，並不是嵌入OpenDaylight內部的應用開發。這種開發方式能夠實現的關鍵是OpenDaylight已經爲咱們提供了相應的開發接口，但若是現有的OpenDaylight沒有爲咱們提供相關的接口，這就須要咱們進行更深一層次的開發，即基於SAL內核相關服務進行所需的控制器組件與上層網絡的應用開發。

本小節所述的基於SAL內核相關服務的控制器組件與上層網絡應用開發方式通常的應用場景是上層網絡應用程序須要藉助已有的SAL相關服務及南向插件/協議實現某些特定的功能，而該功能並未由OpenDaylight控制器給出REST API，如圖2所示的應用B的開發。這種方式相對來講更能夠稱的上是OpenDaylight的二次開發。在介紹具體內容以前，首先須要瞭解如下儲備知識：

• OSGi與OSGi組件：OpenDaylight平臺的後臺。爲整個工程項目提供了模塊化管理的方式，即OSGi組件。每一個組件能夠實現某些特定的功能，並加載到工程的運行環境中。
• Maven工具：Maven工具是用來實現對於OpenDaylight整個工程項目進行管理控制的工具。能夠用Maven生成不一樣的項目，不一樣的組件。每個Maven項目包含一個項目控制文件pom.xml，一個src文件夾，一個test文件夾。一般pom.xml文件使用結構化的文檔來對整個項目的屬性配置、外部依賴、編譯進程與外部輸出等進行設置，實現了工程的自動化管理。在src文件夾內包含項目或組件相關的源程序，test文件夾中包含相關測試程序。Maven是該小節所述的開發方式的基礎，讀者能夠參考官方網站的文檔進行學習。
• Apache Karaf：Karaf工具是基於OSGi的OpenDaylight特性容器，用於實現OpenDaylight各功能組件的熱插拔。

基於SAL內核相關服務的控制器組件與上層網絡應用開發須要藉助於OpenDaylight開發平臺已經實現的模塊與組件，調用其Java APIs以幫助實現咱們所須要的功能。下面簡單羅列一下OpenDaylight爲咱們提供的相關編程服務接口：

表2 OpenDaylight模塊/組件列表

完整組件列表能夠查閱：https://wiki.opendaylight.org/view/Controller_Projects%27_Modules/Bundles_and_Interfaces

鑑於MD-SAL的複雜性，咱們將在下一小節進行重點討論，在本小節咱們將主要關注基於AD-SAL來實現北向應用插件的開發。流程圖以下：

在上述流程圖中須要實現的各個步驟都涉及到了多種文件的配置與工具的使用，請有興趣的讀者自行查閱相關文檔瞭解相關設置.能夠參考如下文章。

實踐參考：https://www.sdnlab.com/11456.html

3、OpenDaylight的南向插件/協議開發

在上一小節中，咱們討論瞭如何基於AD-SAL以及相關北向插件服務進行特定應用北向插件的開發，在這種開發方式中，主要是使用的AD-SAL服務。在接下來的章節中，咱們主要介紹一下基於MD-SAL進行南向插件的開發。

OpenDaylight的南向插件，又叫作南向協議插件，主要承擔如下任務：

• 處理控制器與南向網絡設備之間的會話
• 提供多種接入網絡設置功能的抽象接口

基於MD-SAL的南向協議插件開發方式是咱們橫向拓展OpenDaylight功能的實現方式，是一套從底層到上層的完整功能開發路線。與前兩種開發方式不一樣的是，咱們須要實現的功能在現有的OpenDaylight並未提供太多的功能實現，必須依賴於工業標準或者自主開發的協議算法，在南向插件層進行功能添加，並將插件綁定在SAL上，從而能夠轉入前述的兩種開發方式中。具體開發流程如圖4所述：

圖4

此處關於插件與SAL交互及其工做方式不作介紹，有興趣的讀者能夠參考：
Page 54, OpenDaylight Developer Guide Helium SR2

由上圖咱們能夠看出，整個MD-SAL南向插件開發的第一步源自於對於所要實現功能的YANG建模。YANG是用於對南向協議插件具體功能實現進行服務接口封裝的工具，經過進行YANG建模與Yang Tools工具的配合，咱們能夠產生須要功能的Java API，再通過Maven的編譯能夠產生JAR包做爲OSGi組件插入到控制器中。此時，南向協議插件的服務就能夠被其它插件經過API調用開發。

在另外一方面，經過編寫Java源代碼來具體實現咱們所要添加的協議或者工業標準的功能，經過Maven編譯工具生成JAR包做爲OSGi組件插入到控制器中。這樣，在其它插件調用相對應的Java API時，就能夠依據必定的路由方式及查詢方式來映射API與功能實現。實現上層應用對所添加功能的調用。

4、總結

在本文中，咱們簡單介紹了OpenDaylight二次開發的三種方式，更多的詳細敘述讀者能夠參閱開發者手冊與相關源代碼。本文所提出的三種方式針對不一樣的應用場景，具體方式的選擇能夠參考下圖：

本文幫助讀者梳理了OpenDaylight的二次開發路線，但願讀者在讀完本文以後對於OpenDaylight的二次開發有個更加清晰的認識。基於OpenDaylight複雜的軟件架構，僅僅瞭解以上的內容是遠遠不夠的，須要結合更多具體的代碼進行實踐學習，在實踐中掌握OpenDaylight並開發出好的SDN控制器。

後記

這篇文章是在接觸OpenDaylight一段時間以後的一個階段性總結，主要是幫助本身以及處在OpenDaylight開發入門階段的朋友可以清晰地瞭解咱們在OpenDaylight能作些什麼而且如何去作。但這篇文章畢竟只是個概略性地介紹與梳理，在後續的研發中，還須要不斷地結合代碼去實踐這些開發理念。同時，在寫這篇文章的時候，仍是感受到本身有許多的不足，所以，文章不免出現疏漏，但願讀者可以幫助糾正，你們共同進步。

做者簡介：

郝鵬（fabirdblue@foxmail.com），畢業於美國賓夕法尼亞大學，電子工程碩士，從事SDN相關研發工做。