高可用,要用时,高不可用 故障诊断分析一例

时间:2022-05-27 04:04:57

        企业的信息化系统,为了满足高可用要求,基本都会花高成本构建各类高可用架构,希望在发生故障时,能有各种自动、半自动或可手工切换与接管的后备环境,达到可缩短故障时间与降低故障所带来的影响的目的。

        但是,您所构建的各类高可用架构,在故障时,真的能实现自动或快速切换的高可用目标吗。

      下面高可用架构,是笔者要分享的“高可用,要用时,高不可用”诊断分析案例中的的HA部署架构:高可用,要用时,高不可用 故障诊断分析一例      第1台主机,运行有ORACLE主生产数据库(单实例),同时充当SAP ECC 的备用环境

      第2台主机,运行有SAP ECC主生产环境,同时充当ORACLE数据库备用环境(shutdown状态)

      上述部署结构,以两台小机+1台共享存储,采用HACMP做为高可用管理软件,构成典型的HA架构,同时,两台主机均有自己的主运行程序,并且充当另一台主机所运行程序功能的备用主机,当第1台主机出现故障时,数据库可以通过HACMP自动或手动的切换到2节点上,当第2台主机故障时,SAP ECC也可以自动或手动的切换到1节点上,形成了一个两节点的功能互备的高可用集群架构。

      如果说是满足一定RTO(Recovery TimeObjective,复原时间目标)要求的高可用架构,这个设计还是挺理想的。

      就是设计这么理想的高可用架构,在有故障需要切换时,却切遇到了问题,导致了好几个小时的故障,这到底是怎么回事呢?

1、HA高可用无法切换故障现象

(1)2节点(RXXXHPRD2,物理IP:10.X.XX.67,虚拟IP:10.X.XX.68),因为SAPECC重启时起不来,系统维护人员手工对操作系统进行了重启

(2)2节点(RXXXHPRD2,物理IP:10.X.XX.67,虚拟IP:10.X.XX.68)操作系统重启后,正常情况下,2节点集群中的软件及资源(sap ecc、虚拟IP,共享存储卷激活状态)应该漂到1节点,以继续提供服务,这也是两台服务器创建HA的目标

(3)在2节点重启完成,1节点没有正常接管的情况下,手工启动2节点的高可用软件(HACMP)失败,导致2节点无法激活共享VG,以及对SAPECC绑定的对外提供服务的虚拟IP 10.X.XX.68不能生成

(4)手工在1节点上进入高可用管理软件(HACMP),试图将资源转移到1节点,同样无法成功

(5)      在虚拟IP 10.X.XX.68不能生成的情况下,SAP ECC无法正常启动

2、本HA故障案例分析所涉及日志来源信息列表

序号

日志名称

所属
节点

日志说明

1

hacmp.out

1

记录HACMP 事件脚本和实用程序的运行情况

2

cluster.log

1

记录集群脚本和后台进程等运行情况

3

cluster.log

2

记录集群脚本和后台进程等运行情况

 

3、本次临时故障解决方法

(1) 通过在2节点(RXXXHPRD2,物理IP:10.X.XX.67,虚拟IP:10.X.XX.68)上,手工激活共享卷(civg卷),即绕过高可用(HACMP),以单节点、无高可用方式运行

(2) 手工将虚拟IP:10.X.XX.68绑定到2节点的en2网卡上,以使SAP ECC所指定的IP地址活跃可通

(3) 在2节点手工启动SAP ECC,启动成功,并可对外提供服务

4、故障原因及高可用不能正常切换总结

(1)     在2节点的civg上,于2015年1月27日和10月29日,两次采用extendvg命令对civg中添加磁盘的不恰当的或不完整的操作方式,导致在2节点的加盘信息,没有被自动同步到1节点的VG中,也未实施手工同步操作

(2)     在HACMP软件做切换的过程中,对civg卷组中的磁盘信息校验时,发现本机磁盘状态信息与HACMP的信息不一致,从而无法启动

5、故障原因分析过程及证明日志

(1) 通过在集群节点1(RXXYHPRD1 IP:10.X.XX.65)上的高可用管理软件(HACMP)日志中查看到,集群节点2(RXXXHPRD2 IP:10.X.XX.67),在7点26分重启操作系统后,集群节点1上的高可用管理软件(HACMP)侦测到网络心跳故障,集群节点1中的高可用管理软件(HACMP)做出了资源切换动作:

高可用,要用时,高不可用 故障诊断分析一例

 

(2)  HACMP尝试把SAP软件所使用的civg资源在集群节点1激活,但是不成功,报出错误日志信息如下:

0516-052 varyonvg: Volume group cannot be varied on without a\n\tquorum. More physical volumes in the group must be active.\n\tRun diagnostics on inactive PVs.' ,This normally happens when a PV is added/deleted into a VG on one node and not imported。

高可用,要用时,高不可用 故障诊断分析一例

      根据上面错误日志判断,有些盘是后来追加到civg卷组中,却因没做导入(import)操作或缺少高可用(HA)信      息同步过程,2个集群节点的civg卷组中的物理卷信息不一致导致此次资源切换失败。

(3)1节点报出civg不能激活的原因为“新增加的磁盘(PV)没有加入到VG中来”的告警信息

高可用,要用时,高不可用 故障诊断分析一例

 

(4)人工对比1节点和2节点的磁盘信息,发现确实不一致

A、1节点的磁盘信息

      操作系统中有看到“hdisk42”和 “hdisk45”两块盘,没有相对应的VG信息,说明没有加入到任何VG中

高可用,要用时,高不可用 故障诊断分析一例

 

B、2节点的磁盘信息

      操作系统中有看到“hdisk42”和 “hdisk45”两块盘,均有对应的VG信息,并且是对应的civg,说明在2节点,这两块盘是有加入VG的

高可用,要用时,高不可用 故障诊断分析一例

 

(5)找出在2015年1月27日和2015年10月29日分别有在2节点上增加磁盘,并且增加的磁盘,正好是1节点上没有对应VG关系的“hdisk42”和 “hdisk45”两块盘

高可用,要用时,高不可用 故障诊断分析一例

 

(6)2节点上曾使用smit extendvg命令加盘历史命令记录

高可用,要用时,高不可用 故障诊断分析一例

 

6、高可用,要用时,高不可用 原因总结

      在建设初期,投入了大量的软硬件设备构建了高可用架构,但是,由于日常运行维护过程

中,没有注意适应HA的标准化维护规范,导致高可用环境遭到了破坏,到真正故障出现时,高可用就高不可用了。

 

7、改进建议

(1)对于基于HACMP的高可用集群环境,避免使用extendvg命令加盘

(2)建议基于HACMP的高可用集群环境下加盘采用AIX推荐的C-SPOC功能(HACMP Logical Volume Management)进行VG容量扩展


本文作者:黎俊杰(网名:踩点),从事”系统架构、操作系统、存储设备、数据库、中间件、应用程序“六个层面系统性的性能优化工作

欢迎加入系统性能优化专业群 ,共同探讨性能优化技术。群号:258187244