HACMP 5x 完全手册 第3部分 测试和维护.docx
《HACMP 5x 完全手册 第3部分 测试和维护.docx》由会员分享，可在线阅读，更多相关《HACMP 5x 完全手册 第3部分 测试和维护.docx（29页珍藏版）》请在冰点文库上搜索。
HACMP5x完全手册第3部分测试和维护
HACMP5.x完全手册，第3部分：
测试和维护
辛旻 （xinmin@）,IBM主机工程师,上海宝信软件股份有限公司
简介：
本系列文章的作者通过自己长期的实际项目工作经历，总结出了他对于HACMP设计实施的经验。
本系列会分为4部分，会向您详细地介绍实施HACMP过程中会经历的各个过程，如设计，配置，安装，测试等。
本文为第3部分，会向您介绍在HACMP安装配置完毕后需要进行的测试工作，以及在HACMP正式上线后需要定期进行的维护工作。
本文的标签：
aix, hacmp, 安装, 工具与及实用程序, 故障检修, 系统管理
标记本文！
发布日期：
2008年4月17日
访问情况：
4368次浏览
评论：
0 （查看 | 添加评论 -登录）
平均分（8个评分）
为本文评分
测试部分
虽然HACMP提供了自动化测试工具testtool，使用起来也较为简单。
但个人认为由于HACMP的完整测试是一个比较复杂的事情，工具还不能说非常成熟，也无法模拟交换机等故障，所以只能提供协助，不能完全依靠，结果仅供参考。
测试方法说明：
1.ping测试：
从client同时发起，每次1024个字节，延续10分钟。
2.ping长测试：
每次1024个字节，延续24小时。
3.应用测试：
利用自动化测试工具持续从client连接应用服务使用查询。
4.应用长测试:
48小时内，进行应用测试使用。
5.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种情况没有细化，需要注意。
1.同一网络有2个服务IP地址，考虑到负载均衡， 将自动分别落在boot1、boot2上 ，这样不论那个网卡有问题，都会发生地址漂移。
2.应用中断没有加入应用的重新连接时间，如oracleDB发生漂移，实际tuxedo需要重新启动才可继续连接，这个需要起停脚本来实现。
完全测试表
序号
测试场景
系统结果
应用结果
参考时长
功能测试
1
host2起HA
host2服务IP地址生效，vg、文件系统生效
host2app（db）启动OK
120s
2
host2停HA
host2服务IP地址、vg释放
host2app停止
15s
3
host1起HA
host1服务IP地址生效，vg、文件系统生效
host1app启动OK
120s
4
host1停HA
host1网卡、vg释放
host2app停止
15s
5
host2takeover到host1
host2服务地址切换到host1的boot2和vg切换到host1
host2app短暂中断
30s
host2clstart
恢复原状
host2app短暂中断
120s
6
host1takeover到host2
host1服务地址切换到host2的boot2和vg等切换到host2
host1app短暂中断
30s
host1clstart
恢复原状
host1app短暂中断
120s
网卡异常测试
1
host2断开boot1网线
host2的服务IP从boot1漂移至boot2
host2app短暂中断
30s
host2恢复boot1网线连接
host2boot1join
无影响
40s
2
host2断开boot2网线
host2的服务IP从boot2漂移至boot1
host2app短暂中断
30s
host2恢复boot2网线连接
host2boot1join
无影响
40s
3
host2断开boot1、boot2网线
host2服务地址切换到host1的boot2上，vg等切换到host1
host2app短暂中断
210s
host1再断开boot2网线，
host2的服务IP漂移到host1的boot1
host2app短暂中断
30s
host2恢复boot1、boot2网线连接
host2boot1，boot2join
无影响
30s
host2clstart
恢复原状
host2app短暂中断开
120s
4
host1断开boot1、boot2网线
host1服务地址切换到host2的boot2上，vg等切换到host2
host1app短暂中断
210s
host2再断开boot2网线，
host1的服务IP漂移到host2的boot1
host1app短暂中断
30s
host1恢复boot1、boot2网线链接
host1boot1，boot2join
无影响
30s
host2clstart
恢复原状
host2app短暂中断
120s
5
host2forceclstop
cluster服务停止，IP、vg资源无反应
无影响
20s
host2clstart
恢复原状
无影响
20s
6
host1forceclstop
cluster服务停止，IP、vg资源无反应
无影响
20s
host1clstart
恢复原状
无影响
20s
7
host2,host1boot2网线同时断开30mins
boot2failed
无影响
20s
host2,host1boot2网线恢复
boot2均join
无影响
20s
8
host2,host1boot1网线同时断开30mins
服务IP地址均漂移到boot2上。
host1,host2app短暂中断
30s
host2,host1boot1网线恢复
boot1均join
无影响
20s
主机宕机测试
1
host2突然宕机halt-q
host2服务地址切换到host1的boot2和vg等切换到host1
host2app短暂中断
30s
host2clstart
恢复原状
host2app短暂中断
120s
2
host1突然宕机halt-q
host1服务地址切换到host2的boot2和vg等切换到host2
host1app短暂中断
30s
host1clstart
恢复原状
host1app短暂中断
120s
交换机异常测试
1
SwitchA断电
服务IP地址均漂移到boot2上
host1、host2app短暂中断
50s
SwitchA恢复
boot1join
无影响
40s
SwitchB断电
服务IP地址均漂移回boot1上
host1、host2app短暂中断
50s
SwitchB恢复
boot2join
无影响
40s
2
SwitchB断电
boot2failed
无影响
50s
SwitchB恢复
boot2join
无影响
40s
SwitchA断电
服务IP地址均漂移到boot2上。
host1、host2app短暂中断
50s
SwitchA恢复
boot1join
无影响
40s
3
SwitchA，B同时断电10mins
network报down，其他一切不动。
host1、host2app中断
10min
SwitchA，B恢复
boot1，boot2join
服务自动恢复
50s
4
SwitchA断电
服务IP地址均漂移到boot2上
host1、host2app短暂中断
50s
30s后B也断电
不动
host1、host2app中断
50s
SwitchA，B恢复
boot1join
自动恢复
40s
5
SwitchB断电
boot2failed
无影响
50s
30s后A也断电
network报down，其他一切不动。
host1、host2app中断
50s
SwitchA，B恢复
boot1join
自动恢复
40s
6
SwitchA异常（对接网线触发广播风暴）
机器本身正常，但网络不通
host1、host2app中断
20s
SwitchA恢复
恢复后一切正常
自动恢复
7
SwitchB异常（对接网线触广播风暴）
机器本身正常，但网络不通
恢复后一切正常
host1、host2app中断
20s
SwitchB恢复
自动恢复
8
SwitchA，B同时异常（对接网线触广播风暴）
机器本身正常，但网络丢包严重，
host1、host2app中断
10s
SwitchA，B恢复
恢复后一切正常
自动恢复
20s
稳定性测试
1
host2，host1各起HA
正常服务
2
host2takeover切换host1
正常服务
3
host1takeover到host2
正常服务
运维切换测试：
运维切换测试是为了在运维过程中，保证高可靠性加以实施。
建议每年实施一次。
因为这样的测试实际是一种演练，能够及时发现各方面的问题，为故障期间切换成功提供有效保证。
运维切换测试表
场景
建议时长
切换方式
主备（run->dev）
主切换到备机
>10天
备机开发测试停用或临时修改HA配置
互备（app<->db,app<->app,db<->db）
互相切换
>30天
手工互相交叉启动资源组
主机切换到备机：
有2种方式：
∙可用takeover方式,但由于负荷和防止误操作的原因，备机的开发测试环境一般需要停用。
∙也可通过修改HA的配置，将备机资源组的节点数增加运行节点。
这样可以在切换测试期间继续使用开发测试环境。
但这样不光要对HA有所改动。
还要预先配置时就要保证备机开发测试环境也不是放在本地盘上，需要放在共享vg里，此外还要同步开发测试的环境到运行机。
建议最好在设计时就有这样的考虑。
手工互相切换：
停掉资源组：
smittyhacmp->SystemManagement（C-SPOC）
->HACMPResourceGroupandApplicationManagement
->BringaResourceGroupOffline选择host2_RG,host2
BringaResourceGroupOffline
Typeorselectvaluesinentryfields.
PressEnterAFTERmakingalldesiredchanges.
[EntryFields]
ResourceGrouptoBringOfflinehost2_RG
NodeOnWhichtoBringResourceGroupOfflinehost2
PersistAcrossClusterReboot?
false
同样停掉host1_RG
互换资源组：
smittyhacmp->SystemManagement（C-SPOC）
->HACMPResourceGroupandApplicationManagement
->BringaResourceGroupOnline选择host2_RG,host1
ResourceGrouptoBringOnlinehost2_RG
NodeonWhichtoBringResourceGroupOnlinehost1
PersistAcrossClusterReboot回答No。
即在host1上启动host2的资源组，同样方法在host2上启动host1资源组。
这样2台机器就实现了互换。
注意：
由于互切需要人工干预，恢复原状也要人工干预，所以切换期间需要密切监控运行状况，如方便出现有异常时，能立刻人工处理。
互换crontab及相关后台脚本：
由于备份作业等crontab里的后台作业会有所不同，所以需要进行互换，按我们的做法只需拷贝相应crontab的配置文件即可。
[host1][root][/]>cp/home/scripts/host2/crontab_host2/var/spool/cron/crontabs/root
修改文件属性：
[host1][root][/]>chownroot:
cron/var/spool/cron/crontabs/root
[host1][root][/]>chmod600/var/spool/cron/crontabs/root
重起crontab:
[host1][root][/]> ps-ef|grepcron
root27868810Dec19-0:
02/usr/sbin/cron
[host1][root][/]>kill-9278688
如果不采用我们脚本的做法，除需要拷贝对方的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][/]>smittyclstop
StopClusterServices
Typeorselectvaluesinentryfields.
PressEnterAFTERmakingalldesiredchanges.
*Stopnow,onsystemrestartorbothnow
StopClusterServicesonthesenodes[host1]
BROADCASTclustershutdown?
true
*Shutdownmodeforced
一般所有节点都要进行这样操作。
强制停掉后的HACMP启动:
在修改HACMP的配置后，大多数情况下需要重新申请资源启动，这样才能使HACMP的配置重新生效。
[host1][root][/]>smittyclstart
StartClusterServices
Typeorselectvaluesinentryfields.
PressEnterAFTERmakingalldesiredchanges.
[EntryFields]
*Startnow,onsystemrestartorbothnow
StartClusterServicesonthesenodes[bgbcb04]
BROADCASTmessageatstartup?
true
StartupClusterInformationDaemon?
false
Reacquireresourcesafterforceddown?
true
日常检查及处理
为了更好地维护HACMP，平时的检查和处理是必不可少的。
下面提供的检查和处理方法除非特别说明，均是不用停机，而只需停止应用即可进行，不影响用户使用。
不过具体实施前需要仔细检查状态，再予以实施。
当然，最有说服力的检查和验证是通过”运维切换测试“。
clverify检查
这个检查可以对包括LVM的绝大多数HACMP的配置同步状态，是HACMP检查是否同步的主要方式。
smittyclverify -> VerifyHACMPConfiguration
VerifyCluster
Typeorselectvaluesinentryfields.
PressEnterAFTERmakingalldesiredchanges.
[EntryFields]
BaseHACMPVerificationMethodsboth
（Clustertopology,resources,both,none）
CustomDefinedVerificationMethods[]
ErrorCount[]
LogFiletostoreoutput[]
Verifychangesonly?
[No]
Logging[Standard]
回车即可
经过检查，结果应是OK。
如果发现不一致，需要区别对待。
对于非LVM的报错，大多数情况下不用停止应用，可以用以下步骤解决：
1.先利用强制方式停止HACMP服务。
同样停止host2的HACMP服务。
1.只检查出的问题进行修正和同步 ：
smittyhacmp-> ExtendedConfiguration-> ExtendedVerificationandSynchronization
这时由于已停止HACMP服务，可以包括”自动修正和强制同步“。
对于LVM的报错，一般是由于未使用HACMP的C-SPOC功能，单边修改文件系统、lv、VG造成的，会造成VG的timestamp不一致。
这种情况即使手工在另一边修正（通常由于应用在使用，也不能这样做），如何选取自动修正的同步，也仍然会报failed。
此时只能停掉应用，通过整理VG来解决。
cldump检查：
cldump的监测为将当前HACMP的状态快照，确认显示为UP，STABLE。
[host1][root][/]>/usr/sbin/cluster/utilities/cldump
____________________________________________________________________________
ClusterName:
test_cluster
ClusterState:
UP
ClusterSubstate:
STABLE
_____________________________________________________________________________
NodeName:
host1State:
UP
Net
升级会员 