常用文件存储系统概述

admin管理员组

文章数量:1547089

一、概论

日常工作中，我们每个人都不可避免的遇到一个文件系统的东西，小到日常办公widnows的NTFS，MacOS的HFS+，Linux的日志文件系统ext*,xfs;这些都是我们常见OS的本地文件系统，但随着云计算，大数据，微服务技术的日趋盛起，分布式文件系统，分布式存储大容量数据，存储数据的样式种类越来越多，对数据的安全和性能的平衡等等，我们需要的文件系统的特性也越来越多，不在局限于本地的文件系统存储，本文将就此概述常用的几个文件系统Glusterfs、GFS、HDFS，FastDFS、seaweedfs、Ceph、Cinder、MooseFS、OpenAFS等，用作日常工作中参考。

另外，分布式存储按其存储接口分为三种：文件存储、块存储和对象存储。

1)文件存储

通常支持POSIX接口（如glusterfs，但GFS、HDFS是非POSIX接口的），可以像普通文件系统（如ext4）那样访问，但又比普通文件系统多了并行化访问的能力和冗余机制。主要的分布式文件存储系统有TFS、cephfs、glusterfs和HDFS等。主要存储非结构化数据，如普通文件、图片、音视频等。可以采用NFS和CIFS等协议访问，共享方便。NAS是文件存储类型。

2)块存储

这种接口通常以QEMU Driver或者Kernel Module的方式存在，主要通过qemu或iscsi协议访问。主要的块存储系统有ceph块存储、sheepdog等。主要用来存储结构化数据，如数据库数据。数据共享不方便。DAS和SAN都是块存储类型。

3)对象存储

对象存储系统综合了NAS和SAN的优点，同时具有SAN的高速直接访问和NAS的数据共享等优势。以对象作为基本的存储单元，向外提供RESTful数据读写接口，常以网络服务的形式提供数据访问。主要的对象存储系统有AWS、swift和ceph对象存储。主要用来存储非结构化数据。

二、原理和架构

2.1 Gluster（GlusterFS）

GlusterFS是一个横向扩展（Scale-out）的分布式文件系统，它免费的开源，无需改变现有基础设施，可基于现有的硬件，为媒体流、数据分析以及其他数据和带宽密集型任务创建大型分布式存储的解决方案。它将来自多个服务器的磁盘存储资源整合到一个全局名称空间中，根据存储消耗需求快速调配额外的存储。它将自动故障转移作为主要功能，当发生故障的服务器修复并使其恢复联机状态时，无需执行任何操作即可等待恢复数据。与此同时，数据的最新副本仍继续从运行的节点获取。Gluster适用于数据密集型任务，例如云存储和媒体流。 多被用于媒体、医疗保健、政府、教育、Web 2.0 和金融服务等场景。

官网，官方文档：https://docs.gluster/en/latest/，参考2.

GlusterFS初设计为一个userspace filesystem，作为userspace filesystem,为了与kernel vfs交互，Glusterfs使用了FUSE(Filesystem in Userspace) 。Fuse项目由2个组件组成，Fuse内核模块+用户控件的libfuse库，FUSE是一个kernel module，支持内核VFS和非特权用户应用程序之间的交互，并且有一个可以从用户空间访问的API，使用这个API，几乎可以使用任何语言来编写任何类型的文件系统，libfuse提供了与fuse内核模块通信的参考实现。

上图显示了一个文件系统“hello world”，它被编译来创建一个二进制“hello”。它是在文件系统挂载点/tmp/fuse上执行的。然后用户在挂载点/tmp/fuse上发出ls -l命令。这个命令通过glibc到达VFS，因为该文件系统为直接mount到/tmp/fuse上，它对应于与基于fuse的文件系统，所以VFS将它传递给fuse模块。FUSE内核模块在用户空间(libfuse)中通过glibc和FUSE库之后，与实际的文件系统二进制文件“hello”进行联系。结果由“hello”通过相同的路径返回，并到达ls -l命令。FUSE内核模块与FUSE库(libfuse)之间的通信是通过一个特殊的file descriptor进行的，该file descriptor是通过打开/dev/fuse. .来获取的，可以多次打开这个文件，并将获得的file descriptor传递给挂载的syscall，以便将描述符与挂载的文件系统相匹配。

Gluster数据可以从几乎任何地方访问，使用Tcp/Ip方式互联成一个并行的网络文件系统且兼容POSIX标准，它可在没有运行GlusterFS客户端的终端使用NFS/SMB/CIFS标准协议通过存储网关访问数据，或使用原生 GlusterFS 协议通过客户端访问数据，它没有元数据服务器；特性如下：

