iSCSI网络存储实战：配置、多路径与认证排错指南

1. 项目概述与核心思路

1.1 iSCSI 是用来干什么的

从年初开始，我陆陆续续给几台测试服务器和一台存储服务器配了 iSCSI 挂载，折腾下来最大的感受是：这玩意儿比想象中简单，但坑也比想象中多。先给还没接触过的朋友把概念捋一遍：iSCSI 全称是 Internet Small Computer System Interface，说人话就是——把一块远程的硬盘，通过 TCP/IP 网络，像本地磁盘一样接到你的服务器上。它和 NFS、SMB 这类文件共享协议最大的区别在于，iSCSI 工作在块级别，客户端看到的是一个裸块设备（比如/dev/sdb），不是文件夹，因此可以在上面任性地分区、格式化、跑数据库、做 LVM、塞给虚拟机当磁盘用。

我这次的实际场景是给一台跑虚拟化的主机扩充存储。原来的思路是加一块物理硬盘，但机器硬盘槽位紧张，而且后续扩容也不方便。后来查了下机房里那台存储服务器（平时只用了一半不到的磁盘），决定直接在上面划一个 LUN，通过 iSCSI 网络挂给虚拟化主机。整个过程从规划到完成，大概花了一个下午，真正手动敲命令的时间不到半小时，中间大部分时间都花在排错上。所以写这篇文章，把服务端和客户端两侧的完整配置都记下来，给后面要弄的人省点事。

1.2 为什么不用 NFS 或 SMB，非要 iSCSI

肯定有人问：共享存储那么多选择，NFS 不是更简单吗？确实，如果只是把文件丢在服务器上共享，NFS/SMB 是更省事的选择，协议层帮你做了文件锁、权限、目录结构，挂载完就能用。但遇到这几种场景，iSCSI 就有不可替代的优势：

第一，需要完整的块设备语义。比如要在共享存储上装 Windows 不能装到 NFS 里，虚拟化平台（KVM、VMware）的数据存储如果要走文件级协议，性能损耗和兼容性问题都比较头疼。而 iSCSI 呈现的是裸块设备，存储上所有事情由客户端说了算，你可以在上面初始化 GPT 分区表、创建 vg 做 LVM，甚至直接放整块给数据库裸设备，灵活性完全由你掌控。

第二，多路径和高可用需要多连接。iSCSI 天生支持 Multipath，可以在客户端创建多条 session 连接同一个 LUN，配合 bonding 或独立网卡实现链路冗余和负载均衡。NFS 虽然也能多路径，但配置复杂度高得多，而且很多平台不支持原生多路径。

第三，行为最接近直连本地盘。对于数据库、虚拟化这类随机 IO 密集的场景，iSCSI 的开销更低，因为内核里 SCSI 子系统和块层是原生支持的路径，不需要额外的文件系统转换层。对像我这种用普通千兆网络跑测试环境的人来说，性能瓶颈通常在网络上，但协议的语义开销确实要比 NFS 小。

当然 iSCSI 也有它的问题，比如部署要操心的东西更多：ACL、认证（CHAP）、多路径、持久化配置，这些在后端都是配置项，写错一个就可能挂不上或性能异常。所以下文我把值得注意的都标注出来。

1.3 环境规划与拓扑说明

我这次实验环境分两台机器：

• 存储服务器（服务端 / Target）：Ubuntu 24.04 LTS，双网卡，IP 为192.168.10.10，跑targetcli管理 iSCSI Target。存储介质是一块 2TB SAS 盘和一个 SSD 缓存盘。
• 虚拟化主机（客户端 / Initiator）：Rocky Linux 9.2，IP 为192.168.10.20，通过 iSCSI 连接 Target 上的 LUN，把它作为 QEMU/KVM 的虚拟机存储池。

生产环境下通常会把 iSCSI 流量单独走一张网卡或 VLAN，避免和业务流量互抢带宽。我这里测试环境没这么讲究，但为了踩踩多路径的坑，我给客户端加了一张万兆网卡，并且启用了 Multipath。这个后面在性能调优章节会展开说。

规划清楚了就动手。下面先讲服务端配置，再讲客户端挂载，最后是我踩过的一堆坑和排查思路。

2. 服务端配置：用 targetcli 建一个 iSCSI Target

