CC00023.LBCHAC——|分布式存储之MFS.V1|——|6台server|...

一、什么是MFS

### --- MFS：
~~~     MooseFS是一个具备冗余容错功能的分布式网络文件系统，
~~~     它将数据分别存放在多个物理服务器或单独磁盘或分区上，确保一份数据有多个备份副本，
~~~     然而对于访问MFS的客户端或者用户来说，整个分布式网络文件系统集群看起来就像一个资源一样、
~~~     从其对文件系统的情况看MooseFS就相当于UNIX的文件系统

### --- 单个文件就是存储的最小单位，
~~~     对于上层应用来说认为是存在本地，其实是存储在远程的存储设备

### --- 冗余：良性冗余：
~~~     重要的文件备份了多份；恶性冗余：不重要的文件备份了多份，就是一个文件进行了多个节点的备份

### --- 容错：
~~~     当文件损坏之后还是可以进行恢复的。

### --- MFS特性：
### --- 高可靠性：
### --- 单主机或两个主机死亡数据不会丢失。

~~~     每一份数据可以设置多个备份(多份数据)并可以存储在不同的主机上，

### --- 高可扩展性：
~~~     可以很轻松的通过增加主机的磁盘容量或增加主机数量来动态扩展整个文件系统的存储量

### --- 高可容错性：
~~~     我们可以通过对MFS进行系统设置，实现当数据文件被删除后的一段时间内，
~~~     依旧存放在主机的回收站中。以备#误删除恢复数据

### --- 高数据一致性：
~~~     及时文件被写入，访问时，我们依然可以轻松完成对文件的一致性快照

### --- NFS缺点：NFS社区版本：只能一个节点master配置，NFS企业版：是可以两个节点配置master

~~~     Master目前是单节点(master宕机后集群会失效，数据不会丢失但不可以为应用使用)，
~~~     虽然会把数据信息同步到备份服务器，但是恢复需要时间
~~~     (会有一个备份服务器，会进行实时数据备份，数据不会丢失)
~~~     master服务器对主机的内存要求略高(把所有的源数据存储在内存中)
~~~     默认Metalogger复制元数据(完整备份)时间较长(可调整)

### --- 注：内存使用问题：
### --- 处理一百万个文件chunkserver，大概需要300M的内存空间，

~~~     据此，推算出如果未来要出来1个亿的文件chunkserver，
~~~     大概需要30G内存空间(标配服务的内存是64GB)

### --- MFS适用场景
### --- 应用场景

### --- 大规模高并发的线上数据存储及访问(小文件，大文件都适合)
### --- 大规模的数据处理，如日志分析，小文件强调性能不用HDFS。

二、MFS组件说明

1、MFS结构及原理

### --- MFS MASTER：
~~~     存数据的Metadata存储数据的元数据信息的，比如文件大小，存在哪里，文件的属主权限

### --- CHUNKSERVER：
~~~     文件会被分成不同的chunkserver进行存储，存储真实数据的服务。

### --- client：
~~~     客户端

2、MFS组件角色说明

### --- 管理服务器(managing server 简称master)：

~~~     这个组件的角色是管理整个mfs文件系统的主服务器，除了分发用户请求外，
~~~     还用来存储整个文件系统中每个数据文件的metadata信息，
~~~     # metadate(元数据)信息包括文件(也可以是目录，socket，管道，块设备等)的大小，
~~~     # 属性，文件的位置路径等。
~~~     # 社区版本有且只能存在一个；企业版可以有2个。

### --- 元数据备份服务器Metadata backup servers简称metalogger：

~~~     这个组件的作用是备份管理服务器master的变化metadata信息日志文件，
~~~     文件类型为changelog_m1.*.mfs。以便于管理服务器出问题是，
~~~     可以经过简单的操作即可让服务器进行工作。
~~~     # metalogger实时的和metadate保持联系，备份metadata数据信息。
~~~     # 保证元数据的完整性。可以存在多个

### --- 数据存储服务器组data servers(chunk servers)简称data：

~~~     这个组件就是真正存放数据文件实体的服务器了，
~~~     这个角色可以有多台不同的物理服务器或不同的磁盘及分区来充当，
~~~     当配置数据的副本多于一份时，据写入到一个数据服务器后，
~~~     会根据算法在其他数据服务器上进行同步备份；可以存在多个。

### --- 客户机服务器组(client servers)简称client：

~~~     这个组件就是挂载并使用mfs文件系统的客户端，
~~~     当读写文件时，客户端首先会链接主管理服务器获取数据的metadata信息，
~~~     然后根据得到的metadata信息，访问数据服务器读取或写入文件实体，mfs客户端通过
~~~     # fusemechanism(用户空间文件系统，IBM和微软开发出来的，
~~~     # 可以在用户层去构建文件系统，使用文件系统)，
~~~     实现挂载mfs文件系统，因此只有系统支持fuse，
~~~     就可以作为客户端访问mfs整个文件系统：可以存在多个

三、增/删/改/查/读/遍历

1、基础环境

