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極化？

② 若是用戶流量沒法打散，又該如何防止「大象流」打爆物理雲網絡？

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

二、如何避免封裝隧道後的Hash極化？

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

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

② 方案2：交換機基於隧道內層報文Hash。該方法基於用戶的報文打散，優勢在於能夠較爲均衡地打散在集羣不一樣設備上。但問題在於用戶報文封裝隧道後會再次分片，將致使內層報文信息缺失和分片報文Hash到不一樣設備上。

③ 方案3：爲集羣每臺設備分配單獨的隧道源IP。該方法能夠實現有效的流量打散，但因爲隧道數量有限，Hash不均的問題在現網實際表現依舊明顯。

以上三個方法均不一樣程度地存在缺點，不能徹底解決Hash極化問題。經過一系列的研究，最終咱們找到了一種多隧道解決方案。即打破網關的單隧道模式，全部的網關綁定一個網段的隧道IP，基於用戶的內層報文信息Hash，並在預先分配的網段中選擇隧道的SIP和DIP，保證不一樣流量儘量分佈在不一樣的隧道，從而將用戶流量打散。

圖：多隧道解決方案示意

三、如何防止「大象流」打爆物理雲網絡？

多隧道方案的前提在於用戶流量能夠被打散，可是若是遇到「大象流」呢？即使是多個隧道也沒法將避免被打爆的狀況。面對用戶的「大象流」，單靠技術手段還不夠，咱們同時也須要從硬件配置方面作好事前預防和規避。

■ 單機容量管理

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

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

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

■ 隔離區無損遷移

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

圖：隔離區無損遷移

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

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

在新方案上線前，因爲Hash極化現象，集羣一般只能承載幾十G的流量，而且不時出現過載的狀態。

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

圖：流量監控圖示意

除了提高性能，此次集羣升級中對高可用設計也作了優化。

2、集羣升級後的高可用性優化

針對集羣升級，通常狀況下會先部署新灰度集羣，而後將用戶業務逐步進行遷移。這樣的好處在於能夠在新集羣版本存在缺陷的狀況下，最大限度的控制影響範圍，當出現故障時，能夠及時回遷受影響的用戶業務到老集羣，避免用戶業務受到影響。

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

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

在新集羣Manager部署完畢後，因爲配置錯誤致使灰度集羣接管了舊集羣，Manager基於配置文件的集羣信息自動接管集羣的控制，並直接下發配置信息，舊集羣接受錯誤配置。因爲舊集羣和新集羣配置差別較大，致使舊集羣在解釋新配置時有誤，出現高可用異常。

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

一、風險分析

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

① 部署人爲干預多，會加大故障機率；

② 程序的異常保護不夠；

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

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

■ 自動化運維

自動運維化經過自動化代替人工操做，能夠有效避免人爲錯誤的發生。咱們對集羣部署流程進行了優化，將其分爲配置入庫和部署兩個流程，運維人員只需錄入必要的配置信息，其他均經過自動化生成部署。

■ 完善校驗和告警

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

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

■ 隔離影響

最後，無論自動化運維機制和程序自身多精密，總要假設異常的可能。在此前提下，還須要考慮在故障發生時如何最大程度地減小影響範圍和影響時間。咱們的解決思路以下：

► 去除公共依賴

前次問題主要緣於集羣全部設備同時依賴了異常的Manager，致使一損俱損。所以須要去除集羣設備中的公共依賴，縮減影響範圍。例如不一樣的集羣綁定不一樣Manager，這樣能夠有效控制影響範圍。固然集羣的公共依賴不只僅可能出如今Manager，也多是一個IP、一個機架等，這就須要咱們在實際項目中仔細甄別。

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

總結

隨着技術的發展和業務的擴張，系統架構愈加複雜、關聯度愈加緊密，對技術人員的要求也愈來愈高。在物理雲網關集羣的開發過程當中，不可避免會遇到不少「坑」，可是不管什麼時候都需秉承一點：一切技術都是爲了業務服務。爲此，咱們把方案設計的經驗分享出來，但願可以給予你們更多思考與收穫。