软件定义网络中分布式控制器的在线更换机制

熊一才，张晶晶，刘 轶

1(青海省职业技能鉴定指导中心，西宁 810000) 2(北京航空航天大学 计算机学院，北京 100191)

1 引 言

软件定义网络(Software Defined Networking，SDN)[1，2]将网络中的控制功能与数据转发功能分离，通过控制器进行集中式的转发控制，并允许上层应用对控制器的转发策略等功能进行编程，因而实现了网络的灵活配置与管理，并可实现新应用和服务功能的快速定制和部署.由于软件定义网络技术的诸多优点，近年来得到了快速的发展和应用.

在以大型数据中心和企业网络为代表的大规模网络中，单一集中式控制器难以满足网络的可扩展性需求，且控制器单点故障很容易导致整个网络瘫痪.为了保证网络性能和可靠性，人们进一步提出了分布式控制器[3-5]，该技术通过使用多台物理上分布的SDN控制器协同工作，实现逻辑上的集中式控制，以提高网络的可扩展性和控制器的容错能力.由于此类网络多为长时间持续运行，控制器的硬件升级/更换、软件升级等维护工作通常需要对分布式控制器中的指定节点进行在线更换，且须在不中断服务的情况下完成.在控制器更换过程中，需解决两个问题：首先，被更换的旧控制器的服务不能中断，即交换机和其他控制器的请求在更换过程中必须得到及时响应；其次，由于计算机技术发展迅速，新更换节点的硬件资源和处理能力往往高于现有的其他控制器，这会导致分布式控制器间性能的差异，为充分利用新控制器的硬件资源，需在控制器更换后重新进行异构控制器间的负载均衡.

为了解决上述问题，本文提出了一种分布式控制器的在线更换机制，该机制通过控制器间的协同，可在不中断控制器服务和不丢包的情况下实现指定控制器节点的更换，同时提出了一种更换后的控制器间负载均衡策略，以较低的开销实现分布式异构控制器间的负载均衡.在线更换机制和负载均衡策略以应用程序形式运行在SDN控制器中，易于扩展和部署，实验测试验证了该机制的有效性.

2 SDN控制器的在线更换机制

2.1 在线更换过程概述

本文提出的SDN控制器在线更换机制以应用模块的形式运行在每个控制器上.图1给出了控制器的更换过程.

图1 SDN控制器的在线更换过程Fig.1 Online swap procedure of SDN controllers

假设要用一台新的控制器Xnew更换现有的控制器X，更换过程包括以下三个步骤：

1)将新控制器Xnew加入到网络中

管理员将新的控制器Xnew添加到被替换控制器X的位置，Xnew可以通过分布式数据存储获取当前网络信息(如链路和拓扑信息等)，并将其自身信息(如硬件性能、运行状态等)存储到分布式存储中以供其它控制器访问.

2)在异构分布式控制器间进行负载均衡

新加入的控制器Xnew根据当前网络负载状态和自身性能计算交换机的负载，并根据计算结果调整自身和相邻控制器的管理范围.

3)交换机平滑迁移和控制器角色更换

在确保网络中的请求能被正常接收和处理前提下，将控制器X所管理的交换机迁移到Xnew，并根据上一步的负载均衡计算结果，将相邻控制器的部分交换机迁移到Xnew.在此过程中，控制器和交换机间按照预先设计的角色切换流程和通信协议进行协同，以确保分布式控制器系统的服务不中断.

交换机迁移完成后，管理员即可删除被更换控制器X.

2.2 负载均衡

负载均衡计算由新控制器Xnew负责完成，在此期间，其他控制器正常处理网络中的各种事件.所采用的负载均衡策略基本思路是：在满足延迟需求的情况下，将尽可能多的负载分配给新控制器，这一方面是考虑到新控制器通常拥有更高的硬件性能，另一方面，其他控制器的工作负载不会因为本次负载均衡而增加，因而不会影响到现有的网络性能.

负载均衡过程包括确定负载均衡范围、负载信息收集、区域计算三个步骤.

1)确定负载均衡范围

由于新加入控制器与被替换控制器处于同一位置，这样可以只调整本控制器和相邻区域的负载，而不必进行全网络的负载均衡，这不但可以大幅降低本次负载均衡的开销，还可减小在线更换对整个网络的影响.

以图2为例，图2(a)给出了一个包含8个控制器的网络，每个控制器管理其负责的网络区域.对该网络拓扑进行抽象后，得到如图2(b)所示的控制器向量图.该向量图只包含控制节点和连线边，其中控制节点对应控制器及其控制区域，如果两个控制节点间有边相连，表示这两个控制器所管理的区域相邻.在本例中，假设要更换控制器8，那么根据向量图可以确定负载均衡范围如虚线包含的区域所示.

