Skip to main content

此版本的 GitHub Enterprise Server 已于以下日期停止服务 2024-09-25. 即使针对重大安全问题,也不会发布补丁。 为了获得更好的性能、更高的安全性和新功能,请升级到最新版本的 GitHub Enterprise。 如需升级帮助,请联系 GitHub Enterprise 支持

为群集配置高可用性复制

可以在单独的数据中心配置整个 GitHub Enterprise Server 群集的副本,这使群集可以故障转移至冗余节点。

关于集群的高可用性复制

可以通过配置 GitHub Enterprise Server 的群集部署来防止数据中心或云区域发生中断,从而实现高可用性。 在高可用性配置中,一组相同的副本节点与活动群集中的节点同步。 如果硬件或软件故障影响具有活动群集的数据中心,您可以手动故障转移到副本节点,继续处理用户请求,以尽可能减少中断的影响。

在高可用性配置中,托管数据服务的节点会定期与副本群集同步。 被动节点在等待状态下运行,不适用于应用程序或处理用户请求。

我们建议配置高可用性,作为 GitHub Enterprise Server 全面群集的一部分。 我们还建议进行定期备份。 有关详细信息,请参阅“在实例上配置备份”。

先决条件

硬件和软件

对于活动群集中的每个现有节点,都需要预配第二个具有相同硬件资源的虚拟机。 例如,如果你的群集有 13 个节点,并且每个节点有 12 个 vCP、96 GB 的 RAM 和 750 GB 的附加存储,则必须预配 13 个新虚拟机,每个虚拟机具有 12 个 vCPU、96 GB 的 RAM 和 750 GB 的附加存储。

在每个新虚拟机上,安装活动群集的节点上运行的相同版本 GitHub Enterprise Server。 您不需要上传许可证或执行任何其他配置。 有关详细信息,请参阅“设置 GitHub Enterprise Server 实例”。

Note

你打算用于高可用性复制的节点应该是独立的 GitHub Enterprise Server 实例。 不要将被动副本初始化为第二个群集。

网络

您必须为预配的每个新节点分配一个静态 IP 地址,并且必须配置负载均衡器以接受连接,并将其引导到群集前端层中的节点。

主节点和副本节点之间的延迟不得超过 70 毫秒。 我们不建议在两个节点之间配置防火墙。 有关副本群集中节点之间网络连接的详细信息,请参阅“群集网络配置”。

为群集创建高可用性副本

若要为群集创建高可用性副本,必须完成以下任务。 还可以查看示例配置。

  1. 将主动节点分配到主数据中心
  2. 将副本节点添加到群集配置文件
  3. 查看示例配置

1.将主动节点分配到主数据中心

在为副本节点定义辅助数据中心之前,请确保将主动节点分配给主数据中心。

  1. SSH 到集群中的任何节点。 有关详细信息,请参阅“访问管理 shell (SSH)”。

  2. 在文本编辑器中,打开位于 /data/user/common/cluster.conf 的群集配置文件。 例如,您可以使用 Vim。 在编辑文件之前创建 cluster.conf 文件的备份。

    Shell
    sudo vim /data/user/common/cluster.conf
    
  3. 记下群集主数据中心的名称。 群集配置文件顶部的 [cluster] 部分使用 primary-datacenter 键值对定义主数据中心的名称。

    [cluster]
      mysql-master = HOSTNAME
      redis-master = HOSTNAME
      primary-datacenter = primary
    
    • (可选)通过编辑 primary-datacenter 的值,将主数据中心的名称更改为更具描述性或更准确的值。
  4. 群集配置文件在 [cluster "HOSTNAME"] 标题下列出每个节点。 在每个节点标题下,添加新的键值对,以将节点分配给数据中心。 使用上述第 3 步中 primary-datacenter 所用的值。 例如,如果要使用默认名称 (default),请将以下键值对添加到每个节点的部分。

    datacenter = primary
    

    完成后,群集配置文件中每个节点的部分应如下所示。 键值对的顺序无关紧要。

    [cluster "HOSTNAME"]
      datacenter = default
      hostname = HOSTNAME
      ipv4 = IP-ADDRESS
      ...
    ...
    

    Note

    如果在步骤 3 中更改了主数据中心的名称,请在每个节点的部分找到 consul-datacenter 键值对,然后将值更改为重命名的主数据中心。 例如,如果已将主数据中心命名为 primary,请为每个节点使用以下键值对。

    consul-datacenter = primary
    
  5. 应用新配置。 此命令可能需要一些时间才能完成,因此我们建议在终端多路复用器(例如 screentmux)中运行该命令。

     ghe-cluster-config-apply
    
  6. 配置运行完成后,GitHub Enterprise Server 将显示以下消息。

    Finished cluster configuration
    

在 GitHub Enterprise Server 返回提示符,您已完成将节点分配给群集的主数据中心。

2.将副本节点添加到群集配置文件

