浅谈 HACMP 心跳

任何一种 HA 软件都有一套自己的心跳机制来监控集群中节点的状态。心跳在高可用软件中担负着节点间信息通信，故障判断，事件触发等等重要作用，是 HA 软件最核心的组件。HA 集群就好比人一样，心跳正常就没有大碍，心跳不正常那就出问题了。

初识 HACMP 心跳

HACMP 软件主要监控 4 种故障：节点，网卡，网络，应用。其中前三种都是通过心跳来监控并产生事件响应的，我们可以看出使用 HACMP 集群，可谓玩的就是心跳。如果不了解心跳的过程和基本原理，使用 HACMP 搭建起来的高可用的平台就可能是高不可用。

其实 HACMP 的心跳并不复杂高深，像所有的 HA 软件一样，心跳包是用来传递节点的状态信息，HACMP 的心跳包从最高的 IP 地址依次单向流动到最低 IP 地址，然后再返回到 IP 地址最高的节点形成一个单向循环的环路。每一个物理子网都会有一个心跳环路，包括串口心跳和磁盘心跳这些点对点的心跳，在广义上也是各自独立的心跳环路。每个环路我们称之为一个心跳网络。其心跳过程我们可以参看下图，Node3 有最高的 IP 地址 192.168.1.3，它是该心跳环路的 Group Leader。 Node3 产生的心跳包发送给 Node2，Node2 产生的心跳包发送给 Node1，Node1 则发送给 Node3 形成一个环路。

对于 HACMP 集群来说，至少需要 2 个心跳网络来保证心跳网络的冗余，而且更进一步，至少需要 2 种不同类型的心跳网络保证更高的可靠性，比如，一个 IP 网络心跳，一个磁盘心跳。之所以对心跳网络可靠性有如此高的要求，除了我们之前描述的心跳网络的重要作用以外，还有更重要的原因：如果 2 个节点间心跳通信完全中断后，他们都会认为对方已经宕机，然后都在本地启动应用，并同时去争抢磁盘资源，有可能导致数据出现风险，即所谓的 split-brain 事件。所以 HACMP 包括其他的 HA 的集群应用都有一个很重要的前提，就是要求在任何时刻至少存在一个可用的心跳网络在节点间传递信息。

回页首

再看 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。

回页首

2 个节点的 HACMP 集群

我们从上文可以发现，准确判断网络故障点的位置需要“第三个节点”做仲裁。只有 2 个节点的 HA 集群如何实现正确判断？从一般的逻辑判断上来说，2 个节点之间出问题一定是公说公有理，婆说婆有理，必须要有第三方来做仲裁。

在只有 2 个节点的 HA 集群中，为了解决这个问题，HACMP 需要配置一个文件来设置一些第三方的一个仲裁 IP 地址。当心跳故障发生时，2 个节点都会去试图从本机去 ping 这些仲裁 IP 地址。能正确的 ping 通则表明本节点的网络正常，从而判断出故障点需要注意的是，仅仅是在网络心跳发生问题时，RSCT 才会调用网络诊断的进程去使用这些仲裁 IP，在正常状态下，这些仲裁 IP 不会参与到心跳过程。

这些仲裁 IP 的选择可以是子网的网关，也可以是子网中其他的某一节点 IP 地址。如果有多个子网，需要为每个子网挑选一个仲裁 IP 地址，把他们写成一个 list 保存到一个配置文件（netmon.cf）中。该配置文件的存放位置在 /usr/es/sbin/cluster/netmon.cf。在两个节点的 HA 群里同步配置的过程中，如果没有配置 netmon.cf 可能会弹出一个 warning 的信息提示该文件需要配置。

在配置 netmon.cf 后，RSCT 的进程启动后，会逐条把其中的 IP 读取进来，作为仲裁 IP 使用。我们可以在 nmDiag.nim.topsvcs.xxx 这个日志文件中看到这样的信息......

本文转自IBM Developerworks中国

      请点击此处查看全文