极狐GitLab GEO 功能介绍

极狐GitLab 是 GitLab 在中国的发行版，关于中文参考文档和资料有：

极狐GitLab 中文文档
极狐GitLab 中文论坛
极狐GitLab 官网

Geo (PREMIUM SELF)

Geo 是广泛分布的开发团队的解决方案，可作为灾难恢复策略的一部分提供热备份。Geo 不是开箱即用的 HA 解决方案。

WARNING:Geo 在不同版本之间经历了重大变化。支持升级并会记录升级，但您应该确保使用正确版本的安装文档。

Geo 提供极狐GitLab 实例的本地只读站点。这可以减少克隆和获取大型仓库所需的时间，从而加快开发速度。

为了确保您使用正确版本的文档，请访问 JihuLab.com 上的 Geo 页面，并从 切换分支/标签 下拉列表中选择适当的版本。例如，v13.7.6-ee。

Geo 使用 Geo 术语文档中描述的一组已定义的术语。
请务必熟悉这些术语。

用例

实施 Geo 有以下优势：

将分布式开发人员克隆和获取大型仓库和项目的时间从几分钟缩短到几秒钟。
让您的所有开发人员都能贡献想法，并且并行工作，无论他们身在何处。
平衡您的主要和次要站点之间的只读负载。

此外：

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

Geo 提供：

次要站点上的完整极狐GitLab 体验：维护一个主极狐GitLab 站点，同时为每个分布式团队启用具有完全读写和用户界面体验的次要站点。
认证系统勾子：次要站点接收从主要站点的所有认证数据（注入用户账号和登录）。

Gitaly 集群

Geo 不应与 Gitaly 集群混淆。有关 Geo 和 Gitaly 集群之间差异的更多信息，请参阅与 Geo 对比。

工作原理

这部分是关于极狐GitLab 环境中 Geo 工作原理的简单总结。更多详情，可以查看 Geo 开发页面。

您可以使用 Geo 实例来克隆和拉取项目，此外还能够读取任何数据。这使得远距离操作大型存储库的速度快得多。
在这里插入图片描述

启用 Geo 后：

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

请记住：

次要站点与主要站点对话：
- 获取登录用户数据 (API)。
- 复制仓库、LFS 对象和附件 (HTTPS + JWT)。
主要站点会和次要站点进行通信，以查看数据复制详情。主要站点针对次要站点执行 GraphQL 查询以获取同步和验证数据（通过 API）。
您可以直接推送到次要站点（用 HTTP 和 SSH，包括 Git LFS），并且将这些操作请求代理到主要站点。
当使用 Geo 时，有一些限制。

架构

下图说明了 Geo 的底层架构。
在这里插入图片描述

在此图中：

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

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

主要站点表现为一个完整的读写极狐GitLab 实例。
次要站点是只读的，但代理 Git 推送操作到主要站点。这使得次要站点本身似乎支持推送操作。

为了简化图表，省略了一些必要的组件。

Git over SSH 需要 gitlab-shell 和 OpenSSH。
需要通过 HTTPS 的 Git gitlab-workhorse。

次要站点需要两个不同的 PostgreSQL 数据库：

从极狐GitLab 主数据库流式传输数据的只读数据库实例。
另一个数据库实例由次要站点内部用于记录已复制的数据。

在次要站点中，有一个额外的守护进程：Geo Log Cursor。

运行 Geo 的要求

运行 Geo 需要以下条件：

支持 OpenSSH 6.9 或更高版本的操作系统（需要快速查找数据库中授权的 SSH 密钥）。已知以下操作系统附带当前版本的 OpenSSH：
- CentOS 7.4 或更高版本
- Ubuntu 16.04 或更高版本
可能的话，您应该在所有 Geo 站点上使用相同的操作系统版本。如果在 Geo 站点间使用不同的操作系统版本，您必需跨站点检查 OS 区域数据的兼容性以避免数据库索引的静默损坏。
极狐GitLab 发行版中支持流复制的 PostgreSQL 版本。
- PostgreSQL 逻辑复制并不支持。
所有站点必需运行相同的 PostgreSQL 版本。
Git 2.9 或更高版本
使用 LFS 时用户端的 Git-lfs 2.4.2 或更高版本
所有站点都必须运行相同的极狐GitLab 版本。主、次和补丁版本都必须相匹配。
所有站点必须定义相同的仓库存储。

此外，请查看极狐GitLab 最低要求，我们建议您使用最新版本的极狐GitLab 以获得更好的体验。

防火墙规则

下表列出了必须在主要和次要站点之间为 Geo 开放的基本端口。为了简化故障转移，我们建议在两个方向上打开端口。

源站点	源端口	目的地站点	目的地端口	协议
主要	Any	次要	80	TCP (HTTP)
主要	Any	次要	443	TCP (HTTPS)
次要	Any	主要	80	TCP (HTTP)
次要	Any	主要	443	TCP (HTTPS)
次要	Any	主要	5432	TCP

在软件包默认值文档中查看极狐GitLab 使用的端口的完整列表。

NOTE:Web 终端支持要求您的负载均衡器正确处理 WebSocket 连接。
使用 HTTP 或 HTTPS 代理时，您的负载均衡器必须配置为通过
Connection 和 Upgrade hop-by-hop headers。有关更多详细信息，请参阅 web 终端集成指南。

NOTE:对端口 443 使用 HTTPS 协议时，您必须向负载均衡器添加 SSL 证书。如果您希望在极狐GitLab 应用程序服务器上终止 SSL，请使用 TCP 协议。

NOTE:如果您想为外部/内部 URL 仅使用 HTTPS，就没必要在防火墙中打开 80 端口了。

内部 URL
从任何 Geo 次要站点到主 Geo 站点的 HTTP 请求使用主 Geo 站点的内部 URL。如果在管理中心的主 Geo 站点设置中未明确定义，则使用主要站点公开 URL。
要更新主 Geo 站点的内部 URL：

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

Geo 跟踪数据库

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

下载新 assets。
获取新的 LFS 对象。
从最近更新的仓库中获取更改。

因为复制的数据库实例是只读的，所以我们需要为每个次要站点添加这个额外的数据库实例。

Geo Log Cursor

这个守护进程：

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

当跟踪数据库实例中的某些内容被标记为要更新时，次要站点上运行的异步作业会执行所需的操作并更新状态。

这种新架构使极狐GitLab 能够灵活应对站点之间的连接问题。次要站点与主要站点断开连接的时间无关紧要，因为它能够以正确的顺序重播所有事件并再次与主要站点同步。

限制

WARNING:此限制列表仅反映最新版本的极狐GitLab。如果您使用的是旧版本，则可能会有额外的限制。

直接推送到次要站点会将请求重定向（对于 HTTP）或代理（对于 SSH）到主要站点的请求，而不是直接处理它，除非在 URI 中使用嵌入了凭据的 HTTP 上的 Git。例如，https://user:password@secondary.tld。
主要站点必须在线才能进行 OAuth 登录。现有会话和 Git 不受影响。
安装需要多个手动步骤，视情况而定，总共可能需要大约一个小时。
议题/合并请求的实时更新（例如，通过长轮询）在次要站点上不起作用。
极狐GitLab Runners 无法在次要站点注册。
选择性同步仅限制复制哪些仓库和文件。整个 PostgreSQL 数据仍然被复制。选择性同步不是为了适应合规性/出口控制用例而构建的。
Pages 访问控制在次要节点上无效。
极狐GitLab chart 的 Geo 不支持统一 URL。
由于所有未升级的次要站点的完全重新同步和重新配置，多次要站点的灾难恢复会导致停机。
对于 Git over SSH，为了使项目克隆 URL 正确显示，无论您正在浏览哪个站点，次要站点都必须使用与主站点相同的端口。
对于通过 SSH 对次要站点进行 Git 的推送，不适用于超过 1.86 GB 的推送。
备份无法在次要站点上运行。