0

GitLab简介

GitLab是一个利用 Ruby on Rails 开发的开源应用程序,实现一个自托管的Git项目仓库,可通过Web界面进行访问公开的或者私人项目。Ruby on Rails 是一个可以使你开发、部署、维护 web 应用程序变得简单的框架。GitLab拥有与Github类似的功能,能够浏览源代码,管理缺陷和注释。可以管理团队对仓库的访问,它非常易于浏览提交过的版本并提供一个文件历史库。它还提供一个代码片段收集功能可以轻松实现代码复用,便于日后有需要的时候进行查找。
由于Git的分布式特性,即使Gitlab不可用,开发人员仍然可以在本地提交代码。但是,某些Gitlab功能,比如CI,问题跟踪和持续集成会不可用,也会严重影响线上使用。因此高可用架构还是不可缺少的。GitLab软件架构如下图所示:

GitLab高可用设计

主备模式:启动2个实例,只有一个工作提供服务,数据通过分布式存储保持一致

主主模式(scales):Rails server启动多个,同时提供服务,数据库保持独立,数据通过NAS文件存储共享

GitLab高可用方案

水平扩展

这种架构适用于许多Gitlab客户访问的使用场景,解决高API使用率,大量排队的Sidekiq作业的问题。

  • 3 PostgreSQL nodes
  • 2 Redis nodes
  • 3 Consul/Sentinel nodes
  • 2 or more GitLab application nodes (Unicorn, Workhorse, Sidekiq, PGBouncer)
  • 1 NFS/Gitaly server

混合扩展

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

  • 3 PostgreSQL nodes
  • 1 PgBouncer node
  • 2 Redis nodes
  • 3 Consul/Sentinel nodes
  • 2 or more Sidekiq nodes
  • 2 or more GitLab application nodes (Unicorn, Workhorse)
  • 1 or more NFS/Gitaly servers
  • 1 Monitoring node (Prometheus, Grafana)

全分布式扩展

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

  • 3 PostgreSQL nodes
  • 4 or more Redis nodes (2 separate clusters for persistent and cache data)
  • 3 Consul nodes
  • 3 Sentinel nodes
    Multiple dedicated Sidekiq nodes (Split into real-time, best effort, ASAP, CI Pipeline and Pull Mirror sets)
  • 2 or more Git nodes (Git over SSH/Git over HTTP)
  • 2 or more API nodes (All requests to /api)
  • 2 or more Web nodes (All other web requests)
  • 2 or more NFS/Gitaly servers

阿里云文件存储NAS选型

GitLab场景通常为海量小文件场景,需要并发的进行文件的读写操作。该种场景适用于极速型NAS。该种NAS后端基于RDMA网络进行时延优化,对于元数据操作密集型的业务有很高的OPS和较低的访问时延。

引用文章

https://docs.gitlab.com/ce/administration/high_availability/README.html



本文作者:曜斯

阅读原文

本文为云栖社区原创内容,未经允许不得转载。


如果觉得我的文章对你有用,请随意赞赏

你可能感兴趣的

opsarno · 6月11日

实际测过了吗? 我之前有过用普通NAS做过高可用的经历,不过当时的访问性能不可观。

回复

载入中...