Elasticsearch

13
Sep

Elasticsearch

分布式
节点 & 集群
主分片及副本
一、Elasticsearch 分布式
Elasticsearch 分布式特性包括如下几个点:

1.1 高可用
什么是高可用?CAP 定理是分布式系统的基础,也是分布式系统的 3 个指标:

Consistency(一致性)
Availability(可用性)
Partition tolerance(分区容错性)
那高可用(High Availability)是什么?高可用,简称 HA,是系统一种特征或者指标,通常是指,提供一定性能上的服务运行时间,高于平均正常时间段。反之,消除系统服务不可用的时间。

衡量系统是否满足高可用,就是当一台或者多台服务器宕机的时候,q系统整体和服务依然正常可用。举个例子,一些知名的网站保证 4 个 9 以上的可用性,也就是可用性超过 99.99%。那 0.01% 就是所谓故障时间的百分比。

Elasticsearch 在高可用性上,体现如下两点:

服务可用性:允许部分节点停止服务,整体服务没有影响
数据可用性:允许部分节点丢失,最终不会丢失数据
1.2 可扩展
随着公司业务发展,Elasticsearch 也面临两个挑战:

搜索数据量从百万到亿量级
搜索请求 QPS 也猛增
那么需要将原来节点和增量数据重新从 10 个节点分布到 100 个节点。Elasticsearch 可以横向扩展至数百(甚至数千)的服务器节点,同时可以处理PB级数据。Elasticsearch 为了可扩展性而生,由小规模集群增长为大规模集群的过程几乎完全自动化,这是水平扩展的体现。

1.3 Elasticsearch 分布式特性
上面通过可扩展性,可以看出 Elasticsearch 分布式的好处明显:

存储可以水平扩容,水平空间换时间
部分节点停止服务,整个集群服务不受影响,照样正常提供服务
Elasticsearch 在后台自动完成了分布式相关工作,如下:

自动分配文档到不同分片或者多节点上
均衡分配分片到集群节点上,index 和 search 操作时进行负载均衡
复制每个分片,支持数据冗余,防止硬件故障数据丢失
集群扩容时,无缝整合新节点,并且重新分配分片
等等
Elasticsearch 集群知识点如下:

不同集群通过名字区分,默认集群名称为 "elasticsearch"
集群名 cluster name ,可以通过配置文件修改或者命令行 -E cluster.name=user-es-cluster 进行设置
一个集群由多个节点组成
二、Elasticsearch 节点 & 集群

Elasticsearch 集群有多个节点组成,形成分布式集群。那么,什么是节点呢?

节点(Node),就是一个 Elasticsearch 应用实例。大家都知道 Elasticsearch 源代码是 Java 写的,那么节点就是一个 Java 进程。所以类似 Spring 应用一样,一台服务器或者本机可以运行多个节点,只要对应的端口不同即可。但生产服务器中,一般一台服务器运行一个 Elasticsearch 节点。还有需要注意:

Elasticsearch 都会有 name ,通过 -E node.name=node01 指定或者配置文件中配置
每个节点启动成功,都会分配对应得一个 UID ,保存在 data 目录
可以通过命令 _cluster/health 查看集群的健康状态,如下:

Green 主分片与副本分片都正常
Yellow 主分片正常,副本分片不正常
Red 有主分片不正常,可能某个分片容量超过了磁盘大小等

如图,有主(Master)节点和其他节点。那么节点有多少类型呢?

2.1 Master-eligible Node 和 Master Node
Elasticsearch 被启动后,默认就是 Master-eligible Node。然后通过参与选主过程,可以成为 Master Node。具体选主原理,后续单独写一篇文章。Master Node 有什么作用呢?

Master Node 负责同步集群状态信息:
所有节点信息
所有索引即其 Mapping 和 Setting 信息
所有分片路由信息
只能 Master 节点可以修改信息,是因为这样就能保证数据得一致性
2.2 Data Node 和 Coordinating Node
Data Node,又称数据节点。用于保存数据,其在数据扩展上起至关重要的作用。

Coordinating Node,是负责接收任何 Client 的请求,包括 REST Client 等。该节点将请求分发到合适的节点,最终把结果汇集到一起。一般来说,每个节点默认起到了 Coordinating Node 的职责。

2.3 其他节点类型
还有其他节点类型,虽然不常见,但需要知道:

Hot & Warm Node:不同硬件配置的 Data Node,用来实现冷热数据节点架构,降低运维部署的成本
Machine Learning Node:负责机器学习的节点
Tribe Node:负责连接不同的集群。支持跨集群搜索 Cross Cluster Search
一般在开发环境中,设置单一的角色节点:

master node:通过 node.master 配置,默认 true
data node:通过 node.data 配置,默认 true
ingest node:通过 node.ingest 配置,默认 true
coordinating node:默认每个节点都是 coordinating 节点,设置其他类型全部为 false。
machine learning:通过 node.ml 配置,默认 true,需要通过 x-pack 开启。
三、主分片及副本

