RAC节点两边存储名字不一致导致的故障及相关延伸
2018-03-01 15:54 AlfredZhao 阅读(948) 评论(0) 编辑 收藏 举报起因:一个客户的实际故障,该故障非常典型,其他客户类似的环境也非常多,所以很值得梳理并记录下来。
环境: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的权限修改即可,可参考早期的文章:
而在之后的RHEL版本中,这样不再可行,如果还在/etc/rc.local添加设定权限,udev还是会定时刷新权限为之前默认的。所以正确的做法是使用udev绑定权限。具体方法可参考早期文章:
常见误区三:
这也是本文要描述的真实故障:背景信息详见文章开头部分,客户需求是从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绑定,这样就实现了各节点的盘符识别一致性。