探究Elasticsearch集群规模和容量规划的底层逻辑

作者: OzanShareing | 来源:发表于2020-04-01 21:43 被阅读0次

引言

实战中经常遇到的问题：

问题 1：请问下大家是如何评估集群的规模？比如数据量达到百万，千万，亿万，分别需要什么级别的集群，这要怎么评估？

ps：自己搭建的测试环境很难达到这一级别。

问题 2：

问题 3：我看了很多文章关于 es 集群规划的文章，总感觉乱七八糟的，没有一个统一的规划思路。如何根据硬件条件和数据量来规划集群，设置多少节点，每个节点规划多少分片和副本？

Elasticsearch 集群规模和容量规划：是进行 Elasticsearch 集群部署前对所需资源类型和数量的规划。

通过本文，您将了解：

Elasticsearch 计算资源详解
Elasticsearch 架构、增删改查操作和资源需求
Elasticsearch 集群规模和容量规划的方法论

1、Elasticsearch 基础架构

1.1 自顶向下的架构体系

Cluster—协同工作的节点组，以保障 Elasticsearch 的运行。
Node—运行 Elasticsearch 软件的 Java 进程。
Index—一组形成逻辑数据存储的分片的集合。
Shard—Lucene 索引，用于存储和处理 Elasticsearch 索引的一部分。
Segment—Lucene 段，存储了 Lucene 索引的一部分且不可变。
Document—条记录，用以写入 Elasticsearch 索引并从中检索数据。

1.2 节点角色划分及资源使用情况

角色	描述	存储	内存	计算	网络
数据节点	存储和检索数据	极高	高	高	中
主节点	管理集群状态	低	低	低	低
Ingest 节点	转换输入数据	低	中	高	中
机器学习节点	机器学习	低	极高	极高	中
协调节点	请求转发和合并检索结果	低	中	中	中

划重点：对资源利用率拿不准的，多结合业务实际看看这个表格。

2、维系 Elasticsearch 高性能的资源组成

4 个基本的计算资源存储、内存、计算、网络

2.1 存储资源

2.1.1 存储介质

固态硬盘（SSD）提供最佳“热”工作负载的性能。
普通磁盘（HDD）成本低，用于“暖”和“冷”数据存储。

注意：RAID0 可以提高性能。RAID 是可选的，因为 Elastic 默认为 N + 1 分片复制策略。

为了追求硬件级别的高可用性，可以接受标准性能的 RAID 配置（例如 RAID 1/10/50 等）。

2.1.2 存储建议

建议直接使用：附加存储（DAS）、存储区域网络（SAN）、超融合存储（建议最低〜3Gb / s，250Mb / s）
避免使用：网络附加存储（NAS）
例如 SMB，NFS，AFP。使用时可能带来的性能问题：网络协议的开销，延迟大和昂贵的存储抽象层。

2.2 内存资源

2.2.1 JVM Heap

存储有关集群索引、分片、段和 fielddata 数据。

建议：可用 RAM 的 50％，最多最大 30GB RAM，以避免垃圾回收。

官方文档最大指 32 GB：

https://www.elastic.co/guide/en/elasticsearch/guide/master/heap-sizing.html

2.2.2 操作系统缓存

Elasticsearch 将使用剩余的可用内存来缓存数据（Lucene 使用），通过避免在全文检索、文档聚合和排序环节的磁盘读取，极大地提高了性能。

2.3 计算资源

Elasticsearch 如何使用计算资源？

Elasticsearch 处理数据的方式多种多样，但计算成本较高。

可用的计算资源：线程池、线程队列。

CPU 内核的数量和性能：决定着计算平均速度和峰值吞吐量。

2.4 网络资源

Elasticsearch 如何使用网络？小带宽是限制 Elasticsearch 的资源。

针对大规模集群，ingest、搜索和副本复制相关的数据传输可能会导致网络饱和。

在这些情况下，网络连接可以考虑升级到更高的速度，或者 Elastic 部署可以分为两个或多个集群，然后使用跨集群（CCS）作为单个逻辑单元进行搜索。

3、数据增删改查操作

增、删、改、查是 Elasticsearch 中的四个基本数据操作。

每个操作都有其自己的资源需求。每个业务用例都利用其中一个操作，实际业务往往会侧重其中一个或多个操作。

增：新增索引处理文档并将其存储在索引中，以备将来检索。
删：从索引中删除文档。
改：更新删除文档并为其替换的新文档建立索引。
查：搜索从一个或多个索引中检索或聚合一个或多个文档。

3.1 增/索引数据处理流程

如图所示，增/索引数据大致的处理流程如下：

1、客户端发起写入请求到协调节点；
2、协调节点根据请求类型的不同进行判断，如果是 Ingest 相关，提交给 Ingest 节点；如果不相关，则计算路由后提交给数据节点；
3、数据节点根据数据类型不同决定是否分词以索引化数据，最终落地磁盘存储；同时将副本分发给其他数据节点。

3.2 删除数据处理流程

如果所示，删除数据大致处理流程如下：

1、客户端发出删除文档请求到协调节点；
2、协调节点将请求路由给数据节点；
3、数据节点接收到请求后，将数据标记为 deleted 状态（注意，此处为逻辑删除）
4、待段合并时机，逻辑删除会变成物理删除。

3.3 更新数据处理流程

文档在 Elasticsearch 中是不可变的。当 Elasticsearch 更新文档时，它将删除原始文档并为新的待更新的文档建立索引。

这两步操作在每个 Lucene 分片是原子操作，操作会带来删除和索引（索引不调用任何 ingest pipeline 操作）操作的开销。

Update = Delete + (Index - Ingest Pipeline）

3.4 检索操作处理流程

“搜索”是信息检索的通用术语。Elasticsearch 具有多种检索功能，包括但不限于全文搜索、范围搜索、脚本搜索和聚合。

搜索速度和吞吐量受许多因素影响，包括集群的配置、索引、查询和硬件。

实际的容量规划取决于应用上述优化配置后的大量测试实践结果。

Elasticsearch 检索可以细化分为：scatter（分散）、 search（检索）、gather（收集）、merge（合并）四个阶段。

scatter：将结果分发给各个相关的分片；
search：在各个分片执行检索；
gather：数据节点将检索结果汇集到协调节点；
merge：协调节点将数据结果进行合并，返回给客户端。

3.5 用例场景

Elasticsearch 有一些常规的使用模式。大致可分类如下：

写索引（Index）密集型的业务场景：Logging, Metrics, Security, APM
检索（search）密集型的业务场景：App Search, Site Search, Analytics
更新（update）密集型的业务场景：Caching, Systems of Record
混合（hybrid）业务场景：支持多种操作的混合用例 Transactions Search

4、Elasticsearch 索引化流程

4.0 概述

以下过程适用于 ingest 节点处理数据流程。

Json 数据转换——结构化或非结构化数据，转换为json 落地存储。
数据索引化——数据以不同数据类型进行处理和索引。
数据压缩——提高存储效率。
副本复制——提高容错能力和搜索吞吐量。

4.1 Json 转换

结构化或非结构化数据转换成 json 格式，可通过_source 控制是否展示。

4.2 数据索引化

第一：数据结构 Elasticsearch 索引各种数据结构中的值。每种数据类型有自己的存储特性。

第二：多种索引方法某些值可以通过多种方式索引。字符串值通常是索引两次（借助 fields 实现）。

一次作为聚合的 keyword 类型；
一次作为文本用于全文搜索的 text类型。

4.3 数据压缩

Elasticsearch 可以使用两种不同的压缩算法之一来压缩数据：LZ4（默认）和 DEFLATE。

与 LZ4 相比，DEFLATE 节省了多达 15％的额外空间，但以增加的计算时间为代价。

通常，Elasticsearch 可以将数据压缩 20 – 30％。

4.4 副本分片拷贝

第一：存储 Elasticsearch 可以在数据节点之间复制分片一次或多次，以提高容错能力和搜索吞吐量。

每个副本分片都是其主分片的完整副本。

第二：索引和搜索吞吐量

日志记录和指标用例场景（Logging and metrics）通常具有一个副本分片，这是确保出现故障的最小数量，同时最大程度地减少了写入次数。
搜索用例通常具有更多的副本分片以提高搜索吞吐率。

4.5 完整示例

5、集群规模和容量规划预估方法

容量规划——预估集群中每个节点的分片数、内存及存储资源。

吞吐量规划——以预期的延迟和吞吐量估算处理预期操作所需的内存，计算和网络资源。

5.1 数据量预估

第一，问自己几个问题：

您每天将索引多少原始数据（GB）？
您将保留数据多少天？
每天增量数据是多少？
您将强制执行多少个副本分片？
您将为每个数据节点分配多少内存？
您的内存：数据比率是多少？

第二，预留存储以备错误。(Elastic 官方推荐经验值）

预留 15%警戒磁盘水位空间。
为错误余量和后台活动预留+ 5％。
保留等效的数据节点以处理故障。

第三，容量预估计算方法如下：

总数据量（GB） = 原始数据量（GB） /每天 X 保留天数 X 净膨胀系数 X （副本 + 1）
磁盘存储（GB） = 总数据量（GB）* ( 1 + 0.15 + 0.05)
数据节点 = 向上取正（磁盘存储（GB）/ 每个数据节点的内存量 / 内存：数据比率）+ 1

Tips：腾讯云在 2019 4 月的 meetup 分享中建议：磁盘容量大小 = 原始数据大小 * 3.38。

5.2 分片预估

第一，问自己几个问题：

您将创建多少索引？
您将配置多少个主和副本分片？
您将在什么时间间隔旋转索引？
您将保留索引多长时间？
您将为每个数据节点分配多少内存？

第二，经验值（Elastic 官方推荐）

每 GB JVM 堆内存支持的分片数不超过 20 个。
每个分片大小不要超过 50GB。推荐阅读：https://www.elastic.co/cn/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster

Tips：

将小的每日索引整合为每周或每月的索引，以减少分片数。
将大型（> 50GB）每日索引分拆分成小时索引或增加主分片的数量。

第三，分片预估方法如下：

总分片数 = 索引个数 X 主分片数 * （副本数 +1）X 保留间隔
总数据节点个数 = 向上取整（总分片数 / (20 X 每个节点内存大小））

5.3 搜索吞吐量预估

搜索用例场景除了考虑搜索容量外，还要考虑如下目标：

搜索响应时间；
搜索吞吐量。

这些目标可能需要更多的内存和计算资源。

第一：问自己几个问题

您期望每秒的峰值搜索量是多少？
您期望平均搜索响应时间是多少毫秒？
您期望的数据节点上几核 CPU，每核有多少个线程？

第二：方法论

与其确定资源将如何影响搜索速度，不如通过在计划的固定硬件上进行测量，可以将搜索速度作为一个常数，然后确定集群中要处理峰值搜索吞吐量需要多少个核。

最终目标是防止线程池排队的增长速度超过了 CPU 的处理能力。

如果计算资源不足，搜索请求可能会被拒绝掉。

第三：吞吐量预估方法

峰值线程数 = 向上取整（每秒峰值检索请求数 _ 每个请求的平均响应时间（毫秒）/1000）
线程队列大小 = 向上取整（(每个节点的物理 cpu 核数 _ 每核的线程数 * 3 / 2）+ 1)
总数据节点个数 = 向上取整（峰值线程数 / 线程队列大小）

5.4 冷热集群架构

Elasticsearch 可以使用分片分配感知（shard allocation awareness）在特定硬件上分配分片。

索引密集型业务场景通常使用它在热节点、暖节点和冷（Frozen）节点上存储索引，然后根据业务需要进行数据迁移（热节点->暖节点->冷节点），以完成数据的删除和存档需要。

这是优化集群性能的最经济方法之一，在容量规划期间，先确定每一类节点的数据规模，然后进行组合。

冷热集群架构推荐：

节点类型	存储目标	建议磁盘类型	内存/磁盘比率
热节点	搜索优化	SSD DAS / SAN（> 200Gb / s）	1:30
暖节点	存储优化	HDD DAS / SAN（〜100Gb / s）	1:160
冷节点	归档优化	最便宜的 DAS / SAN（<100Gb / s）	1:1000+

5.5 集群节点角色划分

Elasticsearch 节点执行一个或多个角色。通常，当集群规模大时，每个节点分配一个具体角色很有意义。

您可以针对每个角色优化硬件，并防止节点争夺资源。

同2.2 章节。不再赘述。

6 小结

集群规模和容量规划的底层逻辑涉及到：

Elasticsearch 的基础架构
维系 Elasticsearch 高效运转的计算资源（CPU、内存、磁盘、网络）
Elasticsearch 增删改查的业务流程及资源耗费情况
Elasticsearch 数据索引化的核心流程基于以上四点的整合，才有了：集群规模和容量规划预估方法。

评估所需资源需要执行以下步骤：

步骤1：确定集群的节点类型；
步骤2：对于不同节点类型（热，暖，冷），确定以下规模的最大值：

数据量
分片数量
索引吞吐量
搜索吞吐量

步骤3：合并每一类型节点所需资源大小。注意：在任何专用节点上做出决策-主节点、协调节点、机器学习节点、路由节点。

注：这是 Elastic 官方 2019 年 11 月份的视频内容的详细梳理。

推荐看一遍视频

摘自探究 | Elasticsearch集群规模和容量规划的底层逻辑一文