基于REST-API的SDN控制器故障恢复机制

杨 晨，李 勇，金德鹏

（清华大学电子工程系微波与数字通信国家重点实验室，北京100084）

基于REST-API的SDN控制器故障恢复机制

杨 晨，李 勇，金德鹏

（清华大学电子工程系微波与数字通信国家重点实验室，北京100084）

软件定义网络（SDN）通过可编程的数据平面和逻辑集中的网络控制器实现网络的灵活可控，然而现有的网络控制器不具备故障快速切换功能，难以实现SDN网络故障恢复。为此，基于表述性状态转移-应用程序编程接口（REST-API），提出一种控制器快速恢复机制，通过REST-API将多个控制器同时与控制器代理相连接，使得控制器代理可快速检测出控制器故障并进行切换。实验结果表明，与OpenFlow机制相比，该机制减少了500倍以上的切换时间，且切换时间不受网络规模的影响。

软件定义网络；故障恢复；快速切换；OpenFlow机制；表述性状态转移-应用程序编程接口

1 概述

随着计算机网络规模的不断扩大，互联网已经从早期的局部资源共享平台发展到今天覆盖全球的数据传输通信网络，这使得互联网在社会基础设施中越来越重要，但其缺陷也越发明显，例如结构和功能日趋复杂、管控能力日趋减弱等，解决这些问题的关键是亟需网络架构方面的创新［1］。

OpenFlow技术概念最早由美国斯坦福大学的Nick McKeown教授提出，是斯坦福大学Clean Slate计划资助的一个开放式协议标准，其后成为GENI计划的子项目［2］。OpenFlow将控制功能从网络设备中分离出来，在网络设备上维护流表（flow table）结构，数据分组按照流表进行转发，而流表的生成、维护、配置则由中央控制器进行管理。OpenFlow的流表结构将网络处理层次扁平化，使得网络数据的处理满足精细处理要求。在这种分离架构下，网络逻辑控制功能和上层应用可以通过中央控制器灵活地进行动态管理和配置，同时在不影响传统网络正常流量的情况下，在现有网络中构建新型网络［3］。

软件定义网络（Software Defined Network，SDN）概念引起了学术界和产业界的广泛关注，SDN通过把原有的封闭体系解耦为数据层、控制层和应用层，将网络控制功能独立出来，并为网络应用提供可编程的接口，从而颠覆传统网络架构。它是一种网络实现技术，与IPV 6，IPv4不同，SDN不改变主机可见的转发面封装，它是现有网络协议/架构和未来网络的一种支持平台，某种意义上说更像一种高级语言+编译器，可以用来实现应用软件，而不是另外一种新的功能性软件［4］。对于采用SDN架构的网络，可方便地提高网络设备利用率、降低网络维护代价、优化路由路径及增加网络设备的管理性和灵活性［5］。SDN的发展面临很多安全问题，随着SDN架构的普及和推广，安全问题越来越受到重视［6］。本文主要从应用控制器入手，提出一种在不间断通信的情况下实施控制器切换的方法，当应用控制器发生故障时可实现快速有效的控制器切换。

2 SDN与OPenFlow技术

目前学术界和工业界所讨论的SDN网络一般分为广义和狭义2种［7］。其中，广义SDN一般指向上层应用开放资源接口，能够实现软件编程控制的各种基础网络架构；狭义上的SDN专指符合开放网络基金会（ONF）定义的开放架构，在控制器控制下基于标准OpenFlow协议进行转发的网络架构。无论广义还是狭义其基本设计思想是一致的［8］。

SDN是一种全新的网络架构［9］，其独立控制器可直接编程并与网络层相分离，把传统的网络架构分为应用、控制、数据3个层面，通过标准化接口实现网络的独立控制与编程，如图1所示。

图1 SDN分层架构

在SDN分层架构下的核心和关键是开放式和标准化，其统一标准的数据层与控制层接口屏蔽了网络基础设施在类型、支持协议等方面的异构性，使得数据层的交换网络能够无障碍地接收控制层指令，快速转发网络中的数据业务。标准化控制层和应用层的接口，为上层应用提供统一的管理视图和编程接口，使得用户可以很方便地实现软件定义网络控制和网络服务。

