环境是一套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天继续稳定运行。
待续…
举手之劳，请点击这里—->帮助改进网站访问调查
相关的文章: