HACMP 5x 完全手册 第3部分 测试和维护.docx

1、HACMP 5x 完全手册 第3部分 测试和维护HACMP 5.x 完全手册，第 3 部分：测试和维护辛 旻(xinmin), IBM 主机工程师, 上海宝信软件股份有限公司简介：本系列文章的作者通过自己长期的实际项目工作经历，总结出了他对于 HACMP 设计实施的经验。本系列会分为 4 部分，会向您详细地介绍实施 HACMP 过程中会经历的各个过程，如设计，配置，安装，测试等。本文为第 3 部分，会向您介绍在 HACMP 安装配置完毕后需要进行的测试工作，以及在 HACMP 正式上线后需要定期进行的维护工作。本文的标签：aix,hacmp,安装,工具与及实用程序,故障检修,系统管理标记本文！

2、发布日期：2008 年 4 月 17 日访问情况 ：4368 次浏览评论：0(查看|添加评论- 登录)平均分 (8个评分)为本文评分测试部分虽然 HACMP 提供了自动化测试工具 test tool，使用起来也较为简单。但个人认为由于 HACMP 的完整测试是一个比较复杂的事情，工具还不能说非常成熟，也无法模拟交换机等故障，所以只能提供协助，不能完全依靠，结果仅供参考。测试方法说明：1. ping 测试：从 client 同时发起，每次 1024 个字节，延续 10 分钟。2. ping 长测试：每次 1024 个字节，延续 24 小时。3. 应用测试：利用自动化测试工具持续从 client

3、连接应用服务使用查询。4. 应用长测试 :48 小时内，进行应用测试使用。5. telnet 测试：telnet 连接后根据情况确认。标准测试这个测试为必须完成的测试，每个网段都要做一次，阶段一般为初始配置阶段，运维定修阶段。标准测试表序号测试步骤系统结果应用结果1拔掉 host1 的服务 IP 的网线地址漂移到另一个网卡中断 30s 左右可继续使用2拔掉 host1 剩下的一根网线发生切换中断 5 分钟左右可继续使用3拔掉 host2 的服务 IP 网线所有服务地址漂到另一个网卡中断 30s 左右可继续使用4恢复所有网线地址 join，clstat 可看到所有节点均恢复原始状态。无影响5在

4、host2 上执行 ha1t -qhost2 机宕机，切换到 host1 机中断 5 分钟左右可继续使用启动 host2 恢复原始状态1拔掉 host2 的服务 IP 网线地址漂另一个网卡中断 30s 左右可继续使用2拔掉 host2 的剩下一根的网线发生切换中断 5 分钟左右可继续使用3拔掉 host1 的服务 IP 网线所有服务地址漂到另一网卡中断 30s 左右可继续使用4恢复所有网线地址 join，clstat 可看到均 up无影响5在 host1 上执行 halt -qhost1 机宕机，切换到 host2 机中断 5 分钟左右可继续使用完全测试完全测试在有充分测试时间和测试条件（如交

5、换机可参与测试）下进行，阶段一般为系统上线前一周。注意：考虑到下表的通用性，有 2 种情况没有细化，需要注意。1. 同一网络有 2 个服务 IP 地址，考虑到负载均衡，将自动分别落在 boot1、boot2 上，这样不论那个网卡有问题，都会发生地址漂移。2. 应用中断没有加入应用的重新连接时间，如 oracleDB 发生漂移，实际 tuxedo 需要重新启动才可继续连接，这个需要起停脚本来实现。完全测试表序号测试场景系统结果应用结果参考时长功能测试1host2 起 HAhost2 服务 IP 地址生效，vg、文件系统生效host2 app(db) 启动 OK120s2host2 停 HAhos

6、t2 服务 IP 地址、vg 释放host2 app 停止15s3host1 起 HAhost1 服务 IP 地址生效，vg、文件系统生效host1 app 启动 OK120s4host1 停 HAhost1 网卡、vg 释放host2 app 停止15s5host2 takeover 到 host1host2 服务地址切换到 host1 的 boot2 和 vg 切换到 host1host2 app 短暂中断30shost2 clstart恢复原状host2 app 短暂中断120s6host1 takeover 到 host2host1 服务地址切换到 host2 的 boot2 和 vg

