為什么80%的碼農(nóng)都做不了架構(gòu)師？>>> ??

? ? 關(guān)于構(gòu)建ONOS（開放式網(wǎng)絡(luò)操作系統(tǒng)）的項目專題，是通過性能激發(fā)創(chuàng)建的實驗性分布式SDN控制平臺，滿足大型運營商網(wǎng)絡(luò)的可擴展性、可用性需求。提出了2個版本的ONOS原型，第一個原型版本實現(xiàn)的核心功能是實現(xiàn)一個分布式的但在邏輯上集中的全局網(wǎng)絡(luò)視圖、可擴展性和容錯。另一個原型版本側(cè)重于提高性能，基于這兩個原型的實踐，已形成論文發(fā)表《ONOS:?Towards?an?Open,?Distributed?SDN?OS》，確定需要ONOS來支持使用案例，如核心網(wǎng)絡(luò)流量工程和調(diào)度，變成一個在可用的開源SDN社區(qū)構(gòu)建分布式網(wǎng)絡(luò)操作系統(tǒng)平臺。

一、?介紹

近年，學(xué)術(shù)界和產(chǎn)業(yè)界對SDN產(chǎn)生了極大的興趣。一個開放的、廠商中立的、控制數(shù)據(jù)平面分離的接口如OpenFlow，允許網(wǎng)絡(luò)硬件和軟件獨立發(fā)展，并促進了免費的開源的網(wǎng)絡(luò)操作系統(tǒng)的發(fā)展，來更換傳統(tǒng)的、價格昂貴的、專有的硬件和商用硬件。通過管理網(wǎng)絡(luò)資源和提供高層次的抽象和APIs，NOS提供一個開放的平臺，它簡化了創(chuàng)新有益網(wǎng)絡(luò)應(yīng)用的創(chuàng)建并且服務(wù)于多種硬件網(wǎng)絡(luò)。

為了支持大型網(wǎng)絡(luò)，NOS必須滿足可擴展性大、性能高、可用性強的需求。根據(jù)網(wǎng)絡(luò)運營商的討論，并考慮到服務(wù)提供商網(wǎng)絡(luò)中的流量工程使用，我已確定幾個極具挑戰(zhàn)性的需求，如圖1：

■高吞吐量，達到1M?requests/s；

?■低延遲，事件進程10-100ms；

?■全局網(wǎng)絡(luò)狀態(tài)大小，數(shù)據(jù)量最高達到1TB；

?■高可用性，99.99%的服務(wù)可用性。

為了解決上述問題，已在實驗系統(tǒng)上運行開放網(wǎng)絡(luò)操作系統(tǒng)（Open?Network?Operating?System，ONOS）。ONOS采用一個分布式架構(gòu)，可達到高可用性和高擴展性，為應(yīng)用程序提供一個全局的網(wǎng)絡(luò)視圖，即使物理上分布在多服務(wù)器，邏輯上也可集中管控。ONOS作為一個開源項目，主要通過下面兩個重要原型的開發(fā)逐漸發(fā)展演變：

?（1）原型1在分布式平臺上為擴展性和容錯能力致力于全局網(wǎng)絡(luò)視圖；

?（2）原型2致力于提高性能，尤其是為事件延遲添加了一個事件通知框架，改變數(shù)據(jù)存儲和數(shù)據(jù)模型并添加緩存層。

二、?原型1：網(wǎng)絡(luò)視圖、擴展和容錯

ONOS最初的挑戰(zhàn)是創(chuàng)建一個有用的抽象層、全局網(wǎng)絡(luò)視圖、以及在一個系統(tǒng)上跨多個服務(wù)器運行在控制層面的擴展和容錯能力。使用開源構(gòu)件建立的第一個原型是為了快速驗證以及更深入探索設(shè)計的可能性。根據(jù)現(xiàn)有的開源SDN控制器Floodlight開發(fā)出第一個原型，使用了Floodlight的部分模塊，包括交換機管理、I/O回環(huán)、鏈路發(fā)現(xiàn)、模塊管理和REST?APIs。下圖顯示了原型1的系統(tǒng)架構(gòu)：

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?圖2：原型1架構(gòu)

?

2.1?全局網(wǎng)絡(luò)視圖

