内容简介：网络已经成为许多商业的支撑脊柱，世界网络中每天都有新的设备加入，致使网络规模巨大化。众多的网络设备不仅意味着需要投入更多的资源，且使网络结构越加复杂化，管理难度增大且易错。为了避免网络管理错误的发生，一种新型的网络架构出现，即软件定义网络（Software Defined Networking，SDN）[1]。SDN技术旨在实现控制层与数据层面的分离，而控制层是物理上集中的一系列控制器。这些控制器通过开发一系列应用能够检测和管理网络行为，实现网络可编程化。SDN可以实现各种传统物理网络的功能，如负载均衡。
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.
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持 码农网
猜你喜欢:
- 终于把服务器负载均衡和客户端负载均衡讲清楚了
- 服务器负载均衡原理及实现
- 如何搭建Nginx服务器做到负载均衡？
- Nginx反向代理服务器、负载均衡和正向代理
- 过载保护+异构服务器的负载均衡，怎么设计？
- 全局服务器负载均衡已开始向云上转移
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
