一篇学会系说分布式文件系统

文件系统，篇学是说分我们最熟悉的一项技术了，我们每天都在直接或间接的布式使用着，但说到文件系统的文件定义时，我们又会显得有点模糊。系统任何技术的篇学出现都是为了解决实际问题 ，那文件系统是说分为了解决什么问题呢 ？实质上文件系统就是为了简化用户对磁盘等存储设备使用而出现的系统管理软件，它通过将磁盘中的服务器租用布式数据进行有效的组织并以更形象的方式呈现给用户
。传统的文件文件系统如Ext4、XFS等只能在本地使用，系统而随着数据量不断增长以及资源共享等需求的篇学出现
，又孕育出了分布式文件系统这个技术。说分

1.概述

分布式文件系统（DFS）是布式分布在多个服务器节点上的存储系统，它的文件本质是通过统一多个服务节点的本地文件系统，模板下载构建一个具有统一命名的系统”联合“文件系统 。用户通过分布式文件系统提供的接口，可以像传统文件系统一样使用其中的数据 ，当用户将文件写入到分布式文件系统中  ，分布式文件系统负责将文件分割并保存在不同节点之上 ，这意味着一个文件会分布在不同的节点上，用户对这个文件的读取写入操作可以并行 ，从而提高文件的处理效率

2.元数据管理

对于分布式文件系统而言 ，最关键的难题是云计算维系数据的逻辑位置与物理位置之间的关系，我们通常将这部分数据称之为元数据 ，元数据的管理方式对整个系统的性能、扩展性及部署模型起到决定性作用 
，主流分布式文件系统的元数据管理通常有以下几个方式：

集中式元数据：大多数传统横向扩展系统都通过使用独立元数据节点来解决数据索引问题 ，元数据节点存储所有文件的名称 、位置等属性，其优点为实现简单、代价低，但是免费模板存在性能瓶颈和单点故障两个不可避免的问题 。当我们访问数据时，其元数据往往需要同步更新，随着文件数量的增加、集群规模的扩大，元数据服务将会成为制约集群规模 
、影响集群性能的一个重要因素。另外在集中式元数据架构中，元数据服务器处于极其核心的地位，一旦发生故障 ，整个系统将丢失可用性，源码库需要额外引入 。分布式元数据
：分布式元数据将元数据分布在多台服务器中
，每台服务器都可以独立提供元数据服务 
，元数据的同步在集群内部进行 ，分布式元数据解决了集中式元数据的性能瓶颈和单点故障问题，但是其使得整个系统变得更加复杂
，同时带来了不小的性能开销 。无元数据服务：无独立元数据服务的架构中 ，无论是客户端还是系统节点  ，亿华云只要知道文件的路径名和文件名
，便可依据算法来定位数据 ，由于每个节点都具备独立解决元数据问题的能力 ，因此该实现模式中没有了同步元数据的需要
，规避了所有因为元数据带来的问题 ，真正实现了系统的线性扩展，其缺点是消耗了一定的计算力 。3.GlusterFS

下面以GlusterFS为例，进一步了解分布式文件系统的架构、实现方法 
、测试方法等内容。

GlusterFS是开源的可扩展的分布式文件系统 ，它通过TCP或者InfiniBand高速网络将多个服务器上的磁盘资源有效整合在一起
 ，提供一个统一的全局命名空间。GlusterFS具有强大的横向扩展能力，可扩展至数PB空间，支持大量的客户端并发访问 ，其属于纯软件实现 ，可运行在标准服务器之上，另外其兼容POSIX，应用程序可平滑迁移。其架构如下图所示，主要由服务器端和客户端构成，所有服务器节点称为可信存储池，可信存储池甚至可以只包含1个节点，每个节点可以有多个Brick
，Brick可以是ext4、xfs 、btrfs等文件系统 ，多个Brick可以组合成数种不同类型的卷。

 图1  GlusterFS架构图 

分布式卷（Distributed Glusterfs Volume）
：此种卷以文件为单位将其分布至各个brick中，主要作用为扩展整个文件系统的空间，其数据无任何冗余保护 ，可信存储池中任何一个节点故障
，将会导致数据丢失 ，数据可靠性完全依赖于底层提供。下图是由两个brick组成的分布式卷 。

图2

复制卷（Replicated Glusterfs Volume）：复制卷为了避免分布式卷数据丢失的风险，将数据复制至其它节点中，副本数量可以在创建卷时进行指定
，复制卷的优势在于即使某一个或几个（取决于卷副本数量）Brick中的数据丢失，仍可通过剩余的Brick进行访问。下图是由三个brick组成的复制卷。

图3

分布式复制卷（Distributed Replicated Glusterfs Volume） ：此卷在分布式卷和复制卷的基础之上进行再次组合，将文件分布在多个复制卷之上，同时满足高可用及扩展性，下图为4个brick组成的2副本分布式复制卷 。

