MFS學習總結

公司使用moosefs做圖片存儲，最近學習了一下，在此小小總結一下，主要分以下幾部分：

MFS概述、特性和新版改進
MFS 工作原理和設計架構
MFS的安裝、部署、配置
MFS的高級特性
MFS的性能測試
MFS集羣的維護
MFS的常見問題和建議對策

一、MFS概述、特性和新版改進

MooseFS是一個分佈式存儲的框架，其具有如下特性：

Free(GPL)
通用文件系統，不需要修改上層應用就可以使用（那些需要專門api的dfs很麻煩！）。
可以在線擴容，體系架構可伸縮性極強。（官方的case可以擴到70臺了！）
部署簡單。（sa們特別高興，領導們特別happy！）
高可用，可設置任意的文件冗餘程度（提供比raid1+0更高的冗餘級別，而絕對不會影響讀或者寫的性能，只會加速！）
可回收在指定時間內刪除的文件（“回收站”提供的是系統級別的服務，不怕誤操作了，提供類似oralce 的閃回等高級dbms的即時回滾特性！）
提供netapp，emc，ibm等商業存儲的snapshot特性。（可以對整個文件甚至在正在寫入的文件創建文件的快照）
google filesystem的一個c實現。
提供web gui監控接口。
提高隨機讀或寫的效率（有待進一步證明）。
提高海量小文件的讀寫效率（有待進一步證明）。

MooseFS 1.6版本改進：

修復1.5.x中在大批量操作時打開文件過多的bug。報的錯誤說是打開的文件過多，造成chunker server的鏈接錯誤。在1.6.x中解決此問題，就解決了很大的問題。
新增加了masterlogger服務器。這是在1.5.x中所沒有的，就是做了master服務器的冗餘，進一步的加強的master服務器的穩定性。在mfs體系中master是要求最穩定以及性能要求最高的，因此務必保證master的穩定。
修改1.5.x中存在的對於壞塊的修復功能。在mfs1.5.x中遇到chunker壞塊校驗，錯誤比較多的時候導致master將出現壞塊的chunker自動的剔除出去的情況，此次增加了對壞塊的修復功能，很方便的進行修復，簡化對壞塊的處理功能。
對metadata和changelog的新認識。之前認爲changelog記錄的是文件的操作，定期的像數據庫的日誌一樣歸檔到metadata中。發現上面的理解存在誤區，真正的是changelog中記錄了對文件的操作，metadata記錄文件的大小和位置。因此metadata是比較重要的，在進行修復的過程中是採用metadata和最後一次的changelog進行修復的。
MFS文檔中明確指出對於內存和磁盤大小的要求。
指出了在測試的過程中多個chunker並不影響寫的速度，但是能加快讀的速度。在原來的基礎上增加一個chunker時，數據會自動同步到新增的chunker上以達到數據的平衡和均衡。

二、MFS 工作原理和設計架構

角色	角色作用
管理服務器 managing server (master)	負責各個數據存儲服務器的管理,文件讀寫調度,文件空間回收以及恢復.多節點拷貝
元數據日誌服務器 Metalogger server（Metalogger）	負責備份master 服務器的變化日誌文件，文件類型爲changelog_ml.*.mfs ，以便於在 master server 出問題的時候接替其進行工作
數據存儲服務器 data servers (chunkservers)	負責連接管理服務器,聽從管理服務器調度, 提供存儲空間，併爲客戶提供數據傳輸.
客戶機掛載使用 client computers	通過fuse 內核接口掛接遠程管理服務器上所管理的數據存儲服務器,.看起來共享的文件系統和本地unix 文件系統使用一樣的效果.

官方的網絡示意圖是這樣的：

讀寫原理：

MFS的讀數據過程

client當需要一個數據時，首先向master server發起查詢請求；
管理服務器檢索自己的數據，獲取到數據所在的可用數據服務器位置ip|port|chunkid；
管理服務器將數據服務器的地址發送給客戶端；
客戶端向具體的數據服務器發起數據獲取請求；
數據服務器將數據發送給客戶端；

