[[modules-cluster]] === Cluster-level shard allocation and routing settings include::{es-ref-dir}/modules/shard-allocation-desc.asciidoc[] One of the main roles of the master is to decide which shards to allocate to which nodes, and when to move shards between nodes in order to rebalance the cluster. There are a number of settings available to control the shard allocation process: * <> control allocation and rebalancing operations. * <> explains how Elasticsearch takes available disk space into account, and the related settings. * <> and <> control how shards can be distributed across different racks or availability zones. * <> allows certain nodes or groups of nodes excluded from allocation so that they can be decommissioned. Besides these, there are a few other <>. include::cluster/shards_allocation.asciidoc[] include::cluster/disk_allocator.asciidoc[] [[shard-allocation-awareness-settings]] ==== Shard allocation awareness settings You can use <> 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. <>. `cluster.routing.allocation.awareness.attributes`:: (<>) The node attributes that {es} should use as awareness attributes. For example, if you have a `rack_id` attribute that specifies the rack in which each node resides, you can set this setting to `rack_id` to ensure that primary and replica shards are not allocated on the same rack. You can specify multiple attributes as a comma-separated list. `cluster.routing.allocation.awareness.force.*`:: (<>) The shard allocation awareness values that must exist for shards to be reallocated in case of location failure. Learn more about <>. include::cluster/allocation_filtering.asciidoc[] include::cluster/misc.asciidoc[]