SDN,請別忽悠我(1)

責(zé)任編輯:editor007

作者: 賈彥民

2015-01-14 21:19:49

摘自:北京品科科技

現(xiàn)如今,在網(wǎng)絡(luò)界炒作的最熱鬧的概念莫過于軟件定義網(wǎng)絡(luò)(SDN, Software Defined Networking)。大規(guī)模多租戶云計算數(shù)據(jù)中心(Multi-tenant Cloud Computing Data Center)要求隔離不同租戶的應(yīng)用,而動態(tài)變化的應(yīng)用之間要建立成千上萬的網(wǎng)絡(luò)連接

現(xiàn)如今,在網(wǎng)絡(luò)界炒作的最熱鬧的概念莫過于軟件定義網(wǎng)絡(luò)(SDN, Software Defined Networking)。一時間,SDN風(fēng)生水起,凡是提到網(wǎng)絡(luò),言必稱SDN。仿佛有了SDN,從此網(wǎng)絡(luò)就要走上一條鋪滿鮮花的康莊大道了。但熱鬧了一陣子之后,SDN的應(yīng)用卻是雷聲大,雨點小,只聽樓梯響,不見人下來,真正端得上臺面的只有可憐兮兮的Google一個案例,用來連接Google各個數(shù)據(jù)中心的B4 WAN網(wǎng)絡(luò),勉強算得上差強人意,卻也看不出有什么普遍推廣的意義。其他的所謂殺手級的應(yīng)用(Killer Application)不過是存在于宣傳家的噱頭和運行在研究者實驗室的Mininet上。也許如下幾點可以解釋其中的原因。

首先,SDN是模式遷移(Paradigm Shift)的大動作。SDN所謀者大,不是原有技術(shù)之上的添磚加瓦,也不是原有系統(tǒng)框架的修繕補闕。SDN時代的到來,網(wǎng)絡(luò)界將面臨數(shù)十年未有之變局。正如Thomas S. Kuhn的著作The Structure of Scientific Revolutions中所描述的科學(xué)革命的模式遷移一樣,SDN是網(wǎng)絡(luò)技術(shù)領(lǐng)域的結(jié)構(gòu)性的革命性的模式遷移。這種模式遷移都不是一朝一夕能夠完成的??茖W(xué)發(fā)展的歷史上,從Ptolemaic的地心說到Copernicus的日心說(Copernican Revolution),從Aristotle的力學(xué)到Newton的力學(xué),從Newton的萬有引力到Einstein的相對論,以及原子理論的發(fā)現(xiàn),無不經(jīng)過了長期的痛苦的掙扎,才得以從舊的理論過渡到新的理論。雖然SDN不能和上面列舉的科學(xué)革命相提并論,但是SDN絕不是傳統(tǒng)L2/L3網(wǎng)絡(luò)的development-by-accumulation式的量變過程。眾所周知,SDN最基本的原則包括隔離控制平面(Control Plane)和數(shù)據(jù)平面(Data Plane),管理集中化(Management Centralization),和可編程(Programmable)。這就決定了SDN是另起爐灶從而重建傳統(tǒng)網(wǎng)絡(luò)的運行模式、管理模式和開發(fā)模式的質(zhì)變跳躍。與此同時,SDN的出現(xiàn),也改變了網(wǎng)絡(luò)提供商和客戶之間的關(guān)系。交換芯片(ASIC)商業(yè)化的實現(xiàn),網(wǎng)絡(luò)客戶有機會實施白盒子(White Box)策略。在建設(shè)網(wǎng)絡(luò)設(shè)施時,能夠以BYOD( Bring Your Own Device )和BYOA( Bring Your Own Application )的方式采購組合不同供應(yīng)商的軟硬件產(chǎn)品,不僅節(jié)約了成本,也大大減少了網(wǎng)絡(luò)客戶與單一供應(yīng)商綁定的風(fēng)險。傳統(tǒng)網(wǎng)絡(luò)供應(yīng)商的收益也因此受到影響,利益所關(guān),他們會或多或少抵制這一轉(zhuǎn)變的進程。所有這一切都決定了SDN不可能一蹴而就。

