基于OpenFlow南向協議的SDN控制器性能測試方法及定量分析

張 攀 楊 虹

引言

隨著軟件定義網絡(Software Defined Network,SDN)成為網絡世界的新的范式轉移，控制平面和轉發平面的分離讓后者得到了極大的簡化，繁重的處理和計算工作都遷移至控制平面。作為控制平面的核心組件，控制器在全局網絡性能中扮演決定性角色。鑒于SDN網絡的實驗或商業部署已經展開，網絡用戶將控制器的性能當作一個越來越重要的衡量標準。

作為目前業界關注的焦點，SDN控制器的性能關系到SDN技術是否可以兌現新技術帶來的承諾。為滿足網絡用戶需求，本文介紹SDN控制器性能的詳細測試方法，以及以某一款開源控制器為例的定量測試結果，以便給出結果的標準呈現形式。所有測試例都針對OpenFlow 1.3[1]這一SDN南向協議。

本文介紹的測試方法可以在實驗室中復現，可為所有關心SDN控制器性能的用戶提供標準化的測試過程及測試例設計依據[2]。同時，在本文中提供了示例控制器在特定硬件平臺上的定量測試結果，詳細介紹了結果的分析過程和結論。可為評估控制器性能的用戶，提供必要及有效的參考[3]。

2 環境設計

2.1 設計目標

本文介紹的測試方法旨在以定量的方式測量SDN控制器以下幾個方面的性能。

1)控制通道容量。控制器連接交換機的最大數目，關系到整個SDN網絡的可拓展性。

2)拓撲發現時間。該功能是SDN控制器需要實現的基本功能之一，本文介紹的測試方法可以測量其在不同規模、不同拓撲連接方式下完成網絡拓撲發現所需的時間。

3)拓撲響應時間。SDN控制器針對拓撲變化事件，比如Port Down/Up等事件的偵測及響應時間，可以衡量SDN控制器對網絡鏈路的控制能力。

4)被動流表下發速率。即控制器根據既定策略下發流表的速率。可以衡量控制器對上層網絡策略的執行能力。

5)被動Packet_out消息下發速率。Packet_out消息是OpenFlow協議中主要的消息類型之一，在實際網絡運營中關系到LLDP、ARP等協議的應用。其下發速率也是需要定量測量的指標之一。

在給出測試方法之外，仍會對實際的測量結果加以分析，介紹其結果的定量分析方法。同時，本文也將嘗試對比分析控制器在單點運行模式以及集群運行模式下，同一性能指標的變化，其變化的特點以及所揭示出的控制器的特質，將為SDN網絡用戶提供參考。

2.2 被測控制器設計

為完成設計目標，一款開源控制器被選為示例被測控制器。它是目前流行的開源控制器之一，支持多種功能，例如設備管理、拓撲管理、鏈路管理、集群、圖形用戶界面以及多種SDN應用。它的OpenFlow 1.3南向協議消息處理性能是我們關注的內容。在本次搭建的測試環境里，我們設置了三臺完全相同的虛擬機，每一虛擬機上都運行著一個完全相同的控制器節點實例。

2.3 硬件環境設計

為更好地比較控制器集群運行模式的實驗結果，本次設計硬件環境為單臺物理機運行多臺虛擬機的模式，控制器運行于虛擬機中。詳細配置如下。

物理機：

虛擬機：

2.4 控制器運行模式設計

為得到控制性能更完善的信息，定義了兩種控制器運行模式。

1)單點運行模式。一個控制器節點實例運用于一個虛擬機之上。

2)集群運行模式。每一個虛擬機各運營一個控制器節點實例，三個分布式的，運營在不同虛擬機上的控制器實例組合成控制器集群，共同工作。

2.5 測試建議

1)隔離建議。所有的測試都建議執行于實驗室環境和隔離的網絡之中，以防外界的干擾對測試結果造成影響。

2)連接建議。被測控制器建議與測試工具直接連接，防止中間設備引入延遲或失效，導致測試結果不準確。

