一起VSAN故障的处理过程

事情是这样的，单位有一个虚拟化的vsan测试环境，4台服务器，资源使用上，内存使用率平均75%，vsan磁盘使用率75%左右，这是环境背景。

6月3日下午，一个系统需求增加磁盘空间，该系统已分配4T磁盘空间，同事就去关掉虚拟机电源，准备进行磁盘扩容，这个时候意外发生了，虚拟机所在的主机与vcenter失去联系，vcenter不能控制这台主机了，vsan磁盘组丢失了该主机的磁盘组，随后需要扩容的虚拟机也无法登录，但是这台主机上的其他虚拟机可以ping通，也可以登录，但是当时没确认其它虚拟机可不可以使用。这种情况下，也不敢动了，虽说是测试环境，也不能随便停机啊，同事说等明早关机处理一下，所以就这么放着，放到了第二天。

第二天，一早到单位，同事未到，主机重启估计不能进行了，怀着担心的心情，笔者再次看下环境，状态还是那样，没敢动啊！

同事到了以后，也看了一下，没什么进展，也没有重启，等呗。这个时候另一台主机告警ssd磁盘故障，这下问题大了，4台主机的环境坏掉两台，整合环境的数据就要狒狒了。一听这事同事估计也怕了，去机房处理其它事了。

这个时候开始有其他同事开始反应虚拟机有问题了，可以登录，但是不能用，执行命令没有反应，环境是笔者管的啊，笔者不能不管啊。赶紧跟领导汇报了事情的情况，先把昨天有问题的主机重启一下，列出可能影响的虚拟机，也就是跑在这台主机上的虚拟机，实际上可能其它虚拟机也有问题，没有时间去管了。赶紧去机房把昨天有问题的主机重启，命令重启已不管用了，最后只能按电源键强制关机了。

重启完成后，该主机恢复正常了，但是报ssd磁盘故障那台主机的磁盘组掉了。这个时候接到开发岗电话，部分虚拟机登录后报用户没有写权限，root户也没有，咋回事？想了很多，没办法，就把有问题的虚拟机重启了一下，问题解决了，事后想可能是vsan磁盘组被破坏，影响了磁盘的读写权限。

接下来就开始处理ssd故障的主机了，这里也走了弯路，就不多说了，一定要记住的是要从vsan磁盘管理先把故障ssd磁盘组卸载掉，否则新加入的ssd不识别，就要通过命令行解决了。卸载磁盘组，迁移数据，更换ssd，将更换的ssd磁盘组加入vsan，问题终于都解决了。