2021年SDN交換機在云計算網(wǎng)絡中的應用場景

1、資料來源：來自本人網(wǎng)絡整理！祝您工作順利！2021年sdn交換機在云計算網(wǎng)絡中的應用場景 歡送來到。這篇是我特地為大家整理的，盼望對大家有所關心! sdn的技術(shù)已經(jīng)進展了好幾年了，而云計算的歷史更長，兩者的結(jié)合更是作為sdn的一個殺手級應用在近兩年炒得熾熱，一些知名詢問公司的關于sdn逐年增加的市場份額的論斷，也主要是指sdn在云計算網(wǎng)絡中的應用。 關于sdn在云計算網(wǎng)絡中的應用，目前有兩個主要的流派，一個是vmware為代表的軟派，另外一個那么是以思科為代表的硬派。前者主要是指整個網(wǎng)絡虛擬化方案的核心規(guī)律都是實如今效勞器中的hypervisor之上，物理網(wǎng)絡只是一個管道;而后者那么是指網(wǎng)絡虛

2、擬化的核心規(guī)律實如今物理網(wǎng)絡中(主要邊緣的機頂交換機，即tor)，只有交換機實現(xiàn)不了的局部才放到效勞器或者別的專用設備中。這兩種方案各有千秋，也各有粉絲。 但是世界從來都不是單極的，也不是兩極，而是多極，現(xiàn)實網(wǎng)絡中有許多各種特別規(guī)的需求，這些需求并不是靠這兩個方案就可以解決的，或者說雖然他們能解決，但是不是最優(yōu)的，包括實現(xiàn)難度、性能和價格。作為一個長期用法硬件sdn為用戶供應解決方案的從業(yè)者，我在這里想來介紹一下現(xiàn)實世界中硬件sdn交換機是如何來解決一些云計算網(wǎng)絡中的特定場景需求的，這些需求無論公有云還是私有云都可能會碰到，私有云(包括托管云)居多，因為定制的需求在私有云中更常見。 需要特殊說

3、明的是，這里的這些場景，用思科的aci都可以做到，因為本質(zhì)上aci的思路也是用硬件sdn來支持網(wǎng)絡虛擬化。但是由于許多用戶因為各種緣由并不想用法思科aci(如價格太貴、廠商鎖定、國產(chǎn)化趨勢等)，所以他們需要另外的方案(我并不是說aci不好，相反，純粹從技術(shù)的角度，我個人很觀賞aci)。 云計算網(wǎng)絡對sdn掌握器和交換機的定制要求 許多人對sdn交換機在云計算網(wǎng)絡中的應用都會有一些誤會。最典型的誤會有兩個，一個是總有人問，你們用的掌握器是哪個掌握器?能跟opendaylight/ryu/onos對接嗎?另外一個那么是，覺得只要拿一臺sdn交換機來，就可以支持云計算網(wǎng)絡場景，無論是哪個廠商的哪種s

4、dn交換機。之所以有這兩個誤會，是因為許多人還沒理解到sdn就意味著跟應用相關的定制，以為任憑拿著一個通用的東西就可以來做云計算網(wǎng)絡了。云計算網(wǎng)絡作為一種特定的sdn場景，其掌握器通常都是特地針對云計算這個場景設計的，功能單一，就是完成云計算網(wǎng)絡的需求，甚至都可能沒有顯式的掌握器，而是隱藏在云平臺里面(比方挺直實如今openstack neutron server中的代碼規(guī)律)。這種場景中的掌握器沒法用作通用sdn掌握器，反之，通用sdn掌握器也沒法挺直用于云計算網(wǎng)絡場景。至于其次個問題為什么說是誤會，那也就很簡單理解了，連掌握器都需要為云計算場景定制，更不要說sdn交換機了。所以并非是任憑拿

5、一個sdn交換機過來就能支持云計算網(wǎng)絡場景，而需要有特地的深度定制。比方我們盛科網(wǎng)絡，就特地針對這個場景，設計了相應的掌握器和交換機功能。 場景1：用法硬件sdn交換機提升性能 在這種場景中，用戶用法tunnel overlay的方式部署網(wǎng)絡虛擬化。但是由于vswitch對tunnel(vxlan或者nvgre)的操作對性能影響比擬大(吞吐量偏低，延時偏大，抖動比擬大，詳細影響大小要看每個公司對它的實現(xiàn)和優(yōu)化)，所以這個時候可以借助sdn tor交換機來進展tunnel offload，把對性能影響比擬大的tunnel操作offload到sdn tor交換機上，其它全部操作保持在效勞器中不變，