图2 确定负载均衡范围示例Fig.2 Determine load-balancing scope

2)收集负载信息

在确定负载均衡范围后，需要收集本次负载均衡范围内每个控制器的负载信息，为后续的负载均衡计算提供依据.这通过每个控制器上运行的负载测量模块来完成，该模块周期性地记录控制器的CPU利用率、平均消息到达速率、控制器最大吞吐率、控制器间及控制器与交换机间距离.这些参数将被收集用作后续负载均衡算法的输入.

3)区域计算

图3以伪代码形式给出了计算各控制器区域的算法流程.算法的输入为所收集的负载信息和拓扑，输出为需要迁移的交换机集合.

算法的基本思想是以被更换控制器的现有控制区域为基础，逐层向外扩展，在可能的情况下，加入尽可能多的交换机.首先，新控制器预接管被更换控制器X管理的区域Rx，然后计算其边界交换机集合Sborder(第1-3行)，Sborder是那些和区域边界相连但不属于该区域的交换机的集合，也就是和管理区域相邻一跳的交换机集合；然后，从边界控制器集合中选择合适的交换机(9行)分配给新控制器Xnew(4-15行)；最后更新Sborder和新控制器的信息，进行下一次循环，直到找不到合适的交换机为止.可以看出，该算法的计算复杂度最高为O(n2)，其中n为控制器的边界交换机个数.

对于一个交换机s来说，综合考虑控制器负载、通信延迟和链路数三方面的因素来决定其是否被新控制器管理.这三方面因素的计算公式如下：

控制器负载因子Fu：

(1)

式中的Uori为交换机s当前主控制器的CPU利用率，Unew为新控制器的CPU利用率.该比值越大，说明越应该将该交换机迁移到新控制器.

延迟因子Fd：

(2)

上式中的Ds，ori和Ds，new分别是交换机s到当前主控制器和新控制器的距离，Dori，new指两个控制器之间的距离.考虑到控制器位置的重要性，尽量选择距离控制器较近的交换机进行迁移.另外由于交换机的迁移需要两个控制器间的通信，因此两个控制器间的距离也作为考虑因素.为简单起见，此处用跳数来衡量距离.

链路因子Fl：

(3)

上式中的n是与交换机s直连的链路数，m是连接交换机s和新控制器区域的链路数.对于交换机s来说，m与n的值越大，说明该交换机和新控制器的亲密度越高，该交换机越应该被分配给新控制器.

综合考虑以上三方面的因素，得出交换机s的迁移指数计算公式如下：

M=w1×Fu+w2×Fd+w3×Fl

(4)

上式中的w1、w2和w3分别是负载、延迟、链路三个因子在迁移指数中所占的权重比例系数，取值范围在0—1之间，且三个权重之和为1.对于一个交换机s来说，其迁移指数越高，说明在当时的网络状况下，新控制器管理这个交换机越合理.为控制交换机迁移的数量，设置一个阈值α，当迁移指数M>α时，交换机才会被迁移.

算法1.选择需迁移交换机

输入：Network=(V，E)，负载信息f

输出：应由控制器管理的交换机集合Rx

图3 负载均衡算法
Fig.3 Load-balance algorithm

2.3 交换机平滑迁移和控制器角色更换

在负载均衡计算完成后，就可以根据新的区域划分方案进行交换机的迁移，并完成新旧控制器的在线更换.这一过程按照控制器角色切换流程和通信协议，通过新旧控制器之间以及与其他控制器间的控制消息传输实现角色切换，以确保在更换过程中网络中的各种请求能被正常接收和及时处理，即网络服务不中断.

图4给出了切换过程中控制器间以及控制器-交换机之间通过消息传输进行协同以实现角色切换的流程.如图4(a)所示，角色切换过程分为三个阶段，在不同的阶段，明确定义了由新/旧控制器中的哪一方负责接收和处理网络请求，并且在旧控制器内的请求被处理完毕之前，其角色不能改变.在交换机迁移开始前(第1阶段)，来自其他控制器的请求仍然被发送给旧控制器；交换机迁移开始时，新控制器向除旧控制器外的其他控制器发送迁移信息，包括新旧控制器的地址、需迁移交换机集合等；其他控制器收到迁移信息后(第2阶段)，向新旧控制器发送消息，获取交换机的主控制器，主控制器(可能是新控制器或旧控制器)在收到消息后返回应答；其他控制器在得知交换机的主控制器信息后，在替换过程的后续阶段将请求发送给主控制器.

