faq_2026-09-27_st_1
title: “iSCSI多路径都配好了为什么磁盘速度还是没有提升” description: “iSCSI 存储双网卡双链路 MPIO 配置完成后读写速度没有变化，多数不是配置做错：多路径的第一目标是链路冗余而非带宽叠加，默认路径策略同一时刻只用一条活动路径。本文讲清什么时候多路径能提速、怎么把策略切到轮询负载均衡，以及验收冗余价值的正确姿势。” slug: iscsi-mpio-no-speedup-reason date: 2026-09-27 categories: [“常见问答”] draft: false
服务器接 iSCSI 存储，特意多插了一块网卡，交换机上也规划了两条独立链路，MPIO 装好、两条路径都认出来了，兴冲冲跑一次测速——速度跟单路径时期几乎没有差别。不少人到这一步开始怀疑配置白做了，甚至把好好的多路径拆掉重来。其实链路多数没问题，是预期放错了位置。
原因分析
先立一个基本认知：多路径（MPIO）的首要目标是冗余，不是提速。它解决的是一条链路故障时业务不断的问题，提速只是特定条件下的附带收益。默认的路径策略里，MRU 类策略会一直沿用当前活动路径，另一条只在故障时顶上；Fixed 类策略固定走首选路径。这两种策略下，同一时刻所有 IO 都挤在一条路上，两条链路当然测不出双倍速度——第二条路径本来就没打算干活，它站的是备用岗。
要真把两条路跑满，需要三个条件同时成立。其一，路径策略切到轮询（RR）一类负载均衡模式，让 IO 轮流分发给多条路径。其二，存储控制器支持双活，同一个 LUN 两个控制器都能主动接管，请求分过去有真算力接。其三，两条路径全程无共享瓶颈——两块网卡各走各的线、各上各的交换机，若在某一层汇到同一个口，分了也是白分。
还有一层容易被忽略：单线程的顺序读写本身就跑不满多路径。一个拷贝任务的请求流基本固定走一条路，测速方法不对，配得再对也显示不出差别。
分步解决
- 先确认路径策略。vSphere 里看 LUN 的路径选择策略是 MRU、Fixed 还是 RR；Windows 下打开 MPIO 属性看 DSM 策略。目标是把适合的 LUN 切到轮询负载均衡。
- 换策略后用并发口径测速。多台虚拟机同时压 IO，或用支持多任务并发的测试工具跑多个作业流，单连接大文件拷贝测不出多路径的带宽聚合。
- 核对存储侧双活。确认该 LUN 的控制器归属模式，两控制器是否都能主动服务这个卷；单控属主的 LUN，路径分过去也只是在控制器内部排队。
- 核对网络侧真隔离。两条路径应分别落在独立的网卡与交换机上，检查是否在某台交换机汇合到同一个上联口，共享上联等于假冗余。
- 别漏验多路径的本职。拔掉一条网线或在交换机上停一个口，业务 IO 应无缝切到另一条路径、应用不中断——这才是这套配置花功夫的价值所在，验收时必做。
- 测速前清干扰。存储缓存、操作系统缓存都会让单次测速虚高或虚低，多次取稳态值再下结论。
预防
上多路径之前，把预期写清楚进方案：冗余是保底目标，提速是有条件增益。路径策略、每条链路的网卡与交换机归属，都应当落到交付文档里，验收环节固定加一项拔线切换测试。期望摆正了，多路径交付完是踏实的安全感，而不是一场误会。