一種基于SDN的服務(wù)器負(fù)載均衡方案*

唐月婷，蔣朝惠

（1.貴州大學(xué) 大數(shù)據(jù)與信息工程學(xué)院，貴州 貴陽(yáng) 550025；2.貴州大學(xué) 計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院，貴州 貴陽(yáng)550025）

0 引 言

網(wǎng)絡(luò)已經(jīng)成為許多商業(yè)的支撐脊柱，世界網(wǎng)絡(luò)中每天都有新的設(shè)備加入，致使網(wǎng)絡(luò)規(guī)模巨大化。眾多的網(wǎng)絡(luò)設(shè)備不僅意味著需要投入更多的資源，且使網(wǎng)絡(luò)結(jié)構(gòu)越加復(fù)雜化，管理難度增大且易錯(cuò)。為了避免網(wǎng)絡(luò)管理錯(cuò)誤的發(fā)生，一種新型的網(wǎng)絡(luò)架構(gòu)出現(xiàn)，即軟件定義網(wǎng)絡(luò)（Software Defined Networking，SDN）[1]。SDN技術(shù)旨在實(shí)現(xiàn)控制層與數(shù)據(jù)層面的分離，而控制層是物理上集中的一系列控制器。這些控制器通過開發(fā)一系列應(yīng)用能夠檢測(cè)和管理網(wǎng)絡(luò)行為，實(shí)現(xiàn)網(wǎng)絡(luò)可編程化。SDN可以實(shí)現(xiàn)各種傳統(tǒng)物理網(wǎng)絡(luò)的功能，如負(fù)載均衡。軟件定義網(wǎng)絡(luò)中的控制器通過改變數(shù)據(jù)平面交換機(jī)的流表項(xiàng)來(lái)調(diào)整受影響的流到冗余路徑上傳輸，從而避免網(wǎng)絡(luò)資源被過度占用[2]。

在云場(chǎng)景中，LBaaS（Load Balancing as a Service，負(fù)載均衡即服務(wù)）是Openstack[3]云計(jì)算平臺(tái)已經(jīng)投入研究的負(fù)載均衡解決方案。但是，它搭載的Openstack項(xiàng)目——網(wǎng)絡(luò)和地址管理（Neutron）僅能實(shí)現(xiàn)指定目標(biāo)的網(wǎng)絡(luò)訪問。在大型云應(yīng)用場(chǎng)景中，LBaaS并不能支撐起負(fù)載均衡業(yè)務(wù)。于是，Openstack中將SDN作為Neutron模塊的一個(gè)插件發(fā)展網(wǎng)絡(luò)業(yè)務(wù)解決LBaaS的局限，如NFV（Network Function Virtualization，網(wǎng)絡(luò)功能虛擬化）。Window基于云平臺(tái)的操作系統(tǒng)Azure中的云規(guī)模負(fù)載均衡方案（Ananta）[4]，也借鑒于SDN的控制層面和數(shù)據(jù)平面分離的架構(gòu)，實(shí)現(xiàn)了云規(guī)模下可擴(kuò)展的基于軟件的四層地址轉(zhuǎn)換負(fù)載均衡服務(wù)。它的控制部分不能檢測(cè)網(wǎng)絡(luò)中大小負(fù)載的流量，將數(shù)據(jù)部分規(guī)模設(shè)計(jì)得很大，成本相應(yīng)也增大。相比于前兩者，SDN擁有獨(dú)立的控制器來(lái)自主管理網(wǎng)絡(luò)，可支持編程完成指定業(yè)務(wù)；不似Anata，SDN將控制層面和數(shù)據(jù)平面分別以不同的軟件運(yùn)行，并以網(wǎng)絡(luò)接口連接，內(nèi)部程序互不干擾。目前，對(duì)于SDN環(huán)境中的負(fù)載均衡以算法研究為主，方案部署研究甚少。在以SDN架構(gòu)為主的Google的B4[5]網(wǎng)絡(luò)中，也沒有合適的負(fù)載均衡方案。

