Commit b7aae9a6 authored by Achilleas Pipinellis's avatar Achilleas Pipinellis

Merge branch 'doc/sentinel' into 'master'

Improved redis sentinel documentation

## What does this MR do?
Updates Redis Sentinel documentation (most Omnibus stuff).

## Are there points in the code the reviewer needs to double check?
Grammar / Documentation

## Why was this MR needed?
After this https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/1000 get merged, people will need to follow new instructions.

## Checklist

- Documentation follows Sentinel best-practices:
  - [x] Suggests amount of sentinel nodes
  - [x] Suggests amount of redis nodes
  - [x] Suggests quorum value according to recomended amount of sentinel nodes
  - [x] Describes how to define quorum according to best-practices
  - [x] Lists ports and firewall checklist
- [x] Following Documentation bring us to a working environment
- [ ] Documentation is clear and have no gramatical issue

## What are the relevant issue numbers?

gitlab-org/omnibus-gitlab#1565

See merge request !6471
parents cfcf5460 d5dc44f0
...@@ -7,19 +7,10 @@ highly available. ...@@ -7,19 +7,10 @@ highly available.
## Architecture ## Architecture
### Active/Passive There are two kinds of setups:
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: - active/active
- active/passive
- 2 servers/virtual machines (one active/one passive)
![Active/Passive HA Diagram](../img/high_availability/active-passive-diagram.png)
### Active/Active ### Active/Active
...@@ -28,12 +19,24 @@ user requests simultaneously. The database, Redis, and GitLab application are ...@@ -28,12 +19,24 @@ user requests simultaneously. The database, Redis, and GitLab application are
all deployed on separate servers. The configuration is **only** highly-available all deployed on separate servers. The configuration is **only** highly-available
if the database, Redis and storage are also configured as such. if the database, Redis and storage are also configured as such.
![Active/Active HA Diagram](../img/high_availability/active-active-diagram.png) Follow the steps below to configure an active/active setup:
**Steps to configure active/active:**
1. [Configure the database](database.md) 1. [Configure the database](database.md)
1. [Configure Redis](redis.md) 1. [Configure Redis](redis.md)
1. [Configure NFS](nfs.md) 1. [Configure NFS](nfs.md)
1. [Configure the GitLab application servers](gitlab.md) 1. [Configure the GitLab application servers](gitlab.md)
1. [Configure the load balancers](load_balancer.md) 1. [Configure the load balancers](load_balancer.md)
![Active/Active HA Diagram](../img/high_availability/active-active-diagram.png)
### 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/Passive HA Diagram](../img/high_availability/active-passive-diagram.png)
This diff is collapsed.
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment