Jirong并行集群文件系统技术白皮书2018211

Extreme Fusion并行集群文件系统2018.2.111的技术白皮书. ParaFS的设计目标Extreme Fusion并行集群文件系统（ParaFS）是专门为大中型大型数据平台构建的超文件存储系统. 支持高达1000PB的文件存储. 主要应用场景是语义上的热数据处理. 与Hadoop生态系统完全兼容；考虑到性能和稳定性的原因，Hadoop生态系统中的HDFS可以无缝替换；考虑到“执行IOE”政策，ParaFS还可以在Google大数据平台中无缝替换GFS2. ParaFS的设计目标是组织大量通用，不可靠和廉价的服务器，以提供大量，不加区分和高度可用的数据处理服务. 从外部角度看，ParaFS就像一个庞大，有序且可扩展的存储资源池，并且还具有的抽象计算功能. 因此，从宏的角度来看，ParaFS分为两个部分. 第一部分是将硬件资源组织成可以统一调度的资源. 另一部分是抽象资源并将其组织到标准文件系数系统界面中. 从外部角度看并行文件系统，ParaFS的操作实体是一个存储群集，一个群集是一个完整的存储单元，无论该群集包含多少台物理计算机. 归纳为以下几点: 1.支持商业场景的海量文件存储系统； 2.在整个产品生命周期中的信息安全； 3.支持1000PB级文件存储； 4.支持超大文件，也支持海量超小文件. 5.支持扩展，支持灵活扩展； 6.兼容hadoop生态（支持hadoop fs接口），还支持仿posix接口.

2. 极端并行并行文件系统解决了哪些问题？在开源大数据基础平台Hadoop中，有两个主要子系统: Hadoop分布式文件系统HDFS和Hadoop Map / Reduce. hadoop HDFS通过Namenode File系统索引信息来维护整体；对于任何HDFS文件，Namenode在内存中维护两种元数据: 第一种: 1）HDFS文件与块之间的对应关系，以及2）块在数据节点上的存储位置. Namenode将第一种类型的元数据保存在磁盘上，第二种类型: 元数据由DataNode通过定期的块报告发送到NameNode. 尽管上述架构简洁明了，但仍然存在以下三个问题: 1.性能问题，一系列测试发现，尤其是与硬件的理论性能相比，Hadoop在性能上还有很大的提升空间，其原因主要包括: 在Hadoop的当前设计中，所有元数据操作都必须通过集中式Namenode来执行，这可能是性能瓶颈； M / R应用程序需要通过DataNode访问HDFS，这涉及到频繁的进程切换和网络传输开销；在M / R应用程序方面的开销也有改进的空间.

2. 可扩展性和可靠性. 当前的Hadoop采用单个Namenode和单个Jobtracker设计，这严重限制了整个Hadoop的可伸缩性和可靠性. 首先，Namenode和Jobtracker是整个系统中单点故障（SPOF）的明显来源. 其次，单个Namenode的内存容量是有限的，这将Hadoop集群中的节点数限制为2000个左右，可以支持的文件系统大小限制为10-50PB，并且可以容纳的最大文件数最多可支持1.5亿（注意: 实际数量取决于Namenode的内存大小）. 而集中式的Namenode使得DataNode的块报告也严重影响了Namenode的性能. 例如: 系统有1800个数据节点，每个数据节点具有3T存储，整个集群具有约1.8P的有效存储（假设每个数据块具有3个副本，则为1800 * 3T / 3）. 然后，每个Datanode上大约有50,000个块（假设块大小为64M，然后某些块的大小未达到64M），假设Datanode每小时发送一次块报告，那么Namenode将每两秒钟接收一个块报告，每个块报告包含50000条数据，处理这些数据无疑会消耗大量资源.

实际上，一些用户抱怨重启群集的Namenode需要花费几个小时，这大大降低了系统的可用性. 3.各种企业功能. 随着Hadoop被广泛使用，人们期望Hadoop提供更，例如完全可读和可写的文件系统，快照，镜像等. 当前Hadoop版本不支持这些功能，但是用户有很高的需求. 和通软件认为，Hadoop的这些缺陷来自其架构设计本身. 小修不能解决问题，必须重新设计体系结构. 由同一软件独立开发的ParaFS完全解决了HDFS的问题. ParaFS使用分布式元存储方法. 集群中的每个节点都存储元数据，并且可以并行访问该节点中的数据. ParaFS没有真正的管理节点，只有一个Dealer节点负责协调资源. 经销商节点不是物理节点. 它是一个虚拟节点. 当它挂载的物理节点发生故障时，群集本身可以快速选择一个新的物理节点来做. 这是一个经销商节点. 3. Extreme Fusion并行集群文件系统的特点Extreme Fusion并行集群文件系统的主要设计思想是数据和系统的安全性和稳定性比一切都重要;从技术上讲，它是由软件定义的资源实现的，并且所有资源都已虚拟化，以提高自动化管理能力和容错能力.

