接到集群扩容通知的时候，我一般不会直接让机房把机器加进机架，而是先翻一遍最近几周的监控曲线。Hadoop集群扩展这个动作，表面看就是“新增节点”：把DataNode和NodeManager跑起来，注册到NameNode和ResourceManager，等balancer把数据搬过去就算完。真做起来，版本、机架、磁盘、文件描述符、组件连带关系，随便哪一环出错，轻则节点注册不上，重则影响在线任务。这篇内容就是围绕新增节点的完整操作过程，从容量评估、环境准备到接入HDFS/YARN、数据均衡，最后把我会踩的坑和排查思路一并列出来。适合正在扩容、第一次接触Hadoop集群、或者想把手动流程固化成标准的读者参考。

1. 扩容之前，先把这三件事想清楚

1.1 判断扩容需求，而不是拍脑袋加机器

我见过不少人一看某个DataNode磁盘使用率到了85%就急着加节点，结果机器加完，NameNode内存先顶不住了。扩容不是看单一指标，要先回答三个问题：当前瓶颈在磁盘、CPU、内存还是IO？加完节点能解决什么？会不会把瓶颈转移到别处？

判断扩容需求时我会拉这些监控项：

• HDFS容量使用率：整个集群已使用空间除以总容量，连续多天高于70%到80%就要规划扩容。
• DataNode单盘使用率：有的节点单盘被打满，但集群整体还有富余，这时候优先考虑磁盘均衡而不是加节点。
• NameNode堆内存和块数量：DataNode数量增加，块副本在NameNode上的内存占用也会涨。一个小集群如果只有几百万块，加几十个节点问题不大；如果是上亿块的规模，就得先给NameNode加堆，否则几十个新节点注册进来，Full GC频率会明显上升。
• 网络带宽：副本复制、balancer迁移、Shuffle流量，扩容之后网络压力会变大，尤其是跨机架流量。
• YARN队列等待任务数：如果集群还有大量空闲资源，只是个别队列阻塞，扩容的必要性要打折扣。

容量规划有一个很容易算错的点：HDFS默认三副本，能用多少空间取决于副本因子。裸盘8TB、三副本、留10%预留，实际可用大概是8除以3再乘0.9，大约2.4TB。有些团队算容量直接按裸盘累加，后面会发现“怎么数据没写多少，磁盘就满了”。纠删码情况不同，但生产环境默认还是三副本为主，规划时按这个逻辑折算。

1.2 版本与配置一致性，这是最容易埋雷的地方

新增节点最忌讳“大概装个一样的环境就行”。Hadoop各小版本之间存在协议差异，DataNode的注册、心跳、块报告在2.x和3.x之间就有明显区别。生产环境我要求所有节点用完全相同的发行版、相同的小版本、相同的JDK。一个集群里出现DataNode版本不一致，轻则在NameNode日志里看到“registration denied”，重则节点反复下线，影响副本数。

把配置文件从老节点复制到新节点是最稳的做法，因为老节点的配置已经经过线上验证。复制之后要重点核对以下几项：

• core-site.xml：默认文件系统、代理用户配置、机架感知脚本路径。
• hdfs-site.xml：NameNode地址、dfs.namenode.rpc-address、dfs.datanode.data.dir、dfs.replication、dfs.permissions。
• yarn-site.xml：ResourceManager地址、NodeManager本地目录、日志目录、资源内存和CPU配置。
• mapred-site.xml / capacity-scheduler.xml：如果走MapReduce，注意mapreduce.cluster.local.dir等设置；队列配置决定新资源能否被队列正确使用。
• workers或slaves文件：这是管理脚本控制启动范围的文件。旧版本用slaves，新版本已经改成workers，内容为DataNode节点主机名列表。如果配置文件管理里还保留slaves，而实际脚本读的是workers，start-dfs.sh会漏节点。

配置同步完之后建议做一次差异比较，比如用md5sum批量校验每个配置文件，避免某台机器上的配置被人手工改过但没同步回来。

1.3 机架规划和副本策略，不止是网络拓扑的问题

