王鈺琪++竇偉超

摘要：為了提高可擴展性，軟件定義網(wǎng)絡出現(xiàn)了多控制器架構。但是多控制器架構中數(shù)據(jù)交互的復雜性也在快速增加，某個控制器故障導致網(wǎng)絡不可用的情況時有發(fā)生。為了提高多控制器架構下軟件定義網(wǎng)絡的服務可靠性，本文設計了一種多控制器失效備援方法，降低了現(xiàn)有多控制器架構下提升網(wǎng)絡可靠性的技術的復雜性，同時減少了控制器之間狀態(tài)交互消息的數(shù)量，對提升網(wǎng)絡服務質量，降低設備部署的成本和復雜性，保證網(wǎng)絡的高可用性方面具有極為重要的意義。

關鍵詞：軟件定義網(wǎng)絡；多控制器；失效備援

中圖分類號：TN-915

文獻標識碼：A

DOI： 10.3969/j.issn.1003-6970.2016.01.017

本文著錄格式：王鈺琪，竇偉超.SDN網(wǎng)絡多控制器結構的失效備援設計[J].軟件，2016，37 （01）：71-75

O 引言

由于互聯(lián)網(wǎng)應用的爆發(fā)式增長，全球信息量每年以指數(shù)級的速度增加；目前諸如路由器的數(shù)據(jù)轉發(fā)設備將控制平面和數(shù)據(jù)轉發(fā)平面耦合在一起，導致路由器要支持新功能所需要的升級成本和難度極大，安全性也不夠高，網(wǎng)絡需要一種新的結構來增強可擴展性和服務能力。SDN創(chuàng)造性的將控制平面的邏輯和轉發(fā)平面分離，SDN中分為兩種設備，交換機和控制器?？刂破魍ㄟ^Openflow協(xié)議向交換機下發(fā)流表規(guī)則來控制交換機的轉發(fā)能力，交換機通過流表完成數(shù)據(jù)的轉發(fā)。SDN的核心在于轉發(fā)邏輯不再固化于硬件，所有的轉發(fā)邏輯都由控制器通過Openflow協(xié)議動態(tài)下發(fā)至交換機，交換機因此可以支持各種類型的規(guī)則，極大的增強了網(wǎng)絡的可擴展性。

但是，現(xiàn)有的SDN分布式架構同樣遇到一些挑戰(zhàn)，控制平面的集中化使得控制器出現(xiàn)單點故障的危害性較大，同時單個控制器可支持的交換機數(shù)量有限，不能滿足網(wǎng)絡規(guī)模的不斷擴展。為了解決這個問題，SDN網(wǎng)絡出現(xiàn)了多控制器架構，現(xiàn)有的多控制器結構中，每個控制器會控制一部分交換機，這部分交換機作為此控制器管的一個域，各個控制器管控單獨的一個區(qū)域內的交換機。如圖1所示，控制器之間交換控制信息達到全網(wǎng)數(shù)據(jù)包轉發(fā)和管理的目的。相鄰的交換機之間交換拓撲狀態(tài)、交換機信息等數(shù)據(jù)，這樣使得整個網(wǎng)絡中任何兩個域的數(shù)據(jù)流量可以被轉發(fā)。同時這種結構也解決了聚集式控制平面出現(xiàn)的低擴展性和高負載的問題。

但是這種架構仍然沒有解決在某個控制器出現(xiàn)故障以后出現(xiàn)的網(wǎng)絡可靠性損失，當某一個控制器出現(xiàn)故障之后，部分交換機會失去連接導致一些服務失效。為了最小化這種故障，必須要有一種快速反應機制使失去連接的交換機與其他存活的控制器建立連接?，F(xiàn)有的基于多控制器提出扁平化架構的失效備援解決方案中，各個控制器都維護全網(wǎng)絡的拓撲，某一控制器失效不會影響到網(wǎng)絡服務損失，但是此種方法使控制局部網(wǎng)絡的控制器維護全網(wǎng)拓撲，單個控制器維護大量狀態(tài)，負載過高導致性能下降。

l 相關研究工作

過去的幾年中，一些方法將軟件定義網(wǎng)絡中集中化的控制平面邏輯上分布在多個控制器上，同時也提出了控制器故障時的解決方案，但是這些方法都要在各個控制器之間產生大量控制消息的流量。如.Onix和HyperFlow。Onix作為作為一個分布式控制器，它基于扁平分布式控制器架構，通過網(wǎng)絡信息庫進行管理。每個控制器都有各自獨立的信息庫，并且各個控制器之間通過數(shù)據(jù)交互保持信息庫的一致性，可以實現(xiàn)控制器之間的數(shù)據(jù)同步和更新。HyperFlow允許部署多個控制器，并將這些控制器分布在網(wǎng)絡中的不同位置。控制器之間物理上分離但是邏輯上集中。HyperFlow在某控制器失效時，通過手動配置的方法將失效控制器管理的交換機重新配置到新控制器上，保證了可用性。但是使用這種方法網(wǎng)絡管理員工作量較大而且耗時較長。還有一種方法被提出，它在多控制器環(huán)境下能夠在一些環(huán)境下提升網(wǎng)絡可靠性，但是部署相對比較復雜。

