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

快節(jié)奏的生活，任何的業(yè)務異常 / 中斷都是不能容忍的。

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

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

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

下面，本文將對 UCloud 秒級切換的內(nèi)網(wǎng)高可用服務進行詳細介紹。

基于內(nèi)網(wǎng) VIP 的高可用服務

1、高可用的理念和要點

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

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

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

2、傳統(tǒng)網(wǎng)絡的高可用方案

在傳統(tǒng)網(wǎng)絡中，Keepalived + 虛擬 IP 是一個經(jīng)典的高可用解決方案。

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

3、云計算 Overlay 網(wǎng)絡下的高可用

云計算下的網(wǎng)絡架構發(fā)生了巨大變化，傳統(tǒng)的網(wǎng)絡架構已經(jīng)更新為 Overlay 網(wǎng)絡，并出現(xiàn)了各類復雜的異構網(wǎng)絡。那么在新的網(wǎng)絡環(huán)境下，該如何解決高可用這個問題呢？

首先我們看一下云計算網(wǎng)絡的基本原理：

圖：云計算網(wǎng)絡的實現(xiàn)

如上圖，云資源都橋接在 OVS 的網(wǎng)橋上，同時業(yè)務網(wǎng)卡也橋接在 OVS 的網(wǎng)橋上，Controller 為 UCloud 基于開源框架 Ryu 自研實現(xiàn)。Controller 通過與后臺 Manager 的交互，拉取 ACL、路由表、VPC 聯(lián)通、隔離等各類信息，并通過 OVS Message 將 Flow 固化在 OVS 的網(wǎng)橋上，達到 Flow 管理的目的，實現(xiàn) ACL 的聯(lián)通與阻斷、三層轉發(fā)的功能，進而完成 VPC 聯(lián)通及租戶隔離的能力。上層的實際業(yè)務報文，通過 GRE 封裝，對下層網(wǎng)絡保證透明。

鑒于用戶在云計算網(wǎng)絡中實現(xiàn)高可用的復雜性，UCloud 設計了內(nèi)網(wǎng) VIP 產(chǎn)品，為云平臺上的云主機、物理云主機提供服務。作為用戶自定義高可用服務的可漂移內(nèi)網(wǎng)入口，從發(fā)現(xiàn)故障到自動完成故障切換，無需額外的 API 調(diào)用和機器內(nèi)部配置，即可完成秒級切換。

圖：內(nèi)網(wǎng) VIP 控制臺操作界面

內(nèi)網(wǎng) VIP 如何實現(xiàn)故障轉移的秒級切換？

內(nèi)網(wǎng) VIP 的故障切換時長通常與以下兩個步驟相關：

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

2、需要在廣播域內(nèi)告知其他節(jié)點，該 IP 的位置發(fā)生了變化。

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

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

第一代：模擬廣播

圖：模擬廣播

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

圖：模擬廣播中 Flow 模式

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

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

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

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

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

第二代：廣播集群

圖：廣播集群

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

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

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

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

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

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

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

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

在第二代廣播集群已經(jīng)可以很好的實現(xiàn)高可用服務的情況下，UCloud 為什么還要開發(fā)出第三代呢？

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

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

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

應用實例解析

1、電商支付系統(tǒng)高可用實踐

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

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

為了實現(xiàn)高可用，UCloud 基于 Keepalived + 內(nèi)網(wǎng) VIP 產(chǎn)品為該電商線上支付系統(tǒng)快速構建了高可靠服務，從而避免自身單點故障，大大提高系統(tǒng)的可用性。

圖：高可用服務構建實例

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

2、UCloud 云數(shù)據(jù) UDB 產(chǎn)品高可用技術實現(xiàn)

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