Replication (Geo)

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

• Overview
• Use cases
• How it works
  • Architecture
• Requirements for running Geo
  • Firewall rules
  • LDAP
  • Geo Tracking Database
  • Geo Log Cursor
• Setup instructions
  • Using Omnibus GitLab
• Post-installation documentation
  • Configuring Geo
  • Updating Geo
  • Pausing and resuming replication
  • Configuring Geo for multiple nodes
  • Configuring Geo with Object Storage
  • Disaster Recovery
  • Replicating the Container Registry
  • Security Review
  • Tuning Geo
  • Set up a location-aware Git URL
• Remove Geo node
• Disable Geo
• Current limitations
  • Limitations on replication/verification
• Frequently Asked Questions
• Log files
• Troubleshooting

Replication (Geo)

版本历史

• 在 GitLab 企业版 8.9 中引入.
• 与组合使用地理多节点架构在考虑一般可用 （GA） GitLab 高级 10.4.

使用 Geo 复制是广泛分布的开发团队的解决方案.

Overview

对于远离单个 GitLab 实例的团队而言，获取大型存储库可能需要很长时间.

Geo 提供您的 GitLab 实例的本地只读实例. 这样可以减少克隆和获取大型存储库所需的时间，从而加快开发速度.

注意：在设置 Geo 之前，请仔细检查要求 .

有关 Geo 的视频介绍，请参见GitLab Geo-GitLab 功能介绍 .

注意：从发布到发布，Geo 进行了重大更改. 支持升级和记录 ，但你应该确保您使用的文件的正确的版本进行安装.

为确保您使用的文档版本正确，请在 GitLab.com 上导航至此页面的源版本 ，然后从Switch 分支/标签下拉列表中选择适当的版本. 例如， v11.2.3-ee .

Use cases

实施 Geo 具有以下好处：

• 将分布式开发人员克隆和获取大型存储库和项目所需的时间从几分钟减少到几秒钟.
• 无论您身在何处，都可以使所有开发人员共同贡献想法并并行工作.
• 平衡主节点和辅助节点之间的只读负载.

此外，它：

• 除读取 GitLab Web 界面中可用的任何数据外，还可用于克隆和获取项目（请参阅当前限制 ）.
• 克服远程办公室之间的慢速连接，通过提高分布式团队的速度来节省时间.
• 帮助减少自动任务，自定义集成和内部工作流程的加载时间.
• 可以在灾难恢复方案中快速故障转移到辅助节点.
• 允许计划的故障转移到辅助节点.

地理位置提供：

• 只读辅助节点：维护一个主 GitLab 节点，同时仍为每个分布式团队启用只读辅助节点.
• 身份验证系统挂钩： 辅助节点从主实例接收所有身份验证数据（例如用户帐户和登录名）.
• 直观的用户界面： 辅助节点使用团队已习惯的相同 Web 界面. 此外，还有可视通知会阻止写操作，并清楚表明用户在辅助节点上.

How it works

除了读取任何数据外，您的 Geo 实例还可用于克隆和获取项目. 这将使在较大距离上使用大型存储库的速度更快.

启用地理位置后，：

• 原始实例称为主要节点.
• 复制的只读节点称为辅助节点.

请记住：

• 辅助节点与主节点对话以：
  • 获取用于登录的用户数据（API）.
  • 复制存储库，LFS 对象和附件（HTTPS + JWT）.
• 从 GitLab Premium 10.0 开始， 主节点不再与辅助节点对话以通知更改（API）.
• GitLab Premium 11.3 中引入了直接推送到辅助节点（对于 HTTP 和 SSH，包括 Git LFS）.
• 当前的实施存在局限性 .

Architecture

下图说明了 Geo 的基础体系结构.

在此图中：

• 有主节点和一个辅助节点的详细信息.
• 只能在主节点上执行对数据库的写入. 辅助节点通过 PostgreSQL 流复制接收数据库更新.
• 如果存在，则应将LDAP 服务器配置为针对灾难恢复方案进行复制.
• 辅助节点使用受 JWT 保护的特殊授权对主要节点执行不同类型的同步：
  • 存储库是通过 HTTPS 上的 Git 克隆/更新的.
  • 使用专用 API 端点通过 HTTPS 下载附件，LFS 对象和其他文件.

从用户执行 Git 操作的角度来看：

• 主节点的行为就像一个完整的读写 GitLab 实例.
• 辅助节点是只读的，但代理 Git 将操作推送到主节点. 这使得辅助节点似乎本身就支持推送操作.

为了简化该图，省略了一些必要的组件. 注意：

