All tasks that should be managed by a cluster must be available as a resource. There are two major groups that should be distinguished: resource agents and STONITH agents. For both categories, you can add your own agents, extending the abilities of the cluster to your own needs.
A cluster sometimes detects that one of the nodes is misbehaving
and needs to remove it. This is called fencing
and is commonly done with a STONITH resource.
All STONITH resources reside in
/usr/lib/stonith/plugins on each
node. Exactly how the agent fences the node varies. Methods include
powering off, rebooting, and shutting down.
To test a configuration, it is sufficient to use the
ssh STONITH agent, which simply powers off
the node. However, because it is impossible to know how SSH might react to
other system problems, this STONITH agent is not a good choice
for a production environment.
To get a list of all currently available STONITH devices (from the software side), use the command stonith -L.
Unfortunately, there is no documentation about writing STONITH agents yet. If you want to write new STONITH agents, consult the examples available in the source of the heartbeat package.
All services that are controlled by the cluster have a corresponding RA that handles the changes and monitoring of this service. These RAs are available in three different flavors:
All the resources from Heartbeat 1 are still available in Heartbeat 2. However, it is recommended to migrate your configurations to Heartbeat 2 OCF RAs if possible.
LSB scripts are exactly the same scripts as used in the initialization process when booting the system. Read more about these scripts in the Installation and Administration guide of SUSE Linux Enterprise Server. If you are familiar with this kind of script, it may be the easiest way to extend Heartbeat to your needs.
OCF RA scripts are best suited for use with Heartbeat. With these
scripts, it is also possible to add the same service type
multiple times and still control each of these resources
individually. There is also a standard interface for the
documentation of this kind of RA scripts. In some cases, such as
when using master_slave resources or when
needing special monitoring abilities, you need this type of
resource.
For a detailed list of all available OCF RAs, refer to Appendix A, HB OCF Agents.
All OCF RAs are available in
/usr/lib/ocf/resource.d/. The scripts that are
delivered with the Heartbeat package are found in this directory in
the subdirectory heartbeat. To avoid name
clashes, create a different subdirectory when creating new
resource agents. For example, if you have a resource group
kitchen with the resource
coffee_machine, add this resource to
the directory
/usr/lib/ocf/resource.d/kitchen/. To access
this RA, the configuration would look like:
<primitive id="coffee_1" class="ocf" type="coffee_machine" provider="kitchen"/>
When implementing your own OCF RA, provide several actions for this agent. More details about writing OCF resource agents can be found at http://www.linux-ha.org/OCFResourceAgent.