一、测试环境说明：
10.2.2.230 mfsmaster VIP:10.2.2.130
10.2.2.231 mfsbackup
10.2.2.253 mfsdata01
10.2.2.246 mfsdata02
10.2.2.236 mfsdata03
10.2.2.240 mfsdata04
10.2.2.241 mfsclient
二、分别就client、chunker、master的模拟服务器宕机、断网、故障恢复等环境，进行测试并就出现问题的解决办法。
（1）、MFS的client端:
a. client端宕机、断网对MFS的体系不产生影响
b. 杀掉MFS的client服务会产生
df: '/data/mfsdata': Transport endpoint is not connected
处理的方式:
是umount /data/mfsdata，然后再重新挂载就可以了，这种情况是用户MFS客户端出现误杀的情况。
（2）、MFS的chunker端：
a.断网、杀掉MFS的chunker程序对MFS系统无影响。
b. 宕机：
#无文件传输时，对三个chunker都无影响；
#当有文件传输时，但是文件设置存储一份时，对MFS系统无影响。
#当有文件传输，且设置文件存储多份时：
★关掉chunker1之后，如果在chunker1恢复正常之前文件已经传输完毕，那么数据将从chunker2、chunker3同步到chunker1中，并同时自动清除chunker2、chunker3上的部分文件以便达到chunker1、chunker2、chunker3使用容量的基本均衡。
★关掉chunker1之后，如果在 chunker1恢复之后文件尚未传输完毕，那么文件将一方面继续传输一方面从chunker2、chunker3中进行文件的同步到 chunker3，最终达到chunker1、chunker2、chunker3使用容量的基本均衡。
★关掉chunker1之后随即chunker2也挂掉，如果在chunker1、chunker2恢复正常之前文件已经传输完毕，文件数据都会写到chunker3中，之后chunker1、chunker2恢复，那么文件将从chunker3同步到chunker1、chunker2，最终达到chunker1、chunker2、chunker3使用容量的基本均衡。
★关掉chunker1之后随即chunker2也挂掉，如果在chunker1、chunker2恢复正常之后文件尚未传输完毕，文件一部分从chunker3同步到chunker1、chunker2，一部分均匀写到chunker1、chunker2、chunker3中，最终达到chunker1、chunker2、chunker3使用容量的基本均衡。
★关掉chunker1之后随即chunker2、chunker3也挂掉的话就会影响MFS的应用，因为已经没有了可用的chunker服务器了。
综上可知，只要不是三个chunker服务器同时挂掉的话，就不会影响文件的传输，也不会影响服务的使用。
（3）MFS的master端：
前提：实时的对master端数据目录及配置文件目录做备份，推送到其他的备份服务器中。
a. 断网、停掉master服务对MFS系统无影响。
b. 宕机可能会出现以下的情况：
#若服务器宕机后重启恢复，运行/application/mfs/sbin/mfsmaster start恢复master服务。
#若服务器宕机后不能重启恢复，修复的方法有如下几种：
1）搭建新的master环境，保证配置文件路径和宕机的master机器一致，用实时备份的master端数据目录及配置文件目录修复，修复命令：/application/mfs/sbin/mfsmetarestore -a
之后重启master服务就可以了。
2）若有metalogger服务器，把backup提升为主master的操作
可以把实时备份的master端配置文件目录拷贝到metalogger对应的目录下，使用metalogger改变的日志文件修复的命令：mfsmetarestore -m metadata.mfs.back -o metadata.mfs changelog_ml.*.mfs，
之后重启master服务就可以了。
三、MFS集群的维护
最安全的启动MooseFS 集群（避免任何读或写的错误数据或类似的问题）的方式是按照以下命令步骤：
启动mfsmaster 进程
启动所有的mfschunkserver 进程
启动mfsmetalogger 进程（如果配置了mfsmetalogger）
当所有的chunkservers 连接到MooseFS master 后，任何数目的客户端可以利用mfsmount 去挂接export 的文件系统。（可以通过检查master 的日志或是CGI 监视器来查看是否所有的chunkserver被连接）。
停止MFS集群：
安全的停止MooseFS 集群
在所有的客户端卸载MooseFS 文件系统（用umount 命令或者是其它等效的命令）
用mfschunkserver stop 命令停止chunkserver 进程
用mfsmetalogger stop 命令停止metalogger 进程
用mfsmaster stop 命令停止master 进程
四、MFS读写性能：
简单测试结果：
写：
time dd if=/dev/zero of=/data/mfsdata/mfsdata/test500M bs=1M count=500
读：
time dd if=/data/mfsdata/mfsdata/test500M of=/dev/null
|
|
1copy写 |
2copy写 |
1copy读 |
2copy读 |
|
2M |
0m0.139s |
0m0.119s |
0m0.014s |
0m0.055s |
|
5M |
0m0.093s |
0m0.092s |
0m0.014s |
0m0.011s |
|
20M |
0m0.264s |
0m0.313s |
0m0.026s |
0m0.030s |
|
50M |
0m1.312s |
0m0.460s |
0m0.066s |
0m0.056s |
|
200M |
0m2.437s |
0m4.171s |
0m0.165s |
0m0.169s |
|
500M |
0m5.984s |
0m11.511s |
0m3.047s |
0m5.946s |
|
1G |
0m11.875s |
0m26.839s |
0m17.247s |
0m16.223s |
|
2G |
0m55.460s |
0m55.460s |
1m21.784s |
0m55.736s |
总结：读速度：ca 84.3M/s 写速度：ca 39.4M/s 9M/s （以500M计算）
补充：
上面是在mfs的1.x版本上的测试结果，在mfs的2.x版本的测试流程也是一样的，只是修复故障的命令有些更改。更改后的命令操作如下：
前提：实时备份mfsmaster端的配置文件及数据文件最重要。
1）mfsmaster机器数据丢失损坏导致服务器起不来，可以通过如下方式修复：
mfsmaster -a
2）mfsmaster机器数据丢失导致服务起不来时，可以通过如下方式修复：
把mfsmetalogger备节点的数据拷贝到mfsmaster端对应的路径下，
之后在mfsmaster端执行如下命令修复:
mfsmaster -a
3）把mfsmetalogger备机主动提升为mfsmaster角色：
把mfsmaster端备份的配置文件拷贝到mfsmetalogger对应的路径下，执行如下命令提升mfsmetalogger提升为mfsmaster角色：
mfsmaster -a
修复之后要修改mfsmetalogger机器的hosts文件及ip地址，以便mfschunkserver服务器与之通信。