diff --git a/doc/administration/backup_restore/backup_large_reference_architectures.md b/doc/administration/backup_restore/backup_large_reference_architectures.md index 03998acae4d598e94dad9ee7ac6e447be7a3c43e..fa2d1b0d8df8a8adc0c6d7b603c5ab6cfb7e68f5 100644 --- a/doc/administration/backup_restore/backup_large_reference_architectures.md +++ b/doc/administration/backup_restore/backup_large_reference_architectures.md @@ -18,7 +18,7 @@ This document describes how to: This document is intended for environments using: -- [Linux package (Omnibus) and cloud-native hybrid reference architectures 3,000 users and up](../reference_architectures/index.md) +- [Linux package (Omnibus) and cloud-native hybrid reference architectures 60 RPS / 3,000 users and up](../reference_architectures/index.md) - [Amazon RDS](https://aws.amazon.com/rds/) for PostgreSQL data - [Amazon S3](https://aws.amazon.com/s3/) for object storage - [Object storage](../object_storage.md) to store everything possible, including [blobs](backup_gitlab.md#blobs) and [container registry](backup_gitlab.md#container-registry) diff --git a/doc/administration/geo/disaster_recovery/runbooks/planned_failover_multi_node.md b/doc/administration/geo/disaster_recovery/runbooks/planned_failover_multi_node.md index 0b6f486f3c3c11d6da5d3e9709b5026f3c57b5ee..66351b16479e2e1936b61aec4a79d860b4c5fdc5 100644 --- a/doc/administration/geo/disaster_recovery/runbooks/planned_failover_multi_node.md +++ b/doc/administration/geo/disaster_recovery/runbooks/planned_failover_multi_node.md @@ -23,7 +23,7 @@ DETAILS: | Secondaries | One | This runbook guides you through a planned failover of a multi-node Geo site -with one secondary. The following [2000 user reference architecture](../../../../administration/reference_architectures/2k_users.md) is assumed: +with one secondary. The following [40 RPS / 2,000 user reference architecture](../../../../administration/reference_architectures/2k_users.md) is assumed: ```mermaid graph TD diff --git a/doc/administration/geo/glossary.md b/doc/administration/geo/glossary.md index acaffbbaeb86d1e17fac085f26f463777ff2c203..d289279b375843c2029ad6a6aafb1ffcbd4ffc94 100644 --- a/doc/administration/geo/glossary.md +++ b/doc/administration/geo/glossary.md @@ -31,7 +31,7 @@ these definitions yet. | Primary site | A GitLab site whose data is being replicated by at least one secondary site. There can only be a single primary site. | Geo-specific | Geo deployment, Primary node | | Secondary site | A GitLab site that is configured to replicate the data of a primary site. There can be one or more secondary sites. | Geo-specific | Geo deployment, Secondary node | | Geo deployment | A collection of two or more GitLab sites with exactly one primary site being replicated by one or more secondary sites. | Geo-specific | | -| Reference architecture | A [specified configuration of GitLab for a number of users](../reference_architectures/index.md), possibly including multiple nodes and multiple sites. | GitLab | | +| Reference architecture | A [specified configuration of GitLab based on Requests per Second or user count](../reference_architectures/index.md), possibly including multiple nodes and multiple sites. | GitLab | | | Promoting | Changing the role of a site from secondary to primary. | Geo-specific | | | Demoting | Changing the role of a site from primary to secondary. | Geo-specific | | | Failover | The entire process that shifts users from a primary Site to a secondary site. This includes promoting a secondary, but contains other parts as well. For example, scheduling maintenance. | Geo-specific | | diff --git a/doc/administration/geo/setup/index.md b/doc/administration/geo/setup/index.md index 4b69ac4df93841fedf87ed0a43e7e9f813b0b1bb..1f89918c76ac7752777d3f72408cc0124b58ee3b 100644 --- a/doc/administration/geo/setup/index.md +++ b/doc/administration/geo/setup/index.md @@ -40,7 +40,7 @@ Depending on your GitLab deployment, [additional configuration](#additional-conf ### Multi-node Geo sites -If one or more of your sites is using the [2K reference architecture](../../reference_architectures/2k_users.md) or larger, see +If one or more of your sites is using the [40 RPS / 2,000 user reference architecture](../../reference_architectures/2k_users.md) or larger, see [Configure Geo for multiple nodes](../replication/multiple_servers.md). Depending on your GitLab deployment, [additional configuration](#additional-configuration) for LDAP, object storage, and the container registry might be required. diff --git a/doc/administration/gitaly/index.md b/doc/administration/gitaly/index.md index 84030675f65b40487a461f03199e21136aebf2f5..0fd0d6523b98064d9a86647cc48a99a1d3429ddf 100644 --- a/doc/administration/gitaly/index.md +++ b/doc/administration/gitaly/index.md @@ -167,9 +167,9 @@ E --> F ### Configure Gitaly Gitaly comes pre-configured with a Linux package installation, which is a configuration -[suitable for up to 1000 users](../reference_architectures/1k_users.md). For: +[suitable for up to 20 RPS / 1,000 users](../reference_architectures/1k_users.md). For: -- Linux package installations for up to 2000 users, see [specific Gitaly configuration instructions](../reference_architectures/2k_users.md#configure-gitaly). +- Linux package installations for up to 40 RPS / 2,000 users, see [specific Gitaly configuration instructions](../reference_architectures/2k_users.md#configure-gitaly). - Self-compiled installations or custom Gitaly installations, see [Configure Gitaly](configure_gitaly.md). GitLab installations for more than 2000 active users performing daily Git write operation may be diff --git a/doc/administration/gitaly/praefect.md b/doc/administration/gitaly/praefect.md index 25bd449808a7595e9ee4372a33fd9a2323f36695..a5d045886204fd9fa232ffc5bfcc94cf6023bd9c 100644 --- a/doc/administration/gitaly/praefect.md +++ b/doc/administration/gitaly/praefect.md @@ -14,11 +14,11 @@ Configure Gitaly Cluster using either: - Gitaly Cluster configuration instructions available as part of [reference architectures](../reference_architectures/index.md) for installations of up to: - - [3000 users](../reference_architectures/3k_users.md#configure-gitaly-cluster). - - [5000 users](../reference_architectures/5k_users.md#configure-gitaly-cluster). - - [10,000 users](../reference_architectures/10k_users.md#configure-gitaly-cluster). - - [25,000 users](../reference_architectures/25k_users.md#configure-gitaly-cluster). - - [50,000 users](../reference_architectures/50k_users.md#configure-gitaly-cluster). + - [60 RPS or 3,000 users](../reference_architectures/3k_users.md#configure-gitaly-cluster). + - [100 RPS or 5,000 users](../reference_architectures/5k_users.md#configure-gitaly-cluster). + - [200 RPS or 10,000 users](../reference_architectures/10k_users.md#configure-gitaly-cluster). + - [500 RPS or 25,000 users](../reference_architectures/25k_users.md#configure-gitaly-cluster). + - [1000 RPS or 50,000 users](../reference_architectures/50k_users.md#configure-gitaly-cluster). - The custom configuration instructions that follow on this page. Smaller GitLab installations may need only [Gitaly itself](index.md). diff --git a/doc/administration/postgresql/standalone.md b/doc/administration/postgresql/standalone.md index b1404a919285af601d945d3a3bd34f691f6110c6..9789fa852dc9e1d664c11085d115474352fe0055 100644 --- a/doc/administration/postgresql/standalone.md +++ b/doc/administration/postgresql/standalone.md @@ -13,7 +13,7 @@ DETAILS: If you wish to have your database service hosted separately from your GitLab application servers, you can do this using the PostgreSQL binaries packaged together with the Linux package. This is recommended as part of our -[reference architecture for up to 2,000 users](../reference_architectures/2k_users.md). +[reference architecture for up to 40 RPS or 2,000 users](../reference_architectures/2k_users.md). ## Setting it up diff --git a/doc/administration/reference_architectures/10k_users.md b/doc/administration/reference_architectures/10k_users.md index e6a8cba03508428adcc265172223fc45583e425a..28e95826cf673bc0ea2f615842a9ac654ae3258f 100644 --- a/doc/administration/reference_architectures/10k_users.md +++ b/doc/administration/reference_architectures/10k_users.md @@ -4,14 +4,13 @@ group: Distribution info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments --- -# Reference architecture: up to 10,000 users +# Reference architecture: 200 RPS or up to 10,000 users DETAILS: **Tier:** Premium, Ultimate **Offering:** Self-managed -This page describes the GitLab reference architecture designed for the load of up to 10,000 users -with notable headroom. +This page describes the GitLab reference architecture designed to target a peak load of 200 requests per second (RPS), the typical peak load of up to 10,000 users, both manual and automated, based on real data with headroom added. For a full list of reference architectures, see [Available reference architectures](index.md#available-reference-architectures). @@ -157,7 +156,7 @@ Before starting, see the [requirements](index.md#requirements) for reference arc ## Testing methodology The 10k architecture is designed to cover a large majority of workflows and is regularly -[smoke and performance tested](index.md#validation-and-test-results) by the Quality Engineering team +[smoke and performance tested](index.md#validation-and-test-results) by the Test Platform team against the following endpoint throughput targets: - API: 200 RPS @@ -179,7 +178,7 @@ The load balancers used for testing were HAProxy for Linux package environments ## Setup components -To set up GitLab and its components to accommodate up to 10,000 users: +To set up GitLab and its components to accommodate up to 200 RPS or 10,000 users: 1. [Configure the external load balancer](#configure-the-external-load-balancer) to handle the load balancing of the GitLab application services nodes. @@ -2398,7 +2397,7 @@ Each Webservice pod consumes roughly 4 CPUs and 5 GB of memory using the [recommended topology](#cluster-topology) because four worker processes are created by default and each pod has other small processes running. -For 10,000 users we recommend a total Puma worker count of around 80. +For 200 RPS or 10,000 users we recommend a total Puma worker count of around 80. With the [provided recommendations](#cluster-topology) this allows the deployment of up to 20 Webservice pods with 4 workers per pod and 5 pods per node. Expand available resources using the ratio of 1 CPU to 1.25 GB of memory _per each worker process_ for each additional diff --git a/doc/administration/reference_architectures/1k_users.md b/doc/administration/reference_architectures/1k_users.md index 5499166ded768034a2f278fece44278f3c79a67c..af324966583649366d1eee08ee551d189dec469b 100644 --- a/doc/administration/reference_architectures/1k_users.md +++ b/doc/administration/reference_architectures/1k_users.md @@ -4,14 +4,13 @@ group: Distribution info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments --- -# Reference architecture: up to 1,000 users +# Reference architecture: 20 RPS or up to 1,000 users DETAILS: **Tier:** Free, Premium, Ultimate **Offering:** Self-managed -This page describes the GitLab reference architecture designed for the load of up to 1,000 users -with notable headroom (non-HA standalone). +This page describes the GitLab reference architecture designed to target a peak load of 20 requests per second (RPS), the typical peak load of up to 1,000 users, both manual and automated, based on real data with headroom added. For a full list of reference architectures, see [Available reference architectures](index.md#available-reference-architectures). @@ -26,7 +25,7 @@ For a full list of reference architectures, see | Users | Configuration | GCP | AWS | Azure | |--------------|-------------------------|----------------|--------------|----------| -| Up to 1,000 | 8 vCPU, 7.2 GB memory | `n1-highcpu-8` | `c5.2xlarge` | `F8s v2` | +| Up to 1,000 or 20 RPS | 8 vCPU, 7.2 GB memory | `n1-highcpu-8` | `c5.2xlarge` | `F8s v2` | ```plantuml @startuml 1k @@ -74,7 +73,7 @@ If this applies to you, we strongly recommended referring to the linked document ## Testing methodology The 1k architecture is designed to cover a large majority of workflows and is regularly -[smoke and performance tested](index.md#validation-and-test-results) by the Quality Engineering team +[smoke and performance tested](index.md#validation-and-test-results) by the Test Platform team against the following endpoint throughput targets: - API: 20 RPS @@ -121,5 +120,5 @@ Cloud Native Hybrid Reference Architecture is an alternative approach where sele components are deployed in Kubernetes via our official [Helm Charts](https://docs.gitlab.com/charts/), and _stateful_ components are deployed in compute VMs with the Linux package. -The [2k GitLab Cloud Native Hybrid](2k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) (non HA) and [3k GitLab Cloud Native Hybrid](3k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) (HA) reference architectures are the smallest we recommend in Kubernetes. -For environments that serve fewer users, you can lower the node specs. Depending on your user count, you can lower all suggested node specs as desired. However, it's recommended that you don't go lower than the [general requirements](../../install/requirements.md). +The [2k or 40 RPS GitLab Cloud Native Hybrid](2k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) (non HA) and [3k or 60 RPS GitLab Cloud Native Hybrid](3k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) (HA) reference architectures are the smallest we recommend in Kubernetes. +For environments that serve fewer users or a lower RPS, you can lower the node specs. Depending on your user count, you can lower all suggested node specs as desired. However, it's recommended that you don't go lower than the [general requirements](../../install/requirements.md). diff --git a/doc/administration/reference_architectures/25k_users.md b/doc/administration/reference_architectures/25k_users.md index e2b0b35e03ff9115a4d2e58a073fb23a7007f1da..d8bee9048b9648762ebc0a668eefcb14a158253c 100644 --- a/doc/administration/reference_architectures/25k_users.md +++ b/doc/administration/reference_architectures/25k_users.md @@ -4,14 +4,13 @@ group: Distribution info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments --- -# Reference architecture: up to 25,000 users +# Reference architecture: 500 RPS or up to 25,000 users DETAILS: **Tier:** Premium, Ultimate **Offering:** Self-managed -This page describes the GitLab reference architecture designed for the load of up to 25,000 users -with notable headroom. +This page describes the GitLab reference architecture designed to target a peak load of 500 requests per second (RPS) - The typical peak load of up to 25,000 users, both manual and automated, based on real data with headroom added. For a full list of reference architectures, see [Available reference architectures](index.md#available-reference-architectures). @@ -157,7 +156,7 @@ Before starting, see the [requirements](index.md#requirements) for reference arc ## Testing methodology The 25k architecture is designed to cover a large majority of workflows and is regularly -[smoke and performance tested](index.md#validation-and-test-results) by the Quality Engineering team +[smoke and performance tested](index.md#validation-and-test-results) by the Test Platform team against the following endpoint throughput targets: - API: 500 RPS @@ -179,7 +178,7 @@ The load balancers used for testing were HAProxy for Linux package environments ## Setup components -To set up GitLab and its components to accommodate up to 25,000 users: +To set up GitLab and its components to accommodate up to 500 RPS or 25,000 users: 1. [Configure the external load balancer](#configure-the-external-load-balancer) to handle the load balancing of the GitLab application services nodes. @@ -2403,7 +2402,7 @@ Each Webservice pod consumes roughly 4 CPUs and 5 GB of memory using the [recommended topology](#cluster-topology) because four worker processes are created by default and each pod has other small processes running. -For 25,000 users we recommend a total Puma worker count of around 140. +For 500 RPS or 25,000 users we recommend a total Puma worker count of around 140. With the [provided recommendations](#cluster-topology) this allows the deployment of up to 35 Webservice pods with 4 workers per pod and 5 pods per node. Expand available resources using the ratio of 1 CPU to 1.25 GB of memory _per each worker process_ for each additional diff --git a/doc/administration/reference_architectures/2k_users.md b/doc/administration/reference_architectures/2k_users.md index bdaf4bb7a7ee55e86d7f52ed57db5584e1df6cc0..beb17c13eb894ae730cb35be27ac675cbe655071 100644 --- a/doc/administration/reference_architectures/2k_users.md +++ b/doc/administration/reference_architectures/2k_users.md @@ -4,21 +4,20 @@ group: Distribution info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments --- -# Reference architecture: up to 2,000 users +# Reference architecture: 40 RPS or up to 2,000 users DETAILS: **Tier:** Free, Premium, Ultimate **Offering:** Self-managed -This page describes the GitLab reference architecture designed for the load of up to 2,000 users -with notable headroom (non-HA). +This page describes the GitLab reference architecture designed to target a peak load of 40 requests per second (RPS), the typical peak load of up to 2,000 users, both manual and automated, based on real data with headroom added. For a full list of reference architectures, see [Available reference architectures](index.md#available-reference-architectures). > - **Target Load:** API: 40 RPS, Web: 4 RPS, Git (Pull): 4 RPS, Git (Push): 1 RPS > - **High Availability:** No. For a highly-available environment, you can -> follow a modified [3K reference architecture](3k_users.md#supported-modifications-for-lower-user-counts-ha). +> follow a modified [3K or 60 RPS reference architecture](3k_users.md#supported-modifications-for-lower-user-counts-ha). > - **Estimated Costs:** [See cost table](index.md#cost-to-run) > - **Cloud Native Hybrid:** [Yes](#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) > - **Unsure which Reference Architecture to use?** [Go to this guide for more info](index.md#deciding-which-architecture-to-use). @@ -100,7 +99,7 @@ Before starting, see the [requirements](index.md#requirements) for reference arc ## Testing methodology The 2k architecture is designed to cover a large majority of workflows and is regularly -[smoke and performance tested](index.md#validation-and-test-results) by the Quality Engineering team +[smoke and performance tested](index.md#validation-and-test-results) by the Test Platform team against the following endpoint throughput targets: - API: 40 RPS @@ -122,7 +121,7 @@ The load balancers used for testing were HAProxy for Linux package environments ## Setup components -To set up GitLab and its components to accommodate up to 2,000 users: +To set up GitLab and its components to accommodate up to 40 RPS or 2,000 users: 1. [Configure the external load balancing node](#configure-the-external-load-balancer) to handle the load balancing of the GitLab application services nodes. @@ -1105,7 +1104,7 @@ section assumes this. NOTE: The 2,000 reference architecture is not a highly-available setup. To achieve HA, -you can follow a modified [3K reference architecture](3k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative). +you can follow a modified [3K or 60 RPS reference architecture](3k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative). WARNING: **Gitaly Cluster is not supported to be run in Kubernetes**. @@ -1200,7 +1199,7 @@ Each Webservice pod consumes roughly 4 CPUs and 5 GB of memory using the [recommended topology](#cluster-topology) because two worker processes are created by default and each pod has other small processes running. -For 2,000 users we recommend a total Puma worker count of around 12. +For 40 RPS or 2,000 users we recommend a total Puma worker count of around 12. With the [provided recommendations](#cluster-topology) this allows the deployment of up to 3 Webservice pods with 4 workers per pod and 1 pod per node. Expand available resources using the ratio of 1 CPU to 1.25 GB of memory _per each worker process_ for each additional diff --git a/doc/administration/reference_architectures/3k_users.md b/doc/administration/reference_architectures/3k_users.md index eff1462710b1ff88bdfbfce63e297db2746098c5..dbfe86461b6deb5375d3f9d8c4cccbb2309daacd 100644 --- a/doc/administration/reference_architectures/3k_users.md +++ b/doc/administration/reference_architectures/3k_users.md @@ -4,14 +4,13 @@ group: Distribution info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments --- -# Reference architecture: up to 3,000 users +# Reference architecture: 60 RPS or up to 3,000 users DETAILS: **Tier:** Premium, Ultimate **Offering:** Self-managed -This page describes the GitLab reference architecture designed for the load of up to 3,000 users -with notable headroom. +This page describes the GitLab reference architecture designed to target a peak load of 60 requests per second (RPS), the typical peak load of up to 3,000 users, both manual and automated, based on real data with headroom added. This architecture is the smallest one available with HA built in. If you require HA but have a lower user count or total load the [Supported Modifications for lower user counts](#supported-modifications-for-lower-user-counts-ha) @@ -152,7 +151,7 @@ Before starting, see the [requirements](index.md#requirements) for reference arc ## Testing methodology The 3k architecture is designed to cover a large majority of workflows and is regularly -[smoke and performance tested](index.md#validation-and-test-results) by the Quality Engineering team +[smoke and performance tested](index.md#validation-and-test-results) by the Test Platform team against the following endpoint throughput targets: - API: 60 RPS @@ -174,7 +173,7 @@ The load balancers used for testing were HAProxy for Linux package environments ## Setup components -To set up GitLab and its components to accommodate up to 3,000 users: +To set up GitLab and its components to accommodate up to 60 RPS or 3,000 users: 1. [Configure the external load balancer](#configure-the-external-load-balancer) to handle the load balancing of the GitLab application services nodes. @@ -2202,18 +2201,18 @@ cluster alongside your instance, read how to ## Supported modifications for lower user counts (HA) -The 3,000 user GitLab reference architecture is the smallest we recommend that achieves High Availability (HA). -However, for environments that need to serve fewer users but maintain HA, there are several +The 60 RPS or 3,000 users GitLab reference architecture is the smallest we recommend that achieves High Availability (HA). +However, for environments that need to serve fewer users or a lower RPS but maintain HA, there are several supported modifications you can make to this architecture to reduce complexity and cost. -It should be noted that to achieve HA with GitLab, the 3,000 user architecture's makeup is ultimately what is -required. Each component has various considerations and rules to follow, and the 3,000 user architecture +It should be noted that to achieve HA with GitLab, the 60 RPS or 3,000 users architecture's makeup is ultimately what is +required. Each component has various considerations and rules to follow, and the architecture meets all of these. Smaller versions of this architecture will be fundamentally the same, but with smaller performance requirements, several modifications can be considered as follows: - Lowering node specs: Depending on your user count, you can lower all suggested node specs as desired. However, it's recommended that you don't go lower than the [general requirements](../../install/requirements.md). - Combining select nodes: Some nodes can be combined to reduce complexity at the cost of some performance: - - GitLab Rails and Sidekiq: Sidekiq nodes can be removed and the component instead enabled on the GitLab Rails nodes. + - GitLab Rails and Sidekiq: Sidekiq nodes can be removed, and the component instead enabled on the GitLab Rails nodes. - PostgreSQL and PgBouncer: PgBouncer nodes could be removed and instead be enabled on PostgreSQL nodes with the Internal Load Balancer pointing to them. However, to enable [Database Load Balancing](../postgresql/database_load_balancing.md), a separate PgBouncer array is still required. - Reducing the node counts: Some node types do not need consensus and can run with fewer nodes (but more than one for redundancy). This will also lead to reduced performance. - GitLab Rails and Sidekiq: Stateless services don't have a minimum node count. Two are enough for redundancy. @@ -2381,7 +2380,7 @@ Each Webservice pod consumes roughly 4 CPUs and 5 GB of memory using the [recommended topology](#cluster-topology) because four worker processes are created by default and each pod has other small processes running. -For 3,000 users we recommend a total Puma worker count of around 16. +For 60 RPS or 3,000 users we recommend a total Puma worker count of around 16. With the [provided recommendations](#cluster-topology) this allows the deployment of up to 4 Webservice pods with 4 workers per pod and 2 pods per node. Expand available resources using the ratio of 1 CPU to 1.25 GB of memory _per each worker process_ for each additional diff --git a/doc/administration/reference_architectures/50k_users.md b/doc/administration/reference_architectures/50k_users.md index d80bf01e3a74528b0f38281cc2bd4aca2088c1ff..dfd63ae3688059cc7f2ae7178dbe581875da1a7f 100644 --- a/doc/administration/reference_architectures/50k_users.md +++ b/doc/administration/reference_architectures/50k_users.md @@ -4,14 +4,13 @@ group: Distribution info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments --- -# Reference architecture: up to 50,000 users +# Reference architecture: 1000 RPS or up to 50,000 users DETAILS: **Tier:** Premium, Ultimate **Offering:** Self-managed -This page describes the GitLab reference architecture designed for the load of up to 50,000 users -with notable headroom. +This page describes the GitLab reference architecture designed to target a peak load of 1000 requests per second (RPS), the typical peak load of up to 50,000 users, both manual and automated, based on real data with headroom added. For a full list of reference architectures, see [Available reference architectures](index.md#available-reference-architectures). @@ -156,7 +155,7 @@ Before starting, see the [requirements](index.md#requirements) for reference arc ## Testing methodology The 50k architecture is designed to cover a large majority of workflows and is regularly -[smoke and performance tested](index.md#validation-and-test-results) by the Quality Engineering team +[smoke and performance tested](index.md#validation-and-test-results) by the Test Platform team against the following endpoint throughput targets: - API: 1000 RPS @@ -178,7 +177,7 @@ The load balancers used for testing were HAProxy for Linux package environments ## Setup components -To set up GitLab and its components to accommodate up to 50,000 users: +To set up GitLab and its components to accommodate up to 1000 RPS or 50,000 users: 1. [Configure the external load balancer](#configure-the-external-load-balancer) to handle the load balancing of the GitLab application services nodes. @@ -2417,7 +2416,7 @@ Each Webservice pod consumes roughly 4 CPUs and 5 GB of memory using the [recommended topology](#cluster-topology) because four worker processes are created by default and each pod has other small processes running. -For 50,000 users we recommend a total Puma worker count of around 320. +For 1000 RPS or 50,000 users we recommend a total Puma worker count of around 320. With the [provided recommendations](#cluster-topology) this allows the deployment of up to 80 Webservice pods with 4 workers per pod and 5 pods per node. Expand available resources using the ratio of 1 CPU to 1.25 GB of memory _per each worker process_ for each additional diff --git a/doc/administration/reference_architectures/5k_users.md b/doc/administration/reference_architectures/5k_users.md index b9d4bf619cae39663e0804c1e02c0834de7bae38..7bbc4cb4d579ae8353eeeb032445b4c992e52d7a 100644 --- a/doc/administration/reference_architectures/5k_users.md +++ b/doc/administration/reference_architectures/5k_users.md @@ -4,14 +4,13 @@ group: Distribution info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments --- -# Reference architecture: up to 5,000 users +# Reference architecture: 100 RPS or up to 5,000 users DETAILS: **Tier:** Premium, Ultimate **Offering:** Self-managed -This page describes the GitLab reference architecture designed for the load of up to 5,000 users -with notable headroom. +This page describes the GitLab reference architecture designed to target a peak load of 100 requests per second (RPS) - The typical peak load of up to 5,000 users, both manual and automated, based on real data with headroom added. For a full list of reference architectures, see [Available reference architectures](index.md#available-reference-architectures). @@ -152,7 +151,7 @@ Before starting, see the [requirements](index.md#requirements) for reference arc ## Testing methodology The 5k architecture is designed to cover a large majority of workflows and is regularly -[smoke and performance tested](index.md#validation-and-test-results) by the Quality Engineering team +[smoke and performance tested](index.md#validation-and-test-results) by the Test Platform team against the following endpoint throughput targets: - API: 100 RPS @@ -174,7 +173,7 @@ The load balancers used for testing were HAProxy for Linux package environments ## Setup components -To set up GitLab and its components to accommodate up to 5,000 users: +To set up GitLab and its components to accommodate up to 100 RPS or 5,000 users: 1. [Configure the external load balancer](#configure-the-external-load-balancer) to handle the load balancing of the GitLab application services nodes. @@ -2356,7 +2355,7 @@ Each Webservice pod consumes roughly 4 CPUs and 5 GB of memory using the [recommended topology](#cluster-topology) because four worker processes are created by default and each pod has other small processes running. -For 5,000 users we recommend a total Puma worker count of around 40. +For 100 RPS or 5,000 users we recommend a total Puma worker count of around 40. With the [provided recommendations](#cluster-topology) this allows the deployment of up to 10 Webservice pods with 4 workers per pod and 2 pods per node. Expand available resources using the ratio of 1 CPU to 1.25 GB of memory _per each worker process_ for each additional diff --git a/doc/administration/reference_architectures/index.md b/doc/administration/reference_architectures/index.md index 8b36a31d4101a9f3c94bf3631d8275c464ab4cb5..c5874651cd75dd73e55e1edc24f9385e1f36137a 100644 --- a/doc/administration/reference_architectures/index.md +++ b/doc/administration/reference_architectures/index.md @@ -12,40 +12,41 @@ DETAILS: **Offering:** Self-managed The GitLab Reference Architectures have been designed and tested by the -GitLab Quality Engineering and Support teams to provide recommended deployments at scale. +GitLab Test Platform and Support teams to provide scalable recommended deployments for target loads. ## Available reference architectures The following Reference Architectures are available as recommended starting points for your environment. -The architectures are named in terms of _total_ load, both manual and automated, correlated to user count and based on real data along with substantial headroom added to add additional coverage for most scenarios. +The architectures are named in terms of peak load, based on user count or Requests per Second (RPS). Where the latter has been calculated based on average real data of the former with headroom added. -However, it should be noted that in some cases, known heavy scenarios such as [large monorepos](#large-monorepos) or notable [additional workloads](#additional-workloads) may require adjustments to be made. +NOTE: +Each architecture has been designed to be [scalable and can be adjusted accordingly if required](#scaling-an-environment) by your specific workload. This may be likely in known heavy scenarios such as using [large monorepos](#large-monorepos) or notable [additional workloads](#additional-workloads). For details about what each Reference Architecture has been tested against, see the "Testing Methodology" section of each page. ### GitLab package (Omnibus) -Below is a list of Linux package based architectures: +Below is the list of Linux package based reference architectures: -- [Up to 1,000 users](1k_users.md) _API: 20 RPS, Web: 2 RPS, Git (Pull): 2 RPS, Git (Push): 1 RPS_ -- [Up to 2,000 users](2k_users.md) _API: 40 RPS, Web: 4 RPS, Git (Pull): 4 RPS, Git (Push): 1 RPS_ -- [Up to 3,000 users](3k_users.md) _API: 60 RPS, Web: 6 RPS, Git (Pull): 6 RPS, Git (Push): 1 RPS_ -- [Up to 5,000 users](5k_users.md) _API: 100 RPS, Web: 10 RPS, Git (Pull): 10 RPS, Git (Push): 2 RPS_ -- [Up to 10,000 users](10k_users.md) _API: 200 RPS, Web: 20 RPS, Git (Pull): 20 RPS, Git (Push): 4 RPS_ -- [Up to 25,000 users](25k_users.md) _API: 500 RPS, Web: 50 RPS, Git (Pull): 50 RPS, Git (Push): 10 RPS_ -- [Up to 50,000 users](50k_users.md) _API: 1000 RPS, Web: 100 RPS, Git (Pull): 100 RPS, Git (Push): 20 RPS_ +- [Up to 20 RPS or 1,000 users](1k_users.md) _API: 20 RPS, Web: 2 RPS, Git (Pull): 2 RPS, Git (Push): 1 RPS_ +- [Up to 40 RPS or 2,000 users](2k_users.md) _API: 40 RPS, Web: 4 RPS, Git (Pull): 4 RPS, Git (Push): 1 RPS_ +- [Up to 60 RPS or 3,000 users](3k_users.md) _API: 60 RPS, Web: 6 RPS, Git (Pull): 6 RPS, Git (Push): 1 RPS_ +- [Up to 100 RPS or 5,000 users](5k_users.md) _API: 100 RPS, Web: 10 RPS, Git (Pull): 10 RPS, Git (Push): 2 RPS_ +- [Up to 200 RPS or 10,000 users](10k_users.md) _API: 200 RPS, Web: 20 RPS, Git (Pull): 20 RPS, Git (Push): 4 RPS_ +- [Up to 500 RPS or 25,000 users](25k_users.md) _API: 500 RPS, Web: 50 RPS, Git (Pull): 50 RPS, Git (Push): 10 RPS_ +- [Up to 1000 RPS or 50,000 users](50k_users.md) _API: 1000 RPS, Web: 100 RPS, Git (Pull): 100 RPS, Git (Push): 20 RPS_ ### Cloud native hybrid Below is a list of Cloud Native Hybrid reference architectures, where select recommended components can be run in Kubernetes: -- [Up to 2,000 users](2k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 40 RPS, Web: 4 RPS, Git (Pull): 4 RPS, Git (Push): 1 RPS_ -- [Up to 3,000 users](3k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 60 RPS, Web: 6 RPS, Git (Pull): 6 RPS, Git (Push): 1 RPS_ -- [Up to 5,000 users](5k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 100 RPS, Web: 10 RPS, Git (Pull): 10 RPS, Git (Push): 2 RPS_ -- [Up to 10,000 users](10k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 200 RPS, Web: 20 RPS, Git (Pull): 20 RPS, Git (Push): 4 RPS_ -- [Up to 25,000 users](25k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 500 RPS, Web: 50 RPS, Git (Pull): 50 RPS, Git (Push): 10 RPS_ -- [Up to 50,000 users](50k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 1000 RPS, Web: 100 RPS, Git (Pull): 100 RPS, Git (Push): 20 RPS_ +- [40 RPS or Up to 2,000 users](2k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 40 RPS, Web: 4 RPS, Git (Pull): 4 RPS, Git (Push): 1 RPS_ +- [60 RPS or Up to 3,000 users](3k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 60 RPS, Web: 6 RPS, Git (Pull): 6 RPS, Git (Push): 1 RPS_ +- [100 RPS or Up to 5,000 users](5k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 100 RPS, Web: 10 RPS, Git (Pull): 10 RPS, Git (Push): 2 RPS_ +- [200 RPS or Up to 10,000 users](10k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 200 RPS, Web: 20 RPS, Git (Pull): 20 RPS, Git (Push): 4 RPS_ +- [500 RPS or Up to 25,000 users](25k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 500 RPS, Web: 50 RPS, Git (Pull): 50 RPS, Git (Push): 10 RPS_ +- [1000 RPS or Up to 50,000 users](50k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) _API: 1000 RPS, Web: 100 RPS, Git (Pull): 100 RPS, Git (Push): 20 RPS_ ## Before you start @@ -67,18 +68,18 @@ As a general guide, **the more performant and/or resilient you want your environ This section explains the designs you can choose from. It begins with the least complexity, goes to the most, and ends with a decision tree. -### Expected Load (RPS) +### Expected Load (RPS or user count) + +The first thing to check is what the expected peak load is your environment would be expected to serve. -The first thing to check is what the expected load is your environment would be expected to serve. +Each architecture is described in terms of peak Requests per Second (RPS) or user count load. As detailed under the "Testing Methodology" section on each page, each architecture is tested +against its listed RPS for each endpoint type (API, Web, Git), which is the typical peak load of the given user count, both manual and automated, with headroom. -The Reference Architectures have been designed with substantial headroom by default, but it's recommended to also check the -load of what each architecture has been tested against under the "Testing Methodology" section found on each page, -comparing those values with what load you are expecting against your existing GitLab environment to help select the right Reference Architecture -size. +It's strongly recommended finding out what peak RPS your environment will be expected to handle across endpoint types, through existing metrics (such as [Prometheus](../monitoring/prometheus/gitlab_metrics.md)) +or estimates, and to select the corresponding architecture as this is the most objective. -Load is given in terms of Requests per Second (RPS) for each endpoint type (API, Web, Git). This information on your existing infrastructure -can typically be surfaced by most reputable monitoring solutions or in some other ways such as load balancer metrics. For example, on existing GitLab environments, -[Prometheus metrics](../monitoring/prometheus/gitlab_metrics.md) such as `gitlab_transaction_duration_seconds` can be used to see this data. +If it's not possible for you to find out the expected peak RPS then it's recommended to select based on user count to start and then monitor the environment +closely to confirm the RPS, whether the architecture is performing and adjust accordingly is necessary. ### Standalone (non-HA) @@ -170,10 +171,10 @@ graph TD L3A("Do you need HA?
(or Zero-Downtime Upgrades)") L3B[Do you have experience with
and want additional resilience
with select components in Kubernetes?] - L4A>Recommendation

