企业官网建设流程全解析

简介：一份面向网络存储与容灾系统课程学习者的实验报告，主题为存储区域网络（SAN），完整覆盖FC SAN与iSCSI两大核心协议。包体仅含1个doc文档，大小约11.18MB，已吸引568人浏览学习，内容编排适合需要完成同类实验或入门存储网络配置的读者。报告以西南科技大学实验报告为模板，详细记录了光纤通道端口的WWN收集、主机启动程序端口查看，以及基于XigmaNAS开源存储服务器配置iSCSI目标、LUN（extent）、发起端组、认证组和门户组的全过程。每个步骤均配有界面截图和参数说明，便于对照复现。此外还总结了实际操作中常见的三类问题及解决办法，如路径含中文导致虚拟机创建失败、浏览器登录兼容性、LUN重复创建报错等，能帮助读者避免同类坑点，提升故障排查能力。通过这份报告，读者既能理解SAN工作原理，也能掌握从零搭建IPSAN的动手技能。

1. 存储区域网络：服务器不装硬盘之后发生了什么

一台服务器开机，BIOS 列表里出现了几块完全陌生的磁盘，而机器上并没有安装任何本地硬盘。这个场景在没接触过存储的人看来很怪，却是数据中心里最常规的形态：磁盘被搬到了机柜另一端的存储阵列里，通过光纤通道或者以太网连回来，操作系统只是在跟一个“远端裸盘”打交道。把磁盘拉远的那张网络，就是存储区域网络（SAN）。它和 NAS 最本质的区别是：NAS 给的是带文件系统的目录，SAN 给的是未格式化的块设备，格式化、分区、文件系统创建全发生在主机端。本次实验把 FC SAN 和 iSCSI 两条路线各走了一遍：先在 VNXe 上收集 FC 端口的 WWN，再通过 iSCSI 把 LUN 映射到 Windows 主机，最后用 XigmaNAS 这台开源网络存储服务器完整搭建了一套 IP SAN，适合正在做网络存储与容灾课程设计、第一次接触存储网络的人。

2. FC SAN 端口视角：从 WWN 收集到 Zoning 前置知识

2.1 WWN 的构成：FC 网络里的设备识别号

FC SAN 中设备不靠 IP 寻址，而是靠 WWN（World Wide Name）。WWN 是分配在 FC 节点和 FC 端口上的全球唯一标识，常见的是 64 位格式，写成 16 位十六进制字符，形如50:06:01:60:84:3e:12:34。这个标识的结构比 MAC 复杂：最前面 4 个 bit 是 NAA（Network Address Authority），用来表示地址分配机构，接着是厂商分配的 OUI 和目标设备序列号。不同 NAA 值对应不同的地址格式，生产环境里最常碰到的是 NAA 5 和 NAA 6。

既然 FC 设备挂在交换机上，主机要找到存储端口，就要先让交换机知道两个 WWN：一端是服务器 HBA 的 Port WWN，另一端是存储端口自己的 Port WWN。这两个标识在后续的 Zoning 配置里都会被直接引用，搞混 Node WWN 和 Port WWN 会导致交换机上的 Zone 永远激活不了。

2.2 在 VNXe 管理界面里定位 FC 端口

实验第一步是收集并记录存储端口的名称。在 VNXe 中操作路径是：设置 -> 更多配置 -> 高级配置 -> 端口设置。进入端口设置页面后，会看到 IO 模块列表，展开某个 IO 模块，逐个选择 Fibre Channel 端口，就能看到每个端口对应的 WWN、端口速率以及归属的存储处理器（SP）。

这里有一个容易混淆的点：每个 FC 端口其实有两个 WWN，一个是 Node WWN，标识端口所在设备；另一个是 Port WWN，标识端口本身。VNXe 端口列表里展示的是 Port WWN，而做 Zoning、做多路径识别时也以 Port WWN 为准。因此实验记录不应该只抄一串数字，还要把端口所在 IO 模块、SP 编号和速率一起记下来。这三个信息在排障时能帮助你判断链路到底连到了哪个控制器上，避免把故障范围从存储端误判到主机端。

2.3 收集主机启动器的 WWN

存储端口的 WWN 收集完，还要去 VNXe 的“主机”菜单里查看启动器。在 VNXe > 主机 > 启动器页面，可以看到所有注册上来的启动器条目，它们一般分两类：

• FC 启动器：以 WWN 形式显示，标识前缀是 FC；
• iSCSI 启动器：以 IQN 形式显示，标识前缀是iqn.。

