編者按：UCloud 最新發(fā)布了名為“Sixshot”的可用區(qū)特性，用UCloud VP陳曉建的話說，“可用區(qū)就好比云計(jì)算的太祖長(zhǎng)拳，看似平平淡淡，但要打得好著實(shí)不易。”太祖長(zhǎng)拳屬于南拳流派，共有四套拳路，講求一膽、二力、三功、四氣、五巧、六變、七奸、八狠。有鑒于此，解密「云計(jì)算的太祖長(zhǎng)拳」系列將在接下來的三篇內(nèi)容里，詳細(xì)介紹UCloud可用區(qū)項(xiàng)目的“一膽、二力、三功”。
本文是解密「云計(jì)算的太祖長(zhǎng)拳」系列的第一篇，將全面解析UCloud可用區(qū)特性技術(shù)內(nèi)幕，闡述基礎(chǔ)網(wǎng)絡(luò)的改造和外網(wǎng)新特性技術(shù)實(shí)現(xiàn)。在項(xiàng)目研發(fā)過程中，UCloud團(tuán)隊(duì)不因循守舊并力圖有所創(chuàng)新、敢于打破常規(guī)改變一些已知的不合理設(shè)計(jì)，在編者看來，改革和創(chuàng)新皆需要膽識(shí)，本文作為系列的首篇，選太祖長(zhǎng)拳之“一膽”開題。
從本文起，我們將會(huì)推出一個(gè)系列的分享文章，詳細(xì)介紹為UCloud可用區(qū)項(xiàng)目中所涉及的軟硬件技術(shù)實(shí)現(xiàn)，包括基礎(chǔ)網(wǎng)絡(luò)的改造、NFV虛擬網(wǎng)關(guān)的實(shí)踐、底層SDN控制面和數(shù)據(jù)轉(zhuǎn)發(fā)面的演進(jìn)以及建設(shè)在新老架構(gòu)間平滑遷移海量用戶數(shù)據(jù)的運(yùn)營(yíng)能力等各個(gè)方面，分享該項(xiàng)目中的一些心得和經(jīng)驗(yàn)。
本文是這個(gè)系列的首篇，我們將介紹UCloud為支持可用區(qū)特性對(duì)基礎(chǔ)網(wǎng)絡(luò)所做的改造以及新架構(gòu)下實(shí)現(xiàn)的外網(wǎng)特性。
本文大綱如下：
基礎(chǔ)網(wǎng)絡(luò)改造
可用區(qū)重點(diǎn)功能實(shí)現(xiàn)
EIP支持跨AZ漂移
ULB支持跨AZ后端RS
共享帶寬支持跨AZ的EIP
可用區(qū)核心模塊UVER技術(shù)實(shí)現(xiàn)
結(jié)語
基礎(chǔ)網(wǎng)絡(luò)改造：環(huán)網(wǎng)和POP點(diǎn)
從2014年起，UCloud就開始致力于為分布各個(gè)地區(qū)的數(shù)據(jù)中心建設(shè)高可用高帶寬的同城環(huán)網(wǎng)，其主旨設(shè)計(jì)思想就是將地理位置相近的多個(gè)數(shù)據(jù)中心（Data Center, 以下簡(jiǎn)稱 DC）通過“雙星型網(wǎng)絡(luò)拓?fù)洹苯Y(jié)構(gòu)連接起來，從而使任意兩個(gè)數(shù)據(jù)中心之間都有高速、可靠、并具備全量冗余災(zāi)備能力的基礎(chǔ)網(wǎng)絡(luò)連接，如下圖所示：
從圖中可以看出，同一Region內(nèi)的任意一個(gè)DC都是通過多條專有光纖和兩個(gè)POP點(diǎn)相連。外網(wǎng)通信則是通過在POP點(diǎn)和各個(gè)上聯(lián)運(yùn)營(yíng)商之間建設(shè)的BGP 線路來保證的。任意兩個(gè)DC之間都有兩條全量冗余的邏輯線路（物理鏈路會(huì)依照現(xiàn)實(shí)的帶寬和冗災(zāi)需要進(jìn)行擴(kuò)容），因此即使一個(gè)POP完全不可用，DC和DC間，DC和Internet間的網(wǎng)絡(luò)連通也能保證聯(lián)通性。
另外，由于在POP點(diǎn)和各大上聯(lián)運(yùn)營(yíng)商都建立了BGP peering，因此在某條運(yùn)營(yíng)商線路質(zhì)量不佳或者出現(xiàn)中斷的時(shí)候，可以通過調(diào)整BGP廣播和路由的配置將用戶的流量臨時(shí)調(diào)度到其他的線路上去，保證網(wǎng)絡(luò)的正常工作。
對(duì)于云計(jì)算服務(wù)商而言，具備同城多地的部署和冗災(zāi)能力是必經(jīng)之路。這樣的基礎(chǔ)設(shè)施的設(shè)計(jì)和建設(shè)的能力，是一個(gè)IaaS服務(wù)商發(fā)展到一定規(guī)模和階段后必然的選擇。當(dāng)然，所謂的一個(gè)“地域”（Region）的建設(shè)不是隨意的，組成一個(gè)Region的數(shù)據(jù)中心除了單獨(dú)在資質(zhì)上需要滿足各個(gè)方面的條件（供水、供電、空調(diào)、濕度、防火、防震、基礎(chǔ)網(wǎng)絡(luò)等等）之外，還要在協(xié)同組網(wǎng)上滿足整體的需求，比如從DC到POP點(diǎn)之間的網(wǎng)絡(luò)延遲在0.5ms以下，DC與DC之間的網(wǎng)絡(luò)延遲在1ms以下，以及DC到POP點(diǎn)之間的帶寬要求等等。
在可用區(qū)項(xiàng)目的實(shí)施過程中，我們對(duì)幾個(gè)Region的基礎(chǔ)網(wǎng)絡(luò)都做了大量的變更以滿足我們的建設(shè)要求，比如POP點(diǎn)的建設(shè)、帶寬的擴(kuò)容、內(nèi)外網(wǎng)核心的分拆調(diào)整等等?，F(xiàn)在在華北、華東、華南，以及亞太等主力地域，我們都已完成了“雙星型”POP點(diǎn)的建設(shè)。
有一點(diǎn)需要注意的是，數(shù)據(jù)中心是一個(gè)物理概念，而可用區(qū)是一個(gè)邏輯概念，兩者之間不一定是一一映射的關(guān)系。一個(gè)邏輯上的可用區(qū)（AZ）可以包含一個(gè)或多個(gè)數(shù)據(jù)中心（DC），只要這些組成同一可用區(qū)的數(shù)據(jù)中心之間的物理環(huán)境是符合我們建設(shè)標(biāo)準(zhǔn)的：
可用區(qū)重點(diǎn)功能實(shí)現(xiàn)
在一個(gè)Region內(nèi)部署多個(gè)AZ并通過低延遲且全量冗余的“雙星型”拓?fù)浣Y(jié)構(gòu)進(jìn)行互聯(lián)，只是滿足了我們后續(xù)對(duì)可用區(qū)下平臺(tái)能力改造的前提條件。在可用區(qū)產(chǎn)品介紹中，我們已經(jīng)列舉了在可用區(qū)框架下對(duì)應(yīng)用服務(wù)跨地域互通、冗災(zāi)、平滑遷移等方面的一系列特性支持，如下圖：
我們?cè)谶@里著重針對(duì)EIP、ULB、以及共享帶寬三個(gè)產(chǎn)品做一個(gè)詳細(xì)的技術(shù)層面的剖析，看看在可用區(qū)實(shí)現(xiàn)背后蘊(yùn)含了哪些技術(shù)細(xì)節(jié)。
在原來的底層網(wǎng)絡(luò)架構(gòu)中，外網(wǎng)核心 (DC Core) 是下沉到每個(gè)數(shù)據(jù)中心內(nèi)的。也就是說云主機(jī)在訪問外網(wǎng)的時(shí)候，首先通過內(nèi)網(wǎng)達(dá)到外網(wǎng)接入服務(wù)集群，然后報(bào)文經(jīng)過處理后再經(jīng)由外網(wǎng)核心選擇合適的對(duì)端運(yùn)營(yíng)商線路訪問Internet。
然而，這樣的架構(gòu)決定了用戶使用的EIP (公網(wǎng)IP地址) 是無法跨DC漂移使用的。 因?yàn)樯嫌蔚木W(wǎng)絡(luò)運(yùn)營(yíng)商一直只會(huì)和云平臺(tái)之間動(dòng)態(tài)交互段路由或者使用更簡(jiǎn)單的靜態(tài)路由、而很少會(huì)支持云平臺(tái)向他們廣播全量的BGP明細(xì)路由，這么做的成本開銷太大；另一方面，即使運(yùn)營(yíng)商愿意支持BGP交互全量明細(xì)路由，云平臺(tái)自己的核心路由器也未必能支持那么大量的/32的明細(xì)路由（當(dāng)然云平臺(tái)可以選擇購(gòu)買更昂貴的高端路由器）。
因此，支持單個(gè)外網(wǎng)IP這樣細(xì)粒度的跨DC網(wǎng)絡(luò)流量調(diào)度一直是個(gè)難題——在實(shí)際實(shí)現(xiàn)中，我們發(fā)現(xiàn)不少友商使用的是一種變通的辦法：即，不追求全部的公網(wǎng)IP地址都能跨可用區(qū)漂移，而是劃分出一個(gè)特定地址段來，這個(gè)特定的IP段中分配的公網(wǎng)地址是具備跨AZ漂移能力的。比如AWS EC2 所提供的Elastic IP就是這樣的一個(gè)設(shè)計(jì)。只不過這些特殊的“彈性IP”在使用中可能會(huì)造成一定的困擾：首先用戶需要申請(qǐng)專門的EIP，然后在使用時(shí)需將新申請(qǐng)的Elastic IP綁定到主機(jī)上，但此舉也會(huì)同時(shí)將原主機(jī)上綁定的公網(wǎng)IP銷毀，使用不方便之余，原有的IP也無法再找回，若有備案等原因?qū)е略械腎P有一定特殊性必須要保留，這樣的操作必然會(huì)帶來更多的不便。
需要聲明的是：這是我們根據(jù)友商所提供的產(chǎn)品形態(tài)，由此對(duì)其后端的實(shí)現(xiàn)邏輯進(jìn)行的推斷，可能并不一定正確，歡迎讀者的討論和指正。
我們?cè)趯?duì)EIP可用區(qū)功能的擴(kuò)展中，首先確定了“簡(jiǎn)化EIP概念”這一設(shè)計(jì)主導(dǎo)思想，堅(jiān)決不引入第二類可能造成混淆的外網(wǎng)IP概念。在此前提下，我們決定將DC的外網(wǎng)核心上移至POP點(diǎn)，將和運(yùn)營(yíng)商之間的BGP peering終結(jié)在POP點(diǎn)。外網(wǎng)接入服務(wù)集群仍然分布式部署在各個(gè)DC中，它們能獨(dú)立地為所在DC中的UHost云主機(jī)提供外網(wǎng)流量的報(bào)文轉(zhuǎn)發(fā)處理能力。外網(wǎng)接入服務(wù)對(duì)報(bào)文處理的最后一步是將報(bào)文封裝后通過overlay的隧道送達(dá)POP點(diǎn)內(nèi)的虛擬邊界路由服務(wù)(UCloud Virtual Edge Router or UVER，關(guān)于UVER我們會(huì)在下文詳細(xì)介紹)，再經(jīng)由UVER剝離overlay封裝后送至外網(wǎng)的運(yùn)營(yíng)商線路上。UCloud有多種的外網(wǎng)接入服務(wù)，以下我們以NAT服務(wù)為例來看一下整個(gè)數(shù)據(jù)轉(zhuǎn)發(fā)面 (datapath) 經(jīng)過的每一跳上的處理流程（關(guān)于UVER的處理動(dòng)作，我們會(huì)在下文詳細(xì)敘述）：
我們來感受一下可用區(qū)改造前后整個(gè)架構(gòu)上的區(qū)別：
圖：可用區(qū)改造前整個(gè)架構(gòu)圖
圖：可用區(qū)改造后整個(gè)架構(gòu)圖
可以看出，通過將外網(wǎng)核心的上移，我們可以通過自身的SDN邏輯（即UVER）將地址（源或目標(biāo)）、將任意一個(gè)EIP的網(wǎng)絡(luò)流量自由地在不同的AZ之間調(diào)度，從而實(shí)現(xiàn)了EIP的跨AZ漂移。
討論完EIP之后，我們接下來看看ULB外網(wǎng)負(fù)載均衡的場(chǎng)景。從架構(gòu)上而言，ULB和EIP是很相近的：
通過UVER（(UCloud Virtual Edge Router，虛擬邊界路由）的調(diào)度，同一個(gè)ULB上的外網(wǎng)IP可以將流量分發(fā)到不同AZ內(nèi)的后端RS上，這樣的跨機(jī)房流量均衡和容災(zāi)的能力是很多應(yīng)用層的程序架構(gòu)所希望擁有的，也是云平臺(tái)必須提供支持的。同樣，我們來看一下整個(gè)數(shù)據(jù)轉(zhuǎn)發(fā)面上各個(gè)節(jié)點(diǎn)的具體處理：
值得注意的是，如果需要的話，UVER甚至可以將去向同一個(gè)目的EIP的相同端口的流量通過一致性哈希算法ECMP到不同的ULB服務(wù)器上從而大大提升單個(gè)EIP上可以承載的總體帶寬。也可以將去向同一個(gè)目的EIP的不同端口的流量分發(fā)到不同類型的ULB服務(wù)集群。例如，80端口分發(fā)到七層負(fù)載均衡，443端口分發(fā)到四層負(fù)載均衡。這是UVER這個(gè)虛擬邊界路由服務(wù)通過SDN的方式給平臺(tái)帶來的額外的彈性處理能力。
共享帶寬是UCloud平臺(tái)上一個(gè)比較特殊的帶寬產(chǎn)品，它允許多個(gè)EIP共享一個(gè)帶寬資源，后端控制面的程序在必要的時(shí)刻會(huì)根據(jù)每個(gè)帶寬資源中包含的所有的EIP的實(shí)時(shí)使用數(shù)據(jù)來調(diào)整帶寬的分配。在可用區(qū)之前，共享帶寬只能作用于隸屬同一個(gè)DC下的EIP組。但由于在可用區(qū)下，EIP是可以跨AZ的，因此很自然的，共享帶寬的功能也必須要能支持跨AZ的EIP組。
原先DC級(jí)別的共享帶寬服務(wù)的架構(gòu)比較簡(jiǎn)單：
圖：原先DC級(jí)別的共享帶寬服務(wù)的架構(gòu)
在每臺(tái)主機(jī)上，SDN Agent會(huì)采集UHost云主機(jī)實(shí)時(shí)的帶寬使用數(shù)據(jù)，然后上報(bào)到后端的Redis緩存服務(wù)中，控制面的管理程序 (UTraffic Manager) 根據(jù)上報(bào)的結(jié)果做實(shí)時(shí)的統(tǒng)計(jì)并計(jì)算需要調(diào)整的帶寬設(shè)置，然后通過SDN Agent來推送調(diào)整信令。
在可用區(qū)中，由于每個(gè)AZ間物理網(wǎng)絡(luò)都是可以直連的，因此我們最初的想法就是將Redis緩存和UTraffic Manager進(jìn)行擴(kuò)容即可。但在進(jìn)行了一番計(jì)算推演后，我們推翻了這個(gè)設(shè)計(jì)。主要原因在于，如果我們的架構(gòu)在一個(gè)Region內(nèi)只使用一套共用的后臺(tái)緩存服務(wù)（當(dāng)然為了容災(zāi)起見，我們會(huì)將Redis的集群分布在多個(gè)AZ內(nèi)）的話，整個(gè)Redis緩存服務(wù)需要承載的峰值流量將是巨大的。此外，在考慮了每個(gè)Region后續(xù)的擴(kuò)容計(jì)劃之后，這個(gè)矛盾只會(huì)在日后更加凸顯出來。因此我們決定對(duì)整個(gè)后臺(tái)架構(gòu)做一次分層的拆分：
圖：共享帶寬服務(wù)新架構(gòu)
在這個(gè)新架構(gòu)下，我們?cè)诿總€(gè)AZ會(huì)部署一套R(shí)edis服務(wù)。主機(jī)上的SDN Agent根據(jù)AZ屬性，上報(bào)到各自AZ的Redis。AZ-wide的UTraffic Manager會(huì)負(fù)責(zé)拉取本AZ的Redis數(shù)據(jù)，進(jìn)行第一次本地的匯總計(jì)算后，將共享帶寬的EIP帶寬信息定期上報(bào)到Region-wide的UTraffic Manager。Region-wide的Manager，負(fù)責(zé)計(jì)算最終的實(shí)時(shí)帶寬使用情況，然后決定流控策略。AZ-wide的UTraffic Manager會(huì)從Region-wide的UTraffic Manager處獲得指定的EIP的流控規(guī)則，然后主動(dòng)向SDN Agent推送。這個(gè)新架構(gòu)很好地平衡了我們對(duì)實(shí)時(shí)性和系統(tǒng)可用性的要求，也為之后的水平擴(kuò)展做了良好的鋪墊。
跨AZ的網(wǎng)絡(luò)流量調(diào)度能力是整個(gè)UCloud平臺(tái)SDN基礎(chǔ)架構(gòu)上的一個(gè)簡(jiǎn)單的應(yīng)用，但這一切的關(guān)鍵都在于擁有一個(gè)具備高性能處理能力和自適應(yīng)容災(zāi)能力的邊界轉(zhuǎn)發(fā)服務(wù)——這就是UVER（UCloud Virtual Edge Router）誕生的初衷。這也是本文介紹的最后一部分。
在UVER誕生之前，雖然所有的EIP訪問都已經(jīng)集中到了兩個(gè)POP點(diǎn)機(jī)房，POP點(diǎn)仍然是通過配置C段靜態(tài)路由的方式將EIP的下一跳設(shè)置為具體某個(gè)機(jī)房的外網(wǎng)核心路由器。而用戶可以在同Region內(nèi)任意可用區(qū)綁定EIP后，EIP的路由設(shè)置將不可能再通過靜態(tài)C段路由的方式來設(shè)置，必須引入動(dòng)態(tài)明細(xì)路由配置。而對(duì)硬件路由器來說動(dòng)態(tài)路由的條目數(shù)是有限制的，雖然我們可以選擇更高端型號(hào)的硬件路由器來提升支持的動(dòng)態(tài)路由條目數(shù)，但是考慮到未來UCloud的快速發(fā)展會(huì)對(duì)硬件選型帶來極大的限制，我們還是決定通過軟件的方式來解決這個(gè)問題。
我們首先來看一下UVER的整體架構(gòu)：
圖：UVER的整體架構(gòu)
UVER集群部署在POP點(diǎn)，向外網(wǎng)接入路由器廣播C段路由，引導(dǎo)Internet流量進(jìn)入U(xiǎn)VER。UVER根據(jù)數(shù)據(jù)包的目的IP地址，查找內(nèi)存中的明細(xì)路由表中的下一跳服務(wù)器信息。
進(jìn)行內(nèi)網(wǎng)標(biāo)準(zhǔn)的NVGRE封裝后通過內(nèi)網(wǎng)接入路由器轉(zhuǎn)發(fā)到具體的可用區(qū)機(jī)房的下一跳服務(wù)器上。
下一跳服務(wù)器需要出Internet的時(shí)候同樣通過內(nèi)網(wǎng)標(biāo)準(zhǔn)的NVGRE封裝后發(fā)送到UVER。
UVER服務(wù)器解除NVGRE封裝后通過外網(wǎng)接入路由器發(fā)送到Internet。UVER采用無狀態(tài)的路由模式設(shè)計(jì)，實(shí)現(xiàn)簡(jiǎn)單，容災(zāi)性能好。
總體而言，UVER從以下幾個(gè)方面來保證集群服務(wù)的高可用性：
將一致性哈希算法應(yīng)用于ECMP；
異地容災(zāi)；
分SET部署。
目前在同一個(gè)Region部署了多個(gè)UVER的SET，每個(gè)SET廣播不同的C段EIP路由負(fù)責(zé)一部分EIP的流量。SET間互相獨(dú)立，彼此不會(huì)互相影響。同時(shí)每個(gè)SET內(nèi)包含2個(gè)POP點(diǎn)的服務(wù)器，每個(gè)POP點(diǎn)服務(wù)器的規(guī)劃容量都能承載整個(gè)SET的業(yè)務(wù)。如果有部分EIP的流量特別大，將通過32位明細(xì)路由的方式，將該EIP的流量牽引到獨(dú)立SET進(jìn)行服務(wù)。同時(shí)在每個(gè)Region還有一個(gè)特殊的SET，稱為隔離區(qū)SET。所有檢測(cè)到突發(fā)不正常流量（DDoS）的EIP，將會(huì)被自動(dòng)牽引到隔離區(qū)SET，防止影響其他用戶的正常使用。
在選擇轉(zhuǎn)發(fā)目標(biāo)時(shí)，UVER將一致性哈希算法應(yīng)用于ECMP，從而實(shí)現(xiàn)了對(duì)后端有狀態(tài)的服務(wù)集群的容災(zāi)支持。即，在后端服務(wù)集群中發(fā)生宕機(jī)時(shí)，在UVER這層能最大限度地避免全局性的影響（比如全局哈希移位之類的問題）——理論上，只有發(fā)生宕機(jī)的那臺(tái)后端服務(wù)器上的連接會(huì)發(fā)生中斷需要重連，而其他通過UVER轉(zhuǎn)發(fā)的連接是不受影響的；另一方面UVER集群服務(wù)器本身又是無狀態(tài)的，因此UVER集群內(nèi)部發(fā)生宕機(jī)的話，其他服務(wù)器仍能正常地對(duì)所有經(jīng)過UVER集群的報(bào)文進(jìn)行轉(zhuǎn)發(fā)處理。從用戶的角度看，他們的連接是不受影響的。
因?yàn)椴捎昧薉PDK技術(shù)設(shè)計(jì)UVER，UVER的單機(jī)轉(zhuǎn)發(fā)性能達(dá)到20M pps，能夠提供20G bps的吞吐（10G入、10G出）。單個(gè)UVER SET可以最多由32臺(tái)服務(wù)器組成ECMP集群，能夠提供最大320G入、320G出的吞吐量。而每個(gè)Region可以部署的UVER SET并沒有限制。
在本篇技術(shù)分享中，我們分別介紹了可用區(qū)架構(gòu)下基礎(chǔ)物理網(wǎng)絡(luò)需要進(jìn)行的改造，以及外網(wǎng)新特性的具體實(shí)現(xiàn)。第一期功能發(fā)布后，我們同時(shí)也在著力于新特性的快速迭代開發(fā)。比如，支持ULB實(shí)例本身跨可用區(qū)部署等。希望通過這樣的分享，能夠和大家一起學(xué)習(xí)和探討那些我們樂此不疲的技術(shù)難點(diǎn)和解決方案。在下一篇連載中，我們將詳細(xì)討論和可用區(qū)相關(guān)的內(nèi)網(wǎng)特性和改造的一系列技術(shù)細(xì)節(jié)，敬請(qǐng)期待。
Y3（俞圓圓），UCloud基礎(chǔ)云計(jì)算研發(fā)中心總監(jiān)，負(fù)責(zé)超大規(guī)模的虛擬網(wǎng)絡(luò)及下一代NFV產(chǎn)品的架構(gòu)設(shè)計(jì)和研發(fā)。在大規(guī)模、企業(yè)級(jí)分布式系統(tǒng)、面向服務(wù)架構(gòu)、TCP/IP協(xié)議棧、數(shù)據(jù)中心網(wǎng)絡(luò)、云計(jì)算平臺(tái)的研發(fā)方面積累了大量的實(shí)戰(zhàn)經(jīng)驗(yàn)。曾經(jīng)分別供職于Microsoft Windows Azure和Amazon AWS EC2，歷任研發(fā)工程師，高級(jí)研發(fā)主管，首席軟件開發(fā)經(jīng)理，組建和帶領(lǐng)過實(shí)戰(zhàn)能力極強(qiáng)的研發(fā)團(tuán)隊(duì)。
