关于ES集群规模规划-Toy模板网

这篇具有很好参考价值的文章主要介绍了关于ES集群规模规划。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

在搭建正式的生产集群之前，充分做好硬件和服务器配置以及集群规划是重中之重，磨刀不误砍柴工。

硬件配置推荐

内存

ES排序以及聚合都是高度需求内存的。单机（单节点）64GB是很理想的配置，32GB或16GB也很常见。

不推荐低于8GB，性价比较低，适得其反（很多的小机器也不划算）。

JVM 堆内存：存储关于集群、索引、分片、段和 Fielddata 的元数据。该项较为理想的设置是可用 RAM 的 50%。所以上面的 64GB 内存并不是直接分给ES的 heapsize。

【重要】ES_HEAP_SIZE这个值最大设置30GB，其余的留给OS，因Lucene还要使用 off heap并依赖系统缓存。

Lucene被设计为利用底层操作系统来缓存内存数据结构。Lucene段被存储在单个文件中。因为段是不可变的，这些文件永远不会改变，这使得它们对缓存非常友好.

CPU

多数情况下ES部署对CPU的要求不高。选择现代处理器，2~8核心的机器即可。

在更快的CPU和很多核心之间做选择时，请选择多核。多核心提供的额外并发性的受益远超时钟频率。

现代乱序执行多核向量处理器具有指令级并行技术、向量化SIMD、线程级并行技术、缓存层次及NUMA等许多和代码性能优化相关的特点。

硬盘

磁盘对集群非常重要，在“重写”（write-heavy）场景下最慢的磁盘会成为性能瓶颈。

如果不差钱，SSD优于其他任何旋转存储介质，对查询和索引的性能都有可观的提升。

对全闪存，记得修改IO调度算法为noop、deadline或者none，这可能有奇效。

如果是HDD旋转介质，转速大于15k最好。

建议尽可能使用 SSD，特别是那些运行搜索和索引操作的节点。由于 SSD 存储的成本较高，建议使用热温架构来减少支出。在热数据节点上使用SSD，冷数据节点可以使用HDD。

可以使用RAID 0可以增加磁盘读写速度，不建议用其他RAID方案，Elasticsearch 不需要冗余存储（无需 RAID 1/5/10），日志索引通常至少要有一个副本分片。

不要使用NAS！（官方吐糟，NAS王婆卖瓜自卖自夸，名不副实。）

网络

现代数据中心的千兆和万兆网卡（1 GbE, 10 GbE）网络已经够用，只有个别老旧机房的百兆网显得窘迫。

避免跨数据中心部署ES集群，即使他们被托管在很近的地方。

绝对避免集群跨越很远的地理距离。

集群规划

节点数计算公式

官方有较为清晰的依据容量的计算公式，但是没有什么规则是一成不变的。ES用于广泛的任务且被部署在各种各样的机器上，遵从以下建议是一个良好的开端。

按数据量确定集群规模，需要先确定以下问题的答案：

每天将索引多大的原始数据量（GB）？= Q
数据要保留多少天？= S
强制执行多少个副本分片？= R
内存数据量比率 = 1 : 30 ?

节点数N计算公式：

原始数据总量D1（GB）= Q * S * ( R + 1 )
存储所需容量D2（GB）= D1 * (1 + 0.15磁盘水位阈值 + 0.1误差幅度)
数据节点总数N = CEIL（D2/RAM/30）+ 1

解释：

在确定规模时，我们一般会增加 5% 或 10% 来容纳误差（取0.1），并增加 15% 以保持在磁盘水位线之下。
在大规模部署的情况下，添加一个节点用于故障转移容量会更安全，一般取奇数。
30是内存与数据容量比率，根据用途与性能要求可以调整为30~180。
实际上在计算原始数据总量时还要考虑膨胀系数。参考传送门→

多节点

如果你必须在一台机器上运行多个节点（因为单台机器资源充足,可以部署多个ES节点实例），会增加运维的复杂性，资源利用不均衡的问题也会偶现。虽然一台512GB的机器足够同时运行8个ES的节点（仅需480GB内存），但据压测和经验，最好不要超过6个，尤其是磁盘读写性能一般的时候，单台机器部署多节点的ES性能颇受掣肘，甚至会造成节点短暂地掉线。

根据前述计算公式所需物理机数为：CEIL(N/单机节点数)