SDN下的IPv6任意播實(shí)現(xiàn)負(fù)載均衡的路由算法研究

樊 偉,徐 華,李 京

(中國(guó)科學(xué)技術(shù)大學(xué) 計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院,合肥 230026)

1 引 言

隨著互聯(lián)網(wǎng)的發(fā)展,IPv4地址空間不足的問(wèn)題日益嚴(yán)重,針對(duì)此問(wèn)題被提出的下一代網(wǎng)絡(luò)協(xié)議IPv6在過(guò)去的一段時(shí)間內(nèi)得到了迅速的發(fā)展.大量學(xué)者認(rèn)為IPv4網(wǎng)絡(luò)服務(wù)逐步向IPv6網(wǎng)絡(luò)過(guò)渡將成為不可逆轉(zhuǎn)的趨勢(shì).任意播[1]是IPv6中提出的一種新型的“一對(duì)多”通訊模式,得益于其路由策略會(huì)將數(shù)據(jù)分組路由到“最近”服務(wù)器的特點(diǎn),任意播能夠節(jié)約路由和鏈路資源,增加資源利用率和避免單點(diǎn)失效,因此在DNS、網(wǎng)站鏡像、視頻點(diǎn)播等網(wǎng)絡(luò)服務(wù)的負(fù)載均衡方面有著重要的應(yīng)用.

路由選擇算法是IPv6任意播實(shí)現(xiàn)負(fù)載均衡的關(guān)鍵,因此針對(duì)任意播路由選擇算法如何有效實(shí)現(xiàn)負(fù)載均衡的研究是當(dāng)前相關(guān)領(lǐng)域研究的一個(gè)重要方向.然而現(xiàn)有對(duì)任意播實(shí)現(xiàn)負(fù)載均衡的路由算法的研究存在以下三個(gè)難以解決的問(wèn)題:

1)較為簡(jiǎn)單的任意播負(fù)載均衡路由選擇算法不能準(zhǔn)確地選擇出最佳服務(wù)器.在現(xiàn)有研究的網(wǎng)絡(luò)架構(gòu)中,路由選擇策略往往以分布式算法的形式實(shí)現(xiàn)并集成于分散的網(wǎng)絡(luò)交換設(shè)備當(dāng)中,網(wǎng)絡(luò)架構(gòu)缺乏集中管理的控制平面導(dǎo)致分布式的路由選擇策略難以獲取和維護(hù)全局的網(wǎng)絡(luò)信息和服務(wù)節(jié)點(diǎn)負(fù)載信息,因此一些較為簡(jiǎn)單的任意播路由策略[3-5]僅通過(guò)鏈路的時(shí)延,服務(wù)節(jié)點(diǎn)的響應(yīng)時(shí)間或者當(dāng)前活躍的會(huì)話次數(shù)作為依據(jù)來(lái)估計(jì)網(wǎng)絡(luò)和服務(wù)節(jié)點(diǎn)的負(fù)載,然而僅僅通過(guò)這些信息并不能準(zhǔn)確的估計(jì)服務(wù)節(jié)點(diǎn)的負(fù)載,導(dǎo)致算法無(wú)法較精準(zhǔn)的選擇出最佳服務(wù)器;

2)通過(guò)試圖設(shè)計(jì)較為復(fù)雜的分布式路由算法來(lái)更準(zhǔn)確地計(jì)算網(wǎng)絡(luò)和服務(wù)節(jié)點(diǎn)的負(fù)載,雖然能夠比較準(zhǔn)確地選擇出最佳服務(wù)器,但這大大增加了網(wǎng)絡(luò)路由設(shè)備的負(fù)載.例如一些文獻(xiàn)[7-9]設(shè)計(jì)的較為復(fù)雜的分布式路由算法,通過(guò)路由器采集鏈路和服務(wù)節(jié)點(diǎn)的負(fù)載信息,或者對(duì)任意播樹(shù)自身信息與請(qǐng)求進(jìn)行分布式維護(hù)與處理來(lái)進(jìn)行路由選擇,這類算法雖能較為準(zhǔn)確地計(jì)算網(wǎng)絡(luò)和服務(wù)節(jié)點(diǎn)的負(fù)載,但在文獻(xiàn)的網(wǎng)絡(luò)架構(gòu)下,這些算法既需要路由設(shè)備對(duì)多種負(fù)載參數(shù)信息進(jìn)行采集,還需要對(duì)數(shù)據(jù)包進(jìn)行轉(zhuǎn)發(fā),這就增加了網(wǎng)絡(luò)路由設(shè)備的負(fù)載;

3)現(xiàn)有研究所處的網(wǎng)絡(luò)架構(gòu)下實(shí)現(xiàn)的任意播路由策略缺乏靈活性和可擴(kuò)展性.在現(xiàn)有研究的網(wǎng)絡(luò)架構(gòu)下,任意播路由選擇策略均集成于分布式的網(wǎng)絡(luò)交換設(shè)備當(dāng)中,即數(shù)據(jù)流的控制平面與轉(zhuǎn)發(fā)平面以緊耦合的方式集成于路由設(shè)備中.因此,更新網(wǎng)絡(luò)中任意播負(fù)載均衡路由策略通常需要管理員配置不計(jì)其數(shù)的網(wǎng)絡(luò)設(shè)備和策略機(jī)制.同時(shí),網(wǎng)絡(luò)中不同路由設(shè)備間的管理協(xié)議不同,這更是增加了網(wǎng)絡(luò)中路由策略更新的復(fù)雜度.所以,在這樣的網(wǎng)絡(luò)架構(gòu)下,任意播負(fù)載均衡路由策略很難實(shí)現(xiàn)較高靈活性和可擴(kuò)展性.

導(dǎo)致現(xiàn)有相關(guān)研究存在上述難以解決的問(wèn)題的本質(zhì)原因是研究所處的網(wǎng)絡(luò)架構(gòu)存在以下局限性:第一,網(wǎng)絡(luò)架構(gòu)缺乏集中的控制平面,導(dǎo)致路由策略難以掌握全局網(wǎng)絡(luò)信息和準(zhǔn)確的服務(wù)器負(fù)載信息;第二,網(wǎng)絡(luò)架構(gòu)中控制平面集成于網(wǎng)絡(luò)交換設(shè)備當(dāng)中,導(dǎo)致復(fù)雜路由算法會(huì)增加交換設(shè)備負(fù)載;第三,控制平面和轉(zhuǎn)發(fā)平面緊耦合,導(dǎo)致路由策略缺乏靈活性.軟件定義網(wǎng)絡(luò)[2](SDN)作為一種新興的基于軟件的網(wǎng)絡(luò)架構(gòu)及技術(shù),能夠?qū)⒔粨Q設(shè)備中的控制平面從設(shè)備中抽離,以實(shí)現(xiàn)控制平面與數(shù)據(jù)平面相分離,并通過(guò)邏輯上集中的控制層面,對(duì)分散的網(wǎng)絡(luò)設(shè)備進(jìn)行集中控制管理.因此為了解決現(xiàn)有研究中任意播負(fù)載均衡路由策略的諸多問(wèn)題,論文基于SDN架構(gòu)對(duì)IPv6任意播實(shí)現(xiàn)負(fù)載均衡的路由選擇算法進(jìn)行研究,提出了SDN下的一套任意播路由轉(zhuǎn)發(fā)框架以及一種基于權(quán)值的任意播實(shí)現(xiàn)負(fù)載均衡的路由選擇算法.

