HACMP 5x 完全手册 第3部分 测试和维护Word格式文档下载.docx
《HACMP 5x 完全手册 第3部分 测试和维护Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《HACMP 5x 完全手册 第3部分 测试和维护Word格式文档下载.docx（29页珍藏版）》请在冰点文库上搜索。
2.ping长测试：
每次1024个字节，延续24小时。
3.应用测试：
利用自动化测试工具持续从client连接应用服务使用查询。
4.应用长测试:
48小时内，进行应用测试使用。
5.telnet测试：
telnet连接后根据情况确认。
标准测试
这个测试为必须完成的测试，每个网段都要做一次，阶段一般为初始配置阶段，运维定修阶段。
标准测试表
序号
测试步骤
系统结果
应用结果
1
拔掉host1的服务IP的网线
地址漂移到另一个网卡
中断30s左右可继续使用
2
拔掉host1剩下的一根网线
发生切换
中断5分钟左右可继续使用
3
拔掉host2的服务IP网线
所有服务地址漂到另一个网卡
4
恢复所有网线
地址join，clstat可看到所有节点均
恢复原始状态。
无影响
5
在host2上执行ha1t-q
host2机宕机，切换到host1机
启动host2恢复原始状态
地址漂另一个网卡
拔掉host2的剩下一根的网线
拔掉host1的服务IP网线
所有服务地址漂到另一网卡
地址join，clstat可看到均up
在host1上执行halt-q
host1机宕机，切换到host2机
完全测试
完全测试在有充分测试时间和测试条件（如交换机可参与测试）下进行，阶段一般为系统上线前一周。
注意：
考虑到下表的通用性，有2种情况没有细化，需要注意。
1.同一网络有2个服务IP地址，考虑到负载均衡，
将自动分别落在boot1、boot2上
，这样不论那个网卡有问题，都会发生地址漂移。
2.应用中断没有加入应用的重新连接时间，如oracleDB发生漂移，实际tuxedo需要重新启动才可继续连接，这个需要起停脚本来实现。
完全测试表
测试场景
参考时长
功能测试
host2起HA
host2服务IP地址生效，vg、文件系统生效
host2app（db）启动OK
120s
host2停HA
host2服务IP地址、vg释放
host2app停止
15s
host1起HA
host1服务IP地址生效，vg、文件系统生效
host1app启动OK
host1停HA
host1网卡、vg释放
host2takeover到host1
host2服务地址切换到host1的boot2和vg切换到host1
host2app短暂中断
30s
host2clstart
恢复原状
6
host1takeover到host2
host1服务地址切换到host2的boot2和vg等切换到host2
host1app短暂中断
host1clstart
host1app短暂中断
网卡异常测试
host2断开boot1网线
host2的服务IP从boot1漂移至boot2
host2恢复boot1网线连接
host2boot1join
40s
host2断开boot2网线
host2的服务IP从boot2漂移至boot1
host2恢复boot2网线连接
host2断开boot1、boot2网线
host2服务地址切换到host1的boot2上，vg等切换到host1
210s
host1再断开boot2网线，
host2的服务IP漂移到host1的boot1
host2恢复boot1、boot2网线连接
host2boot1，boot2join
host2app短暂中断开
host1断开boot1、boot2网线
host1服务地址切换到host2的boot2上，vg等切换到host2
host2再断开boot2网线，
host1的服务IP漂移到host2的boot1
host1恢复boot1、boot2网线链接
host1boot1，boot2join
host2forceclstop
cluster服务停止，IP、vg资源无反应
20s
host1forceclstop
7
host2,host1boot2网线同时断开30mins
boot2failed
host2,host1boot2网线恢复
boot2均join
8
host2,host1boot1网线同时断开30mins
服务IP地址均漂移到boot2上。
host1,host2app短暂中断
host2,host1boot1网线恢复
boot1均join
主机宕机测试
host2突然宕机halt-q
host2服务地址切换到host1的boot2和vg等切换到host1
host1突然宕机halt-q
交换机异常测试
SwitchA断电
服务IP地址均漂移到boot2上
host1、host2app短暂中断
50s
SwitchA恢复
boot1join
SwitchB断电
服务IP地址均漂移回boot1上
SwitchB恢复
boot2join
SwitchA，B同时断电10mins
network报down，其他一切不动。
host1、host2app中断
10min
SwitchA，B恢复
boot1，boot2join
服务自动恢复
SwitchA断电
30s后B也断电
不动
自动恢复
SwitchB断电
30s后A也断电
SwitchA异常（对接网线触发广播风暴）
机器本身正常，但网络不通
恢复后一切正常
SwitchB异常（对接网线触广播风暴）
SwitchA，B同时异常（对接网线触广播风暴）
机器本身正常，但网络丢包严重，
10s
稳定性测试
host2，host1各起HA
正常服务
host2takeover切换host1
运维切换测试：
运维切换测试是为了在运维过程中，保证高可靠性加以实施。
建议每年实施一次。
因为这样的测试实际是一种演练，能够及时发现各方面的问题，为故障期间切换成功提供有效保证。
运维切换测试表
场景
建议时长
切换方式
主备（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
互换资源组：
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
修改文件属性：
chownroot:
cron/var/spool/cron/crontabs/root
chmod600/var/spool/cron/crontabs/root
重起crontab:
ps-ef|grepcron
root27868810Dec19-0:
02/usr/sbin/cron
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的目的。
smittyclstop
StopClusterServices
*Stopnow,onsystemrestartorbothnow
StopClusterServicesonthesenodes[host1]
BROADCASTclustershutdown?
true
*Shutdownmodeforced
一般所有节点都要进行这样操作。
强制停掉后的HACMP启动:
在修改HACMP的配置后，大多数情况下需要重新申请资源启动，这样才能使HACMP的配置重新生效。
smittyclstart
StartClusterServices
*Startnow,onsystemrestartorbothnow
StartClusterServicesonthesenodes[bgbcb04]
BROADCASTmessageatstartup?
StartupClusterInformationDaemon?
false
Reacquireresourcesafterforceddown?
日常检查及处理
为了更好地维护HACMP，平时的检查和处理是必不可少的。
下面提供的检查和处理方法除非特别说明，均是不用停机，而只需停止应用即可进行，不影响用户使用。
不过具体实施前需要仔细检查状态，再予以实施。
当然，最有说服力的检查和验证是通过”运维切换测试“。
clverify检查
这个检查可以对包括LVM的绝大多数HACMP的配置同步状态，是HACMP检查是否同步的主要方式。
smittyclverify
VerifyHACMPConfiguration
VerifyCluster
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。
/usr/sbin/cluster/utilities/cldump
____________________________________________________________________________
ClusterName:
test_cluster
ClusterState:
UP
ClusterSubstate:
STABLE
_____________________________________________________________________________
NodeName:
host1State:
Net
升级会员 