最近在AIX的reserve_lock上连续搞出了两个故障，教训是惨痛的，记录一下
我们有套双机AIX+Oracle 11G +ASM的环境,存储是两套EMC DMX3,一主一备,非RAC,正常情况下每台主机拉起自己的ASM DG,做成data guard,ASM DISK是直接基于/dev/hdiskpower的,没有使用AIX的VG,为了方便故障切换,我们让小机同时认到了主备存储的所有LUN,同时asm_diskstring也包含了两套存储所有的数据lun,在上线前,专门修改了PV的属性,reserve_lock=no
参考 http://chj733.spaces.live.com/blog/cns!C59D3364AD37617B!161.entry
 
上周光纤交换机调整,导致备机的hba通道出现问题,我们将备库的powerdisk删除了重认了一次，AIX里面默认认出的pv的reserve_lock=yes，这样两边的reserve_lock信息不一致了，主库是no，备库是yes，这个时候犯了个低级错误,头脑一热 ,在备机上做了次chdev -l hdiskpower reserve_lock=no(包括主库在用的lun)，马上主库的asm实例crash了,alert日志信息显示:device is busy,当时认为chdev是针对本机的ODM库的,不会修改盘头信息,后来IBM工程师解释,这个动作确实只修改ODM库,
但你备库的当前属性是reserve_lock=yes的,他会将磁盘资源lock住,而主库的是以reserve_lock=no打开的磁盘,自然就被抢了
 
第2次故障,种种原因,系统的状态又回到了原点,主库no,备库yes,这时不敢再修改reserve_lock了,但备库ASM还是要起来，standby还要继续使用的，在备库做完alter diskgroup dg2 mount后，主库开始出现大量的磁盘IO报警，很快DG就被强行dismount，数据库又挂了，不过这次ASM实例没挂，从理论上讲，ASM加载DG，会扫描asm_diskstring的所有磁盘，他是根据盘头信息来判断那些盘是要加载的，就算盘的顺序乱掉也没关系，为什么备库挂DG会把主库的DG搞当？后来线下做过测试，在YES的那边，做个简单的select * from v$asm_diskgroup也会把NO的那边弄挂，这个只能说明，ASM配reserve_lock=yes一起使用的时候，会对所有被检查的盘加锁，哪怕这个盘不属于你正要加载的DG,如果两边的lock属性不一致，就会存在抢断的现象，这个是比较危险的

对于这种共享磁盘的使用，建议：
保持两边的reserve_lock=no，严格控制主备磁盘不会重叠使用
出现HBA卡损坏，磁盘需要重认，最好先在powerpath中踢出磁盘，在OS上删除设备，尽量保持设备define，这样重认会重用现有的属性
可以考虑使用AIX VG,用lv作为asm disk，将控制权限交给AIX管理，这样是比较保险的，但估计很多人会觉得多包了层LVM不大爽

 
共享磁盘的lock属性,主要是为了控制多台主机对同一块磁盘设备的并发访问，每个厂商的设备基本都有这个设置，EMC的是reserve_lock，其他的也叫reserve_policy,大致意义是相同的，在访问这个设备的时候，会对设备打个标签，表示我已经持有了锁定，其他请求要访问时就会等待或失败，这个锁定的策略也是分好几种的
No Reserve reservation policy
这个表示不锁定
 
Exclusive Host Access single-path reservation policy
在san环境里面，一个LUN一般是由多条路径组成的，每条路径其实是个disk设备，他的Initiator就是光纤卡，
这些磁盘设备的锁定标志位就是以HBA卡来打的，所以HBA1打的标签，你通过HBA2是不能访问的，这个就叫single-path,
只有当HBA1失败后，切换到HBA2,标志位重新打过后，才能被访问
 
Persistent Reserve Exclusive Host Access reservation policy
我们上面说的hdiskpower应该就是这个策略，他是在HOST级别的，一般每个主机都会生成一个唯一的key，
标签在lun上打上后，后面只要是来自这个主机的请求，都可以访问这个lun，而其他主机由于生成的key不一样，
是没办法访问的

• 

  沙发学习了

  励志名言 @ January 6, 2010 |

• 

  地板了

  vogts @ January 7, 2010 |

• 

  学习～～～～

  orain @ January 7, 2010 |