3种分布式文件系统Word下载.docx
《3种分布式文件系统Word下载.docx》由会员分享，可在线阅读，更多相关《3种分布式文件系统Word下载.docx（15页珍藏版）》请在冰豆网上搜索。
对象存储设备
传统的，或者通常的并行文件系统，数据的定位的信息是保存在文件的metadata中的，也就是inode结构中，通过到metadataserver上去获取数据分布的信息。
而在Ceph中，是通过CRUSH这个算法来提供数据定位的。
第二，元数据服务器可以提供集群metadataserver服务。
只要当我们了解了其结构后，感觉并没有太大的特点。
元数据服务器一般就用来存储文件和目录的信息，提供统一的命名服务。
在Ceph中，元数据的inode，dentry，以及日志都是在对象存储集群RADOS中存储，这就使得metadata的持久化都是在远程的RADOS中完成，metadataserver不保存状态，只是缓存最近的inode和dentry项，当metadataserver失效后，其所所有信息都可以从RADOS中获取，可以比较容易恢复。
CEPH最核心的，就是RADOS就是RADOS（resilientautomaticdistributedobjectstorage）.其resilient指的是可以轻松扩展，automatic指的是其对象存储集群可以处理failover，failurerecovery。
RADOS对象集群其对外提供了一个高可用的，可扩展的，对象集群，从客户端的角度看，就是一个统一命名空间的对象存储。
1.4使用方式
（一）Ceph的Monitor
用来监控集群中所有节点的状态信息，完成类似配置服务的功能。
在Ceph里，配置主要就是clustermap，其保存集群所有节点信息，并和所有的节点保持心跳，来监控所有的节点状态。
其通过Paxos算法实现实现自身的高可用，也就是说，这个CephMonitor是不会有单点问题的。
目前流行的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（placementgroup）由一个OSD列表组成，OSD的个数，就是对象的副本数，一个三副本的PG就是一个主，两个副本的OSD列表组成。
一个PG和OSD列表的映射关系，是通过CRUSH算法计算的，知道PG的id，和当前的clustermap，就可以通过CRUSH算法，计算出OSD列表。
特别强调的是，一个PG是逻辑层概念，也就是说，一个OSD，可能同时是一个或者多个PG的主，同时是另一个PG的从。
一个OSD处于多个PG组中。
一个PG就是复制和修复的基本单位。
每个OSD本地保存其所在的PG列表就可以了，其它OSD可以通过输入当前的该OSD保存的clustermap和PG的id，通过CRUSH计算得出。
（四）Ceph的容错处理
对于Ceph文件系统，错误分两类：
一类是磁盘错误或者数据损坏（diskerroror
corruptteddata），这类错误OSD会自己报告和处理。
（selfreport）；
第二类是OSD失去网络连接导致该OSD不可达（unreachableonthenetwork）这种情况下需要主动检测（activemonitor），在同一个PG组中的其它OSD会发心跳信息互相检测。
这种检测的一个优化的方法就是，当replication复制操作时，就可以顺带检测，不用发单独的消息来检测，只有一段时间没有replication操作时，才发ping消息里检测。
OSD的失效状态有两种：
一种是down状态，这种状态下，被认为是临时错误。
在这种情况下，如果是primay，其任务由下一个replicate接手。
如果该OSD没有迅速恢复（quicklyrecovery），那么就被标记为out状态，在这种状态下，将有新的osd加入这个PG中。
如何标记一个OSD从down状态标记为out状态？
由于网络分区的问题，需要通过CephMonitor来裁定。
（五）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时，导致OSDclustermap的变换。
Ceph处理以上三种情况的策略是一致的。
为了恢复，ceph保存了两类数据，一个是每个OSD的一个version，另一个是PG修改的log，这个log包括PG修改的object的名称和version。
当一个OSD接收到clustermap的更新时：
1）检查该OSD的所属的PG，对每个PG，通过CRUSH算法，计算出主副本的三个OSD
2）如何该PG里的OSD发生了改变，这时候，所有的replicate向主副本发送log，也就是每个对象最后的version，当primay决定了最后各个对象的正确的状态，并同步到所有副本上。
3）每个OSD独立的决定，是从其它副本中恢复丢失或者过时的（missingoroutdated）对象。
（如何恢复?
好像是整个对象全部拷贝，或者基于整个对象拷贝，但是用了一些类似于rsync的算法？
目前还不清楚）
4）当OSD在恢复过程中，delay所有的请求，直到恢复成功。
第二部分GlusterFS
GlusterFS是Scale-Out存储解决方案Gluster的核心，它是一个开源的分布式文件系统，具有强大的横向扩展能力，通过扩展能够支持数PB存储容量和处理数千客户端。
GlusterFS借助TCP/IP或InfiniBandRDMA网络将物理分布的存储资源聚集在一起，使用单一全局命名空间来管理数据。
GlusterFS基于可堆叠的用户空间设计，可为各种不同的数据负载提供优异的性能。
GlusterFS支持运行在任何标准IP网络上标准应用程序的标准客户端，用户可以在全局统一的命名空间中使用NFS/CIFS等标准协议来访问应用数据。
GlusterFS使得用户可摆脱原有的独立、高成本的封闭存储系统，能够利用普通廉价的存储设备来部署可集中管理、横向扩展、虚拟化的存储池，存储容量可扩展至TB/PB级。
2.1特点
1）扩展性和高性能
GlusterFS利用双重特性来提供几TB至数PB的高扩展存储解决方案。
Scale-Out架构允许通过简单地增加资源来提高存储容量和性能，磁盘、计算和I/O资源都可以独立增加，支持10GbE和InfiniBand等高速网络互联。
Gluster弹性哈希（ElasticHash）解除了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）完全软件实现（SoftwareOnly）
GlusterFS认为存储是软件问题，不能够把用户局限于使用特定的供应商或硬件配置来解决。
GlusterFS采用开放式设计，广泛支持工业标准的存储、网络和计算机设备，而非与定制化的专用硬件设备捆绑。
对于商业客户，GlusterFS可以以虚拟装置的形式交付，也可以与虚拟机容器打包，或者是公有云中部署的映像。
开源社区中，GlusterFS被大量部署在基于廉价闲置硬件的各种操作系统上，构成集中统一的虚拟存储资源池。
简而言之，GlusterFS是开放的全软件实现，完全独立于硬件和操作系统。
8）完整的存储操作系统栈（CompleteStorageOperatingSystemStack）
GlusterFS不仅提供了一个分布式文件系统，而且还提供了许多其他重要的分布式功能，比如分布式内存管理、I/O调度、软RAID和自我修复等。
GlusterFS汲取了微内核架构的经验教训，借鉴了GNU/Hurd操作系统的设计思想，在用户空间实现了完整的存储操作系统栈。
9）用户空间实现（UserSpace）
与传统的文件系统不同，GlusterFS在用户空间实现，这使得其安装和升级特别简便。
另外，这也极大降低了普通用户基于源码修改GlusterFS的门槛，仅仅需要通用的C程序设计技能，而不需要特别的内核编程经验。
10）模块化堆栈式架构（ModularStackableArchitecture）
GlusterFS采用模块化、堆栈式的架构，可通过灵活的配置支持高度定制化的应用环境，比如大文件存储、海量小文件存储、云存储、多传输协议应用等。
每个功能以模块形式实现，然后以积木方式进行简单的组合，即可实现复杂的功能。
比如，Replicate模块可实现RAID1，Stripe模块可实现RAID0，通过两者的组合可实现RAID10和RAID01，同时获得高性能和高可靠性。
11）原始数据格式存储（DataStoredinNativeFormats）
GlusterFS以原始数据格式（如EXT3、EXT4、XFS、ZFS）储存数据，并实现多种数据自动修复机制。
因此，系统极具弹性，即使离线情形下文件也可以通过其他标准工具进行访问。
如果用户需要从GlusterFS中迁移数据，不需要作任何修改仍然可以完全使用这些数据。
12）无元数据服务设计（NoMetadatawiththeElasticHashAlgorithm）
对Scale-Out存储系统而言，最大的挑战之一就是记录数据逻辑与物理位置的映像关系，即数据元数据，可能还包括诸如属性和访问权限等信息。
传统分布式存储系统使用集中式或分布式元数据服务来维护元数据，集中式元数据服务会导致单点故障和性能瓶颈问题，而分布式元数据服务存在性能负载和元数据同步一致性问题。
特别是对于海量小文件的应用，元数据问题是个非常大的挑战。
GlusterFS独特地采用无元数据服务的设计，取而代之使用算法来定位文件，元数据和数据没有分离而是一起存储。
集群中的所有存储系统服务器都可以智能地对文件数据分片进行定位，仅仅根据文件名和路径并运用算法即可，而不需要查询索引或者其他服务器。
这使得数据访问完全并行化，从而实现真正的线性性能扩展。
无元数据服务器极大提高了GlusterFS的性能、可靠性和稳定性。
2.2组成
GlusterFS主要由存储服务器（BrickServer）、客户端以及NFS/Samba存储网关组成。
不难发现，GlusterFS架构中没有元数据服务器组件，这是其最大的设计这点，对于提升整个系统的性能、可靠性和稳定性都有着决定性的意义。
GlusterFS支持TCP/IP和InfiniBandRDMA高速网络互联，客户端可通过原生Glusterfs协议访问数据，其他没有运行GlusterFS客户端的终端可通过NFS/CIFS标准协议通过存储网关访问数据。
2.3架构原理
GlusterFS总体架构与组成部分如上图所示，存储服务器主要提供基本的数据存储功能，最终的文件数据通过统一的调度策略分布在不同的存储服务器上。
它们上面运行着Glusterfsd进行，负责处理来自其他组件的数据服务请求。
如前所述，数据以原始格式直接存储在服务器的本地文件系统上，如EXT3、EXT4、XFS、ZFS等，运行服务时指定数据存储路径。
多个存储服务器可以通过客户端或存储网关上的卷管理器组成集群，如Stripe（RAID0）、Replicate（RAID1）和DHT（分布式Hash）存储集群，也可利用嵌套组合构成更加复杂的集群，如RAID10。
由于没有了元数据服务器，客户端承担了更多的功能，包括数据卷管理、I/O调度、文件定位、数据缓存等功能。
客户端上运行Glusterfs进程，它实际是Glusterfsd的符号链接，利用FUSE（FilesysteminUserSpace）模块将GlusterFS挂载到本地文件系统之上，实现POSIX兼容的方式来访问系统数据。
在最新的3.1.X版本中，客户端不再需要独立维护卷配置信息，改成自动从运行在网关上的glusterd弹性卷管理服务进行获取和更新，极大简化了卷管理。
GlusterFS客户端负载相对传统分布式文件系统要高，包括CPU占用率和内存占用。
GlusterFS存储网关提供弹性卷管理和NFS/CIFS访问代理功能，其上运行Glusterd和Glusterfs进程，两者都是Glusterfsd符号链接。
卷管理器负责逻辑卷的创建、删除、容量扩展与缩减、容量平滑等功能，并负责向客户端提供逻辑卷信息及主动更新通知功能等。
GlusterFS3.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具备更高的弹性。
第三部分Lustre
Lustre是一个以GNUGeneralPublic为许可证的，开源的分布式并行文件系统，由SunMicrosystemsInc.公司开发和维护。
由于Lustre文件系统的体系结构具有极好的可扩展性，它得以在科学计算、石油天然气、制造业、richmedia、金融等领域得到广泛部署。
Lustre为其客户端提供了包含对共享文件对象的并行存取能力在内的POSIX接口。
3.1特点
Lustre是一个透明的全局文件系统，客户端可以透明地访问集群文件系统中的数据，而无需知道这些数据的实际存储位置。
。
Lustre作为下一代的集群文件系统，可支持10,000个节点，PB的存储量，100GB/S的传输速度；
两个MDS采用共享存储设备的Active－Standby方式的容错机制；
存储设备跟普通的，基于块的IDE存储设备不同，是基于对象的智能存储设备。
Luxtre实现了可靠性的，可用性的，可扩展性的，可管理性的，高性能的，海量的，分布式的数据存储，并且能够按照应用需求的不同提供不同的服务，如不同的应用、不同的客户端环境、不同的性能等，真正实现了按需服务。
3．2组成
1、对象
对象是系统中数据存储的基本单位，一个对象实际上就是文件的数据和一组属性的组合，这些属性可以定义基于文件的RAID参数、数据分布和服务质量等，而传统的存储系统中用文件或块作为基本的存储单位，在块存储系统中还需要始终追踪系统中每个块的属性，对象通过与存储系统通信维护自己的属性。
在存储设备中，所有对象
升级会员 