公司使用moosefs做图片存储，最近学习了一下，在此小小总结一下，主要分以下几部分：

·MFS概述、特性和新版改进

·MFS 工作原理和设计架构

·MFS的安装、部署、配置

·MFS的高级特性

·MFS的性能测试

·MFS集群的维护

·MFS的常见问题和建议对策

 

一、MFS概述、特性和新版改进

MooseFS是一个分布式存储的框架，其具有如下特性：

  1. Free(GPL)

  2. 通用文件系统，不需要修改上层应用就可以使用（那些需要专门api的dfs很麻烦！）。

  3. 可以在线扩容，体系架构可伸缩性极强。（官方的case可以扩到70台了！）

  4. 部署简单。（sa们特别高兴，领导们特别happy！）

  5. 高可用，可设置任意的文件冗余程度（提供比raid1+0更高的冗余级别，而绝对不会影响读或者写的性能，只会加速！）

  6. 可回收在指定时间内删除的文件（“回收站”提供的是系统级别的服务，不怕误操作了，提供类似oralce 的闪回等高级dbms的即时回滚特性！）

  7. 提供netapp，emc，ibm等商业存储的snapshot特性。（可以对整个文件甚至在正在写入的文件创建文件的快照）

  8. google filesystem的一个c实现。

  9. 提供web gui监控接口。

  10. 提高随机读或写的效率（有待进一步证明）。

  11. 提高海量小文件的读写效率（有待进一步证明）。

 

MooseFS 1.6版本改进：

·修复1.5.x中在大批量操作时打开文件过多的bug。报的错误说是打开的文件过多，造成chunker server的链接错误。在1.6.x中解决此问题，就解决了很大的问题。

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

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

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

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

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

 

二、MFS 工作原理和设计架构

角色

角色作用

管理服务器
managing server (master)

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

元数据日志服务器
Metalogger server（Metalogger）

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

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

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

客户机挂载使用
client computers

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

 官方的网络示意图是这样的：

读写原理：

MFS的读数据过程

  1. client当需要一个数据时，首先向master server发起查询请求；

  2. 管理服务器检索自己的数据，获取到数据所在的可用数据服务器位置ip|port|chunkid；

  3. 管理服务器将数据服务器的地址发送给客户端；

  4. 客户端向具体的数据服务器发起数据获取请求；

  5. 数据服务器将数据发送给客户端；

MFS的写数据过程

  1. 当客户端有数据写需求时，首先向管理服务器提供文件元数据信息请求存储地址（元数据信息如：文件名|大小|份数等）；

  2. 管理服务器根据写文件的元数据信息，到数据服务器创建新的数据块；

  3. 数据服务器返回创建成功的消息；

  4. 管理服务器将数据服务器的地址返回给客户端(chunkIP|port|chunkid)；

  5. 客户端向数据服务器写数据；

  6. 数据服务器返回给客户端写成功的消息；

  7. 客户端将此次写完成结束信号和一些信息发送到管理服务器来更新文件的长度和最后修改时间

MFS的删除文件过程

  1. 客户端有删除操作时，首先向Master发送删除信息；

  2. Master定位到相应元数据信息进行删除，并将chunk server上块的删除操作加入队列异步清理；

  3. 响应客户端删除成功的信号

MFS修改文件内容的过程

  1. 客户端有修改文件内容时，首先向Master发送操作信息；

  2. Master申请新的块给.swp文件，

  3. 客户端关闭文件后，会向Master发送关闭信息；

  4. Master会检测内容是否有更新，若有，则申请新的块存放更改后的文件，删除原有块和.swp文件块；

  5. 若无，则直接删除.swp文件块。

MFS重命名文件的过程

  1. 客户端重命名文件时，会向Master发送操作信息；

  2. Master直接修改元数据信息中的文件名；返回重命名完成信息；

MFS遍历文件的过程

  1. 遍历文件不需要访问chunk server，当有客户端遍历请求时，向Master发送操作信息；

  2. Master返回相应元数据信息；

  3. 客户端接收到信息后显示

 

注：

·Master记录着管理信息，比如：文件路径|大小|存储的位置(ip,port,chunkid)|份数|时间等，元数据信息存在于内存中，会定期写入metadata.mfs.back文件中，定期同步到metalogger，操作实时写入changelog.*.mfs，实时同步到metalogger中。master启动将metadata.mfs载入内存，重命名为metadata.mfs.back文件。

·文件以chunk大小存储，每chunk最大为64M，小于64M的，该chunk的大小即为该文件大小（验证实际chunk文件略大于实际文件），超过64M的文件将被切分，以每一份（chunk）的大小不超过64M为原则；块的生成遵循规则：目录循环写入(00-FF 256个目录循环，step为2)、chunk文件递增生成、大文件切分目录连续。

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

·文件可以有多份copy，当goal为1时，文件会被随机存到一台chunkserver上，当goal的数大于1时，copy会由master调度保存到不同的chunkserver上，goal的大小不要超过chunkserver的数量，否则多出的copy，不会有chunkserver去存。