其次,SDN的實現(xiàn)面臨諸多挑戰(zhàn)。控制平面和數(shù)據(jù)平面的分離使得Controller要管理成千上萬臺交換機,并且還要滿足網(wǎng)絡(luò)規(guī)模動態(tài)的(Dynamic)可伸縮的需求。實現(xiàn)這種可伸縮性(Scalibility),對于大規(guī)模的網(wǎng)絡(luò),當(dāng)然不是單獨的一個Controller所能承受之重,需要采取分而治之(divide and conquer)的策略,即將網(wǎng)絡(luò)分成不同的部分,由多個Controller分別管理。這又會引起其他問題,為了向上層應(yīng)用提供統(tǒng)一的網(wǎng)絡(luò)視圖(Network View)和北向開發(fā)接口(North-bound API),使得上層應(yīng)用的開發(fā)者可以只面對單一的邏輯的基于Controller的應(yīng)用開發(fā)平臺,Controller之間需要做復(fù)雜的數(shù)據(jù)同步,這些數(shù)據(jù)包括網(wǎng)絡(luò)拓撲變更、鏈路端口狀態(tài)、流量(Traffic)統(tǒng)計信息等等。Controller也可能因故障退出或宕機,所以,還必須有相應(yīng)的機制保證系統(tǒng)的可靠性(Reliability),比如采用Master/Slave的架構(gòu),這無疑又增加了數(shù)據(jù)同步的復(fù)雜性。實踐證明,越是復(fù)雜的系統(tǒng)越是難以部署和維護。必須使用有效的技術(shù),來解決可伸縮性和可靠性的問題,從而得到高可用性(Availability)的SDN解決方案。聲勢浩大的Open Source項目OpenDaylight迄今也才發(fā)布一個開發(fā)者版本,也許可以作為SDN具有高難度和高挑戰(zhàn)性的一個明證。SDN的實現(xiàn)還要克服硬件的限制,目前,市場上真正的SDN的芯片還不多見。比如說所謂的OpenFlow交換機,大都是采用變通的方法來實現(xiàn)的。因為昂貴的TCAM表的大小非常有限,就只能拿交換機L2的轉(zhuǎn)發(fā)表(FIB)和L3的路由表(RIB)來湊數(shù)。這樣一來,Controller給交換機下發(fā)的Flow Entry必須要和轉(zhuǎn)發(fā)表的表項或路由表的表項相一致,因此Flow Entry的匹配條件(match)和動作(action)就要受限于MAC表和路由表的表達能力。開發(fā)者會不經(jīng)意間發(fā)現(xiàn),表面上做的東西看起來是高大上的OpenFlow和SDN,到頭來玩的還是原來的L2的轉(zhuǎn)發(fā)(Forwarding)和L3的路由(routing)。就好像夢中以為自己是在開飛機了,醒來一看屁股底下坐的還是原來的拖拉機埃因此,Google的B4網(wǎng)絡(luò)就只好使用自己定制開發(fā)的OpenFlow交換機。另外,SDN還要實現(xiàn)自身網(wǎng)絡(luò)與外部L2/L3網(wǎng)絡(luò)的路由轉(zhuǎn)換,以達到SDN網(wǎng)絡(luò)和L2/L3網(wǎng)絡(luò)的互聯(lián)互通的目的。

最后,網(wǎng)絡(luò)向SDN的變遷(Migration)尚沒有可行的廉價的解決之道。盡管SDN的優(yōu)越性和美好前景被傳說的活靈活現(xiàn)。如利用SDN可以大規(guī)模減少客戶的CAPEX(Capital Expenditure)和OPEX(Operating Expense),提高設(shè)備的投資回報率(Return on Investment),如2015年SDN的市場規(guī)模將達到幾十億美元。但對客戶而言,包括運營商、云計算數(shù)據(jù)中心(Data Center),以及企業(yè),都不會傻到立馬將自己網(wǎng)絡(luò)基礎(chǔ)設(shè)施切換到SDN模式,因為對自身業(yè)務(wù)的影響和風(fēng)險沒有辦法準確評估。另外,從上面對SDN的技術(shù)難度的分析可以看出,傳統(tǒng)網(wǎng)絡(luò)到SDN的轉(zhuǎn)換也絕非易事。在傳統(tǒng)網(wǎng)絡(luò)和SDN之間并不存在一個雙向開關(guān),只要簡單地把這個開關(guān)置為SDN模式就萬事大吉了,必要的時候,還可以再切換回來。因此,大多數(shù)客戶對SDN還是會選擇謹慎的態(tài)度,或持續(xù)觀望,或以小的項目進行探索性的嘗試。