2.1 安装与启动 targetcli

服务端配置最核心的工具是targetcli，这是 Linux 上管理 LIO（Linux IO Target）的命令行工具，几乎所有主流发行版都有现成包。Ubuntu 上安装：

sudo apt update sudo apt install -y targetcli-fb sudo systemctl enable --now targetcli

注意 Ubuntu 上包名是targetcli-fb，CentOS/Rocky 上是targetcli，命名略有差异，但命令和用法完全一致。安装完确认一下内核模块有没有加载：

sudo lsmod | grep target_core

如果target_core_mod和target_core_user等模块存在就说明 LIO 已经可用。万一没加载，可以手动modprobe target_core_mod拉起来，但这在标准内核上基本不会出现。

安装好之后不要急着敲命令，建议先规划好三样东西：LUN 对应的块设备、Target 的 IQN 名称、客户端允许列表。

IQN 的全称是 iSCSI Qualified Name，格式一般是iqn.2025-01.com.example:storage1。这里2025-01是你的域名反向解析日期，com.example是你的域名反写，:storage1是自定义标识。理解成“这个存储域的叫一个唯一编号”就行，在整个网络内不能重复。我见过有人顺手乱写个iqn.test，后面管理和排错的时候把自己坑得不轻，所以建议第一次就按规范命名。

2.2 创建块后端并暴露 LUN

我的存储服务器上全新的一块 800GB 未分区盘/dev/sdb，打算直接整盘作为 LUN 暴露出去。进入targetcli交互界面：

sudo targetcli

targetcli是交互式的，但也可以一条条命令敲，有点像思科设备的命令行。以下是我执行的核心操作：

/> cd backstores/block /backstores/block> create block1 /dev/sdb Created new block device block1 with size 800 GiB.

block1是后端的别名，/dev/sdb是对应的块设备。如果磁盘上已经有分区或文件系统，用lsblk看一下，上传整块盘或是分区都可以。但如果是整块盘，确认盘上没有任何重要数据，因为 Target 会直接接管这块盘，Clinet 格式化后该盘原内容会全部消失。

接着创建 iSCSI Target：

/> cd /iscsi /iscsi> create iqn.2025-01.com.example:storage1 Created target iqn.2025-01.com.example:storage1.

这个命令会自动在该 Target 下创建好默认的tpg1（Target Portal Group），可以把它理解成一个“接入点组合”，里面有 portal、LUN、ACL 这些子配置项。再把刚创建的 block 后端挂到 target 上：

/> cd iqn.2025-01.com.example:storage1/tpg1/luns /iscsi/iqn.../tpg1/luns> create /backstores/block/block1 Created LUN 0. Created LUN 0.

这里显示LUN 0表示这是该 Target 的第一个逻辑单元号。客户端看到的盘符（如/dev/sdb）由客户端自行分配，和 LUN 编号没有直接关系。一般一个 Target 对应一个 LUN，除非你要做多 LUN 多业务分离，那就按同样的操作多建几个，注意编号别重复。

2.3 配置监听地址和访问控制

Target 建好了，但还没监听地址，客户端找不到它。默认targetcli会监听所有 IP 的 3260 端口。我在生产环境一般指定具体 IP 而不是全监听，减少暴露面。假设存储服务器的存储网卡 IP 是192.168.10.10：

/> cd /iscsi/iqn.2025-01.com.example:storage1/tpg1/portals /iscsi/iqn.../tpg1/portals> create 192.168.10.10 3260 Using default IP port 3260. Created network portal 192.168.10.10:3260.

如果之前默认配置里已经有一个0.0.0.0:3260的 portal，建议先把默认的删掉再新建，避免客户端连到非预期网卡：

/iscsi/iqn.../tpg1/portals> delete 0.0.0.0 3260 /iscsi/iqn.../tpg1/portals> create 192.168.10.10 3260

访问控制是重头戏。默认情况下，LIO 会拒绝所有未知客户端发起连接，必须显式指定允许访问的客户端 IQN（Initiator IQN）。客户端侧的 IQN 怎么查？在客户端执行：

sudo cat /etc/iscsi/initiatorname.iscsi # 输出类似：InitiatorName=iqn.2023-11.com.example:client01

把我的客户端 IQNiqn.2023-11.com.example:client01加进 ACL：

