探索華爲雲CCE敏捷版金融級高可用方案實踐案例

本文分享自華爲雲社區《華爲雲CCE敏捷版金融級高可用方案實踐》,作者: 雲容器大未來。

一、背景

1.1. CCE 敏捷版介紹

雲原生技術有利於各組織在公有云、私有云和混合雲等新型動態環境中,構建和運行可彈性擴展的應用。雲原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式 API。這些技術能夠構建容錯性好、易於管理和便於觀察的松耦合系統。結合可靠的自動化手段,雲原生技術使工程師能夠輕鬆地對系統作出頻繁和可預測的重大變更。

從實踐角度講,CCE 敏捷版是在大規模高可靠的雲服務和大量高性能金融級應用的驅動下產生的新一代軟件開發、集成、管理和運維的雲原生管理平臺。CCE 敏捷版,爲企業提供數字化新基建的雲原生技術平臺,幫助企業實現業務敏捷上線、業務戰略快速落地。作爲容器混合雲在線下的延伸,CCE 敏捷版提供了高性能可擴展的容器服務,快速構建高可靠的容器集羣,兼容 Kubernetes 及 Docker 容器生態。幫助用戶輕鬆創建和管理多樣化的容器工作負載,並提供容器故障自愈,監控日誌採集,自動彈性擴容等高效運維能力。

1.2. 爲什麼要兩地三中心

隨着互聯網技術的發展,雲平臺建設已經成爲企業信息化建設的重要組成部分。在實際的雲平臺建設過程中,爲了保證系統的高可用性和可靠性,需要考慮到多個層次上的冗餘。一般通過多副本可以實現應用層面的冗餘,在地域級別的故障場景下,兩地三中心的高可用架構是一種常見的設計方案。

通過將系統部署在兩個地理位置,三個不同的數據中心,從而實現對系統的高可用性和容錯性的保障。在實際的應用場景中,兩地三中心的高可用架構主要適用於對系統可用性要求非常高的場景,例如金融、電信、醫療等行業。利用兩地三中心,可以有效地避免單點故障的風險,並在系統出現故障時快速切換到備中心,從而保證系統的持續穩定運行。

1.3. 適用場景

兩地三數據中心整體統一規劃,採用華爲 CCE 敏捷版的產品構建微服務應用的兩地多中心的容災方案,從單中心開始分步驟實施建設。

二、方案說明

2.1. 整體容災方案

本方案描述兩地三中心的方案支持客戶的業務高可用;

1.png

方案說明:

  • 建立兩地三中心的容災架構,提供多集羣部署能力,以上圖爲例,將 Region1 作爲主區域提供同城雙活,Region2 作爲災備站點。每個中心各自一套獨立集羣,對於核心業務可提供單中心雙集羣進一步提升高可用性,避免因爲單集羣故障導致業務受損。業務根據實際情況分配。

  • 減小集羣規模,控制故障半徑:將大集羣拆解到多個小集羣中,單集羣規模建議不超過 200 節點。災備環境因爲常態無真實業務,出於成本考慮可適當減小規模,但需要在災備流量切換前完成數據檢查和規模擴容。若無法保證規模擴容,建議按照生產環境高峯流量進行環境準備。

  • 每個數據中心的流量通過跨雲負載均衡走到雲平臺 SLB,再進一步將流量導入到集羣中的業務網關。業務網關根據應用的註冊情況將流量分配到後端應用上。正常情況下 DNS 將流量全部導向主區域站點,在災備時將切換到容災中心。

  • 集羣中的網關將流量導向後端時,可根據應用的分佈和註冊情況,進行流量分配,可分階段實現集羣內流量分發,以及跨集羣的流量分發(需微服務框架改造)。通過業務層面的健康檢查,流量探測,可實現應用路由的全局管理分發,避免單一集羣、單一 AZ、單一數據中心故障,引發大量流量異常。

  • 應用狀態信息保存到 DB 中,應用本身無狀態化,便於彈性、遷移等容災行爲處理。根據業務框架數據庫可以採用同城雙中心的統一單邊讀寫機制,多中心的應用使用同一份數據庫,保證一致性。同時數據庫提供跨中心的實時同步到備節點,當同城雙中心間發生容災切換時,備升主,應用也切換到新的主數據庫上。核心業務數據支持異地複製,確保主站點區域級別故障時提供異地的容災拉起手段。

  • 後續可針對應用業務進行單元化改造,降低單應用的故障風險面。應用單元可通過雙集羣等多主架構實現容災高可用,並配套數據庫的同步與容災能力實現單元粒度的容災切換能力。

2.2. 高可用關鍵技術

從容災分層的角度,可以從接入層、應用層、數據層和基礎設施層,分別進行高可用的設計分析。

2.png

接入層流量高可用

核心要點:兩層容災,覆蓋區域級別、單中心級別故障的流量切換。

關鍵技術一:利用 DNS 實現路由高可用解析策略管理

1、通過 DNS A 記錄權重進行輪詢分流

2、支持健康檢查,故障自動切換。某一地區 IP 故障,自動切換到其他可用 IP

關鍵技術二:單區域負載均衡權重管理

1、負載均衡同城跨中心調度流量

2、支持健康檢查,根據後端負載實例情況,動態調整集羣流量權重

如下圖所示,當檢測到故障時,公網流量切換到災備。

3.png

應用層容災高可靠

核心要點,多集羣多副本部署,應用路由網關實現單應用、單中心故障的業務無損,主要針對同城雙活。

關鍵技術一:多集羣多副本部署

通過多集羣部署,避免單集羣故障影響。

關鍵技術二:應用路由管理

1、網關基於註冊信息進行流量轉發。

2、Ingress、nodeport 流量基於 k8s 的 service 註冊進行流量轉發。

3、業務僅在單集羣內訪問,減少跨集羣依賴。

4.png

關鍵技術三:跨集羣路由(可逐步演進)

通過註冊中心雙寫等機制,實現應用路由在兩邊集羣均完整具備,當某一集羣的應用全故障時可將流量導向其他的健康集羣業務。在應用間互訪前先讀取路由,基於就近訪問優先等策略進行業務間的調用轉發。

1、註冊中心路由註冊時,將自動實現集羣內的短路徑以及跨集羣的長路徑的註冊和區分。

2、集羣內調用,時延最低;集羣間調用,1)通過網關對外提供服務類,跨集羣需通過業務網關繞行,時延有所增加,2)對於 ingress、nodeport 等 k8s 對外提供服務類, SLB 需提供健康檢查機制,將流量導到對端健康的集羣上。

5.png

數據庫容災高可靠

核心要點:數據庫多中心部署,跨中心同步。

提供給單元化切片能力。

6.png

關鍵技術一:跨 AZ 高可用支持秒級切換

支持跨 AZ 部署,生產站點部署主庫,同城站點部署備庫,主備庫切換爲秒級

關鍵技術二:數據同步

支持半同步和異步兩種。關注數據安全,建議選擇半同步,關注性能,建議選擇異步。

關鍵技術三:讀寫分離,支持多個只讀實例

支持多個只讀實例,分擔讀流量;提升查詢業務吞吐能力。

關鍵技術四:提供對外訪問的統一地址,主備切換對應用無感知

跨AZ部署的高可用實例對外採用統一的地址訪問,當站點故障時,訪問地址不發生變化。當主實例所在區域發生突發生自然災害等狀況,主節點(Master)和備節點(Slave)均無法連接時,可將異地災備實例切換爲主實例,在應用端修改數據庫鏈接地址後,即可快速恢復應用的業務訪問。

基礎設施容災高可靠

基礎設施主要包括 IaaS、容器、存儲、網絡等基礎資源。

對於容器而言,可以在兩邊的數據中心各自部署一套完整的容器平臺,容器平臺不跨數據中心,可以避免容器管理等業務因爲跨中心的專線網絡故障導致的管理受損情況。對於 IaaS、存儲等基礎設施,特別是存儲持久化數據,則需要提供跨機房、數據中心的容災能力。

關鍵技術一:數據雙活高可靠

對於在機房 A 運行的應用,所有數據持久化後都會立刻寫入機房 B 的 NAS 存儲。當機房 A 存儲故障時,機房 B 存儲有全量最新數據,且立即可用;業務即可快速由機房 B 接管,性能快速恢復。

7.png

關鍵技術二:IaaS 跨 AZ 高可用

IaaS 建設規劃,需要保證數據中心內的多 AZ 建設,在多 AZ 上提供虛機、網絡的高可用能力。同時,IaaS 需要評估是否需要在同城跨數據中心建設,並提供相應的技術要求。

應用單元化改造

核心要點:通過單元化改造,每個單元承擔全業務,從用戶維度進行切分,單元包含應用+數據。

優點:故障不出單元,故障半徑小;提供極致的性能和線性擴展。可通過增加單元進行水平擴展。

