1. 从重启就掉盘说起iSCSI自动挂载到底解决什么问题我先说一个真实场景。公司内部有台存储服务器上面划了一块 2TB 的 LUN专门给一台跑报表的 Linux 机器用。一开始图省事每次重启之后手动执行iscsiadm --mode node --login再把文件系统挂上。结果赶上一次机房断电重启那台机器没人管等天亮业务人员打开报表系统发现目录是空的数据不见了其实数据一根毛都没少纯粹是 iSCSI 会话没建立、文件系统没挂上。从那以后我就老老实实把 iSCSI 的开机自动挂载和认证配置一起做掉了。这个标题拆开看就三层意思第一层是iSCSI 协议本身解决的是通过网络把远端块设备当成一块本地硬盘用的问题第二层是开机自动挂载解决的是重启后不用人工干预就能恢复存储连接的问题第三层是认证配置解决的是这块网络硬盘不是谁想连就能连的访问控制问题。这三层缺一不可很多教程只教你手动挂载但真正能落到生产环境的一定是把服务端 target、客户端 initiator、CHAP 认证、自动挂载这几件事串起来一起做的方案。这篇内容适合谁看一种是刚接触 iSCSI、被/etc/fstab各种坑折腾过的新手另一种是已经在用 iSCSI 但只是手动挂载、想把它做得更稳的运维或后端开发。我会从服务端配置讲到客户端挂载最后再把常见坑挨个列出来尽量让你照着敲一遍就能复现一个带认证、可开机自挂的完整链路。2. 动手前的几个关键概念协议角色、CHAP认证和挂载时序2.1 谁是谁target、initiator、LUN 的关系iSCSI 这套体系里的角色划分其实和 TCP 服务端/客户端非常像。提供存储的一端叫target你可以理解成存储服务端它把本地的一块磁盘、一个分区或者一个文件backing store通过 iSCSI 协议共享出去每个共享对象有唯一的名字叫 IQNiSCSI Qualified Name消费存储的一端叫initiator相当于存储客户端它发起连接请求登录成功之后就能看到远端共享出来的块设备通常表现为/dev/sdb、/dev/sdc之类的磁盘。这里有个特别容易混淆的点LUN 是挂在 target 下面的逻辑单元号。一个 target 可以只共享一个 LUN也可以共享多个 LUN。客户端登录同一个 target 后能看到这些 LUN在系统里对应多个磁盘设备。我见过有人把 target 和 LUN 当成一回事配置的时候对着 IQN 一顿操作结果发现连上了但找不到盘后来才明白 LUN 还要单独映射。配置的时候一定要把target 是入口、LUN 是挂在入口里的磁盘这个层次搞清楚。2.2 为什么认证配置不能跳过iSCSI 默认走的是明文 TCP 连接。如果你在办公网或者机房内网里接了一台存储理论上同网段任何一台机器装上 open-iscsi发起 discovery 扫描到你 target 的 IP 和端口默认 3260就能看到你共享出去的 IQN如果 target 没配认证它甚至可以直接 login 成功把你的块设备挂到它自己系统里。这等于把一块裸盘直接交给了陌生人。所以生产环境必须开认证。iSCSI 最常见的认证方式就是CHAPChallenge Handshake Authentication Protocol原理上可以粗浅理解成客户端和服务端之间互相验证密文口令的过程。它主要分两种方向单向 CHAPIncomingtarget 验证 initiator 的身份客户端需要提供正确的用户名和密码才能登录这是最常用的配置。双向 CHAPMutual CHAPtarget 验证 initiator 的同时initiator 也验证 target 的身份。要求两端都配置对方要验证的用户名密码配置项多一倍适合安全要求更高的场景。顺带说一句热词里提到的Tomcat 作为客户端请求服务端实现 mTLS 双向认证这个思路和 iSCSI 的 Mutual CHAP 在双向验证这个语义上很像但底层完全是两码事。mTLS 是基于证书体系的服务端和客户端各自持有证书、互相验签iSCSI 的 Mutual CHAP 是基于共享密钥的没有证书签发流程。如果你在配 iSCSI 时听到有人说像 mTLS 一样双向认证理解成两边都要验对方的凭证就好别把证书那一套概念生搬硬套到 CHAP 配置上来。2.3 开机自动挂载牵扯的时序问题自动挂载这个事难点不在于配置命令本身而在于 Linux 系统启动时网络和存储的先后顺序。普通本地磁盘在/etc/fstab里写一行就能挂因为设备节点在启动早期就存在但 iSCSI 设备依赖网络网络没有就绪之前 initiator 根本没法发现 target更别说建立会话。如果 fstab 里直接写defaults而不做任何约束系统启动时可能会在挂载这一步长时间卡住甚至直接进入 emergency mode。这就是为什么手动挂载没问题一重启就挂不上的案例满天飞。配置自动挂载时你要同时处理三件事让 iSCSI 的 initiator 在系统启动后自动重新登录 target让 fstab 里的挂载项等待网络和 iSCSI 设备就绪用稳定的设备标识UUID替代不稳定的/dev/sdX设备名。后面我会把这三件事一步一步串起来做。3. 服务端配置用 targetcli 创建带认证的 iSCSI target3.1 安装 targetcli 和基础环境准备服务端通常用 Linux 发行版自带的targetcli工具来管理 target这套工具把内核里的 LIOLinux IO Target封装成了交互式命令配置会持久化到/etc/target/saveconfig.json重启后自动生效不需要额外写开机脚本。以 CentOS/Rocky 系为例安装很简单yum install -y targetcli systemctl enable --now targetDebian/Ubuntu 系把包名换成targetcli-fb服务名是targetcli-fb或target装完顺手systemctl enable --now target即可。这里有个经验配置之前先确认一下要共享的块设备在服务端叫什么名字。我通常用lsblk和blkid先看清楚比如我要共享的是/dev/sdb上的整个盘那就在 targetcli 里直接引用/dev/sdb。如果打算共享的是文件系统镜像文件也可以先用dd创建一个大文件作为 backing store不过性能上不如直接共享块设备生产环境如果条件允许尽量直接给裸盘或分区。3.2 创建 IQN、ACL 和 CHAP 认证的完整步骤进入 targetcli 交互界面依次执行下面这些配置。我先把完整命令贴出来再逐行解释targetcli # 进入 backstores 创建块设备后备存储 / cd /backstores/block /backstores/block create block1 /dev/sdb # 创建 iSCSI target / cd /iscsi /iscsi create iqn.2024-12.example:storage.report # 在 target 下创建 LUN关联刚才的块设备 /iscsi cd iqn.2024-12.example:storage.report/tpg1/luns /iscsi/iqn.../tpg1/luns create /backstores/block/block1 # 配置 initiator 访问控制ACL /iscsi/iqn.../tpg1 cd acls /iscsi/iqn.../tpg1/acls create iqn.2024-12.example:client.report # 设置 CHAP 认证进入 ACL 内配置 /iscsi/iqn.../tpg1/acls cd iqn.2024-12.example:client.report /iscsi/iqn.../tpg1/acls/iqn... set auth useridreportuser /iscsi/iqn.../tpg1/acls/iqn... set auth passwordReport2024 /iscsi/iqn.../tpg1/acls/iqn... set auth mutual_useridstorageuser /iscsi/iqn.../tpg1/acls/iqn... set auth mutual_passwordStorage2024 # 保存配置并退出 / saveconfig / exit逐段说下我的理解。create block1 /dev/sdb是把服务端的/dev/sdb包装成一个块设备后备存储后面创建 LUN 时直接引用block1这个名字即可。create iqn.2024-12.example:storage.report是创建一个新的 targetIQN 的命名规范和域名反写类似一般建议用自己公司的域名加设备名方便维护。create执行完会自动生成tpg1Target Portal Group这是默认的 portal 组客户端通过 IP:3260 连到的就是这个组。ACL 那一步是关键。create iqn.2024-12.example:client.report是声明我允许这个 initiator 访问我的 target这个 IQN 字符串必须和客户端/etc/iscsi/initiatorname.iscsi文件里的 InitiatorName 完全一致一个字符都不能差。如果这里写错了客户端即使 discovery 能看到 targetlogin 也会被拒绝。认证配置我写了四个参数对应双向 CHAP。userid和password是 Incoming 认证也就是服务端验证客户端时用的mutual_userid和mutual_password是 Outgoing 认证也就是客户端反过来验证服务端时用的。如果你只需要单向认证后面两个可以不设但生产环境我推荐直接配双向多两行命令而已安全等级高一个档次。这里有个我踩过的坑targetcli 里设置的 CHAP 密码有长度和复杂度要求太短会直接报错。Password must be at least 12 characters这种提示说明密码不符合要求换一个长一点的复杂密码就好。3.3 验证服务端监听端口和 ACL 生效情况退出 targetcli 后在服务端检查监听端口和全局配置ss -lntp | grep 3260 targetcli lsss输出里应该能看到0.0.0.0:3260在监听。targetcli ls可以查看整个配置树重点确认/iscsi下面的 target、tpg1 里的 ACL、LUN 都正常。如果你看到 ACL 里有刚才创建的 initiator IQN并且 auth 参数已经显示为userid用户名 password加密后的密码就说明服务端认证已经生效。注意targetcli ls里看到的密码是经过混淆处理的不是明文这是正常现象不要以为是配错了。服务端配置到这里就完成了。后面客户端如果连不上排查时先回来看服务端 ACL 和 CHAP 是否匹配大概率问题出在 IQN 写错或者用户名密码不一致上。4. 客户端配置open-iscsi 连接与磁盘发现4.1 安装 open-iscsi 并设置 initiator 名称客户端是 Linux 的话需要安装open-iscsiyum install -y open-iscsi systemctl enable --now iscsid安装完成后/etc/iscsi/initiatorname.iscsi文件里会有一个默认的 InitiatorName大概长这样InitiatorNameiqn.2024-12.example:client.report这个名称必须和服务端 ACL 里创建的那个 initiator IQN 完全一样注意大小写和冒号。如果不一致连接会被目标端拒绝。我一般改完这个文件会顺手执行一次systemctl restart iscsid确保 iscsid 守护进程读到最新的名称。/etc/iscsi/iscsid.conf是另一个重要配置文件里面可以配置node.session.auth.authmethodCHAP等参数但如果你在客户端使用iscsiadm登录时通过--op update指定了认证信息这些参数会被写入到/var/lib/iscsi/nodes/下面的会话配置里优先级高于 iscsid.conf。4.2 手动发现 target 并登录先用 discovery 模式扫描服务端共享的 targetiscsiadm -m discovery -t sendtargets -p 服务端IP:3260执行完如果能看到类似这样的一行输出192.168.10.10:3260,1 iqn.2024-12.example:storage.report说明服务端已经广播了这个 target但此时还没有登录。接下来设置节点的认证信息并登录iscsiadm -m node \ -T iqn.2024-12.example:storage.report \ -p 192.168.10.10:3260 \ -o update \ -n node.session.auth.authmethod -v CHAP iscsiadm -m node \ -T iqn.2024-12.example:storage.report \ -p 192.168.10.10:3260 \ -o update \ -n node.session.auth.username -v reportuser iscsiadm -m node \ -T iqn.2024-12.example:storage.report \ -p 192.168.10.10:3260 \ -o update \ -n node.session.auth.password -v Report2024 # 如果服务端开了双向 CHAP还需要配 mutual 认证 iscsiadm -m node \ -T iqn.2024-12.example:storage.report \ -p 192.168.10.10:3260 \ -o update \ -n node.session.auth.username_in -v storageuser iscsiadm -m node \ -T iqn.2024-12.example:storage.report \ -p 192.168.10.10:3260 \ -o update \ -n node.session.auth.password_in -v Storage2024 iscsiadm -m node \ -T iqn.2024-12.example:storage.report \ -p 192.168.10.10:3260 \ --login这段命令里node.session.auth.username和node.session.auth.password对应服务端的 Incoming CHAP也就是服务端验证客户端时用的用户名和密码node.session.auth.username_in和node.session.auth.password_in对应服务端的 OutgoingmutualCHAP是客户端验证服务端用的。两个方向容易搞混我当时的记忆技巧是username_in里的_in表示验证进来的连接时的凭据在双向 CHAP 下这个值要填服务端设置的mutual_userid和mutual_password。登录成功后执行lsblk应该能看到新的磁盘设备比如/dev/sdb。再执行iscsiadm -m session能看到当前活跃的会话信息。到这一步客户端已经能像使用本地硬盘一样使用远端存储了但还没有解决重启后自动恢复的问题。4.3 为什么建议先手动挂载验证磁盘完整链路在实际配置自动挂载之前一定要先手动完成一次从 discovery 到 login 到挂载的完整验证。原因很简单自动挂载不过就是把手动登录挂载这几个动作延迟到开机时执行链路本身不通的话写再多配置都是白搭。手动挂载的操作是mkfs.xfs /dev/sdb # 第一次使用的盘才需要格式化已有数据别乱动 mkdir -p /data/report mount /dev/sdb /data/report格式化这步要特别注意如果你的 iSCSI LUN 是刚从存储阵列上新划出来的盘需要先建文件系统但如果这个盘已有数据比如从别的机器迁移过来的千万不要执行 mkfs否则数据直接清零。我在生产环境里习惯先用blkid /dev/sdb看一眼有没有现成的文件系统痕迹确认无误再决定要不要格式化。挂载之后写一个测试文件再手动卸载重挂一次确认数据没问题。做完这些基础验证后我们再进入自动挂载阶段。5. 开机自动挂载fstab、_netdev 和 systemd 方案5.1 先调整 iscsi 自动登录参数自动挂载第一步是让 open-iscsi 在开机时自动重新登录 target。这个开关不在 fstab 里而在/var/lib/iscsi/nodes/下的节点配置里有一个叫node.startup的参数默认值通常为manual意思是只有手动执行iscsiadm --mode node --login才登录。我们需要把它改成automaticiscsiadm -m node \ -T iqn.2024-12.example:storage.report \ -p 192.168.10.10:3260 \ -o update \ -n node.startup -v automatic改完可以查看确认iscsiadm -m node -T iqn.2024-12.example:storage.report -p 192.168.10.10:3260输出里node.startup应该显示为automatic。这一步做完重启后 open-iscsi 会尝试自动登录这个 target然后磁盘设备名比如/dev/sdb会出现。但它只保证出现设备不保证挂载到目录所以还需要配 fstab 或 systemd mount 单元。5.2 获取磁盘 UUID避免设备名漂移这是整个自动挂载配置里最重要的一个细节。直接写/dev/sdb /data/report xfs defaults 0 0是最常见的 beginner mistake因为 iSCSI 设备在系统里枚举顺序不稳定如果机器上同时插了两块本地盘、一个 U 盘或者多个 iSCSI LUN重启后/dev/sdb有可能变成/dev/sdc甚至更糟。而且 systemd 对/etc/fstab里的设备名解析是见到什么挂什么一旦设备名变了挂载就会失败。正确的做法是通过blkid拿到文件系统的 UUIDblkid /dev/sdb输出大概是/dev/sdb: UUIDa1b2c3d4-xxxx-xxxx-xxxx-xxxxxxxxxxxx TYPExfs然后把 UUID 写进 fstab。注意 fstab 里UUID后面不要加引号不同版本对引号宽容度不一样但去掉引号最稳UUIDa1b2c3d4-xxxx-xxxx-xxxx-xxxxxxxxxxxx /data/report xfs defaults,_netdev,x-systemd.device-timeout30 0 0重点是_netdev这个挂载选项。它告诉 systemd这是一个依赖网络的设备必须等到网络可用之后再尝试挂载。没有_netdev系统可能在网卡还没有就绪时就尝试挂载 iSCSI 设备此时设备节点根本不存在挂载直接失败。x-systemd.device-timeout30是 systemd 的专门参数意思是等设备最多 30 秒超过就放弃并进入失败状态防止系统无限期卡住。我一开始也以为只要写了_netdev就万事大吉实际测试发现如果服务端暂时不可达比如存储阵列重启比较慢systemd 默认超时时间挺长的开机时会卡在Waiting for device很久。加了这个超时参数后系统最多等 30 秒就放弃挂载并继续启动至少不会把整台机器拖死。5.3 用 mount -a 验证 fstab 和 systemd 方案的取舍写完 fstab 后先不要急着重启执行umount /data/report mount -a如果没有任何报错再执行df -h看挂载是否成功。mount -a会按 fstab 里的配置重新挂载所有尚未挂载的文件系统这一步能提前发现语法错误和路径错误比直接重启高效得多。还有一条路是完全放弃 fstab用 systemd mount 单元来实现自动挂载。io 的时候直接生成一个/etc/systemd/system/data-report.mount文件[Unit] DescriptionMount iSCSI LUN for report Afternetwork-online.target Wantsnetwork-online.target [Mount] What/dev/disk/by-uuid/a1b2c3d4-xxxx-xxxx-xxxx-xxxxxxxxxxxx Where/data/report Typexfs Optionsdefaults,_netdev [Install] WantedBymulti-user.target然后启用systemctl enable>iscsiadm -m session lsblk df -h如果 iSCSI 会话自动建立、磁盘设备存在且/data/report已挂载说明配置成功。此时还可以顺手验证设备路径是否和预期一致。如果发现设备名变了但 UUID 没变恰恰证明我们用 UUID 而不是/dev/sdX是正确选择。6. 认证失败的典型表现与排查技巧6.1 CHAP 认证失败会看到什么报错CHAP 认证失败最常见的一种表现是执行iscsiadm --mode node --login时提示authentication failed但 discovery 是成功的。为什么 discovery 能看到 target、登录却失败因为 discovery 阶段默认不强制认证而 login 阶段会根据服务端 ACL 里的 CHAP 配置验证客户端凭据用户名或密码不对就会直接拒绝。另一种表现是登录命令卡住很久后才超时最后报Connection timed out。这种情况首先要怀疑网络连通性其次要考虑服务端防火墙是否放行了 3260 端口然后再考虑认证配置。排查顺序建议先ping服务端 IP再用nc -vz 服务端IP 3260测端口最后才去看 CHAP 参数。6.2 常见的 CHAP 配置错误对照表现象可能原因解决方法discovery 正常login 报 authentication failed用户名或密码错误服务端 ACL 未配置该 initiator IQN核对服务端 targetcli auth 参数核对客户端 node.session.auth 参数mutual CHAP 配置后 login 报 failedusername_in和password_in与服务端mutual_userid/mutual_password不一致在服务端targetcli ls查看 outgoing 认证用户名客户端对应填到username_in客户端配置文件里的密码含有特殊字符导致解析错误没有给密码加引号$、!等字符被 shell 转义在执行iscsiadm -o update时用单引号包裹密码重启后 iSCSI 设备出现但 fstab 挂载失败fstab 里的_netdev或 UUID 写错设备超时重新执行blkid获取 UUID检查 fstab 挂载选项iscsiadm -m session能看到会话但/dev/sdb消失设备名漂移udev 规则生效慢用/dev/disk/by-uuid/路径访问不要直接用/dev/sdX排查 CHAP 问题有个技巧在客户端登录前先执行iscsiadm -m node -T IQN -p IP:3260看输出里的node.session.auth.*参数确认这些参数确实是本次登录会使用的值。有时候你改了 iscsid.conf但节点配置里存的值没变导致看起来改了配置实际没生效。6.3 开机自动挂载卡死的经典现象和处置方法我在实际运维中遇到过一个最典型的场景机器重启后停在A start job is running for /data/report等了几分钟才进入系统进入后 iSCSI 盘没挂上。排查看下来问题有两层第一层fstab 里的_netdev写对了但x-systemd.device-timeout没写systemd 默认等待时间过长。处理方式是加上超时参数或者改成 systemd mount 单元来细化控制。第二层服务端 target 其实没有启动。存储阵列重启比较慢客户端开机时网络已通但 3260 端口还没监听加上 iSCSI 登录自动重试次数有限首次失败后不会一直重试最终表现就是设备节点从未出现。这个问题的治本方案有两个方向在服务端确保 target 服务开机自启并将/etc/target/saveconfig.json里的 LUN 状态设为 ready在客户端给 fstab 加上更宽松的超时和重试比如x-systemd.device-timeout60或者用单独的服务单元做延迟重试挂载。如果机器上跑的是关键业务我建议再加一层保险写一个小的 systemd oneshot 服务开机后先检查 iSCSI 设备是否存在不存在则执行iscsiadm重新登录和mount -a并记录日志。虽然 fstab 搞定了大部分场景但存储阵列启动比机器慢是常有的事多点冗余总是好的。7. 再聊聊双向认证思路在 iSCSI 里的落地7.1 从 mTLS 到 Mutual CHAP验证方向的一致性热词里提到的tomcat 作为客户端请求服务端实现 mtls 双向认证配置这个场景的核心语义是客户端验证服务端服务端也验证客户端。而 iSCSI 的双向 CHAP 在方向性上其实和它是一致的。如果你已经熟悉 mTLS 的配置思路配置 iSCSI Mutual CHAP 时可以类比理解mTLS 里客户端要有客户端证书服务端要有服务端证书两边互相验签iSCSI Mutual CHAP 里服务端要配置 Incoming 验证用的用户密码同时还要配置 Outgoingmutual验证用的用户密码两边互相验密码。mTLS 里证书由 CA 签发iSCSI 里没有 CA 的概念凭据就是共享密钥所以保管好 CHAP 密码和保管好私钥证书一样重要。mTLS 的证书有有效期CHAP 密码通常也需要定期轮换不要配完就忘建议把密码轮换纳入日常运维计划。不过要注意别被双向这个词绕晕。iSCSI 的双向 CHAP 配置起来比 mTLS 简单得多不存在证书文件分发、信任链配置这些问题本质上就是两对用户名密码。7.2 服务端和客户端各自要维护的认证配置清单角色涉及文件/命令关键配置项说明服务端 targettargetcli交互配置持久化到/etc/target/saveconfig.jsonauth userid、auth password、auth mutual_userid、auth mutual_password分别对应 Incoming 和 Outgoing 两个方向的 CHAP 凭据客户端 initiator/etc/iscsi/initiatorname.iscsi、iscsiadm -o update写入/var/lib/iscsi/nodes/node.session.auth.username、node.session.auth.password、node.session.auth.username_in、node.session.auth.password_inusername/password用于回应服务端 Incoming 验证username_in/password_in用于发起对服务端的 Outgoing 验证对照这个表格配一遍基本不会出现方向错乱的问题。我见过有的同事把username_in和username填反配了一个小时还是认证失败最后发现是方向搞错了。建议你在配置时就按照表格里的命名规则来填不要把两个方向当成一回事。8. 我踩过的坑和最终建议自动挂载这个主题看着简单实际配一轮下来坑基本集中在三个地方一是 IQN 不一致导致连不上二是 fstab 缺_netdev导致开机卡死三是 CHAP 方向填反导致认证失败。这三个坑只要提前知道基本都能快速避开。我个人的习惯是先把服务端 targetcli 配置完整做完确认 ACL 和 CHAP 无误后再到客户端手动 discovery 和 login登录成功后再用 UUID 方式写 fstab最后重启验证。整套流程其实十分钟就能跑完但能省掉后续无数次的存储掉线排查。这里再分享一个容易被忽略的小技巧定期检查/etc/target/saveconfig.json的备份。targetcli 的配置虽然会自动保存但如果你在服务端做过系统迁移、升级内核版本偶尔会出现配置加载异常的情况。养成把saveconfig.json定期导出备份的习惯关键时刻能救命。最后建议所有做存储相关运维的朋友在 iSCSI 配置完成后写一个简短的 README记录服务端 IQN、客户端 InitiatorName、CHAP 用户名、挂载目录、UUID 这些关键信息。倒不一定要上什么配置管理工具一份纯文本记录就能让半年后的你或者接手的同事少走很多弯路。