一種面向多管理域SDN控制器故障處理方案

卞宇翔，沈蘇彬，吳振宇

(1.南京郵電大學(xué) 計(jì)算機(jī)學(xué)院，江蘇 南京 210003；2.南京郵電大學(xué) 物聯(lián)網(wǎng)學(xué)院，江蘇 南京 210003)

一種面向多管理域SDN控制器故障處理方案

卞宇翔1，沈蘇彬1，吳振宇2

(1.南京郵電大學(xué) 計(jì)算機(jī)學(xué)院，江蘇 南京 210003；2.南京郵電大學(xué) 物聯(lián)網(wǎng)學(xué)院，江蘇 南京 210003)

隨著軟件定義聯(lián)網(wǎng)(Software Defined Networking，SDN)的不斷發(fā)展，SDN網(wǎng)絡(luò)的需求和服務(wù)不斷擴(kuò)大。SDN控制器作為全網(wǎng)的控制和管理中心，承受著巨大的業(yè)務(wù)需求壓力，極易造成SDN控制器的癱瘓和故障，出現(xiàn)服務(wù)中斷等不利影響。同時(shí)，單個(gè)管理域所呈現(xiàn)的局限性也越來越大。為了解決SDN控制器癱瘓和故障造成的嚴(yán)重后果，克服單個(gè)管理域的局限性，在多管理域場景下，根據(jù)監(jiān)測到的SDN控制器故障結(jié)果提出具體可行的控制器故障恢復(fù)的解決方案。為此，提出了基于OpenFlow消息進(jìn)行SDN控制器故障監(jiān)測的方法，研究了控制平面的多控制器部署問題，討論了多控制器的同步機(jī)制，搭建主備控制器模型用于實(shí)現(xiàn)交換機(jī)遷移，根據(jù)域內(nèi)和域間不同的應(yīng)用場景，采用了不同的故障恢復(fù)策略。采用交換機(jī)遷移的最小代價(jià)原則選取備用控制器，實(shí)現(xiàn)故障恢復(fù)。測試結(jié)果表明，多管理域場景下對故障控制器執(zhí)行不同的故障恢復(fù)策略可以實(shí)現(xiàn)對SDN控制器的故障恢復(fù)。

SDN控制器；故障監(jiān)控；故障恢復(fù)；多管理域

0 引 言

隨著ICT技術(shù)的不斷發(fā)展，網(wǎng)絡(luò)規(guī)模呈幾何級擴(kuò)大，人們對通信業(yè)務(wù)的需求量也在增大。傳統(tǒng)網(wǎng)絡(luò)設(shè)備的控制邏輯和數(shù)據(jù)轉(zhuǎn)發(fā)功能緊密耦合，例如交換機(jī)和路由器。這些傳統(tǒng)網(wǎng)絡(luò)設(shè)備在解決通信需求中表現(xiàn)得越來越吃力，負(fù)載不斷變大，執(zhí)行效率也在降低。為了解決這一技術(shù)難題，軟件定義聯(lián)網(wǎng)[1](Software Defined Networking，SDN)引起了人們的注意。SDN是一種新型的可編程網(wǎng)絡(luò)架構(gòu)，它把控制模塊從傳統(tǒng)網(wǎng)絡(luò)轉(zhuǎn)發(fā)設(shè)備中分離開，部署于一個(gè)綜合控制邏輯單元—控制器[2]，用戶可以通過開放的可編程接口靈活地指導(dǎo)網(wǎng)絡(luò)設(shè)備的數(shù)據(jù)轉(zhuǎn)發(fā)，而網(wǎng)絡(luò)設(shè)備只具有簡單的數(shù)據(jù)轉(zhuǎn)發(fā)功能。這種創(chuàng)新性的結(jié)構(gòu)實(shí)現(xiàn)了對網(wǎng)絡(luò)的全局集中控制，降低了網(wǎng)絡(luò)管理的復(fù)雜度，提高了對通信業(yè)務(wù)處理的效率。因此，SDN網(wǎng)絡(luò)架構(gòu)的出現(xiàn)對未來網(wǎng)絡(luò)的發(fā)展起著至關(guān)重要的作用。

