技術乾貨|品高雲的SDN實踐

大牛哥的話：此係列意在給各位技術達人分享牛逼的技術乾貨，以及介紹身懷乾貨的技術大牛們，給愛好者們提供技術交（si）流（bi）的平臺。今天，大牛哥給大家介紹一位SDN達人，聽聽他的分享——品高雲的SDN實踐。

分享嘉賓

林冬藝從SDN概念誕生來一直在關注和研究，目前在BingoCloud SDN雲網路團隊任職，我主要負責雲網路、雲網路安全、NFV、高效能雲網路的架構與設計。現在BingoCloudOS 產品的SDN相關功能主要來自我們團隊出品 。

分享正文

在講SDN雲網路之前，我們先來回顧一下，傳統的雲網路。先來一張圖（自己畫的）：

傳統的雲網路我相信大家一定非常熟悉。我簡單介紹一下傳統雲網路的一些特點。

特點：絕大部分網路功能都是沿用Linux原生自帶的網路元件完成。網路功能的控制權分散。網路壓力集中在CC（Network Node）上，這個網路節點它的壓力是非常巨大的，兩個不同子網的虛擬機器之間的訪問需要經過網路節點，外部網路訪問虛擬機器需要經過網路節點，虛擬機器訪問外部網路需要經過網路節點，這樣東西南北各方向的流量都要經過這個網路節點。並且CC（Network Node）的網路控制器是建立在VLan的引流之上，缺乏高可用性的網路處理功能，而它的效能又決定了整個雲網路的效能，同時這個還存在單點的風險。

接下來，我們來說說Bingo SDN的網路模型。大家可以對比一下與傳統雲網路的差異性。

同樣甩上特點：遵循ONF（open network foundation）的SDN標準，NC（Node Compute）完成所有的網路流量的處理，包括：Route、NAT、Security Gourp、QOS、Subnet、VPC、ACL、VPCPeerIng。整體的網路架構設計中，不存在Network Node。SDN controller支援Cluster mode，Cluster mode支援Load Balance 和 HA。

大家在Bingo SDN中，看到的所有云網路的業務功能，基本都是通過OpenFlow協議實現的。這樣做有什麼優點呢？我們一一細說。

優點：統一的高效集中化管理，SDN controller可以感知整體網路的情況。擺脫臃腫的Linux network stack元件。擺脫Network Node的單點效能瓶頸，網路高可用、高容災性、高擴充套件性。

接下來從四點開始講Bingo SDN：1）Bingo SDN貼合品高雲的網路功能

2）Bingo SDN 的安全隔離

3）Bingo SDN的效能優化

4）Bingo SDN的高可用性設計

我們先來看看BingoSDN的業務功能：

簡單解析一下：

l Security Group：充當例項的虛擬防火牆以控制入站和出站流量。

l Subnet：是VPC內的IP地址範圍。可以在選定的子網內啟動雲資源。

l ACL：是一個可選安全層，可作為防火牆，以控制進出子網的資料流。可以設定網路ACL，使其規則與安全組相似，以便為VPC新增額外安全層。

l RouteTable：中包含一系列被稱為路由的規則，可用於判斷網路流量的導向目標。

l VPC：的私有子網內啟動的例項無法與Internet通訊。可以選擇使用公有子網內的網路地址轉換(NAT)例項來讓私有子網中的例項連線到Internet，以及拒絕接收由Internet中其他使用者的入站資料流。

l NAT：可以通過閘道器與外部非VPC網路通訊。通過Internet閘道器，例項可穿越雲網路邊界而連線到Internet，前提是例項要有一個公有IP地址。

這些功能都在SDN controller中實現。因此規則的增加只是記憶體的消耗，不會真實地影響到NC的網路IO。

接下來是分散式的QOS（東西南北分離的QOS）

我們做一下對比：傳統網路的QOS：因為NAT發生在網路節點上，所以QOS只能在網路節點處理的。網路節點的QOS處理存在單點效能瓶頸。並且東西向的QOS難以實現。