● 扩展到 PB级别
● 并发处理千万级访问
● 兼容POSIX（Portable Operating System Interface of UNIX：便携式操作系统接口，它是一个unix标准，但三大主流桌面系统Windows、Linux和Mac OS X中的Linux和Mac OS X本身都支持POSIX接口，这样兼容Posix，应用程序就变成可移植的，基于此的API也就平台无关性，调用通用的API）
● 可基于现有商业类硬件
● 可以使用任何支持扩展属性的磁盘文件系统
● 可使用 NFS 和 SMB 等行业标准协议访问
● 提供复制、配额、异地复制、快照和比特检测
● 允许针对不同的工作负载进行优化
● 开源免费
● 无元数据服务器：即采用无中心对称式架构，没有专用的元数据服务器，也就不存在元数据服务器瓶颈。元数据存在于文件的属性和扩展属性中。当需要访问某文件时，客户端使用DHT(Distributed Hash Table：一个路由函数，负责将每个文件精确地放在其中的一个subvolumes(子卷)上)算法，根据文件的路径和文件名计算出文件所在brick，然后由客户端从此brick获取数据，省去了同元数据服务器通信的过程。这种Hash算法定位存储路径的放肆解决了对元数据服务器的依赖，进而解决了单点故障及访问瓶颈；

常见应用场景：

● 媒体数据：文档、图片、音频、视频
● 共享存储：云储存、虚拟化存储、HPC（高性能计算）
● 大数据：日志文件、RFID（射频识别）数据

相关术语：

Brick（区块）: GFS中的存储单元，表现为一个受信存储池中的服务器的一个导出目录。可以通过主机名和目录名来标识，如’SERVER:EXPORT’
Client: 挂载了GFS卷的设备
Extended Attributes: xattr是一个文件系统的特性，其支持用户或程序关联文件/目录和元数据。
FUSE: Filesystem Userspace是一个可加载的内核模块，其支持非特权用户创建自己的文件系统而不需要修改内核代码。通过在用户空间运行文件系统的代码关联FUSE代码与内核进行桥接。
Geo-Replication（地理复制）：通过局域网(LAN)、广域网(wan)和互联网提供从一个站点到另一个站点的连续、异步和增量复制服务。
GFID: GFS卷中的每个文件或目录都有一个唯一的128位的数据相关联，其用于模拟inode
Namespace: 每个Gluster卷都导出单个ns作为POSIX的挂载点
Node: 一个拥有若干brick的设备
RDMA: 远程直接内存访问，支持不通过双方的OS进行直接内存访问。
RRDNS（round robin DNS）: 一种通过DNS轮转返回不同的设备以进行负载均衡的方法
Self-heal（自愈）: 用于后台运行检测副本卷中文件和目录的不一致性并解决这些不一致。
Split-brain: 脑裂
Translator(转译器): 将来自用户的请求转换为存储请求，可一对一、一对多、一对零；
Volfile: glusterfs进程的配置文件，通常位于/var/lib/glusterd/vols/volname
Volume: 一组bricks的逻辑集合，逻辑上由N个bricks组成。

1）架构


GlusterFS借助TCP/IP或InfiniBand RDMA（Remote Direct Memory Access远程直接内存存取）高速网络互联将分散的存储资源汇聚在一起，统一提供存储服务，并使用单一全局命名空间来管理数据。GlusterFS基于可堆叠的用户空间以及无元的设计，可为各种不同的数据负载提供优异的性能。GlusterFS架构中最大的设计特点就是没有元数据服务器组件，这有助于提升整个系统的性能、可靠性和稳定性。传统的分布式文件系统大多通过元服务器来存储元数据，元数据包含存储节点上的目录信息、目录结构等，这样的设计在浏览目录时效率非常高，且存在单点故障，一旦元数据服务器出现故障，即使节点具备再高的冗余性，整个存储系统也将崩溃，而GlusterFS分布式文件系统是基于无元服务器的设计，数据横向扩展能力强，具备较高的可靠性及存储效率。

Glusterfs是根据fuse提供的接口实现的一个用户态的文件系统，主要包括gluster、glusterd、glusterfs和glusterfsd四大模块组成：

● gluster： 是cli命令执行工具，主要功能是解析命令行参数，然后把命令发送给glusterd模块执行。

