Merge branch 'eread/remove-ha-from-geo-docs' into 'master'

Remove HA references from Geo docs

See merge request gitlab-org/gitlab!32269

doc/administration/geo/replication/geo_validation_tests.md

@@ -11,37 +11,36 @@ The following are GitLab upgrade validation tests we performed.
 
 ### February 2020
 
-[Upgrade Geo HA installation](https://gitlab.com/gitlab-org/gitlab/-/issues/201837):
+[Upgrade Geo multi-server installation](https://gitlab.com/gitlab-org/gitlab/-/issues/201837):
 
-- Description: Tested upgrading from GitLab 12.7.5 to the latest GitLab 12.8 package in a high
-  availability configuration.
+- Description: Tested upgrading from GitLab 12.7.5 to the latest GitLab 12.8 package in a multi-server
+  configuration.
 - Outcome: Partial success because we did not run the looping pipeline during the demo to monitor
   downtime.
 
 ### January 2020
 
-[Upgrade Geo HA installation](https://gitlab.com/gitlab-org/gitlab/-/issues/200085):
+[Upgrade Geo multi-server installation](https://gitlab.com/gitlab-org/gitlab/-/issues/200085):
 
-- Description: Tested upgrading from GitLab 12.6.x to the latest GitLab 12.7 package in a high
-  availability configuration.
+- Description: Tested upgrading from GitLab 12.6.x to the latest GitLab 12.7 package in a multi-server
+  configuration.
 - Outcome: Upgrade test was successful.
 - Follow up issues:
   - [Investigate Geo end-to-end test failures](https://gitlab.com/gitlab-org/gitlab/issues/201823).
   - [Add more logging to Geo end-to-end tests](https://gitlab.com/gitlab-org/gitlab/issues/201830).
   - [Excess service restarts during zero-downtime upgrade](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5047).
 
-[Upgrade Geo HA installation](https://gitlab.com/gitlab-org/gitlab/-/issues/199836):
+[Upgrade Geo multi-server installation](https://gitlab.com/gitlab-org/gitlab/-/issues/199836):
 
-- Description: Tested upgrading from GitLab 12.5.7 to GitLab 12.6.6 in a high availability
-  configuration.
+- Description: Tested upgrading from GitLab 12.5.7 to GitLab 12.6.6 in a multi-server configuration.
 - Outcome: Upgrade test was successful.
 - Follow up issue:
   [Update documentation for zero-downtime upgrades to ensure deploy node it not in use](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5046).
 
-[Upgrade Geo HA installation](https://gitlab.com/gitlab-org/gitlab/-/issues/37044):
+[Upgrade Geo multi-server installation](https://gitlab.com/gitlab-org/gitlab/-/issues/37044):
 
-- Description: Tested upgrading from GitLab 12.4.x to the latest GitLab 12.5 package in a high
-  availability configuration.
+- Description: Tested upgrading from GitLab 12.4.x to the latest GitLab 12.5 package in a multi-server
+  configuration.
 - Outcome: Upgrade test was successful.
 - Follow up issues:
   - [Investigate why HTTP push spec failed on primary node](https://gitlab.com/gitlab-org/gitlab/issues/199825).
@@ -49,17 +48,17 @@ The following are GitLab upgrade validation tests we performed.
 
 ### October 2019
 
-[Upgrade Geo HA installation](https://gitlab.com/gitlab-org/gitlab/-/issues/35262):
+[Upgrade Geo multi-server installation](https://gitlab.com/gitlab-org/gitlab/-/issues/35262):
 
-- Description: Tested upgrading from GitLab 12.3.5 to GitLab 12.4.1 in a high availability configuration.
+- Description: Tested upgrading from GitLab 12.3.5 to GitLab 12.4.1 in a multi-server configuration.
 - Outcome: Upgrade test was successful.
 
-[Upgrade Geo HA installation](https://gitlab.com/gitlab-org/gitlab/-/issues/32437):
+[Upgrade Geo multi-server installation](https://gitlab.com/gitlab-org/gitlab/-/issues/32437):
 
 - Description: Tested upgrading from GitLab 12.2.8 to GitLab 12.3.5.
 - Outcome: Upgrade test was successful.
 
-[Upgrade Geo HA installation](https://gitlab.com/gitlab-org/gitlab/-/issues/32435):
+[Upgrade Geo multi-server installation](https://gitlab.com/gitlab-org/gitlab/-/issues/32435):
 
 - Description: Tested upgrading from GitLab 12.1.9 to GitLab 12.2.8.
 - Outcome: Partial success due to possible misconfiguration issues.
@@ -74,7 +73,7 @@ The following are PostgreSQL upgrade validation tests we performed.
 
 - Description: Prior to making PostgreSQL 11 the default version of PostgreSQL in GitLab 12.10, we
   tested upgrading to PostgreSQL 11 in Geo deployments on GitLab 12.9.
-- Outcome: Partially successful. Issues were discovered in HA configurations with a separate
+- Outcome: Partially successful. Issues were discovered in multi-server configurations with a separate
   tracking database and concerns were raised about allowing automatic upgrades when Geo enabled.
 - Follow up issues:
   - [`replicate-geo-database` incorrectly tries to back up repositories](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5241).
@@ -96,6 +95,6 @@ The following are PostgreSQL upgrade validation tests we performed.
   various upgrade scenarios from GitLab 11.11.5 through to GitLab 12.1.8.
 - Outcome: Multiple issues were found when upgrading and addressed in follow-up issues.
 - Follow up issues:
-  - [`gitlab-ctl` reconfigure fails on Redis node in HA Geo setup](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/4706).
-  - [HA with Geo upgrade from 12.0.9 to 12.1.9 does not upgrade PostgreSQL](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/4705).
-  - [Refresh foreign tables fails on app server in HA setup after upgrade to 12.1.9](https://gitlab.com/gitlab-org/gitlab/-/issues/32119).
+  - [`gitlab-ctl` reconfigure fails on Redis node in multi-server Geo setup](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/4706).
+  - [Geo multi-server upgrade from 12.0.9 to 12.1.9 does not upgrade PostgreSQL](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/4705).
+  - [Refresh foreign tables fails on app server in multi-server setup after upgrade to 12.1.9](https://gitlab.com/gitlab-org/gitlab/-/issues/32119).

doc/administration/geo/replication/high_availability.md

-# Geo High Availability **(PREMIUM ONLY)**
+# Geo for multiple servers **(PREMIUM ONLY)**
 
 This document describes a minimal reference architecture for running Geo
-in a high availability configuration. If your HA setup differs from the one
+in a multi-server configuration. If your multi-server setup differs from the one
 described, it is possible to adapt these instructions to your needs.
 
 ## Architecture overview
 
-![Geo HA Diagram](../../high_availability/img/geo-ha-diagram.png)
+![Geo multi-server diagram](../../high_availability/img/geo-ha-diagram.png)
 
 _[diagram source - GitLab employees only](https://docs.google.com/drawings/d/1z0VlizKiLNXVVVaERFwgsIOuEgjcUqDTWPdQYsE7Z4c/edit)_
 
@@ -23,36 +23,36 @@ The only external way to access the two Geo deployments is by HTTPS at
 NOTE: **Note:**
 The **primary** and **secondary** Geo deployments must be able to communicate to each other over HTTPS.
 
-## Redis and PostgreSQL High Availability
+## Redis and PostgreSQL for multiple servers
 
 Geo supports:
 
-- Redis and PostgreSQL on the **primary** node configured for high availability
-- Redis on **secondary** nodes configured for high availability.
+- Redis and PostgreSQL on the **primary** node configured for multiple servers.
+- Redis on **secondary** nodes configured for multiple servers.
 
 NOTE: **Note:**
-Support for PostgreSQL on **secondary** nodes in high availability configuration
+Support for PostgreSQL on **secondary** nodes in multi-server configuration
 [is planned](https://gitlab.com/groups/gitlab-org/-/epics/2536).
 
 Because of the additional complexity involved in setting up this configuration
-for PostgreSQL and Redis, it is not covered by this Geo HA documentation.
+for PostgreSQL and Redis, it is not covered by this Geo multi-server documentation.
 
-For more information about setting up a highly available PostgreSQL cluster and Redis cluster using the omnibus package see the high availability documentation for
+For more information about setting up a multi-server PostgreSQL cluster and Redis cluster using the omnibus package see the multi-server documentation for
 [PostgreSQL](../../high_availability/database.md) and
 [Redis](../../high_availability/redis.md), respectively.
 
 NOTE: **Note:**
 It is possible to use cloud hosted services for PostgreSQL and Redis, but this is beyond the scope of this document.
 
-## Prerequisites: Two working GitLab HA clusters
+## Prerequisites: Two working GitLab multi-server clusters
 
 One cluster will serve as the **primary** node. Use the
-[GitLab HA documentation](../../reference_architectures/index.md) to set this up. If
+[GitLab multi-server documentation](../../reference_architectures/index.md) to set this up. If
 you already have a working GitLab instance that is in-use, it can be used as a
 **primary**.
 
 The second cluster will serve as the **secondary** node. Again, use the
-[GitLab HA documentation](../../reference_architectures/index.md) to set this up.
+[GitLab multi-server documentation](../../reference_architectures/index.md) to set this up.
 It's a good idea to log in and test it, however, note that its data will be
 wiped out as part of the process of replicating from the **primary**.
 
@@ -85,8 +85,8 @@ After making these changes, [reconfigure GitLab](../../restart_gitlab.md#omnibus
 
 NOTE: **Note:** PostgreSQL and Redis should have already been disabled on the
 application servers, and connections from the application servers to those
-services on the backend servers configured, during normal GitLab HA set up. See
-high availability configuration documentation for
+services on the backend servers configured, during normal GitLab multi-server set up. See
+multi-server configuration documentation for
 [PostgreSQL](../../high_availability/database.md#configuring-the-application-nodes)
 and [Redis](../../high_availability/redis.md#example-configuration-for-the-gitlab-application).
 
@@ -103,7 +103,7 @@ and [Redis](../../high_availability/redis.md#example-configuration-for-the-gitla
 
 ## Configure a **secondary** node
 
-A **secondary** cluster is similar to any other GitLab HA cluster, with two
+A **secondary** cluster is similar to any other GitLab multi-server cluster, with two
 major differences:
 
 - The main PostgreSQL database is a read-only replica of the **primary** node's
@@ -112,8 +112,8 @@ major differences:
   called the "tracking database", which tracks the synchronization state of
   various resources.
 
-Therefore, we will set up the HA components one-by-one, and include deviations
-from the normal HA setup. However, we highly recommend first configuring a
+Therefore, we will set up the multi-server components one-by-one, and include deviations
+from the normal multi-server setup. However, we highly recommend first configuring a
 brand-new cluster as if it were not part of a Geo setup so that it can be
 tested and verified as a working cluster. And only then should it be modified
 for use as a Geo **secondary**. This helps to separate problems that are related
@@ -121,11 +121,10 @@ and are not related to Geo setup.
 
 ### Step 1: Configure the Redis and Gitaly services on the **secondary** node
 
-Configure the following services, again using the non-Geo high availability
+Configure the following services, again using the non-Geo multi-server
 documentation:
 
-- [Configuring Redis for GitLab HA](../../high_availability/redis.md) for high
-  availability.
+- [Configuring Redis for GitLab](../../high_availability/redis.md) for multiple servers.
 - [Gitaly](../../high_availability/gitaly.md), which will store data that is
   synchronized from the **primary** node.
 
@@ -136,7 +135,7 @@ recommended.
 ### Step 2: Configure the main read-only replica PostgreSQL database on the **secondary** node
 
 NOTE: **Note:** The following documentation assumes the database will be run on
-a single node only. PostgreSQL HA on **secondary** nodes is
+a single node only. Multi-server PostgreSQL on **secondary** nodes is
 [not currently supported](https://gitlab.com/groups/gitlab-org/-/epics/2536).
 
 Configure the [**secondary** database](database.md) as a read-only replica of
@@ -276,7 +275,7 @@ application services. These services are enabled selectively in the
 configuration.
 
 Configure the application servers following
-[Configuring GitLab for HA](../../high_availability/gitlab.md), then make the
+[Configuring GitLab for multiple servers](../../high_availability/gitlab.md), then make the
 following modifications:
 
 1. Edit `/etc/gitlab/gitlab.rb` on each application server in the **secondary**
@@ -364,13 +363,13 @@ application servers.
 In this topology, a load balancer is required at each geographic location to
 route traffic to the application servers.
 
-See [Load Balancer for GitLab HA](../../high_availability/load_balancer.md) for
+See [Load Balancer for GitLab with multiple servers](../../high_availability/load_balancer.md) for
 more information.
 
 ### Step 6: Configure the backend application servers on the **secondary** node
 
 The minimal reference architecture diagram above shows all application services
-running together on the same machines. However, for high availability we
+running together on the same machines. However, for multiple servers we
 [strongly recommend running all services separately](../../reference_architectures/index.md).
 
 For example, a Sidekiq server could be configured similarly to the frontend

doc/administration/geo/replication/index.md

@@ -2,7 +2,7 @@
 
 > - Introduced in GitLab Enterprise Edition 8.9.
 > - Using Geo in combination with
->   [High Availability](../../reference_architectures/index.md)
+>   [multi-server architectures](../../reference_architectures/index.md)
 >   is considered **Generally Available** (GA) in
 >   [GitLab Premium](https://about.gitlab.com/pricing/) 10.4.
 
@@ -206,9 +206,9 @@ For information on configuring Geo, see [Geo configuration](configuration.md).
 
 For information on how to update your Geo nodes to the latest GitLab version, see [Updating the Geo nodes](updating_the_geo_nodes.md).
 
-### Configuring Geo high availability
+### Configuring Geo for multiple servers
 
-For information on configuring Geo for high availability, see [Geo High Availability](high_availability.md).
+For information on configuring Geo for multiple servers, see [Geo for multiple servers](high_availability.md).
 
 ### Configuring Geo with Object Storage
 

doc/install/aws/index.md

@@ -533,7 +533,7 @@ gitlab=# \q
 
 #### Set up Gitaly
 
-CAUTION: **Caution:** In this architecture, having a single Gitaly server creates a single point of failure. This limitation will be removed once [Gitaly HA](https://gitlab.com/groups/gitlab-org/-/epics/1489) is released.
+CAUTION: **Caution:** In this architecture, having a single Gitaly server creates a single point of failure. This limitation will be removed once [Gitaly Cluster](https://gitlab.com/groups/gitlab-org/-/epics/1489) is released.
 
 Gitaly is a service that provides high-level RPC access to Git repositories.
 It should be enabled and configured on a separate EC2 instance in one of the