精品国产一级在线观看,国产成人综合久久精品亚洲,免费一级欧美大片在线观看

Software Defined Networking是一種控制平面和數據平面分離的可編程的網絡架構，目前已經有許多商業落地案例。在部署SDN時，往往會因SDN控制器性能不足而限制了SDN的可拓展性。因此SDN網絡的規模往往不大。針對此問題，筆者在研究相關文獻之后，總結了相關的解決方案，并通過本文來記錄和分享。

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

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

DIFANE[1]是DIstributed Flow Architecture for Networked Enterprises的縮寫。 在DIFANE架構中，其數據平面的所有數據均由數據平面完成，而控制器僅負責策略的計算，而不會直接響應Packet_in。其通過減輕控制平面的負載的方式，從而增強了SDN的可拓展性。

圖1.DIFANE 架構圖

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

當網絡上線時，控制器通過收集網絡的拓撲信息和主機接入位置信息等計算出Authority rules并分發到對應的Authority switch中。此外，控制器還需要完成粗粒度的Partition rules的計算和下發。Partition rules是由網絡拓撲的具體情況計算出來的粗粒度規則，其告知Ingress switch將無法匹配Cache rules的數據包應該轉發到哪一個Authority switch。當第一個packet到達Ingress switch時，不會選擇上報controller，而是會匹配到低優先級的Partition rules，并轉發到Authority switch。Authority switch負責將其轉發到對應的Egress switch。此外，Authority switch還會將對應的Authority rules推送并安裝到Ingress switch中，作為其Cache rules。之后的packet就可以匹配Cache rules，然后直接轉發到Egress switch，而不需要轉發給Authority switch。在DIFANE架構中，控制器則負責主動預先計算規則并下發，而網絡事件的被動響應則由數據平面的Authority switch完成。

DIFANE的設計使得所有的數據平面的數據都由數據平面處理，而不是緩存在交換機隊列中，再發送給控制器處理。此舉使得絡首包的延遲變小，同時也大大降低了控制器的壓力，進而可以管理更大的網絡。不過這樣的解決方案難度較大，需要解決許多問題。比如Cache rules的流表項過期之后如何處理，主機移動帶來的策略變化以及拓撲變化帶來的策略轉變等問題。雖然DIFANE確實降低了控制器的壓力，拓展了網絡規模，但是其僅在一定程度上提升了可拓展性，無法大規模地擴大網絡規模，難以從根本上解決可拓展性的問題。

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

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

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

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

HyperFlow

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

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

Onix和ONOS

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

當網絡規模增長到一定程度時，一個控制器無法應付全部的網絡狀態和流表狀態的存儲，內存上出現瓶頸。那么將網絡劃分為分別由多個控制器管理的子網絡可以解決這個問題。所有控制器都共同維持一個網絡狀態的數據，但是流表狀態由本地控制器管理，且本地控制器可以在全局拓撲上計算路徑。

當網絡繼續增大時，一個控制器在全局網絡上計算路徑就顯得有些吃力了，CPU資源成為了新的瓶頸。所以可以把多個子網聚合成一個邏輯節點。而不同邏輯節點之間由另一個管理全局流量的Onix控制器管理，從而實現更大網絡的管理。舉例如，一個很大的校園網里面，每棟大樓都是由一個Onix管理的子網絡。多棟大樓組成的網絡可以被抽象成一個邏輯節點，由管理校際的Onix來管理邏輯節點組成的邏輯網絡，從而實現大規模網絡的管理。

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

ONOS是一款開源的分布式控制器。與其他分布式控制器一樣，ONOS也構建了全局的拓撲，控制器實例也是獨立管理網絡。此外,ONOS也可以實現控制器之間的負載均衡。在ONOS的實現過程中，對于不同的數據的分布式存儲是不同的。對于分布式集群的master/slaver的關系等信息采用的是Hazelcast來存儲，而Device,link等內容則是通過Gossip協議來直接發送。而且發送形式是單播，而非在節點之間組播。

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

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

SDNi

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

West-East Bridge

West-East Bridge協議也是一種支持異構控制器協同工作的協議。其同樣也是通過訂閱/發布機制來完成數據的分發。當網絡視圖發生變化時，該事件將會被發布到所有訂閱其數據的節點。為保證數據的一致性，其節點之間為全連接關系。此外，West-East Bridge還設計了虛擬的網絡視圖，可以滿足某些SDN域對于安全和隱私的需求。

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

Kandoo

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

圖2.Kandoo架構圖

DISCO

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

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