集群文件系统-GlusterFS
2013-04-25 15:08:38 
阿炯
GlusterFS(GNU ClusterFile System)是一个集群的文件系统，支持 PB 级的数据量，它通过 RDMA 和 TCP/IP 方式将分布到不同服务器上的存储空间汇集成一个大的网络并行文件系统。主要由 Z RESEARCH 公司负责开发，十几名开发者，文档也比较齐全。采用C语言开发并在GPLv2或LGPLv2协议下授权。
旨在提供高性能、可扩展性和可靠性，适用于现代数据中心和云环境。它以横向扩展的方式设计，可以在多台服务器之间共享文件系统，为应用程序提供统一的文件存储服务。其核心理念是将多台普通的服务器组合成一个高性能的分布式存储系统。它采用了分布式哈希表来管理数据存储和访问，通过将文件划分为小块并存储在不同服务器上，实现了数据的分布式存储和负载均衡。这种分布式存储模式不仅提高了存储容量和性能，还提高了系统的可靠性，因为数据的冗余备份可以在服务器故障时保证数据的可用性。
GlusterFS 提供了简单而灵活的管理接口，使得管理员可以轻松地管理存储集群并对其进行扩展。它支持多种存储协议，包括标准的网络文件系统（NFS）、Server Message Block（SMB）和本地 POSIX 文件系统，使得应用程序可以通过不同的协议访问存储集群。
由于其高性能、可扩展性和易用性，它在大规模的数据存储和处理场景中被广泛应用，包括云计算、大数据分析、内容交付网络（CDN）等领域；是一个强大而灵活的分布式文件系统解决方案，可以帮助用户构建可靠的存储基础设施，满足不断增长的存储需求。
GlusterFS is an open source, distributed file system capable of scaling to several petabytes (actually, 72 brontobytes!) and handling thousands of clients. GlusterFS clusters together storage building blocks over Infiniband RDMA or TCP/IP interconnect, aggregating disk and memory resources and managing data in a single global namespace. GlusterFS is based on a stackable user space design and can deliver exceptional performance for diverse workloads.
用户可以在全局统一的命名空间中使用NFS/CIFS等标准协议来访问应用数据。GlusterFS使得用户可摆脱原有的独立、高成本的封闭存储系统，能够利用普通廉价的存储设备来部署可集中管理、横向扩展、虚拟化的存储池，存储容量可扩展至TB/PB级。总体架构如下：
主要特征如下：
扩展性和高性能
GlusterFS利用双重特性来提供几TB至数PB的高扩展存储解决方案。Scale-Out架构允许通过简单地增加资源来提高存储容量和性能，磁盘、计算和I/O资源都可以独立增加，支持10GbE和InfiniBand等高速网络互联。Gluster弹性哈希(Elastic Hash)解除了GlusterFS对元数据服务器的需求，消除了单点故障和性能瓶颈，真正实现了并行化数据访问。
高可用性
GlusterFS可以对文件进行自动复制，如镜像或多次复制，从而确保数据总是可以访问，甚至是在硬件故障的情况下也能正常访问。自我修复功能能够把数据恢复到正确的状态，而且修复是以增量的方式在后台执行，几乎不会产生性能负载。GlusterFS没有设计自己的私有数据文件格式，而是采用操作系统中主流标准的磁盘文件系统(如EXT3、ZFS)来存储文件，因此数据可以使用各种标准工具进行复制和访问。
全局统一命名空间
全局统一命名空间将磁盘和内存资源聚集成一个单一的虚拟存储池，对上层用户和应用屏蔽了底层的物理硬件。存储资源可以根据需要在虚拟存储池中进行弹性扩展，比如扩容或收缩。当存储虚拟机映像时，存储的虚拟映像文件没有数量限制，成千虚拟机均通过单一挂载点进行数据共享。虚拟机I/O可在命名空间内的所有服务器上自动进行负载均衡，消除了SAN环境中经常发生的访问热点和性能瓶颈问题。
弹性哈希算法
GlusterFS采用弹性哈希算法在存储池中定位数据，而不是采用集中式或分布式元数据服务器索引。在其他的Scale-Out存储系统中，元数据服务器通常会导致I/O性能瓶颈和单点故障问题。GlusterFS中，所有在Scale-Out存储配置中的存储系统都可以智能地定位任意数据分片，不需要查看索引或者向其他服务器查询。这种设计机制完全并行化了数据访问，实现了真正的线性性能扩展。
弹性卷管理
数据储存在逻辑卷中，逻辑卷可以从虚拟化的物理存储池进行独立逻辑划分而得到。存储服务器可以在线进行增加和移除，不会导致应用中断。逻辑卷可以在所有配置服务器中增长和缩减，可以在不同服务器迁移进行容量均衡，或者增加和移除系统，这些操作都可在线进行。文件系统配置更改也可以实时在线进行并应用，从而可以适应工作负载条件变化或在线性能调优。
基于标准协议
Gluster存储服务支持NFS, CIFS, HTTP, FTP以及Gluster原生协议，完全与POSIX标准兼容。现有应用程序不需要作任何修改或使用专用API，就可以对Gluster中的数据进行访问。这在公有云环境中部署Gluster时非常有用，Gluster对云服务提供商专用API进行抽象，然后提供标准POSIX接口。
其存储卷支持 7 种卷类型，即 分布式卷、条带卷、复制卷、分布式条带卷、分布式复制卷、条带复制卷、分布式条带复制卷，每种卷的特点如下：
分布式卷（Distributed Volume）：分布式卷根据hash算法将数据均匀地分布在不同服务器上，每个文件被分割成固定大小的块，然后分别存储在不同的服务器上。这种分布式存储方式可以提高存储容量和性能，因为数据可以并行地从多个服务器上读取和写入。适用于需要大容量和高性能存储的场景，如大规模数据存储、内容交付网络（CDN）等。缺点是文件没有冗余副本，一旦某台服务宕机，其中存储的数据无法读取。
复制卷（Replicated Volume）：复制卷在多个服务器之间复制数据，以提高数据的可靠性和容错能力。每个文件会被复制到多个服务器上，当某个服务器发生故障时，数据仍然可用。但是需要注意的是，由于数据被复制，这会增加存储开销。适用于对数据可靠性要求较高的场景，如数据备份、关键业务应用等。
条带化卷（Striped Volume）：条带化卷将文件分割成固定大小的块，并将这些块分别存储在不同的服务器上。这样可以提高读写性能，因为数据可以并行地从多个服务器上读取和写入。适用于需要高吞吐量和低延迟的场景，如大规模数据处理、科学计算等。
分布式复制卷（Distributed Replicated Volume）：分布式复制卷结合了分布式卷和复制卷的特点，既实现了数据的横向扩展和负载均衡，又提高了数据的可靠性和容错能力。每个文件会被分割成固定大小的块，并复制到多个服务器上。适用于需要兼顾数据容量、性能和可靠性的场景，如大规模数据存储和分析、虚拟化环境等。
分布式条带化卷（Distributed Striped Volume）：分布式条带化卷结合了分布式卷和条带化卷的特点，既实现了数据的横向扩展和负载均衡，又提高了读写性能。每个文件会被分割成固定大小的块，并分别存储在多个服务器上。适用于需要高性能和横向扩展的场景，如大规模并行计算、大数据处理等。
分布式复制条带化卷（Distributed Replicated Striped Volume）：结合了分布式卷、复制卷和条带化卷的特点，既实现了数据的横向扩展、可靠性和读写性能。每个文件会被分割成固定大小的块，并复制到多个服务器上，然后分别存储在不同的服务器上。适用于需要高性能、高可靠性和横向扩展的场景，如大规模数据处理和存储、分布式文件系统等。
分布式条带化复制卷（Distributed Striped Replicated Volume）：结合了分布式卷、条带化卷和复制卷的特点，既实现了数据的横向扩展、读写性能和可靠性。每个文件会被分割成固定大小的块，并分别存储在多个服务器上，然后在每个服务器上进行数据复制。适用于需要高性能、高可靠性和横向扩展的场景，如大规模并行计算、分布式存储系统等。
GlusterFS架构介绍1
外部架构
GlusterFS总体架构与组成部分如图2所示，它主要由存储服务器(BrickServer)、客户端以及NFS/Samba 存储网关组成。不难发现，GlusterFS 架构中没有元数据服务器组件，这是其最大的设计这点，对于提升整个系统的性能、可靠性和稳定性都有着决定性的意义。GlusterFS 支持TCP/IP 和InfiniBandRDMA 高速网络互联，客户端可通过原生Glusterfs 协议访问数据，其他没有运行GlusterFS客户端的终端可通过NFS/CIFS 标准协议通过存储网关访问数据。
内部架构
GlusterFS是模块化堆栈式的架构设计，如上图所示。模块称为Translator，是GlusterFS提供的一种强大机制，借助这种良好定义的接口可以高效简便地扩展文件系统的功能。
1.服务端与客户端模块接口是兼容的，同一个translator可同时在两边加载。
2.GlusterFS中所有的功能都是通过translator实现，如Cluster, Storage,Performance, Protocol, Features等。
3.重点是GlusterFSClient端。
数据访问流程
上图是GlusterFS数据访问的一个概要图：
1.首先是在客户端，用户通过glusterfs的mount point 来读写数据。
2.用户的这个操作被递交给本地linux系统的VFS来处理。
3.VFS将数据递交给FUSE内核文件系统，在启动glusterfs客户端以前，需要向系统注册一个实际的文件系统FUSE，如上图所示,该文件系统与ext3在同一个层次上面，ext3是对实际的磁片进行处理，而fuse文件系统则是将数据通过/dev/fuse这个设备文件递交给了glusterfs client端。所以，我们可以将fuse文件系统理解为一个代理。
4.数据被fuse递交给Glusterfs client 后，client对数据进行一些指定的处理(所谓的指定，是按照client配置文件来进行的一系列处理)
5.在glusterfsclient的处理末端，通过网路将数据递交给Glusterfs Server,并且将数据写入到服务器所控制的存储设备上
技术特点
GlusterFS在技术实现上与传统存储系统或现有其他分布式文件系统有显著不同之处，主要体现在如下几个方面：
完全软件实现(SoftwareOnly)
GlusterFS认为存储是软件问题，不能够把用户局限于使用特定的供应商或硬件配置来解决。GlusterFS采用开放式设计，广泛支持工业标准的存储、网络和计算机设备，而非与定制化的专用硬件设备捆绑。对于商业客户，GlusterFS可以以虚拟装置的形式交付，也可以与虚拟机容器打包，或者是公有云中部署的映像。开源社区中，GlusterFS被大量部署在基于廉价闲置硬件的各种操作系统上，构成集中统一的虚拟存储资源池。简言之，GlusterFS是开放的全软件实现，完全独立于硬件和操作系统。
完整的存储操作系统栈(CompleteStorage Operating System Stack)
GlusterFS不仅提供了一个分布式文件系统，而且还提供了许多其他重要的分布式功能，比如分布式内存管理、I/O调度、软RAID和自我修复等。GlusterFS汲取了微内核架构的经验教训，借鉴了GNU/Hurd操作系统的设计思想，在用户空间实现了完整的存储操作系统栈。
用户空间实现(User Space)
与传统的文件系统不同，GlusterFS在用户空间实现，这使得其安装和升级特别简便。另外，这也极大降低了普通用户基于源码修改GlusterFS的门槛，仅仅需要通用的C程序设计技能，而不需要特别的内核编程经验。
模块化堆栈式架构(ModularStackable Architecture)
GlusterFS采用模块化、堆栈式的架构，可通过灵活的配置支持高度定制化的应用环境，比如大文件存储、海量小文件存储、云存储、多传输协议应用等。每个功能以模块形式实现，然后以积木方式进行简单的组合，即可实现复杂的功能。比如，Replicate模块可实现RAID1，Stripe模块可实现RAID0，通过两者的组合可实现RAID10和RAID01，同时获得高性能和高可性。
原始数据格式存储(DataStored in Native Formats)
GlusterFS无元数据服务设计(NoMetadata with the Elastic Hash Algorithm)以原始数据格式(如EXT3、EXT4、XFS、ZFS)储存数据，并实现多种数据自动修复机制。因此系统极具弹性，即使离线情形下文件也可以通过其他标准工具进行访问。如果用户需要从GlusterFS中迁移数据，不需要作任何修改仍然可以完全使用这些数据。
对Scale-Out存储系统而言，最大的挑战之一就是记录数据逻辑与物理位置的映像关系，即数据元数据，可能还包括诸如属性和访问权限等信息。传统分布式存储系统使用集中式或分布式元数据服务来维护元数据，集中式元数据服务会导致单点故障和性能瓶颈问题，而分布式元数据服务存在性能负载和元数据同步一致性问题。特别是对于海量小文件的应用，元数据问题是个非常大的挑战。
独特地采用无元数据服务的设计，取而代之使用算法来定位文件，元数据和数据没有分离而是一起存储。集群中的所有存储系统服务器都可以智能地对文件数据分片进行定位，仅仅根据文件名和路径并运用算法即可，而不需要查询索引或者其他服务器。这使得数据访问完全并行化，从而实现真正的线性性能扩展。无元数据服务器极大提高了GlusterFS的性能、可靠性和稳定性。
一些设计与讨论
无元数据服务器vs元数据服务器
无元数据服务器设计的好处是没有单点故障和性能瓶颈问题，可提高系统扩展性、性能、可靠性和稳定性。对于海量小文件应用，这种设计能够有效解决元数据的难点问题。它的负面影响是，数据一致问题更加复杂，文件目录遍历操作效率低下，缺乏全局监控管理功能。同时也导致客户端承担了更多的职能，比如文件定位、名字空间缓存、逻辑卷视图维护等等，这些都增加了客户端的负载，占用相当的CPU 和内存。
用户空间vs内核空间
用户空间实现起来相对要简单许多，对开发者技能要求较低，运行相对安全。用户空间效率低，数据需要多次与内核空间交换，另外GlusterFS 借助FUSE 来实现标准文件系统接口，性能上又有所损耗。内核空间实现可以获得很高的数据吞吐量，缺点是实现和调试非常困难，程序出错经常会导致系统崩溃，安全性低。纵向扩展上，内核空间要优于用户空间，GlusterFS 有横向扩展能力来弥补。
堆栈式vs非堆栈式
这有点像操作系统的微内核设计与单一内核设计之争。GlusterFS 堆栈式设计思想源自GNU/Hurd 微内核操作系统，具有很强的系统扩展能力，系统设计实现复杂性降低很多，基本功能模块的堆栈式组合就可以实现强大的功能。查看GlusterFS卷配置文件我们可以发现，translator 功能树通常深达10层以上，一层一层进行调用，效率可见一斑。非堆栈式设计可看成类似Linux 的单一内核设计，系统调用通过中断实现，非常高效。后者的问题是系统核心臃肿，实现和扩展复杂，出现问题调试困难。
原始存储格式vs私有存储格式
GlusterFS使用原始格式存储文件或数据分片，可以直接使用各种标准的工具进行访问，数据互操作性好，迁移和数据管理非常方便。然而数据安全成了问题，因为数据是以平凡的方式保存的，接触数据的人可以直接复制和查看。这对很多应用显然是不能接受的，比如云存储系统，用户特别关心数据安全，这也是影响公有云存储发展的一个重要原因。私有存储格式可以保证数据的安全性，即使泄露也是不可知的。GlusterFS 要实现自己的私有格式，在设计实现和数据管理上相对复杂一些，也会对性能产生一定影响。
大文件 vs 小文件
GlusterFS适合大文件还是小文件存储?弹性哈希算法和Stripe 数据分布策略，移除了元数据依赖，优化了数据分布，提高数据访问并行性，能够大幅提高大文件存储的性能。对于小文件，无元数据服务设计解决了元数据的问题。但GlusterFS 并没有在I/O 方面作优化，在存储服务器底层文件系统上仍然是大量小文件，本地文件系统元数据访问是一个瓶颈，数据分布和并行性也无法充分发挥作用。因此它适合存储大文件，小文件性能较差，还存在很大优化空间。
可用性vs存储利用率
GlusterFS使用复制技术来提供数据高可用性，复制数量没有限制，自动修复功能基于复制来实现。可用性与存储利用率是一个矛盾体，可用性高存储利用率就低，反之亦然。采用复制技术，存储利用率为1/复制数，镜像是50%，三路复制则只有33%。其实，可以有方法来同时提高可用性和存储利用率，比如RAID5的利用率是(n-1)/n，RAID6是(n-2)/n，而纠删码技术可以提供更高的存储利用率。但鱼和熊掌不可得兼，它们都会对性能产生较大影响。
GlusterFS架构介绍2
GlusterFS系统是一个可扩展的网络文件系统，相比其他分布式文件系统，其具有高扩展性、高可用性、高性能、可横向扩展等特点，并且其没有元数据服务器的设计，让整个服务没有单点故障的隐患。它同时是一个横向扩展的分布式文件系统，就是把多台异构的存储服务器的存储空间整合起来给用户提供统一的命名空间。用户访问存储资源的方式有很多，可以通过NFS，SMB，HTTP协议等访问，还可以通过gluster本身提供的客户端访问。
GlusterFS是Scale-Out存储解决方案Gluster的核心，它是一个开源的分布式文件系统，具有强大的横向扩展能力，通过扩展能够支持数PB存储容量和处理数千客户端。其借助TCP/IP或InfiniBand RDMA网络将物理分布的存储资源聚集在一起，使用单一全局命名空间来管理数据。GlusterFS基于可堆叠的用户空间设计，可为各种不同的数据负载提供优异的性能。
GlusterFS 适合大文件还是小文件存储？弹性哈希算法和 Stripe 数据分布策略，移除了元数据依赖，优化了数据分布，提高数据访问并行性，能够大幅提高大文件存储的性能。对于小文件，无元数据服务设计解决了元数据的问题。但GlusterFS并没有在 I/O 方面作优化，在存储服务器底层文件系统上仍然是大量小文件，本地文件系统元数据访问是一个瓶颈，数据分布和并行性也无法充分发挥作用。因此，GlusterFS 适合存储大文件，小文件性能较差，还存在很大优化空间。
GlusterFS在企业中应用场景
理论和实践上分析，GlusterFS目前主要适用大文件存储场景，对于小文件尤其是海量小文件，存储效率和访问性能都表现不佳。海量小文件LOSF问题是工业界和学术界公认的难题，其作为通用的分布式文件系统，并没有对小文件作额外的优化措施，性能不好也是可以理解的。
Media：文档、图片、音频、视频
Shared storage：云存储、虚拟化存储、HPC(高性能计算)
Big data：日志文件、RFID(射频识别)数据
1)相关术语
Brick：GlusterFS中的存储单元，通过是一个受信存储池中的服务器的一个导出目录。可以通过主机名和目录名来标识，如'SERVER:EXPORT'。
Client：挂载了GlusterFS卷的设备。
GFID：GlusterFS卷中的每个文件或目录都有一个唯一的128位的数据相关联，其用于模拟inode
Namespace：每个Gluster卷都导出单个ns作为POSIX的挂载点。
Node：一个拥有若干brick的设备。
RDMA：远程直接内存访问，支持不通过双方的OS进行直接内存访问。
RRDNS：round robin DNS是一种通过DNS轮转返回不同的设备以进行负载均衡的方法
Self-heal：用于后台运行检测复本卷中文件和目录的不一致性并解决这些不一致。
Split-brain：脑裂
Volfile：Glusterfs进程的配置文件，通常位于/var/lib/glusterd/vols/volname
Volume：一组bricks的逻辑集合
a)Trusted Storage Pool
一堆存储节点的集合
通过一个节点“邀请”其他节点创建，这里叫probe
成员可以动态加入，动态删除
添加命令如下：
node1# gluster peer probe node2
删除命令如下：
node1# gluster peer detach node3
2)Bricks
Brick是一个节点和一个导出目录的集合，e.g. node1:/brick1
Brick是底层的RAID或磁盘经XFS或ext4文件系统格式化而来，所以继承了文件系统的限制
每个节点上的brick数是不限的
理想的状况是，一个集群的所有Brick大小都一样。
3)Volumes
Volume是brick的逻辑组合
创建时命名来识别
Volume是一个可挂载的目录
每个节点上的brick数是不变的,e.g.mount –t glusterfs somehost:test /mnt/gls
一个节点上的不同brick可以属于不同的卷
支持如下种类：
a) 分布式卷
b) 条带卷
c) 复制卷
d) 分布式复制卷
e) 条带复制卷
f) 分布式条带复制卷
3.1)分布式卷
文件分布存在不同的brick里
目录在每个brick里都可见
单个brick失效会带来数据丢失
无需额外元数据服务器
3.2)复制卷
同步复制所有的目录和文件
节点故障时保持数据高可用
事务性操作，保持一致性
有changelog
副本数任意定
3.3)分布式复制卷
最常见的一种模式
读操作可以做到负载均衡
3.4)条带卷
文件切分成一个个的chunk，存放于不同的brick上
只建议在非常大的文件时使用(比硬盘大小还大)
Brick故障会导致数据丢失，建议和复制卷同时使用
Chunks are files with holes – this helps in maintaining offset consistency.
2)无元数据设计
元数据是用来描述一个文件或给定区块在分布式文件系统中所在的位置，简而言之就是某个文件或某个区块存储的位置。传统分布式文件系统大都会设置元数据服务器或者功能相近的管理服务器，主要作用就是用来管理文件与数据区块之间的存储位置关系。相较其他分布式文件系统而言，GlusterFS并没有集中或者分布式的元数据的概念，取而代之的是弹性哈希算法。集群中的任何服务器和客户端都可以利用哈希算法、路径及文件名进行计算，就可以对数据进行定位，并执行读写访问操作。
这种设计带来的好处是极大的提高了扩展性，同时也提高了系统的性能和可靠性；另一显著的特点是如果给定确定的文件名，查找文件位置会非常快。但是如果要列出文件或者目录，性能会大幅下降，因为列出文件或者目录时，需要查询所在节点并对各节点中的信息进行聚合。此时有元数据服务的分布式文件系统的查询效率反而会提高许多。
3)服务的部署
在之前的版本中服务器间的关系是对等的，也就是说每个节点服务器都掌握了集群的配置信息，这样做的好处是每个节点度拥有节点的配置信息，高度自治，所有信息都可以在本地查询。每个节点的信息更新都会向其他节点通告，保证节点间信息的一致性。但如果集群规模较大，节点众多时，信息同步的效率就会下降，节点信息的非一致性概率就会大大提高。因此GlusterFS未来的版本有向集中式管理变化的趋势。
4)技术特点
GlusterFS在技术实现上与传统存储系统或现有其他分布式文件系统有显著不同之处，主要体现在如下几个方面。
a)完全软件实现(SoftwareOnly)
GlusterFS认为存储是软件问题，不能够把用户局限于使用特定的供应商或硬件配置来解决。它采用开放式设计，广泛支持工业标准的存储、网络和计算机设备，而非与定制化的专用硬件设备捆绑。对于商业客户，GlusterFS可以以虚拟装置的形式交付，也可以与虚拟机容器打包，或者是公有云中部署的映像。开源社区中，GlusterFS被大量部署在基于廉价闲置硬件的各种操作系统上，构成集中统一的虚拟存储资源池。简言之，GlusterFS是开放的全软件实现，完全独立于硬件和操作系统。
b)完整的存储操作系统栈(CompleteStorage Operating System Stack)
GlusterFS不仅提供了一个分布式文件系统，而且还提供了许多其他重要的分布式功能，比如分布式内存管理、I/O调度、软RAID和自我修复等。GlusterFS汲取了微内核架构的经验教训，借鉴了GNU/Hurd操作系统的设计思想，在用户空间实现了完整的存储操作系统栈。
c)用户空间实现(User Space)
与传统的文件系统不同，GlusterFS在用户空间实现，这使得其安装和升级特别简便。另外，这也极大降低了普通用户基于源码修改GlusterFS的门槛，仅仅需要通用的C程序设计技能，而不需要特别的内核编程经验。
d)模块化堆栈式架构(ModularStackable Architecture)
GlusterFS采用模块化、堆栈式的架构，可通过灵活的配置支持高度定制化的应用环境，比如大文件存储、海量小文件存储、云存储、多传输协议应用等。每个功能以模块形式实现，然后以积木方式进行简单的组合，即可实现复杂的功能。比如，Replicate模块可实现RAID1，Stripe模块可实现RAID0，通过两者的组合可实现RAID10和RAID01，同时获得高性能和高可性。
e)原始数据格式存储(DataStored in Native Formats)
GlusterFS无元数据服务设计(NoMetadata with the Elastic Hash Algorithm)以原始数据格式(如EXT3、EXT4、XFS、ZFS)储存数据，并实现多种数据自动修复机制。因此系统极具弹性，即使离线情形下文件也可以通过其他标准工具进行访问。如果用户需要从GlusterFS中迁移数据，不需要作任何修改仍然可以完全使用这些数据。
对Scale-Out存储系统而言，最大的挑战之一就是记录数据逻辑与物理位置的映像关系，即数据元数据，可能还包括诸如属性和访问权限等信息。传统分布式存储系统使用集中式或分布式元数据服务来维护元数据，集中式元数据服务会导致单点故障和性能瓶颈问题，而分布式元数据服务存在性能负载和元数据同步一致性问题。特别是对于海量小文件的应用，元数据问题是个非常大的挑战。
GlusterFS独特地采用无元数据服务的设计，取而代之使用算法来定位文件，元数据和数据没有分离而是一起存储。集群中的所有存储系统服务器都可以智能地对文件数据分片进行定位，仅仅根据文件名和路径并运用算法即可，而不需要查询索引或者其他服务器。这使得数据访问完全并行化，从而实现真正的线性性能扩展。无元数据服务器极大提高了GlusterFS的性能、可靠性和稳定性。
5)整体工作流程(即数据访问流程)
a)首先是在客户端， 用户通过glusterfs的mount point 来读写数据， 对于用户来说，集群系统的存在对用户是完全透明的，用户感觉不到是操作本地系统还是远端的集群系统。
b)用户的这个操作被递交给 本地linux系统的VFS来处理。
c)VFS 将数据递交给FUSE 内核文件系统:在启动 glusterfs 客户端以前，需要想系统注册一个实际的文件系统FUSE,如上图所示，该文件系统与ext3在同一个层次上面， ext3 是对实际的磁盘进行处理， 而fuse 文件系统则是将数据通过/dev/fuse 这个设备文件递交给了glusterfs client端。所以， 我们可以将 fuse文件系统理解为一个代理。
d)数据被fuse 递交给Glusterfs client 后， client 对数据进行一些指定的处理(所谓的指定，是按照client 配置文件据来进行的一系列处理， 我们在启动glusterfs client 时需要指定这个文件。
e)在glusterfs client的处理末端，通过网络将数据递交给 Glusterfs Server，并且将数据写入到服务器所控制的存储设备上。
这样整个数据流的处理就完成了。
GlusterFS客户端访问流程
当客户端访问GlusterFS存储时，首先程序通过访问挂载点的形式读写数据，对于用户和程序而言，集群文件系统是透明的，用户和程序根本感觉不到文件系统是本地还是在远程服务器上。读写操作将会被交给VFS(Virtual File System)来处理，VFS会将请求交给FUSE内核模块，而FUSE又会通过设备/dev/fuse将数据交给GlusterFS Client。最后经过GlusterFS Client的计算，并最终经过网络将请求或数据发送到GlusterFS Server上。
6)集群模式
GlusterFS分布式存储集群的模式只数据在集群中的存放结构，类似于磁盘阵列中的级别。
a)分布式卷(Distributed Volume)，默认模式，DHT又称哈希卷，近似于RAID0，文件没有分片，文件根据hash算法写入各个节点的硬盘上，优点是容量大，缺点是没冗余。
# gluster volume create test-volume server1:/exp1 server2:/exp2 server3:/exp3 server4:/exp4
b)复制卷(Replicated Volume)，复制模式，AFR相当于raid1，复制的份数，决定集群的大小，通常与分布式卷或者条带卷组合使用，解决前两种存储卷的冗余缺陷。缺点是磁盘利用率低。复本卷在创建时可指定复本的数量，通常为2或者3，复本在存储时会在卷的不同brick上，因此有几个复本就必须提供至少多个brick，当其中一台服务器失效后，可以从另一台服务器读取数据，因此复制GlusterFS卷提高了数据可靠性的同事，还提供了数据冗余的功能。
# gluster volume create test-volume replica 2 transport tcp server1:/exp1 server2:/exp2
避免脑裂，加入仲裁：
# gluster volume create replica 3 arbiter 1 host1:brick1 host2:brick2 host3:brick3
c)分布式复制卷(Distributed Replicated Volume)，最少需要4台服务器。
# gluster volume create test-volume replica 2 transport tcp server1:/exp1 server2:/exp2 server3:/exp3 server4:/exp4
d)条带卷(Striped Volume)
相当于raid0，文件是分片均匀写在各个节点的硬盘上的，优点是分布式读写，性能整体较好。缺点是没冗余，分片随机读写可能会导致硬盘IOPS饱和。
# gluster volume create test-volume stripe 2 transport tcp server1:/exp1 server2:/exp2
e)分布式条带卷(Distributed Striped Volume)，最少需要4台服务器。
当单个文件的体型十分巨大，客户端数量更多时，条带卷已经无法满足需求，此时将分布式与条带化结合起来是一个比较好的选择。其性能与服务器数量有关。
# gluster volume create test-volume stripe 4 transport tcp server1:/exp1 server2:/exp2 server3:/exp3 server4:/exp4 server5:/exp5 server6:/exp6 server7:/exp7 server8:/exp8
7)存储特点
a)扩展性和高性能
GlusterFS利用双重特性来提供几TB至数PB的高扩展存储解决方案。Scale-Out架构允许通过简单地增加资源来提高存储容量和性能，磁盘、计算和I/O资源都可以独立增加，支持10GbE和InfiniBand等高速网络互联。Gluster弹性哈希(Elastic Hash)解除了GlusterFS对元数据服务器的需求，消除了单点故障和性能瓶颈，真正实现了并行化数据访问。
b)高可用性
GlusterFS可以对文件进行自动复制，如镜像或多次复制，从而确保数据总是可以访问，甚至是在硬件故障的情况下也能正常访问。自我修复功能能够把数据恢复到正确的状态，而且修复是以增量的方式在后台执行，几乎不会产生性能负载。GlusterFS没有设计自己的私有数据文件格式，而是采用操作系统中主流标准的磁盘文件系统(如EXT3、ZFS)来存储文件，因此数据可以使用各种标准工具进行复制和访问。
c)全局统一命名空间
全局统一命名空间将磁盘和内存资源聚集成一个单一的虚拟存储池，对上层用户和应用屏蔽了底层的物理硬件。存储资源可以根据需要在虚拟存储池中进行弹性扩展，比如扩容或收缩。当存储虚拟机映像时，存储的虚拟映像文件没有数量限制，成千虚拟机均通过单一挂载点进行数据共享。虚拟机I/O可在命名空间内的所有服务器上自动进行负载均衡，消除了SAN环境中经常发生的访问热点和性能瓶颈问题。
d)弹性哈希算法
GlusterFS采用弹性哈希算法在存储池中定位数据，而不是采用集中式或分布式元数据服务器索引。在其他的Scale-Out存储系统中，元数据服务器通常会导致I/O性能瓶颈和单点故障问题。GlusterFS中，所有在Scale-Out存储配置中的存储系统都可以智能地定位任意数据分片，不需要查看索引或者向其他服务器查询。这种设计机制完全并行化了数据访问，实现了真正的线性性能扩展。
e)弹性卷管理
数据储存在逻辑卷中，逻辑卷可以从虚拟化的物理存储池进行独立逻辑划分而得到。存储服务器可以在线进行增加和移除，不会导致应用中断。逻辑卷可以在所有配置服务器中增长和缩减，可以在不同服务器迁移进行容量均衡，或者增加和移除系统，这些操作都可在线进行。文件系统配置更改也可以实时在线进行并应用，从而可以适应工作负载条件变化或在线性能调优。
f)基于标准协议
Gluster存储服务支持NFS,CIFS,HTTP,FTP以及Gluster原生协议，完全与POSIX标准兼容。现有应用程序不需要作任何修改或使用专用API，就可以对Gluster中的数据进行访问。这在公有云环境中部署Gluster时非常有用，Gluster对云服务提供商专用API进行抽象，然后提供标准POSIX接口。
8)功能简介
8.1)基本管理功能
GlusterFS服务管理：启动、停止、重启服务；
TrustedStorage Pools管理：增加或删除peer；
Volume管理：增加卷、启动卷、停止卷；
上述这些基本的管理功能不再做介绍。
8.2)TuningVolume Options(调整卷配置)
GlustreFS提供了45项配置用来调整Volume属性，包括端口、cache、安全、存储空间、自愈、日志、扩展性、通讯协议、性能等配置项。用户可以通过gluster volume info命令来查看自定义配置项。
8.3)ConfiguringTransport Types for Volume(配置传输类型)
创建卷的时候，可以选择client与brick的通讯协议。
也可以通过"gluster volume set volnameconfig.transport tcp,rdma OR tcp OR rdma"命令更改通讯协议，需要注意的在更改通讯协议前，必须先停止volume。
默认情况是TCP，根据部署场景可选择RDMA或RDMA+TCP组合，而选择RDMA协议需要相应硬件的支持。
8.4)ExpandingVolumes(扩容)
GlusterFS集群的扩容就是通过增加volume来实现，通过"glustervolume add-brick"命令增加卷。
注意，扩容复制卷的时候，必须同时增加卷的数量是replica的倍数。例如replica 2的集群扩容，需要同时增加2个volume；replica3的集群扩容，需要同时增加3个volume。
8.5)ShrinkingVolumes(缩容)
集群缩减存储空间通过删除卷的“glustervolume remove-brick”命令实现，删除卷的命令执行后，GlustreFS会启动数据迁移，若迁移的数据较大，迁移过程将耗时较长，可能通过命令观察迁移状态。
8.6)Replacefaulty brick(更换坏块)
用好的brick替换故障的brick。
使用方法如下："glustervolume replace-brick test-volume server3:/exp3 server5:/exp5 commit force"，将test-volume卷中的server3:/exp3故障brick替换掉。
8.7)RebalancingVolumes(负载调整)
扩容或缩容卷，集群中可能会出现不同卷的存储利用率较大的不均衡的现象。通过Rebalancing机制，在后台以人工方式来执行负载平滑，将进行文件移动和重新分布，此后所有存储服务器都会均会被调度。为了便于控制管理，rebalance操作分为两个阶段进行实际执行，即FixLayout和MigrateData。
a)FixLayout：修复layout以使得新旧目录下新建文件可以在新增节点上分布上。
b)MigrateData：新增或缩减节点后，在卷下所有节点上进行容量负载平滑。为了提高rebalance效率，通常在执行此操作前先执行FixLayout。
8.8)TriggeringSelf-Heal on Replicate(文件自愈)
在复制卷中，若出现复本间文件不同步的情况，系统每十分钟会自动启动Self-Heal。
也可以主动执行"glustervolume heal"命令触发Self-Heal，通过"gluster volume heal info"可以查看需要heal的文件列表。
在healing过程中，可以通过"gluster volume heal info healed"查看已修复文件的列表；
通过"gluster volume heal info failed"查看修复失败的文件列表。
8.9)Geo-replication(异地备份)
异地备份可以提供数据的灾难恢复。以本地集群作为主存储，异地存储为备份，通过局域网或互联网持续、增量、异步备份数据。
使用"gluster volume geo-replication"相关的命令实现异地备份创建管理。
8.10)Quota(限额管理)
GlusterFS提供目录或卷的存储使用空间的限制设置功能。通过目录限额可以实现对用户按存储容量计费的功能。
使用方法为："gluster volume quota"
8.11)VolumeSnapshots(卷快照)
卷快照功能用于卷的备份和恢复，在非复制卷的应用场景，通过卷快照实现数据冗余备份。
8.12)MonitoringWorkload(性能监控)
监控每一个brick文件操作的IO性能，主要监控打开fd的数量和最大fd数量、最大读文件调用数、最大写文件调用数、最大打开目录调用数、brick读性能、brcik写性能等。
使用方法："gluster volume profile"
GlusterFS的缺点
GlusterFS是一个开源的分布式文件系统，它的历史可以追溯到2006年，最初的目标是代替Lustre和GPFS分布式文件系统。经过八年左右的蓬勃发展，GlusterFS目前在开源社区活跃度非常之高，这个后起之秀已经俨然与Lustre、MooseFS、CEPH并列成为四大开源分布式文件系统。由于GlusterFS新颖和KISS(KeepIt as Stupid and Simple)的系统架构，使其在扩展性、可靠性、性能、维护性等方面具有独特的优势，目前开源社区风头有压倒之势，国内外有大量用户在研究、测试和部署应用。
当然，GlusterFS不是一个完美的分布式文件系统，这个系统自身也有许多不足之处，包括众所周知的元数据性能和小文件问题。没有普遍适用各种应用场景的分布式文件系统，通用的意思就是通通不能用，四大开源系统不例外，所有商业产品也不例外。每个分布式文件系统都有它适用的应用场景，适合的才是最好的。这一次我们反其道而行之，不再谈GlusterFS的各种优点，而是深入谈谈GlusterFS当下的问题和不足，从而更加深入地理解GlusterFS系统，期望帮助大家进行正确的系统选型决策和规避应用中的问题。同时，这些问题也是GlusterFS研究和研发的很好切入点。
1)元数据性能
GlusterFS使用弹性哈希算法代替传统分布式文件系统中的集中或分布式元数据服务，这个是GlusterFS最核心的思想，从而获得了接近线性的高扩展性，同时也提高了系统性能和可靠性。GlusterFS使用算法进行数据定位，集群中的任何服务器和客户端只需根据路径和文件名就可以对数据进行定位和读写访问，文件定位可独立并行化进行。
这种算法的特点是，给定确定的文件名，查找和定位会非常快。但是，如果事先不知道文件名，要列出文件目录(ls或ls -l)，性能就会大幅下降。对于Distributed哈希卷，文件通过HASH算法分散到集群节点上，每个节点上的命名空间均不重叠，所有集群共同构成完整的命名空间，访问时使用HASH算法进行查找定位。列文件目录时，需要查询所有节点，并对文件目录信息及属性进行聚合。这时，哈希算法根本发挥不上作用，相对于有中心的元数据服务，查询效率要差很多。
从接触的一些用户和实践来看，当集群规模变大以及文件数量达到百万级别时，ls文件目录和rm删除文件目录这两个典型元数据操作就会变得非常慢，创建和删除100万个空文件可能会花上15分钟。如何解决这个问题呢？我们建议合理组织文件目录，目录层次不要太深，单个目录下文件数量不要过多；增大服务器内存配置，并且增大GlusterFS目录缓存参数；网络配置方面，建议采用万兆或者InfiniBand。从研发角度看，可以考虑优化方法提升元数据性能。比如，可以构建全局统一的分布式元数据缓存系统；也可以将元数据与数据重新分离，每个节点上的元数据采用全内存或数据库设计，并采用SSD进行元数据持久化。
2)小文件问题
理论和实践上分析，GlusterFS目前主要适用大文件存储场景，对于小文件尤其是海量小文件，存储效率和访问性能都表现不佳。海量小文件LOSF问题是工业界和学术界公认的难题，GlusterFS作为通用的分布式文件系统，并没有对小文件作额外的优化措施，性能不好也是可以理解的。
对于LOSF而言，IOPS/OPS是关键性能衡量指标，造成性能和存储效率低下的主要原因包括元数据管理、数据布局和I/O管理、Cache管理、网络开销等方面。从理论分析以及LOSF优化实践来看，优化应该从元数据管理、缓存机制、合并小文件等方面展开，而且优化是一个系统工程，结合硬件、软件，从多个层面同时着手，优化效果会更显著。GlusterFS小文件优化可以考虑这些方法，这里不再赘述，关于小文件问题请参考“海量小文件问题综述”一文。
3)集群管理模式
GlusterFS集群采用全对等式架构，每个节点在集群中的地位是完全对等的，集群配置信息和卷配置信息在所有节点之间实时同步。这种架构的优点是，每个节点都拥有整个集群的配置信息，具有高度的独立自治性，信息可以本地查询。但同时带来的问题的，一旦配置信息发生变化，信息需要实时同步到其他所有节点，保证配置信息一致性，否则GlusterFS就无法正常工作。在集群规模较大时，不同节点并发修改配置时，这个问题表现尤为突出。因为这个配置信息同步模型是网状的，大规模集群不仅信息同步效率差，而且出现数据不一致的概率会增加。
实际上，大规模集群管理应该是采用集中式管理更好，不仅管理简单，效率也高。可能有人会认为集中式集群管理与GlusterFS的无中心架构不协调，其实不然。GlusterFS 2.0以前，主要通过静态配置文件来对集群进行配置管理，没有Glusterd集群管理服务，这说明glusterd并不是GlusterFS不可或缺的组成部分，它们之间是松耦合关系，可以用其他的方式来替换。从其他分布式系统管理实践来看，也都是采用集群式管理居多，这也算一个佐证，GlusterFS 4.0开发计划也表现有向集中式管理转变的趋势。
4)容量负载均衡
GlusterFS的哈希分布是以目录为基本单位的，文件的父目录利用扩展属性记录了子卷映射信息，子文件在父目录所属存储服务器中进行分布。由于文件目录事先保存了分布信息，因此新增节点不会影响现有文件存储分布，它将从此后的新创建目录开始参与存储分布调度。这种设计，新增节点不需要移动任何文件，但是负载均衡没有平滑处理，老节点负载较重。GlusterFS实现了容量负载均衡功能，可以对已经存在的目录文件进行Rebalance，使得早先创建的老目录可以在新增存储节点上分布，并可对现有文件数据进行迁移实现容量负载均衡。
GlusterFS目前的容量负载均衡存在一些问题。由于采用Hash算法进行数据分布，容量负载均衡需要对所有数据重新进行计算并分配存储节点，对于那些不需要迁移的数据来说，这个计算是多余的。Hash分布具有随机性和均匀性的特点，数据重新分布之后，老节点会有大量数据迁入和迁出，这个多出了很多数据迁移量。相对于有中心的架构，可谓节点一变而动全身，增加和删除节点增加了大量数据迁移工作。GlusterFS应该优化数据分布，最小化容量负载均衡数据迁移。此外，GlusterFS容量负载均衡也没有很好考虑执行的自动化、智能化和并行化。目前，GlusterFS在增加和删除节点上，需要手工执行负载均衡，也没有考虑当前系统的负载情况，可能影响正常的业务访问。GlusterFS的容量负载均衡是通过在当前执行节点上挂载卷，然后进行文件复制、删除和改名操作实现的，没有在所有集群节点上并发进行，负载均衡性能差。
5)数据分布问题
Glusterfs主要有三种基本的集群模式，即分布式集群(Distributed cluster)、条带集群(Stripe cluster)、复制集群(Replica cluster)。这三种基本集群还可以采用类似堆积木的方式，构成更加复杂的复合集群。三种基本集群各由一个translator来实现，分别由自己独立的命名空间。对于分布式集群，文件通过HASH算法分散到集群节点上，访问时使用HASH算法进行查找定位。复制集群类似RAID1，所有节点数据完全相同，访问时可以选择任意个节点。条带集群与RAID0相似，文件被分成数据块以Round Robin方式分布到所有节点上，访问时根据位置信息确定节点。
哈希分布可以保证数据分布式的均衡性，但前提是文件数量要足够多，当文件数量较少时，难以保证分布的均衡性，导致节点之间负载不均衡。这个对有中心的分布式系统是很容易做到的，但GlusteFS缺乏集中式的调度，实现起来比较复杂。复制卷包含多个副本，对于读请求可以实现负载均衡，但实际上负载大多集中在第一个副本上，其他副本负载很轻，这个是实现上问题，与理论不太相符。条带卷原本是实现更高性能和超大文件，但在性能方面的表现太差强人意，远远不如哈希卷和复制卷，没有被好好实现，连官方都不推荐应用。
6)数据可用性问题
副本(Replication)就是对原始数据的完全拷贝。通过为系统中的文件增加各种不同形式的副本，保存冗余的文件数据，可以十分有效地提高文件的可用性，避免在地理上广泛分布的系统节点由网络断开或机器故障等动态不可测因素而引起的数据丢失或不可获取。GlusterFS主要使用复制来提供数据的高可用性，通过的集群模式有复制卷和哈希复制卷两种模式。复制卷是文件级RAID1，具有容错能力，数据同步写到多个brick上，每个副本都可以响应读请求。当有副本节点发生故障，其他副本节点仍然正常提供读写服务，故障节点恢复后通过自修复服务或同步访问时自动进行数据同步。
一般而言，副本数量越多，文件的可靠性就越高，但是如果为所有文件都保存较多的副本数量，存储利用率低(为副本数量分之一)，并增加文件管理的复杂度。目前GlusterFS社区正在研发纠删码功能，通过冗余编码提高存储可用性，并且具备较低的空间复杂度和数据冗余度，存储利用率高。
GlusterFS的复制卷以brick为单位进行镜像，这个模式不太灵活，文件的复制关系不能动态调整，在已经有副本发生故障的情况下会一定程度上降低系统的可用性。对于有元数据服务的分布式系统，复制关系可以是以文件为单位的，文件的不同副本动态分布在多个存储节点上；当有副本发生故障，可以重新选择一个存储节点生成一个新副本，从而保证副本数量，保证可用性。另外，还可以实现不同文件目录配置不同的副本数量，热点文件的动态迁移。对于无中心的GlusterFS系统来说，这些看起来理所当然的功能，实现起来都是要大费周折的。不过值得一提的是，4.0开发计划已经在考虑这方面的副本特性。
7)数据安全问题
GlusterFS以原始数据格式(如EXT4、XFS、ZFS)存储数据，并实现多种数据自动修复机制。因此，系统极具弹性，即使离线情形下文件也可以通过其他标准工具进行访问。如果用户需要从GlusterFS中迁移数据，不需要作任何修改仍然可以完全使用这些数据。
然而，数据安全成了问题，因为数据是以平凡的方式保存的，接触数据的人可以直接复制和查看。这对很多应用显然是不能接受的，比如云存储系统，用户特别关心数据安全。私有存储格式可以保证数据的安全性，即使泄露也是不可知的。GlusterFS要实现自己的私有格式，在设计实现和数据管理上相对复杂一些，也会对性能产生一定影响。
GlusterFS在访问文件目录时根据扩展属性判断副本是否一致，这个进行数据自动修复的前提条件。节点发生正常的故障，以及从挂载点进行正常的操作，这些情况下发生的数据不一致，都是可以判断和自动修复的。但是，如果直接从节点系统底层对原始数据进行修改或者破坏，GlusterFS大多情况下是无法判断的，因为数据本身也没有校验，数据一致性无法保证。
8)Cache一致性
为了简化Cache一致性，GlusterFS没有引入客户端写Cache，而采用了客户端只读Cache。GlusterFS采用简单的弱一致性，数据缓存的更新规则是根据设置的失效时间进行重置的。对于缓存的数据，客户端周期性询问服务器，查询文件最后被修改的时间，如果本地缓存的数据早于该时间，则让缓存数据失效，下次读取数据时就去服务器获取最新的数据。
GlusterFS客户端读Cache刷新的时间缺省是1秒，可以通过重新设置卷参数Performance.cache-refresh-timeout进行调整。这意味着，如果同时有多个用户在读写一个文件，一个用户更新了数据，另一个用户在Cache刷新周期到来前可能读到非最新的数据，即无法保证数据的强一致性。因此实际应用时需要在性能和数据一致性之间进行折中，如果需要更高的数据一致性，就得调小缓存刷新周期，甚至禁用读缓存；反之可以把缓存周期调大一点，以提升读性能。
术语表：
Xlator=translator:glusterfs 模块的代名词
Brick :存储目录是Glusterfs 的基本存储单元，由可信存储池中服务器上对外
输出的目录表示。存储目录的格式由服务器和目录的绝对路径构成，具体如下：
SERVER:EXPORT.例如：myhostname:/exports/myexportdir/
Volume:卷是存储目录的逻辑组合。大部分gluster 管理操作是在卷上进行的。
Metadata:元数据关于数据的数据，用于描述文件、目录等的相关信息。
FUSE=Filesystem inUserspace:是一个内核模块，允许用户创建自己的文件系统无需修改内核代码。
Glusterd : Glusterfs 后台进程，运行在所有Glusterfs 节点上。
DistributeVolume: 分布式卷
ReplicateVolume: 副本卷
StripeVolume: 条带卷
DistributeReplicate Volume: 分布式副本卷
DHT=Distribute HashTable
AFR=Automatic FileReplication
SAN = Storage AreaNetwork：存储区域网络是一种高速网络或子网络，提供在计算机与存储之间的数据传输。
NAS = Network-attachedstorage：网络附属存储是一种将分布、独立的数据整合为大型、集中化管理的数据中心，以便于对不同主机和应用服务器进行访问的技术。
RPC =Remote ProcedureCall: 远程过程调用
XDR =eXtern DataRepresentation: RPC 传递数据的格式
CLI=Command LineInterface 控制台
argp=Argument Parser
UUID=University UnqiueIdentifier
SVC =service
CLNT =client
MGMT=management
cbks = Call Backs
ctx = context
lk = lock
attr = attribute
txn = transaction
rb = replace brick
worm = write once , readmany
系统配额：
1、开启/关闭系统配额
gluster volume quota VOLNAME enable/disable
2、设置(重置)目录配额
gluster volume quota VOLNAME limit-usage/imglimit-value
gluster volume quota img limit-usage/quota10GB
设置 img 卷下的 quota 子目录的限额为10GB。这个目录是以系统挂载目录为根目录”/”，所以 /quota 即客户端挂载目录下的子目录quota。
3、配额查看
gluster volume quota VOLNAME list
gluster volume quota VOLNAME list
可以使用如上两个命令进行系统卷的配额查看，第一个命令查看目的卷的所有配额设置，
第二个命令则是执行目录进行查看。可以显示配额大小及当前使用容量，若无使用容量(最小0KB)则说明设置的目录可能是错误的(不存在)。
地域复制：
glustervolumegeo-replicationMASTERSLAVEstart/status/stop
//地域复制是系统提供的灾备功能，能够将系统的全部数据进行异步的增量备份到另外的磁盘中。
glustervolumegeo-replicationimg192.168.10.8:/data1/brick1start
如上，开始执行将 img 卷的所有内容备份 到10.8 下的 /data1/brick1 中的task，需要注意的是，这个备份目标不能是系统中的Brick。
平衡卷：
平衡布局是很有必要的，因为布局结构是静态的，当新的bricks 加入现有卷，新创建的文件会分布到旧的bricks 中，所以需要平衡布局结构，使新加入的bricks 生效。布局平衡只是使新布局生效，并不会在新的布局移动老的数据，如果你想在新布局生效后，重新平衡卷中的数据，还需要对卷中的数据进行平衡。
当扩展或者缩小卷之后，需要重新在服务器直接重新平衡一下数据，重新平衡的操作被分。
为两个步骤：
1)、Fix Layout
修改扩展或者缩小后的布局，以确保文件可以存储到新增加的节点中。
2)、Migrate Data
重新平衡数据在新加入bricks 节点之后。
* Fix Layout and Migrate Data
先重新修改布局然后移动现有的数据(重新平衡)
#glustervolumerebalanceVOLNAMEfix-layoutstart
#glustervolumerebalanceVOLNAMEmigrate-datastart
也可以两步合一步同时操作
#gluster volume rebalance VOLNAME start
#gluster volume rebalance VOLNAME status //可以在在平衡过程中查看平衡信息。
#glusterv olume rebalance VOLNAME stop //也可以暂停平衡，再次启动平衡的时候会从上次暂停的地方继续开始平衡。
I/O 信息查看：
Profile Command 提供接口查看一个卷中的每一个brick 的IO 信息
#gluster volume profile VOLNAME start //启动profiling，之后则可以进行IO信息查看
#gluster volume profile VOLNAME info //查看IO信息，可以查看到每一个Brick的IO信息
#gluster volume profile VOLNAME stop //查看结束之后关闭profiling功能
Top监控：
Top command 允许你查看bricks 的性能例如：read, write, fileopen calls, file read calls, file,write calls,directory open calls, and directory real calls
所有的查看都可以设置top 数，默认100
#glustervolumetopVOLNAMEopen[brickBRICK-NAME][list-cntcnt]//查看打开的fd
#glustervolumetopVOLNAMEread[brickBRICK-NAME][list-cntcnt]//查看调用次数最多的读调用
#glustervolumetopVOLNAMEwrite[brickBRICK-NAME][list-cntcnt]//查看调用次数最多的写调用
#glustervolumetopVOLNAMEopendir[brickBRICK-NAME][list-cntcnt]//查看次数最多的目录调用
#glustervolumetopVOLNAMEreaddir[brickBRICK-NAME][list-cntcnt]//查看次数最多的目录调用
#glustervolumetopVOLNAMEread-perf[bsblk-sizecountcount][brickBRICK-NAME][list-cntcnt]//查看每个Brick的读性能
#glustervolumetopVOLNAMEwrite-perf[bsblk-sizecountcount][brickBRICK-NAME][list-cntcnt]//查看每个Brick的写性能
性能优化配置选项：
glustervolumesetarch-imgcluster.min-free-disk默认是10%磁盘剩余告警
glustervolumesetarch-imgcluster.min-free-inodes默认是5%inodes剩余告警
glustervolumesetimgperformance.read-ahead-page-count8默认4，预读取的数量
glustervolumesetimgperformance.io-thread-count16默认16io操作的最大线程
glustervolumesetarch-imgnetwork.ping-timeout10默认42s
glustervolumesetarch-imgperformance.cache-size2GB默认128M或32MB，
glustervolumesetarch-imgcluster.self-heal-daemonon开启目录索引的自动愈合进程
glustervolumesetarch-imgcluster.heal-timeout300自动愈合的检测间隔，默认为600s#3.4.2版本才有
glustervolumesetarch-imgperformance.write-behind-window-size256MB#默认是1M能提高写性能单个文件后写缓冲区的大小默认1M
其它类型卷的使用及操作命令
分布式复制卷，机器数最少需要replica 的整数倍，如果指定 replica 2，则最少也需要 4 台机器：
gluster volume create volumeName replica 2 transport tcp node1:/data node2:/data node3:/data node4:/data
条带卷，将文件切割成数据块，分别存储到 stripe x 个节点中。
gluster volume create volumeName stripe 2 transport tcp node1:/data node2:/data
分布式条带卷，机器数最少需要stripe 的整数倍，如果指定 stripe 2 ，则最少需要 4 台机器：
gluster volume create volumeName stripe 2 transport tcp node1:/data node2:/data node3:/data node4:/data
条带复制卷，机器数最少需要stripe+ replica台 ，指定 stripe 2 ，replica 2，则需要 4 台机器：
gluster volume create volumeName stripe 2 replica 2 transport tcp node1:/data node2:/data node3:/data node4:/data
分布式条带复制卷，机器数需要是stripe+ replica 的整数倍，如果指定 stripe 2 ，replica 2，的话，就最少需要 8 台机器：
gluster volume create volumeName stripe 2 replica 2 transport tcp node1:/data node2:/data node3:/data node4:/data node5:/data node6:/data node7:/data node8:/data
查看所有卷：
gluster volume list
停止某个卷：
gluster volume stop volumeName
删除某个卷：
gluster volume delete volumeName
需要同时删除该卷下的 .glusterfs/ .trashcan/ 目录。
移除某个主机节点：
gluster peer detach node3
设置某个卷的 ip 访问限制：
gluster volume set volumeName auth.allow 10.6.0.*,10.7.0.*
为某个已经存在的卷添加节点，如果是复制卷或者条带卷，每次添加的 Brick 数必须是 replica 或者 stripe 的整数倍：
gluster volume add-brick volumeName node4:/data
为某个已经存在的卷移除节点，注意移除后剩余的机器需要能保证大于等于最小机器数：
gluster volume remove-brick volumeName node4:/data
参数调优
1.定磁盘使用配额
开启配额：
gluster volume quota volumeName enable
限制最大使用 100G：
gluster volume quota volumeName limit-usage / 100GB
2.开启异步操作
gluster volume set volumeName performance.flush-behind on
3.调整 io 线程的数量
gluster volume set volumeName performance.io-thread-count 32
4.使用缓存
# 设置缓存大小
gluster volume set models performance.cache-size 4GB
# 开启回写，先写到缓存，再刷到磁盘
gluster volume set models performance.write-behind on
最新版本：3.10
主要是 bug 修复，还包括了libgfapi支持结合NFS Ganesha。
官方主页：https://www.gluster.org/
旨在提供高性能、可扩展性和可靠性，适用于现代数据中心和云环境。它以横向扩展的方式设计，可以在多台服务器之间共享文件系统，为应用程序提供统一的文件存储服务。其核心理念是将多台普通的服务器组合成一个高性能的分布式存储系统。它采用了分布式哈希表来管理数据存储和访问，通过将文件划分为小块并存储在不同服务器上，实现了数据的分布式存储和负载均衡。这种分布式存储模式不仅提高了存储容量和性能，还提高了系统的可靠性，因为数据的冗余备份可以在服务器故障时保证数据的可用性。
GlusterFS 提供了简单而灵活的管理接口，使得管理员可以轻松地管理存储集群并对其进行扩展。它支持多种存储协议，包括标准的网络文件系统（NFS）、Server Message Block（SMB）和本地 POSIX 文件系统，使得应用程序可以通过不同的协议访问存储集群。
由于其高性能、可扩展性和易用性，它在大规模的数据存储和处理场景中被广泛应用，包括云计算、大数据分析、内容交付网络（CDN）等领域；是一个强大而灵活的分布式文件系统解决方案，可以帮助用户构建可靠的存储基础设施，满足不断增长的存储需求。
GlusterFS is an open source, distributed file system capable of scaling to several petabytes (actually, 72 brontobytes!) and handling thousands of clients. GlusterFS clusters together storage building blocks over Infiniband RDMA or TCP/IP interconnect, aggregating disk and memory resources and managing data in a single global namespace. GlusterFS is based on a stackable user space design and can deliver exceptional performance for diverse workloads.
用户可以在全局统一的命名空间中使用NFS/CIFS等标准协议来访问应用数据。GlusterFS使得用户可摆脱原有的独立、高成本的封闭存储系统，能够利用普通廉价的存储设备来部署可集中管理、横向扩展、虚拟化的存储池，存储容量可扩展至TB/PB级。总体架构如下：
主要特征如下：
扩展性和高性能
GlusterFS利用双重特性来提供几TB至数PB的高扩展存储解决方案。Scale-Out架构允许通过简单地增加资源来提高存储容量和性能，磁盘、计算和I/O资源都可以独立增加，支持10GbE和InfiniBand等高速网络互联。Gluster弹性哈希(Elastic Hash)解除了GlusterFS对元数据服务器的需求，消除了单点故障和性能瓶颈，真正实现了并行化数据访问。
高可用性
GlusterFS可以对文件进行自动复制，如镜像或多次复制，从而确保数据总是可以访问，甚至是在硬件故障的情况下也能正常访问。自我修复功能能够把数据恢复到正确的状态，而且修复是以增量的方式在后台执行，几乎不会产生性能负载。GlusterFS没有设计自己的私有数据文件格式，而是采用操作系统中主流标准的磁盘文件系统(如EXT3、ZFS)来存储文件，因此数据可以使用各种标准工具进行复制和访问。
全局统一命名空间
全局统一命名空间将磁盘和内存资源聚集成一个单一的虚拟存储池，对上层用户和应用屏蔽了底层的物理硬件。存储资源可以根据需要在虚拟存储池中进行弹性扩展，比如扩容或收缩。当存储虚拟机映像时，存储的虚拟映像文件没有数量限制，成千虚拟机均通过单一挂载点进行数据共享。虚拟机I/O可在命名空间内的所有服务器上自动进行负载均衡，消除了SAN环境中经常发生的访问热点和性能瓶颈问题。
弹性哈希算法
GlusterFS采用弹性哈希算法在存储池中定位数据，而不是采用集中式或分布式元数据服务器索引。在其他的Scale-Out存储系统中，元数据服务器通常会导致I/O性能瓶颈和单点故障问题。GlusterFS中，所有在Scale-Out存储配置中的存储系统都可以智能地定位任意数据分片，不需要查看索引或者向其他服务器查询。这种设计机制完全并行化了数据访问，实现了真正的线性性能扩展。
弹性卷管理
数据储存在逻辑卷中，逻辑卷可以从虚拟化的物理存储池进行独立逻辑划分而得到。存储服务器可以在线进行增加和移除，不会导致应用中断。逻辑卷可以在所有配置服务器中增长和缩减，可以在不同服务器迁移进行容量均衡，或者增加和移除系统，这些操作都可在线进行。文件系统配置更改也可以实时在线进行并应用，从而可以适应工作负载条件变化或在线性能调优。
基于标准协议
Gluster存储服务支持NFS, CIFS, HTTP, FTP以及Gluster原生协议，完全与POSIX标准兼容。现有应用程序不需要作任何修改或使用专用API，就可以对Gluster中的数据进行访问。这在公有云环境中部署Gluster时非常有用，Gluster对云服务提供商专用API进行抽象，然后提供标准POSIX接口。
其存储卷支持 7 种卷类型，即 分布式卷、条带卷、复制卷、分布式条带卷、分布式复制卷、条带复制卷、分布式条带复制卷，每种卷的特点如下：
分布式卷（Distributed Volume）：分布式卷根据hash算法将数据均匀地分布在不同服务器上，每个文件被分割成固定大小的块，然后分别存储在不同的服务器上。这种分布式存储方式可以提高存储容量和性能，因为数据可以并行地从多个服务器上读取和写入。适用于需要大容量和高性能存储的场景，如大规模数据存储、内容交付网络（CDN）等。缺点是文件没有冗余副本，一旦某台服务宕机，其中存储的数据无法读取。
复制卷（Replicated Volume）：复制卷在多个服务器之间复制数据，以提高数据的可靠性和容错能力。每个文件会被复制到多个服务器上，当某个服务器发生故障时，数据仍然可用。但是需要注意的是，由于数据被复制，这会增加存储开销。适用于对数据可靠性要求较高的场景，如数据备份、关键业务应用等。
条带化卷（Striped Volume）：条带化卷将文件分割成固定大小的块，并将这些块分别存储在不同的服务器上。这样可以提高读写性能，因为数据可以并行地从多个服务器上读取和写入。适用于需要高吞吐量和低延迟的场景，如大规模数据处理、科学计算等。
分布式复制卷（Distributed Replicated Volume）：分布式复制卷结合了分布式卷和复制卷的特点，既实现了数据的横向扩展和负载均衡，又提高了数据的可靠性和容错能力。每个文件会被分割成固定大小的块，并复制到多个服务器上。适用于需要兼顾数据容量、性能和可靠性的场景，如大规模数据存储和分析、虚拟化环境等。
分布式条带化卷（Distributed Striped Volume）：分布式条带化卷结合了分布式卷和条带化卷的特点，既实现了数据的横向扩展和负载均衡，又提高了读写性能。每个文件会被分割成固定大小的块，并分别存储在多个服务器上。适用于需要高性能和横向扩展的场景，如大规模并行计算、大数据处理等。
分布式复制条带化卷（Distributed Replicated Striped Volume）：结合了分布式卷、复制卷和条带化卷的特点，既实现了数据的横向扩展、可靠性和读写性能。每个文件会被分割成固定大小的块，并复制到多个服务器上，然后分别存储在不同的服务器上。适用于需要高性能、高可靠性和横向扩展的场景，如大规模数据处理和存储、分布式文件系统等。
分布式条带化复制卷（Distributed Striped Replicated Volume）：结合了分布式卷、条带化卷和复制卷的特点，既实现了数据的横向扩展、读写性能和可靠性。每个文件会被分割成固定大小的块，并分别存储在多个服务器上，然后在每个服务器上进行数据复制。适用于需要高性能、高可靠性和横向扩展的场景，如大规模并行计算、分布式存储系统等。
GlusterFS架构介绍1
外部架构
GlusterFS总体架构与组成部分如图2所示，它主要由存储服务器(BrickServer)、客户端以及NFS/Samba 存储网关组成。不难发现，GlusterFS 架构中没有元数据服务器组件，这是其最大的设计这点，对于提升整个系统的性能、可靠性和稳定性都有着决定性的意义。GlusterFS 支持TCP/IP 和InfiniBandRDMA 高速网络互联，客户端可通过原生Glusterfs 协议访问数据，其他没有运行GlusterFS客户端的终端可通过NFS/CIFS 标准协议通过存储网关访问数据。
内部架构
GlusterFS是模块化堆栈式的架构设计，如上图所示。模块称为Translator，是GlusterFS提供的一种强大机制，借助这种良好定义的接口可以高效简便地扩展文件系统的功能。
1.服务端与客户端模块接口是兼容的，同一个translator可同时在两边加载。
2.GlusterFS中所有的功能都是通过translator实现，如Cluster, Storage,Performance, Protocol, Features等。
3.重点是GlusterFSClient端。
数据访问流程
上图是GlusterFS数据访问的一个概要图：
1.首先是在客户端，用户通过glusterfs的mount point 来读写数据。
2.用户的这个操作被递交给本地linux系统的VFS来处理。
3.VFS将数据递交给FUSE内核文件系统，在启动glusterfs客户端以前，需要向系统注册一个实际的文件系统FUSE，如上图所示,该文件系统与ext3在同一个层次上面，ext3是对实际的磁片进行处理，而fuse文件系统则是将数据通过/dev/fuse这个设备文件递交给了glusterfs client端。所以，我们可以将fuse文件系统理解为一个代理。
4.数据被fuse递交给Glusterfs client 后，client对数据进行一些指定的处理(所谓的指定，是按照client配置文件来进行的一系列处理)
5.在glusterfsclient的处理末端，通过网路将数据递交给Glusterfs Server,并且将数据写入到服务器所控制的存储设备上
技术特点
GlusterFS在技术实现上与传统存储系统或现有其他分布式文件系统有显著不同之处，主要体现在如下几个方面：
完全软件实现(SoftwareOnly)
GlusterFS认为存储是软件问题，不能够把用户局限于使用特定的供应商或硬件配置来解决。GlusterFS采用开放式设计，广泛支持工业标准的存储、网络和计算机设备，而非与定制化的专用硬件设备捆绑。对于商业客户，GlusterFS可以以虚拟装置的形式交付，也可以与虚拟机容器打包，或者是公有云中部署的映像。开源社区中，GlusterFS被大量部署在基于廉价闲置硬件的各种操作系统上，构成集中统一的虚拟存储资源池。简言之，GlusterFS是开放的全软件实现，完全独立于硬件和操作系统。
完整的存储操作系统栈(CompleteStorage Operating System Stack)
GlusterFS不仅提供了一个分布式文件系统，而且还提供了许多其他重要的分布式功能，比如分布式内存管理、I/O调度、软RAID和自我修复等。GlusterFS汲取了微内核架构的经验教训，借鉴了GNU/Hurd操作系统的设计思想，在用户空间实现了完整的存储操作系统栈。
用户空间实现(User Space)
与传统的文件系统不同，GlusterFS在用户空间实现，这使得其安装和升级特别简便。另外，这也极大降低了普通用户基于源码修改GlusterFS的门槛，仅仅需要通用的C程序设计技能，而不需要特别的内核编程经验。
模块化堆栈式架构(ModularStackable Architecture)
GlusterFS采用模块化、堆栈式的架构，可通过灵活的配置支持高度定制化的应用环境，比如大文件存储、海量小文件存储、云存储、多传输协议应用等。每个功能以模块形式实现，然后以积木方式进行简单的组合，即可实现复杂的功能。比如，Replicate模块可实现RAID1，Stripe模块可实现RAID0，通过两者的组合可实现RAID10和RAID01，同时获得高性能和高可性。
原始数据格式存储(DataStored in Native Formats)
GlusterFS无元数据服务设计(NoMetadata with the Elastic Hash Algorithm)以原始数据格式(如EXT3、EXT4、XFS、ZFS)储存数据，并实现多种数据自动修复机制。因此系统极具弹性，即使离线情形下文件也可以通过其他标准工具进行访问。如果用户需要从GlusterFS中迁移数据，不需要作任何修改仍然可以完全使用这些数据。
对Scale-Out存储系统而言，最大的挑战之一就是记录数据逻辑与物理位置的映像关系，即数据元数据，可能还包括诸如属性和访问权限等信息。传统分布式存储系统使用集中式或分布式元数据服务来维护元数据，集中式元数据服务会导致单点故障和性能瓶颈问题，而分布式元数据服务存在性能负载和元数据同步一致性问题。特别是对于海量小文件的应用，元数据问题是个非常大的挑战。
独特地采用无元数据服务的设计，取而代之使用算法来定位文件，元数据和数据没有分离而是一起存储。集群中的所有存储系统服务器都可以智能地对文件数据分片进行定位，仅仅根据文件名和路径并运用算法即可，而不需要查询索引或者其他服务器。这使得数据访问完全并行化，从而实现真正的线性性能扩展。无元数据服务器极大提高了GlusterFS的性能、可靠性和稳定性。
一些设计与讨论
无元数据服务器vs元数据服务器
无元数据服务器设计的好处是没有单点故障和性能瓶颈问题，可提高系统扩展性、性能、可靠性和稳定性。对于海量小文件应用，这种设计能够有效解决元数据的难点问题。它的负面影响是，数据一致问题更加复杂，文件目录遍历操作效率低下，缺乏全局监控管理功能。同时也导致客户端承担了更多的职能，比如文件定位、名字空间缓存、逻辑卷视图维护等等，这些都增加了客户端的负载，占用相当的CPU 和内存。
用户空间vs内核空间
用户空间实现起来相对要简单许多，对开发者技能要求较低，运行相对安全。用户空间效率低，数据需要多次与内核空间交换，另外GlusterFS 借助FUSE 来实现标准文件系统接口，性能上又有所损耗。内核空间实现可以获得很高的数据吞吐量，缺点是实现和调试非常困难，程序出错经常会导致系统崩溃，安全性低。纵向扩展上，内核空间要优于用户空间，GlusterFS 有横向扩展能力来弥补。
堆栈式vs非堆栈式
这有点像操作系统的微内核设计与单一内核设计之争。GlusterFS 堆栈式设计思想源自GNU/Hurd 微内核操作系统，具有很强的系统扩展能力，系统设计实现复杂性降低很多，基本功能模块的堆栈式组合就可以实现强大的功能。查看GlusterFS卷配置文件我们可以发现，translator 功能树通常深达10层以上，一层一层进行调用，效率可见一斑。非堆栈式设计可看成类似Linux 的单一内核设计，系统调用通过中断实现，非常高效。后者的问题是系统核心臃肿，实现和扩展复杂，出现问题调试困难。
原始存储格式vs私有存储格式
GlusterFS使用原始格式存储文件或数据分片，可以直接使用各种标准的工具进行访问，数据互操作性好，迁移和数据管理非常方便。然而数据安全成了问题，因为数据是以平凡的方式保存的，接触数据的人可以直接复制和查看。这对很多应用显然是不能接受的，比如云存储系统，用户特别关心数据安全，这也是影响公有云存储发展的一个重要原因。私有存储格式可以保证数据的安全性，即使泄露也是不可知的。GlusterFS 要实现自己的私有格式，在设计实现和数据管理上相对复杂一些，也会对性能产生一定影响。
大文件 vs 小文件
GlusterFS适合大文件还是小文件存储?弹性哈希算法和Stripe 数据分布策略，移除了元数据依赖，优化了数据分布，提高数据访问并行性，能够大幅提高大文件存储的性能。对于小文件，无元数据服务设计解决了元数据的问题。但GlusterFS 并没有在I/O 方面作优化，在存储服务器底层文件系统上仍然是大量小文件，本地文件系统元数据访问是一个瓶颈，数据分布和并行性也无法充分发挥作用。因此它适合存储大文件，小文件性能较差，还存在很大优化空间。
可用性vs存储利用率
GlusterFS使用复制技术来提供数据高可用性，复制数量没有限制，自动修复功能基于复制来实现。可用性与存储利用率是一个矛盾体，可用性高存储利用率就低，反之亦然。采用复制技术，存储利用率为1/复制数，镜像是50%，三路复制则只有33%。其实，可以有方法来同时提高可用性和存储利用率，比如RAID5的利用率是(n-1)/n，RAID6是(n-2)/n，而纠删码技术可以提供更高的存储利用率。但鱼和熊掌不可得兼，它们都会对性能产生较大影响。
GlusterFS架构介绍2
GlusterFS系统是一个可扩展的网络文件系统，相比其他分布式文件系统，其具有高扩展性、高可用性、高性能、可横向扩展等特点，并且其没有元数据服务器的设计，让整个服务没有单点故障的隐患。它同时是一个横向扩展的分布式文件系统，就是把多台异构的存储服务器的存储空间整合起来给用户提供统一的命名空间。用户访问存储资源的方式有很多，可以通过NFS，SMB，HTTP协议等访问，还可以通过gluster本身提供的客户端访问。
GlusterFS是Scale-Out存储解决方案Gluster的核心，它是一个开源的分布式文件系统，具有强大的横向扩展能力，通过扩展能够支持数PB存储容量和处理数千客户端。其借助TCP/IP或InfiniBand RDMA网络将物理分布的存储资源聚集在一起，使用单一全局命名空间来管理数据。GlusterFS基于可堆叠的用户空间设计，可为各种不同的数据负载提供优异的性能。
GlusterFS 适合大文件还是小文件存储？弹性哈希算法和 Stripe 数据分布策略，移除了元数据依赖，优化了数据分布，提高数据访问并行性，能够大幅提高大文件存储的性能。对于小文件，无元数据服务设计解决了元数据的问题。但GlusterFS并没有在 I/O 方面作优化，在存储服务器底层文件系统上仍然是大量小文件，本地文件系统元数据访问是一个瓶颈，数据分布和并行性也无法充分发挥作用。因此，GlusterFS 适合存储大文件，小文件性能较差，还存在很大优化空间。
GlusterFS在企业中应用场景
理论和实践上分析，GlusterFS目前主要适用大文件存储场景，对于小文件尤其是海量小文件，存储效率和访问性能都表现不佳。海量小文件LOSF问题是工业界和学术界公认的难题，其作为通用的分布式文件系统，并没有对小文件作额外的优化措施，性能不好也是可以理解的。
Media：文档、图片、音频、视频
Shared storage：云存储、虚拟化存储、HPC(高性能计算)
Big data：日志文件、RFID(射频识别)数据
1)相关术语
Brick：GlusterFS中的存储单元，通过是一个受信存储池中的服务器的一个导出目录。可以通过主机名和目录名来标识，如'SERVER:EXPORT'。
Client：挂载了GlusterFS卷的设备。
GFID：GlusterFS卷中的每个文件或目录都有一个唯一的128位的数据相关联，其用于模拟inode
Namespace：每个Gluster卷都导出单个ns作为POSIX的挂载点。
Node：一个拥有若干brick的设备。
RDMA：远程直接内存访问，支持不通过双方的OS进行直接内存访问。
RRDNS：round robin DNS是一种通过DNS轮转返回不同的设备以进行负载均衡的方法
Self-heal：用于后台运行检测复本卷中文件和目录的不一致性并解决这些不一致。
Split-brain：脑裂
Volfile：Glusterfs进程的配置文件，通常位于/var/lib/glusterd/vols/volname
Volume：一组bricks的逻辑集合
a)Trusted Storage Pool
一堆存储节点的集合
通过一个节点“邀请”其他节点创建，这里叫probe
成员可以动态加入，动态删除
添加命令如下：
node1# gluster peer probe node2
删除命令如下：
node1# gluster peer detach node3
2)Bricks
Brick是一个节点和一个导出目录的集合，e.g. node1:/brick1
Brick是底层的RAID或磁盘经XFS或ext4文件系统格式化而来，所以继承了文件系统的限制
每个节点上的brick数是不限的
理想的状况是，一个集群的所有Brick大小都一样。
3)Volumes
Volume是brick的逻辑组合
创建时命名来识别
Volume是一个可挂载的目录
每个节点上的brick数是不变的,e.g.mount –t glusterfs somehost:test /mnt/gls
一个节点上的不同brick可以属于不同的卷
支持如下种类：
a) 分布式卷
b) 条带卷
c) 复制卷
d) 分布式复制卷
e) 条带复制卷
f) 分布式条带复制卷
3.1)分布式卷
文件分布存在不同的brick里
目录在每个brick里都可见
单个brick失效会带来数据丢失
无需额外元数据服务器
3.2)复制卷
同步复制所有的目录和文件
节点故障时保持数据高可用
事务性操作，保持一致性
有changelog
副本数任意定
3.3)分布式复制卷
最常见的一种模式
读操作可以做到负载均衡
3.4)条带卷
文件切分成一个个的chunk，存放于不同的brick上
只建议在非常大的文件时使用(比硬盘大小还大)
Brick故障会导致数据丢失，建议和复制卷同时使用
Chunks are files with holes – this helps in maintaining offset consistency.
2)无元数据设计
元数据是用来描述一个文件或给定区块在分布式文件系统中所在的位置，简而言之就是某个文件或某个区块存储的位置。传统分布式文件系统大都会设置元数据服务器或者功能相近的管理服务器，主要作用就是用来管理文件与数据区块之间的存储位置关系。相较其他分布式文件系统而言，GlusterFS并没有集中或者分布式的元数据的概念，取而代之的是弹性哈希算法。集群中的任何服务器和客户端都可以利用哈希算法、路径及文件名进行计算，就可以对数据进行定位，并执行读写访问操作。
这种设计带来的好处是极大的提高了扩展性，同时也提高了系统的性能和可靠性；另一显著的特点是如果给定确定的文件名，查找文件位置会非常快。但是如果要列出文件或者目录，性能会大幅下降，因为列出文件或者目录时，需要查询所在节点并对各节点中的信息进行聚合。此时有元数据服务的分布式文件系统的查询效率反而会提高许多。
3)服务的部署
在之前的版本中服务器间的关系是对等的，也就是说每个节点服务器都掌握了集群的配置信息，这样做的好处是每个节点度拥有节点的配置信息，高度自治，所有信息都可以在本地查询。每个节点的信息更新都会向其他节点通告，保证节点间信息的一致性。但如果集群规模较大，节点众多时，信息同步的效率就会下降，节点信息的非一致性概率就会大大提高。因此GlusterFS未来的版本有向集中式管理变化的趋势。
4)技术特点
GlusterFS在技术实现上与传统存储系统或现有其他分布式文件系统有显著不同之处，主要体现在如下几个方面。
a)完全软件实现(SoftwareOnly)
GlusterFS认为存储是软件问题，不能够把用户局限于使用特定的供应商或硬件配置来解决。它采用开放式设计，广泛支持工业标准的存储、网络和计算机设备，而非与定制化的专用硬件设备捆绑。对于商业客户，GlusterFS可以以虚拟装置的形式交付，也可以与虚拟机容器打包，或者是公有云中部署的映像。开源社区中，GlusterFS被大量部署在基于廉价闲置硬件的各种操作系统上，构成集中统一的虚拟存储资源池。简言之，GlusterFS是开放的全软件实现，完全独立于硬件和操作系统。
b)完整的存储操作系统栈(CompleteStorage Operating System Stack)
GlusterFS不仅提供了一个分布式文件系统，而且还提供了许多其他重要的分布式功能，比如分布式内存管理、I/O调度、软RAID和自我修复等。GlusterFS汲取了微内核架构的经验教训，借鉴了GNU/Hurd操作系统的设计思想，在用户空间实现了完整的存储操作系统栈。
c)用户空间实现(User Space)
与传统的文件系统不同，GlusterFS在用户空间实现，这使得其安装和升级特别简便。另外，这也极大降低了普通用户基于源码修改GlusterFS的门槛，仅仅需要通用的C程序设计技能，而不需要特别的内核编程经验。
d)模块化堆栈式架构(ModularStackable Architecture)
GlusterFS采用模块化、堆栈式的架构，可通过灵活的配置支持高度定制化的应用环境，比如大文件存储、海量小文件存储、云存储、多传输协议应用等。每个功能以模块形式实现，然后以积木方式进行简单的组合，即可实现复杂的功能。比如，Replicate模块可实现RAID1，Stripe模块可实现RAID0，通过两者的组合可实现RAID10和RAID01，同时获得高性能和高可性。
e)原始数据格式存储(DataStored in Native Formats)
GlusterFS无元数据服务设计(NoMetadata with the Elastic Hash Algorithm)以原始数据格式(如EXT3、EXT4、XFS、ZFS)储存数据，并实现多种数据自动修复机制。因此系统极具弹性，即使离线情形下文件也可以通过其他标准工具进行访问。如果用户需要从GlusterFS中迁移数据，不需要作任何修改仍然可以完全使用这些数据。
对Scale-Out存储系统而言，最大的挑战之一就是记录数据逻辑与物理位置的映像关系，即数据元数据，可能还包括诸如属性和访问权限等信息。传统分布式存储系统使用集中式或分布式元数据服务来维护元数据，集中式元数据服务会导致单点故障和性能瓶颈问题，而分布式元数据服务存在性能负载和元数据同步一致性问题。特别是对于海量小文件的应用，元数据问题是个非常大的挑战。
GlusterFS独特地采用无元数据服务的设计，取而代之使用算法来定位文件，元数据和数据没有分离而是一起存储。集群中的所有存储系统服务器都可以智能地对文件数据分片进行定位，仅仅根据文件名和路径并运用算法即可，而不需要查询索引或者其他服务器。这使得数据访问完全并行化，从而实现真正的线性性能扩展。无元数据服务器极大提高了GlusterFS的性能、可靠性和稳定性。
5)整体工作流程(即数据访问流程)
a)首先是在客户端， 用户通过glusterfs的mount point 来读写数据， 对于用户来说，集群系统的存在对用户是完全透明的，用户感觉不到是操作本地系统还是远端的集群系统。
b)用户的这个操作被递交给 本地linux系统的VFS来处理。
c)VFS 将数据递交给FUSE 内核文件系统:在启动 glusterfs 客户端以前，需要想系统注册一个实际的文件系统FUSE,如上图所示，该文件系统与ext3在同一个层次上面， ext3 是对实际的磁盘进行处理， 而fuse 文件系统则是将数据通过/dev/fuse 这个设备文件递交给了glusterfs client端。所以， 我们可以将 fuse文件系统理解为一个代理。
d)数据被fuse 递交给Glusterfs client 后， client 对数据进行一些指定的处理(所谓的指定，是按照client 配置文件据来进行的一系列处理， 我们在启动glusterfs client 时需要指定这个文件。
e)在glusterfs client的处理末端，通过网络将数据递交给 Glusterfs Server，并且将数据写入到服务器所控制的存储设备上。
这样整个数据流的处理就完成了。
GlusterFS客户端访问流程
当客户端访问GlusterFS存储时，首先程序通过访问挂载点的形式读写数据，对于用户和程序而言，集群文件系统是透明的，用户和程序根本感觉不到文件系统是本地还是在远程服务器上。读写操作将会被交给VFS(Virtual File System)来处理，VFS会将请求交给FUSE内核模块，而FUSE又会通过设备/dev/fuse将数据交给GlusterFS Client。最后经过GlusterFS Client的计算，并最终经过网络将请求或数据发送到GlusterFS Server上。
6)集群模式
GlusterFS分布式存储集群的模式只数据在集群中的存放结构，类似于磁盘阵列中的级别。
a)分布式卷(Distributed Volume)，默认模式，DHT又称哈希卷，近似于RAID0，文件没有分片，文件根据hash算法写入各个节点的硬盘上，优点是容量大，缺点是没冗余。
# gluster volume create test-volume server1:/exp1 server2:/exp2 server3:/exp3 server4:/exp4
b)复制卷(Replicated Volume)，复制模式，AFR相当于raid1，复制的份数，决定集群的大小，通常与分布式卷或者条带卷组合使用，解决前两种存储卷的冗余缺陷。缺点是磁盘利用率低。复本卷在创建时可指定复本的数量，通常为2或者3，复本在存储时会在卷的不同brick上，因此有几个复本就必须提供至少多个brick，当其中一台服务器失效后，可以从另一台服务器读取数据，因此复制GlusterFS卷提高了数据可靠性的同事，还提供了数据冗余的功能。
# gluster volume create test-volume replica 2 transport tcp server1:/exp1 server2:/exp2
避免脑裂，加入仲裁：
# gluster volume create replica 3 arbiter 1 host1:brick1 host2:brick2 host3:brick3
c)分布式复制卷(Distributed Replicated Volume)，最少需要4台服务器。
# gluster volume create test-volume replica 2 transport tcp server1:/exp1 server2:/exp2 server3:/exp3 server4:/exp4
d)条带卷(Striped Volume)
相当于raid0，文件是分片均匀写在各个节点的硬盘上的，优点是分布式读写，性能整体较好。缺点是没冗余，分片随机读写可能会导致硬盘IOPS饱和。
# gluster volume create test-volume stripe 2 transport tcp server1:/exp1 server2:/exp2
e)分布式条带卷(Distributed Striped Volume)，最少需要4台服务器。
当单个文件的体型十分巨大，客户端数量更多时，条带卷已经无法满足需求，此时将分布式与条带化结合起来是一个比较好的选择。其性能与服务器数量有关。
# gluster volume create test-volume stripe 4 transport tcp server1:/exp1 server2:/exp2 server3:/exp3 server4:/exp4 server5:/exp5 server6:/exp6 server7:/exp7 server8:/exp8
7)存储特点
a)扩展性和高性能
GlusterFS利用双重特性来提供几TB至数PB的高扩展存储解决方案。Scale-Out架构允许通过简单地增加资源来提高存储容量和性能，磁盘、计算和I/O资源都可以独立增加，支持10GbE和InfiniBand等高速网络互联。Gluster弹性哈希(Elastic Hash)解除了GlusterFS对元数据服务器的需求，消除了单点故障和性能瓶颈，真正实现了并行化数据访问。
b)高可用性
GlusterFS可以对文件进行自动复制，如镜像或多次复制，从而确保数据总是可以访问，甚至是在硬件故障的情况下也能正常访问。自我修复功能能够把数据恢复到正确的状态，而且修复是以增量的方式在后台执行，几乎不会产生性能负载。GlusterFS没有设计自己的私有数据文件格式，而是采用操作系统中主流标准的磁盘文件系统(如EXT3、ZFS)来存储文件，因此数据可以使用各种标准工具进行复制和访问。
c)全局统一命名空间
全局统一命名空间将磁盘和内存资源聚集成一个单一的虚拟存储池，对上层用户和应用屏蔽了底层的物理硬件。存储资源可以根据需要在虚拟存储池中进行弹性扩展，比如扩容或收缩。当存储虚拟机映像时，存储的虚拟映像文件没有数量限制，成千虚拟机均通过单一挂载点进行数据共享。虚拟机I/O可在命名空间内的所有服务器上自动进行负载均衡，消除了SAN环境中经常发生的访问热点和性能瓶颈问题。
d)弹性哈希算法
GlusterFS采用弹性哈希算法在存储池中定位数据，而不是采用集中式或分布式元数据服务器索引。在其他的Scale-Out存储系统中，元数据服务器通常会导致I/O性能瓶颈和单点故障问题。GlusterFS中，所有在Scale-Out存储配置中的存储系统都可以智能地定位任意数据分片，不需要查看索引或者向其他服务器查询。这种设计机制完全并行化了数据访问，实现了真正的线性性能扩展。
e)弹性卷管理
数据储存在逻辑卷中，逻辑卷可以从虚拟化的物理存储池进行独立逻辑划分而得到。存储服务器可以在线进行增加和移除，不会导致应用中断。逻辑卷可以在所有配置服务器中增长和缩减，可以在不同服务器迁移进行容量均衡，或者增加和移除系统，这些操作都可在线进行。文件系统配置更改也可以实时在线进行并应用，从而可以适应工作负载条件变化或在线性能调优。
f)基于标准协议
Gluster存储服务支持NFS,CIFS,HTTP,FTP以及Gluster原生协议，完全与POSIX标准兼容。现有应用程序不需要作任何修改或使用专用API，就可以对Gluster中的数据进行访问。这在公有云环境中部署Gluster时非常有用，Gluster对云服务提供商专用API进行抽象，然后提供标准POSIX接口。
8)功能简介
8.1)基本管理功能
GlusterFS服务管理：启动、停止、重启服务；
TrustedStorage Pools管理：增加或删除peer；
Volume管理：增加卷、启动卷、停止卷；
上述这些基本的管理功能不再做介绍。
8.2)TuningVolume Options(调整卷配置)
GlustreFS提供了45项配置用来调整Volume属性，包括端口、cache、安全、存储空间、自愈、日志、扩展性、通讯协议、性能等配置项。用户可以通过gluster volume info命令来查看自定义配置项。
8.3)ConfiguringTransport Types for Volume(配置传输类型)
创建卷的时候，可以选择client与brick的通讯协议。
也可以通过"gluster volume set volnameconfig.transport tcp,rdma OR tcp OR rdma"命令更改通讯协议，需要注意的在更改通讯协议前，必须先停止volume。
默认情况是TCP，根据部署场景可选择RDMA或RDMA+TCP组合，而选择RDMA协议需要相应硬件的支持。
8.4)ExpandingVolumes(扩容)
GlusterFS集群的扩容就是通过增加volume来实现，通过"glustervolume add-brick"命令增加卷。
注意，扩容复制卷的时候，必须同时增加卷的数量是replica的倍数。例如replica 2的集群扩容，需要同时增加2个volume；replica3的集群扩容，需要同时增加3个volume。
8.5)ShrinkingVolumes(缩容)
集群缩减存储空间通过删除卷的“glustervolume remove-brick”命令实现，删除卷的命令执行后，GlustreFS会启动数据迁移，若迁移的数据较大，迁移过程将耗时较长，可能通过命令观察迁移状态。
8.6)Replacefaulty brick(更换坏块)
用好的brick替换故障的brick。
使用方法如下："glustervolume replace-brick test-volume server3:/exp3 server5:/exp5 commit force"，将test-volume卷中的server3:/exp3故障brick替换掉。
8.7)RebalancingVolumes(负载调整)
扩容或缩容卷，集群中可能会出现不同卷的存储利用率较大的不均衡的现象。通过Rebalancing机制，在后台以人工方式来执行负载平滑，将进行文件移动和重新分布，此后所有存储服务器都会均会被调度。为了便于控制管理，rebalance操作分为两个阶段进行实际执行，即FixLayout和MigrateData。
a)FixLayout：修复layout以使得新旧目录下新建文件可以在新增节点上分布上。
b)MigrateData：新增或缩减节点后，在卷下所有节点上进行容量负载平滑。为了提高rebalance效率，通常在执行此操作前先执行FixLayout。
8.8)TriggeringSelf-Heal on Replicate(文件自愈)
在复制卷中，若出现复本间文件不同步的情况，系统每十分钟会自动启动Self-Heal。
也可以主动执行"glustervolume heal"命令触发Self-Heal，通过"gluster volume heal info"可以查看需要heal的文件列表。
在healing过程中，可以通过"gluster volume heal info healed"查看已修复文件的列表；
通过"gluster volume heal info failed"查看修复失败的文件列表。
8.9)Geo-replication(异地备份)
异地备份可以提供数据的灾难恢复。以本地集群作为主存储，异地存储为备份，通过局域网或互联网持续、增量、异步备份数据。
使用"gluster volume geo-replication"相关的命令实现异地备份创建管理。
8.10)Quota(限额管理)
GlusterFS提供目录或卷的存储使用空间的限制设置功能。通过目录限额可以实现对用户按存储容量计费的功能。
使用方法为："gluster volume quota"
8.11)VolumeSnapshots(卷快照)
卷快照功能用于卷的备份和恢复，在非复制卷的应用场景，通过卷快照实现数据冗余备份。
8.12)MonitoringWorkload(性能监控)
监控每一个brick文件操作的IO性能，主要监控打开fd的数量和最大fd数量、最大读文件调用数、最大写文件调用数、最大打开目录调用数、brick读性能、brcik写性能等。
使用方法："gluster volume profile"
GlusterFS的缺点
GlusterFS是一个开源的分布式文件系统，它的历史可以追溯到2006年，最初的目标是代替Lustre和GPFS分布式文件系统。经过八年左右的蓬勃发展，GlusterFS目前在开源社区活跃度非常之高，这个后起之秀已经俨然与Lustre、MooseFS、CEPH并列成为四大开源分布式文件系统。由于GlusterFS新颖和KISS(KeepIt as Stupid and Simple)的系统架构，使其在扩展性、可靠性、性能、维护性等方面具有独特的优势，目前开源社区风头有压倒之势，国内外有大量用户在研究、测试和部署应用。
当然，GlusterFS不是一个完美的分布式文件系统，这个系统自身也有许多不足之处，包括众所周知的元数据性能和小文件问题。没有普遍适用各种应用场景的分布式文件系统，通用的意思就是通通不能用，四大开源系统不例外，所有商业产品也不例外。每个分布式文件系统都有它适用的应用场景，适合的才是最好的。这一次我们反其道而行之，不再谈GlusterFS的各种优点，而是深入谈谈GlusterFS当下的问题和不足，从而更加深入地理解GlusterFS系统，期望帮助大家进行正确的系统选型决策和规避应用中的问题。同时，这些问题也是GlusterFS研究和研发的很好切入点。
1)元数据性能
GlusterFS使用弹性哈希算法代替传统分布式文件系统中的集中或分布式元数据服务，这个是GlusterFS最核心的思想，从而获得了接近线性的高扩展性，同时也提高了系统性能和可靠性。GlusterFS使用算法进行数据定位，集群中的任何服务器和客户端只需根据路径和文件名就可以对数据进行定位和读写访问，文件定位可独立并行化进行。
这种算法的特点是，给定确定的文件名，查找和定位会非常快。但是，如果事先不知道文件名，要列出文件目录(ls或ls -l)，性能就会大幅下降。对于Distributed哈希卷，文件通过HASH算法分散到集群节点上，每个节点上的命名空间均不重叠，所有集群共同构成完整的命名空间，访问时使用HASH算法进行查找定位。列文件目录时，需要查询所有节点，并对文件目录信息及属性进行聚合。这时，哈希算法根本发挥不上作用，相对于有中心的元数据服务，查询效率要差很多。
从接触的一些用户和实践来看，当集群规模变大以及文件数量达到百万级别时，ls文件目录和rm删除文件目录这两个典型元数据操作就会变得非常慢，创建和删除100万个空文件可能会花上15分钟。如何解决这个问题呢？我们建议合理组织文件目录，目录层次不要太深，单个目录下文件数量不要过多；增大服务器内存配置，并且增大GlusterFS目录缓存参数；网络配置方面，建议采用万兆或者InfiniBand。从研发角度看，可以考虑优化方法提升元数据性能。比如，可以构建全局统一的分布式元数据缓存系统；也可以将元数据与数据重新分离，每个节点上的元数据采用全内存或数据库设计，并采用SSD进行元数据持久化。
2)小文件问题
理论和实践上分析，GlusterFS目前主要适用大文件存储场景，对于小文件尤其是海量小文件，存储效率和访问性能都表现不佳。海量小文件LOSF问题是工业界和学术界公认的难题，GlusterFS作为通用的分布式文件系统，并没有对小文件作额外的优化措施，性能不好也是可以理解的。
对于LOSF而言，IOPS/OPS是关键性能衡量指标，造成性能和存储效率低下的主要原因包括元数据管理、数据布局和I/O管理、Cache管理、网络开销等方面。从理论分析以及LOSF优化实践来看，优化应该从元数据管理、缓存机制、合并小文件等方面展开，而且优化是一个系统工程，结合硬件、软件，从多个层面同时着手，优化效果会更显著。GlusterFS小文件优化可以考虑这些方法，这里不再赘述，关于小文件问题请参考“海量小文件问题综述”一文。
3)集群管理模式
GlusterFS集群采用全对等式架构，每个节点在集群中的地位是完全对等的，集群配置信息和卷配置信息在所有节点之间实时同步。这种架构的优点是，每个节点都拥有整个集群的配置信息，具有高度的独立自治性，信息可以本地查询。但同时带来的问题的，一旦配置信息发生变化，信息需要实时同步到其他所有节点，保证配置信息一致性，否则GlusterFS就无法正常工作。在集群规模较大时，不同节点并发修改配置时，这个问题表现尤为突出。因为这个配置信息同步模型是网状的，大规模集群不仅信息同步效率差，而且出现数据不一致的概率会增加。
实际上，大规模集群管理应该是采用集中式管理更好，不仅管理简单，效率也高。可能有人会认为集中式集群管理与GlusterFS的无中心架构不协调，其实不然。GlusterFS 2.0以前，主要通过静态配置文件来对集群进行配置管理，没有Glusterd集群管理服务，这说明glusterd并不是GlusterFS不可或缺的组成部分，它们之间是松耦合关系，可以用其他的方式来替换。从其他分布式系统管理实践来看，也都是采用集群式管理居多，这也算一个佐证，GlusterFS 4.0开发计划也表现有向集中式管理转变的趋势。
4)容量负载均衡
GlusterFS的哈希分布是以目录为基本单位的，文件的父目录利用扩展属性记录了子卷映射信息，子文件在父目录所属存储服务器中进行分布。由于文件目录事先保存了分布信息，因此新增节点不会影响现有文件存储分布，它将从此后的新创建目录开始参与存储分布调度。这种设计，新增节点不需要移动任何文件，但是负载均衡没有平滑处理，老节点负载较重。GlusterFS实现了容量负载均衡功能，可以对已经存在的目录文件进行Rebalance，使得早先创建的老目录可以在新增存储节点上分布，并可对现有文件数据进行迁移实现容量负载均衡。
GlusterFS目前的容量负载均衡存在一些问题。由于采用Hash算法进行数据分布，容量负载均衡需要对所有数据重新进行计算并分配存储节点，对于那些不需要迁移的数据来说，这个计算是多余的。Hash分布具有随机性和均匀性的特点，数据重新分布之后，老节点会有大量数据迁入和迁出，这个多出了很多数据迁移量。相对于有中心的架构，可谓节点一变而动全身，增加和删除节点增加了大量数据迁移工作。GlusterFS应该优化数据分布，最小化容量负载均衡数据迁移。此外，GlusterFS容量负载均衡也没有很好考虑执行的自动化、智能化和并行化。目前，GlusterFS在增加和删除节点上，需要手工执行负载均衡，也没有考虑当前系统的负载情况，可能影响正常的业务访问。GlusterFS的容量负载均衡是通过在当前执行节点上挂载卷，然后进行文件复制、删除和改名操作实现的，没有在所有集群节点上并发进行，负载均衡性能差。
5)数据分布问题
Glusterfs主要有三种基本的集群模式，即分布式集群(Distributed cluster)、条带集群(Stripe cluster)、复制集群(Replica cluster)。这三种基本集群还可以采用类似堆积木的方式，构成更加复杂的复合集群。三种基本集群各由一个translator来实现，分别由自己独立的命名空间。对于分布式集群，文件通过HASH算法分散到集群节点上，访问时使用HASH算法进行查找定位。复制集群类似RAID1，所有节点数据完全相同，访问时可以选择任意个节点。条带集群与RAID0相似，文件被分成数据块以Round Robin方式分布到所有节点上，访问时根据位置信息确定节点。
哈希分布可以保证数据分布式的均衡性，但前提是文件数量要足够多，当文件数量较少时，难以保证分布的均衡性，导致节点之间负载不均衡。这个对有中心的分布式系统是很容易做到的，但GlusteFS缺乏集中式的调度，实现起来比较复杂。复制卷包含多个副本，对于读请求可以实现负载均衡，但实际上负载大多集中在第一个副本上，其他副本负载很轻，这个是实现上问题，与理论不太相符。条带卷原本是实现更高性能和超大文件，但在性能方面的表现太差强人意，远远不如哈希卷和复制卷，没有被好好实现，连官方都不推荐应用。
6)数据可用性问题
副本(Replication)就是对原始数据的完全拷贝。通过为系统中的文件增加各种不同形式的副本，保存冗余的文件数据，可以十分有效地提高文件的可用性，避免在地理上广泛分布的系统节点由网络断开或机器故障等动态不可测因素而引起的数据丢失或不可获取。GlusterFS主要使用复制来提供数据的高可用性，通过的集群模式有复制卷和哈希复制卷两种模式。复制卷是文件级RAID1，具有容错能力，数据同步写到多个brick上，每个副本都可以响应读请求。当有副本节点发生故障，其他副本节点仍然正常提供读写服务，故障节点恢复后通过自修复服务或同步访问时自动进行数据同步。
一般而言，副本数量越多，文件的可靠性就越高，但是如果为所有文件都保存较多的副本数量，存储利用率低(为副本数量分之一)，并增加文件管理的复杂度。目前GlusterFS社区正在研发纠删码功能，通过冗余编码提高存储可用性，并且具备较低的空间复杂度和数据冗余度，存储利用率高。
GlusterFS的复制卷以brick为单位进行镜像，这个模式不太灵活，文件的复制关系不能动态调整，在已经有副本发生故障的情况下会一定程度上降低系统的可用性。对于有元数据服务的分布式系统，复制关系可以是以文件为单位的，文件的不同副本动态分布在多个存储节点上；当有副本发生故障，可以重新选择一个存储节点生成一个新副本，从而保证副本数量，保证可用性。另外，还可以实现不同文件目录配置不同的副本数量，热点文件的动态迁移。对于无中心的GlusterFS系统来说，这些看起来理所当然的功能，实现起来都是要大费周折的。不过值得一提的是，4.0开发计划已经在考虑这方面的副本特性。
7)数据安全问题
GlusterFS以原始数据格式(如EXT4、XFS、ZFS)存储数据，并实现多种数据自动修复机制。因此，系统极具弹性，即使离线情形下文件也可以通过其他标准工具进行访问。如果用户需要从GlusterFS中迁移数据，不需要作任何修改仍然可以完全使用这些数据。
然而，数据安全成了问题，因为数据是以平凡的方式保存的，接触数据的人可以直接复制和查看。这对很多应用显然是不能接受的，比如云存储系统，用户特别关心数据安全。私有存储格式可以保证数据的安全性，即使泄露也是不可知的。GlusterFS要实现自己的私有格式，在设计实现和数据管理上相对复杂一些，也会对性能产生一定影响。
GlusterFS在访问文件目录时根据扩展属性判断副本是否一致，这个进行数据自动修复的前提条件。节点发生正常的故障，以及从挂载点进行正常的操作，这些情况下发生的数据不一致，都是可以判断和自动修复的。但是，如果直接从节点系统底层对原始数据进行修改或者破坏，GlusterFS大多情况下是无法判断的，因为数据本身也没有校验，数据一致性无法保证。
8)Cache一致性
为了简化Cache一致性，GlusterFS没有引入客户端写Cache，而采用了客户端只读Cache。GlusterFS采用简单的弱一致性，数据缓存的更新规则是根据设置的失效时间进行重置的。对于缓存的数据，客户端周期性询问服务器，查询文件最后被修改的时间，如果本地缓存的数据早于该时间，则让缓存数据失效，下次读取数据时就去服务器获取最新的数据。
GlusterFS客户端读Cache刷新的时间缺省是1秒，可以通过重新设置卷参数Performance.cache-refresh-timeout进行调整。这意味着，如果同时有多个用户在读写一个文件，一个用户更新了数据，另一个用户在Cache刷新周期到来前可能读到非最新的数据，即无法保证数据的强一致性。因此实际应用时需要在性能和数据一致性之间进行折中，如果需要更高的数据一致性，就得调小缓存刷新周期，甚至禁用读缓存；反之可以把缓存周期调大一点，以提升读性能。
术语表：
Xlator=translator:glusterfs 模块的代名词
Brick :存储目录是Glusterfs 的基本存储单元，由可信存储池中服务器上对外
输出的目录表示。存储目录的格式由服务器和目录的绝对路径构成，具体如下：
SERVER:EXPORT.例如：myhostname:/exports/myexportdir/
Volume:卷是存储目录的逻辑组合。大部分gluster 管理操作是在卷上进行的。
Metadata:元数据关于数据的数据，用于描述文件、目录等的相关信息。
FUSE=Filesystem inUserspace:是一个内核模块，允许用户创建自己的文件系统无需修改内核代码。
Glusterd : Glusterfs 后台进程，运行在所有Glusterfs 节点上。
DistributeVolume: 分布式卷
ReplicateVolume: 副本卷
StripeVolume: 条带卷
DistributeReplicate Volume: 分布式副本卷
DHT=Distribute HashTable
AFR=Automatic FileReplication
SAN = Storage AreaNetwork：存储区域网络是一种高速网络或子网络，提供在计算机与存储之间的数据传输。
NAS = Network-attachedstorage：网络附属存储是一种将分布、独立的数据整合为大型、集中化管理的数据中心，以便于对不同主机和应用服务器进行访问的技术。
RPC =Remote ProcedureCall: 远程过程调用
XDR =eXtern DataRepresentation: RPC 传递数据的格式
CLI=Command LineInterface 控制台
argp=Argument Parser
UUID=University UnqiueIdentifier
SVC =service
CLNT =client
MGMT=management
cbks = Call Backs
ctx = context
lk = lock
attr = attribute
txn = transaction
rb = replace brick
worm = write once , readmany
系统配额：
1、开启/关闭系统配额
gluster volume quota VOLNAME enable/disable
2、设置(重置)目录配额
gluster volume quota VOLNAME limit-usage/imglimit-value
gluster volume quota img limit-usage/quota10GB
设置 img 卷下的 quota 子目录的限额为10GB。这个目录是以系统挂载目录为根目录”/”，所以 /quota 即客户端挂载目录下的子目录quota。
3、配额查看
gluster volume quota VOLNAME list
gluster volume quota VOLNAME list
可以使用如上两个命令进行系统卷的配额查看，第一个命令查看目的卷的所有配额设置，
第二个命令则是执行目录进行查看。可以显示配额大小及当前使用容量，若无使用容量(最小0KB)则说明设置的目录可能是错误的(不存在)。
地域复制：
glustervolumegeo-replicationMASTERSLAVEstart/status/stop
//地域复制是系统提供的灾备功能，能够将系统的全部数据进行异步的增量备份到另外的磁盘中。
glustervolumegeo-replicationimg192.168.10.8:/data1/brick1start
如上，开始执行将 img 卷的所有内容备份 到10.8 下的 /data1/brick1 中的task，需要注意的是，这个备份目标不能是系统中的Brick。
平衡卷：
平衡布局是很有必要的，因为布局结构是静态的，当新的bricks 加入现有卷，新创建的文件会分布到旧的bricks 中，所以需要平衡布局结构，使新加入的bricks 生效。布局平衡只是使新布局生效，并不会在新的布局移动老的数据，如果你想在新布局生效后，重新平衡卷中的数据，还需要对卷中的数据进行平衡。
当扩展或者缩小卷之后，需要重新在服务器直接重新平衡一下数据，重新平衡的操作被分。
为两个步骤：
1)、Fix Layout
修改扩展或者缩小后的布局，以确保文件可以存储到新增加的节点中。
2)、Migrate Data
重新平衡数据在新加入bricks 节点之后。
* Fix Layout and Migrate Data
先重新修改布局然后移动现有的数据(重新平衡)
#glustervolumerebalanceVOLNAMEfix-layoutstart
#glustervolumerebalanceVOLNAMEmigrate-datastart
也可以两步合一步同时操作
#gluster volume rebalance VOLNAME start
#gluster volume rebalance VOLNAME status //可以在在平衡过程中查看平衡信息。
#glusterv olume rebalance VOLNAME stop //也可以暂停平衡，再次启动平衡的时候会从上次暂停的地方继续开始平衡。
I/O 信息查看：
Profile Command 提供接口查看一个卷中的每一个brick 的IO 信息
#gluster volume profile VOLNAME start //启动profiling，之后则可以进行IO信息查看
#gluster volume profile VOLNAME info //查看IO信息，可以查看到每一个Brick的IO信息
#gluster volume profile VOLNAME stop //查看结束之后关闭profiling功能
Top监控：
Top command 允许你查看bricks 的性能例如：read, write, fileopen calls, file read calls, file,write calls,directory open calls, and directory real calls
所有的查看都可以设置top 数，默认100
#glustervolumetopVOLNAMEopen[brickBRICK-NAME][list-cntcnt]//查看打开的fd
#glustervolumetopVOLNAMEread[brickBRICK-NAME][list-cntcnt]//查看调用次数最多的读调用
#glustervolumetopVOLNAMEwrite[brickBRICK-NAME][list-cntcnt]//查看调用次数最多的写调用
#glustervolumetopVOLNAMEopendir[brickBRICK-NAME][list-cntcnt]//查看次数最多的目录调用
#glustervolumetopVOLNAMEreaddir[brickBRICK-NAME][list-cntcnt]//查看次数最多的目录调用
#glustervolumetopVOLNAMEread-perf[bsblk-sizecountcount][brickBRICK-NAME][list-cntcnt]//查看每个Brick的读性能
#glustervolumetopVOLNAMEwrite-perf[bsblk-sizecountcount][brickBRICK-NAME][list-cntcnt]//查看每个Brick的写性能
性能优化配置选项：
glustervolumesetarch-imgcluster.min-free-disk默认是10%磁盘剩余告警
glustervolumesetarch-imgcluster.min-free-inodes默认是5%inodes剩余告警
glustervolumesetimgperformance.read-ahead-page-count8默认4，预读取的数量
glustervolumesetimgperformance.io-thread-count16默认16io操作的最大线程
glustervolumesetarch-imgnetwork.ping-timeout10默认42s
glustervolumesetarch-imgperformance.cache-size2GB默认128M或32MB，
glustervolumesetarch-imgcluster.self-heal-daemonon开启目录索引的自动愈合进程
glustervolumesetarch-imgcluster.heal-timeout300自动愈合的检测间隔，默认为600s#3.4.2版本才有
glustervolumesetarch-imgperformance.write-behind-window-size256MB#默认是1M能提高写性能单个文件后写缓冲区的大小默认1M
其它类型卷的使用及操作命令
分布式复制卷，机器数最少需要replica 的整数倍，如果指定 replica 2，则最少也需要 4 台机器：
gluster volume create volumeName replica 2 transport tcp node1:/data node2:/data node3:/data node4:/data
条带卷，将文件切割成数据块，分别存储到 stripe x 个节点中。
gluster volume create volumeName stripe 2 transport tcp node1:/data node2:/data
分布式条带卷，机器数最少需要stripe 的整数倍，如果指定 stripe 2 ，则最少需要 4 台机器：
gluster volume create volumeName stripe 2 transport tcp node1:/data node2:/data node3:/data node4:/data
条带复制卷，机器数最少需要stripe+ replica台 ，指定 stripe 2 ，replica 2，则需要 4 台机器：
gluster volume create volumeName stripe 2 replica 2 transport tcp node1:/data node2:/data node3:/data node4:/data
分布式条带复制卷，机器数需要是stripe+ replica 的整数倍，如果指定 stripe 2 ，replica 2，的话，就最少需要 8 台机器：
gluster volume create volumeName stripe 2 replica 2 transport tcp node1:/data node2:/data node3:/data node4:/data node5:/data node6:/data node7:/data node8:/data
查看所有卷：
gluster volume list
停止某个卷：
gluster volume stop volumeName
删除某个卷：
gluster volume delete volumeName
需要同时删除该卷下的 .glusterfs/ .trashcan/ 目录。
移除某个主机节点：
gluster peer detach node3
设置某个卷的 ip 访问限制：
gluster volume set volumeName auth.allow 10.6.0.*,10.7.0.*
为某个已经存在的卷添加节点，如果是复制卷或者条带卷，每次添加的 Brick 数必须是 replica 或者 stripe 的整数倍：
gluster volume add-brick volumeName node4:/data
为某个已经存在的卷移除节点，注意移除后剩余的机器需要能保证大于等于最小机器数：
gluster volume remove-brick volumeName node4:/data
参数调优
1.定磁盘使用配额
开启配额：
gluster volume quota volumeName enable
限制最大使用 100G：
gluster volume quota volumeName limit-usage / 100GB
2.开启异步操作
gluster volume set volumeName performance.flush-behind on
3.调整 io 线程的数量
gluster volume set volumeName performance.io-thread-count 32
4.使用缓存
# 设置缓存大小
gluster volume set models performance.cache-size 4GB
# 开启回写，先写到缓存，再刷到磁盘
gluster volume set models performance.write-behind on
最新版本：3.10
主要是 bug 修复，还包括了libgfapi支持结合NFS Ganesha。
官方主页：https://www.gluster.org/