moosefs mysql_MooseFS文件系统介绍

MooseFS文件系统介绍

MooseFS是一种分布式文件系统，MooseFS文件系统结构包括以下四种角色：

1 管理服务器managing server (master)

2 元数据日志服务器Metalogger server(Metalogger)

3 数据存储服务器data servers (chunkservers)

4 客户机挂载使用client computers

各种角色作用:

1 管理服务器:负责各个数据存储服务器的管理,文件读写调度,文件空间回收以及恢复.多节点拷贝

2 元数据日志服务器: 负责备份master服务器的变化日志文件，文件类型为changelog_ml.*.mfs，以便于在master server出问题的时候接替其进行工作

3 数据存储服务器:负责连接管理服务器,听从管理服务器调度,提供存储空间，并为客户提供数据传输.

4 客户端: 通过fuse内核接口挂接远程管理服务器上所管理的数据存储服务器,.看起来共享的文件系统和本地unix文件系统使用一样的效果.

MooseFS优点

1.开源

2.通用文件系统，不需要要修改上层应用就可以使用

3.可以在线扩容，体系架构可伸缩性极强

4.部署简单

5.体系架构高可用，所有组件无单点故障

6.文件对象高可用，可设置任意的文件冗余程度，而绝对不会影响读写的性能，只会加速

7，提供如windows回收站的功能，

8.提供类似java语言GC(垃圾回收)

9.提供netapp,emc,ibm等商业存储的snapshot特性

10.google filesystem 的一个c实现

11.提供web gui监控接口

12.提高随机读写的效率

13.提高海量小文件的读写效率

MooseFS 1.6版本改进

1.修改1.5中的大批量操作时打开文件过多的bug

2.新增加了masterlogger服务器，在1.5中没有的，就是做了master服务器的冗余，进一步的加强master服务器的稳定性，在mfs体系中master是要求最稳定以及性能要求最高的，因此务必保证master的稳定

3.修改1.5中存在的对于坏块的修复功能，在mfs1.5中遇到chunker坏块校验，错误比较多的是往往导致master将出现坏块的chunker自动剔除出去的情况，此次增加了对坏块的修复功能，很方便的进行修复，简化对坏块的处理功能。

4.对metadata和changelog的新认识，之前认为changelog记录的是文件的操作，定期的像数据库的日志一样归档到metadata中,发现上面的理解存在误区，真正的是changelog中记录了对文件的操作，metadata记录文件的大小和位置，因此metadata是比较重要的，在进行修复的过程中是采用metadata和最后一次changelog进行修复。

5.MFS 文档中明确指出对于内存和磁盘大小的要求

6.指出了在测试的过程中多个chunker并不影响写的速度，但是能加快读的速度，在原来的基础上增加一个chunker时，数据会自动同步到新增的chunker上以达到数据的平衡和均衡。

常见问题，

1.master性能瓶颈，主要是可扩展性不强

2.体系架构存储文件总数的瓶颈，mfs把文件系统的结构缓存到master内存中，这样文件越多，master的内存消耗越大，8G对应2500kw文件数，2亿就的64G内存

3.单点故障解决方案的健壮性

4.垃圾回收   把默认的86400改为300秒，这样可以免的垃圾还没回收完，你的存储容量就暴掉了。

mfs的原理：

就是客户端请求master，master分派他去哪里读数据，

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

matedata.mfs.back文件将消失，那么要恢复整个mfs,则需从metalogger服务器取得该文件。请特别注意这个文件，它与日志文件一起，才能够恢复整个被损坏的分布式文件系统。