ParaFS的主要特征如下: 1.领先的并行计算体系结构使用分布式元数据管理模型，并且元数据分散在群集中. 这种体系结构使整个存储系统没有单点故障. 2.真正的近线性扩展能力，在从三个节点扩展到数万个节点的过程中，无需考虑元数据迁移和扩展的问题. 3.在平台上的本地化I / O中，它将尝试将计算移动到数据所在的节点，而不是移动数据本身，因此大多数数据不需要在网络上读写. 4.高自我修复能力. 当集群中的节点发生故障时，数据将自动迁移到完整的节点. 5.支持完整的随机读写. 6.数据安全性高，平台上存储的所有数据均具有2个以上的副本；同时，它还在较低级别上提供了多个数据安全保证. 7.全方位，多角度的运行时间监控，该平台置于运营支持系统的多维监控之下，可以实时报警并自动修复一些常见故障. 4.用户程序访问过程与并行集群文件系统极其并行，以为用户程序提供一组posix文件系统接口和一组Hadoop兼容访问接口. 对于使用poxis界面的应用程序，用户进程仅需要将原始posix相关的界面功能更改为ParaFS API就足够了. 对于hadoop fs接口，不需要进行任何更改，可以直接使用.

直接读取接口使用C / S模块并行文件系统，该模块由客户端和服务器组成；客户端和服务器可以同时部署在同一台服务器上，也可以分别部署. 直读接口服务器部署在数据节点（数据节点）上）是数据节点服务器程序的主要组件，由parafs的主进程启动；客户端以lib的方式调用应用程序，并被编译成一个so文件. 客户端和服务器之间有两种连接方法: TCP远程连接，unix域接口的本地连接，分别对应于远程调用模式和本地调用模式. 当应用程序与数据节点分离或无法将应用程序绑定到本地数据节点时，将使用远程调用模式. 如下图所示，当应用程序要操作文件时，客户端向最靠近客户端的节点发送寻址请求，返回文件的主副本的节点ID，然后连接到主副本节点以执行文件操作. ParaFS侦听端口（/foo/bar/logic/myfile.no）应用程序ParaFS client12（主副本节点ID）Libparafs服务器文件目录树文件​​操作34结果返回最近节点主副本位于Libparafs服务器ParaFS侦听端口的节点对象服务Brick服务EXT4brick同步（rpc / rdma）Brick服务其他副本节点的远程模式本地调用模式，适用于可以在数据所在节点上直接运行应用程序的场景；如果可能，请尽可能使用本地模块，本地模式比远程模式更有效.

如下图所示，在本地模式下没有寻址过程，并且文件操作请求被直接发送到本机的unix域接口. 主副本节点应用程序ParaFS客户端域接口操作Libparafs服务器对象服务Brick服务EXT4brick同步（rpc / rdma）Brick服务其他副本节点本地模式5. 关键技术原理5.1. 以最简单的方式实现分布式文件目录的原理换句话说，文件系统是用户用来访问数据的系统. 通常，数据以碎片的形式存储在介质上. 没有文件系统，我们将无法合并存储在介质上的数据片段. 我们不知道哪一块是数据的开始，哪一块是数据的结束. 通过将数据分为多个片段，并给每个片段一个标识，可以组织属于同一数据的片段组，并标识名称，称为文件. 操作系统用来管理这些碎片组的信息和名称的逻辑规则和数据结构称为文件系统. 文件系统由三部分组成: 文件系统的外部接口，用于对象操纵和管理的功能集以及对象和属性. 从操作系统的角度来看，文件系统是一种组织和分配用于文件存储介质的空间，负责文件存储以及保护和检索所存储文件的系统. 具体来说，它负责为用户创建文件，存储，读取，修改，转储文件，控制文件访问以及在不再使用用户时撤消文件.

