MFS 概述
MooseFS是一款具有冗余容错功能的分布式文件系统。它把数据分散在多台服务器上,确保一份数据多个备份副本,对外提供统一的结构。
功能特性
对于标准的文件操作,MooseFS表现与其他类Unix文件系统一致。
支持的通过文件系统特性:
- 层次结构(目录树)
- 兼容POSIX文件属性
- 支持特殊文件
- 符号链接和硬链接
- 基于IP地址和密码的访问控制
独有特性
- 高可靠性(数据的多个副本存储在不同服务器)
- 容量动态扩展(添加新硬盘或者服务器)
- 可以回收在制定时间内删除的文件,类似回收站功能
- 可以对整个文件甚至是正在被写入的文件创建文件快照
MFS整体架构的四种角色
Master(元数据服务器)
负责各个数据存储服务器的管理,文件读写调度,文件空间回收以及恢复,多节点拷贝。Metalogger(元数据日志服务器)
负责备份Master服务器的changelog。文件类型为changelog.*.mfs
,以便在Master出问题时接替其工作Chunk(数据存储服务器)
负责连接Master,听从Master调度,提供存储空间,并为客户端提供数据传输Client(客户端挂载)
通过FUSE内核接口挂载远程管理服务器(master)上所管理的数据存储服务器,使用起来和本地文件系统一样
MFS工作图解
- 网络架构
- 工作原理
- 集群拓扑
安装配置MFS
系统环境介绍
- OS:
CentOS Linux release 7.2.1511 (Core)
- 软件版本:2.0.81-1
- 节点配置
ip地址 | 角色 |
---|---|
172.16.18.137 | master |
172.16.18.134 | metalogger |
172.16.18.183 | chunk |
172.16.18.184 | chunk |
172.16.18.185 | chunk |
172.16.18.186 | chunk |
172.16.18.187 | chunk |
chunk上有四块硬盘,第一块为系统,剩下三块作为数据存储,每块容量为4TB
软件安装
从官方软件库安装MFS
- 添加yum key
|
|
- 下载软件库配置文件
|
|
- 安装软件包
|
|
- 启动服务
|
|
从源码安装MFS
- 下载软件包
|
|
- 添加用户和组
|
|
- 安装软件包
|
|
- 安装MFS client
client安装需要fuse支持,fuse可以从源码和仓库中安装
|
|
配置MFS
Master
- 配置文件
|
|
- 修改配置文件
|
|
mfsmaster.cfg : master的主配置文件,配置文件中所有的选项都是用#注释掉的,这代表的是将会使用的选项的默认参数,如果要修改只需取消注释修改其值为你所要使用的值即可;
mfsexportes.cfg 为共享mfs文件系统的控制文件,NFS要共享一个目录时,我们会使用vim /etc/exports命令,编写共享给谁,所要共享的目录,共享出去的属性这些内容,而mfsexports.cfg的作用与其类似其书写格式如下:
|
|
该文件每一个条目分为三部分:
第一部分:客户端的ip 地址
第二部分:被挂接的目录
第三部分:客户端拥有的权限
- 启动服务
|
|
Metalogger
- 修改配置文件
|
|
- 启动服务
|
|
ChunkServer
- 配置分区
|
|
- 修改配置文件
|
|
- 启动服务
|
|
Client
- 挂载MFS
|
|
特别需要注意的是,所有的MFS 都是挂接同一个元数据服务器master 的IP,而不是其他数据存储
服务器chunkserver 的IP
使用MFS
MFS文件系统使用
Client通过MFS软件提供的工具来管理MFS文件系统,下面是工具介绍
|
|
挂载文件系统
MooseFS 文件系统利用下面的命令:
|
|
Mountpoint:是指先前创建的用来挂接mfs 的目录。
在开始mfsmount 进程时,用一个-m 或-o mfsmeta 的选项,这样可以挂接一个辅助的文件系统
MFSMETA,这么做的目的是对于意外的从MooseFS 卷上删除文件或者是为了释放磁盘空间而移动的
文件而又此文件又过去了垃圾文件存放期的恢复,例如:
|
|
设定副本数量
目标(goal),是指文件被拷贝副本的份数,设定了拷贝的份数后是可以通过mfsgetgoal 命令来证实的,也可以通过mfsrsetgoal 来改变设定。
|
|
用mfsgetgoal –r
和mfssetgoal –r
同样的操作可以对整个树形目录递归操作,其等效于mfsrsetgoal
命令。实际的拷贝份数可以通过mfscheckfile
和mfsfile info
命令来证实。
注意以下几种特殊情况:
- 一个不包含数据的零长度的文件,尽管没有设置为非零的目标(the non-zero “goal”),但用mfscheckfile 命令查询将返回一个空的结果;将文件填充内容后,其会根据设置的goal创建副本;这时再将文件清空,其副本依然作为空文件存在。
- 假如改变一个已经存在的文件的拷贝个数,那么文件的拷贝份数将会被扩大或者被删除,这个过程会有延时。可以通过mfscheckfile 命令来证实。
- 对一个目录设定“目标”,此目录下的新创建文件和子目录均会继承此目录的设定,但不会改变已经存在的文件及目录的拷贝份数。
可以通过mfsdirinfo来查看整个目录树的信息摘要。
垃圾回收站
一个被删除文件能够存放在一个“ 垃圾箱”的时间就是一个隔离时间, 这个时间可以用mfsgettrashtime
命令来验证,也可以使用`mfssettrashtime 命令来设置。
时间的单位是秒(有用的值有:1 小时是3600 秒,24 - 86400 秒,1天 - 604800 秒)。就像文件被存储的份数一样, 为一个目录设定存放时间是要被新创建的文件和目录所继承的。数字0 意味着一个文件被删除后, 将立即被彻底删除,在想回收是不可能的。
删除文件可以通过一个单独安装MFSMETA 文件系统。特别是它包含目录/ trash (包含任然可以被还原的被删除文件的信息)和/ trash/undel (用于获取文件)。只有管理员有权限访问MFSMETA(用户的uid 0,通常是root)。
|
|
被删文件的文件名在“垃圾箱”目录里还可见,文件名由一个八位十六进制的数i-node 和被删文件的文件名组成,在文件名和i-node 之间不是用“/”,而是用了“|”替代。如果一个文件名的长度超过操作系统的限制(通常是255 个字符),那么部分将被删除。通过从挂载点起全路径的文件名被删除的文件任然可以被读写。
移动这个文件到trash/undel 子目录下,将会使原始的文件恢复到正确的MooseFS 文件系统上路径下(如果路径没有改变)。如果在同一路径下有个新的同名文件,那么恢复不会成功。
从“垃圾箱”中删除文件结果是释放之前被它站用的空间(删除有延迟,数据被异步删除)。
在MFSMETA中还有另一个目录reserved,该目录内的是被删除但依然打开的文件。在用户关闭了这些被打开的文件后,reserved 目录中的文件将被删除,文件的数据也将被立即删除。在reserved 目录中文件的命名方法同trash 目录中的一样,但是不能有其他功能的操作。
快照snapshot
MooseFS 系统的另一个特征是利用mfsmakesnapshot 工具给文件或者是目录树做快照
Mfsmakesnapshot 是在一次执行中整合了一个或是一组文件的拷贝,而且任何修改这些文件的源文件都不会影响到源文件的快照, 就是说任何对源文件的操作,例如写入源文件,将不会修改副本(或反之亦然)。
也可以使用mfsappendchunks:
当有多个源文件时,它们的快照被加入到同一个目标文件中(每个chunk 的最大量是chunk)。
MFS集群维护
启动MFS集群
安全的启动MooseFS 集群(避免任何读或写的错误数据或类似的问题)的方式是按照以下命令步骤:
- 启动mfsmaster 进程
- 启动所有的mfschunkserver 进程
- 启动mfsmetalogger 进程(如果配置了mfsmetalogger)
- 当所有的chunkservers 连接到MooseFS master 后,任何数目的客户端可以利用mfsmount 去挂接被export 的文件系统。(可以通过检查master 的日志或是CGI 监视器来查看是否所有的chunkserver被连接)。
停止MFS集群
安全的停止MooseFS 集群:
- 在所有的客户端卸载MooseFS 文件系统(用umount 命令或者是其它等效的命令)
- 用mfschunkserver stop 命令停止chunkserver 进程
- 用mfsmetalogger stop 命令停止metalogger 进程
- 用mfsmaster stop 命令停止master 进程
Chunkservers 的维护
若每个文件的goal(目标)都不小于2,并且没有under-goal 文件(这些可以用mfsgetgoal –r和mfsdirinfo 命令来检查),那么一个单一的chunkserver 在任何时刻都可能做停止或者是重新启动。以后每当需要做停止或者是重新启动另一个chunkserver 的时候,要确定之前的chunkserver 被连接,而且要没有under-goal chunks。
MFS元数据备份
通常元数据有两部分的数据:
- 主要元数据文件metadata.mfs,当mfsmaster 运行的时候会被命名为metadata.mfs.back
- 元数据改变日志changelog.*.mfs,存储了过去的N 小时的文件改变(N 的数值是由BACK_LOGS参数设置的,参数的设置在mfschunkserver.cfg 配置文件中)。
主要的元数据文件需要定期备份,备份的频率取决于取决于多少小时changelogs 储存。元数据changelogs 实时的自动复制。1.6版本中这个工作都由metalogger完成。
MFS Master的恢复
一旦mfsmaster 崩溃(例如因为主机或电源失败),需要最后一个元数据日志changelog 并入主要的metadata 中。这个操作时通过mfsmetarestore
工具做的,最简单的方法是:
|
|
如果master 数据被存储在MooseFS 编译指定地点外的路径,则要利用-d 参数指定使用,如:
|
|
从MetaLogger中恢复Master
如果mfsmetarestore -a无法修复,则使用metalogger也可能无法修复,暂时没遇到过这种情况,这里不暂不考虑。
- 找回metadata.mfs.back 文件,可以从备份中找,也可以中metalogger 主机中找(如果启动了metalogger 服务),然后把metadata.mfs.back 放入data 目录,一般为{prefix}/var/mfs
- 从在master 宕掉之前的任何运行metalogger 服务的服务器上拷贝最后metadata 文件,然后放入mfsmaster 的数据目录。
- 利用mfsmetarestore 命令合并元数据changelogs,可以用自动恢复模式mfsmetarestore –a,也可以利用非自动化恢复模式
|
|
或:强制使用metadata.mfs.back创建metadata.mfs,可以启动master,但丢失的数据暂无法确定。
Automated Failover
生产环境使用 MooseFS 时,需要保证 master 节点的高可用。 使用 ucarp
是一种比较成熟的方案,或者DRBD+[hearbeat|keepalived]
。ucarp
类似于 keepalived
,通过主备服务器间的健康检查来发现集群状态,并执行相应操作。另外 MooseFS商业版本已经支持双主配置,解决单点故障。