3K architecture with HA
and supported reductions] + L4A>Recommendation

60 RPS / 3K users architecture with HA
and supported reductions] L4B>Recommendation

Architecture closest to user
count with HA] L4C>Recommendation

Cloud Native Hybrid architecture
closest to user count] - L4D>"Recommendation

Standalone 1K or 2K
architecture with Backups"] + L4D>"Recommendation

Standalone 20 RPS / 1K users or 40 RPS / 2K users
architecture with Backups"] L0A --> L1A L1A --> L2A @@ -412,7 +413,7 @@ If you choose to use a third party external service: [When selecting to use an external Redis service](../redis/replication_and_failover_external.md#redis-as-a-managed-service-in-a-cloud-provider), it should run a standard, performant, and supported version. Note that this specifically must not be run in [Cluster mode](../../install/requirements.md#redis) as this is unsupported by GitLab. -Redis is primarily single threaded. For the 10,000 user and above Reference Architectures, separate out the instances as specified into Cache and Persistent data to achieve optimum performance at this scale. +Redis is primarily single threaded. For environments targeting up to 200 RPS / 10,000 users or higher, separate out the instances as specified into Cache and Persistent data to achieve optimum performance at this scale. ### Recommendation notes for Object Storage @@ -477,7 +478,7 @@ For deploying GitLab over multiple data centers or regions we offer [GitLab Geo] ## Validation and test results -The [Quality Engineering team](https://handbook.gitlab.com/handbook/engineering/quality/) +The [Test Platform team](https://handbook.gitlab.com/handbook/engineering/quality/) does regular smoke and performance tests for the reference architectures to ensure they remain compliant. @@ -517,7 +518,7 @@ per 1,000 users: - Git (Pull): 2 RPS - Git (Push): 0.4 RPS (rounded to the nearest integer) -The above targets were selected based on real customer data of total environmental loads corresponding to the user count, including CI and other workloads along with additional substantial headroom added. +The above RPS targets were selected based on real customer data of total environmental loads corresponding to the user count, including CI and other workloads along with additional substantial headroom added. ### How to interpret the results diff --git a/doc/architecture/blueprints/cells/index.md b/doc/architecture/blueprints/cells/index.md index 12d9bb7ca1a74ab616767f5278f9051c63d979cb..644facd5a3eb4a968d2e5c93ecc35f94ea01fd21 100644 --- a/doc/architecture/blueprints/cells/index.md +++ b/doc/architecture/blueprints/cells/index.md @@ -371,7 +371,7 @@ Cluster-wide features are strongly discouraged because: Services that might initially be cluster-wide are still expected to be split in the future to achieve full service isolation. No feature should be built to depend on such a service (like Elasticsearch). -### Will Cells use the [reference architecture for 50,000 users](../../../administration/reference_architectures/50k_users.md)? +### Will Cells use the [reference architecture for up to 1000 RPS or 50,000 users](../../../administration/reference_architectures/50k_users.md)? The infrastructure team will properly size Cells depending on the load. The Tenant Scale team sees an opportunity to use GitLab Dedicated as a base for Cells deployment. diff --git a/doc/architecture/blueprints/clickhouse_usage/self_managed_costs_and_requirements/index.md b/doc/architecture/blueprints/clickhouse_usage/self_managed_costs_and_requirements/index.md index d8c9c0b25d5ee22339475a0fc43f8f51359ffcb0..25f503862137ea05de3d3392279589c1fda3b15c 100644 --- a/doc/architecture/blueprints/clickhouse_usage/self_managed_costs_and_requirements/index.md +++ b/doc/architecture/blueprints/clickhouse_usage/self_managed_costs_and_requirements/index.md @@ -40,13 +40,13 @@ GitLab Reference Architecture sizes and [costs](../../../../administration/refer | Reference Architecture | ClickHouse type | ClickHouse cost / (GitLab cost + ClickHouse cost) | |-------------|-----------------|-----------------------------------| -| [1k - non HA](https://cloud.google.com/products/calculator#id=a6d6a94a-c7dc-4c22-85c4-7c5747f272ed) | [non-HA](https://cloud.google.com/products/calculator#id=9af5359e-b155-451c-b090-5f0879bb591e) | 78.01% | -| [2k - non HA](https://cloud.google.com/products/calculator#id=0d3aff1f-ea3d-43f9-aa59-df49d27c35ca) | [non-HA](https://cloud.google.com/products/calculator#id=9af5359e-b155-451c-b090-5f0879bb591e) | 44.50% | -| [3k - HA](https://cloud.google.com/products/calculator/#id=15fc2bd9-5b1c-479d-bc46-d5ce096b8107) | [HA](https://cloud.google.com/products/calculator#id=9909f5af-d41a-4da2-b8cc-a0347702a823) | 37.87% | -| [5k - HA](https://cloud.google.com/products/calculator/#id=9a798136-53f2-4c35-be43-8e1e975a6663) | [HA](https://cloud.google.com/products/calculator#id=9909f5af-d41a-4da2-b8cc-a0347702a823) | 30.92% | -| [10k - HA](https://cloud.google.com/products/calculator#id=cbe61840-31a1-487f-88fa-631251c2fde5) | [HA](https://cloud.google.com/products/calculator#id=9909f5af-d41a-4da2-b8cc-a0347702a823) | 20.47% | -| [25k - HA](https://cloud.google.com/products/calculator#id=b4b8b587-508a-4433-adc8-dc506bbe924f) | [HA](https://cloud.google.com/products/calculator#id=9909f5af-d41a-4da2-b8cc-a0347702a823) | 14.30% | -| [50k - HA](https://cloud.google.com/products/calculator/#id=48b4d817-d6cd-44b8-b069-0ba9a5d123ea) | [HA](https://cloud.google.com/products/calculator#id=9909f5af-d41a-4da2-b8cc-a0347702a823) | 8.16% | +| [20 RPS / 1k users - non HA](https://cloud.google.com/products/calculator#id=a6d6a94a-c7dc-4c22-85c4-7c5747f272ed) | [non-HA](https://cloud.google.com/products/calculator#id=9af5359e-b155-451c-b090-5f0879bb591e) | 78.01% | +| [40 RPS / 2k users- non HA](https://cloud.google.com/products/calculator#id=0d3aff1f-ea3d-43f9-aa59-df49d27c35ca) | [non-HA](https://cloud.google.com/products/calculator#id=9af5359e-b155-451c-b090-5f0879bb591e) | 44.50% | +| [60 RPS / 3k users - HA](https://cloud.google.com/products/calculator/#id=15fc2bd9-5b1c-479d-bc46-d5ce096b8107) | [HA](https://cloud.google.com/products/calculator#id=9909f5af-d41a-4da2-b8cc-a0347702a823) | 37.87% | +| [100 RPS / 5k users - HA](https://cloud.google.com/products/calculator/#id=9a798136-53f2-4c35-be43-8e1e975a6663) | [HA](https://cloud.google.com/products/calculator#id=9909f5af-d41a-4da2-b8cc-a0347702a823) | 30.92% | +| [200 RPS / 10k users - HA](https://cloud.google.com/products/calculator#id=cbe61840-31a1-487f-88fa-631251c2fde5) | [HA](https://cloud.google.com/products/calculator#id=9909f5af-d41a-4da2-b8cc-a0347702a823) | 20.47% | +| [500 RPS / 25k users - HA](https://cloud.google.com/products/calculator#id=b4b8b587-508a-4433-adc8-dc506bbe924f) | [HA](https://cloud.google.com/products/calculator#id=9909f5af-d41a-4da2-b8cc-a0347702a823) | 14.30% | +| [1000 RPS / 50k users - HA](https://cloud.google.com/products/calculator/#id=48b4d817-d6cd-44b8-b069-0ba9a5d123ea) | [HA](https://cloud.google.com/products/calculator#id=9909f5af-d41a-4da2-b8cc-a0347702a823) | 8.16% | NOTE: The ClickHouse Self-Managed component evaluation is the minimum estimation for the costs @@ -57,7 +57,7 @@ The following components increase the cost, and were not considered in the minim - Disk size - depends on data size, hard to estimate. - Disk types - ClickHouse recommends [fast SSDs](https://clickhouse.com/docs/ru/operations/tips#storage-subsystem). - Network usage - ClickHouse recommends using [10 GB network, if possible](https://clickhouse.com/docs/en/operations/tips#network). -- For HA we sum minimum cost across all reference architectures from 3k to 50k users, but HA specs tend to increase with user count. +- For HA we sum minimum cost across all reference architectures from 60 RPS / 3k users to 1000 RPS / 50k users, but HA specs tend to increase with user count. ### Resources diff --git a/doc/development/geo.md b/doc/development/geo.md index e0b4b2a68103184d6f7969d6b82701fad986a1ed..81390ffc492e797bd85560ef37d9ebda81bc899f 100644 --- a/doc/development/geo.md +++ b/doc/development/geo.md @@ -689,7 +689,7 @@ After triggering a successful [e2e:package-and-test-ee](testing_guide/end_to_end 1. The `GET:Geo` job can be found and triggered under the `trigger-qa` stage. This pipeline uses [GET](https://gitlab.com/gitlab-org/gitlab-environment-toolkit) to spin up a -[1k](../administration/reference_architectures/1k_users.md) Geo installation, +[20 RPS / 1k users](../administration/reference_architectures/1k_users.md) Geo installation, and run the [`gitlab-qa`](https://gitlab.com/gitlab-org/gitlab-qa) Geo scenario against the instance. When working on Geo features, it is a good idea to ensure the `qa-geo` job passes in a triggered `GET:Geo pipeline`. diff --git a/doc/development/multi_version_compatibility.md b/doc/development/multi_version_compatibility.md index d91e9d10080b86e838b25cc7929e4942b481d239..d1feffb5b465be541ee03b2ac76c919fa98bf20d 100644 --- a/doc/development/multi_version_compatibility.md +++ b/doc/development/multi_version_compatibility.md @@ -93,7 +93,7 @@ These users accept some downtime during the update. Unfortunately we can't ignor ## What kind of components can GitLab be broken down into? -The [50,000 reference architecture](../administration/reference_architectures/50k_users.md) runs GitLab on 48+ nodes. GitLab.com is [bigger than that](https://handbook.gitlab.com/handbook/engineering/infrastructure/production/architecture/), plus a portion of the [infrastructure runs on Kubernetes](https://handbook.gitlab.com/handbook/engineering/infrastructure/production/architecture/#gitlab-com-architecture), plus there is a ["canary" stage which receives updates first](https://handbook.gitlab.com/handbook/engineering/infrastructure/environments/canary-stage/). +The [1000 RPS or 50,000 user reference architecture](../administration/reference_architectures/50k_users.md) runs GitLab on 48+ nodes. GitLab.com is [bigger than that](https://handbook.gitlab.com/handbook/engineering/infrastructure/production/architecture/), plus a portion of the [infrastructure runs on Kubernetes](https://handbook.gitlab.com/handbook/engineering/infrastructure/production/architecture/#gitlab-com-architecture), plus there is a ["canary" stage which receives updates first](https://handbook.gitlab.com/handbook/engineering/infrastructure/environments/canary-stage/). But the problem isn't just that there are many nodes. The bigger problem is that a deployment can be divided into different contexts. And GitLab.com is not the only one that does this. Some possible divisions: diff --git a/doc/install/aws/index.md b/doc/install/aws/index.md index 1f15b726804ffa69af3a28cbf82b17c6dd318874..df6cb7cf3455c99b3ec210363e014b4efc5a7b86 100644 --- a/doc/install/aws/index.md +++ b/doc/install/aws/index.md @@ -16,16 +16,16 @@ DETAILS: This page offers a walkthrough of a common configuration for GitLab on AWS using the official Linux package. You should customize it to accommodate your needs. NOTE: -For organizations with 1,000 users or less, the recommended AWS installation method is to launch an EC2 single box [Linux package installation](https://about.gitlab.com/install/) and implement a snapshot strategy for backing up the data. See the [1,000 user reference architecture](../../administration/reference_architectures/1k_users.md) for more information. +For organizations with 1,000 users or less, the recommended AWS installation method is to launch an EC2 single box [Linux package installation](https://about.gitlab.com/install/) and implement a snapshot strategy for backing up the data. See the [20 RPS or 1,000 user reference architecture](../../administration/reference_architectures/1k_users.md) for more information. ## Getting started for production-grade GitLab NOTE: This document is an installation guide for a proof of concept instance. It is not a reference architecture and it does not result in a highly available configuration. -Following this guide exactly results in a proof of concept instance that roughly equates to a **scaled down** version of a **two availability zone implementation** of the **Non-HA** [2000 User Reference Architecture](../../administration/reference_architectures/2k_users.md). The 2K reference architecture is not HA because it is primarily intended to provide some scaling while keeping costs and complexity low. The [3000 User Reference Architecture](../../administration/reference_architectures/3k_users.md) is the smallest size that is GitLab HA. It has additional service roles to achieve HA, most notably it uses Gitaly Cluster to achieve HA for Git repository storage and specifies triple redundancy. +Following this guide exactly results in a proof of concept instance that roughly equates to a **scaled down** version of a **two availability zone implementation** of the **Non-HA** [40 RPS or 2,000 User Reference Architecture](../../administration/reference_architectures/2k_users.md). The 2K reference architecture is not HA because it is primarily intended to provide some scaling while keeping costs and complexity low. The [60 RPS or 3,000 User Reference Architecture](../../administration/reference_architectures/3k_users.md) is the smallest size that is GitLab HA. It has additional service roles to achieve HA, most notably it uses Gitaly Cluster to achieve HA for Git repository storage and specifies triple redundancy. -GitLab maintains and tests two main types of Reference Architectures. The **Linux package architectures** are implemented on instance compute while **Cloud Native Hybrid architectures** maximize the use of a Kubernetes cluster. Cloud Native Hybrid reference architecture specifications are addendum sections to the Reference Architecture size pages that start by describing the Linux package architecture. For example, the 3000 User Cloud Native Reference Architecture is in the subsection titled [Cloud Native Hybrid reference architecture with Helm Charts (alternative)](../../administration/reference_architectures/3k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) in the 3000 User Reference Architecture page. +GitLab maintains and tests two main types of Reference Architectures. The **Linux package architectures** are implemented on instance compute while **Cloud Native Hybrid architectures** maximize the use of a Kubernetes cluster. Cloud Native Hybrid reference architecture specifications are addendum sections to the Reference Architecture size pages that start by describing the Linux package architecture. For example, the 60 RPS or 3,000 User Cloud Native Reference Architecture is in the subsection titled [Cloud Native Hybrid reference architecture with Helm Charts (alternative)](../../administration/reference_architectures/3k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) in the 60 RPS or 3,000 User Reference Architecture page. ### Getting started for production-grade Linux package installations diff --git a/doc/tutorials/install_gitlab_single_node/index.md b/doc/tutorials/install_gitlab_single_node/index.md index 37812b32025fd175b87b53eab1155484f0f936f1..35df29c54721b89d4a0fe3a6b0b2e1ccc9ff5978 100644 --- a/doc/tutorials/install_gitlab_single_node/index.md +++ b/doc/tutorials/install_gitlab_single_node/index.md @@ -12,7 +12,7 @@ DETAILS: In this tutorial you will learn how to install and securely configure a single node GitLab instance that can accommodate up to -[1,000 users](../../administration/reference_architectures/1k_users.md). +[20 RPS or 1,000 users](../../administration/reference_architectures/1k_users.md). To install a single node GitLab instance and configure it to be secure: diff --git a/doc/update/zero_downtime.md b/doc/update/zero_downtime.md index b00569bbded03516dd065b7dbc9670bfdabb2ffb..025c7811dafbb2e3856e0101e65c66f2048e6ae9 100644 --- a/doc/update/zero_downtime.md +++ b/doc/update/zero_downtime.md @@ -80,7 +80,7 @@ As such, we generally recommend the following order: In this section we'll go through the core process of upgrading a multi-node GitLab environment by sequentially going through each as per the [upgrade order](#upgrade-order) and load balancers / HA mechanisms handle each node going down accordingly. -For the purposes of this guide we'll upgrade a [10,000 Reference Architecture](../administration/reference_architectures/10k_users.md) built with the Linux package. +For the purposes of this guide we'll upgrade a [200 RPS or 10,000 Reference Architecture](../administration/reference_architectures/10k_users.md) built with the Linux package. ### Consul, PostgreSQL, PgBouncer and Redis