獲電信業及網路設備商支持 ONOS躍居SDN控制器主流

2017-01-03
ONF(Open Networking Foundation)的主席在2016年6月的全球SDNFV技術大會上表示,在軟體定義網路(SDN)概念提出後的頭兩年為SDN南向介面的戰爭,而這兩年則為SDN控制器的戰爭。SDN控制器從一開始的百家爭鳴已漸漸收斂為幾款主流,其中包含OpenDaylight與開源網路作業系統(Open Networking Operating System, ONOS),此兩款控制器皆開放原始碼(Open Source)並且在全球皆擁有廣大的使用者、社群與合作的企業。
ONOS為一款以電信服務供應商為出發角度所設計而成的開源SDN作業系統,是由一家名為ON.Lab(Open Networking Laboratory)的非營利組織所開發,第一個版本是在2014年12月5日公布。ONOS的目標為提供電信服務供應商可以同時處理上千萬個用戶的高可靠性、可擴展性及高性能的作業系統,並且提供完整的南北向抽象層,方便服務開發、除錯、維護及升級。

此ONOS專案目前已得到許多業界資助和開發,其中包括電信商AT&T、NTT、中國聯通、SK Telecom、威瑞森(Verizon),網路設備商Ciena、愛立信(Ericsson)、思科(Cisco)、富士通(Fujitsu)、英特爾(Intel)、恩益禧(NEC)、華為,實驗研究網Internet2、CNIT、CREATE-NET,同時也獲得ONF的大力支持,2016年8月也宣布加入ONOS專案,使得ONOS一躍成為主流SDN控制器。

控制器戰場混沌 ON.Lab殺出重圍

在OpenFlow協定推出後,陸續有一些實驗性質的開源SDN控制器出現,包括NOX、POX、Beacon、SNAC、POX和Floodlight,這些控制器的問世展示了SDN的特點與潛力,可透過軟體方式直接控制網路的行為,從中衍生出許多更彈性更優化的網路應用。

但是,這些控制器並不能用於商業化的產品,因為它們皆缺乏可擴展性、可靠性以及良好的性能等商業所需的關鍵特點。ON.Lab瞄準此關鍵特點,耗費2年設計架構與開發,才於2014年底推出ONOS,並在推出後就獲得美國AT&T青睞,開始與業界合作開發各式各樣應用。

以下先從ONOS的大架構開始介紹,從架構中即可看見ONOS如何設計以符合ON.Lab當初的目標,接著將從上至下分別介紹北向介面抽象層、分散式核心架構以及南向介面抽象層,最後將介紹ONOS如何使用軟體模組化讓開發者可以方便地進行添加、改變和維護開發的應用服務。

了解ONOS運作架構

ONOS在設計時就從電信服務供應商的角度著手,充分地考慮到商用SDN控制器所須具備的高可用性、可擴展性以及高性能等基本需求,同時還有完整的北向介面和南向介面抽象層。

ONOS具備許多核心功能,包括分散式核心架構,透過分散式運算提供上述的高可擴展性、高可用性以及高效能,實現運營商等級SDN控制器所需的特徵,ONOS具備以叢集方式運行的能力使得SDN作業系統具有類似雲端風格的靈活性。

北向介面抽象層透過提供網路狀態、設備狀態以及應用程式意圖框架(Intent Framework),將網路和應用與控制、管理和配置等服務的開發解耦。這層抽象層同時也是SDN作業系統具有類似雲端風格的靈活性的因素之一。

南向介面抽象層則透過插件式南向協議控制OpenFlow設備和傳統設備,此抽象層將ONOS的核心功能和底層網路設備隔離,隱藏不同網路設備使用不同協議的差異性,這也是讓供應商能從傳統設備向OpenFlow白牌設備遷移的關鍵。此外,軟體模組化讓ONOS能像軟體系統般方便社群開發者和供應商開發、除錯、維護和升級服務(圖1)。

圖1 ONOS整體架構圖,核心為北向介面抽象層、分散式核心及南向介面抽象層。

何謂北向介面抽象層

ONOS架構中的北向介面抽象層有兩個強大功能:意圖框架和全局網路拓撲。意圖框架隱藏服務運行的複雜性,允許應用程式向網路請求服務而不須要了解服務運行的具體細節,這就意味著網路運營商和應用開發者能夠進行高等程式設計,可以輕鬆地提出意圖,使用想做什麼(What to do)取代要怎麼做(How to do)(圖2)。

