物理雲主機是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異常只會影響集羣中的部分設備，在該情況下還應該迅速剔除異常設備或者直接遷移該集羣下的所有用戶到隔離區，爭取最快時間排除故障。
總結
隨着技術的發展和業務的擴張，系統架構越發複雜、關聯度越發緊密，對技術人員的要求也越來越高。在物理雲網關集羣的開發過程中，不可避免會遇到很多“坑”，但是無論何時都需秉承一點：一切技術都是爲了業務服務。爲此，我們把方案設計的經驗分享出來，希望能夠給予大家更多思考與收穫。