論文提出的任意播負(fù)載均衡路由架構(gòu)利用SDN技術(shù)下集中的控制平面,周期采集全局的網(wǎng)絡(luò)負(fù)載信息以及網(wǎng)絡(luò)中的任意播服務(wù)節(jié)點(diǎn)的負(fù)載信息,然后基于所采集的鏈路以及節(jié)點(diǎn)的負(fù)載信息按照不同權(quán)重對(duì)服務(wù)節(jié)點(diǎn)的綜合負(fù)載進(jìn)行評(píng)估,最終路由系統(tǒng)將新產(chǎn)生的任意播服務(wù)請(qǐng)求轉(zhuǎn)發(fā)給綜合負(fù)載較輕的服務(wù)節(jié)點(diǎn).考慮到在不同應(yīng)用場(chǎng)景下網(wǎng)絡(luò)服務(wù)對(duì)不同網(wǎng)絡(luò)資源的消耗不同,可能存在節(jié)點(diǎn)的某些網(wǎng)絡(luò)資源占用很少,但某些網(wǎng)絡(luò)資源消耗幾乎殆盡而導(dǎo)致性能急劇下降的情況,論文對(duì)評(píng)估節(jié)點(diǎn)綜合負(fù)載的權(quán)重算法進(jìn)行改進(jìn),引入了負(fù)反饋機(jī)制,類似短板效應(yīng),在考量節(jié)點(diǎn)的綜合負(fù)載時(shí),著重考慮其網(wǎng)絡(luò)資源消耗最多的因素.

最終,論文通過(guò)實(shí)驗(yàn)證明了論文提出的任意播負(fù)載均衡路由架構(gòu)和負(fù)載均衡路由選擇算法有較好的負(fù)載均衡性能.同時(shí)實(shí)驗(yàn)表明,論文對(duì)權(quán)重算法引入的負(fù)反饋機(jī)制能夠有效避免網(wǎng)絡(luò)資源消耗不均勻?qū)е乱恍┵Y源消耗過(guò)度使得性能急劇下降的情況.

2 相關(guān)工作

在IPv6任意播實(shí)現(xiàn)負(fù)載均衡的路由選擇算法方面,國(guó)內(nèi)外的不同學(xué)者們從不同角度對(duì)該問(wèn)題進(jìn)行了很多研究.

一些學(xué)者從減輕網(wǎng)絡(luò)交換設(shè)備的負(fù)載方面出發(fā),通過(guò)設(shè)計(jì)簡(jiǎn)單的算法,采集較少的負(fù)載估計(jì)信息,以減輕網(wǎng)絡(luò)交換設(shè)備的負(fù)載,但這類研究由于算法較簡(jiǎn)單,采集的信息較少,導(dǎo)致不能準(zhǔn)確選擇出最佳服務(wù)器.例如在Agarwal[3]等人提出的可擴(kuò)展部署的任意播系統(tǒng)結(jié)構(gòu)(CCAD模型)中,以各任意播組成員的響應(yīng)時(shí)間作為依據(jù)進(jìn)行最佳服務(wù)器的路由選擇,此外還有Zaumen[4]以及 Wang[5]等人也是基于網(wǎng)絡(luò)鏈路或服務(wù)節(jié)點(diǎn)的時(shí)延來(lái)進(jìn)行任意播路由選擇,其中文獻(xiàn)[4]以最小時(shí)延為目的,提出了負(fù)載均衡的任意播路由協(xié)議MIDAS,而文獻(xiàn)[5]則以高概率選擇時(shí)延小的路徑進(jìn)行數(shù)據(jù)傳輸來(lái)達(dá)到負(fù)載均衡.而文獻(xiàn)[6]則通過(guò)選取當(dāng)前會(huì)話次數(shù)最少的任意播成員作為最佳服務(wù)器.然而,上述研究提出的負(fù)載均衡算法較為簡(jiǎn)單,通過(guò)任意播組成員的響應(yīng)時(shí)間或活躍的會(huì)話數(shù)往往不能準(zhǔn)確的估計(jì)服務(wù)節(jié)點(diǎn)的負(fù)載,導(dǎo)致無(wú)法較精準(zhǔn)的選擇出最佳服務(wù)器.

另外一些學(xué)者則從提高路由選擇算法對(duì)最佳服務(wù)器選取的準(zhǔn)確性方面出發(fā),通過(guò)設(shè)計(jì)較為復(fù)雜的任意播負(fù)載均衡路由策略,采集更多的負(fù)載信息或者維護(hù)更加復(fù)雜的狀態(tài),來(lái)提高算法路由選擇的準(zhǔn)確性,但這類算法復(fù)雜度較高,且要求路由設(shè)備采集較多數(shù)據(jù),增加了路由設(shè)備的負(fù)載.例如 Yamamoto[7]等人給出了一種主動(dòng)任意播實(shí)現(xiàn)負(fù)載均衡的網(wǎng)絡(luò)構(gòu)架,并在該構(gòu)架的基礎(chǔ)上進(jìn)行了改進(jìn)[8],最終在他們提出的構(gòu)架中,綜合考慮路徑擁塞,往返時(shí)間以及服務(wù)器負(fù)載信息作為路由選擇的參數(shù),但是該構(gòu)架中,路由器既需要采集這些參數(shù)信息進(jìn)行路由選擇,還需要對(duì)數(shù)據(jù)包進(jìn)行轉(zhuǎn)發(fā),這大大增加了路由器的負(fù)載.在文獻(xiàn)[9]中提出的任意播通信模型中,需要對(duì)任意播樹(shù)自身信息與請(qǐng)求進(jìn)行分布式維護(hù)與處理,這在增加設(shè)備負(fù)載的同時(shí)也增加了算法復(fù)雜度.

由于在傳統(tǒng)網(wǎng)絡(luò)架構(gòu)中,往往存在負(fù)載均衡路由策略不靈活,簡(jiǎn)單負(fù)載均衡算法無(wú)法進(jìn)行準(zhǔn)確的路由選擇,而復(fù)雜算法又會(huì)增加網(wǎng)絡(luò)交換設(shè)備的負(fù)載的缺點(diǎn).隨著SDN網(wǎng)絡(luò)架構(gòu)技術(shù)的興起,研究學(xué)者們開(kāi)始嘗試使用SDN技術(shù)解決傳統(tǒng)網(wǎng)絡(luò)架構(gòu)下負(fù)載均衡存在的缺陷.

