Reference architecture: up to 1,000 users

Reference architecture: up to 1,000 users

该页面描述了最多可容纳 1,000 位用户的 GitLab 参考架构. 有关参考架构的完整列表，请参见可用参考架构 .

  • 支持的用户（大约）： 1,000
  • 高可用性： False

除上述之外，即使您当前有足够的可用 RAM，我们也建议您在服务器上至少有 2GB 的交换空间. 如果您的可用内存发生更改，那么进行交换将有助于减少发生错误的机会. 我们还建议将内核的 swappiness 设置配置为较低的值（例如以充分利用您的 RAM，同时在需要时仍可使用交换功能.

对于需要服务多达 1,000 个用户的情况，具有的单节点解决方案适用于许多组织. 通过自动备份 GitLab 存储库，配置和数据库，如果您对可用性没有严格的要求，这是理想的解决方案.

  • 对于此默认参考体系结构，请使用标准安装说明来安装 GitLab.

Footnotes

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

  2. Recommended Redis setup differs depending on the size of the architecture. For smaller architectures (less than 3,000 users) a single instance should suffice. For medium sized installs (3,000 - 5,000) we suggest one Redis cluster for all classes and that Redis Sentinel is hosted alongside Consul. For larger architectures (10,000 users or more) we suggest running a separate Redis Cluster for the Cache class and another for the Queues and Shared State classes respectively. We also recommend that you run the Redis Sentinel clusters separately for each Redis Cluster.

  4. NFS 可以用作存储库数据（替代 Gitaly）和对象存储的替代方法，但是出于性能原因，通常不建议使用 NFS. 请注意，但是是必需的.

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