/ 5.3. Creating Cluster Resources | ||||
|---|---|---|---|---|
 | 5.2. Debugging Your Configuration Changes | 5.4. Creating a STONITH Resource |  | |
/ 5.3. Creating Cluster Resources | ||||
|---|---|---|---|---|
| 5.2. Debugging Your Configuration Changes | 5.4. Creating a STONITH Resource | | |
There are three types of RAs (Resource Agents) available with the cluster. First, there are legacy Heartbeat 1 scripts. High availability can make use of LSB initialization scripts. Finally, the cluster has its own set of OCF (Open Cluster Framework) agents. This documentation concentrates on LSB scripts and OCF agents.
To create a cluster resource use the crm tool. To add a new resource to the cluster, the general procedure is as follows:
Open a shell and become root.
Run crm to open the internal shell of
crm. The prompt changes to
crm(live)#.
Configure a primitive IP address:
crm(live)# configure crm(live)configure# primitive myIP ocf:heartbeat:IPaddr \ params ip=127.0.0.99 op monitor intervall=60s
The previous command configures a “primitive” with the
name myIP. You need the class (here
ocf), provider (heartbeat), and
type (IPaddr). Furthermore this primitive expects
some parameters like the IP address. You have to change the address to
your setup.
Display and review the changes you have made:
crm(live)configure# showTo see the XML structure, use the following:
crm(live)configure# show xmlCommit your changes to take effect:
crm(live)configure# commit
All LSB scripts are commonly found in the directory
/etc/init.d. They must have several actions
implemented, which are at least start,
stop, restart,
reload, force-reload, and
status as explained in
http://www.linux-foundation.org/spec/refspecs/LSB_1.3.0/gLSB/gLSB/iniscrptact.html.
The configuration of those services is not standardized. If you intend
to use an LSB script with High Availability, make sure that you understand how the
respective script is configured. Often you can find some documentation
to this in the documentation of the respective package in
/usr/share/doc/packages/.
PACKAGENAME
![[Note]](admon/note.png) | Do Not Touch Services Used by High Availability |
|---|---|
When used by High Availability, the service should not be touched by other means. This means that it should not be started or stopped on boot, reboot, or manually. However, if you want to check if the service is configured properly, start it manually, but make sure that it is stopped again before High Availability takes over. | |
Before using an LSB resource, make sure that the configuration of this resource is present and identical on all cluster nodes. The configuration is not managed by High Availability. You must take care of that yourself.
All OCF agents are located in
/usr/lib/ocf/resource.d/heartbeat/. These are small
programs that have a functionality similar to that of LSB scripts.
However, the configuration is always done with environment variables.
All OCF Resource Agents are required to have at least the actions
start, stop,
status, monitor, and
meta-data. The meta-data action
retrieves information about how to configure the agent. For example, if
you want to know more about the IPaddr agent, use the
command:
OCF_ROOT=/usr/lib/ocf /usr/lib/ocf/resource.d/heartbeat/IPaddr meta-data
The output is lengthy information in a simple XML format.
You can validate the output with the ra-api-1.dtd
DTD. Basically this XML format has three sections—first several
common descriptions, second all the available parameters, and last the
available actions for this agent.
This output is meant to be machine-readable, not very readable. For this reason, the crm tool contains the ra command to get different information about resource agents:
# crm
crm(live)# ra
crm(live)ra#The command classes gives you a list of all classes and providers:
crm(live)ra# classes
stonith
lsb
ocf / lvm2 ocfs2 heartbeat pacemaker
heartbeatTo get an overview about all available resource agents for a class (and provider) use list:
crm(live)ra# list ocf
AudibleAlarm ClusterMon Delay Dummy
Filesystem ICP IPaddr IPaddr2
IPsrcaddr IPv6addr LVM LinuxSCSI
MailTo ManageRAID ManageVE Pure-FTPd
Raid1 Route SAPDatabase SAPInstance
SendArp ServeRAID SphinxSearchDaemon Squid
...More information about a resource agent can be viewed with meta:
crm(live)ra# meta Filesystem ocf heartbeat
Filesystem resource agent (ocf:heartbeat:Filesystem)
Resource script for Filesystem. It manages a Filesystem on a shared storage medium.
Parameters (* denotes required, [] the default):
...You can leave the viewer by pressing Q. Find a configuration example at Chapter 6, Setting Up a Simple Testing Resource.
To set up the NFS server, three resources are needed: a file system resource, a drbd resource, and a group of an NFS server and an IP address. The following subsection shows you how to do it.
The filesystem resource is configured as an OCF
primitive resource. It has the task to mount and unmount a device to a
directory on start and stop requests. In this case, the device is
/dev/drbd0 and the directory to use as mount point
is /srv/failover. The file system used is
xfs.
Use the following commands in the crm shell to configure a filesystem resource:
crm(live)# configure crm(live)configure# primitive filesystem_resource \ ocf:heartbeat:Filesystem \ params device=/dev/drbd0 directory=/srv/failover fstype=xfs
Before starting with the drbd High Availability configuration, set up a
drbd device manually. Basically this is configuring
drbd in /etc/drbd.conf and letting it synchronize.
The exact procedure for configuring drbd is described in the Storage Administration Guide.
For now, assume that you configured a resource r0
that may be accessed at the device /dev/drbd0 on
both of your cluster nodes.
The drbd resource is an OCF master slave resource.
This can be found in the description of the metadata of the drbd RA.
However, more important is that there are the actions
promote and demote in the
actions section of the metadata. These are mandatory
for master slave resources and commonly not available to other
resources.
For High Availability, master slave resources may have multiple masters on different
nodes. It is even possible to have a master and slave on the same node.
Therefore, configure this resource in a way that there is exactly one
master and one slave, each running on different nodes. Do this with the
meta attributes of the master resource. Master slave
resources are a special kind of clone resources in High Availability. Every master
and every slave counts as a clone.
Use the following commands in the crm shell to configure a master slave resource:
crm(live)# configure crm(live)configure# primitive drbd_r0 ocf:heartbeat:drbd params crm(live)configure# ms drbd_resource drbd_r0 \ meta clone_max=2 clone_node_max=1 master_max=1 master_node_max=1 notify=true crm(live)configure# commit
To make the NFS server always available at the same IP address, use an additional IP address as well as the ones the machines use for their normal operation. This IP address is then assigned to the active NFS server in addition to the system's IP address.
The NFS server and the IP address of the NFS server should always be active on the same machine. In this case, the start sequence is not very important. They may even be started at the same time. These are the typical requirements for a group resource.
Before starting the High Availability RA configuration, configure the NFS server
with YaST. Do not let the system start the NFS server. Just set up
the configuration file. If you want to do that manually, see the manual
page exports(5) (man 5 exports). The configuration
file is /etc/exports. The NFS server is configured
as an LSB resource.
Configure the IP address completely with the High Availability RA configuration. No additional modification is necessary in the system. The IP address RA is an OCF RA.
crm(live)# configure crm(live)configure# primitive nfs_resource lsb:nfsserver crm(live)configure# primitive ip_resource ocf:heartbeat:IPaddr \ params ip=10.10.0.1 crm(live)configure# group nfs_group nfs_resource ip_resource crm(live)configure# commit crm(live)configure# end crm(live)# quit
