高 平,張 帆,張 東,翟飛龍

(1.中國航空無線電電子研究所,上海 200233; 2.西安交通大學(xué) 計算機科學(xué)與技術(shù)系,西安 710049;3.地理信息工程國家重點實驗室,西安 710054; 4.中國電子科技集團公司第三十二研究所,上海 201808)

0 概述

云計算為越來越多的互聯(lián)網(wǎng)應(yīng)用業(yè)務(wù),如在線購物、網(wǎng)絡(luò)直播、數(shù)據(jù)存儲等提供強有力的技術(shù)支撐,云平臺則對計算、存儲網(wǎng)絡(luò)等資源進行統(tǒng)一的管理和調(diào)度[1]。云架構(gòu)網(wǎng)絡(luò)作為云計算技術(shù)的基礎(chǔ)設(shè)施平臺,它的性能直接影響到企業(yè)提供的云服務(wù)質(zhì)量。在網(wǎng)絡(luò)性能優(yōu)化上,由于云計算業(yè)務(wù)種類和數(shù)量的急劇增長以及服務(wù)節(jié)點和網(wǎng)絡(luò)規(guī)模的不斷增大,節(jié)點流量模型的更加復(fù)雜,對網(wǎng)絡(luò)流量控制提出更高的要求。針對復(fù)雜業(yè)務(wù)模型和動態(tài)網(wǎng)絡(luò)環(huán)境,為了給各類業(yè)務(wù)提供高確定的與合理的服務(wù)質(zhì)量(Quality of Service,QoS)保障,研究一種適用于云架構(gòu)網(wǎng)絡(luò)的流量控制技術(shù)勢在必行。為此,本文提出一種基于軟件定義網(wǎng)絡(luò)(Software Defined Network,SDN)的高確定性流量控制方法。該方法將SDN集中優(yōu)化控制、全網(wǎng)感知優(yōu)點與多隊列調(diào)度機制、擁塞控制策略相結(jié)合,保證各類業(yè)務(wù)的帶寬和時延,同時使用全可編程SDN交換機并配合個性化的流表下發(fā)機制,動態(tài)調(diào)整業(yè)務(wù)傳輸帶寬和業(yè)務(wù)流等級。

1 相關(guān)研究

隊列調(diào)度是網(wǎng)絡(luò)流量控制的重要技術(shù),也是實現(xiàn)網(wǎng)絡(luò)QoS控制的重要手段。在工業(yè)界和學(xué)術(shù)界已經(jīng)出現(xiàn)了許多隊列調(diào)度算法及其改進算法。文獻[2]提出的RR算法實現(xiàn)簡單,但不能滿足不同類業(yè)務(wù)對時延的需求。文獻[3]提出的PQ算法考慮到不同業(yè)務(wù)處理的優(yōu)先級,但易使低優(yōu)先級的業(yè)務(wù)流“餓死”,難以保證調(diào)度的公平性[4]。文獻[5]提出的WFQ算法在原理上比輪詢類調(diào)度算法優(yōu)越,但實現(xiàn)較為復(fù)雜[6],傳統(tǒng)網(wǎng)絡(luò)交換設(shè)備的處理算法對用戶不透明,用戶無法做過多的干預(yù),所以無法對相應(yīng)的業(yè)務(wù)流做精確的帶寬保證。文獻[7]提出的CBWFQ算法允許用戶對流分類,并且考慮到公平性,但缺少對語音類業(yè)務(wù)的支持。文獻[8-9]提出的WRR算法和DWRR算法為每個隊列設(shè)置不同的權(quán)重值,保證了不同優(yōu)先級隊列中的業(yè)務(wù),但由于受到硬件資源的限制,只能將各類業(yè)務(wù)大致的劃分到有限的隊列中進行粗粒度管理,無法充分發(fā)揮算法的作用。此外,網(wǎng)絡(luò)中業(yè)務(wù)數(shù)量和流量分布經(jīng)常變化,需要時常調(diào)整算法參數(shù)。傳統(tǒng)配置方式在頻繁操作下存在人力時間成本高、易引入誤操作的問題。除了RR、WRR這類輪循類算法外,另外提出了基于時延的調(diào)度算法,如EDF[10]、RCS[11]等,以及基于服務(wù)曲線理論的調(diào)度算法,如HFSC[12]、SCED[13]等,但這些算法很少能在商用交換設(shè)備得到部署。綜上,在傳統(tǒng)網(wǎng)絡(luò)中使用上述某種算法對云架構(gòu)網(wǎng)絡(luò)進行流量控制存在以下問題:傳統(tǒng)隊列調(diào)度算法難以同時保證業(yè)務(wù)帶寬和時延保證;傳統(tǒng)網(wǎng)絡(luò)的隊列調(diào)度算法難以實現(xiàn)細(xì)粒度流量控制;靜態(tài)的參數(shù)配置不適合動態(tài)的網(wǎng)絡(luò)流量需求。可以看出,在傳統(tǒng)網(wǎng)絡(luò)中使用上述流量控制技術(shù)難以為云架構(gòu)網(wǎng)絡(luò)中的業(yè)務(wù)提供高確定性的時延和帶寬保證。

