前言
無論你是基于SDN做物理網絡的大二層，還是基于SDN做云計算的網絡支撐。商用的基于SDN產品都有一個不可避免的門檻，就是SDN controller的高可用。
交換機已經失去了對網絡的控制權，控制轉發分離意味著SDN controller需要更加穩固。如果SDNcontroller出現單點故障，這樣整個網絡系統都會失去控制，甚至會帶來不可逆的災難。
在我們設計SDN controller的部署模式的時候，就需要充分考慮SDNcontroller的單點問題。目前也有一種常用的手動去解決SDNcontroller的單點問題，就是HA。
大部分的開源SDN controller都支持HA（如：ODL、Flooldlight），哪怕我們開發設計一個HA模式也不是一件代價很大的事情。HA模式確實可以解決SDN controller的單點故障，但是無法解決SDNcontroller的首包處理的單點性能瓶頸。這也是我們今天討論的重點，分析幾種SDN controller的部署模式。
SDN controller如何做高可用？
在講述SDN controller的部署模型之前，我們還是先了解一下SDN controller的高可用實現原理。有了原理的支撐，對于后續的模型會有更清晰的理解。
其實OpenFlow（>= 1.2）協議本身就支持對交換機的角色管理。對于交換機，SDN controller有Master、Slave兩種角色，并且在同一時間只有一個Master。
不同的角色有不同的權限，當然這個可以通過SDN controller修訂。簡要說Master角色可以接收首包、推送流表、監聽交換機的信息（交換機的ADD、Remove、Port change）等等，而Slava角色只能監聽交換機的信息。SDN controller可以通過OpenFlow協議要求交換機更換角色，SDN controller的高可用就是基于這樣的規則下實現的。假設其中一個SDN controller出現故障，另外的SDNcontroller馬上要求交換機切換角色即可。
SDN controller模型
SDN controller HA模型圖
如上圖：這就是SDN controller HA模型。當Master controller出現故障，Slavecontroller通過心跳線感知，馬上要求vSwitch切換角色。Slave controller變成Master。等故障的controller重啟，角色變回Slave即可。
這個方案有一個明顯的缺點，同一時間只有一個SDNcontroller在工作，這樣整體的網絡規模受限于單個SDNcontroller的首包處理性能。Slave controller的存在無法分擔首包的壓力，這樣的工作態度不太好。
SDN controller AA模型圖
如上圖：這是HA模型的演進版，SDN controller1既是vSwitch1、vSwitch2的Master，又是vSwitch3、vSwitch4的Slave。SDN controller2既是vSwitch3、vSwitch4的Master，又是vSwitch3、vSwitch4的Slave。假設SDN controller1出現故障，SDNcontroller2會接管vSwitch1,vSwitch2。這樣的設計有效地分攤了SDN controller的首包壓力。
AA模式在技術上其實存在幾個難點，第一，SDN controller之間處理心跳以外，還需要知道各自接管的交換機信息。第二，SDN controller之間需要實現負載均衡，假設新的交換機接入進來，需要選擇最空閑的SDN controller接管。第三，自修復功能，假設有交換機脫管了，需要重新接管過來。第四，遠程方法問題，應用層不可能知道哪個Controller現在負責哪個交換機，這時候就需要SDNcontroller實現多控制器之間的遠程方法調用。只要解決這些技術難點，SDN controller AA模型落地不成問題。也可以滿足一定規模的網絡。
竟然AA模型已經做出來的，我們離集群模型還遠嗎？SDNcontroller cluster模型最難的地方是多控制器之間的同步問題。分析一下兩種最常見的SDN controller的同步模型。
自同步模型：
SDN controller Cluster模型
如上圖：AA模型只需要一對一的同步，但是如果N多個Controller之間，就類似與畫星星一樣，這樣模型的收斂時間會變得很長，而且SDN controller之間選舉算法也變得非常復雜。我們需要針對這樣的模型設計高可靠容錯的機制，因為一旦這個模型數據同步出現問題，我們很難排除究竟是哪個Controller出現壞數據。不過只要算法做得足夠高效，并且合理規避風險，自同步模型是完全可以滿足大規模網絡的需求的。SDN controller的擴張性也有足夠高。
統一管理模型（三層模型）
如上圖：既然SDN controller之間的同步如此復雜，我們可以單獨將同步這個功能抽離出來變成一個角色。這個角色負責多Controller之間的同步，而Controller就可以專心負責業務功能，不用過多關系同步的問題。這樣的設計模型我們統稱“三層模型”。也是很多Cluster方案在演進過程中的必經之路。這樣的模型在HP的一個項目中，有見過。自同步模型的問題都在這個方案上得到很好解決。但是Sync Manager卻成為了單點，所以SyncManager需要做HA。假設SDN controller的數量達到一定的量級之后，SyncManager也會網絡收斂的瓶頸。這樣豈不是SyncManager需要做Cluster？四層模型？三層模型在我的觀點上已經是極限了。所以Sync Manager也不是萬靈藥。
我們回到云計算，假設Cluster模型擴張到最大規模也就是在每個NC（計算節點）上運行一個SDN Controller。這時候，其實我們還需不需要做SDNcontroller的角色切換呢？
SDN controller分布式模型
如上圖：SDN controller分布式模型最大的特點是SDNcontroller只負責管理本地的交換機，SDNcontroller之間不存在心跳，假設SDNcontroller1發生故障了，就重啟SDN controller1進程。如果NC宕機了，就遷移VM。這樣也是一個高可用方案。SDN controller之間的數據同步是通過分布式數據庫完成。在云計算中，大量使用的分布式數據庫，技術相對成熟。所以我們不用但是分布式數據庫的可靠性。我們只需要設計好遠程方法調用，讓應用對分布式無感知。這樣的設計SDN controller的首包處理能力會隨著NC的增加而提升。并且如果其中一個實例出現大量的首包（如：DDos攻擊），影響范圍也只是VM所在的NC，這樣我們可以做出很多有效的處理。這樣的模式，我認為是未來SDN云網絡發展的一個重要的分界線。只要在真正意義上，擺脫SDN controller的瓶頸，才能將SDN推向一個產品化之路。
總結
我們分析了很多SDN相關的模型，這樣模式都是在實際的項目場景中，發展演進的產物。我們在設計SDN網絡的過程中，不能只看到SDN的長處，而忽略它的短處。SDN的集中化管理、控制轉發分離特性恰恰是我們設計者的痛點。我們既要原汁原味地保留SDN的特性的同時還需要堅持走高可用、高擴展產品化之路。所以邏輯值集中，模型上分布才是SDN技術的一大精髓。
參考文獻：
https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-spec-v1.3.3.pdf
京公網安備 11010502049343號