/> cd /iscsi/iqn.2025-01.com.example:storage1/tpg1/acls /iscsi/iqn.../tpg1/acls> create iqn.2023-11.com.example:client01 Created Node ACL for iqn.2023-11.com.example:client01.

到这里，最基本的配置就完成了。如果想加一层 CHAP 认证（强烈建议加，后面细说），可以这样设置：

/> cd /iscsi/iqn.2025-01.com.example:storage1/tpg1/acls/iqn.2023-11.com.example:client01 /> set auth userid=storageuser /> set auth password=Str0ngPassw0rd! /> set auth mutual_userid=mutual_user /> set auth mutual_password=MutualPassw0rd!

CHAP 密码有长度要求（官方建议至少 12 位，双向 CHAP 的密码必须不同于单向），太短会直接拒绝设置。设置完记得退出并保存配置：

/> cd / /> saveconfig Last 10 configs saved in /etc/target/backup. Configuration saved to /etc/target/saveconfig.json.

saveconfig这步不能省。targetcli的配置默认是临时的，不保存的话服务一重启，所有 Target、LUN、ACL 设置全丢。保存后配置在节点重启时会自动加载，这是我最开始踩过的坑之一（后文会再提）。

2.4 服务端防火墙与开机自启

如果你机器上开过 ufw 或 firewalld，记得把 3260/tcp 端口放行：

# Ubuntu sudo ufw allow 3260/tcp # Rocky/CentOS sudo firewall-cmd --permanent --add-port=3260/tcp sudo firewall-cmd --reload targetcli 服务本来已经 enable 了，但如果你的系统把 `rtslib` 或 `target` 服务关过，确认一下： systemctl status targetcli # 确保 active (running)

到这里服务端就绪，可以把网线插好，准备客户端搞事了。

3. 客户端挂载：initiator 与磁盘管理

3.1 Linux 客户端：安装 open-iscsi 并发现 Target

客户端要装的是open-iscsi（现代发行版上叫iscsi-initiator-utils）。Rocky 上：

sudo dnf install -y iscsi-initiator-utils sudo systemctl enable --now iscsid iscsi

Ubuntu/Debian 上是：

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

装完之后要保证 iscsid 在运行。接着发现 Target：

sudo iscsiadm -m discovery -t sendtargets -p 192.168.10.10:3260 # 输出应包含类似： # 192.168.10.10:3260,1 iqn.2025-01.com.example:storage1

这一步的输出说明 Target 已经被发现。如果这里就超时或没有输出，先检查两边网络通不通（ping能通但发现失败很可能就是 3260 端口被墙了，或者 portal 配置错了），我后文排错部分会展开。

发现之后，-m node 就能看到这个 target：

sudo iscsiadm -m node 192.168.10.10:3260,1 iqn.2025-01.com.example:storage1

注意如果你没在服务端配 ACL，这里节点信息也出得来，但后续登录时会被拒绝——别问我是怎么知道的。

3.2 登录 LUN 与磁盘验证

正式登录到 Target：

sudo iscsiadm -m node -T iqn.2025-01.com.example:storage1 -p 192.168.10.10:3260 --login

登录成功的话，dmesg | tail会看到 SCSI 设备加入的日志。然后fdisk -l或lsblk就能看到新的块设备了：

sudo lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 80G 0 disk sdb 8:16 0 800G 0 disk

/dev/sdb就是我们暴露出去的 800GB LUN。注意这个盘现在是裸块设备，像一张白纸，需要你自己分区、格式化、挂载——这就是“块级协议”和“文件级协议”最大的区别。我第一次用 iSCSI 的时候以为挂载完就自动出现在/mnt里，结果什么都没有，愣了半天。后来才反应过来，iSCSI 给你的只是硬盘本身，不是文件夹。

接下来按常规操作分区格式化：

sudo parted /dev/sdb mklabel gpt sudo parted /dev/sdb mkpart primary xfs 0% 100% sudo mkfs.xfs /dev/sdb1 sudo mkdir /mnt/iscsi-backup sudo mount /dev/sdb1 /mnt/iscsi-backup

这里我选了 XFS 文件系统，因为它对大容量和高并发写入比较友好，也适合虚拟机存储。如果你的用途是跑数据库，可能要评估 ext4 或 xfs 的差异，或者干脆不做文件系统，直接把裸设备交给数据库/虚拟化层。这个选择空间就是 iSCSI 的灵活性所在。

