用 CSM/RSCT 监控集群中的进程

IBM RSCT（Reliable Scalable Cluster Technology）提供了一套完整的集群资源监控机制，IBM CSM（Cluster System Management）利用此机制预定义了很多用于资源监控的 Condition、Response 和 Association，具体可参见 CSM 的用户手册。但是，CSM 并没有提供用于监控集群中进程的预定义 Condition、Response 和 Association。本文将介绍如何利用 RSCT 资源类 IBM.Program 和 CSM 相关配置命令来监控集群中的进程，同时说明如何对 GPFS 和 LoadLeveler 的关键守护进程进行监控。

RSCT 提供了资源类 IBM.Program 用于监控集群中的进程，通过定义 IBM.Program 资源以及相关的 Condition、Response 以及 Association，可以在当集群中节点上的某些特定进程启动或者退出时在管理节点上收到提示信息。在定义 IBM.Program 资源之前，需要了解 IBM.Program 资源中各个属性及其含义以便在定义资源时正确的对各个属性赋值，下面是 IBM.Program 资源的各个属性及其含义的详细说明：

Name:

Name 是 IBM.Program 资源的名称，可用于识别各个 IBM.Program 资源，IBM.Program 资源的 Name 是可以由用户自由定义的。当然，一个有意义的名称将会帮助用户理解各个资源的用途。

ProgramName：

属性 ProgramName 用于指定监控的进程的名称，进程名称应该为 ps –l 或者 ps –o “common”所返回的进程名称。

Filter：

属性 Filter 用于指定被监控进程除名称之外的其它限制条件，每个 Filter 条件为一个比较操作，如“ruser == root”说明监控实际用户名为 root 的进程。下列属性可以在 Filter 条件中使用：

• ruser: 进程的实际用户。进程的实际用户可以使用 ps –l 或者 ps –o ”ruser”来显示。
• user: 进程的有效用户。进程的有效用户可以使用 ps –l 或者 ps –o ”user”来显示。
• args：进程的参数列表。可以使用 args[n] 来制定第 n 个参数。
• exec：用于指定进程是否使用系统调用 exec 启动，1 说明进程是用 exec 启动的，而 0 则说明进程不是用 exec 启动的。

Origin：

属性 Origin 用于指定进程定义是显式的还是隐式的，当使用选择条件 ProgramName/Filter 来定义进程时即为隐式定义，此时 Origin 的值将会为 0，否则 Origin 的值将会为 1。

ActivePeerDomain：

属性 ActivePeerDomain 用于指定资源所在的 PeerDomain，由于在 CSM 集群中使用的为 ManagementDomain，所以在 CSM 集群中定义 IBM.Program 资源时无需指定 ActivePeerDomain。

NodeNameList：

属性 NodeNameList 用于指定资源所在的节点列表，如果在定义 IBM.Program 资源是不指定 NodeNameList 则说明在本机定义该资源。

RSCT 资源监控要求各被监控节点需要和监控检点在同一个 Peer Domain 或者 Management Domain 中，对 CSM 集群而言，将各被监控节点加入 Management Domain 的步骤就是对节点运行 updatenode。判断一个节点是否已经在 CSM Management Domain 中的方法是 monitorinstall 或者 lsnode –a Mode 显示该节点的 Mode 为 Managed。

用 IBM.Program 资源监控集群节点上的进程的第一个步骤为在 CSM Node（即被监控节点）上使用命令 mkrsrc 定义 IBM.Program 资源，在定义 IBM.Program 资源时可以指定上面列出的各个属性值，在下面例子中指定的属性值为 Name 和 ProgramName：

mkrsrc IBM.Program Name=mydeamon_prog ProgramName=myDaemon.

在 IBM.Program 资源定义完成后，需要在 CSM 管理节点（即监控节点）上定义监控 IBM.Program 资源的 Condition，监控 IBM.Program 资源的 Condition 可以对如下的资源属性进行监控：

CurPidCount： 当前正在运行的符合 Program 定义条件的进程数目。

PrevPidCount： 在上一次发生进程改变之前的符合 Program 定义条件的进程数目，即为前一个 CurPidCount 的值。

CurrentList： 当前正在运行的符合 Program 定义条件的进程号列表。

ChangeList： 在上一次发生进程改变时新增或者退出的进程号的列表。

例如条件 "Processes.CurPidCount!=Processes.PrevPidCount&&Processes.CurPidCount==0" 说明符合 Program 定义条件的最后一个进程退出。

在 CSM 管理节点上定义监控 IBM.Program 资源的 Condition 的基本命令语法如下：

mkcondition -r IBM.Program -e "<event_expression>" -s "Name=='<resource_name>'" -S <event_severity> -m <management_scope> <condition_name>

其中：

event_expression 为 condition 的监控条件，如 "Processes.CurPidCount!=Processes.PrevPidCount&&Processes.CurPidCount==0" 即为一个有效的监控条件。

resource_name 为 IBM.Program 资源中定义中的资源名称。

event_severity 为当 Condition 被触发时信息的优先级，可以为 c（Critical），w(Warning) 或 i（Informational），如果 -S 参数没有被指定则缺省为 i（Informational）。

management_scope 指定 Condition 的作用范围，可以为 l（本机），m（ManagementDomain）或 p（PeerDomain）。

condition_name 为 Condition 的名称，可以由用户自由定义。

在 Condition 定义完成之后，需要在 CSM 管理节点上将 Condition 和 Response 进行关联，即在 Condition 被触发时会调用 Response 所定义的程序在监控的管理节点上进行相应的动作来通知系统管理员。从原理上讲，Condition 可以和任意的 Response 关联，但从实用的角度来看，在管理节点上广播一条信息是进程监控事件的有效方法。因此我们可以在 CSM 管理节点上将进程监控的 Condition 和 Response "BroadcastEventsAnyTime" 关联。

mkcondresp <condition_name> BroadcastEventsAnyTime

startcondresp <condition_name> BroadcastEventsAnyTime

当进程监控的 Condition 被触发时，在监控的管理节点上会看到类似如下的信息：

Broadcast Message from root@ms01 
 (somewhere) at 15:02 ... 
 
Critical Event occurred for Condition MyDaemonDie on the resource mydaemon_prog of the 
resource class IBM.Program at Sunday 07/06/08 17:13:45. The resource was monitored on 
node01.clusters.com and resided on {node01.clusters.com}. 

如果想停止对进程的监控，可以在 CSM 管理节点上运行如下的命令停止并删除 Association 定义：

stopcondresp <condition_name> BroadcastEventsAnyTime

rmcondresp <condition_name> BroadcastEventsAnyTime

利用上面叙述的步骤，可以配置对集群中任何进程的监控。本节将给出两个进程监控的实际例子，即对 GPFS 和 LoadLeveler 守护进程的监控。

GPFS 和 LoadLeveler 是 IBM 集群软件族中的两个重要产品，GPFS 和 LoadLeveler 会在很多情况下和 CSM/RSCT 共存，同时 GPFS 和 LoadLeveler 都是用了守护进程来完成程序的绝大多数功能，因此对 GPFS 和 LoadLeveler 守护进程的监控对集群的系统管理员来说会是非常有用的一个配置。

每个 GPFS 节点上都运行守护进程 mmfsd，mmfsd 是 GPFS 最重要的守护进程，对 GPFS 守护进程 mmfsd 的监控可以严格按照上面论述的步骤进行配置。

除此之外，CSM 提供了 csm.gpfs 包可以在对 GPFS 守护进程 mmfsd 监控的过程中提供额外的帮助。csm.gpfs 包会生成预定义的 GPFS 节点组定义，通过修改 GPFS 节点的属性 Properties 可以将各 GPFS 节点加入预定义的节点组，利用预定的节点组可以省去到各个节点上去定义 IBM.Program 资源的步骤而直接使用 dsh –N GPFSNodes “mkrsrc ...”去定义 IBM.Program 资源。具体可参见 CSM 管理手册。

如下为配置 GPFS 守护进程 mmfsd 监控的具体步骤：