• SSH 上的 Git 需要gitlab-shell和 OpenSSH.
• 通过 HTTPS 进行 Git 时需要gitlab-workhorse .

请注意， 辅助节点需要两个不同的 PostgreSQL 数据库：

• 一个只读数据库实例，用于从 GitLab 主数据库中流式传输数据.
• 辅助节点在内部使用的另一个数据库实例记录已复制的数据.

在辅助节点中，还有一个附加的守护进程： Geo Log Cursor .

Requirements for running Geo

要运行 Geo，必须具备以下条件：

• 支持 OpenSSH 6.9+的操作系统（需要在数据库中快速查找授权的 SSH 密钥 ）当前已知版本的 OpenSSH 随附了以下操作系统：
  • CentOS 7.4 以上
  • Ubuntu 16.04 以上
• PostgreSQL 11+ with FDW support and Streaming Replication
• 转到 2.9+
• 所有节点必须运行相同的 GitLab 版本.

此外，请检查 GitLab 的最低要求 ，我们建议您使用：

• 至少具有 GitLab 企业版 10.0 的基本地理功能.
• 最新版本以获得更好的体验.

Firewall rules

下表列出了在 Geo 的主节点和辅助节点之间必须打开的基本端口.

在Package 默认值中查看 GitLab 使用的端口的完整列表

注意： Web 终端支持要求您的负载平衡器正确处理 WebSocket 连接. 当使用 HTTP 或 HTTPS 代理，负载平衡器必须被配置为通过Connection和Upgrade逐跳头. 有关更多详细信息，请参见Web 终端集成指南.注意：将 HTTPS 协议用于端口 443 时，您需要向负载均衡器添加 SSL 证书. 如果您想在 GitLab 应用程序服务器上终止 SSL，请使用 TCP 协议.

LDAP

We recommend that if you use LDAP on your primary node, you also set up secondary LDAP servers on each secondary node. Otherwise, users will not be able to perform Git operations over HTTP(s) on the secondary node using HTTP Basic Authentication. However, Git via SSH and personal access tokens will still work.

注意：所有辅助节点都可以共享 LDAP 服务器，但是额外的延迟可能是一个问题. 另外，如果将辅助节点提升为主要节点，请考虑在灾难恢复方案中将使用哪些 LDAP 服务器.

查看有关如何在 LDAP 服务中设置复制的说明. 根据使用的软件或服务，说明会有所不同. 例如，OpenLDAP 提供了这些说明 .

Geo Tracking Database

跟踪数据库实例用作元数据，以控制需要在本地实例的磁盘上更新的内容. 例如：

• 下载新资产.
• 提取新的 LFS 对象.
• 从最近更新的存储库中获取更改.

因为复制的数据库实例是只读的，所以每个辅助节点都需要这个额外的数据库实例. 跟踪数据库需要postgres_fdw扩展名.

Geo Log Cursor

该守护程序：

• 读取由主节点复制到辅助数据库实例的事件的日志.
• 使用需要执行的更改更新地理跟踪数据库实例.

在跟踪数据库实例中将某些内容标记为要更新时，在辅助节点上运行的异步作业将执行所需的操作并更新状态.

这种新的体系结构使 GitLab 能够应对节点之间的连接问题. 辅助节点与主节点断开连接的时间无关紧要，因为它将能够以正确的顺序重放所有事件并再次与主节点同步.

Setup instructions

这些说明假定您有一个 GitLab 的工作实例. 他们指导您：

1. 将现有实例设为主要节点.
2. Adding secondary nodes.

Caution: The steps below should be followed in the order they appear. 确保所有节点上的 GitLab 版本均相同.

Using Omnibus GitLab

如果您使用 Omnibus 软件包安装了 GitLab（强烈建议）：

1. 在将用作辅助节点的服务器上安装 GitLab 企业版 . 不要创建帐户或登录到新的辅助节点.
2. 在主节点上载 GitLab 许可以解锁 Geo. 该许可证必须适用于GitLab Premium或更高版本.
3. Set up the database replication (primary (read-write) <-> secondary (read-only) topology).
4. 在数据库中配置快速查找授权的 SSH 密钥 . 此步骤是必需的，并且必须同时在主节点和辅助节点上完成.
5. 配置 GitLab以设置主节点和辅助节点.
6. 可选：为辅助节点配置辅助 LDAP 服务器 . 请参阅LDAP 上的注释 .
7. Follow the “Using a Geo Server” guide.

Post-installation documentation

