高 平,張 帆,張 東,翟飛龍
(1.中國航空無線電電子研究所,上海 200233; 2.西安交通大學 計算機科學與技術系,西安 710049;3.地理信息工程國家重點實驗室,西安 710054; 4.中國電子科技集團公司第三十二研究所,上海 201808)
云計算為越來越多的互聯網應用業務,如在線購物、網絡直播、數據存儲等提供強有力的技術支撐,云平臺則對計算、存儲網絡等資源進行統一的管理和調度[1]。云架構網絡作為云計算技術的基礎設施平臺,它的性能直接影響到企業提供的云服務質量。在網絡性能優化上,由于云計算業務種類和數量的急劇增長以及服務節點和網絡規模的不斷增大,節點流量模型的更加復雜,對網絡流量控制提出更高的要求。針對復雜業務模型和動態網絡環境,為了給各類業務提供高確定的與合理的服務質量(Quality of Service,QoS)保障,研究一種適用于云架構網絡的流量控制技術勢在必行。為此,本文提出一種基于軟件定義網絡(Software Defined Network,SDN)的高確定性流量控制方法。該方法將SDN集中優化控制、全網感知優點與多隊列調度機制、擁塞控制策略相結合,保證各類業務的帶寬和時延,同時使用全可編程SDN交換機并配合個性化的流表下發機制,動態調整業務傳輸帶寬和業務流等級。
隊列調度是網絡流量控制的重要技術,也是實現網絡QoS控制的重要手段。在工業界和學術界已經出現了許多隊列調度算法及其改進算法。文獻[2]提出的RR算法實現簡單,但不能滿足不同類業務對時延的需求。文獻[3]提出的PQ算法考慮到不同業務處理的優先級,但易使低優先級的業務流“餓死”,難以保證調度的公平性[4]。文獻[5]提出的WFQ算法在原理上比輪詢類調度算法優越,但實現較為復雜[6],傳統網絡交換設備的處理算法對用戶不透明,用戶無法做過多的干預,所以無法對相應的業務流做精確的帶寬保證。文獻[7]提出的CBWFQ算法允許用戶對流分類,并且考慮到公平性,但缺少對語音類業務的支持。文獻[8-9]提出的WRR算法和DWRR算法為每個隊列設置不同的權重值,保證了不同優先級隊列中的業務,但由于受到硬件資源的限制,只能將各類業務大致的劃分到有限的隊列中進行粗粒度管理,無法充分發揮算法的作用。此外,網絡中業務數量和流量分布經常變化,需要時常調整算法參數。傳統配置方式在頻繁操作下存在人力時間成本高、易引入誤操作的問題。除了RR、WRR這類輪循類算法外,另外提出了基于時延的調度算法,如EDF[10]、RCS[11]等,以及基于服務曲線理論的調度算法,如HFSC[12]、SCED[13]等,但這些算法很少能在商用交換設備得到部署。綜上,在傳統網絡中使用上述某種算法對云架構網絡進行流量控制存在以下問題:傳統隊列調度算法難以同時保證業務帶寬和時延保證;傳統網絡的隊列調度算法難以實現細粒度流量控制;靜態的參數配置不適合動態的網絡流量需求。可以看出,在傳統網絡中使用上述流量控制技術難以為云架構網絡中的業務提供高確定性的時延和帶寬保證。
基于對云架構網絡業務及傳統流量控制問題的分析,根據提出的SDN高確定性流量控制方法,本文設計一套高確定性流量控制系統,將SDN技術與傳統流量控制技術相結合,對云架構網絡中的各類應用業務全面感知,實現對網絡中的業務流集中化、實時化、精細化管理。
本文系統采用分層設計,總體分為應用層、控制層和網絡層。系統總體架構如圖1所示。

