Resource agents

A resource agent is a program, typically a shell script, that has been written to start, stop, and monitor a resource. For every resource that you want Heartbeat to manage, an associated resource agent handles all the operations.

Heartbeat version 2 is compatible with four classes of resource agents:

򐂰 OCF-based resource agent

򐂰 LSB init scripts in /etc/init.d/

򐂰 Classic Heartbeat resource scripts

򐂰 STONITH resource agent

For a few types of resources, there is an OCF-based RA and an LSB-based RA.

For example, O2CB is a component of Open Cluster File System 2 (OCFS2).

Also, there is an RA of class “ocf/heartbeat” and another one of class “lsb.”

Typically there is no difference in operational functionality between the two different classes. You might choose one over the other for reasons such as flexibility and personal preference.

For a solution that requires multiple Heartbeat resources, you can mix and match among RA classes. For example, you can have an O2CB resource of class LSB and a Filesystem resource of class OCF, both managed under the same cluster.

In this section, we provide an overview of each class of resource agent and discuss the usage scenarios for each class.

OCF resource agents

The Open Cluster Framework project defines standard clustering APIs for basic capabilities such as node services, resource services, and clustering services.

OCF-based resource agents are only supported by Heartbeat version 2. The

Heartbeat version 2 package comes with over 40 OCF-based resource agents, which are in the /usr/lib/ocf/resource.d/heartbeat/ directory. For more information about the OCF project, see the following Web address:

http://opencf.org/home.html

The OCF RAs are more powerful and flexible than the LSB RAs because they are based on an open standard that is recognized by other organizations and used by other development efforts. The OCF standard is supported by a variety of organizations and companies such as IBM, COMPAQ, Open Source

Development Lab, and so on. The SUSE Linux Enterprise Server Heartbeat guide states: “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.”⁶

With OCF RAs, you can also configure resource-related parameters and options directly inside Heartbeat. LSB RAs do not allow you to do that. You can even write an OCF-based RA based on an existing LSB init script to allow for parameters and options. An example of this is the OCF O2CB agent, which is written around the LSB O2CB agent. It is used to load, start, and stop OCFS2 modules and clusters.

LSB resource agents

Heartbeat also works with the LSB init scripts in the /etc/init.d/ directory.

SUSE Linux Enterprise Server (SLES) and Red Hat Enterprise Linux on System z provide these scripts with the standard distribution. A default installation of the operating system includes the basic scripts for the various services that come with the distribution such as Network File System (NFS) and cups. For more information about the LSB specification, see the following Web address:

http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Cor e-generic/iniscrptact.html

When you create a Heartbeat resource by using the LSB init script, you give Heartbeat control of this resource and should not operate this resource directly through the init script while Heartbeat is running. For example, you define an NFS server resource of type LSB in Heartbeat, and Heartbeat is running. In this case, only go through Heartbeat to stop and start the NFS server, and do not manually enter /etc/init.d/nfs start and /etc/init.d/nfs stop. Heartbeat sometimes places a lock on the init script to prevent you from doing this.

Unlike with OCF RAs, LSB resource agents do not accept any parameters or options. Some resources require you to configure resource-related parameters and options outside of Heartbeat and use Heartbeat only to start, stop, and monitor the resource.

LSB resource agents are supported by both Heartbeat version 1 and version 2.

Therefore, if you are an existing Heartbeat version 1 user and simply want to migrate to version 2, you can continue to use LSB RAs.

Heartbeat resource agents

The classic Heartbeat RAs are script-based programs that are similar to LSB init scripts. Unlike LSB RAs, parameters are allowed with Heartbeat RAs. Many Heartbeat RAs are wrapper scripts around OCF RAs. These wrapper scripts handle argument parsing and checking, as well as logistics checking and automation.

When you see a resource with the “ocf/heartbeat” class, there is a wrapper Heartbeat RA around the OCF RA. When there is a classic Heartbeat RA wrapper for an OCF RA, you can never define or invoke the OCF RA directly. The wrapper provides the argument handling required for the resource to function properly under Heartbeat.

The Heartbeat RAs are in the /etc/ha.d/resource.d/ directory. They come packaged with Heartbeat.

STONITH resource agent

Shoot The Other Node In The Head (STONITH) is Linux-HA’s technique for fencing. Fencing is the term used for the actions taken to ensure that a

misbehaving node in a cluster does not access shared resources and does not respond to incoming requests. By halting the errant node, you take care of both.

The STONITH resource agent provides a wrapper for instantiating STONITH objects to be used by the STONITH daemon. The STONITH daemon provides a high level interface to fence one or more errant nodes. The STONITH daemon that comes with Heartbeat version 2 uses the improved release 2 STONITH API.

There are many STONITH device types, or methods, for resetting a node, such as lic_vps or ssh. They are represented by STONITH plug-ins.

The STONITH daemon and STONITH plug-ins are provided by the

heartbeat-stonith package. For more information about STONITH, see 2.2.6,

“Fencing in Linux-HA” on page 23. For implementation and usage examples of the STONITH plug-ins on the System z platform, see 3.1.4, “Heartbeat STONITH mechanisms for the System z server” on page 49.