History

Praveen Arimbrathodiyil dbe389e2f0 New upstream version 8.13.3+dfsg1		2016-11-03 12:29:30 +05:30
..
database.md	Imported Upstream version 8.8.2+dfsg	2016-06-02 11:05:42 +05:30
gitlab.md	New upstream version 8.13.3+dfsg1	2016-11-03 12:29:30 +05:30
load_balancer.md	Imported Upstream version 8.8.2+dfsg	2016-06-02 11:05:42 +05:30
nfs.md	Imported Upstream version 8.9.0+debian~rc4	2016-06-16 23:09:34 +05:30
README.md	Imported Upstream version 8.9.0+debian~rc4	2016-06-16 23:09:34 +05:30
redis.md	New upstream version 8.11.3+dfsg	2016-09-13 17:45:13 +05:30

README.md

High Availability

GitLab supports several different types of clustering and high-availability. The solution you choose will be based on the level of scalability and availability you require. The easiest solutions are scalable, but not necessarily highly available.

Architecture

Active/Passive

For pure high-availability/failover with no scaling you can use an active/passive configuration. This utilizes DRBD (Distributed Replicated Block Device) to keep all data in sync. DRBD requires a low latency link to remain in sync. It is not advisable to attempt to run DRBD between data centers or in different cloud availability zones.

Components/Servers Required:

2 servers/virtual machines (one active/one passive)

Active/Active

This architecture scales easily because all application servers handle user requests simultaneously. The database, Redis, and GitLab application are all deployed on separate servers. The configuration is only highly-available if the database, Redis and storage are also configured as such.

Steps to configure active/active: