GitLab 的高可用性

什么是高可用性?

高可用性是一个被设计用来确保在一段预定时间内保持预定水平的运行性能. 衡量 HA 的通用方式是使用正常运行时间的概念, 用来测量服务能运行多长时间.

GitLab 提供了一个对大多数组织而言常常很重要的功能: 它能使人们能进行及时的代码协作. 任何停机时间都是短暂而有计划的. 幸运的是，GitLab 提供了一个稳定的设置，即使实在一个没有特别措施的服务器上也能应用. 而由于分布式的天然特性，即使GitLab不能使用，git使用者也仍然能够提交代码. 不过，GitLab的一些特性，比如问题追踪和持续集成在GitLab崩溃的时候还是不能用的.

一定要记住高可用性的解决方案带来了一个成本/复杂性和正常运行时间之间的权衡。越长的运行时间意味着解决方案越复杂。并且解决方案越复杂，就带来了更多安装和维护的工作。高可用性不是免费的，每一个高可用性的方案都要在投资和回报之间权衡。

高可用性对你来说

两个你要经常问自己的问题：

1. 对于代码可用性我有什么特殊需求?

2. 我们的团队能够处理什么级别的复杂度?

高可用性的方案范围涵盖了从廉价的简单备份到昂贵的master-master配置。 不幸的是，在高可用性这方面还没有办法将复杂度的提升和成本的提升分开来。

我们建议你深入的对HA的优势及其成本进行一下对比分析. 大多数选择GitLab高可用性方案的组织，都是因为它没有那些直接产生收入的面向主要客户的基础设施那么复杂.  重要的是总是应该选择你已经尝试过并定期测试过的那些东西 . 糟糕的HA方案造成的宕机时间比它所解决的要多得多. 例如  DRBD 用户指南 描述到 : “通过配置自动恢复策略，你可以高效的配置出自动的数据丢失故障!”.  从一个简单方案逐渐过渡到更加复杂的方案比其它的方式更加符合成本效益. 因此，我们建议你从最简单的方案开始，逐步选择最适合你的方案.

成熟度等级

1. 文件和数据库的备份

自动的对GitLab的资源库、配置和数据库进行备份是可能的。你可以使用 GitLab备份任务 来 对备份进行管理: 用 `rake gitlab:backup:create` 创建备份，并用 `rake gitlab:backup:restore` 来进行恢复. 万一服务器不可用了，备份就可以用来恢复GitLab的安装. 此方案适用于那些拥有一台物理服务器的团队. 我们建议你将备份存储到一个外部的服务器. 同时我们还建议你将备份任务进行自动化，并对备份过程进行监控.    

2. 从快照进行恢复

可以创建一个工作服务器的快照. 快照是服务器上所有文件的一个副本. 万一宕机了，就可以手动恢复到最近的可用快照. 如果有第二个位置可用，就有可能自动还原成快照，不需要人来操心.

一般都会用虚拟机来实现; 有许多方案都提供了快照功能. 不过也有肯能使用 XFS 文件系统来实现快照.

从快照恢复比从上面提到的备份恢复要快. 如果使用后者，你就一般要重新安装GitLab，手动重置所有的定制配置，只有在这些操作之后才能执行 `rake gitlab:backup:restore` 进行操作. 从快照恢复就可以跳过这些额外的人工步骤.

如果你使用快照来将GitLab服务器恢复到另一台机器上，你应该考虑到IP地址冲突的问题。为了确保每个人都能快速使用新服务器，最常用的是升级 DNS网关。这样，由于服务器的替换，新机器必须使用新的IP地址，或者，快照应该使用同样的OpenSSH服务验证。否则，通过SSH登录到 GitLab客户端的用户会看到“WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED”，因为服务器验证和GitLab的IP地址不匹配。

这种IP地址不匹配的问题可以使用浮动的IP来解决，浮动IP可以在路由器中进行故障转移。但是这种方法必须得到路由设备和网络的支持。如果新地址在一个二级网络环境，那么，每个地址都需要在同一个网络，使用同一个核心路由。

使用快照做恢复最适合单台虚拟服务器。

3. 多应用服务器

将应用服务器, 文件系统和数据库分开也是可行的. 如果条件允许, 你可以利用负载平衡器, 给多任务应用服务器分配任务.  这样做的好处是, 当其中一个应用服务器崩溃, 工作流程(workflow )不会因此中断.  但会因为服务器数量减少, 速度变慢.

配置如下图所示        

由于本方案需要用到文件共享系统(NFS), 所以, 必须使用 GitLab 6.0 或以上版本, 只有这些版本才将 satellite 放在共享磁盘上. 此外, 你应该将文件存储和数据库分开放到不同的服务器上. 而且, 文件存储和数据库应该使用各自的恢复协议(如: 快照, 备份).

