你知道嗎？當你部署IaaS云計算平臺時，就已經在應用SDN了。你知道嗎？云計算平臺可以在vSwitch和physical Switch之間無縫切換。你知道嗎？當前的云計算平臺的網絡部分有很大的優化空間。本文就帶你了解這一切。

　　一、沒有SDN，就沒有云計算網絡

　　SDN起源于校園網絡，發揚光大于數據中心。但現在看來很多人對后一句話并沒有真正理解，如果你不服氣，你能回答我這個問題嗎：為什么說SDN很適合數據中心？我相信很多人對此都不甚了解。我這么說有一個依據，因為工作的關系，我跟國內不少做云平臺的技術和管理人員聊過，包括提供公有云、私有云服務的公司以及企業內部私有云網絡的研發和運維部門 的員工，有很多人跟我說過這樣一句話：我們目前還沒有開始使用SDN，但正在研究，也許以后會考慮吧。這句話暴露了當前很多從事云計算網絡研發和運維的技術人員，對SDN在云計算網絡中的應用并不清楚。

　　實際上，當你的數據中心在部署云計算平臺（如OpenStack）時，就已在應用SDN了。先來看看OpenStack的網絡組件Neutron的整體架構（如圖1所示）。

　　這個架構，邏輯上可以分為三個部分。最上面的一部分是OpenStack的控制平臺，它通過用戶操作直接或者間接向網絡組件Neutron發送標準的命令。 第二層是Neutron組件，它通常是位于一個獨立的控制節點上（一臺服務器），它有一套標準的API對應上層應用發給它的每個命令，這些API包括 create_network、create_port、create_subnet等創建多租戶網絡以及創建Firewall、Load Balancer等各種業務的API。這套API從SDN的架構來看屬于北向接口。在Neutron組件內部有很多個不同的插件（plugin），這些插 件大多數都是vSwitch插件，例如OVS、Linux Bridge和OpenFlow Controller等，也有部分硬件交換機插件，目前已經存在的包括Cisco、Arista和Mellanox，相信后面還會有公司會提交。用戶可以 選擇自己的網絡使用哪種方式，然后選擇相應的插件，這些插件會處理Neutron API調用，將它們轉換為每種插件對應的switch所提供的API調用，然后通過各自定義的方式，發消息去調用虛擬交換機或者物理交換機提供的API， 這套API從SDN的架構來看屬于南向接口。

　　我們再回過頭來看看SDN的定義。SDN有很多屬性，每個人理解都不同，正是因為如此，所以很 多人對于某一項技術是否是SDN看法不同。實際上，有很多屬性是偽屬性，它們并不影響對某項技術是否是SDN的判斷，比如是否用了OpenFlow，是否 有標準化的編程接口，是否使用了物理交換機，都跟是否是SDN無關。在我看來，SDN有三個核心屬性可以用來判斷一個技術是否是SDN，這三個屬性包括控 制與轉發分離、開放的編程接口、集中化的網絡控制（關于這點會有歧義，這里集中化網絡控制，并不意味著Controller必須是集中式架構，也可以是分 布式的，只是說，所有參與控制的Controller，在被控制的交換機看來，邏輯上只有一個）。

　　然后我們再來看一下 OpenStack（別的云平臺也一樣）是否符合這三個要求。

　　第一，OpenStack架構中，控制面都是在OpenStack邏輯中（圖1中的第一層和 第二層），而轉發面則在虛擬交換機或者物理交換機中，絕對的控制與轉發分離。

　　第二，無論是南向還是北向，都有開放的編程接口。

　　第三，集中化的 OpenStack控制平臺控制著網絡中多臺服務器和交換機。所以無論從哪個方面看，OpenStack都是標準的SDN架構，OpenStack就是一 個超級Controller。

　　可以說如果沒有SDN的理念，就沒有OpenStack，你能想象交換機（物理或者虛擬）如果不提供編程接口 出來，OpenStack怎樣靈活控制網絡嗎？特別是網絡虛擬化的引入更是離不開SDN的協助（但網絡虛擬化不等于SDN，不要搞混了）。而SDN確實為 包括OpenStack在內的云平臺提供了無可替代的便利，讓云平臺的自動化操作成為可能。所以現在可以回答最開始的問題了：為什么說SDN非常適合用在 數據中心？其實更準確地說，是適合部署了云計算網絡的數據中心，因為云計算網絡要協調的資源非常多，引入一個業務要執行的操作非常復雜，靠手工去操作，一 方面容易出錯，另一方面耗時太長，所以需要借助工具進行自動化部署，而使用了SDN的云管理平臺使得這一切成為了可能。以后如果再有人問你SDN到底有什 么用，有什么是SDN能做而傳統網絡設備做不了的，給他講講這個例子。

