曹紹華，張 斌，張培穎

(中國石油大學(xué)(華東) 計算機與通信工程學(xué)院，山東 青島 266580)

0 引言

在如今的網(wǎng)絡(luò)架構(gòu)中，隨著互聯(lián)網(wǎng)用戶數(shù)量的增加、現(xiàn)實生活對互聯(lián)網(wǎng)依賴度的提高，網(wǎng)絡(luò)工程師不斷地豐富和完善傳輸層應(yīng)用層協(xié)議，強大的IP協(xié)議棧雖然足以支撐龐大的上層網(wǎng)絡(luò)架構(gòu)，但其標準化和廣泛化也使得整體網(wǎng)絡(luò)架構(gòu)的性能升級受到限制。采用新的網(wǎng)絡(luò)體系來替代現(xiàn)有的網(wǎng)絡(luò)體系是行之有效的一種方法，從設(shè)計之初對網(wǎng)絡(luò)架構(gòu)的功能與性能進行改良，可以徹底達到提高性能的目的。軟件定義網(wǎng)絡(luò)(Software Defined Network，SDN)技術(shù)應(yīng)運而生。SDN[1-2]具有以下3個基本特征。

(1)控制和轉(zhuǎn)發(fā)分離：指轉(zhuǎn)發(fā)平面由受控轉(zhuǎn)發(fā)的設(shè)備組成，轉(zhuǎn)發(fā)方式以及業(yè)務(wù)邏輯由運行在分離出去的控制面上的控制應(yīng)用所控制。

(2)控制平面與轉(zhuǎn)發(fā)平面之間的開放接口：指SDN為控制平面提供開放可編程接口。通過這種方式，控制應(yīng)用只需要關(guān)注自身邏輯，而不需要關(guān)注底層更多的實現(xiàn)細節(jié)。

(3)邏輯上的集中控制：指邏輯上集中的控制平面可以控制多個轉(zhuǎn)發(fā)面設(shè)備，也就是控制整個物理網(wǎng)絡(luò)，因而可以獲得全局的網(wǎng)絡(luò)狀態(tài)視圖，并根據(jù)該網(wǎng)絡(luò)狀態(tài)視圖實現(xiàn)對網(wǎng)絡(luò)的優(yōu)化控制。這從概念上改變了人們對網(wǎng)絡(luò)設(shè)備的客觀理解，不再單單是傳統(tǒng)意義上的路由器與交換機等單純的二三層設(shè)備。 在SDN的網(wǎng)絡(luò)架構(gòu)中可以使用控制器和交換機的結(jié)構(gòu)(如Openflow Controller和Openflow Switch[3-4])對控制層和轉(zhuǎn)發(fā)層進行分離。通過控制器進行數(shù)據(jù)流和網(wǎng)絡(luò)環(huán)境的判別、采集、下發(fā)；設(shè)備硬件歸一化,硬件只關(guān)注轉(zhuǎn)發(fā)和存儲能力，與業(yè)務(wù)特性解耦；網(wǎng)絡(luò)的功能全部由軟件實現(xiàn)，更好地對網(wǎng)絡(luò)進行監(jiān)測和控制，從而在一定程度上提高網(wǎng)絡(luò)性能。

圖1 SDN網(wǎng)絡(luò)架構(gòu)

同時，SDN技術(shù)與現(xiàn)有網(wǎng)絡(luò)環(huán)境具有良好的兼容性，在數(shù)據(jù)中心[5]內(nèi)采用SDN技術(shù)構(gòu)建網(wǎng)絡(luò)來提高網(wǎng)絡(luò)性能，就是一種改良網(wǎng)絡(luò)架構(gòu)的方案。數(shù)據(jù)中心在其出口帶寬一定的情況下，會出現(xiàn)多個業(yè)務(wù)競爭出口帶寬，導(dǎo)致關(guān)鍵業(yè)務(wù)不能夠分配到足夠帶寬，從而大大降低服務(wù)質(zhì)量。如何及時靈活地分配每個業(yè)務(wù)的帶寬是解決問題的關(guān)鍵所在。因此，采用SDN技術(shù)來組織數(shù)據(jù)中心網(wǎng)絡(luò)內(nèi)環(huán)境，對數(shù)據(jù)中心的業(yè)務(wù)進行保障，具有相當(dāng)重要的現(xiàn)實意義與研究價值。本文針對SDN構(gòu)建的數(shù)據(jù)中心提出了一種多業(yè)務(wù)環(huán)境下的帶寬保障算法。

