TSAM和RSCT的学习笔记

这个是小秦对TSAM和RSCT这个高可用组件的学习笔记:
TSA里的核心是要知道你需要到达什么状态,于是你才被控制转向什么状态!比如A、B两个节点,现在DB跑在A上,WAS跑在B上,你工作的很正常,但是TSA自己运算后得出的结论是他需要DB和WAS都跑在A上,于是它就会去做这个操作。除非你指定不让TSA去管理这个(samctrl -M T)。那节点中的资源什么时候会的被开始管理呢?当被加入资源组的时候就会的被管理。

对于资源有上面的维护操作。对于节点同样也有。TSA会保证节点的Online状态。因此除非你把它加入到exclude列表,否则这个节点手工shutdown是无法成功的。我的理解是TSA把节点也看成是一个资源,这个资源需要的状态是online,因此当你手工stop的时候,资源状态变得不是online了,其就会去修复这个状态。

当启动一个资源组的时候,其会的保证他下面的每个资源都启动。如果是float的资源,其会保证它在nodelist中的一个node启动。如果想要每个node上都启动一份,或许就需要定义n个fix的资源了。对于float的资源,默认的话是在nodelist中的第一个node上启动。

0.如果虚拟机直接复制后没法建立domain,运行:/usr/sbin/rsct/install/bin/recfgct

1.名词
Cluster and peer domains:代表一些组成集群的节点
Resource:软件或硬件的抽象称呼,集群中可以被调度的单位。可以使用mkrsrc或XML或图形编辑器来创建。同时系统自带很多resource类型。
有两类resource:Fixed resource:固定存在于某个节点的资源 Floating resource:可以在集群各个节点中浮动的资源
Resource attributes:资源有两类属性:Persistent attributes和Dynamic attributes。前者是固定的,比如IP,后者是动态的,比如状态
Resource class:是同一类资源的共同属性的集合。比如IBM.application这个集合就有start、stop等属性,所有的高可用应用属于这个class,因为他们都有start或stop属性。

2.Resource Manager
每个节点上都会跑很多个RM,每一个都是一个进程,用于处理特定类型的东西。主要有:
Recovery resource manager:IBM.RecoveryRM是整个SAM的决策引擎。比如各种policy信息就保存在它的信息库中。当其它RM发现有特定时间产生的时候,这个RM就会决定是否要做某种操作。
Global Resource RM:IBM.GblResRM,支持两种资源类:IBM.Application和IBM.ServiceIP,其管理着属于这两个资源类的应用
Event respnse resource manager:IBM.ERRM。等待事件的产生,如可以定义磁盘空间到达80%就发送告警邮件。
Storage resource manager:IBM.StorageRM:提供对磁盘资源的监控和控制。磁盘的设备由这个RM负责映射到对应的资源。
Configuration resource manager:IBM.ConfigRM用于集群的定义。
Test resource manager:IBM.TestRM。仅用于管理test的资源。

3.配置一个简单的没有resource的domain(主机为RHEL5801&RHEL5802,192.168.19为外网,192.168.18为内网)
3.0 确保网络畅通,同时保证单个节点上的所有网卡不属于同一个网段。设置好CT_MANAGEMENT_SCOPT=2。同时把hosts里默认的127网段与主机名的条目删除。
3.1 preprpnode
这个命令会的在节点间做一些准备,比如加入各自的public keys。并且RMC的ACL也会允许其它节点的访问。
在每个节点分别运行:
preprpnode RHEL5801 RHEL5802
3.2 在任一节点运行:mkrpdomain SA_Domain RHEL5801 RHEL5802
3.3 使用lsrpdomain可以查看当前节点所属于的domain的信息,使用lsrpnode查看节点信息
3.4 使用startrpdomain SA_Domain启动domain
3.5 使用stoprpnode XXX可以停止domain中的某个node。
3.6 使用lssrc -s IBM.RecoveryRM这个命令可以查看RM的信息。加入-l可以看到相信信息:lssrc -l -s IBM.RecoveryRM。
甚至可以手工停止RM:stopsrc -s IBM.RecoveryRM,然后通过startsrc -s IBM.RecoveryRM。
每个节点都有IBM.RecoveryRM,其中会有一个master,可以通过lssrc -ls IBM.RecoveryRM | grep Master查看

