Reference architecture: up to 10,000 users

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

• Footnotes

Reference architecture: up to 10,000 users

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

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

Footnotes

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

2. Gitaly 节点的要求取决于客户数据，特别是项目数量及其规模. 对于 HA 环境，我们建议绝对最少使用两个节点，并且在支持 50,000 个或更多用户时，至少应使用四个节点. 我们还建议每个 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 可以用作存储库数据（替代 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基准.