Moosefs 分佈式存儲(MFS)
MFS 文件系統結構:
包含 4 種角色:
1,管理服務器 managing server (master):
管理服務器:負責各個數據存儲服務器的管理,文件讀寫調度,文件空間回收以及恢復.多節點拷貝。
2,元數據日誌服務器 Metalogger server(Metalogger):
元數據日誌服務器: 負責備份 master 服務器的變化日誌文件,文件類型爲
changelog_ml.*.mfs,以便於在 master server 出問題的時候接替其進行工作。
3,數據存儲服務器 data servers (chunkservers):
數據存儲服務器:負責連接管理服務器,聽從管理服務器調度,提供存儲空間,併爲客戶提供數據傳輸。
4,客戶機掛載使用 client computers:
客戶端: 通過 fuse 內核接口掛接遠程管理服務器上所管理的數據存儲服務器,看起來共享的文件系統和本地 unix 文件系統使用一樣的效果。
文件系統結構：
MFS讀寫原理：
原始的讀/寫速度很明顯是主要取決於所使用的硬盤的性能、網絡的容量和拓撲結構的,使用的硬盤和網絡的吞吐量越好,整個系統的性能也就會越好。
MFS 特性:
1. Free(GPL)
2. 通用文件系統,不需要修改上層應用就可以使用
3. 可以在線擴容,體系架構可伸縮性極強。
4. 部署簡單。
5. 高可用,可設置任意的文件冗餘程度(提供比 raid1+0 更高的冗餘級別,而絕對不會影響讀或
寫的性能,只會加速!)
6. 可回收在指定時間內刪除的文件( “ 回收站 ” 提供的是系統級別的服務,不怕誤操作了,提供類
似 oralce 的閃回等高級 dbms 的即時回滾特性!)
7. 提供 netapp,emc,ibm 等商業存儲的 snapshot 特性。(可以對整個文件甚至在正在寫入的文
件創建文件的快照)
8. google filesystem 的一個 c 實現。
9. 提供 web gui 監控接口。
10. 提高隨機讀或寫的效率。
11. 提高海量小文件的讀寫效率。
可能的瓶頸:
1. master 本身的性能瓶頸。mfs 系統 master 存在單點故障如何解決?moosefs+drbd+heartbeat
來保證 master 單點問題?不過在使用過程中不可能完全不關機和間歇性的網絡中斷!
2. 體系架構存儲文件總數的可遇見的上限。(mfs 把文件系統的結構緩存到 master 的內存中,文
件越多,master 的內存消耗越大,8g 對應 2500w 的文件數,2 億文件就得 64GB 內存 )。
master 服務器 CPU 負載取決於操作的次數,內存的使用取決於文件和文件夾的個數。
MFS部署：
Master：172.25.24.4
Chunkserver：172.25.24.5 172.25.24.6
Client：172.25.24.250
在所有服務器上都要添加地址解析：
Vim /etc/hosts
172.25.24.4 mfsmaster server4.example.com
Master端：
yum install -y rpm-build
yum install -y fuse-devel libpcap-devel
ln -s moosefs-3.0.80-1.tar.gz /root/moosefs-3.0.80.tar.gz
rpmbuild -tb moosefs-3.0.80-1.tar.gz
cd rpmbuild/RPMS/x86_64/
rpm -ivh moosefs-master-3.0.80-1.x86_64.rpm moosefs-cgi-3.0.80-1.x86_64.rpm moosefs-cgiserv-3.0.80-1.x86_64.rpm
moosefs-cli-3.0.80-1.x86_64.rpm
rpm -ql moosefs-cgiserv-3.0.80-1.x86_64
[root@server4 mfs]# mfscgiserv##mfs圖形化監控開啓
lockfile created and locked
starting simple cgi server (host: any , port: 9425 , rootpath: /usr/share/mfscgi)
Mfscgiserver port: 9425##mfs圖形監控端口
[root@server4 mfscgi]# mfsmaster##mfsmaster服務開啓
open files limit has been set to: 16384
working directory: /var/lib/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##master端被監視的端口
mfsmaster daemon initialized properly
在瀏覽器訪問master圖形端口：172.25.24.4:9425/mfs.cgi
Master端的圖形監控已經設置好
接下來配置chunkserver（兩個配置方法相同）端：
rpm -ivh libpcap-1.4.0-4.20130826git2dbcaa1.el6.x86_64.rpm libpcap-devel-1.4.0-4.20130826git2dbcaa1.el6.x86_64.rpm
rpm -ivh moosefs-chunkserver-3.0.80-1.x86_64.rpm
vim /etc/mfs/mfshdd.cfg
/mnt/chunk1##定義mfs共享文件目錄這個目錄必須存在，而且所屬用戶和爲組必須時mfs
[root@server6 mnt]# chown mfs.mfs chunk1/
[root@server6 mnt]# ll
total 4
drwxr-xr-x 2 mfs mfs 4096 May 13 21:04 chunk1
[root@server6 mnt]# mfschunkserver ##開啓mfschunkserver服務
open files limit has been set to: 16384
working directory: /var/lib/mfs
lockfile created and locked
setting glibc malloc arena max to 8
setting glibc malloc arena test to 1
initializing mfschunkserver modules ...
hdd space manager: path to scan: /mnt/chunk1/
hdd space manager: start background hdd scanning (searching for available chunks)
main server module: listen on *:9422##mfschunkserver服務端口
no charts data file - initializing empty charts
mfschunkserver daemon initialized properly
安裝客戶端：
Rpm -ivh moosefs-client-3.0.80-1.x86_64.rpm
Mkdir /mnt/mfs
root@taxing ~]# mfsmount /mnt/mfs/ -H mfsmaster
mfsmaster accepted connection with parameters: read-write,restricted_ip,admin ; root mapped to root:root
[root@taxing ~]# df -h
mfsmaster:9421 35G 5.8G 29G 17% /mnt/mfs
[root@taxing mfs]# mfsgetgoal .
.: 2##文件在該目錄i中的存儲份數
[root@taxing mfs]# mfsfileinfo dir1/passwd
dir1/passwd:
chunk 0: 0000000000000001_00000001 / (id:1 ver:1)
copy 1: 172.25.24.5:9422 (status:VALID)
copy 2: 172.25.24.6:9422 (status:VALID)
如果文件過大，則會分片存儲備份
[root@taxing dir2]# dd if=/dev/zero of=testfile bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.873534 s, 120 MB/s
[root@taxing dir2]# mfsfileinfo testfile
testfile:
chunk 0: 0000000000000003_00000001 / (id:3 ver:1)
copy 1: 172.25.24.5:9422 (status:VALID)
copy 2: 172.25.24.6:9422 (status:VALID)
chunk 1: 0000000000000004_00000001 / (id:4 ver:1)
copy 1: 172.25.24.5:9422 (status:VALID)
copy 2: 172.25.24.6:9422 (status:VALID)
關閉一個chunkserver之後：
[root@taxing dir1]# mfsfileinfo passwd
passwd:
chunk 0: 0000000000000001_00000001 / (id:1 ver:1)
copy 1: 172.25.24.6:9422 (status:VALID)
[root@taxing dir1]# mfsfileinfo passwd
passwd:
chunk 0: 0000000000000001_00000001 / (id:1 ver:1)
copy 1: 172.25.24.5:9422 (status:VALID)
copy 2: 172.25.24.6:9422 (status:VALID)
文件刪除之後的恢復：
掛載 MFSMETA 文件系統,它包含目錄 trash (包含仍然可以被還原的刪除文件的信息)和
trash/undel (用於獲取文件)。把刪除的文件,移到/ trash/undel 下,就可以恢復此文件。
在 MFSMETA 的目錄裏,除了 trash 和 trash/undel 兩個目錄,還有第三個目錄 reserved,該目
錄內有已經刪除的文件,但卻被其他用戶一直打開着。在用戶關閉了這些被打開的文件後,
reserved 目錄中的文件將被刪除,文件的數據也將被立即刪除。此目錄不能進行操作。
mfsgettrashtime dir1/
dir1/: 86400##文件刪除後存放在 “ 垃圾箱 ” 中的時間稱爲隔離時間, 這個時間可以用 mfsgettrashtime 命令來查看,用 mfssettrashtime 命令來設置,單位爲秒,默認爲 86400 秒。
掛載數據
[root@taxing mnt]# mfsmount -m /mnt/mfsmeta/ -H mfsmaster
mfsmaster accepted connection with parameters:read-write,restricted_ip## -m 參數 指定元數據
cd mfsmeta/trash
Find -name *passwd* ##查找刪除文件的位置
mv 004/00000004\|dir1\|passwd undel/##將刪除的文件移動的恢復文件的目錄。移動之後就可以在原文件位置找到原文件
修改 linux 下最大文件描述符的限制:
涉及到內核文件
系統級限制:它是限制所有用戶打開文件描述符的總和,可以通過修改內核參數來更改該限制:
Vim /etc/sysctl.conf
fs.file-max=102400##如果此值默認夠大可以不用更改
sysctl -p ##命令使其生效
用戶級限制:只是修改用戶級的最大文件描述符限制,也就是說每一個用戶登錄後執行的程序佔用文件描述符的總數不能超過這個限制
vi /etc/security/limits.conf
* - nofile 102400
保存退出後重新登錄,其最大文件描述符已經被永久更改了。
與 file-max 參數相對應的還有 file-nr,這個參數是隻讀的,可以查看當前文件描述符的使用情況。
# sysctl -a|grep file
fs.file-nr = 12800 0 782554
fs.file-max = 782554
##sysctl -a 查看內核值 共697項
爲了安全停止 MooseFS 集羣,建議執行如下的步驟:
# umount -l /mnt/mfs
#客戶端卸載 MooseFS 文件系統
# mfschunkserver stop
# 停止 chunk server 進程
# mfsmetalogger stop
# 停止 metalogger 進程
# mfsmaster stop
# 停止主控 master server 進程
安全的啓動 MooseFS 集羣:
# mfsmaster start
# 啓動 master 進程
# mfschunkserver start
# 啓動 chunkserver 進程
# mfsmetalogger start
# 啓動 metalogger 進程
# mfsmount
# 客戶端掛載 MooseFS 文件系統
實際上無論如何順序啓動或關閉,未見任何異常,master 啓動後,metalogger、chunker、client
三個元素都能自動與 master 建立連接。
故障測試:
Client 客戶端斷電、斷網對 MFS 的體系不產生影響.如果客戶端誤殺 killall -9 mfsmount 進程,需要先 umount /mnt/mfs,然後再 mfsmount。否則會
提示:/mnt/mfs: Transport endpoint is not connected
chunkserver 端:
傳輸一個大文件,設置存儲 2 份。傳輸過程中,關掉 chunker1,這樣絕對會出現有部分塊只存在
chunker2 上;啓動 chunker1,關閉 chunker2,這樣絕對會有部分塊只存在 chunker1 上。
把 chunker2 啓動起來。整個過程中,客戶端一直能夠正常傳輸。使用 mfsfileinfo 查看此文件,發
現有的塊分佈在 chunker1 上,有的塊分佈在 chunker2 上。使用 mfssetgoal -r 1 後,所有塊都修
改成 1 塊了,再 mfssetgoal -r 2,所有塊都修改成 2 份了。
斷網、殺掉 mfschunkserver 程序對 MFS 系統無影響。
斷電:
#無文件傳輸時,對兩個 chunker 都無影響;
#當有文件傳輸時,但是文件設置存儲一份時,對文件的存儲無影響。
#文件設置存儲兩份,數據傳輸過程中,關掉 chunker1,等待數據傳輸完畢後,啓動
chunker1.chunker1 啓動後,會自動從 chunker2 複製數據塊。整個過程中文件訪問不受影響。
#文件設置存儲兩份,數據傳輸過程中,關掉 chunker1,不等待數據傳輸完畢,開機啓動
chunker1.chunker1 啓動後,client 端會向 chunker1 傳輸數據,同時 chunker1 也從 chunker2 復
制缺失的塊。
只要不是兩個 chunker 服務器同時掛掉的話,就不會影響文件的傳輸,也不會影響服務的使用。
master 端:
斷網、殺掉 MFS 的 master 服務對 MFS 系統無影響。
斷電可能會出現以下的情況:#當沒有文件傳輸時,可在服務器重啓之後,運行 mfsmetarestore –a 進行修復,之後執行
mfsmaster start 恢復 master 服務。
# mfsmetarestore -a
loading objects (files,directories,etc.) ... ok
loading names ... ok
loading deletion timestamps ... ok
loading chunks data ... ok
checking filesystem consistency ... ok
connecting files and chunks ... ok
store metadata into file: /var/lib/mfs/metadata.mfs
# mfsmaster start
working directory: /var/lib/mfs
lockfile created and locked
initializing mfsmaster modules ...
loading sessions ... ok
sessions file has been loaded
exports file has been loaded
mfstopology configuration file (/etc/mfstopology.cfg) not found - using defaults
loading metadata ...
loading objects (files,directories,etc.) ... ok
loading names ... ok
loading deletion timestamps ... ok
loading chunks data ... ok
checking filesystem consistency ... ok
connecting files and chunks ... ok
all inodes: 5
directory inodes: 3
file inodes: 2
chunks: 2
metadata file has been loaded
stats file has been loaded
master <-> metaloggers module: listen on *:9419
master <-> chunkservers module: listen on *:9420
main master server module: listen on *:9421
mfsmaster daemon initialized properly
#當有文件傳輸時,可能會在/usr/local/mfs/sbin/mfsmetarestore –a 進行修復時可能會出現:
# mfsmetarestore -a
loading objects (files,directories,etc.) ... ok
loading names ... ok
loading deletion timestamps ... ok
loading chunks data ... ok
checking filesystem consistency ... ok
connecting files and chunks ... ok
S:115: error: 32 (Data mismatch)
此時無法修復也無法啓動 master 服務,有個應急的辦法是將 metadata.mfs.back 複製成
metadata.mfs,然後再啓動 master。這樣將會丟失那些正在傳輸的數據。