目標(biāo)

ONOS是一個(gè)網(wǎng)絡(luò)控制器。applications通過(guò)intent APIs與ONOS進(jìn)行交互。ONOS通過(guò)其南向適配層控制數(shù)據(jù)網(wǎng)絡(luò)的轉(zhuǎn)發(fā)（例如，openflow網(wǎng)絡(luò)）。ONOS控制層與數(shù)據(jù)轉(zhuǎn)發(fā)層之間是ONOS流 子系統(tǒng)，ONOS流子系統(tǒng)是將application intens轉(zhuǎn)換為openflow流規(guī)則的重要組成部分。ONOS也是一個(gè)分布式系統(tǒng)，至關(guān)重要的是ONOS分布式架構(gòu)使其性能隨著集群數(shù)量增加而提 高。這份評(píng)估報(bào)告將ONOS看作一個(gè)整體的集群系統(tǒng)，計(jì)劃從應(yīng)用和操作環(huán)境兩個(gè)角度去評(píng)估ONOS性能。

我們?cè)O(shè)計(jì)了一系列的實(shí)驗(yàn)，測(cè)試在各種應(yīng)用和網(wǎng)絡(luò)環(huán)境下ONOS的延遲和吞吐量。并通過(guò)分析結(jié)果，我們希望提供給網(wǎng)絡(luò)運(yùn)營(yíng)商和應(yīng)用開(kāi)發(fā)商***手資料去了解ONOS的性能。此外，實(shí)驗(yàn)的結(jié)果將有助于開(kāi)發(fā)人員發(fā)現(xiàn)性能瓶頸并優(yōu)化。
下圖把ONOS分布式系統(tǒng)作為一個(gè)整體，介紹了關(guān)鍵的測(cè)試點(diǎn)。

[[133226]]

圖中包括如下性能測(cè)試點(diǎn):

延遲：

• A -交換機(jī) 連接/斷開(kāi);
• B -link啟用/斷開(kāi);
• C -intent的批量安裝/刪除/路徑切換;

吞吐量：

• D -intent操作;
• E -link事件(測(cè)試暫緩);
• F –迸發(fā)流規(guī)則安裝。

通用實(shí)驗(yàn)設(shè)置

集群規(guī)模性能測(cè)試：

ONOS最突出的特點(diǎn)是其分布式架構(gòu)。因此，ONOS性能測(cè)試的一個(gè)關(guān)鍵方面是比較和分析不同集群大小下ONOS的性能。所有的測(cè)試用例將以O(shè)NOS集群節(jié)點(diǎn)數(shù)量為1,3,5,7展開(kāi)。

測(cè)試工具

為了展示ONOS的本質(zhì)特征，使測(cè)試不受測(cè)試儀器的瓶頸限制，我們采用了一些比較實(shí)用的工具進(jìn)行實(shí)驗(yàn)。所有實(shí)驗(yàn)，除了與Openflow協(xié)議交互的 交換機(jī)和端口及其它相關(guān)的，我們?cè)贠NOS的適配層部署了一套Null Providers與ONOS core進(jìn)行交互。Null Providers擔(dān)任著生成device,link,host以及大量的流規(guī)則的角色。通過(guò)使用Null Providers,我們可以避免并消除Openflow適配和使用真實(shí)設(shè)備或者模擬的Openflow設(shè)備所存在的潛在的性能瓶頸。

同時(shí)，我們也部署了一些負(fù)載生成器，這樣可以使應(yīng)用或者網(wǎng)絡(luò)接口生成高強(qiáng)度的負(fù)載去觸及ONOS的性能極限。

這些生成器包括：

1.Intent performance 生成器“onos-app-intent-perf”，它與intent API交互,生成intent安裝/刪除操作，并根據(jù)ONOS可承受的***速度自我調(diào)節(jié)生成的Intent操作的負(fù)載。

2.流規(guī)則安裝Python腳本工具與ONOS flow subsystem交互去安裝和刪除subsystem中的流規(guī)則。

