1. 磁盘扩容这件事为什么主节点总是最先扛不住干过大数据平台运维的人大概都有个共同体会集群里最先亮红灯的往往不是算力最紧张的计算节点而是那个看起来没干多少活的主节点。我接手过好几个 CDP 集群的救火任务十次里有六七次都是主节点根目录使用率冲到 90% 以上监控告警一响整个团队的心都跟着悬起来。这次要聊的就是这个高频场景——CDP 集群主节点根目录磁盘扩容一个听起来简单、真动起手来处处是坑的活。先把话说清楚CDP 是 Cloudera 的数据平台发行版主节点上跑着一堆关键服务——Cloudera Manager Server、管理数据库、NameNode 元数据、ZooKeeper、Kerberos KDC、各种网关和审计日志。这些东西有个共同特点默认全往根目录写。日志越滚越大、审计数据越攒越多、元数据快照不断堆积根目录那点初始容量根本撑不住长期运行。所以磁盘扩容不是要不要做的问题而是什么时候做、怎么做才不出事的问题。这篇内容适合谁看如果你正在维护一套 CDP 或类似 Hadoop 生态集群遇到过根目录告警、服务因为磁盘满而挂掉、或者正准备给主节点做容量规划那这篇基本能当操作手册用。我会从整体思路、方案选型、具体操作、参数计算到踩坑排查一层层拆开讲尽量把每个为什么这么干都说明白让你看完能直接照着复现而不是只知道敲几条命令。需要提前说明的是下面涉及的具体容量数值、分区大小、路径名称都是基于常见实践的示例你实际动手时一定要按自己集群的真实情况换算别照抄数字。2. 整体思路与方案选型扩容不是简单加块盘2.1 先搞清楚根目录满到底是谁在吃空间动手之前最忌讳的就是上来就加盘。我见过有同行直接给虚拟机挂了一块新硬盘结果根目录还是满的因为新盘根本没挂到根上白忙一场。所以第一步永远是定位空间消耗的真实来源。在主节点上跑几条命令就能摸清底细df -h du -sh /* 2/dev/null | sort -rh | head -20第一条看各挂载点的使用率确认到底是/满了还是某个独立挂载的子目录满了。第二条从根往下逐层统计找出占用最大的目录。实际经验里主节点上吃空间的大户通常集中在这么几个地方/var/logCloudera Manager 和各个组件的日志尤其是没配轮转策略的时候几个月就能吃掉几十 G。/var/lib/cloudera-scm-serverCM Server 的数据库和内部数据。/opt/cloudera parcels 包和配置parcels 解压后体积不小。/dfs/nn或自定义的 NameNode 元数据目录edits 和 fsimage 堆积。/var/lib/zookeeper事务日志和快照。把这份清单列出来你才能判断是该清理还是该扩容。有些情况下清一轮日志、调一下轮转策略就能缓过来但如果是元数据、数据库这类不能随便删的东西占大头那就必须扩容。2.2 三种扩容路径的取舍逻辑定位清楚之后扩容方案大致有三条路各有适用场景我做个对照表方便你决策方案做法优点风险与限制适用场景原地扩盘云盘/虚拟盘在线扩容后扩展分区和文件系统不停机、路径不变、最省事依赖底层存储支持在线扩容云主机、支持热扩的虚拟化环境新增磁盘挂载挂新盘把大目录迁移过去再挂载灵活、可独立管理需要停服务迁移数据有停机窗口物理机、无法原地扩盘的环境LVM 逻辑卷扩展加物理卷到卷组扩展逻辑卷容量管理灵活、可后期再扩前期必须已用 LVM 布局规划时就用 LVM 的环境选哪条路核心看两个条件底层存储能不能在线扩以及根目录当初是不是 LVM 布局。如果是云环境且根盘支持在线扩容那基本走第一条最省心如果是物理机或者根目录是普通分区那就得考虑第二条做好停机窗口如果当初规划就用了 LVM那第三条最优雅加盘扩 LV 再 resize 文件系统一气呵成。我个人的偏好是能原地扩就原地扩不能原地扩就优先考虑把大目录迁到独立盘而不是硬去动根分区表。因为动分区表比如用 growpart 之外的手段调整分区边界风险最高一旦操作失误主节点起不来整个集群的管理面就瘫了。2.3 为什么主节点扩容必须先备份再动手这一点我要单独强调因为它是最容易被忽略、后果又最严重的环节。主节点上跑着 Cloudera Manager 的数据库和 NameNode 的元数据这两样东西一旦在扩容过程中损坏恢复成本极高。所以无论走哪条路动手前必须做两件事第一备份 CM 数据库。用数据库自带的导出工具把 scm 库导一份出来放到独立的位置。第二备份 NameNode 元数据目录至少把 fsimage 和 edits 拷一份。这两步花不了多少时间但真出事的时候就是救命稻草。注意备份要落到扩容操作不会影响到的地方比如另一台机器的共享存储或者对象存储别备份完还放在同一块要动的盘上那就等于没备。3. 核心细节解析原地扩盘的完整实操链路3.1 扩容前的容量计算别拍脑袋定大小很多人扩容就是看着不够就加一倍这其实不科学。合理的做法是先估算增长速率再定扩容后的目标容量。举个实际的算法假设你观察了三个月根目录从 60G 涨到 90G那月均增长约 10G再结合业务规划比如未来一年数据量预计增长 50%那预留空间至少要覆盖 12 个月的增长再打个安全系数。一个常用的经验公式是目标容量 当前使用量 月均增长 × 规划月数 × 安全系数(1.5~2)按上面的例子当前 90G月增 10G规划 12 个月安全系数取 1.5那目标就是 90 10×12×1.5 270G。取个整数扩到 300G 比较稳妥。这个计算过程看着简单但它能避免两个极端扩太小很快又满扩太大浪费成本。云盘按量计费的环境里这个账还是要算的。另外要留意文件系统的开销。ext4 默认会预留 5% 给 rootXFS 也有元数据开销所以实际可用空间会比标称容量小一点计算时心里要有数。3.2 云盘在线扩容的分区与文件系统扩展假设底层已经把云盘从 200G 扩到了 300G但操作系统里看到的还是 200G因为分区表和文件系统还没跟着扩。这一步是整套操作的核心顺序不能乱先扩分区再扩文件系统。先确认磁盘设备名和分区情况lsblk fdisk -l /dev/vda假设根目录在/dev/vda1磁盘整体已经变成 300G但分区还是 200G。这时候用growpart扩展分区最安全growpart /dev/vda 1这条命令只调整分区边界不动数据风险很低。执行完再用lsblk确认分区大小已经变成 300G。接下来扩文件系统这一步要根据文件系统类型选命令选错了会出问题# ext4 文件系统 resize2fs /dev/vda1 # XFS 文件系统 xfs_growfs /XFS 只能扩不能缩而且必须挂载状态下操作命令参数是挂载点而不是设备名这点特别容易搞错。ext4 的 resize2fs 参数是设备名。我见过有人对着 XFS 敲 resize2fs报错还以为是盘没扩成功其实是命令用错了。扩完用df -h验证根目录应该已经显示新容量了。整个过程服务不用停这是原地扩盘最大的优势。3.3 新增磁盘挂载方案的迁移细节如果底层不支持在线扩那就得走加盘 迁移目录的路子。这个方案的关键在于选对要迁移的目录以及迁移过程中的服务停止顺序。选目录的原则是挑那些体积大、增长快、又不是系统启动必需路径的目录。主节点上最典型的候选是/var/log、/opt/cloudera/parcels、NameNode 元数据目录。迁移/var/log相对安全但要注意迁移后日志服务还能正常写入迁移 parcels 目录要小心 CM 的路径配置。操作流程大致是挂新盘 → 格式化 → 挂到临时挂载点 → 停相关服务 → 用rsync把数据同步过去保留权限属性→ 原目录改名备份 → 新盘挂到原路径 → 启服务验证 → 确认无误后删备份。rsync的参数很关键必须带-a保留权限、属主、时间戳否则迁移后服务可能因为权限不对而起不来rsync -avx /var/log/ /mnt/newdisk/log/-x的作用是不跨文件系统避免把挂载点下的其他内容也带过去。同步完还要用diff -r或者对比文件数量确认一致性别急着删原数据。注意迁移 NameNode 元数据目录时必须先停掉 NameNode 服务等它把 edits 刷盘完成再迁否则可能迁到一半数据还在变导致元数据不一致。这个顺序错了恢复起来非常麻烦。4. 实操过程实录一次典型的主节点扩容4.1 环境摸底与变更窗口确认拿一次我实际处理过的场景来说。某套 CDP 集群主节点根目录 200G使用率冲到 93%告警频发。我先做摸底df -h确认是/满du定位到/var/log占了 70G、/opt/cloudera占了 50G、NameNode 元数据 30G剩下是系统和数据库。增长速率看监控历史月均约 12G。底层是云环境根盘支持在线扩容所以直接定方案原地扩到 400G。变更窗口选在业务低峰期虽然在线扩容理论上不停机但为了保险还是提前通知了相关方并准备了回滚预案——万一扩完文件系统有问题至少能快速切到备份节点。动手前先备份导出 CM 数据库到对象存储打包 NameNode 元数据目录到另一台机器。这两步做完心里才踏实。4.2 分步执行与现场验证第一步在云控制台把根盘从 200G 扩到 400G等待底层完成。完成后进系统lsblk一看磁盘是 400G 了但/dev/vda1还是 200G符合预期。第二步growpart /dev/vda 1扩分区再lsblk确认分区变成 400G。这一步很快几秒钟。第三步确认文件系统是 XFSdf -T /一看便知执行xfs_growfs /。命令跑完输出一堆信息最后df -h显示根目录 400G使用率降到 46%扩容成功。第四步验证服务。逐个检查 CM Server、NameNode、ZooKeeper 的状态确认都正常。再故意往根目录写个大文件测试写入没问题后删掉。整个操作从开始到确认完成不到半小时服务全程没停。这里有个细节值得说扩完分区后我没有立刻扩文件系统而是先lsblk确认分区表真的更新了。因为偶尔会遇到内核没重新读取分区表的情况这时候直接扩文件系统会报错。如果真遇到用partprobe让内核重新读一次分区表再继续。4.3 扩容后的收尾与监控调整扩容不是扩完就完事。我做了三件收尾工作一是把这次扩容记录进变更台账写清楚扩容前后的容量、操作步骤、验证结果方便以后追溯二是调整监控阈值原来根目录 85% 就告警现在容量大了把告警线设到 80%留出更充裕的响应时间三是顺手检查了日志轮转配置发现有几个组件的日志没配轮转补上配置从源头上减缓增长。这三件事看着琐碎但第二件和第三件其实是在治本。光扩容不治理增长源头过几个月又得再来一次运维不能总当救火队。5. 常见问题与排查技巧实录5.1 扩容后容量没变化的排查思路这是最高频的问题明明扩了盘df -h还是老样子。排查顺序我整理成了一张速查表现象可能原因排查命令解决磁盘大了但分区没变分区表未扩展lsblk、fdisk -lgrowpart扩分区分区大了但文件系统没变文件系统未 resizedf -T看类型按类型选 resize 命令命令报错设备忙分区表未重读partprobe重读后重试XFS 用 resize2fs 报错命令用错确认文件系统类型改用xfs_growfs扩完很快又满增长源头未治理du定位清理调轮转策略排查的核心逻辑就是逐层确认物理盘 → 分区 → 文件系统哪一层没跟上就补哪一层。别跳步也别假设。5.2 迁移目录后服务起不来的典型坑走新增磁盘方案时迁移完目录服务起不来是常见问题八成是权限或 SELinux 上下文的问题。rsync -a能保留普通权限但 SELinux 的安全上下文不一定能完整保留。如果系统开了 SELinux迁移后要用restorecon -Rv /目标目录恢复上下文否则服务读不到文件。另一个坑是挂载配置。新盘挂载要写进/etc/fstab但写的时候要用 UUID 而不是设备名因为设备名在重启后可能变。用blkid查 UUID写进 fstab 后用mount -a测试确认不报错再重启验证。我见过 fstab 写错导致机器起不来的那真是大事故。提示改 fstab 之前先cp /etc/fstab /etc/fstab.bak备份一份改完mount -a验证通过再放心。这个习惯能救你很多次。5.3 几个只有踩过才知道的经验第一个经验扩容前先看/etc/fstab里根目录是怎么挂的。如果是 LVM那扩容路径和普通分区完全不同得先pvcreate加物理卷、vgextend扩卷组、lvextend扩逻辑卷最后才 resize 文件系统。搞错布局直接上手 growpart会白忙活。第二个经验在线扩容虽然不停机但别在业务高峰期做。文件系统 resize 本身很快但期间 IO 会有短暂波动赶上业务高峰可能引发连锁反应。低峰期操作出问题也有缓冲时间。第三个经验扩容后一定要验证写入。df显示容量对了不代表真能写用dd往根目录写个几百兆的测试文件确认能正常写入再删掉这一步能提前发现文件系统层面的隐患。第四个经验把扩容和容量治理绑在一起做。每次扩容都是一次审视增长源头的机会顺手把日志轮转、审计清理、临时文件策略都检查一遍能显著延长下次扩容的周期。我现在的习惯是扩容必带一次增长源治理效果比单纯加盘好得多。这套流程走下来主节点根目录扩容这件事就从提心吊胆的救火变成了有章可循的常规操作。真正让我安心的从来不是扩容命令本身而是动手前的摸底、备份和动手后的验证、治理——这些看起来不直接产生结果的步骤才是让整个操作稳得住的关键。