AIOps 一场颠覆传统运维的盛筵
875
2022-10-02
21_Elasticsearch运维_集群节点分片
相较于Elasticsearch操作篇关注的索引与文档,Elasticsearch运维更关注集群、节点、分片(主分片,副本分片)
将数据按照一定的规则分为多个数据块,这个就是分片,也叫主分片; 针对每个主分片进行备份,这个就是副本; 将数据块(分片和副本)根据一定规律分散到不同的容器中,这个容器就是节点 多个节点通过同一个master节点进行统一调度管理,这个就是集群 图示如下:
1 集群
elasticsearch其实就是一个分布式系统,需要满足分布式系统具备的高可用性和可扩展性不同的集群通过不同的名称来区分,默认名称是elasticsearch;集群名称可以通过修改配置文件(config/elasticsearch.yml),也可以在启动命令中添加(-E cluster.name=geektim)
1.1 特征
1.1.1 分布式系统的特性
高可用性服务可用性-允许有节点停止服务数据可用性-部分节点丢失,不会丢失数据可扩展性请求量提升/数据的不断增长(数据将分布到所有节点上)
1.1.2 Elasticsearch的分布式特性
高可用性服务可用性-节点停止服务,该节点上的分片及副本将在其他节点上重建。数据可用性-部分节点丢失,将通过对应的副本恢复该节点上的数据,确保数据不丢失可扩展性请求量提升-新增Coordinating节点,专门用于接受请求并分发给合适的节点数据量增加-增加data节点,将会对分片(包括副本)进行重新分配,确保各节点平衡。分片数必须大于扩展后的节点数。
1.2 集群常用操作
GET _cluster/health # Green 主分片和副本都正常分片 # Yellow 主分片全部正常分配,有副本分片未能正常分配 # Red 有主分片未能分配。例如:当服务器的磁盘容量超过85%时,去创建一个新的索引,将导致状态变为Red GET _cluster/health?level=shards GET /_cluster/health/kibana_sample_data_ecommerce,kibana_sample_data_flights GET /_cluster/health/kibana_sample_data_flights?level=shards GET /_cluster/state #集群状态获取 GET /_cluster/settings GET /_cluster/settings?include_defaults=true #集群的配置
2 节点
节点是一个Elasticsearch的实例,本质上是一个Java进程;一台服务器可以启动多个节点,但是生产环境建议只启动一个。同一集群下节点名字要求不重复,节点名字可以通过修改配置文件(config/elasticsearch.yml),也可以在启动命令中添加(-E node.name=node1);节点启动之后会分配一个UID,保存在data目录下
2.1 节点的角色
节点类型 | 用途 | 配置参数 | 默认值 |
---|---|---|---|
master_eligible | 参与master节点选举 | node.master | true |
data | 数据节点 | node.data | true |
ingest | 数据前置处理转换 | node.ingest | true |
coordinating only | 协调节点 | 无 | 每个节点默认都是coordinating节点。设置其他类型全部为false |
machine learning | 机器学习节点 | node.ml | true(需enable x-pack) |
2.1.1 Master-eligible Nodes和Master Node
master node是管理节点,主要用于维护集群状态Master-eligible节点可以参与选举,成为Master节点。
Master NodeMaster Node的职责处理创建,删除索引等请求/决定分片被分配到哪个节点/负责索引的创建与删除维护并且更新Cluster State所有节点都会保存集群信息,但是只有master节点能进行修改任意节点都能修改信息将导致数据的不一致集群状态包括所有的节点信息、索引信息(包括mapping和setting)、分片的路由信息Master Node的最佳实践Master节点非常重要,在部署上需要考虑解决单点的问题为一个集群设置多个Master节点/每个节点只承担Master的单一功能Master-eligible NodesMaster-eligible节点可以参与选举,成为master节点每个节点默认都是master-eligible节点,可通过设置node.master:false关闭
master选举流程
互ping对方,node id低的会成为被选举的节点 其他节点会加入集群,但是不承担master节点的角色,一旦发现被选中的主节点丢失,就会重新选举master节点 若只有一个节点,它就会自己选举成为master节点
脑裂问题
由于网络出现问题,导致一个节点和其他节点无法连接。如有三台master节点(node1,node2,node3),node1无法与集群无法连接 node2和node3重新选举master,并由新的master节点维护cluster state node1自己还是master,同样更新cluster state 当网络恢复时将有两套不一样的cluster state
如何避免脑裂问题
限定一个选举条件,设置quorum(仲裁),只有在Master eligible节点数大于quorum时,才能进行选举建议Quorum = (master 节点总数/2) + 1当3个master eligible时,设置discovery.zen.minimum_master_nodes为2,即可避免脑裂从7.0开始,无需这个配置移除minimum_master_nodes参数,让Elasticsearch自己选择可用形成仲裁的节点典型的主节点选举现在只需要很短的时间就可以完成,集群的伸缩变得更安全、更容易,并且可能造成丢失数据的系统配置选项更少了节点更清楚地记录它们的状态,有助于诊断为什么它们不能加入集群或为什么无法选举出主节点
2.1.2 Data Node
可以保存数据的节点,叫做Data Node节点启动后,默认就是数据节点。可用设置node.data:false禁止Data Node的职责保存分片数据。在数据扩展上起到了至关重要的作用(由Master Node决定如何把分片分发到数据节点上)通过增加数据节点可用解决数据水平扩展和解决数据单点问题
2.1.3 Coordinating Node
协调节点,负责接受Client的请求,将请求分发到合适的节点,最终将结果汇集到一起
每个节点默认都起到Coordinating Node的职责;可设置其他节点类型参数为flase,使其专门用于交互搜索请求在两个阶段中执行(query 和 fetch),这两个阶段由接收客户端请求的节点 - 协调节点协调。在请求阶段,协调节点将请求转发到保存数据的数据节点。每个数据节点在本地执行请求并将其结果返回给协调节点。在收集fetch阶段,协调节点将每个数据节点的结果汇集为单个全局结果集。
2.1.4 Ingest Node
ingest 节点可以看作是数据前置处理转换的节点,支持 pipeline管道 设置,可以使用 ingest 对数据进行过滤、转换等操作,类似于 logstash 中 filter 的作用,功能相当强大。
数据预处理(类似大数据处理环节的ETL--抽取、转化、加载)拦截Index或Bulk API的请求,对数据进行转换,并重新返回给Index或Bulk API为某个字段设置默认值;重命名某个字段的字段名;对字段值进行Split操作支持设置Painless脚本
2.1.5 其他不常用的节点类型
Hot & Warm Node 不同硬件配置的Data Node,用来实现Hot & Warm架构,减低集群部署的成本 Machine Learning Node 负责跑机器学习的Job 用来做异常检测 通过 node.ml 配置,默认 true,需要通过 x-pack 开启 Tribe Node(在5.4中已弃用) 负责连接不同的集群。支持跨集群搜索 Cross Cluster Search
2.2 节点常用操作
GET _cat/nodes?v GET /_nodes/es7_cold,es7_warm,es7_hot GET /_cat/nodes?v GET /_cat/nodes?v&h=id,ip,port,v,m #获取节点信息
3 分片
分片是运维角度elasticsearch的最小单位,又可以分为主分片与副本分片。
3.1 主分片 VS 副本分片
主分片(Primary Shard)用于解决数据水平扩展的问题,通过主分片,可以将数据分布到集群中的多个Data Node上一个分片是一个运行的Lucene的实例主分片数在索引创建时指定,后续不允许修改,除非Reindex副本分片(Replica Shard)用于解决数据高可用的问题。副本是主分片的拷贝,不能与主分片放在统一节点一旦主分片丢失,副本分片可以Promote成主分片。副本分片数可用动态调整。每个节点都有完备的数据。如果不设置副本分片,一旦出现节点硬件故障,就有可能造成数据丢失提升系统的读取性能副本分片由主分片(Primary Shard)同步。通过增加Replica个数,一定程度上可用提高读取的吞吐量副本分片数可用动态调整
3.2 分片的规划
主分片数设置过小后续无法增加节点实现水平扩展增加节点后会调整分片的分布,不会调整分片的数量单个分片的数据量过大,导致数据重新分配耗时主分片数设置过大影响搜索结果的相关性打分,影响统计结果的准确性每个分片的底层即为一个Lucene索引,会消耗一定文件句柄、内存、以及CPU每一个搜索请求都需要命中索引的每一个分片,若需要搜索的多个分片在同一个节点上将导致资源竞争,从而影响性能副本分片设置过多降低集群整体的写入性能
3.3 文档到分片的路由算法
shard = hash(_routing) % number_of_primary_shards Hash算法确保文档均匀分散到分片中 默认的_routing值是文档id,可以自行指定routing数值,例如用相同国家的商品,都分配到指定的shard 基于如上算法导致该算法设置Index Settings后,primary数不能修改(需要重新计算路由算法)
3.4 故障转移能力
启动一个节点,3个Primary shard,1个Replice,集群黄色,因为无法分配Replica启动三个节点,1个索引上包含3个Primary Shard,1个Replica关闭Node1(master)查看Master Node重新选举集群变黄,然后重新分配
3.5 分片常用操作
PUT my_index { "settings": { "number_of_shards": 3, "number_of_replicas": 1 } } #创建索引,设置主分片数为3,副本分片为1 GET _cat/shards GET _cat/shards?h=index,shard,prirep,state,unassigned.reason #查询分片信息
发表评论
暂时没有评论,来抢沙发吧~