Reference architecture: up to 50,000 users

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

• Footnotes

Reference architecture: up to 50,000 users

此页面描述了多达 50,000 个用户的 GitLab 参考架构. 有关参考架构的完整列表，请参见可用参考架构 .

• 支持的用户（大约）： 50,000
• 高可用性： True
• 测试 RPS 速率： API：1000 RPS，网站：100 RPS，Git：100 RPS

Footnotes

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

2. Gitaly node requirements are dependent on customer data, specifically the number of projects and their sizes. We recommend two nodes as an absolute minimum for HA environments and at least four nodes should be used when supporting 50,000 or more users. We also recommend that each Gitaly node should store no more than 5TB of data and have the number of gitaly-ruby workers set to 20% of available CPUs. Additional nodes should be considered in conjunction with a review of expected data size and spread based on the recommendations above.

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 可以用作存储库数据（替代 Gitaly）和对象存储的替代方法，但是出于性能原因，通常不建议使用 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基准.