上述的這些結構和方法，每個控制器雖然掌握了全網(wǎng)狀態(tài)信息，但只能控制局部網(wǎng)絡，造成了一定的資源浪費，同時一旦有一個控制器信息出現(xiàn)變更，就要向全部控制器傳輸更新消息，增加了網(wǎng)絡更新時控制器的整體負載。

為了解決多控制器場景下控制器失效導致網(wǎng)絡服務質量降低的問題，本文提出了一種軟件定義網(wǎng)絡中多控制器失效備援方法，將由于控制器故障而失去連接的交換機動態(tài)切換到其他相鄰控制器上，能夠對控制器失效反應快速且保證全網(wǎng)的連接性。為此我們設計一個主控制器管控其他控制器，維持網(wǎng)絡全局信息，主控制器和其他控制器保持心跳，確保其他控制器正常工作。各個控制器向主控制器報告自己控制的交換機信息。當某控制器失效時，失去連接的交換機能夠向主控制器提出請求，主控制器選擇一個合適的控制器，保證各個控制器上交換機數(shù)量負載均衡。

2 失效備援機制

2.1 多控制器失效備援架構

本文描述的失效備援機制的架構如圖2所示，使用了層次化設計，在最頂端設計一個主控制器。主控制器的主要作用是：（1）維持各個控制器的交換機連接信息（2）和各個控制器保持心跳，確認控制器工作正常（3）在控制器故障時，將失去連接的交換機動態(tài)遷移到適合的存活控制器上。為了防止主控制器出現(xiàn)單點故障，我們需要對主控制器做一次熱備。

Fig.2 Failover mechanisms architecture

為了支持多控制器架構下各個層面的控制器可以協(xié)同工作，各個單個域的控制器要將各自網(wǎng)絡的關鍵信息傳遞給主控制器，所謂的關鍵信息包括：

控制器所管控的交換機的ID和交換機連接拓撲

各個交換機上的流量負載情況

控制器相鄰的控制器的標志和自身處理能力和負載

通過這些信息，當某一個普通控制器出現(xiàn)故障以后，主控制器可以全面的考察其相鄰控制器的狀態(tài)，包括流量負載，連接的交換機等數(shù)據(jù)，從故障控制器相鄰的控制器中選出負載最低的一個作為故障交換機重新連接的目標控制器。

為了統(tǒng)一處理層次間的消息，主控制和普通控制器利用Yang模型設計出抽象的數(shù)據(jù)傳輸接口和數(shù)據(jù)格式。Yang模型和工具就是實現(xiàn)XML字符信息和ODL內部Bean Object之間的轉換，無論從可擴展性、耦合、開發(fā)效率上都有優(yōu)勢。同時Yang模型采用安全的面向連接的通信傳輸方式，相比起SNMP采用UDP傳輸具有更加良好的安全性，且支持更大規(guī)模的數(shù)據(jù)傳輸。

通過Yang模型定義，通用的API運行大量網(wǎng)絡業(yè)務傳輸數(shù)據(jù)，特別是在多控制器架構中，這些不同的普通控制器域可能是由不同的Openflow控制器，但是我們通過定義通用的接口，使得各種不同類型的Openflow控制器可以協(xié)同工作，減少因為軟件不同造成的技術障礙。我們將普通控制器發(fā)送給主控制器的消息中包括的數(shù)據(jù)利用Yang模型定義內容如下：

在本文中，接口基于REST API設計，實現(xiàn)數(shù)據(jù)的高速傳輸。主控制器維持其他控制器的交換機連接信息，為此主控制器內維護一個交換機信息表，保存各個普通控制器的交換機連接信息，同時和其他控制器建立socket連接，傳遞最新的交換機信息。我們定義了一種數(shù)據(jù)格式，如圖3所示，普通控制器向主控制器發(fā)送各自的交換機連接信息，此消息中包括控制器名稱和交換機標志，交換機標志使用交換機硬件地址確保唯一性。此數(shù)據(jù)包分為ADD、DEL_ MOD、RESEND四種類型，ADD表示普通控制器向主控制器發(fā)送交換機信息增加的命令；DEL表示普通控制器向主控制器發(fā)送交換機信息刪除的命令；MOD表示普通控制器向主控制器發(fā)送交換機信息更新的命令，更新交換機所屬控制器，主控制器收到消息后相應地更新交換機信息表；RESEND表示主控制器向普通控制器發(fā)送交換機信息重傳的命令，讓某控制器利用ADD消息重傳全部交換機信息。

