HACMP 5.x 完全手册，第 3 部分：测试和维护
2008-11-12 10:55:18 来源：WEB开发网测试部分
虽然 HACMP 提供了自动化测试工具 test tool，使用起来也较为简单。但个人认为由于 HACMP 的完整测试是一个比较复杂的事情，工具还不能说非常成熟，也无法模拟交换机等故障，所以只能提供协助，不能完全依靠，结果仅供参考。
测试方法说明：
ping 测试：从 client 同时发起，每次 1024 个字节，延续 10 分钟。
ping 长测试：每次 1024 个字节，延续 24 小时。
应用测试：利用自动化测试工具持续从 client 连接应用服务使用查询。
应用长测试 :48 小时内，进行应用测试使用。
telnet 测试：telnet 连接后根据情况确认。
标准测试
这个测试为必须完成的测试，每个网段都要做一次，阶段一般为初始配置阶段，运维定修阶段。
标准测试表
| 序号 | 测试步骤 | 系统结果 | 应用结果 |
| 1 | 拔掉 host1 的服务 IP 的网线 | 地址漂移到另一个网卡 | 中断 30s 左右可继续使用 |
| 2 | 拔掉 host1 剩下的一根网线 | 发生切换 | 中断 5 分钟左右可继续使用 |
| 3 | 拔掉 host2 的服务 IP 网线 | 所有服务地址漂到另一个网卡 | 中断 30s 左右可继续使用 |
| 4 | 恢复所有网线 | 地址 join，clstat 可看到所有节点均 恢复原始状态。 | 无影响 |
| 5 | 在 host2 上执行 ha1t -q | host2 机宕机，切换到 host1 机 | 中断 5 分钟左右可继续使用 |
| 启动 host2 恢复原始状态 | |||
| 1 | 拔掉 host2 的服务 IP 网线 | 地址漂另一个网卡 | 中断 30s 左右可继续使用 |
| 2 | 拔掉 host2 的剩下一根的网线 | 发生切换 | 中断 5 分钟左右可继续使用 |
| 3 | 拔掉 host1 的服务 IP 网线 | 所有服务地址漂到另一网卡 | 中断 30s 左右可继续使用 |
| 4 | 恢复所有网线 | 地址 join，clstat 可看到均 up | 无影响 |
| 5 | 在 host1 上执行 halt -q | host1 机宕机，切换到 host2 机 | 中断 5 分钟左右可继续使用 |
完全测试
完全测试在有充分测试时间和测试条件（如交换机可参与测试）下进行，阶段一般为系统上线前一周。
注意：考虑到下表的通用性，有 2 种情况没有细化，需要注意。
同一网络有 2 个服务 IP 地址，考虑到负载均衡， 将自动分别落在 boot1、boot2 上 ，这样不论那个网卡有问题，都会发生地址漂移。
应用中断没有加入应用的重新连接时间，如 oracleDB 发生漂移，实际 tuxedo 需要重新启动才可继续连接，这个需要起停脚本来实现。
完全测试表
| 序号 | 测试场景 | 系统结果 | 应用结果 | 参考时长 |
| 功能测试 | ||||
| 1 | host2 起 HA | host2 服务 IP 地址生效，vg、文件系统生效 | host2 app(db) 启动 OK | 120s |
| 2 | host2 停 HA | host2 服务 IP 地址、vg 释放 | host2 app 停止 | 15s |
| 3 | host1 起 HA | host1 服务 IP 地址生效，vg、文件系统生效 | host1 app 启动 OK | 120s |
| 4 | host1 停 HA | host1 网卡、vg 释放 | host2 app 停止 | 15s |
| 5 | host2 takeover 到 host1 | host2 服务地址切换到 host1 的 boot2 和 vg 切换到 host1 | host2 app 短暂中断 | 30s |
| host2 clstart | 恢复原状 | host2 app 短暂中断 | 120s | |
| 6 | host1 takeover 到 host2 | host1 服务地址切换到 host2 的 boot2 和 vg 等切换到 host2 | host1 app 短暂中断 | 30s |
| host1 clstart | 恢复原状 | host1 app 短暂中断 | 120s | |
| 网卡异常测试 | ||||
| 1 | host2 断开 boot1 网线 | host2 的服务 IP 从 boot1 漂移至 boot2 | host2 app 短暂中断 | 30s |
| host2 恢复 boot1 网线连接 | host2 boot1 join | 无影响 | 40s | |
| 2 | host2 断开 boot2 网线 | host2 的服务 IP 从 boot2 漂移至 boot1 | host2 app 短暂中断 | 30s |
| host2 恢复 boot2 网线连接 | host2 boot1 join | 无影响 | 40s | |
| 3 | host2 断开 boot1、boot2 网线 | host2 服务地址切换到 host1 的 boot2 上，vg 等切换到 host1 | host2 app 短暂中断 | 210s |
| host1 再断开 boot2 网线， | host2 的服务 IP 漂移到 host1 的 boot1 | host2 app 短暂中断 | 30s | |
| host2 恢复 boot1、boot2 网线连接 | host2 boot1，boot 2join | 无影响 | 30s | |
| host2 clstart | 恢复原状 | host2 app 短暂中断开 | 120s | |
| 4 | host1 断开 boot1、boot2 网线 | host1 服务地址切换到 host2 的 boot2 上，vg 等切换到 host2 | host1 app 短暂中断 | 210s |
| host2 再断开 boot2 网线， | host1 的服务 IP 漂移到 host2 的 boot1 | host1 app 短暂中断 | 30s | |
| host1 恢复 boot1、boot2 网线链接 | host1 boot1，boot 2join | 无影响 | 30s | |
| host2 clstart | 恢复原状 | host2 app 短暂中断 | 120s | |
| 5 | host2 force clstop | cluster 服务停止，IP、vg 资源无反应 | 无影响 | 20s |
| host2 clstart | 恢复原状 | 无影响 | 20s | |
| 6 | host1 force clstop | cluster 服务停止，IP、vg 资源无反应 | 无影响 | 20s |
| host1 clstart | 恢复原状 | 无影响 | 20s | |
| 7 | host2,host1 boot2 网线同时断开 30mins | boot2 failed | 无影响 | 20s |
| host2,host1 boot2 网线恢复 | boot2 均 join | 无影响 | 20s | |
| 8 | host2,host1 boot1 网线同时断开 30mins | 服务 IP 地址均漂移到 boot2 上。 | host1,host2 app 短暂中断 | 30s |
| host2,host1 boot1 网线恢复 | boot1 均 join | 无影响 | 20s | |
| 主机宕机测试 | ||||
| 1 | host2 突然宕机 halt -q | host2 服务地址切换到 host1 的 boot2 和 vg 等切换到 host1 | host2 app 短暂中断 | 30s |
| host2 clstart | 恢复原状 | host2 app 短暂中断 | 120s | |
| 2 | host1 突然宕机 halt -q | host1 服务地址切换到 host2 的 boot2 和 vg 等切换到 host2 | host1 app 短暂中断 | 30s |
| host1 clstart | 恢复原状 | host1 app 短暂中断 | 120s | |
| 交换机异常测试 | ||||
| 1 | SwitchA 断电 | 服务 IP 地址均漂移到 boot2 上 | host1、host2 app 短暂中断 | 50s |
| SwitchA 恢复 | boot1 join | 无影响 | 40s | |
| SwitchB 断电 | 服务 IP 地址均漂移回 boot1 上 | host1、host2 app 短暂中断 | 50s | |
| SwitchB 恢复 | boot2 join | 无影响 | 40s | |
| 2 | SwitchB 断电 | boot2 failed | 无影响 | 50s |
| SwitchB 恢复 | boot2 join | 无影响 | 40s | |
| SwitchA 断电 | 服务 IP 地址均漂移到 boot2 上。 | host1、host2 app 短暂中断 | 50s | |
| SwitchA 恢复 | boot1 join | 无影响 | 40s | |
| 3 | SwitchA，B 同时断电 10mins | network 报 down，其他一切不动。 | host1、host2 app 中断 | 10min |
| SwitchA，B 恢复 | boot1，boot2 join | 服务自动恢复 | 50s | |
| 4 | SwitchA 断电 | 服务 IP 地址均漂移到 boot2 上 | host1、host2 app 短暂中断 | 50s |
| 30s 后 B 也断电 | 不动 | host1、host2 app 中断 | 50s | |
| SwitchA，B 恢复 | boot1 join | 自动恢复 | 40s | |
| 5 | SwitchB 断电 | boot2 failed | 无影响 | 50s |
| 30s 后 A 也断电 | network 报 down，其他一切不动。 | host1、host2 app 中断 | 50s | |
| SwitchA，B 恢复 | boot1 join | 自动恢复 | 40s | |
| 6 | SwitchA 异常（对接网线触发广播风暴） | 机器本身正常，但网络不通 | host1、host2 app 中断 | 20s |
| SwitchA 恢复 | 恢复后一切正常 | 自动恢复 | ||
| 7 | SwitchB 异常（对接网线触广播风暴） | 机器本身正常，但网络不通 恢复后一切正常 | host1、host2 app 中断 | 20s |
| SwitchB 恢复 | 自动恢复 | |||
| 8 | SwitchA，B 同时异常（对接网线触广播风暴） | 机器本身正常，但网络丢包严重， | host1、host2 app 中断 | 10s |
| SwitchA，B 恢复 | 恢复后一切正常 | 自动恢复 | 20s | |
| 稳定性测试 | ||||
| 1 | host2， host1 各起 HA | 正常服务 | ||
| 2 | host2 takeover 切换 host1 | 正常服务 | ||
| 3 | host1 takeover 到 host2 | 正常服务 |
运维切换测试：
运维切换测试是为了在运维过程中，保证高可靠性加以实施。建议每年实施一次。因为这样的测试实际是一种演练，能够及时发现各方面的问题，为故障期间切换成功提供有效保证。
运维切换测试表
| 场景 | 建议时长 | 切换方式 | |
| 主备（run->dev） | 主切换到备机 | >10 天 | 备机开发测试停用或临时修改 HA 配置 |
| 互备（app <->db,app<->app,db<->db） | 互相切换 | >30 天 | 手工互相交叉启动资源组 |
主机切换到备机：
有 2 种方式：
可用 takeover 方式 , 但由于负荷和防止误操作的原因，备机的开发测试环境一般需要停用。
也可通过修改 HA 的配置，将备机资源组的节点数增加运行节点。这样可以在切换测试期间继续使用开发测试环境。但这样不光要对 HA 有所改动。还要预先配置时就要保证备机开发测试环境也不是放在本地盘上，需要放在共享 vg 里，此外还要同步开发测试的环境到运行机。建议最好在设计时就有这样的考虑。
手工互相切换：
停掉资源组：
smitty hacmp->System Management (C-SPOC)
-> HACMP Resource Group and Application Management
->Bring a Resource Group Offline 选择 host2_RG,host2
Bring a Resource Group Offline
Type or select values in entry fields.
Press Enter AFTER making all desired changes.
[Entry Fields]
Resource Group to Bring Offline 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
Node on Which to Bring Resource Group Online host1
Persist Across Cluster Reboot 回答 No。
即在 host1 上启动 host2 的资源组，同样方法在 host2 上启动 host1 资源组。这样 2 台机器就实现了互换。
注意： 由于互切需要人工干预，恢复原状也要人工干预，所以切换期间需要密切监控运行状况，如方便出现有异常时，能立刻人工处理。
互换 crontab 及相关后台脚本：
由于备份作业等 crontab 里的后台作业会有所不同，所以需要进行互换，按我们的做法只需拷贝相应 crontab 的配置文件即可。
[host1][root][/]>cp /home/scripts/host2/crontab_host2 /var/spool/cron/crontabs/root
修改文件属性：
[host1][root][/]>chown root:cron /var/spool/cron/crontabs/root
[host1][root][/]>chmod 600 /var/spool/cron/crontabs/root
重起 crontab:
[host1][root][/]> ps -ef|grep cron
root 278688 1 0 Dec 19 - 0:02 /usr/sbin/cron
[host1][root][/]>kill -9 278688
如果不采用我们脚本的做法，除需要拷贝对方的 crontab 外，还要记得同步相应脚本。
互换备份策略：
由于备份方式不同，可能所作的调整也不一样，需要具体系统具体对待。实验环境中的备份采用后台作业方式，无须进一步处理。实际环境中可能采用备份软件，由于主机互换了，备份策略是否有效需要确认，如无效，需要做相应修正。
维护部分
作为高可用性的保证，通过了配置和测试之后，系统可以成功上线了，但不要忘记，HACMP 也需要精心维护才能在最关键的时刻发生作用，否则不光是多余的摆设，维护人员会由于“已经安装好 HA 了，关键时刻自然会发生作用”的想法反而高枕无忧，麻痹大意。
我们统计了以往遇到的切换不成功或误切换的场景，编制了测试成功切换却失败的原因及对策，如下表：
HACMP 切换问题表
| 故障现象 | 原因 | 根本原因 | 对策 |
| 无法切换 1 | 测试一段时间后两边 HA 不同步 | 没通过 HA 的功能（含 C-SPOC）进行用户、文件系统等系统变更。 | 制定和遵守规范，定期检查，定修及时处理 |
| 无法切换 2 | 应用停不下来，导致超时，文件系统不能 umount | 停止脚本问题 | 规范化增加 kill_vg_user 脚本 |
| 切换成功但应用不好用 | 应用启动异常 | 应用有变动，停止脚本异常停止或启动脚本不正确 | 规范化和及时更新起停脚本 |
| 切换成功但应用不好用 | 备机配置不符合运行要求 | 各类系统和软件参数不合适 | 制定检查规范初稿，通过运维切换测试检查确认。 |
| 切换成功但通信不好用 1 | 网络路由不通 | 网络配置原因 | 修正测试路由，通过运维切换测试检查确认。 |
| 切换成功但通信不好用 2 | 通信软件配置问题 | 由于一台主机同时漂移同一网段的 2 个服务地址，通信电文从另一个 IP 地址通信，导致错误 | 修正配置，绑定指定服务 IP。 |
| 误切换 | DMS 问题 | 系统负荷持续过高 | 参见《脚本和经验》部分。 |
注意：请记住，对于客户来说，不管什么原因，“应用中断超过了 5-10 分钟，就是 HACMP 切换不成功”，也意味着前面所有的工作都白费了，所以维护工作的重要性也是不言而谕的。
强制方式停掉 HACMP:
HACMP 的停止分为 3 种，graceful（正常），takeover（手工切换），force（强制）。
下面的维护工作，很多时候需要强制停掉 HACMP 来进行，此时资源组不会释放，这样做的好处是，由于 IP 地址、文件系统等等没有任何影响，只是停掉 HACMP 本身，所以应用服务可以继续提供，实现了在线检查和变更 HACMP 的目的。
[host1][root][/]>smitty clstop
Stop Cluster Services
Type 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 these nodes [host1]
BROADCAST cluster shutdown? true
* Shutdown mode forced
一般所有节点都要进行这样操作。
强制停掉后的 HACMP 启动 :
在修改 HACMP 的配置后，大多数情况下需要重新申请资源启动，这样才能使 HACMP 的配置重新生效。
[host1][root][/]>smitty clstart
Start Cluster Services
Type or select values in entry fields.
Press Enter AFTER making all desired changes.
[Entry Fields]
* 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，平时的检查和处理是必不可少的。下面提供的检查和处理方法除非特别说明，均是不用停机，而只需停止应用即可进行，不影响用户使用。不过具体实施前需要仔细检查状态，再予以实施。
当然，最有说服力的检查和验证是通过”运维切换测试“。
clverify 检查
这个检查可以对包括 LVM 的绝大多数 HACMP 的配置同步状态，是 HACMP 检查是否同步的主要方式。
smitty clverify -> Verify HACMP Configuration
Verify Cluster
Type or select values in entry fields.
Press Enter AFTER making all desired changes.
[Entry Fields]
Base HACMP Verification Methods both
(Cluster topology, resources, both, none)
Custom Defined Verification Methods []
Error Count []
Log File to store output []
Verify changes only? [No]
Logging [Standard]
回车即可
经过检查，结果应是 OK。如果发现不一致，需要区别对待。对于非 LVM 的报错，大多数情况下不用停止应用，可以用以下步骤解决：
先利用强制方式停止 HACMP 服务。
同样停止 host2 的 HACMP 服务。
只检查出的问题进行修正和同步 ：
smitty hacmp -> Extended Configuration-> Extended Verification and Synchronization
这时由于已停止 HACMP 服务，可以包括”自动修正和强制同步 “。
对于 LVM 的报错，一般是由于未使用 HACMP 的 C-SPOC 功能，单边修改文件系统、lv、VG 造成的，会造成 VG 的 timestamp 不一致。这种情况即使手工在另一边修正（通常由于应用在使用，也不能这样做），如何选取自动修正的同步，也仍然会报 failed。此时只能停掉应用，通过整理 VG 来解决。
cldump 检查：
cldump 的监测为将当前 HACMP 的状态快照，确认显示为 UP，STABLE。
[host1][root][/]>/usr/sbin/cluster/utilities/cldump
____________________________________________________________________________
Cluster Name: test_cluster
Cluster State: UP
Cluster Substate: STABLE
_____________________________________________________________________________
Node Name: host1 State: UP
Network Name: net_ether_01 State: UP
Address: 10.2.100.1 Label: host1_l1_svc1 State: UP
Address: 10.2.101.1 Label: host1_l1_svc2 State: UP
Address: 10.2.1.1 Label: host1_l1_boot1 State: UP
Address: 10.2.11.1 Label: host1_l1_boot2 State: UP
Network Name: net_ether_02 State: UP
Address: 10.2.200.1 Label: host1_l2_svc State: UP
Address: 10.2.2.1 Label: host1_l2_boot1 State: UP
Address: 10.2.12.1 Label: host1_l2_boot2 State: UP
Node Name: host2 State: UP
Network Name: net_ether_01 State: UP
Address: 10.2.100.2 Label: host2_l1_svc1 State: UP
Address: 10.2.101.2 Label: host2_l1_svc2 State: UP
Address: 10.2.1.2 Label: host2_l1_boot1 State: UP
Address: 10.2.11.2 Label: host2_l1_boot2 State: UP
Network Name: net_ether_02 State: UP
Address: 10.2.200.2 Label: host2_l2_svc State: UP
Address: 10.2.2.2 Label: host2_l2_boot1 State: UP
Address: 10.2.12.2 Label: host2_l2_boot2 State: UP
Cluster Name: test_cluster
Resource Group Name: host1_RG
Startup Policy: Online On Home Node Only
Fallover Policy: Fallover To Next Priority Node In The List
Fallback Policy: Fallback To Higher Priority Node In The List
Site Policy: ignore
Node State
--------------- ---------------
host1 ONLINE
host2 OFFLINE
Resource Group Name: host2_RG
Startup Policy: Online On Home Node Only
Fallover Policy: Fallover To Next Priority Node In The List
Fallback Policy: Fallback To Higher Priority Node In The List
Site Policy: ignore
Node State
--------------- ---------------
host2 ONLINE
host1 OFFLINE
clstat 检查
clstat 可以实时监控 HACMP 的状态，及时确认显示为 UP，STABLE
[host1][root][/]>/usr/sbin/cluster/clstat
注：如果没有反应，运行 clinfo
clstat - HACMP Cluster Status Monitor
-------------------------------------
Cluster: test_cluster (1145945461)
Sun Jul 2 16:54:16 BEIST 2006
State: UP Nodes: 2
SubState: STABLE
Node: host1 State: UP
Interface: host1_l2_boot1 (1) Address: 10.2.2.1
State: UP
Interface: host1_l1_boot1 (1) Address: 10.2.1.1
State: UP
Interface: host1_l1_boot2 (2) Address: 10.2.11.1
State: UP
Interface: host1_l2_boot2 (2) Address: 10.2.12.1
State: UP
Interface: host1_tty0_01(0) Address: 0.0.0.0
State: UP
Interface: host1_l1_svc1 (2) Address: 10.2.100.1
State: UP
Interface: host1_l1_svc2(2) Address: 10.2.101.1
State: UP
Interface: host1_l2_svc (2) Address: 10.2.200.1
State: UP
Resource Group: host1_RG State: On line
Node: host2 State: UP
Interface: host2_l2_boot1 (1) Address: 10.2.2.2
State: UP
Interface: host2_l1_boot1 (1) Address: 10.2.1.2
State: UP
Interface: host2_l1_boot2 (2) Address: 10.2.11.2
State: UP
Interface: host2_l2_boot2 (2) Address: 10.2.12.2
State: UP
Interface: host2_tty0_01(0) Address: 0.0.0.0
State: UP
Interface: host2_l1_svc1 (2) Address: 10.2.100.2
State: UP
Interface: host2_l1_svc2(2) Address: 10.2.101.2
State: UP
Interface: host2_l2_svc (2) Address: 10.2.200.2
State: UP
Resource Group: host2_RG State: On line
/etc/hosts 环境检查
正常情况下，2 台互备的 /etc/hosts 应该是一致的，当然如果是主备机方式，可能备机会多些 IP 地址和主机名。通过对比 2 个文件的不同，可以确认是否存在问题。
[host1][root][/]>rsh host2:/etc/hosts >/tmp/host2_hosts
[host1][root][/]>diff /etc/hosts /tmp/host2_hosts
脚本检查
需要注意以下事项：
应用的变更需要及时修正脚本，两边的脚本需要及时同步，并及时申请时间测试。
上一点需要维护人员充分与应用人员沟通，运行环境的任何变更必须通过维护人员实施。
维护人员启停应用要养成使用这些脚本启停的习惯，尽量避免手工启停。
[host1][root][/home/scripts]>rsh host2
"cd /home/scripts;ls -l host1 host2 comm" >/tmp/host2_scripts
[host1][root][/home/scripts]> ls -l host1 host2 comm" >/tmp/host1_scripts
[host1][root][/]>diff /tmp/host1_scripts /tmp/host2_scripts
用户检查
正常情况下，2 台互备的 HA 使用到的用户情况应该是一致的，当然如果是主备机方式，可能备机会多些用户。通过对比 2 节点的不同，可以确认是否存在问题。
[host1][root][/]>rsh host2 lsuser -f orarun,orarunc,tuxrun,bsx1,
xcom >/tmp/host2_users
[host1][root][/]> lsuser -f orarun,orarunc,tuxrun,bsx1,
xcom >/tmp/host1_users >/tmp/host1_users
[host1][root][/]>diff /tmp/host1_user /tmp/host2_user
注：两边的必然有些不同，如上次登录时间等等，只要主要部分相同就可以了。
还有两边 .profile 的对比，用户环境的对比。
[host1][root][/]>rsh host2 su - orarun -c set >/tmp/b
[host1][root][/]> su - orarun -c set >/tmp/a
[host1][root][/]>diff /tmp/a /tmp/b
tty 心跳检查
由于心跳在 HACMP 启动后一直由 HACMP 在使用，所以需要强制停掉 HACMP 进行检查。
察看 tty 速率
确认速率不超过 9600
[host1][root][/]>stty -a </dev/tty0
[host2][root][/]>cat /etc/hosts >/dev/tty0
host1 上显示
speed 9600 baud; 0 rows; 0 columns;
eucw 1:1:0:0, scrw 1:1:0:0:
…
检查连接和配置
[host1][root][/]>host1: cat /etc/hosts>/dev/tty0
[host2][root][/]>host2:cat</dev/tty0
在 host2 可看到 host1 上 /etc/hosts 的内容。
同样反向检测一下。
errpt 的检查
虽然有了以上许多检查，但我们最常看的 errpt 不要忽略，因为有些报错，需要大家引起注意，由于 crontab 里 HACMP 会增加这样一行：
0 0 * * * /usr/es/sbin/cluster/utilities/clcycle 1>/dev/null 2>/dev/null
# HACMP for AIX Logfile rotation
即实际上每天零点，系统会自动执行 HACMP 的检查，如果发现问题，会在 errpt 看到。
除了 HACMP 检查会报错，其他运行过程中也有可能报错，大都是由于心跳连接问题或负载过高导致 HACMP 进程无法处理，需要引起注意，具体分析解决。
变更及实现
由于维护的过程出现的情况远比集成实施阶段要复杂，即使红皮书也不能覆盖所有情况。这里只就大家常见的情况加以说明，对于更为复杂或者更为少见的情况，还是请大家翻阅红皮书，实在不行计划停机重新配置也许也是一个快速解决问题的笨方法。
这里的变更原则上是不希望停机，但实际上 HACMP 的变更，虽然说部分支持 DARE（dynamic reconfiguration），绝大部分操作支持 Force stop 完成， 我们还是希望有条件的话停机完成。
对于 DARE，我不是非常赞成使用，因为使用不当会造成集群不可控，危险性更大。我一般喜欢使用先强制停止 HACMP，再进行以下操作 , 结束同步确认后再 start HACMP。
卷组变更 - 增加磁盘到使用的 VG 里 :
注意，pvid 一定要先认出来，否则盘会没有或不正常。
集群的各个节点机器运行 cfgmgr，设置 pvid
[host1][root][/]>cfgmgr
[host1][root][/]>lspv
….
hdisk2 00c1eedf6ddb9f5e host1vg
hdisk3 00c1eedffa577b0e host2vg
hdisk4 none none
[host1][root][/]>chdev -l hdisk2 -a pv=yes
[host1][root][/]>lspv
….
hdisk4 00c1eedffc677bfe none
在 host2 上也要做同样操作。
运行 C-SPOC 增加盘到 host2vg:
smitty hacmp->System Management (C-SPOC)-> HACMP Logical Volume Management
->Shared Volume Groups-> Set Characteristics of a Shared Volume Group
->Add a Volume to a Shared Volume Group 选择节点 VG 和磁盘增加即可
Resouce Group Name host2_RG
VOLUME GROUP name hostvg
Reference node host2
VOLUME names hdisk4
完成后两边都可看到
hdisk3 00c1eedffa577b0e host2vg
hdisk4 00c1eedffc677bfe host2vg
lv 变更
lv 的变更不多，可以变更的部分如下：
smitty hacmp->System Management (C-SPOC)-> HACMP Logical Volume Management
->Show Characteristics of a Shared Logical Volume-> Shared Logical Volumes
->Change a Shared Logical Volume 选择 lv
* Resource Group Name host2_RG
MAXIMUM NUMBER of PHYSICAL VOLUMES [8]
[/ora10runc]
MAXIMUM NUMBER of LOGICAL PARTITIONS [512]
裸设备增加空间：
smitty hacmp->System Management (C-SPOC)-> HACMP Logical Volume Management
-> Shared Logical Volumes->Set Characteristics of a Shared Logical Volume
-> Increase the Size of a Shared Logical Volume
[Entry Fields]
Resource Group Name rac2_RG
LOGICAL VOLUME name XWFTPlv
Reference node rac2
* Number of ADDITIONAL logical partitions [100]
PHYSICAL VOLUME names hdisk3
POSITION on physical volume outer_middle
RANGE of physical volumes minimum
MAXIMUM NUMBER of PHYSICAL VOLUMES []
to use for allocation
Allocate each logical partition copy superstrict
on a SEPARATE physical volume?
File containing ALLOCATION MAP []
文件系统变更
smitty hacmp->System Management (C-SPOC)-> HACMP Logical Volume Management
->Shared File Systems->Enhanced Journaled File Systems
->Change / Show Characteristics of a Shared Enhanced Journaled File System
Resource Group Name bg595b02_RG
File system name /cube
NEW mount point [/cube]
SIZE of file system [6291456]
Mount GROUP []
PERMISSIONS read/write
Mount OPTIONS []
Start Disk Accounting? no
Block Size (bytes) 4096
Inline Log? no
Inline Log size (MBytes) 0
服务 IP 地址变更
增加服务 IP 地址
修改 /etc/hosts, 增加以下行
10.66.201.1 host1_l2_svc2
10.66.201.2 host2_l2_svc2
HACMP 新增服务 IP
smitty hacmp-> Extended Configuration-> HACMP Extended Resources Configuration
-> Configure HACMP Service IP Labels/Addresses
-> Add a Service IP Label/Address-> Configurable on Multiple Nodes 选择网络
Add a Service IP Label/Address configurable on Multiple Nodes (extended)
Type or select values in entry fields.
Press Enter AFTER making all desired changes.
* IP Label/Address host1_svc2
* Network Name net_ether_01
Alternate HW Address to accompany IP Label/Address []
同样增加 host2_svc2
修正资源组
smitty hacmp->Extended Configuration->Extended Resource Configuration
->HACMP Extended Resource Group Configuration
->Change/Show Resources and Attributes for a Resource Group
->Change/Show All Resources and Attributes for a Resource Group
Type or select values in entry fields.
Press Enter AFTER making all desired changes.
[Entry Fields]
Resource Group Name eai1d0_RG
Participating Nodes (Default Node Priority) bgbcb11 bgbcb04
Startup Policy Online On Home Node Only
Fallover Policy Fallover To Next Priority
Node In The List
Fallback Policy Fallback To Higher Priority
Node In The List
Fallback Timer Policy (empty is immediate) []
Service IP Labels/Addresses [host1_svc host1_svc2]
HACMP 同步
需要同步，参见第 2 部分的“检查和同步 HACMP 配置”一节。
HACMP 启动
注意修改启动参数使得启动时重新申请资源，触发新增服务 IP 生效。
这时 netstat -in，可以看到地址生效了。
修改服务 IP 地址
如果要修改应用服务使用的 IP 地址，自然是需要停止应用来进行的。比如要将原地址 10.2.200.x 改为 10.2.201.x，路由改为 10.2.201.254 步骤如下：
正常停止 HACMP
smitty clstop ->graceful
所有节点修改 /etc/hosts 将服务地址修改为需要的地址
10.2.201.1 host1_l2_svc host1
10.2.201.2 host2_l2_svc host2
修改启动脚本的路由部分（如果需要）
GATEWAY=10.2.201.254
在一个节点修改 HACMP 的配置
smitty hacmp->Extended Configuration-> HACMP Extended Resources Configuration
->Configure HACMP Service IP Labels/Addresses
->Change/Show a Service IP Label/Address 选择 host1_l2_svc
不做修改 ，直接回车即可，同样修改 host2 璤 l2_svc。
smitty hacmp->Extended Configuration->Extended Resource Configuration
->HACMP Extended Resource Group Configuration
->Change/Show Resources and Attributes for a Resource Group
->Change/Show All Resources and Attributes for a Resource Group 选择 host1_RG
不做修改 ，直接回车即可，同样修改 host2 璤 RG
同步 HACMP。
重新启动 HACMP 并确认。
注意修改启动参数使得启动时重新申请资源，触发新服务 IP 地址生效。
注意： 如果修改的不是应用服务要用的地址，或者修改期间对该地址的服务可以暂停，则可以将步骤 1 改为强制停止，增加第 7 步。整个过程可以不停应用服务。
7. 去除原有服务 IP 地址
netstat -in 找到该服务 IP 地址所在网卡 en2。然后执行：
ifconfig en2 alias delete 10.2.200.1
boot 地址变更
smitty tcpip 修改网卡的地址
修改 /etc/hosts 的 boot 地址
修改 HACMP 配置
smitty hacmp ->Extended Configuration-> Extended Topology Configuration
-> Extended Topology Configuration
Change/Show a Communication Interface
Node Name [bgbcb04]
Network Interface en1
IP Label/Address bgbcb04_boot1
Network Type ether
* Network Name [net_ether_01]
不做修改 ，直接回车即可，同样修改其他 boot 地址。
同步 HACMP
重新启动 HACMP 确认
注意：修改启动参数使得启动时重新申请资源，触发新 boot IP 地址生效，否则 clstat 看到的 boot 地址将是 down。
用户变更
修改用户口令
由于安全策略的原因，系统可能需要更改口令，利用 HACMP 会方便不少，也避免切换过去后因时隔太久，想不起口令需要强制修改的烦恼。
唯一设计不合理的是，必须 root 才能使用这个功能。
smitty hacmp ->Extended Configuration-> Security and Users Configuration
-> Passwords in an HACMP cluster
-> Change a User's Password in the Cluster
Selection nodes by resource group host2_RG
*** No selection means all nodes! ***
* User NAME [orarun]
User must change password on first login? false
此时需要你输入新口令更改：
COMMAND STATUS
Command: running stdout: no stderr: no
Before command completion, additional instructions may appear below.
orarun's New password:
Enter the new password again:
OK 即成功
修改用户属性
以下步骤可变更用户属性，值得注意的是，虽然可以直接修改用户的 UID，但实际上和在单独的操作系统一样， 不会自动修改该用户原有的文件和目录的属性，必须事后自己修改 ，所以建议 UID 在规划阶段就早做合理规划。
smitty hacmp ->Extended Configuration-> Security and Users Configuration
->Users in an HACMP cluster
-> Change / Show Characteristics of a User in the Cluster
选择资源组和用户
除开头 1 行，其他使用均等同于独立操作系统。
Change User Attributes on the Cluster
Resource group eai1d0_RG
* User NAME test
User ID [301]
ADMINISTRATIVE USER? false
….
小结
本部分主要对 HACMP 的测试和日常维护进行了较为详尽的描述，基本上是我们的实际工作总结，相信读者可以从中得到启发，对日常 HACMP 的维护相信很有帮助。后面一部分将论述富有特色的脚本管理和特殊情况下的经验总结，这部分几乎没有看到在以往资料中提及，相信大家也会感兴趣。
中查找“HACMP 5.x 完全手册，第 3 部分：测试和维护”更多相关内容
中查找“HACMP 5.x 完全手册，第 3 部分：测试和维护”更多相关内容更多精彩
赞助商链接
