云存储中元数据管理研究与优化路径

(整期优先)网络出版时间:2018-12-22
/ 2

云存储中元数据管理研究与优化路径

张新阳李申章

(云南电网有限责任公司信息中心云南昆明650217)

摘要:云存储由于具备存储管理智能化、存储效率高效化和资源利用集约化等特点,在数据备份、灾难恢复等方面得到了广泛应用。为了进一步提高系统的整体查询速度,云存储中的元数据和数据被相互分离,并独立管理。但是当系统中小文件数量过多时,存储元数据的主节点性能由于不能满足小文件处理需求,容易造成系统运行性能的降低。本文首先概述了云存储环境下元数据管理的基本流程和存在的常见问题,随后分别从元数据数量和结构两方面提出了优化措施,最后结合实验对该优化设计方案的可行性进行了验证。

关键词:云存储;元数据;管理流程;优化路径

引言

现阶段云存储中常见的架构方式主要分为两种,既主从架构和对等架构。以主从架构为例,每个系统中有唯一的主节点,本质上相当于一个独立的存储器。所有的元数据都被存储到主节点中。当系统中同时出现大量的小文件时,由于主节点的上传或下载速率是有限的,容易出现拥堵现象。目前解决主从架构节点拥堵问题的常见方式是增加存储器,及变相增加了主节点的数量。但是这种解决方法增加云存储成本,且影响系统运行效率。因此,探究一种元数据优化管理的新策略就显得十分必要。

一、云存储中元数据管理的基本流程

1、文件读取流程

目前云储存的架构模式有多种,其中像阿里云、百度云等主流云存储均采用集中式架构。以阿里云为例,在这种模式下元数据主要以两种形式存在,一种是应用元数据,存储位置是主节点,其功能是查询、定位文件数据;另一种是系统元数据,存储位置是服务器上的磁盘或者是云数据库中,功能是根据用户查询要求,提供磁盘位置及系统文件等。文件读取分为直接读取和间接读取两种方式,系统服务器通过主节点,获取文件数据的方式,为直接读取;系统服务器需要先访问应用元数据,然后再通过控制流获取文件数据的方式,为间接读取。阿里云的云数据库中,能够提供在线缓存服务,支持PB级海量数据存储,并且提供自动归档、无限容量等服务,提高了文件读取和响应速度,进一步简化了云存储文件读取的流程,阿里云内部文件的读取流程如图1所示。

图1文件读取流程

2、元数据管理面临的问题

在云存储环境下,无论文件本身容量的大小,都会占用一定的缓存,如果小文件数量过多,会导致系统缓存占用率较高,元数据的管理效率也会受到影响。另外,在小文件输入或输出管理中,需要频繁的进行i/o操作,也会在一定程度上降低系统的吞吐上限。在元数据管理中,减少小文件元数据的一种有效方法,是先对大量小文件进行整理和归类,然后将属性相同或类似的多个小文件,存储在一个统一的大文件中。这样通过合并就大幅度减少了小文件的数量。这种元数据管理的优势在于降低了单位时间内文件系统i/o操作频率和系统响应频次,占用的系统缓存减少,为元数据管理预留出更多空间。

但是小文件合成大文件后,也面临一些新的问题。例如,每10个小文件合成1个大文件后,文件系统仍然需要在后台对这10个小文件的副本元数据进行维护。虽然占用的缓存减少了,但是对于主节点性能的要求并没有降低。相反,除了单独对小文件的元数据进行维护外,新和成的大文件也占用维护资源,实际上是增加了文件系统元数据管理的任务量。总体来看,现阶段将小文件合成大文件的元数据管理方式,并不能从根本是解决云储存中元数据管理存在的问题。

二、云存储中元数据管理的优化路径

1、分布式小文件系统元数据数量方案的优化

通过上文分析可以发现,小文件合成大文件的方式,其弊端主要在于并不能完全消除小文件占用系统资源、增加主节点运行负担的问题。基于这一问题,提出了通过缩减元数据数量以达到优化管理目的的方案。具体的优化步骤如下。

RS算法是一种前向编码方式,在算法运行过程中,可以自动检测是否存在错误。如果发现算法错误,可以直接将出现错误的算法语句标记下来,并返回程序的开始部分。在错误修复之后,再重新制定。这样即便是出现了数据丢失,也能够重新找回,保证了云存储中元数据的完整性。另外,RS算法执行过程中,每完成一个任务,会将该任务执行过程中用到的所有元数据,单独生成并存在在数据块中,将某存储文件产生的数据块数量记为q。与数据块对应的是校验块,主要用来检查和验算数据块中元数据的完整性,校验块的数量记为p,且q>p。将数据块的大小记为x,得到存储开销的计算公式为(1+p/q)×x<2x。

还是以上文中的大文件合成方式为例,每个大文件由10个小文件合成,假设现有q个源文件,则主节点中需要预留(10+1)q的元数据存储单元。按照RS算法对源文件进行冗余,不考虑单个小文件对缓存空间的影响,则主节点中需要存储的应用元数据为10q。因此,本文将一定数量的小文件合成的大文件作为一个数据块,用q个数据块(q个大文件)生成其冗余的p个校验块,由此减少主节点存储的副本应用元数据数量。主节点存储的应用元数据化简为图3.6右,图左边为小文件合成大文件后主节点应用元数据的存储,但是因为文件的冗余方式是3副本形式,则其i个文件(q个大文件)有3i个副本,应用元数据也为3i个,图右边i个文件(q个大文件)有p个校验块,但p的数量远远小于3i个副本量的元数据。

2、分布式小文件系统应用元数据结构的优化

造成主节点性能瓶颈的原因主要是存储的元数据数量及元数据信息量,上一节运用基于Vaqderpoqde矩阵的RS算法对小文件合成的大文件进行冗余,减少了应用元数据,为了进一步减少主节点存储的应用元数据数量及信息量,本文引入group概念,如图2所示,对i个小文件(q个大文件)及其所形成的p个校验块形成一个group,即这i个小文件的应用元数据及p个校验块的应用元数据形成一个group,然后将应用元数据信息交由group管理,使文件名与group形成映射关系。

图2改进后主节点元数据树形结构

在此基础上,为了进一步增加元数据存储空间,在原来使用主节点作为主要存储区域的同时,额外的引入了配套的数据节点,也可以为主节点分担一部分存储任务。数据节点并不会对主节点的管控权产生干扰影响,为了继续发挥主节点在元数据管理上的绝对控制权,本文还创新性的引进了“树形索引”的概念。这样一来,多个数据节点共用一个group管理中心,然后多个group管理中心再统一服从于主节点的管理。这样就形成了三级控制体系,保证了元数据管理系统的稳定运行。改进后的元数据管理结构如图2所示

三、云存储中元数据管理优化设计的实验分析

1、实验设计

考虑到不同服务器主节点的数据控制能力存在差异,本次实验分别选取了三组不同数量的小文件组,分别是1万、5万和10万。具体的设计步骤如下:首先,所有的小文件均为进行特殊处理,获取之后将其按数量进行分组。采用单线程传递方式,完成小文件的上传。在完成上传任务后,主节点会自动将响应信息反馈到客户端。其次,下载过程中,采用多线程下载模式,这是由于小文件在云存储元数据管理过程中,被整合成了大文件,对下载通道的性能提出了更高的要求。最后,确定文件上传和下载方式后,检查测试环境,包括测试客户端、数据节点设备、计算机等。

2、文件系统上传性能测试

在文件上传测试中,需要通过数据差异来体现文件上传性能的不同。此外,为了进一步凸显测试对比效果,本次测试中选择分布式文件系统HDFS。测试数据如表1所示。

表1文件上传性能测试数据

对SFS及HDFS采取单线程上传1-4组文件,测试文件都是小于64kb的小文件,测试文件数量递增,SFS上传文件系统的平均吞吐量如表2。结合表2可以发现,随着上传文件的增加,SFS和HDFS的文件吞吐量也在相应增加,并且单位时间内的吞吐量与文件数量保持线性关系。云存储系统的元数据管理效率得到了很好的提升。

表2SFS、HDFS上传文件系统平均吞吐量

3、文件系统下载性能测试

文件下载时,由于所有小文件通过集群管理生成为大文件,因此对于系统下载性能提出了更高的要求。为了减少下载过程中对主节点性能的占用,基于RS算法和集群管理概念,在相同的配置环境下,通过改进元数据存储方式的方法,分担主节点的文件下载压力。采用3组测试数据,文件数量分别为1万、5万和10万,对比3组数据的下载性能。根据实验结果可知,随着文件数量的增加,下载所用时间也会相应的延长,但是相比于传统的元数据管理方式,下载性能有较大幅度的提升。这是因为对于SFS文件来说,所有的元数据平均分布于主节点和数据节点中。当系统接收到下载请求后,主节点最先响应,然后与主节点同步的多个数据节点也会同时开始下载任务。由于数据节点之间相互独立,并不会干扰下载速率,也就解决了传统元数据下载中通道拥堵的问题。特别是在系统高负载的情况下,这种基于数据节点分担下载任务的优化方式,将会为用户提供更好的下载服务。

结语

在大数据和云计算广泛应用的背景下,云储存也得到了越来越多的关注。在云存储环境下,小文件系统元数据管理是需要解决的重要问题。由于元数据主要存储在主节点上,大量小文件频繁访问主节点,会造成云存储系统效率低下。本文提出的基于RS算法的元数据管理优化策略,能够先将大量的小文件整合成大文件,以集群方式再进行统一管理,这样既可以提高系统运行效率,又可以减少元数据管理中单点故障问题,对提高云存储中元数据管理的实用性也有积极意义。

参考文献:

[1]刘仲,王涌,章文嵩,等.OCFS:一种基于对象存储结构的可伸缩高性能集群文件系统[J].通讯和计算机:中英文版,2017(6):1-13.

[2]段翰聪,向小可,吕鹏程.MUSE:一种面向云存储系统的高性能元数据存储引擎[J].电子科技大学学报,2016,45(2):221-226.

[3]李锐,林艳萍,徐正全,等.空间数据存储对象的元数据可伸缩性管理[J].计算机应用研究,2014,28(12):4567-4571.