利用SDN技術(shù)實(shí)現(xiàn)負(fù)載均衡的主體思路為:利用SDN的全局性實(shí)時(shí)監(jiān)測(cè)網(wǎng)絡(luò)以及服務(wù)節(jié)點(diǎn)的全局負(fù)載信息,控制器通過(guò)下發(fā)數(shù)據(jù)轉(zhuǎn)發(fā)規(guī)則,控制數(shù)據(jù)流轉(zhuǎn)發(fā)向不同的服務(wù)節(jié)點(diǎn),從而實(shí)現(xiàn)負(fù)載均衡.而各項(xiàng)研究在SDN負(fù)載均衡框架的設(shè)計(jì)以及技術(shù)的實(shí)現(xiàn)上仍然存在較大差異和諸多問(wèn)題,例如,文獻(xiàn)[10]只能實(shí)現(xiàn)Flow level的負(fù)載均衡轉(zhuǎn)發(fā),無(wú)法對(duì)TCP等基于連接的協(xié)議提供支持;而文獻(xiàn)[11-14]則需要將客戶端產(chǎn)生的請(qǐng)求包上發(fā)給控制器,控制器需要對(duì)每一次連接進(jìn)行負(fù)載均衡分發(fā),控制器負(fù)載大,且存在單點(diǎn)失效的風(fēng)險(xiǎn);文獻(xiàn)[15]則通過(guò)預(yù)先下發(fā)數(shù)據(jù)轉(zhuǎn)發(fā)規(guī)則到OpenFlow交換機(jī),將客戶端地址進(jìn)行分組來(lái)實(shí)現(xiàn)負(fù)載均衡.然而該文獻(xiàn)為了保持客戶端和服務(wù)端的連接,需要控制器對(duì)每一個(gè)源地址產(chǎn)生的數(shù)據(jù)流進(jìn)行狀態(tài)維護(hù),因此當(dāng)網(wǎng)絡(luò)中存在大量數(shù)據(jù)流時(shí),仍然無(wú)法解決控制器負(fù)載較大的問(wèn)題.在協(xié)議支持方面,長(zhǎng)連接的應(yīng)用場(chǎng)景下,往往無(wú)法確定一次長(zhǎng)連接中兩次數(shù)據(jù)通信的時(shí)間間隔,而文獻(xiàn)[15]需要間隔固定時(shí)長(zhǎng)更新客戶端的狀態(tài),因此文獻(xiàn)[15]提出的路由系統(tǒng)不能很好支持長(zhǎng)連接應(yīng)用.而對(duì)于類似FTP服務(wù)這樣具有數(shù)據(jù)信道和控制信道雙信道的協(xié)議,上述的文獻(xiàn)均不能很好支持.

本論文通過(guò)控制器集中采集全局的網(wǎng)絡(luò)負(fù)載信息,通過(guò)預(yù)先下發(fā)數(shù)據(jù)轉(zhuǎn)發(fā)規(guī)則到OpenFlow交換機(jī),適度賦予了OpenFlow交換機(jī)處理局部網(wǎng)絡(luò)問(wèn)題的權(quán)利.論文利用Linux的Conntrack[16]內(nèi)核模塊,使得OpenFlow交換機(jī)能夠追蹤數(shù)據(jù)流的連接狀態(tài),從而對(duì)基于連接的協(xié)議提供支持.由于控制器不需要維護(hù)每個(gè)數(shù)據(jù)流的連接狀態(tài),有效減輕了控制器的負(fù)載.同時(shí),由于conntrack模塊能夠?qū)?shù)據(jù)流的“NEW,EST,REL,RPL,INV,TRK”六種連接狀態(tài)進(jìn)行跟蹤,因而本論文基于Conntrack實(shí)現(xiàn)的負(fù)載均衡路由系統(tǒng)能夠更好的支持長(zhǎng)連接以及FTP等特殊應(yīng)用.

3 基于SDN的任意播路由轉(zhuǎn)發(fā)系統(tǒng)

本章節(jié)主要對(duì)SDN下的任意播路由轉(zhuǎn)發(fā)網(wǎng)絡(luò)架構(gòu),原型系統(tǒng)的設(shè)計(jì)以及OpenFlow交換機(jī)流表的設(shè)計(jì)進(jìn)行闡述.

3.1 基于SDN的任意播負(fù)載均衡路由網(wǎng)絡(luò)框架

如圖1所示,本論文設(shè)計(jì)的基于SDN的任意播路由轉(zhuǎn)發(fā)網(wǎng)絡(luò)架構(gòu)的主干網(wǎng)絡(luò)由OpenFlow交換機(jī)構(gòu)成,且要求任意播服務(wù)的客戶端和服務(wù)端都需要直接或間接連接到該主干網(wǎng)絡(luò),即均通過(guò)由OpenFlow交換機(jī)構(gòu)成的網(wǎng)絡(luò)互聯(lián),OpenFlow交換機(jī)中的數(shù)據(jù)流轉(zhuǎn)發(fā)規(guī)則由SDN控制器集中控制,因此利用SDN的可編程性,向控制器中集成實(shí)現(xiàn)負(fù)載均衡的任意播路由選擇算法,將不同任意播數(shù)據(jù)流根據(jù)控制器采集到的負(fù)載信息轉(zhuǎn)發(fā)向不同服務(wù)節(jié)點(diǎn),便可實(shí)現(xiàn)負(fù)載均衡.

圖1 基于SDN的任意播路由轉(zhuǎn)發(fā)網(wǎng)絡(luò)架構(gòu)Fig.1 Network framework of SDN-based anycast route system

本論文實(shí)現(xiàn)負(fù)載均衡的任意播路由轉(zhuǎn)發(fā)過(guò)程如圖1所示,分為以下4個(gè)步驟:

Step1.客戶端以任意播地址為目的地址請(qǐng)求任意播服務(wù);

Step2.數(shù)據(jù)分組經(jīng)過(guò)OpenFlow交換機(jī)構(gòu)成的網(wǎng)絡(luò)時(shí),通過(guò)集成于SDN控制器中的負(fù)載均衡路由選擇策略選擇出最佳任意播服務(wù)節(jié)點(diǎn),然后將數(shù)據(jù)分組的目的地址更改為服務(wù)節(jié)點(diǎn)的單播地址,并將數(shù)據(jù)分組路由到該服務(wù)節(jié)點(diǎn);

Step3.服務(wù)節(jié)點(diǎn)對(duì)服務(wù)請(qǐng)求進(jìn)行響應(yīng);