2 云架構(gòu)網(wǎng)絡(luò)流量控制方法

基于對云架構(gòu)網(wǎng)絡(luò)業(yè)務(wù)及傳統(tǒng)流量控制問題的分析,根據(jù)提出的SDN高確定性流量控制方法,本文設(shè)計一套高確定性流量控制系統(tǒng),將SDN技術(shù)與傳統(tǒng)流量控制技術(shù)相結(jié)合,對云架構(gòu)網(wǎng)絡(luò)中的各類應(yīng)用業(yè)務(wù)全面感知,實現(xiàn)對網(wǎng)絡(luò)中的業(yè)務(wù)流集中化、實時化、精細(xì)化管理。

2.1 總體架構(gòu)

本文系統(tǒng)采用分層設(shè)計,總體分為應(yīng)用層、控制層和網(wǎng)絡(luò)層。系統(tǒng)總體架構(gòu)如圖1所示。

圖1 本文系統(tǒng)總體架構(gòu)

系統(tǒng)總體架構(gòu)由以下3個方面組成:

1)應(yīng)用層。在該層上主要運行智能流量控制軟件,包括網(wǎng)絡(luò)態(tài)勢感知模塊和網(wǎng)絡(luò)流量配置模塊。網(wǎng)絡(luò)態(tài)勢感知模塊感知網(wǎng)絡(luò)情況并將網(wǎng)絡(luò)信息呈現(xiàn)給網(wǎng)絡(luò)管理者;網(wǎng)絡(luò)流量配置模塊根據(jù)網(wǎng)絡(luò)管理者下發(fā)的策略,區(qū)分不同的業(yè)務(wù)流,對不同級別的業(yè)務(wù)流下發(fā)不同的QoS保證策略。

2)控制層。在該層運行SDN控制器,系統(tǒng)采用輕量級的Ryu[14]作為SDN控制器。該層包括5個模塊:即端口信息收集模塊、流量信息收集模塊、主機管理模塊、交換機管理模塊和拓?fù)涔芾砟K,獲取網(wǎng)絡(luò)的資源以及網(wǎng)絡(luò)流量狀況。其中網(wǎng)絡(luò)的信息包括交換機、端口、主機的信息和網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu),以及基于流的流量統(tǒng)計信息和基于端口的流量統(tǒng)計信息?？刂破鞲鶕?jù)這些信息下發(fā)流量策略,完成網(wǎng)絡(luò)的通信。

3)網(wǎng)絡(luò)層。該層由物理SDN交換機、虛擬SDN交換機以及終端主機組成,其中虛擬SDN交換機、虛擬主機以及兩者之間的鏈路由虛擬交換機生成軟件Mininet[15]生成。SDN交換機跟控制器使用OpenFlow作為南向協(xié)議進行交互,完成網(wǎng)絡(luò)狀態(tài)信息的提取和流表的下發(fā)。

2.2 高確定流量控制方法

