虚拟机之痛-- 记生产环境虚机存储故障

虚拟化技术的普及给IT工作者带来了极大的便利，同时使用虚拟化的企业也应该问问自己的技术储备是否能保证虚拟化环境的安全与稳定。

不要因为虚拟化环境的稳定运行，我们就可以对放松对虚拟化环境的监控与管理。至少应该考虑一个问题，如果虚拟化的存储出问题了，

我们是否准备好了应对方案。感谢虚拟化技术的创作者们。

引子：

VMware 虚拟化环境扩容，由于厂商的工程师认为这个操作比较简单，这个工作轻车熟路，没啥子风险，所以也就没有做回滚方案。

环境概述：

新搭建VMware Vcenter5.5 中包含三台新的VMware ESXI5.5，并挂了一个新的存储。

故障起因：

 当把三台新的VMware ESXI5.5 去认旧环境的VMware ESXI5.0使用的存储的过程中，可能由于老存储的IO过高，最终导致旧环境的虚机操作系统故障。

故障现象：

大部分虚拟机文件系统为READ-ONLY状态，由于不能写入，导致业务中断。所幸只影响Linux系统，Windows系统未受影响。

解决办法：

重启操作系统，用fsck进行修复。

疑难杂症：

其中一个虚机多次尝试无法修复。幸亏有一年前的一个快照，用快照恢复后，又更新了程序，服务才得以恢复正常。

以上简单介绍了虚机扩容过程中遇到的一个问题，从而导致生产环境服务中断的案例。希望能给使用虚拟化技术的朋友们敲一个警钟：

对生产环境的任何改变都应该心存敬畏，要有回滚方案。不要因为简单而肆无忌惮，最终导致悲剧发生。

后记：

试想那个用fsck没有修复成功的虚机，如果没有快照，也没有完整的备份，我们该怎么办呢？

备份重于一切，稳定压倒一切，望每一个IT工作者都应时刻铭记于心。