【ES专题】ElasticSearch集群架构剖析_es集群(1)_elasticsearch 主集群 副集群

2. 每个节点各有一个主副分片

高可用之——故障转移

3. 主副分片之间交叉存储（node1的副本放在node3，node2放在node1，node3放在node2）

使用【cat API查看集群信息】

• GET /_cat/nodes?v #查看节点信息
• GET /_cat/health?v #查看集群当前状态：红、黄、绿
• GET /_cat/shards?v #查看各shard的详细情况
• GET /_cat/shards/{index}?v #查看指定分片的详细情况
• GET /_cat/master?v #查看master节点信息
• GET /_cat/indices?v #查看集群中所有index的详细信息
• GET /_cat/indices/{index}?v #查看集群中指定index的详细信息 `

1.3 搭建三节点ES集群

1.3.1 ES集群搭建步骤

下面是在Linux环境，centos7下面的集群搭建步骤：
1）系统环境准备
首先创建用户，因为es不允许root账号启动

adduser es
passwd es

1
2
3

安装版本：elasticsearch-7.17.3。接着切换到root用户，修改/etc/hosts：

vim  /etc/hosts
192.168.66.150 es-node1  
192.168.66.151 es-node2  
192.168.66.152 es-node3  

1
2
3
4
5

2）修改elasticsearch.yml
注意配置里面的注释，里面有一些细节。比如：

1. 注意集群的名字，3个节点的集群名称必须一直
2. 给每个节点指定名字，比如这里是node1/2/3
3. 是否要开启外网访问，跟redis的配置差不多

# 指定集群名称3个节点必须一致
cluster.name: es-cluster
#指定节点名称，每个节点名字唯一
node.name: node-1
#是否有资格为master节点，默认为true
node.master: true
#是否为data节点，默认为true
node.data: true
# 绑定ip,开启远程访问,可以配置0.0.0.0
network.host: 0.0.0.0
#用于节点发现
discovery.seed_hosts: ["es-node1", "es-node2", "es-node3"]
#7.0新引入的配置项,初始仲裁，仅在整个集群首次启动时才需要初始仲裁。
#该选项配置为node.name的值，指定可以初始化集群节点的名称
cluster.initial_master_nodes: ["node-1","node-2","node-3"]
#解决跨域问题
http.cors.enabled: true
http.cors.allow-origin: "\*"

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

三个节点配置很简单，按照上面的模板，依次修改node.name就行了

3) 启动每个节点的ES服务

# 注意：如果运行过单节点模式，需要删除data目录， 否则会导致无法加入集群
rm -rf data
# 启动ES服务
bin/elasticsearch -d 

1
2
3
4
5

4）验证集群
正常来说，如果我们先启动了192.168.66.150，那么它就是这个集群当中的主节点，所以我们验证集群的话，只需要访问http://192.168.66.150:9200即可看到如下界面：

1.3.2 安装客户端

介绍完了ES的集群部署，我们再来看看ES客户端的部署。这里有两个可选方案，它们分别是Cerebro和Kibana，它们的区别与联系如下：

Cerebro和Kibana都是用于Elasticsearch的开源工具，但它们在功能和使用场景上存在一些区别。

功能：

• Cerebro：Cerebro是Elasticsearch的图形管理工具，可以查看分片分配和执行常见的索引操作，功能集中管理alias和index template，十分快捷。此外，Cerebro还具有实时监控数据的功能。
• Kibana：Kibana是一个强大的可视化工具，可以用于Elasticsearch数据的探索、分析和展示。它提供了丰富的图表类型，包括折线图、直方图、饼图等，可以方便地展示基于时间序列的数据。此外，Kibana还提供了日志管理、分析和展示的功能

使用场景：

• Cerebro：Cerebro适合用于生产和测试环境的Elasticsearch集群管理，尤其适用于需要快速查看和执行索引操作的情况。由于Cerebro轻量且适用于实时监控，它可能更适用于较小的集群和实时监控的场景。
• Kibana：Kibana适合对Elasticsearch数据进行深入的分析和探索，以及对日志进行管理和分析。它提供了丰富的可视化功能和灵活的数据展示方式，适用于各种规模的数据分析和监控场景。

