早在2015年，品高雲正式上線了BingoSDN v3.0版本，併成為品高雲操作系統（BingoCloudOS）V6.0的雲網絡核心組件。至今三年多的時間裡，BingoSDN v3.0服務了各行各業不同的應用系統，在包括政府、公安、軌道交通、金融、軍工以及教育等行業發揮了其重要作用。聯繫品高雲家的小表妹（ID：pingaoyunzzm）瞭解更多。
不誇張地說，BingoSDN v3.0擁有著非常出色的性能，它的虛擬網絡性能損耗比只佔物理服務器的2%，同時可支持創建13億個VPC，並且經過了權威的第三方測試……（之前我們已經分享了很多關於BingoSDN v3.0的內容，感興趣的讀者可以到通過文末的相關閱讀深入瞭解）。BingoSDN v3.0的成功讓我們對SDN雲網絡的發展之路充滿信心，但同時也給BingoSDN v4.0帶來更高的要求和更大的挑戰。在BingoSDN v4.0的設計之初，我們就在反覆地思考：雲網絡的未來將會怎樣發展？未來的挑戰是什麼？
經過了2年多的打磨，BingoSDN v4.0終於伴隨著BingoCloudOS V8.0的迭代正式上線投入使用，並且已經在多個行業用戶中穩定運行。設計一個滿意的作品真的來之不易，BingoSDN v4.0的每一條血管、每一個毛孔、每一個細胞都是我們親手打造的，希望通過下文，可以分享我們對新一代SDN的一些思考。
本期大咖 >> 林冬藝
從SDN概念誕生以來一直在關注和研究，任職於BingoCloud SDN雲網絡團隊，主要負責雲網絡、雲網絡安全、NFV、高性能雲網絡等的架構與設計。目前，BingoCloudOS產品的SDN相關功能主要來自林冬藝所在團隊 。
跨地域多中心SDN控制器容災問題
隨著雲計算的不斷普及，受物理數據中心的地理條件限制，一雲多中心成為雲計算發展的必經過程，此時，雲網絡跨地域容災則是我們首先要面對的問題。基於此深入思考，我們能否在BingoSDN v4.0中做到整個雲的計算節點在只剩下一臺服務器的情況下也能正常工作？如果實現這一點，雲網絡的容災能力將可以不止提升一個級別。
新型應用架構帶來的衝擊
Docker、K8S、FaaS（Function as a Service）概念的興起，使得網絡的地址空間快速擴張。在過去虛擬機的時代，一臺物理服務器能虛擬出30臺虛擬機就已經很了不起了，但是現在僅憑一臺物理服務器就虛擬出上千個Docker也絲毫都不誇張。同時，FaaS的到來對網絡的響應速度提出了更高的要求：在高併發情況下，要想一秒內啟動上百臺Docker，在函數執行完成後瞬間釋放，對雲網絡的彈性響應速度要求極嚴格，這需要SDN控制器以最快的速度、最短的傳輸距離和最高效的處理方式完成首包的處理下發流表。聯繫品高雲家的小表妹（ID：pingaoyunzzm）瞭解更多。
黑盒網絡問題
我們從BingoSDN v3.0開始就一直堅持使用標準的Openflow協議，並且沒有對協議本身做太多的修改，這令我們的運維同事倍感壓力。因為以前傳統雲網絡Bridge、VLAN、Route、IPtables四件套走天下的模式，在SDN雲網絡面前徹底沒用了——在SDN雲網絡中這些都只是一條一條看不懂的流表規則，而且流表規則與VPC組網邏輯沒有任何聯繫。就是這樣的黑盒網絡，讓許多運維同事需要不少時間來適應。當然，我們做了很多運維的培訓工作以及運維工具來幫助他們，不過我們還是希望BingoSDN v4.0能徹底解決這樣的問題，讓流表一眼就能看明白。
網絡隔離不再只是Subnet
Subnet的隔離方式是我們普遍熟悉的，但不知道大家有沒有發現它有一個弊端：同一個Subnet地址是連續的。我們在想，能不能實現192.168.1.1-3-5-7-是一個Subnet，而192.168.1.2-4-6-8是一個Subnet，並且它們的VLAN或者VXLAN是相同ID，還能通過策略授權指定地址呢？
這樣設計並不是在玩雜技，而是因為我們現實的用戶就有很多這樣的需求，尤其是政務雲用戶。在私有云和混合雲中經常存在專線複用隔離或者特定安全事件的及時隔離等情況，這種需求往往非常麻煩：只能通過物理交換機的ACL策略完成，還有可能遺留很多隱患。如果在BingoSDN v4.0中可以像安全組一樣實現這些，將使得網絡隔離的粒度更細，並且更加友好。
最終我們還是把BingoSDN v4.0做出來了，它完美解決了上述的問題和挑戰，並且現在已經在包括公安行業、金融行業和傳媒行業等用戶中上線使用。我們甚至還在設計與開發的過程中做出了很多新鮮的功能，這也算是BingoSDN v4.0的一些小彩蛋了。
分佈式SDN控制器模型
跨地域多中心容災和新型應用架構對網絡響應速度有著很高的要求，我們認為迫切需要把BingoSDN v3.0的集群模型演進成分佈式模型，這是BingoSDN v4.0最大的變革：在每一臺計算節點上部署一個SDN控制器，本地SDN控制器僅負責控制本地的虛擬交換機，SDN控制器節點之間通過消息隊列同步網絡位置與VPC配置信息，這樣我們就踏上分佈式的道路了。
在消息隊列的選型上，我們花費了大量的精力。我們希望實現的是一個完全分佈式（每個計算節點都是消息隊列節點）的消息隊列，因此Kafka、Redis等集群模式的消息隊列不適合我們這種完全分佈式的模型。如果消息隊列也成為故障單點，那就不是真正意義上的分佈式了。而RabbitMQ的網絡分區以及在分佈式的場景之下暴露出的非常多的問題，讓我深刻地明白為什麼OpenStack會在最新版裡面把RabbitMQ替換掉。
我們認為，消息隊列應該更輕、更穩定、更高效。我們的目標是即使宕機到只剩一臺計算節點時它的網絡依舊正常，我們不想作出妥協。兩個月之後，我們基於ZeroMQ的Socket機制成功重新定義了一套消息隊列模型，這套模型非常輕量級，而且很快。有趣的是消息持久化的機制結合了雲平臺能力，讓它變得有點像迅雷P2P機制，所以經常被同事們調侃這是SDN迅雷。那天以後全世界都優雅了很多——SDN控制器和虛擬交換機更近了，它們通過Unix Socket進行通訊，哪怕物理網絡中斷也不會造成影響，本地通訊和輕負載還令網絡響應速度有了質的飛躍。
SDN可視化運維
可視化運維的動態拓撲圖
其中一條流表的分析視圖
我們團隊從來不按套路出牌，所以我們打造的可視化運維平臺可以看到每一條流表，包括歷史流表，也可以瞭解每條流表推送的原因是什麼，比方說，外部網絡訪問虛擬機、虛擬機發起ARP尋址、安全組沒有授權攔截等等。後續我們還能做到：分析這條流表是SDN控制器的哪一個模塊、哪一行代碼計算出來的流表；還可以看到整個雲網絡的邏輯拓撲與物理拓撲。我們相信，未來SDN可視化運維會成為BingoSDN產品的一個爆點。聯繫品高雲家的小表妹（ID：pingaoyunzzm）瞭解更多。
微隔離
微隔離的功能實現其實並不難，因為我們沒有依賴VLAN或者VXLAN的隔離方式，純粹的標準Openflow流表使得我們控制網絡的粒度可以精細到傳輸層的端口。只不過沒想到的是，當我們剛把測試版本做出來就有了用戶需求，所以我們在BingoSDN v3.0上也支持微隔離功能，目前也已經有部分用戶在使用了。微隔離也算是BingoSDN v4.0的一個排頭兵吧。
寫在最後
BingoSDN v4.0目前已經正式上線了。總的來說，相對於BingoSDN v3.0版本，新版本由集中式架構轉換為控制器下沉至雲節點的分佈式架構，網絡控制處理能力得到了橫向擴展。另外，BingoSDN v4.0增加了對微隔離技術的支持，統一子網和安全組可以進行二次隔離；還可通過SDN仲裁機制保證網絡可用性，支持跨IDC容災以及超大規模組網。基於BingoSDN v4.0的可視化運維平臺，排障更輕鬆，有效幫助用戶提升運維質量和效率。
問題和挑戰從來不會讓我們停下腳步，而是激勵我們不斷向前。未來，我們將繼續升級完善BingoSDN，為SDN雲網絡的發展貢獻一份力量，為用戶帶來更優質的服務與產品使用體驗。
相關閱讀：
聯繫我們
如想了解更多品高雲操作系統 V8.0 或索取產品文檔，請聯繫品高雲家的客服小表妹！添加她為好友，任何需求一鍵直達。
閱讀更多 品高雲 的文章
