分布式文件系统概述

分布式文件系统简介

文件系统是在物理存储和文件操作之间的抽象层，使得文件管理，存储管理更加方便。分布式文件系统，使得文件系统容易扩容，方便配置，方便共享和管理。当然具体解释就是文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连，也就是集群文件系统，可以支持大数量的节点以及PB级的数据存储。

常见的专有的分布式文件系统比如GFS、HDFS（模仿GFS）、PanFS、Lustre，MogileFS、FastDFS等等。

通用的文件系统比如NFS、AFS。

一般来说，分布式文件系统有以下特点：

• 可以组建包含大量廉价服务器的海量存储系统。
• 通过内部的冗余复制，保证文件的可以用性，在海量存储系统中，容错能力非常重要
• 可扩展性强，增加存储节点和追踪器都比较容易
• 在对个文件副本之间就进行负载均衡，可以通过横向扩展来确保性能的提升
• 进行特定的索引文件计算

普通的存储方法

Rsync、DAS(IDE/SATA/SAS/SCSI等块)、NAS(NFS、CIFS、SAMBA等文件系统)、SAN(FibreChannel, iSCSI, FoE存储网络块)，Openfiler、FreeNas(ZFS快照复制)。由于生产环境中往往由于对存储数据量很大，而SAN存储价格又比较昂贵。

分布式存储方法

常见的分布式文件系统有FastDFS，GFS、HDFS、Ceph 、GridFS 、mogileFS、TFS等。各自适用于不同的领域。它们都不是系统级的分布式文件系统，而是应用级的分布式文件存储服务。

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）

有无状态的保存（服务器需要保存客户端状态么？）

• 无状态：简单，更快速，容易从崩溃之后恢复；不会有因为追踪状态而消耗资源的问题；
• 有状态：更快，可能。能够提供更好的语义操作。

客户端访问分布式文件时需要handle，这个handle来自于服务器，有inode number，还有根据当前inode随机生成的数字。

多服务器存储

如果只有一个服务器来响应请求的话，那么负载过大，这个服务器会变成瓶颈。考虑到负载均衡和调度更新，可以使用多服务器。

NFSv3中，每个服务器都存了不同的文件，并且都有自己的NFS命名空间。具体怎么挂载就是客户端的事情。每次用户端访问一个文件，需要遍历命名空间来找到mount的节点。负载均衡方面系统管理员手动地将文件子树赋给另外一个。

pNFS

直接送到存储媒介而不需要通过文件系统。

Storage Devices是保存文件实际数据的设备，由一台或者多台数据服务器构成。当Clients获得了文件的layout后，就可以直接向Storage Devices发送数据了。由于Storage Devices包含多台数据服务器 Clients可以同时执行多个I/O请求，从而提升了系统吞吐量。pNFS只是Clients和Server之间的通信协议，Clients和Storage Devices传输数据时需要使用专门的存储协议。目前RFC定义了三种存储协议：file layout(RFC5661)、block layout(RFC5663)、object layout(RFC5664)

Server是支持pNFS特性的一台NFS服务器，Server中保存了文件的布局结构（layout）。文件布局是对文件在Storage Devices中存储方式的一种说明，Clients在读写数据前需要先向Server请求文件的layout，通过layout，Clients就可以知道文件存储在哪个Storage Device中了，以及是如何存储的。读写操作完成后，Clients需要将layout返还给Server。如果是写操作，Clients可能会修改layout，写操作完成后需要更新Server中的layout。

AFS

客户端获取整个文件并从服务器获得回调函数，在v3版本的时候是使用64KB的chunk，当然也支持整个文件。服务器使用回调当数据发生了变化。客户端使用write-back整个文件关闭的时候。（cache+callback）

AFS中，服务器也是服务独立的文件集合，但是在命名空间上只有一个。AFS内部会进行连接，帮客户找到文件在的服务器volumn，而不需要用户进行。遍历命名空间，就可以找到对应的volumn进行管理。在负载均衡上面，使用轮流改变volumn来获得。

PFS(parallel file system)

GPFS

IBM GPFS文件系统是一种专门为群集环境设计的高性能、可扩展的并行文件系统。GPFS可以在群集中的多个节点间实现对共享文件系统中文件的快速存取操作，并提供稳定的故障恢复和容错机制。主要就是HPC，超算进行。

解决metadata服务器瓶颈的方法：IBM GPFS并行文件系统与其它并行文件系统之间最大的区别在于GPFS不需要专用的元数据（Meta Data）管理服务器，所有元数据分散在磁盘阵列中，并可以由任何I/O节点管理。这样的设计避免了并行文件系统中最可能产生性能瓶颈的因素——Meta Data Server。

在文件系统层面，每个GPFS集群中可以创建最多256个文件系统，每个文件系统都对应多个管理服务器（可以由任何I/O节点承担）。当任何一个文件系统管理服务器宕机时，都会有另外一个服务器自动接替其工作，保证并行文件系统的高可用性。

GFS

Goolge的法宝：GFS、BigTable、Chubby、MapReduce。

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

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

GFS简介

GFS针对应用是大文件，连续读，不修改，高并发。

• chunkserver提供存储。GFS会将文件划分为定长数据块，每个数据块都有一个全局唯一不可变的id（chunk_handle），数据块以普通Linux文件的形式存储在chunkserver上，出于可靠性考虑，每个数据块会存储多个副本，分布在不同chunkserver。
• GFS master就是GFS的元数据服务器，负责维护文件系统的元数据，包括命名空间、访问控制、文件-块映射、块地址等，以及控制系统级活动，如垃圾回收、负载均衡等。

BigTable

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

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

MapReduce

可以看我的博客关于Hadoop的东西，在how to write fast code 专栏里面，还有代码实现或者参考文献10，这里面的解释还不错。

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其实就是抢占到了“锁”。用户通过打开、关闭和读取文件，获取共享锁或者独占锁； 并且通过通信机制，向用户发送更新信息。

数据备份

可以看我之前的博客。

参考链接：
1、分布式文件系统简介：

http://blog.51cto.com/lxlxlx/1902457

2、各种分布式文件系统简介：

http://centos2014.blog.163.com/blog/static/24054204420169911227437/

http://blog.csdn.net/qq_34531925/article/details/74908191

3、NFS与GFS的区别：

http://www.tk4479.net/wishfly/article/details/6941018

4、NFS的简介：

http://blog.51cto.com/zjw06/1754084
http://blog.51cto.com/iyull/1946592
http://blog.51cto.com/wuday/1651409

5、pNFS的介绍：

http://blog.csdn.net/ycnian/article/details/8518828

6、GFS与NFS的区别：

http://blog.csdn.net/Firehotest/article/details/69220280

7、GFS、HDFS、Blob File System架构对比：

http://blog.csdn.net/adcxf/article/details/6284871

8、BigTable：

http://blog.csdn.net/opennaive/article/details/7532589

9、GFS：

http://blog.csdn.net/opennaive/article/details/7483523

10、MapReduce：

http://blog.csdn.net/opennaive/article/details/7514146
http://blog.csdn.net/historyasamirror/article/details/3896163

11、Google Cluster：

http://blog.csdn.net/historyasamirror/article/details/3861144

12、Chubby：

http://blog.csdn.net/historyasamirror/article/details/3870168

13、GPFS：

http://www.cnblogs.com/youngerchina/p/5624564.html

14、并行文件系统简介：

http://www.tk4479.net/njpjsoftdev/article/details/52128957