ONOS含有全局網(wǎng)絡(luò)視圖功能，在集群中通過ONOS服務(wù)器管理和共享網(wǎng)絡(luò)狀態(tài)，并提供一個對應(yīng)底層網(wǎng)絡(luò)結(jié)構(gòu)的網(wǎng)絡(luò)視圖模型。在每個ONOS實例中發(fā)現(xiàn)的網(wǎng)絡(luò)拓撲和狀態(tài)，如交換機端口、鏈路和主機信息構(gòu)成全局網(wǎng)絡(luò)視圖，并從全局網(wǎng)絡(luò)視圖中讀取應(yīng)用程序確定轉(zhuǎn)發(fā)策略，然后將轉(zhuǎn)發(fā)策略依次寫到網(wǎng)絡(luò)視圖中，當(dāng)視圖信息發(fā)生變化時，將變化消息發(fā)送到相應(yīng)的OpenFlow控制器并下發(fā)到在指定的交換機上。初始的網(wǎng)絡(luò)視圖數(shù)據(jù)模型，采用Titan圖形數(shù)據(jù)庫實現(xiàn)、使用Cassandra鍵值存儲實現(xiàn)分布式和可持續(xù)性，通過Blue-prints圖形API暴露網(wǎng)絡(luò)狀態(tài)給應(yīng)用程序。由于Cassandra具有一致性存儲的特性，所以保障了網(wǎng)絡(luò)試圖的最終一致性。

2.2?可擴展性

ONOS的一個關(guān)鍵功能是其可擴展性和容錯能力的分布式架構(gòu)，ONOS運行在多個服務(wù)器上，每個作為專屬的master?OpenFlow控制器，管理網(wǎng)絡(luò)子集中的交換機。一個ONOS將獨立完成對網(wǎng)絡(luò)及交換機的控制并負責(zé)全局網(wǎng)絡(luò)視圖之間的狀態(tài)變化；當(dāng)數(shù)據(jù)平面容量增長或者在控制平面需求增加時，附加的ONOS應(yīng)用實例可以被添加到ONOS集群中分發(fā)控制平面的工作負載，體現(xiàn)了良好的可擴展性。

2.3?容錯能力

在ONOS分布式體系結(jié)構(gòu)中，當(dāng)一個組件或ONOS實例失敗時，有其他剩他實例的情況下，允許重新分配，保障系統(tǒng)仍能繼續(xù)工作。ONOS的架構(gòu)允許在運行時組件存在于一個實例，但是提供多個冗余的實例，接管之前的失敗實例來控制組件。在運行時通過在所有實例中選擇一個最優(yōu)實例來代替初始實例。

一個交換機可以連接多個ONOS實例，但是對于每個交換機來說，只有一個主（master）實例控制。這個master實例獨自負責(zé)發(fā)現(xiàn)交換機信息和控制交換機，當(dāng)一個ONOS主實例失敗時，剩余的實例選擇一個新的master來控制交換機。與每個交換機一致性匹配度最高的ONOS實例被選擇運行最為master，以確保在所有交換機中，被選擇的這個ONOS實例能夠負責(zé)每臺交換機。

用Zookeeper管理交換機和控制器之間的關(guān)系，包括監(jiān)測和反饋ONOS實例是否失敗；同時，ONOS實例一定要與Zookeeper保持連接為了成為交換機的master控制器。如果一個ONOS實例與Zookeeper失去連接，另一個ONOS實例將負責(zé)控制此交換機。Zookeeper使用一個匹配的協(xié)議維持與ONOS很大的一致性，且只要大多數(shù)服務(wù)器可用，Zookeeper就有很強的容錯能力。

2.4?評估

第一個ONOS原型開發(fā)歷經(jīng)4個月，在2013年4月在ONS（Open?Networking?Summit）大會上演示了ONOS原型1，這個演示顯示ONOS控制幾百個虛擬交換機、使用網(wǎng)絡(luò)視圖下發(fā)端到端的流、動態(tài)添加交換機和ONOS實例到集群中、針對ONOS實例停機的故障轉(zhuǎn)移以及針對鏈路響應(yīng)失敗重新添加路由等。總體來說，雖然已經(jīng)實現(xiàn)了系統(tǒng)的基本功能，但是一些設(shè)計選擇導(dǎo)致性能和可用性并不好，主要表現(xiàn)是一下幾個方面：

?■一致性和完整性。Titan在Cassandra上最終要保持數(shù)據(jù)存儲的一致性以及圖形架構(gòu)的完整性，比如一條鏈路必須連接兩個節(jié)點；

?■低性能和可見性。原型1延遲比預(yù)期差很多，主要原因在于使用開源軟件，雖然很快可以完成開發(fā)，但是這些開源軟件之間的協(xié)調(diào)，并不容易。而且ONOS的開發(fā)者并不是特別熟悉這些開源代碼，導(dǎo)致性能并不高；

