Hadoop高可用架构：从NameNode到ResourceManager

做大数据平台的同学，几乎没有不跟Hadoop打交道的。Hadoop本身从设计上看并不是一套天生“高可用”的系统，HDFS的NameNode和YARN的ResourceManager在早期都是典型单点，集群规模一大、业务要求一高，挂一次就够让人头疼。我在生产环境里就遇到过NameNode进程还在、但对外服务已经卡死的情况，手动切主前后折腾了快四十分钟，业务方电话一个接一个。后来把Hadoop的高可用架构完整落了一遍，才真正体会到HA不是锦上添花，而是大数据集群能不能长期稳定跑下去的底盘。这篇就结合我自己的实操，把Hadoop高可用架构设计的核心思路、NameNode和ResourceManager的HA细节、ZooKeeper整合的要点，以及我在切换和排查中踩过的一些坑，原原本本整理出来。适合正在搭集群、准备上生产或者面试前想理清HA机制的读者。

1. 高可用架构设计的核心思路

1.1 为什么Hadoop必须考虑高可用

先聊一句“为什么”。HDFS里的NameNode是集群元数据的唯一入口，所有目录、文件、block位置都记在它脑子里；NameNode一旦不可用，客户端连文件列表都拿不到，更不用说读写数据。YARN里的ResourceManager负责集群资源调度，它挂了，所有提交的任务都没法分配资源。早期Hadoop版本没有真正的HA，NameNode只有一个，所谓的备份靠SecondaryNameNode，但这个角色只是周期性合并fsimage和edits，并不能在NameNode挂掉后马上接管服务，而且还会丢失最近一段时间的元数据更新。我见过不少团队把SecondaryNameNode误当成热备，直到某天主节点磁盘损坏，才发现恢复起来极其痛苦。

因此高可用架构的核心目标就两条：一是RPO（Recovery Point Objective）尽量接近0，也就是主节点挂掉时不丢元数据；二是RTO（Recovery Time Objective）尽量短，能够在秒级或分钟级自动把服务切到备用节点。对于大数据平台来说，调度任务可能7x24小时在跑，几十个业务方依赖同一个HDFS，手动切换耗时越长，影响面越大。所以高可用不只是一个“可用性指标”，它直接关系到数据安全和业务连续性。这也是为什么Hadoop高可用架构设计会出现在各种大数据面试题里——它考察的不只是配置命令，而是对整个分布式系统容错模型的理解。

1.2 单点故障模型与HA目标

要设计高可用，先把哪些组件有单点风险列清楚。我这里整理了一个表：

从这张表能看出来，Hadoop HA不是只给某一个进程配个备机，而是从存储元数据、协调选主、日志持久化到上层任务调度都做冗余。真正落地的时候，需要把故障域考虑进去：NameNode两台不要放在同一个机架，JournalNode和ZooKeeper节点尽量分散，避免单机柜掉电把多数派一次打掉。很多人以为高可用就是“多跑一个进程”，结果把备用NameNode和主NameNode放在同一台物理机上，这种部署没有任何意义，宕机来了两个一起躺。

1.3 方案选型：冷备、热备与自动切换

Hadoop 2.x之后官方支持了多种HA模式，选型上我建议优先走“共享edits日志 + ZooKeeper自动切换”这套组合，也就是标准的QJM方案。NFS共享存储也能做NameNode HA，但NFS本身就是单点，存储设备抖动或断连会导致两个NameNode看到的数据不一致，脑裂风险很高。QJM用多个JournalNode组成日志存储组，写edits必须多数派成功才返回，这样就避免了共享存储的单点问题。我在实际对比测试中，QJM在数据一致性上明显更稳，虽然架构稍微复杂一点，但换来的安全边际完全值得。

另一个决策点是用手动切换还是自动切换。小集群、运维可以7x24小时待命，手动也能接受；但生产环境强烈建议上自动故障转移。因为故障往往发生在凌晨三点，等人起来处理不仅慢，还容易因为紧张操作失误。ZooKeeper在这里扮演的是“裁判”角色，通过ZKFC进程去监听NameNode健康状态、抢锁、决定谁做Active。这部分后面会细说。整体思路我总结成一句话：共享日志解决数据一致问题，ZooKeeper解决选主和自动切换问题，fencing解决脑裂和双主问题，三者缺一不可。

