elasticSearch:避免es集群的“脑裂”现象

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了elasticSearch:避免es集群的“脑裂”现象相关的知识,希望对你有一定的参考价值。

参考技术A es集群由多个 数据节点 和一个 主节点 (可以有多个备选主节点)组成。其中数据节点负责数据存储和具体操作,如执行搜索、聚合等任务,计算压力较大。主节点负责创建、删除索引、分配分片、追踪集群中的节点状态等工作,计算压力较轻。

正常情况下,当主节点无法工作时,会从备选主节点中选举一个出来变成新主节点,原主节点回归后变成备选主节点。但有时因为网络抖动等原因,主节点没能及时响应,集群误以为主节点挂了,选举了一个新主节点,此时一个es集群中有了两个主节点,其他节点不知道该听谁的调度,结果将是灾难性的!这种类似一个人得了精神分裂症,就被称之为“脑裂”现象。

造成es“脑裂”的因素有以下几个:

1、网络抖动

        内网一般不会出现es集群的脑裂问题,可以监控内网流量状态。外网的网络出现问题的可能性大些。

2、节点负载

        如果主节点同时承担数据节点的工作,可能会因为工作负载大而导致对应的 ES 实例停止响。

3、内存回收

        由于数据节点上es进程占用的内存较大,较大规模的内存回收操作也能造成es进程失去响应。

避免es“脑裂”的措施主要有以下三个:

1、不要把主节点同时设为数据节点(node.master和node.data不要同时设为true)

2、将节点响应超时(discovery.zen.ping_timeout)稍稍设置长一些(默认是3秒),避免误判。

3、设置需要超过半数的备选节点同意,才能发生主节点重选,类似需要参议院半数以上通过,才能弹劾现任总统。(discovery.zen.minimum_master_nodes = 半数以上备选主节点数)

(转)Elasticsearch集群的脑裂问题

转自 http://blog.csdn.net/cnweike/article/details/39083089

所谓脑裂问题(类似于精神分裂),就是同一个集群中的不同节点,对于集群的状态有了不一样的理解。

 

今天,Elasticsearch集群出现了查询极端缓慢的情况,通过以下命令查看集群状态:

curl -XGET ‘es-1:9200/_cluster/health‘

发现,集群的总体状态是red,本来9个节点的集群,在结果中只显示了4个;但是,将请求发向不同的节点之后,我却发现即使是总体状态是red的,但是可用的节点数量却不一致。

 

正常情况下,集群中的所有的节点,应该对集群中master的选择是一致的,这样获得的状态信息也应该是一致的,不一致的状态信息,说明不同的节点对master节点的选择出现了异常——也就是所谓的脑裂问题。这样的脑裂状态直接让节点失去了集群的正确状态,导致集群不能正常工作。

 

可能导致的原因:

 

1. 网络:由于是内网通信,网络通信问题造成某些节点认为master死掉,而另选master的可能性较小;进而检查Ganglia集群监控,也没有发现异常的内网流量,故此原因可以排除。

2. 节点负载:由于master节点与data节点都是混合在一起的,所以当工作节点的负载较大(确实也较大)时,导致对应的ES实例停止响应,而这台服务器如果正充当着master节点的身份,那么一部分节点就会认为这个master节点失效了,故重新选举新的节点,这时就出现了脑裂;同时由于data节点上ES进程占用的内存较大,较大规模的内存回收操作也能造成ES进程失去响应。所以,这个原因的可能性应该是最大的。

 

应对问题的办法:

 

 

1. 对应于上面的分析,推测出原因应该是由于节点负载导致了master进程停止响应,继而导致了部分节点对于master的选择出现了分歧。为此,一个直观的解决方案便是将master节点与data节点分离。为此,我们添加了三台服务器进入ES集群,不过它们的角色只是master节点,不担任存储和搜索的角色,故它们是相对轻量级的进程。可以通过以下配置来限制其角色:

 

[plain] view plain copy
 
  1. node.master: true  
  2. node.data: false  

当然,其它的节点就不能再担任master了,把上面的配置反过来即可。这样就做到了将master节点与data节点分离。当然,为了使新加入的节点快速确定master位置,可以将data节点的默认的master发现方式有multicast修改为unicast:

 

 

 

[plain] view plain copy
 
  1. discovery.zen.ping.multicast.enabled: false  
  2. discovery.zen.ping.unicast.hosts: ["master1", "master2", "master3"]  

 

2. 还有两个直观的参数可以减缓脑裂问题的出现:

discovery.zen.ping_timeout(默认值是3秒):默认情况下,一个节点会认为,如果master节点在3秒之内没有应答,那么这个节点就是死掉了,而增加这个值,会增加节点等待响应的时间,从一定程度上会减少误判。

discovery.zen.minimum_master_nodes(默认是1):这个参数控制的是,一个节点需要看到的具有master节点资格的最小数量,然后才能在集群中做操作。官方的推荐值是(N/2)+1,其中N是具有master资格的节点的数量(我们的情况是3,因此这个参数设置为2,但对于只有2个节点的情况,设置为2就有些问题了,一个节点DOWN掉后,你肯定连不上2台服务器了,这点需要注意)。

以上是关于elasticSearch:避免es集群的“脑裂”现象的主要内容,如果未能解决你的问题,请参考以下文章

如何防止ElasticSearch集群出现脑裂现象(转)

elasticsearch系列八:ES 集群管理(集群规划集群搭建集群管理)

Elasticsearch 分布式搜索引擎 -- 搭建ES集群 集群状态监控(cerebro) 创建集群索引库 集群脑裂问题 集群职责划分 集群分布式存储 集群分布式查询 集群故障转移

集群搭建(脑裂)

关于Elasticsearch集群脑裂brain-split的预防与解决

Elasticsearch之打分机制集群搭建脑裂问题