Operations 8 min read

GitLab High Availability Solution with DRBD

This guide details a step‑by‑step setup of a highly available GitLab service using two virtual machines, DRBD for block‑level replication, configuration of GitLab and PostgreSQL directories, DRBD resource creation, service start‑up, and manual primary‑secondary failover procedures.

DevOps Cloud Academy
DevOps Cloud Academy
DevOps Cloud Academy
GitLab High Availability Solution with DRBD

GitLab High Availability with DRBD

Two GitLab instances are deployed on separate virtual machines and their data is kept synchronized via DRBD block replication.

Host Planning

192.168.1.104 gitlab-service-01 primary
192.168.1.105 gitlab-service-02 secondary

GitLab Installation

GitLab CE is installed from the Tsinghua mirror and configured via /etc/gitlab/gitlab.rb , then reconfigured.

rpm -ivh gitlab-ce*.rpm
vim /etc/gitlab/gitlab.rb  # extend_url
gitlab-ctl reconfigure

DRBD Installation and Configuration

DRBD packages are installed, SELinux is set to permissive, and the kernel module is loaded.

rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-2.el7.elrepo.noarch.rpm
yum -y install drbd84
yum -y install kmod-drbd84
setenforce 0
modprobe drbd

Identical disks are prepared on each node, then a global DRBD configuration and a resource definition for the GitLab data device are created.

global {
    usage-count no;
}
common {
    protocol C;
    startup {
        wfc-timeout 15;
        degr-wfc-timeout 15;
        outdated-wfc-timeout 15;
    }
    disk {
        on-io-error detach;
        fencing resource-only;
    }
    net {
        cram-hmac-alg sha1;
        shared-secret "123456";
    }
    syncer {
        rate 100M;
    }
}
resource gitlab {
    meta-disk internal;
    device /dev/drbd1;
    on gitlab-service-01 {
        address 192.168.1.104:7779;
        disk /dev/sdb1;
    }
    on gitlab-service-02 {
        address 192.168.1.105:7779;
        disk /dev/sdb1;
    }
}

Metadata is created with drbdadm create-md gitlab , the DRBD service is started and enabled, and the replication status is verified via cat /proc/drbd .

Primary/Secondary Switch

On the primary node a test file is created after formatting and mounting the DRBD device.

drbdadm primary gitlab
mkfs.xfs /dev/drbd1 -f
mkdir /data
mount /dev/drbd1 /data
echo "123" > /data/123.txt

Failover is performed by demoting node 01 to secondary, promoting node 02 to primary, mounting the DRBD device, and confirming the test file.

# Node 01
umount /data
drbdadm secondary gitlab

# Node 02
drbdadm primary gitlab
mkdir /data
mount /dev/drbd1 /data
cat /data/123.txt

GitLab Data Migration

GitLab’s repository and PostgreSQL directories are redirected to the DRBD‑mounted path, the service is stopped, data is synchronized with rsync , the original directories are removed, and GitLab is started again.

# Stop GitLab
gitlab-ctl stop

# Mount DRBD
mount /dev/drbd1 /data

# Sync data
rsync -av /var/opt/gitlab/git-data /data/git-data
rsync -av /var/opt/gitlab/postgresql /data/postgresql

# Clean old data
rm -fr /var/opt/gitlab/*

# Start GitLab
gitlab-ctl start

The same configuration changes are applied to the secondary node, and manual failover can be performed by unmounting, switching DRBD roles, and restarting GitLab.

Operationshigh availabilityGitLabLinuxDRBD
DevOps Cloud Academy
Written by

DevOps Cloud Academy

Exploring industry DevOps practices and technical expertise.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.