然而，雖然SDN是一種新型網(wǎng)絡(luò)架構(gòu)，但是仍然避免不了傳統(tǒng)網(wǎng)絡(luò)中出現(xiàn)的各種各樣的網(wǎng)絡(luò)故障問題，如分組流轉(zhuǎn)發(fā)設(shè)備故障、端口故障、網(wǎng)絡(luò)電纜斷裂等等。其中，控制面的故障問題尤為復(fù)雜。控制器作為SDN網(wǎng)絡(luò)的“大腦”，如果控制器出現(xiàn)故障，整個(gè)網(wǎng)絡(luò)必將癱瘓，會造成嚴(yán)重的網(wǎng)絡(luò)危機(jī)。因此，控制器故障問題后果最為嚴(yán)重，是最需要解決的問題，同時(shí)也是SDN網(wǎng)絡(luò)最大的限制瓶頸[3]。

伴隨著網(wǎng)絡(luò)規(guī)模的擴(kuò)大，單一的管理域服務(wù)已不再能滿足相應(yīng)需求，隨之而來的是多管理域的實(shí)現(xiàn)和部署。為了隨時(shí)應(yīng)對跨管理域的多控制器故障，提供可靠的服務(wù)質(zhì)量，文中提出了域內(nèi)和域間SDN控制器故障監(jiān)控和恢復(fù)策略。基于控制器故障監(jiān)控獲得的結(jié)果，針對不同條件下域內(nèi)和域間的情況，采用最小代價(jià)原則選取備用控制器，通過實(shí)現(xiàn)交換機(jī)遷移，將已故障的控制器所執(zhí)行的功能要求全部交付給備用控制器處理。同時(shí)能夠保證交換機(jī)遷移前后網(wǎng)絡(luò)狀態(tài)的一致性，不再出現(xiàn)備用控制器重復(fù)處理已故障控制器在故障前所處理的需求或者備用控制器遺漏已故障控制器故障后所需要處理的業(yè)務(wù)需求。這樣能夠?qū)崿F(xiàn)控制器的無縫對接，不影響用戶需求，甚至不讓用戶察覺，保證較高的用戶體驗(yàn)。

為了更好地說明控制器故障的監(jiān)控和恢復(fù)原理，文中承認(rèn)以下3個(gè)事實(shí)和條件：

(1)就控制平面的故障問題進(jìn)行監(jiān)測和恢復(fù)策略的研究，需要保證數(shù)據(jù)平面能夠正常工作；

(2)在交換機(jī)與控制器之間以及不同控制器之間，只存在帶內(nèi)連接[4]。也就是說，控制器下發(fā)的控制流量只使用網(wǎng)絡(luò)中已有的數(shù)據(jù)通道進(jìn)行傳送；

(3)控制平面和轉(zhuǎn)發(fā)平面之間的接口協(xié)議需要OpenFlow v1.3及其以上版本的支持。

1 相關(guān)技術(shù)分析

由于SDN控制器是SDN網(wǎng)絡(luò)控制和轉(zhuǎn)發(fā)中心，同時(shí)控制器各個(gè)內(nèi)部單元模塊[5]緊密聯(lián)系，相互依靠，不可分割。因此，控制器出現(xiàn)故障，進(jìn)行故障檢測難度過大，時(shí)間過長，恢復(fù)效果較差。為此，通常采用更換備用控制器的方式進(jìn)行SDN控制器的故障恢復(fù)。當(dāng)監(jiān)測到控制器故障后，更換控制器可以較快地實(shí)現(xiàn)控制器重新工作，且不影響原先的業(yè)務(wù)處理。

但是，與單個(gè)管理域簡單更換控制器相比，多個(gè)管理域間協(xié)同處理網(wǎng)絡(luò)數(shù)據(jù)流更符合未來網(wǎng)絡(luò)發(fā)展的需求。為此，文中立足多管理域?qū)崿F(xiàn)控制器的故障恢復(fù)。

因?yàn)閱我坏目刂破鳠o法應(yīng)對跨多個(gè)管理域的SDN網(wǎng)絡(luò)問題，需要多個(gè)SDN控制器組成分布式的控制架構(gòu)[6]。對外表現(xiàn)出集中控制，這樣可以避免單一的控制器節(jié)點(diǎn)在可靠性、擴(kuò)展性和性能方面的問題。多控制器架構(gòu)主要是用于解決控制器負(fù)載不均衡的問題而設(shè)計(jì)實(shí)現(xiàn)的。但是，結(jié)合多控制器架構(gòu)特點(diǎn)，將多控制器架構(gòu)應(yīng)用到控制器故障恢復(fù)這一場景中，同時(shí)實(shí)現(xiàn)了跨管理域的部署與實(shí)現(xiàn)。

