Skip to main content

此版本的 GitHub Enterprise 已停止服务 2022-06-03. 即使针对重大安全问题,也不会发布补丁。 要获得更好的性能、改进的安全性和新功能,请升级到 GitHub Enterprise 的最新版本。 如需升级方面的帮助,请联系 GitHub Enterprise 支持

关于 Geo-replication

GitHub Enterprise Server 上的 Geo-replication 使用多个活动副本满足从异地分布式数据中心发出的请求。

多个活动副本可以提供到达最近副本的较短距离。 举例来说,一个在旧金山、纽约和伦敦均设有办事处的组织可以在� 近纽约的数据中心运行主设备,在� 近旧金山和伦敦的数据中心运行两个副本。 利用地理位置感知 DNS,用户可以转到距离最近的可用服务器,并更快地访问仓库数据。 如果将� 近旧金山的设备指定为主设备,则与伦敦的延迟会比较大,相比而言,将� 近纽约的设备指定为主设备有助于减小主机之间的延迟。

活动副本会将自身� 法处理的请求委托主实例代为处理。 副本用作终止所有 SSL 连接的入口点。 与没有 Geo-replication 功能的双节点高可用性配置类似,主机之间的流量通过� 密 VPN 连接发送。

Git 请求和特定的文件服务器请求(例如 LFS 和文件上� )可直接通过副本完成,� 需从主设备� 载任何数据。 Web 请求会始终� 送到主设备,但在副本距离用户较近的情况下,由于 SSL 端接距离更近,请求速度更快。

为了让 Geo-replication � 缝运行,需要使用 Geo DNS,例如 Amazon 的 Route 53 服务。 实例的主机名应解析到距离用户最近的副本。

限制

将请求写入副本需要将数据发送到主设备和所有副本。 这意味着所有写入操作的性能都受限于最慢的副本,虽然新的地理副本可以从现有共同位置地理副本(而不是从主设备)播种大部分数据。

Geo-replication 不会增大 GitHub Enterprise Server 实例的容量,也不会解决与 CPU 或内存资源不足相关的性能问题。 如果主设备处于脱机状态,则活动副本将� 法满足任何读取或写入请求。

注意: 允许 GitHub Enterprise Server 使用最多 8 种高可用性副本(被动和主动/地理副本)。

监视 Geo-replication 配置

您可以勾选 https://HOSTNAME/status URL 返回的状态代� �,以监控 GitHub Enterprise Server 的可用性。 可提供用户流量的设备将返回状态代� � 200(正常)。 设备可能出于以下� 个原� 而返回 503(服务不可用):

  • 设备是被动副本,例如双节点高可用性配置中的副本。
  • 设备处于维护模式。
  • 设备属于地理副本配置,但为非活动的副本。

也可使用以下网址的“复制”概述:

https://HOSTNAME/setup/replication

延伸阅读