UCloud物理云網關百G級集群設計實踐

物理云主機是UCloud提供的專用物理服務器，具備出色的計算性能，滿足核心應用場景對高性能及穩定性的需求，也能和其它產品靈活搭配。物理云網關用于承載物理云和公有云各產品間的內網通信，由于用戶有多地部署的必要，網關集群面臨跨地域跨集群的流量壓力。

我們用多隧道流量打散等手段解決了Hash極化造成的流量過載問題，并通過容量管理和隔離區無損遷移限制大象流。新方案上線后，集群從承載幾十G升級為可承載上百G流量，幫助達達等用戶平穩度過雙十一的流量高峰。以下是實踐經驗分享。一

一、流量過載的物理云

為了保證云上業務的高可用性，用戶通常會將業務部署在不同地域。此時用戶的物理云便需要通過物理云網關相互訪問，不可避免地，物理云網關會承載大量物理云主機的跨集群訪問流量。

與此同時，為了保證不同用戶之間網絡流量的隔離和機房內部的任意互訪，物理云網關會對用戶報文封裝隧道，然后發送至接收方。

1、問題出現：Hash極化與過載的物理云

如下圖，我們發現物理云集群2中網關設備e的帶寬過載，影響了訪問集群2的所有業務。通過監控進一步查看到，集群2的流量分布很不均勻，集群中部分設備帶寬被打爆，但是剩余的設備流量卻很小。通過抓包分析，網關設備e的流量幾乎全部來自于物理云集群1。

圖：跨集群訪問時封裝隧道示意

結合業務分析，確定物理云過載的原因在于：物理云集群1和集群2之間的互訪流量出現了Hash極化，導致流量分布不均。

那什么是Hash極化呢？

由于集群之間使用單條隧道傳輸，隧道封裝隱藏了用戶的原始信息，例如IP、MAC等，對外只呈現隧道信息，同時隧道采用了唯一的SIP和DIP。那么Hash算法相同，算出的結果一致，導致流量無法做到很好的負載分擔，便會使集群的單臺設備負載突增，極端情況下就會出現被打爆的現象，進而影響該集群下的所有用戶，這就是Hash極化，常出現于跨設備的多次Hash場景。

根據現狀，我們分別嘗試從以下兩個角度解決該問題：

①?如果用戶流量可以打散，如何避免封裝隧道后的Hash極化？

②?如果用戶流量無法打散，又該如何防止“大象流”打爆物理云網絡？

下面，我們分別從這兩點出發研究對應的解決方案。

2、如何避免封裝隧道后的Hash極化？

針對這個問題，起初我們提出了多個解決方案：

①?方案1：用戶流量由交換機輪詢發送到集群每臺設備。這種方法的優點在于流量可以充分打散，不會出現Hash極化現象。但同時缺點在于網絡報文的時序被打亂，可能影響用戶業務。

②?方案2：交換機基于隧道內層報文Hash。該方法基于用戶的報文打散，優點在于可以較為均衡地打散在集群不同設備上。但問題在于用戶報文封裝隧道后會再次分片，將導致內層報文信息缺失和分片報文Hash到不同設備上。

③?方案3：為集群每臺設備分配單獨的隧道源IP。該方法可以實現有效的流量打散，但由于隧道數量有限，Hash不均的問題在現網實際表現依舊明顯。

以上三個方法均不同程度地存在缺點，不能完全解決Hash極化問題。通過一系列的研究，最終我們找到了一種多隧道解決方案。即打破網關的單隧道模式，所有的網關綁定一個網段的隧道IP，基于用戶的內層報文信息Hash，并在預先分配的網段中選擇隧道的SIP和DIP，保證不同流量盡可能分布在不同的隧道，從而將用戶流量打散。

圖：多隧道解決方案示意

3、如何防止“大象流”打爆物理云網絡？

多隧道方案的前提在于用戶流量可以被打散，但是如果遇到“大象流”呢？即便是多個隧道也無法將避免被打爆的情況。面對用戶的“大象流”，單靠技術手段還不夠，我們同時也需要從硬件配置方面做好事前預防和規避。

■ 單機容量管理

首先需要對物理云網關進行合理的容量管理，保證網關可承載帶寬高于用戶物理云主機的帶寬，同時保證整集群的承載能力滿足用戶需求。

圖：示例-將單機容量從10G調整為25G

