kotovalexarian-likes-gitlab/gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity
gitlab-org--gitlab-foss/doc/administration/high_availability
History
Stan Hu e73760f52f Fix sample fstab file in GitLab HA docs 
The nobootwait option is no longer a valid option in Ubuntu 16.04.
Use nofail instead:

https://askubuntu.com/questions/786928/ubuntu-16-04-fstab-fails-with-nobootwait
2018-02-07 17:05:09 -08:00
..
database.md Add instructions for enabling the pg_trgm extension in the production db. As a workaround to [a fault during HA setup](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/2501). 2017-07-24 16:20:49 +00:00
gitlab.md Fix sample fstab file in GitLab HA docs 2018-02-07 17:05:09 -08:00
load_balancer.md Merge branch 'patch-20' into 'master' 2017-05-02 13:56:32 +00:00
nfs.md Recommend against the use of EFS 2018-01-11 11:42:49 -05:00
README.md Docs: Update admin docs 2017-12-13 15:22:02 +00:00
redis.md doc: Spelling fixes 2018-01-19 12:09:59 +02:00
redis_source.md Support multiple Redis instances based on queue type 2017-07-11 03:35:47 +00: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.

GitLab provides a service that is usually essential to most organizations: it enables people to collaborate on code in a timely fashion. Any downtime should therefore be short and planned. Luckily, GitLab provides a solid setup even on a single server without special measures. Due to the distributed nature of Git, developers can still commit code locally even when GitLab is not available. However, some GitLab features such as the issue tracker and Continuous Integration are not available when GitLab is down.

Keep in mind that all Highly Available solutions come with a trade-off between cost/complexity and uptime. The more uptime you want, the more complex the solution. And the more complex the solution, the more work is involved in setting up and maintaining it. High availability is not free and every HA solution should balance the costs against the benefits.

Architecture

There are two kinds of setups:

  • active/active
  • active/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.

Follow the steps below to configure an active/active setup:

  1. Configure the database
  2. Configure Redis
  3. Configure Redis for GitLab source installations
  4. Configure NFS
  5. Configure the GitLab application servers
  6. Configure the load balancers

Active/Active HA Diagram

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.

Note: GitLab recommends against choosing this HA method because of the complexity of managing DRBD and crafting automatic failover. This is compatible with GitLab, but not officially supported. If you are an EE customer, support will help you with GitLab related problems, but if the root cause is identified as DRBD, we will not troubleshoot further.

Components/Servers Required: 2 servers/virtual machines (one active/one passive)

Active/Passive HA Diagram