OpenFlow是目前SDN最成熟和应用最广的实现方式。基于OpenFlow的SDN技术使用户可以更灵活地管控网络、更高效地利用网络资源、更合理性地分配网络资源［10］。OpenFlow由OpenFlow交换机、Flow Visor和Controller三部分组成［11］。OpenFlow技术最大的特点是OpenFlow交换机将原来完全由交换机和路由器控制的报文转发过程转化为由OpenFlow交换机和Controller来共同完成，实现了数据转发和路由控制的分离。其中，OpenFlow交换机进行数据层转发；Flow Visor对网络进行虚拟化；Controller对网络进行集中控制。Controller可以通过事先规定好的接口操作控制OpenFlow交换机中的流表，从而达到控制数据转发的目的。

3 设计目标

本文设计的总体目标是在不影响网络业务正常运行的条件下支持多控制器的灵活切换，具体目标如下：

（1）支持多种不同的控制器实现形式。SDN网络中有多种形式的控制器，基于不同架构和设计目标，比如Flood light，OpenDay light，Nox等，本文设计需要能够在多种不同的控制器之间进行切换，并且能够兼容多种控制器的应用和下发规则。

（2）能够快速响应控制器故障。传统的控制器故障事件不会反馈到交换机上，控制器失效后，交换机难以快速响应控制器的故障及失效事件。

（3）控制器切换过程不影响现有业务的运行。网络业务在切换过程中不产生明显的中断，多个控制器的状态需要保持一致。

4 SDN控制器故障恢复机制

4.1 控制器故障恢复系统结构

本文控制器故障恢复系统结构分为3个部分，如图2所示，网络底层是OpenFlow交换机，交换机通过物理链路与控制器代理互连，控制器代理通过标准化接口与多种控制器互连。交换机开始运行后，首先通过OpenFlow协议与控制器代理连接；控制器代理通过REST-API与多个控制器同时保持连接，系统随机选择一个控制器作为主要控制器。所有的控制器会运行相同的应用，主要控制器会将规则下发到控制器代理，控制代理再下发到各个交换机上。

图2 本文控制器故障恢复系统结构

4.2 控制器代理功能实现

控制器代理主要完成控制器选择、控制器规则下发、网络事件上传等功能。

控制器代理功能主要分为设备控制和控制器接口两部分，设备控制部分负责与网络底层的交换机进行通信，如图3所示。

图3 控制器代理模块结构

设备控制部分主要功能包括：（1）交换机连接模块通过OpenFlow协议与底层的交换机相连；（2）设备管理模块通过OpenFlow协议管理每个交换机的运行状态；（3）链路发现模块监测交换机之间链路的状态，实时更新链路信息；（4）统计信息模块将OpenFlow协议收集到的交换机信息存储在数据库中；（5）流表缓存模块将需要下发的流表存储在本地数据库中，作为交换机硬件流表的备份；（6）拓扑管理基于已有的链路信息建立交换机的拓扑。基于以上模块，设备控制部分维护了底层交换机网络的拓扑、流表、运行状态等信息。控制器接口部分主要功能包括：（1）状态检测模块监测控制器的运行状态，能够及时发现控制器的故障状态；（2）控制器连接模块通过表述性状态转移-应用程序编程接口（Representational State Transfer-Application Programming Interface，REST-API）与多个控制器进行连接，由于REST-API无需长时间保持连接的特性，因此多个控制器可以分时地访问控制器代理，使得多个控制器能够同时获取底层交换机的状态；（3）消息转换模块将控制器的REST-API访问转换为OpenFlow协议，使得控制器可以透明地控制底层的交换机设备。

4.3 REST-API功能实现

控制器和控制器代理通过REST-API实现通信。为实现本文3个设计目标，设计了4类RESTAPI，分别面向交换机设备控制、信息统计、事件反馈以及控制器状态查询，如表1所示。

表1 REST-API类型及其功能

