3种分布式文件系统

第一部分CEPH1.1 特点Ceph最大的特点是分布式的元数据服务器通过CRUSH，一种拟算法来分配文件的locaiton，其核心是 RADOS（resilient automatic distributed object storage)，一个对象集群存储，本身提供对象的高可用，错误检测和修复功能。1.2 组成CEPH文件系统有三个主要模块：a) Client：每个Client实例向主机或进程提供一组类似于POSIX的接口。b) OSD簇：用于存储所有的数据和元数据。c) 元数据服务簇：协调安全性、一致性与耦合性时，管理命名空间（文件名和目录名）1.3 架构原理Client：用户I/O：输入/输出MDS：Metadata Cluster Server元数据簇服务器OSD：Object Storage Device对象存储设备Client通过与OSD的直接通讯实现I/O操作。这一过程有两种操作方式：1.直接通过Client实例连接到Client；2.通过一个文件系统连接到Client。当一个进行打开一个文件时，Client向MDS簇发送一个请求。MDS通过文件系统层级结构把文件名翻译成文件节点（inode），并获得节点号、模式（mode）、大小与其他文件元数据。注意文件节点号与文件意义对应。如果文件存在并可以获得操作权，则MDS通过结构体返回节点号、文件长度与其他文件信息。MDS同时赋予Client操作权（如果该Client还没有的话）。目前操作权有四种，分别通过一个bit表示：读（read）、缓冲读（cache read）、写（write）、缓冲写（buffer write）。在未来，操作权会增加安全关键字，用于client向OSD证明它们可以对数据进行读写（目前的策略是全部client都允许）。之后，包含在文件I/O中的MDS被用于限制管理能力，以保证文件的一致性与语义的合理性。CEPH产生一组条目来进行文件数据到一系列对象的映射。为了避免任何为文件分配元数据的需要。对象名简单的把文件节点需要与条目号对应起来。对象复制品通过CRUSH（著名的映射函数）分配给OSD。例如，如果一个或多个Client打开同一个文件进行读操作，一个MDS会赋予他们读与缓存文件内容的能力。通过文件节点号、层级与文件大小，Client可以命名或分配所有包含该文件数据的对象，并直接从OSD簇中读取。任何不存在的对象或字节序列被定义为文件洞或0。同样的，如果Client打开文件进行写操作。它获得使用缓冲写的能力。任何位置上的数据都被写到合适的OSD上的合适的对象中。Client关闭文件时，会自动放弃这种能力，并向MDS提供新的文件大小（写入时的最大偏移）。它重新定义了那些存在的并包含文件数据的对象的集合。CEPH的设计思想有一些创新点主要有以下两个方面：第一，数据的定位是通过CRUSH算法来实现的。传统的，或者通常的并行文件系统，数据的定位的信息是保存在文件的metadata 中的， 也就是inode结构中，通过到metadata server上去获取数据分布的信息。而在Ceph中，是通过CRUSH 这个算法来提供数据定位的。第二，元数据服务器可以提供集群metadata server 服务。只要当我们了解了其结构后，感觉并没有太大的特点。元数据服务器一般就用来存储文件和目录的信息，提供统一的命名服务。 在Ceph中，元数据的inode ， dentry，以及日志都是在对象存储集群RADOS中存储，这就使得 metadata的 持久化都是在远程的RADOS中完成，metadata server 不保存状态，只是缓存最近的inode 和 dentry项，当metadata server 失效后，其所所有信息都可以从RADOS中获取，可以比较容易恢复。CEPH最核心的，就是RADOS就是RADOS（resilient automatic distributed object storage). 其resilient 指的是可以轻松扩展，automatic 指的是其对象存储集群可以处理failover， failure recovery。RADOS 对象集群其对外提供了一个高可用的，可扩展的，对象集群，从客户端的角度看，就是一个统一命名空间的对象存储。1.4 使用方式(一) Ceph 的Monitor用来监控集群中所有节点的状态信息，完成类似配置服务的功能。在Ceph里，配置主要就是cluster map ，其保存集群所有节点信息，并和所有的节点保持心跳，来监控所有的节点状态。其通过Paxos算法实现实现自身的高可用，也就是说，这个Ceph Monitor是不会有单点问题的。目前流行的zookeeper 的功能，以及实现都类似。(二) 对象存储Ceph文件系统中的数据和元数据都保存在对象中。 对于对象存储，通常的定义是：一个Object，由三部分组成（id，metadata，data），id是对象的标识，这个不必多说。所谓的metadata，就是key/value的键值存储，至于用来保存什么信息，由文件系统的语义定义。data就是实际存储的数据。Ceph的对象，包括四个部分（id，metadata，attribute，data），在Ceph里，一个Object，实际就对应本地文件系统的一个文件，一个对象的attribute，也是key/value的键值对，其保存在本地文件系统的文件的扩展属性中。对象的metadata就是key/value的键值对，目前Ceph保存在google开源的一个key/value存储系统leveldb中，或者自己写的一个key/value 存储系统中。数据就保存在对象的文件中。对于一个对象的更新，都需要写日志中来保持一个Object数据的一致性（consistence），日志有一个单独的设备或者文件来保存。(三) 副本存储一个PG（placement group）由一个OSD列表组成，OSD的个数，就是对象的副本数，一个三副本的PG就是一个主，两个副本的OSD列表组成。一个PG和OSD列表的映射关系，是通过CRUSH算法计算的，知道PG的id，和当前的cluster map，就可以通过CRUSH算法，计算出OSD列表。特别强调的是，一个PG是逻辑层概念，也就是说，一个OSD，可能同时是一个或者多个PG的主，同时是另一个PG的从。一个OSD处于多个PG组中。一个PG就是复制和修复的基本单位。每个OSD本地保存其所在的PG列表就可以了，其它OSD可以通过输入当前的该OSD保存的cluster map 和 PG 的id ，通过CRUSH计算得出。(四) Ceph的容错处理对于Ceph文件系统，错误分两类：一类是磁盘错误或者数据损坏（ disk error or corruptted data）， 这类错误OSD会自己报告和处理。（self report ）； 第二类是OSD失去网络连接导致该OSD不可达（unreachable on the network）这种情况下需要主动检测（active monitor），在同一个PG组中的其它OSD会发心跳信息互相检测。 这种检测的一个优化的方法就是，当replication复制操作时，就可以顺带检测，不用发单独的消息来检测，只有一段时间没有replication 操作时，才发ping消息里检测。OSD的失效状态有两种：一种是down状态，这种状态下，被认为是临时错误。 在这种情况下，如果是primay，其任务由下一个replicate接手。如果该OSD没有迅速恢复（quickly recovery），那么就被标记为out状态，在这种状态下，将有新的osd加入这个PG中。如何标记一个OSD 从down状态 标记为out状态？由于网络分区的问题，需要通过 Ceph Monitor 来裁定。(五) Ceph 的写流程客户端先写主副本，然后同步到两个从副本。主副本等待从副本的ack消息和apply消息。当主副本收到ack消息，说明写操作已经写在内存中完成，收到apply 消息，说明已经apply到磁盘上了。如果在写的过程中，主副本失效，按顺序下一个从副本接管主副本的工作，这个时候是否返回给客户端写正确？在这种情况下，客户端只是判断正常工作的（acting）的 OSD的返回结果，只要所有正常工作的OSD返回即认为成功，虽然这时候可能只有两副本成功。同时该临时primay必须保存所有操作的recovey队列里，如果原primay恢复，可以replay所有recovery队列里的操作，如果主副本从down到out状态，也即是永久失效，临时primay转正，由临时primay为正式primay，只是需要加入一个新的OSD到该PG中。如果是从副本失效，就比较简单。临时失效，主replay所有写操作，如过永久失效，新加入一个OSD到PG中就可以了。(六) 恢复当有OSD失效，恢复或者增加一个新的OSD时，导致OSD cluster map的变换。Ceph处理以上三种情况的策略是一致的。为了恢复，ceph保存了两类数据，一个是每个OSD的一个version，另一个是PG修改的log，这个log包括PG修改的object 的名称和version。当一个OSD接收到cluster map的更新时：1）检查该OSD的所属的PG，对每个PG，通过CRUSH算法，计算出主副本的三个OSD2）如何该PG里的OSD发生了改变，这时候，所有的replicate向主副本发送log，也就是每个对象最后的version，当primay 决定了最后各个对象的正确的状态，并同步到所有副本上。3）每个OSD独立的决定，是从其它副本中恢复丢失或者过时的（missing or outdated）对象。 (如何恢复? 好像是整个对象全部拷贝，或者基于整个对象拷贝，但是用了一些类似于rsync的算法？目前还不清楚）4）当OSD在恢复过程中，delay所有的请求，直到恢复成功。第二部分GlusterFSGlusterFS是Scale-Out存储解决方案Gluster的核心，它是一个开源的分布式文件系统，具有强大的横向扩展能力，通过扩展能够支持数PB存储容量和处理数千客户端。GlusterFS借助TCP/IP或InfiniBand RDMA网络将物理分布的存储资源聚集在一起，使用单一全局命名空间来管理数据。GlusterFS基于可堆叠的用户空间设计，可为各种不同的数据负载提供优异的性能。GlusterFS支持运行在任何标准IP网络上标准应用程序的标准客户端，用户可以在全局统一的命名空间中使用NFS/CIFS等标准协议来访问应用数据。GlusterFS使得用户可摆脱原有的独立、高成本的封闭存储系统，能够利用普通廉价的存储设备来部署可集中管理、横向扩展、虚拟化的存储池，存储容量可扩展至TB/PB级。2.1 特点 1) 扩展性和高性能GlusterFS利用双重特性来提供几TB至数PB的高扩展存储解决方案。Scale-Out架构允许通过简单地增加资源来提高存储容量和性能，磁盘、计算和I/O资源都可以独立增加，支持10GbE和InfiniBand等高速网络互联。Gluster弹性哈希（Elastic Hash）解除了GlusterFS对元数据服务器的需求，消除了单点故障和性能瓶颈，真正实现了并行化数据访问。2) 高可用性GlusterFS可以对文件进行自动复制，如镜像或多次复制，从而确保数据总是可以访问，甚至是在硬件故障的情况下也能正常访问。自我修复功能能够把数据恢复到正确的状态，而且修复是以增量的方式在后台执行，几乎不会产生性能负载。GlusterFS没有设计自己的私有数据文件格式，而是采用操作系统中主流标准的磁盘文件系统（如EXT3、ZFS）来存储文件，因此数据可以使用各种标准工具进行复制和访问。3) 全局统一命名空间全局统一命名空间将磁盘和内存资源聚集成一个单一的虚拟存储池，对上层用户和应用屏蔽了底层的物理硬件。存储资源可以根据需要在虚拟存储池中进行弹性扩展，比如扩容或收缩。当存储虚拟机映像时，存储的虚拟映像文件没有数量限制，成千虚拟机均通过单一挂载点进行数据共享。虚拟机I/O可在命名空间内的所有服务器上自动进行负载均衡，消除了SAN环境中经常发生的访问热点和性能瓶颈问题。4) 弹性哈希算法GlusterFS采用弹性哈希算法在存储池中定位数据，而不是采用集中式或分布式元数据服务器索引。在其他的Scale-Out存储系统中，元数据服务器通常会导致I/O性能瓶颈和单点故障问题。GlusterFS中，所有在Scale-Out存储配置中的存储系统都可以智能地定位任意数据分片，不需要查看索引或者向其他服务器查询。这种设计机制完全并行化了数据访问，实现了真正的线性性能扩展。5) 弹性卷管理数据储存在逻辑卷中，逻辑卷可以从虚拟化的物理存储池进行独立逻辑划分而得到。存储服务器可以在线进行增加和移除，不会导致应用中断。逻辑卷可以在所有配置服务器中增长和缩减，可以在不同服务器迁移进行容量均衡，或者增加和移除系统，这些操作都可在线进行。文件系统配置更改也可以实时在线进行并应用，从而可以适应工作负载条件变化或在线性能调优。6) 基于标准协议Gluster存储服务支持NFS, CIFS, HTTP, FTP以及Gluster原生协议，完全与POSIX标准兼容。现有应用程序不需要作任何修改或使用专用API，就可以对Gluster中的数据进行访问。这在公有云环境中部署Gluster时非常有用，Gluster对云服务提供商专用API进行抽象，然后提供标准POSIX接口。GlusterFS在技术实现上与传统存储系统或现有其他分布式文件系统有显著不同之处，主要体现在如下几个方面。7) 完全软件实现（Software Only）GlusterFS认为存储是软件问题，不能够把用户局限于使用特定的供应商或硬件配置来解决。GlusterFS采用开放式设计，广泛支持工业标准的存储、网络和计算机设备，而非与定制化的专用硬件设备捆绑。对于商业客户，GlusterFS可以以虚拟装置的形式交付，也可以与虚拟机容器打包，或者是公有云中部署的映像。开源社区中，GlusterFS被大量部署在基于廉价闲置硬件的各种操作系统上，构成集中统一的虚拟存储资源池。简而言之，GlusterFS是开放的全软件实现，完全独立于硬件和操作系统。8) 完整的存储操作系统栈（Complete Storage Operating System Stack）GlusterFS不仅提供了一个分布式文件系统，而且还提供了许多其他重要的分布式功能，比如分布式内存管理、I/O调度、软RAID和自我修复等。GlusterFS汲取了微内核架构的经验教训，借鉴了GNU/Hurd操作系统的设计思想，在用户空间实现了完整的存储操作系统栈。9) 用户空间实现（User Space）与传统的文件系统不同，GlusterFS在用户空间实现，这使得其安装和升级特别简便。另外，这也极大降低了普通用户基于源码修改GlusterFS的门槛，仅仅需要通用的C程序设计技能，而不需要特别的内核编程经验。10) 模块化堆栈式架构（Modular Stackable Architecture）GlusterFS采用模块化、堆栈式的架构，可通过灵活的配置支持高度定制化的应用环境，比如大文件存储、海量小文件存储、云存储、多传输协议应用等。每个功能以模块形式实现，然后以积木方式进行简单的组合，即可实现复杂的功能。比如，Replicate模块可实现RAID1，Stripe模块可实现RAID0，通过两者的组合可实现RAID10和RAID01，同时获得高性能和高可靠性。11) 原始数据格式存储（Data Stored in Native Formats）GlusterFS以原始数据格式（如EXT3、EXT4、XFS、ZFS）储存数据，并实现多种数据自动修复机制。因此，系统极具弹性，即使离线情形下文件也可以通过其他标准工具进行访问。如果用户需要从GlusterFS中迁移数据，不需要作任何修改仍然可以完全使用这些数据。12) 无元数据服务设计（No Metadata with the Elastic Hash Algorithm）对Scale-Out存储系统而言，最大的挑战之一就是记录数据逻辑与物理位置的映像关系，即数据元数据，可能还包括诸如属性和访问权限等信息。传统分布式存储系统使用集中式或分布式元数据服务来维护元数据，集中式元数据服务会导致单点故障和性能瓶颈问题，而分布式元数据服务存在性能负载和元数据同步一致性问题。特别是对于海量小文件的应用，元数据问题是个非常大的挑战。GlusterFS独特地采用无元数据服务的设计，取而代之使用算法来定位文件，元数据和数据没有分离而是一起存储。集群中的所有存储系统服务器都可以智能地对文件数据分片进行定位，仅仅根据文件名和路径并运用算法即可，而不需要查询索引或者其他服务器。这使得数据访问完全并行化，从而实现真正的线性性能扩展。无元数据服务器极大提高了GlusterFS的性能、可靠性和稳定性。2.2 组成GlusterFS主要由存储服务器（Brick Server）、客户端以及NFS/Samba存储网关组成。不难发现，GlusterFS架构中没有元数据服务器组件，这是其最大的设计这点，对于提升整个系统的性能、可靠性和稳定性都有着决定性的意义。GlusterFS支持TCP/IP和InfiniBand RDMA高速网络互联，客户端可通过原生Glusterfs协议访问数据，其他没有运行GlusterFS客户端的终端可通过NFS/CIFS标准协议通过存储网关访问数据。2.3 架构原理GlusterFS总体架构与组成部分如上图所示，存储服务器主要提供基本的数据存储功能，最终的文件数据通过统一的调度策略分布在不同的存储服务器上。它们上面运行着Glusterfsd进行，负责处理来自其他组件的数据服务请求。如前所述，数据以原始格式直接存储在服务器的本地文件系统上，如EXT3、EXT4、XFS、ZFS等，运行服务时指定数据存储路径。多个存储服务器可以通过客户端或存储网关上的卷管理器组成集群，如Stripe（RAID0）、Replicate（RAID1）和DHT（分布式Hash）存储集群，也可利用嵌套组合构成更加复杂的集群，如RAID10。由于没有了元数据服务器，客户端承担了更多的功能，包括数据卷管理、I/O调度、文件定位、数据缓存等功能。客户端上运行Glusterfs进程，它实际是Glusterfsd的符号链接，利用FUSE（File system in User Space）模块将GlusterFS挂载到本地文件系统之上，实现POSIX兼容的方式来访问系统数据。在最新的3.1.X版本中，客户端不再需要独立维护卷配置信息，改成自动从运行在网关上的glusterd弹性卷管理服务进行获取和更新，极大简化了卷管理。GlusterFS客户端负载相对传统分布式文件系统要高，包括CPU占用率和内存占用。GlusterFS存储网关提供弹性卷管理和NFS/CIFS访问代理功能，其上运行Glusterd和Glusterfs进程，两者都是Glusterfsd符号链接。卷管理器负责逻辑卷的创建、删除、容量扩展与缩减、容量平滑等功能，并负责向客户端提供逻辑卷信息及主动更新通知功能等。GlusterFS 3.1.X实现了逻辑卷的弹性和自动化管理，不需要中断数据服务或上层应用业务。对于Windows客户端或没有安装GlusterFS的客户端，需要通过NFS/CIFS代理网关来访问，这时网关被配置成NFS或Samba服务器。相对原生客户端，网关在性能上要受到NFS/Samba的制约。GlusterFS是模块化堆栈式的架构设计，如上图所示。模块称为Translator，是GlusterFS提供的一种强大机制，借助这种良好定义的接口可以高效简便地扩展文件系统的功能。服务端与客户端模块接口是兼容的，同一个translator可同时在两边加载。每个translator都是SO动态库，运行时根据配置动态加载。每个模块实现特定基本功能，GlusterFS中所有的功能都是通过translator实现，比如Cluster, Storage, Performance, Protocol, Features等，基本简单的模块可以通过堆栈式的组合来实现复杂的功能。这一设计思想借鉴了GNU/Hurd微内核的虚拟文件系统设计，可以把对外部系统的访问转换成目标系统的适当调用。大部分模块都运行在客户端，比如合成器、I/O调度器和性能优化等，服务端相对简单许多。客户端和存储服务器均有自己的存储栈，构成了一棵Translator功能树，应用了若干模块。模块化和堆栈式的架构设计，极大降低了系统设计复杂性，简化了系统的实现、升级以及系统维护。2.4 使用方式GlusterFS使用算法进行数据定位，集群中的任何服务器和客户端只需根据路径和文件名就可以对数据进行定位和读写访问。换句话说，GlusterFS不需要将元数据与数据进行分离，因为文件定位可独立并行化进行。GlusterFS中数据访问流程如下：1、计算hash值，输入参数为文件路径和文件名；2、根据hash值在集群中选择子卷（存储服务器），进行文件定位；3、对所选择的子卷进行数据访问。1. 存储节点的添加GlusterFS的哈希分布是以目录为基本单位的，文件的父目录利用扩展属性记录了子卷映射信息，其下面子文件目录在父目录所属存储服务器中进行分布。由于文件目录事先保存了分布信息，因此新增节点不会影响现有文件存储分布，它将从此后的新创建目录开始参与存储分布调度。这种设计，新增节点不需要移动任何文件，但是负载均衡没有平滑处理，老节点负载较重。GlusterFS在设计中考虑了这一问题，在新建文件时会优先考虑容量负载最轻的节点，在目标存储节点上创建文件链接直向真正存储文件的节点。另外，GlusterFS弹性卷管理工具可以在后台以人工方式来执行负载平滑，将进行文件移动和重新分布，此后所有存储服务器都会均会被调度。2. 存储节点删除GlusterFS目前对存储节点删除支持有限，还无法做到完全无人干预的程度。如果直接删除节点，那么所在存储服务器上的文件将无法浏览和访问，创建文件目录也会失败。当前人工解决方法有两个，一是将节点上的数据重新复制到GlusterFS中，二是使用新的节点来替换删除节点并保持原有数据。3. 文件改名如果一个文件被改名，显然hash算法将产生不同的值，非常可能会发生文件被定位到不同的存储服务器上，从而导致文件访问失败。采用数据移动的方法，对于大文件是很难在实时完成的。为了不影响性能和服务中断，GlusterFS采用了文件链接来解决文件重命名问题，在目标存储服务器上创建一个链接指向实际的存储服务器，访问时由系统解析并进行重定向。另外，后台同时进行文件迁移，成功后文件链接将被自动删除。对于文件移动也作类似处理，好处是前台操作可实时处理，物理数据迁移置于后台选择适当时机执行。4. 弹性卷管理 GlusterFS3.1.X实现了真正的弹性卷管理。存储卷是对底层硬件的抽象，可以根据需要进行扩容和缩减，以及在不同物理系统之间进行迁移。存储服务器可以在线增加和移除，并能在集群之间自动进行数据负载平衡，数据总是在线可用，没有应用中断。文件系统配置更新也可以在线执行，所作配置变动能够快速动态地在集群中传播，从而自动适应负载波动和性能调优。弹性哈希算法本身并没有提供数据容错功能，GlusterFS使用镜像或复制来保证数据可用性，推荐使用镜像或3路复制。复制模式下，存储服务器使用同步写复制到其他的存储服务器，单个服务器故障完全对客户端透明。此外，GlusterFS没有对复制数量进行限制，读被分散到所有的镜像存储节点，可以提高读性能。弹性哈希算法分配文件到唯一的逻辑卷，而复制可以保证数据至少保存在两个不同存储节点，两者结合使得GlusterFS具备更高的弹性。第三部分 LustreLustre是一个以GNUGeneral Public为许可证的，开源的分布式并行文件系统，由Sun Microsystems Inc. 公司开发和维护。由于Lustre文件系统的体系结构具有极好的可扩展性，它得以在科学计算、石油天然气、制造业、rich media、金融等领域得到广泛部署。Lustre为其客户端提供了包含对共享文件对象的并行存取能力在内的POSIX接口。3.1 特点Lustre 是一个透明的全局文件系统，客户端可以透明地访问集群文件系统中的数据，而无需知道这些数据的实际存储位置。Lustre作为下一代的集群文件系统，可支持10,000个节点，PB的存储量，100GB/S的传输速度；两个MDS采用共享存储设备的ActiveStandby方式的容错机制；存储设备跟普通的，基于块的IDE存储设备不同，是基于对象的智能存储设备。Luxtre实现了可靠性的，可用性的，可扩展性的，可管理性的，高性能的，海量的，分布式的数据存储，并且能够按照应用需求的不同提供不同的服务，如不同的应用、不同的客户端环境、不同的性能等，真正实现了按需服务。32 组成1、对象对象是系统中数据存储的基本单位，一个对象实际上就是文件的数据和一组属性的组合，这些属性可以定义基于文件的RAID参数、数据分布和服务质量等，而传统的存储系统中用文件或块作为基本的存储单位，在块存储系统中还需要始终追踪系统中每个块的属性，对象通过与存储系统通信维护自己的属性。在存储设备中，所有对象都有一个对象标识，通过对象标识OSD命令访问该对象。通常有多种类型的对象，存储设备上的根对象标识存储设备和该设备的各种属性，组对象是存储设备上共享资源管理策略的对象集合等。2、对象存储设备对象存储设备具有一定的智能，它有自己的CPU、内存、网络和磁盘系统，目前国际上通常采用刀片式结构实现对象存储设备。OSD提供三个主要功能：（1） 数据存储。OSD管理对象数据，并将它们放置在标准的磁盘系统上，OSD不提供块接口访问方式，Client请求数据时用对象ID、偏移进行数据读写。（2） 智能分布。OSD用其自身的CPU和内存优化数据分布，并支持数据的预取。由于OSD可以智能地支持对象的预取，从而可以优化磁盘的性能。（3）每个对象元数据的管理。OSD管理存储在其上对象的元数据，该元数据与传统的inode元数据相似，通常包括对象的数据块和对象的长度。而在传统的NAS 系统中，这些元数据是由文件服务器维护的，对象存储架构将系统中主要的元数据管理工作由OSD来完成，降低了Client的开销。3、元数据服务器（Metadata Server，MDS）MDS控制Client与OSD对象的交互，主要提供以下几个功能：（1） 对象存储访问。MDS构造、管理描述每个文件分布的视图，允许Client直接访问对象。MDS为Client提供访问该文件所含对象的能力，OSD在接收到每个请求时将先验证该能力，然后才可以访问。（2） 文件和目录访问管理。MDS在存储系统上构建一个文件结构，包括限额控制、目录和文件的创建和删除、访问控制等。（3） Client Cache一致性。为了提高Client性能，在对象存储文件系统设计时通常支持Client方的Cache。由于引入Client方的Cache，带来了Cache一致性问题，MDS支持基于Client的文件Cache，当Cache的文件发生改变时，将通知Client刷新Cache，从而防止Cache不一致引发的问题。3.3 对象存储文件系统架构 Lustre是一个面向对象的文件系统。它由三个部件组成：元数据服务器（Metadataservers, MDSs）、对象存储服务器（objectstorage servers, OSSs）和客户端。上图给出了文件系统的体系结构。Lustre使用块设备来作为文件数据和元数据的存储介质，每个块设备只能由一个Lustre服务管理。Lustre文件系统的容量是所有单个OST的容量之和。客户端通过POSIX I/O系统调用来并行访问和使用数据。客户端在需要访问文件系统的文件数据时，先访问MDS，获取文件相关的元数据信息，然后就直接和相关的OST通信，取得文件的实际数据。客户端通过网络读取服务器上的数据，存储服务器负责实际文件系统的读写操作以及存储设备的连接，元数据服务器负责文件系统目录结构、文件权限和文件的扩展属性以及维护整个文件系统的数据一致性和响应客户端的请求。由于Lustre采用元数据和存储数据相分离的技术，可以充分分离计算和存储资源，使得客户端计算机可以专注于用户和应用程序的请求；存储服务器和元数据服务器专注于读、传输和写数据。存储服务器端的数据备份和存储配置以及存储服务器扩充等操作不会影响到客户端，存储服务器和元数据服务器均不会成为性能瓶颈。3.4 使用方式Lustre作为一个遵从POSIX标准的文件系统，为用户提供了诸如open()、read()、write()等统一的文件系统接口。在Linux中，这些接口是通过虚拟文件系统（Virtual File System,VFS）层实现的（在BSD/Solaris中，则称为vnode层）。在Lustre中，诸如创建、打开、读等一般的文件操作，都需要存储在MDS上的元数据信息。这些服务通过一个称为MDC的客户端接口模块来访问。从MDS的观点来看，每个文件都是分条（stripe）在一个或者多个OST上的多个数据对象的集合。一个文件的布局（layout）信息在索引节点（inode）的扩展属性（extended attribute, EA）中定义。从本质上说，EA描述了从文件对象ID到它对应的OST之间的映射关系。这些信息成为分条扩展属性（striping EA）。Lustre是个对用户透明的share文件系统，条带化数据的位置信息不能很完美的暴露出来。所以要用上Hadoop的map/reduce优势还有许多工作要做。实现廉价的Lustre容错冗余机制，实现基于对象的副本复制策略。第四部分 Ceph、GlusterFS、Lustre的比较CephGlusterFSLustreMetadata server多个MDS，不存在单点故障和瓶颈。MDS可以扩展，不存在瓶颈。无，不存在单点故障。靠运行在各个节点上的动态算法来代替MDS,不需同步元数据,无硬盘I/O瓶颈。双MDS(互相备份)。MDS不可以扩展，存在瓶颈。FUSE支持支持支持访问接口POSIXPOSIXPOSIX/MPI文件分布/数据分布文件被分片，每个数据块是一个对象。对象保存在不同的存储服务器上。Cluster Translators(GlusterFS集群存储的核心)包括AFR、DHT（和Stripe三种类型。AFR相当于RAID1，每个文件都被复制到多个存储节点上。Stripe相当于RAID0，文件被分片，数据被条带化到各个存储节点上。Translators可以组合，即AFR和stripe可以组成RAID10，实现高性能和高可用。可以把大文件分片并以类似RAID0的方式分散存储在多个存储节点上。冗余保护/副本多副本镜像无数据可靠性由数据的多副本提供可靠性。由镜像提供可靠性。由存储节点上的RAID1或RAID5/6提供可靠性。假如存储节点失效，则数据不可用。备份提供备份工具。支持远程备份。故障恢复当节点失效时，自动迁移数据、重新复制副本。当节点、硬件、磁盘、网络发生故障时，系统会自动处理这些故障，管理员不需介入。无扩展性可以增加元数据服务器和存储节点。容量可扩展。文件操作性能可扩展。元数据操作性能可扩展。容量可扩展。可增加存储节点，提高容量可文件操作性能，但是由于不能增加MDS，因此元数据操作性能不能提高，是整个系统的瓶颈。安装/部署简单简单复杂。而且Lustre严重依赖内核，需要重新编译内核。开发语言C+CC适合场景小文件适合大文件。对于小文件，无元数据服务设计解决了元数据的问题。但GlusterFS并没有在I/O方面作优化，在存储服务器底层文件系统上仍然是大量小文件，本地文件系统元数据访问是瓶颈，数据分布和并行性也无法充分发挥作用。因此，GlusterFS的小文件性能还存在很大优化空间。大文件读写产品级别中型中型重型应用无较多用户使用HPC领域。优缺点不稳定，目前还在实验阶段，不适合于生产环境。无元数据服务器，堆栈式架构(基本功能模块可以进行堆栈式组合，实现强大功能)。具有线性横向扩展能力。由于没有元数据服务器，因此增加了客户端的负载，占用相当的CPU和内存。但遍历文件目录时，则实现较为复杂和低效，需要搜索所有的存储节点。因此不建议使用较深的路径。很成熟、很庞大。