Moosefs分佈式存儲

Moosefs分佈式存儲

第一部分:原理講解

首先,我們熟悉的百度網盤就是分佈式文件系統的一個例子,百度用來做存儲的。

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 文件系統結構:包含 4 種角色:

管理服務器 managing server (master),這裏不是存貯數據的地方,但是這裏包含着存儲的數據的權限,大小,分別存放在那些服務器上等信息.

元數據日誌服務器MetaloggerserverMetalogger)

數據存儲服務器 data servers chunkservers)

客戶機掛載使用 client computers

clip_image002

各種角色作用:

1. 管理服務器:負責各個數據存儲服務器的管理,文件讀寫調度,文件空間回收以及恢復.多節點拷貝。

2. 元數據日誌服務器:負責備份 master 服務器的變化日誌文件,文件類型爲

changelog_ml.*.mfs,以便於在 master server 出問題的時候接替其進行工作。

3. 數據存儲服務器:負責連接管理服務器,聽從管理服務器調度,提供存儲空間,併爲客戶提供數據傳輸。

4. 客戶端:通過 fuse 內核接口掛接遠程管理服務器上所管理的數據存儲服務器,看起來共享的文件系統和本地 unix 文件系統使用一樣的效果。

5. MFS 讀寫原理:    




clip_image004



clip_image006

第二部分:MFS 部署:

主機環境:RHEL6.0

selinux and iptables disabled

Master:192.168.0.66

Metalogger: 192.168.0.77

Chunkserver: 192.168.0.1 192.168.0.2

Client: 192.168.0.3

軟件下載: www . moosefs . org

生成 rpm,便於部署

# yum install gcc make rpm-build fuse-devel zlib-devel –y

# rpmbuild -tb mfs-1.6.26.tar.gz

# ls ~/rpmbuild/RPMS/x86_64

mfs-cgi-1.6.26-1.x86_64.rpm

mfs-master-1.6.26-1.x86_64.rpm

mfs-chunkserver-1.6.26-1.x86_64.rpm

mfs-metalogger-1.6.26-.x86_64.rpm mfs-client-1.6.26-1.x86_64.rpm

主控服務器 Master server 安裝:

# yum localinstall -y mfs-master-1.6.26-1.x86_64.rpm mfs-cgi-1.6.26-1.x86_64.rpm

# cd /etc

# cp mfsmaster.cfg.dist mfsmaster.cfg

此文件中凡是用#註釋掉的變量均使用其默認值,基本不需要就可以工作:

#WORKING_USER 和 WORKING_GROUP:是運行 master server 的用戶和組;

#SYSLOG_IDENT:是 master server 在 syslog 中的標識;

#LOCK_MEMORY:是否執行 mlockall()以避免 mfsmaster 進程溢出(默認爲 0); #NICE_LEVE:運行的優先級(如果可以默認是 -19; 注意: 進程必須是用 root 啓動);

#EXPORTS_FILENAME:被掛接目錄及其權限控制文件的存放位置

#TOPOLOGY_FILENAME : 定義 MFS 網絡拓撲結構的文件位置

#DATA_PATH:數據存放路徑,此目錄下大致有三類文件,changelog,sessions 和 stats;

#BACK_LOGS:metadata的改變 log 文件數目(默認是 50) ;

#BACK_META_KEEP_PREVIOUS:保存以前 mfs元數據的文件數,默認值是 1;

#REPLICATIONS_DELAY_INIT:延遲複製的時間(默認是 300s);

#REPLICATIONS_DELAY_DISCONNECT:chunkserver 斷開的複製延遲(默認是 3600);

# 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/MATOCL_LISTEN_HOST:用於客戶端掛接連接的 IP 地址(默認是*,代表任何 IP);

# MATOCU_LISTEN_PORT/MATOCL_LISTEN_PORT:用於客戶端掛接連接的端口地址(默認是 9421);

#CHUNKS_LOOP_CPS:chunks 的迴環每秒檢查的塊最大值,默認 100000;

# CHUNKS_LOOP_TIME :chunks 的迴環頻率(默認是:300 秒);

# CHUNKS_SOFT_DEL_LIMIT :一個 chunkserver 中可以刪除 chunks 的最大數,軟限 (默認:

10)

#CHUNKS_HARD_DEL_LIMIT:一個 chunkserver 中可以刪除 chunks 的最大數,硬限 (默認:

25)

# REPLICATIONS_DELAY_DISCONNECT:chunkserver 斷開後的複製延時(默認:3600 秒)

# CHUNKS_WRITE_REP_LIMIT:在一個循環裏複製到一個 chunkserver 的最大 chunk 數目(默認是 2)

# CHUNKS_READ_REP_LIMIT :在一個循環裏從一個 chunkserver 複製的最大 chunk 數目(默認是 10)

# REJECT_OLD_CLIENTS:彈出低於 1.6.0的客戶端掛接(0 或 1,默認是 0)

# deprecated:

# CHUNKS_DEL_LIMIT - use CHUNKS_SOFT_DEL_LIMIT instead

# LOCK_FILE - lock system has been changed, and this option is used only to search for old lockfile

# cp mfsexports.cfg.dist mfsexports.cfg

# vi mfsexports.cfg

192.168.0.0/24 / rw,alldirs,maproot=0

該文件每一個條目分爲三部分:

第一部分:客戶端的 ip 地址

第二部分:被掛接的目錄

第三部分:客戶端擁有的權限

地址可以指定的幾種表現形式:

* 所有的 ip 地址

A.B.C.D 單個 ip 地址

A.B.C.D/BITS IP 網絡地址/位數掩碼 A.B.C.D/E.F.G.H IP 網絡地址/子網掩碼 A.B.C.D-E.F.G.H IP 地址範圍

目錄部分需要注意兩點:

/ 標識 MooseFS 根;

. 表示 MFSMETA 文件系統

權限部分:    

ro

只讀模式共享

rw

讀寫方式共享

alldirs

許掛載任何指定的子目錄


maproot

映射爲 root,還是 指定的用戶


password

指定驗證密碼,客戶端掛載時使用

# cd /var/lib/mfs

# cp metadata.mfs.empty metadata.mfs

# chown nobody /var/lib/mfs

修改/etc/hosts 文件,增加下面的行:

192.168.0.66 mfsmaster

# mfsmaster start 啓動 master server

working directory: /var/lib/mfs lockfile created and locked initializing mfsmaster modules ... loading sessions ... file not found if it is not fresh installation then you have to restart all active mounts !!!

exports file has been loaded

mfstopology configuration file (/etc/mfstopology.cfg) not found - using defaults loading metadata ... create new empty filesystemmetadata 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

此時進入/var/lib/mfs 可以看到 moosefs 所產生的數據:

.mfsmaster.lock 文件記錄正在運行的 mfsmaster 的主進程 metadata.mfs, metadata.mfs.back MooseFS 文件系統的元數據 metadata的鏡像

changelog.*.mfsclip_image007是 MooseFS 文件系統元數據的改變日誌(每一個小時合併到 metadata.mfs 中一次)

Metadata 文件的大小是取決於文件數的多少(而不是他們的大小)。changelog 日誌的大小是取決於每小時操作的數目,但是這個時間長度(默認是按小時)是可配置的。

# mfscgiserv #啓動 CGI 監控服務

lockfile created and locked starting simple cgi server (host: any , port: 9425 , rootpath: /usr/share/mfscgi)

# cd /usr/share/mfscgi/

# chmod +x chart.cgi mfs.cgi

在瀏覽器地址欄輸入 http://192.168.0.66:9425 即可查看 master 的運行情況

元數據日誌服務器 Metalogger server 安裝:

# yum localinstall -y mfs-metalogger-1.6.26-1.x86_64.rpm

# cd /etc

# cp mfsmetalogger.cfg.dist mfsmetalogger.cfg 文件 mfsmetalogger.cfg 的修改是可選的:

# WORKING_USER = nobody

# WORKING_GROUP =

# SYSLOG_IDENT = mfsmetalogger

# LOCK_MEMORY = 0:是否執行 mlockall()以避免交換出 mfsmaster 進程(默認是 0,即 no);

# NICE_LEVEL = -19

# DATA_PATH = /var/lib/mfs

# BACK_LOGS = 50

# BACK_META_KEEP_PREVIOUS = 3

# META_DOWNLOAD_FREQ = 1

metadata 元數據下載間隔時間(默認是 24 小時,單位是小時,至多是 BACK_LOGS 的 1/2)

# MASTER_RECONNECTION_DELAY = 5 :在失去連接之後延遲多少秒重新連接 master

# MASTER_HOST = mfsmaster:連接 MooseFS master 主機的地址(默認是 mfsmaster)

# MASTER_PORT = 9419:連接 MooseFS master 主機的端口(默認是 9420) ;

# MASTER_TIMEOUT = 60:連接 master 的超時時間(默認 60 秒) ;

# deprecated, to be removed in MooseFS 1.7

# LOCK_FILE = /var/run/mfs/mfsmetalogger.lock

# mkdir /var/lib/mfs

# chown nobody /var/lib/mfs

# vi /etc/hosts

192.168.0.66 mfsmaster

# mfsmetalogger start

在/var/lib/mfs 目錄中可以看到從 master 上覆制來的元數據

changelog_ml.*.mfs 是 MooseFS 文件系統的元數據的 changelog 日誌(備份的 Master 的 Master 的 changelog 日誌)

metadata_ml.mfs.back 是從 Master 主機上下載的最新的完整 metadata.mfs.back 的拷貝 sessions.ml.mfs 是從 master 下載的最新的 sessions.mfs 文件拷貝。

Mfsmetalogger 並不能完美的接管 master server,在實際生產環境中使用 HA 解決 master 的單點

故障。

存儲塊服務器 Chunk servers 安裝:

# yum localinstall -y mfs-chunkserver-1.6.26-1.x86_64.rpm

# cd /etc/

# cp mfschunkserver.cfg.dist mfschunkserver.cfg

# WORKING_USER = nobody

# WORKING_GROUP =

# SYSLOG_IDENT = mfschunkserver

# LOCK_MEMORY = 0

# NICE_LEVEL = -19

# DATA_PATH = /var/lib/mfs

# MASTER_RECONNECTION_DELAY = 5:在失去連接之後延遲多少秒重新連接 master

# BIND_HOST = *:本地地址用於連接 mfsmaster(默認值是*,即默認的本地地址)

# MASTER_HOST = mfsmaster:master 服務器的主機名或是 ip 地址。

# MASTER_PORT = 9420

# MASTER_TIMEOUT = 60

# CSSERV_LISTEN_HOST = *:允許掛載的客戶端連接的 IP 地址(*允許全部)

# CSSERV_LISTEN_PORT = 9422:允許掛載的客戶端連接的端口

# HDD_CONF_FILENAME = /etc/mfshdd.cfg:分配給 MFS 使用的磁盤空間配置文件的位置

# HDD_TEST_FREQ = 10:塊的測試期(單位爲秒)

# deprecated, to be removed in MooseFS 1.7

# LOCK_FILE = /var/run/mfs/mfschunkserver.lock

# BACK_LOGS = 50

# CSSERV_TIMEOUT = 5

# cp mfshdd.cfg.dist mfshdd.cfg

# vi mfshdd.cfg 定義 mfs 共享點

/mnt/mfschunks1

/mnt/mfschunks2

# mount /dev/VolGroup/data1 /mnt/mfschunks1/

# mount /dev/VolGroup/data2 /mnt/mfschunks2/

# chown -R nobody:nobody /mnt/mfschunks1

# chown -R nobody:nobody /mnt/mfschunks2

修改/etc/hosts 文件,增加下面的行:

192.168.0.66 mfsmaster

mkdir /var/lib/mfs

chown nobody /var/lib/mfs

# mfschunkserver start

working directory: /var/lib/mfs lockfile created and locked initializing mfschunkserver modules ...

hdd space manager: path to scan: /mnt/mfschunks2/ hdd space manager: path to scan: /mnt/mfschunks1/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

現在再通過瀏覽器訪問 http://192.168.0.66:9425/ 應該可以看見這個 MooseFS 系統的全部信息, 包括主控 master 和存儲服務 chunkserver 。