1. 将 GPFS 节点加入 CSM 集群

   运行 updatenode –n <gpfs_node1, gpfs_node2, …gpfs_noden> 命令即可将 GPFS 节点加入 CSM 集群。

2. 创建 IBM.Program 资源

   在 GPFS 节点上用 mkrsrc 命令定义 IBM.Program 资源：mkrsrc IBM.Program Name=mmfsd_prog ProgramName=mmfsd64

   注意：在 AIX GPFS 节点上，GPFS 守护进程的名称为 mmfsd64，在 Linux GPFS 节点上 GPFS 守护进程的名称为 mmfsd，在创建资源 mmfsd_prog 时应该根据守护进程的名称调整 ProgramName 的值。如在 Linux GPFS 节点上需要使用命令 "mkrsrc IBM.Program Name=mmfsd_prog ProgramName=mmfsd" 来创建资源 mmfsd_prog。

3. 创建 Condition

   在 CSM 管理节点上使用 mkcondition 命令创建监控资源 mmfsd_prog 的 Condition：

   mkcondition -r IBM.Program -e "Processes.CurPidCount!=Processes.PrevPidCount&&Processes.CurPidCount==0" -s "Name=='mmfsd_prog'" -S c -m m GPFSMmfsdDie

4. 将 Condition 和 Response 关联

   可以使用任何已经存在的 Response 和 condition GPFSMmfsdDie 关联，在此以 BroadcastEventsAnyTime 为例：

   mkcondresp GPFSMmfsdDie BroadcastEventsAnyTime

   startcondresp GPFSMmfsdDie BroadcastEventsAnyTime

5. 监控信息

   当任何节点上的 GPFS 守护进程 mmfsd 出错退出或者重新启动时，在 CSM 管理节点上将看到如下的广播警告信息：

   Broadcast Message from root@ms01 
    (somewhere) at 15:02 ... 
    
   Critical Event occurred for Condition GPFSMmfsdDie on the resource mmfsd_prog of the 
   resource class IBM.Program at Sunday 07/06/08 17:13:45. The resource was monitored on
   gpfs01.clusters.com and resided on {gpfs01.clusters.com}. 
   

   
   
6. 停止监控

   如果想停止对 GPFS 守护进程的监控，可以在 CSM 管理节点上运行如下的命令停止并删除和 GPFSMmfsdDie 的 Association 定义：

   stopcondresp GPFSMmfsdDie BroadcastEventsAnyTime

   rmcondresp GPFSMmfsdDie BroadcastEventsAnyTime

与 GPFS 不同，LoadLeveler 使用了多个关键守护进程，各种 LoadLeveler 节点类型所使用的关键守护进程各不相同。在 LoadLeveler CM（Central Manager）节点上的守护进程为 LoadL_negotiator，在 LoadLeveler Schedd 节点上的守护进程为 LoadL_schedd，在 LoadLeveler 计算节点上的守护进程为 LoadL_startd。对各个守护进程的监控所使用的步骤可参照上面对 GPFS 守护进程监控的配置过程，在此不做赘述。

除此之外，CSM 提供了 csm.ll 包可以在对 LoadLeveler 守护进程监控的过程中提供额外的帮助。csm.ll 包会生成预定义的 LoadLeveler 节点组定义，通过修改 LoadLeveler 节点的属性 Properties 可以将各 LoadLeveler 节点加入预定义的节点组，利用预定的节点组可以省去到各个节点上去定义 IBM.Program 资源的步骤而直接使用 dsh –N LLCMNodes“mkrsrc ...”或 dsh –N LLScheddNodes“mkrsrc ...”或 dsh –N LLNodes“mkrsrc ...”去定义 IBM.Program 资源。具体可参见 CSM 管理手册。

RSCT 资源类 IBM.Program 可以用来监控集群节点上的守护进程或应用程序的运行，当集群节点上的守护进程或者应用程序出错退出或者被重新启动时，集群管理节点上可以收到相应的警告信 息。本文论述了如何使用 IBM.Program 资源类来监控集群中进程的步骤，同时说明了如何对 GPFS 和 LoadLeveler 关键守护进程进行监控。