换句话说,XXXsrc用于显示和操作RM有关的东东

4.定义简单的资源(主机为RHEL5801&RHEL5802,192.168.19为外网,192.168.18为内网)
这个例子里我们定义三个东西:
apache1:一个属于IBM.Application的resource,换句说话其拥有start、stop等属性
apache1IP:一个浮动IP,属于IBM.ServiceIP
netequ:一个equivalency,代表网卡,在每个节点上都固定有一个,属于IBM.Equivalency

我们先写一个脚本,这个脚本可以启动、停止和监控apache的状态:
[root@RHEL5801 scripts]# ls
apache
[root@RHEL5801 scripts]# pwd
/cluster/scripts
这个脚本在各个节点上都要可以使用,并且包含start/stop/status三个功能。
同时注意,脚本的返回code是有规定的,这个规定可以在admin guide的第7章找到。系统会更具status的RC与start的RC或stop的RC进行比较决定具体的行为。

定义一个资源属性文件:
PersistentResourceAttributes::
Name=”apache1″
StartCommand=”/cluster/scripts/apache start”
StopCommand=”/cluster/scripts/apache stop”
MonitorCommand=”/cluster/scripts/apache status”
MonitorCommandPeriod=5
MonitorCommandTimeout=5
NodeNameList={“RHEL5801″,”RHEL5802″}
StartCommandTimeout=10
StopCommandTimeout=10
UserName=”root”
ResourceType=1

然后使用下面命令生成一个IBM.applicaiton类型的资源:
[root@RHEL5801 scripts]# mkrsrc -f apache1.def IBM.Application
如果这个命令报错,手工在各个节点运行StartCommand、StopCommand、MonitorCommand里的命令,看看能不能执行,比如如果里边的脚本没有可执行权限就会报错。

定义一个IBM.ServiceIP类型的资源:
[root@RHEL5801 scripts]# mkrsrc IBM.ServiceIP NodeNameList=”{‘RHEL5801′,’RHEL5802’}” Name=”apache1IP” NetMask=255.255.255.0 IPAddress=192.168.19.39

我们可以使用lsrsrc查看各个资源类下的资源,换句话说,XXXrsrc用于显示和操作Resource有关的东东

5.建立equivalency(主机为RHEL5801&RHEL5802,192.168.19为外网,192.168.18为内网)
equivalency表明其各个成员都有同样的功能。物理网卡就是一个很好的例子。
物理网卡属于IBM.NetworkInterface。

另外一般的equ好像默认就是online,除非机子宕了这类情况,其online、offline好像不能手工控制。

在这个例子里,我们的eth0网卡会的成为equivalency。而hosts里和主机名关联的eth1网卡则是心跳网卡。

[root@RHEL5801 scripts]# mkequ -D ‘Name like “eth0″‘ netequ IBM.NetworkInterface

6.定义策略(主机为RHEL5801&RHEL5802,192.168.19为外网,192.168.18为内网)
注意,当一个资源被定义到资源组后,这个资源的状态就有SAM管理了!手工对资源的状态进行修改都是无效的,比如你一个资源是活动的,你手工停了,SAM会把它重新启动起来。

先定义一个资源组:
[root@RHEL5801 scripts]# mkrg apacherg
把刚才定义的两个资源加入到这个group中去,之后这两个资源就由SAM管理了:
[root@RHEL5801 scripts]# addrgmbr -g apacherg IBM.Application:apache1
[root@RHEL5801 scripts]# addrgmbr -g apacherg IBM.ServiceIP:apache1IP

然后再来定义relationship,在这个例子中我们有两个条件要满足:
1.所有的资源都需要在同一台主机,这种关系叫做collocated relationship
2.IP资源需要在Application资源之前启动

现在定义这两个关系:
[root@RHEL5801 scripts]# mkrel -p DependsOn -S IBM.Application:apache1 -G IBM.ServiceIP:apache1IP apache1_dependson_ip1
[root@RHEL5801 scripts]# mkrel -p DependsOn -S IBM.ServiceIP:apache1IP -G IBM.Equivalency:netequ apache1IP_dependson_netequ

最后我们启动这个资源组,看看情况如何:
[root@RHEL5801 scripts]# chrg -o online apacherg

7.resource相关的东东
resource有很多的属性,有:
NodeNameList表明这个resource可以运行在哪些节点上
SelectFromPolicy表明这个资源在哪些几点是可用的
ResourceType表明这个资源可以同时跑在几个节点上。有两类:Fixed和FLoating。Floating其实是在每个节点建立一个Fixed的资源然后在建立一个NodeNameList包含所有节点的公共的一个资源。对于fixed的资源,其只能有一个node。如果你想要在多个node上启动多个同样的资源,那么需要定义多个一样的fixed资源。对于floating的资源,其只会在nodelist里选取一个。
OpState表明这个资源的状态。

8.resource group相关的东东
resource group有一个很重要的属性:nominalState。其代表这个resource group需要到达的状态。比如设置他为online则所有的资源都会努力变成online状态。当然resource group当前处于的状态由属性OpStat表明。

resource group的成员可以是fixed的资源、floating的资源甚至是另一个子resource group。但是不能包含equivalency(感觉equivalency更像是一种硬件,是一种死的,不能改变的,但是可以使用的东东)。

和resource一样,resource group也有很多属性,比如:OpStat,MemberLocation等。MemberLocation默认表明资源组里的所有资源都需要在同一个节点上,所以我们上面的例子就是这样的情况。

mkrg用于创建资源组
rmrg用于删除资源组
chrg用于改变资源组,资源组的状态就是由他控制的,比如chrg -o online XXX。如果要改变资源组的某个属性,用-l参数。如果要改变资源组的名字,用-c参数。
lsrg用于查看有哪些资源组,lsrg -m可以查看具体的member,-g可以明确指明要看哪个资源组,并且加入-g参数后可以看到这个资源组的属性。
addrgmbr用于添加资源入资源组
rmrgmbr用于从资源组删除资源

lssam用于查看当前资源的运行情况,这个命令很有用。从下面的例子可以看出,我们定义了一个资源组和一个equivalency,资源组有两个资源,其中哪些是online的,哪些是offline的:
[root@RHEL5801 scripts]# lssam
Online IBM.ResourceGroup:apacherg Nominal=Online
|- Online IBM.Application:apache1
|- Online IBM.Application:apache1:RHEL5801
‘- Offline IBM.Application:apache1:RHEL5802
‘- Online IBM.ServiceIP:apache1IP
|- Online IBM.ServiceIP:apache1IP:RHEL5801
‘- Offline IBM.ServiceIP:apache1IP:RHEL5802
Online IBM.Equivalency:netequ
|- Online IBM.NetworkInterface:eth0:RHEL5802
‘- Online IBM.NetworkInterface:eth0:RHEL5801

lssam -V则可以查看依赖关系:
[root@RHEL5801 rhsm]# lssam -V
Online IBM.ResourceGroup:apacherg Nominal=Online
|- Online IBM.Application:apache1 -.
|- Offline IBM.Application:apache1:RHEL5801 |
‘- Online IBM.Application:apache1:RHEL5802 DO
‘- Online IBM.ServiceIP:apache1IP IP=192.168.19.39 <‘ -.
|- Offline IBM.ServiceIP:apache1IP:RHEL5801 |
‘- Online IBM.ServiceIP:apache1IP:RHEL5802 DO
Online IBM.Equivalency:netequ <‘
|- Online IBM.NetworkInterface:eth0:RHEL5802
‘- Online IBM.NetworkInterface:eth0:RHEL5801

