秒級容災，UCloud 內網高可用服務之三代架構演進

快節奏的生活，任何的業務異常 / 中斷都是不能容忍的。

在無人化超市選購完成進行結帳時，結帳頁面忽然卡住，沒法完成購買操做。這時該選擇放棄手中的商品 or 繼續等待？

酒店辦理入住時，管理系統忽然崩潰，沒法查詢預訂記錄，致使辦理入住受到影響，酒店前臺排起了長隊……

高可用與咱們每一個人都是息息相關的，在即將到來的雙十一，更是對各個電商的業務可用性提出了更高的要求。對此，UCloud 提供基於內網 VIP 的高可用服務，內網 VIP 經過先後三代廣播集羣的設計演進，解決了複雜異構 Overlay 網絡下的廣播實現問題，得到秒級高可用切換能力，並可以很好的支持物理雲。

下面，本文將對 UCloud 秒級切換的內網高可用服務進行詳細介紹。

基於內網 VIP 的高可用服務

一、高可用的理念和要點

從業務角度看，固然要儘量避免應用出現故障。但要徹底不出故障是不可能的。

那如何解決這個問題呢？答案就是相信任何單一節點都不可靠，要爲每一個節點增長備份。當任一節點發生故障時，業務自動切換至正常節點，且整個切換過程用戶均無感知，這就是高可用的基本理念。而實現高可用的兩個要點是備份節點和自動故障轉移。

圖：一旦 A 發生故障，便會迅速切換至 B

二、傳統網絡的高可用方案

在傳統網絡中，Keepalived + 虛擬 IP 是一個經典的高可用解決方案。

Keepalived 是基於 VRRP 協議的一款高可用軟件，有一臺主服務節點和多臺備份節點，並部署相同的服務。主節點對外使用一個虛擬 IP 提供服務，當主節點出現故障時，Keepalived 發起基於 VRRP 的協商，選擇備節點升級爲主節點，虛擬 IP 地址會自動漂移至該節點，同時利用 GARP 宣告虛擬 IP 的位置信息更新，從而保證服務正常。

三、雲計算 Overlay 網絡下的高可用

雲計算下的網絡架構發生了巨大變化，傳統的網絡架構已經更新爲 Overlay 網絡，並出現了各種複雜的異構網絡。那麼在新的網絡環境下，該如何解決高可用這個問題呢？

首先咱們看一下雲計算網絡的基本原理：

圖：雲計算網絡的實現

如上圖，雲資源都橋接在 OVS 的網橋上，同時業務網卡也橋接在 OVS 的網橋上，Controller 爲 UCloud 基於開源框架 Ryu 自研實現。Controller 經過與後臺 Manager 的交互，拉取 ACL、路由表、VPC 聯通、隔離等各種信息，並經過 OVS Message 將 Flow 固化在 OVS 的網橋上，達到 Flow 管理的目的，實現 ACL 的聯通與阻斷、三層轉發的功能，進而完成 VPC 聯通及租戶隔離的能力。上層的實際業務報文，經過 GRE 封裝，對下層網絡保證透明。

鑑於用戶在雲計算網絡中實現高可用的複雜性，UCloud 設計了內網 VIP 產品，爲雲平臺上的雲主機、物理雲主機提供服務。做爲用戶自定義高可用服務的可漂移內網入口，從發現故障到自動完成故障切換，無需額外的 API 調用和機器內部配置，便可完成秒級切換。

圖：內網 VIP 控制檯操做界面

內網 VIP 如何實現故障轉移的秒級切換？

內網 VIP 的故障切換時長一般與如下兩個步驟相關：

一、Master 發生故障後，備服務器須要選舉出新的 Master；

二、須要在廣播域內告知其餘節點，該 IP 的位置發生了變化。

如上文所述，在 Overlay 網絡中，上層業務報文的 ARP 協議解析、IP 尋址、單播、多播、廣播都須要從新實現，會有不小難度。那麼廣播應當如何實現呢？

UCloud 基於廣播的實現機制，演進出了以下的三個版本。

第一代：模擬廣播

圖：模擬廣播

如上圖所示，一個廣播報文直接複製 N 份，送到其餘廣播域中的節點，便可完成廣播的行爲。因爲 OVS 支持報文的複製和傳輸，只須要在 Flow 中指定多個 Output 動做便可實現。Flow 的模式以下：

圖：模擬廣播中 Flow 模式

這種實現確實能夠知足需求，可是存在幾個明顯的缺點：

一、Flow 的更新。因爲用戶的廣播域是變化的，一旦廣播域發生變化，那麼全部廣播域中節點所在宿主機上的廣播 Flow 所有須要推送更新。所以若是用戶的廣播域比較大，這種更新很是消耗性能。

2.、Flow 的長度數量有限制。OVS 對 Flow 的長度有要求：單條 Flow 的長度不能超過 64K bit，而廣播域增長的時候，Flow 的長度必定隨之增加。若是客戶的子網比較大，致使超過了 Flow 的長度限制，那麼就沒法再進行更新，出現廣播行爲異常，進而影響高可用實現。

三、異構網絡的廣播須要單獨實現。好比物理雲主機底層不是基於 OVS 的架構，那麼就必須重現一遍，開發和維護成本很高。

爲解決上述問題，UCloud 開發出了第二代廣播解決方案 —— 廣播集羣：

第二代：廣播集羣

圖：廣播集羣

如上圖，全部的廣播流量經過 Flow 指向自研的廣播集羣。廣播集羣從業務數據庫中拉取廣播的信息，對報文進行復制和分發。廣播集羣是 UCloud 基於 DPDK 自研的高可用集羣，能夠高性能地實現廣播邏輯。

採用廣播集羣，咱們很好的解決了第一代廣播邏輯中存在的問題：

一、廣播域的變化問題。廣播域變化只須要通知廣播集羣便可，無需全網告知。

二、廣播域的大小問題。廣播集羣經過 DPDK 來進行報文的複製和轉發，理論上廣播域無上限。

三、各類網絡的適配問題。各種網絡只須要將廣播報文送到廣播集羣便可，無需進行額外的邏輯開發，很好的適配了各類網絡場景。

隨後，在第二代的基礎上，UCloud 又提供了第三代的廣播解決方案：

第三代：廣播集羣 + GARP 嗅探

圖：基於 GARP 嗅探的廣播集羣

在第二代廣播集羣已經能夠很好的實現高可用服務的狀況下，UCloud 爲何還要開發出第三代呢？

從前文咱們能夠知道，在 VIP 切換的過程當中，GARP 將利用廣播告知整個廣播域，進而 VIP 發生漂移。可是廣播域以外的服務器是沒有能力獲知相關信息的。這樣就會出現下列問題：VIP 的切換會致使跨三層的訪問失效。

而跨三層的訪問則要求後臺數據庫必須經過某種方式獲知 VIP 位置的變化。在內網 VIP 的切換過程當中，GARP 報文會通知廣播域內的節點 VIP 的位置信息變化，而廣播集羣能夠獲取到全部的廣播流量。所以，廣播集羣利用 ARP_SPA=ARP_TPA 的特徵過濾獲得 GARP 流量，將相應的位置信息上報到後臺，並更新 Flow 信息，從而保證三層的訪問正常。

在第三代架構下，廣播集羣對公有云、物理雲等多種異構網絡均進行了支持，知足不一樣雲計算高可用應用場景的需求。

應用實例解析

一、電商支付系統高可用實踐

某電商在頻繁的平常消費與各種促銷活動中對支付系統可用性提出了很高的要求。消費者對支付系統的可用性是很是敏感的，一旦出現任何一點小小的故障，諸如 「付款失敗、從新支付、支付超時」 等都會帶來很差的使用體驗，嚴重時甚至可能致使用戶流失。

在不考慮外部依賴系統突發故障的前提下，如網絡問題、第三方支付和銀行的大面積不可用等狀況，該電商但願經過提升自身支付系統的高可靠服務能力來保證消費者的可用性體驗。

爲了實現高可用，UCloud 基於 Keepalived + 內網 VIP 產品爲該電商線上支付系統快速構建了高可靠服務，從而避免自身單點故障，大大提升系統的可用性。

圖：高可用服務構建實例

如上圖，VIP 綁定在 UPHost（物理雲主機）做爲主節點存在，當 VIP 綁定的 Master 節點發生故障的時，便會發生 VIP 漂移。物理雲網關收到 GARP 報文，並將 GARP 報文送至廣播集羣。廣播集羣分析 GARP 報文後，會將位置上報到後端，並更新物理雲網關配置和公有云平臺的 Flow。隨後，廣播集羣複製 GARP 報文，併發送到廣播域內的全部 UHost 和 UPHost。二層訪問的信息和三層訪問的信息都會在秒級內獲得更新，保證業務的高可用。

二、UCloud 雲數據 UDB 產品高可用技術實現

在 UCloud 雲數據 UDB 產品的高可用技術實現中，也一樣應用了內網 VIP 技術。以下圖，UDB 產品採用雙主架構，並經過 Semi-Sync 實現數據同步，由 UDB 可用性管理模塊實時監控底層節點可用性，一旦監測到 Master DB 不可用，便會自動觸發容災切換機制，內網 VIP 無狀態漂移至 Standby DB，保證用戶 UDB 數據庫服務的穩定可靠。

圖：基於內網 VIP 的 UCloud 高可用 DB 技術實現

在 UDB 高可用實現的過程當中，因爲採用單一內網 VIP 接入，所以能夠完成應用層的無縫切換，整個過程當中無需用戶進行任何人工干預和配置修改。依託內網 VIP，UDB 產品爲用戶提供了高可用的數據庫服務，目前該產品已經服務於上萬家企業並提供了數萬份數據庫實例。

結語

高可用是一個複雜的命題，除了應用內網 VIP 產品規避可能出現的單點故障外，還須要在服務維護方面作到嚴格規範操做，包括事前作好服務分割，過後作好服務監控等。

但僅止於此嗎？墨菲定律告訴咱們：凡是可能出錯的事有很大概率會出錯。每日三省吾身：業務架構是否足夠穩定？異常處理是否足夠完備？災備方案是否足夠充分？並據此不斷優化業務系統，祝願每一個運維工程師均可以睡個好覺！