anchor.diff:  - Shard allocation awareness is configured to avoid concentrating all copies of
     a shard within a single zone.
   - The cluster has at least three master-eligible nodes. At least two of these 
  -  nodes are not voting-only master-eligible nodes, spread evenly across at least
  -  three zones.
  +  nodes are not voting-only master-eligible nodes, and they are spread evenly
  +  across at least three zones.
   - Clients are configured to send their requests to nodes in more than one zone
     or are configured to use a load balancer that balances the requests across an
     appropriate set of nodes. The {ess-trial}[Elastic Cloud] service provides such
  
positive.code: remote node and a mere loss of connectivity between the nodes. If both nodes
  were capable of running independent elections, a loss of connectivity would
  lead to a https://en.wikipedia.org/wiki/Split-brain_(computing)[split-brain
  problem] and therefore, data loss. {es} avoids this and
  protects your data by electing neither node as master until that node can be
  sure that it has the latest cluster state and that there is no other master in
  the cluster. This could result in the cluster having no master until
  
negative.code: 
  A single node cluster is not resilient. If the the node fails, the cluster will
  stop working. Because there are no replicas in a one-node cluster, you cannot
  store your data redundantly. However, by default at least one replica is
  required for a <<cluster-health,`green` cluster health status>>. To ensure your
  cluster can report a `green` status, override the default by setting
  <<dynamic-index-settings,`index.number_of_replicas`>> to `0` on every index.
  
  If the node fails, you may need to restore an older copy of any lost indices
  from a <<modules-snapshots,snapshot>>.
  
  Because they are not resilient to any failures, we do not recommend using
  one-node clusters in production.
  
  [[high-availability-cluster-design-two-nodes]]
  ==== Two-node clusters
  