【案例分享】NetApp FAS8040 的 LUN09 “卡壳” ？教你轻松解锁访问难题

一、问题概述

6月5日晚，客户反映某一台VMware虚拟平台上的aqsj_fbscj1业务虚拟机HUNG死，强制关机后无法启动，初步检查虚拟机所在lun09访问异常，同一存储映射过来的lun，仅lun09访问异常（可读不可写），且虚拟机迁移也失败。

虚拟机开机报错：

虚拟机所在lun09访问异常：

CLI界面下读写报错：

在VC图形界面访问存储池下的LUN09，并在其目录下创建文件测试失败：

二、问题处理过程

2.1 VMware上检查lun09状态

Lun09使用容量未满，1.98TB的容量，可用空间还剩1.08TB。

能查看lun09下的文件，但写入创建文件仍然异常。

2.2 检查Netapp存储运行状态

针对lun9所属FAS8040-01-HF_C05存储运行状态进行初步检查，存在”disk 0d.30.19 does not have two paths to controller FAS8040-01-HF_05……”报错，其它无异常。

但disk 0d.30.19硬盘仍处于Normal正常运行状态，未达到触发热备盘自动顶替降级盘的阀值，初步判断该磁盘单链路运行报警与本次问题无关。

2.3 检查光交机运行状态

经收集光交机的完整日志进行初步分析检查，DCX_D11_14_27U 光交机上未发现异常

DCX_D12_14_27U 光交机上也未发现异常

最近变更只是针对两台新服务器划了新zone配置

6月5日20点左右（时间慢1小时）在DCX_D12_14_27U 光交机上也只有port 163这个端口重新fabriclog记录

检查这个163端口对端模块发光有点弱，主要会影响到webdb2_fcs1、itjkdb2_fcs0和hailiangdb2_fcs0相关主机访问存储的链路，和本次问题无关。

2.4 Netapp存储深度检查

检查LUN09的存储空间状态正常，LUN所在卷的可用空间正常，截图如下：

所有LUN都处于正常联机状态，并且配置为分配空间预留的模式，即非精简配置LUN。

查看lun09所在聚合磁盘的指标正常，没有出现热点盘（即负载过高、延迟过大、利用率接近100%的盘），截图如下：

2.5 VMware深度检查

通过ssh到4台ESXi宿主机，访问到LUN09所在volumes目录下，创建和删除文件测试，发现仅IP为12的ESXi宿主机读写LUN09异常，其它3台宿主机读写正常。

主机和LUN09的事件日志里有很多由于连接性问题失去naa.xxx（LUN09的naa id）的访问权限

vmkernel.log日志有很多关于LUN09的power-on reset 消息，频繁刷NMP 错误代码：H:0x8 D:0x2 P:0x0 Valid sense data: 0xe 0x1d 0x0

当前所有vmfs3格式的存储包括LUN09的锁定模式为public，即混合使用ATS+SCSI预留两种锁定模式。

三、问题分析与建议

3.1 相关KB参考

3.1.1 NetApp

NetApp官网KB描述了相似的问题与日志：

https://kb-cn.netapp.com/data-mgmt/OTV/VSC_Kbs/VMware_Atomic_Test_and_Set_heartbeats_impact_connectivity_to_storage#

a. 此KB解释了两种LUN锁定机制，描述了同时使用两种锁定模式可能会造成以下问题：

b. 解决方案是仅使用一种锁定模式，例如仅使用ATS或者仅使用SCSI预留锁定。

c. 如果需要改为仅使用ATS，则需要卸载存储重新使用仅ATS参数挂载，这需要停止上面的所有虚拟机。

3.1.2 Dell EMC

Dell官网KB链接：

https://www.dell.com/support/kbdoc/zh-cn/000035613/dell-unity-vnx-%E4%BB%8E%E7%89%88%E6%9C%AC-5-5-u2-%E5%8F%8A%E6%9B%B4%E9%AB%98%E7%89%88%E6%9C%AC%E5%BC%80%E5%A7%8B-esxi-%E4%B8%BB%E6%9C%BA%E4%B8%8A%E5%87%BA%E7%8E%B0%E9%9A%8F%E6%9C%BA%E4%B8%B4%E6%97%B6%E8%BF%9E%E6%8E%A5%E4%B8%A2%E5%A4%B1%E5%92%8C-%E6%88%96%E6%80%A7%E8%83%BD%E4%B8%8B%E9%99%8D-%E7%94%A8%E6%88%B7%E5%8F%AF%E7%BA%A0%E6%AD%A3

a. 虽然此环境未使用DELL EMC存储，但此KB表明了ESXI5.5在同时使用两种锁定模式时，ATS锁定可能会导致性能下降甚至间歇性丢失存储访问。该问题是旧版本ESXI的bug，在ESXI5.5.X和ESXI6.0.X版本均可能会出现。这说明该问题通常不局限于存储供应商。

b. 推荐的解决方案是禁用ATS

3.1.3 VMware

VMware | Broadcom官网KB链接：

https://knowledge.broadcom.com/external/article?legacyId=2113956

该KB给出了禁用/启用ATS的方法，对于同时使用两种模式的vmfs，禁用ATS可以即时生效，无需执行重新挂载存储或者重启主机的操作。

3.2 问题维护建议

本次问题主要影响到计算资源跑在IP为12的ESXi宿主机上，且存储在LUN09磁盘上的业务虚拟机，出问题时相关业务已经及时切换到备用业务虚拟机上，未影响业务的持续性。

经综合分析后，整理出如下3点维护建议：

1、针对VMFS3的LUN，将“Public(ATS+SCSI)”数据存储锁定模式修改为“SCSI”模式，即禁用ATS锁定，仅使用“SCSI”锁定模式，规避“Public(ATS+SCSI)”混合模式下偶发锁定冲突导致LUN无法访问的已知KB问题，修改后观察IP12 ESXi访问LUN09是否能恢复正常读写。

2、如果修改仅使用“SCSI”锁定模式后，LUN09仍不能恢复正常读写，需要安排维护窗口，重启IP为12的ESXi宿主机。重启前需要迁移跑在宿主机上的所有虚拟机，其中邮件服务器的虚拟机由于挂载着RDM直通的磁盘，不能在线迁移，需停机迁移。

3、 NetApp FAS8040存储底层检查所有LUN并无异常，且没有热点盘影响性能的问题存在，整体运行虽正常，但毕竟已上线十几年，不仅设备老化，硬件故障率高，随着虚拟机业务量和数据量的日趋增长，原本几百GB不到的一个虚拟机，现在已占用到十几TB，对存储的性能和容量要求都更高了，该老旧存储已经无法满足当下虚拟机业务的长期稳定运行，建议更新换代使用新存储。

四、问题修复方案

4.1 确认所有vmfs3存储的锁定模式

a. 此配置是主机级别，请依次SSH四台ESXI，然后对所有vmfs3类型的数据存储执行以下命令检查锁定模式是否为public,请注意替换实际的datastore_name