GitLab实战四——Gitlab扩展与高可用

1.Gitlab高可用介绍

Gitlab支持几种不同类型的集群和高可用。生产中选择的解决方案都应该基于业务的需求和整体考虑,然后确认可扩展性和可用性级别。最简单的解决方案是可扩展的,但不一定高度可用。这需要使用者做一个权衡。

由于Git的分布式特性,即使Gitlab不可用,开发人员仍然可以在本地提交代码。但是,某些Gitlab功能,比如CI,问题跟踪和持续集成会不可用,也会严重影响线上使用。因此高可用架构还是不可缺少的。

注意:所有高可用性解决方案都需要在成本/复杂性正常运行时间之间进行权衡。您想要的正常运行时间越多,解决方案就越复杂。而且解决方案越复杂,设置和维护它的工作就越多。高可用性不是免费的,每个HA解决方案都应该平衡成本和收益。

Gitlab基础设施工程师对于Gitlab如何扩展等问题1小时解答: this 1 hour Q&A with John NorthrupGitLab实战四——Gitlab扩展与高可用GitLab实战四——Gitlab扩展与高可用

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个实例,只有一个工作提供服务,数据通过分布式存储保持一致

GitLab实战四——Gitlab扩展与高可用

2.主主模式(scales):Rails server启动多个,同时提供服务,数据库保持独立,数据通过NFS共享

GitLab实战四——Gitlab扩展与高可用                                                                                                                                          

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作业的问题。

GitLab实战四——Gitlab扩展与高可用

GitLab实战四——Gitlab扩展与高可用

2.4 纵向拆分

这种架构通过组件在专用节点上分离,提供高资源使各组件不会相互干扰,解决服务争用/高负载的问题。

GitLab实战四——Gitlab扩展与高可用

GitLab实战四——Gitlab扩展与高可用

以上两种架构推荐组件配置:

  • 2 PostgreSQL节点

  • 2个Redis节点

  • 3个Consul / Sentinel节点

  • 2个或更多GitLab应用程序节点(Unicorn,Workhorse,Sidekiq,PGBouncer)

  • 1个NFS / Gitaly服务器

2.5 分布式架构

该体系结构可扩展到数十万用户和项目,是GitLab.com体系结构的基础。 虽然分布式架构可以很好地扩展,但它增加了节点的复杂性,配置,管理和监控的难度,不易维护。

GitLab实战四——Gitlab扩展与高可用GitLab实战四——Gitlab扩展与高可用

  • 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服务器

> Gitlab官方生产架构

参考:

    anzhihe安志合个人博客,版权所有丨 如未注明,均为原创 丨转载请注明转自:https://chegva.com/3234.html | ☆★★每天进步一点点,加油!★★☆

    您可能还感兴趣的文章!

    发表评论

    电子邮件地址不会被公开。 必填项已用*标注