凌晨一点手机连着震了三下。打开监控一看vCenter里那个存储告警已经变成了红色高亮——ESXi主机上的一个VMFS数据存储容量使用率飙到了97%状态直接挂上了“紧急”。再切到DELL存储管理端一看后端存储池的剩余空间也只剩不到5%。那一瞬间大家都是同一个感觉完蛋今天是别想睡了。这种“VMware ESXi DELL虚拟化存储磁盘容量处于紧急状态”的问题我在过去十年里处理过不下二十次。有自己环境里踩雷也有帮朋友远程救火。每次情况都差不多告警邮件半夜发出来虚拟机还在跑但心里清楚这种状态撑不了太久。一旦数据存储写满虚拟机的磁盘IO会直接冻结所有落盘操作全部挂起整个业务库等于一次性停摆。所以这篇东西不聊理论只聊处理思路和落地操作。如果你是刚接手虚拟化环境的新人或者正在面对一台容量爆红的ESXi主机按我这个排查和处理顺序走一遍大概率能把这颗雷拆掉。1. 先把“容量紧急”这件事拆清楚拿到告警第一反应别急着删文件。虚拟化存储的容量问题往往不是“某个文件太大”这么简单而是多层结构叠加导致的。ESXi数据存储是跑在物理存储之上的一个逻辑层你的DELL存储可能是MD系列、PowerVault系列或者SC系列也可以是戴尔服务器内置的PERC阵列外加DAS存储。无论哪种物理层是存储池和RAID组逻辑层才是你在vCenter里看到的一个个Datastore。1.1 “紧急状态”到底是什么意思VMware的告警阈值一般分两档默认情况下数据存储使用率达到85%时触发“警告”Warning使用率达到95%或者更高时触发“紧急”Critical。而在DELL OpenManage Storage Management或者Unisphere的管理界面里存储池容量也有类似的阈值比如池使用率超过95%会标记为严重。这套告警机制本身是保护性质的但问题在于你不可能在告警发生的那一瞬间才去处理因为从“紧急”到“彻底写满”往往只有一个晚上的时间差。我就见过一台跑着数据库的虚拟机白天看还有3%剩余夜里一个备份任务跑起来日志唰唰涨第二天早上数据存储彻底满了所有Windows Server虚拟机里的系统日志全部报错数据库进程直接hang住。所以在动手之前你需要先回答三个问题告警发生的是哪一层是ESXi的数据存储还是DELL存储后端池告警是持续性的还是突发的持续性的多半是容量规划问题突发的通常是快照、日志、备份文件惹的祸。当前业务能承受多久的停机这个决定了你是走在线处理流程还是需要约维护窗口停业务处理。1.2 容量爆红的四个常见根因我遇到的容量紧急问题九成以上都能归到以下四类快照积压这是最大概率的元凶。虚拟机打了快照之后增量数据全部写在快照文件里快照越积越大原来的VMDK基础盘反而成了“只读层”。有些环境里的虚拟机开了快照之后忘了合并一个快照跑了几个月文件大得吓人。日志和临时文件膨胀Windows的C盘满了会直接影响虚拟机系统但更隐蔽的是应用生成的日志文件比如IIS日志、SQL Server的errorlog、Java应用堆栈日志它们体积变大之后直接把整个Datastore吃掉。模板和ISO镜像残留很多运维人员习惯把安装镜像、操作系统模板直接放在数据存储里一个Windows Server ISO 5到8GB模板几十GB几年下来全是看不见的“存储黑洞”。Thin Provisioning的误判ESXi层面的精简磁盘其实际占用会随着写入增长而变大。如果当初所有虚拟机都是Thick置备那空间占用在创建时就已经锁定了反倒不容易爆用了精简置备之后每台机器都觉得自己“用的不多”但加起来可能远超物理容量。搞清楚根因处理才有方向。下面是详细的排查和操作流程。2. 诊断三步走从vCenter到DELL存储管理端处理容量问题最忌讳的就是凭感觉。没有查清楚问题出在哪一层之前任何删除操作都是拿生产环境冒险。我常用的诊断路径是“先看ESXi数据存储再看虚拟机内部最后查DELL后端”。2.1 第一站vCenter里的Datastore状态用vSphere Client登录到vCenter点击存储视图按使用率排序一眼就能看到哪些数据存储处于“紧急”状态。这时候先记录几个关键数据总容量是多少已使用多少剩余多少这个数据存储上跑着几台虚拟机然后点进数据存储的“文件”标签页把所有文件按大小排序。这一步能帮你快速判断是不是有某个“巨无霸”文件把空间吃了。正常情况下一个数据存储里应该只有虚拟机目录和必要的模板文件如果看到几十GB的vswp文件或者快照文件问题基本就锁定了。提示vCenter里的容量数字是按“文件占用”来统计的它无法反映底层存储池的真实状态。也就是说哪怕ESXi数据存储显示有10%剩余DELL存储池可能已经快满了两者必须一起看。2.2 第二站ESXi主机命令行核实底层数字有时候vCenter界面会卡或者性能数据会延迟直接SSH登录到ESXi主机上用命令行核实一下更靠谱。这里有几个我必须推荐的基础命令df -h这个命令可以从ESXi的视角看每个VMFS卷的使用率。再看一下数据存储的文件列表ls -lh /vmfs/volumes/datastore1/如果想要找一个目录里的大文件可以用du命令du -sh /vmfs/volumes/datastore1/*/用du排一遍那些几十GB的快照目录、备份目录就全暴露出来了。还需要注意一点vSphere Client里显示的使用率有时候会忽略一些系统预留空间但df和du是比较底层的统计更接近真实情况。2.3 第三站DELL存储管理端查物理池ESXi数据存储层面看完了再回头看DELL的存储管理界面。不同型号的DELL存储操作界面不一样MD系列用MD Storage ManagerPowerVault ME系列用PowerVault ManagerSC系列用Dell Storage Manager如果是PowerEdge服务器内置的PERC阵列则用OpenManage Server AdministratorOMSA查看这些工具的共同作用是看清楚物理硬盘组成了几个RAID组或存储池每个池的理论容量是多少热备盘状态如何池实际使用率是多少。如果这里的池使用率已经超过90%那么就算ESXi数据存储还有空间物理层也已经是“肚子快撑破”的状态必须优先处理。实际操作中我习惯把三层数据记录在一张表里对比层级总容量已使用剩余使用率VMware数据存储2.0TB1.94TB60GB97%DELL存储池20TB19TB1TB95%虚拟机内部C盘200GB198GB2GB99%哪一层最先爆掉就从哪一层开始处理。但要注意三层往往是连动的只有同时做清理和扩容才能根治。3. 紧急处置实战从止损到扩容的完整流程诊断结束之后就进入处理阶段。我的处理顺序固定为四步止损、清理、扩容、恢复冗余。顺序不能乱因为如果你先删文件再扩容发现空间还是不够虚拟机可能已经因为IO持续写入而出问题了。3.1 立即止损别让数据存储彻底写满当数据存储使用率超过95%时最先要做的事情是踩刹车。这里的“刹车”有两层含义一是告诉所有同事暂时不要在紧急状态的数据存储上创建新虚拟机、做快照、复制大文件二是检查那些正在高速写入日志的虚拟机必要时暂停它们的日志备份任务我在一次事故处理中就是因为没有第一时间停止某台SQL服务器的凌晨维护作业导致一个晚上时间数据存储从93%直接干到100%最后虚拟机直接IO冻结。所以止损动作一定要快哪怕只是口头通知也比什么都不做好。如果环境里配置了vSphere High AvailabilityHA或者Storage DRS这时候也要检查一下这些自动化功能是否还在正常工作。数据存储空间低于一定阈值时Storage DRS可能会触发迁移操作但如果目标数据存储空间也不足迁移会失败反而增加额外负载。3.2 空间清理实战快照、日志、临时文件逐个击破止损之后开始抢空间。按优先级顺序执行第一步处理虚拟机的快照。用vSphere Client查看每台虚拟机是否有快照。如果有先确认这个快照是最近几小时内创建的比如升级前的备份如果是右键虚拟机→快照→删除快照等待合并完成。这里的“删除快照”不是删除数据而是把快照的增量变化合并回原始VMDK。注意删除快照的操作时间取决于快照文件的大小几十GB的快照可能要等半小时以上。千万不能中途取消否则可能导致虚拟磁盘损坏。对于已经无用的老旧快照删除之后也要确认空间释放情况。我处理过一个案例快照文件显示有120GB但删除之后数据存储只释放了80GB剩下的空间被其他文件占着不得不再做下一步。第二步清理虚拟机内部的大文件。如果快照清理后空间依然紧张接着做虚拟机内部清理。通过vSphere控制台登录到每台虚拟机检查以下几个方面Windows系统的C盘剩余空间清理临时文件夹%TEMP%C:\Windows\TempWindows更新的缓存文件C:\Windows\SoftwareDistribution\Download各数据库日志文件和历史备份文件应用程序日志目录这里的常用工具是Windows自带的“磁盘清理”或者cleanmgr也可以用PowerShell把可执行文件、垃圾缓存一并处理。第三步清理数据存储里的冗余文件。打开vSphere的数据存储浏览器找到那些明显不需要的文件。常见的有过去的旧系统ISO安装镜像长期不用的虚拟机模板备份留下的VMDK副本孤儿vswp文件即虚拟机已关闭但vswp没被清理的残留在删除这些文件之前先确认它们确实没有业务用途。我一般会把疑似不需要的文件先移动到一个“待删除”文件夹观察一周确认没有问题再彻底清理。3.3 扩容操作全解VMFS在线扩容和新增LUN清理只能解决“燃眉之急”如果虚拟机长期增长扩容永远是终局方案。扩容有两个方向给现有数据存储扩容或者新建一个更大的数据存储。方向一给现有VMFS数据存储在线扩容这个过程是在VMware层面完成的。前提是底层的DELL存储还有未分配的空间并且你的LUN已经映射到ESXi主机。操作路径为在vSphere Client中选择目标ESXi主机点击“存储”→ 选择要扩容的VMFS数据存储点击“增加容量”Increase Capacity选择“扩大现有VMFS数据存储”选择空余的存储设备或者扩展设备设置扩容大小点击“确定”整个扩容过程可以在线完成虚拟机不需要停机。扩容完成后数据存储的总容量会立即增加。方向二新增LUN并创建新数据存储这是更常用也更安全的做法。在DELL存储管理端从存储池中划分出一个新的LUN映射给ESXi主机然后在ESXi里执行“新建数据存储”操作选择这个新LUN并格式化为VMFS文件系统。创建完成后需要把这台数据存储上的部分虚拟机迁移过去以此平衡容量压力。迁移方式用Storage vMotion可以在线迁移虚拟机不用停机。3.4 收尾调整告警阈值和存储推荐处理完容量之后必做的收尾工作是调整阈值否则下次告警还会以同样方式提醒你。VMware里可以自定义数据存储的使用率告警阈值比如把“警告”调整到80%“紧急”调整到90%这是给自己留出更充足的反应时间。另外一个重要操作是在DELL存储管理端如果存储池支持自动分级或者分层存储可以根据热点数据情况启用相关功能让热数据放到高性能盘上冷数据下沉到大容量盘上从而减少整体池容量的压力。4. 实操中常见的坑与排查技巧容量处理流程写起来顺实际操作中全是坑。下面这几个问题我在不同环境里反复遇到过单独列出来给大家避雷。4.1 删除快照之后空间没有立即释放最常见的问题。删除快照后vSphere界面显示的数据存储使用率可能半小时都不掉。这不一定代表没释放而是VMFS卷的空间统计有延迟。经验做法是等10到15分钟然后SSH登录ESXi用df -h看实际空间。esxi对VMFS卷的空间管理是延迟回收的这一点不是故障是正常机制。如果过了很久空间确实没有释放需要确认是否还有另一个快照存在或者虚拟机本身处于“已暂停快照”的状态。另外如果虚拟机磁盘是精简置备删除快照后还会有一个“空间重新认领”的过程需要执行esxcli storage vmfs unmap来让底层存储真正回收空间。esxcli storage vmfs unmap --volume-labeldatastore1 --reclaim-unit20484.2 明明删掉了一个大文件但是使用率没变化这种情况大概率是因为删除操作是在Windows虚拟机内部做的而ESXi层面的VMDK文件大小并没有变化。原因在于VMDK是虚拟磁盘文件删除虚拟机内部的文件只会在VMDK内部进行文件空洞不会自动从VMDK释放回数据存储。解决办法是使用esxcli storage vmfs unmap命令执行UNMAP操作让精简置备的VMDK把未使用的块归还给数据存储。前提是底层的DELL存储支持自动精简回收。如果不支持可以考虑定期整理比如每个季度做一次全量UNMAP。4.3 精简置备的“容量幻觉”这是一个非常隐蔽的坑。ESXi用Thin Provisioning创建虚拟磁盘时初始文件很小只有几GB但它会随着虚拟机内部写入逐渐增长。你把一个500GB的精简盘给了一台虚拟机实际复制300GB数据进去VMDK文件就增长到了300GB。如果你给二十台虚拟机都做了500GB精简盘实际每台只用100GB那么总占用是2TB看起来不多。但由于虚拟化环境是多层共享的这2TB的占用已经算进了数据存储容量。如果再叠加快照和系统日志容量爆得比谁都快。应对方案在新环境里尽量合理评估虚拟机真实容量需求重要数据库用Thick置备或者Eager Zeroed Thick普通应用用Thin置备但定期检查增长趋势。4.4 Storage DRS阈值设置不当引发的“假紧急”有集群环境的朋友如果开了Storage DRS会发现数据存储的使用率一直徘徊在85%左右但偶尔会跳到“紧急”状态。这有可能是Storage DRS的I/O负载均衡阈值太敏感导致的I/O平衡建议和容量本身没关系。检查方法是在vSphere Client里看Storage DRS的推荐报告区分是I/O负载迁移还是空间容量迁移。I/O负载迁移只影响性能不影响可用性但如果你把I/O和空间阈值都设置得比较激进会频繁产生迁移动作徒增压力。4.5 扩容后DELL存储LUN映射不对给ESXi扩容时最容易出现的操作失误是在DELL存储上划分了新LUN却没有正确映射给ESXi主机或者映射了但主机没重新扫描。处理方式是在vCenter里选择对应的ESXi主机点击“存储”→“重新扫描存储”让主机重新扫描所有的存储适配器、存储设备然后新LUN才会出现在可用设备列表里。DELL存储上的映射一般有三种方式LUN映射到主机组、LUN映射到主机、LUN映射到端口组。如果之前已经建好了主机组新LUN加入时记得同时加入对应主机否则主机扫描不到设备。4.6 别忘了一个很小的点vSphere HA的心跳数据存储如果集群开启了vSphere HA系统会选择一个数据存储存放心跳文件这个文件非常小只有几MB不会占用太多空间。但问题是如果这个数据存储满了HA可能会失去心跳触发虚拟机在另一台主机上重启造成宕机。所以容量紧急时要特别留意当前告警的数据存储是否就是HA心跳所在的数据存储。如果是清理时的首选迁移目标要避开这台防止HA误判。5. 关于处理优先级的两点心得处理容量紧急问题我踩过不少坑之后总结出两个很重要的原则写在这里供大家参考。第一永远先保数据再保业务。如果数据存储真的满了虚拟机已经IO冻结千万不要强行做快照删除。正确的操作是先给虚拟机关机或挂起再处理否则可能导致虚拟机文件系统损坏甚至整块虚拟磁盘无法挂载。有一次我就遇到虚拟机在满盘状态下直接崩溃结果VMDK的文件系统部分区域损坏被迫用快照文件恢复整个过程折腾了四个小时。第二容量告警类问题能立刻处理的立刻处理不能立刻处理的也要留下一台维护窗口。很多人看到“紧急”两个字觉得很严重但其实如果你每天都有固定的巡检习惯这种问题是可以避免的。我现在每周一都会写一个脚本巡检所有数据存储和DELL存储池的使用率超过80%就在群里发预警。这样发现问题的时候基本不会走到“紧急”这一步。容量管理本质上就是一层窗户纸捅破了之后你会发现处理流程无非就是查、清、扩、防四个字。真正难的是平时有没有养成习惯以及告警真正来临的时候能不能冷静地按顺序操作。希望这篇东西对你有用。