基于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