Geo
- Tier: 专业版,旗舰版
- Offering: 私有化部署
极狐GitLab Geo 是为广泛分布的开发团队提供解决方案,并作为灾难恢复策略的一部分提供热备份。Geo 不是一种现成的高可用性解决方案。
为了确保您使用正确版本的文档,请访问JihuLab.com 上的 Geo 页面,并从 Switch branch/tag 下拉列表中选择适当的发布版本。
对于远离单个极狐GitLab 实例的团队和 runner 来说,获取大型代码库可能需要很长时间。
Geo 提供了可以地理上靠近远程团队的本地缓存,可以处理读取请求。这可以减少克隆和获取大型代码库的时间,加快开发速度,提高远程团队的生产力。
Geo 次要站点透明地将写请求代理到主要站点。所有 Geo 站点都可以配置为响应单个极狐GitLab URL,以提供一致、无缝和全面的体验,无论用户登陆哪个站点。
Geo 使用一组定义的术语,这些术语在Geo 词汇表中进行了描述。请确保熟悉这些术语。
用例
实施 Geo 可解决多个用例。本节提供了一些预期的用例,并突出了其优势。
区域灾难恢复
作为灾难恢复解决方案,Geo 为您提供一个与主要站点位于不同区域的热备份次要站点。数据持续同步到次要站点,确保其始终保持最新状态。在数据中心或网络中断或硬件故障等灾难发生时,您可以切换到一个完全运行的次要站点。您可以通过计划的故障切换测试您的灾难恢复流程和基础设施。
优势:
- 在区域性灾难事件中确保业务连续性。
- 低恢复时间目标 (RTO) 和恢复点目标 (RPO)。
- 使用极狐GitLab 环境工具包 (GET) 进行自动化(但不是自动)故障切换。
- 最小化操作努力——无辅助的持续复制和验证确保次要站点保持最新,并且传输和静止的数据不会被损坏。
远程团队加速
在地理位置上靠近您的远程团队建立 Geo 次要站点,以提供加速读取操作的本地缓存。您可以拥有多个 Geo 次要站点,每个站点仅同步您的远程团队需要的项目。透明代理和具有统一 URL的地理路由确保一致且无缝的开发者体验。
优势:
- 改善地理分布团队的极狐GitLab 体验。Geo 在次要站点提供完整的极狐GitLab 体验:维护一个主要的极狐GitLab 站点,同时为次要站点提供读写访问和完整的用户界面体验。
- 将分布式开发者克隆和获取大型代码库和项目所需的时间从分钟减少到秒。
- 使所有开发者能够贡献想法并进行并行工作,无论他们身处何地。
- 在主要和次要站点之间平衡读取负载。
- 克服远距离办公室之间的慢速连接,通过提高速度为分布团队节省时间。
- 减少自动化任务、定制集成和内部工作流程的加载时间。
CI/CD 流量卸载
您可以配置您的 CI/CD runner 从Geo 次要站点克隆。您可以根据 runner 工作负载的需求调整次要站点,而无需镜像主要站点。受支持的读取请求由次要站点上的缓存数据提供服务,当次要站点上的数据过时或不可用时,请求透明地转发到主要站点。
优势:
- 在主要站点上,通过将流量转移到次要站点来减少 CI/CD 流量对用户体验的影响。
- 减少跨区域流量,并在对您的组织最经济的地方定位 CI/CD 计算时间。创建一个跨区域的数据副本,并使其可用于次要站点的重复读取请求。
附加用例
基础设施迁移
您可以使用 Geo 迁移到新基础设施。如果您将极狐GitLab 实例移至新服务器或数据中心,使用 Geo 在后台将极狐GitLab 数据迁移到新实例,同时旧实例继续为用户服务。任何对活动极狐GitLab 数据的更改都会复制到您的新实例,因此在切换期间不会有数据丢失。
不能使用 Geo 从一个操作系统迁移 PostgreSQL 数据库到另一个操作系统。请参阅升级 PostgreSQL 的操作系统。
优势:
- 与备份和恢复迁移方法相比,显著减少迁移期间的停机时间。在后台复制数据到新实例,而不必在切换停机窗口之前停止活动极狐GitLab 实例。
迁移到极狐GitLab 专属版
您还可以使用 Geo 将极狐GitLab 私有化部署迁移到极狐GitLab 专属版。迁移到极狐GitLab 专属版类似于基础设施迁移。
优势:
- 更顺利的入职体验,显著降低停机时间。在数据迁移过程中,您的团队可以继续使用极狐GitLab 私有化部署。
Geo 未设计用于解决的问题
Geo 并未设计用于解决所有用例。本节提供了 Geo 不适用的用例示例。
强制执行数据导出合规性
虽然 Geo 的选择性同步功能允许您限制同步到次要站点的项目,但其设计目的是减少跨区域流量和存储需求,而不是强制执行导出合规性。您必须根据解决方案和文档独立确定您在隐私、网络安全和适用的贸易控制法律方面的法律义务。解决方案和文档均可能发生变化。
提供访问控制
Geo 的只读次要站点功能不是一流的功能,将来可能不再支持。您不应该依赖此功能用于访问控制目的。极狐GitLab 提供身份验证和授权控制,可以更好地服务于此目的。
零停机升级的替代方案
Geo 不是零停机升级的解决方案。您必须先升级主要 Geo 站点,然后再升级次要站点。
防止恶意或无意的损坏
Geo 将主要站点的损坏复制到所有次要站点。为了防止恶意或无意的损坏,您应该使用备份来补充 Geo。
主动-主动高可用配置
Geo 设计为主动-被动的高可用解决方案。它运行一个最终一致的同步模型,这意味着次要站点与主要站点没有紧密同步。次要站点跟随主要站点有一个小延迟,这可能导致灾难发生后少量数据丢失。灾难发生时切换到次要站点需要人工干预。然而,在将次要站点提升为主要站点的过程中,GitLab 环境工具包 (GET) 自动化了大部分流程,前提是您使用 GET 部署所有站点。
Gitaly 集群
Geo 不应与 Gitaly 集群混淆。有关 Geo 和 Gitaly 集群之间的区别的更多信息,请参阅与 Geo 比较。
工作原理
这是关于 Geo 在极狐GitLab 环境中工作原理的简要总结。有关详细信息,请参阅Geo 开发页面。
您的 Geo 实例不仅可用于克隆和获取项目,还可以用于读取任何数据。这使得在大距离上处理大型代码库的速度更快。

