不好意思，本文有點長，需要閱讀10-15分鐘。

上一篇文章 得到了很多朋友的反饋， 軟硬SDN各自有各自的優(yōu)勢和特點 ，對于之前的文字，有兩個反饋。

第一個是文字上的錯誤，在我的文章里，提到了“據(jù)我所知，國內(nèi)的AWS，Azure和GCP，國內(nèi)的BAT，軟件SDN的方案還是居多”，此處有一個筆誤，這里的國內(nèi)應(yīng)該改成國外，還有朋友提到，這些互聯(lián)網(wǎng)企業(yè)應(yīng)該全部是軟件SDN的方案，在這里采用這樣的理解，針對于云的部分，比如業(yè)務(wù)開通，遷移，安全功能等建立這些內(nèi)容，應(yīng)該是軟件SDN來實現(xiàn)，針對于云基礎(chǔ)設(shè)施里面，關(guān)于多廠家硬件交換機的初次部署，自動化配置上線，以及監(jiān)控的部分，應(yīng)該是軟件自動化來完成，我把這種理解為硬件SDN的提供的功能之一，這也是我為什么說軟件SDN方案居多，而沒有說全部的原因所在。

第二個是一個叫“二馬”網(wǎng)友的留言。

云計算蓬勃發(fā)展，技術(shù)更新迭代，不僅需要團隊持續(xù)更新知識體系，也需要組織架構(gòu)、管理模式作出相應(yīng)調(diào)整，更需要工作思維轉(zhuǎn)變，以前各職能團隊自掃門前雪的情況需要突破，比如devops團隊，google的SRE，都是為了打破原有原有豎井式職能團隊的隔閡，提高團隊協(xié)作效率。

我覺得這樣的思考非常有意義，云的變化，技術(shù)往往只是工具，技術(shù)之外可能需要的更多。

        

好吧，言歸正傳，還是那句話，本文從大牛廠商的文章說起，再次強調(diào)，本文絕對不是針對或者否定特定廠家，還是前文那句話，結(jié)合原文延伸開來，給我們另一個視角去看待，山有南坡北北坡，橫看成嶺側(cè)成峰而已。

原文鏈接如下，建議大家耐心看看。

DCN 學(xué)院派丨數(shù)據(jù)中心網(wǎng)絡(luò)自動部署，軟硬SDN如何選擇？

本文的上半部分參考是原文的前三個層面，鏈接如下，溫故知新。

技術(shù)雜談-再談軟硬SDN（1）

下半部分，我們從性能開始。

●  談及性能

創(chuàng)新互聯(lián)公司服務(wù)項目包括新疆網(wǎng)站建設(shè)、新疆網(wǎng)站制作、新疆網(wǎng)頁制作以及新疆網(wǎng)絡(luò)營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，新疆網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到新疆省份的部分城市，未來相信會繼續(xù)擴大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！

原文提出：

由于硬SDN在交換機硬件上甚至芯片上來處理，性能上確實遠勝軟SDN。軟SDN依賴的vSwitch也在持續(xù)往這個方向努力，比如疊加DPDK，智能網(wǎng)卡卸載等“圍魏救趙”方式，性能問題確實得到了一些緩解，各廠家數(shù)據(jù)普遍提升到十多G，但相比硬SDN能力仍然差距較大。有些卸載技術(shù)能否規(guī)模商用還沒有形成行業(yè)共識，有些還處在創(chuàng)新實驗階段，而且引入這些輔助技術(shù)時又?jǐn)U展了軟SDN的配套邊界和復(fù)雜度，當(dāng)然也增加了成本。

