iSCSI 客户端连接与持久化：open-iscsi 实践

存储管理员最常见的一幕：Target 配置完毕，客户端执行一次登录把盘挂上，业务跑起来；一旦重启服务器，盘没了、挂载失败、业务起不来，回头检查命令和历史，发现每一步"都对的"。这篇文章要解决的正是这个问题：如何让 iSCSI 客户端在重启后自动重连、自动挂载、不丢盘。它背后最基础的事实只有一句：iSCSI 会话是运行时对象，不是配置文件里的一行。登录只是一次性动作，会话活在 iscsid 守护进程与内核驱动里，机器一重启就消失；要让"重连"自动化，必须把登录意图持久化到 /etc/iscsi 的 node 记录里，再由系统服务在开机时替你重新执行登录。理解这条因果链之后，所有命令都有了位置，遇到故障也知道往哪里查。

#原理层：iSCSI 客户端的三层结构与会话生命周期

#1.1 iSCSI 是什么：把 SCSI 指令搬到 TCP/IP 上

要理解客户端行为，先回到协议本身。SCSI（Small Computer System Interface）是一套命令协议：主机作为发起方（Initiator）向存储设备发出命令，比如 INQUIRY（你是谁）、READ/WRITE（读写块）、REPORT LUNS（你有哪些逻辑单元），设备执行后返回状态（成功、失败、忙碌）。iSCSI（Internet Small Computer System Interface）就是把这套命令封装进 TCP/IP：命令、数据、状态分别组织成 iSCSI PDU（Protocol Data Unit），在一条或多条 TCP 连接上传输，默认端口 3260。

对 Linux 内核来说，iSCSI 登录成功后，远端暴露的 LUN（Logical Unit Number，逻辑单元）呈现为普通块设备（/dev/sdX），其上是文件系统、LVM、数据库数据文件——和本地磁盘没有任何区别。这是 iSCSI"好用"的原因：透明、兼容一切文件系统、上层应用无感知。但它也是双刃剑：设备"看起来像本地盘"，一旦会话因网络断开而失败，文件系统会像本地盘掉电一样返回 IO 错误，应用层必须自己应对。这正是后面 replacement_timeout、多路径这些话题的出发点。

一段话概括逻辑：SCSI 定义"发命令-收状态"，iSCSI 定义"命令怎么在 IP 网络上跑"，open-iscsi 定义"Linux 上如何配置和管理这些会话"。

#1.2 三个角色与一个全局唯一的名字

一次 iSCSI 通信涉及三样东西：

• Initiator（发起方）：主动发起连接的客户端，本文的主角；
• Target（目标）：提供存储的服务端，通常是一台存储设备或存储服务器；
• LUN（逻辑单元）：Target 上暴露出来的、可被读写寻址的块设备，一个 Target 可以带多个 LUN，分别对应不同的容量与用途。

让多方能够正确识别彼此，靠的是全局唯一的名字。iSCSI 使用 IQN（iSCSI Qualified Name），格式为 iqn.<yyyy-mm>.<反向域名>[:<可选标识>]，例如 iqn.2026-08.com.example:storage01。反向域名保证命名空间唯一，冒号后的字符串用于在同一组织内区分不同设备。在 Target 侧，权限、命名、LUN 映射通常都以 IQN 为键——所以每台客户端必须有自己唯一的 IQN，客户端名字重复会导致存储端无法区分究竟是哪台机器在访问。

在 Linux 上，客户端 IQN 存放在 /etc/iscsi/initiatorname.iscsi，内容形如：

InitiatorName=iqn.2026-08.com.client:web01

这个文件在安装 open-iscsi 时会被自动生成一个默认值，生产环境务必改成规划好的唯一名字。

#1.3 组件分工：内核、iscsid、iscsiadm 各干什么

open-iscsi 客户端不是一个单进程程序，而是由三部分配合完成"登录并维护会话"这件事：

