Hyper-V 双机集群对接群晖 iSCSI 存储：故障转移与 MPIO 多路径实战

一、为什么 Hyper-V 集群要选群晖 iSCSI 做共享存储

做 Hyper-V 故障转移集群(Failover Cluster)有个绕不开的前置条件——共享存储。两台(或多台)Hyper-V 主机要把同一批虚拟机在节点之间漂移,虚拟机文件必须放在两边都能访问的存储上,否则漂过去就找不到 vhdx 了。

这个共享存储的选型,直接决定整套方案的成本、复杂度、可靠性。常见选项有四类:

方案	成本	性能	运维	适用场景
FC-SAN(光纤存储区域网)	极高(光纤交换机+HBA 卡+存储)	极好	复杂	金融/医疗/大型企业
专业 iSCSI 存储(华为/EMC/Dell)	高(5-30 万)	好	中等	中大型企业
Windows Server 自带 S2D(横向存储)	中(2-3 台服务器即可)	好	中等	2-3 节点小集群
群晖 NAS + iSCSI	低(2-3 万)	好(RAID 10 + SSD 缓存)	简单(DMS GUI)	小微企业 / 成长型企业 / 50-300 VM

对预算有限、运维人手不足的中小型企业来说,群晖 NAS 充当 iSCSI 存储是性价比最高的选择。理由:

• 成本:一台群晖 SA/FS 系列(支持 SSD 缓存 + 万兆网)2-3 万,比专业 iSCSI 存储便宜 10 倍
• 易用:DSM 7.x 的 SAN Manager 全图形化配置 iSCSI LUN/Target,10 分钟出活
• 稳定:群晖 iSCSI 协议实现是 Linux Open-iSCSI,稳定跑了 10+ 年,被 Hyper-V/SCVMM/SQL Server 大量生产用
• 扩展:群晖支持 Btrfs 文件系统快照、Hyper Backup、SSD 读写缓存、SHR/RAID 10 灵活配置

核心思路:把群晖当成”廉价版 SAN 存储”,通过 iSCSI 协议给 Hyper-V 集群提供共享块设备,再在 Hyper-V 端用 MPIO 多路径 + 故障转移集群实现 VM 高可用。

二、整体架构与硬件规划

先画一张完整的架构图,看清每个组件的位置和作用:

层级	组件	建议配置	作用
存储层	群晖 NAS(SA/FS 系列)	2 台(同型号做 SHR 双控,或 1 台主+1 台冷备)	iSCSI LUN 提供共享块设备
网络层	iSCSI 存储网络	双万兆交换机 + 群晖 4 端口 + 每台 Hyper-V 2 端口(MPIO)	物理隔离 iSCSI 流量,避免业务抢带宽
计算层	Hyper-V 主机	2 台 Windows Server 2022 Datacenter(2 颗 CPU/64GB+/SSD 系统盘)	跑故障转移集群 + VM
集群层	MSFC 故障转移集群	2 节点,见证磁盘或文件共享见证(群晖 SMB)	VM 漂移/HA 仲裁
备份层	群晖 Active Backup	Agent 装在每台 Hyper-V 主机	VM 整机备份+恢复

关于”双台群晖还是单台”的经典选择:大多数中小型企业用单台群晖配 RAID 10 + SSD 缓存即可,群晖的 RAID 10 已经提供单机级别的硬盘冗余;真正想做到存储层”零单点”才上双机 SHR + 同步复制(Snapshot Replication),但成本翻倍。故障转移靠 Hyper-V 集群自己解决,不依赖存储双机。

网络规划关键点:

• iSCSI 流量必须和业务流量物理隔离——单独走一对万兆交换机或一对独立 VLAN,避免 VM 业务突发流量挤爆存储 I/O
• 每台 Hyper-V 主机至少 2 个 iSCSI 专用网口——为 MPIO 多路径做准备,单网口无 MPIO 价值
• 群晖至少 2 个 iSCSI 专用网口——同样为 MPIO 准备,4 端口更佳(双链路 + 双交换机)
• 启用 Jumbo Frame(MTU 9000)——端到端(群晖端口 → 交换机 → 服务器 NIC)三层设备全部一致,否则 I/O 性能损失 30%+

三、群晖 DSM 7.x 配置 iSCSI LUN(共享块设备)