交换机设备控制实现了加入、修改和删除流表的操作，允许控制器通过代理直接对交换机流表进行控制；交换机信息统计实现了交换机端口和链路状态查询，使得控制器能够透明地获取网络的运行状态；交换机事件反馈将交换机需要上传的数据包和事件上传到各个控制器中，使得各个控制器能够同步获得交换机事件并根据事件更新控制器应用运行状态；控制器状态查询功能使得控制代理能够实时监测控制器的运行状态，如果某控制器发生故障，则将控制器进行切换。

4.4 控制器故障切换

对于控制器来说，通过网络操作系统（Netw ork Operating System，NOS）实现其控制逻辑功能。NOS是［12］OpenFlow网络中实现网络可编程控制的中央执行单元，在SDN网络中具有重要作用。本文设计的控制器切换故障流程如图4所示。

图4 控制器故障切换流程

控制器故障切换流程具体步骤如下：（1）启动网络中的交换机；（2）启动后的交换机通过OpenFlow协议连接到控制代理上；（3）控制代理从连接到其上的诸多控制器中选择一个进行连接，作为主控制器；（4）通过代理将网络中的交换机事件上报到所有控制器；（5）控制器基于上报的事件保持状态同步；（6）控制代理不断检测控制器的连接事件，如果发现控制器发生故障，则进行控制器切换，选择任意可用的控制器作为主控制器对网络继续进行控制；如果主控制器未发生故障，则控制器代理将按照主控制器生成的流表、运行状态等指令对网络中的交换机进行实时状态更新。

5 性能分析和验证

5.1 故障检测时间

故障检测时间是指从故障发生到控制器代理检测到故障的时间。在本文设计方案中，控制器代理通过实时查询控制器状态来检测故障。假设查询时间间隔为T，且控制器发生故障的时间是完全随机的，则理论上的平均故障检测时间为T/2。对于链路故障，控制器无法响应代理的查询请求，因此需要控制器代理设置超时时间来进行检测。假设超实时间设置为T0，则检测到链路故障所需的时间为max｛T/2，T0｝，一般设置应该满足T0＜T/2。综上所述，不论是哪种故障，平均故障检测时间均为T/2。基于上述理论值和不同的应用场景需求，可以灵活调整查询时间间隔。例如，当控制器发生故障的概率较低时，可以设置较大的查询时间间隔；当控制器发生故障的概率较高时，则需要缩短查询时间间隔。统计在不同查询时间间隔下的故障检测时间，100次实验的平均结果如表2所示，可以看出，实际统计得到的平均故障检测时间和理论值T/2是一致的。

表2 故障检测时间s

5.2 切换时间

切换时间是指从发现故障到完成切换的时间。在本文设计的方案中，当控制器代理发现主控制器发生故障时，只需从其他任意可用的控制器中选择一个作为主控制器继续处理，因此该时间与网络规模无关。而对于传统控制器故障恢复系统结构，如图5所示，在检测到控制器故障时需要与备用控制器重新建立连接，并且进行状态同步，一般而言状态同步与网络规模是成正比的，因此，在传统机制下切换时间受网络规模影响。

图5 传统控制器故障恢复系统结构

为验证上述结论，统计在不同网络规模下2种机制的切换时间。实验所用控制器配置为：4 GB内存，Core 2核CPU处理器。采用树状拓扑，树的深度为3，分支数分别设置为2，4，6，对应交换机数量为6，21，43。实验拓扑用M ininet仿真拓扑环境生成，假设有3个控制器，5次实验的平均结果如表3所示，本文机制是统计从一个数组中随机选择一个控制器的所用时间，传统机制是统计从启动控制器到所有交换机连接到控制器的时间。

表3 2种机制切换时间对比s

可以看出，采用本文机制的切换时间远小于传统机制。当交换机数量为6，21，43时，传统机制切换时间分别是本文机制的575倍、2 670倍、9 600倍。这主要是因为本文机制中的控制器状态在切换前就已同步，在切换时不需要进行同步。这种设计虽然增加了控制信令数量，但是由于控制信令本身所需带宽较小，且不同控制器可以分时共享控制链路，因此不会带来额外的开销。

6 结束语

针对SDN网络难以快速切换的问题，本文提出一种SDN控制器结构，使得多个逻辑完全相同的控制器并行运行，由控制器代理从可用的控制器中选择一个作为主控制器。当主控制器发生故障时，控制器代理将自动选择其他的可用控制器。实验结果表明，与传统恢复机制相比，本文机制可大幅降低切换时间。为增强SDN网络的抗毁能力和快速恢复能力，需要分布式网络控制架构的支持，因此，今后将进一步研究SDN网络的分布式控制器故障恢复机制。

［1］ 左青云，陈 鸣，赵广松，等.基于OpenFlow的SDN技术研究［J］.软件学报，2013，24（5）：1078-1097.

［2］ Clean Slate［EB/OL］.（2012-07-18）.http：//cleanslate. stanford.edu/.

［3］ 王淑玲，李济汉，张云勇，等.SDN架构及安全性研究［J］.电信科学，2013，（3）：117-122.

［4］ OpenFlow/SDN本质论［EB/OL］.（2013-05-11）.http：// blog.sina.com.cn/s/blog_5385c0b901010pu3.htm l.

［5］ 袁广翔.软件定义网络技术发展与应用研究［J］.现代电信科技，2013，（4）：45-50.

［6］ OpenFlow.VOpenFlow Configuration and Management Protocol OF-CONFIG 1.0［EB/OL］.（2012-11-08）. https：//www.opennetworking.org/.

［7］ 刘 璐.对SDN技术的研究与思考［J］.互联网天地，2013，（3）：1-3.

［8］ 李纪周，何 恩.软件定义网络技术及发展趋势综述［J］.通信技术，2014，47（2）：123-127.

［9］ OpenFlow Switch Specification 1.3.1［EB/OL］.［2014-10-05］. https：//www.opennetworking.org/images/stories/dow nloads/specification/openflow-spec-v1.3.1.pdf.

［10］ 林 闯，贾子晓，孟 坤.自适应的未来网络体系架构［J］.计算机学报，2012，35（6）：1077-1092.

［11］ Mckcown N，Andcrson T，Balakrishnan H，et al.OpenFlow：Enabling Innovation in Campus Networks［J］.ACM SIGCOMM Communication Rcnicw，2008，38（2）：69-74.

［12］ NOX［EB/OL］.（2012-11-23）.http：//noxrepo.org.

编辑 陆燕菲

Failure Recovery Mechanism of SDN Controller Based on REST-API

YANG Chen，LIYong，JIN Depeng
（State Key Laboratory of Microware and Digital Communication，Department of Electronic Engineering，Tsinghua University，Beijing 100084，China）

Software Defined Network（SDN）is able to support flexible network programmability by using programmable data p lane and centralized network controller.However，the single network controller is hard to support fast handover of controllers，which leads to the difficulty of failure recovery for SDN network.This paper proposes a failure recovery mechanism of SDN controller based on Representational State Transfer-Application Programming Interface（REST-API）.It uses the controller proxy to connect the underlying devices，and makes the proxy simultaneously connect several with controllers by using REST-API.The proxy can detect the failures and sw itch among controllers in short time.Experimental result show s that the proposed mechanism reduces more than 500 handover times，and the handover time is not affected by network scale.

Software Defined Network（SDN）；failure recovery；fast handover；OpenFlow mechanism；Representational State Transfer-Application Programming Interface（REST-API）

杨 晨，李 勇，金德鹏.基于REST-API的SDN控制器故障恢复机制［J］.计算机工程，2015，41（9）：131-134，139.

英文引用格式：Yang Chen，Li Yong，Jin Depeng.Failure Recovery Mechanism of SDN Controller Based on RESTAPI［J］.Computer Engineering，2015，41（9）：131-134，139.

1000-3428（2015）09-0131-04

A

TP393.1

10.3969/j.issn.1000-3428.2015.09.023

国家“973”计划基金资助项目（2013CB329105）。

杨 晨（1986-），男，硕士研究生，主研方向：软件定义网络，通信工程；李 勇，助理教授、博士；金德鹏，教授、博士。

2014-09-15

2014-10-21 E-m ail：yc31801986@qq.com