mfs分佈式存儲

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。這樣將會丟失那些正在傳輸的數據。