Next in our list of resources to manage with Pacemaker is the filesystem. As with LVM and DRBD, Pacemaker needs the ability to start and stop the resource arbitrarily to clear locks or enable activation. In addition, filesystems are somewhat more complex than LVM simply due to the amount of necessary parameters required to use them.
In order for Pacemaker to manage a filesystem, we need to tell it about the device it's mounting, which directory the mount should target, the type of filesystem, and any extra options we want to use. While DRBD and LVM encode metadata within reserved storage areas on the device, filesystem mounts require explicit parameters.
This recipe will explain the steps necessary to manage our XFS filesystem with Pacemaker.
As we're continuing to configure Pacemaker, make sure you've followed all the previous recipes.
Perform these steps on any Pacemaker node as the root
user:
OPS=noatime,nodiratime,logbufs=8,logbsize=256k OPS=$OPS,attr2,allocsize=1m
primitive
to Pacemaker with crm
:crm configure primitive pg_fs ocf:heartbeat:Filesystem params device="/dev/VG_POSTGRES/LV_DATA" directory="/db" fstype="xfs" options="$OPS" op start interval="0" timeout="60" op stop interval="0" timeout="120"
crm
:crm resource cleanup pg_fs
crm
:crm resource status
Due to the limited format of this book, we wanted to avoid excessive line wrapping in the commands we present. Thus, the first step simply saves all of the XFS mount options from the previous chapter in a variable named OPS
that we can reuse when adding the Pacemaker primitive
.
Regarding the primitive
itself, we continue our preferred naming scheme and label it pg_fs
(for the PostgreSQL filesystem). As usual, we need a resource agent to facilitate Pacemaker management, and the ocf:heartbeat:Filesystem
agent fills that role nicely.
As with all agents, to see the list of parameters for a resource agent, use the ra meta
command to the crm
shell. For the Filesystem
agent, this invocation would display usage information:
crm ra meta ocf:heartbeat:Filesystem
We highly recommend that you use this command in each recipe, if only to verify the parameters act as we claim they do.
This time, the list of parameters (params
) we set for the resource agent is somewhat longer than what we used for LVM. Here's a short explanation of each:
device
parameter tells Pacemaker which device it should try to mount. From the previous chapter, this is /dev/VG_POSTGRES/LV_DATA
.directory
specifies where the device should be mounted. Following the example set by our previous chapter, this is the /db
directory.fstype
, we explicitly tell Pacemaker we are attempting to mount an xfs
filesystem. Modern mount commands can often determine the filesystem automatically, but we advocate a more cautious approach.options
. Our list of options was very long, so we stored it in the $OPS
variable, which we used here.The other options (op
) we set are more advisory minimum values, which reflect the number of seconds we should wait before considering an operation as failed. The timeouts to start and stop a filesystem are somewhat longer than an LVM device, because filesystems can have direct users. A filesystem user includes any terminals currently located in a mounted directory, automated tasks using it as a file target, or files held open by a running process—any one of these can prevent a filesystem from being unmounted.
As usual, we perform a resource cleanup
on the pg_fs
device to clear out any invalid errors. Afterwards, we can view the clean resource status
with crm
, which looks like this on our test system:
As expected, we can see that pg_fs
has joined our growing list of Pacemaker resources.
3.145.75.217