SDN控制器ONOS架構—Vecloud

ONOS 是一個採用 OSGI 技術來管理子專案的 SDN 控制器開源專案，在最初設計時有這麼幾個目標是明確的：
1. 程式碼模組化：支援把新的功能作為新的獨立單元引入
2. 特性可配置：無論是在啟動還是執行時，支援動態載入和解除安裝特性
3. 協議無關：應用不需要和具體的協議庫和實現繫結
模組化的實現： ONOS 專案由一組子專案組成，每個專案都有自己的原始碼樹，可以獨立構建。為此， ONOS 的原始碼採用分層的方式來組織以方便利用 Maven 的級聯 POM 檔案組織。每個子專案都有自己的 pom.xml 檔案和目錄，子 pom.xml 檔案會繼承父 Pom 檔案的共享依賴項和配置，使它們能夠獨立於不相關的子專案構建。 Root 目錄包含用於建立完整的專案及其所有模組的頂層 POM 檔案。
特性可配置： ONOS 使用 Karaf 作為其 OSGI 框架，除了在執行時的動態模組載入和啟動時的依賴解析， Karaf 還支援以下幾個特性。
支援使用標準的 JAX-RS API 來開發安全的 API 介面
支援將特性定義為一組 Bundle 來進行集中的自定義設定
對程式碼包有嚴格的語義版本宣告，包括第三方依賴
有易擴充套件的命令列框架，支援本地和遠端的 SSH 控制檯登陸
支援不同日誌級別的記錄
協議無關， ONOS 被劃分為以下幾個部分：
和網路互動的協議感知模組
協議無關的系統 Core ，跟蹤和服務網路狀態資訊
基於 Core 提供的系統資訊來進行消費和操作的應用
上面的每一層都是分層體系結構，其中面向網路的模組透過一個南向 ( 提供者 )API 與 Core 進行互動， Core 與應用程式透過北向 ( 消費者 )API 進行互動。南向 API 定義了協議中立的手段將網路狀態資訊傳遞給核心， Core 透過面向網路的模組與網路裝置互動。北向 API 為應用程式提供了描述網路元件和屬性的抽象，以便它們可以根據策略定義其所需的動作。
服務是一個功能單元，它由不同層的多個元件作為軟體堆疊建立垂直切片。我們把組成服務的元件的集合稱為子系統。
ONOS 定義了不同的子系統：
裝置子系統 - 管理基礎設施裝置的庫存。
鏈路子系統 - 管理基礎設施連結的庫存。
主機子系統 - 管理終端站主機及其在網路上的位置的庫存。
拓撲子系統 - 管理網路圖檢視的時間順序快照。
path 子系統計算 / 發現基礎設施裝置之間或端站的主機採用最新的拓撲圖快照之間的路徑。
FlowRule 子系統 - 管理安裝在基礎裝置的 match/action 流表項和統計流量。
Packet 子系統 - 允許應用程式監聽從網路裝置接收到的資料包，並透過一個或多個網路裝置向網路傳送資料包。
Provider
該堆疊的最底層是 Provider 元件， Provider 介面透過協議特定的庫和底層裝置打交道，並透過 Provider
Service 介面與 Core 互動。
協議感知 Providers 負責使用各種控制和配置協議與網路環境互動，並向 Core 提供服務特定的感知資料。 Provider 也可以從其他子系統收集資料，將它們轉換成特定於服務的資料。
Provider 可能還需要從 Core 接受控制命令應用並透過適當的網路協議具體手段應用到網路中。這些都是透過 Provider 介面將這些內容送入 Provider 元件。
Provider ID
一個 Provider 與特定的 Providerid 相關。 providerid 的主要目的是提供一個 Provider 族的外部身份，這可以使裝置和其他實體模型保持與負責他們的存在 Provider 相關聯，甚至在 Provider 載入 / 解除安裝操作之後。
Providerid 攜帶一個 URI 方案名稱允許鬆散的配對與從另一個供應商的家庭提供裝置，而這沒有訪問提供商本身是可能的。
Multiple Providers
子系統可以與多個 Provider 關聯。在這種情況下， Provider 被指定為主要的或附屬的。主 Provider 擁有與服務相關聯的實體，輔助提供者將其資訊作為覆蓋提供資訊。如果任何覆蓋導致與底層資訊衝突，則此方法給予主 Provider 優先權。裝置子系統是支援多個提供者的此類服務之一。
Manager
Manager 是駐留在核心中的元件，其接收來自 Provider 的資訊，並將其提供給應用程式和其他服務。它暴露了幾個介面：
Northbound Service interface 應用程式或其他核心元件可以透過該介面瞭解特定方面的網路狀態。
AdminService interface 以管理員命令應用到網路或系統的狀態。
Southbound ProviderRegistry interface
透過該介面 Provider 可以註冊到 Manager 中，透過它可以和 Manager 進行互動。
Southbound ProviderService interface 提供給已經註冊的 Provider
Manager 服務介面的消費者可以同步的查詢 Service 的資訊，也可以非同步的作為一個事件偵聽器 ( 例如，透過使用 listenerservice 介面註冊要監聽的事件並實現相關的 EventListener
interface) 。
Store
Store 的具體實現和 Core 裡面的 Manager 有很強的相關性， Store 需要索引，持久化以及同步 Manager 收到的資訊，這包括分散式 ONOS 多例項間的一致性和魯棒性的保障，
Application
應用透過 AdminService 和 Service 介面來消費和操作 Manager 聚合的資訊，應用程式具有廣泛的功能，這裡面就包括在 Web 瀏覽器中顯示網路拓撲，為網路流量設定路徑
Application ID
每個應用都有一個唯一的 Application ID ，這個標識用於追蹤應用相關的上下文 ( 任務和目標
比如 Intent 和 FlowRule) ，為了獲得一個有效的 ID ，應用需要註冊到 CoreService ，註冊他們的名字來進行反向域名解析，比如： org.onlab.onos.fwd
Events and Descriptions
兩個在 ONOS 中分佈的基本資訊單元是事件和描述。與服務一樣，事件和描述與特定的網路元素和概念相關聯。兩者都是一旦建立就不會改變的。
Descriptions
Descriptions 用於在南向的 API 上傳遞關於元素的資訊。例如，一個 HostDescription 包含一個主機的 MAC 和 IP 地址，在網路中的位置資訊 (VLAN
ID 和裝置 / 埠的連線點 ) 。 Descriptions 通常是由一個或多個模型物件組成。
Events
Manager 使用 Event 通知其 Listener 關於網路中的變化，並透過 Store 通知相關的在分散式設定中的 Peer 。一個事件由一個事件型別和一個由物件模型構成的主題組成。例如，一個 device
event 可通知 devicelisteners ， Device( 主題 ) 已經被發現 (device_added) ，失去了 (device_removed) ，或某一方面改變了 (device_updated) 。
Event dispatch
事件是由 Store 基於 Manager 的輸入產生的。一旦產生，事件就會透過 storedelegate 介面被分發到感興趣的聽眾，最終呼叫 event
deliveryservice 。從本質上講， Store Delegate 把事件從 Store 中取出， event
deliveryservice 確保事件僅為感興趣的聽眾接收。由於它們之間相互作用的方式，這兩個元件駐留在 Manager 中並由那裡的 Manager 提供 storedelegate 來做具體實現。
Event Listeners
Event Listener 是實現 EventListener 介面的任何元件。
EventListener 的子介面被按照監聽事件的型別進一步的分類。典型的 Event
listener 實現模式是將事件偵聽器作為 Manager 或應用程式的內部類，從中從接收到的事件呼叫相應的服務。這限制了事件處理邏輯不需要對子系統外部進行暴露。
Network representations
模型物件是 ONOS
協議無關方式來表示各種網路元素和屬性。事件將這些表示作為它們的主體。這些表示是由 Core 從 Description 中找到的資訊來構建的。

Vecloud是一家面向企業提供雲交換網路服務為核心業務的技術創新企業，在全球的資料中心節點30個，POP節點超過200個，服務的大客戶超過300個，涉及金融、網際網路、遊戲、AI、教育、製造業、跨國企業等行業領域。