转载自# 开源主流分布式文件系统简单介绍

分布式文件系统简介

特点

• 数据量越来越多，在一个操作系统管辖的范围存不下了，那么就分配到更多的操作系统管理的磁盘中，但是不方便管理和维护，因此迫切需要一种系统来管理多台机器上的文件，这就是分布式文件管理系统 。
• 是一种允许文件通过网络在多台主机上分享的文件系统，可让多机器上的多用户分享文件和存储空间。
• 让实际上是通过网络来访问文件的动作，由程序与用户看来，就像是访问本地的磁盘一般。
• 即使系统中有某些节点脱机，整体来说系统仍然可以持续运作而不会有数据损失。
• GFS、HDFS、Lustre 、Ceph 、GridFS 、mogileFS、TFS、FastDFS等。各自适用于不同的领域。它们都不是系统级的分布式文件系统，而是应用级的分布式文件存储服务。
• 可以组建包含大量廉价服务器的海量存储系统。
• 通过内部的冗余复制，保证文件的可以用性，在海量存储系统中，容错能力非常重要。
• 可扩展性强，增加存储节点和追踪器都比较容易
• 在对个文件副本之间就进行负载均衡，可以通过横向扩展来确保性能的提升
• 进行特定的索引文件计算

普通存储方案：Rsync、DAS(IDE/SATA/SAS/SCSI等块)、NAS(NFS、CIFS、SAMBA等文件系统)、SAN(FibreChannel,iSCSI,FoE存储网络块)，Openfiler、FreeNas(ZFS快照复制)由于生产环境中往往由于对存储数据量很大，而SAN存储价格又比较昂贵，因此大多会选择分布式存储来解决以下问题：

• 海量数据存储问题
• 数据高可用问题(冗余备份)问题
• 较高的读写性能和负载均衡问题
• 支持多平台多语言问题
• 高并发问题

对于开源的分布式文件系统，多说几句：

1. GlusterFS 文件系统标准的posix接口支持，可以做分布式的软件NAS，效果莫的HPC共享存储，k8s/openstack共享存储；主要特点如下：
   • 实现了一个stack式可插拔的plugin模式，将文件系统的各种feature做成了不同的插件，比如stripe，replicate，hashErasureCode，consistent-hash等。胖客户端的设计导致了client的cpu利用率会比较高，虽然用c语言实现了协程做以应对网络io的高并发。
   • 成熟的3.x版本，服务器端没有强一致性的元数据设计，最新的4.x版本变化很大，主要是解决强者一性、集群扩展性瓶颈等问题
   • 扩容麻烦，副本rebalance效果不好，坑比较大
2. cephfs，其底层是一个对象存储系统，即ceph的rados对象存储，主要特点如下：
   • rados的crush算法比较有特点，是一种伪随机算法，既考虑了硬件的物理拓扑，也考虑了单点失败后，数据修复或者复制过程中，最小化data migrate。相对于一致性hash等副本allocation算法，在大规模的场景下，效果比较要好。
   • rados的基础上，ceph支持块存储ceph RBD，对象ceph RGW，文件系统cephfs；ceph RBD和ceph RGW比较成熟，ceph最初是跟着openstack一起火起来。ceph也可以作为openstack/k8s社区有用来共享存储，不过RBD只支持ReadWrite once，不支持多个共享写；
   • 回到cephfs上。cephfs设计的比较理想化，对目录树做了动态分区，每个分区是主备高可用，metadata server只是内存cache，持久化在rados中。cephfs的特性过于复杂，bug比较多。后期社区修改了bug，但是稳定性方面有待加强。目前只有单目录树的主备方式是可用的，三节点多活问题很多。社区方面，国内也一些创业公司和传统厂家在做ceph相关的产品，比如北京的xsky吧。
   • 目前ceph社区的关注点主要是本地存储引擎bluestore，以及用户态的block io stack（intel的spdk）。据说国内主流云数据库解决方案也是在ceph rbd基础上做的分布式存储引擎。