SDN的開源控制器有NOX、Opendaylight、RYU 和 Floodlight等[6]。Floodlight集 成 了 SDN 的控制層與部分應(yīng)用層，內(nèi)部的南向接口通過Restful API實(shí)現(xiàn)。比起NOX、POX以及Maestro幾款SDN控制器，F(xiàn)loodlight擁有更好的性能，支持各個(gè)應(yīng)用模塊，同時(shí)處理Openflow消息[7]。本文提出的負(fù)載均衡方案作為一個(gè)應(yīng)用模塊，運(yùn)行在Floodlight控制器程序框架中，可同時(shí)擴(kuò)展服務(wù)器負(fù)載均衡算法與路徑選擇的負(fù)載均衡方案。實(shí)驗(yàn)環(huán)境基于Mininet[8]仿真，每個(gè)節(jié)點(diǎn)默認(rèn)的配置相同，服務(wù)器群的均衡策略采用輪詢算法，路徑則選擇最短路徑。模塊中添加多個(gè)網(wǎng)絡(luò)檢測(cè)參數(shù)，使得此方案可擴(kuò)展性強(qiáng)。

1 負(fù)載均衡方案

1.1 Laodbalancer邏輯架構(gòu)

本文將負(fù)載均衡方案部署為一個(gè)封裝的應(yīng)用模塊（Loadbalancer），并整合在Floodlight的程序框架中。按照此次的試驗(yàn)環(huán)境，負(fù)載均衡方案架構(gòu)顯示如圖1所示。Floodlight用Restful API實(shí)現(xiàn)南向接口連接控制器模塊與應(yīng)用模塊，網(wǎng)絡(luò)遠(yuǎn)程連接實(shí)現(xiàn)其北向接口至Mininet軟件仿真的網(wǎng)絡(luò)，檢測(cè)網(wǎng)絡(luò)數(shù)據(jù)并下發(fā)流表到各Openflow交換機(jī)。Loaderbalancer作為整合在其中的一項(xiàng)應(yīng)用，參與流表的制定。交換機(jī)按照流表進(jìn)行數(shù)據(jù)傳輸，即實(shí)現(xiàn)了負(fù)載均衡服務(wù)。

圖1 Loadbalancer的架構(gòu)

1.2 Loadbalancer服務(wù)過程

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

圖2 Loadbalancer服務(wù)通信流程

①主機(jī)發(fā)送請(qǐng)求包（Request Packet），此處dstIp=VIPIp；

②交換機(jī)檢測(cè)到其流表中不存在與此Request packet相匹配的流表，即發(fā)送Packet_In包向控制器請(qǐng)求決策，此處dstIp=VIPIp；

③首先Floodlight控制器檢測(cè)到Packet_In消息中的VIP地址與其Port之后，即調(diào)用負(fù)載均衡算法，經(jīng)由算法選擇Mininet創(chuàng)建的虛擬服務(wù)器。選擇目標(biāo)服務(wù)器后，計(jì)算主機(jī)到目標(biāo)服務(wù)器的路徑（選擇跳數(shù)最少的路徑），并將其進(jìn)向路由以流表的方式下發(fā)到Openswitch（pushInVipRoutes）。其次，進(jìn)行地址轉(zhuǎn)換，將Request Packet的目的IP地址與Mac地址，由dstIp=VIPIp、dstMac=VIPMac轉(zhuǎn)換為負(fù)載均衡策略選中服務(wù)器的IP地址與MAC地址 dstIp=SeverIp、dstMac=SeverMac。 最 后， 發(fā) 送Packet_out到Openswitch，通知對(duì)此包按照下發(fā)流表工作；

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

⑤Sever回復(fù)主機(jī)發(fā)送的Reply packet，dstIp=HostIp，srcIp=SeverIp；

⑥同第②步，發(fā)送Packet_out至控制器，此處srcIp=SeverIp；

⑦同第③步，首先找到服務(wù)器到主機(jī)的路徑，其次進(jìn)行地址轉(zhuǎn)換；

