MFS 分布式文件系统应用(二)

最新推荐文章于 2024-10-02 10:53:34 发布

weixin_34221036

最新推荐文章于 2024-10-02 10:53:34 发布

阅读量103

点赞数

文章标签：运维

原文链接：http://blog.51cto.com/iceeggplant/717813

版权

四、测试分析

1. Chunk server 的测试

测试环境：

Chunk01 192.168.40.183

Chunk02 192.168.40.184

Mfsmaster 192.168.40.140

Mfsclient 192.168.40.144

Chunk01 分区：

Filesystem Size Used Avail Use% Mounted on

/dev/xvda1 13G 1.9G 9.7G 17% /

/dev/xvdb1 59G 206M 55G 1% /data

tmpfs 129M 0 129M 0% /dev/shm

/dev/xvdc1 122M 5.8M 110M 6% /mnt/chunk1

/dev/xvdd1 122M 5.8M 110M 6% /mnt/chunk2

/dev/xvde1 122M 5.8M 110M 6% /mnt/chunk3

Chunk02 分区：

Filesystem Size Used Avail Use% Mounted on

/dev/xvda1 8.7G 1.9G 6.5G 23% /

/dev/xvdb1 49G 859M 46G 2% /data

tmpfs 129M 0 129M 0% /dev/shm

/dev/xvdc1 494M 11M 458M 3% /mnt/chunks1

/dev/xvdd1 494M 11M 458M 3% /mnt/chunks2

Mfsclient:

文件系统容量已用可用已用 % 挂载点

/dev/mapper/VolGroup00-LogVol00

　　　 19G 8.0G 9.4G 46% /

/dev/sda1 99M 14M 81M 15% /boot

mfs#192.168.40.140:9421

　　　 47G 1.5G 45G 4% /mnt

注：副本数为 mfsrsetgoal 　 2 /mnt

1）上传数据至 mfs-client 端， chunk01,02 分别占用空间 6% ， 3% 。

2 ）取消 chunk02 上的两挂载 chunks1,2 。　前台分别重新设置两台 chunk 的 mfshdd 空间挂载到 /data( 需 mfs 用户可读写权限 ) 上。

注：重新挂载存储分区后，需重启 chunk 服务，重新初始化。

结果：数据重新分配， chunk01 ,02 各使用率 7.7%,6%

现数据挂载及使用情况：

Chunk01

Filesystem Size Used Avail Use% Mounted on

/dev/xvdb1 49G 1008M 45G 3% /data

Chunk02

Filesystem Size Used Avail Use% Mounted on

/dev/xvdb1 59G 995M 55G 2% /data

3 ）关闭 mfs 服务器，使用 /usr/local /sbin/mfsmaster – s 这种方式，如果直接使用 kill 杀死进程，将导致下次启动时出现找不到相关文件，而不能正常启动服务器。可以通过 mfsmetastore 　－ a 来恢复 ( 进程启不来 , 其实是配置文件放 PID 的目录会被删掉，重建这个目录，然后赋予权限就可以了 ) 。

4）删除 mfs-client 所有数据，默认删除文件后的空间回收时间为 1 天（ 86400 秒），可能存在一种可能性是垃圾还没回收完，存储容量已占用很大比例。

方案一：建议设置文件删除回收空间时间为 600s ，监控存储容量。经其他 mfs 测试人员测试，把空间回收时间设置 300s ，完全可以回收容量。

方案二 : 手动周期性删除 metamfs 里的 trash 目录下的文件。这个需要单独安装一个 MFSMETA 文件系统。特别是它包含目录 / trash ( 包含任然可以被还原的被删除文件的信息 ) 和 / trash/undel ( 用于获取文件 ) 。只有管理员有权限访问 MFSMETA( 用户的 uid 0 ，通常是 root) 。

mfsrsettrashtime –r 600 /mnt -r 对整个目录树进行操作

现测试暂改 120 秒。

删除后数据挂载及使用情况：

Chunk01

Filesystem Size Used Avail Use% Mounted on

/dev/xvdb1 49G 　 220M 46G 1% /data

Chunk02

Filesystem Size Used Avail Use% Mounted on

/dev/xvdb1 59G 207M 55G 1% /data

mfsclient

mfs#192.168.40.140:9421 101G 0 101G 0% /mnt

注： /data 中所占用的数据是本地原有数据。

5 ）重新上传数据至 client

787M /mnt/ 　

查看 chunk 服务器：

Chunk01