客戶端 client 安裝:

# yum localinstall -y mfs-client-1.6.26-1.x86_64.rpm

# cd /etc

# cp mfsmount.cfg.dist mfsmount.cfg

# vi mfsmount.cfg 定義客戶端默認掛載

mfsmaster=mfsmaster /mnt/mfs

# mfsmount

# df -h

...

mfsmaster:9421 2729728 0 2729728 0% /mnt/mfs

MFS 測試:

在 MFS 掛載點下創建兩個目錄,並設置其文件存儲份數:

# cd /mnt/mfs

# mkdir dir1 dir2

# mfssetgoal -r 2 dir2/ 設置在 dir2 中文件存儲份數爲兩個,默認是一個 dir2/:

inodes with goal changed: 1 inodes with goal not changed: 0 inodes with permission denied: 0

對一個目錄設定“goal”,此目錄下的新創建文件和子目錄均會繼承此目錄的設定,但不會改變已經存在的文件及目錄的 copy 份數。但使用-r 選項可以更改已經存在的 copy 份數。

拷貝同一個文件到兩個目錄

# cp /etc/passwd dir1

# cp /etc/passwd dir2

查看文件信息

# mfsfileinfo dir1/passwd dir1/passwd: chunk 0: 0000000000000001_00000001 / (id:1 ver:1)

copy 1: 192.168.0.2:9422 # mfsfileinfo dir2/passwd dir2/passwd: chunk 0: 0000000000000002_00000001 / (id:2 ver:1)

copy 1: 192.168.0.1:9422 copy 2: 192.168.0.2:9422

關閉 mfschunkserver2 後再查看文件信息

# mfsfileinfo dir1/passwd dir1/passwd: chunk 0: 0000000000000001_00000001 / (id:1 ver:1) no valid copies !!! # mfsfileinfo dir2/passwd dir2/passwd: chunk 0: 0000000000000002_00000001 / (id:2 ver:1) copy 1: 192.168.0.1:9422

啓動 mfschunkserver2 後,文件回覆正常。

恢復誤刪文件

# rm -f dir1/passwd # mfsgettrashtime dir1/ dir1/: 86400

文件刪除後存放在“ 垃圾箱”中的時間稱爲隔離時間, 這個時間可以用 mfsgettrashtime 命令來查看,用 mfssettrashtime 命令來設置,單位爲秒,默認爲 86400 秒。

# mkdir /mnt/mfsmeta

# mfsmount -m /mnt/mfsmeta/ -H mfsmaster

掛載 MFSMETA 文件系統,它包含目錄 trash (包含仍然可以被還原的刪除文件的信息)和 trash/undel (用於獲取文件)。把刪除的文件,移到/ trash/undel 下,就可以恢復此文件。

# cd /mnt/mfsmeta/trash

# mv 00000004 \|dir1\|passwd undel/

到 dir1 目錄中可以看到 passwd 文件恢復

在 MFSMETA 的目錄裏,除了 trash 和 trash/undel 兩個目錄,還有第三個目錄 reserved,該目

錄內有已經刪除的文件,但卻被其他用戶一直打開着。在用戶關閉了這些被打開的文件後, reserved 目錄中的文件將被刪除,文件的數據也將被立即刪除。此目錄不能進行操作。

修改 linux 下最大文件描述符的限制:在進行大量小文件寫時,可能會出現了一個嚴重錯誤,有可能和操作系統文件描述符有關。操作系統默認文件描述符爲 1024.

1.6.26 版本默認爲 100000 建議上線時,master 和 chunker 修改文件描述符系統級限制:它是限制所有用戶打開文件描述符的總和,可以通過修改內核參數來更改該限制:

# vi /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

在 kernel 2.6 之前的版本中,file-nr 中的值由三部分組成,分別爲:1.已經分配的文件句柄數,2. 已經分配單沒有使用的文件句柄數,3.最大文件句柄數。但在 kernel 2.6 版本中第二項的值總爲 0,這並不是一個錯誤,它實際上意味着已經分配的文件句柄無一浪費的都已經被使用了,file-max 的值是 linux 內核可以分配的最大文件句柄數。如果你看到了很多關於打開文件數已經達到了最大值的錯誤信息,你可以試着增加該值的限制。file-max 的默認值大概是系統內存的 10 %(系統內存以 kb 計算)快照

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

