对于 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 Translators(GlusterFS集群存储的核心)包括 AFR、DHT 和 Stripe 三种类型。 |
可以把大文件分片并以类似 RAID0 的方式分散存储在多个存储节点上。 |
|
冗余保护/副本 |
多副本 |
多副本 |
镜像 |
无 |
|
数据可靠性 |
由数据的多副本提供可靠性。 |
由数据的多副本提供可靠性。 |
由镜像提供可靠性。 |
由存储节点上的RAID1或RAID5/6提供可靠性。假如存储节点失效,则数据不可用。 |
|
备份 |
提供备份工具。支持远程备份。 |
||||
故障恢复 |
手动恢复 |
当节点失效时,自动迁移数据、重新复制副本。 |
当节点、硬件、磁盘、网络发生故障时,系统会自动处理这些故障,管理员不需介入。 |
无 |
|
扩展性 |
增加存储服务器,可以提高容量和文件操作性能。但是由于不能增加MDS,因此元数据操作性能不能提高,是整个系统的瓶颈。 |
可以增加元数据服务器和存储节点。容量可扩展。文件操作性能可扩展。元数据操作性能可扩展。 |
容量可扩展。 |
可增加存储节点,提高容量可文件操作性能,但是由于不能增加MDS,因此元数据操作性能不能提高,是整个系统的瓶颈。 |
|
安装/部署 |
简单 |
简单 |
简单 |
复杂。而且Lustre严重依赖内核,需要重新编译内核。 |
|
开发语言 |
C |
C++ |
C |
C |
|
适合场景 |
大量小文件读写 |
小文件 |
适合大文件。 |
大文件读写 |
|
产品级别 |
小型 |
中型 |
中型 |
重型 |
|
应用 |
国内较多 |
无 |
较多用户使用 |
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 机制):
整个集群使用两组集群方案:
· 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% |
05 – Moosefs 分布式文件系统 – 02 .pdf
mfs_role.pdf 这个是 ansible 的脚本,请把 pdf 改为 tgz 解压即可。
Corosync 如何配置并没有细细说道,可回看马哥的视频,文章结尾只给出了 CIB 的配置部分。最后还是打下广告,马哥教育,你值得拥有。
最后,本着严谨的原则,附上之前 Cobbler 更新版文章:追加 Cobbler 模板引擎(修正)、其内部源的搭建方式。
01 – Cobbler 自动化部署系统 – 01 .pdf
END
原创文章,作者:影·随行,如若转载,请注明出处:http://www.178linux.com/11748