在Oracle 11g RAC集群部署中，单纯配置multipath.conf文件的alias参数是存在风险的。为确保ASM能够稳定识别共享存储磁盘，必须结合udev规则，依据DM_NAME属性创建固定的/dev/asm-*字符设备节点，并精确设置grid:asmadmin所有权与权限。缺少这一关键步骤，ASM实例常因裸I/O访问失败而无法正常启动。
问题的核心在于，multipath服务自身无法保证ASM所需磁盘设备名称在系统重启后保持绝对一致。它生成的/dev/mapper/mpathx这类动态名称，难以满足Oracle ASM对路径持久性、权限可控性及跨节点名称一致性的严格要求。若没有udev规则进行精确映射，asmca配置助手要么无法扫描到磁盘，要么识别到错误的设备，最终导致整个集群启动失败。
为什么不能只靠 multipath.conf 的 alias？
multipath.conf中定义的alias（例如alias db1）仅用于控制/dev/mapper/db1这个符号链接的名称。然而，此路径并非Oracle 11g ASM原生支持的“原始设备”（raw device）。更为关键的是，在执行multipathd reload命令或系统重启后，/dev/mapper/目录下的设备节点可能出现创建延迟、权限重置或被其他进程占用等问题。ASM对存储设备有三项硬性规定：① 主设备号与次设备号固定；② 所有集群节点上的设备路径必须完全相同；③ grid用户必须拥有读写权限。仅依赖alias配置，这三项要求均无法得到可靠保障。
/dev/mapper/db1是device-mapper层生成的逻辑块设备，而Oracle 11g的ASM更推荐使用原始字符设备（如/dev/asm-*）或通过udev绑定的稳定符号链接。alias参数并不管理设备的属主、权限及创建时机，只有udev系统才能在内核发出设备事件后，精确地介入并控制设备节点的最终状态。- 在多节点的RAC环境中，不同服务器上
multipath -ll命令的输出顺序可能存在差异，这会导致alias名称对应的底层物理磁盘发生错位，从而引发数据不一致等严重后果。
怎样写可靠的 udev 规则绑定 multipath 设备？
核心解决方案非常明确：利用multipath设备提供的稳定属性DM_NAME（即配置的alias名称）作为匹配条件，在/dev/asm-*路径下创建持久化的设备节点，并一次性完成属主和权限的设定。规则文件应放置在/etc/udev/rules.d/99-asm.rules（确保文件名前的数字足够大，以使其在multipath相关规则之后执行）。
- 首先，确认multipath设备已被系统识别且alias已生效：执行
multipath -ll | grep "dm-.*mpath"，查找类似mpatha (36001405...)的记录及其对应的alias（例如db1）。 - 接着，验证该设备的
DM_NAME属性值：运行udevadm info --name /dev/mapper/db1 | grep DM_NAME，预期输出为E: DM_NAME=db1。 - 然后，编写udev规则（以alias为
db1的磁盘为例）：ENV{DM_NAME}=="db1", SYMLINK+="asm-disk1", OWNER="grid", GROUP="asmadmin", MODE="660" - 如果需要根据磁盘用途进行区分（例如投票盘Vote Disk、OCR盘、数据盘），可以按照alias分别编写多条规则，例如：
ENV{DM_NAME}=="vot1", SYMLINK+="asm-disk-vote", ...。 - 务必注意，避免使用
NAME=参数或直接匹配/dev/sdX这类不稳定的底层设备路径。必须基于DM_NAME或DM_UUID这类由multipath守护进程提供的、持久且唯一的属性进行匹配。
常见 udev 错误及验证方法
规则编写后未生效，90%的原因在于未正确触发规则重载或匹配条件有误。不应依赖重启服务器来解决问题，使用以下命令序列进行逐级排查更为高效。
- 执行
udevadm control --reload-rules重载规则后，必须紧接着运行udevadm trigger --subsystem-match=block --action=add，否则新规则不会应用到系统中已存在的块设备上。 - 验证规则是否被成功命中：
udevadm test /sys/block/dm-0 2>&1 | grep -A5 -B5 "asm-disk1"（请将dm-0替换为实际multipath设备在sysfs文件系统中的路径）。 - 检查最终生成的设备节点是否存在且权限正确：
ls -l /dev/asm-*。正确的输出应显示设备属主属组为grid:asmadmin，且权限为crw-rw----（注意：Oracle 11g ASM要求使用字符设备，因此规则中的MODE="660"参数会指导udev创建字符设备节点）。 - 若遇到
asmca工具扫描不到磁盘的情况，建议按此顺序排查：首先检查oracleasm listdisks输出是否为空；再确认/dev/asm-*设备文件是否存在；最后查询udev系统日志：journalctl -u systemd-udevd | tail -20。
为什么 /dev/asm-* 必须是字符设备而非块设备？
这是Oracle 11g RAC环境下的一个关键技术特性。ASM实例在启动过程中，会通过libasm库以O_DIRECT模式直接打开设备进行裸I/O操作。这要求底层设备必须支持裸I/O访问。在RHEL/CentOS 6/7等操作系统中，只有由udev创建的字符设备节点（文件类型标识为c）才能被ASM正确识别为“原始磁盘”。如果在udev规则中创建的符号链接指向了一个块设备（类型为b），那么oracleasm scandisks命令可能显示成功，但ASM实例启动时会抛出错误，例如ORA-15018: diskgroup cannot be created或ORA-15032: not all alterations performed——其根本原因在于系统驱动层拒绝向块设备执行裸I/O操作。
- 确认设备类型：执行
ls -l /dev/asm-disk1，行首字符应为crw-rw----，而非brw-rw----。 - 如果错误地生成了块设备，通常是因为udev规则中遗漏了
MODE="660"参数，或者仅设置了OWNER/GROUP而未指定MODE，此时udev会默认创建块设备节点。 - 这一点在Oracle 11g环境中必须严格遵守。从12c版本开始，Oracle逐步增强了对块设备的兼容性支持，但在11g RAC部署中，使用字符设备是必须确保的技术底线。
