Elasticsearch被设计为高可用，并且可以根据你的需求进行扩展。通过自然分布来实现这一点。你可以增加节点Elasticsearch会自动把你的数据和查询请求负载到所有可用的节点上。不需要修改你的应用程序，Elasticsearch知道如何平衡多节点集群来提供伸缩性和高可用。

这是怎么实现的？在底层，一个Elasticsearch索引是一个或多个物理分片的逻辑分组，每个分片是一个自我包含的索引。将文档分布在多个分片的相同索引上，又把分片分布在多个节点上，Elasticsearch可以冗余数据，这样可以避免硬件故障，当节点的加入集群时，查询能力也能随着增加。随着集群的增长或者减少，Elasticsearch可以自动迁移分片使集群重新平衡。

Elastcisearch有两种类型的分片：主分片和复制分片。索引中的每一个文档都属于一个分片。复制分片是主分片的备份。复制分片冗余数据来避免硬件故障同时也增加了服务的查询能力，比如搜索或者检索一个文档。

索引的主分片数量只能索引创建时指定。但是复制分片的数量可以在任何时候修改，并且不会影响索引和查询操作。

这取决于…

对一个索引设置分片数量和分片容量大小，有很多性能和权衡的需要考虑。分片数越多，维护这些索引的开销也就越大。分片的容量越大，当Elasticsearch平衡集群移动分片时所花费的时间也越多。

对大量的小容量分片进行查询，每个分片的查询速度是很快的，但是查询请求越多，开销也就越大。这就意味着对小数量、大容量的分片进行查询，速度可能会快一点。简而言之…视情况而定。

一开始的注意点：
平均每个分片的容量保持在几GB到几十GB之间。对于时间序列化的数据，一般建议在20GB到40GB之间。
避免大量分分片问题，一个节点所能支持的分片数量是跟可用对空间成正比的。一般而言，每GB可用堆空间的分片数量应小于20.

为你的应用场景选择最佳的配置的最好方式是测试你的数据和查询请求。

容灾

出于性能的考虑，集群中的节点需要处于同一网络。在一个横跨不同数据中心的集群中平衡分片花费时间太长了。但是高可用的设计架构强烈要求避免“把鸡蛋都放在一个篮子里”。如果一个区域停电，那么其它区域的服务需要无缝的接管。解决方案？跨集群复制-Cross-cluster replication (CCR).

CCR提供了一种方法，可以自动把你的主集群中索引同步到远程副本集群。如果主集群挂了，备用集群可以接管。你也可以使用CCR来创建副本集群以服务那些在地理位置接近的用户请求。

跨集群复制-Cross-cluster replication是主动的也是被动的。主集群上的索引是leader（领导）索引，处理所有写请求。副本上的索引是只读的followers（追随者）。

监控和管理

与其它企业系统一样，你都需要工具来保护、管理和监控你的Elasticsearch集群。安全、可监控、管理的特性也集成到了Elasticsearch，你可以使用Kibana作为管理集群的控制中心。像数据归档和索引生命周期这些特性能帮你随时智能化的管理你的数据。