记录线上Hadoop集群两个namenode都是standby状态
Hadoop集群产生异常的原因
线上集群扩容,集群要停机重启。发现两个
namenode
都为standby
状态,这种问题存在的原因大部分都是因为Zookeeper
的zkfc
进程未启动成功,当然即使你启动了Zookepper
进程也是没用的,因为此时只要ZKFC
进程未启动的话,那么,HDFS
就没办法与Zookeeper
之间建立沟通的桥梁。ZKFC
是ZooKeeper
中用于自动故障转移的组件,也监视和管理NameNode
的状态。每个运行NameNode
的主机也运行了一个ZKFC
进程。有了ZKFC
之后NameNode之间才可以热切换。
Zookeeper在HA自动故障转移的功能
故障检测:集群中的每个
NameNode
在ZooKeeper
中维护了一个持久会话,如果机器崩溃,ZooKeeper
中的会话将终止,ZooKeeper
通知另一个NameNode
需要触发故障转移。ZooKeeper
提供了一个简单的机制用于唯一的选择一个节点为active
状态。如果目前现役NameNode
崩溃,另一个节点可能从ZooKeeper
获得特殊的排外锁以表明它应该成为现役NameNode
。
#HDFS故障转移的组件
自动故障转移为HDFS部署增加了两个新组件:
ZooKeeper
和ZKFailoverController
(ZKFC
)进程。ZooKeeper
是维护少量协调数据,通知客户端这些数据的改变和监视客户端故障的高可用服务。
#ZFKC故障自动转移组件
ZKFC是自动故障转移中的另一个新组件,是
ZooKeeper
的客户端,也监视和管理NameNode
的状态。每个运行NameNode
的主机也运行了一个ZKFC
进程,ZKFC
负责:
健康监测:ZKFC使用一个健康检查命令定期地ping与之在相同主机的NameNode,只要该NameNode及时地回复健康状态,ZKFC认为该节点是健康的。如果该节点崩溃,冻结或进入不健康状态,健康监测器标识该节点为非健康的。
ZooKeeper会话管理:当本地NameNode是健康的,ZKFC保持一个在ZooKeeper中打开的会话。如果本地NameNode处于active状态,ZKFC也保持一个特殊的znode锁,该锁使用了ZooKeeper对短暂节点的支持,如果会话终止,锁节点将自动删除。
基于ZooKeeper的选择:如果本地NameNode是健康的,且ZKFC发现没有其它的节点当前持有znode锁,它将为自己获取该锁。如果成功,则它已经赢得了选择,并负责运行故障转移进程以使它的本地NameNode为active。故障转移进城与前面描述的手动故障转移相似,首先如果必要保护之前的现役NameNode,然后本地NameNode转换为active状态。
Zookeeper部署建议
在典型部署中,ZooKeeper守护进程运行在三个或者五个节点上,但由于ZooKeeper本身需要较少的资源,所以将ZooKeeper部署在与现役NameNode和待机NameNode相同的主机上,还可以将ZooKeeper部署到与YARN的ResourceManager相同的节点上。建议配置ZooKeeper将数据存储在与HDFS元数据不同的硬盘上以得到最好的性能和隔离性。在配置自动故障转移之前需要先停掉集群,目前在集群运行时还不可能将手动故障转移的安装转换为自动故障转移的安装。
TroubleShooting
先停掉
Hadoop
集群可以在任一
NameNode
中运行下面的命令实现该目的,该命令在ZooKeeper
中创建znode
:1
hdfs zkfc -formatZK
本博客所有文章除特别声明外,均采用 CC BY-SA 4.0 协议 ,转载请注明出处!