diff --git a/doc/administration/reference_architectures/10k_users.md b/doc/administration/reference_architectures/10k_users.md index e5b36f97fa2e3abf8ba1b38fa0ad697febf54132..defc74b7e9e4af56fc5dd15dc6abc15716fb0c66 100644 --- a/doc/administration/reference_architectures/10k_users.md +++ b/doc/administration/reference_architectures/10k_users.md @@ -168,6 +168,8 @@ If this applies to you, we strongly recommended referring to the linked document Testing is done regularly via our [GitLab Performance Tool (GPT)](https://gitlab.com/gitlab-org/quality/performance) and its dataset, which is available for anyone to use. The results of this testing are [available publicly on the GPT wiki](https://gitlab.com/gitlab-org/quality/performance/-/wikis/Benchmarks/Latest). For more information on our testing strategy [refer to this section of the documentation](index.md#validation-and-test-results). +The load balancers used for testing were HAProxy for Linux package environments or equivalent Cloud Provider services via NGINX Ingress for Cloud Native Hybrids. Note that these selections do not represent a specific requirement or recommendation as most [reputable load balancers are expected to work](#configure-the-external-load-balancer). + ## Setup components To set up GitLab and its components to accommodate up to 10,000 users: @@ -234,16 +236,12 @@ 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 -traffic to the application servers. The specifics on which load balancer to use -or its exact configuration is beyond the scope of GitLab documentation. We assume -that if you're managing multi-node systems like GitLab, you already have a load -balancer of choice. Some load balancer examples include HAProxy (open-source), -F5 Big-IP LTM, and Citrix Net Scaler. This documentation outline the ports and -protocols needed for use with GitLab. - -This architecture has been tested and validated with [HAProxy](https://www.haproxy.org/) -as the load balancer. Although other load balancers with similar feature sets -could also be used, those load balancers have not been validated. +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 +what to configure for your load balancer of choice. ### Balancing algorithm diff --git a/doc/administration/reference_architectures/25k_users.md b/doc/administration/reference_architectures/25k_users.md index 4235edea58cd7dee78672d033d80272c49c54c1d..6520f63957b3120e2a76b85ec689dfb529c28bb6 100644 --- a/doc/administration/reference_architectures/25k_users.md +++ b/doc/administration/reference_architectures/25k_users.md @@ -168,6 +168,8 @@ If this applies to you, we strongly recommended referring to the linked document Testing is done regularly via our [GitLab Performance Tool (GPT)](https://gitlab.com/gitlab-org/quality/performance) and its dataset, which is available for anyone to use. The results of this testing are [available publicly on the GPT wiki](https://gitlab.com/gitlab-org/quality/performance/-/wikis/Benchmarks/Latest). For more information on our testing strategy [refer to this section of the documentation](index.md#validation-and-test-results). +The load balancers used for testing were HAProxy for Linux package environments or equivalent Cloud Provider services via NGINX Ingress for Cloud Native Hybrids. Note that these selections do not represent a specific requirement or recommendation as most [reputable load balancers are expected to work](#configure-the-external-load-balancer). + ## Setup components To set up GitLab and its components to accommodate up to 25,000 users: @@ -236,25 +238,12 @@ 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 -traffic to the application servers. The specifics on which load balancer to use -or its exact configuration is beyond the scope of GitLab documentation. We assume -that if you're managing multi-node systems like GitLab, you already have a load -balancer of choice. Some load balancer examples include HAProxy (open-source), -F5 Big-IP LTM, and Citrix Net Scaler. This documentation outline the ports and -protocols needed for use with GitLab. - -This architecture has been tested and validated with [HAProxy](https://www.haproxy.org/) -as the load balancer. Although other load balancers with similar feature sets -could also be used, those load balancers have not been validated. - -The next question is how you will handle SSL in your environment. -There are several different options: +traffic to the application servers. -- [The application node terminates SSL](#application-node-terminates-ssl). -- [The load balancer terminates SSL without backend SSL](#load-balancer-terminates-ssl-without-backend-ssl) - and communication is not secure between the load balancer and the application node. -- [The load balancer terminates SSL with backend SSL](#load-balancer-terminates-ssl-with-backend-ssl) - and communication is *secure* between the load balancer and the application node. +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 +what to configure for your load balancer of choice. ### Balancing algorithm diff --git a/doc/administration/reference_architectures/2k_users.md b/doc/administration/reference_architectures/2k_users.md index e14724fb5d8018f8842658e95d0af9b65cabd3ac..d3f53ce3e14bed1b149616c589f944a10fd53bf7 100644 --- a/doc/administration/reference_architectures/2k_users.md +++ b/doc/administration/reference_architectures/2k_users.md @@ -101,6 +101,8 @@ If this applies to you, we strongly recommended referring to the linked document Testing is done regularly via our [GitLab Performance Tool (GPT)](https://gitlab.com/gitlab-org/quality/performance) and its dataset, which is available for anyone to use. The results of this testing are [available publicly on the GPT wiki](https://gitlab.com/gitlab-org/quality/performance/-/wikis/Benchmarks/Latest). For more information on our testing strategy [refer to this section of the documentation](index.md#validation-and-test-results). +The load balancers used for testing were HAProxy for Linux package environments or equivalent Cloud Provider services via NGINX Ingress for Cloud Native Hybrids. Note that these selections do not represent a specific requirement or recommendation as most [reputable load balancers are expected to work](#configure-the-external-load-balancer). + ## Setup components To set up GitLab and its components to accommodate up to 2,000 users: @@ -124,25 +126,12 @@ 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 -traffic to the application servers. The specifics on which load balancer to use -or its exact configuration is beyond the scope of GitLab documentation. We assume -that if you're managing multi-node systems like GitLab, you already have a load -balancer of choice. Some load balancer examples include HAProxy (open-source), -F5 Big-IP LTM, and Citrix Net Scaler. This documentation outline the ports and -protocols needed for use with GitLab. - -This architecture has been tested and validated with [HAProxy](https://www.haproxy.org/) -as the load balancer. Although other load balancers with similar feature sets -could also be used, those load balancers have not been validated. +traffic to the application servers. -The next question is how you will handle SSL in your environment. There are -several different options: - -- [The application node terminates SSL](#application-node-terminates-ssl). -- [The load balancer terminates SSL without backend SSL](#load-balancer-terminates-ssl-without-backend-ssl) - and communication is not secure between the load balancer and the application node. -- [The load balancer terminates SSL with backend SSL](#load-balancer-terminates-ssl-with-backend-ssl) - and communication is *secure* between the load balancer and the application node. +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 +what to configure for your load balancer of choice. ### Balancing algorithm diff --git a/doc/administration/reference_architectures/3k_users.md b/doc/administration/reference_architectures/3k_users.md index d298bb4fb117fa246302a06cdb183962aaed27af..c01564a3e7a40fcc6392c6475a2263db27022faa 100644 --- a/doc/administration/reference_architectures/3k_users.md +++ b/doc/administration/reference_architectures/3k_users.md @@ -163,6 +163,8 @@ If this applies to you, we strongly recommended referring to the linked document Testing is done regularly via our [GitLab Performance Tool (GPT)](https://gitlab.com/gitlab-org/quality/performance) and its dataset, which is available for anyone to use. The results of this testing are [available publicly on the GPT wiki](https://gitlab.com/gitlab-org/quality/performance/-/wikis/Benchmarks/Latest). For more information on our testing strategy [refer to this section of the documentation](index.md#validation-and-test-results). +The load balancers used for testing were HAProxy for Linux package environments or equivalent Cloud Provider services via NGINX Ingress for Cloud Native Hybrids. Note that these selections do not represent a specific requirement or recommendation as most [reputable load balancers are expected to work](#configure-the-external-load-balancer). + ## Setup components To set up GitLab and its components to accommodate up to 3,000 users: @@ -224,25 +226,12 @@ 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 -traffic to the application servers. The specifics on which load balancer to use -or its exact configuration is beyond the scope of GitLab documentation. We assume -that if you're managing multi-node systems like GitLab, you already have a load -balancer of choice. Some load balancer examples include HAProxy (open-source), -F5 Big-IP LTM, and Citrix Net Scaler. This documentation outline the ports and -protocols needed for use with GitLab. - -This architecture has been tested and validated with [HAProxy](https://www.haproxy.org/) -as the load balancer. Although other load balancers with similar feature sets -could also be used, those load balancers have not been validated. - -The next question is how you will handle SSL in your environment. -There are several different options: +traffic to the application servers. -- [The application node terminates SSL](#application-node-terminates-ssl). -- [The load balancer terminates SSL without backend SSL](#load-balancer-terminates-ssl-without-backend-ssl) - and communication is not secure between the load balancer and the application node. -- [The load balancer terminates SSL with backend SSL](#load-balancer-terminates-ssl-with-backend-ssl) - and communication is *secure* between the load balancer and the application node. +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 +what to configure for your load balancer of choice. ### Balancing algorithm diff --git a/doc/administration/reference_architectures/50k_users.md b/doc/administration/reference_architectures/50k_users.md index 06c2138e639426902498912d01e30836de0da9e3..92421a352739164ea379a0ba6461ce28b3a5d096 100644 --- a/doc/administration/reference_architectures/50k_users.md +++ b/doc/administration/reference_architectures/50k_users.md @@ -168,6 +168,8 @@ If this applies to you, we strongly recommended referring to the linked document Testing is done regularly via our [GitLab Performance Tool (GPT)](https://gitlab.com/gitlab-org/quality/performance) and its dataset, which is available for anyone to use. The results of this testing are [available publicly on the GPT wiki](https://gitlab.com/gitlab-org/quality/performance/-/wikis/Benchmarks/Latest). For more information on our testing strategy [refer to this section of the documentation](index.md#validation-and-test-results). +The load balancers used for testing were HAProxy for Linux package environments or equivalent Cloud Provider services via NGINX Ingress for Cloud Native Hybrids. Note that these selections do not represent a specific requirement or recommendation as most [reputable load balancers are expected to work](#configure-the-external-load-balancer). + ## Setup components To set up GitLab and its components to accommodate up to 50,000 users: @@ -243,16 +245,12 @@ 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 -traffic to the application servers. The specifics on which load balancer to use -or its exact configuration is beyond the scope of GitLab documentation. We assume -that if you're managing multi-node systems like GitLab, you already have a load -balancer of choice. Some load balancer examples include HAProxy (open-source), -F5 Big-IP LTM, and Citrix Net Scaler. This documentation outline the ports and -protocols needed for use with GitLab. - -This architecture has been tested and validated with [HAProxy](https://www.haproxy.org/) -as the load balancer. Although other load balancers with similar feature sets -could also be used, those load balancers have not been validated. +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 +what to configure for your load balancer of choice. ### Balancing algorithm diff --git a/doc/administration/reference_architectures/5k_users.md b/doc/administration/reference_architectures/5k_users.md index 67f1342a71cf815fc112b91704a37bbcc39f82e3..16a92944984c36a7248b26ae0f197ae3135ada24 100644 --- a/doc/administration/reference_architectures/5k_users.md +++ b/doc/administration/reference_architectures/5k_users.md @@ -163,6 +163,8 @@ If this applies to you, we strongly recommended referring to the linked document Testing is done regularly via our [GitLab Performance Tool (GPT)](https://gitlab.com/gitlab-org/quality/performance) and its dataset, which is available for anyone to use. The results of this testing are [available publicly on the GPT wiki](https://gitlab.com/gitlab-org/quality/performance/-/wikis/Benchmarks/Latest). For more information on our testing strategy [refer to this section of the documentation](index.md#validation-and-test-results). +The load balancers used for testing were HAProxy for Linux package environments or equivalent Cloud Provider services via NGINX Ingress for Cloud Native Hybrids. Note that these selections do not represent a specific requirement or recommendation as most [reputable load balancers are expected to work](#configure-the-external-load-balancer). + ## Setup components To set up GitLab and its components to accommodate up to 5,000 users: @@ -224,25 +226,12 @@ 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 -traffic to the application servers. The specifics on which load balancer to use -or its exact configuration is beyond the scope of GitLab documentation. We assume -that if you're managing multi-node systems like GitLab, you already have a load -balancer of choice. Some load balancer examples include HAProxy (open-source), -F5 Big-IP LTM, and Citrix Net Scaler. This documentation outline the ports and -protocols needed for use with GitLab. - -This architecture has been tested and validated with [HAProxy](https://www.haproxy.org/) -as the load balancer. Although other load balancers with similar feature sets -could also be used, those load balancers have not been validated. - -The next question is how you handle SSL in your environment. -There are several different options: +traffic to the application servers. -- [The application node terminates SSL](#application-node-terminates-ssl). -- [The load balancer terminates SSL without backend SSL](#load-balancer-terminates-ssl-without-backend-ssl) - and communication is not secure between the load balancer and the application node. -- [The load balancer terminates SSL with backend SSL](#load-balancer-terminates-ssl-with-backend-ssl) - and communication is *secure* between the load balancer and the application node. +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 +what to configure for your load balancer of choice. ### Balancing algorithm diff --git a/doc/administration/reference_architectures/index.md b/doc/administration/reference_architectures/index.md index 0df4af89fe4f38ddc70c8aa366a98698e3e1b33b..d6fdcbf7e04d08e579fe1900ce72cffdd3d05bdc 100644 --- a/doc/administration/reference_architectures/index.md +++ b/doc/administration/reference_architectures/index.md @@ -720,6 +720,7 @@ You can find a full history of changes [on the GitLab project](https://gitlab.co **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-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.