一种面向多管理域SDN控制器故障处理方案

卞宇翔，沈苏彬，吴振宇

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

一种面向多管理域SDN控制器故障处理方案

卞宇翔1，沈苏彬1，吴振宇2

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

随着软件定义联网(Software Defined Networking，SDN)的不断发展，SDN网络的需求和服务不断扩大。SDN控制器作为全网的控制和管理中心，承受着巨大的业务需求压力，极易造成SDN控制器的瘫痪和故障，出现服务中断等不利影响。同时，单个管理域所呈现的局限性也越来越大。为了解决SDN控制器瘫痪和故障造成的严重后果，克服单个管理域的局限性，在多管理域场景下，根据监测到的SDN控制器故障结果提出具体可行的控制器故障恢复的解决方案。为此，提出了基于OpenFlow消息进行SDN控制器故障监测的方法，研究了控制平面的多控制器部署问题，讨论了多控制器的同步机制，搭建主备控制器模型用于实现交换机迁移，根据域内和域间不同的应用场景，采用了不同的故障恢复策略。采用交换机迁移的最小代价原则选取备用控制器，实现故障恢复。测试结果表明，多管理域场景下对故障控制器执行不同的故障恢复策略可以实现对SDN控制器的故障恢复。

SDN控制器；故障监控；故障恢复；多管理域

0 引 言

随着ICT技术的不断发展，网络规模呈几何级扩大，人们对通信业务的需求量也在增大。传统网络设备的控制逻辑和数据转发功能紧密耦合，例如交换机和路由器。这些传统网络设备在解决通信需求中表现得越来越吃力，负载不断变大，执行效率也在降低。为了解决这一技术难题，软件定义联网[1](Software Defined Networking，SDN)引起了人们的注意。SDN是一种新型的可编程网络架构，它把控制模块从传统网络转发设备中分离开，部署于一个综合控制逻辑单元—控制器[2]，用户可以通过开放的可编程接口灵活地指导网络设备的数据转发，而网络设备只具有简单的数据转发功能。这种创新性的结构实现了对网络的全局集中控制，降低了网络管理的复杂度，提高了对通信业务处理的效率。因此，SDN网络架构的出现对未来网络的发展起着至关重要的作用。

然而，虽然SDN是一种新型网络架构，但是仍然避免不了传统网络中出现的各种各样的网络故障问题，如分组流转发设备故障、端口故障、网络电缆断裂等等。其中，控制面的故障问题尤为复杂。控制器作为SDN网络的“大脑”，如果控制器出现故障，整个网络必将瘫痪，会造成严重的网络危机。因此，控制器故障问题后果最为严重，是最需要解决的问题，同时也是SDN网络最大的限制瓶颈[3]。

伴随着网络规模的扩大，单一的管理域服务已不再能满足相应需求，随之而来的是多管理域的实现和部署。为了随时应对跨管理域的多控制器故障，提供可靠的服务质量，文中提出了域内和域间SDN控制器故障监控和恢复策略。基于控制器故障监控获得的结果，针对不同条件下域内和域间的情况，采用最小代价原则选取备用控制器，通过实现交换机迁移，将已故障的控制器所执行的功能要求全部交付给备用控制器处理。同时能够保证交换机迁移前后网络状态的一致性，不再出现备用控制器重复处理已故障控制器在故障前所处理的需求或者备用控制器遗漏已故障控制器故障后所需要处理的业务需求。这样能够实现控制器的无缝对接，不影响用户需求，甚至不让用户察觉，保证较高的用户体验。

为了更好地说明控制器故障的监控和恢复原理，文中承认以下3个事实和条件：

(1)就控制平面的故障问题进行监测和恢复策略的研究，需要保证数据平面能够正常工作；

(2)在交换机与控制器之间以及不同控制器之间，只存在带内连接[4]。也就是说，控制器下发的控制流量只使用网络中已有的数据通道进行传送；

(3)控制平面和转发平面之间的接口协议需要OpenFlow v1.3及其以上版本的支持。

1 相关技术分析

由于SDN控制器是SDN网络控制和转发中心，同时控制器各个内部单元模块[5]紧密联系，相互依靠，不可分割。因此，控制器出现故障，进行故障检测难度过大，时间过长，恢复效果较差。为此，通常采用更换备用控制器的方式进行SDN控制器的故障恢复。当监测到控制器故障后，更换控制器可以较快地实现控制器重新工作，且不影响原先的业务处理。