rgreq -o move apacherg可以把资源在cluster中进行移动。这里可以加上-n参数,表明现有的资源在哪里,不要移动到那里去,如:
rgreq -o move -n RHEL5802 apacherg,这样的话资源会的从当前集群的当前节点移动到其它节点上去,但不会移动到-n参数指定的RHEL5802这个节点上。如果只有两个节点,那么移动将不会发生。

9.Equivalencies的东东
Equivalencies是一类提供相同功能的资源的集合。其成员是一组属于相同资源类的fixed资源。

有两类Equivalencies:静态的:定义的时候有用户明确指定。动态的:有一个SelectString list用于动态确定哪些资源属于他。

Equivalencies的地位类似于资源组,一个资源可以属于Equivalencies或资源组,但不同同时都属于。

和资源组一样,其也有很多的属性。

通过mkequ创建Equivalencies。
通过lsequ查看Equivalencies。
通过chequ修改Equivalencies。
通过rmequ删除Equivalencies。

10.关于relationships的东东
relationship就是某种依赖关系。比如A资源依赖于B资源。

relationship有两大类:
1.start/stop依赖:
如startafter/stopafter/dependson/dependsonany/forceddownby
2.location依赖
如:collcated/anticollcated/affinity/antiaffinity/isstartable
对于location依赖,除了isstartable外,其余的都可以使用condition属性,如:ifonline/ifnotonline/ifoffline/ifnotoffline/ifpossible/none

相关的命令都类似与XXXrel

详细点的:
对于一个relationship,其有source和target两个点。source依据target的状态来决定接下来的行为。source的类型不可以是equ,而target则可以是equ。
注意对于这种带动关系,其目标状态是source的所在RG的状态。比如A startafter B,那么A所属于的RG_A如果设置为online的话,那么会的把B带起来,然后A才会起来。
另外,online的状态重要度比offline的要高。比如RG_B的目标状态是Offline,那么上面这种情况下是不希望B变成online的,但B收到的是一个online的请求,于是B就会online了。
如果一个RG的状态是Online,那么TSA会维护这个状态,比如你手工干了一个node,那么TSA会尝试重启这个资源。

几种关系:
StartAfter:A startafter B。A需要B online后才可以online。A和B可以在不同的node上。但是这个并不会要求force down,也就是B挂了A也会online。例子:A在RG_A,B在RG_B,A startafter B,如果把RG_A的状态设置为online,会的要求B先起来,然后A才能起来。(也就是说,启动A的时候,先去检查B的状态,如果B起来了,那么就可以起A,如果B没有起来,就先去启动B,B只有起来了A才可以起来
。A和B不一定在同一个node上,也不一定需要在一个RG中)。如果配合IfPossible,那么即便B没有起来,A还是可以起来的。只不过B的BS熟悉会变成Sacrificed。不过,如果B不是意外宕的,那么A处于online状态的时候B是不能offline的。startafter没用定义停的顺序,因此A和B可以同时停止。

StopAfter:A stopafter B。A需要B offline(或failed offline也行)后才可以stop。

DependsOn:和startafter差不多,但是它需要相关的资源有一个隐式的collocation。语义上和startafter的差别是,dependson以为着A需要用到B的功能,B不存在的话A也就不能正常工作了。对于stop和start,dependson都决定了相关的顺序。对于dependson不存在failed force这种东西。由于存在collocation这个要求,因此如果A或B为RG的话,需要保证这个RG中的资源也在同一个节点。

DependsOnAny:和DependsOn类似,不过不要求在同一个节点。换句话说,A depens on B == A dependsonany B + A collcated B

ForcedDownBy:当A forceddownby B的时候,如果B宕了或offline了,A也必须offline。这种offline可以是并行的。这种一般是针对意外,因此没有啥start、stop的动作可言。只要B宕了,A也必须停。

Location相关的关系:
Collcated:比如A和B有这个关系,A可以跑在三个节点上,B可以跑在一个节点上,由于是collcated,因此A和B需要跑在同一个节点上。(如果B是offline的,理论上A就可以放在任意的节点,但是为了保证今后B也可以online并且不重新调整A的位置,A会放在那些B可以启动的节点上)
AntiCollcated:和上面那个相反,不能跑在同一个节点上。
Affinity:比collcated语义要弱一点,如果没有其它办法了,那么可以不跑在一起。
AntiAffinity:比anticollcated语义要弱一点,如果没有其它方法了,那么可以跑在一起。
IsStartable:用于保证A只可以运行在那些B可以被运行的节点上。

Conditions 关系:
可以和location关系一起用。
IfOnline:只有在B的状态是online的时候才考虑location关系,否则忽略
IfOffline:只有B是offline或failed offline的时候才考虑location关系,否则忽略
IfNotOnline:只有B不是online状态的时候才会考虑location关系。比如Pending Online或Stuck Online。
IfNotOffline:只有B不是offline或failed offline或unknown的时候才会考虑location关系。

11.系统状态信息的处理流程
这一部分和系统的切换算法、状态转换有关。具体的可以看Chapter 7。通过这一章可以看到系统选取资源的决策顺序。

需要注意的是:HA脚本的返回code是有规定的,这个规定可以在admin guide的第7章找到。系统会更具status的RC与start的RC或stop的RC进行比较决定具体的行为。

12.关于quorum
主要是用于防止两个节点互相不知道是谁挂了的这种情况的出现。或者说是为了避免临界资源的出现。

注意,这个是domain级别的,和resource啥的其实关系不大。

有两种方法可以进行保护:
configuration quorum:
用于决定集群中的哪种配置的修改可以被接受。只有集群中n/2+1以上的node还active的时候,配置可以接受。比如启动domain的时候需要保证一般以上的node可以启动。所以这种quorum主要是和配置相关的

operational quorum:
由tie breaker和在线的节点数共同决定临界资源的处理。如果没有operational quorum,那么SAM会有很多操作无法执行。

很简单的例子,如果一个集群里就两个主机,都连在一个交换机的同一个VLAN里,这个时候节点A是primary,如果节点A的网线断了,那么节点A和节点B的通信就没了,这个时候节点A怎么知道是他挂了而不是B挂了呢?因此我们需要tie breaker和在线的节点数来帮助节点A确定这些事情。比如我们用一个IP来作为tie breaker,这个时候由于A的网线断了,其ping不通这个IP,于是A知道是自己挂了,其乖乖的做些stop的事情。对与节点B则知道自己还活着,是A挂了,于是其进行接管。

A知道自己挂了后,通过ConfigRM这个RM的CritRsrcProtMethod属性,其会知道自己该做些啥(比如直接关机)。

如果说有ABC三个节点,当网络发生故障后,AB直接可以通信,C不能通信,那么集群也能意识到C挂了,因此会的对C执行ConfigRM这个RM的CritRsrcProtMethod属性指定的操作,并且在A或B上把资源组带起来。对于这种情况就不需要tie breaker了。

比如我们这里的例子,apacherg跑在A和B上,启动的时候AB这个子集群的节点个数为2,大于等于集群节点个数的一半,因此即便没有设置tie breaker也能启动。但如果启动的时候B挂了,那么这个时候要启动的话除非配置了tie breaker,比如给一个IP让A去ping,否则的话这个集群是没法启动的。

tie breaker有很多的种类。比如
Operator:这种是手工的。
Fail:这种其实不算,它让被分隔的每个自己群都认为自己是活的
SCSI:用磁盘来解决
ECKD:Z机上用的
DISK:AIX上用的,也是用磁盘
EXEC:通过某个脚本的返回值来确定自己是不是活的。比如ping某个网络地址。

