企业kafka集群升级

简介: 发现公司生产环境集群版本仍然停留在1.x,在社区已推出最新的稳定版本2.3,版本相差那么大

一、前言
主要分享经历的生产环境多版本kafka集群版本升级统一过程中的经验教训和踩过的坑
二、我的kafka集群是否有必要升级?
做任何一件事之前,首先需要考虑和明确的,不是该怎么做,而是是否有必要做。版本升级这样的“大动作”更是如此。社区发布了新版本,我们是否要跟进,需要根据集群当前运行状况、是否需要新特性这两大方面,结合实际情况来判断
image.png
公司生产环境集群情况,属于上图中第三象限:
触发低版本bug的频率较高,严重影响了集群的稳定性;
由于历史原因,多个集群的版本不一致,用户使用的便捷性受到制约;
由于多版本并存,管理员必须关注各版本的变更项,增加了线上问题排查的耗时和复杂度。

虽然讨论的是集群版本升级过程,但依旧要郑重提醒大家:升级有风险,决定需谨慎。版本升级的目的,是为了使集群运行更稳定功能更强大,如果集群当前运行良好而且在可预见的短期内不需要新特性,那么完全不必要升级版本。
三、集群升级之“道”:方案设计
决定需要进行集群升级后,接下来就是方案制定环节。本节将依照“对用户影响尽量小,操作尽量安全高效”的原则,从是否可以停服升级、如何选择版本、怎样分阶段分批次操作等层面展开,和大家一起讨论升级方案制定过程中的一些关键点。
**3.1 停服升级 or 滚动升级
**
首先,如果可以接受停服,优先选择停服升级。这样可以规避滚动升级过程中必须经过的高风险阶段——新旧版本之间的切换和并存。

停服升级的操作过程简单明了:
image.png
如果不可接受较长时间停服,但有备份集群或者有足够的机器资源可以用来搭建备份集群,可以通过主备切换的方式实现对主集群的停服升级:
1、客户端切换broker/zookeeper连接到备份集群;
2、对主集群进行停服升级;
3、(如果需要) 备份集群数据同步至新版本的主集群;
4、客户端连接切回主集群,主集群恢复对外服务。

如果既需要保持服务不中断,又无法提供备份集群,那么滚动升级是唯一的选项,将必须面对新旧版本切换和共存的问题以及由此带来的潜在风险。作者就是从滚动升级这条路走过来的。

官网和Cloudera、Confluent等主流kafka服务提供商都给出了各自版本的滚动升级流程,这是我们制定滚动升级方案的最主要依据。
image.png
3.2 社区版本 or 服务商封装版本

由于历史原因,运维的诸多集群中既有社区版本,也存在不少Cloudera版本(即CDK),这两种版本在日常工作中的使用体验对比详见下表。大家可以结合各自的使用场景进行选择。
image.png
深感CDK版本的问题排查和调优不便,而且已自研可视化管理平台,因此选择了全部升级为社区版本
3.3 直接升级到目标版本 or 升级到中间版本过渡

