/ /
近期国内疫情大幅好转，很多小伙伴的工作已经步入正轨，积极投身到复工复产中，正如我们在上期技术人生中提到了，越是在这个时候，运维小伙伴们越是要守住红线。
话不多说，马上进入我们本期的技术人生——一场与时间的赛跑。
/ 系统中毒了？ / /
一个月黑风高的晚上，我刚刚进入梦乡，突然响起的手机铃声好像晴天霹雳，让我一下坐了起来。凌晨1:11，我知道来大活了……电话那端服务台的同事已经有点声音扭曲了，“十万火急，XX客户虚拟机全挂了，业务受到严重影响，客户已经赶赴现场了，你也赶紧过去吧！”
我知道，这注定又是一个不眠之夜，打开滴滴，迅速输入目的地，用凉水洗脸精神一下，收拾行装，出发……
在车上，我联系了客户技术负责人，“我们这里好像中毒了，也有可能是被人攻击了，20台虚拟机全挂了，大家都在赶往现场的路上，见面说吧！”客户焦急的语气告诉我，这次的故障很严重。
/ 与时间赛跑 / /
到场，办理手续，进入机房。还没来得及了解具体情况，我就听到了客户领导下达的死命令，“这17台虚拟机早晨7:00前必须都起来，不然影响我们交易，这就是生产事故！”其实我挺理解客户的心情，但是我告诉自己，越是着急越是要静下心来，焦虑解决不了任何问题。
2:30，我登陆了客户的虚拟化平台，距离客户规定的时间还有4个半小时。
客户的环境总共20台虚拟机，17台生产，3台测试。随机找了其中一台虚拟机，打开控制台，无法显示系统状态，换了一台，情况亦然。客户工程师说，“起初他们怀疑中毒了，经过检查也排除了。”马上检查日志，发现有大量存储卷的报错，查看datastore，红色告警，共享存储卷使用率已达100%，数据无法写入，不能正常运行的虚拟机全部位于共享存储，后端存储也无空间可分。
3:10，问题基本定位，存储空间满了，导致虚拟机挂了，距离客户规定的时间还有不到4个小时。
我与客户沟通，首先关闭无法访问的虚拟机释放存储空间，优先恢复重要的虚拟机。随着空间的释放，虚拟机开始慢慢恢复，1台、2台、3台.……到第15台，还都一切正常。正当在场的人都觉得可以松一口气的时候，第16台虚拟机恢复时，出现报错，打开电源失败：
4:10，第16台虚拟机打开电源失败，距离客户规定的时间还有不到3个小时。
我马上对第16台虚拟机文件进行检查，发现虚拟机编辑设置中虚拟机磁盘文件大小变成了0，检查虚拟机对应数据存储中文件夹的数据，发现虚拟机vmdk文件（虚拟磁盘）不见了，消失了，现场的几个人面面相觑…….
我告诉自己不要慌，继续仔细往下搜索，找到了一个-flat.vmdk文件。看到-flat.vmdk文件后，我微放松了一口气——数据文件还在，只是vmdk描述文件丢失……不幸中的万幸，与客户沟通修复数据的办法，继续进行下一步。
4:30，开始修复数据，距离客户规定时间还剩下2个半小时。
我打开ESXi主机，SSH服务登录虚拟机，命令切换到虚拟机所在数据存储卷目录下：
▶查看虚拟机vmx描述文件确定虚拟机磁盘所用的SCSI控制器类型。
▶查看虚拟机数据磁盘的大小。
▶执行vmkfstools命令创建一个新磁盘，新磁盘大小与要修复磁盘大小，ISCSI类型保持一致。
▶当前数据存储目录生成 temp.vmdk和temp-flat.vmdk文件，我们只需要temp.vmdk文件，可直接将tem-flat.vmdk删除，将temp.vmdk改名为rhel69.vmdk去匹配rhel69.vmx数据文件中的vmdk文件配置。
▶对新的rhel69.vmdk进行编辑，修改文件中的temp-flat.vmdk为rhel69-flat.vmdk，用于关联rhel69-flat.vmdk数据文件（如虚拟机磁盘非精简模式非精简将ddb.thinProvisioned删除）。
4:50，对虚拟机进行开机，成功启动，进行业务验证。
5:10，紧接着对第17台生产虚拟机进行了恢复验证。
6:00，所有17台生产虚拟机恢复正常。经过大家的共同努力，我们提前1个小时，完成了客户的要求，确保了客户白天交易的正常进行。
但导致这次故障的根本原因还没解决。由于共享存储空间不足，在与客户沟通后，我将两台测试虚拟机迁移至本地磁盘，并验证系统启动正常。
6:30，本次故障得到了圆满解决。
/ 一点总结 / /
故障解决了，一颗悬着的心终于放了下来。虽然一夜未眠，但我还是想趁热打铁，把自己想到的几个小问题写下来，可能对其他小伙伴有些帮助吧。
一、为什么磁盘空间会暴涨到100%呢？
经过检查发现虚拟机中有三台测试、两台生产虚拟机磁盘采用了精简制备的磁盘模式，导致存储卷存在超额分配的现象，当采用精简置备的虚拟机系统数据增长将占用存储卷剩余空间。
二、为什么关闭些虚拟机磁盘空间就会释放一部分，磁盘空间不是满了吗？
这是因为虚拟机默认配置时在虚拟机启动后会在虚拟机数据存储文件中生成一个和内存等大的.swap文件用于内存不足时缓存使用，当关机后.swap文件空间将自动释放。
三、如何预防这种事故的发生？
我的建议是增加存储卷，并使用存储迁移将使用精简置备磁盘的虚拟机到新存储卷上，将磁盘模式改为厚置备。
生产虚拟机和测试虚拟机分开存放，避免测试虚拟机做测试时占用大量计算和存储资源影响生产系统。共享的存储空间使用率需根据存储卷的大小，存储卷的超额分配情况及数据增长速度设置合理的监控告警阈值（默认使用率达到75%警示告警，使用率达到85%警告告警），对共享存储的使用率及告警阈值要有实时监控，发现问题及时处理。
/ / / /
本期技术人生就到这里了，欢迎大家在评论区与我们互动。如果大家希望了解哪些技术方向的案例可以在评论区里给我们留言哦~
- end -
关注 “中亦科技” 公众号
查看更多精彩文章