　　但為什么還是有很多做云計算平臺的人不認為自己使用了SDN呢？我歸 納了一下，大致有三種原因。

　　第一種，這些人不了解OpenStack Neutron的架構和工作原理，自然就不清楚。就像我在沒有深入研究Neutron之前，也不清楚這一點。

　　第二種，很多人潛意識里面覺得沒有用到 OpenFlow，就不能算用了SDN。前面提到，用不用OpenFlow并非是否是SDN的判斷依據，因為OpenFlow只是SDN的其中一種實現方 式。

　　第三種，有人潛意識里面覺得我都用的是OVS，沒有涉及到物理交換機，就覺得不能算是SDN，或者是覺得沒有全網都用SDN，只是在網絡邊緣用到了， 不能算是部署SDN了。這一切都是誤解，歸根結底還是屬于對SDN的本質或者OpenStack架構看得不透徹。

　　對于云計算網絡的用戶來 說，他們看不到SDN，但這并不代表他們沒有享受到SDN帶給他們的好處。現在大多數公有云平臺的用戶都是自助服務的，他們自己創建虛機，自己創建虛擬網 絡，自己創建虛擬路由器，自己創建防火墻等，誰在底層支撐著這些動作的順利執行呢？是SDN架構！沒有SDN，就沒有這一切！SDN的最高境界就是用戶在 享受著SDN帶來的便利卻并沒有意識到自己使用了SDN。

　　二、用物理交換機取代虛擬交換機？

　　云計算網絡目前還處于發展的初級階段，為了支持多租戶網絡和支持VM的可移動性，網絡虛擬化被廣泛使用，包括基于VLan的、基于VxLan和基于GRE的。

　　目 前絕大多數網絡都使用虛擬交換機（vSwitch）作為網絡的邊緣，最著名的就是Nicira公司發起的開源虛擬交換機項目OVS。之所以vSwitch 被大量用作網絡虛擬化的邊緣，跟VMware等軟件公司的大力推動密不可分，這涉及到他們的利益，也涉及到網絡的控制權之爭：究竟是數據中心的系統運維團 隊控制虛擬網絡還是網絡運維團隊控制虛擬網絡？以Cisco為代表的傳統硬件廠商極力反對VMware的這種做法，理由包括網絡可視化（Network Visibility）以及性能都是大問題，特別是性能問題。

　　但反對歸反對，很多云計算網絡的管理員有了先入為主的思維模式，如果有人讓他 們切換到使用物理交換機，他們會普遍提出一堆問題，包括以下幾個很典型的：會不會被鎖定到特定的廠商身上？物理交換機能有虛擬交換機那么靈活滿足各種需求 嗎？我能像控制虛擬交換機那樣方便地控制物理交換機嗎？會不會增加網絡成本？

　　盡管如此，很多人確實也都同意，使用虛擬交換機，例如OVS，確實有很多性能問題，這是使用物理交換機的方案最吸引人的地方，順帶著還有可擴展性（云管理平臺要控制的虛擬網絡節點太多）。所以現在問題就變成了：我知道使用物理交換機有這樣的好處，但你怎樣解決上述顧慮？

　　其實OpenStack的Neutron plugin機制特別是最新版（Havana）引入的ML2 plugin已經給出了答案。前面講過，Neutron向上提供了一套標準的編程接口，這套接口獨立于任何虛擬或者物理的交換機。對管理員來說，根本不需 要關心底下用的是誰的交換機，虛擬的還是物理的。對于數據中心系統研發部門的工程師來說，他們可以通過plugin機制引入多種交換機，虛擬的或者物理 的，前提是這些交換機必須能支持Neutron向上提供出那些API來，如果無法支持，自然就不會出現在我的采購列表里面，而支持了之后，如果以后因為某 些原因想換掉了，也很簡單，只要換用另外一個交換機的plugin就可以了。這樣第一個廠商鎖定問題就沒有了。特別是Havana版本引入的ML2 plugin機制，允許一個OpenStack域內同時支持多種交換機的plugin。這樣只要管理員愿意，甚至都可以有的節點使用虛擬交換機，有的節點 使用物理交換機，而且可以是不同廠家的，唯一的前提就是這些交換機必須支持通用的Neutron API，這是北向接口標準化的好處。

　　第二個問題，物理交換機能有虛擬交換機那么靈活滿足各種需求嗎？其實對于特定的場景，這是個很隱蔽的偽命題。一提到靈活性，誰都想要，而且最好是無限靈活。但 如果有人問管理員，我可以滿足你的場景中所有的實際需求，但無法提供任意不受約束的靈活性，你要任意靈活的話，需要付出代價，你要不要？我相信絕大多數理 性的管理員都不會要求任意靈活，因為超過需求之外的靈活，是無意義的，而你要為這些無意義的事情付出代價。另外，在有了SDN的機制，交換機可以向上提供 編程接口而不是命令行之后，特別是有了OpenFlow之后，一些交換機特別是為SDN優化過的交換機已可以滿足絕大多數甚至全部云計算網絡的需求了。退 一步說，不能滿足需求的交換機，根據上面第一點，不會進入采購列表。

