一、组网描述

某学校数据中心虚拟化平台采用SAN存储架构，连接了单存储A，和一套双活存储，通过两台SAN交换机连接至ESXI物理主机，链路冗余。由于双活存储是新建存储，迁移工作正在进行，目前此业务虚拟机dawning还存储在单存储A-LUN01上。2月份某日客户业务虚拟机dawning中SQL server数据库故障，于是对dawning进行Storage vMotion，从单存储A-LUN01迁移至双活存储-LUN02，迁移过程中，由于双活存储-LUN02丢失导致迁移失败。后用户决定从清单中移除此虚拟机，手动从单存储A-LUN01复制虚拟机文件到双活存储-LUN02上。在手动复制文件过程中，有一个名为dawning-000004.vmdk磁盘文件无法复制。提示错误由/vmfs/volumes/********************/dawning-000004.vmdk引起错误。

二、故障现象

1.双活存储-LUN02经常性丢失，在ESXI主机上浏览存储消失；

2.通过vSphere client针对单存储A-LUN01中dawning-000004.vmdk文件无法复制，且dawning虚拟机无法开机启动。

三、处理过程

1.现场一线支持人员紧急处理双活存-LUN02丢失问题，联系存储厂商排查存储问题，检查设备控制器，磁盘，RAID，LUN，ESXI物理主机映射等状态均正常，判断存储端正常。建议检查FC链路。

2.一线支持人员使用专业检测设备检查存储两条上联链路，发现正常，此时双活存储-LUN02状态恢复，单I/O延迟平均4000ms最高 15000ms，访问存储异常缓慢。

3.继续排查链路，征得用户同意后，使用单链路连接存储。经过测试，发现其中一条链路连接的时候I/O延迟明显增高，另外一条链路正常，继续排查此链路，最终定位SAN交换机光模块问题。由与现场没有可更换的模块，暂时使用单链路连接存储。至此存储问题解决，用户文件还是无法复制，用户虚拟机暂未恢复，此时问题升级提交到我司二线技术团队处理。

4.二线人员了解情况后测试发现，dawning-000004.vmdk无论是复制到双活存储-LUN01（双活存储中另外一个LUN），还是自身单存储A-LUN01的不同目录均失败，判断是由于迁移失败后VMware保护机制导致的文件被锁定（下图为示意图）

5.登录到dawning之前运行的ESXI物理主机上，通过命令发现此文件是由dawning-000004.vmdk（磁盘描述文件）和dawning-00004-delta.vmdk(数据文件)文件组成（如下图）。此时才知道，这是一个快照磁盘，检查用户之前复制成功的文件，类似的有9个，说明此虚拟机做了多次快照。继续通过vmkfstools 工具发现磁盘果然被锁定，且显示锁定主机的的UUID。（下图为示意图）

6.通过命令找到此主机，发现此主机上并没有任何进程锁定了此文件，无奈只能强制解锁。

7.解锁后，文件可以复制，文件大小为95GB，但是复制到37GB左右，复制中断。后通过ESXI底层命令复制，发现在一段时间后出现write I/O error 和 read I/O error 复制失败，同样复制到37GB左右，此时怀疑这台单存储问题。

8.用户登录单存储发现，存储做RAID 5 其中已经坏了一块盘，且有一块盘是时好时坏的状态，RAID 5坏2块盘，卷组会失效。存储厂商也无法修复，只能更换坏盘，但不能保证数据是否可用。

9.由于此文件是快照文件，二线人员尝试跳过此文件恢复其余快照。修改快照文件关联ID，逐一恢复，恢复后虚拟机启动，但是没有用户所需要的数据，至此恢复失败。

10.后与用户共同协商，尝试修改vmdk（磁盘描述文件）文件中关于对dawning-000004-delta.vmdk文件的引用，修改dawning-000004.vmdk引用的dawning-000004-delta.vmdk文件位置，采用相对路径定位到单存储中dawning-000004-delta.vmdk文件。（下图为示意图）

修改前：

修改后：

11.恢复虚拟机快照文件关联性，然后添加VMX文件到ESXI清单中，成功启动虚拟机，虚拟机恢复到SQL 故障的时候，数据都在，用户拷贝数据后，继续恢复其业务。

四、解决方案

1.替换SAN 交换机的光模块，解决双活存储LUN-02的间断性丢失问题

2.修改vmdk描述文件引用数据文件-flat.vmdk/-delta.vmdk位置启动虚拟机，使用户能够拷贝SQL server中的数据数据，恢复业务。

3.后续操作：

A、确认业务恢复完成后，弃用此虚拟机

B、更换单存储RAID 5 故障盘

C、重要数据在备份设备上执行备份，周期尽量短，减小恢复时候的数据损失

五、总结及建议

1.重要业务数据一定要经常备份，备份策略的设置一般根据RPO（Recovery Point Objective）来的，通俗的说就是允许数据丢失的量，例如备份策略设置每天备份一次，那么数据出现问题时只能恢复到前一天的数据，这样数据丢失量可能就是一天。对于学校业务，建议数据经常发生变化的业务，在设置备份策略时备份时间一定要短保证数据最新，例如每2天一次完整备份，每3小时一次增量备份，保存6天内数据。对于数据变化不大的业务，备份策略可以设置宽松一点。每周一次完整备份，没天一次增量备份，保存7天内数据。

2.虚拟机快照只是作为临时性的一个备份手段，新建快照的时候同时会锁定原来的磁盘文件重新生成新的快照vmdk，当快照多的时候，新的vmdk也会很多，当虚拟机机读取某一个数据，会先从快照vmdk读取，一级一级向上索引，浪费大量的I/O，降低虚拟机性能，同时虚拟化平台业务很多都是依托于快照进行数据的临时性备份，快照文件多了之后若管理不当也会导致虚拟机的迁移，克隆，备份等操作无法完成，建议在某些关键节点使用快照，对于以前老的快照要及时删除，进行磁盘文件整合，控制快照文件数量，一般不要超过3个。

3.虚拟机出现问题，尽量不要动虚拟机文件，文件是虚拟机的根本，这块出了问题，恢复难度大大增加

4.数据中心可以使用双活存储，分布式存储（融合存储）等来提高物理层面的容错性能，避免单节点故障导致数据丢失。

5.数据中心设备需要经常巡检，及时发现问题，预防为主。