目前已有一些非常成熟的多控制器技術(shù)運(yùn)用到SDN網(wǎng)絡(luò)中，構(gòu)成分布式的控制平面[7]，如HyperFlow[8]、Kandoo[9]等。同時(shí)，控制器的軟件化讓服務(wù)器可以作為控制器的載體，因而，多控制器架構(gòu)可以以服務(wù)器集群為基礎(chǔ)搭建。

為保證多控制器架構(gòu)對SDN網(wǎng)絡(luò)的控制效果，有三個(gè)方面的設(shè)計(jì)與實(shí)現(xiàn)非常重要。第一是主控制器的選取[10]。主控制器主要負(fù)責(zé)生成和維護(hù)全網(wǎng)范圍內(nèi)的控制器和交換機(jī)狀態(tài)信息，一旦出現(xiàn)失效，就需要采用一定的選取原則，從域內(nèi)和域間多個(gè)控制器的備用控制器中選取一個(gè)成為新的主控制器；第二是多個(gè)控制器對交換機(jī)的透明化，即在SDN網(wǎng)絡(luò)的運(yùn)行過程中，交換機(jī)無需關(guān)心當(dāng)前它接受的是哪一臺控制器發(fā)來的命令，同時(shí)在其向控制器發(fā)送異步消息時(shí)，能保持之前單一控制器的操作方式，從而保證控制器在邏輯上的集中控制；第三是交換機(jī)處理底層分組流的轉(zhuǎn)發(fā)不受備用控制器的切換影響，交換機(jī)在控制器切換過程中能夠保證處理任務(wù)的一致性，不會因?yàn)榭刂破鞯那袚Q導(dǎo)致交換機(jī)處理分組流轉(zhuǎn)發(fā)中斷和重復(fù)操作。

2 控制器故障處理的設(shè)計(jì)

SDN控制器作為SDN網(wǎng)絡(luò)的控制和管理中心，在處理網(wǎng)絡(luò)的決策和要求中起到了重要作用。控制器的工作狀態(tài)需要實(shí)時(shí)監(jiān)控，當(dāng)出現(xiàn)控制器故障問題后，需要采用一定的控制器恢復(fù)手段進(jìn)行故障恢復(fù)。

2.1 控制器故障監(jiān)控的研究

結(jié)合SDN網(wǎng)絡(luò)的特點(diǎn)，SDN控制器連接著底層所有SDN交換機(jī)。根據(jù)OpenFlow協(xié)議[11]有關(guān)消息類型的說明，對等式的Echo消息可以驗(yàn)證相關(guān)設(shè)備的活躍性。為此，利用SDN交換機(jī)向控制器發(fā)送Echo消息來進(jìn)行SDN控制器的故障監(jiān)控。控制器故障監(jiān)控的研究思路如圖1所示。

圖1 SDN控制器故障監(jiān)測流程

具體來說，數(shù)據(jù)平面的SDN交換機(jī)向控制器發(fā)送Echo-request消息，等待控制器回復(fù)相應(yīng)的Echo-reply消息。一般而言，控制器發(fā)生故障后，交換機(jī)發(fā)送Echo-request消息后是等不到控制器回復(fù)的Echo-reply消息的。為了排除偶然性，防止一個(gè)交換機(jī)因?yàn)槠渌强刂破鞴收显驅(qū)е陆粨Q機(jī)接收不到Echo-reply消息，控制器故障監(jiān)控方案要求該控制器所連接的所有交換機(jī)均需要采取同樣的方法進(jìn)行監(jiān)測。當(dāng)所有的交換機(jī)都接收不到控制器應(yīng)該恢復(fù)的Echo-reply消息時(shí)，方可斷定SDN控制器故障。

2.2 控制器故障恢復(fù)策略的研究

出現(xiàn)SDN控制器故障以后，需要盡快進(jìn)行控制器故障恢復(fù)。面向多管理域進(jìn)行多控制器架構(gòu)搭建，研究多控制器間的同步問題，設(shè)計(jì)了多管理域下的控制器故障恢復(fù)策略。

2.2.1 多控制器同步

