前两天有人问我生产环境重启之后 iSCSI 盘没自动挂上业务起不来应该怎么查。这个问题我前前后后踩过不少坑正好今天把 iSCSI 开机自动挂载和认证配置完整地梳理一遍。iSCSI 本身不复杂就是把远端存储卷通过网络映射成一块本地块设备但涉及开机顺序、CHAP 认证、挂载选项这些细节时一个参数写错就可能让服务器卡在启动界面或者挂进一个不可用的文件系统。这篇文章会从 Initiator 端配置讲起把认证参数、开机自动登录、fstab 和 systemd 挂载方案的取舍以及排查流程都串起来适合正在搭共享存储、做数据库扩容或者第一次接触 iSCSI 存储的运维和开发同学参考。1. 项目背景与整体思路1.1 这个配置到底要解决什么问题iSCSI 的本质是用 TCP/IP 网络传输 SCSI 命令把存储设备上的 LUN 映射到客户端主机上客户端把它当成一块本地硬盘来使用。好处是成本低、部署灵活、跨机房也能做存储扩展坏处是它不像本地 SATA/SAS 盘那样插上就能用它依赖一条完整的链路网络通了、initiator 启动、target 登录成功、认证通过、设备节点出现文件系统才能挂载。“开机自动挂载”这个需求的难点也就在这个链路上。服务器重启以后网络服务可能还没就绪iscsid 守护进程可能还没启动甚至是 iSCSI Target 端还没把卷暴露出来这时候如果系统按传统方式读取 /etc/fstab 去挂载很容易挂载失败。更麻烦的是如果 fstab 里写了这项挂载但没加合适的挂载参数系统在启动时就可能一直等着最后直接进入 emergency mode把整台服务器卡住。1.2 认证配置为什么不能省很多内网部署的同学觉得 iSCSI 在私有网络里不做认证也无所谓。实际上一旦存储卷挂在主机上目标端的 LUN 就像一个裸设备任何能访问到这个 IP 和 iSCSI 端口的主机只要配置了同一个 Target 名称就可能把卷认走甚至对它做格式化或者覆盖写。轻则数据损坏重则整个存储集群出现问题。iSCSI 原生带的安全机制是 CHAPChallenge Handshake Authentication Protocol简单说就是验证用户名和密钥。它分为单向 CHAP 和双向 CHAPMutual CHAP单向 CHAP 只验证发起端也就是客户端要把账号密码交给 targettarget 确认后才允许登录双向 CHAP 则要求 target 和 initiator 互相验证类似现在做服务间通信时用的 mTLS 双向证书认证双方都证明自己的身份。所以这个项目的配置思路非常清晰先准备客户端环境、再配置 CHAP 认证并确认手动登录成功、然后设置 iSCSI 登录自启动最后通过 fstab 或 systemd 完成开机自动挂载。我们按这个顺序一步步来每步都有验证出问题也知道卡在哪里。2. 环境准备与基础配置2.1 内核支持和安装 open-iscsi 工具iSCSI initiator 在 Linux 下最常用的是 open-iscsi 软件包它由 iscsid 守护进程和 iscsiadm 管理命令组成。绝大多数 Linux 发行版的内核都内置了 iSCSI 相关模块所以一般不需要重新编译内核我们只要确认模块能加载、工具链装好就行。安装的时候注意区分系统包管理器。我这里演示两种常见场景。# Debian / Ubuntu apt update apt install -y open-iscsi # RHEL / CentOS / Rocky Linux yum install -y iscsi-initiator-utils安装后首先把 iscsid 服务启动并设为开机自启。这里有个很容易忽略的点iscsid 服务本身必须开机启动否则后面就算配置了 iSCSI 自动登录重启后也没有守护进程来执行登录动作。systemctl enable --now iscsid systemctl status iscsid检查内核是否支持 iSCSI 也可以顺手看一眼。ls /sys/class/iscsi_host/能列出 host 设备说明内核模块已经就绪。如果目录为空多半是模块没有加载可以执行modprobe iscsi_tcp手动加载再重新确认。2.2 配置一个唯一且规范的 InitiatorNameiSCSI 区分一台主机靠的是 InitiatorName。它一般写在/etc/iscsi/initiatorname.iscsi文件里。安装完工具后这个文件会生成一个默认值但这个默认值通常过于通用在多个节点拷贝镜像或者批量交付时容易撞名一旦撞名target 端会认为这是同一个 initiator导致踢掉另一个主机的会话。规范的 iSCSI 名称格式推荐使用 IQN形如iqn.2024-08.com.example:client01。它的结构依次是“iqn”前缀、年份月份、反向域名、冒号后自定义标识。# /etc/iscsi/initiatorname.iscsi InitiatorNameiqn.2024-08.com.example:client01修改后重启 iscsid 服务然后用下面命令确认iscsiadm -m node -o show | grep node.name如果你想确认 target 端到底能不能看到这台主机的正确名称也可以在启动器主机上执行cat /etc/iscsi/initiatorname.iscsi这里我有一个小建议在私有云或虚拟化环境里InititorName 最好能对应主机的主机名比如client01就是那台主机的规范化名称。后面排障的时候target 端会话列表一出来你一眼就知道是哪台机器连着不用靠猜。2.3 提前确认 Target 端已创建好目标自动挂载要成功前提是 target 端存储卷已经准备好。这个环节虽然在存储侧配置但很容易在实验环境里漏掉。下面这段是以 Linux 上常见的 tgt 软件作为 target 的示例方便演示。# 这是 target 端配置仅示意 yum install -y scsi-target-utils # /etc/tgt/conf.d/myshare.conf target iqn.2024-08.com.example:data01 backing-store /dev/sdb initiator-address 192.168.10.0/24 /target实际生产环境可能是硬件存储、商业存储阵列或者另一台服务器目标端配置各有不同但核心要确定目标名称、IP 地址、端口默认3260、LUN ID、允许的网段、CHAP 账号密码这些参数在启动器侧配置时全都会用到。3. 认证配置与参数拆解3.1 CHAP 认证的核心概念和约定CHAP 认证发生在 initiator 和 target 建立会话之前。整个过程简单说就是 initiator 尝试发请求target 返回一段随机质询initiator 用双方共享的密钥计算哈希回传target 校验通过后建立会话。因为密钥本身不会在网络上传明文比 Telnet 时代传密码的方式安全得多但在实际配置中仍然要注意密钥强度和保存方式。CHAP 协议里有两个方向的凭证IncomingUsertarget 校验 initiator 的用户名和密码也就是 initiator 登录 target 时提交的凭证。单向 CHAP 配这个就够了。OutgoingUserinitiator 校验 target 的用户名和密码配合 IncomingUser 一起使用时就形成了双向 CHAP。我习惯用一句话记忆Incoming 是 target 检查进来的人Outgoing 是 target 出去时带的凭证。配置时只要想清楚“谁验证谁”就不会颠倒了。3.2 在 Target 端配置 CHAP以 tgt 为例如果 target 使用的是 tgt配置方式是在 target 配置段里加上incominguser和outgoinguser。下面是一段双向认证的 target 配置示例# target 端 /etc/tgt/conf.d/myshare.conf target iqn.2024-08.com.example:data01 backing-store /dev/sdb initiator-address 192.168.10.0/24 incominguser iscsi_user MySecurePass2024 outgoinguser iscsi_target_user TargetSecurePass2024 /target重启 tgt 服务让配置生效后可以查看 target 配置systemctl restart tgtd tgtadm --mode target --op show如果存储阵列是图形界面管理逻辑类似在目标卷上启用 CHAP填一个入站账号和一个出站账号并记住这些账号绝对不能和别的 target 共用尽量做到一把钥匙开一把锁。3.3 在 Initiator 端配置 CHAP 并手动登录客户端上的配置都用 iscsiadm 完成。首先做 discover发现远端 targetiscsiadm -m discovery -t sendtargets -p 192.168.10.100:3260执行成功后iscsiadm 会把发现的节点信息保存到本地节点数据库里。接着配置 CHAP 认证参数用-o update更新指定节点的属性。# 设置认证方式为 CHAP iscsiadm -m node -T iqn.2024-08.com.example:data01 -p 192.168.10.100 -o update -n node.session.auth.authmethod -v CHAP # 设置 initiator 提交给 target 的用户名和密码 iscsiadm -m node -T iqn.2024-08.com.example:data01 -p 192.168.10.100 -o update -n node.session.auth.username -v iscsi_user iscsiadm -m node -T iqn.2024-08.com.example:data01 -p 192.168.10.100 -o update -n node.session.auth.password -v MySecurePass2024 # 如果是双向 CHAP还需要配置 target 返回给 initiator 的凭证 iscsiadm -m node -T iqn.2024-08.com.example:data01 -p 192.168.10.100 -o update -n node.session.auth.username_in -v iscsi_target_user iscsiadm -m node -T iqn.2024-08.com.example:data01 -p 192.168.10.100 -o update -n node.session.auth.password_in -v TargetSecurePass2024这里要花点篇幅解释几个关键点。第一CHAP 密码最少 12 位有些 target 端实现还要求长度不低于 12 位这是协议本身的安全要求。如果你配置的密码短了会发现登录时总是 authentication failure但看日志又看不出明显原因其实就是长度不满足。第二带特殊字符的密码建议用单引号包起来避免 shell 解释。尤其是$、!、*这些字符在 bash 里可能会有特殊含义不包引号很容易把真实密码改错。第三-o update只会更新节点数据库不会立刻登录所以我们再用 login 命令建立会话。iscsiadm -m node -T iqn.2024-08.com.example:data01 -p 192.168.10.100 --login登录后可以用两个命令确认状态iscsiadm -m session lsblk | grep sd如果会话建立成功你会看到远端磁盘设备出现在系统里。此时手动挂载一下确认文件系统能访问mkdir -p /data mount /dev/sdb1 /data df -h /data到这里手动链路是通的认证也验证过了。接下来才进入“开机自动挂载”的核心部分。3.4 认证参数持久化和 node.startup 的关系很多人配置完认证后重启 iSCSI 会话就丢了原因不是认证参数没保存而是节点未被设置为“自动登录”。open-iscsi 对每个节点都有一个node.startup属性值可以是automatic或manual。默认情况下discovery 出来的节点是 manual也就是重启后需要手动 login。设置成 automatic 之后iscsid 服务一旦启动就会自动对标记为 automatic 的节点发起登录。这一步是开机自动挂载的前提条件之一也是认证参数能持续生效的载体。iscsiadm -m node -T iqn.2024-08.com.example:data01 -p 192.168.10.100 -o update -n node.startup -v automatic设置完以后用iscsiadm -m node -o show看到该节点的 startup 已经是 automatic。需要提醒的是-T加-p的组合要跟之前一致最好连同 portal 一起写清楚避免操作到另一个同名节点。4. 开机自动挂载的落地实现4.1 先想清楚开机过程的前后顺序开机自动挂载能不能成取决于系统启动时事件的先后顺序。正常情况下systemd 会先拉起网络服务再启动 iscsid然后 iscsid 根据 automatic 节点发起 iSCSI 登录等磁盘设备出现后systemd 再处理文件系统挂载。这个链条里任何一个环节没有就绪自动挂载就会失败。传统/etc/fstab在系统初始化阶段就会执行挂载但网络和 iSCSI 设备可能还没就绪。所以 fstab 里必须给挂载选项加上_netdev它的含义是告诉系统“这个设备依赖网络等网络准备好之后再挂载。”这能避免系统启动时盲目去挂载一个还没出现的块设备。如果不用_netdev最典型的现象就是开机卡在 “A start job is running for /data” 很久最后挂载失败。另外强烈建议在 fstab 里再加nofail。这个选项的意思是即使挂载失败也不要卡住系统启动允许系统继续往下走。对于业务关键型存储你可能希望挂载失败就立刻失败、尽快暴露问题但至少在你的排障窗口内nofail 能防止服务器直接进 emergency 模式。等一切稳定了可以根据需要决定要不要去掉 nofail。4.2 方案一使用 /etc/fstab 配合 _netdev推荐先把磁盘分区格式化好然后获取设备 UUID。之所以一定要用 UUID而不是/dev/sdb1是因为系统重启后设备名可能会变。今天sdb是这块盘明天多插一块盘就可能变成sdc但 UUID 在一个文件系统生命周期内是不变的。mkfs.xfs /dev/sdb1 blkid /dev/sdb1假设输出中 UUID 是12345678-abcd-4ef0-1234-5678abcdef90那么 fstab 条目这样写# /etc/fstab UUID12345678-abcd-4ef0-1234-5678abcdef90 /data xfs _netdev,nofail,x-systemd.device-timeout60 0 0解释一下这行参数的选择_netdev告诉 systemd 这个挂载项要等网络就绪。nofail挂载失败不阻塞开机。x-systemd.device-timeout60限制等待设备出现的最大秒数。默认可能等 90 秒甚至更久如果 iSCSI target 端暂时不可用系统就会在启动时干等。设成 60 秒后超过时间直接继续启动。写完后先不要急着重启执行mount -a df -h /data如果mount -a能正常挂载说明 fstab 语法没有问题。之后可以用findmnt /data确认挂载来源是 UUID 而非设备名。4.3 方案二使用 systemd mount unit更精细控制如果你的环境对启动顺序要求严苛比如数据库依赖这块存储且在挂载后需要立即启动某个服务那么可以跳过 fstab直接写 systemd mount unit。systemd 会把 fstab 转换成 unit但显式写 unit 能让你更清楚地声明依赖关系。假设挂载点是/data创建一个名为data.mount的服务单元# /etc/systemd/system/data.mount [Unit] DescriptionMount iSCSI data volume Afternetwork-online.target iscsid.service Wantsnetwork-online.target [Mount] What/dev/disk/by-uuid/12345678-abcd-4ef0-1234-5678abcdef90 Where/data Typexfs Options_netdev,nofail,x-systemd.device-timeout60 [Install] WantedBymulti-user.target注意systemd 里 unit 的名称必须跟挂载点对应。如果你的挂载点是/mnt/dataunit 文件名就要写成mnt-data.mount否则 systemd 不会把它关联到正确位置。这里我用了/data所以文件名是data.mount。然后启用并验证systemctl daemon-reload systemctl enable data.mount systemctl start data.mount systemctl status data.mount相比 fstabsystemd mount unit 的好处是可以用systemctl查看状态、管理启动顺序、设置超时排障时信息更直观。缺点是多写一个文件对新手没那么直观。实际生产里我更推荐先用 fstab 方案跑通再根据场景决定要不要迁移到 systemd。4.4 形成完整的自动挂载闭环自动挂载不是只配 fstab 就行它需要跟 iSCSI 自动登录配合。完整的闭环是这样# 1. iscsid 开机自启 systemctl enable --now iscsid # 2. 节点自动登录 iscsiadm -m node -T iqn.2024-08.com.example:data01 -p 192.168.10.100 -o update -n node.startup -v automatic # 3. 挂载项带 _netdev grep data /etc/fstab UUID12345678-abcd-4ef0-1234-5678abcdef90 /data xfs _netdev,nofail,x-systemd.device-timeout60 0 0配置完成后建议做一次重启验证。重启后依次确认# 会话是否自动建立 iscsiadm -m session # 磁盘设备是否出现 lsblk | grep sd # 挂载是否成功 df -h /data mount | grep /data如果有一个环节不正常就从对应节点往下查。这一步重启验证是整个配置里最值得花时间的地方能省掉很多日后半夜被叫醒的烦恼。5. 常见问题与排查技巧实录5.1 重启后挂载不上先分清是“没登录”还是“没挂载”很多朋友一看到没挂载就去改 fstab但真正问题在 iSCSI 会话压根没建立。重启后先执行iscsiadm -m session如果没有任何会话输出说明不是挂载的问题而是 iSCSI 登录环节就失败了。这时候需要查三件事iscsid 服务是否正常启动systemctl status iscsid节点 startup 是否为 automaticiscsiadm -m node -o show | grep node.startuptarget 端 IP 端口是否可达ping和nc -vz 192.168.10.100 3260通常把 startup 改成 automatic 并确保 iscsid 自启后问题就解决了。如果会话已建立但没挂载再检查 fstab 的挂载参数和是否用了 UUID。5.2 CHAP 认证失败八成是密码、用户名和方向配对问题认证失败的日志通常会出现在内核或 iscsid 日志中表现为authentication failed。常见原因有五个CHAP 密码少于 12 位。initiator 侧配置的用户名/密码跟 target 侧不一致。target 配置了双向 CHAP但 initiator 侧没有配置username_in和password_in。target 端更新认证配置后没有重启或 reload。密码里包含 shell 特殊字符配置的时候因为引号问题写进去的是被解释后的内容。排查时用iscsiadm -m node -T iqn.2024-08.com.example:data01 -p 192.168.10.100 -o show查看当前节点完整参数确认 authmethod 是 CHAPusername、password、username_in、password_in 都是预期的值。不要猜直接把输出贴出来对照 target 端配置。5.3 设备名漂移导致挂载错设备只要用/dev/sdb1这类设备名来挂载早晚会出事。系统盘识别顺序、新插入设备、内核扫描顺序都会影响设备名。建议一律使用blkid获取 UUID或者用/dev/disk/by-path/下带 iSCSI 标识的链路路径。对于多路径环境甚至要用/dev/mapper/下的设备这个下面会单独说。5.4 多路径环境下的自动挂载生产环境里一块存储卷通常通过多条物理链路连接到主机比如两个网卡分别接两个交换机到存储前端。这种情况下就涉及 DM Multipath 多路径主机上看到的多个sd设备其实都对应同一个远端 LUN需要配置 multipath 把它们聚合成一个/dev/mapper/mpathX设备避免同时读写导致文件系统损坏。多路径的典型配置流程# 安装 multipath 工具 yum install -y device-mapper-multipath # 生成 /etc/multipath.conf 并启用 mpathconf --enable # 重新扫描并查看多路径设备 multipath -ll配置完成后fstab 里挂载的不是/dev/sdb1而是/dev/mapper/mpatha1对应的 UUID 同样可以取blkid /dev/mapper/mpatha1需要特别注意多路径环境里建议把user_friendly_names开启让 multipath 的映射名固定否则/dev/mapper/下的名字也可能变化。更稳妥的做法是配置 alias# /etc/multipath.conf multipaths { multipath { wwid 360000000000000000e00000000010001 alias mpath_data } }这样子系统重启后只要 WWID 不变设备映射名就是稳定的即使后续有新的盘插入也不会干扰。5.5 常见问题速查表现象可能原因排查/处理方法重启后没有会话iscsid 未自启 / node.startupmanual启用 iscsid设置 startupautomatic登录超时网络不可达 / target 未启动ping 目标 IP检查防火墙 3260 端口CHAP 认证失败密码长度/用户名/方向不匹配检查 node 参数和 target 端配置fstab 挂载失败用了设备名而非 UUID改用 UUID用 blkid 确认启动卡住很久fstab 缺 _netdev / 缺 nofail加上 _netdev,nofail设 device-timeout挂载点变成只读文件系统异常或前后端时区不同检查 dmesg multipath 和文件系统状态多个 initiator 会话冲突InitiatorName 重复修改 /etc/iscsi/initiatorname.iscsi6. 一些值得记录的实操心得6.1 先把手动链路跑通再谈“开机自动”我踩过最深的坑就是急着配置开机自动挂载结果开机后进不去系统才发现其实手动登录都没能成功。配置 iSCSI 有个铁律discover、login、mount、umount、logout、重启验证每一步都要手动执行一遍确认没问题再配置自动。这条铁律尤其适用于首次接触存储的新手。手动登录成功的标志是iscsiadm -m session有 session 输出然后lsblk能看到新磁盘。只有当你对所有命令都熟练了才能开始写 fstab 和 systemd。别用“简化步骤”换来排查时的痛苦。6.2 认证变更一定要留好回滚路径修改 CHAP 密码或从单向升级到双向认证时建议先停掉业务、卸载挂载点、logout 会话再修改 target 和 initiator 两侧配置。不然在线变更一旦顺序不对会话会被强制断开文件系统可能进入不稳定状态数据库尤其容易出问题。我在实际生产里做过一次在线更新密码以为两边同步改完就没事结果 target 端 reload 后旧会话还在新会话认证失败业务侧某个 ECS 进程的 IO 直接卡死。后面学到的做法是任何认证变更前先在窗口期把服务停掉挂载点从 fstab 临时去掉logout 后再改改完手动 login 并验证再恢复自动挂载配置。6.3 配置文件多备份路径永远写绝对iSCSI 相关的关键文件有三个/etc/iscsi/initiatorname.iscsi、/etc/iscsi/iscsid.conf、/etc/fstab。节点认证参数在 iscsid 自身管理的节点数据库里虽然不直接改文件但备份节点信息可以用iscsiadm -m node -o show把输出保存下来。这样一旦某台机器误删了节点配置可以直接导入。挂载路径也尽量写绝对路径避免脚本里因为~或者相对路径造成误操作。这个小习惯在自动化运维里尤其重要因为你不知道哪天 ansible、salt 或 python 脚本会在什么工作目录下执行这条挂载命令。6.4 没事别手动删会话重启前先 grep 一次 fstab很多人习惯在调试时直接iscsiadm -m session --logout然后忘了重新 login最后跟业务那边说“已经配好了”一重启又是没盘。我的习惯是每次重启前执行一句快速确认iscsiadm -m session | grep iqn grep data /etc/fstab findmnt /data这三条命令同时满足才说明会话存在、fstab 配置存在且当前已挂载。这是一个看起来很笨但极其有效的检查手段它能拦截掉 90% 以上“明明配好却起不来”的低级问题。iSCSI 自动挂载和认证配置说到底是把几个小细节排列组合好initiator 名称唯一、CHAP 凭证齐全、node.startup 设为 automatic、fstab 带 _netdev 和 UUID。按这个顺序配再跑一轮重启验证基本就能稳定运行很久。希望这篇文章能帮你少踩点坑把更多时间留在真正有价值的事情上。