# mfsmakesnapshot source … destination

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

文件快照可以用 mfsappendchunks,例如:

# mfsappendchunks destination-file source-file …

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

爲了安全停止 MooseFS 集羣,建議執行如下的步驟:    

# umount -l /mnt/mfs

#客戶端卸載 MooseFS 文件系統

# mfschunkserver stop

#停止 chunk server 進程

# mfsmetalogger stop

#停止 metalogger 進程

#mfsmaster stop 安全的啓動 MooseFS 集羣:

#停止主控 master server 進程

# 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 份了。

# mfssetgoal -r 1 bigfile bigfile:

inodes with goal changed: 1 inodes with goal not changed: 0 inodes with permission denied: 0

# mfsfileinfo bigfile bigfile:

chunk 0: 0000000000000010_00000001 / (id:16 ver:1)

copy 1: 192.168.0.1:9422

chunk 1: 0000000000000011_00000002 / (id:17 ver:2)

copy 1: 192.168.0.2:9422

# mfssetgoal -r 2 bigfile bigfile:

inodes with goal changed: 1 inodes with goal not changed: 0 inodes with permission denied: 0

# mfsfileinfo bigfile bigfile:

chunk 0: 0000000000000010_00000001 / (id:16 ver:1)

copy 1: 192.168.0.1:9422 copy 2: 192.168.0.2:9422

chunk 1: 0000000000000011_00000002 / (id:17 ver:2)

copy 1: 192.168.0.1:9422 copy 2: 192.168.0.2:9422

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

mfsmaster 熱備:

解決方案:drbd+corosync+pacemaker

drbd 配置:

# cat /etc/drbd.d/mfs.res resource mfsdata { meta-disk internal; device /dev/drbd1; syncer { verify-alg sha1;

}

on server89.example.com { disk /dev/vgdrbd/mfs;

address 192.168.0.189:7789;

}

on server87.example.com { disk /dev/vgdrbd/mfs;

address 192.168.0.187:7789;

}

}

corosync 配置:

# cat /etc/corosync/corosync.conf # Please read the corosync.conf.5 manual page compatibility: whitetank

totem { version: 2 secauth: off threads: 0 interface { ringnumber: 0 bindnetaddr: 192.168.0.0 mcastaddr: 226.94.2.1

mcastport: 5408

ttl: 1

}

}

logging {

fileline: off to_stderr: no to_logfile: yes to_syslog: yes logfile: /var/log/cluster/corosync.log debug: off timestamp: on logger_subsys { subsys: AMF debug: off

}

}

amf { mode: disabled

}

service { name: pacemaker

ver: 0 }

mfs 啓動腳本

# cat /etc/init.d/mfs

#!/bin/bash

#

# Init file for the MooseFS master service

#

# chkconfig: - 92 84

#

# description: MooseFS master

#

# processname: mfsmaster

# Source function library.

# Source networking configuration.

. /etc/init.d/functions

. /etc/sysconfig/network

# Source initialization configuration.

# Check that networking is up.

[ "${NETWORKING}" == "no" ] && exit 0

[ -x "/usr/sbin/mfsmaster" ] || exit 1

[ -r "/etc/mfsmaster.cfg" ] || exit 1

[ -r "/etc/mfsexports.cfg" ] || exit 1

RETVAL=0

prog="mfsmaster" datadir="/var/lib/mfs" mfsbin="/usr/sbin/mfsmaster" mfsrestore="/usr/sbin/mfsmetarestore"

start () {

echo -n $"Starting $prog: "

$mfsbin start >/dev/null 2>&1 if [ $? -ne 0 ];then

$mfsrestore -a >/dev/null 2>&1 && $mfsbin start >/dev/null 2>&1 fi

RETVAL=$?

echo

return $RETVAL

}

stop () {

echo -n $"Stopping $prog: "

$mfsbin -s >/dev/null 2>&1 || killall -9 $prog #>/dev/null 2>&1

RETVAL=$? echo

return $RETVAL

}

