Mfs分佈式文件系統總結

1、MFS介紹：
Distinctive features of MooseFS are:
- higher reliability (data can be stored in several copies on separate computers)
高可用性：數據能夠在不一樣機器上存儲多個副本
- dynamically expanding disk space by attaching new computers/disks
動態擴展：隨時新增長機器或者是磁盤
- possibility of storing deleted files for a defined period of time ("trash
bin" service on a file system level)
回收站：可還原在回收站內的文件
- possibility of creating snapshot of a file, which means coherent copy of the
whole file, even while the file is being written.
快照：能夠對整個文件甚至在正在寫入的文件建立文件的快照

MFS文件系統結構: 包含4種角色:  
管理服務器managing server (master) ：負責各個數據存儲服務器的管理，文件讀寫調度，文件空間回收以及恢復.多節點拷貝。single computer managing the whole filesystem,storing metadata for every file (information on size, attributes and file localisation(s), including all information about non-regular files, i.e.directories, sockets, pipes and devices).
Master（單個機器）管理整個文件系統，用來存儲記錄每個文件的Metadata（記錄文件的大小、文件的屬性、文件的位置，也包括非規則文件，如目錄、sockets、管道和設備）
 
元數據日誌服務器Metalogger server（Metalogger）：負責備份master服務器的變化日誌文件，文件類型爲changelog_ml.*.mfs，以便於在master server出問題的時候接替其進行工做。
數據存儲服務器data servers (chunkservers)  ：負責鏈接管理服務器,遵從管理服務器調度，提供存儲空間，併爲客戶提供數據傳輸。
客戶機掛載使用client computers  ：經過fuse內核接口掛接遠程管理服務器上所管理的數據存儲服務器,.看起來共享的文件系統和本地unix文件系統使用同樣的效果。
 
2、mfs各元素主要配置文件
1、master

Metadata（元數據）存儲在master服務器的內存中，同時也保存在磁盤上（做爲一個按期更新的二進制文件，並實時的更新changelog日誌）。若是存在metaloggers的話，主要的二進制文件以及日誌也複製到metaloggers中。

在咱們的測試環境中（大約500 T的數據，2500萬個文件，200萬文件夾，分紅2600萬個塊（chunks）分佈在70機器上），chunkserver的CPU使用狀況爲（持續傳輸文件）約爲15-20％，內存使用100MiB（和數據量的多少無關）。
 
master服務器CPU消耗約30％（每秒約1500次操做），使用了8G內存。 CPU負載取決於操做的次數，內存的使用取決於文件和文件夾的個數。
 
文件數據是以塊（chunks）爲單位（塊的最大大小64MB以上）存儲在數據服務器（chunkservers）上的指定磁盤上。每一個chunks存儲在不一樣的機器上，但總數等於設定的「goal」
 
Master最重要的因素就是內存，由於整個文件系統結構都緩存到內存中以便加快訪問速度。除了內存要求大，mfsmaster機器還須要必定硬盤大小用來存儲Metadata數據和增加的日誌文件。
 
Metadata文件的大小是取決於文件數的多少（而不是他們的大小）。changelog日誌的大小是取決於每小時操做的數目，可是這個時間長度（默認是按小時）是可配置的。
 
100萬文件大約須要300M內存。2500萬份文件大約須要8G內存和25G硬盤空間。
 
master主要文件
mfsmaster.cfg
參數說明以下：
#WORKING_USER和WORKING_GROUP：是運行master server的用戶和組；
#SYSLOG_IDENT：是master server在syslog中的標識，也就是說明這是由master server產生的；
#LOCK_MEMORY：是否執行mlockall()以免mfsmaster 進程溢出（默認爲0，即否）；
#NICE_LEVE：運行的優先級(若是能夠默認是 -19; 注意: 進程必須是用root啓動)；
#EXPORTS_FILENAME：被掛接目錄及其權限控制文件的存放位置
#DATA_PATH：metadata files and lock file存放路徑，此目錄下大體有如下文件：metadata，changelog，sessions，stats，lock。
#BACK_LOGS：metadata的change log文件數目(默認是 50);
#REPLICATIONS_DELAY_INIT：(initial delay in seconds before starting replications)初始延遲複製的時間（默認是300s）;
#REPLICATIONS_DELAY_DISCONNECT：(replication delay in seconds after chunkserver disconnection） chunkserver斷開後複製延遲（默認是3600s）；
# MATOML_LISTEN_HOST：用於metalogger鏈接的IP地址(默認是*，表明任何IP)；
# MATOML_LISTEN_PORT：監聽metalogger請求的端口地址(默認是9419)；
# MATOCS_LISTEN_HOST：用於chunkserver鏈接的IP地址（默認是*，表明任何IP）；
# MATOCS_LISTEN_PORT：監聽chunkserver鏈接的端口地址（默認是9420）；
# MATOCU_LISTEN_HOST：用於客戶端掛接鏈接的IP地址(默認是*，表明任何IP)；
# MATOCU_LISTEN_PORT：監聽客戶端掛載鏈接的端口地址（默認是9421）；
# CHUNKS_LOOP_TIME ：（Chunks loop frequency in seconds）chunks的迴環頻率（默認是：300秒）；
# CHUNKS_DEL_LIMIT：（Maximum number of chunks to delete in one loop）在一個loop中能夠刪除chunks的最大數 (默認：100)
# CHUNKS_WRITE_REP_LIMIT：（Maximum number of chunks to replicate to one chunkserver in one loop）在一個loop裏複製到一個chunkserver的最大chunk數目（默認是1）
# CHUNKS_READ_REP_LIMIT：（Maximum number of chunks to replicate from one chunkserver in one loop）在一個loop裏從一個chunkserver複製的最大chunk數目（默認是5）
# REJECT_OLD_CLIENTS：彈出低於1.6.0的客戶端掛接（0或1，默認是0）
 
mfsexports.cfg
MooseFS access control file
地址能夠指定的幾種表現形式：全部ip，單個ip，IP網絡地址/位數掩碼，IP網絡地址/子網掩碼，ip段範圍。
權限部分：
ro  只讀模式共享
rw  讀寫方式共享
alldirs  許掛載任何指定的子目錄
maproot   映射爲root，仍是指定的用戶
password  指定客戶端密碼
 
 
.mfsmaster.lock
master進程鎖文件
 
metadata.mfs, metadata.mfs.back
MFS文件系統的元數據的鏡像
 
changelog.*.mfs
changelog.*.mfs 是MFS文件系統元數據的改變日誌（每小時合併到metadata.mfs中一次）
 
Metadata文件的大小取決於文件數（而不是他們的大小），Changelog的大小取決於每小時的操做次數。
 
2、metalogger
主要文件：
mfsmetalogger.cfg
# WORKING_USER = mfs
# WORKING_GROUP = mfs
# SYSLOG_IDENT = mfsmetalogger
# LOCK_MEMORY = 0
# NICE_LEVEL = -19
 
# DATA_PATH = /usr/local/mfs/var/mfs
 
# BACK_LOGS = 50
META_DOWNLOAD_FREQ = 1 # 元數據下載間隔時間（默認是24小時，單位是小時，至可能是BACK_LOGS的1/2）
 
# MASTER_RECONNECTION_DELAY = 5   # 失去鏈接以後延遲多少秒從新鏈接master
 
MASTER_HOST = 192.168.5.230
# MASTER_PORT = 9419
 
# MASTER_TIMEOUT = 60 #鏈接master超時時間（單位是秒）
 
# deprecated, to be removed in MooseFS 1.7
# LOCK_FILE = /var/run/mfs/mfsmetalogger.lock
 
.mfsmetalogger.lock
 
changelog_ml.*.mfs
MooseFS filesystem metadata change logs (backup of master change log files)
MFS文件系統的元數據changelog日誌（備份Master的changelog日誌。）
 
metadata.ml.mfs.back
Latest copy of complete metadata.mfs.back file from MooseFS master.
最近一次從Master上徹底複製metadata.mfs.back（備份master的metadata.mfs.back）
 
sessions.ml.mfs
Latest copy of sessions.mfs file from MooseFS master.
最近一次從Master上徹底複製sessions.mfs（備份master的sessions.mfs）
 
3、chunker
主要文件：
mfschunkserver.cfg
# WORKING_USER = mfs
# WORKING_GROUP = mfs
# SYSLOG_IDENT = mfschunkserver
# LOCK_MEMORY = 0
# NICE_LEVEL = -19
 
# DATA_PATH = /usr/local/mfs/var/mfs
# MASTER_RECONNECTION_DELAY = 5 （ 
 MASTER_HOST = 192.168.5.230 元數據服務器的名稱或地址，能夠是主機名，也能夠是ip地址。只要數據存儲服務器能訪問到元數據服務器就行。
# MASTER_PORT = 9420
 
# MASTER_TIMEOUT = 60
 
# CSSERV_LISTEN_HOST = *  
# CSSERV_LISTEN_PORT = 9422
# CSSERV_TIMEOUT = 5       
# HDD_CONF_FILENAME = /usr/local/mfs/etc/mfshdd.cfg #分配給MFS使用的磁盤空間配置文件的位置
# HDD_TEST_FREQ = 10   #chunk test period in seconds
 
# deprecated, to be removed in MooseFS 1.7
# LOCK_FILE = /var/run/mfs/mfschunkserver.lock
# BACK_LOGS = 50
 
 
mfshdd.cfg
 
mfschunkserver.lock
lock file of running MooseFS chunkserver process
 
4、mfsmount

3、MFS讀寫性能：
簡單測試結果：
寫：time dd if=/dev/zero of=/usr/mfstest/test2/zhhtest500M  bs=1024k count=500
讀：time dd if=/usr/mfstest/test2/zhhtest500M  of=/dev/null
 
1copy寫
2copy寫
1copy讀
2copy讀
1M
0m0.042s
0m0.042s
0m0.017s
0m0.017s
2M
0m0.056s
0m0.066s
0m0.030s
0m0.055s
5M
0m0.073s
0m0.079s
0m0.070s
0m0.071s
10M
0m0.119s
0m0.131s
0m0.136s
0m0.197s
20M
0m0.250s
0m0.288s
0m0.291s
0m0.376s
50M
0m0.514s
0m0.589s
 0m0.896s
0m0.886s
100M
0m0.977s
0m7.497s
0m1.677s
0m1.787s
200M
0m7.910s
0m22.270s
 0m2.683s
0m3.129s
500M
0m22.465s
0m51.735s
0m6.559s
0m6.990s
1G
0m52.346s
1m48.056s
0m17.319s
0m17.154s
2G
1m46.224s
3m46.283s
0m41.608s
0m34.435s
5G
4m41.956s
9m34.798s
2m9.200s
1m56.183s
10G
9m29.037s
19m26.237s
3m55.222s
3m24.914s
100G
95m53.500s
195m7.173s
32m4.295s
41m26.995s
 
總結規律：
1、讀速度：ca 71M/s   寫速度：ca 22M/s  9M/s   （以500M計算）粗略測試，不太準確。
2、goal的設置和讀寫速度的關係？官方說goal和讀寫速度沒有關係，但實際測試中goal越大，寫速度越慢。
 

原始的讀/寫速度很明顯主要取決於所使用的硬盤的性能、網絡的容量和拓撲結構，使用的硬盤和網絡的吞吐量越好，整個系統的性能也就會越好。
 
在咱們的測試環境中，商業服務器（還作了其餘較大量的計算），使用Debian操做系統，設置存儲的份數爲2，簡單的千兆網絡，使用P級別的數據，測試的結果：寫速度大約在20-30MB/s，讀速度爲30-50MB/s。對於小文件寫速度有些降低，可是對於讀速度是沒有影響的。
 
通常來講，goal不會影響讀寫速度。在必定條件下，存儲份數的設置會影響的讀取的速度。例如，多個客戶端同時請求同一個文件，設置goal爲2比1的讀取速度快。可是在真實的環境中，多個客戶端同時讀取同一個文件的機率是比較小的，所以，存儲份數的設置對讀取的速度影響是比較小的。
一樣，設置存儲份數對寫速度影響也是不太大。

 

4、災難測試、恢復及其餘測試 
1、client 機器不管怎樣操做都不會影響master。
客戶端強制kill -9殺掉mfsmount進程，須要先umount，而後再mount。不然會提示：
fuse: bad mount point `/usr/mfstest/': Transport endpoint is not connected
see: /usr/local/mfs/bin/mfsmount -h for help
 
2、matser、metalogger、chunker、client端，服務器關機（init0）和重啓（init6）時，程序都是正常關閉，無需修復。
 
3、master啓動後，metalogger、chunker、client三個元素都能自動與master創建鏈接。
正常啓動順序：matser---chunker---metalogger---client
    關閉順序：client---chunker---metalogger---master
但實際中不管如何順序啓動或關閉，未見任何異常。
 
4、整個mfs體系中，直接斷電只有master有可能沒法啓動。
使用mfsmetarestore -a修復才能啓動，若是沒法修復，使用metalogger上的備份日誌進行恢復。（幾回測試發現：若是mfsmetarestore -a沒法修復，則使用metalogger也沒法修復）。
強制使用metadata.mfs.back建立metadata.mfs，能夠啓動master，但應該會丟失1小時的數據。
mfs開發小組針對此問題回信：明確表示會丟失故障點到上一個整點之間的數據。和以前我猜想的一致。由於對mfs的操做日誌都記錄到changelog.0.mfs裏面。changelog.0.mfs每小時合併一次到metadata.mfs中，若是忽然斷電，則changelog.0.mfs裏面的信息就沒有合併到metadata中，強制使用metadata.mfs.back建立metadata.mfs，就會致使丟失changelog.0.mfs裏的數據。

直接斷電測試過程，使用mfsmetarestore –a沒法修復，使用metalogger也沒法修復的狀況較少發生。5次只有一次沒法修復。
 
5、chunker的維持：chunker的塊（chunks）可以自動複製或刪除
 
對一個目錄設定「goal」，此目錄下的新建立文件和子目錄均會繼承此目錄的設定，但不會改變已經存在的文件及目錄的copy份數。但使用-r選項能夠更改已經存在的copy份數。
 
goal設置爲2，只要兩個chunker有一個可以正常運行，數據就能保證完整性。
假如每一個文件的goal（保存份數）都不小於2，而且沒有under-goal文件（能夠用mfsgetgoal –r和mfsdirinfo命令來檢查），那麼一個單一的chunkserver在任什麼時候刻均可能作中止或者是從新啓動。之後每當須要作中止或者是從新啓動另外一個chunkserver的時候，要肯定以前的chunkserver被鏈接，並且要沒有under-goal chunks。
 
實際測試時，傳輸一個大文件，設置存儲2份。傳輸過程當中，關掉chunker1，這樣絕對會出現有部分塊只存在chunker2上；啓動chunker1，關閉chuner2，這樣絕對會有部分塊只存在chuner1上。
把chunker2啓動起來。整個過程當中，客戶端一直可以正常傳輸。
在客戶端查看，一段時間內，沒法查看；稍後一段時間後，就能夠訪問了。文件正常，使用mfsfileinfo 查看此文件，發現有的塊分佈在chunker1上，有的塊分佈在chuner2上。
使用mfssetgoal 2和mfssetgoal -r 2均不能改變此文件的目前塊的現狀。
但使用mfssetgoal -r 1後，全部塊都修改爲1塊了，再mfssetgoal -r 2，全部塊都修改爲2份了。
 
 
測試chunker端，直接斷電狀況下，chunker會不會出問題：
a、數據傳輸過程當中，關掉chunker1，等待數據傳輸完畢後，開機啓動chunker1.
chunker1啓動後，會自動從chunker2複製數據塊。整個過程當中文件訪問不受影響。
b、數據傳輸過程當中，關掉chunker1，不等待數據傳輸完畢，開機啓動chunker1.
chunker1啓動後，client端會向chunker1傳輸數據，同時chunker1也從chunker2複製缺失的塊。
 
若是有三臺chunker，設置goal=2，則隨機挑選2個chunker存儲。
若是有一個chunker不能提供服務，則剩餘的2個chunker上確定有部分chunks保存的是一份。則在參數（REPLICATIONS_DELAY_DISCONNECT = 3600）後，只有一份的chunks會自動複製一份，即保存兩份。
保存兩份後，若是此時壞掉的chunker可以提供服務後，此時確定有部分chunks存儲了三份，mfs會自動刪除一份。
 
當我增長第三個服務器作爲額外的chunkserver時，雖然goal設置爲2，但看起來第三個chunkserver從另外兩個chunkserver上覆制數據。
是的，硬盤空間平衡器是獨立地使用chunks的，所以一個文件的chunks會被從新分配到全部的chunkserver上。
 
6、chunks修復 ：mfsfilerepair
mfsfilerepair用來處理壞文件（如讀操做引發的I/O錯誤），使文件可以部分可讀。在丟失塊的狀況下使用0對丟失部分進行填充；在塊的版本號（version）不匹配時設置塊的版本號爲master上已知的能在chunkerservers找到的最高版本號；注意：由於在第二種狀況下，可能存在塊的版本號同樣，但內容不匹配，所以建議在文件修復後，對文件進行拷貝（不是快照！），並刪除原始文件。
 
Client端大文件傳輸過程當中，強制拔下master主機電源，形成master非法關閉，使用mfsmetarestore -a修復後，master日誌報告有壞塊：
Jan 19 17:22:17 ngmaster mfsmaster[3250]: chunkserver has nonexistent chunk (000000000002139F_00000001), so create it for future deletion
Jan 19 17:22:18 ngmaster mfsmaster[3250]: (192.168.5.232:9422) chunk: 000000000002139F creation status: 20
Jan 19 17:25:18 ngmaster mfsmaster[3250]: chunk 000000000002139F has only invalid copies (1) - please repair it manually 
Jan 19 17:25:18 ngmaster mfsmaster[3250]: chunk 000000000002139F_00000001 - invalid copy on (192.168.5.232 - ver:00000000)
Jan 19 17:26:43 ngmaster mfsmaster[3250]: currently unavailable chunk 000000000002139F (inode: 135845 ; index: 23)
Jan 19 17:26:43 ngmaster mfsmaster[3250]: * currently unavailable file 135845: blog.xxx.cn-access_log200904.tar.gz
Client端使用mfsfilerepair修復
[root@localhost mfstest]# /usr/local/mfs/bin/mfsfilerepair blog.xxx.cn-access_log200904.tar.gz 
blog.xxt.cn-access_log200904.tar.gz:
chunks not changed: 23
chunks erased: 1
chunks repaired: 0
查看master日誌，發現：
Jan 19 17:30:17 ngmaster mfsmaster[3250]: chunk hasn't been deleted since previous loop - retry
Jan 19 17:30:17 ngmaster mfsmaster[3250]: (192.168.5.232:9422) chunk: 000000000002139F deletion status: 13
Jan 19 17:35:16 ngmaster mfsmaster[3250]: chunk hasn't been deleted since previous loop - retry
Jan 19 17:35:16 ngmaster mfsmaster[3250]: (192.168.5.232:9422) chunk: 000000000002139F deletion status: 13
Client端執行如下操做後，master再也不報告相關信息：
mv blog.xxt.cn-access_log200904.tar.gz blog.xxt.cn-access_log200905.tar.gz
7、chunker的空間
每個chunkserver的磁盤都要爲增加中的chunks保留些磁盤空間，從而達到建立新的chunk。只有磁盤都超過256M而且chunkservers報告自由空間超過1GB總量才能夠被新的數據訪問。最小的配置,應該從幾個G 字節的存儲。
每一個chunkerserver每次以256M的磁盤空間進行申請，客戶端查看獲得的磁盤總使用狀況的是每一個chunkerserver使用量的總和。例如：若是你有3個chunkerserver，7個分區磁盤，每次你的硬盤使用會增長3*7*256MB (大約5GB)。假如你有150T的硬盤空間，磁盤空間就不用過多考慮了。
另外，若是你的chunkservers使用專用的磁盤，df將顯示正確的磁盤使用狀況。可是若是你有其餘的數據在你的MooseFS磁盤上，df將會計算你全部的文件。

若是你想看你的MooseFS文件的使用狀況，請使用'mfsdirinfo'命令。
 
8、快照snapshot
能夠快照任何一個文件或目錄，語法：mfsmakesnapshot src dst
可是src和dst必須都屬於mfs體系，即不能mfs體系中的文件快照到其餘文件系統。both elements must be on the same device。
Mfsappendchunks：追加chunks到一個文件
 
snapshot測試：
a、對一個文件作snapshot後，查看兩個文件的塊，是同一個塊。把原文件刪除，原文件刪除後（回收站中最初能夠看到，但一段時間後，回收站中就完全刪除了），snapshot文件仍然存在，而且能夠訪問。使用mfsfileinfo查看，發現仍然是原來的塊。
b、對一個文件作snapshot後，查看兩個文件的塊，是同一個塊。把原文件修改後，發現原文件使用的塊名變了，即便用的是一個新塊。而snapshot文件仍然使用原來的塊。
 
9、回收站 trash bin
設置文件或目錄的刪除時間。一個刪除的文件可以存放在「 垃圾箱」中的時間稱爲隔離時間， 這個時間能夠用mfsgettrashtime 命令來查看，用mfssettrashtime 命令來設置。單位爲秒。
單獨安裝或掛載MFSMETA 文件系統（mfsmount -m mountpoint），它包含目錄/ trash (包含仍然能夠被還原的刪除文件的信息)和/ trash/undel (用於獲取文件)。
把刪除的文件，移到/ trash/undel下，就能夠恢復此文件。
在MFSMETA 的目錄裏，除了trash 和trash/undel 兩個目錄，還有第三個目錄reserved，該目錄內有已經刪除的文件，但卻被其餘用戶一直打開着。在用戶關閉了這些被打開的文件後，reserved 目錄中的文件將被刪除，文件的數據也將被當即刪除。此目錄不能進行操做。
 
10、文件描述符
1.5.12版本，進行大量小文件寫時，出現了一個嚴重錯誤，有可能和操做系統文件描述符有關。操做系統默認文件描述符爲1024.
1.6.11版本默認爲100000
建議上線時，master和chunker修改文件描述符，即修改/etc/security/limits.conf添加
* - nofile 65535
 
11、mfscgiserv
Mfscgiserv 是一個python 腳本， 它的監聽端口是9425 ，使用/usr/local/mfs/sbin/mfscgiserv 來直接啓動，使用瀏覽器就可全面監控全部客戶掛接， chunkserver 及master server，客戶端的各類操做等。