Elasticsearch7系列下同索引主分片分布不均衡思考

es版本: 7.17.5

现象:

> GET /_cat/shards/sw_segment-20250429?v&s=shard,prirep > es-shard-status-sw_segment-20250428

> cat es-shard-status-sw_segment-20250428 | grep " p " | grep es-data-ssd-0|wc -l
26

> cat es-shard-status-sw_segment-20250428 | grep " p " | grep es-data-ssd-1|wc -l
27

> cat es-shard-status-sw_segment-20250428 | grep " p " | grep es-data-ssd-2|wc -l
72

> cat es-shard-status-sw_segment-20250428 | grep " p " | grep es-data-ssd-3|wc -l
29

> cat es-shard-status-sw_segment-20250428 | grep " p " | grep es-data-ssd-4|wc -l
26

可以看到 sw_segment-20250428 这个索引在不同节点上，主分片分布非常不均衡，如果这个索引写入量/数据量很大的话，很容易导致 IO 相对其他实例有很大的差异

但是经过查询后发现，在整个集群所有分片中，主分片在所有es 实例中分布较为均衡

而es7系列原生自带的 balance 行为不支持针对同 index 的 primary shard 进行干预 (8.12 有 cluster.routing.allocation.balance.write_load 的权重配置)

这时候可以利用index total_shards_per_node选项来进行较为十分不灵活不优雅不可靠的干预，先将索引副本数设置为0，然后在索引初始化前设置该配置，以强制约束每一个es实例分布一样数量的分片数量。等到全部主分片都调度初始化好了，再根据需要把副本数调整回来，把 total_shards_per_node 也根据(该索引的分片数 * 副本数)进行合适的调整。

也可以为了长期打算，将total_shards_per_node数量配置为 (该索引的分片数 * 副本数) / (集群中可调度该索引分片的es实例数 - 1)

当然，也可以像社区issue中提到那样，用现成的工具 / 开发工具，利用reroute等api接口进行实时干预，并将相关shard进行统计监控

相关社区issue: https://github.com/elastic/elasticsearch/issues/41543