GitLab is an open DevOps platform used by many companies and organizations both small and large. While GitLab has a cloud based SaaS offering, it is often deployed and hosted on-premise using self-managed GitLab instances.
Let us focus on a simple, yet common GitLab deployment scenario. Consider a small to mid-market sized business with approximately 100 GitLab users. GitLab’s own installation documentation recommends a single machine installation for under 2,000 users:
For GitLab instances with less than 2,000 users, it’s recommended that you use the default setup by installing GitLab on a single machine to minimize maintenance and resource costs.
A single machine deployment is both simple and straight forward with reduced maintenance and resources required for operation.
GitLab is comprised of much more than just a simple web application. Omnibus GitLab bundles all required services and tools needed to run and manage a GitLab instance easily. Conceptually, think of GitLab running as a typical single service with systemd for process management. Behind the scenes however, many processes such as NGINX, PostgreSQL, Redis, and many more are actively running.
Currently we have one machine (one node) and one service, GitLab. With a slight increase in complexity (and twice the system resources), we can turn a single machine deployment into a highly available (HA) GitLab Cluster.
Let’s put it all together:
Pacemaker is a high availability cluster resource management platform. Pacemaker will be responsible for managing GitLab, it’s data, and all required resources such as mounted filesystems and virtual IP addresses.
DRBD® is a software-based, shared-nothing, replicated storage solution mirroring the content of block devices. Here we will be using DRBD to replicate a mounted filesystem containing GitLab’s data such as a PostgreSQL database and any git repositories.
GitLab will be managed by Pacemaker as a resource. It can only run as a single instance on one node at a time. If there is a system failure, GitLab can immediately failover to an available node.
Building a GitLab cluster managed by Pacemaker while leveraging DRBD as the backing storage device is a simple solution for achieving high availability and increasing the uptime of your GitLab environment in the event of a system failure.
If you’re interested in making your GitLab instance highly available, please have a look at our HA GitLab Using DRBD and Pacemaker tech guide. This guide will walk you through configuring a highly available GitLab Community Edition environment.
While Pacemaker and DRBD are widely used open source tools often used together to create a vast array of HA software stack configurations, there are other HA and disaster recovery (DR) solutions available from GitLab.
For example, GitLab supports multiple application nodes for scaling as well as replicating entire instances using GitLab Geo. These solutions are beyond the scope of this blog post and accompanying tech guide.
Share this post
LINBIT is committed to protecting and respecting your privacy, and we’ll only use your personal information to administer your account and to provide the products and services you requested from us. From time to time, we would like to contact you about our products and services, as well as other content that may be of interest to you. If you consent to us contacting you for this purpose, please tick above to say how you would like us to contact you.
By clicking submit below, you consent to allow LINBIT to store and process the personal information submitted above to provide you the content requested.
Tune into the Red Hat X Tech Talk: Philipp Reisner, our CEO, joined them recently to talk about the business similarities between LINBIT and Red Hat and respective offerings:
Red Hat X Tech Talk: LINBIT SDS and OpenShift – Red Hat X Podcast Series
LINBIT SDS is a software-defined storage, that perfectly fits with Red Hat's OpenShift. It provides persistent volumes…