分布式系统四、MooseFS管理

徐冬丽

　　一、goal（副本）
      副本，在MFS中也被称为目标（Goal），它是指文件被复制的份数，设定目标值后可以通过mfsgetgoal命令来证实，也可以通过mfssetgoal命令来改变设定。
　　
[root@Node1 ~]# cd /mnt
[root@Node1 mnt]# ls
Test
[root@Node1 mnt]# mfsgetgoal Test      #默认没有副本
Test: 1
[root@Node1 mnt]# mfssetgoal 3 Test    #设置3个副本
Test: 3
[root@Node1 mnt]# mfsgetgoal Test   
Test: 3
[root@Node1 mnt]# mfs
mfsappendchunks   mfsfilepaths      mfsmakesnapshot   mfsseteattr
mfscheckfile      mfsfilerepair     mfsmount          mfssetgoal
mfsdeleattr       mfsgeteattr       mfsrgetgoal       mfssetquota
mfsdelquota       mfsgetgoal        mfsrgettrashtime  mfssettrashtime
mfsdirinfo        mfsgetquota       mfsrsetgoal       mfstools
mfsfileinfo       mfsgettrashtime   mfsrsettrashtime  
[root@Node1 mnt]# mfscheckfile Test
Test:
chunks with 2 copies:            1    #只有2个存储块
[root@Node1 mnt]# mfsfileinfo Test
Test:
chunk 0: 0000000000000003_00000001 / (id:3 ver:1)
copy 1: 192.168.10.3:9422
copy 2: 192.168.10.4:9422
[root@Node1 mnt]# mfsdirinfo Test
Test:
inodes:                          1
  directories:                    0
  files:                          1
chunks:                          1
length:                          6
size:                        70656
realsize:                   211968注意：
       当你指定的副本数大于chunk的数目时，会按照实际chunk的数目来保存副本数。
因为一个chunk不存放重复的文件，还有当所有的组件被安装到同一个物理主机的时候，即便设定了goal=2 来到达保存两个副本的目的，但你可能看到的只是一个副本而已，这是合理的，尽管有两个磁盘，但它只是一个chunk server 啊！
      拷贝份数尽量和chunkserver这个服务的数量保持一致，比较易于管理，数据额安全性也得到保障。
[root@Node1 mnt]# mkdir src
[root@Node1 mnt]# mfsgetgoal src
src: 1
[root@Node1 mnt]# mfssetgoal 5 src
src: 5
[root@Node1 mnt]# mfsgetgoal src
src: 5
[root@Node1 mnt]# mfsfileinfo src
src: Operation not permitted
[root@Node1 mnt]# mfsdirinfo src
src:
inodes:                          1
  directories:                    1
  files:                          0
chunks:                          0
length:                          0
size:                            0
realsize:                        0
[root@Node1 mnt]# cd src
[root@Node1 src]# echo aaaaa > a
[root@Node1 src]# ls
a
[root@Node1 src]# cd ..
[root@Node1 mnt]# mfsgetgoal src
src: 5
[root@Node1 mnt]# mfsdirinfo src
src:
inodes:                          2
  directories:                    1
  files:                          1
chunks:                          1
length:                          6
size:                        70656
realsize:                   353280
[root@Node1 mnt]# cd src
[root@Node1 src]# ls
a
[root@Node1 src]# mfsfileinfo a
a:
chunk 0: 0000000000000004_00000001 / (id:4 ver:1)
copy 1: 192.168.10.3:9422
copy 2: 192.168.10.4:9422
[root@Node1 src]# mfsdirinfo a
a:
inodes:                          1
  directories:                    0
  files:                          1
chunks:                          1
length:                          6
size:                        70656
realsize:                   353280
[root@Node1 src]# mfsgetgoal a
a: 5二、回收
      一个删除的文件能够存放在一个“垃圾箱”的时间就是一个隔离时间，这个时间可以用 mfsgettrashtime 命令来验证，也可以用 mfssettrashtime 命令来设置。
