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

Question

背景

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

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

问题

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

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

有时，蓝绿色导致其中一个实例完全用尽空间。发生这种情况时，AWS服务将再次启动蓝绿色，这将解决问题，而不会影响客户。 （尽管它确实会影响我的心跳速度！）

碎片大小

我们索引的碎片大小为千兆字节，但低于recommendation的Elasticsearch 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：

为了避免可能导致单个节点紧张并影响性能的这种情况，如果您计划每个索引有两个或多个副本，我们建议您选择实例计数的三倍。]

进一步改进

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

就我而言，我可以合并较旧的索引，例如data-2019-01 ... data-2019-12-> data-2019。