MFS的寫數據過程

當客戶端有數據寫需求時，首先向管理服務器提供文件元數據信息請求存儲地址（元數據信息如：文件名|大小|份數等）；
管理服務器根據寫文件的元數據信息，到數據服務器創建新的數據塊；
數據服務器返回創建成功的消息；
管理服務器將數據服務器的地址返回給客戶端(chunkIP|port|chunkid)；
客戶端向數據服務器寫數據；
數據服務器返回給客戶端寫成功的消息；
客戶端將此次寫完成結束信號和一些信息發送到管理服務器來更新文件的長度和最後修改時間

MFS的刪除文件過程

客戶端有刪除操作時，首先向Master發送刪除信息；
Master定位到相應元數據信息進行刪除，並將chunk server上塊的刪除操作加入隊列異步清理；
響應客戶端刪除成功的信號

MFS修改文件內容的過程

客戶端有修改文件內容時，首先向Master發送操作信息；
Master申請新的塊給.swp文件，
客戶端關閉文件後，會向Master發送關閉信息；
Master會檢測內容是否有更新，若有，則申請新的塊存放更改後的文件，刪除原有塊和.swp文件塊；
若無，則直接刪除.swp文件塊。

MFS重命名文件的過程

客戶端重命名文件時，會向Master發送操作信息；
Master直接修改元數據信息中的文件名；返回重命名完成信息；

MFS遍歷文件的過程

遍歷文件不需要訪問chunk server，當有客戶端遍歷請求時，向Master發送操作信息；
Master返回相應元數據信息；
客戶端接收到信息後顯示

注：

Master記錄着管理信息，比如：文件路徑|大小|存儲的位置(ip,port,chunkid)|份數|時間等，元數據信息存在於內存中，會定期寫入metadata.mfs.back文件中，定期同步到metalogger，操作實時寫入changelog.*.mfs，實時同步到metalogger中。master啓動將metadata.mfs載入內存，重命名爲metadata.mfs.back文件。
文件以chunk大小存儲，每chunk最大爲64M，小於64M的，該chunk的大小即爲該文件大小（驗證實際chunk文件略大於實際文件），超過64M的文件將被切分，以每一份（chunk）的大小不超過64M爲原則；塊的生成遵循規則：目錄循環寫入(00-FF 256個目錄循環，step爲2)、chunk文件遞增生成、大文件切分目錄連續。
Chunkserver上的剩餘存儲空間要大於1GB（Reference Guide有提到），新的數據纔會被允許寫入，否則，你會看到No space left on device的提示，實際中，測試發現當磁盤使用率達到95%左右的時候，就已經不行寫入了，當時可用空間爲1.9GB。
文件可以有多份copy，當goal爲1時，文件會被隨機存到一臺chunkserver上，當goal的數大於1時，copy會由master調度保存到不同的chunkserver上，goal的大小不要超過chunkserver的數量，否則多出的copy，不會有chunkserver去存。

三、MFS的安裝、部署、配置

測試環境：

IP	作用
192.168.0.1	master server
192.168.0.2	metalogger server
192.168.0.3	chunk server
192.168.0.4	chunk server
192.168.0.5	chunk server
192.168.0.6	mfs client

3.1 Master Server

在192.168.0.1進行如下操作：

3.1.1 安裝:

$useradd mfs -s /sbin/nologin$wget http://www.moosefs.org/tl_files/mfscode/mfs-1.6.20-2.tar.gz$tar zxvf mfs-1.6.20-2.tar.gz$cd mfs-1.6.20-2/
$./configure --prefix=/usr/local/mfs --with-default-user=mfs --with-default-group=mfs --disable-mfschunkserver --disable-mfsmount$make$make install$cd /usr/local/mfs/etc$cp mfsmaster.cfg.dist mfsmaster.cfg  #主配置文件$cp mfsexports.cfg.dist mfsexports.cfg #被掛接目錄及權限配置