我們必須要肯定的一點，軟件SDN單純從性能上的考量，一定和硬件SDN存在差距，但是，是否硬件“遠勝”SDN，那可能就需要用數(shù)據(jù)來考量。以openstack為例，早期為什么會使用硬件SDN，確實OVS本身的性能確實不讓人滿意，而硬件可以有效地承擔(dān)解決這個瓶頸。然而，時過境遷，各種技術(shù)類似于DPDK，SR-IOV，以及智能網(wǎng)卡的興起，軟件SDN從未停止性能上追求的腳步，在保留原有靈活性的同時，努力去滿足實際業(yè)務(wù)的需求，而且客觀的講，商用的案例比較一兩年前，已經(jīng)不限于星星之火，如果按照以往標(biāo)準(zhǔn)，硬件SDN性能打5星好評，軟件性能一顆星的話，現(xiàn)在把軟件達到3.5甚至于4星都有可能，很多網(wǎng)卡，系統(tǒng)廠商的測試指標(biāo)，以及公有云的商用案例已經(jīng)說明了這些。

更主要的是：選擇任何一個技術(shù)，都是綜合性的考量，是性能和靈活性均衡的結(jié)果，在上云的過程中，我們看到有案例是從軟件遷移到硬件，也有案例從硬件遷移到了軟件，也有硬件和軟件不斷地交替實現(xiàn)，恰恰說明了，不管是硬件還是軟件，都在性能這個層面上不斷的追求進步和完美，如同一個馬拉松的歷程，雖有短暫的差距，但是都在你追我趕的過程中。

●  開放和集成

文中提到：

企業(yè)市場細分市場眾多，不同企業(yè)對包括服務(wù)器的廠家和型號、虛擬化平臺、云平臺等不同部件也有不同的喜好或經(jīng)驗，二者誰更能匹配這種開放集成的訴求呢？由于軟SDN依賴服務(wù)器vSwitch，它需要配套底層平臺軟件，甚至匹配虛擬服務(wù)器型號支持。由于不同虛擬層軟件的差異性，導(dǎo)致了單個vSwitch產(chǎn)品無法通配所有虛擬層平臺而需要獨立配套的產(chǎn)品。硬SDN則避免了這些鎖定，由于控制點在硬件交換機，能普遍適應(yīng)下層接入的IT資源生態(tài)，如不同廠家服務(wù)器和不同虛擬化平臺，以及云平臺產(chǎn)品。

回到我的看法，如果我們按照整體規(guī)劃的邏輯，云平臺是整體的調(diào)度-計算，存儲和網(wǎng)絡(luò)資源，虛擬化平臺去承載這些實現(xiàn)，SDN是介于云平臺和虛擬化平臺之間，對上要可以和云平臺有效溝通，對下需要和虛擬化準(zhǔn)確實現(xiàn)，從云平臺的角度，不管硬件還是軟件SDN集成，都是靠API的對接來完成，二者在實現(xiàn)上并無差異，而對虛擬化的平臺如openstack，或者k8s或者vmware的集成，軟硬件實現(xiàn)的落地點就不一樣。

軟SDN如下圖所示：

        

軟SDN的目標(biāo)是可以虛擬化網(wǎng)絡(luò)層統(tǒng)一部署，來實現(xiàn)一致性的網(wǎng)絡(luò)聯(lián)通以及管理，這就意味著，如果你希望實現(xiàn)軟件SDN，就需要對軟件SDN的適配程度（主要是操作系統(tǒng)以及內(nèi)核，虛擬化平臺），具備一定的了解，同時也要考慮是否支持主流的平臺。

硬件SDN如下圖所示：

    

硬SDN的目標(biāo)是保持原有的虛擬化網(wǎng)絡(luò)層不變，通過硬件來實現(xiàn)網(wǎng)絡(luò)聯(lián)通和管理。而這也就意味著，如果是用硬件實現(xiàn)，在虛擬化網(wǎng)絡(luò)層的部分放棄了統(tǒng)一，仍然保留原有的部署，通過硬件交換機來實現(xiàn)對底層虛擬化的適配，相比較而言更為簡單。

        

但是并不能說明硬件交換機可以適配所有的平臺，能適配所有平臺的條件是，虛擬網(wǎng)絡(luò)層不做任何的SDN動作，可以直接把流量透傳上來，而虛擬網(wǎng)絡(luò)層其實恰恰是執(zhí)行網(wǎng)絡(luò)策略相對合理的位置。

       

