云存储的分布式文件系统

第1章绪论
1.1 背景
网络时代是一个信息技术飞速发展的时代，随着互联网服务的日趋完善，特别是多媒体、移动互联网技术的迅猛发展，智能手机、平板电脑的快速普及，以
及企业、政府、医疗机构、学术团体等对数据的巨大需求，使得全球存储数据量
每年以指数增长[1]。根据国际数据公司IDC（International Data Corporation）的统计，截止2011年全球数字信息总量已经达到1.8ZB（1ZB=GB），预计到2020年，全球数字信息总量将达到35ZB。
海量数据带给了人们海量的信息，这些信息已经融入到了人们生活的方方面面，然而海量数据在带给人们信息化便利的同时也带给了诸如Google、Facebook、Amazon等大型互联网企业一个巨大的挑战：面对错综复杂、跨地域、跨时间的海
量数据，如何对它们进行安全的存储和高效的处理？这些挑战大体可以归纳为以下几个方面[2]： 
·海量数据的存储要求数据存储公司必须开发出PB甚至ZB级的文件存储系统，因为传统的文件系统根本无法保证多用户大规模数据的实时迁徙；
·海量数据催生出了海量的用户请求，因此，数据存储公司必须提供一种能并行处理不同用户提交的各项任务以尽可能大的减少服务时间的文件存储服务；
与以往的计算相比，云计算有着自己独一无二的显著特点[5]：
·集群的超大规模
构建云计算集群的服务器数目众多而且分布区域广泛，以Google为例，其服
务器有几十万台，并且分布在全球的几十个国家和地区。
·采用虚拟化技术
云计算服务支持用户在任意位置、使用各种终端获取所需要的服务，用户不
需要知道所需的资源的具体物理位置，只需通过网络就可以获得相应的服务。
·可靠性高
存储在云中的数据采用多副本容错、跨地区容灾、计算节点同构可互换等措
施提高了数据的可靠性，有效防止了因为软硬件故障而造成的用户数据损坏。
·可扩展性高
云中的集群可以动态扩展，可以向集群中动态添加或撤除节点而不影响整个
服务。
1.2意义和现状
1.2.1 课题意义
云存储是云计算系统架构的基础和应用的支撑。由于云存储往往拥有超大的系统规模和海量的用户访问需求，因此应具有较高的系统性能，虽然现有的云服务提供商承诺接近于百分之百的可靠性保证，但包括Google、EMC、Amazon等在内的许多提供云存储业务的公司近两年均出现服务中断的情况，这给用户带来了巨大的损失。所以研究具有高可用性和高可靠性的云存储系统的关键技术很有必要[9]。
1.2.2 现状
目前，国际上知名的网络公司都有自己的云存储产品，例如Google的 GFS[10]（Google File System）、Amazon的弹性计算云EC2[11]（Elastic Compute Cloud）和简单存储 S3[12]（Simple Storage Service)、EMC的Atmos[13]、Apache 基金会开发的 Hadoop[14]等等。其中，Hadoop作为一个分布式系统的基础架构，已经成为云存储领域研究的主流架构之一。用户通过 Hadoop 可以在不了解分布式底层细节的情况下，开发分布式程序，充分利用集群的计算能力高速运算和存储数据。Hadoop实现了一个分布式文件系统，简称HDFS[15]。HDFS就像一个传统的分级文件系统，用户可以任意创建、删除、移动或重命名文件等。作为分布式文件系统的一个典型代表，HDFS具有廉价性、高容错性以及高可扩展性的特点，在当今云存储领域占据了举足轻重的地位，是使用最广泛的一种分布式文件系统。前的硬件水平来说整个系统就无法正常工作了。
1.3 课题内容
本文基于集中主从式体系架构的分布式文件储存系统，探讨了基于HDFS系统部分对等式多Namenode架构，并为所提出的构架设计了多Namenode选择算法、主-备Namenode 元数据的交互流程。
第2章基于HDFS的部分对等式多Namenode架构
2.1 架构概述
2.1.1 架构出发点
作为集中式系统架构的典型代表，相对于其它分布式文件系统，HDFS系统的特点如下：
·单一的命名空间
在HDFS系统中，用户的所有操作都经过单一的命名空间，并且以文件的形
式访问本地文件和远程文件，使得用户对于文件的存储位置具有透明性。
·支持大文件的存储与数据批处理
存储在HDFS系统中的大文件都会被分割成多个固定大小的小文件块，每个
文件块存储在多个存储节点上。基于Hadoop的Map Reduce编程模型[16]，HDFS
的分块存储及流式访问得到并行处理，因此，这种设计理念更适合海量数据的存
储，效率也更高。
·数据一致性
HDFS支持用户文件的“一次写多次读”操作，客户端在成功写入文件之后，才能看到文件。Namenode会根据配置文件利用心跳检测和重新复制等机制复制文
件块来保证数据的一致性及安全性。
2.1.2 架构目标
本文中的云存储架构的要实现的目标有：
(1)改变HDFS架构中的伸缩性差以及单点依赖等缺陷。利用首尾相连并成部分对等关系的多个Namenode改变了集中式架构中的单点依赖，例如克服了HDFS中当Namenode失效时，整个系统将陷入瘫痪状态的情况。
(2)通过一个多Namenode选择算法，从多个Namenode中为接入用户选择特定的Namenode，并且选择出来的Namenode能为用户提供 HDFS系统中的任何应用，如用户透明性、元数据管理、海量数据的存储与检索等，不会对己存在的应用造成任何负面影响，从而提高了整个云存储架构可扩展性。
通过实现以上目标，使得HDFS尽可能在一个更大规模的环境中应用，尽可能的使HDFS系统成为一个真正的云存储系统。
2.2 总体架构
2.2.1 总体架构图
架构图如2.1所示

                      图2.1 部分对等式多NameNode架构

