起因：一个客户的实际故障，该故障非常典型，其他客户类似的环境也非常多，所以很值得梳理并记录下来。
环境：Oracle 11.2.0.4 RAC（2 nodes）+ RHEL 6.6
共享存储：EMC powerpath 做的多路径绑定
分别登陆到两个节点，查看设备名称：
[oracle@node1 ~]$ ls -l /dev/emcpower*
crw-r--r-- 1 root root 10, 56 Feb 2 09:52 /dev/emcpower
brw-rw---- 1 grid asmadmin 120, 0 Feb 2 16:56 /dev/emcpowera
brw-rw---- 1 grid asmadmin 120, 16 Feb 2 16:56 /dev/emcpowerb
brw-rw---- 1 grid asmadmin 120, 32 Feb 2 16:56 /dev/emcpowerc
brw-rw---- 1 grid asmadmin 120, 48 Feb 2 16:56 /dev/emcpowerd
brw-rw---- 1 grid asmadmin 120, 64 Feb 2 16:56 /dev/emcpowere
brw-rw---- 1 grid asmadmin 120, 80 Feb 2 16:56 /dev/emcpowerf
brw-rw---- 1 grid asmadmin 120, 96 Feb 2 16:56 /dev/emcpowerg
brw-rw---- 1 grid asmadmin 120, 112 Feb 2 16:56 /dev/emcpowerh
brw-rw---- 1 grid asmadmin 120, 128 Feb 2 09:52 /dev/emcpoweri
[oracle@node2 ~]$ ls -l /dev/emcpower*
crw-rw---- 1 root root 10, 56 Jan 31 16:16 /dev/emcpower
brw-rw---- 1 grid asmadmin 120, 0 Feb 2 17:06 /dev/emcpowera
brw-rw---- 1 grid asmadmin 120, 16 Feb 2 17:07 /dev/emcpowerb
brw-rw---- 1 grid asmadmin 120, 32 Feb 2 17:07 /dev/emcpowerc
brw-rw---- 1 grid asmadmin 120, 48 Feb 2 17:06 /dev/emcpowerd
brw-rw---- 1 grid asmadmin 120, 64 Feb 2 17:06 /dev/emcpowere
brw-rw---- 1 grid asmadmin 120, 80 Feb 2 17:06 /dev/emcpowerf
brw-rw---- 1 grid asmadmin 120, 96 Feb 2 17:06 /dev/emcpowerg
brw-rw---- 1 grid asmadmin 120, 112 Feb 2 12:19 /dev/emcpowerh
brw-rw---- 1 grid asmadmin 120, 128 Feb 2 17:06 /dev/emcpoweri我们知道，这些都是powerpath多路径聚合之后的名字。
常见误区总结
对于一个这样的生产环境，存在以下几个普遍的误区：
常见误区一：
很多初学者对此存有误解，直接参照网上普及的RAC安装教学类视频，甚至还将这样的盘udev绑定成/dev/asm-disk* 这样的盘。
这样的做法完全是画蛇添足，实际上我们只需要确认这些多路径聚合之后盘的权限是正确的即可。
常见误区二：
在Linux系统中，关于盘的权限设定，很多人不清楚实施的规范究竟是怎样，比如看到有人习惯在/etc/rc.local中设定权限，有人习惯udev绑定权限，之后还有人说哪种方法都可以，给初学者造成了很大的困扰。而实际上具体选择如何赋予权限还和Linux操作系统的具体版本有关系。
这在Linux早期版本（RHEL6.2或更早），甚至只需要在 /etc/rc.local下写入一行chown的权限修改即可，可参考早期的文章：
- Linux平台 Oracle 11gR2 RAC安装Part2：GI安装
而在之后的RHEL版本中，这样不再可行，如果还在/etc/rc.local添加设定权限，udev还是会定时刷新权限为之前默认的。所以正确的做法是使用udev绑定权限。具体方法可参考早期文章：
- multipath多路径实验02-配置多路径软件
常见误区三：
这也是本文要描述的真实故障：背景信息详见文章开头部分，客户需求是从ASM磁盘组中剔除一块盘/dev/emcpoweri用作它用，剔除完毕后，客户第二天在格式化磁盘/dev/emcpoweri时，误以为两边节点的/dev/emcpoeri 对应的底层设备肯定是一样的，就直接到另一个节点去格式化/dev/emcpoweri，结果实际发现二者并不一样（通过kfed read查看磁盘头也可以验证），更糟的是被损坏的DATA磁盘组还是选择的外部冗余模式，相当于硬生生的格式化了一块ASM的数据盘用作它用，且没有任何冗余备份，从而酿成悲剧。
这个案例反映出来的误区就是：在两个节点查看多路径聚合后的共享磁盘的设备名称，得到的结果完全一致，很多初学者就想当然认为两边的名称对应的底层设备也一致。
而实际上RAC节点两边存储名字对应的真实磁盘很可能是不一致的，部分环境有要求一致的需求，那是需要要求存储工程师做相应的操作才可以。
说到各个节点对盘符识别的一致性，还需要延伸一下ASM的基础知识：对于Oracle提供的ASM，其实并不需要硬性要求两边共享磁盘设备的名字完全对应。因为作为ASM磁盘后，盘头是有记录信息的，Oracle通过盘头的信息判断是否是同一块盘。这点也可以在两个节点分别使用kfed read /dev/emcpoweri aun=0 blkn=0|more来查看盘头的信息验证。
PS：早期版本（Oracle 10g RAC）之所以要求ocr和voting disk对应的磁盘名称在两边一致是因为那个时候OCR和voting disk还不能放在ASM中。对于高标准的施工，出于为了方便后期的磁盘管理工作考虑，还是建议让各个节点对盘符识别保持一致性的，比如一般Linux使用自己的multipath软件，可以根据将每个盘唯一的scsi_id取alias绑定，这样就实现了各节点的盘符识别一致性。