做运维这些年最怕的不是半夜被报警电话叫醒而是被叫醒之后发现是磁盘满了而这块磁盘还偏偏是个单分区就挂载上来的老破小。删日志清理临时文件一次两次是应急时间长了谁扛得住。后来我这边几乎所有新上线的系统都统一改用LVM也就是逻辑卷管理。为什么因为LVM的核心价值就一句话让文件系统的大小不再被物理分区焊死扩容、缩容、迁移、快照全都能在线操作。这篇就把LVM从原理到实操整个盘一遍适合刚接触服务器存储管理的朋友也适合已经用了LVM但遇到问题想系统补齐知识点的老手。提示本文所有命令均基于CentOS/RHEL系列部分细节在其他发行版上略有差异但原理和流程完全通用。1. LVM核心概念与架构拆解1.1 没有LVM的时代扩容有多痛先回忆一下没有LVM时磁盘空间管理是怎么玩的。一块物理磁盘用fdisk或者parted分成若干分区每个分区上直接格式化文件系统然后挂载到某个目录。比如/dev/sda1挂到根目录/dev/sda2挂到/home。这套方案看起来简单但一旦布局定死后面想调整就是一场噩梦。业务增长导致/home空间不够传统做法是什么找新磁盘把数据拷过去改挂载点重新配置服务最后找个维护窗口重启。这个过程中服务要中断数据要复制挂载关系要重配稍不留神还可能把目录权限或者软链接给搞乱。更惨的是如果你当初没有预留独立分区直接把所有数据都放在一个根分区里那扩容连“挂新盘”这条路都走不通只能清数据。LVM把问题彻底换了个解法。它不直接让文件系统跟物理分区发生关系而是在中间加了一层逻辑抽象。文件系统看到的是一块“逻辑卷”这逻辑卷有多大、底层由哪些物理存储拼起来文件系统不关心也不需要关心。扩容逻辑卷就是往这个卷里追加空间文件系统在线跟着变大就行。1.2 那五个英文缩写到底代表什么LVM里有几个基础概念必须吃透物理卷PV、卷组VG、逻辑卷LV以及物理扩展块PE、逻辑扩展块LE。物理卷PV指的是被LVM标记过的存储设备可以是一整块磁盘比如/dev/sdb也可以是一个磁盘分区比如/dev/sdc1。PV是LVM能认识的最小存储单元入口。卷组VG是一个由多个PV汇聚成的存储资源池。你可以把它理解成一个“蓄水池”池子里的水就是PV贡献出来的空间。VG建立之后你不再需要关心具体某块磁盘多大你只需要知道池子总共多大、还剩多少。逻辑卷LV是从VG这个池子里切出来的一块空间相当于一个“水桶”。LV创建好之后格式化文件系统、挂载使用对它做操作就跟对普通分区一样。业务看到的、用到的就是LV。PE和LE相辅相成。PV创建时会被切成固定大小的物理扩展块PE默认4MB这个值创建PV时通过-b参数指定创建之后不能改。VG里的空间分配、LV的创建都以PE为单位进行计算。而LE就是逻辑层面的对应块。LE和PE的映射关系就是LVM最核心的底层逻辑所有条带化、镜像、快照都建立在这层映射之上。注意PE大小建议在创建PV之前规划好。默认4MB对绝大多数场景够用但如果你的VG会非常大几十TB以上PE调大到16MB甚至32MB反而能减少元数据开销。PE不能改小所以大空间场景一开始就规划大PE。1.3 LVM的完整逻辑视图把上面几个概念串起来整套LVM的架构是这样的物理磁盘 → PV物理卷 → VG卷组 → LV逻辑卷 → 文件系统 → 挂载点底层物理磁盘经过pvcreate处理变成PV多个PV用vgcreate聚合成VGVG上通过lvcreate划出LVLV格式化mkfs之后就成为了普通文件系统。每一步都有对应命令后面实战部分会逐一演示。这里有个很重要的特性值得多说一句LVM的条带化能力。创建LV时指定-i 2 -I 64可以把数据交错分布在多块PV上类似RAID0的逻辑读写性能会显著提升。但这会引入单点风险——任何一块PV挂了整个LV的数据都会受影响。生产环境用之前一定要想清楚你的数据是否扛得住这种风险该做冗余做冗余。2. 环境准备与基础操作2.1 创建LVM前的磁盘规划动手之前先规划这一点比命令本身重要得多。先明确你手上有哪些磁盘、每块磁盘多大、用来做什么。用lsblk看一眼全貌lsblk输出类似这样NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 40G 0 disk ├─sda1 8:1 0 1G 0 part /boot └─sda2 8:2 0 39G 0 part / sdb 8:16 0 500G 0 disk sdc 8:32 0 500G 0 disk在这个例子里系统盘sda已经装好系统新加了两块500G的数据盘sdb和sdc。我的规划是把这两块盘合成一个VG做成一个1T的池子再从中分出业务逻辑卷。规划时还要考虑几个问题系统和数据要隔离系统盘保持独立VG不要让数据逻辑卷占用系统盘的PV空间。预留一部分VG空间给未来扩容不要一上来把池子分光。后面扩容要在线执行池里有空间才有意义。数据盘选整块磁盘做PV还是分区做PV我的经验是纯数据盘直接整块做PV最省事因为后续换盘、坏盘处理都简单但如果是老系统上还有别的用途的磁盘那就用分区做PV分区类型记得改成8eLinux LVM。规划完成后下一步就是把磁盘变成PV。2.2 PV、VG、LV三步建卷全流程第一步创建PVpvcreate /dev/sdb /dev/sdc这条命令把两块物理磁盘初始化为PV。执行完可以用pvdisplay或pvs确认状态。pvs看到类似输出就说明成功了PV VG Fmt Attr PSize PFree /dev/sdb lvm2 --- 500.00G 500.00G /dev/sdc lvm2 --- 500.00G 500.00G第二步把PV聚合成VGvgcreate data_vg /dev/sdb /dev/sdcdata_vg是我给卷组起的名字。创建后同样用vgs或vgdisplay验证vgs可以看到VG的大小是两块盘的总和刚好1T左右。第三步创建LVlvcreate -n data_lv -L 800G data_vg-n指定LV名称-L 800G指定大小。这样就从data_vg这个池里切了一个800G的逻辑卷data_lv出来。剩下的空间留在池里作为未来扩容的余量。创建完LV之后它的设备路径是这样/dev/data_vg/data_lv也就是/dev/卷组名/逻辑卷名这个路径在LVM世界里就是你的“盘”。2.3 格式化、挂载与自动挂载配置LV建好了接下来就跟普通分区一样处理了。格式化成你要用的文件系统mkfs.xfs /dev/data_vg/data_lv这里用的是xfs如果你更习惯ext4就mkfs.ext4。两者各有优势生产环境我本人偏xfs因为它在扩容场景支持得比较干脆但后面讲缩容时你会发现xfs有个硬伤到时候再说。格式化完成后创建挂载点并挂载mkdir /data mount /dev/data_vg/data_lv /data挂载完成后df -h应该已经能看到这块新空间了。自动挂载必须写进/etc/fstab否则重启就“丢盘”。这里我推荐用UUID而不是设备路径因为设备路径在系统重启或者PV顺序变化后可能变动UUID是稳定的。用blkid查UUIDblkid /dev/data_vg/data_lv然后编辑/etc/fstab加一行UUIDxxxx-xxxx-xxxx /data xfs defaults 0 0写完之后mount -a验证一下没报错就说明配置正确。实操心得fstab里0 0前面那个数字xfs建议写成0 0ext4可以保留1 1。因为xfs不支持系统启动时的自动检查强行设置检查项反而可能出问题。2.4 常用查询命令速查用得多了你会发现LVM相关的查询命令非常好记几乎所有操作都符合“xls、xdisplay、xscan”的命名规律。命令作用pvs / pvdisplay / pvscan查看物理卷状态、大小、所属VGvgs / vgdisplay / vgscan查看卷组大小、空闲空间、PE信息lvs / lvdisplay / lvscan查看逻辑卷大小、路径、状态blkid查看设备UUIDdf -h确认文件系统实际使用情况这三组命令是排障的第一工具。看到PV状态异常第一步就是pvscan扫一遍看到LV扩容后文件系统没变大先lvs确认LV本身是否扩了。排查思路清晰了大部分问题都能定位。3. 在线扩容与缩容实战3.1 在线扩容逻辑卷最核心的场景扩容是LVM用得最多的功能也是它最有价值的地方。业务跑着跑着磁盘告警了账户还登录着应用还在写数据这时候怎么办LVM给出答案在线扩容。扩容分两步先扩大LV再扩大文件系统对应的部分。顺序千万不能颠倒。先看VG里还有没有空闲空间vgsPFree列就是剩余可分配空间。假设data_vg还剩200G现在给data_lv增加50Glvextend -L 50G /dev/data_vg/data_lv-L 50G表示在原有基础上追加50G。如果想把LV扩到正好某个大小用-L 850G不带加号。扩容LV之后文件系统还未感知到新的空间接下来要在线扩文件系统。xfs和ext4的命令不同一定不要搞错。xfs文件系统xfs_growfs /dataext4文件系统resize2fs /dev/data_vg/data_lv注意xfs传挂载点ext4传设备路径这是两个最容易混淆的操作点。执行完成后df -h验证文件系统大小应该已经刷新。提示xfs_growfs在CentOS 7及以后版本上路径通常就是挂载点老版本需要手动指定挂载点参数。如果提示找不到挂载点试试直接传设备路径。3.2 缩容是真正的技术活缩容是LVM里最危险的操作原则是先缩文件系统再缩LV顺序绝对不能反。而且这里有个重大的前置限制xfs文件系统不支持缩容。xfs不支持缩容这是它和ext4最明显的区别。所以你上生产之前就要想清楚如果未来有缩容需求文件系统最好选ext4如果确定只扩不缩xfs的扩容体验更舒服。如果你用的是ext4并且确认数据量小于缩容目标大小那可以往下走。第一步卸载文件系统umount /data缩容不能在线进行必须卸载。第二步检查文件系统e2fsck -f /dev/data_vg/data_lv强制检查文件系统确认没有错误或者不一致这一步不做后面缩容大概率出问题。第三步缩文件系统resize2fs /dev/data_vg/data_lv 750G把文件系统缩到750G。第四步缩LVlvreduce -L 750G /dev/data_vg/data_lv这时系统会提示确认输入y继续。缩完之后重新挂载mount /dev/data_vg/data_lv /data再用df -h和lvs确认结果。这套流程必须严格按顺序执行。我见过太多人把顺序搞反结果文件系统还没缩、LV先缩了数据直接损坏找数据恢复服务花了不少冤枉钱。缩容之前无论如何要备份一份数据特别是数据库这类重要业务备份做完再动手一点都不多余。3.3 跨磁盘迁移数据而不停机LVM还提供了一个很实用但是容易被忽略的功能把LV的数据从一块物理磁盘迁移到另一块全程在线不中断业务。场景很典型某块磁盘SMART报警有坏道趋势趁它还没彻底报废把数据迁到新盘上去。操作非常简单。先把新盘做成PV并加入VGpvcreate /dev/sdd vgextend data_vg /dev/sdd然后执行迁移pvmove /dev/sdb /dev/sdd这条命令会把原来在sdb上的所有PE数据逐个块迁移到sdd上在迁移过程中原有LV上的业务访问不受影响。数据迁完之后把旧盘从VG里移出vgreduce data_vg /dev/sdb之后就可以安全地把sdb拆走或者做其他处理了。这个过程看起来简单实则底下做了大量工作LVM的le映射更新、数据同步、校验全都在后台自动完成。我做过几次这样的热迁移最慢的一次1T数据跑了一个多小时业务全程零中断体验极好。注意pvmove过程中如果系统断电LVM会保留迁移状态信息重启后可以继续或者手动恢复。所以万一断电了别慌先查pv状态再决定下一步。4. LVM快照与数据保护实战4.1 lvm snapshot的工作原理快照是LVM另一个高频使用功能。它可以在秒级创建一个逻辑卷的“冻结副本”而且是几乎不占用额外空间的——至少刚创建时是这样。快照的技术核心是coW也就是写时复制。快照刚创建时它并不复制源LV的数据而只是记录“在这个时间点源LV的每个块是什么内容”的元数据状态。之后源LV上如果有数据块要修改LVM会先把原始数据复制到快照区保存再执行修改。所以快照空间里保存的其实是“源卷上被修改过的原始块”而不是完整的数据副本。这就解释了一个快照使用中最常见的误区快照不是备份。它更像一个“时光机”功能是让你快速回到快照创建那一刻的状态而不是帮你抵御物理损坏。如果源LV的磁盘物理损坏了快照里的数据也保不住因为快照数据本身也在这组磁盘上。4.2 快照的创建与恢复实操创建快照lvcreate -s -n data_snap -L 20G /dev/data_vg/data_lv-s表示生成快照卷data_snap是快照名字-L 20G是预留的快照空间。快照空间大小怎么定取决于你预计在快照有效期间源卷会有多少数据被修改。如果快照空间满了快照会自动变得不可用并且无法恢复。所以第一次做快照空间宁可多给一点。快照创建后可以通过挂载临时访问mkdir /mnt/snap mount /dev/data_vg/data_snap /mnt/snap这时/mnt/snap下看到的就是创建快照那一刻源卷的完整数据。你可以对这个挂载点做备份、导出、或者提取误删的文件。恢复操作更刺激。先把源卷卸载确保数据一致umount /data然后执行快照合并lvconvert --merge /dev/data_vg/data_snap合并完成后快照卷会自动消失源卷回到创建快照时的状态。之后重新挂载即可mount -a实操心得我用快照最频繁的场景是升级前“留后路”。比如跑yum update、升级数据库版本、执行大规模数据变更之前先给关键LV打个快照。万一升级出问题了直接合并回滚比自己备份恢复快得多。这个习惯救过我好几次。4.3 快照空间的监控与务实验证快照空间耗尽是个很隐蔽的问题。LV在快照使用期间不断写入新数据coW持续占用快照空间一旦空间满了快照状态会变成invalid无法使用。这时候你连合并都做不了教训很深刻。所以对快照空间要监控。用lvs查看快照卷的使用率lvs会看到类似LV VG Attr LSize Pool Origin Data% data_snap data_vg swi-a-s--- 20.00g data_lv 58.2Data%就是快照空间使用比例。超过80%就必须处理了要么删掉快照重新做要么想办法扩大快照容量。还有一点务必要提醒快照一定要在业务低峰期创建并定期做“可用性验证”。快照创建后最好挂载到临时目录检查一下关键文件是否完好、能否读取。我遇到过几次快照看着创建成功了结果因为写操作触发额外异常导致内容不完整的情况。千万别等到真出事故需要恢复才发现快照是坏的。5. 常见故障与排查实录5.1 开机VG消失明明做对了一切有一种故障很有代表性系统一切正常重启之后发现挂载的LV目录空了df -h一看分不清哪块盘是哪个。查vgs发现VG状态标记为“not found”或者直接消失实际上LVM没有在启动时激活卷组。排查思路上先确认为什么VG没激活看pvscanpvscan如果是PV missing运行vgchange -ay手动激活vgchange -ay激活之后vgs应该能看到VG回来了再挂载目录看数据是否完好。这类问题背后往往有多个原因。一种常见起因是/etc/lvm/lvm.conf里的volume_list设置了白名单而VG没在名单里。另一种是udev滞后导致的识别问题手动激活能解决但下次重启可能复发这时就要检查系统启动顺序必要时在fstab里用x-systemd.device-timeout设置等待时间。5.2 磁盘老化LVM怎么处理磁盘用久了SMART报警这是运维必须面对的现实。LVM的优势在于即使坏盘发生后数据也不一定全丢因为LVM有冗余和恢复机制。如果PV故障但VG里还有冗余比如做了LV镜像LVM会切换到剩余磁盘继续服务。查看状态pvdisplay --readonly关键是尽快换掉故障盘。新盘加入VG后执行数据重同步vgextend data_vg /dev/sdd pvmove /dev/sdb /dev/sdd这个过程就是前面讲的热迁移LVM会把数据一块块信息迁移到新盘上。迁移完成后把损坏盘从VG里移除vgreduce data_vg /dev/sdb如果没有冗余LVM在处理坏盘时更考验你的备份和恢复预案光靠LVM本身救不回来全量数据。所以底线上永远要记住这句话LVM不是备份方案该做的备份必须做。5.3 快照失效与物理卷异常恢复典型的快照失效场景我前面已经提过空间不足导致快照属性变成了invalid。如果你当时还没删可以先腾出空间但要注意即使腾出空间有些版本的LVM也不会自动恢复。最稳妥的办法就是立即把快照删掉重新再打一次快照lvremove /dev/data_vg/data_snap然后重新创建并实时观察使用率。物理卷异常还有另一种常见场景PV元数据丢失或者设备UUID冲突。排查时先用pvscan扫设备然后用pvs --config devices/filtera|/dev/sd.*|这种命令绕过过滤规则或者用pvck检查pvck /dev/sdb对于元数据LVM会在每次变更时自动备份到/etc/lvm/archive/目录必要时可以从这里恢复VG配置。这个目录平时不起眼关键时刻很重要重装系统或者误操作导致LVM配置丢失时它就是救命稻草。5.4 故障速查表最后整理一份直接能对照使用的速查表遇到问题先看表再动手。现象可能原因排查/解决开机后挂载目录为空VG未激活vgchange -ay手动激活检查fstab与lvm.confvgs找不到VGPV设备丢失或UUID冲突pvscan/pvck检查vgcfgrestore恢复元数据lvextend后文件系统没变大忘记扩文件系统ext4执行resize2fsxfs执行xfs_growfs快照无法使用/无法合并快照空间耗尽删除快照重新创建监控Data%保持80%以下pvmove提示Source device missing源PV已经损坏用--abort放弃迁移另找新盘重建镜像LV显示状态为suspendedI/O错误触发挂起检查底层磁盘尝试lvchange -ay恢复一句话经验LVM的操作都要按顺序来先查状态再动手。遇到问题宁可多看几遍pvdisplay、vgdisplay、lvdisplay的输出也不要凭着记忆盲目执行命令。6. 每块盘都适用的LVM管理建议这部分是我这几年在大量系统上折腾LVM之后攒下来的个人体会算不得教条但是每条都很实用。新装的服务器一个VG里面在系统盘上单独划一块分区给根目录剩下的全部空间留给数据盘VG不要一股脑全部分配。分配LV时不要满打满算留个15%到20%的余量在VG里这样后面遇到紧急扩容会有余地。所有挂载在fstab里都用UUID别用/dev/sda1这种路径否则哪次磁盘顺序一变系统起都起不来。快照是个好东西但要有节制地使用。快照不是备份不能替代真正的备份策略。我是这样做的大的变更前打快照并立即验证一次恢复流程变更完成后删除快照。一切正常后数据持久化的责任交给上层备份工具。LVM的元数据目录/etc/lvm/archive/和/etc/lvm/backup/值得纳入你的定期备份体系。这个目录不大但包含了所有卷组的配置信息有了它即使整机挂了、卷组结构丢了都能重建出来。最后再提醒一次xfs不支持缩容生产环境文件系统选型之前先把这点考虑进去。这是纯经验之谈我身边踩过这个坑的人不在少数。一开始图xfs扩容省事结果到需要缩容的时候才发现根本办不到只能走数据迁移的老路。LVM这套东西学起来门槛不高但用起来上限很高。掌握了基础命令能在线上安全地完成扩容、缩容、迁移、快照这四类操作日常存储管理的大部分场景都已经能从容应对了。平时多在小环境里练一练故障恢复遇到生产事故才有底气。