restart () { stop start }

reload () {

echo -n $"reload $prog: " $mfsbin reload >/dev/null 2>&1

RETVAL=$? echo

return $RETVAL

}

restore () {

echo -n $"restore $prog: " $mfsrestore -a > /dev/null 2>& 1

RETVAL=$? echo

return $RETVAL

}

case "$1" in start)

start

;;

stop) stop

;;

restart)

restart

;;

reload)

reload

;;

restore)

restore

;;

status) status $prog RETVAL=$?

;;

*)

echo $"Usage: $0 {start|stop|restart|reload|restore|status}"

RETVAL=1 esac exit $RETVAL

pacemaker 配置:

node server87.example.com node server89.example.com

primitive MFSdata ocf:linbit:drbd params drbd_resource="mfsdata" primitive MFSfs ocf:heartbeat:Filesystem \

params device="/dev/drbd1" directory="/var/lib/mfs" fstype="ext4" primitive MFSmaster lsb:mfs op monitor interval="30s" primitive vip ocf:heartbeat:IPaddr2 \

params ip="192.168.0.163" cidr_netmask="24" \ op monitor interval="30s" \ group MFSgroup MFSfs vip MFSmaster ms MFSdataclone MFSdata \

meta master-max="1" master-node-max="1" clone-max="2" clone-node-max="1"

notify="true" target-role="Started" colocation mfs-with-drbd inf: MFSgroup MFSdataclone:Master order mfs-after-drbd inf: MFSdataclone:promote MFSgroup:start

property $id="cib-bootstrap-options" \ stonith-enabled="false" \

dc-version="1.1.6-3.el6-a02c0f19a00c1eb2527ad38f146ebc0834814558" cluster-infrastructure="openais" \ expected-quorum-votes="2" \ no-quorum-policy="ignore" \ start-failure-is-fatal="false"

第三部分:實驗操作

實驗環境:

實驗主機:172.25.0.1(master)

172.25.0.2(chunkserver)

172.25.0.3(chunkserver)

172.25.0.251(client)

##下載mfs源碼包,創建rpm包,在不同服務器上安裝所需包

clip_image009

#命令rpmbiuld爲系統命令,可以直接安裝(yum install –y rpm-build)

#在創建rpmnn包過程中會有各種依賴關係,可以到pkgs.org上下載所需要的包

##在master端(節點1),進入剛剛創建的rpm包目錄,安裝master端包

clip_image011

##在chunkserver端(節點2,3),安裝所需包,並且解決依賴性

clip_image013

##在客戶端(節點251)安裝client,當然,在部署中還需要元數據服務器,這裏就不做累述,只需安裝相應包,修改配置文件,指向master,開啓就好了。

##在master端可以查看管理服務器的配置文件

clip_image015

##這裏邊註釋掉的代表默認,需要注意的是和mfs相關的文件的用戶只mfs,所以後面會修改文件的用戶和組

clip_image017

##查看元數據配置文件,這裏是允許所有人有讀寫權限

clip_image019

clip_image021

##master上數據存放目錄,當沒有medadata.mfs時,可以用*。*。empty來複制一份,當master啓動後,會在後面加上.back,當沒有數據傳輸時,關閉master,會變成.mfs,當正在傳輸數據,master異常掉線,回覆不了時,可以將.back去掉,這樣就可以恢復了

clip_image023

##然後就可以啓動master了,沒有啓動腳本,只需要master就可以啓動(沒有路徑限制)

clip_image025

##client監聽master的9421端口,master監聽chunkserver的9420端口,元數據日誌服務器監聽master的9419端口

clip_image027

#切換到/usr/share/mfscgi目錄下,開啓mfscgiserv這樣就可以用圖形界面來看整個分佈式文件系統的動態情況了

clip_image029

##瀏覽器訪問會出現下面的情況,找不到master,這是因爲mfs文件系統是通過主機名來通信的,所以在所有主機的/etc/hosts中0.1對應的主機名加進

clip_image031

##在master的配置文件中有提示,指明需要將master所在主機的解析中加進去

clip_image033

##然後是存儲端的配置

