anchor.diff:  
   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, at least one replica is required for a
  -<<cluster-health,`green` cluster health status>>. To ensure your cluster can
  -report a `green` status, set
  -<<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.
  +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
  
positive.code: them fails then the remaining two still form a majority and can hold a
  successful election.
  
  Similarly, node redundancy makes it likely that if a node for a particular role
  fails, another node can take on its responsibilities.
  
  Finally, a resilient cluster should have at least two copies of each shard. If
  one copy fails then there is another good copy to take over. {es} automatically
  rebuilds any failed shard copies on the remaining nodes in order to restore the
  cluster to full health after a failure.
  
  Depending on your needs and budget, an {es} cluster can consist of a single
  node, hundreds of nodes, or any number in between. When designing a smaller
  
negative.code: - 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, 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
  