圖2 ONOS提供意圖框架平台給上方應用程式能輕鬆地設計程式邏輯,而不需顧慮底層細節。

意圖框架負責處理所有應用程式的網路路徑規則請求,判斷可以滿足哪些應用、解決應用之間的衝突、執行管理者的策略、對網路程式設計提供請求的功能、交付請求的服務給應用程式等等。

一個意圖請求會轉化為多個目標,例如一個連接兩台主機的意圖會轉化為兩個目標,因為連接兩台主機是一個雙向的路經意圖,將各提供一個方向的流(Flow)。將意圖轉化的目標編譯成指令發送給網路設備,整個流程按照網路運維人員指定的策略進行。從某種程度上說,這個方法可以解決意圖之間的衝突。

全域網路拓撲為應用程式提供了網路資訊,包括主機、交換機以及網路相關的狀態參數,如使用率。應用程式可以通過應用程式介面(API)對網路拓撲進行程式設計,一個API可以為應用程式以網路圖的形式提供網路拓撲。基於網路拓撲可以進行以下工作:創建一個簡單的應用,當該應用獲得網路全域拓撲後計算最短路徑。透過監控網路拓撲和程式設計改變路徑調節負載(流量工程)最大化網路利用率,將流量從壅塞或因病毒被隔離的網路中引導出來。

確切地說,北向介面抽象層和API將應用與網路細節進行隔離,而且也可以隔離需要了解網路事件(如路徑中斷)的應用和其他應用。反而言之,將網路作業系統與應用隔離,網路作業系統可以管理來自多個、競爭應用的請求。從商業角度看,提高了應用開發速度,允許網路改變並且保證應用不會當機。

剖析分散式核心架構

ONOS可以被視為服務實例(Instance)部署在伺服器叢集上,在每個伺服器上運行相同的ONOS軟體,此種對稱性分散式部署的設計考量非常重要,讓ONOS在發生故障時能快速由其他正常運作的ONOS服務實例接手保持運作穩定,且網路運營商也可以在不中斷服務的情況下依據網路用量增加或減少伺服器,輕鬆地擴增或縮減SDN作業系統的處理能力。

ONOS服務實例協同運作形成一個被下方網路設備及上方應用程式視為統一的控制平台,網路設備和應用程式無須知道目前是和單一的ONOS服務實例互動抑或是多個ONOS,這個特徵實現了ONOS的可擴展性,也是分散式核心平台所擁有的好處(圖3)。

圖3 多個ONOS服務實例可組成單一控制平台,並且擁有高可靠性與高可擴展性。

分散式核心提供實例間的通訊、狀態管理和領導選舉等服務,因此多個實例可以表現為單一邏輯實體。透過使用發表/訂閱(Publish/Subscribe)模組中的高速訊息(High Speed Messaging),ONOS實例可以將更新訊息快速地通知給其他實例。而ONOS內部也有錯誤恢復協議的設計來處理因為實例故障而引起的更新丟失。

ONOS使用多種機制管理實例的操作狀態,並且每種機制與狀態類型皆一一對應。其中典型的例子就是意圖框架、拓撲資料庫和流表(Flow Table),每個都有獨特的大小、讀/寫模式和時間需求。除此之外,領導選擇服務可以確保每個交換機只會連接到一個Master實例。加總起來,通訊、狀態管理和領導選舉機制保證了叢集的高性能、低延遲和高可靠性(圖4)。

圖4 三個主要同步的狀態,包含意圖框架、拓撲資料和流表。

此分散式核心代表著,對網路設備而言,只有一個主ONOS實例,如果此主實例出現故障,則可透過領導選擇服務迅速連接另一個實例,無須重新創建新實例並重新同步流表。對於應用程式而言,可以透過北向介面抽象層持續獲取網路拓撲。

此外,實例故障或資料層(Data Plane)的故障對於應用程式來說是透明的,此特點使得開發應用程式難度大為簡化,且可省去許多錯誤處理。從商業角度來看,ONOS提供了一個高可用的環境,應用程式可以有效地避免與網路相關的下線時間。而且,電信服務供應商可以隨著網路的發展輕鬆地增減控制平台容量,並且不會產生網路中斷,電信服務供應商也擁有按照實例下線、更新、上線的步驟即可零關機更新軟體的能力。總而言之,分散式核心是ONOS中的關鍵特徵架構,使得SDN控制平台具備營運等級的能力。

認識南向介面抽象層

南向抽象層由網路元件構成,例如交換機、主機或是路徑。ONOS的南向抽象層將每個網路元件表示為通用格式的物件。透過這個抽象層,分散式核心可以維護網路元件的狀態,並且不須要知道底層設備的具體細節。網路元件抽象層允許添加新設備和協定,以可插拔的形式支援擴展。所以,南向介面抽象層確保ONOS能控管多種不同的設備,即使它們使用不同的協定(OpenFlow、NetConf、OVSDB等)。南向介面的最底層是網路設備,ONOS通過協定與設備連接,協定細節被網路元件外掛程式或調配器隱藏。

事實上,南向介面的核心是在不知道具體協定細節和網路元件的條件下維護網路元件物件(如設備、主機、路徑)。透過調配器API,分散式核心可以與網路元件物件狀態保持一致,調配器API將分散式核心與協定細節和網路元件相隔離。

南向介面抽象層的主要優勢包括:用不同的協定管理不同的設備,不會對分散式核心造成影響;擴展性強,可以在系統中添加新的設備和協定;輕鬆地從傳統設備轉移到支援OpenFlow的白牌設備。

軟體模組化加速開發時程

軟體模組化是ONOS一大特徵,基於軟體的形式可以很方便地進行添加、改變和維護開發的服務。ONOS團隊在模組化方面投入很多心血,就是為了讓開發者可以簡單快捷地操作軟體。

何謂模組化?模組化就是將軟體系統拆分為若干元件以及元件之間的互動方式。ONOS的主體架構是圍繞在分散式核心的分層架構。所以,從宏觀結構上來看,北向介面與南向介面抽象層將應用、分散式核心和調配層相互隔離,可以獨立添加新的應用和協議調配器。

從具體細節來看,分散式核心內部的子結構也能體現模組化特徵,分散式核心的存在價值就是約束所有子系統的規模並保證模組的可擴展性。此外,連接不同模組的介面是至關重要的,須保證模組不用依賴其他模組而可以獨立更新。這樣就可以不斷地更新演算法和資料結構,並且不會影響整體系統或是應用。

ONOS很重視溝通介面,因為介面可以促進模組功能和職責的分離,盡量使子系統之間的互動更為自然、簡單。這一特點是確保軟體穩定更新的關鍵。例如,盡量提高南向API的抽象程度,避免將不同協定的偏差傳遞到上層,並且強化分散式核心而不是調配層來創建網路模型物件。ONOS原始程式碼的樹形結構不僅僅為了遵循而是要加強這些結構原則。合理控制模組大小並且模組之間保持適當依賴形成一個非迴圈的結構圖,模組之間透過API模組相互關聯(圖5)。

圖5 ONOS軟體模組化,將不同功能的程式皆設計成一個一個模組。

軟體模組化的好處歸納為以下幾點:保證架構的完整性和連貫性;簡化測試結構,允許更多的整合式測試;減少系統某部分改變的負面影響,從而降低維護難度;元件具有可拓展和可客制的特性;避免迴圈依賴的情況。

擁護廠商漸增 ONOS未來可期

ONOS成軍短短不到2年的時間,已陸續發布七個版本,每個版本皆以一種鳥名命名,第七版為Goldeneye,ONOS每個版本都具有重大更新,例如第三版與許多企業開發的各式PoC專案如SDN-IP、封包與光纖整合網路等等,還有第四版整合了OPNFV和OpenStack雲端協作管理系統,以及提供安全模式的ONOS。以SDN-IP專案來說,可供SDN使用標準的邊界閘道協定來與外部網路連結。

ONOS目前最重要的專案則是CORD(Central Office Re-architected as a Datacenter),這是一個結合SDN、網路功能虛擬化(NFV)與雲端概念的新專案,旨在將部分網路功能以NFV方式部署在局端(Central Office),以此降低對網路設備的需求,以及提供更彈性的服務。目前有越來越多電信服務供應商與網路設備商加入此CORD專案中,他們相信結合SDN、NFV和雲端概念將是新一代網路的未來。

(本文作者任職於工研院資通所)

本站使用cookie及相關技術分析來改善使用者體驗。瞭解更多

我知道了!