首先在兩臺主機上各增加一快磁盤,這裏的磁盤可以直接做成標準的磁盤,也可以做成Lvm邏輯卷,都行,標準磁盤滿後,可以加進磁盤,增加掛載點來繼續工作,邏輯卷的話,就可以直接擴容,這裏我們將節點2做成標準分區,將節點三做成邏輯卷

#節點2,創建分區n>>是新建,

clip_image035

#創建完成,退出之前,用p可以查看創建好的分區

clip_image037

##格式化

clip_image039

##掛載

clip_image041

##編輯配置文件,告訴

首先chunkserver的用戶和組是mfs,需要修改數據存放目錄的權限,包括/var/lib/mfs和磁盤掛載點/mnt/chunk1的權限

clip_image043

clip_image045

##實現磁盤的永久掛載

clip_image047

clip_image049

clip_image051

##配置文件中還指明瞭作爲存貯服務器的主機名和本存儲服務器制定的master服務器的主機名,只需要在解析中加進ip對應的mfsmaster就可以找到了,當然如果有dns服務器就可以省去這些麻煩了

clip_image053

clip_image055

##還指明瞭掛載點文件名

clip_image057

##將掛載點加進去

clip_image059

clip_image061

##然後開啓存儲服務器

clip_image063

##網頁上就可以看到加進來的磁盤

clip_image065

##mfs以塊存儲,會將磁盤換份爲256個大塊,每個塊的大小是64M

##節點3中做類似的步驟,唯一的區別就是將磁盤標籤換成8e,

clip_image067

clip_image069

#創建邏輯卷

clip_image071

clip_image073

clip_image075

clip_image077

clip_image079

##然後就是將磁盤永久掛載,修改磁盤掛載點的權限,,告訴chunkserver掛載點在哪,做好解析,開啓服務,最後就完成了

##在客戶端,安裝client軟件,然後在配置文件中將自己的掛載目錄放進去,做好解析,開啓,就完成了

#這是安裝完軟件的結果

clip_image081

#在/mnt下創建目錄,不必修改權限

clip_image083

#修改配置文件

clip_image085

clip_image087

#做好解析

clip_image089

##這樣就真正完成了分佈式文件系統的構建

clip_image091

##測試mfs

#在client,掛載目錄下創建兩個目錄,

clip_image093

##將目錄1中數據只存一份

clip_image095

##確實只放在了節點3中

clip_image097

##而節點2中就不同,會存兩份

clip_image099

##這樣當存儲設備節點3壞壞掉之後(我們以手動停掉爲例),client存放在目錄2中的數據不會有影響,而目錄一中的數據將會丟失

clip_image101

clip_image103

##將節點三的存儲回覆正常,client都又可以看到數據

##圖形界面能夠更清晰的看到各個節點的chunk(塊)數

clip_image105

##需要注意的是對於空文件,mfs文件系統會記錄塊的個數,但是不會消耗存儲空間

clip_image107

##一塊64M,100M將會被分成兩塊

clip_image109

##再寫進500M

clip_image111

##圖形界面上顯示了存儲的塊的個數以及寫入的速度,但是,不會佔用空間

clip_image113

##在存儲節點上,掛載目錄大小依然不變,但是每個塊中確實有存儲的信息

clip_image115

##這就是放進空文件的原因,下面我們在客戶端往目錄一中放一個鏡像

clip_image117

##這次磁盤使用情況就會變化

clip_image119

##mfsinfo 鏡像名字,就會看到鏡像被均勻的分配在兩個chunkserver上

clip_image121

##刪除數據的恢復,例如百度雲,在我們刪除數據後,其實並不是完全刪除,都會有一個防止誤刪機制,一般會保存3-5天,當然只要你願意交錢,百度會爲你保存更長的時間

##查看目錄一中文件能夠在垃圾箱中存放的時間,爲一天(86400秒)

clip_image123

##掛載元數據目錄

clip_image125

clip_image127

##在元數據目錄中會有存放刪除的文件的目錄trash

clip_image129

##只要將我們不想刪除的文件重新放進trash中的undel中就好了

clip_image131

##我們將目錄一中的passwd刪除

clip_image133

##用find命令找到passwd

clip_image135

