曹紹華，張 斌，張培穎

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

0 引言

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

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

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

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

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

同時(shí)，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ù)中心在其出口帶寬一定的情況下，會(huì)出現(xiàn)多個(gè)業(yè)務(wù)競爭出口帶寬，導(dǎo)致關(guān)鍵業(yè)務(wù)不能夠分配到足夠帶寬，從而大大降低服務(wù)質(zhì)量。如何及時(shí)靈活地分配每個(gè)業(yè)務(wù)的帶寬是解決問題的關(guān)鍵所在。因此，采用SDN技術(shù)來組織數(shù)據(jù)中心網(wǎng)絡(luò)內(nèi)環(huán)境，對數(shù)據(jù)中心的業(yè)務(wù)進(jìn)行保障，具有相當(dāng)重要的現(xiàn)實(shí)意義與研究價(jià)值。本文針對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ù)帶寬需求、源地址以及目的地址進(jìn)行業(yè)務(wù)帶寬保障。這種方法適用于業(yè)務(wù)帶寬需求變化較小的環(huán)境，若高帶寬敏感度的業(yè)務(wù)帶寬需求發(fā)生較大變化時(shí)，則會(huì)導(dǎo)致關(guān)鍵業(yè)務(wù)不流暢或帶寬資源的浪費(fèi)。當(dāng)一個(gè)服務(wù)器主機(jī)同時(shí)在不同端口上提供多個(gè)服務(wù)時(shí)，ATBG算法只根據(jù)源地址以及目的地址無法確定唯一的需保障的業(yè)務(wù)，會(huì)導(dǎo)致帶寬保障無法達(dá)到預(yù)期效果。

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

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

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

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

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

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

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

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

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

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

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

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

2.2 算法描述

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

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

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

IP

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

Port

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

Prio

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

QueueId

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

FlowId

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

Bandwidth_guara

//保障帶寬

Bandwidth_last

//最近記錄帶寬

}

2.2.2交換機(jī)端口隊(duì)列

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

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

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

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

(1)

2.2.4最近記錄帶寬LBW

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

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

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

2.2.6可忽略帶寬浮動(dòng)值a

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

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

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

(2)

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

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

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

3 仿真實(shí)驗(yàn)

3.1 測試環(huán)境

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

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

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

3.2 測試結(jié)果分析

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

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

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

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

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

4 結(jié)束語

從實(shí)驗(yàn)結(jié)果及數(shù)據(jù)分析上來看，應(yīng)用 SDN 技術(shù)實(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ù)流量分配不同的隊(duì)列，向交換機(jī)下發(fā)流表調(diào)整轉(zhuǎn)發(fā)策略，保障高優(yōu)先級業(yè)務(wù)的帶寬需求，從某種程度上提高了整個(gè)網(wǎng)絡(luò)的處理能力和效率。在本實(shí)驗(yàn)中為了達(dá)到實(shí)驗(yàn)效果，交換設(shè)備帶寬設(shè)置得相對較小，實(shí)際網(wǎng)絡(luò)中心的物理拓?fù)渑c模擬的仿真數(shù)據(jù)中心在性能上存在較大的區(qū)別，模塊的適用性還需要進(jìn)一步測試。

[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].計(jì)算機(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é)報(bào), 2013, 24(2): 295-316.

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

[7] 孟飛,蘭巨龍,胡宇翔. 基于合作博弈的數(shù)據(jù)中心骨干網(wǎng)帶寬分配策略[J].計(jì)算機(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].計(jì)算機(jī)與網(wǎng)絡(luò), 2014 (5): 57-569.

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