《Uber是如何在生產環境中部署IPv6的？》要點：
本文介紹了Uber是如何在生產環境中部署IPv6的？，希望對您有用。如果有疑問，可以聯系我們。

作者:JEAN HE

編輯:大愚若智

Uber的成長速度遠遠超出了IPv4的承載能力,為了更好地支持業務擴展,Uber的基礎架構需要跟上用戶增速的步伐,必須使用IPv6.2016年,Uber開始推行IPv6數據中心架構,通過對現有基礎架構進行調整來促進業務的擴展.本文介紹了為適應Uber工程任務的成長,設計這一全新網絡過程中所獲得的最佳實踐,以及通過對基礎架構進行更新以支持IPv6過程中,Uber工程部門學到的經驗.

2014年初,Uber宣布落地100個城市.而在2016年初,Uber已經遍及全球超過400個城市,不僅提供駕乘,還提供了其他類型的交通運輸服務.與此同時,2015年新年前夜,我們達成了10億次行程的里程碑,并很快于2016年6月達成20億次行程.隨著我們將服務擴展至更多城市,這個數字還會繼續飛速攀升,我們也會繼續以可靠的交通服務服務于全球用戶.然而為了繼續提高Uber服務的覆蓋面,我們需要確保工作能夠順利應對IP協議方面遇到的一些挑戰.

Uber目前的基礎架構建于Internet協議版本4(IPv4)地址標準的基礎之上,包含多個數據中心,使用了少量網絡入網點(POP)和云服務.然而Uber的成長速度遠遠超出了IPv4的承載能力,為了更好地支持業務擴展,我們的基礎架構需要跟上用戶增速的步伐,必須使用下一代IP：Internet協議版本6(IPv6).

2016年,Uber開始推行IPv6數據中心架構,通過對現有基礎架構進行調整來促進業務的擴展.本文中,我們將介紹為適應Uber工程任務的成長,我們在設計這一全新網絡的過程中獲得的最佳實踐,以及通過對基礎架構進行更新以支持IPv6過程中,我們學到的經驗.

從IPv4到IPv6的奮力一躍

根據互聯網協會(ISOC)的介紹,IPv4總共43億個地址已于2011年2月全部耗盡.IPv4地址總數超過40億個,遠遠比不上全球移動設備總數.再考慮到物聯網(IoT)設備的飛速增長等因素,我們很快將發現自己開始面臨IP地址“饑荒”.

2011年,全球五大區域性互聯網管理機構(RIR)中的三家,包括亞太網絡信息中心(APNIC)、Réseaux IP Européens(RIPE),以及拉丁美洲和加勒比網絡信息中心(LACNIC)已徹底分配完了自己所有可用IPv4地址.2015年9月24日,美國互聯網號碼注冊機構(ARIN)也宣布自己的全部IPv4地址已耗盡.

早在1996年就已制定的Internet協議版本6(IPv6)是目前最新版的Internet Protocol(IP)地址標準,提供了大量可解決IPv4所面臨諸多弊端的功能,如更大的地址空間、一種多播基礎規范,以及無狀態地址自動配置(SLAAC).IPv6可容納超過340澗(Undecillion,10的36次方)個地址,這一數量已經遠遠超過目前全球所有用戶,當然也包括Uber自己對IP地址的需求.

APNIC制作的一個地圖(見上圖)顯示了全球不同國家目前的IPv6部署,很多國家目前的部署依然為零,而比利時已經超過了56%.互聯網協會在2011年進行的全球IPv6使用情況調查發現,自從2012年起,全球主要ISP運營商,尤其是美國的運營商在部署IPv6方面開始加快步伐.北美運營商目前的IPv6部署范圍從27.93%(Cox Communications)到84.36%(Verizon Wireless)各異.

調查還發現,整個互聯網上的IPv6流量正在穩步增加,然而依然遠低于IPv4流量.更重要的是,2017年4月,Google稱其用戶中使用IPv6的比例已達16%,依然使用IPv4的比例為84%；類似的,Web信息公司Alexa稱截止2017年3月8日,全球排名前1000位的網站中,只有不到20%的用戶在使用IPv6.

專為2014年美國計算機協會大會撰寫的Measuring IPv6 Adoption一文預測說：“到2019年,已分配的IPv6前綴數量將約為IPv4的.25-.50,而屆時IPv6與IPv4流量的比例約介于.03到5.0之間.換句話說,IPv6流量依然只在總流量中占據很小的零頭.”這些結論建議,按照目前的增速,全球對IPv6的接受速度過慢,已無法適應整個世界對網絡連接快速增長的需求.

Uber的IPv6部署

目前Uber運維著數萬臺服務器,整個網絡共承載了超過8百萬個IPv4地址.

