Google數(shù)據(jù)中心網(wǎng)絡(luò)技術(shù)漫談

責(zé)任編輯:editor005

2015-07-17 14:49:19

摘自:sdnlab

在2005年以前,Google還是需要依賴設(shè)備廠商提供的產(chǎn)品建設(shè)其數(shù)據(jù)中心網(wǎng)絡(luò)。圍繞“商用器件+Linux+自有協(xié)議”的網(wǎng)絡(luò)軟硬件設(shè)備的自主研發(fā)理念也勢必會對整個網(wǎng)絡(luò)產(chǎn)業(yè)的發(fā)展產(chǎn)生巨大影響。

Google數(shù)據(jù)中心網(wǎng)絡(luò)技術(shù)漫談

本文以Amin的演講內(nèi)容為主要素材來源,并添加了作者對相關(guān)內(nèi)容的理解和說明,希望能夠幫助讀者對Amin講授的Google網(wǎng)絡(luò)技術(shù)有更深入的認(rèn)識。

2.Google網(wǎng)絡(luò)技術(shù)演進(jìn)路線

Google的網(wǎng)絡(luò)技術(shù)進(jìn)展,特別是其在SDN(Software Defined Networking,軟件定義網(wǎng)絡(luò))領(lǐng)域的實踐,一直以來都是業(yè)界關(guān)注的重點,最典型的就是其于2013年解密的B4網(wǎng)絡(luò)被視作迄今最成功的SDN案例。而Amin在ONS 2015峰會上描繪的Google網(wǎng)絡(luò)技術(shù)的演進(jìn)路徑(如圖1所示),無疑為業(yè)界提供了探知Google網(wǎng)絡(luò)技術(shù)發(fā)展脈絡(luò)的重要線索。

圖1 Google網(wǎng)絡(luò)技術(shù)演進(jìn)路線

圖1 Google網(wǎng)絡(luò)技術(shù)演進(jìn)路線

如圖1所示,在過去的近十年間,Google建立的網(wǎng)絡(luò)技術(shù)體系不但全面覆蓋了眾多的網(wǎng)絡(luò)業(yè)務(wù)場景,并且還在隨著Google業(yè)務(wù)的開展持續(xù)優(yōu)化。與圖1所示的各項網(wǎng)絡(luò)技術(shù)相對應(yīng)的網(wǎng)絡(luò)業(yè)務(wù)場景如表1所示。

表1 Google網(wǎng)絡(luò)創(chuàng)新技術(shù)的運用場景

Google數(shù)據(jù)中心網(wǎng)絡(luò)技術(shù)漫談 表1

如表1所示,Google的網(wǎng)絡(luò)技術(shù)體系在當(dāng)前已經(jīng)非常完備。其中,既有其用于廣域網(wǎng)互連的B4、Andromeda,又有其用于園區(qū)網(wǎng)互連的Freedome及其用于數(shù)據(jù)中心內(nèi)部互連的Watchtower、Jupiter,還有其在網(wǎng)絡(luò)業(yè)務(wù)層面的創(chuàng)新研發(fā),例如QUIC、gRPC。在上述的各項技術(shù)中,gRPC技術(shù)已經(jīng)通過開源的方式全面公開,Onix、B4也有相關(guān)的學(xué)術(shù)論文揭示其核心原理,Andromeda則由Amin在去年的ONS峰會上做過介紹,其余的技術(shù),諸如Freedome等,則仍然保持著神秘。在本次ONS峰會上,Amin為業(yè)界展示了Google數(shù)據(jù)中心網(wǎng)絡(luò)的核心技術(shù),并將它視作支撐Google云平臺的重要基礎(chǔ)。

3.Google數(shù)據(jù)中心網(wǎng)絡(luò)技術(shù)概述

眾所周知,計算、存儲、網(wǎng)絡(luò)是構(gòu)成數(shù)據(jù)中心的三大要素。而在此前的技術(shù)進(jìn)展中,計算和存儲已經(jīng)遭遇瓶頸,主要體現(xiàn)在:計算方面,隨著半導(dǎo)體技術(shù)面臨的物理障礙不可逾越,摩爾定律失效的時限日益臨近,因此單個計算節(jié)點的性能提升有限,從而必須依賴于分布式計算技術(shù),而分布式集群中節(jié)點間的網(wǎng)絡(luò)將成為影響集群工作效率的關(guān)鍵;存儲方面,支持管理機制和存儲空間分離的分布式存儲技術(shù)已經(jīng)解決了存儲容量的問題,但是存儲I/O仍是瓶頸(高性能的Flash當(dāng)前仍舊停留在緩存的范疇),因此存儲性能的改進(jìn)也非常依賴于網(wǎng)絡(luò)能力的增強。因此,網(wǎng)絡(luò)已經(jīng)成為了提升大規(guī)模數(shù)據(jù)中心運行性能的關(guān)鍵點,是維持?jǐn)?shù)據(jù)中心資源效率平衡的關(guān)鍵。

與其它的網(wǎng)絡(luò)環(huán)境相比較,數(shù)據(jù)中心網(wǎng)絡(luò)擁有的特征如圖2所示。在這些特征中,最關(guān)鍵的一點在于數(shù)據(jù)中心的建設(shè)和管理都可以由同一個組織完成并具有單獨的管理域,使得數(shù)據(jù)中心的網(wǎng)絡(luò)邊界相對清晰,并且其對外部網(wǎng)絡(luò)的影響可控,這也是業(yè)界普遍將數(shù)據(jù)中心作為SDN引入首選場景的重要原因之一。另外,數(shù)據(jù)中心網(wǎng)絡(luò)的帶寬普遍有保障,而對延遲的要求更高,特別是Google數(shù)據(jù)中心中大量運行著分布式計算平臺,這種場景下對tail latency的要求更加嚴(yán)格,即計算過程中由響應(yīng)最慢節(jié)點返回結(jié)果時產(chǎn)生的延遲,這塊“短木板”將是影響整個分布式系統(tǒng)計算性能的關(guān)鍵。

圖2 數(shù)據(jù)中心網(wǎng)絡(luò)特征

圖2 數(shù)據(jù)中心網(wǎng)絡(luò)特征

基于上述特征,數(shù)據(jù)中心網(wǎng)絡(luò)產(chǎn)生了其獨特的需求,特別是對于擁有海量服務(wù)器的大規(guī)模數(shù)據(jù)中心而言,其對網(wǎng)絡(luò)的帶寬、延遲、可用性等三方面的指標(biāo)要求更是嚴(yán)格。以如圖3所示的典型的數(shù)據(jù)中心資源環(huán)境為例,相應(yīng)的性能指標(biāo)需求的分析如下:

網(wǎng)絡(luò)帶寬:遵循Amdahl定律(并行計算環(huán)境中,每1MHz的計算將導(dǎo)致1Mbps的I/O需求),一臺擁有64顆2.5GHz CPU的服務(wù)器的網(wǎng)絡(luò)I/O需求將達(dá)到100Gbps的量級。如果數(shù)據(jù)中心中有50000臺這樣的服務(wù)器同時通信,那么相應(yīng)網(wǎng)絡(luò)帶寬總需求將達(dá)到5Pbps。即使考慮到有10倍的超配比率,那么也至少需要500Tbps的網(wǎng)絡(luò)帶寬。同時,如前所述,不同網(wǎng)絡(luò)分區(qū)之間的帶寬(即bisection bandwidth)相對一致的特點使得整個數(shù)據(jù)中心網(wǎng)絡(luò)都需要達(dá)到極高的網(wǎng)絡(luò)帶寬。

網(wǎng)絡(luò)延遲:盡管Flash已經(jīng)成當(dāng)前高性能存儲領(lǐng)域的主流技術(shù),但是在Google看來,F(xiàn)lash在IOPS和訪問延遲等方面還存在不足,而另一類高速存儲技術(shù)NVM(Non-Volatile Memory),則能夠達(dá)到十倍于Flash的吞吐率以及不及其十分之一的訪問延遲,從而更好地提升存儲訪問性能。因此,一旦數(shù)據(jù)中心存儲系統(tǒng)決定引入NVM,那么就意味著相應(yīng)的網(wǎng)絡(luò)延遲必須也要在10微秒的量級,否則的話網(wǎng)絡(luò)將成為系統(tǒng)的瓶頸,造成計算、存儲資源的空轉(zhuǎn),從而導(dǎo)致巨大的浪費。

網(wǎng)絡(luò)可用性:在數(shù)據(jù)中心場景中,存在著大量的軟硬件設(shè)備的運維工作。其中,新服務(wù)器的上架和舊服務(wù)器的下架,都會引起網(wǎng)絡(luò)規(guī)模和組網(wǎng)拓?fù)涞淖儎?同時,數(shù)據(jù)中心網(wǎng)絡(luò)從1G 到10G 到40G再到 100G乃至今后可能的更高速網(wǎng)絡(luò)技術(shù)的演進(jìn),也會導(dǎo)致相應(yīng)網(wǎng)絡(luò)環(huán)境的調(diào)整。在這種情形下,如何確保數(shù)據(jù)中心服務(wù)的持續(xù)不間斷,是數(shù)據(jù)中心網(wǎng)絡(luò)可用性提升面臨的一個難題。

