请选择 进入手机版 | 继续访问电脑版
MSIPO技术圈 首页 IT技术 查看内容

生产环境 kafka 平滑迁移之旅

2023-07-13

背景

线上kafka集群,3台机器,3个broker;其中某台机器因为硬件故障,需要停机维修;停机意味这跑在机器上的服务会停止。所以本次做kafka迁移的目标 是机器可以停止但依赖kafka的上游和下游业务可不能停止,因为所属行业的特殊性,服务的停止,对业务的影响和伤害还蛮大的。

分析

我们知道kafka是有高可用机制的。kafka的高可用机制,是靠分区多副本来保证的 :某个topic 的 leader分区挂了,kafka会从其它follower分区里,选择一个分区做为leader分区,继续对生产者和消费者提供读写服务。所以理论上,我们是可以停止某台机器上的kafka broker服务;kafka的broker 协调节点会自动切换其它follower分区为leader分区。

大概的过程是这样的,切换前:

1688953216234.png

切换后:

1688953239836.png

网上理论分析基本是这样了,但是以个人多年实战研发经验来看,每次的平衡迁移都不会是一次简单的事。从图上可以看到,机器24上以前没有这些leader分区,只有follower分区,那么意味这24上其实是没有这么多生产者和消费者连接的,如果把leader分区转移到24上,那么24的cpu,内存,网络,硬盘IO能支持吗?这个是实际生产上要考虑的一个风险点。

测试环境验证

测试环境搭建了一套和线上一样的环境3台机器3个broker;经过模拟,3分区,2副本的情况下,某个broker宕机情况对生产者和消费者的影响

1688953307031.png

kafka leader分区的切换,看起来对生产者和消费者都比较的友好,而且还不会丢消息。前提是有follower分区

现实很残酷

线上kafka集群的 topic分区是几个副本集了?是否都如我们设想的一样都有follwer分区了?最小同步副本集min.insync.replicas 的配置是多少了?
如果都是2个或者3个副本集就好了,说明我们的topic分区都是高可用的;但是如果只有一个副本集,就意味这只有leader分区,而没有follower分区;那么topic的分区是不满足高可用的。
通过统计zk上的\brokers\topics节点;发现有100+个topic分区是3分片1副本。此时心理有一万匹XXX经过。
怎么办了?
通过查看官方文档资料:

https://kafka.apache.org/0102/documentation.html#basic_ops_automigrate

大概有两种方法

方法1: leader分区直接迁移到另外两台机器,23机器修好后,再把这些topic 迁移回来;但是
这些topic还是没有副本集,不保证这些topic的高可用

方法2: 对这些主题增加副本集,先保证其分区高可用;然后23机器broker 优雅停机;通过优雅停机的方式,把leader分区, 切换到另外两台机器上。

经过大家的沟通,我们选择了方案2,理由是:
这些1副本的topic,大多数是核心业务的topic;当时建分区的时候,可能是由于未考虑到topic 分区的高可用,只选择了1副本,可以趁这本次的迁移,把这些topic的副本给建立起来,让kafka topic具备高可用;
另外一个理由是经过初步的评估,24和25的机器还有较多的,CPU,内存,网络,IO利用率等硬件资源 支持副本的扩充

两种抉择-----leader分区切换方案选择

通过调研我们知道,leader分区切换有两种时机

  • 第一种:靠broker 优雅停机机制,把leader分区全量切换另外两台机器上

  • 第二种:手工增量的方式对leader分区和follower分区进行切换,然后broker优雅停机

这两种方案最后的结果,都能让leader分区切换到follower分区上;两种切换方法,在本质上的不同是:时机1 是全量切换;时机2 是增量切换。
对于时机1来说 优点:
操作方便简单;需要的研发耗时和资源少;
缺点也很明显: 虽然有24和25的硬件资源初步评估,但全量切换后两台机器是否真的能抗住压力了?切换后要是有问题,还能切换回来吗?全量切换后的最终结果和预期可能会存在较大差异

对于时机2 来说,优点:
增量切换能够解决一刀切的问题,并且在增量切换时,发现 24和25机器资源快扛不住时,中途可以立刻停止,整个的切换过程更加可控,即使业务有问题,能及时止损;
缺点也很明显: 由于缺乏kafka等专业领域的技术人才,公司kafka的监控和运维体系一直没有搭建起来,都是通过手工命令行的方式 来进行监控和相关命令的执行,所以这种增量切换需要编写多个脚本和多次的执行;中间执行过程的风险也有;对整个过程的监控和研发时间的投入相对时机1来说,要增加很多。

经过和架构师,团队负责人的沟通,我们采用了时机2;但是副本集的增加和leader分区切换的脚本;可通过编写代码的方式生成,避免手工编写出错的概率;另外生成的脚本由2位同事负责review;先小批量执行,观察情况;没有问题,继续执行剩余的脚本。