6、規(guī)律上可以認為sdn tor交換機是vswitch的擴展。假如更進一步，那么可以把分布式東西向l3 gateway也放到sdn tor上，這樣sdn tor等于是深度參加到網(wǎng)絡虛擬化中。 并非全部用戶都認可這種形式，但是有人喜愛。目前這種場景我們已經(jīng)在幾個中小型的私有云和某有名idc云中部署了，對這些云最大的關心就是優(yōu)良的性能和穩(wěn)定性。 場景2：用法硬件sdn交換機接入物理效勞器 在不少人的理解中，以為云計算數(shù)據(jù)中心里面，全部的效勞器都虛擬化了，事實上這個理解跟事實相去甚遠，不僅在許多公有云和私有云中有大量物理效勞器存在，甚至有些云里面物理效勞器還占了大頭。我接觸到的絕大多數(shù)真正有大量客戶理論

7、的云，根本上都有這個需求。緣由也多種多樣，有的是現(xiàn)存的一些老的效勞器沒有虛擬化力量，有的是客戶要跑一些特別消耗資源的應用，用法虛機性能太差或者性能不行預報，有的是客戶的某些效勞器是定制化的效勞器，有的是出于平安考慮，從物理上就不想跟別人共享，還有的那么是用戶自帶效勞器，壓根就不想云效勞供應商來動，等等，總之緣由是千姿百態(tài)，但是都是客戶真實需求。 對于這個需求，假如用法vlan組網(wǎng)，那還是比擬簡單搞定的，不用sdn交換機也牽強可以，因為要做隔離的話，挺直在一般交換機上配置vlan就行了。但是一旦用法tunnel，那問題就來了，tunnel vtep配置在哪里?有人說可以在效勞器上只起一個虛機，然

8、后也安裝vswitch，這樣當然也可以做，但是性能受損，不是客戶盼望的，相當于欺騙客戶;還有人說特地設計一個特別的vswitch，安裝在效勞器上，這樣理論上確定也行，但是工作量就大了(不僅僅是設計這個vswitch的工作量，還有云平臺掌握的工作量)，一般人搞不定。更何況，假如是用戶自帶設備根本不想你去動，這兩種方法都行不通。對于這個場景，包括vmware在內(nèi)的許多專業(yè)網(wǎng)絡虛擬化解決方案供應商，一般的做法都是通過一臺硬件sdn交換機作為vtep gateway，來將這些物理效勞器接入到虛擬網(wǎng)絡中去，物理效勞器不需要做任何事情。而且這種場景對作為vtep gateway的sdn交換機來說，還有一個

9、比擬重要的要求，是目前用某大牌交換芯片的全部交換機都做不到的，那就是需要交換機既能支持tunnel bridging，也能支持tunnel routing(否那么沒法做分布式l3 gateway)，當前用該大牌芯片的交換機只能支持前者，無法支持后者。思科的aci之所以能支持后者，是因為他們用了自己一顆芯片。當然，該芯片供應商后面的芯片據(jù)說會解決這個問題。 盛科網(wǎng)絡的sdn交換機，用的是自研交換芯片，從第一代芯片開頭就支持tunnel bridging routing。 目前針對這個場景的sdn交換機已經(jīng)大量部署和即將部署在多個公有云中。 場景3：用法硬件sdn交換機接入硬件防火墻 云計算網(wǎng)絡中

10、用法硬件防火墻，這個很常見。特殊是企業(yè)私有云，托管云，甚至公有云里面也有。許多用戶明確提出，我原來用我的硬件防火墻用得很好，你要讓我上云可以，肯定要把我的硬件防火墻用起來。那問題就來了，以前在傳統(tǒng)網(wǎng)絡中，用戶數(shù)據(jù)想經(jīng)過防火墻，很簡潔，把防火墻串接在網(wǎng)絡出口或者配置一個acl把流引過去就可以了。但是在云計算的網(wǎng)絡里面，有可能某個防火墻只是為某幾個用戶或者某一組應用效勞的，甚至這個防火墻壓根就這個用戶自帶的，你不能把它物理上串接在網(wǎng)絡出口，必需要將流量引到放在某個機柜的防火墻上，但是這個時候用傳統(tǒng)acl不適宜，因為vm是動態(tài)產(chǎn)生的，策略也可能動態(tài)改變，你需要動態(tài)在交換機上配置acl。用什么來做最適

