📚 课程目录第4章存储网络故障诊断

4. 存储网络故障诊断

存储网络是Dell存储系统（如PowerStore、PowerMax、Unity XT、PowerScale）与主机之间数据通路的“血管”。当业务出现卷不可见、I/O超时、路径丢失或性能骤降时，故障点往往不在存储阵列本身，而在FC、iSCSI或NVMe over Fabrics（NVMe-oF）链路的某一层。本节围绕三类链路的共性排查逻辑展开，重点覆盖Zone配置、交换机端口状态、HBA队列深度以及多路径软件（PowerPath/MPIO）异常处理。

一、先建立分层排查模型

存储网络故障排查最忌讳“跳步”。建议按物理层→链路层→网络/交换层→主机层→多路径层→存储前端口的顺序逐层收敛。FC链路关注HBA端口、SFP、光纤、交换机端口、Zone、WWN；iSCSI链路关注网卡、IP可达性、VLAN、MTU、iSCSI会话、CHAP；NVMe-oF则同时具备FC-NVMe与NVMe/TCP两种承载，前者沿用FC物理与Zone逻辑，后者依赖IP网络与NVMe子系统NQN。下图给出三类链路的分层排查关系，可作为现场诊断的定位骨架。

二、FC链路：Zone与端口状态是首要嫌疑

FC故障中，最常见的是“主机HBA能亮灯，但看不到存储LUN”。此时先看交换机端口状态：switchshow输出中，端口应为Online，类型为F_Port（连接主机HBA）或E_Port（ISL级联）。若显示No_Light，检查SFP、光纤、光功率；若显示In_Sync但无流量，检查Zone。Zone配置的核心是“WWN对WWN”或“WWN对端口”的成员关系，且必须被正确加入ZoneSet并生效。常见错误包括：Zone成员写错WWN、ZoneSet未激活、主机与存储不在同一Zone、单交换机多Zone配置未提交。

排查命令示例（Brocade/Cisco通用思路）：

# Brocade 查看端口与Zone
switchshow
zoneshow
cfgshow
# Cisco MDS 查看端口与Zone
show interface fc1/1
show zoneset active vsan 10
show flogi database vsan 10

判断依据：zoneshow中应能看到主机HBA WWN与存储前端WWN同时出现在同一Zone；flogi database中应能看到主机和存储的WWN均已登录。若WWN未登录，问题在物理链路或HBA配置；若已登录但Zone无成员，问题在Zone配置。

三、iSCSI链路：IP可达不等于存储可达

iSCSI故障常表现为“ping通但无法登录目标”。排查顺序为：网卡状态→IP/VLAN→MTU→iSCSI会话→CHAP→多路径发现。首先确认主机iSCSI网卡与存储前端端口在同一VLAN或路由可达，且MTU一致。若启用Jumbo Frame（MTU 9000），需端到端一致，否则会出现大包丢失、登录超时或性能异常。其次检查iSCSI会话：Linux下iscsiadm -m session应显示LOGGED_IN；Windows下可在iSCSI发起程序中查看“已连接”。若会话失败，检查目标门户IP、端口3260、CHAP用户名密码及反向CHAP配置。

# Linux 发现与登录
iscsiadm -m discovery -t sendtargets -p 192.168.10.50:3260
iscsiadm -m node -T iqn.2024-01.com.dell:powerstore -p 192.168.10.50:3260 -l
iscsiadm -m session -P 3

若会话已登录但多路径只显示一条路径，通常是发现时只添加了一个目标门户，或存储端未将主机IQN加入主机组。此时需在存储侧确认主机IQN与LUN映射，并在主机侧重新执行发现，确保两个存储前端IP均被识别。

四、NVMe over Fabrics：NQN与控制器状态

NVMe-oF分为FC-NVMe与NVMe/TCP。FC-NVMe沿用FC物理与Zone，但主机侧使用NVMe驱动而非SCSI，排查时需确认nvme list-subsys中控制器状态为live，且命名空间已映射。NVMe/TCP则需检查IP可达性、NQN配置与端口4420。常见问题是主机NQN与存储子系统NQN不匹配，或未在存储侧创建主机条目。排查命令：

nvme discover -t tcp -a 192.168.10.50 -s 4420
nvme connect -t tcp -n nqn.2024-01.com.dell:powerstore -a 192.168.10.50 -s 4420
nvme list-subsys
nvme list

若nvme list-subsys显示控制器为connecting或resetting，优先检查网络丢包、MTU与存储前端端口状态；若为live但无命名空间，检查存储侧命名空间映射与主机NQN绑定。

五、HBA队列深度与多路径异常处理

队列深度（Queue Depth）决定主机HBA可同时下发的I/O数量。FC HBA默认队列深度通常为32或64，若存储前端端口或交换机出现拥塞，过高的队列深度会放大延迟，表现为I/O超时但链路状态正常。排查时可在主机侧查看HBA参数，并结合交换机端口错误计数（如enc_out、crc_err）判断是否存在丢帧。若错误计数持续增长，应先解决物理层问题，再调整队列深度。

多路径软件方面，Dell环境常用PowerPath（Windows/Linux）与原生MPIO。PowerPath异常常见为路径dead或unlicensed；MPIO异常常见为“仅一条Active路径”或“路径频繁切换”。处理思路：先确认所有路径在操作系统层可见（powermt display dev=all或mpclaim -s -d），再检查存储侧前端端口是否均在线、Zone是否包含所有路径WWN。若某条路径dead，可尝试powermt restore或重新扫描磁盘；若路径频繁切换，检查交换机ISL稳定性与存储前端端口负载。

现场排查建议：先看“路径数量是否完整”，再看“路径状态是否Active/Optimized”，最后看“I/O是否超时”。三者顺序不可颠倒，否则容易在错误层面反复调整。

六、快速排查清单（示例）

检查项	FC	iSCSI	NVMe-oF
物理/链路	HBA灯、SFP、光纤	网卡Up、网线	FC物理或IP可达
交换配置	端口Online、Zone生效	VLAN、MTU一致	Zone或TCP端口4420
主机识别	WWN登录、LUN可见	IQN登录、会话LOGGED_IN	NQN匹配、控制器live
多路径	PowerPath/MPIO路径数	多门户发现	多控制器路径
性能参数	队列深度、错误计数	MTU、丢包	队列深度、控制器状态

实际排障时，建议先通过存储管理界面确认前端端口与主机组映射无误，再回到主机侧逐层验证。FC重点在Zone与端口状态，iSCSI重点在IP/VLAN/MTU与会话，NVMe-oF重点在NQN与控制器状态；而HBA队列深度与多路径异常往往是在“链路已通但性能或冗余异常”阶段的最后一道检查。掌握这套分层逻辑，可将大部分存储网络故障在30分钟内定位到具体层。