SAN网络维护导致rac双机宕故障案例分析

客户进行SAN网络维护，由于只是对多路径中的一路进行操作，所以选择在线操作，操作完成后，意外发现RAC群集中的一个数据库实例竟然宕了，并且怎么也拉不起来，重启节点服务器后，解决了，要求事后调查原因。

这是套运行在linux环境上的RAC，ASM磁盘基于asmlib。问题的定位并不困难，主要是两方面的原因，更换sfp模块触发问题，而实施的时候asmlib可能没有关联到多路径盘上面，导致单条路径的失败引起asmlib识别的虚拟设备丢失是根本原因。

让一线取回/etc/sysconfig/oracleasm和/var/log/oracleasm文件的内容，以及ls -l /dev/oracleasm/disks的输出。

从oracleasm的配置来看，ORACLEASM_SCANORDER=""是空的，这样的话，oracleasm扫描磁盘的时候不会只选择多路径化后的设备，而是会包括那些单路径磁盘。这种情况下，在线维护SAN链路就讲究手气了，如果维护的那条链路刚好是asmlib识别的设备，那么就会导致asm文件无法访问，而关闭数据库实例。事实上，客户SAN维护影响到2个RAC节点，结果是一个节点保持存活，另一个节点牺牲。

由于linux内核将故障链路对应的磁盘置于不可访问后，不经过重新扫描或者重启，不会置回活动状态，所以即使SAN链路恢复后，重启数据库实例仍然无法成功。

次日客户获取的ls命令输出确认了，报故障的ASM磁盘DATA2确实是指向了单路径，这样一旦所涉及的路径失败，将导致ASM磁盘组的不可访问。

下面引用解决过程中找到的不记得出处的一段文字，说明asmlib关于多路径的配置方法：

“在多路径环境下使用 ASMLib 时，确保已正确配置 ASMLib，以便多路径设备可用于访问对应的设备。通过编辑 /etc/sysconfig/oracleasm 配置文件和修改 ORACLEASM_SCANORDER 以包括 /proc/partitions 中的有效前缀条目（如“dm”、“emcpower”），即可实现这一点。”