李 婉，沈苏彬，吴振宇

(1.南京邮电大学 计算机学院，江苏 南京 210003；2.南京邮电大学 物联网学院，江苏 南京 210003)

0 引 言

软件定义联网(Software Defined Networking，SDN)是一种新型的网络架构，实现了控制平面和数据平面的分离，能够更好地管理网络流量，为网络及其应用提供了良好的平台。

随着支持OpenFlow设备的增加，数据平面大量的流量被发送到控制平面，引起网络中SDN控制器的负载增加，SDN控制器受到性能和容量的限制，有可能限制了网络的性能。传统的SDN设备依赖于单个集中化的控制器，控制器是SDN网络的核心，拥有全局网络视图，集中控制整个网络，处理交换机发送过来的大量请求。虽然SDN控制器从单线程发展为多线程，但是单控制器在可扩展性、可靠性、安全性等方面存在固有缺陷[1]，因此，业界提出了逻辑上集中、物理上分布的多SDN控制器部署方案HyperFlow[2]、Kandoo[3]和Onix[4]，多个控制器协同工作，实现对整个网络的集中式控制，有着更好的扩展性。

最早提出的分布式控制平面HyperFlow，实际上由物理上分布、逻辑上集中的多SDN控制器组成，在提供可扩展性的同时保持网络集中控制的优点。HyperFlow根据网络规模设置多个管理域，每个管理域中的控制器独立管理自己区域的交换机，只与邻近的控制器交互，不主动地与远处的控制器进行通信，减少了控制器和交换机之间的流配置时间。Kandoo采用分层思想将控制器分为两层：根控制器和本地控制器。根控制器维护网络的状况，本地控制器主要负责管理交换机。

Onix主要包括物理基础设施层、连接基础设施、Onix和控制逻辑四部分。物理基础设施层由路由器、交换机和其他网络元素组成，主要为Onix提供读写状态的API；连接基础设施为物理基础设施层和Onix提供通信通道；Onix为控制逻辑提供到网络的可编程访问接口；控制逻辑决定网络的行为，其包含一个NIB(Network Information Base，网络信息库)，用于维护全网的状态。由此可知，目前的分布式控制平面研究的重点是SDN控制器在正常工作的情况下，如何实现分布式控制器实例之间一致的状态。多控制器部署方案[2-4]中控制器和交换机之间的关系是静态配置的，但是网络中的流量是动态变化的。如果一段时间内，某一控制器管辖的交换机中流量突增，将导致控制器负载过大，紧接着导致控制器响应时间过长，从而降低了整个网络的性能。而其他控制器有可能处于闲置状态，引起控制器之间负载不均衡，造成了控制器资源的浪费。

为解决SDN控制器负载不均衡问题，文献[5-6]提出的弹性分布式控制器ElastiCon能够根据网络中的负载动态减少或增加控制器。为了实现弹性分布式控制器，提出了交换机迁移协议。但是该方案考虑的情况比较简单，只有一个控制器负载过载，采用就近迁移的策略。虽然可以减少交换机和控制器之间的延迟，但是如果邻近控制器的负载过大，将导致多次迁移交换机，效率并不是很高，甚至需要添加新的控制器。

针对上面多控制器负载失衡的问题，文中提出一种交换机动态迁移机制。该机制基于控制器角色实现交换机的迁移，并且提出一种调度算法，该算法综合考虑了控制器的负载和交换机与控制器之间的传输时延两个因素，选择合适的交换机和目标控制器后，控制器通过改变其角色、与其连接的活跃交换机的个数，完成交换机的迁移。为了评价其性能，验证了控制平面的响应时间和吞吐量，并和传统的静态配置作对比。

1 相关技术分析

和传统网络相比，SDN在灵活性和管理性等方面表现出了很多优点，但随着网络的急剧扩张，控制器的性能、可扩展性和可靠性逐渐成为瓶颈。另外，一旦控制器失效，将导致整个网络面临瘫痪。所以单SDN控制器很难应用于大型网络中。为此，研究人员提出了分布式控制器架构来提高SDN控制平面可扩展性。但是，目前大多数方案中交换机与控制器实例之间静态的映射关系会因为流量的动态变化造成控制器负载不均衡。针对上面的问题，ADVAIT等提出了弹性分布式控制器ElastiCon。ElastiCon提出了一种负载窗口机制，当负载超过上、下阈值时，采取增加新控制器、减少已有控制器或迁移交换机的动作，提高了控制器的资源利用率。但是ElastiCon并没有明确怎样选择増添和删除的控制器数量及位置。另外，文献[5]是将交换机迁移到最近的控制器，减少了控制器和交换机之间的时延，但是没有考虑到邻近控制器的负载，有可能导致邻近控制器又超载，紧接着可能多次迁移交换机。因此，如何精细控制控制器的负载，减少交换机的迁移频率，实现多控制器之间的负载均衡是必须要解决的问题。文献[7]提出了一种弹性方案，在不同的情况下，动态改变控制器的个数和位置。文献[8]介绍了在集群中动态添加或移除控制器但没有产生引起网络中断的算法，同时也提到了给控制器动态分配交换机的必要。文献[9]使用利用率最低的迁移策略，每次都将交换机迁移到剩余容量不经常使用的控制器下，没有考虑到控制器和交换机之间的传输时延；另外，也没有实现总体的负载均衡。

目前的交换机迁移算法大部分都是选择负载较大的控制器下的交换机进行迁移，然后判断迁移后的控制器负载是否过大，如果过载则继续进行迁移。虽然这种迁移方式的单次迁移效率较高，但是对于大规模传输速率较大的网络来说，该迁移方式仍需要花费较大的代价。所以，如何对负载过大的控制器下的交换机进行迁移，提高迁移效率也是一个必须要解决的问题。

文中提出的算法综合考虑了控制器的负载和交换机与控制器之间的传输时延两个因素，然后在控制器和交换机位置确定的情况下，当控制器之间的负载大于事先设置的阈值时，交换机将原来连接的主控制器变为从控制器，将其中的一个从控制器变为一个新的主控制器。发生迁移的交换机必须满足迁移到的新的主控制器的负载没有超过其最大负载和交换机迁移之后控制器之间的负载更均衡两个条件。当两个条件都满足的情况下，选择与控制器之间传输时延最小的交换机进行迁移。

2 方案设计

交换机迁移的过程其实是根据网络中的流量重新部署交换机和控制器之间的关系。OpenFow1.3.4协议[10]提到每个交换机可以连接一个主控制器和多个从控制器。另外，OpenFlow协议还介绍了多种消息，交换机如果收到控制器发送的Role-request消息，会根据请求的控制器角色类型做出回复，并向控制器发送Role-reply消息，告诉控制器是否允许修改角色。主控制器域内的交换机在某时刻如果流请求不断激增的话，需要对该域内交换机实现向外迁移，迁移之前，需要从多个从控制器集合中选择一个从控制器作为该交换机新的主控制器，同时把原来的主控制器变更为从控制器。

本节展示了如何定义和估算控制器负载，并讨论了基于交换机迁移的负载均衡模式。管理框架包含三个功能，说明如下：

(1)负载监测功能：周期性收集和计算控制器的负载，并协调维护全局负载信息表。

(2)负载调度功能：检查每个控制器负载信息表，并决定是否执行交换机迁移，哪个控制器应选为主控制器实施负载转移，哪个交换机执行迁移。

(3)交换机迁移功能：控制器协调交换机迁移和改变交换机与控制器之间的映射。

2.1 负载监测

负载监测主要用于周期性监测控制器的负载，设置阈值，判断控制器的负载状态。文献[11]主要考虑两个负载信息：交换机指标和控制器指标。交换机指标包括与控制器连接的活跃交换机的个数和与控制器相连的所有交换机的Packet-in消息请求速率。控制器指标是控制器收集到的所有负载信息，包括当前的CPU使用率和内存使用率。使用具体的负载值表示控制器真实的负载信息，但是对于不同的网络状况，可能会有不同的负载信息。所以，在实际网络中，为了表示不同的负载信息，可以引入系数，指示了综合负载计算中不同负载信息的权重。由文献[5]可以看出，CPU是控制器的主要限制。因此，控制器的负载主要监测主机的CPU使用率、内存使用率和控制器每秒处理Packet-in的消息个数。

