一、背景

1、现公司源代码统一用git管理，流水线对git有着强依赖。流水线一切的构建都会从git仓库拉取代码进行编译构建操作。

 

2、现git是单节点模式，虽然对数据有备份。但是一旦gitlab服务或者服务器异常，将导致服务不可用。需排查问题及解决故障以后方可使用，这期间将直接导致流水线不可用、以及开发人员无法远程提交代码等尴尬境地。



二、目标

实现gitlab的高可用，其中任何一个gitlab的异常不会引起整个系统的异常。通过实现gitlab高可用，多台具有相同能力的服务同时对外提供透明服务，并且分担处理服务请求。



三、方案

方案1

负载均衡器nginx+NFS+redis+PostgreSQL Database

 

方案要术：NFS主从、redis集群（redis哨兵模式高可用方案）

 

 

1、通过NFS文件系统，通过共享挂载，gitlab应用和数据分离，更加安全，不会因为realserver的机器故障而引起数据的丢失。通过对NFS服务器集群可以大大改善单点故障发生的概率在高并发的场合，NFS效率性能有限（一般几千万以下pv的网站不是瓶颈）。

2、redis哨兵模式本身具有高可用的特性，作为缓存redis也有很高的效率。

3、用nginx作为负载均衡器分发流量，性能好，配置简单，完全不必用官方推荐的F5（商业的）。

 

方案2

heartbeat+rsync+innotify

只需要两台相同配置的服务器，每台机器都有相同的 GitLab 资源库, 配置, 和数据库. 从服务器的作用是备份主服务器的文件，一旦主服务器挂掉，从服务器自动接管主服务器的所有工作

 

 

原理：Gitlab（master）节点和Gitlab（slave）节点，通过keepalived互相监控对方的状态。当master节点发生异常，对外提供的虚拟IP自动漂浮到slave节点上对外提供服务。

 

要点：master节点的数据和slave的数据必须保持高度一致性，可沿用文件服务器高可用的方案rsync+innotify+heartbeat实现双机热备方案

 

 

四：方案优缺点


方案一：

缺点：需要对NFS文件系统服务器集群，redis集群，服务都需要部署在不同的机器上，花销较大，维护成本高。

优点：文件通过NFS文件系统来访问存储，能够保证GITlab数据的高一致性。并且有redis缓存机制，大大提高了git的效率。

 

方案二：

缺点：git数据通过互备的方式，严重依赖备份的准确性。没有缓存，速度会稍微慢一些。数据与服务未分离。

优点：配置简单，维护成本很低。