AWS Elasticsearch 集群磁盘空间在数据实例之间不平衡

Question

背景

我有一个 AWS 托管的 Elascsearch v6.0 集群，它有 14 个数据实例。

它具有基于时间的索引，例如 data-2010-01、...、data-2020-01。

问题

各个实例的可用存储空间非常不平衡，我可以在 AWS 控制台中看到：

我注意到，每次 AWS 服务通过蓝绿色部署运行时，这种分布都会发生变化。 更改集群设置或 AWS 发布更新时会发生这种情况。

有时蓝绿色会导致其中一个实例完全耗尽空间。 发生这种情况时，AWS 服务会启动另一个蓝绿色，这会在不影响客户的情况下解决问题。 （不过它确实对我的心率有影响！）

分片大小

我们索引的分片大小为千兆字节，但低于 Elasticsearch recommendation 和 50GB。 不过，分片大小确实因索引而异。我们的许多旧索引只有少量文档。

问题

AWS 平衡算法平衡不好的方式，每次都会导致不同的结果，这是出乎意料的。

我的问题是算法如何选择分配给哪个实例的分片，我可以自己解决这种不平衡吗？

Answer 1

我向 AWS 支持提出了这个问题，他们能够给我一个很好的答案，所以我想我会在这里为其他人分享摘要。

简而言之：

• AWS Elasticsearch 根据 shard count 而不是 shard size 分配分片，因此请尽可能保持分片大小平衡。
• 如果您将集群配置为分布在 3 个可用区，请将您的数据实例计数设置为可被 3 整除。

我的情况

我的 14 个实例中的每一个都获得 ~100 shards 而不是 ~100 GB。

请记住，我有很多相对空的索引。 当 AWS Elasticsearch（不经意间）将大量大分片分配给一个实例时，这会转化为小分片和大分片的混合，从而导致不平衡。

由于我将集群设置为分布在 3 个可用区并且我的数据实例数 (14) 不能被 3 整除，这一事实进一步恶化。

将我的数据实例计数增加到 15（或减少到 12）解决了这个问题。

来自多可用区上的 AWS Elasticsearch docs：

为避免此类情况可能会给单个节点带来压力并影响性能，如果您计划每个索引有两个或更多副本，我们建议您选择实例计数为 3 的倍数。

进一步改进

除了可用区问题，我建议保持索引大小平衡，以使 AWS 算法更容易。

在我的情况下，我可以合并旧索引，例如data-2019-01 ... data-2019-12 -> data-2019.