PowerPath和HACMP抢盘的故障

环境是一套oracle 10g rac，运行在两台P570上，使用存储为EMC CX4-120

各系统软件版本为：
AIX：      6.1
HACMP:     5.4.1.0
PowerPath: 5.3

故障的现象是有一个节点(B)的oracle未启动，现场工程师经检查发现OCR盘损坏，咨询如何修复OCR盘

因为另一个节点(A)检测运行正常，我怀疑并不是OCR盘的问题，在2个节点上检查crs日志，发现节点B上找不到OCR盘了，导致节点B上的oracle进程都未启动成功。

在10g rac环境下，OCR盘还是作为裸设备存在方共享存储上，如果节点B上找不到OCR盘，说明连接存储可能出现了问题，存储上的VG有可能也识别不到了。

果然，在节点B上lsvg发现，oracle所在的datavg都无法访问了，而正常情况下，datavg的状态应该concurrent。

从节点B的hacmp.out中的错误信息大概能判断出来
cl_fscsilunreset[727]: odm_gecl_fscsilunreset[969]: ioctl SCIOLSTART id=0X10300 lun=0X4000000000000: Invalid argument
cl_fscsilunreset[969]: ioctl SCIOLSTART id=0X10300 lun=0X5000000000000: Invalid argument

好在节点A还在正常运行，对业务的影响比较小，我们总结故障之后，马上到EMC的800上报了case，故障为服务器无法挂载存储。

现场工程师检查存储后，又发现了一个问题，在节点B上通过PowerPath的软件，查看磁盘都存在问题，咨询800后，建议删除掉原来的配置，重新扫描一次存储上的磁盘。

但引起了更严重的问题，部分磁盘的配置竟然删除不掉，具体原因我很有兴趣，可惜现场没有把日志给记录下来，800最后给出的建议是先卸载掉PowerPath的软件，存储的配置全部都重新开始做。

重装很顺利，ODM配置这些我也不太懂，得到的结果是磁盘都正常了，在节点B上能够正确认出磁盘，且多路径软件也能正确看见hdiskpower盘

800也发来了日志打包软件，可以把当前的系统状况记录到压缩包，发给emc的工程师确认，经认可后，PowerPath认盘方面已经没有问题了。

似乎都很顺利了，下一步只要启动节点B的hacmp，能够识别共享存储的数据就可以恢复业务了。

因为节点B启动hacmp，可能会对业务产生影响，先和用户约定了停机时间，到晚上6点以后开始进行恢复。

没想到麻烦竟然在后头，节点B启动hacmp后，等待了半天没有反应了，从日志上看应该是失败了，datavg的状态一直没有变动，从节点B上看不出什么原因，就到节点A上看有没有发现。

节点A竟然连接不上，网络似乎中断了，可我连接的不是VIP呀，是物理IP，网络怎么会中断呢，赶紧让现场工程师去机房瞧一下。

现场工程师告之一个很不幸的结果，节点A自动重启了。

处理到这里，我已经有点晕了，好在hacmp导致自动重启也见了几个，先第一时间告诉emc800目前的现状，又开了一个case来处理这个问题，但emc到10点就没有人支持了，要处理需要明天。

在节点A启动的过程中，节点B竟然可以成功启动hacmp了，看样子PowerPath认盘确实没有什么问题了，但是节点B感觉上还是不稳定，不能支撑第2天的业务量，和用户商量后，还是决定继续处理节点B，让节点A第2天继续稳定运行。

今天看了主机B的日志和oracle的crs日志，判断确实是主机B抓盘的问题，首先是crs找不到共享存储的裸设备，日志如下

2010-06-02 11:21:26.432: [ OCROSD][1]utopen:7:failed to open OCR file/disk /dev/rlv_ocr01_512m /dev/rlv_ocr02_512m, errno=6, os err string=No such device or address
2010-06-02 11:21:26.432: [ OCRRAW][1]proprinit: Could not open raw device
2010-06-02 11:21:26.432: [ default][1]a_init:7!: Backend init unsuccessful : [26]
2010-06-02 11:21:26.432: [ CSSCLNT][1]clsssinit: Unable to access OCR device in OCR init.
2010-06-02 11:21:26.432: [ CRSRTI][1]32CSS is not ready. Received status 21 from CSS. Waiting for good status ..

其次是hacmp没有什么本质的变化，仍然还是抓不到盘，从日志的表现上看，pv打开有问题

+ycre:cl_mode3[354] lqueryvg -p hdiskpower8 -X
0516-024 lqueryvg: Unable to open physical volume.
	Either PV was not configured or could not be opened. Run
	diagnostics.

但是白天什么都做不了，已经通过emcgrab把搜集到日志发给技术支持了，到下午四点了还没有什么反馈消息，当然也不是全没有，发来了一个EMC HostConnectivity Guide for IBMAIX.pdf文件，详细介绍了在AIX上连接EMC的设置，文件很大，有440页，难道EMC想让我们自己查手册不成？

