對于SDN交換機在上述場景中的應用，用一句詞來總結，靈活百用。這里說的SDN交換機，不一定是OpenFlow交換機，更多的時候，通過在傳統(tǒng)交換機里面引入一個Cloud Agent。提供開放的API（JSON RPC或者REST API），也許是一種更好的接地氣的實現方式，

　　SDN的技術已經發(fā)展了好幾年了，而云計算的歷史更長，兩者的結合更是作為SDN的一個殺手級應用在近兩年炒得火熱，一些知名咨詢公司的關于SDN逐年增加的市場份額的論斷，也主要是指SDN在云計算網絡中的應用。

　　關于SDN在云計算網絡中的應用，目前有兩個主要的流派，一個是VMware為代表的”軟”派，另外一個則是以思科為代表的“硬”派。前者主要是指整個網絡虛擬化方案的核心邏輯都是實現在服務器中的Hypervisor之上，物理網絡只是一個管道;而后者則是指網絡虛擬化的核心邏輯實現在物理網絡中（主要邊緣的機頂交換機，即TOR），只有交換機實現不了的部分才放到服務器或者別的專用設備中。這兩種方案各有千秋，也各有粉絲。

　　但是世界從來都不是單極的，也不是兩極，而是多極，現實網絡中有很多各種非常規(guī)的需求，這些需求并不是靠這兩個方案就可以解決的，或者說雖然他們能解決，但是不是最優(yōu)的，包括實現難度、性能和價格。作為一個長期使用硬件SDN為用戶提供解決方案的從業(yè)者，我在這里想來介紹一下現實世界中硬件SDN交換機是如何來解決一些云計算網絡中的特定場景需求的，這些需求無論公有云還是私有云都可能會碰到，私有云（包括托管云）居多，因為定制的需求在私有云中更常見。

　　需要特別說明的是，這里的這些場景，用思科的ACI都可以做到，因為本質上ACI的思路也是用硬件SDN來支持網絡虛擬化。但是由于很多用戶因為各種原因并不想使用思科ACI（如價格太貴、廠商鎖定、國產化趨勢等），所以他們需要另外的方案（我并不是說ACI不好，相反，純粹從技術的角度，我個人很欣賞ACI）。

　　云計算網絡對SDN控制器和交換機的定制要求

　　很多人對SDN交換機在云計算網絡中的應用都會有一些誤解。最典型的誤解有兩個，一個是總有人問，你們用的控制器是哪個控制器？能跟OpenDayLight/Ryu/ONOS對接嗎？另外一個則是，覺得只要拿一臺SDN交換機來，就可以支持云計算網絡場景，無論是哪個廠商的哪種SDN交換機。之所以有這兩個誤解，是因為很多人還沒理解到SDN就意味著跟應用相關的定制，以為隨便拿著一個通用的東西就可以來做云計算網絡了。云計算網絡作為一種特定的SDN場景，其控制器通常都是專門針對云計算這個場景設計的，功能單一，就是完成云計算網絡的需求，甚至都可能沒有顯式的控制器，而是隱藏在云平臺里面（比如直接實現在OpenStack Neutron Server中的代碼邏輯）。這種場景中的控制器沒法用作通用SDN控制器，反之，通用SDN控制器也沒法直接用于云計算網絡場景。至于第二個問題為什么說是誤解，那也就很容易理解了，連控制器都需要為云計算場景定制，更不要說SDN交換機了。所以并非是隨便拿一個SDN交換機過來就能支持云計算網絡場景，而需要有專門的深度定制。比如我們盛科網絡，就專門針對這個場景，設計了相應的控制器和交換機功能。

　　場景1：使用硬件SDN交換機提升性能

　　在這種場景中，用戶使用Tunnel Overlay的方式部署網絡虛擬化。但是由于vSwitch對Tunnel（VxLAN或者NvGRE）的操作對性能影響比較大（吞吐量偏低，延時偏大，抖動比較大，具體影響大小要看每個公司對它的實現和優(yōu)化），所以這個時候可以借助SDN TOR交換機來進行tunnel offload，把對性能影響比較大的tunnel操作offload到SDN TOR交換機上，其它所有操作保持在服務器中不變，邏輯上可以認為SDN TOR交換機是vSwitch的擴展。如果更進一步，則可以把分布式東西向L3 Gateway也放到SDN TOR上，這樣SDN TOR等于是深度參與到網絡虛擬化中。

　　并非所有用戶都認可這種模式，但是有人喜歡。目前這種場景我們已經在幾個中小型的私有云和某著名IDC云中部署了，對這些云最大的幫助就是優(yōu)良的性能和穩(wěn)定性。數據流程見下圖。

　　場景2：使用硬件SDN交換機接入物理服務器

　　在不少人的理解中，以為云計算數據中心里面，所有的服務器都虛擬化了，實際上這個理解跟事實相去甚遠，不僅在很多公有云和私有云中有大量物理服務器存在，甚至有些云里面物理服務器還占了大頭。我接觸到的絕大多數真正有大量客戶實踐的云，基本上都有這個需求。原因也多種多樣，有的是現存的一些老的服務器沒有虛擬化能力，有的是客戶要跑一些非常消耗資源的應用，使用虛機性能太差或者性能不可預測，有的是客戶的某些服務器是定制化的服務器，有的是出于安全考慮，從物理上就不想跟別人共享，還有的則是用戶自帶服務器，壓根就不想云服務提供商來動，等等，總之原因是千奇百怪，但是都是客戶真實需求。

　　對于這個需求，如果使用Vlan組網，那還是比較容易搞定的，不用SDN交換機也勉強可以，因為要做隔離的話，直接在普通交換機上配置Vlan就行了。但是一旦使用Tunnel，那問題就來了，Tunnel VTEP配置在哪里？有人說可以在服務器上只起一個虛機，然后也安裝vSwitch，這樣當然也可以做，但是性能受損，不是客戶希望的，相當于欺騙客戶;還有人說專門設計一個特殊的vSwitch，安裝在服務器上，這樣理論上肯定也行，但是工作量就大了（不僅僅是設計這個vSwitch的工作量，還有云平臺控制的工作量），一般人搞不定。更何況，如果是用戶自帶設備根本不想你去動，這兩種辦法都行不通。對于這個場景，包括VMware在內的很多專業(yè)網絡虛擬化解決方案提供商，一般的做法都是通過一臺硬件SDN交換機作為VTEP Gateway，來將這些物理服務器接入到虛擬網絡中去，物理服務器不需要做任何事情。而且這種場景對作為VTEP Gateway的SDN交換機來說，還有一個比較重要的要求，是目前用某大牌交換芯片的所有交換機都做不到的，那就是需要交換機既能支持Tunnel bridging，也能支持Tunnel Routing（否則沒法做分布式L3 Gateway），當前用該大牌芯片的交換機只能支持前者，無法支持后者。思科的ACI之所以能支持后者，是因為他們用了自己一顆芯片。當然，該芯片提供商后面的芯片據說會解決這個問題。

　　盛科網絡的SDN交換機，用的是自研交換芯片，從第一代芯片開始就支持Tunnel bridging & routing。 目前針對這個場景的SDN交換機已經大量部署和即將部署在多個公有云中。該場景架構見下圖（注：SDN的控制協(xié)議未必是OpenFlow，也可以是私有協(xié)議）

　　場景3：使用硬件SDN交換機接入硬件防火墻

　　云計算網絡中使用硬件防火墻，這個很常見。特別是企業(yè)私有云，托管云，甚至公有云里面也有。很多用戶明確提出，我原來用我的硬件防火墻用得很好，你要讓我上云可以，一定要把我的硬件防火墻用起來。那問題就來了，以前在傳統(tǒng)網絡中，用戶數據想經過防火墻，很簡單，把防火墻串接在網絡出口或者配置一個ACL把流引過去就可以了。但是在云計算的網絡里面，有可能某個防火墻只是為某幾個用戶或者某一組應用服務的，甚至這個防火墻壓根就這個用戶自帶的，你不能把它物理上串接在網絡出口，必須要將流量引到放在某個機柜的防火墻上，但是這個時候用傳統(tǒng)ACL不合適，因為VM是動態(tài)產生的，策略也可能動態(tài)變化，你需要動態(tài)在交換機上配置ACL。用什么來做最合適？毫無疑問是SDN交換機，動態(tài)策略跟隨，本來就是SDN的強項，思科的ACI最核心的東西就是動態(tài)策略跟隨。

　　如果云計算網絡中使用了Tunnel，那問題會更麻煩，因為很多硬件防火墻不支持Tunnel，必須要有另外一個地方終結Tunnel，然后將Tunnel轉換成Vlan送到防火墻，誰來做這個事情最合適？毫無疑問，那就是支持Tunnel的SDN交換機。

　　有人說這樣的話防火墻仍然會受4K Vlan的限制。其實不然，因為Tunnel向Vlan轉換的時候，這里的Vlan可以是每端口唯一的，而不需要是全局唯一的。當然，這個也需要交換機能支持才行。盛科的SDN交換機就可以很好地支持這個需求。

　　場景4：使用硬件SDN交換機支持多個Hypervisor混合組網

　　說是多個Hypervisor，其實最多的還是說VMware跟其它Hypervisor的混合組網。因為無論是KVM還是Xen，那些開源的云平臺或者第三方中立的私有云平臺都能支持得很好，云平臺可以完全控制這些Hypervisor。但是VMware是一個閉源的Hypervisor，沒辦法隨心所欲控制。很多客戶都用了VMware以前的老產品，現在VPC比較熱，無論是趕時髦也好，還是真的有需求也好，他們都想能支持VPC，特別是基于Tunnel Overlay的VPC。有人說，那好辦啊，VMware不是有NSX專門來干這事嗎？盡管它提供了對OpenStack的driver，但是NSX非常貴，一般客戶用不起或者覺得不劃算。這些客戶要引入一些開源的KVM，XEN，但是又不想丟棄以前的VMware，還想讓這些Hypervisor一起組成VPC網絡。那怎么辦呢？

　　一個有效的解決方案就是使用SDN交換機接入使用了VMware的服務器，云平臺調用vCenter的接口配置VMware，使用Vlan標識租戶的network，然后在SDN交換機上，將Vlan轉換成Tunnel，如果要讓VM的流量送到防火墻去做過濾，也都可以通過SDN交換機去做。該方案已經由我們的一個行業(yè)云服務提供商合作伙伴成功在其行業(yè)客戶中部署，該行業(yè)客戶群大量使用了VMware產品。而且我們發(fā)現有類似需求的私有云很多，說白了就是不想花錢買NSX，而又想有某些NSX的功能。該方案架構見下圖。

　　場景5：使用硬件SDN交換機按需部署Vlan

　　這個場景不算是剛需，有些客戶不在乎，但是也有客戶在乎。當前很多小型私有云中，還是使用了Vlan的組網方式，畢竟簡單易部署，且性能好。但是用Vlan來組網除了擴展性不如Tunnel Overlay之外，它還有另外一個小問題，因為VM可以隨便遷移，而每個VM都綁到一個特定Vlan，當VM遷移走的時候，Vlan也需要跟著遷移。而在Vlan組網的方案里面，Vlan必須對中間的物理網絡可見，這就意味著交換機端口上的Vlan配置要經常動態(tài)變化。為了規(guī)避這個問題，現在一般的做法都是預先把所有可能用到的vlan在所有的交換機的所有端口上都全部使能。這樣帶來的問題是，所有廣播（如ARP/DHCP）、組播、未知單播的報文每次都會被發(fā)送到整個物理網絡的所有服務器上，最終在服務器里面才丟棄，這種做法一方面浪費了帶寬，另外一方面也有潛在的安全問題。

　　對于這種問題的一個很簡單的解決方案就是引入SDN交換機，動態(tài)按需去配置Vlan。