【編者的話】

“技術(shù)干貨”系列文章意在分享技術(shù)牛人的知識(shí)干貨，每期主題都不一樣喲！期待各位讀者在文后發(fā)表留言，來(lái)一場(chǎng)技術(shù)上的交流和思想上的碰撞！本期將由品高云架構(gòu)師林冬藝帶來(lái)“SDN controller高可用之路”的分享。

【分享嘉賓】

林冬藝，從SDN概念誕生來(lái)一直在關(guān)注和研究，目前在BingoCloud SDN云網(wǎng)絡(luò)團(tuán)隊(duì)任職，主要負(fù)責(zé)云網(wǎng)絡(luò)、云網(wǎng)絡(luò) 安全、NFV、高性能云網(wǎng)絡(luò)的架構(gòu)與設(shè)計(jì)?，F(xiàn)在BingoCloudOS 產(chǎn)品的SDN相關(guān)功能主要來(lái)自林冬藝所在團(tuán)隊(duì) 。

【分享正文】

前言

無(wú)論你是基于SDN做物理網(wǎng)絡(luò)的大二層，還是基于SDN做云計(jì)算的網(wǎng)絡(luò)支撐。商用的基于SDN產(chǎn)品都有一個(gè)不可避免的門檻，就是SDN controller的高可用。

交換機(jī)已經(jīng)失去了對(duì)網(wǎng)絡(luò)的控制權(quán)，控制轉(zhuǎn)發(fā)分離意味著SDN controller需要更加穩(wěn)固。如果SDNcontroller出現(xiàn)單點(diǎn)故障，這樣整個(gè)網(wǎng)絡(luò)系統(tǒng)都會(huì)失去控制，甚至?xí)?lái)不可逆的災(zāi)難。

在我們?cè)O(shè)計(jì)SDN controller的部署模式的時(shí)候，就需要充分考慮SDNcontroller的單點(diǎn)問題。目前也有一種常用的手動(dòng)去解決SDNcontroller的單點(diǎn)問題，就是HA。

大部分的開源SDN controller都支持HA（如：ODL、Flooldlight），哪怕我們開發(fā)設(shè)計(jì)一個(gè)HA模式也不是一件代價(jià)很大的事情。HA模式確實(shí)可以解決SDN controller的單點(diǎn)故障，但是無(wú)法解決SDNcontroller的首包處理的單點(diǎn)性能瓶頸。這也是我們今天討論的重點(diǎn)，分析幾種SDN controller的部署模式。

SDN controller如何做高可用？

在講述SDN controller的部署模型之前，我們還是先了解一下SDN controller的高可用實(shí)現(xiàn)原理。有了原理的支撐，對(duì)于后續(xù)的模型會(huì)有更清晰的理解。

其實(shí)OpenFlow（>= 1.2）協(xié)議本身就支持對(duì)交換機(jī)的角色管理。對(duì)于交換機(jī)，SDN controller有Master、Slave兩種角色，并且在同一時(shí)間只有一個(gè)Master。

不同的角色有不同的權(quán)限，當(dāng)然這個(gè)可以通過SDN controller修訂。簡(jiǎn)要說Master角色可以接收首包、推送流表、監(jiān)聽交換機(jī)的信息（交換機(jī)的ADD、Remove、Port change）等等，而Slava角色只能監(jiān)聽交換機(jī)的信息。SDN controller可以通過OpenFlow協(xié)議要求交換機(jī)更換角色，SDN controller的高可用就是基于這樣的規(guī)則下實(shí)現(xiàn)的。假設(shè)其中一個(gè)SDN controller出現(xiàn)故障，另外的SDNcontroller馬上要求交換機(jī)切換角色即可。

SDN controller模型

　　SDN controller HA模型圖

如上圖：這就是SDN controller HA模型。當(dāng)Master controller出現(xiàn)故障，Slavecontroller通過心跳線感知，馬上要求vSwitch切換角色。Slave controller變成Master。等故障的controller重啟，角色變回Slave即可。

這個(gè)方案有一個(gè)明顯的缺點(diǎn)，同一時(shí)間只有一個(gè)SDNcontroller在工作，這樣整體的網(wǎng)絡(luò)規(guī)模受限于單個(gè)SDNcontroller的首包處理性能。Slave controller的存在無(wú)法分擔(dān)首包的壓力，這樣的工作態(tài)度不太好。

　　SDN controller AA模型圖

如上圖：這是HA模型的演進(jìn)版，SDN controller1既是vSwitch1、vSwitch2的Master，又是vSwitch3、vSwitch4的Slave。SDN controller2既是vSwitch3、vSwitch4的Master，又是vSwitch3、vSwitch4的Slave。假設(shè)SDN controller1出現(xiàn)故障，SDNcontroller2會(huì)接管vSwitch1,vSwitch2。這樣的設(shè)計(jì)有效地分?jǐn)偭薙DN controller的首包壓力。

AA模式在技術(shù)上其實(shí)存在幾個(gè)難點(diǎn)，第一，SDN controller之間處理心跳以外，還需要知道各自接管的交換機(jī)信息。第二，SDN controller之間需要實(shí)現(xiàn)負(fù)載均衡，假設(shè)新的交換機(jī)接入進(jìn)來(lái)，需要選擇最空閑的SDN controller接管。第三，自修復(fù)功能，假設(shè)有交換機(jī)脫管了，需要重新接管過來(lái)。第四，遠(yuǎn)程方法問題，應(yīng)用層不可能知道哪個(gè)Controller現(xiàn)在負(fù)責(zé)哪個(gè)交換機(jī)，這時(shí)候就需要SDNcontroller實(shí)現(xiàn)多控制器之間的遠(yuǎn)程方法調(diào)用。只要解決這些技術(shù)難點(diǎn)，SDN controller AA模型落地不成問題。也可以滿足一定規(guī)模的網(wǎng)絡(luò)。

