GItlab的⾼可⽤⽅案
⼀、背景
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+innotif y
只需要两台相同配置的服务器，每台机器都有相同的 GitLab 资源库, 配置, 和数据库. 从服务器的作⽤是备份主服务器的⽂件，⼀旦主服务器挂掉，从服务器⾃动接管主服务器的所有⼯作
原理：Gitlab（master）节点和Gitlab（slave）节点，通过keepalived互相监控对⽅的状态。当master节点发⽣异常，对外提供的虚拟IP⾃动漂浮到slave节点上对外提供服务。
要点：master节点的数据和slave的数据必须保持⾼度⼀致性，可沿⽤⽂件服务器⾼可⽤的⽅案rsync+innotify+heartbeat实现双机热备⽅案四：⽅案优缺点
⽅案⼀：
缺点：需要对NFS⽂件系统服务器集，redis集，服务都需要部署在不同的机器上，花销较⼤，维护成本⾼。
优点：⽂件通过NFS⽂件系统来访问存储，能够保证GITlab数据的⾼⼀致性。并且有redis缓存机制，⼤⼤提⾼了git的效率。
⽅案⼆：
缺点：git数据通过互备的⽅式，严重依赖备份的准确性。没有缓存，速度会稍微慢⼀些。数据与服务未分离。
优点：配置简单，维护成本很低。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。