智能建筑发展的关键推动力

优先保证分片先从 hot 节点迁移到 warm 节点，这样后续的 shrink 才能顺利执行(也可能执行失败，因为 60 个分片都在一个节点上，可能会触发 rebalance, 导致分片迁移走，shrink 的前置条件又不满足，导致执行失败)。要完全规避这个问题，还得在 ILM 策略中设置，满足创建时间超过 360 个小时的索引，副本直接调整为 0，但是客户又不接受，没办法。

场景 7：自己实现 SLM

上文介绍了 10w 个分片会给集群带来的影响和通过开启 shrink 来降低分片数量，但是仍然有两个需要重点解决的问题：

1. 索引不断新建，如何保证一年内，集群总的分片数量不高于 10w，稳定在一个较低的水位?
2. ILM 中执行 shrink 可能会导致部分分片未分配以及 shrink 执行失败，怎么彻底解决呢?

可以估算一下，按小时建索引，60 分片 1 副本，一年的分片数为 24*120*365=1051200 个分片，执行 shrink 后分片数量 24*10*350 + 24*120*15 = 127200(15 天内的新索引为了保障写入性能和数据可靠性，仍然保持 60 分片 1 副本，旧的索引 shrink 为 5 分片 1 副本), 仍然有超过 10w 个分片。结合集群一年总的存储量和单个分片可以支持的数据量大小进行评估，我们期望集群总体的分片数量可以稳定为 6w~8w，怎么优化?

可以想到的方案是执行数据冷备份，把比较老的索引都冷备到其它的存储介质上比如 HDFS、S3、腾讯云的 COS 对象存储等。但是问题是这些冷备的数据如果也要查询，需要先恢复到 ES 中才可查，恢复速度比较慢，客户无法接受。由此也产生了新的想法，目前老的索引仍然是 1 副本，可以把老索引先进行冷备份，再把副本调为 0，这样做有以下几点好处：

1. 集群整体分片数量能降低一半;
2. 数据存储量也能降低一半，集群可以存储更多数据;
3. 老的索引仍然随时可查;
4. 极端情况下，磁盘故障引起只有一个副本的索引数据无法恢复时，可以从冷备介质中进行恢复。

经过和客户沟通，客户接受了上述方案，计划把老索引冷备到腾讯云的对象存储 COS 中，实施步骤为：

1. 所有存量的老索引，需要批量处理，尽快地备份到 COS 中，然后批量修改副本数量为 0;
2. 最近新建的索引，采用按天备份的策略，结合 ILM, 修改策略，在 ILM 执行过程中修改索引副本数为 0(ILM 的 warm phase 和 cold phase 都支持设置副本数量)。

其中第一个步骤的实施可以通过脚本实现，本案例中就采用了腾讯云 SCF 云函数进行实施，方便快捷可监控。实施要点有：

1. 按天创建 snapshot，批量备份每天产生的 24 个索引，如果是按月或者更大粒度创建快照，因数据量太大如果执行快照过程中出现中断，则必须全部重来，耗时耗力;按小时创建快照也不适用，会造成快照数量太多，可能会踩到坑。
2. 每创建一个快照，后续需要轮询快照的状态，保证前一个快照 state 为"SUCCESS"之后，再创建下一个快照;因为快照是按天创建的，快照名字可以为 snapshot-2020.06.01, 该快照只备份 6 月 1 号的所有索引。而在检查到 snapshot-2020.06.01 快照执行成功后，然后新建下一个快照时，需要知道要对哪天的索引打快照，因此需要记录当前正在执行哪一个快照。有两种方式记录，一是把当前正在执行的快照日期后缀"2020.06.01"写入到文件中, 脚本通过定时任务轮询时，每次都读文件;另外一种方式是创建一个临时的索引，把"2020.06.01"写入到这个临时索引的一个 doc 中，之后对该 doc 进行查询或者更新。
3. 创建快照时，可以把"include_global_state"置为 false, 不对集群的全局状态信息进行备份。

在实施完第一个步骤之后，就可以批量把对索引进行过备份的索引副本数都调为 0， 这样一次性释放了很多磁盘空间，并且显著降低了集群整体的分片数量。

接下来实施第二个步骤，需要每天执行一次快照，多创建时间较久的索引进行备份。实施比较简单，可以通过 crontab 定时执行脚本或者使用腾讯云 SCF 执行。

之后，就可以修改 ILM 策略，开启 cold phase, 修改索引副本数量为 0:

（编辑：常州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!