⑧主機(jī)收到dstIp=HostIp、srcIp=VIPIp的Request Packet。

第一次通信流程結(jié)束后，Openswitch將流表進(jìn)行存儲(chǔ)，之后需要相同路徑的連接直接通過交換機(jī)轉(zhuǎn)發(fā)。

1.3 輪詢調(diào)度算法

在SDN環(huán)境中，虛擬服務(wù)器都有相同的配置，輪詢調(diào)度算法可以節(jié)約負(fù)載策略耗費(fèi)的時(shí)間。在Floodlight控制器中，負(fù)載均衡策略采用輪詢調(diào)度算法能夠?yàn)槠渌K提供計(jì)算空間。輪詢調(diào)度算法將每一次來(lái)自網(wǎng)絡(luò)的請(qǐng)求都可以輪流分配給內(nèi)部中的服務(wù)器，從1到N，然后重新循環(huán)。它每次調(diào)度執(zhí)行i=(i+1)mod n，并選出第i臺(tái)服務(wù)器。

輪詢調(diào)度算法的相關(guān)代碼如下：

public String pickMember(IPClient client){

if (members.size()＞0){

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

return members.get(previousMemberIndex);

}

else{

return null;}

2 實(shí)驗(yàn)及分析

本方案的實(shí)驗(yàn)操作系統(tǒng)采用的是Ubuntu。SDN數(shù)據(jù)平面由虛擬機(jī)中的Mininet搭建，運(yùn)行在主機(jī)中的Floodlight作為控制器與負(fù)載均衡器。Floodlight支持網(wǎng)絡(luò)可視化，通過訪問其端口頁(yè)面可以發(fā)現(xiàn)網(wǎng)絡(luò)拓?fù)洹⒕W(wǎng)絡(luò)連接、交換機(jī)流表、交換機(jī)以及主機(jī)信息。

2.1 配置Loadbalancer

在Ubuntu的主機(jī)終端，通過API開啟Floodlight的負(fù)載均衡服務(wù)。此次試驗(yàn)分別創(chuàng)建了2個(gè)VIP實(shí)現(xiàn)ICMP與TCP負(fù)載均衡服務(wù).圖3、圖4分別是參數(shù)配置和返回的數(shù)據(jù)。

圖3 ICMP負(fù)載均衡參數(shù)配置

圖4 TCP負(fù)載均衡參數(shù)配置

2.2 創(chuàng)建實(shí)驗(yàn)拓?fù)鋱D

圖5 是本次試驗(yàn)的拓?fù)浣Y(jié)構(gòu)圖。由于本文的負(fù)載均衡方案是面向連接的，UDP協(xié)議數(shù)據(jù)傳輸完后不需要斷開連接。流表轉(zhuǎn)發(fā)方式與ICMP類似，所以本文中不再進(jìn)行UDP協(xié)議的測(cè)試。試驗(yàn)中，首先通過在Mininet中分別使用h1～h5、he1～he6發(fā)起4次對(duì)VIP1的請(qǐng)求，模擬ICMP請(qǐng)求的網(wǎng)絡(luò)訪問情況；其次發(fā)起Wget訪問VIP2，模擬TCP協(xié)議負(fù)載均衡情況；最后為了驗(yàn)證本文是面向連接的，使用同一臺(tái)主機(jī)多次對(duì)VIP2進(jìn)行Wget訪問。

2.3 實(shí)驗(yàn)結(jié)果分析

由 Wireshark在 Open-Switch3的 eth1、eth2、eth3抓包分析可以得出，10臺(tái)主機(jī)中，4臺(tái)與server11連接，3臺(tái)與server12連接，3臺(tái)與server13連接，并以輪詢選擇的方式進(jìn)行ICMP通信。圖6是Wireshark在ICMP負(fù)載均衡時(shí)各服務(wù)器的流量情況。

圖5 實(shí)驗(yàn)拓?fù)?/p>

圖6 ICMP負(fù)載均衡流量統(tǒng)計(jì)圖