　　第三個問題，我能像控制虛擬交換機那樣方便地控制物理交換機嗎？在 SDN控制與轉發分離的架構下，管理員通過云平臺控制的永遠都是直接的北向接口，那是與設備無關的。設備的差異性都被底層的實現給屏蔽掉了，如前所述，只 要底層設備能夠提供足夠的南向接口，通過換不同的plugin，OpenStack就可以控制不同的交換機，包括物理交換機。

　　第四個問題， 會不會增加我的網絡成本？無論哪種方案，TOR交換機總是需要的。現在并不需要增加新的交換機設備，而只是要讓原來的TOR交換機支持SDN方式或者換用 能支持SDN的交換機充當TOR。當然，客戶都有保護已有投資的需要，往往不想把現有設備替換掉，這也沒關系，前面講過，OpenStack Neutron ML2的架構允許網絡中有的網絡節點是虛擬交換機，有的是物理交換機，所以想保護已有投資就變得很簡單了，只需要在新增節點上用云平臺來控制SDN物理交 換機就行了，原有的節點仍然是控制虛擬交換機，這樣就可以讓整個網絡平滑引入物理交換機作為云平臺控制的網絡節點。

　　三、虛擬交換機的性能需要優化嗎？

　　前面講這么多，其實主要是想要說明，如果云計算網絡管理員想要從虛擬交換機切換到物理交換機的話，是很容易做到的，不會有什么損失。但接下來網絡管理員馬上就會問：為什么要切換？有什么好處？答案有多個，主要的兩點是網絡可視化和網絡性能。

　　網絡可視化的問題相對好分析，容易理解。因為如果在Hypervisor上做了Tunnel封裝，報文送到TOR交換機上時，交換機已經看不到用戶原始報文了，物理網絡就很難對原始報文做統計和應用各種策略。而如果Tunnel封裝在TOR上面做，則沒有這個問題。

　　而對于性能問題大家的看法可能各異，大體可分為三類：

　　第一類是覺得沒有什么性能問題；

　　第二類是覺得有，但還可以忍受；

　　第三類是覺得已到了影響業務、無法忍受 的地步了。

　　我相信他們講的都是他們所看到的事實，為什么結果迥異？我分析過，基本上前面兩類，要么是仍然處于試驗階段，還沒有大業務的壓力，要么是已正式 部署，但網絡規模不大或者網絡內的業務流量壓力不大，當然我也不排除有的人技術能力特別牛，把性能優化到了極致。而第三類，則是已經有很大業務量部署在生 產網絡中了，或者是用充分的測試手段模擬過實際的業務。第三類的典型例子就是國內的云服務提供商UCloud，他們有大量實際用戶（很多是游戲客戶）租用 了他們的公有云網絡，業務量很大。和AWS等云計算平臺一樣，網絡處理會占用計算資源，帶寬損耗也很大。

　　另外一個云服務提供商 99Cloud也曾經做過這樣的實驗：先是用iPerf進行大流量測試，使用vSwitch帶寬大概能到800多MB，后來在iPerf發包的同時，用迅 雷下載模擬實際網絡流量，帶寬馬上降到了500多MB，有高達300MB的帶寬被損耗掉了。所以結論就是，虛擬交換機肯定有性能問題，需要優化。就算是對 于那種技術特別牛，能將軟件優化做到極致的人，他也無法否認，你再怎么優化，網絡處理也要占用計算資源，而按道理網絡只是工具，計算才是核心價值。

　　前面是定量測試，下面我們來進行一些理論分析。現在服務器的性能這么強勁，還有網卡加速，為什么虛擬交換機還有性能問題？我分析主要有以下幾個原因。

　　vSwitch做Tunnel加封裝和解封裝時，報文在內存中的移動和拷貝會影響性能。

　　網卡中的TSO是可以對TCP報文進行分片加速的，但一旦vSwitch給報文加了VxLan或者GRE Tunnel，網卡一看不是TCP報文，就不會進行分片加速了。這對性能損耗也比較大。

　　軟件中的流表查找消耗比較大，特別是在流表數量比較大，TCP短連接比較多的時候。

　　圖2是使用虛擬交換機OVS的OpenStack網絡架構。

　　四、云計算網絡性能優化方案

　　針對上述產生性能問題的原因，可以從以下幾個方面來對云計算網絡進行優化。將Tunnel加封裝、解封裝的功能Offload到支持SDN的TOR交換機上，這樣一方面去掉了服務器上加解封裝的開銷，另外更重要的是網卡仍然可以通過TSO做TCP報文分片加速。

