MFS讲解（一）分布式文件系统的搭建及简单使用

一.概念讲解

1.MooseFS是一个具有容错性的网络分布式文件系统.它把数据分散存放在多个物理服务器上，而呈现给用户的则是一个统一的资源。

2.MooseFS是一个分布式存储的框架，其具有如下特性：

• Free(GPL)
  *通用文件系统，不需要修改上层应用就可以使用（那些需要专门api的dfs很麻烦！）。
• 可以在线扩容，体系架构可伸缩性极强。（官方的case可以扩到70台了！）
• 部署简单。（sa们特别高兴，领导们特别happy！）
  *高可用，可设置任意的文件冗余程度（提供比raid1+0更高的冗余级别，而绝对不会影响读或者写的性能，只会加速！）
• 可回收在指定时间内删除的文件（“回收站”提供的是系统级别的服务，不怕误操作了，提供类似oralce 的闪回等高级dbms的即时回滚特性！）
  *提供netapp，emc，ibm等商业存储的snapshot特性。（可以对整个文件甚至在正在写入的文件创建文件的快照）
• google filesystem的一个c实现。
• 提供web gui监控接口。
• 提高随机读或写的效率（有待进一步证明）。
• 提高海量小文件的读写效率（有待进一步证明）

3.MFS的读数据过程

（1）client当需要一个数据时，首先向master server发起查询请求；
（2）管理服务器检索自己的数据，获取到数据所在的可用数据服务器位置ip|port|chunkid；
（3）管理服务器将数据服务器的地址发送给客户端；
（4）客户端向具体的数据服务器发起数据获取请求；
（5）数据服务器将数据发送给客户端；

4.MFS的写数据过程

（1）当客户端有数据写需求时，首先向管理服务器提供文件元数据信息请求存储地址（元数据信息如：文件名|大小|份数等）；
（2）管理服务器根据写文件的元数据信息，到数据服务器创建新的数据块；
（3）数据服务器返回创建成功的消息；
（4）管理服务器将数据服务器的地址返回给客户端(chunkIP|port|chunkid)；
（5）客户端向数据服务器写数据；
（6）数据服务器返回给客户端写成功的消息；
（7）客户端将此次写完成结束信号和一些信息发送到管理服务器来更新文件的长度和最后修改时间

5.MFS的删除文件过程

（1）客户端有删除操作时，首先向Master发送删除信息；
（2）Master定位到相应元数据信息进行删除，并将chunk server上块的删除操作加入队列异步清理；
（3）响应客户端删除成功的信号

6.MFS修改文件内容的过程

（1）客户端有修改文件内容时，首先向Master发送操作信息；
（2）Master申请新的块给.swp文件，
（3）客户端关闭文件后，会向Master发送关闭信息；
（4）Master会检测内容是否有更新，若有，则申请新的块存放更改后的文件，删除原有块和.swp文件块；若无，则直接删除.swp文件块。

7.MFS重命名文件的过程

（1）客户端重命名文件时，会向Master发送操作信息；
（2）Master直接修改元数据信息中的文件名；返回重命名完成信息；

8.MFS遍历文件的过程

（1）遍历文件不需要访问chunk server，当有客户端遍历请求时，向Master发送操作信息；
（2）Master返回相应元数据信息；
（3）客户端接收到信息后显示

9.概念：

1.在docker中可以起很多个虚拟机，因为其和物理机的的内核是共享的
2.不论在物理机监控（zabbix，会存起来，数据会保留一段时间），还是云端监控（容器或虚拟机（微服务，普罗米修斯）），会自动拉起回收
3.mfs主要的应用有网盘
4.hadoop：大数据，有一个分布式框架
5.操作系统是红帽的最好，rhel>oel（调参不同）>centos
前端cgi命令行cli
6.不同的端口承担不同的角色(9419,9420,9421）
7.master端是单线程运作的，频率高，cpu不需要太好，内存要大，分布式文件系统，做整个分布式文件系统的缓存，存放的都是原数据（包含一些关键字类的信息）
8.其他数据在这个数据服务器（chunkserver）上
9.64G内存差不多是两亿个文件，和数量有关，和大小无关
10.chunkserver是多线程，磁盘要求高（因为其是真正存储数据的）
11.如果一个磁盘是单独存储的尽量不要多分区，否则万一出现问题，所有的都可能崩溃
12.iscsi是网络磁盘
13.数据在，但是无法访问，因为分区表没有了（如果知道起始和结束就可以继续查看，可以大部分情况下是不会记这个的）
14.挂了一个数据点还是多个意思是不是分区
15.存储挂上之后才可以更改权限，对设备有权限
16.在文件中写上存储点，以便于数据访问
17.一个t存一个点有点浪费
18.block size如果存的东西大，就不要存的少
19.如果block分区分的少，则block数量分的越多，同时增大了寻址的时间
20.不能去访问master（操作系统本身的缓存信息）
21.3份放不下（200/64），解决了冗余的问题
22.分布式文件存储系统，解决海量数据存储问题
23.mster端的原数据（内存大小决定了数量，cpu与操作有关，成正比）
24.原数据都在内存中（但是放在内存中容易丢失，所以需要做镜像）
25.需要读取这个文件metadata.mfs，开机后会生成back
26.如果实在没办法，metadata.mfs.empty会丢失一个小时的数据
27.分布式文件系统中有一个好处就是返回的是地址链表，如果有问题，会返回下一个，即server2有问题，就会访问server3
28.pacemaker做心跳
29.内核崩溃只能用fence
30.master关闭后不能使用df
31.Master记录着管理信息，比如：文件路径|大小|存储的位置(ip,port,chunkid)|份数|时间等，元数据信息存在于内存中，会定期写入metadata.mfs.back文件中，定期同步到metalogger，操作实时写入changelog.*.mfs，实时同步到metalogger中。master启动将metadata.mfs载入内存，重命名为metadata.mfs.back文件。
32.文件以chunk大小存储，每chunk最大为64M，小于64M的，该chunk的大小即为该文件大小（验证实际chunk文件略大于实际文件），超过64M的文件将被切分，以每一份（chunk）的大小不超过64M为原则；块的生成遵循规则：目录循环写入(00-FF 256个目录循环，step为2)、chunk文件递增生成、大文件切分目录连续。
33.Chunkserver上的剩余存储空间要大于1GB（Reference Guide有提到），新的数据才会被允许写入，否则，你会看到No space left on device的提示，实际中，测试发现当磁盘使用率达到95%左右的时候，就已经不行写入了，当时可用空间为1.9GB。
34.文件可以有多份copy，当goal为1时，文件会被随机存到一台chunkserver上，当goal的数大于1时，copy会由master调度保存到不同的chunkserver上，goal的大小不要超过chunkserver的数量，否则多出的copy，不会有chunkserver去存。

二.实验

实验环境：

～～～～～～～～～～～～～～～～～～
server1 172.25.27.1 mfs的master
server2 172.25.27.2 mfs的chunk
server3 172.25.27.3 mfs的chunk
物理机 172.25.250.27 client
～～～～～～～～～～～～～～～～～～

说明：

角色	角色作用
管理服务器 managing server (master)	负责各个数据存储服务器的管理,文件读写调度,文件空间回收以及恢复.多节点拷贝
元数据日志服务器 Metalogger server（Metalogger）	负责备份master 服务器的变化日志文件，文件类型为changelog_ml.*.mfs ，以便于在master server 出问题的时候接替其进行工作