出现:
在搭建hadoop的HA集群环境后,由于两个namenode的状态不一,当active的namenode由于网络等原因出现假死状态,standby接收不到active的心跳,因此判断active的namenode宕机,但实际上active并没有死亡。此时standby的namenode就会切换成active的状态,保证服务能够正常使用。若原来的namenode复活,此时在整个集群中就出现2个active状态的namenode,该状态成为脑裂。脑裂现象可能导致这2个namenode争抢资源,从节点不知道该连接哪一台namenode,导致节点的数据不统一,这在企业生产中是不可以容忍的。
在使用zookeeper的过程中,我们经常会看到这样一些说法:
1.zookeeper cluster的节点数目必须是奇数。
2.zookeeper 集群中必须超过半数节点(Majority)可用,整个集群才能对外可用。
这个说法在大多数情况下是正确的。
实际上ZooKeeper提供了几种方式来认定整个集群是否可用,Majority只是其中的一种。
(http://zookeeper.apache.org/doc/r3.3.5/zookeeperInternals.html)
1. Majority Quorums
2. Weight
3. Hierarchy of groups
所谓整个集群是否可用,隐含的一个意思就是整个集群还能够选举出一个”Leader”。
ZooKeeper默认设置的是采用Majority Qunroms的方式来支持Leader选举。在ZooKeeper中Quorums有2个作用:
1. 集群中最少的节点数用来选举Leader保证集群可用
2. 通知客户端数据已经安全保存前集群中最少数量的节点数已经保存了该数据。一旦这些节点保存了该数据,客户端将被通知已经安全保存了,可以继续其他任务。而集群中剩余的节点将会最终也保存了该数据
采用Quoroms投票的方式来选举Leader主要是为了解决“Split-Brain”问题( http://linux-ha.org/wiki/Split_Brain)。
Split-Brain问题说的是1个集群如果发生了网络故障,很可能出现1个集群分成了两部分,而这两个部分都不知道对方是否存活,不知道到底是网络问题还是直接机器down了,所以这两部分都要选举1个Leader,而一旦两部分都选出了Leader, 并且网络又恢复了,那么就会出现两个Brain的情况,整个集群的行为不一致了。
所以集群要防止出现Split-Brain的问题出现,Quoroms是一种方式,即只有集群中超过半数节点投票才能选举出Leader。
这样的方式可以确保leader的唯一性,要么选出唯一的一个leader,要么选举失败.
ZooKeeper默认采用了这种方式。更广义地解决Split-Brain的问题,一般有3种方式:
解决方案:
1、添加心跳线。
原来两个namenode之间只有一条心跳线路,此时若断开,则接收不到心跳报告,判断对方已经死亡。此时若有2条心跳线路,一条断开,另一条仍然能够接收心跳报告,能保证集群服务正常运行。2条心跳线路同时断开的可能性比1条心跳线路断开的小得多。再有,心跳线路之间也可以HA(高可用),这两条心跳线路之间也可以互相检测,若一条断开,则另一条马上起作用。正常情况下,则不起作用,节约资源。
2、启用磁盘锁。
由于两个active会争抢资源,导致从节点不知道该连接哪一台namenode,可以使用磁盘锁的形式,保证集群中只能有一台namenode获取磁盘锁,对外提供服务,避免数据错乱的情况发生。但是,也会存在一个问题,若该namenode节点宕机,则不能主动释放锁,那么其他的namenode就永远获取不了共享资源。因此,在HA上使用"智能锁"就成为了必要措施。"智能锁"是指active的namenode检测到了心跳线全部断开时才启动磁盘锁,正常情况下不上锁。保证了假死状态下,仍然只有一台namenode的节点提供服务。
3、设置仲裁机制
脑裂导致的后果最主要的原因就是从节点不知道该连接哪一台namenode,此时如果有一方来决定谁留下,谁放弃就最好了。因此出现了仲裁机制,比如提供一个参考的IP地址,当出现脑裂现象时,双方接收不到对方的心跳机制,但是能同时ping参考IP,如果有一方ping不通,那么表示该节点网络已经出现问题,则该节点需要自行退出争抢资源的行列,或者更好的方法是直接强制重启,这样能更好的释放曾经占有的共享资源,将服务的提供功能让给功能更全面的namenode节点。
相关推荐
基于ZooKeeper的集群节点管理方案的设计与实现,李文韵,崔毅东,随着集群技术的普及,集群技术在节点管理方面的缺陷也日益凸显。无法及时了解集群中各节点的资源状态,无法对节点管理给予有效的
本文提出了一种基于ZooKeeper 的配置信息存储方案。首先介绍了ZooKeeper 的架构和ZooKeeper 的相关概念,然后分析了当前配置信息存储方案的不足;...基于ZooKeeper 的配置信息存储方案,包括架构和实现方案
今天小编就为大家分享一篇关于Dubbo无法访问远程Zookeeper已注册服务的问题解决方案,小编觉得内容挺不错的,现在分享给大家,具有很好的参考价值,需要的朋友一起跟随小编来看看吧
Zookeeper双机房容灾方案,以5个zk实例为例 本文在最前面给出操作该集群用的的知识 然后针对可能出现的问题,需要确认的事项进行测试 在最后给出本文的Zookeeper容灾方案
包含Zookeeper-3.4.10和Zookeeper-3.5.7的压缩包
zookeeper-3.4.10和zookeeper-3.4.12
zookeeper的分布式全局锁纯代码解决方案,特点:易上手,可二次开发和封装。
zookeeper升级方案,线上环境实战,新老版本切换。由于公司内部zookeeper集群系统版本较低,对于一些特性的支持上有点欠缺,于是决定进行对zookeeper进行升级操作。从3.3.4升级至3.4.8。
dubbo+zookeeper缓存方案 dubbo+zookeeper缓存方案dubbo+zookeeper缓存方案dubbo+zookeeper缓存方案
zookeeper 服务监控和管理,zookeeper 服务监控和管理
Zookeeper可以进行集群的配置管理,名字服务,分布式锁,集群管理等等
zookeeper3.4.14安装包和配置文件zoo.cfg, 安装流程请查看我的博客。
使用dubbo+zookeeper搭建的分布式代码案例,包含全套的代码和分布式集成的说明文档。
主要介绍了Docker下安装zookeeper(单机和集群),文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧
apache-zookeeper-3.7.1 apache-zookeeper-3.7.1 apache-zookeeper-3.7.1 apache-zookeeper-3.7.1 apache-zookeeper-3.7.1 apache-zookeeper-3.7.1 apache-zookeeper-3.7.1 apache-zookeeper-3.7.1 apache-zookeeper...
Zookeeper 配置和集群操作 Zookeeper 是一个基于 Java 的分布式应用程序协调服务,提供了配置管理、命名、提供分布式同步和提供组服务等功能。下面将对 Zookeeper 的配置和集群操作进行详细说明。 Zookeeper 配置 ...
linux下编译zookeeper3.7.0出的头文件和库: proto.h recordio.h zookeeper.h zookeeper.jute.h zookeeper_log.h zookeeper_version.h libzookeeper_mt.a libzookeeper_mt.la libzookeeper_mt.so libzookeeper_mt....
zookeeper3.8和Dubbo-bin安装包
zookeeper安装和选举说明
#Zookeeper的日志可以用LogFormatter查看 ##命令方式如下 java -classpath .:slf4j-api-1.7.2.jar:zookeeper-3.4.6.jar org.apache.zookeeper.server.LogFormatter /var/lib/zookeeper/version-2/log.1 ##window...