ES的Zen发现机制
Posted woniu4
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了ES的Zen发现机制相关的知识,希望对你有一定的参考价值。
ES的Zen发现机制
Zen发现机制是ElasticSearch默认的发现模块。它提供的是单播发现,但是可被拓展为支持云环境下或者其他形式的发现机制。zen 发现模块集成了其他模块,如在发现期间,节点的通信就是通过transport模块实现 。
zen发现模块可以细分以下几块:
l Ping
这是一个节点通过发现机制查找其他节点的进程
l Unicast
单播发现需要一组主机列表来充当gossip routers,这些主机可以提供主机名称或者主机的IP;当在Ping的过程中,提供名称的主机被解析成IP地址。需要注意的是你的环境中如果DNS解析如果随着时间变化的话,你需要调整JVMsecurity settings.
推荐设置是将单播列表作为当前集群的master后续列表。
单播发现提供的配置是以discovery.zen.ping.unicast开头:
名称 |
描述 |
默认值 |
hosts |
可以是数组设置或者通过“,”分割的设置,每个值的格式是:host:port或者host,如果port可以通过transport.profiles.default.port设置,如果不设置,将会使用transport.tcp.port(默认是9300),需要注意的是如果使用的IPv6的话,必须通过括号括起来 |
127.0.0.1,[::1] |
Hosts.resolve_timeout |
DNS解析的时间。需要指定单位 |
5s |
Master选举
作为ping进程的一部分,集群的master被选举出来或者加入其中。这个过程是自动完成的。discovery.zen.ping_timeout(默认是3s)决定了一个节点在决定开始选举还是加入一个存在集群的等待时间。在超过这个时间后,会尝试3次ping。如果已经达到了超时时间,还没有做出决定,则pnig进程会重启。在一个缓慢的或者拥挤的网络中,3s或许不足以在做出决定前,发觉环境中的其他节点。在这种情况下,应该提升超时时间,进而让选举工作慢下来。一旦一个节点决定加入一个现有的网络,则其会向master发送一个20倍ping超时的加入请求。
当master节点停止或者发生问题时,集群则重新开始选举。这个互相ping也作为了网络出问题的一种保障,当一个节点没有意识到master已经失败了(这个理解应该有错误)。在这种情况下,一个节点可以从其他节点处的得到当前的master节点。
discovery.zen.master_election.ignore_non_master_pings被设置为true,在选举过程中,来自非master候选节点的pings将会被忽略。默认值是false.
通过node.master设置为false,将该节点排除,避免其成为matster节点。
discovery.zen.minimum_master_nodes设置参选master的最小值,需要加入新选的master,来完成选举工作,同时,接受master节点的身份。这个参数同样控制最少活跃候选节点的数量,这些节点应该是集群的一部分。如果没有达到这个值,则当前master将要下台,开始新的选举工作。
这个参数必须设置候选节点的有效值。建议避免有两个候选节点,因为两个的有效值是两个。这样,当丢失其中一个候选节点的结果是集群不可用。
l 故障检测
在es集群中会存在两种故障检测进程,一种是master节点发起的,检测是否可以ping通集群中的节点,同时判断节点是否还存活;另一种是由其他节点发起的,用于判断master节点是否还存活以及是否有必要重新发起选举。相关故障检测参数配置是由discovery.zen.fd为前缀的,相关参数如下:
名称 |
描述 |
默认值 |
ping_interval |
Ping的时间间隔 |
1s |
ping_timeout |
等待结果响应的超时时间 |
30s |
ping_retries |
失败或者超时后重试的次数 |
3s |
- 集群状态更新
Master节点是集群中唯一可以更新集群状态的节点。Master节点一次处理一个集群状态的更新,应用所需的更改,并将集群的状态发布给集群中的其他节点。每一个节点接受到状态后,确认收到消息,但是并不应用该消息。如果master节点没有在规定的时间内(discovery.zen.commit_timeout默认30s)的得到discovery.zen.minimum_master_nodes节点的认可,则集群状态更新废弃。
一旦得到足够的响应,则集群的状态将被提交,同时,消息也会告知其他节点。然后,节点将状态应用到期内部状态中。Master节点会等待所有节点的响应直到超时,然后去处理队列中新的更新。这discovery.zen.publish_timeout默认是30s,是从状态发布开始计算的。这个超时时间是可以通过api动态更新。
l No master block
一个集群可以完整的操作,它必须有一个活的master节点和足够数量的候选master节点来满足discovery.zen.minimum_master_nodes。discovery.zen.no_master_block控制哪些操作将被丢弃,当集群没有master节点时。
discovery.zen.no_master_block有两个有效值:
all |
所有的操作,如读和写都将被丢弃。这个同样应用在集群状态的读写api操作,如get index setting, put mapping 和集群状态的api |
write |
(默认)写操作将被丢弃。根据最后的已知的集群配置,读操作可以成功。这个可能读取部分结果,因为查询的节点可能是一个与其他节点隔离(其实简单的说,就是已经脑裂了)。 |
discovery.zen.no_master_block这个参数对于节点相关的api无效(如集群属性,节点信息,节点属性)。这些请求的api都不会被拒绝,并且可以运行在任意可用节点。
以上是关于ES的Zen发现机制的主要内容,如果未能解决你的问题,请参考以下文章