• 机房 A 目前为饱和状态，批量新增机器难以支持。

• 机房 A 主要由 Hadoop、ES 集群组成，业务交互会产生大量跨机房流量，峰值会影响到业务。

• 如何提升迁移效率

2）迁移的人工成本：迁移过程中，每个流程环节都需要人工介入，如何能提升自动化率，降低人工成本，也是研究提高生产力的方向。

• 手动迁移节点

• 调参保证稳定性

• 整理问题，确立后续工作侧重点

• 添加 exclude_name 后，集群多了很多 relocating shards,此时会出现大量的分片迁移操作，通过_cat/recovery 可以看到期间的分片进行的过程。

• 白天集群是写入高峰，压力不算小，此时还需要同步数据，会造成 exclude name 对应的节点，因为要大量的迁出数据，会进行大量的磁盘读操作，同时，还有很多分片还在进行当前的写入操作，磁盘 io 很容易趋近于100%（使用的是机械盘）。

• 迁入分片的节点也因为读取量的飙升，导致了磁盘的 io 上涨。继而影响同步两侧的节点纷纷 load 飙高，影响的就是会有个别的 appcode 写入堆积。

• 高峰时期：调整到2个机器节点同时 exclude。

• 低峰时期：保持5个节点同时 exclude。

• status：集群状态为 Green

• load：集群 load>30节点不超过7个；load>50的节点不能超过3个（基于日常集群情况）

• 哪些节点迁移完成：如有，则统计数量

• 目前在迁移的 shard 数量

• 高峰：2个机器节点

• 低峰：5个机器节点

之前的第二个阶段解决了自动化的问题，节省了迁移效率，在自动化稳定运行的同时，也在探索提升稳定性与迁移速率，在1~2月期间，主要做了以下几个方面的探索与实践。

1）total_shards_per_node

index.routing.allocation.total_shards_per_node：设置单个索引在单个节点上最多的分片数（包括主副本）。默认无限量。

调整原则：保证单个索引在单个节点上保留最少的分片数，以避免数据分片倾斜的情况，已提升整体稳定性。

total_shards_per_node 的调整逻辑如下：

total_shards_per_node: shard_num/(nodes_count * 0.95（buffer系数） * 0.5)

需要注意的是：

索引级个性化的 template 参考如下：