圖3 數(shù)據(jù)中心資源環(huán)境及網(wǎng)絡(luò)性能需求分析

圖3 數(shù)據(jù)中心資源環(huán)境及網(wǎng)絡(luò)性能需求分析

上述的高性能網(wǎng)絡(luò)指標(biāo)對于維持Google數(shù)據(jù)中心網(wǎng)絡(luò)的運行順暢至關(guān)重要,而傳統(tǒng)的“以設(shè)備盒子為中心(box-centric)”的網(wǎng)絡(luò)技術(shù)體系無論是在性能方面還是在管理復(fù)雜度方面都已經(jīng)難以滿足實際需求。鑒于廠商產(chǎn)品不能跟上Google數(shù)據(jù)中心網(wǎng)絡(luò)發(fā)展的步伐,Google在該領(lǐng)域進(jìn)行了自主的研發(fā)和創(chuàng)新??傮w而言,Google數(shù)據(jù)中心網(wǎng)絡(luò)的設(shè)計與實現(xiàn)引入了以下三條策略:

基于Clos網(wǎng)絡(luò)。Clos網(wǎng)絡(luò)來自傳統(tǒng)的電路交換領(lǐng)域,它于上世紀(jì)五十年代就被提出。其核心理念是無阻塞的多級交換技術(shù),其中每一級的每個單元與下一級的設(shè)備都是全相連,其最大的優(yōu)勢在于能夠提供海量的東西向流量傳輸支持。

使用商用晶片(Merchant Silicon)。商用晶片的優(yōu)勢之一是降低成本,避免了傳統(tǒng)網(wǎng)絡(luò)設(shè)備采用廠商定制ASIC帶來的的高昂成本;同時,Google在運用商用晶片時還有額外的要求,最典型是要其支持Google對網(wǎng)絡(luò)協(xié)議的自主創(chuàng)新。

建立統(tǒng)一控制。邏輯上集中的控制是SDN的核心理念,通過擁有全局網(wǎng)絡(luò)視圖的控制器統(tǒng)一控制網(wǎng)絡(luò)傳輸通路,使得全網(wǎng)數(shù)以千計的網(wǎng)絡(luò)轉(zhuǎn)發(fā)設(shè)備能夠像一臺能力強大的網(wǎng)絡(luò)設(shè)備一樣工作,提升資源利用率,降低管理復(fù)雜度。

遵循上述策略,Google數(shù)據(jù)中心基于Clos網(wǎng)絡(luò)拓?fù)浜蜕逃镁灾餮邪l(fā)了具備強大網(wǎng)絡(luò)吞吐能力的轉(zhuǎn)發(fā)層設(shè)備集群,同時基于統(tǒng)一控制的理念自主研發(fā)了網(wǎng)絡(luò)控制層技術(shù)及配套的控制協(xié)議。

4.Google數(shù)據(jù)中心網(wǎng)絡(luò)轉(zhuǎn)發(fā)層技術(shù)

眾所周知,Google數(shù)據(jù)中心每時每刻都在承擔(dān)著海量的來自互聯(lián)網(wǎng)的數(shù)據(jù)訪問。而在當(dāng)前,Google數(shù)據(jù)中心內(nèi)部的網(wǎng)絡(luò)流量已經(jīng)超出了其數(shù)據(jù)中心與外部互聯(lián)網(wǎng)之間的流量。為了應(yīng)對如此之大的數(shù)據(jù)流量壓力,Google數(shù)據(jù)中心網(wǎng)絡(luò)一直在持續(xù)提升其網(wǎng)絡(luò)轉(zhuǎn)發(fā)層的性能,相關(guān)的數(shù)據(jù)如表2所示。

表2 Google數(shù)據(jù)中心網(wǎng)絡(luò)演進(jìn)

表2 Google數(shù)據(jù)中心網(wǎng)絡(luò)演進(jìn)

如表2所示,在2005年以前,Google還是需要依賴設(shè)備廠商提供的產(chǎn)品建設(shè)其數(shù)據(jù)中心網(wǎng)絡(luò)。但是隨著廠商設(shè)備不能滿足Google數(shù)據(jù)中心高速發(fā)展的需求,Google在2005年開始自主研發(fā),迄今已經(jīng)演進(jìn)了五代。其中,第一代Firehose 1.0貌似只是停留在設(shè)計階段,并沒有實際的設(shè)備產(chǎn)出,而第二代Fierhose 1.1則是真正部署在了Google數(shù)據(jù)中心的網(wǎng)絡(luò)中。為了穩(wěn)妥起見,F(xiàn)irehose 1.1還是采用了與傳統(tǒng)的廠商設(shè)備網(wǎng)絡(luò)并肩運行的方式,直到2008年,第三代數(shù)據(jù)中心網(wǎng)絡(luò)技術(shù)Watchtower出現(xiàn)并全面替代了廠商設(shè)備,使得Google數(shù)據(jù)中心開始完全采用其自主研發(fā)的技術(shù)和設(shè)備。在第四代Saturn中,10G網(wǎng)絡(luò)已經(jīng)成為Google數(shù)據(jù)中心中各計算節(jié)點的標(biāo)配,這也證明了Google網(wǎng)絡(luò)技術(shù)的前瞻性。

Jupiter是Google最新一代的數(shù)據(jù)中心網(wǎng)絡(luò),它引入了SDN技術(shù)并且使用了OpenFlow,其支持的網(wǎng)絡(luò)帶寬已經(jīng)達(dá)到Pbps量級,滿足了前文所述的大規(guī)模數(shù)據(jù)中心對網(wǎng)絡(luò)帶寬的需求。如Amin所言,Pbps的網(wǎng)絡(luò)速度意味著網(wǎng)絡(luò)能夠在十分之一秒內(nèi)就完成美國國會圖書館藏書所有掃描內(nèi)容的數(shù)據(jù)傳輸,達(dá)到這一量級的Google數(shù)據(jù)中心網(wǎng)絡(luò)則可以同時支持100000臺計算節(jié)點以10Gbps的網(wǎng)絡(luò)速度通信,這個規(guī)模是非常驚人的。

從表2所示的數(shù)據(jù)中可以看出,與第一代相比,Google的第五代數(shù)據(jù)中心網(wǎng)絡(luò)帶寬已經(jīng)擴展了100余倍。而Amin在演講中則有提及,在從2008年7月到2014年11月的短短幾年間,Google數(shù)據(jù)中心內(nèi)部的服務(wù)器產(chǎn)生的匯聚層流量已經(jīng)增長近50倍。因此,不難看出,正是Google業(yè)務(wù)的蓬勃發(fā)展驅(qū)動了其數(shù)據(jù)中心網(wǎng)絡(luò)技術(shù)的持續(xù)演進(jìn)。

Jupiter的主要構(gòu)建模塊和最終的設(shè)備形態(tài)分別如圖4和圖5所示。雖然僅僅在圖中還不能完全看出相關(guān)的設(shè)計和實現(xiàn)細(xì)節(jié),同時其顯示的產(chǎn)品規(guī)格也與表2所示的相關(guān)信息不能完全關(guān)聯(lián),但是它已經(jīng)把Google在其數(shù)據(jù)中心網(wǎng)絡(luò)中引入的采用Clos拓?fù)?、商用晶片等核心設(shè)計理念展露無遺。同時,關(guān)于Jupiter的更多信息會在 “Jupiter Rising: A Decade of Clos Topologies and Centralized Control in Google’s Datacenter Network”(將在2015年8月舉辦的SIGCOMM上發(fā)表)一文中被詳盡闡述。

圖4 Jupiter設(shè)備構(gòu)建模塊示意

圖4 Jupiter設(shè)備構(gòu)建模塊示意

圖5 Jupiter設(shè)備最終形態(tài)展示

圖5 Jupiter設(shè)備最終形態(tài)展示

5.Google數(shù)據(jù)中心網(wǎng)絡(luò)控制層技術(shù)

作為網(wǎng)絡(luò)的“大腦”,控制層在Google數(shù)據(jù)中心網(wǎng)絡(luò)中承擔(dān)了非常重要的角色。雖然在本次ONS峰會上,Amin沒有對其做更為詳盡的解讀,但是從他的演講內(nèi)容中已經(jīng)初見端倪,可以看到Goolge在該領(lǐng)域的研發(fā)思路。

