ONOS研究材料

1、整理1、ONOS預熱篇之ONOS簡介（一）ONOS問世后引起廣泛關注，關于ONOS與ODL的紛爭不絕于耳，最近小編拜讀了一下ONOS白皮書，并做了一點粗淺總結，下面就跟大家分享一下。1 ONOS誕生背景1.1 ONOS誕生的利益分析隨著移動設備的不斷普及，OTT服務和內(nèi)容分發(fā)的興起導致服務提供商網(wǎng)絡迫切的需要一次網(wǎng)絡變革。為了應對日益增長的帶寬需求，服務提供商希望網(wǎng)絡可以更加敏捷高效，且能從創(chuàng)新型服務和新型業(yè)務模式中分一杯羹得到更好的發(fā)展，至此SDN的呼聲越來越高。而SDN中控制器占重要部分，是兵家必爭之地，陸陸續(xù)續(xù)已經(jīng)出現(xiàn)了很多SDN控制器，如OpenDaylight、OpenContrai

2、l、Ryu、Floodlight、NOX、SPOX等等，其中最受矚目的莫過于OpenDaylight了。OpenDaylight是由設備商主導的一個開源控制器，雖然打著開放的旗號，但是OpenDaylight一直排斥基于開放的協(xié)議方案，而是想采用折中的方案，即以開放專用接口的方式保留傳統(tǒng)設備，采取以退為進的方式維護自己的利益。不可否認地，設備商擁有豐富的設備研發(fā)經(jīng)驗， OpenDaylight也確實是一款優(yōu)秀的控制器，但是在這樣的壓力下，運營商不得不采取應對措施。于是，運營商推出了開放網(wǎng)絡操作系統(tǒng)ONOS。1.2 ONOS又憑什么與OpenDaylight叫板呢？過去幾年來已經(jīng)有幾款關于軟件定

3、義網(wǎng)絡的控制器，然而，我們很清楚地了解大部分控制器缺乏可擴展性、可靠性，除此之外，他們的性能不夠良好且抽象層過于簡單粗糙，并不能用于商業(yè)化產(chǎn)品。這些控制器直接向功能組件發(fā)送OpenFlow消息，而這些功能組件直接為網(wǎng)絡設備創(chuàng)建OpenFlow消息，這樣看來，這些控制器更像是設備驅(qū)動。它們不具備一個完整的SDN控制器平臺所需的性能特征。真正需要的是一個一體化的網(wǎng)絡操作系統(tǒng)，ONOS就是為了滿足這些需求而創(chuàng)建。一個操作系統(tǒng)應該具備下述功能：§ 用戶資源管理。確保所有用戶有同樣的權利，沒有資源匱乏也沒有資源泛濫、公平、合理的分配資源。§ 用戶隔離。由于每個用戶都希望全權分配資源，

4、所以將用戶相互隔離，在多個應用和多個設備之間多路傳輸，并且通過資源虛擬化技術讓用戶享用各自的虛擬化OS可操作應用。§ 抽象層管理。提供一個抽象層方便用戶使用操作系統(tǒng)所管理的服務和資源，無需了解網(wǎng)絡的復雜性；且在不改變應用的前提下，可以靈活拓展操作系統(tǒng)所管理的設備。§ 提供用戶安全保障機制。§ 提供敏捷高效性服務。用戶無需重建相同的服務，提高使用效率。ONOS具備一個操作系統(tǒng)所具備的所有功能，不僅僅是控制器的功能。除此之外，ONOS還提供技術社區(qū)專欄，給更多的研究學者提供更廣闊的交流、共享平臺。2 ONOS社區(qū)概覽ONOS的發(fā)布是一場業(yè)內(nèi)盛宴，集聚了知名的服務提供商

5、（如AT&T、NTT通信）、高標準的網(wǎng)絡供應商（如Ciena、Ericsson、Fujitsu、Huawei、Intel、NEC）、網(wǎng)絡運營商（如Internet2、CNIT、CREATE-NET），以及其他合作伙伴（如SRI、Infoblox），并且獲得ONF的鼎力支持。2.1 ONOS社區(qū)的目標打造一個社區(qū)，共同完成SDN的愿景與使命：§ 生產(chǎn)高質(zhì)量的網(wǎng)絡操作系統(tǒng)軟件；§ 創(chuàng)建高效的開源流程，吸引更多同道中人；§ 通過不斷努力以及貢獻促進社會科技、生活的發(fā)展。2.2 ONOS社區(qū)的自我要求§ 顧客，服務顧客；§ 精英，采用精英管理體