圖1 本文系統總體架構
系統總體架構由以下3個方面組成:
1)應用層。在該層上主要運行智能流量控制軟件,包括網絡態勢感知模塊和網絡流量配置模塊。網絡態勢感知模塊感知網絡情況并將網絡信息呈現給網絡管理者;網絡流量配置模塊根據網絡管理者下發的策略,區分不同的業務流,對不同級別的業務流下發不同的QoS保證策略。
2)控制層。在該層運行SDN控制器,系統采用輕量級的Ryu[14]作為SDN控制器。該層包括5個模塊:即端口信息收集模塊、流量信息收集模塊、主機管理模塊、交換機管理模塊和拓撲管理模塊,獲取網絡的資源以及網絡流量狀況。其中網絡的信息包括交換機、端口、主機的信息和網絡拓撲結構,以及基于流的流量統計信息和基于端口的流量統計信息。控制器根據這些信息下發流量策略,完成網絡的通信。
3)網絡層。該層由物理SDN交換機、虛擬SDN交換機以及終端主機組成,其中虛擬SDN交換機、虛擬主機以及兩者之間的鏈路由虛擬交換機生成軟件Mininet[15]生成。SDN交換機跟控制器使用OpenFlow作為南向協議進行交互,完成網絡狀態信息的提取和流表的下發。
網絡中的資源是有限的,當各種網絡應用為了滿足自身網絡資源的需求而搶奪網絡資源時,就會出現對服務質量的要求。服務質量主要包括傳輸帶寬、傳送時延、數據的丟包率和時延抖動等。網絡中不同業務對于服務質量有不同的要求。例如,有些業務流具有時效性,只有在規定的時限內完成才有價值,這類流對時延和時延抖動敏感,而有些業務流較大,期望在相對較短時間內完成,這類流對吞吐量和帶寬敏感。為了保證不同業務流需求,本文通過下面4種方法對業務流的Qos進行保障。
1)多隊列調度機制。考慮到DWRR比WFQ的計算復雜度更低,具有良好的公平性、各隊列間互不影響等優點,本文方法將DWRR引入到SDN控制器的多隊列調度中。根據應用層中為不同業務流定制的流表,將不同類別的流分配到相應的隊列中,隊列之間實現輪詢發送。為保證不同隊列的帶寬,利用了“赤字計數器”,并為不同隊列設置不同的權重值,即每次發送指定的字節數。
SDN下的多隊列調度流程如圖2所示。

圖2 SDN下的多隊列調度流程
利用SDN網絡全局控制的特性,為數據流分配合適的路徑。對于有時延要求的業務流,將根據時延的敏感程度為其隊列配置較大權重,控制器會根據其配置信息,在SDN交換機上預裝流表,避免Packet-In消息上報和流表下發導致的網絡時延。對于其他的業務流,網絡流量管理模塊會以網絡態勢感知模塊獲取的網絡中每條鏈路的剩余帶寬為權重,使用最短路徑算法為其計算一條轉發路徑,并為路徑上所有交換機下發相應的流表項,通過轉發端口權重值小的隊列進行轉發。同時,網絡流量管理模塊會實時地監控網絡的負載情況,當局部鏈路負載過重時,調整對時延無要求或對時延要求較小的業務流相關的流表,實現網絡的負載均衡。通過將SDN的全局感知的優勢與DWRR算法相結合,對業務流充分合理調度,實現同時對業務帶寬和時延的保證。
2)擁塞控制策略。在云架構網絡中流量分布具有高動態性和突發性,而且交換設備的緩存有限,很容易出現緩存溢出的擁塞丟包和流延遲變大的現象。為此,系統中摒棄TCP Reno,采用DCTCP協議,如圖3所示,利用顯示擁塞通知(Explicit Congestion Notification,ECN)控制了緩存隊列的長度,當擁塞發生時,對超過隊列擁塞標記閾值的數據包標記,接收端收到被標記的包后,通知源端對這類包限速。這樣可以在很少占用緩沖區的情況下實現高吞吐量傳輸。通過擁塞控制策略,進一步為網絡中高QoS業務流提供高確定性時延和帶寬保證。