但是，与单个管理域简单更换控制器相比，多个管理域间协同处理网络数据流更符合未来网络发展的需求。为此，文中立足多管理域实现控制器的故障恢复。

因为单一的控制器无法应对跨多个管理域的SDN网络问题，需要多个SDN控制器组成分布式的控制架构[6]。对外表现出集中控制，这样可以避免单一的控制器节点在可靠性、扩展性和性能方面的问题。多控制器架构主要是用于解决控制器负载不均衡的问题而设计实现的。但是，结合多控制器架构特点，将多控制器架构应用到控制器故障恢复这一场景中，同时实现了跨管理域的部署与实现。

目前已有一些非常成熟的多控制器技术运用到SDN网络中，构成分布式的控制平面[7]，如HyperFlow[8]、Kandoo[9]等。同时，控制器的软件化让服务器可以作为控制器的载体，因而，多控制器架构可以以服务器集群为基础搭建。

为保证多控制器架构对SDN网络的控制效果，有三个方面的设计与实现非常重要。第一是主控制器的选取[10]。主控制器主要负责生成和维护全网范围内的控制器和交换机状态信息，一旦出现失效，就需要采用一定的选取原则，从域内和域间多个控制器的备用控制器中选取一个成为新的主控制器；第二是多个控制器对交换机的透明化，即在SDN网络的运行过程中，交换机无需关心当前它接受的是哪一台控制器发来的命令，同时在其向控制器发送异步消息时，能保持之前单一控制器的操作方式，从而保证控制器在逻辑上的集中控制；第三是交换机处理底层分组流的转发不受备用控制器的切换影响，交换机在控制器切换过程中能够保证处理任务的一致性，不会因为控制器的切换导致交换机处理分组流转发中断和重复操作。

2 控制器故障处理的设计

SDN控制器作为SDN网络的控制和管理中心，在处理网络的决策和要求中起到了重要作用。控制器的工作状态需要实时监控，当出现控制器故障问题后，需要采用一定的控制器恢复手段进行故障恢复。

2.1 控制器故障监控的研究

结合SDN网络的特点，SDN控制器连接着底层所有SDN交换机。根据OpenFlow协议[11]有关消息类型的说明，对等式的Echo消息可以验证相关设备的活跃性。为此，利用SDN交换机向控制器发送Echo消息来进行SDN控制器的故障监控。控制器故障监控的研究思路如图1所示。

图1 SDN控制器故障监测流程

具体来说，数据平面的SDN交换机向控制器发送Echo-request消息，等待控制器回复相应的Echo-reply消息。一般而言，控制器发生故障后，交换机发送Echo-request消息后是等不到控制器回复的Echo-reply消息的。为了排除偶然性，防止一个交换机因为其他非控制器故障原因导致交换机接收不到Echo-reply消息，控制器故障监控方案要求该控制器所连接的所有交换机均需要采取同样的方法进行监测。当所有的交换机都接收不到控制器应该恢复的Echo-reply消息时，方可断定SDN控制器故障。

2.2 控制器故障恢复策略的研究

出现SDN控制器故障以后，需要尽快进行控制器故障恢复。面向多管理域进行多控制器架构搭建，研究多控制器间的同步问题，设计了多管理域下的控制器故障恢复策略。

2.2.1 多控制器同步

对于分布式的控制平面必然存在多个控制器，多个控制器构成物理上分布的多控制器架构。因此就需要协调这些控制器之间的关系以保证每个控制器对数据平面具有状态同步的一致性，以减少控制器对数据平面控制的重复性[12]，造成安全隐患。

多控制器之间的同步问题主要包括交互信息的同步和事件处理的同步。交互信息同步主要是多个控制器都能获取底层交换机的相关同步报文，每个控制器都具有相同的软硬件配置信息，从控制层面角度考虑，对外具有逻辑上的一致性，但是对用户而言是透明的。事件处理同步主要是针对Master/Slave结构的多控制器，Slave控制器不能处理流表下发等管理决策问题，但是Slave控制器需要获取Master控制器处理流表等事务的结果和反馈。交互信息的同步主要表现如下：

(1)拓扑信息的同步：多控制器节点间必须同步底层网络设备的拓扑结构，以保证多个控制器管理底层网络以及流表生成等的逻辑一致性。当底层网络拓扑结构发生变化时，多个控制器都需要通过LLDP协议获取拓扑结构的变化，以达到对底层拓扑结构的掌控。

(2)设备信息的同步：主要包括底层交换设备信息、主机连通性信息、端口配置信息等。控制面需要获取交换机所连接的控制器信息，当链路中断时，可以快速进行连接重定向。