1 相關(guān)工作

在數(shù)據(jù)中心帶寬保障方面，研究人員提出了一些適合數(shù)據(jù)中心多業(yè)務(wù)環(huán)境下帶寬保障的解決方案，如ATBG算法[6]、基于合作博弈的帶寬分配策略[7]、Netstitcher[8]等。

ATBG算法將數(shù)據(jù)中心的業(yè)務(wù)根據(jù)帶寬敏感度和延遲敏感度劃分為三類，根據(jù)已知的業(yè)務(wù)類型、業(yè)務(wù)帶寬需求、源地址以及目的地址進行業(yè)務(wù)帶寬保障。這種方法適用于業(yè)務(wù)帶寬需求變化較小的環(huán)境，若高帶寬敏感度的業(yè)務(wù)帶寬需求發(fā)生較大變化時，則會導(dǎo)致關(guān)鍵業(yè)務(wù)不流暢或帶寬資源的浪費。當(dāng)一個服務(wù)器主機同時在不同端口上提供多個服務(wù)時，ATBG算法只根據(jù)源地址以及目的地址無法確定唯一的需保障的業(yè)務(wù)，會導(dǎo)致帶寬保障無法達到預(yù)期效果。

基于合作博弈的帶寬分配策略是將多個匯聚流對帶寬分配的競爭行為建模為一個合作博弈，通過尋求此博弈的納什談判解來確定優(yōu)化的帶寬分配策略，權(quán)衡各匯聚流的最小帶寬，保證帶寬分配的公平性。最優(yōu)化的帶寬分配策略需要多次迭代收斂獲得，且選取的基帶寬合適與否影響迭代的周期。方案中的CGBA策略，雖然具有較高帶寬分配滿足度和較高公平性，但其是以犧牲一定計算復(fù)雜度為代價的，若應(yīng)用到實際數(shù)據(jù)中心場景，需要考慮設(shè)備性能及帶寬分配延時問題。

Netstitcher通過獲取資源信息和帶寬的使用情況，使用存儲轉(zhuǎn)發(fā)算法(Store and Forward),優(yōu)先傳輸延遲敏感度高的數(shù)據(jù)，延遲敏感度低的數(shù)據(jù)會被暫存，在帶寬資源有空閑時傳輸，根據(jù)帶寬的使用情況進行實時的調(diào)整。此方案通過調(diào)度策略對帶寬在時間上進行了分配，減小了其他業(yè)務(wù)對延時敏感度高的業(yè)務(wù)的影響，但是對業(yè)務(wù)流量的劃分粒度較大，沒有充分考慮不同流量對于帶寬需求的差異。

2 基于優(yōu)先級的帶寬保障算法描述

在基于優(yōu)先級的帶寬保障算法中，業(yè)務(wù)的優(yōu)先級是對業(yè)務(wù)帶寬保障順序的約束，在多個業(yè)務(wù)并行的數(shù)據(jù)中心，若總帶寬只能滿足其中部分業(yè)務(wù)的需求，需要通過區(qū)分業(yè)務(wù)的優(yōu)先級，在保障高優(yōu)先級業(yè)務(wù)帶寬的前提下，再保障優(yōu)先級次之的業(yè)務(wù)帶寬，盡可能在保障業(yè)務(wù)的同時提高帶寬利用率。

由于不同的業(yè)務(wù)在服務(wù)器中通過網(wǎng)絡(luò)端口與客戶端進行通信，因此使用服務(wù)器IP地址+服務(wù)提供應(yīng)用的網(wǎng)絡(luò)端口號來區(qū)分業(yè)務(wù)。業(yè)務(wù)優(yōu)先級范圍為0～255，數(shù)字越大優(yōu)先級越高，其中0級代表不對業(yè)務(wù)進行帶寬保障，將其加入到默認隊列。為此隊列分配一個大于0的帶寬，以保障所有業(yè)務(wù)不會出現(xiàn)中斷。

