SDN多控制器容錯(cuò)機(jī)制的研究與設(shè)計(jì)

向 波，俞黎陽(yáng)

華東師范大學(xué) 計(jì)算機(jī)科學(xué)與軟件工程學(xué)院，上海 200062

1 引言

傳統(tǒng)網(wǎng)絡(luò)中，網(wǎng)絡(luò)策略和配置在運(yùn)行前都固化一體。網(wǎng)絡(luò)運(yùn)行期間，如果策略需求發(fā)生變動(dòng)，重新配置修改相應(yīng)的網(wǎng)絡(luò)設(shè)備是一件非常繁瑣的事情。在互聯(lián)網(wǎng)/移動(dòng)互聯(lián)網(wǎng)瞬息萬(wàn)變的業(yè)務(wù)環(huán)境下，網(wǎng)絡(luò)的高穩(wěn)定與高性能還不足以滿足實(shí)時(shí)的業(yè)務(wù)需求，靈活性和敏捷性變得日趨重要。

在這樣的背景下，軟件定義網(wǎng)絡(luò)（Software Defined Network，SDN）應(yīng)運(yùn)而生，它提出將網(wǎng)絡(luò)設(shè)備中的轉(zhuǎn)發(fā)平面與控制平面解耦，提供了傳統(tǒng)網(wǎng)絡(luò)難以企及的靈活性和敏捷性。SDN將多個(gè)網(wǎng)絡(luò)節(jié)點(diǎn)的控制平面集中化為一個(gè)中心控制器，網(wǎng)絡(luò)管理人員可以通過(guò)在控制器上編寫軟件應(yīng)用操作下層轉(zhuǎn)發(fā)設(shè)備。通過(guò)這樣的方式，可以大大簡(jiǎn)化網(wǎng)絡(luò)的配置過(guò)程，并可以根據(jù)網(wǎng)絡(luò)狀況實(shí)時(shí)下發(fā)策略，有效提高網(wǎng)絡(luò)的靈活性。

SDN目前仍處于萌芽發(fā)展期，業(yè)內(nèi)已經(jīng)有一部分實(shí)驗(yàn)性的網(wǎng)絡(luò)架構(gòu)應(yīng)用于生產(chǎn)環(huán)境，比如Google的數(shù)據(jù)中心網(wǎng)絡(luò)B4[1]。但是SDN在帶來(lái)極大便利的同時(shí)，也面臨許多新的問(wèn)題，如控制器的可擴(kuò)展性，SDN的故障恢復(fù)等?？刂破鞯目蓴U(kuò)展性指的是單個(gè)控制器的資源有限，導(dǎo)致單控制器無(wú)法處理大量請(qǐng)求負(fù)載。在大型網(wǎng)絡(luò)中，這個(gè)問(wèn)題尤為明顯。而SDN的故障恢復(fù)在小型中型乃至大型網(wǎng)絡(luò)中都是不容忽視的問(wèn)題。SDN中，根據(jù)故障發(fā)生的位置，可以分為數(shù)據(jù)平面故障和控制平面故障，這兩者故障恢復(fù)方式有所差別。數(shù)據(jù)平面故障時(shí)，控制器仍然可以參與故障恢復(fù)，控制器接受下層提交的故障信息，重新計(jì)算、下發(fā)命令給下層。在恢復(fù)時(shí)間要求嚴(yán)格的場(chǎng)合，也可以采用預(yù)先安裝保護(hù)性措施的方式加快恢復(fù)速度[2]。而控制平面的容錯(cuò)則顯得更為復(fù)雜一點(diǎn)，在控制平面（包括控制器自身以及控制器與交換機(jī)之間的通信鏈路）發(fā)生故障時(shí)，不再有控制器從上層指揮恢復(fù)行為。本文研究控制器單點(diǎn)故障時(shí)的容錯(cuò)機(jī)制。學(xué)術(shù)界對(duì)此已有多方討論并提出了各種各樣的解決方案，多控制器容錯(cuò)成為解決此問(wèn)題的方案之一，也是當(dāng)前使用最廣泛的方案之一。當(dāng)前主流的多控制器容錯(cuò)機(jī)制大多采用多控制器主從協(xié)作，這種機(jī)制需要多個(gè)控制器協(xié)同控制同一個(gè)控制域，某種程度上是對(duì)控制器資源的極大浪費(fèi)。鑒于此，本文提出一種帶內(nèi)通信場(chǎng)景下平面式的多控制器容錯(cuò)架構(gòu)，單控制器控制單個(gè)自治域，在可接受的時(shí)間內(nèi)完成控制器故障的快速恢復(fù)。

2 SDN單點(diǎn)故障

圖1展示了單控制器管理的SDN帶內(nèi)通信網(wǎng)絡(luò)。中心化的控制器通過(guò)網(wǎng)絡(luò)的南向接口（如OpenFlow）控制轉(zhuǎn)發(fā)平面行為，這給網(wǎng)絡(luò)帶來(lái)了極大的靈活性。與此同時(shí)，集中化的控制器也成為網(wǎng)絡(luò)運(yùn)行時(shí)的一大隱患。若控制器發(fā)生單點(diǎn)故障，交換機(jī)仍可正常轉(zhuǎn)發(fā)數(shù)據(jù)包，但是控制器無(wú)法對(duì)下屬交換機(jī)進(jìn)行正確的轉(zhuǎn)發(fā)指導(dǎo)，大量的數(shù)據(jù)包（尤其是packet-in報(bào)文）會(huì)被丟棄，導(dǎo)致網(wǎng)絡(luò)無(wú)法正常工作。

圖1 SDN帶內(nèi)通信

3 國(guó)內(nèi)外研究現(xiàn)狀

目前SDN控制器容錯(cuò)主要針對(duì)的是多控制器場(chǎng)景。多控制器容錯(cuò)，主要考慮的有控制器部署、控制器級(jí)聯(lián)失效以及具有容錯(cuò)能力的控制器架構(gòu)設(shè)計(jì)這幾個(gè)方面。

（1）關(guān)于多控制器部署。目前這方面的研究大多探討帶內(nèi)通信場(chǎng)景下，如果某些節(jié)點(diǎn)失效，如何使得整個(gè)網(wǎng)絡(luò)中受影響的節(jié)點(diǎn)數(shù)量最少，而不是考慮故障發(fā)生后如何進(jìn)行故障恢復(fù)。這些研究的關(guān)鍵就在于使用何種算法進(jìn)行多控制器部署。文獻(xiàn)[3-5]分別使用了網(wǎng)絡(luò)依賴分析，最小分割算法和貪心算法部署多個(gè)控制器。這些文章都是在控制器故障已經(jīng)發(fā)生的情景下討論多控制器部署問(wèn)題。文獻(xiàn)[6]則考慮了故障發(fā)生前后這兩種場(chǎng)景，在多控制器部署和性能（控制器與交換機(jī)之間時(shí)延和容錯(cuò)性能）之間進(jìn)行折中。文獻(xiàn)[7]研究了多控制器主從協(xié)作時(shí)的控制器分配問(wèn)題，在保證時(shí)延和交換機(jī)所需控制器數(shù)目的情況下，最小化網(wǎng)絡(luò)中控制器的數(shù)量。

（2）如何處理控制器級(jí)聯(lián)失效?？刂破骷?jí)聯(lián)失效，是指在多控制器場(chǎng)景下，一臺(tái)控制器失效后，其下屬交換機(jī)需要交由其他控制器負(fù)責(zé)管理，此時(shí)就可能出現(xiàn)其他控制器過(guò)載的現(xiàn)象。文獻(xiàn)[8]提出了一個(gè)參數(shù)-容忍模型，以及控制器容量與當(dāng)前負(fù)載之間需滿足的條件，來(lái)解決控制器的級(jí)聯(lián)失效問(wèn)題。

（3）具有容錯(cuò)能力的控制器架構(gòu)設(shè)計(jì)。文獻(xiàn)[9-10]提出使用額外的數(shù)據(jù)存儲(chǔ)同步控制器之間的信息。文章提出采用主從式架構(gòu)，即同一時(shí)間只有一臺(tái)控制器對(duì)全網(wǎng)進(jìn)行控制，從而減少了多個(gè)同時(shí)工作的控制器之間同步信息的開銷。同時(shí)數(shù)據(jù)存儲(chǔ)的使用也避免了控制器切換帶來(lái)的耗時(shí)問(wèn)題。文獻(xiàn)[11]針對(duì)帶內(nèi)通信場(chǎng)景提出了一個(gè)基于事務(wù)的分布式控制平面來(lái)保證控制平面信息的一致性，同時(shí)使得故障域本地化。與帶外通信相比，大大降低了復(fù)雜度，同時(shí)避免了帶外的諸多限制。文獻(xiàn)[12]提出一種高可用性的TCP技術(shù)，解決控制器故障恢復(fù)過(guò)程中交換機(jī)異步報(bào)文丟失的問(wèn)題。文獻(xiàn)[7，10，13]都采用了多控制器主從協(xié)作的思想。文獻(xiàn)[7]提出一種控制器遭遇拜占庭式攻擊而失效的解決方案。文中提出使用BFT（Bayzantine Fault Tolerant）算法來(lái)保證交換機(jī)不受被攻擊控制器發(fā)出的虛假信息的影響，利用多控制器協(xié)作提高交換機(jī)流表下發(fā)更新的準(zhǔn)確率和成功率。文獻(xiàn)[10]重點(diǎn)研究了交換機(jī)與控制器之間多對(duì)多的對(duì)應(yīng)關(guān)系，文中僅簡(jiǎn)單介紹算法的容錯(cuò)原理，沒(méi)有結(jié)合SDN網(wǎng)絡(luò)的具體場(chǎng)景對(duì)其工作機(jī)制和實(shí)現(xiàn)方法做進(jìn)一步研究。此外，文章也沒(méi)有給出FT（Fault Tolerant）算法對(duì)SDN網(wǎng)絡(luò)性能造成的影響。文獻(xiàn)[13-14]提出使用Paxos算法的思想進(jìn)行多控制器容錯(cuò)。文獻(xiàn)[13]著重于容錯(cuò)機(jī)制的實(shí)現(xiàn)，保證主控制器故障時(shí)網(wǎng)絡(luò)能夠平滑地切換到從控制器。而文獻(xiàn)[14]重點(diǎn)研究并減小這種容錯(cuò)機(jī)制對(duì)于控制器性能的影響，在控制器容錯(cuò)與控制器性能之間進(jìn)行平衡。

4 架構(gòu)介紹

4.1 架構(gòu)整體介紹

上述多控制器容錯(cuò)方案中，使用最為廣泛的就是多控制器主從協(xié)作，主從控制器保持狀態(tài)一致，主控制器失效時(shí)，從控制器可以快速接管主控制器的工作，使得網(wǎng)絡(luò)能夠正常運(yùn)作。

然而，使用多個(gè)控制器控制單個(gè)網(wǎng)絡(luò)域是對(duì)控制器資源的極大浪費(fèi)。為了有效利用控制器資源，本文提出一種平面式的架構(gòu)，具體為多個(gè)控制器組成的帶內(nèi)通信場(chǎng)景下，將網(wǎng)絡(luò)劃分成多個(gè)控制域，每個(gè)控制域由單獨(dú)的控制器進(jìn)行管理。這些控制器前后相連形成環(huán)狀結(jié)構(gòu)，利用心跳監(jiān)測(cè)之類的方法檢測(cè)控制器故障，控制器故障后，采用交換機(jī)重托管算法將故障控制器下的交換機(jī)托管到其余正常工作的控制器下。此外，考慮到單個(gè)控制器的負(fù)載能力有限，為了避免控制器過(guò)載引發(fā)控制器級(jí)聯(lián)失效，本文選擇將故障控制器下的交換機(jī)劃分為多個(gè)交換機(jī)簇，再將交換機(jī)簇托管到不同的控制器下。極端情況下，正常工作控制器的總剩余負(fù)載無(wú)法滿足故障控制器下所有交換機(jī)。為此，本文使用預(yù)定義的腳本動(dòng)態(tài)添加控制器。為了獲取故障控制器及其下屬交換機(jī)的網(wǎng)絡(luò)信息，本文將所有控制域的網(wǎng)絡(luò)視圖存儲(chǔ)到一個(gè)分布式的Hazelcast數(shù)據(jù)庫(kù)中。

4.2 模塊介紹

這一節(jié)將對(duì)控制器故障檢測(cè)，交換機(jī)簇劃分和交換機(jī)重托管這三個(gè)主要模塊進(jìn)行介紹。

4.2.1 控制器故障檢測(cè)