3.1.2 配置：

$vi /usr/local/mfs/etc/mfsmaster.cfg# WORKING_ USER = mfs   #運行master server 的用戶# WORKING_ GROUP = mfs   #運行master server 的組# SYSLOG_IDENT = mfsmaster #master server 在syslog 中的標識，說明是由master serve 產生的# LOCK_MEMORY = 0     #是否執行mlockall()以避免mfsmaster 進程溢出（默認爲0）# NICE_LEVEL = -19     #運行的優先級(如果可以默認是-19; 注意: 進程必須是用root 啓動)# EXPORTS_FILENAME = /usr/local/mfs/etc/mfsexports.cfg #被掛接目錄及其權限控制文件的存放位置# DATA_PATH = /usr/local/mfs/var/mfs  #數據存放路徑，此目錄下大致有三類文件，changelog，sessions 和stats；# BACK_LOGS = 50            #metadata 的改變log 文件數目(默認是50);# REPLICATIONS_ DELAY_INIT = 300    #延遲複製的時間（默認是300s）;# REPLICATIONS_ DELAY_DISCONNECT = 3600 #chunkserver 斷開的複製延遲（默認是3600）；# MATOML_LISTEN_HOST = *   #metalogger 監聽的IP 地址(默認是*，代表任何IP)；# MATOML_LISTEN_PORT = 9419 #metalogger 監聽的端口地址(默認是9419)；# MATOCS_LISTEN_ HOST = *  #用於chunkserver 連接的IP 地址（默認是*，代表任何IP）；# MATOCS_LISTEN_PORT = 9420 #用於chunkserver 連接的端口地址（默認是9420）；# MATOCU_LISTEN_HOST = *  #用於客戶端掛接連接的IP 地址(默認是*，代表任何IP)；# MATOCU_LISTEN_PORT = 9421 #用於客戶端掛接連接的端口地址（默認是9421）；# CHUNKS_LOOP_TIME = 300  #chunks 的迴環頻率（默認是：300 秒）；# CHUNKS_DEL_LIMIT = 100# CHUNKS_WRITE_REP_LIMIT = 1 #在一個循環裏複製到一個chunkserver 的最大chunk 數目（默認是1）# CHUNKS_READ_REP_LIMIT = 5 #在一個循環裏從一個chunkserver 複製的最大chunk 數目（默認是5）# REJECT_OLD_ CLIENTS = 0  #彈出低於1.6.0 的客戶端掛接（0 或1，默認是0）

注意：

凡是用#註釋掉的變量均使用其默認值
修改DATA_PATH指定的目錄要權限爲mfs，chown -R mfs:mfs /usr/local/mfs/var/mfs
mfsexports 訪問控制對於那些老客戶是沒用的
注意開通監聽的端口

$vi /usr/local/mfs/etc/mfsexports.cfg
  #客戶端IP允許掛載的目錄客戶端擁有的權限  192.168.0.0/24     /            rw,alldirs,maproot=0  # /標識MFS的根
    192.168.0.0/24     .            rw                    # .標識MFSMETA 文件系統

地址可以指定的格式：

IP格式	說明
*	所有的ip 地址
n.n.n.n	單個ip 地址
n.n.n.n/b	IP 網絡地址/位數掩碼
n.n.n.n/m.m.m.m	IP 網絡地址/子網掩碼
f.f.f.f-t.t.t.t	IP 段

權限說明：

權限	說明
ro	只讀模式
rw	讀寫模式
alldirs	許掛載任何指定的子目錄
maproot	映射爲root，還是指定的用戶
password	指定客戶端密碼

3.1.3 操作：

$/usr/local/mfs/sbin/mfsmaster [-vdu] [-t locktimeout] [-c cfgfile] [start|stop|restart|reload] #master服務操作
$/usr/local/mfs/sbin/mfscgiserv  #啓動WEBUI 監控服務，訪問http://192.168.0.1:9425/

