2020年最危险的多平台恶意软件框架

此处的 timing 是创建时间 20 天后，需要保证在第二步骤中，对过去老索引数据备份先执行完成后才可以进入到 cold phase.

通过老索引数据冷备并且降低索引副本，我们可以把集群整体的分片数量维持在一个较低的水位。但是还有另外一个问题待解决，也即 shrink 失败的问题。刚好，我们可以利用对老索引数据冷备并且降低索引副本的方案，来彻底解决 shrink 失败的问题。

在前文有提到，shrink 失败归根结底是因为索引的副本数量为 1， 现在我们可以把数据备份和降低副本提前，让老索引进入到 ILM 的 warm phase 中时已经是 0 副本，之后再执行 shrink 操作就不会有问题了;同时，因为副本降低了，索引从 hot 节点迁移到 warm 节点迁移的数据量也减少了一半，从而降低了集群负载，一举两得。

因此，我们需要修改 ILM 策略，在 warm phase 就把索引的副本数量调整为 0， 然后去除 cold phase。

另外一个可选的优化项是：对老的索引进行冻结，冻结索引是指把索引常驻内存的一些数据从内存中清理掉(比如 FST, 元数据等)， 从而降低内存使用量，而在查询已经冻结的索引时，会重新构建出临时的索引数据结构存放在内存中，查询完毕再清理掉;需要注意的是，默认情况下是无法查询已经冻结的索引的，需要在查询时显式的增加"ignore_throttled=false"参数。

经过上述优化，我们最终解决了集群整体分片数量过多和 shrink 失败的问题。在实施过程中引入了额外的定时任务脚本实施自动化快照，实际上在 7.4 版本的 ES 中，已经有这个功能了，特性名称为SLM(快照生命周期管理)，并且可以结合 ILM 使用，在 ILM 中增加了"wait_for_snapshot"的 ACTION, 但是却只能在 delete phase 中使用，不满足我们的场景。

场景 8：客户十分喜欢的 Searchable Snapshots!

在上述的场景中，我们花费大量的精力去解决问题和优化使用方式，保证 ES 集群能够稳定运行，支持 PB 级别的存储。溯本回原，如果我们能有一个方案使得客户只需要把热数据放在 SSD 盘上，然后冷数据存储到 COS/S3 上，但同时又使冷数据能够支持按需随时可查，那我们前面碰到的所有问题都迎刃而解了。可以想象得到的好处有：

1. 只需要更小规模的集群和非常廉价的 COS/S3 对象存储就可以支持 PB 级别的数据量，客户的资金成本非常低;
2. 小规模的集群只需要能够支撑热索引的写入和查询即可，集群整体的分片数不会太多，从而避免了集群不稳定现象的发生。

而这正是目前 es 开源社区正在开发中的 Searchable Snapshots 功能，从Searchable Snapshots API的官方文档上可以看到，我们可以创建一个索引，将其挂载到一个指定的快照中，这个新的索引是可查询的，虽然查询时间可能会慢点，但是在日志场景中，对一些较老的索引进行查询时，延迟大点一般都是可以接受的。

所以我认为，Searchable Snapshots 解决了很多痛点，将会给 ES 带来新的繁荣!

总结

经历过上述运维和优化 ES 集群的实践，我们总结到的经验有：

1. 新集群上线前务必做好集群规模和节点规格的评估
2. 集群整体的分片数量不能太多，可以通过调整使用方式并且借助 ES 本身的能力不断进行优化，使得集群总体的分片数维持在一个较低的水位，保证集群的稳定性
3. Searchable Snapshots 利器会给 ES 带来新的生命力，需要重点关注并研究其实现原理

从一开始和客户进行接触，了解客户诉求，逐步解决 ES 集群的问题，最终使得 ES 集群能够保持稳定，这中间的经历让我真真正正地领悟到"实践出真知"这句话的真谛，只有不断实践，才能对异常情况迅速做出反应，以及对客户提的优化需求迅速反馈。

（编辑：常州站长网）

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