3.3 开机自动挂载：千万别只写 fstab

把 iSCSI 盘挂到/mnt/iscsi-backup之后，还要解决重启自动挂载的问题。很多人直接往/etc/fstab里写一行，等重启后就会发现起不来，原因很简单：系统启动时，网络和 iSCSI session 尚未就绪，文件系统挂载顺序早于网络就绪。

正确做法分两步：第一步把 open-iscsi 服务的开机自启打开（systemctl enable --now iscsid iscsi，前面装了就会自动启用），第二步再配置 node 的自动登录：

sudo iscsiadm -m node -T iqn.2025-01.com.example:storage1 -p 192.168.10.10:3260 --op update -n node.startup -v automatic

这个操作把该节点的 startup 属性更新为automatic，系统重启后 iscsid 会自动重新登录 target，块设备就回来了。

然后检查是否需要在 fstab 里写挂载。我给虚拟化平台用的盘最终是交给 libvirt 管理，不需要在宿主机上挂载文件系统，所以 fstab 就省了。但如果你要持久挂到某个目录，建议 fstab 里用 UUID 而不是设备名，因为 iSCSI 盘的设备名可能重启后变化（/dev/sdb变/dev/sdc这种事很常见）。先查 UUID：

sudo blkid /dev/sdb1 # 类似输出：/dev/sdb1: UUID="4d3a...-...." TYPE="xfs"

然后 fstab 里写：

UUID=4d3a...-.... /mnt/iscsi-backup xfs _netdev,nofail 0 0

_netdev让系统等网络就绪后再挂，nofail允许该设备暂时缺失时系统仍能正常启动，这两参数配合 iSCSI 是标准组合，少了任何一个都可能重启直接进救援模式。

3.4 Windows 客户端：记住几个关键操作点

虽然我日常不常用 Windows 当 initiator，但测试虚拟机里有 Windows，也顺手写过一遍。Windows 自带 iSCSI 发起程序，不用额外装，直接搜索“iSCSI 发起程序”打开即可。步骤大致是：

1. 在“目标”标签页输入 Target 的 IP，点“快速连接”，会列出发现到的 IQN。
2. 如果配置了 CHAP，需要点“高级”按钮，填入“启用 CHAP 登录”的用户名和密码。
3. 连接成功后，到“磁盘管理”里操作新出现的磁盘，初始化、分区、格式化。

有一个特别容易忽略的地方：Windows 的 iSCSI 发起程序默认不自动重新连接，虚拟机重启后盘可能丢。需要到“目标”页右键对应的 Target，点“连接”，在弹窗里勾上“将此连接添加到收藏目标列表”，这样 Windows 启动时会自动重连。

另外，如果你的 Windows 虚拟机只配了一块虚拟网卡，而虚拟化平台用的又是 iSCSI，连续登录失败几次之后再去看，很容易发现发起程序连接的 IP 不是你预期的——这个牵涉到多路径和虚拟网卡透传，生产环境建议 Windows 侧单独配置一张存储网卡，别跟业务流量混在一起。

4. 性能调优与多路径：除了挂上，还要挂得稳

4.1 打通 TCP 和块层的关键参数

挂载只是第一步，性能好不好，还要看几个关键的 TCP 和块设备参数。我在配万兆网卡时首先调的是 MTU（Jumbo Frame）。标准以太网 MTU 是 1500 字节，两块万兆网卡如果都支持 9000 字节巨型帧，iSCSI 层的大块传输可以减少拆包次数，延迟和 CPU 占用都会下降。

在客户端和服务端网卡上同时配置：

# 存储服务器 sudo ip link set dev eth0 mtu 9000 # 客户端 sudo ip link set dev eth1 mtu 9000

注意两端要同时改，只改一边会直接用不了，或者跑出奇怪的性能问题（比如小包能通、大包全丢）。改完用ping -M do -s 8972 192.168.10.10验证，能通说明 MTU 调整生效（8972 是因为 9000 减去 28 字节 ICMP/IP 头）。

然后是队列深度（queue depth）和 IO 调度器。queue depth 指设备一次允许多少条未完成 IO 请求进入队列，太浅则并发上不去，太深则会增加延迟和内存占用。Linux 默认的块层队列深度对于千兆网来说够用，但万兆或 SSD 后端建议调大：

# 查看当前队列深度 cat /sys/block/sdb/device/queue_depth # 调整（生产环境慎重，测试可尝试） echo 64 > /sys/block/sdb/device/queue_depth

注意这个参数在服务器端也有对应项，但通常情况下客户端调完就有收益，服务端默认值已经挺高的。如果性能依然不理想，检查 I/O 调度器是否在 NVMe/SSD 设备上用了错误的类型：

cat /sys/block/sdb/queue/scheduler # 对 SSD 存储一般推荐 none 或 mq-deadline，机械盘用 noop/null

我的存储服务器后端是 SSD 缓存盘，客户端是虚拟化宿主机，官方文档和社区反馈都建议对这种随机 IO 场景把调度器设为 none，实测下来确实有百兆级别的带宽收益。

4.2 多路径 MPIO：从单点到两条腿走路

生产环境最怕的是“线断了盘就丢”。iSCSI 的解法是多路径（Multipath），也就是客户端通过多条物理链路连接同一个 LUN。常见做法是给客户端和服务端各插两块网卡，用两个独立 IP 在 iSCSI 层建立两个 session。这样一条链路断了，IO 会自动切换到另一条，对上层应用完全透明。

Linux 下用 multipath-tools 配置：

sudo dnf install -y device-mapper-multipath sudo mpathconf --enable

配置前先确认 iSCSI 已经建了两个 session：

sudo iscsiadm -m session # 如果只有一个 Portal，需要再添加一个（假设服务端第二 IP 是 192.168.10.11） sudo iscsiadm -m discovery -t sendtargets -p 192.168.10.11:3260 sudo iscsiadm -m node -T iqn.2025-01.com.example:storage1 -p 192.168.10.11:3260 --login

然后编辑/etc/multipath.conf，核心是把你要用的盘加进黑名单白名单，不然 multipath 可能把系统盘也做成 dm 设备，导致 root 分区挂在 multipath 虚拟设备上，重启可能找不到盘。我一般这样配：

defaults { user_friendly_names yes find_multipaths yes } blacklist { devnode "^sd[a-z]$" } blacklist_exceptions { devnode "^sdb$" }

意思是默认黑名单所有sd设备，只放行sdb（iSCSI 盘）。如果你的系统盘也是 sd 开头，注意别把真实系统盘放进来。find_multipaths yes让系统只对满足条件的盘启动多路径，省得误伤。

配好后重启 multipath 服务：

sudo systemctl restart multipathd sudo multipath -ll

multipath -ll会列出多路径设备，比如：

mpatha (360014050... ) dm-0 IET,VIRTUAL-DISK size=800G features='0' hwhandler='0' wp=rw `-+- policy='round-robin 0' prio=0 status=active |- 1:0:0:1 sdb 8:16 active ready running `- 2:0:0:1 sde 8:64 active ready running

看到两个路径都是 active 状态，说明多路径已就位。此时你挂载/dev/mapper/mpatha而不是/dev/sdb1，路径失效时 IO 自动切换，应用无感知。

这里有个 SQL 查错了会导致看不到多路径设备——我已经踩过一次，所以提醒：multipath -ll没输出不一定代表有问题，先检查 iSCSI 两个 session 是否都活着，再检查 WWID 是否被黑名单挡了。多路径的 WWID（全球唯一标识符）可以在/sys/block/sdb/device/wwid查看，multipath.conf 里也可以针对 WWID 单独放行。

4.3 CHAP 双向认证与网络安全加固

前文提到给 ACL 加了 CHAP，这里多说几句为什么建议加。iSCSI 默认是明文的，Target 的 3260 端口暴露在网络里，任何能访问到该端口的人，只要知道 IQN 和 ACL 规则就能尝试连接。虽然 IQN 本身有一定保密性，但生产环境（尤其是存储和业务网没分离的网络）还是建议启用 CHAP。

我配置的是双向认证（mutual CHAP），也就是客户端也要验证服务端身份，防止伪 Target。配置时要注意几个细节：