竟然AA模型已經(jīng)做出來(lái)的，我們離集群模型還遠(yuǎn)嗎？SDNcontroller cluster模型最難的地方是多控制器之間的同步問題。分析一下兩種最常見的SDN controller的同步模型。

自同步模型：

　　SDN controller Cluster模型

如上圖：AA模型只需要一對(duì)一的同步，但是如果N多個(gè)Controller之間，就類似與畫星星一樣，這樣模型的收斂時(shí)間會(huì)變得很長(zhǎng)，而且SDN controller之間選舉算法也變得非常復(fù)雜。我們需要針對(duì)這樣的模型設(shè)計(jì)高可靠容錯(cuò)的機(jī)制，因?yàn)橐坏┻@個(gè)模型數(shù)據(jù)同步出現(xiàn)問題，我們很難排除究竟是哪個(gè)Controller出現(xiàn)壞數(shù)據(jù)。不過只要算法做得足夠高效，并且合理規(guī)避風(fēng)險(xiǎn)，自同步模型是完全可以滿足大規(guī)模網(wǎng)絡(luò)的需求的。SDN controller的擴(kuò)張性也有足夠高。

　　統(tǒng)一管理模型（三層模型）

如上圖：既然SDN controller之間的同步如此復(fù)雜，我們可以單獨(dú)將同步這個(gè)功能抽離出來(lái)變成一個(gè)角色。這個(gè)角色負(fù)責(zé)多Controller之間的同步，而Controller就可以專心負(fù)責(zé)業(yè)務(wù)功能，不用過多關(guān)系同步的問題。這樣的設(shè)計(jì)模型我們統(tǒng)稱“三層模型”。也是很多Cluster方案在演進(jìn)過程中的必經(jīng)之路。這樣的模型在HP的一個(gè)項(xiàng)目中，有見過。自同步模型的問題都在這個(gè)方案上得到很好解決。但是Sync Manager卻成為了單點(diǎn)，所以SyncManager需要做HA。假設(shè)SDN controller的數(shù)量達(dá)到一定的量級(jí)之后，SyncManager也會(huì)網(wǎng)絡(luò)收斂的瓶頸。這樣豈不是SyncManager需要做Cluster？四層模型？三層模型在我的觀點(diǎn)上已經(jīng)是極限了。所以Sync Manager也不是萬(wàn)靈藥。

我們回到云計(jì)算，假設(shè)Cluster模型擴(kuò)張到最大規(guī)模也就是在每個(gè)NC（計(jì)算節(jié)點(diǎn)）上運(yùn)行一個(gè)SDN Controller。這時(shí)候，其實(shí)我們還需不需要做SDNcontroller的角色切換呢？

　　SDN controller分布式模型

如上圖：SDN controller分布式模型最大的特點(diǎn)是SDNcontroller只負(fù)責(zé)管理本地的交換機(jī)，SDNcontroller之間不存在心跳，假設(shè)SDNcontroller1發(fā)生故障了，就重啟SDN controller1進(jìn)程。如果NC宕機(jī)了，就遷移VM。這樣也是一個(gè)高可用方案。SDN controller之間的數(shù)據(jù)同步是通過分布式數(shù)據(jù)庫(kù)完成。在云計(jì)算中，大量使用的分布式數(shù)據(jù)庫(kù)，技術(shù)相對(duì)成熟。所以我們不用但是分布式數(shù)據(jù)庫(kù)的可靠性。我們只需要設(shè)計(jì)好遠(yuǎn)程方法調(diào)用，讓應(yīng)用對(duì)分布式無(wú)感知。這樣的設(shè)計(jì)SDN controller的首包處理能力會(huì)隨著NC的增加而提升。并且如果其中一個(gè)實(shí)例出現(xiàn)大量的首包（如：DDos攻擊），影響范圍也只是VM所在的NC，這樣我們可以做出很多有效的處理。這樣的模式，我認(rèn)為是未來(lái)SDN云網(wǎng)絡(luò)發(fā)展的一個(gè)重要的分界線。只要在真正意義上，擺脫SDN controller的瓶頸，才能將SDN推向一個(gè)產(chǎn)品化之路。

總結(jié)

我們分析了很多SDN相關(guān)的模型，這樣模式都是在實(shí)際的項(xiàng)目場(chǎng)景中，發(fā)展演進(jìn)的產(chǎn)物。我們?cè)谠O(shè)計(jì)SDN網(wǎng)絡(luò)的過程中，不能只看到SDN的長(zhǎng)處，而忽略它的短處。SDN的集中化管理、控制轉(zhuǎn)發(fā)分離特性恰恰是我們?cè)O(shè)計(jì)者的痛點(diǎn)。我們既要原汁原味地保留SDN的特性的同時(shí)還需要堅(jiān)持走高可用、高擴(kuò)展產(chǎn)品化之路。所以邏輯值集中，模型上分布才是SDN技術(shù)的一大精髓。

參考文獻(xiàn)：

https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-spec-v1.3.3.pdf

【最后】

更多資訊，可以掃描以下二維碼關(guān)注我們。

想提出問題的同學(xué)們，可以在右下方“下留言”，告訴我們，分享嘉賓會(huì)進(jìn)行解答噢！