实验里这一步很容易被跳过，因为不少同学认为“我还没建 LUN，为什么要看启动器”。实际原因是：存储阵列创建 LUN 时要做主机映射，而映射条件就是启动器的 WWN 或 IQN。如果启动器没有注册到存储上，LUN 建好了也看不到，等于白做。记录启动器时建议同时记下主机名，直接以 IP 或者主机名命名，不要用系统默认生成的编号，否则三个月后回看这张表根本分不清哪条 WWN 对应哪台机器。

2.4 记录 WWN 在真实环境里的用途

这一环节记录的 WWN 在真实环境里主要流向三个地方。第一，FC 交换机 Zoning：把主机 HBA 的 Port WWN 和存储端口的 Port WWN 划到同一个 Zone 里，其他端口不能访问这条链路，这是 FC SAN 环境里最基本的隔离手段。第二，存储端的 LUN 映射：VNXe 的主机定义里会绑定启动器，再给主机分配 LUN，映射关系层级是“主机组 -> 主机 -> 启动器 -> LUN”。第三，多路径软件：比如 PowerPath 或 MPIO 识别多条链路时，会按 WWN 判断路径是否指向同一个目标，WWN 记录一旦出错，多路径会被误判成多个独立链路，导致 I/O 路径混乱。

这一整套流程虽然是在 VNXe 的图形界面上完成的，但它背后的逻辑和命令行环境完全一致。理解了 WWN 在整个链路里的角色，后面再看 FC 交换机配置、存储初始化、主机连线，就能串起来了。

3. iSCSI 协议栈与 LUN 映射：从存储端到 Windows 发起程序

3.1 iSCSI 的分层：SCSI 指令封装进 TCP 段

iSCSI 做的事情是把 SCSI 指令和块数据封装进 TCP/IP 包。发起端（Initiator）发送 SCSI 命令，目标端（Target）执行并返回数据，默认监听端口是 3260。这一层封装有两个直接影响：一是物理层不再依赖光纤，千兆以太网就能跑；二是原来的 HBA 换成了普通网卡，软件启动器就能完成发起端功能，这也是实验里直接在 Windows 上用 iSCSI 发起程序连接 XigmaNAS 的原因。

iSCSI 的“设备标识”是 IQN（iSCSI Qualified Name），格式像这样：

iqn.2004-10.example.com:storage-lun1

这个格式分成三段：iqn.开头，后面是域名登记日期，再往后是反向域名，最后是冒号加自定义标识。和 FC 的 WWN 相比，IQN 是人可读的，但也要注意：发起端和目标端必须严格匹配 IQN 字符串，多一个字符、大小写不对都会认证失败。

3.2 在 VNXe 上创建 iSCSI 接口

实验里 VNXe 的 iSCSI 配置从设置 -> iSCSI 设置 -> iSCSI 接口开始。选择一个以太网端口，点击 Create，在弹出的窗口里指定存储处理器（SP）、IP 地址、子网掩码以及 VLAN 标签。这里的重点是存储处理器的分配：VNXe 有两个 SP，如果只给 SP A 建了 iSCSI 接口，那 LUN 映射到 SP B 时发起端就连不上。生产环境一般给两个 SP 都配置接口，再用多路径软件做聚合；实验中如果只有一个接口，后面 LUN 的归属要仔细看，LUN 创建在哪一侧，主机就必须连哪一侧的 IP。

VLAN 标签在实验里通常留空，但在真实环境里几乎是必填的。存储网络单独划 VLAN、单独分网段，是避免存储流量和业务流量互相干扰的常见做法。如果这里填了 VLAN ID，主机网卡所在交换机端口也必须设置成 trunk 模式，否则二层就通了，三层始终不通。

3.3 创建 LUN 和主机访问授权

接口创建完成后，进入存储管理创建 LUN。需要注意，在 iSCSI 存储里 LUN 不只面对容量申请，还面对主机访问控制。实验界面里依次配置了复制和快照的保护存储、主机访问，这说明 LUN 建好之后默认是不会被任何主机看到的，必须在“主机访问”里显式添加允许访问的发起端。

生产环境里如果有多个服务器，建议用 Initiator Group（发起端组）来管理，而不是给每个 LUN 单独绑一个 IQN。这样后续扩容只需要把新 LUN 挂到已有组，而不用逐个主机修改映射关系。VNXe 中创建 LUN 时还可以选精简配置还是厚配置，实验容量不大，厚配置更直观，性能和容量都更容易理解。

