★ FEATURED ARTICLE 1. 从“磁盘满了”说起为什么基础分区不够用了很多人第一次接触Linux存储都是从fdisk分区、mkfs格式化、mount挂载这三板斧开始的。这套流程应付单块磁盘、固定容量的场景确实够用但只要你的机器开始承载真实业务很快就会撞上墙。我印象很深的一次是帮朋友处理一台跑着数据库的服务器日志分区突然写满服务直接卡死。当时那块盘总共就200G日志、数据、备份全挤在一起想扩容只能停机加盘、重新分区、迁移数据折腾了大半天。那次之后我才真正意识到基础分区管理解决的是“能用”的问题而高级存储管理解决的是“好用、能扛、能长大”的问题。所谓Linux高级存储管理核心要回答三个问题第一磁盘空间能不能按需伸缩而不是一开始就切死第二多块物理磁盘能不能拼成一个逻辑大池子统一调度第三数据能不能在硬件出问题时自动兜底而不是等坏了才去救。围绕这三个问题Linux生态里演化出了几套成熟的机制最典型的就是LVM逻辑卷管理、RAID磁盘阵列、磁盘配额以及交换空间swap的精细调优。这几样东西不是孤立的实际生产里往往是组合使用底层用RAID保证冗余上面盖一层LVM做弹性伸缩再对关键目录做配额限制最后用swap兜住内存峰值。这篇文章面向的是已经会基本分区操作、想往系统管理方向深入的读者。我会把LVM、RAID、配额、swap这几块拆开讲透重点不是背命令而是讲清楚每一步背后的设计意图以及我在实际环境里踩过的坑。命令会给出可直接复制的版本但更重要的是让你明白“为什么这么配”。如果你正在维护一台数据越来越大的服务器或者准备考系统管理相关的认证这篇内容应该能帮你少走不少弯路。2. LVM逻辑卷管理把磁盘变成可以揉捏的橡皮泥2.1 物理卷、卷组、逻辑卷的三层抽象到底在解决什么LVM的全称是Logical Volume Manager逻辑卷管理。它的价值用一句话概括把物理磁盘的边界打破让存储空间像橡皮泥一样可以随时拉伸和收缩。传统分区一旦划好大小就锁死了想改只能备份、删分区、重建、恢复风险极高。LVM在物理磁盘和文件系统之间插入了一层抽象把整个过程变成了在线操作。理解LVM的关键是搞清它的三层结构。最底层是物理卷PV你可以把它理解成“被LVM接管的一块砖”这块砖可以是整块磁盘也可以是磁盘上的一个分区。中间层是卷组VG它是把多块砖砌成的一面墙所有PV的空间汇总到VG里形成一个统一的存储池。最上层是逻辑卷LV它是从这面墙上切下来的一块块可用空间你格式化、挂载、读写数据操作的都是LV。这个模型的好处在于LV的大小和底层PV的物理位置解耦了扩容时只要VG里还有空闲空间就能直接给LV加容量文件系统在线扩展业务完全无感。我习惯用一个类比来解释PV是散装的水泥袋VG是把水泥倒进一个大搅拌池LV是从池子里舀出来装进不同模具的成品。你想多做一块成品只要池子里还有料就行不用管这些料原来来自哪袋水泥。这个解耦就是LVM全部魔力的来源。2.2 从零搭建一套LVM命令背后的每一步意图假设你手上有两块新盘/dev/sdb和/dev/sdc各100G目标是做一个能弹性伸缩的数据卷。完整流程分四步我逐步说明每步在干什么。第一步创建物理卷。命令是pvcreate /dev/sdb /dev/sdc。这条命令会在磁盘头部写入LVM的元数据标签标记“这块盘归LVM管了”。执行完可以用pvs查看输出里会显示每块PV的大小和所属VG。这里有个细节如果磁盘之前有分区表或文件系统残留pvcreate会提示确认覆盖生产环境务必确认盘是干净的别把有数据的盘误初始化了。第二步创建卷组。命令是vgcreate data_vg /dev/sdb /dev/sdc。这一步把两块PV合并成一个叫data_vg的池子总容量约200G。用vgs可以看到VG的总大小、已用和剩余空间。VG的名字自己起建议见名知意比如按用途叫data_vg、log_vg后期维护时一眼能看懂。第三步创建逻辑卷。命令是lvcreate -L 50G -n data_lv data_vg。这表示从data_vg里切出50G命名为data_lv。-L指定具体大小也可以用-l按PE数量或百分比分配比如-l 50%VG表示拿一半。创建完用lvs查看会看到LV的路径通常是/dev/data_vg/data_lv。第四步格式化和挂载。mkfs.ext4 /dev/data_vg/data_lv格式化然后mount挂载到目标目录。到这里一套LVM就跑起来了。你会发现整个过程中LV就像一个普通分区一样使用但它的背后是可以随时调整的。2.3 在线扩容与缩容哪些操作安全哪些是雷区LVM最常用的操作是扩容而且扩容比缩容安全得多。给LV扩容分两种情况VG里还有空闲空间或者没有。如果有空闲直接lvextend -L 20G /dev/data_vg/data_lv然后根据文件系统类型扩展。ext4用resize2fs /dev/data_vg/data_lvxfs用xfs_growfs /挂载点。注意xfs只能扩不能缩这是它的设计限制选文件系统时要想清楚。如果VG没空间了就得先加新盘pvcreate新盘vgextend data_vg /dev/sdd把新盘并入VG然后再扩LV。整个过程业务不用停这是LVM最爽的地方。缩容就是另一回事了必须极其谨慎。顺序和扩容相反先缩文件系统再缩LV。以ext4为例要先umount卸载然后e2fsck -f强制检查再resize2fs缩到目标大小最后lvreduce缩LV。任何一步顺序错了或者缩得比文件系统实际占用还小数据直接损坏。我的建议是生产环境尽量不做缩容如果非要缩先完整备份宁可多花时间也别赌。xfs则根本不支持缩容遇到要缩的场景只能备份重建。提示扩容前用df -h确认文件系统当前用量缩容目标必须大于实际数据量并留出余量一般建议至少多留10%。2.4 快照LVM给数据留的“后悔药”LVM还有一个被低估的功能快照。快照不是完整复制而是基于写时复制机制记录某一时刻卷的状态。创建命令是lvcreate -L 10G -s -n data_snap /dev/data_vg/data_lv-s表示快照-L是给快照分配的COW空间。这个空间不用等于原卷大小但要足够容纳快照存续期间原卷发生的变化量。快照最实用的场景是备份。比如你要备份数据库直接拷贝正在写入的文件可能不一致但可以先打一个快照然后从快照里读数据原卷继续正常读写互不干扰。备份完删掉快照即可。这里有个坑如果快照空间被写满快照会失效变成不可用状态所以快照存续时间不能太长COW空间也要给足。我一般按“原卷日变化量×预计保留天数×1.5”来估算。3. RAID磁盘阵列用多块盘的组合换可靠性和速度3.1 RAID 0/1/5/10的取舍没有最好只有最合适RAID的核心思想是用多块磁盘组合出一个逻辑盘通过冗余或并行来提升可靠性或性能。常见级别就那么几个但选错的人不少。我用一张表把关键差异摆出来。级别最少盘数可用容量冗余能力读性能写性能典型场景RAID 02全部之和无高高临时缓存、可重建数据RAID 12单盘容量允许坏1块高中系统盘、小容量关键数据RAID 53盘数减1允许坏1块高中读多写少的通用存储RAID 104一半视组合可坏多块高高数据库、高并发写入RAID 0把数据条带化分散到多盘速度最快但一块坏全盘完只适合能随时重建的临时数据。RAID 1是镜像两块盘写一样的内容坏一块还有一块容量利用率只有50%适合放系统盘。RAID 5用奇偶校验实现单盘容错容量利用率高但写入时要计算校验值写性能是短板而且重建时压力大。RAID 10是先镜像再条带兼顾性能和安全代价是容量利用率只有一半是数据库场景的常客。选型的逻辑很简单先问数据丢了能不能重建再问读写哪个更频繁最后看预算能买几块盘。能重建的数据用RAID 0省钱不能丢又读多的用RAID 5不能丢又写多的用RAID 10。3.2 软RAID的创建与日常维护Linux用mdadm工具管理软RAID。以创建RAID 5为例假设有三块盘/dev/sdb、/dev/sdc、/dev/sdd命令是mdadm --create /dev/md0 --level5 --raid-devices3 /dev/sdb /dev/sdc /dev/sdd。创建后系统会有一个/dev/md0设备像普通盘一样格式化和挂载。创建完要用mdadm --detail /dev/md0查看状态确认State是clean、Active Devices数量正确。RAID 5在创建时会做一次同步cat /proc/mdstat能看到进度同步期间性能会下降建议在业务低峰期做。日常维护里最重要的是监控。软RAID不会主动弹窗告诉你盘坏了得自己盯。cat /proc/mdstat能看到阵列状态如果某块盘显示(F)就是故障了。更省事的做法是配一个定时任务定期检查mdadm --detail的输出发现degraded就告警。盘坏了之后热插拔换上新盘用mdadm --manage /dev/md0 --add /dev/sde把新盘加进去阵列会自动重建。重建期间性能会明显下降而且如果此时再坏一块盘RAID 5就彻底崩了所以重建要尽快同时避免在重建期间做高负载操作。3.3 硬件RAID与软RAID什么时候该花钱软RAID靠CPU计算校验会占用一部分CPU资源性能不如硬件RAID。硬件RAID卡自带处理芯片和缓存对操作系统透明性能好、不占主机CPU还支持带电池的写缓存。但硬件RAID卡贵而且一旦卡坏了往往要同型号卡才能读盘存在厂商锁定风险。我的经验是小规模、预算有限、对性能不极致要求的场景软RAID完全够用现在CPU性能过剩软RAID的额外开销可以接受。但如果是数据库这类对IO延迟敏感、写入量大的场景硬件RAID卡带来的稳定性和缓存加速是值得投入的。另外云环境里通常直接用云厂商提供的块存储底层RAID已经封装好了你不需要自己管这时候关注点应该放在云盘的类型选择和多副本策略上。4. 磁盘配额给每个用户划一条不能越过的线4.1 配额解决的是“公共资源被一个人吃光”的问题一台多用户共用的服务器最怕的就是某个用户往自己目录里狂写文件把整个分区撑满导致其他人没法工作。磁盘配额就是给每个用户或用户组设定一个用量上限超过就写不进去。它管的是“公平”不是“安全”但在一台共享机器上公平本身就是一种安全。配额分两个维度容量和文件数量。容量限制的是占多少空间文件数限制的是能建多少个inode。两个维度又各有软限制和硬限制硬限制是绝对红线碰到就报错软限制是警告线超过后给一个宽限期宽限期内还能写超期就按硬限制处理。宽限期默认7天可以调整。4.2 开启配额的完整流程与容易忽略的挂载选项配额不是默认开启的要在挂载时就声明。以ext4为例编辑/etc/fstab在目标分区的挂载选项里加上usrquota,grpquota比如/dev/data_vg/data_lv /data ext4 defaults,usrquota,grpquota 0 0。改完mount -o remount /data重新挂载或者重启。接着要生成配额数据库文件命令是quotacheck -cugm /data-c创建、-u用户、-g组、-m强制以读写方式检查。然后quotaon /data开启配额。这两步做完配额才真正生效。设置配额用edquota -u 用户名会打开一个编辑器里面显示当前用量和软硬限制改完保存即可。批量设置可以用edquota -p 模板用户 目标用户复制模板。查看用quota -u 用户名或repquota /data看全量。这里有个特别容易踩的坑配额只对挂载点生效且只统计该挂载点下的文件。如果用户通过软链接或绑定挂载绕到别的路径写数据配额管不到。另外root用户默认不受配额限制别指望用配额去限制管理员。4.3 配额监控与超限后的处理配额超限后用户写入会收到Disk quota exceeded错误。作为管理员要能快速定位是谁超了。repquota -a能列出所有用户的用量和是否超限warnquota可以配置成自动给超限用户发邮件提醒。宽限期到了之后软限制会变成硬限制用户必须清理文件才能继续写。如果某个用户长期超限又联系不上管理员可以用edquota -t调整宽限期或者直接手动清理。我的建议是配额值不要设得太紧留出合理余量否则用户正常业务也会被卡反而增加沟通成本。一般按用户职责预估用量再上浮20%到30%作为硬限制。5. Swap交换空间内存不够时的缓冲垫但别当主力5.1 swap到底在什么情况下才真正被用上swap是磁盘上的一块空间当物理内存不够时内核把不常用的内存页挪到swap里腾出内存给活跃进程。很多人以为swap是“内存扩展”其实它的定位是应急缓冲不是性能方案。磁盘的速度比内存慢几个数量级一旦系统频繁读写swap性能会断崖式下跌这就是所谓的“swap抖动”。swap真正被用上的场景其实有限一是内存确实不够又不想立刻杀进程二是系统休眠时需要把内存内容写到swap三是一些程序启动时申请大块内存但实际用得少swap能兜住。对于数据库这类对延迟敏感的服务通常建议尽量不用swap或者把vm.swappiness调低让内核优先回收缓存而不是换出进程内存。5.2 swap分区、swap文件与swap大小的合理估算swap有两种形式独立分区和文件。分区性能略好但大小固定调整麻烦文件灵活可以随时创建和调整大小现代内核下性能差距已经很小。创建swap文件的命令是dd if/dev/zero of/swapfile bs1M count4096生成4G文件然后chmod 600 /swapfile、mkswap /swapfile、swapon /swapfile。要开机自动挂载在/etc/fstab里加一行/swapfile none swap sw 0 0。swap大小怎么定老规矩是内存的1到2倍但这在内存动辄几十上百G的今天已经过时了。我的经验是内存小于8G时swap给内存的1到2倍内存8G到64G时swap给4G到8G固定值内存超过64G除非要休眠否则给个2G到4G意思一下就行。因为大内存机器上真到了要靠swap救命的时候说明内存规划本身就有问题给再多swap也只是延缓崩溃。5.3 swappiness调优与swap使用情况的判断vm.swappiness这个内核参数控制内核换出内存的积极程度取值0到100默认60。值越高越倾向于用swap值越低越倾向于保留内存。对于服务器我一般调到10让内核尽量不动swap只在万不得已时才用。命令是sysctl vm.swappiness10临时生效写进/etc/sysctl.conf永久生效。判断swap是否被过度使用看free -h里的swap used以及vmstat 1里的si和so两列。si是每秒从swap读入内存的量so是每秒从内存写到swap的量。如果这两个值长期非零说明内存压力已经很大了该考虑加内存或者优化程序内存占用了。sar -W也能看swap的换入换出统计。记住一句话swap used高不一定是坏事但si/so持续高一定是坏事。6. 组合实战一套面向数据库的存储方案怎么搭6.1 分层设计RAID打底、LVM做弹性、配额兜底把前面几块拼起来我给一套实际用过的方案。假设一台数据库服务器有四块500G的SSD目标是把数据、日志、备份分开管理还要能在线扩容。底层用RAID 10四块盘两两镜像再条带兼顾性能和安全可用容量约1T。在RAID之上建LVM把/dev/md0做成PV建一个db_vg卷组。然后从VG里切出三个LVdata_lv给数据库数据目录log_lv给日志backup_lv给本地备份。这样每个部分独立日志写满不会影响数据备份也不会挤占数据空间。配额用在多实例场景如果一台机器上跑多个数据库实例给每个实例的数据目录设配额防止某个实例失控拖垮整机。swap按内存大小配同时把swappiness调到10。6.2 扩容演练从磁盘告警到在线加容量的完整链路假设某天监控告警data_lv使用率超过85%。处理链路是这样的先vgs看db_vg还有没有剩余空间。如果有直接lvextend -L 100G /dev/db_vg/data_lv然后xfs_growfs或resize2fs扩展文件系统全程在线业务无感。如果VG没空间了加新盘。pvcreate /dev/sdevgextend db_vg /dev/sde再扩LV。如果连盘位都没了那就得考虑迁移到更大的存储或者清理历史数据。这个链路的关键是每一步都可回退、可验证扩容前记录当前df -h和lvs输出扩容后再对比确认避免扩错卷。6.3 监控指标与告警阈值别等写满了才发现存储管理最怕的就是“事后救火”。我建议至少监控这几个指标各LV的使用率、VG剩余空间、RAID阵列状态、swap的si/so、inode使用率。使用率告警阈值设两档80%预警、90%严重告警给自己留出处理时间。inode容易被忽略小文件多的场景inode先耗尽表现是“明明还有空间却写不进去”用df -i查看。RAID状态监控可以写个脚本定期跑mdadm --detail解析State字段发现degraded或failed就触发告警。swap的si/so用vmstat采样连续多个周期非零就告警。这些监控不需要多复杂的系统一个定时脚本加邮件或消息通知就能覆盖大部分风险。7. 那些年踩过的存储坑几条用教训换来的经验7.1 扩容成功但文件系统没扩最容易漏的一步我见过不止一次有人lvextend扩了LVlvs看容量确实大了但df -h还是老样子以为扩容失败。原因是LV扩容和文件系统扩容是两回事lvextend只动了逻辑卷这层文件系统那层还得单独扩。ext4用resize2fsxfs用xfs_growfs。现在有些发行版的lvextend支持-r参数自动扩展文件系统能省一步但不是所有版本都支持手动扩最稳妥。养成习惯扩完LV立刻扩文件系统然后用df -h确认。7.2 快照空间写满导致失效COW不是无限容量LVM快照的COW空间是有限的原卷写入量超过快照空间后快照就失效了lvs里会显示Invalid。这时候快照不能用于恢复只能删掉重建。所以打快照前一定要估算好变化量快照存续时间尽量短备份完立刻删。如果原卷写入非常频繁快照空间要给得足够大或者干脆用其他备份机制。7.3 软RAID重建期间再坏一块盘RAID 5的致命窗口RAID 5只允许坏一块盘重建期间如果第二块盘也坏了整个阵列的数据就全没了。重建过程可能持续几小时甚至更久这段时间阵列处于无保护状态。所以RAID 5的盘最好来自不同批次降低同时故障的概率重建期间尽量避免高负载操作加快重建速度重要数据不要只依赖RAID 5要有异地或离线备份。预算允许的话RAID 6能容忍双盘故障安全性更高代价是多一块盘的容量。7.4 配额开了但没生效挂载选项和数据库文件都要检查配额不生效最常见的原因是挂载选项没加usrquota,grpquota或者加了但没重新挂载。另一个隐蔽原因是配额数据库没生成或没开启。排查顺序是mount | grep 挂载点确认选项quotaon -p 挂载点看配额是否开启repquota看有没有数据。还有一个坑是某些文件系统或某些挂载方式下配额支持有限选文件系统时要确认。8. 写在最后存储管理的核心是“留有余地”折腾了这么多存储相关的事我最大的体会是存储管理的本质不是把空间用到极致而是始终留有余地。VG里永远留一部分空闲空间别一次分完RAID别等到盘坏了才想起没做冗余配额别卡得太死swap别指望它扛性能。这些“余地”平时看不出价值但真出事的时候它们就是你和数据丢失之间的那道墙。另外任何存储操作前先确认备份可用。扩容、缩容、改RAID、调配额这些操作都有风险备份是唯一的后悔药。命令可以查文档参数可以试但数据没了就真没了。我现在的习惯是动存储之前先跑一遍备份验证确认能恢复再动手。这个习惯救过我几次也希望能帮到你。
阅读完成 · 觉得有帮助？
