Chinaunix首页 | 论坛 | 博客
  • 博客访问: 9247047
  • 博文数量: 1669
  • 博客积分: 16831
  • 博客等级: 上将
  • 技术积分: 12594
  • 用 户 组: 普通用户
  • 注册时间: 2011-02-25 07:23
个人简介

柔中带刚,刚中带柔,淫荡中富含柔和,刚猛中荡漾风骚,无坚不摧,无孔不入!

文章分类

全部博文(1669)

文章存档

2023年(4)

2022年(1)

2021年(10)

2020年(24)

2019年(4)

2018年(19)

2017年(66)

2016年(60)

2015年(49)

2014年(201)

2013年(221)

2012年(638)

2011年(372)

分类: 系统运维

2013-12-27 11:16:28

 MooseFS 介绍 2011-10-07 11:11:12

分类: 数据库开发技术


最近了解了一个分布式文件系统——MooseFS,之前对分布式的东西知道的很少,分布式文件系统、分布式数据库都是近而远之,觉得太复杂了离我还很遥远。在各位老师的推动下我用6台机器实践了一下moosefs,moosefs的部署还是很简单的,和配置NFS很像,就是多了两种角色的机器,正是有了它们,才使得moosefs在可扩展性和稳定性上都要远好于NFS,在读写的性能方面,通过dd进行的简单测试来看,moosefs也就是写入的速度稍微好于NFS,读上没有差别。下面是对于MFS知识点的一些总结。

MFS系统由4个部分构成,master、metalogger、chunkserver、client。
Master —— mfs的大脑,记录着管理信息,比如:文件大小,存储的位置,份数等,和innodb中共享空间(ibdata)中存储的信息类似,这些信息被记录到metadata.mfs中,当该文件被载入内存后,改文件会重命名为metadata.mfs.back,当chunkserver上有更新时,master会定期将获得的新的信息回写到metadata.mfs.back中,保重元数据的可靠。

硬件推荐:大内存,因为内存中需要将metadata.mfs加载进来,这个文件的大小取决于你chunkserver上存储的数据量,内存的大小会成为之后的问题,要ECC的可以进行错误校验,当内存中数据量达到一定程度,如果没有个容错的机制,会很可怕;冗余电池,和磁盘配置RAID1/RAID5/RAID10,都是为了保证高可靠。

Metalogger —— mfs的备份,好比mysql中的m-s结构,metalogger会定期重master上将的metadata、changelog、session类型的文件下载同步到本地目录下,并加后缀”_ml”将其重命名。

硬件推荐:与master机器配置一致,metalogger本身就是master的一个备机,当master宕机后,可以直接将metalogger提升为master。

Chunkserver —— 数据存储地,文件以chunk大小存储,每chunk最大为64M,小于64M的,该chunk的大小即为该文件大小,超过64M的文件将被均分,每一份(chunk)的大小以不超过64M为原则;文件可以有多份copy,即除了原始文件以外,该文件还存储的份数,当goal为1时,表示只有一份copy,这份copy会被随机存到一台chunkserver上,当goal的数大于1时,每一份copy会被分别保存到每一个chunkserver上,goal的大小不要超过chunkserver的数量,否则多出的copy,不会有chunkserver去存,goal设置再多实际上也就没有意义的。Copy的份数,一般设为大于1份,这样如果有一台chukserver坏掉后,至少还有一份copy,当这台又被加进来后,会将失去的那份copy补回来,始终保持原有的copy数,而如果goal设为1copy,那么当存储该copy的chunkserver坏掉,之后又重新加入回来,copy数将始终是0,不会恢复到之前的1个copy。
Chunkserver上的剩余存储空间要大于1GB(Reference Guide有提到),新的数据才会被允许写入,否则,你会看到No space left on device的提示,实际中,测试发现当磁盘使用率达到95%左右的时候,就已经不行写入了,当时可用空间为1.9GB。

硬件建议:普通的机器就行,就是要来存几份数据,只要磁盘够大就好。

Client —— 客户端通过内核加载的FUSE模块,再通过和master的共同,将chunkserver共享的分区挂载到本地,然后进行读写操作。由于FUSE模块是外加的模块,当系统重启后,需要执行modprobe fuse,将其加载到内核中。


有了测试环境,现在开始一步步来学习Moosefs的特性,现整理了一些,不断添加中... ...