假设网络中有N个控制器{C1,C2,…,Cn}和M个交换机{S1,S2,…,Sm}。根据网络中的状态调节收集和计算负载信息的时间间隔。如果时间间隔较短，虽然可以获得一个准确的负载信息，但是会引起额外的系统开销和通信开销。如果时间间隔较长，则不能准确地描述控制器的负载情况。根据控制器的负载动态调整收集和计算负载信息的时间间隔，不仅可以减少系统开销，还可获得准确的负载信息。

2.2 负载调度

负载调度算法根据负载信息表决定是添加控制器、减少控制器还是执行交换机迁移。迁移交换机过程中哪个控制器应选为主控制器实施负载转移，以及哪个交换机执行迁移。

算法1：整体算法。

While (true) do

if (Ldifi>C) then

Balance(Ci,Sj);

end if

if (Max_Load_Ratio>α) then

Add_controller;

Else if(Max_Load_Ratio<β)then

Sub_cohtntroller;

End if

(1)是否增加/减少控制器。

根据文献[1]可知，控制器每秒能够处理有限的数据包，如果控制器每秒处理的数据包个数较少，则会造成控制器资源的浪费，因此为控制器每秒处理数据包的个数设置上下限阈值，分别为α和β。应该做什么操作由算法1确定。如果资源池中控制器的负载超过事先设置的阈值α，则添加新的控制器。如果资源池中控制器的负载低于事先设置的阈值β，则关闭或者移除部分控制器。如果在两者之间，则需要一直监测控制器的负载，判断是否需要平衡控制器之间的负载。

(2)是否执行交换机迁移。

是否执行交换机迁移由控制器的负载状况决定。具体的迁移策略参见算法2。其中，LOAD(Ci)表示控制器Ci的负载，按照从小到大的顺序列出控制器的负载，最重的负载和最轻的负载之差为Ldifi。当Ldifi比阈值C大时，交换机发生迁移。一个合适的阈值C，可以实现预想的负载平衡，避免频繁地迁移交换机。

算法2：平衡控制器之间的负载。

While (LOAD(Ci)Table!=NULL) do

Sort_Descending(LOAD(C1),…,LOAD(Cn))

if (Ldifi>C) then

Sort_ Descending(S1,…,Sm) to Migrate

根据式(1)计算函数值

MigrateSjtoCi

End if

UpdateCiSjmapping

end while

(3)哪个控制器选为主控制器。

该系统中设置一个协调节点，一个特殊的控制器。协调节点负责收集每个控制器的负载信息，并且计算系统具体的负载。协调节点也有交换机和控制器之间的静态映射和负载信息表。协调节点通常是第一个加入到系统中的节点。一旦协调节点发生故障，其他控制器可以迅速修改角色变成协调节点。根据负载信息表，负载最轻并且时延满足的控制器选为主控制器，实现某个交换机的迁移。为了实现控制平面的扩展性，当在该组加入新的交换机时，负载较轻的控制器作为主控制器。

(4)哪个交换机应该迁移。

具体选择哪个交换机实现迁移对其负载平衡有着重要的影响。如果选择迁移Packet-in请求速率较高的交换机，将导致新的主控制器的负载较大。如果选择迁移Packet-in请求速率较小的交换机，将导致多次迁移。

文献[6]中提到控制器的响应时间直接影响着流安装的处理速度。控制器的响应时间表示交换机和控制器相连后，交换机发送一个消息给控制器，控制器对该消息进行处理，并将结果返回给相应的交换机的过程所使用的时间。对于交换机是否应该迁移，使用响应时间这个参数，设置一个最初的权值Wi，表示交换机选择的优先级。

(1)