群晖从 DSM 7.0 起把 iSCSI 配置整合到独立的 SAN Manager 应用,比老版本(DSM 6.x 的”iSCSI Manager”+”Virtualization Manager”分开)更直观。

Step 1:安装 SAN Manager

• 登录 DSM → 打开套件中心 → 搜索”SAN Manager” → 点击”安装”
• 安装完成后,主菜单会出现”SAN Manager”图标

Step 2:创建 iSCSI LUN(块设备)

• 打开 SAN Manager → 左侧菜单”LUN” → 点”创建” → 选择”块级 LUN”(高级 LUN 需要 Btrfs 卷,普通 LUN 用 ext4 即可)
• 选择目标存储池/存储空间(必须是 RAID 10 或 RAID 6,单盘 RAID 0 严禁做 iSCSI 后端)
• 指定 LUN 容量(预留 20% 容量做快照和扩容,例:100 颗 VM 总需 5TB,分配 6TB LUN)
• 关键:启用”空间回收”(Thin Provisioning)——按需分配,避免一次性分满浪费;但 Thin 不能给数据库类高 IO 应用用,要 Block 级厚置备
• LUN 高级设置:启用”SSD 缓存“(如果已装 SSD 缓存盘),启用”4K 块对齐”,启用”iSCSI 大型 LUN”(超过 2TB 时开启)

Step 3:创建 iSCSI Target(目标门户)

• SAN Manager → 左侧菜单”Target” → 点”创建”
• 输入 Target 名称(例:hyperv-cluster-lun01),IQN 格式自动生成,记下来后面 Hyper-V 端要用
• 关键:绑定 iSCSI 专用网口 IP——把 Target Portal 限定在 iSCSI 专用网卡的 IP 上(例:192.168.50.10/24),不要绑定业务网口
• CHAP 认证:生产环境强烈建议开启双向 CHAP——给所有 Hyper-V 主机分配一个相同的 CHAP 用户(例:hyperv-clu) + 12 位以上强密码,避免未授权访问
• IQN 掩码(更安全):限制只有特定 IQN 的 Initiator 能连这台 Target

Step 4:把 LUN 映射给 Target

• 在 LUN 列表中,选中刚创建的 LUN → 点”映射到现有 Target” → 选中 Target 名称 → 确认
• 此时在 SAN Manager 首页就能看到 LUN 状态为”已映射”,状态绿色

Step 5:配置群晖多路径(MPIO 后端)

• SAN Manager → 顶部”设置” → “iSCSI 多路径”——列出群晖所有可用的 iSCSI 网络接口
• 勾选所有要用于 MPIO 的网口(例:群晖 4 个 iSCSI 专用网口都勾上)
• 多路径策略:Hyper-V 推荐用 “ALUA(Asymmetric Logical Unit Access)” 或 “Round Robin”——SAN Manager 7.x 默认 ALUA,适合多数场景

配置完成后,在 SAN Manager 首页应该看到:

• Target 状态:在线(绿点)
• LUN 状态:已映射(绿点)
• 群晖 iSCSI 服务端口:默认 3260(可改)

四、Hyper-V 主机配置 iSCSI 发起程序 + MPIO 多路径

群晖端已经”开门迎客”,现在去 Hyper-V 主机上”接客”。每台 Hyper-V 节点都要做以下步骤——两台完全一致,做脚本批量部署更省事。

Step 1:启用 iSCSI 发起程序服务

Windows Server 默认不自动启 iSCSI Initiator Service,先把它设为自动启动:

Set-Service -Name MSiSCSI -StartupType Automatic
Start-Service MSiSCSI

Step 2:配置 iSCSI 发起程序连接群晖 Target

• 打开”iSCSI 发起程序“(iscsicpl.exe)— 第一次打开会弹窗问是否启用服务,选”是”
• “发现”选项卡 → “发现门户” → 输入群晖 iSCSI 第一个 IP(例:192.168.50.10),端口 3260 → 重复操作把第二个群晖 IP(例:192.168.50.11)也加进来
• “目标”选项卡 → 刷新后应该看到群晖的 Target 名称(hyperv-cluster-lun01),状态”非活动” → 选中 → 点”连接” → 勾选”启用多路径“和”将此连接添加到收藏目标“
• “配置”选项卡 → 点”CHAP” → 启用 CHAP → 输入群晖配置的 CHAP 名称和密码(双向 CHAP 还要填”反向 CHAP”那栏) → 确定

