onos是一個網絡控制器。applications通過intent apis與onos進行互動。onos通過其南向适配層控制資料網絡的轉發（例如，openflow網絡）。onos控制層與資料轉發層之間是onos流 子系統，onos流子系統是将application intens轉換為openflow流規則的重要組成部分。onos也是一個分布式系統，至關重要的是onos分布式架構使其性能随着叢集數量增加而提 高。這份評估報告将onos看作一個整體的叢集系統，計劃從應用和操作環境兩個角度去評估onos性能。
我們設計了一系列的實驗，測試在各種應用和網絡環境下onos的延遲和吞吐量。并通過分析結果，我們希望提供給網絡營運商和應用開發商第一手資料去了解onos的性能。此外，實驗的結果将有助于開發人員發現性能瓶頸并優化。
下圖把onos分布式系統作為一個整體，介紹了關鍵的測試點。
onos分布式系統作為一個整體
圖中包括如下性能測試點:
延遲：
a -交換機 連接配接/斷開;
b -link啟用/斷開;
c -intent的批量安裝/删除/路徑切換;
吞吐量：
d -intent操作;
e -link事件(測試暫緩);
f –迸發流規則安裝。
<a target="_blank"></a>
叢集規模性能測試：
onos最突出的特點是其分布式架構。是以，onos性能測試的一個關鍵方面是比較和分析不同叢集大小下onos的性能。所有的測試用例将以onos叢集節點數量為1,3,5,7展開。
為了展示onos的本質特征，使測試不受測試儀器的瓶頸限制，我們采用了一些比較實用的工具進行實驗。所有實驗，除了與openflow協定互動的 交換機和端口及其它相關的，我們在onos的适配層部署了一套null providers與onos core進行互動。null providers擔任着生成device,link,host以及大量的流規則的角色。通過使用null providers,我們可以避免并消除openflow适配和使用真實裝置或者模拟的openflow裝置所存在的潛在的性能瓶頸。
同時，我們也部署了一些負載生成器，這樣可以使應用或者網絡接口生成高強度的負載去觸及onos的性能極限。
這些生成器包括：
1.intent performance 生成器“onos-app-intent-perf”，它與intent api互動,生成intent安裝/删除操作，并根據onos可承受的最高速度自我調節生成的intent操作的負載。
2.流規則安裝python腳本工具與onos flow subsystem互動去安裝和删除subsystem中的流規則。
3.null linkprovider中的link 事件（閃爍）生成器，可以迅速提升發送速度到onos所能承受的極限并依此速率發送link up/down資訊給onos core。
4.此外，我們在"topology-events-metrics" 和"intents-events-metrics" 應用中利用計數器去擷取關鍵事件的時間戳與處理速率來友善那些時間及速度相關的測試。
我們将在後續的每個不同的測試過程中詳細介紹這些生成器的配置。
a 7台 叢集實驗所需要的裸伺服器。每個伺服器的規格如下：
雙intel xeon e5-2670v2處理器為2.5ghz - 10核心/20超線程核心
32gb1600mhz的ddr3 dram
1gbps的網絡接口卡
ubuntu的14.04 os
叢集之間使用ptpd同步
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
其他的具體與用例相關的onos參數将在具體的用例中進行說明
下面将具體介紹每個用例的細節配置，測試結果讨論及分析。
本實驗是測試onos控制器在不同規模的叢集環境中是如何響應拓撲事件的，測試拓撲事件的類型包括：
1）交換機連接配接或斷開onos節點
2）在現有拓撲中鍊路的up和down
onos作為一個分布式的系統架構，多節點叢集相比于獨立節點可能會發生額外的同步拓撲事件的延遲。除了限制獨立模式下的延遲時間，也要減少由于onos叢集間由于ew-wise通信事件産生額外延時。
下面的圖表說明了測試設定。一個交換機連接配接事件，是在一個“floating”（即沒有交換機端口和鍊路）的ovs（of1.3）上通過“set- controller”指令設定ovs橋連接配接到onos1控制器。我們在of控制層面網絡上使用tshark工具捕捉交換機上線的時間戳，onos device和graph使用“topology-event-metrics”應用記錄時間戳。通過整理核對這些時間戳，我們得出從最初的事件觸發到 onos在其拓撲中記錄此事件的“端到端”的時序曲線。
交換機連接配接斷開的延遲測試設定
所需得到的幾個關鍵時間戳如下：
1.裝置啟動連接配接時間點t0，tcp syn/ ack；
2.openflow協定的交換：
t0 -> onos features reply；
ovs features reply -> onos role request; (onos 在這裡處理選擇主備控制器)；
onos role request -> ovs role reply –of協定的初始交換完成。
3.onos core處理事件的過程：
of協定交換完成後觸發device event；
本地節點的device event觸發topology (graph) event。
同樣的，測試交換機斷開事件，我們使用ovs指令“del-controller”斷開交換機與它連接配接的onos節點，捕獲的時間戳如下：
1.ovs tcp syn/fin (t0);
2.ovs tcp fin;
3.onos device event;
4.onos graph event (t1).
交換機斷開端到端的延遲為（t1 - t0）
當我們增大onos叢集的大小，我們隻連接配接和斷開onos1上的交換機，并記錄所有節點上的事件時間戳。叢集的整體延遲是graph event報告中最遲的節點的延時時間。在我們的測試腳本中，我們一次測試運作多個疊代（例如，20次疊代）來收集統計結果。
測試一條連結up / down事件的延遲，除了我們用兩個ovs交換機建立鍊路（我們使用mininet建立一個簡單的兩個交換機的線性拓撲結構）外，我們使用了與交換機連接配接 測試的類似方法。這兩個交換機的主要權屬于onos1。參照下面的圖表。初步建立交換機-控制器連接配接後，設定一個交換機的接口up或down，我們通過端 口up或down事件來觸發此測試。
一些關鍵的時間戳記錄，如下所述：
1. 交換機端口up/down, t0；
2. ovs向onos1發送of portstatus update消息；
2a.在端口up的情況下，onos通過給每個ovs交換機發送鍊路發現消息來産生鍊路發現事件，同時onos收到其他交換機發送的openflow packetin消息。
3.onos core處理事件過程：
由of port status消息引起的device事件; （onos處理）
鍊路down時，link event由device event觸發在本地節點産生，鍊路up時，link event是在鍊路發現packetin/out完成後産生的；（主要時間都是在ofp消息和onos處理上）
本地節點生成graph event。（onos處理）
類似于交換機的連接配接測試，我們認為在graph event中登記的叢集中最遲的節點的延時時間為叢集的延遲。
onos core處理事件過程
switch-add event:
交換機連接配接斷開switch-add
link up/down event：
link up down event （up）
switch connect/disconnect event：
當一個交換機連接配接到onos時，明顯的時延劃分為以下幾個部分：
1.鍊路發現的中時延最長的部分，是從最初的tcp連接配接到onos收到openflow features-replay消息。進一步分析資料包（在結果圖中未示出），我們可以看到大部分時間是花在初始化控制器與交換機的openflow握手 階段，onos等待ovs交換機響應它的features_request。而這個時延很大程度上不是由onos的處理引起的。
2.其次是在"ofp feature reply -> ofp role request"部分，這部分時延也會随着onos叢集規模增加而增加，其主要花費在onos給新上線的交換機選擇主要權上，這是由于單節點的onos隻 需在本地處理，而多節點的叢集環境中，叢集節點之間的通信将會帶來這個額外的延時
3.接着便是從openflow握手完成(ofp role reply)到onos登記一個device event的過程中消耗的時延。這部分的時延也受多節點onos配置影響，因為此事件需要onos将其寫入device store。
4.最後一個延時比較長的是onos在本地處理來着device store的device event到向graph中注冊拓撲資訊事件的部分。
斷開交換機時，随着onos叢集規模的增大onos觸發device事件的時延将略有增加。
總之，在openflow消息交換期間，ovs對feature-request的響應時延占據了交換機建立連接配接事件中，整體時延的絕大部分。接 着，onos花費約9毫秒處理主要權選。最後，onos在多節點叢集環境下，由于各節點之間需要通信選舉主節點，交換機上/下線時延将都會增加。
link up/down events:
此次測試，我們首先觀察到的是，鍊路up事件比鍊路down事件花費更長的時間。通過時延分析，我們可以看到ovs的端口up事件觸發了onos特 殊的行為鍊路發現，是以，絕大多數時延主要由處理鍊路發現事件引起。與單節點的onos相比這部分時延受叢集節點的影響也比較大。另外，大多數onos core花費在向graph登記拓撲事件上的時延在個位數的ms級别。
在大部分的網絡操作情況下，雖然整體拓撲事件的低延遲是可以被容忍的，但是交換機/鍊路斷開事件卻至關重要，因為它們被更多的看作是 applications的adverse events。當onos能更快速的檢測到link down/up事件時，pplications也就能更快速的響應此adverse events，我們測試的此版本的onos具有在個位數ms級發現switch/link down事件的能力。
這組測試旨在得到onos當一個application安裝，退出多種批大小的intents時的延遲特性（即響應時間）。
同時也得到onos路徑切換事件的延時特性，即最短路徑不可用，已安裝的intent由于路徑改變而需要重路由時所花費的時延。這是一個onos的 全方位系統測試，從onos的 nb api 經過intent 和flow subsystem 到onos的 sb api；采用null provider代替openflow adaptor進行測試。
這組測試結果将向網絡營運商和應用開發者提供當operating intents時applications所期望的響應時間以及intents批的大小和叢集數量的大小對時延的影響的第一手資料。
參考下圖，我們用onos内置的app“push-test-intent”從onos1并通過onos1的intent api推進一個批的點對點intents。“push-test-intent”工具構造一系列的基于終點的，批大小和application id的intents。然後通過intent api 發送這些intents請求。當成功安裝所有的intents時，傳回延遲（響應時間）。随後退出這些intents并傳回一個退出響應時間。當 intents請求被發送時，onos内部轉換intents到流規則并寫入相應的分布式存儲來分發intents和流表。
參考下圖，特别是我們的實驗中，intents被建構在一個端到端的7個線性配置的交換機上，也就是說所有intents的入口是從s1的一個端口 和它們的出口是s7的一個端口。（我們使用在拓撲中額外的交換機s8進行intent re-route測試，這個測試後續描述）。我們通過null providers來建構交換機（null devices），拓撲（null links）和流量（null flows）。
當增大叢集節點數量時，我們重新平均配置設定switch的主要權到各個叢集節點。
使用名額來衡量onos性能
在這個實驗中，我們将使用如下名額來衡量onos性能：
所有安裝的intents是6hops點到點intents；
intent批的大小：1，10，100，1000，5000 intents；
測試次數：每個用例重複測試20次（4次預測試之後統計）；
叢集規模大小從1到3，5，7個節點。
同樣參照上圖，intent re-route延遲是一個測試onos在最短路徑不可用的情況下，重新安裝所有intents到新路徑的速度。
測試順序如下：
1.我們通過“push-test-intents -i”選項預安裝不會自動退出的intents線上性最短路徑上。然後我們通過修改null provider 鍊路定義檔案模拟最短路徑的故障。當新拓撲被onos發現時，我們通過檢查onos 日志擷取觸發事件的初始時間戳t0；
2.由于 6-hop最短路徑已不可用。onos切換到通過s8的7-hop備份路徑。intent和流系統響應該事件，退出舊intents并删除舊流表（因為onos目前實作，所有intents和流已不可重新使用）。
3.接下來，onos重新編譯intents和流，并安裝。在驗證所有intents确實被成功安裝後，我們從“intents-events-metrics”捕獲最後的intent安裝時間戳（t1）。
4.我們把（t1-t0）作為onos 重路由intent(s)的延遲。
5.測試腳本疊代的幾個參數：
a. intent初始安裝的批大小：1,10,100,1000和5000 intents；
b.每個測試結果統計的是運作20次的結果平均值（4個預測試之後開始統計）；
c. onos叢集規模從1,到3,5,7節點。
c實驗 延遲測試
我們從這個實驗中得出結論：
1.正如預期，與單節點的onos相比，多個節點的onos叢集由于ew-wise通信的需要延遲比較大
2.小批intents(1-100),不計批大小時，其主要的延時是一個固定的處理時延，是以當批大小增大，每一個intent安裝時間減少，這就是時延大批的優點。
3.批大小非常大的情況下（如5000），随着叢集大小增加（從3到7），延遲減少，其主要是由于每個節點處理較小數量的intents；
4.re-routeing延時比初始化安裝和退出的延遲都小。
本項測試的目的是衡量onos處理intents operations 請求的能力。sdn控制器其中一個重要用例就是允許agile applications通過intents和流規則頻繁更改網絡配置。作為一款sdn控制器，onos應該具有高水準的intents安裝和撤銷處理能 力。onos使用的分布式架構, 随着叢集規模的增加，理應能夠維持較高的intent operation吞吐量。
下圖描述了測試方法：
d實驗 測試方法
本測試使用工具"intent-perf"來産生大量的intents operation請求。這個intent-perf工具可以在onos叢集環境中的任何一個節點激活并使用。這個工具在使用過程中有個三個參數需要配置：
numkeys – 唯一的intents數量, 預設 40,000;
cycleperiod – intents安裝和撤銷的周期（時間間隔），預設 1000ms;
numneighbors –程式運作時，發送到各個叢集節點的方式。0表示本節點；-1表示所有的叢集節點
當intent-perf在onos節點運作時，以恒定的速率産生大量的、onos系統可以支援的intents安裝撤銷請求。在onos 日志中或 cli request中，會周期性的給出總體的intents處理吞吐量。持續運作一段時間後，我們可以觀察到在叢集的某個或某些節點總體吞吐量達到了飽和狀 态。總體吞吐量需要包含intents安裝撤銷操作。統計所有運作intent-perf這個工具的onos節點上的吞吐量并求和，進而得到onos叢集 的總體吞吐量。
intent-perf隻産生"1-hop" 的intents，即這些intents被編譯而成的流表的出口和入口都是在同一個交換機上，是以null providers子產品不需要生成一個健全的拓撲結構。
特别是本實驗中，我們使用兩個相鄰的場景。首先，設定numneighbors = 0，這種場景下，intent-perf隻需要為本地的onos節點産生的intents安裝和撤銷請求，進而把intents的東西向接口通信降至最 低；其次，設定numneighbors 為-1後，intent-perf生成器産生的intents安裝和撤銷請求需要分發到所有的onos叢集節點，這樣會把東西向接口的通信量最大化。本次 測試持續進行了300秒的負載測試，統計叢集的總體吞吐量。其他的參數使用預設值。
d實驗吞吐量 結果
通過本次實驗得出結論如下：
1.我們看到在onos的intents operations測試中一個明顯趨勢：總體吞吐量随着叢集節點的增加而增加；
2.在流表子系統測試中叢集的場景對吞吐量的影響微乎其微。
如前面所提到的，流子系統是onos的一個組成部分，其作用是将intents轉換成可以安裝到openflow交換機上的流規則。另外，應用程式 可以直接調用其北向api來注入流規則。使用北向api和intent架構是此次性能評估的關鍵。另外，此次實驗不但給我們暴漏了端到端intent performance的性能缺陷，而且展示了當直接與流規則子系統互動時對應用的要求。
為了産生一批将被onos安裝删除的流規則，我們使用腳本“flow-tester.py”。實際上這些腳本是onos工具執行的一部分。具體位置 在（$onos_root/tools/test/bin）目錄下。執行這個腳本将觸發onos安裝一套流規則到所控制的交換機裝置，當所有流規則安裝成 功之後将會傳回一個時延時間。這個腳本也會根據接收的一系列的參數去決定這個測試怎麼運作。這些參數如下：
每個交換機所安裝的流規則的數量
鄰居的數量-由于交換機的連接配接的控制器并非本地的onos節點，需要onos本地節點同步流規則到（除了運作腳本的onos本地節點之外的）onos節點
服務的數量-運作onos腳本的節點數量，即産生流規則的onos節點數量
下圖簡要的描述了測試的配置：
從下圖可以看出，onos1，onos2是運作onos腳本産生流規則的兩個伺服器；當兩個流生成伺服器生成流給兩個鄰居，也就是所生成的流規則被傳遞到兩個與之相鄰的節點安裝。（因為這個流規則屬于被鄰居節點控制器的交換機）。
f實驗 簡要的描述了測試的配置
我們使用了null provider作為流規則的消費者，繞過了使用openflow擴充卡和真實的或者模拟的交換機存在的潛在的性能限制。
null devices的數量保持常量35不變，然後被平均的配置設定到叢集中的所有節點，例如，當運作的叢集中有5個節點，每個節點将控制7個null devices;
叢集一共安裝122500條流規則-選擇這個值其一是因為它足夠大，其二，它很容易平均配置設定到測試中所使用的叢集節點。這也是工具“flow-tester.py”計算每個交換機所安裝的流規則數量的一個依據。
我們測試了2個關聯場景：1)鄰居數量為0，即所有的流規則都安裝在産生流的伺服器上場景；2)鄰居數量為-1，即每個節點給自己以及叢集中的其它節點産生流規則
測試叢集規模1,3,5,7
響應時間為4次預測試之後20次的的測試時間統計整合得出
備注：版本釋出的時候，onos核心仍然采用hazelcast作為存儲協定來備份流規則。
實驗表明，使用hazelcast協定作為備份，可能導緻流規則安裝速率頻繁迸發增長。
在這一系列實驗中，我們通過修改釋出版本如下路徑的代碼關閉了流規則備份。（$onos_root/core/store/dist/src /main/java/org/onosproject/store/flow/impl /distributedflowrulestore.java）
f實驗并發吞吐量測試 結果
通過測試，可以得出如下系統性能測試結論：
1.根據測試資料顯示，當配置n=0時，與配置n=“all”相比，系統有更高的吞吐量。也就是說當生成的流規則隻安裝給本地onos節點控制器的 裝置時，流子系統的性能比安裝給所有onos節點控制的裝置時高。因為，onos節點之間的ew-wise通信存在開銷/瓶頸。即，當配置n=“all” 時，性能低，符合預期值。
2.總的來說，這兩種情況下通過增大叢集節點數量測試，吞吐量随着叢集數量的增加有明顯的提高。但是這種提高是非線性的。例如，n=“all”與n=“0”相比，當節點間需要通信同步時，平穩增加的性能趨于平緩。
3.設定n=“all”與n=“0”獲得的類似的性能資料說明，ew-wise通信沒有成為onos intent operation性能的瓶頸。
原文釋出時間：2015-05-04
本文來自雲栖合作夥伴“linux中國”