Bingo SDN的QOS：Bingo SDN的NAT發生在計算節點上，所以QOS的處理可以分佈到各個計算節點上處理。並且Bingo SDN可以更加首包分析資料流是東西向還是南北向的。通過規則的下發，將東西向和南北向流量區分到不同Queue上。這樣Bingo SDN的QOS不僅可以做到對南北向分散式的QOS，同時也可以做到的東西向分散式的QOS。

對於一個雲網路，網路安全隔離也是我們重點考慮的問題。

Bingo SDN的網路隔離是基於租戶的網路隔離

無論是Vlan隔離，還是Vxlan隔離，他們都是需要做資料包疊加。Vlan疊加一個Tag，Vxlan需要疊加一個四層包頭。而Bingo SDN的網路隔離是直接通過OpenFlow協議的規則完成的。而且隔離的資訊完全記錄在SDN Controller的Memory Key Store DB中。這樣Bingo SDN的租戶隔離的不受數量的限制，只要記憶體放得下，SDN controller都可以處理。Bingo SDN構建了一個平行化的網路空間。租戶的隔離不會增加NC（Node compute）的IO壓力。

Bingo SDN在實現防火牆的功能的時候，並沒有用到傳統的Iptables。而是通過OpenFlow協議實現的一套。分散式虛擬化Security Group/ACL （靈活多層次化安全保護）先來個圖：

在大規模網路中，如果將龐大的Security Group規則通過靜態配置到計算上節點上，對整個雲網路會造成非常嚴重消耗。同時例項遷移的過程，必須將對應的Security Group規則一同遷移。 遷移的過程還需要考慮解決規則的合併帶來的衝突的問題。

雲網路Security Group是保護物件是VM，但是在某些場景下，使用者希望通過ACL方式保護整個Subnet。

Bingo SDN希望Security Group/ACL規則是按需分配的，假設一個VM沒有發生任何流量。這樣是沒有任何網路規則的，只有在流量發生的時候，SDN controller才會下發規則，並且OpenFlow規則可以實現Security Group /ACL的規則合併。這樣帶來兩個好處，第一，規則數量會減少。第二，VM遷移，規則無需遷移。

Bingo SDN如何將Security Group/ACL配合使用呢? Security Group是White-list帶狀態， 而ACL是WB-LIST，無狀態的。

在雲網路安全中，是需要專業的同人一齊來助力。Bingo SDN的雲網路安全是支援第三方安全廠家的虛擬化產品整合。

我們簡單談談雲網路安全。雲網路的安全包括三個方面：1）邊界網路安全性，2）內部網路安全性，3）內部網路健全性。邊界網路的安全性可以通過硬體防火牆、硬體入侵防禦保證。但是雲的內部網路安全、雲的內部網路健全單靠外部的硬體是無法結局的。

如上圖：一個雲內部的例項因為軟體長期不更新，導致被黑客入侵了。這樣這個時候可以直接攻擊/感染其他例項、GW、資料中心。

Bingo SDN的雲網路整合了分散式的入侵防禦系統，以及分散式的漏洞掃描系統。可以有效地保證雲內部網路的安全性和健全性。值得一提的是Bingo SDN的雲網路安全系統是支援第三方的安全廠家接入。如山石網科、藍盾、深信服等。和山石網科的整合專案已經落地了。主要整合的產品有云格、和雲界。

接下來談談Bingo SDN的網路效能優化。

第一個，DVGW（零消耗的閘道器）

不同的Subnet之間需要有獨立的Gateway作為Subnet出口。在大規模網路中，存在大量的組網，同時需要大量的閘道器。這時候gateway到底在哪裡？在傳統的雲網路是把Gateway部署在的CC（Network node）上，這樣很容易造成單點故障，同時本身閘道器將成為整個雲網路的效能瓶頸。同時Gateway也是黑客攻擊的一個重點物件。

Bingo SDN在考慮Gateway的處理，希望Gateway是隱藏的、虛擬的、分佈的。這個Gateway沒有真實的載體。我們再也不用擔心Gateway會被攻擊了，因為根本沒有Gateway，此外Gateway也不會存在單點，Gateway的資源消耗接近於零。

我們在研發SDN雲網路的過程中，明確Gateway是可以通過OpenFlow協議虛擬處理。VM只是被欺騙而已。

第二個，無連線跟蹤的NAT （高效的網路處理能力）

傳統網路的NAT：NAT是公有IP和私有IP之間互相轉換的有效方式。傳統網路的NAT必須依賴核心網路協議棧的ConntectTrack。Linux Networkstack的ConntectTrack是一個非常消耗計算效能的功能模組。在大規模的雲網路下，NAT對網路效能有很明顯的消耗，同時ConntectTrack也很容易被成為網路攻擊的物件。

Bingo SDN的NAT：

Bingo SDN的NAT是無連線跟蹤的NAT。豐富的OpenFlow協議可以模式實現一對一的NAT。NAT的過程是在二層網路全部處理完成，沒有經過ConntectTrack。

第三個，L2 POP & ARP responder （感知網路，提升網路質量），這個命名方式是借用OpenStack命名方式，大家比較好理解。

雲網路的扁平化，最大的效能問題就是廣播資料等垃圾資料對網路的質量帶來的巨大影響。容易形成廣播風暴。為此，Bingo SDN對網路質量的保證做了很深入的優化。通過Bingo SDN的網路的學習能力與預判能力，把廣播包做一次攔截，直接通過流變把資料包傳送到指定目標。保證有效的網路流量能高效的轉發。

到了這裡，我相信大家可能會有一個疑問。如果SDN Controller當機了，是不是整個雲網路都會出現癱瘓呢？還有 SDN Controller的處理能力能不能支撐大規模的雲網路？

接下來就是Bingo SDN的高可用性，以及叢集化模式。

控制器叢集並高可用（專利保護）

集中化的控制不可避免的一個問題就是高可用。假設Bingo SDN controller出現異常崩潰了，這樣會直接影響到整個雲網路不能執行。甚至連管理IP都無法訪問。如何保證集中化控制的高可用，這也是一個值得研究的課題。

解決方法：

1、secure mode。在openvswitch br0配置了secure mode，加入openvswitch 和控制器失去了連線，openvswitch會保持原來的flowtable繼續工作。這樣即使Bingo SDN controller當機了，雲網路原來的網路連線也不會斷開。

2、Bingo SDN controller的叢集排程能力。controller當機之後，它的工作會由其他控制器接管過來，有因為openvswitch 配置了secure mode的關係，Bingo SDN controller的叢集排程能力可以是無縫切換。值得一提的是，這項技術的專利目前已經公告，編號（33384、38231）。

Q &A

Q1：對使用者來說，會看到多個Controller嗎？

A1：我們SDN controller會獨立的介面。在介面中可以看多個Controller。但是VM是無感知的。

Q2：控制器基於什麼開發的？

A2：是我們自主研發的產品。

Q3：請教一下nat 在哪裡處理？效能咋樣？

A3：NAT是在Openvswitch上處理，我們在Openvswitch上做了優化。效能需要看伺服器的硬體效能。

Q4：這個控制器叢集有什麼特點啊？我看現在很多人都在研究叢集，有什麼區別嗎？

A4：我們的控制器叢集，不存在一個統一的中央管理器。只是SDN controller通過私有協議做HA。資料同步走分散式資料庫。

Q5：控制器後端資料庫剛說了用了記憶體資料庫，那neutron與控制器資料如何保持一致和災難恢復？資料庫是否也是叢集？

A5：資料庫是分散式資料庫。

Q6：這個控制器叢集採用什麼分佈結構？垂直結構還是水平結構？

A6：是水平結構，可以橫向擴充

Q7：大規模部署時，走網路節點存在效能問題，一般情況下網路節點大約可以承受多少VM，效能不受影響？

A7：我們的Bingo SDN不存在專門的網路節點。傳統網路的VM的限制，是網路節點的效能、還有Vlan數量的限制。

Q8：這些控制器之間怎麼實現通訊的？使用的是什麼協議？

