MooseFS分布式文件系统

类似GoogleFS的实现方式,即一个MasterServer和多个ChunkServer构成的存储集群。MFS系统由4个部分构成,master、metalogger、chunkserver、client。

Master

mfs的大脑,记录着管理信息,比如:文件大小,存储的位置,份数等,和innodb中共享空间(ibdata)中存储的信息类似,这些信息被记录到metadata.mfs中,当该文件被载入内存后,改文件会重命名为metadata.mfs.back,当chunkserver上有更新时,master会定期将获得的新的信息回写到metadata.mfs.back中,保重元数据的可靠。

硬件推荐:大内存,因为内存中需要将metadata.mfs加载进来,这个文件的大小取决于你chunkserver上存储的数据量,内存的大小会成为之后的问题,要ECC的可以进行错误校验,当内存中数据量达到一定程度,如果没有个容错的机制,会很可怕;冗余电池,和磁盘配置RAID1/RAID5/RAID10,都是为了保证高可靠。

Metalogger

mfs的备份,好比mySQL中的m-s结构,metalogger会定期重master上将的metadata、changelog、session类型的文件下载同步到本地目录下,并加后缀”_ml”将其重命名。

硬件推荐:与master机器配置一致,metalogger本身就是master的一个备机,当master宕机后,可以直接将metalogger提升为master。

Chunkserver

数据存储地,文件以chunk大小存储,每chunk最大为64M,小于64M的,该chunk的大小即为该文件大小,超过64M的文件将被均分,每一份(chunk)的大小以不超过64M为原则;文件可以有多份copy,即除了原始文件以外,该文件还存储的份数,当goal为1时,表示只有一份copy,这份copy会被随机存到一台chunkserver上,当goal的数大于1时,每一份copy会被分别保存到每一个chunkserver上,goal的大小不要超过chunkserver的数量,否则多出的copy,不会有chunkserver去存,goal设置再多实际上也就没有意义的。Copy的份数,一般设为大于1份,这样如果有一台chukserver坏掉后,至少还有一份copy,当这台又被加进来后,会将失去的那份copy补回来,始终保持原有的copy数,而如果goal设为1copy,那么当存储该copy的chunkserver坏掉,之后又重新加入回来,copy数将始终是0,不会恢复到之前的1个copy。

Chunkserver上的剩余存储空间要大于1GB(Reference Guide有提到),新的数据才会被允许写入,否则,你会看到No space left on device的提示,实际中,测试发现当磁盘使用率达到95%左右的时候,就已经不行写入了,当时可用空间为1.9GB。

Client

客户端通过内核加载的FUSE模块,再通过和master的共同,将chunkserver共享的分区挂载到本地,然后进行读写操作。由于FUSE模块是外加的模块,当系统重启后,需要执行modprobe fuse,将其加载到内核中

本文分享自微信公众号 - DevOps持续集成(devopsadmin)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-08-11

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券