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

相关推荐

  • HDFS写入和读取流程

    一、HDFS HDFS全称是Hadoop Distributed System。HDFS是为以流的方式存取大文件而设计的。适用于几百MB,GB以及TB,并写一次读多次的场合。而对于低延时数据访问、大量小文件、同时写和任意的文件修改,则并不是十分适合。 目前HDFS支持的使用接口除了Java的还有,Thrift、C、FUSE、WebDAV、HTTP等。HDFS…

    Linux干货 2015-05-12
  • linux上的LVM简明教程

    LVM是一个多才多艺的硬盘系统工具。在Linux上非常的好用,传统分区使用固定大小分区,重新调整大小十分麻烦。但是,LVM可以创建和管理“逻辑”卷,而不是直接使用物理硬盘。可以让管理员弹性的管理逻辑卷的扩大缩小,操作简单,而不损坏已存储的数据。可以随意将新的硬盘添加到LVM,以直接扩展已经存在的逻辑卷。 首先是实际的物理磁盘及其划分的分区和其上的物理卷(PV…

    Linux干货 2017-05-02
  • 强大的查找工具之find命令

    一、Linux中的文件查找工具     在文件系统上常常需要根据文件的各种属性去查找符合条件的文件,此前讲到的grep、egrep属于文本过滤、文本搜索工具;而文本查找工具有两个,local和find 二、Linux中的查找工具简介 locate 命令 find 命令 简介:locate属于非实时查找,依赖于事先构建的索引;索引的创建是在…

    Linux干货 2016-08-16
  • N21沉舟11周作业

    1、请描述一次完整的http请求处理过程; (1) 建立或处理连接:接收请求或拒绝请求 (2) 接收请求: (3) 处理请求:对请求报文进行解析,并获取请求的资源及请求方法等相关信息 (4) 访问资源:获取请求报文中请求的资源 (5) 构建响应报文 (6) 发送响应报文 (7) 记录日志 …

    Linux干货 2016-09-26
  • Week 1 计算机组成

    I. 引 Introduction     在学习计算机技术之前,了解计算机的组成是非常必要的。这不仅可以让你对硬件有一个大概的了解,而且会让你将来对基于硬件运行的软件有一个更为透彻的理解。只有理解了计算机是如何协调它的部件来工作的才方能理解人们为何这样设计操作系统和程序。 I. 计算机部件 The Essential…

    Linux干货 2016-06-11
  • Find小总结及应用

    Find总结及应用 搜索命令:     locate命令:         在文件系统上查找符合条件的文件         非实时查找( 数据库查找)…

    Linux干货 2016-08-16