UCloud下一代VPC架構平滑演化方案和技術詳解

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

前言
2月27日，UCloud推出了下一代VPC網路（下面簡稱VPCng）。VPCng旨在解決客戶網路使用情境中的痛點，如IP網段的自主規劃、跨可用性區域容災、VIP跨區高可用方案、混合雲和公用雲端的無縫串連等。
UCloud認為VPC（Virtual Private Cloud）是隸屬於租戶的虛擬網路。在虛擬網路中租戶能完全掌控網路環境，自主管理所有的雲端服務資源，並能靈活擴充混合雲能力，VPC的最終目標是給使用者提供和傳統網路完全一致的功能。
這次推出的新特性如靈活的地址空間管理、VIP跨可用性區域都是業界首創。不過使用者看不見的是，我們在後台服務做了大量工作，許多控制面和轉寄面的邏輯被重構。這些新功能不僅部署在新機房，UCloud在存量機房通過平滑升級，使得使用者大量的已部署業務也能享受到這些新功能。
存量機房的原地升級和新機房部署是完全不同的工作。前者要考慮複雜的現網環境，存量機房往往包含多個曆史版本，還有針對某些客戶做的定製化邏輯，新特性的實現要考慮到各種情境下的相容性。現網的控制資料也要轉換成新格式。網路作為系統級的底層服務，幾乎被所有的雲端服務所使用，其原地升級要比其他產品更為複雜，堪稱是雲端運算中的移花接木。另外，網路原地升級必須要保證使用者的業務不受哪怕1秒鐘的中斷。為了控制風險，全網一次性的升級是萬萬不可的，只能通過漸進的、螞蟻搬家式的灰階升級才能做到平穩運營，才能做到步步為贏。
接下來，一起看下UCloud VPCng平滑升級的架構方案和技術細節。
VPCng架構
VPCng的網路架構如所示，主要由VPC、Subnet、RouteTable三大核心模組組成：
Subnet是VPC資源管理的最小單位，用來管理雲主機、物理雲主機、雲資料庫、容器等資源，VPCng的一大亮點是Subnet可以跨可用性區域，對於跨可用性區域災備提供有力保障。

RouteTable是VPCng設計的核心，負責分布式虛擬路由（DVR）的管理。每個子網都需要關聯一張路由表。

圖1 VPCng整體架構
分布式虛擬路由（DVR）
現有的VPC網路中，部分產品在使用自訂子網時需要先去建立一個虛擬路由器（VRouter）。路由器具備三個特性：多主機共用出外網、指定連接埠轉寄、子網間內網互連。東西向和南北向的流量都要經過虛擬路由器。兩個子網互連需要經過VRouter，子網訪問外網也需要穿越VRouter，這樣不僅實體路徑上多了一跳，並且VRouter本身會成為效能瓶頸。

圖2 集中式路由器架構
VPCng重構了路由定義，並抽象為分布式虛擬路由DVR。DVR的載體是分散在各個計算節點上的虛擬交換器，而路由表是其核心。如，東西向流量通過虛擬交換器進行分發，實現點對點通訊。而NATGW只是作為外網訪問的網關裝置，提供多子網共用出外網能力。在路由表設計上，支援多種路由類型，包括直連路由、預設路由、混合雲路由、主機路由等等，除此之外還支援策略路由以及定義路由優先順序。

圖3 分布式虛擬路由（DVR）架構
DVR作為VPCng設計的核心，平滑升級尤為重要。VPCng設計之初就考慮到上線過程要做到對使用者透明，在不影響現有業務情況下，平滑升級到新架構中，所以在升級方案設計上也比較複雜。
整個升級過程拆分成四個階段。
Stage1 路由表資料移轉
大型分布式系統的平滑升級，最難做到的是控制資料的無縫遷移。VPCng的路由表結構變動很大，在此我們借鑒了可用性區域升級中經典的“雙寫方案”，先將存量資料轉換為新表結構，然後改造現有管理服務模組，使其具備新老表雙寫能力。這個階段資料一致性是最重要的，必須時要通過對賬進行一致性校正。