• 内核驱动：iscsi_tcp 负责真正的数据路径——把 iSCSI PDU 封装到 TCP 包、按序收发；scsi_transport_iscsi 在内核里维护"会话（session）-连接（connection）-设备"的抽象。块设备节点（/dev/sdX）就是内核在这一层注册出来的。
• iscsid 守护进程：用户态的"会话管家"。它负责编排登录协商、维护会话状态、在连接断开时按策略执行错误恢复，并通过 netlink 与内核通信。登录、恢复这类有状态的事情都归它管。
• iscsiadm 管理工具：面向管理员的前端。它读写 /etc/iscsi 下的持久化配置，并向 iscsid 下发登录/注销命令。管理员 95% 的操作都是敲 iscsiadm。
• 系统服务：iscsid.service 启动守护进程本身；iscsi.service 在开机时自动登录所有标记为 automatic 的 node（后面 1.7 详述）。

这里有一个贯穿全文的关键区分：会话本身是易失的运行时状态，由内核对象 + iscsid 内存状态组成；而"要不要在开机时登录、用什么参数登录"是持久化配置，落在 /etc/iscsi 目录下。持久化靠的是磁盘上的记录，易失的会话靠的是进程。

#1.4 discovery：sendtargets 如何找到 Target

第一次接触一台存储，客户端不知道对方暴露了哪些 Target。iSCSI 协议定义了多种发现机制（SendTargets、SLP、iSNS、FC 等），open-iscsi 最常用的是 SendTargets（discovery 类型名写做 sendtargets）。

流程是这样的：initiator 与 Target 建立一个管理用途的 TCP 连接（默认到 3260 端口），在文本协商阶段发送 SendTargets 请求；Target 把自己暴露的所有 Target 名称，以及每个 Target 对应的门户（portal，即 ip:端口,组号）一次性返回。客户端拿到清单后，把结果写入 /etc/iscsi/send_targets 目录，之后就不再需要"重新发现"就能直接登录了。

对应命令是：

sudo iscsiadm -m discovery -t sendtargets -p 192.168.10.10

其中 -m discovery 表示操作对象是发现记录，-t sendtargets 选择发现类型，-p 指定 Target 门户地址。执行后输出形如：

192.168.10.10:3260,1 iqn.2026-08.com.example:storage01

这行的含义是：门户 192.168.10.10:3260（逗号前的 IP 与端口），1 是 Target Portal Group Tag（同一 Target 在多个门户间做故障转移的分组标识），空格后是 Target 的 IQN。

此时磁盘上会多出 /etc/iscsi/send_targets/192.168.10.10,3260/iqn.2026-08.com.example:storage01/default 这样的记录文件，里面保存着发现来源与参数。这就是为什么"只做一次 discovery，之后 iscsiadm -m node 也能看到这个 Target"——记录已经在本地了。

#1.5 node 记录：登录参数落在哪里

真正登录一个 Target 之后，open-iscsi 会在 /etc/iscsi/nodes/<iqn>/<portal>/default 写入一条 node 记录。这条记录是一个纯文本的键值对文件，容纳了登录所需的一切：Target 名称、门户地址、启动策略（startup）、认证方式与凭据（CHAP）、超时与恢复参数等。

管理员执行的这类命令：

sudo iscsiadm -m node -T iqn.2026-08.com.example:storage01 -p 192.168.10.10 --op=update --name node.startup --value=automatic

本质就是：定位到 node 记录（-T 指定 Target IQN，-p 指定门户），把名为 node.startup 的键改成 automatic，写回同一个文件。同理，CHAP 参数、replacement_timeout 参数也都是对这条记录做增改。

node 记录是"重启后一切能否恢复"的总剧本：开机时系统要照着它重新登录；记录不全会导致重连失败——比如漏写了 CHAP 凭据，重启后登录协商走到认证一步直接失败。所以后面所有 --op=update 操作的共同目的，就是把这本剧本修订完整。

#1.6 为什么重启后会丢：四个断点

把前面几节串起来，重启丢盘不是单一原因，而是四个断点叠加：