3. Lustre，比较老牌的分布式文件系统，部署在多个san阵列上，不支持副本，支持分布式锁，主要做HPC高性能计算；luster对posix的语义应该支持的比较好。之前intel在维护社区，主要目的是为了卖自己的cpu给一些HPC用户，后来intel是退出了。
4. HDFS只支持追加写，设计中没有考虑修改写、截断写、稀疏写等复杂的posix语义，目的并不是通用的文件系统，一般作为hadoop ecosystem的存储引擎；HDFS在bigdata领域使用很广泛，但其实big data用s3也是可以的。
5. moosefs 比较接近GoogleFS的c++实现，通过fuse支持了标准的posix，算是通用的文件系统，社区不是太活跃；
6. 还有一些专有的文件系统，比如早年的fastDFS，tfs，BeeFS。大致思想跟facebook Haystack比较像，一个专有的图片存储系统的原型，适合小文件和worm场景（write once read many）。一般大型网站，搞视频流媒体之类，都会有一套类似的解决方案。
7. 京东开源了一个ContainerFS，主要是给k8s用。

主要指标及分类对比

AFS与NFS

网络文件系统

早期的unix和nethud也是一种网络操作系统，网络操作系统和网络文件系统是一种包含关系。

(NFS) 最早由Sun微系统公司作为TCP/IP网上的文件共享系统开发。Sun公司估计现在大约有超过310万个系统在运行NFS，大到大型计算机、小至PC机，其中至少有80%的系统是非Sun平台。

Andrew文件系统

(AFS) 结构与NFS相似，由卡内基·梅隆大学信息技术中心(ITC)开发、现由前ITC职员组成的Transarc公司负责开发和销售。AFS较NFS有所增强。

(DFS) 是AFS的一个版本，作为开放软件基金会(OSF)的分布式计算环境(DCE)中的文件系统部分。

如果文件的访问仅限于一个用户，那么分布式文件系统就很容易实现。可惜的是，在许多网络环境中这种限制是不现实的，必须采取并发控制来实现文件的多用户访问，表现为如下几个形式：

只读共享 任何客户机只能访问文件，而不能修改它，这实现起来很简单。

受控写操作 采用这种方法，可有多个用户打开一个文件，但只有一个用户进行写修改。而该用户所作的修改并不一定出现在其它已打开此文件的用户的屏幕上。

并发写操作 这种方法允许多个用户同时读写一个文件。但这需要操作系统作大量的监控工作以防止文件重写，并保证用户能够看到最新信息。这种方法即使实现得很好，许多环境中的处理要求和网络通信量也可能使它变得不可接受。

NFS和AFS的区别在于对并发写操作的处理方法上。当一个客户机向服务器请求一个文件(或数据库记录)，文件被放在客户工作站的高速缓存中，若另一个用户也请求同一文件，则它也会被放入那个客户工作站的高速缓存中。当两个客户都对文件进行修改时，从技术上而言就存在着该文件的三个版本(每个客户机一个，再加上服务器上的一个)。有两种方法可以在这些版本之间保持同步：

无状态系统
在这个系统中，服务器并不保存其客户机正在缓存的文件的信息。因此，客户机必须协同服务器定期检查是否有其他客户改变了自己正在缓存的文件。这种方法在大的环境中会产生额外的LAN通信开销，但对小型LAN来说，这是一种令人满意的方法。NFS就是个无状态系统。

回呼(Callback)系统
在这种方法中，服务器记录它的那些客户机的所作所为，并保留它们正在缓存的文件信息。服务器在一个客户机改变了一个文件时使用一种叫回叫应答(callbackpromise)的技术通知其它客户机。这种方法减少了大量网络通信。AFS(及OSFDCE的DFS)就是回叫系统。客户机改变文件时，持有这些文件拷贝的其它客户机就被回叫并通知这些改变。

无状态操作在运行性能上有其长处，但AFS通过保证不会被回叫应答充斥也达到了这一点。方法是在一定时间后取消回叫。客户机检查回叫应答中的时间期限以保证回叫应答是当前有效的。回叫应答的另一个有趣的特征是向用户保证了文件的当前有效性。换句话说，若一个被缓存的文件有一个回叫应答，则客户机就认为文件是当前有效的，除非服务器呼叫指出服务器上的该文件已改变了。

开源分布式文件系统

GFS

GFS与NFS，AFS的区别

