在線SDN控制器性能監控器設計與研究

黃序富，劉 川，林亦雷，金耀輝,，羅 萱

（1.上海交通大學區域光纖通信網與新型光通信系統國家重點實驗室 上海200240；2.中國電力科學研究院 北京100192；3.國網上海市電力公司信息通信公司 上海200120；4.上海交通大學網絡信息中心 上海200240）

1 引言

軟件定義網絡（software defined networking，SDN）是由美國Stanford（斯坦福）大學和加州大學Berkeley（伯克利）分校提出的OpenFlow[1]發展起來的。SDN作為新型網絡架構，通常認為具備3個特點[2]：第一，控制平面和轉發平面分離；第二，控制平面為集中式邏輯控制；第三，控制平面向上層提供應用程序接口 （application programming interface，API），以實現網絡業務自動化編排和部署。因為這些特性，SDN可以極大地提升網絡資源的利用率、簡化網絡管理、降低運營成本和促進網絡應用創新，已在工業界和學術界引起了廣泛的研究。目前，SDN技術的應用場景[2]也非常廣泛，包括企業網絡、數據中心、光網絡、無線網絡以及電力通信網絡等。經過大量研究和實踐，已對SDN技術和應用前景有較高評價。

同樣因為SDN的網絡架構，使得SDN控制器處于核心位置，控制器需要同時處理數據平面和上層應用的所有請求，因此控制器性能很可能成為瓶頸。首先，根據參考文獻[3]，在網絡規模或者網絡數據流量變大時，數據平面建立流表請求數變大，控制器性能很可能會成為網絡瓶頸；此外，根據參考文獻[4]，控制器響應時延會給數據流增加額外的時延，而有很多場景如在數據中心、電力通信網絡要求低時延；再者，控制器上層的網絡應用運行是否正常，依賴于控制器性能狀態是否正常。所以，控制器性能為非常重要的問題，這對于優化SDN也具有重要作用。目前，一般認為SDN控制器最主要的功能是控制數據平面的轉發，主要用以下3個指標衡量控制器性能[5]：響應時延，即控制器響應一條數據建立請求（packet-in）所需時間；吞吐量，控制器單位時間內響應packet-in數目；系統開銷，即控制器的CPU和內存開銷。

然而若要更加系統地研究控制器性能問題，需要應對多個挑戰。首先，控制器性能受多個因素影響，如運行設備、控制器轉發算法、控制器線程數目和數據平面拓撲復雜度；再者，如何定義和選擇合理的控制器性能指標，如通常使用平均響應時延，但僅僅用一個平均值過于簡單，它會抹去響應時延分布的細節情況，可能出現這種情況，大多數的響應時延很低，而只有少部分響應時延特別高，得出平均值也較高，認為控制器時延性能差，而這是不恰當的結論，因為此時大多數響應時延性能還是很低；最后，通常網絡流量處于動態變化中，引起的控制器負載也在一直動態變化，未知的負載也會對控制器性能造成影響。

基于控制器性能在SDN中的重要性，同時為了在動態負載情況下仍然可以獲取控制器準確的性能狀態，本文設計了一個在線軟件定義網絡控制器性能監控器框架，并定義了一個可準確衡量控制器性能的指標Lpdex（latency performance index）。根據設計的框架，本文在目前工業界和學術界都廣泛使用的一款控制器FloodLight[6]中做了控制器性能監控器的簡化實現。利用實現的控制器監控器，首先驗證該監控器具有可行性，然后研究分析新定義的控制器性能指標Lpdex的具體含義和參數的選擇，最后研究Lpdex是否可以在動態負載情況下準確地反映出控制器的性能狀態。經過實際評估分析，本文設計的控制器性能監控器和定義的性能指標Lpdex是可行的，能夠準確地表征控制器性能狀態，為控制器運營管理人員提供了一個直觀可靠的控制器性能狀態參考指標。最后，簡要討論性能監控器的其他擴展應用，比較目前已有的控制器性能研究工作，分析了本文工作的創新性。

2 方案設計

為實現可廣泛使用的在線軟件定義網絡控制器性能監控器，設計方案需要解決以下一些難點。

其一，可擴展性問題。目前單個控制器的性能總是有限的，業界有很多解決方案是使用多控制器。針對這個問題，本文設計方案采用的是分布式控制器性能監控模塊。第二個難點為，控制器性能監控器模塊對控制器性能影響最小化。因為監控模塊會對控制器添加一些額外的負載，對控制器性能會有部分影響，所以監控器模塊架構需要盡可能地最小化監控模塊影響。針對此問題，本文監控器設計框架為在控制器端僅添加分布式的原始性能信息采集客戶端，而后所有原始性能信息匯聚到一個集中式的信息管理中心。在管理中心內，對原始性能數據進行存儲、計算處理，提取出本文定義的性能監控指標Lpdex以及監控數據，也可以用于其他的一些應用（第4節）。本文設計的在線SDN控制器性能監控器的框架如圖1所示。