图4 在线更换过程中的协同和消息传输Fig.4 Coordination messages during the swapping

图4(b)给出了在控制器角色切换过程中交换机的切换流程，该流程由新控制器向旧控制器发送启动替换消息开始，旧控制器完成准备操作后回应确认消息，随后，新控制器向需迁移的交换机发送Role-Request消息，将其角色改变为equal，其后的交换机切换流程与文献[6]中的方法一致，该流程可避免切换过程中出现丢包.

在交换机迁移完成后，新控制器向其他控制器发送消息，通知更换结束.至此，旧控制器退出分布式控制器的协同控制，可以由管理员将其从控制平面中删除.

3 系统实现

本文所提出的控制器在线更换机制可用于平面式的分布式控制器系统.基于Openflow实现在线更换机制的系统结构如图5所示，系统主要包括以下四部分：

1)底层物理网络设施：包括网络交换机及链路.从OpenFlow1.3协议开始，为了避免单台控制器和交换机的连接中断，一个交换机可以同时连接到多个控制器上，但是只有一个是master控制器，其余的是slave控制器，该项功能是实现交换机迁移的基础.

2)控制器节点：每个控制器管理SDN网络的不同部分，控制器之间通过通信模块传递消息.在线更换功能主要由控制器中实现的三个模块实现：负责收集本控制器负载信息的负载收集模块，根据所收集信息进行负载均衡计算的计算模块，以及根据负载计算结果进行交换机迁移的迁移模块.

3)分布式数据存储：负责收集集群节点的信息，为上层应用提供一个全局的逻辑视图，它存储所有控制器以及其管理的交换机的特定信息，如控制器负载信息、链路信息、拓扑信息等.

图5 系统结构Fig.5 System architecture

4)分布式协同服务Zookeeper[7]：负责SDN分布式控制器系统的成员管理，如实例变化的检测和应对等.

本文在开源的Floodlight[8]控制器中实现了在线更换机制，包括负载信息收集、负载均衡计算、交换机迁移等模块，这些模块以应用程序的形式运行在控制器中.Zookeeper用来实现分布式数据存储以及提供协同服务，它可向所有的分布式控制器提供网络的全局逻辑视图.

4 实验测试

4.1 实验环境

实验环境包括一台服务器和一台PC机，两者之间通过万兆以太网互连.服务器上运行所有的SDN控制器实例，PC机上运行一种SDN网络模拟软件Mininet[9]，它可以按照设定的网络参数(交换机台数、拓扑等)模拟SDN网络中交换机的工作，并通过网络接口发送/接收交换机-控制器间的消息.因此，该实验平台为SDN控制器提供了与真实SDN网络一致的网络环境.表1给出了实验环境的硬软件参数.

4.2 负载均衡计算时间测试

首先使用随机网络拓扑测试负载调整算法的时间开销.在随机的拓扑中，假设有N个节点，那么边的个数为Nx，其中x是变量.在实验中，选择x=1.25和x=1.15两个数值，交换机节点的个数为0～3000.边的位置随机生成.公式(4)中的三个权值参数w1、w2、w3分别设置为0.8、0.1、0.1.

表1 实验环境配置Table 1 Configuration of experimental environment

图6给出了在不同网络拓扑下负载均衡算法的计算时间.从图中可以看出，随着交换机个数的增加，计算时间呈线性增长.在交换机个数一定时，x=1.25的时间花销明显比x=1.15的时间开销大，这是因为算法在寻找边界交换机和计算交换机花销时，都需要使用链路进行计算.此外，对同一拓扑，阈值α的取值也会对计算时间产生影响.当α值较大时，满足迁移条件的交换机较少，反之亦然.

图6 负载均衡算法在不同网络规模和拓扑下的计算时间Fig.6 Computation cost of load-balancing

4.3 迁移时间测试

该实验测试在不同消息速率下交换机迁移所用时间.实验使用两个控制器实例A和B，首先把所有交换机连接到A和B上，并设置A为Master控制器，B为Slave控制器.然后计算不同条件下把所有交换机从控制器A迁移到B所用的时间.定义控制器A、B的迁移时间为从发出/收到start消息开始到收到所有交换机的role_reply消息为止的时间；总的迁移时间从B发出start消息开始，结束时间从控制器B接收到end消息的时间和B的结束时间中取最大值.

实验测试分为两组.第一组实验中，每个交换机的发送速率固定(100res/s)，改变交换机个数；第二组实验中，交换机个数固定(50个)，改变每个交换机的发送速率(1000res/s～10000res/s).实验结果如图7所示.

