Gitlab支持几种不同类型的集群和高可用。生产中选择的解决方案都应该基于业务的需求和整体考虑，然后确认可扩展性和可用性级别。最简单的解决方案是可扩展的，但不一定高度可用。这需要使用者做一个权衡。
由于Git的分布式特性，即使Gitlab不可用，开发人员仍然可以在本地提交代码。但是,某些Gitlab功能，比如CI，问题跟踪和持续集成会不可用，也会严重影响线上使用。因此高可用架构还是不可缺少的。
注意：所有高可用性解决方案都需要在成本/复杂性和正常运行时间之间进行权衡。您想要的正常运行时间越多，解决方案就越复杂。而且解决方案越复杂，设置和维护它的工作就越多。高可用性不是免费的，每个HA解决方案都应该平衡成本和收益。
Gitlab基础设施工程师对于Gitlab如何扩展等问题1小时解答： this 1 hour Q&A with John Northrup
GitLab 的数据持久层主要由三部分组成：一是文件系统，因为 GitLab 背后是通过调用 libgit2、git 命令、grit 来访问和操作存储在服务器文件系统上的 git 仓库；二是MySQL，这个是用来持久化用户、权限、Merge Request 这些页面交互数据用的；还有Redis，主要作 Sidekiq 的任务队列和 Rails 的缓存用。其实他们还支持 PostgreSQL，因为 ActiveRecord 抽象掉了底层数据源的具体实现。由于Gitlab没有遵守十二法则的第四条：“把后端服务当作附加资源”。对应用程序而言，不管是数据库、消息队列还是缓存，都应该是附加资源，通过一个 url 或是其他存储在配置中的服务定位来获取数据；部署应可以按需加载或卸载资源。然而 GitLab 系统中的三个组件——libgit2、git、grit,都是直接作用在文件系统上的，Gitlab社区版其实是“单机”模式。
在最高层，Nginx 和 OpenSSH 分别用来接收客户端发来的 HTTP 和 SSH 请求。首先，当客户端发来的是一个 HTTP 页面请求，那么它会进入下一层的 Unicorn 进程，进而利用第三层的诸多 gem 获取关于仓库的信息或对仓库进行操作，这些 gem 包会调到第四层，通过调用原生 git 命令或通过调用 libgit2 中的函数对存在磁盘上的 git 仓库进行实际的访问和操作。其次，当客户端发来的是 HTTP 协议下的 git 操作，那么这个操作将直接被转向给 GitLab Workhorse，它会进一步借助 Unicorn 验证用户的操作权限，之后便将操作全然代理给第四层的原生 git 命令。因为这种请求不同于页面请求，是 I/O 繁重型，因此 GitLab Workhorse 用 go 写成，而不是 Ruby。最后，当客户端发来的是 SSH 协议下的 git 操作，OpenSSH 会在用户认证登陆成功后启动一个特殊的 shell——亦即 GitLab Shell——来调用第四层的原生 git 命令，而这个 shell 跟 Workhorse 类似，自身也不含用户逻辑，必须再内部调用 Unicorn 才能完成用户认证与鉴权工作。
目前Gitlab使用的两种主流方案：
大规模使用方案：应用层修改Gitlab实现分发架构，RPC转发通讯，利用Gitlab Hook来同步仓库。
小规模使用方案：保证准实时的仓库数据同步，配置备用环境，服务异常可立即切换。
官方推荐的两种方式：
1.主备模式
2.主主模式(scales)：Rails server启动多个，同时提供服务，数据库保持独立，数据通过NFS共享
2.Gitlab高可用解决方案
2.1 基本扩展
大多数在云环境或者部署小节点情况适用于这种基本扩展方案：将后端组件如(PG/Mysql、Redis和存储)安装在数据节点做好备份，而其余的Gitlab组件部署在2个或者更多分结点上 ，相比于单个较大节点收益更高且维护简单。
1 PostgreSQL节点
1个Redis节点
2个或更多GitLab应用程序节点（Unicorn，Workhorse，Sidekiq）
1个NFS / Gitaly存储服务器
2.2 完全扩展
对于大的，对可用性要求很高的复杂架构，需要拆分组件以获得最大的可扩展性，应用程序节点被拆分为单独的Sidekiq和Unicorn / Workhorse节点，以提供足够的资源支持和可用性。
2个或更多 PostgreSQL节点
3个或更多 Redis节点
2个或更多GitLab应用程序节点（Unicorn，Workhorse）
2个或更多Sidekiq节点
2个或更多NFS / Gitaly存储服务器
2.3 水平扩展
这种架构适用于许多Gitlab客户访问的使用场景，解决高API使用率，大量排队的Sidekiq作业的问题。
2.4 纵向拆分
这种架构通过组件在专用节点上分离，提供高资源使各组件不会相互干扰，解决服务争用/高负载的问题。
以上两种架构推荐组件配置：
2 PostgreSQL节点
2个Redis节点
3个Consul / Sentinel节点
2个或更多GitLab应用程序节点（Unicorn，Workhorse，Sidekiq，PGBouncer）
1个NFS / Gitaly服务器
2.5 分布式架构
该体系结构可扩展到数十万用户和项目，是GitLab.com体系结构的基础。 虽然分布式架构可以很好地扩展，但它增加了节点的复杂性，配置，管理和监控的难度，不易维护。
2 PostgreSQL节点
4个或更多Redis节点（2个独立的簇用于持久性和缓存数据）
3个领事节点
3个Sentinel节点
多个专用Sidekiq节点（分为实时，尽力，ASAP，CI管道和拉镜组）
2个或更多Git节点（基于HTTP的Git over SSH / Git）
2个或更多API节点（对/ api的所有请求）
2个或更多Web节点（所有其他Web请求）
2个或更多NFS / Gitaly服务器
参考：
