網路為何要軟體定義?看清SDN的牌局

来源:本站原创 专业IT吐槽 超过1,601 views围观 0条评论

OpenFlow只是一個協定,就像USB Disk所使用的USB協定一樣,真正有價值的是USB Disk裡的資料,而非這個協定。同樣的,在「以服務驅動的架構」之下,有價值的不是OpenFlow這個協定,而是透過它所建構的服務。

自從SDN(Software Defined Network,軟體定義網路)2012年開始成為熱門議題,延燒到2013年仍是各家網通廠商極力宣傳的關鍵字。筆者常在許多演講或私下場合被問到相關技術的市場概況,雖然樂見業界認同SDN的概念,但也擔心SDN淪為充斥混淆訊息的行銷名詞,非但無法呈現其商業價值,反而日後可能成為票房毒藥。
其實在今日SDN並不是一個「民生必需品」,因為多數的網路環境,沒有它照樣可以運行得很好。但是從熱門的雲端相關應用Infrastructure as a Service、Platform as a Service與Software as a Service等來看,可以發現一個共通點,那就是「Service」。
以「服務」的角度驅動網路建構所需要的環境,並且根據實際網路需要的狀態,提供程式化的服務策略及規模的需求,才是我們對於SDN的需要。
這也是當前硬梆梆的網路概念所無法支持的「以服務驅動的網路基礎架構」(Service Drives Network Infrastructure)觀念。
讀者可以思考,目前維運的網路是否真的需要這種投資。什麼樣的環境才會需要這種高靈活及彈性的網路?一定不是靜態的伺服器或是大型主機,因為這些設備就像大樹一樣屹立不搖,或許多年也不會有變動網路的需求。
但是被高度虛擬化的伺服器(Server Virtualization)可就完全不一樣了,Hypervisor根據用戶或是服務運行的狀態被動地產生、刪除、變更、搬移,越來越多應用的環境已經完全架構在伺服器虛擬化之上,這對網路營運來說就是很大的負擔,因為我們使用的網路概念就像工作了超過30年的老先生,已經跟不上這個跑在雲端上的年輕小夥子所需要的彈性和速度。
多租戶雲非SDN不可
若問哪種網路環境一旦沒有SDN就幾乎無法順利營運,目前看來,多租戶的雲端(Multi-Tenancy Cloud)環境會是首當其衝的痛苦者(Sufferer)。以下舉幾個例子,希望能幫助讀者了解這個網路層面上的苦難。
VLAN數量不足
一個L2 Domain可用的VLAN數量至多支援4094個。如果用戶使用4個VLAN,整個網路只可規劃(provision)1000左右的用戶,並需要建構新的L2 Domain繼續提供服務,但是新舊的L2 Domain卻無法合併運用,而且平均網路背板(Fabric)的運轉效率可能達不到規模的30%。
TCAM記憶體不足(Memory Overflow)
一般機架交換機(ToR)僅需要服務20台左右規模的靜態伺服器,但在伺服器虛擬化之後,即使保守以1:10的比例來看,伺服器規模也會立刻成長10倍。
加上以VLAN Trunk為基礎的便利連結方式,每一個ToR因為VLAN Trunk所帶來的ARP訊息更會呈等比級數增加,最終導致TCAM Overflow成為單點故障。可怕的是,這個問題在許多的除錯過程(Troubleshooting)中不易察覺。
服務可控度低
前面提到以服務驅動基礎架構的議題,在這裡更可以看出更明顯的差異。以多租戶的雲端環境來看,每一個租戶的服務需求各有不同,所以網路管理員幾乎不可能以人力一一應對,用戶更不可能為此等待數個小時。與時間賽跑的商業服務,需要以SDN這樣的技術,建構具有高度彈性的基礎建設,才能符合雲端服務市場需求。
本末倒置的迷思
觀察SDN議題在市場上被廣泛討論,其主軸往往圍繞著OpenFlow這個協定,但OpenFlow真的是救世主方案嗎?筆者很幸運在前幾年加入Nicira公司(現為VMware網路及安全事業群),它是全世界第一個對OpenFlow進行產品化的商業公司,主要成員也是OpenFlow發源地史丹佛大學的早期開發團隊。
某次與發明OpenFlow概念的Nicira技術長Martin Casado對談時,他說,OpenFlow只是一個協定,就像USB Disk所使用的USB協定一樣,真正有價值的是USB Disk裡的資料,而非這個協定。
其實如果讀者理解前面所提到的「以服務驅動的架構」,到此應該可以理解,有價值的不是OpenFlow這個協定,而是透過它所建構的服務。所以SDN是不是民生必需品?未來不敢說,但至少今天可能是只有特定的服務型態,才需要它的支持。
OpenFlow兩大模式
在現今OpenFlow發展中,存在著兩個不同類型,一種是Hop by Hop模式,另外一種則是Overlay模式。

 