從另一方面講,網(wǎng)絡(luò)的確到了不得不變革的時候了,這基本上是一個業(yè)界的共識。一方面,傳統(tǒng)網(wǎng)絡(luò)的控制平面分布在五花八門的不同提供商的設(shè)備上,通過各種網(wǎng)絡(luò)協(xié)議將這些設(shè)備連接在一起,需要一個設(shè)備一個設(shè)備的人工配制。因此,這是一個靜態(tài)配制的復(fù)雜的脆弱的系統(tǒng),部署一個網(wǎng)絡(luò)系統(tǒng)頗費時日,往往需要幾天甚至幾個星期的時間。難得的是,網(wǎng)絡(luò)的這一模式已經(jīng)保持了20多年基本沒有變化了。另一方面,運行在網(wǎng)絡(luò)平臺上的應(yīng)用伴隨著互聯(lián)網(wǎng)革命的興起卻發(fā)生了深刻的變化。尤其是云計算和移動計算的到來,要求應(yīng)用或服務(wù)的部署要以妙級的速度完成,而不是幾天或幾個星期。而且這些服務(wù)或應(yīng)用要求很高的彈性(Resiliency)和靈活性(Flexibility)。如臭名昭著的火車票網(wǎng)上訂票系統(tǒng)12036就是沒有解決好服務(wù)的彈性和靈活性的問題,在節(jié)假日的售票高峰期,系統(tǒng)基本處于癱瘓狀態(tài)。大規(guī)模多租戶云計算數(shù)據(jù)中心(Multi-tenant Cloud Computing Data Center)要求隔離不同租戶的應(yīng)用,而動態(tài)變化的應(yīng)用之間要建立成千上萬的網(wǎng)絡(luò)連接。比如,一般地,一個Web/Cloud Application分為表示層(Presentation Tier)、業(yè)務(wù)邏輯層(Business Tier)和數(shù)據(jù)層(Data Storage Tier)。這樣的層次結(jié)構(gòu)就是為了滿足應(yīng)用的靈活性和安全性。在三層之間必須建立多條網(wǎng)絡(luò)連接以進行數(shù)據(jù)交換。網(wǎng)絡(luò)連接的建立需要一個設(shè)備一個設(shè)備的人工配置。隨著應(yīng)用數(shù)量的增長,當(dāng)前的靜態(tài)的網(wǎng)絡(luò)模型承受的壓力也會越來越大。互聯(lián)網(wǎng)應(yīng)用和服務(wù)的這種變化和網(wǎng)絡(luò)模型的不變是一個尖銳的矛盾,傳統(tǒng)的網(wǎng)路模型面對互聯(lián)網(wǎng)的應(yīng)用和服務(wù)需求就好像電影《讓子彈飛》中用馬匹來拖動沉重火車頭一樣力不從心。雖然,電影里面看起來幾匹馬拉著火車頭在鐵軌上歡快地奔馳如飛,但電影畢竟是電影。解決這個矛盾的技術(shù)是虛擬化(Virtualization),計算資源和存儲資源的虛擬化已經(jīng)基本完成,因此,普遍認為,網(wǎng)絡(luò)業(yè)已成為虛擬化和云計算的最后一塊絆腳石,而SDN是解決網(wǎng)絡(luò)虛擬化的有效手段。總而言之,對于SDN的起步公司(Start-up)而言,SDN是大勢所趨,一定會發(fā)生,所以要有信心;SDN是一個過程,不會馬上發(fā)生,所以要有耐心。我篤信,一定會有致力于SDN的起步公司在網(wǎng)絡(luò)模式遷移的大潮中取得巨大的成功,甚至?xí)娲?dāng)前網(wǎng)絡(luò)產(chǎn)業(yè)界如Cisco那樣的大鱷。但究竟鹿死誰手呢?我沒有足夠的數(shù)據(jù)來給出可信的分析和預(yù)測。以下的幾點看法是我的一些小見識。

不能迷信SDN。SDN不是像一些中醫(yī)神棍胡吹的包治百病的“神藥”,人世間,這樣的“神藥”從來就沒有存在過。SDN是新的模式(Paradigm),所以很適合用來空談吹牛。但SDN的確給出了特有的方法論和相應(yīng)的工具或模型,但從來不是具體的解決方案。所以,起步公司要根據(jù)用戶的具體需求,給出自己的SDN解決方案,開發(fā)出相應(yīng)的產(chǎn)品,來幫助用戶解決問題,在給用戶帶來實實在在的價值的同時,實現(xiàn)自己的價值。在開始一個SDN項目之前,要清楚的知道期望解決的問題是什么,達到的目標是什么,得到的好處是什么。B4之所以成功,就是因為問題和目標非常明確,那就是通過基于SDN的流量工程(Traffic Engineering)提高WAN的物理連接的利用率。

[page]

不能為SDN而SDN。如上文所述,在網(wǎng)絡(luò)模式遷移的浪潮中,我們要理解這一根本變化對網(wǎng)絡(luò)世界的意義和影響。抱殘守缺,腳步向前走,眼睛往后看,都不會有所作為。這就意味著我們不能再固守原有的L2/L3的網(wǎng)絡(luò)技術(shù)了,不能將SDN視為對現(xiàn)有網(wǎng)絡(luò)模型的重新實現(xiàn)。若認識水平局限于此,就將錯過SDN的大風(fēng)景。比如,如果把下面的例子看作SDN的全部就大錯特錯了:基于OpenFlow/Open Virtual Switch的技術(shù)框架,做一個Web界面,通過簡單的Controller,以O(shè)VSDB方式配置OpenFlow的交換機(如創(chuàng)建Bridge,將端口加入Bridge),并向Controller控制的交換機下發(fā)OpenFlow Entries,更新交換機L2表和L3表,最終定義L2轉(zhuǎn)發(fā)的行為和L3路由的行為。這不過是用Web GUI替代原來的ssh/telnet,非但沒有簡化配置,甚至配置變得更為復(fù)雜。因此,只是為SDN而SDN,不過是新瓶裝老酒,沒有任何價值。其實,對于開發(fā)者而言,相對過去的分布式的控制平面,SDN帶來的最大的好處當(dāng)然是可編程,而可編程的基礎(chǔ)和前提是可以通過Controller提供的應(yīng)用開發(fā)平臺的API獲取全局的網(wǎng)絡(luò)視圖(View),包括網(wǎng)絡(luò)拓撲(Network Topology)、網(wǎng)絡(luò)設(shè)備和連接的狀態(tài)以及流量統(tǒng)計數(shù)據(jù)(Counters)。有了這些,就能以直接的方式比較快的開發(fā)出更具智能的網(wǎng)絡(luò)應(yīng)用,如流量工程(Traffic Engineering)、負載均衡(Workload Balance)、防火墻等。另外,還有一些更為具體的應(yīng)用,比如兩個運營商的網(wǎng)絡(luò)之間只允許交換特定服務(wù)(如Web Application)的數(shù)據(jù)流(Application-Specific peering),將特定的數(shù)據(jù)流重定向到事先配置好的目的網(wǎng)絡(luò)(Redirection Through Middleboxes)??梢哉f,網(wǎng)絡(luò)視圖之于SDN,就如同地圖和交通數(shù)據(jù)之于汽車導(dǎo)航系統(tǒng)一樣必不可少。汽車導(dǎo)航系統(tǒng)當(dāng)然要根據(jù)地圖和交通狀況來為用戶算出合理的路線(Route),若把每輛使用導(dǎo)航系統(tǒng)的車看作是網(wǎng)絡(luò)中的數(shù)據(jù)包(Frame/Package),那么,這看起來不就是流量工程的概念嗎?

利用開源(Open Source)的力量。與SDN相關(guān)的開源的項目著實不少,Controller的開源項目就有NOX/POX、NodeFlow、Floodlight、OpenDaylight、Ryu、ovs-controller等。L3路由系統(tǒng)有Xorp、Quaqqa和EXaBGP等。另外,還有一些特殊的應(yīng)用,如Google的RouteFlow提供了基于OpenFlow的虛擬IP路由服務(wù)(virtualized IP routing services),很有想象力(+微信關(guān)注網(wǎng)絡(luò)世界),而Flowvisor可作為在OpenFlow交換機和Controller之間的代理服務(wù),實現(xiàn)虛擬化的網(wǎng)絡(luò)切片(Slice)。Frenetic竟給出了一種網(wǎng)絡(luò)編程語言,支持以模塊化的方式開發(fā)網(wǎng)絡(luò)應(yīng)用,很值得關(guān)注。文獻[2]使用Frenetic和BGPExa實現(xiàn)了SDX(Software Defined Internet Exchange)的實驗系統(tǒng)。而Google的B4也用到了Quagga和Onix。有些SDN開源項目對于上文提的SDN的技術(shù)挑戰(zhàn)給出了解決方案,因此,利用開源,可以使資源非常有限的起步公司更加專注在開發(fā)網(wǎng)絡(luò)應(yīng)用來滿足用戶需求上。Brocade基于OpenDaylight的Helium版本,發(fā)布了自己商業(yè)化的Vyatta Controller,這是一個很值得SDN的起步公司關(guān)注的事件。開源的精神是開放、共享和交流,起步公司在利用開源資源的同時,別忘了為開源做出應(yīng)有的貢獻,這也是在業(yè)界增加影響力的有效途徑。

