企业官网建设流程全解析

前两天有人问我，生产环境重启之后 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 原生带的安全机制是 CHAP（Challenge Handshake Authentication Protocol），简单说就是验证用户名和密钥。它分为单向 CHAP 和双向 CHAP（Mutual CHAP）：单向 CHAP 只验证发起端，也就是客户端要把账号密码交给 target，target 确认后才允许登录；双向 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 配置一个唯一且规范的 InitiatorName

iSCSI 区分一台主机，靠的是 InitiatorName。它一般写在/etc/iscsi/initiatorname.iscsi文件里。安装完工具后，这个文件会生成一个默认值，但这个默认值通常过于通用，在多个节点拷贝镜像或者批量交付时容易撞名，一旦撞名，target 端会认为这是同一个 initiator，导致踢掉另一个主机的会话。

规范的 iSCSI 名称格式推荐使用 IQN，形如iqn.2024-08.com.example:client01。它的结构依次是“iqn”前缀、年份月份、反向域名、冒号后自定义标识。

# /etc/iscsi/initiatorname.iscsi InitiatorName=iqn.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 协议里有两个方向的凭证：

• IncomingUser：target 校验 initiator 的用户名和密码，也就是 initiator 登录 target 时提交的凭证。单向 CHAP 配这个就够了。
• OutgoingUser：initiator 校验 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，发现远端 target：

iscsiadm -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 UUID=12345678-abcd-4ef0-1234-5678abcdef90 /data xfs _netdev,nofail,x-systemd.device-timeout=60 0 0

解释一下这行参数的选择：

• _netdev：告诉 systemd 这个挂载项要等网络就绪。
• nofail：挂载失败不阻塞开机。
• x-systemd.device-timeout=60：限制等待设备出现的最大秒数。默认可能等 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] Description=Mount iSCSI data volume After=network-online.target iscsid.service Wants=network-online.target [Mount] What=/dev/disk/by-uuid/12345678-abcd-4ef0-1234-5678abcdef90 Where=/data Type=xfs Options=_netdev,nofail,x-systemd.device-timeout=60 [Install] WantedBy=multi-user.target

注意，systemd 里 unit 的名称必须跟挂载点对应。如果你的挂载点是/mnt/data，unit 文件名就要写成mnt-data.mount，否则 systemd 不会把它关联到正确位置。这里我用了/data，所以文件名是data.mount。

然后启用并验证：

systemctl daemon-reload systemctl enable data.mount systemctl start data.mount systemctl status data.mount

相比 fstab，systemd 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 UUID=12345678-abcd-4ef0-1234-5678abcdef90 /data xfs _netdev,nofail,x-systemd.device-timeout=60 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 是否为 automatic：iscsiadm -m node -o show | grep node.startup
• target 端 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 是 CHAP，username、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 常见问题速查表

6. 一些值得记录的实操心得

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。按这个顺序配，再跑一轮重启验证，基本就能稳定运行很久。希望这篇文章能帮你少踩点坑，把更多时间留在真正有价值的事情上。