很多Hadoop集群从一两个机架扩展到十几个机架，扩容时机架感知往往被忽略。HDFS的默认副本放置策略，先考虑在客户端所在节点放一个副本，再考虑在不同机架的节点放第二个副本，第三个副本与第二个放同一机架但不同节点。如果新节点没有机架信息，NameNode会把它们全部归到“/default-rack”，这会造成两个后果：副本可能集中在同一交换机下，交换机故障丢数据的风险变大；balancer在迁移副本时无法按机架做最优规划，跨机架流量会比预期高。

有些团队只在core-site.xml里配置了topology.script.file.name，但脚本只覆盖了老节点的IP和机架映射，新节点没有对应记录，脚本就回退到默认机架。所以扩容前要确认机架感知脚本对新节点IP或主机名能返回正确的机架路径。如果你用的不是脚本，而是/topology或/topology.default这类网络拓扑表，也要同步新增项。

另外还要估算新增节点所在交换机带宽。一般新节点会部署到同一机架的剩余U位，这时机架内带宽通常够用。但如果是新增一个完整机架，就要注意上联带宽是否为全机架预留了足够容量，夸张一点的场景是，新机架所有磁盘加起来有5PB，但上联只有10GbE，后续balancer一跑，整个机架的网络就成瓶颈。

2. 新节点系统环境准备，照着清单来

2.1 基础软件与网络配置

Hadoop依赖的基础环境并不复杂，但需要保证和老节点完全对齐。我先列一个操作清单：

• JDK版本：解压安装新版之前，先确认老节点用的到底是OpenJDK 8还是11，以及具体小版本。JDK版本不一致会引发一些诡异的本地库和RPC行为，虽然大多数时候表面正常，但一到高并发读写就开始出奇怪异常。
• SSH免密登录：如果继续使用start-dfs.sh和start-yarn.sh，那么NameNode主机和ResourceManager主机要能免密SSH到新节点。生产环境中我更建议手动启动DataNode和NodeManager，但免密还是要配好，因为排查问题时需要快速登录。
• hosts和DNS：新节点的/etc/hosts必须能解析集群内所有主机名，至少NameNode、ResourceManager、ZooKeeper节点要能双向解析。这里有个小坑：如果你只配了内网IP，没有配主机名，DataNode注册到NameNode时可能会使用IP作为主机名，导致NameNode Web界面上出现两个“同名”不同IP的节点，后续退役和监控都很难处理。
• NTP时间同步：哪怕没开Kerberos，时间偏差过大也会影响HDFS租约恢复和YARN任务时间计算。建议统一使用NTP或chrony，偏差控制在几十毫秒内。
• 防火墙和SELinux：单机防火墙如果开了，至少要放行DataNode和NodeManager需要的端口，比如DFS数据流端口默认9866（Hadoop 3）或50010（Hadoop 2）、IPC端口9867或50020；NodeManager的8040、8042等。我踩过最无语的坑就是新节点防火墙默认拒绝所有端口，导致DataNode进程能起来，但NameNode和客户端建立数据流连接超时。
• 系统文件句柄：DataNode和NodeManager都是长期运行且并发高的进程，需要把/etc/security/limits.conf里的nofile调大，一般设置为65536或更高。Java进程在高负载下还会吃很多线程，也需要检查进程数和内存映射限制。
• vm.swappiness：Hadoop节点不建议系统主动换页，建议调低，比如设成1或直接关掉。

2.2 磁盘规划与数据目录注意事项

新节点加硬盘后，不要只挂载完就完事，还要想清楚数据目录怎么写。HDFS的DataNode支持多目录，在dfs.datanode.data.dir里用逗号分隔。比如：

dfs.datanode.data.dir=/data/1/dfs/dn,/data/2/dfs/dn,/data/3/dfs/dn

这样配置后，DataNode会自动把目录挂到多个磁盘上。注意几个要点：

• 每个挂载点对应不同物理磁盘，不要把一个物理盘分成多个分区给DataNode，那样没意义，而且会让block分布不均匀。
• 建议使用XFS，挂载参数加上noatime,nodiratime，避免访问时间戳产生额外IO。
• DFS数据目录不要自己手动mkdir并创建current目录，交给DataNode进程自动初始化。如果手动mkdir且属主错了，会发现DataNode一直报Permission denied。正确做法是保证父目录存在，并且属主属于运行Hadoop的用户，让DataNode自己生成dfs/dn里后续目录结构。
• 新节点挂载了多块盘，启动后最好用iostat分别看每块盘是否都在工作，避免某块盘没被DataNode识别。