3.Null LinkProvider中的link 事件（閃爍）生成器，可以迅速提升發(fā)送速度到ONOS所能承受的極限并依此速率發(fā)送link up/down信息給ONOS core。

4.此外，我們?cè)?quot;topology-events-metrics" 和"intents-events-metrics" 應(yīng)用中利用計(jì)數(shù)器去獲取關(guān)鍵事件的時(shí)間戳與處理速率來(lái)方便那些時(shí)間及速度相關(guān)的測(cè)試。

我們將在后續(xù)的每個(gè)不同的測(cè)試過(guò)程中詳細(xì)介紹這些生成器的配置。

測(cè)試環(huán)境配置

A 7臺(tái) 集群實(shí)驗(yàn)所需要的裸服務(wù)器。每個(gè)服務(wù)器的規(guī)格如下：

• 雙Intel Xeon E5-2670v2處理器為2.5GHz - 10核心/20超線程內(nèi)核
• 32GB1600MHz的DDR3 DRAM
• 1Gbps的網(wǎng)絡(luò)接口卡
• Ubuntu的14.04 OS
• 集群之間使用ptpd同步

ONOS軟件環(huán)境

• Java HotSpot(TM) （TM）64-Bit server VM; version 1.8.0_31
• JAVA_OPTS=“${JAVA_OPTS： - Xms8G-Xmx8G}”
• onos-1.1.0 snapshot:
• a31e13471ee626abce2bc43c413fab17586f4fc3
• 其他的具體與用例相關(guān)的ONOS參數(shù)將在具體的用例中進(jìn)行說(shuō)明

下面將具體介紹每個(gè)用例的細(xì)節(jié)配置，測(cè)試結(jié)果討論及分析。

實(shí)驗(yàn)A＆B - 拓?fù)洌⊿witch,Link）發(fā)現(xiàn)時(shí)延測(cè)試

目標(biāo)

本實(shí)驗(yàn)是測(cè)試ONOS控制器在不同規(guī)模的集群環(huán)境中是如何響應(yīng)拓?fù)涫录?，測(cè)試拓?fù)涫录念愋桶ǎ?/p>

1）交換機(jī)連接或斷開(kāi)ONOS節(jié)點(diǎn)

2）在現(xiàn)有拓?fù)渲墟溌返膗p和down

ONOS作為一個(gè)分布式的系統(tǒng)架構(gòu)，多節(jié)點(diǎn)集群相比于獨(dú)立節(jié)點(diǎn)可能會(huì)發(fā)生額外的同步拓?fù)涫录难舆t。除了限制獨(dú)立模式下的延遲時(shí)間，也要減少由于onos集群間由于EW-wise通信事件產(chǎn)生額外延時(shí)。

配置和方法—交換機(jī)連接/斷開(kāi)的延遲

下面的圖表說(shuō)明了測(cè)試設(shè)置。一個(gè)交換機(jī)連接事件，是在一個(gè)“floating”（即沒(méi)有交換機(jī)端口和鏈路）的OVS（OF1.3）上通過(guò)“set- controller”命令設(shè)置OVS橋連接到onos1控制器。我們?cè)贠F控制層面網(wǎng)絡(luò)上使用tshark工具捕捉交換機(jī)上線的時(shí)間戳，ONOS Device和Graph使用“topology-event-metrics”應(yīng)用記錄時(shí)間戳。通過(guò)整理核對(duì)這些時(shí)間戳，我們得出從最初的事件觸發(fā)到 ONOS在其拓?fù)渲杏涗洿耸录?ldquo;端到端”的時(shí)序曲線。

[[133227]]

所需得到的幾個(gè)關(guān)鍵時(shí)間戳如下：

1.設(shè)備啟動(dòng)連接時(shí)間點(diǎn)t0，tcp syn/ ack；

2.OpenFlow協(xié)議的交換：

• t0 -> ONOS Features Reply；
• OVS Features Reply -> ONOS Role Request; (ONOS 在這里處理選擇主備控制器)；
• ONOS Role Request -> OVS Role Reply –OF協(xié)議的初始交換完成。

3.ONOS core處理事件的過(guò)程：

• OF協(xié)議交換完成后觸發(fā)Device Event；
• 本地節(jié)點(diǎn)的Device Event觸發(fā)Topology (Graph) Event。

同樣的，測(cè)試交換機(jī)斷開(kāi)事件，我們使用ovs命令“del-controller”斷開(kāi)交換機(jī)與它連接的ONOS節(jié)點(diǎn)，捕獲的時(shí)間戳如下：

1.OVS tcp syn/fin (t0);

2.OVS tcp fin;

3.ONOS Device Event;

4.ONOS Graph Event (t1).

交換機(jī)斷開(kāi)端到端的延遲為（T1 - T0）

當(dāng)我們?cè)龃驩NOS集群的大小，我們只連接和斷開(kāi)ONOS1上的交換機(jī)，并記錄所有節(jié)點(diǎn)上的事件時(shí)間戳。集群的整體延遲是Graph Event報(bào)告中最遲的節(jié)點(diǎn)的延時(shí)時(shí)間。在我們的測(cè)試腳本中，我們一次測(cè)試運(yùn)行多個(gè)迭代（例如，20次迭代）來(lái)收集統(tǒng)計(jì)結(jié)果。

設(shè)置和方法—鏈路up/down的延遲

測(cè)試一條鏈接up / down事件的延遲，除了我們用兩個(gè)OVS交換機(jī)創(chuàng)建鏈路（我們使用mininet創(chuàng)建一個(gè)簡(jiǎn)單的兩個(gè)交換機(jī)的線性拓?fù)浣Y(jié)構(gòu)）外，我們使用了與交換機(jī)連接 測(cè)試的類似方法。這兩個(gè)交換機(jī)的主控權(quán)屬于ONOS1。參照下面的圖表。初步建立交換機(jī)-控制器連接后，設(shè)置一個(gè)交換機(jī)的接口up或down，我們通過(guò)端 口up或down事件來(lái)觸發(fā)此測(cè)試。

一些關(guān)鍵的時(shí)間戳記錄，如下所述：

1. 交換機(jī)端口up/down, t0；

2. OVS向ONOS1發(fā)送OF PortStatus Update消息；

2a.在端口up的情況下，ONOS通過(guò)給每個(gè)OVS交換機(jī)發(fā)送鏈路發(fā)現(xiàn)消息來(lái)產(chǎn)生鏈路發(fā)現(xiàn)事件，同時(shí)ONOS收到其他交換機(jī)發(fā)送的Openflow PacketIn消息。

3.ONOS core處理事件過(guò)程：

由OF port status消息引起的Device事件; （ONOS處理）

鏈路down時(shí)，Link Event由Device Event觸發(fā)在本地節(jié)點(diǎn)產(chǎn)生，鏈路up時(shí)，Link Event是在鏈路發(fā)現(xiàn)PacketIn/out完成后產(chǎn)生的；（主要時(shí)間都是在OFP消息和ONOS處理上）

本地節(jié)點(diǎn)生成Graph Event。（ONOS處理）

類似于交換機(jī)的連接測(cè)試，我們認(rèn)為在Graph Event中登記的集群中最遲的節(jié)點(diǎn)的延時(shí)時(shí)間為集群的延遲。

[[133228]]

結(jié)果

Switch-add Event:

[[133229]] 

[[133230]]

Link Up/Down Event：

[[133231]] 

[[133232]]

分析和總結(jié)

Switch Connect/Disconnect Event：

當(dāng)一個(gè)交換機(jī)連接到ONOS時(shí)，明顯的時(shí)延劃分為以下幾個(gè)部分：

1.鏈路發(fā)現(xiàn)的中時(shí)延最長(zhǎng)的部分，是從最初的tcp連接到ONOS收到Openflow features-replay消息。進(jìn)一步分析數(shù)據(jù)包（在結(jié)果圖中未示出），我們可以看到大部分時(shí)間是花在初始化控制器與交換機(jī)的OpenFlow握手 階段，ONOS等待OVS交換機(jī)響應(yīng)它的features_request。而這個(gè)時(shí)延很大程度上不是由ONOS的處理引起的。

2.其次是在"OFP feature reply -> OFP role request"部分，這部分時(shí)延也會(huì)隨著ONOS集群規(guī)模增加而增加，其主要花費(fèi)在ONOS給新上線的交換機(jī)選擇主控權(quán)上，這是由于單節(jié)點(diǎn)的ONOS只 需在本地處理，而多節(jié)點(diǎn)的集群環(huán)境中，集群節(jié)點(diǎn)之間的通信將會(huì)帶來(lái)這個(gè)額外的延時(shí)

3.接著便是從OpenFlow握手完成(OFP role reply)到ONOS登記一個(gè)Device Event的過(guò)程中消耗的時(shí)延。這部分的時(shí)延也受多節(jié)點(diǎn)ONOS配置影響，因?yàn)榇耸录枰狾NOS將其寫入Device Store。
4.***一個(gè)延時(shí)比較長(zhǎng)的是ONOS在本地處理來(lái)著Device store的Device event到向Graph中注冊(cè)拓?fù)湫畔⑹录牟糠帧?/p>

斷開(kāi)交換機(jī)時(shí)，隨著ONOS集群規(guī)模的增大ONOS觸發(fā)Device事件的時(shí)延將略有增加。

總之，在OpenFlow消息交換期間，OVS對(duì)feature-request的響應(yīng)時(shí)延占據(jù)了交換機(jī)建立連接事件中，整體時(shí)延的絕大部分。接 著，ONOS花費(fèi)約9毫秒處理主控權(quán)選。***，ONOS在多節(jié)點(diǎn)集群環(huán)境下，由于各節(jié)點(diǎn)之間需要通信選舉主節(jié)點(diǎn)，交換機(jī)上/下線時(shí)延將都會(huì)增加。

Link Up/Down Events:

此次測(cè)試，我們首先觀察到的是，鏈路up事件比鏈路down事件花費(fèi)更長(zhǎng)的時(shí)間。通過(guò)時(shí)延分析，我們可以看到OVS的端口up事件觸發(fā)了ONOS特 殊的行為鏈路發(fā)現(xiàn)，因此，絕大多數(shù)時(shí)延主要由處理鏈路發(fā)現(xiàn)事件引起。與單節(jié)點(diǎn)的ONOS相比這部分時(shí)延受集群節(jié)點(diǎn)的影響也比較大。另外，大多數(shù)ONOS core花費(fèi)在向Graph登記拓?fù)涫录系臅r(shí)延在個(gè)位數(shù)的ms級(jí)別。

在大部分的網(wǎng)絡(luò)操作情況下，雖然整體拓?fù)涫录牡脱舆t是可以被容忍的，但是交換機(jī)/鏈路斷開(kāi)事件卻至關(guān)重要，因?yàn)樗鼈儽桓嗟目醋魇?applications的adverse events。當(dāng)ONOS能更快速的檢測(cè)到link down/up事件時(shí)，pplications也就能更快速的響應(yīng)此adverse events，我們測(cè)試的此版本的ONOS具有在個(gè)位數(shù)ms級(jí)發(fā)現(xiàn)switch/link down事件的能力。

#p#

實(shí)驗(yàn)C ：intent install/remove/re-route延遲測(cè)試

目的

這組測(cè)試旨在得到ONOS當(dāng)一個(gè)application安裝，退出多種批大小的intents時(shí)的延遲特性（即響應(yīng)時(shí)間）。

同時(shí)也得到ONOS路徑切換事件的延時(shí)特性，即最短路徑不可用，已安裝的intent由于路徑改變而需要重路由時(shí)所花費(fèi)的時(shí)延。這是一個(gè)ONOS的 全方位系統(tǒng)測(cè)試，從ONOS的 NB API 經(jīng)過(guò)intent 和flow subsystem 到ONOS的 SB API；采用Null Provider代替Openflow Adaptor進(jìn)行測(cè)試。

這組測(cè)試結(jié)果將向網(wǎng)絡(luò)運(yùn)營(yíng)商和應(yīng)用開(kāi)發(fā)者提供當(dāng)operating intents時(shí)applications所期望的響應(yīng)時(shí)間以及intents批的大小和集群數(shù)量的大小對(duì)時(shí)延的影響的***手資料。

配置和方法—batch intent安裝與退出

參考下圖，我們用ONOS內(nèi)置的app“push-test-intent”從ONOS1并通過(guò)ONOS1的intent API推進(jìn)一個(gè)批的點(diǎn)對(duì)點(diǎn)intents。“push-test-intent”工具構(gòu)造一系列的基于終點(diǎn)的，批大小和application id的intents。然后通過(guò)intent API 發(fā)送這些intents請(qǐng)求。當(dāng)成功安裝所有的intents時(shí)，返回延遲（響應(yīng)時(shí)間）。隨后退出這些intents并返回一個(gè)退出響應(yīng)時(shí)間。當(dāng) intents請(qǐng)求被發(fā)送時(shí)，ONOS內(nèi)部轉(zhuǎn)換intents到流規(guī)則并寫入相應(yīng)的分布式存儲(chǔ)來(lái)分發(fā)intents和流表。

參考下圖，特別是我們的實(shí)驗(yàn)中，intents被構(gòu)建在一個(gè)端到端的7個(gè)線性配置的交換機(jī)上，也就是說(shuō)所有intents的入口是從S1的一個(gè)端口 和它們的出口是S7的一個(gè)端口。（我們使用在拓?fù)渲蓄~外的交換機(jī)S8進(jìn)行intent re-route測(cè)試，這個(gè)測(cè)試后續(xù)描述）。我們通過(guò)Null Providers來(lái)構(gòu)建交換機(jī)（Null Devices），拓?fù)洌∟ull Links）和流量（Null Flows）。

當(dāng)增大集群節(jié)點(diǎn)數(shù)量時(shí)，我們重新平均分配switch的主控權(quán)到各個(gè)集群節(jié)點(diǎn)。

[[133233]]

在這個(gè)實(shí)驗(yàn)中，我們將使用如下指標(biāo)來(lái)衡量ONOS性能：

• 所有安裝的intents是6hops點(diǎn)到點(diǎn)intents；
• Intent批的大?。?，10，100，1000，5000 intents；
• 測(cè)試次數(shù)：每個(gè)用例重復(fù)測(cè)試20次（4次預(yù)測(cè)試之后統(tǒng)計(jì)）；
• 集群規(guī)模大小從1到3，5，7個(gè)節(jié)點(diǎn)。

配置和方法--intent Re-route

同樣參照上圖，intent re-route延遲是一個(gè)測(cè)試ONOS在最短路徑不可用的情況下，重新安裝所有intents到新路徑的速度。

測(cè)試順序如下：

1.我們通過(guò)“push-test-intents -i”選項(xiàng)預(yù)安裝不會(huì)自動(dòng)退出的intents在線性最短路徑上。然后我們通過(guò)修改Null Provider 鏈路定義文件模擬最短路徑的故障。當(dāng)新拓?fù)浔籓NOS發(fā)現(xiàn)時(shí)，我們通過(guò)檢查ONOS 日志獲取觸發(fā)事件的初始時(shí)間戳t0；

2.由于 6-hop最短路徑已不可用。ONOS切換到通過(guò)S8的7-hop備份路徑。Intent和流系統(tǒng)響應(yīng)該事件，退出舊intents并刪除舊流表（因?yàn)镺NOS當(dāng)前實(shí)現(xiàn)，所有intents和流已不可重新使用）。

3.接下來(lái)，ONOS重新編譯intents和流，并安裝。在驗(yàn)證所有intents確實(shí)被成功安裝后，我們從“Intents-events-metrics”捕獲***的intent安裝時(shí)間戳（t1）。

