参考架构

极狐GitLab 参考架构提供建议的可扩展和弹性部署，作为目标负载的起点。这些架构由极狐GitLab 测试平台和支持团队设计和测试。

可用的参考架构

以下参考架构作为您环境的建议起点是可用的。

这些架构根据用户数量或每秒请求数 (RPS) 的峰值负载命名。RPS 是基于平均真实数据计算的。

每个架构都设计为可扩展和弹性。可以根据您的工作负载上下调整。例如，一些已知的重负荷场景，如使用大型单体库或显著的额外工作负载。

有关每个参考架构测试对象的详细信息，请参见每个页面的 测试方法 部分。

极狐GitLab 软件包 (Omnibus)

以下是基于 Linux 软件包的参考架构列表：

最多 20 RPS 或 1,000 用户 API: 20 RPS, Web: 2 RPS, Git (Pull): 2 RPS, Git (Push): 1 RPS
最多 40 RPS 或 2,000 用户 API: 40 RPS, Web: 4 RPS, Git (Pull): 4 RPS, Git (Push): 1 RPS
最多 60 RPS 或 3,000 用户 API: 60 RPS, Web: 6 RPS, Git (Pull): 6 RPS, Git (Push): 1 RPS
最多 100 RPS 或 5,000 用户 API: 100 RPS, Web: 10 RPS, Git (Pull): 10 RPS, Git (Push): 2 RPS
最多 200 RPS 或 10,000 用户 API: 200 RPS, Web: 20 RPS, Git (Pull): 20 RPS, Git (Push): 4 RPS
最多 500 RPS 或 25,000 用户 API: 500 RPS, Web: 50 RPS, Git (Pull): 50 RPS, Git (Push): 10 RPS
最多 1000 RPS 或 50,000 用户 API: 1000 RPS, Web: 100 RPS, Git (Pull): 100 RPS, Git (Push): 20 RPS

云原生混合

以下是云原生混合参考架构列表，其中可选择的推荐组件可以在 Kubernetes 中运行：

最多 40 RPS 或 2,000 用户 API: 40 RPS, Web: 4 RPS, Git (Pull): 4 RPS, Git (Push): 1 RPS
最多 60 RPS 或 3,000 用户 API: 60 RPS, Web: 6 RPS, Git (Pull): 6 RPS, Git (Push): 1 RPS
最多 100 RPS 或 5,000 用户 API: 100 RPS, Web: 10 RPS, Git (Pull): 10 RPS, Git (Push): 2 RPS
最多 200 RPS 或 10,000 用户 API: 200 RPS, Web: 20 RPS, Git (Pull): 20 RPS, Git (Push): 4 RPS
最多 500 RPS 或 25,000 用户 API: 500 RPS, Web: 50 RPS, Git (Pull): 50 RPS, Git (Push): 10 RPS
最多 1000 RPS 或 50,000 用户 API: 1000 RPS, Web: 100 RPS, Git (Pull): 100 RPS, Git (Push): 20 RPS

在您开始之前

首先，考虑私有化部署方式是否适合您及您的要求。

在生产环境中运行任何应用程序都很复杂，极狐GitLab 也是如此。虽然我们努力使这一过程尽可能顺利，但仍然存在基于您设计的一般复杂性。通常，您需要管理所有方面，如硬件、操作系统、网络、存储、安全性、极狐GitLab 本身等等。这包括环境的初始设置和长期维护。

如果您决定采用这种方式，您必须具备在生产环境中运行和维护应用程序的工作知识。如果您不是这种情况，我们的专业服务团队提供实施服务。那些希望长期获得更管理解决方案的人，可以探索我们的其他产品，如极狐GitLab SaaS 或极狐GitLab 专用。

如果您正在考虑使用私有化部署方式，我们建议您通读本页面，特别是以下部分：

决定使用哪个架构
大型单体库
额外工作负载

决定使用哪个架构

参考架构旨在在三个重要因素之间取得平衡：性能、弹性和成本。它们旨在简化在大规模上设置极狐GitLab 的过程。然而，仍然可能会有挑战，知道哪个架构满足您的需求以及从哪里开始。

