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