　　所有的流表都是預先加而非動態報文學習，減少Flow學習帶來的沖擊。同時通過合理地設置默認流表項（Default Entry）來有效減少流表項數量。有人對流表為什么可以預先加不理解，其實很簡單，云計算平臺掌握了所有的信息，包括一個租戶有多少個VM，每個VM都 掛在哪個交換機的哪個端口下面，每個VM的MAC和IP各是多少，默認網關是什么，同一個租戶之間VM的通信使用哪個Tunnel，需要對某個VM應用何 種策略等等。有了這些信息，就足以構建起轉發面所需要的流表，既然能預先配置，為什么需要動態學習？為什么需要Flood呢？

　　將流表項查找也Offload到TOR SDN交換機，使用Linux Bridge做內部VM交換或者為了安全可控，讓報文無論如何先送到TOR交換機，交換機處理后再送回去。這樣延時會稍微大一點點兒。這一步根據用戶情況 可選，也可以只做前面兩步，流表查找仍然使用服務器內部的OVS。

　　更進一步，將基本的無狀態Firewall、基于L2-L4的Load Balancer等（當然，如果是有狀態的Firewall或者四層之上的Firewall/Load Balancer，交換機就搞不定了）也都在TOR交換機上面實現，把OpenStack中獨立的網絡節點服務器完全省掉了。當然這一步對交換機的要求比 較高，不是都能做到。如果做不到沒關系，仍然放到服務器內部做。但這一步如果做了，對性能提升也會很明顯。

　　L3 Gateway是所有云計算平臺所共同面臨的瓶頸，比如OpenStack，有專門的網絡節點（Server）來充當L3 Gateway，用于支持租戶的虛擬Router，由于所有需要路由的報文都要經過這些虛擬Router來轉發，充當L3 Gateway的Server就成了瓶頸。有的硬件SDN交換機可以支持這種情況下的L3 Gateway，而且可以做成全分布式的，這樣就不再存在性能瓶頸。

　　通過在TOR上啟用ARP代理，幫助答復ARP請求，這樣就可以避免ARP廣播。

　　當然這只是理論分析，還需要實踐檢驗，目前這方面的實踐很少。盛科網絡在這方面做了嘗試，用自己的SDN交換機V350為多家云服務提供商（如 UCloud、99Cloud等）提供了基于硬件交換機的云計算網絡解決方案，實現了上述優化措施，并將提交自己的plugin到OpenStack。 UCloud與盛科共同推出了云計算網絡解決方案（如圖3所示）。

　　當然并非所有云平臺都是基于OpenStack的，那是否別的云平臺也可以使用硬件交換機代替vSwitch呢？答案是肯定的，其實UCloud的云平臺就 并非OpenStack。另外，對于網絡虛擬化，有人是用VLan做的，有人用Tunnel overlay技術，這并不影響使用vSwitch還是物理交換機。

　　當然，即便是這樣，仍然會有人說，雖然虛擬交換機確實會導致CPU利用 率有點高，但高點就高點，也沒什么；雖然虛擬交換機會導致更多的帶寬損耗，但損耗點也沒關系，反正我的網絡也不需要那么高帶寬，所以我真沒必要使用硬件 SDN方案。這話聽起來也有道理，但換個角度想想，公有云的基礎架構成本非常高昂，公有云服務商要想賺錢，必須要在保證用戶體驗的前提下降低成本。怎么降 低？如果能夠在一個Server內放更多的虛機，自然就可以降低成本，所以如果能把網絡處理的消耗轉移到物理交換機，讓網絡設備去處理網絡功 能，Server專注于計算，那就可以省出更多資源來放置更多虛擬機。而所有這一切并不需要引入額外的設備，用得不爽了可以隨時切換回原有方案，讓SDN TOR交換機只執行普通TOR功能，可以說基本沒有什么負面影響，何樂而不為呢？說到底，還是因為大家都被虛擬機廠商影響太深，有了先入為主的成見，特別 是在很多人對網絡不是很了解的前提下。

　　五、結語

　　當前，很多從事 云計算的技術人員都是從企業內部的運維和系統研發人員直接轉過來的。在傳統網絡時代，網絡對他們來說只是個工具，會操作就行。但到了云計算時代，對云計算平臺的開發人員來說，就不僅僅是會用這么簡單了，而是提出了更高的要求，需要相關從業人員精通網絡原理，這樣才能讓云計算網絡的性能、可擴展性、對業務的 支持都做到最優，現在流行的DevOps概念就體現了這種要求。

　　因此，對這些人來說，深入了解網絡技術就變得必不可少。但無論如何，云計算讓網絡應用變得精彩，讓應用創新變得更容易；網絡是云計算的基石，沒有網絡就沒有云計算，那么，付出一點學習的代價又算得了什么呢？