2. HDFS NameNode高可用实现细节

2.1 Active/Standby模型与共享编辑日志

HDFS HA的基本模型是一台Active、一台Standby，两台都有完整的元数据镜像（fsimage），但Standby不能对外提供写服务。要让Standby随时能接棒，就必须保证它和Active接收到的edits日志完全同步。标准做法是引入JournalNode：Active NameNode把每次元数据修改写成edits log，同时发给多个JournalNode，Standby NameNode持续从JournalNode拉取这些edits，并回放到底层内存元数据中。这样Standby的元数据状态始终和Active保持一致。

JournalNode的数量需要是奇数，通常3个或5个。为什么是奇数？因为QJM要采用多数派写入，只有写入的JournalNode数超过一半才算成功。3个节点允许挂1个，5个节点允许挂2个。节点太少容忍度低，节点太多写入开销大。我一般建议中小集群用3个，超过1000个节点的大集群可以考虑5个。注意JournalNode不是NameNode的替代品，它只负责存edits日志和参与一致性投票，内存和CPU要求不高，但磁盘IO尽量好一点，因为edits写入频率不低。我见过有人把JN目录放在系统盘，结果和操作系统日志争抢IO，NameNode写edits经常超时，这种细节很容易被忽略。

2.2 ZooKeeper在自动故障转移中的角色

ZooKeeper在HDFS HA里不是直接管理NameNode，而是管理ZKFailoverController（ZKFC）。每个NameNode机器上跑一个ZKFC进程，它做三件事：第一，定期对本地NameNode做健康检查，比如检查进程是否存活、能否响应RPC；第二，向ZooKeeper注册临时节点并尝试创建锁，谁抢到锁谁就有资格当Active；第三，监控ZooKeeper中的状态，一旦发现Active对应的临时节点消失，立刻触发本地NameNode切换。整个过程很像会议室抢占：谁先把钥匙插进锁里，谁主持，主持人掉线后其他人顶上。

这里最关键的是防止脑裂：两个NameNode同时认为自己是Active。ZooKeeper锁机制能保证正常情况下只有一个节点拿到锁，但网络抖动或长时间GC可能让Active的ZK会话超时、锁被释放，而Active自己还没意识到，继续在写服务。此时Standby拿到锁切换成Active，系统里就出现了两个“Active”，数据会出乱子。所以ZKFC在切换前必须执行fencing，也就是把旧Active强制“干掉”或隔离。隔离方式最常见的是sshfence：通过SSH登录旧Active节点，执行kill -9干掉NameNode进程；或者用shell命令执行自定义脚本，比如切断网络访问。fencing不成功，就要拒绝切换，避免双主。这个“宁可切不过去，也不能切出双主”的原则，说多少次都不夸张。

2.3 高可用配置实操（core-site.xml/hdfs-site.xml）

下面给出一套比较典型的HDFS HA配置，基于Hadoop 3.x，QJM共享edits。core-site.xml里需要把默认文件系统指向nameservice：

xml复制<configuration>
  <property>
    <name>fs.defaultFS</name>
    <value>hdfs://mycluster</value>
  </property>
  <property>
    <name>ha.zookeeper.quorum</name>
    <value>node1:2181,node2:2181,node3:2181</value>
  </property>
</configuration>

hdfs-site.xml里重点配置nameservice、NameNode节点、JournalNode地址和故障转移方式：

