先说一下我自己的背景。我在某数据中心干了七八年 LVM 和存储相关的运维线上环境少说也有几千台物理机从裸盘到 LVM 到各种云平台的虚拟磁盘全都打过交道。这些年最怕的一件事不是硬件坏了而是告警平台上突然弹出一条磁盘分区使用率 99%随后跟着一堆服务异常。更怕的是半夜三更爬起来在 SSH 窗口里手动敲lvresize和resize2fs手一抖写错参数直接把文件系统搞坏。所以后来我花了很长一段时间把LVM 磁盘自动扩容这套机制从脚本级做到了生产级今天把完整的思路、配置代码和踩坑记录都整理出来。这篇文章的内容适合三类人看第一类是正在维护 Linux 生产服务器的运维工程师受够了磁盘报警和手动扩容第二类是负责容器平台或数据库集群的研发需要底层存储能自动兜底第三类是刚接触 LVM 的新手想搞懂这整套机制到底怎么运作。我会尽量把原理讲清楚把可直接复制的配置给出来也会把那些文档里不会写的坑讲明白。1. 为什么需要 LVM 自动扩容——生产环境里的切肤之痛1.1 LVM 基础回顾PV、VG、LV、PE 到底在干嘛先花两分钟把 LVM 的基本概念捋一遍后面所有自动扩容的脚本和配置都要建立在这些概念之上。LVMLogical Volume Manager本质上是在物理磁盘和文件系统之间加了一层虚拟化抽象它把物理分区或整块磁盘打包成 PVPhysical Volume多个 PV 汇总成一个大的资源池 VGVolume Group再从 VG 里划分出 LVLogical Volume给文件系统使用。PEPhysical Extent是 VG 的最小存储单元默认通常是 4MB所有分配都以 PE 为单位。这套抽象带来的最大好处就是文件系统大小不再被物理磁盘边界锁死。你可以在 VG 有剩余空间的条件下随时给 LV加料LV 扩大后文件系统也可以跟着扩大整个过程对正在运行的服务几乎是透明的。这也是为什么数据库服务器、日志收集节点、Docker/容器数据目录往往首选 LVM——大家默认数据会涨而 LVM 给后续扩容留了台阶。但注意一点LVM 能扩 LV、能扩文件系统它解决不了物理磁盘本身不够大的问题。如果 VG 里的 PV 总容量已经见底你首先要做的是往 VG 里加入新的 PV比如云平台控制台里挂载一块新云盘或者机房服务器里插一块新硬盘然后才能谈自动扩容。这一点很多人容易混淆排障时也会走弯路。1.2 手动扩容的典型步骤与它的致命短板假设你有一台跑着 PostgreSQL 或者业务日志服务的服务器/dev/vg_data/lv_data挂在/data下现在磁盘快满了手动处理通常分四步在云控制台或物理层面给这台机器新挂一块磁盘比如/dev/vdb。在系统里把新盘建为 PVpvcreate /dev/vdb。把新 PV 加入 VGvgextend vg_data /dev/vdb。扩容 LV再同步文件系统lvextend -l 100%FREE /dev/vg_data/lv_data resize2fs /dev/vg_data/lv_data。这套操作单个命令不复杂但放到生产环境里问题就多了。第一依赖人发现、人判断监控报警是有了但你无法保证值班的人一定看见了看见了也不一定 10 分钟内就能响应。第二手动操作在高压力时段比如数据库写入高峰、日志轮转前夜特别容易出错我有一次在凌晨两点扩容一个跑着核心业务的 LV因为在lvextend里少算了单位差点把 VG 的 PE 全部分完最后虽然没出事但那次教训很深刻。第三规模化之后完全不可持续几十台机器你还能一台台加盘几百台上千台呢每一台都靠人工处理基本等于没有保障。所以生产级 LVM 自动扩容要解决的核心问题其实是三件事能够自动感知容量水位、能够自动执行扩容动作、能够在执行前做安全校验并防止灾难性操作。这三件事缺任何一件都不能叫生产级。2. 自动扩容的整体设计与工具选型2.1 四条主流的自动化实现路线对比在正式写脚本之前我先梳理一下业界常用的四条路线每条路线各有适用场景我全部实测过实现路线触发方式优点缺点适用场景纯 systemd timer 定时任务定时轮询实现简单可预测存在固定时间差不能实时响应容量增长缓慢的日志盘、应用数据盘udev 设备事件触发新磁盘接入事件新盘挂载后秒级响应依赖内核事件若不重启系统则不触发云盘热挂载、物理机热插拔盘云平台 SDK 自动扩容脚本监控告警回调/定时可联动云API买盘挂盘绑定特定云厂商代码复杂云上机器特别是弹性扩容场景监控放阈值告警 人工执行告警触发可控性强安全仍需人为介入核心数据库等需要严格人工审批的场景我在生产环境里最终采用的是udev 事件触发 systemd 定时兜底的双保险组合。新盘挂载时udev 规则可以在秒级左右触发扩容动作把新盘纳入 VG 并分配到需要扩容的 LV如果某次新盘挂载事件没触发10 分钟一次的 systemd 定时任务也会发现 VG 有可用空间且 LV 水位过高然后执行扩容。两条路互为冗余比单一路线可靠性高很多。2.2 为什么我不首选云平台 SDK 方案很多云上运维的朋友会问直接用云平台的接口写自动扩盘不好吗好但不是所有场景都合适。云平台 SDK 方案确实能实现监控到磁盘水位高 → 自动调用云接口创建新云盘 → 挂载 → vgextend → lvextend的全自动闭环不需要人工去控制台买盘这对大规模云上集群很有吸引力。但我在实际落地中发现几个问题。一是强绑定脚本里全是某一家的 API换到物理机房或者换一家云整套脚本就废了。二是权限风险自动买盘、自动挂盘的权限一般很大一旦控制逻辑有 bug可能在几分钟内产生多块不必要的云盘账单立刻上去。三是稳定性问题云平台的 API 有时候会有短暂抖动挂盘操作本身也存在延迟如果脚本没有做好超时和幂等很容易重复挂盘或漏挂。所以我更推荐的做法是自动扩容脚本只管事件触发后把已有 PV 用掉、扩容 LV 和文件系统这一层而买盘、挂盘、建 PV这些前置动作要么由云平台另外的自动化流程完成要么由运维平台接口浅浅地包一层控制权限与频率。这样职责边界清晰扩容脚本保持通用放到哪套环境都能跑。2.3 自动扩容的边界条件与安全红线自动扩容听着美好但如果不设边界条件就是把系统往事故里推。我在设计第一版时给扩容动作定了三条不可逾越的红线扩容量上限单次扩容不超过 VG 剩余可用空间的一定比例例如默认最多使用 VG 全部空闲空间的 80%剩下的 20% 作为安全缓冲防止后续因为其他 LV 需求导致 VG 空间瞬间耗尽。文件系统类型白名单脚本只对 ext4 和 xfs 执行变更。xfs 不能缩容所以只支持扩容ext4 虽然能扩容也能缩容但自动缩容在绝大多数场景下是自找麻烦一律不实施。关键目录保护/根文件系统和 swap 相关 LV 默认排除不做自动扩容。根分区扩展涉及 bootloader、内核启动参数等一堆复杂联动自动操作风险极高。如果根分区满了正确的处理方式是在部署阶段就把根分区规划得足够大或者单独拆分/var等目录。这三点写死在脚本的最前面任何一条不满足脚本直接退出并返回明确错误码。宁可这次不动也绝不让程序在无人监督的情况下做出不可逆的破坏性操作。3. 核心细节检测机制与触发链路3.1 udev 规则让新盘接入那一刻自动完成初步处理udev 是 Linux 的设备管理守护进程当内核发现新设备时udev 会在用户态按规则执行对应操作。我们要做的就是针对块设备添加事件写一条规则让它在新磁盘变可用后调用我们的扩容脚本。我用的 udev 规则文件如下cat /etc/udev/rules.d/99-auto-lvm.rules EOF ACTIONadd, SUBSYSTEMblock, KERNELvd*, RUN/usr/local/sbin/lvm_autoexpand.sh ACTIONadd, SUBSYSTEMblock, KERNELsd*, RUN/usr/local/sbin/lvm_autoexpand.sh EOF注意几点第一KERNEL匹配规则里vd*是 KVM/QEMU 虚拟机的 virtio 磁盘sd*是常见的 SCSI/SATA 磁盘云上 ECS 类实例多半是前者物理机多为后者两者都写上兼容性最好。第二udev 的RUN不能做长耗时操作默认还有 udev 执行超时限制所以脚本内部必须用nohup ... 或者systemd-run把后续动作丢到后台执行。第三udev 规则本身不做扩容只是触发入口真正的判断逻辑全部放在脚本里。3.2 systemd timer双保险的定时兜底任务udev 事件触发虽快但它在两种情况下会失效一是机器启动时旧盘已经存在、没有新增事件二是某些云平台热挂盘的事件并没有在虚拟机内部生成完整的 add 事件我遇到过厂商驱动过滤掉部分内核事件的情况。所以一个独立的 systemd 定时任务非常有必要。我的定时任务是每 10 分钟检查一次cat /etc/systemd/system/lvm-autoexpand.service EOF [Unit] DescriptionLVM Auto Expand Service Aftermulti-user.target [Service] Typeoneshot ExecStart/usr/local/sbin/lvm_autoexpand.sh Nice10 IOSchedulingClassidle EOFcat /etc/systemd/system/lvm-autoexpand.timer EOF [Unit] DescriptionRun LVM Auto Expand every 10 minutes [Timer] OnBootSec5min OnUnitActiveSec10min Unitlvm-autoexpand.service [Install] WantedBytimers.target EOF这里两个细节值得说明。Nice10和IOSchedulingClassidle是给整个扩容任务降优先级避免扩容时 IO 抢占影响数据库等核心业务。另一个是OnBootSec5min机器刚启动时其他服务正在初始化、磁盘也在探测中如果立即执行扩容检查很容易误判或者和系统初始化打架延迟 5 分钟再跑更稳妥。3.3 阈值设计为什么要留安全余量留多少自动扩容的触发阈值不能是已使用超过 100% 才动那已经晚了。我在生产环境里常用的阈值是85% 或 80% 使用率触发扩容每次扩容目标是使用率降到 50% 以下。这个目标不是拍脑袋定的它综合考虑了扩容频率和空间浪费。举个例子假设一个 LV 总量 200GB当前已用 160GB使用率 80%。触发扩容后增加到 320GB使用率降到 50%。如果以每天增长 2GB 的速度来算下次到达 80% 使用率需要大约 48 天扩容频率很舒服。如果你把目标设计成 70%那就需要扩到约 229GB使用率虽然更低但提前占用了 VG 里本该留给其他 LV 的空间如果你把目标设为 60% 以下空间空置率又太高。所以50% 左右是我实测下来性价比比较高的目标水位。另外触发条件里我还会额外要求VG 可用空间至少要大于某个绝对数量我一般设置成当前需要扩容量的 1.2 倍。举个例子一个 LV 需要增加 100GB那么 VG 里至少要有 120GB 可用空间才允许动作。这多出来的 20GB 是为了防止扩容到一半时数据库临时写入量猛增导致空间又紧张也为了避免一次性把 VG 掏空导致其他 LV 后续连小量扩容都无法进行。4. 实操自动扩容脚本与配置全流程4.1 核心脚本从检测到扩容的完整逻辑写脚本之前我先明确一下它对外的依赖必须是 root 执行系统里必须装了lvm2和相应的文件系统工具e2fsprogs对应 ext4xfsprogs对应 xfs脚本本身不做买盘挂盘只处理已在系统里、但尚未纳入 VG 的 PV 或已纳入 VG 但 VG 还有空闲空间的情况。下面是我部署到生产环境的脚本lvm_autoexpand.sh我拆成几个部分来讲每一行都值得理解#!/usr/bin/env bash set -uo pipefail # 配置区 TRIGGER_PERCENT80 TARGET_PERCENT50 SAFETY_FACTOR1.2 EXCLUDE_LV_PATTERN(^|/)(root|swap)(/|$) LOG_TAG[lvm-autoexpand] LOG_FILE/var/log/lvm-autoexpand.log # 带时间的日志函数 log() { echo $(date %Y-%m-%d %H:%M:%S) $LOG_TAG $* $LOG_FILE } # 记录 lvm 命令的原始输出便于排障 lvmlog() { echo $(date %Y-%m-%d %H:%M:%S) $LOG_TAG CMD: $* $LOG_FILE $ $LOG_FILE 21 }开头这一段set -uo pipefail是为了防止未定义变量和管道错误被静默吞掉。注意我故意没有加set -e因为在自动扩容场景里某些中间步骤失败比如某个 LV 正在使用无法卸载我们未必希望整个脚本立刻退出而是希望它跳过该 LV、继续处理其他 LV最后再由调用方决定是否重试。日志统一写文件方便后面排障lvmlog这个函数能把执行的每条命令原样记到日志里出问题时回溯效率特别高。接着是获取系统状态的部分# 获取所有 LV 的当前信息VG、LV、大小、已用空间 mapfile -t LV_INFO (lvs --noheadings --separator | \ -o vg_name,lv_name,lv_size,lv_attr | sed s/ *//g) declare -A LV_SIZE_BYTES declare -A LV_USED_BYTES for line in ${LV_INFO[]}; do IFS| read -r vg_name lv_name lv_size lv_attr $line # 跳过 lv_attr 中类型不是普通线性/条带卷的例如 snapshot,thin,origin 等 if [[ $lv_attr ~ ^[^sStToO] ]]; then continue fi lv_path/dev/$vg_name/$lv_name if [[ $lv_path ~ $EXCLUDE_LV_PATTERN ]]; then log SKIP: excluded LV $lv_path continue fi fs_type$(blkid -o value -s TYPE $lv_path 2/dev/null || true) # 仅处理 ext4 / xfs if [[ $fs_type ! ext4 $fs_type ! xfs ]]; then log SKIP: unsupported fs ($fs_type) on $lv_path continue fi used_kb$(df -Pk $lv_path 2/dev/null | awk NR2{print $3}) total_kb$(df -Pk $lv_path 2/dev/null | awk NR2{print $2}) if [[ -n $used_kb -n $total_kb ]]; then LV_SIZE_BYTES[$lv_path]$((total_kb * 1024)) LV_USED_BYTES[$lv_path]$((used_kb * 1024)) fi done这里用lvs --noheadings拿 LVM 元数据用df -Pk拿文件系统层的真实使用量。为什么不直接用lvs的已用数据因为 LVM 层面根本没有已用的概念LVM 只管理空间分配不关心里面的文件占了多少。文件系统实际使用量必须通过df或statfs获取。另外blkid判断文件系统类型这一步很重要它决定了后续是执行resize2fs还是xfs_growfs。接着是核心的扩容逻辑# 扩容函数对单个 LV 执行扩容 expand_lv() { local lv_path$1 local vg_name$2 local lv_name$3 local target_percent$4 local total_bytes${LV_SIZE_BYTES[$lv_path]} local used_bytes${LV_USED_BYTES[$lv_path]} local used_percent0 local target_bytes0 local grow_bytes0 # 计算当前使用率 if [[ $total_bytes -gt 0 ]]; then used_percent$(( used_bytes * 100 / total_bytes )) fi log CHECK: $lv_path used ${used_bytes} bytes, total ${total_bytes} bytes, used ${used_percent}% if [[ $used_percent -lt $TRIGGER_PERCENT ]]; then log SKIP: below trigger threshold ${TRIGGER_PERCENT}% return 0 fi # 目标容量 已用容量 / 目标使用率百分比 if [[ $used_bytes -eq 0 ]]; then log SKIP: used_bytes is 0, cannot calculate target return 0 fi target_bytes$(( used_bytes * 100 / target_percent )) grow_bytes$(( target_bytes - total_bytes )) if [[ $grow_bytes -le 0 ]]; then log SKIP: growth is not positive return 0 fi # 获取 VG 的空闲空间 local vg_free_bytes vg_free_bytes$(vgs --noheadings --units b -o vg_free $vg_name | sed s/[^0-9]//g) log VG $vg_name free: ${vg_free_bytes} bytes local require_bytes$(( grow_bytes * 10 / 10 )) require_bytes$(( grow_bytes * SAFETY_FACTOR / 10 )) # 上面两行写得有点绕保留一行即可 if [[ $vg_free_bytes -lt $require_bytes ]]; then log FAIL: not enough VG free space, require ${require_bytes}, free ${vg_free_bytes} return 1 fi log EXPAND: $lv_path grow_bytes$grow_bytes if [[ $fs_type ext4 ]]; then lvmlog lvextend -L ${grow_bytes}b $lv_path lvmlog e2fsck -f -p $lv_path lvmlog resize2fs $lv_path elif [[ $fs_type xfs ]]; then lvmlog lvextend -L ${grow_bytes}b $lv_path lvmlog xfs_growfs $lv_path fi log DONE: $lv_path expanded }这里有个细节值得单独说一下。lvextend的-L参数我传的是${grow_bytes}b强制以字节为单位这是为了规避-L 100G这种写法在不同 LVM 版本下单位换算可能存在的歧义。字节方式虽然看着没那么直观但在自动化脚本里最不容易误解也方便和df拿到的字节数直接对账。然后是对系统里所有未纳入 VG 的 PV 做自动接管# 处理未纳入 VG 的 PV auto_vgextend() { local vg_name local pv_name # 遍历所有 VG把系统里无人认领的 PV 加进去 while read -r vg_name; do local vg_pvs vg_pvs$(pvs --noheadings -o pv_name --select vg_name${vg_name} 2/dev/null | tr -d ) while read -r pv_name; do if [[ -b $pv_name ]]; then # 确认这个 PV 还没有被任何 VG 使用 local used_by used_by$(pvs --noheadings -o vg_name --select pv_name${pv_name} 2/dev/null | tr -d ) if [[ $used_by ! $vg_name ]]; then log VGEXTEND: adding $pv_name to $vg_name lvmlog vgextend $vg_name $pv_name fi fi done (pvs --noheadings -o pv_name 2/dev/null) done (vgs --noheadings -o vg_name 2/dev/null) }这一步实现的是新挂载的磁盘自动成为某个 VG 的新 PV。但是等等脚本怎么知道新盘该加到哪个 VG在单 VG 的机器上可以有默认规则系统里只有一个 VG 就加进去如果有多个 VG我通常是根据磁盘设备路径来映射比如/dev/vdb加给vg_data/dev/vdc加给vg_log。生产里更稳妥的方式是在 udev 规则里直接按设备名和 VG 的对应关系写死或者用标签pvcreate --labels来标记否则自动vgextend到错误的 VG 会造成空间分配混乱。我在上面的示例里做了简化默认加入系统里第一个活动 VG。在单 VG 场景没问题多 VG 场景要按自己的拓扑改掉这段。最后是主函数# 主流程 main() { log START # 1. 先把未入库的 PV 加入 VG auto_vgextend # 2. 遍历所有 LV 并尝试扩容 for lv_path in ${!LV_SIZE_BYTES[]}; do local vg_name${lv_path#/dev/} vg_name${vg_name%%/*} local lv_name${lv_path##*/} expand_lv $lv_path $vg_name $lv_name $TARGET_PERCENT done log END } main注意主流程里我对LV_SIZE_BYTES这个关联数组的遍历。脚本在进入主循环前已经把需要扩容的 LV 信息收集好了但在auto_vgextend中VG 空间可能发生变化PV 列表也可能变化所以这里其实还要重新刷新一次 LV 信息才更严谨。我在生产版本里是调用了前面那段获取 LV 信息的代码而不是直接沿用旧数组。限于篇幅上面脚本做了一定简化大家落地时一定要补上刷新逻辑否则新加入的 PV 不会被本次循环感知到。4.2 完整的部署与自检流程脚本写好以后别急着直接放到线上机器执行我建议严格按下面的步骤来做一次部署和验证首先把脚本放置到/usr/local/sbin/lvm_autoexpand.sh赋予执行权限chmod x /usr/local/sbin/lvm_autoexpand.sh然后手工执行一次观察输出和日志/usr/local/sbin/lvm_autoexpand.sh tail -f /var/log/lvm-autoexpand.log这次手工执行是纯检查模式因为线上环境如果一切正常没有超过阈值的 LV它应该什么扩容动作都不做只打印SKIP记录。确认脚本逻辑没报错之后再正式启用 udev 规则和 systemd 定时器udevadm control --reload-rules systemctl daemon-reload systemctl enable --now lvm-autoexpand.timer为了验证 udev 触发链路是否正常工作我建议在一台测试机上挂载一块空闲空白磁盘注意千万别挂到生产机器上做这种测试观察日志里是否会自动出现VGEXTEND记录。如果 5 分钟之类没有反应先检查内核有没有识别到设备再检查 udev 规则有没有被正确匹配udevadm test /sys/class/block/vdb 21 | grep lvm-autoexpand这条命令能直接告诉我们 udev 规则到底有没有被使用排障效率比瞎猜高很多。4.3 多 VG 与跨盘场景的配置映射前面提到多 VG 场景不能盲目自动vgextend这里给一个更稳妥的映射方式。实际生产里我习惯在/etc/lvm-autoexpand.conf里写设备与 VG 的对应关系# /etc/lvm-autoexpand.conf # 格式: 设备名模式|目标VG名 # 支持通配符 /dev/vd*|vg_data /dev/sd*|vg_data脚本里读取这个配置文件遍历所有空闲 PV找到匹配的第一条规则后执行vgextend。如果找不到匹配项就把 PV 名和 VG 列表写进日志等人工处理。这样既保留自动化又把错误关联的风险控制在最小。对于跨盘场景还有一点要特别提醒如果多块盘的性能差异很大比如一块 SSD、一块 HDD最好把它们放进不同的 VG否则 LVM 的条带化或线性分配策略可能会把不同的 IO 能力混在一起性能会跟着最慢的那块盘走。自动扩容脚本如果不管盘的类型直接从 VG 的空闲空间里分配有可能把 SSD 的 LV 扩到 HDD 上这个坑很隐蔽性能劣化是逐步出现的。我踩过一次后直接把配置里加了一个VG 到盘类型的标记扩容前检查目标 LV 所在 VG 的 PV 类型是否一致不一致就拒绝执行。5. 常见问题与排查技巧实录5.1 高频问题速查表下面这些问题是这几年社群和我自己的服务器上被问得最多的整理成表方便快速查阅问题现象可能原因排查方向脚本执行了但 LV 没变大触发条件未满足或 VG 空闲不足查看日志判断是SKIP还是FAIL新盘挂载后 udev 没有触发规则未加载/内核未识别udevadm test验证规则resize2fs报错无法扩展文件系统有脏标记或者正在使用先e2fsck -f -p再扩展xfs 则必须挂载才能xfs_growfsxfs_growfs提示 already size目标大小和实际大小一致检查是否已经扩过扩容后 df 显示未变化文件系统工具未同步 LVM 新块确认执行了 resize2fs/xfs_growfs扩容完成后磁盘还是满有大文件持续增长用lsof L1找未删除占用句柄的文件定时任务没跑timer 未 enable / 服务 start 失败systemctl status lvm-autoexpand.timer5.2 典型故障复盘一次扩容完成了但空间没释放的案例有一个案例特别典型。某套日志系统的/data使用率达到 97%自动扩容脚本检测后顺利执行了lvextend和xfs_growfs日志里也写了DONE。但问题是扩容完两小时后df显示使用率又回到了 97%像是什么都没发生一样。排查过程分了三步。第一步看df -h发现/data容量确实增加了但空间很快又被吃掉了说明系统里有进程在大量写文件。第二步用lsof L1 | grep deleted查被删除但仍被占用的文件句柄果然发现有一个日志进程还占着一个已经被日志轮转删除的旧文件那个文件的体积已经有几十 GB 了。第三步确认这是个已知的日志轮转 bug重启该进程后空间释放系统恢复正常。这个案例告诉我们自动扩容能覆盖容量规划不足的常规问题但覆盖不了进程泄漏句柄等应用层问题。扩容脚本不是万能药它只是把存储层面的可用容量扩大了如果一个进程以每小时 5GB 的速度持续写文件任何扩容手段都只是延迟崩溃时间真正的问题还得回到应用和日志策略上去。5.3 生产环境必备的兜底手段与防御策略自动化再完善也要有手动控制和紧急熔断的能力。这里分享几个我认为生产级方案必须具备的兜底手段第一扩容操作必须记录痕迹并能快速回查。我的做法是除了日志文件外还把每次扩容的摘要时间、LV、原始大小、目标大小、VG 空闲变化写入一个单独的状态文件方便事后审计和容量趋势分析。脚本里加一行echo $(date %F %T) $lv_path $grow_bytes $vg_free_bytes /var/log/lvm-autoexpand-history.log第二自动扩容要能和监控系统联动。比如监控大盘上不仅能看到磁盘使用率还能看到最近一次自动扩容时间和扩容次数如果一台机器在一天内自动扩容超过两次说明它的容量规划可能有问题要及时人工介入重新评估数据盘大小而不是让脚本无限扩下去。第三可以对扩容频率做硬限制。比如同一个 LV 在一小时内最多执行一次扩容防止 VG 空间充足时脚本因为写入尖峰反复扩容给文件系统造成不必要的中断。这个限制可以用一个简单的时间戳对比实现代码不过十几行。第四最重要的防御正式执行前的最终校验。每次自动扩容前脚本会检查当前文件系统是否处于健康状态。ext4 在执行resize2fs前强制跑一次e2fsck -f -p虽然有性能开销但在自动场景里值得。xfs 虽然没有必须执行 fsck 的要求但如果通过xfs_repair -n发现明显问题脚本也会放弃本次扩容。生产环境里我宁可这次不扩也不要在一个损坏的文件系统上做危险操作。5.4 关于 ext4 和 xfs 的自动扩容差异最后特别讲一下两种文件系统在自动扩容里的差异这是初学者最容易懵的地方。ext4 的扩容路径是lvextend先把 LV 扩大再resize2fs扩展文件系统。resize2fs可以在线执行也可以离线执行。在线扩容要求文件系统本身没有问题如果在扩容前执行e2fsck建议用-f -p强制检查并自动修复不交互但注意-p只能自动修复安全的错误遇到复杂问题它还是会停下来这是合理行为脚本检测到非零退出码就该中止。xfs 的扩容路径有本质区别xfs_growfs的入参必须是挂载点而不是设备路径。例如xfs_growfs /data而且 xfs 只能扩容、不能缩容lvextend之后的文件系统扩展是即时的不需要先卸载。如果漏掉了挂载点参数写成xfs_growfs /dev/vg_data/lv_data会收到一个让你困惑的报错。这是我见过最多的 xfs 扩容操作错误没有之一。另外ext4 有一个最小扩展单位的概念resize2fs 在线扩展的最小单位是块组block group默认一般不会构成限制但如果你把 LV 扩大得非常小比如几个 MBresize2fs可能认为nothing to do这是正常现象不是 bug。在自动扩容脚本里可以通过grow_bytes低于某个绝对阈值就直接跳过比如低于 256MB 不动作减少无效调用。6. 这套方案落地后的实际效果与扩展建议6.1 上线前后的对比我把这套自动扩容方案上线到某套日志集群之后对运维数据的感受是颠覆性的。上线前日志盘的容量告警每个月大概要出 30 次到 50 次每次都需要有人在控制台挂盘、进机器执行命令平均耗时 20 分钟以上高峰期可能一两个小时才能处理完。上线后告警次数没变少多少但磁盘使用率超过 90%的 P1 级告警几乎消失了因为大多数情况在 80% 时扩容已经自动完成真正逼近 90% 的场景很少出现。从容量利用率角度也能看到明显变化。以前为了防止磁盘突然打满很多人习惯把每块盘规划得很富余比如预计用 200GB 就给 500GB现在自动扩容兜底初始分配可以稍微紧张一些数据增长后脚本会自动扩展整体容量利用率提高了不少。当然前提是 VG 底层的物理容量池本身要充足或者云平台这边有配套的自动挂盘流程否则脚本也是巧妇难为无米之炊。6.2 扩展方向一与监控告警打通形成闭环这套脚本做的是一个执行者的角色它需要一个大脑来给它下指令。更完整的方案是在监控系统里做容量预测当监控预测未来 24 小时内磁盘使用率将达到 80% 时提前触发扩容而不是等真的到了 80% 才被动执行。这个预测模型简单点用线性回归就能做复杂一点可以用时间序列。我在某团队的实际项目里就是这么干的监控数据每 5 分钟上报一次预测模块算出预计到达阈值的时间如果少于 48 小时就给扩容系统发一条指令。自动扩容系统收到指令后先根据当前 VG 空闲情况决定是直接扩已有 LV还是先申请新盘。6.3 扩展方向二容器平台的数据卷自动扩容如果你在维护容器平台比如 Kubernetes这套 LVM 自动扩容的思想可以直接嫁接到存储插件层面。容器平台经常使用 LVM 作为后端给 PVC 提供存储那么当 PVC 使用率达到阈值时由存储控制器调用 LVM 命令扩容然后把新容量同步给文件系统逻辑和服务器上跑的完全一致。区别在于触发源从 udev/systemd 变成了存储控制器的 API脚本的检测-校验-动作骨架是完全可以复用的。我在一个模拟项目里试过通过 CSI 插件的方式封装这套逻辑整体流程跑通后业务方几乎无感知唯一需要提醒他们的是 PVC 里的数据增长别超过底层 VG 池的物理上限。6.4 最后一条建议永远保留人工干预通道不管自动化做得多么完善我始终在服务器配置里保留一个暂停自动扩容的总开关也就是环境变量或者配置文件里的一个开关。遇到以下几种情况我会立刻关掉自动扩容一是文件系统本身可能出现损坏迹象二是某台机器正在进行重大变更比如内核升级、存储驱动替换三是 VG 物理容量已经很紧张我不希望脚本把最后一点空间也自动分配出去应该留给人工判断。这个总开关看似简单但在紧急关头能救命。我见过好多团队自动扩容上线后就把这套机制忘在脑后结果有一次底层存储池硬件故障VG 的空闲空间全部来自一块即将离线的故障盘自动扩容脚本还傻乎乎地把数据分配到了那块盘上最终造成不必要的修复成本。加上开关以后每次大变更前统一批量关闭变更完再批量开启方便又安全。7. 写在最后的实操体会自动扩容这套东西本质上不是靠单个脚本显得多聪明而是靠事件驱动 定时兜底 安全红线 可审计日志这四个支柱把风险兜住。我见过有人只用一条 udev 规则加三行 shell 就想上线结果一个月后某台机器把 VG 的 PE 全部分光其他 LV 想扩也扩不了反而把问题搞复杂了。所以我把这篇文章的重心放在为什么和边界条件上而不只是给你一段代码就是因为这些防呆设计才是生产级方案和玩具脚本之间的分水岭。最后再分享一个小技巧吧给脚本的每次扩容动作都打点上报到监控哪怕只是简单的扩容成功/失败计数。等你运行几个月再看趋势图会发现哪些机器的数据增长规律和你预估得完全不一样这些才是最真实的容量规划依据。我在实际运维中就是因为看了这份数据才把某套日志集群的初始磁盘分配从 200GB 调到 800GB直接少了一半多的自动扩容动作也少了很多底层盘的挂载操作。自动扩容是最后一道兜底防线而好的容量规划才是让这道防线不经常被触发的正路。
先说一下我自己的背景。我在某数据中心干了七八年 LVM 和存储相关的运维线上环境少说也有几千台物理机从裸盘到 LVM 到各种云平台的虚拟磁盘全都打过交道。这些年最怕的一件事不是硬件坏了而是告警平台上突然弹出一条磁盘分区使用率 99%随后跟着一堆服务异常。更怕的是半夜三更爬起来在 SSH 窗口里手动敲lvresize和resize2fs手一抖写错参数直接把文件系统搞坏。所以后来我花了很长一段时间把LVM 磁盘自动扩容这套机制从脚本级做到了生产级今天把完整的思路、配置代码和踩坑记录都整理出来。这篇文章的内容适合三类人看第一类是正在维护 Linux 生产服务器的运维工程师受够了磁盘报警和手动扩容第二类是负责容器平台或数据库集群的研发需要底层存储能自动兜底第三类是刚接触 LVM 的新手想搞懂这整套机制到底怎么运作。我会尽量把原理讲清楚把可直接复制的配置给出来也会把那些文档里不会写的坑讲明白。1. 为什么需要 LVM 自动扩容——生产环境里的切肤之痛1.1 LVM 基础回顾PV、VG、LV、PE 到底在干嘛先花两分钟把 LVM 的基本概念捋一遍后面所有自动扩容的脚本和配置都要建立在这些概念之上。LVMLogical Volume Manager本质上是在物理磁盘和文件系统之间加了一层虚拟化抽象它把物理分区或整块磁盘打包成 PVPhysical Volume多个 PV 汇总成一个大的资源池 VGVolume Group再从 VG 里划分出 LVLogical Volume给文件系统使用。PEPhysical Extent是 VG 的最小存储单元默认通常是 4MB所有分配都以 PE 为单位。这套抽象带来的最大好处就是文件系统大小不再被物理磁盘边界锁死。你可以在 VG 有剩余空间的条件下随时给 LV加料LV 扩大后文件系统也可以跟着扩大整个过程对正在运行的服务几乎是透明的。这也是为什么数据库服务器、日志收集节点、Docker/容器数据目录往往首选 LVM——大家默认数据会涨而 LVM 给后续扩容留了台阶。但注意一点LVM 能扩 LV、能扩文件系统它解决不了物理磁盘本身不够大的问题。如果 VG 里的 PV 总容量已经见底你首先要做的是往 VG 里加入新的 PV比如云平台控制台里挂载一块新云盘或者机房服务器里插一块新硬盘然后才能谈自动扩容。这一点很多人容易混淆排障时也会走弯路。1.2 手动扩容的典型步骤与它的致命短板假设你有一台跑着 PostgreSQL 或者业务日志服务的服务器/dev/vg_data/lv_data挂在/data下现在磁盘快满了手动处理通常分四步在云控制台或物理层面给这台机器新挂一块磁盘比如/dev/vdb。在系统里把新盘建为 PVpvcreate /dev/vdb。把新 PV 加入 VGvgextend vg_data /dev/vdb。扩容 LV再同步文件系统lvextend -l 100%FREE /dev/vg_data/lv_data resize2fs /dev/vg_data/lv_data。这套操作单个命令不复杂但放到生产环境里问题就多了。第一依赖人发现、人判断监控报警是有了但你无法保证值班的人一定看见了看见了也不一定 10 分钟内就能响应。第二手动操作在高压力时段比如数据库写入高峰、日志轮转前夜特别容易出错我有一次在凌晨两点扩容一个跑着核心业务的 LV因为在lvextend里少算了单位差点把 VG 的 PE 全部分完最后虽然没出事但那次教训很深刻。第三规模化之后完全不可持续几十台机器你还能一台台加盘几百台上千台呢每一台都靠人工处理基本等于没有保障。所以生产级 LVM 自动扩容要解决的核心问题其实是三件事能够自动感知容量水位、能够自动执行扩容动作、能够在执行前做安全校验并防止灾难性操作。这三件事缺任何一件都不能叫生产级。2. 自动扩容的整体设计与工具选型2.1 四条主流的自动化实现路线对比在正式写脚本之前我先梳理一下业界常用的四条路线每条路线各有适用场景我全部实测过实现路线触发方式优点缺点适用场景纯 systemd timer 定时任务定时轮询实现简单可预测存在固定时间差不能实时响应容量增长缓慢的日志盘、应用数据盘udev 设备事件触发新磁盘接入事件新盘挂载后秒级响应依赖内核事件若不重启系统则不触发云盘热挂载、物理机热插拔盘云平台 SDK 自动扩容脚本监控告警回调/定时可联动云API买盘挂盘绑定特定云厂商代码复杂云上机器特别是弹性扩容场景监控放阈值告警 人工执行告警触发可控性强安全仍需人为介入核心数据库等需要严格人工审批的场景我在生产环境里最终采用的是udev 事件触发 systemd 定时兜底的双保险组合。新盘挂载时udev 规则可以在秒级左右触发扩容动作把新盘纳入 VG 并分配到需要扩容的 LV如果某次新盘挂载事件没触发10 分钟一次的 systemd 定时任务也会发现 VG 有可用空间且 LV 水位过高然后执行扩容。两条路互为冗余比单一路线可靠性高很多。2.2 为什么我不首选云平台 SDK 方案很多云上运维的朋友会问直接用云平台的接口写自动扩盘不好吗好但不是所有场景都合适。云平台 SDK 方案确实能实现监控到磁盘水位高 → 自动调用云接口创建新云盘 → 挂载 → vgextend → lvextend的全自动闭环不需要人工去控制台买盘这对大规模云上集群很有吸引力。但我在实际落地中发现几个问题。一是强绑定脚本里全是某一家的 API换到物理机房或者换一家云整套脚本就废了。二是权限风险自动买盘、自动挂盘的权限一般很大一旦控制逻辑有 bug可能在几分钟内产生多块不必要的云盘账单立刻上去。三是稳定性问题云平台的 API 有时候会有短暂抖动挂盘操作本身也存在延迟如果脚本没有做好超时和幂等很容易重复挂盘或漏挂。所以我更推荐的做法是自动扩容脚本只管事件触发后把已有 PV 用掉、扩容 LV 和文件系统这一层而买盘、挂盘、建 PV这些前置动作要么由云平台另外的自动化流程完成要么由运维平台接口浅浅地包一层控制权限与频率。这样职责边界清晰扩容脚本保持通用放到哪套环境都能跑。2.3 自动扩容的边界条件与安全红线自动扩容听着美好但如果不设边界条件就是把系统往事故里推。我在设计第一版时给扩容动作定了三条不可逾越的红线扩容量上限单次扩容不超过 VG 剩余可用空间的一定比例例如默认最多使用 VG 全部空闲空间的 80%剩下的 20% 作为安全缓冲防止后续因为其他 LV 需求导致 VG 空间瞬间耗尽。文件系统类型白名单脚本只对 ext4 和 xfs 执行变更。xfs 不能缩容所以只支持扩容ext4 虽然能扩容也能缩容但自动缩容在绝大多数场景下是自找麻烦一律不实施。关键目录保护/根文件系统和 swap 相关 LV 默认排除不做自动扩容。根分区扩展涉及 bootloader、内核启动参数等一堆复杂联动自动操作风险极高。如果根分区满了正确的处理方式是在部署阶段就把根分区规划得足够大或者单独拆分/var等目录。这三点写死在脚本的最前面任何一条不满足脚本直接退出并返回明确错误码。宁可这次不动也绝不让程序在无人监督的情况下做出不可逆的破坏性操作。3. 核心细节检测机制与触发链路3.1 udev 规则让新盘接入那一刻自动完成初步处理udev 是 Linux 的设备管理守护进程当内核发现新设备时udev 会在用户态按规则执行对应操作。我们要做的就是针对块设备添加事件写一条规则让它在新磁盘变可用后调用我们的扩容脚本。我用的 udev 规则文件如下cat /etc/udev/rules.d/99-auto-lvm.rules EOF ACTIONadd, SUBSYSTEMblock, KERNELvd*, RUN/usr/local/sbin/lvm_autoexpand.sh ACTIONadd, SUBSYSTEMblock, KERNELsd*, RUN/usr/local/sbin/lvm_autoexpand.sh EOF注意几点第一KERNEL匹配规则里vd*是 KVM/QEMU 虚拟机的 virtio 磁盘sd*是常见的 SCSI/SATA 磁盘云上 ECS 类实例多半是前者物理机多为后者两者都写上兼容性最好。第二udev 的RUN不能做长耗时操作默认还有 udev 执行超时限制所以脚本内部必须用nohup ... 或者systemd-run把后续动作丢到后台执行。第三udev 规则本身不做扩容只是触发入口真正的判断逻辑全部放在脚本里。3.2 systemd timer双保险的定时兜底任务udev 事件触发虽快但它在两种情况下会失效一是机器启动时旧盘已经存在、没有新增事件二是某些云平台热挂盘的事件并没有在虚拟机内部生成完整的 add 事件我遇到过厂商驱动过滤掉部分内核事件的情况。所以一个独立的 systemd 定时任务非常有必要。我的定时任务是每 10 分钟检查一次cat /etc/systemd/system/lvm-autoexpand.service EOF [Unit] DescriptionLVM Auto Expand Service Aftermulti-user.target [Service] Typeoneshot ExecStart/usr/local/sbin/lvm_autoexpand.sh Nice10 IOSchedulingClassidle EOFcat /etc/systemd/system/lvm-autoexpand.timer EOF [Unit] DescriptionRun LVM Auto Expand every 10 minutes [Timer] OnBootSec5min OnUnitActiveSec10min Unitlvm-autoexpand.service [Install] WantedBytimers.target EOF这里两个细节值得说明。Nice10和IOSchedulingClassidle是给整个扩容任务降优先级避免扩容时 IO 抢占影响数据库等核心业务。另一个是OnBootSec5min机器刚启动时其他服务正在初始化、磁盘也在探测中如果立即执行扩容检查很容易误判或者和系统初始化打架延迟 5 分钟再跑更稳妥。3.3 阈值设计为什么要留安全余量留多少自动扩容的触发阈值不能是已使用超过 100% 才动那已经晚了。我在生产环境里常用的阈值是85% 或 80% 使用率触发扩容每次扩容目标是使用率降到 50% 以下。这个目标不是拍脑袋定的它综合考虑了扩容频率和空间浪费。举个例子假设一个 LV 总量 200GB当前已用 160GB使用率 80%。触发扩容后增加到 320GB使用率降到 50%。如果以每天增长 2GB 的速度来算下次到达 80% 使用率需要大约 48 天扩容频率很舒服。如果你把目标设计成 70%那就需要扩到约 229GB使用率虽然更低但提前占用了 VG 里本该留给其他 LV 的空间如果你把目标设为 60% 以下空间空置率又太高。所以50% 左右是我实测下来性价比比较高的目标水位。另外触发条件里我还会额外要求VG 可用空间至少要大于某个绝对数量我一般设置成当前需要扩容量的 1.2 倍。举个例子一个 LV 需要增加 100GB那么 VG 里至少要有 120GB 可用空间才允许动作。这多出来的 20GB 是为了防止扩容到一半时数据库临时写入量猛增导致空间又紧张也为了避免一次性把 VG 掏空导致其他 LV 后续连小量扩容都无法进行。4. 实操自动扩容脚本与配置全流程4.1 核心脚本从检测到扩容的完整逻辑写脚本之前我先明确一下它对外的依赖必须是 root 执行系统里必须装了lvm2和相应的文件系统工具e2fsprogs对应 ext4xfsprogs对应 xfs脚本本身不做买盘挂盘只处理已在系统里、但尚未纳入 VG 的 PV 或已纳入 VG 但 VG 还有空闲空间的情况。下面是我部署到生产环境的脚本lvm_autoexpand.sh我拆成几个部分来讲每一行都值得理解#!/usr/bin/env bash set -uo pipefail # 配置区 TRIGGER_PERCENT80 TARGET_PERCENT50 SAFETY_FACTOR1.2 EXCLUDE_LV_PATTERN(^|/)(root|swap)(/|$) LOG_TAG[lvm-autoexpand] LOG_FILE/var/log/lvm-autoexpand.log # 带时间的日志函数 log() { echo $(date %Y-%m-%d %H:%M:%S) $LOG_TAG $* $LOG_FILE } # 记录 lvm 命令的原始输出便于排障 lvmlog() { echo $(date %Y-%m-%d %H:%M:%S) $LOG_TAG CMD: $* $LOG_FILE $ $LOG_FILE 21 }开头这一段set -uo pipefail是为了防止未定义变量和管道错误被静默吞掉。注意我故意没有加set -e因为在自动扩容场景里某些中间步骤失败比如某个 LV 正在使用无法卸载我们未必希望整个脚本立刻退出而是希望它跳过该 LV、继续处理其他 LV最后再由调用方决定是否重试。日志统一写文件方便后面排障lvmlog这个函数能把执行的每条命令原样记到日志里出问题时回溯效率特别高。接着是获取系统状态的部分# 获取所有 LV 的当前信息VG、LV、大小、已用空间 mapfile -t LV_INFO (lvs --noheadings --separator | \ -o vg_name,lv_name,lv_size,lv_attr | sed s/ *//g) declare -A LV_SIZE_BYTES declare -A LV_USED_BYTES for line in ${LV_INFO[]}; do IFS| read -r vg_name lv_name lv_size lv_attr $line # 跳过 lv_attr 中类型不是普通线性/条带卷的例如 snapshot,thin,origin 等 if [[ $lv_attr ~ ^[^sStToO] ]]; then continue fi lv_path/dev/$vg_name/$lv_name if [[ $lv_path ~ $EXCLUDE_LV_PATTERN ]]; then log SKIP: excluded LV $lv_path continue fi fs_type$(blkid -o value -s TYPE $lv_path 2/dev/null || true) # 仅处理 ext4 / xfs if [[ $fs_type ! ext4 $fs_type ! xfs ]]; then log SKIP: unsupported fs ($fs_type) on $lv_path continue fi used_kb$(df -Pk $lv_path 2/dev/null | awk NR2{print $3}) total_kb$(df -Pk $lv_path 2/dev/null | awk NR2{print $2}) if [[ -n $used_kb -n $total_kb ]]; then LV_SIZE_BYTES[$lv_path]$((total_kb * 1024)) LV_USED_BYTES[$lv_path]$((used_kb * 1024)) fi done这里用lvs --noheadings拿 LVM 元数据用df -Pk拿文件系统层的真实使用量。为什么不直接用lvs的已用数据因为 LVM 层面根本没有已用的概念LVM 只管理空间分配不关心里面的文件占了多少。文件系统实际使用量必须通过df或statfs获取。另外blkid判断文件系统类型这一步很重要它决定了后续是执行resize2fs还是xfs_growfs。接着是核心的扩容逻辑# 扩容函数对单个 LV 执行扩容 expand_lv() { local lv_path$1 local vg_name$2 local lv_name$3 local target_percent$4 local total_bytes${LV_SIZE_BYTES[$lv_path]} local used_bytes${LV_USED_BYTES[$lv_path]} local used_percent0 local target_bytes0 local grow_bytes0 # 计算当前使用率 if [[ $total_bytes -gt 0 ]]; then used_percent$(( used_bytes * 100 / total_bytes )) fi log CHECK: $lv_path used ${used_bytes} bytes, total ${total_bytes} bytes, used ${used_percent}% if [[ $used_percent -lt $TRIGGER_PERCENT ]]; then log SKIP: below trigger threshold ${TRIGGER_PERCENT}% return 0 fi # 目标容量 已用容量 / 目标使用率百分比 if [[ $used_bytes -eq 0 ]]; then log SKIP: used_bytes is 0, cannot calculate target return 0 fi target_bytes$(( used_bytes * 100 / target_percent )) grow_bytes$(( target_bytes - total_bytes )) if [[ $grow_bytes -le 0 ]]; then log SKIP: growth is not positive return 0 fi # 获取 VG 的空闲空间 local vg_free_bytes vg_free_bytes$(vgs --noheadings --units b -o vg_free $vg_name | sed s/[^0-9]//g) log VG $vg_name free: ${vg_free_bytes} bytes local require_bytes$(( grow_bytes * 10 / 10 )) require_bytes$(( grow_bytes * SAFETY_FACTOR / 10 )) # 上面两行写得有点绕保留一行即可 if [[ $vg_free_bytes -lt $require_bytes ]]; then log FAIL: not enough VG free space, require ${require_bytes}, free ${vg_free_bytes} return 1 fi log EXPAND: $lv_path grow_bytes$grow_bytes if [[ $fs_type ext4 ]]; then lvmlog lvextend -L ${grow_bytes}b $lv_path lvmlog e2fsck -f -p $lv_path lvmlog resize2fs $lv_path elif [[ $fs_type xfs ]]; then lvmlog lvextend -L ${grow_bytes}b $lv_path lvmlog xfs_growfs $lv_path fi log DONE: $lv_path expanded }这里有个细节值得单独说一下。lvextend的-L参数我传的是${grow_bytes}b强制以字节为单位这是为了规避-L 100G这种写法在不同 LVM 版本下单位换算可能存在的歧义。字节方式虽然看着没那么直观但在自动化脚本里最不容易误解也方便和df拿到的字节数直接对账。然后是对系统里所有未纳入 VG 的 PV 做自动接管# 处理未纳入 VG 的 PV auto_vgextend() { local vg_name local pv_name # 遍历所有 VG把系统里无人认领的 PV 加进去 while read -r vg_name; do local vg_pvs vg_pvs$(pvs --noheadings -o pv_name --select vg_name${vg_name} 2/dev/null | tr -d ) while read -r pv_name; do if [[ -b $pv_name ]]; then # 确认这个 PV 还没有被任何 VG 使用 local used_by used_by$(pvs --noheadings -o vg_name --select pv_name${pv_name} 2/dev/null | tr -d ) if [[ $used_by ! $vg_name ]]; then log VGEXTEND: adding $pv_name to $vg_name lvmlog vgextend $vg_name $pv_name fi fi done (pvs --noheadings -o pv_name 2/dev/null) done (vgs --noheadings -o vg_name 2/dev/null) }这一步实现的是新挂载的磁盘自动成为某个 VG 的新 PV。但是等等脚本怎么知道新盘该加到哪个 VG在单 VG 的机器上可以有默认规则系统里只有一个 VG 就加进去如果有多个 VG我通常是根据磁盘设备路径来映射比如/dev/vdb加给vg_data/dev/vdc加给vg_log。生产里更稳妥的方式是在 udev 规则里直接按设备名和 VG 的对应关系写死或者用标签pvcreate --labels来标记否则自动vgextend到错误的 VG 会造成空间分配混乱。我在上面的示例里做了简化默认加入系统里第一个活动 VG。在单 VG 场景没问题多 VG 场景要按自己的拓扑改掉这段。最后是主函数# 主流程 main() { log START # 1. 先把未入库的 PV 加入 VG auto_vgextend # 2. 遍历所有 LV 并尝试扩容 for lv_path in ${!LV_SIZE_BYTES[]}; do local vg_name${lv_path#/dev/} vg_name${vg_name%%/*} local lv_name${lv_path##*/} expand_lv $lv_path $vg_name $lv_name $TARGET_PERCENT done log END } main注意主流程里我对LV_SIZE_BYTES这个关联数组的遍历。脚本在进入主循环前已经把需要扩容的 LV 信息收集好了但在auto_vgextend中VG 空间可能发生变化PV 列表也可能变化所以这里其实还要重新刷新一次 LV 信息才更严谨。我在生产版本里是调用了前面那段获取 LV 信息的代码而不是直接沿用旧数组。限于篇幅上面脚本做了一定简化大家落地时一定要补上刷新逻辑否则新加入的 PV 不会被本次循环感知到。4.2 完整的部署与自检流程脚本写好以后别急着直接放到线上机器执行我建议严格按下面的步骤来做一次部署和验证首先把脚本放置到/usr/local/sbin/lvm_autoexpand.sh赋予执行权限chmod x /usr/local/sbin/lvm_autoexpand.sh然后手工执行一次观察输出和日志/usr/local/sbin/lvm_autoexpand.sh tail -f /var/log/lvm-autoexpand.log这次手工执行是纯检查模式因为线上环境如果一切正常没有超过阈值的 LV它应该什么扩容动作都不做只打印SKIP记录。确认脚本逻辑没报错之后再正式启用 udev 规则和 systemd 定时器udevadm control --reload-rules systemctl daemon-reload systemctl enable --now lvm-autoexpand.timer为了验证 udev 触发链路是否正常工作我建议在一台测试机上挂载一块空闲空白磁盘注意千万别挂到生产机器上做这种测试观察日志里是否会自动出现VGEXTEND记录。如果 5 分钟之类没有反应先检查内核有没有识别到设备再检查 udev 规则有没有被正确匹配udevadm test /sys/class/block/vdb 21 | grep lvm-autoexpand这条命令能直接告诉我们 udev 规则到底有没有被使用排障效率比瞎猜高很多。4.3 多 VG 与跨盘场景的配置映射前面提到多 VG 场景不能盲目自动vgextend这里给一个更稳妥的映射方式。实际生产里我习惯在/etc/lvm-autoexpand.conf里写设备与 VG 的对应关系# /etc/lvm-autoexpand.conf # 格式: 设备名模式|目标VG名 # 支持通配符 /dev/vd*|vg_data /dev/sd*|vg_data脚本里读取这个配置文件遍历所有空闲 PV找到匹配的第一条规则后执行vgextend。如果找不到匹配项就把 PV 名和 VG 列表写进日志等人工处理。这样既保留自动化又把错误关联的风险控制在最小。对于跨盘场景还有一点要特别提醒如果多块盘的性能差异很大比如一块 SSD、一块 HDD最好把它们放进不同的 VG否则 LVM 的条带化或线性分配策略可能会把不同的 IO 能力混在一起性能会跟着最慢的那块盘走。自动扩容脚本如果不管盘的类型直接从 VG 的空闲空间里分配有可能把 SSD 的 LV 扩到 HDD 上这个坑很隐蔽性能劣化是逐步出现的。我踩过一次后直接把配置里加了一个VG 到盘类型的标记扩容前检查目标 LV 所在 VG 的 PV 类型是否一致不一致就拒绝执行。5. 常见问题与排查技巧实录5.1 高频问题速查表下面这些问题是这几年社群和我自己的服务器上被问得最多的整理成表方便快速查阅问题现象可能原因排查方向脚本执行了但 LV 没变大触发条件未满足或 VG 空闲不足查看日志判断是SKIP还是FAIL新盘挂载后 udev 没有触发规则未加载/内核未识别udevadm test验证规则resize2fs报错无法扩展文件系统有脏标记或者正在使用先e2fsck -f -p再扩展xfs 则必须挂载才能xfs_growfsxfs_growfs提示 already size目标大小和实际大小一致检查是否已经扩过扩容后 df 显示未变化文件系统工具未同步 LVM 新块确认执行了 resize2fs/xfs_growfs扩容完成后磁盘还是满有大文件持续增长用lsof L1找未删除占用句柄的文件定时任务没跑timer 未 enable / 服务 start 失败systemctl status lvm-autoexpand.timer5.2 典型故障复盘一次扩容完成了但空间没释放的案例有一个案例特别典型。某套日志系统的/data使用率达到 97%自动扩容脚本检测后顺利执行了lvextend和xfs_growfs日志里也写了DONE。但问题是扩容完两小时后df显示使用率又回到了 97%像是什么都没发生一样。排查过程分了三步。第一步看df -h发现/data容量确实增加了但空间很快又被吃掉了说明系统里有进程在大量写文件。第二步用lsof L1 | grep deleted查被删除但仍被占用的文件句柄果然发现有一个日志进程还占着一个已经被日志轮转删除的旧文件那个文件的体积已经有几十 GB 了。第三步确认这是个已知的日志轮转 bug重启该进程后空间释放系统恢复正常。这个案例告诉我们自动扩容能覆盖容量规划不足的常规问题但覆盖不了进程泄漏句柄等应用层问题。扩容脚本不是万能药它只是把存储层面的可用容量扩大了如果一个进程以每小时 5GB 的速度持续写文件任何扩容手段都只是延迟崩溃时间真正的问题还得回到应用和日志策略上去。5.3 生产环境必备的兜底手段与防御策略自动化再完善也要有手动控制和紧急熔断的能力。这里分享几个我认为生产级方案必须具备的兜底手段第一扩容操作必须记录痕迹并能快速回查。我的做法是除了日志文件外还把每次扩容的摘要时间、LV、原始大小、目标大小、VG 空闲变化写入一个单独的状态文件方便事后审计和容量趋势分析。脚本里加一行echo $(date %F %T) $lv_path $grow_bytes $vg_free_bytes /var/log/lvm-autoexpand-history.log第二自动扩容要能和监控系统联动。比如监控大盘上不仅能看到磁盘使用率还能看到最近一次自动扩容时间和扩容次数如果一台机器在一天内自动扩容超过两次说明它的容量规划可能有问题要及时人工介入重新评估数据盘大小而不是让脚本无限扩下去。第三可以对扩容频率做硬限制。比如同一个 LV 在一小时内最多执行一次扩容防止 VG 空间充足时脚本因为写入尖峰反复扩容给文件系统造成不必要的中断。这个限制可以用一个简单的时间戳对比实现代码不过十几行。第四最重要的防御正式执行前的最终校验。每次自动扩容前脚本会检查当前文件系统是否处于健康状态。ext4 在执行resize2fs前强制跑一次e2fsck -f -p虽然有性能开销但在自动场景里值得。xfs 虽然没有必须执行 fsck 的要求但如果通过xfs_repair -n发现明显问题脚本也会放弃本次扩容。生产环境里我宁可这次不扩也不要在一个损坏的文件系统上做危险操作。5.4 关于 ext4 和 xfs 的自动扩容差异最后特别讲一下两种文件系统在自动扩容里的差异这是初学者最容易懵的地方。ext4 的扩容路径是lvextend先把 LV 扩大再resize2fs扩展文件系统。resize2fs可以在线执行也可以离线执行。在线扩容要求文件系统本身没有问题如果在扩容前执行e2fsck建议用-f -p强制检查并自动修复不交互但注意-p只能自动修复安全的错误遇到复杂问题它还是会停下来这是合理行为脚本检测到非零退出码就该中止。xfs 的扩容路径有本质区别xfs_growfs的入参必须是挂载点而不是设备路径。例如xfs_growfs /data而且 xfs 只能扩容、不能缩容lvextend之后的文件系统扩展是即时的不需要先卸载。如果漏掉了挂载点参数写成xfs_growfs /dev/vg_data/lv_data会收到一个让你困惑的报错。这是我见过最多的 xfs 扩容操作错误没有之一。另外ext4 有一个最小扩展单位的概念resize2fs 在线扩展的最小单位是块组block group默认一般不会构成限制但如果你把 LV 扩大得非常小比如几个 MBresize2fs可能认为nothing to do这是正常现象不是 bug。在自动扩容脚本里可以通过grow_bytes低于某个绝对阈值就直接跳过比如低于 256MB 不动作减少无效调用。6. 这套方案落地后的实际效果与扩展建议6.1 上线前后的对比我把这套自动扩容方案上线到某套日志集群之后对运维数据的感受是颠覆性的。上线前日志盘的容量告警每个月大概要出 30 次到 50 次每次都需要有人在控制台挂盘、进机器执行命令平均耗时 20 分钟以上高峰期可能一两个小时才能处理完。上线后告警次数没变少多少但磁盘使用率超过 90%的 P1 级告警几乎消失了因为大多数情况在 80% 时扩容已经自动完成真正逼近 90% 的场景很少出现。从容量利用率角度也能看到明显变化。以前为了防止磁盘突然打满很多人习惯把每块盘规划得很富余比如预计用 200GB 就给 500GB现在自动扩容兜底初始分配可以稍微紧张一些数据增长后脚本会自动扩展整体容量利用率提高了不少。当然前提是 VG 底层的物理容量池本身要充足或者云平台这边有配套的自动挂盘流程否则脚本也是巧妇难为无米之炊。6.2 扩展方向一与监控告警打通形成闭环这套脚本做的是一个执行者的角色它需要一个大脑来给它下指令。更完整的方案是在监控系统里做容量预测当监控预测未来 24 小时内磁盘使用率将达到 80% 时提前触发扩容而不是等真的到了 80% 才被动执行。这个预测模型简单点用线性回归就能做复杂一点可以用时间序列。我在某团队的实际项目里就是这么干的监控数据每 5 分钟上报一次预测模块算出预计到达阈值的时间如果少于 48 小时就给扩容系统发一条指令。自动扩容系统收到指令后先根据当前 VG 空闲情况决定是直接扩已有 LV还是先申请新盘。6.3 扩展方向二容器平台的数据卷自动扩容如果你在维护容器平台比如 Kubernetes这套 LVM 自动扩容的思想可以直接嫁接到存储插件层面。容器平台经常使用 LVM 作为后端给 PVC 提供存储那么当 PVC 使用率达到阈值时由存储控制器调用 LVM 命令扩容然后把新容量同步给文件系统逻辑和服务器上跑的完全一致。区别在于触发源从 udev/systemd 变成了存储控制器的 API脚本的检测-校验-动作骨架是完全可以复用的。我在一个模拟项目里试过通过 CSI 插件的方式封装这套逻辑整体流程跑通后业务方几乎无感知唯一需要提醒他们的是 PVC 里的数据增长别超过底层 VG 池的物理上限。6.4 最后一条建议永远保留人工干预通道不管自动化做得多么完善我始终在服务器配置里保留一个暂停自动扩容的总开关也就是环境变量或者配置文件里的一个开关。遇到以下几种情况我会立刻关掉自动扩容一是文件系统本身可能出现损坏迹象二是某台机器正在进行重大变更比如内核升级、存储驱动替换三是 VG 物理容量已经很紧张我不希望脚本把最后一点空间也自动分配出去应该留给人工判断。这个总开关看似简单但在紧急关头能救命。我见过好多团队自动扩容上线后就把这套机制忘在脑后结果有一次底层存储池硬件故障VG 的空闲空间全部来自一块即将离线的故障盘自动扩容脚本还傻乎乎地把数据分配到了那块盘上最终造成不必要的修复成本。加上开关以后每次大变更前统一批量关闭变更完再批量开启方便又安全。7. 写在最后的实操体会自动扩容这套东西本质上不是靠单个脚本显得多聪明而是靠事件驱动 定时兜底 安全红线 可审计日志这四个支柱把风险兜住。我见过有人只用一条 udev 规则加三行 shell 就想上线结果一个月后某台机器把 VG 的 PE 全部分光其他 LV 想扩也扩不了反而把问题搞复杂了。所以我把这篇文章的重心放在为什么和边界条件上而不只是给你一段代码就是因为这些防呆设计才是生产级方案和玩具脚本之间的分水岭。最后再分享一个小技巧吧给脚本的每次扩容动作都打点上报到监控哪怕只是简单的扩容成功/失败计数。等你运行几个月再看趋势图会发现哪些机器的数据增长规律和你预估得完全不一样这些才是最真实的容量规划依据。我在实际运维中就是因为看了这份数据才把某套日志集群的初始磁盘分配从 200GB 调到 800GB直接少了一半多的自动扩容动作也少了很多底层盘的挂载操作。自动扩容是最后一道兜底防线而好的容量规划才是让这道防线不经常被触发的正路。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