常見的網(wǎng)絡(luò)故障檢測(cè)方法有三種，分別是Hello報(bào)文（心跳檢測(cè)）、BFD（Bidirectional Forwarding Detection）和LoS（Loss of Signal）。

以O(shè)SPF、ISIS等常見路由協(xié)議為例，這些協(xié)議本身就具有故障檢測(cè)能力，通過(guò)互相發(fā)送Hello報(bào)文用于協(xié)商和建立鄰居。關(guān)系建立完成后，鄰居間仍然會(huì)每隔一定時(shí)間發(fā)送一次Hello報(bào)文并對(duì)收到的Hello報(bào)文進(jìn)行回復(fù)。這種行為就像設(shè)備的心跳一樣，只要心跳一直存在就表明設(shè)備功能正常，反之如果發(fā)送出去的Hello報(bào)文一直沒(méi)有收到回復(fù)，那么協(xié)議就認(rèn)為鄰居出現(xiàn)故障。這種設(shè)備間互相發(fā)送Hello包的方式被稱為慢Hello機(jī)制，其缺點(diǎn)是只能提供秒級(jí)檢測(cè)，對(duì)于時(shí)延敏感的業(yè)務(wù)（如語(yǔ)音業(yè)務(wù)），超過(guò)1秒的延遲也是令人無(wú)法忍受的。BFD（Bidirectional Forwarding Detection）是一個(gè)用于檢測(cè)網(wǎng)絡(luò)故障的協(xié)議，可以實(shí)現(xiàn)毫秒級(jí)檢測(cè)。BFD的原理和IGP協(xié)議自帶的Hello報(bào)文類似，簡(jiǎn)單來(lái)說(shuō)就是高速發(fā)送Hello報(bào)文，因此可以更快檢測(cè)到故障。LoS意為信號(hào)丟失，可能的原因有很多，如網(wǎng)絡(luò)設(shè)備鏈路故障，網(wǎng)絡(luò)設(shè)備配置不正確或者設(shè)備本身故障。LoS往往用于檢測(cè)數(shù)據(jù)平面轉(zhuǎn)發(fā)端口的失效。由于本文是對(duì)控制器故障進(jìn)行檢測(cè)，并且需要保證實(shí)時(shí)性，所以本文選用了BFD。

4.2.2 交換機(jī)簇劃分

控制器故障后，故障控制器無(wú)法對(duì)其下屬交換機(jī)進(jìn)行轉(zhuǎn)發(fā)指導(dǎo)，這時(shí)就需要對(duì)網(wǎng)絡(luò)進(jìn)行快速恢復(fù)。本文采用的是平面式的容錯(cuò)架構(gòu)，所以最好的方法就是將故障控制器下的交換機(jī)托管給其余正常工作的控制器。

然而，控制器負(fù)載交換機(jī)數(shù)量是有限的，在保證控制器能夠正常工作的前提下，當(dāng)前網(wǎng)絡(luò)中可能不存在任何一臺(tái)控制器剩余足夠容量去負(fù)載故障控制器下的所有交換機(jī)，所以需要將故障控制器下的交換機(jī)劃分為若干交換機(jī)簇，將交換機(jī)簇托管到不同的控制器下。交換機(jī)簇的劃分在某種程度上也是一種控制器間的負(fù)載均衡，可以有效緩解文獻(xiàn)[8]中提到的控制器級(jí)聯(lián)失效問(wèn)題。在交換機(jī)簇劃分問(wèn)題上，存在著許多的偏好，偏好不同，則結(jié)果往往大相徑庭。例如，若按照交換機(jī)與控制器間延遲大小進(jìn)行劃分，網(wǎng)絡(luò)恢復(fù)后節(jié)點(diǎn)間的延遲會(huì)較小，但是極易產(chǎn)生控制器負(fù)載失衡甚至級(jí)聯(lián)失效；若按照控制器剩余容量大小進(jìn)行劃分，網(wǎng)絡(luò)恢復(fù)后的延遲可能會(huì)較大，容易產(chǎn)生網(wǎng)絡(luò)擁塞。本文平衡了延遲與控制器剩余容量雙重偏好，延遲優(yōu)先，在低延遲的情況下根據(jù)控制器剩余容量進(jìn)行劃分，保證網(wǎng)絡(luò)恢復(fù)后的低延遲和高性能。即便這樣，仍有可能出現(xiàn)其余正常工作控制器的總剩余容量小于故障控制器下交換機(jī)數(shù)量的極端情況。為此，本文使用預(yù)定義的腳本動(dòng)態(tài)添加控制器。具體的交換機(jī)簇劃分算法和實(shí)例將在5.4節(jié)進(jìn)行詳細(xì)介紹。

4.2.3 交換機(jī)重托管

交換機(jī)簇劃分完成后，接下來(lái)的工作就是將這些交換機(jī)簇托管到對(duì)應(yīng)的控制器下。本文采用的是帶內(nèi)通信模式，若某臺(tái)交換機(jī)需要托管到其他的控制器下，則只需這臺(tái)交換機(jī)與新的控制器直接或間接存在一條可以連通的鏈路即可。具體的重托管思想和過(guò)程將在5.5節(jié)進(jìn)行詳細(xì)介紹。

5 實(shí)現(xiàn)

在上一章介紹整體架構(gòu)的基礎(chǔ)上，本章將詳細(xì)介紹主要模塊的實(shí)現(xiàn)細(xì)節(jié)。

5.1 分布式數(shù)據(jù)庫(kù)

本文選用的Floodlight控制器，雖自身提供了NoSQL的存儲(chǔ)機(jī)制，但過(guò)于簡(jiǎn)單，綜合考慮性能以及安全性和穩(wěn)定性，本文使用Hazelcast實(shí)現(xiàn)分布式數(shù)據(jù)存儲(chǔ)。

在眾多的NoSQL數(shù)據(jù)庫(kù)中，Hazelcast具有領(lǐng)先的多并發(fā)性能和靈活性，其數(shù)據(jù)存儲(chǔ)機(jī)制和分布式架構(gòu)保證了數(shù)據(jù)存儲(chǔ)的低延遲和高并發(fā)。此外，Hazelcast提供了強(qiáng)大的一致性保證、事務(wù)支持和事件通知，并可通過(guò)配置定期將數(shù)據(jù)持久化到磁盤中。Hazelcast是基于Java實(shí)現(xiàn)的，很容易與Floodlight控制器進(jìn)行整合。為了便于控制器故障的快速恢復(fù)，每臺(tái)控制器定時(shí)獲取其下屬控制域的拓?fù)湟晥D，并將抽象化的網(wǎng)絡(luò)視圖存儲(chǔ)到Hazelcast中。