1. 会话易失：会话是内核对象 + iscsid 内存状态，属于运行时数据，机器重启全部清空。
2. node.startup 默认是 manual：只执行过 --login 的 node，其启动策略默认是手动（manual），意思是"只有我手动登录才登录"。iscsi 服务开机时只对 automatic 的 node 执行自动登录，manual 的一律跳过——于是重启后会话不会回来。
3. 设备名不稳定：/dev/sdb 之类的名字由内核按探测顺序分配，重启后设备出现顺序可能变化，/dev/sdb 可能变成 /dev/sdc。fstab 里写死 /dev/sdb 相当于把命运交给启动时序，原文说得很直白：这是定时炸弹。
4. 挂载时机早于网络就绪：系统启动早期网络栈尚未就绪，即使会话能建，mount 也可能因设备尚未出现而失败，或阻塞开机流程等一个永远不会来的设备。

对应地，"持久化"必须三件事一起做：把自动登录意图写进 node 记录（startup=automatic）；用稳定标识（UUID 或 LVM 名称）而不是 /dev/sdX 挂载；用 _netdev、nofail、x-systemd.device-timeout 告诉 systemd"等网络、失败别阻塞、最多等多久"。

#1.7 自动登录的机制：iscsi.service 在开机时做了什么

把开机时序捋清楚，自动重连就再也没有神秘感：

1. iscsid.service 启动，iscsid 守护进程就位；
2. iscsi.service 执行等价于 iscsiadm -m node --loginall=automatic 的操作（即 -L automatic），遍历 /etc/iscsi/nodes 下的每一条记录；
3. 凡是 node.startup=automatic 的记录，都按照记录中的门户、认证、超时参数重新执行登录协商；
4. 登录成功 → 内核扫描 LUN → 块设备出现 → systemd 挂载单元（由 fstab 生成）在满足 _netdev 依赖后完成挂载。

由此可见，"配置开机自动重连" = 把 node 记录的 startup 标记改为 automatic + 确保 iscsid/iscsi 两个服务开机自启，仅此而已。理解了这一步，后面操作层的第 5 步就只是一条命令的事。

#操作层：完整可复现的实施序列

#2.0 环境与前置条件

本文命令以 RHEL/CentOS Stream/Rocky/Alma/Fedora 等 dnf 系发行版 + 传统 Systemd 为基准（这也是原文的默认环境），open-iscsi 版本以发行版自带为准，核心机制在 2.x 各版本一致。Debian/Ubuntu 的差异在"边界与坑"一节单独说明。

实施前确认以下前置条件：

• Target 侧已配置好 Target 与 LUN，管理门户 IP 可达（本文统一用示例地址 192.168.10.10），3260 端口未被防火墙拦截；
• 本文所有 IP、IQN、用户名、密码均为示例，实施时替换为你的真实值；文中客户端 IQN 统一用 iqn.2026-08.com.client:web01，Target IQN 统一用 iqn.2026-08.com.example:storage01；
• 执行用户有 sudo 权限；
• 操作前先执行 lsblk 记录当前磁盘布局，避免把已有的数据盘误当 iSCSI 盘操作。

完整命令序列的"骨架"是：安装并写身份 → 发现 → 登录 → 写入认证/启动/恢复参数 → 配置挂载 → 验证 →（需要时）断开与清理。下面每一步都可独立执行、可独立验证。

#2.1 安装与初始化客户端身份

sudo dnf install -y iscsi-initiator-utils

包内包含 iscsiadm、iscsid、systemd 服务单元和 /etc/iscsi 目录骨架。接着写入客户端自己的 IQN（每台机器唯一）：

sudo vi /etc/iscsi/initiatorname.iscsi

内容形如：

InitiatorName=iqn.2026-08.com.client:web01

如果安装后改动过这个名字，重启守护进程让新名字生效：

sudo systemctl restart iscsid

验证是否读到新名字：

sudo cat /etc/iscsi/initiatorname.iscsi

#2.2 发现 Target

sudo iscsiadm -m discovery -t sendtargets -p 192.168.10.10

预期输出：

192.168.10.10:3260,1 iqn.2026-08.com.example:storage01

看到输出说明发现链路通（TCP 可达、Target 侧允许该 initiator）。两点提示：

• 若只想"新增还没有的记录、不覆盖已有记录"，加 -o new；
• 需要了解 Target 返回的细节（比如 SENDTARGETS 里附带的能力参数），加 -P 1 打印详细信息。

#2.3 登录

sudo iscsiadm -m node -T iqn.2026-08.com.example:storage01 -p 192.168.10.10 --login

登录成功后，内核扫描 LUN，出现块设备（如 /dev/sdb）。立刻确认：

sudo iscsiadm -m session
lsblk -S

iscsiadm -m session 会列出当前 Logged-in 的会话；lsblk -S 会列出内核发现的 SCSI 盘。请务必记住：这只是"这一次登录"，此刻 node.startup 还是 manual，重启后不会自动回来，要继续做第 2.5 步。

#2.4 把双向 CHAP 认证写入 node 记录

如果 Target 配了 CHAP 认证（生产环境强烈建议，至少单向），客户端登录协商时就会走到认证环节。凭据必须写进 node 记录，而不是只写在命令行里——否则下次自动登录根本没有凭据可用。原文的三条命令原样如下：

sudo iscsiadm -m node -T iqn.2026-08.com.example:storage01 -p 192.168.10.10   --op=update --name node.session.auth.authmethod --value=CHAP
sudo iscsiadm -m node -T iqn.2026-08.com.example:storage01 -p 192.168.10.10   --op=update --name node.session.auth.username --value=storage_user
sudo iscsiadm -m node -T iqn.2026-08.com.example:storage01 -p 192.168.10.10   --op=update --name node.session.auth.password --value=strong-pass-123

说明与补充：

• node.session.auth.authmethod=CHAP 表示本会话采用 CHAP 认证；username/password 必须与 Target 侧为该存储用户配置的完全一致；
• 上面三条配置的是 initiator 向 Target 证明身份（单向 CHAP 就够）。如果 Target 配的是双向 CHAP（Mutual CHAP），还要让客户端反过来验证 Target，需要再补两条 Target 侧凭据（具体值由存储管理员分配）：

sudo iscsiadm -m node -T iqn.2026-08.com.example:storage01 -p 192.168.10.10   --op=update --name node.session.auth.target_username --value=storage_target
sudo iscsiadm -m node -T iqn.2026-08.com.example:storage01 -p 192.168.10.10   --op=update --name node.session.auth.target_password --value=target-secret-456

• 认证参数以明文存放在 /etc/iscsi/nodes 下的 node 记录文件中（文件权限默认 600），不要把这些值写进配置管理仓库或公开文档；生产环境按公司密钥管理规范处理；
• 注意 open-iscsi 对 CHAP 密码长度有最小要求（通常要求不少于 12 个字符），过短会在登录时报错。

改完认证参数后，对已建立的会话需要重新登录一次才能用上新凭据（先 2.8 的 logout，再 --login），或留到重启后由自动登录流程验证。

#2.5 开启开机自动登录

iscsiadm -m node --login 只负责这一次；要让开机自动重新登录，把 node 记录的自动登录开关打开：

sudo iscsiadm -m node -T iqn.2026-08.com.example:storage01 -p 192.168.10.10   --op=update --name node.startup --value=automatic

node.startup 的取值主要有：

• manual：默认值，只有手动登录才登录，重启不自动恢复；
• automatic：iscsi 服务开机时自动登录，客户端持久化选这个；
• onboot：用于 discovery 记录的特殊标记，普通 node 不用。

同时确认两个服务开机自启（原文只写了 iscsid，实际负责开机执行自动登录的是 iscsi 服务，两个都要）：

sudo systemctl enable --now iscsid
sudo systemctl enable --now iscsi

