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

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

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

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

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

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

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

1、高可用的理念和要點(diǎn)

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

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

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

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

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

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

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

云計(jì)算下的網(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)境下，該如何解決高可用這個(gè)問(wèn)題呢？

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

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

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

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

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

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

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

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

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

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

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

第一代：模擬廣播

圖：模擬廣播

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

圖：模擬廣播中 Flow 模式

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

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

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

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

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

第二代：廣播集群

圖：廣播集群

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

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

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

2、廣播域的大小問(wèn)題。廣播集群通過(guò) DPDK 來(lái)進(jìn)行報(bào)文的復(fù)制和轉(zhuǎn)發(fā)，理論上廣播域無(wú)上限。

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

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

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

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

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

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

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

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

應(yīng)用實(shí)例解析

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

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

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

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

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

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

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

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