接着上篇博文，上篇博文是讲如何部署 MooseFS 的，部署完毕之后就要涉及到后续的使用了。在使用过程中，肯定会遇到一些故障和性能瓶颈。此时，我们就需要去操心 MooseFS 的管理、维护和优化工作了。

本篇就围绕上面提到的三个方面，介绍 MooseFS 更深入的一些知识。

一、高级功能

1、副本

副本，在MFS中也被称为目标（Goal），它是指文件被复制的份数，设定目标值后可以通过mfsgetgoal命令来证实，也可以通过mfssetgoal命令来改变设定。

补充：

用mfsgetgoal –r和mfssetgoal –r同样的操作可以对整个树形目录递归操作

实际的拷贝份数可以通过mfscheckfile 和 mfsfileinfo 命令来证实,例如：

需要注意的是，一个包含数据的零长度的文件，尽管没有设置为非零的目标（the non-zero goal），但是在使用命令查询时将返回一个空值

2、回收

一个删除文件能够存放在一个“垃圾箱”的时间就是一个隔离时间，这个时间可以用 mfsgettrashtime 命令来验证，也可以用 mfssettrashtime 命令来设置。例如：

这些工具也有个递归选项-r，可以对整个目录树操作，例如：

时间的单位是秒(有用的值有:1小时是3600秒,24 – 86400秒,1 – 604800秒)。就像文件被存储的份数一样, 为一个目录 设定存放时间是要被新创建的文件和目录所继承的。数字0意味着一个文件被删除后, 将立即被彻底删除，在想回收是不可能的
       删除文件可以通过一个单独安装 MFSMETA 文件系统。特别是它包含目录 / trash (包含任然可以被还原的被删除文件的信息)和 / trash/undel (用于获取文件)。只有管理员有权限访问MFSMETA(用户的uid 0，通常是root)。

在开始mfsmount进程时，用一个-m或-o mfsmeta的选项，这样可以挂接一个辅助的文件系统MFSMETA，这么做的目的是对于意外的从MooseFS卷上删除文件或者是为了释放磁盘空间而移动的文件而又此文件又过去了垃圾文件存放期的恢复，例如：

需要注意的是，如果要决定挂载mfsmeta，那么一定要在 mfsmaster 的 mfsexports.cfg 文件中加入如下条目：

原文件中有此条目，只要将其前的#去掉就可以了。

否则，你再进行挂载mfsmeta的时候，会报如下错误：

下面将演示此操作：

从“垃圾箱”中删除文件结果是释放之前被它站用的空间(删除有延迟,数据被异步删除)。在这种被从“垃圾箱”删除的情况下,该文件是不可能恢复了。
       可以通过mfssetgoal工具来改变文件的拷贝数，也可以通过mfssettrashtime工具来改变存储在“垃圾箱”中的时间。
       在 MFSMETA 的目录里，除了trash和trash/undel两个目录外，还有第三个目录reserved，该目录内有已经删除的文件，但却有一直打开着。在用户关闭了这些被打开的文件后，reserved目录中的文件将被删除，文件的数据也将被立即删除。在reserved目录中文件的命名方法同trash目录中的一样，但是不能有其他功能的操作。

3、快照

MooseFS系统的另一个特征是利用mfsmakesnapshot工具给文件或者是目录树做快照，例如：

Mfsmakesnapshot 是在一次执行中整合了一个或是一组文件的拷贝，而且任何修改这些文件的源文件都不会影响到源文件的快照， 就是说任何对源文件的操作,例如写入源文件，将不会修改副本(或反之亦然)。
       文件快照可以用mfsappendchunks，就像MooseFS1.5中的mfssnapshot一样，，作为选择，二者都可以用。例如：

当有多个源文件时，它们的快照被加入到同一个目标文件中（每个chunk的最大量是chunk）。五、额外的属性文件或目录的额外的属性(noowner, noattrcache, noentrycache)，可以被mfsgeteattr，mfsseteattr，mfsdeleattr工具检查，设置，删除，其行为类似mfsgetgoal/mfssetgoal or或者是mfsgettrashtime/mfssettrashtime，详细可见命令手册。

二、综合测试

1、破坏性测试

a、模拟MFS各角色宕机测试

b、mfs 灾难与恢复各种场景测试

2、性能测试

针对 MooseFS 的性能测试，我这边也没有详细去做。通过伟大的互联网，我找到了几位前辈，针对 MooseFS 所做的详细性能测试，这里我就贴出来展示一下。

1、基准测试情况：
随机读

随机写

顺序读

顺序写

小文件性能测试情况：

如果想看更多有关 MooseFS 性能方面的测试报告，可以去参考如下链接：

http://blog.liuts.com/post/203/          MooseFS性能图表[原创]

三、监控

1、mfs内置的监控工具mfscgiserv

针对 Moosefs 每个组件的监控，Moosefs自带了一个监控工具 mfscgiserv，它是一个 python 编写的 web 监控页面，监听端口为9425。该监控页面为我们提供了 Master Server、Metalogger Server、Chunk Servers以及所有Client挂载的状态信息及相关性能指标图示。

在我们安装好 Master Server 时，它就已经默认安装上了，我们可以在/usr/local/mfs/share/mfscgi/  目录下看到这个监控页面的文件。

