3.3.2 配置:

$vi /usr/local/mfs/etc/mfsmetalogger.cfg

# WORKING_USER = mfs

# WORKING_GROUP = mfs

# SYSLOG_IDENT = mfsmetalogger

# LOCK_MEMORY = 0

# NICE_LEVEL = -19

# DATA_PATH = /usr/local/mfs/var/mfs

# BACK_LOGS = 50

# META_DOWNLOAD_FREQ = 24 元数据备份文件下载请求频率。默认为24小时,即每隔一天从元数据服务器(MASTER)下载一个metadata.mfs.back 文件。当元数据服务器关闭或者出故障时,matedata.mfs.back 文件将消失,那么要恢复整个mfs,则需从metalogger 服务器取得该文件。请特别注意这个文件,它与日志文件一起,才能够恢复整个被损坏的分布式文件系统。

# MASTER_RECONNECTION_DELAY = 5

MASTER_HOST = 192.168.0.1

# MASTER_PORT = 9419

# MASTER_TIMEOUT = 60

# deprecated, to be removed in MooseFS 1.7

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

注意:

·MASTER_HOST 不能为localhost127.0.0.1,做单机测试的童鞋们注意了,要使用对外IP

·MASTER_PORT必须为元数据服务器配置中MATOCS_LISTEN_PORT指定的端口,且IP必须被master允许。

3.3.3 操作

/usr/local/mfs/sbin/mfsmetalogger [-vdu] [-t locktimeout] [-c cfgfile] [start|stop|restart|reload]#chunkserver操作命令

3.4 MFS Client

192.168.0.6上执行如下操作:

3.4.1 FUSE安装:

$wget http://nchc.dl.sourceforge.net/project/buluoos/0.2/src/fuse-2.8.5.tar.gz

$tar zxf fuse-2.8.5.tar.gz

$cd fuse-2.8.5

$./configure

$make && make install

$echo 'export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:$PKG_CONFIG_PATH' >>/etc/profile

$source /etc/profile
$lsmod |grep fuse #
检查fuse是否加载到内核,若没有,执行下面命令
$modprobe fuse&&lsmod |grep fuse#
若将下列mfsmount挂载操作加入开机自启动,一定将modprobe fuse也加入开机自启

注意:

·一定要将fuse环境变量配置ok,否则安装mfsmount会装不上

·若将下列mfsmount挂载操作加入开机自启动,一定将modprobe fuse也加入开机自启,且在其执行之前执行。

3.4.2 MFSMount安装:

$useradd mfs -s /sbin/nologin

$wget http://www.moosefs.org/tl_files/mfscode/mfs-1.6.20-2.tar.gz

$tar zxvf mfs-1.6.20-2.tar.gz

$cd mfs-1.6.20-2/

$./configure --prefix=/usr/local/mfs --with-default-user=mfs --with-default-group=mfs --disable-mfsmaster --disable-mfschunkserver

$make;make install

3.4.3 挂载MFS

$mkdir /mnt/mfs /mnt/mfsmeta#创建挂载点

$/usr/local/mfs/bin/mfsmount /mnt/mfs -H 192.168.0.1

$/usr/local/mfs/bin/mfsmount -m /mnt/mfsmeta -H 192.168.0.1

$df -h #检查是否挂载成功
$umount /mnt/mfs #
操作如下出错,说明客户端本机有正在使用此文件系统,可以查明是什么命令正在使用,然后推出就可以了,最好不要强制退出。

到此为止,我们的MFS集群已经搭建完成。

四、MFS的高级特性

4.1 冗余goal设置

目标(goal),是指文件被拷贝的份数,设定了拷贝的份数后是可以通过mfsgetgoal 命令来证实的,也可以通过mfsrsetgoal 来改变设定。

$/usr/local/mfs/bin/mfssetgoal 3 /mnt/mfs/test1

$/usr/local/mfs/bin/mfsgetgoal /mnt/mfs/test1

/mnt/mfs/test1: 3

mfsgetgoal–r mfssetgoal–r 同样的操作可以对整个树形目录递归操作,其等效于mfsrsetgoal命令。实际的拷贝份数可以通过mfscheckfilemfsfile info 命令来证实。

注意以下几种特殊情况:

·一个不包含数据的零长度的文件,尽管没有设置为非零的目标(the non-zero "goal",但用mfscheckfile 命令查询将返回一个空的结果;将文件填充内容后,其会根据设置的goal创建副本;这时再将文件清空,其副本依然作为空文件存在。

·假如改变一个已经存在的文件的拷贝个数,那么文件的拷贝份数将会被扩大或者被删除,这个过程会有延时。可以通过mfscheckfile 命令来证实。

·对一个目录设定目标,此目录下的新创建文件和子目录均会继承此目录的设定,但不会改变已经存在的文件及目录的拷贝份数。

可以通过mfsdirinfo来查看整个目录树的信息摘要。

 

4.2 垃圾回收站

一个删除文件能够存放在一个“ 垃圾箱的时间就是一个隔离时间,这个时间可以用mfsgettrashtime命令来验证,也可以用mfssettrashtime命令来设置。如:

$/usr/local/mfs/bin/mfssettrashtime 64800 /mnt/mfs/test1

$/usr/local/mfs/bin/mfsgettrashtime /mnt/mfs/test1

/mnt/mfs/test1: 64800 

时间的单位是秒(有用的值有:1 小时是3600 ,24 - 86400 ,1 - 604800 )。就像文件被存储的份数一样为一个目录设定存放时间是要被新创建的文件和目录所继承的。数字意味着一个文件被删除后将立即被彻底删除,在想回收是不可能的。

删除文件可以通过一个单独安装MFSMETA 文件系统。特别是它包含目录/ trash (包含任然可以被还原的被删除文件的信息)/ trash/undel (用于获取文件)。只有管理员有权限访问MFSMETA(用户的uid 0,通常是root)

$/usr/local/mfs/bin/mfsmount -m /mnt/mfsmeta -H 192.168.0.1

被删文件的文件名在垃圾箱目录里还可见,文件名由一个八位十六进制的数i-node 和被删文件的文件名组成,在文件名和i-node 之间不是用“/”,而是用了“|”替代。如果一个文件名的长度超过操作系统的限制(通常是255 个字符),那么部分将被删除。通过从挂载点起全路径的文件名被删除的文件任然可以被读写。

移动这个文件到trash/undel 子目录下,将会使原始的文件恢复到正确的MooseFS 文件系统上路径下(如果路径没有改变)。如果在同一路径下有个新的同名文件,那么恢复不会成功。

垃圾箱中删除文件结果是释放之前被它站用的空间(删除有延迟,数据被异步删除)

MFSMETA中还有另一个目录reserved,该目录内的是被删除但依然打开的文件。在用户关闭了这些被打开的文件后,reserved 目录中的文件将被删除,文件的数据也将被立即删除。在reserved 目录中文件的命名方法同trash 目录中的一样,但是不能有其他功能的操作。

 

4.3 快照snapshot

MooseFS 系统的另一个特征是利用mfsmakesnapshot工具给文件或者是目录树做快照。

$/usr/local/mfs/bin/mfsmakesnapshot source ... destination

Mfsmakesnapshot 是在一次执行中整合了一个或是一组文件的拷贝,而且任何修改这些文件的源文件都不会影响到源文件的快照,就是说任何对源文件的操作,例如写入源文件,将不会修改副本(或反之亦然)

也可以使用mfsappendchunks

$/usr/local/mfs/bin/mfsappendchunks destination-file source-file ...

当有多个源文件时,它们的快照被加入到同一个目标文件中(每个chunk 的最大量是chunk)。

五、MFS的性能测试

下面是网上得到的一童鞋的简单测试数据,直接拿过来了。

写:time dd if=/dev/zero of=/mnt/mfs/test2/test500M bs=1024k count=500

读:time dd if=/mnt/mfs/test2/test500M of=/dev/null

1copy写    

2copy写    

1copy读    

2copy读    

1M  

0m0.042s

0m0.042s

0m0.017s

0m0.017s

5M

0m0.073s

0m0.079s

0m0.070s

0m0.071s

20M

0m0.250s

0m0.288s

0m0.291s

0m0.376s

50M

0m0.514s

0m0.589s

0m0.896s

0m0.886s

100M

0m0.977s

0m7.497s

0m1.677s

0m1.787s

200M  

0m7.910s

0m22.270s

0m2.683s

0m3.129s

500M

0m22.465s

0m51.735s

0m6.559s

0m6.990s

1G

0m52.346s

1m48.056s

0m17.319s

0m17.154s

2G

1m46.224s

3m46.283s

0m41.608s

0m34.435s

10G

9m29.037s

19m26.237s

3m55.222s

3m24.914s

 

·读速度:ca 71M/s 写速度:ca 22M/s 9M/s (以500M计算)

·goal的设置和读写速度的关系?貌似没有太大关系。

另一份比较详细的测试数据,就不粘出来了,直接把结果拿过来:

·单盘多进程性能没有提升,因为都在io wait,甚至增加进程会消耗大量调度时间

·MFS多进程时性能会提升,主要性能消耗集中在CPU系统时间。因此实际海量小文件性能要大大强于本地文件系统

六、MFS集群的维护

6.1 启动MFS集群

最安全的启动MooseFS 集群(避免任何读或写的错误数据或类似的问题)的方式是按照以下命令步骤:

  1. 启动mfsmaster 进程

  2. 启动所有的mfschunkserver 进程

  3. 启动mfsmetalogger 进程(如果配置了mfsmetalogger

  4. 当所有的chunkservers 连接到MooseFS master 后,任何数目的客户端可以利用mfsmount 去挂接被export 的文件系统。(可以通过检查master 的日志或是CGI 监视器来查看是否所有的chunkserver被连接)。

 

6.2 停止MFS集群

安全的停止MooseFS 集群:

  1. 在所有的客户端卸载MooseFS 文件系统(用umount 命令或者是其它等效的命令)

  2. mfschunkserver stop 命令停止chunkserver 进程

  3. mfsmetalogger stop 命令停止metalogger 进程

  4. mfsmaster stop 命令停止master 进程

 

6.3 MFS chunkservers 的维护

若每个文件的goal(目标)都不小于2,并且没有under-goal 文件(这些可以用mfsgetgoal –rmfsdirinfo 命令来检查),那么一个单一的chunkserver 在任何时刻都可能做停止或者是重新启动。以后每当需要做停止或者是重新启动另一个chunkserver 的时候,要确定之前的chunkserver 被连接,而且要没有under-goal chunks

 

6.4 MFS元数据备份

通常元数据有两部分的数据:

·主要元数据文件metadata.mfs,当mfsmaster 运行的时候会被命名为metadata.mfs.back

·元数据改变日志changelog.*.mfs,存储了过去的小时的文件改变(的数值是由BACK_LOGS参数设置的,参数的设置在mfschunkserver.cfg 配置文件中)。

主要的元数据文件需要定期备份,备份的频率取决于取决于多少小时changelogs 储存。元数据changelogs 实时的自动复制。1.6版本中这个工作都由metalogger完成。

 

6.5 MFS Master的恢复

一旦mfsmaster 崩溃(例如因为主机或电源失败),需要最后一个元数据日志changelog 并入主要的metadata 中。这个操作时通过mfsmetarestore工具做的,最简单的方法是:

$/usr/local/mfs/bin/mfsmetarestore -a

如果master 数据被存储在MooseFS 编译指定地点外的路径,则要利用-d 参数指定使用,如:

$/usr/local/mfs/bin/mfsmetarestore -a -d /opt/mfsmaster

 

6.6 MetaLogger中恢复Master

有些童鞋提到:如果mfsmetarestore -a无法修复,则使用metalogger也可能无法修复,暂时没遇到过这种情况,这里不暂不考虑。

  1. 找回metadata.mfs.back 文件,可以从备份中找,也可以中metalogger 主机中找(如果启动了metalogger 服务),然后把metadata.mfs.back 放入data 目录,一般为{prefix}/var/mfs

  2. 从在master 宕掉之前的任何运行metalogger 服务的服务器上拷贝最后metadata 文件,然后放入mfsmaster 的数据目录。

  3. 利用mfsmetarestore 命令合并元数据changelogs,可以用自动恢复模式mfsmetarestore –a,也可以利用非自动化恢复模式

$mfsmetarestore -m metadata.mfs.back -o metadata.mfs changelog_ml.*.mfs

或:

强制使用metadata.mfs.back创建metadata.mfs,可以启动master,但丢失的数据暂无法确定。

七、MFS的常见问题和建议对策

7.1 Master性能瓶颈

master本身的性能瓶颈。
短期对策:按业务切分

 

7.2 体系架构存储文件总数的瓶颈

mfs把文件系统的结构缓存到master的内存中,个人认为文件越多,master的内存消耗越大,8g对应2500kw的文件数,2亿文件就得64GB内存。
短期对策:按业务切分

 

7.3 单点故障解决方案的健壮性


7.4 
垃圾回收

默认的垃圾回收时间是86400,存在一种可能性是垃圾还没回收完,你的存储容量就暴掉了。
方案一:设置垃圾回收时间,积极监控存储容量。
经过测试,把垃圾回收时间设置300秒,完全可以正确回收容量。
方案二:手动周期性去删除metamfs里的trash目录下的文件(健壮性还有待测试,反正删除后容量是回收了,不晓得有没有什么后遗症。)

 

7.5 理想的平均写和读的速度是多少?

原始的读/写速度很明显是主要取决于所使用的硬盘的性能、网络的容量和拓扑结构的,使用的硬盘和网络的吞吐量越好,整个系统的性能也就会越好。官方的测试环境中,将MFS安装在linuxDebian)上设置存储的份数为2,一般的测试服务器(还做了其他较大量的计算),G太网络,使用Pbyte级别的数据,测试的结果为写的速度大约在20-30MB/s,读的速度为30-50MB/s。对于小文件写的速度有些下降,但是对于读的速度是没有影响的。

 

7.6 设置文件存储的份数是否影响写/读的速度?

一般来说,它是有影响的。在一定条件下,存储份数的设置会影响的读取的速度。例如,当文件设置存储两份而不是一份时能加快对同一文件有多个客户端读取的速度。但是在真实的环境中,多个机器同时读取同一个文件的机率是比较小的,因此,存储份数的设置对读取的速度影响是比较小的。

同样,设置存储份数对写的速度影响也是不太大的。(只有文件超过64M的时候)

本次总结主要来自一些网络上的资料和当前生产环境使用MFS的一些经验。

参考资料:《MFS知识大汇总》、《MFS权威指南》、《MFS文件系统使用手册》