SDN网络多控制器结构的失效备援设计

SDN网络多控制器结构的失效备援设计
摘要：为了提高可扩展性，软件定义网络出现了多控制器架构。

但是多控制器架构中数据交互的复杂性也在快速增加，某个控制器故障导致网络不可用的情况时有发生。

为了提高多控制器架构下软件定义网络的服务可靠性，本文设计了一种多控制器失效备援方法，降低了现有多控制器架构下提升网络可靠性的技术的复杂性，同时减少了控制器之间状态交互消息的数量，对提升网络服务质量，降低设备部署的成本和复杂性，保证网络的高可用性方面具有极为重要的意义。

关键词：软件定义网络；多控制器；失效备援
中图分类号：TN-915
文献标识码：A
DOI：10.3969/j.issn.1003-6970.2016.01.017
本文著录格式：王钰琪，窦伟超.SDN网络多控制器结构的失效备援设计[J].软件，2016，37 （01）：71-75 O 引言
由于互联网应用的爆发式增长，全球信息量每年以指数级的速度增加；目前诸如路由器的数据转发设备将控制平面和数据转发平面耦合在一起，导致路由器要支持新功能所需
要的升级成本和难度极大，安全性也不够高，网络需要一种新的结构来增强可扩展性和服务能力。

SDN创造性的将控制平面的逻辑和转发平面分离，SDN中分为两种设备，交换机和控制器。

控制器通过Openflow协议向交换机下发流表规则来控制交换机的转发能力，交换机通过流表完成数据的转发。

SDN的核心在于转发逻辑不再固化于硬件，所有的转发逻辑都由控制器通过Openflow协议动态下发至交换机，交换机因此可以支持各种类型的规则，极大的增强了网络的可扩展性。

但是，现有的SDN分布式架构同样遇到一些挑战，控制平面的集中化使得控制器出现单点故障的危害性较大，同时单个控制器可支持的交换机数量有限，不能满足网络规模的不断扩展。

为了解决这个问题，SDN网络出现了多控制器架构，现有的多控制器结构中，每个控制器会控制一部分交换机，这部分交换机作为此控制器管的一个域，各个控制器管控单独的一个区域内的交换机。

如图1所示，控制器之间交换控制信息达到全网数据包转发和管理的目的。

相邻的交换机之间交换拓扑状态、交换机信息等数据，这样使得整个网络中任何两个域的数据流量可以被转发。

同时这种结构也解决了聚集式控制平面出现的低扩展性和高负载的问题。

但是这种架构仍然没有解决在某个控制器出现故障以
后出现的网络可靠性损失，当某一个控制器出现故障之后，
部分交换机会失去连接导致一些服务失效。

为了最小化这种故障，必须要有一种快速反应机制使失去连接的交换机与其他存活的控制器建立连接。

现有的基于多控制器提出扁平化架构的失效备援解决方案中，各个控制器都维护全网络的拓扑，某一控制器失效不会影响到网络服务损失，但是此种方法使控制局部网络的控制器维护全网拓扑，单个控制器维护大量状态，负载过高导致性能下降。

l 相关研究工作
过去的几年中，一些方法将软件定义网络中集中化的控制平面逻辑上分布在多个控制器上，同时也提出了控制器故障时的解决方案，但是这些方法都要在各个控制器之间产生大量控制消息的流量。

如.Onix和HyperFlow。

Onix作为作为一个分布式控制器，它基于扁平分布式控制器架构，通过网络信息库进行管理。

每个控制器都有各自独立的信息库，并且各个控制器之间通过数据交互保持信息库的一致性，可以实现控制器之间的数据同步和更新。

HyperFlow允许部署多个控制器，并将这些控制器分布在网络中的不同位置。

控制器之间物理上分离但是逻辑上集中。

HyperFlow在某控制器失效时，通过手动配置的方法将失效控制器管理的交换机重新配置到新控制器上，保证了可用性。

但是使用这种方法网络管理员工作量较大而且耗时较长。

还有一种方法被提出，它在多控制器环境下能够在一些环境下提升网络可靠性，但
是部署相对比较复杂。

上述的这些结构和方法，每个控制器虽然掌握了全网状态信息，但只能控制局部网络，造成了一定的资源浪费，同时一旦有一个控制器信息出现变更，就要向全部控制器传输更新消息，增加了网络更新时控制器的整体负载。

为了解决多控制器场景下控制器失效导致网络服务质
量降低的问题，本文提出了一种软件定义网络中多控制器失效备援方法，将由于控制器故障而失去连接的交换机动态切换到其他相邻控制器上，能够对控制器失效反应快速且保证全网的连接性。

为此我们设计一个主控制器管控其他控制器，维持网络全局信息，主控制器和其他控制器保持心跳，确保其他控制器正常工作。

各个控制器向主控制器报告自己控制的交换机信息。

当某控制器失效时，失去连接的交换机能够向主控制器提出请求，主控制器选择一个合适的控制器，保证各个控制器上交换机数量负载均衡。

2 失效备援机制
2.1 多控制器失效备援架构
本文描述的失效备援机制的架构如图2所示，使用了层次化设计，在最顶端设计一个主控制器。

主控制器的主要作用是：（1）维持各个控制器的交换机连接信息（2）和各个
控制器保持心跳，确认控制器工作正常（3）在控制器故障时，将失去连接的交换机动态迁移到适合的存活控制器上。

为了防止主控制器出现单点故障，我们需要对主控制器做一次热备。

Fig.2 Failover mechanisms architecture
为了支持多控制器架构下各个层面的控制器可以协同
工作，各个单个域的控制器要将各自网络的关键信息传递给主控制器，所谓的关键信息包括：
控制器所管控的交换机的ID和交换机连接拓扑
各个交换机上的流量负载情况
控制器相邻的控制器的标志和自身处理能力和负载
通过这些信息，当某一个普通控制器出现故障以后，主控制器可以全面的考察其相邻控制器的状态，包括流量负载，连接的交换机等数据，从故障控制器相邻的控制器中选出负载最低的一个作为故障交换机重新连接的目标控制器。

为了统一处理层次间的消息，主控制和普通控制器利用Yang 模型设计出抽象的数据传输接口和数据格式。

Yang模型和工具就是实现XML字符信息和ODL内部Bean Object之间的转换，无论从可扩展性、耦合、开发效率上都有优势。

同时Yang 模型采用安全的面向连接的通信传输方式，相比起SNMP采用UDP传输具有更加良好的安全性，且支持更大规模的数据传输。

通过Yang模型定义，通用的API运行大量网络业务传输数据，特别是在多控制器架构中，这些不同的普通控制器域
可能是由不同的Openflow控制器，但是我们通过定义通用
的接口，使得各种不同类型的Openflow控制器可以协同工作，减少因为软件不同造成的技术障碍。

我们将普通控制器发送给主控制器的消息中包括的数据利用Yang模型定义内
容如下：
在本文中，接口基于REST API设计，实现数据的高速传输。

主控制器维持其他控制器的交换机连接信息，为此主控制器内维护一个交换机信息表，保存各个普通控制器的交换机连接信息，同时和其他控制器建立socket连接，传递最新的交换机信息。

我们定义了一种数据格式，如图3所示，普通控制器向主控制器发送各自的交换机连接信息，此消息中包括控制器名称和交换机标志，交换机标志使用交换机硬件地址确保唯一性。

此数据包分为ADD、DEL_ MOD、RESEND
四种类型，ADD表示普通控制器向主控制器发送交换机信息增加的命令；DEL表示普通控制器向主控制器发送交换机信
息删除的命令；MOD表示普通控制器向主控制器发送交换机信息更新的命令，更新交换机所属控制器，主控制器收到消息后相应地更新交换机信息表；RESEND表示主控制器向普
通控制器发送交换机信息重传的命令，让某控制器利用ADD 消息重传全部交换机信息。

主控制器和普通控制器之间保持心跳，每5秒钟发送一次心跳报文，心跳报文用于主控制器确定普通控制器的存在，
当主控制器发送的报文1秒没有收到回复，则进行重发动作，当重发次数达到5次则可以确定普通控制器已经失去连接。

我们在主控制器上设计失去连接表，表格会维护目前失去连接的控制器表，用于主控制器在收到交换机失去连接的消息时能够决定是否此控制器已经故障中断。

SDN网络可以通过几种方法发现有控制器已经出现故障：主控制器和普通控制器之间的心跳
主控制器和每个控制器之间保持固定间隔的心跳，相互交换机信息，如果在一定时间段内主控制器收不到某个普通控制器的心跳返回消息，则可以判断此普通控制器故障。

交换机发出的连接决断消息
当某个控制器和交换机之间的连接中断，交换机根据自身的反应机制会自动向主控制器发送故障控制器和交换机
的信息，主控制器以此可以判断故障情况。

2.2 0penflow中控制器的角色
在我们设计的分布式多控制器场景中，每个控制器对它自己域内的控制器管理和控制（这些控制器将此控制器设置为Master角色）。

为了达到控制器之间的切换，一个控制器需要能和交换机保持连接，同时能够发送Role-Reque st消息来接管交换机的管理权。

根据Openflow协议的定义，每个交换机可以与多个控
制器相连，与交换机相连的控制器的角色分为Master，Slave，
Echo。

角色为Master和Echo的控制器可以向交换机下发流
表等控制消息，而角色为Echo的控制器只能获取交换机信息。

每个交换机只能设置一个控制器为Master角色。

利用多控制器的角色机制，处理控制器故障最简单的方法是为每个域设计一个备援控制器，但是此举的配置代价和维护费用也是极其昂贵的。

我们再次阐述的控制器失效备援机制中只需要对主控制器做一次主动备援，其他控制器的故障都可以通过相邻控制器的接管完成。

如图4所示，在我们描述的失效备援架构中，每个控制器负责的区域内的交换机都将此控制器设置为Master角色，将主控制器设置为Echo角色，同时将其他相邻的控制器设置为Slave角色。

当交换机失去连接时，会主动向主控制器发
送失去连接消息，由主控制器决定哪一个普通控制器接管交换机，接管的控制器会向交换机发送标准Openflow消息Role-Request消息成为此交换机的Master控制器，保证数据流影响尽可能小。

2.3 失效备援机制流程
整个备援机制的流程可以经过如下几个阶段。

2.3.1 检测到故障控制器的出现
这一步主要是通过主控制器和普通控制器之间的心跳
消息以及交换机发送给主控制器的连接决断消息来完成。

如果主控制器和普通控制器之间的心跳中断，或者主控制器收
到交换机发送来的连接决断消息，都会激发主控制对控制器故障的检查流程。

由于主控制器和某普通控制器的心跳中断并不能直接说明此普通控制器已经故障，因为有可能仅仅是此普通控制器和主控制器之间网络连接断开等原因造成。

主控制器会根据不同的情况做出不同的判断，这部分的操作逻辐会在本文第3部分中详细说明。

2.3.2 检测到故障控制器的出现
当主控制器判断某普通控制器出现故障时，会通过故障控制器相邻的控制器发送来的各自状态信息，计算出一个合适的控制器，算法会考察相邻控制器的交换机连接数，数据流量负载等因素的权重，当主控制器已经决断出一个普通控制器进行接管时，会要求此控制器发送Role-Request消息接管故障控制器的交换机，完成交换机的动态迁移。

2.3.3 域状态更新
当切换完成时，主控制器需要获取实时的网络状态信息，接管的普通控制器会将接收的交换机信息更新至主控制器
的交换机连接表中，保证各个域内的交换机信息保持实时一致。