• 单向 CHAP 密码要求 12 到 16 位字符，双向 CHAP 要求服务端用户密码和客户端用户密码必须不同，否则会报错。
• 客户端 open-iscsi 配置 CHAP 是通过--op update写到 node 里的，不是只登录时临时指定。具体：

sudo iscsiadm -m node -T iqn.2025-01.com.example:storage1 -p 192.168.10.10:3260 --op update -n node.session.auth.authmethod -v CHAP sudo iscsiadm -m node -T iqn.2025-01.com.example:storage1 -p 192.168.10.10:3260 --op update -n node.session.auth.username -v storageuser sudo iscsiadm -m node -T iqn.2025-01.com.example:storage1 -p 192.168.10.10:3260 --op update -n node.session.auth.password -v Str0ngPassw0rd!

改完以后重新登录才生效。另外，如果你要配双向 CHAP，还需要设置：

sudo iscsiadm -m node -T iqn.2025-01.com.example:storage1 -p 192.168.10.10:3260 --op update -n node.session.auth.username_in -v mutual_user sudo iscsiadm -m node -T iqn.2025-01.com.example:storage1 -p 192.168.10.10:3260 --op update -n node.session.auth.password_in -v MutualPassw0rd!

两个方向的密码一定不要设成一样的，我第一次偷懒设成同一个密码，结果客户端登录一直报 CHAP authentication failure，排查了半小时才想起这个细节。不同厂商的 initiator 对 CHAP 兼容性也有细微差别，Windows 发起程序对双向 CHAP 支持得不太好，如果你的客户端是 Windows，建议先用单向 CHAP 确认通了再说。

如果你用的是测试环境且网络完全隔离，CHAP 可以先不开，但正式环境，务必开启。我在生产里见过一次因为 iSCSI 无认证导致虚拟机磁盘被误挂到别人机器上的事故——那个调试现场简直惨烈。

4.4 服务端快照与薄卷管理

这是我后面临时加的，但发现不少朋友不知道 iSCSI 服务端还能做这些操作，所以一并写到这。LIO 支持的块后端里有一个backstores/user、一个backstores/ramdisk，后者其实是模拟内存盘，速度奇快但对掉电零容忍；还有一个backstores/fileio是用文件模拟块设备，支持稀疏文件和快照标志。我的场景是虚拟化存储，还是老老实实 block 直通，没上 fileio。好处是直通块设备性能最接近物理盘；缺点是如果后端是 LVM，需要 LVM 层自行处理快照。

如果你在服务端用 LVM 管理磁盘，可以直接在 LVM 层做快照：

sudo lvcreate -L 20G -s -n snap_storage1 /dev/vg_data/storage1

这样对 iSCSI LUN 做卷级快照，比在客户端上用文件系统快照快得多，而且不占全量空间（COW 方式）。不过要注意，LVM 快照在长时间运行后容易满，满了会自动失效，这属于运维常识，用的时候心里有数。

严格来说，iSCSI 层本身不提供快照功能，需要依赖后端存储（LVM、ZFS、硬件阵列）来实现。但通过 targetcli 暴露的是块设备，这些快照做完之后客户端看到的仍然是同一个 LUN，只是数据版本回滚了。所以选后端存储时留个心眼，别全压在一颗裸盘上没有冗余，万一盘挂了，客户端那边所有依赖存储的服务都会跟着报错。

5. 常见问题与排查指南：从挂不上到性能差

5.1 发现 Target 失败与登录失败的根因

iSCSI 排错本质上就两条线：目标的发现（Discovery）和目标登录（Login）。发现失败时，先别急着怀疑配置，按这个顺序查：

1. 网络连通性：ping 192.168.10.10，不通就查网线、VLAN、路由，不废话。
2. TCP 端口可访问性：用nc -vz 192.168.10.10 3260或telnet 192.168.10.10 3260测试。如果 nc 报Connection refused，大概率服务端 targetcli 服务没起来或 portal 没创建成功，回到服务端targetcli用ls确认 portal 存在。
3. 防火墙：ufw/firewalld 有没有放开 3260。测试阶段可以直接临时关防火墙验证（生产环境就不要这么干了）。
4. ACL 缺失：如果discovery能看到 Target，但 login 时报No connection could be made because the target is not accepting requests或Authentication failure，多半是 ACL 里没加客户端 IQN，或者 CHAP 密码不对。去服务端targetcli /iscsi/.../tpg1/acls看看客户端 IQN 在不在。
5. IQN 拼写错误：客户端和服务端的 IQN 是全匹配的，大小写、冒号都要一致。我一次踩坑就是复制粘贴时带上了一个空格。

