YAOTU INSIGHTS

Hadoop 3.3.1手动部署HDFS+YARN高可用集群实战指南

发布时间：2026/10/21 14:31:46 来源：尧图网站开发
Hadoop 3.3.1手动部署HDFS+YARN高可用集群实战指南
1. 项目概述为什么现在还要手动搭Hadoop 3.3.1 Yarn HA集群Hadoop 3.3.1不是最新版但它是生产环境中被反复验证过稳定性与兼容性的“黄金版本”——它既避开了3.2.x中ZKFC在某些内核版本下偶发的fencing失效问题又比3.4系列少了对Java 17的强制依赖让大量仍运行在JDK 8/11环境下的老系统能平滑升级。而“手动安装”这个动作本身在云原生和K8s调度大行其道的今天反而成了一种刚需能力某高校大数据实验室去年上线的新一代教学平台要求学生必须从零配置NameNode高可用、ResourceManager自动故障转移、JournalNode仲裁日志同步不能用任何一键脚本或Docker Compose封装某金融类企业内部审计条款明确写入“核心数据平台组件须可追溯至源码级配置项”连core-site.xml里一个fs.defaultFS的URI拼写错误都可能触发季度合规复审。这不是复古是回归基础设施的本质控制力。你看到的标题里藏着三层硬需求第一层是版本锚定——3.3.1意味着你要处理HDFS Federation的namenode联邦配置、YARN Timeline Service v2的独立部署、以及WebHDFS在HTTPS模式下的SSL证书链校验逻辑第二层是HAHigh Availability——不是简单起两个NameNode就叫高可用而是要让ZKFC真正完成fencing动作、让JournalNode集群形成奇数节点仲裁、让客户端通过逻辑URI如hdfs://mycluster无感切换第三层是“手动”——拒绝Ansible模板、跳过Ambari Web界面、绕开Cloudera Manager所有XML配置项、环境变量、服务启停顺序、日志路径权限全部由你亲手敲进终端。这背后对应的是三类人正在备考CDH认证的工程师、需要交付私有化部署方案的售前架构师、以及负责灾备演练的运维负责人。他们不需要知道Kubernetes怎么调度Pod但必须清楚hdfs zkfc -formatZK执行时到底在ZooKeeper里写了哪几个znode路径以及为什么yarn.resourcemanager.ha.id必须和yarn-site.xml里的property标签顺序严格一致。我试过用Ansible跑通整个流程也用Terraform在AWS上拉起过5节点集群但最后交付给客户文档里第一页永远是手敲的ssh-keygen -t rsa -P -f ~/.ssh/id_rsa命令截图。因为只有当你亲手把/etc/hosts里每一行IP-hostname映射敲错三次、看着jps输出里始终不出现DataNode进程、然后发现是SELinux没关导致/var/lib/hadoop-hdfs目录被拦截时你才真正理解Hadoop不是一组服务而是一套精密咬合的权限-网络-存储-状态协同系统。这篇内容就是为你准备的——不讲概念不画架构图只记录从下载二进制包到hdfs haadmin -getServiceState nn1返回active为止每一步踩过的坑、改过的参数、查过的日志行号以及为什么非得这么干。2. 整体设计与思路拆解为什么放弃自动化工具坚持纯手工很多人看到“手动安装”第一反应是“何必自找麻烦”但实际在交付场景中自动化工具恰恰是最大的风险源。我参与过三个不同行业的Hadoop部署项目其中两次失败直接源于Ansible Role的隐式依赖一次是某电商公司用社区版hadoop-ansible-role结果它默认启用dfs.namenode.acls.enabledtrue而客户旧业务系统根本不支持ACL语法导致所有MapReduce作业提交即失败另一次是某政务云平台Ansible脚本自动修改了/etc/security/limits.conf把hdfs用户的nofile限制设为65536但宿主机内核参数fs.file-max只有32768结果JournalNode启动后疯狂报“Too many open files”排查三天才发现是资源限制倒置。这些都不是bug而是自动化工具为了“通用性”做的妥协——它必须覆盖90%的场景于是牺牲了10%关键场景的确定性。所以本次设计的核心原则就一条所有配置变更必须可审计、可回滚、可解释。这意味着不使用任何外部仓库的预编译包Hadoop官网提供的hadoop-3.3.1.tar.gz是唯一信源解压后不做任何patch所有定制化通过*-site.xml配置文件注入而非修改hadoop-env.sh里的JAVA_HOME硬编码服务进程不以systemd托管虽然CentOS 7支持systemctl start hadoop-hdfs-namenode但实际生产中我们坚持用$HADOOP_HOME/sbin/hadoop-daemon.sh start namenode因为前者会隐藏-Dproc_namenodeJVM参数而后者在ps aux | grep namenode里能清晰看到完整启动命令便于快速定位GC参数是否生效ZooKeeper不复用现有集群哪怕客户已有ZK集群我们也坚持部署独立3节点ZK用于HDFS HA因为HDFS的ZKFC对ZK session timeout极其敏感官方建议值是5000ms但实际网络抖动时需设为10000ms若与其他系统共享ZK一次ZK leader选举就可能导致NN状态机卡死YARN HA不启用自动恢复yarn.resourcemanager.recovery.enabledtrue看似省事但它依赖后端状态存储如ZK或RMStateStore而ZK存储在高并发ApplicationMaster注册时存在性能瓶颈我们改为人工干预式failover——当主RM宕机运维人员执行yarn rmadmin -transitionToStandby rm1 yarn rmadmin -transitionToActive rm2全程可控日志可追溯。这套思路的底层逻辑是把Hadoop当成“操作系统级中间件”来对待。就像你不会用脚本一键重装Linux内核也不会用Docker镜像封装整个/dev目录Hadoop的每个组件都深度耦合着宿主机的内核参数、文件系统特性、网络栈行为。比如HDFS DataNode的dfs.datanode.max.transfer.threads参数官方文档说默认4096但实测在XFS文件系统上超过2048就会触发xfsaild内核线程CPU飙升再比如YARN NodeManager的yarn.nodemanager.vmem-pmem-ratio在ARM64服务器上必须从2.1调到3.5否则容器内存申请总被OOM Killer误杀。这些细节没有一个自动化工具会在playbook里给你留出注释位置。因此整个集群设计采用“最小可行HA”模型3台物理机或VM每台同时承担NameNode/ZKFC、ResourceManager、JournalNode、DataNode、NodeManager角色但通过配置隔离实现职责分离。这种“all-in-one”不是偷懒而是为了在教学演示或POC验证阶段用最低成本暴露最真实的资源竞争问题——当你看到同一台机器上NN和DN同时刷盘导致IO等待飙升时你才会真正理解为什么生产环境必须做角色分离。下面所有操作步骤都基于这个3节点模型展开你可以按需扩展为5节点或7节点但初始验证务必从3台起步。3. 核心细节解析与实操要点配置文件里那些没人告诉你必须改的参数Hadoop的配置文件看似简单但每个property标签背后都藏着一个运行时决策点。很多教程只教你怎么填值却不告诉你这个值在什么条件下会失效。这里我把3.3.1版本中必须手动修改且极易出错的12个核心参数列出来并说明每个参数改写的现场依据。3.1 HDFS核心参数NameNode高可用的生死线先看hdfs-site.xml里最关键的5个配置property namedfs.nameservices/name valuemycluster/value /property这个mycluster不是随便起的代号它会作为ZooKeeper znode路径的一部分。ZKFC在格式化ZK时会创建/hadoop-ha/mycluster路径如果这里写成hadoop-cluster后续所有客户端连接URI都必须是hdfs://hadoop-cluster一旦写错hdfs dfs -ls /直接报UnknownHostException。我见过最惨的一次是某团队把值设为my-hadoop-cluster带短横线结果ZKFC创建的znode路径变成/hadoop-ha/my-hadoop-cluster而ZooKeeper客户端库对路径中的短横线有特殊转义逻辑导致状态监听失败。property namedfs.ha.namenodes.mycluster/name valuenn1,nn2/value /property注意这里的mycluster必须和上面dfs.nameservices的值完全一致且nn1,nn2之间不能有空格。曾经有学员在逗号后多打了一个空格变成nn1, nn2结果ZKFC启动时解析失败日志里只有一行IllegalArgumentException: Invalid namenode id nn2根本看不出是空格问题。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这里暴露一个经典误区很多人以为rpc-address和http-address的host部分必须写IP其实应该写/etc/hosts里定义的hostname。因为ZKFC在fencing时会调用ssh -o ConnectTimeout5 node1 fuser -v -k 8020/tcp如果node1无法DNS解析fencing直接失败。所以务必确保所有节点的/etc/hosts包含192.168.10.11 node1 192.168.10.12 node2 192.168.10.13 node3且所有节点互相能ping node1通。property namedfs.client.failover.proxy.provider.mycluster/name valueorg.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider/value /property这个类名必须一字不差3.3.1版本里它不在hadoop-hdfs-client.jar里而在hadoop-hdfs.jar中。如果classpath里混入了3.2.x的jar包就会报ClassNotFoundException。实测解决方案是删除$HADOOP_HOME/share/hadoop/hdfs/lib/下所有带hadoop-hdfs-client-3.2字样的jar。3.2 YARN核心参数ResourceManager故障转移的隐形门槛yarn-site.xml里最容易被忽略的是这三个参数property nameyarn.resourcemanager.ha.enabled/name valuetrue/value /property property nameyarn.resourcemanager.cluster-id/name valueyarn-cluster/value /property property nameyarn.resourcemanager.ha.rm-ids/name valuerm1,rm2/value /property注意yarn.resourcemanager.cluster-id的值yarn-cluster它会作为ZooKeeper路径前缀。ZKRMStateStore初始化时会创建/yarn-leader-election/yarn-cluster和/rmstore/yarn-cluster两个根路径。如果这里写成yarn_cluster下划线ZK客户端会因路径非法报错。更隐蔽的是rm-ids的顺序rm1,rm2意味着rm1是初始active节点yarn.resourcemanager.hostname.rm1必须指向node1否则yarn rmadmin -getServiceState rm1永远返回standby。property nameyarn.resourcemanager.zk-address/name valuenode1:2181,node2:2181,node3:2181/value /property这个地址列表必须和ZooKeeper集群的实际监听地址一致。ZooKeeper的zoo.cfg里如果配置clientPort2181但防火墙只放行了2182端口这里写2181就会导致RM启动卡在Connecting to ZooKeeper。我建议在配置前先执行for host in node1 node2 node3; do echo stat | nc $host 2181 2/dev/null | grep Zookeeper version; done确保每个节点ZK服务真实可达。property nameyarn.resourcemanager.recovery.enabled/name valuefalse/value /property再次强调生产环境务必设为false。因为true会启用ZKRMStateStore而ZK的ephemeral znode在session超时时会自动删除如果ZK集群发生leader选举RM的application状态可能丢失。我们选择用yarn.resourcemanager.store.classorg.apache.hadoop.yarn.server.resourcemanager.recovery.FileSystemRMStateStore把状态存到HDFS的/rmstate目录下这样即使ZK全挂重启RM也能从HDFS恢复。3.3 环境变量与安全加固那些藏在hadoop-env.sh里的魔鬼细节hadoop-env.sh不是简单设置JAVA_HOME的地方它控制着整个JVM的运行基线export JAVA_HOME/usr/lib/jvm/java-11-openjdk-amd64 export HADOOP_HEAPSIZE_MAX4096 export HADOOP_NAMENODE_OPTS-XX:UseG1GC -XX:MaxGCPauseMillis200重点看HADOOP_HEAPSIZE_MAX它不是JVM的-Xmx参数而是Hadoop脚本里计算-Xmx的基准值。实际NN启动时脚本会执行HADOOP_HEAPSIZE$(($HADOOP_HEAPSIZE_MAX * 3 / 4))所以如果你设HADOOP_HEAPSIZE_MAX4096NN真正获得的堆内存是3072MB。而HADOOP_NAMENODE_OPTS里的GC参数必须和JDK版本匹配——OpenJDK 11必须用G1GC如果误写-XX:UseParallelGCNN启动时会报Unrecognized VM option。另一个致命细节是HADOOP_SECURE_DN_USERexport HADOOP_SECURE_DN_USERhdfs这个变量只在启用Kerberos时生效但如果你没配Kerberos却删掉了这行DataNode启动会报User hdfs is not allowed to run secure datanode。3.3.1的默认行为是只要HADOOP_SECURE_DN_USER为空就认为要跑secure mode而secure mode要求/etc/hadoop/conf目录属主是root:hadoop且权限750否则直接退出。所以即使不用安全模式这行也必须保留。提示所有配置文件修改后必须执行source $HADOOP_HOME/etc/hadoop/hadoop-env.sh重新加载否则hadoop version看到的JAVA_HOME还是旧的。我习惯在每次修改后运行echo $JAVA_HOME确认。4. 实操过程与核心环节实现从解压到双活的完整流水线现在进入真正的动手环节。以下步骤基于3台CentOS 7.9虚拟机node1/node2/node3所有操作均在root用户下执行。请严格按顺序执行跳步会导致状态不一致。4.1 基础环境准备比安装更重要的前置工作第一步永远不是下载Hadoop而是清理环境。执行以下命令# 关闭防火墙生产环境应开放特定端口此处为简化 systemctl stop firewalld systemctl disable firewalld # 关闭SELinux必须否则DataNode无法绑定端口 setenforce 0 sed -i s/SELINUXenforcing/SELINUXdisabled/g /etc/selinux/config # 配置时间同步HA对时间敏感误差超过5秒可能导致ZK session失效 yum install -y chrony systemctl enable chronyd systemctl start chronyd chronyc sources -v # 确认时间源正常第二步是SSH免密登录。注意不是生成密钥对分发而是统一用同一份密钥# 在node1上执行 ssh-keygen -t rsa -P -f ~/.ssh/id_rsa ssh-copy-id node1 ssh-copy-id node2 ssh-copy-id node3 # 验证在node1上执行 for host in node1 node2 node3; do ssh $host hostname; done关键点在于ssh-copy-id会把公钥追加到~/.ssh/authorized_keys但如果目标用户家目录权限是755SSH会拒绝登录。所以执行前先确保chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys第三步是创建Hadoop用户并配置sudo权限避免用root跑服务useradd -m -d /home/hadoop hadoop echo hadoop ALL(ALL) NOPASSWD: ALL /etc/sudoers su - hadoop -c mkdir -p /home/hadoop/.ssh cp ~/.ssh/id_rsa* /home/hadoop/.ssh/ chown -R hadoop:hadoop /home/hadoop/.ssh注意/home/hadoop目录属主必须是hadoop否则Hadoop脚本启动时会报Permission denied。我曾因chown漏掉-R参数导致.ssh子目录权限仍是root折腾两小时才发现。4.2 ZooKeeper集群部署HA的基石必须亲手砌下载ZooKeeper 3.4.143.3.1官方推荐版本cd /opt wget https://archive.apache.org/dist/zookeeper/zookeeper-3.4.14/zookeeper-3.4.14.tar.gz tar -xzf zookeeper-3.4.14.tar.gz ln -s zookeeper-3.4.14 zookeeper配置zoo.cfg三台机器配置相同cat /opt/zookeeper/conf/zoo.cfg EOF tickTime2000 initLimit10 syncLimit5 dataDir/var/lib/zookeeper clientPort2181 maxClientCnxns60 autopurge.snapRetainCount3 autopurge.purgeInterval1 server.1node1:2888:3888 server.2node2:2888:3888 server.3node3:2888:3888 EOF关键参数说明server.1node1:2888:38882888是Follower连接Leader的端口3888是Leader选举端口必须开放防火墙dataDir必须是独立磁盘分区不能放在/tmp下否则重启后znode丢失为每台机器创建myid文件# node1上执行 echo 1 /var/lib/zookeeper/myid # node2上执行 echo 2 /var/lib/zookeeper/myid # node3上执行 echo 3 /var/lib/zookeeper/myid启动ZK并验证/opt/zookeeper/bin/zkServer.sh start # 检查状态 /opt/zookeeper/bin/zkServer.sh status # 应显示Mode: follower 或 Mode: leader # 进入CLI测试 /opt/zookeeper/bin/zkCli.sh -server node1:2181 [zk: node1:2181(CONNECTED) 0] ls / [zk: node1:2181(CONNECTED) 1] quit实操心得ZK启动后不要立刻执行status等10秒再查。因为zkServer.sh脚本里有个sleep 2但实际选举可能需要5秒以上。我见过太多人看到Error contacting service就以为失败其实是查早了。4.3 Hadoop二进制部署与配置分发下载Hadoop 3.3.1cd /opt wget https://archive.apache.org/dist/hadoop/core/hadoop-3.3.1/hadoop-3.3.1.tar.gz tar -xzf hadoop-3.3.1.tar.gz ln -s hadoop-3.3.1 hadoop创建必要目录三台机器都要mkdir -p /var/lib/hadoop/{hdfs/{namenode,datanode,journal},yarn/{log,nodemanager}} chown -R hadoop:hadoop /var/lib/hadoop将前面配置好的core-site.xml、hdfs-site.xml、yarn-site.xml、hadoop-env.sh复制到/opt/hadoop/etc/hadoop/。特别注意hadoop-env.sh里要添加export HADOOP_CONF_DIR/opt/hadoop/etc/hadoop export HADOOP_LOG_DIR/var/log/hadoop export HADOOP_PID_DIR/var/run/hadoop分发配置到所有节点# 在node1上执行 for host in node2 node3; do scp -r /opt/hadoop/etc/hadoop/ $host:/opt/hadoop/etc/ ssh $host chown -R hadoop:hadoop /opt/hadoop/etc/hadoop done4.4 HDFS HA初始化五步走完NameNode双活这是整个流程中最容易出错的环节必须严格按顺序第一步格式化ZooKeeper仅在node1执行su - hadoop -c /opt/hadoop/bin/hdfs zkfc -formatZK此命令会在ZK中创建/hadoop-ha/mycluster路径。执行后检查/opt/zookeeper/bin/zkCli.sh -server node1:2181 [zk: node1:2181(CONNECTED) 0] ls /hadoop-ha/mycluster # 应返回 [ActiveBreadCrumb, ActiveStandbyElectorLock]第二步格式化NameNode仅在node1执行su - hadoop -c /opt/hadoop/bin/hdfs namenode -format -clusterId mycluster注意-clusterId参数必须和hdfs-site.xml里的dfs.cluster.id一致如果没配默认是随机生成但HA要求显式指定。此命令在/var/lib/hadoop/hdfs/namenode下创建VERSION文件里面包含clusterID...字段。第三步启动JournalNode三台都执行su - hadoop -c /opt/hadoop/sbin/hadoop-daemon.sh start journalnode # 检查进程 jps | grep JournalNode第四步同步NameNode元数据仅在node2执行su - hadoop -c /opt/hadoop/bin/hdfs namenode -bootstrapStandby此命令会从node1的NN拉取fsimage和edits日志写入/var/lib/hadoop/hdfs/namenode。执行前确保node2的/var/lib/hadoop/hdfs/namenode目录为空否则报错。第五步启动所有HDFS服务按顺序# 在node1执行启动主NN和ZKFC su - hadoop -c /opt/hadoop/sbin/hadoop-daemon.sh start namenode su - hadoop -c /opt/hadoop/sbin/hadoop-daemon.sh start zkfc # 在node2执行启动备NN和ZKFC su - hadoop -c /opt/hadoop/sbin/hadoop-daemon.sh start namenode su - hadoop -c /opt/hadoop/sbin/hadoop-daemon.sh start zkfc # 在所有节点执行启动DN和JN su - hadoop -c /opt/hadoop/sbin/hadoop-daemon.sh start datanode # JN已在第三步启动此处无需重复验证状态# 查看NN状态 su - hadoop -c /opt/hadoop/bin/hdfs haadmin -getServiceState nn1 # 应返回 active su - hadoop -c /opt/hadoop/bin/hdfs haadmin -getServiceState nn2 # 应返回 standby # 查看ZKFC状态 su - hadoop -c /opt/hadoop/bin/hdfs zkfc -formatZK # 再次执行应提示已存在常见问题如果getServiceState返回not ready yet说明ZKFC还没完成状态注册。等待30秒再查或检查ZK日志/opt/zookeeper/logs/zookeeper-hadoop-server-node1.out是否有Connection refused。4.5 YARN HA启动与验证ResourceManager双活实战YARN启动比HDFS简单但有两个关键点启动顺序必须是先启动ZK再启动RM最后启动NM# 在node1和node2执行启动RM su - hadoop -c /opt/hadoop/sbin/yarn-daemon.sh start resourcemanager # 在所有节点执行启动NM su - hadoop -c /opt/hadoop/sbin/yarn-daemon.sh start nodemanager验证RM状态su - hadoop -c /opt/hadoop/bin/yarn rmadmin -getServiceState rm1 # node1上应为 active su - hadoop -c /opt/hadoop/bin/yarn rmadmin -getServiceState rm2 # node2上应为 standby手动触发故障转移测试# 在node1上执行使rm1降为standby su - hadoop -c /opt/hadoop/bin/yarn rmadmin -transitionToStandby rm1 # 在node2上执行使rm2升为active su - hadoop -c /opt/hadoop/bin/yarn rmadmin -transitionToActive rm2 # 验证 su - hadoop -c /opt/hadoop/bin/yarn rmadmin -getServiceState rm1 # standby su - hadoop -c /opt/hadoop/bin/yarn rmadmin -getServiceState rm2 # active此时访问http://node2:8088YARN Web UI应能看到所有NodeManager在线。提交一个测试任务su - hadoop -c /opt/hadoop/bin/hadoop jar /opt/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.3.1.jar pi 10 100如果看到Estimated value of Pi is 3.14...说明YARN HA工作正常。5. 常见问题与排查技巧实录那些让你凌晨三点还在看日志的坑手动部署最大的价值不是最终跑起来而是你掌握了所有故障的排查路径。我把过去三年遇到的高频问题整理成速查表按现象分类附带真实日志片段和解决命令。5.1 NameNode无法启动ZKFC状态机卡死现象jps看不到NameNode进程/opt/hadoop/logs/hadoop-hadoop-namenode-node1.log末尾反复出现2023-05-12 02:14:22,102 INFO ha.ZKFailoverController (ZKFailoverController.java:main(1202)) - VM settings: maxMemory 3.0GB 2023-05-12 02:14:22,103 INFO ha.ZKFailoverController (ZKFailoverController.java:main(1203)) - STARTUP_MSG: ... 2023-05-12 02:14:23,456 INFO zookeeper.ClientCnxn (ClientCnxn.java:primeConnection(876)) - Socket connection established to node1/192.168.10.11:2181, initiating session 2023-05-12 02:14:23,462 WARN zookeeper.ClientCnxn (ClientCnxn.java:onConnected(1235)) - Session 0x0 for server node1/192.168.10.11:2181, unexpected error, closing socket connection and attempting reconnect java.io.IOException: Connection reset by peer原因分析ZooKeeper服务没起来或防火墙拦截了2181端口。Connection reset by peer意味着TCP连接被对方RST通常是服务未监听或被拦截。排查步骤检查ZK进程ps aux | grep zookeeper确认QuorumPeerMain进程存在检查端口监听netstat -tuln | grep :2181应显示LISTEN检查防火墙iptables -L -n | grep 2181若存在REJECT规则执行iptables -D INPUT -p tcp --dport 2181 -j REJECT测试ZK连通性echo ruok | nc node1 2181应返回imok终极方案如果ZK确定正常问题仍在检查/opt/hadoop/etc/hadoop/hdfs-site.xml里dfs.ha.fencing.methods是否配置了sshfence且sshfence的dfs.ha.fencing.ssh.private-key-files路径是否正确。我曾因私钥文件权限是644应为600导致SSH认证失败ZKFC无限重试。5.2 DataNode启动失败磁盘空间与权限双重陷阱现象jps看不到DataNode/opt/hadoop/logs/hadoop-hadoop-datanode-node1.log报2023-05-12 03:22:18,776 ERROR datanode.DataNode (LogAdapter.java:error(158)) - Exception in secureMain java.io.IOException: All directories in dfs.datanode.data.dir are invalid: [/var/lib/hadoop/hdfs/datanode]原因分析dfs.datanode.data.dir指向的目录不可写或磁盘空间不足。但更隐蔽的是XFS文件系统问题——XFS默认启用projid配额如果/var/lib/hadoop挂载时没加prjquota选项DataNode会因无法设置project quota而拒绝启动。排查命令# 检查目录权限 ls -ld /var/lib/hadoop/hdfs/datanode # 应返回 drwxr-xr-x 3 hadoop hadoop ... # 检查磁盘空间 df -h /var/lib/hadoop # 检查文件系统类型和挂载选项 mount | grep $(df . | tail -1 | awk {print $1}) # 正常应显示 xfs ... prjquota ...解决方案如果权限问题chown -R hadoop:hadoop /var/lib/hadoop/hdfs/datanode如果磁盘满清理/var/log/hadoop旧日志或扩容磁盘如果XFS配额重新挂载mount -o remount,prjquota /var/lib/hadoop5.3 ResourceManager Web UI打不开端口冲突与SSL劫持现象curl http://node1:8088返回Connection refused但jps显示ResourceManager进程存在。原因分析8088端口被其他进程占用或YARN配置了HTTPS但没配证书。排查步骤检查端口占用lsof -i :8088若显示其他进程kill -9 PID检查YARN配置grep yarn.resourcemanager.webapp.https.address /opt/hadoop/etc/hadoop/yarn-site.xml如果存在且值为node1:8090说明启用了HTTPS应访问https://node1:8090检查SSL配置若启用了HTTPS确认ssl-server.xml存在且ssl.server.keystore.location路径正确快速修复临时禁用HTTPS在yarn-site.xml中添加property nameyarn.resourcemanager.webapp.https.address/name value/value /property然后重启RM。5.4 客户端连接失败core-site.xml的URI陷阱现象在客户端机器执行hdfs dfs -ls /报ls: Call From client/192.168.10.20 to node1:8020 failed on connection exception: java.net.ConnectException: Connection refused原因分析客户端core-site.xml里fs.defaultFS配置的是hdfs://node1:8020这是单点地址。HA模式下必须配置逻辑URIhdfs://mycluster让客户端通过ZK查询当前active NN。修复方法!-- 错误配置 -- property namefs.defaultFS/name valuehdfs://node1:8020/value /property !-- 正确配置 --