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

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

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

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

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

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

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

1、高可用的理念和要點

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

第一代：模擬廣播

圖：模擬廣播

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

圖：模擬廣播中 Flow 模式

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

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

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

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

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

第二代：廣播集群

圖：廣播集群

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

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

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

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

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

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

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

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

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

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

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

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

應(yīng)用實例解析

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

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

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

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

圖：高可用服務(wù)構(gòu)建實例

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

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

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