大牛哥的話：此系列意在給各位技術達人分享牛逼的技術干貨，以及介紹身懷干貨的技術大牛們，給愛好者們提供技術交（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

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

本文系SDN實戰團微信群組織的線上技術分享整理而成，原文來自 SDNLAB。

本文鏈接：http://www.sdnlab.com/16219.html

微信公眾號：SDNLAB（id：SDNLAB）

品高云經授權轉載發布。