Step4.OpenFlow網(wǎng)絡(luò)將響應(yīng)數(shù)據(jù)分組的源地址由服務(wù)節(jié)點(diǎn)的單播地址更改為任意播地址,并轉(zhuǎn)發(fā)給客戶端.

由上述過(guò)程可見(jiàn),論文的任意播負(fù)載均衡路由轉(zhuǎn)發(fā)是基于NAT技術(shù)實(shí)現(xiàn)的,但與傳統(tǒng)的NAT技術(shù)不同的是,傳統(tǒng)網(wǎng)絡(luò)下的NAT技術(shù)往往是通過(guò)一臺(tái)主機(jī)實(shí)現(xiàn)數(shù)據(jù)分組的地址轉(zhuǎn)換的,而本論文的地址轉(zhuǎn)換是通過(guò)SDN網(wǎng)絡(luò)的若干OpenFlow交換機(jī)實(shí)現(xiàn)的,而地址轉(zhuǎn)換規(guī)則則由SDN控制器統(tǒng)一集中管理,這就有效避免了一臺(tái)主機(jī)進(jìn)行地址轉(zhuǎn)換造成性能瓶頸的缺點(diǎn)以及單點(diǎn)失效的風(fēng)險(xiǎn).

3.2 基于SDN的任意播負(fù)載均衡路由系統(tǒng)架構(gòu)

如上一節(jié)上述,任意播的負(fù)載均衡路由轉(zhuǎn)發(fā)主要通過(guò)由OpenFlow交換機(jī)組成的SDN網(wǎng)絡(luò)以及SDN控制器共同實(shí)現(xiàn),其中SDN網(wǎng)絡(luò)主要根據(jù)SDN控制器下發(fā)的數(shù)據(jù)流轉(zhuǎn)發(fā)規(guī)則進(jìn)行地址轉(zhuǎn)換和數(shù)據(jù)轉(zhuǎn)發(fā),因此SDN控制器如何生成合理的數(shù)據(jù)轉(zhuǎn)發(fā)規(guī)則是路由系統(tǒng)的核心.

本論文選取Ryu作為路由系統(tǒng)的控制器,由于Ryu是基于模塊化的設(shè)計(jì)架構(gòu)實(shí)現(xiàn)的,所以本論文通過(guò)向Ryu控制器中添加模塊的方式對(duì)Ryu控制器進(jìn)行擴(kuò)展,故路由系統(tǒng)的架構(gòu)如圖2所示,圖中未畫出Ryu的原有模塊.

圖2 基于SDN的任意播負(fù)載均衡路由系統(tǒng)架構(gòu)Fig.2 Framework of SDN-based anycast route system

如圖2所示,架構(gòu)中主要包含6個(gè)模塊和一個(gè)策略池:

1)任意播模塊:該模塊是系統(tǒng)的核心模塊,該模塊維護(hù)了一個(gè)任意播地址到任意播成員地址的映射關(guān)系表.同時(shí)該模塊還是心跳解析模塊,通過(guò)解析任意播成員節(jié)點(diǎn)提交的心跳信息,將任意播組成員的信息更新到映射表并把負(fù)載信息提交給負(fù)載采集模塊.該模塊通過(guò)心跳判斷服務(wù)節(jié)點(diǎn)的存活狀態(tài),如果超過(guò)一段時(shí)間未接收到節(jié)點(diǎn)發(fā)來(lái)的心跳信息,映射表中的節(jié)點(diǎn)信息將被清理線程刪除;

2)負(fù)載采集模塊:該模塊除了從任意播模塊獲取服務(wù)節(jié)點(diǎn)的負(fù)載信息外,還通過(guò)OpenFlow協(xié)議定期主動(dòng)獲取網(wǎng)絡(luò)鏈路負(fù)載信息;

3)路由選擇模塊:該模塊基于負(fù)載采集模塊采集的鏈路及節(jié)點(diǎn)負(fù)載,利用策略池提供的負(fù)載均衡路由選擇策略進(jìn)行路由選擇,最終將路由選擇的結(jié)果反饋給任意播模塊;

4)流表控制模塊:根據(jù)負(fù)載均衡路由選擇的結(jié)果生成OpenFlow流表更新規(guī)則,并通過(guò)OpenFlow協(xié)議更新OpenFlow交換機(jī)的流表,從而更新SDN網(wǎng)絡(luò)的任意播數(shù)據(jù)轉(zhuǎn)發(fā)規(guī)則.

5)心跳模塊:任意播服務(wù)節(jié)點(diǎn)通過(guò)該模塊將節(jié)點(diǎn)注冊(cè)到控制器的任意播模塊,并通過(guò)周期發(fā)出心跳信息將節(jié)點(diǎn)的負(fù)載信息更新到任意播模塊;

6)REST ful模塊:將路由系統(tǒng)中維護(hù)的任意播服務(wù)信息(如存活的服務(wù)節(jié)點(diǎn)及其負(fù)載信息,可用的負(fù)載均衡策略等)通過(guò)REST接口暴露給上層應(yīng)用,方便上層應(yīng)用的開(kāi)發(fā);

7)策略池:為了實(shí)現(xiàn)SDN任意播路由系統(tǒng)中負(fù)載均衡策略的靈活性和擴(kuò)展性,在論文的路由系統(tǒng)中添加了策略池,用于集成不同的負(fù)載均衡路由策略.

3.3 流表設(shè)計(jì)

目前基于SDN的負(fù)載均衡路由系統(tǒng)主要有主動(dòng)下發(fā)流表和被動(dòng)下發(fā)流表兩類實(shí)現(xiàn)方式.其中主動(dòng)下發(fā)流表方式是指控制器通過(guò)OpenFlow協(xié)議主動(dòng)去更新交換機(jī)中的流表;而被動(dòng)下發(fā)流表則是交換機(jī)接收到流表中無(wú)匹配項(xiàng)的數(shù)據(jù)包時(shí),交換機(jī)通過(guò)Packet-In消息通知控制器,控制器再通過(guò)OpenFlow協(xié)議下發(fā)流表,告訴交換機(jī)如何處理該數(shù)據(jù)包.由于在任意播實(shí)現(xiàn)負(fù)載均衡的場(chǎng)景下,每一次對(duì)任意播服務(wù)的請(qǐng)求都需要進(jìn)行服務(wù)定位,如果采用被動(dòng)下發(fā)流表的方式實(shí)現(xiàn),所有對(duì)任意播服務(wù)的請(qǐng)求都需要經(jīng)過(guò)控制器,這樣會(huì)造成性能瓶頸和單點(diǎn)失效的問(wèn)題,這與我們的設(shè)計(jì)初衷相悖,因此本論文采用主動(dòng)下發(fā)流表的方式實(shí)現(xiàn).