4.我們把（t1-t0）作為ONOS 重路由intent(s)的延遲。

5.測(cè)試腳本迭代的幾個(gè)參數(shù)：

a. Intent初始安裝的批大?。?,10,100,1000和5000 intents；

b.每個(gè)測(cè)試結(jié)果統(tǒng)計(jì)的是運(yùn)行20次的結(jié)果平均值（4個(gè)預(yù)測(cè)試之后開(kāi)始統(tǒng)計(jì)）；

c. ONOS集群規(guī)模從1,到3,5,7節(jié)點(diǎn)。

結(jié)果

[[133234]] 

[[133235]] 

[[133236]] 

[[133237]] 

[[133238]]

分析和總結(jié)

我們從這個(gè)實(shí)驗(yàn)中得出結(jié)論：

1.正如預(yù)期，與單節(jié)點(diǎn)的ONOS相比，多個(gè)節(jié)點(diǎn)的ONOS集群由于EW-wise通信的需要延遲比較大

2.小批intents(1-100),不計(jì)批大小時(shí)，其主要的延時(shí)是一個(gè)固定的處理時(shí)延，因此當(dāng)批大小增大，每一個(gè)intent安裝時(shí)間減少，這就是時(shí)延大批的優(yōu)點(diǎn)。

3.批大小非常大的情況下（如5000），隨著集群大小增加（從3到7），延遲減少，其主要是由于每個(gè)節(jié)點(diǎn)處理較小數(shù)量的intents；

4.Re-routeing延時(shí)比初始化安裝和退出的延遲都小。

#p#

實(shí)驗(yàn)D：Intents Operation吞吐量

目標(biāo)

本項(xiàng)測(cè)試的目的是衡量ONOS處理intents operations 請(qǐng)求的能力。SDN控制器其中一個(gè)重要用例就是允許agile applications通過(guò)intents和流規(guī)則頻繁更改網(wǎng)絡(luò)配置。作為一款SDN控制器，ONOS應(yīng)該具有高水平的intents安裝和撤銷處理能 力。ONOS使用的分布式架構(gòu), 隨著集群規(guī)模的增加，理應(yīng)能夠維持較高的intent operation吞吐量。

設(shè)置和方法

下圖描述了測(cè)試方法：

[[133239]]

本測(cè)試使用工具"intent-perf"來(lái)產(chǎn)生大量的Intents operation請(qǐng)求。這個(gè)intent-perf工具可以在ONOS集群環(huán)境中的任何一個(gè)節(jié)點(diǎn)激活并使用。這個(gè)工具在使用過(guò)程中有個(gè)三個(gè)參數(shù)需要配置：

• numKeys – 唯一的intents數(shù)量, 默認(rèn) 40,000;
• cyclePeriod – intents安裝和撤銷的周期（時(shí)間間隔），默認(rèn) 1000ms;
• numNeighbors –程序運(yùn)行時(shí)，發(fā)送到各個(gè)集群節(jié)點(diǎn)的方式。0表示本節(jié)點(diǎn)；-1表示所有的集群節(jié)點(diǎn)

當(dāng)intent-perf在ONOS節(jié)點(diǎn)運(yùn)行時(shí)，以恒定的速率產(chǎn)生大量的、ONOS系統(tǒng)可以支持的intents安裝撤銷請(qǐng)求。在ONOS 日志中或 cli request中，會(huì)周期性的給出總體的intents處理吞吐量。持續(xù)運(yùn)行一段時(shí)間后，我們可以觀察到在集群的某個(gè)或某些節(jié)點(diǎn)總體吞吐量達(dá)到了飽和狀 態(tài)。總體吞吐量需要包含intents安裝撤銷操作。統(tǒng)計(jì)所有運(yùn)行intent-perf這個(gè)工具的ONOS節(jié)點(diǎn)上的吞吐量并求和，從而得到ONOS集群 的總體吞吐量。

