Reference architectures

原文：https://docs.gitlab.com/ee/administration/reference_architectures/

Reference architectures

您可以在单个服务器上设置 GitLab 或扩展它以服务许多用户. 本页详细介绍了由 GitLab 的质量和支持团队构建和验证的推荐参考架构.

下面的图表表示每个体系结构层及其可处理的用户数量. 随着用户数量的增长，建议您相应地调整 GitLab.

Reference Architectures

这些参考架构的测试是使用GitLab 的 Performance Tool在特定的编码工作负载下进行的，用于测试的吞吐量是根据样本客户数据计算得出的. 选择适合您规模的参考架构后，请参考将GitLab 配置为可缩放以查看所涉及的组件以及如何配置它们.

每 1000 个用户使用以下每秒请求数（RPS）测试每种端点类型：

  • API：20 RPS
  • 网络：2 RPS
  • 转到：2 RPS

对于用户数少于 2,000 的 GitLab 实例，建议您通过在单个计算机上安装 GitLab来使用默认设置 ，以最大程度地减少维护和资源成本.

如果您的组织有 2000 多名用户，则建议将 GitLab 的组件扩展到多个机器节点. 机器节点按组件分组. 这些节点的增加提高了您的 GitLab 实例的性能和可伸缩性.

扩展 GitLab 时，需要考虑以下几个因素：

  • 多个应用程序节点来处理前端流量.
  • 前面添加了一个负载均衡器，以在应用程序节点之间分配流量.
  • 应用程序节点连接到共享文件服务器以及后端的 PostgreSQL 和 Redis 服务.

注意：根据您的工作流程，以下建议的参考体系结构可能需要进行相应的调整. 您的工作负载受以下因素影响，这些因素包括用户的活跃程度，使用的自动化程度，镜像和存储库/更改大小. 此外，显示的内存值由GCP 机器类型提供 . 对于不同的云供应商，请尝试选择最匹配所提供架构的选项.

Available reference architectures

提供以下参考体系结构：

Availability Components

GitLab 随附以下组件供您使用，从最小到最复杂列出：

  1. Automated backups
  2. Traffic load balancer
  3. Zero downtime updates
  4. Automated database failover
  5. Instance level replication with GitLab Geo

在实现这些组件时，请从单个服务器开始，然后再进行备份. 仅在完成第一台服务器后，才可以继续执行下一个.

此外，不为 GitLab 实施额外的服务器并不一定意味着您将有更多的停机时间. 根据您的需求和经验水平，单个服务器可以为用户带来更多实际的正常运行时间.

Automated backups

该解决方案适用于具有默认 GitLab 安装的许多团队. 通过自动备份 GitLab 存储库，配置和数据库，如果您没有严格的要求，这可能是最佳的解决方案. 自动备份的设置最简单. 这提供了预定时间表的时间点恢复.

Traffic load balancer

这需要使用添加的负载平衡器将 GitLab 分离为多个应用程序节点. 负载平衡器将在 GitLab 应用程序节点之间分配流量. 同时，每个应用程序节点都连接到后端的共享文件服务器和数据库系统. 这样，如果其中一台应用程序服务器发生故障，则工作流不会中断. 建议使用HAProxy作为负载平衡器.

与默认安装相比，有了此添加的组件，您具有许多优点：

  • 增加用户数量.
  • 启用零停机时间升级.
  • 提高可用性.

Zero downtime updates

GitLab 支持零停机时间更新 . 尽管您可以使用单个 GitLab 节点执行零停机时间更新，但是建议将 GitLab 分为几个应用程序节点. 只要每个组件中的至少一个在线且能够处理实例的使用负载，您的团队的生产力就不会在更新期间被打断.

Automated database failover

  • 复杂程度： 高
  • 必需的领域知识：PgBouncer，Repmgr 或 Patroni，共享存储，分布式系统
  • 支持的级别： GitLab Premium 和 Ultimate

通过为数据库系统添加自动故障转移，可以通过其他数据库节点来提高正常运行时间. 这将使用群集管理和故障转移策略扩展默认数据库. 建议将 PgBouncer 与 Repmgr 或 Patroni 结合使用 .

Instance level replication with GitLab Geo

GitLab Geo允许您将 GitLab 实例复制到其他地理位置，作为只读的完全可操作实例，如果发生灾难，也可以升级它.

Configure GitLab to scale

Note: From GitLab 13.0, using NFS for Git repositories is deprecated. In GitLab 14.0, support for NFS for Git repositories is scheduled to be removed. Upgrade to Gitaly Cluster as soon as possible.

以下组件是您需要配置以扩展 GitLab 的组件. 如果您选择的参考体系结构要求它们，则按照通常配置它们的顺序列出它们.

它们大多数捆绑在 GitLab deb / rpm 软件包（称为 Omnibus GitLab）中，但是根据您的系统架构，您可能需要其中未包含的某些组件. 如果需要，应在设置 GitLab 提供的组件之前对其进行配置. 配置说明列中提供了有关如何为您的组织选择正确的解决方案的建议.

Component Description 配置说明 与 Omnibus GitLab 捆绑在一起
负载均衡器（ 6 ） 处理负载平衡，通常在您有多个 GitLab 应用程序服务节点时 Load balancer configuration (6) No
对象存储服务（ 4 ） 推荐的共享数据对象存储 Object Storage configuration No
NFS（ 5 ）（ 7 ） 共享磁盘存储服务. 可以用作备用对象存储. GitLab 页面必需 NFS configuration No
Consul (3) Service discovery and health checks/failover Consul configuration Yes
PostgreSQL Database PostgreSQL configuration Yes
PgBouncer 数据库连接池 PgBouncer configuration Yes
Repmgr PostgreSQL 集群管理和故障转移 PostgreSQL and Repmgr configuration Yes
Patroni 替代的 PostgreSQL 集群管理和故障转移 PostgreSQL and Patroni configuration Yes
Redis (3) 键/值存储，用于快速查找和缓存数据 Redis configuration Yes
Redis 前哨 Redis Redis Sentinel configuration Yes
吉塔利 （ 2 ）（ 7 ） 提供对 Git 存储库的访问 Gitaly configuration Yes
Sidekiq 异步/后台作业 Sidekiq configuration Yes
GitLab application services(1) Puma / Unicorn，Workhorse，GitLab Shell-服务于前端请求（UI，API，基于 HTTP / SSH 的 Git） GitLab app scaling configuration Yes
Prometheus and Grafana GitLab 环境监控 Monitoring node for scaling Yes

Configuring select components with Cloud Native Helm

我们还提供Helm 图表作为 GitLab 的 Cloud Native 安装方法. 对于参考体系结构，如果需要，可以以这种方式设置选择组件.

对于此类设置，我们支持在高级配置中使用图表，在这些高级配置中 ，有状态后端组件（例如数据库或 Gitaly）可通过 Omnibus 或信誉良好的第三方服务在外部运行. 请注意，我们目前不支持通过 Helm 大规模运行有状态组件.

设计这些环境时，应参考上面的相应参考体系结构以获取有关大小调整的指导. 通过 Helm 运行的组件将按类似比例缩放到其 Omnibus 规格，仅转换为 Kubernetes 资源.

例如，如果您要设置一个 50k 的安装，并且 Rails 节点在 Helm 中运行，那么应该为 Kubernetes 集群提供与 Omnibus 相同数量的资源，并且将 Rails 节点分解为多个较小的 Pod 跨集群.

Footnotes

  1. 在我们的体系结构中，我们使用 Puma Web 服务器运行每个 GitLab Rails 节点，并将其工作程序数量设置为 90％的可用 CPU 以及四个线程. 对于运行带有其他组件的 Rails 的节点，应该相应地降低 worker 的值，我们发现 50％达到了很好的平衡，但这取决于工作量.

  2. Gitaly 节点的要求取决于客户数据，特别是项目数量及其规模. 我们建议每个 Gitaly 节点应存储不超过 5TB 的数据，并且将gitaly-ruby工作者的数量设置为可用 CPU 的 20％. 根据以上建议，应结合其他节点并结合对预期数据大小和分布的审查.

  3. 推荐的 Redis 设置因架构的大小而异. 对于较小的体系结构（少于 3000 个用户），一个实例就足够了. 对于中型安装（3,000-5,000），我们建议为所有课程使用一个 Redis 集群，并且 Redis Sentinel 与 Consul 一起托管. 对于较大的体系结构（10,000 个或更多用户），我们建议分别为 Cache 类和队列和 Shared State 类运行一个单独的Redis 群集 . 我们还建议您为每个 Redis 群集分别运行 Redis Sentinel 群集.

  4. 对于 LFS，Uploads，Artifacts 等数据对象.由于性能更好，我们建议尽可能在 NFS 上使用对象存储服务 .

  5. NFS 可以用作对象存储的替代方法，但是出于性能考虑，通常不建议使用 NFS. 请注意，但是GitLab Pages是必需的.

  6. 我们的架构已通过HAProxy作为负载均衡器进行了测试和验证. 尽管也可以使用具有类似功能集的其他负载均衡器，但这些负载均衡器尚未经过验证.

  7. 我们强烈建议为任何 Gitaly 或 NFS 节点设置 HDD 之上的 SSD 磁盘，其读操作的吞吐量至少为 8000 IOPS，写操作的吞吐量至少为 2,000 IOPS，因为这些组件的 I / O 繁重. 这些 IOPS 值仅建议作为启动器使用，因为随着时间的推移，它们可能会根据环境工作负载的规模而调整得更高或更低. 如果您正在 Cloud provider 上运行环境，则可能需要参考其文档以了解如何正确配置 IOPS.

  8. 这些架构是使用 GCP 上的Intel Xeon E5 v3（Haswell） CPU 平台构建和测试的. 在不同的硬件上，您可能会发现需要对 CPU 或节点数进行相应的调整，无论是较低还是较高. 有关更多信息，请在此处找到 CPU 的Sysbench基准.