Elasticsearch旨在始终可用并根据你的需求扩展。它是通过自然分布来实现的。您可以将服务器（节点）添加到集群以增加容量，Elasticsearch会自动在所有可用节点上分配数据和负载查询。无需大改你的应用程序，Elasticsearch知道如何平衡多节点集群以提供扩展性和高可用性。节点多多益善。
这是如何运作的呢？在幕后，Elasticsearch索引实际上只是一个或多个物理分片的逻辑分组，其中每个碎片实际上是一个独立的索引。通过在多个分片之间的索引中分配文档，并在多个节点之间分配这些分片，Elasticsearch可以确保冗余，这既可以防止硬件故障，又可以在将节点添加到集群中时提高查询能力。随着集群的增长（或收缩），Elasticsearch会自动迁移分片以重新平衡集群。
分片有两种类型：主分片和副本分片。索引中的每个文档都属于一个主分片。副本分片是主分片的副本。副本可提供数据的冗余副本，以防止硬件故障并提高处理读取请求（例如搜索或查询文档）的能力。
创建索引时，索引中主分片的数量是固定的，但是副本分片的数量可以随时更改，而不会中断索引或查询操作。
在分片大小和为索引配置的主分片数量方面，存在许多性能方面的考虑和权衡取舍。分片越多，维护这些索引的开销就越大。分片大小越大，当Elasticsearch需要重新平衡集群时，分片移动所需的时间就越长。
见机行事
在为一个索引配置分片大小和主分片数量时，存在许多性能方面的考虑和权衡取舍。分片越多，维护这些索引的开销就越大。分片大小越大，当Elasticsearch需要重平衡集群时，迁移分片所需的时间就越长。
查询很多小的分片会使每个分片的处理速度更快，但是更多的查询意味着更多的开销，因此查询较小数量的大分片可能会更快。简而言之...要见机行事。
作为出发点：
旨在将平均分片大小保持在几GB到几十GB之间。对于具有基于时间的数据的例子，通常会看到20GB到40GB范围内的分片。
避免分片过大的问题。节点可以容纳的分片数量与可用堆空间成正比。通常，每GB堆空间中的分片数量应少于20。
确定你的使用场景最佳配置的最好方法是通过使用自己的数据和查询进行测试。（https://www.elastic.co/cn/elasticon/conf/2016/sf/quantitative-cluster-sizing）
容灾
出于性能原因，群集内的节点必须位于同一网络上。跨数据中心节点的群集中的分片平衡会花费太长时间。但是高可用架构要求你不能将所有鸡蛋都放在一个篮子里。如果一个地点发生重大故障，则另一个地点的服务器需要能够无缝接管。答案？跨集群复制（CCR）。
CCR提供了一种方法，可以自动将索引从主群集同步到可作为热备份的第二群集。如果主群集发生故障，则第二群集可以接管。您还可以使用CCR创建第二群集，根据地理位置就近向用户提供读服务。
运维
对于任何商用系统，你都需要工具来保护，管理和监控Elasticsearch集群。集成到Elasticsearch中的安全，监控和管理功能使你可以将Kibana用作控制中心来管理集群。数据汇总（data rollups）和索引生命周期管理(index lifecycle management)等功能可帮助你随时智能地管理数据。
