不知道大家有没有想过一个问题Hadoop集群的“老大”挂了整个集群是不是就瘫痪了在很多初学者的认知里HDFS的NameNode就是那个总指挥它挂了集群就停摆。你说得没错在没有HAHigh Availability高可用的年代这确实就是常态。Hadoop能把数据分散到几百上千台机器上存却会因为一台NameNode宕机而全员失业听起来挺讽刺的。这一篇笔记我就是来聊清楚这件事的。HDFS与Hadoop的HA核心就干一件事让整个集群有“备胎”而且这个备胎能无缝顶上客户端甚至感知不到变化。这篇文章适合刚学完HDFS基础、开始接触生产环境部署的人也适合那些打算自己搭一套高可用集群、但被各种概念绕晕的朋友。我会从设计思路讲到组件原理再给一套完整的搭建过程最后把实战中容易踩的坑挨个点名。看完你就能明白为什么现在几乎没有哪个正经集群敢不做HA。1. 为什么HDFS非做HA不可——从单点故障说起1.1 HDFS的“老大”只有一个要理解HA的必要性先搞清楚HDFS的架构痛点。HDFS是主从架构NameNode负责管理整个文件系统的元数据哪些文件、存在哪些Block、Block分布在哪些DataNode上全在它脑子里。DataNode是真正存数据的人但它们是“没头脑”的执行者只听NameNode指挥。问题就出在这个“总指挥”上NameNode是单点的。如果不做HA它挂了会出现什么后果客户端无法再读写文件所有任务全部失败DataNode因为收不到心跳也会慌甚至可能开始自行删除副本当然它有保护机制但集群确实处于不可用状态。注意NameNode挂了不等于数据丢了。数据还在DataNode上元数据也还在本地的FsImage和EditLog里。但问题是你没法访问它也不知道怎么把这些数据重新组织起来。整个过程就像硬盘还在但操作系统打不开了。1.2 普通主备切换为什么不行有人会说备份一个NameNode不就行了主挂了把备用顶上。想法没错但实现起来没那么简单。两台NameNode如果各自为政一台写了新的元数据另外一台不知道等切换过去发现状态不一致数据可能已经乱了。HDFS对元数据一致性要求极高因为元数据一旦不一致客户端看到的文件结构就是错的甚至可能读到损坏的数据。所以HA的核心不是“再放一台一样的东西”而是让两台NameNode能保持元数据实时同步同时还要保证任何时刻只有一台在对外提供服务。这就是Active和Standby两个角色的由来Active对外服务处理所有客户端请求Standby同步状态随时准备接替。两个角色不是固定的主挂了备用顶上原主恢复后变成新的Standby。整个过程不能靠人肉盯着得自动化。我见过不少初学者有这种想法把NameNode的元数据目录做成NFS共享两台机器挂同一个目录不就同步了这个思路确实在Hadoop早期版本用过。NFS本身是个单点而且性能瓶颈明显网络抖动就会导致整个元数据写不进去。还有更麻烦的NFS的“分布式锁”能力很差两台NameNode同时写一个文件时你可能得到一个乱七八糟的混合体。后来又试过基于传统共享存储的方案但最终胜出的还是我们自己下面要讲的Quorum Journal Manager方式。1.3 共享存储的纠葛NFS往事与QJM登场在Hadoop 2.x之前做HA的方式确实是靠共享存储比如NFS或商业SAN设备。这种方式的好处是概念简单NameNode把EditLog写到共享目录里就行。代价也很明显共享存储本身是单点存储挂了两个NameNode都完蛋。主备切换时如果共享目录里数据损坏没有任何可回退的东西。NFS性能受限于网络和存储元数据操作频繁日志量大会拖垮整个集群。商业SAN价格感人不是每个团队都烧得起。Hadoop后来抛弃了这个方向内置了QJMQuorum Journal Manager仲裁日志管理器方案。它本质上是搞了多个JournalNode节点组成一个小集群专门负责存储EditLog。NameNode在写EditLog时只有“大多数”JournalNode确认写成功了才算写成功。这就是QCQuorum Callback机制。为什么是“大多数”因为要保证两个NameNode不会同时认为自己是Active。假如有3个JournalNode某个NameNode想成为Active它必须能读到大多数2个以上JournalNode最新日志并且得到ZooKeeper的支持。如果网络分区把两台NameNode隔开最多只有一边能凑齐“大多数”另一边就只能乖乖当Standby不可能出现“脑裂”split-brain两边同时写的情况。这个思想跟Raft、Paxos这类共识算法是一致的只不过Hadoop把它用在了日志存储上。2. HA集群的“四梁八柱”——核心组件与选型逻辑2.1 ZooKeeper选主这件事就交给专业机构搞HA离不开ZooKeeper。它在这套架构里扮演的角色是协调者负责三件事维护NameNode的健康状态、选举Active节点、管理自动故障转移的触发。为什么选它而不是自己写一套因为ZooKeeper本身就是为分布式协调而生的它提供了临时节点Ephemeral Node和监听机制。Active NameNode会在ZooKeeper上创建一个临时节点如果它挂了会话超时后临时节点自动消失Standby那边立刻收到通知开始新一轮选举。ZooKeeper集群一般也部署奇数个节点比如3个或5个。它自己还要存活大多数才能对外服务。所以一个完整的HA集群至少有2个NameNode 3个JournalNode 3个ZooKeeper节点。不少生产集群还会把ZooKeeper和JournalNode部署在同样的机器上省资源后面我会给出一套我常用的布局。2.2 JournalNode让两个NameNode对上账本可以把JournalNode理解成“共享日志服务器”。Active NameNode的每一次元数据修改都会追加写到EditLog里然后通过QJM协议同步到所有JournalNode。Standby NameNode则不停地从JournalNode上读这些日志重放到自己的内存里保证它跟Active的状态保持接近一致。选JournalNode数量时有讲究奇数个至少要大于一半。原理很简单如果只有2个JournalNode其中一个网络故障剩下1个不满足“大多数”至少2个结果任何NameNode都不能写EditLog了集群直接瘫痪。3个看起来只比2个多1个但容错能力却完全不同——允许挂1个。5个允许挂2个7个允许挂3个。提示JournalNode不是越装越多越好。每写一次EditLog都要等大多数节点确认节点越多同步开销越大。常规集群3个足够大型集群可以上5个再多基本没有意义。我自己搭集群一般选3个便宜又皮实。2.3 ZKFC每个NameNode的“贴身哨兵”ZKFCZooKeeper Failover ControllerZooKeeper故障转移控制器是跑在NameNode旁边的独立守护进程。每个NameNode节点都部署一个ZKFC它干的事很纯粹定期向ZooKeeper发送心跳同时监控本机NameNode的健康状态。如果本机NameNode正常它就尝试在ZooKeeper上创建代表Active的临时节点。如果本机NameNode挂了或者健康检查失败它主动删除对应的临时节点让对方有机会抢占Active。当选主成功后它还会主动确认对方的NameNode已经进入Standby状态通过SSH执行命令或调用专门的接口防止两边同时Active。这里有个容易误解的地方ZKFC挂掉不等于NameNode挂掉。ZKFC只是监测和控制的进程如果它本身异常退出ZooKeeper会因会话超时删除临时节点此时即使NameNode还活着也可能被强制降级成Standby。所以ZKFC进程本身也要纳入监控体系。2.4 Fencing机制物理隔离才能杜绝脑子分裂前面一直强调“绝对不能出现两个Active”但光靠协议约束还不够万一真出现网络分区加上极端情况两边同时认为自己是Active怎么办那就需要Fencing隔离机制兜底。Fencing的本质是选主成功后新的Active要么确认旧的Active已经被“杀掉”要么有什么手段让旧节点无法继续工作。Hadoop里常用的隔离方式有通过SSH远程执行命令强制停止旧NameNode的进程fuser或者kill。调用HDFS自带的transitionToStandby接口强制旧NameNode转为Standby。如果配了共享存储还可以断开旧NameNode对存储的访问权限。很多人只关注“如何选新主”却忽略“如何处置旧主”。在真实生产环境里脑裂是比NameNode宕机更恐怖的故障轻则元数据错乱重则整个集群数据不可恢复。所以配置HA时一定要把dfs.ha.fencing.methods配完整。我用的是sshfence加一个shell脚本兜底确保就算SSH失败也有第二重手段把旧节点拉下来。3. 动手搭建HA集群——从规划到跑通的完整实录3.1 集群规划与版本选择我们实际建集群时会明确每台机器的角色。这里以一套精简但完整的5节点HA集群为例规划如下全部使用虚构的主机名实际使用时应替换为你的节点主机名角色与组件node01NameNodeActive候选、ZKFC、JournalNode、ZooKeepernode02NameNodeStandby候选、ZKFC、JournalNode、ZooKeepernode03DataNode、JournalNode、ZooKeepernode04DataNode、ResourceManagernode05DataNode、ResourceManagerResourceManager的HA属于YARN范畴这篇文章不展开但注意规划时可以一并考虑避免后期重复部署。上面这个布局里ZooKeeper和JournalNode都放在前3个节点机器资源足够的话可以拆分小型测试集群这样搭完全Ok。版本选择我建议直接用Hadoop 3.x。Hadoop 3.x本身对HA的配置精简了不少例如不需要单独为ZKFC配置密钥登录还支持了基于内置的基于容器和本地化机制的NameNode自动恢复等特性。最重要的是Hadoop 3.x中RPC端口等信息都能用默认值配置文件更简洁。如果你还在翻2.x的老教程很多步骤对新版本已经不再适用照着抄容易出事。3.2 配置文件的修改要点核心配置文件集中在$HADOOP_HOME/etc/hadoop下面。与HA相关的核心是core-site.xml和hdfs-site.xml。下面给出最小可用的配置并逐一说明含义。先看core-site.xml重点设置默认文件系统为HA服务的名字服务以及ZooKeeper连接地址configuration property namefs.defaultFS/name valuehdfs://mycluster/value /property property nameha.zookeeper.quorum/name valuenode01:2181,node02:2181,node03:2181/value /property /configurationfs.defaultFS这里写的mycluster是一个逻辑名称它会映射到后面对应的两个NameNode地址。ha.zookeeper.quorum告诉HDFS到哪里找ZooKeeper集群如果ZooKeeper装了多个节点这里要全部写上。再来看重头戏hdfs-site.xml先设置全局名字服务property namedfs.nameservices/name valuemycluster/value /property这个mycluster就是逻辑名称后面所有跟HA相关的配置都会带上这个前缀类似dfs.ha.namenodes.mycluster。接着定义这个集群里有哪些NameNode ID以及它们的RPC和HTTP通信地址property namedfs.ha.namenodes.mycluster/name valuenn1,nn2/value /property property namedfs.namenode.rpc-address.mycluster.nn1/name valuenode01:8020/value /property property namedfs.namenode.rpc-address.mycluster.nn2/name valuenode02:8020/value /property property namedfs.namenode.http-address.mycluster.nn1/name valuenode01:9870/value /property property namedfs.namenode.http-address.mycluster.nn2/name valuenode02:9870/value /property接下来配置两个NameNode的元数据目录。注意两个节点的本地存储目录应该各自独立不要指向同一个共享路径property namedfs.namenode.name.dir/name value/data/hdfs/namenode/value /property property namedfs.datanode.data.dir/name value/data/hdfs/datanode/value /property然后是核心中的核心——共享编辑日志的JournalNode地址property namedfs.namenode.shared.edits.dir/name valueqjournal://node01:8485;node02:8485;node03:8485/mycluster/value /property这里写的qjournal://协议指向3个JournalNode后面的mycluster是服务名必须与dfs.nameservices保持一致。写错这个JournalNode会出现各种诡异日志。接下去是故障转移相关配置。首先启用自动故障转移以及配置ZKFCproperty namedfs.ha.automatic-failover.enabled/name valuetrue/value /property property namedfs.client.failover.proxy.provider.mycluster/name valueorg.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider/value /property如果不配置最后这个代理类客户端就只知道写hdfs://mycluster这个逻辑名但不知道如何做到故障转移。这个类的作用是让客户端在Active NameNode挂掉时自动切换到新Active。JournalNode自己的数据目录也需要配置property namedfs.journalnode.edits.dir/name value/data/hdfs/jn/value /property最后是隔离方法配置。为了让新Active能强制终止旧Active可以配置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 /propertysshfence需要配置免密钥登录从node01和node02两个NameNode上都要能免密SSH到对方。如果觉得SSH方式不够稳可以再加一个shell方式把旧节点的进程直接kill掉。我这里实际用的是sshfence加shell(/path/to/kill_nn.sh)两重保险。3.3 格式化与启动的正确姿势配置写完后千万别急着执行hdfs namenode -format顺序错了会踩不少坑。第一次启动HA集群的正确流程可以总结为先在所有JournalNode上启动JournalNode进程hdfs --daemon start journalnode然后在第一台NameNodenode01上格式化hdfs namenode -format格式化完成后再把这台的元数据同步到第二台NameNodenode02可以执行hdfs namenode -bootstrapStandby这个命令会自动从Active NameNode复制最新的元数据包括FsImage和EditLog到本机二台就不需要再手动格式化。接着先在node01上启动ZooKeeper并初始化HA状态zkServer.sh start hdfs zkfc -formatZKhdfs zkfc -formatZK的作用是在ZooKeeper里创建HA相关的节点并清除旧的选举状态。只在第一次建集群时需要执行之后不能乱跑否则会清掉选举元数据。再依次启动node01的NameNode和ZKFChdfs --daemon start namenode hdfs --daemon start zkfcnode01上的NameNode启动后因为ZKFC已经注册到ZooKeeper它会自动通过抢注把状态置为Active。接着启动node02的NameNode和ZKFChdfs --daemon start namenode hdfs --daemon start zkfcnode02会识别出当前已有Active自动进入Standby状态。最后启动DataNodehdfs --daemon start datanode启动全部完成后用命令验证状态hdfs haadmin -getAllServiceState正常输出应该是node01是activenode02是standby。可以再用浏览器分别访问http://node01:9870和http://node02:9870能看到UI界面正常且Standby那台会显示当前处于Standby模式不接受写操作。3.4 验证高可用手动切换演练集群搭好只是一个开始必须实际演练一次故障转移。最简单的方式是直接停掉Active NameNode所在的进程。比如当前Active在node01执行hdfs --daemon stop namenode同时观察node02上的NameNode日志会发现ZKFC检测到对方挂了然后把自己切换成Active。整个切换过程通常在10到30秒内完成。再执行hdfs haadmin -getAllServiceState确认node02已经变成active。如果只想测试切换而不想停进程可以执行手动切换命令hdfs haadmin -transitionToActive nn2不过手动切换会自动把node01降级为Standby过程中集群会短暂进入无Active状态。生产环境里进行这种操作前最好确认当前没有正在写入的关键业务或者选在一个业务低峰窗口做演练。我见过不少团队集群搭完就扔一边完全不做故障演练。结果真出问题时第一反应是手忙脚乱去看文档本来几秒钟能完成的切换硬生生拖了几十分钟。所以这里特别强调HA不只是配置出来的更是练出来的。4. 自动故障转移的工作机制与日常运维手记4.1 一次完整的自动Failover是怎么发生的很多人以为自动故障转移就是“检测到挂了换一个”但实际流程是分步骤、有先后顺序的任何一个环节没配置好都会失败。这里拆细了讲方便排查时对照。第一步是异常检测。Active NameNode上的ZKFC会持续检查本机NameNode的健康状态同时维持与ZooKeeper的心跳。NameNode本身异常退出或进入假死状态ZKFC都会察觉到。第二步是临时节点消失。ZKFC在ZooKeeper上创建的Active临时节点因为会话超时被自动删除。Standby那边的ZKFC一直在监听这个节点收到删除通知后就知道主节点已不可用开始发起选主。第三步是抢占。Standby的ZKFC尝试在ZooKeeper上创建新的临时节点。这里有个细节如果两个Standby同时抢谁先创建成功谁就是新的Active。不过常规HA就两个NameNode通常只有一个Standby。第四步是Fencing旧主。新Active会执行配置里的隔离方法。如果旧的NameNode没有完全死掉还留在原来的机器上继续写EditLog就会造成元数据混乱。所以必须确保旧的已经退出。这是选主成功里最容易被忽略但至关重要的一步。第五步是推进日志。新Active会从JournalNode读取最新的EditLog并清掉Standby期间积压的日志然后开始接受客户端请求。客户端那边因为配置了FailoverProxyProvider对于正在进行的操作会自动重试因此大多数情况下业务侧看到的就是短暂地“卡一下”然后恢复正常。4.2 日常巡检与监控指标HA并不是配置完就能睡大觉。日常巡检我会重点关注以下几项两个NameNode的HA状态是否始终是一个Active一个Standby。JournalNode的磁盘使用量EditLog增长是否正常磁盘是否健康。NameNode的RPC延迟和GC情况NameNode假死往往和FullGC脱不了干系。Active NameNode的堆内存使用堆内存满了会频繁GC影响整体性能。ZooKeeper的会话超时、节点延迟情况ZooKeeper整体不健康HA就是纸糊的。用监控系统时可以采集以下指标做成Dashboard指标来源说明NameNode状态JMX或hdfs haadmin1表示Active0表示StandbyEdits日志目录大小文件系统监控增长异常可能是日志堆积JournalNode同步延迟JournalNode JMXRPC处理耗时ZooKeeper连接数ZooKeeper监控连接数异常增多需排查Active NameNode的GC时间JVM监控GC Pause时间过长需要扩容堆内存还有一点Standby NameNode也需要和Active一样的内存规格和CPU资源。很多团队给Standby配置很低觉得“反正它又不干活”。可一旦切换新Active要承担全部客户端请求配置不够就会在故障后造成第二波麻烦。我在实际管理中就见过因为Standby内存只给Active一半切换后频繁OOM、反复重启的小型集群。HA的意义是冗余资源换高可用既然配了就让它具备随时接班的能力。4.3 踩过的坑元数据不一致、脑裂与日志拖垮下面记录几个我实际踩过的坑类别不同、表现形式也不同但都会把集群推向深渊。第一个是元数据不一致。它有一个很典型的出错场景手动执行了hdfs haadmin -transitionToActive nn2但nn1其实还活着并且还在写日志。如果隔离方法没有真正生效nn2虽然通过抢注节点成了Active但nn1因为网络等原因没有收到降级指令继续向JournalNode写EditLog。两边各写各的元数据就分叉了。这种问题的坑在于平时看不出来只有切换到坏的那台时才发现文件列表缺了一大块某些目录损坏。第二个是脑裂。形式比较极端就是两个NameNode同时把自己当成Active。这种一般发生在配置不当或Fencing失败时。脑裂的危害是整个HDFS元数据不可信修复极其复杂基本只能回滚到最近的一致快照。对付脑裂最好的方式是“防患于未然”隔离方法必须配置并且要验证有效不能只写个sshfence就当完事了另外要定期查看NameNode日志中的状态切换记录确认它们一直在正常交替而不是偷偷“打架”。第三个是JournalNode日志拖垮磁盘。EditLog是按天滚动的如果集群写操作频繁日志增速相当快。JournalNode的本地目录如果不定期清理磁盘会被写满JournalNode一旦挂了所有NameNode都无法提交日志更新。这里建议把日志保留时间调短并配置监控告警。大集群还会定时做Checkpoint把NameNode的FsImage合并更新减少回放日志的量。Standby NameNode天然会定期做Checkpoint原因就是它在追日志的同时也在合并元数据快照这一点很多初学者容易忽略以为是Active在做实际上是Standby在默默做事。5. 一网打尽常见问题与排查技巧实录5.1 高频问题速查表搭建和运维HA集群就会遇到一些高频问题我整理了一张对照速查表给出的建议都是基于个人实践按“现象——可能原因——排查顺序”来列。现象可能原因排查方法两个NameNode都不是Active启动顺序不对或ZKFC没起来先看ZKFC日志再确认ZooKeeper连接Active状态总是自动切换网络抖动、GC暂停、JournalNode超时检查网络和GC日志Active每重启一次都会引发切换客户端报StandbyException请求打到了Standby且代理类没配置对检查dfs.client.failover.proxy.provider配置bootstrapStandby失败两台NameNode元数据差异太大或目录权限不对先确认Active能正常提供服务再确认同步目录权限JournalNode无法启动数据目录不存在或权限不对检查dfs.journalnode.edits.dir指定的目录格式化NameNode重复执行误操作先确认集群是否已有数据不能随意重跑格式化切换耗时过长ZooKeeper会话超时设置太长检查ZooKeeper的sessionTimeout配置适当调短5.2 独家排查思路看日志的顺序与关键项很多人遇到问题就抓瞎到处翻日志。我分享一下自己的日志排查顺序按这个顺序来通常能快速定位问题。第一步先看ZKFC日志。它是最初的“哨兵”主节点有没有问题、切换有没有发生、选举成功还是失败都会记录在hadoop-hdfs-zkfc-*.log里。在这能看到故障是否被正确感知。第二步看ZooKeeper日志和临时节点状态。用ZooKeeper客户端连上集群查看HA节点路径默认在/hadoop-ha/mycluster下能看到当前谁是Active临时节点持有者。如果这里和预期不一致说明选举环节出了问题。第三步看NameNode自己的日志。Active和Standby的日志路径分别在两个节点各自的logs/目录下。重点查关键词Failover、Fencing、transitionToActive、transitionToStandby围绕这些关键词能快速还原故障转移的发生过程。排查过程中的“看日志顺序”其实比日志本身更重要。很多初级运维喜欢一上来就翻NameNode主日志但主日志里的报错信息往往只是结果不是原因。顺着“哨兵ZKFC——协调者ZooKeeper——当事者NameNode”这条链路去查绝大多数问题都能找到根源。5.3 基于个人经验的实施建议最后分享几条我反复跟团队强调的实施经验也算是对整套内容的一个实操收尾。搭建HA的第一时间就把自动故障转移打开。有些团队为了“怕误切换”而关掉自动故障转移只用手动切换。这样相当于把高可用变成了“半自动”稳定性会大打折扣。打开自动切换虽然偶尔会有误判但整体收益远大于风险。别在集群上“裸奔”跑format命令。尤其集群里已有数据时任何格式化都要先做元数据快照备份。HA本身不是备份它防的是进程宕机不是防人肉误操作。新集群第一次做故障切换演练时尽量在业务低峰期并且提前准备好恢复预案。我见过同事在演练时把Active和Standby同时停掉了结果整个集群进入无主状态客户端堆积大量请求恢复期间压力很大。预案里至少要写明如何确认Fencing成功、如何手动指定Active、如何回滚到之前的元数据备份。还有一点大家很容易忽略客户端侧也要配HA。光在服务端搞HA客户端如果用老方式直连某个NameNode地址那切换对它来说还是不可用的。客户端配置里需要设置fs.defaultFS为hdfs://mycluster并配置同样的nameservices和failover proxy provider。生产环境里集群里的计算框架、数据分析组件全部要跟着改成这种访问方式。整套内容写到这里我已经把自己平时搭HA、运维HA时涉及的思路、配置、步骤和教训都整理了一遍。HDFS的HA并不是那种“照着官网敲几行配置就能跑稳”的东西更关键的是理解它为什么这么设计以及在你自己的环境里怎么验证它确实生效。搭建只是一小步日常的巡检、演练、日志排查才是保证集群真正高可用的关键。如果你正准备把手里的单点集群改成HA架构照着这篇文章的流程走一遍遇到问题再回头看第5节应该能少走不少弯路。