图4

分散卷（Dispersed Glusterfs Volume）：分散卷基于纠删码实现，在创建分散卷时可以通过指定冗余值来调整整个卷的可靠程度 ，它决定了在不影响数据访问的前提下，可以丢失的brick数量。下图是由6个brick组成的冗余为2的分散卷
 ，它的可用空间为所有brick空间的三分之一 ，即使有2个brick损坏，也不会影响对卷中数据的访问。分散卷在冗余度与可用容量之间提供了一个更加平衡的解决方案。

图5

分布式分散卷（Distributed Dispersed Glusterfs Volume）：和分布式复制卷类似，只是其子卷为分散卷 ，下图为6个brick组成的分布式分散卷。

图6

GlusterFS客户端实现原理：

GlusterFS原生客户端基于fuse（Filesystem in Userspace）实现 ，fuse作为Linux kernel的模块，实现VFS与用户应用之间的交互 ，让用户态文件系统成为了可能 。如下图所示，用户执行ls命令之后，请求通过glibc到达VFS,VFS将请求传递给fuse模块，最终请求由hello程序负责处理并返回结果
，原生客户端为首选的方式 。另外GlusterFS也支持NFS等访问方式 。

图7 GlusterFS客户端

4.分布式文件系统测试

功能测试

文件系统功能测试主要涉及POSIX语义的兼容性测试，包括文件读取与访问控制 、元数据操作、锁操作等功能。文件系统的POSIX语义不同 ，实现的文件系统API也不同，功能测试要能覆盖到文件系统实现的API和功能点。

非功能测试

数据一致性测试：这里的数据一致性是指，文件系统中的数据与写入前的数据保持一致 ，即写入数据与读出数据始终是一致的。数据一致，能够表明文件系统可以保证数据的完整性，不会导致数据丢失或数据错误 ，这是文件系统最基本的功能 。

部署方案测试：分布式文件系统通常都具备横向扩展的能力，能够构建大规模 、高性能的文件系统集群。针对不同应用和解决方案，文件系统部署方式会有所不同。部署方式测试需要测试不同场景下的系统部署方式 ，包括自动安装配置、卷管理、集群管理 、自动负载均衡 、高可用等 。

可用性测试 ：高可用是分布文件系统必须提供特性之一 ，以保证业务的连续性 。分布式文件系统可用性主要包括元数据服务和数据两部分，元数据服务高可用性通常采用Failover机制或集群 ，数据可用性主要包括Replication、纠删码等机制。文件系统高可用性非常关键
，需要严格进行测试和验证。

扩展性测试 ：弹性扩展能力对于分布式文件系统尤为重要。文件系统扩展性测试，主要包括测试系统的弹性扩展能力（扩展与回缩两方面） ，以及扩展过程中带来的性能影响 ，验证是否具有线性扩展能力 。

稳定性测试：分布式文件系统一旦上线运行，通常都是不间断长期运行，稳定性的重要性不言而喻。稳定性测试主要验证系统在长时间（7/30/180/365x24）运行下 ，系统是否仍然能够正常运行 、功能是否正常 。

性能测试 ：性能是评估一个分布式文件系统的关键维度 ，根据文件系统在不同场景下的性能表现，可以判断文件系统是否适合特定的应用场景，并为系统性能调优提供依据
。另外当系统过载时 ，系统就有可能出现性能下降 、功能异常、拒绝访问等问题 。性能测试要验证系统在大压力下，包括数据多客户端、高OPS压力
、高IOPS/吞吐量压力
，系统是否仍然能够正常运行、功能是否正常 、系统资源消耗情况 ，从而为生产运营提供依据
。

测试案例

性能测试

FIO是一个开源的IO压力测试和验证的工具，可以模拟生成不同类型的I/O负载。IO负载通常可以分为顺序与随机读写两大类。分布式文件系统典型的测试场景及作业生成如下所示（以4K为例）：

图8

测 试 实 验

本测试环境用10个节点组成一个存储池，在其基础之上构建一个8+2的disperse-volume（图9所示） ，IO模型选取rand_rw_70read_4k ，测试数据输出如图10（篇幅有限 ，省略了部分输出信息）。

图9

图10

根据测试结论所示
， randrw_70read_4k的负载模型工作在disperse-volume上，性能表现得并不是很好。不同的IO负载类型以及不同的卷类型，得出的测试数据会有比较大的偏差，实际工作中需依据实际的应用需要进行多种场景的组合测试，寻找出最适合自己的解决方案 。

总结

本文介绍了分布式文件系统的一些基本概念，并以GlusterFS为例详细说明分布式文件系统的一些原理，最后介绍了分布式文件系统的测试思路，由于篇幅有限 ，一些技术细节并未展开详细说明，对于分布式文件系统的使用中应充分考虑当前基础架构以及应用场景等因素  ，谨慎合理选择 。