启用 Geo 时:
- 原始实例被称为 主要站点。
- 复制站点被称为 次要站点。
请记住:
- 次要站点与 主要站点通信以:
- 获取登录的用户数据(API)。
- 复制代码库、LFS 对象和附件(HTTPS + JWT)。
- 主要站点与 次要站点通信以查看复制详细信息。主要站点对 次要站点进行 GraphQL 查询以获取同步和验证数据(API)。
- 您可以直接推送到 次要站点(无论是 HTTP 还是 SSH,包括 Git LFS),它会将请求代理到 主要站点。
- 使用 Geo 时存在一些已知问题。
架构
以下图表展示了 Geo 的底层架构。

在此图中:
- 有 主要站点和一个 次要站点的详细信息。
- 只能在 主要站点上执行数据库写入操作。次要站点通过使用 PostgreSQL 流复制接收数据库更新。
- 如果存在,LDAP 服务器应配置为复制以用于灾难恢复场景。
- 次要站点执行不同类型的同步操作对 主要站点,使用一种由 JWT 保护的特殊授权:
- 代码库通过 HTTPS 使用 Git 克隆/更新。
- 附件、LFS 对象和其他文件通过 HTTPS 使用私有 API 端点下载。
从执行 Git 操作的用户的角度来看:
- 主要站点表现为完整的读写极狐GitLab 实例。
- 次要站点表现为完整的读写极狐GitLab 实例。次要站点透明地代理所有操作到 主要站点,有一些值得注意的例外。特别是,当 次要站点是最新时,Git 获取由 次要站点提供服务。
从浏览极狐GitLab 用户界面或使用 API 的用户的角度来看:
- 主要站点表现为完整的读写极狐GitLab 实例。
- 次要站点表现为完整的读写极狐GitLab 实例。次要站点透明地代理所有操作到 主要站点,有一些值得注意的例外。特别是,网页 UI 资源由 次要站点提供服务。
为了简化图表,省略了一些必要组件。
- Git over SSH 需要 gitlab-shell。
- Git over HTTPS 需要 gitlab-workhorse。
次要站点需要两个不同的 PostgreSQL 数据库:
- 一个从主要极狐GitLab 数据库流数据的只读数据库实例。
- 一个读写数据库实例(跟踪数据库),由 次要站点内部使用,以记录已复制的数据。
次要站点还运行一个额外的守护程序:Geo 日志游标。
运行 Geo 的要求
运行 Geo 需要以下条件:
- 支持 OpenSSH 6.9 或更高版本的操作系统(需要快速查找数据库中的授权 SSH 密钥)。
以下操作系统已知提供最新版本的 OpenSSH:
- CentOS 7.4 或更高版本
- Ubuntu 16.04 或更高版本
- 在可能的情况下,您还应在所有 Geo 站点上使用相同的操作系统版本。如果在 Geo 站点之间使用不同的操作系统版本,您必须检查操作系统区域数据兼容性,以避免数据库索引的静默损坏。
- PostgreSQL 逻辑复制不受支持。
- 所有站点必须运行相同的 PostgreSQL 版本。
- Git 2.9 或更高版本
- 在使用 LFS 时用户端需要 Git-lfs 2.4.2 或更高版本
- 所有站点必须运行完全相同的极狐GitLab 版本。主要、次要和补丁版本必须全部匹配。
- 所有站点必须定义相同的代码库存储。
此外,请检查极狐GitLab 的最低要求,并使用最新版本的极狐GitLab 以获得更好的体验。
防火墙规则
下表列出了 Geo 主要和 次要站点之间必须打开的基本端口。为了简化故障切换,您应该在两个方向上打开端口。
| 来源站点 | 来源端口 | 目标站点 | 目标端口 | 协议 |
|---|---|---|---|---|
| 主要 | 任意 | 次要 | 80 | TCP (HTTP) |
| 主要 | 任意 | 次要 | 443 | TCP (HTTPS) |
| 次要 | 任意 | 主要 | 80 | TCP (HTTP) |
| 次要 | 任意 | 主要 | 443 | TCP (HTTPS) |
| 次要 | 任意 | 主要 | 5432 | TCP |
查看极狐GitLab 使用的完整端口列表,请参阅软件包默认值。
内部 URL
从任何 Geo 次要站点到主要 Geo 站点的 HTTP 请求使用主要 Geo 站点的内部 URL。如果在 管理员区域的主要 Geo 站点设置中未明确定义,则使用主要站点的公共 URL。
要更新主要 Geo 站点的内部 URL:
- 在左侧边栏底部,选择 管理员。
- 选择 Geo > 站点。
- 在主要站点上选择 编辑。
- 更改 内部 URL,然后选择 保存更改。
Geo 跟踪数据库
跟踪数据库实例用作元数据,用于控制本地实例上需要更新的内容。例如:
- 下载新资源。
- 获取新的 LFS 对象。
- 从最近更新的代码库中获取更改。
由于复制的数据库实例是只读的,我们需要为每个 次要站点提供此附加数据库实例。
Geo 日志游标
此守护程序:
- 读取由 主要站点复制到 次要数据库实例的事件日志。
- 使用必须执行的更改更新 Geo 跟踪数据库实例。
当在跟踪数据库实例中标记为更新时,次要站点上运行的异步作业执行所需操作并更新状态。
这种新架构使极狐GitLab 能够抵抗站点之间的连接问题。无论 次要站点与 主要站点断开连接多长时间,它都能够按正确顺序重放所有事件,并再次与 主要站点同步。
已知问题
- 直接推送到 次要站点会将请求重定向(对于 HTTP)或代理(对于 SSH)到 主要站点,而不是直接处理。您不能使用嵌入在 URI 中的凭证进行 Git over HTTP,例如 https://user:personal-access-token@secondary.tld。有关更多信息,请参阅如何使用 Geo 站点。
- 主要站点必须在线才能进行 OAuth 登录。现有会话和 Git 不受影响。支持 次要站点使用独立于主要站点的 OAuth 提供商正在规划中。
- 安装需要多个手动步骤,具体情况可能需要约一个小时。考虑使用极狐GitLab 环境工具包中的 Terraform 和 Ansible 脚本来部署和操作基于我们的参考架构的生产极狐GitLab 实例,包括常见日常任务的自动化。Epic 1465 提议进一步改进 Geo 安装。
- 议题/合并请求的实时更新(例如,通过长轮询)在 次要站点上不起作用,其中禁用 HTTP 代理。
- 选择性同步仅限制复制的代码库和文件。整个 PostgreSQL 数据仍然被复制。选择性同步不是为了适应合规性/出口控制用例而构建的。
- 页面访问控制在次要站点上不起作用。
- 灾难恢复对于具有多个次要站点的部署会导致停机,因为需要重新初始化所有非提升次要站点上的 PostgreSQL 流复制以跟随新的主要站点。
- 对于 Git over SSH,要使项目克隆 URL 无论您浏览哪个站点都正确显示,次要站点必须使用与主要站点相同的端口。
- 对次要站点的 Git push over SSH 不适用于超过 1.86 GB 的推送。
- 备份不能在 Geo 次要站点上运行。
- 对次要站点的 Git push with options over SSH 不起作用并终止连接。
- Geo 次要站点在大多数情况下不加速(提供)流水线第一阶段的克隆请求。后续阶段也不保证由次要站点提供服务,例如如果 Git 更改较大、带宽较小或流水线阶段较短。通常,它确实为后续阶段提供克隆请求服务。
- 当单个 Git 代码库以足够高的速率接收推送时,次要站点的本地副本可能会持续过时。这导致该代码库的所有 Git 获取都被转发到主要站点。
- 代理仅在极狐GitLab 应用程序中的 Puma 服务或 Web 服务中实现,因此其他服务不会从此行为中受益。您应该使用单独的 URL以确保请求始终发送到主要站点。这些服务包括:
- 极狐GitLab 容器注册表 - 可以配置为使用单独的域,例如 registry.example.com。次要站点容器注册表仅用于灾难恢复。用户不应该被路由到它们,尤其不是用于推送,因为数据不会传播到主要站点。
- 极狐GitLab 页面 - 应始终使用单独的域,作为运行极狐GitLab 页面的先决条件的一部分。
- 使用统一 URL,Let's Encrypt 不能生成证书,除非它可以通过同一域访问两个 IP。要使用 TLS 证书和 Let's Encrypt,您可以手动将域指向其中一个 Geo 站点,生成证书,然后将其复制到所有其他站点。
- 当次要站点使用与主要站点不同的 URL时,使用 SAML 在次要站点登录仅在 SAML 身份提供者 (IdP) 允许应用程序配置多个回调 URL 时才受支持。
- 对次要站点的 Git clone 和 fetch 请求使用选项 --depth over SSH 不起作用,并在请求启动时次要站点未最新时无限期挂起。这是由于在代理期间将 Git SSH 转换为 Git https 的问题。一种新工作流不涉及上述翻译步骤,现在可用于 Linux 打包的极狐GitLab Geo 次要站点,可以通过功能标志启用。
- 一些客户报告说,当次要站点过时时,git fetch over SSH 挂起并/或超时失败。git clone 请求不受影响。一种可用于 Linux 打包的极狐GitLab Geo 次要站点的修复可以通过功能标志启用。
复制的数据类型
有一个极狐GitLab 的所有数据类型和复制的数据类型的完整列表。
安装后文档
在 次要站点上安装极狐GitLab 并执行初始配置后,请参阅以下文档以获取安装后信息。
设置 Geo
有关配置 Geo 的信息,请参阅设置 Geo。
使用对象存储配置 Geo
有关使用对象存储配置 Geo 的信息,请参阅使用对象存储配置 Geo。
复制容器注册表
有关如何复制容器注册表的更多信息,请参阅次要站点的容器注册表。
为 Geo 站点设置统一 URL
有关如何使用 AWS Route53 或 Google Cloud DNS 设置单一位置感知 URL 的示例,请参阅为 Geo 站点设置统一 URL。
单点登录 (SSO)
有关配置单点登录 (SSO) 的更多信息,请参阅Geo 单点登录 (SSO)。
LDAP
有关配置 LDAP 的更多信息,请参阅Geo 单点登录 (SSO) > LDAP。
调整 Geo
有关调整 Geo 的更多信息,请参阅调整 Geo。
暂停和恢复复制
有关更多信息,请参阅暂停和恢复复制。
回填
当 次要站点设置时,它开始从 主要站点复制缺失数据,称为 回填。您可以在浏览器中从 主要站点的 Geo 节点仪表板监控每个 Geo 站点上的同步过程。
回填过程中发生的失败将在回填结束时安排重试。
Runner
- 除了我们部署runner 车队的标准最佳实践外,还可以配置 runner 连接到 Geo 次要站点以分散作业负载。请参阅如何在次要站点注册 runner。
- 另请参阅如何处理灾难恢复与 runner。
升级 Geo
有关如何将您的 Geo 站点更新到最新的极狐GitLab 版本的信息,请参阅升级 Geo 站点。
安全审查
有关 Geo 安全的更多信息,请参阅Geo 安全审查。
移除 Geo 站点
有关移除 Geo 站点的更多信息,请参阅移除 次要 Geo 站点。
禁用 Geo
要了解如何禁用 Geo,请参阅禁用 Geo。
日志文件
Geo 将结构化日志消息存储在 geo.log 文件中。
有关如何访问和使用 Geo 日志的更多信息,请参阅日志系统文档中的 Geo 部分。
灾难恢复
有关在灾难恢复情况下使用 Geo 来减轻数据丢失和恢复服务的信息,请参阅灾难恢复。
常见问题解答
有关常见问题的答案,请参阅Geo FAQ。
故障排除
-
有关 Geo 故障排除步骤,请参阅Geo 故障排除。
-
有关灾难恢复故障排除步骤,请参阅Geo 故障切换故障排除。