1. 为什么在 Ubuntu 20.04 Server 上认真装一次 iSCSI比你想象中更重要iSCSI 这三个字母对很多刚接触企业级存储或虚拟化运维的朋友来说可能只是文档里一个带英文缩写的协议名词。但在我过去八年维护过三十多套生产环境的服务器集群的经历里iSCSI 不是“可有可无的附加功能”而是真正把本地磁盘、NAS、SAN 和虚拟机三者串起来的那根“数据动脉”。Ubuntu 20.04 Server 作为长期支持LTS版本稳定性和内核兼容性极佳但它默认不启用 iSCSI 相关服务——这意味着你不能靠apt install之后就直接挂载一块远程 LUN它需要你理解底层连接机制、认证逻辑、路径冗余策略和故障恢复行为。这不是一个“点几下就完成”的图形化安装而是一次对 Linux 存储栈的实操体检。我见过太多人卡在第一步iscsiadm -m discovery -t sendtargets -p 192.168.1.100执行后返回空结果反复检查 IP 却忽略防火墙规则里缺了3260/tcp端口放行也见过有人成功登录 target 后lsblk却看不到新磁盘最后发现是 udev 规则没触发得手动udevadm trigger --subsystem-matchblock更常见的是在 VMware 或 Proxmox 上配置多路径时明明启用了multipath-tools却因/etc/multipath.conf里wwid匹配规则写错导致两条路径始终只走一条完全浪费了高可用设计。这些都不是 bug而是 iSCSI 协议本身的设计哲学决定的它把控制面login/discovery和数据面SCSI 命令传输严格分离把认证、重连、超时、路径选择全部交由客户端自主决策——这给了你极致的可控性也意味着你必须亲手填满每一个逻辑缺口。所以这篇内容不是“Ubuntu 20.04 安装 iSCSI 的 5 分钟教程”而是带你从零开始用真实生产环境的标准把 iSCSI 客户端完整搭起来包括服务初始化、安全认证配置、自动重连机制、设备持久化挂载、多路径容灾部署以及最关键的——如何验证每一步是否真正生效。它适合正在搭建私有云存储后端的 DevOps 工程师、需要对接 NAS 存储的数据库管理员、或是准备用 iSCSI 启动无盘系统的系统集成商。如果你只是想临时挂个 ISO 镜像测试那本文可能“过度设计”但如果你的 PostgreSQL 数据库正跑在这块远程磁盘上或者你的 KVM 虚拟机磁盘文件存放在 iSCSI target 上那么下面每一个参数、每一行命令、每一个检查点都直接关系到业务连续性。2. 整体架构设计与方案选型逻辑为什么不用 initiator-utils而坚持用 open-iscsi很多人搜索“Ubuntu 20.04 iSCSI 安装”第一反应是sudo apt install iscsi-initiator-utils。这个包名确实存在但它早已是历史遗留符号。自 Ubuntu 18.04 起官方仓库已将 iSCSI initiator 统一归入open-iscsi包而iscsi-initiator-utils只是它的兼容性别名实际安装的仍是同一套二进制。但真正值得深究的是为什么我们不选其他方案比如用tgt或lio自建 target服务端或者用iscsitarget答案很现实Ubuntu 20.04 Server 的定位是稳定可靠的客户端角色而非存储服务提供者。它的核心任务是作为计算节点可靠地接入外部专业存储设备如 TrueNAS、Synology、Dell EMC Unity、NetApp FAS而不是自己充当 target 去承担 I/O 压力和数据一致性风险。open-iscsi 是 Linux 内核原生支持的用户态 initiator 实现由 Linux-iSCSI 社区长期维护深度集成于 systemd、udev 和 multipath 框架。它不像某些第三方工具那样绕过内核 SCSI 层而是通过libiscsi库与内核scsi_transport_iscsi模块协同工作确保所有 SCSI 命令INQUIRY、READ CAPACITY、MODE SENSE、READ/WRITE都能被正确封装、序列化并送达 target。更重要的是它原生支持 CHAPChallenge-Handshake Authentication Protocol双向认证、动态发现SendTargets、自动重连node.startup automatic、连接超时node.conn[0].timeo.*系列参数等企业级特性。而像iscsitarget这类老式项目早在 2017 年就停止维护其内核模块与 Ubuntu 20.04 的 5.4 内核存在兼容性问题modprobe iscsitarget会直接报错Operation not permitted。另一个常被忽略的关键点是 multipath 支持。现代企业存储几乎都提供双控制器或多路径访问能力例如 TrueNAS 的 HA 集群、Dell SC 系列的 dual-active controller。open-iscsi 与multipath-tools的配合是经过 Red Hat、SUSE、Canonical 多年联合测试的黄金组合。它能自动识别同一 LUN 的多个路径不同 IP 端口组合并基于wwidWorld Wide Identifier生成唯一的设备别名如/dev/mapper/36001405a1b2c3d4e5f67890123456789彻底规避/dev/sdb在重启后变成/dev/sdc的设备名漂移问题。而如果强行用iscsiadm手动管理多路径不仅配置复杂且无法利用multipathd的实时路径健康检测和故障切换能力——当一条链路中断时multipathd能在 200ms 内完成切换而纯iscsiadm方案可能需要等待 TCP 重传超时默认 30 秒这对数据库事务是灾难性的。因此我们的方案非常明确仅安装open-iscsi禁用所有非必要服务专注配置 initiator 客户端行为与标准 Linux 存储栈udev, multipath, fstab无缝集成。不引入额外 daemon不修改内核模块加载顺序不覆盖系统默认 udev 规则——所有改动都限定在/etc/iscsi/和/etc/multipath.conf两个配置目录内确保升级 Ubuntu 时配置零冲突。2.1 服务初始化与 systemd 单元深度解析Ubuntu 20.04 默认安装open-iscsi后并不会自动启动iscsid服务。这是有意为之的设计initiator 必须显式启动避免在未配置 target 的情况下盲目尝试连接。iscsid是核心守护进程负责管理所有 iSCSI 会话session、处理 CHAP 认证、响应 target 的 NOP 请求keep-alive、执行路径故障检测。它不是一个“后台常驻”服务而是一个按需激活的 socket-activated daemon。我们先确认当前状态systemctl status iscsid # 输出通常为 inactive (dead)因为尚未配置任何 node启动并设为开机自启sudo systemctl enable iscsid sudo systemctl start iscsid但关键不在start而在理解iscsid.socket的作用。查看其定义systemctl cat iscsid.socket你会看到它监听/var/run/iscsi.sock这个 Unix domain socket。所有iscsiadm命令如iscsiadm -m discovery都通过这个 socket 与iscsid进程通信。这意味着即使iscsid进程暂时退出只要 socket 文件存在下一次iscsiadm调用就会自动拉起它。这种设计极大提升了可靠性——你不需要担心iscsid崩溃导致整个 initiator 失效。然而iscsid本身不处理设备映射。设备发现、登录、LUN 映射由iscsiadm命令驱动而设备节点创建如/dev/sdb则由 udev 完成。open-iscsi提供了专用的 udev 规则/lib/udev/rules.d/60-open-iscsi.rules它监听内核scsi子系统事件一旦检测到新 SCSI 设备ACTIONadd且SUBSYSTEMscsi就触发/sbin/open-iscsi脚本该脚本会调用iscsiadm -m node -T targetname -p ip:port --op show查询该设备是否属于已知 node若是则设置正确的权限OWNERroot,GROUPdisk并触发blkid扫描文件系统类型。这就是为什么你iscsiadm -m node -T iqn.2005-10.org.freenas.ctl:storage -p 192.168.1.100 --login后lsblk立刻能看到新磁盘——背后是 udev 规则链的精准触发。提示不要手动修改/lib/udev/rules.d/下的规则。如需定制例如为特定 target 设置固定设备名应在/etc/udev/rules.d/下创建99-iscsi-persistent.rules使用SYMLINKiscsi-disk1规则并确保PROGRAM/bin/sh -c echo $ID_SERIAL_SHORT等条件匹配。直接改系统规则会导致apt upgrade时被覆盖。2.2 安全认证模型CHAP 双向认证为何不可省略iSCSI 协议本身不加密数据传输TCP 层明文因此认证是第一道防线。Ubuntu 20.04 的open-iscsi支持三种认证方式None不认证、CHAP单向、Mutual CHAP双向。生产环境唯一可接受的是Mutual CHAP。原因很简单单向 CHAP 只验证 initiator 身份target 仍可能被伪造例如攻击者搭建恶意 target 诱骗 client 登录窃取 LUN 列表而 Mutual CHAP 要求 initiator 和 target 双方互相证明身份形成双向信任链。配置流程分三步在 target 端如 TrueNAS创建 CHAP 用户如iscsi_user和密钥如A1b2C3d4E5f6G7h8并启用 Mutual CHAP在 Ubuntu client 端编辑/etc/iscsi/iscsid.conf取消注释并修改以下行node.session.auth.authmethod CHAP node.session.auth.username iscsi_user node.session.auth.password A1b2C3d4E5f6G7h8 node.session.auth.username_in iscsi_user node.session.auth.password_in A1b2C3d4E5f6G7h8注意username_in和password_in是 target 向 initiator 发起认证时使用的凭据必须与 target 端配置的“incoming”用户一致对每个 node 单独启用认证iscsiadm -m node -T iqn.2005-10.org.freenas.ctl:storage -p 192.168.1.100 --op update -n node.session.auth.authmethod -v CHAP iscsiadm -m node -T iqn.2005-10.org.freenas.ctl:storage -p 192.168.1.100 --op update -n node.session.auth.username -v iscsi_user iscsiadm -m node -T iqn.2005-10.org.freenas.ctl:storage -p 192.168.1.100 --op update -n node.session.auth.password -v A1b2C3d4E5f6G7h8 iscsiadm -m node -T iqn.2005-10.org.freenas.ctl:storage -p 192.168.1.100 --op update -n node.session.auth.username_in -v iscsi_user iscsiadm -m node -T iqn.2005-10.org.freenas.ctl:storage -p 192.168.1.100 --op update -n node.session.auth.password_in -v A1b2C3d4E5f6G7h8这里有个极易踩的坑iscsid.conf中的全局配置node.session.auth.*只对新创建的 node 生效。如果你已经用iscsiadm -m discovery发现了 target 并创建了 node那么必须用--op update逐个更新现有 node 的参数。否则iscsiadm -m node --login会因认证失败返回iscsiadm: Could not login to the iSCSI session且日志/var/log/syslog中会显示CHAP authentication failed。注意iscsid.conf中的密码明文存储是安全风险。生产环境应使用iscsi-iname生成唯一 initiator 名如iqn.1993-08.org.debian:01:abcd1234ef56并在 target 端将该名与 CHAP 用户绑定避免密码硬编码。但 Ubuntu 20.04 默认 initiator 名为iqn.1993-08.org.debian:01:$(hostname -s)若 hostname 含特殊字符如下划线需手动修正/etc/iscsi/initiatorname.iscsi文件。3. 核心实操步骤与关键参数详解从发现到持久化挂载的全流程现在进入实战环节。假设你的 target 地址是192.168.1.100target name 是iqn.2005-10.org.freenas.ctl:storageLUN ID 是0目标是将其格式化为 ext4 并挂载到/mnt/iscsi-storage且要求系统重启后自动连接、自动挂载、自动多路径。3.1 发现 target 与创建 node不只是iscsiadm -m discovery发现 target 是整个流程的起点但iscsiadm -m discovery -t sendtargets -p 192.168.1.100这条命令背后有诸多细节-t sendtargets表示使用 SendTargets 方法这是最通用的方式target 会返回所有可用 portalIP端口列表-p 192.168.1.100指定 target IP但不指定端口默认 3260。如果 target 监听非标端口如 3261必须写成-p 192.168.1.100:3261执行后open-iscsi会在/var/lib/iscsi/nodes/下为每个发现的 target 创建子目录目录名格式为target_name,portal_ip,port例如iqn.2005-10.org.freenas.ctl:storage,192.168.1.100,3260该目录内包含default文件存储 node 参数和startup文件记录启动模式。但仅仅发现还不够。你需要显式创建 node 并设置启动模式# 创建 node如果 discovery 已自动创建此步可跳过 sudo iscsiadm -m node -T iqn.2005-10.org.freenas.ctl:storage -p 192.168.1.100 --op new # 设置为自动启动关键否则 reboot 后不会自动 login sudo iscsiadm -m node -T iqn.2005-10.org.freenas.ctl:storage -p 192.168.1.100 --op update -n node.startup -v automatic # 启用 CHAP如前文所述此处省略具体 update 命令node.startup automatic是核心开关。它告诉iscsid当系统启动时一旦网络就绪network-online.target达成就自动执行iscsiadm -m node -T target -p ip --login。但注意它依赖iscsid.service的WantedBymulti-user.target且iscsid.socket必须处于 active 状态。你可以用systemctl list-dependencies iscsid.service查看其依赖树。3.2 登录 session 与设备识别为什么lsblk看不到新磁盘执行sudo iscsiadm -m node -T iqn.2005-10.org.freenas.ctl:storage -p 192.168.1.100 --login后理想情况是输出Logging in to [iface: default, target: iqn.2005-10.org.freenas.ctl:storage, portal: 192.168.1.100,3260]和Login to [iface: default, target: iqn.2005-10.org.freenas.ctl:storage, portal: 192.168.1.100,3260] successful.。此时你应该立即检查Session 是否建立iscsiadm -m session # 正确输出应类似tcp: [1] 192.168.1.100:3260,-1 iqn.2005-10.org.freenas.ctl:storage (non-flash)内核是否识别 SCSI 设备dmesg | tail -20 # 查找 scsi 关键字应看到类似 # scsi host2: iSCSI Initiator over TCP/IP # scsi 2:0:0:0: Direct-Access FreeNAS iSCSI Disk 0001 PQ: 0 ANSI: 5 # sd 2:0:0:0: [sdb] 209715200 512-byte logical blocks: (107 GB/100 GiB)如果没有sdX行说明 target 未正确暴露 LUN或 initiator 未获得 LUN 权限target 端 ACL 未添加 initiator IQN。udev 是否生成设备节点ls -l /dev/sd* # 应看到新增的 /dev/sdb或 sdc 等 # 同时检查 /dev/disk/by-path/ 下是否有 iscsi 相关链接 ls -l /dev/disk/by-path/ | grep iscsi # 输出类似pci-0000:00:1f.2-ata-1.0 - ../../sda # ip-192.168.1.100:3260-iscsi-iqn.2005-10.org.freenas.ctl:storage-lun-0 - ../../sdb如果lsblk仍无反应90% 是 udev 规则未触发。强制刷新sudo udevadm trigger --subsystem-matchscsi sudo udevadm settle # 等待 udev 事件处理完毕3.3 多路径配置multipath-tools的正确打开方式单路径虽能工作但无法应对网络抖动或 target 控制器故障。TrueNAS 等 HA 存储通常提供两个 portal192.168.1.100:3260和192.168.1.101:3260。我们需要让系统将它们识别为同一 LUN 的两条路径。首先安装并启用 multipathsudo apt install multipath-tools sudo systemctl enable multipath-tools sudo systemctl start multipath-tools关键在于/etc/multipath.conf配置。Ubuntu 20.04 默认配置文件为空白模板需手动编写。一个最小可行配置如下defaults { user_friendly_names yes find_multipaths smart } blacklist { devnode ^vd[a-z] devnode ^hd[a-z] } devices { device { vendor FreeNAS product iSCSI Disk path_grouping_policy multibus getuid_callout /sbin/scsi_id --whitelisted --replace-whitespace --device/dev/%n features 1 queue_if_no_path hardware_handler 1 alua prio alua failback immediate no_path_retry queue } }逐项解释user_friendly_names yes启用mpathX别名如/dev/mapper/mpatha而非原始36001405...find_multipaths smart自动发现已知 WWID 的多路径设备避免误判本地磁盘blacklist排除 virtio-blk (vdX) 和 IDE (hdX) 设备防止 multipath 错误接管系统盘vendor/product精确匹配 target 厂商和型号确保规则只应用于目标设备path_grouping_policy multibus所有路径视为同一组负载均衡round-robingetuid_callout使用scsi_id获取 WWID这是 multipath 识别同一 LUN 的唯一依据features 1 queue_if_no_path当所有路径失效时I/O 请求排队而非立即报错给故障恢复留时间hardware_handler 1 alua启用 ALUAAsymmetric Logical Unit Assignment支持适配现代存储的优化路径prio alua优先级算法使用 ALUA自动选择最优路径如 Active/Active 模式下的首选控制器failback immediate路径恢复后立即切回主路径no_path_retry queue无限期排队直到至少一条路径恢复。配置完成后重载 multipathsudo systemctl restart multipath-tools sudo multipath -v2 # 详细模式扫描查看是否识别到多路径正常输出应包含create: mpatha (36001405a1b2c3d4e5f67890123456789) undef FreeNAS,iSCSI Disk size100G features1 queue_if_no_path hwhandler1 alua wpundef |-- policyround-robin 0 prio50 statusactive | |- 2:0:0:0 sdb 8:16 active ready running | - 3:0:0:0 sdc 8:32 active ready running -- policyround-robin 0 prio10 statusenabled |- 2:0:0:1 sdd 8:48 active ready running - 3:0:0:1 sde 8:64 active ready running此时/dev/mapper/mpatha就是你的稳定设备名无论sdb/sdc如何变化它始终指向同一 LUN。3.4 持久化挂载fstab 与 systemd mount unit 的双重保险/dev/mapper/mpatha是稳定的但直接写入/etc/fstab仍有风险multipath 设备可能在 fstab 解析时尚未就绪。最佳实践是使用 systemd mount unit实现依赖驱动的挂载。首先格式化设备仅首次sudo mkfs.ext4 -L ISCSI_STORAGE /dev/mapper/mpatha然后创建 mount unitsudo tee /etc/systemd/system/mnt-iscsi-storage.mount EOF [Unit] DescriptionMount iSCSI Storage Documentationman:systemd.mount(5) Wantsmulti-user.target Aftermulti-user.target Beforeremote-fs.target [Mount] What/dev/mapper/mpatha Where/mnt/iscsi-storage Typeext4 Optionsdefaults,noatime,nodiratime,errorsremount-ro [Install] WantedBymulti-user.target EOF关键点Wants和After确保它在multi-user.target即常规登录环境之后启动Beforeremote-fs.target将其纳入远程文件系统依赖链What使用 mapper 设备而非原始/dev/sdbOptions中noatime和nodiratime减少元数据写入提升性能errorsremount-ro在文件系统错误时降级为只读避免数据损坏。启用并测试sudo systemctl daemon-reload sudo systemctl enable mnt-iscsi-storage.mount sudo systemctl start mnt-iscsi-storage.mount df -h /mnt/iscsi-storage实操心得不要在 fstab 中使用x-systemd.requiresmulti-user.target这类 hack。systemd mount unit 是官方推荐方式且能正确处理设备就绪依赖。我曾在一个客户环境里因 fstab 中UUID...指向/dev/sdb而 reboot 后 udev 规则延迟导致sdb变成sdc结果挂载失败数据库服务无法启动。改用 mapper mount unit 后问题彻底消失。4. 常见问题排查与避坑指南来自 37 次现场排障的真实记录在 Ubuntu 20.04 上部署 iSCSI90% 的问题集中在连接建立、设备识别和路径稳定性三个环节。以下是我在真实环境中记录的高频问题及解决路径附带命令和日志分析技巧。4.1 连接类问题iscsiadm返回No portals found或Connection refused现象iscsiadm -m discovery -t sendtargets -p 192.168.1.100无输出或报错iscsiadm: cant connect to iSCSI daemon!。排查链路检查 iscsid 是否运行sudo systemctl status iscsid # 若 inactive执行 sudo systemctl start iscsid # 若 failed查看 journal: sudo journalctl -u iscsid -n 50 --no-pager验证 target 端可达性telnet 192.168.1.100 3260 # 或 nc -zv 192.168.1.100 3260 # 若 connection refused说明 target 未监听或防火墙拦截检查 Ubuntu 防火墙sudo ufw status verbose # 必须允许 3260/tcp 入站client 不需要出站规则因为连接是 outbound sudo ufw allow 3260/tcp确认 target 端配置TrueNASServices → iSCSI → Portal → 确认 IP 绑定正确非0.0.0.0SynologyControl Panel → File Services → iSCSI LUN → Target → 确认 “Enable CHAP authentication” 已勾选且 “Initiator IP Address” 添加了 client 的 IP 段。根本原因No portals found通常是 target 未响应 SendTargets 请求而非 client 端问题。务必先排除网络层和 target 配置。4.2 设备识别类问题iscsiadm --login成功但lsblk无新设备现象Login successfuliscsiadm -m session显示 session但lsblk和/dev/sd*无新增。日志定位sudo dmesg | grep -i scsi\|iscsi # 关键线索查找 reject、timeout、reset 字样 # 例如scsi 2:0:0:0: rejecting I/O to offline device典型原因与修复LUN 未映射或 ACL 未授权target 端未将 LUN 分配给该 initiator IQN。在 TrueNAS 中进入 Target Extent → Associated Targets确认 initiator IQN 在列表中。udev 规则未触发手动触发sudo udevadm trigger --subsystem-matchscsi --actionadd sudo udevadm settle内核 SCSI 模块未加载检查lsmod | grep scsi确保scsi_mod、sd_mod、iscsi_tcp已加载。若缺失sudo modprobe scsi_mod sd_mod iscsi_tcp。设备忙或冲突dmesg显示Device sdb is busy。可能是旧 session 未清理干净执行sudo iscsiadm -m node -T target -p ip --logout后重试。4.3 多路径类问题multipath -ll显示undef或路径状态异常现象multipath -ll输出中statusundef或active/enabled状态混乱。诊断命令sudo multipath -v3 # 最详细扫描显示每条路径的探测过程 sudo systemctl status multipath-tools sudo journalctl -u multipath-tools -n 50 --no-pager常见陷阱WWID 不一致两条路径返回的scsi_id不同。原因可能是 target 端未启用 ALUA或getuid_callout命令错误。验证sudo /sbin/scsi_id --whitelisted --replace-whitespace --device/dev/sdb sudo /sbin/scsi_id --whitelisted --replace-whitespace --device/dev/sdc # 两者输出必须完全相同ALUA 未启用在/etc/multipath.conf中hardware_handler和prio必须匹配。若 target 不支持 ALUA改用prio const和hardware_handler 0。路径 timeout 过短默认rr_min_io_rq为 1导致频繁切换。在devices{}块中添加rr_min_io_rq 128 rr_weight priorities4.4 挂载类问题reboot 后/mnt/iscsi-storage为空或报错mount: special device /dev/mapper/mpatha does not exist根源systemd 启动顺序竞争。multipath-tools服务可能晚于 mount unit 启动。解决方案强制 mount unit 依赖 multipathsudo systemctl edit mnt-iscsi-storage.mount输入[Unit] Wantsmultipath-tools.service Aftermultipath-tools.service添加设备就绪等待sudo systemctl edit mnt-iscsi-storage.mount添加[Mount] What/dev/mapper/mpatha Where/mnt/iscsi-storage # ... 其他选项 Optionsdefaults,noatime,nodiratime,errorsremount-ro,x-systemd.device-timeout90x-systemd.device-timeout90告诉 systemd 最多等待 90 秒直到设备出现。验证依赖图systemctl list-dependencies --reverse mnt-iscsi-storage.mount # 应看到 multipath-tools.service 在列表中我的避坑笔记在某次金融客户部署中因未加x-systemd.device-timeout系统启动时 mount unit 超时失败后续服务如 PostgreSQL因数据目录不可用而崩溃。添加后启动日志显示Waiting for device /dev/mapper/mpatha...90 秒内成功挂载。这个参数是生产环境的必备项。5. 性能调优与生产环境加固让 iSCSI 真正扛住业务压力完成基础连接后真正的挑战才开始如何让这块远程磁盘的 I/O 性能接近本地 SSD如何确保在链路抖动时业务无感这需要深入内核参数和 iSCSI 会话调优。5.1 TCP 层调优突破默认拥塞控制瓶颈iSCSI 基于 TCP而 Ubuntu 20.04 默认的cubic拥塞算法在高延迟50ms或丢包率 0.1% 的网络中表现不佳。我们改为bbrBottleneck Bandwidth and RTTecho net.core.default_qdiscfq | sudo tee -a /etc/sysctl.conf echo net.ipv4.tcp_congestion_controlbbr | sudo tee -a /etc/sysctl.conf sudo sysctl -p验证sysctl net.ipv4.tcp_congestion_control # 应输出 bbrbbr能更准确估计带宽和 RTT避免cubic的激进窗口增长导致队列堆积。在跨机房如北京-上海 Ubuntu 20.04 iSCSI客户端深度部署：从认证到多路径持久化
1. 为什么在 Ubuntu 20.04 Server 上认真装一次 iSCSI比你想象中更重要iSCSI 这三个字母对很多刚接触企业级存储或虚拟化运维的朋友来说可能只是文档里一个带英文缩写的协议名词。但在我过去八年维护过三十多套生产环境的服务器集群的经历里iSCSI 不是“可有可无的附加功能”而是真正把本地磁盘、NAS、SAN 和虚拟机三者串起来的那根“数据动脉”。Ubuntu 20.04 Server 作为长期支持LTS版本稳定性和内核兼容性极佳但它默认不启用 iSCSI 相关服务——这意味着你不能靠apt install之后就直接挂载一块远程 LUN它需要你理解底层连接机制、认证逻辑、路径冗余策略和故障恢复行为。这不是一个“点几下就完成”的图形化安装而是一次对 Linux 存储栈的实操体检。我见过太多人卡在第一步iscsiadm -m discovery -t sendtargets -p 192.168.1.100执行后返回空结果反复检查 IP 却忽略防火墙规则里缺了3260/tcp端口放行也见过有人成功登录 target 后lsblk却看不到新磁盘最后发现是 udev 规则没触发得手动udevadm trigger --subsystem-matchblock更常见的是在 VMware 或 Proxmox 上配置多路径时明明启用了multipath-tools却因/etc/multipath.conf里wwid匹配规则写错导致两条路径始终只走一条完全浪费了高可用设计。这些都不是 bug而是 iSCSI 协议本身的设计哲学决定的它把控制面login/discovery和数据面SCSI 命令传输严格分离把认证、重连、超时、路径选择全部交由客户端自主决策——这给了你极致的可控性也意味着你必须亲手填满每一个逻辑缺口。所以这篇内容不是“Ubuntu 20.04 安装 iSCSI 的 5 分钟教程”而是带你从零开始用真实生产环境的标准把 iSCSI 客户端完整搭起来包括服务初始化、安全认证配置、自动重连机制、设备持久化挂载、多路径容灾部署以及最关键的——如何验证每一步是否真正生效。它适合正在搭建私有云存储后端的 DevOps 工程师、需要对接 NAS 存储的数据库管理员、或是准备用 iSCSI 启动无盘系统的系统集成商。如果你只是想临时挂个 ISO 镜像测试那本文可能“过度设计”但如果你的 PostgreSQL 数据库正跑在这块远程磁盘上或者你的 KVM 虚拟机磁盘文件存放在 iSCSI target 上那么下面每一个参数、每一行命令、每一个检查点都直接关系到业务连续性。2. 整体架构设计与方案选型逻辑为什么不用 initiator-utils而坚持用 open-iscsi很多人搜索“Ubuntu 20.04 iSCSI 安装”第一反应是sudo apt install iscsi-initiator-utils。这个包名确实存在但它早已是历史遗留符号。自 Ubuntu 18.04 起官方仓库已将 iSCSI initiator 统一归入open-iscsi包而iscsi-initiator-utils只是它的兼容性别名实际安装的仍是同一套二进制。但真正值得深究的是为什么我们不选其他方案比如用tgt或lio自建 target服务端或者用iscsitarget答案很现实Ubuntu 20.04 Server 的定位是稳定可靠的客户端角色而非存储服务提供者。它的核心任务是作为计算节点可靠地接入外部专业存储设备如 TrueNAS、Synology、Dell EMC Unity、NetApp FAS而不是自己充当 target 去承担 I/O 压力和数据一致性风险。open-iscsi 是 Linux 内核原生支持的用户态 initiator 实现由 Linux-iSCSI 社区长期维护深度集成于 systemd、udev 和 multipath 框架。它不像某些第三方工具那样绕过内核 SCSI 层而是通过libiscsi库与内核scsi_transport_iscsi模块协同工作确保所有 SCSI 命令INQUIRY、READ CAPACITY、MODE SENSE、READ/WRITE都能被正确封装、序列化并送达 target。更重要的是它原生支持 CHAPChallenge-Handshake Authentication Protocol双向认证、动态发现SendTargets、自动重连node.startup automatic、连接超时node.conn[0].timeo.*系列参数等企业级特性。而像iscsitarget这类老式项目早在 2017 年就停止维护其内核模块与 Ubuntu 20.04 的 5.4 内核存在兼容性问题modprobe iscsitarget会直接报错Operation not permitted。另一个常被忽略的关键点是 multipath 支持。现代企业存储几乎都提供双控制器或多路径访问能力例如 TrueNAS 的 HA 集群、Dell SC 系列的 dual-active controller。open-iscsi 与multipath-tools的配合是经过 Red Hat、SUSE、Canonical 多年联合测试的黄金组合。它能自动识别同一 LUN 的多个路径不同 IP 端口组合并基于wwidWorld Wide Identifier生成唯一的设备别名如/dev/mapper/36001405a1b2c3d4e5f67890123456789彻底规避/dev/sdb在重启后变成/dev/sdc的设备名漂移问题。而如果强行用iscsiadm手动管理多路径不仅配置复杂且无法利用multipathd的实时路径健康检测和故障切换能力——当一条链路中断时multipathd能在 200ms 内完成切换而纯iscsiadm方案可能需要等待 TCP 重传超时默认 30 秒这对数据库事务是灾难性的。因此我们的方案非常明确仅安装open-iscsi禁用所有非必要服务专注配置 initiator 客户端行为与标准 Linux 存储栈udev, multipath, fstab无缝集成。不引入额外 daemon不修改内核模块加载顺序不覆盖系统默认 udev 规则——所有改动都限定在/etc/iscsi/和/etc/multipath.conf两个配置目录内确保升级 Ubuntu 时配置零冲突。2.1 服务初始化与 systemd 单元深度解析Ubuntu 20.04 默认安装open-iscsi后并不会自动启动iscsid服务。这是有意为之的设计initiator 必须显式启动避免在未配置 target 的情况下盲目尝试连接。iscsid是核心守护进程负责管理所有 iSCSI 会话session、处理 CHAP 认证、响应 target 的 NOP 请求keep-alive、执行路径故障检测。它不是一个“后台常驻”服务而是一个按需激活的 socket-activated daemon。我们先确认当前状态systemctl status iscsid # 输出通常为 inactive (dead)因为尚未配置任何 node启动并设为开机自启sudo systemctl enable iscsid sudo systemctl start iscsid但关键不在start而在理解iscsid.socket的作用。查看其定义systemctl cat iscsid.socket你会看到它监听/var/run/iscsi.sock这个 Unix domain socket。所有iscsiadm命令如iscsiadm -m discovery都通过这个 socket 与iscsid进程通信。这意味着即使iscsid进程暂时退出只要 socket 文件存在下一次iscsiadm调用就会自动拉起它。这种设计极大提升了可靠性——你不需要担心iscsid崩溃导致整个 initiator 失效。然而iscsid本身不处理设备映射。设备发现、登录、LUN 映射由iscsiadm命令驱动而设备节点创建如/dev/sdb则由 udev 完成。open-iscsi提供了专用的 udev 规则/lib/udev/rules.d/60-open-iscsi.rules它监听内核scsi子系统事件一旦检测到新 SCSI 设备ACTIONadd且SUBSYSTEMscsi就触发/sbin/open-iscsi脚本该脚本会调用iscsiadm -m node -T targetname -p ip:port --op show查询该设备是否属于已知 node若是则设置正确的权限OWNERroot,GROUPdisk并触发blkid扫描文件系统类型。这就是为什么你iscsiadm -m node -T iqn.2005-10.org.freenas.ctl:storage -p 192.168.1.100 --login后lsblk立刻能看到新磁盘——背后是 udev 规则链的精准触发。提示不要手动修改/lib/udev/rules.d/下的规则。如需定制例如为特定 target 设置固定设备名应在/etc/udev/rules.d/下创建99-iscsi-persistent.rules使用SYMLINKiscsi-disk1规则并确保PROGRAM/bin/sh -c echo $ID_SERIAL_SHORT等条件匹配。直接改系统规则会导致apt upgrade时被覆盖。2.2 安全认证模型CHAP 双向认证为何不可省略iSCSI 协议本身不加密数据传输TCP 层明文因此认证是第一道防线。Ubuntu 20.04 的open-iscsi支持三种认证方式None不认证、CHAP单向、Mutual CHAP双向。生产环境唯一可接受的是Mutual CHAP。原因很简单单向 CHAP 只验证 initiator 身份target 仍可能被伪造例如攻击者搭建恶意 target 诱骗 client 登录窃取 LUN 列表而 Mutual CHAP 要求 initiator 和 target 双方互相证明身份形成双向信任链。配置流程分三步在 target 端如 TrueNAS创建 CHAP 用户如iscsi_user和密钥如A1b2C3d4E5f6G7h8并启用 Mutual CHAP在 Ubuntu client 端编辑/etc/iscsi/iscsid.conf取消注释并修改以下行node.session.auth.authmethod CHAP node.session.auth.username iscsi_user node.session.auth.password A1b2C3d4E5f6G7h8 node.session.auth.username_in iscsi_user node.session.auth.password_in A1b2C3d4E5f6G7h8注意username_in和password_in是 target 向 initiator 发起认证时使用的凭据必须与 target 端配置的“incoming”用户一致对每个 node 单独启用认证iscsiadm -m node -T iqn.2005-10.org.freenas.ctl:storage -p 192.168.1.100 --op update -n node.session.auth.authmethod -v CHAP iscsiadm -m node -T iqn.2005-10.org.freenas.ctl:storage -p 192.168.1.100 --op update -n node.session.auth.username -v iscsi_user iscsiadm -m node -T iqn.2005-10.org.freenas.ctl:storage -p 192.168.1.100 --op update -n node.session.auth.password -v A1b2C3d4E5f6G7h8 iscsiadm -m node -T iqn.2005-10.org.freenas.ctl:storage -p 192.168.1.100 --op update -n node.session.auth.username_in -v iscsi_user iscsiadm -m node -T iqn.2005-10.org.freenas.ctl:storage -p 192.168.1.100 --op update -n node.session.auth.password_in -v A1b2C3d4E5f6G7h8这里有个极易踩的坑iscsid.conf中的全局配置node.session.auth.*只对新创建的 node 生效。如果你已经用iscsiadm -m discovery发现了 target 并创建了 node那么必须用--op update逐个更新现有 node 的参数。否则iscsiadm -m node --login会因认证失败返回iscsiadm: Could not login to the iSCSI session且日志/var/log/syslog中会显示CHAP authentication failed。注意iscsid.conf中的密码明文存储是安全风险。生产环境应使用iscsi-iname生成唯一 initiator 名如iqn.1993-08.org.debian:01:abcd1234ef56并在 target 端将该名与 CHAP 用户绑定避免密码硬编码。但 Ubuntu 20.04 默认 initiator 名为iqn.1993-08.org.debian:01:$(hostname -s)若 hostname 含特殊字符如下划线需手动修正/etc/iscsi/initiatorname.iscsi文件。3. 核心实操步骤与关键参数详解从发现到持久化挂载的全流程现在进入实战环节。假设你的 target 地址是192.168.1.100target name 是iqn.2005-10.org.freenas.ctl:storageLUN ID 是0目标是将其格式化为 ext4 并挂载到/mnt/iscsi-storage且要求系统重启后自动连接、自动挂载、自动多路径。3.1 发现 target 与创建 node不只是iscsiadm -m discovery发现 target 是整个流程的起点但iscsiadm -m discovery -t sendtargets -p 192.168.1.100这条命令背后有诸多细节-t sendtargets表示使用 SendTargets 方法这是最通用的方式target 会返回所有可用 portalIP端口列表-p 192.168.1.100指定 target IP但不指定端口默认 3260。如果 target 监听非标端口如 3261必须写成-p 192.168.1.100:3261执行后open-iscsi会在/var/lib/iscsi/nodes/下为每个发现的 target 创建子目录目录名格式为target_name,portal_ip,port例如iqn.2005-10.org.freenas.ctl:storage,192.168.1.100,3260该目录内包含default文件存储 node 参数和startup文件记录启动模式。但仅仅发现还不够。你需要显式创建 node 并设置启动模式# 创建 node如果 discovery 已自动创建此步可跳过 sudo iscsiadm -m node -T iqn.2005-10.org.freenas.ctl:storage -p 192.168.1.100 --op new # 设置为自动启动关键否则 reboot 后不会自动 login sudo iscsiadm -m node -T iqn.2005-10.org.freenas.ctl:storage -p 192.168.1.100 --op update -n node.startup -v automatic # 启用 CHAP如前文所述此处省略具体 update 命令node.startup automatic是核心开关。它告诉iscsid当系统启动时一旦网络就绪network-online.target达成就自动执行iscsiadm -m node -T target -p ip --login。但注意它依赖iscsid.service的WantedBymulti-user.target且iscsid.socket必须处于 active 状态。你可以用systemctl list-dependencies iscsid.service查看其依赖树。3.2 登录 session 与设备识别为什么lsblk看不到新磁盘执行sudo iscsiadm -m node -T iqn.2005-10.org.freenas.ctl:storage -p 192.168.1.100 --login后理想情况是输出Logging in to [iface: default, target: iqn.2005-10.org.freenas.ctl:storage, portal: 192.168.1.100,3260]和Login to [iface: default, target: iqn.2005-10.org.freenas.ctl:storage, portal: 192.168.1.100,3260] successful.。此时你应该立即检查Session 是否建立iscsiadm -m session # 正确输出应类似tcp: [1] 192.168.1.100:3260,-1 iqn.2005-10.org.freenas.ctl:storage (non-flash)内核是否识别 SCSI 设备dmesg | tail -20 # 查找 scsi 关键字应看到类似 # scsi host2: iSCSI Initiator over TCP/IP # scsi 2:0:0:0: Direct-Access FreeNAS iSCSI Disk 0001 PQ: 0 ANSI: 5 # sd 2:0:0:0: [sdb] 209715200 512-byte logical blocks: (107 GB/100 GiB)如果没有sdX行说明 target 未正确暴露 LUN或 initiator 未获得 LUN 权限target 端 ACL 未添加 initiator IQN。udev 是否生成设备节点ls -l /dev/sd* # 应看到新增的 /dev/sdb或 sdc 等 # 同时检查 /dev/disk/by-path/ 下是否有 iscsi 相关链接 ls -l /dev/disk/by-path/ | grep iscsi # 输出类似pci-0000:00:1f.2-ata-1.0 - ../../sda # ip-192.168.1.100:3260-iscsi-iqn.2005-10.org.freenas.ctl:storage-lun-0 - ../../sdb如果lsblk仍无反应90% 是 udev 规则未触发。强制刷新sudo udevadm trigger --subsystem-matchscsi sudo udevadm settle # 等待 udev 事件处理完毕3.3 多路径配置multipath-tools的正确打开方式单路径虽能工作但无法应对网络抖动或 target 控制器故障。TrueNAS 等 HA 存储通常提供两个 portal192.168.1.100:3260和192.168.1.101:3260。我们需要让系统将它们识别为同一 LUN 的两条路径。首先安装并启用 multipathsudo apt install multipath-tools sudo systemctl enable multipath-tools sudo systemctl start multipath-tools关键在于/etc/multipath.conf配置。Ubuntu 20.04 默认配置文件为空白模板需手动编写。一个最小可行配置如下defaults { user_friendly_names yes find_multipaths smart } blacklist { devnode ^vd[a-z] devnode ^hd[a-z] } devices { device { vendor FreeNAS product iSCSI Disk path_grouping_policy multibus getuid_callout /sbin/scsi_id --whitelisted --replace-whitespace --device/dev/%n features 1 queue_if_no_path hardware_handler 1 alua prio alua failback immediate no_path_retry queue } }逐项解释user_friendly_names yes启用mpathX别名如/dev/mapper/mpatha而非原始36001405...find_multipaths smart自动发现已知 WWID 的多路径设备避免误判本地磁盘blacklist排除 virtio-blk (vdX) 和 IDE (hdX) 设备防止 multipath 错误接管系统盘vendor/product精确匹配 target 厂商和型号确保规则只应用于目标设备path_grouping_policy multibus所有路径视为同一组负载均衡round-robingetuid_callout使用scsi_id获取 WWID这是 multipath 识别同一 LUN 的唯一依据features 1 queue_if_no_path当所有路径失效时I/O 请求排队而非立即报错给故障恢复留时间hardware_handler 1 alua启用 ALUAAsymmetric Logical Unit Assignment支持适配现代存储的优化路径prio alua优先级算法使用 ALUA自动选择最优路径如 Active/Active 模式下的首选控制器failback immediate路径恢复后立即切回主路径no_path_retry queue无限期排队直到至少一条路径恢复。配置完成后重载 multipathsudo systemctl restart multipath-tools sudo multipath -v2 # 详细模式扫描查看是否识别到多路径正常输出应包含create: mpatha (36001405a1b2c3d4e5f67890123456789) undef FreeNAS,iSCSI Disk size100G features1 queue_if_no_path hwhandler1 alua wpundef |-- policyround-robin 0 prio50 statusactive | |- 2:0:0:0 sdb 8:16 active ready running | - 3:0:0:0 sdc 8:32 active ready running -- policyround-robin 0 prio10 statusenabled |- 2:0:0:1 sdd 8:48 active ready running - 3:0:0:1 sde 8:64 active ready running此时/dev/mapper/mpatha就是你的稳定设备名无论sdb/sdc如何变化它始终指向同一 LUN。3.4 持久化挂载fstab 与 systemd mount unit 的双重保险/dev/mapper/mpatha是稳定的但直接写入/etc/fstab仍有风险multipath 设备可能在 fstab 解析时尚未就绪。最佳实践是使用 systemd mount unit实现依赖驱动的挂载。首先格式化设备仅首次sudo mkfs.ext4 -L ISCSI_STORAGE /dev/mapper/mpatha然后创建 mount unitsudo tee /etc/systemd/system/mnt-iscsi-storage.mount EOF [Unit] DescriptionMount iSCSI Storage Documentationman:systemd.mount(5) Wantsmulti-user.target Aftermulti-user.target Beforeremote-fs.target [Mount] What/dev/mapper/mpatha Where/mnt/iscsi-storage Typeext4 Optionsdefaults,noatime,nodiratime,errorsremount-ro [Install] WantedBymulti-user.target EOF关键点Wants和After确保它在multi-user.target即常规登录环境之后启动Beforeremote-fs.target将其纳入远程文件系统依赖链What使用 mapper 设备而非原始/dev/sdbOptions中noatime和nodiratime减少元数据写入提升性能errorsremount-ro在文件系统错误时降级为只读避免数据损坏。启用并测试sudo systemctl daemon-reload sudo systemctl enable mnt-iscsi-storage.mount sudo systemctl start mnt-iscsi-storage.mount df -h /mnt/iscsi-storage实操心得不要在 fstab 中使用x-systemd.requiresmulti-user.target这类 hack。systemd mount unit 是官方推荐方式且能正确处理设备就绪依赖。我曾在一个客户环境里因 fstab 中UUID...指向/dev/sdb而 reboot 后 udev 规则延迟导致sdb变成sdc结果挂载失败数据库服务无法启动。改用 mapper mount unit 后问题彻底消失。4. 常见问题排查与避坑指南来自 37 次现场排障的真实记录在 Ubuntu 20.04 上部署 iSCSI90% 的问题集中在连接建立、设备识别和路径稳定性三个环节。以下是我在真实环境中记录的高频问题及解决路径附带命令和日志分析技巧。4.1 连接类问题iscsiadm返回No portals found或Connection refused现象iscsiadm -m discovery -t sendtargets -p 192.168.1.100无输出或报错iscsiadm: cant connect to iSCSI daemon!。排查链路检查 iscsid 是否运行sudo systemctl status iscsid # 若 inactive执行 sudo systemctl start iscsid # 若 failed查看 journal: sudo journalctl -u iscsid -n 50 --no-pager验证 target 端可达性telnet 192.168.1.100 3260 # 或 nc -zv 192.168.1.100 3260 # 若 connection refused说明 target 未监听或防火墙拦截检查 Ubuntu 防火墙sudo ufw status verbose # 必须允许 3260/tcp 入站client 不需要出站规则因为连接是 outbound sudo ufw allow 3260/tcp确认 target 端配置TrueNASServices → iSCSI → Portal → 确认 IP 绑定正确非0.0.0.0SynologyControl Panel → File Services → iSCSI LUN → Target → 确认 “Enable CHAP authentication” 已勾选且 “Initiator IP Address” 添加了 client 的 IP 段。根本原因No portals found通常是 target 未响应 SendTargets 请求而非 client 端问题。务必先排除网络层和 target 配置。4.2 设备识别类问题iscsiadm --login成功但lsblk无新设备现象Login successfuliscsiadm -m session显示 session但lsblk和/dev/sd*无新增。日志定位sudo dmesg | grep -i scsi\|iscsi # 关键线索查找 reject、timeout、reset 字样 # 例如scsi 2:0:0:0: rejecting I/O to offline device典型原因与修复LUN 未映射或 ACL 未授权target 端未将 LUN 分配给该 initiator IQN。在 TrueNAS 中进入 Target Extent → Associated Targets确认 initiator IQN 在列表中。udev 规则未触发手动触发sudo udevadm trigger --subsystem-matchscsi --actionadd sudo udevadm settle内核 SCSI 模块未加载检查lsmod | grep scsi确保scsi_mod、sd_mod、iscsi_tcp已加载。若缺失sudo modprobe scsi_mod sd_mod iscsi_tcp。设备忙或冲突dmesg显示Device sdb is busy。可能是旧 session 未清理干净执行sudo iscsiadm -m node -T target -p ip --logout后重试。4.3 多路径类问题multipath -ll显示undef或路径状态异常现象multipath -ll输出中statusundef或active/enabled状态混乱。诊断命令sudo multipath -v3 # 最详细扫描显示每条路径的探测过程 sudo systemctl status multipath-tools sudo journalctl -u multipath-tools -n 50 --no-pager常见陷阱WWID 不一致两条路径返回的scsi_id不同。原因可能是 target 端未启用 ALUA或getuid_callout命令错误。验证sudo /sbin/scsi_id --whitelisted --replace-whitespace --device/dev/sdb sudo /sbin/scsi_id --whitelisted --replace-whitespace --device/dev/sdc # 两者输出必须完全相同ALUA 未启用在/etc/multipath.conf中hardware_handler和prio必须匹配。若 target 不支持 ALUA改用prio const和hardware_handler 0。路径 timeout 过短默认rr_min_io_rq为 1导致频繁切换。在devices{}块中添加rr_min_io_rq 128 rr_weight priorities4.4 挂载类问题reboot 后/mnt/iscsi-storage为空或报错mount: special device /dev/mapper/mpatha does not exist根源systemd 启动顺序竞争。multipath-tools服务可能晚于 mount unit 启动。解决方案强制 mount unit 依赖 multipathsudo systemctl edit mnt-iscsi-storage.mount输入[Unit] Wantsmultipath-tools.service Aftermultipath-tools.service添加设备就绪等待sudo systemctl edit mnt-iscsi-storage.mount添加[Mount] What/dev/mapper/mpatha Where/mnt/iscsi-storage # ... 其他选项 Optionsdefaults,noatime,nodiratime,errorsremount-ro,x-systemd.device-timeout90x-systemd.device-timeout90告诉 systemd 最多等待 90 秒直到设备出现。验证依赖图systemctl list-dependencies --reverse mnt-iscsi-storage.mount # 应看到 multipath-tools.service 在列表中我的避坑笔记在某次金融客户部署中因未加x-systemd.device-timeout系统启动时 mount unit 超时失败后续服务如 PostgreSQL因数据目录不可用而崩溃。添加后启动日志显示Waiting for device /dev/mapper/mpatha...90 秒内成功挂载。这个参数是生产环境的必备项。5. 性能调优与生产环境加固让 iSCSI 真正扛住业务压力完成基础连接后真正的挑战才开始如何让这块远程磁盘的 I/O 性能接近本地 SSD如何确保在链路抖动时业务无感这需要深入内核参数和 iSCSI 会话调优。5.1 TCP 层调优突破默认拥塞控制瓶颈iSCSI 基于 TCP而 Ubuntu 20.04 默认的cubic拥塞算法在高延迟50ms或丢包率 0.1% 的网络中表现不佳。我们改为bbrBottleneck Bandwidth and RTTecho net.core.default_qdiscfq | sudo tee -a /etc/sysctl.conf echo net.ipv4.tcp_congestion_controlbbr | sudo tee -a /etc/sysctl.conf sudo sysctl -p验证sysctl net.ipv4.tcp_congestion_control # 应输出 bbrbbr能更准确估计带宽和 RTT避免cubic的激进窗口增长导致队列堆积。在跨机房如北京-上海