{  "order": 99,  "index_patterns": [    "log_appcode-*" ],  "settings": {    "index": {      "number_of_shards": "278",      "routing": {        "allocation": {          "total_shards_per_node": "2"       }     },      "refresh_interval": "60s"   } },  "mappings": {    "properties": {        #索引独立的结构          } }}

注：上面这个template 模板设定的索引分片单个节点最多分配两个分片。

2）node_left.delayed_timeout

index.unassigned.node_left.delayed_timeout : 节点脱离集群后多久分配unassigned shards（默认1min），相当于延迟恢复分配多久的时间。

这个参数相当重要，尤其是大集群中，节点宕机重启时有发生，如果不做设置，节点对应的数百副本分片就会进行恢复操作，期间会耗费大量的 IO 资源，影响集群稳定性。而且集群重启后，还会进一步做 rebalance 以平衡分片。

索引恢复主要有6个阶段，如下：

当机器宕机重启后，机器对应的所有分片会短暂成为 UNASSIGNED SHARD 状态，默认60s后集群 UNASSIGNED SHARD 进行恢复操作，此时会把原本宕机机器的未分配分片（副本）分配到其余节点，因为是副本分片同步，需要从主分片进行同步数据，比从本地恢复慢了不少，且极为影响性能。过程类似于：

基于此，针对 node_left 的设置做了两次的尝试：

a. index.unassigned.node_left.delayed_timeout: 120m

将所有的索引 template 设置延迟分配时间设置为120分钟。

当遇到节点宕机后，不会再次出现大量分片迁移的过程，当节点重启后，分片会从节点本地进行恢复，效率高，性能影响小。

但是如果是节点故障宕机，无法启动时，会出现在 delyed_timeout 时间到达后，进行集中大量的分片恢复，如果节点分片多，同样会有性能方面的影响和损耗。

b. index.unassigned.node_left.delayed_timeout: random time

在调大延迟分配时间后，还会出现集中分片恢复的情况，主要是因为对于单一节点的索引分片都是同一时间变成的 unassigned，也会在同一时间进行恢复。

基于此，将 delayed_timeout 设置为随机数值，在创建索引的时候，设置为100~300min区间的随机数，类似如下：

delayed_timeout = random.randint(100, 300)PUT /index/_settings{  "settings": {    "index.unassigned.node_left.delayed_timeout": delayed_timeout }}

调整后，在故障宕机观测，会发现恢复分片是一个持续间断过程，而非之前的突增突降。如图对比：

3）单机器单节点迁移

数据节点的物理机的配置为：32core 128g 14TB（为主，还有9TB、18TB）。

单物理机部署两个节点（data1，data2）实例，每个节点占用16core 64g资源，磁盘共用。

之前两个阶段的迁移是以物理机为单位进行迁移，批次迁移多台物理机数据，期间会因为大量的数据同步传输导致磁盘io问题，所以需要在高低峰进行批次调整，以保证稳定性。但是批次量无法提升，导致速率不太理想。

此次更换为单机器单节点迁移，exclude_node 中只选择同批次机器的data1，等 data1节点迁移完成后，迁移 data2。cluster exclude 设置如下：

PUT _cluster/settings{  "transient" :{      "cluster.routing.allocation.exclude._name" : "data1_node1,data1_node2,..." }}

使用单节点迁移后，单批次节点在高峰期可以增加50%，低峰时期增加80%。在迁移过程中，集群整体写入，与同步节点的 cpu、磁盘 io 均比较稳定，当 data1迁移完成后，批次节点的 load 整体会控制在10以内，稳定性得到相应的提升。

4）cluster_concurrent_rebalance

cluster.routing.allocation.cluster_concurrent_rebalance: 用来控制集群内并发分片的 rebalance 数量，默认为2。

ES集群的 cluster_concurrent_rebalance 参数长期使用的在10（节点数多，增加分片的同步效率）。

在迁移节点过程中，同步的节点会非常多，出现很多的 relocating shards，且同时还会有 rebalance 的分片，在迁移之后，还会继续做 rebalance。

此处为了减少 rebalance 的频率与周期，设置 cluster_concurrent_rebalance 为0，相当于一直都不做 rebalance。

但是如果长期不进行 rebalance，分片会出现倾斜不均衡的情况，基于此，进行了3.3.4 手动 reroute 操作，来调整分片的均衡。

rebalance 节点主要由decider 控制器来决定的，而非当前分片使用的情况，这样会造成一个情况，机器在rebalance 后整体分片数均衡，但是写入不均衡（有些分片是当周分片正在写入数据，有些分片是上周分片，均衡之后可能会出现一些节点的当周分片数很多，导致写入压力大，磁盘 io 高，反而没有达到真正的均衡）。

现象是会有一些节点在高峰期出现持续高 load，磁盘 io 趋近100%的情况。不得不做一些手动的 reroute 分片，来缓解节点压力，遇到持续增高，可能会出现 node_left 重启的现象。

因为3.3.3 中将 cluster_concurrent_rebalance 调为0，集群不会做分片均衡操作，新增索引分片会按照 decider 进行调度，最极端的情况会将某些分片数少的节点分配超过一倍的分片数。

举个例子：

上述两个现象直观导致的现象都是因为个别节点分片不均衡，导致性能受到影响，继而会出现 node_left 的情况。

分析了上述两个原因，决定从写入的分片均衡来入手。

因为是日志集群，索引是以周维度创建，每周日凌晨提前进行创建次周索引（tips:如果不提前创建，会在次周切换索引时，引发大量的 pending_tasks，造成集群写入大面积堆积），只要保证次周写索引的分片在索引节点均衡即可。

在创建完新周索引后，可以对分片进行调整，流程图如下：

针对以上流程做简要说明：

➃reroute new node

以上所有的措施已经能解决最核心的两个问题：稳定性、迁移速度。

按照当时迁移速度估算，可以在剩余1个月内完成全部的节点迁移，但是否有更快更好的方法做迁移？

在上个优化点 reroute new shard 调整分片均衡 中得到灵感，新分片迁移是很快的，因为没有数据，基本不费时间且对性能没有任何影响。那能否用于在迁移节点上来呢？答案是可以的。

在 reroute new shard 基础上，做了改进，并根据机器配置，做了差异化的处理(包括迁移节点和平衡分片)，设计图如下：

以上设计图有几点需要了解：

如果有 ssd 机器，可以在原有阈值上进一步提升，也可以做点对点分片均衡调整，将高配置节点、分片数较少节点统一作为被同步节点，将配置低节点、分片数远高于阈值节点作为同步节点，进行 reroute。

分片均衡，可以参考以下用法：

POST _cluster/reroute{  "commands": [   {      "move": {        "index": "log_appcode-2023.18",        "shard": 59,        "from_node": "data2_node1",        "to_node": "data2_node10"     }   } ]}

在做完以上步骤后，等到次周开始，集群写入都切到了新的索引后，可以进行 exclude 节点操作，此时由于批次节点都没有写入索引，迁移同步分片会非常快，且对性能影响非常小。

总结：

5）coordinate node迁移

coordinate node 主要用来做协调作用，负责接收集群的读写请求，继而传递到数据节点进行实际的数据交互。

本身协调节点不进行存储，主要需要 cpu、内存的资源。

ES日志集群的协调机器大致在40+，分批次每周5台迁移即可，迁移完成，需要对 Logstash 的 output 端进行重刷服务。

注：

6）master node迁移

master 节点迁移相对来说比较简单，只需要找到临时机器部署在机房 B，部署好对应服务，把机房 A 的 master 服务下掉，把机房 B 的 new master 节点起来即可。

注：

当然也可以通过负载和服务发现框架来实现动态调整 master 节点。

做完以上步骤，ES 集群就全部迁移到新机房了，后续就是对应的服务迁移与适配。

最终在近三个月的时间里，不断尝试中，完成了集群整体迁移，并且提前了一周多的时间，也做到了零故障。期间遇到元旦峰值，也得到了锻炼和考验。

总结下大规模 ES 集群节点迁移主要的要点有以下：

技术层面

相信以上的经验和一些技术要点，不仅在集群节点迁移可以参考，同样也适用于大规模集群开发与维护。可以说，就是有了不断地集群平台维护开发的经验与总结，才逐步总结出各种优化方法。

• https://www.elastic.co/cn/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster

• https://www.elastic.co/guide/en/elasticsearch/reference/7.7/allocation-total-shards.html

• https://www.elastic.co/guide/en/elasticsearch/reference/7.7/delayed-allocation.html

• https://www.elastic.co/guide/en/elasticsearch/reference/7.7/index-modules-translog.html

• https://www.elastic.co/guide/en/elasticsearch/reference/7.7/cluster-reroute.html

• https://cloud.tencent.com/developer/article/1334743?cps_key=6a15b90f1178f38fb09b07f16943cf3e

• https://blog.csdn.net/laoyang360/article/details/108047071