当前位置: 代码迷 >> 综合 >> kafka集群扩容以及物理资源(broker)隔离
  详细解决方案

kafka集群扩容以及物理资源(broker)隔离

热度:61   发布时间:2023-11-28 00:41:29.0

需求:

要对于几个业务topic进行基于broker级别的物理资源隔离

步骤

1:Ambari2.7.x基于HDP3.x进行kafka集群扩容

用于隔离的broker是若干台新机子
在ambari界面–主机–add—kafka broker
进行kafka的broker扩容

2:登陆zk查看扩容机对应的broker id

sh zkcli.sh
ls /broker/ids
get每一个broker id的值,查询新增的brokers 主机名对应的broker id,一般都是基于之前的broker id进行追加,比如之前一共有10台broker,由1001到1010,然后扩容了4台,则新的broker id为1011到1014,与hostname一一对应(前提是你的hostname都是按顺序的噢)

3:创建新topic时进行物理隔离

在创建topic的时候加上replica-assignment参数,后面的值用逗号分隔每个partition,每个partition中冒号分隔副本所在的broker。例如通过下面的命令创建两个topic。

./kafka-topics.sh --zookeeper hostA:2181  --create --topic user1 --replica-assignment 1008:1001,1007:1002./kafka-topics.sh --zookeeper hostA:2181  --create --topic user1 --replica-assignment 1010:1003,1009:1004

注意:这里创建topic时不能添加–partitions与–replication-factor参数,因为那是自动分配,这里是通过–replica-assignment进行手动分配(隔离)

查看创建之后的user1 topic 的partition分布,partition0的leader是1008,副本在1008和1001,partition1也是和预期的一致.
user2一样
describe如下

./kafka-topics.sh --describe --zookeeper hostA:2181 --topic user1,user2
Topic:user1       PartitionCount:2        ReplicationFactor:2     Configs:Topic: user1      Partition: 0    Leader: 1008    Replicas: 1008,1001     Isr: 1008,1001Topic: user1      Partition: 1    Leader: 1007    Replicas: 1007,1002     Isr: 1007,1002Topic:user2       PartitionCount:2        ReplicationFactor:2     Configs:Topic: user2      Partition: 0    Leader: 1010    Replicas: 1010,1003     Isr: 1010,1003Topic: user2      Partition: 1    Leader: 1009    Replicas: 1009,1004     Isr: 1009,1004

4:分析

3中的结果已经表明了 用replica-assignment新创建的2个topic已经分布在不同的broker中了,副本也在完全不同的机子中,user1主题的所有分区的副本一直在1008,1001,1007,1002中,user2主题的所有分区的副本一直在1010,1003,1009,1009中。user1,user2两个主题互不影响。实现了主题在broker级别的物理隔离

其实究其topic创建方式,无非这个参数就是把原本基于固定分区副本数随机分配broker转变成固定分区副本id名称。
id名称固定了,那么分区数,副本数都不需要指定了。
所以省略了–partitions,–replication-factor参数

5:疑问

难道在后续使用的过程中,user1与user2的副本永远不会重叠而造成隔离污染吗?

6:思考

想了下kafka的重平衡机制
有三个参数如下

auto.leader.rebalance.enable=true   ## 是否leader自动重平衡
leader.imbalance.check.interval.seconds=300s    ## 不均衡扫描间隔时间
leader.imbalance.per.broker.percentage=10	## 不均衡比率阈值(不均衡比率=leader不等于preferred replicas的分区数/总分区数)

参数不好理解拿下图举个例子
在这里插入图片描述
如果满足上图,在
auto.leader.rebalance.enable=true
leader.imbalance.check.interval.seconds=300s
的条件下,进行第三个参数leader.imbalance.per.broker.percentage的判定

iteblog主题的6个分区中只有一个分区的leader不等于replica中的第一个副本id(这里第一个副本就是上文中所说的preferred replica)

比率为1/7,小于10%,所以不会触发leader的重平衡机制

但是如果这个比例大于10%了呢,就会触发重平衡机制,会在所有broker中进行重平衡算法,包括之前新添加的broker(只用于某些topic的物理资源隔离)

这样子就会导致该topic的分区们将所有的broker宠幸了个遍。破坏了物理隔离

7:优化方式

基于现有业务量,合理将leader.imbalance.per.broker.percentage参数进行增大,15%,20%,像这样,但是也不要太大

8:修正·回滚

发了博客后,我参考官方文档的参数定义,发现6中的三个参数,如果判定生效,他会进行leader的rebalance,但是并不会将隔离前的broker也拉进来一起平衡。而是会在当前topic中将leader不为preferred replica的分区leader改为preferred replica(优先副本),就像刚才那张图
在这里插入图片描述
图中1号分区的leader为3,优先副本(preferred replica)却为7。
假设那个平衡比率大于10%了,那么auto.leader.rebalance.enable=true是对leader的负载均衡,不会将扩容前的机子牵扯进来。

leader的rebalance是将leader改为preferred replica。我之前将leader的重平衡跟kafka-reassign-partition脚本搞混了。

kafka-reassign-partition脚本才会对当前topic的所有分区重新分配(如果你自己的执行计划特立独行只修改指定分区当我没说),而auto.leader.rebalance.enable=true只会对某些分区进行操作

上图中编号为3的broker作为分区1、6的leader,压力大,当不均衡比率高于阈值(leader.imbalance.per.broker.percentage)则将分区1的leader更换为7(当然图中的比率是1/7,这里是假设比率高于阈值)。这样子编号3broker就很舒服了

那么得出结论
kafka的–replica-assignment参数所生成的topic的分区副本永远不会改变,除非手动指定执行计划运行kafka-reassign-partition脚本来修改分区的副本id,所以无需修改leader.imbalance.per.broker.percentage阈值