我们经常发布文档更新,此页面的翻译可能仍在进行中。有关最新信息,请访问英文文档。如果此页面上的翻译有问题,请告诉我们
文章版本: Enterprise Server 2.21

About geo-replication

Geo-replication on GitHub Enterprise Server uses multiple active replicas to fulfill requests from geographically distributed data centers.

本文内容

Multiple active replicas can provide a shorter distance to the nearest replica. For example, an organization with offices in San Francisco, New York, and London could run the primary appliance in a datacenter near New York and two replicas in datacenters near San Francisco and London. Using geolocation-aware DNS, users can be directed to the closest server available and access repository data faster. Designating the appliance near New York as the primary helps reduce the latency between the hosts, compared to the appliance near San Francisco being the primary which has a higher latency to London.

The active replica proxies requests that it can't process itself to the primary instance. The replicas function as a point of presence terminating all SSL connections. Traffic between hosts is sent through an encrypted VPN connection, similar to a two-node high availability configuration without geo-replication.

Git requests and specific fileserver requests, such as LFS and file uploads, can be served directly from the replica without loading any data from the primary. Web requests are always routed to the primary, but if the replica is closer to the user the requests are faster due to the closer SSL termination.

Geo DNS, such as Amazon's Route 53 service, is required for geo-replication to work seamlessly. The hostname for the instance should resolve to the replica that is closest to the user's location.

Limitations

Writing requests to the replica requires sending the data to the primary and all replicas. This means that the performance of all writes are limited by the slowest replica, although new geo-replicas can seed the majority of their data from existing co-located geo-replicas, rather than from the primary. Geo-replication will not add capacity to a GitHub Enterprise Server instance or solve performance issues related to insufficient CPU or memory resources. If the primary appliance is offline, active replicas will be unable to serve any read or write requests.

Monitoring a geo-replication configuration

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

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

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

https://HOSTNAME/setup/replication

Further reading

问问别人

找不到要找的内容?

联系我们