原文地址https://www.infoq.cn/article/sdn-and-cloud-network

1.1，什麼是 SDN？

什麼是 SDN？SDN 的官方解釋上提出了 SDN 的三個特性：集中化管理、控制轉發分離、開放的 API。可以這麼說，只要滿足 SDN 的三個特性的，就是 SDN。SDN 是一種理念，一種思想。在我們架構網路的時候，SDN 是一種新的思路。

SDN 的三大特性：

• 集中化的管理：有統一的管理入口。比方說我有 100 臺交換機，對著 100 臺交換機的配置管理，不需要逐個交換機配置，可以通過一個統一的控制器配置著 100 臺交換機。這就是集中化的管理。
• 控制轉發分離：在 SDN 的網路種，SDN 所希望的是交換機應該足夠的“傻瓜”。交換機的功能應該只是匹配和動作（match & action）。裡面的鄰居子系統、ACL 規則、路由、閘道器等功能都應該在交換機上完成，而不是在控制器上完成。當然也是一種理想的情況。也是大部分宣稱自己是 SDN 雲網絡的產品做到的地方。在 Open vSwitch 的 Dragonflow 雲網絡中，其實就把鄰居子系統和閘道器的部分功能做到 SDN 控制器上，主要的目的是為了解決東西流量的分散式以及減少故障域。在 Dragonflow 的雲網絡中還是保留了不少傳統雲網絡的實現。
• 開放的 API：在 SDN 的架構中，開放的 API 成為北向介面。傳統網路的交換機的配置基本上都是 CLI 配置，或者 Netconf 配置，這樣的配置介面很難實現通過軟體控制網路。對於我們的這些軟體開發者來說，如果通過可以對網路程式設計，就需要一個統一的開放的 API 進行呼叫。這也是 SDN 的核心思想可程式設計的網路。

1.2，SDN 有什麼好處？

這個問題其實有很多人問過我，SDN 究竟有什麼好處？有些比較直接會問，用了 SDN 網路效能會不會提升 30%？用了 SDN 之後，會不會多出很多新的網路功能？我的觀點是 SDN 的提出不是一場網路的革命，而是一次網路的發展。架構雲網絡的過程中，SDN 給我們帶來最大的好處是通過 SDN 實現的網路功能所付出的代價會比傳統網路的要小很多。這個代價主要是指這幾個個方面：開發週期、網路複雜度、架構的完整度、網路 IO 路徑長度、冗餘耦合度。

我們很早之前就有考慮將雲網絡和第三方的安全產品整合，提供一套更安全的雲網絡。安全的廠家只要把原來的安全產品做成例項，執行到雲網絡中即可。但是最大的問題是雲網絡，如何將流量引流到虛擬化的安全產品？為了引流我們需要建立更多的 Vlan，需要更多的橋，並且第三方的安全廠家還需要識別我們的例項的遷移日誌，配合遷移做規則的調整，我們也需要開放很多本來不應該開放的 API（提供 vlan、橋的建立、日誌的篩選）。最終這個計劃還是終止了，因為代價太高了。我們的整體網路架構都有大量的改動，同時網路的 IO 路徑增加了近一倍，並且開發週期預計要兩個季度，更重要的是和第三方的整合專案是不應該存在這麼多的交叉開發過程。後來我們的 SDN 雲網絡終於開發完成了。引流的工作集中在 SDN 控制器完成，整體的網路架構基本沒有任何改動。網路 IO 路徑沒有變化。即使例項的遷移我們的 SDN 控制器也能夠識別出來，不需要第三方安全廠家監聽日誌事件。實現這樣的功能一個月就能完成了。這就是 SDN 的最大的好處了。當然這是我們對 SDN 雲網絡的技術實現細節有關係，後續我會專門寫一篇關於品高 SDN 雲網絡的介紹文章，專門講一講這一方面的事情。

傳統的雲網絡

2.1，傳統的雲網絡

傳統的雲網絡：就是基於 Linux kernel 的網路協議棧提供的傳統網路元件實現雲網絡的基本功能。比方說：安全組就用 Linux 自帶的 iptables 實現、子網隔離就用 Linux 自帶的 Vlan 實現、地址轉換就用 Linux 自帶的 NAT 實現、流量控制就用 Linux 自帶的 TC 實現、路由功能 Linux 自帶的 route table 實現等等。再配合一些網路規劃，用其中一兩臺伺服器作為網路節點（雲網絡的出口核心路由器）。最後配合上雲的排程能力。這樣傳統的雲網絡就構建起來的。

傳統的雲網絡確實也存在不少的問題:

• 網路節點的網路業務過於集中，容易出現單點故障。
• 東西南北流量混合，網路質量不高。
• 傳統 Linux 網路協議棧的網路功能捆綁嚴重，資源消耗嚴重。
• Vlan 的子網隔離，數量不足。
• 橫向擴充套件能力差，網路規模難以擴充套件。
• 縱向吞掉效能，受網路節點點單限制。

為了解決傳統網路的這些問題，其實很多企業、開源組織也是付出了不少的努力。說到底其實最關鍵的就是把網路節點的業務功能下沉到計算節點（分散式的虛擬化網路）。當然還有其他的問題，這是不會這麼快暴露出來。

2.2 Open vSwitch 雲網絡之路

前段時間看了《通向高可用與分散式的 OpenStack 網路之路》。我得到很多的啟發，深深地體會到雲網絡之路確實艱辛並且曲折。我對比了 Open vSwitch 的發展之路和品高的 SDN 雲網絡做了一些分析。如下圖：

一個成熟的商用雲網絡有一個准入條件就是高可用。Open vSwitch 在 Neutron L3HA 版本中實現了的 HA。但是在後續的幾個版本中，因為架構上衝突 Neutron L2POP & ARP Respondar 、DVR、Dragonflow 的版本中 HA 就無法相容了。Open vSwitch 的發展之路總結起來就是把網路節點上網路功能（FW，Gateway，NAT，ROUTE，DHCP 等功能）下沉到計算節點。也是提高為了網路容災能力。不可否認 Open vSwitch 是一個成功的產品，目前很多雲廠商也是在 Open vSwitch 的基礎上實現自己的雲。

SDN 的雲網絡

SDN 的提出確實給了我們很多的新的想法。首當其中的想法就是：如果雲網絡是通過 SDN 實現的，是不是可以解決傳統雲網絡難以解決的問題呢？對於一個新的技術，我們必須要有足夠的寬容度。我們的做法是通過 SDN 實現和傳統雲網絡一樣功能的雲網絡，不要求 SDN 去突破效能，創造新功能。我們和 Dragonflow 不同，我們不是部分功能使用 SDN，而是全部網路功能都通過 SDN 實現。這想法確實有點瘋狂，但是可行性上是完全沒有問題的。

我們制定了一些 SDN 的要求：

• 擺脫網路節點。
• 不使用 Linux 網路協議棧自帶的網路元件。
• 計算節點使用 Open vSwitch 作為分散式虛擬交換機。
• 使用 SDN 控制器，將全部的雲網絡業務功能都集中在 SDN 控制器。
• SDN 控制器和 Open vSwitch 的通訊使用 OpenFlow 協議。
• SDN 控制器叢集高可用。

在開發的過程中，我們深刻地體會到 SDN 的強大之處。我們不僅僅完成了我們當初制定的要求，我們也通過 SDN 帶來了很多新的網路特性。隱藏式分散式虛擬化閘道器、例項遷移規則不用重新配置、網路功能可熱插拔、網路業務的疊加不會增加 IO 路徑、網路視覺化、ARP 預處理以及 ARP 預填充等等。所有網路功能都在 SDN 控制器，所有網路規則都是按需分配自動超時，控制器叢集高可用。後續我會和大家分享一下 Bingo SDN 的網路功能。

SDN 的雲網絡開發過程中我們也確實遇到了很多問題。比方說，OpenFlow 協議對一些網路功能功能的不支援，Open vSwitch 中有一些 Bug，SDN 網路的新建連線效能低，SDN 控制器叢集高可用等等。最後我們還是突破這些問題，後續我會和大家分享的 Bingo SDN 的遇到的問題和解決方法。