我搭建Hadoop高可用集群前前后后折腾了快两周踩了无数坑才把一套能扛故障的环境跑起来。这篇文章想把这套完整的部署过程写出来包括每台机器上做什么、每个配置文件为什么这么改、故障转移到底怎么验证不只要让你照着做能跑通更要让你理解每一步背后的原理。这套方案基于我实际使用的三节点架构两台机器跑NameNode主备角色三台机器跑JournalNode和ZooKeeper同时每台机器都跑DataNode和NodeManager。后面涉及的所有版本、配置、命令都是我在生产环境验证过的直接抄作业是可行的。适合谁看呢你已经会装单机Hadoop或者伪分布式但对高可用部署还一头雾水的人最合适如果你正打算给公司或实验室搭一套不依赖单点的集群这篇文章也能帮你少走弯路。1. 为什么单点NameNode撑不住HA架构要解决的核心问题1.1 没有HA的Hadoop集群故障半径有多大很多人第一次接触Hadoop用的是伪分布式或者单NameNode集群master节点上跑着NameNode和ResourceManager看起来一切正常数据也能写能读。但这种架构有个致命问题NameNode一旦宕机整个HDFS就不可写了所有客户端连接全部失败。数据虽然还在DataNode上但你没办法知道文件在哪些块上、元数据在哪、怎么拼接出完整文件。更麻烦的是恢复过程。传统方式下你得找一台新机器把原来NameNode的数据目录拷过去重新启动这个过程少说也要几分钟到十几分钟。对离线跑批的场景还能忍但如果上层有实时写入、有OLAP查询、有业务系统在实时拉数这种中断是没法接受的。还有一个很多人忽略的点NameNode的内存中维护着整个文件系统的目录树和文件块映射进程本身很容易因为JVM Full GC、元数据量过大、磁盘IO异常等问题卡住甚至崩掉。这种故障不是靠多买一台机器就能解决的必须从架构层面提供冗余。1.2 HDFS HA与YARN HA的工作原理高可用方案的核心思路其实不复杂让同一角色跑两份一份active一份standby通过共享状态和自动选举来决定谁干活。HDFS HA依赖三个关键组件JournalNodeJN负责保存NameNode的编辑日志EditLog。Active NameNode把每一次元数据变更写到JournalNode集群Standby NameNode实时从JournalNode读取这些编辑日志并应用到自己内存中。这样一旦Active挂掉Standby的内存状态基本是实时的。ZooKeeperZK负责故障转移的决策。NameNode通过ZKFCZK Failover Controller这个独立进程向ZooKeeper注册临时节点ZK通过锁机制决定谁是Active。ZKFC这是一个与NameNode进程一一起部署的小进程它监控NameNode的健康状态并在故障发生时触发切换。YARN HA的原理类似。ResourceManagerRM也有Active和Standby之分它们把应用状态、队列状态等写入ZooKeeper或内置的LevelDB存储切换时新的Active RM会从存储中恢复状态避免正在跑的应用被直接杀光。注意这里的高可用主要指进程级的自动故障转移不保证数据零丢失。极端情况下比如Active节点直接断电可能丢失少量最近几秒的元数据变更。这在绝大多数场景下是可接受的但如果你的业务对元数据一致性要求极高需要另行设计备份策略。1.3 我采用的节点规划与角色分配很多教程喜欢用五台机器两台NameNode、三台JournalNode、三台DataNode。但对大多数人来说手头可能只有两三台物理机或云主机所以我用了三节点方案角色分配如下主机名IP规划部署角色h01192.168.10.11NameNode、ResourceManager、JournalNode、ZooKeeper、DataNode、NodeManagerh02192.168.10.12NameNode、ResourceManager、JournalNode、ZooKeeper、DataNode、NodeManagerh03192.168.10.13JournalNode、ZooKeeper、DataNode、NodeManager三台机器上都部署了DataNode和NodeManager这样存储和计算资源不浪费。JournalNode和ZooKeeper各三台正好满足奇数的选主条件。唯一的不平衡是h01和h02多跑了NameNode和ResourceManager但因为有HA其中一台挂了不影响整体。这种架构适合以下几个典型场景数据规模在几十TB以内、计算任务以离线批处理为主、集群长期运行需要保证稳定。如果你的规模更大建议把JournalNode单独拆到专用节点避免和DataNode抢IO。2. 动手前的关键决策版本组合、节点规划与网络准备2.1 版本组合与JDK的坑版本选择这里最容易翻车。我强烈建议不要盲目追求最新版而要选一套经过大量生产环境验证的稳定组合。我最终用的组合是Hadoop 3.3.4ZooKeeper 3.7.1JDK 1.8OpenJDK这里有个关键点Hadoop 3.3.x官方文档说支持JDK 8和JDK 11但在实际部署中JDK 8是最稳的。我试过用JDK 11跑Hadoop 3.3.4表面上能启动但跑一段时间后NameNode日志里会出现一些奇怪的类加载警告部分Web UI功能异常。如果你不想花时间排查这些边缘问题老老实实用JDK 8。ZooKeeper的3.7.x版本是3.4之后比较稳定的一个系列支持滚动升级配置格式也清晰。不要用3.4的老版本它和新版Hadoop的客户端库有兼容性问题。2.2 主机名映射、SSH免密与防火墙这三件事属于不做好后面全是坑的基础工作。主机名映射三台机器都要在/etc/hosts里写好彼此的映射不能用IP直接访问。因为Hadoop内部很多组件之间通过主机名通信配置里写IP虽然也能跑但某些模块尤其是ZKFC和JournalNode的通信会出怪问题。# /etc/hosts 192.168.10.11 h01 192.168.10.12 h02 192.168.10.13 h03SSH免密Hadoop集群的启停脚本通过SSH在节点间执行命令如果没有免密配置每次启停都要输密码自动化脚本根本跑不起来。我配置的是h01到所有节点的免密登录包括自身如果你有自己的操作习惯保证统一起始节点能免密访问所有节点即可。ssh-keygen -t rsa -P ssh-copy-id h01 ssh-copy-id h02 ssh-copy-id h03防火墙与SELinux这是最容易忽略但最致命的问题。很多人在本机测试时没开防火墙部署到服务器上就发现各种连接超时。最简单的做法是直接关闭防火墙针对内网集群环境systemctl stop firewalld systemctl disable firewalld setenforce 0 sed -i s/SELINUXenforcing/SELINUXdisabled/ /etc/selinux/config如果出于安全原因不能关闭防火墙至少要把下面的端口放通8020/9820HDFS RPC、9870NameNode WebUI、8088YARN WebUI、9000ZK通信、8485JournalNode RPC、8030/8031/8032/8033RM端口。但说实话内网集群直接关防火墙是主流做法。2.3 JDK安装与基础环境变量ZooKeeper和Hadoop都是Java应用。JDK安装方式两种直接下载JDK的tar.gz解压配置环境变量或使用系统包管理器安装。我更推荐前者因为版本可控且不依赖系统源。# 假设JDK已解压到 /usr/local/jdk1.8 cat /etc/profile EOF export JAVA_HOME/usr/local/jdk1.8 export PATH$PATH:$JAVA_HOME/bin export ZOOKEEPER_HOME/usr/local/zookeeper-3.7.1 export HADOOP_HOME/usr/local/hadoop-3.3.4 export PATH$PATH:$ZOOKEEPER_HOME/bin:$HADOOP_HOME/bin:$HADOOP_HOME/sbin EOF source /etc/profile java -version注意一点HADOOP_HOME这个环境变量建议统一配置很多辅助脚本比如后续可能用到的Hive、Spark都会引用它。如果漏了后面装生态组件时会绕很大圈子。3. ZooKeeper集群先落位HDFS和YARN的选举都依赖它3.1 ZooKeeper配置的逐行解析ZooKeeper虽然是独立组件但它是整个HA体系的裁判。我先搭ZK再搭HDFS顺序不能反否则NameNode格式化时注册不了ZK节点。在h01/h02/h03三台机器上分别解压ZooKeeper然后修改conf/zoo.cfg# zoo.cfg tickTime2000 initLimit10 syncLimit5 dataDir/data/zookeeper clientPort2181 server.1h01:2888:3888 server.2h02:2888:3888 server.3h03:2888:3888解释一下关键参数tickTimeZK的最小时间单元单位毫秒。2000表示一个tick为2秒。initLimit从节点连接主节点并完成初始同步的最大tick数。这里是10意味着20秒内必须完成初始化否则从节点自判连接失败。syncLimit从节点与主节点之间心跳的最大tick间隔。5个tick即10秒超过则认为主节点失联。server.NhX:2888:3888固定格式。2888是集群节点间同步数据的端口3888是选举端口。配置完后还要在dataDir指定的目录下创建myid文件# h01 上执行 mkdir -p /data/zookeeper echo 1 /data/zookeeper/myid # h02 上执行 echo 2 /data/zookeeper/myid # h03 上执行 echo 3 /data/zookeeper/myid这个myid必须与zoo.cfg中的server编号一致ZK集群靠这个文件识别自己是哪一台。3.2 启动ZK并验证集群状态三台机器分别启动zookeeper-3.7.1/bin/zkServer.sh start启动后查状态尤其是要确认哪台是leaderzookeeper-3.7.1/bin/zkServer.sh status正常情况下三台中一台显示leader两台显示follower。如果三台都是follower或者一台都起不来先看日志。常见问题是myid不一致或hosts没配好。这里说一个重要经验ZooKeeper启动失败后不要只盯着zookeeper.out这个文件看。/data/zookeeper/目录下还有一个zookeeper.log最后的报错信息更全。我在排错时经常发现有人只看了前者根本没看到真正的报错。3.3 ZK在HA里到底做了什么很多教程直接说装好ZooKeeper但很少解释它为什么重要。我用自己的话总结ZK在HDFS HA里干了三件事。第一ZKFC通过创建临时节点来竞争Active锁谁创建成功谁是Active NameNode。第二ZKFC监控局部节点的健康状态健康时维持锁不健康时释放锁。第三YARN的RM选举也依赖ZK的临时节点机制。可以说没有ZK就没有自动故障转移。理解的这层关系你在配置时有任何一步连不上ZK就能快速定位到问题。4. HDFS HA配置核心链路JournalNode、元数据同步与自动故障转移4.1 core-site.xml的核心配置Hadoop的HA配置主要在两个文件里core-site.xml和hdfs-site.xml。先说core-site.xml。configuration property namefs.defaultFS/name valuehdfs://hacluster/value /property property nameha.zookeeper.quorum/name valueh01:2181,h02:2181,h03:2181/value /property /configurationfs.defaultFS是核心的。它不再是指向某个具体NameNode地址而是指向一个逻辑名称hacluster这个名称在hdfs-site.xml里映射到两台NameNode。客户端通过这个逻辑名称访问集群Active切换后客户端不需要改任何配置因为ZK会动态告知客户端当前Active在哪。ha.zookeeper.quorum是ZK连接地址注意每个地址之间用逗号分隔不要加空格。4.2 hdfs-site.xmlnameservice、JournalNode与切换方式这里的配置项比较多我拆开讲。configuration !-- 指定nameservice逻辑名称必须与core-site.xml中的hacluster一致 -- property namedfs.nameservices/name valuehacluster/value /property !-- 列出这个nameservice下有哪些NameNode ID -- property namedfs.ha.namenodes.hacluster/name valuenn1,nn2/value /property !-- nn1和nn2各自的RPC通信地址 -- property namedfs.namenode.rpc-address.hacluster.nn1/name valueh01:8020/value /property property namedfs.namenode.rpc-address.hacluster.nn2/name valueh02:8020/value /property !-- 各自HTTP UI地址 -- property namedfs.namenode.http-address.hacluster.nn1/name valueh01:9870/value /property property namedfs.namenode.http-address.hacluster.nn2/name valueh02:9870/value /property !-- JournalNode服务的地址列表 -- property namedfs.namenode.shared.edits.dir/name valueqjournal://h01:8485;h02:8485;h03:8485/hacluster/value /property !-- 故障自动切换实现类 -- property namedfs.client.failover.proxy.provider.hacluster/name valueorg.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider/value /property !-- 启用自动故障转移 -- property namedfs.ha.automatic-failover.enabled/name valuetrue/value /property !-- NameNode的隔离机制 -- property namedfs.ha.fencing.methods/name valuesshfence/value /property property namedfs.ha.fencing.ssh.connect-timeout/name value30000/value /property !-- JournalNode的本地数据目录 -- property namedfs.journalnode.edits.dir/name value/data/hadoop/journal/value /property /configuration重点解释几个很多人看不懂的配置dfs.ha.fencing.methods这是隔离fencing机制。它在故障转移时非常重要目的是确保旧Active NameNode被真正杀掉避免两个节点同时认为自己是Active也就是所谓的脑裂。默认支持sshfence意思是通过SSH登录到旧的Active节点执行kill -9杀掉NameNode进程。这要求h01能免密SSH登录到h02反之亦然否则fencing会失败。提示sshfence有个前提就是集群间SSH免密配置要双向打通。很多人在第2步只配了单向免密结果故障转移时卡在fencing这一步。dfs.client.failover.proxy.provider这个类是客户端的故障转移代理。客户端连接hdfs://hacluster时会使用这个类去ZK里查询当前Active NameNode的地址。没有这个配置客户端永远不知道切换后的新主节点在哪。4.3 初始化的完整顺序一步错步步错HA集群的初始化顺序和伪分布式完全不同这一点必须重视。第一步在三个节点上分别启动JournalNode# 在 h01、h02、h03 上分别执行 hdfs --daemon start journalnode初始化JournalNode会创建一个空的edits日志存储空间后续所有NameNode的元数据变更都会写入这里。第二步在h01第一台NN上格式化NameNodehdfs namenode -format注意这一步只在h01上执行。格式化后h01的NameNode会生成一个初始的fsimage和空的edits文件。但这个edits文件目前存在h01本地还没同步到JournalNode。第三步在h01上启动NameNodehdfs --daemon start namenode此时h01只是以NameNode身份启动并不会去ZK注册Active因为还没有初始化ZKFC的锁状态。它的元数据会写入JournalNode。第四步在h02上执行元数据同步# 在 h02 上执行 hdfs namenode -bootstrapStandby这个命令会从h01的NameNode拉取最新的fsimage和edits日志同步到h02的本地状态。如果不执行这一步h02启动后它以为自己是全新的NameNode会拒绝接管元数据。第五步初始化ZKFC在ZK中的状态# 在 h01 上执行 hdfs zkfc -formatZK这个命令会在ZooKeeper中创建HA相关的节点路径/hadoop-ha/hacluster并初始化锁状态。它只会创建一次。第六步启动所有NameNode和ZKFC# h01、h02 上分别执行 hdfs --daemon start namenode hdfs --daemon start zkfc启动后观察日志正常情况下h01的ZKFC会成功获取Active锁h02的ZKFC保持Standby状态。第七步启动DataNode# 三台机器上分别执行 hdfs --daemon start datanode4.4 初始化阶段最常见的三个报错整个初始化过程里我遇到的报错翻来覆去就那几类。报错一Unable to determine local address或者Connection refused指向8485端口。原因是JournalNode还没完全启动或dfs.namenode.shared.edits.dir里的主机名写错了。先确认三台JN的进程在然后用telnet h01 8485测试连通性基本一分钟能定位。报错二bootstrapStandby时提示Storage directory already exists。这是因为h02的本地NameNode目录已经存在可能你之前在这台机器上试过单机模式。解决办法是清掉h02的dfs.namenode.name.dir指向的目录再重新执行bootstrapStandby。报错三zkfc启动后10秒内退出。大概率是ha.zookeeper.quorum配置里ZK地址不通或者ZK的myid配置错了。去ZK那侧看zookeeper.out日志会发现连接数异常。5. YARN高可用配置ResourceManager状态同步与切换逻辑5.1 yarn-site.xml的核心配置HDFS落地后接着配YARN高可用。虽然YARN挂了的后果不如NameNode挂那么严重数据不会丢只是资源调度中断但没有HA的话只要RM一重启所有正在跑的MapReduce作业全部失败这对上层任务是不可接受的。configuration !-- 启用RM HA -- property nameyarn.resourcemanager.ha.enabled/name valuetrue/value /property property nameyarn.resourcemanager.cluster-id/name valueyarn-ha-cluster/value /property property nameyarn.resourcemanager.ha.rm-ids/name valuerm1,rm2/value /property property nameyarn.resourcemanager.hostname.rm1/name valueh01/value /property property nameyarn.resourcemanager.hostname.rm2/name valueh02/value /property !-- RM的Web UI和客户端端口 -- property nameyarn.resourcemanager.webapp.address.rm1/name valueh01:8088/value /property property nameyarn.resourcemanager.webapp.address.rm2/name valueh02:8088/value /property !-- 状态存储ZK方式 -- property nameyarn.resourcemanager.store.class/name valueorg.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore/value /property property nameyarn.resourcemanager.zk-address/name valueh01:2181,h02:2181,h03:2181/value /property !-- 启用自动恢复 -- property nameyarn.resourcemanager.recovery.enabled/name valuetrue/value /property !-- NodeManager辅助 -- property nameyarn.nodemanager.aux-services/name valuemapreduce_shuffle/value /property property nameyarn.nodemanager.aux-services.mapreduce_shuffle.class/name valueorg.apache.hadoop.mapred.ShuffleHandler/value /property /configuration5.2 RM的切换细节与实测结果RM的HA配置好后它依赖ZKRMStateStore把所有的队列配置、应用状态、token等持久化到ZK中。当Active RM挂掉时Standby RM从ZK中读取这些状态然后接管整个集群的资源调度。这里有一个值得注意的差异HDFS的切换时延通常在几秒到十几秒而RM的切换也会类似。但切换完成后集群里正在跑的MapReduce任务不会立即恢复而是需要等ApplicationMaster重新向新RM注册。这个过程中部分任务可能会重试但业务数据不会丢。我实测过整个切换时间手动强杀RM进程后大约8秒集群重新恢复调度NodeManager开始向新RM汇报心跳新任务能正常提交。这个时间在可接受范围内。6. 故障转移实测停掉主节点看集群如何自救6.1 验证HDFS自动切换的完整步骤配置全结束代码能不能扛住事故必须实测。我的验证方法如下先确认当前Active节点hdfs haadmin -getAllServiceState输出结果预期是h01:active、h02:standby。然后在h01上直接把NameNode进程杀掉模拟宕机kill -9 PID_of_NameNode_on_h01正常情况下ZKFC会检测到NameNode进程不再响应因为sshfence会先尝试杀掉旧active然后standby获得锁h02会在大约10秒内变为active。# 再次查询 hdfs haadmin -getAllServiceState # 预期 h01:standby或挂掉、h02:active然后我在客户端上执行HDFS写操作hdfs dfs -put /etc/hosts /tmp/switch_test.txt命令正常执行说明客户端通过故障转移代理自动切换到了h02整个过程中用户无感知。6.2 验证YARN的切换类似的在h01上杀掉ResourceManager进程观察h02是否自动接管yarn rmadmin -getAllServiceState预期输出h01为standby、h02为active如果强杀后zkfc已将其标记。然后提交一个简单的MapReduce任务测试可用性hadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.3.4.jar pi 3 100任务正常跑完说明YARN HA配置生效。6.3 实测时的注意事项验活前先把ZK和JournalNode的状态都检查一遍。有些人只测NameNode切换忘了JournalNode本身也是集群三台JN如果一台坏了共享日志仍然可用JN的quorum机制允许最多挂掉一台。但如果你用了错误的配置让JN变成单点那HA就名存实亡了。注意kill -9和fencing的配合。我用kill -9模拟宕机时fencing机制其实可能没有真正触发因为进程已经死了。更严格的测试应该是把网络断开或者STOP进程而非KILL让fencing真实发挥作用。在这篇文章的场景里用kill模拟已经能说明问题但如果你想更严谨可以用systemctl stop或直接拔网线来测。7. 高可用集群运维排障我踩过的坑和排查路径7.1 DataNode启动后一直处于安全模式我遇到过集群刚启动时DataNode都注册了但NameNode一直提示Safe mode is ON不能写数据。原因在于DataNode的数据块上报进度不足阈值。HDFS默认需要收到足够多的DataNode报告块信息后才退出安全模式如果块数量大、上报慢就会卡住。排查路径用hdfs dfsadmin -safemode get查看当前阈值和块上报进度。检查DataNode日志里有没有大量的连接异常。如果确认只是块上报慢可以临时用hdfs dfsadmin -safemode leave强制退出但正常生产不要这么做等它自己退出更安全。7.2 ZooKeeper连接超时与session过期ZK session超时是高可用集群里最容易反复出现的问题。表现是ZKFC日志里不停报Session expired或Connection refused。最常见的原因是ZK的tickTime和Hadoop默认的ZK超时时间不匹配。Hadoop的ZKFC默认超时是5000ms如果你的ZK因网络波动或GC暂停导致session超过这个时间未续期ZK就会判定客户端失联并清理节点进而触发不必要的故障转移。解决思路在hdfs-site.xml中显式配置ha.zookeeper.session-timeout为更大的值比如10000ms或15000ms。改善ZK所在节点的网络稳定性尽量避免在同一台机器上跑高负载任务导致GC停顿。7.3 脑裂问题在于fencing配置其实没生效脑裂是HA架构最恐怖的问题两台NameNode同时认为自己是Active。正常情况下ZKFC通过锁机制避免并发获得Active锁但如果网络隔离或GC暂停时间过长可能出现旧Active没来得及释放锁新Active就抢到了锁的情况。此时sshfence就变得非常重要新Active在获取锁之前先通过SSH登录旧Active执行kill命令把旧进程杀掉。如果SSH免密配得不对fencing失败新Active会拒绝成为Active集群反而变成双standby这比脑裂还好一点。我实测过的经验fencing的ssh.connect-timeout不要设得太长。设成30000ms的话网络差时整个切换流程会被拖到一分钟以上前端业务早超时了。设成10000ms以内更合适。7.4 日志是排障的第一直觉来源最后总结一条通用经验。Hadoop集群问题千奇百怪但绝大多数坑都能在日志里找到答案NameNode日志$HADOOP_HOME/logs/hadoop-hdfs-namenode-*.logYARN日志$HADOOP_HOME/logs/hadoop-yarn-resourcemanager-*.logZKFC日志$HADOOP_HOME/logs/hadoop-hdfs-zkfc-*.logZooKeeper日志$ZOOKEEPER_HOME/logs/zookeeper.out排查时从那一条日志开始追往往会发现根本不是表面那个组件的问题。比如我遇到过DataNode上报失败实际是YARN的NodeManager把机器资源吃满了导致DataNode的socket被延迟这类问题只看DataNode侧日志是找不到答案的。8. 一些总结性的运维心得这套高可用集群搭完到现在我已经稳定运行了挺长时间期间也故意做了几次故障演练。个人感受是Hadoop HA的架构设计本身并不复杂难的是你对每个组件之间依赖关系的理解。把ZooKeeper、JournalNode、ZKFC、RM状态存储这几件事的原理吃透配置起来就有底气出问题也不会慌。最后想分享一个小经验高可用集群的价值不在正常时多棒而在挂掉时多稳。一些人在配置完以后就再也不管了平时也不做故障演练等到真出事故才发现切换失败、fencing超时、ZK脑裂——那时候已经晚了。建议每个月做一次切换演练主动杀掉NameNode或RM进程验证集群能否自动恢复。这个习惯看起来麻烦但真到关键时刻能救你命。所以照着我上面的步骤把集群搭起来然后一定要亲手做一遍故障转移测试。只有经历过一次主节点毫无征兆挂掉、集群却不受影响的体验你才算真正拥有了一套高可用Hadoop环境。