主控制器和普通控制器之間保持心跳，每5秒鐘發(fā)送一次心跳報文，心跳報文用于主控制器確定普通控制器的存在，當主控制器發(fā)送的報文1秒沒有收到回復，則進行重發(fā)動作，當重發(fā)次數(shù)達到5次則可以確定普通控制器已經失去連接。我們在主控制器上設計失去連接表，表格會維護目前失去連接的控制器表，用于主控制器在收到交換機失去連接的消息時能夠決定是否此控制器已經故障中斷。

SDN網(wǎng)絡可以通過幾種方法發(fā)現(xiàn)有控制器已經出現(xiàn)故障：

主控制器和普通控制器之間的心跳

主控制器和每個控制器之間保持固定間隔的心跳，相互交換機信息，如果在一定時間段內主控制器收不到某個普通控制器的心跳返回消息，則可以判斷此普通控制器故障。

交換機發(fā)出的連接決斷消息

當某個控制器和交換機之間的連接中斷，交換機根據(jù)自身的反應機制會自動向主控制器發(fā)送故障控制器和交換機的信息，主控制器以此可以判斷故障情況。

2.2 0penflow中控制器的角色

在我們設計的分布式多控制器場景中，每個控制器對它自己域內的控制器管理和控制（這些控制器將此控制器設置為Master角色）。為了達到控制器之間的切換，一個控制器需要能和交換機保持連接，同時能夠發(fā)送Role-Reque st消息來接管交換機的管理權。

根據(jù)Openflow協(xié)議的定義，每個交換機可以與多個控制器相連，與交換機相連的控制器的角色分為Master，Slave，Echo。角色為Master和Echo的控制器可以向交換機下發(fā)流表等控制消息，而角色為Echo的控制器只能獲取交換機信息。每個交換機只能設置一個控制器為Master角色。

利用多控制器的角色機制，處理控制器故障最簡單的方法是為每個域設計一個備援控制器，但是此舉的配置代價和維護費用也是極其昂貴的。我們再次闡述的控制器失效備援機制中只需要對主控制器做一次主動備援，其他控制器的故障都可以通過相鄰控制器的接管完成。

如圖4所示，在我們描述的失效備援架構中，每個控制器負責的區(qū)域內的交換機都將此控制器設置為Master角色，將主控制器設置為Echo角色，同時將其他相鄰的控制器設置為Slave角色。當交換機失去連接時，會主動向主控制器發(fā)送失去連接消息，由主控制器決定哪一個普通控制器接管交換機，接管的控制器會向交換機發(fā)送標準Openflow消息Role-Request消息成為此交換機的Master控制器，保證數(shù)據(jù)流影響盡可能小。

2.3 失效備援機制流程

整個備援機制的流程可以經過如下幾個階段。

2.3.1 檢測到故障控制器的出現(xiàn)

這一步主要是通過主控制器和普通控制器之間的心跳消息以及交換機發(fā)送給主控制器的連接決斷消息來完成。如果主控制器和普通控制器之間的心跳中斷，或者主控制器收到交換機發(fā)送來的連接決斷消息，都會激發(fā)主控制對控制器故障的檢查流程。由于主控制器和某普通控制器的心跳中斷并不能直接說明此普通控制器已經故障，因為有可能僅僅是此普通控制器和主控制器之間網(wǎng)絡連接斷開等原因造成。主控制器會根據(jù)不同的情況做出不同的判斷，這部分的操作邏輻會在本文第3部分中詳細說明。

2.3.2 檢測到故障控制器的出現(xiàn)

當主控制器判斷某普通控制器出現(xiàn)故障時，會通過故障控制器相鄰的控制器發(fā)送來的各自狀態(tài)信息，計算出一個合適的控制器，算法會考察相鄰控制器的交換機連接數(shù)，數(shù)據(jù)流量負載等因素的權重，當主控制器已經決斷出一個普通控制器進行接管時，會要求此控制器發(fā)送Role-Request消息接管故障控制器的交換機，完成交換機的動態(tài)遷移。

2.3.3 域狀態(tài)更新

當切換完成時，主控制器需要獲取實時的網(wǎng)絡狀態(tài)信息，接管的普通控制器會將接收的交換機信息更新至主控制器的交換機連接表中，保證各個域內的交換機信息保持實時一致。

3 故障情況分析