其中，本文控制器內設計的采集器采集的時延是控制器端的時延，如圖2所示，雖然對整個packet-in時延而言，這僅是其中的一部分，但本文仍僅測量這部分時延，主要基于以下幾點原因。首先，性能監控器最關注的是控制器，監控其內部時延更為重要，而且根據分析時延具體組成，控制器與交換機之間的傳輸時延一般為實際變化較小的部分，傳輸時延一般也較小，而控制器處理時延根據控制器性能變化會較大，這部分時延也占整個時延的大部分，這部分將在實驗部分具體驗證。

圖1 在線SDN控制器性能監控器框架

圖2 控制器端監控時延和交換機端監控時延

為了解決平均響應時延可能不能準確表征控制器性能狀態的問題，類似于Apdex[7]定義應用性能指標用于解決平均時延可能不能全面反映應用的時延性能，定義了一個Lpdex指標來衡量控制器時延性能。Lpdex的原理是在一定的時間內，基于統計的規律，把packet-in響應請求的響應時延劃分為3類：第1類，若是響應時延小于或等于自定義的目標響應時延（target latency），則為滿意的響應時延，可得1分；第2類，若是響應時延大于目標響應時延，但小于或等于4倍的目標響應時延，則為可容忍的響應時延，可得0.5分；第3類，若是響應時延大于4倍的目標響應時延，則歸為不能容忍的響應時延，得0分。Lpdex即在這段時間內得分總和除以這段時間內packet-in請求數目的總和（本文中的一段時間內，選擇的是秒級的單位時間粒度，若是粒度過細可以進行數據匯聚，得出更加粗粒度的Lpdex），如式（1）所示：

其中，Nsat為一段時間內滿意的響應時延數目，Ntol為一段時間內可容忍的響應時延數目，Nall為該段時間內packet-in請求數目的總和。由式（1）可知，Lpdex的取值范圍是0～1，其值越大，表示滿意的響應時延數目越多，交換機滿意度越高，控制器性能狀態越佳，反之則性能狀態越差。

3 實現與評估

根據上述控制器性能監控器的設計框架，在目前業內使用比較廣泛的一款開源控制器FloodLight中做了一個簡化的性能監控器原型實現。因為FloodLight控制器是功能模塊化的控制器，本文的實現方法即在內部添加了一個監控模塊。這個監控模塊的主要原理為：在packet-in請求進入時添加時間戳，完成處理后再記錄時間戳，這樣即可知道在控制器內處理一條packet-in請求的時延，即完成了控制器時延性能采集的功能；然后監控模塊分別統計每秒鐘滿意響應時延的數目、可容忍響應時延的數目、不可容忍響應時延的數目和請求總數等參數。根據這些數據即可計算出定義的性能參數Lpdex和其他的一些性能參數。具體修改的FloodLight控制器代碼已開源在github[8]中。

根據FloodLight實現的性能監控器，搭建了一個實驗平臺進行控制器監控器合理性驗證、Lpdex的具體含義與目標響應時延的設定和動態負載情況下的Lpdex 3個實驗。其中FloodLight控制器運行在雙核CPU和4 GB內存的虛擬機內，虛擬機操作系統為Ubuntu14.04，Java版本為1.7。具體實驗配置和結果如下文所述。

3.1 控制器監控器合理性驗證

關于在交換機端測量packet-in的響應時延，目前已有Cbench[9]工具可以很方便地測試出。Cbench模擬的測試環境如圖3所示，其工作原理為模擬多個OpenFlow交換機向控制器發送packet-in請求，然后在交換機上統計請求所需時延和單位時間內收到的響應數目。

使用Cbench可以方便地測量出交換機側的響應時延，使用本文的性能監控器可測試出在控制器側的響應時延。最終兩者的響應時延和比例結果如圖4所示。

圖3 Cbench模擬環境

由圖4可知，兩種響應時延都是在啟動過程中逐漸降低的，而且在控制器側測量的響應時延比較接近從交換機側測量的響應時延，經過多次測量，在控制器端測量的平均響應時延占整個時延的60%以上（圖4中的具體數值為65.17%），由此驗證了在控制器端測量響應時延是可行的。

3.2 Lpdex的具體含義與目標響應時延的設定

在驗證了控制器端測量響應時延具有實際意義后，還需要分析自定義的控制器性能參數Lpdex的具體含義以及其參數目標響應時延的設定。類似驗證控制器性能監控的有效性，使用Cbench發送packet-in請求，然后在控制器中統計10 s內經過控制器的響應時延，觀測其CDF，根據設定的不同目標響應時延，計算Lpdex。具體的響應時延的CDF和不同目標響應時延Lpdex值的設定如圖5所示。