?■數(shù)據(jù)模型問題。使用Titan存儲導(dǎo)致所有數(shù)據(jù)如Port,flow?entries等都需要以Vertices存儲，需要構(gòu)建一個索引來查詢數(shù)據(jù)，如交換機數(shù)據(jù)。當(dāng)大量節(jié)點加入網(wǎng)絡(luò)時，并發(fā)的數(shù)據(jù)量增加導(dǎo)致索引構(gòu)建就會成為瓶頸；

?■過多的數(shù)據(jù)存儲操作。Titan和Cassandra間的數(shù)據(jù)轉(zhuǎn)換會產(chǎn)生過多數(shù)據(jù)存儲操作導(dǎo)致延遲；

?■輪詢問題。通過周期同步數(shù)據(jù)，沒有實現(xiàn)訂閱分發(fā)，增加CPU的使用率。

通過模型1的測試及分析，需要設(shè)計更高效的數(shù)據(jù)模型，減少多余的數(shù)據(jù)操作，實現(xiàn)訂閱分發(fā)機制以及簡化API等。

三、?原型2：性能提高

原型2主要集中關(guān)注于提高ONOS的性能，但是這個導(dǎo)致改變了網(wǎng)絡(luò)視圖架構(gòu)并添加了事件通知架構(gòu)，如下圖所示：

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?圖3：原型2架構(gòu)

遠程數(shù)據(jù)操作是原型1最大的性能瓶頸之一，所以在原型2中主要通過盡可能快的遠程操作、減少ONOS遠程操作量這2種方法解決這個問題。主要涉及的優(yōu)化主要有：

1.RAM云數(shù)據(jù)存儲。使用內(nèi)存來代替普通硬盤來存儲，從而大大提高存儲速度；

2.優(yōu)化數(shù)據(jù)模型。新設(shè)計了一個data?model，更新相對獨立，大大減少了數(shù)據(jù)的讀寫操作，優(yōu)化了性能；

3.拓撲緩存。原型1讀取拓撲非常耗時，ONOS將拓撲信息存在高速緩存中，從而提高了讀取拓撲的速度。除此之外，通過構(gòu)建索引更快速地查找數(shù)據(jù)。構(gòu)建索引可以在任何時刻由全部的數(shù)據(jù)生成，但是一般情況下，只有新接入ONOS節(jié)點時，才會讀取全部數(shù)據(jù)，這不會消耗太多時間；

4.事件通知。上文已提到由于周期獲取數(shù)據(jù)而引起的性能問題，所以引入事件通知機制。原型2創(chuàng)建實例內(nèi)部的發(fā)布-訂閱的事件機制，將這個通信系統(tǒng)部署在Hazelcast上；

5.網(wǎng)絡(luò)視圖API。ONOS用自己設(shè)計的API取代生成的Blueprints?graph?API。圖4展示了網(wǎng)絡(luò)視圖的內(nèi)容，ONOS的API主要包涵下面的三個部分：

?■對底層設(shè)施拓撲的抽象描述的接口；

?■處理網(wǎng)絡(luò)或系統(tǒng)Events（事件）的接口；

?■提供安裝流表等信息的接口。

? ? ? ? ? ? ? ? ? ? ? ? ?圖4：使用流表創(chuàng)建數(shù)據(jù)包路徑的連通性請求網(wǎng)絡(luò)視圖

?

3.1?性能評估

原型2的性能主要在以下三個方面進行測試和評價：

?■基礎(chǔ)網(wǎng)絡(luò)狀態(tài)改變；

?■對網(wǎng)絡(luò)事件的反應(yīng)；

?■路徑部署；

3.1.1?基礎(chǔ)網(wǎng)絡(luò)狀態(tài)改變

當(dāng)網(wǎng)絡(luò)中狀態(tài)發(fā)生改變，將進行數(shù)據(jù)更新操作，會阻塞ONOS的操作，將影響整個ONOS的性能。測試案例中使用三個節(jié)點的ONOS集群，連接81個OpenFlow交換機，構(gòu)成一個典型的WAN拓撲，且每個交換機上都有四個活躍的端口。

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

? ? ? ? ? ? ? ? ? ? ? ? 表1：添加一個交換機的延遲性能測試

3.1.2?對網(wǎng)絡(luò)事件的反應(yīng)

對網(wǎng)絡(luò)事件的反應(yīng)測試主要是針對ONOS對網(wǎng)絡(luò)事件的反應(yīng)速度、端到端的延遲等性能，如網(wǎng)絡(luò)中某一條鏈路斷掉后，ONOS對流量重選路由的過程需要多長時間，這個性能直接關(guān)系到SLA（Service-Level?Agreement）的性能。

