先说结论给 Hadoop 集群加一台新节点真正的难点从来不是“把 datanode 进程跑起来”这一步而是你有没有想清楚为什么要加、加完之后对整个集群的容量和计算水位有什么影响以及加完之后怎么让数据平滑地分布过去。我在维护离线数据处理集群时踩过不少坑新机器注册不上、均衡程序跑了一天一夜没动静、扩容后老节点磁盘反而更满这种事都遇到过。后来我把整套新增节点的流程标准化从容量规划、环境初始化、标准部署与校验到数据均衡和参数调优整理成一套可以直接照着做的步骤。这篇文章就围绕这条主线来写适合正在维护 HDFS YARN 集群的运维、数据工程师以及第一次负责集群扩容的开发者参考至少能帮你少走几个弯路。1. 扩展前的总体规划为什么加节点加多少才合适1.1 先想清楚扩展的真实动机我见过不少团队只要一听“集群性能不行”第一反应就是加机器。但有一类问题加机器反而会变差。举个例子如果你只是想跑更多并发的 Spark 作业但当前瓶颈其实是小文件太多导致 NameNode 内存压力大那么把大量小文件做合并、调整分区裁剪收益比加节点大得多。所以动手之前先做一轮三问磁盘空间是不是真的接近预警线看的是 HDFS 使用率不只是单台机器的 df 输出。作业排队是不是因为 YARN 队列资源不足看 ResourceManager 的活跃节点、队列容量和挂起任务数。任务运行慢是因为计算能力不够还是磁盘 IO、网络 IO 已经打满加节点能分散压力但解决不了单任务本身的数据倾斜。做完判断再决定加哪类角色。常见的扩容场景有三种存储型扩容只增加 DataNode把 HDFS 容量抬上去计算型扩容着重增加 NodeManager扩 YARN 资源混合型扩容也就是大多数存储和计算共用集群的选择新机器同时挂 DataNode 和 NodeManager。明确动机之后再往下走才不会扩完才发现买错了配置。1.2 用数据说话容量和时间规划容量规划最容易混淆的是“裸容量”和“HDFS 可用容量”。客户或者业务方问“我们还有多少存储空间”通常指的是 HDFS 逻辑可用量。但 HDFS 默认副本因子是 3所以可用逻辑容量实际上是裸数据盘总容量除以副本因子。计算方法大致是HDFS 可用总量 集群裸数据盘总容量 / 副本因子HDFS 当前使用率 HDFS 已用逻辑容量 / HDFS 可用总量举例来说集群有 10 台机器每台 4 块 4TB 数据盘裸容量是 160TB副本因子 3HDFS 可用约 53.3TB。如果已用逻辑容量 40TB使用率约 75%。这个水位已经不低了我一般建议存储型集群长期保持在 60% 到 70% 以内给临时文件、三副本复制和均衡跳动留出缓冲。现在想把它压到 60% 以下HDFS 可用容量需要达到 40 / 0.6 ≈ 66.7TB对应裸容量需要 66.7 × 3 ≈ 200TB。当前裸容量 160TB还缺约 40TB。如果新增机器每台也是 4 块 4TB 盘也就是 16TB 裸盘至少补 3 台建议预留余量直接上 4 台。时间窗口同样重要。数据均衡会持续占用网络带宽如果集群一天 24 小时都有实时任务就选业务低峰期启动均衡并且用温和的带宽慢慢跑。如果可能尽量一次性把未来半年到一年的增长空间都考虑进去频繁扩容对集群稳定性没什么好处。1.3 DataNode 加 NodeManager 的取舍最普遍的做法是一个新节点上同时启动 DataNode 和 NodeManager。但这两类角色对硬件的要求不一样DataNode 主要吃磁盘容量和网络 IONodeManager 主要吃内存和 CPU。如果仅仅因为磁盘不够扩容就不必给新机器配太高内存否则 YARN 会把可用资源放大调度器把一堆任务塞到同一台机器上磁盘迟早再次爆满。一体化节点还要注意一个常见问题YARN 资源配置超配。假设新机器物理内存 48GB如果你给yarn.nodemanager.resource.memory-mb配成 40GB再叠加系统、Java 堆、JVM overhead物理内存不够时系统会开始用 swap性能直接崩。我的经验值是预留 20% 的内存给系统页缓存NodeManager 最大可用内存按物理内存的 0.8 来估单容器内存上限不要超过节点总内存的三分之一。至于纯存储型节点NodeManager 完全可以不启动避免进程白白占资源。2. 环境准备与前置检查把新机器变成集群的“正规军”2.1 硬件、网络与操作系统的初始化机器到手之后先别急着装 Hadoop把基础环境收拾干净再动手。磁盘方面我强烈建议每块数据盘单独挂载到一个挂载点。HDFS 的 DataNode 会针对dfs.datanode.data.dir里的每个目录建立独立 volume上报给 NameNode也方便单盘坏掉时隔离。如果你把四块盘做成一个大 LVM 逻辑卷之后坏了一块盘整个逻辑卷可能都不可用等于四块盘一起报废。系统盘单独挂载并且留足空间给日志目录因为 DataNode 和 NodeManager 的日志增长很快日志盘满了也会导致进程异常。网络方面DataNode 之间复制数据非常依赖带宽。新机器上线前至少做一次局域网带宽测试用 dd 或 iperf 验证单流吞吐。千兆环境期望达到 110MB/s 的量级如果只有 30MB/s先排查网卡协商速率、驱动和交换机端口限速否则上线后均衡数据会慢到怀疑人生。操作系统层面虽然不同发行版有细节差异但通用思路是一致的调低宿主机的 swap 使用倾向让 Hadoop 系进程尽可能避免长时间换页导致卡死关闭透明大页 THP它对内存管理和 Java 进程有明显干扰调高文件描述符和进程数上限例如把ulimit -n调到 65535 以上否则高并发下会出现 too many open files 之类的错误时间同步务必做好确保 NTP 或 Chrony 正常运行集群里时间漂移会影响心跳判断和租约机制。2.2 版本统一、主机名与 SSH 免密版本不统一是新手最容易踩的坑。新机器上的 JDK 版本和 Hadoop 版本要尽可能与现有节点严格一致。我遇到过一个小版本不一致DataNode 启动时一直报协议校验错误排查了几小时最后发现就是版本差异。最稳妥的方法是从现有节点拿完全相同的安装包或者从发布仓库选择完全一致的版本。主机名和 hosts 映射要提前规划。HDFS 的块放置、YARN 的节点调度都基于主机名新机器必须把集群内所有节点的主机名解析表写好老节点的 hosts 里也要加上新节点的 IP 和主机名。虽然新版 Hadoop 用 IP 也能工作但大多数发行版默认基于主机名打交道两边不一致会发生各种诡异问题。SSH 免密也容易被忽略。把新机器的公钥追加到所有管理节点的authorized_keys里包括 NameNode、备 NameNode、ResourceManager 等这样管理节点远程执行命令时不会卡在密码提示。2.3 软件目录、配置文件和角色白名单的准备最稳妥的部署方式是从一台已经稳定运行的老节点把整个 Hadoop 安装目录打包同步过去。打包前先做两件事删除运行时产生的 logs、pids、tmp 等目录删除节点私有的数据目录内容避免把老节点的数据目录一起复制过去。然后在新机器解压到相同路径确保用户、组、uid、gid 与集群一致否则跨节点访问会有权限问题。配置文件方面通常只需要同步core-site.xml、hdfs-site.xml、yarn-site.xml、mapred-site.xml、workers或slaves以及自定义的机架感知脚本。如果公司有配置中心统一下发可以跳过手工步骤但一定要确认新节点拉取到的配置与集群一致尤其是fs.defaultFS、dfs.namenode.rpc-address不然 DataNode 启动后根本找不到 NameNode。这里有个关键坑如果 NameNode 开启dfs.hosts白名单文件光在workers里加新节点是不算数的必须把新节点的 IP 或主机名写进白名单文件并执行hdfs dfsadmin -refreshNodes。我早期在这里栽过一次新节点日志一直显示重复向 NameNode 注册但 NameNode 就是不接受原因就是白名单没刷新。3. 新增节点的标准流程从部署到出现在集群里3.1 目录创建与权限准备启动进程之前把数据目录建好。假设规划了三个挂载点/data01、/data02、/data03可以分别创建mkdir -p /data01/hdfs/data chown -R hdfs:hadoop /data01/hdfs具体的用户和组按集群实际来有些发行版会使用hadoop用户。目录所有权必须是启动 DataNode 进程的用户否则启动时报 Permission denied即使启动成功写入块时也会遇到 IOException。磁盘配额和预留空间设置也要提前检查比如 ext4 文件系统的 reserved-blocks-percentage底层设置后期不太好改。3.2 分批启动先单节点验证再批量推广我的习惯是第一次只启动一台新节点确认日志里注册成功后再批量启动其余机器。Hadoop 3.x 下启动命令是# 先启动 DataNode 角色 hdfs --daemon start datanode # 确认无误后再启动 NodeManager yarn --daemon start nodemanager顺序上有讲究。DataNode 先注册到 NameNodeNodeManager 再向 ResourceManager 注册这样不会出现 YARN 认为节点可调度、但 HDFS 块服务还没就绪的情况。启动后要主动看日志不能只看进程在不在。DataNode 日志里出现Starting block service; registering with namenode now说明正在注册看到Registered with nameNode才算成功。如果一直出现Problem connecting to server或Retrying connect to server多半是网络或端口问题。这里说的端口通常是 NameNode RPC 端口比如 8020 或 9000DataNode 数据传输端口常用 9866需要一并确认防火墙策略。3.3 把新节点加入受管列表并刷新如果集群依赖workers或slaves文件管理节点需要在活跃 NameNode 对应的机器上把新节点主机名追加进去。如果用了dfs.hosts白名单文件追加节点后执行hdfs dfsadmin -refreshNodesYARN 侧如果配置了yarn.resourcemanager.nodes.exclude-path排除文件新增节点不需要额外处理但如果保险起见可以在 ResourceManager 上刷新节点信息yarn rmadmin -refreshNodes这个命令不是所有版本都支持但主流发行版基本都保留了。刷新操作不会影响存量节点在线状态这一步可以放心做。3.4 验证新节点真正在线而非假活我会同时看三个地方来确认节点真正加入NameNode Web UI默认 9870 端口打开 Datanodes 页面看新主机是否出现以及容量、最后心跳时间。命令行执行hdfs dfsadmin -report关注 Live datanodes 数量是否增加新节点容量和已用空间是否正常。如果启动了 NodeManager去 ResourceManager Web UI默认 8088 端口看 Active Nodes 列表里有没有新机器可用内存和核数是否正确。命令行也可以直接过滤hdfs dfsadmin -report | grep -A 6 Hostname: newhost看到 Last contact 是刚才的时间说明 DataNode 已经和 NameNode 建立了稳定心跳。再多看一眼日志确认没有磁盘坏盘或寻址失败。我不建议看见进程在就宣告扩容完成进程活着但块服务没起来的情况并不少见至少观察一个心跳周期通常也就是 3 秒到十几秒。4. 数据均衡与参数优化让新节点真正扛起流量4.1 为什么必须做数据均衡以及什么时候做新节点注册后HDFS 不会自动把老节点上的一部分块搬过去。NameNode 的块放置策略对已经存在的块不会重新计算所以新节点只是“以后写入的新块会优先考虑它”存量数据依然压在老节点上。后果很直接老节点磁盘快速接近上限新节点大量空闲后续写文件又会因为空间更充足而继续优先写入新节点形成新一轮不均衡。所以节点上线后要主动跑均衡。触发条件主要是集群不处于安全模式没有其他写操作锁影响均衡带宽提前设置好。判断安全模式用hdfs dfsadmin -safemode get输出Safe mode is OFF才适合跑均衡。如果你的集群还在数据迁移或者滚动重启中不建议立刻均衡先把集群状态稳定下来。4.2 设置带宽并启动均衡我会先把均衡带宽设成偏向保守的值比如 50MB/shdfs dfsadmin -setBalancerBandwidth 52428800单位是字节每秒。1MB/s 就是 1048576100MB/s 就写 104857600。设置带宽的意图是让均衡在后台慢慢移动数据不过分抢占业务流量。如果你直接在业务高峰期用默认带宽甚至更大带宽跑网络延迟会明显上升。然后执行hdfs balancer -threshold 10threshold 表示允许的容量偏差百分比。阈值 10 意味着各节点存储使用率与平均使用率的目标偏差控制在 10% 以内。老节点使用率已经很高时可以先把阈值设到 5让它尽量追平。但不要设置成 0那几乎永远跑不完因为总会存在微小的容量差异。均衡过程中会不断输出日志显示正在从哪些块池移动数据。我一般观察 10 分钟如果进度数字一直不跳再看带宽设置和网络状况。Hadoop 3.x 还支持多线程调度块移动用-D dfs.balancer.dispatcherThreads4可以提高吞吐但线程数不宜过大我通常控制在 4 到 8 之间避免把磁盘 IO 和网络都打满。4.3 均衡完成后的二次检查与配置核对均衡程序正常退出后不代表工作结束。再跑一遍hdfs dfsadmin -report对比各节点的 Used 和 Free确认已经趋于接近。同时记录一次当前总体使用率确认降到了目标区间。如果一次均衡后老节点使用率还是明显偏高可以过几天再跑一轮因为数据写入也在变化。此时顺手核对几项配置dfs.datanode.data.dir是否完整包含了每块盘对应的挂载点。我见过只配了一个目录导致新机器白白浪费几块盘的情况。yarn.nodemanager.resource.memory-mb、yarn.nodemanager.resource.cpu-vcores是否和新机器规格匹配。机架感知脚本是否已经让新节点上报了正确的机架名称。机架信息不对会影响副本分布策略等到均衡完成后发现再改会比较麻烦。5. 常见问题与排查技巧实录5.1 新节点半天不注册的排查思路这是新增节点最常碰到的问题。定位顺序按下面几步走看 DataNode 日志明确是网络层、认证层还是 NameNode 拒绝。用 telnet 或 nc 测试新节点到 NameNode RPC 端口是否通比如nc -vz namenode01 8020。确认/etc/hosts里的主机名与 IP 映射两边一致且 NameNode 反向解析正常。有白名单就确认dfs.hosts文件包含新节点并已刷新。常见报错也很有规律。出现File /xxx could only be replicated to 0 nodes基本说明新节点无法写入块多半是磁盘目录或权限问题。出现Unregistered node说明白名单或受管列表拒绝。出现ConnectException优先查网络和防火墙。防火墙这块特别提一下很多发行版默认开着 firewalld需要放行 Hadoop 相关端口最省心的方式是确认集群内节点间端口全部互通。5.2 数据均衡慢得像蜗牛常见原因其实就是几个。均衡带宽太低调大setBalancerBandwidth就好。集群处于安全模式或存在危险状态需要先解决底层问题。目标阈值设得太低比如 1% 甚至更小均衡程序会长时间找不到满足条件的块对放宽到 5 到 10 会快很多。还有可能是单线程执行试试-D dfs.balancer.dispatcherThreads4。如果均衡反复失败看nohup.out或均衡日志里的拒绝原因很多情况是权限不足或块损坏。块损坏会导致均衡任务反复重试先运行hdfs fsck / -files -blocks -locations查看文件健康状态。5.3 磁盘容量和坏盘问题新增节点启动后df -h显示的可用空间远低于预期先查三样系统默认预留的 5% 空间可以用tune2fs -m 1调低inode 是否耗尽多个挂载点空间不均导致 DataNode 把大量数据写到同一块盘。坏盘处理上DataNode 日志出现Disk out of space或Invalid mount而系统盘没问题基本说明某块数据盘异常。最稳的做法是把异常挂载点从dfs.datanode.data.dir里暂时摘除再重启 DataNode避免整个节点因为一块坏盘被迫下线。摘除之后NameNode 会通过副本复制机制把缺失的块在其他节点补齐前提是副本数配置满足三副本策略。5.4 YARN 侧看不到新计算资源如果 DataNode 注册正常但 ResourceManager 一直不显示新 NodeManager常见原因包括NodeManager 没有启动或反复崩溃要看 nodemanager 日志YARN 队列配置里把资源划分给了特定节点标签或放置约束新节点没有加对应标签旧配置缓存问题需要重启 NodeManager 或在 ResourceManager 上刷新。启动 NodeManager 后也可以用yarn node -list -all查看节点状态能直接看到是新节点处于 RUNNING 还是 LOST。最后再分享一个我多次扩容后养成的习惯每次扩容前先确认 NameNode 的元数据备份或者至少保证所处环境是高可用状态。新增节点本来属于低风险操作但refreshNodes这种命令一旦误操作比如写错白名单把所有节点都踢出去影响范围就大了。我会把扩容前的状态留一份存档包括hdfs dfsadmin -report输出、yarn node -list输出、每台节点的df快照放到固定目录。之后拿存档和新状态对比就能准确判断这次扩容到底把存储和计算水位降了多少。这个小动作帮我定位过好几次容量规划偏差也推荐给你。