从图 7(a)可以看出，当每个交换机的发送速率固定时，随着交换机个数的增加，迁移时间呈上升趋势.并且当交换机个数达到一定数值时，迁移时间有一个快速上升.这说明当迁移的交换机达到一定规模时，需要的迁移时间也会很长.其次，从每组的三个数据来看，当所有的控制器实例运行在一个服务器上时，网络节点之间的通信开销，包括控制器之间以及控制器和交换机之间的通信，对于迁移交换机影响很小.实验中通信的花销一般是几毫秒，但是当多个控制器运行在不同的服务器上时，控制器间的通信开销值会达到几十毫秒甚至几百毫秒，这与设备的性能有很大的关联.在图7(b)所示的第二组实验结果中，在交换机个数固定情况下，迁移时间随着包速率的增加而增加，但是增长的速度小于图 7(a)中的速度，这说明在总速率相同的情况下，交换机个数对于迁移时间的影响要大于消息速率.

图7 交换机迁移时间Fig.7 Migration time of switches

4.4 在线更换测试

本实验测试控制器在更换前后的性能变化.使用Mininet模拟的SDN网络拓扑如图8所示，图中包含64个节点(交换

图8 实验网络拓扑图Fig.8 Topology of SDN network

机)和77条链路，这些交换机分由4个控制器C1～C4控制，初始时各控制器负责的区域如图中虚线所示，每个区域中的交换机均为16.实验中，4个控制器实例运行在一台服务器中，每个控制器实例绑定一个处理器核运行，每个交换机每秒发送固定数量的packet-in消息，然后用一台拥有四核处理器的新控制器更换当前控制器C1.

图9 替换前后控制器的CPU利用率和管理区域的变化Fig.9 CPU utilization and area of controllers

图9给出了控制器吞吐率、负载和管理区域的变化.在更换之前，每个控制器的处理能力相同，且管理的交换机数量相同，由于交换机发送的流量请求超过控制器的处理能力，四个控制器的吞吐率相同，且cpu利用率均达到100%.控制器更换完成后，由于新控制器C1的处理能力更高，经过负载均衡，其管理区域内的交换机个数由16个增加到31个，吞吐率也相应增加，同时其他三台控制器管理的交换机数量都从16减少到11，吞吐率也随之下降.

通过本实验可以看出，在一个控制器负载较高的网络中，使用一台硬件性能更高的控制器更换原有控制器后，网络的综合状况得到明显改善.

5 相关工作

针对SDN网络中控制器软件更新问题，文献[10]提出了HotSwap，该系统首先记录网络事件，并把这些事件回放给新控制器，然后比较新旧控制器转发规则，进行规则的更新，最后完成新旧机器的替换.HotSwap能够在不中断服务的情况下完成控制器软件系统的更新，同时保证软件更新的正确性.HotSwap的更新过程主要针对控制器软件的更新，并不考虑设备的硬件性能的提升，以及在SDN异构环境下设备性能提升后对整个网络带来的影响.

针对控制器与交换机之间静态的映射关系难以适应网络中控制平面负载变化的问题，现有的关于多控制器的研究提出多种解决方案[6，11-14].这些方案是根据网络中负载的实时变化，利用不同的负载均衡策略，动态地均衡控制器之间的负载.它们主要是通过定期收集交换机和控制器的负载信息，对信息进行整合计算，并根据不同的负载策略通过改变交换机和控制器的映射关系进行负载调整.如ElastiCon[6]周期性的检测每个控制节点的负载并进行记录.每隔一段时间执行负载调整算法，以cpu利用率为衡量指标查找是否有需要迁移的交换机，根据返回的结果调整交换机和控制器之间的映射关系，从而达到负载均衡的目的.根据上述分析，现有的负载均衡方法无法满足管理员对指定网络范围进行调整的需求.例如，当管理员希望对某控制器进行硬件升级时，现有方法无法根据管理员的意愿对指定机器进行操作，并在没有触发负载调整的条件下，升级的控制器需要等待一段时间才能获取足够的负载.

6 结 论

分布式SDN控制器是提高SDN网络可扩展性和可靠性的有效途径，在系统的长时间持续运行过程中，控制器的硬软件维护和升级在所难免.针对这一问题，本文提出了一种分布式SDN控制器的在线更换机制，实现了分布式控制器的在线更换和不中断服务，同时针对控制器更换后性能异构带来的负载不均衡问题，给出了异构控制器间的负载均衡算法.实验测试表明该机制可高效地完成新旧控制器的在线更换，以及交换机的平滑迁移和负载均衡调整.