网络已经成为许多商业的支撑脊柱,世界网络中每天都有新的设备加入,致使网络规模巨大化。众多的网络设备不仅意味着需要投入更多的资源,且使网络结构越加复杂化,管理难度增大且易错。为了避免网络管理错误的发生,一种新型的网络架构出现,即软件定义网络(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]仿真,每个节点默认的配置相同,