圖3 擁塞控制策略
3)全可編程的SDN交換機。ONetSwitch是一款全可編程的SDN交換機,系統將其做為網絡層中物理SDN交換機。利用該交換機“軟件可編程、邏輯可重構、硬件可擴展”的特點,可以對交換機端口隊列數量合理配置,對業務數量大的端口多配隊列,對業務量數量小的端口少配隊列,使參與多隊列調度的業務流得到了更精細的劃分,在很大程度上增加了不同業務流之間的隔離程度,減小它們之間影響。ONetSwitch交換機的使用讓原有的隊列調度算法實現了細粒度流量控制。
4)個性化的流表下發機制。在傳統網絡流量QoS保障中,需要對網絡設備進行參數設置,配置的策略是靜態的。而且需要網絡管理員精通不同廠家設備的配置方式,對管理員業水平要求較高,配置過程耗時、易出錯。本文方法能夠讓網絡管理者根據業務流本身的性質通過網絡流量配置模塊,使控制器向交換機下發為不同的需求業務流定制的流表。流分類方法主要包含基于源IP地址、目的IP地址、源端口號、目的端口號、MAC地址、服務編碼(ToS)、基于MPLS包頭等。網絡流量配置模塊可以將上述分類方法任意組合并根據帶寬時延要求劃分業務流,不同類別的業務流可以隨時調整轉發隊列。個性化的流表下發機制實現了在動態的網絡環境下依然可以保證不同級別的QoS的。
云架構網絡流量控制系統原型分前端可視化界面、SDN控制器和SDN交換機3個部分。
前端可視化界面由JavaScript、HTML和CSS開發,運行在Apache服務器上,用于實現軟件和網絡管理員的可視化交互。前端界面一方面通過Restful接口與SDN控制器交互,將網絡拓撲信息、交換機信息、主機信息和相關的流量控制信息展示出來。其中,交換機信息包括交換機dpid、端口號、端口MAC;主機信息包括主機MAC、連接端口號等;流量控制信息包括交換機上的流表信息、流表匹配數據包條目以及端口帶寬等。另一方面,前端接收管理員的指令,根據源IP地址、目的IP地址、源端口號、目的端口號、協議號、流量的優先級和指定帶寬,為業務流添加或刪除流量策略,完成流量的細化控制。
云架構網絡流量控制系統原型如圖4所示。

圖4 云架構網絡流量控制系統原型
SDN控制器安裝在一臺服務器上,預裝基于Linux的Ryu控制器系統。在Ryu控制器下,開發了流量控制的應用程序,通過openflow協議與SDN交換交互,獲取全網資源信息,生成網絡拓撲,并根據流量信息和前端提供的流量策略為各類業務流計算最優傳輸路徑,向在相應路徑上的交換機下發流表信息,實現不同級別的QoS保證。同時,控制器與前端交互,向前端提供網絡拓撲信息、交換機信息、主機信息和相關的流量控制信息。
由于本文系統需要在云網絡下運行,既需要仿真的SDN網絡中具有一定規模的主機、網絡交換機和網絡鏈路,又要具有更好的真實性效果。因此,本文采用Mininet和物理交換機組成半實物環境來進行仿真。運用ONetSwitch交換機作為物理SDN交換機,利用Mininet生成若干虛擬SDN交換機和虛擬主機,Mininet宿主機上有多個網口,分別于控制器以及物理交換機相連。在宿主機上按照定義的網絡結構為網卡和Mininet中相應的虛擬交換機之間搭建網橋,將物理網絡中的流量導入Mininet構建的虛擬網絡中,同時將虛擬網絡的流量導入物理網絡中,實現網絡的互聯,即可構建半實物半虛擬的網絡環境,擴展網絡規模、并增強了實驗結果的真實性。
為了實現系統中的多隊列調度機制,在物理SDN交換機上,對原有的輪循調度功能進行修改,實現DWRR調度;在虛擬SDN交換機上,通過Linux流量控制器(Traffic Control,TC),根據控制器下發流量策略,將不同的業務流導入相應的隊列中,并為隊列設置指定帶寬,實現了多隊列的輪循調度,完成高QoS業務流帶寬和時延保證功能。為了實現擁塞控制策略,在物理SDN交換機上,實現ECN功能,即為每個隊列設置一個標記閾值,當實際隊列長度超過該值時,會對多出的數據包進行ECN標記;在mininet上創建拓撲時啟用ECN功能,使虛擬SDN交換機支持ECN功能,并且在虛擬終端上使用DCTCP協議。通過以上的方式可以進一步防止擁塞發生,減小業務流的時延。
本文系統能夠根據用戶需求區分關鍵業務流和背景流,為指定的關鍵業務流提供性能保證。為此,本文設計下面的實驗,觀察在多個流共存的擁塞狀況下,關鍵業務流的丟包率、時延抖動、平均時延以及隊列占用的情況。
實驗環境:該系統在由一臺安裝Mininet的服務器、ONetSwitch物理交換機以及安裝Ryu控制器PC機組成的網絡上運行,如圖5所示。其中,虛擬化SDN交換機數量10臺,物理SDN交換機端口數4個,物理SDN交換機每個端口數據傳輸帶寬為1 000 Mb/s。