除依赖zookeeper的0.9.0.0版本客户端由于Bug而无法被0.10.0.x版本的集群兼容以外,Apache kafka官方文档明确给出了其它各低版本向任一高版本直接升级的操作流程。作者操作完成了CDK和社区共计0.8.2.0~2.1.0其间6个不同版本向目标版本2.2.1的直接升级,得益于kafka优秀的版本兼容性。
3.4 集群升级五阶段
作为C/S架构,Kafka集群的完整升级过程,包括集群(broker)侧和客户端(client)侧两方面共五部分。
image.png
在决定上述各部分执行次序前,需要详细了解kafka的版本兼容特性:
0.10.2.0版本之前,broker版本单向向下兼容client版本:broker可以兼容等于或低于其版本的client,反之不兼容;
0.10.2.0版本及后续版本,broker和client版本双向兼容:broker可以兼容0.8.x及以上版本的client,client可以兼容0.10.0及以上版本的broker。
image.png
0.10.2.0及以后broker和client的版本双向兼容,是通过新增的ApiVersions接口进行协调的:client在读写数据前,先向broker发送该类型请求,以获取当前集群所能支持的所有版本。
image.png
为保证客户端读写不受影响,结合上述版本兼容特性,可以得出这五部分的执行次序应该如下:
第一阶段:[broker侧] 代码升级。该阶段只升级broker代码,复制协议和消息格式版本配置保持和低版本一致。
image.png
第二阶段:[broker侧] broker间通信协议/复制协议版本升级。该阶段对配置项 inter.broker.protocol.version 进行升级,消息格式版本配置保持和低版本一致。
(说明:如果此时升级消息格式版本,会导致当前低版本Consumer无法识别高版本格式的消息!)
image.png
第三阶段:[client侧] Consumer版本升级。升级后的高版本Consumer可以兼容集群当前的低版本格式的消息。
image.png
第四阶段:[broker侧] 消息格式版本升级。Consumer版本升级完成后,才可以升级broker消息格式版本,即配置项 log.message.format.version。
image.png
该阶段完成后:
至此,broker侧的升级过程全部完成;
Consumer和集群交互的协议将使用新版本。

第五阶段:[client侧] Producer版本升级。Producer版本在最后进行升级。
image.png
该阶段完成后:
升级后的Producer和集群交互的协议将直接使用新版本;
至此,整个集群包括broker和client均已升级完毕。

3.5 分批次操作

集群升级操作是对集群的重大变更,如果生产环境有不止一个集群,为保证升级期间的服务稳定性,建议根据集群承载业务的重要程度和流量,由小到大循序渐进分批次操作。

所操作的集群批次划分如下,供参考。
image.png
四、集群升级之“术”:执行流程

综合考虑上一节提到的各种因素确定升级方案后,即可将方案细化为可执行的操作步骤实施执行。

作者所在团队制定的执行流程概要如下图所示。
image.png
关键环节集中在:
测试:要对升级操作过程中可能遇到的各种场景进行充分测试,以尽力降低出现意外的概率;
升级流程演练:在测试环境对即将进行升级的集群操作进行全流程演练,主要目的有两点:
以文档的形式固化操作步骤 (包括每一步的执行人、执行的具体操作命令、执行耗时、检查点,和可能的回滚方案),供线上操作使用;
演练执行并确认回滚方案的有效性。
线上升级操作:之前各环节都充分执行完成后,按照既定步骤执行即可。

后续文章将依次对各阶段的执行流程,以及操作过程中遇到的问题,进行详细解析。
五、总结

是否有必要升级集群:取决于集群当前运行是否稳定和对新特性的需求是否迫切。
升级方案设计关键点:
优先选择停服升级的方式,可以规避新旧版本切换和共存过程中的潜在风险;
社区版本和服务商封装版本各有千秋,可根据实际情况进行选择;
kafka支持broker从几乎所有的低版本向各个高版本的直接升级,无需中间版本过渡;
集群的完整升级过程包括broker和client两方面共五部分,需严格按照先后次序分五个阶段依次进行;
建议根据业务和流量对所有集群进行循序渐进分批次升级。
执行流程关键点:要对升级操作进行全流程演练,以固化操作步骤并验证回滚方案的有效性。