intent-perf只產(chǎn)生"1-hop" 的intents，即這些intents被編譯而成的流表的出口和入口都是在同一個(gè)交換機(jī)上，所以Null providers模塊不需要生成一個(gè)健全的拓?fù)浣Y(jié)構(gòu)。

特別是本實(shí)驗(yàn)中，我們使用兩個(gè)相鄰的場(chǎng)景。首先，設(shè)置numNeighbors = 0，這種場(chǎng)景下，intent-perf只需要為本地的ONOS節(jié)點(diǎn)產(chǎn)生的intents安裝和撤銷請(qǐng)求，從而把intents的東西向接口通信降至***；其次，設(shè)置numNeighbors 為-1后，intent-perf生成器產(chǎn)生的intents安裝和撤銷請(qǐng)求需要分發(fā)到所有的ONOS集群節(jié)點(diǎn)，這樣會(huì)把東西向接口的通信量***化。本次 測(cè)試持續(xù)進(jìn)行了300秒的負(fù)載測(cè)試，統(tǒng)計(jì)集群的總體吞吐量。其他的參數(shù)使用默認(rèn)值。

結(jié)果

[[133240]]

分析和結(jié)論

通過(guò)本次實(shí)驗(yàn)得出結(jié)論如下：

1.我們看到在ONOS的intents operations測(cè)試中一個(gè)明顯趨勢(shì)：總體吞吐量隨著集群節(jié)點(diǎn)的增加而增加；

2.在流表子系統(tǒng)測(cè)試中集群的場(chǎng)景對(duì)吞吐量的影響微乎其微。

#p#

實(shí)驗(yàn)F：Flow子系統(tǒng)迸發(fā)吞吐量測(cè)試

目的

如前面所提到的，流子系統(tǒng)是onos的一個(gè)組成部分，其作用是將Intents轉(zhuǎn)換成可以安裝到openflow交換機(jī)上的流規(guī)則。另外，應(yīng)用程序 可以直接調(diào)用其北向api來(lái)注入流規(guī)則。使用北向api和intent框架是此次性能評(píng)估的關(guān)鍵。另外，此次實(shí)驗(yàn)不但給我們暴漏了端到端Intent performance的性能缺陷，而且展示了當(dāng)直接與流規(guī)則子系統(tǒng)交互時(shí)對(duì)應(yīng)用的要求。

配置及方法

為了產(chǎn)生一批將被onos安裝刪除的流規(guī)則，我們使用腳本“flow-tester.py”。實(shí)際上這些腳本是onos工具執(zhí)行的一部分。具體位置 在（$ONOS_ROOT/tools/test/bin）目錄下。執(zhí)行這個(gè)腳本將觸發(fā)onos安裝一套流規(guī)則到所控制的交換機(jī)設(shè)備，當(dāng)所有流規(guī)則安裝成 功之后將會(huì)返回一個(gè)時(shí)延時(shí)間。這個(gè)腳本也會(huì)根據(jù)接收的一系列的參數(shù)去決定這個(gè)測(cè)試怎么運(yùn)行。這些參數(shù)如下：

• 每個(gè)交換機(jī)所安裝的流規(guī)則的數(shù)量
• 鄰居的數(shù)量-由于交換機(jī)的連接的控制器并非本地的onos節(jié)點(diǎn)，需要onos本地節(jié)點(diǎn)同步流規(guī)則到（除了運(yùn)行腳本的onos本地節(jié)點(diǎn)之外的）onos節(jié)點(diǎn)
• 服務(wù)的數(shù)量-運(yùn)行onos腳本的節(jié)點(diǎn)數(shù)量，即產(chǎn)生流規(guī)則的onos節(jié)點(diǎn)數(shù)量

下圖簡(jiǎn)要的描述了測(cè)試的配置：