Filesystem 　 Size Used 　 Avail 　 Use% 　 Mounted on

/dev/xvdb1 49G 　 1008M 45G 3% 　 /data

　　 Chunk02

Filesystem Size Used 　 Avail 　 Use% 　 Mounted on

/dev/xvdb1 59G 995M 55G 2% 　　 /data

　 mfsclient

mfs#192.168.40.140:9421 101G 1.6G 99G 2% /mnt

根据以上数据存储分析正确 .

Chunk01,02 上传数据后总共 2003M －原先总共占用 427M ＝数据占用 1576M 。

上传的数据大小 787M* 副本数为 2= 总存储容量应是 1574M 。

6 ）停止 chunk02-server ，向 client 端上传数据 1.8M 　 www_error_log

　　　 Master 查看系统日志 /var/log/message ：只有 chunk01 日志存储记录，查看空间，均存储到 chunk01 上。重复上传，删除，下载操作，观察 chunk01 存储变化，查看 master 机上 /var/lib/mfs/changlog 记录存储变化日志。

注：由于测试时单个文件上传，读取不会超过 10M ，速度很快。 Down 掉一台 chunk02 ，另外一台正常提供存储和读取操作。

7 ）恢复 chunk02-server 上服务，重新扫描加载磁盘 hdd space manager: scanning complete

再上传数据至 client 端，查看日志和 chunk 空间大小， chunk02 已启用存储。

2. Master 的主备切换

mfsmaster 的故障恢复在 1.6 版本后可以由 mfsmetalogger 产生的日志文件 changelog_ml.*.mfs 和 metadata.mfs.back 由命令 mfsmetarestore 恢复，恢复后 MFS 文件系统信息内容是完全一样的。

2.1 　由 metalogger 恢复 master

1 ）启动 metalogger 服务后， metalogger 定期从 master 下载 metadata 文件，并实时记录 changlog, 可在配置文件参数中设置每小时同步一次。

META_DOWNLOAD_FREQ = 1

2 ）备份 master 的两个配置文件 mfsmaster.cfg,mfsexports.cfg 至 metalogger, 　因配置文件基本属于一次性更改，暂测试先 scp 192.168.40.140:/etc/mfsmaster.cfg /etc/mfs/ 过来，后期 rsync 通过定时脚本进行配置文件的同步。

3) 将 master:192.168.40.140 down 掉，使用 metalogger server:192.168.40.185 #mfsmetarestore –a 或

#mfsmetarestore –a -d /var/lib/mfs 指定 master 数据存储的路径

将 metalogger 中的基准和增量变成 master 需要的 metadata

metarestore 程序是根据 metalogger 中定期下载的 metadata 和 changelog 来恢复 master 挂掉时刻 master 所记录的整个 mfs 的信息。

#/usr/sbin/mfsmaster start 启动 master 服务。

2.2 　 chunk 和 client 端进行响应的处理。

1) 对于 client ，需要 umount 掉 mfs 分区后，重启 mfsmount 新的 master 的 IP 地址。

2) 修改两 chunk server 配置文件中指定的 master ip, 重启 chunk 服务 .

3. 测试问题小记

1）磁盘规划问题：最好一个盘作一个挂载点，这样坏一个盘，只用转移那一个盘的数据。分布存储在多个盘上，可以提高读写速度。

2）暂不支持 master 主备的热切换问题，后期测试成熟打算改用 corosync+pacemaker+mfsmaster+metalog 方案实现。

3）如果文件数量和 chunk 块较多的话，建议增大 chunk_loop_time 的时间，可以减少 master 的负载。

4） Currently MooseFS imposes a maximum file size limit of 2 TiB ， However we are considering removing this limitation in the near future, which is currently 16EiB

单个存储空间最好大于 2G ，我试验的 512M ，两 chunk ，怎么着环境测试都不对，后来在官网上的这句话彻底醒悟。

5 ）我 chunk 上挂的 /data 本来就有数据，之前做 SVN 试验留下来的，忘删了，我核对 client 端和两 chunk 上的数据大小怎么就不对，无论是一副本还是两副本。后来查块文件从 00-FF ，看到后面的多出了几个 SVN 的目录，浪费时间折腾。

6 ） Every chunkserver sends its own disk usage increased by 256MB for each used partition/hdd, and a sum of these master sends to the client as total disk usage. If you have 3 chunkservers with 7 hdd each, your disk usage will be increased by 3*7*256MB (about 5GB). In practice, this is not usually a concern for example when you have 150TB of HDD space. ?