6、制；§ 創(chuàng)新，堅持創(chuàng)新；§ 質(zhì)量，始終如一地追求高質(zhì)量；§ 尊重，永遠尊重別人；§ 透明化，透明化操作及管理。3 ONOS簡介服務提供商希望他們的網(wǎng)絡敏捷、高效，滿足日益增長的帶寬需求，以創(chuàng)新服務和新型業(yè)務模式獲取收入。軟件定義網(wǎng)絡SDN是服務提供商網(wǎng)絡轉(zhuǎn)型的關鍵，而ONOS是一個為服務提供商量身打造的新型運營商級別的SDN網(wǎng)絡操作系統(tǒng)，由ON.Lab和ONOS社區(qū)內(nèi)領先的服務提供商、供應商和開發(fā)者共同開發(fā)。ONOS是首款開源的SDN網(wǎng)絡操作系統(tǒng)，主要面向服務提供商和企業(yè)骨干網(wǎng)。ONOS的設計宗旨是滿足網(wǎng)絡需求實現(xiàn)可靠性強、性能好、靈活度高。此外，ONO

7、S的北向接口抽象層和API支持簡單的應用開發(fā)，而通過南向接口抽象層和接口則可以管控OpenFlow或者傳統(tǒng)設備?？傮w來說，ONOS將會實現(xiàn)以下功能：§ SDN控制層面實現(xiàn)電信級特征（可靠性強，性能好，靈活度高）；§ 提供網(wǎng)絡敏捷性強有力保證；§ 幫助服務提供商從現(xiàn)有網(wǎng)絡遷移到白牌設備；§ 減少服務提供商的資本開支和運營開支。ONOS架構概述：ONOS具有下述核心功能：§ 分布式核心平臺，提供高可擴展性、高可靠性以及高穩(wěn)性能，實現(xiàn)運營商級SDN控制器平臺特征。ONOS像集群一樣運行，使SDN控制平臺和服務提供商網(wǎng)絡具有網(wǎng)頁式敏捷度。§

8、北向接口抽象層/APIs，圖像化界面和應用提供更加友好的控制、管理和配置服務，抽象層也是實現(xiàn)網(wǎng)頁式敏捷度的重要因素。§ 南向接口抽象層/APIs，可插拔式南向接口協(xié)議可以控制OpenFlow設備和傳統(tǒng)設備。南向接口抽象層隔離ONOS核心平臺和底層設備，屏蔽底層設備和協(xié)議的差異性。且南向接口是從傳統(tǒng)設備向OpenFlow白牌設備遷移的關鍵。§ 軟件模塊化，讓ONOS像軟件操作系統(tǒng)一樣，便于社區(qū)開發(fā)者和服務提供商開發(fā)、調(diào)試、維護和升級。   SDNLAB語：SDN時代的到來為服務提供商提供了轉(zhuǎn)型機遇，為了能夠從創(chuàng)新型服務和新型業(yè)務模式中分一杯羹，服

9、務提供商一直在探索轉(zhuǎn)型的跳板。ONOS就是一款為服務提供商量身打造的產(chǎn)品，助力服務提供商轉(zhuǎn)型。隨著ONOS的參戰(zhàn)，業(yè)內(nèi)競爭愈加激烈，SDN的發(fā)展前景也越來越明朗化。期待12月5號，ONOS的首發(fā)！2、ONOS預熱篇之架構簡析（二）ONOS是首款專門面向服務提供商和企業(yè)骨干網(wǎng)的開源SDN網(wǎng)絡操作系統(tǒng)，是由一家名為開放網(wǎng)絡實驗室（ON.Lab）的非盈利性組織打造的一款商用控制器，并將于美國時間2014年12月5日全球首發(fā)。ONOS旨在為服務提供商和企業(yè)骨干網(wǎng)提供高可用性（HA）、可橫向擴展及高性能的網(wǎng)絡需求。由于該項目得到了業(yè)界各知名大佬包括服務提供商AT&T、NTT，網(wǎng)絡供應商Ciena

