多路径存储故障切换延迟影响高可用，分析dm-multipath配置与路径健康检测优化方案的要点与经验分享

一、多路径存储故障切换延迟为啥影响高可用

咱们先从一个真实的运维场景说起：某电商大促期间，用户突然反映下单页面加载特别慢，甚至提交订单失败。运维排查后发现，是连接存储的一条光纤线路断了，系统切换到备用路径用了将近10秒，刚好卡在大促的流量峰值，导致部分订单请求超时。

其实这种场景在很多企业里都发生过，核心问题就是多路径存储的故障切换延迟太高，拖垮了系统的高可用能力。多路径存储的作用，简单说就是给服务器和存储之间搭多条“路”，哪怕一条路断了，系统能立刻切到别的路，保证数据访问不中断。但如果切换太慢，相当于中间“堵车”时间太长，系统就会出问题。

高可用的核心要求是“业务不中断、响应不超时”，切换延迟一旦超过业务能容忍的阈值，比如大促要求响应时间不超过1秒，那切换延迟10秒就直接突破了这个阈值，导致业务故障。所以搞懂多路径的配置和路径检测优化，是保障系统高可用的关键。

二、dm-multipath的核心配置要点

dm-multipath是Linux系统里专门用来做多路径管理的工具，它能把多条通往同一存储的路径，虚拟成一个逻辑设备，让上层系统不用管底层有多少条路，只需要访问这个虚拟设备就行。要让它工作得好，配置是基础，核心要点有这几个。

2.1 配置文件的核心参数

dm-multipath的配置文件一般在/etc/multipath.conf，里面有几个关键参数必须配置对，不然要么路径识别错，要么切换慢。比如wwid（全球唯一标识），每个存储设备都有自己的wwid，相当于身份证，dm-multipath靠这个来识别哪些路径属于同一个存储。

举个例子，咱们先看一个完整的配置示例，技术栈是Linux CentOS 7，所有配置都在multipath.conf里：

# 配置文件路径：/etc/multipath.conf
# 全局配置块
defaults {
    user_friendly_names yes  # 给多路径设备起友好名字，比如mpatha，而不是一串数字
    find_multipaths yes     # 自动识别多路径设备，不用手动加wwid
    path_grouping_policy multibus  # 路径分组策略，所有路径分一组，适合大部分场景
    failback immediate      # 故障恢复后立刻切回原来的路径，不用等
    no_path_retry 5         # 所有路径都断了的话，重试5次后再报错
}
# 存储厂商特定配置块，比如华为存储
devices {
    device {
        vendor "HUAWEI"    # 存储厂商名称，要和存储的实际信息一致
        product "OceanStor" # 存储产品型号
        path_grouping_policy multibus  # 针对该存储的路径分组策略
        path_checker tur     # 路径检测方式，tur是发送测试单元就绪命令，适合大部分存储
        rr_weight uniform    # 轮询权重，所有路径权重一样，平均分配流量
        rr_min_io 100        # 轮询切换的最小IO数，每100个IO切一次路径
    }
}

这里要注意，vendor和product的取值，必须和存储实际上报的一致，不然dm-multipath识别不到对应的设备。怎么查呢？可以用这个命令：

# 查看存储设备的厂商和产品信息
lsblk -o NAME,VENDOR,MOUNTPOINT

如果配置错了，比如把HUAWEI写成HUAWEI，少了个空格，dm-multipath就会用默认的通用配置，可能导致路径检测不及时。

2.2 路径分组策略的选择

路径分组策略是dm-multipath配置里很重要的一点，不同的策略适合不同的场景，选错了会直接影响切换效率。常见的策略有两种： 第一种是multibus，也就是所有路径分在一个组里，所有路径都能用来传数据，故障了直接切到同组的其他路径，这种适合大部分场景，配置简单，切换快。 第二种是group_by_prio，按优先级分组，高优先级的组先工作，低优先级的组备用，比如主路径组优先级10，备用组优先级5，主路径断了切到备用组，这种适合需要主备区分的场景，比如有的路径带宽不一样，主路径用高带宽的，备用用低带宽的。

