Geo High Availability

This document describes a minimal reference architecture for running Geo in a high availability configuration. If your HA setup differs from the one described, it is possible to adapt these instructions to your needs.

Architecture overview

Geo HA Diagram

diagram source - gitlab employees only

The topology above assumes that the primary and secondary Geo clusters are located in two separate locations, on their own virtual network with private IP addresses. The network is configured such that all machines within one geographic location can communicate with each other using their private IP addresses. The IP addresses given are examples and may be different depending on the network topology of your deployment.

The only external way to access the two Geo deployments is by HTTPS at gitlab.us.example.com and gitlab.eu.example.com in the example above.

Note: The primary and secondary Geo deployments must be able to communicate to each other over HTTPS.

Redis and PostgreSQL High Availability

The primary and secondary Redis and PostgreSQL should be configured for high availability. Because of the additional complexity involved in setting up this configuration for PostgreSQL and Redis it is not covered by this Geo HA documentation.

For more information about setting up a highly available PostgreSQL cluster and Redis cluster using the omnibus package see the high availability documentation for PostgreSQL and Redis, respectively.

Note: It is possible to use cloud hosted services for PostgreSQL and Redis but this is beyond the scope of this document.

Prerequisites: A working GitLab HA cluster

This cluster will serve as the primary node. Use the GitLab HA documentation to set this up.

Configure the GitLab cluster to be the primary node

The following steps enable a GitLab cluster to serve as the primary node.

Step 1: Configure the primary frontend servers

  1. Edit /etc/gitlab/gitlab.rb and add the following:

     ##
 ## Enable the Geo primary role
 ##
 roles ['geo_primary_role']

 ##
 ## Disable automatic migrations
 ##
 gitlab_rails['auto_migrate'] = false

After making these changes, reconfigure GitLab so the changes take effect.

Note: PostgreSQL and Redis should have already been disabled on the application servers, and connections from the application servers to those services on the backend servers configured, during normal GitLab HA set up. See high availability configuration documentation for PostgreSQL and Redis.

The primary database will require modification later, as part of step 2.

Configure a secondary node

A secondary cluster is similar to any other GitLab HA cluster, with two major differences:

  • The main PostgreSQL database is a read-only replica of the primary node’s PostgreSQL database.
  • There is also a single PostgreSQL database for the secondary cluster, called the “tracking database”, which tracks the synchronization state of various resources.

Therefore, we will set up the HA components one-by-one, and include deviations from the normal HA setup.

Step 1: Configure the Redis and NFS services on the secondary node

Configure the following services, again using the non-Geo high availability documentation:

Step 2: Configure the main read-only replica PostgreSQL database on the secondary node

Note: The following documentation assumes the database will be run on only a single machine, rather than as a PostgreSQL cluster.

Configure the secondary database as a read-only replica of the primary database. Be sure to follow the External PostgreSQL instances section.

Step 3: Configure the tracking database on the secondary node

Note: This documentation assumes the tracking database will be run on only a single machine, rather than as a PostgreSQL cluster.

Configure the tracking database.

Step 4: Configure the frontend application servers on the secondary node

In the architecture overview, there are two machines running the GitLab application services. These services are enabled selectively in the configuration.

Configure the application servers following Configuring GitLab for HA, then make the following modifications:

  1. Edit /etc/gitlab/gitlab.rb on each application server in the secondary cluster, and add the following:

     ##
 ## Enable the Geo secondary role
 ##
 roles ['geo_secondary_role', 'application_role']

 ##
 ## Disable automatic migrations
 ##
 gitlab_rails['auto_migrate'] = false

 ##
 ## Configure the connection to the tracking DB. And disable application
 ## servers from running tracking databases.
 ##
 geo_secondary['db_host'] = '10.1.4.1'
 geo_secondary['db_password'] = 'plaintext Geo tracking DB password'
 geo_postgresql['enable'] = false

 ##
 ## Configure connection to the streaming replica database, if you haven't
 ## already
 ##
 gitlab_rails['db_host'] = '10.1.3.1'
 gitlab_rails['db_password'] = 'plaintext DB password'

 ##
 ## Configure connection to Redis, if you haven't already
 ##
 gitlab_rails['redis_host'] = '10.1.2.1'
 gitlab_rails['redis_password'] = 'Redis password'

 ##
 ## If you are using custom users not managed by Omnibus, you need to specify
 ## UIDs and GIDs like below, and ensure they match between servers in a
 ## cluster to avoid permissions issues
 ##
 user['uid'] = 9000
 user['gid'] = 9000
 web_server['uid'] = 9001
 web_server['gid'] = 9001
 registry['uid'] = 9002
 registry['gid'] = 9002
Note: If you had set up PostgreSQL cluster using the omnibus package and you had set up postgresql['sql_user_password'] = 'md5 digest of secret' setting, keep in mind that gitlab_rails['db_password'] and geo_secondary['db_password'] mentioned above contains the plaintext passwords. This is used to let the Rails servers connect to the databases.
Note: Make sure that current node IP is listed in postgresql['md5_auth_cidr_addresses'] setting of your remote database.

After making these changes Reconfigure GitLab so the changes take effect.

On the secondary the following GitLab frontend services will be enabled:

  • geo-logcursor
  • gitlab-pages
  • gitlab-workhorse
  • logrotate
  • nginx
  • registry
  • remote-syslog
  • sidekiq
  • unicorn

Verify these services by running sudo gitlab-ctl status on the frontend application servers.

Step 5: Set up the LoadBalancer for the secondary node

In this topology, a load balancer is required at each geographic location to route traffic to the application servers.

See Load Balancer for GitLab HA for more information.