登录失败后一定要看日志。服务端查journalctl -u targetcli，客户端查dmesg | grep iscsi和/var/log/messages，95% 的报错信息都能在里面找到具体原因。有些错误信息虽然人话读不懂，但对照iscsiadm的退出码（比如Exit Code: 8表示连接失败）能缩小范围。

5.2 挂载之后性能差：先分清楚是哪一跳慢

有段时间我挂载完成后测速，只有 300MB/s 左右，而两块网卡是万兆，明显不对。排查思路值得分享：先用 iperf 测纯 TCP 带宽，如果 iperf 只有 1GB/s，那就是链路或网卡问题，与 iSCSI 无关。如果 iperf 正常但 dd 读盘慢，就要看是不是磁盘后端或文件系统的问题。

我用dd粗测有很多误导性，后来改成fio才靠谱：

sudo fio --name=test --bs=4k --size=1G --numjobs=4 --rw=randrw --runtime=30 --group_reporting

fio 测的是真实 IO 负载模式，比 dd 更接近数据库/虚拟机的实际使用方式。测完发现瓶颈在 MTU：我服务端设了 9000 但客户端忘了跟着改，导致大包不通，iSCSI 不得不靠 TCP 分段回退，性能直线下降。改完两端 MTU 后重新测，带宽直接翻倍。

另一个常见性能坑是单队列多路径未配置。如果你网卡有多条队列但 iSCSI 只建了一个 session，单路带宽上不去。可以用 ethtool 查看网卡队列数：

sudo ethtool -l eth0 sudo ethtool -L eth0 combined 4 # 调整队列数

但在 iSCSI 层，更直接的解法就是前面说的多路径配置。IO 分散到多个 session 后，带宽和冗余都上来了。

5.3 重启后 Target 或 LUN 消失

这个问题在新手手里发生率极高，核心原因是没保存配置。targetcli 临时配置和保存配置是两回事，必须执行saveconfig，配置才会持久化到/etc/target/saveconfig.json。如果重启后客户端能发现 Target 但登录失败，去服务端跑targetcli ls，看 ACL 和 LUN 是不是都在。如果 Target 都没了，确认一下 targetcli 服务有没有开机自启：

systemctl list-unit-files | grep target # target.service 应该是 enabled

另外，注意不要把块设备名写死在配置里。比如你把/dev/sdb配成 LUN，下次重启后系统盘顺序可能变化（多了 USB 盘、换了 SATA 口），/dev/sdb可能变成别的盘。稳妥做法是：在/etc/target/saveconfig.json里看backstores/block引用是不是用的设备路径或 WWID。LIO 在某些内核版本上支持用/dev/disk/by-uuid/...或/dev/disk/by-path/...来定址，我就是靠这个解决过一次盘符漂移问题，强烈建议生产配置里不要直接写裸sd设备名。

5.4 CHAP 认证失败的特殊场景：多方客户端密钥不同

如果你有多个客户端（类如 Linux、Windows、VMware），它们对 CHAP 的实现各有怪癖。比如 Linux 的 open-iscsi 对密码里的特殊字符（!、@、#）要求转义，实际写进 node 配置时要用引号包住。而 Windows 发起程序有时会在密码末尾自动补空格，导致两边不一致。

遇到 CHAP 认证失败，排错技巧是：先把服务端某个客户端 ACL 的 CHAP 临时关掉，确认网络、ACL、认证路径哪一环有问题；或者用 open-iscsi 的-d 8调试选项打出完整认证流程：

sudo iscsiadm -m node -T iqn.2025-01.com.example:storage1 -p 192.168.10.10:3260 --login -d 8

-d 8的调试日志里能看到 CHAP challenge/response 过程，密码错误会直接显示明文吗？不会，但你能看到是哪一步失败，比如CHAP response received后verification failed，就说明密码确实错了，好好比对两边的密码。

5.5 常见问题速查表

6. 实操中的几个独家心得与建议

6.1 保存配置与命名规范是稳定性的基础

