早晨刚泡好咖啡手机告警推送就响了。vSphere Client打开一看某个DELL服务器承载的VMFS数据存储容量直接亮红——“紧急”状态。对很多虚拟化运维同事来说这画面再熟悉不过VMware ESXi DELL虚拟化存储几乎是中小机房的标配组合而“容量紧急”这类告警又是最常见的存储问题之一。这里想把整套处理链路单独拿出来讲清楚因为相当一部分人看到“紧急”两个字就条件反射式地决定加盘结果加完盘发现几天后又报警甚至有的环境连业务虚拟机都没能保住——根子往往不是硬件容量本身而是快照堆积、日志膨胀或者磁盘规划出了问题。先说结论存储容量进入“紧急”状态不等于立刻宕机但如果不及时处理虚拟机I/O会被阻塞甚至挂起尤其当多台ESXi共享同一个LUN时影响面会被成倍放大。所以这类问题的处理顺序非常关键先应急保住业务再定位根因扩容最后做防复发的机制设计。下面按我实际处理过的流程一步步拆解。1. 从“黄色”到“红色”vSphere存储容量告警机制解读很多人看到“紧急”就慌了但说实话这个状态本身就是vSphere的告警机制在按预设阈值工作理解阈值逻辑是第一步。1.1 vCenter告警阈值的默认设置与计算逻辑vCenter Server对数据存储容量的监控有一套默认阈值在vSphere 6.x及之后的版本中数据存储容量使用达到85%时触发黄色警告达到95%时触发红色紧急告警。这两个百分比对应的是“已用容量 / 总容量”而不是“剩余容量”。很多新手第一次看告警会看反以为95%是“剩余95%”结果把紧急状态当成了健康状态这个细节务必注意。阈值触发后vCenter会记录一条事件并按照你配置的通知方式发送邮件或SNMP Trap。也就是说你收到“存储容量处于紧急状态”的邮件时其实vCenter已经忍了很久了——它先给过黄色警告只是大多数人没在黄色阶段处理一直拖到了红色。这里有一个隐藏问题默认阈值是“一刀切”的固定比例并不区分LUN大小。一个10TB的大LUN到95%时还剩余500GB空间管理员有充足时间处理但一个300GB的小LUN到95%时只剩余15GB可能连快照合并的临时空间都不够处理窗口非常短。所以越小的数据存储越不应该等到95%才动手。1.2 存储状态从“正常”到“紧急”的演变链路告警不是瞬间出现的它通常经历一个过程数据存储容量缓慢或快速上升达到85%触发黄色告警。虚拟机仍在继续写入容量继续攀升。达到95%状态变为红色“紧急”。vCenter发送告警通知数据存储在界面上显示为红色感叹号。但如果你以为“只有到95%才影响业务”那就错了。VMFS文件系统本身需要预留一些元数据空间和临时操作空间当容量极度紧缺时一些常见的运维操作会先出问题创建快照失败、快照删除合并卡住、虚拟机迁移失败、甚至虚拟机挂起后无法恢复。我见过一个生产环境数据存储100%写满后虚拟机直接进入了Paused状态I/O完全阻塞只能通过紧急腾挪空间才能恢复。这类故障最麻烦的地方在于很多应急操作本身也需要空间。删除快照需要临时空间进行合并迁移虚拟机需要目标空间所以越是到红色紧急状态你的操作空间就越小能用的手段也越少。这就是为什么“防患于未然”比“紧急处理”重要得多。1.3 别只看数字哪些容量消耗最容易低估排查容量问题时我一般会把空间占用分成四类来盘虚拟机磁盘文件VMDK这是最大头的部分但也是最容易估算的部分。快照Delta文件名字类似vmname-000001.vmdk是虚拟机的增量文件会随业务写入持续变大但界面上不直接显示大小非常隐蔽。ISO镜像、模板、备份暂存文件这类文件经常被遗忘在数据存储里一个Windows安装ISO就能占掉5GB。日志与临时文件ESXi主机的/vmfs/volumes下如果有虚拟机放置了日志目录或者虚拟机内部日志增长到上百GB都不是新鲜事。四类里快照和临时文件是最值得优先处理的因为它们通常不是业务必需品删掉后业务不受影响。虚拟机磁盘文件则要看实际情况不能乱动。2. 诊断确认先定位谁在占用空间告警只是告诉你“存储紧急”了但没告诉你“谁导致的”。在动手扩容之前必须先确诊。这一步做得越细后续处理就越有针对性。我见过有人不看占用分布直接加了一块盘结果加完之后才发现空间都堆在同一台虚拟机的快照上加盘等于白加。2.1 在vSphere Client中定位告警数据存储打开vSphere Client进入“存储”视图先看数据存储列表。重点不是看告警颜色而是看三列数据容量、已置备、已用空间。容量物理LUN的总大小。已置备所有虚拟机配置磁盘大小的总和可以大于容量Overcommit。已用空间实际写入的数据量其中包含VMDK实际大小、快照、ISO等所有文件。如果“已置备”远大于“容量”说明这个数据存储存在超分Overcommit虚拟机配置的磁盘总额已经超过物理容量。这类环境一旦多台虚拟机同时开始大量写入容量就会快速打满。如果“已用空间”接近“容量”说明数据存储上已经有大量文件积压需要进一步下钻到目录级别看明细。2.2 逐个虚拟机检查磁盘占用与快照文件界面看的是整体具体到虚拟机级别需要命令行辅助。ESXi主机开启SSH后可以登录到主机上操作。先列出数据存储上的所有虚拟机vim-cmd vmsvc/getallvms拿到虚拟机ID之后查看某个虚拟机的磁盘和快照信息vim-cmd vmsvc/get.summary [vmid]但最直观的还是直接用du命令按目录统计占用du -h --max-depth1 /vmfs/volumes/your-datastore/注意ESXi自带的busybox版本对--max-depth参数支持可能不完全如果命令报错可以改为du -h /vmfs/volumes/your-datastore/*这样会把数据存储根目录下每个子目录通常每台虚拟机是一个目录的大小列出来一眼就能看出哪个虚拟机目录是“大头”。进入目标虚拟机目录后重点看有没有-delta.vmdk或-0000xx.vmdk这类快照文件以及-flat.vmdk的大小是否与虚拟机配置的磁盘大小一致。这里要提醒一个很容易忽略的点如果虚拟机在创建时选择了厚置备Thick Provision那么-flat.vmdk文件会立即占据与配置容量一样大的物理空间即使guest OS里只用了10GB物理上也会占用100GB。这类虚拟机越多数据存储的可用空间越容易被“预占”掉。反过来说如果虚拟机是精简置备Thin Provision-flat.vmdk大小会随实际使用增长相对可控。排查时看到“配置容量100GB文件用量10GB”的情况基本可以确认是厚置备或Eager Zeroed Thick。2.3 DELL硬件侧排查从iDRAC到PERC控制器的状态检查软件层定位完虚拟机占用之后还要把DELL硬件层扫一遍。这不是走过场因为“容量紧急”有可能是硬件层故障引起的假象。如果这台DELL服务器是PowerEdge系列本地盘通过PERCPowerEdge RAID Controller控制器管理那么进入iDRAC管理界面查看“存储”菜单下的物理磁盘和虚拟磁盘状态。重点看虚拟磁盘VD的状态是不是“Online”有没有出现“Degraded”或“Rebuilding”。如果RAID组里的某块物理盘故障或降级VD容量并不会减少但性能会明显下降虚拟机写入变慢数据存储占用率也可能因为日志堆积而异常增长。如果有条件在ESXi主机上装Dell EMC OpenManage插件或OMSAOpenManage Server Administrator可以直接在命令行查看PERC状态omreport storage vdisk controller0 omreport storage pdisk controller0如果是外部DELL存储阵列比如PowerVault ME4系列则进入存储管理界面检查存储池容量、卷映射和物理磁盘健康状态。确认LUN是否有扩容空间或者是否需要在阵列侧新建卷。这一步的结果会直接决定后面是“扩展现有LUN”还是“新加LUN并迁移数据”。3. 应急处理不重启业务的前提下迅速腾出空间确诊之后如果数据存储还有一点剩余空间优先做定点清理。注意应急处理的优先级不是“哪个文件大先删哪个”而是“哪个操作对业务影响最小、风险最低、释放空间最快”。3.1 第一优先级清理过期快照与临时文件快照是存储空间的第一大杀手而且它有“滚雪球”效应——虚拟机一直在写快照Delta文件就会持续增大。更麻烦的是很多虚拟化平台的备份软件为了保证一致性会先打快照再备份如果备份流程异常中断快照就一直挂在虚拟机上不释放。删除快照的操作不复杂在vSphere Client中选中虚拟机右键“快照”-“管理快照”选中不需要的快照后点击“删除”或“删除全部”。命令行方式也可以vim-cmd vmsvc/snapshot.get [vmid] vim-cmd vmsvc/snapshot.remove [vmid] [snapshotId]但这地方有个大坑删除快照的过程是把Delta文件中的数据合并回基础VMDK合并操作本身需要临时空间。如果在红色告警状态下剩余空间小于快照文件大小快照删除可能会卡住甚至一直停留在“正在删除”状态。所以有一类常见做法是先清掉ISO、日志、模板等非关键文件腾出一部分空间再回头删快照。另一个优先级高且安全的清理项是临时文件。数据存储里常见的临时目录包括备份软件工作目录、vCenter导出日志目录、手工拷贝的ISO/驱动包、过期的vm-support包等。这些文件删掉不影响任何业务也不需要合并操作释放空间立竿见影。3.2 第二优先级处理日志轮转与swap文件如果快照和临时文件已经清了一轮空间还是吃紧就要考虑虚拟机的日志和swap文件。虚拟机内部产生的日志文件通常不会直接显示在VMDK外面但会在VMDK内部持续占用空间。如果虚拟机里有应用疯狂写日志比如Tomcat的catalina.out、Windows的C盘日志要先登录guest OS清理然后通过压缩VMDK或迁移虚拟机来释放数据存储空间——这个操作无法在线完成一般建议在维护窗口做这里不展开。ESXi主机本身也有日志落盘问题。当主机设置的Syslog.global.logDir指向本地数据存储时vmkernel.log、hostd.log、vpxa.log等文件可能持续增长。可以登录ESXi主机检查df -h ls -lh /var/log/vmware/ /var/log/旧日志直接清理或者调整日志轮转策略避免日志把数据存储写满。这是一个非常容易被忽略的点尤其是刚部署完ESXi的主机默认日志路径如果配置不当长时间运行后日志体积会非常可观。swap文件.vswp在虚拟机内存配置较大且没有设置内存预留时会自动创建在虚拟机目录下大小等于虚拟机配置的内存减去预留部分。对一台配置了64GB内存、没有预留的虚拟机来说swap文件就会占用64GB。这个文件在虚拟机运行期间不能删除但可以调整虚拟机的内存预留值来缩小它调整后需要重启虚拟机生效。如果条件允许也可以把swap文件位置改成独立的低占用数据存储。3.3 如果你发现ESXi本身已经无法进入管理界面极端情况下数据存储写满可能导致vCSA或ESXi管理服务异常——表现为vCenter登录后看不到主机或者ESXi的DCUI直接控制台界面响应迟钝。此时不要慌先区分是vCenter失联还是ESXi agent失联。vCenter失联登录ESXi主机DCUI本地控制台或iDRAC远程控制台按F2进入系统配置查看“Troubleshooting Options”里SSH/ESXi Shell是否可用。SSH可用的话登进去用df -h查看哪些分区满了。ESXi agent失联通常是/scratch分区或/var/log所在分区写满导致hostd等进程异常。这种情况优先清理日志。如果SSH和DCUI都进不去只能重启ESXi主机——别忘了先通过iDRAC确认服务器状态并在维护窗口操作。重启之后VMFS数据存储会重新挂载只要不是存储本身损坏业务虚拟机在ESXi启动后通常可以手动或自动注册回来。这个极端场景下关键教训是永远不要让存储容量到100%才处理保留至少10%的安全余量既是给快照合并留空间也是给管理操作留退路。4. DELL硬件层面的空间释放与扩容评估应急腾挪只是治标数据存储容量还是不够用的话最终还是要落到扩容上。DELL服务器加存储扩容这条路线很多人以为“插块盘就行”实际上绕不开RAID组的概念。4.1 分析物理存储布局RAID组、虚拟磁盘与主机映射在DELL PowerEdge服务器上物理磁盘要先组成RAID组Array再划分虚拟磁盘VD虚拟磁盘最终作为LUN呈现给ESXi。ESXi在这个LUN上创建VMFS文件系统虚拟机VMDK才落在上面。所以“给ESXi扩容”可能发生在这几层中的任何一层物理磁盘层添加新的物理磁盘扩展RAID组容量。虚拟磁盘层在RAID组容量允许的情况下扩展VD的容量。VMFS文件系统层在LUN容量扩大后扩展数据存储。排查时进入PERC配置界面开机按CtrlR或者通过iDRAC/OMSA查看当前RAID组里的物理盘数量、容量以及VD大小。如果VD容量已经等于RAID组总容量说明硬件层没有富余空间必须加盘如果VD比RAID组总容量小还有空闲容量没有划分给这个VD那就可以直接扩VD。4.2 添加新物理磁盘扩展VD容量有空的硬盘位时添加新物理磁盘扩展VD是相对稳妥的方案。操作路线是确认服务器有空闲盘位并且新磁盘规格与现有RAID组容量校验匹配如果现有RAID组是4块2TB盘组成的RAID5那新盘最好也是同规格。关机状态插入新磁盘部分DELL服务器支持热插拔但建议确认控制器和背板支持。开机进入PERC配置界面选择“Virtual Disk Management”-“Reconfigure Virtual Disks”把新盘加入现有RAID组。保存配置后PERC会在后台执行“On-line Capacity ExpansionOCE”这个过程不影响线上数据但RAID组在重建期间性能会受影响。OCE完成后VD容量变大ESXi侧重新扫描后就能看到更大的LUN。这里有一个容易踩的坑掰热备盘去扩容。有些服务器配了热备盘管理员见RAID组空间不够就顺手把热备盘拉进RAID组。如果这块热备盘是同一RAID组里唯一的保护机制你等于把数据安全置于裸奔状态。真遇到这种情况宁可关一个业务虚拟机腾出空间也别动热备盘。如果你用的是外置Dell EMC存储阵列流程会更简单在存储管理界面把存储池里未分配的空间分配到现有卷上或者新建一个卷并映射给主机然后在ESXi侧执行存储扫描Rescan。相比之下外置存储在扩容灵活性和热插拔支持上确实优于服务器内置RAID。4.3 在线扩容成功后VMFS层的扩展操作无论哪种方式LUN容量扩大后ESXi不会自动把新空间并入现有数据存储需要手动扩展。在vSphere Client中操作选择目标数据存储点击“增加容量”按钮选择“扩展现有VMFS数据存储”系统会列出同一个LUN上可用的未分配空间。确认后直接执行整个过程不需要停虚拟机也不会中断业务I/O。执行完成后数据存储容量列会变为新的更大数值。需要注意这段扩展只在VMFS层面增加空间虚拟机内的磁盘大小并不会自动变大。如果业务侧确实需要更大的磁盘空间还要到虚拟机级别做“扩展磁盘”再到guest OS里扩展文件系统。三步缺一不可很多人做完第一步就以为完事了结果数据库还是报磁盘满——因为guest OS看到的C盘/D盘根本没变。5. 数据存储从“紧急”恢复正常扩容后的验证步骤扩容完成不代表事情结束了。我习惯把“验证”分成三个维度来做文件系统层、虚拟机层、监控层每层都要看到明确结果才闭环。5.1 扩展VMFS数据存储的常用方法与场景选择“增加容量”至少有两种路径一种是扩展现有VMFS数据存储把新增空间直接并入原LUN另一种是新建VMFS数据存储把新增LUN格式化为新数据存储然后迁移虚拟机。这两种路径的应用场景完全不同扩展现有数据存储适合所有虚拟机分散在同一个数据存储上、不想动现有布局的场景。操作快、不需要迁移、不存在虚拟机路径变化的问题。新建数据存储并迁移适合原有数据存储文件布局混乱、想借机整理或者需要把不同业务虚拟机拆分到独立存储的场景。缺点是迁移会带来一定的性能开销和计划内影响。如果是单台ESXi主机一般扩展VD后直接走“扩展现有VMFS”就够。如果环境是vSAN或者有多个主机共享存储建议优先考虑新数据存储的路径因为可以顺便实现存储侧的负载均衡。5.2 虚拟机磁盘VMDK扩容时的注意事项数据存储扩容后要按业务需求决定是否扩容虚拟机磁盘。注意虚拟机磁盘扩展操作本身是支持在线进行的不需要关机。在vSphere Client中编辑虚拟机设置找到目标硬盘把“容量”改成更大的值即可。但真正容易出错的是扩展之后guest OS层面的处理。Windows虚拟机扩展完VMDK后打开“磁盘管理”能看到磁盘尾部有一段未分配空间。右键对应分区选择“扩展卷”把未分配空间并入系统分区或数据分区。如果分区使用了BitLocker或某些第三方加密软件可能无法在线扩展需要额外处理。Linux虚拟机则更麻烦一点。以ext4文件系统为例扩展分区和文件系统是两步# 扩展分区示例具体盘符以实际为准 growpart /dev/sda 1 # 扩展文件系统 resize2fs /dev/sda1如果是XFS文件系统最后一步要换成xfs_growfs /这些操作在虚拟机内执行时建议先确认文件系统健康状态重要数据提前备份避免误操作损坏分区表。5.3 验证告警状态恢复正常与业务影响评估完成VMFS扩展和虚拟机磁盘扩展后回到vSphere Client等待一两分钟的刷新数据存储状态会从红色“紧急”恢复为正常绿色。同时可以在“监控”-“告警”中确认告警事件被清除。我还会额外做一步观察24小时内的容量增长趋势和虚拟机性能。具体操作方法是在vSphere“监控”-“性能”中选择目标数据存储关注IO延迟、读写吞吐量、已用容量曲线。如果扩容后马上又被大量写入塞满说明不是容量不够而是有把空间“吃掉”的运行负载比如日志疯狂增长或者快照再次堆积这时候就要回到诊断阶段重新排查。另外一个常常被忽略的验证项检查虚拟机快照是否正常可以创建和删除。在红色状态下快照功能可能因为空间不足被阻塞扩容后测试一下快照的创建和删除链路能确保备份软件后续运行不受影响。6. 踩过坑之后为什么你的“紧急”总是反复出现处理完一次紧急状态如果不做复盘大概率三个月后还会再来一次。我总结了几条最容易被忽视的根因每条都是真实环境里反复出现过的。6.1 快照生命周期管理没有落地存储反复报警最典型的原因就是快照没人管。备份软件创建的快照、运维人员手动打的快照、虚拟机升级前打的回滚快照全堆在数据存储里。快照不是备份它只是一个增量文件不仅占空间还会拖慢虚拟机性能。建议的做法是用PowerCLI定期扫描快照超过策略时限的自动删除。示例脚本Get-VM | Get-Snapshot | Where-Object { $_.Created -lt (Get-Date).AddHours(-24) } | Remove-Snapshot -Confirm:$false把这段脚本放在vCenter的调度任务里每天跑一次基本能杜绝快照长期堆积的问题。如果你的备份软件是Veeam或同类工具备份完成后快照会自动清理但一旦备份失败快照残留仍然需要外部巡检兜底。6.2 告警阈值从未调整一套默认值走天下默认的黄色85%、红色95%对某些环境来说太晚了。我一般把阈值分成两类数据存储规模黄色告警红色告警处理策略1TB以下75%85%提前介入避免小空间快速打满1TB~5TB80%90%留足快照合并临时空间5TB以上85%92%大空间容错性好但仍需关注增长趋势调整位置在vCenter的“告警定义”中选择数据存储的“容量”事件编辑阈值即可。同时建议配置告警通知邮件让相关人员第一时间收到消息。6.3 容量监控报表缺失等到报警才动手告警只是底线更好的做法是主动监控趋势。vCenter本身有容量报告但生成不方便vRealize OperationsvROps可以预测容量趋势但对小环境来说成本偏高。更轻量的方案是写个小脚本用PowerCLI定期拉取所有数据存储容量和虚拟机快照信息输出成表格Get-Datastore | Select-Object Name, CapacityGB, FreeSpaceGB, {NUsedPercent;E{[math]::Round(($_.CapacityGB - $_.FreeSpaceGB)/$_.CapacityGB*100,2)}} | Export-Csv capacity_report.csv -NoTypeInformation每周一跑一次容量涨到80%就提前规划黄色阶段就能把问题消化掉根本不给你等到红色紧急的机会。6.4 制定你自己的存储容量应急预案最后也是最重要的一步把这次处理经验沉淀成一份可执行的应急预案。我的清单里至少包含这些内容告警触发后的处理顺序先清快照-再清临时文件-再评估扩容。责任人谁负责登录vCenter查看告警、谁负责联系硬件运维确认DELL存储状态。硬件扩容流程确认RAID组状态、添加新盘/扩展LUN、重新扫描、扩展VMFS。备用措施如果数据存储完全写满优先选择哪台虚拟机可以安全关机或迁移提前列好清单避免现场拍脑袋。预案不需要复杂但一定要写下来并发给相关同事。虚拟化环境里最贵的时间是决策时间——当你已经站在红色告警面前才去想“怎么办”决策时间必然被拉长风险也随之放大。说一个我自己切身的体会。早些年处理过一次存储紧急状态当时因为快照删除合并失败不得不把一台核心数据库虚拟机从数据存储里迁移出去腾空间整个过程花了将近六个小时期间业务做了两次暂停窗口。后来我把快照巡检脚本和容量周报固化下来连续两年再没出现过红色告警。这让我意识到绝大多数存储容量事件不是“硬件不够”而是“管理缺失”造成的。如果你正在为反复出现的“紧急”状态头疼不妨先把顺序反过来不要急着买硬盘先看看你的快照、日志和阈值配置有没有管好。想彻底解决问题功夫在平常。