xml复制<configuration>
  <property>
    <name>dfs.nameservices</name>
    <value>mycluster</value>
  </property>
  <property>
    <name>dfs.ha.namenodes.mycluster</name>
    <value>nn1,nn2</value>
  </property>
  <property>
    <name>dfs.namenode.rpc-address.mycluster.nn1</name>
    <value>node1:8020</value>
  </property>
  <property>
    <name>dfs.namenode.rpc-address.mycluster.nn2</name>
    <value>node2:8020</value>
  </property>
  <property>
    <name>dfs.namenode.http-address.mycluster.nn1</name>
    <value>node1:9870</value>
  </property>
  <property>
    <name>dfs.namenode.http-address.mycluster.nn2</name>
    <value>node2:9870</value>
  </property>
  <property>
    <name>dfs.namenode.shared.edits.dir</name>
    <value>qjournal://jn1:8485;jn2:8485;jn3:8485/mycluster</value>
  </property>
  <property>
    <name>dfs.client.failover.proxy.provider.mycluster</name>
    <value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
  </property>
  <property>
    <name>dfs.ha.automatic-failover.enabled</name>
    <value>true</value>
  </property>
  <property>
    <name>dfs.ha.fencing.methods</name>
    <value>sshfence</value>
  </property>
  <property>
    <name>dfs.ha.fencing.ssh.connect-timeout</name>
    <value>30000</value>
  </property>
  <property>
    <name>dfs.journalnode.edits.dir</name>
    <value>/data/hadoop/journal</value>
  </property>
</configuration>

参数看起来多，但核心就几个：dfs.nameservices定义整个逻辑集群名，客户端只认这个逻辑名字；dfs.namenode.shared.edits.dir告诉NameNode去哪些JournalNode读写共享edits；dfs.ha.automatic-failover.enabled打开自动切换；fencing方法建议至少配置sshfence。如果节点间没有免密SSH，可以临时用shellfence加上自定义脚本，生产上一定要保证脚本幂等且执行失败时不会误伤正常节点。

配置完成后，先逐台启动JournalNode，再在其中一个NameNode上执行hdfs namenode -initializeSharedEdits初始化共享日志，然后分别格式化并启动NameNode，最后执行hdfs zkfc -formatZK在ZooKeeper里创建HA锁的目录。顺序不能乱，否则两个NameNode可能都尝试格式化共享edits，导致数据不一致。启动顺序这块，我建议严格按照Hadoop官方文档走，因为你后来排查“为什么Standby不同步”时，十有八九会回到初始化这一步。

2.4 手动切换与自动切换命令

虽然上了自动切换，日常运维还是需要手动切换能力，比如要做NameNode节点操作系统升级或内存扩容。手动切换的命令是：

bash复制hdfs haadmin -ns mycluster -transitionToStandby nn1
hdfs haadmin -ns mycluster -transitionToActive nn2

如果自动故障转移是开启状态，手动执行transition命令时系统会检查ZooKeeper锁，避免和自动切换打架。这里有个老坑：早期版本直接用haadmin手动切换，有可能在自动故障转移关闭的情况下强行切换，导致两个Active。所以建议所有切换操作都通过ZKFC来协调，不要绕过ZooKeeper。每次切换后要确认一下状态，命令是hdfs haadmin -getAllServiceState，两台NN一个显示active，一个显示standby才算正常。我还习惯在切换前先看一眼客户端连接是不是都指向了nameservice逻辑地址，如果客户端配置的是某个具体NameNode地址，那个客户端在切换后会一直连不上，这属于典型的客户端配置问题。

3. YARN ResourceManager高可用设计

3.1 RM HA的两种模式

做完HDFS高可用，不少同学以为集群就高可用了，实际还差一大块：YARN ResourceManager。YARN的ResourceManager高可用，核心思想和NameNode HA类似，都是多实例+选主，但它没有共享edits日志这种机制，而是依赖ZooKeeper进行领导者选举。Hadoop 2.4之后，RM HA默认使用基于ZooKeeper的内嵌选主实现，不需要单独部署ZKFC进程。RM启动时会往ZooKeeper的指定路径创建临时节点，谁创建成功谁就是Active，其他RM处于Standby状态并持续监听这个节点，一旦Active的会话失效，Standby会尝试抢占。

选择Active后，RM还需要恢复之前运行中的Application状态。因此RM需要把应用提交信息、状态存储下来。存储有两种：一种是基于ZooKeeper，把每个Application的状态直接写到ZK节点，适合小集群，但是ZK写入压力大；另一种是基于LevelDB文件系统存储，状态保存在RM本地磁盘，通过多个RM共享一个文件系统路径（要求是共享存储），或使用Ratis，Hadoop 3.2以后支持基于Ratis的RM状态存储，但一般生产上还是用LevelDB+共享目录比较多。实际选型时，我会优先用LevelDB+共享存储，因为ZK如果承担太多小对象写入，会拖慢其他HA组件的响应。

