前言:
MooseFS是一个具有容错性的网络分布式文件系统。它把数据分散存放在多个物理服务器上,而呈现给用户的则是一个统一的资源。
一、MFS 介绍
1.1 MFS 概述
- 分布式文件系统(Distributed File System) 是指文件系统管理的物理存储资源不一
定直接连接在本地节点上,而是通过计算机网络与节点相连。简单来说就是把一些分散的(分
布在局域网内各个计算机上) 共享文件夹, 集合到一个文件夹内(虚拟共享文件夹)。 对于
用户来说, 要访问这些共享文件夹时, 只要打开这个虚拟共享文件夹, 就可以看到所有链接
到虚拟共享文件夹内的共享文件夹, 用户感觉不到这些共享文件是分散于各个计算机上的。
分布式文件系统的好处是集中访问、 简化操作、 数据容灾、 提高文件存取性能
1.2 MFS特性
- ① 通用文件系统,不需要修改上层应用就可以使用
- ② 可以在线扩容,体系架构可伸缩性极强
- ③ 部署简单
- ④ 高可用,可设置任意的文件冗余程度(提供比raid1+0更高的冗余级别,不会影响读写性能)
- ⑤ 可回收在指定时间内删除的文件(“回收站”提供的是系统级别的服务,不怕误操作了,提供类似oralce 的闪回等高级dbms的即时回滚特性)
- ⑥ 提供netapp,emc,ibm等商业存储的snapshot特性(可以对整个文件甚至在正在写入的文件创建文件的快照)
- ⑦ google filesystem的一个c实现
- ⑧ 提供web gui监控接口
1.2.1 MFS优势
- ① 集中访问
- ② 简化操作
- ③ 数据容灾
- ④ 提高文件存储性能
1.3 MFS文件系统组成
- 元数据服务器(Master): 在整个体系中负责管理文件系统, 维护元数据
- 元数据日志服务器(MetaLogger): 备份 Master 服务器的变化日志文件, 文件类型为 changelog_ml.*.mfs。 当 Master 服务器数据丢失或者损坏,可以从日志服务器中取得文件恢复
- 数据存储服务器(Chunk Server): 真正存储数据的服务器。 存储文件时, 会把文件分块保存, 并在数据服务器之间复制, 数据服务器越多, 能使用的“容量” 就越大, 可靠性就越高, 性能越好。
- 客户端(Client): 可以像挂载 NFS 一样挂载 MFS 文件系统, 其操作是相同的。
1.4 MFS 工作读写原理
-
MFS工作流程图
-
MFS工作流程图(简易版)
- MFS 读写原理\处理过程
- MFS 读取数据过程
- ① client 当需要一个数据时,首先向master server发起查询请求;
- ② 管理服务器检索自己的数据,获取到数据所在的可用数据服务器位置 (IP地址 |port端口|chunk编号)
- ③ 管理服务器将数据服务器的地址发送给客户端
- ④ 客户端向具体的数据服务器发起数据获取请求
- ⑤ 数据服务器将数据发送给客户端
- MFS 写数据过程
- ① 当客户端又数据写入的需求时,首先向管理服务器提供文件元数据信息请求存储地址(元数据信息如:文件名|大小|份数等)
- ② 管理服务器与 Chunk Server 进行交互(只有当所需的分块 Chunks 存在的时候才进行这个交互),
但管理服务器只在某些服务器创建新的分块Chunks,创建成功后由Servers 告知元数据服务器操作成功 - ③ 管理服务器告知客户端, 可以在哪个 Chunk Server 的哪些 Chunks 写入数据。
- ④ 客户端向指定的 Chunk Server 写入数据
- ⑤ 该 Chunk Server 与其他 Chunk Server 进行数据同步, 同步成功后 Chunk Server 告知客户端数据写入成功
- ⑥ 客户端将此次写完成结束信号和一些信息发送到管理服务器来更新文件的长度和最后修改时间
二、MFS实验
2.1 实验环境
2.2 实验思路
- ① 搭建MFSmaster
- ② 搭建MFS日志服务器
- ③ 搭建chunk 存储端
- ④ 使用MFS 挂载到客户端
- ⑤ 创建MFS监控
- ⑥ 学习MFS维护及灾难恢复
2.3 配置环境
- 所有服务器关闭防火墙、核心防护、配置yum仓库及hosts映射
#修改所有服务器主机名
hostnamectl set-hostname Master
su
hostnamectl set-hostname MetaLogger
su
hostnamectl set-hostname Chunk1
su
hostnamectl set-hostname Chunk2
su
hostnamectl set-hostname Chunk3
su
hostnamectl set-hostname Client
su
[root@master ~]# vim /etc/hosts
#在行为插入以下内容
192.168.226.128 Master
192.168.226.132 MetaLogger
192.168.226.133 Chunk1
192.168.226.134 Chunk2
192.168.226.148 Chunk3
192.168.226.167 Client
-----》wq
#安装编译器
[root@master ~]# yum -y install gcc zlib-devel
2.4 搭建Master服务
- 创建用户并编译安装源码包
[root@master ~]# mount.cifs //192.168.226.1/LAMP-C7 /mnt
Password for root@//192.168.226.1/LAMP-C7:
[root@master mnt]# cd /mnt
[root@master mnt]# tar xzvf moosefs-3.0.100-1.tar.gz -C /opt/
[root@master mnt]# cd /opt/moosefs-3.0.100/
[root@master moosefs-3.0.100]# ./configure \ #配置
> --prefix=/usr/local/mfs \ #指定安装目录
> --with-default-user=mfs \ #指定运行用户
> --with-default-group=mfs \ #指定运行组
> --disable-mfschunkserver \ #禁用chunk功能
> --disable-mfsmount #禁用mfsnount功能
[root@master moosefs-3.0.100]# make && make install
.......省略部分内容
- 复制master服务器配置文件
[root@master moosefs-3.0.100]# cd /usr/local/mfs/etc/mfs/
#复制master服务器mfs配置文件
[root@master mfs]# cp mfsmaster.cfg.sample mfsmaster.cfg
[root@master mfs]# cp mfsexports.cfg.sample mfsexports.cfg
[root@master mfs]# cp mfstopology.cfg.sample mfstopology.cfg
[root@master mfs]# cd /usr/local/mfs/var/mfs/
[root@master mfs]# cp metadata.mfs.empty metadata.mfs
#分配时间
[root@master mfs]# chown mfs:mfs /usr/local/mfs/var/mfs
#启动服务
[root@master mfs]# /usr/local/mfs/sbin/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 ...
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 mfs]# netstat -anpt | grep mfs
tcp 0 0 0.0.0.0:9419 0.0.0.0:* LISTEN 9202/mfsmaster
tcp 0 0 0.0.0.0:9420 0.0.0.0:* LISTEN 9202/mfsmaster
tcp 0 0 0.0.0.0:9421 0.0.0.0:* LISTEN 9202/mfsmaster
2.5 搭建MetaLogger日志服务器
- 安装编译过程与master服务器一致,此处略过
- 复制metalogger 主配置文件模板并进行编辑
[root@metalogger moosefs-3.0.100]# cd /usr/local/mfs/etc/mfs
[root@metalogger mfs]# ls
mfsexports.cfg.sample mfsmetalogger.cfg.sample
mfsmaster.cfg.sample mfstopology.cfg.sample
[root@metalogger mfs]# cp mfsmetalogger.cfg.sample mfsmetalogger.cfg
[root@metalogger mfs]# vim mfsmetalogger.cfg
#52行 更改master的IP
MASTER_HOST = 192.168.226.128
- 启动MFS服务
[root@metalogger mfs]# /usr/local/mfs/sbin/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]# netstat -anpt | grep mfs
tcp 0 0 192.168.226.132:52024 192.168.226.128:9419 ESTABLISHED 29267/mfsmetalogger
2.6 搭建 Chunk 存储服务器
- 安装编译过程与master服务器基本一致,只有配置项有所不同,配置内容如下:
./configure \
--prefix=/usr/local/mfs \
--with-default-user=mfs \
--with-default-group=mfs \
--disable-mfsmaster \ #关闭master功能
--disable-mfsmount
- 三台chunk 节点服务器操作相同,此处只演示chunk1的节点操作
- 复制mfschunk 主配置文件模板并修改
[root@chunk1 moosefs-3.0.100]# cd /usr/local/mfs/etc/mfs/
[root@chunk1 mfs]# ls
mfschunkserver.cfg.sample mfshdd.cfg.sample mfsmetalogger.cfg.sample
mfsexports.cfg.sample mfsmaster.cfg.sample mfstopology.cfg.sample
[root@chunk1 mfs]# cp mfschunkserver.cfg.sample mfschunkserver.cfg
[root@chunk1 mfs]# cp mfshdd.cfg.sample mfshdd.cfg
[root@chunk1 mfs]# vi mfschunkserver.cfg
MASTER_HOST = 192.168.226.128
[root@chunk1 mfs]# vim mfshdd.cfg
#添加挂载点
/data
#创建挂载点
[root@chunk1 mfs]# mkdir /data
#给与属主属组
[root@chunk1 mfs]# chown -R mfs:mfs /data
- 启动MFS服务
[root@chunk1 mfs]# /usr/local/mfs/sbin/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: /data/
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@chunk1 mfs]# netstat -anpt | grep mfs
tcp 0 0 0.0.0.0:9422 0.0.0.0:* LISTEN 49840/mfschunkserve
tcp 0 0 192.168.226.133:39072 192.168.226.128:9420 ESTABLISHED 49840/mfschunkserve
[root@chunk1 mfs]#
2.7 部署client客户端
- 安装FUSE
[root@client ~]# mount.cifs //192.168.226.1/LAMP-C7 /mnt
Password for root@//192.168.226.1/LAMP-C7:
[root@client ~]# cd /mnt
[root@client mnt]# tar xzvf fuse-2.9.2.tar.gz -C /opt
[root@client mnt]# cd /opt/fuse-2.9.2/
[root@client fuse-2.9.2]# ./configure
[root@client fuse-2.9.2]# make && make install
[root@client fuse-2.9.2]# echo "export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:$PKG_CONFIG_PATH" >> /etc/profile
[root@client fuse-2.9.2]# source /etc/profile
- 安装MFS客户端
[root@client fuse-2.9.2]# cd /mnt
[root@client mnt]# tar zxvf moosefs-3.0.100-1.tar.gz -C /opt
[root@client mnt]# cd /opt/moosefs-3.0.100
[root@client moosefs-3.0.100]#
./configure \
--prefix=/usr/local/mfs \
--with-default-user=mfs \
--with-default-group=mfs \
--disable-mfsmaster \
--disable-mfschunkserver \
--enable-mfsmount
[root@client moosefs-3.0.100]# make && make install
- 挂载MFS文件系统
[root@client moosefs-3.0.100]# cd
#创建挂载点
[root@client ~]# mkdir /opt/mfs
#加载fuse模块到内核
[root@client ~]# modprobe fuse
#指向master服务器地址
[root@client ~]# /usr/local/mfs/bin/mfsmount /opt/mfs -H 192.168.226.128
mfsmaster accepted connection with parameters: read-write,restricted_ip,admin ; root mapped to root:root
[root@client ~]# df -hT
192.168.226.128:9421 fuse.mfs 60G 14G 47G 22% /opt/mfs
#挂载成功
- MFS优化
- MFS 在客户端安装完毕后, 会生成/usr/local/mfs/bin/目录, 在这个目录下有很多命令是用户所需要的。 为了方便使用这些命令, 可将/usr/local/mfs/bin 加入到环境变量中
[root@client ~]# vim /etc/profile
#在威航添加以下内容
export PATH=/usr/local/mfs/bin:$PATH
#刷新生效
[root@client bin]# source /etc/profile
#mfsgetgoal 命令 用来设置文件被复制的份数,-r选项可以对整个目录进行递归,goal 是指文件被复制的份数
[root@client bin]# mfsgetgoal -r /opt/mfs
/opt/mfs:
directories with goal 2 : 1
#生产环境 chunk server 节点数量应至少大于2,文件副本数小于等于chunk server 服务器数量
[root@client opt]# mfssetgoal -r 3 /opt/mfs
/opt/mfs:
inodes with goal changed: 1
inodes with goal not changed: 0
inodes with permission denied: 0
#创建文件测试
[root@client opt]# cd /opt/mfs
[root@client mfs]# touch aaa.txt
m[root@client mfs]# mfsgetgoal aaa.txt
aaa.txt: 3
[root@client mfs]#
2.8 开启MFS监控、访问测试
- master节点服务器启动监控
[root@master ~]# /usr/local/mfs/sbin/mfscgiserv
-
mfscgiserv是用python编写的一个web服务器,其监听端口是9425,可以在masster server 上通过 /usr/local/mfs/sbin/mfscgiserv来启动,用户利用浏览器就可以完全监控所有客户挂接、Chunk server、Master server等。
-
访问测试
① 用宿主机访问master页面(http://192.168.226.128:9425)
② 访问http://192.168.226.128:9425/mfs.cgi?masterhost=master
三、MFS其他测试
- master服务器启动后,metalogger、chunker、client三个元素都能自动与master建立连接。
3.1 MFS启动顺序
1、正常启动顺序:matser---chunker---metalogger---client
2、关闭顺序:client---chunker---metalogger---master
实验环境中中无论如何顺序启动或关闭,未见任何异常。
3.2 断电测试
1、使用mfsmetarestore -a修复才能启动,如果无法修复,使用metalogger上的备份日志进行恢复。(几次测试发现:如果mfsmetarestore -a无法修复,则使用metalogger也无法修复)。
2、强制使用metadata.mfs.back创建metadata.mfs,可以启动master,但应该会丢失1小时的数据。
3、mfs开发小组针对此问题回信:明确表示会丢失故障点到上一个整点之间的数据。和之前我猜测的一致。因为对mfs的操作日志都记录到changelog.0.mfs里面。changelog.0.mfs每小时合并一次到metadata.mfs中,如果突然断电,则changelog.0.mfs里面的信息就没有合并到metadata中,强制使用metadata.mfs.back创建metadata.mfs,就会导致丢失changelog.0.mfs里的数据。
4、直接断电测试过程,使用mfsmetarestore –a无法修复,使用metalogger也无法修复的情况较少发生。5次只有一次无法修复。
3.3 chunker的维持
- chunker的块(chunks)能够自动复制或删除
1、对一个目录设定“goal”,此目录下的新创建文件和子目录均会继承此目录的设定,但不会改变已经存在的文件及目录的copy份数。但使用-r选项可以更改已经存在的copy份数。
2、goal设置为2,只要两个chunker有一个能够正常运行,数据就能保证完整性。
假如每个文件的goal(保存份数)都不小于2,并且没有under-goal文件(可以用mfsgetgoal –r和mfsdirinfo命令来检查),那么一个单一的chunkserver在任何时刻都可能做停止或者是重新启动。以后每当需要做停止或者是重新启动另一个chunkserver的时候,要确定之前的chunkserver被连接,而且要没有under-goal chunks。
3、实际测试时,传输一个大文件,设置存储2份。传输过程中,关掉chunker1,这样绝对会出现有部分块只存在chunker2上;启动chunker1,关闭chuner2,这样绝对会有部分块只存在chuner1上。
把chunker2启动起来。整个过程中,客户端一直能够正常传输。
4、在客户端查看,一段时间内,无法查看;稍后一段时间后,就可以访问了。文件正常,使用mfsfileinfo 查看此文件,发现有的块分布在chunker1上,有的块分布在chuner2上。
使用mfssetgoal 2和mfssetgoal -r 2均不能改变此文件的目前块的现状。
但使用mfssetgoal -r 1后,所有块都修改成1块了,再mfssetgoal -r 2,所有块都修改成2份了。
5、测试chunker端,直接断电情况下,chunker会不会出问题:
①、数据传输过程中,关掉chunker1,等待数据传输完毕后,开机启动chunker1.
chunker1启动后,会自动从chunker2复制数据块。整个过程中文件访问不受影响。
②、数据传输过程中,关掉chunker1,不等待数据传输完毕,开机启动chunker1.
chunker1启动后,client端会向chunker1传输数据,同时chunker1也从chunker2复制缺失的块。
6、如果有三台chunker,设置goal=2,则随机挑选2个chunker存储。
7、如果有一个chunker不能提供服务,则剩余的2个chunker上肯定有部分chunks保存的是一份。则在参数(REPLICATIONS_DELAY_DISCONNECT = 3600)后,只有一份的chunks会自动复制一份,即保存两份。
保存两份后,如果此时坏掉的chunker能够提供服务后,此时肯定有部分chunks存储了三份,mfs会自动删除一份。
8、当我增加第三个服务器做为额外的chunkserver时,虽然goal设置为2,但看起来第三个chunkserver从另外两个chunkserver上复制数据。
9、硬盘空间平衡器是独立地使用chunks的,因此一个文件的chunks会被重新分配到所有的chunkserver上。
3.4 chunks修复(mfsfilerepair)
1、mfsfilerepair用来处理坏文件(如读操作引起的I/O错误),使文件能够部分可读。在丢失块的情况下使用0对丢失部分进行填充;在块的版本号(version)不匹配时设置块的版本号为master上已知的能在chunkerservers找到的最高版本号;注意:因为在第二种情况下,可能存在块的版本号一样,但内容不匹配,因此建议在文件修复后,对文件进行拷贝(不是快照!),并删除原始文件。
Client端大文件传输过程中,强制拔下master主机电源,造成master非法关闭,使用mfsmetarestore -a修复后,master日志报告有坏块:
Jan 19 17:22:17 ngmaster mfsmaster[3250]: chunkserver has nonexistent chunk (000000000002139F_00000001), so create it for future deletion
Jan 19 17:22:18 ngmaster mfsmaster[3250]: (192.168.5.232:9422) chunk: 000000000002139F creation status: 20
Jan 19 17:25:18 ngmaster mfsmaster[3250]: chunk 000000000002139F has only invalid copies (1) - please repair it manually
Jan 19 17:25:18 ngmaster mfsmaster[3250]: chunk 000000000002139F_00000001 - invalid copy on (192.168.5.232 - ver:00000000)
Jan 19 17:26:43 ngmaster mfsmaster[3250]: currently unavailable chunk 000000000002139F (inode: 135845 ; index: 23)
Jan 19 17:26:43 ngmaster mfsmaster[3250]: * currently unavailable file 135845: blog.xxx.cn-access_log200904.tar.gz
Client端使用mfsfilerepair修复
[root@localhost mfstest]# /usr/local/mfs/bin/mfsfilerepair blog.xxx.cn-access_log200904.tar.gz
blog.xxt.cn-access_log200904.tar.gz:
chunks not changed: 23
chunks erased: 1
chunks repaired: 0
查看master日志,发现:
Jan 19 17:30:17 ngmaster mfsmaster[3250]: chunk hasn't been deleted since previous loop - retry
Jan 19 17:30:17 ngmaster mfsmaster[3250]: (192.168.5.232:9422) chunk: 000000000002139F deletion status: 13
Jan 19 17:35:16 ngmaster mfsmaster[3250]: chunk hasn't been deleted since previous loop - retry
Jan 19 17:35:16 ngmaster mfsmaster[3250]: (192.168.5.232:9422) chunk: 000000000002139F deletion status: 13
Client端执行以下操作后,master不再报告相关信息:
mv blog.xxt.cn-access_log200904.tar.gz blog.xxt.cn-access_log200905.tar.gz
3.5 chunker空间介绍
-每一个chunkserver的磁盘都要为增长中的chunks保留些磁盘空间,从而达到创建新的chunk。只有磁盘都超过256M并且chunkservers报告自由空间超过1GB总量才可以被新的数据访问。最小的配置,应该从几个G 字节的存储。
-每个chunkerserver每次以256M的磁盘空间进行申请,客户端查看得到的磁盘总使用情况的是每个chunkerserver使用量的总和。例如:如果你有3个chunkerserver,7个分区磁盘,每次你的硬盘使用会增加3*7*256MB (大约5GB)。假如你有150T的硬盘空间,磁盘空间就不用过多考虑了。
-另外,如果你的chunkservers使用专用的磁盘,df将显示正确的磁盘使用情况。但是如果你有其他的数据在你的MooseFS磁盘上,df将会计算你所有的文件。
-如果你想看你的MooseFS文件的使用情况,请使用'mfsdirinfo'命令。
3.6 snapshot 快照
1、可以快照任何一个文件或目录,语法:mfsmakesnapshot src dst
2、但是src和dst必须都属于mfs体系,即不能mfs体系中的文件快照到其他文件系统。
Mfsappendchunks:追加chunks到一个文件
3、snapshot测试:
①、对一个文件做snapshot后,查看两个文件的块,是同一个块。把原文件删除,原文件删除后(回收站中最初可以看到,但一段时间后,回收站中就彻底删除了),snapshot文件仍然存在,并且可以访问。使用mfsfileinfo查看,发现仍然是原来的块。
②、对一个文件做snapshot后,查看两个文件的块,是同一个块。把原文件修改后,发现原文件使用的块名变了,即使用的是一个新块。而snapshot文件仍然使用原来的块。
3.7 回收站 trash bin
1、设置文件或目录的删除时间。一个删除的文件能够存放在“ 垃圾箱”中的时间称为隔离时间, 这个时间可以用mfsgettrashtime 命令来查看,用mfssettrashtime 命令来设置。单位为秒。
2、单独安装或挂载MFSMETA 文件系统(mfsmount -m mountpoint),它包含目录/ trash (包含仍然可以被还原的删除文件的信息)和/ trash/undel (用于获取文件)。
3、把删除的文件,移到/ trash/undel下,就可以恢复此文件。
4、在MFSMETA 的目录里,除了trash 和trash/undel 两个目录,还有第三个目录reserved,该目录内有已经删除的文件,但却被其他用户一直打开着。在用户关闭了这些被打开的文件后,reserved 目录中的文件将被删除,文件的数据也将被立即删除。此目录不能进行操作。
3.8 文件描述符
1、1.5.12版本,进行大量小文件写时,出现了一个严重错误,有可能和操作系统文件描述符有关。操作系统默认文件描述符为1024.
2、1.6.11版本默认为100000
3、建议上线时,master和chunker修改文件描述符,即修改/etc/security/limits.conf添加
* - nofile 65535
3.9 mfscgiserv
Mfscgiserv 是一个python 脚本, 它的监听端口是9425 ,使用/usr/local/mfs/sbin/mfscgiserv 来直接启动,使用浏览器就可全面监控所有客户挂接, chunkserver 及master server,客户端的各种操作等。
总结
- 一般的自动挂载方式如下:
vim /etc/fstab
#尾行插入
192.168.226.128 /opt/mfs mfs defaults,_netdev 0 0
--->wq
#以上挂载好像无法生效
- 所以我们通过脚本实现自动挂载,操作如下
cd /etc/profiled.
vim up.sh
#!/bin/bash
/usr/local/mfs/bin/mfsmount /opt/mfs -H 192.168.233.131 >/dev/null 2>&1
---->wq
reboot