##將其移動到undel中,這樣就又可以在目錄一中查看passwd了

clip_image137

clip_image139

##元數據服務器的作用是在master異常關閉後重啓後恢復數據

clip_image141

##master作爲整個分佈式文件系統的瓶頸,我們可以用高可用實現高可用

以前我們用過幾個高可用套件,其中drbd(網絡raid)+heartbeat最簡單

Pacemaker比較複雜,有資源監控,而heartbeat只是純心跳

##這裏我們以pacemaker+corosync+iscsi搭建master端的高可用,節點一盒節點四作爲master實現高可用,iscsi作爲HA集羣的一部分,我們這裏用251作爲服務器(安裝scsi),節點一和節點四作爲iscsi客戶端安裝iscsi

clip_image143

##在iscsi服務器端,安裝完軟件後,編輯配置文件,將磁盤和客戶端ip加進來,記得磁盤必須是沒有格式化的磁盤,只是做存儲

clip_image145

clip_image147

##開啓iscsi

clip_image149

##查看iscsi集羣狀態,要有新加進來的磁盤和ip

clip_image151

clip_image153

##在兩個客戶端,都安裝iscsi,並且發現,加載iscsi磁盤

clip_image155

clip_image157

clip_image159

##這是用fdisk –l可以查看到可以用的磁盤,這裏就包括iscsi磁盤

clip_image161

##掛載,這裏是我們之前所做數據庫時的iscsi,將裏邊的數據刪除

clip_image163

##將mfs的數據存放進iscsi中

clip_image165

clip_image167

##當然在做這之前需要將master停掉,以防止數據丟失

clip_image169

##停掉後,這裏我們將cp過來的數據刪除,再進行cp,主要的區別就是.mfs 和.mfs.back區別

clip_image171

##對於要寫進數據的目錄和文件一定要記得改權限

clip_image173

##將iscsi掛載到master的數據目錄下面,並開啓master

clip_image175

##

clip_image177

##關閉

clip_image179

##寫入mfs啓動腳本

clip_image181

clip_image183

##當然,上面的腳本需要修改

clip_image185

##

clip_image187

##現在查看進程,master已經開啓,然後關閉,將啓動腳本cp給節點4

clip_image189

##當然也要在節點4上安裝master軟件包

clip_image191

##卸載

clip_image193

##發現加載

clip_image195

##掛載

clip_image197

##兩邊mfs用戶的uid和gid要一樣,這裏節點一 是498,499,節點四是497,498需要修改成一樣的,節點一上的zabbix用戶佔據了498

clip_image199

clip_image201

##現在在251上可以看到iscsi狀態

clip_image203

##

clip_image205

##

clip_image207

##然後,在節點1和4上安裝pacemaker,需要配置yum源

clip_image209

##然後,在新配的yum源中能夠發現7509個包

clip_image211

##

clip_image213

##然後安裝pacemaker和上面下載的兩個包,節點4上做相同的做法

##

clip_image215

##修改下面這一行,並在最後一行增加服務

clip_image217

clip_image219

##cp給節點4

clip_image221

##開啓

clip_image223

clip_image225

clip_image227

##

clip_image229

##在真機上查看fence的key

clip_image231

clip_image233

##將key拷貝給節點1和4,沒有目錄,要先建立

clip_image235

clip_image237

##

clip_image239

##

clip_image241

##安裝fence

clip_image243

clip_image245

clip_image247

##配置

clip_image249

clip_image251

##查看

clip_image253

##繼續配置

clip_image255

##這時開啓了(節點4中查看)

clip_image257

##增加虛擬ip

clip_image259

##查看

clip_image261

##節點2,3上關閉

clip_image263

##將VIP對應mfsmaster主機(在所有mfs節點上)

clip_image265

##

clip_image267

##

clip_image269

##將存儲節點,客戶端服務都打開

clip_image271

##寫進大文件

clip_image273

##本來是節點4在作爲master,現在讓他靠邊

clip_image275

##在節點1上查看

clip_image277

clip_image279

##節點1接管了

##再將節點4上線,會自動回切

clip_image281

clip_image283

#

clip_image285

#至此就完成了高可用部分。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章