3.2 RM HA配置要点

yarn-site.xml的核心配置可以这样写：

xml复制<configuration>
  <property>
    <name>yarn.resourcemanager.ha.enabled</name>
    <value>true</value>
  </property>
  <property>
    <name>yarn.resourcemanager.cluster-id</name>
    <value>rmcluster</value>
  </property>
  <property>
    <name>yarn.resourcemanager.ha.rm-ids</name>
    <value>rm1,rm2</value>
  </property>
  <property>
    <name>yarn.resourcemanager.hostname.rm1</name>
    <value>node1</value>
  </property>
  <property>
    <name>yarn.resourcemanager.hostname.rm2</name>
    <value>node2</value>
  </property>
  <property>
    <name>yarn.resourcemanager.webapp.address.rm1</name>
    <value>node1:8088</value>
  </property>
  <property>
    <name>yarn.resourcemanager.webapp.address.rm2</name>
    <value>node2:8088</value>
  </property>
  <property>
    <name>yarn.resourcemanager.recovery.enabled</name>
    <value>true</value>
  </property>
  <property>
    <name>yarn.resourcemanager.store.class</name>
    <value>org.apache.hadoop.yarn.server.resourcemanager.recovery.LeveldbStateStore</value>
  </property>
  <property>
    <name>yarn.resourcemanager.zk-address</name>
    <value>node1:2181,node2:2181,node3:2181</value>
  </property>
</configuration>

需要注意RM HA和HDFS HA共用同一套ZooKeeper，但不要共用一个路径，RM默认路径是/yarn-leader-election，HDFS的ZKFC路径是/hadoop-ha，互不影响。另外yarn.resourcemanager.recovery.enabled必须设为true，否则RM切换后已经提交的任务会全部丢失，客户端会看到提交失败或任务状态异常。LevelDB状态存储路径默认在${hadoop.tmp.dir}/yarn-leveldb，要保证RM1和RM2都能访问同一个路径。如果是本地磁盘，那两个RM之间无法共享状态，严格来说不满足恢复要求，这也是很多初学者没留意的地方。我通常会单独挂一块共享存储目录（比如NFS或云盘）给两个RM，或者用支持多writer的LevelDB配置。

3.3 RM状态存储与故障恢复

故障恢复时，新Active RM会从状态存储中读出正在运行的Application，并重新接管对应的ApplicationMaster。这里有个限制：如果AM不是可恢复的，任务可能失败需要客户端重试；如果开启了unmanaged-AM等特性，恢复能力也有差异。实际运营中，MapReduce和Spark作业大多可以恢复，但流式作业（比如Flink on YARN）恢复会受到checkpoint机制影响。所以RM HA不是万能药，上层作业自身的容错设计同样重要。

我遇到过一种情况：RM Active节点负载很高，频繁Full GC，导致ZooKeeper会话超时，Standby自动接管；但旧进程因为GC卡顿迟迟没有退出，结果新的RM已经接管，旧的RM恢复后又开始响应心跳，造成YARN状态混乱。这类问题不能只靠HA解决，更要在JVM参数、ZK会话超时时间和RM堆内存之间做平衡，比如把zookeeper.session.timeout从默认10秒调大到20秒，同时给RM足够的内存，避免GC导致会话误判。生产环境里我给RM堆内存通常设置32GB以上，具体要看集群规模，但至少不能让它因为Full GC频繁丢会话。

4. 整体集群高可用的其他关键环节

4.1 ZooKeeper集群本身的高可用

名字里带“高可用”的Hadoop HA，有个很容易忽略的角色就是ZooKeeper自己。如果ZK集群挂了，HDFS自动故障转移和RM选主都会失效，整个集群会退化成“两个NameNode谁能干活全看运气”。所以ZK本身也要按高可用标准部署。我的建议是至少3个节点，有条件用5个，节点数必须奇数，并且放在不同机架或至少不同电源域。ZK的磁盘建议使用SSD，因为事务日志写盘频率高，性能差的磁盘会导致所有依赖ZK的组件出现延迟抖动。

