Forcing allocation awareness can come in handy when we know, in advance, how many values our awareness attributes can take, and we don't want more replicas than needed to be allocated in our cluster, for example, not to overload our cluster with too many replicas. To do this, we can force allocation awareness to be active only for certain attributes. We can specify these values using the cluster.routing.allocation.awareness.force.zone.values property and providing a list of comma-separated values to it. For example, if we would like allocation awareness to only use the groupA and groupB values of the node.group property, we would add the following to the elasticsearch.yml file:

cluster.routing.allocation.awareness.attributes: group
cluster.routing.allocation.awareness.force.zone.values: groupA, groupB

If you look closely at the parameters mentioned previously, you would notice that there are three kinds:

In order to update settings for a given index (for example, our mastering index), we could run the following command:

curl -XPUT 'localhost:9200/mastering/_settings' -d '{
 "index.routing.allocation.require.group": "groupA"
}'

As you can see, the command was sent to the _settings end-point for a given index. You can include multiple properties in a single call.

In order to update settings for the whole cluster, we could run the following command:

curl -XPUT 'localhost:9200/_cluster/settings' -d '{
 "transient" : {
  "cluster.routing.allocation.require.group": "groupA"
 }
}'

As you can see, the command was sent to the cluster/_settings end-point. You can include multiple properties in a single call. Please remember that the transient name in the preceding command means that the property will be forgotten after the cluster restart. If you want to avoid this and set this property as a permanent one, use persistent instead of the transient one. An example command, which will keep the settings between restarts, could look like this:

curl -XPUT 'localhost:9200/_cluster/settings' -d '{
 "persistent" : {
  "cluster.routing.allocation.require.group": "groupA"
 }
}'

Now, let's use our example cluster to see how the allocation inclusion works. Let's start by deleting and recreating the mastering index by using the following commands:

curl -XDELETE 'localhost:9200/mastering'
curl -XPOST 'localhost:9200/mastering' -d '{
 "settings" : {
  "index" : {
   "number_of_shards" : 2,
   "number_of_replicas" : 0
  }
 }
}'

After this, let's try to run the following command:

curl -XPUT 'localhost:9200/mastering/_settings' -d '{
 "index.routing.allocation.include.tag": "node1",
 "index.routing.allocation.include.group": "groupA",
 "index.routing.allocation.total_shards_per_node": 1
}'

If we visualize the response of the index status, we would see that the cluster looks like the one in the following image:

As you can see, the mastering index shards are allocated to nodes with the tag property set to node1 or the group property set to groupA.

Now, let's reuse our example cluster and try running the following command:

curl -XPUT 'localhost:9200/mastering/_settings' -d '{
 "index.routing.allocation.require.tag": "node1",
 "index.routing.allocation.require.group": "groupA"
}'

If we visualize the response of the index status command, we would see that the cluster looks like this:

As you can see, the view is different than the one when using include. This is because we tell Elasticsearch to allocate shards of the mastering index only to the nodes that match both the require parameters, and in our case, the only node that matches both is the first node.

Let's now look at exclusions. To test it, we try to run the following command:

curl -XPUT 'localhost:9200/mastering/_settings' -d '{
 "index.routing.allocation.exclude.tag": "node1",
 "index.routing.allocation.require.group": "groupA"
}'

Again, let's look at our cluster now:

As you can see, we said that we require the group property to be equal to groupA, and we want to exclude the node with a tag equal to node1. This resulted in the shard of the mastering index being allocated to the node with the 192.168.2.2 IP address, which is what we wanted.

Of course, the mentioned properties are not the only ones that can be used. With the release of Elasticsearch 1.3.0 we got the ability to configure awareness on the basis of the disk usage. By default, disk-based allocation is turned on, and if we want, we can turn it off by setting the cluster.routing.allocation.disk.threshold_enabled property to false.

There are three additional properties that can help us configure disk-based allocation. The cluster.routing.allocation.disk.watermark.low cluster controls when Elasticsearch does not allow you to allocate new shards on the node. By default, it is set to 85 percent and it means that when the disk usage is equal or higher than 85 percent, no new shards will be allocated on that node. The second property is cluster.routing.allocation.disk.watermark.high, which controls when Elasticsearch will try to move the shards out of the node and is set to 90 percent by default. This means that Elasticsearch will try to move the shard out of the node if the disk usage is 90 percent or higher.

Both cluster.routing.allocation.disk.watermark.low and cluster.routing.allocation.disk.watermark.high can be set to absolute values, for example, 1024mb.