當前位置:
首頁 > 最新 > 一種基於SDN的伺服器負載均衡方案

一種基於SDN的伺服器負載均衡方案

摘要:目前傳統網路的負載均衡存在硬體設備高成本或軟體架構高消耗的缺點。因此,提出基於軟體定義網路(SDN)的伺服器負載均衡方案,實現了伺服器負載均衡服務的可編程化,降低了成本與消耗。利用SDN控制層面和數據層面分離的特性,控制器下發流表管理交換機進行負載均衡工作。在獨立的SDN控制器Floodlight中,通過Java腳本部署該負載均衡方案,支持多種負載均衡與鏈路選擇演算法。搭建SDN環境實驗並使用Wireshark抓包提取交換機的流表,實驗證明所提方案能夠實現面向連接的伺服器負載均衡。

正文內容:

0 引言

網路已經成為許多商業的支撐脊柱,世界網路中每天都有新的設備加入,致使網路規模巨大化。眾多的網路設備不僅意味著需要投入更多的資源,且使網路結構越加複雜化,管理難度增大且易錯。為了避免網路管理錯誤的發生,一種新型的網路架構出現,即軟體定義網路(Software Defined Networking,SDN)[1]。SDN技術旨在實現控制層與數據層面的分離,而控制層是物理上集中的一系列控制器。這些控制器通過開發一系列應用能夠檢測和管理網路行為,實現網路可編程化。SDN可以實現各種傳統物理網路的功能,如負載均衡。軟體定義網路中的控制器通過改變數據平面交換機的流表項來調整受影響的流到冗餘路徑上傳輸,從而避免網路資源被過度佔用[2]。

在雲場景中,LBaaS(Load Balancing as a Service,負載均衡即服務)是Openstack[3]雲計算平台已經投入研究的負載均衡解決方案。但是,它搭載的Openstack項目——網路和地址管理(Neutron)僅能實現指定目標的網路訪問。在大型雲應用場景中,LBaaS並不能支撐起負載均衡業務。於是,Openstack中將SDN作為Neutron模塊的一個插件發展網路業務解決LBaaS的局限,如NFV(Network Function Virtualization,網路功能虛擬化)。Window基於雲平台的操作系統Azure中的雲規模負載均衡方案(Ananta)[4],也借鑒於SDN的控制層面和數據平面分離的架構,實現了雲規模下可擴展的基於軟體的四層地址轉換負載均衡服務。它的控制部分不能檢測網路中大小負載的流量,將數據部分規模設計得很大,成本相應也增大。相比於前兩者,SDN擁有獨立的控制器來自主管理網路,可支持編程完成指定業務;不似Anata,SDN將控制層面和數據平面分別以不同的軟體運行,並以網路介面連接,內部程序互不干擾。目前,對於SDN環境中的負載均衡以演算法研究為主,方案部署研究甚少。在以SDN架構為主的Google的B4[5]網路中,也沒有合適的負載均衡方案。

SDN的開源控制器有NOX、Opendaylight、RYU和Floodlight等[6]。Floodlight集成了SDN的控制層與部分應用層,內部的南向介面通過Restful API實現。比起NOX、POX以及Maestro幾款SDN控制器,Floodlight擁有更好的性能,支持各個應用模塊,同時處理Openflow消息[7]。本文提出的負載均衡方案作為一個應用模塊,運行在Floodlight控制器程序框架中,可同時擴展伺服器負載均衡演算法與路徑選擇的負載均衡方案。實驗環境基於Mininet[8]模擬,每個節點默認的配置相同,伺服器群的均衡策略採用輪詢演算法,路徑則選擇最短路徑。模塊中添加多個網路檢測參數,使得此方案可擴展性強。

1 負載均衡方案

1.1 Laodbalancer邏輯架構

本文將負載均衡方案部署為一個封裝的應用模塊(Loadbalancer),並整合在Floodlight的程序框架中。按照此次的試驗環境,負載均衡方案架構顯示如圖1所示。Floodlight用Restful API實現南向介面連接控制器模塊與應用模塊,網路遠程連接實現其北向介面至Mininet軟體模擬的網路,檢測網路數據並下發流表到各Openflow交換機。Loaderbalancer作為整合在其中的一項應用,參與流表的制定。交換機按照流表進行數據傳輸,即實現了負載均衡服務。

1.2 Loadbalancer服務過程

負載均衡的服務過程中包含了分析Packet_In消息、負載均衡決策、路徑選擇以及流表下發。圖2為整個負載均衡服務的通信流程。

①主機發送請求包(Request Packet),此處dstIp=VIPIp;

②交換機檢測到其流表中不存在與此Request packet相匹配的流表,即發送Packet_In包向控制器請求決策,此處dstIp=VIPIp;

