极狐GitLab集群高可用方案，多节点架构与故障自愈实践
极狐GitLab集群高可用方案，多节点架构与故障自愈实践
集群高可用方案指通过多节点部署与组件级冗余，消除极狐GitLab研发平台中数据库、缓存、存储等单点故障，实现故障自动转移与持续可用。
一个单节点实例撑不住一家企业的研发命脉
很多团队从单节点极狐GitLab起步，跑了几百人规模一切正常，于是默认它永远不会挂。但单节点的风险从不体现在日常，而是体现在数据库损坏、磁盘故障、机房断网这些低频高损事件上。
研发平台一停，代码提交、合并请求、流水线、发布全部中断。对多数企业来说，这已经不是"运维事故"，而是研发组织停摆。
极狐GitLab在参考架构文档中把这件事讲得很直白：2,000用户以内建议单节点或非HA部署配合自动备份；3,000用户及以上建议完整HA架构。也就是说，HA不是可选项，而是规模的函数——用户量到了，可用性要求就到了。
三种部署形态，先把路选对
极狐GitLab官方提供了三种可投入生产的多节点形态，选择前先对号入座：
部署形态 | 组成方式 | 适用规模 |
|---|---|---|
Linux 软件包（Omnibus） | 全组件部署在虚拟机，PostgreSQL/Redis/对象存储可选云服务 | 1k / 2k / 3k / 5k / 10k / 25k / 50k 用户 |
云原生混合（Cloud Native Hybrid） | 无状态组件（Webservice、Sidekiq）用 Helm Chart 跑在 K8s，有状态组件留在 VM 或云服务 | 2k / 3k / 5k / 10k / 25k / 50k 用户 |
云原生（Cloud Native） | 全部组件进 K8s，PostgreSQL/Redis/对象存储用外部托管服务 | 小（≤100 RPS）/ 中（≤200）/ 大（≤500）/ 超大（≤1000 RPS） |
选型还有一条官方红线要注意：不支持在 K8s 中运行有状态组件（PostgreSQL、Redis），也不支持跨多个地域部署单个环境——高延迟与脑裂风险是硬约束。跨地域容灾请走 Geo 方案，那是另一个专题。
以3K参考架构为例，看清楚每个节点在干什么
3K架构（60 RPS / 3,000用户）是官方定义的实现HA的最小推荐规模。它的组件分工如下：
组件 | 节点数与规格 | HA机制 |
|---|---|---|
PostgreSQL | 3 × 2 vCPU / 7.5 GB | Patroni 管理 1主2从，故障自动转移 |
PgBouncer | 3 × 2 vCPU / 1.8 GB | 经内部负载均衡分发连接 |
Redis/Sentinel | 3 × 2 vCPU / 7.5 GB | 主从 + Sentinel 哨兵，quorum=2 自动选主 |
Gitaly | 3 × 4 vCPU / 15 GB | Gitaly Cluster，仓库多副本自动切换 |
Praefect | 3 × 2 vCPU / 1.8 GB | 事务代理，奇数节点法定人数 |
GitLab Rails | 3 × 8 vCPU / 7.2 GB | 无状态，负载均衡后横向扩展 |
Sidekiq | 2 × 4 vCPU / 15 GB | 后台任务横向扩展 |
Consul | 3 × 2 vCPU / 1.8 GB | 服务发现与健康检查 |
监控节点 | 1 × 2 vCPU / 1.8 GB | Prometheus 全链路指标 |
负载均衡 | 外部1 + 内部1，各 4 vCPU | 流量入口与组件间分发 |
这里体现了一个通用工程共识：HA的本质是把"单点"改成"奇数个节点的多数派"。PostgreSQL靠Patroni、Redis靠Sentinel、Gitaly Cluster靠Praefect，三套机制殊途同归。
故障自愈是怎么发生的
以数据库为例，三个PostgreSQL节点由Patroni托管。主库宕机时，Patroni在剩余两个从库中自动选出新主库，Rails应用通过数据库负载均衡（db_load_balancing配置）将读写路由到新主，全程无需人工介入。验证集群状态只需一条命令：
sudo gitlab-ctl patroni membersGit仓库层面，Gitaly Cluster把每个仓库复制到所有Gitaly节点，Praefect监控副本健康度，主Gitaly节点故障时自动提升新主，写入请求随即切换。
落地配置长什么样
PostgreSQL节点核心配置（/etc/gitlab/gitlab.rb）：
roles(['patroni_role', 'pgbouncer_role'])
patroni['postgresql']['max_replication_slots'] = 6
patroni['postgresql']['max_wal_senders'] = 7Rails节点连接数据库与Praefect：
gitlab_rails['db_host'] = '10.6.0.20'
gitlab_rails['db_port'] = 6432
gitlab_rails['db_load_balancing'] = { 'hosts' => ['10.6.0.21', '10.6.0.22', '10.6.0.23'] }
gitlab_rails['repositories_storages'] = {
"default" => { "gitaly_address" => "tcp://10.6.0.40:2305", "gitaly_token" => '<praefect_external_token>' }
}部署完成后按顺序验证：
sudo gitlab-ctl status——各节点服务状态全绿sudo /opt/gitlab/embedded/bin/consul members——Consul成员完整sudo gitlab-rake gitlab:gitaly:check——Gitaly连通性通过gitlab-ctl pgb-console后执行show databases;——PgBouncer连接正常
什么时候别一步到位上全套HA
官方在3K架构文档中给出了明确的伸缩口径：用户数或RPS低于3K但必须保证HA时，可以采用受支持的缩减修改——本质是同一架构的低性能版本，组件拓扑不变、规格下调。但除文档明确列出的修改外，其他缩减均不受支持。
另外三点实践经验值得放在决策清单里：
HA意味着每个组件成倍部署，成本会明显高于单节点，先算清可用性收益与预算的账
对象存储建议外置并替代NFS，每种数据类型独立bucket，性能与可靠性都更好
所有节点共享
/etc/gitlab/gitlab-secrets.json，这是极易遗漏的坑
如果当前规模还没到临界点，先把自动化备份与恢复演练做扎实，同样能拿到不错的RTO/RPO——高可用是渐进工程，不是一步登天。
常见问题
Q1：多少用户规模才需要上集群高可用？
官方建议2,000用户以内采用单节点或非HA部署配合自动备份；3,000用户及以上采用完整HA架构。若用户数不足3,000但必须保证HA，可使用官方支持的3K架构缩减修改。
Q2：Gitaly Cluster和普通Gitaly节点有什么区别？
普通Gitaly节点是单副本存储，节点故障时该节点上的仓库不可用。Gitaly Cluster通过Praefect将每个仓库复制到多个Gitaly节点，主节点故障自动转移，存储层无单点。
Q3：能不能把PostgreSQL部署在Kubernetes里实现高可用？
官方明确不支持在K8s中运行PostgreSQL、Redis等有状态组件。云原生混合架构中，这类组件应保留在虚拟机或使用外部托管服务，无状态的Webservice和Sidekiq才进K8s。
想评估贵司研发平台的可用性现状与多节点改造路径？可预约极狐GitLab专家演示，或先免费试用体验完整的企业级能力。更多架构细节可直达官方文档中心。