在辅助节点上安装 GitLab 并执行初始配置后，请参阅以下文档以获取安装后信息.

Configuring Geo

有关配置 Geo 的信息，请参见Geo 配置 .

Updating Geo

有关如何将 Geo 节点更新到最新的 GitLab 版本的信息，请参见更新 Geo 节点 .

Pausing and resuming replication

Introduced in GitLab Premium 13.2.

在某些情况下，例如在升级或计划的故障转移期间，最好暂停主数据库和辅助数据库之间的复制.

暂停和恢复复制是通过辅助节点上的命令行工具完成的.

暂停：（从中学开始）

gitlab-ctl geo-replication-pause

恢复：（从中学开始）

gitlab-ctl geo-replication-resume

Configuring Geo for multiple nodes

有关为多个节点配置 Geo 的信息，请参阅针对多个服务器的 Geo .

Configuring Geo with Object Storage

有关配置带对象存储的 Geo 的信息，请参阅带对象存储的 Geo .

Disaster Recovery

有关在灾难恢复情况下使用 Geo 减轻数据丢失和恢复服务的信息，请参阅灾难恢复 .

Replicating the Container Registry

有关如何复制 Container Registry 的更多信息，请参阅辅助节点的 Docker Registry .

Security Review

有关地理安全的更多信息，请参阅地理安全审阅 .

Tuning Geo

有关调整 Geo 的更多信息，请参见调整 Geo .

Set up a location-aware Git URL

有关如何使用 AWS Route53 设置位置感知的 Git 远程 URL 的示例，请参阅使用 AWS Route53 感知位置的 Git 远程 URL .

Remove Geo node

For more information on removing a Geo node, see Removing secondary Geo nodes.

Disable Geo

要了解如何禁用地理位置，请参阅禁用地理位置 .

Current limitations

注意：此限制列表仅反映最新版本的 GitLab. 如果您使用的是旧版本，则可能存在其他限制.

• 将请求直接推送到辅助节点（对于 HTTP）或代理（对于 SSH）​​会将请求重定向到主要节点，而不是直接处理它 ，除非在 HTTP 中使用 Git over HTTP 并在 URI 中嵌入凭据. 例如， https://user:password@secondary.tld .
• 克隆，拉动或推送存在于主节点上但不存在于辅助节点上的存储库，这些存储库中的选择性同步不包括项目，因此不支持通过 SSH 进行， 但已计划进行支持 . 支持 HTTP（S）.
• 主节点必须在线才能进行 OAuth 登录. 现有会话和 Git 均不受影响. 正在计划支持辅助节点使用独立于主节点的 OAuth 提供程序.
• 安装过程需要执行多个手动步骤，根据具体情况，总共可能需要一个小时的时间. 我们正在努力改善这种体验. 有关详细信息，请参见Omnibus GitLab 第 2978期.
• 问题/合并请求的实时更新（例如，通过长轮询）在辅助节点上不起作用.
• 选择性同步仅适用于文件和存储库. 其他数据集已完全复制到辅助节点，使其不适合用作访问控制机制.
• 用于分支项目重复数据删除的对象池仅在主节点上工作，并在辅助节点上重复.
• 如果外部合并请求差异在磁盘上，则将不会复制它们，并且查看合并请求将失败. 但是，支持对象存储中的外部 MR 差异. 默认配置（数据库中）起作用.
• GitLab Runners 无法向辅助节点注册. 计划在将来对此提供支持.

Limitations on replication/verification

您可以跟踪实现这些史诗/问题中缺少的项目的进度：

• Unreplicated Data Types
• Verify all replicated data

这里有所有 GitLab 数据类型的完整列表以及对复制和验证的现有支持 .

Frequently Asked Questions

有关常见问题的答案，请参见地理位置常见问题解答 .

Log files

自 GitLab 9.5 起，Geo 将结构化日志消息存储在geo.log文件中. 对于 Omnibus 安装，此文件位于/var/log/gitlab/gitlab-rails/geo.log .

该文件包含有关 Geo 何时尝试同步存储库和文件的信息. 文件中的每一行都包含一个可以提取的单独的 JSON 条目. 例如，Elasticsearch 或 Splunk.

例如：

{"severity":"INFO","time":"2017-08-06T05:40:16.104Z","message":"Repository update","project_id":1,"source":"repository","resync_repository":true,"resync_wiki":true,"class":"Gitlab::Geo::LogCursor::Daemon","cursor_delay_s":0.038}

此消息表明，Geo 检测到项目1需要存储库更新.

Troubleshooting

有关故障排除步骤，请参阅地理故障排除 .