浅谈 HACMP 心跳

核心提示： 再看 HACMP 心跳 从 HACMP5.1 版本以后，HACMP 的心跳已经交由 RSCT（Reliable Scalable Cluster Technology）这一套中间层软件来实现，浅谈 HACMP 心跳(2)，RSCT 相当于是一个集群应用与集群管理的中间通讯平台，它提供了丰富

再看 HACMP 心跳

从 HACMP5.1 版本以后，HACMP 的心跳已经交由 RSCT（Reliable Scalable Cluster Technology）这一套中间层软件来实现。RSCT 相当于是一个集群应用与集群管理的中间通讯平台，它提供了丰富的集群功能简化了集群应用开发的复杂性。在其他的一些软件，比如 IBM CSM 集群管理软件和 HMC 上的部分管理功能都是通过 RSCT 的组件来实现的。

再细分来看，负责心跳的是 RSCT 中的 Topology Services 模块。我们下面先了解一下 Topology Services 的初始化过程。Topology Services 的核心进程是 /usr/sbin/rsct/bin/hatsd 。hatsd 启动后就开始广播本节点信息同时侦听其他节点的信息，经过自举、推举、还有一段时间等待（其过程有点类似于以太网交换机通过 spanning-tree 协议选举 root 节点），最后在该子网中找出所有节点里一个 IP 地址最高的，将它定义为 group leader。 Group leader 作为一个权威节点负责该子网中节点状态信息的收集，管理，更新和发布。至此，心跳网络就完成了其初始化过程开始正常心跳。另外，为防止 Group Leader 宕机，还定义了 IP 地址第二高的节点作为 Group Leader 的监控节点称之为 Group Leader Successor，它负责监控 Group Leader 状态，在必要时可以弹劾并成为 Group Leader。

在心跳网络建立以后，网络状态的监控被分为两部分，一是网卡物理状态的监控；一是逻辑上的网络链路状态监控。网卡物理状态的监控是通过为每一块网块创建一个监控进程（NIM）来实现的，当网卡状态改变会立刻通知 RSCT，比如网卡 Link down 的信息就会被 NIM 立刻发现并产生 Network adaptor failure 的事件。

另一方面，hacmp 心跳故障判断还能从逻辑上分析判断网络状态。我们以下图为例。假设在运行过程中，Node3 到 Node2 之间的网络发生意外中断，但是 Node3 网卡的链路状态仍然为 UP，此时物理的网卡监控不会做出反应。然而心跳包会开始丢包，Node2 会发现无法收到 Node3 的心跳包，但此时并不能确定到底是 Node2 还是 Node3 网络出现故障。为了进一步确定故障，Node3 会通过 RSCT 走别的心跳网络发命令给第三个节点（node1），让第三个节点（Node1）分别去 ping Node2 和 Node3。如果故障点在 Node3 上面，那么显然 ping Node3 会失败，于是确定故障位置在 Node3 上面，最后产生一个的 Network adaptor failure 的事件通知给 HACMP。