(3)配置文件信息的同步：对于控制器来说，如流表配置信息；对于交换设备来说，包括端口能力的配置、连接信息配置等。类似于相关日志文件，配置文件信息的同步和备份，可以用于底层设备的故障恢复。

事件处理的同步主要有控制器管理事件，比如网络中控制器失效或主动增加删除控制器个数，这会引起多控制器结构的变化。处理来自交换机的异步消息需要同步更新某些控制器的相关配置信息。还有，控制器可能会向其他控制器主动发送自身的一些响应事件，都需要事件处理的同步性。

多控制器架构的交互信息同步和事件处理同步的一致性，能够保证用户和管理人员通过南北向两个接口访问逻辑上集中控制、物理上分布管理的平面，进行应用部署、流表下发等操作。因此，对于多控制器构成的分布式控制平面，对外表现为一个逻辑上集中控制的逻辑单元，对内表现为多个分布式控制物理单元。在多控制器系统中，访问控制平面是独立的。

2.2.2 多管理域下备用控制器选择策略

基于分布式的控制器平面，采用主备控制器模型故障恢复策略，使用选取备用的SDN控制器最小代价原则，应用于多管理域下的SDN网络。当某域内主控制器发生故障后，选取恰当的备用控制器，将故障控制器下的交换机迁移至该控制器下[13]。在多SDN管理域下的迁移主要有2种情况：

(1)单个管理域内，主控制器故障，存在多个完好的备用控制器，采用域内最小代价原则设定好选择的备用控制器，然后需要将主控制器下的交换机迁移至域内选定的备用控制器。具体来说，在分布式控制平面的单个管理域内，每个备用控制器和主控制器之间都存在迁移代价。如果主控制器故障，同时也有不定数量的备用控制器出现故障以及被其他管理域选择作为备用控制器的SDN控制器。那么此时根据备用控制器选择的最小代价原则，选择代价最小同时备用控制器完好，而且未被其他管理域选择的SDN控制器。如图2所示的分布式控制平面，主控制器M1故障，同时有2个备用控制器C1和C5出现故障，C3控制器被其他管理域选择作为备用控制器。根据上文所述，虽然C1的代价最小，但是C1出现故障，不可选；C3代价次之，但是C3被其他管理域选择作为备用控制器，同样不可选。C2备用控制器完好，而且未被其他管理域选择，因此选择C2作为待交换机迁移的备用控制器。

图2 情况1备用控制器选择示意图

(2)当在一个管理域内，主控制器和备用控制器均故障，而邻近域存在某一个域内的备用控制器没有故障。这时需要将发生故障的主控制器下的所有交换机迁移至该邻近域内的备用控制器。所选择的其他域内的备用控制器仍然按照最小代价原则执行。同时，该控制器完好，且未被其他管理域选择。

如图3所示，管理域1内的主控制器和备用控制器全部故障。相邻管理域2内的备用控制器存在不同的代价。应选择代价最小的控制器作为M1控制器的备用控制器。虽然控制器C4的代价最小，但是C4出现故障，不可选；C5代价次之，但是C5被其他管理域选择作为备用控制器，同样不可选。因此，选择剩余可用控制器中代价最小的C6作为管理域1中故障控制器M1的待迁移控制器。

图3 情况2备用控制器选择示意图

3 控制器故障处理的实现

SDN控制器的故障恢复的主要思路是更换控制器。为了提高网络的可靠性和容错率，在SDN网络的控制平面部署了多控制器架构，采用Master/Slaves体系结构，防止单点故障造成的网络中断。面向多管理域进行控制器的选择，然后将故障控制器下的交换机迁移至已选择的控制器，继续完成交换机分组流转发的任务。

3.1 控制器故障监控的实现

由于Echo消息是对等式的OpenFlow消息，可由所有的SDN交换机都发送Echo-request消息至SDN控制器，SDN控制器接收到来自交换机的Echo-request消息，会执行以下代码：

void processOFEchoRequest(OFEchoRequest m) throws IOException

{

sendEchoReply(m);

}

private void sendEchoReply(OFEchoRequest request)

{

OFEchoReply reply=factory.buildEchoReply().setXid (request.getXid()).setData(request.getData()).build();

channel.write(Collections.singletonList(reply));

}

如果所有的SDN交换机都接收不到控制器回复的Echo-reply消息，判断SDN控制器故障。

3.2 控制器故障恢复策略的实现