這一點其實與云廠商自身的能力密切相關，目前UCloud網關集群單機的承受能力遠遠大于單個用戶的流量，在承載多用戶匯聚流量的情況下，仍能保證個別用戶的突發“大象流”不會打爆網關。

■?隔離區無損遷移

提升單機容量還遠遠不夠，以防萬一，UCloud還配備了隔離區，隔離區通常是無流量通過的。

圖：隔離區無損遷移

如上圖，一旦監測到流量過大，存在集群被打爆的風險時，集群配套的自動遷移系統便會修改需要遷移的物理機數據庫信息，并自動更新對應轉發規則，部分業務流量便可通過隔離區分擔出去。同時我們還會基于強校驗技術對遷移結果進行自動驗證，保證遷移業務的無損可靠。

4、實例：新舊方案下的用戶應用對比

在新方案上線前，由于Hash極化現象，集群通常只能承載幾十G的流量，并且不時出現過載的狀態。

新方案上線后，如下監控圖，可以看到流量基本在集群上打散，集群的優勢得到了充分發揮，目前集群可以承載上百G的流量，充分抵御用戶業務量突增時的風險。例如達達在雙十一時60G的流量壓力是普遍現象，突發時還會出現流量達到100G的情況，此時集群流量依舊轉發正常，對業務毫無影響。

圖：流量監控圖示意

除了提升性能，這次集群升級中對高可用設計也做了優化。

二、集群升級后的高可用性優化

針對集群升級，一般情況下會先部署新灰度集群，然后將用戶業務逐步進行遷移。這樣的好處在于可以在新集群版本存在缺陷的情況下，最大限度的控制影響范圍，當出現故障時，可以及時回遷受影響的用戶業務到老集群，避免用戶業務受到影響。

圖：預期結果-新Manager接管灰度集群

在灰度過程中，曾發現一個問題。

在新集群Manager部署完畢后，由于配置錯誤導致灰度集群接管了舊集群，Manager基于配置文件的集群信息自動接管集群的控制，并直接下發配置信息，舊集群接受錯誤配置。由于舊集群和新集群配置差異較大，導致舊集群在解釋新配置時有誤，出現高可用異常。

圖：灰度Manager錯誤接管舊集群示意

1、風險分析

為了系統性避免這類問題，我們對配置過程進行了回溯分析，總結了存在的風險：

①?部署人為干預多，會加大故障概率；

②?程序的異常保護不夠；

③?集群之間的有效隔離不足，若故障影響范圍大。

2、優化：自動化運維&程序優化&隔離影響

■ 自動化運維

自動運維化通過自動化代替人工操作，可以有效避免人為錯誤的發生。我們對集群部署流程進行了優化，將其分為配置入庫和部署兩個流程，運維人員只需錄入必要的配置信息，其余均通過自動化生成部署。

■?完善校驗和告警

此外，我們還對部分程序作了優化，加大對異常配置的校驗。例如，配置加載前，首先需進行白名單過濾，如果發現配置異常則終止配置加載，并進行告警通知后續人工介入。

圖：白名單限制程序，只允許正確的控制面同步配置

■?隔離影響

最后，不管自動化運維機制和程序自身多精密，總要假設異常的可能。在此前提下，還需要考慮在故障發生時如何最大程度地減少影響范圍和影響時間。我們的解決思路如下：

??去除公共依賴

前次問題主要緣于集群所有設備同時依賴了異常的Manager，導致一損俱損。因此需要去除集群設備中的公共依賴，縮減影響范圍。例如不同的集群綁定不同Manager，這樣可以有效控制影響范圍。當然集群的公共依賴不僅僅可能出現在Manager，也可能是一個IP、一個機架等，這就需要我們在實際項目中仔細甄別。

??設置隔離區在影響范圍可控的情況下，一個Manager異常只會影響集群中的部分設備，在該情況下還應該迅速剔除異常設備或者直接遷移該集群下的所有用戶到隔離區，爭取最快時間排除故障。

總結

隨著技術的發展和業務的擴張，系統架構越發復雜、關聯度越發緊密，對技術人員的要求也越來越高。在物理云網關集群的開發過程中，不可避免會遇到很多“坑”，但是無論何時都需秉承一點：一切技術都是為了業務服務。為此，我們把方案設計的經驗分享出來，希望能夠給予大家更多思考與收獲。