根据算法2，对该控制器管控的交换机在时间间隔内产生的平均流请求进行降序排序，初始时选择平均流请求最大的交换机作为待迁移的对象，然后按照上面介绍的方式依次遍历该控制器管控下的所有交换机，直到选择合适的交换机和控制器。

2.3 交换机迁移

设计交换机迁移机制，当控制器负载较大时，实现将交换机资源迁移到负载较小的控制器管理域内[5-6]。为了保证交换机迁移过程中消息的正常处理，需遵循两个原则：

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

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

3 系统实现

3.1 控制器部署

文中采用ZooKeeper[12]技术搭建多个控制器，ZooKeeper是一个简单高效的分布式协调器。当服务器启动后，从配置文件设置的服务器中选择一台SDN控制器作为领导者，其余控制器便成为跟随者。领导者负责对多个SDN控制器进行管理并提供北向接口服务，跟随者主要负责管理控制交换机。

ZooKeeper采用了原子广播协议，分为广播模式和恢复模式。广播模式可用于数据同步，保证了控制器之间的一致性。服务启动或在领导者崩溃后，恢复模式用于选举领导者。ZooKeeper组服务的功能,可以感知集群中控制器的添加和移除。Zookeeper的观察机制可以实时同步控制器的状态信息。

控制器之间可以通过Zookeeper进行通信，协商完成交换机的迁移，并且更新交换机和控制器之间的映射关系。

每台控制器都有两部分信息：控制器节点的负载信息和控制器与交换机之间的角色映射关系。为了更好地模拟大型网络，将整个系统划分为若干个更小的范围。这里采用分组的形式，每组控制器只知道自己的完整拓扑结构，不知道其他组的拓扑结构，减少了网络上的通信量。

如图1所示，对控制器进行分组，在部署过程中，各分组物理上是分布的，交换机就近选择控制器，减少了控制器和交换机之间的传输时延。每组至少有两台控制器，在主控制器失效的情况下，集群能够从多台从控制器中选择一个作为新的主控制器，避免了控制器的单点故障。当其中一台控制器负载过大，交换机可以迁移到其他的控制器，实现了集群的负载均衡。同时，控制器对交换机透明化，交换机不需要知道接受哪台控制器的控制，保证了逻辑上的集中。

图1 多控制器部署方式

3.2 负载均衡的实现

主要通过修改运行中的控制器角色完成交换机的迁移过程，从而均衡控制器之间的负载。通过对OpenFlow协议的学习，文中提出的迁移机制由从控制器发送Role-request消息开始，后续阶段对其响应，逐步完成交换机的迁移。假设交换机(S)分别与主控制器(C1)和从控制器(C2)相连，当C1的负载较大、C2的负载较轻时，通过S实现负载的转移。交换机的迁移过程如图2所示，主要分为4个阶段。

图2 交换机的无缝迁移过程

第1阶段：C2请求修改角色为对等角色。对于待迁移的S而言，C2首先由从控制器变为对等控制器。C1通过控制器间信道发送一个开始迁移消息给C2，开始交换机迁移阶段。C2发送一个Role-request消息到S中，请求将角色变成过渡角色对等角色。在C2从S收到Role-reply之后，角色将变为对等。只有当C2变为对等角色后，才可以接收到S发送的异步消息，但是此时C2忽视这些消息，不需要响应这些消息。在该阶段，C1仍是唯一的主控制器，能够处理来自S的所有消息，保证了活跃性和安全性。

第2阶段：插入和删除空流表。为了确保迁移的精确时刻，C1发送一个空的Flow-mod命令给S，用于添加一个空流表项，但是该流表项无法匹配即将到来的任何数据包。这里，假设所有的控制器都知道该空流表项。然后，C1再发送另外一个Flow-mod消息用于删除该流表。相应的，S将会发送Flow-removed消息给C1和C2。Flow-removed事件用于确认删除空流表项。之后，只有C2处理S的异步消息。另外，在插入和删除空流表中间使用Barrier消息，用于确保在插入任何消息之前的所有消息都被处理完了，而不是被删除了。