3 故障情况分析
此场景如图5所示，控制器B和控制器A和控制器C相邻，控制器A、B、C各管理一块交换机区域，并和主控制器保持连接和心跳。

控制器B管理的交换机将主控制器设置为
Echo角色，将与控制器B相邻的交换机设置为Slave角色。

3.1 普通控制器故障
当控制器B出现故障时，控制器B所控制的交换机失去连接，同时主控制器根据心跳判断出控制器B出现故障，这时会将控制器B加入失去连接的控制器表。

此时失去连接的交换机会向主控制器发送连接决断消息，此消息中包含交换机信息和控制器B的标志。

主控制器收到此消息后会先判断控制器B是否在失去连接的控制器表中，如果在则根据交换机信息表中存储的控制器B相邻的控制器的流量负载以及交换机连接数，进行如下计算：
W=C*0.3+L*0.7
其中W标示最终加权值，C表示控制器连接的交换机数，L表示控制器上的负载流量。

对于控制器B相邻的控制器都进行一次加权计算，将W 值最低的作为交换机的接管控制器，此时主控制器会命令权值最低的控制器向交换机发送Openflow的Role-Request消息，将角色变更为Master，接管此交换机，同时此控制器向主控制器发送交换机信息MOD消息对交换机信息表更新。

通过
此处理，控制器B管控的交换机可以均匀的由控制器A和控制器C接管，保证网络的负载均衡。

3.2 控制器B和交换机连接故障
此种情况下控制器B和某交换机连接故障，但是和主控
制器之间保持心跳。

此时交换机会向主控制器发送连接决断消息，主控制器收到此消息后查找失去连接的控制器表失败，则向交换机发送重新连接控制器B的命令，如果主控制器仍然收到此交换机发送的连接决断消息，则可以判断出控制器
B和交换机连接故障，会根据上一小节所述方法选择出一个
合适的控制器接管此交换机，同时利用交换机信息MOD消
息更新交换机信息表。

3.3 控制器B和主控制器连接故障
此种情况下控制器B和主控制器连接故障，和交换机保持连接。

此时主控制器会向管理员报警，当网络连接正常以后，会将交换机信息表中与控制器B相关的交换机信息删除，同时发送RESEND消息让控制器重新传输交换机信息。

4 实验验证
为了验证基于本文提出的多控制器场景下SDN网络失
效备援方法的有效性，本文对同现有的扁平结构下失效备援机制做出数据上的对比，主要包括为保证可靠性所需要的状态信息表的内存大小和故障恢复时间。

首先是统计对比在不同数量的交换机场景下，上述两种方法为了保证可靠性所需状态信息表占用的内存大小。

统计此项数据通过在程序运行时对状态信息表分配内存的数值
存入log完成统计。

对比数据如表2所示：
网络从发生故障到故障切换完成会造成一定的网络服
务质量降低，这一段时间越短，网络服务质量越高。

为此，本文比较了现有扁平结构的失效备援机制故障时间和本文
所述备援机制的故障切换时间，此数据通过在检查出故障到完成切换前后加入Linux定时器统计出故障切换时间。

所得
到实验数据如表3所示：
通过上述数据的对比，我们可以证明本文描述的层次式多控制器失效备援机制可以减小设置的状态信息表大小，同时切换时间在交换机数量增加时增长幅度较小，很好的提高了网络服务质量。

5 结论
本文描述了一种软件定义网络中多控制器场景下失效
备援机制，此失效备援机制基于层次化设计，减少各个控制器同步消息所用的带宽，当控制器故障发生时，可以在尽量小的时间内动态恢复网络连接，提升网络故时的服务质量；在此基础上设计平衡选择策略，使交换机连接负载最小的相邻控制器，网络流量和交换机连接均衡分配在各个控制器上，使现有网络稳定性较高。

同时无需在各个控制器之间同步消息，使各个控制器仅仅维护局部网络拓扑和连接信息，减少各个控制器不必要的负载。