圖4 交換機側響應時延和控制器側響應時延

圖5 響應時延的CDF圖和不同目標參數的Lpdex

根據響應時延的CDF可知，Lpdex總是根據目標參數把CDF劃分為3部分，各個部分分別被賦予不同的權重即可得出值，所以Lpdex實際上是簡化的加權CDF。Lpdex相比于直接的平均值，仍然部分保留統計分布的規律，因此比僅使用平均值更能反映出總體規律，可更加準確地反映控制器性能的狀態。另外，目標參數的設定可根據具體的要求設定，如有嚴格的響應時延要求，則可以設定較小的值，反之可設定更大的值。即使設定好初始值后，具體的值也可以根據實際情況在控制器性能監控器中做反饋調節。其中一種參考調節方式為對數據流體驗的時延采樣調整目標參數，例如采樣的數據流響應時延為滿意范圍，而Lpdex卻較低，則可以適當加大目標參數，具體的定量關系不在本文的研究范圍。至于初始值，可以根據實際需求設定一個大概的值，例如，若在某些場景下，流可容忍的額外時延很低，則定義目標響應時延為較小的值，本文初步設定目標響應時延參數為25μs，后文也使用這個目標響應參數。

3.3 動態負載情況下的Lpdex

在線監控器總是工作于動態負載情況下，必須分析其能否準確反映出不同負載情況下的控制器性能狀態。由于Cbench不能夠定量控制發送packet-in請求的速率，本文將控制主機定量地發送大量ARP請求，從而在交換機側觸發一定量的packet-in請求，實現不同負載的情況。為了模擬OpenFlow網絡，Mininet[10]是一個非常不錯的選擇，本文模擬的簡單樹型結構數據平面如圖6所示。

圖6 Mininet模擬OpenFlow網絡

在模擬完成OpenFlow網絡之后，在主機端每秒定量地產生ARP請求，根據產生的量的不同對控制器施加不同的負載，圖7為對控制器動態地施加負載壓力時，性能監控器Lpdex的時序變化情況。圖8為控制器在不同ARP負載下的Lpdex箱線圖統計以及處理packet-in請求吞吐量的箱線圖統計。

從圖7可以明顯看出，在一定負載范圍內，Lpdex雖然會有些波動變化，但都保持在較高的水平，而當負載達到某一個臨界值時，控制器先盡力處理packet-in請求，若請求負載一直很高，則會出現大量的響應時延變大，Lpdex將會急劇降低，也反映出控制器時延性能快速下降。若這時除去負載，根據Lpdex的請求可以看出其控制器時延性能也逐漸恢復到較高的水平。根據圖8可知，Lpdex和吞吐量具有相似的規律，吞吐量驗證了Lpdex隨負載變化的規律。由此，本文的在線控制器性能監控器及Lpdex可以在動態負載情況下，準確地表征控制器的時延性能狀態變化，Lpdex為性能監控的可參考指標。

4 相關研究工作

本文設計的在線SDN控制器性能監控器除了可使用Lpdex準確地反映當前控制器的時延性能外，還可有其他的一些應用。例如，packet-in限流反饋功能，在監控器中統計發現某臺交換機或某臺主機發送packet-in請求的速率過快，可對該端口或主機進行packet-in限流；packet-in的DDoS攻擊或其他異常檢測功能，若統計發現在一段較為平穩正常的狀態，突然有某些主機持續不斷地發送大量的packet-in請求，則可以對這些請求進行分析，監測其是否為DDoS攻擊源或是否有其他異常情況；控制器線程或實例自動擴展功能，在正常的一些請求情況下，工作負載壓力較大時，Lpdex和其他的一些性能指標變差，可以考慮自動擴展控制器的線程或者添加控制器實例，或考慮能否增加主機的CPU和內存資源等，這樣可使得控制器保持較佳的時延性能。

圖7 不同ARP負載Lpdex變化時序

圖8 不同ARP負載的Lpdex和吞吐量

本文設計的在線SDN控制器性能監控器和控制器性能監控指標Lpdex都是針對通用的SDN控制器框架，在SDN中具有廣泛的應用場景。例如，該設計系統可運用在SDN架構的電力通信網絡中。電力通信網絡作為智能電網的基礎支撐平臺，對于整個智能電網正常安全運行具有重要作用。運用SDN架構的電力通信網絡可以解決以傳統SDH技術為基礎的電力通信網絡無法滿足其“流量可觀可控，資源動態分配”的需求。在運用SDN架構的電力通信網絡中，SDN控制器性能狀態對于電力網絡正常安全運行至關重要，使用本文設計的在線SDN控制器性能監控器和控制器監控指標Lpdex，即可準確地反映控制器在動態負載情況下的性能狀態。