由于OpenFlow協(xié)議本身不支持有狀態(tài)協(xié)議,即OpenFlow交換機(jī)內(nèi)的流表只能基于規(guī)則對(duì)數(shù)據(jù)包進(jìn)行無(wú)狀態(tài)的匹配轉(zhuǎn)發(fā).這會(huì)導(dǎo)致基于SDN實(shí)現(xiàn)的路由系統(tǒng)無(wú)法支持類似TCP這樣有狀態(tài),基于連接的協(xié)議.在被動(dòng)下發(fā)流表實(shí)現(xiàn)方案下,控制器會(huì)針對(duì)每一次連接生成相應(yīng)的數(shù)據(jù)包匹配處理流表,通過(guò)對(duì)原地址和目的地址的匹配,能夠區(qū)分?jǐn)?shù)據(jù)包所屬的連接,這樣就可以將屬于同一連接的數(shù)據(jù)包路由到同一服務(wù)節(jié)點(diǎn),實(shí)現(xiàn)對(duì)有狀態(tài)協(xié)議的支持.然而在主動(dòng)下發(fā)實(shí)現(xiàn)方案中,控制器只是周期地更新SDN網(wǎng)絡(luò)中任意播的處理流表,無(wú)法針對(duì)每次連接生成區(qū)分其他連接的匹配域,因此本論文利用Conntrack[16,17]模塊對(duì)數(shù)據(jù)包的連接狀態(tài)進(jìn)行追蹤和分類.Conntrack是Linux內(nèi)核中的一個(gè)跟蹤記錄連接狀態(tài)的模塊,通常該模塊被用于實(shí)現(xiàn)有狀態(tài)的防火墻,本論文則利用該模塊在交換機(jī)內(nèi)實(shí)現(xiàn)有狀態(tài)的負(fù)載均衡.Conntrack內(nèi)部為每一個(gè)連接實(shí)現(xiàn)了狀態(tài)機(jī),論文利用該狀態(tài)機(jī),將無(wú)狀態(tài)的數(shù)據(jù)包轉(zhuǎn)變?yōu)閹в羞B接狀態(tài)的數(shù)據(jù)包,從而區(qū)分?jǐn)?shù)據(jù)包所屬的連接.

圖3 主動(dòng)下發(fā)流表實(shí)現(xiàn)方案的流表設(shè)計(jì)Fig.3 Design of flow table in active mode

論文采用的主動(dòng)下發(fā)流表實(shí)現(xiàn)方案的流表設(shè)計(jì)如圖3所示.其中流表0對(duì)數(shù)據(jù)包類型進(jìn)行分類;流表1為ICMPv6協(xié)議的處理流表,而基于連接的TCP協(xié)議數(shù)據(jù)包則需要通過(guò)Conntrack模塊進(jìn)行追蹤標(biāo)記,以區(qū)分?jǐn)?shù)據(jù)包所屬的連接以及連接所處狀態(tài),本論文將連接分為兩個(gè)狀態(tài):連接尚未建立(NEW)狀態(tài),連接已建立(EST)狀態(tài).NEW狀態(tài)指三次握手還未完成的階段,在流表中特指客戶端發(fā)出SYN數(shù)據(jù)包請(qǐng)求連接的狀態(tài).NEW狀態(tài)的數(shù)據(jù)包將通過(guò)組表1進(jìn)行處理,由于該狀態(tài)的數(shù)據(jù)包企圖建立一次新的TCP連接,因此組表將會(huì)選擇一臺(tái)任意播服務(wù)節(jié)點(diǎn)對(duì)該新連接產(chǎn)生NAT規(guī)則,并將該規(guī)則提交到Conntrack模塊.組表1中包含了任意播服務(wù)器組中服務(wù)節(jié)點(diǎn)數(shù)目個(gè)buckets,其中,第i個(gè)bucket中的actions定義為:(nat(server_i_uni_ip),commit),組表的Group Type設(shè)為SELECT.EST狀態(tài)的數(shù)據(jù)包則表明數(shù)據(jù)包所屬連接已經(jīng)通過(guò)三次握手建立,因此僅需要通過(guò)組表向Conntrack模塊提交的NAT規(guī)則對(duì)數(shù)據(jù)包進(jìn)行地址轉(zhuǎn)換即可,即流表3僅進(jìn)行地址轉(zhuǎn)換操作.

3.4 系統(tǒng)可擴(kuò)展性分析

OpenFlow將控制平面從網(wǎng)絡(luò)設(shè)備中分離,并移出到OpenFlow控制器上,由控制器完成控制層的所有功能,OpenFlow交換機(jī)只保留了基本的數(shù)據(jù)轉(zhuǎn)發(fā)功能.因此基于SDN的負(fù)載均衡路由系統(tǒng)的可擴(kuò)展性問(wèn)題也就演化成了控制器在復(fù)雜網(wǎng)絡(luò)結(jié)構(gòu)和大量數(shù)據(jù)量下的處理性能問(wèn)題[18].為了提高控制器對(duì)網(wǎng)絡(luò)請(qǐng)求的處理能力,可以通過(guò)多線程或分布式的技術(shù)手段,提高控制器軟件本身的處理速度,例如Beacon,HyperFlow等;也可以通過(guò)對(duì)流表的巧妙設(shè)計(jì)來(lái)減少對(duì)控制器的請(qǐng)求,例如文獻(xiàn)[18,19]通過(guò)設(shè)計(jì)流表,對(duì)數(shù)據(jù)流初始化請(qǐng)求進(jìn)行聚類處理來(lái)減少對(duì)控制器請(qǐng)求,但是通過(guò)對(duì)數(shù)據(jù)分組源地址進(jìn)行聚類的方法無(wú)法實(shí)現(xiàn)細(xì)粒度的負(fù)載均衡,且文獻(xiàn)[18,19]提出的實(shí)現(xiàn)均不支持基于連接的服務(wù).本文通過(guò)預(yù)先下發(fā)數(shù)據(jù)轉(zhuǎn)發(fā)規(guī)則到OpenFlow交換機(jī),賦予了OpenFlow交換機(jī)處理局域網(wǎng)絡(luò)問(wèn)題的權(quán)利,并利用Conntrack技術(shù)使得OpenFlow交換機(jī)能夠獨(dú)立跟蹤數(shù)據(jù)流的連接狀態(tài),不再需要控制器維護(hù)連接狀態(tài),使得論文提出的負(fù)載均衡路由系統(tǒng)能夠在支持基于連接協(xié)議的前提下,也減少了控制器負(fù)載,從而增強(qiáng)了系統(tǒng)的可擴(kuò)展能力.

