關於構建ONOS（開放式網絡操作系統）的項目專題，是通過性能激發創建的實驗性分佈式SDN控制平臺，滿足大型運營商網絡的可擴展性、可用性需求。提出了2個版本的ONOS原型，第一個原型版本實現的核心功能是實現一個分佈式的但在邏輯上集中的全局網絡視圖、可擴展性和容錯。另一個原型版本側重於提高性能，基於這兩個原型的實踐，已形成論文發表《ONOS: Towards an Open, Distributed SDN OS》，確定需要ONOS來支持使用案例，如核心網絡流量工程和調度，變成一個在可用的開源SDN社區構建分佈式網絡操作系統平臺。
一、 介紹
近年，學術界和產業界對SDN產生了極大的興趣。一個開放的、廠商中立的、控制數據平面分離的接口如OpenFlow，允許網絡硬件和軟件獨立發展，並促進了免費的開源的網絡操作系統的發展，來更換傳統的、價格昂貴的、專有的硬件和商用硬件。通過管理網絡資源和提供高層次的抽象和APIs，NOS提供一個開放的平臺，它簡化了創新有益網絡應用的創建並且服務於多種硬件網絡。
爲了支持大型網絡，NOS必須滿足可擴展性大、性能高、可用性強的需求。根據網絡運營商的討論，並考慮到服務提供商網絡中的流量工程使用，我已確定幾個極具挑戰性的需求，如圖1：
■高吞吐量，達到1M requests/s；
■低延遲，事件進程10-100ms；
■全局網絡狀態大小，數據量最高達到1TB；
■高可用性，99.99%的服務可用性。
爲了解決上述問題，已在實驗系統上運行開放網絡操作系統（Open Network Operating System，ONOS）。ONOS採用一個分佈式架構，可達到高可用性和高擴展性，爲應用程序提供一個全局的網絡視圖，即使物理上分佈在多服務器，邏輯上也可集中管控。ONOS作爲一個開源項目，主要通過下面兩個重要原型的開發逐漸發展演變：
（1）原型1在分佈式平臺上爲擴展性和容錯能力致力於全局網絡視圖；
（2）原型2致力於提高性能，尤其是爲事件延遲添加了一個事件通知框架，改變數據存儲和數據模型並添加緩存層。
二、 原型1：網絡視圖、擴展和容錯
ONOS最初的挑戰是創建一個有用的抽象層、全局網絡視圖、以及在一個系統上跨多個服務器運行在控制層面的擴展和容錯能力。使用開源構件建立的第一個原型是爲了快速驗證以及更深入探索設計的可能性。根據現有的開源SDN控制器Floodlight開發出第一個原型，使用了Floodlight的部分模塊，包括交換機管理、I/O迴環、鏈路發現、模塊管理和REST APIs。下圖顯示了原型1的系統架構：
圖2：原型1架構
2.1 全局網絡視圖
ONOS含有全局網絡視圖功能，在集羣中通過ONOS服務器管理和共享網絡狀態，並提供一個對應底層網絡結構的網絡視圖模型。在每個ONOS實例中發現的網絡拓撲和狀態，如交換機端口、鏈路和主機信息構成全局網絡視圖，並從全局網絡視圖中讀取應用程序確定轉發策略，然後將轉發策略依次寫到網絡視圖中，當視圖信息發生變化時，將變化消息發送到相應的OpenFlow控制器並下發到在指定的交換機上。初始的網絡視圖數據模型，採用Titan圖形數據庫實現、使用Cassandra鍵值存儲實現分佈式和可持續性，通過Blue-prints圖形API暴露網絡狀態給應用程序。由於Cassandra具有一致性存儲的特性，所以保障了網絡試圖的最終一致性。
2.2 可擴展性
ONOS的一個關鍵功能是其可擴展性和容錯能力的分佈式架構，ONOS運行在多個服務器上，每個作爲專屬的master OpenFlow控制器，管理網絡子集中的交換機。一個ONOS將獨立完成對網絡及交換機的控制並負責全局網絡視圖之間的狀態變化；當數據平面容量增長或者在控制平面需求增加時，附加的ONOS應用實例可以被添加到ONOS集羣中分發控制平面的工作負載，體現了良好的可擴展性。
2.3 容錯能力
在ONOS分佈式體系結構中，當一個組件或ONOS實例失敗時，有其他剩他實例的情況下，允許重新分配，保障系統仍能繼續工作。ONOS的架構允許在運行時組件存在於一個實例，但是提供多個冗餘的實例，接管之前的失敗實例來控制組件。在運行時通過在所有實例中選擇一個最優實例來代替初始實例。
一個交換機可以連接多個ONOS實例，但是對於每個交換機來說，只有一個主（master）實例控制。這個master實例獨自負責發現交換機信息和控制交換機，當一個ONOS主實例失敗時，剩餘的實例選擇一個新的master來控制交換機。與每個交換機一致性匹配度最高的ONOS實例被選擇運行最爲master，以確保在所有交換機中，被選擇的這個ONOS實例能夠負責每臺交換機。
用Zookeeper管理交換機和控制器之間的關係，包括監測和反饋ONOS實例是否失敗；同時，ONOS實例一定要與Zookeeper保持連接爲了成爲交換機的master控制器。如果一個ONOS實例與Zookeeper失去連接，另一個ONOS實例將負責控制此交換機。Zookeeper使用一個匹配的協議維持與ONOS很大的一致性，且只要大多數服務器可用，Zookeeper就有很強的容錯能力。
2.4 評估
第一個ONOS原型開發歷經4個月，在2013年4月在ONS（Open Networking Summit）大會上演示了ONOS原型1，這個演示顯示ONOS控制幾百個虛擬交換機、使用網絡視圖下發端到端的流、動態添加交換機和ONOS實例到集羣中、針對ONOS實例停機的故障轉移以及針對鏈路響應失敗重新添加路由等。總體來說，雖然已經實現了系統的基本功能，但是一些設計選擇導致性能和可用性並不好，主要表現是一下幾個方面：
■一致性和完整性。Titan在Cassandra上最終要保持數據存儲的一致性以及圖形架構的完整性，比如一條鏈路必須連接兩個節點；
■低性能和可見性。原型1延遲比預期差很多，主要原因在於使用開源軟件，雖然很快可以完成開發，但是這些開源軟件之間的協調，並不容易。而且ONOS的開發者並不是特別熟悉這些開源代碼，導致性能並不高；
■數據模型問題。使用Titan存儲導致所有數據如Port,flow entries等都需要以Vertices存儲，需要構建一個索引來查詢數據，如交換機數據。當大量節點加入網絡時，併發的數據量增加導致索引構建就會成爲瓶頸；
■過多的數據存儲操作。Titan和Cassandra間的數據轉換會產生過多數據存儲操作導致延遲；
■輪詢問題。通過週期同步數據，沒有實現訂閱分發，增加CPU的使用率。
通過模型1的測試及分析，需要設計更高效的數據模型，減少多餘的數據操作，實現訂閱分發機制以及簡化API等。
三、 原型2：性能提高
原型2主要集中關注於提高ONOS的性能，但是這個導致改變了網絡視圖架構並添加了事件通知架構，如下圖所示：
圖3：原型2架構
遠程數據操作是原型1最大的性能瓶頸之一，所以在原型2中主要通過儘可能快的遠程操作、減少ONOS遠程操作量這2種方法解決這個問題。主要涉及的優化主要有：
1.RAM雲數據存儲。使用內存來代替普通硬盤來存儲，從而大大提高存儲速度；
2.優化數據模型。新設計了一個data model，更新相對獨立，大大減少了數據的讀寫操作，優化了性能；
3.拓撲緩存。原型1讀取拓撲非常耗時，ONOS將拓撲信息存在高速緩存中，從而提高了讀取拓撲的速度。除此之外，通過構建索引更快速地查找數據。構建索引可以在任何時刻由全部的數據生成，但是一般情況下，只有新接入ONOS節點時，纔會讀取全部數據，這不會消耗太多時間；
4.事件通知。上文已提到由於週期獲取數據而引起的性能問題，所以引入事件通知機制。原型2創建實例內部的發佈-訂閱的事件機制，將這個通信系統部署在Hazelcast上；
5.網絡視圖API。ONOS用自己設計的API取代生成的Blueprints graph API。圖4展示了網絡視圖的內容，ONOS的API主要包涵下面的三個部分：
■對底層設施拓撲的抽象描述的接口；
■處理網絡或系統Events（事件）的接口；
■提供安裝流表等信息的接口。
圖4：使用流表創建數據包路徑的連通性請求網絡視圖
3.1 性能評估
原型2的性能主要在以下三個方面進行測試和評價：
■基礎網絡狀態改變；
■對網絡事件的反應；
■路徑部署；
3.1.1 基礎網絡狀態改變
當網絡中狀態發生改變，將進行數據更新操作，會阻塞ONOS的操作，將影響整個ONOS的性能。測試案例中使用三個節點的ONOS集羣，連接81個OpenFlow交換機，構成一個典型的WAN拓撲，且每個交換機上都有四個活躍的端口。
ONOS採用了對比的方式，表1展示添加一個交換機後需要的latency，結果可以看出，使用通用的API速度最慢；使用自定義的API，速度提高很多。因爲新的Data model僅需要一步就可以完成添加交換機操作，時間上從22.2ms降到1.19ms，延遲減少了很多。在序列化方面由原來的Kryo 嘗試使用Google Protocol Buffers，這使延遲時間下降了0.244ms。除此之外，在RAM雲集羣中還嘗試使用Infiniband硬件並優化網絡的I/O，性能數據得到了提高。
表1：添加一個交換機的延遲性能測試
3.1.2 對網絡事件的反應
對網絡事件的反應測試主要是針對ONOS對網絡事件的反應速度、端到端的延遲等性能，如網絡中某一條鏈路斷掉後，ONOS對流量重選路由的過程需要多長時間，這個性能直接關係到SLA（Service-Level Agreement）的性能。
實驗測試使用了6個節點的ONOS集羣，數據層面使用Mininet模擬206個交換機和416條鏈路。將16000條flows添加到網絡中，然後關掉交換機的其中一個端口，結果分析顯示1000多條flows重新選擇路由，其中每一條流有6跳，當某一端口關掉之後，重新選擇路由，每一條流將變成7跳。
表2顯示重選路由進度進行到一半和99%的數據，從網絡時間上捕捉到下發第一條flow_mod及全部flow_mod下發的延遲時間。
表2：重選1000條流的路由延遲時間
3.1.3 路徑部署
第三個性能指標測試ONOS系統的吞吐量，測試使用了與對網絡事件的反應測試相同的拓撲，但是預先下發15000條靜態流表，添加1000條6跳的flows。表3測試結果顯示的是路徑部署的延遲時間，吞吐量與延遲成反比，在所有流進程進行到一半時吞吐量爲18832paths/sec
表3：路徑部署延遲時間
3.2 評估
在原型2中，ONOS對說網絡事件的延遲達到了預期的要求，但是吞吐量上還沒有達到1M path/sec的標準。不過開發者們將這個原因歸咎於僅使用了一個ONOS節點來計算路勁。
四、 實例
2014年3月，論文作者們將ONOS原型2部署在Internet2上運行展示，在大會上展示了（1）ONOS的網絡視圖；（2）在真實WAN上操作；（3）使用虛擬化硬件和軟件交換機；（4）加速ONOS和鏈路故障轉移。圖5闡明瞭ONOS的系統配置：地理上分佈5個硬件交換機的主幹網絡，且每個交換機連接一個模擬的軟件交換機。並一個在物理架構上使用OVX（OpenVirteX）創建一個含有205個交換機和414條鏈路的虛擬網絡，並且在印度大學NOC實驗室有一個8節點的ONOS集羣控制此虛擬網絡。
圖5：Internet2拓撲和配置Demo
圖6顯示ONOS發現的拓撲，與圖5對比，Los Angeles和Chicago 、 Chicago和Washington D.C之間顯示的鏈路是由OVX虛擬，如下圖顯示：
圖6：ONOS GUI顯示發現的交換機和鏈路拓撲
五、 總結：開放分佈式SDN操作系統
建立了兩個版本ONOS原型，希望將分佈式SDN控制平臺發展成爲一個更完善的網絡操作系統滿足大型運營商網絡性能和可靠性需求。現在意欲開發多個原型案例幫助推進SDN的發展，其中包括系統APIs、抽象、資源隔離以及調度等。另外，將繼續致力於滿足性能需求以及開發有用的系統開源版本。
後語：小編在翻譯總結的過程中，學習到了很多關於全局網絡視圖以及分佈式管理的知識。ONOS應該是不錯的控制器產品，甚至於說是不錯的SDN 操作系統。ONOS應用了Titan和Cassandra技術保障了數據的完整性，添加了事件通知框架減少了事件的延遲，使用Zookeeper檢測和反饋系統狀態，提高了容錯能力，採用的分佈式框架使擴展能力得到延伸，應用最新的OVX虛擬化網絡，以及在性能調優上做了更大的改變和進步，期待ONOS開源版本的發佈使用！