做大数据平台的人迟早都会碰到一个问题集群里的NameNode挂了整个HDFS就瘫了。对就是那个管理着所有文件元数据、目录树、block映射的进程它一旦退出客户端连文件读写都做不了所有跑在上面的计算任务跟着全部失败。我最初维护的几套集群就是单NameNode架构每次重启、升级、甚至一次内存抖动都要提心吊胆。后来下决心把核心集群改造成Hadoop高可用HA架构用ZooKeeper做主节点选举、JournalNode同步日志配合ZKFC自动切换才真正把集群的可用性提上来。这篇文章就把我在设计、部署和运行Hadoop HA集群过程中沉淀下来的方案、踩过的坑和一些体会完整地梳理出来给正在规划或维护大数据集群的同学做个参考。1. 为什么必须做高可用从单点故障说起1.1 单NameNode的致命瓶颈先说清楚问题本身。NameNode在HDFS里承担的是“大脑”角色所有文件的元数据信息——路径、权限、副本位置、block列表——都由它维护客户端的读写请求必须先跟它确认元数据才能真正开始传输数据。所以NameNode一旦不可用整个HDFS就变成一个只能看不能用的黑盒子所有依赖HDFS的组件Hive、Spark、MapReduce、HBase等全部被拖垮影响面是级联式的不只是“慢一点”那么简单。有人会问Hadoop不是自带SecondaryNameNode吗它难道不能顶上去这是个很常见的误解。SecondaryNameNode根本就不是热备节点它的职责是定期从NameNode拉取fsimage和edits合并后回传给NameNode相当于一个checkpoint辅助进程。它不持有完整的、实时的元数据状态也没有能力在NameNode故障时自动接管服务真正故障发生时靠它恢复光是日志合并、元数据加载就够折腾半天期间业务完全不可用。我印象很深的一次事故某天凌晨NameNode进程突然退出靠SecondaryNameNode手动恢复整个恢复过程花了将近两个小时业务侧的电话一个接一个打过来那滋味真不好受。那次之后我就下定决心生产集群必须上HA不能拿单点去赌运气。1.2 高可用要解决的核心问题HA方案表面上是“加一台NameNode当备机”但深挖下去它要解决的是三个环环相扣的问题。第一个问题元数据不能丢。Active NameNode在运行过程中会不断产生edits日志这些日志记录了所有元数据变更操作如果只写在本地磁盘一旦节点故障就可能丢数据所以必须把这些日志同步到一个“共享层”让Standby节点也能读到。第二个问题主备状态必须一致。光有日志还不够Standby节点要持续消费这些日志并应用到自己的内存元数据中保证自己随时“知道”集群的最新状态这样拿过来才能用而不是接管之后还要花很长时间恢复元数据。第三个问题故障要能自动转移。主节点挂了备节点要能感知到并且快速接管服务。这背后涉及健康检测、选主、以及一个非常关键的隔离机制——fencing防止两个节点同时认为自己是Active也就是“脑裂”。用一个生活化的比喻这就像两个值班员共用一个工作日志本A负责干活B在旁边同步抄写日志。A倒地了B要能发现从日志本上确认最新进度然后接过工作。但前提是有人在确认A确实“死透了”之后才能让B接手否则两个人同时写日志工作记录就全乱了。1.3 方案选型为什么最终选择QJMHadoop HA的共享存储方案历史上出现过几个方向。一种是基于NFS共享目录的方案把edits日志放到NFS上两个NameNode共用。它实现简单但依赖NFS这个单点存储本身一旦出问题整个HA都失效而且脑裂隔离做起来很困难。另一种是BookKeeper方案虽然可靠但部署运维成本高生产环境中很少见到。目前最主流、最推荐的方案是QJMQuorum Journal Manager仲裁日志管理器也就是使用一组JournalNode通常3个来存储edits日志。QJM采用“多数派写成功”机制——Active写入一条日志必须至少2个JournalNode3节点集群中返回成功才算写入成功。这样整个日志存储层本身就是高可用的坏掉一个JournalNode不影响写入也不需要额外依赖NFS这类共享存储设备。我自己最终选择QJM就是看中它三个优势第一不依赖特定硬件普通服务器就能跑第二一致性模型清晰多数派协议在分布式领域已经被验证得很充分第三与HDFS生态集成度高配置项完善网上踩坑案例多出了问题也好查。后面的内容全部围绕QJM方案展开。2. 核心组件原理解析不只是“多个节点”那么简单2.1 ZooKeeper在HA里到底干了什么很多初学者以为ZooKeeper在HA里是存元数据的其实不是。ZK在HDFS HA中的核心角色是“分布式协调器”主要管两件事选主和故障探测。具体机制是两个ZKFCZooKeeper Failover ControllerZK故障切换控制器进程会去ZooKeeper上争抢同一个临时节点锁节点。Active NameNode对应的ZKFC持有这个锁Standby节点的ZKFC则持续监控这个锁节点的状态。一旦Active NameNode异常ZKFC与ZooKeeper之间的会话会超时临时节点自动被删除。Standby的ZKFC立刻感知到这个变化发起新的一轮选主流程。这里面有个关键点ZooKeeper本身不参与HDFS元数据的读写它只提供“谁持有锁”的状态信息。所以ZK集群不要和NameNode抢资源但也不要觉得它不重要因为ZK一旦出问题HA的自动切换机制就废了生产环境强烈建议至少部署3台ZK并保证它们所在节点的网络稳定。2.2 JournalNode与QJM日志一致性保证先看JournalNode本身。它就是一个轻量级守护进程专门用来接收、存储、分发edits日志。生产推荐部署3个JournalNode因为QJM写入遵循“多数派成功”原则3个节点允许坏1个5个节点允许坏2个一般3个就够用了。Active NameNode每次元数据变更都会生成一条edits并发给所有JournalNode。JournalNode各自写入本地磁盘后返回确认Active只有收到超过半数3节点中至少2个的确认才认为这次元数据变更成功。如果某个JournalNode响应慢或者挂了只要还有2个节点成功写入照常进行这就是多数派协议的价值。Standby NameNode会持续从JournalNode拉取新的edits读到一条就立即应用到自己的内存镜像中让自身保持“准实时同步状态”。这样当故障发生Standby接管时它已经具备和Active几乎一致的元数据可以快速对外提供服务。可以理解为JournalNode就像前面比喻里的“共享日志本”而且这个日志本有3本副本只要其中2本写上了工作日志就算记下来了。这种设计把“单点共享存储”变成了“分布式共享日志”从根源上避免了NFS方案的存储单点问题。2.3 ZKFC与Fencing如何彻底避免脑裂ZKFC是NameNode节点上的一个小守护进程职责有两个一是持续监控本机NameNode的健康状态比如调用健康检查接口二是与ZooKeeper交互参与选主。Active和Standby节点上各有一个ZKFC它们互相配合构成了自动故障切换的最前端。再来看fencing这是整个HA方案里容易被忽视、但恰恰最要命的一环。所谓fencing就是“隔离”确保旧的Active节点在失去领导权后无法再往JournalNode写入任何edits。如果不做这一步极端场景下可能出现两个NameNode同时认为自己是Active、同时写入edits的情况也就是脑裂最终导致元数据分叉整个集群数据损坏后果远比“暂停服务”严重。HDFS内置的fencing方式主要有两种sshfence和shell。sshfence通过SSH登录到旧Active节点执行fuser或者kill命令强制杀掉NameNode进程shell可以执行任意自定义脚本比如调用硬件管理接口强制重启机器。我生产环境用的是sshfence配合免密登录。需要特别提醒sshfence依赖到目标节点的SSH连通性和执行权限如果网络隔离或权限不足fencing会失败切换流程会中断所以一定提前把SSH免密、用户sudo权限这些基建搞好。2.4 故障切换的完整时序把整个自动切换流程串起来看大致是这么几步Active节点上的ZKFC持续健康检查发现NameNode进程无响应或状态异常该ZKFC与ZooKeeper的会话超时临时锁节点自动消失Standby节点的ZKFC监控到锁节点被删除向ZooKeeper发起新一轮选主请求Standby ZKFC成功创建新锁节点宣告自己的节点赢得选举执行fencing通过sshfence杀掉旧Active上的NameNode进程确保它无法再写edits新Active从JournalNode读取全部尚未应用的edits完成元数据追平新Active正式对外提供服务客户端通过配置的proxy provider自动重连。整个流程中客户端不需要感知后端变化因为客户端配置了dfs.client.failover.proxy.provider它会在连接失败时自动尝试另一台NameNode。不过要注意故障切换不是零损失的正在执行的作业可能会失败重试只是相比过去人工恢复分钟级甚至秒级的自动切换已经能显著缩小故障窗口。3. 实操Hadoop HA集群设计与落地全流程3.1 资源规划与角色分配先谈资源规划这一步直接影响后续运维的舒适度。以一套3节点ZK 2节点NameNode 3节点JournalNode的常见中小型集群为例推荐的部署形态是把ZK和JN角色合并部署在3台独立节点上同时这3台也可以承担其他轻量级角色但要避免和DataNode混装导致磁盘IO竞争。下面是我常用的一套6节点布局节点角色node1NameNode(active), ZKFC, ZooKeeper, JournalNodenode2NameNode(standby), ZKFC, ZooKeeper, JournalNodenode3ZooKeeper, JournalNodenode4DataNode, NodeManagernode5DataNode, NodeManagernode6DataNode, NodeManager如果你预算允许更推荐把ZooKeeper单独用3台小规格机器部署和NameNode、JournalNode都分开减少角色间的互相干扰。JournalNode的磁盘建议用SSD或者至少独立的机械盘因为每次edits写入都要经过它磁盘延迟会直接影响HDFS的写入性能这块千万别省。NameNode的JVM堆内存也要提前估算。业界通常的经验是1GB堆内存可以管理大约100万个对象但实际每个block、文件的元数据对象占用还不一样建议生产环境至少16GB起步元数据量大的集群上到32GB甚至更大。Standby节点同样要分配相同学内存因为它在故障时要能无缝接管。3.2 环境准备与版本选择部署之前环境准备工作如果没做扎实后面排查问题会非常痛苦。我列一下自己每次部署都会检查的清单JDK版本Hadoop 3.x推荐JDK 8或JDK 11不同版本测试矩阵不一样别乱升大版本Hadoop版本生产环境建议用稳定版比如3.3.x系列社区bug修复及时时间同步所有节点必须配置NTP或chrony时间漂移会直接影响ZooKeeper会话判断和edits日志顺序SSH免密NameNode节点之间必须做SSH免密因为sshfence要登录过去杀进程防火墙与端口提前放通NameNode RPC/HTTP端口、JournalNode的8485/8480端口、ZooKeeper的2181/2888/3888端口、ZKFC的8019端口主机名与/etc/hosts所有节点统一使用主机名通信避免IP变动带来的隐患。版本选择方面我个人建议新集群直接上Hadoop 3.x系列。3.x在HA配置上有很多细节优化比如NameNode HTTP端口从2.x的50070改成了9870RPC端口、DataNode通信端口也有变化网上很多旧教程是2.x的照着配容易踩坑抄作业时一定要确认版本。3.3 核心配置文件解析配置HA时主要改两个文件core-site.xml和hdfs-site.xml。下面给一份我实际部署用的配置模板关键项都加了注释说明。core-site.xml中最重要的是指定默认文件系统为HA逻辑名称以及配置客户端故障转移的proxy providerconfiguration property namefs.defaultFS/name valuehdfs://mycluster/value /property property namehadoop.proxyuser.hadoop.hosts/name value*/value /property property namehadoop.proxyuser.hadoop.groups/name value*/value /property /configurationhdfs-site.xml里需要配置nameservice、两个NameNode的地址、JournalNode地址、自动故障切换开关和fencing方式。这里我截取核心部分configuration !-- 命名服务名称和core-site.xml里的hdfs://mycluster对应 -- property namedfs.nameservices/name valuemycluster/value /property !-- 该nameservice下有两个NameNode逻辑ID分别为nn1和nn2 -- property namedfs.ha.namenodes.mycluster/name valuenn1,nn2/value /property !-- nn1和nn2的RPC通信地址 -- property namedfs.namenode.rpc-address.mycluster.nn1/name valuenode1:8020/value /property property namedfs.namenode.rpc-address.mycluster.nn2/name valuenode2:8020/value /property !-- nn1和nn2的HTTP UI地址3.x版本默认9870 -- property namedfs.namenode.http-address.mycluster.nn1/name valuenode1:9870/value /property property namedfs.namenode.http-address.mycluster.nn2/name valuenode2:9870/value /property !-- 共享edits目录使用QJM协议指向三台JournalNode -- property namedfs.namenode.shared.edits.dir/name valueqjournal://node1:8485;node2:8485;node3:8485/mycluster/value /property !-- 客户端故障转移代理实现 -- property namedfs.client.failover.proxy.provider.mycluster/name valueorg.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider/value /property !-- JournalNode本地存储edits的目录 -- property namedfs.journalnode.edits.dir/name value/data/hdfs/journal/value /property !-- 开启自动故障切换 -- property namedfs.ha.automatic-failover.enabled/name valuetrue/value /property !-- 配置fencing方式生产环境用sshfence -- property namedfs.ha.fencing.methods/name valuesshfence/value /property property namedfs.ha.fencing.ssh.private-key-files/name value/home/hadoop/.ssh/id_rsa/value /property property namedfs.ha.fencing.ssh.connect-timeout/name value30000/value /property /configuration这里有个容易搞混的点dfs.nameservices的值是逻辑名称可以自定义但必须保证core-site.xml里的fs.defaultFS、hdfs-site.xml里的nameservices、qjournal路径里的nameservice三处一致。我见过不少同学因为这个名称对不上启动NameNode时各种莫名其妙的报错。3.4 初始化与启动顺序不对全白搭HA集群的启动顺序非常讲究顺序错了轻则启动失败重则元数据不一致。我梳理一下我自己反复验证过的一套标准流程第一步启动ZooKeeper集群。三台节点都执行zkServer.sh start然后用zkServer.sh status确认主从角色正常。第二步在三台JournalNode节点上分别启动journalnode进程hdfs --daemon start journalnode启动后检查日志确认没有异常进程能正常监听8485端口。第三步在一台NameNode比如node1上执行格式化hdfs namenode -format这一步会生成集群的clusterID、namespaceID等元数据。如果你是从已有单NameNode集群迁移到HA这一步不能直接format否则会丢掉原来的元数据正确做法是在原有NameNode上保持数据直接走后续的bootstrapStandby流程。第四步同步元数据到Standby节点。在node2上执行hdfs namenode -bootstrapStandby这个命令会把node1上的元数据目录包括fsimage复制到node2并保证两边的clusterID一致比手动拷贝current目录更安全。第五步初始化共享edits日志。在node1上执行hdfs namenode -initializeSharedEdits该命令会把当前NameNode上的edits日志初始化到JournalNode集群中这样Standby才能从JournalNode读到日志。注意如果你采用的是“全新集群”部署也可以先启动JournalNode再格式化NameNode最后initializeSharedEdits。但绝不能让JournalNode还没有初始化共享日志的时候就启动两个NameNode否则会出现谁能写、写哪里都搞不清楚的局面。第六步手动启动两个NameNodehdfs --daemon start namenode在node1和node2上分别执行。启动后访问node1:9870、node2:9870确认Web UI正常。第七步初始化ZKFC在ZooKeeper中的状态hdfs zkfc -formatZK这一步会在ZooKeeper中创建HA的锁节点路径只在首次部署时执行以后不要随便再跑。第八步在node1和node2上分别启动ZKFC进程hdfs --daemon start zkfc第九步验证HA状态hdfs haadmin -getAllServiceState正常输出应该是一个节点显示active另一个显示standby两个节点的状态不能都是active也不能都是standby。这里补充一个常见坑很多教程会让人先format再启动journalnode或者先启动NameNode再初始化shared edits流程一乱就会出现“A节点认为自己是activeB节点也认为自己是active”的伪脑裂状态。建议把你自己的部署环境当成白纸严格按上面顺序执行一次之后再做变更就有底了。3.5 故障切换演练如何验证HA真的可用配置完不能拍拍手就完事一定要做一次故障演练。我在每次新集群交付时都会做这几步验证第一步先正常提交一些测试文件到HDFS比如用hdfs dfs -put上传几个文件确认集群写入正常。第二步在Active NameNode节点上直接kill掉NameNode进程kill -9 namenode_pid模拟进程级故障。第三步观察Standby节点日志和zkfc日志通常在几十秒内Standby会接管为Active不再有手动干预。第四步重新执行文件写入和读取确认客户端能正常连接。因为客户端有failover provider它会自动重连到新的Active上。第五步把被kill的NameNode重新启动确认它作为Standby回归集群hdfs --daemon start namenode启动后过一段时间再次执行hdfs haadmin -getAllServiceState确认“新的Active 新的Standby”组合是正常的。特别提醒演练前一定要对集群做一次完整备份或快照防止意外损伤数据。我见过有人演练时fencing没生效两个NameNode同时写edits最后只能靠备份恢复非常惨烈。4. 常见问题与排查技巧实录4.1 问题速查表把高频问题整理成一个速查表方便大家定位现象可能原因排查手段解决建议Active NameNode启动失败报JournalNode不可用JournalNode没启动、端口不通、qjournal路径配置错误检查JournalNode进程状态、telnet端口8485先启动所有JournalNode再启动NameNodebootstrapStandby报错元数据同步失败node2的current目录已存在且clusterID不一致查看namenode日志中具体报错备份后删除node2的current目录重新bootstrap两个NameNode都显示standby自动切换未开启、ZKFC未启动、选主失败检查zkfc进程、ZooKeeper锁节点启动zkfc检查ha.zookeeper.quorum配置两个NameNode都显示active脑裂fencing未生效立即停止所有NN和ZKFC评估数据一致性手动选择元数据最新的节点重建standby客户端切换后报连接失败客户端未配置failover proxy provider检查core-site.xml中的provider配置添加ConfiguredFailoverProxyProvider并分发到客户端自动切换后旧Active仍存活并能写editsfencing方法执行失败查看ZKFC日志、检查SSH免密配置shell fence兜底或修复ssh权限JournalNode上edits目录涨得很快两个NameNode可能都在写日志或日志清理未配置检查各JournalNode的edits大小是否一致修复脑裂并确认只有Active写日志4.2 一个真实案例脑裂后的恢复过程有一次我遇到过一次网络抖动引发的“伪脑裂”当时恢复过程很值得记录。现象是集群告警提示两个NameNode都变成了active状态客户端写入时分时成功分时失败元数据有分叉风险。我第一时间做了三件事第一步在所有NameNode节点上立刻停止NameNode进程和ZKFC进程避免继续写入edits第二步停止所有JournalNode进程确保日志不再增长第三步逐一检查两个NameNode的本地edits日志找出谁能追平到最新状态。由于QJM的edits日志只允许Active写入理论上不可能两个都“合法”但在fencing失败的情况下确实可能两边的edits都有新内容。我当时的做法是选择其中一个NameNode将其本地edits末尾内容与JournalNode上的日志对比没有冲突就把它作为基准然后将另一个NameNode的元数据目录清空用bootstrapStandby重新同步最后启动ZKFC重新选主集群恢复。这个案例给我们的教训很深刻HA不是万能的自动切换不等于永远不会脑裂fencing配置必须经过实际演练验证。同时恢复时的心态要冷静——先停服务再分析数据不要急着拉活业务。4.3 那些不容易发现的小坑除了上面这些显性问题还有一些隐藏坑是从实战里慢慢摸出来的。第一个是JournalNode与DataNode混布时的磁盘竞争。如果你的JournalNode和DataNode在同一块盘上DataNode大量读写时edits日志写入容易被拖慢进而影响HDFS整体写入性能。建议JournalNode用独立盘或者和NameNode错开部署。第二个是sshfence的权限问题。sshfence本质是SSH到目标机器执行fuser命令杀进程如果启动NameNode的用户没有权限操作目标进程fencing会失败。生产环境建议配置sudo免密或者用专门的运维账号管理。第三个是ZKFC手动操作和自动切换的冲突。开启了dfs.ha.automatic-failover.enabled之后原则上不要再用hdfs haadmin -transitionToActive手动切换因为手动和自动选主机制会互相打架很容易搞出双Active。如果确实需要手动切换先把自动切换开关关闭操作完再开启。第四个是升级Hadoop版本时HA配置项会变化。比如Hadoop 3.x中改了一些默认端口namenode http端口从50070变成9870QJM相关配置项也做了调整网上搜到的大部分教程都是2.x时代的照抄前一定要对照官方文档确认。5. 高可用方案的延伸与边界5.1 HDFS HA之外YARN ResourceManager HA聊完HDFS的HA还必须提一句YARN层面的ResourceManager HA。集群的可用性不是只有NameNode一个点ResourceManager负责集群资源调度它挂了作业照样跑不了。好在YARN的HA思路和HDFS高度相似也是基于ZooKeeper做选主配置两个ResourceManager一个Active一个Standby主要配置在yarn-site.xml里。核心配置包括yarn.resourcemanager.ha.enabled、yarn.resourcemanager.ha.rm-ids、yarn.resourcemanager.zk-address等。启动时先启动ZooKeeper再启动两个ResourceManager最后把RM的Web代理也配上。这块的故障切换和HDFS一样也需要结合ZKFCYARN里叫EmbeddedElector集成在RM进程中实现配置项没有HDFS那么复杂但同样要做故障演练。我自己的经验是一个完整的高可用大数据平台至少要在三个层面做HAHDFS NameNode、YARN ResourceManager、Hive Metastore或其它元数据服务。只做其中某一个整体可用性提升有限。5.2 高可用不等于数据高可用这里必须强调一个容易混淆的概念HA解决的是进程可用性解决的是“节点挂了业务还能继续跑”但它不等于数据高可用。数据不丢靠的是HDFS的多副本机制、机架感知、以及定期的快照和备份策略。所以我的建议是HA和副本策略要同时做。比如将默认副本因子设置为3并配合机架感知让副本分布在不同机架防止整个机架断电导致数据全部丢失同时定期对关键目录做快照hdfs dfsadmin -allowSnapshot后可以创建快照万一逻辑误删还有回滚余地。HA负责扛进程故障副本和快照负责扛数据故障两者是互补关系。5.3 什么时候该考虑Federation或其他形态HA方案也不是银弹。当集群规模增长到单NameNode内存无法支撑全部元数据时即使HA也解决不了性能瓶颈因为同一个时刻只有一个Active能对外服务元数据总量还是压在那台机器上。这时候就要考虑HDFS Federation方案把多个NameNode组成联邦每个NameNode管理一部分目录命名空间实现元数据水平扩展。另外如果上云或者新业务选型也可以考虑用对象存储替代或补充HDFS比如云上的OSS/S3/COS等它们的元数据层天然分布式几乎不需要考虑NameNode单点问题但随之而来的是语义差异和网络延迟需要业务侧做适配。我的建议是中小规模、强依赖HDFS生态的团队继续用HA QJM方案规模大到单NameNode扛不住再考虑联邦或者迁移到对象存储别一上来就追求最复杂的架构。这套HA方案我们已经在生产环境稳定运行了两年多真正发生自动切换的次数其实不多但每次切换都帮我挡下了灾难级别的影响。给我留下最深印象的教训是HA不是配完就结束的它需要定期演练切换流程确认运维手册上的每一条命令在真实故障时真的能跑通。如果等凌晨三点收到告警再翻文档查fencing是不是配对了那种压力真的让人崩溃。希望这篇文章能帮你把Hadoop HA的每个环节都搞清楚也少踩一些我踩过的坑。