在虚拟环境中，数据不再分散存放在服务器的本地硬盘而是集中存放在共享数据存储中。由于在共享存储中存放了众多虚拟机的业务数据，因此一旦数据存储访问发生故障，其带来的破坏性影响要比传统的物理环境大得多。

　　为了满足虚拟机访问共享存储时对性能的需求，企业环境中大多采用FC SAN存储。本文结合在生产环境中虚拟机访问共享存储发生故障的案例，简要介绍一下如何快速定位并消除故障。

　　vSphere问题初现

　　接到用户反应众多虚拟机无法使用的故障报告后，使用vSphere Client登录到vCenter Server中，在ESXi主机配置选项卡下的存储适配器选项，发现有一个数据存储处于“非活动”状态，尝试执行“全部重新扫描”链接，在弹出的重新扫描窗口，勾选默认的“扫描新的存储设备”以及“扫描新的VMFS卷”，然后点击确认。扫描完成后，发现原来状态为“非活动”的数据存储仍旧不可访问。

图1. 重新扫描存储

　　依次点击“主页”—>“清单”—>“数据存储和数据存储集群”选项，进入到数据存储列表，选中状态为“非活动”的数据存储。如下图所示，选中“任务与事件”选项卡，查看与该数据存储相关的事件。发现大量的错误信息：“与存储设备...连接丢失，路径...已断开”。

图2. 查看数据存储近期事件

　　vSphere问题分析

　　从上述故障可以初步判断，由于ESXi主机无法访问数据存储导致存放在该数据存储上的所有虚拟机都无法访问。在设计SAN网络时，为避免单条链路发生故障，SAN网络中的存储、光纤交换机、主机HBA卡通常采用交叉连接方式，达到通过多条路径访问同一个共享存储的效果。按照通常的思路，我们首先需要判断是否是由于ESXi主机访问存储的某条链路发生故障导致无法访问共享存储。vSphere 5.0支持三种存储路径选择策略固定 (VMware)、最近使用 (VMware)、循环 (VMware)，其含义如下表所示。

表1. vSphere 5.0 存储路径选择策略

　　从上表可以看出，无论选择哪种存储策略，只要有一条路径可用，那么ESXi主机仍旧可以访问共享存储。为了实现更好的负载均衡，建议用户修改默认的存储访问策略，使用“循环 (VMware)”策略。如果是由于链路发生故障导致无法访问共享存储，那么可能的原因就是所有链路同时发生故障。通过检查SAN交换机链路状态没有发现异常，那么故障点可能发生在存储上。

　　vSphere存储问题定位及故障解决

　　在vSphere Client中每个数据存储对应着磁盘阵列上的一个LUN，登录到NetApp存储LUN所在的控制器后，执行lun show命令查看当前控制器上的所有LUN，发现/vol/vol2/lun0的状态为offline。初步判断是由于lun状态不正常导致访问故障的出现，尝试执行lun online /vol/vol2/lun0命令尝试将该lun的状态修改为online。

　　完成lun状态的修改后，需要在ESXi主机上重新扫描数据存储。本文介绍在命令行下重新扫描数据存储的操作。

　　（1） 登录到ESXi主机控制台，按ALT+F1切换到ESXi Shell下。

　　（2） 执行如下命令扫描主机的所有HBA卡：

　　esxcli storage core adapter rescan --all。

　　（3） 如果只想扫描特定的HBA卡，首先需要依次执行如下命令：

　　esxcli storage core adapter list  #列出所有的HBA卡

图3. 查看ESXi主机HBA卡信息

　　esxcli storage core adapter rescan --adapter <vmhba#> #扫描特定的HBA卡。

　　（4） 查看当前挂载的数据存储：df -h

　　（5）  查找新的VMFS数据存储：vmkfstools -V，如果发现了新的数据存储，那么将会自动挂载到/vmfs/volumes/目录下的子目录中，目录名为UUID或者我们预先指定的标签。

　　（6） 再次查看当前挂载的数据存储：df -h

　　（7） 如果之前状态为“不可用”的数据存储仍旧无法访问，那么可能需要重启ESXi主机，对存储进行重新识别。

　　总之，ESXi主机访问SAN数据存储发生故障将会造成大量虚拟机的访问中断。在问题发生时作为虚拟化管理员要快速对问题进行分析，准确定位问题并进行排除，将存储访问中断造成的破坏性影响降至最低，本文结合实际案例为用户解决类似故障提供处理问题的思路及建议。