分佈式文件系統之MooseFS----管理優化

       接着上篇博文，上篇博文是講如何部署 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:

二、回收

       一個刪除文件可以存放在一個「垃圾箱」的時間就是一個隔離時間，這個時間能夠用 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目錄中的同樣，可是不能有其餘功能的操做。

三、快照

       MooseFS系統的另外一個特徵是利用mfsmakesnapshot工具給文件或者是目錄樹作快照，例如：

$ mfsmakesnapshot source ... destination

       Mfsmakesnapshot 是在一次執行中整合了一個或是一組文件的拷貝，並且任何修改這些文件的源文件都不會影響到源文件的快照， 就是說任何對源文件的操做,例如寫入源文件，將不會修改副本(或反之亦然)。
       文件快照能夠用mfsappendchunks，就像MooseFS1.5中的mfssnapshot同樣，，做爲選擇，兩者均可以用。例如：

$ mfsappendchunks destination-file source-file ...

       當有多個源文件時，它們的快照被加入到同一個目標文件中（每一個chunk的最大量是chunk）。5、額外的屬性文件或目錄的額外的屬性(noowner, noattrcache, noentrycache)，能夠被mfsgeteattr，mfsseteattr，mfsdeleattr工具檢查，設置，刪除，其行爲相似mfsgetgoal/mfssetgoal or或者是mfsgettrashtime/mfssettrashtime，詳細可見命令手冊。

2、綜合測試

一、破壞性測試

 a、模擬MFS各角色宕機測試

 b、mfs 災難與恢復各類場景測試

二、性能測試

       針對 MooseFS 的性能測試，我這邊也沒有詳細去作。經過偉大的互聯網，我找到了幾位前輩，針對 MooseFS 所作的詳細性能測試，這裏我就貼出來展現一下。

一、基準測試狀況：
隨機讀

隨機寫

順序讀

順序寫

小文件性能測試狀況：

        若是想看更多有關 MooseFS 性能方面的測試報告，能夠去參考以下連接：

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

3、監控

一、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)

下面是訪問的頁面：

二、使用zabbix監控mfs

一、監控要點

        根據 MooseFS 中各個組件的特色，咱們所須要監控的要點主要有以下幾點：

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

        b、Chunk Server 的磁盤空間

二、實施步驟

        經過在各個組件的對應服務器上部署好zabbix監控的代理端，而後分別添加端口監控和磁盤監控便可！

        操做過程略！

8、維護

一、經常使用管理命令

mfsgetgoal              # 獲取mfs目錄、文件的副本數
mfssetgoal              # 設置mfs目錄、文件的副本數
mfscheckfile            # 查看副本數簡單
mfsfileinfo             # 查看詳細的副本數，chunks/分片
mfsdirinfo              # 以數量的方法顯示mfsfileinfo
mfsgettrashtime         # 獲取垃圾箱的定隔時間
mfssettrashtime         # 設置垃圾箱的定隔時間（和memcached類）
mfsmakesnapshot         # 快照

二、可能存在的問題

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 的單點問題。

三、性能瓶頸的解決辦法

       因爲 MooseFS 的高可擴展性，所以咱們能夠很輕鬆的經過增長 Chunk Server 的磁盤容量或增長 Chunk Server 的數量來動態擴展整個文件系統的存儲量和吞吐量，這些操做絲絕不會影響到在線業務。

四、安全開啓/中止MFS集羣

一、啓動 MooseFS 集羣

安全的啓動 MooseFS 集羣（避免任何讀或寫的錯誤數據或相似的問題）的步驟以下：
       一、啓動 mfsmaster 進程
       二、啓動全部的 mfschunkserver 進程
       三、啓動 mfsmetalogger 進程（若是配置了mfsmetalogger）
       四、當全部的 chunkservers 鏈接到 MooseFS master 後，任何數目的客戶端能夠利用 mfsmount 去掛載被 export 的文件系統。（能夠經過檢查 master 的日誌或是 CGI 監控頁面來查看是否全部的chunkserver 被鏈接）。

二、中止 MooseFS 集羣

安全的中止 MooseFS 集羣的步驟以下：
       一、在全部的客戶端卸載MooseFS 文件系統（用umount命令或者是其它等效的命令）
       二、用 mfschunkserver –s命令中止chunkserver進程
       三、用 mfsmetalogger –s命令中止metalogger進程
       四、用 mfsmaster –s命令中止master進程

五、增長塊設備（會自動平均）

        針對增長塊設備的狀況，其實就是說針對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的選型必定不能使用虛擬機，而是使用大內存量的物理機。