四、测试分析
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 )的文件都放在一个 “ 垃圾箱 ”, 所以他们也占用的空间 , 其大小也依赖文件的份数。
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
# /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
# 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
日志。
6.
文件信息查看
# /usr/bin/mfsfileinfo /mnt/pscs2.rar
/mnt/pscs2.rar:
chunk 0: 0000000000000027_00000002 / (id:39 ver:2)
copy 1: 192.168.40.183:9422
copy 2: 192.168.40.184:9422
7.
查看目录信息
#/usr/bin/mfsdirinfo /mnt
/mnt:
inodes: 12
directories: 1
files: 11
chunks: 24
length: 1019325511
size: 1019863040
realsize: 2039726080
8.
维护工具列表:
mfsappendchunks mfsfileinfo mfsgettrashtime mfsrgettrashtime
mfssetgoal mfscheckfile mfsfilerepair mfsmakesnapshot
mfsrsetgoal mfssettrashtime mfsdeleattr mfsgeteattr
mfsmount mfsrsettrashtime mfssnapshot mfsdirinfo
mfsgetgoal mfsrgetgoal mfsseteattr mfstools