ZK节点数量不是越多越好。5个节点能容忍2个宕机，但写入需要3个节点确认，每个写入请求都要在多个节点之间同步，节点越多，写入延迟越大。生产上很多团队直接用3节点，简单够用；如果集群规模特别大、依赖ZK的服务多，可以拆成多套ZK集群分别服务不同组件，避免互相影响。我还习惯给ZK单独设置JVM堆大小，默认1G对事务日志多的情况不太够，建议Xmx2g或3g，并开启JMX监控，盯住磁盘延迟和watch数量。ZK中的watch数量指数增长时，很容易拖垮选主性能。

4.2 JournalNode的角色与元数据保护

JournalNode在HDFS HA里承担着edits日志的存储和多数派校验，但它不是数据节点，不参与实际数据块存储。很多人容易低估它的重要性，随便拿几台业务机器部署，结果NameNode每次写edits延迟都很大，一旦其中一个JournalNode磁盘满了，整个HDFS写入都会受阻。我一般会把JournalNode独立部署在专用的几台机器上，磁盘用RAID1或云盘，并设置单独的磁盘容量告警。这里说的独立部署不是说要买很高规格的服务器，而是别让JN和DataNode混跑在IO密集的机器上。

元数据保护除了JournalNode自身的edits日志，还要关注fsimage。NameNode定期做checkpoint生成新的fsimage，Standby NameNode也会合并edits生成fsimage。要定期把fsimage备份到异地或对象存储，防止逻辑错误、误删除源数据。这里推荐开启dfs.namenode.num.checkpoints.retained和定期跨机备份，至少能恢复到几小时前的元数据状态。HDFS的Trash机制也要打开，这样误删文件还有机会从回收站捞回来。我遇到过有同学手动删了HDFS某个业务目录，过了两天才发现，因为没开Trash，只能靠之前的fsimage加edits日志人工回放，费了很大劲。

4.3 网络、机架感知与故障域隔离

高可用设计必须考虑故障域隔离，否则冗余部署形同虚设。比如两台NameNode放在同一个机架，上面恰好是个汇聚交换机，交换机挂了两个NameNode都联系不上；3个JournalNode均匀分布到不同机架，单机架故障时最多丢一个JN，还能满足多数派。ZooKeeper也一样。我在设计集群布局时，一般会画一张故障域矩阵：每个机架上放了哪些NameNode、JournalNode、ZooKeeper和ResourceManager，保证任意一个机架故障时，HDFS和YARN仍能完成选主和多数派写入。

机架感知（rack awareness）虽然更多用于数据块副本放置策略，但和HA也有关联。配置了网络拓扑脚本后，HDFS在写数据块时会优先把副本放到不同机架，提升数据可靠性。对于NameNode的HA，还可以通过dfs.namenode.avoid.write-to-datanode等参数优化写入，但更重要的是在物理部署时把关键角色错开。我曾在一个测试环境里把两个NameNode和三个JournalNode全放在了一个机架上，然后去做“交换机宕机演练”，结果整个HDFS直接不可用，那次演练让我对故障域隔离的重视程度提升了一个级别。

4.4 运维监控与故障演练

HA架构落地后不是一劳永逸，要定期验证。我会在测试环境做一个“故障演练计划”：每季度随机挑选一台NameNode、一台ResourceManager或一个ZooKeeper节点，模拟宕机或断网，观察自动切换是否在预期时间内完成，fencing是否生效，客户端是否有明显报错。第一次做故障演练时，我们发现ZKFC的健康检查脚本一直返回正常，但NameNode其实已经僵死，导致切换没有触发，后来在健康检查里增加了RPC端口探测和HDFS读写探测才解决。这个坑非常典型：进程在，服务不一定在。