11、宜?毫無疑問是sdn交換機，動態(tài)策略跟隨，原來就是sdn的強項，思科的aci最核心的東西就是動態(tài)策略跟隨。 假如云計算網(wǎng)絡中用法了tunnel，那問題會更費事，因為許多硬件防火墻不支持tunnel，必需要有另外一個地方終結(jié)tunnel，然后將tunnel轉(zhuǎn)換成vlan送到防火墻，誰來做這個事情最適宜?毫無疑問，那就是支持tunnel的sdn交換機。 有人說這樣的話防火墻仍舊會受4k vlan的限制。其實不然，因為tunnel向vlan轉(zhuǎn)換的時候，這里的vlan可以是每端口唯一的，而不需要是全局唯一的。當然，這個也需要交換機能支持才行。盛科的sdn交換機就可以很好地支持這個需求。 場景4：用法硬

12、件sdn交換機支持多個hypervisor混合組網(wǎng) 說是多個hypervisor，其實最多的還是說vmware跟其它hypervisor的混合組網(wǎng)。因為無論是kvm還是xen，那些開源的云平臺或者第三方中立的私有云平臺都能支持得很好，云平臺可以完全掌握這些hypervisor。但是vmware是一個閉源的hypervisor，沒方法隨心所欲掌握。許多客戶都用了vmware以前的老產(chǎn)品，如今vpc比擬熱，無論是趕時髦也好，還是真的有需求也好，他們都想能支持vpc，特殊是基于tunnel overlay的vpc。有人說，那好辦啊，vmware不是有nsx特地來干這事嗎?盡管它供應了對opensta

13、ck的driver，但是nsx特別貴，一般客戶用不起或者覺得不劃算。這些客戶要引入一些開源的kvm，xen，但是又不想丟棄以前的vmware，還想讓這些hypervisor一起組成vpc網(wǎng)絡。那怎么辦呢? 一個有效的解決方案就是用法sdn交換機接入用法了vmware的效勞器，云平臺調(diào)用vcenter的接口配置vmware，用法vlan標識租戶的network，然后在sdn交換機上，將vlan轉(zhuǎn)換成tunnel，假如要讓vm的流量送到防火墻去做過濾，也都可以通過sdn交換機去做。該方案已經(jīng)由我們的一個行業(yè)云效勞供應商合作伙伴勝利在其行業(yè)客戶中部署，該行業(yè)客戶群大量用法了vmware產(chǎn)品。而且我們

14、發(fā)覺有類似需求的私有云許多，說白了就是不想花錢買nsx，而又想有某些nsx的功能。 場景5：用法硬件sdn交換機按需部署vlan 這個場景不算是剛需，有些客戶不在乎，但是也有客戶在乎。當前許多小型私有云中，還是用法了vlan的組網(wǎng)方式，到底簡潔易部署，且性能好。但是用vlan來組網(wǎng)除了擴展性不如tunnel overlay之外，它還有另外一個小問題，因為vm可以任憑遷移，而每個vm都綁到一個特定vlan，當vm遷移走的時候，vlan也需要跟著遷移。而在vlan組網(wǎng)的方案里面，vlan必需對中間的物理網(wǎng)絡可見，這就意味著交換機端口上的vlan配置要常常動態(tài)改變。為了躲避這個問題，如今一般的做法都

15、是預先把全部可能用到的vlan在全部的交換機的全部端口上都全部使能。這樣帶來的問題是，全部播送(如arp/dhcp)、組播、未知單播的報文每次都會被發(fā)送到整個物理網(wǎng)絡的全部效勞器上，最終在效勞器里面才丟棄，這種做法一方面鋪張了帶寬，另外一方面也有潛在的平安問題。 對于這種問題的一個很簡潔的解決方案就是引入sdn交換機，動態(tài)按需去配置vlan。 總結(jié) 張衛(wèi)峰(盛科網(wǎng)絡sdn云計算cto 兼 軟件研發(fā)部門總監(jiān)，深度解析sdn一書。)：對于sdn交換機在上述場景中的應用，用一句話來總結(jié)，就是運用之妙存乎一心?，F(xiàn)實中的需求真的是千姿百態(tài)，我這里列出來的還都是相對有一些共性，大家簡單理解的需求。還有一些一般人理解不了的，甚至我都無法理解的需求，都還沒列出來。面對這