### --- Client：客户端
### --- MFS-Master：master服务器
### --- MFS-ChunkServer：2台
### --- MFS-MetaData：1台备份服务器

2、读/遍历

### --- 遍历：
~~~     ls /：查看根下有哪些内容；这种方式就是遍历。

### --- 遍历：
~~~     Client客户端向MFS-Master服务器发出请求，需要访问某一个文件；
~~~     MFS-Master会检索自己存储的数据信息，检索弯沉后把对应的元数据信息直接发送给client端，
~~~     遍历的时候没有接受到真实的数据，查看到的只是元数据信息。

### --- 读：
~~~     client客户把请求发送到MFS-Master服务器，MFS-Master接收到这个请求， 
~~~     MFS-Master会在自己的内存中检索这个文件的元数据信息到底在哪里，
~~~     然后把这个请求的元数据信息发送给client端，
~~~     client接收后会连接到对应的MFS-ChunkServer的对应的IP端口对应的ChunkServerID
~~~     上对应的文件上；获取数据；返回给client。

3、删

### --- Client删除文件想MFS-Master服务器发起请求，

~~~     MFS-Master服务器会检索有没有需要删除的这个文件的元数据信息；
~~~     若有的情况下，会删除MFS-Master服务器中这个文件的元数据信息；
~~~     还需要把该文件的元数据信息对应的真实数据加载到这台服务器的里
~~~     # 异步队列(现在不做，设定多少秒后执行正式删除操作)
~~~     #(也就说明在异步队列里未删除之前还能将文件恢复回来)

4、改

### --- client发起修改文件请求到MFS-Master服务器，

~~~     MFS-Master会在MFS-ChunkServer上拷贝该文件的新块。
~~~     MFS-ChunkServer会把改文件拷贝的新块的元数据信息告诉给MFS-Master服务器，
~~~     MFS-Master把这该文件新块的元数据信息路径返回给client，
~~~     client连接MFS-ChunkServer服务器后 打开该新块进行数据修改。
~~~     (介入新块：是为了防止数据干扰，或者同步操作失败，类似于VIM的操作)；
~~~     当该新块文件修改完成后，client会告诉MFS-Master该文件我准备关闭，
~~~     MFS-Master会对比这两个文件之间有没有区别；若有区别，
~~~     它会创建一个新的块，把这个文件的内容再拷贝过来，然后再把旧文件和新文件全部删除。
~~~     更新这个文件的元数据信息，和最新块的对应关系。 
~~~     后期若是有访问的话，访问的是这个最新的块文件。若是没有区别；
~~~     就不会创建最新块，会删除新块，还是用老块的地址并且更新旧块的最终修改时间。

5、增

### --- Client告诉MFS-Master我要touch一个1.txt新文件，

~~~     Client会告诉MFS-Master这个文件的元数据信息：
~~~     名称，文件大小，类型等，MFS-Master会选择一个MFS-ChunkServer创建一个块， 
~~~     MFS-ChunkServer把这个块创建完成之后会告诉MFS-Master创建的这个文件的路径在哪里：
~~~     IP,Port绝对地址，MFS-Master会把这个块的数据信息发送给client，
~~~     client连接到这个空块上去写入数据，写入弯沉过之后，
~~~     client告诉MFS-Master这个文件我已经写完，你可以把它关闭后了；
~~~     MFS-Master会去查找这个文件的最终大小，
~~~     以及保存它的属组属主以及元数据信息并保存在MFS-Master中。

四、MFS补充描述

### --- 存储文件变更

~~~     Master记录着管理信息，比如：文件路径|大小|存储位置|(IP、port、chunkid)
~~~     |份数|时间等，# 元数据信息存在于内存中，
~~~     会定期写入metadata.mfs.back文件中(持久化同步)，定期同步到metalogger中。
~~~     操作实时写入changelog.*.mfs，实时同步到metalogger中。
~~~     master启动将metadata.mfs载入内存，重命名为metadata.mfs.back文件

### --- 存储块分割

~~~     文件以chunk大小存储，每chunk最大为64M，小于64M的，
~~~     该chunk的大小即为该文件大小(验证实际chunk文件略大于实际文件)
~~~     超过64M的文件将切分，以每一份(chunk)的大小不超过64M为原则，
~~~     块的生成遵循规则：目录循环写入(00-FF 256个目录循环，step为2)，
~~~     chunk文件递增生成，大文件切分目录连接。

### --- MFS存储可用性

~~~     Chunkserver上的剩余存储空间要大于1GB(Reference Guide有提到)，
~~~     新的数据才会被允许写入，否则，你会看到NO space left on device的提示，
~~~     实际上，测试发现当磁盘使用率达到95%左右的时候，就已经不行写入了，当时可用空间1.9GB

### --- MFS副本可用性：

~~~     文件可以有多分copy，当goal为1时，文件会被随机存到一台chunkserver上，
~~~     当goal的数大于1 时，copy会由master调度保存到不用的chunkserver上，
~~~     goal的大小不要超过chunkserver的数量，否则多出的copy，不会有chunkserver去存。