anchor.diff:  === Shard Allocation Awareness
   
   When running nodes on multiple VMs on the same physical server, on multiple
  -racks, or across multiple awareness zones, it is more likely that two nodes on
  -the same physical server, in the same rack, or in the same awareness zone will
  +racks, or across multiple zones or domains, it is more likely that two nodes on
  +the same physical server, in the same rack, or in the same zone or domain will
   crash at the same time, rather than two unrelated nodes crashing
   simultaneously.
   
  
positive.code: -------------------------------------------------------------------
  <1> We must list all possible values that the `zone` attribute can have.
  
  Now, if we start 2 nodes with `node.attr.zone` set to `zone1` and create an index
  with 5 shards and 1 replica. The index will be created, but only the 5 primary
  shards will be allocated (with no replicas). Only when we start more nodes
  with `node.attr.zone` set to `zone2` will the replicas be allocated.
  
  The `cluster.routing.allocation.awareness.*` settings can all be updated
  dynamically on a live cluster with the
  
negative.code: Forced awareness solves this problem by *NEVER* allowing copies of the same
  shard to be allocated to the same zone.
  
  For example, lets say we have an awareness attribute called `zone`, and we
  know we are going to have two zones, `zone1` and `zone2`. Here is how we can
  force awareness on a node:
  
  [source,yaml]
  -------------------------------------------------------------------
  