Elasticsearch Rack Awareness

前言|

前面的冷热章节中，我们讲到了ES集群的冷热架构，也知道了如何将相关的数据手动分配到指定的节点上，同时结合索引生命周期管理策略更好的去维护集群上的索引，那么今天，在本节基础上，我们再来讲讲ES的Rack Awareness功能。

一、何为Rack Awareness?

Rack的中文意思是支架、机架。Awareness是感知、识别、意识的意思。那么合在一起就是机架感知。也就是说ES具备节点所在机架感知的能力。为了更好的理解此功能，我们先来看一张下面的架构图：

Rack Awareness 拓扑图

从这个图我们可以看到如下信息：

1，ES的节点分布在不同的机架上。比如这里是机架1，机架2，每个机架上有2个节点。每个节点上分配了一些分片。

2，当一个机架掉电，可能会同时丢失几个节点。

3，如果相同主分片、副本分片的索引同时在这个机架上的几个节点上，那么此时，因为机架掉电，也可能会导致数据的丢失

4，通过Rack Awareness的机制，可以尽可能的避免将同一个索引的主副本分片同时分配到同一个机架上进而保证数据的高可用

二、Rack Awareness架构构建

《一》构建Rack Awareness 架构步骤：

1，标记Rack节点

2，配置集群

3，结果验证

《二》 实战演练

环境：ES 7.2 3台 分别对应机器：s4 s5 s6

将s4 ----> Rack1

将s5、s6 ----> Rack2

那么我们需要在S4上添加如下配置：

s4上配置

S5、S6分别配置如下：

S5、S6上配置

接下来重启ES集群，那么我们这个一个具有机架转移功能的集群就搭建完毕。那么接下来，我们去Kibana上进行一些软配置，让集群的索引的主副分片分配到不同的机架上。执行如下命令：

唤醒集群的机架配置

我们创建一个索引，指定3个分片、一个副本，我们来看一下分片的分布情况：

创建索引

分片分布情况

因此，我们会发现这个索引的分片分布分配在不同机架的不同节点上。这样就保证紧急情况下数据的高可用。

接下来，我们再来看一下操作：在上面的配置中，我们已经将集群配置在不同的机架上，那么我如果要强制改变这个属性，有没有办法呢？我们可以这样：

强制唤醒

我们再来写入点数据验证会发生什么？

分片未分配

我们通过查看集群健康状态可知：黄色。有副本分片未分配

查看集群健康状态

查看解释集群为何为不健康状态

三、总结

本节通过节点+机架部署的方式结合之前的冷热集群属性，让我们更加方便的去搭建一个高可用的ES分布式集群。好的。这就是本节的内容。