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