软件：MooseFS 1.6.20
安装方式： RPM包
安装Master服务器
和官方的安装指导使用编译安装方式不同，通过RPM包安装，首先要导入第三方的仓库
下载 仓库配置文件
Wget
安装配置文件
rpm -i rpmforge-release-0.5.2-2.el5.rf.*.rpm
搜索RPM包
yum search mfs
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* rpmforge: apt.sw.be
===================Matched: mfs =======================
mfs.x86_64 : Fault tolerant, network distributed file system
mfs-cgi.x86_64 : Status CGI for MooseFS
mfs-client.x86_64 : Client tools for MooseFS
其中三个包mfs.x86_64是主程序包，mfs-cgi.x86-64是用于apache主机的cgi监控，如果你不用apache，可以不用安装的。第三个包mfs-client，是给客户端安装的，需要fuse的相关依赖性予以支持。
修改配置文件并启动服务器
1、切换目录
#cd /etc
2、复制样例文件，以得到master 所需的配置文件
#cp mfsmaster.cfg.dist mfsmaster.cfg
#cp mfsmetalogger.cfg.dist mfsmetalogger.cfg
#cp mfsexports.cfg.dist mfsexports.cfg
mfsmaster.cfg包含了服务器的相关设置，配置文件mfsexports.cfg
配置元数据文件，初次安装的时候，元数据文件只是一个空文件，在启动服务器之前，必须做如下配置
1、切换目录
#cd /var/mfs
2、重命名文件
#cp metadata.mfs.empty metadata.mfs
启动服务器
#/usr/sbin/mfsmaster start
启动CGI监控页面
/usr/local/sbin/mfscgiserv start
Mfscgiserv是用python编写的一个web服务器，监听端口是9425。用户利用浏览器就可全面监控所有客户挂载、服务器状态、磁盘IO信息、客户端的各种操作等等。
mfsexports.cfg文件的配置
[root@mfsMaster mfs]# vim mfsexports.cfg
# Allow everything but "meta".
* / rw,alldirs,maproot=0
# Allow "meta".
* . rw
# Some examples:
# Users from any IP can mount root directory as a read-only file system. Local roots are mapped as users with uid:gid = 999:
999.
#* / ro
# Users from IP 192.168.1.0-192.168.1.255 can mount root directory as a standard read/write file system. Local roots are map
ped as users with uid:gid = 999:999.
#192.168.1.0/24 / rw
# Users from IP 192.168.1.0-192.168.1.255 when give password 'passcode' can mount any subdirectory as a standard read/write
file system. Local roots are left unmapped.
#192.168.1.0/24 / rw,alldirs,maproot=0,password=passcode
# Users from IP 10.0.0.0-10.0.0.5 when give password 'test' can mount 'test' subdirectory as a standard read/write file syst
em. Local roots are mapped as 'nobody' users (usually uid=65534).
#10.0.0.0-10.0.0.5 /test rw,maproot=nobody,password=test
# Users from IP 10.1.0.0-10.1.255.255 can mount 'public' subdirectory as a standard read/write file system. All users are ma
pped as users with uid:gid = 1000:1000.
#10.1.0.0/255.255.0.0 /public rw,mapall=1000:1000
该文件每一行分为三部分：
第一部分：被允许接入的客户端的ip地址
第二部分：被挂接的目录
第三部分：客户端的权限
第一部分IP地址可以指定多种形式：
* 所有的ip地址
n.n.n.n 单个ip地址
n.n.n.n/m IP网络地址/位数掩码
n.n.n.n/m.m.m.m IP网络地址/子网掩码
a.a.a.a-b.b.b.b IP段
第二部分 目录用以下表示：
/ 表示MooseFS 文件系统的根;
. 表示MFS META 元数据文件系统
第三部分 权限有以下选项：
ro 只读的模式共享
rw 读写的模式共享
alldirs 允许挂载任意指定的子目录
maproot 映射本地root到远程服务器上的用户
mapall 映射本地其他用户到远程服务器上的用户
password 指定客户端挂载密码
安装Metalogger服务器
拷贝配置文件并编辑
cp mfsmetalogger.cfg.dist mfsmetalogger.cfg
修改配置文件MASTER_HOST = 16.157.134.165
安装chunk服务器
因为RPM包编译后，服务器进程默认的执行用户是daemon，所以必须给mfshdd.cfg中指定的路径赋予权限，允许其读写。执行以下语句:
chmod –R daemon:daemon /mnt/mfschunks1
使用mfschunk start初始化 目录，大概要浪费掉300mb的空间。Chuck块大小是64MB,block块大小是64KB,原始设计倾向于保存大文件。效验和的开销：Block 每64KB是4B，所以Chunk每64MB是4KB。
在线热拔插硬盘
需要注意的是必须保证任何一个chunks有2个以上的备份（goal）才可以安全的移除主机或磁盘。
第一步，首先编辑待去除硬盘主机的/etc/mfs/mfshdd.cfg文件，把需要去除的路径前面标记*号 ，例如：
# mount points of HDD drives
#/mnt/hd1
#/mnt/hd2
#etc.
/mnt/mfschunks1
*/mnt/mfschunks2
第二步，重启chunkserver进程
# mfschunkserver restart
working directory: /var/mfs
sending SIGTERM to lock owner (pid:3532)
waiting for termination ... terminated
initializing mfschunkserver modules ...
hdd space manager: scanning folder /mnt/mfschunks1/ ...
hdd space manager: scanning complete
hdd space manager: /mnt/mfschunks1/: 0 chunks found
hdd space manager: scanning complete
main server module: listen on *:9422
stats file has been loaded
mfschunkserver daemon initialized properly
第三步查看 CGI页面，可以观察到相应的硬盘已经标记marked for removal，这个时候说明MFS软件已经阻止任何新的IO写入该磁盘。并且要在CGI页面中确认undergoal的chunk数量为0，否则说明还有chunk没有完整的备份到其他服务器上。做完以上这些工作，停止mfschunkserverstop，即可安全的移除磁盘了。
客户端挂载MFS文件系统
mfsmount /mnt/mfstest(本地挂载点) -H 16.157.134.165 (Master主机IP或域名)
挂载MFS META文件系统
挂载该系统主要是为了恢复被误删除的文件，挂载命令为：
mfsmount -m /mnt/mfstest -H 16.157.134.165 (Master主机IP或域名)
文件系统结构如下：
[root@mfsClient2 mfstest]# ll
total 0
dr-x------ 2 root root 0 Sep 8 15:24 reserved
drwx------ 3 root root 0 Sep 8 15:24 trash
[root@mfsClient2 mfstest]# cd trash/
[root@mfsClient2 trash]# ls
undel
trash目录中是删除到回收站中的文件，如果移动到undel子目录，那么被删除的文件就会恢复到原MFS文件系统中。只有管理员有权限访问MFSMETA (用户的uid 0，通常是root)。在 MFSMETA的目录里，除了trash和trash/undel两个目录外，还有第三个目录reserved，该目录内有已经删除的文件，但却有一直打开着。在用户关闭了这些被打开的文件后，reserved目录中的文件将被删除，文件的数据也将被立即删除。在reserved目录中文件的命名方法同trash目录中的一样。
系统启动自动挂载
编辑文件 /etc/fstab 加入如下行
mfsmount 挂载点 fuse mfsmaster=MFSMASTER_IP,mfsport=MFSMASTER_PORT,_netdev 0 0
其中的_netdev这个参数 大多数redhat或者debian系统都可以识别，表示该设备在网络服务正常运行后开始挂载，从而避免挂载失败。
系统管理：
MFS系统管理文件系统比较奇怪，由指定权限的客户端管理而不是由master服务器管理，如果不想给予客户端管理的权限，必须在mfsexports.cfg文件中设置为ro权限。它由一系列的get/set管理命令组成：
mfsgeteattr/ mfsseteattr 文件或目录的额外的属性
mfsgetgoal/ mfssetgoal 设置文件的冗余份数，建议设置值为2以上，保证至少允许一台服务器故障
mfsgettrashtime/ mfssettrashtime 设置垃圾箱保留时间，如果设置为0，则表示直接删除，不进入回收站
以上的命令均是对单个文件或者目录起效果，如果想对整个文件系统生效，请在根目录下面使用命令，并且加上递归的参数 –r。
实际的拷贝份数可以通过mfscheckfile 和 mfsfileinfo/mfsdirinfo 命令来证实
[root@mfsClient1 mfstest]# mfscheckfile b
b:
2 copies: 1 chunks
[root@mfsClient1 mfstest]# mfsfileinfo b
b:
chunk 0: 0000000000006334_00000001 / (id:25396 ver:1)
copy 1: 192.168.0.3:9422
copy 2: 192.168.0.4:9422
MFS测试
测试的考量方面主要有两点，一性能测试；二可靠性测试。主要的测试项目如下图所示：
测试环境
|
主机名
|
CPU
|
Mem
|
|
Master
|
2 Core
|
2GB
|
|
MetaLogger
|
1 Core
|
1GB
|
|
Chunk X 3
|
1 Core
|
1GB
|
|
Client X 1
|
1 Core
|
256MB
|
对比测试方案：
1. 本地硬盘测试
2. 不配置MetaLogger服务器
3. 配置MetaLogger服务器
4. Master服务器硬盘由thin升级为thick
5. 网络环境更改为MTU 9K
6. 设置goal为2
测试结果数据和图表如下所示：
表1，本地测试结果
表2，不配置MetaLogger服务器
表3，配置MetaLogger服务器
表4 ，Master服务器硬盘由thin升级为thick
对网络MTU优化后进行测试
主要优化部分，将测试的环境全部更换到MTU 9000，并且开启网卡的相应的一些offload功能，如tcp segmentation offload、generic segmentation offload、generic-receive-offload。
在ESX主机上增加vswitch 并且设置MTU
~ # esxcfg-vswitch -a mfsswitch
~ # esxcfg-vswitch mfsswitch -m 9000
在虚拟机中，在线给VM添加新网卡，网卡类型选择性能最好的VMXNET3。在Linux发现新网卡，并设置相关IP
# kudzu
# system-config-network-tui
# service network restart
设置MTU，并开启相关功能
# ifconfig eth1 mtu 9000
# ethtool -K eth1 gso on
# ethtool -K eth1 gro on
# ethtool -K eth1 tso on
表5，网络环境更改为MTU 9K
表6，设置GOAL 为2
测试结果横向比较
为了消除CPU Cache和Memory Buffer对结果的影响，和考察极端条件下的真实IO能力，我选取上面测试结果中的FileSize=512MB和BlockSize=64KB的Random Read/Write成绩做出下表进行横向比较和研究：
从结果上，是否配置日志备份服务器对性能影响不大。提升Master服务器的配置，对性能有轻微影响。改进MTU 9K对性能影响较大。设置GOAL =2的时候，读的性能获得类似于负载均衡的效果，故有一定的提高，而写入的性能，由于需要等待多台服务器进行同步之后，才能确定write successful，故该参数设置对写性能有负面影响。
可靠性测试
修改goal 目标为1 ，尝试写入大文件的途中，模拟一台chunk服务器网络中断故障的结果：
dd if=/dev/zero of=/mnt/mfstest/test bs=100MB count=50
dd: writing `/mnt/mfstest/test': Input/output error
dd: closing output file `/mnt/mfstest/test': Input/output error
改为goal为2的时候，模拟相同的故障，结果顺利完成写入大文件。为了文件的完整性，建议使用MFS系统时，必须将GOAL 设置为2以上。
MooseFS文件系统介绍 2011-06-07 18:42:13
MooseFS文件系统介绍
MooseFS是一种分布式文件系统，MooseFS文件系统结构包括以下四种角色：
1 管理服务器managing server (master)
2 元数据日志服务器Metalogger server（Metalogger）
3 数据存储服务器data servers (chunkservers)
4 客户机挂载使用client computers
各种角色作用:
1 管理服务器:负责各个数据存储服务器的管理,文件读写调度,文件空间回收以及恢复.多节点拷贝
2 元数据日志服务器: 负责备份master服务器的变化日志文件，文件类型为changelog_ml.*.mfs，以便于在master server出问题的时候接替其进行工作
3 数据存储服务器:负责连接管理服务器,听从管理服务器调度,提供存储空间，并为客户提供数据传输.
4 客户端: 通过fuse内核接口挂接远程管理服务器上所管理的数据存储服务器,.看起来共享的文件系统和本地unix文件系统使用一样的效果.
MooseFS优点
1.开源
2.通用文件系统，不需要要修改上层应用就可以使用
3.可以在线扩容，体系架构可伸缩性极强
4.部署简单
5.体系架构高可用，所有组件无单点故障
6.文件对象高可用，可设置任意的文件冗余程度，而绝对不会影响读写的性能，只会加速
7，提供如windows回收站的功能，
8.提供类似java语言GC(垃圾回收)
9.提供netapp,emc,ibm等商业存储的snapshot特性
10.google filesystem 的一个c实现
11.提供web gui监控接口
12.提高随机读写的效率
13.提高海量小文件的读写效率
MooseFS 1.6版本改进
1.修改1.5中的大批量操作时打开文件过多的bug
2.新增加了masterlogger服务器，在1.5中没有的，就是做了master服务器的冗余，进一步的加强master服务器的稳定性，在mfs体系中master是要求最稳定以及性能要求最高的，因此务必保证master的稳定
3.修改1.5中存在的对于坏块的修复功能，在mfs1.5中遇到chunker坏块校验，错误比较多的是往往导致master将出现坏块的chunker自动剔除出去的情况，此次增加了对坏块的修复功能，很方便的进行修复，简化对坏块的处理功能。
4.对metadata和changelog的新认识，之前认为changelog记录的是文件的操作，定期的像数据库的日志一样归档到metadata中,发现上面的理解存在误区，真正的是changelog中记录了对文件的操作，metadata记录文件的大小和位置，因此metadata是比较重要的，在进行修复的过程中是采用metadata和最后一次changelog进行修复。
5.MFS 文档中明确指出对于内存和磁盘大小的要求
6.指出了在测试的过程中多个chunker并不影响写的速度，但是能加快读的速度，在原来的基础上增加一个chunker时，数据会自动同步到新增的chunker上以达到数据的平衡和均衡。
常见问题，
1.master性能瓶颈，主要是可扩展性不强
2.体系架构存储文件总数的瓶颈，mfs把文件系统的结构缓存到master内存中，这样文件越多，master的内存消耗越大，8G对应2500kw文件数，2亿就的64G内存
3.单点故障解决方案的健壮性
4.垃圾回收 把默认的86400改为300秒，这样可以免的垃圾还没回收完，你的存储容量就暴掉了。
mfs的原理：
就是客户端请求master，master分派他去哪里读数据，
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，将其加载到内核中
matedata.mfs.back文件将消失，那么要恢复整个mfs,则需从metalogger服务器取得该文件。请特别注意这个文件，它与日志文件一起，才能够恢复整个被损坏的分布式文件系统。
