如何规划 Elasticsearch 新集群？

当有一个新的业务准备使用 Elasticsearch，尤其是业务首次建设 Elasticsearch 集群时，往往不知道该如何规划集群大小，应该使用什么样的服务器？规划多少个节点才够用？

集群规模当然是越大越好，但是出于成本考虑，还是希望集群规模规划的尽量准确，能够满足业务需求，又有一些余量，不建议规划一个规模“刚刚好”的集群，因为当负载出现波动，或者一些其他偶然的故障时，会影响到业务的可用性，因此留一些余量出来是必要的。

1 规划数据节点规模

Elasticsearch 节点有多种角色，例如主节点，数据节点，协调节点等，默认情况下，每个节点都同时具有全部的角色。对于节点角色的规划我们将在下一个小节讨论，首先考虑一下我们需要多少个数据节点存储我们的数据。规划数据节点数量需要参考很多因素，有一些原则可以帮助我们根据业务情况进行规划。

1.1 数据总量

数据总量是指集群需要存储的数据总大小，如果每天都有新数据入库，总量随之相应地增加。我们之所以要考虑数据总量，并非因为磁盘空间容量的限制，而是 JVM 内存的限制。

为了加快搜索速度，Lucene 需要将每个段的倒排索引都加载到 JVM 内存中，因此每一个 open 状态的索引都会在 JVM 中占据一部分常驻内存，这些是 GC 不掉的，而且这部分空间占用的比较大，并且由于堆内存不建议超过 32G，在磁盘使用率达到极限之前，JVM 占用量会先到达极限。

按照我们的经验，Elasticsearch 中 1TB 的 index 大约占用 2GB 的 JVM 内存，具体和字段数据类型及样本相关，有些会更多。一般情况下，我们可以按照这个比例来做规划。如果想要精确计算，业务可以根据自己的样本数据入库 1TB，然后查看分段所占的内存大小（实际上会比 REST 接口返回的值高一些）

curl -X GET "localhost:9200/_cat/nodes?v&h=name,segments.memory"

以 1TB 数据占用 2GB 内存，JVM 堆内存配置 31G ，垃圾回收器 CMS 为例，新生代建议配置 10G，old 区 21G，这 21G 内存分配一半给分段内存就已经很多了，想想看还没有做任何读写操作时 old 区就占用了一半，其他几个内存大户例如 bulk 缓冲，Query 缓存，indexing buffer，聚合计算等都可能会使用到 old 区内存，因此为了保证节点稳定，分段内存不超过 10G 比较好，换算成索引数据量为5TB。

因此，我们可以按照单个节点打开的索引数据总量不超过 5TB 来进行规划，如果预计入库 Elasticsearch 中的数据总量有 100TB 的数据（包括副分片所占用空间），那么数据节点的数量至少应该是: 100/5=20，此外出于冗余方面的考虑，还要多加一些数据节点。冗余节点的数量则和日增数据量以及故障转移能力相关。

可以看出这样规划出来的节点数是相对比较多的，带来比较高的成本预算。在新的 6.7 及以上的版本 Elasticsearch 增加了冻结索引的特性，这是一种冷索引机制，平时他可以不占内存，只有查询的时候才去加载到内存，虽然查询慢一些，但是节点可以持有更多的数据总量。

因此，如果你想要节点存储更多的数据量，在超出上述原则后，除了删除或 close 索引之外，一个新的选择是将它变成冻结状态。

《高可用 Elasticsearch 集群 21 讲》。

1.2 单个节点持有的最大分片数量

单个节点可以持有的最大分片数量并没有明确的界限，但是过多的分片数量会造成比较大的管理压力，官方给出的建议是，单个节点上所持有的分片数按 JVM 内存来计算：每 GB 的内存乘以 20。例如 JVM 内存为 30GB，那么分片数最大为：30*20=600个。当然分片数越少会越稳定。

但是使用这个参考值也会有些问题，当分片大小为 40GB 时，节点所持有的数据量为：40 * 600 = 24TB，按照 1TB 数据量占用 2GB JVM 内存来计算，所占用 JVM 内存为：24 * 2 = 48GB，已经远超 JVM 大小，因此我们认为一般情况下不必将单个节点可以持有的分片数量作为一个参考依据，只需要关心一个原则：让 JVM 占用率和 GC 时间保持在一个合理的范围。

考虑另一个极端情况，每个分片的数据量都很小，同样不必关心每个节点可以持有多少，对大量分片的管理属于主节点的压力。一般情况下，建议整个集群的分片数量建议不超过 10 万。

2 规划集群节点角色

一个 Elasticsearch 节点默认拥有所有的角色，分离节点角色可以让集群更加稳定，尤其是更加注重稳定性和可用性的在线业务上，分离节点角色是必要的。

2.1 使用独立的主节点

集群有唯一的活跃主节点，他负责分片管理和集群管理等操作，如果主节点同时作为数据节点的角色，当活跃主节点失效的时候，例如网络故障，硬件故障，新的主节点当选后需要重新分配原主节点上持有的分片数据，导致集群在一段时间内处于 RED 和 YELLOW 状态。而独立部署的主节点不需要这个过程，新节点当选后集群可以迅速 GREEN。

另外，由于数据节点通常有较大的内存占用，GC 的影响也会导致混合部署的工作受到影响。因此如果集群很在意稳定性和可用性，我们建议数据节点有 3 个及以上时，应该独立部署 3 个独立的主节点，共 6 个节点。

2.2 使用独立的协调节点

有时候，你无法预知客户端会发送什么样的查询请求过来，也许他会包括一个深度聚合，这种操作很容易导致节点 OOM，而数据节点离线，或者长时间 GC，都会对业务带来明显影响。

亦或者客户端需要进行许多占用内存很多的聚合操作，虽然不会导致节点 OOM，但也会导致节点 GC 压力较大，如果数据节点长时间 GC，查询延迟就会有明显抖动，影响查询体验。

此时最好的方式就是让客户端所有的请求都发到某些节点，这种节点不存储数据，也不作为主节点，即使 OOM 了也不会影响集群的稳定性，这就是仅查询节点（Coordinating only node）。

2.3 使用独立的预处理节点

Elasticsearch 支持在将数据写入索引之前对数据进行预处理、内容富化等操作，这通过内部的 processor 和 pipeline 实现，如果你在使用这个特性，为了避免对数据节点的影响， 我们同样建议将他独立出来，让写请求发送到仅预处理节点。

独立节点的各个角色后的集群结构如下图所示，其中数据节点也是独立的。

如果没有使用预处理功能，可以将读写请求都发送到协调节点。另外数据写入过程最好先进入 Kafka 之类的 MQ，来缓冲一下对集群的写入压力，同时也便于对集群的后期维护。

总结

本文介绍了如何规划集群节点数和集群节点角色，依据这些原则进行规划可以较好的保证集群的稳定性，可以适用于组件新集群时评估集群规模，以及在现有集群接入新业务时对集群资源的评估。

关于索引和分片的规划将在后续章节中介绍。

为了方便学习和技术交流，创建了高可用 Elasticsearch 集群的读者群，入群方式在第 1-3 课，欢迎已购课程的同学入群交流。

点击了解《高可用 Elasticsearch 集群 21 讲》。