注意
向 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 和作业工作负荷,从而提高工作负荷分发和管理效率。
此命令采用以下格式:
/usr/local/share/enterprise/ghe-add-node PRIMARY_IP [--hostname HOSTNAME]
/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 主实例,请运行以下命令:
/usr/local/share/enterprise/ghe-add-node 192.168.1.1 --hostname ghes-node-1
/usr/local/share/enterprise/ghe-add-node 192.168.1.1 --hostname ghes-node-1
然后,在主节点上,必须运行以下命令:
ghe-config-apply ghe-cluster-balance rebalance --yes
ghe-config-apply
ghe-cluster-balance rebalance --yes
此命令 ghe-config-apply 是添加无状态节点的要求。
对于公共预览版,我们尚未专门测试停机时间,目前还不清楚是否需要维护时段。
删除其他节点
若要删除节点,请从要删除的节点运行 ghe-remove-node 。 然后,您必须在主节点上运行:
ghe-config-apply
ghe-config-apply
此命令 ghe-config-apply 是删除无状态节点的要求。
对于公共预览版,我们尚未专门测试停机时间,目前还不清楚是否需要维护时段。
重新预配以前托管 GitHub Enterprise Server 的节点
可以将之前托管和运行GitHub Enterprise Server的节点用作无状态节点。 为此,节点应更新到版本 3.18 或更高版本,并且部署中的所有节点都必须运行相同的版本。 请检查在该节点上,/data/user/common/cluster.conf 是否已存在。 如果这样做,则需要在无状态节点上运行 ghe-add-node 命令之前执行清理。
例如:
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
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-nodes和ghe-cluster-status的命令包含无状态节点的详细信息。 所有管理控制台请求都由主节点提供。
日志存储在无状态节点上。 可以将这些节点导出到第三方日志管理服务。
可以使用 ghe-cluster-support-bundle 和 ghe-support-bundle 命令生成并上传集群或单节点捆绑包。
已知的限制
此功能不是针对 monorepos 设计的,但添加新的无状态节点可能会通过减少主节点上的 Web 和作业工作负荷间接改善 monorepo 操作。 没有自动缩放和缩减功能。