1. 从一次真实的磁盘告警说起为什么LV扩容是运维的必备技能那天下午监控平台的告警邮件像往常一样准时弹出来但内容却让人心头一紧生产环境某台核心服务器的/data目录磁盘使用率已经飙升至 95%并且还在持续增长。这可不是开发测试环境/data下面跑着数据库和业务日志一旦写满服务瞬间就会瘫痪。登录服务器习惯性地敲下df -h那个刺眼的红色数字如果终端支持颜色或者后面跟着的(95%)赫然在目。按照“古老”的物理分区管理方式这时候可能就要经历一场心惊肉跳的运维操作申请新硬盘、备份数据、在新硬盘上重建分区、恢复数据、修改应用配置指向新路径……整个过程耗时耗力服务中断时间不可控。但幸运的是这台服务器在最初规划时就采用了LVMLogical Volume Manager逻辑卷管理器。这意味着/data并不是直接挂载在像/dev/sdb1这样的物理分区上而是挂载在一个名为data_lv的逻辑卷上。这个逻辑卷属于一个叫vg_data的卷组而卷组则由多块物理硬盘或分区提供的物理卷组成。LVM 的精髓就在于“逻辑”二字它将底层的物理存储资源抽象化、池化管理。所以面对磁盘空间告警我的解决方案不再是“搬家”而是“扩容”。只要卷组vg_data里还有剩余空间无论是来自已加入的硬盘未使用部分还是新添加的硬盘我就可以在线、动态地扩展data_lv逻辑卷并同步扩展其上的文件系统整个过程业务无感知。这就是 LVM 带来的核心价值灵活的存储管理。今天要聊的就是把这个“扩容”操作从一次可能手忙脚乱的救火变成一套清晰、稳定、可复用的标准操作流程。2. 理解LVM三层架构PV、VG、LV与挂载点的关系在动手扩容之前必须把 LVM 的基本概念捋清楚否则后面的命令就是空中楼阁。你可以把 LVM 想象成一个高度灵活的建筑公司。第一层物理卷Physical Volume, PV。这就是最原始的“建筑材料”比如砖块、水泥。在 Linux 里它们就是一块完整的硬盘如/dev/sdb或者一个分区如/dev/sda3。但光有材料不行LVM 不能直接使用它们。我们需要用pvcreate命令把这些“材料”初始化打上 LVM 的标签变成 LVM 可管理的“标准建材”。例如pvcreate /dev/sdb就是把整块硬盘/dev/sdb变成一块物理卷。第二层卷组Volume Group, VG。这是“建材仓库”。我们可以把一个或多个物理卷PV加入到一个卷组里。比如vgcreate vg_data /dev/sdb /dev/sdc就是创建了一个名为vg_data的仓库并把/dev/sdb和/dev/sdc这两块“砖”放了进去。卷组将所有加入的物理卷的存储空间合并成一个大的、连续的存储池。管理员不再需要关心文件是存在哪块具体的硬盘上只需从池子里分配空间。你可以随时向这个仓库里添加新的“砖”vgextend也可以把不用的“砖”移走vgreduce需先移走数据。第三层逻辑卷Logical Volume, LV。这是从“建材仓库”里划出来实际用于建造“房间”的“空间”。比如lvcreate -L 100G -n data_lv vg_data就是从vg_data这个仓库里划出 100G 的空间创建了一个名叫data_lv的逻辑卷。这个逻辑卷在系统里看起来就像一块独立的硬盘设备路径通常是/dev/mapper/vg_data-data_lv或者更简单的/dev/vg_data/data_lv。最后一步文件系统与挂载点Mount Point。光有“房间”空间还不行我们需要给这个空间铺上地板、刷上墙漆也就是创建文件系统如 ext4, xfs。mkfs.ext4 /dev/vg_data/data_lv就是在data_lv这个逻辑卷上创建 ext4 文件系统。创建好后就可以把它“挂载”到目录树的一个空目录上比如/data。这个目录就是挂载点。命令mount /dev/vg_data/data_lv /data完成了这个操作。之后所有写入/data的文件实际上都存储在了data_lv逻辑卷上而逻辑卷的空间又来自于卷组vg_data卷组的空间最终来自于物理卷/dev/sdb和/dev/sdc。所以当我们说“给挂载点/data扩容”时完整的链条是确保卷组VG有空间 - 扩展逻辑卷LV的大小 - 扩展该逻辑卷上文件系统的大小 - 挂载点/data的可用空间变大。前两步是 LVM 层的操作第三步是文件系统层的操作缺一不可。如果只扩展了 LV 但没扩展文件系统df -h看到的容量就不会变。3. 扩容前的侦察摸清家底制定方案盲目操作是运维大忌。扩容前我们必须像侦探一样收集所有相关信息评估风险并制定详细的方案。以下是必须执行的侦察步骤。3.1 确认存储架构与空间现状首先使用df -hT命令。-h参数让人性化显示单位G, M-T参数显示文件系统类型。这个命令能直接告诉我们哪个挂载点空间不足它挂载在哪个设备上以及文件系统类型。[rootserver ~]# df -hT Filesystem Type Size Used Avail Use% Mounted on ... /dev/mapper/vg_data-data_lv ext4 98G 92G 1.2G 99% /data关键信息获取问题挂载点/data使用率 99%告警。对应的设备/dev/mapper/vg_data-data_lv。这明确告诉我们/data是一个 LVM 逻辑卷。如果这里显示的是/dev/sda1之类的那就是普通分区不适用本教程。文件系统类型ext4。这决定了后续扩展文件系统时使用的命令resize2fs用于 ext2/3/4xfs_growfs用于 xfs。接下来顺藤摸瓜查看这个逻辑卷的详细信息lvdisplay /dev/vg_data/data_lv。--- Logical volume --- LV Path /dev/vg_data/data_lv LV Name data_lv VG Name vg_data LV UUID XXXXXXXXXXXXXXXXX LV Write Access read/write LV Creation host, time server, 2023-01-01 10:00:00 LV Status available # open 1 LV Size 100.00 GiB Current LE 25600 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:2这里我们重点关注VG Name卷组名是vg_dataLV Size是 100G。这验证了df看到的总容量。然后查看逻辑卷所在的卷组还有多少剩余空间vgdisplay vg_data。--- Volume group --- VG Name vg_data System ID Format lvm2 Metadata Areas 2 Metadata Sequence No 5 VG Access read/write VG Status resizable MAX LV 0 Cur LV 1 Open LV 1 Max PV 0 Cur PV 2 Act PV 2 VG Size 199.99 GiB PE Size 4.00 MiB Total PE 51198 Alloc PE / Size 25600 / 100.00 GiB Free PE / Size 25598 / 99.99 GiB VG UUID XXXXXXXXXXXXXXXXX这是最关键的一步我们找到了“弹药”VG Size卷组总大小约 200G。Alloc PE / Size已分配的空间是 100G正好是我们的data_lv大小。Free PE / Size剩余空间约 100G太好了卷组里还有充足的剩余空间这意味着我们不需要添加新硬盘可以直接进行扩容。如果这里Free PE是 0 或者很小那么扩容方案就需要先扩展卷组vgextend这通常需要添加新的物理硬盘或使用现有硬盘的未分配空间。3.2 制定扩容方案与风险评估基于侦察结果方案很明确目标将/data挂载点的可用空间扩大。路径扩展逻辑卷data_lv- 扩展其上的 ext4 文件系统。可用资源卷组vg_data有约 100G 剩余空间。扩容量我们需要决定扩多大。可以全部用完也可以留一部分。假设业务评估需要 50G我们决定给data_lv增加 50G。风险与预案数据丢失风险任何磁盘操作都有理论上的数据丢失风险。必须确保已有有效备份。对于生产环境应在业务低峰期操作。操作中断风险LVM 扩展逻辑卷和文件系统通常是在线操作但极端情况下可能导致文件系统损坏。确保有回滚预案虽然LVM扩展通常不可逆但备份是最后的保障。业务影响在线扩容对正在读写的文件影响极小但并非为零。对于极度敏感的业务可申请短暂维护窗口。命令敲错风险务必再三核对命令中的卷组名、逻辑卷名、大小参数。/dev/vg_data/data_lv和/dev/vg_data/log_lv可能只是一字之差但后果天壤之别。注意在执行任何破坏性命令虽然本例不是或关键变更前养成执行lsblk、df -h、vgdisplay、lvdisplay并截图或记录的好习惯。这既是操作记录也方便在出问题时对比状态。4. 实战扩容三部曲扩展LV与文件系统侦察完毕方案已定现在开始动手。整个过程分为三个核心步骤顺序不能错。4.1 第一步扩展逻辑卷LV容量这是 LVM 层面的操作使用lvextend命令。其核心语法是lvextend -L [要增加的大小] /dev/卷组名/逻辑卷名或者指定扩展后的总大小lvextend -L [扩展后的总大小] /dev/卷组名/逻辑卷名在我们的场景中vg_data卷组有100G剩余我们要给data_lv增加50G。方法A增加指定容量[rootserver ~]# lvextend -L 50G /dev/vg_data/data_lv Size of logical volume vg_data/data_lv changed from 100.00 GiB (25600 extents) to 150.00 GiB (38400 extents). Logical volume vg_data/data_lv successfully resized.-L 50G表示在原有基础上增加 50G。命令输出清晰地显示了变化从 100G 变成了 150G。方法B指定总容量[rootserver ~]# lvextend -L 150G /dev/vg_data/data_lv-L 150G没有加号表示将逻辑卷的总大小设置为 150G。如果原先是100G效果就是增加50G。实操心得我个人更倾向于使用-L [大小]的方式因为它明确表达了“增加”这个动作更不容易出错。使用指定总大小的方式时一定要心算一下当前大小加上增量是否等于你输入的总大小否则可能意外缩容如果输入值小于当前值或超出卷组容量。执行成功后可以用lvdisplay /dev/vg_data/data_lv再次确认LV Size应该已经变成了 150 GiB。4.2 第二步扩展文件系统Filesystem这是很多新手会忘记的关键一步lvextend只是把“房间”的墙壁向外推了扩大了建筑面积。但“房间”内部的地板文件系统还没有铺到新扩大的区域。所以我们需要告诉文件系统“嘿你的地盘变大了去管理那些新空间吧”使用什么命令取决于第一步中df -hT查看到的文件系统类型。情况一ext2/ext3/ext4 文件系统使用resize2fs命令。这个命令非常智能如果你不指定大小它会自动探测逻辑卷的大小并扩展到填满整个逻辑卷。[rootserver ~]# resize2fs /dev/vg_data/data_lv resize2fs 1.45.5 (07-Jan-2020) Filesystem at /dev/vg_data/data_lv is mounted on /data; on-line resizing required old_desc_blocks 13, new_desc_blocks 19 The filesystem on /dev/vg_data/data_lv is now 39321600 (4k) blocks long.输出信息显示文件系统正在被在线调整大小on-line resizing required并且最终块数增加了。这就成功了。如果你想精确控制文件系统的大小极少需要也可以指定大小resize2fs /dev/vg_data/data_lv 140G但通常就让其填满LV。情况二xfs 文件系统使用xfs_growfs命令。注意xfs 文件系统只能扩容不能缩容。命令需要指定挂载点而不是设备路径。[rootserver ~]# xfs_growfs /data meta-data/dev/mapper/vg_data-data_lv isize512 agcount4, agsize6553600 blks sectsz512 attr2, projid32bit1 crc1 finobt1, sparse1, rmapbt0 reflink1 data bsize4096 blocks26214400, imaxpct25 sunit0 swidth0 blks naming version 2 bsize4096 ascii-ci0, ftype1 log internal log bsize4096 blocks12800, version2 sectsz512 sunit0 blks, lazy-count1 realtime none extsz4096 blocks0, rtextents0 data blocks changed from 26214400 to 39321600同样输出末尾的data blocks changed from ... to ...表明文件系统已成功扩展。4.3 第三步验收成果最后使用最初的侦察命令df -h来验证扩容是否真正生效。[rootserver ~]# df -h /data Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_data-data_lv 148G 92G 49G 66% /data可以看到文件系统总大小Size已经从约 98G 变成了约 148G可用空间Avail从 1.2G 大幅增加到了 49G使用率Use%也从 99% 降到了 66%。至此一次完整的在线扩容操作成功完成业务在过程中无需中断。5. 进阶场景与深度避坑指南上面的三步走是标准流程但实际环境往往更复杂。下面分享几种进阶场景和容易踩坑的地方。5.1 场景一卷组空间不足需先加硬盘扩VG这是更常见的场景vgdisplay发现Free PE为 0 或很小不够扩容 LV。这时就需要先扩展卷组。步骤1添加新物理硬盘。这可能是物理插拔新硬盘或者在虚拟机管理界面添加虚拟硬盘。添加后在操作系统中使用lsblk或fdisk -l找到新硬盘例如/dev/sdd。步骤2创建物理卷PV。[rootserver ~]# pvcreate /dev/sdd Physical volume /dev/sdd successfully created.步骤3扩展卷组VG。将新创建的 PV 加入到目标卷组。[rootserver ~]# vgextend vg_data /dev/sdd Volume group vg_data successfully extended步骤4验证卷组空间。再次执行vgdisplay vg_data你会发现Free PE增加了。之后就可以回到第4章的标准流程去扩展 LV 和文件系统了。5.2 场景二扩容空间不是整数G理解PE与LE在vgdisplay的输出里你会看到PE SizePhysical Extent Size物理扩展块大小和Total PE、Free PE。LVM 以 PE 为最小分配单位默认是 4MB。创建 VG 时可以指定-s参数修改。当使用lvextend -L 50G时LVM 会尝试分配最接近 50G 的整数个 PE。因为 1G 1024M50G 51200M除以 PE Size 4M等于 12800 个 PE。这是一个整数所以会精确分配 50G。但如果你输入lvextend -L 51G51G 52224M除以 4M 等于 13056 个 PE这也是整数。问题在于如果你用-L 150G这种方式而原来的大小不是整数G或者PE计算有细微出入可能会导致分配的空间不是你想要的精确值。更稳妥的做法是使用-l小写L参数直接指定扩展多少个 PE。首先用vgdisplay vg_data查看Free PE数量假设是 25598。然后计算你想扩展的容量需要多少 PE。比如想扩展 50GPE Size 是 4M那么需要50 * 1024 / 4 12800个 PE。最后执行[rootserver ~]# lvextend -l 12800 /dev/vg_data/data_lv这种方式绝对精确避免了因单位换算导致的细微偏差。5.3 避坑文件系统扩容失败与救援坑1顺序错误先扩文件系统后扩LV。这一定会失败。因为文件系统无法扩展到超出其所在设备LV的边界。必须牢记先 LV后文件系统。坑2针对 xfs 文件系统使用了resize2fs。这会导致错误。必须使用xfs_growfs且针对挂载点操作。坑3resize2fs提示 “The filesystem is already XXXX blocks long.”这通常意味着你已经成功扩展过文件系统了或者 LV 并没有成功扩展。请先用lvdisplay确认 LV 大小是否已改变。如果 LV 已变大但还报此错可以尝试强制指定一下大小resize2fs /dev/vg_data/data_lv 150G。坑4在线扩容过程中突然断电或系统崩溃。这是最危险的情况。对于 ext4 文件系统在重启后系统可能会在启动时自动进行fsck检查并尝试修复。但存在一定风险。因此在操作前对关键数据进行备份是无论如何强调都不为过的铁律。对于 xfs 文件系统其元数据日志特性使其在意外崩溃后恢复能力较强但同样不是100%保险。坑5空间并未释放检查进程与已删除文件。有时候扩容后应用依然报“磁盘空间不足”。用df -h看确实空间多了但用du -sh /data统计目录大小却发现远小于df显示的使用量。这通常是某个进程打开了一个大文件然后这个文件被删除了。在 Linux 中如果一个文件被进程打开后删除其磁盘空间并不会立即释放直到关闭该文件的进程终止。可以使用lsof /data | grep deleted命令查找这样的进程然后重启相应进程以释放空间。6. 自动化与监控让扩容防患于未然手动扩容是补救措施优秀的运维应该追求自动化预警和自动化处理。监控预警使用 Zabbix、Prometheus 等监控系统对/data这类关键挂载点的使用率设置告警阈值例如超过 80% 发警告超过 90% 发紧急告警。这样你就有充足的时间在空间用尽前从容处理。自动化扩容脚本对于标准化环境可以编写一个简单的扩容脚本。脚本逻辑如下接收参数目标挂载点如/data、期望扩容后的使用率阈值如 70%。通过df获取该挂载点对应的设备、文件系统类型、当前使用率。判断是否为 LVM 设备判断设备路径是否包含/mapper/或/dm-。通过lvdisplay、vgdisplay解析出 VG 名称、LV 名称、当前 LV 大小、VG 剩余空间。计算需要扩容的大小当前使用量 / 目标阈值 - 当前 LV 大小。判断 VG 剩余空间是否足够。执行lvextend和对应的文件系统扩展命令根据文件系统类型分支判断。记录日志并发送通知。这样的脚本可以在监控系统触发告警后自动执行实现“自愈”。当然自动化扩容涉及权限和安全需要在受控的、测试充分的环境中实施。最后LVM 的功能远不止扩容还有快照用于在线备份、缩容风险高需谨慎、条带化提升性能、镜像提高可用性等。但扩容是其最常用、最核心的功能。掌握它你就掌握了 Linux 存储管理的主动权从被磁盘空间追着跑的“救火队员”变成了从容调配资源的“架构师”。
