摘要：對此，提供基于內網的高可用服務，內網通過前后三代廣播集群的設計演進，解決了復雜異構網絡下的廣播實現問題，獲得秒級高可用切換能力，并能夠很好的支持物理云。宋體下面，本文將對秒級切換的內網高可用服務進行詳細介紹。

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

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

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

高可用與我們每個人都是息息相關的，在即將到來的雙十一，更是對各個電商的業務可用性提出了更高的要求。對此，UCloud 提供基于內網 VIP 的高可用服務，內網 VIP 通過前后三代廣播集群的設計演進，解決了復雜異構 Overlay 網絡下的廣播實現問題，獲得秒級高可用切換能力，并能夠很好的支持物理云。

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

基于內網 VIP 的高可用服務

1、高可用的理念和要點

從業務角度看，當然要盡可能避免應用出現故障。但要完全不出故障是不可能的。

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

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

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

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

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

3、云計算 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 的故障切換時長通常與以下兩個步驟相關：

1、Master 發生故障后，備服務器需要選舉出新的 Master；

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

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

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

第一代：模擬廣播

圖：模擬廣播

如上圖所示，一個廣播報文直接復制 N 份，送到其他廣播域中的節點，即可完成廣播的行為。由于 OVS 支持報文的復制和傳輸，只需要在 Flow 中指定多個 Output 動作即可實現。Flow 的模式如下：

圖：模擬廣播中 Flow 模式

這種實現確實可以滿足需求，但是存在幾個明顯的缺點：

1、Flow 的更新。由于用戶的廣播域是變化的，一旦廣播域發生變化，那么所有廣播域中節點所在宿主機上的廣播 Flow 全部需要推送更新。因此如果用戶的廣播域比較大，這種更新非常消耗性能。

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

3、異構網絡的廣播需要多帶帶實現。比如物理云主機底層不是基于 OVS 的架構，那么就必須重現一遍，開發和維護成本很高。

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

第二代：廣播集群

圖：廣播集群

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

采用廣播集群，我們很好的解決了第一代廣播邏輯中存在的問題：

1、廣播域的變化問題。廣播域變化只需要通知廣播集群即可，無需全網告知。

2、廣播域的大小問題。廣播集群通過 DPDK 來進行報文的復制和轉發，理論上廣播域無上限。

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

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

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

圖：基于 GARP 嗅探的廣播集群

在第二代廣播集群已經可以很好的實現高可用服務的情況下，UCloud 為什么還要開發出第三代呢？

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

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

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

應用實例解析

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

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

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

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

圖：高可用服務構建實例

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

2、UCloud 云數據 UDB 產品高可用技術實現

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