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。这样将会丢失那些正在传输的数据。
本文转自 Taxing祥 51CTO博客，原文链接:http://blog.51cto.com/12118369/1957602
