【轉】淺談SDN

 

原文:https://zhuanlan.zhihu.com/p/144676870

----------------

 

最近工作啊學習啊,比較忙,少有時間抽出身來做其它事情,今天,簡單來說說一直很火又不溫不火的SDN,也就是軟件定義網絡。

作爲一名遊手好閒的網絡工程師,多年前,我就開始不看BGP、不看OSPF了,聽說SDN挺好,我決心要看看,玩一把新鮮,睡覺前,想起了一個什麼概念,起來加個夜班,網上翻翻資料,甚至會因爲對某一個知識點的新領悟弄得興奮不已輾轉反側,然而,然而,現實確是殘酷的,因爲,瞎折騰了許久,還是,無從下手,不少小夥伴其實都有類似痛苦,不是不願意學習,而是,說起SDN,很多時候是真不知道從何學起。

SDN是一個很寬泛的概念,分爲很多的技術流派,但主要,還是分爲以下幾類:

第一類:網絡設備廠商派系——要玩一起玩,不然,再見!

這裏,說說網絡廠商的大爺CISCO數據中心級別SDN,思科作爲宇宙最大牌的網絡設備廠商,早些年也參與了很多網絡協議的制定和規範,穩穩地處於leader地位,當然也有很多自己的私有協議,據說部分也已經開放了,但其實不重要,思科在SDN領域內其實逐漸在喪失話語權,所謂軟件定義網絡,如果你不懂軟件,那就更別說使用軟件去定義了,思科的SDN方案很有意思,最終交付給用戶的就是幾臺服務器和一堆交換機還有一套軟件,這套軟件就是SDN的大腦,聰明的你只需要登陸上web控制檯,手別抖,鼠標拿穩了,點點點,點完了,完成配置了,可以交付了,這時,花了幾萬大洋考過CCIE的你會有種被侮辱的感覺,擺明了讓你難堪,但是思科的SDN就是這麼簡單,不需要敲什麼命令,你甚至可以不懂BGP不懂vxlan,讓你真正體驗到用tplink的方式去操作cisco,交換機一堆控制器幾臺足夠提供可靠性,SDN上線後,在性能上,10G-100G轉發都不是問題,管理上,簡化了網絡變更時繁雜的操作步驟,不再需要逐個設備去敲命令,一堆設備一個控制檯即可搞定,你還可以制定各種不同的業務路徑鏈接起來形成一套標準化的策略,比如和防火牆和負載均衡進行聯動,聽起來高大上,但是軟件定義你都玩完了,那身爲用戶的我們玩啥,廠商說,沒關係,我把API提供給你,你可以自己進行二次開發,但,前提是,你必須帶上我一起玩。

身爲老大哥思科的方案這麼定了,於是華爲、華三的方案也都來了,大同小異,但各廠商之間協議不互通,可謂是戴着鐐銬在舞蹈,畢竟,廠商是要充分考慮盈利問題的,賣設備賣平臺半點不馬虎,至於使用體驗,若有機會,我會加入各個廠商SDN方案的詳細部署和簡單使用評測,這裏先不作評論。

第二類:虛擬化派系——會玩自己玩,不會玩我帶你玩

說到軟件廠商,曾經思科的盟友VMware,在虛擬化方面這家廠商持續保持着全球第一的份額,他們家SD(軟件定義)的範圍非常廣,服務器是虛擬出來的,存儲是虛擬出來的,網絡自然也是虛擬出來的,當之無愧的軟件定義,曾經,思科開特意爲VMware開發了一款虛擬化交換機,但在vxlan技術廣泛使用後,兩兄弟分道揚鑣,VMware說,只要保證我的網絡能通,我都能給你虛擬化了,交換機、路由器、防火牆、負載均衡都不用買設備了。思科表示納悶,那你還要我幹嘛?分手!於是,各奔東西。vmware的SDN方案使用了vxlan技術,在現有底層網絡的基礎之上虛擬出一張大二層網絡,這就是Overlay網絡,所以並不關心你是用思科華爲誰家的交換機,虛擬化之後的網絡功能可以在每個節點(esxi)上進行實現,理論上來說,或多或少會影響到節點的性能,另外從節點出局後依舊需要依賴底層網絡,雖然不關心品牌型號,但底層網絡的高效性和穩定性也是VMware解決方案的必備基礎條件,由於是運行在各個節點之上,控制使用一套單獨控制系統,同樣,控制與轉發是分離的,即使節點掛了網絡組件隨即失效,虛擬機可以飄走,也不會有太大影響。還有一個問題應該考慮,即便不買硬件設備了,那麼軟件價格呢,我想還是聊點別的,VMware的確是好,但同時,也是真的貴。

虛擬化產品非常豐富,除了VMware,還有像Xen、KVM等,早幾年火爆的OPENSTACK則是用來解決若干臺服務器同時運行KVM的管理調度問題,通俗的說,就是一個雲計算管理平臺項目,OPENSTACK的網絡組件叫Neutron,我們也可以使用其他開源的網絡組件,比如OpenVSwitch(簡稱OVS),也有很多商業化的SDN產品,如BigSwitch的方案,同樣,都是爲了解決節點的網絡互通性問題,區別在於不同的產品方案使用了不同的方法技術並提供了差異化的功能和服務。

