1、现场情况及故障现象
客户现场有2套虚拟化vmware esxi6.7，由于采购的硬件不是同一批次，CPU型号不一致，故分为了两个集群：
集群1：服务器139、服务器140、服务器141；
集群2：服务器200、服务器201。
所有服务器通过2台博科6505的24口的16GB交换机，组成FC-SAN网络。两套集群都使用这3个存储。
存储1是全SATA的慢盘（共12块）、存储2是正常的SAS盘（25块）、存储3是SSD（13块）+SAS（12块）混闪阵列。
前一阵这个存储1上承担了一些高IOPS的任务，由于这个存储1本身配置很低承受不住，导致大部分虚拟机卡顿，后来把这部分业务迁移到到存储3上了，得以缓解。
然而客户这几天突然反映某些业务虚拟机严重卡顿，数据库查询几乎无结果、业务账号登录也没有反应，虚拟机网络也是时断时续，顺着客户提供的IP地址，检查发现是集群1中使用存储1的虚拟机突然十分卡顿，几乎无法办公。
集群1、集群2运行在存储2、存储3 LUN上的虚拟机没有延迟卡顿。
2、排查分析方向
出现这种故障，有以下几点需要考虑：
- ESXI主机资源不足或系统负载过高；
- 是不是存储1又到了SATA盘的性能瓶颈导致业务卡顿；
- 是不是物理链路由于线、模块故障导致误码过多。
3、排查相关问题
1、首先查看集群中主机资源利用情况，资源利用率中规中矩，并没有严重不足。
2、查看这些虚拟机的最近性能指标，发现磁盘延迟巨大。
3、登录虚拟机操作系统查看资源监视器，发现磁盘一直维持到100%最长活动时间、查看进程磁盘响应时间都1000ms延迟左右（这块当时没截图，文字说明一下）。
4、检查下存储端对应情况，发现存储磁盘这边几乎没啥压力，延迟在us级别，LUN的平均响应时间存在波动情况，对应的LUN块带宽也是存在波浪的情况。
初步分析，存储性能应该没有达到瓶颈，这次应该不是出现存储这端性能的问题。
再监控存储上主机的相关指标，发现都存在波浪线的情况，且主机队列长度达到4000以上！！主机的平均I/O响应时间最高达到200以上。看来是链路有问题导致的问题发生。
同时查看一下存储2上的数据指标，在存储2端监控这3台主机没有问题。
5、于是检查了存储1端口误码率，从存储侧来看误码率几乎没有。
6、在两台光交上porterrshow查看，FC-SW1报错也几乎是没有。
FC-SW2上有一些报错但并不多，检查之前有因为调整断过对应的端口，所以这里有些错误，并没有持续增长。
7、于是收集一下fc-san交换机的supportshow，发现其中FC-SW1交换机上有port9端口收发光不正常。TX功率明显低于380uW。
检查port9为服务器201，集群2里的服务器201所在的也使用了存储1，考虑可能是光模块功率导致loop环网络IO提交慢，导致其它与这个存储相连的主机队列长度提高。
于是尝试禁用port9。再观察SAN网络性能有一部分提升，但是就目前的指标来看，队列长度还是挺高，平均IO响应时间仍高达20ms，这对前端业务来说，还是会非常明显。
最后尝试在ESXI上对使用存储的路径进行切换，就是禁用当前路径，让他自动切换到另1个路径去读写，共涉及到3台主机，3个LUN。
尝试几次切换后，再看存储的性能指标都恢复正常了，业务也不再卡顿了。
也就是说使用的某1条存储路径有问题（这里VMWARE使用的是固定路径，没有使用循环，默认只走1条路径，其它链路为备份链路）。
4、后记
与其它友商存储的技术也沟通过类似的案例，这种情况一般是某个物理接口或线缆质量导致的FC网络问题。
通常查看sfphow指标，如果模块显示TX<380uw功率，建议更换16G FC模块(这个16G模块通常故障率比较高)。
问题发生可能的原因是在某个设备1个或多个链路有问题，会导致队列积压（即使是划了ZONE时行了隔离，比如多个服务器都连这1台存储了，那么相关于都在1个loop环里，如果1个提交有问题，其它获取存储资源也会产生等待，具体原因还得再温习一下FC-SAN AL协议相关的原理。）
目前看肯定是这个存储的某个端口链路质量出了问题，可能是存储模块、对应连接的光纤、交换机端的模块，具体还要再分析日志排查，目前问题解决。
