一、问题背景与现象分析

在基于Linux的NAS存储系统中，iSCSI磁盘作为共享存储资源被广泛应用。当系统完成重启后，部分用户反馈iSCSI磁盘无法正常挂载，通过fdisk -l或lsblk命令查看时，发现目标磁盘设备节点消失。这种问题通常发生在服务启动时序不当的场景，具体表现为：

服务竞争条件：iSCSI Target服务与网络服务启动顺序冲突
存储初始化延迟：后端存储设备（如RAID卡）初始化耗时超过系统预期
依赖服务未就绪：LVM、MDADM等底层存储管理服务尚未完成初始化

典型错误日志可通过journalctl -u rtslib-fb-targetctl.service查看，常见报错包括：

Failed to add target: Device or resource busy
Timeout waiting for storage backend initialization

二、问题诊断流程

2.1 服务状态检查

首先需要确认服务运行状态及依赖关系：

systemctl status rtslib-fb-targetctl.service

重点关注以下关键信息：

Loaded字段显示的服务文件路径
Active状态是否为active (running)
日志中的错误堆栈信息

2.2 启动时序分析

使用systemd-analyze critical-chain命令查看服务启动链：

● ░░░░░░░░░░░░░░░░░░░░░░ rtslib-fb-targetctl.service
░░ ┌─network-online.target
░░ │└─NetworkManager-wait-online.service
░░ └─system.slice

若发现关键网络服务或存储服务未出现在依赖链中，则需要手动调整启动顺序。

2.3 存储设备检测

通过ls /dev/sd*和ls /dev/disk/by-id/确认物理设备是否已识别。若设备节点存在但iSCSI服务无法访问，可能是权限问题；若设备节点完全缺失，则属于初始化时序问题。

三、解决方案实施

3.1 服务文件修改

获取root权限：
```
sudo -i
```

编辑服务定义文件：

nano /lib/systemd/system/rtslib-fb-targetctl.service

添加启动前延迟：
在[Service]段落下新增：
```
ExecStartPre=/bin/sleep 180
```
完整配置示例：
```ini
[Unit]
Description=iSCSI Target daemon
After=network.target

[Service]
Type=simple
ExecStartPre=/bin/sleep 180
ExecStart=/usr/sbin/rtslib-fb-targetctl
Restart=on-failure

[Install]
WantedBy=multi-user.target


## 3.2 依赖关系优化
对于复杂存储环境，建议创建自定义依赖单元：
```bash
cat > /etc/systemd/system/storage-init.service <<EOF
[Unit]
Description=Storage Initialization Service
Before=rtslib-fb-targetctl.service
[Service]
Type=oneshot
ExecStart=/bin/bash -c 'while [ ! -e /dev/sdX ]; do sleep 5; done'
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
EOF

然后修改target服务依赖：

After=network.target storage-init.service

3.3 服务重载与验证

重新加载配置：
```
systemctl daemon-reload
```

验证服务状态：

systemctl restart rtslib-fb-targetctl.service
journalctl -u rtslib-fb-targetctl.service -f

测试重启场景：

reboot
# 重启后验证
lsblk | grep -i iscsi
fdisk -l /dev/sdX

四、高级优化方案

4.1 动态延迟调整

对于存储初始化时间不固定的环境，可实现动态检测机制：

cat > /usr/local/bin/wait-for-storage.sh <<'EOF'
#!/bin/bash
TIMEOUT=300
INTERVAL=5
START_TIME=$(date +%s)
while [ $(date +%s) -lt $((START_TIME + TIMEOUT)) ]; do
    if [ -e /dev/sdX ]; then
        exit 0
    fi
    sleep $INTERVAL
done
exit 1
EOF
chmod +x /usr/local/bin/wait-for-storage.sh

然后在服务文件中调用：

ExecStartPre=/usr/local/bin/wait-for-storage.sh

4.2 监控告警集成

建议将iSCSI服务状态纳入监控体系：

# 创建监控脚本
cat > /usr/local/bin/check-iscsi.sh <<'EOF'
#!/bin/bash
if ! systemctl is-active --quiet rtslib-fb-targetctl.service; then
    echo "CRITICAL: iSCSI Target service not running"
    exit 2
fi
if ! lsblk | grep -q iscsi; then
    echo "WARNING: No iSCSI disks detected"
    exit 1
fi
echo "OK: iSCSI service and disks healthy"
exit 0
EOF

4.3 日志分析优化

配置rsyslog实现关键日志集中管理：

# /etc/rsyslog.d/iscsi.conf
local0.* /var/log/iscsi-target.log

在服务文件中添加日志标识：

StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=iscsi-target

五、最佳实践建议

分阶段部署：先在测试环境验证延迟参数，再应用到生产环境

版本控制：对修改的服务文件进行备份管理

cp /lib/systemd/system/rtslib-fb-targetctl.service \
/lib/systemd/system/rtslib-fb-targetctl.service.bak

文档记录：详细记录修改原因、参数值和验证结果
变更回滚：制定应急方案，确保可快速恢复原始配置

六、总结

通过系统性分析iSCSI磁盘丢失问题的根本原因，本文提供了从基础时序调整到高级监控集成的完整解决方案。运维人员可根据实际环境选择适合的优化级别，建议优先实施服务延迟加载方案，再逐步完善监控体系。对于关键业务系统，建议结合存储厂商的最佳实践进行参数调优，确保存储服务的可靠性和可用性达到企业级标准。

iSCSI磁盘重启丢失问题解析与targetcli服务优化方案