前阵子在一个项目里搭了一套Hadoop HA高可用集群从角色规划、ZooKeeper部署、HDFS配置一路调下来中间踩了不少坑也总结出一些判断问题的思路。这篇记录就把整个搭建过程和关键细节完整捋一遍给同样要上Hadoop HA的朋友做个参考。这篇东西适合两类人看一类是刚接触Hadoop、想搞明白HA到底在解决什么问题的初学者另一类是要真正在生产环境落地的工程师。我会尽量把每个配置参数背后的原因也讲清楚这样你看到的不只是一堆配置命令而是知道为什么要这么配、出问题该往哪个方向查。1. 先弄明白HA到底在解决什么问题1.1 单点不是小事NameNode挂了会发生什么在讲HA之前得先把基础痛点聊透。HDFS的NameNode负责维护整个文件系统的元数据包括目录树、文件块位置、租约等等。客户端读写文件之前首先要把这些元数据拿到手DataNode上报心跳和块报告也都要先经过NameNode。换句话说NameNode就是整个HDFS的“总闸门”。没有HA的年代NameNode挂了整个HDFS就停摆了。而且最难受的还不是“读写停止”而是元数据恢复的难度。NameNode把元数据持久化到本地磁盘的fsimage和edits文件里如果节点物理损坏或者磁盘故障这些文件没了那整个命名空间就丢了。这意味着所有文件在HDFS里还存在但已经不知道它们存哪里了基本等同数据报废。后来有人想到“冷备”方案定期把NameNode的元数据拷贝到另一台机器上。听起来简单实际很难做。NameNode的元数据是持续变化的每一次建目录、删文件、写块都要写edits日志冷备只能按周期同步周期内的元数据变化很大概率丢失。而且冷备的切换还靠手工操作恢复时间完全不可控。Hadoop HA解决的就是这个核心问题让两个NameNode机器热备运行一台Active负责提供读写服务另一台Standby保持元数据实时同步。Active出问题时Standby能自动接管把服务中断时间压缩到几十秒甚至几秒内。1.2 三个组件各司其职JournalNode、ZKFC、FencingHA能跑起来依赖的不是一个技术而是一个组合机制。我习惯把HA拆成三块来理解状态同步、故障探测与选举、原Active的隔离。状态同步这一块靠的是JournalNode。JournalNode有点像几个人合用的“工作日志本”Active NameNode每做一次命名空间变更都要往这本日志本上写一条Standby NameNode则实时盯着这本日志本读到新记录后立刻在自己的内存里重放让自己的元数据状态尽量贴着Active走。JournalNode本身是一个独立进程生产环境一般部署奇数台因为状态同步只要多数派写成功就算数这是一个典型的Quorum机制。故障探测与选举这一块靠的是ZKFCZooKeeper Failover Controller。ZKFC是跑在NameNode机器上的一个小进程它的工作逻辑很清晰在ZooKeeper上创建一个临时节点Active NameNode的ZKFC持有这个节点Standby NameNode的ZKFC则在旁边监听。一旦Active的ZKFC和ZooKeeper之间的会话超时临时节点自动消失Standby的ZKFC立刻竞争创建这个节点谁抢到了谁就升级成Active。Fencing隔离这一块很多人容易忽略但其实是最要命的一环。想象一个场景Active NameNode没死只是和ZooKeeper之间的网络断了ZKFC判定它“失联”然后让Standby升为主。这时候如果两个NameNode同时对外服务就会出现“双脑”状态也就是常说的脑裂两个节点同时写edits日志元数据很快分叉整个文件系统一致性直接毁掉。Fencing要做的事情就是在Standby接管之前用手段把旧Active“按住”保证它不能再写。这三块缺一不可。只做状态同步没有自动选举退化成了手工冷备只做选举不做fencing危险系数比单NameNode还高。1.3 脑裂到底有多可怕说到脑裂多说几句。之前我有一个同事对fencing理解不深觉得“反正两个名字节点谁状态好谁上不就行了”结果在测试环境模拟网络抖动时两个NameNode都尝试写JournalNodeedits日志的epoch直接错乱后面查日志的时候发现txid都对不上整个命名空间已经没法继续重放了。后来我们把fencing配置补上再模拟网络分区系统会先等旧Active被隔离成功Standby才敢真正接管。这个顺序很重要不是“先切换再隔离”而是“先隔离再切换”。所以生产环境里fencing策略的可靠性直接影响切换的时间和安全。现在好一点的HA实践其实还会在Fencing之外再加一层保障JournalNode每条edits记录都带着epoch号旧的Active即使没被杀干净它写记录时用的epoch已经过期会被JournalNode拒掉。这算是有个双保险但fencing仍然是首道防线。2. 动手前的环境规划与版本选型2.1 节点角色怎么分布最少几台机器不少新手一上来就问“HA是不是两台机器就够了”答案是两台的HA属于勉强跑demo生产环境别这么干。原因很直接JournalNode至少要3台才能构成多数派如果只有2台一台JournalNode挂掉后剩下1台即使能把edits写进去也无法满足“多数派”的判定集群会失去写入能力。所以在常见规模下我比较推荐两种方案。第一种是3台机器一台做主NameNodeActive一台做备NameNodeStandby第三台和另外两台上各放一个JournalNode进程同时DataNode也分布在这3台上。这套方案能跑通HA但主备角色和JournalNode挤在一起NameNode重启或维护时JournalNode也会跟着动风险偏高适合测试环境。第二种是5台机器比较适合生产。前两台上只跑NameNode和ZKFC不跑DataNode把元数据服务和数据存储分离另外3台上各跑一个JournalNode和DataNode。这样JournalNode天然就是3个节点奇数台写Quorum正好满足多数派NameNode机器也相对干净GC和IO都不会被DataNode干扰。还有一个容易被忽略的规划如果公司只有4台物理机可以考虑把ZooKeeper也拆成3个进程分布在不同机器上不要为了省机器把所有进程堆在一起。ZooKeeper和JournalNode都属于“低占用但高可用”的组件物理机上多跑一个进程不会带来明显负载但能显著提升容错范围。2.2 版本选择稳定优先还是新功能优先Hadoop版本这一块我见过太多“非要上最新版”的案例结果官方文档和第三方博客对不上折腾一周都在跟版本差异较劲。我的建议很简单在满足业务最新特性需求的前提下尽量选已经发布较久、社区反馈集中的稳定版本。大版本选好之后还需要考虑一个细节配套的ZooKeeper版本。Hadoop自带的一些依赖和ZooKeeper版本强相关ZooKeeper太新或太旧都会出现兼容问题。比如有些Hadoop版本配ZooKeeper 3.5.x没问题但换到3.7.x就出现会话重复加载。我的习惯是去官方发布说明里查对应兼容版本然后用包里自带的或推荐版本别自己拍脑袋升级。JDK版本同样很重要。Hadoop对JDK版本非常敏感高版本JDK会出现一些奇怪的JNI调用问题常见的是Native库加载失败但有些场景是Spark和HDFS混合部署时GC参数配置失效。我建议优先选发行方认证过的JDK版本设置JAVA_HOME时也顺手确认一下lib/native目录里的native库能正常加载。如果只是为了学习或小型内部系统用Apache社区版就行配置简单、资料多。如果业务规模大或者对技术支持有硬性要求商业发行版会更省心但有些商业版会改掉默认端口和目录结构后面的配置需要额外注意。2.3 系统网络准备及端口清单在配置HA之前系统层面的准备直接决定后面能不能顺利启动。我一般按下面这个顺序做。第一是hosts文件。集群里所有节点的IP和主机名都要写在每台机器的/etc/hosts里并且保持一致。不要在生产环境依赖DNS解析DNS偶尔抽风的那几分钟正是HA最怕的隐患。团队里如果小机器多建议把hosts文件做成模板统一推送别一台一台手改。第二是SSH免密。虽然HA的核心机制不是靠SSH做状态同步但配置fencing的sshfence策略时必须依赖SSH从一台机器登录另一台机器执行命令而且日常手动切换时也要靠SSH操作。我通常把每台机器相互之间都配了免密登录避免两边来回操作时反复输密码。第三是时间同步。NameNode和JournalNode之间的edits写入对时间顺序很敏感ZooKeeper的事务语义对节点间时钟偏差也很敏感。时间不同步会导致会话超时判断混乱出现误切换。最简单的做法是每台机器都装chrony或者ntp指向同一个时间源启动后确认每台机器时间差在几百毫秒以内就行。第四是防火墙和端口。Hadoop集群内部组件之间通信的端口不少生产环境一般都开了防火墙这里就要对照端口清单逐项放行。常见的端口如下建议存成一份清单。组件默认端口用途ZooKeeper2181客户端访问ZooKeeper2888/3888选举和节点间通信JournalNode8485RPC端口NameNode写入/读取editsNameNode8020RPC端口接受客户端请求NameNode9870Web UI查看集群状态ZKFC8019ZKFC内部通信DataNode9864DataNode HTTP服务DataNode9866DataNode IPC通信最后是磁盘规划。NameNode的元数据目录dfs.namenode.name.dir和JournalNode的edits目录dfs.journalnode.edits.dir尽量放在单独的、SSD性能好一点的磁盘上不要让它们和数据目录共享一块盘。元数据写磁盘的延迟直接影响NameNode的写请求性能共享盘在高负载下抖动会很厉害。3. ZooKeeper集群部署要点3.1 为什么ZooKeeper必须要奇数台HA里的自动故障切换依赖ZooKeeper的分布式协调能力而ZooKeeper本身又是一个集群。它用的也是Quorum机制集群中的多数派节点存活时整个ZooKeeper才能对外服务。所以3台ZooKeeper可以容忍1台挂掉5台可以容忍2台挂掉。这里要注意部署ZooKeeper时大家选的节点数量其实和“奇数台”这个原则有关系。2台ZooKeeper在功能上是能启动的但一旦其中一台挂掉剩余的1台不构成多数派整个集群就不可用。4台看起来比3台多了一台的冗余但实际容错数和3台一样都是只能挂1台挂2台时整个集群就废了。所以多花的这一台机器没有带来任何可用性收益奇数台成了一种事实标准。在实际规划里3台ZooKeeper是绝大多数中小型集群的配置。ZooKeeper本身很轻量内存占用主要Follower节点维护事务日志和快照给它1GB到2GB堆内存基本够用。如果你觉得5台更保险也可以但维护成本会上去。3.2 ZooKeeper安装与配置文件准备ZooKeeper安装包解压后核心配置就在conf/zoo.cfg。先讲一下每个参数的用途这样你看到那些数字不会懵。tickTime2000 initLimit10 syncLimit5 dataDir/data/zookeeper clientPort2181 server.1node1:2888:3888 server.2node2:2888:3888 server.3node3:2888:3888tickTime是ZooKeeper的最小时间单元单位毫秒2000表示2秒。initLimit配置的是Follower启动时能容忍的最大初始化连接时间这里是10个tick也就是20秒。如果集群规模大、节点多这个值可以适当调大比如改成20。syncLimit配置的是Follower与Leader之间通信的超时时间5个tick也就是10秒如果网络抖动频繁可以适当放大一点但别调得太大否则故障检测也会变迟钝。dataDir是事务日志和数据快照的存储目录最好放在磁盘IO性能好的地方。每个ZooKeeper节点还要在dataDir目录下创建一个myid文件内容就是它的序号。比如node1的myid内容是1node2的内容是2要和zoo.cfg里server.x的数字对应上。这个文件很简单但漏掉它或者写错数字启动后ZooKeeper怎么都组不成集群。还有一个容易踩坑的地方ZooKeeper进程默认继承系统的JVM内存设置很多教程没提这茬结果ZooKeeper吃掉了所有机器内存。建议单独设置ZooKeeper的堆内存比如在conf/zoo.cfg同目录的java.env或者启动脚本里设置JVMFLAGS限制到1GB左右。3.3 启动与验证三台机器上分别执行zkServer.sh start然后检查每个节点的状态。zkServer.sh status正常情况下会显示一台是leader其余是follower。如果有节点一直显示standalone或者报connection refused多半是myid、server.x配置或者防火墙端口的问题。也可以看ZooKeeper自己的日志日志里会明确写“QuorumPeerMain”等启动过程信息。如果日志出现“Unexpected exception causing shutdown”先把配置文件从头对一遍多半是格式问题。ZooKeeper对配置文件格式还是比较严格的某个server行少个空格都能启动失败。4. Hadoop核心配置逐项详解4.1 core-site.xml全局基础配置HA配置的核心文件主要就是两个core-site.xml和hdfs-site.xml。core-site.xml里最关键的两个配置是默认文件系统和ZooKeeper的地址。configuration property namefs.defaultFS/name valuehdfs://mycluster/value /property property nameha.zookeeper.quorum/name valuenode1:2181,node2:2181,node3:2181/value /property /configurationfs.defaultFS的值是一个逻辑服务ID我这里的mycluster就是后面在hdfs-site.xml里定义的nameservice名字。客户端访问HDFS时会用这个逻辑名字去解析真正的NameNode地址而不是直接连某一台物理机。ha.zookeeper.quorum就是ZooKeeper集群的地址列表这个配置主要是给ZKFC用的故障选举时它要连到ZooKeeper去注册和探测。注意这里的地址要写完整包括端口。4.2 hdfs-site.xmlHA核心参数hdfs-site.xml是HA里配置量最大、最容易出错的地方。我把宽度分几个模块过一遍。先定义nameservice和它包含的NameNodeproperty namedfs.nameservices/name valuemycluster/value /property property namedfs.ha.namenodes.mycluster/name valuenn1,nn2/value /propertydfs.nameservices定义了整个HDFS服务集群的逻辑名称。dfs.ha.namenodes.mycluster定义了这个逻辑集群下有哪些NameNode的逻辑名称我这里是nn1和nn2。这是给客户端做地址解析用的基础信息。接着给每个NameNode配置RPC地址和HTTP地址这些地址要能通过SSH访问到对应机器。注意每个NameNode的逻辑ID要清楚否则后面节点启动时会找不到对应的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 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的配置格式是一个固定模板property namedfs.namenode.shared.edits.dir/name valueqjournal://node1:8485;node2:8485;node3:8485/mycluster/value /property这里的意思是通过三个JournalNode的8485端口组成一个quorum逻辑路径名是mycluster。JournalNode实际写盘的目录在下面这个配置里指定property namedfs.journalnode.edits.dir/name value/data/hadoop/journal/value /property接下来是自动故障转移和代理Providerproperty namedfs.client.failover.proxy.provider.mycluster/name valueorg.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider/value /property property namedfs.ha.automatic-failover.enabled/name valuetrue/value /propertyproxy provider这一项决定了客户端如何感知NameNode的状态变化。ConfiguredFailoverProxyProvider会读取core-site.xml和hdfs-site.xml里配置好的NameNode列表在请求遇到故障时自动切换到另一个NameNode。automatic-failover.enabled设为true表示启用ZKFC自动切换。然后是Fencing相关的配置property namedfs.ha.fencing.methods/name valuesshfence/value /property property namedfs.ha.fencing.ssh.connect-timeout/name value30000/value /property property namedfs.ha.fencing.ssh.private-key-files/name value/home/hadoop/.ssh/id_rsa/value /property这里用的是sshfence策略。Hadoop会通过SSH登录到旧Active机器执行fuser命令去er明占用NameNode端口的进程从而达到“杀死旧Active”的目的。connect-timeout是SSH连接超时时间默认比较短网络慢的话容易fencing失败可以适当调到30秒。private-key-files是SSH免密的私钥文件必须是运行Hadoop的那个用户能访问的并且权限不能太开放否则SSH客户端会拒绝加载。4.3 关于Fencing策略的选型Fencing策略这块生产环境里很多人会纠结sshfence和shell(true)该选哪个。sshfence是Hadoop自带的SSH隔离方式它需要能通过SSH登录到旧Active然后执行命令kill进程。优点是实现简单、不依赖额外工具缺点是如果旧Active所在机器网络分区而且SSH也不通那fencing就会失败。shell(true)策略实际上就是“默认认为旧Active已经被隔离”直接返回成功。这个策略非常危险等于放弃了物理隔离一旦出现脑裂两个NameNode同时写edits后果不堪设想。我见过的唯一合理用法是和外部物理隔离工具配合比如通过shell脚本调用带外管理接口或断电工具但这已经是定制级别了一般团队不会自己写。所以我的建议是默认用sshfence并且在配置fencing之前先在两台NameNode之间做一轮SSH免密测试确保能免密登录、能执行fuser命令。fencing失败的表现通常是自动切换卡在Fencing这一步NameNode迟迟没有变成Active日志里有大量“Fencing failed”或者超时记录。4.4 其他值得调的参数除了HA核心参数有几个日常运维里经常踩坑的参数我顺手说一下。dfs.namenode.name.dir是NameNode元数据目录建议配两个以上路径可以分布在不同的磁盘或者挂载点上元数据的多副本能抵挡单盘故障。dfs.replication控制在HDFS上的副本数。测试环境可以设1到2生产环境建议3。如果副本数设置太低数据块在某台DataNode下线后会因为副本不足而迟迟无法恢复。dfs.namenode.handler.count是NameNode处理RPC请求的线程数。如果NameNode机器核心数多、业务并发大默认值可能偏小。出现RPC超时或者线程池排队严重时可以考虑调大这个值但要结合实际CPU和内存盲调大了反而增加上下文切换开销。dfs.image.compress以及事务相关参数我就不具体展开了这些属于优化项不影响HA主流程跑通。5. 集群初始化和启动全流程5.1 启动顺序先ZooKeeper再JournalNode再NameNodeHA集群的启动顺序比较固定我每次搭建都按这个节奏来。顺序错了轻则报错重则元数据目录状态混乱后面要花不少时间收拾。第一步启动ZooKeeper集群。逐台执行zkServer.sh start并确认状态正常。第二步在每台部署了JournalNode的机器上启动JournalNode进程hdfs --daemon start journalnode这一步很多人会忘。JournalNode里会存储共享edits日志目录如果JournalNode没启动后面格式化NameNode时可能不会报错但真正启动时NameNode会连不上JournalNode卡在启动阶段。第三步格式化ZooKeeper上的HA状态。在其中一台NameNode机器上执行hdfs zkfc -formatZK这个命令会在ZooKeeper上创建HA相关节点清空旧的故障转移状态。需要注意的是这一步只在第一次部署HA或者需要重置HA状态时执行不要没事就重复跑。跑多了可能把正在工作的自动切换状态破坏掉。第四步格式化主NameNode并启动它。在nn1机器上执行hdfs namenode -format hdfs --daemon start namenode格式化只在这台机器上做选哪台当初始Active不代表以后它永远当Active只是第一次要有个起点。格式化会在本地元数据目录生成fsimage和VERSION文件这个过程中包含集群唯一的clusterID后面Standby节点同步时必须保持这个clusterID一致否则集群会认为它们在两个完全不同的命名空间里。第五步在Standby NameNode机器上执行元数据同步然后启动它hdfs namenode -bootstrapStandby hdfs --daemon start namenodebootstrapStandby做的事情是从已格式化的NameNode或JournalNode上拉取当前元数据并构建Standby的本地状态。一定要用bootstrapStandby而不是再执行一次namenode -format。格式化会生成全新的clusterID两个NameNode的clusterID不一致整个HA直接起不来。第六步启动DataNode。可以逐台执行也可以用start-dfs.sh统一启动。DataNode启动时会向NameNode注册两个NameNode都能感知到DataNode的存在但只有Active的NameNode会管理它们的块汇报。5.2 第一次格式化的易错点格式化这个环节我说一个典型事故。有一次精简测试环境我临时决定“重新初始化整个集群”顺手在两台机器上都执行了namenode -format。结果悲剧了两台NameNode的clusterID完全不同启动后JournalNode里写入的edits根本没法同步因为Standby在读共享edits时发现clusterID不匹配直接拒绝。正确的重置方式是只在一台NameNode上format另一台永远用bootstrapStandby去同步。如果真出现clusterID不一致的情况可以手动修改两台机器上VERSION文件里的clusterID和storageID改完再重启但这个方法比较粗暴最好还是备份好数据后彻底重来。还有一个细节先启动JournalNode再格式化NameNode以后再启动集群仍然要保证JournalNode先于NameNode启动。否则NameNode启动时会尝试连接JournalNode拿最新edits连不上就一直卡在“等待JournalNode”的状态日志里全是连接超时。5.3 启动后的验证jps、Web UI和状态命令启动流程走完后先看进程。jps输出里应该能看到NameNode、DataNode、ZKFC这几种进程不同角色机器上进程组合不一样。然后浏览器打开Active NameNode的Web UI。UI上有两个关键信息一个是HA状态显示为active还是standby另一个是Active NameNode的“Cluster ID”和“Block Pool ID”。如果看到两个NameNode都是active那说明fencing没生效赶紧停一个如果两个都是standby说明ZKFC没有成功让其中一个抢到Active需要去查ZooKeeper会话和ZKFC日志。命令行验证更直接hdfs haadmin -getAllServiceState正常输出是node1:8020 active node2:8020 standby这个命令同时验证了ZKFC是否正常工作。如果一直显示两个standby大概率是ZKFC没启动或者没能和ZooKeeper建立会话。6. 手动切换与故障演练实操6.1 手动故障转移命令自动切换是HA的核心能力但日常运维中手动切换才是更常用的操作。比如计划内升级、给NameNode机器更换硬件时都需要主动把Active切换到另一台机器上而不是等它故障。手动切换的命令是hdfs haadmin -failover nn1 nn2这个命令的含义是把Active角色从nn1切换到nn2。Hadoop会先触发nn1的fencing确认nn1已经失效后再把nn2拉起为Active。所以手动failover其实和自动failover走的流程是一样的好处是你可以主动控制切换时机。如果只是想查询状态用hdfs haadmin -getServiceState nn1执行failover时有个特别需要注意的地方如果当前Active的节点还在正常运行但你手动failover时正好赶上它所在机器网络抖动fencing阶段可能会超时或者失败这时命令会报错集群保持原来状态。所以手动切换也要给SSH和fencing留足时间窗口别真的在业务高峰做。6.2 模拟故障kill掉Active NameNode自动切换是否真的能用不能光靠配置来保证一定要做一次故障演练。我建议在测试环境搭好之后先把进程跑稳然后模拟一次Active NameNode宕机。模拟方式很简单在当前的Active NameNode机器上执行kill -9 NameNode进程PID注意这是故意制造一个“没有正常退出通知”的强杀场景最能检验ZKFC和fencing的真实状态。kill之后观察Standby节点的日志和状态正常情况下几十秒内Standby就会变成Active客户端在短暂报错后能重新连接。我演练过的场景里自动切换时间一般在20到50秒之间具体取决于ZooKeeper会话超时时间、fencing耗时和Standby的元数据加载速度。如果超过1分钟还没有切过去就要去查ZooKeeper和ZKFC的状态了。演练结束恢复原状时再手动failover切回去然后确认两个NameNode都能正常服务。6.3 自动切换没生效时的排查思路如果自动切换迟迟不生效我的排查顺序一般是这样的。第一步看ZKFC进程还在不在。如果ZKFC进程死了自动切换能力等于零手动切也不行。第二步看ZKFC日志。日志里通常会写清楚是ZooKeeper会话超时、fencing失败还是候选节点没有获得足够票数。第三步看ZooKeeper状态。在ZooKeeper上执行zkCli.sh检查HA相关的节点是否存在、临时节点是否由正确的ZKFC持有。如果Active已经失联但临时节点还没消失说明会话超时时间还没到如果临时节点已经消失但Standby没有接管问题多半在Standby的ZKFC上。第四步确认fencing。如果日志里反复出现“Unable to fence”字样说明旧Active没被杀掉或者SSH不通Standby不敢接管。这时候重点检查SSH免密和sshfence的配置。7. 常见问题排查速查表与运维心得7.1 高频问题与排查手段把搭建运维过程中最容易碰到的高频问题整理成一张速查表方便大家对照排查。现象可能原因排查方向两个NameNode都是standbyZKFC未启动或ZooKeeper连接异常检查ZKFC进程和日志检查ha.zookeeper.quorum配置两个NameNode都是activefence失效脑裂检查fencing配置立即停掉一台NameNode进程防止继续写edits自动切换不触发会话超时时间过长、fencing失败、ZKFC异常查ZKFC日志、ZooKeeper状态调整会话超时或fencing策略NameNode启动后一直卡在等待JournalNodeJournalNode没启动或端口不通确认JournalNode进程和8485端口防火墙放行bootstrapStandby报错clusterID不一致误格式化导致多套clusterID手动对齐VERSION文件或重新初始化慢切换且日志大量重试fsimage和edits加载慢或handler线程不够增大堆内存和handler.count检查磁盘IODataNode一直连不上NameNodeRPC地址配置错误或防火墙核对dfs.namenode.rpc-address测试8020端口连通性集群中某个JournalNode写失败磁盘满、权限不对、单台JournalNode宕机检查磁盘空间与目录权限重启JournalNode7.2 配置起来容易踩的坑配置层面有几个容易被忽略的地方再提醒一次。一是权限问题。NameNode元数据目录和JournalNode的edits目录如果权限不是运行Hadoop的用户所有启动时会直接报Permission denied而且报错信息藏得比较深容易被误判成端口问题。所以我一般都会先chown -R把目录归属设置好。二是端口冲突。如果之前装过单NameNode模式的HDFS很可能有进程占用了8020或者9870端口。启动前用ss -lntp检查一下端口避免两个进程互踩。三是配置同步。核心配置文件一定要在所有相关节点上保持完全一致。不要只在主NameNode机器上改了hdfs-site.xml其他节点忘了同步结果启动时各种行为不一致。我记得有一次客户端写文件老是失败排查半天发现是其中一台DataNode上没有同步更新配置导致客户端与DataNode之间版本不一致。解决方案很简单改配置后检查不同节点配置文件md5值。四是启动顺序。以后每次重启集群都要先启动ZooKeeper和JournalNode再启动NameNode。顺序错乱虽然不一定会报错但会拖慢NameNode的启动过程因为在等待接入JournalNode时它会反复重试。7.3 运维阶段的几个经验HA跑起来之后日常运维要比单机集群多几件固定动作。定期做一次故障演练。我一般每个月或者每两个月在测试环境做一次kill Active的演练看自动切换是否正常。这个习惯很值因为很多时候配置没变、版本没变但某台机器磁盘快满或者ZooKeeper节点状态异常切换便会出问题演练能提前暴露这些隐患。监控NameNode的GC、ZooKeeper的会话数和JournalNode的edits写入延迟。这三个指标能早期预警HA的健康度。NameNode GC停顿时间过长会导致心跳超时被ZKFC判定失联后触发不必要的自动切换。版本升级前老老实实看升级文档。HA涉及的组件多升级顺序和兼容性比较敏感。尤其当你准备小版本升级Hadoop或ZooKeeper时先看官方升级说明确认旧版本edits和ZooKeeper元数据能被新版本识别再安排夜间操作窗口。还有一个小经验手动切换之前先确认目标Standby的元数据真的跟得上。可以通过Web UI看Standby的“Last Checkpoint”或者“Transactions Applied”如果明显落后于Active宁可等等再切也不要强行切换造成大量事务回放那样NameNode起来后还要做长回放业务反而停得更久。8. 最后再分享两个实用工具习惯第一个习惯是给所有节点写一个统一的部署检查脚本。脚本内容其实很简单检查进程、jps对比、端口连通、磁盘空间、配置文件一致性。每次变更后跑一遍能在几分钟内筛出绝大多数低级失误。我自己用类似脚本省了很多排查时间。第二个习惯是保存好每次切换前后的状态快照。用hdfs haadmin -getAllServiceState输出配合时间戳存到本地文件。这样一旦出现问题能快速判断到底是哪一步操作导致了状态变化。尤其多人在同一套集群操作时这个日志能帮你复盘出“是谁动的手”。如果条件允许建议构建集群之后专门留一个晚上做一次完整的模拟演练包括kill Active进程、断开一台JournalNode的网线、调整ZooKeeper会话超时等场景。演练时重点看两点切换时间是否符合预期、fencing是否每次都能成功。只有把这些都验证过才能放心把业务交到HA集群上。