diff --git a/doc/administration/reference_architectures/10k_users.md b/doc/administration/reference_architectures/10k_users.md index 34506958a1ca8c9c459dc06e0e2cddd9ca84683f..2c5f0537c4897f7276c44670f612a8084bd74dc6 100644 --- a/doc/administration/reference_architectures/10k_users.md +++ b/doc/administration/reference_architectures/10k_users.md @@ -28,34 +28,38 @@ specifically the [Before you start](index.md#before-you-start) and [Deciding whi | Service | Nodes | Configuration | GCP | AWS | Azure | |------------------------------------------|-------|-------------------------|------------------|----------------|-----------| -| External load balancing node 3 | 1 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | `F2s v2` | -| Consul 1 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | `F2s v2` | -| PostgreSQL 1 | 3 | 8 vCPU, 30 GB memory | `n1-standard-8` | `m5.2xlarge` | `D8s v3` | -| PgBouncer 1 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | `F2s v2` | -| Internal load balancing node 3 | 1 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | `F2s v2` | -| Redis/Sentinel - Cache 2 | 3 | 4 vCPU, 15 GB memory | `n1-standard-4` | `m5.xlarge` | `D4s v3` | -| Redis/Sentinel - Persistent 2 | 3 | 4 vCPU, 15 GB memory | `n1-standard-4` | `m5.xlarge` | `D4s v3` | -| Gitaly 5 | 3 | 16 vCPU, 60 GB memory 6 | `n1-standard-16` | `m5.4xlarge` | `D16s v3` | -| Praefect 5 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | `F2s v2` | -| Praefect PostgreSQL 1 | 1+ | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | `F2s v2` | -| Sidekiq 7 | 4 | 4 vCPU, 15 GB memory | `n1-standard-4` | `m5.xlarge` | `D4s v3` | -| GitLab Rails 7 | 3 | 32 vCPU, 28.8 GB memory | `n1-highcpu-32` | `c5.9xlarge` | `F32s v2` | +| External load balancer3 | 1 | 4 vCPU, 3.6 GB memory | `n1-highcpu-4` | `c5n.xlarge` | `F4s v2` | +| Consul1 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | `F2s v2` | +| PostgreSQL1 | 3 | 8 vCPU, 30 GB memory | `n1-standard-8` | `m5.2xlarge` | `D8s v3` | +| PgBouncer1 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | `F2s v2` | +| Internal load balancer3 | 1 | 4 vCPU, 3.6 GB memory | `n1-highcpu-4` | `c5n.xlarge` | `F4s v2` | +| Redis/Sentinel - Cache2 | 3 | 4 vCPU, 15 GB memory | `n1-standard-4` | `m5.xlarge` | `D4s v3` | +| Redis/Sentinel - Persistent2 | 3 | 4 vCPU, 15 GB memory | `n1-standard-4` | `m5.xlarge` | `D4s v3` | +| Gitaly5 | 3 | 16 vCPU, 60 GB memory6 | `n1-standard-16` | `m5.4xlarge` | `D16s v3` | +| Praefect5 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | `F2s v2` | +| Praefect PostgreSQL1 | 1+ | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | `F2s v2` | +| Sidekiq7 | 4 | 4 vCPU, 15 GB memory | `n1-standard-4` | `m5.xlarge` | `D4s v3` | +| GitLab Rails7 | 3 | 32 vCPU, 28.8 GB memory | `n1-highcpu-32` | `c5.9xlarge` | `F32s v2` | | Monitoring node | 1 | 4 vCPU, 3.6 GB memory | `n1-highcpu-4` | `c5.xlarge` | `F4s v2` | | Object storage 4 | - | - | - | - | - | **Footnotes:** + + 1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Provide your own PostgreSQL instance](#provide-your-own-postgresql-instance) and [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information. -1. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Provide your own Redis instances](#provide-your-own-redis-instances) and [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information. +2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Provide your own Redis instances](#provide-your-own-redis-instances) and [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information. - Redis is primarily single threaded and doesn't significantly benefit from an increase in CPU cores. For this size of architecture it's strongly recommended having separate Cache and Persistent instances as specified to achieve optimum performance. -1. Can be optionally run on reputable third-party load balancing services (LB PaaS). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information. -1. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information. -1. Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management. +3. Recommended to be run with a reputable third-party load balancer or service (LB PaaS) which can provide HA capabilities. + Also note that sizing depends on selected Load Balancer as well as additional factors such as Network Bandwidth. Refer to [Load Balancers](index.md#load-balancers) for more information. +4. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information. +5. Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management. Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster). If you want sharded Gitaly, use the same specs listed above for `Gitaly`. -1. Gitaly specifications are based on high percentiles of both usage patterns and repository sizes in good health. +6. Gitaly specifications are based on high percentiles of both usage patterns and repository sizes in good health. However, if you have [large monorepos](index.md#large-monorepos) (larger than several gigabytes) or [additional workloads](index.md#additional-workloads) these can *significantly* impact Git and Gitaly performance and further adjustments will likely be required. -1. Can be placed in Auto Scaling Groups (ASGs) as the component doesn't store any [stateful data](index.md#autoscaling-of-stateful-nodes). +7. Can be placed in Auto Scaling Groups (ASGs) as the component doesn't store any [stateful data](index.md#autoscaling-of-stateful-nodes). However, for GitLab Rails certain processes like [migrations](#gitlab-rails-post-configuration) and [Mailroom](../incoming_email.md) should be run on only one node. + NOTE: For all PaaS solutions that involve configuring instances, it is strongly recommended to implement a minimum of three nodes in three different availability zones to align with resilient cloud architecture practices. @@ -238,22 +242,14 @@ The following list includes descriptions of each server and its assigned IP: ## Configure the external load balancer -In a multi-node GitLab configuration, you'll need a load balancer to route +In a multi-node GitLab configuration, you'll need an external load balancer to route traffic to the application servers. The specifics on which load balancer to use, or its exact configuration -is beyond the scope of GitLab documentation. It is expected however that any -reputable load balancer should work and as such this section will focus on the specifics of +is beyond the scope of GitLab documentation but refer to [Load Balancers](index.md) for more information around +general requirements. This section will focus on the specifics of what to configure for your load balancer of choice. -### Balancing algorithm - -We recommend that a least-connection load balancing algorithm or equivalent -is used wherever possible to ensure equal spread of calls to the nodes and good performance. - -We don't recommend the use of round-robin algorithms as they are known to not -spread connections equally in practice. - ### Readiness checks Ensure the external load balancer only routes to working services with built @@ -365,10 +361,14 @@ for details on managing SSL certificates and configuring NGINX. ## Configure the internal load balancer -The Internal Load Balancer is used to balance any internal connections the GitLab environment requires +In a multi-node GitLab configuration, you'll need an internal load balancer to route +traffic for select internal components if configured such as connections to [PgBouncer](#configure-pgbouncer) and [Praefect](#configure-praefect) (Gitaly Cluster). -It's a separate node from the External Load Balancer and shouldn't have any access externally. +The specifics on which load balancer to use, or its exact configuration +is beyond the scope of GitLab documentation but refer to [Load Balancers](index.md) for more information around +general requirements. This section will focus on the specifics of +what to configure for your load balancer of choice. The following IP will be used as an example: @@ -422,14 +422,6 @@ backend praefect Refer to your preferred Load Balancer's documentation for further guidance. -### Balancing algorithm - -We recommend that a least-connection-based load balancing algorithm or equivalent -is used wherever possible to ensure equal spread of calls to the nodes and good performance. - -We don't recommend the use of round-robin algorithms as they are known to not -spread connections equally in practice. -
Back to setup components @@ -2293,28 +2285,32 @@ services where applicable): | Service | Nodes | Configuration | GCP | AWS | |------------------------------------------|-------|-----------------------|------------------|--------------| -| Consul 1 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | -| PostgreSQL 1 | 3 | 8 vCPU, 30 GB memory | `n1-standard-8` | `m5.2xlarge` | -| PgBouncer 1 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | -| Internal load balancing node 3 | 1 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | -| Redis/Sentinel - Cache 2 | 3 | 4 vCPU, 15 GB memory | `n1-standard-4` | `m5.xlarge` | -| Redis/Sentinel - Persistent 2 | 3 | 4 vCPU, 15 GB memory | `n1-standard-4` | `m5.xlarge` | -| Gitaly 5 | 3 | 16 vCPU, 60 GB memory 6 | `n1-standard-16` | `m5.4xlarge` | -| Praefect 5 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | -| Praefect PostgreSQL 1 | 1+ | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | -| Object storage 4 | - | - | - | - | +| Consul1 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | +| PostgreSQL1 | 3 | 8 vCPU, 30 GB memory | `n1-standard-8` | `m5.2xlarge` | +| PgBouncer1 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | +| Internal load balancer3 | 1 | 4 vCPU, 3.6 GB memory | `n1-highcpu-4` | `c5n.xlarge` | +| Redis/Sentinel - Cache2 | 3 | 4 vCPU, 15 GB memory | `n1-standard-4` | `m5.xlarge` | +| Redis/Sentinel - Persistent2 | 3 | 4 vCPU, 15 GB memory | `n1-standard-4` | `m5.xlarge` | +| Gitaly5 | 3 | 16 vCPU, 60 GB memory6 | `n1-standard-16` | `m5.4xlarge` | +| Praefect5 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | +| Praefect PostgreSQL1 | 1+ | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | +| Object storage4 | - | - | - | - | **Footnotes:** + + 1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Provide your own PostgreSQL instance](#provide-your-own-postgresql-instance) and [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information. -1. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Provide your own Redis instances](#provide-your-own-redis-instances) and [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information. +2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Provide your own Redis instances](#provide-your-own-redis-instances) and [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information. - Redis is primarily single threaded and doesn't significantly benefit from an increase in CPU cores. For this size of architecture it's strongly recommended having separate Cache and Persistent instances as specified to achieve optimum performance. -1. Can be optionally run on reputable third-party load balancing services (LB PaaS). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information. -1. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information. -1. Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management. +3. Recommended to be run with a reputable third-party load balancer or service (LB PaaS) which can provide HA capabilities. + Also note that sizing depends on selected Load Balancer as well as additional factors such as Network Bandwidth. Refer to [Load Balancers](index.md#load-balancers) for more information. +4. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information. +5. Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management. Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster). If you want sharded Gitaly, use the same specs listed above for `Gitaly`. -1. Gitaly specifications are based on high percentiles of both usage patterns and repository sizes in good health. +6. Gitaly specifications are based on high percentiles of both usage patterns and repository sizes in good health. However, if you have [large monorepos](index.md#large-monorepos) (larger than several gigabytes) or [additional workloads](index.md#additional-workloads) these can *significantly* impact Git and Gitaly performance and further adjustments will likely be required. + NOTE: For all PaaS solutions that involve configuring instances, it is strongly recommended to implement a minimum of three nodes in three different availability zones to align with resilient cloud architecture practices. diff --git a/doc/administration/reference_architectures/25k_users.md b/doc/administration/reference_architectures/25k_users.md index 9206dea764ef02e983346b6601d35f97c1dd0fab..6ad78957fa5ae930d30e91cf02e7beba6eb38f47 100644 --- a/doc/administration/reference_architectures/25k_users.md +++ b/doc/administration/reference_architectures/25k_users.md @@ -28,11 +28,11 @@ specifically the [Before you start](index.md#before-you-start) and [Deciding whi | Service | Nodes | Configuration | GCP | AWS | Azure | |------------------------------------------|-------|-------------------------|------------------|--------------|-----------| -| External load balancing node3 | 1 | 4 vCPU, 3.6 GB memory | `n1-highcpu-4` | `c5.xlarge` | `F4s v2` | +| External load balancer3 | 1 | 8 vCPU, 7.2 GB memory | `n1-highcpu-8` | `c5n.2xlarge` | `F8s v2` | | Consul1 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | `F2s v2` | | PostgreSQL1 | 3 | 16 vCPU, 60 GB memory | `n1-standard-16` | `m5.4xlarge` | `D16s v3` | | PgBouncer1 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | `F2s v2` | -| Internal load balancing node3 | 1 | 4 vCPU, 3.6 GB memory | `n1-highcpu-4` | `c5.xlarge` | `F4s v2` | +| Internal load balancer3 | 1 | 8 vCPU, 7.2 GB memory | `n1-highcpu-8` | `c5n.2xlarge` | `F8s v2` | | Redis/Sentinel - Cache2 | 3 | 4 vCPU, 15 GB memory | `n1-standard-4` | `m5.xlarge` | `D4s v3` | | Redis/Sentinel - Persistent2 | 3 | 4 vCPU, 15 GB memory | `n1-standard-4` | `m5.xlarge` | `D4s v3` | | Gitaly5 | 3 | 32 vCPU, 120 GB memory6 | `n1-standard-32` | `m5.8xlarge` | `D32s v3` | @@ -43,12 +43,15 @@ specifically the [Before you start](index.md#before-you-start) and [Deciding whi | Monitoring node | 1 | 4 vCPU, 3.6 GB memory | `n1-highcpu-4` | `c5.xlarge` | `F4s v2` | | Object storage4 | - | - | - | - | - | +**Footnotes:** + 1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Provide your own PostgreSQL instance](#provide-your-own-postgresql-instance) for more information. 2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Provide your own Redis instances](#provide-your-own-redis-instances) for more information. - Redis is primarily single threaded and doesn't significantly benefit from an increase in CPU cores. For this size of architecture it's strongly recommended having separate Cache and Persistent instances as specified to achieve optimum performance. -3. Can be optionally run on reputable third-party load balancing services (LB PaaS). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information. +3. Recommended to be run with a reputable third-party load balancer or service (LB PaaS) which can provide HA capabilities. + Also note that sizing depends on selected Load Balancer as well as additional factors such as Network Bandwidth. Refer to [Load Balancers](index.md#load-balancers) for more information. 4. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information. 5. Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management. Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster). If you want sharded Gitaly, use the same specs listed above for `Gitaly`. @@ -241,22 +244,14 @@ The following list includes descriptions of each server and its assigned IP: ## Configure the external load balancer -In a multi-node GitLab configuration, you'll need a load balancer to route +In a multi-node GitLab configuration, you'll need an external load balancer to route traffic to the application servers. The specifics on which load balancer to use, or its exact configuration -is beyond the scope of GitLab documentation. It is expected however that any -reputable load balancer should work and as such this section will focus on the specifics of +is beyond the scope of GitLab documentation but refer to [Load Balancers](index.md) for more information around +general requirements. This section will focus on the specifics of what to configure for your load balancer of choice. -### Balancing algorithm - -We recommend that a least-connection load balancing algorithm or equivalent -is used wherever possible to ensure equal spread of calls to the nodes and good performance. - -We don't recommend the use of round-robin algorithms as they are known to not -spread connections equally in practice. - ### Readiness checks Ensure the external load balancer only routes to working services with built @@ -425,14 +420,6 @@ backend praefect Refer to your preferred Load Balancer's documentation for further guidance. -### Balancing algorithm - -We recommend that a least-connection load balancing algorithm or equivalent -is used wherever possible to ensure equal spread of calls to the nodes and good performance. - -We don't recommend the use of round-robin algorithms as they are known to not -spread connections equally in practice. -
Back to setup components @@ -2307,7 +2294,7 @@ services where applicable): | Consul1 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | | PostgreSQL1 | 3 | 16 vCPU, 60 GB memory | `n1-standard-16` | `m5.4xlarge` | | PgBouncer1 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | -| Internal load balancing node3 | 1 | 4 vCPU, 3.6 GB memory | `n1-highcpu-4` | `c5.xlarge` | +| Internal load balancer3 | 1 | 8 vCPU, 7.2 GB memory | `n1-highcpu-8` | `c5.2xlarge` | | Redis/Sentinel - Cache2 | 3 | 4 vCPU, 15 GB memory | `n1-standard-4` | `m5.xlarge` | | Redis/Sentinel - Persistent2 | 3 | 4 vCPU, 15 GB memory | `n1-standard-4` | `m5.xlarge` | | Gitaly5 | 3 | 32 vCPU, 120 GB memory6 | `n1-standard-32` | `m5.8xlarge` | @@ -2315,6 +2302,8 @@ services where applicable): | Praefect PostgreSQL1 | 1+ | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | | Object storage4 | - | - | - | - | +**Footnotes:** + 1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Provide your own PostgreSQL instance](#provide-your-own-postgresql-instance) for more information. diff --git a/doc/administration/reference_architectures/2k_users.md b/doc/administration/reference_architectures/2k_users.md index 2f2d2d7b865be55a6af5afca2b56020342cf20ce..c94ef66cce0d38ecfaf808bba2a596912190452e 100644 --- a/doc/administration/reference_architectures/2k_users.md +++ b/doc/administration/reference_architectures/2k_users.md @@ -23,28 +23,32 @@ For a full list of reference architectures, see > - **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). -| Service | Nodes | Configuration | GCP | AWS | Azure | -|----------------------------|-------|------------------------|-----------------|--------------|----------| -| Load balancer 3 | 1 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | `F2s v2` | -| PostgreSQL 1 | 1 | 2 vCPU, 7.5 GB memory | `n1-standard-2` | `m5.large` | `D2s v3` | -| Redis 2 | 1 | 1 vCPU, 3.75 GB memory | `n1-standard-1` | `m5.large` | `D2s v3` | -| Gitaly 5 | 1 | 4 vCPU, 15 GB memory 5 | `n1-standard-4` | `m5.xlarge` | `D4s v3` | -| Sidekiq 6 | 1 | 4 vCPU, 15 GB memory | `n1-standard-4` | `m5.xlarge` | `D4s v3` | -| GitLab Rails 6 | 2 | 8 vCPU, 7.2 GB memory | `n1-highcpu-8` | `c5.2xlarge` | `F8s v2` | -| Monitoring node | 1 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | `F2s v2` | -| Object storage 4 | - | - | - | - | - | +| Service | Nodes | Configuration | GCP | AWS | Azure | +|------------------------------------|-------|------------------------|-----------------|--------------|----------| +| External Load balancer3 | 1 | 4 vCPU, 3.6 GB memory | `n1-highcpu-4` | `c5n.xlarge` | `F4s v2` | +| PostgreSQL1 | 1 | 2 vCPU, 7.5 GB memory | `n1-standard-2` | `m5.large` | `D2s v3` | +| Redis2 | 1 | 1 vCPU, 3.75 GB memory | `n1-standard-1` | `m5.large` | `D2s v3` | +| Gitaly5 | 1 | 4 vCPU, 15 GB memory5 | `n1-standard-4` | `m5.xlarge` | `D4s v3` | +| Sidekiq6 | 1 | 4 vCPU, 15 GB memory | `n1-standard-4` | `m5.xlarge` | `D4s v3` | +| GitLab Rails6 | 2 | 8 vCPU, 7.2 GB memory | `n1-highcpu-8` | `c5.2xlarge` | `F8s v2` | +| Monitoring node | 1 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | `F2s v2` | +| Object storage4 | - | - | - | - | - | **Footnotes:** + + 1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Provide your own PostgreSQL instance](#provide-your-own-postgresql-instance) and [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information. -1. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Provide your own Redis instance](#provide-your-own-redis-instance) and [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information. -1. Can be optionally run on reputable third-party load balancing services (LB PaaS). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information. -1. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information. -1. Gitaly specifications are based on the use of normal-sized repositories in good health. +2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Provide your own Redis instance](#provide-your-own-redis-instance) and [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information. +3. Recommended to be run with a reputable third-party load balancer or service (LB PaaS). + Also note that sizing depends on selected Load Balancer as well as additional factors such as Network Bandwidth. Refer to [Load Balancers](index.md#load-balancers) for more information. +4. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information. +5. Gitaly specifications are based on the use of normal-sized repositories in good health. However, if you have large monorepos (larger than several gigabytes) this can **significantly** impact Git and Gitaly performance and an increase of specifications will likely be required. Refer to [large monorepos](index.md#large-monorepos) for more information. -1. Can be placed in Auto Scaling Groups (ASGs) as the component doesn't store any [stateful data](index.md#autoscaling-of-stateful-nodes). +6. Can be placed in Auto Scaling Groups (ASGs) as the component doesn't store any [stateful data](index.md#autoscaling-of-stateful-nodes). However, for GitLab Rails certain processes like [migrations](#gitlab-rails-post-configuration) and [Mailroom](../incoming_email.md) should be run on only one node. + NOTE: For all PaaS solutions that involve configuring instances, it's recommended to deploy them over multiple availability zones for resilience if desired. @@ -138,22 +142,14 @@ To set up GitLab and its components to accommodate up to 2,000 users: ## Configure the external load balancer -In a multi-node GitLab configuration, you'll need a load balancer to route +In a multi-node GitLab configuration, you'll need an external load balancer to route traffic to the application servers. The specifics on which load balancer to use, or its exact configuration -is beyond the scope of GitLab documentation. It is expected however that any -reputable load balancer should work and as such this section will focus on the specifics of +is beyond the scope of GitLab documentation but refer to [Load Balancers](index.md) for more information around +general requirements. This section will focus on the specifics of what to configure for your load balancer of choice. -### Balancing algorithm - -We recommend that a least-connection load balancing algorithm or equivalent -is used wherever possible to ensure equal spread of calls to the nodes and good performance. - -We don't recommend the use of round-robin algorithms as they are known to not -spread connections equally in practice. - ### Readiness checks Ensure the external load balancer only routes to working services with built @@ -1146,9 +1142,12 @@ services where applicable): **Footnotes:** + + 1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Provide your own PostgreSQL instance](#provide-your-own-postgresql-instance) and [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information. -1. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Provide your own Redis instance](#provide-your-own-redis-instance) and [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information. -1. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information. +2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Provide your own Redis instance](#provide-your-own-redis-instance) and [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information. +3. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information. + NOTE: For all PaaS solutions that involve configuring instances, it is strongly recommended to implement a minimum of three nodes in three different availability zones to align with resilient cloud architecture practices. diff --git a/doc/administration/reference_architectures/3k_users.md b/doc/administration/reference_architectures/3k_users.md index d3db0d1fabecb0788443e0d421777950361de214..ed23fb075a44f7e99d6bfbee34b2ffce3932abe8 100644 --- a/doc/administration/reference_architectures/3k_users.md +++ b/doc/administration/reference_architectures/3k_users.md @@ -28,32 +28,36 @@ For a full list of reference architectures, see | Service | Nodes | Configuration | GCP | AWS | Azure | |-------------------------------------------|-------|-----------------------|-----------------|--------------|----------| -| External load balancing node 3 | 1 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | `F2s v2` | -| Redis 2 | 3 | 2 vCPU, 7.5 GB memory | `n1-standard-2` | `m5.large` | `D2s v3` | -| Consul 1 + Sentinel 2 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | `F2s v2` | -| PostgreSQL 1 | 3 | 2 vCPU, 7.5 GB memory | `n1-standard-2` | `m5.large` | `D2s v3` | -| PgBouncer 1 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | `F2s v2` | -| Internal load balancing node 3 | 1 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | `F2s v2` | -| Gitaly 5 | 3 | 4 vCPU, 15 GB memory 6 | `n1-standard-4` | `m5.xlarge` | `D4s v3` | -| Praefect 5 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | `F2s v2` | -| Praefect PostgreSQL 1 | 1+ | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | `F2s v2` | -| Sidekiq 7 | 2 | 4 vCPU, 15 GB memory | `n1-standard-4` | `m5.xlarge` | `D2s v3` | -| GitLab Rails 7 | 3 | 8 vCPU, 7.2 GB memory | `n1-highcpu-8` | `c5.2xlarge` | `F8s v2` | +| External load balancer3 | 1 | 4 vCPU, 3.6 GB memory | `n1-highcpu-4` | `c5n.xlarge` | `F4s v2` | +| Redis2 | 3 | 2 vCPU, 7.5 GB memory | `n1-standard-2` | `m5.large` | `D2s v3` | +| Consul1 + Sentinel2 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | `F2s v2` | +| PostgreSQL1 | 3 | 2 vCPU, 7.5 GB memory | `n1-standard-2` | `m5.large` | `D2s v3` | +| PgBouncer1 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | `F2s v2` | +| Internal load balancer3 | 1 | 4 vCPU, 3.6 GB memory | `n1-highcpu-4` | `c5n.xlarge` | `F4s v2` | +| Gitaly5 | 3 | 4 vCPU, 15 GB memory6 | `n1-standard-4` | `m5.xlarge` | `D4s v3` | +| Praefect5 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | `F2s v2` | +| Praefect PostgreSQL1 | 1+ | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | `F2s v2` | +| Sidekiq7 | 2 | 4 vCPU, 15 GB memory | `n1-standard-4` | `m5.xlarge` | `D2s v3` | +| GitLab Rails7 | 3 | 8 vCPU, 7.2 GB memory | `n1-highcpu-8` | `c5.2xlarge` | `F8s v2` | | Monitoring node | 1 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | `F2s v2` | | Object storage 4 | - | - | - | - | - | **Footnotes:** + + 1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Provide your own PostgreSQL instance](#provide-your-own-postgresql-instance) for more information. -1. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Provide your own Redis instance](#provide-your-own-redis-instance) for more information. -1. Can be optionally run on reputable third-party load balancing services (LB PaaS). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information. -1. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information. -1. Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management. +2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Provide your own Redis instance](#provide-your-own-redis-instance) for more information. +3. Recommended to be run with a reputable third-party load balancer or service (LB PaaS) which can provide HA capabilities. + Also note that sizing depends on selected Load Balancer as well as additional factors such as Network Bandwidth. Refer to [Load Balancers](index.md#load-balancers) for more information. +4. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information. +5. Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management. Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster). If you want sharded Gitaly, use the same specs listed above for `Gitaly`. 1. Gitaly specifications are based on high percentiles of both usage patterns and repository sizes in good health. However, if you have [large monorepos](index.md#large-monorepos) (larger than several gigabytes) or [additional workloads](index.md#additional-workloads) these can *significantly* impact Git and Gitaly performance and further adjustments will likely be required. 1. Can be placed in Auto Scaling Groups (ASGs) as the component doesn't store any [stateful data](index.md#autoscaling-of-stateful-nodes). However, for GitLab Rails certain processes like [migrations](#gitlab-rails-post-configuration) and [Mailroom](../incoming_email.md) should be run on only one node. + NOTE: For all PaaS solutions that involve configuring instances, it is strongly recommended to implement a minimum of three nodes in three different availability zones to align with resilient cloud architecture practices. @@ -228,22 +232,14 @@ The following list includes descriptions of each server and its assigned IP: ## Configure the external load balancer -In a multi-node GitLab configuration, you'll need a load balancer to route +In a multi-node GitLab configuration, you'll need an external load balancer to route traffic to the application servers. The specifics on which load balancer to use, or its exact configuration -is beyond the scope of GitLab documentation. It is expected however that any -reputable load balancer should work and as such this section will focus on the specifics of +is beyond the scope of GitLab documentation but refer to [Load Balancers](index.md) for more information around +general requirements. This section will focus on the specifics of what to configure for your load balancer of choice. -### Balancing algorithm - -We recommend that a least-connection load balancing algorithm or equivalent -is used wherever possible to ensure equal spread of calls to the nodes and good performance. - -We don't recommend the use of round-robin algorithms as they are known to not -spread connections equally in practice. - ### Readiness checks Ensure the external load balancer only routes to working services with built @@ -355,10 +351,14 @@ for details on managing SSL certificates and configuring NGINX. ## Configure the internal load balancer -The Internal Load Balancer is used to balance any internal connections the GitLab environment requires +In a multi-node GitLab configuration, you'll need an internal load balancer to route +traffic for select internal components if configured such as connections to [PgBouncer](#configure-pgbouncer) and [Praefect](#configure-praefect) (Gitaly Cluster). -It's a separate node from the External Load Balancer and shouldn't have any access externally. +The specifics on which load balancer to use, or its exact configuration +is beyond the scope of GitLab documentation but refer to [Load Balancers](index.md) for more information around +general requirements. This section will focus on the specifics of +what to configure for your load balancer of choice. The following IP will be used as an example: @@ -412,14 +412,6 @@ backend praefect Refer to your preferred Load Balancer's documentation for further guidance. -### Balancing algorithm - -We recommend that a least-connection load balancing algorithm or equivalent -is used wherever possible to ensure equal spread of calls to the nodes and good performance. - -We don't recommend the use of round-robin algorithms as they are known to not -spread connections equally in practice. -
Back to setup components @@ -2281,26 +2273,30 @@ services where applicable): | Service | Nodes | Configuration | GCP | AWS | |-------------------------------------------|-------|-----------------------|-----------------|-------------| -| Redis 2 | 3 | 2 vCPU, 7.5 GB memory | `n1-standard-2` | `m5.large` | -| Consul 1 + Sentinel 2 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | -| PostgreSQL 1 | 3 | 2 vCPU, 7.5 GB memory | `n1-standard-2` | `m5.large` | -| PgBouncer 1 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | -| Internal load balancing node 3 | 1 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | -| Gitaly 5 | 3 | 4 vCPU, 15 GB memory 6 | `n1-standard-4` | `m5.xlarge` | -| Praefect 5 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | -| Praefect PostgreSQL 1 | 1+ | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | -| Object storage 4 | - | - | - | - | +| Redis2 | 3 | 2 vCPU, 7.5 GB memory | `n1-standard-2` | `m5.large` | +| Consul1 + Sentinel2 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | +| PostgreSQL1 | 3 | 2 vCPU, 7.5 GB memory | `n1-standard-2` | `m5.large` | +| PgBouncer1 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | +| Internal load balancer3 | 1 | 4 vCPU, 3.6 GB memory | `n1-highcpu-4` | `c5n.xlarge` | +| Gitaly5 | 3 | 4 vCPU, 15 GB memory6 | `n1-standard-4` | `m5.xlarge` | +| Praefect5 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | +| Praefect PostgreSQL1 | 1+ | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | +| Object storage4 | - | - | - | - | **Footnotes:** + + 1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Provide your own PostgreSQL instance](#provide-your-own-postgresql-instance) for more information. -1. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Provide your own Redis instance](#provide-your-own-redis-instance) for more information. -1. Can be optionally run on reputable third-party load balancing services (LB PaaS). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information. -1. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information. -1. Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management. +2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Provide your own Redis instance](#provide-your-own-redis-instance) for more information. +3. Recommended to be run with a reputable third-party load balancer or service (LB PaaS) which can provide HA capabilities. + Also note that sizing depends on selected Load Balancer as well as additional factors such as Network Bandwidth. Refer to [Load Balancers](index.md#load-balancers) for more information. +4. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information. +5. Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management. Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster). If you want sharded Gitaly, use the same specs listed above for `Gitaly`. -1. Gitaly specifications are based on high percentiles of both usage patterns and repository sizes in good health. +6. Gitaly specifications are based on high percentiles of both usage patterns and repository sizes in good health. However, if you have [large monorepos](index.md#large-monorepos) (larger than several gigabytes) or [additional workloads](index.md#additional-workloads) these can *significantly* impact Git and Gitaly performance and further adjustments will likely be required. + NOTE: For all PaaS solutions that involve configuring instances, it is strongly recommended to implement a minimum of three nodes in three different availability zones to align with resilient cloud architecture practices. diff --git a/doc/administration/reference_architectures/50k_users.md b/doc/administration/reference_architectures/50k_users.md index affef4101367cf7d8593ac7397840c90694bcb8c..11c26bdd2ac26143277fa3404fd6625f2399d785 100644 --- a/doc/administration/reference_architectures/50k_users.md +++ b/doc/administration/reference_architectures/50k_users.md @@ -28,11 +28,11 @@ specifically the [Before you start](index.md#before-you-start) and [Deciding whi | Service | Nodes | Configuration | GCP | AWS | Azure | |------------------------------------------|-------|-------------------------|------------------|---------------|-----------| -| External load balancing node3 | 1 | 8 vCPU, 7.2 GB memory | `n1-highcpu-8` | `c5.2xlarge` | `F8s v2` | +| External load balancer3 | 1 | 16 vCPU, 14.4 GB memory | `n1-highcpu-16` | `c5.4xlarge` | `F16s v2` | | Consul1 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | `F2s v2` | | PostgreSQL1 | 3 | 32 vCPU, 120 GB memory | `n1-standard-32` | `m5.8xlarge` | `D32s v3` | | PgBouncer1 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | `F2s v2` | -| Internal load balancing node3 | 1 | 8 vCPU, 7.2 GB memory | `n1-highcpu-8` | `c5.2xlarge` | `F8s v2` | +| Internal load balancer3 | 1 | 16 vCPU, 14.4 GB memory | `n1-highcpu-16` | `c5.4xlarge` | `F16s v2` | | Redis/Sentinel - Cache2 | 3 | 4 vCPU, 15 GB memory | `n1-standard-4` | `m5.xlarge` | `D4s v3` | | Redis/Sentinel - Persistent2 | 3 | 4 vCPU, 15 GB memory | `n1-standard-4` | `m5.xlarge` | `D4s v3` | | Gitaly5 | 3 | 64 vCPU, 240 GB memory6 | `n1-standard-64` | `m5.16xlarge` | `D64s v3` | @@ -43,6 +43,8 @@ specifically the [Before you start](index.md#before-you-start) and [Deciding whi | Monitoring node | 1 | 4 vCPU, 3.6 GB memory | `n1-highcpu-4` | `c5.xlarge` | `F4s v2` | | Object storage4 | - | - | - | - | - | +**Footnotes:** + 1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Provide your own PostgreSQL instance](#provide-your-own-postgresql-instance) for more information. @@ -248,22 +250,14 @@ The following list includes descriptions of each server and its assigned IP: ## Configure the external load balancer -In a multi-node GitLab configuration, you'll need a load balancer to route +In a multi-node GitLab configuration, you'll need an external load balancer to route traffic to the application servers. The specifics on which load balancer to use, or its exact configuration -is beyond the scope of GitLab documentation. It is expected however that any -reputable load balancer should work and as such this section will focus on the specifics of +is beyond the scope of GitLab documentation but refer to [Load Balancers](index.md) for more information around +general requirements. This section will focus on the specifics of what to configure for your load balancer of choice. -### Balancing algorithm - -You should use a least-connection load balancing algorithm or equivalent -wherever possible to ensure equal spread of calls to the nodes and good performance. - -We don't recommend the use of round-robin algorithms as they are known to not -spread connections equally in practice. - ### Readiness checks Ensure the external load balancer only routes to working services with built @@ -375,10 +369,14 @@ for details on managing SSL certificates and configuring NGINX. ## Configure the internal load balancer -The Internal Load Balancer is used to balance any internal connections the GitLab environment requires +In a multi-node GitLab configuration, you'll need an internal load balancer to route +traffic for select internal components if configured such as connections to [PgBouncer](#configure-pgbouncer) and [Praefect](#configure-praefect) (Gitaly Cluster). -It's a separate node from the External Load Balancer and shouldn't have any access externally. +The specifics on which load balancer to use, or its exact configuration +is beyond the scope of GitLab documentation but refer to [Load Balancers](index.md) for more information around +general requirements. This section will focus on the specifics of +what to configure for your load balancer of choice. The following IP will be used as an example: @@ -432,14 +430,6 @@ backend praefect Refer to your preferred Load Balancer's documentation for further guidance. -### Balancing algorithm - -We recommend that a least-connection load balancing algorithm or equivalent -is used wherever possible to ensure equal spread of calls to the nodes and good performance. - -We don't recommend the use of round-robin algorithms as they are known to not -spread connections equally in practice. -
Back to setup components @@ -2318,7 +2308,7 @@ services where applicable): | Consul1 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | | PostgreSQL1 | 3 | 32 vCPU, 120 GB memory | `n1-standard-32` | `m5.8xlarge` | | PgBouncer1 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | -| Internal load balancing node3 | 1 | 8 vCPU, 7.2 GB memory | `n1-highcpu-8` | `c5.2xlarge` | +| Internal load balancer3 | 1 | 16 vCPU, 14.4 GB memory | `n1-highcpu-16` | `c5.4xlarge` | | Redis/Sentinel - Cache2 | 3 | 4 vCPU, 15 GB memory | `n1-standard-4` | `m5.xlarge` | | Redis/Sentinel - Persistent2 | 3 | 4 vCPU, 15 GB memory | `n1-standard-4` | `m5.xlarge` | | Gitaly5 | 3 | 64 vCPU, 240 GB memory6 | `n1-standard-64` | `m5.16xlarge` | @@ -2326,6 +2316,8 @@ services where applicable): | Praefect PostgreSQL1 | 1+ | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | | Object storage4 | - | - | - | - | +**Footnotes:** + 1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Provide your own PostgreSQL instance](#provide-your-own-postgresql-instance) for more information. diff --git a/doc/administration/reference_architectures/5k_users.md b/doc/administration/reference_architectures/5k_users.md index 4524248833ee927443d50c8478fa663ebad1fcf0..14f60d73f65516f2b130e5086acaa932038b6624 100644 --- a/doc/administration/reference_architectures/5k_users.md +++ b/doc/administration/reference_architectures/5k_users.md @@ -26,34 +26,38 @@ specifically the [Before you start](index.md#before-you-start) and [Deciding whi > - **Cloud Native Hybrid Alternative:** [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) -| Service | Nodes | Configuration | GCP | AWS | Azure | -|---------------------------------------------|-------|-------------------------|-----------------|--------------|----------| -| External load balancing node 3 | 1 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | `F2s v2` | -| Redis 2 | 3 | 2 vCPU, 7.5 GB memory | `n1-standard-2` | `m5.large` | `D2s v3` | -| Consul 1 + Sentinel 2 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | `F2s v2` | -| PostgreSQL 1 | 3 | 4 vCPU, 15 GB memory | `n1-standard-4` | `m5.xlarge` | `D4s v3` | -| PgBouncer 1 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | `F2s v2` | -| Internal load balancing node 3 | 1 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | `F2s v2` | -| Gitaly 5 | 3 | 8 vCPU, 30 GB memory 6 | `n1-standard-8` | `m5.2xlarge` | `D8s v3` | -| Praefect 5 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | `F2s v2` | -| Praefect PostgreSQL 1 | 1+ | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | `F2s v2` | -| Sidekiq 7 | 2 | 4 vCPU, 15 GB memory | `n1-standard-4` | `m5.xlarge` | `D2s v3` | -| GitLab Rails 7 | 3 | 16 vCPU, 14.4 GB memory | `n1-highcpu-16` | `c5.4xlarge` | `F16s v2`| -| Monitoring node | 1 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | `F2s v2` | -| Object storage 4 | - | - | - | - | - | +| Service | Nodes | Configuration | GCP | AWS | Azure | +|-------------------------------------------|-------|-------------------------|-----------------|--------------|----------| +| External load balancer3 | 1 | 4 vCPU, 3.6 GB memory | `n1-highcpu-4` | `c5n.xlarge` | `F4s v2` | +| Redis2 | 3 | 2 vCPU, 7.5 GB memory | `n1-standard-2` | `m5.large` | `D2s v3` | +| Consul1 + Sentinel2 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | `F2s v2` | +| PostgreSQL1 | 3 | 4 vCPU, 15 GB memory | `n1-standard-4` | `m5.xlarge` | `D4s v3` | +| PgBouncer1 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | `F2s v2` | +| Internal load balancer3 | 1 | 4 vCPU, 3.6 GB memory | `n1-highcpu-4` | `c5n.xlarge` | `F4s v2` | +| Gitaly5 | 3 | 8 vCPU, 30 GB memory6 | `n1-standard-8` | `m5.2xlarge` | `D8s v3` | +| Praefect5 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | `F2s v2` | +| Praefect PostgreSQL1 | 1+ | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | `F2s v2` | +| Sidekiq7 | 2 | 4 vCPU, 15 GB memory | `n1-standard-4` | `m5.xlarge` | `D2s v3` | +| GitLab Rails7 | 3 | 16 vCPU, 14.4 GB memory | `n1-highcpu-16` | `c5.4xlarge` | `F16s v2`| +| Monitoring node | 1 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | `F2s v2` | +| Object storage4 | - | - | - | - | - | **Footnotes:** + + 1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Provide your own PostgreSQL instance](#provide-your-own-postgresql-instance) for more information. -1. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Provide your own Redis instance](#provide-your-own-redis-instance) for more information. -1. Can be optionally run on reputable third-party load balancing services (LB PaaS). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information. -1. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information. -1. Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management. +2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Provide your own Redis instance](#provide-your-own-redis-instance) for more information. +3. Recommended to be run with a reputable third-party load balancer or service (LB PaaS) which can provide HA capabilities. + Also note that sizing depends on selected Load Balancer as well as additional factors such as Network Bandwidth. Refer to [Load Balancers](index.md#load-balancers) for more information. +4. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information. +5. Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management. Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster). If you want sharded Gitaly, use the same specs listed above for `Gitaly`. -1. Gitaly specifications are based on high percentiles of both usage patterns and repository sizes in good health. +6. Gitaly specifications are based on high percentiles of both usage patterns and repository sizes in good health. However, if you have [large monorepos](index.md#large-monorepos) (larger than several gigabytes) or [additional workloads](index.md#additional-workloads) these can *significantly* impact Git and Gitaly performance and further adjustments will likely be required. -1. Can be placed in Auto Scaling Groups (ASGs) as the component doesn't store any [stateful data](index.md#autoscaling-of-stateful-nodes). +7. Can be placed in Auto Scaling Groups (ASGs) as the component doesn't store any [stateful data](index.md#autoscaling-of-stateful-nodes). However, for GitLab Rails certain processes like [migrations](#gitlab-rails-post-configuration) and [Mailroom](../incoming_email.md) should be run on only one node. + NOTE: For all PaaS solutions that involve configuring instances, it is strongly recommended to implement a minimum of three nodes in three different availability zones to align with resilient cloud architecture practices. @@ -228,22 +232,14 @@ The following list includes descriptions of each server and its assigned IP: ## Configure the external load balancer -In a multi-node GitLab configuration, you'll need a load balancer to route +In a multi-node GitLab configuration, you'll need an external load balancer to route traffic to the application servers. The specifics on which load balancer to use, or its exact configuration -is beyond the scope of GitLab documentation. It is expected however that any -reputable load balancer should work and as such this section will focus on the specifics of +is beyond the scope of GitLab documentation but refer to [Load Balancers](index.md) for more information around +general requirements. This section will focus on the specifics of what to configure for your load balancer of choice. -### Balancing algorithm - -We recommend that a least-connection load balancing algorithm or equivalent -is used wherever possible to ensure equal spread of calls to the nodes and good performance. - -We don't recommend the use of round-robin algorithms as they are known to not -spread connections equally in practice. - ### Readiness checks Ensure the external load balancer only routes to working services with built @@ -355,10 +351,14 @@ for details on managing SSL certificates and configuring NGINX. ## Configure the internal load balancer -The Internal Load Balancer is used to balance any internal connections the GitLab environment requires +In a multi-node GitLab configuration, you'll need an internal load balancer to route +traffic for select internal components if configured such as connections to [PgBouncer](#configure-pgbouncer) and [Praefect](#configure-praefect) (Gitaly Cluster). -It's a separate node from the External Load Balancer and shouldn't have any access externally. +The specifics on which load balancer to use, or its exact configuration +is beyond the scope of GitLab documentation but refer to [Load Balancers](index.md) for more information around +general requirements. This section will focus on the specifics of +what to configure for your load balancer of choice. The following IP is used as an example: @@ -412,14 +412,6 @@ backend praefect Refer to your preferred Load Balancer's documentation for further guidance. -### Balancing algorithm - -We recommend that a least-connection load balancing algorithm or equivalent -is used wherever possible to ensure equal spread of calls to the nodes and good performance. - -We don't recommend the use of round-robin algorithms as they are known to not -spread connections equally in practice. -
Back to setup components @@ -2254,28 +2246,32 @@ the overall makeup as desired as long as the minimum CPU and Memory requirements Next are the backend components that run on static compute VMs using the Linux package (or External PaaS services where applicable): -| Service | Nodes | Configuration | GCP | AWS | -|---------------------------------------------|-------|-----------------------|-----------------|--------------| -| Redis 2 | 3 | 2 vCPU, 7.5 GB memory | `n1-standard-2` | `m5.large` | -| Consul 1 + Sentinel 2 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | -| PostgreSQL 1 | 3 | 4 vCPU, 15 GB memory | `n1-standard-4` | `m5.xlarge` | -| PgBouncer 1 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | -| Internal load balancing node 3 | 1 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | -| Gitaly 5 | 3 | 8 vCPU, 30 GB memory 6 | `n1-standard-8` | `m5.2xlarge` | -| Praefect 5 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | -| Praefect PostgreSQL 1 | 1+ | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | -| Object storage 4 | - | - | - | - | +| Service | Nodes | Configuration | GCP | AWS | +|-------------------------------------------|-------|-----------------------|-----------------|--------------| +| Redis2 | 3 | 2 vCPU, 7.5 GB memory | `n1-standard-2` | `m5.large` | +| Consul1 + Sentinel2 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | +| PostgreSQL1 | 3 | 4 vCPU, 15 GB memory | `n1-standard-4` | `m5.xlarge` | +| PgBouncer1 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | +| Internal load balancer3 | 1 | 4 vCPU, 3.6 GB memory | `n1-highcpu-4` | `c5n.xlarge` | +| Gitaly5 | 3 | 8 vCPU, 30 GB memory6 | `n1-standard-8` | `m5.2xlarge` | +| Praefect5 | 3 | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | +| Praefect PostgreSQL1 | 1+ | 2 vCPU, 1.8 GB memory | `n1-highcpu-2` | `c5.large` | +| Object storage4 | - | - | - | - | **Footnotes:** + + 1. Can be optionally run on reputable third-party external PaaS PostgreSQL solutions. See [Provide your own PostgreSQL instance](#provide-your-own-postgresql-instance) for more information. -1. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Provide your own Redis instance](#provide-your-own-redis-instance) for more information. -1. Can be optionally run on reputable third-party load balancing services (LB PaaS). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information. -1. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information. -1. Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management. +2. Can be optionally run on reputable third-party external PaaS Redis solutions. See [Provide your own Redis instance](#provide-your-own-redis-instance) for more information. +3. Recommended to be run with a reputable third-party load balancer or service (LB PaaS). + Also note that sizing depends on selected Load Balancer as well as additional factors such as Network Bandwidth. Refer to [Load Balancers](index.md#load-balancers) for more information. +4. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information. +5. Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management. Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster). If you want sharded Gitaly, use the same specs listed above for `Gitaly`. -1. Gitaly specifications are based on high percentiles of both usage patterns and repository sizes in good health. +6. Gitaly specifications are based on high percentiles of both usage patterns and repository sizes in good health. However, if you have [large monorepos](index.md#large-monorepos) (larger than several gigabytes) or [additional workloads](index.md#additional-workloads) these can *significantly* impact Git and Gitaly performance and further adjustments will likely be required. + NOTE: For all PaaS solutions that involve configuring instances, it is strongly recommended to implement a minimum of three nodes in three different availability zones to align with resilient cloud architecture practices. diff --git a/doc/administration/reference_architectures/index.md b/doc/administration/reference_architectures/index.md index 9a861039d19465c5927f10b417b014358a74c358..65d9c038d2945fbb8bb4f8a84b7f6f34b8c0fa8a 100644 --- a/doc/administration/reference_architectures/index.md +++ b/doc/administration/reference_architectures/index.md @@ -277,6 +277,32 @@ As a general rule, you should have robust monitoring in place to measure the imp inform any changes needed to be made. It's also strongly encouraged for you to reach out to your [Customer Success Manager](https://handbook.gitlab.com/job-families/sales/customer-success-management/) or our [Support team](https://about.gitlab.com/support/) for further guidance. +### Load Balancers + +The Reference Architectures make use of up to two Load Balancers depending on the class: + +- External Load Balancer - Serves traffic to any external facing components, primarily Rails. +- Internal Load Balancer - Serves traffic to select internal components that have been deployed in an HA fashion such as Praefect or PgBouncer. + +The specifics on which load balancer to use, or its exact configuration is beyond the scope of GitLab documentation. The most common options +are to set up load balancers on machine nodes or to use a service such as one offered by Cloud Providers. If deploying a Cloud Native Hybrid environment the Charts can handle the set-up of the External Load Balancer via Kubernetes Ingress. + +For each Reference Architecture class a base machine size has given to help get you started if you elect to deploy directly on machines, but these may need to be adjusted accordingly depending on the load balancer used and amount of workload. Of note machines can have varying [network bandwidth](#network-bandwidth) that should also be taken into consideration. + +Note the following sections of additional guidance for Load Balancers. + +#### Balancing algorithm + +We recommend that a least-connection-based load balancing algorithm or equivalent is used wherever possible to ensure equal spread of calls to the nodes and good performance. + +We don’t recommend the use of round-robin algorithms as they are known to not spread connections equally in practice. + +#### Network Bandwidth + +The total network bandwidth available to a load balancer when deployed on a machine can vary notably across Cloud Providers. In particular some Cloud Providers, like [AWS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html), may operate on a burst system with credits to determine the bandwidth at any time. + +The network bandwidth your environment's load balancers will require is dependent on numerous factors such as data shape and workload. The recommended base sizes for each Reference Architecture class have been selected to give a good level of bandwidth with adequate headroom but in some scenarios, such as consistent clones of [large monorepos](#large-monorepos), the sizes may need to be adjusted accordingly. + ### No swap Swap is not recommended in the reference architectures. It's a failsafe that impacts performance greatly. The @@ -491,6 +517,8 @@ 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. + ### How to interpret the results NOTE: @@ -729,14 +757,14 @@ You can find a full history of changes [on the GitLab project](https://gitlab.co **2024:** +- [2024-02](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/145436): Updated recommended sizings for Load Balancer nodes if deployed on VMs. Also added notes on network bandwidth considerations. - [2024-02](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/143539): Remove the Sidekiq Max Concurrency setting in examples as this is deprecated and no longer required to be set explicitly. - [2024-02](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/143539): Adjusted the Sidekiq recommendations on 2k to disable Sidekiq on Rails nodes and updated architecture diagram. - [2024-01](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/140465): Updated recommendations for Azure for all Reference Architecture sizes and latest cloud services. **2023:** -- [2023-12-12](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/133457): Updated notes on Load Balancers to be more reflective that any reputable offering is expected to work. -- [2023-12-12](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/133457): Updated notes on Load Balancers to be more reflective that any reputable offering is expected to work. +- [2023-12-12](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/139557): Updated notes on Load Balancers to be more reflective that any reputable offering is expected to work. - [2023-11-03](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/133457): Expanded details on what each Reference Architecture is designed for, the testing methodology used as well as added details on how to scale environments. - [2023-11-03](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/134518): Added expanded notes on disk types, object storage and monitoring. - [2023-10-25](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/134518): Adjusted Sidekiq configuration example to use Linux Package role.