1. 项目缘起:为什么要在Windows Server 2012上折腾iSCSI和MPIO?
如果你正在管理一个中小型企业的IT基础设施,或者负责一个虚拟化平台的存储后端,那么“存储”这个词对你来说,可能既熟悉又充满挑战。熟悉的是,数据总得有个地方放;挑战的是,如何让这个“地方”既快又稳,还不能太贵。几年前,我接手了一个老旧业务系统的迁移项目,原系统跑在几台老旧的物理服务器上,存储是直接挂载的本地硬盘。性能瓶颈和单点故障问题日益突出,但预算又不足以采购全套的商用SAN(存储区域网络)解决方案。正是在这种“既要马儿跑,又要马儿不吃草”的背景下,我把目光投向了 iSCSI 。
iSCSI简单来说,就是让服务器可以通过普通的以太网,像访问本地硬盘一样去访问网络另一端的存储设备。它把存储的“门槛”拉低了一大截,你不需要昂贵的光纤交换机(FC SAN),用现有的千兆甚至万兆以太网就能搭建一个共享存储池。这对于预算有限但又需要集中存储、虚拟机迁移(如Hyper-V Live Migration)或构建故障转移集群的场景,简直是福音。
但问题也随之而来:网络有延迟,网线会松动,网卡可能故障。如果存储流量只走一条网络路径,那么这条路径上的任何一个环节出问题,整个存储连接就会中断,导致上层的应用和服务宕机。这显然违背了我们追求“高可用”的初衷。于是, MPIO(多路径I/O) 技术就登场了。它的核心思想是“不要把鸡蛋放在一个篮子里”。通过为同一个iSCSI存储目标配置多条独立的网络路径(比如,服务器有两块网卡,分别连接到交换机的两个不同端口,再抵达存储设备),MPIO可以实现路径的负载均衡和故障自动切换。一条路堵了或者断了,流量立刻无缝切换到另一条路,上层应用毫无感知。
所以, 在Windows Server 2012上部署基于MPIO的高可用链路iSCSI ,本质上是在用相对低廉的IP网络成本,构建一个具备企业级可靠性和性能的存储网络。这不仅是技术上的优化,更是一种务实的架构设计选择。今天,我就把这个从规划、部署到调优的完整过程,结合我踩过的坑和总结的经验,详细拆解一遍。无论你是初次接触,还是想优化现有环境,这篇内容都能给你提供一条清晰的实操路径。
2. 部署前的核心规划:网络、存储与服务器三位一体
在动手点击“下一步”之前,规划阶段决定了整个项目的成败。很多人部署失败,问题往往不是出在配置步骤,而是最初的架构设计就有缺陷。高可用iSCSI部署,必须同时考虑服务器、网络和存储端三个维度。
2.1 网络架构设计:隔离与冗余是基石
iSCSI流量对网络延迟和丢包非常敏感,因此 强烈建议为iSCSI规划独立的网络 ,至少是独立的VLAN。千万不要让iSCSI流量和员工的日常上网、文件共享、视频会议等流量混在一起。后者的突发流量会严重干扰存储的稳定I/O。
对于高可用链路,你需要至少两条物理上隔离的网络路径。一个典型的最小化冗余设计如下:
- 服务器端 :准备两块专用的物理网卡(NIC1和NIC2)。如果服务器是虚拟机,则需要配置两块独立的虚拟网卡,并分别绑定到宿主物理机两块不同的物理网卡上。
- 网络设备端 :需要两台物理交换机(Switch A和Switch B)。这是实现真正物理冗余的关键。如果只有一台交换机,即使服务器连了多个端口,交换机本身故障仍会导致全部路径中断。
-
连接方式
:
- 服务器NIC1连接至Switch A。
- 服务器NIC2连接至Switch B。
- 你的iSCSI存储设备(可能是一台Windows Server做的iSCSI Target,或是专业的NAS/SAN)也需要至少两个网络接口,分别连接到Switch A和Switch B。
这样,就形成了“服务器 -> 交换机A -> 存储”和“服务器 -> 交换机B -> 存储”两条完全独立的物理路径。交换机之间 不要 为iSCSI VLAN做链路聚合或堆叠,保持它们的独立性,避免故障域扩散。
注意 :很多教程会教你在单台交换机上划多个VLAN或用端口隔离来模拟多路径,这在学习测试中可以,但生产环境绝对不行。真正的冗余必须消除单点故障,而单台交换机本身就是最大的单点。
2.2 存储端准备:明确你的iSCSI Target
iSCSI架构中有两个角色: Initiator(启动器) 和 Target(目标) 。我们的Windows Server 2012将作为Initiator,去连接存储端提供的Target。存储端可以是:
- 专业的存储设备 :如Dell EMC、NetApp、Synology、QNAP等NAS/SAN,它们通常有友好的管理界面来创建iSCSI Target和LUN(逻辑单元号)。
- Windows Server自身 :Windows Server 2012及更高版本内置了“iSCSI目标服务器”角色,可以在一台服务器上创建虚拟磁盘(VHD/VHDX)并将其作为Target共享给其他服务器。这非常适合测试或小型环境。
在规划时,你需要从存储端管理员那里获取以下关键信息:
-
Target名称
:例如
iqn.2024-08.com.example:storage.target01。 -
Target的IP地址
:通常有两个,分别对应存储设备连接Switch A和Switch B的端口IP。例如
192.168.10.100和192.168.20.100。 - 认证信息 :如果启用了CHAP认证,需要获取用户名和密码。
- LUN信息 :准备映射给这台服务器的LUN编号和大小。
2.3 服务器端准备:IP配置与功能确认
在我们要部署MPIO的Windows Server 2012服务器上,需要进行如下准备:
-
配置网络
:为那两块专用网卡配置IP地址。它们需要和存储端对应端口的IP在同一网段,但属于不同子网,以实现路径隔离。
-
NIC1 (连接Switch A): IP:
192.168.10.10, 掩码:255.255.255.0, 网关: 留空 (iSCSI专用网络通常不设网关)。 -
NIC2 (连接Switch B): IP:
192.168.20.10, 掩码:255.255.255.0, 网关: 留空 。 - 禁用NetBIOS :在这两块网卡的“高级TCP/IP设置”中,切换到“WINS”选项卡,选择“禁用TCP/IP上的NetBIOS”。这可以减少不必要的广播流量。
- 关闭IPv6 :如果确定环境不用,可以在网卡属性中取消勾选“Internet协议版本6(TCP/IPv6)”,简化配置。
-
NIC1 (连接Switch A): IP:
- 安装MPIO功能 :Windows Server 2012默认可能未安装MPIO。打开“服务器管理器”,点击“添加角色和功能”,在“功能”列表中勾选“ 多路径I/O ”,然后完成安装。安装后需要重启服务器。
- 安装iSCSI发起程序 :这个功能通常默认已安装。可以在“服务器管理器”的“工具”菜单中查找“iSCSI发起程序”,如果找不到,同样通过“添加角色和功能”来安装“iSCSI发起程序”功能。
3. 配置iSCSI连接:建立初始存储通道
规划好之后,我们开始进行实际的连接配置。这一步的目标是让服务器能通过至少一条路径看到存储设备提供的磁盘。
3.1 发现并连接iSCSI Target
- 打开“iSCSI发起程序”(可以在开始屏幕搜索或从服务器管理器工具菜单打开)。首次打开会提示启动服务,点击“是”。
-
在“目标”选项卡的“快速连接”或“发现”中,输入存储端
其中一个
IP地址(例如
192.168.10.100),点击“快速连接”。 - 如果连接成功,下方“已发现的目标”列表中会出现你的Target名称,状态为“非活动”。选中它,点击“连接”。
- 在弹出的连接窗口中, 务必勾选“启用多路径” 。然后点击“高级”。
-
在高级设置中:
- “本地适配器”选择“Microsoft iSCSI Initiator”。
-
“发起程序IP”选择当前用来连接的网卡IP(
192.168.10.10)。 -
“目标门户IP”确认是存储端对应端口的IP(
192.168.10.100)。 - 如果存储端启用了CHAP认证,在此处配置。
- 点击“确定”完成第一条路径的连接。
此时,你通过第一条路径(
192.168.10.10
->
192.168.10.100
)连接上了Target。但任务只完成了一半,磁盘虽然可见,但路径是单点的。
3.2 验证磁盘并初始化
连接Target后,打开“磁盘管理”(
diskmgmt.msc
),你应该会看到一个新的未知磁盘,显示为“未初始化”。
- 右键点击该磁盘,选择“初始化磁盘”。选择分区样式(MBR或GPT,对于大于2TB的磁盘必须选GPT)。
- 初始化后,磁盘变为“联机”状态,你可以像操作本地磁盘一样,新建简单卷、格式化并分配盘符。
重要提醒
:到此为止,你只是用单条路径挂载了网络磁盘。如果此时
192.168.10.0/24
网络出现问题,磁盘就会脱机。我们的高可用目标尚未实现。
4. 配置MPIO:将单路变为双路高可用
这是实现高可用的核心步骤。MPIO会将我们添加的两条物理路径,识别为访问同一个LUN的不同路径,并进行管理。
4.1 添加第二条路径
- 回到“iSCSI发起程序”的“目标”选项卡,在“已发现的目标”列表中,再次选中你的Target,点击“连接”。
- 同样勾选“启用多路径”,点击“高级”。
-
这次,在高级设置中:
- “本地适配器”依然选择“Microsoft iSCSI Initiator”。
-
“发起程序IP”
选择另一块网卡的IP
(
192.168.20.10)。 -
“目标门户IP”输入存储端
另一个端口的IP
(
192.168.20.100)。 - 点击“确定”完成连接。
现在,你为同一个Target建立了两条独立的连接。但MPIO还不知道如何管理它们。
4.2 在MPIO中配置多路径策略
-
打开“MPIO”配置工具(在服务器管理器工具菜单中,或运行
mpiocpl)。 - 切换到“ 发现多路径 ”选项卡,勾选“ 添加对iSCSI设备的支持 ”,点击“添加”,然后重启服务器。这一步是让MPIO驱动能够识别iSCSI设备。
- 重启后,再次打开“MPIO”工具,切换到“ MPIO设备 ”选项卡。
- 点击“添加”,系统会自动列出支持MPIO的磁盘设备。你应该能看到一个设备,其硬件ID包含你的iSCSI Target信息。选中它添加。
- 添加后,在MPIO设备列表中选中该设备,点击“ 设备详细信息 ”。在这里,你将看到至关重要的信息: 路径列表 。你应该能看到两条路径,分别对应之前配置的两个发起程序IP和目标门户IP的组合。每条路径都有其状态(活动/待机/故障等)。
4.3 配置负载均衡策略
在“设备详细信息”窗口,点击“ MPIO ”选项卡。这里可以配置该设备的负载均衡策略。Windows Server MPIO 提供了几种策略:
- 故障转移 :只有一条主路径是活动的,其他路径处于待机状态。仅当主路径故障时,才切换到备用路径。 不提供负载均衡 。
- 轮询 :所有活动路径被循环使用,I/O请求依次分发到各条路径。这是最常用的 负载均衡 策略。
- 子集轮询 :一组路径活动,另一组待机。活动组内轮询,活动组故障则切换到待机组。
- 最少队列深度 :将I/O请求发送到当前未处理请求最少的路径。
- 加权路径 :根据管理员设置的权重分配I/O。
对于两条对等路径的高可用环境, “轮询” 策略通常是最佳选择,它能同时利用两条链路的带宽。选择“轮询”,点击“应用”。
配置完成后,你可以通过“磁盘管理”或使用
mpclaim
命令行工具来查看路径状态。一个健康的配置应该显示两条路径均为“活动”状态。
5. 验证、测试与性能调优
配置完成不等于万事大吉。必须进行严格的验证和测试,确保高可用机制真的生效。
5.1 基础连通性与路径验证
- Ping测试 :从服务器分别用两个IP去Ping存储端的两个IP,确保基础网络连通性。
-
路径状态验证
:在“MPIO”工具的“设备详细信息”中,确认两条路径均为“活动”。你也可以在PowerShell中使用命令
Get-MSDSMGlobalDefaultLoadBalancePolicy查看全局策略,用mpclaim -s -d查看具体设备路径信息。 -
磁盘压力测试
:使用工具如
diskspd(微软官方磁盘性能测试工具)或CrystalDiskMark,对挂载的iSCSI磁盘进行读写测试。同时,在任务管理器的“性能”选项卡中观察两块iSCSI网卡的网络利用率。在“轮询”策略下,你应该能看到两块网卡都有流量波动,说明负载均衡正在工作。
5.2 故障转移测试(核心验证)
这是最关键的一步,模拟路径故障,看业务是否中断。
-
模拟网络断开
:在服务器上,禁用其中一块iSCSI网卡(例如连接
192.168.10.0/24的网卡)。或者更安全一点,在对应的交换机上关闭连接服务器的端口。 -
观察现象
:
- 立即打开“MPIO”工具查看设备路径详情,你会发现被禁用网卡对应的路径状态会变为“故障”或“禁用”,而另一条路径依然保持“活动”。
- 在“磁盘管理”中, 该iSCSI磁盘应该始终保持“联机”状态,没有任何脱机或丢失的提示 。
- 尝试向该磁盘复制一个大文件,操作应该能继续进行,只是速度可能会因为只剩一条路径而下降。
- 恢复测试 :重新启用网卡或打开交换机端口。观察路径是否自动恢复为“活动”状态,流量是否重新开始在两卡间均衡。
如果以上测试全部通过,恭喜你,一个真正的高可用iSCSI存储链路已经部署成功。
5.3 性能调优与高级设置
为了让性能更好,还可以进行一些调优:
- Jumbo Frame(巨帧) :如果你的网络设备(交换机、网卡、存储)都支持,启用Jumbo Frame(通常设置为9000字节)可以显著降低CPU开销并提升大块数据连续读写的吞吐量。 务必确保路径上所有设备MTU设置一致 ,否则会导致网络问题。
-
网卡高级设置
:在iSCSI专用网卡的属性中,可以考虑:
- 禁用流量控制 。
- 将“中断节流率”或“中断 moderation”调整为“低延迟”或直接禁用(取决于具体网卡驱动和型号)。
- 禁用诸如“大量发送卸载(IPv4)”等可能在某些场景下引起问题的特性(需实测)。
-
MPIO注册表调优
:对于高级用户,可以通过注册表调整MPIO的超时和重试参数。例如,
PathRecoveryInterval(路径恢复间隔)和RetryCount(重试次数)。 修改注册表有风险,请务必在测试环境验证并备份注册表 。 - 使用专用iSCSI HBA卡 :对于性能要求极高的生产环境,可以考虑购买支持TOE(TCP卸载引擎)的iSCSI HBA卡。它能将iSCSI协议处理任务从服务器CPU卸载到网卡专用芯片上,大幅提升性能并降低CPU占用。
6. 生产环境部署的深度踩坑实录
理论步骤总是清晰的,但现实环境往往复杂得多。下面分享几个我在实际部署中遇到的典型问题和解决方案,这些在官方手册里可不容易找到。
6.1 坑一:MPIO配置后磁盘在集群中显示为“重复磁盘”
场景 :在配置了MPIO的Windows Server上,将iSCSI磁盘添加到故障转移集群(Failover Cluster)时,集群验证报告或磁盘管理中出现“重复磁盘”警告,即集群看到了两个签名相同的磁盘。
根因分析 :这个问题非常经典。在没有MPIO时,服务器通过一条路径看到一块磁盘,操作系统给它一个唯一的磁盘标识符(Signature/UniqueId)。当你添加第二条路径时,MPIO驱动需要正确地将两条路径识别为指向 同一块物理磁盘 。如果MPIO配置不正确,或者操作系统在两条路径完全就绪前就初始化了磁盘,可能导致磁盘的“即插即用”机制为每条路径上的“同一个磁盘”分配了不同的临时标识,从而被误认为是两块磁盘。
排查与解决过程 :
- 首先,切勿在集群中强制导入“重复磁盘” ,这会导致数据损坏。
-
在每一台需要连接该共享磁盘的集群节点服务器上,执行以下操作:
a. 打开“磁盘管理”,确保只通过
一条
路径使磁盘联机(如果有多条,先断开其他路径)。
b. 如果磁盘已初始化并有数据,请确保其处于“联机”状态。如果是新磁盘,将其初始化并格式化为NTFS(不要分配盘符)。
c. 打开PowerShell(管理员身份),运行以下命令,获取该磁盘的唯一ID:
记录下Get-Disk | Where-Object {$_.BusType -eq 'iSCSI'} | Format-List Number, FriendlyName, SerialNumber, UniqueIdUniqueId,它应该是一个很长的包含SCSI标识的字符串。 - 关键步骤 :在每一台节点服务器上,确保MPIO已正确安装且为该磁盘设备配置了多路径(参考第4章)。然后,在“MPIO”配置工具的“MPIO设备”列表中,确认该磁盘设备存在,并且其硬件ID与你记录的UniqueId有对应关系。
- 在所有节点上完成上述操作后,回到集群管理器。刷新可用磁盘列表,此时应该只看到一个候选磁盘,而不再是重复的。这是因为所有节点都通过MPIO,基于相同的UniqueId识别到了同一块物理磁盘。
实操心得 :这个问题经常出现在跨节点配置不一致时。一个最佳实践是,在将磁盘引入集群之前,先在单个节点上完成所有的MPIO配置和路径测试,并记录下磁盘的UniqueId。然后在其他节点上,先配置好网络和MPIO支持,再连接Target,系统会自动识别并匹配到正确的磁盘,从而避免“重复磁盘”的出现。
6.2 坑二:路径状态频繁在“活动”与“待机”间跳动
场景 :配置了“轮询”策略,但观察MPIO设备详细信息时,发现某条路径的状态不稳定,时而“活动”,时而“待机”,甚至“故障”。网络Ping测试却是通的。
根因分析 :这通常不是MPIO本身的问题,而是 路径质量 问题。iSCSI对延迟和丢包极其敏感。虽然物理链路是通的,但如果延迟过高(例如超过几毫秒的波动)或存在间歇性丢包,MPIO的路径检测机制(通过发送SCSI命令检测)可能会认为该路径“不健康”,从而将其降级。
排查与解决过程 :
-
排除基础网络问题
:使用
ping -t <存储IP>进行持续ping测试,观察是否有丢包或延迟激增(time值突然变大)。同时,检查交换机的端口计数器,是否有CRC错误、巨帧错误等。 -
检查MTU一致性
:这是巨坑!如果服务器、交换机、存储端任何一端的Jumbo Frame设置不一致,会导致大数据包被分片或丢弃,引发间歇性问题。在服务器和存储端分别用
ping -f -l 8972 <对端IP>命令测试(8972是9000字节MTU减去IP和ICMP头后的数据大小)。如果提示“需要拆分数据包但是设置 DF”,说明路径上存在MTU小于9000的设备。 -
调整MPIO路径验证参数
:如果网络质量确实无法优化(如跨机房长距离),可以尝试调整MPIO的路径检测敏感度。通过修改注册表:
-
路径:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\msdsm\Parameters -
新建或修改DWORD值:
PathVerifyEnabled设置为0(禁用周期性路径验证,依赖底层链路状态)。 注意:这会将故障检测责任交给网络层,请谨慎评估 。 -
修改
PathRecoveryInterval(默认值10秒),增加此值可以给不稳定的路径更长的恢复时间,避免频繁切换。
-
路径:
- 检查存储端性能 :存储设备本身的处理能力不足、缓存用尽或硬盘队列过长,也会导致响应超时,被MPIO误判为路径故障。观察存储设备的管理界面,查看CPU、内存、缓存和LUN的延迟指标。
6.3 坑三:启用MPIO后,磁盘性能反而下降
场景 :单路径时磁盘IO表现正常,启用MPIO和“轮询”负载均衡后,使用IOMeter或Diskspd测试,发现随机读写IOPS不升反降,延迟增高。
根因分析 :这通常与 队列深度(Queue Depth) 和 负载均衡策略的适用场景 有关。
- 队列深度 :每个SCSI路径都有其队列深度限制。当使用“轮询”策略时,I/O请求被分散到两条路径。如果单个I/O请求本身很大,或者应用发出的队列深度很低,那么分散到单条路径上的队列深度可能变得更小,无法充分“压满”存储设备,导致聚合性能反而低于单一路径饱和的情况。
- 策略不匹配 :“轮询”策略对顺序大块读写(如视频编辑、备份)的带宽提升效果明显,因为可以聚合两条链路的带宽。但对于高随机、小块的IO(如数据库事务日志),路径切换本身会引入微小的开销,如果存储端处理能力不是瓶颈,可能看不到提升甚至略有下降。
排查与优化 :
- 测试不同策略 :在MPIO设备详细信息的“MPIO”选项卡中,将负载均衡策略临时改为“ 故障转移 ”或“ 最少队列深度 ”,重新进行性能测试。对比“轮询”策略下的结果。
- 调整应用I/O模式 :在性能测试工具中,尝试增加队列深度(例如从默认的1或8增加到32、64)。观察在更高队列深度下,“轮询”策略的聚合性能是否能够超越单路径。
- 评估实际工作负载 :分析你的生产应用是顺序密集型还是随机密集型。对于SQL Server的Data File,随机IO多,“轮询”或“最少队列深度”可能更优;对于Log File,是顺序写,“轮询”能有效聚合带宽。
- 考虑使用第三方DSM :Windows自带的MPIO DSM(设备特定模块)是通用型的。一些专业的存储厂商(如Dell、HPE)会提供自己优化的DSM,能实现更智能的、基于存储阵列特性的负载均衡。如果存储设备厂商提供了DSM,安装它可能会获得更好的性能。
7. 将iSCSI磁盘用于Hyper-V或故障转移集群
部署高可用iSCSI存储的最终目的,往往是为了支撑上层的虚拟化或高可用应用。这里以Hyper-V和故障转移集群为例,说明集成时的关键点。
7.1 为Hyper-V提供共享存储
Hyper-V的实时迁移(Live Migration)和故障转移(Failover)功能,要求虚拟机文件(VHDX)存放在所有Hyper-V主机都能访问的共享存储上。我们刚配置好的MPIO iSCSI磁盘完美符合要求。
- 在所有需要加入集群的Hyper-V主机上,重复第2至第5章的所有步骤,确保每台主机都能通过MPIO看到 同一块 iSCSI磁盘,并且路径状态健康。
- 在其中一台主机上,打开“磁盘管理”,在该iSCSI磁盘上创建卷、格式化(NTFS)、分配一个盘符(例如S:)。
- 在其他主机上,打开“磁盘管理”,你会看到同一块磁盘显示为“脱机”。这是因为Windows防止多台服务器同时写入同一块非集群磁盘导致数据损坏。 这是正常现象,不要将其联机!
- 接下来,你需要在这块共享磁盘上创建故障转移集群,或者直接将其配置为Hyper-V的SMB 3.0共享存储(另一种方式)。对于传统方式,先创建集群,集群服务会以受控的方式将磁盘联机并管理其所有权。
7.2 创建Windows故障转移集群
- 在所有节点服务器上,安装“故障转移集群”功能。
- 使用“故障转移集群管理器”,运行“验证配置”向导,将所有节点和共享磁盘(iSCSI磁盘)添加进去进行验证。验证报告会检查网络、存储等所有配置是否符合集群要求。 必须全部通过,尤其是存储部分的测试 。
- 验证通过后,运行“创建集群”向导。集群创建成功后,在“存储 -> 磁盘”中,你应该能看到我们配置的iSCSI磁盘。它的状态应该是“已就绪”,所有者是当前的主节点。
- 右键点击该磁盘,选择“添加到群集共享卷(CSV)”。CSV是集群中所有节点都能同时读写的一种卷,特别适合存放Hyper-V虚拟机文件或Scale-Out文件服务器数据。
- 现在,你可以在CSV上创建文件夹,并将其作为Hyper-V虚拟机的存储路径。当一台主机故障时,集群会自动将虚拟机所有权及其存储访问权转移到另一台健康的主机,实现业务高可用。
关键检查点 :在集群环境中,务必使用集群管理器来管理共享磁盘的联机/脱机,不要直接在磁盘管理中进行操作。同时,确保所有节点的MPIO配置、iSCSI发起程序配置完全一致,包括CHAP密码等细节,任何不一致都可能导致某个节点无法访问磁盘,引发集群故障。

150

被折叠的 条评论
为什么被折叠?