实施步骤

手工副本集增加步骤

主要是通过kafka的kafka-reassign-partitions.sh 工具,进行副本集的增加。

1、查看当前topic副本集情况
kafka-topics.sh --describe --zookeeper XXX:2181/data/kafka --topic test-order

1688953519127.png

这里的/data/kafka是kafka 集群元数据 存入到zk的路径;
108,109,110是brokerId。
即.23机器的 brokerId是109
.24机器的 brokerId是108
.25机器的 brokerId是110

2、新建副本集扩充脚本。新建 reassign.json,把以下内容增加到文件

{"version":1,"partitions":[{"topic":"test-order","partition":0,"replicas":[108,109]},{"topic":"test-order","partition":1,"replicas":[110,109]},{"topic":"test-order","partition":2,"replicas":[108,110]}]}

简单说明下:结合第一步和脚本的内容可看出,分区0的扩充副本,增加了108 follower分区,分区1的扩充副本增加了109 follower分区,分区2的扩充副本,增加了 110 follower分区;这里的 109 110 108是brokder Id

3、执行,副本集扩充复制集方案

kafka-reassign-partitions.sh --zookeeper XXX:2181/data/kafka --execute --reassignment-json-file reassign.json --throttle 1048576

–throttle 是分区增加时的限流,单位为B/S;整理是1M/S的速度
输出

Current partition replica assignment

{"version":1,"partitions":[{"topic":"test-order","partition":1,"replicas":[110]},{"topic":"test-order","partition":0,"replicas":[109]},{"topic":"test-order","partition":2,"replicas":[108]}]}

Save this to use as the --reassignment-json-file option during rollback
Warning: You must run Verify periodically, until the reassignment completes, to ensure the throttle is removed. You can also alter the throttle by rerunning the Execute command passing a new value.
The throttle limit was set to 1048576 B/s
Successfully started reassignment of partitions.

4、 验证是否执行成功—注意会把限流设置也删除


kafka-reassign-partitions.sh --zookeeper XXX:2181/data/kafka --verify --reassignment-json-file reassign.json

输出

Status of partition reassignment: 
Reassignment of partition [test-order,0] completed successfully
Reassignment of partition [test-order,1] completed successfully
Reassignment of partition [test-order,2] completed successfully
Throttle was removed.

5、再次查看当前topic副本集情况
kafka-topics.sh --zookeeper XXX:2181/data/kafka --topic test-order --describe

1688953658593.png

手工leader分区切换步骤

主要是利用了kafka的优先副本集选举;leader分区按照副本集的顺序进行选举;上面扩副本分区脚本时,故意把108 follower分区写在leader分区前面

1、创建 election.json 指定topic 需要调整的优化副本内容

{
    "partitions": [{
        "partition": 0,
        "topic": "test-order"
    }]
}

2、执行优化副本集选举脚本

kafka-preferred-replica-election.sh --zookeeper XXX:2181/data/kafka --path-to-json-file election.json

输出

Created preferred replica election path with {"version":1,"partitions":[{"topic":"test-order","partition":0}]}
Successfully started preferred replica election for partitions Set([test-order,0])

3、查看当前topic是否切换leader

1688953625056.png

结合副本集增加的第五步和手工leader分区切换第三步,可看到 分区0的leader 分区由109切换到了108上;所以.23上 109的leader分区变为了follower分区,而.24上的 108 follower分区变为了leader分区

4、查看产者和消费者,是否有丢消息
从生产者的日志看到,在经过自动重试后,消息能发到新的分区上;消费者也能自动进行leader分区切换,并且能继续消费消息

总结

本次kafka broker停服机器维修的本质,从应用技术的角度看,是对生产环境kafka集群 高可用的一次检阅。而这次检阅是被动的一次检阅,并不是由研发主动发起的。被动检阅,有点类似搞突击检测,但我们比突击检测好的是,还可以有足够的时间为了kafka集群具备高可用,做必要的自检工作,准备工作,验证工作;也把这么多年欠的kafka高可用的技术债给还了。

kafka集群本身是具备高可用机制的;但并不意味着你实际部署的kafka集群就具备业务高可用。生产环境kafka具备业务高可用,和使用kafka的姿势有关。这些姿势包括:
1、topic对应的分区是否有多副本
2、多副本最小同步数要求 即min.insync.replicas的配置,考虑好性能和可用性的tradeoff

你的kafka生产环境是如何做类似迁移和切换的了?欢迎留言评价。

相关阅读

手机版|MSIPO技术圈 皖ICP备19022944号-2

Copyright © 2024, msipo.com

返回顶部