Your submission was sent successfully! Close

You have successfully unsubscribed! Close

Thank you for signing up for our newsletter!
In these regular emails you will find the latest updates about Ubuntu and upcoming events where you can meet our team.Close

Pacemaker resource agents

From the ClusterLabs definition:

Resource agents are the abstraction that allows Pacemaker to manage services it knows nothing about. They contain the logic for what to do when the cluster wishes to start, stop or check the health of a service. This particular set of agents conform to the Open Cluster Framework (OCF) specification.

Currently, the resource-agents binary package has been split into two: resource-agents-base and resource-agents-extra. The resource-agents-base binary package contains a set of curated agents which the Ubuntu Server team continuously runs tests on to make sure everything is working as expected. All the other agents previously in the resource-agents binary package are now found in the resource-agents-extra package.

The resource-agents-base binary package contains the following agents in the latest Ubuntu release:

  • IPaddr2
  • iscsi
  • iSCSILogicalUnit
  • iSCSITarget
  • LVM-activate
  • systemd

All of these agents are in main and are fully supported.

All other agents are in resource-agents-extra and while most of them are supported by upstream, they are not curated by the Ubuntu Server team. The set of resource agents that are not maintained by upstream is listed in /usr/share/doc/resource-agents-extra/DEPRECATED_AGENTS, the use of those agents is discouraged.

For the resource agents provided by resource-agents-base, we will briefly describe how to use them.

Note:
There are two well known tools used to manage fence agents, they are crmsh and pcs. Here we will present examples with both, since crmsh is the recommended and supported tool until Ubuntu 22.10 Kinetic Kudu, and pcs is the recommended and supported tool from Ubuntu 23.04 Lunar Lobster onwards. For more information on how to migrate from crmsh to pcs please refer to this migration guide.

IPaddr2

From its manpage:

This Linux-specific resource manages IP alias IP addresses. It can add an IP alias, or remove one. In addition, it can implement Cluster Alias IP functionality if invoked as a clone resource.

One could configure a IPaddr2 resource with the following command:

$ crm configure primitive $RESOURCE_NAME ocf:heartbeat:IPaddr2 \
            ip=$IP_ADDRESS \
            cidr_netmask=$NET_MASK \
            op monitor interval=30s

One can do the same using pcs via the following command:

$ pcs resource create $RESOURCE_NAME ocf:heartbeat:IPaddr2 \
            ip=$IP_ADDRESS \
            cidr_netmask=$NET_MASK \
            op monitor interval=30s

This is one way to set up IPaddr2, for more information refer to its manpage.

iscsi

From its manpage:

Manages a local iSCSI initiator and its connections to iSCSI targets.

Once the iSCSI target is ready to accept connections from the initiator(s), with all the appropriate permissions, the iscsi resource can be configured with the following command:

$ crm configure primitive $RESOURCE_NAME ocf:heartbeat:iscsi \
          target=$TARGET \
          portal=$PORTAL

One can do the same using pcs via the following command:

$ pcs resource create $RESOURCE_NAME ocf:heartbeat:iscsi \
          target=$TARGET \
          portal=$PORTAL

Where $TARGET is the iSCSI Qualified Name (IQN) of the iSCSI target and $PORTAL its address, which can be, for instance, formed by the IP address and port number used by the target daemon.

This is one way to set up iscsi, for more information refer to its manpage.

iSCSILogicalUnit

From its manpage:

Manages iSCSI Logical Unit. An iSCSI Logical unit is a subdivision of an SCSI Target, exported via a daemon that speaks the iSCSI protocol.

This agent is usually used alongside with iSCSITarget to manage the target itself and its Logical Units. The supported implementation of iSCSI targets is using targetcli-fb, due to that, make sure to use lio-t as the implementation type. Considering one has an iSCSI target in place, the iSCSILogicalUnit resource could be configured with the following command:

$ crm configure primitive $RESOURCE_NAME ocf:heartbeat:iSCSILogicalUnit \
          implementation=lio-t \
          target_iqn=$IQN_TARGET \
          path=$DEVICE \
          lun=$LUN

One can do the same using pcs via the following command:

$ pcs resource create $RESOURCE_NAME ocf:heartbeat:iSCSILogicalUnit \
          implementation=lio-t \
          target_iqn=$IQN_TARGET \
          path=$DEVICE \
          lun=$LUN

Where implementation is set to lio-t as mentioned before, $IQN_TARGET is the iSCSI Qualified Name (IQN) that this Logical Unit belongs to, $DEVICE is the path to the exposed block device, and $LUN is the number representing the Logical Unit which will be exposed to initiators.

This is one way to set up iSCSILogicalUnit, for more information refer to its manpage.

iSCSITarget

From its manpage:

Manages iSCSI targets. An iSCSI target is a collection of SCSI Logical Units (LUs) exported via a daemon that speaks the iSCSI protocol.

This agent is usually used alongside with iSCSILogicalUnit to manage the target itself and its Logical Units. The supported implementation of iSCSI targets is using targetcli-fb, due to that, make sure to use lio-t as the implementation type. With targetcli-fb installed on the system, the iSCSITarget resource can be configured with the following command:

$ crm configure primitive $RESOURCE_NAME ocf:heartbeat:iSCSITarget \
          implementation=lio-t \
          iqn=$IQN_TARGET

One can do the same using pcs via the following command:

$ pcs resource create $RESOURCE_NAME ocf:heartbeat:iSCSITarget \
          implementation=lio-t \
          iqn=$IQN_TARGET

Where implementation is set to lio-t as mentioned before and $IQN_TARGET is the IQN of the target.

This is one way to set up iSCSITarget, for more information refer to its manpage.

LVM-activate

From its manpage:

This agent manages LVM activation/deactivation work for a given volume group.

If the LVM setup is ready to be activated and deactivated by this resource agent (make sure the system_id_resource is set to uname in /etc/lvm/lvm.conf), the LVM-activate resource can be configured with the following command:

$ crm configure primitive $RESOURCE_NAME ocf:heartbeat:LVM-activate \
             vgname=$VOLUME_GROUP \
             vg_access_mode=system_id

One can do the same using pcs via the following command:

$ pcs resource create $RESOURCE_NAME ocf:heartbeat:LVM-activate \
             vgname=$VOLUME_GROUP \
             vg_access_mode=system_id

This is one way to set up LVM-activate, for more information refer to its manpage.

Systemd

There is also a way to manage systemd unit files via a resource agent. One need to have the systemd unit file in place (already loaded by systemd) and configure a resource using the following command:

$ crm configure primitive $RESOURCE_NAME systemd:$SERVICE_NAME

One can do the same using pcs via the following command:

$ pcs resource create $RESOURCE_NAME systemd:$SERVICE_NAME

The $SERVICE_NAME can be any service managed by a systemd unit file, and it needs to be available for the cluster nodes.

Further reading

Previous System tuning: TuneD Next Pacemaker fence agents

This page was last modified a day ago. Help improve this document in the forum.