為探究論文所提出的路由系統(tǒng)的可擴(kuò)展能力,論文分別對(duì)路由系統(tǒng)能夠維持的最大交換機(jī)數(shù)量(下文稱為信道容量實(shí)驗(yàn))和在大量數(shù)據(jù)流下觀測(cè)網(wǎng)絡(luò)丟包率(下文稱為丟包率實(shí)驗(yàn))兩類情況進(jìn)行了實(shí)驗(yàn).論文使用Ryu作為網(wǎng)絡(luò)的SDN控制器,控制器的運(yùn)行環(huán)境為:Ubuntu系統(tǒng),4核CPU,8G內(nèi)存.

在信道容量實(shí)驗(yàn)中,論文分別對(duì)網(wǎng)絡(luò)中存在不同交換機(jī)數(shù)量進(jìn)行了實(shí)驗(yàn),實(shí)驗(yàn)結(jié)果表明,當(dāng)網(wǎng)絡(luò)中交換機(jī)數(shù)量增加時(shí),控制器處理交換機(jī)各種請(qǐng)求時(shí)所占用的系統(tǒng)資源也隨之增加.實(shí)驗(yàn)以內(nèi)存為例,當(dāng)交換機(jī)數(shù)量為200,400,600,800,1000個(gè)時(shí),控制器占用內(nèi)存大約為:38MB,49MB,63MB,78MB,92MB.在實(shí)驗(yàn)中,當(dāng)交換機(jī)數(shù)量達(dá)到800時(shí),出現(xiàn)少量通道連接斷開(kāi),Feature Request消息不發(fā)送等問(wèn)題,當(dāng)交換機(jī)數(shù)量達(dá)到1000時(shí),連接斷開(kāi)現(xiàn)象更加明顯,存在接近9%的通道連接會(huì)斷開(kāi).

在丟包率實(shí)驗(yàn)中,分別對(duì)論文提出的主動(dòng)下發(fā)流表策略實(shí)現(xiàn)的路由系統(tǒng)和被動(dòng)下發(fā)流表策略實(shí)現(xiàn)的路由系統(tǒng)進(jìn)行實(shí)驗(yàn).實(shí)驗(yàn)中,網(wǎng)絡(luò)中存在20個(gè)交換機(jī),交換機(jī)首尾相連形成環(huán),每個(gè)交換機(jī)連接一臺(tái)主機(jī),共20臺(tái)主機(jī),其中10臺(tái)客戶機(jī),10臺(tái)服務(wù)機(jī).每臺(tái)客戶機(jī)產(chǎn)生一定數(shù)量線程,每個(gè)線程間隔0.1s對(duì)隨機(jī)服務(wù)器發(fā)起連接請(qǐng)求,持續(xù)請(qǐng)求60s.論文對(duì)線程數(shù)量為2,4,6,8,10時(shí)進(jìn)行實(shí)驗(yàn),發(fā)現(xiàn)被動(dòng)下發(fā)流表實(shí)現(xiàn)方案在線程數(shù)為6時(shí),便有大約5%的連接失敗,在線程數(shù)為10時(shí),連接失敗數(shù)約占11%.而論文設(shè)計(jì)的主動(dòng)下發(fā)流表實(shí)現(xiàn)方案,在線程數(shù)為10時(shí),連接失敗數(shù)仍未超過(guò)5%.

通過(guò)上述可擴(kuò)展實(shí)驗(yàn)得知,論文設(shè)計(jì)的主動(dòng)下發(fā)流表的實(shí)現(xiàn)方案,通過(guò)控制器預(yù)先下發(fā)轉(zhuǎn)發(fā)規(guī)則,賦予OpenFlow交換機(jī)獨(dú)立轉(zhuǎn)發(fā)連接請(qǐng)求的權(quán)利,相比被動(dòng)下發(fā)流表實(shí)現(xiàn)方案,能夠有效減少對(duì)控制器的上發(fā)請(qǐng)求次數(shù),有效避免了控制器處理過(guò)多不必要的負(fù)載,因此論文提出的主動(dòng)下發(fā)流表實(shí)現(xiàn)方案具有更強(qiáng)可擴(kuò)展性.

4 負(fù)載均衡路由選擇算法

任意播服務(wù)器的路由選擇策略是提高任意播負(fù)載均衡效率的關(guān)鍵,本論文采用權(quán)值調(diào)度算法,綜合考慮系統(tǒng)收集到的節(jié)點(diǎn)負(fù)載信息來(lái)設(shè)計(jì)任意播負(fù)載均衡路由選擇算法.在實(shí)驗(yàn)過(guò)程中,我們發(fā)現(xiàn)對(duì)服務(wù)器的處理能力影響較大的因素主要是服務(wù)器的 CPU 占用率,鏈路的跳數(shù),服務(wù)器的響應(yīng)時(shí)間,內(nèi)存的占用率以及鏈路帶寬的占用率.其中服務(wù)節(jié)點(diǎn)的鏈路帶寬占用率取到達(dá)該服務(wù)節(jié)點(diǎn)所經(jīng)過(guò)路徑的帶寬占用率的最大值,如第i個(gè)節(jié)點(diǎn)的帶寬占用率由公式(1)計(jì)算得到,其中uij為到達(dá)第i個(gè)服務(wù)節(jié)點(diǎn)的第j跳鏈路的帶寬利用率.

li=max(uij)

(1)

綜合考慮以上五種負(fù)載指標(biāo),按照不同的權(quán)重來(lái)計(jì)算服務(wù)節(jié)點(diǎn)的權(quán)值,該權(quán)值代表了服務(wù)器的綜合負(fù)載,且權(quán)值越高,服務(wù)器的綜合負(fù)載越大,故論文設(shè)計(jì)的權(quán)值計(jì)算公式如下:

H=WTL

(2)

其中L是上述五個(gè)負(fù)載指標(biāo)的負(fù)載情況向量,W則是影響因素對(duì)應(yīng)的權(quán)重向量.通過(guò)公式(2)得到的服務(wù)節(jié)點(diǎn)綜合負(fù)載可認(rèn)為是服務(wù)節(jié)點(diǎn)處理性能的度量值,其值越大,服務(wù)節(jié)點(diǎn)的處理性能越差.

然而在實(shí)驗(yàn)中,我們發(fā)現(xiàn),當(dāng)任意負(fù)載指標(biāo)出現(xiàn)瓶頸時(shí)都會(huì)導(dǎo)致服務(wù)節(jié)點(diǎn)處理性能急劇下降,即當(dāng)服務(wù)節(jié)點(diǎn)CPU占用率超過(guò)一定閾值時(shí),即使到達(dá)該節(jié)點(diǎn)的鏈路的帶寬占用率很低,服務(wù)節(jié)點(diǎn)的處理性能仍然很差.因此在評(píng)估服務(wù)節(jié)點(diǎn)的處理性能時(shí),應(yīng)該著重考慮達(dá)到瓶頸或接近瓶頸的負(fù)載指標(biāo),所以在計(jì)算服務(wù)節(jié)點(diǎn)綜合負(fù)載大小時(shí),還需根據(jù)單個(gè)負(fù)載指標(biāo)的負(fù)載情況調(diào)整其在綜合負(fù)載評(píng)價(jià)中的權(quán)重大小.因此論文引入負(fù)反饋的方式,根據(jù)單個(gè)負(fù)載指標(biāo)的負(fù)載情況來(lái)動(dòng)態(tài)調(diào)整其權(quán)重大小.權(quán)重的負(fù)反饋調(diào)整公式如下:

(3)

(4)

5 實(shí)驗(yàn)評(píng)估

本文針對(duì)SDN下任意播實(shí)現(xiàn)負(fù)載均衡的路由轉(zhuǎn)發(fā)進(jìn)行模擬實(shí)驗(yàn).實(shí)驗(yàn)以服務(wù)器的響應(yīng)時(shí)間作為負(fù)載均衡策略的性能指標(biāo),將論文中設(shè)計(jì)的負(fù)載均衡路由策略與基于SDN實(shí)現(xiàn)的輪詢策略[14]和基于響應(yīng)時(shí)間的策略[11]進(jìn)行性能對(duì)比.

表1 節(jié)點(diǎn)配置
Table 1 Configuration of hosts

節(jié)點(diǎn)CPU/核內(nèi)存/MBSDN控制器48192Client42048Server142048Server221024Server31512

實(shí)驗(yàn)在五臺(tái)虛擬機(jī)上部署實(shí)現(xiàn)了論文提出的SDN任意播實(shí)現(xiàn)負(fù)載均衡的路由轉(zhuǎn)發(fā)系統(tǒng),并通過(guò)OpenvSwitch將虛擬機(jī)互連,網(wǎng)絡(luò)拓?fù)淙鐖D4所示.其中一個(gè)節(jié)點(diǎn)作為SDN控制器,Client節(jié)點(diǎn)作為任意播服務(wù)的客戶端,另外三臺(tái)作為任意播服務(wù)的服務(wù)端.各虛擬節(jié)點(diǎn)配置如表1所示.

圖4 網(wǎng)絡(luò)拓?fù)銯ig.4 Topology of network

如前文所述:在不同的應(yīng)用場(chǎng)景下,可能存在節(jié)點(diǎn)的某些資源占用率較低,但某些網(wǎng)絡(luò)資源消耗幾乎殆盡而導(dǎo)致性能急劇下降的情況,因此為了驗(yàn)證論文提出的權(quán)重自調(diào)節(jié)的基于權(quán)重的負(fù)載均衡路由選擇算法能夠適應(yīng)對(duì)網(wǎng)絡(luò)資源消耗不同的應(yīng)用場(chǎng)景,論文分為以下兩類不同應(yīng)用場(chǎng)景進(jìn)行實(shí)驗(yàn).

場(chǎng)景1.非CPU敏感型應(yīng)用場(chǎng)景.在此場(chǎng)景下,任意播服務(wù)是一個(gè)HTTP應(yīng)用,客戶端通過(guò)任意播地址請(qǐng)求HTTP服務(wù),三臺(tái)任意播服務(wù)器中的一臺(tái)將進(jìn)行響應(yīng)并返回一個(gè)HTML靜態(tài)頁(yè)面.該場(chǎng)景主要在網(wǎng)絡(luò)中傳輸一個(gè)HTML靜態(tài)頁(yè)面,對(duì)網(wǎng)絡(luò)帶寬消耗相對(duì)較多而對(duì)服務(wù)節(jié)點(diǎn)的CPU資源消耗較小.

場(chǎng)景2.CPU敏感型應(yīng)用場(chǎng)景.客戶端仍通過(guò)HTTP協(xié)議進(jìn)行任意播請(qǐng)求,與場(chǎng)景1不同的是,服務(wù)返回的是300次浮點(diǎn)運(yùn)算的結(jié)果,即返回計(jì)算密集型運(yùn)算的結(jié)果.該場(chǎng)景由于需要在服務(wù)節(jié)點(diǎn)進(jìn)行計(jì)算密集型運(yùn)算,因此該應(yīng)用場(chǎng)景對(duì)服務(wù)節(jié)點(diǎn)的CPU資源消耗較大而對(duì)帶寬等其他資源消耗較小.

實(shí)驗(yàn)時(shí),客戶機(jī)開(kāi)啟100個(gè)線程對(duì)任意播服務(wù)并發(fā)訪問(wèn)60s,每次訪問(wèn)間隔0.1s,最終對(duì)不同負(fù)載均衡策略下的任意播服務(wù)的響應(yīng)時(shí)間進(jìn)行統(tǒng)計(jì)比較.

為驗(yàn)證算法在節(jié)點(diǎn)負(fù)載不均衡的情況下仍然具有較好的負(fù)載均衡效果,在場(chǎng)景1中實(shí)驗(yàn)對(duì)服務(wù)節(jié)點(diǎn)初始負(fù)載不同的情況進(jìn)行了討論.在場(chǎng)景1中,實(shí)驗(yàn)將服務(wù)節(jié)點(diǎn)的CPU初始負(fù)載情況分為以下4類:

1)服務(wù)節(jié)點(diǎn)的CPU初始占用率均為0%;

2)服務(wù)節(jié)點(diǎn)的CPU初始占用率均為20%;

3)服務(wù)節(jié)點(diǎn)的CPU初始占用率均為50%;

4)服務(wù)節(jié)點(diǎn)的CPU初始占用率不同,節(jié)點(diǎn)Server1,Server2,Server3的CPU初始占用率分別為0%,20%,50%.

對(duì)上述四類情況分別進(jìn)行實(shí)驗(yàn),并且實(shí)驗(yàn)結(jié)果統(tǒng)計(jì)如圖5所示.圖5中橫坐標(biāo)的0%,20%,50%,DIFF分別對(duì)應(yīng)了上述的四類情況.由實(shí)驗(yàn)結(jié)果可知,對(duì)于服務(wù)節(jié)點(diǎn)的上述四類初始情況,論文提出的基于權(quán)值的算法的服務(wù)響應(yīng)時(shí)間均最少.其中,在三臺(tái)服務(wù)器節(jié)點(diǎn)初始負(fù)載不相同(即第四類)的情況下,論文提出的負(fù)載均衡策略的響應(yīng)時(shí)間較輪選算法縮短了大約17.9%,較基于響應(yīng)時(shí)間算法縮短了大約14.04%.結(jié)果證明,在場(chǎng)景1下,論文提出的帶有負(fù)反饋的基于權(quán)重的負(fù)載均衡路由選擇算法在上述四類的情況下均有較好負(fù)載均衡效果.