Stage2 SDN轉寄面服務升級
轉寄面服務直接影響到存量使用者的現網服務，所以升級過程必須慎之又慎。 路由表和控制器模組是本次SDN轉寄面服務升級的重心，我們通過設計一層轉寄Proxy實現了按使用者灰階的能力，只有灰階使用者才能走到新轉寄邏輯，有效控制灰階影響範圍。

Stage3 SDN控制面服務升級
為了滿足VPCng的功能和效能需求，這個階段我們做了大量重構，原有控制面架構採用分層結構，可擴充性不好。新加特性涉及多處改動，而且容易造成髒資料。UVPCFE是一套基於Golang語言開發微服務系統，穩定、快速，可擴充性好。UVPCFE通過APIGW灰階系統同樣做到使用者層級的灰階。這個階段由於前端尚未開放，所以仍然需要保證資料的“雙寫”。

Stage4 前端開放升級
前三個階段完成後，存量使用者後台已經運行在新的網路架構下。所以Stage4階段要做的事情變的簡單，只要把VPCng的控制台開放給使用者即可。圖中綠色部分表示VPCng商務邏輯，藍色部分表示原有邏輯，這兩套邏輯在灰階過程中長期存在，一旦發現新邏輯有缺陷，可以立即復原到原有邏輯，現有業務不受影響。

圖4 VPCng灰階方案
詳細的升級方案讓平滑升級過程變得可行、可控、可復原，在實際操作中也會遇到各種問題。底層網路架構升級，對各個業務（雲主機，雲資料等）的管理服務都會產生影響，必然會存在業務間的耦合，即便是網路系統內部模組也會存在灰階時序問題。如何做到解耦合？如何控制好灰階發布節奏？這些問題都離不開系統化的統籌和精細化的運營，這是考驗一支團隊是否具備大型分布式系統持續運營的能力。

公用服務
UCloud雲平台提供了許多公用服務如內網DNS、NTP、軟體源等，這些公用服務對所有租戶開放。不同租戶的IP可能相同，他們都可能去訪問公用服務後端伺服器，所以後端伺服器無法通過路由表決定返回哪個租戶。舉例來說：租戶A和租戶B雲主機的IP地址均為172.16.0.16，當訪問內網DNS時，DNS伺服器回複時無法決定是送到租戶A還是B。

圖5 公用服務集中式NAT架構
現有VPC網路是通過NAT轉換來實現的，這也是業界主流的解決方案，這需要解決兩個問題：
首先，要解決使用者子網和公用服務子網網段重疊導致路由衝突問題。考慮到公用服務子網規模不大，通常採取預留網段的方式，確保公用服務網段不被使用者使用。
其次，要解決NAT轉換的問題。
UCloud團隊論證了多種NAT可行方案，這裡介紹兩種：
NAT Gateway採用namespace方案，為每個租戶建立獨立的namespace，在namespace裡面進行SNAT轉換，通過SNAT後的IP去訪問公用服務。公用服務響應的報文在namespace裡面進行DNAT轉換，送回給租戶，從而達到訪問公用服務目的。
NAT Gateway會將租戶ID資訊儲存到SKB的mark上，通過核心netfilter模組做SNAT轉換，同時connection track中會維護mark對應關係。NAT Gateway收到公用服務響應報文後匹配connection track，得到mark，然後通過netfilter做DNAT將mark對應報文返回給租戶。

這些NAT方案存在兩個問題，一是源地址不可見，如果公用服務依賴源地址，則此方案不可行；二是NAT Gateway是效能瓶頸，特別是針對大流量的公用服務（如UFile），需要搭建多台伺服器方能支撐。
VPCng吸收了分布式NAT理念，將集中式的NAT Gateway分散到各個計算節點的虛擬交換器上，解決了網關效能的問題，並自主研發一套NAT Plugin來解決源地址問題，不同租戶即使IP相同也能正常訪問公用服務。分布式NAT架構圖如下：

