GlusterFS 4.0开发计划解读

GlusterFS社区最近给出了 4.0的开发计划，其目标是对3.x版本在扩展性和易操作性方面作出重大改进，支持10K节点的集群扩展能力。为此，GlusterFS将在系统架构、控制平面和数据平面的内部机制、命令行工具和接口等方面作全新的重构，以实现更大的扩展性和易用性，期望使得GlusterFS成为倍受用户青睐的分布式文件系统。

GlusterFS 4.0开发计划主要涉及管理平面和数据平面两大部分，管理平面改进包括资源池管理、简化卷管理、灵活副本、卷内部机制、简化卷操作、卷配置数据管理、REST管理API、统一管理、透明驱动器迁移等方面，数据平面改进包括弹性Hash算法2.0、廋原生客户端和Stripe 2.0等。在这些重大改进中，我个人认为产生积极影响的是资源池管理、灵活副本、卷配置数据管理、弹性Hash 2.0和Stripe 2.0等五个新特性。

资源池管理
Xlator是GlusterFS最为核心的概念，按照特定拓扑结构组织的一组xlator可以构建出用户可访问的存储空间，即GLusterFS的卷，也就是一个分布式文件系统。GlusterFS使用卷配置文件来表示拓扑构造，早先版本需要人工编辑生成该文件，3.0之后引入Gluster工具来简化卷管理工作。使用gluster工具创建卷，需要按照卷类型指定brick列表和顺序，当卷包含的brick数量很大时，比如节点规模达到1000以上，操作非常不便且很容易产生失误。因此，4.0计划引入新的管理方式，采用函数编程式的声明方法，声明资源属性并定义操作目标，以更加适合人类思维模式的方式管理资源，简化管理和提高效率。

灵活副本
复制卷和条带卷模式下，扩展卷必须以复制和条带的倍数进行节点扩展，这个在处理卷扩展时极为不方便。4.0计划引入两个特性，一个是复制数和条带数可动态改变，二是同一个卷中不同子目录可以设置不同的复制数和条带数。如此，用户可以根据实际需求动态调整复制卷和条带卷设置，管理便利，而且可以提高存储资源利用率。

卷配置数据管理
GlusterFS 3.x中，配置信息在所有节点之间是同步的，也就是说所有节点都是对等的，每个节点都保存有全部的节点和卷配置信息。这种机制下，要求两两节点之间都要建立长连接的通信链路，集群规模扩展会大大受限于此。4.0引入超节点的概念和etcd服务，比如每个机架Rack为一个超节点，选举其中一个节点作为代表节点，多个Rack就会选举出多个代表节点并组建成一个quorum集群，存储所有的配置数据。代表节点之间按照之前的规则进行配置数据同步，Rack中的节点从本Rack代表节点处获得配置信息。由于代表节点组成的quorum集群规模远远小于整个集群规模，因此系统扩展能力大大增强。同时，管理服务进程工作也得到一定解放，不用再负责配置信息同步，而转为重点负责存储智能管理、系统监控和brick进程管理等工作。

弹性Hash 2.0
当前DHT Xlator在所有brick上维护相同的命名空间目录结构，lookup时需要与所有brick交互通信，实际上这是GluserFS扩展到10K节点的最大限制因素。4.0引入一个种全新的方法来消除这种限制，它选择一个brick子集(一个或多个)来存储目录结构，仅存储分配有GFID的目录，而不存储任何文件，这样的节点称为框架节点。目录结构覆盖整个命名空间，目录下的文件通过hash算法分散到不同节点上。对于每一个目录，每个节点会在偏平命名空间下创建一个对应的目录描述文件，采用UUID方式的ASCII编码GFID命名。ls列目录时，首先从框架节点上获得所有子目录，然后从所有数据节点获取文件列表，从而获得完整的目录文件列表。数据节点上也会保存文件对应子目录的列表项文件，当框架节点不可用时，可以用数据节点上获取子目录列表。这种模式下，扩展目录独立于父目录或子目录，服务器的扩展数量远高于目前集群可达的规模。框架节点不会产生新的负载，实际上当前系统中已经随处存在(比如复制卷和锁节点)，这样我们可以把负载从N个节点减少到一个节点。此外，这种方式还可带来诸如以下的其他更多好处。
(1)由于每个目录是完全独立的，按目录级别设置复制实现难度大大降低；
(2)数据节点上的偏平目录可以按需进行创建，当首次文件名hash到节点时创建；
(3)框架目录结构可以存储在SSD固态硬盘上，或者使用大缓存，以加速目录结构访问；
(4)框架目录结构能够存储所有节点的hash范围，可以有效避免lookup扇出；
(5)框架节点上目录访问记帐(如访问时间、文件大小、文件数量等)，相比在数据节点上处理，会避免大量的重复操作。

Stripe 2.0
GlusterFS处理超大文件的方法不够明智，一个文件大小可能增长超过一个brick容量。GlusterFS可以使用stripe进行条带化存储，但不够灵活，不可能混合存储条带化的文件和非条带化的文件。在大数据或hadoop应用下，超大文件是正常现象，这就限制了GlusterFS适用范围。4.0计划提出使用Shard xlator替换原先的条带，初始情况下所有文件都正常创建，当文件增长每超过预先设置的阈值(如64MB)，则按照特定 规则生成一个新文件，比如依据GFID和块索引号命名。这种模式下，所有数据块仍然按正常的Hash方式分布，扩展节点不需要按照之前的条带倍数进行，大文件的自修复拆分成多个较小文件在多个节点之间并发进行，数据块文件名命名模式不受重命名和硬链接影响。