摘要：目前傳統網路的負載均衡存在硬體設備高成本或軟體架構高消耗的缺點。 因此， 提出基於軟體定義網路（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擁有獨立的控制器來自主管理網路，
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期（轉載請注明出處，否則禁止轉載）
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期（轉載請注明出處，否則禁止轉載）