目录
打赏
0
0
0
0
2219
分享
相关文章
构建高可用性Apache Kafka集群:从理论到实践
【10月更文挑战第24天】随着大数据时代的到来,数据传输与处理的需求日益增长。Apache Kafka作为一个高性能的消息队列服务,因其出色的吞吐量、可扩展性和容错能力而受到广泛欢迎。然而,在构建大规模生产环境下的Kafka集群时,保证其高可用性是至关重要的。本文将从个人实践经验出发,详细介绍如何构建一个高可用性的Kafka集群,包括集群规划、节点配置以及故障恢复机制等方面。
108 4
大数据-79 Kafka 集群模式 集群监控方案 JavaAPI获取集群指标 可视化监控集群方案: jconsole、Kafka Eagle
大数据-79 Kafka 集群模式 集群监控方案 JavaAPI获取集群指标 可视化监控集群方案: jconsole、Kafka Eagle
129 2
【手把手教你Linux环境下快速搭建Kafka集群】内含脚本分发教程,实现一键部署多个Kafka节点
本文介绍了Kafka集群的搭建过程,涵盖从虚拟机安装到集群测试的详细步骤。首先规划了集群架构,包括三台Kafka Broker节点,并说明了分布式环境下的服务进程配置。接着,通过VMware导入模板机并克隆出三台虚拟机(kafka-broker1、kafka-broker2、kafka-broker3),分别设置IP地址和主机名。随后,依次安装JDK、ZooKeeper和Kafka,并配置相应的环境变量与启动脚本,确保各组件能正常运行。最后,通过编写启停脚本简化集群的操作流程,并对集群进行测试,验证其功能完整性。整个过程强调了自动化脚本的应用,提高了部署效率。
【手把手教你Linux环境下快速搭建Kafka集群】内含脚本分发教程,实现一键部署多个Kafka节点
2024最全Kafka集群方案汇总
Apache Kafka 是一个高吞吐量、可扩展、可靠的分布式消息系统,广泛应用于数据驱动的应用场景。Kafka 支持集群架构,具备高可用性和容错性。其核心组件包括 Broker(服务器实例)、Topic(消息分类)、Partition(有序消息序列)、Producer(消息发布者)和 Consumer(消息消费者)。每个分区有 Leader 和 Follower,确保数据冗余和高可用。Kafka 2.8+ 引入了不依赖 Zookeeper 的 KRaft 协议,进一步简化了集群管理。常见的集群部署方案包括单节点和多节点集群,后者适用于生产环境以确保高可用性。
44 0
云消息队列 Kafka 版全面升级:经济、弹性、稳定,成本比自建最多降低 82%
本文介绍了阿里云云消息队列 Kafka 版的全面升级,强调了其在经济性、稳定性和弹性方面的显著提升。同时,与 Apache Kafka 相比,云消息队列 Kafka 版通过节省 66% 的资源,实现了客户使用成本比自建最多降低 82%。
大数据-78 Kafka 集群模式 集群的应用场景与Kafka集群的搭建 三台云服务器
大数据-78 Kafka 集群模式 集群的应用场景与Kafka集群的搭建 三台云服务器
120 6
【Kafka揭秘】Leader选举大揭秘!如何打造一个不丢失消息的强大Kafka集群?
【8月更文挑战第24天】Apache Kafka是一款高性能分布式消息系统,利用分区机制支持数据并行处理。每个分区含一个Leader处理所有读写请求,并可有多个副本确保数据安全与容错。关键的Leader选举机制保障了系统的高可用性和数据一致性。选举发生于分区创建、Leader故障或被手动移除时。Kafka提供多种选举策略:内嵌机制自动选择最新数据副本为新Leader;Unclean选举快速恢复服务但可能丢失数据;Delayed Unclean选举则避免短暂故障下的Unclean选举;Preferred选举允许基于性能或地理位置偏好指定特定副本为首选Leader。
109 5
联通实时计算平台问题之监控Kafka集群的断传和积压情况要如何操作
联通实时计算平台问题之监控Kafka集群的断传和积压情况要如何操作
【Kafka节点存活大揭秘】如何让Kafka集群时刻保持“心跳”?探索Broker、Producer和Consumer的生死关头!
【8月更文挑战第24天】在分布式系统如Apache Kafka中,确保节点的健康运行至关重要。Kafka通过Broker、Producer及Consumer间的交互实现这一目标。文章介绍Kafka如何监测节点活性,包括心跳机制、会话超时与故障转移策略。示例Java代码展示了Producer如何通过定期发送心跳维持与Broker的连接。合理配置这些机制能有效保障Kafka集群的稳定与高效运行。
109 2

热门文章

最新文章

AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等