共计 7963 个字符，预计需要花费 20 分钟才能阅读完成。
概述
GlusterFS (Gluster File System) 是一个开源的分布式文件系统，次要由 Z RESEARCH 公司负责开发。GlusterFS 是 Scale-Out 存储解决方案 Gluster 的外围，具备弱小的横向扩大能力，通过扩大可能反对数 PB 存储容量和解决数千客户端。GlusterFS 借助 TCP/IP 或 InfiniBand RDMA 网络将物理散布的存储资源汇集在一起，应用繁多全局命名空间来治理数据。GlusterFS 基于可重叠的用户空间设计，可为各种不同的数据负载提供优异的性能。
GlusterFS 总体架构与组成部分如图 1 所示，它次要由存储服务器（Brick Server）、客户端以及 NFS/Samba 存储网关组成。不难发现，GlusterFS 架构中没有元数据服务器组件，这是其最大的设计这点，对于晋升整个零碎的性能、可靠性和稳定性都有着决定性的意义。
GlusterFS 反对 TCP/IP 和 InfiniBand RDMA 高速网络互联。
客户端可通过原生 GlusterFS 协定拜访数据，其余没有运行 GlusterFS 客户端的终端可通过 NFS/CIFS 标准协议通过存储网关拜访数据（存储网关提供弹性卷治理和拜访代理性能）。
存储服务器次要提供根本的数据存储性能，客户端补救了没有元数据服务器的问题，承当了更多的性能，包含数据卷治理、I/O 调度、文件定位、数据缓存等性能，利用 FUSE（File system in User Space）模块将 GlusterFS 挂载到本地文件系统之上，实现 POSIX 兼容的形式来拜访零碎数据。
根底术语
Brick: 最根本的存储单元，示意为 trusted storage pool 中输入的目录，供客户端挂载用。
Volume: 一个卷。在逻辑上由 N 个 bricks 组成。
FUSE: Unix-like OS 上的可动静加载的模块，容许用户不必批改内核即可创立本人的文件系统。
Glusterd: Gluster management daemon，要在 trusted storage pool 中所有的服务器上运行。
POSIX: 一个规范，GlusterFS 兼容。
卷类型
为了满足不同利用对高性能、高可用的需要，GlusterFS 反对 7 种卷，即 distribute 卷、stripe 卷、replica 卷、distribute stripe 卷、distribute replica 卷、stripe Replica 卷、distribute stripe replica 卷。其实不难看出，GlusterFS 卷类型实际上能够分为 3 种根本卷和 4 种复合卷，每种类型的卷都有其本身的特点和实用场景。
GlusterFS 集群的模式只数据在集群中的寄存构造，相似于磁盘阵列中的级别。
1、分布式卷（Distributed Volume）
又称哈希卷，近似于 RAID0，文件没有分片，文件依据 hash 算法写入各个节点的硬盘上，长处是容量大，毛病是没冗余。
创立卷指令如下：
gluster volume create test-volume server1:/exp1 server2:/exp2 server3:/exp3 server4:/exp42、复制卷（Replicated Volume）
相当于 raid1，复制的份数，决定集群的大小，通常与分布式卷或者条带卷组合应用，解决前两种存储卷的冗余缺点。毛病是磁盘利用率低。
复本卷在创立时可指定复本的数量，通常为 2 或者 3，复本在存储时会在卷的不同 brick 上，因而有几个复本就必须提供至多多个 brick，当其中一台服务器生效后，能够从另一台服务器读取数据，因而复制 GlusterFS 卷进步了数据可靠性的共事，还提供了数据冗余的性能。
创立卷指令如下：
gluster volume create test-volume replica 2 transport tcp server1:/exp1 server2:/exp23、分布式复制卷（Distributed Replicated Volume）
分布式复制 GlusterFS 卷联合了分布式和复制 Gluster 卷的特点，看起来相似 RAID10，但其实不同，RAID10 其实质是条带化，但分布式复制 GlusterFS 卷则没有。
创立卷指令如下：
gluster volume create test-volume replica 2 transport tcp server1:/exp1 server2:/exp2 server3:/exp3 server4:/exp44、条带卷（Striped Volume）
相当于 raid0，文件是分片平均写在各个节点的硬盘上的，长处是分布式读写，性能整体较好。毛病是没冗余，分片随机读写可能会导致硬盘 IOPS 饱和。
创立卷指令如下：
gluster volume create test-volume stripe 2 transport tcp server1:/exp1 server2:/exp25、分布式条带卷（Distributed Striped Volume）
当单个文件的体型非常微小，客户端数量更多时，条带卷曾经无奈满足需要，此时将分布式与条带化联合起来是一个比拟好的抉择。其性能与服务器数量无关。
创立卷指令如下：
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工作流程
数据拜访流程
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 存储时，首先程序通过拜访挂载点的模式读写数据，对于用户和程序而言，集群文件系统是通明的，用户和程序基本感觉不到文件系统是本地还是在近程服务器上。读写操作将会被交给 VFS(Virtual File System)来解决，VFS 会将申请交给 FUSE 内核模块，而 FUSE 又会通过设施 /dev/fuse 将数据交给 GlusterFS Client。最初通过 GlusterFS Client 的计算，并最终通过网络将申请或数据发送到 GlusterFS Server 上;
毛病
GlusterFS（GNU ClusterFile System）是一个开源的分布式文件系统，它的历史能够追溯到 2006 年，最后的指标是代替 Lustre 和 GPFS 分布式文件系统。通过八年左右的蓬勃发展，GlusterFS 目前在开源社区活跃度十分之高，这个后起之秀曾经俨然与 Lustre、MooseFS、CEPH 并列成为四大开源分布式文件系统。因为 GlusterFS 新鲜和 KISS（KeepIt as Stupid and Simple）的零碎架构，使其在扩展性、可靠性、性能、维护性等方面具备独特的劣势，目前开源社区风头有压倒之势，国内外有大量用户在钻研、测试和部署利用。
当然，GlusterFS 不是一个完满的分布式文件系统，这个零碎本身也有许多不足之处，包含家喻户晓的元数据性能和小文件问题。没有广泛实用各种利用场景的分布式文件系统，通用的意思就是统统不能用，四大开源零碎不例外，所有商业产品也不例外。每个分布式文件系统都有它实用的利用场景，适宜的才是最好的。这一次咱们反其道而行之，不再谈 GlusterFS 的各种长处，而是深刻谈谈 GlusterFS 当下的问题和有余，从而更加深刻地了解 GlusterFS 零碎，冀望帮忙大家进行正确的零碎选型决策和躲避利用中的问题。同时，这些问题也是 GlusterFS 钻研和研发的很好切入点;
- 元数据性能
GlusterFS 应用弹性哈希算法代替传统分布式文件系统中的集中或分布式元数据服务，这个是 GlusterFS 最外围的思维，从而取得了靠近线性的高扩展性，同时也进步了零碎性能和可靠性。GlusterFS 应用算法进行数据定位，集群中的任何服务器和客户端只需依据门路和文件名就能够对数据进行定位和读写访问，文件定位可独立并行化进行。
这种算法的特点是，给定确定的文件名，查找和定位会十分快。然而，如果当时不晓得文件名，要列出文件目录（ls 或 ls -l），性能就会大幅降落。对于 Distributed 哈希卷，文件通过 HASH 算法扩散到集群节点上，每个节点上的命名空间均不重叠，所有集群独特形成残缺的命名空间，拜访时应用 HASH 算法进行查找定位。列文件目录时，须要查问所有节点，并对文件目录信息及属性进行聚合。这时，哈希算法基本施展不上作用，绝对于有核心的元数据服务，查问效率要差很多。
从接触的一些用户和实际来看，当集群规模变大以及文件数量达到百万级别时，ls 文件目录和 rm 删除文件目录这两个典型元数据操作就会变得十分慢，创立和删除 100 万个空文件可能会花上 15 分钟。如何解决这个问题呢？
咱们倡议正当组织文件目录，目录档次不要太深，单个目录下文件数量不要过多；增大服务器内存配置，并且增大 GlusterFS 目录缓存参数；网络配置方面，倡议采纳万兆或者 InfiniBand。从研发角度看，能够思考优化办法晋升元数据性能。比方，能够构建全局对立的分布式元数据缓存零碎；也能够将元数据与数据从新拆散，每个节点上的元数据采纳全内存或数据库设计，并采纳 SSD 进行元数据长久化。
- 小文件问题
实践和实际上剖析，GlusterFS 目前次要实用大文件存储场景，对于小文件尤其是海量小文件，存储效率和拜访性能都体现不佳。海量小文件 LOSF 问题是工业界和学术界公认的难题，GlusterFS 作为通用的分布式文件系统，并没有对小文件作额定的优化措施，性能不好也是能够了解的。
对于 LOSF 而言，IOPS/OPS 是要害性能掂量指标，造成性能和存储效率低下的次要起因包含元数据管理、数据布局和 I / O 治理、Cache 治理、网络开销等方面。从实践剖析以及 LOSF 优化实际来看，优化应该从元数据管理、缓存机制、合并小文件等方面开展，而且优化是一个系统工程，联合硬件、软件，从多个层面同时着手，优化成果会更显著。GlusterFS 小文件优化能够思考这些办法，这里不再赘述，对于小文件问题请参考“海量小文件问题综述”一文。
- 集群管理模式
GlusterFS 集群采纳全对等式架构，每个节点在集群中的位置是齐全对等的，集群配置信息和卷配置信息在所有节点之间实时同步。这种架构的长处是，每个节点都领有整个集群的配置信息，具备高度的独立自治性，信息能够本地查问。但同时带来的问题的，一旦配置信息发生变化，信息须要实时同步到其余所有节点，保障配置信息一致性，否则 GlusterFS 就无奈失常工作。在集群规模较大时，不同节点并发批改配置时，这个问题体现尤为突出。因为这个配置信息同步模型是网状的，大规模集群不仅信息同步效率差，而且呈现数据不统一的概率会减少。
实际上，大规模集群治理应该是采纳集中式治理更好，不仅治理简略，效率也高。可能有人会认为集中式集群治理与 GlusterFS 的无核心架构不协调，其实不然。GlusterFS 2.0 以前，次要通过动态配置文件来对集群进行配置管理，没有 Glusterd 集群治理服务，这阐明 glusterd 并不是 GlusterFS 不可或缺的组成部分，它们之间是松耦合关系，能够用其余的形式来替换。从其余分布式系统治理实际来看，也都是采纳集群式治理居多，这也算一个佐证，GlusterFS 4.0 开发计划也体现有向集中式治理转变的趋势。
- 容量负载平衡
GlusterFS 的哈希散布是以目录为根本单位的，文件的父目录利用扩大属性记录了子卷映射信息，子文件在父目录所属存储服务器中进行散布。因为文件目录当时保留了散布信息，因而新增节点不会影响现有文件存储散布，它将从此后的新创建目录开始参加存储散布调度。这种设计，新增节点不须要挪动任何文件，然而负载平衡没有平滑解决，老节点负载较重。GlusterFS 实现了容量负载平衡性能，能够对曾经存在的目录文件进行 Rebalance，使得新近创立的老目录能够在新增存储节点上散布，并可对现有文件数据进行迁徙实现容量负载平衡。
GlusterFS 目前的容量负载平衡存在一些问题。因为采纳 Hash 算法进行数据分布，容量负载平衡须要对所有数据从新进行计算并调配存储节点，对于那些不须要迁徙的数据来说，这个计算是多余的。Hash 散布具备随机性和平均性的特点，数据从新散布之后，老节点会有大量数据迁入和迁出，这个多出了很多数据迁徙量。绝对于有核心的架构，堪称节点一变而动全身，减少和删除节点减少了大量数据迁徙工作。GlusterFS 应该优化数据分布，最小化容量负载平衡数据迁徙。此外，GlusterFS 容量负载平衡也没有很好思考执行的自动化、智能化和并行化。目前，GlusterFS 在减少和删除节点上，须要手工执行负载平衡，也没有思考以后零碎的负载状况，可能影响失常的业务拜访。GlusterFS 的容量负载平衡是通过在以后执行节点上挂载卷，而后进行文件复制、删除和改名操作实现的，没有在所有集群节点上并发进行，负载平衡性能差。
- 数据分布问题
Glusterfs 次要有三种根本的集群模式，即分布式集群(Distributed cluster)、条带集群(Stripe cluster)、复制集群(Replica cluster)。这三种根本集群还能够采纳相似沉积木的形式，形成更加简单的复合集群。三种根本集群各由一个 translator 来实现，别离由本人独立的命名空间。对于分布式集群，文件通过 HASH 算法扩散到集群节点上，拜访时应用 HASH 算法进行查找定位。复制集群相似 RAID1，所有节点数据完全相同，拜访时能够抉择任意个节点。条带集群与 RAID0 类似，文件被分成数据块以 Round Robin 形式散布到所有节点上，拜访时依据地位信息确定节点。
哈希散布能够保证数据分布式的均衡性，但前提是文件数量要足够多，当文件数量较少时，难以保障散布的均衡性，导致节点之间负载不平衡。这个对有核心的分布式系统是很容易做到的，但 GlusteFS 不足集中式的调度，实现起来比较复杂。复制卷蕴含多个正本，对于读申请能够实现负载平衡，但实际上负载大多集中在第一个正本上，其余正本负载很轻，这个是实现上问题，与实践不太相符。条带卷本来是实现更高性能和超大文件，但在性能方面的体现太差强人意，远远不如哈希卷和复制卷，没有被好好实现，连官网都不举荐利用。
- 数据可用性问题
正本（Replication）就是对原始数据的齐全拷贝。通过为零碎中的文件减少各种不同模式的正本，保留冗余的文件数据，能够非常无效地进步文件的可用性，防止在天文上宽泛散布的零碎节点由网络断开或机器故障等动静不可测因素而引起的数据失落或不可获取。GlusterFS 次要应用复制来提供数据的高可用性，通过的集群模式有复制卷和哈希复制卷两种模式。复制卷是文件级 RAID1，具备容错能力，数据同步写到多个 brick 上，每个正本都能够响应读申请。当有正本节点产生故障，其余正本节点依然失常提供读写服务，故障节点复原后通过自修复服务或同步拜访时主动进行数据同步。
一般而言，正本数量越多，文件的可靠性就越高，然而如果为所有文件都保留较多的正本数量，存储利用率低（为正本数量分之一），并减少文件治理的复杂度。目前 GlusterFS 社区正在研发纠删码性能，通过冗余编码进步存储可用性，并且具备较低的空间复杂度和数据冗余度，存储利用率高。
GlusterFS 的复制卷以 brick 为单位进行镜像，这个模式不太灵便，文件的复制关系不能动静调整，在曾经有正本产生故障的状况下会肯定水平上升高零碎的可用性。对于有元数据服务的分布式系统，复制关系能够是以文件为单位的，文件的不同正本动静散布在多个存储节点上；当有正本产生故障，能够从新抉择一个存储节点生成一个新正本，从而保障正本数量，保障可用性。另外，还能够实现不同文件目录配置不同的正本数量，热点文件的动静迁徙。对于无核心的 GlusterFS 零碎来说，这些看起来天经地义的性能，实现起来都是要大费周折的。不过值得一提的是，4.0 开发计划曾经在思考这方面的正本个性。
- 数据安全问题
GlusterFS 以原始数据格式（如 EXT4、XFS、ZFS）存储数据，并实现多种数据主动修复机制。因而，零碎极具弹性，即便离线情景下文件也能够通过其余规范工具进行拜访。如果用户须要从 GlusterFS 中迁徙数据，不须要作任何批改依然能够齐全应用这些数据。
然而，数据安全成了问题，因为数据是以平庸的形式保留的，接触数据的人能够间接复制和查看。这对很多利用显然是不能承受的，比方云存储系统，用户特地关怀数据安全。公有存储格局能够保证数据的安全性，即便泄露也是不可知的。GlusterFS 要实现本人的公有格局，在设计实现和数据管理上绝对简单一些，也会对性能产生肯定影响。
GlusterFS 在拜访文件目录时依据扩大属性判断正本是否统一，这个进行数据主动修复的前提条件。节点产生失常的故障，以及从挂载点进行失常的操作，这些状况下产生的数据不统一，都是能够判断和主动修复的。然而，如果间接从节点零碎底层对原始数据进行批改或者毁坏，GlusterFS 大多状况下是无奈判断的，因为数据自身也没有校验，数据一致性无奈保障。
- Cache 一致性
为了简化 Cache 一致性，GlusterFS 没有引入客户端写 Cache，而采纳了客户端只读 Cache。GlusterFS 采纳简略的弱一致性，数据缓存的更新规定是依据设置的生效工夫进行重置的。对于缓存的数据，客户端周期性询问服务器，查问文件最初被批改的工夫，如果本地缓存的数据早于该工夫，则让缓存数据生效，下次读取数据时就去服务器获取最新的数据。
GlusterFS 客户端读 Cache 刷新的工夫缺省是 1 秒，能够通过从新设置卷参数 Performance.cache-refresh-timeout 进行调整。这意味着，如果同时有多个用户在读写一个文件，一个用户更新了数据，另一个用户在 Cache 刷新周期到来前可能读到非最新的数据，即无奈保证数据的强一致性。因而理论利用时须要在性能和数据一致性之间进行折中，如果须要更高的数据一致性，就得调小缓存刷新周期，甚至禁用读缓存；反之，是能够把缓存周期调大一点，以晋升读性能。
更多技术分享浏览我的博客：
https://thierryzhou.github.io
参考
- Gluster 存储简介, 原理, 部署应用
本文由 mdnice 多平台公布