mirror of
https://github.com/didi/KnowStreaming.git
synced 2026-01-07 15:12:14 +08:00
130 lines
5.6 KiB
Markdown
130 lines
5.6 KiB
Markdown
#### 1. 功能范围
|
||
|
||
功能包含增加节点、集群均衡、范围均衡、Topic黑名单。Topic迁移、节点下线本次不实现，设计的时候需考虑进去避免后期无法实现或者成本过高。容量红线触发自动均衡本期不考虑，均衡算法优先实现Topic leader、副本、磁盘均衡，后续逐步实现其他维度。
|
||
|
||
#### 2. 指标采集
|
||
|
||
通过KS3采集指标写入ES，需要计算到每个分区的指标，只要Leader分区的指标，副本指标根据Leader分区指标进行推导
|
||
|
||
**采集周期：** 每分钟
|
||
|
||
**相关指标：** 共计4个，分区磁盘使用、分区流入流量、分区流出流量、分区CPU使用率
|
||
|
||
1. 分区Log磁盘使用大小，关联指标kafka.log:type=Log,name=Size,topic=yy_topic_b,partition=0
|
||
|
||
2. 分区流入流量，根据当前节点的Leader数计算出每个分区平均流入流量，关连指标kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec,topic=yy_topic_b Attributes=OneMinuteRate
|
||
|
||
3. 分区流出流量，根据当前节点的Leader数计算出每个分区平均流量，关连指标kafka.server:type=BrokerTopicMetrics,name=BytesOutPerSec,topic=yy_topic_b Attributes=OneMinuteRate
|
||
|
||
4. 分区CPU使用率，当前节点CPU使用率 \* PartitonBytesIn / (BrokerBytesIn \* 3 + BrokerReplicationBytesIn \*1)，副本CPU使用率为Leader使用率 / 3，关连指标java.lang:type=OperatingSystem Attributes=ProcessCpuLoad（本期不考虑）
|
||
|
||
**计算方法：** 计算方法有两种，一种是由分区驱动，首先生产1分钟整个集群的指标快照，然后根据Topic元数据分别查询每个Topic分区的Leader所在节点，根据当前节点的Leader数量平均计算当前分区的指标。
|
||
|
||
另一种是在采集时进行计算由指标驱动，指标由多个采集节点进行采集，每个采集节点需要维护对应Topic的元数据，元数据有效期为1分钟，采集到Topic指标之后根据当前节点Leader分布情况分别计算出各个分区的平均指标，比如Topic A的BytesIn指标为10240，当前节点分布的Leader分区有0、5，那么0分区和5分区的指标值分别为5120（可由标准采集扩展processor进行计算处理）
|
||
|
||
**放弃方案：**
|
||
|
||
由采集模块采集标准指标写入ES，然后再由样本模块定期查询ES进行分区维度指标计算，需要额外协调或者降低实时性，否则很难确定是否采集完成
|
||
|
||
**存储格式：**
|
||
|
||
| **Cluster** | **IP** | **Broker** **ID** | **Topic** | **Partition** | **NW** **IN** | **NW** **OUT** | **Disk** **Size** | **Cpu** **Load** | **Create** **Time** |
|
||
| ----------- | ------ | ------------------ | --------- | ------------- | -------------- | --------------- | ------------------ | ----------------- | -------------------- |
|
||
|
||
|
||
|
||
#### 3. 模型计算
|
||
|
||
- 根据集群配置查询最近N小时的样本数据，计算每个Topic分区的平均指标
|
||
|
||
- 根据集群的副本、Leader、Topic、Rack等元数据信息抽象出虚拟集群(Class类)，根据均衡目标算法来改变虚拟集群(Class类)中的元数据分布。
|
||
|
||
- 根据真实集群与虚拟集群元数据分布的不同提取出需要的副本迁移任务、Leader切换任务
|
||
|
||
#### 4. 均衡算法
|
||
|
||
输入参数：指标计算周期、均衡节点范围、均衡维度（有顺序）、各维度均衡区间、Topic黑名单、下线节点列表（应用到副本）、迁移Topic列表（应用到副本）
|
||
|
||
输出结果：迁移总览、迁移概览、迁移明细、reassignment json file，其中迁移明细为副本从哪个节点迁移到哪个节点上
|
||
|
||
均衡维度：
|
||
|
||
1. Rack感知(副本迁移)
|
||
|
||
1. 默认维度
|
||
|
||
2. 迁移策略
|
||
- Broker每个副本AR分配列表存在2个以上相同的Rack则迁移到不同的Rack
|
||
|
||
2. Topic Leader数平均分布(Leader切换、副本迁移)
|
||
|
||
1. 默认维度
|
||
|
||
2. 迁移策略
|
||
- 每台Broker的Topic Leader分布数\>=Topic的Leader总数/broker总数
|
||
|
||
3. Topic副本数平均分布(副本迁移)
|
||
|
||
1. 默认维度
|
||
|
||
2. 迁移策略
|
||
|
||
- 每台Broker相同Topic副本分布个数\>upperLimit迁出
|
||
|
||
- 每台Broker相同Topic副本分布个数\<lowerLimit迁入
|
||
|
||
4. 磁盘使用率平均分布(副本迁移)
|
||
|
||
1. 可选维度
|
||
|
||
2. 迁移策略
|
||
|
||
- 磁盘使用率\>upperThreshold副本降序迁出
|
||
|
||
- 磁盘使用率\<lowerThreshold迁入
|
||
|
||
5. 网络流入使用率平均分布(副本迁移)
|
||
|
||
1. 可选维度
|
||
|
||
2. 迁移策略
|
||
|
||
- 流入\> upperThreshold副本降序迁出
|
||
|
||
- 流入\<lowerThreshold迁入
|
||
|
||
6. 网络流出使用率平均分布(Leader切换、副本迁移)
|
||
|
||
1. 可选维度
|
||
|
||
2. 迁移策略
|
||
|
||
- 流出\>upperThreshold副本降序进行Leader切换
|
||
|
||
- 切换后流量依然\> upperThreshold则需要把Leader副本迁出
|
||
|
||
- 流出\<lowerThreshold则需要把follower切换成Leader
|
||
|
||
- 切换后流量依然\< lowerThreshold则需要进行副本迁入
|
||
|
||
7. CPU使用率平均分布
|
||
|
||
1. 可选维度
|
||
|
||
2.
|
||
|
||
|
||
|
||
#### 5. 均衡执行
|
||
|
||
输入参数：并行度、限速、执行策略、reassignment json file
|
||
|
||
处理：
|
||
|
||
- 并行度定义，导致有流入或流出流量各计算一个并行度，流出统计在Leader上，比如一个分区0 \[10,11,12\] -\> \[10,11,15\] ，那么10计入一个并行度，15计入一个并行度
|
||
|
||
- 根据并行度拆分任务，对于小于2.4版本Kafka，按照并行度拆分各个小的子任务分别执行，每个节点迁入或迁出副本数不大于并行度限制。对于大于等于2.4版本Kafka，根据节点并行度动态增加副本迁移数。
|
||
|
||
- 根据集群metadata元数据查询所有URP分区，优先迁移
|
||
|