Install and Configure DRBD on RHEL 10 / Rocky Linux 10 [Guide]

DRBD (Distributed Replicated Block Device) is a Linux kernel module that mirrors block devices between servers in real time. Think of it as network-based RAID 1 – your data is written to both local and remote disks simultaneously, giving you a fully synchronized copy on a second node. This is the foundation for high availability storage in Linux environments where downtime is not an option.

Original content from computingforgeeks.com - post 60755

This guide walks through installing and configuring DRBD 9 on RHEL 10 and Rocky Linux 10. We cover the full setup – from installing packages to creating a replicated resource, handling failover, firewall rules, and integrating with Pacemaker/Corosync for automatic failover. DRBD 9.3.1 is the latest kernel module version available from ELRepo at the time of writing.

Prerequisites

Before starting, make sure you have the following in place:

Two servers running RHEL 10 or Rocky Linux 10 with root or sudo access
An extra unpartitioned disk or partition on each server (same size on both nodes) – this will be the DRBD backing device. You can also use an LVM logical volume as the backing device
Network connectivity between both servers (dedicated DRBD network recommended for production)
DNS or /etc/hosts entries so each node can resolve the other by hostname
Firewall access on TCP ports 7788-7799 between the two nodes

For this guide, we use the following setup:

Hostname	IP Address	DRBD Disk
node1.example.com	10.0.1.10	/dev/sdb
node2.example.com	10.0.1.11	/dev/sdb

Set up hostname resolution on both nodes by editing /etc/hosts:

sudo vi /etc/hosts

Add these entries on both servers:

10.0.1.10  node1.example.com  node1
10.0.1.11  node2.example.com  node2

Step 1: Install DRBD on RHEL 10 / Rocky Linux 10

DRBD is not included in the default RHEL/Rocky repositories. We install it from ELRepo, which provides the kernel module and userspace utilities for EL10 systems.

Run these commands on both nodes. First, import the ELRepo GPG key and install the repository:

sudo rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
sudo dnf install -y https://www.elrepo.org/elrepo-release-10.el10.elrepo.noarch.rpm

Install the DRBD 9 kernel module and utilities:

sudo dnf install -y kmod-drbd9x drbd9x-utils

Load the DRBD kernel module:

sudo modprobe drbd

Verify the module loaded successfully:

lsmod | grep drbd

You should see the DRBD module listed in the output:

drbd                  647168  0
drbd_transport_tcp     28672  0
lru_cache              16384  1 drbd
libcrc32c              16384  2 drbd,xfs

Make the module load automatically on boot:

echo "drbd" | sudo tee /etc/modules-load.d/drbd.conf

Check the installed DRBD version to confirm everything is working:

drbdadm --version

The output shows both the userspace tools and kernel module versions:

DRBDADM_BUILDTAG=GIT-hash:\ built\ from\ source
DRBDADM_API_VERSION=2
DRBD_KERNEL_VERSION_CODE=0x090301
DRBD_KERNEL_VERSION=9.3.1
DRBDADM_VERSION_CODE=0x092100
DRBDADM_VERSION=9.33.0

Step 2: Configure DRBD Resource

DRBD configuration lives in /etc/drbd.d/. The main config file /etc/drbd.conf includes everything from that directory. Each replicated device is defined as a “resource” in its own .res file.

Create a resource configuration file on both nodes. The configuration must be identical on both servers:

sudo vi /etc/drbd.d/data.res

Add the following resource definition:

resource data {
    protocol C;

    net {
        after-sb-0pri discard-zero-changes;
        after-sb-1pri discard-secondary;
        after-sb-2pri disconnect;
    }

    disk {
        on-io-error detach;
    }

    on node1.example.com {
        device /dev/drbd0;
        disk /dev/sdb;
        address 10.0.1.10:7789;
        meta-disk internal;
    }

    on node2.example.com {
        device /dev/drbd0;
        disk /dev/sdb;
        address 10.0.1.11:7789;
        meta-disk internal;
    }
}

Here is what each setting means:

protocol C – synchronous replication. A write is only considered complete when both nodes have written it to disk. This is the safest option for data integrity
after-sb-* – split-brain recovery policies. These define automatic recovery behavior if the nodes lose contact and both accept writes
on-io-error detach – if the backing disk fails, DRBD detaches from it and continues running in diskless mode rather than crashing
device /dev/drbd0 – the DRBD block device that applications will use
disk /dev/sdb – the physical backing device on each node
meta-disk internal – DRBD metadata is stored on the same disk as the data

Step 3: Initialize DRBD Metadata and Bring Up the Resource

With the configuration in place on both nodes, initialize the DRBD metadata on the backing device. Run this on both nodes:

sudo drbdadm create-md data

When prompted, type yes to confirm. The output shows the metadata being written:

initializing activity log
initializing bitmap (640 KB) to all zero
Writing meta data...
New drbd meta data block successfully created.

Bring up the DRBD resource on both nodes:

sudo drbdadm up data

Check the connection status:

sudo drbdadm status data

Both nodes should show as Connected with Secondary role and Inconsistent data (this is expected since no initial sync has happened yet):

data role:Secondary
  disk:Inconsistent
  peer role:Secondary
    replication:Connected peer-disk:Inconsistent

Step 4: Set the Primary Node and Start Initial Sync

One node must be designated as Primary to trigger the initial full synchronization. Run this on node1 only:

sudo drbdadm primary --force data

The --force flag is needed only for the initial sync because both disks are currently marked as Inconsistent. After this, DRBD starts synchronizing data from node1 to node2.

Monitor the sync progress:

sudo drbdadm status data

During synchronization, you will see the progress percentage and estimated time remaining:

data role:Primary
  disk:UpToDate
  peer role:Secondary
    replication:SyncSource peer-disk:Inconsistent
    done:45.20

Wait for synchronization to complete. When finished, both nodes show UpToDate:

data role:Primary
  disk:UpToDate
  peer role:Secondary
    replication:Established peer-disk:UpToDate

For large disks, the initial sync can take a while. You can check detailed progress with /proc/drbd:

cat /proc/drbd

Step 5: Create Filesystem and Mount the DRBD Device

Once synchronization is complete, create a filesystem on the DRBD device. This is done on the Primary node (node1) only:

sudo mkfs.xfs /dev/drbd0

Create a mount point and mount the device:

sudo mkdir -p /mnt/drbd
sudo mount /dev/drbd0 /mnt/drbd

Verify the mount:

df -h /mnt/drbd

The output confirms the DRBD device is mounted and shows the available space:

Filesystem      Size  Used Avail Use% Mounted on
/dev/drbd0       20G  175M   20G   1% /mnt/drbd

Write a test file to confirm data replication is working:

echo "DRBD replication test" | sudo tee /mnt/drbd/test.txt
cat /mnt/drbd/test.txt

Do not add the DRBD device to /etc/fstab – if you are using Pacemaker/Corosync for automatic failover, the cluster manager handles mounting. For manual failover setups, mount it only on the active Primary node.

Step 6: Test Manual Failover

Testing failover ensures your DRBD setup actually works when you need it. This process involves demoting the current Primary and promoting the Secondary.

On node1 (current Primary), unmount and demote:

sudo umount /mnt/drbd
sudo drbdadm secondary data

On node2, promote to Primary and mount:

sudo drbdadm primary data
sudo mkdir -p /mnt/drbd
sudo mount /dev/drbd0 /mnt/drbd

Verify the test file we created earlier is intact on node2:

cat /mnt/drbd/test.txt

The file should contain “DRBD replication test”, confirming data was fully replicated. Check the status from node2:

sudo drbdadm status data

Node2 is now Primary and node1 is Secondary:

data role:Primary
  disk:UpToDate
  peer role:Secondary
    replication:Established peer-disk:UpToDate

To switch back, reverse the process – unmount and demote on node2, then promote and mount on node1.

Step 7: Configure Firewall Rules for DRBD

DRBD uses TCP for replication traffic. The default port range is 7788-7799, with each resource using one port. Our configuration uses port 7789. If you are new to firewalld on RHEL/Rocky Linux, check our dedicated guide. Open the required ports on both nodes:

sudo firewall-cmd --permanent --add-port=7788-7799/tcp
sudo firewall-cmd --reload

Verify the firewall rules are active:

sudo firewall-cmd --list-ports

The output should include the DRBD port range:

7788-7799/tcp

For production environments, restrict the port to only the peer node’s IP for tighter security:

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.0.1.11" port port="7788-7799" protocol="tcp" accept'
sudo firewall-cmd --reload

Step 8: Integrate DRBD with Pacemaker and Corosync

Manual failover works, but production systems need automatic failover. Pacemaker and Corosync handle this by monitoring node health and automatically promoting the Secondary when the Primary fails.