举个例子，如果是主备场景，配置就可以改成这样：

# 路径分组策略改为按优先级分组
path_grouping_policy group_by_prio
prio alua  # 优先级计算方式，alua是主动/被动存储常用的

这里的prio参数决定了路径的优先级，alua会自动识别存储的主动路径和被动路径，把主动路径分在高优先级组，被动路径分在低优先级组，这样平时用主动路径，故障了切被动路径。

2.3 路径检测方式的选择

路径检测是dm-multipath判断路径好坏的方式，选对了才能及时发现故障，选不对要么误判路径故障，要么发现不及时。常见的检测方式有三种： 第一种是tur，也就是发送测试单元就绪命令，存储收到后会返回正常或故障，这种方式简单，对存储的负载小，适合大部分场景，是默认的检测方式。 第二种是readio，也就是读指定的扇区，比如读路径的第一个扇区，如果能读到就正常，读不到就故障，这种方式比tur更准确，但会增加存储的负载，适合对路径检测准确性要求高的场景。 第三种是none，也就是不检测路径，这种方式一般不用，除非是特殊的存储设备。

比如如果存储支持tur，就用tur，要是存储不支持tur，或者需要更准确的检测，就用readio，配置如下：

# 路径检测方式改为readio
path_checker readio

这里要注意，不同的存储支持的检测方式不一样，要根据存储的说明来选，不然会导致路径检测失效。

三、路径健康检测的优化方案

配置只是基础，要让故障切换更快，还要优化路径健康检测的机制，让系统能更快发现故障，更快切换路径。

3.1 调整检测频率和超时时间

路径检测的频率和超时时间直接影响故障发现的速度，频率太高会增加存储的负载，频率太低会发现故障慢，超时时间太长会导致故障切换慢。

比如默认的检测频率是10秒，超时时间是5秒，那系统要10秒才能检测一次路径，要是路径断了，可能要10秒才能发现，再加上切换的时间，总延迟就会很高。如果把检测频率改成2秒，超时时间改成1秒，那系统2秒就能检测一次，能更快发现故障。

配置示例如下：

# 调整路径检测频率和超时时间
path_checker tur
polling_interval 2  # 检测间隔，单位是秒，默认是10
path_timeout 1       # 路径检测的超时时间，单位是秒，默认是5

这里要注意，检测频率不能太低，比如改成0.1秒，会导致系统频繁发送检测命令，增加存储的负载，甚至影响正常的IO。一般建议检测频率在1-5秒之间，根据业务的容忍度来调整。

3.2 故障切换的触发机制优化

默认的dm-multipath切换机制是，当检测到路径故障后，会把故障路径从活跃路径里移除，然后把流量切到其他路径。但默认的机制可能会有延迟，比如要等几次检测失败才会切换，这样会增加切换的时间。

可以通过配置no_path_retry和rr_min_io来优化切换触发机制，比如no_path_retry设为1，也就是只要检测到路径故障，立刻切换，不用重试；rr_min_io设为1，也就是每1个IO就检查一次路径状态，这样能更快发现故障。

配置示例如下：

# 优化故障切换触发机制
no_path_retry 1  # 路径故障后，重试1次就切换
rr_min_io 1       # 每1个IO检查一次路径状态

这里要注意，no_path_retry设为1会导致系统对路径故障更敏感，可能会因为网络波动导致误切换，所以要结合实际的网络情况来调整，如果网络比较稳定，就可以设低一点，如果网络波动大，就设高一点。

3.3 故障恢复的切换机制优化

故障恢复后，系统会切回原来的路径，默认的机制是等一段时间再切回，比如等10秒，这样会导致故障恢复后的路径利用率低，也会增加切换的延迟。

可以通过配置failback参数来优化故障恢复的切换机制，failback设为immediate，也就是故障恢复后立刻切回原来的路径，不用等；failback设为manual，也就是手动切回，适合需要人工确认的场景。

配置示例如下：

# 优化故障恢复切换机制
failback immediate  # 故障恢复后立刻切回

这里要注意，如果原来的路径是高带宽的，故障恢复后立刻切回能提高路径的利用率，要是原来的路径带宽和备用路径一样，就可以设为manual，减少切换的次数。