注意：

最好不要kill master，安全停止執行mfsmaster stop，否則下次啓動因metadata.mfs.back而出現問題，還需要使用備份來恢復。

文件說明：

$ls -l /usr/local/mfs/var/mfs #此目錄見mfsmaster.cfg中DATA_PATH配置   metadata.mfs.back #MFS元數據信息，延遲將內存數據寫入文件，默認頻率1h，默認1d同步一次此文件到metalogger server
      changelog.*.mfs      #文件操作日誌記錄，實時記錄、同步到metalogger server
      sessions.mfs  #客戶操作狀態記錄
      stats.mfs        #？

3.1.4 備註：

用戶操作日誌見：changelog.*.mfs
進程產生的日誌放到系統日誌中：/var/log/messages
Master可以單獨啓動，注意開通監聽的端口

3.2 Chunk Server

在192.168.0.3-在192.168.0.5 進行如下操作

3.2.1 安裝：

$useradd mfs -s /sbin/nologin$wget http://www.moosefs.org/tl_files/mfscode/mfs-1.6.20-2.tar.gz$tar zxvf mfs-1.6.20-2.tar.gz$cd mfs-1.6.20-2/
$./configure --prefix=/usr/local/mfs --with-default-user=mfs --with-default-group=mfs --disable-mfsmaster --disable-mfsmount$make$make install$cd /usr/local/mfs/etc$cp mfschunkserver.cfg.dist mfschunkserver.cfg #chunk配置文件
$cp mfshdd.cfg.dist mfshdd.cfg #MFS使用空間配置

3.2.2 配置：

$vi /usr/local/mfs/etc/mfschunkserver.cfg# WORKING_USER = mfs# WORKING_GROUP = mfs# DATA_PATH = /usr/local/mfs/var/mfs# LOCK_FILE = /var/run/mfs/mfschunkserver.pid# SYSLOG_IDENT = mfschunkserver# BACK_LOGS = 50# MASTER_RECONNECTION_DELAY = 30
MASTER_HOST = 192.168.0.1 #元數據服務器的名稱或地址，可以是主機名，也可以是ip 地址# MASTER_PORT = 9420 #爲Matser中 MATOCS_LISTEN_PORT指定的端口# MASTER_TIMEOUT = 60# CSSERV_LISTEN_HOST = *# CSSERV_LISTEN_PORT = 9422 這個監聽端口用於與其它數據存儲服務器間的連接，通常是數據複製# CSSERV_TIMEOUT = 60# CSTOCS_TIMEOUT = 60# HDD_CONF_FILENAME = /usr/local/mfs/etc/mfshdd.cfg 分配給MFS 使用的磁盤空間配置文件的位置

注意：

MASTER_HOST 不能爲localhost或127.0.0.1，做單機測試的童鞋們注意了，要使用對外IP。
MASTER_PORT必須爲元數據服務器配置中MATOCS_LISTEN_PORT指定的端口，且IP必須被master允許。
注意開通監控的端口(這裏是9422)

$chown -R mfs:mfs /data   #沒有這一操作，會出現寫權限問題，因進程是用mfs運行的。
$vi /usr/local/mfs/etc/mfshdd.cfg  /data

注意：

在這裏/data 是一個給mfs 的分區，但在本機上是一個獨立的目錄，最好是一個單獨的硬盤或者一個raid 卷，最低要求是一個分區。
不要忘了更改目錄的權限，因爲mfschunkserver進程是用mfs運行的。

3.2.3 操作

/usr/local/mfs/sbin/mfschunkserver [-vdu] [-t locktimeout] [-c cfgfile] [start|stop|restart|reload]  #chunkserver操作命令

3.3 MetaLogger Server

在192.168.0.2上執行如下操作：

3.3.1 安裝：

同Master的安裝步驟。

3.3.2 配置：