③首先Floodlight控制器檢測到Packet_In消息中的VIP地址與其Port之後,即調用負載均衡演算法,經由演算法選擇Mininet創建的虛擬伺服器。選擇目標伺服器後,計算主機到目標伺服器的路徑(選擇跳數最少的路徑),並將其進向路由以流表的方式下發到Openswitch(pushInVipRoutes)。其次,進行地址轉換,將Request Packet的目的IP地址與Mac地址,由dstIp=VIPIp、dstMac=VIPMac轉換為負載均衡策略選中伺服器的IP地址與MAC地址dstIp=SeverIp、dstMac=SeverMac。最後,發送Packet_out到Openswitch,通知對此包按照下發流表工作;

④Sever收到dstIp=SeverIp、srcIp=HostIp的Request packet;

⑤Sever回復主機發送的Reply packet,dstIp=HostIp,srcIp=SeverIp;

⑥同第②步,發送Packet_out至控制器,此處srcIp=SeverIp;

⑦同第③步,首先找到伺服器到主機的路徑,其次進行地址轉換;

⑧主機收到dstIp=HostIp、srcIp=VIPIp的Request Packet。

第一次通信流程結束後,Openswitch將流表進行存儲,之後需要相同路徑的連接直接通過交換機轉發。

1.3 輪詢調度演算法

在SDN環境中,虛擬伺服器都有相同的配置,輪詢調度演算法可以節約負載策略耗費的時間。在Floodlight控制器中,負載均衡策略採用輪詢調度演算法能夠為其他模塊提供計算空間。輪詢調度演算法將每一次來自網路的請求都可以輪流分配給內部中的伺服器,從1到 ,然後重新循環。它每次調度執行 ,並選出第 台伺服器。

輪詢調度演算法的相關代碼如下:

public String pickMember(IPClient client){

if (members.size()>0){

previousMemberIndex=(previousMemberIndex +1)%members.size();

return members.get(previousMemberIndex);

}

else{

return null;}

2 實驗及分析

本方案的實驗操作系統採用的是Ubuntu。SDN數據平面由虛擬機中的Mininet搭建,運行在主機中的Floodlight作為控制器與負載均衡器。Floodlight支持網路可視化,通過訪問其埠頁面可以發現網路拓撲、網路連接、交換機流表、交換機以及主機信息。

2.1 配置Loadbalancer

在Ubuntu的主機終端,通過API開啟Floodlight的負載均衡服務。此次試驗分別創建了2個VIP實現ICMP與TCP負載均衡服務.圖3、圖4分別是參數配置和返回的數據。

2.2 創建實驗拓撲圖

圖5是本次試驗的拓撲結構圖。由於本文的負載均衡方案是面向連接的,UDP協議數據傳輸完後不需要斷開連接。流錶轉發方式與ICMP類似,所以本文中不再進行UDP協議的測試。試驗中,首先通過在Mininet中分別使用h1~h5、he1~he6發起4次對VIP1的請求,模擬ICMP請求的網路訪問情況;其次發起Wget訪問VIP2,模擬TCP協議負載均衡情況;最後為了驗證本文是面向連接的,使用同一台主機多次對VIP2進行Wget訪問。

2.3 實驗結果分析

由Wireshark在Open-Switch3的eth1、eth2、eth3抓包分析可以得出,10台主機中,4台與server11連接,3台與server12連接,3台與server13連接,並以輪詢選擇的方式進行ICMP通信。圖6是Wireshark在ICMP負載均衡時各伺服器的流量情況。

整個用戶網路向ICMP伺服器共發起了10起訪問,每起4次,並被輪詢分配到不同伺服器下。圖7為通過wireshark在某一主機端的抓包分析。可見,它的數據包的目的地址已經被轉換為VIP1的地址。

通過負載均衡服務找到路徑並下發流表後,交換機會自動記錄流表,下次收到同樣請求包時會自動按照流表下發。圖8通過控制器的顯示頁面查詢Open-Switch3中記錄的流表,從中亦可以分析出本文提出的負載均衡方案實現了面向連接的伺服器均衡。為了再次驗證,本文繼續採用TCP協議進行實驗。

圖9是使用10台主機對VIP2發起Wget訪問的結果,圖10則是使用同一台主機對VIP2發起10次Wget訪問。理論上,由於TCP協議是無狀態的連接,每次協議完成後會自動斷開連接。而本文的均衡方案是面向連接,所以兩次訪問的結果相同。實驗結果顯示與理論一致,證明本文的負載均衡方案適合於面向連接的負載均衡。從圖11的Open-Switch3的流表可以得出,同一主機多次訪問VIP2時,數據包輪換通過不同埠,證實了訪問過程由不同的伺服器輪換進行響應。

與ICMP協議均衡不同的是,針對TCP協議,此方案保存在交換機內的流表是不可用的。TCP協議著重於其可靠性,數據傳輸結束後會關閉連接,因此待到下一次連接時,交換機收到的包數據與存在流表記錄中的數據不同。此時,交換需要再次向Floodlight提取解析目的地址的請求,由Loadbalancer重新決策選擇目的伺服器,並決定其傳輸路徑。

3 結 語

相比於傳統網路,SDN能夠更好地統籌網路,並控制網路中的流量轉發。本文利用SDN的全局網路視圖,提出了一個擴展性極高、靈活性強的基於Floodlight控制器的負載均衡方案。運用Floodlight的Rest API設置負載均衡參數進行實驗,並通過Wireshak抓包驗證了其在伺服器間的均衡結果良好,能夠解決網路的擁塞問題,提高網路的服務技能。SDN控制器的可移植性高,網路業務發展前景巨大。網路控制權的集中不僅使負載均衡服務成本降低、易實現,且網路中其他節點不必再進行負載計算,消耗減小。

但是,本方案的弊端仍然存在。

(1)Monitor會一直認為Pool中的所有負載均衡成員都處於活躍狀態,即都能夠處理網路請求,所有的成員會一直出現在VIP的分發列表中,即使成員對應的主機不能響應網路請求,這在實際應用中會造成負載均衡的響應異常;

(2)目前只能實現ARP、TCP、UDP和ICMP包的負載均衡;

(3)未對路徑選擇加以更加優秀的演算法,直接選擇了路由跳數最小的最短路徑。

如何尋找到更優秀的負載均衡演算法,是解決本文不足的關鍵。目前,不少研究者基於SDN負載均衡演算法進行了研究。文獻[9]提出一種可以優化負載均衡問題的粒子群化演算法,以鏈路的帶寬使用率最接近為負載均衡決策下發到Openflow交換機的準則;文獻[10]基於馬爾科夫鏈演算法選出最優負載均衡的路徑;文獻[11]則提取傳輸路徑的特性,訓練BP神經網路預測綜合負載並選擇最小負載的路徑。比較眾多的負載均衡演算法,適當擴展到本文提出的負載均衡方案中,需要做更進一步的研究。

參考文獻:

[1] 范偉.軟體定義網路及應用[J].通信技術,2013(03):67-70.

[2] 程克非,高江明,段潔等.面向SDN的數據中心網路更新研究綜述[J].電訊技術,2017,57(10):1224-1232.

[3] Jackson K,Bunch C,Sigler E.OpenStack Cloud Computing Cookbook[M].Packt Publishing,2015:121-165.

[4] Patel P,Bansal D,Yuan L,et al.Ananta:Cloud Scale Load Balancing[J].Computer Communication Review,2013,43(04):207-218.

[5] 張衛峰.走近Google基於SDN的B4網路[J].程序員,2013(11):100-104.

[6] 房秉毅,張歌,張雲勇等.開源SDN控制器發展現狀研究[J].郵電設計技術,2014(07):29-36.

[7] Erickson D.The Beacon Openflow Controller[C].ACM SIGCOMM Workshop on Hot Topics in Software Defined Networking ACM,2013:13-18.

[8] Kaur K,Singh J,Ghumman N S.Mininet as Software Defined Networking Testing Platform[C].International Conference on Communiction,Computing & Systems,2014.

[9] 曹欲曉,徐金寶.基於粒子群優化的SDN負載均衡研究[J].現代計算機,2016(29):18-21.

[10]王春枝,羅晨,陳宏偉.SDN中基於負載均衡的最優路徑分配演算法研究[J].計算機應用研究,2016,33(08):2462-2466.

[11]CUI Chen-xiao,XU Ya-bin.Research on Load Balance Method in SDN[C].International Journal of Grid and Distributed Computing,2016:25-36.

作者:唐月婷1,蔣朝惠2

單位:1.貴州大學 大數據與信息工程學院,貴州 貴陽 550025;

2.貴州大學 計算機科學與技術學院,貴州 貴陽550025

作者簡介:唐月婷,女,碩士,主要研究方向為大數據與通信網路、通信網路安全;

蔣朝惠,男,碩士,教授,主要研究方向為雲計算與大數據、網路信息安全。

本文刊登在《通信技術》2018年第5期(轉載請註明出處,否則禁止轉載)

喜歡這篇文章嗎?立刻分享出去讓更多人知道吧!

本站內容充實豐富,博大精深,小編精選每日熱門資訊,隨時更新,點擊「搶先收到最新資訊」瀏覽吧!


請您繼續閱讀更多來自 通信技術編輯部 的精彩文章:

三維視頻的深度圖快速編碼演算法

TAG:通信技術編輯部 |