Oracle RAC集群存储链路冗余如何设计？多路径配置与故障切换实战解析

搭建Oracle RAC集群时，大多数注意力都放在数据库参数、网格基础设施和私网心跳上，存储链路这一层却经常被草草带过。不少生产环境的RAC节点只配置了一条存储路径，表面看运行正常，一旦光纤线松动、交换机端口故障或者HBA卡损坏，节点会瞬间丢失对共享存储的访问，CRS判定节点异常后触发节点驱逐，整个业务被迫切换，严重的甚至造成脑裂后集群重启。本文从存储链路冗余的必要性讲起，给出多路径配置的完整落地过程，并说明如何验证故障切换是否真正生效。

为什么RAC环境必须做存储链路冗余

RAC的核心价值是高可用，而高可用是一个整体，任何单点都会把前面做的努力全部抵消。存储链路是从数据库服务器到共享存储的完整IO通路，包含HBA卡、光纤线、存储交换机、存储控制器这几个环节。只要其中任意一个环节只有一份，这条链路就是单点故障。

单链路存储在RAC中的风险比单机数据库大得多。原因在于CRS的磁盘心跳依赖共享存储上的投票盘，当节点在IO超时时间内无法访问投票盘，节点会被判定为失联，触发驱逐机制。驱逐发生后实例重启、服务切换，业务会感受到明显的抖动。如果所有节点同时丢失存储访问，还可能出现集群整体重启的情况。所以在RAC的体系里，存储链路冗余不是可选项，而是和私网冗余同等级别的必备项。

理想的冗余设计是：每台数据库服务器至少配两块HBA卡，分别连接两台独立的存储交换机，存储侧使用两个控制器，两个控制器分别上联到两台交换机。这样任何一个环节故障，都只损失一条路径，IO流量自动走剩下的路径，业务无感知。

多路径技术的原理与ASM冗余的关系

配置了多条物理路径之后，操作系统默认会把每条路径识别成独立的块设备，比如同一块LUN可能同时表现为/dev/sdb和/dev/sdc。如果不对这些设备做聚合，数据库根本无法使用，因为通过两个设备名写入同一块LUN会造成数据混乱。多路径软件的作用就是在内核层面把这些指向同一LUN的设备聚合成一个虚拟设备，由多路径层负责路径选择和故障切换。

Linux平台最常用的是device-mapper-multipath。它在SCSI层工作，向RAC暴露一个统一的设备，比如/dev/mapper/ocrdisk01，内部维护活动路径和备用路径。路径策略一般选round-robin让所有活动路径分担负载，也可以为关键盘配置主备模式。

需要特别说明的是，多路径冗余和ASM的冗余是两个不同层面的事情。多路径解决的是访问链路层面的高可用，ASM的normal冗余解决的是数据块层面的镜像。两者不能互相替代：只有多路径没有ASM冗余，存储盘柜损坏数据照样丢；只有ASM冗余没有多路径，一根光纤故障节点照样可能被驱逐。生产环境标准做法是两层都做，并且用ASM的failure group把镜像副本分布在不同存储控制器对应的LUN上。

Multipath配置与ASM磁盘绑定的完整步骤

先安装多路径软件包并确认服务开机自启：

yum install device-mapper-multipath
systemctl enable --now multipathd

核心配置文件为/etc/multipath.conf。下面给出一份适合RAC的参考配置，关键点是关闭user_friendly_names让设备名基于wwid稳定生成，同时设置find_multipaths避免误聚合本地系统盘：

defaults {
    user_friendly_names no
    find_multipaths yes
    path_selector "round-robin 0"
    path_grouping_policy multibus
    path_checker tur
    no_path_retry 18
    failback immediate
}

blacklist {
    devnode "^sd[a-z]$"
    devnode "^(ram|raw|loop|fd|sr|dm-)[0-9]*"
}

其中no_path_retry 18表示所有路径都失败时 multipath会重试18次（默认间隔约1秒），给存储侧故障恢复留出缓冲时间，这个值需要结合ASM的disk_repair_time和存储切换速度综合调整，不宜设置过小。配置完成后执行multipath -v2重新扫描，用multipath -ll查看聚合结果，确认每个共享LUN对应一个聚合设备且状态为active。

接下来要通过udev规则把聚合设备固定权限，供ASM使用。先获取磁盘的wwid：

multipath -ll | grep -i wwid
# 假设ocr盘的wwid为 3600a0980383036346b5b4d4464776f72

vi /etc/udev/rules.d/99-oracle-asmdevices.rules
KERNEL=="dm-*", ENV{DM_UUID=="mpath-3600a0980383036346b5b4d4464776f72", \
  OWNER="grid", GROUP="asmadmin", MODE="0660"

udevadm control --reload-rules
udevadm trigger --type=devices --name-match=disk

规则生效后检查/dev/mapper/下对应设备的属主是否已经变成grid用户。这里最常犯的错误是直接对/dev/sd*设备做udev绑定，绕过了多路径层，这样做切换路径时权限可能失效，属于典型的错误配置。ASM创建磁盘组时使用AFD标签或者/dev/mapper/下的聚合设备路径，不要使用底层sd设备。

故障切换验证与常见问题排查

配置完成不代表冗余真正可用，必须做拔线级别的切换测试。测试方法很简单：在执行大表全表扫描的同时，逐根拔掉某节点到存储的光纤线，观察IO是否中断以及恢复时间。理想表现是multipath -ll中对应路径变为failed，IO继续通过剩余路径执行，SQL不报错。拔线测试建议每条路径、每个交换机端口都轮流做一遍。

测试不通过时按以下思路排查。第一，确认multipath -ll里能看到所有物理路径，路径数量少于预期通常是HBA端口zone配置问题，需要检查交换机的zone划分。第二，切换时间过长时检查path_checker和no_path_retry参数，特别是参数值为fail时会在路径全断的瞬间直接向数据库返回IO错误，极易触发节点驱逐。第三，检查udev规则是否对所有聚合设备生效，权限不对会导致CRS启动磁盘组时报权限拒绝错误。

最后提醒一点，私网和存储链路的冗余要一起规划。如果存储链路已经双路径，而私网还是单网卡，整个集群的高可用短板依然存在。上线前把心跳链路冗余、存储链路冗余、ASM磁盘组冗余三张检查表全部过一遍，RAC集群的稳定性才有真正的保障。

Oracle RAC多路径冗余Multipath配置修改时间：2026-09-10 06:16:37