圖5 實驗拓撲示意圖
在實驗中,觀察關鍵業務流在背景流的干擾下的性能指標。設置1條關鍵業務流與2條背景流。如圖5所示,背景流為TCP流量,分別從主機Host1和Host3發出,都到達主機Host0,一共占用1 000 Mb/s的帶寬,帶寬被完全占用。關鍵業務流從主機Host2到主機Host0,同樣是TCP流量,持續80 s,共計發送8.688 GB數據。在這種情況下,關鍵業務流與背景流在Switch1、Switch2和ONetSwitch 3個交換機上發生競爭。為了完全保證關鍵業務流的帶寬和時延,通過前端為3條流配置流量策略:將關鍵業務流的優先級設為最高,帶寬為1 000 Mb/s,2條背景流優先級分別設為中等和最低。
使用sockperf測試關鍵業務流時延,如圖6所示,99%的數據包的平均時延小于500 μs,所有的數據包平均時延為270 μs,小于2 ms。并使用iperf3測試關鍵業務流的丟包率,如表1所示,出現了4個重傳包,按照1 500 Byte的最大數據包大小進行計算:關鍵業務流丟包率=4/((8.688×1 0243)/1 500)≈6.4×10-7。為了測試關鍵業務流的時延抖動,將其改為UDP流,經過iperf測試發現時延抖動為0.144 ms。通過以上測試,可以看出本文系統能為指定的業務流提供可靠的性能保障。

圖6 數據包時延分布

間隔時間/s傳輸量/MB重傳數據包數0~101 116010~201 108120~301 116030~401 112140~501 113050~601 110160~701 111170~801 11000~808 8964
為了進一驗證擁塞控制策略的性能,采用與圖5相同的拓撲,鏈路帶寬為100 Mb/s,對比本文方法和傳統的TCP Reno協議下擁塞控制方法的效果,并觀察隊列的占用情況。主機Host1和主機Host2向主機Host0同時發送數據,在這種情況下,交換機Switch1發生擁塞。如圖7所示,與傳統TCP Reno相比,本文系統的擁塞控制方法可以使隊列中數據包個數降低到個位數,隊列占用率至少降低了80%,較大程度上避免了擁塞的發生。

圖7 隊列占用情況
本文提出一種基于SDN的云架構網絡高確定性流量控制方法。該方法將SDN集中優化控制、全網感知、靈活敏捷管理的優點與傳統多隊列調度機制相結合,并使用擁塞控制策略保證了業務流的帶寬和時延。運用全可編程交換機進行業務流的細粒度管理,再配合個性化的流表下發機制,實現了業務傳輸帶寬、路由和業務流等級動態調整。實驗結果表明,該方法實現對業務流的集中化、實時化、精細化管理,為云架構網絡中交換業務提供高確定性帶寬、路由和時延保障。下一步將繼續完善本文方法,并將其使用到更大的網絡范圍中進行驗證。