對于分布式的控制平面必然存在多個(gè)控制器，多個(gè)控制器構(gòu)成物理上分布的多控制器架構(gòu)。因此就需要協(xié)調(diào)這些控制器之間的關(guān)系以保證每個(gè)控制器對數(shù)據(jù)平面具有狀態(tài)同步的一致性，以減少控制器對數(shù)據(jù)平面控制的重復(fù)性[12]，造成安全隱患。

多控制器之間的同步問題主要包括交互信息的同步和事件處理的同步。交互信息同步主要是多個(gè)控制器都能獲取底層交換機(jī)的相關(guān)同步報(bào)文，每個(gè)控制器都具有相同的軟硬件配置信息，從控制層面角度考慮，對外具有邏輯上的一致性，但是對用戶而言是透明的。事件處理同步主要是針對Master/Slave結(jié)構(gòu)的多控制器，Slave控制器不能處理流表下發(fā)等管理決策問題，但是Slave控制器需要獲取Master控制器處理流表等事務(wù)的結(jié)果和反饋。交互信息的同步主要表現(xiàn)如下：

(1)拓?fù)湫畔⒌耐剑憾嗫刂破鞴?jié)點(diǎn)間必須同步底層網(wǎng)絡(luò)設(shè)備的拓?fù)浣Y(jié)構(gòu)，以保證多個(gè)控制器管理底層網(wǎng)絡(luò)以及流表生成等的邏輯一致性。當(dāng)?shù)讓泳W(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)發(fā)生變化時(shí)，多個(gè)控制器都需要通過LLDP協(xié)議獲取拓?fù)浣Y(jié)構(gòu)的變化，以達(dá)到對底層拓?fù)浣Y(jié)構(gòu)的掌控。

(2)設(shè)備信息的同步：主要包括底層交換設(shè)備信息、主機(jī)連通性信息、端口配置信息等。控制面需要獲取交換機(jī)所連接的控制器信息，當(dāng)鏈路中斷時(shí)，可以快速進(jìn)行連接重定向。

(3)配置文件信息的同步：對于控制器來說，如流表配置信息；對于交換設(shè)備來說，包括端口能力的配置、連接信息配置等。類似于相關(guān)日志文件，配置文件信息的同步和備份，可以用于底層設(shè)備的故障恢復(fù)。

事件處理的同步主要有控制器管理事件，比如網(wǎng)絡(luò)中控制器失效或主動增加刪除控制器個(gè)數(shù)，這會引起多控制器結(jié)構(gòu)的變化。處理來自交換機(jī)的異步消息需要同步更新某些控制器的相關(guān)配置信息。還有，控制器可能會向其他控制器主動發(fā)送自身的一些響應(yīng)事件，都需要事件處理的同步性。

多控制器架構(gòu)的交互信息同步和事件處理同步的一致性，能夠保證用戶和管理人員通過南北向兩個(gè)接口訪問邏輯上集中控制、物理上分布管理的平面，進(jìn)行應(yīng)用部署、流表下發(fā)等操作。因此，對于多控制器構(gòu)成的分布式控制平面，對外表現(xiàn)為一個(gè)邏輯上集中控制的邏輯單元，對內(nèi)表現(xiàn)為多個(gè)分布式控制物理單元。在多控制器系統(tǒng)中，訪問控制平面是獨(dú)立的。

2.2.2 多管理域下備用控制器選擇策略

基于分布式的控制器平面，采用主備控制器模型故障恢復(fù)策略，使用選取備用的SDN控制器最小代價(jià)原則，應(yīng)用于多管理域下的SDN網(wǎng)絡(luò)。當(dāng)某域內(nèi)主控制器發(fā)生故障后，選取恰當(dāng)?shù)膫溆每刂破鳎瑢⒐收峡刂破飨碌慕粨Q機(jī)遷移至該控制器下[13]。在多SDN管理域下的遷移主要有2種情況：

(1)單個(gè)管理域內(nèi)，主控制器故障，存在多個(gè)完好的備用控制器，采用域內(nèi)最小代價(jià)原則設(shè)定好選擇的備用控制器，然后需要將主控制器下的交換機(jī)遷移至域內(nèi)選定的備用控制器。具體來說，在分布式控制平面的單個(gè)管理域內(nèi)，每個(gè)備用控制器和主控制器之間都存在遷移代價(jià)。如果主控制器故障，同時(shí)也有不定數(shù)量的備用控制器出現(xiàn)故障以及被其他管理域選擇作為備用控制器的SDN控制器。那么此時(shí)根據(jù)備用控制器選擇的最小代價(jià)原則，選擇代價(jià)最小同時(shí)備用控制器完好，而且未被其他管理域選擇的SDN控制器。如圖2所示的分布式控制平面，主控制器M1故障，同時(shí)有2個(gè)備用控制器C1和C5出現(xiàn)故障，C3控制器被其他管理域選擇作為備用控制器。根據(jù)上文所述，雖然C1的代價(jià)最小，但是C1出現(xiàn)故障，不可選；C3代價(jià)次之，但是C3被其他管理域選擇作為備用控制器，同樣不可選。C2備用控制器完好，而且未被其他管理域選擇，因此選擇C2作為待交換機(jī)遷移的備用控制器。

圖2 情況1備用控制器選擇示意圖

(2)當(dāng)在一個(gè)管理域內(nèi)，主控制器和備用控制器均故障，而鄰近域存在某一個(gè)域內(nèi)的備用控制器沒有故障。這時(shí)需要將發(fā)生故障的主控制器下的所有交換機(jī)遷移至該鄰近域內(nèi)的備用控制器。所選擇的其他域內(nèi)的備用控制器仍然按照最小代價(jià)原則執(zhí)行。同時(shí)，該控制器完好，且未被其他管理域選擇。

如圖3所示，管理域1內(nèi)的主控制器和備用控制器全部故障。相鄰管理域2內(nèi)的備用控制器存在不同的代價(jià)。應(yīng)選擇代價(jià)最小的控制器作為M1控制器的備用控制器。雖然控制器C4的代價(jià)最小，但是C4出現(xiàn)故障，不可選；C5代價(jià)次之，但是C5被其他管理域選擇作為備用控制器，同樣不可選。因此，選擇剩余可用控制器中代價(jià)最小的C6作為管理域1中故障控制器M1的待遷移控制器。

圖3 情況2備用控制器選擇示意圖

3 控制器故障處理的實(shí)現(xiàn)

SDN控制器的故障恢復(fù)的主要思路是更換控制器。為了提高網(wǎng)絡(luò)的可靠性和容錯(cuò)率，在SDN網(wǎng)絡(luò)的控制平面部署了多控制器架構(gòu)，采用Master/Slaves體系結(jié)構(gòu)，防止單點(diǎn)故障造成的網(wǎng)絡(luò)中斷。面向多管理域進(jìn)行控制器的選擇，然后將故障控制器下的交換機(jī)遷移至已選擇的控制器，繼續(xù)完成交換機(jī)分組流轉(zhuǎn)發(fā)的任務(wù)。

3.1 控制器故障監(jiān)控的實(shí)現(xiàn)

由于Echo消息是對等式的OpenFlow消息，可由所有的SDN交換機(jī)都發(fā)送Echo-request消息至SDN控制器，SDN控制器接收到來自交換機(jī)的Echo-request消息，會執(zhí)行以下代碼：

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交換機(jī)都接收不到控制器回復(fù)的Echo-reply消息，判斷SDN控制器故障。

3.2 控制器故障恢復(fù)策略的實(shí)現(xiàn)

面向多管理域的SDN控制器故障恢復(fù)策略，首先需要根據(jù)備用控制器選擇策略進(jìn)行備用控制器選擇，然后采用交換機(jī)遷移方式進(jìn)行控制器故障恢復(fù)。

3.2.1 面向多管理域的控制器選擇

采用Master/Slaves體系結(jié)構(gòu)部署SDN網(wǎng)絡(luò)控制平面，適用于多SDN管理域。每個(gè)管理域中存在多個(gè)備用控制器，分配角色為Slave；唯一一個(gè)主控制器，分配角色為Master，直接管理網(wǎng)絡(luò)。當(dāng)主控制器故障時(shí)，需要從域內(nèi)和域外選擇相應(yīng)的備用控制器作為遷移控制器。為了實(shí)現(xiàn)多個(gè)管理域之間相互選擇控制器，設(shè)定一個(gè)代價(jià)二維數(shù)組Price[m][n]和控制器的二維數(shù)組Controller[][]，其中，m為相應(yīng)的管理域個(gè)數(shù)，n為相應(yīng)管理域中備用控制器個(gè)數(shù)。需要選擇的備用控制器的條件是非故障的，且沒有被其他管理域或本域選擇的控制器，在此條件基礎(chǔ)之上選擇最小代價(jià)值的控制器。認(rèn)定備用控制器故障或者備用控制器已被其他管理域選擇，相應(yīng)的代價(jià)值為0x7fffffff；未與控制器連接的相應(yīng)的代價(jià)值也為0x7fffffff。具體實(shí)現(xiàn)的關(guān)鍵代碼如下：

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];

}

}

主控制器能夠?qū)W(wǎng)絡(luò)進(jìn)行管控，是控制平面正常工作的執(zhí)行控制平面相應(yīng)功能的主體。備用控制器在主控制器正常運(yùn)行的情況下處于假休眠狀態(tài)。另外，為了實(shí)現(xiàn)多管理域下的控制器之間的信息交互，需要在主控制器內(nèi)新建兩個(gè)功能模塊，分別是活躍監(jiān)控模塊和數(shù)據(jù)同步模塊。

活躍監(jiān)控模塊是主控制器用來與備用控制器保持通信的模塊，主要功能是在主備控制器之間周期性地接收和發(fā)送心跳報(bào)文，在主控制器故障前都可以保證備用控制器處于正常工作狀態(tài)。不需要交換機(jī)獲取備用控制器的狀態(tài)，交換機(jī)可以放心地進(jìn)行遷移。同時(shí)，因?yàn)橹骺刂破鞴收蠈?dǎo)致活躍監(jiān)控模塊不能正常工作，就不能監(jiān)控備用控制器是否故障，所以文中暫不考慮主備控制器同時(shí)故障這種小概率事件。如果主控制器一直能接收到備用控制器的心跳報(bào)文，那么就認(rèn)為備用控制器完好。當(dāng)主控制器故障后，可以執(zhí)行2.2.2小節(jié)情況1的域內(nèi)交換機(jī)遷移策略；如果活躍監(jiān)控模塊在設(shè)定的閾值時(shí)間內(nèi)主控制器還沒有收到來自備用控制器的心跳報(bào)文，那么就認(rèn)為備用控制器失效，對于主控制器故障需要執(zhí)行2.2.2小節(jié)情況2的域間交換機(jī)遷移策略。

數(shù)據(jù)同步模塊是備用控制器獲取主控制器的重要功能模塊。在主控制器故障前，備用控制器就會通過該模塊周期性地讀取主控制器的相關(guān)數(shù)據(jù)信息，如轉(zhuǎn)發(fā)平面的拓?fù)洹⒌讓咏粨Q機(jī)的IP、端口等。這樣，當(dāng)主控制器故障后，備用控制器可以根據(jù)主控制器故障前獲得的數(shù)據(jù)信息來保證故障前后的網(wǎng)絡(luò)狀態(tài)一致性和多控制器同步。

3.2.2 故障恢復(fù)策略實(shí)現(xiàn)

選擇好相應(yīng)的備用控制器以后，需要執(zhí)行SDN控制器的故障恢復(fù)策略。恢復(fù)策略采用交換機(jī)遷移方式。需要把故障的主控制器下的交換機(jī)全部遷移至備用控制器下。將OF交換機(jī)由主控制器遷移到備用控制器的具體過程如下：

Step1：主控制器通過活躍監(jiān)控模塊與備用控制器進(jìn)行周期性的信息交互，交互協(xié)議可以采用OpenFlow。主控制器發(fā)送Echo_request消息到備用控制器，備用控制器接收到Echo_request消息后需要返回給主控制器一個(gè)Echo_reply消息，這個(gè)請求和回復(fù)的過程需要不間斷地周期性發(fā)送和接收，以確保備用控制器沒有故障。當(dāng)經(jīng)過一段時(shí)間，主控制器仍然沒有接收到來自備用控制器的Echo_reply消息，就認(rèn)為備用控制器失效，這時(shí)需要采取一定的策略，如更換備用控制器等。