通过lsrsrc IBM.Application Name NodeNameList ProtectionMode可以查看某个资源是否属于临界资源,对于临界资源,必须满足启动条件才能启动。
可以用chrsrc -s “Name=’apache1′” IBM.Application ProtectionMode=1命令将某个资源设置为临界资源。

用lssrc -ls IBM.RecoveryRM可以查看quorum的信息。

通过lsrsrc -c IBM.TieBreaker可以查看当前系统支持哪些种类的tie breaker。

通过lsrsrc IBM.TieBreaker可以查看tie breaker的名字。也就是各个具体的IBM.TieBreaker类型的资源。

虽然上面的命令可能会的列出当前系统中定义了很多的tie breaker,但是其实一个cluster同一时间只能使用一种tie breaker。可以通过:
lsrsrc -c IBM.PeerNode OpQuorumTieBreaker查看当前集群使用了何种tie breaker。

通过chrsrc -c IBM.PeerNode OpQuorumTieBreaker=”Operator”命令设置使用的tie breaker

当tie breaker是手动的时候(operator),那么通过下面的命令给予操作:runact -c IBM.PeerDomain ResolveOpQuorumTie Ownership=1 #(0 to deny)

下面我们来定义一个EXEC的使用网络的tie breaker。对于这种tie breaker,一般要求在同一个网段(防止交换机故障)
通过mkrsrc来创建这么个资源:
[root@RHEL5801 scripts]# mkrsrc IBM.TieBreaker Type=”EXEC” Name=”mynetworktb” DeviceInfo=’PATHNAME=/usr/sbin/rsct/bin/samtb_net Address=192.168.19.2 Log=1’ PostReserveWaitTime=30
其实这个就是调用一个ping的脚本,要保证这里的路径能被每个节点访问。
然后把这个tie breaker做成默认的:
chrsrc -c IBM.PeerNode OpQuorumTieBreaker=”mynetworktb”

13.修改SAM的一些参数
通过lssamctrl可以看到sam的一些control参数,比如timeout、count等。这些可以通过samctrl来进行修改。

14.关于进程
整套RSCT的进程可以用下面的来看,其实也就是启动各个RM:
[root@RHEL5801 rhsm]# ps -elf | grep -i ibm
4 S root 4499 2376 0 30 – – 8208 – 04:18 ? 00:00:00 /usr/sbin/rsct/bin/IBM.ConfigRMd
4 S root 4828 2376 0 30 – – 4875 – 04:19 ? 00:00:00 /usr/sbin/rsct/bin/rmcd -a IBM.LPCommands -r
4 S root 4885 2376 0 75 0 – 5701 – 04:19 ? 00:00:00 /usr/sbin/rsct/bin/IBM.StorageRMd
4 S root 4886 2376 0 75 0 – 6616 – 04:19 ? 00:00:00 /usr/sbin/rsct/bin/IBM.GblResRMd
4 S root 4887 2376 0 75 0 – 3786 – 04:19 ? 00:00:00 /usr/sbin/rsct/bin/IBM.TestRMd
4 S root 4888 2376 0 76 0 – 8014 – 04:19 ? 00:00:00 /usr/sbin/rsct/bin/IBM.RecoveryRMd
0 R root 23232 4118 0 78 0 – 15298 – 07:35 pts/1 00:00:00 grep -i ibm
各种资源应该是定义在某个XML文件里。

15.关于日志
所有的日志都记录在系统的常用日志处。比如对于linux就是记录在/var/log/messages中。

16.exclude list
这个list里的node的状态不归tsa管理(也就是你可以shutdown他们,tsa也不会把它们重新启动)。所有的资源不会的放到处于exclude状态的node上去,即便当前其它的node都offline了。通过samctrl命令可以管理这个list

17.状态间的转换关系
Bound:就是把资源指定一个运行节点的过程。算法叫做binder算法。
Binding算法的过程:
1.先是去发现。发现的过程首先就是更具各种关系,得到独立的关系子集。比如A依赖于B,C依赖于D,这两个关系其实没有多大交集,因此可以看成是两个子集。然后就是忽略那些OpState=Failed Offline的资源。然后再是把那些还有failed offline状态的资源的资源组标记为不可用,从关系子集里边踢出出去。最后这个发现的过程就完成了。现在手边就知道了哪些group是可以启动的。下面要做的就是决定启动顺序以及启动的节点。
2.寻找最好的运行方法。也就是根据各种关系,决定运行在哪些节点上。那什么是最好的呢?比如anticollcated就不是最好的,pure collcated才是。
3.有时候运行的时候会有一些关系冲突,这一步就需要做丢弃。丢弃的时候首先丢弃那些引起冲突的affinity或antiaffinity关系。然后丢弃那些OpState=offline并且不需要启动的资源。再然后丢弃那些不重要的资源。
4.如果这个时候binding算法还是不能成功运行,那么就停止整个集群。

看一下哪些事件会让RG变成online吧:
修改了allowednode属性、移除了一个资源、增加了一个作为target的资源、启动一个不是由TSA管理的资源。。。

最后,看一下TSA的行为模式:
StartCommand:
该命令在下面两种情况下会运行:1.RG的NominalState编程了online并且这个资源的所有依赖已经满足。2.这个资源的状态意外的从Online变成了Offline(但如果不是意外的就不会运行)。
对于上面的第二种情况,当一个资源在Online timeout时间内还是没有起来或超过了最大的尝试次数的话,那么其会的尝试在其它地方启动。并且当前节点的该进程会被kill给杀掉。但这里有个问题,如果你的这个程序不返回(也就是输入命令就一直跑着),那么TSA就不能得到返回值,因此也必然会的超过timeout规定的时间,所以要么把它加上&跑在后台,要么设置RunCommandsSync为0.

MonitorCommand:
TSA用这个命令去获取资源的状态。频率由MonitorCommandPeriod决定。并且在所有节点上都会监视(哪怕没有跑在那个节点上)。如果这个monitor的脚本运行时间太久了,那么TSA会kill它,记录一条日志,同时把这个资源的状态标记为UNKNOWN。

StopCommand:
就是停止的一个脚本,也有超时时间啥的。如果stop失败,那么资源状态会变成stuck online。需要手工的干预了。

资源的各种OpState转换图以及造成该状态的原因参见P112或者快盘的截图。

18.管理TSAM的行为
lssamctrl可以查看下面的属性,samctrl则可以修改。
主要的用于管理行为的参数是:
TimeOut:用于设置如start这类操作的超时时间
RetryCount:用于指明最多允许的失败次数
Automation:用于确定是否允许system的自动化管理。如果这个打开,那么所有的资源会由TSAM去维护一个状态。如果关闭,那么你可以任意修改资源,但是状态不会改变。当重新打开这个的时候,TSA会继续维护之前的状态。
ExcludedNodes:用于生成一个node的list。系统不会吧资源放在这list中的节点。因此这些节点可以任意的做维护而不影响到生产。如果某个RG的某个资源所能运行的所有node都在这个list里,那么这个RG就会stopped。
ResourceRestartTimeOut:资源在另一个节点重启前会的等待这段时间,用于给失败的那个节点足够的时间做清理工作。
TraceLevel:用于控制记录的等级。越大越详细,最大是255

考虑下面的几个操作的行为:
Start操作:
当发送start请求后,有这么几个情况:
1.资源状态改变成了需要的状态。这样的话就没有别的操作了,一切正常
2.在timeout规定的时间内资源拒绝了操作(注意,不是失败)。这个时候会有一个出错的返回码,如果这个返回码意味着还可以进行,那么会再次尝试启动。如果返回码说明这个资源无法在当前节点启动,然后就会进入下一步纠错操作:如果是个静态资源,那么没啥操作可做了。如果是个浮动资源,那么会的在其它节点上尝试运行。注意对于拒绝这个操作的节点,其状态会的是一个不变的error,除非手工重置。
3.在timeout规定的时间内没有变成指定状态(不是被拒绝)。这样的话TSA首先会执行reset操作把这个资源的状态重置为offline,然后会再次尝试知道超出RetryCount。

