Software Defined Networking是一種控制平面和數(shù)據(jù)平面分離的可編程的網(wǎng)絡(luò)架構(gòu)，目前已經(jīng)有許多商業(yè)落地案例。在部署SDN時，往往會因SDN控制器性能不足而限制了SDN的可拓展性。因此SDN網(wǎng)絡(luò)的規(guī)模往往不大。針對此問題，筆者在研究相關(guān)文獻(xiàn)之后，總結(jié)了相關(guān)的解決方案，并通過本文來記錄和分享。

SDN分離了網(wǎng)絡(luò)的控制平面和數(shù)據(jù)平面，而控制平面是SDN的大腦，其能力極大地影響著SDN網(wǎng)絡(luò)的可拓展性。所以基本上，解決方案都是圍繞如何給控制平面減壓或者提升控制平面的能力來實(shí)現(xiàn)。根據(jù)控制器數(shù)目的不同，解決方案可以分為如下兩類：

單控制器節(jié)點(diǎn)的性能拓展是最常見的方式之一，包括控制器采用多線程，負(fù)載下放等解決方案。多線程等解決方案屬于軟件開發(fā)范疇，不屬于本文討論范圍。通過負(fù)載下放（offload）等方式可以降低網(wǎng)絡(luò)對控制平面的依賴，減少控制平面的負(fù)載和壓力，從而可以管理更多的交換機(jī)，進(jìn)而提升SDN網(wǎng)絡(luò)的可拓展性。DIFANE和DoveFlow就是典型的代表。

DIFANE[1]是DIstributed Flow Architecture for Networked Enterprises的縮寫。 在DIFANE架構(gòu)中，其數(shù)據(jù)平面的所有數(shù)據(jù)均由數(shù)據(jù)平面完成，而控制器僅負(fù)責(zé)策略的計(jì)算，而不會直接響應(yīng)Packet_in。其通過減輕控制平面的負(fù)載的方式，從而增強(qiáng)了SDN的可拓展性。

圖1.DIFANE 架構(gòu)圖

在DIFANE的數(shù)據(jù)平面，可以分為權(quán)威交換機(jī)（Authority switch）和包括Ingress switch在內(nèi)的普通交換機(jī)的兩類交換機(jī)。此外，DIFANE還定義了Cache rules、Authority rules和Partition rules三類流表項(xiàng)。其中Cache rules為從Authority switch上取回來的緩存規(guī)則，用于指導(dǎo)數(shù)據(jù)包的轉(zhuǎn)發(fā)；Authority rules是控制器預(yù)計(jì)算下發(fā)的規(guī)則，可將其分發(fā)給Ingress switch，并作為Cache rules, 其僅存在于Authority switch中。Partition rules用于指導(dǎo)交換機(jī)將無法匹配到Cache rules的數(shù)據(jù)包轉(zhuǎn)向指定的Authority switch，優(yōu)先級最低。Authority switch具有一定的處理數(shù)據(jù)的能力，可以運(yùn)行鏈路協(xié)議等基本協(xié)議，可實(shí)現(xiàn)DIFANE的數(shù)據(jù)層面需求。

當(dāng)網(wǎng)絡(luò)上線時，控制器通過收集網(wǎng)絡(luò)的拓?fù)湫畔⒑椭鳈C(jī)接入位置信息等計(jì)算出Authority rules并分發(fā)到對應(yīng)的Authority switch中。此外，控制器還需要完成粗粒度的Partition rules的計(jì)算和下發(fā)。Partition rules是由網(wǎng)絡(luò)拓?fù)涞木唧w情況計(jì)算出來的粗粒度規(guī)則，其告知Ingress switch將無法匹配Cache rules的數(shù)據(jù)包應(yīng)該轉(zhuǎn)發(fā)到哪一個Authority switch。當(dāng)?shù)谝粋€packet到達(dá)Ingress switch時，不會選擇上報(bào)controller，而是會匹配到低優(yōu)先級的Partition rules，并轉(zhuǎn)發(fā)到Authority switch。Authority switch負(fù)責(zé)將其轉(zhuǎn)發(fā)到對應(yīng)的Egress switch。此外，Authority switch還會將對應(yīng)的Authority rules推送并安裝到Ingress switch中，作為其Cache rules。之后的packet就可以匹配Cache rules，然后直接轉(zhuǎn)發(fā)到Egress switch，而不需要轉(zhuǎn)發(fā)給Authority switch。在DIFANE架構(gòu)中，控制器則負(fù)責(zé)主動預(yù)先計(jì)算規(guī)則并下發(fā)，而網(wǎng)絡(luò)事件的被動響應(yīng)則由數(shù)據(jù)平面的Authority switch完成。