$vi /usr/local/mfs/etc/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 = 24 元數據備份文件下載請求頻率。默認爲24小時，即每隔一天從元數據服務器(MASTER)下載一個metadata.mfs.back 文件。當元數據服務器關閉或者出故障時，matedata.mfs.back 文件將消失，那麼要恢復整個mfs,則需從metalogger 服務器取得該文件。請特別注意這個文件，它與日誌文件一起，才能夠恢復整個被損壞的分佈式文件系統。# MASTER_RECONNECTION_DELAY = 5
MASTER_HOST = 192.168.0.1
# MASTER_PORT = 9419# MASTER_TIMEOUT = 60# deprecated, to be removed in MooseFS 1.7# LOCK_FILE = /var/run/mfs/mfsmetalogger.lock

注意：

MASTER_HOST 不能爲localhost或127.0.0.1，做單機測試的童鞋們注意了，要使用對外IP。
MASTER_PORT必須爲元數據服務器配置中MATOCS_LISTEN_PORT指定的端口，且IP必須被master允許。

3.3.3 操作

/usr/local/mfs/sbin/mfsmetalogger [-vdu] [-t locktimeout] [-c cfgfile] [start|stop|restart|reload]  #chunkserver操作命令

3.4 MFS Client

在192.168.0.6上執行如下操作：

3.4.1 FUSE安裝：

$wget http://nchc.dl.sourceforge.net/project/buluoos/0.2/src/fuse-2.8.5.tar.gz$tar zxf fuse-2.8.5.tar.gz$cd fuse-2.8.5
$./configure$make && make install$echo 'export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:$PKG_CONFIG_PATH' >>/etc/profile$source /etc/profile
$lsmod |grep fuse #檢查fuse是否加載到內核，若沒有，執行下面命令
$modprobe fuse&&lsmod |grep fuse  #若將下列mfsmount掛載操作加入開機自啓動，一定將modprobe fuse也加入開機自啓

注意：

一定要將fuse環境變量配置ok，否則安裝mfsmount會裝不上
若將下列mfsmount掛載操作加入開機自啓動，一定將modprobe fuse也加入開機自啓，且在其執行之前執行。

3.4.2 MFSMount安裝：

$useradd mfs -s /sbin/nologin$wget http://www.moosefs.org/tl_files/mfscode/mfs-1.6.20-2.tar.gz$tar zxvf mfs-1.6.20-2.tar.gz$cd mfs-1.6.20-2/
$./configure --prefix=/usr/local/mfs --with-default-user=mfs --with-default-group=mfs --disable-mfsmaster --disable-mfschunkserver$make;make install

3.4.3 掛載MFS

$mkdir /mnt/mfs /mnt/mfsmeta #創建掛載點$/usr/local/mfs/bin/mfsmount /mnt/mfs -H 192.168.0.1
$/usr/local/mfs/bin/mfsmount -m /mnt/mfsmeta -H 192.168.0.1
$df -h #檢查是否掛載成功
$umount /mnt/mfs #操作如下出錯，說明客戶端本機有正在使用此文件系統，可以查明是什麼命令正在使用，然後推出就可以了，最好不要強制退出。

到此爲止，我們的MFS集羣已經搭建完成。

四、MFS的高級特性

4.1 冗餘goal設置

目標（goal），是指文件被拷貝的份數，設定了拷貝的份數後是可以通過mfsgetgoal 命令來證實的，也可以通過mfsrsetgoal 來改變設定。

$/usr/local/mfs/bin/mfssetgoal 3 /mnt/mfs/test1$/usr/local/mfs/bin/mfsgetgoal /mnt/mfs/test1 /mnt/mfs/test1: 3

用mfsgetgoal–r 和mfssetgoal–r 同樣的操作可以對整個樹形目錄遞歸操作，其等效於mfsrsetgoal命令。實際的拷貝份數可以通過mfscheckfile 和mfsfile info 命令來證實。

注意以下幾種特殊情況：

一個不包含數據的零長度的文件,儘管沒有設置爲非零的目標（the non-zero "goal"）,但用mfscheckfile 命令查詢將返回一個空的結果；將文件填充內容後，其會根據設置的goal創建副本；這時再將文件清空，其副本依然作爲空文件存在。
假如改變一個已經存在的文件的拷貝個數，那麼文件的拷貝份數將會被擴大或者被刪除，這個過程會有延時。可以通過mfscheckfile 命令來證實。
對一個目錄設定“目標”，此目錄下的新創建文件和子目錄均會繼承此目錄的設定，但不會改變已經存在的文件及目錄的拷貝份數。

可以通過mfsdirinfo來查看整個目錄樹的信息摘要。

4.2 垃圾回收站

一個刪除文件能夠存放在一個“ 垃圾箱”的時間就是一個隔離時間，這個時間可以用mfsgettrashtime 命令來驗證，也可以用mfssettrashtime命令來設置。如：

$/usr/local/mfs/bin/mfssettrashtime 64800 /mnt/mfs/test1$/usr/local/mfs/bin/mfsgettrashtime /mnt/mfs/test1 /mnt/mfs/test1: 64800

時間的單位是秒(有用的值有:1 小時是3600 秒,24 - 86400 秒,1天 - 604800 秒)。就像文件被存儲的份數一樣, 爲一個目錄設定存放時間是要被新創建的文件和目錄所繼承的。數字0 意味着一個文件被刪除後, 將立即被徹底刪除，在想回收是不可能的。

刪除文件可以通過一個單獨安裝MFSMETA 文件系統。特別是它包含目錄/ trash (包含任然可以被還原的被刪除文件的信息)和/ trash/undel (用於獲取文件)。只有管理員有權限訪問MFSMETA(用戶的uid 0，通常是root)。

$/usr/local/mfs/bin/mfsmount -m /mnt/mfsmeta -H 192.168.0.1

被刪文件的文件名在“垃圾箱”目錄裏還可見,文件名由一個八位十六進制的數i-node 和被刪文件的文件名組成，在文件名和i-node 之間不是用“/”,而是用了“|”替代。如果一個文件名的長度超過操作系統的限制（通常是255 個字符），那麼部分將被刪除。通過從掛載點起全路徑的文件名被刪除的文件任然可以被讀寫。

移動這個文件到trash/undel 子目錄下，將會使原始的文件恢復到正確的MooseFS 文件系統上路徑下（如果路徑沒有改變）。如果在同一路徑下有個新的同名文件，那麼恢復不會成功。

從“垃圾箱”中刪除文件結果是釋放之前被它站用的空間(刪除有延遲,數據被異步刪除)。

在MFSMETA中還有另一個目錄reserved，該目錄內的是被刪除但依然打開的文件。在用戶關閉了這些被打開的文件後，reserved 目錄中的文件將被刪除，文件的數據也將被立即刪除。在reserved 目錄中文件的命名方法同trash 目錄中的一樣，但是不能有其他功能的操作。

4.3 快照snapshot

MooseFS 系統的另一個特徵是利用mfsmakesnapshot 工具給文件或者是目錄樹做快照。

$/usr/local/mfs/bin/mfsmakesnapshot source ... destination

Mfsmakesnapshot 是在一次執行中整合了一個或是一組文件的拷貝，而且任何修改這些文件的源文件都不會影響到源文件的快照，就是說任何對源文件的操作,例如寫入源文件，將不會修改副本(或反之亦然)。

也可以使用mfsappendchunks：

$/usr/local/mfs/bin/mfsappendchunks destination-file source-file ...

當有多個源文件時，它們的快照被加入到同一個目標文件中（每個chunk 的最大量是chunk）。

五、MFS的性能測試

下面是網上得到的一童鞋的簡單測試數據，直接拿過來了。

寫：time dd if=/dev/zero of=/mnt/mfs/test2/test500M bs=1024k count=500讀：time dd if=/mnt/mfs/test2/test500M of=/dev/null

	1copy寫	2copy寫	1copy讀	2copy讀
1M	0m0.042s	0m0.042s	0m0.017s	0m0.017s
5M	0m0.073s	0m0.079s	0m0.070s	0m0.071s
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
10G	9m29.037s	19m26.237s	3m55.222s	3m24.914s

讀速度：ca 71M/s 寫速度：ca 22M/s 9M/s （以500M計算）
goal的設置和讀寫速度的關係？貌似沒有太大關係。

另一份比較詳細的測試數據，就不粘出來了，直接把結果拿過來：

單盤多進程性能沒有提升，因爲都在io wait，甚至增加進程會消耗大量調度時間
MFS多進程時性能會提升，主要性能消耗集中在CPU系統時間。因此實際海量小文件性能要大大強於本地文件系統

六、MFS集羣的維護

6.1 啓動MFS集羣

最安全的啓動MooseFS 集羣（避免任何讀或寫的錯誤數據或類似的問題）的方式是按照以下命令步驟：

啓動mfsmaster 進程
啓動所有的mfschunkserver 進程
啓動mfsmetalogger 進程（如果配置了mfsmetalogger）
當所有的chunkservers 連接到MooseFS master 後，任何數目的客戶端可以利用mfsmount 去掛接被export 的文件系統。（可以通過檢查master 的日誌或是CGI 監視器來查看是否所有的chunkserver被連接）。

6.2 停止MFS集羣

安全的停止MooseFS 集羣：

在所有的客戶端卸載MooseFS 文件系統（用umount 命令或者是其它等效的命令）
用mfschunkserver stop 命令停止chunkserver 進程
用mfsmetalogger stop 命令停止metalogger 進程
用mfsmaster stop 命令停止master 進程

6.3 MFS chunkservers 的維護

若每個文件的goal（目標）都不小於2，並且沒有under-goal 文件（這些可以用mfsgetgoal –r和mfsdirinfo 命令來檢查），那麼一個單一的chunkserver 在任何時刻都可能做停止或者是重新啓動。以後每當需要做停止或者是重新啓動另一個chunkserver 的時候，要確定之前的chunkserver 被連接，而且要沒有under-goal chunks。

6.4 MFS元數據備份

通常元數據有兩部分的數據：

主要元數據文件metadata.mfs，當mfsmaster 運行的時候會被命名爲metadata.mfs.back
元數據改變日誌changelog.*.mfs，存儲了過去的N 小時的文件改變（N 的數值是由BACK_LOGS參數設置的，參數的設置在mfschunkserver.cfg 配置文件中）。

主要的元數據文件需要定期備份，備份的頻率取決於取決於多少小時changelogs 儲存。元數據changelogs 實時的自動複製。1.6版本中這個工作都由metalogger完成。

6.5 MFS Master的恢復

一旦mfsmaster 崩潰（例如因爲主機或電源失敗），需要最後一個元數據日誌changelog 併入主要的metadata 中。這個操作時通過mfsmetarestore 工具做的，最簡單的方法是：

$/usr/local/mfs/bin/mfsmetarestore -a

如果master 數據被存儲在MooseFS 編譯指定地點外的路徑，則要利用-d 參數指定使用，如：

$/usr/local/mfs/bin/mfsmetarestore -a -d /opt/mfsmaster

6.6 從MetaLogger中恢復Master

有些童鞋提到：如果mfsmetarestore -a無法修復，則使用metalogger也可能無法修復，暫時沒遇到過這種情況，這裏不暫不考慮。

找回metadata.mfs.back 文件，可以從備份中找，也可以中metalogger 主機中找（如果啓動了metalogger 服務），然後把metadata.mfs.back 放入data 目錄，一般爲{prefix}/var/mfs
從在master 宕掉之前的任何運行metalogger 服務的服務器上拷貝最後metadata 文件，然後放入mfsmaster 的數據目錄。
利用mfsmetarestore 命令合併元數據changelogs，可以用自動恢復模式mfsmetarestore –a，也可以利用非自動化恢復模式