1、/mnt/mfs空间的大小为chunkserver定义空间空闲的大小,已使用空间为mfs所存储的数据容量。

2、在任一台client执行chmod -R nobody:nobody /mnt/mfs(任意操作),所有client看到的结果是一样的。

3、mfschunkfile 用来检查给定的文件以多少副本数来存储。

引用

#mfscheckfile /mnt/mfs/folder1/mfs-1.6.15.tar.gz
/mnt/mfs/folder1/mfs-1.6.15.tar.gz:
1 copies: 1 chunks

说明有一个副本存储在一个 chunk里。

4、设定、查看的目标mfssetgoal、mfsgetgoal副本数
引用

mfssetgoal 3 /mnt/mfs/folder1
mfsgetgoal /mnt/mfs/folder1

5、mfsdirinfo 显示了目录、文件及 chunks 的数目,还有整个目录占用磁盘空间的情况
引用

mfsdirinfo /mnt/mfs/floder1/
inodes:                          2
  directories:                    1
  files:                          1
chunks:                          1
length:                   44145890
size:                     44176384
realsize:                 88352768  包括所有副本的大小。

6、mfsfileinfo 显示文件基本信息。
引用

mfsfileinfo /mnt/mfs/folder1/ccav.dat

7、mfsgettrashtime 验证、查看数据删除回收时间,默认为86400(1天)
引用

mfsgettrashtime -r /mnt/mfs/folder1

8、配置mfssettrashtime 数据删除回收时间
引用