还有emc69100.txt和emc97234.txt，看说明应该还要配置emcpowerreset类的参数才行，现在都是想法而已，等晚上有回复了再说吧。

和昨天一样，还是用WebEx联系上了emc的支持，他们需要看界面，必要的时候需要远程控制，联系上的技术支持在上海，通过他再联系可以处理该问题的人员。

很快，上海的支持人员找到了线上能支持的工程师，不过看了下物理位置，是一个印度的工程师，这下上海的支持还得充当翻译了。

大家都通过WebEx上面了，首先我介绍了一下故障：单节点独自启动hacmp是正常的，但是2个节点不能同时启动hacmp，后启动的节点是不能成功的。

英语还是没学好呀，翻译过来的语法和我想的差别真远，印度人问了几个问题，如系统软件版本，emcgrab的一些情况，然后他通过lspv看了一下参数后，很久都没有回复消息了，我忍不住问下翻译，下一步应该怎么做。

过了一会，翻译说已经确认了主机上识别存储是没有问题的，原来刚才印度的工程师又确认一次识别存储的过程，在他看来，主机连接存储正常，在这方面是没有问题的，而我等不及翻译，直接用英语交流了几句，估计理解有困难，他纳闷的问翻译，问题在哪里?

语言沟通不畅真的是急死人了，只好一字一句的翻译吧，首先说单机启动hacmp是正常的，但是2个节点都启动的话，后启动的节点会抓不到盘，另外把错误日志给贴上了。

看来印度的工程师应该是懂了，然后等了好半天，又没有动静了，还是问翻译，下一步准备干什么，答复是在查资料，看有没有类似故障的解决办法。

一直等到了近10点，上海的支持都快下班了，还有没有结果，我仔细看了emc69100.txt和emc97234.txt说的情况，感觉应该是需要在hacmp中配置emcpowerreset后，或许才有可能抓到包吧。

等了一会，印度人说磁盘参数reserve_lock要修改，需要所有存储的盘都改为no（命令为：chdev -l hdiskpower0 -a reserve_lock=no），然后建议启动hacmp试试。

对现场环境来说，真的是个馊主意，给主机的有16个lun，这样能识别的盘有32个，多路径后还有16个，得写个脚本干这个了。

没想到这个阿三（真想叫一句印度阿三）说有脚本，能批量改，让我们等等，他去找脚本了。

一晃半个小时过去了，中间阿三羞涩的说没找到，让再等等，继续等待，终于等来了emc_reserve_v1.sh脚本。
还别说，挺好使的，存储的盘屁颠屁颠都改好了，被阿三折腾这么久，时间都耗了不少。

继续启hacmp，没想到故障依旧，没有什么大的变化，从日志上也没有什么新的发现。

快12点的时候，阿三仍然没有更新的消息，翻译讲他似乎又去处理其他故障去了，天，这哪知道什么时候有结果，他们的时区和我们不一样，我们可是午夜了啊。
熬了一晚上，除了给印度人介绍故障，修改一个磁盘参数之外，没有什么进展了，确实也太晚了，就约定明晚再看看吧。

白天的业务，还是单节点运行，很顺利，没出一点岔子，平安的到了晚上。

远程的支持还是太慢了，实在是等不起，我参考了不少网上的资料，类似的故障也有不少，修改了reserve_lock参数和增加hacmp配置后，一般都能够解决故障。
那就在hacmp上增加emcpowerreset参数吧。

按照emc69100.txt的介绍的做法的步骤，摘抄部分如下

 I) For HACMP 5.1 and higher (SMIT): 

 1. Enter into the SMIT fastpath for HACMP "smitty hacmp".  

 2. Select Extended Configuration.  

 3. Select Extended Resource Configuration.  

 4. Select HACMP Extended Resources Configuration.  

 5. Select Configure Custom Disk Methods.  

 6. Select Add Custom Disk Methods.  

 7. The following fields are available, enter as follows:  

 For IBM Fibre Channel configurations with PowerPath 3.0.3 and higher:  

 Disk Type (PdDvLn field from CuDv) = disk/pseudo/power 

Method to identify ghost disks = SCSI3 

Method to determine if a reserve is held = SCSI_TUR 

Method to break a reserve = /usr/lpp/EMC/Symmetrix/bin/emcpowerreset 

or 

/usr/lpp/EMC/CLARiiON/bin/emcpowerreset 

Break reserves in parallel = true 

Method to make the disk available = MKDEV

而且做的过程很保守，先是把其中一台关掉了，更改好了以后，再加电另一个节点做设置，终于苦日子到头了，测试下都能成功。

然后继续多测试几个，果然都行，看现象是PowerPath不去参和抢盘了，hacmp也能顺利的把盘接管过来。

正好800电话过来问情况，先答复说恢复正常，但需要观察一周，继续关注这个情况吧。