2.3 用户、安装目录和程序包同步

我在多个集群都遇到过“用户ID不一致”的问题：老节点运行用户是hadoop，uid是1001，新节点系统里hadoop用户uid是1002。由于HDFS权限和本地文件属主校验的链路，这种不一致会导致权限假象，比如本地文件属主看起来是hadoop，但NameNode里记录的是数字uid，最终出现莫名其妙的Permission denied。

为了让新增节点和老节点完全一致，我会做这几件事：

1. 确认运行用户、uid、gid和home目录一致。
2. 把Hadoop安装包从老节点直接打包拷贝到新节点，或者用内部配置管理工具分发，保证二进制完全一致。
3. 重点校验环境变量和软链接。比如有的机器把/opt/hadoop软链到实际安装目录，新节点如果直接复制安装包但没创建软链，后面所有脚本都会找不到路径。
4. 检查JAVA_HOME路径是否一致，包括部署JDK的路径和软链方式。

这一步看起来琐碎，但能在后面省掉大量排查时间。配置漂移和版本漂移是扩容后出现隐性故障的最主要来源。

3. 把节点正式接入HDFS和YARN

3.1 配置同步时，要额外处理的几个参数

先从老节点同步配置文件到新节点，这一步没有太多技巧，关键是同步完之后只改新节点特有的参数。需要特别关注的是：

• dfs.datanode.data.dir必须是新节点上实际存在的挂载目录，不能直接照搬老节点路径。如果有老节点用了/server1/disk1这样的路径，新节点必须改成自己的路径。
• yarn.nodemanager.local-dirs和yarn.nodemanager.log-dirs需要按新节点磁盘规划重新写。
• yarn.nodemanager.resource.memory-mb和yarn.nodemanager.resource.cpu-vcores要根据新节点实际配置估算。很多集群会漏设这两项，NodeManager起来后会按默认值或容器自动检测，结果是新节点资源被低估，任务跑得慢。
• dfs.datanode.handler.count通常保持和老节点一致，不需要针对新节点单独调。

还有两个配置需要重点检查：如果NameNode上配置了dfs.hosts（也就是include白名单文件），那么新节点的主机名必须加进这个白名单，否则DataNode启动后会被拒绝注册。同样，ResourceManager如果配置了yarn.resourcemanager.nodes.include-path，必须把新节点加进去。这类白名单配置一旦漏了，现象就是DataNode或NodeManager一直起不来，或者起来后在界面上看不到节点在线，很多人会误以为端口不通，实际是注册被拒。

3.2 手动启动DataNode和NodeManager

接入过程一般不推荐修改NameNode和ResourceManager配置后重启集群，正常情况也不需要重启现有服务。新节点只是增加一个注册者，配置好之后启动对应进程即可。

第一步，启动DataNode。在Hadoop 3.x环境中，执行：

hdfs --daemon start datanode

如果用的是Hadoop 2.x，则执行：

hadoop-daemon.sh start datanode

启动后先看日志，日志一般输出到Hadoop日志目录，文件名通常类似hadoop-hadoop-datanode-主机名.log。我习惯在启动后等一分钟左右，再执行：

hdfs dfsadmin -report

列表里应该能看到新节点，状态是“In Service”，并且配置容量比加入之前增加了。

第二步，启动NodeManager：

yarn --daemon start nodemanager

对应Hadoop 2.x版本是：

yarn-daemon.sh start nodemanager

然后执行：

yarn node -list -all

查看新节点是否出现。正常情况下它会自动注册到ResourceManager，无需重启RM。

这里有个细节：workers/slaves文件控制的是start-dfs.sh、start-yarn.sh这类批量启动脚本的范围。如果你采用手动启动方式，那么是否把新节点写进workers文件其实不影响本次启动和注册。但如果后续有人执行了全量启动脚本，新节点不在列表里，重启后就会漏掉，导致集群容量回退。所以新节点稳定运行后，一定要把它加入workers文件。

如果这次扩容同时改动了机架感知脚本，或者改了dfs.hosts配置，需要在NameNode上执行：

hdfs dfsadmin -refreshNodes

让NameNode重新加载白名单和机架信息。对应YARN也要刷新：

yarn rmadmin -refreshNodes

3.3 用数据说话，确认节点确实在服务

只用jps看到DataNode进程还不够，因为进程存在只能说明守护程序活着，不能证明它已经被NameNode接收。我一般按下面几步验证：

1. 看HDFS容量有没有增加：

hdfs dfsadmin -report

对比扩容前和扩容后的“已配置容量”，新节点单机容量应该能算出来。

2. 看数据块是否落到新节点：

hdfs fsck /user/testdir/testdata -files -blocks -locations

执行后能看到每个块所在的DataNode，如果新节点已经接管了部分副本，说明注册和心跳都是正常的。如果新节点上全是空的，只能说明副本还没有被复制过来，需要等待或主动平衡。

3. 在YARN上跑一个简单任务验证资源：

yarn jar /opt/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-*.jar pi 10 100

确认任务能在新节点上申请到容器并正常运行。如果新NodeManager没有容器运行，检查YARN Web界面上新节点的“Used MemoryPercentage”或“Container”状态。

4. 如果集群启用了HDFS的“DataNode磁盘均衡”，也就是单个节点内多块磁盘使用率差异很大，可以直接用hdfs diskbalancer命令生成均衡计划，这个后面会专门谈。

4. 数据均衡与长期维护

4.1 为什么刚加入的节点总是“只登记不干活”

新节点加入集群后，HDFS不会自动把老节点上的数据搬过来。NameNode只是把这个DataNode纳入了副本放置候选。结果是，新节点磁盘可能很长时间都是空的，老节点磁盘持续增长，客户端写入时如果选择数据本地性，又总是优先写老节点附近的位置。要解决这个问题，必须手动运行HDFS Balancer。

跑Balancer之前先定两个参数：带宽和阈值。默认Balancer带宽太低，而且在线业务繁忙时跑太快会影响正常IO，所以我习惯先设置带宽，一般100MB到200MB，选业务低峰期执行：

hdfs dfsadmin -setBalancerBandwidth 104857600

这里单位是字节/秒，104857600就是100MB/s。带宽设太低，比如10MB/s，均衡一个大集群可能要跑好几天。

然后执行：

hdfs balancer -threshold 10

threshold表示数据节点存储使用率与集群平均使用率的最大偏差。比如集群平均使用率70%，threshold=10，那么Balancer会尽量让每个节点使用率落在60%到80%之间。值设越小越“精准”，但需要移动的数据量越大，耗时越长。第一次扩容我建议用10，等集群稳定后再把阈值调低到5跑一轮。

如果只想针对新增节点做均衡，可以用：

hdfs balancer -include 新增节点列表文件 -threshold 5

include参数指定只处理哪些节点，但注意它不意味着“只从老节点搬到新节点”，而是全局均衡时优先考虑这些节点，最终还是以整体均衡为目标。

Balancer跑完看一遍各节点磁盘使用率，保留一份均衡前后的对比记录，方便后面复盘。

4.2 机架感知/diskbalancer与数据分布验证

机架感知配置生效后，最直接的验证方式是查看块副本分布：

hdfs fsck -files -blocks -locations | grep "DatanodeInfo\|rack"

或者用hdfs dfsadmin -printTopology查看当前Node的机架环。如果新节点出现在错误的机架下，说明topology脚本返回有问题，可以单独在节点上执行一次脚本验证返回值：

bash /path/to/topology/script <IP或主机名>

脚本返回的必须是机架路径，类似“/rack-1”或“/dc/rack-1”。如果返回空或者报错，就把问题留在接入阶段解决，不要拖到数据均衡之后，否则副本会按错误机架放置，后面想纠正代价更高。

还有一个容易被忽视的操作：Hadoop 3的diskbalancer专门处理单个节点内不同磁盘利用率不均的问题。比如一个DataNode挂了12块盘，数据写入时可能集中在前几块盘，后几块盘闲置。命令分三步：

hdfs diskbalancer -plan datanode主机名

会生成一个JSON计划，然后执行：

hdfs diskbalancer -execute 刚才生成的计划文件

再查询：

hdfs diskbalancer -query 主机名

Balancer和diskbalancer是两个不同层面的工具，前者负责节点间均衡，后者负责节点内磁盘均衡，可以按需使用。

4.3 长期监控与容量规划调整

节点接入后，监控和容量规划要跟着更新。我最注意的是这几项：

• NameNode内存和块数量：新增节点会带来更多block副本信息，NameNode内存占用会缓慢上升。大集群扩容后建议观察一周的GC曲线，如果Full GC更频繁，就要及时调大NameNode堆并重启。
• YARN队列资源：如果启用了Capacity Scheduler，新增节点带来的资源会自动加到租户可用资源池中。但如果你为某个队列配置了绝对资源上限，比如“最大可用内存500GB”，新节点资源可能不会全部被该队列利用。如果确实要把新资源分配到对应队列，需要调整容量调度配置。
• 监控告警阈值：新节点接入后，总容量和总内存都变了，原先的高水位阈值要同步修改。很多扩容事故都发生在“容量报警还没调整，下个季度数据继续增长，某一刻突然打满”。
• CMDB和资产信息：记录新节点的物理位置、机架、磁盘序列号、网口、开始服务时间。扩张之后如果不维护这些信息，后续排查硬件故障会非常痛苦。

4.4 新老替换场景下的退役流程

扩容还有一种常见场景是“新节点顶替旧节点退役”。这种情况下，建议先让新节点进来并完成数据均衡，再让旧节点退役，避免节点数和副本数双重减少导致数据风险。

退役操作依赖include/exclude黑白名单机制。在NameNode上，dfs.hosts是允许列表，dfs.hosts.exclude是退役列表。动态退役步骤是：

1. 把要退役的主机名写入dfs.hosts.exclude文件。
2. 执行hdfs dfsadmin -refreshNodes。
3. 观察hdfs dfsadmin -report中该节点状态从In Service变为Decommission In Progress，再变为Decommissioned。
4. 等所有块都被复制到其他节点后，节点可安全下线。

注意不要在执行退役前把节点从dfs.hosts里直接删掉，那样会变成“直接移除”而不是“优雅退役”，严重时丢副本数。

YARN侧同理，在yarn.resourcemanager.nodes.exclude-path指定的文件中写入节点，执行yarn rmadmin -refreshNodes，等NodeManager不再接收新容器后就能停掉进程。

退役和新增经常一起做，所以我把这两步放在扩容器流程里一起说。分批扩容时，我习惯同时只退役一两个节点并启动一两个新节点，而不是一次性换掉十几台，否则balancer和副本复制压力叠加，很容易把集群拖垮。

5. 实战中踩过的坑与排查技巧

5.1 DataNode启动即退出，常见原因怎么找

新节点DataNode启动后进程消失，是最常见的问题。第一步不是改配置，而是去日志目录里看日志，通常能看到明确原因。我归纳了几类高频问题：

• 数据目录异常：日志里出现“Invalid directory”或者“Permission denied”。原因往往是dfs.datanode.data.dir指向的父目录不存在，或者权限不是hadoop用户。有些团队喜欢先手动mkdir并chown，但chown时把uid搞错了。
• 版本不一致：日志出现“Incorrect configuration”或者“Storage version mismatch”。说明DataNode的本地版本文件格式和NameNode不一致，最常见的原因是安装包版本不同。解决办法是把新节点上的Hadoop二进制换成老节点版本，删除残留的dfs数据目录（如果有的话），再启动。
• 主机名解析问题：日志里显示DataNode用localhost或IP注册，而NameNode白名单里写的是主机名。解决办法是修正hosts和主机名，确保hostname -f返回可预期的名字。
• 端口被占用或防火墙拦截：DataNode启动进程看起来正常，但NameNode长时间没有收到心跳。检查节点是否能连通NameNode的8020/9820端口，检查防火墙是否放行DFS数据流端口。
• DataNode注册被NameNode拒绝：如果日志或NameNode日志出现“DatanodeRegistration denied”，优先检查dfs.hosts白名单内容和节点主机名是否匹配，然后执行hdfs dfsadmin -refreshNodes。

排查完启动问题后，务必用hdfs dfsadmin -report确认节点数，不要只看jps。有时候DataNode进程活着，但状态是“STALE”，说明NameNode长时间没收到心跳，这通常和网络或DNS解析有关。

5.2 NodeManager状态为UNHEALTHY，怎么处理

NodeManager有自己的健康检查机制。我遇到过新节点前两小时正常，跑了一批任务后状态变为UNHEALTHY。这类问题基本是因为本地磁盘空间不足或磁盘IO异常，NodeManager会定期检查local-dirs和log-dirs。日志里可以看到类似“local-dir is bad”的提示。

处理方式是：确认对应磁盘是否还有空间和IO能力，修复后执行：

yarn node -list -all yarn rmadmin -refreshNodes

如果磁盘真的坏了，需要把坏盘从yarn.nodemanager.local-dirs里移除，然后重启NodeManager。新节点刚上线时最容易出现这个问题，因为很多临时容器和中间文件会快速把唯一的系统盘或容量小的挂载点写满。建议yarn.nodemanager.local-dirs不只挂一个目录，至少跨两块独立磁盘。

另一个容易被忽略的问题是yarn.nodemanager.resource.memory-mb没配好。新节点物理内存64GB，NodeManager默认只给8GB的话，容器资源会非常紧张。配置好之后重启NodeManager，再用yarn node -list -all看资源总量是否变化。

5.3 Balancer跑得非常慢或完全不前进

扩容后跑Balancer，最怕界面一直停留在0%。常见原因有三个：

1. 集群还处于安全模式或副本复制进行中。比如刚写入大量数据，NameNode还在补副本，Balancer会等待。
2. 设置带宽太低。默认带宽可能只有1MB/s，需要手动调高。
3. 集群网络或磁盘IO已经饱和。这时即使提高Balancer带宽也没用，需要错峰执行。

有一种情况是Balancer本身没有权限移动某些块，比如文件设置了“append-only”或“snapshot”保护，这些块会被跳过。一般不用干预，等Balancer跳过这些块后继续跑即可。

跑Balancer的一个小习惯：不要一次跑完所有节点。一个大集群如果所有节点都参与均衡，移动的数据量非常大。我通常会分几个批次执行，用-include限定一批节点，比如先处理新增节点和相邻节点，跑通后再扩展到全集群，这样即便中途出问题，也只会影响一部分节点。

5.4 新增节点后任务性能反而下降

有一部分集群在扩容后短期任务变慢，原因不是新节点性能差，而是数据还留在老节点上，任务被迫通过网络读取远端数据块，本地性变差。这种情况在跑完Balancer后会好转，所以如果扩容后立刻跑业务，建议先用小数据量任务验证流程，再安排正式业务。

还有一种情况是任务调度器把大量container调度到了新节点，而新节点虽然计算资源多，但HDFS缓存、磁盘性能和网络配置可能不如老节点。查看新节点有没有“数据本地性不佳”的告警，如果存在，等待均衡之后再看效果。

另外，新节点上如果跑着除DataNode之外的业务进程，比如日志采集、监控Agent，可能抢占IO和CPU。扩容新增节点时我习惯同步关闭或降级非核心Agent的写入频率，避免影响DataNode对外服务能力。

5.5 快速问题速查表

排查问题前，先做好时间线和日志收集。我看到很多现场排查时会逐个节点看jps，这没有问题，但更重要的是从NameNode、ResourceManager的汇总日志里定位“节点被拒绝”或“心跳超时”这类主因。单个DataNode的日志只能证明它自己做了什么，无法代替管理端的判断。

写到最后，我个人在扩容这件事上的体验是：新增节点本身并不难，难的是“稳定地、可重复地”把一套节点从裸机变成集群的一员。手动操作一两台可以，数量多了之后就必须把前置检查、配置分发、启动验证、均衡观察固化成一套脚本和清单。我在实际操作中有一个笨办法：把每个新节点的启动过程做成一段日志式记录，包括检查项、执行命令、输出结果、验证命令四列，每次扩容都对照检查。这个习惯已经帮我避开了很多低级失误。最后再分享一个小技巧：新节点上线后，先不要急着把它加入任何自动扩缩容脚本，先观察24小时，确认它稳定处理了任务、没有反复掉线，再放开自动调度权限。集群扩容不是一锤子买卖，而是持续运维的一部分，稳一点，比快一点更重要。