Skip to content

G
gitlab-ce
Commit 7677855b authored by Achilleas Pipinellis's avatar Achilleas Pipinellis
Browse files
Options

Merge branch 'docs-remove-notes-ra-docs' into 'master' 

Docs: Update RA docs to remove additional notes

See merge request gitlab-org/gitlab!45078
parents 4c85d1e5 e6319a46
Show whitespace changes
Inline Side-by-side
Showing with 375 additions and 469 deletions
doc/administration/reference_architectures/10k_users.md
View file @ 7677855b
...@@ -114,19 +114,18 @@ The following list includes descriptions of each server and its assigned IP: ...@@ -114,19 +114,18 @@ The following list includes descriptions of each server and its assigned IP:
## Configure the external load balancer ## Configure the external load balancer
NOTE: **Note:** In an active/active 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 hope
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/) 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 as the load balancer. Although other load balancers with similar feature sets
could also be used, those load balancers have not been validated. could also be used, those load balancers have not been validated.
In an active/active GitLab configuration, you will need a load balancer to route
traffic to the application servers. The specifics on which load balancer to use
or the exact configuration is beyond the scope of GitLab documentation. We hope
that if you're managing multi-node systems like GitLab you have a load balancer of
choice already. Some examples including HAProxy (open-source), F5 Big-IP LTM,
and Citrix Net Scaler. This documentation will outline what ports and protocols
you need to use with GitLab.
The next question is how you will handle SSL in your environment. The next question is how you will handle SSL in your environment.
There are several different options: There are several different options:
...@@ -284,10 +283,9 @@ To configure Consul: ...@@ -284,10 +283,9 @@ To configure Consul:
1. Go through the steps again for all the other Consul nodes, and 1. Go through the steps again for all the other Consul nodes, and
make sure you set up the correct IPs. make sure you set up the correct IPs.
NOTE: **Note:** A Consul leader is _elected_ when the provisioning of the third Consul server is
A Consul leader will be elected when the provisioning of the third Consul server is completed. complete. Viewing the Consul logs `sudo gitlab-ctl tail consul` displays
Viewing the Consul logs `sudo gitlab-ctl tail consul` will display `...[INFO] consul: New leader elected: ...`.
`...[INFO] consul: New leader elected: ...`
You can list the current Consul members (server, client): You can list the current Consul members (server, client):
...@@ -664,7 +662,6 @@ The following IPs will be used as an example: ...@@ -664,7 +662,6 @@ The following IPs will be used as an example:
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect. 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
NOTE: **Note:**
If an error `execute[generate databases.ini]` occurs, this is due to an existing If an error `execute[generate databases.ini]` occurs, this is due to an existing
[known issue](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/4713). [known issue](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/4713).
It will be resolved when you run a second `reconfigure` after the next step. It will be resolved when you run a second `reconfigure` after the next step.
...@@ -798,25 +795,23 @@ to be used with GitLab. The following IPs will be used as an example: ...@@ -798,25 +795,23 @@ to be used with GitLab. The following IPs will be used as an example:
- `10.6.0.82`: Sentinel - Queues 2 - `10.6.0.82`: Sentinel - Queues 2
- `10.6.0.83`: Sentinel - Queues 3 - `10.6.0.83`: Sentinel - Queues 3
NOTE: **Providing your own Redis instance:** ### Providing your own Redis instance
Managed Redis from cloud providers such as AWS ElastiCache will work. If these
services support high availability, be sure it is **not** the Redis Cluster type. Managed Redis from cloud providers (such as AWS ElastiCache) will work. If these
Redis version 5.0 or higher is required, as this is what ships with services support high availability, be sure it _isn't_ of the Redis Cluster type.
Omnibus GitLab packages starting with GitLab 13.0. Older Redis versions Redis version 5.0 or higher is required, which is included with Omnibus GitLab
do not support an optional count argument to SPOP which is now required for packages starting with GitLab 13.0. Older Redis versions don't support an
[Merge Trains](../../ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md). optional count argument to SPOP, which is required for [Merge Trains](../../ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md).
Note the Redis node's IP address or hostname, port, and password (if required). Note the Redis node's IP address or hostname, port, and password (if required).
These will be necessary when configuring the These will be necessary later when configuring the [GitLab application servers](#configure-gitlab-rails).
[GitLab application servers](#configure-gitlab-rails) later.
### Configure the Redis and Sentinel Cache cluster ### Configure the Redis and Sentinel Cache cluster
This is the section where we install and set up the new Redis Cache instances. This is the section where we install and set up the new Redis Cache instances.
NOTE: **Note:** Both the primary and replica Redis nodes need the same password defined in
Redis nodes (both primary and replica) will need the same password defined in `redis['password']`. At any time during a failover, the Sentinels can reconfigure
`redis['password']`. At any time during a failover the Sentinels can a node and change its status from primary to replica (and vice versa).
reconfigure a node and change its status from primary to replica and vice versa.
#### Configure the primary Redis Cache node #### Configure the primary Redis Cache node
...@@ -870,10 +865,9 @@ reconfigure a node and change its status from primary to replica and vice versa. ...@@ -870,10 +865,9 @@ reconfigure a node and change its status from primary to replica and vice versa.
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect. 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
NOTE: **Note:** You can specify multiple roles, like sentinel and Redis, as:
You can specify multiple roles like sentinel and Redis as: `roles ['redis_sentinel_role', 'redis_master_role']`. Read more about
`roles ['redis_sentinel_role', 'redis_master_role']`. [roles](https://docs.gitlab.com/omnibus/roles/).
Read more about [roles](https://docs.gitlab.com/omnibus/roles/).
#### Configure the replica Redis Cache nodes #### Configure the replica Redis Cache nodes
...@@ -936,10 +930,9 @@ Read more about [roles](https://docs.gitlab.com/omnibus/roles/). ...@@ -936,10 +930,9 @@ Read more about [roles](https://docs.gitlab.com/omnibus/roles/).
1. Go through the steps again for all the other replica nodes, and 1. Go through the steps again for all the other replica nodes, and
make sure to set up the IPs correctly. make sure to set up the IPs correctly.
NOTE: **Note:** You can specify multiple roles, like sentinel and Redis, as:
You can specify multiple roles like sentinel and Redis as: `roles ['redis_sentinel_role', 'redis_master_role']`. Read more about
`roles ['redis_sentinel_role', 'redis_master_role']`. [roles](https://docs.gitlab.com/omnibus/roles/).
Read more about [roles](https://docs.gitlab.com/omnibus/roles/).
These values don't have to be changed again in `/etc/gitlab/gitlab.rb` after These values don't have to be changed again in `/etc/gitlab/gitlab.rb` after
a failover, as the nodes will be managed by the [Sentinels](#configure-the-sentinel-cache-nodes), and even after a a failover, as the nodes will be managed by the [Sentinels](#configure-the-sentinel-cache-nodes), and even after a
...@@ -957,13 +950,6 @@ are supported and can be added if needed. ...@@ -957,13 +950,6 @@ are supported and can be added if needed.
#### Configure the Sentinel Cache nodes #### Configure the Sentinel Cache nodes
NOTE: **Note:**
If you are using an external Redis Sentinel instance, be sure
to exclude the `requirepass` parameter from the Sentinel
configuration. This parameter will cause clients to report `NOAUTH
Authentication required.`. [Redis Sentinel 3.2.x does not support
password authentication](https://github.com/antirez/redis/issues/3279).
Now that the Redis servers are all set up, let's configure the Sentinel Now that the Redis servers are all set up, let's configure the Sentinel
servers. The following IPs will be used as an example: servers. The following IPs will be used as an example:
...@@ -971,6 +957,12 @@ servers. The following IPs will be used as an example: ...@@ -971,6 +957,12 @@ servers. The following IPs will be used as an example:
- `10.6.0.72`: Sentinel - Cache 2 - `10.6.0.72`: Sentinel - Cache 2
- `10.6.0.73`: Sentinel - Cache 3 - `10.6.0.73`: Sentinel - Cache 3
NOTE: **Note:**
If you're using an external Redis Sentinel instance, be sure to exclude the
`requirepass` parameter from the Sentinel configuration. This parameter causes
clients to report `NOAUTH Authentication required.`.
[Redis Sentinel 3.2.x doesn't support password authentication](https://github.com/antirez/redis/issues/3279).
To configure the Sentinel Cache server: To configure the Sentinel Cache server:
1. SSH into the server that will host Consul/Sentinel. 1. SSH into the server that will host Consul/Sentinel.
...@@ -1083,10 +1075,9 @@ To configure the Sentinel Cache server: ...@@ -1083,10 +1075,9 @@ To configure the Sentinel Cache server:
This is the section where we install and set up the new Redis Queues instances. This is the section where we install and set up the new Redis Queues instances.
NOTE: **Note:** Both the primary and replica Redis nodes need the same password defined in
Redis nodes (both primary and replica) will need the same password defined in `redis['password']`. At any time during a failover, the Sentinels can reconfigure
`redis['password']`. At any time during a failover the Sentinels can a node and change its status from primary to replica (and vice versa).
reconfigure a node and change its status from primary to replica and vice versa.
#### Configure the primary Redis Queues node #### Configure the primary Redis Queues node
...@@ -1145,10 +1136,9 @@ reconfigure a node and change its status from primary to replica and vice versa. ...@@ -1145,10 +1136,9 @@ reconfigure a node and change its status from primary to replica and vice versa.
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect. 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
NOTE: **Note:** You can specify multiple roles, like sentinel and Redis, as:
You can specify multiple roles like sentinel and Redis as: `roles ['redis_sentinel_role', 'redis_master_role']`. Read more about
`roles ['redis_sentinel_role', 'redis_master_role']`. [roles](https://docs.gitlab.com/omnibus/roles/).
Read more about [roles](https://docs.gitlab.com/omnibus/roles/).
#### Configure the replica Redis Queues nodes #### Configure the replica Redis Queues nodes
...@@ -1211,10 +1201,9 @@ Read more about [roles](https://docs.gitlab.com/omnibus/roles/). ...@@ -1211,10 +1201,9 @@ Read more about [roles](https://docs.gitlab.com/omnibus/roles/).
1. Go through the steps again for all the other replica nodes, and 1. Go through the steps again for all the other replica nodes, and
make sure to set up the IPs correctly. make sure to set up the IPs correctly.
NOTE: **Note:** You can specify multiple roles, like sentinel and Redis, as:
You can specify multiple roles like sentinel and Redis as: `roles ['redis_sentinel_role', 'redis_master_role']`. Read more about
`roles ['redis_sentinel_role', 'redis_master_role']`. [roles](https://docs.gitlab.com/omnibus/roles/).
Read more about [roles](https://docs.gitlab.com/omnibus/roles/).
These values don't have to be changed again in `/etc/gitlab/gitlab.rb` after These values don't have to be changed again in `/etc/gitlab/gitlab.rb` after
a failover, as the nodes will be managed by the [Sentinels](#configure-the-sentinel-queues-nodes), and even after a a failover, as the nodes will be managed by the [Sentinels](#configure-the-sentinel-queues-nodes), and even after a
...@@ -1232,13 +1221,6 @@ are supported and can be added if needed. ...@@ -1232,13 +1221,6 @@ are supported and can be added if needed.
#### Configure the Sentinel Queues nodes #### Configure the Sentinel Queues nodes
NOTE: **Note:**
If you are using an external Redis Sentinel instance, be sure
to exclude the `requirepass` parameter from the Sentinel
configuration. This parameter will cause clients to report `NOAUTH
Authentication required.`. [Redis Sentinel 3.2.x does not support
password authentication](https://github.com/antirez/redis/issues/3279).
Now that the Redis servers are all set up, let's configure the Sentinel Now that the Redis servers are all set up, let's configure the Sentinel
servers. The following IPs will be used as an example: servers. The following IPs will be used as an example:
...@@ -1246,6 +1228,12 @@ servers. The following IPs will be used as an example: ...@@ -1246,6 +1228,12 @@ servers. The following IPs will be used as an example:
- `10.6.0.82`: Sentinel - Queues 2 - `10.6.0.82`: Sentinel - Queues 2
- `10.6.0.83`: Sentinel - Queues 3 - `10.6.0.83`: Sentinel - Queues 3
NOTE: **Note:**
If you're using an external Redis Sentinel instance, be sure to exclude the
`requirepass` parameter from the Sentinel configuration. This parameter causes
clients to report `NOAUTH Authentication required.`.
[Redis Sentinel 3.2.x doesn't support password authentication](https://github.com/antirez/redis/issues/3279).
To configure the Sentinel Queues server: To configure the Sentinel Queues server:
1. SSH into the server that will host Sentinel. 1. SSH into the server that will host Sentinel.
...@@ -1519,11 +1507,10 @@ Name. If you are addressing the Gitaly server by its IP address, you must add it ...@@ -1519,11 +1507,10 @@ Name. If you are addressing the Gitaly server by its IP address, you must add it
as a Subject Alternative Name to the certificate. as a Subject Alternative Name to the certificate.
[gRPC does not support using an IP address as Common Name in a certificate](https://github.com/grpc/grpc/issues/2691). [gRPC does not support using an IP address as Common Name in a certificate](https://github.com/grpc/grpc/issues/2691).
NOTE: **Note:** It's possible to configure Gitaly servers with both an unencrypted listening
It is possible to configure Gitaly servers with both an address (`listen_addr`) and an encrypted listening address (`tls_listen_addr`)
unencrypted listening address `listen_addr` and an encrypted listening at the same time. This allows you to do a gradual transition from unencrypted to
address `tls_listen_addr` at the same time. This allows you to do a encrypted traffic, if necessary.
gradual transition from unencrypted to encrypted traffic, if necessary.
To configure Gitaly with TLS: To configure Gitaly with TLS:
...@@ -1699,15 +1686,14 @@ You can also run [multiple Sidekiq processes](../operations/extra_sidekiq_proces ...@@ -1699,15 +1686,14 @@ You can also run [multiple Sidekiq processes](../operations/extra_sidekiq_proces
## Configure GitLab Rails ## Configure GitLab Rails
NOTE: **Note:**
In our architectures we run each GitLab Rails node using the Puma webserver
and have its number of workers set to 90% of available CPUs along with four threads. For
nodes that are running Rails with other components the worker value should be reduced
accordingly where we've found 50% achieves a good balance but this is dependent
on workload.
This section describes how to configure the GitLab application (Rails) component. This section describes how to configure the GitLab application (Rails) component.
In our architecture, we run each GitLab Rails node using the Puma webserver, and
have its number of workers set to 90% of available CPUs, with four threads. For
nodes running Rails with other components, the worker value should be reduced
accordingly. We've determined that a worker value of 50% achieves a good balance,
but this is dependent on workload.
The following IPs will be used as an example: The following IPs will be used as an example:
- `10.6.0.111`: GitLab application 1 - `10.6.0.111`: GitLab application 1
...@@ -1716,7 +1702,7 @@ The following IPs will be used as an example: ...@@ -1716,7 +1702,7 @@ The following IPs will be used as an example:
On each node perform the following: On each node perform the following:
1. Download/install Omnibus GitLab using **steps 1 and 2** from 1. Download and install Omnibus GitLab using **steps 1 and 2** from
[GitLab downloads](https://about.gitlab.com/install/). Do not complete other [GitLab downloads](https://about.gitlab.com/install/). Do not complete other
steps on the download page. steps on the download page.
...@@ -1878,12 +1864,10 @@ On each node perform the following: ...@@ -1878,12 +1864,10 @@ On each node perform the following:
sudo /opt/gitlab/embedded/bin/gitaly-hooks check /var/opt/gitlab/gitaly/config.toml sudo /opt/gitlab/embedded/bin/gitaly-hooks check /var/opt/gitlab/gitaly/config.toml
``` ```
NOTE: **Note:** When you specify `https` in the `external_url`, as in the previous example,
When you specify `https` in the `external_url`, as in the example GitLab expects that the SSL certificates are in `/etc/gitlab/ssl/`. If the
above, GitLab assumes you have SSL certificates in `/etc/gitlab/ssl/`. If certificates aren't present, NGINX will fail to start. For more information, see
certificates are not present, NGINX will fail to start. See the the [NGINX documentation](https://docs.gitlab.com/omnibus/settings/nginx.html#enable-https).
[NGINX documentation](https://docs.gitlab.com/omnibus/settings/nginx.html#enable-https)
for more information.
### GitLab Rails post-configuration ### GitLab Rails post-configuration
...@@ -1895,12 +1879,11 @@ for more information. ...@@ -1895,12 +1879,11 @@ for more information.
sudo gitlab-rake gitlab:db:configure sudo gitlab-rake gitlab:db:configure
``` ```
NOTE: **Note:** If you encounter a `rake aborted!` error message stating that PgBouncer is
If you encounter a `rake aborted!` error stating that PgBouncer is failing to connect to failing to connect to PostgreSQL, it may be that your PgBouncer node's IP
PostgreSQL it may be that your PgBouncer node's IP address is missing from address is missing from PostgreSQL's `trust_auth_cidr_addresses` in `gitlab.rb`
PostgreSQL's `trust_auth_cidr_addresses` in `gitlab.rb` on your database nodes. See on your database nodes. Before proceeding, see
[PgBouncer error `ERROR: pgbouncer cannot connect to server`](troubleshooting.md#pgbouncer-error-error-pgbouncer-cannot-connect-to-server) [PgBouncer error `ERROR: pgbouncer cannot connect to server`](troubleshooting.md#pgbouncer-error-error-pgbouncer-cannot-connect-to-server).
in the Troubleshooting section before proceeding.
1. [Configure fast lookup of authorized SSH keys in the database](../operations/fast_ssh_key_lookup.md). 1. [Configure fast lookup of authorized SSH keys in the database](../operations/fast_ssh_key_lookup.md).
...@@ -2053,16 +2036,13 @@ work. ...@@ -2053,16 +2036,13 @@ work.
## Configure Advanced Search **(STARTER ONLY)** ## Configure Advanced Search **(STARTER ONLY)**
NOTE: **Note:** You can leverage Elasticsearch and [enable Advanced Search](../../integration/elasticsearch.md)
Elasticsearch cluster design and requirements are dependent on your specific data. for faster, more advanced code search across your entire GitLab instance.
For recommended best practices on how to set up your Elasticsearch cluster
alongside your instance, read how to
[choose the optimal cluster configuration](../../integration/elasticsearch.md#guidance-on-choosing-optimal-cluster-configuration).
You can leverage Elasticsearch and enable Advanced Search for faster, more
advanced code search across your entire GitLab instance.
[Learn how to set it up.](../../integration/elasticsearch.md) Elasticsearch cluster design and requirements are dependent on your specific
data. For recommended best practices about how to set up your Elasticsearch
cluster alongside your instance, read how to
[choose the optimal cluster configuration](../../integration/elasticsearch.md#guidance-on-choosing-optimal-cluster-configuration).
<div align="right"> <div align="right">
<a type="button" class="btn btn-default" href="#setup-components"> <a type="button" class="btn btn-default" href="#setup-components">
......
doc/administration/reference_architectures/25k_users.md
View file @ 7677855b
...@@ -114,19 +114,18 @@ The following list includes descriptions of each server and its assigned IP: ...@@ -114,19 +114,18 @@ The following list includes descriptions of each server and its assigned IP:
## Configure the external load balancer ## Configure the external load balancer
NOTE: **Note:** In an active/active 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 hope
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/) 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 as the load balancer. Although other load balancers with similar feature sets
could also be used, those load balancers have not been validated. could also be used, those load balancers have not been validated.
In an active/active GitLab configuration, you will need a load balancer to route
traffic to the application servers. The specifics on which load balancer to use
or the exact configuration is beyond the scope of GitLab documentation. We hope
that if you're managing multi-node systems like GitLab you have a load balancer of
choice already. Some examples including HAProxy (open-source), F5 Big-IP LTM,
and Citrix Net Scaler. This documentation will outline what ports and protocols
you need to use with GitLab.
The next question is how you will handle SSL in your environment. The next question is how you will handle SSL in your environment.
There are several different options: There are several different options:
...@@ -284,10 +283,9 @@ To configure Consul: ...@@ -284,10 +283,9 @@ To configure Consul:
1. Go through the steps again for all the other Consul nodes, and 1. Go through the steps again for all the other Consul nodes, and
make sure you set up the correct IPs. make sure you set up the correct IPs.
NOTE: **Note:** A Consul leader is _elected_ when the provisioning of the third Consul server is
A Consul leader will be elected when the provisioning of the third Consul server is completed. complete. Viewing the Consul logs `sudo gitlab-ctl tail consul` displays
Viewing the Consul logs `sudo gitlab-ctl tail consul` will display `...[INFO] consul: New leader elected: ...`.
`...[INFO] consul: New leader elected: ...`
You can list the current Consul members (server, client): You can list the current Consul members (server, client):
...@@ -664,7 +662,6 @@ The following IPs will be used as an example: ...@@ -664,7 +662,6 @@ The following IPs will be used as an example:
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect. 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
NOTE: **Note:**
If an error `execute[generate databases.ini]` occurs, this is due to an existing If an error `execute[generate databases.ini]` occurs, this is due to an existing
[known issue](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/4713). [known issue](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/4713).
It will be resolved when you run a second `reconfigure` after the next step. It will be resolved when you run a second `reconfigure` after the next step.
...@@ -798,25 +795,23 @@ to be used with GitLab. The following IPs will be used as an example: ...@@ -798,25 +795,23 @@ to be used with GitLab. The following IPs will be used as an example:
- `10.6.0.82`: Sentinel - Queues 2 - `10.6.0.82`: Sentinel - Queues 2
- `10.6.0.83`: Sentinel - Queues 3 - `10.6.0.83`: Sentinel - Queues 3
NOTE: **Providing your own Redis instance:** ### Providing your own Redis instance
Managed Redis from cloud providers such as AWS ElastiCache will work. If these
services support high availability, be sure it is **not** the Redis Cluster type. Managed Redis from cloud providers (such as AWS ElastiCache) will work. If these
Redis version 5.0 or higher is required, as this is what ships with services support high availability, be sure it _isn't_ of the Redis Cluster type.
Omnibus GitLab packages starting with GitLab 13.0. Older Redis versions Redis version 5.0 or higher is required, which is included with Omnibus GitLab
do not support an optional count argument to SPOP which is now required for packages starting with GitLab 13.0. Older Redis versions don't support an
[Merge Trains](../../ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md). optional count argument to SPOP, which is required for [Merge Trains](../../ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md).
Note the Redis node's IP address or hostname, port, and password (if required). Note the Redis node's IP address or hostname, port, and password (if required).
These will be necessary when configuring the These will be necessary later when configuring the [GitLab application servers](#configure-gitlab-rails).
[GitLab application servers](#configure-gitlab-rails) later.
### Configure the Redis and Sentinel Cache cluster ### Configure the Redis and Sentinel Cache cluster
This is the section where we install and set up the new Redis Cache instances. This is the section where we install and set up the new Redis Cache instances.
NOTE: **Note:** Both the primary and replica Redis nodes need the same password defined in
Redis nodes (both primary and replica) will need the same password defined in `redis['password']`. At any time during a failover, the Sentinels can reconfigure
`redis['password']`. At any time during a failover the Sentinels can a node and change its status from primary to replica (and vice versa).
reconfigure a node and change its status from primary to replica and vice versa.
#### Configure the primary Redis Cache node #### Configure the primary Redis Cache node
...@@ -870,10 +865,9 @@ reconfigure a node and change its status from primary to replica and vice versa. ...@@ -870,10 +865,9 @@ reconfigure a node and change its status from primary to replica and vice versa.
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect. 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
NOTE: **Note:** You can specify multiple roles, like sentinel and Redis, as:
You can specify multiple roles like sentinel and Redis as: `roles ['redis_sentinel_role', 'redis_master_role']`. Read more about
`roles ['redis_sentinel_role', 'redis_master_role']`. [roles](https://docs.gitlab.com/omnibus/roles/).
Read more about [roles](https://docs.gitlab.com/omnibus/roles/).
#### Configure the replica Redis Cache nodes #### Configure the replica Redis Cache nodes
...@@ -936,10 +930,9 @@ Read more about [roles](https://docs.gitlab.com/omnibus/roles/). ...@@ -936,10 +930,9 @@ Read more about [roles](https://docs.gitlab.com/omnibus/roles/).
1. Go through the steps again for all the other replica nodes, and 1. Go through the steps again for all the other replica nodes, and
make sure to set up the IPs correctly. make sure to set up the IPs correctly.
NOTE: **Note:** You can specify multiple roles, like sentinel and Redis, as:
You can specify multiple roles like sentinel and Redis as: `roles ['redis_sentinel_role', 'redis_master_role']`. Read more about
`roles ['redis_sentinel_role', 'redis_master_role']`. [roles](https://docs.gitlab.com/omnibus/roles/).
Read more about [roles](https://docs.gitlab.com/omnibus/roles/).
These values don't have to be changed again in `/etc/gitlab/gitlab.rb` after These values don't have to be changed again in `/etc/gitlab/gitlab.rb` after
a failover, as the nodes will be managed by the [Sentinels](#configure-the-sentinel-cache-nodes), and even after a a failover, as the nodes will be managed by the [Sentinels](#configure-the-sentinel-cache-nodes), and even after a
...@@ -957,13 +950,6 @@ are supported and can be added if needed. ...@@ -957,13 +950,6 @@ are supported and can be added if needed.
#### Configure the Sentinel Cache nodes #### Configure the Sentinel Cache nodes
NOTE: **Note:**
If you are using an external Redis Sentinel instance, be sure
to exclude the `requirepass` parameter from the Sentinel
configuration. This parameter will cause clients to report `NOAUTH
Authentication required.`. [Redis Sentinel 3.2.x does not support
password authentication](https://github.com/antirez/redis/issues/3279).
Now that the Redis servers are all set up, let's configure the Sentinel Now that the Redis servers are all set up, let's configure the Sentinel
servers. The following IPs will be used as an example: servers. The following IPs will be used as an example:
...@@ -971,6 +957,12 @@ servers. The following IPs will be used as an example: ...@@ -971,6 +957,12 @@ servers. The following IPs will be used as an example:
- `10.6.0.72`: Sentinel - Cache 2 - `10.6.0.72`: Sentinel - Cache 2
- `10.6.0.73`: Sentinel - Cache 3 - `10.6.0.73`: Sentinel - Cache 3
NOTE: **Note:**
If you're using an external Redis Sentinel instance, be sure to exclude the
`requirepass` parameter from the Sentinel configuration. This parameter causes
clients to report `NOAUTH Authentication required.`.
[Redis Sentinel 3.2.x doesn't support password authentication](https://github.com/antirez/redis/issues/3279).
To configure the Sentinel Cache server: To configure the Sentinel Cache server:
1. SSH into the server that will host Consul/Sentinel. 1. SSH into the server that will host Consul/Sentinel.
...@@ -1083,10 +1075,9 @@ To configure the Sentinel Cache server: ...@@ -1083,10 +1075,9 @@ To configure the Sentinel Cache server:
This is the section where we install and set up the new Redis Queues instances. This is the section where we install and set up the new Redis Queues instances.
NOTE: **Note:** Both the primary and replica Redis nodes need the same password defined in
Redis nodes (both primary and replica) will need the same password defined in `redis['password']`. At any time during a failover, the Sentinels can reconfigure
`redis['password']`. At any time during a failover the Sentinels can a node and change its status from primary to replica (and vice versa).
reconfigure a node and change its status from primary to replica and vice versa.
#### Configure the primary Redis Queues node #### Configure the primary Redis Queues node
...@@ -1145,10 +1136,9 @@ reconfigure a node and change its status from primary to replica and vice versa. ...@@ -1145,10 +1136,9 @@ reconfigure a node and change its status from primary to replica and vice versa.
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect. 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
NOTE: **Note:** You can specify multiple roles, like sentinel and Redis, as:
You can specify multiple roles like sentinel and Redis as: `roles ['redis_sentinel_role', 'redis_master_role']`. Read more about
`roles ['redis_sentinel_role', 'redis_master_role']`. [roles](https://docs.gitlab.com/omnibus/roles/).
Read more about [roles](https://docs.gitlab.com/omnibus/roles/).
#### Configure the replica Redis Queues nodes #### Configure the replica Redis Queues nodes
...@@ -1211,10 +1201,9 @@ Read more about [roles](https://docs.gitlab.com/omnibus/roles/). ...@@ -1211,10 +1201,9 @@ Read more about [roles](https://docs.gitlab.com/omnibus/roles/).
1. Go through the steps again for all the other replica nodes, and 1. Go through the steps again for all the other replica nodes, and
make sure to set up the IPs correctly. make sure to set up the IPs correctly.
NOTE: **Note:** You can specify multiple roles, like sentinel and Redis, as:
You can specify multiple roles like sentinel and Redis as: `roles ['redis_sentinel_role', 'redis_master_role']`. Read more about
`roles ['redis_sentinel_role', 'redis_master_role']`. [roles](https://docs.gitlab.com/omnibus/roles/).
Read more about [roles](https://docs.gitlab.com/omnibus/roles/).
These values don't have to be changed again in `/etc/gitlab/gitlab.rb` after These values don't have to be changed again in `/etc/gitlab/gitlab.rb` after
a failover, as the nodes will be managed by the [Sentinels](#configure-the-sentinel-queues-nodes), and even after a a failover, as the nodes will be managed by the [Sentinels](#configure-the-sentinel-queues-nodes), and even after a
...@@ -1232,13 +1221,6 @@ are supported and can be added if needed. ...@@ -1232,13 +1221,6 @@ are supported and can be added if needed.
#### Configure the Sentinel Queues nodes #### Configure the Sentinel Queues nodes
NOTE: **Note:**
If you are using an external Redis Sentinel instance, be sure
to exclude the `requirepass` parameter from the Sentinel
configuration. This parameter will cause clients to report `NOAUTH
Authentication required.`. [Redis Sentinel 3.2.x does not support
password authentication](https://github.com/antirez/redis/issues/3279).
Now that the Redis servers are all set up, let's configure the Sentinel Now that the Redis servers are all set up, let's configure the Sentinel
servers. The following IPs will be used as an example: servers. The following IPs will be used as an example:
...@@ -1246,6 +1228,12 @@ servers. The following IPs will be used as an example: ...@@ -1246,6 +1228,12 @@ servers. The following IPs will be used as an example:
- `10.6.0.82`: Sentinel - Queues 2 - `10.6.0.82`: Sentinel - Queues 2
- `10.6.0.83`: Sentinel - Queues 3 - `10.6.0.83`: Sentinel - Queues 3
NOTE: **Note:**
If you're using an external Redis Sentinel instance, be sure to exclude the
`requirepass` parameter from the Sentinel configuration. This parameter causes
clients to report `NOAUTH Authentication required.`.
[Redis Sentinel 3.2.x doesn't support password authentication](https://github.com/antirez/redis/issues/3279).
To configure the Sentinel Queues server: To configure the Sentinel Queues server:
1. SSH into the server that will host Sentinel. 1. SSH into the server that will host Sentinel.
...@@ -1519,11 +1507,10 @@ Name. If you are addressing the Gitaly server by its IP address, you must add it ...@@ -1519,11 +1507,10 @@ Name. If you are addressing the Gitaly server by its IP address, you must add it
as a Subject Alternative Name to the certificate. as a Subject Alternative Name to the certificate.
[gRPC does not support using an IP address as Common Name in a certificate](https://github.com/grpc/grpc/issues/2691). [gRPC does not support using an IP address as Common Name in a certificate](https://github.com/grpc/grpc/issues/2691).
NOTE: **Note:** It's possible to configure Gitaly servers with both an unencrypted listening
It is possible to configure Gitaly servers with both an address (`listen_addr`) and an encrypted listening address (`tls_listen_addr`)
unencrypted listening address `listen_addr` and an encrypted listening at the same time. This allows you to do a gradual transition from unencrypted to
address `tls_listen_addr` at the same time. This allows you to do a encrypted traffic, if necessary.
gradual transition from unencrypted to encrypted traffic, if necessary.
To configure Gitaly with TLS: To configure Gitaly with TLS:
...@@ -1699,15 +1686,14 @@ You can also run [multiple Sidekiq processes](../operations/extra_sidekiq_proces ...@@ -1699,15 +1686,14 @@ You can also run [multiple Sidekiq processes](../operations/extra_sidekiq_proces
## Configure GitLab Rails ## Configure GitLab Rails
NOTE: **Note:**
In our architectures we run each GitLab Rails node using the Puma webserver
and have its number of workers set to 90% of available CPUs along with four threads. For
nodes that are running Rails with other components the worker value should be reduced
accordingly where we've found 50% achieves a good balance but this is dependent
on workload.
This section describes how to configure the GitLab application (Rails) component. This section describes how to configure the GitLab application (Rails) component.
In our architecture, we run each GitLab Rails node using the Puma webserver, and
have its number of workers set to 90% of available CPUs, with four threads. For
nodes running Rails with other components, the worker value should be reduced
accordingly. We've determined that a worker value of 50% achieves a good balance,
but this is dependent on workload.
The following IPs will be used as an example: The following IPs will be used as an example:
- `10.6.0.111`: GitLab application 1 - `10.6.0.111`: GitLab application 1
...@@ -1716,7 +1702,7 @@ The following IPs will be used as an example: ...@@ -1716,7 +1702,7 @@ The following IPs will be used as an example:
On each node perform the following: On each node perform the following:
1. Download/install Omnibus GitLab using **steps 1 and 2** from 1. Download and install Omnibus GitLab using **steps 1 and 2** from
[GitLab downloads](https://about.gitlab.com/install/). Do not complete other [GitLab downloads](https://about.gitlab.com/install/). Do not complete other
steps on the download page. steps on the download page.
...@@ -1878,12 +1864,10 @@ On each node perform the following: ...@@ -1878,12 +1864,10 @@ On each node perform the following:
sudo /opt/gitlab/embedded/bin/gitaly-hooks check /var/opt/gitlab/gitaly/config.toml sudo /opt/gitlab/embedded/bin/gitaly-hooks check /var/opt/gitlab/gitaly/config.toml
``` ```
NOTE: **Note:** When you specify `https` in the `external_url`, as in the previous example,
When you specify `https` in the `external_url`, as in the example GitLab expects that the SSL certificates are in `/etc/gitlab/ssl/`. If the
above, GitLab assumes you have SSL certificates in `/etc/gitlab/ssl/`. If certificates aren't present, NGINX will fail to start. For more information, see
certificates are not present, NGINX will fail to start. See the the [NGINX documentation](https://docs.gitlab.com/omnibus/settings/nginx.html#enable-https).
[NGINX documentation](https://docs.gitlab.com/omnibus/settings/nginx.html#enable-https)
for more information.
### GitLab Rails post-configuration ### GitLab Rails post-configuration
...@@ -1895,12 +1879,11 @@ for more information. ...@@ -1895,12 +1879,11 @@ for more information.
sudo gitlab-rake gitlab:db:configure sudo gitlab-rake gitlab:db:configure
``` ```
NOTE: **Note:** If you encounter a `rake aborted!` error message stating that PgBouncer is
If you encounter a `rake aborted!` error stating that PgBouncer is failing to connect to failing to connect to PostgreSQL, it may be that your PgBouncer node's IP
PostgreSQL it may be that your PgBouncer node's IP address is missing from address is missing from PostgreSQL's `trust_auth_cidr_addresses` in `gitlab.rb`
PostgreSQL's `trust_auth_cidr_addresses` in `gitlab.rb` on your database nodes. See on your database nodes. Before proceeding, see
[PgBouncer error `ERROR: pgbouncer cannot connect to server`](troubleshooting.md#pgbouncer-error-error-pgbouncer-cannot-connect-to-server) [PgBouncer error `ERROR: pgbouncer cannot connect to server`](troubleshooting.md#pgbouncer-error-error-pgbouncer-cannot-connect-to-server).
in the Troubleshooting section before proceeding.
1. [Configure fast lookup of authorized SSH keys in the database](../operations/fast_ssh_key_lookup.md). 1. [Configure fast lookup of authorized SSH keys in the database](../operations/fast_ssh_key_lookup.md).
...@@ -2053,16 +2036,13 @@ work. ...@@ -2053,16 +2036,13 @@ work.
## Configure Advanced Search **(STARTER ONLY)** ## Configure Advanced Search **(STARTER ONLY)**
NOTE: **Note:** You can leverage Elasticsearch and [enable Advanced Search](../../integration/elasticsearch.md)
Elasticsearch cluster design and requirements are dependent on your specific data. for faster, more advanced code search across your entire GitLab instance.
For recommended best practices on how to set up your Elasticsearch cluster
alongside your instance, read how to
[choose the optimal cluster configuration](../../integration/elasticsearch.md#guidance-on-choosing-optimal-cluster-configuration).
You can leverage Elasticsearch and enable Advanced Search for faster, more
advanced code search across your entire GitLab instance.
[Learn how to set it up.](../../integration/elasticsearch.md) Elasticsearch cluster design and requirements are dependent on your specific
data. For recommended best practices about how to set up your Elasticsearch
cluster alongside your instance, read how to
[choose the optimal cluster configuration](../../integration/elasticsearch.md#guidance-on-choosing-optimal-cluster-configuration).
<div align="right"> <div align="right">
<a type="button" class="btn btn-default" href="#setup-components"> <a type="button" class="btn btn-default" href="#setup-components">
......
doc/administration/reference_architectures/2k_users.md
View file @ 7677855b
...@@ -64,18 +64,17 @@ To set up GitLab and its components to accommodate up to 2,000 users: ...@@ -64,18 +64,17 @@ To set up GitLab and its components to accommodate up to 2,000 users:
## Configure the external load balancer ## Configure the external load balancer
NOTE: **Note:**
This architecture has been tested and validated with [HAProxy](https://www.haproxy.org/).
Although you can use a load balancer with a similar set of features, GitLab
hasn't validated other load balancers.
In an active/active GitLab configuration, you'll need a load balancer to route In an active/active GitLab configuration, you'll need a load balancer to route
traffic to the application servers. The specifics for which load balancer to traffic to the application servers. The specifics on which load balancer to use
use or its exact configuration is out of scope for the GitLab documentation. or its exact configuration is beyond the scope of GitLab documentation. We hope
If you're managing multi-node systems (including GitLab) you'll probably that if you're managing multi-node systems like GitLab, you already have a load
already have a load balancer of choice. Some examples including HAProxy balancer of choice. Some load balancer examples include HAProxy (open-source),
(open-source), F5 Big-IP LTM, and Citrix Net Scaler. This documentation F5 Big-IP LTM, and Citrix Net Scaler. This documentation outline the ports and
includes the ports and protocols for use with GitLab. 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 The next question is how you will handle SSL in your environment. There are
several different options: several different options:
...@@ -489,11 +488,10 @@ Name. If you are addressing the Gitaly server by its IP address, you must add it ...@@ -489,11 +488,10 @@ Name. If you are addressing the Gitaly server by its IP address, you must add it
as a Subject Alternative Name to the certificate. as a Subject Alternative Name to the certificate.
[gRPC does not support using an IP address as Common Name in a certificate](https://github.com/grpc/grpc/issues/2691). [gRPC does not support using an IP address as Common Name in a certificate](https://github.com/grpc/grpc/issues/2691).
NOTE: **Note:** It's possible to configure Gitaly servers with both an unencrypted listening
It is possible to configure Gitaly servers with both an address (`listen_addr`) and an encrypted listening address (`tls_listen_addr`)
unencrypted listening address `listen_addr` and an encrypted listening at the same time. This allows you to do a gradual transition from unencrypted to
address `tls_listen_addr` at the same time. This allows you to do a encrypted traffic, if necessary.
gradual transition from unencrypted to encrypted traffic, if necessary.
To configure Gitaly with TLS: To configure Gitaly with TLS:
...@@ -537,14 +535,14 @@ To configure Gitaly with TLS: ...@@ -537,14 +535,14 @@ To configure Gitaly with TLS:
## Configure GitLab Rails ## Configure GitLab Rails
NOTE: **Note:**
In our architectures we run each GitLab Rails node using the Puma webserver
and have its number of workers set to 90% of available CPUs along with four threads. For
nodes that are running Rails with other components the worker value should be reduced
accordingly where we've found 50% achieves a good balance but this is dependent
on workload.
This section describes how to configure the GitLab application (Rails) component. This section describes how to configure the GitLab application (Rails) component.
In our architecture, we run each GitLab Rails node using the Puma webserver, and
have its number of workers set to 90% of available CPUs, with four threads. For
nodes running Rails with other components, the worker value should be reduced
accordingly. We've determined that a worker value of 50% achieves a good balance,
but this is dependent on workload.
On each node perform the following: On each node perform the following:
1. If you're [using NFS](#configure-nfs-optional): 1. If you're [using NFS](#configure-nfs-optional):
...@@ -572,10 +570,10 @@ On each node perform the following: ...@@ -572,10 +570,10 @@ On each node perform the following:
mkdir -p /var/opt/gitlab/.ssh /var/opt/gitlab/gitlab-rails/uploads /var/opt/gitlab/gitlab-rails/shared /var/opt/gitlab/gitlab-ci/builds /var/opt/gitlab/git-data mkdir -p /var/opt/gitlab/.ssh /var/opt/gitlab/gitlab-rails/uploads /var/opt/gitlab/gitlab-rails/shared /var/opt/gitlab/gitlab-ci/builds /var/opt/gitlab/git-data
``` ```
1. Download/install Omnibus GitLab using **steps 1 and 2** from 1. Download and install Omnibus GitLab using **steps 1 and 2** from
[GitLab downloads](https://about.gitlab.com/install/). Do not complete other [GitLab downloads](https://about.gitlab.com/install/). Do not complete other
steps on the download page. steps on the download page.
1. Create/edit `/etc/gitlab/gitlab.rb` and use the following configuration. 1. Create or edit `/etc/gitlab/gitlab.rb` and use the following configuration.
To maintain uniformity of links across nodes, the `external_url` To maintain uniformity of links across nodes, the `external_url`
on the application server should point to the external URL that users will use on the application server should point to the external URL that users will use
to access GitLab. This would be the URL of the [load balancer](#configure-the-external-load-balancer) to access GitLab. This would be the URL of the [load balancer](#configure-the-external-load-balancer)
...@@ -671,12 +669,10 @@ On each node perform the following: ...@@ -671,12 +669,10 @@ On each node perform the following:
[Gitaly node](#configure-gitaly) and [Gitaly node](#configure-gitaly) and
[reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure). [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
NOTE: **Note:** When you specify `https` in the `external_url`, as in the previous example,
When you specify `https` in the `external_url`, as in the example GitLab expects that the SSL certificates are in `/etc/gitlab/ssl/`. If the
above, GitLab assumes you have SSL certificates in `/etc/gitlab/ssl/`. If certificates aren't present, NGINX will fail to start. For more information, see
certificates are not present, NGINX will fail to start. See the the [NGINX documentation](https://docs.gitlab.com/omnibus/settings/nginx.html#enable-https).
[NGINX documentation](https://docs.gitlab.com/omnibus/settings/nginx.html#enable-https)
for more information.
### GitLab Rails post-configuration ### GitLab Rails post-configuration
...@@ -688,12 +684,11 @@ for more information. ...@@ -688,12 +684,11 @@ for more information.
sudo gitlab-rake gitlab:db:configure sudo gitlab-rake gitlab:db:configure
``` ```
NOTE: **Note:** If you encounter a `rake aborted!` error message stating that PgBouncer is
If you encounter a `rake aborted!` error stating that PgBouncer is failing to connect to failing to connect to PostgreSQL, it may be that your PgBouncer node's IP
PostgreSQL it may be that your PgBouncer node's IP address is missing from address is missing from PostgreSQL's `trust_auth_cidr_addresses` in `gitlab.rb`
PostgreSQL's `trust_auth_cidr_addresses` in `gitlab.rb` on your database nodes. See on your database nodes. Before proceeding, see
[PgBouncer error `ERROR: pgbouncer cannot connect to server`](troubleshooting.md#pgbouncer-error-error-pgbouncer-cannot-connect-to-server) [PgBouncer error `ERROR: pgbouncer cannot connect to server`](troubleshooting.md#pgbouncer-error-error-pgbouncer-cannot-connect-to-server).
in the Troubleshooting section before proceeding.
1. [Configure fast lookup of authorized SSH keys in the database](../operations/fast_ssh_key_lookup.md). 1. [Configure fast lookup of authorized SSH keys in the database](../operations/fast_ssh_key_lookup.md).
...@@ -893,16 +888,13 @@ functioning backups is encountered. ...@@ -893,16 +888,13 @@ functioning backups is encountered.
## Configure Advanced Search **(STARTER ONLY)** ## Configure Advanced Search **(STARTER ONLY)**
NOTE: **Note:** You can leverage Elasticsearch and [enable Advanced Search](../../integration/elasticsearch.md)
Elasticsearch cluster design and requirements are dependent on your specific data. for faster, more advanced code search across your entire GitLab instance.
For recommended best practices on how to set up your Elasticsearch cluster
alongside your instance, read how to
[choose the optimal cluster configuration](../../integration/elasticsearch.md#guidance-on-choosing-optimal-cluster-configuration).
You can leverage Elasticsearch and enable Advanced Search for faster, more
advanced code search across your entire GitLab instance.
[Learn how to set it up.](../../integration/elasticsearch.md) Elasticsearch cluster design and requirements are dependent on your specific
data. For recommended best practices about how to set up your Elasticsearch
cluster alongside your instance, read how to
[choose the optimal cluster configuration](../../integration/elasticsearch.md#guidance-on-choosing-optimal-cluster-configuration).
<div align="right"> <div align="right">
<a type="button" class="btn btn-default" href="#setup-components"> <a type="button" class="btn btn-default" href="#setup-components">
......
doc/administration/reference_architectures/3k_users.md
View file @ 7677855b
...@@ -109,19 +109,18 @@ The following list includes descriptions of each server and its assigned IP: ...@@ -109,19 +109,18 @@ The following list includes descriptions of each server and its assigned IP:
## Configure the external load balancer ## Configure the external load balancer
NOTE: **Note:** In an active/active 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 hope
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/) 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 as the load balancer. Although other load balancers with similar feature sets
could also be used, those load balancers have not been validated. could also be used, those load balancers have not been validated.
In an active/active GitLab configuration, you will need a load balancer to route
traffic to the application servers. The specifics on which load balancer to use
or the exact configuration is beyond the scope of GitLab documentation. We hope
that if you're managing multi-node systems like GitLab you have a load balancer of
choice already. Some examples including HAProxy (open-source), F5 Big-IP LTM,
and Citrix Net Scaler. This documentation will outline what ports and protocols
you need to use with GitLab.
The next question is how you will handle SSL in your environment. The next question is how you will handle SSL in your environment.
There are several different options: There are several different options:
...@@ -279,14 +278,13 @@ The requirements for a Redis setup are the following: ...@@ -279,14 +278,13 @@ The requirements for a Redis setup are the following:
([Internet](https://gitlab.com/gitlab-org/gitlab-foss/uploads/c4cc8cd353604bd80315f9384035ff9e/The_Internet_IT_Crowd.png)), ([Internet](https://gitlab.com/gitlab-org/gitlab-foss/uploads/c4cc8cd353604bd80315f9384035ff9e/The_Internet_IT_Crowd.png)),
using a firewall. using a firewall.
NOTE: **Note:** Both the primary and replica Redis nodes need the same password defined in
Redis nodes (both primary and replica) will need the same password defined in `redis['password']`. At any time during a failover, the Sentinels can reconfigure
`redis['password']`. At any time during a failover the Sentinels can a node and change its status from primary to replica (and vice versa).
reconfigure a node and change its status from primary to replica and vice versa.
#### Configuring the primary Redis instance #### Configuring the primary Redis instance
1. SSH into the **Primary** Redis server. 1. SSH in to the **Primary** Redis server.
1. [Download/install](https://about.gitlab.com/install/) the Omnibus GitLab 1. [Download/install](https://about.gitlab.com/install/) the Omnibus GitLab
package you want using **steps 1 and 2** from the GitLab downloads page. package you want using **steps 1 and 2** from the GitLab downloads page.
- Make sure you select the correct Omnibus package, with the same version - Make sure you select the correct Omnibus package, with the same version
...@@ -336,18 +334,17 @@ reconfigure a node and change its status from primary to replica and vice versa. ...@@ -336,18 +334,17 @@ reconfigure a node and change its status from primary to replica and vice versa.
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect. 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
NOTE: **Note:** You can specify multiple roles, like sentinel and Redis, as:
You can specify multiple roles like sentinel and Redis as: `roles ['redis_sentinel_role', 'redis_master_role']`. Read more about
`roles ['redis_sentinel_role', 'redis_master_role']`. [roles](https://docs.gitlab.com/omnibus/roles/).
Read more about [roles](https://docs.gitlab.com/omnibus/roles/).
You can list the current Redis Primary, Replica status via: You can list the current Redis Primary, Replica status by using:
```shell ```shell
/opt/gitlab/embedded/bin/redis-cli -h <host> -a 'redis-password-goes-here' info replication /opt/gitlab/embedded/bin/redis-cli -h <host> -a 'redis-password-goes-here' info replication
``` ```
Show running GitLab services via: Show running GitLab services by using:
```shell ```shell
gitlab-ctl status gitlab-ctl status
...@@ -365,7 +362,7 @@ run: redis-exporter: (pid 30075) 76861s; run: log: (pid 29674) 76896s ...@@ -365,7 +362,7 @@ run: redis-exporter: (pid 30075) 76861s; run: log: (pid 29674) 76896s
#### Configuring the replica Redis instances #### Configuring the replica Redis instances
1. SSH into the **replica** Redis server. 1. SSH in to the **replica** Redis server.
1. [Download/install](https://about.gitlab.com/install/) the Omnibus GitLab 1. [Download/install](https://about.gitlab.com/install/) the Omnibus GitLab
package you want using **steps 1 and 2** from the GitLab downloads page. package you want using **steps 1 and 2** from the GitLab downloads page.
- Make sure you select the correct Omnibus package, with the same version - Make sure you select the correct Omnibus package, with the same version
...@@ -424,10 +421,9 @@ run: redis-exporter: (pid 30075) 76861s; run: log: (pid 29674) 76896s ...@@ -424,10 +421,9 @@ run: redis-exporter: (pid 30075) 76861s; run: log: (pid 29674) 76896s
1. Go through the steps again for all the other replica nodes, and 1. Go through the steps again for all the other replica nodes, and
make sure to set up the IPs correctly. make sure to set up the IPs correctly.
NOTE: **Note:** You can specify multiple roles, like sentinel and Redis, as:
You can specify multiple roles like sentinel and Redis as: `roles ['redis_sentinel_role', 'redis_master_role']`. Read more about
`roles ['redis_sentinel_role', 'redis_master_role']`. [roles](https://docs.gitlab.com/omnibus/roles/).
Read more about [roles](https://docs.gitlab.com/omnibus/roles/).
These values don't have to be changed again in `/etc/gitlab/gitlab.rb` after These values don't have to be changed again in `/etc/gitlab/gitlab.rb` after
a failover, as the nodes will be managed by the [Sentinels](#configure-consul-and-sentinel), and even after a a failover, as the nodes will be managed by the [Sentinels](#configure-consul-and-sentinel), and even after a
...@@ -445,13 +441,6 @@ are supported and can be added if needed. ...@@ -445,13 +441,6 @@ are supported and can be added if needed.
## Configure Consul and Sentinel ## Configure Consul and Sentinel
NOTE: **Note:**
If you are using an external Redis Sentinel instance, be sure
to exclude the `requirepass` parameter from the Sentinel
configuration. This parameter will cause clients to report `NOAUTH
Authentication required.`. [Redis Sentinel 3.2.x does not support
password authentication](https://github.com/antirez/redis/issues/3279).
Now that the Redis servers are all set up, let's configure the Sentinel Now that the Redis servers are all set up, let's configure the Sentinel
servers. The following IPs will be used as an example: servers. The following IPs will be used as an example:
...@@ -459,6 +448,12 @@ servers. The following IPs will be used as an example: ...@@ -459,6 +448,12 @@ servers. The following IPs will be used as an example:
- `10.6.0.12`: Consul/Sentinel 2 - `10.6.0.12`: Consul/Sentinel 2
- `10.6.0.13`: Consul/Sentinel 3 - `10.6.0.13`: Consul/Sentinel 3
NOTE: **Note:**
If you're using an external Redis Sentinel instance, be sure to exclude the
`requirepass` parameter from the Sentinel configuration. This parameter causes
clients to report `NOAUTH Authentication required.`.
[Redis Sentinel 3.2.x doesn't support password authentication](https://github.com/antirez/redis/issues/3279).
To configure the Sentinel: To configure the Sentinel:
1. SSH into the server that will host Consul/Sentinel. 1. SSH into the server that will host Consul/Sentinel.
...@@ -558,10 +553,9 @@ To configure the Sentinel: ...@@ -558,10 +553,9 @@ To configure the Sentinel:
1. Go through the steps again for all the other Consul/Sentinel nodes, and 1. Go through the steps again for all the other Consul/Sentinel nodes, and
make sure you set up the correct IPs. make sure you set up the correct IPs.
NOTE: **Note:** A Consul leader is _elected_ when the provisioning of the third Consul server is
A Consul leader will be elected when the provisioning of the third Consul server is completed. complete. Viewing the Consul logs `sudo gitlab-ctl tail consul` displays
Viewing the Consul logs `sudo gitlab-ctl tail consul` will display `...[INFO] consul: New leader elected: ...`.
`...[INFO] consul: New leader elected: ...`
You can list the current Consul members (server, client): You can list the current Consul members (server, client):
...@@ -1258,11 +1252,10 @@ Name. If you are addressing the Gitaly server by its IP address, you must add it ...@@ -1258,11 +1252,10 @@ Name. If you are addressing the Gitaly server by its IP address, you must add it
as a Subject Alternative Name to the certificate. as a Subject Alternative Name to the certificate.
[gRPC does not support using an IP address as Common Name in a certificate](https://github.com/grpc/grpc/issues/2691). [gRPC does not support using an IP address as Common Name in a certificate](https://github.com/grpc/grpc/issues/2691).
NOTE: **Note:** It's possible to configure Gitaly servers with both an unencrypted listening
It is possible to configure Gitaly servers with both an address (`listen_addr`) and an encrypted listening address (`tls_listen_addr`)
unencrypted listening address `listen_addr` and an encrypted listening at the same time. This allows you to do a gradual transition from unencrypted to
address `tls_listen_addr` at the same time. This allows you to do a encrypted traffic, if necessary.
gradual transition from unencrypted to encrypted traffic, if necessary.
To configure Gitaly with TLS: To configure Gitaly with TLS:
...@@ -1430,14 +1423,14 @@ You can also run [multiple Sidekiq processes](../operations/extra_sidekiq_proces ...@@ -1430,14 +1423,14 @@ You can also run [multiple Sidekiq processes](../operations/extra_sidekiq_proces
## Configure GitLab Rails ## Configure GitLab Rails
NOTE: **Note:**
In our architectures we run each GitLab Rails node using the Puma webserver
and have its number of workers set to 90% of available CPUs along with four threads. For
nodes that are running Rails with other components the worker value should be reduced
accordingly where we've found 50% achieves a good balance but this is dependent
on workload.
This section describes how to configure the GitLab application (Rails) component. This section describes how to configure the GitLab application (Rails) component.
In our architecture, we run each GitLab Rails node using the Puma webserver, and
have its number of workers set to 90% of available CPUs, with four threads. For
nodes running Rails with other components, the worker value should be reduced
accordingly. We've determined that a worker value of 50% achieves a good balance,
but this is dependent on workload.
On each node perform the following: On each node perform the following:
1. If you're [using NFS](#configure-nfs-optional): 1. If you're [using NFS](#configure-nfs-optional):
...@@ -1465,10 +1458,10 @@ On each node perform the following: ...@@ -1465,10 +1458,10 @@ On each node perform the following:
mkdir -p /var/opt/gitlab/.ssh /var/opt/gitlab/gitlab-rails/uploads /var/opt/gitlab/gitlab-rails/shared /var/opt/gitlab/gitlab-ci/builds /var/opt/gitlab/git-data mkdir -p /var/opt/gitlab/.ssh /var/opt/gitlab/gitlab-rails/uploads /var/opt/gitlab/gitlab-rails/shared /var/opt/gitlab/gitlab-ci/builds /var/opt/gitlab/git-data
``` ```
1. Download/install Omnibus GitLab using **steps 1 and 2** from 1. Download and install Omnibus GitLab using **steps 1 and 2** from
[GitLab downloads](https://about.gitlab.com/install/). Do not complete other [GitLab downloads](https://about.gitlab.com/install/). Do not complete other
steps on the download page. steps on the download page.
1. Create/edit `/etc/gitlab/gitlab.rb` and use the following configuration. 1. Create or edit `/etc/gitlab/gitlab.rb` and use the following configuration.
To maintain uniformity of links across nodes, the `external_url` To maintain uniformity of links across nodes, the `external_url`
on the application server should point to the external URL that users will use on the application server should point to the external URL that users will use
to access GitLab. This would be the URL of the [external load balancer](#configure-the-external-load-balancer) to access GitLab. This would be the URL of the [external load balancer](#configure-the-external-load-balancer)
...@@ -1604,12 +1597,10 @@ On each node perform the following: ...@@ -1604,12 +1597,10 @@ On each node perform the following:
run: puma: (pid 4936) 8645s; run: log: (pid 29656) 79161s run: puma: (pid 4936) 8645s; run: log: (pid 29656) 79161s
``` ```
NOTE: **Note:** When you specify `https` in the `external_url`, as in the previous example,
When you specify `https` in the `external_url`, as in the example GitLab expects that the SSL certificates are in `/etc/gitlab/ssl/`. If the
above, GitLab assumes you have SSL certificates in `/etc/gitlab/ssl/`. If certificates aren't present, NGINX will fail to start. For more information, see
certificates are not present, NGINX will fail to start. See the the [NGINX documentation](https://docs.gitlab.com/omnibus/settings/nginx.html#enable-https).
[NGINX documentation](https://docs.gitlab.com/omnibus/settings/nginx.html#enable-https)
for more information.
### GitLab Rails post-configuration ### GitLab Rails post-configuration
...@@ -1619,12 +1610,11 @@ for more information. ...@@ -1619,12 +1610,11 @@ for more information.
gitlab-rake gitlab:db:configure gitlab-rake gitlab:db:configure
``` ```
NOTE: **Note:** If you encounter a `rake aborted!` error message stating that PgBouncer is
If you encounter a `rake aborted!` error stating that PgBouncer is failing to connect to failing to connect to PostgreSQL, it may be that your PgBouncer node's IP
PostgreSQL it may be that your PgBouncer node's IP address is missing from address is missing from PostgreSQL's `trust_auth_cidr_addresses` in `gitlab.rb`
PostgreSQL's `trust_auth_cidr_addresses` in `gitlab.rb` on your database nodes. See on your database nodes. Before proceeding, see
[PgBouncer error `ERROR: pgbouncer cannot connect to server`](troubleshooting.md#pgbouncer-error-error-pgbouncer-cannot-connect-to-server) [PgBouncer error `ERROR: pgbouncer cannot connect to server`](troubleshooting.md#pgbouncer-error-error-pgbouncer-cannot-connect-to-server).
in the Troubleshooting section before proceeding.
1. [Configure fast lookup of authorized SSH keys in the database](../operations/fast_ssh_key_lookup.md). 1. [Configure fast lookup of authorized SSH keys in the database](../operations/fast_ssh_key_lookup.md).
...@@ -1781,16 +1771,13 @@ work. ...@@ -1781,16 +1771,13 @@ work.
## Configure Advanced Search **(STARTER ONLY)** ## Configure Advanced Search **(STARTER ONLY)**
NOTE: **Note:** You can leverage Elasticsearch and [enable Advanced Search](../../integration/elasticsearch.md)
Elasticsearch cluster design and requirements are dependent on your specific data. for faster, more advanced code search across your entire GitLab instance.
For recommended best practices on how to set up your Elasticsearch cluster
alongside your instance, read how to
[choose the optimal cluster configuration](../../integration/elasticsearch.md#guidance-on-choosing-optimal-cluster-configuration).
You can leverage Elasticsearch and enable Advanced Search for faster, more Elasticsearch cluster design and requirements are dependent on your specific
advanced code search across your entire GitLab instance. data. For recommended best practices about how to set up your Elasticsearch
cluster alongside your instance, read how to
[Learn how to set it up.](../../integration/elasticsearch.md) [choose the optimal cluster configuration](../../integration/elasticsearch.md#guidance-on-choosing-optimal-cluster-configuration).
<div align="right"> <div align="right">
<a type="button" class="btn btn-default" href="#setup-components"> <a type="button" class="btn btn-default" href="#setup-components">
......
doc/administration/reference_architectures/50k_users.md
View file @ 7677855b
...@@ -114,19 +114,18 @@ The following list includes descriptions of each server and its assigned IP: ...@@ -114,19 +114,18 @@ The following list includes descriptions of each server and its assigned IP:
## Configure the external load balancer ## Configure the external load balancer
NOTE: **Note:** In an active/active 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 hope
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/) 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 as the load balancer. Although other load balancers with similar feature sets
could also be used, those load balancers have not been validated. could also be used, those load balancers have not been validated.
In an active/active GitLab configuration, you will need a load balancer to route
traffic to the application servers. The specifics on which load balancer to use
or the exact configuration is beyond the scope of GitLab documentation. We hope
that if you're managing multi-node systems like GitLab you have a load balancer of
choice already. Some examples including HAProxy (open-source), F5 Big-IP LTM,
and Citrix Net Scaler. This documentation will outline what ports and protocols
you need to use with GitLab.
The next question is how you will handle SSL in your environment. The next question is how you will handle SSL in your environment.
There are several different options: There are several different options:
...@@ -284,10 +283,9 @@ To configure Consul: ...@@ -284,10 +283,9 @@ To configure Consul:
1. Go through the steps again for all the other Consul nodes, and 1. Go through the steps again for all the other Consul nodes, and
make sure you set up the correct IPs. make sure you set up the correct IPs.
NOTE: **Note:** A Consul leader is _elected_ when the provisioning of the third Consul server is
A Consul leader will be elected when the provisioning of the third Consul server is completed. complete. Viewing the Consul logs `sudo gitlab-ctl tail consul` displays
Viewing the Consul logs `sudo gitlab-ctl tail consul` will display `...[INFO] consul: New leader elected: ...`.
`...[INFO] consul: New leader elected: ...`
You can list the current Consul members (server, client): You can list the current Consul members (server, client):
...@@ -664,7 +662,6 @@ The following IPs will be used as an example: ...@@ -664,7 +662,6 @@ The following IPs will be used as an example:
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect. 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
NOTE: **Note:**
If an error `execute[generate databases.ini]` occurs, this is due to an existing If an error `execute[generate databases.ini]` occurs, this is due to an existing
[known issue](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/4713). [known issue](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/4713).
It will be resolved when you run a second `reconfigure` after the next step. It will be resolved when you run a second `reconfigure` after the next step.
...@@ -798,25 +795,23 @@ to be used with GitLab. The following IPs will be used as an example: ...@@ -798,25 +795,23 @@ to be used with GitLab. The following IPs will be used as an example:
- `10.6.0.82`: Sentinel - Queues 2 - `10.6.0.82`: Sentinel - Queues 2
- `10.6.0.83`: Sentinel - Queues 3 - `10.6.0.83`: Sentinel - Queues 3
NOTE: **Providing your own Redis instance:** ### Providing your own Redis instance
Managed Redis from cloud providers such as AWS ElastiCache will work. If these
services support high availability, be sure it is **not** the Redis Cluster type. Managed Redis from cloud providers (such as AWS ElastiCache) will work. If these
Redis version 5.0 or higher is required, as this is what ships with services support high availability, be sure it _isn't_ of the Redis Cluster type.
Omnibus GitLab packages starting with GitLab 13.0. Older Redis versions Redis version 5.0 or higher is required, which is included with Omnibus GitLab
do not support an optional count argument to SPOP which is now required for packages starting with GitLab 13.0. Older Redis versions don't support an
[Merge Trains](../../ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md). optional count argument to SPOP, which is required for [Merge Trains](../../ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md).
Note the Redis node's IP address or hostname, port, and password (if required). Note the Redis node's IP address or hostname, port, and password (if required).
These will be necessary when configuring the These will be necessary later when configuring the [GitLab application servers](#configure-gitlab-rails).
[GitLab application servers](#configure-gitlab-rails) later.
### Configure the Redis and Sentinel Cache cluster ### Configure the Redis and Sentinel Cache cluster
This is the section where we install and set up the new Redis Cache instances. This is the section where we install and set up the new Redis Cache instances.
NOTE: **Note:** Both the primary and replica Redis nodes need the same password defined in
Redis nodes (both primary and replica) will need the same password defined in `redis['password']`. At any time during a failover, the Sentinels can reconfigure
`redis['password']`. At any time during a failover the Sentinels can a node and change its status from primary to replica (and vice versa).
reconfigure a node and change its status from primary to replica and vice versa.
#### Configure the primary Redis Cache node #### Configure the primary Redis Cache node
...@@ -870,10 +865,9 @@ reconfigure a node and change its status from primary to replica and vice versa. ...@@ -870,10 +865,9 @@ reconfigure a node and change its status from primary to replica and vice versa.
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect. 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
NOTE: **Note:** You can specify multiple roles, like sentinel and Redis, as:
You can specify multiple roles like sentinel and Redis as: `roles ['redis_sentinel_role', 'redis_master_role']`. Read more about
`roles ['redis_sentinel_role', 'redis_master_role']`. [roles](https://docs.gitlab.com/omnibus/roles/).
Read more about [roles](https://docs.gitlab.com/omnibus/roles/).
#### Configure the replica Redis Cache nodes #### Configure the replica Redis Cache nodes
...@@ -936,10 +930,9 @@ Read more about [roles](https://docs.gitlab.com/omnibus/roles/). ...@@ -936,10 +930,9 @@ Read more about [roles](https://docs.gitlab.com/omnibus/roles/).
1. Go through the steps again for all the other replica nodes, and 1. Go through the steps again for all the other replica nodes, and
make sure to set up the IPs correctly. make sure to set up the IPs correctly.
NOTE: **Note:** You can specify multiple roles, like sentinel and Redis, as:
You can specify multiple roles like sentinel and Redis as: `roles ['redis_sentinel_role', 'redis_master_role']`. Read more about
`roles ['redis_sentinel_role', 'redis_master_role']`. [roles](https://docs.gitlab.com/omnibus/roles/).
Read more about [roles](https://docs.gitlab.com/omnibus/roles/).
These values don't have to be changed again in `/etc/gitlab/gitlab.rb` after These values don't have to be changed again in `/etc/gitlab/gitlab.rb` after
a failover, as the nodes will be managed by the [Sentinels](#configure-the-sentinel-cache-nodes), and even after a a failover, as the nodes will be managed by the [Sentinels](#configure-the-sentinel-cache-nodes), and even after a
...@@ -957,13 +950,6 @@ are supported and can be added if needed. ...@@ -957,13 +950,6 @@ are supported and can be added if needed.
#### Configure the Sentinel Cache nodes #### Configure the Sentinel Cache nodes
NOTE: **Note:**
If you are using an external Redis Sentinel instance, be sure
to exclude the `requirepass` parameter from the Sentinel
configuration. This parameter will cause clients to report `NOAUTH
Authentication required.`. [Redis Sentinel 3.2.x does not support
password authentication](https://github.com/antirez/redis/issues/3279).
Now that the Redis servers are all set up, let's configure the Sentinel Now that the Redis servers are all set up, let's configure the Sentinel
servers. The following IPs will be used as an example: servers. The following IPs will be used as an example:
...@@ -971,6 +957,12 @@ servers. The following IPs will be used as an example: ...@@ -971,6 +957,12 @@ servers. The following IPs will be used as an example:
- `10.6.0.72`: Sentinel - Cache 2 - `10.6.0.72`: Sentinel - Cache 2
- `10.6.0.73`: Sentinel - Cache 3 - `10.6.0.73`: Sentinel - Cache 3
NOTE: **Note:**
If you're using an external Redis Sentinel instance, be sure to exclude the
`requirepass` parameter from the Sentinel configuration. This parameter causes
clients to report `NOAUTH Authentication required.`.
[Redis Sentinel 3.2.x doesn't support password authentication](https://github.com/antirez/redis/issues/3279).
To configure the Sentinel Cache server: To configure the Sentinel Cache server:
1. SSH into the server that will host Consul/Sentinel. 1. SSH into the server that will host Consul/Sentinel.
...@@ -1083,10 +1075,9 @@ To configure the Sentinel Cache server: ...@@ -1083,10 +1075,9 @@ To configure the Sentinel Cache server:
This is the section where we install and set up the new Redis Queues instances. This is the section where we install and set up the new Redis Queues instances.
NOTE: **Note:** Both the primary and replica Redis nodes need the same password defined in
Redis nodes (both primary and replica) will need the same password defined in `redis['password']`. At any time during a failover, the Sentinels can reconfigure
`redis['password']`. At any time during a failover the Sentinels can a node and change its status from primary to replica (and vice versa).
reconfigure a node and change its status from primary to replica and vice versa.
#### Configure the primary Redis Queues node #### Configure the primary Redis Queues node
...@@ -1145,10 +1136,9 @@ reconfigure a node and change its status from primary to replica and vice versa. ...@@ -1145,10 +1136,9 @@ reconfigure a node and change its status from primary to replica and vice versa.
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect. 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
NOTE: **Note:** You can specify multiple roles, like sentinel and Redis, as:
You can specify multiple roles like sentinel and Redis as: `roles ['redis_sentinel_role', 'redis_master_role']`. Read more about
`roles ['redis_sentinel_role', 'redis_master_role']`. [roles](https://docs.gitlab.com/omnibus/roles/).
Read more about [roles](https://docs.gitlab.com/omnibus/roles/).
#### Configure the replica Redis Queues nodes #### Configure the replica Redis Queues nodes
...@@ -1211,10 +1201,9 @@ Read more about [roles](https://docs.gitlab.com/omnibus/roles/). ...@@ -1211,10 +1201,9 @@ Read more about [roles](https://docs.gitlab.com/omnibus/roles/).
1. Go through the steps again for all the other replica nodes, and 1. Go through the steps again for all the other replica nodes, and
make sure to set up the IPs correctly. make sure to set up the IPs correctly.
NOTE: **Note:** You can specify multiple roles, like sentinel and Redis, as:
You can specify multiple roles like sentinel and Redis as: `roles ['redis_sentinel_role', 'redis_master_role']`. Read more about
`roles ['redis_sentinel_role', 'redis_master_role']`. [roles](https://docs.gitlab.com/omnibus/roles/).
Read more about [roles](https://docs.gitlab.com/omnibus/roles/).
These values don't have to be changed again in `/etc/gitlab/gitlab.rb` after These values don't have to be changed again in `/etc/gitlab/gitlab.rb` after
a failover, as the nodes will be managed by the [Sentinels](#configure-the-sentinel-queues-nodes), and even after a a failover, as the nodes will be managed by the [Sentinels](#configure-the-sentinel-queues-nodes), and even after a
...@@ -1232,13 +1221,6 @@ are supported and can be added if needed. ...@@ -1232,13 +1221,6 @@ are supported and can be added if needed.
#### Configure the Sentinel Queues nodes #### Configure the Sentinel Queues nodes
NOTE: **Note:**
If you are using an external Redis Sentinel instance, be sure
to exclude the `requirepass` parameter from the Sentinel
configuration. This parameter will cause clients to report `NOAUTH
Authentication required.`. [Redis Sentinel 3.2.x does not support
password authentication](https://github.com/antirez/redis/issues/3279).
Now that the Redis servers are all set up, let's configure the Sentinel Now that the Redis servers are all set up, let's configure the Sentinel
servers. The following IPs will be used as an example: servers. The following IPs will be used as an example:
...@@ -1246,6 +1228,12 @@ servers. The following IPs will be used as an example: ...@@ -1246,6 +1228,12 @@ servers. The following IPs will be used as an example:
- `10.6.0.82`: Sentinel - Queues 2 - `10.6.0.82`: Sentinel - Queues 2
- `10.6.0.83`: Sentinel - Queues 3 - `10.6.0.83`: Sentinel - Queues 3
NOTE: **Note:**
If you're using an external Redis Sentinel instance, be sure to exclude the
`requirepass` parameter from the Sentinel configuration. This parameter causes
clients to report `NOAUTH Authentication required.`.
[Redis Sentinel 3.2.x doesn't support password authentication](https://github.com/antirez/redis/issues/3279).
To configure the Sentinel Queues server: To configure the Sentinel Queues server:
1. SSH into the server that will host Sentinel. 1. SSH into the server that will host Sentinel.
...@@ -1519,11 +1507,10 @@ Name. If you are addressing the Gitaly server by its IP address, you must add it ...@@ -1519,11 +1507,10 @@ Name. If you are addressing the Gitaly server by its IP address, you must add it
as a Subject Alternative Name to the certificate. as a Subject Alternative Name to the certificate.
[gRPC does not support using an IP address as Common Name in a certificate](https://github.com/grpc/grpc/issues/2691). [gRPC does not support using an IP address as Common Name in a certificate](https://github.com/grpc/grpc/issues/2691).
NOTE: **Note:** It's possible to configure Gitaly servers with both an unencrypted listening
It is possible to configure Gitaly servers with both an address (`listen_addr`) and an encrypted listening address (`tls_listen_addr`)
unencrypted listening address `listen_addr` and an encrypted listening at the same time. This allows you to do a gradual transition from unencrypted to
address `tls_listen_addr` at the same time. This allows you to do a encrypted traffic, if necessary.
gradual transition from unencrypted to encrypted traffic, if necessary.
To configure Gitaly with TLS: To configure Gitaly with TLS:
...@@ -1699,15 +1686,14 @@ You can also run [multiple Sidekiq processes](../operations/extra_sidekiq_proces ...@@ -1699,15 +1686,14 @@ You can also run [multiple Sidekiq processes](../operations/extra_sidekiq_proces
## Configure GitLab Rails ## Configure GitLab Rails
NOTE: **Note:**
In our architectures we run each GitLab Rails node using the Puma webserver
and have its number of workers set to 90% of available CPUs along with four threads. For
nodes that are running Rails with other components the worker value should be reduced
accordingly where we've found 50% achieves a good balance but this is dependent
on workload.
This section describes how to configure the GitLab application (Rails) component. This section describes how to configure the GitLab application (Rails) component.
In our architecture, we run each GitLab Rails node using the Puma webserver, and
have its number of workers set to 90% of available CPUs, with four threads. For
nodes running Rails with other components, the worker value should be reduced
accordingly. We've determined that a worker value of 50% achieves a good balance,
but this is dependent on workload.
The following IPs will be used as an example: The following IPs will be used as an example:
- `10.6.0.111`: GitLab application 1 - `10.6.0.111`: GitLab application 1
...@@ -1716,7 +1702,7 @@ The following IPs will be used as an example: ...@@ -1716,7 +1702,7 @@ The following IPs will be used as an example:
On each node perform the following: On each node perform the following:
1. Download/install Omnibus GitLab using **steps 1 and 2** from 1. Download and install Omnibus GitLab using **steps 1 and 2** from
[GitLab downloads](https://about.gitlab.com/install/). Do not complete other [GitLab downloads](https://about.gitlab.com/install/). Do not complete other
steps on the download page. steps on the download page.
...@@ -1878,12 +1864,10 @@ On each node perform the following: ...@@ -1878,12 +1864,10 @@ On each node perform the following:
sudo /opt/gitlab/embedded/bin/gitaly-hooks check /var/opt/gitlab/gitaly/config.toml sudo /opt/gitlab/embedded/bin/gitaly-hooks check /var/opt/gitlab/gitaly/config.toml
``` ```
NOTE: **Note:** When you specify `https` in the `external_url`, as in the previous example,
When you specify `https` in the `external_url`, as in the example GitLab expects that the SSL certificates are in `/etc/gitlab/ssl/`. If the
above, GitLab assumes you have SSL certificates in `/etc/gitlab/ssl/`. If certificates aren't present, NGINX will fail to start. For more information, see
certificates are not present, NGINX will fail to start. See the the [NGINX documentation](https://docs.gitlab.com/omnibus/settings/nginx.html#enable-https).
[NGINX documentation](https://docs.gitlab.com/omnibus/settings/nginx.html#enable-https)
for more information.
### GitLab Rails post-configuration ### GitLab Rails post-configuration
...@@ -1895,12 +1879,11 @@ for more information. ...@@ -1895,12 +1879,11 @@ for more information.
sudo gitlab-rake gitlab:db:configure sudo gitlab-rake gitlab:db:configure
``` ```
NOTE: **Note:** If you encounter a `rake aborted!` error message stating that PgBouncer is
If you encounter a `rake aborted!` error stating that PgBouncer is failing to connect to failing to connect to PostgreSQL, it may be that your PgBouncer node's IP
PostgreSQL it may be that your PgBouncer node's IP address is missing from address is missing from PostgreSQL's `trust_auth_cidr_addresses` in `gitlab.rb`
PostgreSQL's `trust_auth_cidr_addresses` in `gitlab.rb` on your database nodes. See on your database nodes. Before proceeding, see
[PgBouncer error `ERROR: pgbouncer cannot connect to server`](troubleshooting.md#pgbouncer-error-error-pgbouncer-cannot-connect-to-server) [PgBouncer error `ERROR: pgbouncer cannot connect to server`](troubleshooting.md#pgbouncer-error-error-pgbouncer-cannot-connect-to-server).
in the Troubleshooting section before proceeding.
1. [Configure fast lookup of authorized SSH keys in the database](../operations/fast_ssh_key_lookup.md). 1. [Configure fast lookup of authorized SSH keys in the database](../operations/fast_ssh_key_lookup.md).
...@@ -2053,16 +2036,13 @@ work. ...@@ -2053,16 +2036,13 @@ work.
## Configure Advanced Search **(STARTER ONLY)** ## Configure Advanced Search **(STARTER ONLY)**
NOTE: **Note:** You can leverage Elasticsearch and [enable Advanced Search](../../integration/elasticsearch.md)
Elasticsearch cluster design and requirements are dependent on your specific data. for faster, more advanced code search across your entire GitLab instance.
For recommended best practices on how to set up your Elasticsearch cluster
alongside your instance, read how to
[choose the optimal cluster configuration](../../integration/elasticsearch.md#guidance-on-choosing-optimal-cluster-configuration).
You can leverage Elasticsearch and enable Advanced Search for faster, more
advanced code search across your entire GitLab instance.
[Learn how to set it up.](../../integration/elasticsearch.md) Elasticsearch cluster design and requirements are dependent on your specific
data. For recommended best practices about how to set up your Elasticsearch
cluster alongside your instance, read how to
[choose the optimal cluster configuration](../../integration/elasticsearch.md#guidance-on-choosing-optimal-cluster-configuration).
<div align="right"> <div align="right">
<a type="button" class="btn btn-default" href="#setup-components"> <a type="button" class="btn btn-default" href="#setup-components">
......
doc/administration/reference_architectures/5k_users.md
View file @ 7677855b
...@@ -109,19 +109,18 @@ The following list includes descriptions of each server and its assigned IP: ...@@ -109,19 +109,18 @@ The following list includes descriptions of each server and its assigned IP:
## Configure the external load balancer ## Configure the external load balancer
NOTE: **Note:** In an active/active 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 hope
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/) 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 as the load balancer. Although other load balancers with similar feature sets
could also be used, those load balancers have not been validated. could also be used, those load balancers have not been validated.
In an active/active GitLab configuration, you will need a load balancer to route
traffic to the application servers. The specifics on which load balancer to use
or the exact configuration is beyond the scope of GitLab documentation. We hope
that if you're managing multi-node systems like GitLab you have a load balancer of
choice already. Some examples including HAProxy (open-source), F5 Big-IP LTM,
and Citrix Net Scaler. This documentation will outline what ports and protocols
you need to use with GitLab.
The next question is how you will handle SSL in your environment. The next question is how you will handle SSL in your environment.
There are several different options: There are several different options:
...@@ -279,10 +278,9 @@ The requirements for a Redis setup are the following: ...@@ -279,10 +278,9 @@ The requirements for a Redis setup are the following:
([Internet](https://gitlab.com/gitlab-org/gitlab-foss/uploads/c4cc8cd353604bd80315f9384035ff9e/The_Internet_IT_Crowd.png)), ([Internet](https://gitlab.com/gitlab-org/gitlab-foss/uploads/c4cc8cd353604bd80315f9384035ff9e/The_Internet_IT_Crowd.png)),
using a firewall. using a firewall.
NOTE: **Note:** Both the primary and replica Redis nodes need the same password defined in
Redis nodes (both primary and replica) will need the same password defined in `redis['password']`. At any time during a failover, the Sentinels can reconfigure
`redis['password']`. At any time during a failover the Sentinels can a node and change its status from primary to replica (and vice versa).
reconfigure a node and change its status from primary to replica and vice versa.
#### Configuring the primary Redis instance #### Configuring the primary Redis instance
...@@ -336,10 +334,9 @@ reconfigure a node and change its status from primary to replica and vice versa. ...@@ -336,10 +334,9 @@ reconfigure a node and change its status from primary to replica and vice versa.
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect. 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
NOTE: **Note:** You can specify multiple roles, like sentinel and Redis, as:
You can specify multiple roles like sentinel and Redis as: `roles ['redis_sentinel_role', 'redis_master_role']`. Read more about
`roles ['redis_sentinel_role', 'redis_master_role']`. [roles](https://docs.gitlab.com/omnibus/roles/).
Read more about [roles](https://docs.gitlab.com/omnibus/roles/).
You can list the current Redis Primary, Replica status via: You can list the current Redis Primary, Replica status via:
...@@ -424,10 +421,9 @@ run: redis-exporter: (pid 30075) 76861s; run: log: (pid 29674) 76896s ...@@ -424,10 +421,9 @@ run: redis-exporter: (pid 30075) 76861s; run: log: (pid 29674) 76896s
1. Go through the steps again for all the other replica nodes, and 1. Go through the steps again for all the other replica nodes, and
make sure to set up the IPs correctly. make sure to set up the IPs correctly.
NOTE: **Note:** You can specify multiple roles, like sentinel and Redis, as:
You can specify multiple roles like sentinel and Redis as: `roles ['redis_sentinel_role', 'redis_master_role']`. Read more about
`roles ['redis_sentinel_role', 'redis_master_role']`. [roles](https://docs.gitlab.com/omnibus/roles/).
Read more about [roles](https://docs.gitlab.com/omnibus/roles/).
These values don't have to be changed again in `/etc/gitlab/gitlab.rb` after These values don't have to be changed again in `/etc/gitlab/gitlab.rb` after
a failover, as the nodes will be managed by the [Sentinels](#configure-consul-and-sentinel), and even after a a failover, as the nodes will be managed by the [Sentinels](#configure-consul-and-sentinel), and even after a
...@@ -445,13 +441,6 @@ are supported and can be added if needed. ...@@ -445,13 +441,6 @@ are supported and can be added if needed.
## Configure Consul and Sentinel ## Configure Consul and Sentinel
NOTE: **Note:**
If you are using an external Redis Sentinel instance, be sure
to exclude the `requirepass` parameter from the Sentinel
configuration. This parameter will cause clients to report `NOAUTH
Authentication required.`. [Redis Sentinel 3.2.x does not support
password authentication](https://github.com/antirez/redis/issues/3279).
Now that the Redis servers are all set up, let's configure the Sentinel Now that the Redis servers are all set up, let's configure the Sentinel
servers. The following IPs will be used as an example: servers. The following IPs will be used as an example:
...@@ -459,6 +448,12 @@ servers. The following IPs will be used as an example: ...@@ -459,6 +448,12 @@ servers. The following IPs will be used as an example:
- `10.6.0.12`: Consul/Sentinel 2 - `10.6.0.12`: Consul/Sentinel 2
- `10.6.0.13`: Consul/Sentinel 3 - `10.6.0.13`: Consul/Sentinel 3
NOTE: **Note:**
If you're using an external Redis Sentinel instance, be sure to exclude the
`requirepass` parameter from the Sentinel configuration. This parameter causes
clients to report `NOAUTH Authentication required.`.
[Redis Sentinel 3.2.x doesn't support password authentication](https://github.com/antirez/redis/issues/3279).
To configure the Sentinel: To configure the Sentinel:
1. SSH into the server that will host Consul/Sentinel. 1. SSH into the server that will host Consul/Sentinel.
...@@ -558,10 +553,9 @@ To configure the Sentinel: ...@@ -558,10 +553,9 @@ To configure the Sentinel:
1. Go through the steps again for all the other Consul/Sentinel nodes, and 1. Go through the steps again for all the other Consul/Sentinel nodes, and
make sure you set up the correct IPs. make sure you set up the correct IPs.
NOTE: **Note:** A Consul leader is _elected_ when the provisioning of the third Consul server is
A Consul leader will be elected when the provisioning of the third Consul server is completed. complete. Viewing the Consul logs `sudo gitlab-ctl tail consul` displays
Viewing the Consul logs `sudo gitlab-ctl tail consul` will display `...[INFO] consul: New leader elected: ...`.
`...[INFO] consul: New leader elected: ...`
You can list the current Consul members (server, client): You can list the current Consul members (server, client):
...@@ -1257,11 +1251,10 @@ Name. If you are addressing the Gitaly server by its IP address, you must add it ...@@ -1257,11 +1251,10 @@ Name. If you are addressing the Gitaly server by its IP address, you must add it
as a Subject Alternative Name to the certificate. as a Subject Alternative Name to the certificate.
[gRPC does not support using an IP address as Common Name in a certificate](https://github.com/grpc/grpc/issues/2691). [gRPC does not support using an IP address as Common Name in a certificate](https://github.com/grpc/grpc/issues/2691).
NOTE: **Note:** It's possible to configure Gitaly servers with both an unencrypted listening
It is possible to configure Gitaly servers with both an address (`listen_addr`) and an encrypted listening address (`tls_listen_addr`)
unencrypted listening address `listen_addr` and an encrypted listening at the same time. This allows you to do a gradual transition from unencrypted to
address `tls_listen_addr` at the same time. This allows you to do a encrypted traffic, if necessary.
gradual transition from unencrypted to encrypted traffic, if necessary.
To configure Gitaly with TLS: To configure Gitaly with TLS:
...@@ -1429,14 +1422,14 @@ You can also run [multiple Sidekiq processes](../operations/extra_sidekiq_proces ...@@ -1429,14 +1422,14 @@ You can also run [multiple Sidekiq processes](../operations/extra_sidekiq_proces
## Configure GitLab Rails ## Configure GitLab Rails
NOTE: **Note:**
In our architectures we run each GitLab Rails node using the Puma webserver
and have its number of workers set to 90% of available CPUs along with four threads. For
nodes that are running Rails with other components the worker value should be reduced
accordingly where we've found 50% achieves a good balance but this is dependent
on workload.
This section describes how to configure the GitLab application (Rails) component. This section describes how to configure the GitLab application (Rails) component.
In our architecture, we run each GitLab Rails node using the Puma webserver, and
have its number of workers set to 90% of available CPUs, with four threads. For
nodes running Rails with other components, the worker value should be reduced
accordingly. We've determined that a worker value of 50% achieves a good balance,
but this is dependent on workload.
On each node perform the following: On each node perform the following:
1. If you're [using NFS](#configure-nfs-optional): 1. If you're [using NFS](#configure-nfs-optional):
...@@ -1464,10 +1457,10 @@ On each node perform the following: ...@@ -1464,10 +1457,10 @@ On each node perform the following:
mkdir -p /var/opt/gitlab/.ssh /var/opt/gitlab/gitlab-rails/uploads /var/opt/gitlab/gitlab-rails/shared /var/opt/gitlab/gitlab-ci/builds /var/opt/gitlab/git-data mkdir -p /var/opt/gitlab/.ssh /var/opt/gitlab/gitlab-rails/uploads /var/opt/gitlab/gitlab-rails/shared /var/opt/gitlab/gitlab-ci/builds /var/opt/gitlab/git-data
``` ```
1. Download/install Omnibus GitLab using **steps 1 and 2** from 1. Download and install Omnibus GitLab using **steps 1 and 2** from
[GitLab downloads](https://about.gitlab.com/install/). Do not complete other [GitLab downloads](https://about.gitlab.com/install/). Do not complete other
steps on the download page. steps on the download page.
1. Create/edit `/etc/gitlab/gitlab.rb` and use the following configuration. 1. Create or edit `/etc/gitlab/gitlab.rb` and use the following configuration.
To maintain uniformity of links across nodes, the `external_url` To maintain uniformity of links across nodes, the `external_url`
on the application server should point to the external URL that users will use on the application server should point to the external URL that users will use
to access GitLab. This would be the URL of the [external load balancer](#configure-the-external-load-balancer) to access GitLab. This would be the URL of the [external load balancer](#configure-the-external-load-balancer)
...@@ -1603,12 +1596,10 @@ On each node perform the following: ...@@ -1603,12 +1596,10 @@ On each node perform the following:
run: puma: (pid 4936) 8645s; run: log: (pid 29656) 79161s run: puma: (pid 4936) 8645s; run: log: (pid 29656) 79161s
``` ```
NOTE: **Note:** When you specify `https` in the `external_url`, as in the previous example,
When you specify `https` in the `external_url`, as in the example GitLab expects that the SSL certificates are in `/etc/gitlab/ssl/`. If the
above, GitLab assumes you have SSL certificates in `/etc/gitlab/ssl/`. If certificates aren't present, NGINX will fail to start. For more information, see
certificates are not present, NGINX will fail to start. See the the [NGINX documentation](https://docs.gitlab.com/omnibus/settings/nginx.html#enable-https).
[NGINX documentation](https://docs.gitlab.com/omnibus/settings/nginx.html#enable-https)
for more information.
### GitLab Rails post-configuration ### GitLab Rails post-configuration
...@@ -1618,12 +1609,11 @@ for more information. ...@@ -1618,12 +1609,11 @@ for more information.
gitlab-rake gitlab:db:configure gitlab-rake gitlab:db:configure
``` ```
NOTE: **Note:** If you encounter a `rake aborted!` error message stating that PgBouncer is
If you encounter a `rake aborted!` error stating that PgBouncer is failing to connect to failing to connect to PostgreSQL, it may be that your PgBouncer node's IP
PostgreSQL it may be that your PgBouncer node's IP address is missing from address is missing from PostgreSQL's `trust_auth_cidr_addresses` in `gitlab.rb`
PostgreSQL's `trust_auth_cidr_addresses` in `gitlab.rb` on your database nodes. See on your database nodes. Before proceeding, see
[PgBouncer error `ERROR: pgbouncer cannot connect to server`](troubleshooting.md#pgbouncer-error-error-pgbouncer-cannot-connect-to-server) [PgBouncer error `ERROR: pgbouncer cannot connect to server`](troubleshooting.md#pgbouncer-error-error-pgbouncer-cannot-connect-to-server).
in the Troubleshooting section before proceeding.
1. [Configure fast lookup of authorized SSH keys in the database](../operations/fast_ssh_key_lookup.md). 1. [Configure fast lookup of authorized SSH keys in the database](../operations/fast_ssh_key_lookup.md).
...@@ -1780,16 +1770,13 @@ work. ...@@ -1780,16 +1770,13 @@ work.
## Configure Advanced Search **(STARTER ONLY)** ## Configure Advanced Search **(STARTER ONLY)**
NOTE: **Note:** You can leverage Elasticsearch and [enable Advanced Search](../../integration/elasticsearch.md)
Elasticsearch cluster design and requirements are dependent on your specific data. for faster, more advanced code search across your entire GitLab instance.
For recommended best practices on how to set up your Elasticsearch cluster
alongside your instance, read how to
[choose the optimal cluster configuration](../../integration/elasticsearch.md#guidance-on-choosing-optimal-cluster-configuration).
You can leverage Elasticsearch and enable Advanced Search for faster, more Elasticsearch cluster design and requirements are dependent on your specific
advanced code search across your entire GitLab instance. data. For recommended best practices about how to set up your Elasticsearch
cluster alongside your instance, read how to
[Learn how to set it up.](../../integration/elasticsearch.md) [choose the optimal cluster configuration](../../integration/elasticsearch.md#guidance-on-choosing-optimal-cluster-configuration).
<div align="right"> <div align="right">
<a type="button" class="btn btn-default" href="#setup-components"> <a type="button" class="btn btn-default" href="#setup-components">
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7