若要配置高可用性,必须为群集中的每个主动节点定义相应的副本节点。 若要创建定义主动节点和副本节点的新群集配置,需要完成以下任务。

  • 创建主动群集配置文件的副本。
  • 编辑副本以定义与主动节点对应的副本节点,添加预配的新虚拟机的 IP 地址。
  • 将群集配置的修改副本合并回主动配置。
  • 应用新配置以开始复制。

有关示例配置,请参阅“查看示例配置”。

  1. 对于群集中的每个节点,预配规范相同的匹配虚拟机,运行相同版本的 GitHub Enterprise Server。 记下每个新群集节点的 IPv4 地址和主机名。 有关详细信息,请参阅“先决条件”。

    Note

    如果在故障转移后重新配置高可用性,可以改用主数据中心的旧节点。

  2. SSH 到集群中的任何节点。 有关详细信息,请参阅“访问管理 shell (SSH)”。

  3. 备份现有群集配置。

    cp /data/user/common/cluster.conf ~/$(date +%Y-%m-%d)-cluster.conf.backup
    
  4. 在临时位置创建现有群集配置文件的副本,例如 /home/admin/cluster-replica.conf

    grep -Ev "(?:|ipv|uuid)" /data/user/common/cluster.conf > ~/cluster-replica.conf
    
  5. 从上一步中复制的临时群集配置文件删除 [cluster] 部分。

    git config -f ~/cluster-replica.conf --remove-section cluster
    
  6. 确定在其中预配了副本节点的辅助数据中心的名称,然后使用新的数据中心名称更新临时群集配置文件。 将 SECONDARY 替换为所选名称。

    sed -i 's/datacenter = default/datacenter = SECONDARY/g' ~/cluster-replica.conf
    
  7. 确定副本节点主机名的模式。

    Warning

    副本节点的主机名必须是唯一的,并且与对应主动节点的主机名不同。

  8. 在文本编辑器中打开步骤 3 中的临时群集配置文件。 例如,您可以使用 Vim。

    sudo vim ~/cluster-replica.conf
    
  9. 在临时群集配置文件中的每个部分,更新节点的配置。 群集配置文件在 [cluster "HOSTNAME"] 标题下列出每个节点。

    • 根据上面步骤 7 中选择的模式,将部分标题中引用的主机名和部分中 hostname 的值更改为副本节点的主机名。
    • 新增一个名为 ipv4 的密钥,并将值设置为副本节点的静态 IPv4 地址。
    • 添加新的键值对 replica = enabled
    [cluster "NEW REPLICA NODE HOSTNAME"]
      ...
      hostname = NEW REPLICA NODE HOSTNAME
      ipv4 = NEW REPLICA NODE IPV4 ADDRESS
      replica = enabled
      ...
    ...
    
  10. 将步骤 4 中创建的临时群集配置文件的内容附加到活动的配置文件。

    cat ~/cluster-replica.conf >> /data/user/common/cluster.conf
    
  11. 在辅助数据中心中指定主 MySQL 和 Redis 节点。 将 REPLICA MYSQL PRIMARY HOSTNAMEREPLICA REDIS PRIMARY HOSTNAME 替换为预配的副本节点的主机名,以匹配现有的 MySQL 和 Redis 主节点。

    git config -f /data/user/common/cluster.conf cluster.mysql-master-replica REPLICA-MYSQL-PRIMARY-HOSTNAME
    git config -f /data/user/common/cluster.conf cluster.redis-master-replica REPLICA-REDIS-PRIMARY-HOSTNAME
    

    Warning

    在继续之前请检查群集配置文件。

    • 在顶级 [cluster] 部分中,确保 mysql-master-replicaredis-master-replica 的值是辅助数据中心中副本节点的正确主机名,这些副本节点将在故障转移后用作 MySQL 和 Redis 主节点。
    • 在名为 [cluster "ACTIVE NODE HOSTNAME"] 的主动节点的每个部分中,仔细检查以下键值对。
      • datacenter 应与顶级 [cluster] 部分中 primary-datacenter 的值匹配。
      • consul-datacenter 应与 datacenter 的值匹配,该值应与顶级 [cluster] 部分中 primary-datacenter 的值相同。
    • 确保每个主动节点的配置与一个包含相同角色的副本节点的配置具有一个相对应的部分。 在副本节点的每个部分中,仔细检查每个键值对。
      • datacenter 应与其他所有副本节点匹配。
      • consul-datacenter 应与其他所有副本节点匹配。
      • hostname 应与部分标题中的主机名匹配。
      • ipv4 应与节点的唯一静态 IPv4 地址匹配。
      • replica 应配置为 enabled
    • 利用机会删除已经不再使用的离线节点的部分。

    要查看示例配置,请参阅“查看示例配置”。

  12. 初始化新群集配置。 此命令可能需要一些时间才能完成,因此我们建议在终端多路复用器(例如 screentmux)中运行该命令。

    ghe-cluster-config-init
    
  13. 初始化完成后,GitHub Enterprise Server 将显示以下消息。

    Finished cluster initialization
    
  14. 应用新配置。 此命令可能需要一些时间才能完成,因此我们建议在终端多路复用器(例如 screentmux)中运行该命令。

     ghe-cluster-config-apply
    
  15. 配置运行完成后,请验证群集复制是否已正确设置并正常运行。

    ghe-cluster-repl-status
    
  16. 配置运行完成后,GitHub Enterprise Server 将显示以下消息。

    Finished cluster configuration
    
  17. 配置负载均衡器,故障转移到副本节点后,该均衡器将接受来自用户的连接。 有关详细信息,请参阅“群集网络配置”。