本架构共分为三层：用户应用层、元数据服务器层和存储服务器层。
下面将逐一进行介绍。
(1)用户应用层
用户应用层是系统客户端的抽象，同时也是用户与服务器系统的纽带与桥梁，主要功能是向Namenode发送RPC（Remote Procedure Call Protocol）请求并与之建立通信连接，通过请求信息表与Namenode交互各种控制信息。
(2)元数据服务器层
在元数据服务器层，根据需求的不同，每个Namenode会在主-备之间进行角色转变，每一个Namenode既是它前驱节点的备用Namenode，同时也是它后继节点的主Namenode，前后节点之间是一种主-备关系，是典型的对等关系。在元数据服务器层中，由部分对等的多个Namenode组成，并且这些Namenode首尾相连构成一个环状。每个Namenode存储了特定用户文件的所有元数据信息及操作日志文件并且管理部分存储服务器，同时接收自己管辖区域内的存储服务器发送的定时心跳包和块报告信息。每个Namenode都有一个特定的ID，并且每个Namenode 都存储了一份Namenode ID与IP地址之间的映射表，可以随时进行 Namenode ID与IP地址之间的转换。一般情况下，每个Namenode 在存储用户元数据的同时，也将元数据的副本发送给自己的后继Namenode。当某个Namenode发生故障时，该节点的全部功能均由其后继Namenode承担，直到自己恢复正常。
(3)存储服务器层
存储服务器层由多个存储服务器机架组成，每个机架有多台存储服务器，也
就是本文的Datanode，并且不同机架通过一台交换机相连。采用分区域自治的管理方式，每个Namenode负责管理存储服务器层中特定机架的Datanode，若NNn表示系统中Namenode总数，NDn表示系统中Datanode机架总数，一定有NNn<NDn。存储服务器层中的Datanode会定期的向管辖自己的Namenode发送心跳包和数据块信息，通过接收Datanode的心跳包，Namenode能判断出Datanode的实时状态信息，为用户文件块在存储服务器层中存储位置做出选择。当某个Namenode发生故障时，其管辖的机架内的Datanode会和该Namenode的备用Namenode联系，负责心跳包和数据块信息的接收。
2.2.2 架构交互机制
本文所述的架构共有三层，并且每一层只有一种节点类型，即用户应用层中的用户Client，元数据服务器层中的元数据服务器Namenode和存储服务器层中的存储服务器Datanode，它们之间的交互过程可以概括为：Client与Namenode、Client与Datanode、Datanode与Namenode、主-备Namenode之间以及不同Datanode之间这几种。
2.3 架构细节设计
2.3.1 元数据的存储结构
元数据被定义为数据的数据，它是描述数据属性的一个参量。在分布式文件系统中，元数据主要作为块数据的索引来使用。在HDFS系统中，文件的元数据信息主要包括文件命名空间、文件到数据块的映射、数据块到数据存储节点的映射三部分。HDFS系统元数据的存储类型一共分为两种：Fsimage文件和Editlog文件。
（1）Fsimage文件
Fsimage是一个二进制文件，其中存储了命名空间中所有文件以及目录的元数据信息，其保存的文件和目录信息的格式如图 2.3 所示：

                   图2.3 Fsimage文件格式

