Update Redis section with cluster info

doc/administration/reference_architectures/10k_users.md

@@ -51,10 +51,7 @@ To set up GitLab and its components to accommodate up to 10,000 users:
 1. [Configure PostgreSQL](#configure-postgresql), the database for GitLab.
 1. [Configure PgBouncer](#configure-pgbouncer).
 1. [Configure the internal load balancing node](#configure-the-internal-load-balancer)
-1. [Configure Redis Cache](#configure-redis-cache).
-1. [Configure Redis Queues](#configure-redis-queues).
-1. [Configure Sentinel Cache](#configure-sentinel-cache).
-1. [Configure Sentinel Queues](#configure-sentinel-queues).
+1. [Configure Redis](#configure-redis).
 1. [Configure Gitaly](#configure-gitaly),
    which provides access to the Git repositories.
 1. [Configure Sidekiq](#configure-sidekiq).
@@ -88,12 +85,12 @@ Here is a list and description of each machine and the assigned IP:
 - `10.6.0.51`: Redis - Cache Primary
 - `10.6.0.52`: Redis - Cache Replica 1
 - `10.6.0.53`: Redis - Cache Replica 2
-- `10.6.0.61`: Redis - Queues Primary
-- `10.6.0.62`: Redis - Queues Replica 1
-- `10.6.0.63`: Redis - Queues Replica 2
 - `10.6.0.71`: Sentinel - Cache 1
 - `10.6.0.72`: Sentinel - Cache 2
 - `10.6.0.73`: Sentinel - Cache 3
+- `10.6.0.61`: Redis - Queues Primary
+- `10.6.0.62`: Redis - Queues Replica 1
+- `10.6.0.63`: Redis - Queues Replica 2
 - `10.6.0.81`: Sentinel - Queues 1
 - `10.6.0.82`: Sentinel - Queues 2
 - `10.6.0.83`: Sentinel - Queues 3
@@ -761,11 +758,17 @@ to be used with GitLab. The following IPs will be used as an example:
 - `10.6.0.51`: Redis - Cache Primary
 - `10.6.0.52`: Redis - Cache Replica 1
 - `10.6.0.53`: Redis - Cache Replica 2
+- `10.6.0.71`: Sentinel - Cache 1
+- `10.6.0.72`: Sentinel - Cache 2
+- `10.6.0.73`: Sentinel - Cache 3
 - `10.6.0.61`: Redis - Queues Primary
 - `10.6.0.62`: Redis - Queues Replica 1
 - `10.6.0.63`: Redis - Queues Replica 2
+- `10.6.0.81`: Sentinel - Queues 1
+- `10.6.0.82`: Sentinel - Queues 2
+- `10.6.0.83`: Sentinel - Queues 3
 
-NOTE: **Provide your own Redis instance:**
+NOTE: **Providing your own Redis instance:**
 Managed Redis from cloud providers such as AWS ElastiCache will work. If these
 services support high availability, be sure it is **not** the Redis Cluster type.
 Redis version 5.0 or higher is required, as this is what ships with
@@ -776,7 +779,7 @@ Note the Redis node's IP address or hostname, port, and password (if required).
 These will be necessary when configuring the
 [GitLab application servers](#configure-gitlab-rails) later.
 
-### Configure Redis Cache
+### Configure the Redis and Sentinel Cache cluster
 
 This is the section where we install and set up the new Redis Cache instances.
 
@@ -785,7 +788,7 @@ Redis nodes (both primary and replica) will need the same password defined in
 `redis['password']`. At any time during a failover the Sentinels can
 reconfigure a node and change its status from primary to replica and vice versa.
 
-#### Configuring the primary Redis Cache instance
+#### Configure the primary Redis Cache node
 
 1. SSH into the **Primary** Redis server.
 1. [Download/install](https://about.gitlab.com/install/) the Omnibus GitLab
@@ -804,14 +807,14 @@ reconfigure a node and change its status from primary to replica and vice versa.
    # 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.6.0.61'
+   redis['bind'] = '10.6.0.51'
 
    # 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'
+   redis['password'] = 'REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER'
 
    ## Enable service discovery for Prometheus
    consul['enable'] = true
@@ -843,7 +846,7 @@ You can specify multiple roles like sentinel and Redis as:
 `roles ['redis_sentinel_role', 'redis_master_role']`.
 Read more about [roles](https://docs.gitlab.com/omnibus/roles/).
 
-#### Configuring the replica Redis Cache instances
+#### Configure the replica Redis Cache nodes
 
 1. SSH into the **replica** Redis server.
 1. [Download/install](https://about.gitlab.com/install/) the Omnibus GitLab
@@ -862,17 +865,17 @@ Read more about [roles](https://docs.gitlab.com/omnibus/roles/).
    # 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.6.0.62'
+   redis['bind'] = '10.6.0.52'
 
    # Define a port so Redis can listen for TCP requests which will allow other
    # machines to connect to it.
    redis['port'] = 6379
 
    # The same password for Redis authentication you set up for the primary node.
-   redis['password'] = 'redis-password-goes-here'
+   redis['password'] = 'REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER'
 
    # The IP of the primary Redis node.
-   redis['master_ip'] = '10.6.0.61'
+   redis['master_ip'] = '10.6.0.51'
 
    # Port of primary Redis server, uncomment to change to non default. Defaults
    # to `6379`.
@@ -909,7 +912,7 @@ You can specify multiple roles like sentinel and Redis as:
 Read more about [roles](https://docs.gitlab.com/omnibus/roles/).
 
 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](#configure-sentinel-cache), and even after a
+a failover, as the nodes will be managed by the [Sentinels](#configure-the-sentinel-cache-nodes), and even after a
 `gitlab-ctl reconfigure`, they will get their configuration restored by
 the same Sentinels.
 
@@ -922,7 +925,135 @@ are supported and can be added if needed.
   </a>
 </div>
 
-### Configure Redis Queues
+#### Configure the Sentinel Cache nodes
+
+NOTE: **Note:**
+If you are using an external Redis Sentinel instance, be sure
+to exclude the `requirepass` parameter from the Sentinel
+configuration. This parameter will cause clients to report `NOAUTH
+Authentication required.`. [Redis Sentinel 3.2.x does not support
+password authentication](https://github.com/antirez/redis/issues/3279).
+
+Now that the Redis servers are all set up, let's configure the Sentinel
+servers. The following IPs will be used as an example:
+
+- `10.6.0.71`: Sentinel - Cache 1
+- `10.6.0.72`: Sentinel - Cache 2
+- `10.6.0.73`: Sentinel - Cache 3
+
+To configure the Sentinel Cache server:
+
+1. SSH into the server that will host Consul/Sentinel.
+1. [Download/install](https://about.gitlab.com/install/) 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.
+
+1. Edit `/etc/gitlab/gitlab.rb` and add the contents:
+
+   ```ruby
+   roles ['redis_sentinel_role']
+
+   ## Must be the same in every sentinel node
+   redis['master_name'] = 'gitlab-redis-cache'
+
+   ## The same password for Redis authentication you set up for the primary node.
+   redis['master_password'] = 'REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER'
+
+   ## The IP of the primary Redis node.
+   redis['master_ip'] = '10.6.0.51'
+
+   ## Define a port so Redis can listen for TCP requests which will allow other
+   ## machines to connect to it.
+   redis['port'] = 6379
+
+   ## Port of primary Redis server, uncomment to change to non default. Defaults
+   ## to `6379`.
+   #redis['master_port'] = 6379
+
+   ## Configure Sentinel's IP
+   sentinel['bind'] = '10.6.0.71'
+
+   ## 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 primary failures,
+   ##    triggering a failover as soon as even just a minority of Sentinels is no longer
+   ##    able to talk with the primary.
+   ## 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 primary 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 primary by a given Sentinel, is two
+   ##   times the failover timeout.
+   ##
+   ## - The time needed for a replica replicating to a wrong primary according
+   ##   to a Sentinel current configuration, to be forced to replicate
+   ##   with the right primary, 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 (REPLICAOF NO ONE yet not
+   ##   acknowledged by the promoted replica).
+   ##
+   ## - The maximum time a failover in progress waits for all the replica to be
+   ##   reconfigured as replicas of the new primary. However even after this time
+   ##   the replicas will be reconfigured by the Sentinels anyway, but not with
+   ##   the exact parallel-syncs progression as specified.
+   #sentinel['failover_timeout'] = 60000
+
+   ## Enable service discovery for Prometheus
+   consul['enable'] = true
+   consul['monitoring_service_discovery'] =  true
+
+   ## The IPs of the Consul server nodes
+   ## You can also use FQDNs and intermix them with IPs
+   consul['configuration'] = {
+      retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
+   }
+
+   # Set the network addresses that the exporters will listen on
+   node_exporter['listen_address'] = '0.0.0.0:9100'
+   redis_exporter['listen_address'] = '0.0.0.0:9121'
+
+   # Disable auto migrations
+   gitlab_rails['auto_migrate'] = false
+   ```
+
+1. To prevent database migrations from running on upgrade, run:
+
+   ```shell
+   sudo touch /etc/gitlab/skip-auto-reconfigure
+   ```
+
+   Only the primary GitLab application server should handle migrations.
+
+1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+1. Go through the steps again for all the other Consul/Sentinel nodes, and
+   make sure you set up the correct IPs.
+
+<div align="right">
+  <a type="button" class="btn btn-default" href="#setup-components">
+    Back to setup components <i class="fa fa-angle-double-up" aria-hidden="true"></i>
+  </a>
+</div>
+
+### Configure the Redis and Sentinel Queues cluster
 
 This is the section where we install and set up the new Redis Queues instances.
 
@@ -931,7 +1062,7 @@ Redis nodes (both primary and replica) will need the same password defined in
 `redis['password']`. At any time during a failover the Sentinels can
 reconfigure a node and change its status from primary to replica and vice versa.
 
-#### Configuring the primary Redis Queues instance
+#### Configure the primary Redis Queues node
 
 1. SSH into the **Primary** Redis server.
 1. [Download/install](https://about.gitlab.com/install/) the Omnibus GitLab
@@ -957,7 +1088,7 @@ reconfigure a node and change its status from primary to replica and vice versa.
    redis['port'] = 6379
 
    # Set up password authentication for Redis (use the same password in all nodes).
-   redis['password'] = 'redis-password-goes-here'
+   redis['password'] = 'REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER'
 
    ## Enable service discovery for Prometheus
    consul['enable'] = true
@@ -989,7 +1120,7 @@ You can specify multiple roles like sentinel and Redis as:
 `roles ['redis_sentinel_role', 'redis_master_role']`.
 Read more about [roles](https://docs.gitlab.com/omnibus/roles/).
 
-#### Configuring the replica Redis Queues instances
+#### Configure the replica Redis Queues nodes
 
 1. SSH into the **replica** Redis Queue server.
 1. [Download/install](https://about.gitlab.com/install/) the Omnibus GitLab
@@ -1015,7 +1146,7 @@ Read more about [roles](https://docs.gitlab.com/omnibus/roles/).
    redis['port'] = 6379
 
    # The same password for Redis authentication you set up for the primary node.
-   redis['password'] = 'redis-password-goes-here'
+   redis['password'] = 'REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER'
 
    # The IP of the primary Redis node.
    redis['master_ip'] = '10.6.0.61'
@@ -1055,7 +1186,7 @@ You can specify multiple roles like sentinel and Redis as:
 Read more about [roles](https://docs.gitlab.com/omnibus/roles/).
 
 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](#configure-sentinel-cache), and even after a
+a failover, as the nodes will be managed by the [Sentinels](#configure-the-sentinel-queues-nodes), and even after a
 `gitlab-ctl reconfigure`, they will get their configuration restored by
 the same Sentinels.
 
@@ -1068,135 +1199,7 @@ are supported and can be added if needed.
   </a>
 </div>
 
-### Configure Sentinel Cache
-
-NOTE: **Note:**
-If you are using an external Redis Sentinel instance, be sure
-to exclude the `requirepass` parameter from the Sentinel
-configuration. This parameter will cause clients to report `NOAUTH
-Authentication required.`. [Redis Sentinel 3.2.x does not support
-password authentication](https://github.com/antirez/redis/issues/3279).
-
-Now that the Redis servers are all set up, let's configure the Sentinel
-servers. The following IPs will be used as an example:
-
-- `10.6.0.71`: Sentinel - Cache 1
-- `10.6.0.72`: Sentinel - Cache 2
-- `10.6.0.73`: Sentinel - Cache 3
-
-To configure the Sentinel Cache server:
-
-1. SSH into the server that will host Consul/Sentinel.
-1. [Download/install](https://about.gitlab.com/install/) 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.
-
-1. Edit `/etc/gitlab/gitlab.rb` and add the contents:
-
-   ```ruby
-   roles ['redis_sentinel_role', 'consul_role']
-
-   # Must be the same in every sentinel node
-   redis['master_name'] = 'gitlab-redis'
-
-   # The same password for Redis authentication you set up for the primary node.
-   redis['master_password'] = 'redis-password-goes-here'
-
-   # The IP of the primary Redis node.
-   redis['master_ip'] = '10.6.0.61'
-
-   # Define a port so Redis can listen for TCP requests which will allow other
-   # machines to connect to it.
-   redis['port'] = 6379
-
-   # Port of primary Redis server, uncomment to change to non default. Defaults
-   # to `6379`.
-   #redis['master_port'] = 6379
-
-   ## Configure Sentinel
-   sentinel['bind'] = '10.6.0.11'
-
-   # 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 primary failures,
-   ##    triggering a failover as soon as even just a minority of Sentinels is no longer
-   ##    able to talk with the primary.
-   ## 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 primary 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 primary by a given Sentinel, is two
-   ##   times the failover timeout.
-   ##
-   ## - The time needed for a replica replicating to a wrong primary according
-   ##   to a Sentinel current configuration, to be forced to replicate
-   ##   with the right primary, 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 (REPLICAOF NO ONE yet not
-   ##   acknowledged by the promoted replica).
-   ##
-   ## - The maximum time a failover in progress waits for all the replica to be
-   ##   reconfigured as replicas of the new primary. However even after this time
-   ##   the replicas will be reconfigured by the Sentinels anyway, but not with
-   ##   the exact parallel-syncs progression as specified.
-   # sentinel['failover_timeout'] = 60000
-
-   ## Enable service discovery for Prometheus
-   consul['enable'] = true
-   consul['monitoring_service_discovery'] =  true
-
-   ## The IPs of the Consul server nodes
-   ## You can also use FQDNs and intermix them with IPs
-   consul['configuration'] = {
-      retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
-   }
-
-   # Set the network addresses that the exporters will listen on
-   node_exporter['listen_address'] = '0.0.0.0:9100'
-   redis_exporter['listen_address'] = '0.0.0.0:9121'
-
-   # Disable auto migrations
-   gitlab_rails['auto_migrate'] = false
-   ```
-
-1. To prevent database migrations from running on upgrade, run:
-
-   ```shell
-   sudo touch /etc/gitlab/skip-auto-reconfigure
-   ```
-
-   Only the primary GitLab application server should handle migrations.
-
-1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
-1. Go through the steps again for all the other Consul/Sentinel nodes, and
-   make sure you set up the correct IPs.
-
-<div align="right">
-  <a type="button" class="btn btn-default" href="#setup-components">
-    Back to setup components <i class="fa fa-angle-double-up" aria-hidden="true"></i>
-  </a>
-</div>
-
-### Configure Sentinel Queues
+#### Configure the Sentinel Queues nodes
 
 NOTE: **Note:**
 If you are using an external Redis Sentinel instance, be sure
@@ -1212,9 +1215,9 @@ servers. The following IPs will be used as an example:
 - `10.6.0.82`: Sentinel - Queues 2
 - `10.6.0.83`: Sentinel - Queues 3
 
-To configure the Sentinel Cache server:
+To configure the Sentinel Queues server:
 
-1. SSH into the server that will host Consul/Sentinel.
+1. SSH into the server that will host Sentinel.
 1. [Download/install](https://about.gitlab.com/install/) the
    Omnibus GitLab Enterprise Edition package using **steps 1 and 2** from the
    GitLab downloads page.
@@ -1225,31 +1228,31 @@ To configure the Sentinel Cache server:
 1. Edit `/etc/gitlab/gitlab.rb` and add the contents:
 
    ```ruby
-   roles ['redis_sentinel_role', 'consul_role']
+   roles ['redis_sentinel_role']
 
-   # Must be the same in every sentinel node
-   redis['master_name'] = 'gitlab-redis'
+   ## Must be the same in every sentinel node
+   redis['master_name'] = 'gitlab-redis-persistent'
 
-   # The same password for Redis authentication you set up for the primary node.
-   redis['master_password'] = 'redis-password-goes-here'
+   ## The same password for Redis authentication you set up for the primary node.
+   redis['master_password'] = 'REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER'
 
-   # The IP of the primary Redis node.
+   ## The IP of the primary Redis node.
    redis['master_ip'] = '10.6.0.61'
 
-   # Define a port so Redis can listen for TCP requests which will allow other
-   # machines to connect to it.
+   ## Define a port so Redis can listen for TCP requests which will allow other
+   ## machines to connect to it.
    redis['port'] = 6379
 
-   # Port of primary Redis server, uncomment to change to non default. Defaults
-   # to `6379`.
+   ## Port of primary Redis server, uncomment to change to non default. Defaults
+   ## to `6379`.
    #redis['master_port'] = 6379
 
-   ## Configure Sentinel
-   sentinel['bind'] = '10.6.0.11'
+   ## Configure Sentinel's IP
+   sentinel['bind'] = '10.6.0.81'
 
-   # Port that Sentinel listens on, uncomment to change to non default. Defaults
-   # to `26379`.
-   # sentinel['port'] = 26379
+   ## 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.
@@ -1265,7 +1268,7 @@ To configure the Sentinel Cache server:
    sentinel['quorum'] = 2
 
    ## Consider unresponsive server down after x amount of ms.
-   # sentinel['down_after_milliseconds'] = 10000
+   #sentinel['down_after_milliseconds'] = 10000
 
    ## Specifies the failover timeout in milliseconds. It is used in many ways:
    ##
@@ -1286,7 +1289,7 @@ To configure the Sentinel Cache server:
    ##   reconfigured as replicas of the new primary. However even after this time
    ##   the replicas will be reconfigured by the Sentinels anyway, but not with
    ##   the exact parallel-syncs progression as specified.
-   # sentinel['failover_timeout'] = 60000
+   #sentinel['failover_timeout'] = 60000
 
    ## Enable service discovery for Prometheus
    consul['enable'] = true
@@ -1660,35 +1663,10 @@ The following IPs will be used as an example:
 
 On each node perform the following:
 
-1. If you're [using NFS](#configure-nfs-optional):
-
-   1. If necessary, install the NFS client utility packages using the following
-      commands:
-
-      ```shell
-      # Ubuntu/Debian
-      apt-get install nfs-common
-
-      # CentOS/Red Hat
-      yum install nfs-utils nfs-utils-lib
-      ```
-
-   1. Specify the necessary NFS mounts in `/etc/fstab`.
-      The exact contents of `/etc/fstab` will depend on how you chose
-      to configure your NFS server. See the [NFS documentation](../high_availability/nfs.md)
-      for examples and the various options.
-
-   1. Create the shared directories. These may be different depending on your NFS
-      mount locations.
-
-      ```shell
-      mkdir -p /var/opt/gitlab/.ssh /var/opt/gitlab/gitlab-rails/uploads /var/opt/gitlab/gitlab-rails/shared /var/opt/gitlab/gitlab-ci/builds /var/opt/gitlab/git-data
-      ```
-
 1. Download/install Omnibus GitLab using **steps 1 and 2** from
    [GitLab downloads](https://about.gitlab.com/install/). Do not complete other
    steps on the download page.
-1. Create/edit `/etc/gitlab/gitlab.rb` and use the following configuration.
+1. Edit `/etc/gitlab/gitlab.rb` and use the following configuration.
    To maintain uniformity of links across nodes, the `external_url`
    on the application server should point to the external URL that users will use
    to access GitLab. This would be the URL of the [external load balancer](#configure-the-external-load-balancer)
@@ -1724,17 +1702,34 @@ On each node perform the following:
    gitlab_rails['auto_migrate'] = false
 
    ## Redis connection details
-   ## Must be the same in every sentinel node
-   redis['master_name'] = 'gitlab-redis'
+   ## First cluster that will host the cache
+   gitlab_rails['redis_cache_instance'] = 'redis://:<REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER>@gitlab-redis-cache'
 
-   ## The same password for Redis authentication you set up for the Redis primary node.
-   redis['master_password'] = '<redis_primary_password>'
+   gitlab_rails['redis_cache_sentinels'] = [
+     {host: '10.6.0.71', port: 26379},
+     {host: '10.6.0.72', port: 26379},
+     {host: '10.6.0.73', port: 26379},
+   ]
 
-   ## A list of sentinels with `host` and `port`
-   gitlab_rails['redis_sentinels'] = [
-     {'host' => '10.6.0.11', 'port' => 26379},
-     {'host' => '10.6.0.12', 'port' => 26379},
-     {'host' => '10.6.0.13', 'port' => 26379}
+   ## Second cluster that will host the queues, shared state, and actionable
+   gitlab_rails['redis_queues_instance'] = 'redis://:<REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER>@gitlab-redis-persistent'
+   gitlab_rails['redis_shared_state_instance'] = 'redis://:<REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER>@gitlab-redis-persistent'
+   gitlab_rails['redis_actioncable_instance'] = 'redis://:<REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER>@gitlab-redis-persistent'
+
+   gitlab_rails['redis_queues_sentinels'] = [
+     {host: '10.6.0.81', port: 26379},
+     {host: '10.6.0.82', port: 26379},
+     {host: '10.6.0.83', port: 26379},
+   ]
+   gitlab_rails['redis_shared_state_sentinels'] = [
+     {host: '10.6.0.81', port: 26379},
+     {host: '10.6.0.82', port: 26379},
+     {host: '10.6.0.83', port: 26379},
+   ]
+   gitlab_rails['redis_actioncable_sentinels'] = [
+     {host: '10.6.0.81', port: 26379},
+     {host: '10.6.0.82', port: 26379},
+     {host: '10.6.0.83', port: 26379},
    ]
 
    # Set the network addresses that the exporters used for monitoring will listen on
@@ -1747,21 +1742,6 @@ On each node perform the following:
    # scrape the NGINX metrics
    gitlab_rails['monitoring_whitelist'] = ['10.6.0.81/32', '127.0.0.0/8']
    nginx['status']['options']['allow'] = ['10.6.0.81/32', '127.0.0.0/8']
-
-   ## Uncomment and edit the following options if you have set up NFS
-   ##
-   ## Prevent GitLab from starting if NFS data mounts are not available
-   ##
-   #high_availability['mountpoint'] = '/var/opt/gitlab/git-data'
-   ##
-   ## Ensure UIDs and GIDs match between servers for permissions via NFS
-   ##
-   #user['uid'] = 9000
-   #user['gid'] = 9000
-   #web_server['uid'] = 9001
-   #web_server['gid'] = 9001
-   #registry['uid'] = 9002
-   #registry['gid'] = 9002
    ```
 
 1. If you're using [Gitaly with TLS support](#gitaly-tls-support), make sure the
@@ -1781,6 +1761,45 @@ On each node perform the following:
       sudo cp cert.pem /etc/gitlab/trusted-certs/
       ```
 
+1. If you're [using NFS](#configure-nfs-optional):
+   1. If necessary, install the NFS client utility packages using the following
+      commands:
+
+      ```shell
+      # Ubuntu/Debian
+      apt-get install nfs-common
+
+      # CentOS/Red Hat
+      yum install nfs-utils nfs-utils-lib
+      ```
+
+   1. Specify the necessary NFS mounts in `/etc/fstab`.
+      The exact contents of `/etc/fstab` will depend on how you chose
+      to configure your NFS server. See the [NFS documentation](../high_availability/nfs.md)
+      for examples and the various options.
+
+   1. Create the shared directories. These may be different depending on your NFS
+      mount locations.
+
+      ```shell
+      mkdir -p /var/opt/gitlab/.ssh /var/opt/gitlab/gitlab-rails/uploads /var/opt/gitlab/gitlab-rails/shared /var/opt/gitlab/gitlab-ci/builds /var/opt/gitlab/git-data
+      ```
+
+   1. Edit `/etc/gitlab/gitlab.rb` and use the following configuration:
+
+      ```ruby
+      ## Prevent GitLab from starting if NFS data mounts are not available
+      high_availability['mountpoint'] = '/var/opt/gitlab/git-data'
+
+      ## Ensure UIDs and GIDs match between servers for permissions via NFS
+      user['uid'] = 9000
+      user['gid'] = 9000
+      web_server['uid'] = 9001
+      web_server['gid'] = 9001
+      registry['uid'] = 9002
+      registry['gid'] = 9002
+      ```
+
 1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
 1. Run `sudo gitlab-rake gitlab:gitaly:check` to confirm the node can connect to Gitaly.
 1. Tail the logs to see the requests:
@@ -1798,10 +1817,10 @@ for more information.
 
 ### GitLab Rails post-configuration
 
-Ensure that all migrations ran:
+Ensure that all migrations ran, by running the following in one of the Rails nodes:
 
 ```shell
-gitlab-rake gitlab:db:configure
+sudo gitlab-rake gitlab:db:configure
 ```
 
 NOTE: **Note:**