5.2 帶內(nèi)通信

帶內(nèi)通信的建立參考了文獻(xiàn)[15]中使用的DHCP客戶端-服務(wù)器模式。帶內(nèi)通信網(wǎng)絡(luò)下，交換機(jī)與控制器之間的會(huì)話通過(guò)TCP連接進(jìn)行維持。選用DHCP客戶端-服務(wù)器模式可以實(shí)現(xiàn)交換機(jī)動(dòng)態(tài)獲取網(wǎng)絡(luò)地址，以便交換機(jī)與控制器之間能夠建立TCP連接。具體步驟為：

（1）每臺(tái)交換機(jī)運(yùn)行一個(gè)DHCP（動(dòng)態(tài)主機(jī)配置協(xié)議）客戶端。

（2）每臺(tái)交換機(jī)中開辟兩塊單獨(dú)的棧區(qū)分別用來(lái)保存數(shù)據(jù)流和控制流。

（3）DHCP客戶端（交換機(jī)）廣播發(fā)送DHCP報(bào)文，DHCP服務(wù)器向客戶端（交換機(jī)）回復(fù)DHCP報(bào)文時(shí)攜帶控制器的IP地址和端口號(hào)。DHCP服務(wù)器可以位于控制器內(nèi)部進(jìn)程中，也可以位于其他外部進(jìn)程中。若DHCP服務(wù)器位于獨(dú)立進(jìn)程中，則此進(jìn)程必須與控制器處于同一子網(wǎng)，以保證DHCP服務(wù)器能夠與交換機(jī)進(jìn)行通信。本文為了方便，將DHCP服務(wù)器放置于單獨(dú)的進(jìn)程中（一個(gè)控制域擁有一個(gè)DHCP服務(wù)器，所有DHCP服務(wù)器共享同一IP資源池）。

若交換機(jī)沒(méi)有連接到控制器，即交換機(jī)沒(méi)有分配IP地址，則交換機(jī)周期性地發(fā)送DHCP報(bào)文給其鄰居節(jié)點(diǎn)，直到收到DHCP服務(wù)器的應(yīng)答。如果鄰居節(jié)點(diǎn)就是DHCP服務(wù)器，則DHCP服務(wù)器直接回復(fù)DHCP響應(yīng)。否則，鄰居節(jié)點(diǎn)根據(jù)自身是否已經(jīng)與控制器建立Open-Flow會(huì)話決定轉(zhuǎn)發(fā)或者丟棄DHCP報(bào)文。如果鄰居節(jié)點(diǎn)已經(jīng)與控制器建立DHCP會(huì)話，則鄰居節(jié)點(diǎn)將DHCP請(qǐng)求報(bào)文轉(zhuǎn)發(fā)給DHCP服務(wù)器，否則直接丟棄。當(dāng)交換機(jī)獲取到IP地址并且知曉了控制器的IP地址和端口號(hào)，交換機(jī)便與控制器建立OpenFlow會(huì)話。當(dāng)每臺(tái)交換機(jī)都與控制器建立或保持OpenFlow會(huì)話后，控制器通過(guò)LLDP（鏈路層發(fā)現(xiàn)協(xié)議）獲取網(wǎng)絡(luò)拓?fù)洹?/p>

5.3 控制器故障檢測(cè)算法

控制器故障檢測(cè)主要利用相鄰控制器間BFD通信進(jìn)行控制器狀態(tài)監(jiān)測(cè)，這個(gè)模塊被整合到控制器中。BFD原本用于兩個(gè)轉(zhuǎn)發(fā)點(diǎn)間快速發(fā)送Hello包進(jìn)行故障檢測(cè)，其中某個(gè)轉(zhuǎn)發(fā)點(diǎn)接收不到Hello報(bào)文，則認(rèn)為轉(zhuǎn)發(fā)點(diǎn)間的鏈路發(fā)生故障。本文利用BFD故障檢測(cè)的思想，在環(huán)形控制器間建立雙BFD鏈路，假定鏈路持續(xù)穩(wěn)定的情況下，若控制器間通信間斷，則假定控制器發(fā)生故障。環(huán)形控制器類似于一條雙向鏈表，鏈表節(jié)點(diǎn)可以與前后相鄰節(jié)點(diǎn)進(jìn)行通信。使用雙BFD鏈路的目的是為了降低鏈路故障的概率，進(jìn)一步保證控制器故障檢測(cè)的準(zhǔn)確率。

圖2展示了4個(gè)控制器形成的環(huán)狀鏈路。現(xiàn)舉例說(shuō)明控制器故障檢測(cè)的思想和過(guò)程。

圖2 中的控制器D、A、B依次相連。A定時(shí)向D和B發(fā)送Hello消息，同時(shí)在發(fā)送后將當(dāng)前時(shí)間存儲(chǔ)到數(shù)據(jù)庫(kù)中。D和B若收到A發(fā)送的Hello消息，則將收到消息的時(shí)間存儲(chǔ)到數(shù)據(jù)庫(kù)中。若D在指定時(shí)刻未收到A發(fā)送的Hello消息，則D查詢B在相應(yīng)時(shí)刻是否收到A發(fā)送的Hello消息。若B未收到Hello消息，其也會(huì)采取相同的措施。只有D和B均未收到A發(fā)送的Hello消息，則假定A發(fā)生故障。為了進(jìn)一步確認(rèn)A是否故障，D和B到數(shù)據(jù)庫(kù)中查詢A最近一次發(fā)送Hello消息時(shí)記錄到數(shù)據(jù)庫(kù)中的時(shí)間，若該時(shí)間與當(dāng)前時(shí)間相差超出Hello消息發(fā)送時(shí)間允許的誤差，則判定A發(fā)生故障。

每臺(tái)控制器與前后相鄰兩臺(tái)控制器維持BFD會(huì)話可以大大提高控制器故障檢測(cè)的準(zhǔn)確率。此外，輔之以時(shí)間對(duì)比，可以進(jìn)一步提高控制器故障檢測(cè)的實(shí)時(shí)性和準(zhǔn)確率。為了保證控制器間BFD消息發(fā)送的同步，實(shí)驗(yàn)環(huán)境均使用同一時(shí)鐘服務(wù)器進(jìn)行時(shí)鐘同步。

據(jù)證監(jiān)會(huì)公開數(shù)據(jù)顯示，浦銀安盛、招商、永贏、銀華、平安基金等公司也申報(bào)了多只政策性金融債指數(shù)基金，目前正在排隊(duì)等待審批。其中，平安基金于10月25日一口氣申報(bào)了0-3年期、3-5年期、5-10年期等三只政策性金融債指數(shù)基金，覆蓋到了短中長(zhǎng)期的不同期限。整體來(lái)看，目前已經(jīng)有15家公募基金公司開始布局政策性金融債指數(shù)基金（包括已申報(bào)但暫未獲批的在內(nèi)）。

5.4 交換機(jī)簇劃分算法

交換機(jī)簇劃分的前提是獲取控制器故障前的全局網(wǎng)絡(luò)拓?fù)洌悦颗_(tái)控制器需要定時(shí)獲取各自控制域的網(wǎng)絡(luò)拓?fù)洳⒋鎯?chǔ)到數(shù)據(jù)庫(kù)中。這里就存在這樣一種情況，控制器剛剛獲取網(wǎng)絡(luò)拓?fù)湫畔⒉⒋鎯?chǔ)到數(shù)據(jù)庫(kù)中，之后網(wǎng)絡(luò)拓?fù)浒l(fā)生了變化，而在下一次控制器主動(dòng)獲取網(wǎng)絡(luò)拓?fù)渲翱刂破靼l(fā)生了故障，此時(shí)數(shù)據(jù)庫(kù)中關(guān)于此網(wǎng)絡(luò)的拓?fù)湫畔⒈闩c實(shí)際的網(wǎng)絡(luò)拓?fù)洳灰恢?。為了保證拓?fù)湫畔⒌膶?shí)時(shí)性和一致性，本文使用LoS對(duì)交換機(jī)端口狀態(tài)進(jìn)行監(jiān)測(cè)，當(dāng)檢測(cè)到端口狀態(tài)發(fā)生變化（Up/Down），交換機(jī)發(fā)送packet-in消息通知控制器拓?fù)湫畔⒆兓?，控制器便可以及時(shí)更新網(wǎng)絡(luò)拓?fù)洹?/p>

在已有網(wǎng)絡(luò)拓?fù)涞那闆r下，接下來(lái)需要將數(shù)據(jù)庫(kù)中存儲(chǔ)的拓?fù)湫畔⒊橄蟪梢粡垷o(wú)向圖，在無(wú)向圖上進(jìn)行圖論切割。本文切割的標(biāo)準(zhǔn)是優(yōu)先延遲（使用控制信息在網(wǎng)絡(luò)中傳輸?shù)奶鴶?shù)來(lái)表示），在保證低延遲的情況下再優(yōu)先考慮新控制器的剩余負(fù)載。

為了描述交換機(jī)簇劃分算法，本文定義了一些變量如表1。

表1 交換機(jī)簇劃分算法中的符號(hào)表示

算法流程：

（1）若其余正常工作控制器的總剩余負(fù)載小于故障控制器下交換機(jī)數(shù)量，則新增控制器，否則轉(zhuǎn)到（2）。

（2）使用DIJKSTRA（迪杰斯特拉）算法計(jì)算故障控制器下交換機(jī)到其余各臺(tái)控制器的最小跳數(shù)，并將這些跳數(shù)存儲(chǔ)到每臺(tái)交換機(jī)對(duì)應(yīng)的一個(gè)集合中（這一步是離線操作，離線操作可以節(jié)約大量時(shí)間，當(dāng)網(wǎng)絡(luò)拓?fù)浒l(fā)生變化后，控制器會(huì)重新計(jì)算）。

（3）對(duì)每臺(tái)交換機(jī)集合中的數(shù)據(jù)按照跳數(shù)從小到大排序。

（4）對(duì)所有交換機(jī)集合按照集合中的最小跳數(shù)從小到大排序。

（6）若S中的交換機(jī)個(gè)數(shù)為1，則找出最小跳數(shù)對(duì)應(yīng)的控制器Ci并判斷Ri是否大于0，若大于0，則將S0托管到Ci下并更新Ri，同時(shí)將S0標(biāo)記為已托管。否則，將S0的最小跳數(shù)從S0的跳數(shù)集合中移除，并轉(zhuǎn)到（4）。若S中交換機(jī)個(gè)數(shù)大于1，則轉(zhuǎn)到（7）。

（7）將S中的交換機(jī)按照跳數(shù)集合中最小跳數(shù)對(duì)應(yīng)的控制器進(jìn)行分組，分組結(jié)果為SS。對(duì)SS中的元素進(jìn)行如下操作：若SSi中交換機(jī)對(duì)應(yīng)控制器Ci的剩余容量Ri大于等于SSi中交換機(jī)的數(shù)量，則將SSi中的交換機(jī)托管到Ci下并更新Ri，同時(shí)將SSi中的交換機(jī)標(biāo)記為已托管，否則轉(zhuǎn)到（8）。

（8）比較SSi中交換機(jī)對(duì)應(yīng)跳數(shù)集合中的下一個(gè)最小跳數(shù)，找出擁有下一個(gè)最小跳數(shù)的交換機(jī)SSij及對(duì)應(yīng)的控制器Cj，記下一個(gè)最小跳數(shù)為h。順序遍歷其余未被托管的交換機(jī)中是否存在某個(gè)交換機(jī)Sk到控制器Cj的最小跳數(shù)小于h，若存在則將Sk托管到Cj下，更新Rj，將Sk標(biāo)記為已托管，重復(fù)此過(guò)程直到遍歷結(jié)束或Rj為0。若此時(shí)Rj仍大于0，則將SSij托管到Cj下，更新Rj，將SSij標(biāo)記為已托管。否則，按照剛開始的思路重復(fù)執(zhí)行。上述過(guò)程每次結(jié)束后，若SSi中的交換機(jī)數(shù)量小于等于Ri，則將SSi中的交換機(jī)托管到Ci下。若S Si中未被托管交換機(jī)數(shù)量仍大于Ri，則轉(zhuǎn)到（8）直到SSi中的交換機(jī)全部被托管或SSi中未被托管的交換機(jī)數(shù)量不大于Ri。

（9）若交換機(jī)集合SS中仍有未處理的交換機(jī)，則轉(zhuǎn)到（7），否則轉(zhuǎn)到（5）直到所有的交換機(jī)都被托管。

