樊 偉,徐 華,李 京

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

1 引 言

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

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

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

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

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

導(dǎo)致現(xiàn)有相關(guā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ù)雜路由算法會增加交換設(shè)備負(fù)載;第三,控制平面和轉(zhuǎn)發(fā)平面緊耦合,導(dǎo)致路由策略缺乏靈活性.軟件定義網(wǎng)絡(luò)[2](SDN)作為一種新興的基于軟件的網(wǎng)絡(luò)架構(gòu)及技術(shù),能夠?qū)⒔粨Q設(shè)備中的控制平面從設(shè)備中抽離,以實現(xiàn)控制平面與數(shù)據(jù)平面相分離,并通過邏輯上集中的控制層面,對分散的網(wǎng)絡(luò)設(shè)備進行集中控制管理.因此為了解決現(xiàn)有研究中任意播負(fù)載均衡路由策略的諸多問題,論文基于SDN架構(gòu)對IPv6任意播實現(xiàn)負(fù)載均衡的路由選擇算法進行研究,提出了SDN下的一套任意播路由轉(zhuǎn)發(fā)框架以及一種基于權(quán)值的任意播實現(xiàn)負(fù)載均衡的路由選擇算法.

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

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

2 相關(guān)工作

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Step3.服務(wù)節(jié)點對服務(wù)請求進行響應(yīng);

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

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

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

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

本論文選取Ryu作為路由系統(tǒng)的控制器,由于Ryu是基于模塊化的設(shè)計架構(gòu)實現(xiàn)的,所以本論文通過向Ryu控制器中添加模塊的方式對Ryu控制器進行擴展,故路由系統(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個模塊和一個策略池:

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

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

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

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

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

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

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

3.3 流表設(shè)計

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

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

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

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

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

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

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

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

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

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

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

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

li=max(uij)

(1)

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

H=WTL

(2)

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

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

(3)

(4)

5 實驗評估

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圖5 場景1下實驗結(jié)果數(shù)據(jù)Fig.5 Statistics data of experiment in scenario 1

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

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

表2 場景2下實驗結(jié)果數(shù)據(jù)
Table 2 Statistics data of experiment in scenario 2

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

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

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

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

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

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

6 結(jié) 論

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