从Fsimage的文件格式可以看出，Fsimage保存有如下信息：
首先，是一个文件头，其中包括：
·img Version(int)：当前image的版本信息；
·namespace ID(int)：用来确保别的HDFS系统中的Datanode不会误连上当
前Namenode；
·num Files(long)：整个文件系统中包含有文件和目录的个数；
·gen Stamp(long)：生成该image时的时间戳信息；
其次，是对每个文件或目录的元数据信息，如果是目录，则包含以下信息：
·path(String)：该目录的路径，如“/user/build/build-index”；
·replications(short)：副本数（目录虽然没有副本，但这里记录的目录副本
数也为3）；
·mtime(long)：该目录的修改时间的时间戳信息；
·atime(long)：该目录的访问时间的时间戳信息；
·blocksize(long)：目录的blocksize都为0；
·num Blocks(int)：实际有多少个文件块，目录的该值都为-1，表示该item为目录；
·ns Quota(long)：namespace Quota值，若没加Quota 限制则为-1；
·ds Quota(long)：disk Quota值，若没加限制则也为-1；
·username(String)：该目录的所属用户名；
·group(String)：该目录的所属组；
·permission(short)：该目录的permission信息，有一个short来记录。
若是一个文件，则还会额外包含如下信息：
·block ID(long)：属于该文件的block的 block ID；
·num Bytes(long)：该block的大小；
·gen Stamp(long)：该block的时间戳。
当该文件对应的num Blocks数不为1，且大于1时，表示该文件对应多个block信息，此时在该Fsimage之后的就会有多个block ID 、num Bytes和gen Stamp信息。因此，在Namenode启动时，就需要对Fsimage按照如下格式进行顺序的加载，以将Fsimage中记录的HDFS元数据信息加载到内存中，但为了元数据的安全性，Namenode还会将元数据持久化到硬盘中。
（2）Editlog文件
在HDFS中Editlog文件是用来记录Namenode的命名空间的修改操作进行日志记录的。文件系统的命名空间被全部缓存在Namenode的内存中，一旦Namenode重启或出现故障，必须有一种方法能够将整个命名空间进行重建，目前Namenode是通过将命名空间信息记录Fsimage中，Namenode重启的时候，就是通过读取Fsimage文件来重构命名空间目录树结构。但是，Fsimage始终是硬盘上的一个文件，不可能时时刻刻都跟Namenode内存中的数据结构保持同步，而是每过一段时间更新一次Fsimage文件，以此来保持Fsimage跟Namenode内存命名空间的尽量同步。而在一个新Fsimage和上一个Fsimage中间的Namenode操作，就会被记录在Editlog中，所以，Namenode会对应一个Fsimage文件和一个Editlog文件，Editlog一般存储在Namenode节点的硬盘中。
2.3.2 NameNode的启动
(1)Fsimage加载过程
HDFS中，文件的命名空间、文件到数据块的映射关系等元数据信息都存储在Fsimage文件中，所以元数据的加载过程即是Fsimage的加载过程，在NameNode启动时完成对Fsimage的加载。Fsimage加载过程完成的操作主要是为了：
·从Fsimage中读取该HDFS中保存的每一个目录和文件;
·对每个目录和文件的元数据信息进行初始化操作;
·根据目录和文件的路径，在内存中构造出整个命名空间;
·读取出文件包含的所有block，并记录在BlocksMap中。
Fsimage的整个加载流程如下图3.7所示:
如图2.3, Namenode加载Fsimage的过程非常简单，就是从Fsimage文件中依次顺序的读取用户的每个文件和目录的元数据信息来构建整个命名空间，同时，将每个文件所对应的block信息存入BlocksMap块映射表中。Fsimage文件头都有一个统一的标识。Fsimage文件加载完毕意味着在整个HDFS系统，除了每个文件所对应的block块的Datanode列表信息以外所有的目录在内存中已经初始化结束。这些初始化信息需要Namenode从Datanode的blockReport包中获取，所以加载Fsimage文件结束后，Namenode开始进入了RPC等待状态，所谓RPC等待状态是指Namenode开始等待自己管辖机架内的Datanode发送blockReport包。