下面舉個(gè)例子來(lái)說(shuō)明。

圖3展示了4臺(tái)控制器管理的SDN帶內(nèi)通信網(wǎng)絡(luò)。C1控制 S10～S18，C2控制 S20～S28，C3控制 S30～S38，C4控制 S40～S48。

圖3 四個(gè)控制器管理的SDN帶內(nèi)通信網(wǎng)絡(luò)

假設(shè)控制器C1發(fā)生故障，從圖3可以看出，整體上控制器C2、C3、C4下屬交換機(jī)與控制器C1之間的延遲約為 C2≈C4＜C3?，F(xiàn)假設(shè)控制器 C2、C3、C4剩余容量分別為3、6、9。根據(jù)延遲優(yōu)先原則，首先計(jì)算出控制器C1下各臺(tái)交換機(jī)距離其余正常工作控制器的跳數(shù)，圖中所示可以計(jì)算如下：

S10{5C2,10C3,7C4},S11{4C2,9C3,6C4},S12{3C2,8C3,7C4},S13{6C2,9C3,6C4},S14{5C2,8C3,5C4},S15{4C2,7C3,6C4},S16{7C2,8C3,5C4},S17{6C2,7C3,4C4},S18{5C2,6C3,5C4}。其中，S10{5C2,10C3,7C4}表示交換機(jī)S10距離C2控制器5跳，距離C3控制器10跳，距離C4控制器7跳。

下面對(duì)各個(gè)交換機(jī)集合中的數(shù)據(jù)按照跳數(shù)從小到大進(jìn)行排序，結(jié)果為S10{5C2,7C4,10C3},S11{4C2,6C4，9C3},S12{3C2,7C4,8C3},S13{6C2,6C4,9C3},S14{5C2,5C4,8C3},S15{4C2,6C4,7C3},S16{5C4,7C2,8C3},S17{4C4,6C2,7C3},S18{5C2,5C4,6C3}。

接下來(lái)對(duì)所有交換機(jī)集合按照集合中的最小跳數(shù)從小到大進(jìn)行排序，結(jié)果為S12{3C2,7C4,8C3},S11{4C2,6C4,9C3},S15{4C2,6C4,7C3},S17{4C4,6C2,7C3},S10{5C2,7C4,10C3},S14{5C2,5C4,8C3},S16{5C4,7C2,8C3},S18{5C2,5C4,6C3},S13{6C2,6C4,9C3}。

根據(jù)上面的排序結(jié)果，可以將交換機(jī)S12、S11和S15托管到控制器C2下，其余交換機(jī)都托管到控制器C4下，則劃分出來(lái)的交換機(jī)簇為{C2{S12,S11,S15},C4{S16,S13,S17,S10,S14,S18}}。

這里再討論一種情況，假設(shè)控制器C2、C3、C4剩余容量分別為2、9、2。根據(jù)之前排序的結(jié)果，將交換機(jī)S12托管到控制器C2下，之后R2為1。交換機(jī)S11、S15、S17的最小跳數(shù)都為4，因?yàn)镽4等于2，所以交換機(jī)S17可以直接連接到C4下，之后R4為1。因?yàn)镽2為1，所以交換機(jī)S11和S15不能同時(shí)托管到控制器C2下。接下來(lái)考慮交換機(jī)S11和S15的下一個(gè)最小跳數(shù)。S11和S15的次小跳數(shù)都為6且對(duì)應(yīng)的控制器都是C4，而R4為1，此時(shí)需要查詢是否存在某臺(tái)交換機(jī)與控制器C4之間的最小跳數(shù)小于6，發(fā)現(xiàn)S16與控制器C4之間的最小跳數(shù)為5，所以將交換機(jī)S16托管到控制器C4下，之后R4為0。同理，接下來(lái)S11的下一個(gè)最小跳數(shù)為9，S15的下一個(gè)最小跳數(shù)為7，所以將交換機(jī)S11托管到控制器C2下，交換機(jī)S15托管到控制器C3下。

按照上述思路，可得出{C2{S12,S11},C3{S18,S15,S14,S13,S10},C4{S17,S16}}這樣一種最優(yōu)化劃分方案。

5.5 交換機(jī)重托管

交換機(jī)簇劃分完成后，下一步就需要將劃分出的交換機(jī)簇托管到相應(yīng)的控制器下。

SDN控制器與交換機(jī)的通信是由交換機(jī)主動(dòng)發(fā)起的，而劃分出的交換機(jī)簇中的交換機(jī)并不知道該向哪臺(tái)控制器發(fā)起連接請(qǐng)求，所以這就需要交換機(jī)主動(dòng)獲取或者被告知即將連接的新控制器的相關(guān)信息。

本文構(gòu)建帶內(nèi)通信使用了DHCP客戶端-服務(wù)器模式，這一通信模式可以用來(lái)實(shí)現(xiàn)上述應(yīng)用。交換機(jī)重托管的思想就是重置交換機(jī)的IP地址，之后交換機(jī)中的DHCP客戶端會(huì)和初始建立帶內(nèi)通信網(wǎng)絡(luò)時(shí)那樣向DHCP服務(wù)器發(fā)送DHCP請(qǐng)求報(bào)文，最后實(shí)現(xiàn)交換機(jī)與指定控制器建立連接。文獻(xiàn)[15]中提到使用DHCP建立帶內(nèi)通信網(wǎng)絡(luò)的速度較慢，然而此時(shí)的交換機(jī)托管速度會(huì)快得多，這是因?yàn)榫W(wǎng)絡(luò)中絕大部分的交換機(jī)都與控制器建立了OpenFlow會(huì)話，同時(shí)，本文的DHCP服務(wù)器處于單獨(dú)的進(jìn)程中，一個(gè)控制域擁有一個(gè)DHCP服務(wù)器，所以DHCP報(bào)文的下一跳選擇更多，被轉(zhuǎn)發(fā)的幾率也就大大提高。因此，幾乎所有的DHCP請(qǐng)求報(bào)文都能夠被直接轉(zhuǎn)發(fā)給DHCP服務(wù)器，很少會(huì)出現(xiàn)帶內(nèi)通信建立時(shí)的DHCP請(qǐng)求報(bào)文丟棄行為。

6 實(shí)驗(yàn)結(jié)果

本文使用Mininet作為仿真工具，在Floodlight控制器上進(jìn)行增量開發(fā)，實(shí)現(xiàn)本文所提架構(gòu)。