3)迭代建議。每一測試例都建議迭代執行10次以上，分別記錄最大值、最小值和平均值。可以更全面地體現控制器的性能。

4)負載均衡驗證建議。當控制器以集群模式運行時，建議分別記錄各節點實例的CPU、內存使用率，以便檢測在壓力之下，控制器集群是否可以進行負載分擔。

3 性能測試例及結果

3.1 控制通道容量測試

1)測試目的。測量控制器可以同時建立的OpenFlow 1.3通道的最大數目。

2)測試前提。

①被測控制器可以分別運行于單點模式和集群模式。

②被測控制器和模擬交換機都可以通過OpenFlow Echo request/reply消息維持控制通道的連接。

3)測試拓撲。如圖1所示。

圖1 控制通道容量測試示例拓撲

4)測試方法。

①以單點模式啟動被測控制器。

②以不同拓撲連接的模擬交換機開始建立與被測控制器的OpenFlow 1.3連接。

③逐步增加交換機的數量，直到最大數目Nm，記錄每一步的內存占用量。

④等待5分鐘，確保已建立的控制通道穩定。

⑤在集群模式下迭代該測試過程。

5)測試結果。

①單點模式。本次測試采用三種拓撲連接方式：即Linear拓撲、Ring拓撲和Grid拓撲。如果建立的控制通道穩定并且每一個模擬控制器都收到了來自被測控制器的正確配置(安裝默認流表)，那么此時記錄的內存使用量即視為有效數據。默認情況下，控制器會下發兩個針對ARP和LLDP數據包的流表給交換機，如果有交換機沒收到這兩條流表，我們即認為此時的交換機數目已超過最大數目，并將此時內存使用情況標記為N/A。詳細的平均內存使用情況如圖2所示。

②集群模式。在集群模式下，三個節點的內存使用量需要分別表示。該模式下，采用了兩種拓撲：Linear拓撲和Ring拓撲。從測試結果可以看出，即便是存在一個leader節點，三個節點的內存使用量也大致相同，并且在每一個的總量上也稍稍高于單點模式。分析認為這是由于每一個節點都需要建立與全部交換機的控制通道，同時加入額外的集群同步機制；因此，可建立控制通道的數量并沒有得到極大提升。詳細結果如圖3所示。

3.2 拓撲發現時間

1)測試目的。測量在不同網絡拓撲和不同交換機數量下的控制器拓撲發現時間。

2)測試前提。

①被測控制器可以分別運行于單點模式和集群模式。被測控制器可以無差錯地支持拓撲發現功能。

②默認的Table-miss流表的動作必須為上送控制器，或交換機有預先安裝的針對拓撲發現消息的流表。

3)測試拓撲。如圖4所示。

圖2 單點模式測試結果

圖3 控制通道容量集群模式測試結果

圖4 拓撲發現時間測試示例拓撲

4)測試方法。

①以單點模式啟動被測控制器。

②模擬交換機開始建立與被測控制器的連接。

③記錄時間Tstart為控制器開啟拓撲發現服務的時間。

④記錄時間Tfout為控制器發出第一個包含LLDP數據包的Packet_out消息的時間。

⑤記錄時間Tfin為控制器收到第一個Packet_in消息的時間。

⑥記錄時間Tlin為最后一個由模擬交換機發出的Packet_in消息的時間。

⑦記錄時間Tend為控制器完成拓撲發現的時間。

⑧取得拓撲發現時間為T=Tend - Tstart。

⑨同時計算Tfout - Tstart(Tinit)，為控制器初始化拓撲發現服務時間，Tfin - Tfout (Ttool)和Tlin -Tfin(Tnode)為使用不同測試工具和不同拓撲、節點數目的變動時間。Tend - Tlin(Tproc)為控制器處理LLDP消息并生成拓撲發現結果的處理時間。

⑩在不同拓撲連接方式，不同節點數目下迭代該測試。

在集群模式下迭代該測試。

5)測試結果。