面向多管理域的SDN控制器故障恢复策略，首先需要根据备用控制器选择策略进行备用控制器选择，然后采用交换机迁移方式进行控制器故障恢复。

3.2.1 面向多管理域的控制器选择

采用Master/Slaves体系结构部署SDN网络控制平面，适用于多SDN管理域。每个管理域中存在多个备用控制器，分配角色为Slave；唯一一个主控制器，分配角色为Master，直接管理网络。当主控制器故障时，需要从域内和域外选择相应的备用控制器作为迁移控制器。为了实现多个管理域之间相互选择控制器，设定一个代价二维数组Price[m][n]和控制器的二维数组Controller[][]，其中，m为相应的管理域个数，n为相应管理域中备用控制器个数。需要选择的备用控制器的条件是非故障的，且没有被其他管理域或本域选择的控制器，在此条件基础之上选择最小代价值的控制器。认定备用控制器故障或者备用控制器已被其他管理域选择，相应的代价值为0x7fffffff；未与控制器连接的相应的代价值也为0x7fffffff。具体实现的关键代码如下：

public String selectController(int Price[][],String Controller[][],int n)

{

int m=2;

for(int i=0;i

{

for(int j=0;j

{

if(Controller[i][j].isFailure()||Controller[i][j].isSelected())

Price[i][j]=0x7fffffff;

}

}

for(int i=0;i

{

if(Price[0][i]==min(Price[0][n]))

return Controller[0][i];

}

for(int i=0;i

{

if(Price[1][i]==min(Price[1][n]))

return Controller[1][i];

}

}

主控制器能够对网络进行管控，是控制平面正常工作的执行控制平面相应功能的主体。备用控制器在主控制器正常运行的情况下处于假休眠状态。另外，为了实现多管理域下的控制器之间的信息交互，需要在主控制器内新建两个功能模块，分别是活跃监控模块和数据同步模块。

活跃监控模块是主控制器用来与备用控制器保持通信的模块，主要功能是在主备控制器之间周期性地接收和发送心跳报文，在主控制器故障前都可以保证备用控制器处于正常工作状态。不需要交换机获取备用控制器的状态，交换机可以放心地进行迁移。同时，因为主控制器故障导致活跃监控模块不能正常工作，就不能监控备用控制器是否故障，所以文中暂不考虑主备控制器同时故障这种小概率事件。如果主控制器一直能接收到备用控制器的心跳报文，那么就认为备用控制器完好。当主控制器故障后，可以执行2.2.2小节情况1的域内交换机迁移策略；如果活跃监控模块在设定的阈值时间内主控制器还没有收到来自备用控制器的心跳报文，那么就认为备用控制器失效，对于主控制器故障需要执行2.2.2小节情况2的域间交换机迁移策略。

数据同步模块是备用控制器获取主控制器的重要功能模块。在主控制器故障前，备用控制器就会通过该模块周期性地读取主控制器的相关数据信息，如转发平面的拓扑、底层交换机的IP、端口等。这样，当主控制器故障后，备用控制器可以根据主控制器故障前获得的数据信息来保证故障前后的网络状态一致性和多控制器同步。

3.2.2 故障恢复策略实现

选择好相应的备用控制器以后，需要执行SDN控制器的故障恢复策略。恢复策略采用交换机迁移方式。需要把故障的主控制器下的交换机全部迁移至备用控制器下。将OF交换机由主控制器迁移到备用控制器的具体过程如下：

Step1：主控制器通过活跃监控模块与备用控制器进行周期性的信息交互，交互协议可以采用OpenFlow。主控制器发送Echo_request消息到备用控制器，备用控制器接收到Echo_request消息后需要返回给主控制器一个Echo_reply消息，这个请求和回复的过程需要不间断地周期性发送和接收，以确保备用控制器没有故障。当经过一段时间，主控制器仍然没有接收到来自备用控制器的Echo_reply消息，就认为备用控制器失效，这时需要采取一定的策略，如更换备用控制器等。

Step2：在备用控制器未失效的情况下，此时，OF交换机监控发现Master控制器已经故障，于是向备用控制器发出迁移请求M_request；备用控制器接收到OF交换机的连接请求M_request后，并发送M_reply给OF交换机，允许OF交换机和备用控制器进行交换机迁移。备用控制器请求修改自身相对于OF交换机的角色为Equal。备用控制器发送一个Role_request消息到OF交换机，请求将备用控制器的角色由Slave修改为Equal。在OF交换机接收到来自备用控制器的角色修改请求信息Role_request后，OF交换机将备用控制器的角色修改为Equal，同时告知备用控制器角色已经修改完毕，并回复消息Role_reply。

Step3：此时主控制器还是OF交换机的Master角色，为了让OF交换机完全脱离主控制器，OF交换机的流表项中的某一流表指定action为控制器端口，OF交换机会根据这个动作指令以Packet_In消息发送给主备两个控制器。由于主控制器故障，因此主控制器不进行Packet_In消息处理；备用控制器因为处于Equal角色，所以备用控制器开始介入处理OF交换机的事务。

Step4：经过以上步骤，需要将备用控制器由相对于OF交换机的Equal角色转变为Master角色。备用控制器立刻向OF交换机发送Role_request消息，请求角色变为Master控制器，而OF交换机在收到备用控制器的Master角色变换请求后，经过OF交换机内部处理与协调，返回Role-reply消息到备用控制器。此时，OF交换机已经完成了从故障的主控制器迁移到备用控制器并修改备用控制器角色为Master的过程，备用控制器开始执行作为OF交换机的Master控制器角色的相关管控功能。

相应的迁移过程中的报文传递示意图如图4所示。

以上4个步骤很好地完成了交换机从故障控制器迁移至备用控制器。同时，在迁移的前后始终保持有控制器对交换机进行同步报文的处理。出现故障终端时，备用控制器可以获取主控制器在故障点之前的网络状态和事件处理等相关信息，迁移结束之后，备用控制器可以代替主控制器接着原来主控制器没有完成的业务流程继续管理网络，以保证交换机迁移前后不影响网络状态的一致性。

图4 OF交换机迁移消息传递过程示意图

4 实验与测试

实验在两个SDN管理域对SDN控制器进行故障监控和故障恢复。使用Wireshark[14]抓包软件在控制器和交换机之间进行OpenFlow消息抓取，验证控制器故障监控的效果；搭建两个管理域，每个管理域内部署SDN交换机连接多个Floodlight控制器，模拟控制器故障，验证故障恢复策略的执行效果。

4.1 实验拓扑环境的搭建

搭建多管理域SDN网络实验拓扑环境[15]，如图5所示。每个管理域中搭建了3台SDN交换机，每台交换机与一个主控制器和两个备用控制器相连，构成主备控制器模型。其中，C1和C4分别为管理域1和管理域2内的主控制器；C2、C3和C5、C6分别为管理域1和管理域2内的备用控制器。

图5 控制器故障处理测试拓扑图

4.2 故障恢复测试结果分析

搭建好以上实验拓扑，启动SDN交换机和Floodlight控制器。配置SDN交换机连接已运行的两台Floodlight控制器。

以管理域1为例，监控主控制器C1是否故障，通过Wireshark软件抓取3个交换机S1、S2和S3与C1之间的Echo心跳报文来进行测试与验证。如果C1正常工作，那么3个交换机与C1之间的Echo消息都是成对存在的，即有request请求，必定都有reply回应；如果C1控制器故障，那么Wireshark抓取的Echo消息都没有reply回应。由此可以监控主控制器C1故障，并且证明Echo消息可以用于控制器故障的监控。

如果C1正常工作，关闭C1，模拟主控制器C1故障，如果C2和C3均未故障，经过域内控制器故障恢复策略，比较C2和C3的代价，选定C2为待选备用控制器，经过交换机迁移之后，查看C2控制台信息发现原来在管理域1内作为备用控制器的C2在C1控制器关闭之后作为新的主控制器。

关闭C1、C2和C3，模拟管理域1内主控制器和备用控制器全部故障，同时管理域2内的C5和C6备用控制器均正常。经过域间控制器故障恢复策略，比较C5和C6的代价，选定C6为待选备用控制器，经过交换机迁移之后发现C6成为管理域1的主控制器。

通过以上实验可以发现，在多管理域情况下，按照一定的控制器选择策略，选定恰当的备用控制器后，经过交换机迁移，备用控制器确实可以在主控制器故障之后成为新的主控制器来接管网络。

5 结束语

为解决多管理域下SDN网络中控制器发生单点故障的问题，就目前复杂多变的网络环境，提出了跨管理域的故障监控和恢复的解决方案。分析了控制器故障对SDN网络的重大影响和必要性，给出了故障恢复解决方案的应用场景。设计了SDN控制器故障的监测方法，然后基于故障监测的结果设计了多管理域下的SDN控制器故障恢复策略，通过备用控制器的选择和交换机迁移的手段实现了SDN控制器的故障恢复。最后通过实验测试了控制器故障恢复策略的正确性，证明该方案是可行的，具有较高的实用价值。

[1] 沈苏彬.软件定义联网的建模与分析[J].南京邮电大学学报：自然科学版，2014，34(3)：1-9.

[2] 黄 韬，刘 江.软件定义网络核心原理与应用实践[M].北京：人民邮电出版社，2014.

[3] MCKEOWN N， ANDERSON T，BALAKRISHNAN H，et al.OpenFlow：enabling innovation in campus networks[J].ACM SIGCOMM Computer Communication Review，2008，38(2)：69-74.

[4] BRAUN W,MENTH M. Software-defined networking using OpenFlow:protocols,applications and architectural design choices[J].Future Internet,2014,6(2):302-336.

[5] WANG Feng,WANG Heyu,LEI Baohua,et al.A research on carrier-grade SDN controller[C]//International conference on cloud computing and big data.[s.l.]:IEEE,2014:168-174.

[6] 林萍萍，毕 军，胡虹雨，等.一种面向SDN域内控制平面可扩展性的机制[J].小型微型计算机系统，2013，34(9)：1969-1974.

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

[8] 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.

[9] YEGANEHS H, GANJALI Y. Kandoo:a framework for efficient and scalable offloading of control application[C]//Workshop on hot topics in software defined networks.[s.l.]:ACM,2012:19-24.

[10] 姚 龙.软件定义网络控制器容量及部署问题研究[D].合肥：中国科学技术大学，2015.

[11] Open Network Fundation.Software-defined networking:the new norm for networks[EB/OL].(2012-04-13)[2016-02-08].https://www.opennetworking.org.

[12] 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.

[13] CHAN Y C, WANG Kuochen, HSU Y H. Fast controller failover for multi-domain software-defined networks[C]//European conference on networks and communications.[s.l.]:IEEE,2014:370-374.

[14] OREBAUGH A,RAMIREZ G,BURKE J,et al.Wireshark & ethereal network protocol analyzer toolkit[J].Jay Beales Open Source Security,2007,12(2):523-540.

[15] LANTZ B,O'CONNOR B.A mininet-based virtual testbed for distributed SDN development[J].ACM SIGCOMM Computer Communication Review,2015,45(5):365-366.

ASolutionforControllerFailureTreatmentofSDNinMultiple-managementDomains

BIAN Yu-xiang1，SHEN Su-bin1，WU Zhen-yu2

(1.School of Computer，Nanjing University of Posts and Telecommunications，Nanjing 210003，China；2.School of IoT，Nanjing University of Posts and Telecommunications，Nanjing 210003，China)

With the constant development of Software-Defined Networking (SDN),the demands and services on SDN network will be more rised.As the whole network control and management center,SDN controller has lots of business pressure which can easily suffer from paralysis and failure,service interruptions and other disadvantages.At the same time,the limitations of a single management domains are also increased.In order to solve the serious consequences of SDN controller paralysis and failure and overcome the limitations of a single management domain,a feasible solution for controller failure recovery based on the monitoring results of SDN controller failure in the multi-management domains scenario is proposed.Specifically,the method of SDN controller failure monitoring based on OpenFlow messages is proposed,the issues of multi-controller deployment in control plane are studied,and the synchronization mechanism of multiple controllers are discussed.The master and slave controllers model is built to implement switch migration,and different failure recovery strategies are adopted according to the different application scenarios within and between different domains.The minimum cost principle of the switch migration is used to select the standby controller to achieve controller failure recovery.The experiment indicates that the use of different recovery strategies for the failure controller can realize the failure recovery of SDN controller in the multi-management domains scenario.

SDN controller;failure monitoring;failure recovery;multiple-management domains

TP393

A

1673-629X(2017)12-0108-07

10.3969/j.issn.1673-629X.2017.12.024

2017-01-21

2017-05-25 < class="emphasis_bold">网络出版时间

时间：2017-09-27

国家自然科学基金资助项目(61502246)；江苏省科技厅(未来网络前瞻性研究项目)

卞宇翔(1990-)，男，硕士研究生，研究方向为计算机网络；沈苏彬，博士生导师，教授，CCF高级会员(E200005482S)，研究方向为计算网络、下一代电信网及网络安全；吴振宇，博士，讲师，CCF会员(200061869M)，研究方向为数据挖掘和人工智能。

http://kns.cnki.net/kcms/detail/61.1450.TP.20170927.1000.078.html