整個(gè)用戶網(wǎng)絡(luò)向ICMP服務(wù)器共發(fā)起了10起訪問，每起4次，并被輪詢分配到不同服務(wù)器下。圖7為通過wireshark在某一主機(jī)端的抓包分析。可見，它的數(shù)據(jù)包的目的地址已經(jīng)被轉(zhuǎn)換為VIP1的地址。

圖7 ICMP負(fù)載均衡主機(jī)端抓包

通過負(fù)載均衡服務(wù)找到路徑并下發(fā)流表后，交換機(jī)會(huì)自動(dòng)記錄流表，下次收到同樣請(qǐng)求包時(shí)會(huì)自動(dòng)按照流表下發(fā)。圖8通過控制器的顯示頁(yè)面查詢Open-Switch3中記錄的流表，從中亦可以分析出本文提出的負(fù)載均衡方案實(shí)現(xiàn)了面向連接的服務(wù)器均衡。為了再次驗(yàn)證，本文繼續(xù)采用TCP協(xié)議進(jìn)行實(shí)驗(yàn)。

圖8 ICMP負(fù)載均衡流表

圖9 是使用10臺(tái)主機(jī)對(duì)VIP2發(fā)起Wget訪問的結(jié)果，圖10則是使用同一臺(tái)主機(jī)對(duì)VIP2發(fā)起10次Wget訪問。理論上，由于TCP協(xié)議是無(wú)狀態(tài)的連接，每次協(xié)議完成后會(huì)自動(dòng)斷開連接。而本文的均衡方案是面向連接，所以兩次訪問的結(jié)果相同。實(shí)驗(yàn)結(jié)果顯示與理論一致，證明本文的負(fù)載均衡方案適合于面向連接的負(fù)載均衡。從圖11的Open-Switch3的流表可以得出，同一主機(jī)多次訪問VIP2時(shí)，數(shù)據(jù)包輪換通過不同端口，證實(shí)了訪問過程由不同的服務(wù)器輪換進(jìn)行響應(yīng)。

圖9 TCP負(fù)載均衡多主機(jī)訪問流量統(tǒng)計(jì)圖

圖10 TCP負(fù)載均衡單主機(jī)訪問流量統(tǒng)計(jì)圖

圖11 TCP負(fù)載均衡單主機(jī)多次訪問流表

與ICMP協(xié)議均衡不同的是，針對(duì)TCP協(xié)議，此方案保存在交換機(jī)內(nèi)的流表是不可用的。TCP協(xié)議著重于其可靠性，數(shù)據(jù)傳輸結(jié)束后會(huì)關(guān)閉連接，因此待到下一次連接時(shí)，交換機(jī)收到的包數(shù)據(jù)與存在流表記錄中的數(shù)據(jù)不同。此時(shí)，交換需要再次向Floodlight提取解析目的地址的請(qǐng)求，由Loadbalancer重新決策選擇目的服務(wù)器，并決定其傳輸路徑。

3 結(jié) 語(yǔ)

相比于傳統(tǒng)網(wǎng)絡(luò)，SDN能夠更好地統(tǒng)籌網(wǎng)絡(luò)，并控制網(wǎng)絡(luò)中的流量轉(zhuǎn)發(fā)。本文利用SDN的全局網(wǎng)絡(luò)視圖，提出了一個(gè)擴(kuò)展性極高、靈活性強(qiáng)的基于Floodlight控制器的負(fù)載均衡方案。運(yùn)用Floodlight的Rest API設(shè)置負(fù)載均衡參數(shù)進(jìn)行實(shí)驗(yàn)，并通過Wireshak抓包驗(yàn)證了其在服務(wù)器間的均衡結(jié)果良好，能夠解決網(wǎng)絡(luò)的擁塞問題，提高網(wǎng)絡(luò)的服務(wù)技能。SDN控制器的可移植性高，網(wǎng)絡(luò)業(yè)務(wù)發(fā)展前景巨大。網(wǎng)絡(luò)控制權(quán)的集中不僅使負(fù)載均衡服務(wù)成本降低、易實(shí)現(xiàn)，且網(wǎng)絡(luò)中其他節(jié)點(diǎn)不必再進(jìn)行負(fù)載計(jì)算，消耗減小。

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

