如何用阿里云极速型NAS构建高可用GitLab

使用阿里云文件存储NAS构建GitLab高可用环境

GitLab简介

GitLab 是一个基于 Ruby on Rails 开发的开源应用，说白了就是一套能自己托管的 Git 仓库管理平台，通过 Web 界面可以轻松访问公开或私有项目。Ruby on Rails 这个框架，让开发、部署、维护 Web 应用变得相当顺手。GitLab 的功能和 GitHub 很像，支持浏览源码、管理缺陷和注释，还能细致地控制团队对仓库的访问权限。浏览提交历史、查看文件变更记录，这些都是基础操作。它还有一个代码片段收集功能，方便日后复用——你懂的，写代码时经常需要翻以前的“宝贝”。

由于 Git 本身就是分布式的，即便 GitLab 服务挂了，开发人员照样能在本地提交代码。但问题来了：一旦 GitLab 不可用，CI 持续集成、问题跟踪这些核心功能就会瘫痪，线上业务也会受到严重影响。所以，为 GitLab 搭建高可用架构，绝不是“锦上添花”，而是“雪中送炭”。下面这张图是 GitLab 的软件架构全貌，先有个整体印象。

GitLab高可用设计

主备模式：启动2个实例，只有一个工作提供服务，数据通过分布式存储保持一致

主主模式（scales）：Rails server启动多个，同时提供服务，数据库保持独立，数据通过NAS文件存储共享

GitLab高可用方案

水平扩展

这种架构特别适合需要应对大量 GitLab 客户访问的场景——比如 API 调用率很高，或者 Sidekiq 任务队列排起了长队。它的核心组件配置如下：3 个 PostgreSQL 节点、2 个 Redis 节点、3 个 Consul/Sentinel 节点、2 个或更多 GitLab 应用节点（包括 Unicorn、Workhorse、Sidekiq、PGBouncer），以及 1 个 NFS/Gitaly 服务器。

混合扩展

这种方案的核心思路是把各个组件拆分到专用节点上，让它们各干各的，互不干扰。好处很明显：资源利用率高，不会出现服务争抢导致的高负载问题。典型配置包括：3 个 PostgreSQL 节点、1 个 PgBouncer 节点、2 个 Redis 节点、3 个 Consul/Sentinel 节点、2 个或更多 Sidekiq 节点、2 个或更多 GitLab 应用节点（Unicorn、Workhorse）、1 个或更多 NFS/Gitaly 服务器，再加上一个专门的监控节点（跑 Prometheus 和 Grafana）。

全分布式扩展

这套架构能轻松支撑几十万用户和项目，GitLab.com 的底层就是基于它设计的。不过话说回来，扩展能力强的背后是复杂度的飙升——节点数量、配置管理、监控运维的难度都上了一个台阶，维护成本不低。具体来看：3 个 PostgreSQL 节点、4 个或更多 Redis 节点（分成持久化和缓存两个独立集群）、3 个 Consul 节点、3 个 Sentinel 节点；多个专用的 Sidekiq 节点（按实时、尽力、 ASAP、CI 流水线、Pull Mirror 等任务类型拆分）；2 个或更多 Git 节点（处理 Git over SSH 和 Git over HTTP）；2 个或更多 API 节点（专门处理 /api 请求）；2 个或更多 Web 节点（处理其他 Web 请求）；2 个或更多 NFS/Gitaly 服务器。

阿里云文件存储NAS选型

GitLab 的使用场景有个显著特点：海量小文件、高并发读写。这类业务对文件系统的元数据操作性能要求极高——说白了，就是要 OPS 足够高、时延足够低。阿里云的极速型 NAS 正是为此而生，它后端基于 RDMA 网络做了时延优化，对于元数据密集型的应用场景表现非常突出。选它就对了。