前面提到，軟件SDN的目標(biāo)是可以在虛擬化網(wǎng)絡(luò)層里實現(xiàn)統(tǒng)一，也是有條件的統(tǒng)一，他的技術(shù)路線一定是先滿足大部分的云平臺，進而考慮其他虛擬化方式，例如VMware，就需要考慮本身是私有化平臺，軟件SDN如何去與之適應(yīng)，要采用什么樣的方式與其兼容，這一點的思路和硬件SDN是一樣的。

        

因此，談到開放和集成，兩者的目的一致，各自有各自的實現(xiàn)方法，從我的目前的認(rèn)知來說，各有千秋，說句墻頭草和事佬的話，軟也好，硬也好，各有各的門道兒。

        

但回到“鎖定”這事兒上，讓軟件SDN背上“鎖定”這個鍋，可能需要重新琢磨琢磨。

        

前文提到：硬件SDN的控制點在硬件交換機上，基于此我們在追問一下？    

    

誰的硬件交換機呢？？

參考一下前面硬件SDN的實現(xiàn)圖形，我們假定有三個虛擬化平臺，分別為V1，V2和V3，假定硬件廠家為一家A，此時所有的SDN設(shè)計都是V1-V3和A的對應(yīng)，這個邏輯沒有問題，但是如果業(yè)務(wù)規(guī)模增長之后，對于硬件交換機的品牌，我們有兩種選擇：

1. 依然選擇A家，這樣可以保證SDN對的一致性。

2. 選擇增加B家，這時帶來的復(fù)雜的排列組合問題，V1-V3不僅需要和A家的SDN產(chǎn)生對應(yīng)，也需要對B家的SDN產(chǎn)生對應(yīng)，如果再加一個C家，組合更多。

由此產(chǎn)生的話題包括：

1. A家的SDN軟件能夠兼容B家的硬件嗎？

2. A家的整體SDN可以和B家的整體SDN實現(xiàn)網(wǎng)絡(luò)側(cè)的對接嗎？

3. 在SDN業(yè)務(wù)邏輯實現(xiàn)上，其他網(wǎng)絡(luò)功能設(shè)備（如防火墻，路由器）可以是多品牌嗎？

這些或許都不是問題，因為我說過，每一家的方案都有自己的優(yōu)秀之處，用各種技術(shù)來將客戶的業(yè)務(wù)邏輯通過硬件SDN的方式呈現(xiàn)出來，就如同房子裝修一樣，如果想簡單易行，那么就找一個裝修公司，所有的東西都全部交給他們搞定，或者直接買一個精裝修的房子，既有好處，也會有遺憾。

        

這些或者又都是問題，本身硬件SDN其天生的基因就是，軟件和硬件緊密集合，這也就決定了你無法在硬件上去靈活的選擇，我們不去評價商業(yè)利益和廠商策略，至少在技術(shù)實現(xiàn)的邏輯上，硬件SDN存在這樣的現(xiàn)狀，我們不應(yīng)，也無需回避。

        

而我的觀點還是很“中庸”，是否有更合適的“軟件”和“硬件”攜手的方案呢？我知道理想很豐滿，但我們不應(yīng)因現(xiàn)實的骨感，而放棄對美好事物的追求。上一篇文章提到了AWS為代表的國外云企業(yè)，以及阿里云為代表的國內(nèi)云企業(yè)，在他們公用云的設(shè)計中，軟SDN負責(zé)云網(wǎng)絡(luò)，硬SDN負責(zé)設(shè)備管理（而且是多廠家的模式），可以作為我們架構(gòu)設(shè)計的一個借鑒，我在京東上預(yù)定了本《企業(yè)數(shù)字化基石》的書，我希望從阿里的描述中學(xué)習(xí)更多，作為后面文章的參考。

●  成本，以及場景

還是引用原文：