首先,Google數(shù)據(jù)中心網(wǎng)絡(luò)控制層借鑒了其在分布式計算領(lǐng)域的先進(jìn)理念。Google研發(fā)的分布式計算技術(shù),例如GFS、MapReduce、BigTable、Spanner等,其架構(gòu)中普遍在控制層采用了邏輯上集中化部署的管控節(jié)點,用于管理分布式部署的計算/存儲節(jié)點并控制相關(guān)任務(wù)的實現(xiàn)流程,而具體的處理工作則由相應(yīng)的計算/存儲節(jié)點并行完成。這種架構(gòu)的最大優(yōu)點在于管控節(jié)點的集中化管理有效降低了管理復(fù)雜度,同時帶外管控的方式又不影響分布式系統(tǒng)的性能。類似的理念在Google網(wǎng)絡(luò)技術(shù)中也已經(jīng)多有引入,例如B4、Andromeda。

其次,Google數(shù)據(jù)中心網(wǎng)絡(luò)控制平面協(xié)議采用了自主研發(fā)的思路。這主要是因為數(shù)據(jù)中心網(wǎng)絡(luò)性能的提升需要破除對多路徑轉(zhuǎn)發(fā)的限制,所以大量的傳統(tǒng)協(xié)議將不再適用。同時Google不希望在這方面過分依賴于廠商專有設(shè)備,又苦于沒有合適的開源項目支持,使得自主研發(fā)成為了最好的途徑。Google自主研發(fā)的數(shù)據(jù)中心網(wǎng)絡(luò)控制平面協(xié)議能夠支持大規(guī)模網(wǎng)絡(luò)的廣播協(xié)議擴展,以及具備對各臺網(wǎng)絡(luò)設(shè)備獨立配置的網(wǎng)管能力,從而滿足大規(guī)模數(shù)據(jù)中心網(wǎng)絡(luò)的集中化管理的需求。

以上述思路為指導(dǎo),Google在其數(shù)據(jù)中心網(wǎng)絡(luò)中研發(fā)和部署了FirePath協(xié)議,相應(yīng)的控制層架構(gòu)和工作方式如圖6所示。其中,邏輯上集中化的Master節(jié)點通過Firepath協(xié)議從分布式部署的Client節(jié)點上采集網(wǎng)絡(luò)中所有網(wǎng)絡(luò)設(shè)備的連接狀態(tài),并將其在Master節(jié)點集群中散布,最終把計算得到的網(wǎng)絡(luò)數(shù)據(jù)轉(zhuǎn)發(fā)表項統(tǒng)一下發(fā)給各臺設(shè)備。

圖6 Google Firepath Route Controller工作示意

圖6 Google Firepath Route Controller工作示意

據(jù)Amin介紹,F(xiàn)irePath協(xié)議主要是在早期的Google數(shù)據(jù)中心網(wǎng)絡(luò)(Firehose、Watchtower)中被使用,其中的技術(shù)細(xì)節(jié)也將在相關(guān)的學(xué)術(shù)論文上作披露。而在Jupiter網(wǎng)絡(luò)中,是否有新的網(wǎng)絡(luò)控制層技術(shù)被提出,目前尚不得而知,但是有理由相信其核心原理和架構(gòu)設(shè)計一定也是會遵從Google一貫的分布式系統(tǒng)理念。

6.小結(jié)

Amin在ONS 2015上透露的信息讓業(yè)界得以有機會感受到Google在網(wǎng)絡(luò)領(lǐng)域的強大創(chuàng)新。依托其在分布式計算領(lǐng)域的先進(jìn)優(yōu)勢,Google在數(shù)據(jù)中心網(wǎng)絡(luò)中強調(diào)網(wǎng)絡(luò)設(shè)備的同質(zhì)化,進(jìn)而通過組建分布式集群的方式改進(jìn)整個網(wǎng)絡(luò)的性能、擴展性、可用性,并以邏輯上的集中控制提升網(wǎng)絡(luò)的管控效率。就在業(yè)界還在紛紛攘攘討論SDN的概念含義的時候,Google已經(jīng)以實際行動開展了相關(guān)的實踐,從而再次成為網(wǎng)絡(luò)領(lǐng)域的領(lǐng)先者。

不夸張地說,Google的今天就是廣大互聯(lián)網(wǎng)服務(wù)提供商、基礎(chǔ)網(wǎng)絡(luò)運營商的明天和后天,因此其技術(shù)路徑和研發(fā)思路具有非常重要的參考價值。同時,圍繞“商用器件+Linux+自有協(xié)議”的網(wǎng)絡(luò)軟硬件設(shè)備的自主研發(fā)理念也勢必會對整個網(wǎng)絡(luò)產(chǎn)業(yè)的發(fā)展產(chǎn)生巨大影響。

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

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