● glusterd: 是一个管理模块，处理gluster发过来的命令，处理集群管理、存储池管理、brick管理、负载均衡、快照管理等。集群信息、存储池信息和快照信息等都是以配置文件的形式存放在服务器中，当客户端挂载存储时，glusterd会把存储池的配置文件发送给客户端。

● glusterfsd：是服务端模块，存储池中的每个brick都会启动一个glusterfsd进程。此模块主要是处理客户端的读写请求，从关联的brick所在磁盘中读写数据，然后返回给客户端。

● glusterfs：是客户端模块，负责通过mount挂载集群中某台服务器的存储池，以目录的形式呈现给用户。当用户从此目录读写数据时，客户端根据从glusterd模块获取的存储池的配置文件信息，通过DHT算法计算文件所在服务器的brick位置，然后通过Infiniband RDMA 或Tcp/Ip 方式把数据发送给brick，等brick处理完，给用户返回结果。存储池的副本、条带、hash、EC等逻辑都在客户端处理。使用glusterfs提供的存储服务之前，需要先挂载存储池，向挂载点写数据，会经过fuse内核模块传给客户端，客户端检查存储池的类型，然后计算数据所在服务器 ，最后通过socket或rdma与服务器通信来完成写入;

2）优缺点

缺点：

● 不适用于存储大量小文件的场景，因GlusterFS的设计之初就是用于存储大数据的，对小文件的优化不是很好，推荐保存单个文件至少1MB以上的环境，如果是大量小文件的场景建议使用FastDFS、MFS等；
● 扩容、缩容时影响的服务器较多：Glusterfs对逻辑卷中的存储单元brick划分hash分布空间（会以brick所在磁盘大小作为权重，空间总范围为0至232-1），一个brick占一份空间，当访问某文件时，使用Davies-Meyer算法根据文件名计算出hash值，比较hash值落在哪个范围内，即可确定文件所在的brick，这样定位文件会很快。但是在向逻辑卷中添加或移除brick时，hash分布空间会重新计算，每个brick的hash范围都会变化，文件定位就会失败，因此需要遍历文件，把文件移动到正确的hash分布范围对应的brick上，移动的文件可能会很多，加重系统负载，影响到正常的文件访问操作。
● 遍历目录下文件耗时：
  1.Glusterfs没有元数据节点，而是根据hash算法来确定文件的分布，目录利用扩展属性记录子卷的中brick的hash分布范围，每个brick的范围均不重叠。遍历目录时，需要readdir子卷中每个brick中的目录，获取每个文件的属性和扩展属性，然后进行聚合，相对于有专门元数据节点的分布式存储，遍历效率会差很多，当目录下有大量文件时，遍历会非常缓慢。
  2.删除目录也会遇到同样的问题。
  3.目前提供的解决方法是合理组织目录结构，目录层级不要太深，目录下文件数量不要太多，增大glusterfs目录缓存。另外，还可以设计把元数据和数据分离，把元数据放到内存数据库中（如redis、memcache）,并在ssd上持久保存。
● 小文件性能较差：
  1.Glusterfs主要是为大文件设计，如io-cache、read-ahead、write-behind和条带等都是为优化大文件访问，对小文件的优化很少。
  2.Glusterfs采用无元数据节点的设计，文件的元数据和数据一起保存在文件中，访问元数据和数据的速率相同，访问元数据的时间与访问数据的时间比例会较大，而有元数据中心的分布式存储系统，对元数据服务器可以采用更快速的ssd盘，可以采用更大的元数据缓存等优化措施来减小访问元数据时间与访问数据时间的比值，来提高小文件性能。
  3.Glusterfs在客户端采用了元数据缓存md-cache来提高小文件性能，但是md-cache大小有限，但在海量小文件场景下，缓存命中率会严重下降，优化效果会减小，这就需要增大元数据缓存。
  4.针对小文件性能差的问题，也可以参考TFS的做法， TFS会将大量的小文件合并成一个大文件，这个大文件称为Block，每个Block拥有在集群内唯一的编号（Block Id），Block Id在NameServer创建Block时分配，NameServer维护block与DataServer（存储Block的实际数据）的关系。

优点：