網(wǎng)絡(luò)中的資源是有限的,當(dāng)各種網(wǎng)絡(luò)應(yīng)用為了滿足自身網(wǎng)絡(luò)資源的需求而搶奪網(wǎng)絡(luò)資源時,就會出現(xiàn)對服務(wù)質(zhì)量的要求。服務(wù)質(zhì)量主要包括傳輸帶寬、傳送時延、數(shù)據(jù)的丟包率和時延抖動等。網(wǎng)絡(luò)中不同業(yè)務(wù)對于服務(wù)質(zhì)量有不同的要求。例如,有些業(yè)務(wù)流具有時效性,只有在規(guī)定的時限內(nèi)完成才有價值,這類流對時延和時延抖動敏感,而有些業(yè)務(wù)流較大,期望在相對較短時間內(nèi)完成,這類流對吞吐量和帶寬敏感。為了保證不同業(yè)務(wù)流需求,本文通過下面4種方法對業(yè)務(wù)流的Qos進行保障。

1)多隊列調(diào)度機制?？紤]到DWRR比WFQ的計算復(fù)雜度更低,具有良好的公平性、各隊列間互不影響等優(yōu)點,本文方法將DWRR引入到SDN控制器的多隊列調(diào)度中。根據(jù)應(yīng)用層中為不同業(yè)務(wù)流定制的流表,將不同類別的流分配到相應(yīng)的隊列中,隊列之間實現(xiàn)輪詢發(fā)送。為保證不同隊列的帶寬,利用了“赤字計數(shù)器”,并為不同隊列設(shè)置不同的權(quán)重值,即每次發(fā)送指定的字節(jié)數(shù)。

SDN下的多隊列調(diào)度流程如圖2所示。

圖2 SDN下的多隊列調(diào)度流程

利用SDN網(wǎng)絡(luò)全局控制的特性,為數(shù)據(jù)流分配合適的路徑。對于有時延要求的業(yè)務(wù)流,將根據(jù)時延的敏感程度為其隊列配置較大權(quán)重,控制器會根據(jù)其配置信息,在SDN交換機上預(yù)裝流表,避免Packet-In消息上報和流表下發(fā)導(dǎo)致的網(wǎng)絡(luò)時延。對于其他的業(yè)務(wù)流,網(wǎng)絡(luò)流量管理模塊會以網(wǎng)絡(luò)態(tài)勢感知模塊獲取的網(wǎng)絡(luò)中每條鏈路的剩余帶寬為權(quán)重,使用最短路徑算法為其計算一條轉(zhuǎn)發(fā)路徑,并為路徑上所有交換機下發(fā)相應(yīng)的流表項,通過轉(zhuǎn)發(fā)端口權(quán)重值小的隊列進行轉(zhuǎn)發(fā)。同時,網(wǎng)絡(luò)流量管理模塊會實時地監(jiān)控網(wǎng)絡(luò)的負(fù)載情況,當(dāng)局部鏈路負(fù)載過重時,調(diào)整對時延無要求或?qū)r延要求較小的業(yè)務(wù)流相關(guān)的流表,實現(xiàn)網(wǎng)絡(luò)的負(fù)載均衡。通過將SDN的全局感知的優(yōu)勢與DWRR算法相結(jié)合,對業(yè)務(wù)流充分合理調(diào)度,實現(xiàn)同時對業(yè)務(wù)帶寬和時延的保證。

2)擁塞控制策略。在云架構(gòu)網(wǎng)絡(luò)中流量分布具有高動態(tài)性和突發(fā)性,而且交換設(shè)備的緩存有限,很容易出現(xiàn)緩存溢出的擁塞丟包和流延遲變大的現(xiàn)象。為此,系統(tǒng)中摒棄TCP Reno,采用DCTCP協(xié)議,如圖3所示,利用顯示擁塞通知(Explicit Congestion Notification,ECN)控制了緩存隊列的長度,當(dāng)擁塞發(fā)生時,對超過隊列擁塞標(biāo)記閾值的數(shù)據(jù)包標(biāo)記,接收端收到被標(biāo)記的包后,通知源端對這類包限速。這樣可以在很少占用緩沖區(qū)的情況下實現(xiàn)高吞吐量傳輸。通過擁塞控制策略,進一步為網(wǎng)絡(luò)中高QoS業(yè)務(wù)流提供高確定性時延和帶寬保證。

圖3 擁塞控制策略

3)全可編程的SDN交換機。ONetSwitch是一款全可編程的SDN交換機,系統(tǒng)將其做為網(wǎng)絡(luò)層中物理SDN交換機。利用該交換機“軟件可編程、邏輯可重構(gòu)、硬件可擴展”的特點,可以對交換機端口隊列數(shù)量合理配置,對業(yè)務(wù)數(shù)量大的端口多配隊列,對業(yè)務(wù)量數(shù)量小的端口少配隊列,使參與多隊列調(diào)度的業(yè)務(wù)流得到了更精細(xì)的劃分,在很大程度上增加了不同業(yè)務(wù)流之間的隔離程度,減小它們之間影響。ONetSwitch交換機的使用讓原有的隊列調(diào)度算法實現(xiàn)了細(xì)粒度流量控制。

4)個性化的流表下發(fā)機制。在傳統(tǒng)網(wǎng)絡(luò)流量QoS保障中,需要對網(wǎng)絡(luò)設(shè)備進行參數(shù)設(shè)置,配置的策略是靜態(tài)的。而且需要網(wǎng)絡(luò)管理員精通不同廠家設(shè)備的配置方式,對管理員業(yè)水平要求較高,配置過程耗時、易出錯。本文方法能夠讓網(wǎng)絡(luò)管理者根據(jù)業(yè)務(wù)流本身的性質(zhì)通過網(wǎng)絡(luò)流量配置模塊,使控制器向交換機下發(fā)為不同的需求業(yè)務(wù)流定制的流表。流分類方法主要包含基于源IP地址、目的IP地址、源端口號、目的端口號、MAC地址、服務(wù)編碼(ToS)、基于MPLS包頭等。網(wǎng)絡(luò)流量配置模塊可以將上述分類方法任意組合并根據(jù)帶寬時延要求劃分業(yè)務(wù)流,不同類別的業(yè)務(wù)流可以隨時調(diào)整轉(zhuǎn)發(fā)隊列。個性化的流表下發(fā)機制實現(xiàn)了在動態(tài)的網(wǎng)絡(luò)環(huán)境下依然可以保證不同級別的QoS的。

3 系統(tǒng)實現(xiàn)

云架構(gòu)網(wǎng)絡(luò)流量控制系統(tǒng)原型分前端可視化界面、SDN控制器和SDN交換機3個部分。

前端可視化界面由JavaScript、HTML和CSS開發(fā),運行在Apache服務(wù)器上,用于實現(xiàn)軟件和網(wǎng)絡(luò)管理員的可視化交互。前端界面一方面通過Restful接口與SDN控制器交互,將網(wǎng)絡(luò)拓?fù)湫畔?、交換機信息、主機信息和相關(guān)的流量控制信息展示出來。其中,交換機信息包括交換機dpid、端口號、端口MAC;主機信息包括主機MAC、連接端口號等;流量控制信息包括交換機上的流表信息、流表匹配數(shù)據(jù)包條目以及端口帶寬等。另一方面,前端接收管理員的指令,根據(jù)源IP地址、目的IP地址、源端口號、目的端口號、協(xié)議號、流量的優(yōu)先級和指定帶寬,為業(yè)務(wù)流添加或刪除流量策略,完成流量的細(xì)化控制。

云架構(gòu)網(wǎng)絡(luò)流量控制系統(tǒng)原型如圖4所示。

圖4 云架構(gòu)網(wǎng)絡(luò)流量控制系統(tǒng)原型

SDN控制器安裝在一臺服務(wù)器上,預(yù)裝基于Linux的Ryu控制器系統(tǒng)。在Ryu控制器下,開發(fā)了流量控制的應(yīng)用程序,通過openflow協(xié)議與SDN交換交互,獲取全網(wǎng)資源信息,生成網(wǎng)絡(luò)拓?fù)?并根據(jù)流量信息和前端提供的流量策略為各類業(yè)務(wù)流計算最優(yōu)傳輸路徑,向在相應(yīng)路徑上的交換機下發(fā)流表信息,實現(xiàn)不同級別的QoS保證。同時,控制器與前端交互,向前端提供網(wǎng)絡(luò)拓?fù)湫畔?、交換機信息、主機信息和相關(guān)的流量控制信息。

由于本文系統(tǒng)需要在云網(wǎng)絡(luò)下運行,既需要仿真的SDN網(wǎng)絡(luò)中具有一定規(guī)模的主機、網(wǎng)絡(luò)交換機和網(wǎng)絡(luò)鏈路,又要具有更好的真實性效果。因此,本文采用Mininet和物理交換機組成半實物環(huán)境來進行仿真。運用ONetSwitch交換機作為物理SDN交換機,利用Mininet生成若干虛擬SDN交換機和虛擬主機,Mininet宿主機上有多個網(wǎng)口,分別于控制器以及物理交換機相連。在宿主機上按照定義的網(wǎng)絡(luò)結(jié)構(gòu)為網(wǎng)卡和Mininet中相應(yīng)的虛擬交換機之間搭建網(wǎng)橋,將物理網(wǎng)絡(luò)中的流量導(dǎo)入Mininet構(gòu)建的虛擬網(wǎng)絡(luò)中,同時將虛擬網(wǎng)絡(luò)的流量導(dǎo)入物理網(wǎng)絡(luò)中,實現(xiàn)網(wǎng)絡(luò)的互聯(lián),即可構(gòu)建半實物半虛擬的網(wǎng)絡(luò)環(huán)境,擴展網(wǎng)絡(luò)規(guī)模、并增強了實驗結(jié)果的真實性。

為了實現(xiàn)系統(tǒng)中的多隊列調(diào)度機制,在物理SDN交換機上,對原有的輪循調(diào)度功能進行修改,實現(xiàn)DWRR調(diào)度;在虛擬SDN交換機上,通過Linux流量控制器(Traffic Control,TC),根據(jù)控制器下發(fā)流量策略,將不同的業(yè)務(wù)流導(dǎo)入相應(yīng)的隊列中,并為隊列設(shè)置指定帶寬,實現(xiàn)了多隊列的輪循調(diào)度,完成高QoS業(yè)務(wù)流帶寬和時延保證功能。為了實現(xiàn)擁塞控制策略,在物理SDN交換機上,實現(xiàn)ECN功能,即為每個隊列設(shè)置一個標(biāo)記閾值,當(dāng)實際隊列長度超過該值時,會對多出的數(shù)據(jù)包進行ECN標(biāo)記;在mininet上創(chuàng)建拓?fù)鋾r啟用ECN功能,使虛擬SDN交換機支持ECN功能,并且在虛擬終端上使用DCTCP協(xié)議。通過以上的方式可以進一步防止擁塞發(fā)生,減小業(yè)務(wù)流的時延。

4 系統(tǒng)評估及結(jié)果分析

本文系統(tǒng)能夠根據(jù)用戶需求區(qū)分關(guān)鍵業(yè)務(wù)流和背景流,為指定的關(guān)鍵業(yè)務(wù)流提供性能保證。為此,本文設(shè)計下面的實驗,觀察在多個流共存的擁塞狀況下,關(guān)鍵業(yè)務(wù)流的丟包率、時延抖動、平均時延以及隊列占用的情況。

實驗環(huán)境:該系統(tǒng)在由一臺安裝Mininet的服務(wù)器、ONetSwitch物理交換機以及安裝Ryu控制器PC機組成的網(wǎng)絡(luò)上運行,如圖5所示。其中,虛擬化SDN交換機數(shù)量10臺,物理SDN交換機端口數(shù)4個,物理SDN交換機每個端口數(shù)據(jù)傳輸帶寬為1 000 Mb/s。

圖5 實驗拓?fù)涫疽鈭D