验证配置已落盘：

sudo iscsiadm -m node -T iqn.2026-08.com.example:storage01 -p 192.168.10.10 --op=show | grep -E 'node.startup|node.session.auth.authmethod'

当输出里能看到 node.startup = automatic 和 node.session.auth.authmethod = CHAP，自动登录的"剧本"就已经齐了。

#2.6 自动挂载：别用 fstab 硬写 /dev/sdX

设备名不稳定的问题在原理层已经讲过：重启后 /dev/sdb 可能变成 /dev/sdc。因此挂载层面要做两件事：用稳定标识（UUID 或 LVM 名称）代替设备名；在 fstab 里给 systemd 足够的信息。

最省心的做法是直接对 iSCSI 盘建 LVM——LVM 的卷组名/逻辑卷名不受设备探测顺序影响，且以后扩容量也方便。原文命令如下：

# 在 iSCSI 盘上建 LVM（以 /dev/sdb 为例，先确认它就是目标盘）
sudo pvcreate /dev/sdb
sudo vgcreate vg_iscsi /dev/sdb
sudo lvcreate -l 100%FREE -n data vg_iscsi
sudo mkfs.xfs /dev/vg_iscsi/data

# 用 UUID 挂载，并在 fstab 里加 nofail
UUID=$(blkid -s UUID -o value /dev/vg_iscsi/data)
echo "UUID=$UUID /data xfs defaults,_netdev,nofail,x-systemd.device-timeout=30 0 0" | sudo tee -a /etc/fstab
sudo systemctl daemon-reload

最后一行 systemctl daemon-reload 让 systemd-fstab-generator 重新读取 fstab、生成对应的挂载单元，这一步常被遗漏，改完 fstab 建议执行。

三个关键挂载参数逐个说清楚：

• _netdev：告诉 systemd 这个挂载点依赖网络设备，生成的挂载单元会等待网络就绪后再挂，避免"网络还没起就试图 mount"；
• nofail：挂载失败不阻塞开机流程，防止"存储没起来，整台机器卡在挂载上"；
• x-systemd.device-timeout=30：最多等 30 秒，超时放弃继续启动（而不是无限期等待）。

没有 LVM 的话，也可以直接对裸盘执行 mkfs，然后 blkid 拿 UUID 写 fstab：

sudo mkfs.xfs /dev/sdb
UUID=$(blkid -s UUID -o value /dev/sdb)
echo "UUID=$UUID /data xfs defaults,_netdev,nofail,x-systemd.device-timeout=30 0 0" | sudo tee -a /etc/fstab

无论哪种方式，都不要用 /dev/sdX。挂载点按需调整（本文示例挂到 /data）。

若希望"用到才挂、不用不挂"以降低对启动的干扰，还可以改用 x-systemd.automount 按需挂载，属于可选优化，不在本文展开。

#2.7 断线恢复参数

iSCSI 断线（网络抖动、Target 重启）时，会话默认不会立刻失败，而是进入恢复尝试。控制这个行为的关键参数是 node.session.timeo.replacement_timeout，原文给出 120 秒的示例：

sudo iscsiadm -m node -T iqn.2026-08.com.example:storage01 -p 192.168.10.10   --op=update --name node.session.timeo.replacement_timeout --value=120

机制与权衡：

• replacement_timeout 是会话等待 Target 恢复的秒数：连接断开后，内核与 iscsid 进入错误恢复，反复尝试重建连接；在超时时间内恢复，IO 无缝续上；超时后会话失败，块设备上的所有 IO 返回错误。
• 取值太短：网络抖一下就掉盘，业务直接 IO 错误；
• 取值太长：故障期间 IO 一直阻塞，应用层表现为卡死、无响应；
• 数据库场景一般取 60-120 秒，再配合 multipath（多路径）让另一条路径顶上，才是完整的可用性方案——单路径下超时只是"拖延失败"，路径冗余才是"消除失败"。