此場景如圖5所示，控制器B和控制器A和控制器C相鄰，控制器A、B、C各管理一塊交換機區(qū)域，并和主控制器保持連接和心跳?？刂破鰾管理的交換機將主控制器設置為Echo角色，將與控制器B相鄰的交換機設置為Slave角色。

3.1 普通控制器故障

當控制器B出現(xiàn)故障時，控制器B所控制的交換機失去連接，同時主控制器根據(jù)心跳判斷出控制器B出現(xiàn)故障，這時會將控制器B加入失去連接的控制器表。此時失去連接的交換機會向主控制器發(fā)送連接決斷消息，此消息中包含交換機信息和控制器B的標志。主控制器收到此消息后會先判斷控制器B是否在失去連接的控制器表中，如果在則根據(jù)交換機信息表中存儲的控制器B相鄰的控制器的流量負載以及交換機連接數(shù)，進行如下計算：

W=C*0.3+L*0.7

其中W標示最終加權值，C表示控制器連接的交換機數(shù)，L表示控制器上的負載流量。

對于控制器B相鄰的控制器都進行一次加權計算，將W值最低的作為交換機的接管控制器，此時主控制器會命令權值最低的控制器向交換機發(fā)送Openflow的Role-Request消息，將角色變更為Master，接管此交換機，同時此控制器向主控制器發(fā)送交換機信息MOD消息對交換機信息表更新。通過此處理，控制器B管控的交換機可以均勻的由控制器A和控制器C接管，保證網(wǎng)絡的負載均衡。

3.2 控制器B和交換機連接故障

此種情況下控制器B和某交換機連接故障，但是和主控制器之間保持心跳。此時交換機會向主控制器發(fā)送連接決斷消息，主控制器收到此消息后查找失去連接的控制器表失敗，則向交換機發(fā)送重新連接控制器B的命令，如果主控制器仍然收到此交換機發(fā)送的連接決斷消息，則可以判斷出控制器B和交換機連接故障，會根據(jù)上一小節(jié)所述方法選擇出一個合適的控制器接管此交換機，同時利用交換機信息MOD消息更新交換機信息表。

3.3 控制器B和主控制器連接故障

此種情況下控制器B和主控制器連接故障，和交換機保持連接。此時主控制器會向管理員報警，當網(wǎng)絡連接正常以后，會將交換機信息表中與控制器B相關的交換機信息刪除，同時發(fā)送RESEND消息讓控制器重新傳輸交換機信息。

4 實驗驗證

為了驗證基于本文提出的多控制器場景下SDN網(wǎng)絡失效備援方法的有效性，本文對同現(xiàn)有的扁平結構下失效備援機制做出數(shù)據(jù)上的對比，主要包括為保證可靠性所需要的狀態(tài)信息表的內存大小和故障恢復時間。

首先是統(tǒng)計對比在不同數(shù)量的交換機場景下，上述兩種方法為了保證可靠性所需狀態(tài)信息表占用的內存大小。統(tǒng)計此項數(shù)據(jù)通過在程序運行時對狀態(tài)信息表分配內存的數(shù)值存入log完成統(tǒng)計。對比數(shù)據(jù)如表2所示：

網(wǎng)絡從發(fā)生故障到故障切換完成會造成一定的網(wǎng)絡服務質量降低，這一段時間越短，網(wǎng)絡服務質量越高。為此，本文比較了現(xiàn)有扁平結構的失效備援機制故障時間和本文所述備援機制的故障切換時間，此數(shù)據(jù)通過在檢查出故障到完成切換前后加入Linux定時器統(tǒng)計出故障切換時間。所得到實驗數(shù)據(jù)如表3所示：

通過上述數(shù)據(jù)的對比，我們可以證明本文描述的層次式多控制器失效備援機制可以減小設置的狀態(tài)信息表大小，同時切換時間在交換機數(shù)量增加時增長幅度較小，很好的提高了網(wǎng)絡服務質量。

5 結論

本文描述了一種軟件定義網(wǎng)絡中多控制器場景下失效備援機制，此失效備援機制基于層次化設計，減少各個控制器同步消息所用的帶寬，當控制器故障發(fā)生時，可以在盡量小的時間內動態(tài)恢復網(wǎng)絡連接，提升網(wǎng)絡故時的服務質量；在此基礎上設計平衡選擇策略，使交換機連接負載最小的相鄰控制器，網(wǎng)絡流量和交換機連接均衡分配在各個控制器上，使現(xiàn)有網(wǎng)絡穩(wěn)定性較高。同時無需在各個控制器之間同步消息，使各個控制器僅僅維護局部網(wǎng)絡拓撲和連接信息，減少各個控制器不必要的負載。