實(shí)驗(yàn)選用網(wǎng)格狀拓?fù)洌ㄈ鐖D3所示），網(wǎng)格狀拓?fù)湟子跀U(kuò)展，在進(jìn)行網(wǎng)絡(luò)仿真時(shí)，網(wǎng)格狀拓?fù)淇梢钥焖贁U(kuò)展到大規(guī)模網(wǎng)絡(luò)，可以方便地對(duì)本文所提架構(gòu)進(jìn)行測(cè)試。

本文選擇兩種實(shí)驗(yàn)方案，一種是所有的控制器和仿真系統(tǒng)都安裝在同一臺(tái)Ubuntu14.04機(jī)器上，這臺(tái)機(jī)器搭載Intel Core i7-6700 CPU，擁有16 GB內(nèi)存；另一種是在三臺(tái)云主機(jī)上部署控制器進(jìn)行實(shí)驗(yàn)，三臺(tái)云主機(jī)的配置相同，均為1核2 GB內(nèi)存。第二種配置方案主要是為了模擬實(shí)際環(huán)境下控制器間的通信延遲。

控制器故障檢測(cè)模塊。控制器故障檢測(cè)使用BFD的思想，大量實(shí)驗(yàn)表明，控制器故障檢測(cè)的實(shí)時(shí)性和準(zhǔn)確率與BFD消息的時(shí)間間隔有著很強(qiáng)的關(guān)聯(lián)性。實(shí)驗(yàn)假設(shè)控制器間BFD鏈路通道穩(wěn)定的情況下，隨機(jī)停掉其中一臺(tái)控制器，并重復(fù)運(yùn)行50次統(tǒng)計(jì)平均檢測(cè)時(shí)間。

圖4展示了兩種實(shí)驗(yàn)配置方案下選擇不同BFD時(shí)間間隔對(duì)應(yīng)的控制器平均故障檢測(cè)時(shí)間。從圖中可以看出，BFD消息發(fā)送時(shí)間間隔不同，對(duì)應(yīng)的故障檢測(cè)時(shí)間也會(huì)不同?？偟膩?lái)說(shuō)，故障檢測(cè)時(shí)間隨著BFD消息時(shí)間間隔的增大而變長(zhǎng)。圖中顯示若發(fā)生故障，則實(shí)際用來(lái)檢測(cè)故障的時(shí)間很短。配置方案一的故障檢測(cè)時(shí)間基本維持在4 ms以內(nèi)，而配置方案二的故障檢測(cè)時(shí)間會(huì)略長(zhǎng)，大致在17 ms左右，比配置方案一多耗時(shí)約13 ms，這是由于控制器部署在同一臺(tái)機(jī)器上時(shí)，控制器間的時(shí)延較小，而控制器部署在不同機(jī)器上時(shí)，控制器間的時(shí)延較大。通過(guò)PING命令可以測(cè)量出配置方案二不同機(jī)器之間的延遲約為12 ms，這也驗(yàn)證了實(shí)驗(yàn)結(jié)果的合理性。同時(shí)，這也說(shuō)明實(shí)際環(huán)境下故障檢測(cè)的時(shí)間預(yù)計(jì)都是在可接受的范圍內(nèi)。由于系統(tǒng)實(shí)際用來(lái)檢測(cè)故障的時(shí)間很短，所以可以根據(jù)具體的應(yīng)用場(chǎng)景選擇BFD時(shí)間間隔。

圖4 故障檢測(cè)時(shí)間

綜合下來(lái)無(wú)論是控制器處于同一機(jī)器環(huán)境下還是處于多臺(tái)機(jī)器環(huán)境下，BFD時(shí)間間隔在10 ms至20 ms之間將是一個(gè)比較好的選擇，既能保證故障檢測(cè)的實(shí)時(shí)性，同時(shí)也可以達(dá)到幾乎100%的故障檢測(cè)率。

交換機(jī)簇劃分。交換機(jī)簇劃分有很多的偏好選擇，不同的偏好對(duì)于故障恢復(fù)時(shí)間和恢復(fù)后的網(wǎng)絡(luò)性能都有很大的影響。本文選擇延遲優(yōu)先，在延遲相同的情況下優(yōu)先選擇剩余容量大的控制器進(jìn)行托管。假設(shè)網(wǎng)絡(luò)中其余控制器總剩余容量為100，這些剩余容量隨機(jī)分配到其余正常工作的控制器上并重復(fù)進(jìn)行50次統(tǒng)計(jì)平均劃分時(shí)間。

圖5展示了故障控制器下不同交換機(jī)數(shù)量時(shí)選擇不同偏好對(duì)應(yīng)交換機(jī)簇劃分所需時(shí)間。從圖中可以看出，延遲優(yōu)先以及控制器剩余容量?jī)?yōu)先這兩種偏好與本文選擇的延遲優(yōu)先剩余容量次之的方式所需劃分時(shí)間基本相當(dāng)。由于本文選用的延遲優(yōu)先剩余容量次之采用了雙重偏好，所以耗時(shí)比其他兩種略長(zhǎng)，不過(guò)都是可以忽略不計(jì)的。此外，當(dāng)控制器剩余總?cè)萘啃∮诠收峡刂破飨陆粨Q機(jī)數(shù)量時(shí)，系統(tǒng)會(huì)新增一個(gè)新的控制器，實(shí)驗(yàn)表明這一過(guò)程比較耗時(shí)，基本上維持在百毫秒的級(jí)別，但是新增控制器后便不再需要進(jìn)行交換機(jī)簇劃分，而是將故障控制器下的交換機(jī)全部掛載到新的控制器下。

圖5 交換機(jī)簇劃分所需時(shí)間

為了測(cè)試不同劃分偏好對(duì)于故障恢復(fù)后網(wǎng)絡(luò)性能的影響，本文從故障恢復(fù)后整體網(wǎng)絡(luò)延遲（全網(wǎng)環(huán)境下交換機(jī)到所屬控制器平均跳數(shù)）和各個(gè)控制器下交換機(jī)個(gè)數(shù)標(biāo)準(zhǔn)差這兩個(gè)方面進(jìn)行衡量。本文實(shí)驗(yàn)選用的是網(wǎng)格狀網(wǎng)絡(luò)，網(wǎng)絡(luò)初始階段各個(gè)控制器下交換機(jī)數(shù)量是相等的。選擇故障恢復(fù)后各個(gè)控制器下交換機(jī)個(gè)數(shù)標(biāo)準(zhǔn)差這一指標(biāo)，可以有效衡量故障恢復(fù)后各個(gè)控制器間的負(fù)載均衡以及是否可能出現(xiàn)控制器級(jí)聯(lián)失效。假設(shè)網(wǎng)絡(luò)中的故障控制器為C1，其余控制器總剩余容量為102（其余3個(gè)正常工作控制器都各自擁有34的剩余容量）。

