做HA高可用很多人一开始会直接跳到配置文件那一堆dfs.nameservices、dfs.ha.namenodes.xxx上配完一启动发现两个 NameNode 都抢着做 Active或者主节点挂了备节点根本接管不过去日志刷了一屏 ERROR看着就头大。我在生产环境里从零搭过不止一次 Hadoop HA也帮人排查过不少这类集群今天这篇就从原理到实操把 HDFS HA 环境搭建这摊事完整捋一遍包括配置清单、启动顺序、踩过的坑以及平时线上运维的一些习惯。适合刚接触 Hadoop 想搭 HA 的开发者也适合那些已经搭过但总是出问题的朋友对照排查。1. 为什么一定要做HA先理解单点故障的代价1.1 单点故障到底有多疼不少人在学习阶段是用伪分布式或者单节点集群跑 Hadoop觉得挺稳定。可一旦到了生产环境客户端要一直读写数据任务要持续调度单 NameNode 的问题就暴露无遗只要这个节点宕机、网络抖动、或者进程因内存溢出退出整个集群就直接瘫痪。当时我们线上遇到过一次比较典型的情况NameNode 所在的机器半夜因内存暴涨触发 OOM进程没了所有 MapReduce 任务排队等待Hive 查询超时部分 Flume 任务还在往里灌数据直接把后续链路顶到不可用。等人工登录机器、重启进程、加载元数据前前后后花了快一个小时才恢复。这一个小时里所有依赖 HDFS 的服务全部处于停顿状态损失是实打实的。HDFS 的设计思路是 NameNode 只保存元数据真正数据块在 DataNode 上。但这不代表 NameNode不重要——它恰恰是客户端访问数据的“目录表”。目录表没了就算数据块都完好客户端也不知道文件被切成了多少块、每一块放在哪个节点上更无从谈起读取和写入。1.2 HA要解决的核心问题HAHigh Availability要解决的就是去掉这个单点当主 NameNodeActive挂掉时另一台备份 NameNodeStandby能及时顶上接管元数据服务让客户端继续访问文件系统。基于这个目标核心要解决两个问题元数据必须同步Standby 节点要能拿到最新的 Edit Log编辑日志否则切换过去后文件的目录结构和最近写入的数据块信息都是旧的数据等于丢失了。故障检测要自动化不能靠人工看到告警再手动切那样恢复时间依然很长而且容易操作失误。所以业界就形成了 Active/Standby 架构两个 NameNode 共享元数据存储由 ZooKeeper 感知主节点健康状态一旦异常自动触发故障转移。1.3 HA的边界需要提前认清HA 不是万能的它解决的是进程级故障、机器宕机这类问题并不解决数据错误、误删文件这类逻辑问题。如果管理员误执行了一行rm -rfHA 切换后数据照旧丢失。所以即便搭好了 HA快照机制、备份策略、权限管控这些一个都不能少。另一方面HA 只能做到主备切换期间的秒级停顿不是无感知。写入方已经拿到 Active NameNode 的租约、正在提交数据块时发生切换客户端可能会收到异常需要重试这个异常在应用层要有重试机制。很多人误以为 HA 等于零停机其实严格说应该是“快速恢复”我们要把这个预期先摆正。2. 架构拆解三套机制协同工作2.1 谁来决定谁是主节点——ZKFCZooKeeper FailoverControllerHDFS HA 里每个 NameNode 节点都跑一个 ZKFC 进程它本质上是一个轻量级的监控与控制器核心职责有三块一是监控本机 NameNode 的健康状态定期做健康检查二是和 ZooKeeper 交互在 ZooKeeper 上创建临时节点谁成功创建了那个节点或者说谁抢到了锁谁就是 Active三是当本机 NameNode 出现异常时主动删除 ZooKeeper 上的临时节点触发另一边接管。用一句话讲ZKFC 就是主备切换的“裁判员”。要注意的是ZKFC 监控的不是 NameNode 进程是否活着而是它是否还能正常提供服务——比如 NameNode 进程明明活着但已经处于 SafeMode 或者长时间没有响应那 ZKFC 也会判定异常。2.2 元数据“账本”的实时同步——JournalNode 与 QJM为了让 Standby NameNode 拿到最新的 Edit LogHadoop 引入了 JournalNode简称 JN的角色。简单类比一下Active NameNode 每做一次修改元数据的操作比如创建目录、写文件、删除文件都会把对应的操作记录追加到 Edit Log 里然后同步写入一组 JournalNode。Standby NameNode 持续从 JournalNode 读取这些日志回放应用到自己的内存元数据上保证两个节点的目录树和文件块映射尽量一致。这个过程称为 QJMQuorum Journal Manager。涉及 QJM 的核心要点是JournalNode 至少部署 3 台因为同步日志时过半写入成功才算提交3 台的话容忍 1 台宕机5 台容忍 2 台宕机。生产环境通常奇数部署但很少有人会部署超过 5 个因为 JournalNode 越多写日志的网络开销和 IO 压力越大反而可能成为瓶颈。不过 JournalNode 本身负载并不算重可以和数据节点混部但磁盘 IO 最好和 DataNode 数据盘分开避免互相干扰。2.3 防止“脑裂”的关键一环——Fencing隔离主备架构里最怕的一种情况叫做“脑裂”Split-Brain网络发生分区两个 NameNode 都认为对方挂了自己应该当 Active结果同时对外提供写服务元数据就会被破坏。防止脑裂依靠的是 Fencing 机制——当 ZooKeeper 一侧判定原 Active 失联并准备切换时会先触发一系列隔离动作确保旧主节点不再存活或无法继续提供写服务。常见的 Fencing 策略有通过 SSH 登录旧主节点执行kill -9杀掉进程调用旧主节点上的脚本执行dfsadmin -shutdownDatanode等或者配置基于共享存储的隔离方式。配置里对应参数是dfs.ha.fencing.methods一般生产环境至少配置两种组合方式比如sshfence加上shell(true)并配置好dfs.ha.fencing.ssh.private-key-files为免密的 SSH 私钥路径。这样即使 SSH 方式没执行成功也能通过自定义脚本强制兜底。3. 搭建前期版本选型与节点规划3.1 版本怎么选现在很多人一上来就直接用 Hadoop 3.x 最新版本但做 HA 我个人更倾向于选相对成熟的发行版CDH、HDP 这类商业发行版虽然停止更新了但老集群存量很大社区里资料也容易搜到。Apache 原生版本的话以 2.7.x、2.10.x、3.1.x、3.3.x 为主。要注意 3.x 和 2.x 在 HA 配置上大体相同但部分参数默认值和端口有所不同比如 3.x 里dfs.namenode.rpc-address配置方式更严格需要明确指定 nameservice 和 namenode ID 组合。如果你是新手建议直接用 CDH 发行版或较新的 Apache 版本并且一定要保证所有节点的 Hadoop 版本完全一致版本不一致是最容易引发各种诡异问题的根源。3.2 节点规划清单以一个典型的 3 节点 HA 测试环境为例我常用的规划是这样主机名角色分配说明nn-01NameNode、ZKFC、ZooKeeper、JournalNode、DataNode主节点候选nn-02NameNode、ZKFC、ZooKeeper、JournalNode、DataNode备节点候选dn-01JournalNode、ZooKeeper、DataNode、NodeManager第三台 JN/ZK 节点生产环境建议把 NameNode 和 ResourceManager 解耦单独的物理机器跑 NameNode 元数据服务不建议和数据节点混部因为 NameNode 内存需求大、GC 停顿敏感和数据节点混跑容易因磁盘写满互相影响。JournalNode 本身是轻量服务与 NameNode 同机部署完全没有问题但 ZooKeeper 尽量独立于 NameNode避免同机故障导致主备同时失去与 ZK 的通信。3.3 前置基础配置JDK、SSH、hosts这一步看着简单但很多同事栽跟头就在 hostname 配置上。HA 配置里大量使用主机名比如dfs.namenode.rpc-address.mycluster.nn-01这个配置项Hadoop 会根据你填的主机名去解析 IP。如果/etc/hosts没配好启动的时候会一直提示无法解析主机你要是没仔细看日志很容易误以为是网络问题或者端口没通。基础配置包括安装 JDK 8 或 11配置JAVA_HOME和PATH。Hadoop 3.3 以上对 JDK 版本支持范围更宽但我个人觉得如果集群规模不大用 JDK 8 最稳妥遇到的内存和编译问题少一些。配置所有节点 /etc/hosts包括本机 IP、短主机名、完全限定域名确保三台机器互 ping 主机名都通。配置 SSH 免密登录至少保证 nn-01 能免密登录 nn-02 和 dn-01。因为 ZKFC 在做故障转移时可能通过 SSH 执行 fence 操作如果免密没配置会出现 Active 节点切换失败报SSHException之类的错误。关闭防火墙或放行对应端口。HA 模式涉及 RPC、HTTP、ZK、JN 多个端口新手先直接关掉最省事生产环境再按需放行。4. 手把手实操HDFS HA 配置全过程4.1 部署 ZooKeeper在配置 Hadoop 之前先把三台节点上的 ZooKeeper 装好并启动。不需要太复杂的调优保证zoo.cfg里tickTime、dataDir、clientPort配置正确然后写好myid。三台节点分别执行zkServer.sh start用zkServer.sh status确认一台 Leader、两台 Follower。注意 ZooKeeper 的dataDir要选在磁盘空间大一点的路径它日志虽小但长期运行会产生大量事务日志目录太小会导致集群莫名抖动。如果只是用 ZooKeeper 来做 HA 锁不需要专门给它做 HAZooKeeper 自身集群就是 HA 机制三台节点组成一个 ZK 集群即可重视一下快照和数据目录的监控告警。4.2 Hadoop 核心配置逐个说明进入$HADOOP_HOME/etc/hadoop主要是改core-site.xml、hdfs-site.xml。这里我给出一个最常用的配置示例并逐项解释避免大家配完不知道什么意思改错了也不知道影响在哪core-site.xml中关键配置property namefs.defaultFS/name valuehdfs://mycluster/value /property property nameha.zookeeper.quorum/name valuenn-01:2181,nn-02:2181,dn-01:2181/value /propertyfs.defaultFS要改成逻辑 nameservice 名称不是某个具体节点。这个逻辑名称后续在hdfs-site.xml里继续定义。ha.zookeeper.quorum是 ZK 集群地址列表ZKFC 和 JournalNode 都会用到它。如果名称写错了故障转移就会一直报告连不上 ZooKeeper。在hdfs-site.xml中核心配置如下property namedfs.nameservices/name valuemycluster/value /property property namedfs.ha.namenodes.mycluster/name valuenn-01,nn-02/value /property property namedfs.namenode.rpc-address.mycluster.nn-01/name valuenn-01:8020/value /property property namedfs.namenode.rpc-address.mycluster.nn-02/name valuenn-02:8020/value /property property namedfs.namenode.http-address.mycluster.nn-01/name valuenn-01:9870/value /property property namedfs.namenode.http-address.mycluster.nn-02/name valuenn-02:9870/value /property注意 Hadoop 3.x 的 HTTP 默认端口是 9870如果从 2.x 迁移过来记得把原来 50070 改掉否则页面打不开。接下来配置 JournalNode 地址和本地目录property namedfs.namenode.shared.edits.dir/name valueqjournal://nn-01:8485;nn-02:8485;dn-01:8485/mycluster/value /property property namedfs.journalnode.edits.dir/name value/data/hdfs/journal/value /propertyqjournal://后面的列表就是三台 JournalNode这是 QJM 写日志的入口读写 Edit Log 都走这个地址。dfs.journalnode.edits.dir是本地日志目录比如/data/hdfs/journal记得目录属主改成运行 Hadoop 的用户并且磁盘有容量。再配置自动故障转移这里决定了 ZKFC 是否启动、是否自动切换property namedfs.ha.automatic-failover.enabled/name valuetrue/value /property /xml最后一个关键配置是dfs.client.failover.proxy.provider.mycluster这是客户端用来做故障转移的代理类写错会导致客户端访问 HDFS 时完全不识别两个 NameNode 的切换。1 这个参数可能有点绕它的作用是告诉 HDFS 客户端在访问mycluster这个 nameservice 时应该用哪个类来判断当前已经发生了故障转移、接下来该连接哪个 NameNode。property namedfs.client.failover.proxy.provider.mycluster/name valueorg.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider/value /property注意 8088 是 YARN 的 Web UI 端口跟这里无关别混淆。还有dfs.ha.fencing.methods按前面方法配置好。4.3 初始化与启动顺序这一步最容易乱HA 环境第一次启动有严格的顺序很多人一上来就start-dfs.sh结果报各种错。正确顺序是先启动三台 JournalNode在每一台上执行hdfs --daemon start journalnode或直接hadoop-daemon.sh start journalnode。此时 JN 会创建dfs.journalnode.edits.dir指定的目录等待 NameNode 连接。在 nn-01 上格式化 NameNode执行hdfs namenode -format。注意只需要格式化一台另一台不用格式化。启动 nn-01 的 NameNode执行hdfs --daemon start namenode此时它会把自己生成的元数据也写到 JournalNode 上。在 nn-02 上执行hdfs namenode -bootstrapStandby这一步会把 nn-01 的元数据同步到本地同时从 JournalNode 拉取 Edit Log。执行完后 nn-02 上会生成一份完整的元数据目录。都完成后执行hdfs zkfc -formatZK在 ZooKeeper 上初始化 HA 状态创建对应的临时节点。这一步只在首次搭建时做初始化的是 ZK 上的锁节点信息之后不要随意重复执行。启动 nn-01 上的 ZKFC 和 nn-02 上的 ZKFC顺序随意因为抢锁是并发的。之后再分别启动 nn-02 的 NameNode。如果配置正确两个 ZKFC 经过协商最终会有一个 NameNode 变为 Active另一个保持 Standby。最后启动 DataNode执行hdfs --daemon start datanode或start-dfs.sh已经启动的情况下start-dfs.sh会自动检测但新手建议分开一步步启动方便定位问题。这里有一个常见疑问为什么 nn-02 不能直接也执行hdfs namenode -format因为如果两台都 format它们的clusterID和元数据版本会各自独立之后做-bootstrapStandby时可能会因为集群 ID 不一致直接报错或者即使起来了NameNode 在后续运行中也会发现 journal 信息对不上。正确做法就是前面的流程只 format 一台另一台用 bootstrap 拉取元数据。启动完成后建议执行hdfs haadmin -getServiceState nn-01和hdfs haadmin -getServiceState nn-02正常情况下一个输出active另一个输出standby。如果两个都是 standby大概率是 ZKFC 没起来或者 JournalNode 通信有问题。如果两个都是 active说明 Fencing 没配置好脑裂风险极高这种情况要立刻停止集群排查。4.4 手动切换演练验证HA真的能用配置好之后不要觉得万事大吉手动演练一次故障转移是必要操作。执行hdfs haadmin -transitionToStandby nn-01 hdfs haadmin -transitionToActive nn-02等状态确认后再用hdfs dfs -ls /测试读写。如果手动切换正常说明 Nameservice 路由、ZK 通信、JN 日志同步基本没问题。之后可以做一次模拟宕机找一台机器把 Active NameNode 进程 kill 掉看 Standby 是否在几十秒内自动变成 Active。这个过程记录一下确认自动切换生效。我自己的经验是演练这步不能省。因为这个操作验证的不仅是 Hadoop 本身还验证了 ZK 集群可用性、SSH 免密配置、Fencing 脚本权限这些外部依赖任何一个环节有问题线上宕机时都会出大问题。5. YARN 的 HAResourceManager 也要做主备5.1 为什么 HDFS HA 不代表 YARN 也 HA很多人只做了 HDFS 的 HA就以为整个 Hadoop 高可用已经完成了。实际上 YARN 的资源管理器 ResourceManagerRM同样是单点RM 挂掉后虽然已经运行的任务通常还能继续跑但新的任务、新的 Application 提交就不行了整个集群相当于半瘫痪状态。而且 HDFS HA 和 YARN HA 是两套独立机制配置互不影响各做各的。好在 RM 的 HA 比 NameNode HA 简单一些它不需要 JournalNode 去同步元数据而是把状态存储到 ZooKeeper 上对应参数yarn.resourcemanager.zk-state-store通过 ZKFC 机制选主。同一时刻只有一个 RM 是 Active另一个是 Standby客户端通过逻辑地址访问当前 Active 的 RM。5.2 YARN HA 的配置要点在yarn-site.xml中需要配置以下关键项property nameyarn.resourcemanager.ha.enabled/name valuetrue/value /property property nameyarn.resourcemanager.cluster-id/name valuemy-yarn-cluster/value /property property nameyarn.resourcemanager.ha.rm-ids/name valuerm-01,rm-02/value /property property nameyarn.resourcemanager.hostname.rm-01/name valuenn-01/value /property property nameyarn.resourcemanager.hostname.rm-02/name valuenn-02/value /property property nameyarn.resourcemanager.zk-address/name valuenn-01:2181,nn-02:2181,dn-01:2181/value /property property nameyarn.resourcemanager.zk-state-store/name valueZKStore/value /property配置完还要在core-site.xml里加一个 RM 的逻辑地址映射不然客户端不认识my-yarn-cluster这个逻辑 IDproperty nameyarn.resourcemanager.address.my-yarn-cluster.rm-01/name valuenn-01:8032/value /property property nameyarn.resourcemanager.address.my-yarn-cluster.rm-02/name valuenn-02:8032/value /property之后同样要分别启动两个节点的 ResourceManager然后用yarn rmadmin -getServiceState rm-01检查状态。与 HDFS 不同YARN HA 默认状态下切换是自动的但依赖 ZooKeeper 存储状态。如果 ZK 连接中断RM 反复切换运行中的任务可能中断重试所以 ZK 集群的稳定性在任何 HA 方案里都是前提。5.3 不要为了 HA 而 HA一台机别跑两个主备许多刚接触 HA 的同学在只有两台或三台机器的小集群上会想要把所有角色都配上主备结果每台机上既有 NameNode 又有 ResourceManager 又有 ZKFC还有 ZooKeeper、JournalNode、DataNode、NodeManager启动后资源互相争抢系统负载极高反而比单点更难维护。HA 的本质是消除单点但如果你机器资源有限一个 NameNode 一个 RM 跑在同一台物理机上其实也可以接受只要把不同角色错开到不同节点不要两台机器完全等价地跑所有角色就行。6. 常见问题与排查技巧实录6.1 JournalNode 起不来或状态异常最典型的表现是hdfs namenode -bootstrapStandby一直连接不上 JN日志里出现Unable to connect to journal之类的错误。排查思路很简单先看 JN 端口 8485 是否在监听ss -tlnp | grep 8485再看防火墙有没有拦截然后确认三台 JN 的本地目录是不是都被正确创建最后检查/etc/hosts里主机名解析是否正常。另外一种情况是 JournalNode 能启动但目录权限不对或者hdfs用户没有写权限启动后很快就退出了日志里会直接写出来。6.2 ZKFC 起来了但状态一直是 standby要检查两个方向一是 ZK 上锁节点是否被正确创建可以进入 ZooKeeper 客户端zkCli.sh查看/hadoop-ha或者/mycluster下的节点情况二是检查两个节点zkfc日志看它为什么没有抢到锁。有一种常见的迷惑现场网络抖动后ZK 上出现一个旧节点的 session 还没过期导致新节点一直申请不到锁看起来两边都正常但就是切不过来。这种情况可以把两个 ZKFC 都停掉到 ZK 里删掉对应的锁节点后重启让它们重新抢一次。6.3 手动切换可以kill 后自动切换不生效大概率是自动故障转移没打开确认dfs.ha.automatic-failover.enabled是否为true并且两个节点上zkfc进程是否都在。还有一个容易被忽略的是有些人在hdfs-site.xml里写了这个参数但忘了同步到另外一台节点。HA 配置没有同步像是只改了一台就启动这是最坑的。改完配置一定要检查所有节点的文件一致性能用 Ansible 或scp直接分发不要手动一台台改太容易漏。6.4 两个节点都变成 Active脑裂警报一旦出现两个 NameNode 都是 active要立刻人为干预。先用haadmin -transitionToStandby强制把其中一个降为 standby然后排查 Fencing 配置。常见原因有dfs.ha.fencing.methods没有配置、sshfence 的私钥路径配错、shell fence 脚本没设置可执行权限。之后去 ZK 上删掉异常锁节点恢复集群。这个情形记得在操作记录里留档避免第二次踩。6.5 一个小坑清单hdfs namenode -format格式化完成后千万不要两台机器都执行zkfc -formatZK重复初始化会清掉 ZK 上的 HA 元数据。JournalNode 所在目录不能挂载在系统盘或者空间比较小的分区日志写满会让主节点写入阻塞。/etc/hosts里不要同时配置短主机名和完全限定域名导致重复解析某些 Hadoop 版本会取错地址。所有节点的时间要保持一致这一点在 Kerberos 开启环境里尤其重要ZK 的 session 机制对时钟漂移比较敏感。Config 里建议把dfs.ha.automatic-failover.enabled和dfs.client.failover.proxy.provider写在一起方便排查。7. 运维验证清单与加速排障的小习惯HA 搭建完成不代表工作结束后期的巡检比搭建更耗时。我的习惯是维护一份验证清单每隔一周跑一次检查两个 NameNode 的状态、JournalNode 磁盘空间、ZooKeeper 进程和 Leader 状态、Edit Log 同步延迟、最近几次自动切换记录。这些信息分别用dfs haadmin、hdfs journalnode日志、ZooKeeper 的mntr命令去获取再配合监控大盘展示很容易发现隐患。还有一个很有用的操作提前准备一个“故障恢复脚本”脚本内容就是把 ZKFC、NameNode、JournalNode 按顺序重启并校验得到两个节点状态为一主一备。线上出了问题人是慌的手忙脚乱最容易误操作。先脚本化出问题立即执行再慢慢排查细节这是我在几次应急处置后总结出来的做法。如果要做更深一步可以再加一层监控用 curl 定时访问 Active NameNode 的 JMX 接口判断HAServiceProtocol的状态异常就告警。但监控要避免过于频繁10 秒到 30 秒一次足够过于密集反而增加 NameNode 的 RPC 压力。我个人在实际操作中的体会是HA 搭建本身不难难的是真正理解每一条配置背后的作用以及反复演练故障切换流程。很多人配完之后从没主动 kill 过 Active 节点真到故障来了连当时配置了什么开关都忘了。所以建议大家在测试环境里刻意制造几次故障kill -9 杀掉 NameNode、停掉一台 JournalNode、把 ZK 集群里的一台挂掉观察整个集群如何应对。这些实验做完你对这套架构的信任度会完全不一样。最后再分享一个小技巧在/etc/hosts里配置主机名解析时优先使用内网 IP不要用公网 IP也不要让 Hadoop 去依赖 DNS 服务器。很多环境里 DNS 解析偶尔慢一下可能就导致 NameNode 通信超时触发不必要的切换把网络基础打稳HA 才会真的可靠。