一、iSCSI故障的常见类型
1. 连接建立失败
当发起端（Initiator）无法与目标端（Target）建立会话时，可能表现为：
- 认证失败：CHAP（Challenge Handshake Authentication Protocol）配置错误或密钥不匹配。
- 网络不可达：IP地址配置错误、子网掩码不匹配或路由问题。
- 端口未监听：目标端服务未启动或防火墙阻止了TCP 3260端口。
- 资源不足：目标端存储池空间耗尽或LUN（Logical Unit Number）配额超限。
2. 数据传输异常
连接建立后可能出现的性能问题包括：
- 延迟波动：网络拥塞、链路质量差或目标端负载过高。
- 丢包重传：TCP窗口大小配置不当或网络抖动导致数据包丢失。
- I/O超时：存储设备响应缓慢或链路中断未及时检测。
3. 会话中断
已建立的连接可能因以下原因意外终止：
- 网络闪断：物理链路瞬断或交换机端口重启。
- 目标端故障：存储设备重启、服务崩溃或硬件损坏。
- 协议协商失败：双方支持的iSCSI版本或参数不兼容。
二、故障排查流程
1. 信息收集阶段
（1）基础环境检查
- 网络拓扑验证：确认发起端与目标端位于同一子网，或通过路由可达。使用
ping命令测试基础连通性，通过traceroute定位链路跳数异常。 - 端口状态确认：使用
telnet <目标IP> 3260或nc -zv <目标IP> 3260检查端口是否开放。 - 服务状态检查：在目标端确认iSCSI服务进程（如
iscsid或targetd）是否运行，日志中是否有启动失败记录。
（2）配置文件审查
- 发起端配置：检查
/etc/iscsi/initiatorname.iscsi中的IQN（iSCSI Qualified Name）是否唯一，/etc/iscsi/iscsid.conf中的认证参数（如node.session.auth.username）是否与目标端匹配。 - 目标端配置：验证目标端ACL（Access Control List）是否允许发起端IQN访问，LUN映射是否正确。
2. 日志分析阶段
iSCSI协议栈涉及多层次日志，需按优先级逐层排查：
（1）系统日志
- 内核日志：通过
dmesg或journalctl -k过滤iscsi关键词，查看内核模块加载失败、TCP连接重置等底层错误。 - 服务日志：目标端的
/var/log/messages或/var/log/syslog可能记录服务启动失败、权限拒绝等事件。
（2）iSCSI专用日志
- 发起端日志：
/var/log/iscsi/iscsid.log记录会话建立、认证过程及I/O错误。例如，Login request failed表明认证环节出现问题。 - 目标端日志：部分存储系统会将iSCSI事件写入独立日志文件，需关注
Login rejected、Connection reset by peer等关键信息。
（3）网络设备日志
- 交换机日志：检查端口状态变化（如
up/down）、STP（Spanning Tree Protocol）收敛事件或ACL丢包统计。 - 防火墙日志：确认是否有规则阻止了iSCSI流量，尤其关注双向流量（发起端→目标端：TCP 3260；目标端→发起端：动态端口）。
3. 工具辅助阶段
（1）网络诊断工具
- Wireshark抓包：在发起端或目标端捕获iSCSI流量，分析TCP三次握手、SCSI命令交互过程。重点关注：
- SYN包是否被目标端拒绝（RST响应）。
- SCSI命令（如
READ(10)、WRITE(10)）是否超时重传。 - 登录阶段
Text Response是否包含错误代码（如0x1C表示认证失败）。
（2）性能监控工具
- iostat：监控发起端磁盘设备的
util%（利用率）、await（平均I/O延迟）指标，判断是否因存储响应慢导致超时。 - nmon：观察网络带宽使用率，确认是否因并发流量过大引发拥塞。
三、典型日志场景分析
场景1：认证失败（CHAP配置错误）
现象：发起端日志反复出现Login request failed: the session setup was rejected by the target。
分析步骤：
- 检查发起端配置文件中的
node.session.auth.username和node.session.auth.password是否与目标端配置一致。 - 确认目标端ACL中是否包含发起端IQN，且CHAP策略为
Mutual CHAP（双向认证）或One-way CHAP（单向认证）与发起端匹配。 - 使用Wireshark抓包，验证登录阶段
Text Request中的用户名/密码字段是否被正确封装。
场景2：网络闪断导致会话中断
现象：应用层报错I/O error，内核日志显示iSCSI session resumed后伴随大量SCSI重传。
分析步骤：
- 检查交换机日志，确认是否存在端口
flapping（频繁上下线）或STP重新计算事件。 - 分析Wireshark抓包文件，统计TCP重传率。若重传集中在特定时间段，可能为网络设备重启导致。
- 调整发起端
/etc/iscsi/iscsid.conf中的node.session.timeo.replacement_timeout参数（默认120秒），适当缩短超时阈值以快速恢复连接。
场景3：目标端存储响应慢
现象：iostat显示await值持续高于500ms，目标端日志无明确错误。
分析步骤：
- 登录目标端管理界面，检查存储池的IOPS、吞吐量及延迟指标，确认是否存在硬件性能瓶颈。
- 使用
top或iotop观察目标端进程CPU占用率，排除因资源竞争导致的响应延迟。 - 检查目标端缓存策略（如写缓存是否启用、电池备份单元状态），优化参数配置。
四、预防性维护建议
- 配置备份：定期备份发起端和目标端的配置文件，避免误操作导致配置丢失。
- 日志轮转：配置
logrotate自动切割iSCSI日志，防止日志文件过大占用磁盘空间。 - 网络冗余：部署双链路或MPLS VPN，避免单点故障引发连接中断。
- 监控告警：通过Zabbix等工具监控iSCSI会话状态、网络延迟及存储性能，设置阈值告警。
- 定期演练：模拟目标端故障切换，验证发起端自动重连机制的有效性。
结语
iSCSI故障的排查需结合网络、存储、系统多维度信息，通过日志分析定位根本原因。开发工程师应熟悉iSCSI协议交互流程，掌握基础网络诊断工具，并建立系统化的排查思维。通过预防性维护措施，可显著降低故障发生率，保障存储系统的稳定性与数据可靠性。在实际环境中，建议根据具体设备型号和操作系统版本补充厂商文档中的特定调试命令，以提升排查效率。