例如：
[root@Node1 mnt]# echo 111 >test1
[root@Node1 mnt]#
[root@Node1 mnt]# mfsgettrashtime test1
test1: 86400                     #垃圾箱文件保留期默认是1天，86400秒
[root@Node1 mnt]# mfssettrashtime 300 test1
test1: 300
[root@Node1 mnt]# mfsgettrashtime test1
test1: 300
[root@Node1 mnt]#
       时间的单位是秒(有用的值有:1小时是3600秒,24 – 86400秒,1 – 604800秒)。就像文件被存储的份数一样, 为一个目录 设定存放时间是要被新创建的文件和目录所继承的。数字0意味着一个文件被删除后（不会存放在垃圾箱里）, 将立即被彻底删除，在想回收是不可能的
       恢复垃圾箱里文件可以通过一个单独安装 MFSMETA 文件系统。特别是它包含目录 / trash (包含任然可以被还原的被删除文件的信息)和 / trash/undel (用于获取文件)。只有管理员有权限访问MFSMETA(用户的uid 0，通常是root)。
       在开始mfsmount进程时，用一个-m或-o mfsmeta的选项，这样可以挂接一个辅助的文件系统MFSMETA，这么做的目的是对于意外的从MooseFS卷上删除文件或者是为了释放磁盘空间而移动的文件
例如：
[root@Node1 ~]# mkdir /mfsmetas
[root@Node1 ~]# mfsmount /mfsmetas -H 192.168.10.2 -m
mfsmaster accepted connection with parameters: read-write,restricted_ip
[root@Node1 ~]# ls /mnt
src  Test  test1
[root@Node1 ~]# ls /mfsmetas/
sustained  trash注意：
       需要注意的是，如果要决定挂载mfsmeta，那么一定要在 mfsmaster 的 mfsexports.cfg 文件中有如下条目否则会报错（默认是有的）：
# Allow "meta".
*                       .       rw    1）mfsmeta的挂载目录不需要执行chown –R mfs.mfs
    2）  在这个目录下进行恢复意外删除文件的时候，必须使用root账户进行操作
    3）   原来的位置下不能有一个已存在的与被删文件同名的文件,否则恢复不会成功。
    4）/mfsmetas/sustained  该目录内有已经删除的文件，但却有一直打开着。在用户关闭了这些被打开的文件后，目录中的文件将被删除，文件的数据也将被立即删除。在sustained目录中文件的命名方法同trash目录中的一样，但是不能有其他功能的操作。
     5） 从“垃圾箱”中删除文件结果是释放之前被它站用的空间(删除有延迟,数据被异步删除)。在这种被从“垃圾箱”删除的情况下,该文件是不可能恢复了。


注意：
   1）/mfsmetas/sustained、/mfsmetas/trash 出现这两个目录
   2）有/mfsmetas/trash/undel的目录,还有一些被删除的以8位16进制命名的目录，并且以"|"作为目录符号，再加上被删除文件名字。（如果文件名字大于系统支持的255最大长度时，将从左到右进行裁剪，直到满足255）
规则：00000009|1，1代表删除的文件。
0000002E|123|tst 代表123目录下tst文件，如果123目录被一起删除，
恢复的时候123这个目录也会被一同恢复出来。
   3）如果想恢复文件，把00000009|1该文件移动到/mnt/mfsmeta/trash/undel下，文件即可恢复。
　　

三、快照
   MooseFS系统的另一个特征是利用mfsmakesnapshot工具给文件或者是目录树做快照
       Mfsmakesnapshot 是在一次执行中整合了一个或是一组文件的拷贝，而且任何修改这些文件的源文件都不会影响到源文件的快照， 就是说任何对源文件的操作,例如写入源文件，将不会修改副本(或反之亦然)。  
　　