作为一般指导，您希望您的环境越具性能和/或弹性，它就越复杂。

本节解释了选择参考架构时需要考虑的事项。

预期负载 (RPS 或用户数量)

适当的架构大小主要取决于您环境的预期峰值负载。此负载的最客观衡量标准是通过进入环境的每秒请求数 (RPS) 峰值。

每个架构设计用于处理不同类型请求的特定 RPS 目标 (API, Web, Git)。这些详细信息在每个页面的 测试方法 部分中描述。

确定 RPS 可能显著依赖于具体的环境设置和监控堆栈。一些潜在选项包括：

极狐GitLab Prometheus 以及像 sum(irate(gitlab_transaction_duration_seconds_count{controller!~'HealthController|MetricsController|'}[1m])) by (controller, action) 这样的查询。
其他监控解决方案。
负载均衡器统计。

如果您无法确定您的 RPS，我们提供基于等效负载类别用户数量的替代尺寸方法。此数量映射到典型的 RPS 值，考虑到手动和自动使用。

初始尺寸指南

要确定为预期负载选择哪个架构，请参见以下初始尺寸指南表格：

负载类别	每秒请求数 (RPS)				典型用户数量	参考架构
负载类别	API	Web	Git Pull	Git Push	典型用户数量	参考架构
X 小型	20	2	2	1	1,000	最多 20 RPS 或 1,000 用户
小型	40	4	4	1	2,000	最多 40 RPS 或 2,000 用户
中型	60	6	6	1	3,000	最多 60 RPS 或 3,000 用户
大型	100	10	10	2	5,000	最多 100 RPS 或 5,000 用户
X 大型	200	20	20	4	10,000	最多 200 RPS 或 10,000 用户
2X 大型	500	50	50	10	25,000	最多 500 RPS 或 25,000 用户
3X 大型	1000	100	100	20	50,000	最多 1000 RPS 或 50,000 用户

在选择初始架构之前，请仔细审阅本节。考虑其他因素，如高可用性 (HA) 或使用大型单体库，因为它们可能影响选择，不仅仅是 RPS 或用户数量。

选择初始参考架构后，如果指标支持，您可以根据需要向上或向下扩展。

独立 (非 HA)

对于服务 2,000 或更少用户的环境，我们建议通过部署非 HA 的单节点或多节点环境采用独立方式。通过这种方式，您可以采用诸如自动备份的策略进行恢复。这些策略提供了良好的恢复时间目标 (RPO) 或恢复点目标 (RTO)，同时避免了 HA 带来的复杂性。

对于独立设置，特别是单节点环境，可以通过各种选项进行安装和管理。选项包括能够直接使用选择的云提供商市场进行部署，这进一步减少了复杂性。

高可用性 (HA)

高可用性确保极狐GitLab 设置中的每个组件都可以通过各种机制处理故障。然而，要实现这一目标是复杂的，所需的环境可能很大。

对于服务 3,000 或更多用户的环境，我们通常建议使用 HA 策略。在这个级别，停机对更多用户的影响更大。此范围内的所有架构都设计为内置 HA。

您需要高可用性 (HA) 吗？

如前所述，实现 HA 是有代价的。环境要求相当大，因为每个组件都需要被倍增，这带来了额外的实际和维护成本。

对于许多用户少于 3,000 的客户，我们发现备份策略足够甚至更优。虽然这确实有较慢的恢复时间，但这也意味着您拥有更小的架构，因此维护成本较低。

作为一般指导，只有在以下情况下使用 HA：

当您有 3,000 或更多用户时。
当极狐GitLab 停机会严重影响您的工作流程时。

缩减的高可用性 (HA) 方法

如果您仍需要为较少的用户提供 HA，可以通过调整 3K 架构来实现。

零停机升级

零停机升级可用于标准环境的 HA (云原生混合不支持)。这允许在升级期间保持环境运行。然而，此过程因此更加复杂，并在文档中详细说明了一些限制。

在进行此过程时，值得注意的是，当 HA 机制生效时，可能仍会有短暂的停机时刻。

在大多数情况下，进行升级所需的停机时间不应该很长。仅在这是您的关键要求时使用此方法。

