Chapter 1. Overview / 1.5. Architecture | ||||
|---|---|---|---|---|
 | 1.4. Heartbeat Cluster Components | Chapter 2. Installation and Setup |  | |
Chapter 1. Overview / 1.5. Architecture | ||||
|---|---|---|---|---|
| 1.4. Heartbeat Cluster Components | Chapter 2. Installation and Setup | | |
This section provides a brief overview of the Heartbeat architecture. It identifies and provides information on the Heartbeat architectural components, and describes how those components interoperate.
Heartbeat has a layered architecture. Figure 1.6, “Heartbeat Architecture” illustrates the different layers and their associated components.
The primary or first layer is the messaging/infrastructure layer, also known as the Heartbeat layer. This layer contains components that send out the Heartbeat messages containing “I'm alive” signals, as well as other information. The Heartbeat program resides in the messaging/infrastructure layer.
The second layer is the membership layer. The membership layer is responsible for calculating the largest fully connected set of cluster nodes and synchronizing this view to all of its members. It performs this task based on the information it gets from the Heartbeat layer. The logic that takes care of this task is contained in the Cluster Consensus Membership service, which provides an organized cluster topology overview (node-wise) to cluster components that are the higher layers.
The third layer is the resource allocation layer. This layer is the most complex, and consists of the following components:
Every action taken in the resource allocation layer passes through the Cluster Resource Manager. If any other components of the resource allocation layer, or other components which are in a higher layer need to communicate, they do so through the local Cluster Resource Manager.
On every node, the Cluster Resource Manager maintains the Cluster Information Base, or CIB (see Cluster Information Base below). One Cluster Resource Manager in the cluster is elected as the Designated Coordinator (DC), meaning that it has the master CIB. All other CIBs in the cluster are a replicas of the master CIB. Normal read and write operations on the CIB are serialized through the master CIB. The DC is the only entity in the cluster that can decide that a cluster-wide change needs to be performed, such as fencing a node or moving resources around.
The Cluster Information Base or CIB is an in-memory XML
representation of the entire cluster configuration and status,
including node membership, resources, constraints, etc. There is one
master CIB in the cluster, maintained by the DC. All the other nodes
contain a CIB replica. If an administrator wants to manipulate the
cluster's behavior, he can use either the cibadmin command line tool
or the Heartbeat GUI tool.
![[Note]](admon/note.png) | Usage of Heartbeat GUI Tool and cibadmin |
|---|---|
The Heartbeat GUI tool can be used from any machine with a connection to the cluster. The cibadmin command must be used on a cluster node, and is not restricted to only the DC node. | |
Whenever the Designated Coordinator needs to make a cluster-wide change (react to a new CIB), the Policy Engine is used to calculate the next state of the cluster and the list of (resource) actions required to achieve it. The commands computed by the Policy Engine are then executed by the Transition Engine. The DC will send out messages to the relevant Cluster Resource Managers in the cluster, who then use their Local Resource Managers (see Local Resource Manager (LRM) below) to perform the necessary resource manipulations. The PE/TE pair only runs on the DC node.
The Local Resource Manager calls the local Resource Agents (see Section “Resource Layer” below) on behalf of the CRM. It can thus perform start / stop / monitor operations and report the result to the CRM. The LRM is the authoritative source for all resource related information on its local node.
The fourth and highest layer is the Resource Layer. The Resource Layer includes one or more Resource Agents (RA). A Resource Agent is a program, usually a shell script, that has been written to start, stop, and monitor a certain kind of service (a resource). The most common Resource Agents are LSB init scripts. However, Heartbeat also supports the more flexible and powerful Open Clustering Framework Resource Agent API. The agents supplied with Heartbeat are written to OCF specifications. Resource Agents are called only by the Local Resource Manager. Third parties can include their own agents in a defined location in the file system and thus provide out-of-the-box cluster integration for their own software.
Many actions performed in the cluster will cause a cluster-wide change. These actions can include things like adding or removing a cluster resource or changing resource constraints. It is important to understand what happens in the cluster when you perform such an action.
For example, suppose you want to add a cluster IP address resource. To do this, you use either the cibadmin command line tool or the Heartbeat GUI tool to modify the master CIB. It is not required to use the cibadmin command or the GUI tool on the Designated Coordinator. You can use either tool on any node in the cluster, and the local CIB will relay the requested changes to the Designated Coordinator. The Designated Coordinator will then replicate the CIB change to all cluster nodes and will start the transition procedure.
With help of the Policy Engine and the Transition Engine, the Designated Coordinator obtains a series of steps that need to be performed in the cluster, possibly on several nodes. The Designated Coordinator sends commands out via the messaging/infrastructure layer which are received by the other Cluster Resource Managers.
If necessary, the other Cluster Resource Managers use their Local Resource Manager to perform resource modifications and report back to the Designated Coordinator about the result. Once the Transition Engine on the Designated Coordinator concludes that all necessary operations are successfully performed in the cluster, the cluster will go back to the idle state and wait for further events.
If any operation was not carried out as planned, the Policy Engine is invoked again with the new information recorded in the CIB.
When a service or a node dies, the same thing happens. The Designated Coordinator is informed by the Cluster Consensus Membership service (in case of a node death) or by a Local Resource Manager (in case of a failed monitor operation). The Designated Coordinator determines that actions need to be taken in order to come to a new cluster state. The new cluster state will be represented by a new CIB.