　　四、监控
　　1、mfs内置的监控工具mfscgiserv
       针对 Moosefs 每个组件的监控，Moosefs自带了一个监控工具 mfscgiserv，它是一个 python 编写的 web 监控页面，监听端口为9425。该监控页面为我们提供了 Master Server、Metalogger Server、Chunk Servers以及所有Client挂载的状态信息及相关性能指标图示。
启动moosefs-cgiserv：
[root@Node2 ~]# service moosefs-cgiserv start
正在启动 mfscgiserv：                                      [确定]启动完毕之后，我们可以通过访问http://IP:9425来访问该监控页面：

　　

　　五、维护

　　1、mfscgiserv的访问安全问题

       mfscgiserv只是一个非常简单的HTTP服务器，只用来编写运行MooseFS CGI脚本。它不支持任何的附加功能，比如HTTP认证。如果公司出于对监控界面的安全访问需求，我们可以使用功能丰富的HTTP服务器，比如apache、nginx等。在使用这些更强大的HTTP服务器时，我们只需要将CGI和其它数据文件（index.html、mfs.cgi、chart.cgi、mfs.css、logomini.png、err.gif）存放到选择的站点根目录下。我们可以创建一个新的虚拟机，来设定特定的主机名和端口来进行访问。


2、Master Server 的单点问题


       Master server的单点问题，在前面介绍 MooseFS 的优缺点时已经提到过了。由于官方提供的解决方案，在恢复的时候还是需要一定时间的，因此我们建议使用第三方的高可用方案（heartbeat+drbd+moosefs）来解决 Master Server 的单点问题。


3、性能瓶颈的解决办法

       由于 MooseFS 的高可扩展性，因此我们可以很轻松的通过增加 Chunk Server 的磁盘容量或增加 Chunk Server 的数量来动态扩展整个文件系统的存储量和吞吐量，这些操作丝毫不会影响到在线业务。
　　

　　
4、安全开启/停止MFS集群

1）启动 MooseFS 集群
安全的启动 MooseFS 集群（避免任何读或写的错误数据或类似的问题）的步骤如下：
       1、启动 mfsmaster
       2、启动所有的 mfschunkserver
       3、启动 mfsmetalogger （如果配置了mfsmetalogger）
       4、当所有的 chunkservers 连接到 MooseFS master 后，任何数目的客户端可以利用 mfsmount 去挂载被 export 的文件系统。（可以通过检查 master 的日志或是 CGI 监控页面来查看是否所有的chunkserver 被连接）。

2）停止 MooseFS 集群

安全的停止 MooseFS 集群的步骤如下：
       1、在所有的客户端卸载MooseFS 文件系统（用umount命令或者是其它等效的命令）
       2、停止chunkserver
       3、停止metalogger
       4、停止master

　　

5、增加块设备（会自动平均）

       针对增加块设备的情况，其实就是说针对chunk server 有变化（增加或减少）的情况。
        为了增加一个案例说明，这里就以 UC 在使用 MooseFS 中遇到的一个问题为案例，讲解新增加 chunk server 时，MooseFS集群发生的变化，其实也就是 Master Server 发生的变化。

        UC在使用 MooseFS 集群的过程中，有次一台 Chunk Server 挂了，于是就涉及到了后期的恢复问题。在问题Chunk Server修复之后，就从新加入到了集群当中。此时，新增加的 chunk server 启动之后会向 Master 汇报 Chunk 的信息，Master接收到 Chunk 信息之后会逐个检查 Chunk_id是否存在。如果不存在，就表示该chunk_id其实已经删除了（chunk_id过期），然后会调用chunk_new()创建该chunk，并设置lockedio属性为7天后。这些操作都是属于内存操作，并且Master是单线程的进程，并不存在全局锁，因此不会导致 Master 阻塞无响应。因此，针对增加chunk server的情况，是不会对MooseFS集群产生什么大的影响的。
        以上就是新增加 Chunk Server 后的，MooseFS 集群中 Master Server 的变化。而针对各个Chunk Server，Master Server会重新去调整块文件的磁盘空间，然后全部重新动态分配块文件。如果遇到空间不够的磁盘，Master Server会自动调整块文件的分布，从不够的磁盘里动态的把块服务移动到有大的磁盘块服务器里
        当然，如果按照上面的情况这次就不会是故障了，因此并不会对 MooseFS 集群产生什么大的影响。由于他们当时因为资源紧张，就把 Master Server 放到了虚拟机上，而虚拟机的磁盘是挂载的iscsi磁盘。并且他们的MooseFS使用的版本并不是最新的1.6.27，而是1.6.19。在1.6.19版本中，会把chunk的汇报过程写入磁盘，这样就导致了几十万条的磁盘写入，由于磁盘是前面提到的网络盘，就最终酿成了 Master Server 恢复时无响应几十分钟。
　　因此，我们在生产环境中，针对Master Server的选型一定不能使用虚拟机，而是使用大内存量的物理机
　　

　　6、MFS元数据备份

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

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

　　元数据改变日志：changelog.*.mfs，存储了过去的N 小时的文件改变（N 的数值是由：BACK_LOGS参数设置的，参数的设置在mfschunkserver.cfg 配置文件中）。
　　主要的元数据文件需要定期备份，备份的频率取决于取决于多少小时changelogs 储存。元数据changelogs 实时的自动复制。这个工作都由metalogger完成。
[root@Node2 ~]# ls /var/lib/mfs/
changelog.12.mfs  changelog.19.mfs  changelog.25.mfs   metadata.mfs.back.1
changelog.13.mfs  changelog.1.mfs   changelog.27.mfs   metadata.mfs.back.2
changelog.14.mfs  changelog.20.mfs  changelog.28.mfs   metadata.mfs.empty
changelog.15.mfs  changelog.21.mfs  changelog.2.mfs    stats.mfs
changelog.16.mfs  changelog.22.mfs  changelog.3.mfs
changelog.17.mfs  changelog.23.mfs  changelog.6.mfs
changelog.18.mfs  changelog.24.mfs  metadata.mfs.back　　

　　7、MFS Master的恢复
   一旦mfsmaster 崩溃（例如因为主机或电源失败），需要最后一个元数据日志changelog 并入主要的metadata 中。这个操作时通过 mfsmetarestore 工具做的，最简单的方法是：
mfsmetarestore  -a
如果master 数据被存储在MooseFS 编译指定地点外的路径，则要利用-d 参数指定使用，如：
mfsmetarestore -a -d /opt/mfsmaster　　

　　从备份恢复MooseFS master
　　为了从备份中恢复一个master，需要做：
　　 1）安装一个mfsmaster
　　 2）利用同样的配置来配置这台mfsmaster（利用备份来找回mfsmaster.cfg），可见配置文件也是需要备份的。
　　 3）找回metadata.mfs.back文件，可以从备份中找，也可以中metalogger主机中找（如果启动了metalogger服务），然后把metadata.mfs.back放入data目录
　　 4）从在master宕掉之前的任何运行metalogger服务的服务器上拷贝最后metadata文件，然后放入mfsmaster的数据目录。
　　 5）利用mfsmetarestore命令合并元数据changelogs，可以用自动恢复模式mfsmetarestore –a，也可以利用非自动化恢复模式，语法如下：
　　mfsmetarestore -m metadata.mfs.back -o metadata.mfs changelog_ml.*.mfs
　　

Automated Failover
生产环境使用 MooseFS 时，需要保证 master 节点的高可用。 使用 ucarp 是一种比较成熟的方案，或者 DRBD+[hearbeat|keepalived] 。 ucarp 类似于 keepalived ，通过主备服务器间的健康检查来发现集群状态，并执行相应操作。另外 MooseFS商业版本已经支持双主配置，解决单点故障。