2.1 網(wǎng)絡(luò)模型

研究的數(shù)據(jù)中心模型假定滿足以下條件：

(1)數(shù)據(jù)中心有唯一對外出口，數(shù)據(jù)出入均通過一個交換機，出口鏈路帶寬值一定。

(2)數(shù)據(jù)中心同時提供多種業(yè)務(wù)的數(shù)據(jù)服務(wù)，如FTP服務(wù)、視頻點播服務(wù)、語音通話服務(wù)，業(yè)務(wù)的延遲敏感度不同，且不同時段業(yè)務(wù)的帶寬需求可能有較大變化。

(3)數(shù)據(jù)中心提供的數(shù)據(jù)服務(wù)數(shù)量會產(chǎn)生不定變化，如某一時段要求關(guān)閉某個服務(wù)或新增服務(wù)。

(4)數(shù)據(jù)中心使用基于SDN的網(wǎng)絡(luò)架構(gòu)。

圖2 數(shù)據(jù)中心模型

2.2 算法描述

2.2.1業(yè)務(wù)隊列

算法在系統(tǒng)中保持兩個數(shù)據(jù)結(jié)構(gòu)隊列，即帶寬保障隊列和非帶寬保障隊列。帶寬保障隊列中按照業(yè)務(wù)優(yōu)先級從高到低的順序存放需要進行帶寬保障的業(yè)務(wù)信息，非帶寬保障隊列存放不進行帶寬保障的業(yè)務(wù)信息(優(yōu)先級為0的業(yè)務(wù)不進行帶寬保障)。

業(yè)務(wù)類 class Business_class{

IP

//業(yè)務(wù)ip地址

Port

//業(yè)務(wù)端口

Prio

//業(yè)務(wù)優(yōu)先級

QueueId

//對應(yīng)交換機隊列Id

FlowId

//對應(yīng)交換機流表Id

Bandwidth_guara

//保障帶寬

Bandwidth_last

//最近記錄帶寬

}

2.2.2交換機端口隊列

通過下發(fā)流表為不同優(yōu)先級的業(yè)務(wù)分配對應(yīng)的交換機端口隊列，利用交換機端口隊列的最小速率和最大速率限制業(yè)務(wù)的帶寬。

將所有不進行帶寬保障的業(yè)務(wù)分配到同一個默認隊列中，該隊列設(shè)置最小速率，以保證不進行帶寬保障的業(yè)務(wù)不會中斷。

2.2.3業(yè)務(wù)可用帶寬VB

對于每個進行帶寬保障的業(yè)務(wù)，業(yè)務(wù)可用帶寬VBi與總帶寬T、優(yōu)先級較高的業(yè)務(wù)保障帶寬BWj和默認隊列帶寬BW0有關(guān)，計算公式如下：

(1)

2.2.4最近記錄帶寬LBW

最近記錄帶寬：記錄最近一次業(yè)務(wù)保障帶寬變化時業(yè)務(wù)實際占用的帶寬值。

2.2.5業(yè)務(wù)保障帶寬BW

業(yè)務(wù)保障帶寬需要根據(jù)業(yè)務(wù)當(dāng)前占用帶寬CBW和VBi計算得到。由于無法得知業(yè)務(wù)對帶寬的實際需求，系統(tǒng)中采用逐步逼近的方法來得到滿足保障業(yè)務(wù)需求的帶寬值。假設(shè)在業(yè)務(wù)可用帶寬充足的情況下，將業(yè)務(wù)保障帶寬設(shè)為大于當(dāng)前業(yè)務(wù)占用帶寬的值，當(dāng)下次檢測此業(yè)務(wù)帶寬時，如果業(yè)務(wù)占用的帶寬接近于業(yè)務(wù)保障帶寬，則說明當(dāng)前業(yè)務(wù)保障帶寬不能滿足業(yè)務(wù)對帶寬的實際需求，此時就需要增大業(yè)務(wù)保障帶寬，直到業(yè)務(wù)占用帶寬不再出現(xiàn)明顯增長，說明當(dāng)前業(yè)務(wù)占用帶寬接近于業(yè)務(wù)對帶寬的實際需求。業(yè)務(wù)保障帶寬需要大于業(yè)務(wù)對帶寬的實際需求，以防止業(yè)務(wù)帶寬需求增長導(dǎo)致系統(tǒng)不能及時為業(yè)務(wù)分配足夠帶寬。由于業(yè)務(wù)可用帶寬的限制，系統(tǒng)中為每個業(yè)務(wù)設(shè)置的業(yè)務(wù)保障帶寬不能大于VBi。

