Shard Allocation Awareness(碎片分配意

官网地址：Shard Allocation Awareness | Elasticsearch Reference [5.5] | Elastic

Shard Allocation Awareness（碎片分配意识）

当在同一物理服务器上、多个机架上或跨多个感知区域上运行多个VM上的节点时，在同一物理服务器上、同一机架或同一感知区域中的两个节点更可能同时崩溃，而不是两个不相关的节点同时崩溃。

如果Elasticsearch觉察到你的硬件的物理结构，它可以确保主碎片和复制碎片分布在不同的物理服务器，机架，或区域，以减少在同一时间失去了所有的碎片复制风险。

碎片分配意识设置允许你告诉Elasticsearch关于您的硬件配置。

举个例子，假设我们有几个架子。当我们开始一个节点，我们可以告诉它这架是通过分配一个任意元数据属性称为rack_id - 我们可以使用任何属性的名字。例如:

./bin/elasticsearch -Enode.attr.rack_id=rack_one

此设置也可以在配置文件中指定的elasticsearch.yml。

现在，我们需要告诉Elasticsearch要使用哪个属性来设置碎片分配意识。这可以通过在所有候选主节点（master-eligible node）的elasticsearch.yml的文件，也可以通过cluster-update-settings API设置

对于我们的示例，我们将在配置文件中设置值：

cluster.routing.allocation.awareness.attributes: rack_id

使用这个配置，假设我们用node.attr启动两个节点。rack_id设置为rack_one，我们创建一个索引，其中包含5个主碎片和1个主分的副本。所有的主分片和副本都分配在两个节点上。

现在，如果我们用node.arrt.rack_id设置为rack_two启动两个以上的节点，Elasticsearch将把shard移动到新的几点，确保（如果可能的话），相同碎片的两个拷贝不会再同一个机机架上。然后，如果rack_two 挂了，集群会将两个节点取下来，Elasticsearch会将丢失的shard副本分配到rack_one中的节点。

Prefer local shards（更喜欢本地分片）

当执行搜索或GET请求，启用shard Awareness，Elasticsearch将喜欢使用本地的碎片 - 碎片在同一意识团体 - 执行请求。这通常比跨越机架或感知区域更快。

可以指定多个感知属性，在这种情况下，每个属性的值的组合被认为是一个单独的值。

cluster.routing.allocation.awareness.attributes: rack_id,zone

注意（note）：当使用感知属性时，碎片不会被分配给那些没有为这些属性设置值的节点。

注意（note）：在具有相同感知属性值的特定组节点上分配的碎片的主/副本数量由属性值的数量决定。当组中的节点数不平衡且有许多副本时，可能没有分配复制碎片。

Forced Awareness（强制意识）

假设您有两个感知区域和足够的硬件跨越两个区域来托管所有主和复制碎片。但是，单个区域的硬件，虽然足以容纳一半的碎片，却无法承载所有的碎片。

有了普通的意识，如果一个区域失去了与另一个区域的联系，弹性搜索将把所有丢失的复制碎片分配给一个区域。但是在这个例子中，这个突然的额外负载会导致剩余区域的硬件过载。

强制意识（forced awareness）解决了这个问题，不允许将同一碎片的副本分配给同一区域。

例如，假设我们有一个名为zone的感知属性,我们知道我们将有两个区域，zone1和zone2。下面是我们如何在一个节点上强制意识:

cluster.routing.allocation.awareness.force.zone.values: zone1,zone2

cluster.routing.allocation.awareness.attributes: zone

我们必须列出zone属性可以拥有的所有可能值。

现在，如果我们将node.attr.zone设置为zone1启动两个节点，并创建一个包含5个碎片和1个副本的索引。该索引将被创建，但只有5个主碎片将被分配(没有副本)。只有当我们用node.attr.zone设置为zone2启动更多的节点时，才会分配副本。

cluster.routing.allocation.awareness.*可以通过cluster-update-settingsAPI在一个实时cluster中动态更新。