第3阶段：使用Barrier消息刷新待处理请求。虽然C2在第2阶段已经接管了S，但S中可能还有正在处理的请求，C1所需要做的就是处理完所有在Flow-removed之前的消息并且下发给S。因为，交换机并没有明确地确认信息可以确保所有的消息都被C1处理了。如果C1没有发送一个信号给C2，则C1无法变为从控制器，S也将忽略之前的所有操作。因此，为了确保所有的消息都能被处理，C1发送一个Barrier-request消息到S，并等待S回复Barrier-reply消息。此时，C1与S之间的迁移正式结束。

第4阶段：C2请求修改角色为主控制器。C2发送Role-request消息给交换机将其角色改为主控制器。同时，C2更新分布式数据。S在收到Role-request消息后，返回Role-reply消息给C2，S自动将C1的角色修改为从控制器。至此，S的迁移过程正式完成，C2开始处理S的请求。

4 仿真实验与分析

4.1 实验环境

实验基于Ubuntu14.04系统，采用Floodlight[13]控制器组成的控制器集群，在Mininet[14]仿真平台上进行仿真验证。

4.2 性能评价和测试

在SDN网络中，控制器的性能主要体现在短时间内尽可能完成流表项的制定和下发，可以采用吞吐量和响应时间两个指标测试控制器的性能。

吞吐量评估不同的控制器在不同数量线程条件下，能够处理交换机发过来的数据流请求的最大平均流量。响应时间主要评价控制器在被动流表安装模式下，流表项设置过程中产生的最大、最小和平均时延。

(1)吞吐量。

本节测试文中提出的基于集群的部署方案和交换机迁移机制的性能，并且与传统的静态配置方案进行对比。

使用Cbench测量Floodlight控制器的性能，受到本身硬件的影响，测量时参数设置每台交换机连接100台主机，通过改变交换机的个数，经过多次测量，四核CPU的单台Floodlight控制器每秒最多大约可以处理48 600个数据包。Packet-in消息是Floodlight控制器众多模块处理的重点，因此，统计某一段时间内Floodlight控制器处理Packet-in消息的个数反映了系统的处理性能。在Floodlight控制器源码中添加了一个统计Packet-in消息的模块，用于计算系统所处理的消息个数。

逐渐部署1到5台Floodlight控制器，每台控制器连接一台交换机，每台交换机连接一台主机，主机用于在网络中产生UDP数据流。流表的下发有主动和被动两种方式。为了使到达控制器的数据流的速率最大，交换机采取被动安装流表的策略。在控制平面，对其应用做一些修改，禁用交换机安装流表项的功能。这意味着交换机接收到的数据包都是新的流，都要封装成Packet-in消息发送给控制器。

图3表明CPU是限制控制器性能的主要原因，系统整体的吞吐量随着控制器个数的増加大约呈线性增加的趋势，表明系统具有良好的伸缩性，可以通过增加网络中控制器的个数来提高控制平面的处理能力。因此基于集群的多控制器部署方案具有良好的可扩展性。

图3 不同控制器个数的吞吐量

为了测量迁移交换机的方式可以实现负载均衡，实验中部署了5台控制器和20台交换机，交换机随机连接控制器，然后模拟向不同控制器中不均匀地注入大量的数据流，分别测试迁移之前和之后每台控制器的资源使用情况。

从图4中可以看出，静态配置关系中控制器1、2、3的资源使用率都超过80%，而控制器4、5的资源使用率在20%左右，说明控制器之间负载很不均衡。使用迁移机制之后，每台控制器的资源使用率在60%左右，说明交换机迁移的机制可以较好地平衡各控制器负载。

图4 迁移前后控制器的资源利用率

(2)响应时间。

对于交换机迁移过程中响应时间的测量，实验环境中，集群中部署了两台Floodlight控制器C1和C2，8台OpenvSwitch分别连接两台控制器，每台交换机分别连接一台主机。模拟三种不同的负载，主机使用Iperf工具发送不同速率的数据包。

