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