Gleasy的分布式文件系统Cloudfs

声明
本文为Gleasy原创文章,转载请指明引自Gleasy团队博客

一。轮子,又见轮子
分布式文件系统确实很多,开源的也不少,像FASTDFS,TFS,MogileFS,HDFS,MongoDB(Gridfs),而且个个响当当,相当优秀。Gleasy在创业阶段坚持自己开发分布式文件系统,乍看上去确实有重复造轮子的嫌疑。可事实上,Gleasy选择此举属无奈。最初选用的是MongoDB(Gridfs),图的是它超级方便,用一段时间发现支持不了断点续传(由于分片保存的时候要对所有内容生成HASH),而且IOPS极低,压力一上下CPU就狂升100%,果断抛弃。后来换成FASTDFS,确实可以支持断点续传了,用一段时间为节省空间想引入文件去重能力(整个文件系统相同内容文件只留一份),结果令人失望,加上使用过程中还遇到1S只能建一个空文件的限制,实在没办法满足Gleasy这种协同读写环境,想改代码又觉得维护成本太高,忍痛弃之。开始研究TFS,HDFS,MogileFS,经过大量实验,对比,总结,Gleasy个个都是完美主义者,愣是发现没有一个极为适合我们。没办法了,关上门开始造车。。这就有了Gleasy的Cloudfs 1.0诞生。

二。没有最好,只有最适合
Cloudfs重点关注的指标是高性能,去重,容灾,线上扩容,最终一致,简单易用。经过长时间的优化,它已经开始具备这些能力。Cloudfs没有像大多数FS一样分块存储,虽然分块存储的好处非常明显,但高性能和加密的要求令我们对分块SAY NO。Cloudfs采用JAVA开发,也许在理论上,它永远超越不了C语言开发的TFS和FastDFS,但是从实际测试的对比结果来看,似乎又不一定。在Gleasy这个特定的环境,Cloudfs无疑是最优秀最合适的,虽然,换了别的地方,它可能就变得平庸。我们始终相信没有最好,只有最适合。

三。架构设计
1. 物理架构
数据结点(DataNode):真正用来存储数据的结点
组(Group): 包括若干数据结点,同组内的所有数据结点内容保持一致(实时互相同步)
分区(Region): 包括若干组,同一个分区内的文件会自动去重(相同内容的文件只会存在一份),每个分区最多可以容纳10亿个文件。
注意:一个分布式文件系统可以包括若干分区。

2. 软件架构
单个运行的Cloudfs只包含一个DataNode服务器(DataNode Server)和一台Nginx服务器。DataNode Server提供文件的上传,复制,删除等功能,Nginx服务器提供流式下载功能。
DataNode Server采用JAVA开发,采用MINA框架,使用java NIO FileChannel进行文件存取操作。
使用Zookeeper进行结点发现和管理
使用Redis存储文件信息和索引信息
使用CloudMQ进行同组内基于操作日志的数据同步

四。运行特性
a. 数据多备(一个组可以有多台服务器结点,组内每个结点的文件会自动同步,文件多结点互备)
b. 负载均衡(对某一个组的访问会平均地分配到各个结点,某个结点挂掉,不影响整个系统运作)
c. 动态扩容(通过增加新的组进行容量扩容,通过增加组内结点可以做到负载扩容,扩容过程不需要关闭服务)
d. 自动去重(在同一分区内相同内容的文件只会只存在一份,极大地节省空间和省去大量文件传输时间)
e. 高性能(IOPS达到1200以上,创建文件TPS达4W以上,复制文件TPS达9000以上,删除文件达2W以上,上传下载速率可达25MBPS)

五。性能测试报告

cloudfs-创建空文件
tps 46k
[root@DB1 cloudfs]# best online casino bin/dfs-benchmark -t create -p 60 -c 1000 -s 1024
成功:2816889
失败:0
命中缓存:0
总时间:60014662
最长用时:606
最短用时:0
平均用时:21.30529885984148
max tps:108389
avg tps:46178

cloudfs--创建并上传文件(全部不命中)
[root@gleasy cloudfs]# bin/dfs-benchmark -t upload -p 30 -c 50 -s 1024
成功:29782
失败:0
命中缓存:0
总时间:1728787
最长用时:5997
最短用时:0
平均用时:58.04804915720905
max tps:1700
avg tps:960

创建文件并上传---全部命中缓存
bin/dfs-benchmark -t cache -p 60 -c 200 -s 1024
成功:353676
失败:0
命中缓存:353676
总时间:12007269
最长用时:574
最短用时:0
平均用时:33.94991178366641
max tps:6861
avg tps:5797
清除测试数据(delete File) tps:19244.828832083822

复制文件
500 clients(fast redis)
bin/dfs-benchmark -t copy -p 60 -c 500 -s 1024
成功:507496
失败:0
命中缓存:0
总时间:30016590
最长用时:258
最短用时:0
平均用时:59.14645632674937
max tps:10004
avg tps:8319
清除测试数据(delete File) tps:18875.823589899835

删除文件
清除测试数据(delete File) tps:18875.823589899835

五。去重效果分析
采用Cloudfs(在10亿文件内只有一个分区)后,相同内容的文件只会存储一份。通过查看线上数据,线上运行6个月,计量容量600G,实际物理容量180G,节省420G,节省比例70%。可见Gleasy系统内,文件重复比例非常高,这与Gleasy企业客户为主的用户群体使用习惯很有关系。
可以预见,随着文件系统基数增大,节省的比例会继续增大,目标是可以做到1:10,即用1G的空间可以完美达到10G的使用量,使用该技术对用户体验没有任何损害,反而会带来性能质的提升。

此条目发表在 Java技术, 分布式技术, 运维 分类目录。将固定链接加入收藏夹。

Gleasy的分布式文件系统Cloudfs》有 2 条评论

  1. Pingback 引用通告: Gleasy分布式架构体系介绍 | Gleasy团队博客

  2. Pingback 引用通告: Cloudfs一致性问题分析及解决 | Gleasy团队博客

发表评论