實驗測試使用了6個節(jié)點的ONOS集群，數(shù)據(jù)層面使用Mininet模擬206個交換機和416條鏈路。將16000條flows添加到網(wǎng)絡(luò)中，然后關(guān)掉交換機的其中一個端口，結(jié)果分析顯示1000多條flows重新選擇路由，其中每一條流有6跳，當(dāng)某一端口關(guān)掉之后，重新選擇路由，每一條流將變成7跳。

表2顯示重選路由進度進行到一半和99%的數(shù)據(jù)，從網(wǎng)絡(luò)時間上捕捉到下發(fā)第一條flow_mod及全部flow_mod下發(fā)的延遲時間。

? ? ? ? ? ? ? ? ? ? ? ? ?表2：重選1000條流的路由延遲時間

3.1.3?路徑部署

第三個性能指標測試ONOS系統(tǒng)的吞吐量，測試使用了與對網(wǎng)絡(luò)事件的反應(yīng)測試相同的拓撲，但是預(yù)先下發(fā)15000條靜態(tài)流表，添加1000條6跳的flows。表3測試結(jié)果顯示的是路徑部署的延遲時間，吞吐量與延遲成反比，在所有流進程進行到一半時吞吐量為18832paths/sec。

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 表3：路徑部署延遲時間

3.2?評估

在原型2中，ONOS對說網(wǎng)絡(luò)事件的延遲達到了預(yù)期的要求，但是吞吐量上還沒有達到1M?path/sec的標準。不過開發(fā)者們將這個原因歸咎于僅使用了一個ONOS節(jié)點來計算路勁。

四、?實例

2014年3月，論文作者們將ONOS原型2部署在Internet2上運行展示，在大會上展示了（1）ONOS的網(wǎng)絡(luò)視圖；（2）在真實WAN上操作；（3）使用虛擬化硬件和軟件交換機；（4）加速ONOS和鏈路故障轉(zhuǎn)移。圖5闡明了ONOS的系統(tǒng)配置：地理上分布5個硬件交換機的主干網(wǎng)絡(luò)，且每個交換機連接一個模擬的軟件交換機。并一個在物理架構(gòu)上使用OVX（OpenVirteX）創(chuàng)建一個含有205個交換機和414條鏈路的虛擬網(wǎng)絡(luò)，并且在印度大學(xué)NOC實驗室有一個8節(jié)點的ONOS集群控制此虛擬網(wǎng)絡(luò)。

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 圖5：Internet2拓撲和配置Demo

圖6顯示ONOS發(fā)現(xiàn)的拓撲，與圖5對比，Los?Angeles和Chicago?、?Chicago和Washington?D.C之間顯示的鏈路是由OVX虛擬，如下圖顯示：

? ? ? ? ? ? ? ? ? ? ? ? ? ?圖6：ONOS?GUI顯示發(fā)現(xiàn)的交換機和鏈路拓撲

?

五、?總結(jié)：開放分布式SDN操作系統(tǒng)

建立了兩個版本ONOS原型，希望將分布式SDN控制平臺發(fā)展成為一個更完善的網(wǎng)絡(luò)操作系統(tǒng)滿足大型運營商網(wǎng)絡(luò)性能和可靠性需求。現(xiàn)在意欲開發(fā)多個原型案例幫助推進SDN的發(fā)展，其中包括系統(tǒng)APIs、抽象、資源隔離以及調(diào)度等。另外，將繼續(xù)致力于滿足性能需求以及開發(fā)有用的系統(tǒng)開源版本。

后語：小編在翻譯總結(jié)的過程中，學(xué)習(xí)到了很多關(guān)于全局網(wǎng)絡(luò)視圖以及分布式管理的知識。ONOS應(yīng)該是不錯的控制器產(chǎn)品，甚至于說是不錯的SDN?操作系統(tǒng)。ONOS應(yīng)用了Titan和Cassandra技術(shù)保障了數(shù)據(jù)的完整性，添加了事件通知框架減少了事件的延遲，使用Zookeeper檢測和反饋系統(tǒng)狀態(tài)，提高了容錯能力，采用的分布式框架使擴展能力得到延伸，應(yīng)用最新的OVX虛擬化網(wǎng)絡(luò)，以及在性能調(diào)優(yōu)上做了更大的改變和進步，期待ONOS開源版本的發(fā)布使用！

本文來源于SDNLAB，可點擊此閱讀原文。如果您對本文感興趣，可參與以下互動方式與作者近距離交流。

（1）?微博（http://weibo.com/sdnlab/）

（2）?微信(賬號：SDNLAB)

（3）?QQ群

SDN研究群（214146842）

OpenDaylight研究群（194240432）

?

轉(zhuǎn)載于:https://my.oschina.net/sdnlab/blog/357976

總結(jié)

以上是生活随笔為你收集整理的ONOS之开放分布式SDN操作系统的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。