云原生混合 (Kubernetes HA)

作为 HA 弹性额外层，您可以在 Kubernetes 中部署选定的组件，称为云原生混合参考架构。出于稳定性原因，像 Gitaly 这样的有状态组件不能在 Kubernetes 中部署。

云原生混合是与标准参考架构相比的替代和更高级的设置。在 Kubernetes 中运行服务是复杂的。仅在您在 Kubernetes 中具有强大的工作知识和经验时使用此设置。

极狐GitLab Geo (跨区域分布/灾难恢复)

使用极狐GitLab Geo，您可以在不同地区实现分布式环境，具备完整的灾难恢复 (DR) 设置。极狐GitLab Geo 需要至少两个独立环境：

一个主站点。
一个或多个作为副本的次要站点。

如果主站点不可用，您可以切换到其中一个次要站点。

仅在 DR 是您环境的关键要求时使用这种高级和复杂的设置。您还必须做出其他决定，例如每个站点的配置方式。例如，是否每个次要站点与主站点具有相同的架构或每个站点是否配置为 HA。

大型单体库/额外工作负载

大型单体库或显著的额外工作负载会显著影响环境的性能。根据具体情况可能需要进行一些调整。

如果这种情况适用于您，请联系您的客户成功经理或我们的支持团队获取进一步指导。

云提供商服务

对于前面描述的所有策略，您可以在等效的云提供商服务上运行选定的极狐GitLab 组件，例如 PostgreSQL 数据库或 Redis。

决策树

在您参考以下决策树之前，请先完整阅读上述指南。

