Skip to main content
We publish frequent updates to our documentation, and translation of this page may still be in progress. For the most current information, please visit the English documentation.

关于高可用性配置

在高性能配置中,完全冗余的次级 GitHub Enterprise Server 设备通过复制所有主要数据存储与主设备保持同步。

配置高可用性时,会自动设置将所有数据存储(Git 仓库、MySQL、Redis 和 Elasticsearch)单向、异步地从主设备复制到副本。 还会复制大多数 GitHub Enterprise Server 配置设置,包括 Management Console 密码。 有关详细信息,请参阅“访问管理控制台”。

GitHub Enterprise Server 支持主动/被动配置,在这些配置下,副本作为备用设备运行,并且数据库服务在复制模式下运行,但应用程序服务将停止。

建立复制后,副本设备上将不再可访问 Management Console 。 如果在端口 8443 上导航到副本的 IP 地址或主机名,您将看到“Server in replication mode(服务器处于复制模式)”消息,表示设备当前已配置为副本。

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

有针对性的故障场景

使用高可用性配置防护以下问题:

  • 软件崩溃,操作系统失败或不可恢复的应用程序所致。
  • 硬件故障,包括存储硬件、CPU、RAM、网络接口等。
  • 虚拟化主机系统故障,包括 AWSAzureGCP 上未计划和计划性维护事件。
  • 逻辑或物理服务网络(如果故障转移设备在不受故障影响的单独网络上)。

高可用性配置不适用于:

  • 横向扩展。虽然可以使用异地复制将流量分布在不同地理位置,但写入性能受限于主设备的速度和可用性。 有关详细信息,请参阅“有关异地复制”。
  • CI/CD 负载。 如果您有大量在地理位置上远离主实例的 CI 客户端,则配置仓库缓存可能会使您受益匪浅。 有关详细信息,请参阅“关于存储库缓存”。
  • 备份主设备。 高可用性副本不会替代灾难恢复计划中的非现场备份。 某些形式的数据损坏或数据丢失可能会立即从主设备复制到副本。 为确保安全回滚到稳定的过去状态,必须通过历史快照执行定期备份。
  • 零停机时间升级。 为避免受控升级场景下出现数据丢失和裂脑的状况,请先将主设备置于维护模式并等待所有写入操作完成,然后再对副本进行升级。

网络流量故障转移策略

在故障转移期间,您必须单独配置和管理从主设备到副本的网络流量的重定向。

DNS 故障转移

对于 DNS 故障转移,请使用 DNS 记录中指向主 GitHub Enterprise Server 设备的短 TTL 值。 建议的 TTL 值范围为 60 秒到 5 分钟。

在故障转移期间,必须将主设备置于维护模式,并将其 DNS 记录重定向到副本的 IP 地址。 将流量从主设备重新定向到副本所需的时间将取决于 TTL 配置以及更新 DNS 记录所需的时间。

如果您要使用 Geo-replication,则必须配置 Geo DNS,将流量定向到距离最近的副本。 有关详细信息,请参阅“有关异地复制”。

负载均衡器

负载均衡器设计使用网络设备将 Git 和 HTTP 流量引导至各个 GitHub Enterprise Server 设备。 您可以使用负载均衡器限制引导至设备的流量以确保安全,或者在没有 DNS 记录更改的情况下根据需要重定向流量。 我们强烈建议使用支持 PROXY 协议的基于 TCP 负载均衡器。 对 GitHub Enterprise Server 主机名的 DNS 查询应解析为负载均衡器。 我们建议您启用子域隔离。 如果启用了子域隔离,另一个通配符记录 *.HOSTNAME 也应解析到负载均衡器。 有关详细信息,请参阅“启用子域隔离”。

在故障转移期间,您必须将主设备置于维护模式。 您可以将负载均衡器配置为自动检测副本何时已升级为主设备,或者可能需要手动更改配置。 您必须先将副本手动升级为主设备,随后副本才能对用户流量作出响应。 有关详细信息,请参阅“将 GitHub Enterprise Server 与负载均衡器配合使用”。

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

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

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

https://HOSTNAME/setup/replication

用于复制管理的实用程序

要管理 GitHub Enterprise Server 上的复制,请使用 SSH 连接到副本,以使用以下命令行实用程序。

ghe-repl-setup

ghe-repl-setup 命令将 GitHub Enterprise Server 设备置于副本备用模式。

  • 配置加密的 WireGuard VPN 隧道以实现两台设备之间的通信。
  • 配置用于复制的数据库服务并启动。
  • 禁用应用程序服务。 尝试通过 HTTP、Git 或其他受支持协议访问副本将出现“设备处于副本模式”维护页面或显示错误消息。
admin@169-254-1-2:~$ ghe-repl-setup 169.254.1.1
Verifying ssh connectivity with 169.254.1.1 ...
Connection check succeeded.
Configuring database replication against primary ...
Success: Replica mode is configured against 169.254.1.1.
To disable replica mode and undo these changes, run `ghe-repl-teardown'.
Run `ghe-repl-start' to start replicating against the newly configured primary.

ghe-repl-start

ghe-repl-start 命令启用所有数据存储的主动复制。

admin@169-254-1-2:~$ ghe-repl-start
Starting MySQL replication ...
Starting Redis replication ...
Starting Elasticsearch replication ...
Starting Pages replication ...
Starting Git replication ...
Success: replication is running for all services.
Use `ghe-repl-status' to monitor replication health and progress.

ghe-repl-status

ghe-repl-status 命令返回每个数据存储复制流的 OKWARNINGCRITICAL 状态。 如果有任何复制通道处于 WARNING 状态,命令将停止执行并显示代码 1。 同样,如果有任何通道处于 CRITICAL 状态,命令将停止执行并显示代码 2

admin@169-254-1-2:~$ ghe-repl-status
OK: mysql replication in sync
OK: redis replication is in sync
OK: elasticsearch cluster is in sync
OK: git data is in sync (10 repos, 2 wikis, 5 gists)
OK: pages data is in sync

-v-vv 选项提供关于各数据存储复制状态的详细信息:

$ ghe-repl-status -v
OK: mysql replication in sync
  | IO running: Yes, SQL running: Yes, Delay: 0

OK: redis replication is in sync
  | master_host:169.254.1.1
  | master_port:6379
  | master_link_status:up
  | master_last_io_seconds_ago:3
  | master_sync_in_progress:0

OK: elasticsearch cluster is in sync
  | {
  |   "cluster_name" : "github-enterprise",
  |   "status" : "green",
  |   "timed_out" : false,
  |   "number_of_nodes" : 2,
  |   "number_of_data_nodes" : 2,
  |   "active_primary_shards" : 12,
  |   "active_shards" : 24,
  |   "relocating_shards" : 0,
  |   "initializing_shards" : 0,
  |   "unassigned_shards" : 0
  | }

OK: git data is in sync (366 repos, 31 wikis, 851 gists)
  |                   TOTAL         OK      FAULT    PENDING      DELAY
  | repositories        366        366          0          0        0.0
  |        wikis         31         31          0          0        0.0
  |        gists        851        851          0          0        0.0
  |        total       1248       1248          0          0        0.0

OK: pages data is in sync
  | Pages are in sync

ghe-repl-stop

ghe-repl-stop 命令暂时禁用所有数据存储的复制并停止复制服务。 若要恢复复制,请使用 ghe-repl-start 命令。

admin@168-254-1-2:~$ ghe-repl-stop
Stopping Pages replication ...
Stopping Git replication ...
Stopping MySQL replication ...
Stopping Redis replication ...
Stopping Elasticsearch replication ...
Success: replication was stopped for all services.

ghe-repl-promote

ghe-repl-promote 命令禁用复制并将副本转换为主设备。 设备会配置为使用与原主设备相同的设置,并启用所有服务。

推广副本不会自动为现有设备创建副本。 在推广副本后,如有需要,可以设置从新的主设备复制到现有设备及之前的主设备。

admin@168-254-1-2:~$ ghe-repl-promote
Enabling maintenance mode on the primary to prevent writes ...
Stopping replication ...
  | Stopping Pages replication ...
  | Stopping Git replication ...
  | Stopping MySQL replication ...
  | Stopping Redis replication ...
  | Stopping Elasticsearch replication ...
  | Success: replication was stopped for all services.
Switching out of replica mode ...
  | Success: Replication configuration has been removed.
  | Run `ghe-repl-setup' to re-enable replica mode.
Applying configuration and starting services ...
Success: Replica has been promoted to primary and is now accepting requests.

ghe-repl-teardown

ghe-repl-teardown 命令完全禁用复制模式,并移除副本配置。

延伸阅读