Install the HA cluster packages on both nodes:

sudo dnf install -y pacemaker corosync pcs

Enable and start the PCS daemon on both nodes:

sudo systemctl enable --now pcsd

Set a password for the hacluster user on both nodes:

sudo passwd hacluster

Authenticate the nodes from node1:

sudo pcs host auth node1.example.com node2.example.com -u hacluster

Create the cluster:

sudo pcs cluster setup drbd_cluster node1.example.com node2.example.com

Start and enable the cluster on all nodes:

sudo pcs cluster start --all
sudo pcs cluster enable --all

For a two-node cluster, disable STONITH temporarily (you should configure proper fencing for production) and set the no-quorum policy:

sudo pcs property set stonith-enabled=false
sudo pcs property set no-quorum-policy=ignore

Before adding DRBD resources to Pacemaker, stop and unmount DRBD on both nodes since the cluster manager will control it from now on:

sudo umount /mnt/drbd
sudo drbdadm secondary data

Create the DRBD cluster resource and a promotable clone:

sudo pcs resource create drbd_data ocf:linbit:drbd drbd_resource=data op monitor interval=30s
sudo pcs resource promotable drbd_data promoted-max=1 promoted-node-max=1 clone-max=2 clone-node-max=1 notify=true

Create a filesystem resource that mounts the DRBD device on the Primary node:

sudo pcs resource create drbd_fs ocf:heartbeat:Filesystem device=/dev/drbd0 directory=/mnt/drbd fstype=xfs

Add constraints so the filesystem only runs where DRBD is Primary, and the filesystem starts after DRBD promotion:

sudo pcs constraint colocation add drbd_fs with drbd_data-clone INFINITY with-rsc-role=Promoted
sudo pcs constraint order promote drbd_data-clone then start drbd_fs

Verify the cluster status:

sudo pcs status

The output shows DRBD running on both nodes with one promoted to Primary, and the filesystem mounted on the Primary node. Pacemaker now handles automatic failover – if node1 goes down, node2 is automatically promoted and the filesystem is mounted there.

Step 9: Monitor DRBD Status

Regular monitoring ensures replication stays healthy and catches problems early. DRBD provides several ways to check the status of your replicated resources.

The primary monitoring command shows the current role, connection state, and disk status:

sudo drbdadm status

For a healthy setup, both disks show UpToDate and the connection is Established:

data role:Primary
  disk:UpToDate
  peer role:Secondary
    replication:Established peer-disk:UpToDate

The /proc/drbd file provides detailed statistics including sync progress, data transferred, and connection info:

cat /proc/drbd

For distributed storage environments, you can use the drbdtop utility for a real-time overview if available, or watch the status continuously:

watch -n 2 'drbdadm status'

Key states to watch for during monitoring:

UpToDate/UpToDate – both disks are in sync (healthy state)
SyncSource/SyncTarget – synchronization is in progress
Inconsistent – disk needs synchronization
StandAlone – node is disconnected from its peer. Run drbdadm connect data to reconnect

DRBD Command Reference

Here is a quick reference of the most common DRBD administration commands:

Command	Description
`drbdadm status`	Show current status of all DRBD resources
`drbdadm up data`	Bring up a DRBD resource
`drbdadm down data`	Take down a DRBD resource
`drbdadm primary data`	Promote node to Primary for a resource
`drbdadm secondary data`	Demote node to Secondary for a resource
`drbdadm connect data`	Reconnect to the peer node
`drbdadm disconnect data`	Disconnect from the peer node
`drbdadm create-md data`	Initialize DRBD metadata on a resource
`drbdadm verify data`	Run online verification of data consistency
`drbdadm invalidate data`	Force full resync from the peer
`drbdadm adjust data`	Apply configuration changes without restart
`cat /proc/drbd`	Show detailed DRBD kernel status

Conclusion

You now have DRBD 9 configured for real-time block-level replication between two RHEL 10 / Rocky Linux 10 servers, with Pacemaker handling automatic failover. This setup gives you a solid foundation for high availability storage.

For production deployments, configure proper STONITH/fencing devices in Pacemaker, use a dedicated network interface for DRBD replication traffic, and set up monitoring alerts for DRBD state changes. Consider running DRBD alongside other storage solutions depending on your workload requirements. Regular drbdadm verify runs catch any silent data corruption before it becomes a problem.