以做互聯(lián)網(wǎng)產(chǎn)品的精神做SDN。在互聯(lián)網(wǎng)公司有過工作經(jīng)驗的人都了解,互聯(lián)網(wǎng)產(chǎn)品尤其是移動設(shè)備上面的應(yīng)用的研發(fā)與其他軟件的研發(fā)有些許不同。最突出的一點就是這些應(yīng)用和服務(wù)的設(shè)計和開發(fā)完全以用戶體驗(UX, User eXperience)為中心,這一趨勢可能是受到Apple或者說是Steve Jobs的影響。一言以蔽之,好的用戶體驗就是做出來的產(chǎn)品卓爾不群(Good and Different),如圖中的那把SENZ的傘就是一個較好的例子,它與眾不同,且美觀實用,是我比較喜歡的設(shè)計。而在設(shè)計研發(fā)互聯(lián)網(wǎng)產(chǎn)品的過程中,互聯(lián)網(wǎng)公司對用戶體驗的追求具體表現(xiàn)在:第一,制造需求。不期望用戶完全了解需求,而認為用戶并不真正知道想要的需求是什么,或者說對需求是模糊的,因此,需求要靠開發(fā)團隊發(fā)掘出來,在制造需求時,有的公司更多的是靠經(jīng)驗和直覺,如Apple;有的公司更多的是靠大規(guī)模的數(shù)據(jù)分析,如Google。第二,消除痛點(Pain Point)。不斷地發(fā)現(xiàn)用戶在使用產(chǎn)品過程中的所謂痛點,這些痛點,是產(chǎn)品持續(xù)改進的動力和目標。第三,崇尚簡約。讓用戶在完成一項功能時,所做的操作盡可能的簡單,且容易明白。Apple的產(chǎn)品常常追求極致的簡單,使得從孩童到老嫗都可以輕而易舉使用iPhone/iPad執(zhí)行想要的功能。支撐產(chǎn)品使用簡單的背后是開發(fā)團隊的才華、創(chuàng)造能力(Creativity)、以及必不可少的艱辛付出。第三,注重細節(jié)。對產(chǎn)品的任何部分,哪怕看起來多么的微不足道,都要精雕細琢,精益求精,做得好到不能再好。對照以上四點,讓我們檢查一下當(dāng)前的網(wǎng)絡(luò)系統(tǒng):第一,有的網(wǎng)絡(luò)需求是很明確的,無須發(fā)掘,如在IaaS的云計算數(shù)據(jù)中心中,虛擬機(Virtual Machine)的動態(tài)遷移的需求,VLAN的4096個編碼空間已不足用的問題。另外,可以將網(wǎng)絡(luò)用戶按照不同的需求梳理分類,分別發(fā)掘他們最關(guān)切的需求,做到自己的產(chǎn)品或解決方案中。讓用戶看到自己的產(chǎn)品和解決方案之后,會眼前一亮,立馬感覺這就是TA想要的。第二,當(dāng)前網(wǎng)絡(luò)的痛點可謂數(shù)不勝數(shù),已經(jīng)到了虱子多了不癢的程度,需要改進的地方太多,這正是SDN存在的理由。第三,當(dāng)前網(wǎng)絡(luò)的管理配置繁冗復(fù)雜,讓管理員疲于奔命,苦不堪言。第四,SDN往往是一個很大的系統(tǒng),若對系統(tǒng)的每個部分都做到完美無缺,真不是一件容易的事兒。比如說,交換機的失敗多數(shù)情況是由于軟件的錯誤引起的,因此,如果對于交換機操作系統(tǒng)的每個細節(jié),不放過任何的內(nèi)存泄漏和core dump的因素,那么系統(tǒng)的可靠性和穩(wěn)定性將會大幅提升。我想,對于以上四點,當(dāng)別人做不到或做不好的時候,你做到了,而且做的很好。那你就是江湖中故老相傳的獨孤求敗,求一敗而不可得,想不成功,不也是很難嗎?!

鏈接已復(fù)制,快去分享吧

企業(yè)網(wǎng)版權(quán)所有?2010-2024 京ICP備09108050號-6京公網(wǎng)安備 11010502049343號