From c76ff8cf32801198e93122fdcf689f3ac1987e41 Mon Sep 17 00:00:00 2001 From: Gabriel Mazetto Date: Thu, 22 Sep 2016 06:05:28 -0300 Subject: Improved redis sentinel documentation for CE --- doc/administration/high_availability/redis.md | 62 +++++++++++---------------- 1 file changed, 26 insertions(+), 36 deletions(-) (limited to 'doc/administration') diff --git a/doc/administration/high_availability/redis.md b/doc/administration/high_availability/redis.md index bc424330656..e347959ebbc 100644 --- a/doc/administration/high_availability/redis.md +++ b/doc/administration/high_availability/redis.md @@ -143,6 +143,7 @@ the master, and `masterauth` in slaves. redis['port'] = 6379 ## Slave redis instance + redis['master'] = false redis['master_ip'] = '10.10.10.10' # IP of master Redis server redis['master_port'] = 6379 # Port of master Redis server redis['master_password'] = "" @@ -157,31 +158,19 @@ servers. ### Sentinel setup -We don't provide yet an automated way to setup and run the Sentinel daemon -from Omnibus installation method. You must follow the instructions below and -run it by yourself. +We provide an automated way to setup and run the Sentinel daemon +with GitLab EE. -The support for Sentinel in Ruby has some [caveats](https://github.com/redis/redis-rb/issues/531). -While you can give any name for the `master-group-name` part of the -configuration, as in this example: - -```conf -sentinel monitor -``` - -,for it to work in Ruby, you have to use the "hostname" of the master Redis -server, otherwise you will get an error message like: -`Redis::CannotConnectError: No sentinels available.`. Read -[Sentinel troubleshooting](#sentinel-troubleshooting) for more information. +See the instructions below how to setup it by yourself. Here is an example configuration file (`sentinel.conf`) for a Sentinel node: ```conf port 26379 -sentinel monitor master-redis.example.com 10.10.10.10 6379 1 -sentinel down-after-milliseconds master-redis.example.com 10000 -sentinel config-epoch master-redis.example.com 0 -sentinel leader-epoch master-redis.example.com 0 +sentinel monitor gitlab-redis 10.0.0.1 6379 1 +sentinel down-after-milliseconds gitlab-redis 10000 +sentinel config-epoch gitlab-redis 0 +sentinel leader-epoch gitlab-redis 0 ``` --- @@ -213,10 +202,11 @@ The following steps should be performed in the [GitLab application server](gitla 1. Edit `/etc/gitlab/gitlab.rb` and add/change the following lines: ```ruby - gitlab-rails['redis_host'] = "master-redis.example.com" - gitlab-rails['redis_port'] = 6379 - gitlab-rails['redis_password'] = '' - gitlab-rails['redis_sentinels'] = [ + redis['master_name'] = "gitlab-redis" + redis['master_ip'] = "10.0.0.1" + redis['master_port'] = 6379 + redis['master_password'] = '' + gitlab_rails['redis_sentinels'] = [ {'host' => '10.10.10.1', 'port' => 26379}, {'host' => '10.10.10.2', 'port' => 26379}, {'host' => '10.10.10.3', 'port' => 26379} @@ -229,33 +219,33 @@ The following steps should be performed in the [GitLab application server](gitla If you get an error like: `Redis::CannotConnectError: No sentinels available.`, there may be something wrong with your configuration files or it can be related -to [this issue][gh-531] ([pull request][gh-534] that should make things better). +to [this issue][gh-531]. -It's a bit rigid the way you have to config `resque.yml` and `sentinel.conf`, -otherwise `redis-rb` will not work properly. +It's a bit non-intuitive the way you have to config `resque.yml` and +`sentinel.conf`, otherwise `redis-rb` will not work properly. -The hostname ('my-primary-redis') of the primary Redis server (`sentinel.conf`) -**must** match the one configured in GitLab (`resque.yml` for source installations -or `gitlab-rails['redis_*']` in Omnibus) and it must be valid ex: +The `master-group-name` ('gitlab-redis') defined in (`sentinel.conf`) +**must** be used as the hostname in GitLab (`resque.yml` for source installations +or `gitlab-rails['redis_*']` in Omnibus): ```conf # sentinel.conf: -sentinel monitor my-primary-redis 10.10.10.10 6379 1 -sentinel down-after-milliseconds my-primary-redis 10000 -sentinel config-epoch my-primary-redis 0 -sentinel leader-epoch my-primary-redis 0 +sentinel monitor gitlab-redis 10.10.10.10 6379 1 +sentinel down-after-milliseconds gitlab-redis 10000 +sentinel config-epoch gitlab-redis 0 +sentinel leader-epoch gitlab-redis 0 ``` ```yaml # resque.yaml production: - url: redis://my-primary-redis:6378 + url: redis://:myredispassword@gitlab-redis/ sentinels: - - host: slave1 + host: slave1.example.com # or use ip port: 26380 # point to sentinel, not to redis port - - host: slave2 + host: slave2.exampl.com # or use ip port: 26381 # point to sentinel, not to redis port ``` -- cgit v1.2.3 From f6d29583b02ffbb35b3c344f78b5a3575bf9c656 Mon Sep 17 00:00:00 2001 From: Gabriel Mazetto Date: Fri, 7 Oct 2016 01:16:32 +0200 Subject: Small fixes on Sentinel documentation for CE --- doc/administration/high_availability/redis.md | 2 -- 1 file changed, 2 deletions(-) (limited to 'doc/administration') diff --git a/doc/administration/high_availability/redis.md b/doc/administration/high_availability/redis.md index e347959ebbc..69184ae9723 100644 --- a/doc/administration/high_availability/redis.md +++ b/doc/administration/high_availability/redis.md @@ -203,8 +203,6 @@ The following steps should be performed in the [GitLab application server](gitla ```ruby redis['master_name'] = "gitlab-redis" - redis['master_ip'] = "10.0.0.1" - redis['master_port'] = 6379 redis['master_password'] = '' gitlab_rails['redis_sentinels'] = [ {'host' => '10.10.10.1', 'port' => 26379}, -- cgit v1.2.3 From f54d60b41df3d30181a371d3799fa8b9451d4c5b Mon Sep 17 00:00:00 2001 From: Gabriel Mazetto Date: Fri, 7 Oct 2016 01:47:22 +0200 Subject: Updated password examples and improved omnibus troubleshooting --- doc/administration/high_availability/redis.md | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-) (limited to 'doc/administration') diff --git a/doc/administration/high_availability/redis.md b/doc/administration/high_availability/redis.md index 69184ae9723..9fca7bfb8b4 100644 --- a/doc/administration/high_availability/redis.md +++ b/doc/administration/high_availability/redis.md @@ -45,7 +45,7 @@ Redis. redis['bind'] = '0.0.0.0' # If you wish to use Redis authentication (recommended) - redis['password'] = 'Redis Password' + redis['password'] = 'redis-password-goes-here' ``` 1. Run `sudo gitlab-ctl reconfigure` to install and configure PostgreSQL. @@ -132,7 +132,7 @@ the master, and `masterauth` in slaves. redis['port'] = 6379 ## Master redis instance - redis['password'] = '' + redis['password'] = 'redis-password-goes-here' ``` 1. Edit `/etc/gitlab/gitlab.rb` of a slave Redis machine (should be one or more machines): @@ -146,7 +146,7 @@ the master, and `masterauth` in slaves. redis['master'] = false redis['master_ip'] = '10.10.10.10' # IP of master Redis server redis['master_port'] = 6379 # Port of master Redis server - redis['master_password'] = "" + redis['master_password'] = "redis-password-goes-here" ``` 1. Reconfigure the GitLab for the changes to take effect: `sudo gitlab-ctl reconfigure` @@ -203,7 +203,7 @@ The following steps should be performed in the [GitLab application server](gitla ```ruby redis['master_name'] = "gitlab-redis" - redis['master_password'] = '' + redis['master_password'] = 'redis-password-goes-here' gitlab_rails['redis_sentinels'] = [ {'host' => '10.10.10.1', 'port' => 26379}, {'host' => '10.10.10.2', 'port' => 26379}, @@ -215,6 +215,21 @@ The following steps should be performed in the [GitLab application server](gitla ### Sentinel troubleshooting +#### Omnibus install + +If you get an error like: `Redis::CannotConnectError: No sentinels available.`, +there may be something wrong with your configuration files or it can be related +to [this issue][gh-531]. + +You must make sure you are defining the same value in `redis['master_name']` +and `redis['master_pasword']` as you defined for your sentinel node. + +The way the redis connector `redis-rb` works with sentinel is a bit +non-intuitive. We try to hide the complexity in omnibus, but it still requires +a few extra configs. + +#### Source install + If you get an error like: `Redis::CannotConnectError: No sentinels available.`, there may be something wrong with your configuration files or it can be related to [this issue][gh-531]. -- cgit v1.2.3 From c4d3c0de1f489639e1e2f1a12b7b4d88384d3e06 Mon Sep 17 00:00:00 2001 From: Gabriel Mazetto Date: Sat, 15 Oct 2016 05:40:15 +0200 Subject: Improved documentation on HA sentinel part and Redis replication troubleshooting. --- doc/administration/high_availability/redis.md | 316 +++++++++++++++++++++----- 1 file changed, 256 insertions(+), 60 deletions(-) (limited to 'doc/administration') diff --git a/doc/administration/high_availability/redis.md b/doc/administration/high_availability/redis.md index 9fca7bfb8b4..840f5896bd7 100644 --- a/doc/administration/high_availability/redis.md +++ b/doc/administration/high_availability/redis.md @@ -8,6 +8,27 @@ that comes bundled with GitLab Omnibus packages. information. We recommend using a combination of a Redis password and tight firewall rules to secure your Redis service. + + +**Table of Contents** + +- [Configure your own Redis server](#configure-your-own-redis-server) +- [Configure Redis using Omnibus](#configure-redis-using-omnibus) +- [Experimental Redis Sentinel support](#experimental-redis-sentinel-support) + - [Redis setup](#redis-setup) + - [Source install](#source-install) + - [Omnibus Install](#omnibus-install) + - [Troubleshooting Replication](#troubleshooting-replication) + - [Sentinel](#sentinel) + - [Sentinel setup (Community Edition)](#sentinel-setup-community-edition) + - [Sentinel setup (EE Only)](#sentinel-setup-ee-only) + - [GitLab setup](#gitlab-setup) + - [Sentinel troubleshooting](#sentinel-troubleshooting) + - [Omnibus install](#omnibus-install) + - [Source install](#source-install-1) + + + ## Configure your own Redis server If you're hosting GitLab on a cloud provider, you can optionally use a @@ -37,6 +58,7 @@ Redis. unicorn['enable'] = false sidekiq['enable'] = false postgresql['enable'] = false + gitlab_rails['enable'] = false gitlab_workhorse['enable'] = false mailroom['enable'] = false @@ -59,120 +81,294 @@ Redis. ## Experimental Redis Sentinel support -> [Introduced][ce-1877] in GitLab 8.11. +> [Introduced][ce-1877] in GitLab 8.11, improved in 8.13. Since GitLab 8.11, you can configure a list of Redis Sentinel servers that will monitor a group of Redis servers to provide you with a standard failover support. -There is currently one exception to the Sentinel support: `mail_room`, the -component that processes incoming emails. It doesn't support Sentinel yet, but -we hope to integrate a future release that does support it. - To get a better understanding on how to correctly setup Sentinel, please read the [Redis Sentinel documentation](http://redis.io/topics/sentinel) first, as failing to configure it correctly can lead to data loss. +Redis Sentinel can handle the most important tasks in a HA environment to help +keep servers online with minimal to no downtime: + +- Monitors master and slave instances to see if they are available +- Promote a slave to master when the master fails. +- Demote a master to slave when failed master comes back online (to prevent + data-partitioning). +- Can be queried by clients to always connect to the correct master server. + +There is currently one exception to the Sentinel support: `mail_room`, the +component that processes incoming emails. It doesn't support Sentinel yet, but +we hope to integrate a future release that does support it soon. + The configuration consists of three parts: -- Redis setup -- Sentinel setup -- GitLab setup +- Setup Redis Master and Slave nodes +- Setup Sentinel nodes +- Setup GitLab + +> **IMPORTANT**: You need at least 3 independent machines: physical, or VMs +running into distinct physical machines. If you fail to provision the +machines in that specific way, any issue with the shared environment can +bring your entire setup down. Read carefully how to configure those components below. ### Redis setup -You must have at least 2 Redis servers: 1 Master, 1 or more Slaves. +You must have at least `3` Redis servers: `1` Master, `2` Slaves, and they need to +be each in a independent machine (see explanation above). + They should be configured the same way and with similar server specs, as -in a failover situation, any Slave can be elected as the new Master by +in a failover situation, any `Slave` can be elected as the new `Master` by the Sentinel servers. -In a minimal setup, the only required change for the slaves in `redis.conf` -is the addition of a `slaveof` line pointing to the initial master. -You can increase the security by defining a `requirepass` configuration in -the master, and `masterauth` in slaves. +With Sentinel, you must define a password to protect the access as both +Sentinel instances and other redis instances should be able to talk to +each other over the network. ---- +You'll need to define both `requirepass` and `masterauth` in all +nodes because they can be re-configured at any time by the Sentinels +during a failover, and change it's status as `Master` or `Slave`. -**Configuring your own Redis server** +Initial `Slave` nodes will have in `redis.conf` an additional `slaveof` line +pointing to the initial `Master`. -1. Add to the slaves' `redis.conf`: +#### Source install - ```conf - # IP and port of the master Redis server - slaveof 10.10.10.10 6379 - ``` +**Master Redis instance** -1. Optionally, set up password authentication for increased security. - Add the following to master's `redis.conf`: +You need to make the following changes in `redis.conf`: - ```conf - # Optional password authentication for increased security - requirepass "" - ``` +1. Define a `bind` address pointing to a local IP that your other machines + can reach you. If you really need to bind to an external acessible IP, make + sure you add extra firewall rules to prevent unauthorized access: -1. Then add this line to all the slave servers' `redis.conf`: + ```conf + # By default, if no "bind" configuration directive is specified, Redis listens + # for connections from all the network interfaces available on the server. + # It is possible to listen to just one or multiple selected interfaces using + # the "bind" configuration directive, followed by one or more IP addresses. + # + # Examples: + # + # bind 192.168.1.100 10.0.0.1 + # bind 127.0.0.1 ::1 + bind 0.0.0.0 # This will bind to all interfaces + ``` + +1. Define a `port` to force redis to listin on TCP so other machines can + connect to it: + + ```conf + # Accept connections on the specified port, default is 6379 (IANA #815344). + # If port 0 is specified Redis will not listen on a TCP socket. + port 6379 + ``` + +1. Set up password authentication (use the same password in all nodes) ```conf - masterauth "" + requirepass "redis-password-goes-here" + masterauth "redis-password-goes-here" ``` 1. Restart the Redis services for the changes to take effect. ---- +**Slave Redis instance** -**Using Redis via Omnibus** +1. Follow same instructions from master with the extra change in `redis.conf`: -1. Edit `/etc/gitlab/gitlab.rb` of a master Redis machine (usualy a single machine): + ```conf + # IP and port of the master Redis server + slaveof 10.10.10.10 6379 + ``` - ```ruby - ## Redis TCP support (will disable UNIX socket transport) - redis['bind'] = '0.0.0.0' # or specify an IP to bind to a single one - redis['port'] = 6379 +1. Restart the Redis services for the changes to take effect. - ## Master redis instance - redis['password'] = 'redis-password-goes-here' - ``` +#### Omnibus Install -1. Edit `/etc/gitlab/gitlab.rb` of a slave Redis machine (should be one or more machines): +You need to install the omnibus package in 3 different and independent machines. +We will elect one as the initial `Master` and the other 2 as `Slaves`. - ```ruby - ## Redis TCP support (will disable UNIX socket transport) - redis['bind'] = '0.0.0.0' # or specify an IP to bind to a single one - redis['port'] = 6379 +If you are migrating from a single machine install, you may want to setup the +machines as Slaves, pointing to the original machine as `Master`, to migrate +the data first, and than switch to this setup. - ## Slave redis instance - redis['master'] = false - redis['master_ip'] = '10.10.10.10' # IP of master Redis server - redis['master_port'] = 6379 # Port of master Redis server - redis['master_password'] = "redis-password-goes-here" - ``` +To disable redis in the single install, edit `/etc/gitlab/gitlab.rb`: + +```ruby +redis['enable'] = false +``` + +**Master Redis instances** + +You need to make the following changes in `/etc/gitlab/gitlab.rb`: + +1. Define a `redis['bind']` address pointing to a local IP that your other machines + can reach you. If you really need to bind to an external acessible IP, make + sure you add extra firewall rules to prevent unauthorized access. +1. Define a `redis['port']` to force redis to listin on TCP so other machines can + connect to it. +1. Set up password authentication with `redis['master_password']` (use the same + password in all nodes). -1. Reconfigure the GitLab for the changes to take effect: `sudo gitlab-ctl reconfigure` +```ruby +## Redis TCP support (will disable UNIX socket transport) +redis['bind'] = '0.0.0.0' # or specify an IP to bind to a single one +redis['port'] = 6379 +redis['requirepass'] = 'redis-password-goes-here' +redis['master_password'] = 'redis-password-goes-here' +``` + +Reconfigure GitLab Omnibus for the changes to take effect: `sudo gitlab-ctl reconfigure` + +**Slave Redis instances** + +You need to make the same changes listed for the `Master` instance, +with an additional `Slave` section as in the example below: + +```ruby +## Redis TCP support (will disable UNIX socket transport) +redis['bind'] = '0.0.0.0' # or specify an IP to bind to a single one +redis['port'] = 6379 +redis['requirepass'] = 'redis-password-goes-here' +redis['master_password'] = 'redis-password-goes-here' + +## Slave redis instance +redis['master'] = false +redis['master_ip'] = '10.10.10.10' # IP of master Redis server +redis['master_port'] = 6379 # Port of master Redis server +``` + +Reconfigure GitLab Omnibus for the changes to take effect: `sudo gitlab-ctl reconfigure` + +#### Troubleshooting Replication + +You can check if everything is correct by connecting to each server using +`redis-cli` application, and sending the `INFO` command. + +If authentication was correctly defined, it should fail with: +`NOAUTH Authentication required` error. Try to authenticate with the +previous defined password with `AUTH redis-password-goes-here` and +try the `INFO` command again. + +Look for the `# Replication` section where you should see some important +information like the `role` of the server. + +When connected to a `master` redis, you will see the number of connected +`slaves`, and a list of each with connection details. + +When it's a `slave`, you will see details of the master connection and if +its `up` or `down`. --- Now that the Redis servers are all set up, let's configure the Sentinel servers. -### Sentinel setup +If you are not sure if your Redis servers are working and replicating +correctly, please read the [Troubleshooting Replication](#troubleshooting-replication) +and fix it before proceeding with Sentinel setup. + +### Sentinel + +You must have at least `3` Redis Sentinel servers, and they need to +be each in a independent machine. You can install them in the same +machines you installed the other `3` Redis servers. + +This number is required for the consensus algorithm to be effective +in the case of a failure. You should always have and `odd` number +of Sentinel nodes provisioned. -We provide an automated way to setup and run the Sentinel daemon -with GitLab EE. +Here is a simple explanation on how Sentinel handles a failover: -See the instructions below how to setup it by yourself. +When a number of Sentinels (`quorum` value) agree the fact the `master` is +not reachable, the **majority** of the sentinels must elect a temporary +Sentinel `leader`, that will be responsible to start the failover proceedings. -Here is an example configuration file (`sentinel.conf`) for a Sentinel node: +As an example, for a cluster of `3` Sentinels, at least `2` must agree on a +`leader`. If you have total of `5` at least `3` must agree on the leader. + +The `quorum` is only used to detect failure, not to elect the `leader`. + +Official [Sentinel documentation](http://redis.io/topics/sentinel#example-sentinel-deployments) +also lists different network topologies and warns againts situations like +network partition and how it can affect the state of the HA solution. Make +sure you read it carefully and understand the implications in your current +setup. + +To make Sentinel setup easier, ee provide an [automated way to setup and run](#sentinel-setup-ee-only) +the Sentinel daemon with GitLab EE. + +#### Sentinel setup (Community Edition) + +For GitLab CE, you need to install, configure, execute and monitor Sentinel +by yourself. + +Here is an example configuration file (`sentinel.conf`) for a minimal Sentinel +node: ```conf -port 26379 -sentinel monitor gitlab-redis 10.0.0.1 6379 1 +bind 0.0.0.0 # bind to all interfaces or change to a specific IP +port 26379 # default sentinel port +sentinel auth-pass gitlab-redis redis-password-goes-here +sentinel monitor gitlab-redis 10.0.0.1 6379 2 sentinel down-after-milliseconds gitlab-redis 10000 sentinel config-epoch gitlab-redis 0 sentinel leader-epoch gitlab-redis 0 ``` +#### Sentinel setup (EE Only) + +To setup sentinel, you must edit `/etc/gitlab/gitlab.rb` file. +This is a minimal configuration required to run the daemon: + +```ruby +redis['master_name'] = 'gitlab-redis' # must be the same in every sentinel node +redis['master_ip'] = '10.0.0.1' # ip of the initial master redis instance +redis['master_port'] = 6379 # port of the initial master redis instance +redis['master_password'] = 'your-secure-password-here' # the same value defined in redis['password'] in the master instance + +sentinel['enable'] = true +# sentinel['port'] = 26379 + +## Quorum must reflect the amount of voting sentinels it take to start a failover. +sentinel['quorum'] = 2 + +## Consider unresponsive server down after x amount of ms. +# sentinel['down_after_milliseconds'] = 10000 + +# sentinel['failover_timeout'] = 60000 +``` + +When you install Sentinel in a separate machine, you need to control which +other services will be running in it. Take a look at the following variables +and enable or disable whenever it fits your strategy: + +```ruby +# Enabled Redis and Sentinel services +redis['enable'] = true +sentinel['enable'] = true + +# Disabled all other services +redis['enable'] = false +bootstrap['enable'] = false +nginx['enable'] = false +unicorn['enable'] = false +sidekiq['enable'] = false +postgresql['enable'] = false +gitlab_workhorse['enable'] = false +gitlab_rails['enable'] = false +mailroom['enable'] = false +``` + +Remember that enabling a new service may also require additional configuration +params (like `redis` for example). + --- The final part is to inform the main GitLab application server of the Redis @@ -243,7 +439,7 @@ or `gitlab-rails['redis_*']` in Omnibus): ```conf # sentinel.conf: -sentinel monitor gitlab-redis 10.10.10.10 6379 1 +sentinel monitor gitlab-redis 10.10.10.10 6379 2 sentinel down-after-milliseconds gitlab-redis 10000 sentinel config-epoch gitlab-redis 0 sentinel leader-epoch gitlab-redis 0 @@ -276,7 +472,7 @@ To make sure your configuration is correct: sudo gitlab-rails console # For source installations - sudo -u git rails console RAILS_ENV=production + sudo -u git rails console production ``` 1. Run in the console: -- cgit v1.2.3 From 3242ea6d40442f19c3932715521864ac5eb3700b Mon Sep 17 00:00:00 2001 From: Gabriel Mazetto Date: Tue, 18 Oct 2016 19:45:57 +0200 Subject: Improved Redis HA and Sentinel documentation. --- doc/administration/high_availability/redis.md | 327 +++++++++++++++++--------- 1 file changed, 210 insertions(+), 117 deletions(-) (limited to 'doc/administration') diff --git a/doc/administration/high_availability/redis.md b/doc/administration/high_availability/redis.md index 840f5896bd7..29bf2c54a08 100644 --- a/doc/administration/high_availability/redis.md +++ b/doc/administration/high_availability/redis.md @@ -1,7 +1,7 @@ # Configuring Redis for GitLab HA You can choose to install and manage Redis yourself, or you can use the one -that comes bundled with GitLab Omnibus packages. +that comes bundled with Omnibus GitLab packages. > **Note:** Redis does not require authentication by default. See [Redis Security](http://redis.io/topics/security) documentation for more @@ -15,17 +15,22 @@ that comes bundled with GitLab Omnibus packages. - [Configure your own Redis server](#configure-your-own-redis-server) - [Configure Redis using Omnibus](#configure-redis-using-omnibus) - [Experimental Redis Sentinel support](#experimental-redis-sentinel-support) +- [Redis Sentinel support](#redis-sentinel-support) - [Redis setup](#redis-setup) - - [Source install](#source-install) - - [Omnibus Install](#omnibus-install) - - [Troubleshooting Replication](#troubleshooting-replication) - - [Sentinel](#sentinel) - - [Sentinel setup (Community Edition)](#sentinel-setup-community-edition) - - [Sentinel setup (EE Only)](#sentinel-setup-ee-only) + - [Existing single-machine installation](#existing-single-machine-installation) + - [Installation from source](#installation-from-source) + - [Omnibus packages](#omnibus-packages) + - [Configuring Sentinel](#configuring-sentinel) + - [How sentinel handles a failover](#how-sentinel-handles-a-failover) + - [Sentinel setup](#sentinel-setup) + - [Community Edition](#community-edition) + - [Enterprise Edition](#enterprise-edition) - [GitLab setup](#gitlab-setup) - - [Sentinel troubleshooting](#sentinel-troubleshooting) +- [Troubleshooting](#troubleshooting) + - [Redis replication](#redis-replication) + - [Sentinel](#sentinel) - [Omnibus install](#omnibus-install) - - [Source install](#source-install-1) + - [Source install](#source-install) @@ -41,7 +46,7 @@ If you don't want to bother setting up your own Redis server, you can use the one bundled with Omnibus. In this case, you should disable all services except Redis. -1. Download/install GitLab Omnibus using **steps 1 and 2** from +1. Download/install Omnibus GitLab using **steps 1 and 2** from [GitLab downloads](https://about.gitlab.com/downloads). Do not complete other steps on the download page. 1. Create/edit `/etc/gitlab/gitlab.rb` and use the following configuration. @@ -70,7 +75,7 @@ Redis. redis['password'] = 'redis-password-goes-here' ``` -1. Run `sudo gitlab-ctl reconfigure` to install and configure PostgreSQL. +1. Run `sudo gitlab-ctl reconfigure` to install and configure Redis. > **Note**: This `reconfigure` step will result in some errors. That's OK - don't be alarmed. @@ -81,7 +86,12 @@ Redis. ## Experimental Redis Sentinel support -> [Introduced][ce-1877] in GitLab 8.11, improved in 8.13. + > Experimental Redis Sentinel support was [Introduced][ce-1877] in GitLab 8.11. + Starting with 8.13, Redis Sentinel is no longer experimental. + If you used with versions `< 8.13` before, please check the updated + documentation below. + +## Redis Sentinel support Since GitLab 8.11, you can configure a list of Redis Sentinel servers that will monitor a group of Redis servers to provide you with a standard failover @@ -100,20 +110,19 @@ keep servers online with minimal to no downtime: data-partitioning). - Can be queried by clients to always connect to the correct master server. -There is currently one exception to the Sentinel support: `mail_room`, the -component that processes incoming emails. It doesn't support Sentinel yet, but -we hope to integrate a future release that does support it soon. - The configuration consists of three parts: - Setup Redis Master and Slave nodes - Setup Sentinel nodes - Setup GitLab -> **IMPORTANT**: You need at least 3 independent machines: physical, or VMs -running into distinct physical machines. If you fail to provision the -machines in that specific way, any issue with the shared environment can -bring your entire setup down. +### Prerequisites + +You need at least `3` independent machines: physical, or VMs running into +distinct physical machines. + +If you fail to provision the machines in that specific way, any issue with +the shared environment can bring your entire setup down. Read carefully how to configure those components below. @@ -131,15 +140,35 @@ Sentinel instances and other redis instances should be able to talk to each other over the network. You'll need to define both `requirepass` and `masterauth` in all -nodes because they can be re-configured at any time by the Sentinels -during a failover, and change it's status as `Master` or `Slave`. +nodes. At any time during a failover the Sentinels can reconfigure a node +and change it's status from `Master` to `Slave` and vice versa. -Initial `Slave` nodes will have in `redis.conf` an additional `slaveof` line +Initial `Slave` nodes require an additional `slaveof` setting in `redis.conf` pointing to the initial `Master`. -#### Source install +#### Existing single-machine installation + +If you already have a single-machine GitLab install running, you will need to +replicate from this machine first, before de-activating the Redis instance +inside it. + +Your single-machine install will be the initial `Master`, and the `3` others +should be configured as `Slave` pointing to this machine. + +After replication catchs-up, you will need to stop services in the +single-machine install, to rotate the `Master` to one of the new nodes. + +Make the required changes in configuration and restart the new nodes again. + +To disable redis in the single install, edit `/etc/gitlab/gitlab.rb`: -**Master Redis instance** +```ruby +redis['enable'] = false +``` + +#### Installation from source + +**Configuring Master Redis instance** You need to make the following changes in `redis.conf`: @@ -178,9 +207,9 @@ You need to make the following changes in `redis.conf`: 1. Restart the Redis services for the changes to take effect. -**Slave Redis instance** +**Configuring Slave Redis instance** -1. Follow same instructions from master with the extra change in `redis.conf`: +1. Follow same instructions from master, with the extra change in `redis.conf`: ```conf # IP and port of the master Redis server @@ -189,33 +218,24 @@ You need to make the following changes in `redis.conf`: 1. Restart the Redis services for the changes to take effect. -#### Omnibus Install - -You need to install the omnibus package in 3 different and independent machines. -We will elect one as the initial `Master` and the other 2 as `Slaves`. +#### Omnibus packages -If you are migrating from a single machine install, you may want to setup the -machines as Slaves, pointing to the original machine as `Master`, to migrate -the data first, and than switch to this setup. - -To disable redis in the single install, edit `/etc/gitlab/gitlab.rb`: - -```ruby -redis['enable'] = false -``` +You need to install the Omnibus GitLab package in `3` independent machines. -**Master Redis instances** +**Configuring Master Redis instance** -You need to make the following changes in `/etc/gitlab/gitlab.rb`: +You will need to configure the following: 1. Define a `redis['bind']` address pointing to a local IP that your other machines can reach you. If you really need to bind to an external acessible IP, make sure you add extra firewall rules to prevent unauthorized access. -1. Define a `redis['port']` to force redis to listin on TCP so other machines can - connect to it. -1. Set up password authentication with `redis['master_password']` (use the same +1. Define a `redis['port']` so redis can listen for TCP requests which will + allow other machines to connect to it. +1. Set up a password authentication with `redis['master_password']` (use the same password in all nodes). +In `/etc/gitlab/gitlab.rb`: + ```ruby ## Redis TCP support (will disable UNIX socket transport) redis['bind'] = '0.0.0.0' # or specify an IP to bind to a single one @@ -224,15 +244,14 @@ redis['requirepass'] = 'redis-password-goes-here' redis['master_password'] = 'redis-password-goes-here' ``` -Reconfigure GitLab Omnibus for the changes to take effect: `sudo gitlab-ctl reconfigure` +Reconfigure Omnibus GitLab for the changes to take effect: `sudo gitlab-ctl reconfigure` -**Slave Redis instances** +**Configuring Slave Redis instances** You need to make the same changes listed for the `Master` instance, with an additional `Slave` section as in the example below: ```ruby -## Redis TCP support (will disable UNIX socket transport) redis['bind'] = '0.0.0.0' # or specify an IP to bind to a single one redis['port'] = 6379 redis['requirepass'] = 'redis-password-goes-here' @@ -244,26 +263,7 @@ redis['master_ip'] = '10.10.10.10' # IP of master Redis server redis['master_port'] = 6379 # Port of master Redis server ``` -Reconfigure GitLab Omnibus for the changes to take effect: `sudo gitlab-ctl reconfigure` - -#### Troubleshooting Replication - -You can check if everything is correct by connecting to each server using -`redis-cli` application, and sending the `INFO` command. - -If authentication was correctly defined, it should fail with: -`NOAUTH Authentication required` error. Try to authenticate with the -previous defined password with `AUTH redis-password-goes-here` and -try the `INFO` command again. - -Look for the `# Replication` section where you should see some important -information like the `role` of the server. - -When connected to a `master` redis, you will see the number of connected -`slaves`, and a list of each with connection details. - -When it's a `slave`, you will see details of the master connection and if -its `up` or `down`. +Reconfigure Omnibus GitLab for the changes to take effect: `sudo gitlab-ctl reconfigure` --- @@ -274,26 +274,29 @@ If you are not sure if your Redis servers are working and replicating correctly, please read the [Troubleshooting Replication](#troubleshooting-replication) and fix it before proceeding with Sentinel setup. -### Sentinel +### Configuring Sentinel You must have at least `3` Redis Sentinel servers, and they need to -be each in a independent machine. You can install them in the same -machines you installed the other `3` Redis servers. +be each in a independent machine. You can configure them in the same +machines where you've configured the other Redis servers. This number is required for the consensus algorithm to be effective -in the case of a failure. You should always have and `odd` number -of Sentinel nodes provisioned. +in the case of a failure. **You should always have and `odd` number +of Sentinel nodes provisioned**. + +#### How sentinel handles a failover -Here is a simple explanation on how Sentinel handles a failover: +If (`quorum` value of) Sentinels agree the fact the `master` is not reachable, +Sentinels will try to elect a temporary `Leader`. The **Majority** of the +Sentinels must agree to start a failover. -When a number of Sentinels (`quorum` value) agree the fact the `master` is -not reachable, the **majority** of the sentinels must elect a temporary -Sentinel `leader`, that will be responsible to start the failover proceedings. +If you don't have the **Majority** of the Sentinels online (for example if you +are under a network partitioning), a failover **will not be started**. -As an example, for a cluster of `3` Sentinels, at least `2` must agree on a -`leader`. If you have total of `5` at least `3` must agree on the leader. +For example, for a cluster of `3` Sentinels, at least `2` must agree on a +`Leader`. If you have total of `5` at least `3` must agree on a `Leader`. -The `quorum` is only used to detect failure, not to elect the `leader`. +The `quorum` is only used to detect failure, not to elect the `Leader`. Official [Sentinel documentation](http://redis.io/topics/sentinel#example-sentinel-deployments) also lists different network topologies and warns againts situations like @@ -301,16 +304,16 @@ network partition and how it can affect the state of the HA solution. Make sure you read it carefully and understand the implications in your current setup. -To make Sentinel setup easier, ee provide an [automated way to setup and run](#sentinel-setup-ee-only) -the Sentinel daemon with GitLab EE. +GitLab Enterprise Edition provides [automated way to setup and run](#sentinel-setup-ee-only) the Sentinel daemon. -#### Sentinel setup (Community Edition) +#### Sentinel setup -For GitLab CE, you need to install, configure, execute and monitor Sentinel -by yourself. +##### Community Edition +With GitLab Community Edition, you need to install, configure, execute and +monitor Sentinel from source. Omnibus GitLab Community Edition package does +not support Sentinel configuration. -Here is an example configuration file (`sentinel.conf`) for a minimal Sentinel -node: +A minimal configuration file (`sentinel.conf`) should contain the following: ```conf bind 0.0.0.0 # bind to all interfaces or change to a specific IP @@ -322,35 +325,17 @@ sentinel config-epoch gitlab-redis 0 sentinel leader-epoch gitlab-redis 0 ``` -#### Sentinel setup (EE Only) +##### Enterprise Edition -To setup sentinel, you must edit `/etc/gitlab/gitlab.rb` file. -This is a minimal configuration required to run the daemon: +To setup sentinel, you edit `/etc/gitlab/gitlab.rb` file: ```ruby -redis['master_name'] = 'gitlab-redis' # must be the same in every sentinel node -redis['master_ip'] = '10.0.0.1' # ip of the initial master redis instance -redis['master_port'] = 6379 # port of the initial master redis instance -redis['master_password'] = 'your-secure-password-here' # the same value defined in redis['password'] in the master instance -sentinel['enable'] = true -# sentinel['port'] = 26379 +## When you install Sentinel in a separate machine, you need to control which +## other services will be running in it. Take a look at the following variables +## and enable or disable whenever it fits your strategy: -## Quorum must reflect the amount of voting sentinels it take to start a failover. -sentinel['quorum'] = 2 - -## Consider unresponsive server down after x amount of ms. -# sentinel['down_after_milliseconds'] = 10000 - -# sentinel['failover_timeout'] = 60000 -``` - -When you install Sentinel in a separate machine, you need to control which -other services will be running in it. Take a look at the following variables -and enable or disable whenever it fits your strategy: - -```ruby -# Enabled Redis and Sentinel services +## Enabled Redis and Sentinel services redis['enable'] = true sentinel['enable'] = true @@ -364,10 +349,53 @@ postgresql['enable'] = false gitlab_workhorse['enable'] = false gitlab_rails['enable'] = false mailroom['enable'] = false -``` -Remember that enabling a new service may also require additional configuration -params (like `redis` for example). +## Configure Redis +redis['master_name'] = 'gitlab-redis' # must be the same in every sentinel node +redis['master_ip'] = '10.0.0.1' # ip of the initial master redis instance +redis['master_port'] = 6379 # port of the initial master redis instance +redis['master_password'] = 'your-secure-password-here' # the same value defined in redis['password'] in the master instance + +## Configure Sentinel +# sentinel['port'] = 26379 # uncomment to change default port + +## Quorum must reflect the amount of voting sentinels it take to start a failover. +## Value must NOT be greater then the ammount of sentinels. +## +## The quorum can be used to tune Sentinel in two ways: +## 1. If a the quorum is set to a value smaller than the majority of Sentinels +## we deploy, we are basically making Sentinel more sensible to master failures, +## triggering a failover as soon as even just a minority of Sentinels is no longer +## able to talk with the master. +## 1. If a quorum is set to a value greater than the majority of Sentinels, we are +## making Sentinel able to failover only when there are a very large number (larger +## than majority) of well connected Sentinels which agree about the master being down.s +sentinel['quorum'] = 2 + +## Consider unresponsive server down after x amount of ms. +# sentinel['down_after_milliseconds'] = 10000 + +## Specifies the failover timeout in milliseconds. It is used in many ways: +## +## - The time needed to re-start a failover after a previous failover was +## already tried against the same master by a given Sentinel, is two +## times the failover timeout. +## +## - The time needed for a slave replicating to a wrong master according +## to a Sentinel current configuration, to be forced to replicate +## with the right master, is exactly the failover timeout (counting since +## the moment a Sentinel detected the misconfiguration). +## +## - The time needed to cancel a failover that is already in progress but +## did not produced any configuration change (SLAVEOF NO ONE yet not +## acknowledged by the promoted slave). +## +## - The maximum time a failover in progress waits for all the slaves to be +## reconfigured as slaves of the new master. However even after this time +## the slaves will be reconfigured by the Sentinels anyway, but not with +## the exact parallel-syncs progression as specified. +# sentinel['failover_timeout'] = 60000 +``` --- @@ -409,9 +437,74 @@ The following steps should be performed in the [GitLab application server](gitla 1. [Reconfigure] the GitLab for the changes to take effect. -### Sentinel troubleshooting +## Troubleshooting + +There are a lot of moving parts that needs to be taken care carefully +in order for the HA setup to work as expected. + +Before proceeding with the troubleshooting below, check your firewall +rules: +- Redis machines + - Accept TCP connection in `6379` + - Connect to the other Redis machines via TCP in `6379` +- Sentinel machines + - Accept TCP connection in `26379` + - Connect to other Sentinel machines via TCP in `26379` + - Connect to the Redis machines via TCP in `6379` + +### Redis replication + +You can check if everything is correct by connecting to each server using +`redis-cli` application, and sending the `INFO` command. + +If authentication was correctly defined, it should fail with: +`NOAUTH Authentication required` error. Try to authenticate with the +previous defined password with `AUTH redis-password-goes-here` and +try the `INFO` command again. + +Look for the `# Replication` section where you should see some important +information like the `role` of the server. + +When connected to a `master` redis, you will see the number of connected +`slaves`, and a list of each with connection details: + +``` +# Replication +role:master +connected_slaves:1 +slave0:ip=10.133.5.21,port=6379,state=online,offset=208037514,lag=1 +master_repl_offset:208037658 +repl_backlog_active:1 +repl_backlog_size:1048576 +repl_backlog_first_byte_offset:206989083 +repl_backlog_histlen:1048576 +``` + +When it's a `slave`, you will see details of the master connection and if +its `up` or `down`: + +``` +# Replication +role:slave +master_host:10.133.1.58 +master_port:6379 +master_link_status:up +master_last_io_seconds_ago:1 +master_sync_in_progress:0 +slave_repl_offset:208096498 +slave_priority:100 +slave_read_only:1 +connected_slaves:0 +master_repl_offset:0 +repl_backlog_active:0 +repl_backlog_size:1048576 +repl_backlog_first_byte_offset:0 +repl_backlog_histlen:0 +``` + +### Sentinel -#### Omnibus install +#### Omnibus GitLab If you get an error like: `Redis::CannotConnectError: No sentinels available.`, there may be something wrong with your configuration files or it can be related @@ -424,7 +517,7 @@ The way the redis connector `redis-rb` works with sentinel is a bit non-intuitive. We try to hide the complexity in omnibus, but it still requires a few extra configs. -#### Source install +#### Install from Source If you get an error like: `Redis::CannotConnectError: No sentinels available.`, there may be something wrong with your configuration files or it can be related -- cgit v1.2.3 From 0ca14544df6f8053a998009043290a4242d0362c Mon Sep 17 00:00:00 2001 From: Gabriel Mazetto Date: Tue, 18 Oct 2016 19:52:19 +0200 Subject: Reduce the ammount of lines to disable services and update TOC --- doc/administration/high_availability/redis.md | 12 +++--------- 1 file changed, 3 insertions(+), 9 deletions(-) (limited to 'doc/administration') diff --git a/doc/administration/high_availability/redis.md b/doc/administration/high_availability/redis.md index 29bf2c54a08..aa334a8a0f6 100644 --- a/doc/administration/high_availability/redis.md +++ b/doc/administration/high_availability/redis.md @@ -16,6 +16,7 @@ that comes bundled with Omnibus GitLab packages. - [Configure Redis using Omnibus](#configure-redis-using-omnibus) - [Experimental Redis Sentinel support](#experimental-redis-sentinel-support) - [Redis Sentinel support](#redis-sentinel-support) + - [Prerequisites](#prerequisites) - [Redis setup](#redis-setup) - [Existing single-machine installation](#existing-single-machine-installation) - [Installation from source](#installation-from-source) @@ -29,8 +30,8 @@ that comes bundled with Omnibus GitLab packages. - [Troubleshooting](#troubleshooting) - [Redis replication](#redis-replication) - [Sentinel](#sentinel) - - [Omnibus install](#omnibus-install) - - [Source install](#source-install) + - [Omnibus GitLab](#omnibus-gitlab) + - [Install from Source](#install-from-source) @@ -60,11 +61,8 @@ Redis. redis['enable'] = true bootstrap['enable'] = false nginx['enable'] = false - unicorn['enable'] = false - sidekiq['enable'] = false postgresql['enable'] = false gitlab_rails['enable'] = false - gitlab_workhorse['enable'] = false mailroom['enable'] = false # Redis configuration @@ -340,13 +338,9 @@ redis['enable'] = true sentinel['enable'] = true # Disabled all other services -redis['enable'] = false bootstrap['enable'] = false nginx['enable'] = false -unicorn['enable'] = false -sidekiq['enable'] = false postgresql['enable'] = false -gitlab_workhorse['enable'] = false gitlab_rails['enable'] = false mailroom['enable'] = false -- cgit v1.2.3 From 1dcbff1c4b07a0893f6d4a676895e8a01b8cfb14 Mon Sep 17 00:00:00 2001 From: Gabriel Mazetto Date: Thu, 20 Oct 2016 18:11:00 +0200 Subject: Few more fixes to Sentinel documentation to address MR feedback --- doc/administration/high_availability/redis.md | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) (limited to 'doc/administration') diff --git a/doc/administration/high_availability/redis.md b/doc/administration/high_availability/redis.md index aa334a8a0f6..d60852814bb 100644 --- a/doc/administration/high_availability/redis.md +++ b/doc/administration/high_availability/redis.md @@ -63,13 +63,10 @@ Redis. nginx['enable'] = false postgresql['enable'] = false gitlab_rails['enable'] = false - mailroom['enable'] = false # Redis configuration redis['port'] = 6379 redis['bind'] = '0.0.0.0' - - # If you wish to use Redis authentication (recommended) redis['password'] = 'redis-password-goes-here' ``` @@ -85,8 +82,8 @@ Redis. ## Experimental Redis Sentinel support > Experimental Redis Sentinel support was [Introduced][ce-1877] in GitLab 8.11. - Starting with 8.13, Redis Sentinel is no longer experimental. - If you used with versions `< 8.13` before, please check the updated + Starting with 8.14, Redis Sentinel is no longer experimental. + If you used with versions `< 8.14` before, please check the updated documentation below. ## Redis Sentinel support @@ -279,7 +276,7 @@ be each in a independent machine. You can configure them in the same machines where you've configured the other Redis servers. This number is required for the consensus algorithm to be effective -in the case of a failure. **You should always have and `odd` number +in the case of a failure. **You should always have an `odd` number of Sentinel nodes provisioned**. #### How sentinel handles a failover @@ -400,7 +397,7 @@ master and the new sentinels servers. You can enable or disable sentinel support at any time in new or existing installations. From the GitLab application perspective, all it requires is -the correct credentials for the master Redis and for a few Sentinel nodes. +the correct credentials for the master Redis and for all Sentinel nodes. It doesn't require a list of all Sentinel nodes, as in case of a failure, the application will need to query only one of them. -- cgit v1.2.3 From 92e603727fd93ab862f7c6b5b46dfa2b1dd3a44e Mon Sep 17 00:00:00 2001 From: Gabriel Mazetto Date: Sat, 29 Oct 2016 00:40:28 +0200 Subject: Fixed documentation and added redis/sentinel roles instruction --- doc/administration/high_availability/redis.md | 68 +++++++++++++++++++++------ 1 file changed, 54 insertions(+), 14 deletions(-) (limited to 'doc/administration') diff --git a/doc/administration/high_availability/redis.md b/doc/administration/high_availability/redis.md index d60852814bb..bfad3047385 100644 --- a/doc/administration/high_availability/redis.md +++ b/doc/administration/high_availability/redis.md @@ -235,7 +235,7 @@ In `/etc/gitlab/gitlab.rb`: ## Redis TCP support (will disable UNIX socket transport) redis['bind'] = '0.0.0.0' # or specify an IP to bind to a single one redis['port'] = 6379 -redis['requirepass'] = 'redis-password-goes-here' +redis['password'] = 'redis-password-goes-here' redis['master_password'] = 'redis-password-goes-here' ``` @@ -249,7 +249,7 @@ with an additional `Slave` section as in the example below: ```ruby redis['bind'] = '0.0.0.0' # or specify an IP to bind to a single one redis['port'] = 6379 -redis['requirepass'] = 'redis-password-goes-here' +redis['password'] = 'redis-password-goes-here' redis['master_password'] = 'redis-password-goes-here' ## Slave redis instance @@ -327,27 +327,25 @@ To setup sentinel, you edit `/etc/gitlab/gitlab.rb` file: ```ruby ## When you install Sentinel in a separate machine, you need to control which -## other services will be running in it. Take a look at the following variables -## and enable or disable whenever it fits your strategy: +## other services will be running in it. +## We've simplified the choice using special "roles" settings: -## Enabled Redis and Sentinel services -redis['enable'] = true -sentinel['enable'] = true +## Enabled Sentinel and Redis Master services +redis_sentinel_role['enable'] = true +redis_master_role['enable'] = true -# Disabled all other services -bootstrap['enable'] = false -nginx['enable'] = false -postgresql['enable'] = false -gitlab_rails['enable'] = false -mailroom['enable'] = false +## Enabled Sentinel and Redis Slave services +redis_sentinel_role['enable'] = true +redis_master_role['enable'] = true ## Configure Redis redis['master_name'] = 'gitlab-redis' # must be the same in every sentinel node redis['master_ip'] = '10.0.0.1' # ip of the initial master redis instance redis['master_port'] = 6379 # port of the initial master redis instance -redis['master_password'] = 'your-secure-password-here' # the same value defined in redis['password'] in the master instance +redis['master_password'] = 'redis-password-goes-here' # the same value defined in redis['password'] in the master instance ## Configure Sentinel +sentinel['bind'] = '0.0.0.0' # or specify an IP to bind to a single one # sentinel['port'] = 26379 # uncomment to change default port ## Quorum must reflect the amount of voting sentinels it take to start a failover. @@ -388,6 +386,48 @@ sentinel['quorum'] = 2 # sentinel['failover_timeout'] = 60000 ``` +In the example above we've used `redis_sentinel_role` and `redis_master_role` +which simplify the ammount of configuration changes. + +If you want more control, here is what each one sets for you automatically +when enabled: + +```ruby +## Redis Sentinel Role +redis_sentinel_role['enable'] = true + +# When Sentinel Role is enabled, the following services are enabled/disabled: +sentinel['enable'] = true + +# This others are disabled: +redis['enable'] = false +bootstrap['enable'] = false +nginx['enable'] = false +postgresql['enable'] = false +gitlab_rails['enable'] = false +mailroom['enable'] = false + +## Redis master/slave Role: +redis_master_role['enable'] = true # enable only one of them +redis_slave_role['enable'] = true # enable only one of them + +# When Redis Master or Slave role are enabled, the following services are enabled/disabled: +# (Note that if redis and sentinel roles are combined both services will be enabled) + +# When Sentinel Role is enabled, the following services are enabled/disabled: +redis['enable'] = true + +# This others are disabled: +sentinel['enable'] = false +bootstrap['enable'] = false +nginx['enable'] = false +postgresql['enable'] = false +gitlab_rails['enable'] = false +mailroom['enable'] = false + +# Redis Slave role also change this setting from default 'true' to 'false': +redis['master'] = false +``` --- The final part is to inform the main GitLab application server of the Redis -- cgit v1.2.3 From 494c2785fdc6a2f67edf20cbfc2106ffdba3ef28 Mon Sep 17 00:00:00 2001 From: Gabriel Mazetto Date: Tue, 8 Nov 2016 06:24:43 +0100 Subject: Fixed some documentation and moved Source install specific to other file. --- doc/administration/high_availability/redis.md | 135 +--------- .../high_availability/redis_source.md | 286 +++++++++++++++++++++ 2 files changed, 300 insertions(+), 121 deletions(-) create mode 100644 doc/administration/high_availability/redis_source.md (limited to 'doc/administration') diff --git a/doc/administration/high_availability/redis.md b/doc/administration/high_availability/redis.md index bfad3047385..f49bf1d4ab5 100644 --- a/doc/administration/high_availability/redis.md +++ b/doc/administration/high_availability/redis.md @@ -19,7 +19,6 @@ that comes bundled with Omnibus GitLab packages. - [Prerequisites](#prerequisites) - [Redis setup](#redis-setup) - [Existing single-machine installation](#existing-single-machine-installation) - - [Installation from source](#installation-from-source) - [Omnibus packages](#omnibus-packages) - [Configuring Sentinel](#configuring-sentinel) - [How sentinel handles a failover](#how-sentinel-handles-a-failover) @@ -31,7 +30,6 @@ that comes bundled with Omnibus GitLab packages. - [Redis replication](#redis-replication) - [Sentinel](#sentinel) - [Omnibus GitLab](#omnibus-gitlab) - - [Install from Source](#install-from-source) @@ -161,58 +159,6 @@ To disable redis in the single install, edit `/etc/gitlab/gitlab.rb`: redis['enable'] = false ``` -#### Installation from source - -**Configuring Master Redis instance** - -You need to make the following changes in `redis.conf`: - -1. Define a `bind` address pointing to a local IP that your other machines - can reach you. If you really need to bind to an external acessible IP, make - sure you add extra firewall rules to prevent unauthorized access: - - ```conf - # By default, if no "bind" configuration directive is specified, Redis listens - # for connections from all the network interfaces available on the server. - # It is possible to listen to just one or multiple selected interfaces using - # the "bind" configuration directive, followed by one or more IP addresses. - # - # Examples: - # - # bind 192.168.1.100 10.0.0.1 - # bind 127.0.0.1 ::1 - bind 0.0.0.0 # This will bind to all interfaces - ``` - -1. Define a `port` to force redis to listin on TCP so other machines can - connect to it: - - ```conf - # Accept connections on the specified port, default is 6379 (IANA #815344). - # If port 0 is specified Redis will not listen on a TCP socket. - port 6379 - ``` - -1. Set up password authentication (use the same password in all nodes) - - ```conf - requirepass "redis-password-goes-here" - masterauth "redis-password-goes-here" - ``` - -1. Restart the Redis services for the changes to take effect. - -**Configuring Slave Redis instance** - -1. Follow same instructions from master, with the extra change in `redis.conf`: - - ```conf - # IP and port of the master Redis server - slaveof 10.10.10.10 6379 - ``` - -1. Restart the Redis services for the changes to take effect. - #### Omnibus packages You need to install the Omnibus GitLab package in `3` independent machines. @@ -304,25 +250,16 @@ GitLab Enterprise Edition provides [automated way to setup and run](#sentinel-se #### Sentinel setup ##### Community Edition + With GitLab Community Edition, you need to install, configure, execute and monitor Sentinel from source. Omnibus GitLab Community Edition package does not support Sentinel configuration. -A minimal configuration file (`sentinel.conf`) should contain the following: - -```conf -bind 0.0.0.0 # bind to all interfaces or change to a specific IP -port 26379 # default sentinel port -sentinel auth-pass gitlab-redis redis-password-goes-here -sentinel monitor gitlab-redis 10.0.0.1 6379 2 -sentinel down-after-milliseconds gitlab-redis 10000 -sentinel config-epoch gitlab-redis 0 -sentinel leader-epoch gitlab-redis 0 -``` +See documentation for Source Install [here](redis_source.md). ##### Enterprise Edition -To setup sentinel, you edit `/etc/gitlab/gitlab.rb` file: +To setup sentinel, edit `/etc/gitlab/gitlab.rb` file: ```ruby @@ -336,7 +273,7 @@ redis_master_role['enable'] = true ## Enabled Sentinel and Redis Slave services redis_sentinel_role['enable'] = true -redis_master_role['enable'] = true +redis_slave_role['enable'] = true ## Configure Redis redis['master_name'] = 'gitlab-redis' # must be the same in every sentinel node @@ -345,7 +282,7 @@ redis['master_port'] = 6379 # port of the initial master redis instance redis['master_password'] = 'redis-password-goes-here' # the same value defined in redis['password'] in the master instance ## Configure Sentinel -sentinel['bind'] = '0.0.0.0' # or specify an IP to bind to a single one +# sentinel['bind'] = '0.0.0.0' # bind to all interfaces, uncomment to specify an IP and bind to a single one # sentinel['port'] = 26379 # uncomment to change default port ## Quorum must reflect the amount of voting sentinels it take to start a failover. @@ -435,24 +372,16 @@ master and the new sentinels servers. ### GitLab setup -You can enable or disable sentinel support at any time in new or existing +You can enable or disable Sentinel support at any time in new or existing installations. From the GitLab application perspective, all it requires is -the correct credentials for the master Redis and for all Sentinel nodes. +the correct credentials for the Sentinel nodes. -It doesn't require a list of all Sentinel nodes, as in case of a failure, -the application will need to query only one of them. +While it doesn't require a list of all Sentinel nodes, in case of a failure, +it needs to access at one of listed ones. >**Note:** -The following steps should be performed in the [GitLab application server](gitlab.md). - -**For source based installations** - -1. Edit `/home/git/gitlab/config/resque.yml` following the example in - `/home/git/gitlab/config/resque.yml.example`, and uncomment the sentinels - line, changing to the correct server credentials. -1. Restart GitLab for the changes to take effect. - -**For Omnibus installations** +The following steps should be performed in the [GitLab application server](gitlab.md) +which ideally should not have Redis or Sentinels in the same machine for a HA setup. 1. Edit `/etc/gitlab/gitlab.rb` and add/change the following lines: @@ -466,7 +395,7 @@ The following steps should be performed in the [GitLab application server](gitla ] ``` -1. [Reconfigure] the GitLab for the changes to take effect. +1. [Reconfigure] GitLab for the changes to take effect. ## Troubleshooting @@ -548,42 +477,6 @@ The way the redis connector `redis-rb` works with sentinel is a bit non-intuitive. We try to hide the complexity in omnibus, but it still requires a few extra configs. -#### Install from Source - -If you get an error like: `Redis::CannotConnectError: No sentinels available.`, -there may be something wrong with your configuration files or it can be related -to [this issue][gh-531]. - -It's a bit non-intuitive the way you have to config `resque.yml` and -`sentinel.conf`, otherwise `redis-rb` will not work properly. - -The `master-group-name` ('gitlab-redis') defined in (`sentinel.conf`) -**must** be used as the hostname in GitLab (`resque.yml` for source installations -or `gitlab-rails['redis_*']` in Omnibus): - -```conf -# sentinel.conf: -sentinel monitor gitlab-redis 10.10.10.10 6379 2 -sentinel down-after-milliseconds gitlab-redis 10000 -sentinel config-epoch gitlab-redis 0 -sentinel leader-epoch gitlab-redis 0 -``` - -```yaml -# resque.yaml -production: - url: redis://:myredispassword@gitlab-redis/ - sentinels: - - - host: slave1.example.com # or use ip - port: 26380 # point to sentinel, not to redis port - - - host: slave2.exampl.com # or use ip - port: 26381 # point to sentinel, not to redis port -``` - -When in doubt, please read [Redis Sentinel documentation](http://redis.io/topics/sentinel) - --- To make sure your configuration is correct: @@ -611,8 +504,8 @@ To make sure your configuration is correct: 1. To simulate a failover on master Redis, SSH into the Redis server and run: ```bash - # port must match your master redis port - redis-cli -h localhost -p 6379 DEBUG sleep 60 + # port must match your master redis port, and the sleep time must be a few seconds bigger than defined one + redis-cli -h localhost -p 6379 DEBUG sleep 20 ``` 1. Then back in the Rails console from the first step, run: diff --git a/doc/administration/high_availability/redis_source.md b/doc/administration/high_availability/redis_source.md new file mode 100644 index 00000000000..7e8c8c2b4b9 --- /dev/null +++ b/doc/administration/high_availability/redis_source.md @@ -0,0 +1,286 @@ +# Configuring Redis for GitLab HA (Source Install) + +We highly recommend that you use Omnibus GitLab packages, as we can optimize +required packages specifically for GitLab, and we will take care of upgrading +to the latest supported version. + +If you are building packages for a specific distro, or trying to build some +internal automation, you can check this documentation to learn about the +minimal setup, required changes, etc. + +If you want to see the documentation for Omnibus GitLab Install, please [read it here](redis.md). + + + +**Table of Contents** + +- [Configure your own Redis server](#configure-your-own-redis-server) + - [Configuring Master Redis instance](#configuring-master-redis-instance) + - [Configuring Slave Redis instances](#configuring-slave-redis-instances) + - [Configuring Redis Sentinel instances](#configuring-redis-sentinel-instances) +- [GitLab setup](#gitlab-setup) +- [Example configurations](#example-configurations) + - [Configuring Redis Master](#configuring-redis-master) + - [Configuring Redis Slaves](#configuring-redis-slaves) + - [Configuring Redis Sentinel](#configuring-redis-sentinel) +- [Troubleshooting](#troubleshooting) + + + +## Configure your own Redis server + +Redis server must be configured to use TCP connection instead of socket, +and since Redis `3.2`, you must define a password to receive external +connections (`requirepass`). + +You will also need to define equal password for slave password definition +(`masterauth`), in the same instance, if you are using Redis with Sentinel. + +To configure Redis to use TCP connection you need to define both +`bind` and `port`. You can bind to all interfaces (`0.0.0.0`) or specify the +ip of the desired interface (for ex. one from an internal network). + + +### Configuring Master Redis instance + +You need to make the following changes in `redis.conf`: + +1. Define a `bind` address pointing to a local IP that your other machines + can reach you. If you really need to bind to an external acessible IP, make + sure you add extra firewall rules to prevent unauthorized access: + +1. Define a `port` to force redis to listen on TCP so other machines can + connect to it (default port is `6379`). + +1. Set up password authentication (use the same password in all nodes). + The password should be defined equal for both `requirepass` and `masterauth` + when setting up Redis to use with Sentinel. + +1. Restart the Redis services for the changes to take effect. + +See [example configuration](#configuring-redis-master) below. + +### Configuring Slave Redis instances + +1. Follow same instructions for Redis Master + +1. Define `slaveof` pointing to the Redis master instance with **IP** and **port**. + +1. Restart the Redis services for the changes to take effect. + +See [example configuration](#configuring-redis-slaves) below. + +### Configuring Redis Sentinel instances + +Sentinel is a special type of Redis server. It inherits most of the basic +configuration options you can define in `redis.conf`, with specific ones +starting with `sentinel` prefix. + +You will need to define the initial configs to enable connectivity: + +1. Define a `bind` address pointing to a local IP that your other machines + can reach you. If you really need to bind to an external acessible IP, make + sure you add extra firewall rules to prevent unauthorized access: + +1. Define a `port` to force sentinel to listen on TCP so other machines can + connect to it (default port is `26379`). + +And the sentinel specific ones: + +1. Define with `sentinel auth-pass` the same shared password you have + defined for both Redis **Master** and **Slaves** instances. + +1. Define with `sentinel monitor` the **IP** and **port** of the Redis + **Master** node, and the **quorum** required to start a failover. + If you need more information to understand about quorum, please + read the detailed explanation in the [HA documentation for Omnibus Installs](redis.md). + +1. Define with `sentinel down-after-milliseconds` the ammount in `ms` of time + that an unresponsive server will be considered down. + +1. Define a value for `sentinel failover_timeout` in `ms`. This has multiple + meanings: + + * The time needed to re-start a failover after a previous failover was + already tried against the same master by a given Sentinel, is two + times the failover timeout. + + * The time needed for a slave replicating to a wrong master according + to a Sentinel current configuration, to be forced to replicate + with the right master, is exactly the failover timeout (counting since + the moment a Sentinel detected the misconfiguration). + + * The time needed to cancel a failover that is already in progress but + did not produced any configuration change (SLAVEOF NO ONE yet not + acknowledged by the promoted slave). + + * The maximum time a failover in progress waits for all the slaves to be + reconfigured as slaves of the new master. However even after this time + the slaves will be reconfigured by the Sentinels anyway, but not with + the exact parallel-syncs progression as specified. + +See [example configuration](#configuring-redis-sentinel) below. + +## GitLab setup + +You can enable or disable Sentinel support at any time in new or existing +installations. From the GitLab application perspective, all it requires is +the correct credentials for the Sentinel nodes. + +While it doesn't require a list of all Sentinel nodes, in case of a failure, +it needs to access at one of listed ones. + +>**Note:** +The following steps should be performed in the [GitLab application server](gitlab.md) +which ideally should not have Redis or Sentinels in the same machine for a HA setup. + +1. Edit `/home/git/gitlab/config/resque.yml` following the example in + `/home/git/gitlab/config/resque.yml.example`, and uncomment the sentinels + lines, pointing to the correct server credentials. + +1. Restart GitLab for the changes to take effect. + +## Example configurations + +In this example we consider that all servers have an internal network +interface with IPs in the `10.0.0.x` range, and that they can connect +to each other using these IPs. + +In a real world usage, you would also setup firewall rules to prevent +unauthorized access from other machines, and block traffic from the +outside (Internet). + +We will use the same `3` nodes with **Redis** + **Sentinel** topology +discussed in the [Configuring Redis for GitLab HA](redis.md) documentation. + +Here is a list and description of each **machine** and the assined **ip**: + +* `10.0.0.1`: Redis Master + Sentinel 1 +* `10.0.0.2`: Redis Slave 1 + Sentinel 2 +* `10.0.0.2`: Redis Slave 2 + Sentinel 3 + +Please note that after the initial configuration, if a failover is initiated +by the Sentinel nodes, the Redis nodes will be reconfigured and the **Master** +will change permanently (including in `redis.conf`) from one node to the other, +until a new failover is initiated again. + +The same thing will happen with `sentinel.conf` that will be overriten after the +initial execution, after any new sentinel node starts watching the **Master**, +or a failover promotes a different **Master** node. + +### Configuring Redis Master + +`redis.conf`: + +```conf +bind 10.0.0.1 +port 6379 +requirepass redis-password-goes-here +masterauth redis-password-goes-here +``` + +### Configuring Redis Slaves + +**Slave 1 - `redis.conf`:** + +```conf +bind 10.0.0.2 +port 6379 +requirepass redis-password-goes-here +masterauth redis-password-goes-here + +# IP and port of the master Redis server +slaveof 10.0.0.1 6379 +``` + +**Slave 2 - `redis.conf`:** + +```conf +bind 10.0.0.3 +port 6379 +requirepass redis-password-goes-here +masterauth redis-password-goes-here + +# IP and port of the master Redis server +slaveof 10.0.0.1 6379 +``` + +### Configuring Redis Sentinel + +For this example, **Sentinel 1** will be configured in the same machine as the +**Redis Master**, **Sentinel 2** and **Sentinel 3** in the same machines as the +**Slave 1** and **Slave 2** respectively. + +Sentinel 1 - `sentinel.conf` + +```conf +bind 10.0.0.1 +port 26379 +sentinel auth-pass gitlab-redis redis-password-goes-here +sentinel monitor gitlab-redis 10.0.0.1 6379 2 +sentinel down-after-milliseconds gitlab-redis 10000 +sentinel failover_timeout 30000 +``` + +Sentinel 2 - `sentinel.conf` + +```conf +bind 10.0.0.2 +port 26379 +sentinel auth-pass gitlab-redis redis-password-goes-here +sentinel monitor gitlab-redis 10.0.0.1 6379 2 +sentinel down-after-milliseconds gitlab-redis 10000 +sentinel failover_timeout 30000 +``` + +Sentinel 3 - `sentinel.conf` + +```conf +bind 10.0.0.3 +port 26379 +sentinel auth-pass gitlab-redis redis-password-goes-here +sentinel monitor gitlab-redis 10.0.0.1 6379 2 +sentinel down-after-milliseconds gitlab-redis 10000 +sentinel failover_timeout 30000 +``` + +## Troubleshooting + +We have a more detailed [Troubleshooting](redis.md#troubleshooting) explained in the documentation for Omnibus +Install. Here we will list only the things that are specific to a **Source** install. + +If you get an error in GitLab like: `Redis::CannotConnectError: No sentinels available.`, +there may be something wrong with your configuration files or it can be related +to [this issue][gh-531]. + +It's a bit non-intuitive the way you have to config `resque.yml` and +`sentinel.conf`, otherwise `redis-rb` will not work properly. + +The `master-group-name` ('gitlab-redis') defined in (`sentinel.conf`) +**must** be used as the hostname in GitLab (`resque.yml`): + +```conf +# sentinel.conf: +sentinel monitor gitlab-redis 10.0.0.1 6379 2 +sentinel down-after-milliseconds gitlab-redis 10000 +sentinel config-epoch gitlab-redis 0 +sentinel leader-epoch gitlab-redis 0 +``` + +```yaml +# resque.yaml +production: + url: redis://:myredispassword@gitlab-redis/ + sentinels: + - + host: 10.0.0.1 + port: 26379 # point to sentinel, not to redis port + - + host: 10.0.0.2 + port: 26379 # point to sentinel, not to redis port + - + host: 10.0.0.3 + port: 26379 # point to sentinel, not to redis port +``` + +When in doubt, please read [Redis Sentinel documentation](http://redis.io/topics/sentinel) -- cgit v1.2.3 From 1e4f86744627fbf0d0190c7d76f30cd77480db37 Mon Sep 17 00:00:00 2001 From: Gabriel Mazetto Date: Thu, 10 Nov 2016 07:07:30 +0100 Subject: Remade documentation for Redis HA with Omnibus --- doc/administration/high_availability/redis.md | 648 +++++++++++++++------ .../high_availability/redis_source.md | 14 +- 2 files changed, 480 insertions(+), 182 deletions(-) (limited to 'doc/administration') diff --git a/doc/administration/high_availability/redis.md b/doc/administration/high_availability/redis.md index f49bf1d4ab5..6b16f9e791f 100644 --- a/doc/administration/high_availability/redis.md +++ b/doc/administration/high_availability/redis.md @@ -1,9 +1,14 @@ # Configuring Redis for GitLab HA -You can choose to install and manage Redis yourself, or you can use the one +High Availability with Redis is possible using a **Master** x **Slave** +topology with **Sentinel** service to watch and automatically start +failover proceedings. + +You can choose to install and manage Redis and Sentinel yourself, use +a hosted, managed clouse solution or you can use or you can use the one that comes bundled with Omnibus GitLab packages. -> **Note:** Redis does not require authentication by default. See +> **Note:** Redis requires authentication for High Availability. See [Redis Security](http://redis.io/topics/security) documentation for more information. We recommend using a combination of a Redis password and tight firewall rules to secure your Redis service. @@ -12,20 +17,26 @@ that comes bundled with Omnibus GitLab packages. **Table of Contents** -- [Configure your own Redis server](#configure-your-own-redis-server) -- [Configure Redis using Omnibus](#configure-redis-using-omnibus) -- [Experimental Redis Sentinel support](#experimental-redis-sentinel-support) -- [Redis Sentinel support](#redis-sentinel-support) +- [Using an external Redis server](#using-an-external-redis-server) +- [High Availability with Sentinel](#high-availability-with-sentinel) - [Prerequisites](#prerequisites) - [Redis setup](#redis-setup) - - [Existing single-machine installation](#existing-single-machine-installation) - - [Omnibus packages](#omnibus-packages) - - [Configuring Sentinel](#configuring-sentinel) - - [How sentinel handles a failover](#how-sentinel-handles-a-failover) - - [Sentinel setup](#sentinel-setup) + - [Experimental Redis Sentinel support](#experimental-redis-sentinel-support) + - [Sentinel setup](#sentinel-setup) + - [Recommended setup](#recommended-setup) +- [Configuring instances using Omnibus](#configuring-instances-using-omnibus) + - [Existing single-machine installation](#existing-single-machine-installation) + - [Configuring Master Redis instance](#configuring-master-redis-instance) + - [Configuring Slave Redis instances](#configuring-slave-redis-instances) + - [Configuring Sentinel instances](#configuring-sentinel-instances) - [Community Edition](#community-edition) - [Enterprise Edition](#enterprise-edition) - [GitLab setup](#gitlab-setup) +- [Example Configurations](#example-configurations) + - [Configuration for Redis Master](#configuration-for-redis-master) + - [Configuration for Redis Slave](#configuration-for-redis-slave) + - [Configuration for Sentinel (EE only)](#configuration-for-sentinel-ee-only) + - [Control running services](#control-running-services) - [Troubleshooting](#troubleshooting) - [Redis replication](#redis-replication) - [Sentinel](#sentinel) @@ -33,75 +44,57 @@ that comes bundled with Omnibus GitLab packages. -## Configure your own Redis server +## Using an external Redis server If you're hosting GitLab on a cloud provider, you can optionally use a managed service for Redis. For example, AWS offers a managed ElastiCache service that runs Redis. -## Configure Redis using Omnibus +Managed services can provide High Availability using their own proprietary +technology and provide a transparent proxy, which means that GitLab doesn't +need any additional change, or will use Sentinel and manage it for you. -If you don't want to bother setting up your own Redis server, you can use the -one bundled with Omnibus. In this case, you should disable all services except -Redis. +If your provider, uses Sentinel method, see [GitLab Setup](#gitlab-setup) +to understant where you need to provide the list of servers and credentials. -1. Download/install Omnibus GitLab using **steps 1 and 2** from - [GitLab downloads](https://about.gitlab.com/downloads). Do not complete other - steps on the download page. -1. Create/edit `/etc/gitlab/gitlab.rb` and use the following configuration. - Be sure to change the `external_url` to match your eventual GitLab front-end - URL: +If you want to setup Redis by yourself, without using Omnibus, you can +read our documentation: [Configuring Redis for GitLab HA (Source Install)](redis_source.md) - ```ruby - external_url 'https://gitlab.example.com' - - # Disable all services except Redis - redis['enable'] = true - bootstrap['enable'] = false - nginx['enable'] = false - postgresql['enable'] = false - gitlab_rails['enable'] = false - - # Redis configuration - redis['port'] = 6379 - redis['bind'] = '0.0.0.0' - redis['password'] = 'redis-password-goes-here' - ``` +## High Availability with Sentinel -1. Run `sudo gitlab-ctl reconfigure` to install and configure Redis. +> Since GitLab `8.11`, you can configure a list of Redis Sentinel servers that +will monitor a group of Redis servers to provide failover support. - > **Note**: This `reconfigure` step will result in some errors. - That's OK - don't be alarmed. +> With GitLab `8.14`, we bundled Redis Sentinel as part of Omnibus package and +improved the way you use and configure it. -1. Run `touch /etc/gitlab/skip-auto-migrations` to prevent database migrations - from running on upgrade. Only the primary GitLab application server should - handle migrations. +High Availability with Redis requires a few things: -## Experimental Redis Sentinel support +- Multiple Redis instances +- Run Redis in a **Master** x **Slave** topology +- Multiple Sentinel instances +- Application support and visiblity to all Sentinel and Redis instances - > Experimental Redis Sentinel support was [Introduced][ce-1877] in GitLab 8.11. - Starting with 8.14, Redis Sentinel is no longer experimental. - If you used with versions `< 8.14` before, please check the updated - documentation below. +Redis Sentinel can handle the most important tasks in a HA environment to help +keep servers online with minimal to no downtime: -## Redis Sentinel support +- Monitors **Master** and **Slaves** instances to see if they are available +- Promote a **Slave** to **Master** when the **Master** fails. +- Demote a **Master** to **Slave** when failed **Master** comes back online (to prevent + data-partitioning). +- Can be queried by clients to always connect to the current **Master** server. -Since GitLab 8.11, you can configure a list of Redis Sentinel servers that -will monitor a group of Redis servers to provide you with a standard failover -support. +When a **Master** fails to respond, it's the client responsability to handle timeout +and reconnect (querying a **Sentinel** for a new **Master**). To get a better understanding on how to correctly setup Sentinel, please read the [Redis Sentinel documentation](http://redis.io/topics/sentinel) first, as -failing to configure it correctly can lead to data loss. +failing to configure it correctly can lead to data loss, or can bring your +whole cluster down, invalidating the failover effort. -Redis Sentinel can handle the most important tasks in a HA environment to help -keep servers online with minimal to no downtime: - -- Monitors master and slave instances to see if they are available -- Promote a slave to master when the master fails. -- Demote a master to slave when failed master comes back online (to prevent - data-partitioning). -- Can be queried by clients to always connect to the correct master server. +This documentation will provide you with a minimal and a recommended topology +that can resist to some levels of failure. Usually the more Redis and Sentinel +instances you have provisioned, the better will be your availability. The configuration consists of three parts: @@ -112,44 +105,191 @@ The configuration consists of three parts: ### Prerequisites You need at least `3` independent machines: physical, or VMs running into -distinct physical machines. +distinct physical machines. They must be believed to fail in an +independent way. If you fail to provision the machines in that specific way, any issue with the shared environment can bring your entire setup down. -Read carefully how to configure those components below. +You also need to take in consideration the underlying network topology, +making sure you have redundant connectivity between Redis / Sentinel and +GitLab instances, otherwhise the networks will become a single point of +failure. + +Read carefully how to configure the components below. ### Redis setup -You must have at least `3` Redis servers: `1` Master, `2` Slaves, and they need to -be each in a independent machine (see explanation above). +You must have at least `3` Redis servers: `1` Master, `2` Slaves, and they +need to be each in a independent machine (see explanation above). -They should be configured the same way and with similar server specs, as -in a failover situation, any `Slave` can be elected as the new `Master` by +You can have additional Redis nodes, that will help survive a situation +where more nodes goes down. Whenever there is only `2` nodes online, a failover +will not be initiated. + +As an example, if you have `6` Redis nodes, a maximum of `3` can be +simultaneously down. + +Please note that there are different requirements for Sentinel nodes. +If you host them in the same Redis machines, you may need to take +that restrictions into consideration when calculating the ammount of +nodes to be provisioned. See [Sentinel setup](#sentinel-setup) +documentation for more information. + +All Redis nodes should be configured the same way and with similar server specs, as +in a failover situation, any **Slave** can be promoted as the new **Master** by the Sentinel servers. -With Sentinel, you must define a password to protect the access as both -Sentinel instances and other redis instances should be able to talk to +The replication requires authentication, so you need to define a password to +protect all Redis nodes and the Sentinels. They will all share the same +password, and all instances must be able to talk to each other over the network. -You'll need to define both `requirepass` and `masterauth` in all -nodes. At any time during a failover the Sentinels can reconfigure a node -and change it's status from `Master` to `Slave` and vice versa. +Redis nodes will need the same password defined in `redis['password']` and +`redis['master_password']`, no matter if **Master** or **Slave**. At any time +during a failover the Sentinels can reconfigure a node and change it's status +from **Master** to **Slave** and vice versa. + +Initial **Slave** nodes requires `redis['master']` defined to `false` and +`redis['master_ip']` pointing to the initial **Master**. If you use the +simplified configuration by enabling `redis_slave_role['enable']`, you +just need to fill in the `redis['master_ip']`. + +This values doesn't have to be changed again in `/etc/gitlab/gitlab.rb` after +a failover, as the nodes will be managed by the Sentinels, and even after a +`gitlab-ctl reconfigure`, they will get their configuration restored by +the same Sentinels. + +### Experimental Redis Sentinel support + + > Experimental Redis Sentinel support was [Introduced][ce-1877] in GitLab 8.11. + Starting with 8.14, Redis Sentinel is no longer experimental. + If you used with versions `< 8.14` before, please check the updated + documentation here. + +### Sentinel setup + +Sentinels watches both other sentinels and Redis nodes. Whenever a Sentinel +detects that a Redis node is not responding, it will announce that to the +other sentinels. You have to reach the **quorum**, the minimum ammount of +sentinels that agrees that a node is down, to be able to start a failover. + +Whenver the **quorum** is met, you need the **majority** of all known +Sentinel nodes to be available and reachable, to elect the Sentinel **leader** +who will take all the decisions to restore the service availability by: + +- Promoting a new **Master** +- Reconfiguring the other **Slaves** and make them point to the new **Master** +- Announce the new **Master** to every other Sentinel peer +- Reconfigure the old **Master** and demote to **Slave** when it comes back online + +You must have at least `3` Redis Sentinel servers, and they need to +be each in a independent machine (that are believed to fail independently). + +You can configure them in the same machines where you've configured the other +Redis servers, but understand that if a whole node goes down, you loose both +a Sentinel and a Redis instance. -Initial `Slave` nodes require an additional `slaveof` setting in `redis.conf` -pointing to the initial `Master`. +The number of sentinels should ideally always be an **odd** number, for the +consensus algorithm to be effective in the case of a failure. -#### Existing single-machine installation +In a `3` nodes topology, you can only afford `1` Sentinel node going down. +Whenever the **majority** of the Sentinels goes down, the network partition +protection prevents destructive actions and a failover **will not be started**. + +Here are some examples: + +- With `5` or `6` sentinels, a maximum of `2` can go down for a failover begin. +- With `7` sentinels, a maximum of `3` nodes can go down. + +The **Leader** election can sometimes fail the voting round when **consensus**, +is not achieved (see the odd number of nodes requirement above). In that case, +a new attempt will be made after the amount of time defined in +`sentinel['failover_timeout']` (in milliseconds). + +The `failover_time` variable have a lot of different usages, according to +official documentation: + +- The time needed to re-start a failover after a previous failover was + already tried against the same master by a given Sentinel, is two + times the failover timeout. + +- The time needed for a slave replicating to a wrong master according + to a Sentinel current configuration, to be forced to replicate + with the right master, is exactly the failover timeout (counting since + the moment a Sentinel detected the misconfiguration). + +- The time needed to cancel a failover that is already in progress but + did not produced any configuration change (SLAVEOF NO ONE yet not + acknowledged by the promoted slave). + +- The maximum time a failover in progress waits for all the slaves to be + reconfigured as slaves of the new master. However even after this time + the slaves will be reconfigured by the Sentinels anyway, but not with + the exact parallel-syncs progression as specified. + +### Recommended setup + +For a minimal setup, you will install the Omnibus GitLab package in `3` +independent machines, both with **Redis** and **Sentinel**: + +- Redis Master + Sentinel +- Redis Slave + Sentinel +- Redis Slave + Sentinel + +Make sure you've read [Redis Setup](#redis-setup) and [Sentinel Setup](#sentinel-setup) +before, to understant how and why the ammount of nodes came from. + +For a recommended setup, that can resist more failures, you will install +the Omnibus GitLab package in `5` independent machines, both with +**Redis** and **Sentinel**: + +- Redis Master + Sentinel +- Redis Slave + Sentinel +- Redis Slave + Sentinel +- Redis Slave + Sentinel +- Redis Slave + Sentinel + +## Configuring instances using Omnibus + +This is a summary of what are we going to do: + +1. Provision the required number of instances specified previously + - You can opt to install Redis and Sentinel in the same machine or each in + independent ones. + - Don't install Redis and Sentinel in the same machines your GitLab instance + is running on. + - All machines must be able to talk to each other and accept incomming + connection over Redis (`6379`) and Sentinel (`26379`) ports. + - GitLab machines must be able to access these machines and with the same + permissions. + - Protected them from indiscriminated access from external networks (Internet), + to harden the security. + +1. Download/install Omnibus GitLab using **steps 1 and 2** from + [GitLab downloads](https://about.gitlab.com/downloads) in each node. + - Do not complete other steps on the download page. + - Make sure you select the correct Omnibus package, with the same version + and type (Community, Enterprise editions) of your current install. + +1. Run `touch /etc/gitlab/skip-auto-migrations` to prevent database migrations + from running on upgrade. Only the primary GitLab application server should + handle migrations. + +1. Create/edit `/etc/gitlab/gitlab.rb` and make the changes based on the + [Example Configurations](#example-configurations). + +### Existing single-machine installation If you already have a single-machine GitLab install running, you will need to replicate from this machine first, before de-activating the Redis instance inside it. -Your single-machine install will be the initial `Master`, and the `3` others -should be configured as `Slave` pointing to this machine. +Your single-machine install will be the initial **Master**, and the `3` others +should be configured as **Slave** pointing to this machine. After replication catchs-up, you will need to stop services in the -single-machine install, to rotate the `Master` to one of the new nodes. +single-machine install, to rotate the **Master** to one of the new nodes. Make the required changes in configuration and restart the new nodes again. @@ -159,130 +299,317 @@ To disable redis in the single install, edit `/etc/gitlab/gitlab.rb`: redis['enable'] = false ``` -#### Omnibus packages +If you fail to replicate first, you may loose data (unprocessed background jobs). + +### Configuring Master Redis instance + +You will need to configure the following in `/etc/gitlab/gitlab.rb`: + +1. Define `redis_master_role['enable']` to `true`, to disable other services + in the machine (you can still enable Sentinel) + +1. Define a `redis['bind']` address pointing to a local IP that your other machines + can reach you. + - If you really need to bind to an external acessible IP, make + sure you add extra firewall rules to prevent unauthorized access. + - You can also set bind to `0.0.0.0` which listen in all interfaces. + +1. Define a `redis['port']` so redis can listen for TCP requests which will + allow other machines to connect to it. + +1. Set up a password authentication with `redis['password']` and + `redis['master_password']` (use the same password in all nodes). + +Reconfigure Omnibus GitLab for the changes to take effect: `sudo gitlab-ctl reconfigure` -You need to install the Omnibus GitLab package in `3` independent machines. +### Configuring Slave Redis instances -**Configuring Master Redis instance** +You will need to configure the following in `/etc/gitlab/gitlab.rb`: -You will need to configure the following: +1. Define `redis_slaves_role['enable']` to `true`, to disable other services + in the machine (you can still enable Sentinel) + - This will also set automatically `redis['master'] = false`. 1. Define a `redis['bind']` address pointing to a local IP that your other machines - can reach you. If you really need to bind to an external acessible IP, make + can reach you. + - If you really need to bind to an external acessible IP, make sure you add extra firewall rules to prevent unauthorized access. + - You can also set bind to `0.0.0.0` which listen in all interfaces. + 1. Define a `redis['port']` so redis can listen for TCP requests which will allow other machines to connect to it. -1. Set up a password authentication with `redis['master_password']` (use the same - password in all nodes). + +1. Set up a password authentication with `redis['password']` and + `redis['master_password']` (use the same password in all nodes). + +1. Define `redis['master_ip']` with the IP of the **Master** Redis. + +1. Define `redis['master_port']` with the port of the **Master** Redis (default to `6379`). + +### Configuring Sentinel instances + +Now that the Redis servers are all set up, let's configure the Sentinel +servers. + +If you are not sure if your Redis servers are working and replicating +correctly, please read the [Troubleshooting Replication](#troubleshooting-replication) +and fix it before proceeding with Sentinel setup. + +You must have at least `3` Redis Sentinel servers, and they need to +be each in a independent machine. You can configure them in the same +machines where you've configured the other Redis servers. + +##### Community Edition + +With GitLab Community Edition, you need to install, configure, execute and +monitor Sentinel from source. Omnibus GitLab Community Edition package does +not support Sentinel configuration. + +See [documentation for Source Install](redis_source.md). + +##### Enterprise Edition + +With GitLab Enterprise Edition, you can use Omnibus package to setup multiple +machines with Sentinel daemon. + +See [example configuration](#configuration-for-sentinel-ee-only) below. + +### GitLab setup + +The final part is to inform the main GitLab application server of the Redis +Sentinels servers and authentication credentials. + +You can enable or disable Sentinel support at any time in new or existing +installations. From the GitLab application perspective, all it requires is +the correct credentials for the Sentinel nodes. + +While it doesn't require a list of all Sentinel nodes, in case of a failure, +it needs to access at least one of listeds. + +>**Note:** +The following steps should be performed in the [GitLab application server](gitlab.md) +which ideally should not have Redis or Sentinels in the same machine for a HA setup. + +1. Edit `/etc/gitlab/gitlab.rb` and add/change the following lines: + + - `redis['master_name']` - this is the `master-group-name` from sentinel (default: `gitlab-redis`) + - `redis['master_password']` - the same password you've defined before for Redis and Sentinels + - `gitlab_rails['redis_sentinels']` - a list of sentinels with `host` and `port` + +1. [Reconfigure] GitLab for the changes to take effect. + +See [example configuration](#configuration-for-gitlab) below. + +## Example Configurations + +In this example we consider that all servers have an internal network +interface with IPs in the `10.0.0.x` range, and that they can connect +to each other using these IPs. + +In a real world usage, you would also setup firewall rules to prevent +unauthorized access from other machines, and block traffic from the +outside (Internet). + +We will use the same `3` nodes with **Redis** + **Sentinel** topology +discussed in [Redis Setup](#redis-setup) and [Sentinel Setup](#sentinel-setup) +documentation. + +Here is a list and description of each **machine** and the assigned **IP**: + +* `10.0.0.1`: Redis Master + Sentinel 1 +* `10.0.0.2`: Redis Slave 1 + Sentinel 2 +* `10.0.0.2`: Redis Slave 2 + Sentinel 3 + +Please note that after the initial configuration, if a failover is initiated +by the Sentinel nodes, the Redis nodes will be reconfigured and the **Master** +will change permanently (including in `redis.conf`) from one node to the other, +until a new failover is initiated again. + +The same thing will happen with `sentinel.conf` that will be overriten after the +initial execution, after any new sentinel node starts watching the **Master**, +or a failover promotes a different **Master** node. + +### Configuration for Redis Master + +**Example configation for Redis Master:** In `/etc/gitlab/gitlab.rb`: ```ruby -## Redis TCP support (will disable UNIX socket transport) -redis['bind'] = '0.0.0.0' # or specify an IP to bind to a single one +redis_master_role['enable'] = true + +redis['bind'] = '10.0.0.1' redis['port'] = 6379 redis['password'] = 'redis-password-goes-here' redis['master_password'] = 'redis-password-goes-here' ``` - Reconfigure Omnibus GitLab for the changes to take effect: `sudo gitlab-ctl reconfigure` -**Configuring Slave Redis instances** +### Configuration for Redis Slave + +**Example configation for Slave 1:** -You need to make the same changes listed for the `Master` instance, -with an additional `Slave` section as in the example below: +In `/etc/gitlab/gitlab.rb`: ```ruby -redis['bind'] = '0.0.0.0' # or specify an IP to bind to a single one +redis_slave_role['enable'] = true + +redis['bind'] = '10.0.0.2' redis['port'] = 6379 redis['password'] = 'redis-password-goes-here' redis['master_password'] = 'redis-password-goes-here' -## Slave redis instance -redis['master'] = false -redis['master_ip'] = '10.10.10.10' # IP of master Redis server -redis['master_port'] = 6379 # Port of master Redis server +redis['master_ip'] = '10.0.0.1' # IP of master Redis server +#redis['master_port'] = 6379 # Port of master Redis server, uncomment to change to non default ``` Reconfigure Omnibus GitLab for the changes to take effect: `sudo gitlab-ctl reconfigure` ---- - -Now that the Redis servers are all set up, let's configure the Sentinel -servers. +**Example configation for Slave 2:** -If you are not sure if your Redis servers are working and replicating -correctly, please read the [Troubleshooting Replication](#troubleshooting-replication) -and fix it before proceeding with Sentinel setup. +In `/etc/gitlab/gitlab.rb`: -### Configuring Sentinel +```ruby +redis_slave_role['enable'] = true -You must have at least `3` Redis Sentinel servers, and they need to -be each in a independent machine. You can configure them in the same -machines where you've configured the other Redis servers. +redis['bind'] = '10.0.0.3' +redis['port'] = 6379 +redis['password'] = 'redis-password-goes-here' +redis['master_password'] = 'redis-password-goes-here' -This number is required for the consensus algorithm to be effective -in the case of a failure. **You should always have an `odd` number -of Sentinel nodes provisioned**. +redis['master_ip'] = '10.0.0.1' # IP of master Redis server +#redis['master_port'] = 6379 # Port of master Redis server, uncomment to change to non default +``` -#### How sentinel handles a failover +Reconfigure Omnibus GitLab for the changes to take effect: `sudo gitlab-ctl reconfigure` -If (`quorum` value of) Sentinels agree the fact the `master` is not reachable, -Sentinels will try to elect a temporary `Leader`. The **Majority** of the -Sentinels must agree to start a failover. +### Configuration for Sentinel (EE only) -If you don't have the **Majority** of the Sentinels online (for example if you -are under a network partitioning), a failover **will not be started**. +Please note that some of the variables are already configured previously +as they are required for Redis replication. -For example, for a cluster of `3` Sentinels, at least `2` must agree on a -`Leader`. If you have total of `5` at least `3` must agree on a `Leader`. +**Example configation for Sentinel 1:** -The `quorum` is only used to detect failure, not to elect the `Leader`. +In `/etc/gitlab/gitlab.rb`: -Official [Sentinel documentation](http://redis.io/topics/sentinel#example-sentinel-deployments) -also lists different network topologies and warns againts situations like -network partition and how it can affect the state of the HA solution. Make -sure you read it carefully and understand the implications in your current -setup. +```ruby +redis_sentinel_role['enable'] = true -GitLab Enterprise Edition provides [automated way to setup and run](#sentinel-setup-ee-only) the Sentinel daemon. +redis['master_name'] = 'gitlab-redis' # must be the same in every sentinel node +redis['master_ip'] = '10.0.0.1' # ip of the initial master redis instance +#redis['master_port'] = 6379 # port of the initial master redis instance, uncomment to change to non default +redis['master_password'] = 'redis-password-goes-here' # the same value defined in redis['password'] in the master instance -#### Sentinel setup +## Configure Sentinel +sentinel['bind'] = '10.0.0.1' +# sentinel['port'] = 26379 # uncomment to change default port -##### Community Edition +## Quorum must reflect the amount of voting sentinels it take to start a failover. +## Value must NOT be greater then the ammount of sentinels. +## +## The quorum can be used to tune Sentinel in two ways: +## 1. If a the quorum is set to a value smaller than the majority of Sentinels +## we deploy, we are basically making Sentinel more sensible to master failures, +## triggering a failover as soon as even just a minority of Sentinels is no longer +## able to talk with the master. +## 1. If a quorum is set to a value greater than the majority of Sentinels, we are +## making Sentinel able to failover only when there are a very large number (larger +## than majority) of well connected Sentinels which agree about the master being down.s +sentinel['quorum'] = 2 -With GitLab Community Edition, you need to install, configure, execute and -monitor Sentinel from source. Omnibus GitLab Community Edition package does -not support Sentinel configuration. +## Consider unresponsive server down after x amount of ms. +# sentinel['down_after_milliseconds'] = 10000 -See documentation for Source Install [here](redis_source.md). +## Specifies the failover timeout in milliseconds. It is used in many ways: +## +## - The time needed to re-start a failover after a previous failover was +## already tried against the same master by a given Sentinel, is two +## times the failover timeout. +## +## - The time needed for a slave replicating to a wrong master according +## to a Sentinel current configuration, to be forced to replicate +## with the right master, is exactly the failover timeout (counting since +## the moment a Sentinel detected the misconfiguration). +## +## - The time needed to cancel a failover that is already in progress but +## did not produced any configuration change (SLAVEOF NO ONE yet not +## acknowledged by the promoted slave). +## +## - The maximum time a failover in progress waits for all the slaves to be +## reconfigured as slaves of the new master. However even after this time +## the slaves will be reconfigured by the Sentinels anyway, but not with +## the exact parallel-syncs progression as specified. +# sentinel['failover_timeout'] = 60000 +``` -##### Enterprise Edition +**Example configation for Sentinel 2:** -To setup sentinel, edit `/etc/gitlab/gitlab.rb` file: +In `/etc/gitlab/gitlab.rb`: ```ruby +redis_sentinel_role['enable'] = true -## When you install Sentinel in a separate machine, you need to control which -## other services will be running in it. -## We've simplified the choice using special "roles" settings: +redis['master_name'] = 'gitlab-redis' # must be the same in every sentinel node +redis['master_ip'] = '10.0.0.1' # ip of the initial master redis instance +#redis['master_port'] = 6379 # port of the initial master redis instance, uncomment to change to non default +redis['master_password'] = 'redis-password-goes-here' # the same value defined in redis['password'] in the master instance -## Enabled Sentinel and Redis Master services -redis_sentinel_role['enable'] = true -redis_master_role['enable'] = true +## Configure Sentinel +sentinel['bind'] = '10.0.0.2' +# sentinel['port'] = 26379 # uncomment to change default port + +## Quorum must reflect the amount of voting sentinels it take to start a failover. +## Value must NOT be greater then the ammount of sentinels. +## +## The quorum can be used to tune Sentinel in two ways: +## 1. If a the quorum is set to a value smaller than the majority of Sentinels +## we deploy, we are basically making Sentinel more sensible to master failures, +## triggering a failover as soon as even just a minority of Sentinels is no longer +## able to talk with the master. +## 1. If a quorum is set to a value greater than the majority of Sentinels, we are +## making Sentinel able to failover only when there are a very large number (larger +## than majority) of well connected Sentinels which agree about the master being down.s +sentinel['quorum'] = 2 -## Enabled Sentinel and Redis Slave services +## Consider unresponsive server down after x amount of ms. +# sentinel['down_after_milliseconds'] = 10000 + +## Specifies the failover timeout in milliseconds. It is used in many ways: +## +## - The time needed to re-start a failover after a previous failover was +## already tried against the same master by a given Sentinel, is two +## times the failover timeout. +## +## - The time needed for a slave replicating to a wrong master according +## to a Sentinel current configuration, to be forced to replicate +## with the right master, is exactly the failover timeout (counting since +## the moment a Sentinel detected the misconfiguration). +## +## - The time needed to cancel a failover that is already in progress but +## did not produced any configuration change (SLAVEOF NO ONE yet not +## acknowledged by the promoted slave). +## +## - The maximum time a failover in progress waits for all the slaves to be +## reconfigured as slaves of the new master. However even after this time +## the slaves will be reconfigured by the Sentinels anyway, but not with +## the exact parallel-syncs progression as specified. +# sentinel['failover_timeout'] = 60000 +``` + +**Example configation for Sentinel 3:** + +In `/etc/gitlab/gitlab.rb`: + +```ruby redis_sentinel_role['enable'] = true -redis_slave_role['enable'] = true -## Configure Redis redis['master_name'] = 'gitlab-redis' # must be the same in every sentinel node redis['master_ip'] = '10.0.0.1' # ip of the initial master redis instance -redis['master_port'] = 6379 # port of the initial master redis instance +#redis['master_port'] = 6379 # port of the initial master redis instance, uncomment to change to non default redis['master_password'] = 'redis-password-goes-here' # the same value defined in redis['password'] in the master instance ## Configure Sentinel -# sentinel['bind'] = '0.0.0.0' # bind to all interfaces, uncomment to specify an IP and bind to a single one +sentinel['bind'] = '10.0.0.3' # sentinel['port'] = 26379 # uncomment to change default port ## Quorum must reflect the amount of voting sentinels it take to start a failover. @@ -323,6 +650,8 @@ sentinel['quorum'] = 2 # sentinel['failover_timeout'] = 60000 ``` +### Control running services + In the example above we've used `redis_sentinel_role` and `redis_master_role` which simplify the ammount of configuration changes. @@ -365,37 +694,6 @@ mailroom['enable'] = false # Redis Slave role also change this setting from default 'true' to 'false': redis['master'] = false ``` ---- - -The final part is to inform the main GitLab application server of the Redis -master and the new sentinels servers. - -### GitLab setup - -You can enable or disable Sentinel support at any time in new or existing -installations. From the GitLab application perspective, all it requires is -the correct credentials for the Sentinel nodes. - -While it doesn't require a list of all Sentinel nodes, in case of a failure, -it needs to access at one of listed ones. - ->**Note:** -The following steps should be performed in the [GitLab application server](gitlab.md) -which ideally should not have Redis or Sentinels in the same machine for a HA setup. - -1. Edit `/etc/gitlab/gitlab.rb` and add/change the following lines: - - ```ruby - redis['master_name'] = "gitlab-redis" - redis['master_password'] = 'redis-password-goes-here' - gitlab_rails['redis_sentinels'] = [ - {'host' => '10.10.10.1', 'port' => 26379}, - {'host' => '10.10.10.2', 'port' => 26379}, - {'host' => '10.10.10.3', 'port' => 26379} - ] - ``` - -1. [Reconfigure] GitLab for the changes to take effect. ## Troubleshooting diff --git a/doc/administration/high_availability/redis_source.md b/doc/administration/high_availability/redis_source.md index 7e8c8c2b4b9..ab5bb13f070 100644 --- a/doc/administration/high_availability/redis_source.md +++ b/doc/administration/high_availability/redis_source.md @@ -153,7 +153,7 @@ outside (Internet). We will use the same `3` nodes with **Redis** + **Sentinel** topology discussed in the [Configuring Redis for GitLab HA](redis.md) documentation. -Here is a list and description of each **machine** and the assined **ip**: +Here is a list and description of each **machine** and the assigned **IP**: * `10.0.0.1`: Redis Master + Sentinel 1 * `10.0.0.2`: Redis Slave 1 + Sentinel 2 @@ -170,7 +170,7 @@ or a failover promotes a different **Master** node. ### Configuring Redis Master -`redis.conf`: +**Example configation for Redis Master - `redis.conf`:** ```conf bind 10.0.0.1 @@ -181,7 +181,7 @@ masterauth redis-password-goes-here ### Configuring Redis Slaves -**Slave 1 - `redis.conf`:** +**Example configation for Slave 1 - `redis.conf`:** ```conf bind 10.0.0.2 @@ -193,7 +193,7 @@ masterauth redis-password-goes-here slaveof 10.0.0.1 6379 ``` -**Slave 2 - `redis.conf`:** +**Example configation for Slave 2 - `redis.conf`:** ```conf bind 10.0.0.3 @@ -211,7 +211,7 @@ For this example, **Sentinel 1** will be configured in the same machine as the **Redis Master**, **Sentinel 2** and **Sentinel 3** in the same machines as the **Slave 1** and **Slave 2** respectively. -Sentinel 1 - `sentinel.conf` +**Example configation for Sentinel 1 - `sentinel.conf`:** ```conf bind 10.0.0.1 @@ -222,7 +222,7 @@ sentinel down-after-milliseconds gitlab-redis 10000 sentinel failover_timeout 30000 ``` -Sentinel 2 - `sentinel.conf` +**Example configation for Sentinel 2 - `sentinel.conf`:** ```conf bind 10.0.0.2 @@ -233,7 +233,7 @@ sentinel down-after-milliseconds gitlab-redis 10000 sentinel failover_timeout 30000 ``` -Sentinel 3 - `sentinel.conf` +**Example configation for Sentinel 3 - `sentinel.conf`:** ```conf bind 10.0.0.3 -- cgit v1.2.3 From 646f81afac23b74b604c77af61254f90e205505f Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Thu, 10 Nov 2016 13:14:22 +0100 Subject: Fix typos of Redis sentinel docs --- doc/administration/high_availability/redis.md | 44 +++++++++++++-------------- 1 file changed, 22 insertions(+), 22 deletions(-) (limited to 'doc/administration') diff --git a/doc/administration/high_availability/redis.md b/doc/administration/high_availability/redis.md index 6b16f9e791f..ca773ea20aa 100644 --- a/doc/administration/high_availability/redis.md +++ b/doc/administration/high_availability/redis.md @@ -5,7 +5,7 @@ topology with **Sentinel** service to watch and automatically start failover proceedings. You can choose to install and manage Redis and Sentinel yourself, use -a hosted, managed clouse solution or you can use or you can use the one +a hosted, managed cloud solution or you can use or you can use the one that comes bundled with Omnibus GitLab packages. > **Note:** Redis requires authentication for High Availability. See @@ -55,10 +55,10 @@ technology and provide a transparent proxy, which means that GitLab doesn't need any additional change, or will use Sentinel and manage it for you. If your provider, uses Sentinel method, see [GitLab Setup](#gitlab-setup) -to understant where you need to provide the list of servers and credentials. +to understand where you need to provide the list of servers and credentials. If you want to setup Redis by yourself, without using Omnibus, you can -read our documentation: [Configuring Redis for GitLab HA (Source Install)](redis_source.md) +read our documentation: [Configuring Redis for GitLab HA (source install)](redis_source.md). ## High Availability with Sentinel @@ -73,19 +73,19 @@ High Availability with Redis requires a few things: - Multiple Redis instances - Run Redis in a **Master** x **Slave** topology - Multiple Sentinel instances -- Application support and visiblity to all Sentinel and Redis instances +- Application support and visibility to all Sentinel and Redis instances Redis Sentinel can handle the most important tasks in a HA environment to help keep servers online with minimal to no downtime: - Monitors **Master** and **Slaves** instances to see if they are available -- Promote a **Slave** to **Master** when the **Master** fails. +- Promote a **Slave** to **Master** when the **Master** fails - Demote a **Master** to **Slave** when failed **Master** comes back online (to prevent - data-partitioning). -- Can be queried by clients to always connect to the current **Master** server. + data-partitioning) +- Can be queried by clients to always connect to the current **Master** server -When a **Master** fails to respond, it's the client responsability to handle timeout -and reconnect (querying a **Sentinel** for a new **Master**). +When a **Master** fails to respond, it's the client's responsibility to handle +timeout and reconnect (querying a **Sentinel** for a new **Master**). To get a better understanding on how to correctly setup Sentinel, please read the [Redis Sentinel documentation](http://redis.io/topics/sentinel) first, as @@ -113,7 +113,7 @@ the shared environment can bring your entire setup down. You also need to take in consideration the underlying network topology, making sure you have redundant connectivity between Redis / Sentinel and -GitLab instances, otherwhise the networks will become a single point of +GitLab instances, otherwise the networks will become a single point of failure. Read carefully how to configure the components below. @@ -132,7 +132,7 @@ simultaneously down. Please note that there are different requirements for Sentinel nodes. If you host them in the same Redis machines, you may need to take -that restrictions into consideration when calculating the ammount of +that restrictions into consideration when calculating the amount of nodes to be provisioned. See [Sentinel setup](#sentinel-setup) documentation for more information. @@ -171,10 +171,10 @@ the same Sentinels. Sentinels watches both other sentinels and Redis nodes. Whenever a Sentinel detects that a Redis node is not responding, it will announce that to the -other sentinels. You have to reach the **quorum**, the minimum ammount of +other sentinels. You have to reach the **quorum**, the minimum amount of sentinels that agrees that a node is down, to be able to start a failover. -Whenver the **quorum** is met, you need the **majority** of all known +Whenever the **quorum** is met, you need the **majority** of all known Sentinel nodes to be available and reachable, to elect the Sentinel **leader** who will take all the decisions to restore the service availability by: @@ -238,7 +238,7 @@ independent machines, both with **Redis** and **Sentinel**: - Redis Slave + Sentinel Make sure you've read [Redis Setup](#redis-setup) and [Sentinel Setup](#sentinel-setup) -before, to understant how and why the ammount of nodes came from. +before, to understand how and why the amount of nodes came from. For a recommended setup, that can resist more failures, you will install the Omnibus GitLab package in `5` independent machines, both with @@ -259,11 +259,11 @@ This is a summary of what are we going to do: independent ones. - Don't install Redis and Sentinel in the same machines your GitLab instance is running on. - - All machines must be able to talk to each other and accept incomming + - All machines must be able to talk to each other and accept incoming connection over Redis (`6379`) and Sentinel (`26379`) ports. - GitLab machines must be able to access these machines and with the same permissions. - - Protected them from indiscriminated access from external networks (Internet), + - Protected them from indiscriminating access from external networks (Internet), to harden the security. 1. Download/install Omnibus GitLab using **steps 1 and 2** from @@ -288,7 +288,7 @@ inside it. Your single-machine install will be the initial **Master**, and the `3` others should be configured as **Slave** pointing to this machine. -After replication catchs-up, you will need to stop services in the +After replication catches up, you will need to stop services in the single-machine install, to rotate the **Master** to one of the new nodes. Make the required changes in configuration and restart the new nodes again. @@ -310,7 +310,7 @@ You will need to configure the following in `/etc/gitlab/gitlab.rb`: 1. Define a `redis['bind']` address pointing to a local IP that your other machines can reach you. - - If you really need to bind to an external acessible IP, make + - If you really need to bind to an external accessible IP, make sure you add extra firewall rules to prevent unauthorized access. - You can also set bind to `0.0.0.0` which listen in all interfaces. @@ -332,7 +332,7 @@ You will need to configure the following in `/etc/gitlab/gitlab.rb`: 1. Define a `redis['bind']` address pointing to a local IP that your other machines can reach you. - - If you really need to bind to an external acessible IP, make + - If you really need to bind to an external accessible IP, make sure you add extra firewall rules to prevent unauthorized access. - You can also set bind to `0.0.0.0` which listen in all interfaces. @@ -384,7 +384,7 @@ installations. From the GitLab application perspective, all it requires is the correct credentials for the Sentinel nodes. While it doesn't require a list of all Sentinel nodes, in case of a failure, -it needs to access at least one of listeds. +it needs to access at least one of the listed. >**Note:** The following steps should be performed in the [GitLab application server](gitlab.md) @@ -425,7 +425,7 @@ by the Sentinel nodes, the Redis nodes will be reconfigured and the **Master** will change permanently (including in `redis.conf`) from one node to the other, until a new failover is initiated again. -The same thing will happen with `sentinel.conf` that will be overriten after the +The same thing will happen with `sentinel.conf` that will be overridden after the initial execution, after any new sentinel node starts watching the **Master**, or a failover promotes a different **Master** node. @@ -653,7 +653,7 @@ sentinel['quorum'] = 2 ### Control running services In the example above we've used `redis_sentinel_role` and `redis_master_role` -which simplify the ammount of configuration changes. +which simplify the amount of configuration changes. If you want more control, here is what each one sets for you automatically when enabled: -- cgit v1.2.3 From c43b540095b6de03e679dc4dd56df97f08a6aed0 Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Thu, 10 Nov 2016 13:21:34 +0100 Subject: Move experimental heading at the bottom under changelog --- doc/administration/high_availability/redis.md | 59 +++++++++++++++------------ 1 file changed, 33 insertions(+), 26 deletions(-) (limited to 'doc/administration') diff --git a/doc/administration/high_availability/redis.md b/doc/administration/high_availability/redis.md index ca773ea20aa..3837a8a0a88 100644 --- a/doc/administration/high_availability/redis.md +++ b/doc/administration/high_availability/redis.md @@ -19,28 +19,29 @@ that comes bundled with Omnibus GitLab packages. - [Using an external Redis server](#using-an-external-redis-server) - [High Availability with Sentinel](#high-availability-with-sentinel) - - [Prerequisites](#prerequisites) - - [Redis setup](#redis-setup) - - [Experimental Redis Sentinel support](#experimental-redis-sentinel-support) - - [Sentinel setup](#sentinel-setup) - - [Recommended setup](#recommended-setup) + - [Prerequisites](#prerequisites) + - [Redis setup](#redis-setup) + - [Sentinel setup](#sentinel-setup) + - [Recommended setup](#recommended-setup) - [Configuring instances using Omnibus](#configuring-instances-using-omnibus) - - [Existing single-machine installation](#existing-single-machine-installation) - - [Configuring Master Redis instance](#configuring-master-redis-instance) - - [Configuring Slave Redis instances](#configuring-slave-redis-instances) - - [Configuring Sentinel instances](#configuring-sentinel-instances) - - [Community Edition](#community-edition) - - [Enterprise Edition](#enterprise-edition) - - [GitLab setup](#gitlab-setup) + - [Existing single-machine installation](#existing-single-machine-installation) + - [Configuring Master Redis instance](#configuring-master-redis-instance) + - [Configuring Slave Redis instances](#configuring-slave-redis-instances) + - [Configuring Sentinel instances](#configuring-sentinel-instances) + - [Community Edition](#community-edition) + - [Enterprise Edition](#enterprise-edition) + - [GitLab setup](#gitlab-setup) - [Example Configurations](#example-configurations) - - [Configuration for Redis Master](#configuration-for-redis-master) - - [Configuration for Redis Slave](#configuration-for-redis-slave) - - [Configuration for Sentinel (EE only)](#configuration-for-sentinel-ee-only) - - [Control running services](#control-running-services) + - [Configuration for Redis Master](#configuration-for-redis-master) + - [Configuration for Redis Slave](#configuration-for-redis-slave) + - [Configuration for Sentinel (EE only)](#configuration-for-sentinel-ee-only) + - [Control running services](#control-running-services) - [Troubleshooting](#troubleshooting) - - [Redis replication](#redis-replication) - - [Sentinel](#sentinel) - - [Omnibus GitLab](#omnibus-gitlab) + - [Redis replication](#redis-replication) + - [Sentinel](#sentinel) + - [Omnibus GitLab](#omnibus-gitlab) +- [Changelog](#changelog) + - [Experimental Redis Sentinel support](#experimental-redis-sentinel-support) @@ -160,13 +161,6 @@ a failover, as the nodes will be managed by the Sentinels, and even after a `gitlab-ctl reconfigure`, they will get their configuration restored by the same Sentinels. -### Experimental Redis Sentinel support - - > Experimental Redis Sentinel support was [Introduced][ce-1877] in GitLab 8.11. - Starting with 8.14, Redis Sentinel is no longer experimental. - If you used with versions `< 8.14` before, please check the updated - documentation here. - ### Sentinel setup Sentinels watches both other sentinels and Redis nodes. Whenever a Sentinel @@ -815,6 +809,19 @@ To make sure your configuration is correct: You should see a different port after a few seconds delay (the failover/reconnect time). + +## Changelog + +Changes to Redis HA over time. + +### Experimental Redis Sentinel support + +> +Experimental Redis Sentinel support was [Introduced][ce-1877] in GitLab 8.11. +Starting with 8.14, Redis Sentinel is no longer experimental. +If you used with versions `< 8.14` before, please check the updated +documentation here. + --- Read more on high-availability configuration: -- cgit v1.2.3 From fb0dff6ea848f58a068030f93e8728ce0143c592 Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Thu, 10 Nov 2016 15:51:13 +0100 Subject: Move some things over --- doc/administration/high_availability/redis.md | 195 +++++++++++++++----------- 1 file changed, 112 insertions(+), 83 deletions(-) (limited to 'doc/administration') diff --git a/doc/administration/high_availability/redis.md b/doc/administration/high_availability/redis.md index 3837a8a0a88..5d4dfe22779 100644 --- a/doc/administration/high_availability/redis.md +++ b/doc/administration/high_availability/redis.md @@ -1,73 +1,105 @@ # Configuring Redis for GitLab HA -High Availability with Redis is possible using a **Master** x **Slave** -topology with **Sentinel** service to watch and automatically start -failover proceedings. +High Availability with [Redis] is possible using a **Master** x **Slave** +topology with a [Redis Sentinel][sentinel] service to watch and automatically +start failover proceedings. You can choose to install and manage Redis and Sentinel yourself, use -a hosted, managed cloud solution or you can use or you can use the one -that comes bundled with Omnibus GitLab packages. +a hosted cloud solution or you can use the one that comes bundled with +Omnibus GitLab packages. -> **Note:** Redis requires authentication for High Availability. See +> **Notes:** +- Redis requires authentication for High Availability. See [Redis Security](http://redis.io/topics/security) documentation for more information. We recommend using a combination of a Redis password and tight firewall rules to secure your Redis service. +- You are highly encouraged to read the [Redis Sentinel][sentinel] documentation + before configuring Redis HA with GitLab to fully understand the topology and + architecture. **Table of Contents** -- [Using an external Redis server](#using-an-external-redis-server) -- [High Availability with Sentinel](#high-availability-with-sentinel) - - [Prerequisites](#prerequisites) - - [Redis setup](#redis-setup) - - [Sentinel setup](#sentinel-setup) - - [Recommended setup](#recommended-setup) +- [Overview](#overview) + - [Available setups](#available-setups) + - [Using a non-Omnibus external Redis server](#using-a-non-omnibus-external-redis-server) + - [High Availability with Sentinel](#high-availability-with-sentinel) + - [Prerequisites](#prerequisites) + - [Recommended setup](#recommended-setup) +- [Redis HA configuration](#redis-ha-configuration) + - [Redis setup](#redis-setup) + - [Sentinel setup](#sentinel-setup) - [Configuring instances using Omnibus](#configuring-instances-using-omnibus) - - [Existing single-machine installation](#existing-single-machine-installation) - - [Configuring Master Redis instance](#configuring-master-redis-instance) - - [Configuring Slave Redis instances](#configuring-slave-redis-instances) - - [Configuring Sentinel instances](#configuring-sentinel-instances) - - [Community Edition](#community-edition) - - [Enterprise Edition](#enterprise-edition) - - [GitLab setup](#gitlab-setup) -- [Example Configurations](#example-configurations) - - [Configuration for Redis Master](#configuration-for-redis-master) - - [Configuration for Redis Slave](#configuration-for-redis-slave) - - [Configuration for Sentinel (EE only)](#configuration-for-sentinel-ee-only) - - [Control running services](#control-running-services) + - [Existing single-machine installation](#existing-single-machine-installation) + - [Configuring Master Redis instance](#configuring-master-redis-instance) + - [Configuring Slave Redis instances](#configuring-slave-redis-instances) + - [Configuring Sentinel instances](#configuring-sentinel-instances) + - [Community Edition](#community-edition) + - [Enterprise Edition](#enterprise-edition) + - [GitLab setup](#gitlab-setup) +- [Minimal example configuration with 1 master, 2 slaves and 3 sentinels](#minimal-example-configuration-with-1-master-2-slaves-and-3-sentinels) + - [Configuration for Redis Master](#configuration-for-redis-master) + - [Configuration for Redis Slave](#configuration-for-redis-slave) + - [Configuration for Sentinel (EE only)](#configuration-for-sentinel-ee-only) + - [Control running services](#control-running-services) - [Troubleshooting](#troubleshooting) - - [Redis replication](#redis-replication) - - [Sentinel](#sentinel) - - [Omnibus GitLab](#omnibus-gitlab) + - [Redis replication](#redis-replication) + - [Sentinel](#sentinel) + - [Omnibus GitLab](#omnibus-gitlab) - [Changelog](#changelog) - - [Experimental Redis Sentinel support](#experimental-redis-sentinel-support) + - [Experimental Redis Sentinel support](#experimental-redis-sentinel-support) -## Using an external Redis server + +## Overview + +Before diving into the details of setting up Redis and Redis Sentinel for HA, +make sure you read this section to better understand the underline architecture. + +### Available setups + +Based on your infrastructure setup, there are multiple ways to setup Redis HA +with GitLab. Omnibus GitLab packages have Redis and Redis Sentinel bundled with +them to save you the hassle to install it yourself. Pick the one that suits your +needs. + +- **Installations from source:** You need to install Redis and Redis Sentinel + yourself. Use the [Redis HA source install](redis_source.md) guide. +- **Omnibus Community Edition (CE):** Redis is bundled so you can use the + package with only the Redis service enabled (works for both master and slave + setups). +- **Omnibus Enterprise Edition (EE):** Both Redis and Redis Sentinel are bundled + in the Omnibus package so you can use only them to setup the whole Redis HA + infrastructure (master, slave and Sentinel). + +Note that with the Omnibus packages (both CE and EE), you can also use an +[external Redis server](#using-a-non-omnibus-external-redis-server). + +### Using a non-Omnibus external Redis server If you're hosting GitLab on a cloud provider, you can optionally use a managed service for Redis. For example, AWS offers a managed ElastiCache service that runs Redis. Managed services can provide High Availability using their own proprietary -technology and provide a transparent proxy, which means that GitLab doesn't -need any additional change, or will use Sentinel and manage it for you. +technology and provide a transparent proxy (which means that GitLab doesn't +need any additional change) or they will use Sentinel and manage it for you. -If your provider, uses Sentinel method, see [GitLab Setup](#gitlab-setup) +If your provider, uses Sentinel, see [GitLab Setup](#gitlab-setup) to understand where you need to provide the list of servers and credentials. If you want to setup Redis by yourself, without using Omnibus, you can -read our documentation: [Configuring Redis for GitLab HA (source install)](redis_source.md). - -## High Availability with Sentinel +read the documentation on [configuring Redis HA for source installs](redis_source.md). -> Since GitLab `8.11`, you can configure a list of Redis Sentinel servers that -will monitor a group of Redis servers to provide failover support. +### High Availability with Sentinel -> With GitLab `8.14`, we bundled Redis Sentinel as part of Omnibus package and -improved the way you use and configure it. +> +- Since GitLab `8.11`, you can configure a list of Redis Sentinel servers that + will monitor a group of Redis servers to provide failover support. +- With GitLab `8.14`, we bundled Redis Sentinel as part of Omnibus package and + improved the way you use and configure it. High Availability with Redis requires a few things: @@ -77,12 +109,12 @@ High Availability with Redis requires a few things: - Application support and visibility to all Sentinel and Redis instances Redis Sentinel can handle the most important tasks in a HA environment to help -keep servers online with minimal to no downtime: +keep servers online with minimal to no downtime. Redis Sentinel: - Monitors **Master** and **Slaves** instances to see if they are available -- Promote a **Slave** to **Master** when the **Master** fails -- Demote a **Master** to **Slave** when failed **Master** comes back online (to prevent - data-partitioning) +- Promotes a **Slave** to **Master** when the **Master** fails +- Demotes a **Master** to **Slave** when failed **Master** comes back online + (to prevent data-partitioning) - Can be queried by clients to always connect to the current **Master** server When a **Master** fails to respond, it's the client's responsibility to handle @@ -93,24 +125,16 @@ the [Redis Sentinel documentation](http://redis.io/topics/sentinel) first, as failing to configure it correctly can lead to data loss, or can bring your whole cluster down, invalidating the failover effort. -This documentation will provide you with a minimal and a recommended topology -that can resist to some levels of failure. Usually the more Redis and Sentinel -instances you have provisioned, the better will be your availability. - -The configuration consists of three parts: - -- Setup Redis Master and Slave nodes -- Setup Sentinel nodes -- Setup GitLab - ### Prerequisites You need at least `3` independent machines: physical, or VMs running into -distinct physical machines. They must be believed to fail in an -independent way. +distinct physical machines. It is essential that all master and Redis slaves +run in different machines. If you fail to provision the machines in that +specific way, any issue with the shared environment can bring your entire setup +down. -If you fail to provision the machines in that specific way, any issue with -the shared environment can bring your entire setup down. +It is OK to run a Sentinel along with a master or slave Redis instance. +No more than one though. You also need to take in consideration the underlying network topology, making sure you have redundant connectivity between Redis / Sentinel and @@ -119,6 +143,30 @@ failure. Read carefully how to configure the components below. +### Recommended setup + +For a minimal setup, you will install the Omnibus GitLab package in `3` +independent machines, both with **Redis** and **Sentinel**: + +- Redis Master + Sentinel +- Redis Slave + Sentinel +- Redis Slave + Sentinel + +Make sure you've read [Redis Setup](#redis-setup) and [Sentinel Setup](#sentinel-setup) +before, to understand how and why the amount of nodes came from. + +For a recommended setup, that can resist more failures, you will install +the Omnibus GitLab package in `5` independent machines, both with +**Redis** and **Sentinel**: + +- Redis Master + Sentinel +- Redis Slave + Sentinel +- Redis Slave + Sentinel +- Redis Slave + Sentinel +- Redis Slave + Sentinel + +## Redis HA configuration + ### Redis setup You must have at least `3` Redis servers: `1` Master, `2` Slaves, and they @@ -156,14 +204,14 @@ Initial **Slave** nodes requires `redis['master']` defined to `false` and simplified configuration by enabling `redis_slave_role['enable']`, you just need to fill in the `redis['master_ip']`. -This values doesn't have to be changed again in `/etc/gitlab/gitlab.rb` after +This values don't have to be changed again in `/etc/gitlab/gitlab.rb` after a failover, as the nodes will be managed by the Sentinels, and even after a `gitlab-ctl reconfigure`, they will get their configuration restored by the same Sentinels. ### Sentinel setup -Sentinels watches both other sentinels and Redis nodes. Whenever a Sentinel +Sentinels watch both other sentinels and Redis nodes. Whenever a Sentinel detects that a Redis node is not responding, it will announce that to the other sentinels. You have to reach the **quorum**, the minimum amount of sentinels that agrees that a node is down, to be able to start a failover. @@ -222,33 +270,12 @@ official documentation: the slaves will be reconfigured by the Sentinels anyway, but not with the exact parallel-syncs progression as specified. -### Recommended setup - -For a minimal setup, you will install the Omnibus GitLab package in `3` -independent machines, both with **Redis** and **Sentinel**: - -- Redis Master + Sentinel -- Redis Slave + Sentinel -- Redis Slave + Sentinel - -Make sure you've read [Redis Setup](#redis-setup) and [Sentinel Setup](#sentinel-setup) -before, to understand how and why the amount of nodes came from. - -For a recommended setup, that can resist more failures, you will install -the Omnibus GitLab package in `5` independent machines, both with -**Redis** and **Sentinel**: - -- Redis Master + Sentinel -- Redis Slave + Sentinel -- Redis Slave + Sentinel -- Redis Slave + Sentinel -- Redis Slave + Sentinel - ## Configuring instances using Omnibus This is a summary of what are we going to do: 1. Provision the required number of instances specified previously + - You can opt to install Redis and Sentinel in the same machine or each in independent ones. - Don't install Redis and Sentinel in the same machines your GitLab instance @@ -257,7 +284,7 @@ This is a summary of what are we going to do: connection over Redis (`6379`) and Sentinel (`26379`) ports. - GitLab machines must be able to access these machines and with the same permissions. - - Protected them from indiscriminating access from external networks (Internet), + - Protect them from access from external networks (Internet), to harden the security. 1. Download/install Omnibus GitLab using **steps 1 and 2** from @@ -394,7 +421,7 @@ which ideally should not have Redis or Sentinels in the same machine for a HA se See [example configuration](#configuration-for-gitlab) below. -## Example Configurations +## Minimal example configuration with 1 master, 2 slaves and 3 sentinels In this example we consider that all servers have an internal network interface with IPs in the `10.0.0.x` range, and that they can connect @@ -836,3 +863,5 @@ Read more on high-availability configuration: [reconfigure]: ../restart_gitlab.md#omnibus-gitlab-reconfigure [gh-531]: https://github.com/redis/redis-rb/issues/531 [gh-534]: https://github.com/redis/redis-rb/issues/534 +[redis]: http://redis.io/ +[sentinel]: http://redis.io/topics/sentinel -- cgit v1.2.3 From b575b00402da92d15f8edcaab702039e6e92eddc Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Thu, 10 Nov 2016 19:00:06 +0100 Subject: Rearrange sections in Sentinel docs [ci skip] --- doc/administration/high_availability/redis.md | 343 ++++++++++++++------------ 1 file changed, 181 insertions(+), 162 deletions(-) (limited to 'doc/administration') diff --git a/doc/administration/high_availability/redis.md b/doc/administration/high_availability/redis.md index 5d4dfe22779..3eaa0ffdcec 100644 --- a/doc/administration/high_availability/redis.md +++ b/doc/administration/high_availability/redis.md @@ -16,82 +16,67 @@ Omnibus GitLab packages. - You are highly encouraged to read the [Redis Sentinel][sentinel] documentation before configuring Redis HA with GitLab to fully understand the topology and architecture. +- This is the documentation for the Omnibus packages. For installations from + source, follow the [Redis HA source install](redis_source.md) guide. +- Redis Sentinel is bundled with Omnibus GitLab Enterprise Edition only. For the + Omnibus Community Edition and installations from source, follow the + [Redis HA source install](redis_source.md) guide. **Table of Contents** - [Overview](#overview) - - [Available setups](#available-setups) - - [Using a non-Omnibus external Redis server](#using-a-non-omnibus-external-redis-server) - - [High Availability with Sentinel](#high-availability-with-sentinel) - [Prerequisites](#prerequisites) + - [High Availability with Sentinel](#high-availability-with-sentinel) - [Recommended setup](#recommended-setup) + - [Available configuration setups](#available-configuration-setups) + - [Using a non-Omnibus external Redis server](#using-a-non-omnibus-external-redis-server) + - [Redis setup overview](#redis-setup-overview) + - [Sentinel setup overview](#sentinel-setup-overview) - [Redis HA configuration](#redis-ha-configuration) - - [Redis setup](#redis-setup) - - [Sentinel setup](#sentinel-setup) -- [Configuring instances using Omnibus](#configuring-instances-using-omnibus) - - [Existing single-machine installation](#existing-single-machine-installation) - - [Configuring Master Redis instance](#configuring-master-redis-instance) - - [Configuring Slave Redis instances](#configuring-slave-redis-instances) - - [Configuring Sentinel instances](#configuring-sentinel-instances) - - [Community Edition](#community-edition) - - [Enterprise Edition](#enterprise-edition) - - [GitLab setup](#gitlab-setup) + - [Configuring the Master Redis instance](#configuring-the-master-redis-instance) + - [Configuring the Slave Redis instances](#configuring-the-slave-redis-instances) + - [Configuring the Sentinel instances](#configuring-the-sentinel-instances) + - [Configuring the GitLab application](#configuring-the-gitlab-application) +- [Switching from an existing single-machine installation to Redis HA](#switching-from-an-existing-single-machine-installation-to-redis-ha) - [Minimal example configuration with 1 master, 2 slaves and 3 sentinels](#minimal-example-configuration-with-1-master-2-slaves-and-3-sentinels) - - [Configuration for Redis Master](#configuration-for-redis-master) - - [Configuration for Redis Slave](#configuration-for-redis-slave) - - [Configuration for Sentinel (EE only)](#configuration-for-sentinel-ee-only) + - [Configuration for Redis master](#configuration-for-redis-master) + - [Configuration for Redis slaves](#configuration-for-redis-slaves) + - [Configuration for Sentinels](#configuration-for-sentinels) +- [Advanced configuration](#advanced-configuration) - [Control running services](#control-running-services) - [Troubleshooting](#troubleshooting) - - [Redis replication](#redis-replication) - - [Sentinel](#sentinel) - - [Omnibus GitLab](#omnibus-gitlab) + - [Troubleshooting Redis replication](#troubleshooting-redis-replication) + - [Troubleshooting Sentinel](#troubleshooting-sentinel) - [Changelog](#changelog) - [Experimental Redis Sentinel support](#experimental-redis-sentinel-support) - ## Overview Before diving into the details of setting up Redis and Redis Sentinel for HA, -make sure you read this section to better understand the underline architecture. - -### Available setups - -Based on your infrastructure setup, there are multiple ways to setup Redis HA -with GitLab. Omnibus GitLab packages have Redis and Redis Sentinel bundled with -them to save you the hassle to install it yourself. Pick the one that suits your -needs. - -- **Installations from source:** You need to install Redis and Redis Sentinel - yourself. Use the [Redis HA source install](redis_source.md) guide. -- **Omnibus Community Edition (CE):** Redis is bundled so you can use the - package with only the Redis service enabled (works for both master and slave - setups). -- **Omnibus Enterprise Edition (EE):** Both Redis and Redis Sentinel are bundled - in the Omnibus package so you can use only them to setup the whole Redis HA - infrastructure (master, slave and Sentinel). - -Note that with the Omnibus packages (both CE and EE), you can also use an -[external Redis server](#using-a-non-omnibus-external-redis-server). +make sure you read this Overview section to better understand how the components +are tied together. -### Using a non-Omnibus external Redis server +### Prerequisites -If you're hosting GitLab on a cloud provider, you can optionally use a -managed service for Redis. For example, AWS offers a managed ElastiCache service -that runs Redis. +You need at least `3` independent machines: physical, or VMs running into +distinct physical machines. It is essential that all master and slaves Redis +instances run in different machines. If you fail to provision the machines in +that specific way, any issue with the shared environment can bring your entire +setup down. -Managed services can provide High Availability using their own proprietary -technology and provide a transparent proxy (which means that GitLab doesn't -need any additional change) or they will use Sentinel and manage it for you. +It is OK to run a Sentinel along with a master or slave Redis instance. +No more than one Sentinel in the same machine though. -If your provider, uses Sentinel, see [GitLab Setup](#gitlab-setup) -to understand where you need to provide the list of servers and credentials. +You also need to take in consideration the underlying network topology, +making sure you have redundant connectivity between Redis / Sentinel and +GitLab instances, otherwise the networks will become a single point of +failure. -If you want to setup Redis by yourself, without using Omnibus, you can -read the documentation on [configuring Redis HA for source installs](redis_source.md). +Read carefully how to configure the components below. ### High Availability with Sentinel @@ -108,12 +93,12 @@ High Availability with Redis requires a few things: - Multiple Sentinel instances - Application support and visibility to all Sentinel and Redis instances -Redis Sentinel can handle the most important tasks in a HA environment to help -keep servers online with minimal to no downtime. Redis Sentinel: +Redis Sentinel can handle the most important tasks in a HA environment and that's +to help keep servers online with minimal to no downtime. Redis Sentinel: - Monitors **Master** and **Slaves** instances to see if they are available - Promotes a **Slave** to **Master** when the **Master** fails -- Demotes a **Master** to **Slave** when failed **Master** comes back online +- Demotes a **Master** to **Slave** when the failed **Master** comes back online (to prevent data-partitioning) - Can be queried by clients to always connect to the current **Master** server @@ -122,41 +107,23 @@ timeout and reconnect (querying a **Sentinel** for a new **Master**). To get a better understanding on how to correctly setup Sentinel, please read the [Redis Sentinel documentation](http://redis.io/topics/sentinel) first, as -failing to configure it correctly can lead to data loss, or can bring your +failing to configure it correctly can lead to data loss or can bring your whole cluster down, invalidating the failover effort. -### Prerequisites - -You need at least `3` independent machines: physical, or VMs running into -distinct physical machines. It is essential that all master and Redis slaves -run in different machines. If you fail to provision the machines in that -specific way, any issue with the shared environment can bring your entire setup -down. - -It is OK to run a Sentinel along with a master or slave Redis instance. -No more than one though. - -You also need to take in consideration the underlying network topology, -making sure you have redundant connectivity between Redis / Sentinel and -GitLab instances, otherwise the networks will become a single point of -failure. - -Read carefully how to configure the components below. - ### Recommended setup For a minimal setup, you will install the Omnibus GitLab package in `3` -independent machines, both with **Redis** and **Sentinel**: +**independent** machines, both with **Redis** and **Sentinel**: - Redis Master + Sentinel - Redis Slave + Sentinel - Redis Slave + Sentinel -Make sure you've read [Redis Setup](#redis-setup) and [Sentinel Setup](#sentinel-setup) -before, to understand how and why the amount of nodes came from. +If you are not sure or don't understand why and where the amount of nodes come +from, read [Redis Setup](#redis-setup) and [Sentinel Setup](#sentinel-setup). -For a recommended setup, that can resist more failures, you will install -the Omnibus GitLab package in `5` independent machines, both with +For a recommended setup that can resist more failures, you will install +the Omnibus GitLab package in `5` **independent** machines, both with **Redis** and **Sentinel**: - Redis Master + Sentinel @@ -165,9 +132,42 @@ the Omnibus GitLab package in `5` independent machines, both with - Redis Slave + Sentinel - Redis Slave + Sentinel -## Redis HA configuration +### Available configuration setups + +Based on your infrastructure setup and how you have installed GitLab, there are +multiple ways to configure Redis HA. Omnibus GitLab packages have Redis and/or +Redis Sentinel bundled with them to save you the hassle to install them yourself. +Pick the one that suits your needs. + +- [Installations from source][source]: You need to install Redis and Sentinel + yourself. Use the [Redis HA source install](redis_source.md) guide. +- [Omnibus package Community Edition (CE)][ce]: Redis is bundled, so you can use the + package with only the Redis service enabled (works for both master and slave + setups). +- [Omnibus package Enterprise Edition (EE)][ee]: Both Redis and Sentinel are bundled, + so you can use the EE package to setup the whole Redis HA infrastructure + (master, slave and Sentinel). + +Note that if you have installed GitLab using the Omnibus packages (both CE and EE), +you can also use an [external Redis server](#using-a-non-omnibus-external-redis-server). + +### Using a non-Omnibus external Redis server + +If you're hosting GitLab on a cloud provider, you can optionally use a +managed service for Redis. For example, AWS offers a managed ElastiCache service +that runs Redis. + +Managed services can provide High Availability using their own proprietary +technology and provide a transparent proxy (which means that GitLab doesn't +need any additional change) or they will use Sentinel and manage it for you. + +If your provider uses Sentinel, see [GitLab Setup](#gitlab-setup) +to understand where you need to provide the list of servers and credentials. + +If you want to setup Redis by yourself, without using Omnibus, you can +read the documentation on [configuring Redis HA for source installs](redis_source.md). -### Redis setup +### Redis setup overview You must have at least `3` Redis servers: `1` Master, `2` Slaves, and they need to be each in a independent machine (see explanation above). @@ -194,22 +194,7 @@ protect all Redis nodes and the Sentinels. They will all share the same password, and all instances must be able to talk to each other over the network. -Redis nodes will need the same password defined in `redis['password']` and -`redis['master_password']`, no matter if **Master** or **Slave**. At any time -during a failover the Sentinels can reconfigure a node and change it's status -from **Master** to **Slave** and vice versa. - -Initial **Slave** nodes requires `redis['master']` defined to `false` and -`redis['master_ip']` pointing to the initial **Master**. If you use the -simplified configuration by enabling `redis_slave_role['enable']`, you -just need to fill in the `redis['master_ip']`. - -This values don't have to be changed again in `/etc/gitlab/gitlab.rb` after -a failover, as the nodes will be managed by the Sentinels, and even after a -`gitlab-ctl reconfigure`, they will get their configuration restored by -the same Sentinels. - -### Sentinel setup +### Sentinel setup overview Sentinels watch both other sentinels and Redis nodes. Whenever a Sentinel detects that a Redis node is not responding, it will announce that to the @@ -249,8 +234,11 @@ is not achieved (see the odd number of nodes requirement above). In that case, a new attempt will be made after the amount of time defined in `sentinel['failover_timeout']` (in milliseconds). -The `failover_time` variable have a lot of different usages, according to -official documentation: +>**Note:** +We will see where `sentinel['failover_timeout']` is defined later. + +The `failover_timeout` variable has a lot of different use cases, according to +the official documentation: - The time needed to re-start a failover after a previous failover was already tried against the same master by a given Sentinel, is two @@ -270,18 +258,29 @@ official documentation: the slaves will be reconfigured by the Sentinels anyway, but not with the exact parallel-syncs progression as specified. -## Configuring instances using Omnibus +## Redis HA configuration + +This is the section where we install and setup the new Redis instances. -This is a summary of what are we going to do: +>**Notes:** +- We assume that you install GitLab and all HA components from scratch. If you + already have it installed and running, read how to + [switch from a single-machine installation to Redis HA](#switching-from-an-existing-single-machine-installation-to-redis-ha). +- Redis nodes (both master and slaves) will need the same password defined in + `redis['password']` and `redis['master_password']`. At any time during a + failover the Sentinels can reconfigure a node and change its status + from master to slave and vice versa. -1. Provision the required number of instances specified previously +A summary of what are we going to do: +1. Provision the required number of instances specified previously: - You can opt to install Redis and Sentinel in the same machine or each in independent ones. - - Don't install Redis and Sentinel in the same machines your GitLab instance + - Don't install Redis and Sentinel in the same machines your GitLab application is running on. - All machines must be able to talk to each other and accept incoming - connection over Redis (`6379`) and Sentinel (`26379`) ports. + connections over Redis (`6379`) and Sentinel (`26379`) ports (unless you + change the default ports). - GitLab machines must be able to access these machines and with the same permissions. - Protect them from access from external networks (Internet), @@ -297,32 +296,10 @@ This is a summary of what are we going to do: from running on upgrade. Only the primary GitLab application server should handle migrations. -1. Create/edit `/etc/gitlab/gitlab.rb` and make the changes based on the +1. Edit `/etc/gitlab/gitlab.rb` and make the changes based on the [Example Configurations](#example-configurations). -### Existing single-machine installation - -If you already have a single-machine GitLab install running, you will need to -replicate from this machine first, before de-activating the Redis instance -inside it. - -Your single-machine install will be the initial **Master**, and the `3` others -should be configured as **Slave** pointing to this machine. - -After replication catches up, you will need to stop services in the -single-machine install, to rotate the **Master** to one of the new nodes. - -Make the required changes in configuration and restart the new nodes again. - -To disable redis in the single install, edit `/etc/gitlab/gitlab.rb`: - -```ruby -redis['enable'] = false -``` - -If you fail to replicate first, you may loose data (unprocessed background jobs). - -### Configuring Master Redis instance +### Configuring the Master Redis instance You will need to configure the following in `/etc/gitlab/gitlab.rb`: @@ -341,9 +318,9 @@ You will need to configure the following in `/etc/gitlab/gitlab.rb`: 1. Set up a password authentication with `redis['password']` and `redis['master_password']` (use the same password in all nodes). -Reconfigure Omnibus GitLab for the changes to take effect: `sudo gitlab-ctl reconfigure` +1. [Reconfigure Omnibus GitLab][reocnfigure] for the changes to take effect. -### Configuring Slave Redis instances +### Configuring the Slave Redis instances You will need to configure the following in `/etc/gitlab/gitlab.rb`: @@ -367,7 +344,22 @@ You will need to configure the following in `/etc/gitlab/gitlab.rb`: 1. Define `redis['master_port']` with the port of the **Master** Redis (default to `6379`). -### Configuring Sentinel instances +Initial **Slave** nodes require `redis['master']` defined to `false` and +`redis['master_ip']` pointing to the initial **Master**. If you use the +simplified configuration by enabling `redis_slave_role['enable']`, you +just need to fill in the `redis['master_ip']`. + +This values don't have to be changed again in `/etc/gitlab/gitlab.rb` after +a failover, as the nodes will be managed by the Sentinels, and even after a +`gitlab-ctl reconfigure`, they will get their configuration restored by +the same Sentinels. + +### Configuring the Sentinel instances + +>**Note:** +- Redis Sentinel is bundled with Omnibus GitLab Enterprise Edition only. For the + Omnibus Community Edition and installations from source, follow the + [Redis HA source install](redis_source.md) guide. Now that the Redis servers are all set up, let's configure the Sentinel servers. @@ -380,22 +372,12 @@ You must have at least `3` Redis Sentinel servers, and they need to be each in a independent machine. You can configure them in the same machines where you've configured the other Redis servers. -##### Community Edition - -With GitLab Community Edition, you need to install, configure, execute and -monitor Sentinel from source. Omnibus GitLab Community Edition package does -not support Sentinel configuration. - -See [documentation for Source Install](redis_source.md). - -##### Enterprise Edition - -With GitLab Enterprise Edition, you can use Omnibus package to setup multiple -machines with Sentinel daemon. +With GitLab Enterprise Edition, you can use the Omnibus package to setup multiple +machines with the Sentinel daemon. See [example configuration](#configuration-for-sentinel-ee-only) below. -### GitLab setup +### Configuring the GitLab application The final part is to inform the main GitLab application server of the Redis Sentinels servers and authentication credentials. @@ -409,7 +391,7 @@ it needs to access at least one of the listed. >**Note:** The following steps should be performed in the [GitLab application server](gitlab.md) -which ideally should not have Redis or Sentinels in the same machine for a HA setup. +which ideally should not have Redis or Sentinels on it for a HA setup. 1. Edit `/etc/gitlab/gitlab.rb` and add/change the following lines: @@ -417,10 +399,32 @@ which ideally should not have Redis or Sentinels in the same machine for a HA se - `redis['master_password']` - the same password you've defined before for Redis and Sentinels - `gitlab_rails['redis_sentinels']` - a list of sentinels with `host` and `port` -1. [Reconfigure] GitLab for the changes to take effect. +1. [Reconfigure Omnibus GitLab][reconfigure] for the changes to take effect. See [example configuration](#configuration-for-gitlab) below. +## Switching from an existing single-machine installation to Redis HA + +If you already have a single-machine GitLab install running, you will need to +replicate from this machine first, before de-activating the Redis instance +inside it. + +Your single-machine install will be the initial **Master**, and the `3` others +should be configured as **Slave** pointing to this machine. + +After replication catches up, you will need to stop services in the +single-machine install, to rotate the **Master** to one of the new nodes. + +Make the required changes in configuration and restart the new nodes again. + +To disable redis in the single install, edit `/etc/gitlab/gitlab.rb`: + +```ruby +redis['enable'] = false +``` + +If you fail to replicate first, you may loose data (unprocessed background jobs). + ## Minimal example configuration with 1 master, 2 slaves and 3 sentinels In this example we consider that all servers have an internal network @@ -428,7 +432,7 @@ interface with IPs in the `10.0.0.x` range, and that they can connect to each other using these IPs. In a real world usage, you would also setup firewall rules to prevent -unauthorized access from other machines, and block traffic from the +unauthorized access from other machines and block traffic from the outside (Internet). We will use the same `3` nodes with **Redis** + **Sentinel** topology @@ -450,7 +454,7 @@ The same thing will happen with `sentinel.conf` that will be overridden after th initial execution, after any new sentinel node starts watching the **Master**, or a failover promotes a different **Master** node. -### Configuration for Redis Master +### Configuration for Redis master **Example configation for Redis Master:** @@ -464,9 +468,10 @@ redis['port'] = 6379 redis['password'] = 'redis-password-goes-here' redis['master_password'] = 'redis-password-goes-here' ``` -Reconfigure Omnibus GitLab for the changes to take effect: `sudo gitlab-ctl reconfigure` -### Configuration for Redis Slave +[Reconfigure Omnibus GitLab][reconfigure] for the changes to take effect. + +### Configuration for Redis slaves **Example configation for Slave 1:** @@ -502,9 +507,14 @@ redis['master_ip'] = '10.0.0.1' # IP of master Redis server #redis['master_port'] = 6379 # Port of master Redis server, uncomment to change to non default ``` -Reconfigure Omnibus GitLab for the changes to take effect: `sudo gitlab-ctl reconfigure` +[Reconfigure Omnibus GitLab][reconfigure] for the changes to take effect. + +### Configuration for Sentinels -### Configuration for Sentinel (EE only) +>**Note:** +Redis Sentinel is bundled with Omnibus GitLab Enterprise Edition only. For the +Omnibus Community Edition and installations from source, follow the +[Redis HA source install](redis_source.md) guide. Please note that some of the variables are already configured previously as they are required for Redis replication. @@ -517,9 +527,9 @@ In `/etc/gitlab/gitlab.rb`: redis_sentinel_role['enable'] = true redis['master_name'] = 'gitlab-redis' # must be the same in every sentinel node +redis['master_password'] = 'redis-password-goes-here' # the same value defined in redis['password'] in the master instance redis['master_ip'] = '10.0.0.1' # ip of the initial master redis instance #redis['master_port'] = 6379 # port of the initial master redis instance, uncomment to change to non default -redis['master_password'] = 'redis-password-goes-here' # the same value defined in redis['password'] in the master instance ## Configure Sentinel sentinel['bind'] = '10.0.0.1' @@ -571,9 +581,9 @@ In `/etc/gitlab/gitlab.rb`: redis_sentinel_role['enable'] = true redis['master_name'] = 'gitlab-redis' # must be the same in every sentinel node +redis['master_password'] = 'redis-password-goes-here' # the same value defined in redis['password'] in the master instance redis['master_ip'] = '10.0.0.1' # ip of the initial master redis instance #redis['master_port'] = 6379 # port of the initial master redis instance, uncomment to change to non default -redis['master_password'] = 'redis-password-goes-here' # the same value defined in redis['password'] in the master instance ## Configure Sentinel sentinel['bind'] = '10.0.0.2' @@ -625,9 +635,9 @@ In `/etc/gitlab/gitlab.rb`: redis_sentinel_role['enable'] = true redis['master_name'] = 'gitlab-redis' # must be the same in every sentinel node +redis['master_password'] = 'redis-password-goes-here' # the same value defined in redis['password'] in the master instance redis['master_ip'] = '10.0.0.1' # ip of the initial master redis instance #redis['master_port'] = 6379 # port of the initial master redis instance, uncomment to change to non default -redis['master_password'] = 'redis-password-goes-here' # the same value defined in redis['password'] in the master instance ## Configure Sentinel sentinel['bind'] = '10.0.0.3' @@ -671,10 +681,15 @@ sentinel['quorum'] = 2 # sentinel['failover_timeout'] = 60000 ``` +## Advanced configuration + +Omnibus GitLab configures some things behind the curtains to make the sysadmins' +lives easier. If you want to know what happens underneath keep reading. + ### Control running services -In the example above we've used `redis_sentinel_role` and `redis_master_role` -which simplify the amount of configuration changes. +In the previous example above we've used `redis_sentinel_role` and +`redis_master_role` which simplify the amount of configuration changes. If you want more control, here is what each one sets for you automatically when enabled: @@ -716,13 +731,15 @@ mailroom['enable'] = false redis['master'] = false ``` +You can find the relevant attributes defined in [gitlab_rails.rb][omnifile]. + ## Troubleshooting There are a lot of moving parts that needs to be taken care carefully in order for the HA setup to work as expected. -Before proceeding with the troubleshooting below, check your firewall -rules: +Before proceeding with the troubleshooting below, check your firewall rules: + - Redis machines - Accept TCP connection in `6379` - Connect to the other Redis machines via TCP in `6379` @@ -731,7 +748,7 @@ rules: - Connect to other Sentinel machines via TCP in `26379` - Connect to the Redis machines via TCP in `6379` -### Redis replication +### Troubleshooting Redis replication You can check if everything is correct by connecting to each server using `redis-cli` application, and sending the `INFO` command. @@ -781,9 +798,7 @@ repl_backlog_first_byte_offset:0 repl_backlog_histlen:0 ``` -### Sentinel - -#### Omnibus GitLab +### Troubleshooting Sentinel If you get an error like: `Redis::CannotConnectError: No sentinels available.`, there may be something wrong with your configuration files or it can be related @@ -865,3 +880,7 @@ Read more on high-availability configuration: [gh-534]: https://github.com/redis/redis-rb/issues/534 [redis]: http://redis.io/ [sentinel]: http://redis.io/topics/sentinel +[omnifile]: https://gitlab.com/gitlab-org/omnibus-gitlab/blob/82b7345b150f072c8673c79738ce893f92d0d652/files/gitlab-cookbooks/gitlab/libraries/gitlab_rails.rb#L134-159 +[source]: ../../install/installation.md +[ce]: https://about.gitlab.com/downloads +[ee]: https://about.gitlab.com/downloads-ee -- cgit v1.2.3 From cc2bf503dbeb23561302bb77ff824e0c30a560b6 Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Fri, 11 Nov 2016 17:53:26 +0100 Subject: Add missing link to GH issue --- doc/administration/high_availability/redis_source.md | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) (limited to 'doc/administration') diff --git a/doc/administration/high_availability/redis_source.md b/doc/administration/high_availability/redis_source.md index ab5bb13f070..20630b070c0 100644 --- a/doc/administration/high_availability/redis_source.md +++ b/doc/administration/high_availability/redis_source.md @@ -8,7 +8,8 @@ If you are building packages for a specific distro, or trying to build some internal automation, you can check this documentation to learn about the minimal setup, required changes, etc. -If you want to see the documentation for Omnibus GitLab Install, please [read it here](redis.md). +If you want to see the documentation for Omnibus GitLab Install, please +[read it here](redis.md). @@ -38,7 +39,7 @@ You will also need to define equal password for slave password definition To configure Redis to use TCP connection you need to define both `bind` and `port`. You can bind to all interfaces (`0.0.0.0`) or specify the -ip of the desired interface (for ex. one from an internal network). +IP of the desired interface (for ex. one from an internal network). ### Configuring Master Redis instance @@ -46,7 +47,7 @@ ip of the desired interface (for ex. one from an internal network). You need to make the following changes in `redis.conf`: 1. Define a `bind` address pointing to a local IP that your other machines - can reach you. If you really need to bind to an external acessible IP, make + can reach you. If you really need to bind to an external accessible IP, make sure you add extra firewall rules to prevent unauthorized access: 1. Define a `port` to force redis to listen on TCP so other machines can @@ -79,7 +80,7 @@ starting with `sentinel` prefix. You will need to define the initial configs to enable connectivity: 1. Define a `bind` address pointing to a local IP that your other machines - can reach you. If you really need to bind to an external acessible IP, make + can reach you. If you really need to bind to an external accessible IP, make sure you add extra firewall rules to prevent unauthorized access: 1. Define a `port` to force sentinel to listen on TCP so other machines can @@ -95,7 +96,7 @@ And the sentinel specific ones: If you need more information to understand about quorum, please read the detailed explanation in the [HA documentation for Omnibus Installs](redis.md). -1. Define with `sentinel down-after-milliseconds` the ammount in `ms` of time +1. Define with `sentinel down-after-milliseconds` the amount in `ms` of time that an unresponsive server will be considered down. 1. Define a value for `sentinel failover_timeout` in `ms`. This has multiple @@ -164,7 +165,7 @@ by the Sentinel nodes, the Redis nodes will be reconfigured and the **Master** will change permanently (including in `redis.conf`) from one node to the other, until a new failover is initiated again. -The same thing will happen with `sentinel.conf` that will be overriten after the +The same thing will happen with `sentinel.conf` that will be overridden after the initial execution, after any new sentinel node starts watching the **Master**, or a failover promotes a different **Master** node. @@ -284,3 +285,5 @@ production: ``` When in doubt, please read [Redis Sentinel documentation](http://redis.io/topics/sentinel) + +[gh-531]: https://github.com/redis/redis-rb/issues/531 -- cgit v1.2.3 From 39a9af1594bf2365ba0da6457efef238d7e42e24 Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Tue, 15 Nov 2016 14:07:38 +0100 Subject: Swap HA setups --- doc/administration/high_availability/README.md | 33 +++++++++------- doc/administration/high_availability/redis.md | 54 +++++++++++++------------- 2 files changed, 45 insertions(+), 42 deletions(-) (limited to 'doc/administration') diff --git a/doc/administration/high_availability/README.md b/doc/administration/high_availability/README.md index d74a786ac24..d5a5aef7ec0 100644 --- a/doc/administration/high_availability/README.md +++ b/doc/administration/high_availability/README.md @@ -7,19 +7,10 @@ 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. +There are two kinds of setups: -Components/Servers Required: - -- 2 servers/virtual machines (one active/one passive) - -![Active/Passive HA Diagram](../img/high_availability/active-passive-diagram.png) +- active/active +- active/passive ### Active/Active @@ -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 if the database, Redis and storage are also configured as such. -![Active/Active HA Diagram](../img/high_availability/active-active-diagram.png) - -**Steps to configure active/active:** +Follow the steps below to configure an active/active setup: 1. [Configure the database](database.md) 1. [Configure Redis](redis.md) 1. [Configure NFS](nfs.md) 1. [Configure the GitLab application servers](gitlab.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) diff --git a/doc/administration/high_availability/redis.md b/doc/administration/high_availability/redis.md index 3eaa0ffdcec..bb46de65e3c 100644 --- a/doc/administration/high_availability/redis.md +++ b/doc/administration/high_availability/redis.md @@ -16,10 +16,10 @@ Omnibus GitLab packages. - You are highly encouraged to read the [Redis Sentinel][sentinel] documentation before configuring Redis HA with GitLab to fully understand the topology and architecture. -- This is the documentation for the Omnibus packages. For installations from - source, follow the [Redis HA source install](redis_source.md) guide. -- Redis Sentinel is bundled with Omnibus GitLab Enterprise Edition only. For the - Omnibus Community Edition and installations from source, follow the +- This is the documentation for the Omnibus GitLab packages. For installations + from source, follow the [Redis HA source install](redis_source.md) guide. +- Redis Sentinel daemon is bundled with Omnibus GitLab Enterprise Edition only. + For the Omnibus Community Edition and installations from source, follow the [Redis HA source install](redis_source.md) guide. @@ -50,7 +50,6 @@ Omnibus GitLab packages. - [Troubleshooting Redis replication](#troubleshooting-redis-replication) - [Troubleshooting Sentinel](#troubleshooting-sentinel) - [Changelog](#changelog) - - [Experimental Redis Sentinel support](#experimental-redis-sentinel-support) @@ -76,15 +75,16 @@ making sure you have redundant connectivity between Redis / Sentinel and GitLab instances, otherwise the networks will become a single point of failure. -Read carefully how to configure the components below. +Make sure that you read this document once as a whole before configuring the +components below. ### High Availability with Sentinel > -- Since GitLab `8.11`, you can configure a list of Redis Sentinel servers that - will monitor a group of Redis servers to provide failover support. -- With GitLab `8.14`, we bundled Redis Sentinel as part of Omnibus package and - improved the way you use and configure it. +- Starting with GitLab `8.11`, you can configure a list of Redis Sentinel + servers that will monitor a group of Redis servers to provide failover support. +- Starting with GitLab `8.14`, the Omnibus GitLab Enterprise Edition package + comes with Redis sentinel daemon support. High Availability with Redis requires a few things: @@ -136,20 +136,21 @@ the Omnibus GitLab package in `5` **independent** machines, both with Based on your infrastructure setup and how you have installed GitLab, there are multiple ways to configure Redis HA. Omnibus GitLab packages have Redis and/or -Redis Sentinel bundled with them to save you the hassle to install them yourself. +Redis Sentinel bundled with them so you only need to focus on configuration. Pick the one that suits your needs. - [Installations from source][source]: You need to install Redis and Sentinel - yourself. Use the [Redis HA source install](redis_source.md) guide. -- [Omnibus package Community Edition (CE)][ce]: Redis is bundled, so you can use the - package with only the Redis service enabled (works for both master and slave - setups). -- [Omnibus package Enterprise Edition (EE)][ee]: Both Redis and Sentinel are bundled, - so you can use the EE package to setup the whole Redis HA infrastructure - (master, slave and Sentinel). - -Note that if you have installed GitLab using the Omnibus packages (both CE and EE), -you can also use an [external Redis server](#using-a-non-omnibus-external-redis-server). + yourself. Use the [Redis HA installation from source](redis_source.md) guide. +- [Omnibus package Community Edition (CE) package][ce]: Redis is bundled, so you + can use the package with only the Redis service enabled (works for both master + and slave setups). To install and configure Sentinel, you can use the + [Redis HA installation from source](redis_source.md) guide. +- [Omnibus package Enterprise Edition (EE) package][ee]: Both Redis and Sentinel + are bundled, so you can use the EE package to setup the whole Redis HA + infrastructure (master, slave and Sentinel). + +Note that if you have installed GitLab using the Omnibus GitLab packages (both +CE and EE), you can also use an [external Redis server](#using-a-non-omnibus-external-redis-server). ### Using a non-Omnibus external Redis server @@ -198,7 +199,7 @@ each other over the network. Sentinels watch both other sentinels and Redis nodes. Whenever a Sentinel detects that a Redis node is not responding, it will announce that to the -other sentinels. You have to reach the **quorum**, the minimum amount of +other sentinels. They have to reach the **quorum**, the minimum amount of sentinels that agrees that a node is down, to be able to start a failover. Whenever the **quorum** is met, you need the **majority** of all known @@ -267,9 +268,8 @@ This is the section where we install and setup the new Redis instances. already have it installed and running, read how to [switch from a single-machine installation to Redis HA](#switching-from-an-existing-single-machine-installation-to-redis-ha). - Redis nodes (both master and slaves) will need the same password defined in - `redis['password']` and `redis['master_password']`. At any time during a - failover the Sentinels can reconfigure a node and change its status - from master to slave and vice versa. + `redis['password']`. At any time during a failover the Sentinels can + reconfigure a node and change its status from master to slave and vice versa. A summary of what are we going to do: @@ -354,7 +354,7 @@ a failover, as the nodes will be managed by the Sentinels, and even after a `gitlab-ctl reconfigure`, they will get their configuration restored by the same Sentinels. -### Configuring the Sentinel instances +### Configuring the Redis Sentinel instances >**Note:** - Redis Sentinel is bundled with Omnibus GitLab Enterprise Edition only. For the @@ -425,7 +425,7 @@ redis['enable'] = false If you fail to replicate first, you may loose data (unprocessed background jobs). -## Minimal example configuration with 1 master, 2 slaves and 3 sentinels +## Example of a minimal configuration with 1 master, 2 slaves and 3 sentinels In this example we consider that all servers have an internal network interface with IPs in the `10.0.0.x` range, and that they can connect -- cgit v1.2.3 From 9b70c09d07d180229501799f2d440191853aba57 Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Tue, 15 Nov 2016 16:08:53 +0100 Subject: Refactor Redis HA docs [ci skip] --- doc/administration/high_availability/redis.md | 547 +++++++++++++++----------- 1 file changed, 314 insertions(+), 233 deletions(-) (limited to 'doc/administration') diff --git a/doc/administration/high_availability/redis.md b/doc/administration/high_availability/redis.md index bb46de65e3c..6de92ae3741 100644 --- a/doc/administration/high_availability/redis.md +++ b/doc/administration/high_availability/redis.md @@ -17,10 +17,11 @@ Omnibus GitLab packages. before configuring Redis HA with GitLab to fully understand the topology and architecture. - This is the documentation for the Omnibus GitLab packages. For installations - from source, follow the [Redis HA source install](redis_source.md) guide. + from source, follow the [Redis HA source installation](redis_source.md) guide. - Redis Sentinel daemon is bundled with Omnibus GitLab Enterprise Edition only. - For the Omnibus Community Edition and installations from source, follow the - [Redis HA source install](redis_source.md) guide. + For configuring Sentinel with the Omnibus GitLab Community Edition and + installations from source, follow the + [Redis HA source installation](redis_source.md) guide. @@ -31,16 +32,15 @@ Omnibus GitLab packages. - [High Availability with Sentinel](#high-availability-with-sentinel) - [Recommended setup](#recommended-setup) - [Available configuration setups](#available-configuration-setups) - - [Using a non-Omnibus external Redis server](#using-a-non-omnibus-external-redis-server) - [Redis setup overview](#redis-setup-overview) - [Sentinel setup overview](#sentinel-setup-overview) -- [Redis HA configuration](#redis-ha-configuration) - - [Configuring the Master Redis instance](#configuring-the-master-redis-instance) - - [Configuring the Slave Redis instances](#configuring-the-slave-redis-instances) - - [Configuring the Sentinel instances](#configuring-the-sentinel-instances) - - [Configuring the GitLab application](#configuring-the-gitlab-application) +- [Configuring Redis HA](#configuring-redis-ha) + - [Step 1. Configuring the Master Redis instance](#step-1-configuring-the-master-redis-instance) + - [Step 2. Configuring the Slave Redis instances](#step-2-configuring-the-slave-redis-instances) + - [Step 3. Configuring the Redis Sentinel instances](#step-3-configuring-the-redis-sentinel-instances) + - [Step 4. Configuring the GitLab application](#step-4-configuring-the-gitlab-application) - [Switching from an existing single-machine installation to Redis HA](#switching-from-an-existing-single-machine-installation-to-redis-ha) -- [Minimal example configuration with 1 master, 2 slaves and 3 sentinels](#minimal-example-configuration-with-1-master-2-slaves-and-3-sentinels) +- [Example of a minimal configuration with 1 master, 2 slaves and 3 sentinels](#example-of-a-minimal-configuration-with-1-master-2-slaves-and-3-sentinels) - [Configuration for Redis master](#configuration-for-redis-master) - [Configuration for Redis slaves](#configuration-for-redis-slaves) - [Configuration for Sentinels](#configuration-for-sentinels) @@ -50,6 +50,7 @@ Omnibus GitLab packages. - [Troubleshooting Redis replication](#troubleshooting-redis-replication) - [Troubleshooting Sentinel](#troubleshooting-sentinel) - [Changelog](#changelog) + - [Experimental Redis Sentinel support](#experimental-redis-sentinel-support) @@ -59,8 +60,6 @@ Before diving into the details of setting up Redis and Redis Sentinel for HA, make sure you read this Overview section to better understand how the components are tied together. -### Prerequisites - You need at least `3` independent machines: physical, or VMs running into distinct physical machines. It is essential that all master and slaves Redis instances run in different machines. If you fail to provision the machines in @@ -84,16 +83,16 @@ components below. - Starting with GitLab `8.11`, you can configure a list of Redis Sentinel servers that will monitor a group of Redis servers to provide failover support. - Starting with GitLab `8.14`, the Omnibus GitLab Enterprise Edition package - comes with Redis sentinel daemon support. + comes with Redis Sentinel daemon support. High Availability with Redis requires a few things: - Multiple Redis instances -- Run Redis in a **Master** x **Slave** topology -- Multiple Sentinel instances + - Run Redis in a **Master** x **Slave** topology + - Multiple Sentinel instances - Application support and visibility to all Sentinel and Redis instances -Redis Sentinel can handle the most important tasks in a HA environment and that's +Redis Sentinel can handle the most important tasks in an HA environment and that's to help keep servers online with minimal to no downtime. Redis Sentinel: - Monitors **Master** and **Slaves** instances to see if they are available @@ -120,7 +119,8 @@ For a minimal setup, you will install the Omnibus GitLab package in `3` - Redis Slave + Sentinel If you are not sure or don't understand why and where the amount of nodes come -from, read [Redis Setup](#redis-setup) and [Sentinel Setup](#sentinel-setup). +from, read [Redis setup overview](#redis-setup-overview) and +[Sentinel setup overview](#sentinel-setup-overview). For a recommended setup that can resist more failures, you will install the Omnibus GitLab package in `5` **independent** machines, both with @@ -149,24 +149,9 @@ Pick the one that suits your needs. are bundled, so you can use the EE package to setup the whole Redis HA infrastructure (master, slave and Sentinel). -Note that if you have installed GitLab using the Omnibus GitLab packages (both -CE and EE), you can also use an [external Redis server](#using-a-non-omnibus-external-redis-server). - -### Using a non-Omnibus external Redis server - -If you're hosting GitLab on a cloud provider, you can optionally use a -managed service for Redis. For example, AWS offers a managed ElastiCache service -that runs Redis. - -Managed services can provide High Availability using their own proprietary -technology and provide a transparent proxy (which means that GitLab doesn't -need any additional change) or they will use Sentinel and manage it for you. - -If your provider uses Sentinel, see [GitLab Setup](#gitlab-setup) -to understand where you need to provide the list of servers and credentials. - -If you want to setup Redis by yourself, without using Omnibus, you can -read the documentation on [configuring Redis HA for source installs](redis_source.md). +Note that even if you have installed GitLab using the Omnibus GitLab packages +(both CE and EE), you can still use an +[external Redis server](#using-a-non-omnibus-external-redis-server). ### Redis setup overview @@ -197,13 +182,13 @@ each other over the network. ### Sentinel setup overview -Sentinels watch both other sentinels and Redis nodes. Whenever a Sentinel +Sentinels watch both other Sentinels and Redis nodes. Whenever a Sentinel detects that a Redis node is not responding, it will announce that to the -other sentinels. They have to reach the **quorum**, the minimum amount of -sentinels that agrees that a node is down, to be able to start a failover. +other Sentinels. They have to reach the **quorum**, that is the minimum amount +of Sentinels that agrees a node is down, in order to be able to start a failover. -Whenever the **quorum** is met, you need the **majority** of all known -Sentinel nodes to be available and reachable, to elect the Sentinel **leader** +Whenever the **quorum** is met, the **majority** of all known Sentinel nodes +need to be available and reachable, so that they can elect the Sentinel **leader** who will take all the decisions to restore the service availability by: - Promoting a new **Master** @@ -212,7 +197,8 @@ who will take all the decisions to restore the service availability by: - Reconfigure the old **Master** and demote to **Slave** when it comes back online You must have at least `3` Redis Sentinel servers, and they need to -be each in a independent machine (that are believed to fail independently). +be each in a independent machine (that are believed to fail independently), +ideally in different geographical areas. You can configure them in the same machines where you've configured the other Redis servers, but understand that if a whole node goes down, you loose both @@ -230,7 +216,7 @@ Here are some examples: - With `5` or `6` sentinels, a maximum of `2` can go down for a failover begin. - With `7` sentinels, a maximum of `3` nodes can go down. -The **Leader** election can sometimes fail the voting round when **consensus**, +The **Leader** election can sometimes fail the voting round when **consensus** is not achieved (see the odd number of nodes requirement above). In that case, a new attempt will be made after the amount of time defined in `sentinel['failover_timeout']` (in milliseconds). @@ -238,7 +224,7 @@ a new attempt will be made after the amount of time defined in >**Note:** We will see where `sentinel['failover_timeout']` is defined later. -The `failover_timeout` variable has a lot of different use cases, according to +The `failover_timeout` variable has a lot of different use cases. According to the official documentation: - The time needed to re-start a failover after a previous failover was @@ -259,7 +245,7 @@ the official documentation: the slaves will be reconfigured by the Sentinels anyway, but not with the exact parallel-syncs progression as specified. -## Redis HA configuration +## Configuring Redis HA This is the section where we install and setup the new Redis instances. @@ -271,95 +257,138 @@ This is the section where we install and setup the new Redis instances. `redis['password']`. At any time during a failover the Sentinels can reconfigure a node and change its status from master to slave and vice versa. -A summary of what are we going to do: +### Prerequisites -1. Provision the required number of instances specified previously: - - You can opt to install Redis and Sentinel in the same machine or each in - independent ones. - - Don't install Redis and Sentinel in the same machines your GitLab application - is running on. - - All machines must be able to talk to each other and accept incoming - connections over Redis (`6379`) and Sentinel (`26379`) ports (unless you - change the default ports). - - GitLab machines must be able to access these machines and with the same - permissions. - - Protect them from access from external networks (Internet), - to harden the security. +The prerequisites for a HA Redis setup are the following: -1. Download/install Omnibus GitLab using **steps 1 and 2** from - [GitLab downloads](https://about.gitlab.com/downloads) in each node. - - Do not complete other steps on the download page. - - Make sure you select the correct Omnibus package, with the same version - and type (Community, Enterprise editions) of your current install. +1. Provision the minimum required number of instances as specified in the + [recommended setup](#recommended-setup) section. +1. **Do NOT** install Redis or Redis Sentinel in the same machines your + GitLab application is running on. You can however opt in to install Redis + and Sentinel in the same machine (each in independent ones is recommended + though). +1. All Redis nodes must be able to talk to each other and accept incoming + connections over Redis (`6379`) and Sentinel (`26379`) ports (unless you + change the default ones). +1. The server that hosts the GitLab application must be able to access the + Redis nodes. +1. Protect the nodes from access from external networks (Internet), using + firewall. -1. Run `touch /etc/gitlab/skip-auto-migrations` to prevent database migrations - from running on upgrade. Only the primary GitLab application server should - handle migrations. +### Step 1. Configuring the master Redis instance -1. Edit `/etc/gitlab/gitlab.rb` and make the changes based on the - [Example Configurations](#example-configurations). +1. SSH into the **master** Redis server and login as root: -### Configuring the Master Redis instance + ``` + sudo -i + ``` -You will need to configure the following in `/etc/gitlab/gitlab.rb`: +1. [Download/install](https://about.gitlab.com/installation) the Omnibus GitLab + package using **steps 1 and 2** from the GitLab downloads page. + - Make sure you select the correct Omnibus package, with the same version + and type (Community, Enterprise editions) of your current install. + - Do not complete any other steps on the download page. -1. Define `redis_master_role['enable']` to `true`, to disable other services - in the machine (you can still enable Sentinel) +1. Edit `/etc/gitlab/gitlab.rb` and add the contents: -1. Define a `redis['bind']` address pointing to a local IP that your other machines - can reach you. - - If you really need to bind to an external accessible IP, make - sure you add extra firewall rules to prevent unauthorized access. - - You can also set bind to `0.0.0.0` which listen in all interfaces. + ```ruby + # Enable the master role and disable all other services in the machine + # (you can still enable Sentinel). + redis_master_role['enable'] = true + + # IP address pointing to a local IP that the other machines can reach to. + # You can also set bind to '0.0.0.0' which listen in all interfaces. + # If you really need to bind to an external accessible IP, make + # sure you add extra firewall rules to prevent unauthorized access. + redis['bind'] = '10.0.0.1' + + # Define a port so Redis can listen for TCP requests which will allow other + # machines to connect to it. + redis['port'] = 6379 + + # Set up password authentication for Redis (use the same password in all nodes). + redis['password'] = 'redis-password-goes-here' + ``` + +1. To prevent database migrations from running on upgrade, run: + + ``` + touch /etc/gitlab/skip-auto-migrations + ``` -1. Define a `redis['port']` so redis can listen for TCP requests which will - allow other machines to connect to it. + Only the primary GitLab application server should handle migrations. -1. Set up a password authentication with `redis['password']` and - `redis['master_password']` (use the same password in all nodes). +1. [Reconfigure Omnibus GitLab][reconfigure] for the changes to take effect. -1. [Reconfigure Omnibus GitLab][reocnfigure] for the changes to take effect. +### Step 2. Configuring the slave Redis instances -### Configuring the Slave Redis instances +1. SSH into the **slave** Redis server and login as root: -You will need to configure the following in `/etc/gitlab/gitlab.rb`: + ``` + sudo -i + ``` -1. Define `redis_slaves_role['enable']` to `true`, to disable other services - in the machine (you can still enable Sentinel) - - This will also set automatically `redis['master'] = false`. +1. [Download/install](https://about.gitlab.com/installation) the Omnibus GitLab + package using **steps 1 and 2** from the GitLab downloads page. + - Make sure you select the correct Omnibus package, with the same version + and type (Community, Enterprise editions) of your current install. + - Do not complete any other steps on the download page. -1. Define a `redis['bind']` address pointing to a local IP that your other machines - can reach you. - - If you really need to bind to an external accessible IP, make - sure you add extra firewall rules to prevent unauthorized access. - - You can also set bind to `0.0.0.0` which listen in all interfaces. +1. Edit `/etc/gitlab/gitlab.rb` and add the contents: + + ```ruby + # Enable the slave role and disable all other services in the machine + # (you can still enable Sentinel). This will also set automatically + # `redis['master'] = false`. + redis_slave_role['enable'] = true -1. Define a `redis['port']` so redis can listen for TCP requests which will - allow other machines to connect to it. + # IP address pointing to a local IP that the other machines can reach to. + # You can also set bind to '0.0.0.0' which listen in all interfaces. + # If you really need to bind to an external accessible IP, make + # sure you add extra firewall rules to prevent unauthorized access. + redis['bind'] = '10.0.0.2' -1. Set up a password authentication with `redis['password']` and - `redis['master_password']` (use the same password in all nodes). -1. Define `redis['master_ip']` with the IP of the **Master** Redis. + # Define a port so Redis can listen for TCP requests which will allow other + # machines to connect to it. + redis['port'] = 6379 -1. Define `redis['master_port']` with the port of the **Master** Redis (default to `6379`). + # The same password for Redeis authentication you set up for the master node. + redis['password'] = 'redis-password-goes-here' -Initial **Slave** nodes require `redis['master']` defined to `false` and -`redis['master_ip']` pointing to the initial **Master**. If you use the -simplified configuration by enabling `redis_slave_role['enable']`, you -just need to fill in the `redis['master_ip']`. + # The IP of the master Redis node. + redis['master_ip'] = '10.0.0.1' -This values don't have to be changed again in `/etc/gitlab/gitlab.rb` after + # Port of master Redis server, uncomment to change to non default. Defaults + # to `6379`. + #redis['master_port'] = 6379 + ``` + +1. To prevent database migrations from running on upgrade, run: + + ``` + touch /etc/gitlab/skip-auto-migrations + ``` + + Only the primary GitLab application server should handle migrations. + +1. [Reconfigure Omnibus GitLab][reconfigure] for the changes to take effect. +1. Go through the steps again for all the other slave nodes. + +--- + +These values don't have to be changed again in `/etc/gitlab/gitlab.rb` after a failover, as the nodes will be managed by the Sentinels, and even after a `gitlab-ctl reconfigure`, they will get their configuration restored by the same Sentinels. -### Configuring the Redis Sentinel instances +### Step 3. Configuring the Redis Sentinel instances >**Note:** -- Redis Sentinel is bundled with Omnibus GitLab Enterprise Edition only. For the - Omnibus Community Edition and installations from source, follow the - [Redis HA source install](redis_source.md) guide. +Redis Sentinel is bundled with Omnibus GitLab Enterprise Edition only. The +following section assumes you are using Omnibus GitLab Enterprise Edition. +For the Omnibus Community Edition and installations from source, follow the +[Redis HA source install](redis_source.md) guide. Now that the Redis servers are all set up, let's configure the Sentinel servers. @@ -369,15 +398,112 @@ correctly, please read the [Troubleshooting Replication](#troubleshooting-replic and fix it before proceeding with Sentinel setup. You must have at least `3` Redis Sentinel servers, and they need to -be each in a independent machine. You can configure them in the same +be each in an independent machine. You can configure them in the same machines where you've configured the other Redis servers. -With GitLab Enterprise Edition, you can use the Omnibus package to setup multiple -machines with the Sentinel daemon. +With GitLab Enterprise Edition, you can use the Omnibus package to setup +multiple machines with the Sentinel daemon. + +--- + +1. SSH into the server that will host Redis Sentinel and login as root: + + ``` + sudo -i + ``` + +1. **You can omit this step if the Sentinels will be hosted in the same node as + the other Redis instances.** + + [Download/install](https://about.gitlab.com/downloads-ee) the + Omnibus GitLab Enterprise Edition package using **steps 1 and 2** from the + GitLab downloads page. + - Make sure you select the correct Omnibus package, with the same version + the GitLab application is running. + - Do not complete any other steps on the download page. -See [example configuration](#configuration-for-sentinel-ee-only) below. +1. Edit `/etc/gitlab/gitlab.rb` and add the contents (if you are installing the + Sentinels in the same node as the other Redis instances, some values might + be duplicate below): -### Configuring the GitLab application + + ```ruby + redis_sentinel_role['enable'] = true + + # Must be the same in every sentinel node + redis['master_name'] = 'gitlab-redis' + + # The same password for Redis authentication you set up for the master node. + redis['password'] = 'redis-password-goes-here' + + # The IP of the master Redis node. + redis['master_ip'] = '10.0.0.1' + + # Define a port so Redis can listen for TCP requests which will allow other + # machines to connect to it. + redis['port'] = 6379 + + # Port of master Redis server, uncomment to change to non default. Defaults + # to `6379`. + #redis['master_port'] = 6379 + + ## Configure Sentinel + sentinel['bind'] = '10.0.0.1' + + # Port that Sentinel listens on, uncomment to change to non default. Defaults + # to `26379`. + # sentinel['port'] = 26379 + + ## Quorum must reflect the amount of voting sentinels it take to start a failover. + ## Value must NOT be greater then the amount of sentinels. + ## + ## The quorum can be used to tune Sentinel in two ways: + ## 1. If a the quorum is set to a value smaller than the majority of Sentinels + ## we deploy, we are basically making Sentinel more sensible to master failures, + ## triggering a failover as soon as even just a minority of Sentinels is no longer + ## able to talk with the master. + ## 1. If a quorum is set to a value greater than the majority of Sentinels, we are + ## making Sentinel able to failover only when there are a very large number (larger + ## than majority) of well connected Sentinels which agree about the master being down.s + sentinel['quorum'] = 2 + + ## Consider unresponsive server down after x amount of ms. + # sentinel['down_after_milliseconds'] = 10000 + + ## Specifies the failover timeout in milliseconds. It is used in many ways: + ## + ## - The time needed to re-start a failover after a previous failover was + ## already tried against the same master by a given Sentinel, is two + ## times the failover timeout. + ## + ## - The time needed for a slave replicating to a wrong master according + ## to a Sentinel current configuration, to be forced to replicate + ## with the right master, is exactly the failover timeout (counting since + ## the moment a Sentinel detected the misconfiguration). + ## + ## - The time needed to cancel a failover that is already in progress but + ## did not produced any configuration change (SLAVEOF NO ONE yet not + ## acknowledged by the promoted slave). + ## + ## - The maximum time a failover in progress waits for all the slaves to be + ## reconfigured as slaves of the new master. However even after this time + ## the slaves will be reconfigured by the Sentinels anyway, but not with + ## the exact parallel-syncs progression as specified. + # sentinel['failover_timeout'] = 60000 + ``` + +1. To prevent database migrations from running on upgrade, run: + + ``` + touch /etc/gitlab/skip-auto-migrations + ``` + + Only the primary GitLab application server should handle migrations. + +1. [Reconfigure Omnibus GitLab][reconfigure] for the changes to take effect. +1. Go through the steps again for all the other Sentinel nodes. + +### Step 4. Configuring the GitLab application The final part is to inform the main GitLab application server of the Redis Sentinels servers and authentication credentials. @@ -395,14 +521,23 @@ which ideally should not have Redis or Sentinels on it for a HA setup. 1. Edit `/etc/gitlab/gitlab.rb` and add/change the following lines: - - `redis['master_name']` - this is the `master-group-name` from sentinel (default: `gitlab-redis`) - - `redis['master_password']` - the same password you've defined before for Redis and Sentinels - - `gitlab_rails['redis_sentinels']` - a list of sentinels with `host` and `port` + ``` + # Must be the same in every sentinel node + redis['master_name'] = 'gitlab-redis' + + # The same password for Redis authentication you set up for the master node. + redis['password'] = 'redis-password-goes-here' + + # A list of sentinels with `host` and `port` + gitlab_rails['redis_sentinels'] = [ + {'host' => '10.0.0.1', 'port' => 26379}, + {'host' => '10.0.0.2', 'port' => 26379}, + {'host' => '10.0.0.3', 'port' => 26379} + ] + ``` 1. [Reconfigure Omnibus GitLab][reconfigure] for the changes to take effect. -See [example configuration](#configuration-for-gitlab) below. - ## Switching from an existing single-machine installation to Redis HA If you already have a single-machine GitLab install running, you will need to @@ -436,14 +571,15 @@ unauthorized access from other machines and block traffic from the outside (Internet). We will use the same `3` nodes with **Redis** + **Sentinel** topology -discussed in [Redis Setup](#redis-setup) and [Sentinel Setup](#sentinel-setup) -documentation. +discussed in [Redis setup overview](#redis-setup-overview) and +[Sentinel setup overview](#sentinel-setup-overview) documentation. Here is a list and description of each **machine** and the assigned **IP**: * `10.0.0.1`: Redis Master + Sentinel 1 * `10.0.0.2`: Redis Slave 1 + Sentinel 2 -* `10.0.0.2`: Redis Slave 2 + Sentinel 3 +* `10.0.0.3`: Redis Slave 2 + Sentinel 3 +* `10.0.0.4`: GitLab application Please note that after the initial configuration, if a failover is initiated by the Sentinel nodes, the Redis nodes will be reconfigured and the **Master** @@ -454,7 +590,7 @@ The same thing will happen with `sentinel.conf` that will be overridden after th initial execution, after any new sentinel node starts watching the **Master**, or a failover promotes a different **Master** node. -### Configuration for Redis master +### Example configuration for Redis master **Example configation for Redis Master:** @@ -466,14 +602,13 @@ redis_master_role['enable'] = true redis['bind'] = '10.0.0.1' redis['port'] = 6379 redis['password'] = 'redis-password-goes-here' -redis['master_password'] = 'redis-password-goes-here' ``` [Reconfigure Omnibus GitLab][reconfigure] for the changes to take effect. -### Configuration for Redis slaves +### Example configuration for Redis slaves -**Example configation for Slave 1:** +**Example configuration for Slave 1:** In `/etc/gitlab/gitlab.rb`: @@ -489,9 +624,9 @@ redis['master_ip'] = '10.0.0.1' # IP of master Redis server #redis['master_port'] = 6379 # Port of master Redis server, uncomment to change to non default ``` -Reconfigure Omnibus GitLab for the changes to take effect: `sudo gitlab-ctl reconfigure` +[Reconfigure Omnibus GitLab][reconfigure] for the changes to take effect. -**Example configation for Slave 2:** +**Example configuration for Slave 2:** In `/etc/gitlab/gitlab.rb`: @@ -509,7 +644,7 @@ redis['master_ip'] = '10.0.0.1' # IP of master Redis server [Reconfigure Omnibus GitLab][reconfigure] for the changes to take effect. -### Configuration for Sentinels +### Example configuration for Sentinels >**Note:** Redis Sentinel is bundled with Omnibus GitLab Enterprise Edition only. For the @@ -519,7 +654,7 @@ Omnibus Community Edition and installations from source, follow the Please note that some of the variables are already configured previously as they are required for Redis replication. -**Example configation for Sentinel 1:** +**Example configuration for Sentinel 1:** In `/etc/gitlab/gitlab.rb`: @@ -534,46 +669,17 @@ redis['master_ip'] = '10.0.0.1' # ip of the initial master redis instance ## Configure Sentinel sentinel['bind'] = '10.0.0.1' # sentinel['port'] = 26379 # uncomment to change default port - -## Quorum must reflect the amount of voting sentinels it take to start a failover. -## Value must NOT be greater then the ammount of sentinels. -## -## The quorum can be used to tune Sentinel in two ways: -## 1. If a the quorum is set to a value smaller than the majority of Sentinels -## we deploy, we are basically making Sentinel more sensible to master failures, -## triggering a failover as soon as even just a minority of Sentinels is no longer -## able to talk with the master. -## 1. If a quorum is set to a value greater than the majority of Sentinels, we are -## making Sentinel able to failover only when there are a very large number (larger -## than majority) of well connected Sentinels which agree about the master being down.s sentinel['quorum'] = 2 ## Consider unresponsive server down after x amount of ms. # sentinel['down_after_milliseconds'] = 10000 -## Specifies the failover timeout in milliseconds. It is used in many ways: -## -## - The time needed to re-start a failover after a previous failover was -## already tried against the same master by a given Sentinel, is two -## times the failover timeout. -## -## - The time needed for a slave replicating to a wrong master according -## to a Sentinel current configuration, to be forced to replicate -## with the right master, is exactly the failover timeout (counting since -## the moment a Sentinel detected the misconfiguration). -## -## - The time needed to cancel a failover that is already in progress but -## did not produced any configuration change (SLAVEOF NO ONE yet not -## acknowledged by the promoted slave). -## -## - The maximum time a failover in progress waits for all the slaves to be -## reconfigured as slaves of the new master. However even after this time -## the slaves will be reconfigured by the Sentinels anyway, but not with -## the exact parallel-syncs progression as specified. # sentinel['failover_timeout'] = 60000 ``` -**Example configation for Sentinel 2:** +[Reconfigure Omnibus GitLab][reconfigure] for the changes to take effect. + +**Example configuration for Sentinel 2:** In `/etc/gitlab/gitlab.rb`: @@ -589,45 +695,17 @@ redis['master_ip'] = '10.0.0.1' # ip of the initial master redis instance sentinel['bind'] = '10.0.0.2' # sentinel['port'] = 26379 # uncomment to change default port -## Quorum must reflect the amount of voting sentinels it take to start a failover. -## Value must NOT be greater then the ammount of sentinels. -## -## The quorum can be used to tune Sentinel in two ways: -## 1. If a the quorum is set to a value smaller than the majority of Sentinels -## we deploy, we are basically making Sentinel more sensible to master failures, -## triggering a failover as soon as even just a minority of Sentinels is no longer -## able to talk with the master. -## 1. If a quorum is set to a value greater than the majority of Sentinels, we are -## making Sentinel able to failover only when there are a very large number (larger -## than majority) of well connected Sentinels which agree about the master being down.s sentinel['quorum'] = 2 ## Consider unresponsive server down after x amount of ms. # sentinel['down_after_milliseconds'] = 10000 -## Specifies the failover timeout in milliseconds. It is used in many ways: -## -## - The time needed to re-start a failover after a previous failover was -## already tried against the same master by a given Sentinel, is two -## times the failover timeout. -## -## - The time needed for a slave replicating to a wrong master according -## to a Sentinel current configuration, to be forced to replicate -## with the right master, is exactly the failover timeout (counting since -## the moment a Sentinel detected the misconfiguration). -## -## - The time needed to cancel a failover that is already in progress but -## did not produced any configuration change (SLAVEOF NO ONE yet not -## acknowledged by the promoted slave). -## -## - The maximum time a failover in progress waits for all the slaves to be -## reconfigured as slaves of the new master. However even after this time -## the slaves will be reconfigured by the Sentinels anyway, but not with -## the exact parallel-syncs progression as specified. # sentinel['failover_timeout'] = 60000 ``` -**Example configation for Sentinel 3:** +[Reconfigure Omnibus GitLab][reconfigure] for the changes to take effect. + +**Example configuration for Sentinel 3:** In `/etc/gitlab/gitlab.rb`: @@ -643,44 +721,37 @@ redis['master_ip'] = '10.0.0.1' # ip of the initial master redis instance sentinel['bind'] = '10.0.0.3' # sentinel['port'] = 26379 # uncomment to change default port -## Quorum must reflect the amount of voting sentinels it take to start a failover. -## Value must NOT be greater then the ammount of sentinels. -## -## The quorum can be used to tune Sentinel in two ways: -## 1. If a the quorum is set to a value smaller than the majority of Sentinels -## we deploy, we are basically making Sentinel more sensible to master failures, -## triggering a failover as soon as even just a minority of Sentinels is no longer -## able to talk with the master. -## 1. If a quorum is set to a value greater than the majority of Sentinels, we are -## making Sentinel able to failover only when there are a very large number (larger -## than majority) of well connected Sentinels which agree about the master being down.s sentinel['quorum'] = 2 ## Consider unresponsive server down after x amount of ms. # sentinel['down_after_milliseconds'] = 10000 -## Specifies the failover timeout in milliseconds. It is used in many ways: -## -## - The time needed to re-start a failover after a previous failover was -## already tried against the same master by a given Sentinel, is two -## times the failover timeout. -## -## - The time needed for a slave replicating to a wrong master according -## to a Sentinel current configuration, to be forced to replicate -## with the right master, is exactly the failover timeout (counting since -## the moment a Sentinel detected the misconfiguration). -## -## - The time needed to cancel a failover that is already in progress but -## did not produced any configuration change (SLAVEOF NO ONE yet not -## acknowledged by the promoted slave). -## -## - The maximum time a failover in progress waits for all the slaves to be -## reconfigured as slaves of the new master. However even after this time -## the slaves will be reconfigured by the Sentinels anyway, but not with -## the exact parallel-syncs progression as specified. # sentinel['failover_timeout'] = 60000 ``` +[Reconfigure Omnibus GitLab][reconfigure] for the changes to take effect. + +### Example configuration for the GitLab application + +In `/etc/gitlab/gitlab.rb`: + +``` +# Must be the same in every sentinel node +redis['master_name'] = 'gitlab-redis' + +# The same password for Redis authentication you set up for the master node. +redis['password'] = 'redis-password-goes-here' + +# A list of sentinels with `host` and `port` +gitlab_rails['redis_sentinels'] = [ + {'host' => '10.0.0.1', 'port' => 26379}, + {'host' => '10.0.0.2', 'port' => 26379}, + {'host' => '10.0.0.3', 'port' => 26379} +] +``` + +[Reconfigure Omnibus GitLab][reconfigure] for the changes to take effect. + ## Advanced configuration Omnibus GitLab configures some things behind the curtains to make the sysadmins' @@ -688,8 +759,8 @@ lives easier. If you want to know what happens underneath keep reading. ### Control running services -In the previous example above we've used `redis_sentinel_role` and -`redis_master_role` which simplify the amount of configuration changes. +In the previous example, we've used `redis_sentinel_role` and +`redis_master_role` which simplifies the amount of configuration changes. If you want more control, here is what each one sets for you automatically when enabled: @@ -698,10 +769,10 @@ when enabled: ## Redis Sentinel Role redis_sentinel_role['enable'] = true -# When Sentinel Role is enabled, the following services are enabled/disabled: +# When Sentinel Role is enabled, the following services are also enabled sentinel['enable'] = true -# This others are disabled: +# The following services are disabled redis['enable'] = false bootstrap['enable'] = false nginx['enable'] = false @@ -709,17 +780,17 @@ postgresql['enable'] = false gitlab_rails['enable'] = false mailroom['enable'] = false -## Redis master/slave Role: +------- + +## Redis master/slave Role redis_master_role['enable'] = true # enable only one of them redis_slave_role['enable'] = true # enable only one of them -# When Redis Master or Slave role are enabled, the following services are enabled/disabled: -# (Note that if redis and sentinel roles are combined both services will be enabled) +# When Redis Master or Slave role are enabled, the following services are +# enabled/disabled. Note that if Redis and Sentinel roles are combined, both +# services will be enabled. -# When Sentinel Role is enabled, the following services are enabled/disabled: -redis['enable'] = true - -# This others are disabled: +# The following services are disabled sentinel['enable'] = false bootstrap['enable'] = false nginx['enable'] = false @@ -727,7 +798,7 @@ postgresql['enable'] = false gitlab_rails['enable'] = false mailroom['enable'] = false -# Redis Slave role also change this setting from default 'true' to 'false': +# For Redis Slave role, also change this setting from default 'true' to 'false': redis['master'] = false ``` @@ -856,6 +927,16 @@ To make sure your configuration is correct: Changes to Redis HA over time. +**8.14** + +- Redis Sentinel support is production-ready and bundled in the Omnibus GitLab + Enterprise Edition package +- Documentation restructure for better readability + +**8.11** + +- Experimental Redis Sentinel support was added + ### Experimental Redis Sentinel support > @@ -880,7 +961,7 @@ Read more on high-availability configuration: [gh-534]: https://github.com/redis/redis-rb/issues/534 [redis]: http://redis.io/ [sentinel]: http://redis.io/topics/sentinel -[omnifile]: https://gitlab.com/gitlab-org/omnibus-gitlab/blob/82b7345b150f072c8673c79738ce893f92d0d652/files/gitlab-cookbooks/gitlab/libraries/gitlab_rails.rb#L134-159 +[omnifile]: https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-cookbooks/gitlab/libraries/gitlab_rails.rb [source]: ../../install/installation.md [ce]: https://about.gitlab.com/downloads [ee]: https://about.gitlab.com/downloads-ee -- cgit v1.2.3 From a75c5f195124c12d3776d8c553bc71721cee121d Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Wed, 16 Nov 2016 10:20:59 +0100 Subject: Add clear instructions for the different Redis HA setups --- doc/administration/high_availability/redis.md | 75 ++++++++++++++------------- 1 file changed, 40 insertions(+), 35 deletions(-) (limited to 'doc/administration') diff --git a/doc/administration/high_availability/redis.md b/doc/administration/high_availability/redis.md index 6de92ae3741..7ea49a2c22a 100644 --- a/doc/administration/high_availability/redis.md +++ b/doc/administration/high_availability/redis.md @@ -20,8 +20,9 @@ Omnibus GitLab packages. from source, follow the [Redis HA source installation](redis_source.md) guide. - Redis Sentinel daemon is bundled with Omnibus GitLab Enterprise Edition only. For configuring Sentinel with the Omnibus GitLab Community Edition and - installations from source, follow the - [Redis HA source installation](redis_source.md) guide. + installations from source, read the + [Available configuration setups](#available-configuration-setups) section + below. @@ -40,7 +41,7 @@ Omnibus GitLab packages. - [Step 3. Configuring the Redis Sentinel instances](#step-3-configuring-the-redis-sentinel-instances) - [Step 4. Configuring the GitLab application](#step-4-configuring-the-gitlab-application) - [Switching from an existing single-machine installation to Redis HA](#switching-from-an-existing-single-machine-installation-to-redis-ha) -- [Example of a minimal configuration with 1 master, 2 slaves and 3 sentinels](#example-of-a-minimal-configuration-with-1-master-2-slaves-and-3-sentinels) +- [Example of a minimal configuration with 1 master, 2 slaves and 3 Sentinels](#example-of-a-minimal-configuration-with-1-master-2-slaves-and-3-sentinels) - [Configuration for Redis master](#configuration-for-redis-master) - [Configuration for Redis slaves](#configuration-for-redis-slaves) - [Configuration for Sentinels](#configuration-for-sentinels) @@ -79,17 +80,17 @@ components below. ### High Availability with Sentinel -> +>**Notes:** - Starting with GitLab `8.11`, you can configure a list of Redis Sentinel servers that will monitor a group of Redis servers to provide failover support. - Starting with GitLab `8.14`, the Omnibus GitLab Enterprise Edition package - comes with Redis Sentinel daemon support. + comes with Redis Sentinel daemon built-in. High Availability with Redis requires a few things: - Multiple Redis instances - - Run Redis in a **Master** x **Slave** topology - - Multiple Sentinel instances +- Run Redis in a **Master** x **Slave** topology +- Multiple Sentinel instances - Application support and visibility to all Sentinel and Redis instances Redis Sentinel can handle the most important tasks in an HA environment and that's @@ -132,27 +133,6 @@ the Omnibus GitLab package in `5` **independent** machines, both with - Redis Slave + Sentinel - Redis Slave + Sentinel -### Available configuration setups - -Based on your infrastructure setup and how you have installed GitLab, there are -multiple ways to configure Redis HA. Omnibus GitLab packages have Redis and/or -Redis Sentinel bundled with them so you only need to focus on configuration. -Pick the one that suits your needs. - -- [Installations from source][source]: You need to install Redis and Sentinel - yourself. Use the [Redis HA installation from source](redis_source.md) guide. -- [Omnibus package Community Edition (CE) package][ce]: Redis is bundled, so you - can use the package with only the Redis service enabled (works for both master - and slave setups). To install and configure Sentinel, you can use the - [Redis HA installation from source](redis_source.md) guide. -- [Omnibus package Enterprise Edition (EE) package][ee]: Both Redis and Sentinel - are bundled, so you can use the EE package to setup the whole Redis HA - infrastructure (master, slave and Sentinel). - -Note that even if you have installed GitLab using the Omnibus GitLab packages -(both CE and EE), you can still use an -[external Redis server](#using-a-non-omnibus-external-redis-server). - ### Redis setup overview You must have at least `3` Redis servers: `1` Master, `2` Slaves, and they @@ -168,7 +148,7 @@ simultaneously down. Please note that there are different requirements for Sentinel nodes. If you host them in the same Redis machines, you may need to take that restrictions into consideration when calculating the amount of -nodes to be provisioned. See [Sentinel setup](#sentinel-setup) +nodes to be provisioned. See [Sentinel setup overview](#sentinel-setup-overview) documentation for more information. All Redis nodes should be configured the same way and with similar server specs, as @@ -245,6 +225,31 @@ the official documentation: the slaves will be reconfigured by the Sentinels anyway, but not with the exact parallel-syncs progression as specified. +### Available configuration setups + +Based on your infrastructure setup and how you have installed GitLab, there are +multiple ways to configure Redis HA. Omnibus GitLab packages have Redis and/or +Redis Sentinel bundled with them so you only need to focus on configuration. +Pick the one that suits your needs. + +- [Installations from source][source]: You need to install Redis and Sentinel + yourself. Use the [Redis HA installation from source](redis_source.md) + documentation. +- [Omnibus GitLab **Community Edition** (CE) package][ce]: Redis is bundled, so you + can use the package with only the Redis service enabled as described in steps + 1 and 2 of this document (works for both master and slave setups). To install + and configure Sentinel, jump directly to the Sentinel section in the + [Redis HA installation from source](redis_source.md#step-3-configuring-the-redis-sentinel-instances) documentation. +- [Omnibus GitLab **Enterprise Edition** (EE) package][ee]: Both Redis and Sentinel + are bundled in the package, so you can use the EE package to setup the whole + Redis HA infrastructure (master, slave and Sentinel) which is described in + this document. +- If you have installed GitLab using the Omnibus GitLab packages (CE or EE), + but you want to use your own external Redis server, follow steps 1-3 in the + [Redis HA installation from source](redis_source.md) documentation, then go + straight to step 4 in this guide to + [set up the GitLab application](#step-4-configuring-the-gitlab-application). + ## Configuring Redis HA This is the section where we install and setup the new Redis instances. @@ -284,7 +289,7 @@ The prerequisites for a HA Redis setup are the following: ``` 1. [Download/install](https://about.gitlab.com/installation) the Omnibus GitLab - package using **steps 1 and 2** from the GitLab downloads page. + package you want using **steps 1 and 2** from the GitLab downloads page. - Make sure you select the correct Omnibus package, with the same version and type (Community, Enterprise editions) of your current install. - Do not complete any other steps on the download page. @@ -313,7 +318,7 @@ The prerequisites for a HA Redis setup are the following: 1. To prevent database migrations from running on upgrade, run: ``` - touch /etc/gitlab/skip-auto-migrations + sudo touch /etc/gitlab/skip-auto-migrations ``` Only the primary GitLab application server should handle migrations. @@ -329,7 +334,7 @@ The prerequisites for a HA Redis setup are the following: ``` 1. [Download/install](https://about.gitlab.com/installation) the Omnibus GitLab - package using **steps 1 and 2** from the GitLab downloads page. + package you want using **steps 1 and 2** from the GitLab downloads page. - Make sure you select the correct Omnibus package, with the same version and type (Community, Enterprise editions) of your current install. - Do not complete any other steps on the download page. @@ -367,7 +372,7 @@ The prerequisites for a HA Redis setup are the following: 1. To prevent database migrations from running on upgrade, run: ``` - touch /etc/gitlab/skip-auto-migrations + sudo touch /etc/gitlab/skip-auto-migrations ``` Only the primary GitLab application server should handle migrations. @@ -495,7 +500,7 @@ multiple machines with the Sentinel daemon. 1. To prevent database migrations from running on upgrade, run: ``` - touch /etc/gitlab/skip-auto-migrations + sudo touch /etc/gitlab/skip-auto-migrations ``` Only the primary GitLab application server should handle migrations. @@ -560,7 +565,7 @@ redis['enable'] = false If you fail to replicate first, you may loose data (unprocessed background jobs). -## Example of a minimal configuration with 1 master, 2 slaves and 3 sentinels +## Example of a minimal configuration with 1 master, 2 slaves and 3 Sentinels In this example we consider that all servers have an internal network interface with IPs in the `10.0.0.x` range, and that they can connect -- cgit v1.2.3 From 178d5ae9719b0edf6a4873502422e3302d264528 Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Wed, 16 Nov 2016 10:21:44 +0100 Subject: Rearrange Redis HA source installations sections --- .../high_availability/redis_source.md | 57 +++++++++++++--------- 1 file changed, 33 insertions(+), 24 deletions(-) (limited to 'doc/administration') diff --git a/doc/administration/high_availability/redis_source.md b/doc/administration/high_availability/redis_source.md index 20630b070c0..a420d44f451 100644 --- a/doc/administration/high_availability/redis_source.md +++ b/doc/administration/high_availability/redis_source.md @@ -1,26 +1,34 @@ -# Configuring Redis for GitLab HA (Source Install) +# Configuring non-Omnibus Redis for GitLab HA -We highly recommend that you use Omnibus GitLab packages, as we can optimize -required packages specifically for GitLab, and we will take care of upgrading +This is the documentation for configuring a Highly Available Redis setup when +you have installed Redis all by yourself and not using the bundled one that +comes with the Omnibus packages. + +We cannot stress enough the importance of reading the +[Overview section](redis.md#overview) of the Omnibus Redis HA as it provides +some invaluable information to the configuration of Redis. Please proceed to +read it before going forward with this guide. + +We also highly recommend that you use the Omnibus GitLab packages, as we +optimize them specifically for GitLab, and we will take care of upgrading Redis to the latest supported version. -If you are building packages for a specific distro, or trying to build some -internal automation, you can check this documentation to learn about the -minimal setup, required changes, etc. +If you're not sure whether this guide is for you, please refer to +[Available configuration setups](redis.md#available-configuration-setups) in +the Omnibus Redis HA documentation. -If you want to see the documentation for Omnibus GitLab Install, please -[read it here](redis.md). +--- **Table of Contents** -- [Configure your own Redis server](#configure-your-own-redis-server) - - [Configuring Master Redis instance](#configuring-master-redis-instance) - - [Configuring Slave Redis instances](#configuring-slave-redis-instances) - - [Configuring Redis Sentinel instances](#configuring-redis-sentinel-instances) -- [GitLab setup](#gitlab-setup) -- [Example configurations](#example-configurations) +- [Configuring your own Redis server](#configuring-your-own-redis-server) + - [Step 1. Configuring the master Redis instance](#step-1-configuring-the-master-redis-instance) + - [Step 2. Configuring the slave Redis instances](#step-2-configuring-the-slave-redis-instances) + - [Step 3. Configuring the Redis Sentinel instances](#step-3-configuring-the-redis-sentinel-instances) + - [Step 4. Configuring the GitLab application](#step-4-configuring-the-gitlab-application) +- [Example of minimal configuration with 1 master, 2 slaves and 3 Sentinels](#example-of-minimal-configuration-with-1-master-2-slaves-and-3-sentinels) - [Configuring Redis Master](#configuring-redis-master) - [Configuring Redis Slaves](#configuring-redis-slaves) - [Configuring Redis Sentinel](#configuring-redis-sentinel) @@ -28,7 +36,7 @@ If you want to see the documentation for Omnibus GitLab Install, please -## Configure your own Redis server +## Configuring your own Redis server Redis server must be configured to use TCP connection instead of socket, and since Redis `3.2`, you must define a password to receive external @@ -41,8 +49,7 @@ To configure Redis to use TCP connection you need to define both `bind` and `port`. You can bind to all interfaces (`0.0.0.0`) or specify the IP of the desired interface (for ex. one from an internal network). - -### Configuring Master Redis instance +### Step 1. Configuring the master Redis instance You need to make the following changes in `redis.conf`: @@ -61,7 +68,7 @@ You need to make the following changes in `redis.conf`: See [example configuration](#configuring-redis-master) below. -### Configuring Slave Redis instances +### Step 2. Configuring the slave Redis instances 1. Follow same instructions for Redis Master @@ -71,7 +78,7 @@ See [example configuration](#configuring-redis-master) below. See [example configuration](#configuring-redis-slaves) below. -### Configuring Redis Sentinel instances +### Step 3. Configuring the Redis Sentinel instances Sentinel is a special type of Redis server. It inherits most of the basic configuration options you can define in `redis.conf`, with specific ones @@ -122,7 +129,7 @@ And the sentinel specific ones: See [example configuration](#configuring-redis-sentinel) below. -## GitLab setup +### Step 4. Configuring the GitLab application You can enable or disable Sentinel support at any time in new or existing installations. From the GitLab application perspective, all it requires is @@ -141,7 +148,7 @@ which ideally should not have Redis or Sentinels in the same machine for a HA se 1. Restart GitLab for the changes to take effect. -## Example configurations +## Example of minimal configuration with 1 master, 2 slaves and 3 Sentinels In this example we consider that all servers have an internal network interface with IPs in the `10.0.0.x` range, and that they can connect @@ -247,12 +254,13 @@ sentinel failover_timeout 30000 ## Troubleshooting -We have a more detailed [Troubleshooting](redis.md#troubleshooting) explained in the documentation for Omnibus -Install. Here we will list only the things that are specific to a **Source** install. +We have a more detailed [Troubleshooting](redis.md#troubleshooting) explained +in the documentation for Omnibus GitLab installations. Here we will list only +the things that are specific to a source installation. If you get an error in GitLab like: `Redis::CannotConnectError: No sentinels available.`, there may be something wrong with your configuration files or it can be related -to [this issue][gh-531]. +to [this upstream issue][gh-531]. It's a bit non-intuitive the way you have to config `resque.yml` and `sentinel.conf`, otherwise `redis-rb` will not work properly. @@ -287,3 +295,4 @@ production: When in doubt, please read [Redis Sentinel documentation](http://redis.io/topics/sentinel) [gh-531]: https://github.com/redis/redis-rb/issues/531 +[downloads]: https://about.gitlab.com/downloads -- cgit v1.2.3 From dc54239683fbe77b13216deb6a0728563a0a89d0 Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Wed, 16 Nov 2016 11:42:12 +0100 Subject: Merge examples of Redis master/slave + Sentinels --- doc/administration/high_availability/redis.md | 144 +++++++------------------- 1 file changed, 37 insertions(+), 107 deletions(-) (limited to 'doc/administration') diff --git a/doc/administration/high_availability/redis.md b/doc/administration/high_availability/redis.md index 7ea49a2c22a..02ca4999cd4 100644 --- a/doc/administration/high_availability/redis.md +++ b/doc/administration/high_availability/redis.md @@ -29,22 +29,23 @@ Omnibus GitLab packages. **Table of Contents** - [Overview](#overview) - - [Prerequisites](#prerequisites) - [High Availability with Sentinel](#high-availability-with-sentinel) - [Recommended setup](#recommended-setup) - - [Available configuration setups](#available-configuration-setups) - [Redis setup overview](#redis-setup-overview) - [Sentinel setup overview](#sentinel-setup-overview) + - [Available configuration setups](#available-configuration-setups) - [Configuring Redis HA](#configuring-redis-ha) - - [Step 1. Configuring the Master Redis instance](#step-1-configuring-the-master-redis-instance) - - [Step 2. Configuring the Slave Redis instances](#step-2-configuring-the-slave-redis-instances) + - [Prerequisites](#prerequisites) + - [Step 1. Configuring the master Redis instance](#step-1-configuring-the-master-redis-instance) + - [Step 2. Configuring the slave Redis instances](#step-2-configuring-the-slave-redis-instances) - [Step 3. Configuring the Redis Sentinel instances](#step-3-configuring-the-redis-sentinel-instances) - [Step 4. Configuring the GitLab application](#step-4-configuring-the-gitlab-application) - [Switching from an existing single-machine installation to Redis HA](#switching-from-an-existing-single-machine-installation-to-redis-ha) - [Example of a minimal configuration with 1 master, 2 slaves and 3 Sentinels](#example-of-a-minimal-configuration-with-1-master-2-slaves-and-3-sentinels) - - [Configuration for Redis master](#configuration-for-redis-master) - - [Configuration for Redis slaves](#configuration-for-redis-slaves) - - [Configuration for Sentinels](#configuration-for-sentinels) + - [Example configuration for Redis master and Sentinel 1](#example-configuration-for-redis-master-and-sentinel-1) + - [Example configuration for Redis slave 1 and Sentinel 2](#example-configuration-for-redis-slave-1-and-sentinel-2) + - [Example configuration for Redis slave 2 and Sentinel 3](#example-configuration-for-redis-slave-2-and-sentinel-3) + - [Example configuration for the GitLab application](#example-configuration-for-the-gitlab-application) - [Advanced configuration](#advanced-configuration) - [Control running services](#control-running-services) - [Troubleshooting](#troubleshooting) @@ -277,7 +278,7 @@ The prerequisites for a HA Redis setup are the following: change the default ones). 1. The server that hosts the GitLab application must be able to access the Redis nodes. -1. Protect the nodes from access from external networks (Internet), using +1. Protect the nodes from access from external networks ([Internet][it]), using firewall. ### Step 1. Configuring the master Redis instance @@ -527,13 +528,13 @@ which ideally should not have Redis or Sentinels on it for a HA setup. 1. Edit `/etc/gitlab/gitlab.rb` and add/change the following lines: ``` - # Must be the same in every sentinel node + ## Must be the same in every sentinel node redis['master_name'] = 'gitlab-redis' - # The same password for Redis authentication you set up for the master node. + ## The same password for Redis authentication you set up for the master node. redis['password'] = 'redis-password-goes-here' - # A list of sentinels with `host` and `port` + ## A list of sentinels with `host` and `port` gitlab_rails['redis_sentinels'] = [ {'host' => '10.0.0.1', 'port' => 26379}, {'host' => '10.0.0.2', 'port' => 26379}, @@ -567,6 +568,11 @@ If you fail to replicate first, you may loose data (unprocessed background jobs) ## Example of a minimal configuration with 1 master, 2 slaves and 3 Sentinels +>**Note:** +Redis Sentinel is bundled with Omnibus GitLab Enterprise Edition only. For +different setups, read the +[available configuration setups](#available-configuration-setups) section. + In this example we consider that all servers have an internal network interface with IPs in the `10.0.0.x` range, and that they can connect to each other using these IPs. @@ -595,142 +601,70 @@ The same thing will happen with `sentinel.conf` that will be overridden after th initial execution, after any new sentinel node starts watching the **Master**, or a failover promotes a different **Master** node. -### Example configuration for Redis master - -**Example configation for Redis Master:** +### Example configuration for Redis master and Sentinel 1 In `/etc/gitlab/gitlab.rb`: ```ruby redis_master_role['enable'] = true - +redis_sentinel_role['enable'] = true redis['bind'] = '10.0.0.1' redis['port'] = 6379 redis['password'] = 'redis-password-goes-here' -``` - -[Reconfigure Omnibus GitLab][reconfigure] for the changes to take effect. - -### Example configuration for Redis slaves - -**Example configuration for Slave 1:** - -In `/etc/gitlab/gitlab.rb`: - -```ruby -redis_slave_role['enable'] = true - -redis['bind'] = '10.0.0.2' -redis['port'] = 6379 -redis['password'] = 'redis-password-goes-here' -redis['master_password'] = 'redis-password-goes-here' - -redis['master_ip'] = '10.0.0.1' # IP of master Redis server -#redis['master_port'] = 6379 # Port of master Redis server, uncomment to change to non default -``` - -[Reconfigure Omnibus GitLab][reconfigure] for the changes to take effect. - -**Example configuration for Slave 2:** - -In `/etc/gitlab/gitlab.rb`: - -```ruby -redis_slave_role['enable'] = true - -redis['bind'] = '10.0.0.3' -redis['port'] = 6379 -redis['password'] = 'redis-password-goes-here' -redis['master_password'] = 'redis-password-goes-here' - -redis['master_ip'] = '10.0.0.1' # IP of master Redis server -#redis['master_port'] = 6379 # Port of master Redis server, uncomment to change to non default -``` - -[Reconfigure Omnibus GitLab][reconfigure] for the changes to take effect. - -### Example configuration for Sentinels - ->**Note:** -Redis Sentinel is bundled with Omnibus GitLab Enterprise Edition only. For the -Omnibus Community Edition and installations from source, follow the -[Redis HA source install](redis_source.md) guide. - -Please note that some of the variables are already configured previously -as they are required for Redis replication. - -**Example configuration for Sentinel 1:** - -In `/etc/gitlab/gitlab.rb`: - -```ruby -redis_sentinel_role['enable'] = true - redis['master_name'] = 'gitlab-redis' # must be the same in every sentinel node redis['master_password'] = 'redis-password-goes-here' # the same value defined in redis['password'] in the master instance redis['master_ip'] = '10.0.0.1' # ip of the initial master redis instance #redis['master_port'] = 6379 # port of the initial master redis instance, uncomment to change to non default - -## Configure Sentinel sentinel['bind'] = '10.0.0.1' # sentinel['port'] = 26379 # uncomment to change default port sentinel['quorum'] = 2 - -## Consider unresponsive server down after x amount of ms. # sentinel['down_after_milliseconds'] = 10000 - # sentinel['failover_timeout'] = 60000 ``` [Reconfigure Omnibus GitLab][reconfigure] for the changes to take effect. -**Example configuration for Sentinel 2:** +### Example configuration for Redis slave 1 and Sentinel 2 In `/etc/gitlab/gitlab.rb`: ```ruby +redis_slave_role['enable'] = true redis_sentinel_role['enable'] = true - +redis['bind'] = '10.0.0.2' +redis['port'] = 6379 +redis['password'] = 'redis-password-goes-here' +redis['master_password'] = 'redis-password-goes-here' +redis['master_ip'] = '10.0.0.1' # IP of master Redis server +#redis['master_port'] = 6379 # Port of master Redis server, uncomment to change to non default redis['master_name'] = 'gitlab-redis' # must be the same in every sentinel node -redis['master_password'] = 'redis-password-goes-here' # the same value defined in redis['password'] in the master instance -redis['master_ip'] = '10.0.0.1' # ip of the initial master redis instance -#redis['master_port'] = 6379 # port of the initial master redis instance, uncomment to change to non default - -## Configure Sentinel sentinel['bind'] = '10.0.0.2' # sentinel['port'] = 26379 # uncomment to change default port - sentinel['quorum'] = 2 - -## Consider unresponsive server down after x amount of ms. # sentinel['down_after_milliseconds'] = 10000 - # sentinel['failover_timeout'] = 60000 ``` [Reconfigure Omnibus GitLab][reconfigure] for the changes to take effect. -**Example configuration for Sentinel 3:** +### Example configuration for Redis slave 2 and Sentinel 3 In `/etc/gitlab/gitlab.rb`: ```ruby +redis_slave_role['enable'] = true redis_sentinel_role['enable'] = true - +redis['bind'] = '10.0.0.3' +redis['port'] = 6379 +redis['password'] = 'redis-password-goes-here' +redis['master_password'] = 'redis-password-goes-here' +redis['master_ip'] = '10.0.0.1' # IP of master Redis server +#redis['master_port'] = 6379 # Port of master Redis server, uncomment to change to non default redis['master_name'] = 'gitlab-redis' # must be the same in every sentinel node -redis['master_password'] = 'redis-password-goes-here' # the same value defined in redis['password'] in the master instance -redis['master_ip'] = '10.0.0.1' # ip of the initial master redis instance -#redis['master_port'] = 6379 # port of the initial master redis instance, uncomment to change to non default - -## Configure Sentinel sentinel['bind'] = '10.0.0.3' # sentinel['port'] = 26379 # uncomment to change default port - sentinel['quorum'] = 2 - -## Consider unresponsive server down after x amount of ms. # sentinel['down_after_milliseconds'] = 10000 - # sentinel['failover_timeout'] = 60000 ``` @@ -740,14 +674,9 @@ sentinel['quorum'] = 2 In `/etc/gitlab/gitlab.rb`: -``` -# Must be the same in every sentinel node +```ruby redis['master_name'] = 'gitlab-redis' - -# The same password for Redis authentication you set up for the master node. redis['password'] = 'redis-password-goes-here' - -# A list of sentinels with `host` and `port` gitlab_rails['redis_sentinels'] = [ {'host' => '10.0.0.1', 'port' => 26379}, {'host' => '10.0.0.2', 'port' => 26379}, @@ -970,3 +899,4 @@ Read more on high-availability configuration: [source]: ../../install/installation.md [ce]: https://about.gitlab.com/downloads [ee]: https://about.gitlab.com/downloads-ee +[it]: https://gitlab.com/gitlab-org/gitlab-ce/uploads/c4cc8cd353604bd80315f9384035ff9e/The_Internet_IT_Crowd.png -- cgit v1.2.3 From b6447f3027b7439e33bb8864992f5b4e60ca5cc5 Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Wed, 16 Nov 2016 11:51:28 +0100 Subject: Add steps to Redis HA source installation --- .../high_availability/redis_source.md | 196 +++++++++++++-------- 1 file changed, 123 insertions(+), 73 deletions(-) (limited to 'doc/administration') diff --git a/doc/administration/high_availability/redis_source.md b/doc/administration/high_availability/redis_source.md index a420d44f451..1660e26c784 100644 --- a/doc/administration/high_availability/redis_source.md +++ b/doc/administration/high_availability/redis_source.md @@ -38,45 +38,79 @@ the Omnibus Redis HA documentation. ## Configuring your own Redis server -Redis server must be configured to use TCP connection instead of socket, -and since Redis `3.2`, you must define a password to receive external -connections (`requirepass`). +This is the section where we install and setup the new Redis instances. -You will also need to define equal password for slave password definition -(`masterauth`), in the same instance, if you are using Redis with Sentinel. +### Prerequisites -To configure Redis to use TCP connection you need to define both -`bind` and `port`. You can bind to all interfaces (`0.0.0.0`) or specify the -IP of the desired interface (for ex. one from an internal network). +- All Redis servers in this guide must be configured to use a TCP connection + instead of a socket. To configure Redis to use TCP connections you need to + define both `bind` and `port` in the Redis config file. You can bind to all + interfaces (`0.0.0.0`) or specify the IP of the desired interface + (e.g., one from an internal network). +- Since Redis 3.2, you must define a password to receive external connections + (`requirepass`). +- If you are using Redis with Sentinel, you will also need to define the same + password for the slave password definition (`masterauth`) in the same instance. + +In addition, read the prerequisites as described in the +[Omnibus Redis HA document](redis.md#prerequisites) since they provide some +valuable information for the general setup. ### Step 1. Configuring the master Redis instance -You need to make the following changes in `redis.conf`: +Assuming that the Redis master instance IP is `10.0.0.1`: -1. Define a `bind` address pointing to a local IP that your other machines - can reach you. If you really need to bind to an external accessible IP, make - sure you add extra firewall rules to prevent unauthorized access: +1. [Install Redis](../../install/installation.md#6-redis) +1. Edit `/etc/redis/redis.conf`: -1. Define a `port` to force redis to listen on TCP so other machines can - connect to it (default port is `6379`). + ```conf + ## Define a `bind` address pointing to a local IP that your other machines + ## can reach you. If you really need to bind to an external accessible IP, make + ## sure you add extra firewall rules to prevent unauthorized access: + bind 10.0.0.1 -1. Set up password authentication (use the same password in all nodes). - The password should be defined equal for both `requirepass` and `masterauth` - when setting up Redis to use with Sentinel. + ## Define a `port` to force redis to listen on TCP so other machines can + ## connect to it (default port is `6379`). + port 6379 -1. Restart the Redis services for the changes to take effect. + ## Set up password authentication (use the same password in all nodes). + ## The password should be defined equal for both `requirepass` and `masterauth` + ## when setting up Redis to use with Sentinel. + requirepass redis-password-goes-here + masterauth redis-password-goes-here + ``` -See [example configuration](#configuring-redis-master) below. +1. Restart the Redis service for the changes to take effect. ### Step 2. Configuring the slave Redis instances -1. Follow same instructions for Redis Master +Assuming that the Redis slave instance IP is `10.0.0.2`: + +1. [Install Redis](../../install/installation.md#6-redis) +1. Edit `/etc/redis/redis.conf`: + + ```conf + ## Define a `bind` address pointing to a local IP that your other machines + ## can reach you. If you really need to bind to an external accessible IP, make + ## sure you add extra firewall rules to prevent unauthorized access: + bind 10.0.0.2 + + ## Define a `port` to force redis to listen on TCP so other machines can + ## connect to it (default port is `6379`). + port 6379 -1. Define `slaveof` pointing to the Redis master instance with **IP** and **port**. + ## Set up password authentication (use the same password in all nodes). + ## The password should be defined equal for both `requirepass` and `masterauth` + ## when setting up Redis to use with Sentinel. + requirepass redis-password-goes-here + masterauth redis-password-goes-here -1. Restart the Redis services for the changes to take effect. + ## Define `slaveof` pointing to the Redis master instance with IP and port. + slaveof 10.0.0.1 6379 + ``` -See [example configuration](#configuring-redis-slaves) below. +1. Restart the Redis service for the changes to take effect. +1. Go through the steps again for all the other slave nodes. ### Step 3. Configuring the Redis Sentinel instances @@ -84,50 +118,64 @@ Sentinel is a special type of Redis server. It inherits most of the basic configuration options you can define in `redis.conf`, with specific ones starting with `sentinel` prefix. -You will need to define the initial configs to enable connectivity: - -1. Define a `bind` address pointing to a local IP that your other machines - can reach you. If you really need to bind to an external accessible IP, make - sure you add extra firewall rules to prevent unauthorized access: - -1. Define a `port` to force sentinel to listen on TCP so other machines can - connect to it (default port is `26379`). - -And the sentinel specific ones: - -1. Define with `sentinel auth-pass` the same shared password you have - defined for both Redis **Master** and **Slaves** instances. - -1. Define with `sentinel monitor` the **IP** and **port** of the Redis - **Master** node, and the **quorum** required to start a failover. - If you need more information to understand about quorum, please - read the detailed explanation in the [HA documentation for Omnibus Installs](redis.md). - -1. Define with `sentinel down-after-milliseconds` the amount in `ms` of time - that an unresponsive server will be considered down. - -1. Define a value for `sentinel failover_timeout` in `ms`. This has multiple - meanings: - - * The time needed to re-start a failover after a previous failover was - already tried against the same master by a given Sentinel, is two - times the failover timeout. - - * The time needed for a slave replicating to a wrong master according - to a Sentinel current configuration, to be forced to replicate - with the right master, is exactly the failover timeout (counting since - the moment a Sentinel detected the misconfiguration). - - * The time needed to cancel a failover that is already in progress but - did not produced any configuration change (SLAVEOF NO ONE yet not - acknowledged by the promoted slave). - - * The maximum time a failover in progress waits for all the slaves to be - reconfigured as slaves of the new master. However even after this time - the slaves will be reconfigured by the Sentinels anyway, but not with - the exact parallel-syncs progression as specified. - -See [example configuration](#configuring-redis-sentinel) below. +Assuming that the Redis Sentinel is installed on the same instance as Redis +master with IP `10.0.0.1` (some settings might overlap with the master): + +1. [Install Redis](../../install/installation.md#6-redis) +1. Edit `/etc/redis/redis.conf`: + + ```conf + ## Define a `bind` address pointing to a local IP that your other machines + ## can reach you. If you really need to bind to an external accessible IP, make + ## sure you add extra firewall rules to prevent unauthorized access: + bind 10.0.0.1 + + ## Define a `port` to force Sentinel to listen on TCP so other machines can + ## connect to it (default port is `6379`). + port 26379 + + ## Set up password authentication (use the same password in all nodes). + ## The password should be defined equal for both `requirepass` and `masterauth` + ## when setting up Redis to use with Sentinel. + requirepass redis-password-goes-here + masterauth redis-password-goes-here + + ## Define with `sentinel auth-pass` the same shared password you have + ## defined for both Redis master and slaves instances. + sentinel auth-pass gitlab-redis redis-password-goes-here + + ## Define with `sentinel monitor` the IP and port of the Redis + ## master node, and the quorum required to start a failover. + sentinel monitor gitlab-redis 10.0.0.1 6379 2 + + ## Define with `sentinel down-after-milliseconds` the time in `ms` + ## that an unresponsive server will be considered down. + sentinel down-after-milliseconds gitlab-redis 10000 + + ## Define a value for `sentinel failover_timeout` in `ms`. This has multiple + ## meanings: + ## + ## * The time needed to re-start a failover after a previous failover was + ## already tried against the same master by a given Sentinel, is two + ## times the failover timeout. + ## + ## * The time needed for a slave replicating to a wrong master according + ## to a Sentinel current configuration, to be forced to replicate + ## with the right master, is exactly the failover timeout (counting since + ## the moment a Sentinel detected the misconfiguration). + ## + ## * The time needed to cancel a failover that is already in progress but + ## did not produced any configuration change (SLAVEOF NO ONE yet not + ## acknowledged by the promoted slave). + ## + ## * The maximum time a failover in progress waits for all the slaves to be + ## reconfigured as slaves of the new master. However even after this time + ## the slaves will be reconfigured by the Sentinels anyway, but not with + ## the exact parallel-syncs progression as specified. + sentinel failover_timeout 30000 + ``` +1. Restart the Redis service for the changes to take effect. +1. Go through the steps again for all the other Sentinel nodes. ### Step 4. Configuring the GitLab application @@ -136,17 +184,17 @@ installations. From the GitLab application perspective, all it requires is the correct credentials for the Sentinel nodes. While it doesn't require a list of all Sentinel nodes, in case of a failure, -it needs to access at one of listed ones. +it needs to access at least one of listed ones. ->**Note:** The following steps should be performed in the [GitLab application server](gitlab.md) -which ideally should not have Redis or Sentinels in the same machine for a HA setup. +which ideally should not have Redis or Sentinels in the same machine for a HA +setup: 1. Edit `/home/git/gitlab/config/resque.yml` following the example in `/home/git/gitlab/config/resque.yml.example`, and uncomment the sentinels lines, pointing to the correct server credentials. -1. Restart GitLab for the changes to take effect. +1. [Restart GitLab][restart] for the changes to take effect. ## Example of minimal configuration with 1 master, 2 slaves and 3 Sentinels @@ -156,7 +204,7 @@ to each other using these IPs. In a real world usage, you would also setup firewall rules to prevent unauthorized access from other machines, and block traffic from the -outside (Internet). +outside ([Internet][it]). We will use the same `3` nodes with **Redis** + **Sentinel** topology discussed in the [Configuring Redis for GitLab HA](redis.md) documentation. @@ -165,7 +213,7 @@ Here is a list and description of each **machine** and the assigned **IP**: * `10.0.0.1`: Redis Master + Sentinel 1 * `10.0.0.2`: Redis Slave 1 + Sentinel 2 -* `10.0.0.2`: Redis Slave 2 + Sentinel 3 +* `10.0.0.3`: Redis Slave 2 + Sentinel 3 Please note that after the initial configuration, if a failover is initiated by the Sentinel nodes, the Redis nodes will be reconfigured and the **Master** @@ -296,3 +344,5 @@ When in doubt, please read [Redis Sentinel documentation](http://redis.io/topics [gh-531]: https://github.com/redis/redis-rb/issues/531 [downloads]: https://about.gitlab.com/downloads +[restart]: ../restart_gitlab.md#installations-from-source +[it]: https://gitlab.com/gitlab-org/gitlab-ce/uploads/c4cc8cd353604bd80315f9384035ff9e/The_Internet_IT_Crowd.png -- cgit v1.2.3 From 850405b42ef408785c6133ab7ba9c7f7303f18b6 Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Wed, 16 Nov 2016 12:04:33 +0100 Subject: Merge examples of Redis master/slave + Sentinels for source docs [ci skip] --- .../high_availability/redis_source.md | 173 +++++++++++++-------- 1 file changed, 106 insertions(+), 67 deletions(-) (limited to 'doc/administration') diff --git a/doc/administration/high_availability/redis_source.md b/doc/administration/high_availability/redis_source.md index 1660e26c784..e7a8f47355d 100644 --- a/doc/administration/high_availability/redis_source.md +++ b/doc/administration/high_availability/redis_source.md @@ -24,14 +24,16 @@ the Omnibus Redis HA documentation. **Table of Contents** - [Configuring your own Redis server](#configuring-your-own-redis-server) + - [Prerequisites](#prerequisites) - [Step 1. Configuring the master Redis instance](#step-1-configuring-the-master-redis-instance) - [Step 2. Configuring the slave Redis instances](#step-2-configuring-the-slave-redis-instances) - [Step 3. Configuring the Redis Sentinel instances](#step-3-configuring-the-redis-sentinel-instances) - [Step 4. Configuring the GitLab application](#step-4-configuring-the-gitlab-application) - [Example of minimal configuration with 1 master, 2 slaves and 3 Sentinels](#example-of-minimal-configuration-with-1-master-2-slaves-and-3-sentinels) - - [Configuring Redis Master](#configuring-redis-master) - - [Configuring Redis Slaves](#configuring-redis-slaves) - - [Configuring Redis Sentinel](#configuring-redis-sentinel) + - [Example configuration for Redis master and Sentinel 1](#example-configuration-for-redis-master-and-sentinel-1) + - [Example configuration for Redis slave 1 and Sentinel 2](#example-configuration-for-redis-slave-1-and-sentinel-2) + - [Example configuration for Redis slave 2 and Sentinel 3](#example-configuration-for-redis-slave-2-and-sentinel-3) + - [Example configuration of the GitLab application](#example-configuration-of-the-gitlab-application) - [Troubleshooting](#troubleshooting) @@ -121,8 +123,8 @@ starting with `sentinel` prefix. Assuming that the Redis Sentinel is installed on the same instance as Redis master with IP `10.0.0.1` (some settings might overlap with the master): -1. [Install Redis](../../install/installation.md#6-redis) -1. Edit `/etc/redis/redis.conf`: +1. [Install Redis Sentinel](http://redis.io/topics/sentinel) +1. Edit `/etc/redis/sentinel.conf`: ```conf ## Define a `bind` address pointing to a local IP that your other machines @@ -191,8 +193,24 @@ which ideally should not have Redis or Sentinels in the same machine for a HA setup: 1. Edit `/home/git/gitlab/config/resque.yml` following the example in - `/home/git/gitlab/config/resque.yml.example`, and uncomment the sentinels - lines, pointing to the correct server credentials. + [resque.yml.example][resque], and uncomment the Sentinel lines, pointing to + the correct server credentials: + + ```yaml + # resque.yaml + production: + url: redis://:redi-password-goes-here@gitlab-redis/ + sentinels: + - + host: 10.0.0.1 + port: 26379 # point to sentinel, not to redis port + - + host: 10.0.0.2 + port: 26379 # point to sentinel, not to redis port + - + host: 10.0.0.3 + port: 26379 # point to sentinel, not to redis port + ``` 1. [Restart GitLab][restart] for the changes to take effect. @@ -206,14 +224,16 @@ In a real world usage, you would also setup firewall rules to prevent unauthorized access from other machines, and block traffic from the outside ([Internet][it]). -We will use the same `3` nodes with **Redis** + **Sentinel** topology -discussed in the [Configuring Redis for GitLab HA](redis.md) documentation. +For this example, **Sentinel 1** will be configured in the same machine as the +**Redis Master**, **Sentinel 2** and **Sentinel 3** in the same machines as the +**Slave 1** and **Slave 2** respectively. Here is a list and description of each **machine** and the assigned **IP**: * `10.0.0.1`: Redis Master + Sentinel 1 * `10.0.0.2`: Redis Slave 1 + Sentinel 2 * `10.0.0.3`: Redis Slave 2 + Sentinel 3 +* `10.0.0.4`: GitLab application Please note that after the initial configuration, if a failover is initiated by the Sentinel nodes, the Redis nodes will be reconfigured and the **Master** @@ -224,81 +244,100 @@ The same thing will happen with `sentinel.conf` that will be overridden after th initial execution, after any new sentinel node starts watching the **Master**, or a failover promotes a different **Master** node. -### Configuring Redis Master +### Example configuration for Redis master and Sentinel 1 -**Example configation for Redis Master - `redis.conf`:** +1. In `/etc/redis/redis.conf`: -```conf -bind 10.0.0.1 -port 6379 -requirepass redis-password-goes-here -masterauth redis-password-goes-here -``` + ```conf + bind 10.0.0.1 + port 6379 + requirepass redis-password-goes-here + masterauth redis-password-goes-here + ``` + +1. In `/etc/redis/sentinel.conf`: -### Configuring Redis Slaves + ```conf + bind 10.0.0.1 + port 26379 + sentinel auth-pass gitlab-redis redis-password-goes-here + sentinel monitor gitlab-redis 10.0.0.1 6379 2 + sentinel down-after-milliseconds gitlab-redis 10000 + sentinel failover_timeout 30000 + ``` -**Example configation for Slave 1 - `redis.conf`:** +1. Restart the Redis service for the changes to take effect. -```conf -bind 10.0.0.2 -port 6379 -requirepass redis-password-goes-here -masterauth redis-password-goes-here +### Example configuration for Redis slave 1 and Sentinel 2 -# IP and port of the master Redis server -slaveof 10.0.0.1 6379 -``` +1. In `/etc/redis/redis.conf`: -**Example configation for Slave 2 - `redis.conf`:** + ```conf + bind 10.0.0.2 + port 6379 + requirepass redis-password-goes-here + masterauth redis-password-goes-here + slaveof 10.0.0.1 6379 + ``` -```conf -bind 10.0.0.3 -port 6379 -requirepass redis-password-goes-here -masterauth redis-password-goes-here +1. In `/etc/redis/sentinel.conf`: -# IP and port of the master Redis server -slaveof 10.0.0.1 6379 -``` + ```conf + bind 10.0.0.2 + port 26379 + sentinel auth-pass gitlab-redis redis-password-goes-here + sentinel monitor gitlab-redis 10.0.0.1 6379 2 + sentinel down-after-milliseconds gitlab-redis 10000 + sentinel failover_timeout 30000 + ``` -### Configuring Redis Sentinel +1. Restart the Redis service for the changes to take effect. -For this example, **Sentinel 1** will be configured in the same machine as the -**Redis Master**, **Sentinel 2** and **Sentinel 3** in the same machines as the -**Slave 1** and **Slave 2** respectively. +### Example configuration for Redis slave 2 and Sentinel 3 -**Example configation for Sentinel 1 - `sentinel.conf`:** +1. In `/etc/redis/redis.conf`: -```conf -bind 10.0.0.1 -port 26379 -sentinel auth-pass gitlab-redis redis-password-goes-here -sentinel monitor gitlab-redis 10.0.0.1 6379 2 -sentinel down-after-milliseconds gitlab-redis 10000 -sentinel failover_timeout 30000 -``` + ```conf + bind 10.0.0.3 + port 6379 + requirepass redis-password-goes-here + masterauth redis-password-goes-here + slaveof 10.0.0.1 6379 + ``` -**Example configation for Sentinel 2 - `sentinel.conf`:** +1. In `/etc/redis/sentinel.conf`: -```conf -bind 10.0.0.2 -port 26379 -sentinel auth-pass gitlab-redis redis-password-goes-here -sentinel monitor gitlab-redis 10.0.0.1 6379 2 -sentinel down-after-milliseconds gitlab-redis 10000 -sentinel failover_timeout 30000 -``` + ```conf + bind 10.0.0.3 + port 26379 + sentinel auth-pass gitlab-redis redis-password-goes-here + sentinel monitor gitlab-redis 10.0.0.1 6379 2 + sentinel down-after-milliseconds gitlab-redis 10000 + sentinel failover_timeout 30000 + ``` -**Example configation for Sentinel 3 - `sentinel.conf`:** +1. Restart the Redis service for the changes to take effect. -```conf -bind 10.0.0.3 -port 26379 -sentinel auth-pass gitlab-redis redis-password-goes-here -sentinel monitor gitlab-redis 10.0.0.1 6379 2 -sentinel down-after-milliseconds gitlab-redis 10000 -sentinel failover_timeout 30000 -``` +### Example configuration of the GitLab application + +1. Edit `/home/git/gitlab/config/resque.yml`: + + ```yaml + production: + url: redis://:redi-password-goes-here@gitlab-redis/ + sentinels: + - + host: 10.0.0.1 + port: 26379 # point to sentinel, not to redis port + - + host: 10.0.0.2 + port: 26379 # point to sentinel, not to redis port + - + host: 10.0.0.3 + port: 26379 # point to sentinel, not to redis port + ``` + +1. [Restart GitLab][restart] for the changes to take effect. ## Troubleshooting -- cgit v1.2.3