1 概述

现代科学研究中, 数据密集型的科学研究产生越来越多的数据, 科学大数据对数据采集、数据处理、数据保存、数据共享等提出了巨大的挑战^[1]. 在这种背景下, 传统的单节点数据存储显然无法满足需求, 其传输速度慢、存储周期短、灾备容错率低、传输共享性差等问题制约着海量数据的高效存储和应用. 对象存储系统以其在可伸缩性、易用性、可靠性和低成本等方面的优势而成为应对这些挑战的很有前途的解决方案, 因而得到日益广泛的应用^[2].

在中科院战略性先导科技专项地球大数据科学工程中, 提出了实现200台存储服务器节点总计20 PB存储容量的稳定、高效、安全和高可用的存储系统需求. 传统的数据存储主要依托于分布式的文件系统, 例如Lusture^[3]、GPFS^[4]、PVFS^[5]、Panasas^[6]等, 其遵循POSIX存储语义进行存储空间的组织和数据访问, 功能完备, 系统设计复杂^[7], 树状的目录便于文件的查看和管理, 但是当数据量不断增大时, 庞大的树状目录结构会给系统带来巨大的元数据管理的开销, 每次文件的读取和移动操作都需要与元数据服务器进行交互, 导致访问效率低下. 同时, 元数据与文件内容共存于同一存储物理结构内, 导致数据形式的耦合性高, 不利于存储节点的扩展. 此外, 文件系统的访问形式和传输工具也比较单一, 通过NFS或者CIFS网络协议挂载, 认证方式单一, 共享效率低下, 无法满足多种科研计算环境下的访问和获取需求.

对象存储技术自2000年左右被提出来以后^[8], 随着大数据行业的蓬勃发展, 该技术被广泛应用到各种存储需求领域, 开源领域有Ceph^[9]、Gluster^[10]和OpenStack Swift^[11]等及其成熟的对象存储底层存储项目, 这些开源项目在近些年持续高涨的火热, 也印证了该技术的可行性和科学性, 同时推动了对象存储技术的广泛应用. 在工业领域, 云计算鼻祖Amazon在2006年提出S3^[12]对象存储平台后, 彻底改变了IT存储领域. 但是在追求相对安全、扩展性和灵活性的科研存储领域, 单一地采用商业公有云存储或开源框架明显不能满足需求, 公有云对象存储服务存在安全性和扩展性方面的劣势, 开源软件则在功能服务性上过于基础化和单一化, 表1给出了两者的优缺点对比.

在大型科研领域中, 考虑到数据的绝对的安全性和私有性, 项目组一般拥有一定规模的私有物理服务器集群, 因此选择共有云对象存储无法成为有意义的方案. 针对以上需求和现状, i-Harbor结合两种存储方案的优势, 将灵活可扩展的开源对象存储框架作为底层存储引擎, 设计独立的元数据管理模块, 提供功能完善、可控性强的对象存储架构, 同时设计独立的业务管理模块、数据传输功能模块、权限认证模块等, 提供符合公有云对象存储业界标准的可定制化的服务, 增强功能可交互性, 提升产品用户体验.

综上, i-Harbor拥有以几方面的下技术优势:

(1)对象存储的核心思路是将文件中的内容和元数据进行分离, 分为控制节点+数据节点. 将数据内容以对象的形式存储到分布式的数据节点中, 此外搭建若干控制节点, 通过软件管理分布式的内容数据集群, 同时, 控制节点也存储元数据, 元数据主要负责存储对象的属性(所属数据节点、创建时间、长度大小等). 元数据与对象数据存储资源实现逻辑隔离, 降低了存储形式的耦合性, 提高了物理存储资源的利用率;

(2)对象存储结合块存储和文件存储各自的优势, 同时克服共同的缺陷. 块存储读写快, 不利于共享, 文件存储读写慢, 利于共享. 因此将数据切分为二, 元数据软件控制节点避免了树状目录在传输中的效率低的问题, 对象形式的扁平化数据内容存储提高了数据的读写效率;

(3)科研数据不仅仅需要静态稳定的存储, 也需要动态的分享和下载, 通过元数据服务器中对每个对象位置和目录结构的记录, 分散地到分布式中读取数据内容, 直接将分片好的数据内容以字节流的形式通过HTTP或FTP网络传输协议等方式获取, 极大地提高了数据的共享效率和便捷性;

(4)系统采用硬盘阵列的raid多副本技术^[13]、Ceph集群的纠删码^[14]恢复技术和元数据数据库MongoDB的副本集^[15]策略, 避免了集群单点故障, 提高了数据存储的安全性, 在实现分布式集群可扩展性的同时, 提高了集群的容灾性能.

2 系统设计

i-Harbor是一个对象存储为核心功能的分布式存储系统, 主要包含数据对象存储集群Ceph、元数据存储集群MongoDB、Web数据管理系统、FTP和HTTP传输接口、Zabbix^[16]集群参数监控系统等模块, 图1为系统整体架构设计.

2.1 业务管理系统

该模块主要负责为用户提供管理数据的主要入口, 包含用户管理、数据上传和下载、文件权限管理、数据共享等主要功能, 通过高效率的MVC开发框架Django实现. 功能逻辑上, 以bucket作为数据在物理资源的唯一划分单位, 同时也是数据上传、下载、共享的逻辑单元, 在每一个bucket内部, 用户可以创建不限量的文件夹和上传数据文件, 以此模拟出文件系统的树状目录结构, 方便用户管理和共享. 此外, 该模块实现了用户对API和FTP数据接口的权限认证和密钥获取, 方便用户在大规模批量地上传和获取数据场景下拥有稳定、高效的数据读写接口.

2.2 元数据管理

在i-Harbor系统中, 元数据负责记录用户存储的数据的具体信息, 包含名称、大小、创建时间、修改时间、所在目录等信息. 只有元数据分配更加平均, 才能使得集群资源得到充分利用, 元数据服务器之间的负载达到均衡, 从而提高系统的性能^[17]. 因此采用开源数据库MongoDB, 它是一个高性能、面向文档式的分布式架构数据库, 适用于大尺寸海量数据存储场景, 拥有高度扩展和伸缩、低容灾性的特点, 非常适合该系统.

在元数据管理模型中, 每个存储桶bucket作为一个collection, 上述具体信息作为field, 每一个document为用户上传的一个文件记录, 利用系统的ObjectId作为数据库主键, 也是该条数据在对象数据管理模型中的唯一标识, 通过它来寻找数据对象内容的具体存储地址.

i-Harbor充分利用MongoDB原生的分布式性能, 搭建主+从+仲裁节点的副本集存储集群, 避免了存储集群的单点故障, 同时, 利用sharding分片机制, 根据field特点选择对id字段进行Hash分片, 使所有document随机、均匀地分布在所有的mongod存储节点, 实现了负载均衡, 同时在增加节点时通过内部的数据迁移机制, 实现了高度扩展的分布式特点, 大大提高了存储效率.

2.3 对象数据管理

作为i-Harbor的存储核心, 对象数据存储管理依赖于开源的分布式对象存储系统Ceph. Ceph是在存储领域应用最广泛的可持续化存储系统, 主要包含对象网关RWG、块存储RBD和文件存储CephFS三大功能模块, 其底层依赖rados对象作为数据的基本存储单元, 通过每一个数据文件的唯一标识符uuid, 经过原生的crush数据寻址算法计算出所在的存储池和存储设备, 充分利用了存储节点的计算能力, 实现了高度可扩展的对象数据存储策略.

i-Harbor利用Ceph中的核心库librados, 通过内存的字节流读写, 将数据写入rados对象且从中获取数据实现文件的上传和下载. 在该模块中, 用户通过业务管理模块中的数据目录和元数据记录获取数据的唯一标识符uuid, 通过Ceph的monitor发送给OSD, 经过crush的数据寻址算法找到对应的rados存储位置, 获取对应数据并经过对应接口返回给客户端, 以此来完成数据读写的主要IO.

在该模块中, 为了保证对象数据存储的安全性, 设计了纠删码的冗余技术, 在测试实验环境中采取16+4的纠删码策略, 即在不超过五分之一的数据丢失损坏后可以利用其他完好的数据通过对应的矩阵算法恢复出丢失数据, 这种策略在保证数据安全性的同时极大的提高了资源的利用率, 同时配合实际物理环境中的raid多副本备份技术, 最大程度避免了单一故障, 提高了集群的容灾性.

2.4 数据接口管理

在业务管理系统中, 用户可以通过Web界面在线上传文件、删除文件、下载文件以及共享文件, 非常方便快捷, 但是在大规模的数据上传和下载场景下, 这种模式显然效率极低, 在科研环境中大部分的数据读写都是大批量进行的, 为此设计了API和FTP两种数据接口形式. API为RESTFul形式接口, 遵循基于HTTP协议的接口标准形式, 用户通过Token、JWT或密钥对等多种认证形式连接到i-Harbor, 进行数据的上传下载. FTP工具是基于开源的Pyftplib库实现, 用户以每个存储桶为操作单位, 通过对应的密码连接到bucket文件目录, 从而实现客户端与服务端文件同步显示的功能, 方便用户上传和下载.

2.5 其他模块

为满足整体系统健壮性, 配合以上主要模块稳定运行, 设计以下其他模块:

(1) Nginx反向代理: 将用户通过HTTP的请求按照轮询机制反向代理到集群中的django业务管理系统节点, 实现访问负载均衡;

(2) Zabbix集群监控体系: 监控所有物理节点CPU、内存运行情况和网络负载等参数, 以及MongoDB和Ceph集群各节点数据读写速率, 保证系统平台高可用性;

(3)数据归档备份: 对于超过一定年限的数据, 定时备份归档到存储成本更低的磁带库集群, 保证物理资源中高速读写硬盘的有效利用.

3 关键技术 3.1 MongoDB副本+分片集群

在2.2元数据管理模块中, 利用MongoDB分布式数据库作为元数据的存储引擎, 并依赖副本集合分片机制保证数据的安全性和均匀分布. 在i-Harbor集群环境中, 搭建了一个30个物理节点的分片键+副本集的MongoDB集群. 本节将其约分为3个节点, 介绍其中关键技术.

共3个节点, 分为3个shard, 3个节点分别为mongo01、mongo02和mongo03, mongo01和mongo02节点上包含入口服务mongos, 在mongo03节点上包含配置服务config. 由于物理磁盘已做raid多副本备份, 考虑到存储效率, 主需要一个MongoDB备服务器, 所以采用1主+1备+1仲裁的集群节点分布策略(仲裁节点负责在主服务器宕机情况下通过心跳机制将备服务器升级为主服务器), 表2给出了集群具体各个节点服务分布.

表3给出了各服务端口分配情况.

在3台节点的配置文件conf中配置好3台服务器的地址、数据目录等参数之后, 登录任意节点, 初始化副本集:

1. mongo --port 27000

2. #定义副本集配置(键“_id”对应的值必须与配置文件中的replicaction.replSetName一致, priority代表权重[1,100], 大的被分配为主服务器, 0永久不会变为主服务器)

3. config = {

4. ···_id : "shard0",

5. ······members : [

6. ·········{_id : 0, host : "mongo01:27001", priority : 1 },

7. ·········{_id : 1, host : "mongo02:27001", priority : 2 },

8. ············{_id : 2, host : "mongo03:27001", arbiterOnly:true }

9. ······]

10. ···}

11. #初始化副本集

12. rs.initiate(config)

13. #查看分区状态

14. rs.status();

初始化成功之后, 需要启用分片机制. MongoDB的分片机制共有Hash和range两种, Hash方法为随机分片, 按照分片键的值在副本集中随机分配, 利于数据均匀分布, 但是在按区间获取数据时会访问较多节点; range方法根据分片键的值按照一定的范围分布, 在分区域获取数据时可以较少地访问不同节点, 但是无法做到数据足够均衡. 考虑到在i-Harbor中, 海量数据主要以批量上传为主, 较少有大规模按范围获取, 因此选择将主键ObjectId作为分片键, Hash方法作为分片策略:

1. sh.addShard( "localhost:27 001")

2. sh.enableSharding("i-harbor")

3. sh.shardCollection("i-harbor.bucket01", { ObjectId : "hashed" } )

经过上述的关键步骤配置, 完成搭建一个副本集+分片键的MongoDB分布式高可用集群, 为元数据存储模块提供稳定的数据存储引擎.

3.2 Rados数据对象读写

在2.3对象数据管理模块中, 采用Ceph作为底层对象存储引擎, 此模块的关键在于数据从数据接口如何写入到Ceph中的OSD (Object Storage Device), 因此需要设计合理的rados对象读写IO方法. 在Ceph中有原生的对象网关协议RGW支持Amazon S3和Swift的对象存储接口, 但是其认证方法和读写策略无法满足i-Harbor需求, 因此选择直接利用librados库实现对rados的读写的中间件.

在业务管理模块中, 数据接口和Web系统由Python开发实现, 但是在官方社区中对librados的Python版本支持较为滞后, 无法与当前版本兼容, 因此该中间件基于官方社区中的go-ceph (对librados的go语言封装), 采用执行效率和开发效率更高的go语言, 实现对rados读写方法的封装, 编译为动态链接库.so, 为业务管理模块提供数据读写方法, 图2给出了该中间件结构设计.

在该中间件中, 对rados的操作主要为push、get、delete和list四种方法, 主要功能为创建并写入对象、获取对象内容、删除对象、获取对象列表, 方法介绍如下:

(1) Push: 根据oid写入rados对象, 从offset位置起, 写入长度为len, 数据内容为data;

(2) Get: 获取oid的rados对象内容, 起始位置为offset, 获取数据的长度为block;

(3) Delete: 删除oid的rados对象;

(4) List: 获取指定pool中的所有rados对象oid列表.

表4给出了其所需参数.

经过上述设计, 实现Ceph底层对象到业务系统中的数据读写的中间件. 作为一个关键数据中转站, 其在i-Harbor中承担着非常重要的角色.

4 成果总结 4.1 系统环境

在地球科学大数据先导项目课题需求下, 搭建一套完整的计算+存储+网络系统环境. 共有200台对象存储服务器, 每台服务器100 TB硬盘, 部署Ceph分布式存储系统, 承担对象数据存储任务; 20台元数据服务器, 每台服务器10 TB高速SSD固态硬盘, 部署分布式的副本集+分片制的MongoDB集群; 10台业务系统服务器, 包含Web服务、API接口服务、FTP服务和nginx反向代理服务器; 3台Zabbix监控服务. 节点间通信全部使用万兆以太网光纤.

4.2 系统成果

用户通过Web界面、API或FTP接口, 创建存储桶, 在存储桶内创建任意数量的文件夹, 然后以存储桶为单位进行数据上传, 通过Web界面, 用户可以管理FTP和API数据接口认证. 图3给出了系统Web界面效果, 用户通过Web系统, 创建和删除存储桶, 实现文件夹和文件的创建、删除和下载, 同时管理FTP和API接口的认证方式.

用户通过RESTful API的调用接口, 将数据通过成熟的HTTP协议进行上传下载, 方便在各种在线数据处理系统中调用存储桶中的数据, 图4给出API管理界面.

用户在业务管理系统中, 以存储桶为单位, 开启FTP连接, 管理FTP读写权限账户, 图5给出Windows下FTP数据接口映射说明, 用户通过网络驱动映射将某个存储桶通过FTP协议映射到本地, 实现本地浏览与线上系统同步, 方便用户进行数据上传下载.

5 结束语

针对在科研场景中海量级数据的高效率存储和数据共享需求, 本文设计并实现了i-Harbor分布式对象存储系统. 该系统以开源框架Ceph和MongoDB为对象数据和元数据存储引擎, 将整体底层架构合理解耦, 通过分布式技术实现弹性可扩展存储集群, 利用纠删码多分本等技术避免了单点故障, 保证了系统容灾性. 同时, 深度结合公有云对象存储服务, 提供丰富的多种数据读写接口, 方便用户在各种场景完成数据的批量上传下载, 同时设计合理数据共享策略, 方便用户在复杂的科研场景之下更高效的利用数据, 提升科研工作效率.

下一步将继续研究在科研场景中如何解决大数据量同时高并发上传瓶颈, 如何优化海量小文件上传这样的IO密集型任务^[18]. 同时, 为更广泛利用i-Harbor存储系统的高效服务, 需要调研在数据处理场景下对于存储平台的需求, 实现对科研数据处理任务的支持.