Centos下MooseFS（MFS）分佈式存儲共享環境部署記錄
分佈式文件系統（Distributed File System）是指文件系統管理的物理存儲資源不必定直接鏈接在本地節點上，而是經過計算機網絡與節點相連，分佈式文件系統的實際基於客戶機/服務器模式。目前常見的分佈式文件系統有不少種，好比Hadoop、Moosefs、HDFS、FastDFS、PNFS(Parallel NFS）、Lustre、TFS、GFS等等一系列。在衆多的分佈式文件系統解決方案中，MFS是搭建比較簡單、使用起來也不須要過多的修改web程序，很是方便。前端
1、MooseFS是什麼node
MooseFS(即Moose File System，簡稱MFS)是一個具備容錯性的網絡分佈式文件系統，它將數據分散存放在多個物理服務器或單獨磁盤或分區上，確保一份數據 有多個備份副本，對於訪問MFS的客戶端或者用戶來講，整個分佈式網絡文件系統集羣看起來就像一個資源同樣，也就是說呈現給用戶的是一個統一的資源。 MooseFS就至關於UNIX的文件系統（相似ext三、ext四、nfs），它是一個分層的目錄樹結構。 MFS存儲支持POSIX標準的文件屬性（權限，最後訪問和修改時間），支持特殊的文件，如塊設備，字符設備，管道、套接字、連接文件（符合連接、硬連接）； MFS支持FUSE(用戶空間文件系統Filesystem in Userspace，簡稱FUSE），客戶端掛載後能夠做爲一個普通的Unix文件系統使用MooseFS。 MFS可支持文件自動備份的功能，提升可用性和高擴展性。MogileFS不支持對一個文件內部的隨機或順序讀寫，所以只適合作一部分應用，如圖片服務，靜態HTML服務、 文件服務器等，這些應用在文件寫入後基本上不須要對文件進行修改，可是能夠生成一個新的文件覆蓋原有文件。
2、MooseFS的特性python
1）高可靠性，每一份數據能夠設置多個備份（多分數據），並能夠存儲在不一樣的主機上 2）高可擴展性，能夠很輕鬆的經過增長主機的磁盤容量或增長主機數量來動態擴展整個文件系統的存儲量 3）高可容錯性，能夠經過對mfs進行系統設置，實現當數據文件被刪除後的一段時間內，依舊存放於主機的回收站中，以備誤刪除恢復數據 4）高數據一致性，即便文件被寫入、訪問時，依然能夠輕鬆完成對文件的一致性快照 5）通用文件系統，不須要修改上層應用就可使用（那些須要專門api的dfs很麻煩！）。 6）能夠在線擴容，體系架構可伸縮性極強。（官方的case能夠擴到70臺了！） 7）部署簡單。（sa們特別高興，領導們特別happy！） 8）可回收在指定時間內刪除的文件，便可以設置刪除文件的空間回收時間（"回收站"提供的是系統級別的服務，不怕誤操做了，提供相似oralce 的閃回等 高級dbms的即時回滾特性！）,命令"mfsgettrashtime filename" 9)提供web gui監控接口。 10)提升隨機讀或寫的效率（有待進一步證實）。 11)提升海量小文件的讀寫效率（有待進一步證實）
3、MooseFS的優勢mysql
1）部署簡單，輕量、易配置、易維護 2）易於擴展，支持在線擴容，不影響業務，體系架構可伸縮性極強（官方的case能夠擴到70臺） 3）通用文件系統，不須要修改上層應用就可使用（比那些須要專門api的dfs方便多了）。 4）以文件系統方式展現:如存圖片，雖然存儲在chunkserver上的數據是二進制文件，可是在掛載mfs的client端仍舊以圖片文件形式展現，便於數據備份 5）硬盤利用率高。測試須要較大磁盤空間 6）可設置刪除的空間回收時間，避免誤刪除文件丟失就恢復不及時影響業務 7）系統負載，即數據讀寫分配到全部的服務器上 8）可設置文件備份的副本數量，通常建議3份，將來硬盤容量也要是存儲單份的容量的三倍
4、MooseFS的缺點linux
1）master目前是單點（雖然會把數據信息同步到備份服務器，可是恢復須要時間，所以，會影響上線，針對這個問題， 能夠經過DRBD+Keeaplived方案或者DRBD+Inotify方案解決），master和backup之間的同步，相似mysql的主從不一樣。 2）master服務器對主機的內存要求略高 3）默認metalogger複製元數據時間較長（可調整）
5、MooseFS文件系統架構組成及原理c++
MFS架構圖web
MFS文件的讀寫流程圖算法
---------------------------------------------------------MFS讀寫處理過程--------------------------------------------------------
1、MFS讀取數據步驟：
1）客戶端向元數據服務器發出請求
2）元數據服務器把所需數據存放的位置(Chunk Server 的IP地址及Chunk編號）告知客戶端
3）客戶端向已知Chunk Server請求發送數據
4）客戶端取得所需數據
數據傳輸並不經過元數據服務器，這既減輕了元數據服務器的壓力，同時也大大增長了
整個系統的吞吐能力，在多個客戶端讀取數據時，讀取點(Chunk Server)有可能被分散到不一樣
的服務器
2、MFS寫入數據步驟：
1）客戶端向元數據服務器發送寫入請求
2）元數據服務器與Chunk Server進行交互以下：
1）元數據服務器指示在某些Chunk Server建立分塊Chunks
2）Chunk Server告知元數據服務器，步驟(1)的操做成功
3）元數據服務器告知客戶端，你能夠在哪一個Chunk Server的哪一個Chunks寫入數據
4）向指定的Chunk Server寫入數據
5）與其餘Chunk Server進行數據同步，同步的服務器依據設定的副本數而定，副本爲2，則需同步一個ChunkServer
6）Chunk Sever之間同步成功
7）Chunk Server告知客戶端數據寫入成功
8）客戶端告知元數據服務器本次寫入完畢
3、MFS的刪除文件過程
1）客戶端有刪除操做時，首先向Master發送刪除信息；
2）Master定位到相應元數據信息進行刪除，並將chunk server上塊的刪除操做加入隊列異步清理；
3）響應客戶端刪除成功的信號
4、MFS修改文件內容的過程
1）客戶端有修改文件內容時，首先向Master發送操做信息；
2）Master申請新的塊給.swp文件，
3）客戶端關閉文件後，會向Master發送關閉信息；
4）Master會檢測內容是否有更新，如有，則申請新的塊存放更改後的文件，刪除原有塊和.swp文件塊；
5）若無，則直接刪除.swp文件塊。
5、MFS重命名文件的過程
1）客戶端重命名文件時，會向Master發送操做信息；
2）Master直接修改元數據信息中的文件名；返回重命名完成信息；
6、MFS遍歷文件的過程
1）遍歷文件不須要訪問chunk server，當有客戶端遍歷請求時，向Master發送操做信息；
2）Master返回相應元數據信息；
3—— 客戶端接收到信息後顯示
須要注意：
1）Master記錄着管理信息，好比：文件路徑|大小|存儲的位置(ip,port,chunkid)|份數|時間等，元數據信息存在於內存中，會按期寫入metadata.mfs.back文件中，
按期同步到metalogger，操做實時寫入changelog.*.mfs，實時同步到metalogger中。master啓動將metadata.mfs載入內存，重命名爲metadata.mfs.back文件。
2）文件以chunk大小存儲，每chunk最大爲64M，小於64M的，該chunk的大小即爲該文件大小（驗證明際chunk文件略大於實際文件），超過64M的文件將被切分，以每一
份（chunk）的大小不超過64M爲原則；塊的生成遵循規則：目錄循環寫入(00-FF 256個目錄循環，step爲2)、chunk文件遞增生成、大文件切分目錄連續。
3）Chunkserver上的剩餘存儲空間要大於1GB（Reference Guide有提到），新的數據纔會被容許寫入，不然，你會看到No space left on device的提示，實際中，
測試發現當磁盤使用率達到95%左右的時候，就已經不行寫入了，當時可用空間爲1.9GB。
4）文件能夠有多份copy，當goal爲1時，文件會被隨機存到一臺chunkserver上，當goal的數大於1時，copy會由master調度保存到不一樣的chunkserver上，goal的大小
不要超過chunkserver的數量，不然多出的copy，不會有chunkserver去存。
MFS組件sql
1）管理服務器managing server簡稱（master）： 這個組件的角色是管理整個mfs文件系統的主服務器，除了分發用戶請求外，還用來存儲整個文件系統中每一個數據文件的metadata信息，metadate（元數據）信息包括 文件（也能夠是目錄，socket，管道，塊設備等）的大小，屬性，文件的位置路徑等，很相似lvs負載均衡的主服務器，不一樣的是lvs僅僅根據算法分發請求，而master 根據內存裏的metadata信息來分發請求，內存的信息會被實時寫入到磁盤，這個master只能由一臺處於激活的狀態 2）元數據備份服務器Metadata backup servers（簡稱metalogger或backup）： 這個組件的做用是備份管理服務器master的變化的metadata信息日誌文件，文件類型爲changelog_ml.*.mfs。以便於在管理服務器出問題時，能夠通過簡單的操做便可 讓新的主服務器進行工做。這相似mysql主從同步，只不過它不像mysql從庫那樣在本地應用數據，而只是接受主服務器上文寫入時記錄的文件相關的metadata信息，這 個backup，能夠有一臺或多臺，它很相似lvs從負載均衡服務器 3）數據存儲服務器組data servers（chunk servers）簡稱data： 這個組件就是真正存放數據文件實體的服務器了，這個角色能夠有多臺不一樣的物理服務器或不一樣的磁盤及分區來充當，當配置數據的副本多於一份時，據寫入到一個數 據服務器後，會根據算法在其餘數據服務器上進行同步備份。這有點相似lvs集羣的RS節點 4）客戶機服務器組（client servers）簡稱client： 這個組件就是掛載並使用mfs文件系統的客戶端，當讀寫文件時，客戶端首先會鏈接主管理服務器獲取數據的metadata信息，而後根據獲得的metadata信息，訪問數據服 務器讀取或寫入文件實體，mfs客戶端經過fuse mechanism實現掛載mfs文件系統的，所以，只有系統支持fuse，就能夠做爲客戶端訪問mfs整個文件系統，所謂的客戶端 並非網站的用戶，而是前端訪問文件系統的應用服務器，如web -------------------MFS 文件系統結構包含4種角色---------------------- 1）管理服務器 Master Server（Master） 2）元數據日誌服務器 Metalogger Server(Metalogger) 3）數據存儲服務器 Data Servers (Chunkservers) 4）客戶端 Client ---------------MFS的4種角色做用以下--------------- 1）Master管理服務器 有時也稱爲元數據服務器，負責管理各個數據存儲服務器，調度文件讀寫，回收文件空間以及恢復多節點拷貝。目前MFS只支持一個元數據服務器master，這是一個單點故障， 須要一個性能穩定的服務器來充當。但願從此MFS能支持多個master服務器，進一步提升系統的可靠性。 2）Metalogger元數據日誌服務器 負責備份管理服務器的變化日誌文件，文件類型爲changelog_ml.*.mfs，以便於在管理服務器出問題時接替其進行工做。元數據日誌服務器是mfsl.6之後版本新增的服務， 能夠把元數據日誌保留在管理服務器中，也能夠單獨存儲在一臺服務器中。爲保證數據的安全性和可靠性，建議單獨用一臺服務器來存放元 數據日誌。須要注意的是，元 數據日誌守護進程跟管理服務器在同一個服務器上，備份元數據日誌服務器做爲它的客戶端，從管理服務器取得日誌文件進行備份。 3）Chunkserver數據存儲服務器(推薦至少兩臺chunkserver) 數據存儲服務器是真正存儲用戶數據的服務器，負責鏈接管理服務器,遵從管理服務器調度,提供存儲空間，併爲客戶提供數據傳輸。在存儲文件時，首先把文件分紅塊， 而後將這些塊在數據存儲服務器之間互相複製（複製份數手工指定，建議設置副本數爲3），數據服務器能夠是多個，而且數量越多，可以使用的"磁盤空間"越小，可靠性也越高。 同時，數據存儲服務器還負責鏈接管理服務器，遵從管理服務器調度，併爲客戶提供數據傳輸。數據存儲服務器能夠有多個，而且數量越多，可靠性越高，MFS可用的磁盤空間也越大。 4）Client客戶端 經過fuse內核接口掛接遠程管理服務器上所管理的數據存儲服務器，使共享的文件系統和使用本地Linux文件系統的效果看起來是同樣的。 ----------------MFS內部運行機制------------------- 1）客戶端請求訪問存儲，請求發送到了MFS Master 2）MFS Master根據客戶訪問的請求，查詢所須要的文件分佈在那些服務器上 3）客戶端直接和存儲服務器進行數據存儲和讀寫 ---------------MFS的應用場景--------------- 1）大規模高併發的線上數據存儲及訪問（小文件，大文件都適合） 2）大規模的數據處理，如日誌分析，小文件強調性能不用HDFS。 有大多的應用不適合分佈式文件系統，不建議你們爲了使用而使用。儘可能在前端加cache應用，而不是一味的 擴充文件系統
6、爲何要使用MFSvim
因爲用戶數量的不斷攀升,對訪問量大的應用實現了可擴展、高可靠的集羣部署（即lvs+keepalived的方式），但仍然有用戶反饋訪問慢的問題。經過排查個服務器的狀況， 發現問題的根源在於共享存儲服務器NFS。在我這個網絡環境裏，N個服務器經過NFS方式共享一個服務器的存儲空間，使得NFS服務器不堪重負。察看系統日誌，全是NFS服 務超時之類的報錯。通常狀況下，當NFS客戶端數目較小的時候，NFS性能不會出現問題；一旦NFS服務器數目過多，而且是那種讀寫都比較頻繁的操做，所獲得的結果就不 是咱們所期待的。
NFS缺陷（以下在web集羣中使用NFS共享文件）
NFS雖然使用簡單，但當NFS客戶端訪問量大時，經過NFS方式共享一個服務器的存儲空間，使得NFS服務器不堪重負，而且執行讀寫都比較頻繁的操做會出現 意外的錯誤，對於高可靠的集羣部署是有挑戰的。這種架構除了性能問題而外，還存在單點故障，一旦這個NFS服務器發生故障，全部靠共享提供數據的應用 就再也不可用，儘管用rsync方式同步數據到另一個服務器上作NFS服務的備份，但這對提升整個系統的性能毫無幫助。基於這樣一種需求，咱們須要對NFS服 務器進行優化或採起別的解決方案，然而優化並不能對應對日益增多的客戶端的性能要求，所以惟一的選擇只能是採起別的解決方案了； 經過調研，分佈式文件系統是一個比較合適的選擇。採用分佈式文件系統後，服務器之間的數據訪問再也不是一對多的關係（1個NFS服務器，多個NFS客戶端）， 而是多對多的關係，這樣一來，性能大幅提高毫無問題。 選擇MFS分佈式文件系統來做爲共享存儲服務器，主要考慮以下： 1）實施起來簡單。MFS的安裝、部署、配置相對於其餘幾種工具來講，要簡單和容易得多。看看lustre 700多頁的pdf文檔，讓人頭昏吧。 2）不停服務擴容。MFS框架作好後，隨時增長服務器擴充容量；擴充和減小容量皆不會影響現有的服務。注：hadoop也實現了這個功能。 3）恢復服務容易。除了MFS自己具有高可用特性外，手動恢復服務也是很是快捷的
MFS分佈式文件系統環境部署記錄
1）master-server元數據服務器上的操做記錄
1）綁定host，關閉防火牆
[root@master-server ~]# vim /etc/hosts
182.48.115.233 master-server
182.48.115.235 metalogger
182.48.115.236 chunkServer1
182.48.115.237 chunkServer1
最好是關閉防火牆（selinux也要關閉，執行setenforce 0）
[root@master-server ~]# /etc/init.d/iptables stop
2）建立mfs用戶和組
[root@master-server ~]# useradd mfs -s /sbin/nologin
3）編譯安裝mfs
百度下載地址：https://pan.baidu.com/s/1slS7JK5 （提取密碼：park）
[root@master-server ~]# wget https://fossies.org/linux/misc/legacy/moosefs-3.0.91-1.tar.gz
[root@master-server ~]# tar -zvxf moosefs-3.0.91-1.tar.gz
[root@master-server ~]# cd moosefs-3.0.91
[root@master-server moosefs-3.0.91]# ./configure --prefix=/usr/local/mfs --with-default-user=mfs --with-default-group=mfs
[root@master-server moosefs-3.0.91]# make && make install
[root@master-server moosefs-3.0.91]# cd /usr/local/mfs/etc/mfs
[root@master-server mfs]# ls
mfschunkserver.cfg.sample mfshdd.cfg.sample mfsmetalogger.cfg.sample mfstopology.cfg.sample
mfsexports.cfg.sample mfsmaster.cfg.sample mfsmount.cfg.sample
4）master服務器須要如下文件：
mfsmaster.cfg 主文件
mfsexports.cfg mfs掛載權限設置，參考NFS文件系統中的exports.cfg
mfstopology.cfg 機架感知
下面開始修改配置文件
[root@master-server mfs]# cp -a mfsmaster.cfg.sample mfsmaster.cfg
[root@master-server mfs]# cp -a mfstopology.cfg.sample mfstopology.cfg
[root@master-server mfs]# cp -a mfsexports.cfg.sample mfsexports.cfg
[root@master-server mfs]# vim mfsexports.cfg
.......
182.48.115.0/27 / rw,alldirs,maproot=0
* . rw
設置解釋：
第一個設置，表明讓182.48.115.0網段機器能夠掛載mfs的根分區；若是將"/"改成"."符號則表示容許訪問全部
注意這裏機器的netmask是255.255.255.224，因此子網掩碼是27位，若是是255.255.255.0，那麼掩碼就是24位。
第二個設置是容許客戶端掛載使用回收站功能。若是決定了掛載mfsmeta，那麼必定要在mfsmaster的mfsexport.cfg文件中添加這條記錄：
權限說明：
ro 只讀模式
rw 讀寫模式
alldirs 容許掛載任何指定的子目錄
maproot 映射爲root，仍是指定的用戶
[root@master-server mfs]# cd ../../var/mfs/
[root@master-server mfs]# ls
metadata.mfs.empty
[root@master-server mfs]# cp -a metadata.mfs.empty metadata.mfs
[root@master-server mfs]# chown -R mfs:mfs /usr/local/mfs
5）啓動mfsmaster命令：
[root@master-server mfs]# /usr/local/mfs/sbin/mfsmaster start //可使用/usr/local/mfs/sbin/mfsmaster -a 命令進行啓動，這種方式通常可用於修復性啓動。
open files limit has been set to: 16384
working directory: /usr/local/mfs/var/mfs
lockfile created and locked
initializing mfsmaster modules ...
exports file has been loaded
topology file has been loaded
loading metadata ...
metadata file has been loaded
no charts data file - initializing empty charts
master <-> metaloggers module: listen on *:9419
master <-> chunkservers module: listen on *:9420
main master server module: listen on *:9421
mfsmaster daemon initialized properly
[root@master-server mfs]# ps -ef|grep mfs
mfs 31312 1 2 10:58 ? 00:00:00 /usr/local/mfs/sbin/mfsmaster start
root 31314 24958 0 10:58 pts/0 00:00:00 grep mfs
[root@master-server ~]# lsof -i:9420 //防火牆若是開啓了，須要開放9420端口訪問
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
mfsmaster 31312 mfs 9u IPv4 108440 0t0 TCP *:9420 (LISTEN)
-------------------------------------------------------------------------------------
mfsmaster相關啓動命令
# /usr/local/mfs/sbin/mfsmaster start|stop|restart|reload|info|test|kill
將mfsmaster啓動命令軟連接到/etc/init.d下面
[root@master-server mfs]# ln -s /usr/local/mfs/sbin/mfsmaster /etc/init.d/mfsmaster
[root@master-server mfs]# /etc/init.d/mfsmaster statrt/stop/status/reload/restart //還可使用/etc/init.d/mfsmaster -a命令進行啓動
-------------------------------------------------------------------------------------
master管理節點的數據存放在/usr/local/mfs/var/mfs/目錄下
6）啓動和中止Web GUI
[root@master-server mfs]# /usr/local/mfs/sbin/mfscgiserv start
lockfile created and locked
starting simple cgi server (host: any , port: 9425 , rootpath: /usr/local/mfs/share/mfscgi)
[root@master-server mfs]# ps -ef|grep mfscgiserv
root 31352 1 0 11:01 ? 00:00:00 /usr/bin/python /usr/local/mfs/sbin/mfscgiserv
root 31356 24958 0 11:02 pts/0 00:00:00 grep mfscgiserv
[root@master-server mfs]# lsof -i:9425
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
mfscgiser 31352 root 3u IPv4 105260 0t0 TCP *:9425 (LISTEN)
相關啓動命令
[root@master-server mfs]# /usr/local/mfs/sbin/mfscgiserv start/stop/status/restart/reload
訪問Web GUI方式（若是打開了防火牆，防火牆裏開放9245端口訪問），訪問地址是http://182.48.115.233:9425
mfscgiserv 是用python寫的一個監控MFS狀態的web界面，監聽端口是9425，必須在master（管理服務器上）上啓動。 經常使用的參數： -h 幫助信息 -H 綁定的IP，默認爲0.0.0.0 -P 綁定端口號，默認是9425 -R mfscgi的root路徑，默認是/usr/local/mfs/share/mfscgi -f 運行HTTP服務器，-f 表示在前臺運行，-v表示請求的日誌發往標準的錯誤設備 mfscgiserv監控圖有8個部分組成： info 這個部分顯示了MFS的基本信息。 Servers 列出現有的ChunkServer。 Disks 列出每一臺ChunkServer的磁盤目錄以及使用量 Exports 列出共享的目錄，既能夠被掛載的目錄 mounts 顯示被掛載的狀況。 Openrations 顯示正在執行的操做。 Master Charts 顯示Master server的操做狀況，包括讀取，寫入，建立目錄，刪除目錄等消息。 Server Charts 顯示ChunkServer的操做狀況，數據傳輸率以及系統狀態等信息。
訪問的時候,出現上面界面，提示找不到master主機。莫慌！在DNS解析欄裏輸入master管理節點的主機名便可
2）chunkServer數據儲存節點上的操做記錄（在chunkServer1和chunkServer2上都要操做）
1）關閉防火牆（selinux也要關閉，執行setenforce 0） [root@chunkServer1 ~]# /etc/init.d/iptables stop 2）建立mfs用戶和組 [root@chunkServer1 ~]# useradd mfs -s /sbin/nologin 3）編譯安裝mfs（下載地址在上面已經提到） [root@chunkServer1 ~]# yum install -y gcc c++ zlib-devel [root@chunkServer1 ~]# tar -zxvf moosefs-3.0.91-1.tar.gz [root@chunkServer1 ~]# cd moosefs-3.0.91 [root@chunkServer1 moosefs-3.0.91]# ./configure --prefix=/usr/local/mfs --with-default-user=mfs --with-default-group=mfs [root@chunkServer1 moosefs-3.0.91]# make && make install [root@chunkServer1 moosefs-3.0.91]# cd /usr/local/mfs/etc/mfs/ [root@chunkServer1 mfs]# ls mfschunkserver.cfg.sample mfsexports.cfg.sample mfshdd.cfg.sample mfsmaster.cfg.sample mfsmetalogger.cfg.sample mfstopology.cfg.sample 4）chunkserver配置文件以下： mfschunkserver.cfg 這個是mfschunkserver配置文件 mfshdd.cfg 這個是mfschunkserver上的分區，必須是獨立分區！ [root@chunkServer1 mfs]# cp mfschunkserver.cfg.sample mfschunkserver.cfg [root@chunkServer1 mfs]# vim mfschunkserver.cfg ....... MASTER_HOST = 182.48.115.233 //這個填寫master管理節點的ip或主機名 MASTER_PORT = 9420 [root@chunkServer1 mfs]# cp mfshdd.cfg.sample mfshdd.cfg [root@chunkServer1 mfs]# vim mfshdd.cfg //在文件尾行添加下面兩行內容 ....... # mount points of HDD drives /usr/local/mfsdata //因爲mfschunkserver上的分區須要是獨立分區！因此這裏最好配置成獨立分區。好比/data （df -h命令查看，/data要是獨立分區） [root@chunkServer1 mfs]# mkdir /usr/local/mfsdata //這個是數據的真實存放目錄。裏面存放的是數據的chunks塊文件 [root@chunkServer1 mfs]# chown -R mfs:mfs /usr/local/mfsdata/ [root@chunkServer1 mfs]# cd ../../var/mfs/ [root@chunkServer1 mfs]# ls metadata.mfs.empty [root@chunkServer1 mfs]# cp metadata.mfs.empty metadata.mfs [root@chunkServer1 mfs]# chown -R mfs:mfs /usr/local/mfs 5）啓動chunkserver [root@chunkServer1 mfs]# ln -s /usr/local/mfs/sbin/mfschunkserver /etc/init.d/mfschunkserver [root@chunkServer1 mfs]# /etc/init.d/mfschunkserver start open files limit has been set to: 16384 working directory: /usr/local/mfs/var/mfs lockfile created and locked setting glibc malloc arena max to 4 setting glibc malloc arena test to 4 initializing mfschunkserver modules ... hdd space manager: path to scan: /usr/local/mfsdata/ hdd space manager: start background hdd scanning (searching for available chunks) main server module: listen on *:9422 no charts data file - initializing empty charts mfschunkserver daemon initialized properly [root@chunkServer1 mfs]# ps -ef|grep mfs mfs 13843 1 1 13:30 ? 00:00:00 /etc/init.d/mfschunkserver start root 13853 4768 0 13:31 pts/0 00:00:00 grep mfs [root@chunkServer1 mfs]# lsof -i:9422 #防火牆開啓這個端口的訪問 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME mfschunks 13843 mfs 11u IPv4 54792 0t0 TCP *:9422 (LISTEN) 其餘相關命令 [root@chunkServer1 mfs]# /etc/init.d/mfschunkserver start/stop/restart/status/reload
3）metalogger元數據日誌服務器操做記錄
1）關閉防火牆（selinux也要關閉） [root@metalogger ~]# setenforce 0 [root@metalogger ~]# /etc/init.d/iptables stop 2）建立mfs用戶和組 [root@metalogger ~]# useradd mfs -s /sbin/nologin 3）編譯安裝mfs [root@metalogger ~]# yum install -y gcc c++ zlib-devel [root@metalogger ~]# tar -zvxf moosefs-3.0.91-1.tar.gz [root@metalogger ~]# cd moosefs-3.0.91 [root@metalogger moosefs-3.0.91]# ./configure --prefix=/usr/local/mfs --with-default-user=mfs --with-default-group=mfs [root@metalogger moosefs-3.0.91]# make && make install 4）mfsmetalogger.cfg文件配置 [root@metalogger moosefs-3.0.91]# cd /usr/local/mfs/etc/mfs/ [root@metalogger mfs]# ls mfschunkserver.cfg.sample mfsexports.cfg.sample mfshdd.cfg.sample mfsmaster.cfg.sample mfsmetalogger.cfg.sample mfstopology.cfg.sample [root@metalogger mfs]# cp mfsmetalogger.cfg.sample mfsmetalogger.cfg [root@metalogger mfs]# vim mfsmetalogger.cfg ...... META_DOWNLOAD_FREQ = 1 MASTER_HOST = 182.48.115.233 #若是是單機環境的話，這個不能爲localhost或127.0.0.1，要使用對外IP MASTER_PORT = 9419 參數解釋： META_DOWNLOAD_FREQ 表示源數據備份下載請求頻率，這裏設置爲1小時。默認爲24小時，即每隔一天從元數據服務器(MASTER)下載一個metadata.mfs.back 文件。 當元數據服務器關閉或者出故障時，matedata.mfs.back 文件將消失，那麼要恢復整個mfs,則需從metalogger 服務器取得該文件。請特別注意這個文件，它與日誌 文件（即changelog_ml.0.mfs文件）一塊兒，纔可以恢復整個被損壞的分佈式文件系統。元數據日誌服務器的備份數據存放目錄是/usr/local/mfs/var/mfs/。 [root@metalogger mfs]# cd ../../var/mfs/ [root@metalogger mfs]# ls metadata.mfs.empty [root@metalogger mfs]# cp metadata.mfs.empty metadata.mfs [root@metalogger mfs]# chown -R mfs:mfs /usr/local/mfs 5）啓動metalogger節點服務 [root@metalogger mfs]# ln -s /usr/local/mfs/sbin/mfsmetalogger /etc/init.d/mfsmetalogger [root@metalogger mfs]# /etc/init.d/mfsmetalogger start open files limit has been set to: 4096 working directory: /usr/local/mfs/var/mfs lockfile created and locked initializing mfsmetalogger modules ... mfsmetalogger daemon initialized properly [root@metalogger mfs]# ps -ef|grep mfs mfs 9353 1 1 14:22 ? 00:00:00 /etc/init.d/mfsmetalogger start root 9355 3409 0 14:22 pts/0 00:00:00 grep mfs [root@metalogger mfs]# lsof -i:9419 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME mfsmetalo 9353 mfs 8u IPv4 38278 0t0 TCP 182.48.115.235:37237->182.48.115.233:9419 (ESTABLISHED) 其餘相關啓動命令 [root@metalogger mfs]# /etc/init.d/mfsmetalogger start/stop/status/restart/reload
接着再看看Web GUI訪問頁面（能夠reload 重載mfscgiserv服務）
4）mfs client客戶端上的操做記錄
1）mfs client安裝依賴與系統包fuse，經過yum方式安裝（也能夠源碼安裝）
[root@clinet-server ~]# yum -y install fuse fuse-devel
2）建立mfs用戶和組
[root@clinet-server ~]# useradd mfs -s /sbin/nologin
3）編譯安裝mfs
[root@clinet-server ~]# yum install -y gcc c++ zlib-devel
[root@clinet-server ~]# tar -zvxf moosefs-3.0.91-1.tar.gz
[root@clinet-server ~]# cd moosefs-3.0.91
[root@clinet-server moosefs-3.0.91]# ./configure --prefix=/usr/local/mfs --with-default-user=mfs --with-default-group=mfs --enable-mfsmount
[root@clinet-server moosefs-3.0.91]# make && make install
4）建立mfs掛載目錄
[root@clinet-server ~]# mkdir /mnt/mfs //這個是掛載的數據目錄，掛載目錄能夠在客戶機上任意定義
[root@clinet-server ~]# mkdir /mnt/mfsmeta //這個是掛載的回收站目錄
5）mfs client 掛載命令
[root@clinet-server ~]# /usr/local/mfs/bin/mfsmount /mnt/mfs -H 182.48.115.233 //掛載MFS文件系統的根目錄到本機的/mnt/mfs下
mfsmaster accepted connection with parameters: read-write,restricted_ip,admin ; root mapped to root:root
[root@clinet-server ~]# /usr/local/mfs/bin/mfsmount -m /mnt/mfsmeta/ -H 182.48.115.233 //掛載MFS文件系統的mfsmeta，使用回收站功能
mfsmaster accepted connection with parameters: read-write,restricted_ip
6）查看
[root@clinet-server ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VolGroup-lv_root
8.3G 3.8G 4.1G 49% /
tmpfs 499M 228K 498M 1% /dev/shm
/dev/vda1 477M 35M 418M 8% /boot
/dev/sr0 3.7G 3.7G 0 100% /media/CentOS_6.8_Final
182.48.115.233:9421 16G 2.7G 14G 17% /mnt/mfs
mount查看
[root@clinet-server ~]# mount
/dev/mapper/VolGroup-lv_root on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw,rootcontext="system_u:object_r:tmpfs_t:s0")
/dev/vda1 on /boot type ext4 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
gvfs-fuse-daemon on /root/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev)
/dev/sr0 on /media/CentOS_6.8_Final type iso9660 (ro,nosuid,nodev,uhelper=udisks,uid=0,gid=0,iocharset=utf8,mode=0400,dmode=0500)
182.48.115.233:9421 on /mnt/mfs type fuse.mfs (rw,nosuid,nodev,allow_other)
182.48.115.233:9421 on /mnt/mfsmeta type fuse.mfsmeta (rw,nosuid,nodev,allow_other)
mfsmount是本地文件系統代理，掛接FUSE，監聽文件系統IO。
mfsmout向master獲取chunk信息，向mfschunkserver發出讀寫數據的命令，chunkserver是磁盤IO的執行者。mfsmount是用戶發出IO請求的命令接收者，master是
mfs全部chunk和node信息的維護者。
在掛載目錄/mnt/mfs下的文件就會經過master管理節點放到chunkserver上，而且是被分紅多個塊放到各個chunkserver上的；能夠再其餘的clinet機器上掛載MFS，那麼掛載點裏的
文件都是同步共享的。這樣當一臺或多臺chunkserver宕機或出現故障時（只要不是所有出現故障），對於clinet端來講，共享MFS數據都是不受影響的。
到掛載目錄/mnt/mfs下，就能夠查看到MFS文件系統根目錄下的內容了
[root@clinet-server ~]# cd /mnt/mfs
[root@clinet-server mfs]# ls
hqsb huanqiu ip_list
[root@clinet-server mfs]# echo "123123123" > test
[root@clinet-server mfs]# ls
hqsb huanqiu ip_list test
--------------------------------------------------------------------------------
卸載的話，直接使用命令：
[root@clinet-server ~]# umount /mnt/mfs
[root@clinet-server ~]# umount /mnt/mfsmeta
卸載後，在客戶機上的掛載目錄下就什麼內容都查看不到了
[root@clinet-server ~]# cd /mnt/mfs
[root@clinet-server mfs]# ls
[root@clinet-server mfs]#
---------------------------------------------------------------------------------
5）MFS平常操做（都在client端下操做）
1->回收站功能
mfs文件系統是正規的mfs掛載系統，裏面包含了全部的mfs存儲的文件與目錄。 mfsmeta文件系統是mfs提供用於輔助的文件系統，至關於windows的回收站。 如上，在clinet端啓動管理服務器進程時，用了一個-m選項，這樣能夠掛載一個輔助的文件系統mfsmeta，輔助文件系統能夠在以下兩個方面恢復丟失的數據： 1）MFS捲上誤刪除了文件，而此文件又沒有過垃圾文件存放期。 2）爲了釋放磁盤空間而刪除或者移動的文件，當須要恢復這些文件時，文件又沒有過垃圾文件的存放期。 要使用MFS輔助文件系統，能夠執行以下指令： # mfsmount -m /mnt/mfsclient -H mfsmaster //回收站目錄掛載前面已操做 須要注意的是，若是決定了掛載mfsmeta，那麼必定要在mfsmaster的mfsexport.cfg文件中添加下面這條記錄（前面已提到）： * . rw 掛載文件系統就能夠執行所全部標準的文件操做了。如建立，刪除，複製，重命名文件等。MFS因爲是一個網絡文件系統，因此操做進度比本地的偏慢。 須要注意的是，每一個文件均可以存儲爲多個副本，在這種狀況下，每個文件所佔用的空間要比其餘文件自己大的多，此外，被刪除且在有效期內的文件都放在 一個「垃圾箱」中，因此他們也佔用的空間，其大小也依賴文件的分鐘。。爲防止刪除被其餘進程打開的文件，數據將一直被存儲，直到文件被關閉。 被刪文件的文件名在「垃圾箱」目錄裏還可見,文件名由一個八位十六進制的數i-node 和被刪文件的文件名組成，在文件名和i-node 之間不是用「/」,而是用了「|」替代。 若是一個文件名的長度超過操做系統的限制（一般是255 個字符），那麼部分將被刪除。經過從掛載點起全路徑的文件名被刪除的文件仍然能夠被讀寫。 移動這個文件到trash/undel 子目錄下，將會使原始的文件恢復到正確的MooseFS 文件系統上路徑下（若是路徑沒有改變）。若是在同一路徑下有個新的同名文件， 那麼恢復不會成功。從「垃圾箱」中刪除文件結果是釋放以前被它站用的空間(刪除有延遲,數據被異步刪除)。 刪除的文件經過一個單獨安裝的mfsmeta輔助文件系統來恢復。這個文件系統包含了目錄trash（含有仍然能夠被還原的刪除文件的信息）和目錄trash/undel（用於獲取文件）。 只有管理員權限訪問mfsmeta輔助文件系統(一般是root) ---------------------------下面測試下MFS回收站功能------------------------------ 在mfs掛載點刪除一個文件，在mfsmeta掛載點能夠找到: [root@clinet-server ~]# echo "asdfasdfnoijoiujro2er0" >/mnt/mfs/haha1 [root@clinet-server ~]# /usr/local/mfs/bin/mfsrgettrashtime /mnt/mfs/haha1 deprecated tool - use "mfsgettrashtime -r" /mnt/mfs/haha1: files with trashtime 14400 : 1 //確認回收站存放的時間爲4小時 [root@clinet-server ~]# rm /mnt/mfs/haha1 //刪除文件 rm: remove regular file `/mnt/mfs/haha1'? y [root@clinet-server ~]# find /mnt/mfsmeta/trash/ -name "*haha*" //在回收站裏面找到被刪除的文件 /mnt/mfsmeta/trash/01F/0000001F|haha1 被刪除的文件名在垃圾箱裏面其實仍是能夠找到的，文件名是由一個8位16進制數的i-node和被刪的文件名組成。在文件名和i-node之間不能夠用"/"，而是以"|"替代。 若是一個文件名的長度超過操做系統的限制（一般是255字符），那麼超出部分將被刪除。從掛載點起所有路徑的文件名被刪除的文件仍然能夠被讀寫。 須要注意的是，被刪除的文件在使用文件名（注意文件名是兩部分），必定要用單引號引發來。以下所示： [root@clinet-server ~]# cat '/mnt/mfsmeta/trash/01F/0000001F|haha1' haha1 從回收站裏恢復已刪除的文件 移動這個文件到文件所在目錄下的undel下面，將會使原始的文件恢復到正確的MFS文件系統原來的路徑下。以下所示： [root@clinet-server ~]# cd /mnt/mfsmeta/trash/01F [root@clinet-server 01F]# ls 0000001F|haha1 undel [root@clinet-server 01F]# mv 0000001F\|haha1 ./undel/ [root@clinet-server 01F]# cat /mnt/mfs/haha1 //發現haha1文件已經恢復了 asdfasdfnoijoiujro2er0 在恢復文件的時候，原來被刪文件下面的目錄下，不能有同名文件，否則恢復不成功。 從垃圾箱中刪除文件的結構是釋放以前它佔用的空間（刪除有延遲，由於數據是異步刪除的）。在垃圾箱中刪除文件後，就不可以再恢復了。 能夠經過mfssetgoal命令來修改文件的副本數，也能夠經過mfssettrashtime工具來改變文件存儲在垃圾箱中的時間。 ----------------------------爲垃圾箱設定隔離時間--------------------------------------- 刪除的文件存放在"垃圾箱（trash bin）"的時間就是隔離時間（quarantine time）,即一個刪除文件可以存放在一個"垃圾箱"的時間。 這個時間能夠用mfsrgettrashtime命令來驗證，也能夠用mfssettrashtime或者mfsrsettrashtime命令來設置。 設置的時間是按照小時計算，設置的單位是秒，不滿一小時就按一小時計算，以下所示： [root@clinet-server ~]# /usr/local/mfs/bin/mfssettrashtime 600 /mnt/mfs/ /mnt/mfs/: 600 上面設置爲600秒，即10分鐘，不足1小時，算做1小時，因此查看結果是3600秒（即1小時） [root@clinet-server ~]# /usr/local/mfs/bin/mfsrgettrashtime /mnt/mfs deprecated tool - use "mfsgettrashtime -r" /mnt/mfs: files with trashtime 3600 : 2 directories with trashtime 3600 : 1 #查看這一行結果 [root@clinet-server ~]# /usr/local/mfs/bin/mfssettrashtime 6000 /mnt/mfs/ /mnt/mfs/: 6000 設置6000秒，多餘1小時，不足2小時，結果算做是2小時 [root@clinet-server ~]# /usr/local/mfs/bin/mfsrgettrashtime /mnt/mfs deprecated tool - use "mfsgettrashtime -r" /mnt/mfs: files with trashtime 3600 : 2 directories with trashtime 7200 : 1 若把時間設置爲0，說明文件執行刪除命令後，就會當即刪除，不可能再恢復，不進入回收站： [root@clinet-server ~]# /usr/local/mfs/bin/mfssettrashtime 0 /mnt/mfs/ /mnt/mfs/: 0 [root@clinet-server ~]# /usr/local/mfs/bin/mfsrgettrashtime /mnt/mfs deprecated tool - use "mfsgettrashtime -r" /mnt/mfs: files with trashtime 3600 : 2 directories with trashtime 0 : 1 mfssettrashtime -r是對目錄進行遞歸賦值的。爲一個目錄設定存放時間後，在此目錄下新建立的文件和目錄就能夠繼承這個設置了。 [root@clinet-server ~]# /usr/local/mfs/bin/mfssettrashtime -r 6000 /mnt/mfs/ /mnt/mfs/: inodes with trashtime changed: 4 inodes with trashtime not changed: 0 inodes with permission denied: 0 [root@clinet-server ~]# /usr/local/mfs/bin/mfsrgettrashtime /mnt/mfs/ deprecated tool - use "mfsgettrashtime -r" /mnt/mfs/: files with trashtime 7200 : 3 directories with trashtime 7200 : 1 [root@clinet-server ~]# /usr/local/mfs/bin/mfsrgettrashtime /mnt/mfs/haha1 deprecated tool - use "mfsgettrashtime -r" /mnt/mfs/haha1: files with trashtime 7200 : 1
2->設定目標的拷貝份數
目標（goal），是指文件被拷貝的份數，設定了拷貝的份數後是能夠經過mfsgetgoal 命令來證明的，也能夠經過mfsrsetgoal 來改變設定。
設置mfs文件系統中文件的副本個數，好比本案例中，設置2份：
[root@clinet-server ~]# /usr/local/mfs/bin/mfssetgoal 2 /mnt/mfs/test.txt
/mnt/mfs/test.txt: goal: 2
查看文件份數：
[root@clinet-server ~]# /usr/local/mfs/bin/mfsgetgoal /mnt/mfs/test.txt
/mnt/mfs/test.txt: 2
能夠看出，與設置的文件副本數一致！
根據測試：goal number<=chunkserver number
即拷貝份數要不能多餘chunkserver的節點數量
目錄設置與文件設置操做一致，給目錄設置goal，以後在該目錄下建立的文件將會繼承該goal，但不會影響到已經存在的文件。
[root@clinet-server ~]# /usr/local/mfs/bin/mfssetgoal 2 /mnt/mfs
/mnt/mfs: goal: 2
[root@clinet-server ~]# /usr/local/mfs/bin/mfsgetgoal /mnt/mfs
/mnt/mfs: 2
若要使該命令遞歸到目錄下的全部文件，添加-r參數。
用mfsgetgoal –r 和mfssetgoal –r 一樣的操做能夠對整個樹形目錄遞歸操做，其等效於mfsrsetgoal命令
[root@clinet-server ~]# /usr/local/mfs/bin/mfssetgoal -r 2 /mnt/mfs
/mnt/mfs:
inodes with goal changed: 0
inodes with goal not changed: 2
inodes with permission denied: 0
[root@clinet-server ~]# /usr/local/mfs/bin/mfsgetgoal -r /mnt/mfs
/mnt/mfs:
files with goal 2 : 2
directories with goal 2 : 1
[root@clinet-server ~]# /usr/local/mfs/bin/mfsrgetgoal /mnt/mfs
deprecated tool - use "mfsgetgoal -r"
/mnt/mfs:
files with goal 2 : 2
directories with goal 2 : 1
----------------------------------------------------------------------------------------------------------------------------------------
對一個目錄設定「goal」，此目錄下的新建立文件和子目錄均會繼承此目錄的設定，但不會改變已經存在的文件及目錄的copy份數。但使用-r選項能夠更改已經存在的copy份數。
goal設置爲2，只要兩個chunkserver有一個可以正常運行，數據就能保證完整性。
假如每一個文件的goal（保存份數）都不小於2，而且沒有under-goal文件（能夠用mfsgetgoal –r和mfsdirinfo命令來檢查），那麼一個單一的chunkserver在任什麼時候刻均可能作
中止或者是從新啓動。之後每當須要作中止或者是從新啓動另外一個chunkserver的時候，要肯定以前的chunkserver被鏈接，並且要沒有under-goal chunks。
實際測試時，傳輸一個大文件，設置存儲2份。傳輸過程當中，關掉chunkserver1，這樣絕對會出現有部分塊只存在chunkserver2上；啓動chunkserver1，關閉chuner2，這樣絕對
會有部分塊只存在chuner1上。把chunkserver2啓動起來。整個過程當中，客戶端一直可以正常傳輸。在客戶端查看，一段時間內，沒法查看；稍後一段時間後，就能夠訪問了。
文件正常，使用mfsfileinfo 查看此文件，發現有的塊分佈在chunkserver1上，有的塊分佈在chuner2上。使用mfssetgoal 2和mfssetgoal -r 2均不能改變此文件的目前塊的現狀。
但使用mfssetgoal -r 1後，全部塊都修改爲1塊了，再mfssetgoal -r 2，全部塊都修改爲2份了。
測試chunkserver端，直接斷電狀況下，chunkserver會不會出問題：
1）數據傳輸過程當中，關掉chunkserver1，等待數據傳輸完畢後，開機啓動chunkserver1.
chunkserver1啓動後，會自動從chunkserver2複製數據塊。整個過程當中文件訪問不受影響。
2）數據傳輸過程當中，關掉chunkserver1，不等待數據傳輸完畢，開機啓動chunkserver1.
chunkserver1啓動後，client端會向chunkserver1傳輸數據，同時chunkserver1也從chunkserver2複製缺失的塊。
若是有三臺chunkserver，設置goal=2，則隨機挑選2個chunkserver存儲。
若是有一個chunkserver不能提供服務，則剩餘的2個chunkserver上確定有部分chunks（塊）保存的是一份。則在參數（REPLICATIONS_DELAY_DISCONNECT = 3600）後，只有一份的chunks
會自動複製一份，即保存兩份。保存兩份後，若是此時壞掉的chunkserver可以提供服務後，此時確定有部分chunks存儲了三份，mfs會自動刪除一份。
當增長第三個服務器作爲額外的chunkserver時，雖然goal設置爲2，但看起來第三個chunkserver從另外兩個chunkserver上覆制數據。
是的，硬盤空間平衡器是獨立地使用chunks的，所以一個文件的chunks會被從新分配到全部的chunkserver上。
----------------------------------------------------------------------------------------------------------------------------------------------
查看文件的實際副本數量能夠經過mfscheckfile和mfsfileinfo命令證明。
mfscheckfile可查看copy數：
mfsfileinfo可查看具體的copy位置
注意下面幾個特殊狀況：
1）一個不包含數據的零長度的文件,儘管沒有設置爲非零的目標，但用mfscheckfile命令查詢將返回一個空的結果；將文件填充內容後，其會根據設置的goal建立副本；
這時再將文件清空，其副本依然做爲空文件存在。
2）假如改變一個已經存在的文件的拷貝個數，那麼文件的拷貝份數將會被擴大或者被刪除，這個過程會有延時。能夠經過mfscheckfile 命令來證明。
3）對一個目錄設定「目標」，此目錄下的新建立文件和子目錄均會繼承此目錄的設定，但不會改變已經存在的文件及目錄的拷貝份數。能夠經過mfsdirinfo來查看整個目錄樹的信息摘要。
以下示例：
[root@clinet-server ~]# touch /mnt/mfs/wangshibo
[root@clinet-server ~]# /usr/local/mfs/bin/mfscheckfile /mnt/mfs/wangshibo
/mnt/mfs/wangshibo: //雖然有文件（雖然沒有設置爲非零目標，the noo-zero goal），可是是一個空文件，因此mfscheckfile是爲空的結果。
[root@clinet-server ~]# /usr/local/mfs/bin/mfsfileinfo /mnt/mfs/wangshibo
/mnt/mfs/wangshibo:
no chunks - empty file
往上面測試文件裏寫入數據
[root@clinet-server ~]# echo "1213442134" > /mnt/mfs/wangshibo
[root@clinet-server ~]# echo "1213442134" > /mnt/mfs/wangshibo
[root@clinet-server ~]# /usr/local/mfs/bin/mfscheckfile /mnt/mfs/wangshibo
/mnt/mfs/wangshibo:
chunks with 2 copies: 1
[root@clinet-server ~]# /usr/local/mfs/bin/mfsfileinfo /mnt/mfs/wangshibo
/mnt/mfs/wangshibo:
chunk 0: 0000000000000015_00000001 / (id:21 ver:1)
copy 1: 182.48.115.236:9422 (status:VALID)
copy 2: 182.48.115.237:9422 (status:VALID) //因爲上面對/mnt/mfs目錄進行遞歸設置拷貝的份數是2，因此這裏顯示的副本數正好是2
下面設置/mnt/mfs/wangshibo 文件的副本數爲3或者大於3的副本數
[root@clinet-server ~]# /usr/local/mfs/bin/mfssetgoal 3 /mnt/mfs/wangshibo
/mnt/mfs/wangshibo: goal: 3
[root@clinet-server ~]# /usr/local/mfs/bin/mfsgetgoal /mnt/mfs/wangshibo
/mnt/mfs/wangshibo: 3
[root@clinet-server ~]# echo "asdfasdfasdf" > /mnt/mfs/wangshibo
[root@clinet-server ~]# /usr/local/mfs/bin/mfscheckfile /mnt/mfs/wangshibo
/mnt/mfs/wangshibo:
chunks with 2 copies: 1
[root@clinet-server ~]# /usr/local/mfs/bin/mfsfileinfo /mnt/mfs/wangshibo
/mnt/mfs/wangshibo:
chunk 0: 0000000000000017_00000001 / (id:23 ver:1)
copy 1: 182.48.115.236:9422 (status:VALID)
copy 2: 182.48.115.237:9422 (status:VALID)
以上可知，雖然將文件的副本數設置爲3（或者大於3），理論上應該是複製3份副本，可是這裏的chunkserver只有2臺，因此copy也就爲2了。
所以得出結論，goal number不能超過chunkserver number，要小於或等於chunkserver的數量。
另外，須要特別注意的是：
若是你的Chunkserver只有n臺服務器，那麼goal拷貝份數就設置爲n便可，千萬別設置爲超過n的數目，否則往文件裏寫入數據時，會很卡！！
順便說說目錄繼承副本數量的問題：
1）若是改變一個已經存在的文件副本份數，那麼文件的副本份數就會擴大或刪除，這個過程會有延遲的。
2）對於一個目錄設定"目標"，此目錄下新建立的文件或子目錄均會繼承此目錄的設定，但不會改變已經存在的文件以及目錄副本數量。
--------------------------------------------------------------------------------------------------------------------------------
mfsdirinfo
整個目錄樹的內容須要經過一個功能加強、等同於「du -s」的命令mfsdirinfo來顯示。mfsdirinfo能夠顯示MFS的具體信息，查看目錄樹的內容摘要：
[root@clinet-server ~]# /usr/local/mfs/bin/mfsdirinfo /mnt/mfs
/mnt/mfs:
inodes: 5
directories: 1
files: 4
chunks: 4
length: 12342
size: 294912
realsize: 1253376
其中：
1）length 表示文件大小的總和
2）size 表示塊長度總和
3）realsize 表示磁盤空間的使用，包括全部的副本
3->快照功能
MFS系統能夠利用mfsmakesnapshot工具給文件或者目錄作快照（snapshot），以下所示，將mfs文件體系下的wangshibo文件作快照
[root@clinet-server ~]# cd /mnt/mfs
[root@clinet-server mfs]# ls
wangshibo
[root@clinet-server mfs]# /usr/local/mfs/bin/mfsmakesnapshot wangshibo /opt/wangshibo-snapshot
(/opt/wangshibo-snapshot,wangshibo): both elements must be on the same device
[root@clinet-server mfs]# /usr/local/mfs/bin/mfsmakesnapshot wangshibo wangshibo-snapshot
[root@clinet-server mfs]# ll
total 1
-rw-r--r--. 1 root root 12 May 23 10:38 wangshibo
-rw-r--r--. 1 root root 12 May 23 10:38 wangshibo-snapshot
特別要注意的是：
不能將快照放到MFS文件系統以外的其餘文件系統下，快照文件和源文件必需要在同一個MFS文件系統下（即路徑一致）
[root@clinet-server mfs]# /usr/local/mfs/bin/mfsfileinfo wangshibo-snapshot
wangshibo-snapshot:
chunk 0: 000000000000001A_00000001 / (id:26 ver:1)
copy 1: 182.48.115.236:9422 (status:VALID)
copy 2: 182.48.115.237:9422 (status:VALID)
[root@clinet-server mfs]# /usr/local/mfs/bin/mfsfileinfo wangshibo
wangshibo:
chunk 0: 000000000000001A_00000001 / (id:26 ver:1)
copy 1: 182.48.115.236:9422 (status:VALID)
copy 2: 182.48.115.237:9422 (status:VALID)
經過mfsfileinfo命令能夠查看建立出來的文件快照，它只佔用了一個inode，並不佔用磁盤空間，就像ln命令建立硬連接相似！！！！
mfsmakesnapshot是一次執行中整合了一個或者一組文件的副本，並且對這些文件的源文件進行任何修改都不會影響源文件的快照，就是說任何對源文件的操做，如寫入操做，將會不修改副本。
mfsmakesnapshot能夠實現這個快照功能，當有多個源文件時，他們的快照會被加入到同一個目標文件中，經過對比快照的測試，能夠發現快照的本質：
1）一個MFS系統下的文件作快照後，查看兩個文件的塊信息，他們是同一個塊。接着，把原文件刪除，刪除源文件後（最初會留在回收站上，但過一段時間後回收站的文件也刪除了），快照
文件仍然存儲，而且能夠訪問。使用mfsfileinfo查看，發現仍是原來的塊。
2）對一個文件作快照後，查看兩個文件的塊信息，發現是同一個塊。把原文件修改後，發現原文件的使用塊信息變了，即便用了一個新塊。而快照文件仍然使用原來的塊，保持文件內容不變。
4->MFS掛載目錄技巧
1）掛載目錄管理 Moosefs系統支持客戶端根據須要掛載對應子目錄；默認不指定-S的話會掛載到根目錄（/）下，當經過df –sh查看空間使用used顯示的是當前整個mfs系統的硬盤使用狀況； 而掛載子目錄則只會看到目錄的使用狀況。具體操做以下： # mfsmount /mnt –H mfsmaster //掛載到MFS的根目錄（/）下。即在客戶端/mnt目錄下寫入的數據會直接寫到MFS的根目錄下。這裏客戶端的掛載路徑能夠自定義。 # mkdir –p /mnt/subdir # mfsmount /mnt –H mfsmaster –S /subdir //掛載到MFS子目錄（/subdir）下。這個subdir目錄是在MFS文件系統下真實存在的。在客戶端顯示的仍是/mnt路徑，往裏面寫入的數據實際上是寫到了MFS的/mnt/subdir路徑下 在Moosefs的管理中，能夠找一臺機器做爲管理型的client端，在master管理節點的配置文件mfsexports.cfg中限制只有該臺機器能夠掛載到根目錄下，同時也可限制只有 該臺機器能夠掛載metadata目錄（恢復誤刪除時可用到），而其餘普通client端，則根據不一樣業務的須要讓管理client端爲其建立獨立用途的目錄，分別掛載到對應的子 目錄下，這樣就能夠細化管理控制權限。 在master管理節點的mfsexports.cfg的配置以下： [root@master-server mfs]# pwd /usr/local/mfs/etc/mfs [root@master-server mfs]# vim mfsexports.cfg ....... 182.48.115.238 / rw,alldirs,maproot=0 182.48.115.238 . rw //即容許182.48.115.238客戶機掛載MFS的根目錄 # for huanqiu data 182.48.115.239 /huanqiu rw.maproot=0 //即容許182.48.115.239客戶機掛載MFS的子目錄huanqiu（這個子目錄是真實存在MFS文件系統下的），在客戶端寫入的數據就會保存到MFS的子目錄huanqiu下 # for hatime data 182.48.115.240 /hqsb/hqtime rw.maproot=0 //即容許182.48.115.240客戶機掛載MFS的根目錄hqsb/hqtime（這個子目錄是真實存在MFS文件系統下的） ----------------------------------------------------------------------------------------------------------------------- 在客戶機182.48.115.238上掛載MFS文件系統的根目錄，命令以下（掛載後，df -h或mount命令都能查看到掛載信息） [root@clinet-238 ~]# /usr/local/mfs/bin/mfsmount /mnt/mfs -H 182.48.115.233 這樣在182.48.115.238機器的掛載目錄/mnt/mfs裏的數據就是MFS文件系統根目錄下的數據。這個掛載目錄在客戶機上能夠隨意定義。在/mnt/mfs掛載目錄下寫入數據，就會自動同步到MFS文件系統的根目錄下 [root@clinet-238 ~]# cd /mnt/mfs [root@clinet-238 mfs]# ll total 3 drwxr-xr-x. 3 root root 0 May 23 12:57 hqsb drwxr-xr-x. 2 root root 1800 May 23 13:04 huanqiu -rw-r--r--. 1 root root 39 May 23 12:54 ip_list ----------------------------------------------------------------------------------------------------------------------- 在客戶機182.48.115.239上掛載MFS文件系統的子目錄huanqiu [root@clinet-239]# mkdir -p /opt/huanqiu [root@clinet-239]# /usr/local/mfs/bin/mfsmount /opt/huanqiu -H 182.48.115.233 -S huanqiu //後面的子目錄寫成"huanqiu"或"/huanqiu"均可以 [root@clinet-239]# cd /opt/huanqiu/ [root@clinet-239]# echo "huanqiu test data" > hq.txt //寫入數據，則會自動同步到MFS文件系統的子目錄huanqiu下 到掛載MFS根目錄的182.48.115.238客戶機上查看，發現MFS的子目錄huanqiu下已經有了新數據 [root@clinet-238 ~]# cd /mnt/mfs [root@clinet-238 mfs]# ll total 3 drwxr-xr-x. 3 root root 0 May 23 12:57 hqsb drwxr-xr-x. 2 root root 1800 May 23 13:04 huanqiu -rw-r--r--. 1 root root 39 May 23 12:54 ip_list [root@clinet-238 mfs]# cd huanqiu/ [root@clinet-238 huanqiu]# ll total 1 -rw-r--r--. 1 root root 18 May 23 13:04 hq.txt [root@clinet-238 huanqiu]# cat hq.txt huanqiu test data ----------------------------------------------------------------------------------------------------------------------- 在客戶機182.48.115.240上掛載MFS文件系統的子目錄hqsb/hqtime [root@clinet-240 ~]# mkdir -p /mfs/data [root@clinet-240 ~]# /usr/local/mfs/bin/mfsmount /mfs/data -H 182.48.115.233 -S /hqsb/hqtime //將MFS文件系統的子目錄hqsb/hqtime掛載到本機的/mfs/data下 [root@clinet-240 ~]# cd /mfs/data/ [root@clinet-240 data]# echo "hatime 12313123123" > test 到掛載MFS根目錄的182.48.115.238客戶機上查看，發現MFS的子目錄hqsb/hqtime下已經有了新數據 [root@clinet-238 ~]# cd /mnt/mfs/hqsb/hqtime/ [root@clinet-238 hqtime]# ls test [root@clinet-238 hqtime]# cat test hatime 12313123123 2）客戶端重啓後自動掛載mfs目錄 # vim /etc/rc.local ...... /sbin/modprobe fuse /usr/bin/mfsmount /mnt1 -H mfsmaster -S /backup/db /usr/bin/mfsmount /mnt2 -H mfsmaster -S /app/image Moosefs官方網頁上有提到，1.6.x以上的版本還能夠經過/etc/fstab的方式，系統重啓後自動掛載mfs文件系統，測試以後，並無成功，緣由是FUSE模塊沒有加載到內核。 因此，用/etc/fstab，FUSE模塊須要事先將其編譯進系統內核中才行。fstab的配置以下： # vim /etc/fstab mfsmount /mnt fuse mfsmaster=MASTER_IP,mfsport=9421,_netdev 0 0 //重啓系統後掛載MFS的根目錄 mfsmount /mnt fuse mfstermaster=MASTER_IP,mfsport=9421,mfssubfolder=/subdir,_netdev 0 0 //重啓系統後掛載MFS的子目錄 採用fstab配置文件掛載方式能夠經過以下命令，測試是否配置正確： # mount –a –t fuse 3）Moosefs能夠節省空間 經過測試發現，拷貝到mfs目錄下的文件大小比ext3下的小了不少，開始覺得是少同步了一些文件，因而又將mfs下的全部文件拷回到ext3下，發現大小和以前的一致。 因此說，mfs對小文件（測試文件爲8K左右）存儲空間的節省很是明顯，能夠節省一半的空間。 對於大文件存儲，mfs一樣能夠節省空間。拷貝了一個1.7G文件到mfs下，大小爲1.6G。
5->MFS元數據損壞後的恢復（簡單解決Master單點故障的瓶頸）
當master管理節點（即元數據服務器）出現故障致使元數據損壞後，能夠經過Metalogger元數據日誌服務器上的備份數據進行恢復！ 一般元數據有兩部分的數據： 1）主要元數據文件metadata.mfs，當mfsmaster運行的時候會被命名爲metadata.mfs.back 2）元數據改變日誌changelog.*.mfs，存儲了過去的N小時的文件改變。主要的元數據文件須要按期備份，備份的頻率取決於取決於多少小時changelogs儲存。 元數據changelogs應該實時的自動複製。自從MooseFS 1.6.5,這兩項任務是由mfsmetalogger守護進程作的。 元數據損壞是指因爲各類緣由致使master上的metadata.mfs數據文件不可用。一旦元數據損壞，全部的存儲在moosefs上的文件都不可以使用。 一旦master管理節點出現崩潰（好比由於主機或電源失敗），須要最後一個元數據日誌changelog併入主要的metadata中。 這個操做時經過mfsmetarestore工具作的，最簡單的方法是： # /usr/local/mfs/sbin/mfsmetarestore -a 若是master數據被存儲在MooseFS編譯指定地點外的路徑，則要利用-d參數指定使用，好比： # /usr/local/mfs/sbin/mfsmetarestore -a -d /storage/mfsmaster ------------------------------------------------------------------------------------------------------------------------- 下面模擬一個元數據損壞後的恢復操做 中止master節點並刪除metadata.mfs及changelog.0.mfs（變動日誌文件）。 [root@master-server ~]# /etc/init.d/mfsmaster stop //master服務關閉後，在客戶端的現象是：掛載目錄下操做一直在卡的狀態中 [root@master-server ~]# cd /usr/local/mfs/var/mfs [root@master-server mfs]# ls changelog.11.mfs changelog.21.mfs changelog.24.mfs changelog.28.mfs changelog.34.mfs changelog.5.mfs metadata.mfs.empty changelog.19.mfs changelog.22.mfs changelog.25.mfs changelog.29.mfs changelog.3.mfs metadata.mfs mfsmaster changelog.1.mfs changelog.23.mfs changelog.27.mfs changelog.2.mfs changelog.4.mfs metadata.mfs.back.1 stats.mfs [root@master-server mfs]# rm -rf ./* 而後從新啓動master將報錯： [root@master-server mfs]# /etc/init.d/mfsmaster start open files limit has been set to: 16384 working directory: /usr/local/mfs/var/mfs lockfile created and locked initializing mfsmaster modules ... exports file has been loaded topology file has been loaded loading metadata ... can't find metadata.mfs - try using option '-a' init: metadata manager failed !!! error occurred during initialization - exiting ---------------------------------------如今進行元數據恢復--------------------------------- 從metalogger元數據日誌服務器上將最新一份metadata_ml.mfs.back及changelog_ml.0.mfs複製到master元數據服務器的的數據目錄下，並注意文件屬主屬組爲mfs。 （或者能夠拷貝所有數據到Master元數據服務器上，這個沒驗證） 先登錄metalogger元數據日誌服務器上查看 [root@metalogger ~]# cd /usr/local/mfs/var/mfs total 108 -rw-r-----. 1 mfs mfs 2186 May 23 13:27 changelog_ml.0.mfs -rw-r-----. 1 mfs mfs 26 May 23 03:46 changelog_ml.10.mfs -rw-r-----. 1 mfs mfs 400 May 22 19:11 changelog_ml.18.mfs -rw-r-----. 1 mfs mfs 1376 May 23 12:57 changelog_ml.1.mfs -rw-r-----. 1 mfs mfs 1313 May 22 17:41 changelog_ml.20.mfs -rw-r-----. 1 mfs mfs 9848 May 22 16:58 changelog_ml.21.mfs -rw-r-----. 1 mfs mfs 18979 May 22 15:57 changelog_ml.22.mfs -rw-r-----. 1 mfs mfs 1758 May 22 14:58 changelog_ml.23.mfs -rw-r-----. 1 mfs mfs 2388 May 23 11:29 changelog_ml.2.mfs -rw-r-----. 1 mfs mfs 3780 May 23 10:59 changelog_ml.3.mfs -rw-r-----. 1 mfs mfs 1886 May 23 09:56 changelog_ml.4.mfs -rw-r-----. 1 mfs mfs 558 May 23 13:10 changelog_ml_back.0.mfs -rw-r-----. 1 mfs mfs 1376 May 23 13:10 changelog_ml_back.1.mfs -rw-r--r--. 1 mfs mfs 8 May 22 14:16 metadata.mfs -rw-r-----. 1 mfs mfs 4783 May 23 13:10 metadata_ml.mfs.back -rw-r-----. 1 mfs mfs 4594 May 23 12:10 metadata_ml.mfs.back.1 -rw-r-----. 1 mfs mfs 4834 May 23 11:10 metadata_ml.mfs.back.2 -rw-r-----. 1 mfs mfs 4028 May 23 10:10 metadata_ml.mfs.back.3 [root@metalogger mfs]# rsync -e "ssh -p22" -avpgolr metadata_ml.mfs.back changelog_ml.0.mfs 182.48.115.233:/usr/local/mfs/var/mfs/ 而後在master元數據服務器上修改複製過來的文件屬性 [root@master-server mfs]# chown -R mfs.mfs ./* [root@master-server mfs]# ll total 12 -rw-r-----. 1 mfs mfs 27 May 23 14:40 changelog.0.mfs -rw-r-----. 1 mfs mfs 2213 May 23 14:34 changelog_ml.0.mfs 啓動master服務 [root@master-server mfs]# /etc/init.d/mfsmaster start open files limit has been set to: 16384 working directory: /usr/local/mfs/var/mfs lockfile created and locked initializing mfsmaster modules ... exports file has been loaded topology file has been loaded loading metadata ... can't find metadata.mfs - try using option '-a' init: metadata manager failed !!! error occurred during initialization - exiting 發現啓動仍是報錯！！！ mfs的操做日誌都記錄到changelog.0.mfs裏面。changelog.0.mfs每小時合併一次到metadata.mfs中 此時應該利用mfsmetarestore命令合併元數據changelogs，能夠用自動恢復模式命令"mfsmetarestore –a" [root@master-server mfs]# /usr/local/mfs/sbin/mfsmetarestore -a mfsmetarestore has been removed in version 1.7, use mfsmaster -a instead 而後須要以-a方式啓動master [root@master-server mfs]# /usr/local/mfs/sbin/mfsmaster -a open files limit has been set to: 16384 working directory: /usr/local/mfs/var/mfs lockfile created and locked initializing mfsmaster modules ... exports file has been loaded topology file has been loaded loading metadata ... loading sessions data ... ok (0.0000) loading storage classes data ... ok (0.0000) loading objects (files,directories,etc.) ... ok (0.1653) loading names ... ok (0.1587) loading deletion timestamps ... ok (0.0000) loading quota definitions ... ok (0.0000) loading xattr data ... ok (0.0000) loading posix_acl data ... ok (0.0000) loading open files data ... ok (0.0000) loading flock_locks data ... ok (0.0000) loading posix_locks data ... ok (0.0000) loading chunkservers data ... ok (0.0000) loading chunks data ... ok (0.1369) checking filesystem consistency ... ok connecting files and chunks ... ok all inodes: 17 directory inodes: 4 file inodes: 13 chunks: 10 metadata file has been loaded no charts data file - initializing empty charts master <-> metaloggers module: listen on *:9419 master <-> chunkservers module: listen on *:9420 main master server module: listen on *:9421 mfsmaster daemon initialized properly [root@master-server mfs]# ls changelog.0.mfs changelog_ml_back.1.mfs metadata_ml.mfs.back 此時，master服務已經啓動，元數據已經恢復了。 [root@master-server mfs]# ps -ef|grep mfs mfs 556 1 0 13:46 ? 00:00:26 /usr/local/mfs/sbin/mfsmaster -a root 580 24958 0 14:32 pts/0 00:00:00 grep mfs [root@master-server mfs]# lsof -i:9420 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME mfsmaster 556 mfs 9u IPv4 120727 0t0 TCP *:9420 (LISTEN) mfsmaster 556 mfs 11u IPv4 120737 0t0 TCP master-server:9420->chunkServer1:52513 (ESTABLISHED) mfsmaster 556 mfs 12u IPv4 120742 0t0 TCP master-server:9420->chunkServer2:45785 (ESTABLISHED) [root@master-server mfs]# ll total 12 -rw-r-----. 1 mfs mfs 27 May 23 14:40 changelog.0.mfs -rw-r-----. 1 mfs mfs 2213 May 23 14:34 changelog_ml.0.mfs -rw-r-----. 1 mfs mfs 3967 May 23 14:10 metadata_ml.mfs.back 能夠在客戶端掛載mfs文件系統，查看元數據是否恢復及數據使用是否正常。
6->Moosefs存儲空間擴容
如上的部署環境：一臺master、一臺metalogger、兩臺chunkserver（182.48.115.236和182.48.115.237）
在客戶端掛載MFS，並設置副本數爲2。注意，副本數不能多餘chunkserver的數量！
[root@clinet-server ~]# /usr/local/mfs/bin/mfsmount /mnt/mfs -H 182.48.115.233
mfsmaster accepted connection with parameters: read-write,restricted_ip,admin ; root mapped to root:root
[root@clinet-server ~]# /usr/local/mfs/bin/mfssetgoal -r 2 /mnt/mfs/
/mnt/mfs/:
inodes with goal changed: 19
inodes with goal not changed: 0
inodes with permission denied: 0
[root@clinet-server ~]# /usr/local/mfs/bin/mfsgetgoal /mnt/mfs
/mnt/mfs: 2
準備數據
[root@clinet-server mfs]# echo "asdfasdf" > /mnt/mfs/huihui
查看副本數狀況
[root@clinet-server mfs]# /usr/local/mfs/bin/mfsfileinfo /mnt/mfs/huihui
/mnt/mfs/huihui:
chunk 0: 0000000000000031_00000001 / (id:49 ver:1)
copy 1: 182.48.115.236:9422 (status:VALID)
copy 2: 182.48.115.237422 (status:VALID)
如上，這個MFS文件系統下的huihui文件被切成了1個塊（chunks），作成了2個副本分別放在了182.48.115.236和182.48.115.237的chunkserver上了。
這兩個chunkserver只要有一個還在提供服務，則客戶端就能正常共享MFS下的這個文件數據。但若是兩個chunkserver都出現故障而不提供服務了，那
麼客戶端就不能共享MFS下的這個文件了。
注意：
1）上面例子的文件過小，小文件的話，通常是隻切割成了一個塊，若是文件比較大的話，就會切成不少歌chunks塊，好比chunk 0、chunk 一、chunk二、....
2）一旦副本數設定，而且副本已經存放到了分配的chunkserver上，後續再添加新的chunkserver，那麼這些副本也不會再次放到這些新的chunkserver上了。
除非從新調整goal副本數，則chunks塊的副本會從新匹配chunkserver進行存放。
---------------------------------再看一個大文件的例子--------------------------------------------
上傳一個200多M的大文件到MFS文件系統裏
[root@clinet-server ~]# cp -r install.img /mnt/mfs
[root@clinet-server ~]# du -sh /mnt/mfs/images/
270M /mnt/mfs/install.img
[root@clinet-server ~]# /usr/local/mfs/bin/mfsgetgoal /mnt/mfs/images/
/mnt/mfs/images/: 2
查看文件的副本數。以下發現這個大文件被切割成了4個chunks塊
[root@clinet-server mfs]# /usr/local/mfs/bin/mfsfileinfo /mnt/mfs/install.img
/mnt/mfs/install.img:
chunk 0: 0000000000000034_00000001 / (id:52 ver:1)
copy 1: 182.48.115.236:9422 (status:VALID)
copy 2: 182.48.115.237:9422 (status:VALID)
chunk 1: 0000000000000035_00000001 / (id:53 ver:1)
copy 1: 182.48.115.236:9422 (status:VALID)
copy 2: 182.48.115.237:9422 (status:VALID)
chunk 2: 0000000000000036_00000001 / (id:54 ver:1)
copy 1: 182.48.115.236:9422 (status:VALID)
copy 2: 182.48.115.237:9422 (status:VALID)
chunk 3: 000000000000003B_00000001 / (id:59 ver:1)
copy 1: 182.48.115.236:9422 (status:VALID)
copy 2: 182.48.115.237:9422 (status:VALID)
chunk 4: 000000000000003C_00000001 / (id:60 ver:1)
copy 1: 182.48.115.236:9422 (status:VALID)
copy 2: 182.48.115.237:9422 (status:VALID)
新增長兩臺chunkserver節點（分別是103.10.86.20和103.10.86.22），擴容存儲空間.chunkserver安裝部署過程如上記錄。
若是goal副本數不修改，依然保持以前設定的2個副本，那麼以上文件的4個chunks的各自副本數依然還會放到以前的2個chunkserver上，
不會調整到新增長的chunkserver上。
調整goal副本數
[root@clinet-server ~]# /usr/local/mfs/bin/mfssetgoal 3 /mnt/mfs/install.img
/mnt/mfs/install.img: goal: 3
[root@clinet-server ~]# /usr/local/mfs/bin/mfsgetgoal /mnt/mfs/install.img
/mnt/mfs/install.img: 3
再次查看副本數據，能夠看到數據進行從新平衡
[root@clinet-server ~]# /usr/local/mfs/bin/mfsfileinfo /mnt/mfs/install.img
/mnt/mfs/install.img:
chunk 0: 0000000000000034_00000001 / (id:52 ver:1)
copy 1: 103.10.86.22:9422 (status:VALID)
copy 2: 182.48.115.236:9422 (status:VALID)
copy 3: 182.48.115.237:9422 (status:VALID)
chunk 1: 0000000000000035_00000001 / (id:53 ver:1)
copy 1: 103.10.86.22:9422 (status:VALID)
copy 2: 182.48.115.236:9422 (status:VALID)
copy 3: 182.48.115.237:9422 (status:VALID)
chunk 2: 0000000000000036_00000001 / (id:54 ver:1)
copy 1: 103.10.86.20:9422 (status:VALID)
copy 2: 182.48.115.236:9422 (status:VALID)
copy 3: 182.48.115.237:9422 (status:VALID)
chunk 3: 000000000000003B_00000001 / (id:59 ver:1)
copy 1: 103.10.86.22:9422 (status:VALID)
copy 2: 182.48.115.236:9422 (status:VALID)
copy 3: 182.48.115.237:9422 (status:VALID)
chunk 4: 000000000000003C_00000001 / (id:60 ver:1)
copy 1: 103.10.86.20:9422 (status:VALID)
copy 2: 182.48.115.236:9422 (status:VALID)
copy 3: 182.48.115.237:9422 (status:VALID)
上面是最終從新平衡後的效果（須要通過必定的分配過程），若是中間注意觀察，會發現chunks塊的各個副本的分配的過程。
相關文章
- 1. 分佈式文件系統MFS(moosefs)實現存儲共享
- 2. 分佈式文件系統MFS(moosefs)實現存儲共享(二)
- 3. 分佈式文件系統MFS(moosefs)實現存儲共享(一)
- 4. Centos7下GlusterFS分佈式存儲集羣環境部署記錄
- 5. 分佈式文件系統MFS(moosefs)實現存儲共享(第二版)
- 6. Moosefs 分佈式存儲
- 7. MFS分佈式存儲
- 8. mfs分佈式存儲
- 9. 分佈式存儲（MFS）
- 10. 分佈式存儲 - MFS
- 更多相關文章...
- • Maven 自動化部署 - Maven教程
- • ADO 添加記錄 - ADO 教程
- • 再有人問你分佈式事務，把這篇扔給他
- • 常用的分佈式事務解決方案
相關標籤/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
歡迎關注本站公眾號,獲取更多信息
