前言
集群(Cluster)是一种计算模型,由多台相互独立的计算机/服务节点,通过高速网络连接并共同工作,对外界提供单一系统的服务。 集群的目的是通过多台计算机的协同工作,提供更高的计算性能、可靠性和数据冗余。
集群基本组成:计算节点、调度器、网络、存储系统
工作步骤:任务分配、任务调度、结果合并
Elasticsearch的集群
- Elasticsearch内置一个ZenDiscovery模块,只需稍加修改配置文件,即可自动实现集群(auto-clustering)
# 集群名称,各个节点的集群名称必须一致
cluster.name: dingsu
# 本节点在集群中的名称
node.name: node-1
# 本节点是否具备成为master的资格,设为true,不一定直接就能成为master
node.master: true
# 本节点是否为数据节点
node.data: true
# 本节点端口号,默认9200,因为是单机启动多个节点,所以自定义了端口
http.port: 9200
# 节点之间通信端口,可以设置单个端口,也可以设置为端口区段,默认端口区段9300-9400
transport.tcp.port: 9300
# 自动集群静态配置,值为一组具有master资格的节点环回地址,可以是ip、dns可解析为的一个或多个IP地址的域名
discovery.seed_hosts: ["192.168.100.100:9300","192.168.100.100:9303","192.168.100.100:9302"]
# 首次启动 Elasticsearch 集群时的引导步骤使用该配置,需要显式列出具有master资格的节点,其选票用于第一次master节点选举,不要配置在node.master为false的节点上
cluster.initial_master_nodes: ["node-1","node-2","node-3"]
- 更多配置参考官网,ES配置介绍
- 以下是配置了5个节点的cerebro界面,也可以自行安装elasticsearch-head去查看集群状态
节点 nodes
ES 7.10之后,增加了数据分层(Data tiers)功能
数据层实际上就是先定义好数据节点的角色,比如热节点、温节点等,然后可以在ILM(Information Lifecycle Management)索引生命周期管理中实现索引由热节点迁移到温节点,再迁移到冷节点,达到数据冷热分离的目的
-
在上面配置中,我们能看出来在ES中,各个节点可以根据配置,承载不同的功能
-
官方配置为node.roles = [],可以看出一个节点可以承担多个角色功能
-
在ES 7中,存在9种节点类型/角色,ES 8新增两种类型,扩至11种,以下内容根据8.15.3版本进行介绍
- master
- 符合master节点的候选节点
- 当前节点存在master角,active master宕机时,则其有资格被选为控制集群的节点
- data
- 泛型数据(generic data)节点
- 5种具体数据节点类型的通用类型,也可以担任 data_content、data_hot、data_warm、data_cold、data_frozen其中一个角色
- 数据节点用来保存数据、执行数据相关操作,比如CRUD、查询、聚合等
- data_content
- 内容数据节点
- 存储在内容层中的数据通常是项目集合,例如产品目录或文章存档。
- 内容层的数据特点是,一段时间内相对恒定,几乎或极少会去修改,但是随着时间的推移,依旧会增长
- 内容层节点通常需要针对查询性能进行优化 ,优先考虑处理能力而不是 IO 吞吐量,可以处理复杂的搜索和聚合并快速返回结果。
- data_hot
- 热数据节点
- 用于保存最新的、最常搜索的时间序列数据。
- 热存储层中的节点需要快速读取和写入。 这需要更多的硬件资源和更快的存储 (SSD)。
- 为了实现弹性,应将热存储层中的索引配置为使用一个或多个副本。
- data_warm
- 暖数据节点
- 时间序列数据在查询频率降低后可以移动到暖层。
- 暖层通常包含最近几周的数据,定时进行查询某时间内的数据时,仍然需要参与计算。
- 更新仍被允许,但可能不频繁。
- 暖层中的节点通常不需要像热层中的节点一样快。
- 同时跟热层一样,为了实现弹性,应将暖层中的索引配置为使用一个或多个副本。
- data_cold
- 冷数据节点
- 不再需要定期搜索的时间序列数据,可以从暖层到冷层。
- 虽然仍可搜索,但此层设计的目的,通常是针对降低存储成本而不是搜索速度。
- data_frozen
- 冻数据节点
- 一旦数据不再被查询或很少被查询,尽量将这些数据从冷层迁移至冻层
- 冻结层需要快照存储库。
- 冻结层使用部分挂载的索引来存储 以及从 Snapshot 存储库加载数据。这减少了本地存储和 运营成本,同时仍允许您搜索冻结数据。因为 Elasticsearch 必须有时从快照存储库中获取冻结的数据,在冻层通常比冷层慢。
- ingest
- 预处理节点 (数据前置处理转换)
- 负责处理文档索引和更新操作之前的数据转换
- ml
- 机器学习节点
- remote_cluster_client
- 候选跨集群客户端节点
- 可以搜索使用跨集群搜索的远程集群
- 可以同步使用跨集群复制的集群之间的数据。
- transform
- 转换节点
- 将 Elasticsearch 索引数据进行统计分析并产生新的索引
- voting_only
- 在7.10的文档中,没有罗列出来,但是后续介绍中提到的一种节点,仅投票节点
- 8.15文档中已经不介绍了
- 只参与主节点选举过程,但不会被选为主节点
- master
分片是Elasticsearch的最小工作/数据存储单元
主分片 Primary Shard
- 在一个索引(Index)中,数据(Document)会被分片处理(sharding)成多个主分片(Shard)。
- 每个节点(Node)都知道集群中任一分片及文档位置,所以接收到请求的节点,可以直接将请求转发(广播)到分片(主分片及副本分片)的节点上,接收转发请求的节点,执行查询,将结果排序之后,发送给协调节点(收到客户端请求的节点),协调节点整理合并之后,响应给对应请求
- 整个过程中,Elasticsearch屏蔽了管理分片的复杂性,在用户使用角度看来,只执行了一次查询,过程透明无感。
- 默认每个索引创建时,1 主分片 、1 副本分片,所以当我们启动单个节点时,集群健康状态为Yellow(所有主分片正常,部分副本分片异常),因为主分片与副本分片,不能存在于同个节点
- 创建索引时,可以在setting中,手动指定主分片数量
"settings": {
"number_of_shards": 3
}
- 索引一旦创建成功,不能修改主分片数量,插入文档(Document)时,使用hash算法,将文档路由到对应分片
# routing一般是_id,_id % 主分片数量,取余,比如 7 % 3 = 1,即第2个主分片,主分片序号为 [0] 至 [数量-1]
shardAddress = hash(routing) % number_of_primary_shards
- 同时,索引的主分片数量也决定,该索引能够存储文档的数量上限,单个主分片理论上能够存储Integer.MAX_VALUE -128条数据,根据单条Document大小及硬件情况会有所减少,所以每个索引能够存储的最大数量 ≤ number_of_shards *(Integer.MAX_VALUE -128)
- 假设允许修改分片数量的话,新值带入hash算法,将找不到原来数据的位置
- 到这一步,我们对索引(Index)的理解应该更清晰一些,索引(Index)实际上是指向一个或者多个物理分片的逻辑命名空间 。
副本分片 Replica
-
为了提升访问压力过大是单机无法处理所有请求的问题,Elasticsearch集群引入了副本策略replica。
-
副本(Replica)是对索引(Index)的每个分片(Shard)创建冗余的副本,处理查询时可以把这些副本会被当做主分片来执行查询(官方图是这样),主分片主要用来执行写入操作(不是只做写入),如果需要索引的文档,存在于主分片,但还未同步的情况下,依旧能够正常返回。
-
由于副本(Replica)和主分片(Shard)不在同一节点存放,所以副本能够保证集群的高可用和数据安全
-
当主分片(Shard)所在的机器/节点宕机,Elasticsearch可以使用其宕机主分片的副本 + 未宕机主分片,集齐整套数据进行恢复,重新分配节点存储,从而避免数据丢失。
-
创建索引时,可以在setting中,手动指定主分片的副本数量,默认为1
"settings": {
"number_of_replicas": 1
}
- 不同于主分片(Shard),副本(Replica)是同步主分片的数据,不会对文档(Document)路由到哪个主分片产生影响,所以索引(Index)创建成功后,仍然可以修改副本数量
- 以下是5个节点,索引dingsu 3 主分片,2 副本的启动情况,粗线边框是Shard,虚线边框是Replica,实心星标是master节点