接到集群扩容通知的时候我一般不会直接让机房把机器加进机架而是先翻一遍最近几周的监控曲线。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.xmlNameNode地址、dfs.namenode.rpc-address、dfs.datanode.data.dir、dfs.replication、dfs.permissions。yarn-site.xmlResourceManager地址、NodeManager本地目录、日志目录、资源内存和CPU配置。mapred-site.xml / capacity-scheduler.xml如果走MapReduce注意mapreduce.cluster.local.dir等设置队列配置决定新资源能否被队列正确使用。workers或slaves文件这是管理脚本控制启动范围的文件。旧版本用slaves新版本已经改成workers内容为DataNode节点主机名列表。如果配置文件管理里还保留slaves而实际脚本读的是workersstart-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数据流端口默认9866Hadoop 3或50010Hadoop 2、IPC端口9867或50020NodeManager的8040、8042等。我踩过最无语的坑就是新节点防火墙默认拒绝所有端口导致DataNode进程能起来但NameNode和客户端建立数据流连接超时。系统文件句柄DataNode和NodeManager都是长期运行且并发高的进程需要把/etc/security/limits.conf里的nofile调大一般设置为65536或更高。Java进程在高负载下还会吃很多线程也需要检查进程数和内存映射限制。vm.swappinessHadoop节点不建议系统主动换页建议调低比如设成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不一致”的问题老节点运行用户是hadoopuid是1001新节点系统里hadoop用户uid是1002。由于HDFS权限和本地文件属主校验的链路这种不一致会导致权限假象比如本地文件属主看起来是hadoop但NameNode里记录的是数字uid最终出现莫名其妙的Permission denied。为了让新增节点和老节点完全一致我会做这几件事确认运行用户、uid、gid和home目录一致。把Hadoop安装包从老节点直接打包拷贝到新节点或者用内部配置管理工具分发保证二进制完全一致。重点校验环境变量和软链接。比如有的机器把/opt/hadoop软链到实际安装目录新节点如果直接复制安装包但没创建软链后面所有脚本都会找不到路径。检查JAVA_HOME路径是否一致包括部署JDK的路径和软链方式。这一步看起来琐碎但能在后面省掉大量排查时间。配置漂移和版本漂移是扩容后出现隐性故障的最主要来源。3. 把节点正式接入HDFS和YARN3.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”并且配置容量比加入之前增加了。第二步启动NodeManageryarn --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 -refreshNodes3.3 用数据说话确认节点确实在服务只用jps看到DataNode进程还不够因为进程存在只能说明守护程序活着不能证明它已经被NameNode接收。我一般按下面几步验证看HDFS容量有没有增加hdfs dfsadmin -report对比扩容前和扩容后的“已配置容量”新节点单机容量应该能算出来。看数据块是否落到新节点hdfs fsck /user/testdir/testdata -files -blocks -locations执行后能看到每个块所在的DataNode如果新节点已经接管了部分副本说明注册和心跳都是正常的。如果新节点上全是空的只能说明副本还没有被复制过来需要等待或主动平衡。在YARN上跑一个简单任务验证资源yarn jar /opt/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-*.jar pi 10 100确认任务能在新节点上申请到容器并正常运行。如果新NodeManager没有容器运行检查YARN Web界面上新节点的“Used MemoryPercentage”或“Container”状态。如果集群启用了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 10threshold表示数据节点存储使用率与集群平均使用率的最大偏差。比如集群平均使用率70%threshold10那么Balancer会尽量让每个节点使用率落在60%到80%之间。值设越小越“精准”但需要移动的数据量越大耗时越长。第一次扩容我建议用10等集群稳定后再把阈值调低到5跑一轮。如果只想针对新增节点做均衡可以用hdfs balancer -include 新增节点列表文件 -threshold 5include参数指定只处理哪些节点但注意它不意味着“只从老节点搬到新节点”而是全局均衡时优先考虑这些节点最终还是以整体均衡为目标。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是退役列表。动态退役步骤是把要退役的主机名写入dfs.hosts.exclude文件。执行hdfs dfsadmin -refreshNodes。观察hdfs dfsadmin -report中该节点状态从In Service变为Decommission In Progress再变为Decommissioned。等所有块都被复制到其他节点后节点可安全下线。注意不要在执行退役前把节点从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没配好。新节点物理内存64GBNodeManager默认只给8GB的话容器资源会非常紧张。配置好之后重启NodeManager再用yarn node -list -all看资源总量是否变化。5.3 Balancer跑得非常慢或完全不前进扩容后跑Balancer最怕界面一直停留在0%。常见原因有三个集群还处于安全模式或副本复制进行中。比如刚写入大量数据NameNode还在补副本Balancer会等待。设置带宽太低。默认带宽可能只有1MB/s需要手动调高。集群网络或磁盘IO已经饱和。这时即使提高Balancer带宽也没用需要错峰执行。有一种情况是Balancer本身没有权限移动某些块比如文件设置了“append-only”或“snapshot”保护这些块会被跳过。一般不用干预等Balancer跳过这些块后继续跑即可。跑Balancer的一个小习惯不要一次跑完所有节点。一个大集群如果所有节点都参与均衡移动的数据量非常大。我通常会分几个批次执行用-include限定一批节点比如先处理新增节点和相邻节点跑通后再扩展到全集群这样即便中途出问题也只会影响一部分节点。5.4 新增节点后任务性能反而下降有一部分集群在扩容后短期任务变慢原因不是新节点性能差而是数据还留在老节点上任务被迫通过网络读取远端数据块本地性变差。这种情况在跑完Balancer后会好转所以如果扩容后立刻跑业务建议先用小数据量任务验证流程再安排正式业务。还有一种情况是任务调度器把大量container调度到了新节点而新节点虽然计算资源多但HDFS缓存、磁盘性能和网络配置可能不如老节点。查看新节点有没有“数据本地性不佳”的告警如果存在等待均衡之后再看效果。另外新节点上如果跑着除DataNode之外的业务进程比如日志采集、监控Agent可能抢占IO和CPU。扩容新增节点时我习惯同步关闭或降级非核心Agent的写入频率避免影响DataNode对外服务能力。5.5 快速问题速查表现象可能原因排查命令/动作DataNode启动后进程消失数据目录权限/不存在查看datanode日志确认dfs.datanode.data.dirDataNode启动但NameNode上不出现hosts解析不一致、防火墙、白名单未刷新hdfs dfsadmin -refreshNodes检查NameNode日志DataNode状态异常或STALE网络抖动、心跳未到达检查网络重启DataNode观察NameNode日志新节点容量为0尚未运行Balancerhdfs balancer -threshold 5NodeManager为UNHEALTHYlocal-dir磁盘故障或空间不足修复磁盘执行yarn node -list -all任务容器在新节点申请不到资源资源参数没配或队列配置限制检查yarn.nodemanager.resource.memory-mb调整调度器配置扩容后任务变慢数据本地性差、Balancer未跑完跑完Balancer后再观察检查机架感知是否生效排查问题前先做好时间线和日志收集。我看到很多现场排查时会逐个节点看jps这没有问题但更重要的是从NameNode、ResourceManager的汇总日志里定位“节点被拒绝”或“心跳超时”这类主因。单个DataNode的日志只能证明它自己做了什么无法代替管理端的判断。写到最后我个人在扩容这件事上的体验是新增节点本身并不难难的是“稳定地、可重复地”把一套节点从裸机变成集群的一员。手动操作一两台可以数量多了之后就必须把前置检查、配置分发、启动验证、均衡观察固化成一套脚本和清单。我在实际操作中有一个笨办法把每个新节点的启动过程做成一段日志式记录包括检查项、执行命令、输出结果、验证命令四列每次扩容都对照检查。这个习惯已经帮我避开了很多低级失误。最后再分享一个小技巧新节点上线后先不要急着把它加入任何自动扩缩容脚本先观察24小时确认它稳定处理了任务、没有反复掉线再放开自动调度权限。集群扩容不是一锤子买卖而是持续运维的一部分稳一点比快一点更重要。