（1）Monitor會(huì)一直認(rèn)為Pool中的所有負(fù)載均衡成員都處于活躍狀態(tài)，即都能夠處理網(wǎng)絡(luò)請(qǐng)求，所有的成員會(huì)一直出現(xiàn)在VIP的分發(fā)列表中，即使成員對(duì)應(yīng)的主機(jī)不能響應(yīng)網(wǎng)絡(luò)請(qǐng)求，這在實(shí)際應(yīng)用中會(huì)造成負(fù)載均衡的響應(yīng)異常；

（2）目前只能實(shí)現(xiàn)ARP、TCP、UDP和ICMP包的負(fù)載均衡；

（3）未對(duì)路徑選擇加以更加優(yōu)秀的算法，直接選擇了路由跳數(shù)最小的最短路徑。

如何尋找到更優(yōu)秀的負(fù)載均衡算法，是解決本文不足的關(guān)鍵。目前，不少研究者基于SDN負(fù)載均衡算法進(jìn)行了研究。文獻(xiàn)[9]提出一種可以優(yōu)化負(fù)載均衡問題的粒子群化算法，以鏈路的帶寬使用率最接近為負(fù)載均衡決策下發(fā)到Openflow交換機(jī)的準(zhǔn)則；文獻(xiàn)[10]基于馬爾科夫鏈算法選出最優(yōu)負(fù)載均衡的路徑；文獻(xiàn)[11]則提取傳輸路徑的特性，訓(xùn)練BP神經(jīng)網(wǎng)絡(luò)預(yù)測(cè)綜合負(fù)載并選擇最小負(fù)載的路徑。比較眾多的負(fù)載均衡算法，適當(dāng)擴(kuò)展到本文提出的負(fù)載均衡方案中，需要做更進(jìn)一步的研究。

參考文獻(xiàn)：

[1] 范偉.軟件定義網(wǎng)絡(luò)及應(yīng)用[J].通信技術(shù),2013(03)：67-70.FAN Wei.Software-defined Networking and Application[J].Communications Technology,2013(03)：67-70.

[2] 程克非,高江明,段潔等.面向SDN的數(shù)據(jù)中心網(wǎng)絡(luò)更新研究綜述[J].電訊技術(shù),2017,57(10)：1224-1232.CHENG Ke-fei,GAO Jiang-ming,DUAN Jie,et al.Survey of Research on Data Center Network Update Based on SDN[J].Teleconmmunication Engineeri ng,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] 張衛(wèi)峰.走近Google基于SDN的B4網(wǎng)絡(luò)[J].程序員 ,2013(11)：100-104.ZHANG Wei-feng.Approaching Google's SDN-based B4 Network[J].Programmers,2013(11)：100-104.

[6] 房秉毅,張歌,張?jiān)朴碌?開源SDN控制器發(fā)展現(xiàn)狀研究[J].郵電設(shè)計(jì)技術(shù),2014(07)：29-36.FANG Bing-yi,ZHANG Ge,ZHANG Yun-yong,et al.Research on the Development of Open Source SDN Controller[J].DTPT,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] 曹欲曉,徐金寶.基于粒子群優(yōu)化的SDN負(fù)載均衡研究[J].現(xiàn)代計(jì)算機(jī),2016(29)：18-21.CAO Yu-xiao,XU Jin-bao.Research on SDN Load Balance Based on Particle Swarm Optimization[J].Mordern Computer,2016(29)：18-21.

[10] 王春枝,羅晨,陳宏偉.SDN中基于負(fù)載均衡的最優(yōu)路徑分配算法研究[J].計(jì)算機(jī)應(yīng)用研究 ,2016,33(08)：2462-2466.WANG Chun-zhi,LUO Chen,CHEN Hong-wei.Optimal Path Allocation Algorithm Based on Load Balancing for SDN[J].Application Research of Computer,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.