2.2.6可忽略帶寬浮動值a

帶寬浮動值小于可忽略帶寬浮動值時，認為業(yè)務(wù)實際需求的帶寬沒有發(fā)生變化，避免因帶寬正常浮動而引起算法被頻繁執(zhí)行。

2.2.7基于優(yōu)先級的業(yè)務(wù)帶寬保障

每間隔一段時間對所有帶寬保障的業(yè)務(wù)按照優(yōu)先級由高到低的順序進行帶寬使用情況的檢測，并根據(jù)CBW與LBW計算帶寬浮動值α：

(2)

若α大于a，則認為業(yè)務(wù)實際需求帶寬發(fā)生變化，根據(jù)CBW和VBi重新計算業(yè)務(wù)保障帶寬。當(dāng)某個業(yè)務(wù)的BW發(fā)生變化時，優(yōu)先級小于這個業(yè)務(wù)優(yōu)先級的所有業(yè)務(wù)的BW需要重新計算。

若計算得到的BW等于VBi且不為零(業(yè)務(wù)可用帶寬小于或接近于業(yè)務(wù)實際需求帶寬)時，有兩種處理策略：一是將此業(yè)務(wù)和優(yōu)先級更小的業(yè)務(wù)加入到默認隊列，并將此業(yè)務(wù)的可用帶寬分配給默認隊列；二是將業(yè)務(wù)可用帶寬全部分配給此業(yè)務(wù)。假設(shè)加入到默認隊列中的業(yè)務(wù)平分默認隊列帶寬，通過計算兩種策略中此業(yè)務(wù)能夠分得的帶寬值，選擇業(yè)務(wù)能夠獲得帶寬值較大的策略執(zhí)行。

圖3 基于優(yōu)先級的業(yè)務(wù)帶寬保障業(yè)務(wù)流程圖

3 仿真實驗

3.1 測試環(huán)境

為了驗證基于優(yōu)先級的帶寬保障算法的性能，本文使用Mininet[9]建立模擬數(shù)據(jù)中心網(wǎng)絡(luò)拓撲進行測試。

測試使用VMware Workstation部署Ubuntu13.10虛擬機，并在Ubuntu中安裝Mininet，使用Mininet建立自定義拓撲來完成對數(shù)據(jù)中心的模擬。利用 Xterm 命令在Mininet內(nèi)開啟不同的主機節(jié)點，根據(jù)Mininet的特性，每一個主機節(jié)點都可以看作是一個獨立、同系統(tǒng)、同內(nèi)核的主機服務(wù)器節(jié)點，使用VLC軟件和Vsftpd 在服務(wù)器節(jié)點上部署視頻服務(wù)器或FTP服務(wù)器?？刂破魇褂瞄_源Floodlight[10]控制器，加入自定義的帶寬保障模塊。

對算法進行測試時，使用未加入帶寬保障模塊的控制器進行測試作為對照，對測試結(jié)果進行比較分析。

3.2 測試結(jié)果分析

圖4為在使用帶寬保障模塊的情況下，測得的FTP服務(wù)和視頻服務(wù)的傳輸速度隨時間的變化曲線。測試中規(guī)定視頻服務(wù)優(yōu)先級高于FTP服務(wù)，用戶主機先請求視頻服務(wù)，一段時間后請求FTP服務(wù)。在FTP服務(wù)流量開始傳輸時視頻播放出現(xiàn)卡頓，此時FTP服務(wù)和視頻服務(wù)爭奪帶寬資源?？刂破髯远x的帶寬保障功能將視頻服務(wù)的流量加入到帶寬保障隊列，通過不斷調(diào)整帶寬使隊列的最小速率可以滿足視頻服務(wù)的需求，視頻播放恢復(fù)流暢，F(xiàn)TP傳輸速度相應(yīng)下降。