There is one other thing. If you use disks exclusively for MooseFS on chunkservers df will show correct disk usage, but if you have other data on your MooseFS disks df will count your own files too. ?

If you want to see usage of your MooseFS files use 'mfsdirinfo' command.chunk

初始化磁盘要占用 2*2*256M 的空间，这就是为什么监控上看到的数据会要多 2G 多原因。一直以为 chunk 或 master 调度出了问题，找不出原因。

1) mfs 把文件系统的结构缓存到 master 的内存中，文件越多， master 的内存消耗越大， 8g 对应 2500kw 的文件数， 2 亿文件就得 64GB 内存 .

2) Chunk 上的每个挂载点存储目录 00-FF ，共 256 个。每单个文件最大上限 64M ，超过 64M 目录下会循环生成下一个文件。

五、常用维护

1. 挂载文件系统
mfsmount mountpoint [-d] [-f] [-s] [-m] [-n] [-p] [-H MASTER] [-P PORT] [-S PATH] [-o OPT[,OPT...]]
-H MASTER ：是管理服务器（ master server ）的 ip 地址
-P PORT ：是管理服务器（ master server ）的端口号，要按照 mfsmaster.cfg 配置文件中的变量 MATOCU_LISTEN_POR 的之填写。如果 master serve 使用的是默认端口号则不用指出。
-S PATH ：指出被挂接 mfs 目录的子目录，默认是 / 目录，就是挂载整个 mfs 目录。
Mountpoint ：是指先前创建的用来挂接 mfs 的目录。
在开始mfsmount 进程时，用一个 -m 或 -o mfsmeta 的选项，这样可以挂接一个辅助的文件系统 MFSMETA ，这么做的目的是对于意外的从 MooseFS 卷上删除文件或者是为了释放磁盘空间而移动的文件而又此文件又过去了垃圾文件存放期的恢复，例如：
mfsmount -m /mnt/mfsmeta
需要注意的是，如果要决定挂载 mfsmeta ，那么一定要在 mfsmaster 的 mfsexports.cfg 文件中加入如下条目：
* . rw
MooseFS 卷的剩余空间检查 df ：
# df -h | grep mfs

重要的是每一个文件可以被储存多个副本，在这种情况下，每一个文件所占用的空间要比其文件本身大多了。此外 , 被删除且在有效期内（ trashtime ）的文件都放在一个 “ 垃圾箱 ”, 所以他们也占用的空间 , 其大小也依赖文件的份数。

2. 查看文件保存状态 .

goal 指文件被拷贝的份数，可以通过 mfsgetgoal 命令查看，也可以通过 mfssetgoal 来改变设置。
# /usr/bin/mfsgetgoal /mnt
/mnt: 2
#/usr/bin/ mfssetgoal 3 /mnt
/mnt : 3

用 mfsgetgoal –r 和 mfssetgoal –r 同样的操作可以对整个树形目录递归操作。
# mfsgetgoal -r /mnt/mfs-test/test2
/mnt/mfs-test/test2:
files with goal 2 : 36
directories with goal 2 : 1
# mfssetgoal -r 3 /mnt/mfs-test/test2
/mnt/mfs-test/test2:
inodes with goal changed: 37
inodes with goal not changed: 0
inodes with permission denied: 0
实际的拷贝份数可以通过 mfscheckfile 和 mfsfileinfo 命令查看：
# mfscheckfile /mnt/mfs-test/test1
/mnt/mfs-test/test1:
3 copies: 1 chunks

3. 设置删除文件回收时间

#/usr/bin/mfsgettrashtime –r 600 /mnt 600s 回收时间，也可针对单个文件设置，递归选项 -r 目录树 , 默认一天 86400s 。

4. 备份 meta 状态：

master: /var/lib/mfs 下的 metadata.mfs 文件是当前的 metadata ，默认每小时都会更新，旧文件将会添加 .back 后缀备份即可，并同时增加 changelog.*.log 。当然，推荐使用 moosefs metalogger 来作备份恢复。

5. 安全的停止 MooseFS 集群：

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

用 mfschunkserver – s 命令停止 chunkserver 进程

用 mfsmetalogger – s 命令停止 metalogger 进程

用 mfsmaster – s 命令停止 master 进程

数据恢复：

master: mfsmetarestore –a 　自动恢复模式

master: mfsmetarestore -m metadata.mfs.back -o metadata.mfs changelog.*.mfs 非自动指定文件恢复。拷贝最后的 metadata 文件，合并 changlog 日志。