①單點模式。本次測試采用了三種不同的拓撲類型，Linear拓撲、Ring拓撲和Grid拓撲。從測試結果來看，Tinit和Ttool兩個時間間隔在不同情況下基本保持恒定，這兩個時間分別為60±5ms和1ms，在下述的圖標中并不容易被觀察到。Tnode和Tproc與節點數量成正比，同時遠大于Tinit和Ttool兩個時間間隔。詳細結果見圖5所示。

圖5 拓撲發現時間單點模式測試結果

②集群模式。在集群模式下，采用了相同的三種拓撲連接類型。Tinit和Ttool與在單點模式下的測試結果相同。當節點數量相對較小時，Tproc比單點模式要長，主要由于節點間同步進程的額外開銷。當節點數量較大時(100～300)，Tproc的時間減小，由于集群增加的計算能力成為了主要的影響因素。根據測試過程中的抓包記錄，只有leader節點通過Packet_out消息發送LLDP數據包，但是交換機將Packet_in消息分別發送給三個節點，因此，Tnode時間在集群模式下增長。所以全局的拓撲發現時間在不同的測試環境下，可能增加也可能增長。同時可以發現拓撲發現時間與交換機連接的拓撲類型有密切關系。詳細測試結果如圖6所示。

3.3 拓撲事件響應時間測試

1)測試目的。測量被測控制器對拓撲變化事件的響應時間。這些事件包括Port up/down和Switch up/down。在本測試例中不僅檢測控制器對這些事件的偵測時間，同時也包括整套拓撲更新動作的完成時間。

圖6 拓撲發現時間集群模式測試結果

2)測試前提。

①被測控制器可以分別運行于單點和集群模式。

②被測控制器可以無差錯地支持拓撲發現功能。

③默認的Table-miss流表的動作必須為上送控制器，或交換機有預先安裝的針對拓撲發現消息的流表。

3)測試拓撲。如圖7所示。

圖7 拓撲時間相應時間測試示例拓撲

4)測試方法。

①以單點模式啟動被測控制器。

②以不同拓撲連接的模擬交換機開始建立與被測控制器的OpenFlow 1.3連接。

③等待直至拓撲發現完成。

④手動關閉交換機的某一端口。

⑥記錄時間T1為控制器收到通知消息的時間。

⑦記錄時間T2為控制器完成拓撲重新發現的時間。

⑧取得拓撲事件響應時間T = T2 - T1。

⑨在不同拓撲、不同交換機數量下迭代執行該測試。

⑩在集群模式下迭代執行該測試。

5)測試結果。

①單點模式。本次測試中采用了兩種拓撲連接模式，Ring拓撲和Hub-spoke拓撲。從測試結果看來，Port up/down事件相對于Switch up/down事件，被測服務器響應的時間更短。對拓撲影響更大的Port down事件比Port up事件響應的時間更長。針對Port down事件的響應時間甚至超過了10秒，被測控制器在該方面還有很大的提升空間。圖8中，Port down/up事件的時間單位是秒，Switch up/down事件的時間單位是毫秒。

圖8 拓撲事件響應時間單點模式測試結果

②集群模式。在集群模式下，采用了三種拓撲連接模式。從測試結果來看，拓撲變化事件的響應時間展現出不可控的特性。集群節點之間的同步進程、拓撲類型以及集群內部的拓撲發現機制(發送LLDP數據包的時間間隔)，所有這些有影響的變量都讓測試結果出現了隨機性。沒有人可以斷言集群模式下的控制器響應時間更短，或拓撲中節點數量越小越容易響應。這也是網絡用戶在真實部署SDN網絡時可能遇到的問題。詳細測試結果如圖9所示。

圖9 拓撲事件響應時間集群模式測試結果

3.4 被動流表下發速率測試

1)測試目的。測量被測控制器被動流表下發最大速率。

2)測試前提。①被測控制器可以分別運行于單點模式和集群模式。②被測控制器可以無差錯地支持拓撲發現功能。③默認的Table-miss流表的動作必須為上送控制器。④一個SDN應用需要在控制器之上運行，響應流表下發的需求，并能以最大可能的速率下發流表。

3)測試拓撲。如圖10所示。

圖10 被動流表下發速率測試示例拓撲

4)測試方法。

①以單點模式啟動被測控制器。

②模擬交換機開始建立與被測控制器的OpenFlow 1.3連接。

③等待直至拓撲發現完成。

④被測控制器運行L2 Learning Switch應用。

⑤一定數量M的ARP_request消息通過Packet_in消息上送控制器。

⑥當控制器下發Packet_out消息結束之后，模擬交換機以一定速率通過Packet_in消息上送對應的ARP_Reply消息。

⑦記錄時間Tf為模擬交換機收到的一個Flow_mod消息的時間。

⑧記錄時間Tl為模擬交換機收到的最后一個Flow_mod消息的時間。

⑨確保所有的APR_reply消息都被控制器正確回應。

⑩求出被動流表下發速率R=M/(Tl-Tf)。

以不同的模擬交換機APR_reply上送速率迭代該測試。

在集群模式下迭代該測試。

5)測試結果。

①單點模式。在該測試中，一個模擬交換機連接被測控制器。測試工具被配置為以不同的速率上送Packet_in消息。在一些特定的配置下，被測控制器不能為每一條APR_Reply消息都下發兩條雙向連通的流表，但是實際流表下發數量還是被統計并作為有效數據。當上送速率在一定范圍之內時，被測控制器流表下發速率與上送速率呈正相關關系。當上送速率超過某一閾值之后，流表下發速率顯著下降，可認為此時被測控制器出現過載。APR消息的總數對流表下發的速率沒有影響。詳細測試結果請參照圖11。

圖11 被動流表下發速率單點模式測試結果

②集群模式。在集群模式，模擬交換機產生的每一個Packet_in消息都復制三份，分別發給集群中的三個節點，但只期望三個節點中的一個下發對應的兩條雙向連通的流表。在測試結果分析階段，發現有兩個或兩個以上的節點同時下發了相同的流表。換言之，一部分ARP_request/reply消息，控制器集群一共下發了四條或六條，互相重復的流表。這很大程度上是由于集群節點之間的同步進程未能正確地完成同步工作引起的。根據OpenFlow 1.3.4協議，如果Flow_mod消息中設定了CHECK_OVERLAP標志位，這還會導致交換機返回錯誤消息。所以針對集群模式的測試結果不能作為有效的結果。

3.5 被動Packet_out消息下發速率測試

1)測試目的。測量被測控制器最大被動Packet_out消息下發速率。

2)測試前提。①被測控制器可以分別運行于單點模式和集群模式。②被測控制器可以無差錯地支持拓撲發現功能。③默認的Table-miss流表的動作必須為上送控制器。④一個SDN應用需要在控制器之上運行，響應發送Packet_out的請求，并能以最大可能的速率下發Packet_out消息。

3)測試拓撲。如圖12所示。

圖12 被動Packet_out速率示例拓撲

4)測試方法。

①以單點模式啟動被測控制器。

②模擬交換機開始建立與被測控制器的OpenFlow 1.3連接。

③等待直至拓撲發現完成。

④被測控制器運行L2 Learning Switch應用。

⑤模擬交換機以一定速率，通過Packet_in消息上送一定數量M的ARP_request消息。

⑥記錄時間T1為模擬交換機收到第一個包含上送ARP_request的Packet_out消息的時間。

⑦記錄時間T2為模擬交換機收到的最后一個Packet_out消息的時間。

⑧確保所有的APR_request消息都被控制器以Packet_out消息下發。

⑨求出被動Packet_out消息下發速率R=M/(T2-T1)。

⑩以不同的模擬交換機APR_request上送速率迭代該測試。

在集群模式下迭代該測試。

5)測試結果。

