Git 分布式 Moosefs + Corosync + DRBD 集群

    对于 Git 集群来说,在不采用存储阵列的情况下,分布式存储系统是一个很好的解决方案。目前可使用的分布式文件系统,初步了解了一下,Git 是属于小文件的应用,因此可考量的我想就只有目前的 Moosefs、Ceph 了,Ceph 目前好似国内应用不多,貌似不太稳定。至于 GlusterFS 其比较适用于大文件的应用场景,而且其文件的存储方式有别于 Moosefs 和 Ceph:

  • Moosefs 和 Ceph 都属于文件多副本的方式,集群扩展较比容易, 这点 GlusterFS 不具备;

  • GlusterFS 是基于镜像的方式,其通过 AFR、DHT、Stripe 组合的方式,来创建卷管理,管理比较麻烦。且其应用场景主要在 KVM 等虚拟化管理上。

    下图,是摘自网上的一个分布式文件系统的对比。

MooseFS(MFS)

Ceph

GlusterFS

Lustre

Metadata server

单个 MDS,存在单点故障和瓶颈。

多个 MDS,不存在单点故障和瓶颈。MDS 可以扩展,不存在瓶颈。

无,不存在单点故障。靠运行在各个节点上的动态算法来代替 MDS,不需同步元数据,无硬盘 I/O 瓶颈。

MDS(互相备份)MDS不可以扩展,存在瓶颈。

FUSE

支持

支持

支持

支持

访问接口

POSIX

POSIX

POSIX

POSIX/MPI

文件分布/数据分布

文件被分片,数据块保存在不同的存储服务器上。

文件被分片,每个数据块是一个对象。对象保存在不同的存储服务器上。

Cluster TranslatorsGlusterFS集群存储的核心)包括 AFRDHT Stripe 三种类型。
  AFR
相当于 RAID1,每个文件都被复制到多个存储节点上。
  Stripe
相当于 RAID0,文件被分片,数据被条带化到各个存储节点上。
  Translators
可以组合,即 AFR Stripe 可以组成 RAID10,实现高性能和高可用。

可以把大文件分片并以类似 RAID0 的方式分散存储在多个存储节点上。

冗余保护/副本

多副本

多副本

镜像

数据可靠性

由数据的多副本提供可靠性。

由数据的多副本提供可靠性。

由镜像提供可靠性。

由存储节点上的RAID1RAID5/6提供可靠性。假如存储节点失效,则数据不可用。

备份

提供备份工具。支持远程备份。

故障恢复

手动恢复

当节点失效时,自动迁移数据、重新复制副本。

当节点、硬件、磁盘、网络发生故障时,系统会自动处理这些故障,管理员不需介入。

扩展性

增加存储服务器,可以提高容量和文件操作性能。但是由于不能增加MDS,因此元数据操作性能不能提高,是整个系统的瓶颈。

可以增加元数据服务器和存储节点。容量可扩展。文件操作性能可扩展。元数据操作性能可扩展。

容量可扩展。

可增加存储节点,提高容量可文件操作性能,但是由于不能增加MDS,因此元数据操作性能不能提高,是整个系统的瓶颈。

安装/部署

简单

简单

简单

复杂。而且Lustre严重依赖内核,需要重新编译内核。

开发语言

C

C++

C

C

适合场景

大量小文件读写

小文件

适合大文件。
 
对于小文件,无元数据服务设计解决了元数据的问题。但 GlusterFS 并没有在 I/O 方面作优化,在存储服务器底层文件系统上仍然是大量小文件,本地文件系统元数据访问是瓶颈,数据分布和并行性也无法充分发挥作用。因此, GlusterFS 的小文件性能还存在很大优化空间。

大文件读写

产品级别

小型

中型

中型

重型

应用

国内较多

较多用户使用

HPC 领域。

优缺点

实施简单,存在单点故障。

不稳定,目前还在实验阶段,不适合于生产环境。

无元数据服务器,堆栈式架构(基本功能模块可以进行堆栈式组合,实现强大功能)。具有线性横向扩展能力。由于没有元数据服务器,因此增加了客户端的负载,占用相当的 CPU 和内存。但遍历文件目录时,则实现较为复杂和低效,需要搜索所有的存储节点。因此不建议使用较深的路径。