$mfsmetarestore -m metadata.mfs.back -o metadata.mfs changelog_ml.*.mfs

或：

強制使用metadata.mfs.back創建metadata.mfs，可以啓動master，但丟失的數據暫無法確定。

七、MFS的常見問題和建議對策

7.1 Master性能瓶頸

master本身的性能瓶頸。
短期對策：按業務切分

7.2 體系架構存儲文件總數的瓶頸

mfs把文件系統的結構緩存到master的內存中，個人認爲文件越多，master的內存消耗越大，8g對應2500kw的文件數，2億文件就得64GB內存。
短期對策：按業務切分

7.3 單點故障解決方案的健壯性

7.4 垃圾回收

默認的垃圾回收時間是86400，存在一種可能性是垃圾還沒回收完，你的存儲容量就暴掉了。
方案一：設置垃圾回收時間，積極監控存儲容量。
經過測試，把垃圾回收時間設置300秒，完全可以正確回收容量。
方案二：手動週期性去刪除metamfs裏的trash目錄下的文件（健壯性還有待測試，反正刪除後容量是回收了，不曉得有沒有什麼後遺症。）

7.5 理想的平均寫和讀的速度是多少？

原始的讀/寫速度很明顯是主要取決於所使用的硬盤的性能、網絡的容量和拓撲結構的，使用的硬盤和網絡的吞吐量越好，整個系統的性能也就會越好。官方的測試環境中，將MFS安裝在linux（Debian）上設置存儲的份數爲2，一般的測試服務器（還做了其他較大量的計算），G太網絡，使用Pbyte級別的數據，測試的結果爲寫的速度大約在20-30MB/s，讀的速度爲30-50MB/s。對於小文件寫的速度有些下降，但是對於讀的速度是沒有影響的。

7.6 設置文件存儲的份數是否影響寫/讀的速度？

一般來說，它是有影響的。在一定條件下，存儲份數的設置會影響的讀取的速度。例如，當文件設置存儲兩份而不是一份時能加快對同一文件有多個客戶端讀取的速度。但是在真實的環境中，多個機器同時讀取同一個文件的機率是比較小的，因此，存儲份數的設置對讀取的速度影響是比較小的。

同樣，設置存儲份數對寫的速度影響也是不太大的。(只有文件超過64M的時候)

MFS調研

一、MFS概述、特性和新版改進

二、MFS 工作原理和設計架構

MFS的讀數據過程

MFS的寫數據過程

MFS的刪除文件過程

MFS修改文件內容的過程

MFS重命名文件的過程

MFS遍歷文件的過程

三、MFS的安裝、部署、配置

3.1 Master Server

3.1.1 安裝:

3.1.2 配置：

3.1.3 操作：

3.1.4 備註：

3.2 Chunk Server

3.2.1 安裝：

3.2.2 配置：

3.2.3 操作

3.3 MetaLogger Server

3.3.1 安裝：

3.3.2 配置：

3.3.3 操作

3.4 MFS Client

3.4.1 FUSE安裝：

3.4.2 MFSMount安裝：

3.4.3 掛載MFS

四、MFS的高級特性

4.1 冗餘goal設置

4.2 垃圾回收站

4.3 快照snapshot

五、MFS的性能測試

六、MFS集羣的維護

6.1 啓動MFS集羣

6.2 停止MFS集羣

6.3 MFS chunkservers 的維護

6.4 MFS元數據備份

6.5 MFS Master的恢復

6.6 從MetaLogger中恢復Master

七、MFS的常見問題和建議對策

7.1 Master性能瓶頸

7.2 體系架構存儲文件總數的瓶頸

7.3 單點故障解決方案的健壯性

7.4 垃圾回收

7.5 理想的平均寫和讀的速度是多少？

7.6 設置文件存儲的份數是否影響寫/讀的速度？