首先来说一下GFS和NFS、AFS的区别：NFS、GFS都是Remote Access Model，需要用RPC进行，每次对文件的修改立马会反馈给服务器。AFS使用的是Upload/ Download Model，拷贝文件到本地，只有关闭本地文件的时候才会把所有的更新返回，同时使用了callback函数，只有callback说本地缓存有效才能使用。

GFS用单一主控机+多台工作机的模式，由一台主控机(Master)存储系统全部元数据，并实现数据的分布、复制、备份决策，主控机还实现了元数据的checkpoint和操作日志记录及回放功能。工作机存储数据，并根据主控机的指令进行数据存储、数据迁移和数据计算等。其次，GFS通过数据分块和复制（多副本，一般是3）来提供更高的可靠性和更高的性能。当其中一个副本不可用时，系统都提供副本自动复制功能。同时，针对数据读多于写的特点，读服务被分配到多个副本所在机器，提供了系统的整体性能。最后，GFS提供了一个树结构的文件系统，实现了类似与Linux下的文件复制、改名、移动、创建、删除操作以及简单的权限管理等。

BigTable

Bigtable是一个为管理大规模结构化数据而设计的分布式存储系统，可以扩展到PB级数据和上千台服务器。本质上说，Bigtable是一个键值（key-value）映射。按作者的说法，Bigtable是一个稀疏的，分布式的，持久化的，多维的排序映射。稀疏的意思是行列时间戳的维度可以不一样，分布式是以为BigTable本身就是建立在GFS上，持久化就是它在GFS上建立可以保持数据的稳定性。用GFS来存储日志和数据文件；按SSTable文件格式存储数据；用Chubby管理元数据。主服务器负责将片分配给片服务器，监控片服务器的添加和删除，平衡片服务器的负载，处理表和列族的创建等。注意，主服务器不存储任何片，不提供任何数据服务，也不提供片的定位信息。

客户端需要读写数据时，直接与片服务器联系。因为客户端并不需要从主服务器获取片的位置信息，所以大多数客户端从来不需要访问主服务器，主服务器的负载一般很轻。

Chubby

Consensus：在一个分布式系统中，有一组的Process，它们需要确
定一个Value。于是每个Process都提出了一个Value，consensus就是指只有其中的一个Value能够被选中作为最后确定的值，并且
当这个值被选出来以后，所有的Process都需要被通知到。

在GFS中，进行数据传递的时候，Master需要选择一个chunkserver作为临时的Master响应客户端的请求，这个就是一个consensus的问题。

Chubby是一个 lock service，一个针对松耦合的分布式系统的lock service。所谓lock service，就是这个service能够提供开发人员经常用的“锁”，“解锁”功能。通过Chubby，一个分布式系统中的上千个client都能够
对于某项资源进行“加锁”，“解锁”。那么，Chubby是怎样实现这样的“锁”功能的？就是通过文件。

Chubby中的“锁”就是文件，在上例 中，创建文件其实就是进行“加锁”操作，创建文件成功的那个server其实就是抢占到了“锁”。用户通过打开、关闭和读取文件，获取共享锁或者独占锁； 并且通过通信机制，向用户发送更新信息。

HDFS

HDFS与Ceph对比

Ceph对比HDFS优势在于易扩展，无单点。HDFS是专门为Hadoop这样的云计算而生，在离线批量处理大数据上有先天的优势，而Ceph是一个通用的实时存储系统。虽然Hadoop可以利用Ceph作为存储后端，但执行计算任务上性能还是略逊于HDFS。

HDFS是GoogleFS的开源实现。HDFS1.0版本架构是一种经典的分布式文件系统架构，包括个部分：独立的元数据服务器（name node），客户端（client），数据节点（data node）。文件被切分为大小相同的chunk分布在不同的data node上。Name node维护file与chunk的映射关系以及chunk的位置信息。Client跟data node交互进行数据读写。

Ceph

• 是加州大学圣克鲁兹分校的Sage weil攻读博士时开发的分布式文件系统。并使用Ceph完成了他的论文。说 ceph 性能最高，C++编写的代码，支持Fuse，并且没有单点故障依赖， 于是下载安装， 由于 ceph 使用 btrfs 文件系统， 而btrfs 文件系统需要 Linux 2.6.34 以上的内核才支持。可是ceph太不成熟了，它基于的btrfs本身就不成熟，它的官方网站上也明确指出不要把ceph用在生产环境中。
• Ceph是一个可以按对象/块/文件方式存储的开源分布式文件系统，其设计之初，就将单点故障作为首先要解决的问题，因此该系统具备高可用性、高性能及可扩展等特点。该文件系统支持目前还处于试验阶段的高性能文件系统BTRFS(B-Tree文件系统)，同时支持按OSD方式存储，因此其性能是很卓越的，因为该系统处于试商用阶段，需谨慎引入到生产环境。
• 通过FUSE，Ceph支持类似的POSIX访问方式；Ceph分布式系统中最关键的MDS节点是可以部署多台，无单点故障的问题，且处理性能大大提升
• Ceph通过使用CRUSH算法动态完成文件inode number到object number的转换，从而避免再存储文件metadata信息，增强系统的灵活性

FastDFS

是一款类似Google FS的开源分布式文件系统，是纯C语言开发的。FastDFS是一个开源的轻量级分布式文件系统，它对文件进行管理，功能包括：文件存储、文件同步、文件访问（文件上传、文件下载）等，解决了大容量存储和负载均衡的问题。特别适合以文件为载体的在线服务，如相册网站、视频网站等等。

FastDFS是国人开发的一款分布式文件系统，目前社区比较活跃。如上图所示系统中存在三种节点：Client、Tracker、Storage，在底层存储上通过逻辑的分组概念，使得通过在同组内配置多个Storage，从而实现软RAID10,提升并发IO的性能、简单负载均衡及数据的冗余备份；同时通过线性的添加新的逻辑存储组，从容实现存储容量的线性扩容。

目前FastDFS(V4.x)代码量大概6w多行，内部的网络模型使用比较成熟的libevent三方库，具备高并发的处理能力。

NFS

NFS 是Network File System的缩写，即网络文件系统。一种使用于分散式文件系统的协定，由Sun公司开发，于1984年向外公布。功能是通过网络让不同的机器、不同的操作系统能够彼此分享个别的数据，让应用程序在客户端通过网络访问位于服务器磁盘中的数据，是在类Unix系统间实现磁盘文件共享的一种方法。

NFS 的基本原则是“容许不同的客户端及服务端通过一组RPC分享相同的文件系统”，它是独立于操作系统，容许不同硬件及操作系统的系统共同进行文件的分享。

nfsd：它是基本的NFS守护进程，主要功能是管理客户端是否能够登录服务器；mountd：它是RPC安装守护进程，主要功能是管理NFS的文件系统。当客户端顺利通过nfsd登录NFS服务器后，在使用NFS服务所提供的文件前，还必须通过文件使用权限的验证。它会读取NFS的配置文件/etc/exports来对比客户端权限;idmapd：主要功能是进行端口映射工作。当客户端尝试连接并使用RPC服务器提供的服务（如NFS服务）时，rpcbind会将所管理的与服务对应的端口提供给客户端，从而使客户可以通过该端口向服务器请求服务。

使用NFS
mount到了客户端之后，客户端访问远程文件就像访问本地文件一样。mount之后，路径访问每次只能访问当前目录，需要一次RPC，所以用户端最好进行缓存。为什么不能直接把整个目录全部返回，因为服务器不知道用户端在该目录下的文件有没有mount别的文件系统，这样贸然返回全部，很浪费资源，而且客户端不一定用得到。当然也存在有时候需要返回全部的情况，但是NFS
v4.2才有，目前该版本还在开发中。

在NFSv3维护缓存一致性的时候，采用的是30s原则。使用了一个叫做租约的东西。AFS是读取最近关闭的版本的数据。Unix是能够获得最近多有的写操作；HTTP：没有进行一致性操作，每次读取数据，都要判断是否是最新的数据。在30s内服务器不会做出改变，客户端使用write-through
缓存，并且再超过30s以后检查缓存。客户端提供会话和缓存，服务器做了一个本地服务器能够做的一切。（属于无状态缓存，stateless）