换个角度深刻理解GlusterFS（三）

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以原始数据格式（如EXT四、XFS、ZFS）存储数据，并实现多种数据自动修复机制。所以，系统极具弹性，即便离线情形下文件也能够经过其余标准工具进行访问。若是用户须要从GlusterFS中迁移数据，不须要做任何修改仍然能够彻底使用这些数据。

 

然而，数据安全成了问题，由于数据是以平凡的方式保存的，接触数据的人能够直接复制和查看。这对不少应用显然是不能接受的，好比云存储系统，用户特别关心数据安全。私有存储格式能够保证数据的安全性，即便泄露也是不可知的。GlusterFS要实现本身的私有格式，在设计实现和数据管理上相对复杂一些，也会对性能产生必定影响。

 

GlusterFS在访问文件目录时根据扩展属性判断副本是否一致，这个进行数据自动修复的前提条件。节点发生正常的故障，以及从挂载点进行正常的操做，这些状况下发生的数据不一致，都是能够判断和自动修复的。可是，若是直接从节点系统底层对原始数据进行修改或者破坏，GlusterFS大多状况下是没法判断的，由于数据自己也没有校验，数据一致性没法保证。

 

八、Cache一致性

为了简化Cache一致性，GlusterFS没有引入客户端写Cache，而采用了客户端只读Cache。GlusterFS采用简单的弱一致性，数据缓存的更新规则是根据设置的失效时间进行重置的。对于缓存的数据，客户端周期性询问服务器，查询文件最后被修改的时间，若是本地缓存的数据早于该时间，则让缓存数据失效，下次读取数据时就去服务器获取最新的数据。

 

GlusterFS客户端读Cache刷新的时间缺省是1秒，能够经过从新设置卷参数Performance.cache-refresh-timeout进行调整。这意味着，若是同时有多个用户在读写一个文件，一个用户更新了数据，另外一个用户在Cache刷新周期到来前可能读到非最新的数据，即没法保证数据的强一致性。所以实际应用时须要在性能和数据一致性之间进行折中，若是须要更高的数据一致性，就得调小缓存刷新周期，甚至禁用读缓存；反之，是能够把缓存周期调大一点，以提高读性能。

参考文章：https://blog.csdn.net/liuaigui/article/details/20941159