当集群中只有一个节点在运行时，意味着会有一个单点故障问题——没有冗余。单点的最大问题是系统容错性不高，当单节点所在服务器发生故障后，整个 ES 服务就会停止工作。
让我们在包含一个空节点的集群内创建名为 user 的索引。索引在默认情况下会被分配5个主分片和每个主分片的1个副本， 但是为了演示目的，我们将分配3个主分片和一份副本（每个主分片拥有一个副本分片）：
PUT /user { "settings" : { "number_of_shards" : 3, "number_of_replicas" : 1 } }我们的集群现在是下图所示情况，所有3个主分片都被分配在 Node 1 。
此时检查集群的健康状况GET /_cluster/health，我们会发现：
{ "cluster_name": "elasticsearch", "status": "yellow", # 1 "timed_out": false, "number_of_nodes": 1, "number_of_data_nodes": 1, "active_primary_shards": 3, "active_shards": 3, "relocating_shards": 0, "initializing_shards": 0, "unassigned_shards": 3, # 2 "delayed_unassigned_shards": 0, "number_of_pending_tasks": 0, "number_of_in_flight_fetch": 0, "task_max_waiting_in_queue_millis": 0, "active_shards_percent_as_number": 50 }#1 集群的状态值是 yellow
#2 未分配的副本数是 3
集群的健康状况为 yellow 则表示全部 主 分片都正常运行（集群可以正常服务所有请求），但是 副本 分片没有全部处在正常状态。 实际上，所有3个副本分片都是 unassigned —— 它们都没有被分配到任何节点。 在同一个节点上既保存原始数据又保存副本是没有意义的，因为一旦失去了那个节点，我们也将丢失该节点上的所有副本数据。
主分片和对应的副本分片是不会在同一个节点上的。所以副本分片数的最大值是 n -1（其中n 为节点数）。
虽然当前我们的集群是正常运行的，但是在硬件故障时有丢失数据的风险。
水平扩容既然单点是有问题的，那我们只需再启动几个节点并加入到当前集群中，这样就可以提高可用性并实现故障转移，这种方式即 水平扩容。
还以上面的 user 为例，我们新增一个节点后，新的集群如上图所示。
当第二个节点加入到集群后，3个 副本分片 将会分配到这个节点上——每个主分片对应一个副本分片。 这意味着当集群内任何一个节点出现问题时，我们的数据都完好无损。
所有新近被索引的文档都将会保存在主分片上，然后被并行的复制到对应的副本分片上。这就保证了我们既可以从主分片又可以从副本分片上获得文档。
cluster-health现在展示的状态为 green ，这表示所有6个分片（包括3个主分片和3个副本分片）都在正常运行。我们的集群现在不仅仅是正常运行的，并且还处于 始终可用 的状态。
动态扩容产品不断升级，业务不断增长，用户数也会不断新增，也许我们之前设计的索引容量（3个主分片和3个副本分片）已经不够使用了，用户数据的不断增加，每个主分片和副本分片的数据不断累积，达到一定程度之后也会降低搜索性能。那么怎样为我们的正在增长中的应用程序按需扩容呢？
我们将之前的两个节点继续水平扩容，再增加一个节点，此时集群状态如下图所示：
为了分散负载，ES 会对分片进行重新分配。Node 1 和 Node 2 上各有一个分片被迁移到了新的 Node 3 节点，现在每个节点上都拥有2个分片，而不是之前的3个。 这表示每个节点的硬件资源（CPU, RAM, I/O）将被更少的分片所共享，每个分片的性能将会得到提升。
分片是一个功能完整的搜索引擎，它拥有使用一个节点上的所有资源的能力。 我们这个拥有6个分片（3个主分片和3个副本分片）的索引可以最大扩容到6个节点，每个节点上存在一个分片，并且每个分片拥有所在节点的全部资源。
但是如果我们想要扩容超过6个节点怎么办呢？