Commit 647ec9d0 authored by Marcel Amirault's avatar Marcel Amirault

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

Remove HA references from Geo docs

See merge request gitlab-org/gitlab!32269
parents 5cf77d7f 2d05ef24
...@@ -11,37 +11,36 @@ The following are GitLab upgrade validation tests we performed. ...@@ -11,37 +11,36 @@ The following are GitLab upgrade validation tests we performed.
### February 2020 ### 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 - Description: Tested upgrading from GitLab 12.7.5 to the latest GitLab 12.8 package in a multi-server
availability configuration. configuration.
- Outcome: Partial success because we did not run the looping pipeline during the demo to monitor - Outcome: Partial success because we did not run the looping pipeline during the demo to monitor
downtime. downtime.
### January 2020 ### 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 - Description: Tested upgrading from GitLab 12.6.x to the latest GitLab 12.7 package in a multi-server
availability configuration. configuration.
- Outcome: Upgrade test was successful. - Outcome: Upgrade test was successful.
- Follow up issues: - Follow up issues:
- [Investigate Geo end-to-end test failures](https://gitlab.com/gitlab-org/gitlab/issues/201823). - [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). - [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). - [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 - Description: Tested upgrading from GitLab 12.5.7 to GitLab 12.6.6 in a multi-server configuration.
configuration.
- Outcome: Upgrade test was successful. - Outcome: Upgrade test was successful.
- Follow up issue: - 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). [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 - Description: Tested upgrading from GitLab 12.4.x to the latest GitLab 12.5 package in a multi-server
availability configuration. configuration.
- Outcome: Upgrade test was successful. - Outcome: Upgrade test was successful.
- Follow up issues: - Follow up issues:
- [Investigate why HTTP push spec failed on primary node](https://gitlab.com/gitlab-org/gitlab/issues/199825). - [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. ...@@ -49,17 +48,17 @@ The following are GitLab upgrade validation tests we performed.
### October 2019 ### 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. - 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. - Description: Tested upgrading from GitLab 12.2.8 to GitLab 12.3.5.
- Outcome: Upgrade test was successful. - 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. - Description: Tested upgrading from GitLab 12.1.9 to GitLab 12.2.8.
- Outcome: Partial success due to possible misconfiguration issues. - Outcome: Partial success due to possible misconfiguration issues.
...@@ -74,7 +73,7 @@ The following are PostgreSQL upgrade validation tests we performed. ...@@ -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 - 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. 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. tracking database and concerns were raised about allowing automatic upgrades when Geo enabled.
- Follow up issues: - Follow up issues:
- [`replicate-geo-database` incorrectly tries to back up repositories](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5241). - [`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. ...@@ -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. 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. - Outcome: Multiple issues were found when upgrading and addressed in follow-up issues.
- 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). - [`gitlab-ctl` reconfigure fails on Redis node in multi-server 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). - [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 HA setup after upgrade to 12.1.9](https://gitlab.com/gitlab-org/gitlab/-/issues/32119). - [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).
# Geo High Availability **(PREMIUM ONLY)** # Geo for multiple servers **(PREMIUM ONLY)**
This document describes a minimal reference architecture for running Geo 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. described, it is possible to adapt these instructions to your needs.
## Architecture overview ## 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)_ _[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 ...@@ -23,36 +23,36 @@ The only external way to access the two Geo deployments is by HTTPS at
NOTE: **Note:** NOTE: **Note:**
The **primary** and **secondary** Geo deployments must be able to communicate to each other over HTTPS. 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: Geo supports:
- Redis and PostgreSQL on the **primary** node configured for high availability - Redis and PostgreSQL on the **primary** node configured for multiple servers.
- Redis on **secondary** nodes configured for high availability. - Redis on **secondary** nodes configured for multiple servers.
NOTE: **Note:** 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). [is planned](https://gitlab.com/groups/gitlab-org/-/epics/2536).
Because of the additional complexity involved in setting up this configuration 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 [PostgreSQL](../../high_availability/database.md) and
[Redis](../../high_availability/redis.md), respectively. [Redis](../../high_availability/redis.md), respectively.
NOTE: **Note:** NOTE: **Note:**
It is possible to use cloud hosted services for PostgreSQL and Redis, but this is beyond the scope of this document. 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 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 you already have a working GitLab instance that is in-use, it can be used as a
**primary**. **primary**.
The second cluster will serve as the **secondary** node. Again, use the 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 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**. 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 ...@@ -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 NOTE: **Note:** PostgreSQL and Redis should have already been disabled on the
application servers, and connections from the application servers to those application servers, and connections from the application servers to those
services on the backend servers configured, during normal GitLab HA set up. See services on the backend servers configured, during normal GitLab multi-server set up. See
high availability configuration documentation for multi-server configuration documentation for
[PostgreSQL](../../high_availability/database.md#configuring-the-application-nodes) [PostgreSQL](../../high_availability/database.md#configuring-the-application-nodes)
and [Redis](../../high_availability/redis.md#example-configuration-for-the-gitlab-application). 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 ...@@ -103,7 +103,7 @@ and [Redis](../../high_availability/redis.md#example-configuration-for-the-gitla
## Configure a **secondary** node ## 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: major differences:
- The main PostgreSQL database is a read-only replica of the **primary** node's - The main PostgreSQL database is a read-only replica of the **primary** node's
...@@ -112,8 +112,8 @@ major differences: ...@@ -112,8 +112,8 @@ major differences:
called the "tracking database", which tracks the synchronization state of called the "tracking database", which tracks the synchronization state of
various resources. various resources.
Therefore, we will set up the HA components one-by-one, and include deviations Therefore, we will set up the multi-server components one-by-one, and include deviations
from the normal HA setup. However, we highly recommend first configuring a 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 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 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 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. ...@@ -121,11 +121,10 @@ and are not related to Geo setup.
### Step 1: Configure the Redis and Gitaly services on the **secondary** node ### 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: documentation:
- [Configuring Redis for GitLab HA](../../high_availability/redis.md) for high - [Configuring Redis for GitLab](../../high_availability/redis.md) for multiple servers.
availability.
- [Gitaly](../../high_availability/gitaly.md), which will store data that is - [Gitaly](../../high_availability/gitaly.md), which will store data that is
synchronized from the **primary** node. synchronized from the **primary** node.
...@@ -136,7 +135,7 @@ recommended. ...@@ -136,7 +135,7 @@ recommended.
### Step 2: Configure the main read-only replica PostgreSQL database on the **secondary** node ### 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 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). [not currently supported](https://gitlab.com/groups/gitlab-org/-/epics/2536).
Configure the [**secondary** database](database.md) as a read-only replica of 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 ...@@ -276,7 +275,7 @@ application services. These services are enabled selectively in the
configuration. configuration.
Configure the application servers following 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: following modifications:
1. Edit `/etc/gitlab/gitlab.rb` on each application server in the **secondary** 1. Edit `/etc/gitlab/gitlab.rb` on each application server in the **secondary**
...@@ -364,13 +363,13 @@ application servers. ...@@ -364,13 +363,13 @@ application servers.
In this topology, a load balancer is required at each geographic location to In this topology, a load balancer is required at each geographic location to
route traffic to the application servers. 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. more information.
### Step 6: Configure the backend application servers on the **secondary** node ### Step 6: Configure the backend application servers on the **secondary** node
The minimal reference architecture diagram above shows all application services 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). [strongly recommend running all services separately](../../reference_architectures/index.md).
For example, a Sidekiq server could be configured similarly to the frontend For example, a Sidekiq server could be configured similarly to the frontend
......
...@@ -2,7 +2,7 @@ ...@@ -2,7 +2,7 @@
> - Introduced in GitLab Enterprise Edition 8.9. > - Introduced in GitLab Enterprise Edition 8.9.
> - Using Geo in combination with > - Using Geo in combination with
> [High Availability](../../reference_architectures/index.md) > [multi-server architectures](../../reference_architectures/index.md)
> is considered **Generally Available** (GA) in > is considered **Generally Available** (GA) in
> [GitLab Premium](https://about.gitlab.com/pricing/) 10.4. > [GitLab Premium](https://about.gitlab.com/pricing/) 10.4.
...@@ -206,9 +206,9 @@ For information on configuring Geo, see [Geo configuration](configuration.md). ...@@ -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). 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 ### Configuring Geo with Object Storage
......
...@@ -533,7 +533,7 @@ gitlab=# \q ...@@ -533,7 +533,7 @@ gitlab=# \q
#### Set up Gitaly #### 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. 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 It should be enabled and configured on a separate EC2 instance in one of the
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment