作為世界上最強大的互聯(lián)網(wǎng)服務提供商之一，Google一直在推動著業(yè)界技術的發(fā)展，最知名的當屬其在分布式計算領域的領先成果和領導地位。而隨著Google的網(wǎng)絡技術領域的領導人Amin Vahdat在2015年6月召開的Open Networking Summit (ONS，開放網(wǎng)絡峰會)上首次發(fā)布了Google網(wǎng)絡技術的演進路徑并重點對其數(shù)據(jù)中心網(wǎng)絡技術進行闡述，Google在網(wǎng)絡領域的技術創(chuàng)新才被揭開了神秘的面紗，并迅速在業(yè)界引起極大的反響。


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

Google網(wǎng)絡技術演進路線

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


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


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

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

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

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


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

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

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

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


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

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

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

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

遵循上述策略，Google數(shù)據(jù)中心基于Clos網(wǎng)絡拓撲和商用晶片自主研發(fā)了具備強大網(wǎng)絡吞吐能力的轉發(fā)層設備集群，同時基于統(tǒng)一控制的理念自主研發(fā)了網(wǎng)絡控制層技術及配套的控制協(xié)議。

Google數(shù)據(jù)中心網(wǎng)絡轉發(fā)層技術

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


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

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

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

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

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

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

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

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

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


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

小結

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

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