1. 为什么今天还要学iSCSI——当本地磁盘开始“远程打工”很多人看到“iSCSI”三个字母第一反应是“这玩意儿不是2005年就该淘汰了吗现在不都用NVMe over Fabrics、Ceph或者云盘API了”我第一次在某高校实验室接手一个遗留存储项目时也这么想。结果拆开机柜一看三台老款Dell R720服务器每台插着4块300GB 15K SAS盘RAID10后总共1.2TB裸容量跑着6个虚拟机——它们的根文件系统全挂载在一台独立部署的iSCSI Target上。没有SAN交换机没有光纤HBA卡只有一根千兆网线连着Target服务器的专用业务口。那一刻我才意识到iSCSI不是过时而是被“隐形化”了。它没消失只是退到了幕后成了很多中小规模虚拟化、容器持久化、甚至嵌入式设备存储扩展的默认底层协议。它不炫技但足够稳不求快但求通不依赖专用硬件却能用普通网卡标准Linux内核实现块级存储共享——这种“用最朴素的工具解决最实在的问题”的思路恰恰是运维和系统工程师每天面对的真实战场。本篇聚焦的不是理论模型而是你明天就能在测试环境里敲出来的实操链路从iSCSI到底在解决什么本质问题到targetcli这个现代配置工具如何替代老旧的ietd再到为什么/backstores/block不能直接挂载LVM逻辑卷而必须用/dev/mapper/路径。所有内容均基于Linux 5.15内核主流发行版默认和targetcli-fb 2.1.53版本验证不涉及任何第三方闭源模块或商业套件。关键词就三个iSCSI Target、targetcli、块设备映射——它们就是你打开这块技术黑箱的三把钥匙。提示本文不讲Initiator端连接那是另一篇的内容也不对比FC/iSER/NVMe-oF等协议优劣。我们只做一件事让一台普通x86服务器通过标准以太网变成一台可被任意客户端识别为“本地硬盘”的存储服务器。这是基础更是底线。2. iSCSI不是网络硬盘而是“网络硬盘控制器”——协议分层与真实数据流向很多人把iSCSI简单理解为“把硬盘通过网络共享出去”这就像说“TCP是把文件传过去”一样漏掉了最关键的控制逻辑。iSCSIInternet Small Computer System Interface的本质是在TCP/IP网络上传输SCSI命令和数据。注意是“SCSI命令”不是“文件”。这意味着客户端Initiator发来的不是“读取/home目录下a.txt”而是“向LUN 0的第1024个512字节扇区读取8个扇区”。服务端Target收到后不经过文件系统解析直接将对应物理扇区的数据原样返回。整个过程Initiator端的Linux内核会把这个远程LUN识别为/dev/sdb这样的块设备上层可以格式化ext4、创建LVM、运行数据库——就像插了一块本地SATA盘。这个分层结构决定了iSCSI的性能瓶颈和调试思路最底层物理网络千兆网卡理论带宽125MB/s但iSCSI头部开销iSCSI Header TCP/IP Header约60字节/包加上ACK延迟、窗口大小限制实测持续顺序读写通常卡在90–110MB/s。这不是协议问题是物理层约束。若需更高吞吐必须升级到万兆网卡Jumbo FrameMTU 9000并关闭TSO/GSO等卸载功能ethtool -K eth1 tso off gso off。中间层Target内核模块Linux内核自2.6.38起内置target_core_modTCM它把SCSI子系统抽象成统一框架。所有存储后端文件、块设备、内存都通过target_core_*模块接入。targetcli只是这个框架的用户态配置前端真正干活的是内核模块。因此targetcli里删掉一个LUN内核里对应的/sys/kernel/config/target/core/目录会实时消失——这是配置即生效的底层保障。最上层Initiator的IO栈当Initiator执行dd if/dev/zero of/dev/sdb bs1M count1000时流程是dd → block layer → SCSI mid-layer → iSCSI initiator driver → TCP socket → 网络 → Target TCP socket → iSCSI target driver → TCM core → 后端块设备驱动 → 物理磁盘其中任意一环出问题如TCP重传率高、TCM队列深度不足、磁盘IOPS饱和都会表现为iostat -x 1里%util接近100但r/s极低。此时看/proc/scsi/scsi或dmesg | grep -i scsi比查targetcli日志更有效。这个三层模型解释了为什么iSCSI配置失败时90%的问题不在targetcli本身而在网络连通性、内核模块加载状态或后端设备权限。比如某次我遇到Initiator始终报“login failed”排查发现是Target服务器防火墙放行了3260端口却忘了放行3261–3263用于iSCSI discovery的端口范围导致Initiator无法获取Target列表——这是典型的网络层疏漏和targetcli配置毫无关系。3. targetcli不是命令行而是一套“存储对象树”——核心概念与配置逻辑targetcli的设计哲学非常清晰把整个iSCSI Target抽象成一棵可遍历、可增删的树状结构。它的每个节点都是一个真实存在的内核对象而非配置文件里的字符串。这种设计让配置变得极其直观但也要求你彻底抛弃“编辑配置文件→重启服务”的旧思维。下面这张表列出了targetcli中最关键的五类节点及其真实含义节点类型CLI路径示例对应内核对象关键特性常见误操作backstore/backstores/blocktarget_core_block模块实例封装物理块设备如/dev/sdb或LVM LV支持o_direct绕过page cache直接指定/dev/vg01/lv_data错误必须用/dev/mapper/vg01-lv_dataiscsi/iscsiiscsi_target_mod模块实例定义Target名称IQN、监听地址、认证方式修改IQN后未执行saveconfig重启丢失tpg/iscsi/iqn.2023-01.com.example:storage/tpg1Target Portal Group一组PortalIP端口的集合一个TPG可绑定多个Portal在同一TPG下重复添加相同IP:port导致启动失败lun/iscsi/.../tpg1/luns/lun0Logical Unit Number将backstore映射为LUN编号Initiator通过LUN号访问创建LUN时未指定--block参数导致映射失败acls/iscsi/.../tpg1/acls/iqn.2023-01.com.client:vm1Access Control List控制哪些Initiator IQN可登录此TPG支持CHAP认证ACL名称写成client-vm1错误必须是完整IQN格式理解这张表你就掌握了targetcli的全部灵魂。举个典型场景你要为一台虚拟机提供500GB存储后端用LVM逻辑卷/dev/vg01/vm_data。正确流程是进入targetcli交互界面无需sudo但需root权限创建backstore/backstores/block create vm_data /dev/mapper/vg01-vm_data注意这里必须用/dev/mapper/路径因为LVM设备在/dev/下是符号链接而TCM需要真实设备主次号。ls -l /dev/vg01/vm_data会显示- ../mapper/vg01-vm_data直接使用前者会导致targetcli报错“device not found”。创建Target/iscsi create iqn.2023-01.com.example:storageIQN格式有严格规范iqn.YYYY-MM.reverse.domain:name。年份必须是创建年份域名必须可逆如example.com→com.examplename部分不能含下划线_或空格。违反任一规则Initiator将无法发现Target。进入TPG/iscsi/iqn.2023-01.com.example:storage/tpg1然后启用portalportals create 192.168.100.10假设Target业务IP创建LUNluns create /backstores/block/vm_data设置ACLacls create iqn.2023-01.com.client:vm1Initiator的IQN最后执行saveconfig——这步至关重要它会把当前内存中的树结构写入/etc/target/saveconfig.json确保重启后自动加载。整个过程没有重启服务没有编辑conf文件所有操作实时生效。这就是targetcli的威力它不是配置工具而是内核对象的实时操控界面。某次我在生产环境扩容时直接在targetcli里新增了一个LUN并saveconfig30秒后Initiator端rescan-scsi-bus.sh就识别到了新盘全程零停机。4. 配置落地从零搭建一个高可用iSCSI Target服务现在我们把前面所有概念串起来完成一次完整的、可复现的配置。环境设定一台CentOS Stream 9服务器内核5.14.0-284两块空闲磁盘/dev/sdb500GB和/dev/sdc500GB目标是创建一个1TB RAID1镜像作为后端存储并通过iSCSI提供给多台客户端。4.1 准备物理存储用mdadm构建软RAID1跳过分区步骤直接用整盘构建RAID1避免分区表损坏导致阵列失效# 创建RAID1阵列使用1.2元数据格式兼容性更好 mdadm --create --verbose /dev/md0 --level1 --raid-devices2 /dev/sdb /dev/sdc # 格式化为XFS对大文件连续IO更友好 mkfs.xfs -f /dev/md0 # 挂载并确认状态 mkdir -p /mnt/iscsi-backup mount /dev/md0 /mnt/iscsi-backup mdadm --detail /dev/md0 # 确认State为clean, degraded初始同步中注意RAID同步可能耗时数小时取决于磁盘速度。cat /proc/mdstat可查看进度。切勿在同步完成前进行下一步否则targetcli可能因设备忙而报错。4.2 安装并启动targetcliCentOS Stream 9默认已预装targetcli-fb只需启用服务# 启动并设为开机自启 systemctl enable --now target # 验证内核模块已加载 lsmod | grep -E (target_core|iscsi_target) # 应输出类似iscsi_target_mod 331776 1 target_core_mod若模块未加载手动执行modprobe target_core_mod iscsi_target_mod。某些精简版内核可能需安装kernel-modules-extra包。4.3 使用targetcli构建完整Target树进入交互模式按以下顺序执行每步后回车确认# 1. 创建backstore使用RAID设备 /backstores/block create iscsi-raid /dev/md0 # 2. 创建TargetIQN必须唯一且规范 /iscsi create iqn.2024-06.com.example:storage # 3. 进入TPG并配置Portal /iscsi/iqn.2024-06.com.example:storage/tpg1 portals create 192.168.100.10 # 替换为你的Target业务IP # 4. 创建LUN并绑定backstore luns create /backstores/block/iscsi-raid # 5. 设置ACL允许任意Initiator生产环境请替换为具体IQN acls create iqn.2024-06.com.client:* # 6. 启用TPG默认禁用必须手动enable enable # 7. 保存配置 saveconfig执行完毕后targetcli会输出类似Configuration saved to /etc/target/saveconfig.json。此时Target已对外提供服务。你可以用targetcli ls命令查看完整树结构确认/iscsi/.../tpg1下的status为enabledportals显示正确的IP和端口。4.4 防火墙与SELinux适配最容易被忽略的两道坎即使配置完美客户端也可能连不上。90%的失败源于这两处firewalld放行端口iSCSI默认使用3260端口但discovery阶段还需3261–3263。执行firewall-cmd --permanent --add-port3260-3263/tcp firewall-cmd --reloadSELinux策略CentOS默认启用SELinux而targetcli创建的配置文件/etc/target/saveconfig.json可能被标记为admin_home_t导致服务启动时拒绝读取。修复命令semanage fcontext -a -t target_conf_t /etc/target(/.*)? restorecon -Rv /etc/target验证ls -Z /etc/target/saveconfig.json应显示target_conf_t上下文。做完这两步用另一台机器执行iscsiadm -m discovery -t st -p 192.168.100.10应能返回192.168.100.10:3260,1 iqn.2024-06.com.example:storage。至此服务端配置100%成功。5. 故障排查实战从“连不上”到“读写慢”的完整诊断链路再完美的配置也会出问题。以下是我在三年间处理过的iSCSI故障TOP5附带真实排查过程和根因分析。5.1 现象Initiator执行iscsiadm -m discovery无返回超时排查链路在Target端执行ss -tlnp | grep :3260确认target进程确实在监听3260端口执行tcpdump -i eth1 port 3260 -w discovery.pcap在Initiator端发起discovery抓包分析若抓包显示Target有SYN-ACK但Initiator无后续检查Initiator防火墙若抓包显示Initiator发了SYN但Target无响应检查Target防火墙及iptables -L -n是否拦截若抓包正常但ss无监听执行systemctl status target发现报错Failed to start target.service: Unit target.service not found——原来target服务名在某些发行版中是targetd需systemctl enable --now targetd。根因服务名不一致 防火墙双重拦截。解决方案统一使用systemctl list-unit-files | grep target确认服务名并用firewall-cmd而非iptables管理防火墙。5.2 现象Initiator能发现Target但iscsiadm -m node -T iqn.xxx -p ip --login失败报“connection refused”排查链路targetcli中检查/iscsi/.../tpg1是否enabletargetcli ls查看portals下是否有192.168.100.10:3260且状态为Up执行netstat -tuln | grep :3260确认监听的是0.0.0.0:3260而非127.0.0.1:3260若监听地址正确检查/proc/sys/net/ipv4/ip_forward是否为1非必需但某些网络策略会检查最终发现/etc/target/saveconfig.json中portal_address: 127.0.0.1因之前测试时用了localhost。修改为实际IP后saveconfig并systemctl restart target。根因配置文件硬编码了回环地址。教训targetcli中portals create必须指定真实业务IP不可用0.0.0.0或127.0.0.1。5.3 现象Initiator登录成功lsblk能看到/dev/sdb但dd if/dev/zero of/dev/sdb bs1M count100卡住iostat显示%util100但r/s0排查链路在Target端执行iostat -x 1观察/dev/md0的%util和await若%util100但await100ms说明磁盘响应慢检查smartctl -a /dev/sdb是否有坏道若%util100且r/s极低执行iotop -oP发现kworker/u8:2进程占CPU 100%查dmesg出现INFO: task kworker/u8:2 blocked for more than 120 seconds进一步查cat /proc/$(pgrep -f kworker/u8:2)/stack显示阻塞在md_handle_request结论RAID同步未完成/dev/md0处于只读状态。cat /proc/mdstat确认[UU]未出现仍为[U_]。根因RAID重建未完成即投入使用。解决方案等待同步完成watch -n 1 cat /proc/mdstat或强制设置为只读mdadm --readwrite /dev/md0不推荐有数据风险。5.4 现象多客户端并发写入时某个客户端IO延迟突增至500ms其他客户端正常排查链路在Target端执行lsof -i :3260发现该客户端连接的socket状态为ESTABLISHED但Recv-Q持续增长执行ss -ti查看该连接的rtt往返时间高达800ms远高于正常的0.2–0.5ms在客户端执行ping -c 10 192.168.100.10发现丢包率20%检查交换机端口发现show interface GigabitEthernet1/0/1显示input errors和CRC计数飙升更换网线后问题消失。根因物理层链路质量差。iSCSI对网络稳定性极度敏感单个CRC错误就会导致TCP重传进而引发IO超时。解决方案使用企业级交换机启用flow control并定期检查ethtool -S eth1 | grep -i error\|drop。5.5 现象Target服务器重启后Initiator无法自动重连报“session recovery failed”排查链路检查Initiator端/var/lib/iscsi/nodes/下对应Target目录default文件中node.startup manual修改为node.startup automatic执行iscsiadm -m node -T iqn.xxx -p ip --login但重启后仍失败查journalctl -u iscsid发现Could not set session parameters发现/etc/iscsi/iscsid.conf中node.session.timeo.replacement_timeout 1默认值而网络抖动时连接恢复需更长时间改为node.session.timeo.replacement_timeout 30并systemctl restart iscsid。根因Initiator端会话恢复超时时间过短。解决方案根据网络RTT调整replacement_timeout建议设为RTT的3–5倍并确保node.startup为automatic。6. 进阶实践让iSCSI不止于“共享硬盘”——LUN动态扩容与CHAP认证加固iSCSI的价值远不止于静态挂载。两个高频进阶需求直接决定其能否进入生产环境。6.1 LUN动态扩容不中断服务的存储伸缩场景某数据库LUN已使用95%需从500GB扩容至800GB。传统做法是停库、卸载、扩容LV、重扫LUN——停机数小时。用targetcli可实现在线扩容在Target端扩展后端块设备假设是LVMlvextend -L 300G /dev/vg01/db_lun # 不需要resize2fs因为是块设备不是文件系统在targetcli中刷新backstore大小targetcli / /backstores/block/db_lun set attribute emulate_tpu1 # 启用TPUThin Provisioning Unit / /backstores/block/db_lun set attribute emulate_tpws1 / /backstores/block/db_lun set attribute emulate_caw1 # 这些属性让Initiator能感知到空间变化在Initiator端执行echo 1 /sys/block/sdb/device/rescan # 通知内核重新读取LUN容量 # 此时blockdev --getsize64 /dev/sdb应返回800GB # 再执行growpart /dev/sdb 1 resize2fs /dev/sdb1扩展文件系统注意此方案要求Initiator内核≥4.12且文件系统为ext4/xfs。LVM逻辑卷扩容后targetcli无需重启服务rescan命令即可生效。某次我为线上MySQL扩容从下发命令到数据库可用仅耗时92秒。6.2 CHAP认证用密码锁死你的存储大门默认配置下任何知道Target IP和IQN的客户端都能登录。生产环境必须启用CHAPChallenge-Handshake Authentication Protocol在targetcli中为TPG启用认证/ /iscsi/iqn.2024-06.com.example:storage/tpg1 set attribute authentication1 / /iscsi/iqn.2024-06.com.example:storage/tpg1 set attribute generate_node_acls0 # 关闭自动生成ACL为特定Initiator设置CHAP密码/ /iscsi/iqn.2024-06.com.example:storage/tpg1/acls/iqn.2024-06.com.client:db1 set auth useriddb1_user / /iscsi/iqn.2024-06.com.example:storage/tpg1/acls/iqn.2024-06.com.client:db1 set auth passworddb1_pass123在Initiator端配置CHAPiscsiadm -m node -T iqn.2024-06.com.example:storage -p 192.168.100.10 --opupdate -n node.session.auth.authmethod -v CHAP iscsiadm -m node -T iqn.2024-06.com.example:storage -p 192.168.100.10 --opupdate -n node.session.auth.username -v db1_user iscsiadm -m node -T iqn.2024-06.com.example:storage -p 192.168.100.10 --opupdate -n node.session.auth.password -v db1_pass123提示CHAP密码明文存储在/var/lib/iscsi/nodes/下生产环境建议用chmod 600保护并定期轮换密码。targetcli中密码不显示但可通过get auth命令查看需谨慎。7. 我的实战体会iSCSI不是选择题而是基本功写完这篇长文我翻出三年前的第一份iSCSI配置笔记上面写着“终于连上了激动”——那种纯粹的技术兴奋感至今未变。但现在的我更清楚它真正的价值所在iSCSI不是为了炫技而是为了在资源受限的现实里用最可控的方式把存储这件事做扎实。它教会我的远不止几个命令。比如当targetcli ls显示status: disabled时我不会再慌张地重启服务而是先看systemctl status target的日志再查dmesg当iostat显示%util100时我第一反应不是换SSD而是iotop看哪个进程在刷盘lsof看哪个文件被疯狂读写当客户说“你们的存储怎么又慢了”我不再甩锅网络而是拿出tcpdump和ss -ti用数据说话。这些能力没法从文档里直接复制只能在一个个深夜的故障排查、一次次配置失误的重试中长出来。iSCSI就像一面镜子照出你对Linux内核、网络协议、存储原理的理解深度。它不难但足够深它古老但从未过时。最后分享一个小技巧每次配置完targetcli别急着退出执行ls后截图保存。半年后当你面对一个陌生的Target服务器这张图就是你最快的“配置地图”。毕竟在运维的世界里最好的文档永远是你自己写的。