Moosefs概念总结

近来了解了一个分布式文件系统——MooseFS,之前对分布式的东西知道的很少,分布式文件系统、分布式数据库都是近而远之,觉得太杂乱了离我还很悠远。在各位教师的推动下我用6台机器实习了一下moosefs,moosefs的安置仍是很简略的,和装备NFS很像,便是多了两种人物的机器,恰是有了它们,才使得moosefs在可扩展性和稳定性上都要远好于NFS,在读写的功用方面,通过dd进行的简略检验来看,moosefs也便是写入的速度稍微好于NFS,读上没有不同。下面是关于MFS知识点的一些总结。

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,将其加载到内核中。