第1章 介绍
写在前面，自己的理解。
对比nfs文件共享系统，其目的都是一样的。nfs的运行过程是客户端先向服务端的rpc服务请求nfs的端口号，然后客户端再根据端口号找到对应的nfs服务，进行读写。
而mfs将nfs服务端的结构再进行细分，mfs的主服务端（master server）仅仅充当一个类似rpcbind的作用，而真正的数据存放在别的主机上（chunk server），客户端向mfs主服务端请求存储位置，主服务端回复客户端数据存放的位置，客户端根据返回的位置寻找对应主机进行读写。
另mfs自带高可用，它还有一个元数据备份服务器（metalogger Server），当主服务端（master server）产生问题时，它可以暂时顶替。
1.1介绍
MooseFS是一个具备冗余容错功能的分布式网络文件系统，它将数据分别存放在多个物理服务器或单独磁盘或分区上，确保一份数据有多个备份副本。对于访问的客户端或者用户来说，整个分布式网络文件系统集群看起来就像一个资源一样。从其对文件操作的情况看，MooseFS就相当于一个类UNIX文件系统:
1、mfs是一个分层的目录树结构
2、存储支持POSIX标准的文件属性（权限，最后访问和修改时间）
3、支持特殊的文件，如：块设备，字符设备，管道和套接字，链接文件（符号链接和硬链接）
4、支持基于IP地址和密码的方式访问文件系统
1.2特性
1、高可靠性，每一份数据可以设置多个副本（多份数据），并可以存储在不同的主机上
2、高可扩展性，可以很轻松的通过增加主机磁盘容量或增加主机数量来动态扩展整个文件系统的存储量
3、高可容错性，我们可以通过对mfs进行系统设置，实现当数据文件被删除后的一段时间内，依然存放于主机的回收站中，以备误删恢复数据
4、高数据一致性，即便文件被写入/访问时，我们依然可以完成对文件的一致性快照
1.3优缺点
优点：
1、由于MFS是基于GPL发布的，因此完全免费，并且开发和社区都很活跃，资料也非常丰富
2、轻量、易部署、易配置、易维护
3、通用文件系统，不需要修改上层应用就可以使用（那些需要专门 API 的DFS确实有点麻烦）
4、扩容成本低、支持在线扩容，不影响业务，体系架构可伸缩性极强（官方的case可以扩到70台了！）
5、体系架构高可用，所有组件无单点故障
6、文件对象高可用，可设置任意的文件冗余程度（提供比 Raid 10 更高的冗余级别）
7、提供系统负载，将数据读写分配到所有的服务器上，加速读写性能
8、提供诸多高级特性，比如类似Windows的回收站功能、类似JAVA语言的GC（垃圾回收）、快照功能等
9、MooseFS 是 Google Filesystem 的一个 c 实现
10、自带 Web Gui 的监控接口
11、提高随机读或写效率和海量小文件的读写效率（有待进一步证明）
缺点：
1、Master Server 本身的性能瓶颈。MFS的主备架构情况类似于MySQL的主从复制，从可以扩展，主却不容易扩展。短期的对策就是按照业务来做切分。
2、随着MFS体系架构中存储文件的总数上升，Master Server对内存的需求量会不断增大（MFS把文件系统的结构缓存到 Maset Server 的内存中）。根据官方提供的数据，8g对应2500kw的文件数，2亿文件就得64GB内存。短期的对策也是按照业务来做切分。
3、Master server的单点解决方案的健壮性。目前官方自带的是把数据信息从MasterServer同步到MetaloggerServer上，MasterServer一旦出问题MetaloggerServer可以恢复升级为MasterServer，但是需要恢复时间。目前，也可以通过第三方的高可用方案（heartbeat+drbd+moosefs）来解决 Master Server 的单点问题。
4、Metalogger Server 复制元数据的间隔时间较长（可调整）
1.4应用场景
谈及MooseFS的应用场景，其实就是去谈分布式文件系统的应用场景。
1、大规模高并发的数据存储及访问（小文件、大文件），TFS适合小文件（<1M）
2、大规模的数据处理，如日志分析
1.5架构图
整个架构中，主要有四个组件，分别是管理服务器 Master Server、备份服务器Metalogger Server、数据存储服务器 Chunk Server 和 客户端 Client。
管理服务器 Master Server负责所有数据存储服务器的数据存储管理，响应客户端文件的读写请求，收回文件空间以及恢复文件，多存储节点之间的文件复制；
元数据日志服务器 Metalogger Server，对 Master Server 服务器的变化日志文件进行备份，changelog_ml.*.mfs 是备份文件的类型，当 Master Server 出现故障时替换其继续工作，避免 Master Server 的单点故障导致分布式文件系统的不能正常运行；
数据存储服务器chunkserver，服从 Master Server 的安排，定期向 Master Server 发送自己的状态信息，除此之外，还能向客户提供数据存储空间，能够向客户传输数据；
客户端 Client，通过 FUSE 内核接口挂载到数据存储服务器上，在客户端看来使用数据存储服务器上的文件系统和使用本地Unix文件系统是一样的。
组件 |
作用 |
管理服务器 Master Server |
这个组件的角色是管理整个mfs文件系统的主服务器，除了分发用户请求外，还用来存储整个文件系统中的每个数据文件的metadata信息，metadata（元数据）信息包括文件（也可以是目录、socket、管道、设备等）的大小、属性、文件位置路径等，以及文件空间的回收和恢复，控制多chunk server节点的数据拷贝。很类似lvs负载均衡主服务器，不同的是lvs仅仅根据算法分发请求，而master根据内存里的metadata信息来分发请求。这个master只能有一台处于激活工作的状态。 |
元数据备份服务器 metalogger Server |
这个组件的作用是备份管理服务器master的变化的metadata信息日志文件，文件类型为changelog_ml.*.mfs，以便于在主服务器出现问题的时候，可以经过简单的操作即可让新主服务器进行工作。这很类似Mysql的主从同步，只不过他不像mysql从库那样在本地应用数据，而只是接收主服务器上文件写入时记录的文件相关的metadata信息。这个backup可以有一台或多台，它很类似于lvs从负载均衡器。 |
数据存储服务器组 Chunk Servers |
这个组件就是真正存放数据文件实体的服务器了，这个角色可以有多台不同的物理服务器或不同的磁盘及分区来充当，当配置数据的副本多于一份时，剧写入到一个数据服务器后，会根据算法在其他数据服务器上进行同步备份。这个很像lvs集群的rs节点。 |
客户机服务器组 Client |
这个组件就是挂载并使用mfs文件系统的客户端，当读写文件时，客户端首先连接主管理服务器获取数据的metadata信息，然后根据得到的metadata信息，访问数据服务器读取或写入文件实体。mfs客户端通过FUSE mechanism实现挂载MFS文件系统的。因此，只要系统支持FUSE，就可以作为客户端访问MFS整个文件系统。所谓的客户端并不是网站用户，而是前端访问文件系统的应用服务器，如web |
1.6读写原理
1.6.1读的原理
三角形为master server 矩形是client 圆形是chunk server
①客户端向master server发送请求
②master server告诉客户端数据存放的位置
③客户端向给出的位置即chunkserver 请求数据
④chunk server返回数据
1.6.2写的流程
①客户端向master server发送请求写入数据
②主服务器master查询缓存记录，如果是新文件，则会联系后面的数据服务器创建对应的chunk对象准备存放文件。
③主服务器master把文件实体的位置等相关信息发给client客户端。
④Client客户端访问对应的数据服务器写数据
⑤多个chunk server同步用户写入的数据
⑥同步成功
⑦chunk server返回客户端写入成功的信号
⑧Client客户端回报给主服务器master写入结束
1.7生产环境各组件硬件要求
1.7.1Master Server
由于 Master Server 控制着整个 MooseFS 中的各个组件，并且负责对外提供服务，因此我们一定需要保证 MasterServer 处于非常稳定的状态。比如，针对 Master Server采用双电源双路配置，多块磁盘使用RAID1或RAID10，进行冗余。
前面也提到，Master Server 将所有访问的元数据信息都放在内存当中，提供用户访问。因此，当文件数量增加的时候，内存使用量也会增加。根据官方的数据，100万个文件chunk信息，大概需要300M的内存空间来进行。对于磁盘来讲，Master Server 对磁盘的使用量不是很大，这个取决于所用的文件和chunk块的数目（记录在主元数据文件）以及对文件作出操作的数量（记录在元数据更改日志），一般情况下 20G 可以用来存储信息 2500 万个文件变更记录长达50小时。由此看来，作为Master Server 内存量够大才是重中之重。
总结：双电源双路，raid1或raid10，大内存
1.7.2Metalogger Server
由于需要做管理服务器的高可用备份，所以配置与Master Server一样即可
1.7.3Chunk Server
作为真正存储数据的载体，重点保证磁盘性能即可。需要注意尽量保持个主机之间磁盘大小一致
第2章 mfs部署
2.1主机规划
组件 |
主机名 |
IP |
管理服务器 Master Server |
master |
10.0.0.103 |
元数据备份服务器 Metalogger Server |
metalogger |
10.0.0.104 |
数据存储服务器1 Chunk Servers |
chunk1 |
10.0.0.105 |
数据存储服务器2 Chunk Servers |
chunk2 |
10.0.0.106 |
客户机服务器 Client |
web |
10.0.0.107 |
2.2更新yum源及安装
向包管理器添加相应的密钥（以下两步在所有主机执行）
[root@master ~]# curl"http://ppa.moosefs.com/RPM-GPG-KEY-MooseFS">/etc/pki/rpm-gpg/RPM-GPG-KEY-MooseFS 添加yum源 [root@master ~]# curl"http://ppa.moosefs.com/MooseFS-3-el6.repo"> /etc/yum.repos.d/MooseFS.repo master端安装 [root@master ~]# yum install -y moosefs-mastermoosefs-cli moosefs-cgi moosefs-cgiserv chunk端安装 [root@chunk01 ~]# yum install -ymoosefs-chunkserver metalogger端安装 [root@metalogger ~]# yum install moosefs-metalogger-y 客户端安装 [root@web ~]# yum install moosefs-client -y
2.3配置
2.3.1配置master端
[root@master mfs]# ll /etc/mfs total 44 -rw-r--r-- 1 root root 4102 Oct 10 18:45mfsexports.cfg -rw-r--r-- 1 root root 4057 Aug 2 19:43 mfsexports.cfg.sample -rw-r--r-- 1 root root 8521 Oct 10 17:49mfsmaster.cfg -rw-r--r-- 1 root root 8521 Aug 2 19:43 mfsmaster.cfg.sample -rw-r--r-- 1 root root 1052 Oct 10 17:49mfstopology.cfg -rw-r--r-- 1 root root 1052 Aug 2 19:43 mfstopology.cfg.sample
这是mfs的三个配置文件
mfsmaster.cfg ：主文件
mfsexports.cfg ：mfs挂载权限设置，参考NFS文件系统中的exports.cfg
mfstopology.cfg ：机架感知
[root@master mfs]# vim mfsexports.cfg(把前面两行没注释的删掉) 10.0.0.0/24 / rw,alldirs,maproot=0:0 #类似nfs的export配置文件 [root@master mfs]# /etc/init.d/moosefs-master start
2.3.2配置chunk server端
[root@chunk01 ~]# sed -i '71a MASTER_HOST = 10.0.0.103'/etc/mfs/mfschunkserver.cfg [root@chunk01 ~]# echo "/tmp" >/etc/mfs/mfshdd.cfg #将/tmp目录作为存放数据的目录 [root@chunk01 ~]# /etc/init.d/moosefs-chunkserverstart 这里看一下tmp目录，由于是块状文件，所以数据在chunk端是不可读的。 [root@chunk02 ~]# ls /tmp/ 00 08 10 18 20 28 30 38 40 48 50 58 60 68 70 78 80 88 90 98 A0 A8 B0 B8 C0 C8 D0 D8 E0 E8 F0 F8 01 09 11 19 21 29 31 39 41 49 51 59 61 69 71 79 81 89 91 99 A1 A9 B1 B9 C1 C9 D1 D9 E1 E9 F1 F9 02 0A 12 1A 22 2A 32 3A 42 4A 52 5A 62 6A 72 7A 82 8A 92 9A A2 AA B2 BA C2 CA D2 DA E2 EA F2 FA 03 0B 13 1B 23 2B 33 3B 43 4B 53 5B 63 6B 73 7B 83 8B 93 9B A3 AB B3 BB C3 CB D3 DB E3 EB F3 FB 04 0C 14 1C 24 2C 34 3C 44 4C 54 5C 64 6C 74 7C 84 8C 94 9C A4 AC B4 BC C4 CC D4 DC E4 EC F4 FC 05 0D 15 1D 25 2D 35 3D 45 4D 55 5D 65 6D 75 7D 85 8D 95 9D A5 AD B5 BD C5 CD D5 DD E5 ED F5 FD 06 0E 16 1E 26 2E 36 3E 46 4E 56 5E 66 6E 76 7E 86 8E 96 9E A6 AE B6 BE C6 CE D6 DE E6 EE F6 FE 07 0F 17 1F 27 2F 37 3F 47 4F 57 5F 67 6F 77 7F 87 8F 97 9F A7 AF B7 BF C7 CF D7 DF E7 EF F7 FF
2.3.3配置metalogger端
[root@metalogger ~]# vim /etc/mfs/mfsmetalogger.cfg META_DOWNLOAD_FREQ = 1 #每隔1小时同步一下日志 MASTER_HOST = 10.0.0.103
[root@metalogger ~]# /etc/init.d/moosefs-metaloggerstart
2.3.4客户端配置
[root@web ~]# mfsmount /mnt -H 10.0.0.103 [root@web ~]# df -h Filesystem Size Used Avail Use% Mounted on /dev/sda3 8.8G 1.5G 6.9G 18% / tmpfs 238M 0 238M 0% /dev/shm /dev/sda1 190M 40M 141M 22% /boot 10.0.0.103:9421 17G 3.5G 14G 21% /mnt
测试一下
[root@web ~]# dd if=/dev/zero of=/mnt/1.txt bs=1M count=10 去chunk01端查看， [root@chunk01 ~]# tree /tmp/ /tmp/ ├── 00 │ └── chunk_0000000000000001_00000001.mfs ├── 01 ├── 02 ├── 03 同时chunk02 也同步了该数据 [root@chunk02 ~]# tree /tmp/ /tmp/ ├── 00 │ └── chunk_0000000000000001_00000001.mfs ├── 01 ├── 02 ├── 03 随后我又找了一个客户端 也挂载到/mnt下 也能发现1.txt这个文件 [root@m01 ~]# ll /mnt/ total 10240 -rw-r--r-- 1 root root 10485760 Oct 10 19:51 1.txt
其实搭建起来还是很简单的，重点在于理解mfs服务的原理。
有关原理部分借鉴多个博客，如有侵权请联系删除