为了模拟控制器之间负载失衡的情况，刚开始时，交换机S1、S2、S3和S4连接控制器C1作为主控制器和C2作为从控制器，交换机S5、S6、S7和S8连接控制器C2作为主控制器和C1作为从控制器。在交换机和控制器之间静态映射的情况下，测量三种不同负载(见表1)下控制器的响应时间，具体结果如表2所示。

表1 三种不同的负载(数据包个数)

表2 不同负载下控制器的响应时间 ms

负载A情况下，在静态配置和迁移机制下，控制器的响应时间差别不大。对于负载B和负载C两种情况，控制器C2的响应时间有很大差别。根据实验可知，集群带来的时延是可以接受的。当在重负载情况下，通过迁移交换机，集群可以使时延更低。

5 结束语

针对多控制器系统中负载不平衡引起的控制器性能下降的问题，提出将集群技术应用到多控制器系统中。为了解决多控制器负载不均衡的问题，提出了交换机资源的实时转移。与传统的静态映射关系相比，该方案可以有效提高系统的处理性能以及网络的吞吐量。下一步工作是考虑到交换机迁移的次数，进一步优化负载调度算法。

[1] TOOTOONCHIAN A, GORBUNOV S, GANJALI Y,et al. On controller performance in software-defined networks[C]//USENIX conference on hot topics in management of internet,cloud,and enterprise networks and services.[s.l.]:USENIX Association,2012:10.

[2] TOOTOONCHIAN A,GANJALI Y.HyperFlow:a distributed control plane for OpenFlow[C]//Proceedings of the 2010 internet network management conference on research on enterprise networking.[s.l.]:USENIX Association,2010:3.

[3] YEGANEH S H,GANJALI Y.Kandoo:a framework for efficient and scalable offloading of control applications[C]//Proceedings of the first workshop on hot topics in software defined networks.[s.l.]:ACM,2012:19-24.

[4] KOPONEN T,CASADO M,GUDE N,et al.Onix:a distributed control platform for large-scale production networks[C]//USENIX conference on operating systems design and implementation.[s.l.]:USENIX Association,2010:351-364.

[5] DIXIT A,HAO F,MUKHERJEE S,et al.Towards an elastic distributed SDN controller[J].ACM SIGCOMM Computer Communication Review,2013,43(4):7-12.

[6] DIXIT A A,HAO F,MUKHERJEE S,et al.ElastiCon:an elastic distributed SDN controller[C]//Proceedings of the tenth ACM/IEEE symposium on architectures for networking and communications systems.[s.l.]:ACM,2014.

[7] BARI M F,ROY A R,CHOWDHURY S R, et al.Dynamic controller provisioning in software defined networks[C]//IEEE/ACM/IFIP international conference on network and service management.[s.l.]:IEEE,2013:18-25.

[8] YAZICI V,SUNAY M O,ERCAN A O.Controlling a software-defined network via distributed controllers[C]//Proceedings of the 2012 NEM summit.[s.l.]:[s.n.],2012:16-20.

[9] YAO G,BI J,LI Y,et al.On the capacitated controller placement problem in software defined networks[J].IEEE Communications Letters,2014,18(8):1339-1342.

[10] Open Networking Foundation. OpenFlow switch specification version 1.3.4[EB/OL].2014-05-27.https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-switch-v1.3.4.pdf.

[11] LIANG C,KAWASHIMA R,MATSUO H.Scalable and crash-tolerant load balancing based on switch migration for multiple open flow controllers[C]//Second international symposium on computing and networking.[s.l.]:IEEE,2014:171-177.

[12] Apache Software Foundation. Apache Zookeepr[EB/OL].2016.http://zookeeper.apache.org/.

[13] Floodlight OpenFlow Controller-Project Floodlight[EB/OL].2012.http://www.projectfloodlight.org/floodlight/.

[14] LANTZ B,HELLER B,MCKEOWN N.A network in a laptop:rapid prototyping for software-defined networks[C]//ACM workshop on hot topics in networks.Monterey,CA,USA:ACM,2010:1-6.