圖6展示了故障控制器下不同交換機(jī)數(shù)量時(shí)選擇不同偏好對(duì)應(yīng)網(wǎng)絡(luò)恢復(fù)后的全網(wǎng)平均跳數(shù)。圖7展示了故障控制器下不同交換機(jī)數(shù)量時(shí)選擇不同偏好對(duì)應(yīng)網(wǎng)絡(luò)恢復(fù)后控制器下交換機(jī)個(gè)數(shù)標(biāo)準(zhǔn)差。

圖6 交換機(jī)簇劃分前后全網(wǎng)平均跳數(shù)

圖7 交換機(jī)簇劃分后各個(gè)控制器下交換機(jī)個(gè)數(shù)標(biāo)準(zhǔn)差

從圖6中可以看出，本文所選延遲優(yōu)先剩余容量次之的劃分偏好對(duì)應(yīng)劃分后的全網(wǎng)平均跳數(shù)介于延遲優(yōu)先和剩余容量?jī)?yōu)先這兩種偏好對(duì)應(yīng)結(jié)果之間，略遜于延遲優(yōu)先對(duì)應(yīng)的結(jié)果。然而從圖7中可以看出，這一點(diǎn)點(diǎn)延遲上的遜色卻換來(lái)了更加均衡的控制器負(fù)載，可以有效避免控制器級(jí)聯(lián)失效。

交換機(jī)重托管。圖8展示了交換機(jī)與新控制器間跳數(shù)對(duì)重托管時(shí)延的影響。從圖8中可以看出，跳數(shù)對(duì)于時(shí)延的影響很小。若網(wǎng)絡(luò)中其余交換機(jī)都與相應(yīng)控制器建立了OpenFlow會(huì)話，那么當(dāng)某臺(tái)交換機(jī)需要連接到指定控制器時(shí)，其DHCP請(qǐng)求報(bào)文會(huì)被快速轉(zhuǎn)發(fā)到DHCP服務(wù)器，這就類似于數(shù)據(jù)包的轉(zhuǎn)發(fā)過(guò)程，速度會(huì)特別快。

圖8 交換機(jī)重托管時(shí)延

容錯(cuò)機(jī)制對(duì)比。為了驗(yàn)證本文提出的帶內(nèi)通信場(chǎng)景下多控制器容錯(cuò)架構(gòu)的有效性，本文選取目前廣泛使用的多控制器主從容錯(cuò)機(jī)制進(jìn)行實(shí)驗(yàn)對(duì)比，主要考慮的是容錯(cuò)所需控制器數(shù)量、控制器故障后的恢復(fù)時(shí)間以及存儲(chǔ)拓?fù)湫畔⑺杩臻g大小。

實(shí)驗(yàn)均在相同條件下進(jìn)行部署模擬。主從容錯(cuò)機(jī)制需要選擇合適數(shù)量的從控制器，本文對(duì)比實(shí)驗(yàn)中選用的從控制器數(shù)量與主控制器數(shù)量相同，即主從容錯(cuò)機(jī)制使用的控制器數(shù)量是本文所提架構(gòu)的2倍。

表2展示了兩種容錯(cuò)方式下的故障恢復(fù)時(shí)間。從表2中可以看出，故障控制域下交換機(jī)數(shù)量對(duì)故障恢復(fù)時(shí)間有著較大影響。若故障控制域下存在大量交換機(jī)，交換機(jī)發(fā)送的DHCP報(bào)文需要等待鄰居節(jié)點(diǎn)與控制器建立OpenFlow會(huì)話后才能被轉(zhuǎn)發(fā)，部分DHCP請(qǐng)求報(bào)文會(huì)被丟棄，重托管速度較慢。主從機(jī)制下交換機(jī)一直與從控制器保持OpenFlow會(huì)話，所以切換速度相對(duì)較快。然而，主從控制器架構(gòu)所需控制器數(shù)量最少是本文所提架構(gòu)的兩倍。文獻(xiàn)[7，9]中提到為了保持高容錯(cuò)性，主從FT（Fault Tolerant）算法所需從控制器數(shù)量往往是主控制器數(shù)量的兩倍甚至更多。

表2 故障恢復(fù)時(shí)間 ms

主從機(jī)制下，每個(gè)控制域?qū)?yīng)的主從控制器都需要維護(hù)一份獨(dú)立的網(wǎng)絡(luò)拓?fù)洌疚乃峒軜?gòu)只需維護(hù)一份全網(wǎng)拓?fù)湫畔?，所需存?chǔ)空間自然會(huì)低得多。

實(shí)驗(yàn)證明本文提出的帶內(nèi)通信場(chǎng)景下多控制器容錯(cuò)架構(gòu)可以大大減少SDN網(wǎng)絡(luò)中的控制器數(shù)量，顯著提高控制器資源利用率，很好地提高網(wǎng)絡(luò)服務(wù)質(zhì)量。

7 結(jié)束語(yǔ)

本文研究并設(shè)計(jì)了一種帶內(nèi)通信場(chǎng)景下平面式的多控制器容錯(cuò)架構(gòu)，使用單控制器控制單個(gè)自治域，與目前廣泛使用的控制器主從協(xié)作方式相比，在相同的實(shí)驗(yàn)條件下，以30%左右的故障恢復(fù)時(shí)間為代價(jià)，將控制器的資源利用率至少提高了200%，并且隨著網(wǎng)絡(luò)規(guī)模的擴(kuò)大，本文所提架構(gòu)的優(yōu)勢(shì)將變得愈加明顯。

未來(lái)考慮在交換機(jī)簇劃分時(shí)添加一個(gè)負(fù)載均衡模塊，以根據(jù)控制器的實(shí)際負(fù)載提供動(dòng)態(tài)規(guī)劃。同時(shí)，根據(jù)控制器的實(shí)時(shí)負(fù)載，可以預(yù)判性地新增控制器，這樣可以大大縮短控制器故障恢復(fù)時(shí)間。