GlusterFS的分析与应用【毕业论文】 GlusterFS分布式文件系统HDFS弹性hash算法
GlusterFS 的分析和应用
[ 论文摘要] 随着互联网发展的深入，数据存储的需求得到了空前的增长。如何利用软件在廉价机器上实现高性能、高容量、高可靠性、高扩展性的存储系统便成了很值得研究的问题。作为一个分布式文件系统， GlusterFS 采用了独特的弹性 hash 算法，实现了没有元数据的非中心式的架构设计。本文以分析 GlusterFS 的原理实现为主要目的，并进行了简单的部署。过程中，结合当前流行的 Hadoop Distribute File System （ HDFS ），对其总体架构的设计、分布式存储的实现、底层存储结构和可靠性进行了对比分析。
[ 关键词] glusterfs; 分布式文件系统 ; HDFS ；弹性 hash 算法
[Abstract] With the deepening of the development of the Internet, the demand of saving data on the internet is largely growing. It has become worthy of study that how to realize a high-performance, high capacity, high reliability, highly scalable storage system in an inexpensive way. GlusterFS is a distributed file system. Using a unique Elastic-Hash Algorithm, it realizes a non-centric architecture without metadata. The main purpose of this paper is to analyze the principle of GlusterFS, and with a simple deployment case finally. Comparing with the Hadoop Distribute File System (HDFS), I make a comparative analysis of the overall architecture design, distributed storage, the underlying storage structure and reliability.
[Key Words] glusterfs; Distribute File System; HDFS; Elastic Hash Algorithm
目 录
7.2. NFS 协议和 Gluster Native Protocol 协议的区别
1. 引言
1.1. 背景
随着互联网的持续发展，一方面，为了更加便利地存取个人数据，越来越多的消费者开始将自己的资料上传到了互联网上；另一方面，各种互联网内容提供商为了更好的服务用户，也开始不断地增加着各种资源。这样一来，如何可靠、安全地存储这些大量的数据就成了一个值得研究的课题。
随着需要存储的数据越来越多，单个设备的存储能力已经不能够满足大规模数据存储系统的需要，而且数据的不断增长也要求存储系统的存储能力可以不断地进行扩展。所以如何将多台较为廉价的计算机通过网络连结起来，并通过软件来实现一个高容量、高可靠性、高扩展性的存储系统成了研究的热点问题，而分布式文件系统（ Distribute File System ）就是其中很重要的一个概念。
1.2. 国内外研究现状
在实现文件存储的网络化方面，比较早的有 NFS 等。但 NFS 是在单一的服务器上运行的，只是将文件存储服务的提供者和使用者进行了分离，可以说这只是一种文件访问协议，而并没有做到连结多台服务器来共同提供存储服务。
所以相比较与 NFS 这种分布式文件系统，有学者把这种大规模存储的文件系统也叫做集群文件系统（ Clustered File System ）。比较有名的就是 Lustre 文件系统、 Hadoop 分布式文件系统（ HDFS ）和本文要分析的 Gluster 文件系统（ GlusterFS ）。
作为一个后起之秀， GlusterFS 有着很多独有的特色，尤其是其弹性 hash 算法，成功消除了系统对元数据服务器的依赖，不仅使得系统可靠性得到了大幅的提升，也使得线性扩展成为了可能。但目前国内外 GlusterFS 的资料相对较少，也暂时没有相应的书籍或论文可以参考，除了少数比较好的博客，其余的主要还是来自 Gluster 的官方网站。
1.3. 文章的组织
为了强调 GlusterFS 的特色设计，文章主体部分（即 2 至 6 节）结合了目前非常流行的 HDFS ，对系统的总体结构、分布式存储、底层存储结构、可靠性进行了对比分析。并在第 7 节给出了一个 GlusterFS 的一个完整的部署过程和应用。
2. 总体架构设计
2.1. GlusterFS
GlusterFS 旨在成为一个通用的、 PB 级存储的、可线性扩展的分布式文件系统，提供统一的全局命名空间，并支持 NFS 、 CIFS 、 HTTP 等通用的网络访问协议。
GlusterFS 的大部分功能都是使用 Translator 机制来实现的，这借鉴了 GNU/Hurd 的设计思想，将功能点设计成一个个的 translator 。每一个 translator 被编译成了共享库文件（ .so 文件），并定义了统一的接口，这样通过串行组合很多的 translator 就可以很灵活地实现复杂的功能。在 GlusterFS 中使用的 translator 主要有：
1) Cluster ：各种集群模式，目前有 AFR （ Automatic File Replication ）、 DHT （ Distributed Hash Table ）、 Stripe ；
2) Features ：特色功能，有 locks 、 read-only 、 trash 等；
3) Performance ：跟性能相关的功能，有 io-cache 、 io-threads 、 quick-read 、 read-ahead 、 write-behind 等；
4) Protocol ： Gluster Native Protocol 通信协议的客户端和服务器端实现，有 client 、 server 等；
5) Storage ：跟本地文件系统直接交互的 POSIX 接口实现；
6) NFS ：将 GlusterFS 以 NFS 服务器的形式提供服务的功能；
7) System ：目前有 posix-acl ，提供访问控制功能；
8) Mount ： FUSE 接口实现；
9) Mgmt ：弹性卷管理器；
10) Encryption ：加密功能；
11) Debug ：系统调试相关的功能实现；
下图是一种功能串联的实现：
图 2 ‑ 1
2.2. HDFS
Hadoop 作为近年来发展迅猛的一种分布式计算 / 存储技术，为人们所瞩目，并引发了大量的研究。其采用的分布式文件系统 HDFS （ Hadoop Distributed File System ）是 2003 年 Google 工程师发表的论文《 The Google File System 》 [1] 即 GFS 的一种开源实现。 HDFS 的目的在于为特殊的应用（尤其是 MapReduce 应用）提供存储服务，而并不是一个通用型的、交互式的文件系统。在《 The Google File System 》 [1] 中提到 GFS 设计的几个基本假设：
1) 在大规模集群中，错误不再是异常；
2) 大量的超大文件；
3) 新增数据为主，很少修改已有数据；
4) 针对应用软件来设计文件系统可以简化应用软件开发和提高性能；
所以其设计采用了 “write-once-read-many （一次写入多次读取） ” 的文件访问模型：文件一经创建、写入和关闭之后，就不需要改变。简化了数据一致性问题，从而使高吞吐量的数据访问成为可能。
HDFS 是一个 Master/Slave （ NameNode/DataNode ）的结构， NameNode 负责存储目录结构、文件属性、文件块及副本的位置等元数据信息， client 需要先与 NameNode 通信获取元数据之后才去 DataNode 获取文件块，最终在 client 端进行组合拼装成一个完整的文件。 HDFS 的基本架构如下图所示：
图 2 ‑ 2
相比较与 GlusterFS 的非中心式设计， HDFS 的架构相对复杂一些，配置起来也会比较复杂，但其原理却是很清晰易懂的。
3. 研究的环境和方法
在 VMware 7.0.1 下搭建的环境：三台 server （ 192.168.37.147 、 192.168.37.148 、 192.168.37.149 ）、一台 client （ 192.168.37.139 ），操作系统为 centOS 6.0 ， GlusterFS 版本为 3.2.5 。如下图所示：
图 3 - 1
由于目前 GlusterFS 的文章比较少，且阅读 C 语言写的源代码实在有些难度，所以我还使用了下面这些工具来辅助进行分析：
l wireshark ：通过对 client 和 server 的通信过程进行抓包，然后利用关键字搜索进行分析，利用的关键字主要是“ trusted.glusterfs.dht ”和“ gfid ”。
l getfattr ：用来查看目录的扩展属性，如： “getfattr -d -m . –e hex /test1/dir1” ，即可查看 /test1/dir1 的扩展属性了。
l lsof 、 netstat 、 ps 等系统命令。
4. 分布式存储
4.1. 简单的分布式存取模型
考虑一种简单的模型： N 个存储服务器 server 构成存储池，每个存储服务器对应一个 ID ；
l 存储文件：获取当前 server 节点数为 N ，对 path 进行 hash 计算（模 N ）计算，直接将文件存放在计算结果对应的 server 节点上 。
l 读取文件：将文件读取请求发送到每个 server 节点，有该文件的 server 就将文件发给 client 。
在这种简单的模型里，每台 server 的负担是比较重的，即需要接受所有 client 的所有文件的存取请求，而且因为每一次文件请求都是广播行为，所以其网络负担也是比较重的。但是其优点也是明显的：在网络通畅的情况下，线性扩展是非常容易的。
4.2. 弹性 Hash 算法的实现
4.2.1. 扩展文件属性
由于弹性 Hash 算法中使用到了扩展文件属性，所以这里先简述一下这个概念。
扩展文件属性是文件系统的一种功能，在 linux 中 ext2 、 ext3 、 ext4 、 JFS 、 ReiserFS 以及 XFS 文件系统都支持扩展属性（英文简写为 xattr ）。以 ext4 为例，文件系统结构中主要的是 inode table 和 data blocks ，前者用来存储文件的元数据（数据块的位置信息等），每个文件或目录对应一个 inode 记录；后者即实际文件的数据块。扩展属性存放在 inode table 的每一条记录中。
图 4 ‑ 1
任何一个文件或目录都对应有一个 inode ，所以就可以有一系列的扩展属性。扩展属性是 name/value 对， name 必须有名称空间前缀，中间用点 “.” 分隔（如 user.name ）。目前有四种名称空间： user 、 trusted 、 security 、 system 。 GlusterFS 主要使用 trusted 名称空间进行保存其需要的一些信息。
4.2.2. 弹性 Hash 算法原理
4.2.2.1. 算法概述
在前面简单的模型中，文件查找时， server 端的计算量可以分成两类：
1) 文件父目录（ path 最后一个目录节点）的定位查找
2) 父目录下文件的定位查找
该算法利用文件系统的扩展属性保存了 hash 计算需要的信息，减免了第二步的计算量，一定程度上降低了 server 端的负担。
将简单模型精细化为：假设有 N 个节点， hash 函数的值域对应的 32 位整数空间就被均分成 N 个子空间，每个节点对应一个子空间（以下称为 hash range ），对文件名进行 hash 计算后会落在 N 个子空间中的一个，这样就去其对应的节点存取文件。
该算法将每个节点的 hash range 信息保存在每个节点上文件父目录的扩展属性中名为 trusted.glusterfs.dht 的属性里，如下图所示：
图 4 ‑ 2
增加新节点时，新节点会完全复制目录结构和扩展属性中的 gfid （目录 id ），但不复制 hash range 属性。所以如果在虚拟卷的旧目录下新增文件，该新节点将不会参与分布。如下图所示，创建 Dir1 和 Dir2 后，新增节点 ③ ，如果新建文件的父目录是 Dir1 或 Dir2 （例 :/Dir1/newfile.txt 或 /Dir2/newfile.txt ），那么该文件只会被分布在节点 ① 或 ② ，而不会分布在节点 ③ ，因为节点③上的 Dir1 或 Dir2 的扩展属性中没有 trusted.glusterfs.dht 属性。
图 4 ‑ 3
4.2.2.2. 创建目录的过程
1) 给当前的所有节点分配 hash range ；
2) 向当前的所有节点发送创建目录 Dir1 请求，并发送目录的 gfid 和分配给该节点的 hash range ；
3) server 端创建目录 Dir1 ，并将 hash range 写入扩展属性 trusted.glusterfs.dht 。
图 4 ‑ 4
4.2.2.3. 创建文件的过程
在 Dir1 已经存在的情况下，存储 Dir1/file1.txt 时，过程如下：
1) 对文件名 “file1.txt” 进行 hash 计算，得到 32 位的 hash 值；
2) client 向每个 server 节点请求该节点上 Dir1 的扩展属性 hash range ；
3) 确定 hash 值落在哪节点的 hash range 中，然后就将文件存储在该节点上；
图 4 ‑ 5
4.2.2.4. 读取文件的过程
在将 test-volume 所在的任意一台 brick 服务器 server1 挂载到了 client 上后，进行文件读取的过程如下：
1) 对文件名 “file1.txt” 进行 hash 计算，得到 32 位的 hash 值
2) 读取 Dir1/file1.txt 时， client 需要向所有的 server 节点上获取 Dir1 的扩展属性 hash range 。
3) 看 hash 值落在哪个节点的 hash range 中，再去对应的节点请求文件。
图 4 ‑ 6
4.2.3. 负载均衡问题及其解决办法
如果仅仅只有上面的解决方案，系统就有两个重要的问题：一个是部分节点空间不足导致创建文件失败；另一个是老节点的负载比较重导致负载不均衡。对于这个两个问题， GlusterFS 提供了对应的解决办法：
1) 使用链接文件。新建文件时，如果 hash 选定的目标节点已满，那么系统就会选择其他节点中负载最小的节点进行文件存储，同时在原目标节点上创建链接文件指向实际的文件。这种方式同样用于解决文件重命名问题。
2) 提供了 rebalance 机制，以人工的方式进行 hash range 的重新分配和文件的迁移。默认情况下会进行简单的 hash range 平均分配，并不考虑原有的存储情况。但这种简单平均分配 hash range 的方式可能会导致大量的文件迁移，所以这种机制还有改进的余地。
4.2.4. 算法改进的一种思路
针对原来算法中广播文件请求带来的网络负担，我的一种改进思路如下：
1) 每个节点的父目录的扩展属性中保存所有参与分布的节点的 hash range ，而不仅仅只有该节点的 hash range 。这样就可以避免向所有的节点请求 hash range 信息。
2) 新增节点完全复制目录结构和扩展属性（含 gfid 和所有参与该目录下文件分布的节点的 hash range 信息）。这样 client 端去任意一台 server ，无论新旧，都可以获得所有参与该目录下文件分布的节点的 hash range 信息。
3) client 每次查找文件时需要随机的获取两台 server 上的扩展属性，并进行比对，如果一致则进行文件定位和访问，否则需要先进行扩展属性的修复。
这时，其实也就可以说也出现了一点 “ 元数据 ” 的感觉，但是这个元数据是被备份了多份的，这样就会存在一致性问题，至于那种更好还需要更多的实验去验证。
4.3. HDFS 的元数据式的存储设计
典型的集群文件系统使用的是 Master/Slave 结构的，如 lustre 和 GFS 等，有专门的元数据服务器（在 lustre 中是 MDS ，在 GFS 中是 NameNode ）。
HDFS 是基于 Master/Salve 结构（ NameNode/DataNode ），由 NameNode 维护着统一的名字空间、文件块及其副本的分布信息等元数据。
以文件读取为例，其时序图如下：
图 4 ‑ 7
这种中心式的结构的优点是：可以灵活地对文件块进行分布，容易进行性能优化和访问控制。
但它所带来的问题也是显而易见的：
1) 如果 NameNode 出现故障，那么整个文件系统就完全崩溃了。
2) 任何的文件操作都需要跟 NameNode 进行交互，这就导致了 NameNode 容易成为整个文件系统的瓶颈，导致系统性能不能随着存储节点的增加而线性提高。
所以在整个系统的可靠性和扩展性方面， HDFS 会不如 GlusterFS ，所以它并不太适合作为可靠性为主的通用存储系统，而更适合于并行计算为主且系统可靠性性要求较低的应用环境，如 Page-Rank 网页排名算法应用等。
5. 底层存储结构
5.1. GlusterFS
5.1.1. Distributed 模式
在该模式下，并没有对文件进行分块处理，文件直接存储在某个 server 节点上。 “ 没有重新发明* ” ，这句话很好的概括了这种 GlusterFS 的设计思路。因为使用了已有的本地文件系统进行存储文件，所以通用的很多 linux 命令和工具可以继续正常使用。这使得 GlusterFS 可以在一个比较稳定的基础上发展起来，也更容易为人们所接受。因为需要使用到扩展文件属性，所以其目前支持的底层文件系统有： ext3 、 ext4 、 ZFS 、 XFS 等。
由于使用本地文件系统，一方面，存取效率并没有什么没有提高，反而会因为网络通信的原因而有所降低；另一方面，支持超大型文件会有一定的难度。虽然 ext4 已经可以支持最大 16T 的单个文件，但是本地存储设备的容量实在有限。所以如果有大量的大文件存储需求，可以考虑使用 Stripe 模式来实现，如考虑新建专门存储超大型文件的 stripe 卷。
5.1.2. Stripe 模式
其实 Stripe 模式相当于 raid0 ，在该模式下，系统只是简单地根据偏移量将文件分成 N 块（ N 个 stripe 节点时），然后发送到每个 server 节点。 server 节点把每一块都作为普通文件存入本地文件系统中，并用扩展属性记录了总的块数（ stripe-count ）和每一块的序号（ stripe-index ）。如下图，这个是第一块，另外两块的 index 分别是 0x3100 和 0x3200 。
图 5 ‑ 1
使用 du -h 命令可以查看每个块所占用的硬盘空间，相加即等于整个文件的大小。所以使用这种方式系统就可以支持存储更大的文件，并且因为可以并行读取，文件的读取速度也可以得到大幅的提升。
5.2. HDFS
5.2.1. HDFS 文件块
在 HDFS 中，文件的分布式存储基本是在块（ Block ）级别上进行的，就如其设计的初衷：适合大文件存储。其将文件进行分块，将不同的块分布在不同的服务器上，由 NameNode 来记录每个文件对应的所有块的位置信息。
在 HDFS 块的默认大小为 64M （ ext4 支持的最大块的 8k ），一个大文件会被拆分成一堆块集合，每个块都会被独立地进行存储。其目的是减少寻址时间占整体传输时间的比例，而且可以降低整个系统的负担：一方面，因为块越大，总的元数据就会越少，减少了内存占用；另一方面，存取一个大文件时，访问 NameNode 的次数和数据传输量都会减少，从而也就降低了 CPU 和网络的负担。
图 5 ‑ 2
5.2.2. 文件分块设计的优缺点
在以计算为主和超大文件存储的应用环境下，分块的好处是显而易见的，它使得 MapReduce 可以对大文件的每一块进行独立地计算处理，而且可以在计算机网络内进行文件块的动态迁移，将文件块迁移到计算空闲的机器上，充分利用 CPU 计算资源，加快处理速度。这一点是 GlusterFS 无法做到的。对于 GlusterFS ，因为是根据文件名进行 hash 计算的，所以文件一经创建，基本就确定了位置了，如果不人工干预，是不会发生改变的。
但这种设计的问题也是明显的，因为分块导致了文件难以修改数据，这也就是《 The Google File System 》 [1] 中提到的第三条假设： “ 新增数据为主，很少修改已有数据 ” 所导致的，所以这样存储系统并不适合作为通用文件系统进行使用。
6. 可靠性
6.1. GlusterFS
6.1.1. Replicated 模式
Replicated 模式，也称作 AFR （ Auto File Replication ），相当于 raid1 ，即同一文件在多个镜像存储节点上保存多份，每个 replicated 子节点有着相同的目录结构和文件。 replicated 模式一般不会单独使用，经常是以“ Distribute + Replicated” 或“ Stripe + Replicated ”的形式出现的。如果两台机的存储容量不同，那么就如木桶效应，系统的存储容量由容量小的机器决定。
Replicated 模式是在文件的级别上进行的（相比较于 HDFS ），而且在创建卷 volume 时就确定每个 server 节点的职责，而且只能人工的进行调整。这样的话就相对的不灵活，如果一个节点 A 出了问题，就一定要用新的节点去替代 A ，否则就会出现一些问题隐患。
在 Replicated 模式下，每个文件会有如下几个扩展属性：
图 6 ‑ 1
读写数据时，具体的情况如下 ：
l 读数据时：系统会将请求均衡负载到所有的镜像存储节点上，在文件被访问时同时就会触发 self-heal 机制，这时系统会检测副本的一致性（包括目录、文件内容、文件属性等）。若不一致则会通过 change log 找到正确版本，进而修复文件或目录属性，以保证一致性。
l 写数据时：以第一台服务器作为锁服务器，先锁定目录或文件，写 change log 记录该事件，再在每个镜像节点上写入数据，确保一致性后，擦除 change log 记录，解开锁。
如果互为镜像的多个节点中有一个镜像节点出现了问题，用户的读 / 写请求都可以正常的进行，并不会受到影响。而问题节点被替换后，系统会自动在后台进行同步数据来保证副本的一致性。但是系统并不会自动地需找另一个节点来替代它，而是需要通过人工新增节点来进行，所以管理员必须及时地去发现这些问题，不然可靠性就很难保证。
6.2. HDFS
6.2.1. 数据块级别的副本
HDFS 的可靠性是在文件块级别上进行的，所以可以定义每个块的副本数，比较灵活，而且由于同一个文件的多个文件块不一定在同一台存储服务器上，甚至不一定在同一机架 rack 上，所以丢失一个文件的所有数据的可能性更低。所以相比之下， HDFS 的可靠性更高一些。
6.2.2. Rack-Aware 策略
在通常情况下，整个集群上的所有节点可以认为是等同的，这时候所有的存储节点可以看作是一个平坦的存储空间。按这种考虑，文件块的所有是否放在同一个机架上就没有什么值得研究的实际意义，但实际情况却非如此。
实际情况中，集群是由大量的机架组成的，某些问题可能会导致整个机架同时崩溃，所以同一个机架或不同一个机架上的两个节点同时崩溃的概率是不同的。 Rack-Aware Replica Placement （机架感知的副本存放策略） 就是为了这个目的而设计的。
该策略的具体实现需要自己编写脚本，输入参数为 IP 地址，输出为 Rack Id ，编写完的脚本需要在 JobTracker 的 hadoop-site.xml 配置文件中配置 topology.script.file.name 。这样 Hadoop 在启动时就会去检查并利用这个脚本来进行 rack-aware 策略。
合理的策略下，文件块的副本会被分别放在不同的 rack 机架上。因为不同一个机架上的两个节点同时崩溃的概率低于同一机架上的两个节点，所以仅从单个文件的角度来看， HDFS 的这种方案的确比 GlusterFS 有着更好的可靠性。
7. 在 NFS 协议下 GlusterFS 的应用
7.1. NFS 协议简介
NFS 是 Network File System 的简写 , 即网络文件系统 . ， NFS 允许一个系统在网络上与他人共享目录和文件。通过使用 NFS ，客户端程序就可以像访问本地文件一样访问远端系统上的文件了。
NFS 的两个主要的进程（守护进程）
l biod 守护进程：运行在所有 client 机上，当客户机上的用户要读写服务器上的文件时， biod 守护进程将此请求发送至服务器。
l nfsd 守护进程：运行在 server 机上，接收来自 client 机的请求，并转换为本地文件系统的读写，并将结果返回给 client 机。
实现的方式基本流程如下：
1) NFS 的底层使用 RPC 实现，且 NFS 守护进程使用的端口号是临时决定的，所以使用该协议时需要使用 portmap （ rpcbind ）提供注册服务。
2) server 端进程启动时向 portmap(rpcbind) 进行注册
3) client 端进程先通过服务名在 portmap （ rpcbind ）中找到目标服务进程的端口号
4) 根据目标服务进程的端口号，发送某目录挂载 mount 请求，由 mountd 负责检查权限，然后返回文件目录句柄
5) client 进程利用远程的文件目录句柄，虚拟的将文件目录挂载到本地，此后对文件操作可以透明地进行了。
在 GlusterFS 中， server 端的 glusterfs 进程会同时启动 nfs 和 mountd 线程，并向 rpcbind 进行注册（可以通过 rpcinfo 命令查看）。
所以在使用 NFS 协议挂载 GlusterFS 时，会有如下通信过程：
图 7 ‑ 1
7.2. NFS 协议和 Gluster Native Protocol 协议的区别
通过查看 /etc/glusterd/nfs/nfs-server.vol 配置文件可以知道，其实 GlusterFS 的 nfs-server 其实也是一个 GlusterFS 客户端，只是它没有将 GlusterFS 挂载到本地文件系统，而是将 glusterfs 逻辑卷重新以 NFS 的方式分享出去。如下图， nfs-server 将三个逻辑卷 test-volume 、 stripe-volume 和 replicated-volume 重新以 NFS 服务器的形式分享出去：
图 7 ‑ 2
直接使用 Gluster Native Protocol 时，数据流如下
图 7 ‑ 3
使用 NFS 时数据流是：
图 7 ‑ 4
所以使用这种方式，性能的下降是必然的，同时还会带来一个 “ 单点故障 ” 的问题。在使用 Gluster Native Protocol 协议时，因为 client 跟每个 server 节点是有端口直接相连，如下图所示（ 1832 即 client 端的 glusterfs 进程 ID ）：
图 7 ‑ 5
所以即使某个 server 节点出了问题，也不会影响 client 端对其他 server 节点的访问，即不会有 “ 单点故障 ” 问题。但是在 NFS 协议下，如果 mount 的那个节点出了问题， client 就无法访问这个逻辑卷了。
但不得不承认， NFS 协议已经非常通用了，所以，虽然这种方式性能和可靠性都不佳，但是使用起来是很方便的。
7.3. GlusterFS 的安装和部署
7.3.1. 安装 GlusterFS
安装 GlusterFS 之前需要安装一些基础依赖的包。由于 GlusterFS 的 client 端需要使用 FUSE （ file system in user space ）进行挂载逻辑卷，所以需要安装：
yum install fuse fuse-libs
安装 NFS 相关的 rpcbind 和 nfs-utils ：
yum install rpcbind nfs-utils
进入到已下载并解压好的 Glusterfs-3.2.5-src 下：
1) 运行 “./configure”
2) 运行 “make”
3) 运行 “make install”
安装完后运行 “glusterfs --version” ，查看是否安装成功。
7.3.2. 配置部署 GlusterFS
首先进行 server 端的配置，下面在 server1 （ 192.168.37.147 ）上进行：
1) 将多个 server 组成一个可信存储池（ trusted storage pool ）命令如下：
gluster peer probe 192.168.37.148 192.168.37.149
2) 在三个 server 上分别新建存储目录 /test1 、 /test2 、 /test3 ，然后建立逻辑卷，命令如下：
gluster volume create test-volume 192.168.37.147:/test1 192.168.37.148:/test2 192.168.37.149:/test3
3) 启动卷： gluster volume start test-volume
如下图，是新建的 test-volume 卷的信息：
图 7 ‑ 6
在 client 端（ 192.168.37.139 ）的配置，就是将卷 volume 以 NFS 的方式 mount 装载到某个目录节点上。
mount –t nfs –o vers=3 192.168.37.147:/test-volume /mnt/glusterfs-nfs
下面是通过 df 查看到的信息：
图 7 ‑ 7
这样就可以像本地的文件目录一样对 /mnt/glusterfs-nfs 进行文件操作了。
8. 总结
可靠性方面， GlusterFS 有比较大的优势。因为没有元数据服务器，整个系统就不容易出现整体崩溃的情况，也就容易在廉价机器上实现比较可靠稳定的系统。扩展性方面，如果集群内网络带宽充足，其理论上具有近乎线性的扩展能力。在 IO 性能上，在使用 Stripe 卷时可以达到不错的性能，但不太适合海量小文件的存储。总的来说，作为通用型的文件系统， GlusterFS 在中小规模的存储集群中是个不错的选择。
[1] Sanjay G., Howard G., and Shun-Tak L. The Google File System. 19th ACM Symposium on Operating Systems Principles [J], October, 2003.
[2] HDFS Architecture Guide. http://hadoop.apache.org
[3] Tom White. 《 Hadoop 权威指南》第二版 [M] ，清华大学出版社 2011
[4] 张佳 . 基于 NFS 的云存储网关的研究 [D]. 电子科技大学 2010
[5] 周轶男，王宇 Hadoop 文件系统性能分析，电子技术研发 [J]
[6] Gluster File System 3.2.5 Administration Guide Edition 1, http://www.gluster.org
[7] Gluster File System 3.2.5 Installation Guide Edition 1, http://www.gluster.org
[8] David K., Eric L., Tom L., Matthew L., Daniel L., Rina P. Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web STOC '97 Proceedings of the twenty-ninth annual ACM symposium on Theory of computing[J]: 654 – 663
[9] 刘爱贵 . http://blog.csdn.net/liuben
[10] 吴吉义 . 基于 DHT 的开放对等云存储服务系统研究 [D]. 浙江大学 2011
[11] 汪璐，石京燕，程耀东 . 基于 Lustre 的 BES 集群存储系统 [J]. 核电子学与探测技术 2010 第 30 卷第 12 期： 1574-1578
致谢
我很庆幸自己能够来到中山大学，并来到这个充满人文气息和鸟语花香的南校区。在这里我有幸可以认识很多为理想、为学术而奋斗的老师和同学们，他们指导着我，也感染着我，让我真的受益匪浅。在完成论文的这一刻，我想感谢在论文的写作的过程中帮助我的那些人们。
在这里我首先想感谢的是 UDSAFE 公司的刘爱贵先生。在论文的写作过程中他给了我很多的技术上的帮助，让我理清 GlusterFS 的关键原理，也让我认识到了计算机科学研究中 “ 动手实验 ” 的关键性。
此外还要感谢网络中心的老师们。他们给我提供了可部署的设备环境和技术支持，让我对 GlusterFS 的应用环境有了更多直观的感受和理解。
还有就是感谢吴红老师和谢博宇师兄。他们的细心指导和帮助，让我更好地完成了论文的写作。
最后感谢大学四年里与我邂逅的每个老师和朋友，让我顺利地走过了大学的四年。还有我的父母，感谢他们的辛勤劳作，给我提供了那么好的一个学习机会，让我一步一步顺利地走到了今天。
感谢大家！