A8：多SDN controller的通訊協議，是我們自定義的協議。基於VRRP的二次開發。

Q9：品高的SDN controller可以同時控制的openflow交換機數量有上限嗎？

A9：一個SDN controller的控制上有上限的。 最多不超過1000個。我們多個SDN controller是負載均衡的。

Q10：你們一個控制器能控制多少個OVS？多控制器是分域控制麼？packet_in和flow entry install處理效能一個控制器有多少？

A10：目前不支援分域控制。一個控制器的處理效能5kpps。

Q11：除了ovs，支援其它帶openflow功能的交換機嗎？對ovs擴充套件的功能不能使用的話，整個架構會有問題嗎

A11：Cloud 硬體的交換機目前和Pica8的SDN交換機整合過。

Q12：一種多少種flow？用了幾級pipeline？控制器只有這一級麼？

A12：目前的table分佈，是三級。控制器只有一級。

Q13：我想了解山石網科在你們整合方案中雲格和雲界的工作原理，謝謝。

A13：主要是Bingo SDN做了引流。他們做專業的分析，然後反饋給雲平臺。

Q14：虛機在br-int上會打上localvlan，你們通過什麼資訊來識別租戶？

A14：MAC地址。

Q15：既然都是依靠flow entris，那怎麼知道一個switch可以容納多少flow entries？有具體的數字嗎？

A15：我們實測，一個switch最大的Flow entries能到3萬。當然controller也有保護機制。

Q16：請問第三方安全產品具體是如何接入租戶網路呢，通過部署到虛擬機器還是直接部署到硬體呢？

A16：通過虛擬機器的方式接入。

Q17：NC是分散式的，那最終到公網的出口應該遠低於NC的數量，多鏈路物理交換機支援？

A17：這個是支援的。

Q18：像保護vm流量的sg規則和保護子網的acl規則都是通過odl下發流表規則到ovs交換機上，而且好像還能動態設定，方便遷移，那vm ovs controller間是如何協調實現的？

A18：vm 和 ovs 其實就是 virtio的連結，沒有特別的。ovs 和 controller通過OpenFlow連結。關鍵的協調者還是 SDN controller。

Q19：我以為租戶網路是通過vlan，vxlan，gre來實現的隔離，剛才有提到通過sdn控制器通過of協議規則實現租戶隔離，大致實現概念是什麼？

A19： 我們的ovs本身的網路是不同的。和傳統的二層不太一樣。大致的實現，其實在SDN controller知道所有網路的佈局。通過OpenFlow協議配置互聯。

Q20：出外網的SNAT是建立VM時靜態生成的吧？每個VM針對外網都有一個IP+port，出外網的查表有沒有效能問題？

A20：SNAT是動態的。我們的NAT是 IP一對一NAT。查表必然存在效能損耗。我們通過Bingo SDN優化Flowtable的粒度，減少規則的產生。

Q21：在Controller故障切換，特別是Controller都故障時，因為secure mode，轉發還繼續，可能生成流表，等Controller OK後，怎麼做Controller和OVS的資料平滑，平滑的思路是？

A21：如果SDN 都故障了，拿新建連結無法進行。OVS的首包無法上傳。等SDN controller重新接管之後，新建連結恢復。這裡的新建連結泛指首包。

Q22：就是preactive和reactive的概念，可以在需要時再下發，不過如果reactive用的多了，控制器壓力會不會太大？

A22：會有壓力的，我們使用S&D flow的方式，動態和靜態流表會配合。同時如果是惡意的首包，我們會將限制。同時我們的Flow table是可以匹配多個流的。

Q23：有宣傳的案例嗎？

A23：www.bingocloud.cn上有案例。案例如：廣州市電子政務雲，互聯港灣公有云，招商銀行，南車，國藥集團等。

相關閱讀：

商用SDN必經門檻：SDN Controller的高可用性研究（附demo）

品高雲SDN概述淺談SDN&SDN控制器 | 品高雲公開課

年度熱詞之——SDN

品高雲：越開放，越安全 | 合作伙伴特輯.

本文轉自d1net（轉載）