10、、Ericsson、Fujitsu、Huawei、Intel、NEC，網(wǎng)絡運營商Internet2、CNIT、CREATE-NET的資助和開發(fā)，并獲得了ONF的鼎力支持，使得ONOS的消息一公布就被炒得炙手可熱，可謂賺足了眼球。目前市面上已經(jīng)有很多開源SDN控制器，包括NOX、Beacon、SNAC和POX，這些控制器的問世向我們展示了SDN的魅力與潛力。但是我們必須清楚這些控制器并不能用于商業(yè)化的產(chǎn)品，因為它們?nèi)狈蓴U展性、可靠性以及良好的性能等商業(yè)所需的關鍵特性。據(jù)稱這也將是一款能與OpenDaylight抗衡的一款商業(yè)級SDN網(wǎng)絡操作系統(tǒng)。那么，ONOS到底怎樣實現(xiàn)商業(yè)化性能的，它的架構

11、到底出色在哪里？下面小編從ON.Lab官方發(fā)布的白皮書摘取了相關資料來簡析一下ONOS的架構。1. ONOS架構ONOS架構設計伊始就將服務提供商放在首位?？煽啃詮姟㈧`活度高以及良好的性能都是最基本的要素，同時它還具有強大的北向接口和南向接口。ONOS具有的核心功能主要包含：北向接口抽象層/APIs、分布式核心、南向接口抽象層/APIs、軟件模塊化，具體將做詳細分析。下圖給出了ONOS的設計架構圖:圖 1. ONOS的設計架構圖1.1 北向抽象層ONOS有兩個強大的北向抽象層：Intent架構和全局網(wǎng)絡視圖。Intent架構屏蔽服務運行的復雜性，應用向網(wǎng)絡請求服務而不需要了解服務運行的具體細節(jié)

12、。應用更多的集中于能做什么，而不是怎么做。全局網(wǎng)絡視圖為應用提供了網(wǎng)絡視圖，包括主機、交換機以及和網(wǎng)絡相關的狀態(tài)參數(shù)，如利用率。應用可以通過APIs對網(wǎng)絡視圖進行編程，一個API可以為應用提供網(wǎng)絡視圖。確切的說，北向接口抽象層和APIs將應用與網(wǎng)絡細節(jié)隔離，而且也可以隔離應用和網(wǎng)絡事件（如連接中斷）。相反的，將網(wǎng)絡操作系統(tǒng)與應用隔離，網(wǎng)絡操作系統(tǒng)可以管理來自多個、競爭應用的請求。從業(yè)務角度看，提高了應用開發(fā)速度，并允許在應用不停機的狀態(tài)下進行網(wǎng)絡更改。1.2 分布式核心（DISTRIBUTED CORE）分布式核心平臺提供組件間的通信、狀態(tài)管理，領導人選舉服務。因此，多個組件表現(xiàn)為一個邏輯組件

13、。對設備而言，總是存在一個主要組件，一旦這個主要組件出現(xiàn)故障，則連接另一個組件而無需重新創(chuàng)建新組件和重新同步流表。對應用而言，網(wǎng)絡圖形抽象層屏蔽了網(wǎng)絡的差異性。另外，應用可以獲悉組件和數(shù)據(jù)平臺的故障代碼。這些都大大簡化了應用開發(fā)和故障處理過程。從業(yè)務角度看，ONOS創(chuàng)建了一個可靠性極高的環(huán)境，有效地避免應用遭遇網(wǎng)絡連接中斷的情況。而且，當網(wǎng)絡擴展時網(wǎng)絡服務提供商可以方便地擴容數(shù)據(jù)平臺，且不會導致網(wǎng)絡中斷。通過相同的機制，網(wǎng)絡運營商也可以實現(xiàn)零宕機離線更新軟件。總而言之，分布式核心平臺是ONOS架構特征的關鍵，將SDN控制器特征提升到電信運營商級別。圖 2. ONOS分布式核心架構圖1.3 南向

14、接口抽象層南向抽象層由網(wǎng)絡單元構成，例如交換機、主機或是鏈路。ONOS的南向抽象層將每個網(wǎng)絡單元表示為通用格式的對象。通過這個抽象層，分布式核心平臺可以維護網(wǎng)絡單元的狀態(tài)，并且不需要知道底層設備的具體細節(jié)。這個網(wǎng)絡單元抽象層允許添加新設備和協(xié)議，以可插拔的形式支持擴展，插件從通用網(wǎng)絡單元描述或操作映射或轉(zhuǎn)化為具體的形式，反之亦然。所以，南向接口確保了ONOS可以管控多個使用不同的協(xié)議的不同設備。南向抽象層的主要優(yōu)勢包括：§ 可以用不同的協(xié)議管理不同的設備，且不會對分布式核心平臺造成影響。§ 擴展性強，可以在系統(tǒng)中添加新的設備和協(xié)議。§ 可以輕松地從傳統(tǒng)設備遷移到支

15、持OpenFlow的白牌設備。1.4 軟件模塊化軟件模塊化是ONOS一大結構特征，方便軟件的添加、改變和維護。ONOS的主體架構是圍繞分布式核心平臺的三層架構，核心平臺內(nèi)部的子結構也能體現(xiàn)模塊化特征，核心平臺的存在價值就是約束任何一個子系統(tǒng)的規(guī)模并保證模塊的可拓展性。此外，連接不同模塊的接口是至關重要的，允許模塊不依賴其他模塊獨立更新。這樣就可以不斷更新算法和數(shù)據(jù)結構，并且不會影響整體系統(tǒng)或是應用，這一特點是確保軟件穩(wěn)定更新的關鍵。ONOS建立樹形結構不僅僅為了遵循而是要加強這些結構原則。合理控制模塊大小并且模塊之間保持適當依賴形成一個非循環(huán)的結構圖，模塊之間通過API模塊之間關聯(lián)，正如下圖所

16、示：圖 3. ONOS模塊結構圖軟件模塊化的優(yōu)勢歸納為一下幾點：§ 保證結構的完整性和連貫性；§ 簡化測試結構，允許更多的集成測試；§ 減小系統(tǒng)某部分改變的影響，從而降低維護難度；§ 組件具有可拓展和可定制的特性；§ 規(guī)避循環(huán)依賴的情況。2. 總結本文簡析了ONOS的設計架構，因為截稿前產(chǎn)品還未發(fā)布，只是根據(jù)官方發(fā)布的白皮書簡要闡述它們的設計意圖、理念以及架構各層面主要特點。想要具體了解ONOS還待12月5日正式發(fā)布及小編后續(xù)的文章。3、ONOS預熱篇之開放分布式SDN操作系統(tǒng)（三）關于構建ONOS（開放式網(wǎng)絡操作系統(tǒng)）的項目專題，是通過性能激

17、發(fā)創(chuàng)建的實驗性分布式SDN控制平臺，滿足大型運營商網(wǎng)絡的可擴展性、可用性需求。提出了2個版本的ONOS原型，第一個原型版本實現(xiàn)的核心功能是實現(xiàn)一個分布式的但在邏輯上集中的全局網(wǎng)絡視圖、可擴展性和容錯。另一個原型版本側(cè)重于提高性能，基于這兩個原型的實踐，已形成論文發(fā)表ONOS: Towards an Open, Distributed SDN OS，確定需要ONOS來支持使用案例，如核心網(wǎng)絡流量工程和調(diào)度，變成一個在可用的開源SDN社區(qū)構建分布式網(wǎng)絡操作系統(tǒng)平臺。一、 介紹近年，學術界和產(chǎn)業(yè)界對SDN產(chǎn)生了極大的興趣。一個開放的、廠商中立的、控制數(shù)據(jù)平面分離的接口如OpenFlow，允許網(wǎng)絡硬件

18、和軟件獨立發(fā)展，并促進了免費的開源的網(wǎng)絡操作系統(tǒng)的發(fā)展，來更換傳統(tǒng)的、價格昂貴的、專有的硬件和商用硬件。通過管理網(wǎng)絡資源和提供高層次的抽象和APIs，NOS提供一個開放的平臺，它簡化了創(chuàng)新有益網(wǎng)絡應用的創(chuàng)建并且服務于多種硬件網(wǎng)絡。為了支持大型網(wǎng)絡，NOS必須滿足可擴展性大、性能高、可用性強的需求。根據(jù)網(wǎng)絡運營商的討論，并考慮到服務提供商網(wǎng)絡中的流量工程使用，我已確定幾個極具挑戰(zhàn)性的需求，如圖1：圖1：ONOS需求§ 高吞吐量，達到1M requests/s；§ 低延遲，事件進程10-100ms；§ 全局網(wǎng)絡狀態(tài)大小，數(shù)據(jù)量最高達到1TB；§ 高可用性，9

19、9.99%的服務可用性。為了解決上述問題，已在實驗系統(tǒng)上運行開放網(wǎng)絡操作系統(tǒng)（Open Network Operating System，ONOS）。ONOS采用一個分布式架構，可達到高可用性和高擴展性，為應用程序提供一個全局的網(wǎng)絡視圖，即使物理上分布在多服務器，邏輯上也可集中管控。ONOS作為一個開源項目，主要通過下面兩個重要原型的開發(fā)逐漸發(fā)展演變：（1）原型1在分布式平臺上為擴展性和容錯能力致力于全局網(wǎng)絡視圖；（2）原型2致力于提高性能，尤其是為事件延遲添加了一個事件通知框架，改變數(shù)據(jù)存儲和數(shù)據(jù)模型并添加緩存層。二、 原型1：網(wǎng)絡視圖、擴展和容錯ONOS最初的挑戰(zhàn)是創(chuàng)建一個有用的抽象層、全

20、局網(wǎng)絡視圖、以及在一個系統(tǒng)上跨多個服務器運行在控制層面的擴展和容錯能力。使用開源構件建立的第一個原型是為了快速驗證以及更深入探索設計的可能性。根據(jù)現(xiàn)有的開源SDN控制器Floodlight開發(fā)出第一個原型，使用了Floodlight的部分模塊，包括交換機管理、I/O回環(huán)、鏈路發(fā)現(xiàn)、模塊管理和REST APIs。下圖顯示了原型1的系統(tǒng)架構：圖2：原型1架構2.1 全局網(wǎng)絡視圖ONOS含有全局網(wǎng)絡視圖功能，在集群中通過ONOS服務器管理和共享網(wǎng)絡狀態(tài)，并提供一個對應底層網(wǎng)絡結構的網(wǎng)絡視圖模型。在每個ONOS實例中發(fā)現(xiàn)的網(wǎng)絡拓撲和狀態(tài)，如交換機端口、鏈路和主機信息構成全局網(wǎng)絡視圖，并從全局網(wǎng)絡視圖中

21、讀取應用程序確定轉(zhuǎn)發(fā)策略，然后將轉(zhuǎn)發(fā)策略依次寫到網(wǎng)絡視圖中，當視圖信息發(fā)生變化時，將變化消息發(fā)送到相應的OpenFlow控制器并下發(fā)到在指定的交換機上。初始的網(wǎng)絡視圖數(shù)據(jù)模型，采用Titan圖形數(shù)據(jù)庫實現(xiàn)、使用Cassandra鍵值存儲實現(xiàn)分布式和可持續(xù)性，通過Blue-prints圖形API暴露網(wǎng)絡狀態(tài)給應用程序。由于Cassandra具有一致性存儲的特性，所以保障了網(wǎng)絡試圖的最終一致性。2.2 可擴展性ONOS的一個關鍵功能是其可擴展性和容錯能力的分布式架構，ONOS運行在多個服務器上，每個作為專屬的master OpenFlow控制器，管理網(wǎng)絡子集中的交換機。一個ONOS將獨立完成對網(wǎng)絡

22、及交換機的控制并負責全局網(wǎng)絡視圖之間的狀態(tài)變化；當數(shù)據(jù)平面容量增長或者在控制平面需求增加時，附加的ONOS應用實例可以被添加到ONOS集群中分發(fā)控制平面的工作負載，體現(xiàn)了良好的可擴展性。2.3 容錯能力在ONOS分布式體系結構中，當一個組件或ONOS實例失敗時，有其他剩他實例的情況下，允許重新分配，保障系統(tǒng)仍能繼續(xù)工作。ONOS的架構允許在運行時組件存在于一個實例，但是提供多個冗余的實例，接管之前的失敗實例來控制組件。在運行時通過在所有實例中選擇一個最優(yōu)實例來代替初始實例。一個交換機可以連接多個ONOS實例，但是對于每個交換機來說，只有一個主（master）實例控制。這個master實例獨自負

23、責發(fā)現(xiàn)交換機信息和控制交換機，當一個ONOS主實例失敗時，剩余的實例選擇一個新的master來控制交換機。與每個交換機一致性匹配度最高的ONOS實例被選擇運行最為master，以確保在所有交換機中，被選擇的這個ONOS實例能夠負責每臺交換機。用Zookeeper管理交換機和控制器之間的關系，包括監(jiān)測和反饋ONOS實例是否失敗；同時，ONOS實例一定要與Zookeeper保持連接為了成為交換機的master控制器。如果一個ONOS實例與Zookeeper失去連接，另一個ONOS實例將負責控制此交換機。Zookeeper使用一個匹配的協(xié)議維持與ONOS很大的一致性，且只要大多數(shù)服務器可用，Zook

24、eeper就有很強的容錯能力。2.4 評估第一個ONOS原型開發(fā)歷經(jīng)4個月，在2013年4月在ONS（Open Networking Summit）大會上演示了ONOS原型1，這個演示顯示ONOS控制幾百個虛擬交換機、使用網(wǎng)絡視圖下發(fā)端到端的流、動態(tài)添加交換機和ONOS實例到集群中、針對ONOS實例停機的故障轉(zhuǎn)移以及針對鏈路響應失敗重新添加路由等?？傮w來說，雖然已經(jīng)實現(xiàn)了系統(tǒng)的基本功能，但是一些設計選擇導致性能和可用性并不好，主要表現(xiàn)是一下幾個方面：§ 一致性和完整性。Titan在Cassandra上最終要保持數(shù)據(jù)存儲的一致性以及圖形架構的完整性，比如一條鏈路必須連接兩個節(jié)點；

25、67; 低性能和可見性。原型1延遲比預期差很多，主要原因在于使用開源軟件，雖然很快可以完成開發(fā)，但是這些開源軟件之間的協(xié)調(diào)，并不容易。而且ONOS的開發(fā)者并不是特別熟悉這些開源代碼，導致性能并不高；§ 數(shù)據(jù)模型問題。使用Titan存儲導致所有數(shù)據(jù)如Port,flow entries等都需要以Vertices存儲，需要構建一個索引來查詢數(shù)據(jù)，如交換機數(shù)據(jù)。當大量節(jié)點加入網(wǎng)絡時，并發(fā)的數(shù)據(jù)量增加導致索引構建就會成為瓶頸；§ 過多的數(shù)據(jù)存儲操作。Titan和Cassandra間的數(shù)據(jù)轉(zhuǎn)換會產(chǎn)生過多數(shù)據(jù)存儲操作導致延遲；§ 輪詢問題。通過周期同步數(shù)據(jù)，沒有實現(xiàn)訂閱分發(fā)，增

26、加CPU的使用率。通過模型1的測試及分析，需要設計更高效的數(shù)據(jù)模型，減少多余的數(shù)據(jù)操作，實現(xiàn)訂閱分發(fā)機制以及簡化API等。三、 原型2：性能提高原型2主要集中關注于提高ONOS的性能，但是這個導致改變了網(wǎng)絡視圖架構并添加了事件通知架構，如下圖所示：圖3：原型2架構遠程數(shù)據(jù)操作是原型1最大的性能瓶頸之一，所以在原型2中主要通過盡可能快的遠程操作、減少ONOS遠程操作量這2種方法解決這個問題。主要涉及的優(yōu)化主要有：1.RAM云數(shù)據(jù)存儲。使用內(nèi)存來代替普通硬盤來存儲，從而大大提高存儲速度；2.優(yōu)化數(shù)據(jù)模型。新設計了一個data model，更新相對獨立，大大減少了數(shù)據(jù)的讀寫操作，優(yōu)化了性能；3.拓撲

27、緩存。原型1讀取拓撲非常耗時，ONOS將拓撲信息存在高速緩存中，從而提高了讀取拓撲的速度。除此之外，通過構建索引更快速地查找數(shù)據(jù)。構建索引可以在任何時刻由全部的數(shù)據(jù)生成，但是一般情況下，只有新接入ONOS節(jié)點時，才會讀取全部數(shù)據(jù)，這不會消耗太多時間；4.事件通知。上文已提到由于周期獲取數(shù)據(jù)而引起的性能問題，所以引入事件通知機制。原型2創(chuàng)建實例內(nèi)部的發(fā)布-訂閱的事件機制，將這個通信系統(tǒng)部署在Hazelcast上；5.網(wǎng)絡視圖API。ONOS用自己設計的API取代生成的Blueprints graph API。圖4展示了網(wǎng)絡視圖的內(nèi)容，ONOS的API主要包涵下面的三個部分：§ 對底層設

28、施拓撲的抽象描述的接口；§ 處理網(wǎng)絡或系統(tǒng)Events（事件）的接口；§ 提供安裝流表等信息的接口。圖4：使用流表創(chuàng)建數(shù)據(jù)包路徑的連通性請求網(wǎng)絡視圖3.1 性能評估原型2的性能主要在以下三個方面進行測試和評價：§ 基礎網(wǎng)絡狀態(tài)改變；§ 對網(wǎng)絡事件的反應；§ 路徑部署；3.1.1 基礎網(wǎng)絡狀態(tài)改變當網(wǎng)絡中狀態(tài)發(fā)生改變，將進行數(shù)據(jù)更新操作，會阻塞ONOS的操作，將影響整個ONOS的性能。測試案例中使用三個節(jié)點的ONOS集群，連接81個OpenFlow交換機，構成一個典型的WAN拓撲，且每個交換機上都有四個活躍的端口。ONOS采用了對比的方式，表1展

29、示添加一個交換機后需要的latency，結果可以看出，使用通用的API速度最慢；使用自定義的API，速度提高很多。因為新的Data model僅需要一步就可以完成添加交換機操作，時間上從22.2ms降到1.19ms，延遲減少了很多。在序列化方面由原來的Kryo 嘗試使用Google Protocol Buffers，這使延遲時間下降了0.244ms。除此之外，在RAM云集群中還嘗試使用Infiniband硬件并優(yōu)化網(wǎng)絡的I/O，性能數(shù)據(jù)得到了提高。表1：添加一個交換機的延遲性能測試3.1.2 對網(wǎng)絡事件的反應對網(wǎng)絡事件的反應測試主要是針對ONOS對網(wǎng)絡事件的反應速度、端到端的延遲等性能，如網(wǎng)絡

30、中某一條鏈路斷掉后，ONOS對流量重選路由的過程需要多長時間，這個性能直接關系到SLA（Service-Level Agreement）的性能。實驗測試使用了6個節(jié)點的ONOS集群，數(shù)據(jù)層面使用Mininet模擬206個交換機和416條鏈路。將16000條flows添加到網(wǎng)絡中，然后關掉交換機的其中一個端口，結果分析顯示1000多條flows重新選擇路由，其中每一條流有6跳，當某一端口關掉之后，重新選擇路由，每一條流將變成7跳。表2顯示重選路由進度進行到一半和99%的數(shù)據(jù)，從網(wǎng)絡時間上捕捉到下發(fā)第一條flow_mod及全部flow_mod下發(fā)的延遲時間。表2：重選1000條流的路由延遲時間3.

31、1.3 路徑部署第三個性能指標測試ONOS系統(tǒng)的吞吐量，測試使用了與對網(wǎng)絡事件的反應測試相同的拓撲，但是預先下發(fā)15000條靜態(tài)流表，添加1000條6跳的flows。表3測試結果顯示的是路徑部署的延遲時間，吞吐量與延遲成反比，在所有流進程進行到一半時吞吐量為18832paths/sec。表3：路徑部署延遲時間3.2 評估在原型2中，ONOS對說網(wǎng)絡事件的延遲達到了預期的要求，但是吞吐量上還沒有達到1M path/sec的標準。不過開發(fā)者們將這個原因歸咎于僅使用了一個ONOS節(jié)點來計算路勁。四、 實例2014年3月，論文作者們將ONOS原型2部署在Internet2上運行展示，在大會上展示了（1

32、）ONOS的網(wǎng)絡視圖；（2）在真實WAN上操作；（3）使用虛擬化硬件和軟件交換機；（4）加速ONOS和鏈路故障轉(zhuǎn)移。圖5闡明了ONOS的系統(tǒng)配置：地理上分布5個硬件交換機的主干網(wǎng)絡，且每個交換機連接一個模擬的軟件交換機。并一個在物理架構上使用OVX（OpenVirteX）創(chuàng)建一個含有205個交換機和414條鏈路的虛擬網(wǎng)絡，并且在印度大學NOC實驗室有一個8節(jié)點的ONOS集群控制此虛擬網(wǎng)絡。圖5：Internet2拓撲和配置Demo圖6顯示ONOS發(fā)現(xiàn)的拓撲，與圖5對比，Los Angeles和Chicago 、 Chicago和Washington D.C之間顯示的鏈路是由OVX虛擬，如下圖顯

33、示：圖6：ONOS GUI顯示發(fā)現(xiàn)的交換機和鏈路拓撲五、 總結：開放分布式SDN操作系統(tǒng)建立了兩個版本ONOS原型，希望將分布式SDN控制平臺發(fā)展成為一個更完善的網(wǎng)絡操作系統(tǒng)滿足大型運營商網(wǎng)絡性能和可靠性需求。現(xiàn)在意欲開發(fā)多個原型案例幫助推進SDN的發(fā)展，其中包括系統(tǒng)APIs、抽象、資源隔離以及調(diào)度等。另外，將繼續(xù)致力于滿足性能需求以及開發(fā)有用的系統(tǒng)開源版本。后語：小編在翻譯總結的過程中，學習到了很多關于全局網(wǎng)絡視圖以及分布式管理的知識。ONOS應該是不錯的控制器產(chǎn)品，甚至于說是不錯的SDN 操作系統(tǒng)。ONOS應用了Titan和Cassandra技術保障了數(shù)據(jù)的完整性，添加了事件通知框架減少了

34、事件的延遲，使用Zookeeper檢測和反饋系統(tǒng)狀態(tài)，提高了容錯能力，采用的分布式框架使擴展能力得到延伸，應用最新的OVX虛擬化網(wǎng)絡，以及在性能調(diào)優(yōu)上做了更大的改變和進步，期待ONOS開源版本的發(fā)布使用！4、ONOS預熱篇之ONOS與OpenDaylight比較（四）目前以設備提供商為代表的OpenDaylight陣營目前發(fā)展勢頭正勁，而由斯坦福大學和加州大學伯克利分校SDN先驅(qū)創(chuàng)立的非營利性組織ON.Lab也緊鑼密鼓地推出了自己的開源SDN操作系統(tǒng)ONOS。此次打造的商業(yè)級的以用戶為導向的ONOS開放網(wǎng)絡操作系統(tǒng)是以服務提供商為首，并且得到了開放網(wǎng)絡基金會ONF的鼎力支持，意欲與OpenDa

35、ylight一決高下。具體的性能究竟孰好孰壞還需要等待發(fā)布之后的評測，下面小編就從不同的方面比較一下這兩個業(yè)界最知名的網(wǎng)絡操作系統(tǒng)。1. 驅(qū)動方式不同ONOS白皮書中寫道，一個操作系統(tǒng)應該具備下述功能：§ 為用戶管理有限的資源。§ 隔離和保護NOS用戶。需要操作系統(tǒng)能復用多個應用和多個設備。§ 提供一個可用的抽象層讓用戶靈活的使用操作系統(tǒng)所管理的服務和資源，并且無需了解網(wǎng)絡的復雜性。§ 為外部操作系統(tǒng)提供安全保障。§ 提供敏捷高效的服務，用戶不需要創(chuàng)建、重建相同的服務。這些都是網(wǎng)絡應用所需要的。通常控制器所控制的范圍十分局限，通常設置為控制一個

36、設備。ONOS具備一個操作系統(tǒng)所具備的所有功能，不僅僅是控制器的功能，例如可以提供高效敏捷的抽象層，能夠?qū)⒉煌目刂破魇褂谜吒綦x開來，能夠提供有價值的服務等等。ONOS是根據(jù)服務提供商的特點和需求進行軟件架構設計的。因此ONOS是需求驅(qū)動下的產(chǎn)物。相比而言，目前圍繞SDN炒作更多的是來自設備供應商。OpenDaylight是由思科和IBM 聯(lián)合其合作伙伴，以及競爭對手建立的組織。其初創(chuàng)成員包括：微軟、Big Switch（已退出）、博科、思科、思杰、戴爾、愛立信、富士通、IBM、英特爾、瞻博網(wǎng)絡、微軟、NEC、惠普、紅帽和VMware等。我們可以看到這些成員都是設備供應商，和ONF不同的是Op

37、enDaylight是由大廠商控制的并且削弱了用戶的聲音。并且它還可能會出于利益問題將部分功能同設備鎖定，這并不是SDN的初衷。我們所期望的便是看到所有參與其中的人能共同推動SDN的進步。2.面向?qū)ο蟛煌琌NOS和OpenDaylight代表的陣營不同，面向?qū)ο笠膊煌?。ONOS的設計理念是能在任何硬件（包括白牌機）上靈活的創(chuàng)建服務并且大規(guī)模部署，因其可靠性強，性能好，靈活度高的特點適用于面向服務提供商和企業(yè)骨干網(wǎng)。它不僅可以滿足運營商提供敏捷和靈活的需求，并且有可能使其擺脫設備供應商的束縛，因此很多運營商愿意接受ONOS。而最近發(fā)布的2.0版本的OpenDaylight以及來自其成員企業(yè)的支持給其帶來了新的發(fā)展勢頭，但是因其成員關系，其在很大層面上受設備商的制約。因此OpenDaylight是設備商在一定程度上為了維護自己陣營的利益的產(chǎn)物，其主要面向?qū)ο笠彩窃O備商。3.架構不同ONOS架構設計伊始就將服務提供商放在首位。下圖是ONOS架構圖：圖1：ONOS架構我們看到ONOS架構具體由應用層、北向核心接口層、分布是核心層、南向核心接口層、適配層、設備層六部分構成，其中南向核心接口層和適配層可以合起來