注意：--op=update 写的是 node 记录，对下一次登录生效。如需让当前已建立的会话立即采用新值，最直接的方式是注销后重新登录（见 2.8），或查阅你所用 open-iscsi 版本文档确认是否支持会话级更新。

#2.8 断开与清理（logout 与删记录）

排查、换存储或下线业务时，需要干净的断开与清理流程。三条命令层级分明：

# 1) 注销当前会话：停止使用，但保留 node 记录
sudo iscsiadm -m node -T iqn.2026-08.com.example:storage01 -p 192.168.10.10 --logout

# 2) 确认会话已消失
sudo iscsiadm -m session

# 3) 删除 node 记录：防止开机自动登录
sudo iscsiadm -m node -T iqn.2026-08.com.example:storage01 -p 192.168.10.10 --op=delete

# 4) 如需连 discovery 记录也一起清掉
sudo iscsiadm -m discovery -p 192.168.10.10 --op=delete

这样做是分层的：第一步只断会话，配置还在，随时可以 --login 回来；第三步删掉 node 记录，自动登录从此失效；第四步连"发现记录"也删，机器上不再残留这台存储的任何痕迹。

如果这块盘上还挂着文件系统，先卸载再动 LVM：

sudo umount /data          # 卸载挂载点
sudo sed -i '\#/data#d' /etc/fstab   # 删除对应的 fstab 行（先备份 /etc/fstab）
sudo vgchange -an vg_iscsi # 停用卷组（可选，若该卷组只服务这台存储）

清理属于高风险操作：执行前确认业务已停、无 IO 在途、备份 fstab；不要在未确认目标盘身份的情况下对 /dev/sdb 执行 pvcreate/格式化。

#验证层：怎么确认我做对了

验证分四档，从"参数对不对"到"整机重启后业务能不能起"，层层加码。不要只停在第一档。

第一档：配置与记录检查（不重启，先确认剧本齐了）

# node 记录里的启动策略与认证参数
sudo iscsiadm -m node -T iqn.2026-08.com.example:storage01 -p 192.168.10.10 --op=show | grep -E 'node.startup|node.session.auth'

# 服务自启状态
systemctl is-enabled iscsid iscsi

预期：node.startup = automatic、node.session.auth.authmethod = CHAP、两个服务都是 enabled。

第二档：会话与设备检查（确认当前登录态与设备身份）

sudo iscsiadm -m session
sudo iscsiadm -m session -P 3
lsblk -S
lsblk /dev/vg_iscsi/data
blkid -s UUID -o value /dev/vg_iscsi/data

预期：会话列表里有 Logged-in 的记录；lsblk -S 出现对应的 SCSI 盘；逻辑卷与 UUID 都找得到。

第三档：挂载检查

mountpoint /data
mount | grep /data
df -h /data

预期：/data 是挂载点，文件系统就位，磁盘容量正确。

第四档：终极验证——真实重启（原文最强调的一步）

sudo systemctl reboot
# 起来之后依次执行：
sudo iscsiadm -m session      # 有会话
lsblk -S                      # 盘在
mountpoint /data              # 挂载正常

判定标准一句话：会话在、盘在、挂载正常，且业务能正常写读。手动验证一次完整重启，比读十遍文档都管用——重启恢复这条链路，只有真正重启过才敢说配好了。若重启后没自动登录，进入下一节的排查路径。

#边界与坑

#坑 1：CHAP 没写进 node 记录

只改了 Target 侧要求认证、客户端侧没把凭据写进 node 记录，或者凭据写错，那么手动登录可能成功（因为你在交互里输了正确值或之前试过），但开机自动登录时 iscsid 拿不到凭据，协商在认证环节失败。这是重启后不自动登录的最常见原因之一。

排查入口（原文给的命令）：

journalctl -u iscsid -u iscsi

在日志里找登录失败的具体阶段：如果是认证失败，日志会明确指出 initiator 在 SecurityNegotiation 阶段被拒——这时回到 2.4 核对 authmethod/username/password（以及双向 CHAP 的 target 侧两个值）。

