1.前言
作爲世界上最強大的互聯網服務提供商之一，Google一直在推動着業界技術的發展，最知名的當屬其在分佈式計算領域的領先成果和領導地位。而隨着Google的網絡技術領域的領導人Amin Vahdat在2015年6月召開的Open Networking Summit （ONS，開放網絡峯會）上首次發佈了Google網絡技術的演進路徑並重點對其數據中心網絡技術進行闡述，Google在網絡領域的技術創新才被揭開了神祕的面紗，並迅速在業界引起極大的反響。
本文以Amin的演講內容爲主要素材來源，並添加了作者對相關內容的理解和說明，希望能夠幫助讀者對Amin講授的Google網絡技術有更深入的認識。
2.Google網絡技術演進路線
Google的網絡技術進展，特別是其在SDN（Software Defined Networking，軟件定義網絡）領域的實踐，一直以來都是業界關注的重點，最典型的就是其於2013年解密的B4網絡被視作迄今最成功的SDN案例。而Amin在ONS 2015峯會上描繪的Google網絡技術的演進路徑（如圖1所示），無疑爲業界提供了探知Google網絡技術發展脈絡的重要線索。
圖1 Google網絡技術演進路線
如圖1所示，在過去的近十年間，Google建立的網絡技術體系不但全面覆蓋了衆多的網絡業務場景，並且還在隨着Google業務的開展持續優化。與圖1所示的各項網絡技術相對應的網絡業務場景如表1所示。
表1 Google網絡創新技術的運用場景
如表1所示，Google的網絡技術體系在當前已經非常完備。其中，既有其用於廣域網互連的B4、Andromeda，又有其用於園區網互連的Freedome及其用於數據中心內部互連的Watchtower、Jupiter，還有其在網絡業務層面的創新研發，例如QUIC、gRPC。
在上述的各項技術中，gRPC技術已經通過開源的方式全面公開，Onix、B4也有相關的學術論文揭示其核心原理，Andromeda則由Amin在去年的ONS峯會上做過介紹，其餘的技術，諸如Freedome等，則仍然保持着神祕。在本次ONS峯會上，Amin爲業界展示了Google數據中心網絡的核心技術，並將它視作支撐Google雲平臺的重要基礎。
3.Google數據中心網絡技術概述
衆所周知，計算、存儲、網絡是構成數據中心的三大要素。而在此前的技術進展中，計算和存儲已經遭遇瓶頸，主要體現在：計算方面，隨着半導體技術面臨的物理障礙不可逾越，摩爾定律失效的時限日益臨近，因此單個計算節點的性能提升有限，從而必須依賴於分佈式計算技術，而分佈式集羣中節點間的網絡將成爲影響集羣工作效率的關鍵；存儲方面，支持管理機制和存儲空間分離的分佈式存儲技術已經解決了存儲容量的問題，但是存儲I/O仍是瓶頸（高性能的Flash當前仍舊停留在緩存的範疇），因此存儲性能的改進也非常依賴於網絡能力的增強。因此，網絡已經成爲了提升大規模數據中心運行性能的關鍵點，是維持數據中心資源效率平衡的關鍵。
與其它的網絡環境相比較，數據中心網絡擁有的特徵如圖2所示。在這些特徵中，最關鍵的一點在於數據中心的建設和管理都可以由同一個組織完成並具有單獨的管理域，使得數據中心的網絡邊界相對清晰，並且其對外部網絡的影響可控，這也是業界普遍將數據中心作爲SDN引入首選場景的重要原因之一。另外，數據中心網絡的帶寬普遍有保障，而對延遲的要求更高，特別是Google數據中心中大量運行着分佈式計算平臺，這種場景下對tail latency的要求更加嚴格，即計算過程中由響應最慢節點返回結果時產生的延遲，這塊“短木板”將是影響整個分佈式系統計算性能的關鍵。
圖2 數據中心網絡特徵
基於上述特徵，數據中心網絡產生了其獨特的需求，特別是對於擁有海量服務器的大規模數據中心而言，其對網絡的帶寬、延遲、可用性等三方面的指標要求更是嚴格。以如圖3所示的典型的數據中心資源環境爲例，相應的性能指標需求的分析如下：
- 網絡帶寬：遵循Amdahl定律（並行計算環境中，每1MHz的計算將導致1Mbps的I/O需求），一臺擁有64顆2.5GHz CPU的服務器的網絡I/O需求將達到100Gbps的量級。如果數據中心中有50000臺這樣的服務器同時通信，那麼相應網絡帶寬總需求將達到5Pbps。即使考慮到有10倍的超配比率，那麼也至少需要500Tbps的網絡帶寬。同時，如前所述，不同網絡分區之間的帶寬（即bisection bandwidth）相對一致的特點使得整個數據中心網絡都需要達到極高的網絡帶寬。
- 網絡延遲：儘管Flash已經成當前高性能存儲領域的主流技術，但是在Google看來，Flash在IOPS和訪問延遲等方面還存在不足，而另一類高速存儲技術NVM（Non-Volatile Memory），則能夠達到十倍於Flash的吞吐率以及不及其十分之一的訪問延遲，從而更好地提升存儲訪問性能。因此，一旦數據中心存儲系統決定引入NVM，那麼就意味着相應的網絡延遲必須也要在10微秒的量級，否則的話網絡將成爲系統的瓶頸，造成計算、存儲資源的空轉，從而導致巨大的浪費。
- 網絡可用性：在數據中心場景中，存在着大量的軟硬件設備的運維工作。其中，新服務器的上架和舊服務器的下架，都會引起網絡規模和組網拓撲的變動；同時，數據中心網絡從1G 到10G 到40G再到 100G乃至今後可能的更高速網絡技術的演進，也會導致相應網絡環境的調整。在這種情形下，如何確保數據中心服務的持續不間斷，是數據中心網絡可用性提升面臨的一個難題。
圖3 數據中心資源環境及網絡性能需求分析
上述的高性能網絡指標對於維持Google數據中心網絡的運行順暢至關重要，而傳統的“以設備盒子爲中心（box-centric）”的網絡技術體系無論是在性能方面還是在管理複雜度方面都已經難以滿足實際需求。鑑於廠商產品不能跟上Google數據中心網絡發展的步伐，Google在該領域進行了自主的研發和創新。總體而言，Google數據中心網絡的設計與實現引入了以下三條策略：
- 基於Clos網絡。Clos網絡來自傳統的電路交換領域，它於上世紀五十年代就被提出。其核心理念是無阻塞的多級交換技術，其中每一級的每個單元與下一級的設備都是全相連，其最大的優勢在於能夠提供海量的東西向流量傳輸支持。
- 使用商用晶片（Merchant Silicon）。商用晶片的優勢之一是降低成本，避免了傳統網絡設備採用廠商定製ASIC帶來的的高昂成本；同時，Google在運用商用晶片時還有額外的要求，最典型是要其支持Google對網絡協議的自主創新。
- 建立統一控制。邏輯上集中的控制是SDN的核心理念，通過擁有全局網絡視圖的控制器統一控制網絡傳輸通路，使得全網數以千計的網絡轉發設備能夠像一臺能力強大的網絡設備一樣工作，提升資源利用率，降低管理複雜度。
遵循上述策略，Google數據中心基於Clos網絡拓撲和商用晶片自主研發了具備強大網絡吞吐能力的轉發層設備集羣，同時基於統一控制的理念自主研發了網絡控制層技術及配套的控制協議。
4.Google數據中心網絡轉發層技術
衆所周知，Google數據中心每時每刻都在承擔着海量的來自互聯網的數據訪問。而在當前，Google數據中心內部的網絡流量已經超出了其數據中心與外部互聯網之間的流量。爲了應對如此之大的數據流量壓力，Google數據中心網絡一直在持續提升其網絡轉發層的性能，相關的數據如表2所示。
表2 Google數據中心網絡演進
如表2所示，在2005年以前，Google還是需要依賴設備廠商提供的產品建設其數據中心網絡。但是隨着廠商設備不能滿足Google數據中心高速發展的需求，Google在2005年開始自主研發，迄今已經演進了五代。其中，第一代Firehose 1.0貌似只是停留在設計階段，並沒有實際的設備產出，而第二代Fierhose 1.1則是真正部署在了Google數據中心的網絡中。爲了穩妥起見，Firehose 1.1還是採用了與傳統的廠商設備網絡並肩運行的方式，直到2008年，第三代數據中心網絡技術Watchtower出現並全面替代了廠商設備，使得Google數據中心開始完全採用其自主研發的技術和設備。在第四代Saturn中，10G網絡已經成爲Google數據中心中各計算節點的標配，這也證明了Google網絡技術的前瞻性。
Jupiter是Google最新一代的數據中心網絡，它引入了SDN技術並且使用了OpenFlow，其支持的網絡帶寬已經達到Pbps量級，滿足了前文所述的大規模數據中心對網絡帶寬的需求。如Amin所言，Pbps的網絡速度意味着網絡能夠在十分之一秒內就完成美國國會圖書館藏書所有掃描內容的數據傳輸，達到這一量級的Google數據中心網絡則可以同時支持100000臺計算節點以10Gbps的網絡速度通信，這個規模是非常驚人的。
從表2所示的數據中可以看出，與第一代相比，Google的第五代數據中心網絡帶寬已經擴展了100餘倍。而Amin在演講中則有提及，在從2008年7月到2014年11月的短短几年間，Google數據中心內部的服務器產生的匯聚層流量已經增長近50倍。因此，不難看出，正是Google業務的蓬勃發展驅動了其數據中心網絡技術的持續演進。
Jupiter的主要構建模塊和最終的設備形態分別如圖4和圖5所示。雖然僅僅在圖中還不能完全看出相關的設計和實現細節，同時其顯示的產品規格也與表2所示的相關信息不能完全關聯，但是它已經把Google在其數據中心網絡中引入的採用Clos拓撲、商用晶片等核心設計理念展露無遺。同時，關於Jupiter的更多信息會在 “Jupiter Rising: A Decade of Clos Topologies and Centralized Control in Google’s Datacenter Network”（將在2015年8月舉辦的SIGCOMM上發表）一文中被詳盡闡述。
圖4 Jupiter設備構建模塊示意
圖5 Jupiter設備最終形態展示
5.Google數據中心網絡控制層技術
作爲網絡的“大腦”，控制層在Google數據中心網絡中承擔了非常重要的角色。雖然在本次ONS峯會上，Amin沒有對其做更爲詳盡的解讀，但是從他的演講內容中已經初見端倪，可以看到Goolge在該領域的研發思路。
首先，Google數據中心網絡控制層借鑑了其在分佈式計算領域的先進理念。Google研發的分佈式計算技術，例如GFS、MapReduce、BigTable、Spanner等，其架構中普遍在控制層採用了邏輯上集中化部署的管控節點，用於管理分佈式部署的計算/存儲節點並控制相關任務的實現流程，而具體的處理工作則由相應的計算/存儲節點並行完成。這種架構的最大優點在於管控節點的集中化管理有效降低了管理複雜度，同時帶外管控的方式又不影響分佈式系統的性能。類似的理念在Google網絡技術中也已經多有引入，例如B4、Andromeda。
其次，Google數據中心網絡控制平面協議採用了自主研發的思路。這主要是因爲數據中心網絡性能的提升需要破除對多路徑轉發的限制，所以大量的傳統協議將不再適用。同時Google不希望在這方面過分依賴於廠商專有設備，又苦於沒有合適的開源項目支持，使得自主研發成爲了最好的途徑。Google自主研發的數據中心網絡控制平面協議能夠支持大規模網絡的廣播協議擴展，以及具備對各臺網絡設備獨立配置的網管能力，從而滿足大規模數據中心網絡的集中化管理的需求。
以上述思路爲指導，Google在其數據中心網絡中研發和部署了FirePath協議，相應的控制層架構和工作方式如圖6所示。其中，邏輯上集中化的Master節點通過Firepath協議從分佈式部署的Client節點上採集網絡中所有網絡設備的連接狀態，並將其在Master節點集羣中散佈，最終把計算得到的網絡數據轉發表項統一下發給各臺設備。
圖6 Google Firepath Route Controller工作示意
據Amin介紹，FirePath協議主要是在早期的Google數據中心網絡（Firehose、Watchtower）中被使用，其中的技術細節也將在相關的學術論文上作披露。而在Jupiter網絡中，是否有新的網絡控制層技術被提出，目前尚不得而知，但是有理由相信其核心原理和架構設計一定也是會遵從Google一貫的分佈式系統理念。
6.小結
Amin在ONS 2015上透露的信息讓業界得以有機會感受到Google在網絡領域的強大創新。依託其在分佈式計算領域的先進優勢，Google在數據中心網絡中強調網絡設備的同質化，進而通過組建分佈式集羣的方式改進整個網絡的性能、擴展性、可用性，並以邏輯上的集中控制提升網絡的管控效率。就在業界還在紛紛攘攘討論SDN的概念含義的時候，Google已經以實際行動開展了相關的實踐，從而再次成爲網絡領域的領先者。
不誇張地說，Google的今天就是廣大互聯網服務提供商、基礎網絡運營商的明天和後天，因此其技術路徑和研發思路具有非常重要的參考價值。同時，圍繞“商用器件+Linux+自有協議”的網絡軟硬件設備的自主研發理念也勢必會對整個網絡產業的發展產生巨大影響。