2014年之前,Uber的數據中心托管在第三方.為滿足我們對容量的需求并為用戶提供更可靠的服務,我們在2014年建立了自己的首個北美數據中心.2015年,Uber對北美數據中心進行了擴展,在美國東西海岸建立了更多數據中心；2016年,Uber建立了幾個網絡POP點,并將其擴展至云中.隨著2017年來用戶數量持續激增,IPv6部署已開始成為我們后續擴展過程中的關鍵一環.

對我們來說,為了維持大規模架構的可靠性,在整個網絡中部署IPv6主要有三個原因：

• 更“慷慨”的IP分配：過去幾年來,我們的網絡規模增速飛快,數據中心內服務器機架數已達數千個.我們會從自己的Request for Comment (RFC) 1918 IP空間內為每個機架分配一個/24 IP子網,而目前機架中僅剩48臺服務器.
• 資源局限：增長到目前這樣的規模后,我們現有的10.0.0.0/8 IPv4子網中已經有超過50%的地址被用于內部用途.如果不過渡至IPv6,我們的RFC1918(互聯網工程任務組(IETF)有關私有IP地址分配方式的備忘錄)地址空間很快就會耗盡.
• IP地址重疊：按照傳統,Uber的網絡中為自己的資源定義了自己的IP地址.當Uber開始與其他公司合并時,不同機構的兩個內部網絡中會出現一些重疊的IPv4地址.

經過全面研究、測量以及其他分析后,我們意識到為了支持IPv6部署,我們的基礎架構還有三大領域需要進行更新：

• 網絡架構
• 軟件支持
• 供應商支持

首先,我們將介紹Uber數據中心網絡中上述三方面內容的構成,隨后將介紹如何面向IPv6的部署做準備.

網絡架構

Uber的網絡架構包含三個主要部分,接下來分別介紹下.

硬件

Uber使用了統一且一致的硬件,這樣可以更容易地實現模塊化、可伸縮的數據中心設計.每個設備通常會使用相同型號的硬件,因此可以很容易地根據需求進行伸縮.我們的網絡設備可支持通過100G/50G/25G以太網下行鏈路連接至服務器.

自動化

以Uber的系統規模來說,網絡的構建、管理和運維必須使用自動化工具.我們的網絡數據中心可使用零接觸供應工具自動構建,日常網絡管理工作中可通過內部開發的自動化工具管理網絡配置和IP地址,此外如果哪里出現問題,智能監視工具可以向我們發出通知.

網絡設計

我們數據中心的設計符合IETF RFC 7938所定義的Clos設計,“在大規模數據中心內部使用BGP進行路由”,該設計方式決定了我們需要使用邊界網關協議(BGP)作為動態路由協議.按照網絡架構,我們使用了對分(Bisectional)帶寬,可快速收斂(Convergence)并且故障域很少.此外我們還通過構建網絡過程中使用的功能集實現了不同供應商產品的互操作性,如下所示：

在Clos設計的基礎上,我們將整個數據中心劃分為模塊化的Pod和集群.每個Pod包含相同數量的服務器機架,每個集群包含多個服務器Pod.因此整個網絡可拆分為多個小規模但完全一致的單元,所有Pod之間統一使用高性能網絡進行互聯.Uber的數據中心包含多個集群,所有集群連接至我們的邊緣骨干網絡,進而連接至互聯網.

為了向Uber的網絡提供足夠的帶寬,包括向Hadoop等主要的內部“東西”流量提供支持,我們的集群架構使用了一種1:1無閉鎖(Unblocking)網絡模型,例如下圖展示了我們設施內部的IPv4網絡架構：

為了在維持冗余的同時盡可能讓每個網絡層實現最大化的帶寬共享,隨后我們還在網絡設計中引入了一種Fabric plane的概念.另外,1:1的無閉鎖超額開通(Oversubscription)率意味著任何服務器主機均可在維持自己端到端上行帶寬的同時與這個IP設施網絡內的其他任何主機通信.

為了在這種網絡架構中部署IPv6,我們為每個服務器機架和集群指定了要分配的IPv6地址,其中服務器機架會被分配一個/64 IPv6子網,集群會分配并匯聚至子網/n,其中n<64.這些子網會通過一個/32全局唯一IPv6地址塊獲得地址,這個地址塊是由區域性互聯網管理機構(RIR)分配給我們的,僅限內部網絡使用.IPv6的分配和管理工作使用了上文提到的自動化過程.

由于我們的數據中心網絡是模塊化的,使用了模板化的配置,并且我們的Clos設計自上至下只使用了一種協議：外部邊界網關協議(eBGP),相比在從IPv4遷移至IPv6過程中需要重新配置協議的網絡設計,我們可以快速簡單地為所有機架分配原生IPv6地址.我們數據中心集群的每個組件,例如機架子網、Pod子網、環回、帶外(Out-of-band)子網,以及點對點子網均使用了相同的IPv6分配過程.這些自動化的IPv6地址生成工具使用了與我們的IPv4地址分配架構類似的邏輯.