7、 等切换到 host2host1 app 短暂中断30shost1 clstart恢复原状host1 app 短暂中断120s网卡异常测试1host2 断开 boot1 网线host2 的服务 IP 从 boot1 漂移至 boot2host2 app 短暂中断30shost2 恢复 boot1 网线连接host2 boot1 join无影响40s2host2 断开 boot2 网线host2 的服务 IP 从 boot2 漂移至 boot1host2 app 短暂中断30shost2 恢复 boot2 网线连接host2 boot1 join无影响40s3host2 断开 boot1、boo

8、t2 网线host2 服务地址切换到 host1 的 boot2 上，vg 等切换到 host1host2 app 短暂中断210shost1 再断开 boot2 网线，host2 的服务 IP 漂移到 host1 的 boot1host2 app 短暂中断30shost2 恢复 boot1、boot2 网线连接host2 boot1，boot 2join无影响30shost2 clstart恢复原状host2 app 短暂中断开120s4host1 断开 boot1、boot2 网线host1 服务地址切换到 host2 的 boot2 上，vg 等切换到 host2host1 app 短暂

9、中断210shost2 再断开 boot2 网线，host1 的服务 IP 漂移到 host2 的 boot1host1 app 短暂中断30shost1 恢复 boot1、boot2 网线链接host1 boot1，boot 2join无影响30shost2 clstart恢复原状host2 app 短暂中断120s5host2 force clstopcluster 服务停止，IP、vg 资源无反应无影响20shost2 clstart恢复原状无影响20s6host1 force clstopcluster 服务停止，IP、vg 资源无反应无影响20shost1 clstart恢复原状无影

10、响20s7host2,host1 boot2 网线同时断开 30minsboot2 failed无影响20shost2,host1 boot2 网线恢复boot2 均 join无影响20s8host2,host1 boot1 网线同时断开 30mins服务 IP 地址均漂移到 boot2 上。host1,host2 app 短暂中断30shost2,host1 boot1 网线恢复boot1 均 join无影响20s主机宕机测试1host2 突然宕机 halt -qhost2 服务地址切换到 host1 的 boot2 和 vg 等切换到 host1host2 app 短暂中断30shost2

11、 clstart恢复原状host2 app 短暂中断120s2host1 突然宕机 halt -qhost1 服务地址切换到 host2 的 boot2 和 vg 等切换到 host2host1 app 短暂中断30shost1 clstart恢复原状host1 app 短暂中断120s交换机异常测试1SwitchA 断电服务 IP 地址均漂移到 boot2 上host1、host2 app 短暂中断50sSwitchA 恢复boot1 join无影响40sSwitchB 断电服务 IP 地址均漂移回 boot1 上host1、host2 app 短暂中断50sSwitchB 恢复boot2

12、join无影响40s2SwitchB 断电boot2 failed无影响50sSwitchB 恢复boot2 join无影响40sSwitchA 断电服务 IP 地址均漂移到 boot2 上。host1、host2 app 短暂中断50sSwitchA 恢复boot1 join无影响40s3SwitchA，B 同时断电 10minsnetwork 报 down，其他一切不动。host1、host2 app 中断10minSwitchA，B 恢复boot1，boot2 join服务自动恢复50s4SwitchA 断电服务 IP 地址均漂移到 boot2 上host1、host2 app 短暂中断

13、50s30s 后 B 也断电不动host1、host2 app 中断50sSwitchA，B 恢复boot1 join自动恢复40s5SwitchB 断电boot2 failed无影响50s30s 后 A 也断电network 报 down，其他一切不动。host1、host2 app 中断50sSwitchA，B 恢复boot1 join自动恢复40s6SwitchA 异常（对接网线触发广播风暴）机器本身正常，但网络不通host1、host2 app 中断20sSwitchA 恢复恢复后一切正常自动恢复7SwitchB 异常（对接网线触广播风暴）机器本身正常，但网络不通恢复后一切正常host

