Remove HA references from Geo docs

2d05ef24 · Evan Read · Marcel Amirault · 5cf77d7f · 2d05ef24 · 2d05ef24
Commit 2d05ef24 authored May 15, 2020 by Evan Read Committed by Marcel Amirault May 15, 2020
4 changed files
--- a/doc/administration/geo/replication/geo_validation_tests.md
+++ b/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).
--- a/doc/administration/geo/replication/high_availability.md
+++ b/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

--- a/doc/administration/geo/replication/index.md
+++ b/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


--- a/doc/install/aws/index.md
+++ b/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