從下圖可以看出，onos1，onos2是運(yùn)行onos腳本產(chǎn)生流規(guī)則的兩個(gè)服務(wù)器；當(dāng)兩個(gè)流生成服務(wù)器生成流給兩個(gè)鄰居，也就是所生成的流規(guī)則被傳遞到兩個(gè)與之相鄰的節(jié)點(diǎn)安裝。（因?yàn)檫@個(gè)流規(guī)則屬于被鄰居節(jié)點(diǎn)控制器的交換機(jī)）。

[[133241]]

我們使用了Null Provider作為流規(guī)則的消費(fèi)者，繞過(guò)了使用Openflow適配器和真實(shí)的或者模擬的交換機(jī)存在的潛在的性能限制。

具體實(shí)驗(yàn)參數(shù)設(shè)置

• Null Devices的數(shù)量保持常量35不變，然后被平均的分配到集群中的所有節(jié)點(diǎn)，例如，當(dāng)運(yùn)行的集群中有5個(gè)節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)將控制7個(gè)Null Devices;
• 集群一共安裝122500條流規(guī)則-選擇這個(gè)值其一是因?yàn)樗銐虼?，其二，它很容易平均分配到測(cè)試中所使用的集群節(jié)點(diǎn)。這也是工具“flow-tester.py”計(jì)算每個(gè)交換機(jī)所安裝的流規(guī)則數(shù)量的一個(gè)依據(jù)。
• 我們測(cè)試了2個(gè)關(guān)聯(lián)場(chǎng)景：1)鄰居數(shù)量為0，即所有的流規(guī)則都安裝在產(chǎn)生流的服務(wù)器上場(chǎng)景；2)鄰居數(shù)量為-1，即每個(gè)節(jié)點(diǎn)給自己以及集群中的其它節(jié)點(diǎn)產(chǎn)生流規(guī)則
• 測(cè)試集群規(guī)模1,3,5,7
• 響應(yīng)時(shí)間為4次預(yù)測(cè)試之后20次的的測(cè)試時(shí)間統(tǒng)計(jì)整合得出

備注：版本發(fā)布的時(shí)候，ONOS核心仍然采用Hazelcast作為存儲(chǔ)協(xié)議來(lái)備份流規(guī)則。

實(shí)驗(yàn)表明，使用Hazelcast協(xié)議作為備份，可能導(dǎo)致流規(guī)則安裝速率頻繁迸發(fā)增長(zhǎng)。

在這一系列實(shí)驗(yàn)中，我們通過(guò)修改發(fā)布版本如下路徑的代碼關(guān)閉了流規(guī)則備份。（$ONOS_ROOT/core/store/dist/src /main/java/org/onosproject/store/flow/impl /DistributedFlowRuleStore.java）

[[133242]]

分析與結(jié)論

通過(guò)測(cè)試，可以得出如下系統(tǒng)性能測(cè)試結(jié)論：

1.根據(jù)測(cè)試數(shù)據(jù)顯示，當(dāng)配置N=0時(shí)，與配置N=“all”相比，系統(tǒng)有更高的吞吐量。也就是說(shuō)當(dāng)生成的流規(guī)則只安裝給本地ONOS節(jié)點(diǎn)控制器的 設(shè)備時(shí)，流子系統(tǒng)的性能比安裝給所有ONOS節(jié)點(diǎn)控制的設(shè)備時(shí)高。因?yàn)椋琌NOS節(jié)點(diǎn)之間的EW-wise通信存在開(kāi)銷/瓶頸。即，當(dāng)配置N=“all” 時(shí)，性能低，符合預(yù)期值。

2.總的來(lái)說(shuō)，這兩種情況下通過(guò)增大集群節(jié)點(diǎn)數(shù)量測(cè)試，吞吐量隨著集群數(shù)量的增加有明顯的提高。但是這種提高是非線性的。例如，N=“all”與N=“0”相比，當(dāng)節(jié)點(diǎn)間需要通信同步時(shí)，平穩(wěn)增加的性能趨于平緩。

3.設(shè)置N=“all”與N=“0”獲得的類似的性能數(shù)據(jù)說(shuō)明，EW-wise通信沒(méi)有成為ONOS intent operation性能的瓶頸。