最后,我們的骨干網絡所用的諸如BGP和IS-IS等路由協議可以很輕松地通過更新支持IPv6,在運維方面不會產生太多額外的工作量.

軟件支持

為了順利部署IPv6,還需要對整個網絡對軟件的支持情況進行更新,尤其是可提升IPv6流量的軟件更是需要重點處理.為軟件實現IPv6的支持需要不同團隊通力協作,涉及到Uber的多個團隊,包括安全工程團隊和站點可靠性工程團隊.

一些工程師所接受的培訓只介紹過如何編寫僅支持IPv4的代碼,因此他們針對IPv6兼容性開發的應用程序和工具也能支持IPv4.IPv4和IPv6地址無論地址長度、前綴,以及表現形式等方面都有很大差異,例如在從純IPv4代碼遷移至可支持IPv6代碼的過程中,我們遇到了一些常見的應用程序問題,包括：

• 代碼將前綴長度設置為常見的IPv4前綴,例如/24,無法適應IPv6前綴的長度.
• 會將“a.b.c.d”拆分為”(“a”、“b”、“c”、“d”)元組(Tuple)的代碼將無法識別IPv6地址,因為拆分是以分號“:”而非句號“.”為依據的.
• 需要將“主機：端口號”,例如“a.b.c.d:8080”拆分為“a.b.c.d”,“80”的代碼遇到“[2002:a:b:c::ff]:8080”之后會出錯.同理,需要將“a.b.c.d”,“80”組合為“a.b.c.d:8080”的代碼遇到“2002:a:b:c::ff:8080”會創建出無效的IPv6地址.
• 使用regex匹配IPv4地址的代碼在收到IPv6地址后會給出無效的結果.
• 通過硬編碼方式指定尺寸的列將IPv4地址存儲為“varchar(16)”的數據庫,會由于“a.b.c.d\0”問題而無法存儲IPv6地址.

Uber的基礎架構使用haproxy在不同地區進行路由.我們廣泛使用諸如haproxy.cfg yaml等配置(config)文件將不同IPv4地址與對應的主機名存儲在一起.所有服務的配置文件也需要仔細檢查,并根據不同用途進行更新,以便在為所有主機啟用IPv6后支持IPv6地址.

我們并未使用硬編碼的方式指定IPv4地址,而是在代碼中使用主機名,隨后通過DNS解決過渡期遇到的問題.目前我們正在對開發者進行培訓,告訴他們如何使用諸如getaddrinfo(3)等IPv6相關支持工具促進整個過渡進程.

供應商支持

大型網絡設備和服務器硬件供應商多年來一直在積極地為IPv6提供著支持,并且已經順利實現了大量IPv6特性.然而考慮到生產環境中使用IPv6的歷史并不長,并且大家普遍缺乏相關運維經驗,隨著越來越多的組織開始在生產環境中部署IPv6,大家陸續發現了很多bug.IPv6的質量保證(QA)需要努力與IPv4看齊.

隨著越來越多的組織將服務部署在云端,Amazon AWS、Google GCP,以及Microsoft Azure等云供應商也加快了對IPv6的支持步伐.

Uber的IPv6部署：現在和未來

Uber目前正在以設計文檔,包括IPv6尋址機制和特性RFC為指導,對IPv6部署進行實驗室測試.在全面將IPv6部署到生產環境之前,為了發現任何可能存在的問題,還需要在準備環境中進行深入的負載測試.

我們預計可以通過全面部署IPv6立刻獲得下列收益(包括但不限于)：

• 前端：前端將可以直接為原生IPv6流量提供服務.
• 組織合并：面對相互重疊的IPv4地址,IPv6為我們提供了更具伸縮性的解決方案.
• 車輛上下客：目前,Uber為自有車輛提供的車載設備底座會被解析至一個/24 IPv4子網.當前的這種設計是為了預留IPv4資源同時確保不同工程項目一致的配置.然而IPv6可以通過設備底座為車輛上下客網絡架構提供一種更具伸縮性的解決方案.然而需要注意,僅在用戶的iOS或Android軟件能夠支持的情況下才可以在上下客網絡中使用IPv6.行動呼吁：迎接IPv6

企業內部的IPv6部署需要大量規劃,絕不是一種“要么全有,要么全無”的實現.為了對網絡連接以及技術創新的飛速增長提供更廣泛的支持,我們鼓勵開發者在應用程序層面編寫能同時支持IPv4和IPv6的代碼.同時我們也希望您能與我們一起在自己的技術圈里推動IPv6的更廣泛部署.

隨著多方的不斷努力,早期“嘗鮮者”所組成的社區所產生的統計結果和指標也將幫助我們進一步優化IPv6的相關設計和性能,等到IPv4徹底耗盡那天再著手進行就來不及了.通過攜手努力,我們將能共同打造一個更好的互聯網世界.

原文地址：https://eng.uber.com/ipv6/

文章來自微信公眾號 ：聊聊架構

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4195.html