DIFANE的設(shè)計(jì)使得所有的數(shù)據(jù)平面的數(shù)據(jù)都由數(shù)據(jù)平面處理，而不是緩存在交換機(jī)隊(duì)列中，再發(fā)送給控制器處理。此舉使得絡(luò)首包的延遲變小，同時也大大降低了控制器的壓力，進(jìn)而可以管理更大的網(wǎng)絡(luò)。不過這樣的解決方案難度較大，需要解決許多問題。比如Cache rules的流表項(xiàng)過期之后如何處理，主機(jī)移動帶來的策略變化以及拓?fù)渥兓瘞淼牟呗赞D(zhuǎn)變等問題。雖然DIFANE確實(shí)降低了控制器的壓力，拓展了網(wǎng)絡(luò)規(guī)模，但是其僅在一定程度上提升了可拓展性，無法大規(guī)模地?cái)U(kuò)大網(wǎng)絡(luò)規(guī)模，難以從根本上解決可拓展性的問題。

同樣的，為解決OpenFlow處理首包所帶來的性能不足的問題，DoveFlow[2]也設(shè)計(jì)了自己的解決方案。DevoFlow同樣主張盡可能將包括流表的安裝，統(tǒng)計(jì)信息的收集等IO高消耗的業(yè)務(wù)下放到交換機(jī)上，由交換機(jī)負(fù)責(zé)完成。而控制器負(fù)責(zé)高級的策略計(jì)算和下發(fā)工作。不過論文僅完成了模型建立和仿真分析，并沒有實(shí)際部署。

將控制器的部分高IO消耗的業(yè)務(wù)下放到數(shù)據(jù)平面來處理，是解決SDN可拓展性問題的主要思路之一。這種方法可以實(shí)現(xiàn)不僅可以提升可拓展性，還可以降低網(wǎng)絡(luò)延遲。不過這樣的解決方案難度相對也比較大。

除了通過下放負(fù)載來減輕控制器壓力來提高可拓展性這種解決思路以外，更普遍的解決思路是通過部署多控制器系統(tǒng)來共同實(shí)現(xiàn)網(wǎng)絡(luò)的管理。而根據(jù)控制器系統(tǒng)中控制器的種類異同可以將方案分為分布式控制器和東西向接口協(xié)議兩種解決方案。

較為出名的分布式控制器，當(dāng)屬HyperFlow[3]系統(tǒng), Google的Onix[4]以及開源控制器ONOS[5]。

HyperFlow

HyperFlow是一個基于事件的OpenFlow分布式控制平臺，可以實(shí)現(xiàn)多控制器之間協(xié)同工作。部署HyperFlow分布式系統(tǒng)的多控制器實(shí)例維護(hù)一個共同的全局網(wǎng)絡(luò)視圖。在管理本地網(wǎng)絡(luò)時，控制器無需和其他節(jié)點(diǎn)交互而直接進(jìn)行網(wǎng)絡(luò)管理，從而實(shí)現(xiàn)快速地響應(yīng)Packet_in請求。同時HyperFlow并沒有改變OpenFlow的協(xié)議內(nèi)容，也不會影響已有的應(yīng)用運(yùn)行。與部署DHT不同，HyperFlow不需要改變控制器本身的存儲。在數(shù)據(jù)同步方面也是通過直接推送方式將信息直接推送到其他節(jié)點(diǎn)。

每個HyperFlow節(jié)點(diǎn)都維護(hù)著全局的網(wǎng)絡(luò)視圖，看起來好像管理了全局網(wǎng)絡(luò)一樣，但是只能管理本地的網(wǎng)絡(luò)。交換機(jī)可配置多控制器，從而提供High Availability。一旦某節(jié)點(diǎn)的網(wǎng)絡(luò)視圖發(fā)生改變，這個事件將會發(fā)布給所有訂閱它的節(jié)點(diǎn)。而其他節(jié)點(diǎn)將需要重播(replay)所有已發(fā)布的事件來重新構(gòu)建網(wǎng)絡(luò)視圖，這點(diǎn)將產(chǎn)生大量的同步數(shù)據(jù)。

Onix和ONOS

Onix是google的分布式控制器，其在所有節(jié)點(diǎn)之間維護(hù)了全局網(wǎng)絡(luò)視圖，實(shí)現(xiàn)分布式控制。此外，還定義了一套API，用于定義具體的同步操作。面對不同的場景，比如不同域之間的通信，可制定具體的同步數(shù)據(jù)細(xì)節(jié)來保障網(wǎng)絡(luò)的安全和隱私。Onix支持兩種形式的網(wǎng)絡(luò)拓展：Partition(分區(qū))， Aggregation(聚合)。

當(dāng)網(wǎng)絡(luò)規(guī)模增長到一定程度時，一個控制器無法應(yīng)付全部的網(wǎng)絡(luò)狀態(tài)和流表狀態(tài)的存儲，內(nèi)存上出現(xiàn)瓶頸。那么將網(wǎng)絡(luò)劃分為分別由多個控制器管理的子網(wǎng)絡(luò)可以解決這個問題。所有控制器都共同維持一個網(wǎng)絡(luò)狀態(tài)的數(shù)據(jù)，但是流表狀態(tài)由本地控制器管理，且本地控制器可以在全局拓?fù)渖嫌?jì)算路徑。

當(dāng)網(wǎng)絡(luò)繼續(xù)增大時，一個控制器在全局網(wǎng)絡(luò)上計(jì)算路徑就顯得有些吃力了，CPU資源成為了新的瓶頸。所以可以把多個子網(wǎng)聚合成一個邏輯節(jié)點(diǎn)。而不同邏輯節(jié)點(diǎn)之間由另一個管理全局流量的Onix控制器管理，從而實(shí)現(xiàn)更大網(wǎng)絡(luò)的管理。舉例如，一個很大的校園網(wǎng)里面，每棟大樓都是由一個Onix管理的子網(wǎng)絡(luò)。多棟大樓組成的網(wǎng)絡(luò)可以被抽象成一個邏輯節(jié)點(diǎn)，由管理校際的Onix來管理邏輯節(jié)點(diǎn)組成的邏輯網(wǎng)絡(luò)，從而實(shí)現(xiàn)大規(guī)模網(wǎng)絡(luò)的管理。

此外Onix也針對數(shù)據(jù)一致性等方面做了相關(guān)的部署。然而由于分布式控制器本身數(shù)據(jù)同步數(shù)據(jù)量較大，其需要比較充裕的網(wǎng)絡(luò)帶寬。盡管如此，Onix還是在Google的數(shù)據(jù)中心中起到了很大的作用。

ONOS是一款開源的分布式控制器。與其他分布式控制器一樣，ONOS也構(gòu)建了全局的拓?fù)?，控制器?shí)例也是獨(dú)立管理網(wǎng)絡(luò)。此外,ONOS也可以實(shí)現(xiàn)控制器之間的負(fù)載均衡。在ONOS的實(shí)現(xiàn)過程中，對于不同的數(shù)據(jù)的分布式存儲是不同的。對于分布式集群的master/slaver的關(guān)系等信息采用的是Hazelcast來存儲，而Device,link等內(nèi)容則是通過Gossip協(xié)議來直接發(fā)送。而且發(fā)送形式是單播，而非在節(jié)點(diǎn)之間組播。

ONOS作為一款新興的分布式控制器，在可拓展性方面還是相對不錯的。但是分布式系統(tǒng)的心跳包等大量數(shù)據(jù)需要消耗大量帶寬，使其可能難以適應(yīng)鏈路質(zhì)量不足的場景。

本質(zhì)上HyperFlow也可以部署在異構(gòu)的控制器上從而實(shí)現(xiàn)多控制協(xié)同工作。不過異構(gòu)控制器部分，解決方案的思路主要是通過協(xié)議來消除通信終端的差異性,而HyperFlow并沒有強(qiáng)調(diào)這一點(diǎn)。目前已有的可用于異構(gòu)控制器之間的東西向協(xié)議有SDNi[6]和West-East[7] Bridge協(xié)議。

SDNi

SDNi是華為提出的一種用于處理SDN域之間通信的協(xié)議。在其提交的草案中，定義了SDN域的概念和SDNi如何幫助域之間通信。目前SDNi已經(jīng)在開源控制器OpenDaylight[8]上作為應(yīng)用實(shí)現(xiàn)。SDNi需要在控制器之間交互Reachability、Flow setup/tear-down/update請求和包括帶寬，QoS和延遲等Capability信息。SDNi的數(shù)據(jù)交換可以基于SIP或者BGP協(xié)議實(shí)現(xiàn)，如OpenDaylight中就是基于BGP協(xié)議實(shí)現(xiàn)的?；赟DNi可以實(shí)現(xiàn)異構(gòu)控制器協(xié)同工作，實(shí)現(xiàn)大規(guī)模網(wǎng)絡(luò)的管理，實(shí)現(xiàn)跨域流量優(yōu)化等應(yīng)用。

