各位搭过Hadoop HA集群的朋友应该都遇到过这种场景主备两个NameNode都配好了ZooKeeper和JournalNode也跑着但无论怎么手动切换或者干脆让集群自动故障转移NameNode状态都卡在Standby不动Active节点挂掉之后也没人接管。排查到最后多半是ZKFC进程没起来。在Linux环境下的Hadoop集群里ZKFCZooKeeper Failover Controller就是负责NameNode自动故障转移的那个幕后角色。这篇文章就从实际运维角度把ZKFC的启动原理、准备条件、具体命令、验证方式和常见坑一次讲透照着做就能搞定。1. 先搞清楚ZKFC到底是干什么的再谈启动1.1 没有ZKFC的HA集群就像有副驾驶却没装联动油门很多人以为Hadoop HA就是开着两个NameNode一个Active一个Standby主挂了备用顶上。这话只说对了一半。两个NameNode进程之间其实不会主动“通气”它们各自运行谁都不知道对方是活着还是死了。真正决定哪个节点该接管服务的是ZKFC。ZKFC的全称是ZooKeeper Failover Controller翻译过来就是“ZooKeeper故障转移控制器”。它是一个独立的Java守护进程通常和NameNode跑在同一台机器上。你可以把它理解为HA集群里的“哨兵”它盯着自己所在节点的NameNode同时通过ZooKeeper和其他节点的ZKFC通信大家一起决定谁来当Active。如果你在Linux上部署的是两个NameNode节点却只启动了NameNode进程而忘了启动ZKFC那么整个集群就像一辆有副驾驶却完全没有联动油门的车——副驾驶能看到路况也能喊但方向盘和油门根本连不上真要出事故他什么都做不了。1.2 ZKFC的三个核心动作监控、上报、接管ZKFC不是简单的“心跳”进程它一共干三件事监控本机NameNode健康状态通过本地的健康检查接口判断当前NameNode是否还活着RPC服务是否正常响应是否处于“应该存活”的状态。向ZooKeeper上报状态并竞争Active锁每个ZKFC都会尝试在ZooKeeper上创建一个临时的Active标识节点锁谁抢到了锁谁对应的NameNode就允许成为Active。这个锁是临时节点ZKFC自己不行了、或者与ZooKeeper会话断了锁会自动消失其他ZKFC就能接管。触发故障转移并执行隔离当某个ZKFC发现自己的NameNode挂了ZooKeeper上的锁又会因为会话超时被释放另一个节点的ZKFC就会收到通知把自己的NameNode从Standby切换成Active。同时为了保证不出现两个NameNode同时活跃的“裂脑”现象ZKFC还会执行fencing操作比如通过sshfence等机制把已经掉的节点真正隔离掉。理解了这三个动作你就不难明白启动ZKFC本质上就是启动一个NameNode的“代理人”。NameNode自己是不会去抢Active的真正去抢锁、去协调、去切换的是ZKFC。所以回到文章标题在Linux的Hadoop集群中启动ZKFC这件事本身不难难的是理解它为什么必须启动、什么时候启动、启动之后如何验证它已经正常参与选举。下面的内容全部围绕这三个问题展开。2. 启动ZKFC之前这些准备项没做完等于白搭2.1 检查配置文件里的三个关键入口ZKFC不是一个随便就能启动的进程它启动后第一件事就是去读Hadoop的配置如果关键配置缺失启动报错都算好的更怕进程起来了却不干活让人白查半天。在Linux上配置文件一般位于$HADOOP_CONF_DIR也就是core-site.xml和hdfs-site.xml。用hdfs --daemon start zkfc或老版本的hadoop-daemon.sh start zkfc启动时它首先会去校验以下三块内容第一块ZooKeeper quorum地址。在core-site.xml里必须有这个配置property nameha.zookeeper.quorum/name valuenode1:2181,node2:2181,node3:2181/value /property这是ZKFC连接ZooKeeper集群的地址。注意这里不是单个ZooKeeper而是多个ZKFC会随机选择一个连接失败后自动切换。如果这个配置没写ZKFC启动会直接告诉你找不到配置。第二块自动故障转移总开关。在core-site.xml里必须有property namedfs.ha.automatic-failover.enabled/name valuetrue/value /property这个开关是ZKFC能参与自动故障转移的前提。如果它是false那么即便你手动把ZKFC进程拉起来ZKFC也会认为自己不需要工作或者直接抛异常退出。在Hadoop 2.x早期版本里手动启动ZKFC时如果这个开关没打开日志里会出现“Automatic failover is not enabled”之类的信息。第三块NameSpace和相关NameNode地址。在hdfs-site.xml里至少要有dfs.nameservices、dfs.ha.namenodes.nameservice以及两个NameNode的RPC地址。比如property namedfs.nameservices/name valuemycluster/value /property property namedfs.ha.namenodes.mycluster/name valuenn1,nn2/value /property property namedfs.namenode.rpc-address.mycluster.nn1/name valuenode1:8020/value /property property namedfs.namenode.rpc-address.mycluster.nn2/name valuenode2:8020/value /propertyZKFC启动后会通过这个配置找到自己对应的NameNode地址并向它发送状态查询请求。如果没有这些配置ZKFC甚至不知道自己该监控谁。建议在启动前做一个最简单的检查在所有需要运行ZKFC的节点上执行hdfs getconf -confKey dfs.ha.automatic-failover.enabled如果返回true再执行hdfs getconf -confKey ha.zookeeper.quorum确认地址不是空的。这一步虽然简单但在多节点集群里特别有用——因为经常有人只改了一台节点的配置就开跑其他节点还在用旧配置。2.2 ZooKeeper、JournalNode、NameNode的启动顺序ZKFC依赖的东西很多但不是每个都要在它启动前完全就绪。以我自己的实操经验推荐的启动顺序是这样启动ZooKeeper集群。在三台或五台机器上执行zkServer.sh start然后用zkServer.sh status确认是leader还是follower至少看到集群中有leader才能继续。启动JournalNode。在每个JournalNode节点上执行hdfs --daemon start journalnode。JournalNode是Active NameNode写edit log的地方备NameNode要靠它同步元数据。启动两个NameNode。先启动第一个作为Active的那个执行hdfs --daemon start namenode。这时它会是Standby因为还没有ZKFC去抢锁。再启动第二个NameNode同样也是Standby。启动ZKFC。在第一个NameNode节点上启动hdfs --daemon start zkfc几秒钟后在第二个NameNode节点上也启动同样的命令。理论上你可以先启动两个ZKFC再启动NameNodeZKFC会周期性地检测NameNode是否就绪。但实践中我发现先启动NameNode观察hdfs haadmin -getAllServiceState能看到两个Standby再逐台启动ZKFC这样便于定位问题。如果顺序乱了也不至于起不来但日志会多很多“NameNode is not ready”之类的重试信息容易干扰判断。2.3 首次启动前要不要做 formatZK这是一个非常容易踩坑的点。首次搭建HA集群时你需要在ZooKeeper上初始化HA状态这个动作由命令hdfs zkfc -formatZK完成。这个命令的作用是在ZooKeeper上创建/hadoop-ha/nameservice这个znode路径并清除旧的数据。如果你之前没有跑过这个命令第一次直接启动ZKFC日志里会报错或者警告“Parent znode does not exist”因为ZKFC要去创建临时锁节点结果发现父节点还没建好。注意formatZK不是每次都要做。它只在两种情况下需要集群首次搭建ZooKeeper上还没有对应的znode。你修改了dfs.nameservices或者改变了集群拓扑需要清空旧的故障转移状态。特别提醒不要在集群正常运行期间随便执行formatZK。它会删除ZooKeeper上的所有HA状态信息包括当前的Active锁。一旦执行正在运行的ZKFC会瞬间丢失锁然后重新选举可能导致Active切换一次这期间客户端会出现短暂不可用。我在一次模拟演练中干过这事教训很深。所以如果你的集群已经运行过且之前创建过znode直接启动ZKFC就行不需要再format。3. 手动启动ZKFC的完整命令与验证链路3.1 新版老版命令的差异在Linux上手动启动ZKFC根据Hadoop版本不同命令有两套。老版本Hadoop2.x早期以及很多沿用旧脚本习惯的同学会使用hadoop-daemon.sh start zkfc新版本Hadoop2.6之后推荐3.x同样可用会使用统一的daemon管理方式hdfs --daemon start zkfc两者的效果是一样的都是把ZKFC作为独立守护进程后台启动日志写在$HADOOP_LOG_DIR下。区别主要是hadoop-daemon.sh已经标记为deprecated在新环境下我更推荐直接用hdfs --daemon这样和启动NameNode、JournalNode的命令风格统一也方便用一条hdfs --daemon stop zkfc停止。另外ZKFC进程在JPS命令里显示的名字是DFSZKFailoverController。所以如果你执行jps能看到类似这样的输出12345 NameNode 12346 DFSZKFailoverController注意不是“ZKFC”三个字母而是DFSZKFailoverController。有些同学用ps -ef | grep zkfc找不到进程就是因为没注意进程名。3.2 在哪个节点上执行顺序有没有讲究集群里有两个NameNode就必须在两个NameNode节点上各启动一个ZKFC。不能只在Active节点上启动一个那样Standby节点永远无法接管。也不能在第三台机器上启动——ZKFC必须和NameNode同机因为它要通过本机地址比如127.0.0.1的health check监控NameNode状态跨机器监控在默认配置下是行不通的。执行顺序上先启动哪个都可以。我个人的习惯是“先Standby后Active”其实启动时两个都是Standby无所谓先后。我更习惯在准备作为主节点的机器上先启动观察它是否能抢到Active锁再启动备节点。这样如果第一台抢到锁失败日志就在眼前排查起来更方便。具体操作登录node1NameNode1所在机器执行hdfs --daemon start zkfc等待2到3秒执行hdfs haadmin -getAllServiceState如果一切正常且node1抢到Active锁你会看到类似node1:8020 active node2:8020 standby再登录node2执行同样的hdfs --daemon start zkfc然后再次执行hdfs haadmin -getAllServiceState。理想状态下node1依然是activenode2依然是standby。如果这个时候node1变成了standbynode2变成了active说明node1那边的ZKFC有问题或者锁被抢走了需要回头查日志。3.3 启动后一眼判断进程是否健康启动完ZKFC不能只看jps里有没有进程还要确认它真的和ZooKeeper建立了会话。常用的验证方式有这么几个第一看日志文件。ZooKeeper的日志在$HADOOP_LOG_DIR目录下文件名是hadoop-hdfs-zkfc-主机名.log。用命令tail -100 $HADOOP_LOG_DIR/hadoop-hdfs-zkfc-*.log正常情况下你会看到类似这样的关键行INFO zookeeper.ZooKeeper: Session: 0x... established INFO ha.ActiveStandbyElector: Successfully created /hadoop-ha/mycluster/ActiveStandbyElectorLock INFO ha.DFSZKFailoverController: Successfully transitioned NameNode to Active state如果只看到“Session established”而没有“Successfully transitioned”说明ZKFC已经连上ZooKeeper但还没把本机NameNode切换成Active可能是另一个节点占了锁这本身不算错误只要一个Active一个Standby就是正常的。第二看ZooKeeper里的znode。在有zkCli.sh的节点上通常是ZooKeeper所在机器执行$ZOOKEEPER_HOME/bin/zkCli.sh -server node1:2181 get /hadoop-ha/mycluster/ActiveStandbyElectorLock如果返回了数据说明锁已经被某个ZKFC创建了。配合下面的命令可以查看锁里记录的主机名dump或者直接在zkCli中执行get /hadoop-ha/mycluster/ActiveStandbyElectorLock数据部分会包含哪一个NameNode成为了Active。第三看端口连接数。ZKFC本身不监听对外端口但它会主动连接ZooKeeper的2181端口。在NameNode节点上执行netstat -anp | grep 2181能看到一条ESTABLISHED连接对端IP是ZooKeeper节点进程名称显示是java。如果一条都没有说明ZKFC没连ZooKeeper就算进程活着也是白搭。3.4 从Standby到Active用常见场景验证启动完成后强烈建议做一次“人工模拟故障”来验证ZKFC真的有用。最干净的方法是直接杀掉Active节点的NameNode进程但不要动ZKFC。比如现在的状态是node1是activenode2是standby。在node1上执行kill -9 $(jps | grep NameNode | awk {print $1})注意不要用hdfs --daemon stop namenode因为那是优雅停止ZKFC收到NameNode优雅退出的通知后可能会主动让出Active锁而kill -9会模拟突发崩溃更能检验ZKFC的故障转移能力。杀掉NameNode后等待大约30秒到1分钟在node2上执行hdfs haadmin -getAllServiceState正常情况下node2应该变成active。如果node2依然standby或者两个都是standby说明ZKFC的故障转移链路有问题需要按下一节的排查思路处理。做完这个测试后记得把node1的NameNode再拉起来它会是standby再观察ZKFC是否正常让它参与下一次故障转移。这样一轮测试下来ZKFC的启动验证才算完整。4. 把ZKFC纳入集群自启避免每次重启手工拉起4.1 加到 start-dfs.sh 自动启动的适用条件手动启动ZKFC适合首次搭建和排错但生产环境不可能每次开机都手动敲命令。常见做法是把ZKFC并入集群统一的启动脚本。Hadoop的start-dfs.sh在执行时不仅会启动NameNode和DataNode还会检查dfs.ha.automatic-failover.enabled是否为true。如果是它会在每个NameNode节点上自动启动ZKFC。也就是说如果你的配置正确其实根本不用手动启动ZKFC直接运行start-dfs.sh就能一起起来。但这里有个细节start-dfs.sh默认会在你执行命令的那台机器上读取配置文件然后通过SSH登录到其他节点执行启动。如果节点间SSH免密没有配好或者各节点HADOOP_CONF_DIR路径不一致ZKFC可能只在某一台起来了另一台没有。所以就算用了start-dfs.sh建议启动后仍然用jps确认每个NameNode节点上都有DFSZKFailoverController。如果你不想依赖start-dfs.sh也可以在hadoop-env.sh里加一个HADOOP_CONF_DIR的source但更推荐直接在节点的crontab或systemd层面做托管这样最可控。4.2 通过systemd托管ZKFC的实操例子在Linux上使用systemd托管ZKFC的好处是进程崩了会自动拉起开机自动启动日志也方便用journalctl查看。下面是一个简单可用的systemd unit示例。在每台NameNode节点上创建文件/etc/systemd/system/hdfs-zkfc.service[Unit] DescriptionHadoop ZKFC for NameNode HA Afternetwork-online.target zooKeeper.service Wantsnetwork-online.target [Service] Typeforking Userhdfs Grouphdfs EnvironmentHADOOP_HOME/opt/hadoop EnvironmentHADOOP_CONF_DIR/etc/hadoop/conf ExecStart/opt/hadoop/bin/hdfs --daemon start zkfc ExecStop/opt/hadoop/bin/hdfs --daemon stop zkfc PIDFile/opt/hadoop/hadoop-hdfs-zkfc.pid Restarton-failure RestartSec10s [Install] WantedBymulti-user.target注意几个细节User和Group要改成你实际运行Hadoop的用户千万别用root。PIDFile路径要确保目录有写权限如果不定PIDFile也可以Typeforking依赖脚本自己fork但最好还是设置。After里写zooKeeper.service只是为了排序如果你的ZooKeeper不是systemd启动的可以把这行去掉改成本机网络起来后等几秒。写完文件后执行systemctl daemon-reload systemctl enable hdfs-zkfc systemctl start hdfs-zkfc systemctl status hdfs-zkfc这样ZKFC就变成了一个常驻服务。你在两个NameNode节点都要做一次这个配置。还有一个取巧的办法如果你不想写systemd也可以直接在/etc/rc.local里追加启动命令但这已经是老古董做法不建议在生产环境用。5. 启动ZKFC时最常见的四个坑以及排查思路5.1 日志先于上层工具告诉你真相任何启动相关的问题第一手资料永远是日志。ZKFC的日志路径前面提过默认在$HADOOP_LOG_DIR下文件名带zkfc关键词。如果你配置了日志聚合也可以通过YARN或MapReduce日志页面查看但启动阶段直接tail本机日志最直接。有些同学一遇到ZKFC起不来第一反应去检查防火墙或者重启ZooKeeper这其实是绕远路。正确顺序是先看ZKFC的log找到第一行ERROR或Exception。根据异常类型判断是配置、网络还是权限问题。举个例子常见的第一行错误可能是java.net.UnknownHostException: zk1这说明ha.zookeeper.quorum里的主机名解析不了去/etc/hosts加解析即可。再比如org.apache.zookeeper.KeeperException$NodeExistsException这通常不是致命错误只是两个ZKFC在抢锁其中一个抢不到日志就会打这条另一个节点才是active。如果你分不清“正常抢锁失败”和“异常”就会误判。5.2 连不上ZooKeeper先分清网络还是配置ZKFC启动最典型的故障是连不上ZooKeeper。日志里会出现Unable to connect to ZooKeeper这种时候先在NameNode节点上用网络工具测试到ZooKeeper的连通性。假设配置的是node1:2181,node2:2181,node3:2181那么在本地执行telnet node1 2181或者用nc -vz node1 2181。如果通了再检查是不是ZKFC使用的java.net解析有问题比如hosts里写错了IP。如果网络没问题ZooKeeper也正常但还是连不上看看ZooKeeper的maxClientCnxns参数是不是设得太小。经典场景是ZooKeeper同机上一堆临时客户端连接数达到上限ZKFC被拒。这时调大ZooKeeper配置里的maxClientCnxns或者干脆不设置重启ZooKeeper再试。另外如果ZKFC进程是以hdfs用户启动的但ZooKeeper的路径权限有问题也可能出现连接被拒绝。不过这种情况相对少见先按网络和配置两个维度排查。5.3 进程起来了但一直是Standby怎么看日志和锁状态常见场景是两个ZKFC进程都活着但两个NameNode都是standby也就是没人抢到Active锁。这时候先查日志里有没有这两行INFO ha.ActiveStandbyElector: Trying to create /hadoop-ha/mycluster/ActiveStandbyElectorLock INFO ha.ActiveStandbyElector: Successfully created ... ActiveStandbyElectorLock如果两台机器都只看到“Trying”而没有“Successfully”说明它们连ZooKeeper没问题但创建锁的时候失败了。去ZooKeeper上执行get /hadoop-ha/mycluster/ActiveStandbyElectorLock看看这个znode是不是已经存在如果存在而持有锁的ZKFC也已经连上了ZooKeeper那问题多半出在“锁的持有者是谁”的判断上。再有一种情况是某台ZKFC认为自己创建锁成功了但对应的NameNode却没能快速进入Active状态可能是NameNode本身还没启动完成、还在加载元数据或者处于safemode。ZKFC会不停重试但如果你只在几秒内观察可能会觉得一切正常却一直是standby。多等一会儿同时看NameNode的log是不是有“STATE entering Active”的字样。还有一种隐蔽情况dfs.ha.automatic-failover.enabled在hdfs-site.xml里写了但在core-site.xml里没写或相反。ZKFC启动时读取的是配置合并后的结果如果值不是true它可能在日志里打印“failover is not enabled”然后直接继续跑但什么都不做。这种时候用hdfs getconf -confKey dfs.ha.automatic-failover.enabled确认比翻两个xml更快。5.4 两个NameNode同时Active的防护机制如果真的发生两个NameNode同时Active那说明ZKFC没有起到隔离作用。这种情况很少见但一旦发生对元数据的破坏很大。ZKFC默认启用fencing机制通过配置dfs.ha.fencing.methods来加强。常见配置是property namedfs.ha.fencing.methods/name valuesshfence/value /property property namedfs.ha.fencing.ssh.connect-timeout/name value30000/value /propertysshfence的意思是在触发故障转移时ZKFC会通过SSH登录到对方节点然后用kill命令把对方的NameNode杀掉。如果对方的进程已经死了这条fencing就算成功。如果SSH免密没配置好fencing会失败ZKFC会拒绝让本机成为Active从而避免双主。所以如果你在生产环境里看到某次故障转移失败日志里有“Unable to fence”的字样多半是SSH免密或者fencing命令执行权限的问题。这也是启动ZKFC之前就该检查的一项从每个NameNode到另一个NameNode的SSH免密要能通。6. 我的一些手工运维习惯最后分享几个从实际运维中沉淀下来的习惯不一定写在官方文档里但对日常维护特别有用。第一重启ZKFC和重启NameNode的顺序尽量固定。我一般遵循“先停NameNode再停ZKFC启动时反过来先启动ZKFC再启动NameNode”。为什么要这样因为ZKFC在启动时会去检查NameNode是否就绪如果NameNode还没起来它会重试等待等NameNode起来后自动接手。反过来如果NameNode先起来且一直没人抢锁它就一直Standby倒也不出问题只是日志看起来会比较乱。为了日志清爽让ZKFC先跑起来重试其实是个好习惯。第二把验证命令做成一个脚本。我习惯在集群的某个管理节点上放一个shell脚本内容大致是hdfs haadmin -getAllServiceState hdfs dfsadmin -report -live每次重启或维护后都执行一次。如果看到两个NameNode的状态一主一备DataNode连接正常那ZKFC基本没问题。第三不要手动去kill一个看起来多出来的ZKFC进程。如果你发现某台节点上有两个DFSZKFailoverController可能是因为之前用hdfs --daemon start启动了又手动执行了hadoop-daemon.sh导致重复启动。这种情况下不要直接kill -9随便杀一个先查两个进程的PIDFile和启动参数确认哪个是“真货”然后按官方停止命令优雅停掉再清理残留进程。否则可能会让ZooKeeper上的锁状态混乱引起不必要的切换。另外如果你的Hadoop版本是3.x我建议在升级后重新测试一次ZKFC的完整故障转移流程因为不同小版本之间关于dfs.ha.automatic-failover.enabled的默认值和日志格式有过调整命令行为也可能有变化。测试很简单就是前面提到过的kill掉Active NameNode看备节点能否接管。ZKFC这种进程就是这样平时看起来毫无存在感一旦真的发生NameNode所在机器宕机或者进程异常退出它能不能把集群从崩溃边缘拉回来全看你启动时有没有做对细节、有没有验过故障转移链路。希望这篇文章能帮你在下一次搭建或维护HA集群时少走弯路。