mfssettrashtime 3600 /mnt/mfs/folder1
mfsmount -o nonempty -m /mnt/mfsmeta -H mfsmaster
/mnt/mfsmeta/trash/  已标志删除的文件[回收站]
/mnt/mfsmeta/trash/undel 还原文件
mv /mnt/mfsmeta/trash/* undel

被删文件的文件名在 “垃圾箱”目录里还可见,文件名由一个八位十六进制的数 i-node 和被删文
件的文件名组成,在文件名和 i-node 之间不是用“/”,而是用了“|”替代。
如:00000004|folder1|jdk-1_5_0_20-linux-amd64.bin

在 MFSMETA 的目录里,除了 trash 和 trash/undel 两个目录外,还有第三个目录 reserved,该目
录内有已经删除的文件,但却有一直打开着。在用户关闭了这些被打开的文件后,reserved 目录中的
文件将被删除,  文件的数据也将被立即删除。 reserved 目录中文件的命名方法同 trash 目录中的一样 ,
在但是不能有其他功能的操作。
/mnt/mfsmeta/reserved

9、大于64MB的文件将进行分片存储。
如tb_access_20100517.tar.gz 文件被分成了25个片,文件本身配置成4个副本。
引用

/usr/bin/mfsfileinfo tb_access_20100517.tar.gz 
tb_access_20100517.tar.gz:
  chunk 0: 0000000000016121_00000001 / (id:90401 ver:1)
    copy 1: 19.2.172.134:9422
    copy 2: 19.2.172.135:9422
  chunk 1: 00000000000161D8_00000001 / (id:90584 ver:1)
    copy 1: 19.2.172.134:9422
    copy 2: 19.2.172.135:9422
  chunk 2: 000000000001625D_00000001 / (id:90717 ver:1)
    copy 1: 19.2.172.134:9422
    copy 2: 19.2.172.135:9422
  chunk 3: 00000000000162E8_00000001 / (id:90856 ver:1)
    copy 1: 19.2.172.134:9422
    copy 2: 19.2.172.135:9422
  chunk 4: 000000000001637E_00000001 / (id:91006 ver:1)
    copy 1: 19.2.172.134:9422
    copy 2: 19.2.172.135:9422
  chunk 5: 0000000000016427_00000001 / (id:91175 ver:1)
    copy 1: 19.2.172.134:9422
    copy 2: 19.2.172.135:9422
  chunk 6: 00000000000164B0_00000001 / (id:91312 ver:1)
    copy 1: 19.2.172.134:9422
    copy 2: 19.2.172.135:9422
  chunk 7: 0000000000016554_00000001 / (id:91476 ver:1)
    copy 1: 19.2.172.134:9422
    copy 2: 19.2.172.135:9422
  chunk 8: 00000000000165F2_00000001 / (id:91634 ver:1)
    copy 1: 19.2.172.134:9422
    copy 2: 19.2.172.135:9422
  chunk 9: 0000000000016690_00000001 / (id:91792 ver:1)
    copy 1: 19.2.172.134:9422
    copy 2: 19.2.172.135:9422
  chunk 10: 000000000001673B_00000001 / (id:91963 ver:1)
    copy 1: 19.2.172.134:9422
    copy 2: 19.2.172.135:9422
  chunk 11: 00000000000167E6_00000001 / (id:92134 ver:1)
    copy 1: 19.2.172.134:9422
    copy 2: 19.2.172.135:9422
  chunk 12: 000000000001686D_00000001 / (id:92269 ver:1)
    copy 1: 19.2.172.134:9422
    copy 2: 19.2.172.135:9422
  chunk 13: 0000000000016927_00000001 / (id:92455 ver:1)
    copy 1: 19.2.172.134:9422
    copy 2: 19.2.172.135:9422
  chunk 14: 00000000000169C4_00000001 / (id:92612 ver:1)
    copy 1: 19.2.172.134:9422
    copy 2: 19.2.172.135:9422
  chunk 15: 0000000000016A62_00000001 / (id:92770 ver:1)
    copy 1: 19.2.172.134:9422
    copy 2: 19.2.172.135:9422
  chunk 16: 0000000000016B16_00000001 / (id:92950 ver:1)
    copy 1: 19.2.172.134:9422
    copy 2: 19.2.172.135:9422
  chunk 17: 0000000000016BB8_00000001 / (id:93112 ver:1)
    copy 1: 19.2.172.134:9422
    copy 2: 19.2.172.135:9422
  chunk 18: 0000000000016C54_00000001 / (id:93268 ver:1)
    copy 1: 19.2.172.134:9422
    copy 2: 19.2.172.135:9422
  chunk 19: 0000000000016CE6_00000001 / (id:93414 ver:1)
    copy 1: 19.2.172.134:9422
    copy 2: 19.2.172.135:9422
  chunk 20: 0000000000016DB2_00000001 / (id:93618 ver:1)
    copy 1: 19.2.172.134:9422
    copy 2: 19.2.172.135:9422
  chunk 21: 0000000000016E76_00000001 / (id:93814 ver:1)
    copy 1: 19.2.172.134:9422
    copy 2: 19.2.172.135:9422
  chunk 22: 0000000000016F23_00000001 / (id:93987 ver:1)
    copy 1: 19.2.172.134:9422
    copy 2: 19.2.172.135:9422
  chunk 23: 0000000000016FC8_00000001 / (id:94152 ver:1)
    copy 1: 19.2.172.134:9422
    copy 2: 19.2.172.135:9422
  chunk 24: 000000000001708F_00000002 / (id:94351 ver:2)
    copy 1: 19.2.172.134:9422
    copy 2: 19.2.172.135:9422

10、恢复master故障
  1、在master服务器上的恢复方法,如只是主机电源故障,更新后重启。
  运行:mfsmetarestore -a
  确保/www/lib/mfs/有metadata.mfs.back及changelog_ml.*.mfs
  2、从metalogger服务器恢复
  将/www/lib/mfs下的metadata.mfs.back及changelog_ml.*.mfs 复制到master的/www/lib/mfs目录。
运行:mfsmetarestore -m metadata.mfs.back -o metadata.mfs changelog_ml.*.mfs或mfsmetarestore -a。
*changelog_ml.*.mfs *表示最近50(默认)个小时的文件变化日志。

11、安全的停止MooseFS集群
引用

1.在所有的客户端卸载 MooseFS 文件系统(用 umount 命令或者是其它等效的命令)  umount /mnt/mfs
2.用 mfschunkserver –s 命令停止 chunkserver 进程
3.用 mfsmetalogger –s 命令停止 metalogger 进程
4.用 mfsmaster –s 命令停止 master 进程


12、安全的启动MooseFS集群
引用

1、mfsmaster start 命令启动 master 进程
2、mfschunkserver start 命令启动 chunkserver 进程
3、mfsmetalogger start 命令启动 metalogger 进程
4、在所有的客户端挂载 MooseFS 文件系统  /usr/bin/mfsmount /mnt/mfs -H mfsmaster

阅读(1236) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~