系统中的存储介质如下图所示. 块的起始地址是存储介质的高位地址. 如上图所示，存储介质被抽象为一个有序的存储块（block），每个块都有唯一的地址；目录是一种方便的寻址方法，可以将这些地址形成一棵​​树. 文件实体等效于目录系统中的地址起点. 在独立版本的文件系统中，使用索引节点[inode索引]标识每个文件的起点，并使用索引节点表[inode索引表]存储文件系统的元信息；目录本身作为文件处理；由于索引节点表本身占用存储介质空间，因此存储在独立文件系统中的数据受到限制；这引入了分布式并行文件系统；并行文件系统的目录结构非常大，因此无法以独立方式表示. Jirong并行群集文件系统使用分层方式来存储目录和文件描述数据. 为了方便表达，我们使用meta来表示[注: 实际上，严格来讲，它不是真正的meta]. 如下图所示，当群集节点的目录长度小于级别7时，所有目录都在群集范围内有效；当它高于级别7时，前7个级别在集群范围内有效，后部由节点内部处理. 全局meta保存全局目录信息，但不保存单个目录信息，并且许多目录的前7个级别相同，这意味着必须处理同一目录；全局元由以下组成: 相同目录的节点被分布，并且熵值确定目录的后半部分. 段的哈希值由目录规则库的三个规则组成；总占用空间仅超过10万；仅当物理节点更改时，规则才会更改.

那么为什么不只使用哈希结果呢？这是因为在数万亿的文件中，不同的路径不可避免地会产生相同的哈希值. 创建文件时，将生成一个熵值，并且文件的特定存储节点由熵值确定. 由于特定的熵值也存储在节点中，因此文件本身的创建不会引起全局元数据的更改. 5.2. 随机写入实现的原理在高计算量应用系统中，对实时性的要求很高，并且数据的读取和写入是同步进行的. 因此，ParaFS实现的方案是“一次写入，多次读取”，对于同一数据允许多个. 客户端正在执行读操作，这允许客户端进行写操作，并且读和写操作最终可以实现“结果一致性”. 实现过程如下: 1.每个积木都有一个版本号，并且版本号递增. 如果砖块没有变化，则版本号保持不变，如图1的左侧所示，当读写请求同时到达时，如果它们不返回Restrictions，则将出现这种情况. 在图1的右侧，刚刚写入的读取数据即“脏”数据，则读取的数据毫无意义. client2дBrickv101Brick v101读取client1ͼ12.解决方案是将读取和写入分开在不同的位置. 接收到写请求时，复制砖的副本[注: 类似于快照，但不快照]，如果是v101“，如图2所示，砖v101”砖v101ͼ23. 完成后，写入操作处于副本版本（v101“）中，仍然在原始块上进行读取，因此此时读取的数据是完整且干净的数据，如图3所示， client2дBrickv101“ Brick v101阅读client1ͼ34. 写入操作完成后，等待读取操作完成，所有外部操作都将暂停一毫秒，请完成以下任务，然后接受新的操作请求: 重印版本（v101“）升级到该版本的最新版本实体v102，删除原始v101 brcik实体，然后元更改最新版本号v102.

如图4所示，Brick v101“ Brick v102Brick v101Brick v101图4 5.3. 复制同步极端融合并行集群文件系统的基本存储单元是Brick，每个Brick具有2至4个副本，由编译器设置；保持副本之间的一致性是文件系统的最重要任务，极限融合并行集群文件系统使用版本来确保副本的一致性，并以高度一致性来同步副本，这些版本以整数表示，例如两个个副本如果版本与99相同，则表示它们相同；如果不同，则一个为99，另一个为100，则表示它们不一致，需要先进行同步，然后才能使用. 5.4. 群集角色系统群集只需要少量的手动管理，不需要手动管理，没有实际的管理节点，也没有中央节点工人；所有节点都是工人，而经销商是回应适用于全局集群数据的分发者会更改，并负责全局元的更新. 持有人是经销商的数据备份. 交易者和持有者都具有全局元的永久存储；经销商死后，将选择其中一位持有人作为经销商，换句话说，经销商是活跃的持有人.

Worker还会在内存中缓存全局元数据，但不会巩固这些元数据. 特定于文件的元数据存储在工作程序节点中，并且每个节点都维护自己的元数据. 6.总体组成从逻辑功能的角度来看，集群组成是分层的，如下图所示. 总体组成由客户端Lib和服务器组成；服务器由以下部分组成: 文件系统分析层，对象存储服务层，集群管理和调度模块，砖块层，资源层. 客户端Lib服务器端文件系统解析层对象存储服务层砖层资源层集群管理和调度模块文件系统解析层提供客户端lib交互功能，并与其他功能模块互为领导. 集群管理调度模块提供集群管理接口，同时负责节点的角色定位；对象存储服务层将砖块层提供的服务转换为数据存储接口. 砖层与资源层直接交互，为上层提供固定长度的存储区域，并通过本地文件系统读写硬盘. 这里的资源层是指群集中的所有硬盘驱动器.

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/jisuanjixue/article-201661-1.html