RocketMQ無論采用Master/Slave的主從模式,還是采用Dledger的多副本模式,均能保證RocketMQ集群的高可用性,但在一些極端場景下,例如機房斷電、機房火災、地震等不可抗拒因素使得該IDC可用區(qū)的RocketMQ集群無法正常對外提供消息服務能力。因此,為了增強抗風險能力,消息隊列RocketMQ集群多活異地容災極為重要。
圖2-1 物理部署異地容災方案圖
移動云部署的RocketMQ采用的Master/Slave的主從模式,其中物理部署異地容災的方案包括以下幾部分:
(1) NameServer組件作為輕量級注冊中心,無狀態(tài),負責更新和發(fā)現(xiàn) Broker服務Namesrv之間相互沒有通信,單臺Namesrv宕機不影響其他Namesrv節(jié)點與集群的功能,兩臺Namesrv部署在不同的可用區(qū),當一個可用區(qū)故障,另外一個可用區(qū)的Namesrv依然能對外提供服務。
(2) Broker組件作為消息中轉角色,負責存儲消息,轉發(fā)消息,采用Master/Slave部署模式,在兩個可用區(qū)上交叉部署(如broker-a的Master部署在可用區(qū)1上,Slave節(jié)點部署在可用區(qū)2上,broker-b的Master部署在可用區(qū)2上,Slave節(jié)點部署在可用區(qū)1上),消息發(fā)送到Master節(jié)點后會實時同步到Slave節(jié)點,保證每個可用區(qū)保存了全量的消息。當單個可用區(qū)故障也會對外提供消息的讀寫能力。
針對物理機部署RocketMQ運維、遷移、擴縮容費時費力,操作復雜;業(yè)務增加以后,資源無法彈性,手動擴縮容實時性差;底層資源利用率不高,用戶資源隔離和流量的管控需要額外投入等問題。可以借助K8S Operator,Operator 的工作原理,實際上是利用了 Kubernetes 的自定義 API 資源(如使用CRD,CustomResourceDefinition),來描述想要部署的應用;然后在自定義控制器里,根據(jù)自定義 API 對象的變化,來完成具體的部署和運維工作,實現(xiàn)Operator主要關鍵是 CRD(自定義資源)和 Controller(控制器)的設計。
圖3-1 Operator原理圖
自研了RocketMQ Operator實現(xiàn)集群的秒級部署,擴縮容,規(guī)格變更等一些列常見的運維操作,進而解決在物理部署所帶來的難題。下圖是RocketMQ Operator設計實現(xiàn):
圖3-2 RocketMQ Operator架構圖
該方案使用三個異地可用區(qū)部署一個K8S集群,每個可用區(qū)部署一個master節(jié)點,圖中的Broker是兩主兩從高可用方案,采用交叉部署,namesrv每個可用區(qū)部署一個實例。
圖3-3 云化異地容災單集群方案
這個方案存在幾個問題:大規(guī)模單K8S集群出現(xiàn)故障時可能會對整個集群產(chǎn)生影響,且組件升級難、風險大;隨著業(yè)務增加,核心組件壓力增大,性能下降;單一集群的建設可能受限于特定的地理位置和前期規(guī)劃,缺乏靈活性。
針對上述方案的缺點,消息隊列RocketMQ云化版本多可用區(qū)的現(xiàn)階段優(yōu)化為如下方案:
圖4-1 云化異地容災多聯(lián)邦集群方案
K8S集群采用云原生Kosmos進行多個集群聯(lián)邦,不在單純依賴單個K8S集群,RocketMQ服務資源通過Kosmos CluterTree同步聯(lián)邦集群間的svc,pod等資源 ,聯(lián)邦集群間的網(wǎng)絡由Kosmos ClusterLink打通。
Kosmos是移動云的分布式云原生聯(lián)邦集群技術集合,于2023年8月開源,項目地址:https://github.com/kosmos-io/kosmos。Kosmos包含多集群網(wǎng)絡工具ClusterLink、跨集群編排工具ClusterTree等:
圖5-1 Kosmos模塊和組件
ClusterLink的作用是打通多個Kubernetes集群之間的網(wǎng)絡,在CNI上層實現(xiàn),用戶無需卸載或重啟已經(jīng)安裝的CNI插件,且不會對正在運行的pod產(chǎn)生影響。ClusterLink的主要功能如下:
? 提供跨集群PodIP、ServiceIP互訪能力 ? 提供P2P、Gateway多種網(wǎng)絡模式 ? 支持全局IP分配 ? 支持IPv4、IPv6雙棧
ClusterTree的作用是實現(xiàn)Kubernetes的樹形擴展和應用的跨集群編排。ClusterTree本質是一組控制器,用戶可以像使用單集群那樣直接與控制面kube-apiserver進行交互,不需要額外的代碼改造。目前,ClusterTree包含的主要功能如下:
?提供創(chuàng)建跨集群應用能力 ?兼容k8s api,用戶零改造 ?支持有狀態(tài)應用 ?支持k8s-native(需要訪問kube-apiserver的)應用
除此之外,Kosmos還提供一些輔助工具,其中,kosmos-operator簡化了Kosmos部署。Kosmosctl是一款命令行工具,為用戶提供網(wǎng)絡連通性測試、集群納管、Kosmos部署安裝等功能。
ClusterLink基于linux隧道技術打通跨集群網(wǎng)絡,隧道類型是可配置的,例如:VxLAN或IPSec。ClusterLink包含Network-Manager、Agent等多個組件,如下圖所示淺藍色部分。各個組件相互協(xié)作完成隧道、路由表、fdb等網(wǎng)絡配置。
圖 6-1 ClusterLink架構
其工作流程如下:
圖 6-2 ClusterLink網(wǎng)絡模式
目前,ClusterLink包含兩種網(wǎng)絡模式:Gateway和P2P。在Gateway模式中,數(shù)據(jù)包由左側pod發(fā)出后,先經(jīng)由集群內(nèi)隧道vx-local到達該集群gateway節(jié)點。然后再走跨集群隧道到達對端集群。數(shù)據(jù)包到達對端集群后,交由CNI處理,走單集群網(wǎng)絡到達目標pod。該模式有利有弊,其優(yōu)勢在于每個集群只需要1個節(jié)點(考慮HA時需要2個)提供對外訪問即可,適用于跨云混合云場景。缺點是因為網(wǎng)絡路徑較長,有一定的性能損耗。針對此問題,ClusterLink提供P2P模式,對網(wǎng)絡性能要求較高的場景可以使用此模式。在該模式下,數(shù)據(jù)包的控制粒度更細,會直接發(fā)往對端pod所在節(jié)點。此外,P2P和Gateway兩種模式支持混合使用。
ClusterTree實現(xiàn)了Kubernetes的樹形擴展和應用的跨集群編排,用戶可以像使用單集群那樣訪問root kube-apiserver。Leaf集群作為節(jié)點添加在root集群中,用戶可以使用k8s原生的方式控制pod分布,例如:labelSelector、親和/反親和、污點和容忍、拓撲分布約束等。
圖 7-1 ClusterTree 架構
ClusterTree其本質是一組控制器,各個控制器的作用如下:
當出現(xiàn)AZ級故障,或者AZ之間網(wǎng)絡中斷,確保用戶正常訪問RocketMQ集群實例是非常重要的。如上圖所示,為了應對A處網(wǎng)絡斷開或者控制面故障,ClusterTree實現(xiàn)了service和endpoint資源的同步,讓用戶訪問流量直接從子集群走,解耦了管理和業(yè)務,也縮短了網(wǎng)絡路徑。RocketMQ的nameserver pod是跨集群分布,當B處網(wǎng)絡斷開或者某個AZ故障,會導致用戶有50%概率訪問失敗的nsv pod。針對此問題,ClusterTree的eps-probe插件會周期對跨集群ep進行探測,并移除失效endpoint。
圖 7-2 RocketMQ跨AZ高可用
ClusterTree能管理多少節(jié)點和pod?ClusterLink較單集群網(wǎng)絡的性能如何?這些都是用戶非常關注的問題,對此我們也做了相應的測試。
圖 8-1 集群負載測試-測試方法
如圖所示,我們首先通過kwok創(chuàng)建了20個大規(guī)模集群,每個集群包含5000個節(jié)點,我們將這些集群使用Kosmos進行納管。接下來,使用clusterloader2 連接控制面kube-apiserver進行集群負載測試,其關鍵測試參數(shù)如圖所示。
圖 8-2 集群負載測試-測試結果
使用kosmos管理k8s集群聯(lián)邦,在 100,000 節(jié)點和 200,000 pod場景下,達到官方SLOs標準,并且該規(guī)模并未達到kosmos上限。
圖 8-3 網(wǎng)絡性能測試-測試方法
圖片
本文鏈接:http://www.www897cc.com/showinfo-26-71458-0.htmlRocketMQ基于Kosmos實現(xiàn)AZ級高可用,你學會了嗎?
聲明:本網(wǎng)頁內(nèi)容旨在傳播知識,若有侵權等問題請及時與本網(wǎng)聯(lián)系,我們將在第一時間刪除處理。郵件:2376512515@qq.com