基于控制器性能的重要性，目前學術界也有關于控制器性能方面的相關研究工作。目前關于控制器性能的主要研究工作有參考文獻[5,10～13]。參考文獻[5]中，主要就控制器的吞吐量和響應時延性能做了初步的研究，對NOX控制器提出改進，提出其多線程版本，并設計了控制器性能的測量工具Cbench；參考文獻[11]中建立OpenFlow排隊論模型，然后分析數據分組在系統中的逗留時間和分組丟失概率；參考文獻[12]主要研究控制器的設計架構對控制器性能的影響，從而可以在控制器系統架構設計上提供指導；參考文獻[13]主要使用網絡微積分從理論上研究了一個分級部署控制器的性能，從數學模型中獲得根控制器的緩存大小和上界值；參考文獻[14]中，為測量更加細粒度（到每個交換機級別）的控制器響應時延性能，設計了類似于Cbench的測量工具OPCBenchmark并驗證了其有效性。本文與這些工作的主要不同點有兩點：其一，本文為研究控制器性能，從在線監控的角度出發，可以實時地獲取動態負載下的控制器性能狀態，而非從理論上或者離線分析控制器的性能；其二，相關的研究工作對控制器性能的研究指標較多的都是控制器的吞吐量和平均響應時延，而本文定義了一個性能衡量參數Lpdex，可更加準確地反映控制器性能狀態。

5 結束語

本文基于軟件定義網絡控制器性能，設計了一個在線的SDN控制器性能監控器，并定義了一個比平均響應時延更能反映群體響應時延性能的指標Lpdex。為了克服性能監控器的擴展問題和對原控制器最小化性能的影響，設計的監控器采用分布式采集模塊和集中式性能信息處理模塊，用以收集控制器性能信息。根據這個框架，本文在FloodLight控制器中實現了一個簡化的性能監控器，并在監控器中定義了Lpdex用于在線衡量控制器時延性能。最后，在實現的監控器中，經過多個實驗評估分析，驗證了設計的控制器性能監控器和定義的Lpdex具有實際意義，針對不同的負載壓力，可在線準確地衡量控制器的響應時延性能。

1 McKeown N,Anderson T,Balakrishnan H,et al.OpenFlow:enabling innovation in campus networks.ACM SIGCOMM Computer Communication Review,2008,38(2):69～74

2 Mendonca M,Nunes B A A,Nguyen X N,et al.A survey of software-defined networking:past,present,and future of programmable networks.IEEE Communications Society,Institute of Electrical and Electronics Engineers(IEEE),2014,16(3):1617～1634

3 Kandula S,Sengupta S,Greenberg A,et al.The nature of data center traffic:measurements & analysis.Proceedings of Internet Measurement Conference,Chicago,Illinois,2009

4 Benson T,Akella A,Maltz D A.Network traffic characteristics of data centers in the wild.Proceedings ofInternet Measurement Conference,Melbourne,Australia,2010

5 Tootoonchian A,Gorbunov S,Ganjali Y,et al.On controller performance in software-defined networks.Proceedings of USENIX Workshop on Hot Topics in Management of Internet,Cloud,and Enterprise Networks and Services(Hot-ICE),San Jose,CA,2012

6 FloodLight.FloodLight controller.http://floodlight.openflowhub.org/

7 Apdex.http://en.wikipedia.org/wiki/Apdex

8 Github code.https://github.com/rainmetersjtu/floodlight

9 Cbench.http://archive.openflow.org/wk/index.php/Oflops

10 Handigol N,Heller B,Jeyakumar V,et al.Reproducible network experiments using container-based emulation.Proceedings of the 8th International Conference on Emerging Networking Experiments and Technologies,Guilin,China,2012

11 Jarschel M,Oechsner S,Schlosser D,et al.Modeling and performance evaluation of an OpenFlow architecture.Proceedings of the 23rd International Teletraffic Congress International Teletraffic Congress,San Francisco,USA,2011

12 Shah S A,Faiz J,Farooq M,et al.An architectural evaluation of SDN controllers.Proceedings of 2013 IEEE International Conference on Communications(ICC),London,UK,2013

13 Azodolmolky S,Wieder P,Yahyapour R.Performance evaluation of a scalable software-defined networking deployment.Proceedings of 2013 Second European Workshop on Software Defined Networks(EWSDN),Singapore,2013

14 Jarschel M,Lehrieder F,Magyari Z,et al.A flexible OpenFlow-controller benchmark.Proceedings of 2012 European Workshop on Software Defined Networking(EWSDN),San Diego,CA,USA,2012