很成熟、很庞大。

    对于 Git 分布式存储的方案,前前后后,测试了一下 Moosefs、Mogilefs 和 GlusterFS,最终还是在管理便利上选择在 Moosefs 和 Ceph 中选择一个,Ceph 是基于内核级的,效率最高,但目上前好似不稳定,因此对于 Git 集群存储我还是选择了目前国内使用最多的 Moosefs。

    Moosefs 目前最新版本为2.x,分为 CE 社区版 和 PRO 专业版(收费),CE 只拥有单 Master,Pro 有双 Master 机制,自我实现 HA 高可用。

    先来一张整个 Git 集群的拓扑图(基于 Moosefs CE HA 高可用,仿 PRO 双 master 机制):

mfs cluster.jpg

    整个集群使用两组集群方案:

·         LVS + Keepalvied,实现后端 Git Server 的集群

·         Corosync + Pacemake + DRBD,实现后端 Git Server 存储资源的分布式集群。

    Keepalived + LVS 怎么实现(具体不做介绍),我想大家学过马哥的都知道怎么做,这里不做介绍。马哥教育,你值得选择!

    允许我偷懒一下,下面给出一份 Git Moosefs(CE) + Corosync + Pacemaker + CRM + DRBD 的单 Master HA 高可用方案,整个集群环境测试,我还利于了 Cobbler + Ansbile + KVM 来完成虚拟机,再到真实物理机的测试。对于 KVM 我还是推荐大家学了马哥视频以后,就不要再去用 VMWare,不是说它不好,而是对于一个 Linuxer 而言,我们要尽量 Linux 化,何况我们还有 Openstack 可用。在学好一个东西的时候,尽量全部使用命令行的工具,慎用图形化的工具,在掌握以后,倒是无所谓了。而且在掌握一个知识点以后,要不断总结,马哥的视频前后有很多关联性的,总结再总结,实践再实践,理论很重要。笔记部分在每学一个知识点以后,要回头看看之前的东西是否有优化完善的地方,有就回去再总结、再完善,那笔记会很丰满的。我不太喜欢写博客,我习惯写笔记,公司内部的 Wiki 我都懒得写,我基本就是每总结完一个笔记,就直接把笔记打印成 PDF 放到 Wiki 或者博客上了。我写笔记很费时,因为我总会把笔记补得丰满,解决自己所有的疑惑点以后才会认可这份笔记,这通常需要一个很长的时间跨度。因此,博客对我来说,处女座很纠结,我喜欢写笔记。有点费话了,报歉,大家忽略吧^-^

     Moosefs 双 Master + 三台 chunkserver,一共五台设备,在简单的以三份副本的测试中,其性能如下表所示(普通 PC 机,单个硬盘,7200 转 SATA 接口):

读速度(MB/S)

写速度(MB/S)

单点

175

150

分布式(三节点)

450

90

性能对比

提升:157%

下降:40%

    

Git 分布式 Moosefs + Corosync + DRBD 集群05 – Moosefs 分布式文件系统 – 01.pdf

Git 分布式 Moosefs + Corosync + DRBD 集群05 – Moosefs 分布式文件系统 – 02 .pdf

Git 分布式 Moosefs + Corosync + DRBD 集群05 – Moosefs 分布式文件系统 – 03.pdf

Git 分布式 Moosefs + Corosync + DRBD 集群05 – Moosefs 分布式文件系统 – 04.pdf

Git 分布式 Moosefs + Corosync + DRBD 集群05 – Moosefs 分布式文件系统 – 05.pdf

Git 分布式 Moosefs + Corosync + DRBD 集群05 – Moosefs 分布式文件系统 – 06.pdf

Git 分布式 Moosefs + Corosync + DRBD 集群05 – Moosefs 分布式文件系统 – 07.pdf

Git 分布式 Moosefs + Corosync + DRBD 集群05 – Moosefs 分布式文件系统 – 08.pdf

Git 分布式 Moosefs + Corosync + DRBD 集群mfs_role.pdf 这个是 ansible 的脚本,请把 pdf 改为 tgz 解压即可。

    Corosync 如何配置并没有细细说道,可回看马哥的视频,文章结尾只给出了 CIB 的配置部分。最后还是打下广告,马哥教育,你值得拥有。

    最后,本着严谨的原则,附上之前 Cobbler 更新版文章:追加 Cobbler 模板引擎(修正)、其内部源的搭建方式。

Git 分布式 Moosefs + Corosync + DRBD 集群01 – Cobbler 自动化部署系统 – 01 .pdf

Git 分布式 Moosefs + Corosync + DRBD 集群01 – Cobbler 自动化部署系统 – 02.pdf

END

原创文章,作者:影·随行,如若转载,请注明出处:http://www.178linux.com/11748