Cerebro安装
Cerebro 可以查看分片分配和通过图形界面执行常见的索引操作，完全开源，并且它允许添加用户，密码或 LDAP 身份验证问网络界面。Cerebro 基于 Scala 的Play 框架编写，用于后端 REST 和 Elasticsearch 通信。 它使用通过 AngularJS 编写的单页应用程序（SPA）前端。
安装包下载地址如下：https://github.com/lmenezes/cerebro/releases/download/v0.9.4/cerebro-0.9.4.zip

下载安装之后，用以下命令启动即可：

cerebro-0.9.4/bin/cerebro

#后台启动
nohup bin/cerebro > cerebro.log &

1
2
3
4
5

访问：http://192.168.66.150:9000/

输入ES集群节点：http://192.168.66.150:9200，建立连接。然后会出现以下界面：

kibana安装
1）修改kibana配置

vim config/kibana.yml

server.port: 5601
server.host: "192.168.66.150" 
elasticsearch.hosts: ["http://192.168.66.150:9200","http://192.168.66.151:9200","http://192.168.66.152:9200"]  
i18n.locale: "zh-CN"   

1
2
3
4
5
6
7

2）运行Kibana

#后台启动
nohup  bin/kibana &

1
2
3

3）访问
访问http://192.168.66.150:5601/验证

二、生产环境最佳实践

2.1 一个节点只承担一个角色的配置

我们在上面的介绍中知道，节点有多种不同的类型（角色），有：Master eligible / Data / Ingest / Coordinating /Machine Learning等。不过跟之前学习的各种集群架构不同的是，ES一个节点可承担多种角色。
不过，在生产环境中尽量还是一个节点一种角色比较好，优点是：极致的高可用；缺点是：可能有点费钱
想要一个节点只承担一个角色，只需要修改如下配置：

#Master节点
node.master: true
node.ingest: false
node.data: false

#data节点
node.master: false
node.ingest: false
node.data: true

#ingest 节点
node.master: false
node.ingest: true
node.data: false

#coordinate节点
node.master: false
node.ingest: false
node.data: false

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

2.2 增加节点水平扩展场景

在实际生产中，我们可能会遇到需要水平扩展容量的场景，通常来说，以下是几个常见的场景：

• 当磁盘容量无法满足需求时，可以增加数据节点
• 磁盘读写压力大时，增加数据节点
• 当系统中有大量的复杂查询及聚合时候，增加Coordinating节点，增加查询的性能

2.3 异地多活架构

下面是一个多集群架构。集群处在三个数据中心，数据三写，使用GTM分发读请求

全局流量管理（GTM）和负载均衡（SLB）的区别：
GTM 是通过DNS将域名解析到多个IP地址，不同用户访问不同的IP地址，来实现应用服务流量的分配。同时通过健康检查动态更新DNS解析IP列表，实现故障隔离以及故障切换。最终用户的访问直接连接服务的IP地址，并不通过GTM。
而 SLB 是通过代理用户访问请求的形式将用户访问请求实时分发到不同的服务器，最终用户的访问流量必须要经过SLB。 一般来说，相同Region使用SLB进行负载均衡，不同region的多个SLB地址时，则可以使用GTM进行负载均衡。

2.4 Hot & Warm 架构

热节点存放用户最关心的热数据；温节点或者冷节点存放用户不太关心或者关心优先级低的冷数据或者暖数据。
它的典型的应用场景如下：
在成本有限的前提下，让客户关注的实时数据和历史数据硬件隔离，最大化解决客户反应的响应时间慢的问题。业务场景描述：每日增量6TB日志数据，高峰时段写入及查询频率都较高，集群压力较大，查询ES时，常出现查询缓慢问题。

• ES集群的索引写入及查询速度主要依赖于磁盘的IO速度，冷热数据分离的关键为使用SSD磁盘存储热数据，提升查询效率。
• 若全部使用SSD，成本过高，且存放冷数据较为浪费，因而使用普通SATA磁盘与SSD磁盘混搭，可做到资源充分利用，性能大幅提升的目标。

ES为什么要设计Hot & Warm 架构呢？

• ES数据通常不会有 Update操作;
• 适用于Time based索引数据，同时数据量比较大的场景。
• 引入 Warm节点，低配置大容量的机器存放老数据，以降低部署成本

两类数据节点，不同的硬件配置：

• Hot节点(通常使用SSD)︰索引不断有新文档写入。
• Warm 节点（通常使用HDD)︰索引不存在新数据的写入，同时也不存在大量的数据查询

