[[shard-allocation-awareness]]
== Shard allocation awareness

You can use custom node attributes as _awareness attributes_ to enable {es}
to take your physical hardware configuration into account when allocating shards.
If {es} knows which nodes are on the same physical server, in the same rack, or
in the same zone, it can distribute the primary shard and its replica shards to
minimize the risk of losing all shard copies in the event of a failure.

When shard allocation awareness is enabled with the `cluster.routing.allocation.awareness.attributes` setting, shards are only allocated to nodes that have values set for the specified awareness attributes. If you use multiple awareness attributes, {es} considers each attribute separately when allocating shards.

NOTE: The number of attribute values determines how many shard copies are
allocated in each location. If the number of nodes in each location is
unbalanced and there are a lot of replicas, replica shards might be left
unassigned.

TIP: Learn more about <<high-availability-cluster-design-large-clusters,designing resilient clusters>>.

[[enabling-awareness]]
=== Enabling shard allocation awareness

To enable shard allocation awareness:

. Specify the location of each node with a <<custom-node-attributes,custom node attribute>>. For example, 
if you want Elasticsearch to distribute shards across different racks, you might 
use an awareness attribute called `rack_id`. 
+
You can set custom attributes in two ways:

- By editing the `elasticsearch.yml` config file:
+
[source,yaml]
--------------------------------------------------------
node.attr.rack_id: rack_one
--------------------------------------------------------
+
- Using the `-E` command line argument when you start a node:
+
[source,sh]
--------------------------------------------------------
./bin/elasticsearch -Enode.attr.rack_id=rack_one
--------------------------------------------------------

. Tell {es} to take one or more awareness attributes into account when
allocating shards by setting
`cluster.routing.allocation.awareness.attributes` in *every* master-eligible
node's `elasticsearch.yml` config file.
+
--
[source,yaml]
--------------------------------------------------------
cluster.routing.allocation.awareness.attributes: rack_id <1>
--------------------------------------------------------
<1> Specify multiple attributes as a comma-separated list.
--
+
You can also use the
<<cluster-update-settings,cluster-update-settings>> API to set or update
a cluster's awareness attributes:
+
[source,console]
--------------------------------------------------
PUT /_cluster/settings
{
  "persistent" : {
    "cluster.routing.allocation.awareness.attributes" : "rack_id"
  }
}
--------------------------------------------------

With this example configuration, if you start two nodes with
`node.attr.rack_id` set to `rack_one` and create an index with 5 primary
shards and 1 replica of each primary, all primaries and replicas are
allocated across the two node.

.All primaries and replicas allocated across two nodes in the same rack
image::images/shard-allocation/shard-allocation-awareness-one-rack.png[All primaries and replicas are allocated across two nodes in the same rack]

If you add two nodes with `node.attr.rack_id` set to `rack_two`,
{es} moves shards to the new nodes, ensuring (if possible)
that no two copies of the same shard are in the same rack.

.Primaries and replicas allocated across four nodes in two racks, with no two copies of the same shard in the same rack
image::images/shard-allocation/shard-allocation-awareness-two-racks.png[Primaries and replicas are allocated across four nodes in two racks with no two copies of the same shard in the same rack]

If `rack_two` fails and takes down both its nodes, by default {es}
allocates the lost shard copies to nodes in `rack_one`. To prevent multiple
copies of a particular shard from being allocated in the same location, you can
enable forced awareness.

[[forced-awareness]]
=== Forced awareness

By default, if one location fails, {es} spreads its shards across the remaining
locations. This might be undesirable if the cluster does not have sufficient
resources to host all its shards when one location is missing.

To prevent the remaining locations from being overloaded in the event of a
whole-location failure, specify the attribute values that should exist with the
`cluster.routing.allocation.awareness.force.*` settings. This will mean that
{es} will prefer to leave some replicas unassigned in the event of a
whole-location failure instead of overloading the nodes in the remaining
locations.

For example, if you have an awareness attribute called `zone` and configure
nodes in `zone1` and `zone2`, you can use forced awareness to make {es} leave
half of your shard copies unassigned if only one zone is available:

[source,yaml]
-------------------------------------------------------------------
cluster.routing.allocation.awareness.attributes: zone
cluster.routing.allocation.awareness.force.zone.values: zone1,zone2 <1>
-------------------------------------------------------------------
<1> Specify all possible `zone` attribute values.

With this example configuration, if you have two nodes with `node.attr.zone`
set to `zone1` and an index with `number_of_replicas` set to `1`, {es}
allocates all the primary shards but none of the replicas. It will assign the
replica shards once nodes with a different value for `node.attr.zone` join the
cluster. In contrast, if you do not configure forced awareness, {es} will
allocate all primaries and replicas to the two nodes even though they are in
the same zone.