3.4 Windows 发起程序连接与磁盘加载

在 Windows 主机上打开 iSCSI 发起程序，输入存储端 IP，点击快速连接。连接成功后还不能直接使用，因为 Windows 磁盘管理里这只是块未初始化的磁盘。到计算机管理里的磁盘管理，右键联机，再用右键初始化磁盘，之后才能新建简单卷。

# 查看 Windows 上已发现的 iSCSI 目标 Get-IscsiTarget | Format-Table -Property TargetAddress, IsConnected, TargetName

这段命令在管理员权限的 PowerShell 会话里执行。TargetAddress 是存储端的地址，IsConnected 显示当前是否已经建立连接，TargetName 是目标端暴露出来的名称。如果这里显示 False，就要回头检查存储端的 Portal Group 和 Initiator Group 配置，尤其是发起端组里有没有把当前主机的 IQN 加进去。

提示：连接后如果磁盘管理里看不到新硬盘，先检查目标是否为已连接状态，再检查磁盘是否处于脱机状态。Windows Server 会把新 LUN 默认设为脱机，这是常见坑。

4. XigmaNAS 构建 IP SAN：ZFS 存储池与 iSCSI Target 全链路

4.1 为什么用 XigmaNAS 做实验

XigmaNAS 是一个基于 FreeBSD 的开源网络存储服务器，提供文件共享、备份、RAID、ZFS 存储池和 iSCSI Target 服务。和直接在 Linux 上写 iscsi-target.conf 相比，它把磁盘管理、存储池和 iSCSI 目标全部集成到了 WebGUI 里，做存储网络实验时能省掉大量命令行调试时间。先在这里跑熟 iSCSI Target 的组件关系，再迁移到 tgtadm 或者 FreeBSD 的 ctld 环境，理解成本会低很多。

4.2 虚拟机里安装和磁盘规划

创建虚拟机时，除了系统盘之外，再添加四块同样大小的虚拟磁盘，作为后续 ZFS 存储池的成员盘。导入老师提供的 ISO 后开机，安装控制台里选择第 9 项进入安装程序，然后选择第 3 项 Install'Full' OS on HDD/SSD + DATA/SWAP。这个全盘安装模式会把系统文件、数据文件、交换分区放到同一块目标硬盘上，适合虚拟机测试场景。安装完成后重启，控制台会显示 WebGUI 访问地址，通常是一个http://开头的内网地址。

这里有个容易忽略的细节：虚拟机网卡模式。如果后续 Windows 主机和 XigmaNAS 不在同一个虚拟机网络里，iSCSI 发起程序会一直发现不了目标。实验时建议把 XigmaNAS 和 Windows 主机放在同一个 VMware 网络或 VirtualBox Host-Only 网络里，保证二层互通。

4.3 添加磁盘、格式化和 ZFS 池

登录 WebGUI 后的操作顺序是固定的：

1. Disks -> Management -> HDD Management，逐个添加四块数据盘；
2. Disks -> Management -> HDD Format，对每块盘执行格式化；
3. Disks -> ZFS -> Pools -> Virtual Device，把四块盘组成虚拟设备；
4. Disks -> ZFS -> Pools -> Management，基于虚拟设备创建存储池。

ZFS 的层次结构和普通文件系统不一样：vdev 是池底层的构成单元，一个池可以有一个或者多个 vdev，创建时要选对 RAID 级别。实验里四块盘是按 stripe 处理，还是按 raidz1 处理，决定了可用容量和故障容忍度。如果只是验证 iSCSI 链路，stripe 最省事；如果希望接近生产环境，就用 raidz1，它允许坏一块盘而不丢数据。

创建完存储池，可以在 Shell 或 SSH 下用命令直接验证：

# 查看 ZFS 存储池整体状态 zpool status # 查看池内数据集和挂载点 zfs list

zpool status是 ZFS 场景下排障的第一条命令，它输出池名、状态（ONLINE / DEGRADED / FAULTED）、vdev 布局以及 I/O 错误计数。zfs list则列出池里的数据集、已用空间和挂载点。这两条命令在之后的 iSCSI 排障里能帮助我们确认池是否处于可用状态，避免把存储池故障误判成 iSCSI 配置问题。

4.4 iSCSI Target 的四个组件

XigmaNAS 的 iSCSI Target 配置由四个部分组成，实验里创建的顺序也印证了这一点：

