接着上篇博文，上篇博文是講如何部署 MooseFS 的，部署完畢之後就要涉及到後續的使用了。在使用過程中，肯定會遇到一些故障和性能瓶頸。此時，我們就需要去操心 MooseFS 的管理、維護和優化工作了。
本篇就圍繞上面提到的三個方面，介紹 MooseFS 更深入的一些知識。
一、高級功能
1、副本
副本，在MFS中也被稱爲目標（Goal），它是指文件被複制的份數，設定目標值後可以通過mfsgetgoal命令來證實，也可以通過mfssetgoal命令來改變設定。
[root@mfs-client ~]# cd /mfsdata/ [root@mfs-client mfsdata]# dd if=/dev/zero of=/mfsdata/test.file bs=1M count=200 200+0 records in 200+0 records out 209715200 bytes (210 MB) copied, 9.1094 s, 23.0 MB/s [root@mfs-client mfsdata]# mfsgetgoal test.file test.file: 1 [root@mfs-client mfsdata]# mfssetgoal 3 test.file test.file: 3 [root@mfs-client mfsdata]# mfsgetgoal test.file test.file: 3
補充：
用mfsgetgoal –r和mfssetgoal –r同樣的操作可以對整個樹形目錄遞歸操作
[root@mfs-client mfsdata]# mkdir dir/dir1/dir2/dir3 -p [root@mfs-client mfsdata]# touch dir/file1 [root@mfs-client mfsdata]# touch dir/dir1/file2 [root@mfs-client mfsdata]# touch dir/dir1/dir2/file3 [root@mfs-client mfsdata]# mfsgetgoal -r dir dir: files with goal 1 : 3 directories with goal 1 : 4 [root@mfs-client mfsdata]# mfssetgoal -r 3 dir dir: inodes with goal changed: 7 inodes with goal not changed: 0 inodes with permission denied: 0
實際的拷貝份數可以通過mfscheckfile 和 mfsfileinfo 命令來證實,例如：
[root@mfs-client mfsdata]# mfscheckfile test.file test.file: chunks with 1 copy: 4 [root@mfs-client mfsdata]# mfsfileinfo test.file test.file: chunk 0: 00000000000000D2_00000001 / (id:210 ver:1) copy 1: 172.16.100.6:9422 chunk 1: 00000000000000D3_00000001 / (id:211 ver:1) copy 1: 172.16.100.7:9422 chunk 2: 00000000000000D4_00000001 / (id:212 ver:1) copy 1: 172.16.100.6:9422 chunk 3: 00000000000000D5_00000001 / (id:213 ver:1) copy 1: 172.16.100.7:9422
需要注意的是，一個包含數據的零長度的文件，儘管沒有設置爲非零的目標（the non-zero goal），但是在使用命令查詢時將返回一個空值
[root@mfs-client mfsdata]# touch a [root@mfs-client mfsdata]# mfscheckfile a a: [root@mfs-client mfsdata]# mfsfileinfo a a:
2、回收
一個刪除文件能夠存放在一個“垃圾箱”的時間就是一個隔離時間，這個時間可以用 mfsgettrashtime 命令來驗證，也可以用 mfssettrashtime 命令來設置。例如：
[root@mfs-client mfsdata]# mfsgettrashtime test.file test.file: 86400 [root@mfs-client mfsdata]# mfssettrashtime 0 test.file test.file: 0 $ mfsgettrashtime /mnt/mfs-test/test1 /mnt/mfs-test/test1: 0
這些工具也有個遞歸選項-r，可以對整個目錄樹操作，例如：
[root@mfs-client mfsdata]# mfsgettrashtime -r dir dir: files with trashtime 86400 : 3 directories with trashtime 86400 : 4 [root@mfs-client mfsdata]# mfssettrashtime -r 0 dir dir: inodes with trashtime changed: 7 inodes with trashtime not changed: 0 inodes with permission denied: 0 [root@mfs-client mfsdata]# mfsgettrashtime -r dir dir: files with trashtime 0 : 3 directories with trashtime 0 : 4
時間的單位是秒(有用的值有:1小時是3600秒,24 – 86400秒,1 – 604800秒)。就像文件被存儲的份數一樣, 爲一個目錄 設定存放時間是要被新創建的文件和目錄所繼承的。數字0意味着一個文件被刪除後, 將立即被徹底刪除，在想回收是不可能的
刪除文件可以通過一個單獨安裝 MFSMETA 文件系統。特別是它包含目錄 / trash (包含任然可以被還原的被刪除文件的信息)和 / trash/undel (用於獲取文件)。只有管理員有權限訪問MFSMETA(用戶的uid 0，通常是root)。
在開始mfsmount進程時，用一個-m或-o mfsmeta的選項，這樣可以掛接一個輔助的文件系統MFSMETA，這麼做的目的是對於意外的從MooseFS捲上刪除文件或者是爲了釋放磁盤空間而移動的文件而又此文件又過去了垃圾文件存放期的恢復，例如：
mfsmount -m /mnt/mfsmeta
需要注意的是，如果要決定掛載mfsmeta，那麼一定要在 mfsmaster 的 mfsexports.cfg 文件中加入如下條目：
* . rw
原文件中有此條目，只要將其前的#去掉就可以了。
否則，你再進行掛載mfsmeta的時候，會報如下錯誤：
mfsmaster register error: Permission denied
下面將演示此操作：
$ mfssettrashtime 3600 /mnt/mfs-test/test1 /mnt/mfs-test/test1: 3600
從“垃圾箱”中刪除文件結果是釋放之前被它站用的空間(刪除有延遲,數據被異步刪除)。在這種被從“垃圾箱”刪除的情況下,該文件是不可能恢復了。
可以通過mfssetgoal工具來改變文件的拷貝數，也可以通過mfssettrashtime工具來改變存儲在“垃圾箱”中的時間。
在 MFSMETA 的目錄裏，除了trash和trash/undel兩個目錄外，還有第三個目錄reserved，該目錄內有已經刪除的文件，但卻有一直打開着。在用戶關閉了這些被打開的文件後，reserved目錄中的文件將被刪除，文件的數據也將被立即刪除。在reserved目錄中文件的命名方法同trash目錄中的一樣，但是不能有其他功能的操作。
3、快照
MooseFS系統的另一個特徵是利用mfsmakesnapshot工具給文件或者是目錄樹做快照，例如：
$ mfsmakesnapshot source ... destination
Mfsmakesnapshot 是在一次執行中整合了一個或是一組文件的拷貝，而且任何修改這些文件的源文件都不會影響到源文件的快照， 就是說任何對源文件的操作,例如寫入源文件，將不會修改副本(或反之亦然)。
文件快照可以用mfsappendchunks，就像MooseFS1.5中的mfssnapshot一樣，，作爲選擇，二者都可以用。例如：
$ mfsappendchunks destination-file source-file ...
當有多個源文件時，它們的快照被加入到同一個目標文件中（每個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/ 目錄下看到這個監控頁面的文件。
[root@mfs-master-1 mfs]# ll /usr/local/mfs/share/mfscgi/ # 這個 mfscgi 目錄裏面存放的是master圖形監控界面的程序 total 136 -rwxr-xr-x. 1 root root 1881 Dec 29 00:10 chart.cgi -rw-r--r--. 1 root root 270 Dec 29 00:10 err.gif -rw-r--r--. 1 root root 562 Dec 29 00:10 favicon.ico -rw-r--r--. 1 root root 510 Dec 29 00:10 index.html -rw-r--r--. 1 root root 3555 Dec 29 00:10 logomini.png -rwxr-xr-x. 1 root root 107456 Dec 29 00:10 mfs.cgi -rw-r--r--. 1 root root 5845 Dec 29 00:10 mfs.css
我們可以通過執行如下命令啓動該監控程序。
/moosefs_install_path/sbin/mfscgiserv start
啓動完畢之後，我們可以通過訪問http://IP:9425來訪問該監控頁面。
下面，我列出啓動 mfscgiserv 監控工具的操作：
[root@mfs-master-1 mfs]# /usr/local/mfs/sbin/mfscgiserv start # 啓動mfs圖形控制檯 lockfile created and locked starting simple cgi server (host: any , port: 9425 , rootpath: /usr/local/mfs-1.6.27/share/mfscgi) [root@mfs-master-1 mfs]# netstat -lantup|grep 9425 tcp 0 0 0.0.0.0:9425 0.0.0.0:* LISTEN 7940/python tcp 0 0 172.16.100.1:9425 172.16.100.100:50693 ESTABLISHED 7940/python tcp 0 0 172.16.100.1:9425 172.16.100.100:50692 ESTABLISHED 7940/python [root@mfs-master-1 mfs]# lsof -i tcp:9425 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME python 7940 root 3u IPv4 27066 0t0 TCP *:9425 (LISTEN) python 7940 root 7u IPv4 27136 0t0 TCP 172.16.100.1:9425->172.16.100.100:50693 (ESTABLISHED) python 7940 root 8u IPv4 27124 0t0 TCP 172.16.100.1:9425->172.16.100.100:50692 (ESTABLISHED)
下面是訪問的頁面：
2、使用zabbix監控mfs
1、監控要點
根據 MooseFS 中各個組件的特點，我們所需要監控的要點主要有如下幾點：
a、Master Server的9420、9421端口，Chunk Server 的9422端口
b、Chunk Server 的磁盤空間
2、實施步驟
通過在各個組件的對應服務器上部署好zabbix監控的代理端，然後分別添加端口監控和磁盤監控即可！
操作過程略！
八、維護
1、常用管理命令
mfsgetgoal # 獲取mfs目錄、文件的副本數 mfssetgoal # 設置mfs目錄、文件的副本數 mfscheckfile # 查看副本數簡單 mfsfileinfo # 查看詳細的副本數，chunks/分片 mfsdirinfo # 以數量的方法顯示mfsfileinfo mfsgettrashtime # 獲取垃圾箱的定隔時間 mfssettrashtime # 設置垃圾箱的定隔時間（和memcached類） mfsmakesnapshot # 快照
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的選型一定不能使用虛擬機，而是使用大內存量的物理機。