14、1、host2 app 中断20sSwitchB 恢复自动恢复8SwitchA，B 同时异常（对接网线触广播风暴）机器本身正常，但网络丢包严重，host1、host2 app 中断10sSwitchA，B 恢复恢复后一切正常自动恢复20s稳定性测试1host2， host1 各起 HA正常服务2host2 takeover 切换 host1正常服务3host1 takeover 到 host2正常服务运维切换测试：运维切换测试是为了在运维过程中，保证高可靠性加以实施。建议每年实施一次。因为这样的测试实际是一种演练，能够及时发现各方面的问题，为故障期间切换成功提供有效保证。运维切换测试表场景建议

15、时长切换方式主备（run-dev）主切换到备机10 天备机开发测试停用或临时修改 HA 配置互备（app db,appapp,dbdb）互相切换30 天手工互相交叉启动资源组主机切换到备机：有 2 种方式： 可用 takeover 方式 , 但由于负荷和防止误操作的原因，备机的开发测试环境一般需要停用。 也可通过修改 HA 的配置，将备机资源组的节点数增加运行节点。这样可以在切换测试期间继续使用开发测试环境。但这样不光要对 HA 有所改动。还要预先配置时就要保证备机开发测试环境也不是放在本地盘上，需要放在共享 vg 里，此外还要同步开发测试的环境到运行机。建议最好在设计时就有这样的考虑。手工互

16、相切换：停掉资源组：smitty hacmp-System Management (C-SPOC)- HACMP Resource Group and Application Management-Bring a Resource Group Offline 选择 host2_RG,host2 Bring a Resource Group OfflineType or select values in entry fields.Press Enter AFTER making all desired changes. Entry Fields Resource Group to Bring O

17、ffline host2_RG Node On Which to Bring Resource Group Offline host2 Persist Across Cluster Reboot? false 同样停掉 host1_RG互换资源组：smitty hacmp-System Management (C-SPOC)- HACMP Resource Group and Application Management-Bring a Resource Group Online 选择 host2_RG,host1 Resource Group to Bring Online host2_RG

18、 Node on Which to Bring Resource Group Online host1 Persist Across Cluster Reboot 回答 No。即在 host1 上启动 host2 的资源组，同样方法在 host2 上启动 host1 资源组。这样 2 台机器就实现了互换。注意：由于互切需要人工干预，恢复原状也要人工干预，所以切换期间需要密切监控运行状况，如方便出现有异常时，能立刻人工处理。互换 crontab 及相关后台脚本：由于备份作业等 crontab 里的后台作业会有所不同，所以需要进行互换，按我们的做法只需拷贝相应 crontab 的配置文件即可。ho

19、st1root/cp /home/scripts/host2/crontab_host2 /var/spool/cron/crontabs/root修改文件属性：host1root/chown root:cron /var/spool/cron/crontabs/roothost1root/chmod 600 /var/spool/cron/crontabs/root重起 crontab:host1root/ps -ef|grep cronroot 278688 1 0 Dec 19 - 0:02 /usr/sbin/cronhost1root/kill -9 278688如果不采用我们脚本的

20、做法，除需要拷贝对方的 crontab 外，还要记得同步相应脚本。互换备份策略：由于备份方式不同，可能所作的调整也不一样，需要具体系统具体对待。实验环境中的备份采用后台作业方式，无须进一步处理。实际环境中可能采用备份软件，由于主机互换了，备份策略是否有效需要确认，如无效，需要做相应修正。回页首维护部分作为高可用性的保证，通过了配置和测试之后，系统可以成功上线了，但不要忘记，HACMP 也需要精心维护才能在最关键的时刻发生作用，否则不光是多余的摆设，维护人员会由于“已经安装好 HA 了，关键时刻自然会发生作用”的想法反而高枕无忧，麻痹大意。我们统计了以往遇到的切换不成功或误切换的场景，编制了测试