Step2：在備用控制器未失效的情況下，此時(shí)，OF交換機(jī)監(jiān)控發(fā)現(xiàn)Master控制器已經(jīng)故障，于是向備用控制器發(fā)出遷移請求M_request；備用控制器接收到OF交換機(jī)的連接請求M_request后，并發(fā)送M_reply給OF交換機(jī)，允許OF交換機(jī)和備用控制器進(jìn)行交換機(jī)遷移。備用控制器請求修改自身相對于OF交換機(jī)的角色為Equal。備用控制器發(fā)送一個(gè)Role_request消息到OF交換機(jī)，請求將備用控制器的角色由Slave修改為Equal。在OF交換機(jī)接收到來自備用控制器的角色修改請求信息Role_request后，OF交換機(jī)將備用控制器的角色修改為Equal，同時(shí)告知備用控制器角色已經(jīng)修改完畢，并回復(fù)消息Role_reply。

Step3：此時(shí)主控制器還是OF交換機(jī)的Master角色，為了讓OF交換機(jī)完全脫離主控制器，OF交換機(jī)的流表項(xiàng)中的某一流表指定action為控制器端口，OF交換機(jī)會根據(jù)這個(gè)動作指令以Packet_In消息發(fā)送給主備兩個(gè)控制器。由于主控制器故障，因此主控制器不進(jìn)行Packet_In消息處理；備用控制器因?yàn)樘幱贓qual角色，所以備用控制器開始介入處理OF交換機(jī)的事務(wù)。

Step4：經(jīng)過以上步驟，需要將備用控制器由相對于OF交換機(jī)的Equal角色轉(zhuǎn)變?yōu)镸aster角色。備用控制器立刻向OF交換機(jī)發(fā)送Role_request消息，請求角色變?yōu)镸aster控制器，而OF交換機(jī)在收到備用控制器的Master角色變換請求后，經(jīng)過OF交換機(jī)內(nèi)部處理與協(xié)調(diào)，返回Role-reply消息到備用控制器。此時(shí)，OF交換機(jī)已經(jīng)完成了從故障的主控制器遷移到備用控制器并修改備用控制器角色為Master的過程，備用控制器開始執(zhí)行作為OF交換機(jī)的Master控制器角色的相關(guān)管控功能。

相應(yīng)的遷移過程中的報(bào)文傳遞示意圖如圖4所示。

以上4個(gè)步驟很好地完成了交換機(jī)從故障控制器遷移至備用控制器。同時(shí)，在遷移的前后始終保持有控制器對交換機(jī)進(jìn)行同步報(bào)文的處理。出現(xiàn)故障終端時(shí)，備用控制器可以獲取主控制器在故障點(diǎn)之前的網(wǎng)絡(luò)狀態(tài)和事件處理等相關(guān)信息，遷移結(jié)束之后，備用控制器可以代替主控制器接著原來主控制器沒有完成的業(yè)務(wù)流程繼續(xù)管理網(wǎng)絡(luò)，以保證交換機(jī)遷移前后不影響網(wǎng)絡(luò)狀態(tài)的一致性。

圖4 OF交換機(jī)遷移消息傳遞過程示意圖

4 實(shí)驗(yàn)與測試

實(shí)驗(yàn)在兩個(gè)SDN管理域?qū)DN控制器進(jìn)行故障監(jiān)控和故障恢復(fù)。使用Wireshark[14]抓包軟件在控制器和交換機(jī)之間進(jìn)行OpenFlow消息抓取，驗(yàn)證控制器故障監(jiān)控的效果；搭建兩個(gè)管理域，每個(gè)管理域內(nèi)部署SDN交換機(jī)連接多個(gè)Floodlight控制器，模擬控制器故障，驗(yàn)證故障恢復(fù)策略的執(zhí)行效果。

4.1 實(shí)驗(yàn)拓?fù)洵h(huán)境的搭建

搭建多管理域SDN網(wǎng)絡(luò)實(shí)驗(yàn)拓?fù)洵h(huán)境[15]，如圖5所示。每個(gè)管理域中搭建了3臺SDN交換機(jī)，每臺交換機(jī)與一個(gè)主控制器和兩個(gè)備用控制器相連，構(gòu)成主備控制器模型。其中，C1和C4分別為管理域1和管理域2內(nèi)的主控制器；C2、C3和C5、C6分別為管理域1和管理域2內(nèi)的備用控制器。

圖5 控制器故障處理測試拓?fù)鋱D

4.2 故障恢復(fù)測試結(jié)果分析

搭建好以上實(shí)驗(yàn)拓?fù)洌瑔覵DN交換機(jī)和Floodlight控制器。配置SDN交換機(jī)連接已運(yùn)行的兩臺Floodlight控制器。

