Geo

  • Tier: 专业版,旗舰版
  • Offering: 私有化部署

极狐GitLab Geo 是为广泛分布的开发团队提供解决方案,并作为灾难恢复策略的一部分提供热备份。Geo 不是一种现成的高可用性解决方案。

Geo 在每个发布版本中都会发生显著变化。升级是支持并[记录](#upgrading-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 概述

启用 Geo 时:

  • 原始实例被称为 主要站点。
  • 复制站点被称为 次要站点。

请记住:

  • 次要站点与 主要站点通信以:
    • 获取登录的用户数据(API)。
    • 复制代码库、LFS 对象和附件(HTTPS + JWT)。
  • 主要站点与 次要站点通信以查看复制详细信息。主要站点对 次要站点进行 GraphQL 查询以获取同步和验证数据(API)。
  • 您可以直接推送到 次要站点(无论是 HTTP 还是 SSH,包括 Git LFS),它会将请求代理到 主要站点。
  • 使用 Geo 时存在一些已知问题

架构#

以下图表展示了 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 数据库:

次要站点还运行一个额外的守护程序: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 主要次要站点之间必须打开的基本端口。为了简化故障切换,您应该在两个方向上打开端口。

来源站点来源端口目标站点目标端口协议
主要任意次要80TCP (HTTP)
主要任意次要443TCP (HTTPS)
次要任意主要80TCP (HTTP)
次要任意主要443TCP (HTTPS)
次要任意主要5432TCP

查看极狐GitLab 使用的完整端口列表,请参阅软件包默认值

[网页终端](../../ci/environments/_index.md#web-terminals-deprecated)支持需要您的负载均衡器正确处理 WebSocket 连接。 使用 HTTP 或 HTTPS 代理时,您的负载均衡器必须配置为通过 `Connection` 和 `Upgrade` hop-by-hop 头。有关详细信息,请参阅[网页终端](../integration/terminal.md)集成指南。
使用 443 端口的 HTTPS 协议时,您必须向负载均衡器添加 SSL 证书。 如果您希望在极狐GitLab 应用服务器而不是负载均衡器终止 SSL,请使用 TCP 协议。
如果您仅使用 `HTTPS` 进行外部/内部 URL,则不需要在防火墙中打开端口 80。

内部 URL#

从任何 Geo 次要站点到主要 Geo 站点的 HTTP 请求使用主要 Geo 站点的内部 URL。如果在 管理员区域的主要 Geo 站点设置中未明确定义,则使用主要站点的公共 URL。

要更新主要 Geo 站点的内部 URL:

  1. 在左侧边栏底部,选择 管理员
  2. 选择 Geo > 站点
  3. 在主要站点上选择 编辑
  4. 更改 内部 URL,然后选择 保存更改

Geo 跟踪数据库#

跟踪数据库实例用作元数据,用于控制本地实例上需要更新的内容。例如:

  • 下载新资源。
  • 获取新的 LFS 对象。
  • 从最近更新的代码库中获取更改。

由于复制的数据库实例是只读的,我们需要为每个 次要站点提供此附加数据库实例。

Geo 日志游标#

此守护程序:

  • 读取由 主要站点复制到 次要数据库实例的事件日志。
  • 使用必须执行的更改更新 Geo 跟踪数据库实例。

当在跟踪数据库实例中标记为更新时,次要站点上运行的异步作业执行所需操作并更新状态。

这种新架构使极狐GitLab 能够抵抗站点之间的连接问题。无论 次要站点与 主要站点断开连接多长时间,它都能够按正确顺序重放所有事件,并再次与 主要站点同步。

已知问题#

这些已知问题仅反映了极狐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#

升级 Geo#

有关如何将您的 Geo 站点更新到最新的极狐GitLab 版本的信息,请参阅升级 Geo 站点

安全审查#

有关 Geo 安全的更多信息,请参阅Geo 安全审查

移除 Geo 站点#

有关移除 Geo 站点的更多信息,请参阅移除 次要 Geo 站点

禁用 Geo#

要了解如何禁用 Geo,请参阅禁用 Geo

日志文件#

Geo 将结构化日志消息存储在 geo.log 文件中。

有关如何访问和使用 Geo 日志的更多信息,请参阅日志系统文档中的 Geo 部分

灾难恢复#

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

常见问题解答#

有关常见问题的答案,请参阅Geo FAQ

故障排除#