● 良好的可扩展性： 使用弹性hash算法代替传统的有元数据节点服务，获得了接近线性的高扩展性。
● 高可用：采用副本（Replication）、EC（Erasure Code纠删码，相较于副本机制，纠删码机制具有更高的存储效率，在提供相同存储可靠性的条件下，可以最小化冗余存储开销，在大规模存储系统中使用纠删码机制能够节约网路带宽）等冗余设计，保证在冗余范围内的节点掉线时，仍然可以从其它服务节点获取数据，保证高可用性。采用弱一致性的设计，当向副本中文件写入数据时，客户端计算出文件所在brick，然后通过网络把数据传给所在brick，当其中有一个成功返回，就认为数据成功写入，不必等待其它brick返回，就会避免当某个节点网络异常或磁盘损坏时因为一个brick没有成功写入而导致写操作等待。服务器端还会随着存储池的启动，而开启一个glustershd进程，这个进程会定期检查副本和EC卷（Dispersed（稀疏）卷和Distributed Dispersed卷，又称纠删码卷，弥补条带和副本卷的缺点，类似于RAID5/6）中各个brick之间数据的一致性，并恢复。
● 存储池类型丰富： 包括粗粒度、条带、副本、条带副本和EC，可以根据用户的需求，满足不同程度的冗余。粗粒度卷不带任何冗余，文件不进行切片，是完整的存放在某个brick上。条带卷不带任何冗余，文件会切片存储（默认大小为128kB）在不同的brick上。这些切片可以并发读写（并发粒度是条带块），可以明显提高读写性能。该模式一般只适合用于处理超大型文件和多节点性能要求高的情况。副本卷冗余度高，副本数量可以灵活配置，可以保证数据的安全性。条带副本卷是条带卷和副本卷的结合。EC卷使用EC校验算法，提供了低于副本卷的冗余度，冗余度小于100%，满足比较低的数据安全性，例如可以使2+1（冗余度为50%）、5+3（冗余度为60%）等。这个可以满足安全性要求不高的数据。

● 高性能：采用弱一致性的设计，向副本中写数据时，只要有一个brick成功返回，就认为写入成功，不必等待其它brick返回，这样的方式比强一致性要快。另外，还提供了I/O并发、write-behind、read-ahead、io-cache、条带等提高读写性能的技术。并且这些都还可以根据实际需求进行开启/关闭，i/o并发数量，cache大小都可以调整。

说明：客户端，把原始数据信息切分为k块source data，然后通过纠删码Encoder生成n块encoded data，最后统一向服务端传输；服务端，只要能够接收到k` >= k块的encoded data（纠删码的容错能力正是来源于这些校验数据块，数据冗余度就是纠删码数，数据库最大失败小于等于该数），就能够通过纠删码decoder出所有的source data。GlusterFS存储中，EC卷是通过使用系统内存储的信息来重建丢失或损坏的数据的。存储系统底层无需做RAID，使用EC卷就能提供大容量的存储空间，还能保证较高的存储可靠性。

EC卷的自修复过程：

首先客户端检查元数据是否一致；如果不一致，则向服务端发出数据修复请求；服务端接收到请求后则会调用entrylk()和inodelk()两个函数，先是和客户端通信确认，确认后，如果修复准备就绪，就开始对元数据进行修复；元数据修复成功后，下一步就是对数据块的修复了，数据块在修复期间是没有锁的；数据块修复成功后会再次调用inodelk()函数，用于同步元数据（如扩展属性），同步成功后，自修复也就完成了。

Dispersed卷可以有任意多个bricks(B)，且可配置冗余度redunancy®，R最小值为1，最大值为(B-1)/2。R的最小值不能为0的原因在于，如果当R的值为0时，卷就不提供容错机制了，其性能还不如直接使用哈希卷，所以限定R最小值为1；R的最大值为(B-1)/2的原因在于，当R的值为B/2时，其存储利用率和replica-2复制卷相同，但其性能就远远不如replica-2复制卷了，所以限定其最大值为(B-1)/2。R最小值、最大值的确定使得B的最小值被确定为3，也就是说创建EC卷至少需要3个brick，才能创建成功。

Dispersed卷提高了存储空间的利用率，其存储利用率计算公式为(B-R)/B，有效存储空间为(B-R)*Brick_size，在理论上存储空间利用率可以达到99.9%。也就是说，能够保证在提供一定容错机制的情况下，最大限度的提高存储利用率。

Dispersed卷提高了存储的可靠性，只要任意大于等于B-R个brick能够正常则数据可正常读写，就能够保证数据是可用的、可恢复的；同时还优化了带宽的使用，且部分文件数据的分片失效引起的降级读写不影响其他文件数据的读写。

Distributed Dispersed 卷可以通过扩展Dispersed 卷生成，即扩展一倍或n倍的bricks(B)。对比于Dispersed卷，其原理相同，但在相同的erasure codeing配置下，具有更好的I/O性能。下面来以Dispersed卷来看EC卷的原理。

Disperse卷的机制：

Disperse卷中，会把每个读写请求切分为大小相同的Chunk(块)，而每个Chunk块又被分割成(B-R)个大小为512bytes的Fragment(数据分片)；然后使用算法Rabin IDA计算生成R个大小为512bytes的Fragment校验分片；最后把(B-R)个数据分片和R个校验分片以条带的方式存储在一起，即分别存储于每个Brick上，从而降低访问热点；其中R个校验分片会以轮询的方式存储于卷的每个brick上，用以提高卷的可靠性。（注：Fragment的大小在GlusterFS的源码中是一个宏定义，其大小等于EC_METHOD_WORD_SIZE* EC_GF_BITS = 648 = 512 bytes）

Disperse卷中，Chunk的大小可配置，其大小与具体的Redundancy配置有关，其大小等于512(B-R) bytes。可通过调整Redundancy的配置（注：Redundancy的配置在Disperse卷创建之后就确定，不可修改），来修改Chunk的大小。那么以官方经典的配置B=6，R=2的Disperse卷为例，得出Chunk的大小为（6-2）*512 = 2048 bytes。

Chunk的大小与性能有关，而性能又与访问模式以及文件大小有关。其性能会随着Chunk的大小改变而改变，用户可以根据具体的应用场景，通过调整Chunk的大小，在存储利用和可靠性之间做均衡选择，从而获得更好的性能。

Disperse卷使用算法Rabin IDA(Information Dispersal Algorithm)进行编码，其中R(redundancy)个校验数据由(B-R)个原始数据计算得出。

任意数据/校验块的失效都可用(B-R)个数据/校验块通过解码/编码恢复，数据块通过解码方式恢复，校验块通过编码方式恢复。

读操作时，每个Chunk都必须从B-R个brick中成功读取B-R个数据/校验分片；尽量读数据块而不是校验块；校验块轮询分布在各个brick上，达到更好的平衡负载。

写操作时，根据(B-R)个原始数据块使用算法IDA计算得出R(redundancy)个校验块，然后再把数据块和校验块以条带的方式一起写入底层所有brick中；

对于部分写操作，分为两种情况，一是没有失效的数据块分片，首先将不完整的Chunk将读出来，然后结合新写入数据重新计算校验块，最后再把数据块、校验块统一写入底层brick中；二是有失效的数据块分片，首先利用该Chunk中其他的分片通过编码/解码计算恢复，然后结合新写入数据重新计算校验块，最后再把数据块、校验块统一写入底层brick中。

更多参看：EC卷；

3）GlusterFS的卷类型：

GlusterFS支持7种卷：分布式卷、条带卷、副本卷、分布式条带卷、分布式副本卷、条带副本卷和分布式条带副本卷，这七种卷可以满足不同应用对高性能、高可用的需求。

分布式卷（Distribute volume）：文件通过HASH算法分布到所有Brick Server上，这种卷是Glusterf的基础；以文件为单位根据HASH算法散列到不同的Brick，其实只是扩大了磁盘空间，如果有一个磁盘损坏，数据也将丢失，属于文件级的RAID0，不具备容错能力；

条带卷（Stripe volume）：类似于RAID0，文件被分为数据块并以轮询的方式分布到多个Brick Server上，文件存储以数据块为单位，支持大文件存储，文件越大，读取效率越高；

副本卷（Replica volume）：将文件同步到多个Brick上，使其具备多个文件副本，属于文件级RAID1，具有容错能力。因为数据分散到多个Brick中，所以读性能得到了很大提升，但写性能下降；

分布式条带卷（Distribute Stripe volume）：Brick Server数量是条带数（数据块分布的Brick数量）的倍数，兼备分布式卷和条带卷的特点；

分布式副本卷（Distribute Replica volume）：Brick Server数量是镜像数（数据副本数量）的倍数，具有分布式卷和复制卷的特点；

条带副本卷（Stripe Replica volume）：类似于RAID10，同时具有条带卷和复制卷的特点；

分布式条带副本卷（Distribute Stripe Replica volume）：三种基本卷的复合卷，通常用于类Map Reduce应用；

1>分布式卷是GlusterFS的默认卷，在创建卷时，默认选项就是创建分布式卷。在该模式下，并没有对文件进行分块处理，文件直接存储在某个Server节点上。直接使用本地文件系统进行文件存储，大部分Linux命令和工具可以继续正常使用。需要通过扩展文件属性保存HASH值，目前支持的底层文件系统有ext3、ext4、ZFS、XFS等。由于使用本地文件系统，所以存取效率并没有提高，反而会因为网络通信的原因而有所降低；另外支持超大型文件也会有一定的难度，因为分布式卷不会对文件进行分块处理。虽然ext4已经可以支持最大16TB的单个文件，但是本地存储设备的容量实在有限。

如上图所示，File1和File2存放在Server1，而File3存放在Server2，文件都是随机存储，一个文件要么在Server1上，要么在Server2上，不能分块同时存放在Server1和Server2上。

2>条带卷：Stripe模式相当于RAID0，在该模式下，根据偏移量将文件分成N块（N个条带节点），轮询地存储在每个Brick Server节点。节点把每个数据块都作为普通文件存入本地文件系统中，通过扩展属性记录总块数和每块的序号。在配置时指定的条带数必须等于卷中Brick所包含的存储服务器数，在存储大文件时，性能尤为突出，但是不具备冗余性。

如上图所示，将文件存放在不同服务器里，File被分割为6段，1、3、5放在server1，2、4、6放在server2。

3>副本模式，也称为AFR（Automatic File Replication：使用扩展属性来跟踪文件操作，它负责跨块复制数据 ），相当于RAID1。即同一文件保存一份或多份副本，每个节点保存相同的内容和目录结构。副本模式因为要保存副本，所以磁盘利用率较低。如果多个节点上的存储空间不一致，那么将按照木桶效应取最低节点的容量作为该卷的总容量。在配置副本卷时，副本数必须等于卷中Brick所包含的存储服务器数，复制卷具备冗余性，即使一个节点损坏，也不影响数据的正常使用。AFR能保证复制一致性(即两个brick上的数据应该是相同的，即使在多个应用程序/挂载点并行地在相同的文件/目录上发生操作的情况下）；提供一种在发生故障时恢复数据的方法，只要至少有一个brick具有正确的数据；为read/stat/readdir等操作提供及时更新的数据；

如上图所示，将文件存放在服务器里，File1和File2同时存放在Server1和Server2上，相当于Server2中的文件是Server1中文件的副本。

4>分布式条带卷兼顾分布式和条带卷的功能，主要用于大文件访问处理，创建一个分布式条带卷最少需要4台服务器。

如上图所示，File1和File2通过分布式卷的功能分别定位到Server1和Server2。在Server1中，File1被分割成4段，其中1、3在Server1中exp1目录中；2、4在Server1中的exp2目录中。在Server2中，File2也被分割成4段，其中1、3在Server2中的exp3目录中，2、4在Server2中的exp4目录中。

5>分布式副本卷：兼顾分布式卷和复制卷的功能，主要用于需要冗余的情况下。

如上图所示，File1和File2通过分布式卷的功能分别定位到Server1和Server2。在存放File1时，File1根据复制卷的特性，将存在两个相同的副本，分别是Server1中的exp1目录和Server2中的exp2目录，在存放File2时，File2根据复制卷的特性，也将存在两个相同的副本，分别是Server3中的exp3目录和Server4中的exp4目录。

2.2 GFS（Google File System，GFS）

Google文件系统（Google File System，GFS）是构建在廉价的服务器之上的大型分布式系统，专为存储海量搜索数据而设计，适用于大量的顺序读取和顺序追加，如大文件的读写；注重大文件的持续稳定带宽，而不是单次读写的延迟，用于大型的、分布式的、对大量数据进行访问的应用。它将服务器故障视为正常现象，通过软件的方式自动容错，在保证系统可靠性和可用性的同时，大大减少了系统的成本。Google MapReduce就需要利用GFS作为海量数据的输入输出。

1）架构

如上图所示，GFS主要由以下三个系统模块组成：Master：是GFS 的中心节点，管理元数据、整体协调系统活动。·ChunkServer：GFS 的存储节点，存储维护数据块（Chunk），读写文件数据。·Client：向Master请求元数据，并根据元数据访问对应ChunkServer的Chunk。 正常一个GFS集群由一个master、多个chunkserver和多个clients组成。Client 向中心节点请求“查询某个文件的某部分数据”，中心节点返回文件所在的位置 (哪台 chunkserver 上的哪个文件) 以及字节区间信息；Client 根据中心节点返回的信息，向对应的 chunk server 直接发送数据读取的请求；chunk server 返回数据。

在GFS中，所有文件被切分成若干个chunk（数据块），chunk是GFS中管理数据的最小单元，每个chunk拥有唯一不变的标识（64位handle唯一标识）（在chunk创建时，由master负责分配），所有chunk都实际存储在chunkserver的磁盘上，这些chunk被当做普通的文件存储在linux系统中，每个chunk至少会在另一个chunk server上有备份，而默认会为每个chunk做三个备份。chunk大小默认为64MB，比一般的文件系统的4kb的块要大的多得多。Chunk server一般不会缓存数据，因为chunk都是存储在本地，故而linux已经将经常被访问的数据缓存在内存中了。为了容灾，每个chunk都会被复制到多个chunk serve上；注意，一般中心节点并不参与真正的数据读写，而是将文件 meta 信息返回给 Client 之后，即由 Client 来与数据节点直接通信，从而降低中心节点的负载，防止中心瓶颈。

2）工作原理：

1> 写入流程：

2.3 HDFS

2.4 Fastdfs

2.5 seaweedfs

2.6 Ceph：CephFS（对象存储）

Ceph是一个强大的可以按对象/块/文件方式存储的开源分布式文件系统，即它可在同一个系统中同时提供了3中存储实现：对象，块（通过RBD）和文件存储。无论是希望在虚拟机中使用块设备，还是将非结构化数据存储在对象存储中，Ceph都可以在一个平台上提供所有功能，并且还能获得出色的灵活性。 Ceph底层存储是基于RADOS（可靠的、自动的分布式对象存储），它提供了LIBRADOS/RADOSGW/RBD/CEPH FS方式访问底层的存储系统，Ceph中的所有内容都以对象的形式存储，不管原始的数据类型是什么，RADOS（reliable autonomic distributed object store）都会把它们当做对象来进行存储。ceph可轻松扩展到数 PB 容量。从Linux 2.6.34版内核开始，ceph目前已支持作为Linux的文件系统备选之一，Ceph.ko已经集成入Linux内核之中，另外Ceph也是目前OpenStack生态系统中呼声最高的开源存储解决方案，通过libvirt调用Ceph作为块设备进行读写访问，因此它也具备云原生属性；

Ceph 侧重构架一个企业级的对象(object)存储系统，它把每一个待管理的数据流(文件等数据)切分为一到多个固定大小(默认 4 兆)的对象数据，作为原子单元(原子是构成元素的最小单元)完成数据的读写。对象数据的底层存储服务是由多个存储主机(host)组成的存储集群，该集群也被称之为RADOS(reliable automatic distributed object store即可靠的、自动化的、分布式的对象存储系统)存储集群。

RADOS层确保数据始终保持一致状态并且可靠。Ceph会通过数据复制，故障检测和恢复，以及跨群集节点进行数据迁移和重新平衡来实现数据一致性。Ceph提供了一个符合POSIX的网络文件系统（CephFS），旨在实现高性能，大数据存储以及与传统应用程序的最大兼容。Ceph可以通过各种编程语言或者radosgw（RGW）实现无缝的访问对象存储，其中（RGW）是一种REST接口，它与为S3和Swift编写的应用程序兼容。另一方面，Ceph的RADOS块设备（RBD）可以访问在整个存储集群中条带化和复制的块设备映像。Ceph设计之初就将单点故障作为首先要解决的问题，它假设大规模（PB 级存储）存储故障是常见现象而不是例外情况，因此该系统天然具备高可用性、高性能及可扩展等特点。Ceph最适合用于块存储，大数据或直接与librados通信的任何其他应用程序的场景。

相关文献：官方文档、源码站、官网、C站

1）产品架构

Ceph的整体采用分层架构，其最底层就是RADOS集群。该集群实现了分布式的基本特征，比如数据可靠性保护（副本或者纠删码）、分布式一致性和故障检测与恢复等等。

2）特性：

♞ 独立、开放和统一的平台：将块，对象和文件存储组合到一个平台中，包括最新添加的CephFS
♞ 兼容性：可以使用Ceph 存储对外提供最兼容Amazon Web Services（AWS）S3的对象存储，支持FUSE机制，考虑POSIX 兼容性的同时加入了复制和容错功能。
♞ 精简配置模式：分配存储空间时，只是虚拟分配容量，再跟进使用情况占用实际磁盘空间。这种模式提供了更多的灵活性和磁盘空间利用率。
♞ 多副本：在Ceph Storage中，所有存储的数据都会自动从一个节点复制到多个其他节点。默认任何时间群集中的都有三份数据。
♞ 自我修复：Ceph Monitors会不断监控你的数据集。一旦出现一个副本丢失，Ceph会自动生成一个新副本，以确保始终有三份副本。
♞ 高可用：在Ceph Storage中，所有存储的数据会自动从一个节点复制到多个其他的节点。这意味着，任意节点中的数据集被破坏或被意外删除，在其他节点上都有超过两个以上副本可用，保证我们数据的可用性。
♞ 统一存储：的集群可以用于任何场景。无论希望存储非结构化数据或为数据提供块存储或提供文件系统，或者希望应用程序直接通过librados使用存储，只需要一个Ceph平台就可全部实现。
♞ 可伸缩性：Ceph Works 可以在集群中弹性扩容，满足更多规模需求。

3）工作原理：

Ceph 架构采用分层结构，可以划分为四部分：

1. Clients：客户端（数据用户）
2. cmds：Metadata server cluster，元数据服务器（缓存和同步分布式元数据）；客户使用元数据服务器，执行元数据操作（来确定数据位置）。元数据服务器管理数据位置，以及在何处存储新数据。值得注意的是，元数据存储在一个存储集群（标为 “元数据 I/O”）。实际的文件 I/O 发生在客户和对象存储集群之间。这样一来，更高层次的 POSIX 功能（例如，打开、关闭、重命名）就由元数据服务器管理，不过 POSIX 功能（例如读和写）则直接由对象存储集群管理。
3. cosd：Object storage cluster，对象存储集群（将数据和元数据作为对象存储，执行其他关键职能）
4. cmon：Cluster monitors，集群监视器（执行监视功能）

Ceph构成：

1. Pool：存储池、分区，存储池的大小取决于底层的存储空间。

2. PG(placement group)：一个 pool 内部可以有多个 PG 存在，pool 和 PG 都是抽象的逻辑概念，一个 pool 中有多少个 PG 可以通过公式计算。

3. OSD(Object Storage Daemon):每一块磁盘叫做 osd，多个 osd 组成一个主机

4. librados 是 RADOS 存储集群的 API，支持 C/C++/JAVA/python/ruby/php 等编程语言客户端调用。

有别于其他分布式系统就在于它采用Crush（Controlled Replication Under Scalable Hashing）算法使得数据的存储位置都是计算出来的而不是去查询专门的元数据服务器得来的。

2.7 cinder

2.8 MooseFS

MooseFS是波兰公司Gemius SA公司在12年前推出的，是大数据存储行业中的突破性概念。 它使您可以使用负担得起的商用硬件将数据存储和数据处理结合在一个单元中。

产品特性：

冗余：所有系统组件都是冗余的，如果发生故障，会触发自动故障转移机制，这些对用户是透明的。
节点上的计算：通过利用空闲的CPU和内存资源，支持在数据节点上调度计算，可以降低系统的总体拥有成本。
原子快照：在任何特定时间点配置文件系统都是瞬间完成且不间断。 此特性非常适合用于在线备份的解决方案。
分层存储：将不同类别的数据分配给各种类型的存储介质，以降低总存储成本。 可以将热数据存储在快速的SSD磁盘上，而将不经常使用的数据转移到更便宜，更慢的机械硬盘驱动器上。
本地客户端：通过专门为Linux，FreeBSD和MacOS系统设计的专用客户端（安装）组件来提高性能。
全局回收站:：一个虚拟的全局空间，用于记录删除对象的，和每个文件和目录的配置。 借助这个有利的特性，可以轻松恢复意外删除的数据
配额限制：系统管理员可以灵活地设置限制，以限制每个目录的数据存储容量。
滚动升级：能够一次执行一个节点的升级，硬件替换和添加，而不会中断服务。 此功能使您可以在不停机的情况下保持硬件平台的最新状态。
快速磁盘恢复：万一硬盘或硬件出现故障，系统会立即启动从冗余副本到系统内其他可用存储资源的并行数据复制。 此过程比传统的磁盘重建方法快得多。
并行性：在执行的并行线程中执行所有I / O操作，以提供高性能的读/写操作。
管理界面：提供丰富的管理工具，例如基于命令行和基于Web的界面

相关资料：官网、

1）架构

2）工作原理

2.9 OpenAFS

2.10 Lustre

三、对比分析

四、

Glusterfs、Ceph、Cinder

本文标签： 存储系统常用文件