一、測試環境說明：
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服務器與之通信。