History

Sean McGivern 3939d4dfbf Fix secret names in HA docs		2016-10-13 09:58:06 +01:00
..
README.md	Add new HA diagrams [ci skip]	2016-05-25 11:35:00 -05:00
database.md	New HA docs [ci skip]	2016-04-22 13:18:06 -05:00
gitlab.md	Fix secret names in HA docs	2016-10-13 09:58:06 +01:00
load_balancer.md	Change all occurrences of doc.gitlab.com to docs.gitlab.com	2016-05-13 16:26:56 -05:00
nfs.md	Explicitly mention advisory file locking	2016-06-01 14:46:07 -05:00
redis.md	Small refactor and a few documentation fixes	2016-08-04 19:02:39 +02:00

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: