技術雜談-再談軟硬SDN(1)

以下文章來源於微信公衆號:網絡裏賣藝的小青年 ,作者KkBLuE

【直播回顧】TF Live丨KK/建勳:多雲、SDN,還有網工進化論

我曾在SDNLAB和TF中文社區聯合舉辦的直播活動上做了一次分享,討論到軟件SDN和硬件SDN的話題,巧合的是,看到國內大牛廠家也在討論軟硬之路,於是就有了本文的第一篇,文章比較長,需要閱讀5-10分鐘。

DCN 學院派丨數據中心網絡自動部署,軟硬SDN如何選擇?

強烈建議,對軟件SDN不瞭解的同學一定讀一下,裏面有很多中肯之語,但是裏面很多語句也有待商榷,因此摘錄一下,說說自己的看法。撰文之前,先說幾點聲明:

(1)選取本文絕非針對特定廠家,任何廠家均有優秀之處,值得學習的東西太多太多。
(2)軟硬SDN的討論一直是長期話題,本人目的絕非否定硬件SDN,而是闡述本人所見所感,供大家參考。
(3)沒有絕對完美的方案,只有適合與不適合,所有IT和網絡的進步,都是原有技術方案的認知積累和不斷反思創新的結果。

請先看完原文之後在看本文,再次強調:本文不會否定原文任何觀點,而是爲各位讀者補充提供另外一個視角,去看待SDN而已。

首先,從自動化能力的靈活性來看,自動化程度更多取決於不同廠家對網絡業務的理解能力和邏輯抽象水平,與軟硬方式相關性並不那麼高。比如在SDN的業務發放上,北美廠商沿用一貫簡單的多級表單的方式來下發業務邏輯。而國內廠家基本已經使用圖形化交互的方式,抽象層次更高、邏輯理解更直接,這一點值得爲國內廠家點贊。而目前逐步興起的意圖網絡,硬SDN廠商可用基於IT業務語言來自動化網絡的配置,甚至可以做到事前校驗、事後驗證等更高的自動化水平。軟SDN廠商則相對落後。
DCN 學院派丨數據中心網絡自動部署,軟硬SDN如何選擇?

特別認同這句話,自動化程度更多取決於不同廠家對網絡業務的理解能力和邏輯抽象水平這句話,看每個廠家的方案,都能體會到背後研發人員功底和水平,也正因如此,從討論技術實現本身的角度,我更傾向於國內廠商和國外廠商都各有可取之處,所謂文無第一,武無第二,蘿蔔白菜,各有所愛。但是本文中以SDN業務發放的舉例,用來討論網絡自動化程度更爲合適,用來討論硬件SDN和軟件SDN的比較上,略有脫節。

我們不妨換個角度,從數據中心對SDN的訴求角度而言,大家追求的目標是都是文中提到的IT業務語言到網絡設備配置的實現,這裏的訴求一個層面是管理配置界面的實現,是否邏輯通順,是否界面整潔美觀,是否滿足基本需求,另一個層面纔是配置的實現由軟件還是硬件來完成。如果我們用SDN軟件管理界面的喜好程度,去評價軟硬SDN哪個更強的話,有一定道理但並非全貌。

管理配置界面的水平和能力,恰恰也是體現了不同廠家對業務的理解,而自動化程度的實現,恰恰取決於底層的實現,究竟是軟件還是硬件呢?文中對的第二段恰好給出了比較。

軟SDN在於其業務開發全部依賴於軟件實現,更靈活、迭代更快,能力可以不依賴於硬件快速更新。但實際商用時也有嚴格的版本策略,並且需要考慮將對性能影響嚴重的特性如加密、封裝卸載在網卡上。總體而言,軟件方式身段更靈活一點,但因爲完全依賴CPU也面臨較多約束。所以在這一點上,更應該側重考察的是,不同廠家不論軟硬方式,其在自動化能力上表現出的不同眼界和實踐水平。
DCN 學院派丨數據中心網絡自動部署,軟硬SDN如何選擇?

本文的觀點十分中肯,軟件更加靈活,其實是否全部依賴CPU有待商榷,提到的CPU會有較多約束,只看到結論,如何證明這個結論,我需要進一步去學習研究。其實太靈活,意味着對掌控的人的要求更高,我想,任何一個技術的嘗試,最終是都達到效果,與有使用者的能力半徑,技術的實現邏輯,方法都有關係。當選擇硬件產品的時候,會參考彩頁,看端口,看功能支持,同樣的道理,當選擇軟件方案的時候,我們同樣需要考慮版本適配,性能考量,做到知己知彼。兩者參考的方面不同,但是背後的邏輯是一樣的,更重要的是,看看業務對網絡的需求在哪裏。

其次,從網絡的可擴展性來看,二者能力不分伯仲。二者均可以構築大規模的SDN網絡,包括支持跨域多DC的級聯網絡。軟SDN可以靈活犧牲服務器資源來置換網絡資源,所以在租戶、VPC等規格上可能會超過硬SDN在交換機上的硬件資源限制,然而當前主流交換機規格基本不存在瓶頸,所以這個優勢無法體現到實際項目價值中。暫且認爲二者在此打成平手。
DCN 學院派丨數據中心網絡自動部署,軟硬SDN如何選擇?

網絡的擴展性,粗淺的說,取決於如下要素,性能,彈性,功能支持。

  • 性能:泛指吞吐,轉發,以及相關的表項支撐
  • 彈性:泛指自動化程度,擴展程度,網絡設備能否隨業務快速的變化
  • 功能支持:除了網絡中的功能支持之外,在虛擬化或者說雲的DC裏面,也增加了諸如NAT,FW,以及相應的服務鏈的支持。