4. 单个辅助服务器

如果你的方案, 只计划使用两台服务器, 我们建议你把其中一台设为辅助服务器(Slave Server). 在 这种配置下,  每台机器都有相同的 GitLab 资源库, 配置, 和数据库. 辅助服务器的作用是备份主服务器的文件. 你可以通过分布式复制块设备(Distributed Replicated Block Device,  DRBD), 确保主服务器上的所有数据, 都及时复制到辅助服务器上.

若要手动故障转移(Manual failover),  只要挂载(mounting )辅助服务器上的文件存储器(file storage)就可以. 此时, 辅助服务器会变成主服务器. 注意, 要将故障服务器(unavailable server) 关闭或脱离网络.  以免它又重新上线, 成为主服务器.

不管主服务器和辅助服务器, 是放在同一个机房, 还是分隔两地, 这种方式都行得通.

5. 文件存储和DBMS从服务器

不可能把多个应用服务器的解决方案放在一个从服务器上. 在这种情况下，你需要另外的多个无状态应用服务器和一个文件存储，以及DBMS从服务器。

在这种解决方案中， 用户仍然会通过负载均衡应用服务器连接， 但是文件存储和DBMS会被从一个数据中心或另一个位置拷贝到一个或多个从服务器中。 分布式复制块设备（Distributed Replicated Block Device） (DRBD) 可以被用来从主文件存储和DBMS服务器中传递数据到从服务器中。

在GitLab的应用服务器上只有很少的状态，因此我们不推荐有从应用服务器单边的文件存储和DBMS。使用负载均衡的结果有同样的效果，但是更简 单。自动化备灾可以实现定制化STONITH（Shoot The Other Node In The Head）的网络管理。准备为传输到新的网络地址，需要保持应用服务器的状态。 PostgreSQL.在这个解决方案中你可能需要通过一个数据库特殊协议替换DRBD去同步数据库，在这篇文档中你可以找到关于 MySQL 和 PostgreSQL 的相关选项。

6. 集群的/主节点-主节点（master-master） 文件存储和 DBMS

集群一直是众所周知的分布式解决方案。GitLab的目的解决一个主节点/主节点解决方案(性能)下降这一类的问题。集群解决方案比主-从解决方案更难安装和维护。 但是他们可以给故障提供更多的弹性，并且给予你超越单一文件存储或dbms服务器的能力。

集群模式在这两种模式（同步和异步）中更有效。一个同步的集群配置需要广播每一个变更到每一台服务器，这是一个耗时的处理。 这是同步解决方案中的一个基本缺点， 当这些服务器在地理上接近时，这个方案是可行的。 否则对于终端用户来说系统就会变得非常慢。

如果以异步的方式通信会大大提高处理速度。但是这样又可能导致服务器之间的数据不兼容，比如可能会创建两个拥有相同用户名的账户。GitLab没有解决这种问题的方法，因此使用异步通信机制对于GitLab来讲是行不通的。

文件存储的HA方案可以选择使用各种分布式文件系统, 比如GFS2, VMFS 和 Ceph。另外还可以选择使用一个水平扩展设备，比如IBM的NASA或者EMC Isilon。而DBMS也有诸多选择：Oracle的MySQL Cluster和PostgreSQL’s clustering solutions。

在不久的将来GitLab可能会开始使用libgit2-backends来存储数据库中的Git仓库。这样的话一个集群数据库就能存储GitLab应用的所有状态。这使得建立一个集群系统变得很容易。可惜的是libgit2以及它的ruby依赖库Rugged目前还不能提供GitLab所需要的所有功能。

尽管集群或master/master配置支持暂时还不是GitLab未来计划的一部分，但也有好消息。不同公司对于HA的需求导致了各种更加简单和廉价的解决方案。例如:

• 如果你需要写HA和快速恢复功能，前面任何HA设置都能做到。

• 如果你需要本地克隆大仓库，可以使用一个针对GitHub的第三方镜像解决方案，gitlab-mirrors

• 如果你仅仅只需要在不同的地点push到多个GitLab服务器上去，可以使用git remotes。

• 如果你需要让工作在地球上各个洲的人都能有快速的用户体验，可以使用本地git客户端、命令行、Tower等等。

请与我们联系

在 GitLab.com 我们很重视提供一个高可用（High Availabily）的安装（设置）。我们提供在这里的信息仅仅是一个粗略的向导，旨在帮助你感受硬件， 软件和处理不同的高可用（HA）安装（设 置）。当涉及到你的具体情况， 我们最好评估它的上下文环境。 我们强烈建议你在设置前与我们联系。支持HA可以标准订阅。 如果你有任何问题请发邮件 给我们。