圖5 場(chǎng)景1下實(shí)驗(yàn)結(jié)果數(shù)據(jù)Fig.5 Statistics data of experiment in scenario 1

場(chǎng)景2下實(shí)驗(yàn)僅對(duì)服務(wù)器初始負(fù)載不相同的情況進(jìn)行實(shí)驗(yàn).在該場(chǎng)景下任意播服務(wù)對(duì)服務(wù)節(jié)點(diǎn)CPU資源消耗較大,因此該場(chǎng)景下CPU資源將是影響服務(wù)質(zhì)量的最主要因素,若算法能夠有效均衡節(jié)點(diǎn)間CPU資源消耗量,便能避免CPU資源幾乎消耗殆盡導(dǎo)致服務(wù)質(zhì)量嚴(yán)重變差的問(wèn)題.為驗(yàn)證論文為基于權(quán)重算法引入的負(fù)反饋機(jī)制能有效控制服務(wù)對(duì)資源的過(guò)量消耗,論文在該場(chǎng)景下分別對(duì)引入負(fù)反饋機(jī)制的權(quán)重負(fù)載均衡算法(Weight-based Load-balancing algorithm with feedback,WLAWF)和未引入負(fù)反饋的權(quán)重負(fù)載均衡算法(Weight-based Load-balancing algorithm with no feedback,WLAWNF)進(jìn)行實(shí)驗(yàn),并統(tǒng)計(jì)對(duì)比不同算法下服務(wù)節(jié)點(diǎn)CPU資源消耗的情況,得出算法對(duì)資源閾值的控制能力.該場(chǎng)景下實(shí)驗(yàn)結(jié)果如表2所示.

由表2數(shù)據(jù)可知,在該應(yīng)用場(chǎng)景下,引入負(fù)反饋機(jī)制的基于權(quán)值算法的響應(yīng)時(shí)間較輪詢算法縮短了18.1%,較基于響應(yīng)時(shí)間算法縮短了17%,且基于權(quán)值算法的響應(yīng)時(shí)間方差最小.從服務(wù)的平均響應(yīng)時(shí)間和響應(yīng)時(shí)間方差可看出,WLAWF算法負(fù)載均衡性能優(yōu)于WLAWNF算法.

表2 場(chǎng)景2下實(shí)驗(yàn)結(jié)果數(shù)據(jù)
Table 2 Statistics data of experiment in scenario 2

實(shí)現(xiàn)方案算法平均響應(yīng)時(shí)間/s響應(yīng)時(shí)間方差主動(dòng)下發(fā)流表輪詢算法0.017580.0003572基于響應(yīng)時(shí)間算法0.017340.0003078負(fù)反饋基于權(quán)值算法0.014390.0002795樸素基于權(quán)重算法0.014920.0002843被動(dòng)下發(fā)流表基于權(quán)值算法0.094720.0002897

論文還對(duì)流表的兩種不同下發(fā)實(shí)現(xiàn)方案進(jìn)行了比較,見(jiàn)表2,被動(dòng)下發(fā)流表實(shí)現(xiàn)方案由于每次對(duì)任意播服務(wù)的請(qǐng)求都需要上發(fā)控制器,因此產(chǎn)生了較大的額外時(shí)延,在實(shí)驗(yàn)中,上發(fā)控制器產(chǎn)生了平均8ms的額外時(shí)延.因此被動(dòng)下發(fā)流表實(shí)現(xiàn)方案效率低下,且存在前文所述的性能瓶頸和單點(diǎn)失效的缺點(diǎn).

圖6 場(chǎng)景2下輪詢算法各節(jié)點(diǎn)CPU占用情況Fig.6 CPU utilization of servers of Round-Robin algorithm in scenario 2

不同算法在場(chǎng)景2下各服務(wù)節(jié)點(diǎn)CPU占用率的統(tǒng)計(jì)圖如圖6至圖8所示.由圖6可以看出,輪詢算法只能做到均衡地把服務(wù)請(qǐng)求分發(fā)給不同服務(wù)節(jié)點(diǎn),而無(wú)法真正均衡節(jié)點(diǎn)間的負(fù)載,從而使得性能最優(yōu)且初始負(fù)載最小的Server1的CPU資源沒(méi)能充分利用,而性能最差的Server3的CPU資源接近飽和,自然該算法下的服務(wù)質(zhì)量最差.而對(duì)比圖7、圖8可知,WLAWNF的和WLAWF算法均能較為有效地利用各節(jié)點(diǎn)的CPU資源,均衡節(jié)點(diǎn)間CPU資源的消耗.然而WLAWNF算法僅能基于固定權(quán)重評(píng)估節(jié)點(diǎn)的綜合負(fù)載,無(wú)法考慮資源消耗接近飽和或超過(guò)一定閾值的情況,因而沒(méi)能通過(guò)動(dòng)態(tài)調(diào)整權(quán)重來(lái)避免將新的請(qǐng)求分配給資源消耗超過(guò)閾值的節(jié)點(diǎn).對(duì)于WLAWF算法,利用資源當(dāng)前的消耗量來(lái)動(dòng)態(tài)調(diào)整權(quán)重,考量節(jié)點(diǎn)綜合負(fù)載時(shí),優(yōu)先考慮資源消耗大的因素,因此在圖8中,當(dāng)節(jié)點(diǎn)的CPU占用率較高時(shí),其CPU占用率成為節(jié)點(diǎn)負(fù)載的主要考量因素,因此算法會(huì)將新的請(qǐng)求分配給當(dāng)前CPU負(fù)載較小的節(jié)點(diǎn),達(dá)到均衡負(fù)載的效果.

圖7 場(chǎng)景2下WLAWNF算法各節(jié)點(diǎn)CPU占用情況Fig.7 CPU utilization of servers of WLAWNF in scenario 2

圖8 場(chǎng)景2下有負(fù)反饋的基于權(quán)重算法各節(jié)點(diǎn)CPU占用情況Fig.8 CPU utilization of servers of WLAWF in scenario 2

6 結(jié) 論

論文對(duì)SDN下任意播實(shí)現(xiàn)負(fù)載均衡的路由轉(zhuǎn)發(fā)進(jìn)行研究,實(shí)現(xiàn)了一套基于SDN技術(shù)的任意播負(fù)載均衡路由轉(zhuǎn)發(fā)原型系統(tǒng),討論了不同流表下發(fā)實(shí)現(xiàn)方案的優(yōu)缺點(diǎn),同時(shí)設(shè)計(jì)了一套權(quán)重自適應(yīng)調(diào)整的基于權(quán)值的任意播負(fù)載均衡路由選擇算法,實(shí)驗(yàn)證明了論文提出的SDN下的任意播負(fù)載均衡路由系統(tǒng)以及策略具有較好的負(fù)載均衡性能.