GlusterFS（GNUClusterFileSystem）是一个开源的分布式文件系统，它的历史可以追溯到2006年，最初的目标是取代Lustre和GPFS分布式文件系统。经过大约八年的蓬勃发展，GlusterFS目前在开源社区中非常活跃。这颗冉冉升起的新星已成为与Lustre、MooseFS和CEPH并列的四大开源分布式文件系统之一。由于GlusterFS和KISS（KeepItasStupidandSimple）系统架构的新颖性，使其在可扩展性、可靠性、性能、可维护性等方面具有独特的优势。目前开源社区铺天盖地，有大量国内外用户。研究、测试和部署应用程序。当然，GlusterFS并不是一个完美的分布式文件系统。系统本身有很多缺点，包括众所周知的元数据性能和小文件问题。不存在一种普遍适用于各种应用场景的分布式文件系统。通用意味着不能全部使用。四大开源系统也不例外，所有商业产品也不例外。每一种分布式文件系统都有其适用的应用场景，适合的才是最好的。这次我们反其道而行之，不再讲GlusterFS的各种优点，而是深入讲讲GlusterFS目前存在的问题和不足，从而更深入的了解GlusterFS系统，希望能帮助大家做出正确的系统选择决策和避免应用程序中的问题。同时，这些问题也是GlusterFS研发的一个很好的切入点。1、元数据性能GlusterFS使用弹性哈希算法来替代传统分布式文件系统中的集中式或分布式元数据服务。这就是GlusterFS的核心思想，实现了接近线性的高扩展性，提高了系统性能和可靠性。GlusterFS使用算法进行数据定位。集群中的任何服务器和客户端都可以根据路径和文件名定位和读写数据。文件位置可以独立并行化。该算法的特点是，给定一个文件名，查找和定位的速度会非常快。但是，如果你想在事先不知道文件名的情况下列出文件目录（ls或ls-l），性能会显着下降。对于Distributedhashvolumes，文件通过HASH算法分布到集群节点，每个节点上的命名空间不重叠。所有集群共同组成一个完整的命名空间，访问时使用HASH算法进行搜索定位。列出文件目录时，需要查询所有节点，聚合文件目录信息和属性。这时候hash算法根本不起作用。与中心元数据服务相比，查询效率要差很多。根据我接触过的一些用户和实践，当集群规模变大，文件数量达到一定程度时，ls文件目录和rm删除文件目录这两个典型的元数据操作会变得很慢，creatingandItmighttake15分钟删除100万个空文件。如何解决这个问题呢？建议合理组织文件目录，目录层次不宜过深，单个目录下的文件数量不宜过多；增加服务器内存配置，增加GlusterFS目录缓存参数；网络配置方面，推荐使用10G或者InfiniBand。从研发的角度来看，可以考虑优化方法来提高元数据性能。例如，可以构建全球统一的分布式元数据缓存系统；元数据和数据也可以重新分离。各节点元数据采用全内存或数据库设计，元数据持久化采用SSD。2、小文件问题的理论和实践分析表明，GlusterFS目前主要适用于大文件存储场景。对于小文件，尤其是海量小文件，存储效率和访问性能都不好。海量小文件的LOSF问题是业界和学术界公认的问题。作为一个通用的分布式文件系统，GlusterFS并没有对小文件采取额外的优化措施，性能不佳无可厚非。对于LOSF，IOPS/OPS是一个关键的性能衡量指标。性能和存储效率低下的主要原因包括元数据管理、数据布局和I/O管理、缓存管理和网络开销。从理论分析和LOSF优化实践来看，应该从元数据管理、缓存机制、小文件合并等方面进行优化，优化是一项系统工程。结合硬件和软件，同时从多个层面入手，优化效果会更好。显著地。GlusterFS小文件优化可以考虑这几种方法，这里不再赘述。小文件问题可以参考《海量小文件问题总结》一文。3、集群管理方式GlusterFS集群采用对等架构，集群中各个节点的状态完全平等，集群配置信息和卷配置信息在所有节点间实时同步。这种架构的好处是每个节点都有整个集群的配置信息，具有高度的独立性和自治性，可以在本地查询信息。但同时也存在一个问题，一旦配置信息发生变化，需要将信息实时同步到所有其他节点，以保证配置信息的一致性，否则GlusterFS无法正常工作。当集群规模较大，不同节点同时修改配置时，这个问题尤为突出。由于这种配置信息同步模型是网状的，大规模的集群不仅信息同步效率差，还会增加数据不一致的概率。其实大规模的集群管理最好还是采用集中式管理，这样不仅管理方便，效率也高。有些人可能认为集中式集群管理与GlusterFS的分散式架构不兼容，但事实并非如此。在GlusterFS2.0之前，集群的配置管理主要是通过静态配置文件，并没有Glusterd集群管理服务，可见glusterd并不是GlusterFS不可或缺的一部分。它们是松耦合的，可以用其他方法代替。.从其他分布式系统的管理实践来看，大多采用集群管理，这也证明了GlusterFS4.0的发展规划也呈现出向集中管理转移的趋势。4、容量和负载均衡GlusterFS的哈希分布是以目录为基本单位的。文件的父目录使用扩展属性记录子卷映射信息，子文件分布在父目录所属的存储服务器中。由于分布信息预先存储在文件目录中，新节点不会影响已有的文件存储分布，它会从新建的目录开始参与存储分布调度。采用这种设计，新节点不需要移动任何文件，但负载均衡不平滑，旧节点负载过重。GlusterFS实现了容量负载均衡功能，可以对已有的目录文件进行再均衡，让之前创建的旧目录分布在新的存储节点上，迁移已有的文件数据，实现容量负载均衡。GlusterFS目前在容量负载平衡方面存在一些问题。由于采用Hash算法进行数据分布，容量负载均衡需要重新计算所有数据并分配存储节点。对于那些不需要迁移的数据，这个计算是多余的。哈希分布具有随机性和均匀性的特点。数据重新分布后，大量数据会从旧节点迁入迁出，增加了数据迁移量。与中心化架构相比，可以说是节点变则全身变，增删节点增加了大量的数据迁移工作。GlusterFS应该优化数据分布，最小化容量负载平衡数据迁移。另外，GlusterFS容量负载均衡并没有考虑到执行的自动化、智能化和并行化。目前GlusterFS在增删节点时需要手动进行负载均衡，没有考虑当前系统负载，可能会影响正常的业务访问。GlusterFS的容量负载均衡是通过在当前执行节点挂载卷，然后进行文件复制、删除、重命名等操作来实现的，这些操作并不是在所有集群节点上并发进行的，负载均衡性能较差。5、数据分布问题Glusterfs主要有三种基本的集群模式，即分布式集群（Distributedcluster）、条带集群（Stripecluster）和复制集群（Replicacluster）。这三个基本簇也可以通过类似于堆叠块的方式来使用，以形成更复杂的复合簇。三个基本集群中的每一个都由翻译器实现，每个都有自己独立的命名空间。对于分布式集群，文件通过HASH算法分布到集群节点，访问时使用HASH算法进行搜索定位。复制集群类似于RAID1，所有节点的数据完全一样，可以选择任意一个节点访问。条带集群类似于RAID0。文件被划分为数据块，以RoundRobin的方式分发到所有节点。接入时根据位置信息确定节点。哈希分布可以保证数据分布的均衡，但前提是文件数量足够。当文件数量较少时，难以保证分布均衡，导致节点间负载不均衡。这对于集中式分布式系统来说很容易做到，但是GlusteFS缺乏集中调度，实现起来比较复杂。一个replicatedvolume包含多个副本，读请求可以实现负载均衡，但实际上大部分负载都集中在第一个副本上，其他副本的负载很轻。这是一个实现问题，与理论不符。Stripedvolumes最初是为了实现更高的性能和非常大的文件而设计的，但是它们的性能远不能令人满意，远不如hashedvolumes和replicatedvolumes。它们没有得到很好的实施，甚至不被官方推荐使用。6.数据可用性问题复制是原始数据的完整副本。通过对系统中的文件添加多种形式的副本，保存冗余文件数据，可以有效提高文件的可用性，避免广泛分布的系统节点出现断网或机器故障等动态不可测性。各种因素导致的数据丢失或无法访问。GlusterFS主要通过复制来提供数据的高可用，采用的集群模式有复制卷和散列复制卷两种模式。复制卷是具有容错功能的文件级RAID1。数据同步写入多个brick，每个replica可以响应读请求。当一个副本节点发生故障时，其他副本节点仍能正常提供读写服务。故障节点恢复后，会通过自愈服务或同步访问自动进行数据同步。一般来说，副本数越大，文件的可靠性越高，但如果所有文件都保存大量副本，则存储利用率低（副本数的二分之一），并且增加了文件管理的复杂性。目前GlusterFS社区正在开发纠删码功能，通过冗余编码提高存储可用性，空间复杂度和数据冗余度低，存储利用率高。GlusterFS的复制卷以块为单位进行镜像。这种模式不是很灵活，不能动态调整文件的复制关系。如果一个副本失败，系统的可用性会在一定程度上降低。对于具有元数据服务的分布式系统，复制关系可以基于文件，文件的不同副本动态分布在多个存储节点上；当副本失败时，可以重新选择存储节点生成新的副本。以保证份数和可用性。另外，不同的文件目录可以配置不同的副本数，也可以实现热点文件的动态迁移。对于非中心化的GlusterFS系统来说，要实现这些看似理所当然的功能，要花很多功夫。不过值得一提的是，4.0的开发计划已经在考虑这方面的复制特性。7、数据安全问题GlusterFS以原始数据格式（如EXT4、XFS、ZFS）存储数据，并实现了多种数据自动修复机制。因此，该系统具有极强的弹性，即使在离线状态下也可以使用其他标准工具访问文件。如果用户需要从GlusterFS迁移数据，数据仍然可以完全使用，无需任何修改。然而，数据安全成为一个问题，因为数据以一种普通的方式保存，并且可以被有权访问数据的人直接复制和查看。这对于很多应用来说显然是不能接受的，比如云存储系统，用户特别关心数据安全。私有存储格式可以保证数据的安全性，即使泄露也无从知晓。GlusterFS需要实现自己的私有格式，在设计实现和数据管理上都比较复杂，对性能也会有一定的影响。GlusterFS在访问文件目录时根据扩展属性判断副本是否一致，这是数据自动修复的前提。这些情况下的数据不一致可以在节点正常故障、挂载点正常运行时进行判断并自动修复。但是，如果直接从节点系统底层修改或销毁原始数据，GlusterFS在大多数情况下是无法判断的，因为数据本身没有经过验证，无法保证数据的一致性。8、Cache一致性为了简化Cache一致性，GlusterFS没有引入客户端写Cache，而是采用客户端只读Cache。GlusterFS采用简单的弱一致性，根据设置的过期时间重新设置数据缓存的更新规则。对于缓存的数据，客户端会定期向服务器询问文件***被修改的时间。如果本地缓存的数据早于这个时间，缓存的数据就会作废，下次读取数据的时候，会去服务端获取**数据。GlusterFS客户端读取和刷新缓存的默认时间为1秒，可以通过重新设置卷参数Performance.cache-refresh-timeout来调整。这意味着如果多个用户同时读写一个文件，一个用户更新数据，在缓存刷新周期到来之前另一个用户可能读取到非***数据，即无法保证数据的强一致性.因此，在实际应用中需要在性能和数据一致性之间进行折衷。如果需要更高的数据一致性，则必须减少缓存刷新周期，甚至可能禁用读缓存；否则，缓存周期可能会增加。以提高读取性能。