以管理域1為例，監(jiān)控主控制器C1是否故障，通過Wireshark軟件抓取3個(gè)交換機(jī)S1、S2和S3與C1之間的Echo心跳報(bào)文來進(jìn)行測試與驗(yàn)證。如果C1正常工作，那么3個(gè)交換機(jī)與C1之間的Echo消息都是成對存在的，即有request請求，必定都有reply回應(yīng)；如果C1控制器故障，那么Wireshark抓取的Echo消息都沒有reply回應(yīng)。由此可以監(jiān)控主控制器C1故障，并且證明Echo消息可以用于控制器故障的監(jiān)控。

如果C1正常工作，關(guān)閉C1，模擬主控制器C1故障，如果C2和C3均未故障，經(jīng)過域內(nèi)控制器故障恢復(fù)策略，比較C2和C3的代價(jià)，選定C2為待選備用控制器，經(jīng)過交換機(jī)遷移之后，查看C2控制臺信息發(fā)現(xiàn)原來在管理域1內(nèi)作為備用控制器的C2在C1控制器關(guān)閉之后作為新的主控制器。

關(guān)閉C1、C2和C3，模擬管理域1內(nèi)主控制器和備用控制器全部故障，同時(shí)管理域2內(nèi)的C5和C6備用控制器均正常。經(jīng)過域間控制器故障恢復(fù)策略，比較C5和C6的代價(jià)，選定C6為待選備用控制器，經(jīng)過交換機(jī)遷移之后發(fā)現(xiàn)C6成為管理域1的主控制器。

通過以上實(shí)驗(yàn)可以發(fā)現(xiàn)，在多管理域情況下，按照一定的控制器選擇策略，選定恰當(dāng)?shù)膫溆每刂破骱螅?jīng)過交換機(jī)遷移，備用控制器確實(shí)可以在主控制器故障之后成為新的主控制器來接管網(wǎng)絡(luò)。

5 結(jié)束語

為解決多管理域下SDN網(wǎng)絡(luò)中控制器發(fā)生單點(diǎn)故障的問題，就目前復(fù)雜多變的網(wǎng)絡(luò)環(huán)境，提出了跨管理域的故障監(jiān)控和恢復(fù)的解決方案。分析了控制器故障對SDN網(wǎng)絡(luò)的重大影響和必要性，給出了故障恢復(fù)解決方案的應(yīng)用場景。設(shè)計(jì)了SDN控制器故障的監(jiān)測方法，然后基于故障監(jiān)測的結(jié)果設(shè)計(jì)了多管理域下的SDN控制器故障恢復(fù)策略，通過備用控制器的選擇和交換機(jī)遷移的手段實(shí)現(xiàn)了SDN控制器的故障恢復(fù)。最后通過實(shí)驗(yàn)測試了控制器故障恢復(fù)策略的正確性，證明該方案是可行的，具有較高的實(shí)用價(jià)值。

[1] 沈蘇彬.軟件定義聯(lián)網(wǎng)的建模與分析[J].南京郵電大學(xué)學(xué)報(bào)：自然科學(xué)版，2014，34(3)：1-9.

[2] 黃 韜，劉 江.軟件定義網(wǎng)絡(luò)核心原理與應(yīng)用實(shí)踐[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域內(nèi)控制平面可擴(kuò)展性的機(jī)制[J].小型微型計(jì)算機(jī)系統(tǒng)，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] 姚 龍.軟件定義網(wǎng)絡(luò)控制器容量及部署問題研究[D].合肥：中國科學(xué)技術(shù)大學(xué)，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">網(wǎng)絡(luò)出版時(shí)間

時(shí)間：2017-09-27

國家自然科學(xué)基金資助項(xiàng)目(61502246)；江蘇省科技廳(未來網(wǎng)絡(luò)前瞻性研究項(xiàng)目)

卞宇翔(1990-)，男，碩士研究生，研究方向?yàn)橛?jì)算機(jī)網(wǎng)絡(luò)；沈蘇彬，博士生導(dǎo)師，教授，CCF高級會員(E200005482S)，研究方向?yàn)橛?jì)算網(wǎng)絡(luò)、下一代電信網(wǎng)及網(wǎng)絡(luò)安全；吳振宇，博士，講師，CCF會員(200061869M)，研究方向?yàn)閿?shù)據(jù)挖掘和人工智能。

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