①單點模式。在該測試中，一個模擬交換機連接被測控制器。APR_request消息總數被設定為恒定值(1K)，但會以不同的上送速率進行迭代測試。與上一個流表下發速率測試例不同，Packet_out消息下發速率并沒有隨著APR_request消息上送速率的增加而增加。在該測試例的結果分析階段，被測控制器在下發Packet_out消息時發現有大量的TCP重傳，使下發速率在上送速率超過200個/秒時出現了顯著下降。即便如此，實際的Packet_out下發速率也被認為是有效數據。詳細測試結果請參照圖13。

圖13 單點模式測試結果

②集群模式。在集群模式下，情況與上一測試例類似。每一個上送的ARP_request消息封裝于Packet_in消息之中，并復制三份，分別發給三個集群節點。每一個ARP_request消息都只期望有一個對應的Packet_out消息回應。但在該測試結果分析階段，某些ARP_request消息被發現由多個控制器節點分別回應了相同的Packet_out消息。換言之，在集群模式下，Packet_out消息的總數比上送的APR_request消息多(大約為其1.5倍)，某些APR_request被重復泛洪多次。這一現象，同樣是由控制器集群節點間同步機制不能正確完成工作所致。因該現象不但沒有正確完成所需的工作，同時又浪費了現有的網絡資源，所以其測試數據不能作為有效的測試結果。這也同樣是網絡用戶可能在部署SDN網路時遇到的問題。

4 總結

本文介紹了一些SDN控制器的性能測試方法及對測試結果的定量分析[4]。意在著重介紹測試方法及結果的呈現形式。這些測試例，都是依據網絡用戶的實際場景和需求制定的。一個開源SDN[5]控制器被選擇為示例被測控制器，以便提供定量的結果呈現方式和分析過程?？偨Y測試結果，被測控制器在單點模式下可以穩定運行，盡管一些方面的性能仍需要加強，但其已經可以作為一個小規模的SDN網絡的控制器。反觀集群模式，控制器節點間的同步機制還未成熟。這或將導致過重的管理開支甚至是控制行為錯誤，從而最終引發網絡失效。文中介紹的性能測試方法，任何需要獲得控制器確切性能參數的個人或組織都可以在實驗環境中復現。

本文介紹的性能測試例被認為是這項工作的一個起點。對每一個測試例來說，都可以添加更詳細的配置，同時新的測試例也將會不斷地被介紹進這項工作中來。當前，性能測試僅僅關注于南向接口，并且僅有一個特定版本的OpenFlow協議被提及。未來，北向接口的性能也將會納入測試范疇。每一項測試例都可以用于SDN用戶評估網絡的實際部署情況，并成為其控制器選型的指標與依據。

參考文獻

[1]Open Networking Foundation OpenFlow switch protocol 1.3.4[EB/OL].(2014-3-27)[2015-12-10].https://www.opennetworking.org/images/stories/downloads/sdnresources/onf-specifications/open fl ow/open fl ow-switchv1.3.4.pdf

[2]Open Networking Foundation Conformance Test Specification For OpenFlow Switch Specification v1.3.4 Basic Single Table Conformance Test Profile[EB/OL].(2015-4-15)[2015-12-10].https://www.opennetworking.org/images/stories/downloads/working-groups/OpenFlow1.3.4TestSpecification-Basic.pdf

[3]Team of Rivals: Aligning Technology & Market Drivers in an Open-Source Standards Testing Program[EB/OL].(2013-10-5)[2015-12-10].Rick Bauer Ron Milford Zhen Li https://www.opennetworking.org/images/stories/downloads/sdn-resources/IEEE-papers/team-of-rivals.pdf

[4]The Evolution of SDN and OpenFlow:A Standards Perspective[EB/OL].(2014-1-26)[2015-12-10].https://www.opennetworking.org/images/stories/downloads/sdn-resources/IEEE-papers/evolution-of-sdn-and-of.pdf

[5]When Open Source Meets Network Control Planes[EB/OL].(2012-12)[2015-12-10].https://www.opennetworking.org/images/stories/downloads/sdnresources/IEEE-papers/when-os-meets-nc-controlplanes.pdf