一种基于集群的SDN控制器负载均衡方案

黄小曼　沈苏彬

(南京邮电大学计算机学院　江苏 南京 210003)



一种基于集群的SDN控制器负载均衡方案

黄小曼沈苏彬

(南京邮电大学计算机学院江苏 南京 210003)

摘要SDN(Software Defined Networking)集中式管控在带来网络全局视角、可编程以及灵活性的同时，其可靠性和可缩放性一直是其弱点。工业界和学术界普遍指出分布式控制器是解决这个问题的一种可行方案。然而，交换机和控制器之间的静态映射关系会限制分布式控制器系统的性能。针对这个问题，基于OpenFlow协议，提出一种在运行时动态修改交换机与控制器之间配置关系的交换机迁移方案。实验证明，该方案可以实现分布式控制器之间的负载均衡，提高了控制平面的可缩放性。

关键词SDN可缩放性OpenFlow负载均衡

0引言

软件定义联网SDN[1]是一种软件可编程的新型网络体系结构，其核心思想是将数据平面与控制平面分离，控制平面利用控制—转发接口对数据平面上的网络设备进行集中控制，SDN网络中的集中式管控由软件控制器实现。

大规模数据中心具有成百上千台交换机，仅使用一台集中式控制器很难满足要求，且集中控制器会带来可缩放性和可靠性的问题。实现一个逻辑集中、物理分布式的控制器体系结构成为解决SDN控制平面可缩放性的良好解决方案，这样既可以获得分布式系统带来的较高可缩放性和可靠性，又可以保留集中控制系统的简单特性。近年来，关于分布式SDN控制结构已经有了一系列研究成果[2,3]，大多分布式控制器系统的研究焦点是建立实现分布式功能的模块。然而，限制分布式控制器系统性能的一个关键因素是交换机与控制器之间的静态配置关系，这一静态配置关系会造成控制平面的负载不均衡。现实网络(例如数据中心网络、企业网)中流量在时间和空间上都是不停变化的。所以，当交换机突发大量流请求时，与之相连的控制器负载将快速上升，可能会造成控制器性能降低甚至瘫痪，经过一段时间，可能会造成整个控制平面性能的降低[4]。因此，交换机和控制器间的静态配置关系会降低系统性能。解决方法之一是为控制器配置多冗余容量，以应对大量突发流。但这种方法会增加开销，同时浪费资源。

针对这个问题，本文提出了交换机迁移方案，实现在运行过程中动态修改交换机与控制器之间的配置状态。然而将交换机从一台控制器中迁往另外一台控制器时会破坏控制器正在进行的消息处理过程，现有OpenFlow[5]协议标准并没有提供一个合适的解决方案，本文提出的迁移机制是在充分利用OpenFlow定义的三种控制器角色基础上，保护控制器的流处理过程，实现分布式控制器之间的流请求负载均衡，提高了系统的吞吐量和可缩放性。

1相关技术分析

1.1分布式控制器

控制器结构发展经历了单线程控制器[6]到多线程控制器[7]这样的过程。但单一的物理控制器系统带来了低可缩放性和易受损的缺点。近年来，随着网络需求的提高，分布式控制器受到广泛关注。分布式控制器研究的核心研究问题是关于如何解决分布式控制器实例之间的状态一致性。例如，Onix[2]通过维护网络信息库NIB(NetworkInformationBase)的分发机制，保证整个网络状态信息库的一致性。HyperFlow[3]复制所有分布式节点中发生的事件，所以每个节点可以处理这些事件并更新本地状态。现有的分布式控制器方案大多建立在传统分布式系统基础之上，旨在建立分布式节点状态信息共享、状态更新等分布式功能模块。SDN作为新兴网络技术，将分布式系统引入到SDN控制器中时，需要对控制—转发接口协议进行分析，提供在分布式环境下的灵活部署特性。

1.2OpenFlow协议

OpenFlow协议从2009年首次提出后，目前已经发展到v1.4，ONF组织将v1.3作为一个稳定的版本，本节以OpenFlowv1.3进行讨论。下面简要介绍本文使用的OpenFlow消息类型：

