How to Configure DRBD for High-Availability Storage on RHEL 7

Distributed Replicated Block Device (DRBD) is a Linux kernel module and set of user-space utilities that provide synchronous block-level replication between two servers over a network. It is often described as a network-based RAID-1 and is widely used as the storage layer in high-availability clusters alongside Pacemaker and Corosync. When one node fails, the other holds a complete, up-to-date copy of the data and can take over within seconds. This tutorial covers the full process of setting up DRBD on RHEL 7: installing packages from EPEL, writing the resource configuration, performing the initial synchronization, creating a filesystem, and understanding the failover procedure.

Prerequisites

  • Two RHEL 7 servers: node1 (IP 192.168.1.101) and node2 (IP 192.168.1.102)
  • Both nodes have an identical unused block device, e.g. /dev/sdb (the data disk)
  • Hostnames resolvable between nodes (via /etc/hosts or DNS)
  • EPEL repository enabled on both nodes
  • Root or sudo access on both nodes
  • Firewall rules allowing TCP port 7789 (DRBD default) between the nodes

Step 1: Enable EPEL and Install DRBD Packages

DRBD is not included in the standard RHEL 7 repositories and must be installed from the Extra Packages for Enterprise Linux (EPEL) repository. Run the following on both nodes:

sudo yum install -y epel-release
sudo yum install -y drbd90-utils kmod-drbd90

The kmod-drbd90 package provides the kernel module for the DRBD 9.x series. Verify the module loads correctly:

sudo modprobe drbd
lsmod | grep drbd

If the module loads without errors, you will see a line such as:

drbd                  405504  0

Ensure DRBD starts on boot:

sudo systemctl enable drbd

Step 2: Configure /etc/hosts for Node Resolution

Both nodes must be able to resolve each other by hostname. Add entries to /etc/hosts on both nodes if DNS is not available:

sudo vi /etc/hosts

Add:

192.168.1.101  node1
192.168.1.102  node2

Test resolution from each node:

ping -c 2 node2   # from node1
ping -c 2 node1   # from node2

Step 3: Configure the Global DRBD Settings

The global configuration file /etc/drbd.d/global_common.conf defines DRBD-wide defaults. Edit it on both nodes:

sudo vi /etc/drbd.d/global_common.conf

A recommended baseline configuration:

global {
    usage-count no;
}

common {
    net {
        protocol C;
    }
    syncer {
        rate 100M;
    }
    handlers {
        pri-on-incon-degr "/usr/lib/drbd/notify-pri-on-incon-degr.sh; /usr/lib/drbd/notify-emergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f";
        pri-lost-after-sb "/usr/lib/drbd/notify-pri-lost-after-sb.sh; /usr/lib/drbd/notify-emergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f";
        local-io-error "/usr/lib/drbd/notify-io-error.sh; /usr/lib/drbd/notify-emergency-shutdown.sh; echo o > /proc/sysrq-trigger ; halt -f";
    }
}

protocol C means synchronous replication: a write is only acknowledged to the application after it has been confirmed written on both nodes, ensuring zero data loss.

Step 4: Create the Resource Configuration File

Each replicated disk is called a DRBD resource. Create a resource configuration file on both nodes:

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

Add the following, substituting your actual hostnames and IP addresses:

resource mydata {
    protocol C;

    on node1 {
        device    /dev/drbd0;
        disk      /dev/sdb;
        address   192.168.1.101:7789;
        meta-disk internal;
    }

    on node2 {
        device    /dev/drbd0;
        disk      /dev/sdb;
        address   192.168.1.102:7789;
        meta-disk internal;
    }
}

device /dev/drbd0 is the DRBD virtual block device. disk /dev/sdb is the underlying raw disk. meta-disk internal stores DRBD metadata at the end of the same disk rather than on a separate device.

Step 5: Initialize DRBD Metadata

Before DRBD can use the disk, it must write its metadata. Run drbdadm create-md on both nodes:

sudo drbdadm create-md mydata

When prompted, type yes to confirm. You will see output confirming that the metadata was written:

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

Step 6: Bring the Resource Up

Activate the resource on both nodes:

sudo drbdadm up mydata

Check the status — at this point both nodes will show Secondary/Secondary and the disk state will be Inconsistent because initial synchronization has not yet started:

sudo drbdadm status mydata

Step 7: Perform the Initial Synchronization

Designate node1 as the initial primary and force synchronization. Run this on node1 only:

sudo drbdadm primary --force mydata

DRBD will begin overwriting node2’s disk with node1’s data. Monitor synchronization progress:

watch -n 1 "cat /proc/drbd"

You will see a line like:

0: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r-----
    [===>................] sync'ed: 21.4% (16028/20476)M
    finish: 0:02:34 speed: 105,604 (99,940) K/sec

Wait until the sync completes and the disk state on both sides reads UpToDate/UpToDate.

Step 8: Create a Filesystem and Mount

Once synchronization is complete, create a filesystem on the DRBD device from node1 (the current primary):

sudo mkfs.xfs /dev/drbd0

Mount and use it:

sudo mkdir -p /mnt/drbddata
sudo mount /dev/drbd0 /mnt/drbddata
df -h /mnt/drbddata

Write a test file to confirm everything is working:

echo "DRBD test" | sudo tee /mnt/drbddata/testfile.txt

Step 9: Check Status with drbdadm status

The drbdadm status command gives a clean summary of the resource state:

sudo drbdadm status mydata

Healthy output on node1 looks like:

mydata role:Primary
  disk:UpToDate
  node2 role:Secondary
    replication:Established proto:C
    disk:UpToDate

Step 10: Failover Procedure

To fail over to node2 (simulate node1 going down or perform a planned migration):

On node1, unmount and demote to Secondary:

sudo umount /mnt/drbddata
sudo drbdadm secondary mydata

On node2, promote to Primary and mount:

sudo drbdadm primary mydata
sudo mkdir -p /mnt/drbddata
sudo mount /dev/drbd0 /mnt/drbddata
ls /mnt/drbddata

You will see the test file created on node1, confirming that all data was replicated successfully.

To fail back to node1, reverse the process: demote node2, promote node1, and mount on node1.

Firewall Configuration

Ensure the DRBD port is open between both nodes:

sudo firewall-cmd --permanent --add-port=7789/tcp
sudo firewall-cmd --reload

Conclusion

DRBD on RHEL 7 delivers synchronous block-level replication that forms the foundation of a high-availability storage architecture. You have installed DRBD from EPEL, configured the global settings and a named resource, initialized the metadata on both nodes, performed the initial disk synchronization, and practiced the failover procedure. When combined with Pacemaker and Corosync, DRBD enables fully automated failover where the cluster manager handles demotion, promotion, and mount operations in response to node failures. The result is a resilient, shared-nothing storage solution with no single point of failure for your most critical data.