不得不提及到的是,服務器虛擬化技術的誕生大大降低了企業服務器採購成本,通過虛擬化企業用戶可以輕鬆建立自己的私有云,當然,使用久了,弊端便開始顯現了,例如我所在的企業,虛擬機開了兩千臺,但是資源利用率並不高,監控顯示,這兩千臺虛擬機中,計算資源使用率普遍較低,新的問題因此而來,比如有臺8核8G硬盤200G的服務器就跑了一個NTP服務,爲了提高服務可靠性,又加了一臺同樣配置的虛擬服務器組成了集羣,CPU/內存利用率常年處於1%以下,這樣的情況非常常見,很浪費,解決方案其實也有,那就是服務容器化,當前最流行的容器化技術非Docker莫屬,一臺服務器(虛擬機或者物理服務器)可以運行多個容器,同時提供多個服務,直到你認爲這臺服務器性能用到差不多了爲止,但你認爲畢竟是你認爲,倘若這臺服務器運行的容器數量過多,性能被榨乾,服務全掛掉大家誰都別想好,於是又有Kubernetes(簡稱k8s)來幫你解決,k8s解決了多臺運行容器服務的服務器之間的服務編排和資源調度問題,若干個容器組成的集羣同時提供一個服務,即便是其中某個容器因爲所在服務器的問題無法提供服務,集羣中還有其他容器可用,業務依舊會正常運行,講這麼多,引出來另外一個話題,那就是容器化之後的網絡,容器和容器之間怎樣通信?容器和服務之間怎樣通信?容器和外部又是怎樣通信? 這其實依舊是虛擬化網絡的一個部分,逃不開軟件定義網絡的範疇,作爲一個開源項目,搞不明白爲何谷歌自己沒有把網絡這部分充分考慮進去,也因此,k8s中最複雜的應該就數網絡架構,當前,k8s的網絡插件也越來越多,flannel、calico、Weave等,有足夠的技術能力,可以自行開發適合企業本身的網絡插件,但技術本身很有可能是我們無比熟悉的,比如flannel使用的vxlan、calico可使用ipinip(gre)或者是bgp,這些在路由器上隨手就能敲出來的技術,搬到SDN上來,可能會令你一臉茫然,啥,這還是我熟悉的BGP麼.......

第三類:OpenFlow派系——純正意義上的SDN

OpenFlow是一種SDN控制層面的網絡協議,從最早的1.0版本發佈至今,已經超過10年,目前最新版本爲1.5,各大網絡設備廠商均有設備支持,應用較多的版本爲1.3,其工作模型中,也同樣將控制層面與轉發層面進行分離,Controller負責將流量控制策略以流表形式下發給受管理的網絡設備,交換機設備只需要按照流表上制定的流表項進行逐一匹配和轉發,如此一來,也很容易實現對於每個網絡節點設備的統一管理,這裏強調一點,SDN的初衷並非是要解決網絡性能上的問題,對於傳統網絡而言,除了管理方式上的改變帶來運維效率提升外,很難找到更多的功能亮點,只有在虛擬網絡中,比如kvm、k8s環境,基於OpenFlow的虛擬交換機或許能夠解決一些功能上的問題,目前支持OpenFlow的控制器有很多款:OpenDaylight(簡稱ODL)、ONOS、Ryu等等,雖然市面上很多交換機支持OpenFlow,但是也只是支持,是否能夠很好的與控制器匹配工作,有待驗證,大概,未來的某個時刻,會有越來越多的白盒OpenFlow交換機取代現有傳統交換機,企業中的網絡將成爲一套系統,而不再是一臺一臺的網絡設備,當然,這還需要一個漫長的過程,至少當前,網絡廠商是排斥的。

這些如同雨後春筍的SDN網絡新技術,看上去是對工程師的要求越來越高了,但我認爲,這也是SDN發展緩慢的原因之一,大多數網工不懂程序語言,正如OpenDayLight控制器,倘若沒有java基礎,入門較困難,Ryu是用Python寫的,若不懂Python,也很難有所成就,同樣,在國內,程序猿們可能對網絡一無所知,他們大多數不理解交換機CAM表不懂得ARP工作原理,也不知道IP尋址路由等等,他們開發的程序更多的使用對象是用戶,可能是公司的核心業務,而網絡只是基礎架構中的一個部分,上級部門是否願意花費財力和人力進行相關開發也是一個很大的問題。

爲什麼要用SDN

技術是好東西,它能解決問題創造價值,然而使用不當將會帶來更多的問題,講這麼多,憑什麼我一定要選擇使用SDN呢?若公司就一個網工兩臺服務器四臺交換機,那是沒必要,還是老老實實迴歸傳統,稍有規模的企業數據中心,可能會有需求,以下幾個案例:

案例一:部署思科的數據中心SDN解決方案,提升業務發佈與故障排查效率;

案例二:通過VMware的SDN解決方案建立大二層數據中心網絡,實現主機的異地遷移;

案例三:服務容器化部署過渡期,使用OVS解決容器環境與外部網絡非NAT類型的互通。

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