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:
- Export our list of XFS mount options to avoid long lines by executing these commands:
OPS=noatime,nodiratime,logbufs=8,logbsize=256k OPS=$OPS,attr2,allocsize=1m
- Add an XFS
primitiveto Pacemaker withcrm: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"
- Clean up any errors that might have accumulated with
crm:crm resource cleanup pg_fs - Display the status of our new XFS resource with
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.
Tip
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:
- The
deviceparameter tells Pacemaker which device it should try to mount. From the previous chapter, this is/dev/VG_POSTGRES/LV_DATA. - The
directoryspecifies where the device should be mounted. Following the example set by our previous chapter, this is the/dbdirectory. - By setting
fstype, we explicitly tell Pacemaker we are attempting to mount anxfsfilesystem. Modern mount commands can often determine the filesystem automatically, but we advocate a more cautious approach. - Finally, we set the mount
options. Our list of options was very long, so we stored it in the$OPSvariable, 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.