企业官网建设流程全解析

从一条multipathd告警看Linux存储链路排查的"黄金三法则"

凌晨三点，告警铃声划破寂静——multipathd: directio checker reports path is down。这个看似简单的日志条目背后，可能隐藏着从主机HBA卡到存储阵列的整条I/O路径上的任何环节故障。本文将分享一套经过实战检验的"黄金三法则"排查框架，帮助你在纷繁复杂的存储链路问题中快速定位真凶。

1. 告警背后的真相：理解multipath工作机制

多路径I/O（Multipath I/O）是存储高可用的基石技术，它允许服务器通过多条物理路径访问同一块存储设备。当一条路径发生故障时，系统会自动切换到备用路径，保障业务连续性。典型的multipath架构包含以下组件：

[主机HBA卡] —— [光纤交换机] —— [存储控制器] |___________________________|

理解几个关键概念对排查至关重要：

• 路径状态：每条路径可能有active（正常）、failed（失败）、faulty（故障）等状态
• 策略组：决定I/O如何分配的策略，常见round-robin（轮询）和failover（故障切换）
• 检查器：用于检测路径健康状态的机制，如directio（直接I/O检查）

当看到directio checker reports path is down时，说明multipathd守护进程通过直接I/O方式检测到某条路径不可用。但这只是表象，真正的问题可能存在于：

1. 主机端的HBA卡驱动或配置
2. 光纤线缆或交换机端口
3. 存储阵列的控制器或LUN映射

2. 黄金三法则：系统性排查框架

2.1 法则一：日志关联分析

存储问题的排查始于日志，但不止于简单查看。需要掌握三层日志关联分析法：

1. multipathd日志：定位具体故障路径

   journalctl -u multipathd --since "1 hour ago" | grep -i down

2. 内核日志：获取底层SCSI错误信息

   dmesg | grep -E 'sd [a-z]:|end_request'

3. 硬件日志：检查HBA卡状态

   lspci -vvv | grep -A10 Fibre

典型日志关联分析示例：

提示：当看到Illegal Request和Logical unit not supported组合出现时，通常指向存储端的LUN映射问题。

2.2 法则二：状态对比定位

通过命令组合拳建立设备状态全景图：

1. 物理磁盘视图：

   lsblk -o NAME,SIZE,MODEL,TRAN,SERIAL

2. 多路径聚合视图：

   multipath -ll | grep -E 'status=|path'

3. 存储厂商特定工具（如有）：

   # HP 3PAR示例 hp3par showvlun

关键对比技巧：

• 对比multipath -ll输出中不同存储设备的路径状态
• 检查所有故障路径是否属于同一存储阵列
• 确认正常工作的路径是否存在共同特征（如使用相同HBA卡）

2.3 法则三：拓扑责任划分

绘制简易拓扑图帮助责任划分：

[主机]---[HBA卡1]---[交换机A]---[存储阵列X] | | |---[HBA卡2]---[交换机B]---[存储阵列Y]

排查步骤：

1. 主机层验证：

   • 检查HBA卡链路状态：

     cat /sys/class/fc_host/host*/port_state

   • 验证光纤端口速率：

     cat /sys/class/fc_host/host*/speed

2. 网络层验证：

   • 通过交换机CLI检查端口状态
   • 确认Zone配置是否正确

3. 存储层验证：

   • 检查存储控制器状态
   • 确认LUN映射和访问权限

注意：当部分路径正常工作时，可以排除主机和交换机问题，直接聚焦存储端。

3. 实战案例：从混乱到清晰的排查过程

某金融系统凌晨出现存储告警，按照"黄金三法则"的排查过程：

3.1 第一阶段：信息收集

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

2. 初步执行状态检查：

   # 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 running

3.2 第二阶段：模式识别

通过对比发现：

• 所有故障路径均来自HUAWEI存储
• HP存储路径全部正常
• 故障设备状态均为failed faulty running

由此排除：

• 主机HBA卡问题（因为HP存储路径正常）
• 光纤交换机问题（同上）

3.3 第三阶段：真相大白

联系存储管理员后确认：

• 故障LUNs是临时测试使用的
• 存储管理员在业务时间外执行了LUN取消映射
• 未按流程通知主机团队执行umount和multipath清理

根本原因：存储端变更未遵循标准流程。

4. 预防胜于治疗：构建存储运维最佳实践

基于多次类似事件的经验，总结出以下防护措施：

1. 变更管理三板斧：

   • 存储变更必须提前通知
   • 执行前双重确认影响范围
   • 变更后验证主机端状态

2. 监控增强方案：

   # 监控多路径状态脚本示例 #!/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

3. 自动化处理流程：

   • 对于已知的临时LUN，设置自动清理任务
   • 定期审计存储映射关系

存储链路问题往往看似复杂，但只要掌握系统性的排查方法，就能拨云见日。记住这个简单但有效的排查顺序：日志分析→状态对比→责任划分。下次遇到类似问题时，不妨先深呼吸，然后按照这"黄金三法则"一步步推进，你会发现再复杂的存储问题也能迎刃而解。