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、教育、制造業、跨國企業等行業領域。http://www.vecloud.com/products/cloudconnect.html

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的SDN控制器ONOS架构—Vecloud的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。