监控方面，至少要盯这些指标：NameNode的RPC延迟和线程阻塞数、JournalNode写入延迟、ZooKeeper会话数和选主耗时、RM的Active/Standby状态和状态存储写入耗时。告警规则不要只盯着进程是否存活，还要看“功能是否可用”。比如NameNode进程还在，但RPC队列堆满，这种情况下进程存活告警不会触发，但集群已经无法正常服务了。我在生产上就用一个定时脚本每隔30秒执行hdfs dfs -ls /，如果连续3次失败就告警，简单粗暴但很有效。监控系统建议直接接Prometheus+Grafana，Hadoop的JMX指标很全，关键是选对看板怎么组合。

5. 典型故障场景与排查技巧实录

5.1 NameNode切换失败

现象：Active NameNode所在机器宕机，但Standby没有自动升主，整个HDFS卡死。排查时先看ZooKeeper中的锁节点，确认ZKFC有没有抢到锁。如果Standby机器上ZKFC日志提示“unable to connect to local NameNode”，多半是检查脚本误判健康状态，或者Standby NameNode本身没起来。我遇到过一次：两个NameNode都配置正确，但Standby的namespaceID和Active不一致，初始化共享edits时忽略了格式化，导致Standby一直进入不了对应状态，ZKFC自然无法完成切换。解决方法是备份元数据后重新初始化standby NameNode，再执行hdfs zkfc -formatZK重新初始化ZKFC状态。这类问题最怕在业务高峰期遇到，所以集群初始化流程一定要写成文档，不要每次都靠记忆。

5.2 脑裂与fencing未生效

双Active是最危险的故障，日志里会看到两个NameNode都绑定同一个nameservice地址，DataNode同时向两个NameNode发送心跳。原因通常是fencing方法配置有问题，比如sshfence要求免密SSH，但没配好，旧节点一分隔就ping不通，fencing一直卡在超时。后来我加了dfs.ha.fencing.ssh.private-key-files配置，并且用检查脚本验证从新Active节点能免密ssh到旧节点。另外，fencing方法可以配置多个，例如：

xml复制<property>
  <name>dfs.ha.fencing.methods</name>
  <value>sshfence,shell(/path/to/fence.sh)</value>
</property>

这样第一条失败后会自动执行shell脚本，增加隔离成功率。但自定义脚本一定不能“无脑kill”，要判断目标节点是否真的还是Active，否则可能在正常降级过程中误杀进程，造成不必要的切换。我见过有人写了一个fence脚本，只要执行就kill NameNode，结果主动切换时把新Active给杀了，两边都变成Standby，整个集群直接不可写。好的fence脚本应该先查状态、再做隔离，而且要预留手动确认时间。

5.3 JournalNode性能瓶颈与恢复

JournalNode的高延迟会导致NameNode写edits超时，严重时Active NameNode会进入Safemode或退化为只读。我遇到过一台JN所在虚拟机磁盘IO被打满，edits日志写入延迟从几毫秒飙升到十几秒，NameNode的RPC整体变慢，客户端大量超时。排查手段是看JMX指标和系统日志，重点看journalnode的sync时间。恢复手段是先把这台JN停止，确认另外两个JN依然满足多数派，再修复磁盘后重新加入集群。注意JN在运行时不能直接格式化目录，否则会丢掉edits历史，导致后续无法参与同步。正确的做法是备份旧目录、复制Active NameNode的当前fsimage和edits，再启动JN。

这里要特别注意：JournalNode的目录不能随便清理。很多同学看到JN日志盘快满了，直接删除edits文件来“腾空间”，这是非常危险的操作，可能直接破坏HDFS元数据一致性。我建议在JN上单独划分一个大分区，并设置inode和空间双重告警。如果实在膨胀得厉害，可以考虑缩短HDFS的checkpoint周期，让Standby更频繁地合并edits，从而减少JN上保留的历史文件量。

5.4 常见问题速查表

下面是整理后的速查表，基本覆盖了我在生产环境里见过的高可用相关问题：

这张表我建议存下来，面试讲到Hadoop高可用时也很有用。最后再分享一个经验：高可用架构设计不是“配完就完了”，它的价值要靠在真实故障中能不能快速恢复来验证。我每次变更集群配置后，都会在低峰期主动做一次切换测试，记录切换耗时和数据健康状态，长期积累下来，这套集群的出问题率明显下降，业务方也能感受到平台更稳了。