此时打开”磁盘管理” → 应能看到一块”未知”新硬盘(容量等于群晖 LUN 容量)→ 右键”联机” → “初始化”为 GPT → 不需要建分区,只是占位让 MPIO 看到

Step 3:安装并启用 MPIO 多路径 I/O 功能

Windows Server 自带 MPIO 功能,默认不启用,装一次:

Install-WindowsFeature Multipath-IO
Restart-Computer  # 装完必重启

重启后打开”MPIO“(mpiocpl.exe)→ “发现多路径”选项卡 → 勾选”添加对 iSCSI 设备的支持” → 设备硬件 ID 默认填 “MSFT2005iSCSIBusType_0x00000001” → 确定

再回到 “iSCSI 发起程序” → “目标” 选项卡 → 选中 Target → “属性” → “会话” → 应该看到2 条以上的会话(每条对应一个群晖网口/路径)

Step 4:配置 MPIO 负载均衡策略

• 打开 MPIO → “设备”选项卡 → 找到 iSCSI 设备(显示为”MSFT Virtual HD”或磁盘 GUID)
• 右键 → “属性” → “MPIO 策略” 选项卡
• 推荐策略:
• Round Robin(轮询):I/O 均匀分摊到所有路径,适合大多数读多写少场景,性能最好
• Least Queue Depth:选队列最少的路径,适合 SSD 缓存场景
• Fail Over Only(主备):只有主路径挂了才走备路径,适合资金紧张的”双链路热备”场景
• 勾选”路径失败后等待 X 秒再重试”——推荐 30 秒,避免频繁切换抖动

Step 5:验证 MPIO 路径状态

PowerShell 一行验证所有 iSCSI 路径是否健康:

Get-IscsiConnection | Select-Object InitiatorPortalAddress, TargetPortalAddress, ConnectionState
# 期望输出:每个 Target 显示 2 行(MPIO 多路径),State 全部 "Connected"

再查 MPIO 磁盘健康状态:

mpclaim -e  # 列出所有 MPIO 设备和路径状态
# 期望:每个设备至少 2 条 "Active/Optimized" 路径

五、搭建 Hyper-V 故障转移集群(MSFC)

iSCSI + MPIO 都通了,现在装故障转移集群角色。两台 Hyper-V 主机都装:

Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools
Install-WindowsFeature -Name Hyper-V -IncludeManagementTools -Restart
# 注:Hyper-V 已经装过的可以跳过

两台都装完后,用”验证集群”向导先体检(强烈建议,不要直接建集群):

• 打开”故障转移集群管理器” → 右键左侧”故障转移集群管理器” → “验证配置”
• 添加两台主机名(例:HV01、HV02)→ 下一步
• 运行”所有测试”(存储、网络、系统配置)→ 大约 5-10 分钟
• 警告列表里重点看这 3 条:
• “未配置群集见证”——下一步建集群时补
• “网络通信延迟”——iSCSI 网卡有丢包,检查网线/交换机/Jumbo Frame
• “磁盘见证要求”——CSV 没启用,建集群后再说
• 验证通过后(即使有警告也行,但不能有”错误”),点”完成”→ 立即”创建集群”

创建集群:

• 集群名称:CLU-HV01(自定义)
• 集群 IP:192.168.50.100(集群管理地址,与 iSCSI 同网段方便心跳)
• 勾选”将所有符合条件的存储添加到集群“——把群晖 iSCSI 磁盘加进集群

配置集群共享卷(CSV):

• 故障转移集群管理器 → 集群名 → “磁盘”
• 找到群晖 iSCSI 磁盘 → 右键”添加到群集共享卷“
• CSV 卷路径自动分配(如 C:ClusterStorageVolume1)
• 所有 VM 文件(.vhdx)都放 CSV 卷里,这样 VM 漂移时文件能跟着走

配置集群见证(Quorum):

• 右键集群 → “更多操作” → “配置集群仲裁设置”
• 选择”选择仲裁见证”→ “配置文件共享见证”(成本最低,2 节点集群最常用)
• 文件共享路径:\\群晖IP\ClusterWitness(在群晖上建一个只允许集群账号读写的 SMB 共享)
• 见证文件大小 5MB 起步,集群自动管理

六、创建高可用 VM + 实测故障转移

集群就绪后,开始建高可用 VM。

Step 1:创建 VM(注意选 CSV 卷存 vhdx)

• 故障转移集群管理器 → 右键”角色” → “虚拟机” → “新建虚拟机” → 选择目标节点(HV01)→ 选第二代 VM(Gen 2,UEFI 启动)→ 指定 vhdx 路径到 C:ClusterStorageVolume1VMsTest-VM01
• VM 创建后,在”角色”列表里 Test-VM01 状态为”高可用”(而非”非高可用”)

Step 2:配置 VM 首选节点 + 优先级

• 右键 VM → “属性” → 切换到”首选所有者”列表,把所有节点都加进去,第一个为”首选”
• “自动启动”选项:设置”如果状态为运行中,不要自动启动”(避免节点切换时双启)

Step 3:实测故障转移——这是验证整套方案最关键的一步:

• 方法 A:模拟节点宕机——拔掉 HV01 的电源或网线,看 VM 是否在 30-60 秒内自动漂到 HV02 并恢复运行
• 方法 B:PowerShell 实时迁移(不中断业务):

# 手动实时迁移 VM(无中断)
Move-ClusterVirtualMachineRole -Name "Test-VM01" -Node HV02

# 查询 VM 当前所在节点
Get-ClusterGroup -Name "Test-VM01" | Select-Object OwnerNode, State

# 集群验证报告(查所有资源健康)
Get-ClusterResource | Where-Object {$_.ResourceType -eq "Virtual Machine"} | Select-Object Name, OwnerNode, State

方法 C:模拟 iSCSI 路径故障——验证 MPIO 兜底:

• 在 HV01 上禁用其中一个 iSCSI 网口(模拟一根网线断了)
• 观察 MPIO 状态:路径从”Active”变”Standby”,但 VM 不中断
• 网口恢复后,路径自动回到”Active”

实测典型时延:

故障类型	检测到故障	VM 重新上线	业务中断时间
Hyper-V 节点宕机(电源断)	~10s(集群心跳超时)	20-40s	20-40s
单条 iSCSI 路径故障(网线/交换机端口)	< 5s(MPIO 检测)	0s(走另一条路径)	无感知
群晖整机故障(极端)	30-60s	需群晖修复/启用备机	数分钟-数小时

注意:Node 宕机 VM 漂移有 20-40s 业务中断(取决于 VM 内存大小、集群心跳配置),如果你的业务是 SQL Server/Oracle 这类对中断敏感的服务,应配置 AlwaysOn / 数据库镜像 在 VM 之上再做一层应用级 HA,避免单 VM 中断影响数据库事务。

七、性能调优:Jumbo Frame / 块对齐 / SSD 缓存

默认配置下,iSCSI 性能往往只有裸磁盘的 50-60%。三个调优点立竿见影:

1.启用 Jumbo Frame(MTU 9000)

标准以太网 MTU 1500,每个 iSCSI 包都要切片重组;MTU 9000 后每个包负载大 6 倍,CPU 中断减少 70%。端到端三层设备必须全部支持 9000 并启用:

# PowerShell 在每台 Hyper-V 主机设置 iSCSI 网卡 MTU
$nic = Get-NetAdapter | Where-Object {$_.Name -like "*iSCSI*"}
Set-NetAdapterAdvancedProperty -Name $nic.Name -DisplayName "Jumbo Packet" -DisplayValue "9014"
# 群晖端:控制面板 → 网络 → 网络接口 → 编辑 → MTU 设为 9000
# 交换机端:对应端口开启 jumbo frame(具体命令看交换机品牌)

验证 MTU 生效:

# 在 Hyper-V 主机 ping 群晖 iSCSI IP,数据负载 8000 字节测试
ping 192.168.50.10 -f -l 8000
# 期望:如果 MTU 9000 全链路通了,会 "需要拆分数据包但是设置 DF" 失败 → 表示 MTU 实际是 9000+

2.iSCSI 块对齐 4K(避免写放大)

群晖 DSM 7.x 的 SAN Manager 创建 LUN 时默认就是 4K 块对齐,只要不在 Windows 端用”快速初始化”,4K 对齐会自动生效。验证方法:

# 验证磁盘分区是否 4K 对齐
wmic partition get Name, StartingOffset
# 期望:StartingOffset 能被 4096 整除(现代 Windows 自动对齐)

3.SSD 缓存(读缓存 + 写缓存)

群晖 SA/FS 系列支持两块 SSD 做只读缓存(Read Cache)或读写缓存(RW Cache)。把 LUN 卷加入 SSD 缓存池后,随机读性能提升 5-10 倍:

• 群晖 → 存储管理器 → SSD 缓存 → 创建 → 选 LUN 所在存储池 → 选 RAID 类型(单 SSD 只读,双 SSD 镜像读写)
• 容量建议:缓存 SSD ≥ LUN 热数据集的 10%(例:LUN 6TB,SSD 缓存 600GB+)
• 注意:SSD 缓存不是备份,断电时未刷盘的写缓存会丢失(群晖有 supercap 电容保护)

实测性能对比(仅供方向参考,实际以你环境为准):

配置	顺序读	顺序写	4K 随机读 IOPS
群晖 RAID 10 + 万兆 + 默认 MTU	~800 MB/s	~400 MB/s	~8K
群晖 RAID 10 + 万兆 + MTU 9000	~1100 MB/s	~550 MB/s	~12K
+ 双 SSD 读缓存	~1100 MB/s	~550 MB/s	~80K+

SSD 缓存对随机读的提升是数量级的——如果你的 VM 跑的是 SQL Server、ERP 这类高随机读负载,加 SSD 缓存基本是”花小钱办大事”。

八、常见故障排查与避坑指南

实战中 90% 的问题集中在以下 5 类,提前预防能省 80% 排障时间:

1.iSCSI Target 频繁断开重连

• 症状:Hyper-V 主机日志看到 “iSCSI target connection lost, attempting reconnect” 每隔几分钟一次
• 原因:90% 是 iSCSI 网口和业务网口接错 VLAN,导致业务突发流量挤爆 iSCSI 链路
• 解决:物理隔离 iSCSI 网络(独立交换机或独立 VLAN),给 iSCSI 网口绑 QoS 优先级(802.1p Class 4)

2.MPIO 路径只显示 1 条

• 症状:MPIO 属性里只能看到一个路径,Round Robin 退化为单路径
• 原因:群晖只暴露了一个 iSCSI IP,或 Hyper-V 只连接了一个 Target Portal
• 解决:在”iSCSI 发起程序”→ “发现” → 添加群晖所有 iSCSI IP → 删除后重新连接 → MPIO 自动发现新路径

3.Reservation Conflict(预留冲突)

• 症状:群晖 LUN 上的 VM 启动报 “The requested operation could not be completed because the storage device is reserved”
• 原因:LUN 同时被两台主机访问,Windows 集群 SCM(Service Control Manager)检测到冲突
• 解决:确认 LUN 已添加到”集群共享卷(CSV)”,而非普通磁盘;只有 CSV 才支持多节点同时访问

4.集群节点掉线”脑裂”风险

• 症状:2 节点集群心跳丢失,两个节点都尝试上线 VM,导致 LUN 同时被两个节点写
• 原因:见证磁盘/见证共享配置错误,集群无法决定谁”活”谁”死”
• 解决:再次检查”文件共享见证”配置,群晖 SMB 共享权限允许集群计算机账户读写;在每台节点用 \群晖IPClusterWitness 路径测试可访问

5.群晖 DSM 升级后 iSCSI 异常

• 症状:DSM 大版本升级(如 6.x → 7.x)后,iSCSI Target 状态变红,Hyper-V 端连接失败
• 原因:DSM 7 改了 LUN 元数据格式(从 ext4 升级到 Btrfs),老 LUN 可能无法被新版本识别
• 解决:升级前在 Hyper-V 端把所有 VM 漂移到单节点,把 LUN 卸载 → DSM 升级 → 重新挂载 LUN;或干脆在 DSM 7 上重新创建 LUN,数据从备份恢复

避坑 6 招:

1. 集群先验证后建——”验证集群”向导发现的警告一定要处理,不要为了省时间跳过
2. iSCSI 流量物理隔离——别为了省钱共用业务交换机,iSCSI 一旦抖动 VM 直接卡顿
3. 见证磁盘/共享必须独立——不能把见证放 iSCSI LUN 上(循环依赖),独立放群晖 SMB 共享或第三方 SMB
4. VM 内存别超节点物理内存 80%——预留 20% 给宿主机+故障转移时 VM 启动内存
5. 定期做故障演练——每季度模拟一次节点宕机,确认 VM 真能漂起来,别等真出事了才发现漂移失败
6. 群晖 Active Backup 备份——Hyper-V 集群的 VM 一定要用 Active Backup 整机备份(参考站内 10037 群晖 ABB 完整教程),有备份才能在 LUN 彻底损坏时恢复

九、与主流方案横评:群晖 iSCSI vs FC-SAN vs S2D vs VMware vSAN

很多企业 IT 负责人问”群晖做超融合后端到底行不行”,下面给一个决策表:

方案	成本	性能上限	可靠性	运维难度
群晖 iSCSI 后端	⭐⭐⭐⭐⭐ 低(2-3 万)	⭐⭐⭐ 中(万兆上限)	⭐⭐⭐ 单点依赖群晖	⭐⭐⭐⭐ 简单
Windows Server S2D(横向存储)	⭐⭐⭐ 中(2-3 台服务器)	⭐⭐⭐ 中(受限于节点数)	⭐⭐⭐⭐ 副本自动恢复	⭐⭐⭐ 需 Windows 集群管理
VMware vSAN	⭐⭐ 极高(订阅费 + 服务器)	⭐⭐⭐⭐⭐ 高	⭐⭐⭐⭐⭐ 业内标杆	⭐⭐⭐ 需 vCenter + vSAN 许可
FC-SAN(光纤存储)	⭐ 极贵(光纤交换机 + HBA)	⭐⭐⭐⭐⭐ 最高	⭐⭐⭐⭐⭐ 企业级	⭐ 复杂(需专业存储工程师)

群晖 iSCSI 适合:50-200 台 VM、预算 5-15 万、运维团队 1-3 人、追求”5 年内不换架构”的中小型企业

群晖 iSCSI 不适合:1000+ VM、对存储延迟 < 1ms 的金融核心交易、超大规模数据库(Oracle RAC / SQL Server FCI 高 I/O 场景)

五问决策树(判断你该选哪个):

1. 你的 VM 数量是? ≤ 200 → 群晖 iSCSI;200-500 → 群晖双机同步 / S2D;500+ → vSAN / FC-SAN
2. 你的预算是? < 15 万 → 群晖;15-50 万 → S2D;50 万+ → vSAN / FC-SAN
3. 你有专业存储工程师吗? 没有 → 群晖(DMS 图形化)或 S2D(Windows 工具链)
4. 你的业务能接受 30s 中断吗? 能 → 群晖;不能 → vSAN/S2D + 应用层 HA(AlwaysOn)
5. 未来 3 年 VM 增长预测? 平稳 → 群晖;翻倍 → 上 S2D/vSAN 留扩展空间

十、发布前必读 + 延伸阅读

本文涉及到的官方文档和延伸阅读,峰哥建议你发布前 5 分钟打开核对一下当前最新版本,避免凭记忆写错命令或路径:

• 微软官方:故障转移集群概述 — MSFC 角色和功能
• 微软官方:Hyper-V 集成服务 — VM 性能调优
• 群晖官方:DSM 7 SAN Manager 用户指南 — iSCSI LUN/Target 配置
• 群晖官方:Btrfs 文件系统 — LUN 文件系统选择
• 微软官方:多路径 I/O (MPIO) 概述 — MPIO 策略详解
• 微软官方:文件共享见证 — 集群仲裁配置
• 站内:ESXi 6.7 导出虚拟机文件夹导入 Hyper-V 完整实战教程 — 跨平台迁移参考
• 站内:群晖 NAS 在企业中的使用技能和教程 — 群晖基础入门
• 站内:群晖 Active Backup for Business 完整实战教程 — Hyper-V VM 备份方案

声明:本文所有命令和操作步骤基于 Windows Server 2022 / DSM 7.x 官方文档 + 实战部署经验总结。具体步骤可能随版本变化,正式部署以微软/群晖官方实时文档为准。涉及产品规格、价格、SAN Manager UI 截图等可能与最新版本有差异,请以官方实时页面为准。