图2.3Fsimage的加载过程
(2)blockReport的接收
每个Datanode在开始启动时都会周期性的扫描其机器上对应保存HDFS块的目录下存储的所有文件块信息，然后通过Namenode的RPC调用请求将这些块信息通过一个矩阵数组的方式发送给管辖自己的主Namenode，主Namenode在接收到一个管辖区域内的Datanode发送过来的blockReport RPC调用请求后，从RPC中解析出该块数组，并将这些收到的数据块插入到BlocksMap块映射表中，由于此时BlocksMap缺少的仅仅是每个块对应的Datanode信息，而主Namenode能从blockReport块报告中获知当前汇报上来的Datanode的位置、IP地址和块信息，所以，B1ockReport块报告过程就是主Namenode在接收到Datanode的块信息汇报后，填充BlocksMap映射表中每个块对应Datanode列表的三元组信息的过程。具体流程细节如下图2.8所示:

                   图2.8 BlockMap填充流程

当所有Datanode的块信息汇报完成，并且Namenode对每个Datanode的汇报处理结束，这意味着BlocksMap映射表建立完毕。此时，Namenode的启动过程结束，Namenode主动退出安全模式，开始提供服务。

第3章总结
首先，本文在对云存储的发展现状以及主要技术做了详细的介绍，介绍了分布式文件系统的相关背景以及相关知识。
其次，基于HDFS系统同时结合对等式结构的优点，本文介绍了一种部分对等式的多Namenode系统架构，从架构的出发点入手，对架构的总体结构图，层次间的节点构成、不同层次间的交互方式以及文件的写入过程和读取操作做了概括描述；随后，本文从架构的细节出发，讲解基于本架构的多Namenode选择算法、主一备Namenode元数据的交互流程。