同样看这个图,3 个节点分别为 Node1、Node2、Node3。并且 Node3 上面有一个主分片 P0 和一个副本 R2。那什么是主分片呢?

主分片,用来解决数据水平扩展的问题。比如上图这个解决可以将数据分布到所有节点上:

节点上可以有主分片,也可以没有主分片
主分片在索引创建的时候确定,后续不允许修改。除非 Reindex 操作进行修改
副本,用来备份数据,提高数据的高可用性。副本分片是主分片的拷贝

副本分片数,可以动态调整
增加副本数,可以一定程度上提高服务读取的吞吐和可用性
如何查看 Elasticsearch 集群的分片配置呢?可以从 settings 从看出:

number_of_shards 主分片数
number_of_replicas 副本分片数
{
  "my_index": {
    "settings": {
      "index": {
        "number_of_shards": "8",
        "number_of_replicas": "1"
      }
    }
  }
}

复制
实战建议:对生产环境中,分片设置很重要,需要最好容量评估与规划

根据数据容量评估分配数,设置过小,后续无法水平扩展;单分片数据量太大,也容易导致数据分片耗时严重
分片数设置如果太大,会导致资源浪费,性能降低;同时也会影响搜索结果打分和搜索准确性
索引评估,每个索引下面的单分片数不用太大。如何评估呢?比如这个索引 100 G 数据量,那设置 10 个分片,平均每个分片数据量就是 10G 。每个分片 10 G 数据量这么大,耗时肯定严重。所以根据评估的数据量合理安排分片数即可。如果需要调整主分片数,那么需要进行 reindex 等迁索引操作。

小结
从上一篇到这一篇:

一个节点,对应一个实例
一个节点,可以多个索引
一个索引,可以多个分片
一个分片,对应底层一个 lucene 分片
比如知道了搜索性能场景,例如多少数据量,多大的写入,是写为主还是查询为主等等,才可以确定:

磁盘,推荐 SSD,JVM最大 Xmx 不要超过30G。副本分片至少设置为1。主分片,单个存储不要超过 30 GB,按照这个你推算出分片数,进行设定。
集群中磁盘快满的时候,你再增加机器,确实可能导致新建的索引全部分配到新节点上去的可能性。最终导致数据分配不均。所以要记得监控集群,到70%就需要考虑删除数据或是增加节点
可以设置最大分片数缓解这个问题。
分片的尺寸如果过大,确实也没有快速恢复的办法,所以尽量保证分片的size在40G以下

集群信息

GET _cluster/health?pretty
GET _cluster/pending_tasks?pretty
GET _cluster/allocation/explain?prettyq

节点下线

1.将节点设置为 "排水" 状态,防止新的分片被分配到该节点

PUT _cluster/settings
{
  "transient": {
    "cluster.routing.allocation.exclude._ip": "10.1.22.129"
  }
}

2. 等待所有分片从该节点迁移走

1.查询分片状态

GET /_cat/shards

2.查看节点信息

GET /_nodes/节点名称/stats/indices?pretty

3. 完成维护或升级后重置

PUT _cluster/settings
{
  "transient": {
    "cluster.routing.allocation.exclude._ip": null
  }
}

修改副本数

PUT my_index/_settings
{
  "index": {
    "number_of_replicas": 1
  }
}

修改分片的速度

cluster.routing.allocation.node_concurrent_recoveries

单节点分片恢复的并发数
indices.recovery.max_bytes_per_sec

单节点分片恢复的速率,适用于 peer recoveries 和 snapshot recoveries
peer recoveries 对等恢复,增加副本数就是对等恢复

GET _cluster/settings?flat_settings&include_defaults

PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.node_concurrent_recoveries": "4",
    "indices.recovery.max_bytes_per_sec": "100mb"
  }
}

分片的进度

GET _cat/recovery?v=true&h=i,s,t,ty,st,shost,thost,f,fp,b,bp

快照进度

快照的速度
indices.recovery.max_bytes_per_sec 仍然有效
HDFS 与 S3

max_snapshot_bytes_per_sec  指定创建快照时的速度,默认为 40mb/s
max_restore_bytes_per_sec   指定数据恢复速度,默认无限制
快照恢复的进度
GET _cat/recovery?v=true&h=i,s,t,ty,st,rep,snap,f,fp,b,bp
查看分片未分配原因

GET _cat/shards?v&h=index,docs,shard,prirep,state,unassigned.reason
查看进度

# 示例
GET _cat/recovery?v=true&h=index,shard,time,type,stage,files_percent,bytes_percent
# 示例(简写)
GET _cat/recovery?v=true&h=i,s,t,ty,st,fp,bp

添加新评论