Add configuration steps for the 2,000 reference architecture

The most notable change is the split of the table reference
in regards to the steps needed to configure the reference.

doc/administration/reference_architectures/index.md

@@ -50,7 +50,8 @@ For different cloud vendors, attempt to select options that best match the provi
 
 ## Up to 1,000 users
 
-From 1 to 1,000 users, a [single-node setup with frequent backups](#automated-backups-core-only) is adequate.
+> - **Supported users (approximate):** 1,000
+> - **High Availability:** False
 
 | Users | Configuration([8](#footnotes)) | GCP type      | AWS type([9](#footnotes)) |
 |-------|--------------------------------|---------------|---------------------------|
@@ -58,9 +59,20 @@ From 1 to 1,000 users, a [single-node setup with frequent backups](#automated-ba
 | 500   | 4 vCPU, 15GB Memory            | n1-standard-4 | m5.xlarge                 |
 | 1000  | 8 vCPU, 30GB Memory            | n1-standard-8 | m5.2xlarge                |
 
-This solution is appropriate for many teams that have a single server at their disposal. With automatic backup of the GitLab repositories, configuration, and the database, this can be an optimal solution if you don't have strict availability requirements.
+For situations where you need to serve up to 1,000 users, a single-node
+solution with [frequent backups](#automated-backups-core-only) is appropriate
+for many organizations. With automatic backup of the GitLab repositories,
+configuration, and the database, if you don't have strict availability
+requirements, this is the ideal solution.
+
+For this default reference architecture, use the standard
+[installation instructions](../../install/README.md) to install GitLab.
 
-You can also optionally configure GitLab to use an [external PostgreSQL service](../external_database.md) or an [external object storage service](../high_availability/object_storage.md) for added performance and reliability at a relatively low complexity cost.
+NOTE: **Note:**
+You can also optionally configure GitLab to use an
+[external PostgreSQL service](../external_database.md) or an
+[external object storage service](../high_availability/object_storage.md) for
+added performance and reliability at a reduced complexity cost.
 
 ## Up to 2,000 users
 
@@ -70,12 +82,32 @@ You can also optionally configure GitLab to use an [external PostgreSQL service]
 
 | Service                                                      | Nodes | Configuration ([8](#footnotes)) | GCP type      | AWS type ([9](#footnotes)) |
 |--------------------------------------------------------------|-------|---------------------------------|---------------|----------------------------|
-| GitLab Rails, Sidekiq, Consul ([1](#footnotes))              | 2     | 8 vCPU, 7.2GB Memory            | n1-highcpu-8  | c5.2xlarge                 |
-| PostgreSQL                                                   | 1     | 2 vCPU, 7.5GB Memory            | n1-standard-2 | m5.large                   |
-| Gitaly ([2](#footnotes)) ([5](#footnotes)) ([7](#footnotes)) | X     | 4 vCPU, 15GB Memory             | n1-standard-4 | m5.xlarge                  |
-| Cloud Object Storage ([4](#footnotes))                       | -     | -                               | -             | -                          |
-| NFS Server ([5](#footnotes)) ([7](#footnotes))               | 1     | 4 vCPU, 3.6GB Memory            | n1-highcpu-4  | c5.xlarge                  |
 | External load balancing node ([6](#footnotes))               | 1     | 2 vCPU, 1.8GB Memory            | n1-highcpu-2  | c5.large                   |
+| Object Storage ([4](#footnotes))                             | -     | -                               | -             | -                          |
+| NFS Server ([5](#footnotes)) ([7](#footnotes))               | 1     | 4 vCPU, 3.6GB Memory            | n1-highcpu-4  | c5.xlarge                  |
+| PostgreSQL                                                   | 1     | 2 vCPU, 7.5GB Memory            | n1-standard-2 | m5.large                   |
+| Redis ([3](#footnotes))                                      | 1     | 1 vCPU, 3.75GB Memory           | n1-standard-1 | m5.large                   |
+| Gitaly ([5](#footnotes)) ([7](#footnotes))                   | X ([2](#footnotes))  | 4 vCPU, 15GB Memory             | n1-standard-4 | m5.xlarge   |
+| GitLab Rails ([1](#footnotes))                               | 2     | 8 vCPU, 7.2GB Memory            | n1-highcpu-8  | c5.2xlarge                 |
+| Monitoring node                                              | 1     | 2 vCPU, 1.8GB Memory            | n1-highcpu-2  | c5.large                   |
+
+To set up GitLab for up to 2000 users:
+
+1. [Configure the external load balancing node](../high_availability/load_balancer.md)
+   that will handle the load balancing of the two GitLab application services nodes.
+1. [Configure the Object Storage](../object_storage.md) ([4](#footnotes)) used for shared data objects.
+1. (Optional) [Configure NFS](../high_availability/nfs.md) to have
+   shared disk storage service as an alternative to Gitaly and/or
+   [Object Storage](../object_storage.md) (although not recommended).
+   NFS is required for GitLab Pages, you can skip this step if you're not using that feature.
+1. [Configure PostgreSQL](../high_availability/load_balancer.md), the database for GitLab.
+1. [Configure Redis](../high_availability/redis.md).
+1. [Configure Gitaly](../gitaly/index.md#running-gitaly-on-its-own-server),
+   which is used to provide access to the Git repositories.
+1. [Configure the main GitLab Rails application](../high_availability/gitlab.md)
+   to run Puma/Unicorn, Workhorse, GitLab Shell, and to serve all
+   frontend requests (UI, API, Git over HTTP/SSH).
+1. [Configure Prometheus](../high_availability/monitoring_node.md) to monitor your GitLab environment.
 
 ## Up to 3,000 users
 
@@ -83,9 +115,7 @@ NOTE: **Note:** The 3,000-user reference architecture documented below is
 designed to help your organization achieve a highly-available GitLab deployment.
 If you do not have the expertise or need to maintain a highly-available
 environment, you can have a simpler and less costly-to-operate environment by
-deploying two or more GitLab Rails servers, external load balancing, an NFS
-server, a PostgreSQL server and a Redis server. A reference architecture with
-this alternative in mind is [being worked on](https://gitlab.com/gitlab-org/quality/performance/-/issues/223).
+following the [2,000-user reference architecture](#up-to-2000-users).
 
 > - **Supported users (approximate):** 3,000
 > - **High Availability:** True
@@ -100,7 +130,7 @@ this alternative in mind is [being worked on](https://gitlab.com/gitlab-org/qual
 | Redis ([3](#footnotes))                                      | 3     | 2 vCPU, 7.5GB Memory            | n1-standard-2 | m5.large                   |
 | Consul + Sentinel ([3](#footnotes))                          | 3     | 2 vCPU, 1.8GB Memory            | n1-highcpu-2  | c5.large                   |
 | Sidekiq                                                      | 4     | 2 vCPU, 7.5GB Memory            | n1-standard-2 | m5.large                   |
-| Cloud Object Storage ([4](#footnotes))                       | -     | -                               | -             | -                          |
+| Object Storage ([4](#footnotes))                       | -     | -                               | -             | -                          |
 | NFS Server ([5](#footnotes)) ([7](#footnotes))               | 1     | 4 vCPU, 3.6GB Memory            | n1-highcpu-4  | c5.xlarge                  |
 | Monitoring node                                              | 1     | 2 vCPU, 1.8GB Memory            | n1-highcpu-2  | c5.large                   |
 | External load balancing node ([6](#footnotes))               | 1     | 2 vCPU, 1.8GB Memory            | n1-highcpu-2  | c5.large                   |
@@ -121,7 +151,7 @@ this alternative in mind is [being worked on](https://gitlab.com/gitlab-org/qual
 | Redis ([3](#footnotes))                                      | 3     | 2 vCPU, 7.5GB Memory            | n1-standard-2 | m5.large                   |
 | Consul + Sentinel ([3](#footnotes))                          | 3     | 2 vCPU, 1.8GB Memory            | n1-highcpu-2  | c5.large                   |
 | Sidekiq                                                      | 4     | 2 vCPU, 7.5GB Memory            | n1-standard-2 | m5.large                   |
-| Cloud Object Storage ([4](#footnotes))                       | -     | -                               | -             | -                          |
+| Object Storage ([4](#footnotes))                       | -     | -                               | -             | -                          |
 | NFS Server ([5](#footnotes)) ([7](#footnotes))               | 1     | 4 vCPU, 3.6GB Memory            | n1-highcpu-4  | c5.xlarge                  |
 | Monitoring node                                              | 1     | 2 vCPU, 1.8GB Memory            | n1-highcpu-2  | c5.large                   |
 | External load balancing node ([6](#footnotes))               | 1     | 2 vCPU, 1.8GB Memory            | n1-highcpu-2  | c5.large                   |
@@ -145,7 +175,7 @@ this alternative in mind is [being worked on](https://gitlab.com/gitlab-org/qual
 | Redis Sentinel ([3](#footnotes)) - Queues / Shared State     | 3     | 1 vCPU, 1.7GB Memory                | g1-small       | t2.small                   |
 | Consul                                                       | 3     | 2 vCPU, 1.8GB Memory                | n1-highcpu-2   | c5.large                   |
 | Sidekiq                                                      | 4     | 4 vCPU, 15GB Memory                 | n1-standard-4  | m5.xlarge                  |
-| Cloud Object Storage ([4](#footnotes))                       | -     | -                                   | -              | -                          |
+| Object Storage ([4](#footnotes))                       | -     | -                                   | -              | -                          |
 | NFS Server ([5](#footnotes)) ([7](#footnotes))               | 1     | 4 vCPU, 3.6GB Memory                | n1-highcpu-4   | c5.xlarge                  |
 | Monitoring node                                              | 1     | 4 vCPU, 3.6GB Memory                | n1-highcpu-4   | c5.xlarge                  |
 | External load balancing node ([6](#footnotes))               | 1     | 2 vCPU, 1.8GB Memory                | n1-highcpu-2   | c5.large                   |
@@ -169,7 +199,7 @@ this alternative in mind is [being worked on](https://gitlab.com/gitlab-org/qual
 | Redis Sentinel ([3](#footnotes)) - Queues / Shared State     | 3     | 1 vCPU, 1.7GB Memory            | g1-small       | t2.small                   |
 | Consul                                                       | 3     | 2 vCPU, 1.8GB Memory            | n1-highcpu-2   | c5.large                   |
 | Sidekiq                                                      | 4     | 4 vCPU, 15GB Memory             | n1-standard-4  | m5.xlarge                  |
-| Cloud Object Storage ([4](#footnotes))                       | -     | -                               | -              | -                          |
+| Object Storage ([4](#footnotes))                       | -     | -                               | -              | -                          |
 | NFS Server ([5](#footnotes)) ([7](#footnotes))               | 1     | 4 vCPU, 3.6GB Memory            | n1-highcpu-4   | c5.xlarge                  |
 | Monitoring node                                              | 1     | 4 vCPU, 3.6GB Memory            | n1-highcpu-4   | c5.xlarge                  |
 | External load balancing node ([6](#footnotes))               | 1     | 2 vCPU, 1.8GB Memory            | n1-highcpu-2   | c5.large                   |
@@ -194,7 +224,7 @@ this alternative in mind is [being worked on](https://gitlab.com/gitlab-org/qual
 | Consul                                                       | 3     | 2 vCPU, 1.8GB Memory            | n1-highcpu-2   | c5.large                   |
 | Sidekiq                                                      | 4     | 4 vCPU, 15GB Memory             | n1-standard-4  | m5.xlarge                  |
 | NFS Server ([5](#footnotes)) ([7](#footnotes))               | 1     | 4 vCPU, 3.6GB Memory            | n1-highcpu-4   | c5.xlarge                  |
-| Cloud Object Storage ([4](#footnotes))                       | -     | -                               | -              | -                          |
+| Object Storage ([4](#footnotes))                       | -     | -                               | -              | -                          |
 | Monitoring node                                              | 1     | 4 vCPU, 3.6GB Memory            | n1-highcpu-4   | c5.xlarge                  |
 | External load balancing node ([6](#footnotes))               | 1     | 2 vCPU, 1.8GB Memory            | n1-highcpu-2   | c5.large                   |
 | Internal load balancing node ([6](#footnotes))               | 1     | 8 vCPU, 7.2GB Memory            | n1-highcpu-8   | c5.2xlarge                 |
@@ -286,7 +316,7 @@ column.
 | Component | Description | Configuration instructions | Bundled with Omnibus GitLab |
 |-----------|-------------|----------------------------|
 | Load balancer(s) ([6](#footnotes)) | Handles load balancing, typically when you have multiple GitLab application services nodes | [Load balancer configuration](../high_availability/load_balancer.md) ([6](#footnotes))      | No |
-| Object storage service ([4](#footnotes)) | Recommended store for shared data objects | [Cloud Object Storage configuration](../object_storage.md) | No |
+| Object storage service ([4](#footnotes)) | Recommended store for shared data objects | [Object Storage configuration](../object_storage.md) | No |
 | NFS ([5](#footnotes)) ([7](#footnotes)) | Shared disk storage service. Can be used as an alternative for Gitaly or Object Storage. Required for GitLab Pages | [NFS configuration](../high_availability/nfs.md) | No |
 | [Consul](../../development/architecture.md#consul) ([3](#footnotes)) | Service discovery and health checks/failover | [Consul HA configuration](../high_availability/consul.md) **(PREMIUM ONLY)** | Yes |
 | [PostgreSQL](../../development/architecture.md#postgresql) | Database | [PostgreSQL configuration](https://docs.gitlab.com/omnibus/settings/database.html) | Yes |
@@ -316,14 +346,15 @@ column.
    with a review of expected data size and spread based on the recommendations above.
 
 1. Recommended Redis setup differs depending on the size of the architecture.
-   For smaller architectures (less than 5,000 users), we suggest one Redis cluster for all
+   For smaller architectures (less than 3,000 users) a single instance should suffice.
+   For medium sized installs (3,000 - 5,000) we suggest one Redis cluster for all
    classes and that Redis Sentinel is hosted alongside Consul.
    For larger architectures (10,000 users or more) we suggest running a separate
    [Redis Cluster](../high_availability/redis.md#running-multiple-redis-clusters) for the Cache class
    and another for the Queues and Shared State classes respectively. We also recommend
    that you run the Redis Sentinel clusters separately for each Redis Cluster.
 
-1. For data objects such as LFS, Uploads, Artifacts, etc. We recommend a [Cloud Object Storage service](../object_storage.md)
+1. For data objects such as LFS, Uploads, Artifacts, etc. We recommend an [Object Storage service](../object_storage.md)
    over NFS where possible, due to better performance and availability.
 
 1. NFS can be used as an alternative for both repository data (replacing Gitaly) and