从一条multipathd告警看Linux存储链路排查的黄金三法则凌晨三点告警铃声划破寂静——multipathd: directio checker reports path is down。这个看似简单的日志条目背后可能隐藏着从主机HBA卡到存储阵列的整条I/O路径上的任何环节故障。本文将分享一套经过实战检验的黄金三法则排查框架帮助你在纷繁复杂的存储链路问题中快速定位真凶。1. 告警背后的真相理解multipath工作机制多路径I/OMultipath I/O是存储高可用的基石技术它允许服务器通过多条物理路径访问同一块存储设备。当一条路径发生故障时系统会自动切换到备用路径保障业务连续性。典型的multipath架构包含以下组件[主机HBA卡] —— [光纤交换机] —— [存储控制器] |___________________________|理解几个关键概念对排查至关重要路径状态每条路径可能有active正常、failed失败、faulty故障等状态策略组决定I/O如何分配的策略常见round-robin轮询和failover故障切换检查器用于检测路径健康状态的机制如directio直接I/O检查当看到directio checker reports path is down时说明multipathd守护进程通过直接I/O方式检测到某条路径不可用。但这只是表象真正的问题可能存在于主机端的HBA卡驱动或配置光纤线缆或交换机端口存储阵列的控制器或LUN映射2. 黄金三法则系统性排查框架2.1 法则一日志关联分析存储问题的排查始于日志但不止于简单查看。需要掌握三层日志关联分析法multipathd日志定位具体故障路径journalctl -u multipathd --since 1 hour ago | grep -i down内核日志获取底层SCSI错误信息dmesg | grep -E sd [a-z]:|end_request硬件日志检查HBA卡状态lspci -vvv | grep -A10 Fibre典型日志关联分析示例日志类型关键信息含义解析multipathdsdy - directio checker reports path is down路径/dev/sdy检测失败kernelsd 6:0:3:7: [sdy] Sense Key : Illegal RequestSCSI层返回非法请求kernelend_request: I/O error, dev sdy, sector 0设备sdy发生I/O错误提示当看到Illegal Request和Logical unit not supported组合出现时通常指向存储端的LUN映射问题。2.2 法则二状态对比定位通过命令组合拳建立设备状态全景图物理磁盘视图lsblk -o NAME,SIZE,MODEL,TRAN,SERIAL多路径聚合视图multipath -ll | grep -E status|path存储厂商特定工具如有# HP 3PAR示例 hp3par showvlun关键对比技巧对比multipath -ll输出中不同存储设备的路径状态检查所有故障路径是否属于同一存储阵列确认正常工作的路径是否存在共同特征如使用相同HBA卡2.3 法则三拓扑责任划分绘制简易拓扑图帮助责任划分[主机]---[HBA卡1]---[交换机A]---[存储阵列X] | | |---[HBA卡2]---[交换机B]---[存储阵列Y]排查步骤主机层验证检查HBA卡链路状态cat /sys/class/fc_host/host*/port_state验证光纤端口速率cat /sys/class/fc_host/host*/speed网络层验证通过交换机CLI检查端口状态确认Zone配置是否正确存储层验证检查存储控制器状态确认LUN映射和访问权限注意当部分路径正常工作时可以排除主机和交换机问题直接聚焦存储端。3. 实战案例从混乱到清晰的排查过程某金融系统凌晨出现存储告警按照黄金三法则的排查过程3.1 第一阶段信息收集发现多条告警Jun 7 03:23:31 pmsdb1 multipathd: mpathap: sdy - directio checker reports path is down Jun 7 03:23:31 pmsdb1 kernel: sd 6:0:3:7: [sdy] Sense Key : Illegal Request初步执行状态检查# multipath -ll输出摘要 mpathap (36e02861...) dm-25 HUAWEI,XSG1 |- 6:0:3:7 sdy 65:128 failed faulty running mpathz (360060e8...) dm-9 HP,OPEN-V |- 5:0:0:7 sdan 66:112 active ready running - 6:0:0:7 sdj 8:144 active ready running3.2 第二阶段模式识别通过对比发现所有故障路径均来自HUAWEI存储HP存储路径全部正常故障设备状态均为failed faulty running由此排除主机HBA卡问题因为HP存储路径正常光纤交换机问题同上3.3 第三阶段真相大白联系存储管理员后确认故障LUNs是临时测试使用的存储管理员在业务时间外执行了LUN取消映射未按流程通知主机团队执行umount和multipath清理根本原因存储端变更未遵循标准流程。4. 预防胜于治疗构建存储运维最佳实践基于多次类似事件的经验总结出以下防护措施变更管理三板斧存储变更必须提前通知执行前双重确认影响范围变更后验证主机端状态监控增强方案# 监控多路径状态脚本示例 #!/bin/bash CRITICAL$(multipath -ll | grep -c failed faulty) if [ $CRITICAL -gt 0 ]; then echo CRITICAL: $CRITICAL paths in faulty state multipath -ll | grep -A1 failed faulty exit 2 fi自动化处理流程对于已知的临时LUN设置自动清理任务定期审计存储映射关系存储链路问题往往看似复杂但只要掌握系统性的排查方法就能拨云见日。记住这个简单但有效的排查顺序日志分析→状态对比→责任划分。下次遇到类似问题时不妨先深呼吸然后按照这黄金三法则一步步推进你会发现再复杂的存储问题也能迎刃而解。