Keeping shared storage available during node failures gets tricky when the data lives on a filesystem that must never be mounted in two places at once. Pairing DRBD block replication with a cluster-managed filesystem mount keeps the volume writable on a single node, while still allowing fast failover when the active node disappears.
In a typical Pacemaker + Corosync cluster, DRBD provides a replicated block device with a Primary and Secondary role, and the pcs CLI manages that role as a promotable resource. A separate OCF Filesystem resource mounts the DRBD device only on the promoted node, and constraints ensure promotion happens before mounting and colocation keeps both resources together.
The DRBD resource must already be configured on every node (for example in /etc/drbd.d) and be fully synchronized before the cluster starts managing the mount. The filesystem must be created once on the DRBD device before mounting under cluster control, and the device path, mount directory, and filesystem type must be consistent across nodes. Quorum and fencing (STONITH) are critical to prevent split-brain and double-primary writes on the same filesystem.
Steps to set up DRBD-backed filesystem high availability with PCS:
- Confirm the cluster is online and has quorum.
$ sudo pcs status Cluster name: clustername Stack: corosync Current DC: node-02 (version 2.1.7) - partition with quorum ##### snipped #####
- Check the DRBD resource role and replication state.
$ sudo drbdadm status ha-data ha-data role:Primary disk:UpToDate peer role:Secondary replication:Established peer-disk:UpToDateUse the resource name that matches /etc/drbd.d and the intended drbd_resource= value.
- Create the mountpoint directory on every cluster node.
$ sudo mkdir -p /srv/drbd
The mount directory must match the directory= value in the Filesystem resource.
- Confirm the DRBD device contains the expected filesystem signature.
$ sudo blkid /dev/drbd0 /dev/drbd0: LABEL="drbd-data" UUID="1f2b7c2e-9f46-4edb-8c4b-cc08f1f4d7a1" TYPE="xfs"
Creating a filesystem (mkfs) on the wrong device destroys data, and running mkfs more than once on the same replicated volume can cause corruption.
- Create the DRBD cluster resource.
$ sudo pcs resource create drbd_data ocf:linbit:drbd drbd_resource=ha-data op monitor interval=20s
Use a stable DRBD resource name (drbd_resource=) that exists on all nodes.
- Promote the DRBD resource so it can switch between primary and secondary.
$ sudo pcs resource promotable drbd_data
Use pcs resource master on older pcs releases.
- Create the filesystem resource for the DRBD device.
$ sudo pcs resource create drbd_fs ocf:heartbeat:Filesystem device=/dev/drbd0 directory=/srv/drbd fstype=xfs op monitor interval=20s
Use the DRBD device path, mount directory, and fstype= that match the existing filesystem on the replicated volume.
- Add an order constraint to start the filesystem only after DRBD is promoted.
$ sudo pcs constraint order promote drbd_data-clone then start drbd_fs
The promotable clone ID commonly defaults to <primitive>-clone (for example drbd_data-clone).
- Add a colocation constraint to keep the filesystem on the DRBD master node.
$ sudo pcs constraint colocation add drbd_fs with master drbd_data-clone
- Verify the promotable resource and filesystem status.
$ sudo pcs status resources Promotable Clone: drbd_data-clone Masters: [ node-02 ] Slaves: [ node-01 ] drbd_fs (ocf::heartbeat:Filesystem): Started node-02
- Confirm the filesystem is mounted on the current DRBD master node.
$ sudo mount | grep /srv/drbd /dev/drbd0 on /srv/drbd type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota)
Run the same check on other nodes to confirm the mount appears on only one node at a time.
- Run a failover test after the filesystem is mounted.
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.