業(yè)界不少人認(rèn)為軟硬SDN之爭最關(guān)鍵的兩點便是可靠性和成本。性能問題最后歸到底也可以看為成本的一個部分。在這場賽跑中，一邊是軟SDN通過服務(wù)器成本來置換網(wǎng)絡(luò)資源，包括性能疊加和規(guī)模管理引入的成本。另一邊則是網(wǎng)絡(luò)設(shè)備商的硬件能力提升快速消化掉硬SDN的成本。哪個效率曲線跑的快，哪個就更有優(yōu)勢。這一點上，目前硬SDN有明顯優(yōu)勢。從實際項目中取得信息看，硬SDN方案交換機已經(jīng)基本消化了SDN的成本，和非SDN交換機的價格基本一樣，這得益于這幾年芯片集成能力飛速發(fā)展。反觀軟SDN，vSwitch的數(shù)量龐大加上運維年費，價格也并不便宜。

這里關(guān)于硬件SDN的描述是非常準(zhǔn)確的，尤其提到，隨著芯片能力的提升，我把這個話題延伸一下，總結(jié)起來可以是這么幾句話。

1. 10GE和25GE光模塊的成本下降，使得服務(wù)器側(cè)和交換機側(cè)在在網(wǎng)絡(luò)方面的整體成本下降。

2. 從一個小技術(shù)點分析，VxLAN分布式網(wǎng)關(guān)已經(jīng)成為交換機標(biāo)配，芯片的快速迭代，使得最低的接入層交換機都可以幾乎具備SDN的全部功能。

3. 所謂的SDN交換機和非SDN交換機，就是功能的支持能力，隨著時間的推移，兩者一定會趨于一致，如同過去所謂二層交換機和三層交換機的差異一樣，但是SDN和非SDN對的交換機價格差異是客觀存在，究竟是不是基本一致，差又差了多少，就要看市場的定價如何。

從分析成本而言，成本既包括產(chǎn)品購置的成本，也包括學(xué)習(xí)的成本，維護的成本，產(chǎn)品更新替代的成本，一個個掰開看， 硬件軟件之間，說不定誰貴誰便宜，即便把時間拉長也是如此，我覺得真的需要具體問題具體分析。

        

能夠考量成本最直接的方式是什么？回報或許是一個考量，也就是ROI（投資回報率），在企業(yè)的IT投資里面，ROI是相對較難評估的，因為IT從來都是花錢的部門，如何評估直接帶來經(jīng)濟效益呢？這個話題又太大了。

        

在我看來，除了要講企業(yè)的整體收益納入到IT的投資回報中之外，還可能有如下幾個指標(biāo)，例如IT規(guī)模增加的情況下，IT人員的成本是否線性增加，如果沒有增加，也是隱形的收入，所謂沒多花錢，就是省錢。再比如與以前業(yè)務(wù)的IT流程比較（這里說的是傳統(tǒng)業(yè)務(wù)通過IT業(yè)務(wù)的實現(xiàn)，比如上線新產(chǎn)品，新系統(tǒng)等等），效率是提升了，還是降低了？是更靈活了，還是更復(fù)雜了？在樸素一點，IT人員做了這些，業(yè)務(wù)人員到底有沒有感到“舒服”了，自己運維是不是感到“輕松”了？這些隱形的東西，可以在實踐中，作為成本考量的一些標(biāo)準(zhǔn)。

        

從成本的話題再回到場景的考量上，文中提到的這個場景的“錨定”，就需要我們進一步反思。

原文提到：

但具體到不同場景上，軟SDN展現(xiàn)了其靈活的用武之地。比如在一個不再增長的傳統(tǒng)業(yè)務(wù)數(shù)據(jù)中心，客戶無意過多投資網(wǎng)絡(luò)改造，而老舊的交換機不支持SDN，這時軟件SDN方式用服務(wù)器資源置換SDN能力會是一個好的選擇。畢竟對一個沒有增長的業(yè)務(wù)不必要去大動干戈。硬幣的另一面，如果預(yù)期業(yè)務(wù)要持續(xù)增長時，仍然建議采用硬SDN的方式來建設(shè)或逐步改造，時間越長回報越大。