%%{init: { 'theme': 'base' } }%% graph TD L0A(我应该使用什么参考架构？) L1A(您的 <a href=#expected-load-rps-or-user-count>预期负载</a> 是多少？) L2A("60 RPS / 3,000 用户或更多？") L2B("40 RPS / 2,000 用户或更少？") L3A("<a href=#do-you-need-high-availability-ha>您需要 HA 吗？</a> (或零停机升级)") L3B[您是否有经验 并希望在 Kubernetes 中选择组件 以获得额外的弹性？] L4A>推荐 60 RPS / 3,000 用户架构具有 HA 和支持的缩减] L4B>推荐 最接近 <a href=#expected-load-rps-or-user-count>预期负载</a> 的架构，具有 HA] L4C>推荐 最接近 <a href=#expected-load-rps-or-user-count>预期负载</a> 的云原生混合架构] L4D>"推荐 独立 20 RPS / 1,000 用户或 40 RPS / 2,000 用户 架构，具有备份" L0A --> L1A L1A --> L2A L1A --> L2B L2A -->|是| L3B L3B -->|是| L4C L3B -->|否| L4B L2B --> L3A L3A -->|是| L4A L3A -->|否| L4D L5A("<a href=#gitlab-geo-cross-regional-distribution-disaster-recovery>您需要跨区域分布或灾难恢复吗？</a>") --> |是| L6A>额外推荐 极狐GitLab Geo] L4A ~~~ L5A L4B ~~~ L5A L4C ~~~ L5A L4D ~~~ L5A L5B("您是否有 <a href=#large-monorepos>大型单体库</a> 或期望 有大量的 <a href=#additional-workloads>额外工作负载</a>?") --> |是| L6B>额外推荐 联系客户成功经理或支持团队] L4A ~~~ L5B L4B ~~~ L5B L4C ~~~ L5B L4D ~~~ L5B classDef default fill:#FCA326 linkStyle default fill:none,stroke:#7759C2

要求

在实施参考架构之前，请参见以下要求和指导。

支持的 CPU

这些架构在各种云提供商上构建和测试，主要是和 AWS。为了确保最大的兼容性范围，CPU 目标故意设定为这些平台上的最低公分母：

AWS 的 m5 系列。

根据其他要求，例如内存或网络带宽以及云提供商的可用性，不同的机器类型在整个架构中被使用。我们预计上述目标 CPU 表现良好。

如果您愿意，可以选择更新的机器类型系列，并因此获得更好的性能。

此外，ARM CPU 支持 Linux 软件包环境和任何云提供商服务。

由于性能不一致，不建议使用任何“突发型”实例类型。

支持的磁盘类型

极狐GitLab 预期可在大多数标准磁盘类型上正常工作。然而，请注意以下特定警告：

Gitaly 至少需要 8,000 输入/输出操作每秒 (IOPS) 用于读取操作，以及 2,000 IOPS 用于写入操作。
我们不建议使用任何“突发型”磁盘类型，因为性能不一致。

其他磁盘类型预期可与极狐GitLab 一起正常工作。根据您的需求选择，例如耐久性或成本。

支持的基础设施

极狐GitLab 应该可以在大多数基础设施上运行，例如信誉良好的云提供商 (AWS, GCP, Azure) 及其服务，或者满足以下条件的私有化部署 (ESXi)：

每个架构中详述的规格。
本节中的任何要求。

然而，这并不保证与每个潜在排列的兼容性。

有关更多信息，请参见推荐的云提供商和服务。

大型单体库

这些架构经过测试，使用了遵循最佳实践的不同大小的存储库。

然而，大型单体库 (数十 GB 或更多) 可以显著影响 Git 的性能，进而影响整个环境。 它们的存在和使用方式可能会对整个系统从 Gitaly 到底层基础设施造成巨大压力。

性能影响主要是软件性质的。额外的硬件资源导致收益递减。

如果这适用于您，我们强烈建议您遵循链接的文档，并联系您的客户成功经理或我们的支持团队获取进一步指导。

大型单体库带来了显著的成本。如果您有这样的存储库，请遵循这些指南，以确保良好的性能并控制成本：

优化大型单体库。使用诸如 LFS 等功能不存储二进制文件，以及其他减少存储库大小的方法，可以显著提高性能并降低成本。
根据单体库，可能需要增加环境规格以进行补偿。Gitaly 可能需要额外资源，以及 Praefect、极狐GitLab Rails 和负载均衡器。这取决于单体库本身及其使用情况。
当单体库显著大 (20 GB 或更多) 时，可能需要进一步的额外策略，例如进一步增加规格，或在某些情况下，为单体库单独设置 Gitaly 后端。
网络和磁盘带宽是大型单体库的另一个潜在考虑因素。在非常重的情况下，如果有大量并发克隆 (例如使用 CI)，可能会导致带宽饱和。在这种情况下，尽可能减少完全克隆减少并发克隆。否则，可能需要额外的环境规格来增加带宽。这因云提供商而异。

额外工作负载

这些架构是根据真实数据设计和测试的标准极狐GitLab 设置。

然而，额外的工作负载可以通过触发后续动作乘倍操作的影响。如果您使用以下内容，可能需要调整建议的规格以进行补偿：

节点上的安全软件。
数百个并发 CI 作业用于大型存储库。
高频率运行的自定义脚本高频率运行。
大型项目中的集成。
服务器钩子。
系统钩子。

通常，您应该有强大的监控系统来测量任何额外工作负载的影响，以通知需要进行的任何更改。如需进一步指导，请联系您的客户成功经理或我们的支持团队。

负载均衡器

根据类的不同，架构使用了最多两个负载均衡器：

外部负载均衡器 - 为任何面向外部的组件提供流量，主要是 Rails。
内部负载均衡器 - 为选择的内部组件提供流量，这些组件以 HA 形式部署，例如 Praefect 或 PgBouncer。

选择使用哪个负载均衡器或其确切配置超出了极狐GitLab 文档的范围。最常见的选项是在机器节点上设置负载均衡器或使用云提供商提供的服务。如果部署云原生混合环境，图表可以通过 Kubernetes Ingress 处理外部负载均衡器设置。

每个架构类包括建议的基础机器大小以直接在机器上部署。然而，根据选择的负载均衡器和预期工作负载，可能需要进行调整。值得注意的是，机器可能具有不同的网络带宽，这也应考虑。

以下部分提供负载均衡器的额外指导。

平衡算法

为了确保对节点的调用均匀分布并获得良好的性能，尽可能使用基于最少连接的负载均衡算法或等效算法。

我们不建议使用循环算法，因为它们在实际中已知不能均匀分配连接。

网络带宽

当在机器上部署时，负载均衡器的总网络带宽可能会在云提供商之间显著变化。某些云提供商，如 AWS 可能会在一个突发系统上运行，使用积分来确定任何时候的带宽。

负载均衡器所需的网络带宽取决于诸如数据形状和工作负载等因素。每个架构类的推荐基础大小是根据真实数据选择的。然而，在某些情况下，例如持续克隆大型单体库，可能需要根据需要调整大小。

不使用交换

参考架构中不推荐使用交换。它是一个保险措施，极大地影响性能。架构设计为在大多数情况下具有足够的内存，以避免需要交换。

Praefect PostgreSQL

Praefect 需要其自己的数据库服务器。为了实现完整的 HA，需要第三方 PostgreSQL 数据库解决方案。

我们希望在未来为这些限制提供内置解决方案。同时，可以使用 Linux 软件包设置非 HA PostgreSQL 服务器，因为规格反映了这一点。

数据库服务的最佳实践

使用运行标准、性能良好的外部数据库服务，并支持 PostgreSQL 的支持版本。

如果您选择使用第三方外部服务：

HA Linux 软件包 PostgreSQL 设置包括 PostgreSQL、PgBouncer 和 Consul。当使用第三方外部服务时，这些组件不再需要。
HA 所需的节点数量可能会因服务而异。一个部署的要求可能与 Linux 软件包安装的要求不同。
为了获得最佳性能，使用具有读副本的数据库负载均衡。将节点数量与标准 Linux 软件包部署中使用的数量匹配。这种方法对较大的环境 (超过 200 每秒请求或 10,000+ 用户) 特别重要。
确保如果服务中包含了池，则它可以处理总负载而不会成为瓶颈。例如，Azure Database for PostgreSQL 弹性服务器可以选择在数据库前部署 PgBouncer 池。然而，PgBouncer 是单线程的，在负载较重的情况下可能导致瓶颈。为缓解此问题，您可以使用数据库负载均衡来在多个节点上分布池。
要使用极狐GitLab Geo，服务应支持跨区域复制。

不支持的数据库服务

以下数据库云提供商服务由于缺乏支持或已知问题不推荐使用：

Amazon Aurora 与极狐GitLab 不兼容且不支持。
Azure Database for PostgreSQL 单服务器不支持，因为该服务现已弃用，并运行在不支持的 PostgreSQL 版本上。它还存在显著的性能和稳定性问题。
Google AlloyDB 和 Amazon RDS 多可用区数据库集群未测试且不推荐。两个解决方案预计无法与极狐GitLab Geo 一起工作。
- Amazon RDS 多可用区数据库实例是一个独立产品并受支持。

Redis 服务的最佳实践

使用运行标准、性能良好的外部 Redis 服务。不要在集群模式下运行 Redis 服务，因为极狐GitLab 不支持。

Redis 主要是单线程的。对于目标高达 200 RPS 或 10,000 或更多用户的环境，分离实例为缓存和持久数据，以在该规模上实现最佳性能。

对象存储的最佳实践

极狐GitLab 已针对各种对象存储提供商进行了测试，预计正常工作。

使用具有完整 S3 兼容性的信誉良好的解决方案。

偏离建议的参考架构

您越偏离参考架构，就越难获得支持。每次偏离都会引入复杂性层，使潜在问题的故障排除更加复杂。

这些架构使用官方 Linux 软件包或 Helm Charts 来安装和配置各种组件。这些组件安装在单独的机器上 (虚拟化或裸金属)。机器硬件要求列在配置列中。每个可用架构的 GCP/AWS/Azure 列中列出了等效的 VM 标准大小。

您可以在 Docker 上运行极狐GitLab 组件，包括 Docker Compose。Docker 得到了良好的支持，并在环境之间提供了一致的规格。然而，它仍然是一个额外的层，可能会增加一些支持复杂性。例如，无法在容器中运行 strace。

不支持的设计

虽然我们努力为极狐GitLab 环境设计提供良好的支持范围，但某些方法无法有效工作。以下部分详细说明了这些不支持的方法。

Kubernetes 中的有状态组件

在 Kubernetes 中运行有状态组件，例如 Gitaly 集群，不支持。

Gitaly 集群仅支持在常规虚拟机上运行。Kubernetes 严格限制内存使用。然而，Git 的内存使用不可预测，这可能导致 Gitaly pod 的偶发内存不足 (OOM) 终止。OOM 终止导致显著的中断和潜在的数据丢失。因此，Gitaly 在 Kubernetes 中未经过测试或支持。有关更多信息，请参见 epic 6127。

这适用于有状态组件，例如 Postgres 和 Redis。您可以使用其他支持的云提供商服务，除非特别指出不支持。

有状态节点的自动缩放

作为一般指导，只有 无状态 的极狐GitLab 组件可以在自动缩放组中运行，即极狐GitLab Rails 和 Sidekiq。其他具有状态的组件，例如 Gitaly，不以这种方式支持。

这适用于有状态组件，例如 Postgres 和 Redis。您可以使用其他支持的云提供商服务，除非特别指出不支持。

云原生混合设置比自动缩放组更优选。Kubernetes 更好地处理只能在一个节点上运行的组件，例如数据库迁移和 Mailroom。

在多个数据中心部署一个环境

极狐GitLab 不支持在多个数据中心部署单个环境。这些设置可能导致显著问题，例如网络延迟或数据中心故障时的分裂脑场景。

几个极狐GitLab 组件需要奇数个节点才能正常运行，例如 Consul、Redis Sentinel 和 Praefect。在多个数据中心之间拆分这些组件可能会对其功能产生负面影响。

此限制适用于所有潜在的极狐GitLab 环境设置，包括云原生混合替代方案。

有关在多个数据中心或地区部署极狐GitLab，请参见极狐GitLab Geo 作为全面解决方案。

验证和测试结果

测试平台团队定期对这些架构进行烟雾和性能测试，以确保它们保持合规。

我们为什么进行测试

质量部门测量和提高极狐GitLab 的性能。他们创建并验证架构，以确保私有化部署用户的可靠配置。

我们如何进行测试

测试针对所有架构和云提供商以自动化和临时方式进行。使用两个工具进行测试：

极狐GitLab 环境工具包的 Terraform 和 Ansible 脚本用于构建环境。
极狐GitLab 性能工具用于性能测试。

所有云提供商上的测试环境之间的组件网络延迟测量结果为 <5 ms。这是观察结果，而不是建议。

我们希望采用 智能测试 方法，其中测试的架构范围良好，也可以适用于其他架构。测试重点在于安装 10k Linux 软件包在 GCP。这种方法作为其他架构、云提供商和云原生混合的可靠指标。

这些架构是跨平台的。所有内容都通过 Linux 软件包在虚拟机上运行。测试主要在 GCP 上进行。然而，它们在其他云提供商或在本地 (裸金属) 上运行的具有等效规格的硬件上表现相似。

极狐GitLab 使用极狐GitLab 性能工具对这些架构进行测试。我们使用基于样本客户数据的特定编码工作负载。选择与您的规模相匹配的架构。

每个端点类型都以以下每 1,000 用户的 RPS 数进行测试：

API：20 RPS
Web：2 RPS
Git（Pull）：2 RPS
Git（Push）：0.4 RPS（四舍五入到最接近的整数）

上述 RPS 目标是基于实际客户数据选择的，反映了与用户数量相对应的总环境负载，包括 CI 和其他工作负载。

成本计算器模板

下表列出了 GCP、AWS 和 Azure 不同架构的初始成本模板。这些成本是使用每个云提供商的官方计算器计算的。

但是，请注意以下注意事项：

表格仅列出了 Linux 软件包架构的大致计算模板。
它们没有考虑动态元素，如磁盘、网络或对象存储，这些因素会显著影响成本。
由于云原生混合架构的特性，无法给出该部署的静态成本计算。
如果云提供商计算器中设置了默认值，则适用承诺使用折扣。
这里也不包括裸机成本，因为它们因每种配置而异。

为了准确估算环境的成本，请选择最接近的模板，并根据您的规格和预期使用情况进行调整。

参考架构	GCP	AWS	Azure
参考架构	Linux 软件包	Linux 软件包	Linux 软件包
最多 20 RPS 或 1,000 个用户	计算成本	计算成本	计算成本
最多 40 RPS 或 2,000 个用户	计算成本	计算成本	计算成本
最多 60 RPS 或 3,000 个用户	计算成本	计算成本	计算成本
最多 100 RPS 或 5,000 个用户	计算成本	计算成本	计算成本
最多 200 RPS 或 10,000 个用户	计算成本	计算成本	计算成本
最多 500 RPS 或 25,000 个用户	计算成本	计算成本	计算成本
最多 1000 RPS 或 50,000 个用户	计算成本	计算成本	计算成本

维护参考架构环境

维护参考架构环境通常与其他极狐GitLab 环境相同。

在本节中，您可以找到相关领域的文档链接和特定架构说明。

扩展环境

参考架构设计为起点，具有弹性和可扩展性。在部署后，您可能希望根据具体需求调整环境，例如增加性能容量或降低成本。这种行为是预期的。如果指标表明某个组件已经耗尽，可以迭代扩展或整体升级到下一个架构大小。

如果某个组件的资源持续耗尽，请在执行任何重大扩展之前，联系我们的支持团队。

对于大多数组件，可以像往常一样进行垂直和水平扩展。然而，在进行扩展之前，请注意以下注意事项：

在垂直扩展 Puma 或 Sidekiq 时，必须调整工作者数量以使用额外的规格。Puma 在下次重新配置时会自动扩展。然而，您可能需要在此之前更改 Sidekiq 配置。
Redis 和 PgBouncer 主要是单线程的。如果这些组件出现 CPU 耗尽，可能需要水平扩展。
当以 HA 形式部署时，Consul、Redis Sentinel 和 Praefect 组件需要奇数节点数来进行投票仲裁。
大幅扩展某些组件可能会导致显著的连锁效应，影响环境的性能。有关更多指导，请参见扩展连锁效应。

相反，如果您有健全的指标显示环境过度配置，则可以缩减规模。在向下扩展时，您应该采取迭代的方法，以确保没有问题。

扩展连锁效应

在某些情况下，显著扩展组件可能会对下游组件产生连锁效应，影响性能。架构的设计考虑到了平衡，以确保依赖于彼此的组件在规格上是一致的。显著扩展组件可能会导致额外的吞吐量传递给其依赖的其他组件。因此，它们也可能需要扩展。

架构已设计为具有弹性以适应上游组件的扩展。然而，在对环境进行重大更改之前，请联系我们的支持团队以确保安全。

以下组件在显著扩展时可能会影响其他组件：

Puma 和 Sidekiq - 显著增加 Puma 或 Sidekiq 工作者将导致更高的并发连接到内部负载均衡器、PostgreSQL（如果存在通过 PgBouncer）、Gitaly（如果存在通过 Praefect）和 Redis。
- Redis 主要是单线程的。在某些情况下，如果增加的吞吐量导致 CPU 耗尽在集群中，可能需要将 Redis 拆分为单独的实例（例如，缓存和持久）。
- PgBouncer 也是单线程的，但扩展可能导致添加新的池，从而可能增加到 Postgres 的总连接。强烈建议只有在您有管理 Postgres 连接经验时才这样做，并在有疑问时寻求帮助。
Gitaly 集群 / PostgreSQL - 额外节点的显著扩展可能会对 HA 系统和性能产生负面影响，因为对主节点的复制调用增加。

从非 HA 架构扩展到 HA 架构

在大多数情况下，仅需垂直扩展以增加环境的资源。然而，如果您要转向 HA 环境，则需要为以下组件切换到其 HA 形式采取额外步骤。

有关更多信息，请参阅以下文档：

升级

升级参考架构环境与其他极狐GitLab 环境相同。主要的升级极狐GitLab部分有关于如何处理此问题的详细步骤。零停机时间升级也可用。

您应按创建参考架构的顺序进行升级。

监控

您可以使用各种选项监控您的基础设施和极狐GitLab。有关更多信息，请参阅所选监控解决方案的文档。

极狐GitLab 应用程序捆绑了 Prometheus 和各种与 Prometheus 兼容的导出器，可以集成到您的解决方案中。