Help us learn about your current experience with the documentation. Take the survey.

Gitaly 在 AWS 上的 SRE 考虑因素

  • 层级：Free, Premium, Ultimate
  • 提供：GitLab Self-Managed

Gitaly SRE 考虑因素

Gitaly 是一个用于 Git 仓库存储的嵌入式服务。GitLab 工程化了 Gitaly 和 Gitaly Cluster (Praefect)，以克服在使用开源 Git 二进制文件进行 GitLab 服务端水平扩展时面临的基本挑战。关于这个主题，这里有深入的技术阅读材料：

为什么构建了 Gitaly

如果您想了解 GitLab 为什么必须投入资源创建 Gitaly 的基本原理，请阅读以下简短的主题列表：

Gitaly 和 Praefect 选举

作为 Gitaly Cluster (Praefect) 一致性的一部分，Praefect 节点必须偶尔投票决定哪个数据副本最准确。这需要奇数个 Praefect 节点以避免僵局。这意味着对于高可用性（HA），Gitaly 和 Praefect 至少需要三个节点。

Gitaly 性能监控

应该收集 Gitaly 实例的完整性能指标以识别瓶颈，因为这些瓶颈可能与磁盘 IO、网络 IO 或内存有关。

Gitaly 性能指南

Gitaly 在 GitLab 中充当主要的 Git 仓库存储。然而，它不是一个流式文件服务器。它还执行大量要求高的计算工作，例如准备和缓存 Git packfile，这影响了以下一些性能建议。

所有建议都适用于生产配置，包括性能测试。对于测试配置，如培训或功能测试，您可以使用成本较低的选择。但是，如果性能出现问题，您应该进行调整或重建。

总体建议

  • 由于所有前述和后述特性，生产级 Gitaly 必须在实例计算上实现。
  • 永远不要为 Gitaly 使用 突发性能实例类型（如 t2、t3、t4g）。
  • 始终至少使用 AWS Nitro 代实例，以确保许多以下问题得到自动处理。
  • 使用 Amazon Linux 2，以确保所有 AWS 硬件和操作系统优化 都得到最大化，无需额外配置或 SRE 管理。

CPU 和内存建议

GitLab Gitaly 节点在 CPU 和内存方面的通用建议假设跨仓库的负载相对均衡。对任何非特征仓库进行 GitLab Performance Tool (GPT) 测试和/或对 Gitaly 指标进行 SRE 监控，可能会提示何时选择高于通用建议的内存和/或 CPU。

为适应:

  • Git packfile 操作是内存和 CPU 密集型的。
  • 如果仓库提交流量密集、量大或非常频繁，则需要更多的 CPU 和内存来处理负载。存储二进制文件和/或繁忙或大型 monorepo 等模式是可能导致高负载的例子。

磁盘 I/O 建议

  • 仅使用 SSD 存储和符合您的耐用性和速度要求的 弹性块存储 (EBS) 存储类别。
  • 当不使用预配置的 EBS IO 时，EBS 卷大小决定 I/O 级别，因此提供远大于所需大小的卷可能是提高 EBS IO 的最经济方法。
  • 如果 Gitaly 性能监控显示磁盘压力迹象，则可以选择一个预配置的 IOPS 级别。EBS IOPS 级别还具有增强的耐用性，除了性能考虑外，某些实现可能也会对此感兴趣。

为适应:

  • Gitaly 存储应该是本地的（不包括任何类型的 NFS，包括 EFS）。
  • Gitaly 服务器还需要磁盘空间来构建和缓存 Git packfile。这超出了 Git 仓库的永久存储空间。
  • Git packfile 在 Gitaly 中缓存。在临时磁盘上创建 packfile 得益于快速磁盘，而 packfile 的磁盘缓存则得益于充足的磁盘空间。

网络 I/O 建议

  • 仅使用支持 弹性网络适配器 (ENA) 高级网络 的实例类型列表中的实例，以确保集群复制延迟不是由实例级网络 I/O 瓶颈引起的。
  • 选择大小超过 10 Gbps 的实例 - 但仅在需要时，并且仅在通过监控和/或压力测试证明存在节点级网络瓶颈时。

为适应:

  • Gitaly 节点负责推送和拉取操作（添加开发端点和 CI/CD）的仓库流式传输的主要工作。
  • 为了使集群保持操作和数据完整性，Gitaly 服务器需要在集群节点之间以及与 Praefect 服务之间具有合理的低延迟。
  • 选择 Gitaly 节点时应将避免网络瓶颈作为主要考虑因素。
  • 应监控 Gitaly 节点的网络饱和情况。
  • 并非所有网络问题都可以通过优化节点级网络来解决：
    • Gitaly Cluster (Praefect) 节点复制依赖于节点之间的所有网络连接。
    • Gitaly 到拉取和推送端点的网络性能依赖于中间的所有网络连接。

AWS Gitaly 备份

由于 Praefect 跟踪 Gitaly 磁盘信息复制元数据的方式，最佳备份方法是 官方的备份和恢复 Rake 任务。

AWS Gitaly 恢复

Gitaly Cluster (Praefect) 不支持快照备份，因为这可能导致 Praefect 数据库与磁盘存储不同步的问题。由于 Praefect 在恢复过程中重建 Gitaly 磁盘信息复制元数据的方式，最佳恢复方法是 官方的备份和恢复 Rake 任务。

Gitaly 长期管理

必须监控和增加 Gitaly 节点的磁盘大小，以适应 Git 仓库的增长以及 Gitaly 临时和缓存存储的需求。所有节点的存储配置应保持一致。