七天七文件系统之seaweedfs

非常年轻的一个开源分布式文件系统,项目发起于2015年。具有高可用、可扩展性等特点。其设计来源于facebook的haystack(提供图片存储服务),目标是提供快速、能够存储billions级别的文件存储,并可对接大数据业务。另外,兼容性较好,适应异构的硬件平台、不同的操作系统。

架构基于对象存储实现。对象存储利用一个中心服务(central master)管理所有节点的volumes。每个volume默认为32GB,存储各自的文件和元数据。使用若干Storage Node(卷存储服务器)存储这些volumes。从而将访问和存储压力分散在各个节点上。

该文件系统特点大多体现在性能上,特别是对小文件访问上:

- 分布式架构

- 同时支持大文件和小文件(很多文件系统不具备)

- 针对小文件采取过优化(很多文件系统不具备,但并没有相应的介绍)

- 并发处理能力

- 随机访问且延迟较低

- 备份功能 , 即远程复制,异步将数据备份到公有云上,如亚马逊S3,微软azure,google cloud storage等。文件在Filer中变更将发送通知到消息队列(message queues,可以是kafka等),一个复制进程(weed replicate)将会读取消息队列,读取文件并将变更上传到公有云山。

- 支持非常丰富的接口,类型有RESTFul、POSIX、FUSE、S3,HDFS(能够作为hadoop和spark的后端存储)。

- 文件操作能够保持原子性

但是由于发起较晚目前功能尚不是很完善缺少纠删码、分层存储、自动均衡(不同于cephfs和lizardfs,服务删除和添加不会引起数据重平衡。)、快照、配额、ACL等能力。

采用go和java开发,使用Apache 2.0许可证。

架构

相对HDFS架构,其进行扩展,增加了一层逻辑上的volumes,volumes分布在各个卷服务(volume server)上。由master管理volumes数据,以及volumes和服务器的映射。采用多volume server节点,避免了集中式的数据管理中不利于大量小文件处理的弊端和性能无法扩展的劣势。volume的后端volume store的组织方式由超级块和needle(相当于对象)组成。master负责将写请求分配到随机的volume上。

master支持以集群方式组织,多master使用RAFT算法进行Leader选举。



对于文件系统的元数据则有Filer进行管理。使用常见的数据库进行存储元数据,如LevelDB(默认使用)、Cassandra、MySQL、Postgres、Redis等,后端的不同数据库可以对操作产生一定的影响。比如在lookup效率上redis的时间复杂度是O(1),而其他使用LSM或者B树的数据库则为O(lgn),又比如对于文件夹中的文件数量是否存在限制,redis存在限制、而MySql等不存在限制。

Filer的作用和ceph中的mds有些类似,都是管理元数据,但是ceph是有状态的,而Filer是无状态的,ceph将元数据存放在资源池上,而Filer将元数据存放在本地数据库(Filer Storage)中(redis等则可以扩展至不同节点)。Filer包含一个和master通讯的客户端,主要实时获取volumes的状态和位置更新。存储目录数据的元数据则对应的只有目录的一些属性,而文件的元数据除了文件的属性,还保存了文件的chunks信息。

Filer 是可线性扩展无状态的,各个Filer只出列各自的目录集合(collections),并不使用统一的命名空间,扩展能力依赖于存储后端的扩展能力。Filer的高可用则是依赖于后端Filer Store的共享能力进行实现。

数据以chunk形式(类比ceph的object)存放在各个volume server中。采用强一致性模型写入数据副本。

对于不同的客户端,Filer的作用有所区别

对S3或者Filer (RESTFul接口)客户端元数据会负责将数据转发到对象存储中。

对于一个文件的读而言,其流程:客户端先向Filer请求元数据,Filer将元数据获取返回,然后客户端再向相应的卷服务获得数据。

对于一个文件的写而言,其流程:客户端将文件发送给Filer,由Filer负责将文件分割成chunks之后写入各个volume server。Filer将元数据信息和chunks信息存放在本地存储中。

对FUSE、hadoop等客户挂载型端,Filer只负责元数据的操作。

对于一个文件的读而言(和S3相似),其流程:客户端先向Filer请求元数据,Filer将元数据获取返回,然后客户端再向相应的卷服务获得数据。

对于一个文件的写而言,其流程:客户端先向master确认数据写入哪一个volume,然后客户端直接将数据写入到volume中,向Filer写入元数据(包含chunk信息)。


应用场景

和ceph没有经过优化的小文件性能对比seaweedfs专门进行了优化,比ceph更容易搭建,没有ceph那么重量级。

PS:搜了一下竟然是某东抄袭的文件系统。

参考

https://www.slideshare.net/chrislusf/seaweedfs-introduction

https://github.com/chrislusf/seaweedfs/wiki/Directories-and-Files

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 199,711评论 5 468
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 83,932评论 2 376
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 146,770评论 0 330
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 53,799评论 1 271
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 62,697评论 5 359
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,069评论 1 276
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,535评论 3 390
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,200评论 0 254
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,353评论 1 294
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,290评论 2 317
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,331评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,020评论 3 315
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,610评论 3 303
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,694评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,927评论 1 255
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,330评论 2 346
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 41,904评论 2 341