这次配置过程中，我来回折腾了三四次，最深的两条体会是命名和持久化，前面分别讲过，这里串起来说一下。iSCSI 里 IQN、ACL、LUN、Portal 这些概念本身不难，但配置一多，如果命名没有规则，排查时人很容易晕。我自己的习惯是：

• Target IQN 用iqn.年份-月份.域名反写:业务名-环境名
• 客户端 IQN 用iqn.年份-月份.域名反写:hostname
• LUN 编号按业务从 0 开始，分配表维护一份在 wiki 或 README 里，别让它烂在脑子里

配合saveconfig一定要定时执行，或者干脆写完配置立刻保存。我吃过一次大亏：配完测试环境没保存就去忙别的，第二天发现 Target 没了，一度怀疑存储盘坏了，实际上就是忘了保存。那种焦虑感，我不想再体验第二次。

6.2 安全加固别嫌麻烦：CHAP 和网络隔离都建议做

如果你把 CHAP 当成“可选项”，我劝你重新想想。测试环境网络自娱自乐当然无所谓，但生产环境 iSCSI 流量里跑的是你的数据库、虚拟机、关键业务数据，明文传输意味着抓包就能看到块内容。虽然不是像 HTTP 明文那样直接看到密码，但泄露的是完整磁盘数据，比泄露单个密码严重多了。至少加单向 CHAP，让交互过程带认证。有条件就把存储流量隔离到独立 VLAN 或物理网卡，再用防火墙规则限制只有指定来源 IP 能访问 3260 端口。

有一次我给客户排查问题，发现他们的 iSCSI Target 直接暴露在 0.0.0.0 的 3260 端口上，且完全无认证。我试着用一台新机器去iscsiadm -m discovery，竟然直接发现了 Target。这个隐患细思极恐，相当于存储裸奔在网络里。如果你的环境已经这么干了，建议尽快在 portal 配置里指定存储网卡 IP，并开启 CHAP——做这个改动可能需要短暂断开连接，但比起数据泄露的后果，这点停机时间完全值得。

6.3 多路径的“可用”不等于“会切换”：多路验证才靠谱

配置好多路径以后，很多人看一眼multipath -ll输出有两条 active 就放心了。但生产环境真正要验证的是断掉一条路径后 IO 是否无缝切换。我建议在非业务高峰期做一次破坏性测试：拔掉一根网线或 shutdown 一个服务端网口，然后持续写数据看有没有报错。如果配置正确，写入不会中断，只是路径状态变化，IO 自动走剩下那条。如果发现问题，多半是 multipath 配置里没有设置好path_checker或failback策略。

我在测试时用了path_checker tur（SCSI 测试单元就绪命令）和failback immediate，切换效果最好。配置示例：

defaults { path_checker tur failback immediate user_friendly_names yes find_multipaths yes }

重启 multipathd 之后，再断链测试。切到备用路径后业务无感，这个验证做完你才能真正睡得安心。

6.4 一定要做好备份：iSCSI 本身不提供数据冗余

最后想特别强调一个很多人都存在的误解：iSCSI 只是一个传输协议，它不负责数据冗余和备份。你从 iSCSI 挂载的盘和本地盘一样会发生故障、误删除、损坏。我见过有人以为存储在“服务器上”就是安全的，结果服务器硬盘坏了，数据没备份，后果全部承担。iSCSI 给你的是“远程的裸块设备”，底层还是物理硬盘，依然遵循“数据可靠性由 RAID/副本/备份决定”的铁律。

我的习惯是，每个重要的 LUN 都要有对应后端存储的快照策略（LVM/ZFS/硬件阵列级别），并且定期验证快照可恢复性。另外，如果虚拟化平台用了 iSCSI 存储池，快照和克隆功能逻辑上独立于 iSCSI，但你把虚拟机磁盘放在 iSCSI 上，虚拟化层的快照同样要定期测试恢复。千万别把所有鸡蛋放一个篮子里，就算那个篮子看起来再高级。

这次 iSCSI 的配置过程整体很顺利，但中途遇到的坑不少，尤其是 CHAP 密码规则和saveconfig这两个细节，应该坑了不少人。希望这篇指南能帮你少走弯路，让存储挂载这件事变得像搭积木一样清晰。如果配的时候遇到什么奇怪的问题，欢迎在评论区留下现象和报错信息，我看到会尽量回复。