SDN下的IPv6任意播實現負載均衡的路由算法研究

樊 偉,徐 華,李 京

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

1 引 言

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

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

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

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

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

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

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

最終,論文通過實驗證明了論文提出的任意播負載均衡路由架構和負載均衡路由選擇算法有較好的負載均衡性能.同時實驗表明,論文對權重算法引入的負反饋機制能夠有效避免網絡資源消耗不均勻導致一些資源消耗過度使得性能急劇下降的情況.

2 相關工作

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

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

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

由于在傳統網絡架構中,往往存在負載均衡路由策略不靈活,簡單負載均衡算法無法進行準確的路由選擇,而復雜算法又會增加網絡交換設備的負載的缺點.隨著SDN網絡架構技術的興起,研究學者們開始嘗試使用SDN技術解決傳統網絡架構下負載均衡存在的缺陷.

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

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

3 基于SDN的任意播路由轉發系統

本章節主要對SDN下的任意播路由轉發網絡架構,原型系統的設計以及OpenFlow交換機流表的設計進行闡述.

3.1 基于SDN的任意播負載均衡路由網絡框架

如圖1所示,本論文設計的基于SDN的任意播路由轉發網絡架構的主干網絡由OpenFlow交換機構成,且要求任意播服務的客戶端和服務端都需要直接或間接連接到該主干網絡,即均通過由OpenFlow交換機構成的網絡互聯,OpenFlow交換機中的數據流轉發規則由SDN控制器集中控制,因此利用SDN的可編程性,向控制器中集成實現負載均衡的任意播路由選擇算法,將不同任意播數據流根據控制器采集到的負載信息轉發向不同服務節點,便可實現負載均衡.

圖1 基于SDN的任意播路由轉發網絡架構Fig.1 Network framework of SDN-based anycast route system

本論文實現負載均衡的任意播路由轉發過程如圖1所示,分為以下4個步驟:

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

Step2.數據分組經過OpenFlow交換機構成的網絡時,通過集成于SDN控制器中的負載均衡路由選擇策略選擇出最佳任意播服務節點,然后將數據分組的目的地址更改為服務節點的單播地址,并將數據分組路由到該服務節點;

Step3.服務節點對服務請求進行響應;

Step4.OpenFlow網絡將響應數據分組的源地址由服務節點的單播地址更改為任意播地址,并轉發給客戶端.

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

3.2 基于SDN的任意播負載均衡路由系統架構

如上一節上述,任意播的負載均衡路由轉發主要通過由OpenFlow交換機組成的SDN網絡以及SDN控制器共同實現,其中SDN網絡主要根據SDN控制器下發的數據流轉發規則進行地址轉換和數據轉發,因此SDN控制器如何生成合理的數據轉發規則是路由系統的核心.

本論文選取Ryu作為路由系統的控制器,由于Ryu是基于模塊化的設計架構實現的,所以本論文通過向Ryu控制器中添加模塊的方式對Ryu控制器進行擴展,故路由系統的架構如圖2所示,圖中未畫出Ryu的原有模塊.

圖2 基于SDN的任意播負載均衡路由系統架構Fig.2 Framework of SDN-based anycast route system

如圖2所示,架構中主要包含6個模塊和一個策略池:

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

2)負載采集模塊:該模塊除了從任意播模塊獲取服務節點的負載信息外,還通過OpenFlow協議定期主動獲取網絡鏈路負載信息;

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

4)流表控制模塊:根據負載均衡路由選擇的結果生成OpenFlow流表更新規則,并通過OpenFlow協議更新OpenFlow交換機的流表,從而更新SDN網絡的任意播數據轉發規則.

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

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

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

3.3 流表設計

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

由于OpenFlow協議本身不支持有狀態協議,即OpenFlow交換機內的流表只能基于規則對數據包進行無狀態的匹配轉發.這會導致基于SDN實現的路由系統無法支持類似TCP這樣有狀態,基于連接的協議.在被動下發流表實現方案下,控制器會針對每一次連接生成相應的數據包匹配處理流表,通過對原地址和目的地址的匹配,能夠區分數據包所屬的連接,這樣就可以將屬于同一連接的數據包路由到同一服務節點,實現對有狀態協議的支持.然而在主動下發實現方案中,控制器只是周期地更新SDN網絡中任意播的處理流表,無法針對每次連接生成區分其他連接的匹配域,因此本論文利用Conntrack[16,17]模塊對數據包的連接狀態進行追蹤和分類.Conntrack是Linux內核中的一個跟蹤記錄連接狀態的模塊,通常該模塊被用于實現有狀態的防火墻,本論文則利用該模塊在交換機內實現有狀態的負載均衡.Conntrack內部為每一個連接實現了狀態機,論文利用該狀態機,將無狀態的數據包轉變為帶有連接狀態的數據包,從而區分數據包所屬的連接.

圖3 主動下發流表實現方案的流表設計Fig.3 Design of flow table in active mode

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

3.4 系統可擴展性分析

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

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

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

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

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

4 負載均衡路由選擇算法

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

li=max(uij)

(1)

綜合考慮以上五種負載指標,按照不同的權重來計算服務節點的權值,該權值代表了服務器的綜合負載,且權值越高,服務器的綜合負載越大,故論文設計的權值計算公式如下:

H=WTL

(2)

其中L是上述五個負載指標的負載情況向量,W則是影響因素對應的權重向量.通過公式(2)得到的服務節點綜合負載可認為是服務節點處理性能的度量值,其值越大,服務節點的處理性能越差.

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

(3)

(4)

5 實驗評估

本文針對SDN下任意播實現負載均衡的路由轉發進行模擬實驗.實驗以服務器的響應時間作為負載均衡策略的性能指標,將論文中設計的負載均衡路由策略與基于SDN實現的輪詢策略[14]和基于響應時間的策略[11]進行性能對比.

表1 節點配置
Table 1 Configuration of hosts

節點CPU/核內存/MBSDN控制器48192Client42048Server142048Server221024Server31512

實驗在五臺虛擬機上部署實現了論文提出的SDN任意播實現負載均衡的路由轉發系統,并通過OpenvSwitch將虛擬機互連,網絡拓撲如圖4所示.其中一個節點作為SDN控制器,Client節點作為任意播服務的客戶端,另外三臺作為任意播服務的服務端.各虛擬節點配置如表1所示.

圖4 網絡拓撲Fig.4 Topology of network

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

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

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

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

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

1)服務節點的CPU初始占用率均為0%;

2)服務節點的CPU初始占用率均為20%;

3)服務節點的CPU初始占用率均為50%;

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

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

圖5 場景1下實驗結果數據Fig.5 Statistics data of experiment in scenario 1

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

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

表2 場景2下實驗結果數據
Table 2 Statistics data of experiment in scenario 2

實現方案算法平均響應時間/s響應時間方差主動下發流表輪詢算法0.017580.0003572基于響應時間算法0.017340.0003078負反饋基于權值算法0.014390.0002795樸素基于權重算法0.014920.0002843被動下發流表基于權值算法0.094720.0002897

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

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

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

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

圖8 場景2下有負反饋的基于權重算法各節點CPU占用情況Fig.8 CPU utilization of servers of WLAWF in scenario 2

6 結 論

論文對SDN下任意播實現負載均衡的路由轉發進行研究,實現了一套基于SDN技術的任意播負載均衡路由轉發原型系統,討論了不同流表下發實現方案的優缺點,同時設計了一套權重自適應調整的基于權值的任意播負載均衡路由選擇算法,實驗證明了論文提出的SDN下的任意播負載均衡路由系統以及策略具有較好的負載均衡性能.