快節奏的生活，任何的業務異常 / 中斷都是不能容忍的。
在無人化超市選購完成進行結賬時，結賬頁面突然卡住，無法完成購買操作。這時該選擇放棄手中的商品 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 數據庫服務的穩定可靠。
圖：基於內網 VIP 的 UCloud 高可用 DB 技術實現
在 UDB 高可用實現的過程中，由於採用單一內網 VIP 接入，因此可以完成應用層的無縫切換，整個過程中無需用戶進行任何人工干預和配置修改。依託內網 VIP，UDB 產品爲用戶提供了高可用的數據庫服務，目前該產品已經服務於上萬家企業並提供了數萬份數據庫實例。
結語
高可用是一個複雜的命題，除了應用內網 VIP 產品規避可能出現的單點故障外，還需要在服務維護方面做到嚴格規範操作，包括事前做好服務分割，事後做好服務監控等。
但僅止於此嗎？墨菲定律告訴我們：凡是可能出錯的事有很大機率會出錯。每日三省吾身：業務架構是否足夠穩定？異常處理是否足夠完備？災備方案是否足夠充分？並據此不斷優化業務系統，祝願每個運維工程師都可以睡個好覺！