(1)Role-request/Role-reply消息：Role-Request消息由控制器发起，用于交换机与多控制器连接的场景中，当交换机收到该消息时，根据请求的控制器角色类型作出相应回复，向控制器发送Role-Reply消息，告知控制器是否允许修改角色。

(2)Flow-mod/Flow-removed消息：Flow-mod消息由控制器发起，用来增加、删除和修改交换机中的流表项，通过对Flow-mod消息格式中command字段指定操作来完成，该字段可以指定为增加、删除和修改等。当交换机收到控制器的Flow-mod删除消息时，根据消息中指定的流表项信息，找到流表中的相应流表项删除，并返回Flow-removed消息表示确认删除，Flow-Removed消息也用于因流表项超时，而引起的流表项删除情况。当交换机连接到多台控制器时，Flow-Removed会发送给与交换机相连的master控制器和equal控制器.

(3)Barrier-request/Barrier-reply消息：Barrier-request消息用于确保之前下发的消息已经被交换机处理完毕，当控制器发送该消息到交换机时，交换机会立即处理之前收到的所有消息，并回复Barrier-reply消息。如果要确保控制器先后发送到交换机的两条消息得到按序处理，可以在两个消息中间增加Barrier-request消息。

OpenFlow协议提出了交换机与多台控制器相连的概念，多连接可以有效地预防控制器单点故障问题，OpenFlow协议将控制器角色分为三种：Master、Equal和Slave。

控制器的默认角色是Equal，Equal控制器对于交换机具有全部处理能力，能够接受所有交换机发来的异步消息(例如Packet-in、Flow-removed消息等)，Equal控制器也可以发送控制器-交换机消息以修改交换机的状态；Slave控制器对交换机只有读权限，默认情况下Slave控制器不接受任何交换机异步消息，但交换机可以处理Slave控制器的角色请求消息；Master控制器与Equal控制器对交换机所具有的权限相似，区别在于交换机可以与多台Equal控制器相连，而仅可以与一台Master控制器相连。当某台控制器发送Role-request消息到交换机，请求将当前角色修改为Master，交换机会将与之相连的Master控制器角色改为Slave。交换机维护与多控制器的连接，控制器可以在任意时刻修改它的角色。

本文旨在分布式控制器环境下，基于OpenFlow协议定义的三种控制器角色，将Equal角色作为过渡角色，逐步实现交换机在多控制器之间的无缝迁移，以实现在集群环境下的控制器负载均衡功能。

2设计目标

本文将服务器集群技术应用到SDN分布式控制器方案中，构建SDN控制器集群环境。本节首先介绍控制器集群需要完成的功能，其次分析交换机迁移方案所需解决的几类关键问题。

2.1控制器集群

控制器集群采用分布式数据存储方式维持一个逻辑集中的控制平面.它存储所有交换机信息,集群中各个节点共享这些信息。集群服务主要提供以下服务：集群系统在启动时，集群服务提供从文件读取集群配置的服务；运行过程中，集群服务提供集群节点名称到节点所在主机名称/IP地址的解析服务。

一个控制器集群的例子，如图1所示，该集群包括两个控制器节点，分别为A和B；A连接交换机X，交换机X又与多个交换机相连，x1、x2、…、xn。B连接交换机Y，Y与一系列交换机相连。根据OpenFlow协议的定义，交换机可以与多台控制器相连，图1中，实线A1和B1代表与交换机相连的控制器是Master控制器，虚线代表与交换机相连的控制器是Slave控制器，在该集群结构下，A与B之间通过TCP协议互联，共享网络状态信息，且每个控制器节点都维护全局网络状态拓扑，包含全局网络状态信息。

图1　两个节点的控制器集群