四、应用场景、优缺点与注意事项

4.1 应用场景

dm-multipath和路径检测优化的方案，适合大部分需要高可用的存储场景，比如： 第一是企业级服务器集群，比如数据库集群、应用服务器集群，这些场景需要数据访问不中断，切换延迟低； 第二是虚拟化平台，比如KVM、VMware，虚拟化平台的存储需要高可用，不然虚拟机无法正常运行； 第三是大数据平台，比如Hadoop、Spark，大数据平台的存储需要大量的IO，多路径能提高IO的效率，同时保障高可用； 第四是灾备场景，比如主备存储，主存储故障后能快速切到备用存储，保障业务不中断。

4.2 技术优缺点

优点方面，首先是开源免费，dm-multipath是Linux系统自带的工具，不用额外付费，成本低；其次是配置灵活，能根据不同的场景调整配置，满足不同的需求；第三是兼容性好，支持大部分的存储设备，比如光纤存储、iSCSI存储、FC存储等；第四是能提高IO的效率，多路径能同时传数据，提高IO的吞吐量。

缺点方面，首先是配置复杂，需要对dm-multipath的参数有深入的了解，配置错了会导致路径识别错、切换慢等问题；其次是对运维人员的要求高，需要运维人员能快速排查多路径的故障，比如路径识别错、路径检测失效等；第三是不同的存储设备的配置不一样，需要根据存储的说明来调整配置，增加了配置的难度；第四是如果配置不当，会导致误切换，比如网络波动导致路径误判为故障，切换到其他路径，影响业务的正常运行。

4.3 注意事项

第一是配置前要备份配置文件，修改配置前先备份/etc/multipath.conf，万一配置错了能恢复； 第二是配置后要验证路径状态，用multipath -ll命令查看路径的状态，确保路径识别正确，检测方式正常； 第三是要结合业务的容忍度调整参数，比如大促期间业务容忍度低，就把检测频率调低点，切换触发机制调灵敏点，平时业务容忍度高，就调高点，减少误切换； 第四是要定期检查路径的状态，比如每天用multipath -ll命令查看路径的状态，确保路径正常； 第五是要结合存储的说明调整配置，比如有的存储支持tur，有的不支持，要根据存储的说明来选检测方式； 第六是要测试故障切换的延迟，比如模拟路径故障，用命令查看切换的时间，确保切换延迟在业务的容忍范围内。

五、经验分享与文章总结

5.1 经验分享

我在之前的运维工作中，遇到过很多多路径的问题，比如有一次，某客户的数据库服务器，因为路径检测频率太高，导致存储的负载太高，影响了数据库的性能，后来把检测频率从1秒改成了3秒，问题就解决了；还有一次，某客户的虚拟化平台，因为配置错了vendor和product，导致dm-multipath识别不到路径，后来查了存储的信息，修改了vendor和product，问题就解决了；还有一次，某客户的灾备场景，因为failback设为了manual，故障恢复后没有切回主路径，导致主路径的利用率低，后来改成了immediate，问题就解决了。

总结下来，有几个经验：第一是配置要从实际出发，不要盲目照搬别人的配置，要根据自己的业务、存储、网络情况来调整；第二是要多测试，配置后要测试路径识别、路径检测、故障切换等功能，确保正常；第三是要多学习，了解dm-multipath的参数、存储的特性、网络的情况，才能更好的配置和优化；第四是要做好监控，监控路径的状态、切换的延迟、存储的负载等，及时发现问题。

5.2 文章总结

多路径存储的故障切换延迟是影响高可用的关键因素，dm-multipath的配置和路径健康检测的优化是解决这个问题的核心。要做好dm-multipath的配置，要掌握核心参数、路径分组策略、路径检测方式的选择；要做好路径健康检测的优化，要调整检测频率和超时时间、优化故障切换和恢复的触发机制；要结合应用场景、优缺点、注意事项来调整配置，确保系统的高可用。

通过合理的配置和优化，能把故障切换延迟降到业务能容忍的范围内，保障系统的高可用，避免业务故障的发生。