圖6 公用服務分布式NAT架構
混合雲
混合雲串連傳統IT和公用雲端，博採眾之所長，目前已是雲端運算發展的主流趨勢之一。在傳統的混合雲方案中，混合雲只是作為若干網段接入公用雲端，使用者的諸多日常需求比如路由管理、頻寬容量管理，混合雲日常營運需要大量人力和溝通成本，亟需最佳化。
在VPCng的設計方案中，混合雲抽象為租戶的一個獨立VPC，其中包含多個子網，子網可以是託管裝置網段，也可以是通過光纖、數字鏈路、VPN串連到公用雲端POP點的自建IDC網段。混合雲VPC的架構圖如下：

圖7 混合雲VPC架構
為了在功能上完全相容VPCng，混合雲需要支援使用者自訂混合雲網段、使用者自訂混合雲路由策略、使用者自主控制混合雲的連通許可權等特性，因此混合雲系統的控制面需要完全重構，另外對於作為轉寄面核心的混合雲網關提出了轉寄能力、路由控制能力、鑒權能力等全方位的新需求。此外，我們還必須保證讓使用者無感知地從傳統混合雲升級到混合雲VPC。
控制面
我們設計了與舊混合雲控制系統完全解耦的新系統，資料庫、控製程序均與舊版本獨立。在使用者添加路由、修改網段等動作時，API層利用訊息佇列對DB進行雙寫，同時通過DB對賬保證資料的一致性。新舊系統分別擁有獨立的轉寄面，分別獨立拉取後台配置，確保新舊系統除了雙寫動作其他動作均解耦。

轉寄面
為了支援混合雲VPC，我們開發了新版本的混合雲網關。通過拉取後台配置，網關執行相關報文的鑒權、轉寄、封裝和解鎖裝等操作。同時，網關叢集擁有scale out的能力，可無縫擴容，最高支援高達數百G的流量轉寄。
混合雲網關的無縫切換是升級的核心步驟。我們開發了多個工具以輔助這個關鍵過程：
基於Netconf的交換器配置API，用於切換及回退交換器側路由配置。
基於VPCng的路由切換API，VPCng控制後台結合推送與拉取，可以在10s內更新全網三層路由流表。該API用於切換及回退公用雲端側的路由配置。
基於OVS PacketOut的連通性檢查工具，通過拼接ICMP報文，注入到公用雲端宿主機的OVS Virtual Interface上，可以類比使用者的業務互連，並基本覆蓋使用者的連通性黑盒檢查情境。
基於交換器統計資料、混合雲網關統計資料的流量統計工具，可以從統計角度確認使用者切換前後的流量狀況。

轉寄面的切換過程如所示：

圖8 混合雲VPC轉寄面切換流程
步驟一：調用交換器側路由切換API，切換PE的路由，此時，混合雲側向公用雲端側的流量已經切換至新混合雲網關，而公用雲端側到混合雲側的流量則仍然給到舊混合雲網關。我們在網關類產品設計的一條基本理念就是路由交換網關一定要是無狀態的，因此使用者的服務不會受到任何影響。切換之後，利用連通性檢查工具和流量統計工具進行檢查，如發現異常立即回退。
步驟二：調用公用雲端側路由切換API，切換公用雲端側路由。切換完成後，新混合雲網關將承載全部流量。同樣利用工具進行檢查，發現異常則回退。
我們按照上述策略對多個使用者的混合雲系統進行了成功升級，從實踐來看，使用者完全無感知。

結束語
雲網路是大型公用雲端平台的基石，網路架構調整是對雲端服務商研發、交付、運營等綜合能力的考驗。從系統設計、灰階方案，到每個階段實施、變更發布、最後交付，UCloud VPCng最大化做到了平滑演化。
另外，在本篇技術分享中，我們也詳細介紹了VPCng在升級過程中遇到的幾個關鍵問題以及應對之策，當然VPCng升級複雜度還不止這些，歡迎大家就相關技術細節進行討論。