0引言网络已经成为很多业务的支柱，每天都有新的设备加入到世界网络中，导致网络规模庞大。大量的网络设备不仅意味着需要投入更多的资源，同时也使得网络结构更加复杂，管理难度加大，容易出错。为了避免网络管理错误，出现了一种新型的网络架构，即软件定义网络（SDN）[1]。SDN技术旨在实现控制平面和数据平面的分离，控制平面是一系列物理上集中的控制器。这些控制器通过开发一系列能够检测和管理网络行为的应用程序来实现网络可编程性。SDN可以实现各种传统物理网络的功能，如负载均衡。软件定义网络中的控制器通过改变数据平面交换机的流表项来调整受影响的流在冗余路径上传输，从而避免过度占用网络资源[2]。在云场景下，LBaaS（LoadBalancingasaService）是Openstack[3]云计算平台研究的一种负载均衡方案。但是其承载的Openstack项目——网络和地址管理（Neutron）只能实现指定的目标网络访问。在大规模云应用场景中，LBaaS无法支持负载均衡服务。因此，Openstack将SDN作为Neutron模块的插件来开发网络服务，以解决LBaaS的局限性，例如NFV（NetworkFunctionVirtualization，网络功能虚拟化）。Window的云级负载均衡方案（Ananta）[4]在基于云的操作系统Azure中也借鉴了SDN控制面和数据面分离架构，实现了云级可扩展的基于软件的四层地址转换负载均衡服务。它的控制部分无法检测网络中大小负载的流量，数据部分的规模设计得很大，成本也相应增加。与前两者相比，SDN有一个独立的控制器来独立管理网络，并且可以支持编程来完成指定的服务；与Anata不同，SDN以不同的软件运行控制平面和数据平面，并通过网络接口将它们连接起来。这些程序不会相互干扰。目前SDN环境下的负载均衡主要基于算法研究，对解决方案部署的研究较少。在以SDN架构为主的GoogleB4[5]网络中，没有合适的负载均衡方案。SDN的开源控制器有NOX、Opendaylight、RYU和Floodlight等[6]。Floodlight集成了SDN的控制层和部分应用层，内部南向接口通过RestfulAPI实现。与NOX、POX和Maestro等几种SDN控制器相比，Floodlight具有更好的性能，支持各种应用模块，同时处理Openflow消息[7]。本文提出的负载均衡方案作为一个应用模块运行在Floodlight控制器程序框架中，可以同时扩展服务器负载均衡算法和路径选择的负载均衡方案。实验环境基于Mininet[8]模拟，各节点默认配置相同，服务器组均衡策略采用roundrobin算法，路径选择最短路径。向模块添加多个网络检测参数使该解决方案具有高度可扩展性。1 LoadBalancerSolution1.1 LaodbalancerLogicArchitecture本文将负载均衡器解决方案部署为一个打包的应用模块（Loadbalancer），并将其集成到Floodlight程序框架中。根据本次的测试环境，负载均衡方案的架构如图1所示，Floodlight使用RestfulAPI实现南向接口连接controller模块和应用模块，网络远程连接实现其北向接口到Mininet软件模拟的网络，检测网络数据，并将流表发送到各个Openflow交换机。Loaderbalancer作为一个集成应用，参与流表的制定。交换机根据流表传输数据，实现了负载均衡服务。1.2 Loadbalancer服务流程负载均衡服务流程包括解析Packet_In消息、负载均衡决策、路径选择、流表下发。图2展示了整个负载均衡服务的通信流程。①主机发送请求包（RequestPacket），其中dstIp=VIIPp；②交换机检测到自己的流表中没有与Request报文匹配的流表，即发送Packet_In报文请求controller做决定，其中dstIp=VIPIP；③首先，Floodlight控制器检测到Packet_In消息中的VIP地址及其端口后，调用负载均衡算法，通过算法选择Mininet创建的虚拟服务器。选择目标服务器后，计算主机到目标服务器的路径（选择跳数最少的路径），将其传入路由以流表的形式发送给Openswitch（pushInVipRoutes）。其次进行地址转换，将RequestPacket的目的IP地址和Mac地址由dstIp=VIIPp,dstMac=VIPMac转换为负载均衡策略选择的服务器的IP地址和MAC地址dstIp=SeverIp,dstMac=服务器Mac。***，发送Packet_out给Openswitch，根据下发的流表通知数据包工作；④Sever收到dstIp=SeverIp，srcIp=HostIp的Request包；⑤Sever回复host发送的Reply包，dstIp=HostIp，srcIp=SeverIp；⑥同步骤②，向controller发送Packet_out，其中srcIp=SeverIp；⑦同步骤③，先找到服务器到主机的路径，然后进行地址转换；⑧主机收到dstIp=HostIp,srcIp=VIIPp的Request包。在第一次通信过程结束后，Openswitch存储流表，然后需要相同路径的连接直接通过交换机转发。1.3 RoundRobin调度算法在SDN环境下，虚拟服务器配置相同，RoundRobin调度算法可以节省负载策略的时间。在Floodlight控制器中，负载均衡策略采用round-robin调度算法，为其他模块提供计算空间。round-robin调度算法将来自网络的每一个请求依次分配给内部服务器，从1到，然后循环使用。它每次都安排执行并选择服务器。轮询调度算法相关代码如下：publicStringpickMember(IPClientclient){if(members.size()>0){previousMemberIndex=(previousMemberIndex+1)%members.size();returnmembers.get(previousMemberIndex);}else{returnnull;}2 实验与分析本程序实验操作系统为Ubuntu。SDN数据平面由Mininet在虚拟机中构建，运行在主机中的Floodlight充当控制器和负载均衡器。Floodlight支持网络可视化。通过访问其端口页面，您可以发现网络拓扑、网络连接、交换流表、交换机和主机信息。2.1 在Ubuntu主机端配置Loadbalancer，通过API开启Floodlight的负载均衡服务。在这个实验中，创建了两个VIP来实现ICMP和TCP负载均衡服务。图3和图4分别是参数配置和返回数据。2.2 制作实验拓扑图图5是本实验的拓扑图。由于本文的负载均衡方案是面向连接的，因此UDP协议数据传输完毕后无需断开连接。流表转发方式与ICMP类似，因此本文不再进行UDP协议测试。实验中首先使用Mininet中的h1~h5、he1~he6分别向VIP1发起4次请求，模拟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台主机发起Wget访问VIP2的结果，图10是使用同一台主机发起10次Wget访问VIP2的结果。理论上，由于TCP协议是无状态连接，每次协议完成后连接都会自动断开。本文中的平衡方案是面向连接的，所以两次访问的结果是一样的。实验结果与理论一致，证明了本文的负载均衡方案适用于面向连接的负载均衡。从图11中Open-Switch3的流表可以看出，当同一台主机多次访问VIP2时，数据包交替通过不同的端口，这证实了访问过程中不同的服务器依次响应。与ICMP协议平衡不同，对于TCP协议，本方案不提供交换机中存储的流表。TCP协议侧重于其可靠性。数据传输结束后，连接将关闭。因此，在进行下一次连接时，交换机接收到的数据包数据与流表记录中存储的数据不同。这时，交换机需要再次从Floodlight中提取解析目的地址的请求，Loadbalancer会重新做出选择目的服务器的决定，并确定其传输路径。3 结论 备注与传统网络相比，SDN可以更好地协调网络，控制网络中的流量转发。本文利用SDN的全局网络视图，提出了一种基于Floodlight控制器的高度可扩展、灵活的负载均衡方案。使用Floodlight的RestAPI设置负载均衡参数进行实验，通过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]JacksonK,BunchC,SiglerE.OpenStackCloudComputingCookbook[M].PacktPublishing,2015:121-165.[4]PatelP、BansalD、YuanL等人。Ananta：云级负载均衡[J]．计算机通信评论,2013,43(04):207-218.[5]张伟峰．走近谷歌基于SDN的B4网络[J].程序员,2013(11):100-104.[6]方秉义，张戈，张云勇等．开源SDN控制器发展现状研究[J]．邮电设计技术，2014(07)：29-36.[7]EricksonD.TheBeaconOpenflowController[C].ACMSIGCOMMWorkshoponHotTopicsinSoftwareDefinedNetworkingACM,2013:13-18.[8]KaurK,SinghJ,GhummanNS.MininetasSoftwareDefinedNetworkingTestingPlatform[C].InternationalConferenceonCommunication,Computing&Systems,2014.[9]曹玉晓,徐金宝.基于粒子群优化的SDN负载均衡研究[J].现代计算机,2016(29):18-21.[10]王春芝，罗晨，陈宏伟．SDN中基于负载均衡的最优路径分配算法研究[J].计算机应用研究,2016,33(08):2462-2466.[11]崔晨晓,许亚斌.SDN负载均衡方法研究[C].国际网格与分布式期刊ributed计算，2016：25-36。
