Skip to main content

Enterprise Server 3.20 目前作为发布候选版本提供。

将节点添加到高可用性配置

将节点添加到主要高可用性(HA)数据中心。 这旨在从主节点卸载 CPU 密集型任务,从而允许 GitHub Enterprise Server 实例水平扩展。

注意

向 HA 添加其他计算节点的功能位于 公共预览版 中,并可能会更改。 在预览期间,请与客户成功团队共享任何反馈。

对于 GitHub Enterprise Server 客户而言,希望实现水平扩展可以考虑迁移到并操作集群,但这需要大量资源且耗时。 作为替代方法,我们建议将节点添加到 HA 配置。

本文中可互换使用术语“其他节点”和“无状态节点”。 无状态节点只能添加到包含至少一个副本的 HA 部署。

其他节点

在 GitHub Enterprise Server 设备上运行的所有服务中,Unicorn 通常是 CPU 和内存最密集的服务,紧随其后的是 Aqueduct、Git 和 MySQL。 由于 Unicorn 和 Aqueduct 是无状态服务,因此它们非常适合水平缩放,可以在一组单独的节点上运行。 其余服务可以继续使用每个数据中心的单个实例运行。

附加节点允许您水平扩展 Web 和任务工作负载。 它们还可以将 Unicorn 和 Aqueduct 从主节点迁移走,为剩余的有状态服务释放大量的计算和内存资源。 如果由于 Unicorn 实例的 CPU 使用率较高而遇到性能相关的服务中断,建议添加其他节点。 在数据中心内可以添加的这些节点的数量没有重大限制。

条件

如果由于 HA 配置中的重载主节点而导致性能下降,应考虑将其他节点添加到 HA 环境。 通过在主节点之外水平缩放 Web 角色和作业角色,这些额外的节点可以帮助减少主主机上的负载。

例如,如果你注意到 Unicorn 或 Aqueduct 队列中积压工作,或者遇到其他类型的资源争用,则应考虑此方法。 即使没有可见的队列,主节点上的 CPU 耗尽也是另一个明确的信号。 在这些情况下,可以添加其他节点并减少每个节点的工作器数,因此主节点处理的总体工作负荷更少。

添加节点

在 HA 部署中添加的每个节点都是运行 GitHub Enterprise Server 软件的虚拟机(VM)。 它应运行与主系统相同的软件。 通常,无状态节点不需要与主节点的内存、CPU 或存储规范匹配。 但是,无状态节点和主实例都需要子毫秒连接。 副本连接要求保持不变。

若要将节点添加到 HA 配置中的主数据中心,请使用 ghe-add-node 命令。 该 ghe-add-node 命令将当前设备设置为 HA 部署中的节点,旨在从主数据节点卸载 CPU 密集型任务,从而启用水平缩放。 这些节点旨在处理 Web 和作业工作负荷,从而提高工作负荷分发和管理效率。 此命令采用以下格式:

Shell
/usr/local/share/enterprise/ghe-add-node PRIMARY_IP [--hostname HOSTNAME]
  •         `PRIMARY_IP`:主节点的 IP 地址。
    
  •         `HOSTNAME` (可选):所添加主机的所需主机名。
    

例如,若要将主机名 ghes-node-1 的节点添加到 HA 主数据中心具有 IP 地址 192.168.1.1 的 HA 主实例,请运行以下命令:

Shell
/usr/local/share/enterprise/ghe-add-node 192.168.1.1 --hostname ghes-node-1

然后,在主节点上,必须运行以下命令:

Shell
ghe-config-apply
ghe-cluster-balance rebalance --yes

此命令 ghe-config-apply 是添加无状态节点的要求。

对于公共预览版,我们尚未专门测试停机时间,目前还不清楚是否需要维护时段。

删除其他节点

若要删除节点,请从要删除的节点运行 ghe-remove-node 。 然后,您必须在主节点上运行:

Shell
ghe-config-apply

此命令 ghe-config-apply 是删除无状态节点的要求。

对于公共预览版,我们尚未专门测试停机时间,目前还不清楚是否需要维护时段。

重新预配以前托管 GitHub Enterprise Server 的节点

可以将之前托管和运行GitHub Enterprise Server的节点用作无状态节点。 为此,节点应更新到版本 3.18 或更高版本,并且部署中的所有节点都必须运行相同的版本。 请检查在该节点上,/data/user/common/cluster.conf 是否已存在。 如果这样做,则需要在无状态节点上运行 ghe-add-node 命令之前执行清理。

例如:

Shell
sudo rm -f /etc/github/cluster /data/user/common/cluster.conf
sudo timeout -k4 10 systemctl stop wireguard 2>/dev/null || sudo ip link delete tun0 || true

限制和行为

可以添加的节点数没有理论限制。 但是,在实践中,添加过多的节点可能会导致问题并影响稳定性或性能。 此时,新添加的节点将处理一组预定义的任务。 无法选择要卸载的任务类型。 所有 API 都可以由其他节点处理。

如果 Git 操作位于路径中,则只有逻辑可在主节点上处理 Git 操作。 其他节点不会处理 Git 操作。 例如,分支删除是 Git 操作,不会由无状态节点处理。

无状态节点不运行 Elasticsearch 工作负载,但它们确实运行 kafka-lite。

系统和网络要求

通常,无状态节点不需要与主节点的内存、CPU 和存储规格匹配。 系统要求应考虑到主节点上 Web 和作业服务的现有资源消耗,以及主节点是否会将这些工作负荷完全卸载到新节点。

无状态节点和主实例需要子毫秒连接。 通常,主数据中心内的所有节点都需要子毫秒连接。 副本连接要求保持不变。

流量路由和请求处理

主节点将流量路由到其他节点。 如果有多个无状态节点,主节点会选择当前活动连接最少的服务器将新连接发送给它。

使用其他节点升级 HA 部署

下面是升级序列示例:

  • 启动维护时间窗口。
  • 停止复制副本。
  • 并行地升级无状态节点。
  • 升级主节点。
  • 升级副本。 可以根据灾难恢复首选项并行或按顺序升级它们。
  • 启动副本。
  • 删除维护时段。

在升级期间,其他节点不应造成额外的停机。

故障转移和灾难恢复行为

无需“拆解”其他节点,因为它们不包含任何数据。

在故障转移期间,副本节点将从原始部署中删除,并转换为独立节点。 无状态节点应重新连接到已提升为主副本的节点上,类似于故障转移后其他副本重新连接的方式。

如果主节点正常运行,并且想要将副本提升为主节点,则应使用 ghe-remove-node 命令从主节点中删除无状态节点,然后再将其重新添加到已升级的节点。

如果主节点无法访问且不可恢复,则可以重新添加无状态节点,而无需从原始主节点中删除它们。

监控、日志和支持包

在主节点上,管理控制台监视仪表板显示所有节点(包括无状态节点)的指标。 诸如ghe-cluster-nodesghe-cluster-status的命令包含无状态节点的详细信息。 所有管理控制台请求都由主节点提供。

日志存储在无状态节点上。 可以将这些节点导出到第三方日志管理服务。

可以使用 ghe-cluster-support-bundleghe-support-bundle 命令生成并上传集群或单节点捆绑包。

已知的限制

此功能不是针对 monorepos 设计的,但添加新的无状态节点可能会通过减少主节点上的 Web 和作业工作负荷间接改善 monorepo 操作。 没有自动缩放和缩减功能。