如果状态是failed offline,那么表明某个资源是不可自动恢复的,必须需要手工干预。

Stop操作:
当发送stop请求后,有这么几个情况:
1.一切ok
2.在timeout时间内reject了。如果返回码是可以恢复的,那么再次尝试。如果不是可以恢复的,那么需要手工干预
3.如果超时了,那么就重新尝试

19.Start和Stop操作
详细讲一讲这个:
rgreq -o <start|stop>
rgmbrreq -o <start|stop>

首先关于这两个操作有一个要注意的,那就是这个既可以针对特定的RG,也可以针对某个RG里的特定的Member:
对于RG:操作会的影响所有的member,并且对于关系中涉及到的其它资源,那些资源也会被影响
对于member:只会影响特定的资源,并且对于关系中涉及到的其它资源,那些资源也会被影响(如果是资源组的强制资源,那么会的让资源组状态改变)

可以取消已经发出的start或stop操作(cancel只用于前一次的request,且只能是start/stop):
rgreq -o cancel
rgmbrreq -o cancel

其实request是持久的,你发送后会的把request给加入到request list里,所以cancel其实就是从这个list里移除。可以使用lsrgreq查看request。(类似与tsm的request)

20.lock&unlock资源
用于保证某个RG或某个资源的状态不会被其它的行为改变。也就是不受TSA的影响。
rgreq -o lock/unlock
rgmbrreq -o lock/unlock

lock/unlock也是一个request,也可以用lsrgreq查看。

21.移动资源组/资源
就是在节点间移动资源。

22.Shadow resource
shadow resource的含义是指的那些拥有下面两个特点的资源:1.一个属于IBM.Application类的fixed的资源,其不停的监视着另外一个fixed的资源的OpState。2.一个SelectFromPolicy是Nocontrol的equivalency。

23.Security
默认只有root有权限进行管理操作。TSAM的权限管理是基于RSCT的RMC组件,后者有一个ACL的文件。

总的来说security的管理是比较难的,所以一般会要求建立一些role来进行授权。

24.diagnostic
常用命令
samdiag -g apacherg
/usr/sbin/rsct/install/bin/getsadata
查看系统日志,如/var/log/messages
rpttr /var/ct/SA_Domain/log/mc/IBM.RecoveryRM/trace_summary:查看详细的审计日志(SA_Domain要换成domain的名字),用于记入request之类的信息
rpttr /var/ct/SA_Domain/log/mc/IBM.GblResRM/trace_summary:查看详细的审计日志(SA_Domain要换成domain的名字),用于记入start/stop之类的信息

对于BindsingState,有三种状态:
Unbound:就是offline,没有启动资源,资源没有和节点绑定
Bound:启动了资源
Sacrificed:无法为资源找到合适的运行节点

另外,对于任何异常状态(比如failed offline/stuck online),检查对应的stop、monitor、start脚本,看看为什么无法停止。同时看下应用的日志,是什么原因组织其状态的改变

25.重启一个节点:
先把一个节点加入exclude list中:
samctrl -u a XXX
然后把它重启
再然后把它移出exclude list:
samctrl -u d XXX

26.如果move操作失败,且一直处于move状态,那么(注意,move的cancel的action是movecancel,不是cancel!)
Determine which node has the “master” IBM.RecoveryRM :
lssrc -ls IBM.RecoveryRM |grep -i master
On that node, determine the pid of the IBM.RecoveryRMd process:
ps -ef |grep Recovery
Kill the IBM.RecoveryRMd process using its pid:
kill -9 Then:
rgreq -o movecancel db2_db2inst1_db2inst1_TSADB-rg
Then:
chrg -o onlie/offline RGXXX

发表评论

电子邮件地址不会被公开。 必填项已用*标注

*