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

(0)
影·随行影·随行
上一篇 2016-02-19 17:22
下一篇 2016-02-24 00:19

相关推荐

  • N26-第一周博客作业

    一:计算机的组成及其功能  1.运算器(CPU) 对数据进行各种运算;  2.控制器(CPU) 用来控制整个计算机操作系统;  3.存储器 内存(RAM)存储程序和各种数据信息;  4.输入装置 (Input)下达指令,提供数据,常见的输入装置有鼠标,键盘等;  5.输出设备 (Output)输出数据加工后的…

    Linux干货 2016-12-31
  • 马哥教育网络班21期+第6周课程练习

    请详细总结vim编辑器的使用并完成以下练习题 1、复制/etc/rc.d/rc.sysinit文件至/tmp目录,将/tmp/rc.sysinit文件中的以至少一个空白字符开头的行的行首加#; [root@localhost ~]#cp /etc/rc.d/rc.sysinit /tmp/ [root@localhost&nbs…

    Linux干货 2016-07-29
  • BIND(Berkeley Internet Name Domain) is an implementation of the DNS(Domain Name System) (Blob 12)

    正向解析区域、反向解析区域;主/从;子域;基本安全控制;

    2017-11-29
  • Linux用户、组、权限管理

    Linux用户与组管理 Linux系统上,用户通过内核拷贝程序到内存中,从此发起进程。进程以发起者的身份进行,进程对文件的访问权限,取决于发起进程的用户的权限。而有些后台进程或服务类进程以非管理员身份运行,为此也需要创建多个普通用户,此类用户不需登录。 系统中,用户类别分为管理员和普通用户(系统用户和登录用户),组类别分为基本组和附加组。管理系统上的用户与组…

    Linux干货 2016-12-07
  • Python装饰器与面向切面编程

    新年好~ 那么,很久没有更新了,其实想想也没多少可以写的,因为Python的文档似乎很全面的说……能做的差不多只有翻译和整理了,英文过关的朋友不妨直接去doc.python.org这里查看相关资料 :) 转载请注明原作者和原文地址,多谢! 今天来讨论一下装饰器。装饰器是一个很著名的设计模式,经常被用于有切面需求的场景,较为经典的有插入日志、性能测试、事务处理…

    Linux干货 2015-03-12
  • 15磁盘管理

    在系统中,常见的硬盘接口有分两类:并行的和串行的 并行: IDE: 133MB/s SCSI: 640MB/s 串行: SATA: 6Gbps SAS: 6Gbps USB: 480MB/s 存储设备的设备文件命名方式大致为:/dev/DEV_FILE IDE: /dev/hd#  #–>0,1,2,3 SCSI,SATA,SAS…

    Linux干货 2016-12-02