控制器集群的可缩放性体现在整个集群平面对数据平面流请求的处理性能，包括计算时间和流规则安装延迟。文献[8]中实验证明，控制器对流请求的计算时间可以忽略不计，流规则安装延迟则受控制器资源使用情况限制，主要包括CPU使用率和内存使用率，控制器集群需要监测集群中每个控制器节点的资源使用情况，当集群中某点控制器节点资源使用率较高时，负责从集群中选举出具有较小资源使用率的控制节点。

2.2交换机迁移

交换机与控制器之间的静态配置关系是限制分布式控制器系统性能的一个主要因素，它使得分布式控制器结构无法适用于在空间上和时间上多变的流情况。例如，不同时间测量数据中心网络的流量，其最大值和最小值之间相差很大[9]，或者数据中心网络中可能大部分流量只由少量几台交换机产生，而大部分交换机产生较少流量。当一台控制器资源使用率较高时，分布式控制器系统的整体响应时间会增加，从而影响上层应用。本文通过在控制器之间动态迁移交换机的方法，来提高整个控制平面的可缩放性，即在数据层是通过迁移交换机来实现控制平面负载均衡，交换机在迁移过程中，需要满足下面两个条件：

(1)交换机在迁移的过程中，要保证与该迁移交换机至少有一台相连控制器处于正常运行状态，而不能直接通过将目的控制器的角色改成Master来完成交换机的迁移工作。例如控制器在迁移开始之前，发送了一条Flow-mod删除消息到交换机中，在交换机迁移之前还没有回复Flow-removed消息到控制器中，那么迁移之后会造成信息的丢失和状态的不一致性。

(2) 交换机在迁移的过程中，要保证安全性。即只能有一台控制器处理交换机的异步消息。例如多台控制器对同一交换机的Packet-in消息进行处理，会造成流表项的多次安装，还会造成分布式数据存储的不一致性。

3系统实现

3.1集群配置

集群配置主要描述集群内部状态信息，包括集群中包含的成员信息、每个控制器节点所维护的数据分片信息以及数据分片上所存放的数据信息。