Hot Nodes：用于数据的写入

• lndexing 对 CPU和IO都有很高的要求，所以需要使用高配置的机器
• 存储的性能要好，建议使用SSD
  

Warm Nodes
用于保存只读的索引，比较旧的数据。通常使用大容量的磁盘

配置Hot & Warm 架构
使用Shard Filtering实现Hot&Warm node间的数据迁移

• node.attr来指定node属性：hot或是warm。
• 在index的settings里通过index.routing.allocation来指定索引（index)到一个满足要求的node
  
  使用 Shard Filtering，步骤分为以下几步：
• 标记节点(Tagging)
• 配置索引到Hot Node
• 配置索引到 Warm节点

1）标记节点
需要通过“node.attr”来标记一个节点

• 节点的attribute可以是任何的key/value
• 可以通过elasticsearch.yml 或者通过-E命令指定

# 标记一个 Hot 节点
elasticsearch.bat  -E node.name=hotnode -E cluster.name=tulingESCluster -E http.port=9200 -E path.data=hot_data -E node.attr.my\_node\_type=hot

# 标记一个 warm 节点
elasticsearch.bat  -E node.name=warmnode -E cluster.name=tulingESCluster -E http.port=9201 -E path.data=warm_data -E node.attr.my\_node\_type=warm

# 查看节点
GET /_cat/nodeattrs?v

1
2
3
4
5
6
7
8
9

2）配置Hot数据
创建索引时候，指定将其创建在hot节点上

# 配置到 Hot节点
PUT /index-2022-05
{
  "settings":{
    "number\_of\_shards":2,
    "number\_of\_replicas":0,
    "index.routing.allocation.require.my\_node\_type":"hot"
  }
}

POST /index-2022-05/_doc
{
  "create\_time":"2022-05-27"
}

#查看索引文档的分布
GET _cat/shards/index-2022-05?v

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

3）旧数据移动到Warm节点
Index.routing.allocation是一个索引级的dynamic setting，可以通过API在后期进行设定

# 配置到 warm 节点
PUT /index-2022-05/_settings
{  
  "index.routing.allocation.require.my\_node\_type":"warm"
}
GET _cat/shards/index-2022-05?v

1
2
3
4
5
6
7

2.5 如何对集群的容量进行规划

一个集群总共需要多少个节点?一个索引需要设置几个分片？规划上需要保持一定的余量，当负载出现波动，节点出现丢失时，还能正常运行。做容量规划时，一些需要考虑的因素：

• 机器的软硬件配置
• 单条文档的大小│文档的总数据量│索引的总数据量（(Time base数据保留的时间)|副本分片数
• 文档是如何写入的(Bulk的大小)
• 文档的复杂度，文档是如何进行读取的(怎么样的查询和聚合)

评估业务的性能需求：

• 数据吞吐及性能需求
  • 数据写入的吞吐量，每秒要求写入多少数据?
  • 查询的吞吐量?
• 单条查询可接受的最大返回时间?
  • 了解你的数据
  • 数据的格式和数据的Mapping
  • 实际的查询和聚合长的是什么样的

ES集群常见应用场景：

• 搜索: 固定大小的数据集
  • 搜索的数据集增长相对比较缓慢
• 日志: 基于时间序列的数据
  • 使用ES存放日志与性能指标。数据每天不断写入，增长速度较快
  • 结合Warm Node 做数据的老化处理

硬件配置：

• 选择合理的硬件，数据节点尽可能使用SSD
• 搜索等性能要求高的场景，建议SSD
  • 按照1∶10-20的比例配置内存和硬盘
• 日志类和查询并发低的场景，可以考虑使用机械硬盘存储
  • 按照1:50的比例配置内存和硬盘
• 单节点数据建议控制在2TB以内，最大不建议超过5TB
• JVM配置机器内存的一半，JVM内存配置不建议超过32G
• 不建议在一台服务器上运行多个节点

内存大小要根据Node 需要存储的数据来进行估算

• 搜索类的比例建议: 1:16
• 日志类: 1:48——1:96之间

假设总数据量1T，设置一个副本就是2T总数据量

• 如果搜索类的项目，每个节点31*16 = 496 G，加上预留空间。所以每个节点最多400G数据，至少需要5个数据节点
• 如果是日志类项目，每个节点31*50= 1550 GB，2个数据节点即可

部署方式：

• 按需选择合理的部署方式
• 如果需要考虑可靠性高可用，建议部署3台单一的Master节点
• 如果有复杂的查询和聚合，建议设置Coordinating节点

集群扩容：

• 增加Coordinating / Ingest Node
• 解决CPU和内存开销的问题
• 增加数据节点
• 解决存储的容量的问题
• 为避免分片分布不均的问题，要提前监控磁盘空间，提前清理数据或增加节点

2.6 如何设计和管理分片

单个分片

• 7.0开始，新创建一个索引时，默认只有一个主分片。单个分片，查询算分，聚合不准的问题都可以得以避免
• 单个索引，单个分片时候，集群无法实现水平扩展。即使增加新的节点，无法实现水平扩展

两个分片
集群增加一个节点后，Elasticsearch 会自动进行分片的移动，也叫 Shard Rebalancing

算分不准的原因
相关性算分在分片之间是相互独立的，每个分片都基于自己的分片上的数据进行相关度计算。这会导致打分偏离的情况，特别是数据量很少时。当文档总数很少的情况下，如果主分片大于1，主分片数越多，相关性算分会越不准
一个示例如下：

PUT /blogs
{
  "settings":{
    "number\_of\_shards" : "3"
  }
}

POST /blogs/_doc/1?routing=fox
{
 "content":"Cross Cluster elasticsearch Search"
}

POST /blogs/_doc/2?routing=fox2
{
 "content":"elasticsearch Search"
}

POST /blogs/_doc/3?routing=fox3
{
 "content":"elasticsearch"
}

GET /blogs/_search
{
  "query": {
    "match": {
      "content": "elasticsearch"
    }
  }
}

#解决算分不准的问题
GET /blogs/_search?search_type=dfs_query_then_fetch
{
  "query": {
    "match": {
      "content": "elasticsearch"
    }
  }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

解决算分不准的方法：

• 数据量不大的时候，可以将主分片数设置为1。当数据量足够大时候，只要保证文档均匀分散在各个分片上，结果一般就不会出现偏差
• 使用DFS Query Then Fetch
  • 搜索的URL中指定参数“_search?search_type=dfs_query_then_fetch"
  • 到每个分片把各分片的词频和文档频率进行搜集，然后完整的进行一次相关性算分

但是这样耗费更加多的CPU和内存，执行性能低下，一般不建议使用

如何设计分片数
当分片数>节点数时

• 一旦集群中有新的数据节点加入，分片就可以自动进行分配
• 分片在重新分配时，系统不会有downtime

多分片的好处: 一个索引如果分布在不同的节点，多个节点可以并行执行

• 查询可以并行执行
• 数据写入可以分散到多个机器

分片过多所带来的副作用
Shard是Elasticsearch 实现集群水平扩展的最小单位。过多设置分片数会带来一些潜在的问题：

• 每个分片是一个Lucene的索引，会使用机器的资源。过多的分片会导致额外的性能开销。
• 每次搜索的请求,需要从每个分片上获取数据
• 分片的Meta 信息由Master节点维护。过多，会增加管理的负担。经验值，控制分片总数在10W以内

如何确定主分片数
从存储的物理角度看：

• 搜索类应用，单个分片不要超过20 GB
• 日志类应用，单个分片不要大于50 GB

为什么要控制分片存储大小：

• 提高Update 的性能
• 进行Merge 时，减少所需的资源
• 丢失节点后，具备更快的恢复速度
• 便于分片在集群内 Rebalancing

如何确定副本分片数
副本是主分片的拷贝：

• 提高系统可用性︰响应查询请求，防止数据丢失
• 需要占用和主分片一样的资源

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取

储的物理角度看：

• 搜索类应用，单个分片不要超过20 GB
• 日志类应用，单个分片不要大于50 GB

为什么要控制分片存储大小：

• 提高Update 的性能
• 进行Merge 时，减少所需的资源
• 丢失节点后，具备更快的恢复速度
• 便于分片在集群内 Rebalancing

如何确定副本分片数
副本是主分片的拷贝：

• 提高系统可用性︰响应查询请求，防止数据丢失
• 需要占用和主分片一样的资源

[外链图片转存中…(img-RVRJ3CYZ-1714167560233)]
[外链图片转存中…(img-VaEIMcct-1714167560233)]
[外链图片转存中…(img-evJ0my5l-1714167560234)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取