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

AWS Elasticsearch cluster disk space not balanced across data instances

背景

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

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

问题

免费存储 space 在各个实例之间非常不平衡,我可以在 AWS 控制台中看到:

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

有时,蓝绿色会导致 space 中的一个实例完全 运行。 发生这种情况时,AWS 服务会启动另一个蓝绿服务,这会在不影响客户的情况下解决问题。 (不过它确实会影响我的心率!)

碎片大小

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

问题

AWS 平衡算法的平衡效果不佳,每次都会产生不同的结果,这是意想不到的。

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

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

简而言之:

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

我的案例

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

记住我有很多相对空的索引。 这转化为小型和大型分片的混合,当 AWS Elasticsearch(无意中)为一个实例分配大量大型分片时会导致不平衡。

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

将我的数据实例数增加到 15(或减少到 12)解决了问题。

来自多可用区上的 AWS Elasticsearch docs

To avoid these kinds of situations, which can strain individual nodes and hurt performance, we recommend that you choose an instance count that is a multiple of three if you plan to have two or more replicas per index.

进一步改进

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

在我的例子中,我可以合并旧的索引,例如data-2019-01 ... data-2019-12 -> data-2019.