modules= [

{

name= “Topology”

//网络拓扑模块

shards= [

{

name= “shard-1”

replicas= [

“member-2”

//备份存放在成员2中

“member-1”

]

}

}

3.2资源使用情况监测实现

考虑到本分布式系统是运行在一个局域网中，各个控制器节点的IP地址各不相同。使用IP地址作为区分不同节点负载情况的标识。每个控制器节点维护一张日志表格，用于存放集群中各个节点的负载信息，其中包括IP地址、CPU使用率和内存使用率。控制器节点之间传递负载情况的消息格式如表1所示：

表1　资源使用情况格式

本集群中各个节点运行在Ubuntu系统上，每个控制器节点监测本机负载信息，并每隔30秒向其他所有节点发送负载信息。下面为监测CPU和内存使用率的描述：

Userid=”ip”

//IP地址作为控制机器节点标识

if(userid==＄1){cpuUsage+=＄3

//监测CPU使用率

memUsage+=＄4

//检测内存使用率

}

3.3交换机动态迁移

交换机迁移机制是通过运行中动态修改控制器角色完成，图2(a)代表迁移前的拓扑图，S1、S2、S3和S4共同组成一个网络，每个交换机与一个或者两个控制器相连；图中虚线代表交换机连接的是Slave控制器，实线代表交换机连接的是Master控制器。图2(b)中由于控制器A上负载过大，决定将交换机S3迁移到控制器B中，图2(b)为交换机迁移后拓扑图。

本文应用的迁移方案在开始阶段由交换机插入一条冗余消息，由后续阶段对其响应，逐步完成交换机的迁移。下面将迁移过程分为4个阶段，具体描述如下：

阶段1：控制器B请求修改角色为Equal；由控制器A通过集群通信信道告知控制器B交换机开始迁移，此时交换机尚未开始处理事务，交换机在迁移之前加入一条空的流表项，这样操作主要是为了减少下一阶段的冗余时间。当控制器B接收到来自控制器A的开始迁移消息，控制器B发送一个Role-request消息到交换机S3中，请求将控制器B的角色变成过渡角色-Equal。在交换机接收到来自控制器B的角色改变请求信息，交换机将控制器B的角色改变成Equal，且回复控制器B角色已经改变。

阶段2：删除空流表项；此时还无法完全将交换机S3的事务转移到控制器B中，因为控制器A仍然是交换机S3的Master控制器，而控制器B是交换机S3的Equal控制器。为了将交换机业务平滑无缝地转移到控制器B中，需利用迁移开始前插入的空流表项来实现。现阶段控制器A发送Flow-mod删除消息来删除该流表项，在交换机S3收到该消息后，因为此时控制器A仍然工作在Master角色下，而控制器B工作在Equal角色下，所以交换机S3会向两台控制器都发送Flow-removed消息，以确认空流表项删除。控制器B开始介入交换机S3的事务处理。

阶段3：确认事物结束；控制器A此时无法立即与交换机S3断开连接，网络中可能还有正在处理的事务，所以控制器A发送一个Barrier-request消息到交换机中，直到交换机S3回复Barrier-reply消息。此时，控制器A与交换机S3之间的事务处理正式结束。

阶段4：控制器B请求修改角色为Master；至此需要将控制器B改为Equal控制器，在上阶段结束后，控制器A发送事务提交完成消息到控制器B中，在接收到该消息后，控制器B立即向交换机S3发送Role-request消息，请求变化为Master控制器，而交换机S3在收到角色改变请求后，经过交换机内部处理，返回Role-reply消息到控制器B中，交换机会自动将控制器A的角色修改为Slave。至此，正式完成交换机S3的迁移过程，控制器B开始处理交换机S3的请求。

图3为交换机无缝迁移过程中具体的消息传递过程。

图3　消息传递过程

4系统测试

4.1实验环境

本文通过测试两台控制器组成的集群系统来分析SDN控制器系统的可缩放性，利用两台OpenDaylight[10]控制器组成控制器集群，以构成控制平面；下层的数据平面采用Mininet[11]来部署网络设备环境。其中，控制平面上部署的两台控制器，控制器A和控制器B，两台控制器部署的主机IP地址分别是10.10.136.121和10.10.136.122；数据平面上利用Mininet部署八台交换机，运行Mininet的主机IP地址是10.10.136.123，三台主机均运行Ubuntu12.04系统。

图4　实验网络拓扑

初始网络如图4所示，其中S1～S7的Master控制器是控制器A，控制器B作为Slave与S1～S7相连；S8的Master控制器是控制器B，控制器A作为Slave与S8相连，图4中，实线代表与交换机相连的是Master控制器，虚线代表与交换机相连的是Slave控制器。

4.2测试方法和结果分析

文献[12]指出SDN控制平面实际是一个分布式系统，可以通过测量分布式系统的响应时间来评估分布式系统的可缩放性。本文通过向控制器集群轮询发送流请求消息，测试其响应时间来反映其可缩放性。每台交换机每次发送2000条流请求消息(Packet-in消息)，一共发送4次，分别测量每个控制器的资源使用情况以及响应时间。首次测量为控制器A处理S1～S7的流请求，控制器B处理S8的流请求；第二次测量时，将S7迁移到控制器B的控制域内，即将控制器B变为S7的Master控制器；按照这样的顺序，直到控制器A负责处理S1～S4的流请求，控制器B负责处理S5～S8的流请求。由于Slave控制器接收到Packet-in消息时，不处理并将其丢失，故对控制器的性能影响可以忽略不计。

(a) CPU使用率对比图

(b) 内存使用率对比图

(c) 响应时间对比图图5　对比情况

经过以上4次测量，得出4次监测控制器CPU使用率对比情况如图5(a)所示，内存使用率对比如图5(b)所示，两台控制器的响应时间对比如图5(c)所示。

实验证明，运行过程中迁移交换机可以降低控制平面的总体响应时间，提高控制平面的可缩放性，实现控制平面负载均衡。当应对数据平面的大量数据流请求时，控制平面仍能保持稳定的处理能力。

5结语

本文的研究内容是针对多控制器系统中负载不平衡引起的控制器效率下降的问题，提出了将集群技术应用到多控制系统中，且在集群中实现交换机在运行时动态转移，这可以有效地提高控制器的处理性能以及网络的吞吐量，使各个控制器节点负载得到均衡。本文未来的研究计划是将容错功能加入到控制器集群环境中。

参考文献

[1]SDN[EB/OL].[2015-01-27].https://www.opennetworking.org/sdn-resources/sdn-library/whitepapers.2015.

[2]KoponenT,CasadoM,GudeN,etal.Onix:ADistributedControlPlatformforLarge-scaleProductionNetworks[C]//The9thUSENIXconferenceonOperatingSystemsDesignandImplementation(OSDI).2010.Vancouver,Canada,2010:351-364.

[3]TootoonchianA,GanjaliY.HyperFlow:AdistributedcontrolplaneforOpenFlow[C]//Proceedingsofthe2010internetnetworkmanagementconferenceonResearchonenterprisenetworking.USENIXAssociation,2010:3-3.

[4]YaoG,BiJ,GuoL.Onthecascadingfailuresofmulti-controllersinSoftwareDefinedNetworks[C]//NetworkProtocols(ICNP),2013 21stIEEEInternationalConferenceon.IEEE,2013:1- 2.

[5]OpenNetworkingFoundation(ONF).SDNArchitectureOverview[EB/OL].[2015-02-10].http://www.opennetworking.org.2015.

[6]GudeN,KoponenT,PettitJ,etal.NOX:towardsanoperatingsystemfornetworks[J].ACMSIGCOMMComputerCommunicationReview,2008,38(3):105-110.

[7]Floodlight[EB/OL].[2015-02-10 ].http://www.projectfloodlight.org/.2015.

[8]KrishnamurthyA,ChandraboseSP,Gember-JacobsonA.Pratyaastha:anefficientelasticdistributedSDNcontrolplane[C]//ProceedingsofthethirdworkshoponHottopicsinsoftwaredefinednetworking.ACM,2014:133-138.

[9]BensonT,AkellaA,MaltzDA.Networktrafficcharacteristicsofdatacentersinthewild[C]//Proceedingsofthe10thACMSIGCOMMconferenceonInternetmeasurement.ACM,2010:267-280.

[10]OpenDaylight[EB/OL].[2015-01-28].http://www.opendaylight.org.2015.

[11]LantzB,HellerB,McKeownN.Anetworkinalaptop:rapidprototypingforsoftware-definednetworks[C]//Proceedingsofthe9thACMSIGCOMMWorkshoponHotTopicsinNetworks.ACM,2010:19.

[12]HuJ,LinC,LiX,etal.ScalabilityofcontrolplanesforSoftwaredefinednetworks:Modelingandevaluation[C]//QualityofService(IWQoS),2014IEEE22ndInternationalSymposiumof.IEEE,2014:147-152.

A LOAD BALANCING SCHEME OF SDN CONTROLLERS BASED ON CLUSTERING

Huang XiaomanShen Subin

(School of Computer,Nanjing University of Posts and Telecommunications,Nanjing 210003,Jiangsu,China)

AbstractThe centralised SDN control brings the global network perspective,programmability and flexibility,but it also brings the weakness of reliability and scalability as well.The solution based on distributed controllers is a feasible method as widely noted by the industry and academia.However,the static mapping relationship between a switch and a controller limits the performance of distributed controllers.To solve this problem,this paper proposes based on OpenFlow protocol a switch migration scheme which can dynamically modify the configuration relationship between switch and controller on operation.It is proved by the experiment that the scheme can achieve the load balance between controllers and improve the scalability of the control plane.

KeywordsSDNScalabilityOpenFlowLoad balancing

收稿日期：2015-02-06。江苏省未来网络前瞻性研究项目(BY2013095-1-08)。黄小曼，硕士生，主研领域：计算机网络。沈苏彬，研究员。

中图分类号TP393

文献标识码A

DOI:10.3969/j.issn.1000-386x.2016.06.032