在這個說法中，在傳統(tǒng)數(shù)據(jù)中心的場景下，建議使用軟件SDN去置換SDN能力，但是前文說道，硬SDN在成本上有明顯優(yōu)勢，那為什么在老的數(shù)據(jù)中心場景下，又建議使用軟SDN呢？畢竟SDN這件事，不管軟件還是硬件，對于老的數(shù)據(jù)中心，都可能是“回爐改造”的過程，在前文中并沒有提到在傳統(tǒng)數(shù)據(jù)中心和新興數(shù)據(jù)中心的成本參考，而在后文又緣何要把軟SDN框定在傳統(tǒng)數(shù)據(jù)中心的“藩籬”之內(nèi)？

        

如果是我的話，我可能要換個說法，各位看是否合適：

        

對于不再增長的傳統(tǒng)業(yè)務(wù)數(shù)據(jù)中心，業(yè)務(wù)已經(jīng)固定，客戶無意過多投資網(wǎng)絡(luò)改造，老舊的交換機不支持SDN（其實這些年，這樣的數(shù)據(jù)中心似乎越來越少了），與其說大動干戈進行改造，不如保持不變，維持原有業(yè)務(wù)的連通性和邏輯，當(dāng)新的數(shù)據(jù)中心建設(shè)完成之后，將業(yè)務(wù)遷移過去，慢慢完成新老交替。

        

而在新的數(shù)據(jù)中心建設(shè)中，投入資源去進行調(diào)研和學(xué)習(xí)，在了解自身能力半徑，確定業(yè)務(wù)發(fā)展的思路，云平臺的選擇，技術(shù)發(fā)展上的方向之后，綜合考慮文中提到性能和靈活性，擴展性和穩(wěn)定性，開放性和集成度，成本和收益的種種要素。

        

我相信，行業(yè)千差萬別，技術(shù)也層出不窮，但千變?nèi)f化之中，總有普適性的道理可以遵循，總有常規(guī)的邏輯可以分析，總有成功或者失敗的案例可供參考，而我們得出的結(jié)論并不是硬件SDN和軟件SDN誰更是主流。而是這個答案，能否幫助你在實際的業(yè)務(wù)中達到要求，解決問題，實現(xiàn)增長。

所以你要是問我的答案是什么，對不起，我真的很難直接告訴你，因為我的答案，未必就是你的，我也在不斷的學(xué)習(xí)，不斷推翻自己的結(jié)論。

        

在這個旅程中，我看到了互聯(lián)網(wǎng)公司對性能的要求，對靈活性的追捧，也看到了金融行業(yè)對穩(wěn)定性的執(zhí)著和對創(chuàng)新的渴望，我看到了制造業(yè)對物聯(lián)網(wǎng)，工業(yè)互聯(lián)網(wǎng)的思考，也看到了政府和公眾事業(yè)，對自我業(yè)務(wù)IT重塑的決心。

        

數(shù)字化醫(yī)療，新零售，無人駕駛，5G，各種新的業(yè)務(wù)場景帶來了企業(yè)數(shù)字化轉(zhuǎn)型的各種可能，這其中，有失有得，有固守，亦有革新，如果你讓我究竟SDN的路該如何走，那我們不如找個機會一起坐下來。

聊一聊，看一看……

PS：唉，寫到這里，又超了不少字，很多人已經(jīng)不愛看超過3k字以上的微信文章了，不過我也懶得再去為了分割而分割，文字也是一個記錄，僅從記錄本身而言，多少字并無關(guān)系。下一期打算寫一些技術(shù)類的文章，還請大家多多監(jiān)督，避免爛尾。

TF Live丨KK/建勛：多云、SDN，還有網(wǎng)工進化論

技術(shù)雜談-再談軟硬SDN（1）

網(wǎng)站欄目：技術(shù)雜談-再談軟硬SDN（2）
網(wǎng)頁網(wǎng)址：http://vcdvsql.cn/article24/pccgce.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供虛擬主機、網(wǎng)站內(nèi)鏈、云服務(wù)器、搜索引擎優(yōu)化、小程序開發(fā)、品牌網(wǎng)站制作

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)