Controlling shard and replica allocation

As we already discussed, indices that live inside your cluster can be built of many shards and each shard can have many replicas. With the ability to have multiple shards of a single index, we can deal with indices that are too large to fit on a single machine. The reasons may be different—from memory to storage ones. With the ability to have multiple replicas of each shard, we can handle a higher query load by spreading replicas over multiple servers. In order to shard and replicate, ElasticSearch has to figure out where in the cluster it should place the shards and replicas. It needs to figure out which server/node each shard or replica should be placed on.

Explicitly controlling allocation

Imagine that we have our cluster divided into two sections. We want one index, named shop, to be placed on some nodes and the second index called users to be placed on other nodes, and the last index called promotions to be placed on all the nodes that the users...