21、成功切换却失败的原因及对策，如下表：HACMP 切换问题表故障现象原因根本原因对策无法切换 1测试一段时间后两边 HA 不同步没通过 HA 的功能（含 C-SPOC）进行用户、文件系统等系统变更。制定和遵守规范，定期检查，定修及时处理无法切换 2应用停不下来，导致超时，文件系统不能 umount停止脚本问题规范化增加 kill_vg_user 脚本切换成功但应用不好用应用启动异常应用有变动，停止脚本异常停止或启动脚本不正确规范化和及时更新起停脚本切换成功但应用不好用备机配置不符合运行要求各类系统和软件参数不合适制定检查规范初稿，通过运维切换测试检查确认。切换成功但通信不好用 1网络路由不通网络

22、配置原因修正测试路由，通过运维切换测试检查确认。切换成功但通信不好用 2通信软件配置问题由于一台主机同时漂移同一网段的 2 个服务地址，通信电文从另一个 IP 地址通信，导致错误修正配置，绑定指定服务 IP。误切换DMS 问题系统负荷持续过高参见脚本和经验部分。注意：请记住，对于客户来说，不管什么原因，“应用中断超过了 5-10 分钟，就是 HACMP 切换不成功”，也意味着前面所有的工作都白费了，所以维护工作的重要性也是不言而谕的。强制方式停掉 HACMP:HACMP 的停止分为 3 种，graceful（正常），takeover（手工切换），force（强制）。下面的维护工作，很多时候需要

23、强制停掉 HACMP 来进行，此时资源组不会释放，这样做的好处是，由于 IP 地址、文件系统等等没有任何影响，只是停掉 HACMP 本身，所以应用服务可以继续提供，实现了在线检查和变更 HACMP 的目的。host1root/smitty clstop Stop Cluster ServicesType or select values in entry fields.Press Enter AFTER making all desired changes.* Stop now, on system restart or both now Stop Cluster Services on th

24、ese nodes host1 BROADCAST cluster shutdown? true* Shutdown mode forced 一般所有节点都要进行这样操作。强制停掉后的 HACMP 启动 :在修改 HACMP 的配置后，大多数情况下需要重新申请资源启动，这样才能使 HACMP 的配置重新生效。host1root/smitty clstart Start Cluster ServicesType or select values in entry fields.Press Enter AFTER making all desired changes. Entry Fields*

25、Start now, on system restart or both now Start Cluster Services on these nodes bgbcb04 BROADCAST message at startup? true Startup Cluster Information Daemon? false Reacquire resources after forced down ? true 日常检查及处理为了更好地维护 HACMP，平时的检查和处理是必不可少的。下面提供的检查和处理方法除非特别说明，均是不用停机，而只需停止应用即可进行，不影响用户使用。不过具体实施前需要

26、仔细检查状态，再予以实施。当然，最有说服力的检查和验证是通过”运维切换测试“。clverify 检查这个检查可以对包括 LVM 的绝大多数 HACMP 的配置同步状态，是 HACMP 检查是否同步的主要方式。smitty clverify-Verify HACMP Configuration Verify ClusterType or select values in entry fields.Press Enter AFTER making all desired changes. Entry FieldsBase HACMP Verification Methods both(Cluste

27、r topology, resources, both, none)Custom Defined Verification Methods Error Count Log File to store output Verify changes only? NoLogging Standard回车即可经过检查，结果应是 OK。如果发现不一致，需要区别对待。对于非 LVM 的报错，大多数情况下不用停止应用，可以用以下步骤解决：1. 先利用强制方式停止 HACMP 服务。同样停止 host2 的 HACMP 服务。1. 只检查出的问题进行修正和同步：smitty hacmp -Extended Co

28、nfiguration-Extended Verification and Synchronization这时由于已停止 HACMP 服务，可以包括”自动修正和强制同步 “。对于 LVM 的报错，一般是由于未使用 HACMP 的 C-SPOC 功能，单边修改文件系统、lv、VG 造成的，会造成 VG 的 timestamp 不一致。这种情况即使手工在另一边修正（通常由于应用在使用，也不能这样做），如何选取自动修正的同步，也仍然会报 failed。此时只能停掉应用，通过整理 VG 来解决。cldump 检查：cldump 的监测为将当前 HACMP 的状态快照，确认显示为 UP，STABLE。host1root/usr/sbin/cluster/utilities/cldump_Cluster Name: test_clusterCluster State: UPCluster Substate: STABLE_Node Name: host1 State: UP Net