背景
我有一个具有14个数据实例的AWS托管Elascsearch v6.0集群。
它具有基于时间的索引,例如data-2010-01
,...
,data-2020-01
。
问题
[可用存储空间在实例之间非常不平衡,我可以在AWS控制台中看到:
我已经注意到,每次AWS服务通过蓝绿色部署运行时,此分布都会发生变化。当集群设置更改或AWS发布更新时,会发生这种情况。
有时,蓝绿色导致其中一个实例完全用尽空间。发生这种情况时,AWS服务将再次启动蓝绿色,这将解决问题,而不会影响客户。 (尽管它确实会影响我的心跳速度!)
碎片大小
我们索引的碎片大小为千兆字节,但低于recommendation的Elasticsearch 50GB
。但是,分片大小确实因索引而异。我们的许多旧索引只有很少的文件。
问题
AWS平衡算法无法很好平衡的方式,并且每次都导致不同的结果,这是意外的。
我的问题是算法如何选择将哪些碎片分配给哪个实例,我自己可以解决这种不平衡问题?
我问了这个AWS支持人员的问题,谁能够给我一个很好的答案,所以我想在此与其他人分享摘要。
简而言之:
我的案件
[我的14个实例中的每个实例都获得~100 shards
,而不是每个~100 GB
。
请记住,我有很多相对空白的索引。这转化为大小碎片的混合,当AWS Elasticsearch(无意间)向实例分配大量大碎片时,会导致不平衡。
由于我将群集设置为分布在3个可用区上并且我的数据实例数(14)不能被3整除,这一事实使情况进一步恶化。
将我的数据实例计数增加到15(或减少到12)解决了这个问题。
从多可用区上的AWS Elasticsearch docs:
为了避免可能导致单个节点紧张并影响性能的这种情况,如果您计划每个索引有两个或多个副本,我们建议您选择实例计数的三倍。]
进一步改进
除了可用性区域问题之外,我建议保持索引大小平衡以使AWS算法更容易。
就我而言,我可以合并较旧的索引,例如data-2019-01
... data-2019-12
-> data-2019
。