West-East Bridge

West-East Bridge協(xié)議也是一種支持異構(gòu)控制器協(xié)同工作的協(xié)議。其同樣也是通過訂閱/發(fā)布機(jī)制來完成數(shù)據(jù)的分發(fā)。當(dāng)網(wǎng)絡(luò)視圖發(fā)生變化時，該事件將會被發(fā)布到所有訂閱其數(shù)據(jù)的節(jié)點(diǎn)。為保證數(shù)據(jù)的一致性，其節(jié)點(diǎn)之間為全連接關(guān)系。此外，West-East Bridge還設(shè)計(jì)了虛擬的網(wǎng)絡(luò)視圖，可以滿足某些SDN域?qū)τ诎踩碗[私的需求。

除了以上列舉的解決方案外，還有許多其他的解決方案，但是筆者無法簡單地將其歸類為以上兩種方案，所以在此部分介紹。

Kandoo

第一種解決方案中提到減輕控制器負(fù)載可以提升SDN的可拓展性。而第一種方案是通過把相關(guān)高IO消耗的業(yè)務(wù)下放到了數(shù)據(jù)平面的交換機(jī)上。但是這種方式需要對交換機(jī)進(jìn)行修改，其難度較大。所以在控制平面做文章則成為另一種可選的方案。Kandoo就是一種控制平面的解決方案。Kandoo[9]是一種分層式的控制平面，由本地控制器和根控制器組成。其中本地控制器對網(wǎng)絡(luò)的信息并不了解，僅完成本地的業(yè)務(wù)。而根控制器負(fù)責(zé)完成網(wǎng)絡(luò)范圍內(nèi)的業(yè)務(wù)請求，如路由等等。本地控制器需要運(yùn)行APP detect應(yīng)用來檢測大象流等需要上報(bào)給根控制器的報(bào)文，而根控制器需要運(yùn)行APP reroute應(yīng)用來完成網(wǎng)絡(luò)范圍內(nèi)的業(yè)務(wù)部署。在根控制器完成計(jì)算之后，發(fā)送給本地控制器，由本地控制器完成流表項(xiàng)的安裝。即本地控制器本質(zhì)上只是一個代理，完成了大部分的高發(fā)頻率的本地網(wǎng)絡(luò)事件，而根控制器完成網(wǎng)絡(luò)范圍內(nèi)的業(yè)務(wù)響應(yīng)。從而將全局網(wǎng)絡(luò)事件分?jǐn)偟蕉鄠€本地控制器上，降低對IO性能的要求，從而提升SDN可拓展性。

圖2.Kandoo架構(gòu)圖

DISCO

DISCO[10]本質(zhì)上可以理解為一種和SDNi類似的東西向協(xié)議，但是由于論文中只字不提東西向協(xié)議，所以筆者只能將其放在這部分了。DISCO通過AMQP協(xié)議實(shí)現(xiàn)了控制器之間的數(shù)據(jù)交換，來實(shí)現(xiàn)控制器之間的協(xié)同，實(shí)現(xiàn)跨域業(yè)務(wù)的部署，從而增強(qiáng)了SDN的可拓展性。其實(shí)現(xiàn)原理和SDNi，West-East Bridge基本一樣，不再贅述。

目前針對SDN可拓展性的研究已經(jīng)非?；馃?，對應(yīng)的解決方案也已經(jīng)有不少。從以上的解決方案中我們可以總結(jié)出來可以從把負(fù)載從控制器上offload到數(shù)據(jù)平面和拓展控制平面兩種大的解決思路。在控制平面能力拓展方面，Google的Onix確實(shí)是做得最全面的，包括了是網(wǎng)絡(luò)的分區(qū)和聚合?；旧夏壳癝DN可擴(kuò)展性方面的研究已經(jīng)有了一定的基礎(chǔ)。隨著SDN的發(fā)展，相信后續(xù)SDN的可拓展性方面或者說東西向方面的內(nèi)容將會有更多的研究成果出現(xiàn)，從而推動SDN東西向和可拓展性方面的發(fā)展進(jìn)程，進(jìn)而帶來一個更大的SDN網(wǎng)絡(luò)。