圖4 使用基于優(yōu)先級的業(yè)務(wù)帶寬保障兩個業(yè)務(wù)對比圖

圖5為在不使用帶寬保障模塊的情況下，測得的FTP服務(wù)和視頻服務(wù)的傳輸速度。

圖5 不使用基于優(yōu)先級的業(yè)務(wù)帶寬保障兩個業(yè)務(wù)對比圖

以上兩個實驗表明了基于優(yōu)先級的帶寬保障算法能較好地保障優(yōu)先級較高的視頻服務(wù)占有充足的帶寬資源，限制了FTP占用的帶寬，使用戶的視頻播放不會出現(xiàn)卡頓。

4 結(jié)束語

從實驗結(jié)果及數(shù)據(jù)分析上來看，應(yīng)用 SDN 技術(shù)實現(xiàn)區(qū)分業(yè)務(wù)的帶寬保障，是數(shù)據(jù)中心重要業(yè)務(wù)帶寬保障的一種較為有效的解決方案。通過SDN控制器的帶寬保障模塊，根據(jù)業(yè)務(wù)的優(yōu)先級對高優(yōu)先級的業(yè)務(wù)優(yōu)先執(zhí)行帶寬保障，為不同的業(yè)務(wù)流量分配不同的隊列，向交換機下發(fā)流表調(diào)整轉(zhuǎn)發(fā)策略，保障高優(yōu)先級業(yè)務(wù)的帶寬需求，從某種程度上提高了整個網(wǎng)絡(luò)的處理能力和效率。在本實驗中為了達到實驗效果，交換設(shè)備帶寬設(shè)置得相對較小，實際網(wǎng)絡(luò)中心的物理拓撲與模擬的仿真數(shù)據(jù)中心在性能上存在較大的區(qū)別，模塊的適用性還需要進一步測試。

[1] 畢軍. SDN體系結(jié)構(gòu)與未來網(wǎng)絡(luò)體系結(jié)構(gòu)創(chuàng)新環(huán)境[J].電信科學(xué), 2013, 29(8): 6-15.

[2] 張順淼，鄒復(fù)民. 軟件定義網(wǎng)絡(luò)研究綜述 [J].計算機應(yīng)用研究, 2013, 30(8): 2246-2251.

[3] WANG K C.Floodlight controiler[EB/OL][2018-01-11].https：//floodlight.atlassian.net/wiki/spaces/floodlightcontroller/overview+.

[4] OpenFlow. http://www.openflow.org/.

[5] 魏祥麟,陳鳴,范建華,等.數(shù)據(jù)中心網(wǎng)絡(luò)的體系結(jié)構(gòu)[J]. 軟件學(xué)報, 2013, 24(2): 295-316.

[6] 曹紹華,張鑫.面向業(yè)務(wù)的SDN網(wǎng)絡(luò)帶寬保障研究[J].計算機工程與應(yīng)用, 2016, 52(22): 127-132.

[7] 孟飛,蘭巨龍,胡宇翔. 基于合作博弈的數(shù)據(jù)中心骨干網(wǎng)帶寬分配策略[J].計算機研究與發(fā)展, 2016, 53(6): 1306-1313.

[8] LAOUTARIS N, SIRIVIANOS M, YANG X, et al. Inter-datacenter bulk transfers with netstitcher [J].ACM SIGCOMM Computer Communication Review, 2011, 41(4):74-85.

[9] 李艷,郝志安,李寧,等.基于mininet的SDN架構(gòu)仿真研究[J].計算機與網(wǎng)絡(luò), 2014 (5): 57-569.

[10] 黎進都,時向泉.基于Openflow的FloodLight控制器實現(xiàn)研究[J].中國電子商情(通信市場),2014 (1): 70-75.