從我的角度來看,擴展性是一個綜合工程,如果套用木桶理論的話,前文提到的這些,都是木桶中的每一個木板,而擴展性如何,取決於最短的哪塊,要評價,估計在寫幾萬字都寫不完,我們還是簡單粗暴,列出如下兩個問題:

1.軟件SDN比硬件SDN靈活,但是性能不如硬件SDN,硬件SDN的性能毋庸置疑,那麼軟件的性能到底如何?能否滿足需求?是否我們還是用早期軟件SDN的性能的早期印象,從而看待現在的軟件SDN的性能?
2.硬件SDN不如軟件SDN靈活,那麼硬件SDN在靈活性方面,有哪些是可取之處,哪些又是天然不足,還有哪些可以後續不足呢?

大概真的沒有十全十美的方案,真正落地的使用,都是客觀技術和主觀喜好的綜合。很早以前,我有兩個工作選擇,問一個前輩怎麼辦,前輩說你拿一張紙吧,題目就是兩個工作A和B,然後A寫清楚好的有哪些,不好的有哪些,B寫清楚好的有哪些,不好的有哪些,最好在加上自己現在的工作,不敢保證你選的對不對,但至少有過思考,可能選錯了,也不後悔~

談及軟SDN和硬SDN,道理大概也是如此吧。

但是,技術人員總有追求完美的慾望,如果我們把SDN的功能拆解,部分功能交給軟件完成,部分功能交給硬件完成,採用結合的方案,揚長避短,可能會有更有意思的話題出現,這個話題我們可以在後面的文章進一步討論。

第三,在實際的網絡部署中,可靠、穩定是重中之重。沒有人會容忍一個頻繁掉鏈子的網絡。這一點硬SDN天然具備更佳的身位,其從早期一路積累的商用可靠性能力有巨大優勢。而軟SDN通過vSwitch也提供了故障切換的能力,但作爲業務軟件依然受限於軟件特有的可靠性問題。此外,軟SDN會給網絡運維團隊帶來新的挑戰,運維邊界需要延伸到服務器內部,服務器運維在網絡和業務團隊部分疊合,存在衝突的可能。所以我們看到,敢於使用軟SDN的基本是互聯網廠家,自身擁有較強的技術能力來克服這個問題也是一個重要原因。
DCN 學院派丨數據中心網絡自動部署,軟硬SDN如何選擇?

網絡的穩定性,一直以來,任何人都毋庸置疑,越是貼近市場的業務,越是敏感,越是賺錢的業務,越是不容有失,這一點,我們可以看到互聯網公司,運營商,金融企業,以及其他大型企業,都有對穩定性的渴求,而穩定性,恰恰又是另外一個木桶。

而這個木桶裏,除了包含硬件的穩定性之外,還包括網絡的高可用設計,故障恢復的機制等等,可能硬件運行沒有問題,可一個生成樹成環就讓網工死去活來的。對於硬件SDN和軟件SDN穩定性和可靠性誰更優異,如果沒有充分的案例和素材,我本人不敢做出評價,希望看過這本文的兄弟姐妹可以給我更多素材。

正如文中所說,互聯網廠家敢於使用軟SDN,想必他們對穩定性方面有自己的看法,找機會和互聯網的兄弟們聊聊,據我所知,國內的AWS,Azure和GCP,國內的BAT,軟件SDN的方案還是居多,結合我前面的說法,其實他們的技術能力和掌控能力有關係,這又是一個新的話題,這裏就不多說。

文中引出的一個話題更吸引大家的關注,並非技術的實現,而是管理的邊界,簡而言之,當使用軟SDN的時候,因爲執行點在服務器,那麼該誰管呢?擴展點說,誰來配置,誰來維護?粗俗點說,出事了,誰管?

必須承認的是,運維的衝突,是客觀存在的現象,但我們稍作反思,這是一個管理的問題?還是技術的問題?

雲帶給行業的改變,不止於業務形態,技術的改變,對於組織架構,管理模式,分工協作,也都帶來改變。

恰恰是市場需要企業的業務具備敏捷性,才引發了企業的業務要求IT的敏捷性,也正是因爲有了IT的敏捷性需求,纔會有雲的興起,而正是有了雲的興起,纔會有網絡和業務的關聯度如此之高。因此,以前是IT組織下各司其職的各個部門,現在正是需要一起坐下來,重新制定戰略和業務分工,我們看到很多的客戶在IT內部,專門成了雲業務部門,核心的原因,就是希望打破原有的壁壘,讓整個IT有機結合起來。

但是組織的變革也勢必帶來挑戰,管理的權限,能力的學習,部門之間如何攜手,這裏有太多的思考,而這個衝突,我更傾向於是管理的思考,未來企業IT的掌舵人以及所有從業人員的思考,而軟硬SDN的穩定性討論方面,我們更多還是需要關注在技術實現和設計架構上。

一不小心,3000多字,數字化轉型,雲計算,SDN從來就不是單一的問題,更多的角度,會帶來我們更多的思考,華爲的這篇文章,幫助我們看到了實現SDN的各種可能,我的文字,希望提供另外一個角度,更傾向於引出更多的思考,而不是武斷的得出結論,言辭也一定侷限之處,希望能和同道更多的交流學習,我們下期再會。

沒有冬天不會過去,沒有春天不會到來!

【直播回顧】TF Live丨KK/建勳:多雲、SDN,還有網工進化論


技術雜談-再談軟硬SDN(1)

技術雜談-再談軟硬SDN(1)

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章