关于集群的高可用性复制
您可以配置 GitHub Enterprise Server 的群集部署以实现高可用性,其中一组相同的被动节点与活动群集中的节点同步。 如果硬件或软件故障影响具有活动群集的数据中心,您可以手动故障转移到副本节点,继续处理用户请求,以尽可能减少中断的影响。
在高可用性模式下,每个活动节点定期与相应的被动节点同步。 被动节点在待机状态下运行,不服务于应用程序或处理用户请求。
我们建议配置高可用性,作为 GitHub Enterprise Server 全面灾难恢复计划的一部分。 我们还建议进行定期备份。 有关详细信息,请参阅“在设备上配置备份”。
先决条件
硬件和软件
对于活动群集中的每个现有节点,都需要预配第二个具有相同硬件资源的虚拟机。 例如,如果� 的群集有 11 个节点,并且每个节点有 12 个 vCP、96 GB 的 RAM 和 750 GB 的附� 存储,则必须预配 11 个新虚拟机,每个虚拟机具有 12 个 vCPU、96 GB 的 RAM 和 750 GB 的附� 存储。
在每个新虚拟机上,安装活动群集的节点上运行的相同版本 GitHub Enterprise Server。 您不需要上� 许可证或执行任何其他配置。 有关详细信息,请参阅“设置 GitHub Enterprise Server 实例”。
注意: � 打算用于高可用性副本的节点应该是独立的 GitHub Enterprise Server 实例。 不要将被动节点初始化为第二个群集。
网络
您必须为预配的每个新节点分配一个静态 IP 地址,并且必须配置负载均衡器以接受连接,并将其引导到群集前端层中的节点。
我们不建议在具有主动群集的网络和具有被动群集的网络之间配置防火墙。 具有主动节点的网络与具有被动节点的网络之间的延迟必须小于 70 毫秒。 有关被动群集中节点之间网络连接的详细信息,请参阅“网络配置”。
为群集创建高可用性副本
将主动节点分配到主数据中心
在为被动节点定义辅助数据中心之前,请确保将活动节点分配给主数据中心。
-
SSH 到集群中的任何节点。 有关详细信息,请参阅“访问管理 shell (SSH)”。
-
在文本编辑器中打开 /data/user/common/cluster.conf 中的群集配置文件。 例如,您可以使用 Vim。
sudo vim /data/user/common/cluster.conf
-
记下群集主数据中心的名称。 群集配置文件顶部的
[cluster]
部分使用primary-datacenter
键值对定义主数据中心的名称。 默认情况下,群集的主数据中心名为default
。[cluster] mysql-master = HOSTNAME redis-master = HOSTNAME primary-datacenter = default
- (可选)通过编辑
primary-datacenter
的值,将主数据中心的名称更改为更具描述性或更准确的值。
- (可选)通过编辑
-
群集配置文件在
[cluster "HOSTNAME"]
� �题下列出每个节点。 在每个节点� �题下,添� 新的键值对,以将节点分配给数据中心。 使用上述第 3 步中primary-datacenter
所用的值。 例如,如果要使用默认名称 (default
),请将以下键值对添� 到每个节点的部分。datacenter = default
完成后,群集配置文件中每个节点的部分应如下所示。 键值对的顺序� 关紧要。
[cluster "HOSTNAME"] datacenter = default hostname = HOSTNAME ipv4 = IP ADDRESS ... ...
注意: 如果在步骤 3 中更改了主数据中心的名称,请在每个节点的部分找到
consul-datacenter
键值对,然后将值更改为重命名的主数据中心。 例如,如果已将主数据中心命名为primary
,请为每个节点使用以下键值对。consul-datacenter = primary
-
应用新配置。 此命令可能需要一些时间才能完成,� 此我们建议在终端多路复用器(例如
screen
或tmux
)中运行该命令。ghe-cluster-config-apply
-
配置运行完成后,GitHub Enterprise Server 将显示以下消息。
Finished cluster configuration
在 GitHub Enterprise Server 返回提示符,您已完成将节点分配给群集的主数据中心。
将被动节点添� 到群集配置文件
要配置高可用性,必须为群集中的每个主动节点定义相应的被动节点。 以下说明创建用于定义主动节点和被动节点的新群集配置。 � 将:
- 创建主动群集配置文件的副本。
- 编辑副本以定义与主动节点对应的被动节点,添� 预配的新虚拟机的 IP 地址。
- 将群集配置的修改副本合并回主动配置。
- 应用新配置以开始复制。
有关示例配置,请参阅“示例配置”。
-
对于群集中的每个节点,预配规范相同的匹配虚拟机,运行相同版本的 GitHub Enterprise Server。 记下每个新群集节点的 IPv4 地址和主机名。 有关详细信息,请参阅“先决条件”。
注意: 如果在故障转移后重新配置高可用性,可以改用主数据中心的旧节点。
-
SSH 到集群中的任何节点。 有关详细信息,请参阅“访问管理 shell (SSH)”。
-
备份现有群集配置。
cp /data/user/common/cluster.conf ~/$(date +%Y-%m-%d)-cluster.conf.backup
-
在临时位置创建现有群集配置文件的副本,例如 /home/admin/cluster-passive.conf。 � 除 IP 地址的唯一键值对 (
ipv*
)、UUID (uuid
) 和 WireGuard 的公钥 (wireguard-pubkey
)。grep -Ev "(?:|ipv|uuid|vpn|wireguard\-pubkey)" /data/user/common/cluster.conf > ~/cluster-passive.conf
-
从上一步中复制的临时群集配置文件� 除
[cluster]
部分。git config -f ~/cluster-passive.conf --remove-section cluster
-
确定在其中预配了被动节点的辅助数据中心的名称,然后使用新的数据中心名称更新临时群集配置文件。 将
SECONDARY
替换为所选名称。sed -i 's/datacenter = default/datacenter = SECONDARY/g' ~/cluster-passive.conf
-
确定被动节点主机名的模式。
警告:被动节点的主机名必须是唯一的,并且与对应主动节点的主机名不同。
-
在文本编辑器中打开步骤 3 中的临时群集配置文件。 例如,您可以使用 Vim。
sudo vim ~/cluster-passive.conf
-
在临时群集配置文件中的每个部分,更新节点的配置。 群集配置文件在
[cluster "HOSTNAME"]
� �题下列出每个节点。- � �据上面步骤 7 中选择的模式,将部分� �题中引用的主机名和部分中
hostname
的值更改为被动节点的主机名。 - 新增一个名为
ipv4
的密钥,并将值设置为被动节点的静态 IPv4 地址。 - 添� 新的键值对
replica = enabled
。
[cluster "NEW PASSIVE NODE HOSTNAME"] ... hostname = NEW PASSIVE NODE HOSTNAME ipv4 = NEW PASSIVE NODE IPV4 ADDRESS replica = enabled ... ...
- � �据上面步骤 7 中选择的模式,将部分� �题中引用的主机名和部分中
-
将步骤 4 中创建的临时群集配置文件的内容附� 到活动的配置文件。
cat ~/cluster-passive.conf >> /data/user/common/cluster.conf
-
在辅助数据中心中指定主 MySQL 和 Redis 节点。 将
REPLICA MYSQL PRIMARY HOSTNAME
和REPLICA 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
警告:在继续之前请检查群集配置文件。
- 在顶级
[cluster]
部分中,确保mysql-master-replica
和redis-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
。
- 利用机会� 除已经不再使用的离线节点的部分。
要查看示例配置,请参阅“示例配置”。
- 在顶级
-
初始化新群集配置。 此命令可能需要一些时间才能完成,� 此我们建议在终端多路复用器(例如
screen
或tmux
)中运行该命令。ghe-cluster-config-init
-
初始化完成后,GitHub Enterprise Server 将显示以下消息。
Finished cluster initialization
-
应用新配置。 此命令可能需要一些时间才能完成,� 此我们建议在终端多路复用器(例如
screen
或tmux
)中运行该命令。ghe-cluster-config-apply
-
配置运行完成后,GitHub Enterprise Server 将显示以下消息。
Finished cluster configuration
-
配置负载均衡器,如果故障转移到被动节点,该均衡器将接受来自用户的连接。 有关详细信息,请参阅“群集网络配置”。
您已完成为群集中的节点配置高可用性副本。 每个主动节点开始将配置和数据复制到其对应的被动节点,并且您可以在发生故障时将流量直接引导至辅助数据中心的负载均衡器。 有关故障转移的详细信息,请参阅“发起到副本群集的故障转移”。
配置示例
顶级 [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 PASSIVE MYSQL MASTER
redis-master-replica = HOSTNAME OF PASSIVE 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
vpn = IPV4 ADDRESS SET AUTOMATICALLY
uuid = UUID SET AUTOMATICALLY
wireguard-pubkey = PUBLIC KEY SET AUTOMATICALLY
...
存储层中对应的被动节点的配置应如下所示。
- 与相应主动节点的重要区别以粗体显示。
- GitHub Enterprise Server 自动为
vpn
、uuid
和wireguard-pubkey
分配值,� 此不应为要初始化的被动节点定义值。 *-server
密钥定义的服务器角色与相应的主动节点匹配。
...
[cluster "UNIQUE PASSIVE NODE HOSTNAME"]
replica = enabled
ipv4 = IPV4 ADDRESS OF NEW VM WITH IDENTICAL RESOURCES
datacenter = SECONDARY DATACENTER NAME
hostname = UNIQUE PASSIVE 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
vpn = DO NOT DEFINE
uuid = DO NOT DEFINE
wireguard-pubkey = DO NOT DEFINE
...
监控主动与被动群集节点之间的复制
群集中主动节点与被动节点之间的初始复制需要时间。 时间量取决于要复制的数据量和 GitHub Enterprise Server 的活动水平。
您可以通过 GitHub Enterprise Server 系统管理 shell 使用命令行工具监控群集中任何节点的进度。 有关管理 shell 的详细信息,请参阅“访问管理 shell (SSH)”。
-
监控数据库的复制:
/usr/local/share/enterprise/ghe-cluster-status-mysql
-
监控仓库和 Gist 数据的复制:
ghe-spokes status
-
监控附件和 LFS 数据的复制:
ghe-storage replication-status
-
监控 Pages 数据的复制:
ghe-dpages replication-status
� 可以使用 ghe-cluster-status
查看群集的整体运行状况。 有关详细信息,请参阅“命令行实用工具”。
故障转移后重新配置高可用性复制
从群集的产动节点故障转移到群集的被动节点后,您可以通过两种方式重新配置高可用性副本。
预配和配置新的被动节点
故障转移后,您可以通过两种方式重新配置高可用性。 选择的方法将取决于故障转移的原� 以及原始主动节点的状态。
-
为辅助数据中心中的每个新主动节点预配和配置一组新的被动节点。
-
将旧的主动节点用作新的被动节点。
重新配置高可用性的过程与高可用性的初始配置相同。 有关详细信息,请参阅“为群集创建高可用性副本”。
禁用群集的高可用性复制
您可以停止复制到 GitHub Enterprise Server 群集部署的被动节点。
-
SSH 到集群中的任何节点。 有关详细信息,请参阅“访问管理 shell (SSH)”。
-
在文本编辑器中打开 /data/user/common/cluster.conf 中的群集配置文件。 例如,您可以使用 Vim。
sudo vim /data/user/common/cluster.conf
-
在顶级
[cluster]
部分中,� 除redis-master-replica
和mysql-master-replica
键值对。 -
� 除被动节点的每个部分。 对于被动节点,
replica
配置为enabled
。 -
应用新配置。 此命令可能需要一些时间才能完成,� 此我们建议在终端多路复用器(例如
screen
或tmux
)中运行该命令。ghe-cluster-config-apply
-
配置运行完成后,GitHub Enterprise Server 将显示以下消息。
Finished cluster configuration
在 GitHub Enterprise Server 返回提示后,您已完成禁用高可用性复制操作。