Hop by Hop模式
這是OpenFlow最早期的發展模式,Edge Device(OpenFlow交換器)將未知數據流的第一個數據封包發送給OpenFlow Controller作為路徑演算的條件,如果一條路徑需要經過5個Hop Count,這樣的行為至少重複5次才能畫出一條 Slice Topology,而OpenFlow Controller也就是坐落在Data Panel之上。
在公開網路中,如果透過這種模式進行Topology的學習,OpenFlow Controller將承受極大的流量壓力,成為最主要的瓶頸點。如果要預先載入Flow Table以解決學習的問題,先需要知道完整網路訊息以建立Slice Topology Flow,操作比傳統網路更為複雜。
Overlay模式
這是OpenFlow逐漸發展之後所開發出來的新型運作模式,透過API直接對OpenFlow Controller定義需求網路Topology的型態,並且發送Flow更新至Edge(OpenFlow交換器),Edge便可以根據Flow定義結果,在本地建立IP Tunnel作為數據轉發的橋樑。

▲Overlay模式透過API直接對OpenFlow Controller定義需求網路拓撲型態,並發送Flow更新至Edge (OpenFlow交換器),在本地建立IP Tunnel作為數據轉發的橋樑。

這個模式,因為OpenFlow Controller不坐落在Data Panel上,所以不會成為瓶頸點,並且透過IP Tunnel的模式,同時間也抽象化了物理網路,讓由Overlay模式所建立的邏輯網路,不受限於傳統L2網路邊界或設備可達範圍,只要是IP連線能到的地方,SDN Overlay Network就能存在。
目前在市場上,硬體架構的OpenFlow交換器的廠商還是以Hop by Hop模式為主。如果是以Overlay的模式運作,Open vSwitch是廣泛被應用的開放式交換器軟體,多半是安裝在服務虛擬化平台(Hypervisor)。 此運作模式是直接在內部連接虛擬伺服器及網路,無須基於OpenFlow的硬體交換器就可達成SDN的需求,尤其對於多租戶的雲端環境來說,節省了特殊硬體成本的開銷,也達成了服務驅動網路架構的目的。
為何使用Tunnel協定
近來市場上也有許多關於Tunnel協定的討論,如VxLAN、NVGRE、GRE或是STT,主要的課題鎖定在如何跨三層網路延伸二層網路,且應用場景幾乎都在高度虛擬化的資訊中心服務內,鎖定的痛點也都說明現今網路的規模不足及簡化網路的架構。這其實呼應了前文所提及規模化服務網路的需求,及根據服務驅動網路的概念。
Tunnel技術解決了L2網路規模化的問題,但並沒有完全命中簡化複雜網路的需求。因為這個概念只涉及L2網路連線的建立,而沒有滿足更細節的網路服務需求,如QoS、MAC Spoofing、ACL或是Layer 3及更高層服務網路的建立。
至於如何利用Tunnel傳遞更多的網路應用需求,便是OpenFlow Overlay架構的目標,而非建立規模很大但功能單純的網路來面對用戶複雜的需求。
往往有人質疑Tunnel的封裝會大量消耗操作系統CPU資源,但很幸運的是,今日許多晶片廠商已開發出x86系統上的卸載(Offload)機制,Tunnel協定本身更可以直接結合於核心(Kernel)之中,事實上在x86系統上,網路傳輸及同時降低CPU耗損的目標已經實現。
SDN方案誰提供
硬體網路技術已經非常成熟,產品差異變得越來越小,但服務需求的差異卻越來越大。如前面所說,網路必須有能力去面對各種不同的動態需求的挑戰,目前大致有幾種類型的廠商能夠提供相關服務:
1.成熟的網路設備商
這一類型的廠商是生產網路硬體設備為主,著重在效能及連接密度,為網路提供非常良好的傳輸媒介。這也是我們天天都在使用的網路設備。
2.SDN元件商
最重要的就是SDN Controller,畢竟Controller這個控制元件是SDN核心技術之所在。至於OpenFlow交換器,因為在功能上為接受者,所以雖然跟SDN的議題有相關,但畢竟不是主導元件,所以地位相對沒有Controller的廠商來得重要,但也還是必要元件之一。
3.網路抽象化(Abstraction)廠商
幾乎都是軟體和晶片廠商的天下,重點在於把現有的IP網路建立成一個背板資源池(Network Fabric Pool),讓用戶的網路可以被任意部署,不需要再為L2網路的邊界而傷腦筋,這也是讓服務網路規模化的新選擇,代表技術就是VxLAN、STT、GRE或NVGRE等等。
4.網路虛擬化(Virtualization)解決方案商
此類型廠商並非提供單一技術產品,而是全面性可以部署於生產環境的解決方案,包括了Controller、Edge Switch、Tunnel在同一方案之內,提供高度的網路效能、擴展性及靈活性。對於真正需要SDN網路的用戶來說,這才是所需要的統合式網路能力,而不再是元件堆疊後的一座危樓網路基礎建設。
一個都不能少
雖然受到業界的高度重視,但畢竟SDN自身無法變成一個獨立有價值的東西,真正有價值的是服務。網路、伺服器、儲存的關係是密不可分的,但是誰來協調這些元件?在雲端資訊中心裡,是由CMS(Cloud Management System)來扮演指揮者的角色,沒有了它,大家只不過是一群「烏合之眾」。
因為服務不可能單獨由網路所提供,伺服器沒有網路也無法傳遞服務,沒有儲存,重要的數據該何去何從?對雲端資訊中心的運轉而言,CMS是非常關鍵的工具,千萬不要忘記這個指揮官。
近期廣受關注的OpenStack就是一個代表性的CMS平台,透過協同運作的力量,擁有包含了8000名以上的個人會員、82個國家的社群、150家以上矽谷及其他地區的IT商業公司共同參與,全球超過600名的共同開發者。當然此外VMware vCloud、CloudStack等平台,也都是這方面出色的CMS平台。
所以當讀者如果開始做SDN的準備,希望不要忘記CMS這個重要指揮官。當然最重要的還是服務, SDN相關的技術則是扮演撐起服務的螺絲釘。
<作者:陳建民,曾任Nicira亞太區技術顧問,2012年VMware收購Nicira之後,現任VMware 網路虛擬化平台工程師,專精於資訊中心基礎建設規劃及內容應用安全。>

文章出自:CCIE那点事 http://www.jdccie.com/ 版权所有。本站文章除注明出处外,皆为作者原创文章,可自由引用,但请注明来源。 禁止全文转载。
本文链接:http://www.jdccie.com/?p=3190转载请注明转自CCIE那点事
如果喜欢:点此订阅本站
  • 相关文章
  • 为您推荐
  • 各种观点

暂时还木有人评论,坐等沙发!
发表评论

您必须 [ 登录 ] 才能发表留言!