企业的信息化系统，为了满足高可用要求，基本都会花高成本构建各类高可用架构，希望在发生故障时，能有各种自动、半自动或可手工切换与接管的后备环境，达到可缩短故障时间与降低故障所带来的影响的目的。
但是，您所构建的各类高可用架构，在故障时，真的能实现自动或快速切换的高可用目标吗。
下面高可用架构，是笔者要分享的“高可用，要用时，高不可用”诊断分析案例中的的HA部署架构：
第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