江苏龙网

  1. 首页 > 人文 > >

【Linux】面向海量数据的分布式用户态文件系统研究与设计( 二 )



【Linux】面向海量数据的分布式用户态文件系统研究与设计
本文插图
图3 元数据服务模块架构为了提高系统的访问效率 ， 将文件系统中所有目录和文件用一张统一的表（fs_object）来管理 ， 即用户空间里的所有文件和目录都被映射为存储系统里面的一个个对象 ， 通过关键字（is_dir）是否为0来区分文件和目录 。 每个对象的元数据信息包括对象ID、对象名、父节点ID、是否是目录、对象大小、创建时间、修改时间以及父inode号等 。 在访问请求中 ， 客户端只需要访问一张表就可以获得文件对象的所有元数据信息 ， 从而减少不必要的开销 ， 提高元数据的管理效率 。
03
数据访问设计
3.1　基于bfs-fuse的数据访问
分布式存储系统通常使用Linux系统作为硬件操作系统 ， 但Linux中文件系统中文件系统都在内核态实现 ， 文件系统功能的增加和修改在内核中需要做很大的工作量 ， 且调试起来非常复杂 ， 而fuse的出现改善了这一情况 。 fuse（用户态文件系统）是一个在用户空间实现的文件系统框架 ， 通过fuse内核模块给予支持 。 基于fuse提供的接口 ， 本文设计实现了支持对象与文件映射和文件操作的文件访问系统bfs-fuse 。 在bfs-fuse中 ， 由内核模块创建块设备/dev/fuse ， 作用是沟通用户空间进程的fuse进程和系统内核 。 来自/dev/fuse的所有请求都是通过file requests请求队列发送到内核 ， bfs-fuse从/dev/fuse中读取请求并进行处理 。 当用户态应用程序（如ls、cp、mv、rm等）发起具体请求时 ， 应用程序将文件系统操作请求发送给内核 ， 内核读取来自该设备的请求 。 内核中 ， 每一个具体的请求都包含具体文件的inode ， 内核需要解析文件路径中每一层路径的inode号进行拼接 ， 得到文件具体的inode号 ， 再根据文件的inode号从MongoDB数据库中得到文件映射在存储系统中对象的object_id ， 进而通过一致性哈希运算得到对象在分布式储存中的location地址 ， 最后从分布式系统中取出数据对象 ， 返回给用户空间的应用程序 。 它的内核调用流程如图4所示 。

【Linux】面向海量数据的分布式用户态文件系统研究与设计
本文插图
图4 bfs-fuse内核调用流程3.2　fuse组件改进在原有的分布式集群中增加fuse组件和元数据信息的管理 ， 必然会降低文件系统增删查改对象的效率 。 为了减少系统性能的损失 ， 在设计bfs-fuse时 ， 本文针对分布式存储的特性 ， 对fuse挂载组件的部分参数配置进行了如下改进 。 （1）提高页面空间大小 。 在fuse中 ， 默认请求被分配的page大小是4 kB ， 但实际中存储的文件大小通常远大于4 kB ， 使得文件写入时上下文切换频率增加 ， 降低文件读写效率 ， 故bfs-fuse中将页面空间大小修改为128 kB 。 （2）缓存文件的元数据信息 。 对于只读和查询的文件 ， 对文件的inode和dentry结构进行缓存 。 （3）数据直接I/O读写 。 对于数据需要直接落盘的应用 ， 允许应用程序跳过缓存 ， 直接将数据写入存储设备中 。
04
性能测试
本文的测试方案通过海量数量小文件读写测试和大文件读写测试两个角度模拟实际应用中的I/O需求 。 通过海量小文件的读写 ， 测试系统的性能瓶颈；通过大文件的读写 ， 测试系统的吞吐量性能 。 部署3节点分布式存储集群作为测试环境 ， 所有硬件服务器均为DELL服务器 ， 内存32 GB ， 16核CPU ， 千兆以太网 。 测试脚本通过调用linux读写接口 ， 在磁盘中创建和读写文件 ， 并返回读写时间和带宽 。
在小文件测试中 ， 分别使用1～1 024个线程 。 每个线程分别在挂载目录写入、读取100个16 kB大小的文件 ， 用来模拟现实网络中常见的小文件读写 ， 测试结果如图5所示 。
【Linux】面向海量数据的分布式用户态文件系统研究与设计


推荐阅读


上一篇：「传染病」抗疫情 保生产：互联网助力复工复产 线上业务迎来春暖花开

下一篇：#农村电商#电子商务扶贫发展新趋势