1. 高可用集群的核心思路与方案选型1.1 为什么单点 Namenode 是生产环境的定时炸弹刚接触 Hadoop 集群那会儿我最开始搭的是伪分布式和单节点版本跑跑测试没问题一旦放到真实业务场景里就原形毕露。单点 NameNode 最大的问题在于整个 HDFS 的元数据全部压在一台机器上这台机器一挂整个集群直接瘫痪。更麻烦的是元数据如果没做好持久化和恢复机制重启之后可能连数据块的位置信息都找不回来那才是真正的灾难。我踩过最惨的一次坑是某次机房供电波动导致 NameNode 所在节点意外宕机虽然数据块本身还在 DataNode 上但因为没有 Standby 节点接管集群整整停了四十多分钟才恢复。从那之后我就下定决心任何上生产环境的 Hadoop 集群NameNode 高可用必须做没有商量余地。高可用High Availability的核心思路其实很朴素准备两台 NameNode一台处于 Active 状态对外提供服务另一台处于 Standby 状态实时同步元数据。Active 挂了Standby 立刻顶上。听起来简单但难点在于两个地方一是元数据怎么实时同步二是谁来仲裁“到底哪台是 Active”。这两个问题前者靠 JournalNode 集群解决后者靠 ZooKeeper 解决。1.2 JournalNode 与 ZooKeeper 各自扮演什么角色先说 JournalNode。它是一组轻量级的服务进程通常部署三台或以上奇数台作用是让 Active NameNode 把编辑日志EditLog实时写入 JournalNode 集群Standby NameNode 再从 JournalNode 读取这些日志并应用到自己的元数据中。这样两台 NameNode 的元数据就能保持近乎实时的一致。为什么用奇数台因为 JournalNode 的写入需要多数派确认Quorum三台允许挂一台五台允许挂两台这是典型的分布式共识思路。再说 ZooKeeper。它在这里的角色是“仲裁者”和“状态协调者”。ZooKeeper 集群上会维护一个叫 ActiveStandbyElector 的机制两台 NameNode 会去 ZooKeeper 上抢一个临时节点ephemeral node谁抢到谁就是 Active。Active 节点会持续持有这个节点一旦它宕机会话超时临时节点自动消失Standby 就会收到通知并尝试抢占抢到后自动切换为 Active。整个过程不需要人工干预这就是自动故障转移Automatic Failover的核心。ZooKeeper 集群同样建议部署奇数台三台起步。它和 JournalNode 可以是同一批机器也可以分开部署看你的资源情况。我个人的习惯是 JournalNode 和 ZooKeeper 分开部署避免资源争抢也方便独立扩容和排障。1.3 整体架构与数据流向梳理把上面这些组件串起来一个典型的 HA 集群长这样两台 NameNodenn1、nn2三台 JournalNodejn1、jn2、jn3三台 ZooKeeperzk1、zk2、zk3再加若干 DataNode。正常情况下nn1 是 Activenn2 是 Standby。nn1 处理所有客户端请求同时把 EditLog 写到三台 JournalNodenn2 持续从 JournalNode 读取 EditLog 并同步到自己的内存和磁盘。ZooKeeper 集群上nn1 持有 Active 锁nn2 处于待命状态。同时还有一个 ZKFCZooKeeper Failover Controller进程跑在每台 NameNode 上它负责监控 NameNode 的健康状态并代表 NameNode 去 ZooKeeper 上抢锁。ZKFC 是连接 NameNode 和 ZooKeeper 的桥梁没有它自动故障转移就无从谈起。DataNode 这边要同时向两台 NameNode 汇报块信息所以配置里要写两个 NameNode 的地址。客户端这边则通过一个逻辑名称nameservice ID来访问底层由配置决定具体连哪台对上层应用透明。理解了这套架构再看配置文件就不会觉得那些参数是凭空冒出来的了。每一个配置项背后都对应着上面某个组件的行为逻辑。2. 配置文件逐项拆解与参数详解2.1 core-site.xml 的关键改动core-site.xml 是 Hadoop 的全局配置HA 相关的核心改动集中在这里。最关键的参数是fs.defaultFS单节点时它写的是hdfs://主机名:8020HA 模式下要改成逻辑名称比如hdfs://mycluster。这个mycluster就是 nameservice ID你可以随便起名但要和 hdfs-site.xml 里的配置对应上。property namefs.defaultFS/name valuehdfs://mycluster/value /property property nameha.zookeeper.quorum/name valuezk1:2181,zk2:2181,zk3:2181/value /propertyha.zookeeper.quorum告诉 ZKFC 去哪些 ZooKeeper 节点上做选举。这里有个细节端口默认是 2181如果你改过 ZooKeeper 的端口这里必须同步改否则 ZKFC 连不上自动故障转移直接失效。我见过有人 ZooKeeper 端口改成了 2182结果忘了改这里排查了大半天才发现。另外hadoop.tmp.dir也建议显式配置指向一个空间充足的磁盘路径。默认值在 /tmp 下面很多系统重启会清理 /tmp导致集群起不来。这个坑我在早期踩过不止一次。2.2 hdfs-site.xml 的完整配置逻辑hdfs-site.xml 是 HA 配置的重头戏参数最多也最容易配错。我把它拆成几组来讲。第一组是 nameservice 和 NameNode 定义。dfs.nameservices定义逻辑名称dfs.ha.namenodes.mycluster定义这个 nameservice 下有哪些 NameNode比如 nn1 和 nn2。然后每个 NameNode 的 RPC 地址和 HTTP 地址要分别配置。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 valuenn1:8020/value /property property namedfs.namenode.rpc-address.mycluster.nn2/name valuenn2:8020/value /property property namedfs.namenode.http-address.mycluster.nn1/name valuenn1:50070/value /property property namedfs.namenode.http-address.mycluster.nn2/name valuenn2:50070/value /property第二组是 JournalNode 相关。dfs.namenode.shared.edits.dir指向 JournalNode 集群的地址格式是qjournal://jn1:8485;jn2:8485;jn3:8485/mycluster。注意这里的 nameservice ID 要和前面一致。dfs.journalnode.edits.dir是 JournalNode 本地存放编辑日志的路径建议放在独立磁盘上避免和 DataNode 数据盘抢 IO。第三组是故障转移代理。dfs.client.failover.proxy.provider.mycluster指定客户端用哪个类来做故障转移标准值是org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider。这个类负责在 Active 切换后让客户端自动重连到新的 Active 节点。第四组是隔离机制Fencing。dfs.ha.fencing.methods定义当发生脑裂时怎么隔离旧 Active。常见配置是sshfence加shell(/bin/true)。sshfence 需要配置免密登录确保能 SSH 到对方节点把 NameNode 进程杀掉。如果 SSH 不通后面的 shell 方法会兜底。这个配置非常关键配不好可能导致两个 NameNode 同时认为自己是 Active元数据直接损坏。property namedfs.ha.fencing.methods/name valuesshfence shell(/bin/true)/value /property property namedfs.ha.fencing.ssh.private-key-files/name value/home/hadoop/.ssh/id_rsa/value /property第五组是自动故障转移开关。dfs.ha.automatic-failover.enabled设为 true启用 ZKFC 自动切换。这个参数一开ZKFC 进程就必须起来否则集群状态会不正常。2.3 参数之间的依赖关系与常见配错点配置项之间不是孤立的很多参数互相引用。比如dfs.namenode.shared.edits.dir里的 nameservice ID 必须和dfs.nameservices一致dfs.ha.namenodes.mycluster里定义的 nn1、nn2 必须和后面 rpc-address、http-address 的前缀对应。我见过有人 nameservice 叫 mycluster但 shared.edits.dir 里写成了 cluster1结果 JournalNode 根本找不到对应的编辑日志目录NameNode 启动直接报错。还有一个高频错误是端口冲突。NameNode 的 RPC 端口默认 8020HTTP 端口默认 50070JournalNode 默认 8485。如果你在同一台机器上跑多个角色端口必须错开。我一般会在配置前先画一张端口分配表把所有角色的端口列清楚避免后期冲突。另外dfs.replication也要根据 DataNode 数量合理设置。HA 集群至少三台 DataNode 起步副本数设 3 比较稳妥。如果只有两台 DataNode副本数设 3 会导致部分块永远处于欠副本状态虽然不影响读写但集群健康度会一直报警。3. 从零开始的完整启动流程3.1 启动前的环境检查清单在敲任何启动命令之前有几项检查必须做否则后面会浪费大量时间在排错上。我整理了一个检查清单每次搭新集群都照着过一遍。检查项具体内容不通过的后果主机名解析所有节点的 /etc/hosts 包含全部节点的主机名和 IP节点间通信失败SSH 免密nn1 和 nn2 之间双向免密fencing 失败脑裂风险Java 环境所有节点 JAVA_HOME 一致且版本兼容进程启动即退出防火墙相关端口全部放行连接超时选举失败时间同步所有节点时间差在秒级以内ZooKeeper 会话异常目录权限数据目录、日志目录属主正确启动报权限拒绝时间同步这一项特别容易被忽略。ZooKeeper 对时间敏感如果节点之间时间差太大会话超时判断会出问题可能导致误判节点宕机。我一般用 chrony 或 ntp 做同步确保所有节点时间一致。3.2 格式化与首次启动的正确顺序HA 集群的首次启动顺序和单节点完全不同顺序错了就得从头再来。正确顺序是这样的第一步先启动 JournalNode 集群。在三台 JournalNode 上分别执行hadoop-daemon.sh start journalnode。注意JournalNode 必须先于 NameNode 启动因为 NameNode 格式化时需要往 JournalNode 写初始元数据。第二步格式化其中一台 NameNode。在 nn1 上执行hdfs namenode -format -clusterId mycluster。这里的 clusterId 建议显式指定方便后续管理。格式化完成后nn1 的元数据目录里会有初始的 fsimage。第三步启动 nn1 的 NameNode 进程。执行hadoop-daemon.sh start namenode。此时 nn1 会把自己注册到 JournalNode 上并开始写入 EditLog。第四步在 nn2 上同步元数据。执行hdfs namenode -bootstrapStandby。这个命令会让 nn2 从 JournalNode 拉取最新的 fsimage 和 EditLog完成元数据同步。这一步非常关键如果跳过nn2 启动后会因为元数据不一致而无法进入 Standby 状态。第五步格式化 ZooKeeper 上的 HA 状态。在任意一台 NameNode 上执行hdfs zkfc -formatZK。这个命令会在 ZooKeeper 上创建 HA 相关的节点结构。注意这个命令只需要执行一次重复执行会清空已有的 HA 状态可能导致正在运行的集群异常。第六步启动两台 NameNode 的 ZKFC 进程。执行hadoop-daemon.sh start zkfc。ZKFC 启动后会自动去 ZooKeeper 抢锁抢到的那台 NameNode 变成 Active另一台变成 Standby。第七步启动所有 DataNode。在每台 DataNode 上执行hadoop-daemon.sh start datanode。DataNode 启动后会同时向两台 NameNode 汇报集群正式可用。3.3 验证集群状态是否正常启动完成后怎么确认集群真的正常我一般从三个维度验证。第一看 NameNode 的 Web UI。分别访问 nn1 和 nn2 的 50070 端口页面上会明确显示当前是 Active 还是 Standby。正常情况下一台 Active 一台 Standby如果两台都是 Standby说明 ZKFC 没起来或者 ZooKeeper 连不上。第二用命令行查状态。执行hdfs haadmin -getServiceState nn1和hdfs haadmin -getServiceState nn2输出应该是 active 和 standby。如果报错说连不上检查 ZKFC 进程和 ZooKeeper 连接。第三实际写数据测试。执行hdfs dfs -mkdir /test和hdfs dfs -put上传一个文件然后hdfs dfs -ls /test看是否成功。这一步能验证整个链路是否通畅。我还习惯做一个故障转移演练手动 kill 掉 Active 的 NameNode 进程观察 Standby 是否在几十秒内自动切换为 Active。这个演练在生产环境上线前必做确保故障转移真的有效而不是配置看起来对但实际不工作。4. 常见故障与排查经验实录4.1 NameNode 启动失败的高频原因NameNode 起不来是最常见的问题原因五花八门。我整理了几种高频情况。第一种端口被占用。报错信息通常是BindException: Address already in use。这时候用netstat -tlnp | grep 8020查一下谁占用了端口要么杀掉占用进程要么改配置换端口。第二种元数据目录权限不对。报错是Permission denied。检查dfs.namenode.name.dir指向的目录确保运行 Hadoop 的用户有读写权限。我一般会统一用 hadoop 用户跑所有进程目录属主也设成 hadoop。第三种JournalNode 连不上。报错是Unable to connect to JournalNode。先确认 JournalNode 进程是否在跑再检查网络和端口。如果 JournalNode 是刚启动的可能还没完全就绪等几秒再试。第四种clusterId 不一致。如果 nn2 的 clusterId 和 nn1 不同nn2 会拒绝启动。这时候需要检查dfs.namenode.name.dir/current/VERSION文件里的 clusterId确保两台一致。不一致的话重新执行 bootstrapStandby 或者手动改 VERSION 文件。4.2 自动故障转移不生效的排查路径自动故障转移不生效表现是 Active 挂了之后 Standby 不顶上。排查要按链路一步步来。先看 ZKFC 进程是否在跑。jps命令应该能看到 DFSZKFailoverController 进程。如果没有说明 ZKFC 没启动手动启动一下。再看 ZKFC 日志。日志里会明确写它有没有连上 ZooKeeper有没有抢到锁。常见错误是Connection refused说明 ZooKeeper 地址配错了或者 ZooKeeper 没起来。然后检查 ZooKeeper 上的节点状态。用zkCli.sh连上 ZooKeeper执行ls /hadoop-ha/mycluster应该能看到 ActiveBreadCrumb 和 ActiveStandbyElectorLock 之类的节点。如果这个路径不存在说明 formatZK 没执行或者执行失败。最后检查 fencing 配置。如果 fencing 方法配置不当切换时可能卡在隔离旧 Active 的步骤上。日志里会显示Fencing method failed。这时候要么修好 SSH 免密要么调整 fencing 方法。4.3 脑裂问题的预防与处理脑裂Split Brain是 HA 集群最危险的状态两台 NameNode 同时认为自己是 Active同时往 JournalNode 写数据元数据直接损坏。预防脑裂的核心就是 fencing 机制。SSH fencing 的原理是当 Standby 要切换为 Active 时先通过 SSH 连到旧 Active 节点执行命令把 NameNode 进程杀掉。只有确认旧 Active 已经死了新 Active 才正式接管。如果 SSH 连不上fencing 失败切换中止避免脑裂。我遇到过 SSH 免密失效导致 fencing 失败的情况。原因是有人改了密钥或者权限导致 nn1 连不上 nn2。排查方法是手动从 nn1 SSH 到 nn2看是否需要密码。如果需要重新配置免密即可。还有一种情况是网络分区两台 NameNode 都连不上 ZooKeeper但彼此能通。这时候 ZooKeeper 会话超时两台都可能尝试抢锁但因为连不上 ZooKeeper谁也抢不到集群进入不可用状态。这种情况只能等网络恢复或者人工介入。预防办法是 ZooKeeper 集群本身也要高可用避免单点故障。4.4 常见问题速查表现象可能原因排查方法解决方式NameNode 启动报 BindException端口被占用netstat 查端口杀进程或改端口Standby 无法同步元数据JournalNode 未启动jps 查 JournalNode启动 JournalNode自动切换不生效ZKFC 未启动jps 查 ZKFC启动 ZKFC切换卡住fencing 失败查 ZKFC 日志修 SSH 免密两台都是 StandbyZooKeeper 连不上查 ZooKeeper 状态恢复 ZooKeeper客户端连不上nameservice 配错查 core-site.xml修正配置这张表是我这些年排障经验的浓缩基本上覆盖了八成以上的常见问题。遇到问题先查表能省不少时间。5. 生产环境下的优化建议与个人心得5.1 硬件与部署层面的经验生产环境的 HA 集群硬件不能太寒酸。NameNode 对内存要求高因为元数据全在内存里我一般建议至少 64G 内存起步元数据量大的话 128G 也不过分。JournalNode 对磁盘 IO 敏感建议用 SSD且独立于 DataNode 的数据盘。ZooKeeper 对延迟敏感建议单独部署不要和 NameNode 混部。网络方面NameNode 和 JournalNode 之间、NameNode 和 ZooKeeper 之间的网络延迟要低。我见过跨机房部署 JournalNode 的延迟几十毫秒导致 EditLog 写入慢整个集群性能下降。JournalNode 最好和 NameNode 同机房。5.2 日常运维中的监控要点HA 集群上线后监控要跟上。我重点监控几个指标NameNode 的堆内存使用率、JournalNode 的写入延迟、ZooKeeper 的会话数、ZKFC 的切换次数。切换次数这个指标特别重要如果频繁切换说明集群不稳定要赶紧排查。另外建议定期做故障转移演练至少每季度一次。演练内容包括手动 kill Active、模拟网络分区、模拟 ZooKeeper 宕机等。只有真正演练过才知道配置是否可靠团队是否有能力处理故障。5.3 我踩过的几个印象深刻的坑第一个坑是格式化顺序搞反。我第一次搭 HA 时先格式化了 NameNode 才启动 JournalNode结果 NameNode 格式化时找不到 JournalNode元数据写不进去后面怎么都起不来。后来才明白JournalNode 必须先启动。第二个坑是忘了 formatZK。ZKFC 启动后一直报错说找不到 HA 节点。查了半天才发现 ZooKeeper 上根本没有 HA 的目录结构因为 formatZK 没执行。这个命令很容易被忽略但它是自动故障转移的前提。第三个坑是 fencing 配置里 SSH 密钥路径写错。配置里写的是/home/hadoop/.ssh/id_rsa但实际密钥在/root/.ssh/下面因为当时用 root 跑的。结果 fencing 一直失败切换不了。后来统一用 hadoop 用户路径也统一了问题才解决。这些坑看起来都是小问题但在实际排障时往往就是这些小细节卡住你几个小时。所以我现在养成了一个习惯每次搭集群都照着检查清单过一遍不凭记忆不跳步骤。5.4 后续扩展的方向这套 HA 架构搭好之后还可以继续扩展。比如加 Federation把多个 nameservice 联合起来突破单 NameNode 的内存瓶颈。或者加 Router 做联邦路由让客户端透明访问多个子集群。再比如把 JournalNode 和 ZooKeeper 的监控接入统一的告警平台实现自动化运维。不过这些都是后话先把基础 HA 搭稳把故障转移演练做扎实比什么都重要。我见过太多集群配置看起来花哨但真出故障时切换不了那还不如老老实实把基础打好。最后分享一个小技巧每次修改配置文件后不要急着重启整个集群先用hdfs haadmin -getServiceState和hdfs dfsadmin -report检查状态确认配置生效且集群健康再逐步重启相关进程。这样能把影响降到最低也方便定位问题。