别急着换HBA卡！Linux服务器messages日志狂刷multipath报错，先按这个流程查存储

深夜的告警铃声总是格外刺耳。当你打开终端，看到/var/log/messages里不断刷新的multipathd: ... path is down和I/O error时，第一反应是不是想立刻更换HBA卡？且慢——在存储故障排查中，硬件往往是最无辜的替罪羊。本文将带你建立一套科学的诊断思维，用系统化的方法揪出真正的元凶。

1. 从日志风暴中提取关键信号

面对海量日志时，新手常会陷入两个极端：要么被吓懵，要么盲目搜索解决方案。正确的做法是像老练的侦探那样，先收集所有线索再分析关联性。

1.1 解码multipath日志的隐藏信息

典型的报错日志可能长这样：

Jun 15 03:22:45 node1 multipathd: 8:0:0:0: sdd: path is down Jun 15 03:22:45 node1 kernel: sd 8:0:0:0: [sdd] tag#0 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK Jun 15 03:22:45 node1 kernel: sd 8:0:0:0: [sdd] tag#0 CDB: Read(10) 28 00 00 00 00 00 00 00 08 00

关键字段解析：

• path is down：多路径组件检测到路径失效
• DID_NO_CONNECT：SCSI层连接中断
• Read(10)：故障发生时正在执行的命令

快速过滤命令：

# 按时间范围提取关键日志 grep -E 'multipathd|sd .*FAILED' /var/log/messages | awk -v d1="$(date -d '1 hour ago' '+%b %d %H:%M:%S')" -v d2="$(date '+%b %d %H:%M:%S')" '$0 > d1 && $0 < d2' # 统计各设备错误频率 grep 'path is down' /var/log/messages | awk '{print $NF}' | sort | uniq -c | sort -nr

1.2 区分症状与病因

存储故障常呈现"一因多果"现象。下表对比了不同层级的典型表现：

提示：当看到I/O error时，先记录下对应的SCSI命令（如上面的Read(10)），这能帮助判断是读操作还是写操作触发了故障。

2. 构建三维诊断矩阵

成熟的排错流程需要同时考虑时间维度（何时开始）、空间维度（影响范围）、逻辑维度（配置变更）。

2.1 时间线重建

执行这条命令可以快速建立故障时间轴：

journalctl -u multipathd --since "2 hours ago" --no-pager | grep -A 3 -B 3 'state change'

典型输出示例：

May 20 02:15:11 node1 multipathd: sdb: path state changed from 'active' to 'faulty' May 20 02:15:11 node1 multipathd: 3600a09803830445455244a4a56774b72: remaining active paths: 1 May 20 02:15:13 node1 multipathd: sdc: path state changed from 'active' to 'ghost'

状态转换分析：

• active → faulty：路径彻底失效
• active → ghost：路径时断时续
• faulty → active：路径自动恢复

2.2 拓扑验证

绘制简化的存储拓扑图非常必要。使用这些命令快速获取信息：

# 查看HBA卡信息 lspci | grep -i fibre systool -c fc_host -v # 检查WWN连接状态 cat /sys/class/fc_host/host*/port_name cat /sys/class/fc_host/host*/port_state # 验证交换机端口 echo "show port ${SWITCH_PORT}" | ssh switch_admin

关键验证点：

1. 服务器HBA端口与交换机端口的光功率是否正常（通常在-7dBm到-3dBm之间）
2. 存储前端端口是否显示为logged in状态
3. 多路径配置中的WWN是否与存储映射一致

3. 多路径状态深度解读

multipath -ll的输出就像一本密码书，需要正确解码才能获取有价值的信息。

3.1 状态字段解析

以华为存储的典型输出为例：

3600a09803830445455244a4a56774b72 dm-5 HUAWEI,XSG1 size=10G features='0' hwhandler='0' wp=rw `-+- policy='service-time 0' prio=1 status=enabled |- 8:0:0:0 sdd 8:48 faulty running `- 9:0:0:0 sde 9:32 active ready

重点字段：

• faulty running：路径异常但设备仍在尝试恢复
• active ready：正常工作的路径
• prio=1：路径优先级（存储阵列可能设置了非对称ALUA）

对比诊断法：同时检查正常和异常的LUN路径状态，差异点往往就是突破口。

3.2 路径测试实战

不要依赖静态检查，实际触发IO才能验证路径可靠性：

# 使用dd测试特定路径 dd if=/dev/sdd of=/dev/null bs=1M count=100 iflag=direct # 使用sg3_utils进行底层测试 sg_inq /dev/sdd sg_verify /dev/sdd --ff

注意：测试前确保有业务影响预案，避免在关键生产环境直接操作。

4. 存储阵列侧排查技巧

70%的多路径问题最终发现是存储配置问题。即使你没有存储管理员权限，也能通过这些方法间接验证：

4.1 智能日志关联

收集这些关键信息提供给存储团队：

# 收集SCSI sense数据 grep -i 'sense key' /var/log/messages # 提取设备标识符 udevadm info --query=all --name=/dev/sdd | grep -E 'ID_VENDOR|ID_MODEL|ID_SERIAL'

常见sense key解读：

• sense key=0x6：单元注意（存储可能有配置变更）
• sense key=0x2：设备未就绪（可能LUN被卸载）
• sense key=0x3：介质错误（物理磁盘问题）

4.2 配置变更追溯

突然出现的多路径问题往往与这些操作有关：

• 存储固件升级
• 端口zone配置变更
• LUN迁移或扩容
• 主机组权限调整

使用这条命令检查系统最近变更：

grep -iE 'upgrade|config|change' /var/log/messages | grep -i storage

5. 应急处理与长效防护

当半夜三点面对崩溃的存储系统时，你需要分阶段应对策略。

5.1 紧急恢复步骤

1. 路径隔离：将故障路径移出多路径组

   multipathd -k"fail path sdd"

2. IO重定向：强制使用剩余路径

   echo 1 > /sys/block/dm-5/device/fast_io_fail_tmo

3. 服务降级：对于关键业务，临时切换到本地存储

5.2 防御性配置建议

在/etc/multipath.conf中添加这些优化参数：

defaults { fast_io_fail_tmo 5 # 快速失败避免IO堆积 dev_loss_tmo 30 # 控制设备移除超时 user_friendly_names no # 使用WWN便于追踪 } devices { device { vendor "HUAWEI" product "XSG1" path_grouping_policy group_by_prio # 按ALUA优先级分组 prio alua # 启用ALUA感知 } }

最后记住：存储故障就像密室杀人案，所有路径（线索）都指向HBA卡（那个最明显的嫌疑人）时，往往真凶藏在存储阵列（密室机关）里。保持怀疑精神，用数据说话，才是高级运维的生存之道。