#坑 2：node.startup 没设成 automatic

只登录、没执行 --op=update --name node.startup --value=automatic。会话手动登录时是正常的，重启后 iscsi 服务把它跳过。用第一档验证命令看 node 记录即可定位。

#坑 3：fstab 硬写 /dev/sdX

重启后磁盘探测顺序变化，/dev/sdb 变成 /dev/sdc，fstab 找不到设备，挂载失败；如果还没写 nofail，整台机器可能卡在挂载等待上。解法就是 2.6：UUID 或 LVM 名称 + _netdev,nofail + x-systemd.device-timeout。

#坑 4：防火墙拦 3260 / "能 ping 通但登录超时"

发现与登录走的是 TCP 3260，能 ping 通只代表 ICMP 通，不代表 3260 可达。先验证端口：

nc -vz 192.168.10.10 3260

不通则检查存储侧与中间链路的防火墙/安全组规则。客户端本地的 firewalld 一般是从外访问才需要放行，主动出方向默认允许，但云环境的安全组、存储侧的白名单都要逐一确认。

#坑 5：Target 门户变了，旧记录残留

存储迁移、门户 IP 变更后，/etc/iscsi 下残留旧 portal 的 node/discovery 记录。新地址会发现并写入新记录，但旧记录还在，可能出现"自动登录尝试连旧地址、反复失败"的日志噪音；更危险的是用了旧记录登录到别的机器。处理方式：用 2.8 的流程删掉旧记录，重新 discovery 再登录。

#坑 6：多路径拓扑下直接单路径直挂

如果存储侧配置了多条路径（多网卡、多控制器），生产环境应该先用 dm-multipath 把多条路径聚合成一个 /dev/mapper/mpathX，再对聚合设备建 LVM/文件系统，fstab 用聚合设备的 UUID。单路径直挂不仅浪费冗余，还可能在路径切换时遇到设备冲突。原文讲的 replacement_timeout + multipath 才是完整方案：超时负责"等"，多路径负责"换"。

#坑 7：CHAP 密码长度不足

open-iscsi 对 CHAP 密码有最小长度约束（一般要求不少于 12 个字符）。密码过短在登录阶段直接报错，且错误信息不够直观，容易绕圈子。配置侧就把密码定到 12 位以上。

#补充：Debian/Ubuntu 上的差异

非 dnf 系发行版（Debian/Ubuntu）原理与参数完全一致，差异只在安装和服务名：

sudo apt install -y open-iscsi
sudo systemctl enable --now open-iscsi iscsid

其余 iscsiadm 命令、fstab 参数原样可用。

#何时不该按本文方案做

• 需要严格可用性（数据库、核心业务）：单路径直连不够，要做多路径 + 存储侧副本/快照，并配合应用层超时；
• 多台机器共享同一个 LUN：没有集群文件系统或共享锁管理时，多写者同时挂载有损坏风险；
• 对性能有极致要求：iSCSI 走 TCP/IP 网络栈，延迟与吞吐受网络约束，需要先做压测再上生产。

#收尾

把整条链路压缩成三件事：node 记录里 startup=automatic（让系统知道开机要登录）、把认证与恢复参数写全（让登录能成功）、用稳定标识 + _netdev/nofail 挂载（让挂载不依赖时序、失败不拖垮启动），最后用一次真实重启做验收。照此配置，重启不再是冒险，而是一次可预期的演练。

下一步建议：在测试机上做完整重启验证，记录从 reboot 到 /data 可写的时间；需要高可用时再上多路径并配合存储侧快照/复制；日常监控 iscsiadm -m session 的会话状态与多路径路径数，把"丢盘"从故障变成告警。

从底层机制出发就是这个好处：一旦知道会话是运行时状态、重启后由服务照剧本重演，所有配置项都变成了"剧本里的台词"，你写的每一行都有明确的因果位置，排查时也不再靠猜。