diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2020-03-30 12:07:40 +0000 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2020-03-30 12:07:40 +0000 |
commit | 506d6dcd7c787ba71a8a53102f3d4fdb6adcfa5e (patch) | |
tree | b1d65f48256b1f17d6f47429a65050c5d43f420a /doc/administration | |
parent | 45b4df3e57c949c88107840c44ccbfaf2eabdf26 (diff) | |
download | gitlab-ce-506d6dcd7c787ba71a8a53102f3d4fdb6adcfa5e.tar.gz |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc/administration')
-rw-r--r-- | doc/administration/high_availability/README.md | 86 | ||||
-rw-r--r-- | doc/administration/instance_limits.md | 8 |
2 files changed, 60 insertions, 34 deletions
diff --git a/doc/administration/high_availability/README.md b/doc/administration/high_availability/README.md index 88f1079dec5..2bc2f28e4c5 100644 --- a/doc/administration/high_availability/README.md +++ b/doc/administration/high_availability/README.md @@ -4,62 +4,80 @@ type: reference, concepts # Scaling and High Availability -GitLab supports a number of options for larger self-managed instances to -ensure that they are scalable and highly available. While these needs can be tackled -individually, they typically go hand in hand: a performant scalable environment -will have availability by default, as its components are separated and pooled. +GitLab supports a number of scaling options to ensure that your self-managed +instance is able to scale out to meet your organization's needs when scaling up +is no longer practical or feasible. -On this page, we present a maturity model for a progression from simple to complex -GitLab installations as your GitLab usage evolves. For larger setups we give several recommended -architectures based on experience with GitLab.com and internal scale -testing that aim to achieve the right balance between both scalability -and availability. +GitLab also offers high availability options for organizations that require +the fault tolerance and redundancy necessary to maintain high-uptime operations. + +Scaling and high availability can be tackled separately as GitLab comprises +modular components which can be individually scaled or made highly available +depending on your organization's needs and resources. + +On this page, we present examples of self-managed instances which demonstrate +how GitLab can be scaled out and made highly available. These examples progress +from simple to complex as scaling or highly-available components are added. + +For larger setups serving 2,000 or more users, we provide +[reference architectures](#reference-architectures) based on GitLab's +experience with GitLab.com and internal scale testing that aim to achieve the +right balance of scalability and availability. For detailed insight into how GitLab scales and configures GitLab.com, you can watch [this 1 hour Q&A](https://www.youtube.com/watch?v=uCU8jdYzpac) with [John Northrup](https://gitlab.com/northrup), and live questions coming in from some of our customers. -## Maturity levels +## Scaling examples -### Level 1: Single-node Omnibus installation +### Single-node Omnibus installation This solution is appropriate for many teams that have a single server at their disposal. With automatic backup of the GitLab repositories, configuration, and the database, this can be an optimal solution if you don't have strict availability requirements. -This configuration is supported in [GitLab Starter, Premium and Ultimate](https://about.gitlab.com/pricing/). +You can also optionally configure GitLab to use an [external PostgreSQL service](../external_database.md) +or an [external object storage service](object_storage.md) for added +performance and reliability at a relatively low complexity cost. References: - [Installation Docs](../../install/README.md) - [Backup/Restore Docs](https://docs.gitlab.com/omnibus/settings/backups.html#backup-and-restore-omnibus-gitlab-configuration) -### Level 2: Multiple application servers +### Omnibus installation with multiple application servers -By separating components you can see a number of advantages compared to a single-node setup. Namely, you can: +This solution is appropriate for teams that are starting to scale out when +scaling up is no longer meeting their needs. In this configuration, additional application nodes will handle frontend traffic, with a load balancer in front to distribute traffic across those nodes. Meanwhile, each application node connects to a shared file server and PostgreSQL and Redis services on the back end. -- Increase the number of users -- Enable zero-downtime upgrades -- Increase availability - -Additional application nodes will handle frontend traffic, with a load balancer in front to distribute traffic across those nodes. Meanwhile, each application node connects to a shared file server and database systems on the back end. This way, if one of the application servers fails, the workflow is not interrupted. - -This configuration is supported in [GitLab Starter, Premium and Ultimate](https://about.gitlab.com/pricing/). +The additional application servers adds limited fault tolerance to your GitLab +instance. As long as one application node is online and capable of handling the +instance's usage load, your team's productivity will not be interrupted. Having +multiple application nodes also enables [zero-downtime updates](https://docs.gitlab.com/omnibus/update/#zero-downtime-updates). References: -- [High Availability Reference Architectures](#reference-architectures), without HA components +- [Configure your load balancer for GitLab](load_balancer.md) +- [Configure your NFS server to work with GitLab](nfs.md) +- [Configure packaged PostgreSQL server to listen on TCP/IP](https://docs.gitlab.com/omnibus/settings/database.html#configure-packaged-postgresql-server-to-listen-on-tcpip) +- [Setting up a Redis-only server](https://docs.gitlab.com/omnibus/settings/redis.html#setting-up-a-redis-only-server) -### Level 3: Highly Available +## High-availability examples -By adding automatic failover for database systems, we can enable higher uptime with an additional layer of complexity. +### Omnibus installation with automatic database failover -This configuration is supported in [GitLab Premium and Ultimate](https://about.gitlab.com/pricing/). +By adding automatic failover for database systems, we can enable higher uptime with an additional layer of complexity. -References: +- For PostgreSQL, we provide repmgr for server cluster management and failover + and a combination of [PgBouncer](pgbouncer.md) and [Consul](consul.md) for + database client cutover. +- For Redis, we use [Redis Sentinel](redis.md) for server failover and client cutover. -- [High Availability Reference Architectures](#reference-architectures) +You can also optionally run [additional Sidekiq processes on dedicated hardware](sidekiq.md) +and configure individual Sidekiq processes to +[process specific background job queues](../operations/extra_sidekiq_processes.md) +if you need to scale out background job processing. -### Level 4: GitLab Geo +### GitLab Geo GitLab Geo allows you to replicate your GitLab instance to other geographical locations as a read-only fully operational instance that can also be promoted in case of disaster. @@ -70,12 +88,6 @@ References: - [Geo Documentation](../geo/replication/index.md) - [GitLab Geo with a highly available configuration](../geo/replication/high_availability.md) -## Recommended setups based on number of users - -- 1 - 1000 Users: A single-node [Omnibus](https://docs.gitlab.com/omnibus/) setup with frequent backups. Refer to the [requirements page](../../install/requirements.md) for further details of the specs you will require. -- 1000 - 10000 Users: A scaled environment based on one of our [Reference Architectures](#reference-architectures), without the HA components applied. This can be a reasonable step towards a fully HA environment. -- 2000 - 50000+ Users: A scaled HA environment based on one of our [Reference Architectures](#reference-architectures) below. - ## GitLab components and configuration instructions The GitLab application depends on the following [components](../../development/architecture.md#component-diagram). @@ -116,6 +128,12 @@ them. In some cases, components can be combined on the same nodes to reduce complexity as well. +## Recommended setups based on number of users + +- 1 - 1000 Users: A single-node [Omnibus](https://docs.gitlab.com/omnibus/) setup with frequent backups. Refer to the [requirements page](../../install/requirements.md) for further details of the specs you will require. +- 1000 - 10000 Users: A scaled environment based on one of our [Reference Architectures](#reference-architectures), without the HA components applied. This can be a reasonable step towards a fully HA environment. +- 2000 - 50000+ Users: A scaled HA environment based on one of our [Reference Architectures](#reference-architectures) below. + ## Reference architectures In this section we'll detail the Reference Architectures that can support large numbers diff --git a/doc/administration/instance_limits.md b/doc/administration/instance_limits.md index 04af406a295..c1ab7730903 100644 --- a/doc/administration/instance_limits.md +++ b/doc/administration/instance_limits.md @@ -35,6 +35,14 @@ Read more in the [CI documentation](../ci/yaml/README.md#processing-git-pushes). Activity history for projects and individuals' profiles was limited to one year until [GitLab 11.4](https://gitlab.com/gitlab-org/gitlab-foss/issues/52246) when it was extended to two years, and in [GitLab 12.4](https://gitlab.com/gitlab-org/gitlab/issues/33840) to three years. +## Number of embedded metrics + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/14939) in GitLab 12.7. + +There is a limit when embedding metrics in GFM for performance reasons. + +- **Max limit:** 100 embeds + ## Number of webhooks On GitLab.com, the [maximum number of webhooks](../user/gitlab_com/index.md#maximum-number-of-webhooks) per project, and per group, is limited. |