Elasticsearch容量规划-干货

前言

当客户或者业务咨询您一套Elasticsearch该如何搭建的时候，您脑海中闪过的第一个想法是啥？业务数据量有多大,eps峰值是多少，业务场景是啥....本文将详细介绍从下到上改如何规划一套Elasticsearch集群。

节点角色规划

谈到Elasticsearch规划，首先提到的是节点角色规划，而要了解节点角色规划则需要介绍Elasticsearch每种角色的作用，让我们看下这些角色。

Master主节点: 主要负责集群元数据(Cluster State)管理和分发

Data数据节点: 主要负责数据存储和数据读写请求处理

Coordinate协调节点: 主要负责请求转发

Ingest预处理节点: 主要负责对数据进行处理转换

ML机器学习节点: 负责跑机器学习Job，用来做异常检测

如果你是使用默认的Elasticsearch node，那它将拥有全部的角色

Elasticsearch node

同样，当一套Elasticsearch 集群大于9个节点时有几个有用的建议：1.使用独立的主节点；2.使用独立的协调节点；3.使用独立的预处理节点。下面则是我给出这三个建议的理由：

使用独立的主节点:集群状态信息管理和数据读写分开

使用独立的协调节点:分摊data节点压力

使用独立的预处理节点: 一定程度上可以替代 Logstash ,如果采用logstash进行数据预处理，则此步骤可忽略

节点硬件配置

讲完节点角色规划，肯定离不了节点的硬件配置。

1.内存磁盘比

比如内存 64GB，磁盘 2TB，那么内存 : 磁盘=64 : 2048=1 : 32

搜索类场景一般建议控制在 1:16

日志类场景热节点 1:32

冷节点可以 1:96

针对每种角色的配置如下：

Master 节点：

CPU 4Core/Memory 8GB( Heap 4~6GB )/Disk 10GB

Data 节点：

热节点(处理写请求的节点)，CPU 16Core/Memory 64GB( Heap 30GB )/Disk 2~4TB

冷节点(只处理读请求的节点)，CPU 8Core/Memory 64GB( Heap 30GB )/Disk 6~10TB

磁盘介质

SSD 好于 HDD，多块磁盘时建议做磁盘阵列，提升读写性能，阵列上RAID 0 > RAID50 > RAID5 ，当然有钱可以用RAID10,但是RAID0是不建议使用的，为什么呢？磁盘维护成本太高了，特别是日志云hot节点。由于磁盘读写速率很高，平均每周会坏一块磁盘（特指某想品牌的磁盘）。下面这个图是所有节点配置的官网参考图，可以借鉴一下哈。

硬件配置图

数据节点数规划

1.以数据总量规划

单个节点数据量内存限制。根据官网介绍，单个节点最大内存不能超过32GB，正常我们也就设置30GB左右的内存。以CMS垃圾回收器为例，新生代建议配置10GB，old区20GB，这20GB内存分配一般给分段内存就已经很多了，想想看，还没有做任何读写操作时old区就占用了一般，其他几个内存大户例如bulk缓冲，Query缓冲，indexing buffer,聚合计算等都会使用到old区，又由于1TB 的数据大约占用 2GB 的 JVM 内存,实际情况和数据字段数目、类型等相关。综合考虑，单个节点数据量为5TB左右是比较合适的，当然g1的垃圾回收器对这方面优势比较明显，在ES7.0后默认也是g1的垃圾回收器，这个可以按照实际生产测试数据为准。

下面是查看segments对应内存的接口

GET /_cat/nodes?v&h=name,segments.memory

segments占用内存图

那如何估算数据存入 ES 后的数据量，举个例子：假设数据每天新增 500GB，要求留存 1 个月。可按照如下公式估算：

500GB(每天新增数据量)*1.3(索引膨胀率)*2(副本)*30(留存时长)*1.3(磁盘预留 30% 空间)=50700GB=50TB

假设我们按照单个节点 16Core/64GB/2TB 计算，那么需要的数据节点数为 50TB/2TB=25。

2.以数据写入速率规划

当规划一套ES集群的时候，需要问业务两个问题，1.需要支撑的最大数据写入速率是多少?2.单节点可以支撑的最大数据写入速率是多少?而这两个问题得到的计算公式如下：

假设需要支撑的最大数据写入速率是 50 万 eps，单节点可以支撑的最大数据写入速率是 4 万 eps，
那么所需的数据节点数目=50/4=13

3.以单个节点持有的最大分片数量规划

根据官方解释，从Elasticsearch v7.0.0 开始，集群中的每个节点默认限制 1000 个shard(包含主分片,副本,未分配分片,关闭索引的分片不计入此限制)，如果你的es集群有3个数据节点，那么最多 3000 shards。

当然还有一种官方建议是这样的，单个节点所持有的分片按照JVM内存来计算：每GB的内存乘以20，例如JVM为30GB，那么分片最大为30*20=600个。

其实按照这两种官方参考值来看都是有些问题的，假设每个分片30GB，单个节点所持有的的数据量为:30 * 600 =18TB,按照1TB数据量占用2gb的jvm来计算，所占用的jvm大小为：18*2=36GB，已经远远大于jvm大小。所以这个分片以单个节点可以持有的分片数量作为参考依据其实很鸡肋。我们主要关心的应该是jvm占用率要跟GC时间保持在一个合理的范围。

但是从极端的角度来看，集群的分片总量还是有用的，每个分片如果数据量很小，最终的瓶颈就落在了master节点上，所以从理论上建议单个集群分片数据量不要超过10w。

4.ES节点架构图

对于大的日志系统来说，ES的架构基本上都是如下方所涉及，为什么不涉及warm节点呢？当节点超过100个之后，你会发现master节点压力是很大的，这个时候建议将warm节点变成cold节点，这样数据可以存放更多。

ES架构图

总结

本文介绍了集群节点角色、节点硬件配置和集群节点数三个方面，依据这些原则进行规划可以更好地保证集群的稳定性，可以适用于组建新集群是评估集群规模以及现有集群扩容的资源评估。

参考资料

https://www.elastic.co/guide/en/elasticsearch/reference/7.13/modules-cluster.html