您已完成为群集中的节点配置高可用性副本。 每个主动节点开始将配置和数据复制到其对应的副本节点,并且您可以在发生故障时将流量直接引导至辅助数据中心的负载均衡器。 有关故障转移的详细信息,请参阅“发起到副本群集的故障转移”。

3.查看示例配置

顶级 [cluster] 配置应如下例所示。

[cluster]
  mysql-master = HOSTNAME-OF-ACTIVE-MYSQL-MASTER
  redis-master = HOSTNAME-OF-ACTIVE-REDIS-MASTER
  primary-datacenter = PRIMARY-DATACENTER-NAME
  mysql-master-replica = HOSTNAME-OF-REPLICA-MYSQL-MASTER
  redis-master-replica = HOSTNAME-OF-REPLICA-REDIS-MASTER
  mysql-auto-failover = false
...

群集存储层中主动节点的配置应如下所示。

...
[cluster "UNIQUE ACTIVE NODE HOSTNAME"]
  datacenter = default
  hostname = UNIQUE-ACTIVE-NODE-HOSTNAME
  ipv4 = IPV4-ADDRESS
  consul-datacenter = default
  consul-server = true
  git-server = true
  pages-server = true
  mysql-server = true
  elasticsearch-server = true
  redis-server = true
  memcache-server = true
  metrics-server = true
  storage-server = true
  uuid = UUID SET AUTOMATICALLY
...

存储层中对应的副本节点的配置应如下所示。

  • 与相应主动节点的重要区别以粗体显示。
  • GitHub Enterprise Server 将自动为 uuid 分配值,因此不应为要初始化的副本节点定义值。
  • *-server 密钥定义的服务器角色与相应的主动节点匹配。
...
[cluster "UNIQUE REPLICA NODE HOSTNAME"]
  replica = enabled
  ipv4 = IPV4 ADDRESS OF NEW VM WITH IDENTICAL RESOURCES
  datacenter = SECONDARY DATACENTER NAME
  hostname = UNIQUE REPLICA NODE HOSTNAME
  consul-datacenter = SECONDARY DATACENTER NAME
  consul-server = true
  git-server = true
  pages-server = true
  mysql-server = true
  elasticsearch-server = true
  redis-server = true
  memcache-server = true
  metrics-server = true
  storage-server = true
  uuid = DO NOT DEFINE
...

监控主动与副本群集节点之间的复制

群集中主动节点与副本节点之间的初始复制需要时间。 时间量取决于要复制的数据量和 GitHub Enterprise Server 的活动水平。

您可以通过 GitHub Enterprise Server 系统管理 shell 使用命令行工具监控群集中任何节点的进度。 有关管理 shell 的详细信息,请参阅“访问管理 shell (SSH)”。

若要监视所有服务的复制,请使用以下命令。

ghe-cluster-repl-status

你可以使用 ghe-cluster-status 查看群集的整体运行状况。 有关详细信息,请参阅“命令行实用程序”。

故障转移后重新配置高可用性复制

从群集的产动节点故障转移到群集的副本节点后,可以通过两种方式重新配置高可用性。 选择的方法将取决于故障转移的原因以及原始主动节点的状态。

  • 为辅助数据中心中的每个新主动节点预配和配置一组新的副本节点。
  • 使用原始主动节点作为新的副本节点。

重新配置高可用性的过程与高可用性的初始配置相同。 有关详细信息,请参阅“为群集创建高可用性副本”。

如果使用原始活动节点,在重新配置高可用性后,需要在节点上取消设置维护模式。 有关详细信息,请参阅“启用和排定维护模式”。

禁用群集的高可用性复制

可以使用 ghe-cluster-repl-teardown 实用工具停止复制到 GitHub Enterprise Server.

  1. SSH 到集群中的任何节点。 有关详细信息,请参阅“访问管理 shell (SSH)”。

  2. 在文本编辑器中,打开位于 /data/user/common/cluster.conf 的群集配置文件。 例如,您可以使用 Vim。 在编辑文件之前创建 cluster.conf 文件的备份。

    Shell
    sudo vim /data/user/common/cluster.conf
    
  3. 在顶级 [cluster] 部分中,删除 redis-master-replicamysql-master-replica 键值对。

  4. 删除副本节点的每个部分。 对于副本节点,replica 配置为 enabled

  5. 应用新配置。 此命令可能需要一些时间才能完成,因此我们建议在终端多路复用器(例如 screentmux)中运行该命令。

     ghe-cluster-config-apply
    
  6. 配置运行完成后,GitHub Enterprise Server 将显示以下消息。

    Finished cluster configuration