参考文献
[1]张大洋.基于云存储的分布式文件系统研究与优化[D].西安电子科技大学硕士学位论文，2013.
[2]李琛.开放分布式文件存储服务的设计与实现[D].北京邮电大学硕士学位论文，2016.
[3]韩晓明.磁盘阵列技术的新进展[N].中国计算机报，2012-01-09.
[4]邓见光，潘晓衡，袁华强.云存储及其分布式文件系统研究[J/OL].东莞理工学院学报，2012.
[5]马帅，李建新，胡春明.大数据科学与工程的挑战与思考[EB/OL].中国计算机学会通讯，2011.
[6]周江，王伟平，孟丹，马灿，古晓艳，蒋杰.面向大数据分析的分布式文件系统关键技术[J].计算机研究与发展,2015：382-394.
[7]彭海琴.云存储模型及架构解析[J].数字技术与应用.2015(4):76-77
[8]百度文库.NAS存储——数据备份方案[EB/OL].[2018-06-30].
https://wenku.baidu.com/view/568b38d4360cba1aa811daf9.html?sxts=1546010007534
[9]刘洋.云存储技术——分析与实现[M].经济管理出版社，2016.
[10]Ghemawat S,Gobioff H,Leung S T.The Google file system[C]//ACM SIGOPS Operating Systems Review.ACM,2003,37(5):29-43.
[11]Amazon.Amazon EC2[EB/OL].https://aws.amazon.com/cn/ec2/?nc2=h_m1
[12]郭巍.基于Amazon S3接口的云存储系统的设计与实现[D].上海交通大学硕士学位论文，2016.
[13]DELLEMC.EMC ATMOS云存储解决方案[EB/OL].
https://china.emc.com/storage/atmos/atmos.htm
[14]百度百科.Hadoop[EB/OL].[2014-04-30].
http://baidu.com/vicw/908354.html?Fr aladdin#rcfIndex_7_908354.
[15]Hayes B.Cloud Computing[J].Commuincations of the ACM,2008,51(7):9-11.
[16]apache hadoop.MapReduce Tutorial[EB/OL].[2016-08-18].
http://hadoop.apache.org/docs/r2.7.3/hadoop-mapreduce-client/hadoop-mapreduce-client-core/MapReduceTutorial.html
[17]朱颂．分布式文件系统HDFS的分析[J].福建电脑,2012(4)：63-65.

云存储的分布式文件系统相关推荐

云存储及其分布式文件系统
转自: https://www.cnblogs.com/langren1992/p/5432517.html 随着信息化程度的不断提高,全球数据日益膨胀.面对当前PB级的海量数据存储需求,传统的存储系 ...
[转]Unix下针对邮件,搜索,网络硬盘等海量存储的分布式文件系统项目（关于GFS、MogileFS分布式文件系统邮件列表）
Unix下针对邮件,搜索,网络硬盘等海量存储的分布式文件系统项目 :Google是当前最有影响的Web搜索引擎,它利用一万多台廉价PC机构造了一个高性能.超大存储容量.稳定.实用的巨型Linux集群. ...
搭建自己的云存储空间|FastDFS分布式文件系统考虑一下？
一. 前言最近有很多小伙伴问壹哥,大规模的文件存储该怎么做? 这个感觉很难实现呢.其实这个需求,并没有大家想的那么难以实现.今天壹哥就带着各位,用10分钟的时间来搞定这个需求.不信?那你就跟着壹哥一 ...
Unix下针对邮件,搜索,网络硬盘等海量存储的分布式文件系统项目
:Google是当前最有影响的Web搜索引擎,它利用一万多台廉价PC机构造了一个高性能.超大存储容量.稳定.实用的巨型Linux集群. http://bbs.chinaunix.net/forum/v ...
基于滴滴云搭建 Lustre 分布式文件系统
1. Lustre简介 Lustre 是一个具有高可用.高性能.可扩展的分布式文件系统.主要由 Manage Server.Meta Data Server 和 Data Server 组成.详细介绍 ...
云存储及分布式创新应用笔记一
1.安装Eclipse 登录官网The Community for Open Innovation and Collaboration | The Eclipse Foundation 点击downl ...
【云存储】主流分布式文件系统介绍
目录 1.引言 2.云存储与分布式文件系统 2.1.云存储 2.2.分布式文件系统 3.Google的三大云计算与云存储论文 3.1.The Google File System(谷歌文件系统) 3. ...
盘点Linux下的开源云平台云存储服务
15个您可能不知道的开源云平台桉树云服务环境 Eucalyptus 开源协议及语言 GPL Java C/C++ 官方网站 http://www.eucalyptus.com/participate ...
云存储相关技术及术语的探讨
摘要在经历计算浪潮和网络浪潮之后,数据存储技术已经发展成为信息领域的三大支撑技术之一.随着云计算.等信息技术的发展,异构数据源越来越多,数据量飞速增长,这就使得社会对数据存储的需求逐日攀升.同时, ...

云存储的分布式文件系统

云存储的分布式文件系统相关推荐

最新文章

热门文章