在實驗中,觀察關(guān)鍵業(yè)務(wù)流在背景流的干擾下的性能指標(biāo)。設(shè)置1條關(guān)鍵業(yè)務(wù)流與2條背景流。如圖5所示,背景流為TCP流量,分別從主機Host1和Host3發(fā)出,都到達主機Host0,一共占用1 000 Mb/s的帶寬,帶寬被完全占用。關(guān)鍵業(yè)務(wù)流從主機Host2到主機Host0,同樣是TCP流量,持續(xù)80 s,共計發(fā)送8.688 GB數(shù)據(jù)。在這種情況下,關(guān)鍵業(yè)務(wù)流與背景流在Switch1、Switch2和ONetSwitch 3個交換機上發(fā)生競爭。為了完全保證關(guān)鍵業(yè)務(wù)流的帶寬和時延,通過前端為3條流配置流量策略:將關(guān)鍵業(yè)務(wù)流的優(yōu)先級設(shè)為最高,帶寬為1 000 Mb/s,2條背景流優(yōu)先級分別設(shè)為中等和最低。

使用sockperf測試關(guān)鍵業(yè)務(wù)流時延,如圖6所示,99%的數(shù)據(jù)包的平均時延小于500 μs,所有的數(shù)據(jù)包平均時延為270 μs,小于2 ms。并使用iperf3測試關(guān)鍵業(yè)務(wù)流的丟包率,如表1所示,出現(xiàn)了4個重傳包,按照1 500 Byte的最大數(shù)據(jù)包大小進行計算:關(guān)鍵業(yè)務(wù)流丟包率=4/((8.688×1 0243)/1 500)≈6.4×10-7。為了測試關(guān)鍵業(yè)務(wù)流的時延抖動,將其改為UDP流,經(jīng)過iperf測試發(fā)現(xiàn)時延抖動為0.144 ms。通過以上測試,可以看出本文系統(tǒng)能為指定的業(yè)務(wù)流提供可靠的性能保障。

圖6 數(shù)據(jù)包時延分布

間隔時間/s傳輸量/MB重傳數(shù)據(jù)包數(shù)0～101 116010～201 108120～301 116030～401 112140～501 113050～601 110160～701 111170～801 11000～808 8964

為了進一驗證擁塞控制策略的性能,采用與圖5相同的拓?fù)?鏈路帶寬為100 Mb/s,對比本文方法和傳統(tǒng)的TCP Reno協(xié)議下?lián)砣刂品椒ǖ男Ч?并觀察隊列的占用情況。主機Host1和主機Host2向主機Host0同時發(fā)送數(shù)據(jù),在這種情況下,交換機Switch1發(fā)生擁塞。如圖7所示,與傳統(tǒng)TCP Reno相比,本文系統(tǒng)的擁塞控制方法可以使隊列中數(shù)據(jù)包個數(shù)降低到個位數(shù),隊列占用率至少降低了80%,較大程度上避免了擁塞的發(fā)生。

圖7 隊列占用情況

5 結(jié)束語

本文提出一種基于SDN的云架構(gòu)網(wǎng)絡(luò)高確定性流量控制方法。該方法將SDN集中優(yōu)化控制、全網(wǎng)感知、靈活敏捷管理的優(yōu)點與傳統(tǒng)多隊列調(diào)度機制相結(jié)合,并使用擁塞控制策略保證了業(yè)務(wù)流的帶寬和時延。運用全可編程交換機進行業(yè)務(wù)流的細(xì)粒度管理,再配合個性化的流表下發(fā)機制,實現(xiàn)了業(yè)務(wù)傳輸帶寬、路由和業(yè)務(wù)流等級動態(tài)調(diào)整。實驗結(jié)果表明,該方法實現(xiàn)對業(yè)務(wù)流的集中化、實時化、精細(xì)化管理,為云架構(gòu)網(wǎng)絡(luò)中交換業(yè)務(wù)提供高確定性帶寬、路由和時延保障。下一步將繼續(xù)完善本文方法,并將其使用到更大的網(wǎng)絡(luò)范圍中進行驗證。