我们可以通过执行如下命令启动该监控程序。

启动完毕之后，我们可以通过访问http://IP:9425来访问该监控页面。

下面，我列出启动 mfscgiserv 监控工具的操作：

下面是访问的页面：

2、使用zabbix监控mfs

1、监控要点

根据 MooseFS 中各个组件的特点，我们所需要监控的要点主要有如下几点：

a、Master Server的9420、9421端口，Chunk Server 的9422端口

b、Chunk Server 的磁盘空间

2、实施步骤

通过在各个组件的对应服务器上部署好zabbix监控的代理端，然后分别添加端口监控和磁盘监控即可！

操作过程略！

八、维护

1、常用管理命令

2、可能存在的问题

A、mfscgiserv的访问安全问题

mfscgiserv只是一个非常简单的HTTP服务器，只用来编写运行MooseFS CGI脚本。它不支持任何的附加功能，比如HTTP认证。如果公司出于对监控界面的安全访问需求，我们可以使用功能丰富的HTTP服务器，比如apache、nginx等。在使用这些更强大的HTTP服务器时，我们只需要将CGI和其它数据文件（index.html、mfs.cgi、chart.cgi、mfs.css、logomini.png、err.gif）存放到选择的站点根目录下。我们可以创建一个新的虚拟机，来设定特定的主机名和端口来进行访问。

B、Master Server 的单点问题

Master server的单点问题，在前面介绍 MooseFS 的优缺点时已经提到过了。由于官方提供的解决方案，在恢复的时候还是需要一定时间的，因此我们建议使用第三方的高可用方案（heartbeat+drbd+moosefs）来解决 Master Server 的单点问题。

3、性能瓶颈的解决办法

由于 MooseFS 的高可扩展性，因此我们可以很轻松的通过增加 Chunk Server 的磁盘容量或增加 Chunk Server 的数量来动态扩展整个文件系统的存储量和吞吐量，这些操作丝毫不会影响到在线业务。

4、安全开启/停止MFS集群

1、启动 MooseFS 集群

安全的启动 MooseFS 集群（避免任何读或写的错误数据或类似的问题）的步骤如下：
       1、启动 mfsmaster 进程
       2、启动所有的 mfschunkserver 进程
       3、启动 mfsmetalogger 进程（如果配置了mfsmetalogger）
       4、当所有的 chunkservers 连接到 MooseFS master 后，任何数目的客户端可以利用 mfsmount 去挂载被 export 的文件系统。（可以通过检查 master 的日志或是 CGI 监控页面来查看是否所有的chunkserver 被连接）。

2、停止 MooseFS 集群

安全的停止 MooseFS 集群的步骤如下：
       1、在所有的客户端卸载MooseFS 文件系统（用umount命令或者是其它等效的命令）
       2、用 mfschunkserver –s命令停止chunkserver进程
       3、用 mfsmetalogger –s命令停止metalogger进程
       4、用 mfsmaster –s命令停止master进程

5、增加块设备（会自动平均）

针对增加块设备的情况，其实就是说针对chunk server 有变化（增加或减少）的情况。

为了增加一个案例说明，这里就以 UC 在使用 MooseFS 中遇到的一个问题为案例，讲解新增加 chunk server 时，MooseFS集群发生的变化，其实也就是 Master Server 发生的变化。

UC在使用 MooseFS 集群的过程中，有次一台 Chunk Server 挂了，于是就涉及到了后期的恢复问题。在问题Chunk Server修复之后，就从新加入到了集群当中。此时，新增加的 chunk server 启动之后会向 Master 汇报 Chunk 的信息，Master接收到 Chunk 信息之后会逐个检查 Chunk_id是否存在。如果不存在，就表示该chunk_id其实已经删除了（chunk_id过期），然后会调用chunk_new()创建该chunk，并设置lockedio属性为7天后。这些操作都是属于内存操作，并且Master是单线程的进程，并不存在全局锁，因此不会导致 Master 阻塞无响应。因此，针对增加chunk server的情况，是不会对MooseFS集群产生什么大的影响的。

以上就是新增加 Chunk Server 后的，MooseFS 集群中 Master Server 的变化。而针对各个Chunk Server，Master Server会重新去调整块文件的磁盘空间，然后全部重新动态分配块文件。如果遇到空间不够的磁盘，Master Server会自动调整块文件的分布，从不够的磁盘里动态的把块服务移动到有大的磁盘块服务器里

当然，如果按照上面的情况这次就不会是故障了，因此并不会对 MooseFS 集群产生什么大的影响。由于他们当时因为资源紧张，就把 Master Server 放到了虚拟机上，而虚拟机的磁盘是挂载的iscsi磁盘。并且他们的MooseFS使用的版本并不是最新的1.6.27，而是1.6.19。在1.6.19版本中，会把chunk的汇报过程写入磁盘，这样就导致了几十万条的磁盘写入，由于磁盘是前面提到的网络盘，就最终酿成了 Master Server 恢复时无响应几十分钟。

因此，我们在生产环境中，针对Master Server的选型一定不能使用虚拟机，而是使用大内存量的物理机。

本文转自 aaao 51CTO博客，原文链接：http://blog.51cto.com/nolinux/1602616，如需转载请自行联系原作者