Switch to multi-node nomenclature on geo pages

fa04a8aa · Joshua Lambert · Evan Read · 1832db54 · fa04a8aa · fa04a8aa
Commit fa04a8aa authored Jul 02, 2020 by Joshua Lambert Committed by Evan Read Jul 02, 2020
3 changed files
--- a/doc/administration/geo/replication/geo_validation_tests.md
+++ b/doc/administration/geo/replication/geo_validation_tests.md
@@ -18,18 +18,18 @@ The following are GitLab upgrade validation tests we performed.
 ### February 2020
-[Upgrade Geo multi-server installation](https://gitlab.com/gitlab-org/gitlab/-/issues/201837):
+[Upgrade Geo multi-node 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 multi-server
+- Description: Tested upgrading from GitLab 12.7.5 to the latest GitLab 12.8 package in a multi-node
  configuration.
 - Outcome: Partial success because we did not run the looping pipeline during the demo to monitor
  downtime.
 ### January 2020
-[Upgrade Geo multi-server installation](https://gitlab.com/gitlab-org/gitlab/-/issues/200085):
+[Upgrade Geo multi-node 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 multi-server
+- Description: Tested upgrading from GitLab 12.6.x to the latest GitLab 12.7 package in a multi-node
  configuration.
 - Outcome: Upgrade test was successful.
 - Follow up issues:
@@ -37,16 +37,16 @@ The following are GitLab upgrade validation tests we performed.
  - [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 multi-server installation](https://gitlab.com/gitlab-org/gitlab/-/issues/199836):
+[Upgrade Geo multi-node installation](https://gitlab.com/gitlab-org/gitlab/-/issues/199836):
- Description: Tested upgrading from GitLab 12.5.7 to GitLab 12.6.6 in a multi-server configuration.
+- Description: Tested upgrading from GitLab 12.5.7 to GitLab 12.6.6 in a multi-node 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 multi-server installation](https://gitlab.com/gitlab-org/gitlab/-/issues/37044):
+[Upgrade Geo multi-node 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 multi-server
+- Description: Tested upgrading from GitLab 12.4.x to the latest GitLab 12.5 package in a multi-node
  configuration.
 - Outcome: Upgrade test was successful.
 - Follow up issues:
@@ -55,17 +55,17 @@ The following are GitLab upgrade validation tests we performed.
 ### October 2019
-[Upgrade Geo multi-server installation](https://gitlab.com/gitlab-org/gitlab/-/issues/35262):
+[Upgrade Geo multi-node installation](https://gitlab.com/gitlab-org/gitlab/-/issues/35262):
- Description: Tested upgrading from GitLab 12.3.5 to GitLab 12.4.1 in a multi-server configuration.
+- Description: Tested upgrading from GitLab 12.3.5 to GitLab 12.4.1 in a multi-node configuration.
 - Outcome: Upgrade test was successful.
-[Upgrade Geo multi-server installation](https://gitlab.com/gitlab-org/gitlab/-/issues/32437):
+[Upgrade Geo multi-node 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 multi-server installation](https://gitlab.com/gitlab-org/gitlab/-/issues/32435):
+[Upgrade Geo multi-node 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.
@@ -80,7 +80,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 multi-server configurations with a separate
+- Outcome: Partially successful. Issues were discovered in multi-node 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).
@@ -102,6 +102,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 multi-server Geo setup](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/4706).
+  - [`gitlab-ctl` reconfigure fails on Redis node in multi-node 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).
+  - [Geo multi-node 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).
+  - [Refresh foreign tables fails on app server in multi-node setup after upgrade to 12.1.9](https://gitlab.com/gitlab-org/gitlab/-/issues/32119).
--- a/doc/administration/geo/replication/index.md
+++ b/doc/administration/geo/replication/index.md
@@ -9,7 +9,7 @@ type: howto
 > - Introduced in GitLab Enterprise Edition 8.9.
 > - Using Geo in combination with
->   [multi-server architectures](../../reference_architectures/index.md)
+>   [multi-node architectures](../../reference_architectures/index.md)
 >   is considered **Generally Available** (GA) in
 >   [GitLab Premium](https://about.gitlab.com/pricing/) 10.4.
@@ -233,9 +233,9 @@ gitlab-ctl geo-replication-pause
 gitlab-ctl geo-replication-resume
 ```
-### Configuring Geo for multiple servers
+### Configuring Geo for multiple nodes
-For information on configuring Geo for multiple servers, see [Geo for multiple servers](multiple_servers.md).
+For information on configuring Geo for multiple nodes, see [Geo for multiple servers](multiple_servers.md).
 ### Configuring Geo with Object Storage

--- a/doc/administration/geo/replication/multiple_servers.md
+++ b/doc/administration/geo/replication/multiple_servers.md
@@ -5,15 +5,15 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: howto
 ---
-# Geo for multiple servers **(PREMIUM ONLY)**
+# Geo for multiple nodes **(PREMIUM ONLY)**
 This document describes a minimal reference architecture for running Geo
-in a multi-server configuration. If your multi-server setup differs from the one
+in a multi-node configuration. If your multi-node setup differs from the one
 described, it is possible to adapt these instructions to your needs.
 ## Architecture overview
-![Geo multi-server diagram](../../high_availability/img/geo-ha-diagram.png)
+![Geo multi-node diagram](../../high_availability/img/geo-ha-diagram.png)
 _[diagram source - GitLab employees only](https://docs.google.com/drawings/d/1z0VlizKiLNXVVVaERFwgsIOuEgjcUqDTWPdQYsE7Z4c/edit)_
@@ -30,36 +30,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 for multiple servers
+## Redis and PostgreSQL for multiple nodes
 Geo supports:
- Redis and PostgreSQL on the **primary** node configured for multiple servers.
+- Redis and PostgreSQL on the **primary** node configured for multiple nodes.
- Redis on **secondary** nodes configured for multiple servers.
+- Redis on **secondary** nodes configured for multiple nodes.
 NOTE: **Note:**
-Support for PostgreSQL on **secondary** nodes in multi-server configuration
+Support for PostgreSQL on **secondary** nodes in multi-node 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 multi-server documentation.
+for PostgreSQL and Redis, it is not covered by this Geo multi-node documentation.
-For more information about setting up a multi-server PostgreSQL cluster and Redis cluster using the omnibus package see the multi-server documentation for
+For more information about setting up a multi-node PostgreSQL cluster and Redis cluster using the omnibus package see the multi-node documentation for
 [PostgreSQL](../../postgresql/replication_and_failover.md) and
 [Redis](../../redis/replication_and_failover.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 multi-server clusters
+## Prerequisites: Two working GitLab multi-node clusters
 One cluster will serve as the **primary** node. Use the
-[GitLab multi-server documentation](../../reference_architectures/index.md) to set this up. If
+[GitLab multi-node 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 multi-server documentation](../../reference_architectures/index.md) to set this up.
+[GitLab multi-node 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**.
@@ -92,8 +92,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 multi-server set up. See
+services on the backend servers configured, during normal GitLab multi-node set up. See
-multi-server configuration documentation for
+multi-node configuration documentation for
 [PostgreSQL](../../postgresql/replication_and_failover.md#configuring-the-application-nodes)
 and [Redis](../../redis/replication_and_failover.md#example-configuration-for-the-gitlab-application).
@@ -110,7 +110,7 @@ and [Redis](../../redis/replication_and_failover.md#example-configuration-for-th
 ## Configure a **secondary** node
-A **secondary** cluster is similar to any other GitLab multi-server cluster, with two
+A **secondary** cluster is similar to any other GitLab multi-node cluster, with two
 major differences:
 - The main PostgreSQL database is a read-only replica of the **primary** node's
@@ -119,8 +119,8 @@ major differences:
  called the "tracking database", which tracks the synchronization state of
  various resources.
-Therefore, we will set up the multi-server components one-by-one, and include deviations
+Therefore, we will set up the multi-node components one-by-one, and include deviations
-from the normal multi-server setup. However, we highly recommend first configuring a
+from the normal multi-node 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
@@ -128,10 +128,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 multi-server
+Configure the following services, again using the non-Geo multi-node
 documentation:
- [Configuring Redis for GitLab](../../redis/replication_and_failover.md#example-configuration-for-the-gitlab-application) for multiple servers.
+- [Configuring Redis for GitLab](../../redis/replication_and_failover.md#example-configuration-for-the-gitlab-application) for multiple nodes.
 - [Gitaly](../../high_availability/gitaly.md), which will store data that is
  synchronized from the **primary** node.
@@ -142,7 +142,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. Multi-server PostgreSQL on **secondary** nodes is
+a single node only. Multi-node 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
@@ -282,7 +282,7 @@ application services. These services are enabled selectively in the
 configuration.
 Configure the application servers following
-[Configuring GitLab for multiple servers](../../high_availability/gitlab.md), then make the
+[Configuring GitLab for multiple nodes](../../high_availability/gitlab.md), then make the
 following modifications:
 1. Edit `/etc/gitlab/gitlab.rb` on each application server in the **secondary**
@@ -370,13 +370,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 with multiple servers](../../high_availability/load_balancer.md) for
+See [Load Balancer for GitLab with multiple nodes](../../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 multiple servers we
+running together on the same machines. However, for multiple nodes we
 [strongly recommend running all services separately](../../reference_architectures/index.md).
 For example, a Sidekiq server could be configured similarly to the frontend