先创建 Extent，再创建 Initiator Group、Auth Group、Portal Group，最后在 Target 页面把它们绑定在一起。Extent 里如果选 File 类型，路径必须指向 ZFS 池中的实际文件或目录，路径写错是创建失败最常见的原因；选 Disk 类型则直接指定块设备。做实验时 File 类型更灵活，一个文件就是一个 LUN，删除也简单，对应关系一目了然。

Auth Group 在实验里可以配置也可以不配置。生产环境几乎必须开启 CHAP，否则同一个二层网络里的任何主机都能发现并连接这个 target。CHAP 认证配置时要注意用户名和密码在发起端、目标端两侧都要一致，发起端配置错了通常表现为“目标已发现但连接超时”，而不是直接报密码错，这个现象容易误导人。

4.5 目标创建与客户端接入

在 Service -> iSCSI Target -> Target 页面创建目标，填一个规范的 Target Name，比如iqn.2024-04.local.xigmanas:target1，然后把前面创建的 Extent、Portal Group、Initiator Group、Auth Group 全部选进来，保存后目标状态为 Online。

客户端接入的流程和上一章 VNXe 部分基本一致：Windows 打开 iSCSI 发起程序，输入 XigmaNAS 的 IP 地址，发现目标后连接；之后到磁盘管理里联机、初始化、新建卷。到这里，一台开源网络存储服务器上的完整 IP SAN 就跑通了。

5. 排错场景：ISO 路径、浏览器会话与 Extent 目录三连坑

5.1 ISO 路径含中文导致虚拟机创建失败

实验记录里第一个卡壳点是创建虚拟机时卡在一个位置直接失败。排查到最后，问题出在 ISO 文件路径带中文字符，虚拟化软件在解析镜像路径时行为异常。把 ISO 拷贝到纯英文路径后创建即恢复正常。这个问题的通用性不低：桌面虚拟化软件对非 ASCII 字符路径的兼容性时好时坏，更容易出现在 ISO 挂载、快照目录和虚拟磁盘路径三类场景。建议虚拟机目录、ISO 路径一律只用英文字母、数字和下划线。

5.2 登录页面闪回问题

第二个坑在 WebGUI 登录：输入账号密码点击 login，页面闪一下又停回登录界面，再点还是一样的现象。这个表现通常让人误以为是密码错误，但其实界面上没有任何报错。实验中换到 Chrome 后正常登录，后续重新登录时原来的浏览器也能成功，说明是会话 Cookie 和页面重定向逻辑的兼容性问题，而不是账号问题。

遇到这种“闪回”时，先清除该站点的 Cookie，再用无痕窗口验证一次；仍然失败就换浏览器内核，检查 WebGUI 使用的 Web 服务器日志。不要反复尝试改密码，那样只会把问题带到另一个方向。

5.3 Extent 创建失败：文件路径的父目录问题

第三个坑发生在 iSCSI Extent 创建上：添加 Extent 时页面没有成功，重新创建时提示已有同名项冲突。单独看提示很容易以为是资源被占用，实际原因是 Extent 里指定的文件路径其父目录不存在，XigmaNAS 不会自动创建深层目录。

处理方法是使用 Tools -> File Manager，用 WebGUI 账号登录后先创建/mnt/vd01/extend目录，然后回到 iSCSI 页面重新创建 Extent，路径指定到该目录下的文件，创建才成功。关键点在于：File 类型的 Extent 不仅需要文件路径，还需要保证父目录存在；如果后续要建多个 LUN，建议先规划好目录结构，比如按池名和业务名分目录，再逐层创建，避免每次添加都要临时补目录。

5.4 一条命令验证 iSCSI 链路

实验结束后再次连接时，不必每次打开图形界面确认状态。在 Windows 上用 PowerShell 直接查会话：

# 查看当前主机的 iSCSI 会话，确认目标连接状态 Get-IscsiSession | Select-Object -Property TargetName, InitiatorAddress, TargetAddress, NumberOfConnections

TargetName对应存储端创建的目标名，InitiatorAddress是发起端网卡 IP，TargetAddress是存储端 IP，NumberOfConnections为当前会话的连接数。单路径场景为 1，多路径场景为 2 或更多。出现“连得上但磁盘管理里没有盘”的情况时，先执行这条命令：确认会话是通的，再查磁盘是否脱机，最后才去检查存储端映射关系，顺序反了会在错误的方向上浪费时间。

本文还有配套的精品资源，点击获取