依賴:要求業務模型固定;應用和數據庫耦合度高,需要有合適的業務分片構建全局路由,跨單元通過 API 訪問,需要應用側聚合;成本高,應用、數據需要一體化規劃設計。

8.png

統一運維

核心要點:分層運維,提供應用的統一運維管理視圖。

關鍵技術一:統一登錄 SSO

對於 IaaS、容器、存儲、數據庫等多管理平臺,需要與企業內部 SSO 系統打通,統一登錄,統一管理,避免出現不同地域的平臺登錄不同的情況。

關鍵技術二:日誌監控統一管理

多集羣的應用日誌、監控、鏈路信息,統一收集到運維服務平臺,提供監控大盤、全鏈路分析、運營報表等能力。

9.png

三、高可用容災系統建設

基於整體容災方案,在基礎設施建設就緒後,可以在各數據中心,進行 CCE 敏捷版的規劃建設。

3.1. 集羣容災規劃建設

採用多集羣模式,一個數據中心一套獨立的管控面,避免跨數據中心的依賴。在每個數據中心,存在一個管控集羣,和基於業務情況規劃的業務集羣。

管控集羣

管控集羣主要功能

承擔一個數據中心內部多個業務集羣管理,主要包含集羣管理、應用管理、運維管理等作用。

管控集羣部署位置

運管區。管控集羣與業務集羣所有節點進行網絡打通(22, 5443端口等)

管控集羣運行服務

  • 管控集羣本質是一個K8S集羣,在K8S集羣上運行容器化管控服務

  • 管控服務主要包含:管理控制檯、租戶管理、鑑權服務、API網關、監控管理服務、集羣管理服務、平臺數據庫、平臺鏡像倉庫等

管控集羣部署關注點

  • 滿足K8S集羣本身組件的分佈式高可用需求,3RU部署

  • 滿足管控服務的分佈式高可用需求,3RU部署

管控集羣節點規劃

管理節點

  • 虛擬機/物理機*3;分佈在3RU中

  • 部署服務:K8S管理組件(apiserver,controller,scheduler,etcd);平臺數據庫

計算節點(無狀態服務)

  • 虛擬機/物理機*2;分佈在2RU中

  • 部署服務:管理控制檯、租戶管理、API網關

  • 服務特點:無狀態,支持彈性擴縮容

管控集羣支持規模

支持1000+個節點規模的管理,大規模時建議獨立出業務集羣管理。節點數增加後,需要同步對有狀態服務節點進行擴容(增加物理機個數),需要做數據遷移。

業務集羣

業務集羣主要功能

作爲容器化應用的運行環境

業務集羣部署位置

  • 按照網絡分區進行規劃

  • 每個分區集羣根據業務屬性劃分,例如管理類應用集羣和對客類應用集羣

業務集羣運行服務

  • 無狀態服務:數據無持久化要求,多副本機制。例如Java應用、TongWeb、Nginx等

業務集羣部署關注點

  • 滿足K8S集羣本身組件的分佈式高可用需求,3RU部署

  • 上層應用根據K8S集羣部署2RU特性進行高可用保障

業務集羣節點規劃

管理節點

  • 3臺節點;分佈在3RU中;部署K8S管理組件(apiserver,controller,scheduler,etcd)

計算節點

  • 2*N臺節點;分佈在2RU中;部署應用服務

業務集羣形態

虛擬機集羣:適用於通用應用場景,目前運行在虛擬機上的應用均可以使用虛擬機集羣

物理機集羣:適用於高性能要求或者專用集羣要求場景,例如ES、數據庫等

業務集羣規模規劃

支持1000+個節點規模的管理,從控制爆炸半徑的角度看,建議在規模控制在200節點以內。

3.2. 高可用建設演進策略

技術中臺建設的高可用的基礎設施建設可以分三個階段進行分批建設和演進:第一階段進行同城雙活階段的高可用,第二階段演進成三地雙活異地災備高可用體系。

在高可用架構的演進過程中,在層次上需要從下往上逐步演進,即首先完成基礎設施,即第二數據中心的機房、IaaS 基礎建設;然後完成數據庫、中間件的雙中心高可用演進;再建設新集羣,將業務發佈到新的數據中心集羣上;在應用發佈到網關層並驗證通過後,即達到雙中心多活的效果。在雙中心向異地容災演進時,也是類似的流程。

9.jpg

 

點擊關注,第一時間瞭解華爲雲新鮮技術~

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章