FastDFS等7种分布式文件系统简介.pdf

FastDFS.7Fastdfs 简介.7Fastdfs系统结构图.7FastDFS 和 mogileFS 的对比.8MogileFS.10Mogilefs 简介.10Mogilefs组成部分.100）数据库（MySQL）部分.101）存储节点.112）trackers（星艮踪器）.113）工具.114）Client.11Mogilefs 的特点.121.应用层没有特殊的组件要求.122.无单点失败.123.自动的文件复制.124.“比 RAID 好多了”.125.传输中立，无特殊协议.136.简单的命名空间.137.不用共享任何东西.138.不需要RAID.139.不会碰到文件系统本身的不可知情况.13HDFS.14HDFS 简介.14特点和目标.141.硬件故障.142.流式的数据访问.143.简单一致性模型.154.通信协议.15基本概念.151.数据块(block).152.元数据节点(Namenode)和数据节点(datanode).162.1 这些结点的用途.162.2 元数据节点文件夹结构.172.3 文件系统命名空间映像文件及修改日志.182.4 从元数据节点的目录结构.212.5数据节点的目录结构.21文件读写.221.读取文件.221.1 读取文件示意图.221.2 文件读取的过程.232.写入文件.242.1写入文件示意图.242.2写入文件的过程.24HDFS不能提供的特点.251.低延时访问.252.大量小文件.263.多用户写，任意文件修改.27TFS.27TFS简介.27TFS系统的基本情况.28应用规模.28性能参数.28TFS的逻辑架构图.29结合架构图做了进一步说明.29TFS的不足之处.301、通用性方面。.302、性能方面。.303、用户接口。.304、代码方面。.305、技术文档。.316、小文件优化。.31MooseFS（简称 MFS）.31MFS简介.31MFS的优点.31网络示意图（如下）.32MFS文件系统结构.33包含的4种角色.33管理月艮务器 managing server(master)33元数据日志服务器 Metalogger serve(Metalogger)33数据存储服务器 data servers(chunkservers)34客 户 端 client computers344种角色的协作过程.35MFS读写进程.35MFS读进程.35MFS写进程.36KFS.38KFS简介.38KFS的特性.381.自动存储扩充.382.有效性.383.文件复制粒度.384.还原复制.385.负载平衡.396.数据完整性.397.文件写入.398.契约.399.支持 FUSE.3910.支持C+,Java,Python方式的调用.4011.提供了丰富的工具程序.4012.提供了启动和停止服务的脚本.40KFS高级特性.40KFS与HDFS的比较.401.体系结构图的比较.402.特点的比较.41Ceph.42Ceph的目标.42Ceph生态系统.42可以大致划分为四部分.42Ceph生态系统的概念架构.43架构视图1.43架构视图2.44Ceph 组件.44Ceph客户端.45Ceph元数据服务器.47Ceph对象存储.49其他有趣功能.49Ceph的地位和未来.50其他分布式文件系统.50展望未来.50FastDFSFastdfs 简介一国人在mogileFS基础上进行改进的key-value型文件系统，不支 持FUSE,提供比mogileFS更好的性能-轻量级（移植性比较强，资源依赖性小？）的开源分布式文件系 统-解决的问题：1.大容量的文件存储2.高并发的访问3.文件存取 时的负载均衡一特色：实现了软件方式的RAID;支持服务器在线扩充；支持相同 的文件只存一份，节省了磁盘空间一限制：只能通过client api方式访问，不支持posix方式访问-适合范围：大中型网站用来存储资源文件（如图片、文档、音频、视频、音频等），即以文件为载体的在线服务FastDFS服务端有两个角色：跟踪器（）和存储节点O,跟踪 器总要做调度工作，在访问上做负载均衡的作用，且跟踪器可用 多台服务器进行均衡，这样可避免单点故障的发生。通信协议：有专门协议，下载文件支持HTTPFastdfs系统结构图Client 2Volume 1Storage server KZ i _ Linux-QStorage server K2Client4!1 nicker N IVolume KStorage server KIi Client 1IClient M|Storage server 11Storage server 12Storage server IXVolume 2Storage server 21Storage server 2Yw Storage server 22FastDFS 和 mogileFS 的对比1.FastDFS完善程度较高，不需要二次开发即可直接使用；2.和MogileFs相比，FastDFS裁减了跟踪用的数据库,只有两个角 色：tracker和storage。FastDFS的架构既简 化了系统，同时 也消除了性能瓶颈；3.在系统中增加任何角色的服务器都很容易：增加tracker服务器 时，只需要修改storage和client的配置文件（增加一行tra cker配置）；增加storage服务器时，通常不需要修改任何配 置文件，系统会自动将该卷中已有文件复制到该服务器；4.FastDFS比MogileFS更高效。表现在如下几个方面：1）参见上面的第2点，FastDFS和MogileFS相比，没有文件索 引数据库，FastDFS整体性能更高；2）从采用的开发语言上看，FastDFS比MogileFS更底层、更 高效。FastDFS用C语言编写，代码量不到2万行，没有依赖其他 开源软件或程序包，安装和部署特别简洁；而MogileFS用perl 编写；3）FastDFS直接使用socket通信方式，相对于MogileFS的HTTP方式，效率更高。并且FastDFS使用sendfile传输文件，采用了内存零拷贝，系统开销更小，文件传输效率更高。5.FastDFS有着详细的设计和使用文档，而MogileFS的文档相对 比较缺乏。6.FastDFS的日志记录非常详细，系统运行时发生的任何错误信息 都会记录到日志文件中，当出现问题时方便管理员定位错误所在。7.FastDFS还对文件附加属性（即meta data,如文件大小、图片宽度、高度等)进行存取，应用不需要使用数据库来存储这些信息。8.FastDFS从V1.14开始支持相同文件内容只保存一份，这样可 以节省存储空间，提高文件访问性能。MogileFSMogilefs 简介一一种分布式文件存储系统，可支持文件自动备份的功能，提供可 用性和高可扩展性，用Perl语言编写，由于有依赖模块的问题，安 装过程需要其他库和模块的支持，安装不算容易。key-value型元文件系统，不支持FUSE,应用程序访问它需要 API,主要在web领域处理海量小图片，效率高，适用性：不支持对一个文件的随机读写，只适合做一部分应用。比如图片服务，静态html服务，即文件写入后基本上那个不需要修 改的应用。Mogilefs组成部分0)数据库(MySQL)部分mogdbsetup程序可用来初始化数据库。数据库保存了Mogilefs的所有元数据，你可以单独拿数据库服务器来做，也 可以跟其他程序跑在一起，数据库部分非常重要，类似邮件系统的认证中心那么重要，如果这儿挂了，那么整个Mogilefs 将处于不可用状态。因此最好是HA结构。1)存储节点mogstored程序的启动将使本机成为一个存储节点。启动 时默认去读/etc/mogilefs/mogstorecLconf,具体配置可以参 考配置部分。mogstored启动后，便可以通过mogadm增 加这台机器到cluster中。一台机器可以只运行一个mogstored作为存储节点即可，也可以同时运行其他程序。2)trackers(跟踪器)mogilefsd 即 trackers 程序，类似 mogilefs 的 wiki 上介绍的，trackers 做了很多工作，Replication,Deletion,Query,Reaper,Monitor等等。mogadm,mogtool的所有操作都要跟 trackers打交道，Client的一些操作也需要定义好trackers,因此最好同时运行多个trackers来做负载均衡。trackers也可 以只运行在一台机器上，也可以跟其他程序运行在一起，只要 你配置好他的配置文件即可，默认在/etc/mogilefs/mogilefsd.confo3)工具主要就是mogadm,mogtool这两个工具了，用来在命令行下控 制整个mogilefs系统以及查看状态等等。4)ClientClient实际上是一个Perl的pm,可以写程序调用该pm来使用mogilefs系统，对整个系统进行读写操作。Mogilefs的特点1.应用层没有特殊的组件要求2.无单点失败MogileFS启动的三个组件（存储节点、跟踪器、跟踪用的数据库），均可运行在多个 机器上，因此没有单点失败。（你也可以将跟踪器和存储节点运行在同一台机器上，这样你就 没有必要用4台机器）推荐至少两台机器。3.自动的文件复制基于不同的文件“分类”，文件可以被自动的复制到多个有足够存储 空间的存储节点上，这样可以满足这个“类别”的最少复制要求。比 如你有一个图片网站，你可以设置原始的JPEG图片需要复制至少三 份，但实际只有1 or 2分拷贝，如果丢失了数据，那么Mogile可 以重新建立遗失的拷贝数。用这种办法，MogileFS（不做RAID）可 以节约磁盘，否则你将存储同样的拷贝多份，完全没有必要。4.“比RAID好多了”在一个非存储区域网络的RAID（non-SAN RAID）的建立中，磁 盘是冗余的，但主机不是，如果你整个机器坏了，那么文件也将不能 访问。MogileFS在不同的机器之间进行文件复制，因此文件始终 是可用的。5.传输中立，无特殊协议MogileFS客户端可以通过NFS或HTTP来和MogileFS的存储节 点来通信，但首先需要告知跟踪器一下。6.简单的命名空间文件通过一个给定的key来确定，是一个全局的命名空间。你可以 自己生成多个命名空间，只要你愿意，但是这样可能在同一 MogileFS 中，会造成冲突key。7.不用共享任何东西MogileFS不需要依靠昂贵的SAN来共享磁盘，每个机器只用维护 好自己的磁盘。8.不需要RAID在MogileFS中的磁盘可以是做了 RAI D的也可以是没有，如果是为 了安全性着想的话RAI D没有必要买了，因为MogileFS已经提供了。9.不会碰到文件系统本身的不可知情况在MogileFS中的存储节点的磁盘可以被格式化成多种格（ext3,reiserFS等等）。MogilesFS会做自己内部目录的哈希，所以它不会碰到文件系统本身的一些限制，比如一个目录中的最大文件数。你可以放心的使用。HDFSHDFS简介HDFS 全称是 Hadoop Distributed FileSystem0目前 HDFS支持的使 用接口除了 Java 的还有，Thrift C、FUSE、WebDAV,HTTP等。构成 HDFS主要是 Namenode(master)和一系歹U的 Datanode(workers)。特点和目标1.硬件故障硬件故障是计算机常见的问题。整个HDFS系统由数百或数千个存 储着文件数据片断的服务器组成。实际上它里面有非常巨大的组 成部分，每一个组成部分都会频繁地出现故障，这就意味着HDFS 里的一些组成部分总是失效的，因此，故障的检测和自动快速恢 复是HDFS一个核心的目标。2.流式的数据访问HDFS使应用程序流式地访问它们的数据集。HDFS是设计成适合批 量处理的，而不是用户交互式的。所以其重视数据吞吐量，而不 是数据访问的反应速度。亦即HDFS是为以流的方式存取大文件而 设计的。适用于几百MB,GB以及TB,并写一次读多次的场合。而 对于低延时数据访问、大量小文件、同时写和任意的文件修改,则并 不是十分适合。3.简单一致性模型大部分的HDFS程序对文件操作需要的是一次写入，多次读取 的。一个文件一旦创建、写入、关闭之后就不需要修改了。这个 假定简化了数据一致的问题和高吞吐量的数据访问。4.通信协议所有的通信协议都是在TCP/IP协议之上的。一个客户端和明 确的配置端口的名字节点建立连接之后，它和名字节点的 协议是ClientProtocal o数据节点和名字节点之间用 DatanodeProtocal。基本概念1.数据块(block)HDFS(Hadoop Distributed File System)默认的最基本的存 储单位是64M的数据块。和普通文件系统相同的是,HDFS中的文件是被分成64M一块的数据块存储的。A不同于普通文件系统的是，HDFS中，如果一个文件小于一个数 据块的大小，并不占用整个数据块存储空间。之所以将默认的block大小设置为64MB这么大，是因为block-sized对于文件定位很有帮助，同时大文件更使传输的时间远大于文件寻找的时间，这样可以最大化地减少文件定位的时间在整个文件获取总时间中 的比例。2.元数据节点(附1716的16)和数据节点(2的(6)2.1 这些结点的用途2.1.1 元数据节点用来管理文件系统的命名空间1)其将所有的文件和文件夹的元数据保存在一个文件系 统树中。2)这些信息也会在硬盘上保存成以下文件：命名空间镜像(namespace image)及修改日志(edit log)3)其还保存了一个文件包括哪些数据块，分布在哪些数据节点上。然而这些信息并不存储在硬盘上，而是在 系统启动的时候从数据节点收集而成的。2.1.2 数据节点是文件系统中真正存储数据的地方。1)客户端(client)或者元数据信息(namenode)可以 向数据节点请求写入或者读出数据块。2)其周期性的向元数据节点回报其存储的数据块信息。2.1.3 从元数据节点(secondary namenode)1)从元数据节点并不是元数据节点出现问题时候的备 用节点，它和元数据节点负责不同的事情。2)其主要功能就是周期性将元数据节点的命名空间 镜像文件和修改日志合并，以防日志文件过大。这 点在下面会相信叙述。3)合并过后的命名空间镜像文件也在从元数据节点 保存了一份，以防元数据节点失败的时候，可以恢 复。2.2 元数据节点文件夹结构dfs.name.dirJ/current/VERSION/edits/fs image/-fstime VERSION 文件是 java properties 文件，保存了 HDFS的版本号。o layoutversion 是一个负整数,保存了 HDFS的持续化在硬盘 上的数据结构的格式版本号。o namespacel D是文件系统的 唯一标识符,是在文件系统初次 格式化时生成的。o cTime此处为0o storageType表示此文件夹中 保存的是元数据节点的数据结 构。namespacel D=1 232737062cTime=0storageType=NAME_NODElayoutVersion=-182.3文件系统命名空间映像文件及修改日志当文件系统客户端(client)进行写操 作时，首先把它记录在修改日志中(edit log)元数据节点在内存中保存了文件系统 的元数据信息。在记录了修改日志后，元数据节点则修改内存中的数据结 构。每次的写操作成功之前，修改日志都会同步(sync)到文件系统。fsimage文件，也即命名空间映像文 件，是内存中的元数据在硬盘上的 checkpoint,它是一种序列化的格 式，并不能够在硬盘上直接修改。同数据的机制相似，当元数据节点失 败时，则最新checkpoint的元数据 信息从fsimage加载到内存中，然后 逐一重新执行修改日志中的操作。从元数据节点就是用来帮助元数据节 点将内存中的元数据信息 checkpoint到硬盘上的 checkpoint的过程如下：O从元数据节点通知元数据节点 生成新的日志文件，以后的日志 都写到新的日志文件中。o从元数据节点用http get从元 数据节点获得fsimage文件及 旧的日志文件。o从元数据节点将fsimage文件 加载到内存中，并执行日志文件中的操作，然后生成新的fsimage 文件。从元数据节点奖新的fsimage 文件用http post传回元数据 节点O元数据节点可以将旧的 fsimage文件及旧的日志文 件，换为新的fsimage文件和 新的日志文件（第一步生成的），然后更新fstime文件，写入此 次checkpoint的时间。o这样元数据节点中的fsimage 文件保存了最新的checkpoint 的元数据信息，日志文件也重新 开始，不会变的很大了。元数据节点从元数据节点2.4 从元数据节点的目录结构$fs.checkpoint.d ir/current/VERSION/edits/,fsimage/,fstime/previous.checkpoint/VERSION/edits/fsimage/fstime2.5 数据节点的目录结构$dfs.data.di r/c urren t/VE RSION/blk_meta/bl/blk_.meta/-/blk_/blk_.meta/subdiro7/subdirl/subdir63/数据节点的VERSION文件格式如下：namespacelD=1232737062storagelD=DS-1 64041 1 682-1 27.0.1.1-5001 0-1 25499731 9480cTime=0storageType=DATA_NODElayoutVersion=-18blk_v id保存的是HDFS的数据块，其中保存了具体的二进制数据。blk_v id.meta保存的是数据块的属性信息:版本信息，类型信息，和checksum 当一个目录中的数据块到达一定数量的时候，则创建子文件夹来保存数据块及数据块属性文件读写1.读取文件1.1 读取文件示意图datanode datanode datanode1.2 文件读取的过程使用HDFS提供的客户端开发库，向远程的Namenode发起RPC(Remote Procedure Call)请求；Namenode会视情况返回文件的部分或者全部block列表，对于每个 block,Namenode都会返回有该block拷贝的datanode地址；客户端开发库会选取离客户端最接近的datanode来读取block；读取完当前block的数据后，关闭与当前的datanode连接，并为读 取下一个block寻找最佳的datanode；当读完列表的block后，且文件读取还没有结束，客户端开发库会继 续向Namenode获取下一批的block列表。读取完一个block都会进行checksum验证，如果读取datanode时 出现错误，客户端会通知Namenode,然后再从下一个拥有该block 拷贝的datanode继续读。2.写入文件2.1 写入文件示意图2.2 写入文件的过程1）使用HDFS提供的客户端开发库，向远程的Namenode发起RPC 请求；2）Namenode会检查要创建的文件是否已经存在，创建者是否有权 限进行操作，成功则会为文件创建一个记录，否则会让客户端抛出异 常；3）当客户端开始写入文件的时候，开发库会将文件切分成多个 packets,并在内部以“data queue”的形式管理这些packets,并向 Namenode申请新的blocks,获取用来存储replicas的合适的 datanodes歹U表,列表的大小根据在Namenode中对replication的设 置而定。4）开始以pipeline（管道）的形式将packet写入所有的replicas中。开发库把packet以流的方式写入第一个datanode,该datanode把 该packet存储之后，再将其传递给在此pipeline中的下一个 datanode,直到最后一个datanode,这种写数据的方式呈流水线的 形式。5）最后一个datanode成功存储之后会返回一个ack packet,在 pipeline里传递至客户端，在客户端的开发库内部维护着ack queue%成功收至U datanode 返回的 ack packet 后会从“ack queue 移除相应的packet o如果传输过程中，有某个datanode出现了故障，那么当前的pipeline 会被关闭，出现故障的datanode会从当前的pipeline中移除，剩余 的block会继续剩下的datanode中继续以pipeline的形式传输，同 时Namenode会分配一个新的datanode,保持replicas设定的数量。HDFS不能提供的特点1.低延时访问HDFS不太适合于那些要求低延时（数十毫秒）访问的应用程序，因为HDFS是设计用于大吞吐量数据的，这是以一定延时为代价的。HDFS是单Master的，所有的对文件的请求都要经过它，当请求多 时，肯定会有延时。当前，对于那些有低延时要求的应用程序，HBase是一个更好的选择。现在HBase的版本是0.20,相对于以前的版本，在性能上有了很大的提升，它的口号就是goes real time。使用缓存或多master设计可以降低client的数据请求压力，以减少延时。还有就是对HDFS系统内部的修改，这就得权衡大吞 吐量与低延时了，HDFS不是万能的银弹。2.大量小文件因为Namenode把文件系统的元数据放置在内存中，所以文件 系统所能容纳的文件数目是由Namenode的内存大小来决定。一般 来说，每一个文件、文件夹和Block需要占据150字节左右的空间,所以，如果你有100万个文件，每一个占据一个Block,你就至少 需要300MB内存。当前来说，数百万的文件还是可行的，当扩展到 数十亿时，对于当前的硬件水平来说就没法实现了。还有一个问题就 是，因为Map task的数量是由splits来决定的，所以用MR处理 大量的小文件时，就会产生过多的Map task,线程管理开销将会增 加作业时间。举个例子，处理10000M的文件，若每个split为1M,那就会有1 0000个Map tasks,会有很大的线程开销；若每个split 为100M,贝I只有100个Map tasks,每个Map task将会有更多 的事情做，而线程的管理开销也将减小很多。要想让HDFS能处理好小文件，有不少方法：1、利用SequenceFile MapFile Har等方式归档小文 件，这个方法的原理就是把小文件归档起来管理，HBase就是基于 此的。对于这种方法，如果想找回原来的小文件内容，那就必须得知 道与归档文件的映射关系。2、横向扩展，一个Hadoop集群能管理的小文件有限，那就把 儿个Hadoop集群拖在一个虚拟服务器后面,形成一个大的Hadoop 集群。google也是这么干过的。3、多Master设计，这个作用显而易见了。正在研发中的GFS 11也要改为分布式多Master设计，还支持Master的Failover,而 且Block大小改为1 M,有意要调优处理小文件啊。附带个Alibaba DFS的设计，也是多Master设计，它把Metadata 的映射存储和管理分开了，由多个Metadata存储节点和一个查询 Master节点组成。3.多川广写，任意文件修改目前Hadoop只支持单用户写，不支持并发多用户写。可以使 用Append操作在文件的末尾添加数据，但不支持在文件的任意位 置进行修改。这些特性可能会在将来的版本中加入，但是这些特性的 加入将会降低Hadoop的效率。利用Chubby、ZooKeeper之类的 分布式协调服务来解决一致性问题。TFSTFS简介Taobao File System（TFS）作为淘宝内部使用的分布式文件系统，是一个高可扩展、高可用、高性能、面向互联网服务的分布式文 件系统，其设计目标是“支持海量的非结构化数据”。针对海量小文 件的随机读写访问性能做了特殊优化，承载着淘宝主站所有图片、商 品描述等数据存储。TFS系统的基本情况1.完全扁平化的数据组织结构，抛弃了传统文件系统的目录结构。2.在块设备基础上建立自有的文件系统，减少EXT3等文件系统数据 碎片带来的性能损耗。3.单进程管理单块磁盘的方式，摒除RA工D5机制。4.带有HA机制的中央控制节点，在安全稳定和性能复杂度之间取得 平衡。5.尽量缩减元数据大小，将元数据全部加载入内存，提升访问速度。6.跨机架和IDC的负载均衡和冗余安全策略。7.完全平滑扩容。应用规模达到数百台PCServer,PB级数据量，百亿数据级别性能参数TFS在淘宝的部署环境中前端有两层缓冲，到达TFS系统的请求非 常离散，所以TFS内部是没有任何数据的内存缓冲的，包括传统文 件系统的内存缓冲也不存在.基本上可以达到单块磁盘随机IOPS(即I/O per second)理论最大值的60%左右，整机的输出随盘数增加而线性增加。TFS的逻辑架构图/-XApplication Client v-/blockid.file id allocatedataserver id(blockid.file id)HA heart beatIINameServera”同e-eonrrol messageheartbeat message t.八.0 heartbeat message国iq 51 购物吧结合架构图做了进一步说明1.TFS尚未对最终用户提供传统文件系统AP工，需要通过 TFSCIient进行接口访问，现有JAVA、JN工、C、PHP的客户端2.TFS的NameServer作为中心控缶I节点，监控所有数据节点的运 行状况，负责读写调度的负载均衡，同时管理一级元数据用来帮助客 户端定位需要访问的数据节点3.TFS的DataServer作为数据节点，负责数据实际发生的负载均 衡和数据冗余，同时管理二级元数据帮助客户端获取真实的业务数 据。TFS的不足之处TFS与目前一些主流的开源分布式文件系统设计思想是相似的，如 HDFS,MFS,KFS,Sector。其高可扩展、高可用性是很好的，然 而也存在-定不足,如通用性、用户接口、性能等方面。1、通用性方面。TFS目前只支持小文件的应用，大文件应用是不支持的。对小图片、网页等几十KB内的数据存储非常适用，但对视频点播VOD、文件 下载等应用暂时无法适用。2、性能方面。Client写文件是同步处理的，需要等所有dataserver写成功后才能 返回，这很是影响性能。3、用户接口。TFS没有提供POSIX接口，提供的API也与标准接口不一致。另外,TFS有自己的文件命名规则，如果用户使用自定义的文件名，则需要 自己维护文件名与TFS文件名之间的映射关系。4、代码方面。使用了 C+实现，感觉相对臃肿一点，如果用纯C实现应该会简洁 不少。代码注释基本没有，代码质量也不是很好。5、技术文档。官方有一些文档，但显然非常不够深入和全面。6、小文件优化。官方称针对海量小文件的随机读写访问性能做了特殊优化，现在只看 到把众多小文件存放与一个Block中，这与Squid中的COSS原理 相似。其他特殊优化措施未知，LOFS（Lost of small files）是个难 点问题。MooseFS（简称 MFS）MFS简介MFS是一款网络分布式文件系统。它把数据分散在多台服务器上，但对于用户来讲，看到的只是一个源。MFS也像其他类unix文件系 统一样，包含了层级结构（目录树），存储着文件属性（权限，最 后访问和修改时间），可以创建特殊的文件（块设备，字符设备，管 道，套接字），符号链接，硬链接。MFS的优点1.免费开源2.通用文件系统，不需要修改上层应用就可以使用3.可以在线扩容，体系架构可伸缩性极强4.部署简单5.体系架构高可用，所有组件无单点故障6.文件对象高可用，可任意设置文件的冗余程度，而绝对不会影响读 或写的性能，只会加速。7.提供windows回收站的功能8.提供类似java语言的垃圾回收(GC)9.提供netapp,emc,ibm等商业存储的snapshot特性。10.GFS的一个c实现1L提供web gui监控接口12.提高随机读或写的效率13.提高海量小文件的读写效率网络示意图(如下)CHUNKSERVER 1DataDISKI|DISK 2|.CHUNKSERVER 2DataDISKI|DISK 2|.CHUNKSERVER 3DataDISKI|DISK 2|.MFS文件系统结构包含的4种角色 管理服务器 managing server(master)负责各个数据存储服务器的管理,文件读写调度,文件空间回收以及 恢复.多节点拷贝 元数据日志服务器 Metalogger serve(Metalogger)负责备份master服务器的变化日志文件，文件类型为 changelog_ml.*.mfs,以便于在master server出问题的时候接替其 进行工作。元数据存储在Master的内存中，同时会保存一份在硬盘 上(作为临时更新的二进制文件和立即更新的增量日志方式)数据存储服务器 data servers(chunkservers)负责连接管理服务器,听从管理服务器调度,提供存储空间，并为客户 提供数据传输.数据文件被分成64Mb大小的块，每个块被分散的存 储在块服务器的硬盘上，同时块服务器上还会存储其他块服务器上块 文件的副本。客户端 client computers通过fuse内核接口挂接远程管理服务器上所管理的数据存储服务 器,.看起来共享的文件系统和本地unix文件系统使用一样的效果.客户端只需要mount上MFS就可像操作其他文件系统的文件一样操作 MFS中的文件了。操作系统的内核把对文件的操作传递给FUSE模块,这个模块用来和mfsmount进程进行通信。mfsmount进程后续通过网 络和管理服务器和数据块服务器进行通信。整个过程对用户来讲是透 明的。4种角色的协作过程在对所有元数据文件（文件创建，文件删除，读文件夹，读取和更改 属性，改变文件大小等等涉及到在MFSMETA上的特殊文件）进行操作 的过程中，mfsmount和管理服务器建立通信，然后开始读取和写入 数据。数据发送到所有数据服务器中有相关文件块的一台上。在完成 写操作之后，管理服务器收到文件长度和最后修改时间的更新信息。而且，数据服务器之间进行复制通信，保证每个块在不同的块服务器 上都有拷贝。因为文件块存在多个拷贝，所以，任何一台数据服务器 不可用都是不会影响到文件的正常访问的。整体来看moosfs,他的 设计理念还是很符合gfs的，从架构图来看，整个系统实现起来还是 很容易的。不过有一点值得注意的还是，对于master主机来说，这 个是一个单点，会存在隐患，在正式环境应用的时候，如何解决这里,是个关键。MFS读写进程MFS读进程MooseFS Read processCLIENTS on X chunk server(s).O 0-0CHUNK SERVERSMASTER SERVERMFS写进程MooseFS Write processCLIENTS1 Where town1 z 6?5 the 8.2d CreMt new chMtMcsooX3 SmthedMi8 X chunlc seiverts)2b SuccessCHUNK SERVERSMASTER SERVERPS:MFS提供文件系统级回收站的配置，这个回收站在整个文件系统 工作。那样如果用户删除一个文件，这个文件可以一直存在回收站中,只要管理员想留着它。回收站中的文件会在一段配置时间之后自动清 理。KFSKFS简介KFS(KOSMOS DISTRIBUTED FILE SYSTEM),一个类似 GFS、Hadoop 中HDFS的一个开源的分布式文件系统。可以应用在诸如图片存储、搜索引擎、网格计算、数据挖掘这样需要处理大数据量的网络应用中。与hadoop集成得也比较好，这样可以充分利用了 hadoop 一些现成 的功能，基于C+。KFS的特性1.自动存储扩充添加新的chunckserver,系统自动感知2.有效性复制机制保证文件有效性，一般文件会被以三种方式存储，当其中一 个chunkserver出现错误的时候，不会影响数据的读取；3.文件复制粒度可以配置文件复制的粒度，最大可以被复制64份4.还原复制当其中一个Chunckserver出现故障的时候，Metaserver会强制使用其他的chunckserver5.负载平衡系统周期地检查chunkservers的磁盘利用，并重新平衡 chunkservers的磁盘利用,HDFS现在还没有支持6.数据完整性当要读取数据时检查数据的完整性,如果检验出错使用另外的备份覆 盖当前的数据7.文件写入当一个应用程序创建了 一个文件，这个文件名会被立刻写入文件系 统，但为了性能，写入的数据会被缓存在kfs客户端.并且周期性的 从缓存中把数据更新到chunkserver中。当然，应用程序也可以强 制把数据更新到服务器上。一旦数据被更新到服务器，就可以被有效 的读取了。（我怎么能知道这个文件什么时候可以读取了呢？）8.契约使用契约来保证Client缓存的数据和文件系统中的文件保持一致性9.支持FUSE在linux系统下，可以通过Fuse映射一个文件夹，从而可以很方便的读取kfs的文件10.支持C+,Java,Python方式的调用H.提供了丰富的工具程序如 kfsshell,cp2kfs 等12.提供了启动和停止服务的脚本KFS高级特性1.支持同一文件多次写入和Append,不过不能在文件中间插入数据。（HDFS支持一次写入多次读取，不支持Append）2.文件及时生效，当应用程序创建一个文件时,文件名在系统马上有 效。（HDFS文件只当输入流关闭时才在系统中有效，因此，如果应 用程序在关闭前出现异常导致没有关闭输入流，数据将会丢失。）这一点好像也不是很好，如果输入流中断，在kfs里会留下一个错误 的文件，当读取时会出现错误，好像也没有太大的意义。KFS与HDFS的比较1.体系结构图的比较HDFS体系结构KFS体系结构2.特点的比较两者都是GFS的开源实现，而HDFS是Hadoop的子项目，用Java实 现，为Hadoop上层应用提供高吞吐量的可扩展的大文件存储服务。KFS是一个高性能的分布式文件系统，主要针对网络规模的应用，例 如存储日志数据，Map/Reduce数据等.用C+实现。它们的元数据 管理采用集中式方式实现，数据实体先分片然后分布式存储。CephCeph的目标1.可轻松扩展到数PB容量2.对多种工作负载的高性能（每秒输入/输出操作IOPS和带宽）3.高可靠性不幸的是，这些目标之间会互相竞争（例如，可扩展性会降低或者抑 制性能或者影响可靠性）。Ceph开发了一些非常有趣的概念（例如,动态元数据分区，数据分布和复制），这些概念在本文中只进行简短 地探讨。Ceph的设计还包括保护单一点故障的容错功能，它假设大 规模（PB级存储）存储故障是常见现象而不是例外情况。最后，它 的设计并没有假设某种特殊工作负载，但是包括适应变化的工作负 载，提供最佳性能的能力。它利用POSIX的兼容性完成所有这些任 务，允许它对当前依赖POSIX语义（通过以Ceph为目标的改进）的应用进行透明的部署。最后，Ceph是开源分布式存储，也是主线 Linux内核（2634）的一部分。Ceph生态系统可以大致划分为四部分1.客户端（数据用户），2.元数据服务器（缓存和同步分布式元数据），3.一个对象存储集群（将数据