存储优化

存储优化（共7篇）

存储优化 篇1

1 引言

存储作为道路视频监控系统的关键后端设备, 用于集中存储前端高清摄像机输出的数字视频流。由于其技术复杂, 可靠性要求高, 其造价在整个监控项目设备造价中占比较高的比重, 一般占监控设备造价的1/4~1/3。

机房中存储的配置数量取决于前端监控点位数量、存储的视频流大小、保存的天数、设备性能指标的限制、Raid方式、硬盘的盘位数量和硬盘的容量等因数。下文通过对存储系统的设计分析, 找出优化配置的突破口, 对实际案例进行优化, 体现配置微创新带来的效益。

2 存储系统介绍

监控中心存储系统采用CVR存储方式, 对前端治安监控点及卡口全景录像单元的实时视频流进行保存, 按照每秒25帧、实时存储日期为30天。

目前, 从系统的兼容性、稳定性、可靠性及高性价比角度出发, 同时考虑到保护已有的投资, 选择了基于IP网络架构的视频流直接存储方案。视频流直接存储系统, 在实现低成本数据安全集中、冗余备份的同时, 能有效提高存储资源的利用率, 减少存储用电量。

2.1 存储模式分析

1) 支持高清应用:支持百万像素级高清IP摄像机直接接入存储, 无需配置服务器做视频转发。

2) 存储可靠性高:CVR支持RAID技术, 存储服务可靠性高。

3) 灵活的录像配置方式:不同监控点可选择不同时间长度、不同录像方式进行录像, 且可动态更改。

4) 采用流式存储:可对录像文件进行流式管理, 根据需要能便利节选所需片段, 提高录像数据管理能力和效率。

5) 扩展便利:系统存储容量、前端监控点数量、接入视频专网数量可基于IP网络灵活扩展。

6) 可管理性强:基于网络实现对监控设备的统一管理;基于网络实现对监控数据统一管理。

2.2 CVR存储流

存储数据流如图1所以。

1) 存储流:高清前端的视频流可直写到CVR存储系统。

2) 实时流:流媒体服务器从高清前端获取实时视频流, 将实时视频流转发给各个客户端。

3) 回放流:客户端可直接从CVR获取回放视频流。

2.3 卡口图片存储容量计算

按照每张图片400KB, 每个车道每天通过的6000辆车来计算所需的容量。

3 存储系统设计分析

中心存储系统一般需要集中存储3种信息——车辆号牌等动态数据信息、车辆图片信息和车辆视频信息, 因数据保存时间长、数据量很大, 各类数据应根据数据类型、特点及重要性进行区别存储。对于核心数据, 应当以确保数据绝对安全及高速读写为核心目标;对于一般数据, 应当在保障数据稳定、满足存储速度和安全需求的条件下, 以降低单位容量存储成本为主要目标。同时, 存储系统设计应当充分考虑项目未来扩展的可能性, 确保在存储容量需求进一步增加的情况下, 能够简单、快速地进行系统扩容, 不得出现扩容困难或受限于系统初始设计等问题。

3.1 数据存储设计

每辆车辆的号牌等动态数据信息量为0.4KB/条, 按单车道日均6000辆流量估算, 每条车道的数据信息量按不同存储时间的容量计算公式如下:

表1为不同车道数量和不同保存时间的数据存储容量。

按照单车道日均6000辆流量估算, 不同车道规模和不同保存时间情况下的信息记录条数见表2。

对于超大数据量, 数据库软件选用Oracle 10GB正版数据库, 可支持8EB的超大数据量, 支持双机热备。

数据库存储系统选用高性能服务器, 具有数据绝对安全、对块的快速定位查询以及高速读写能力, 存储媒介使用高性能硬盘;同时, 存储系统1台数据库热备服务器用于系统级冗余备份, 热备服务器选用与数据库主服务器同系列的服务器。

3.2 图片存储设计

车辆图片信息采用JPEG编码格式, 符合ISO/IEC1544∶2000要求, 压缩因子不高于70, 200万高清摄像机输出照片文件平均大小为400KB, 按单车道日均6000辆流量估算, 每条车道的图片信息按不同存储时间的容量计算公式如下:

表3为不同车道数量和不同保存时间的数据存储容量。

3.3 视频存储设计

以每方向1台200万像素全景监控摄像机, 输出8MB码流、25fps@1920×1080分辨率视频流为例, 不同路数和不同保存时间下的存储空间如表4所示。

4 优化案例分析

4.1 存储容量的计算

以200个200万像素高清监控, 30个300万像素视频卡口, 以及海康威视的存储DS-AS82024D为例进行计算。

1) 硬盘数量

高清监控每一路的录像数据存储时间为30天, 图片数据存储为180天。实际需要的磁盘空间计算如下:

故录像需要磁盘空间为310.2TB, 图片需要磁盘空间为16.48TB。

考虑到硬盘格式化损耗10%及RAID5设置, 本项目录像实际需要24盘位磁盘阵列8台, 2T企业级硬盘数量为192块;车辆过车实际需要24盘位磁盘阵列1台, 硬盘数量14块。

2) 存储性能的核算

海康威视的存储DS-AS82024D接入前端摄像机的路数受性能指标的限制, 其路数包括录像+回放D1 (2Mbps) 240路数, 合计带宽480Mbps。

以上案例中每台存储的接入带宽平均为 (200×4+30×6) /8=122.5Mbps, 其小于480Mbps, 满足设备性能要求。

4.2 存储设备数量的优化突破口

对以上的存储设备数量的计算过程进行分析, 可看出硬盘容量作为分母, 决定着存储设备的数量;而随着超大容量硬盘的技术逐渐成熟, 4T硬盘已经开始应用, 如果采用4T硬盘, 在满足存储要求的前提下, 则存储的配置数量会减少一半。

下一步需要对存储的性能进行核算。仍按上例, 重新计算每台存储的接入带宽平均为 (200×4+30×6) /4=245Mbps, 其小于480Mbps, 同样满足设备性能要求。至此, 对存储配置数量的优化工作完毕, 使视频存储数量从8台减少一半, 变成4台, 而4T硬盘的造价则基本是2T的一倍, 这样优化后的硬盘造价基本不变, 而存储的造价则降低一半。

5 结束语

以上的优化方案已在绍兴镜湖滨海的监控系统中应用, 并顺利通过竣工验收。2014年第1期滨海新区高清治安监控租赁项目, 节约存储3台;2014年镜湖高清治安监控租赁项目和2014年第2期滨海新区高清治安监控租赁项目中, 对存储也进行了优化, 节约存储7台, 合计节约10台, 以每台采购价格6万计算, 共节约存储采购费用60余万元, 大幅度降低了工程建设成本。

存储优化 篇2

近年来,随着国内外社会信息化的发展,无论企事业单位还是政府机构对文件服务系统(指所有提供文件存储以及访问的系统)的要求越来越高,文件服务系统越来越向着专业化的方向发展,体现为网络存储、集群技术、企业文件系统以及网格技术的发展,当前云存储更成为研究与应用的热点。本文将研究分析在云存储环境下,如何有效提高文件服务效率,即提供面向通用文件服务的同时优化不同特征文件的存储。

由于众多应用环境下,现有的文件服务系统面向的是通用文件存储,并不能很好地满足一些不同特征文件的存储的需求。以小文件存储为例,由于网络监控时会产生海量的小文件,而目前的文件服务系统对于小文件存储以及访问时性能非常低下;另以多媒体文件存储为例,文件服务系统提供文件服务时并没有考虑多媒体文件读取时的特性,导致性能低下。此外当文件服务系统同时提供多种类型文件存取服务的情况下,目前的文件服务系统技术性能更是无法满足需求。

目前各种文件服务系统技术已经相对成熟,研发人员开始转向研究如何提高文件服务系统的服务效率,当前的研究方法如下:

• 采用更加高级的硬件来提高系统的性能,从而提高文件服务系统的服务效率,这却带来文件服务系统服务成本的提高;

• 采用对文件系统进行修改以适用于某类文件的存储,修改文件系统的方法可以在某种程度上提高对某类文件的服务的效率,但是导致文件服务系统的专用化,带来了文件服务系统开发成本的提高;

• 通过可堆叠文件系统/文件系统驱动来实现对文件系统的修改,可以节省大量的开发时间、减少文件系统开发的错误以及降低文件系统开发的难度。

1相关工作

1.1相关研究

国外研究人员的研究已经取得了一定的进展,主要包括:采用可堆叠文件系统实现了对文件系统的精确的有效的跟踪,该可堆叠文件系统用来提供关于文件系统评测、文件系统压力测试以及其他文件系统的分析[1];通过可堆叠文件系统来有效防止被删除的文件被非授权人员恢复[2];认为可堆叠文件系统是实现文件系统修改的最好的方法,该方法可以节省大量的开发时间、减少文件系统开发的错误并降低文件系统开发的难度[3];文献[4]采用可堆叠文件系统技术实现了一个文件系统,证明了可堆叠文件系统技术的可用性;文献[5]采用可堆叠文件系统来保证文件存储的完整性;文献[6]采用了可堆叠文件系统来实现并行虚拟文件系统,有效地提高了文件系统的吞吐能力;文献[7,8,9]同样通过采用可堆叠文件系统来实现文件系统服务的修改;文献[11]采用了可堆叠文件系统来实现新型文件系统的设计以及可堆叠文件系统在网络存储中的应用。

然而,上述研究都是面向某种特定文件类型的存储以及访问优化机制的研究,并不能满足云存储中文件服务系统对不同特征文件的文件服务的优化,仅证明了通过可堆叠文件系统/文件驱动可以有效地达到对文件系统功能的修改。对于文件服务系统同时提供对不同特征文件服务的优化,目前国内外尚未有这方面的研究,而且相关的文献资料较少。

1.2可堆叠文件系统

可堆叠文件系统是指多个文件系统堆叠在一起来完成某种任务。上层的文件系统根据具体的文件操作调用下层的文件系统执行某种操作,而下层的文件系统向上层文件系统隐藏实现的细节。层与层之间的调用是通过VFS层实现的。

可堆叠文件系统开发利用分层堆叠的vnode接口技术。通过该技术,可以允许一个vnode接口层的函数调用另一个vnode接口层的函数,实现模块化文件系统。在vnode分层堆叠接口引入之前,操作系统内核中只存在单层的vnode接口(对于Linux,就是VFS)。高层代码调用vnode接口,而vnode接口调用底层的具体的文件系统。引入vnode分层堆叠接口之后,内核中可以同时存在数个vnode接口层,它们之间可以依次调用:第N层例程可以调用第(N-1)层相应的代码,第(N-1)层可以调用第(N-2)层,如此类推。

如图1所示,通过可堆叠文件系统与常规文件系统比较可以看出,常规文件系统虚拟层和实际文件系统层是层次明显的两层结构:实际文件系统作为低层,虚拟文件系统作为高层。加入可堆叠文件系统后,系统边界增多了,可堆叠文件系统同时扮演两个角色。相对于底层文件系统而言,它是高层,相当于虚拟文件系统;相对于高层的虚拟文件系统而言,它又扮演一个普通的底层文件系统角色。

2多类型文件存储及访问优化机制

2.1系统结构

本文提出在Linux VFS和底层文件系统中间插入两层可堆叠文件系统,上层为自适应系统,在这一层上完成对下层文件系统的选取、对下层文件系统的调用、接受VFS的调用等等,将文件请求按照不同的文件类型或者不同目录,调用不同的下层可堆叠文件系统,从而执行不同的优化机制。对于上层应用来说,这两层可堆叠文件系统对应用而言则是透明的。如图2所示。

本文中提出的自适应文件系统AFS包括两层可堆叠文件系统,这里主要讨论第一层可堆叠文件系统,即自适应文件系统。AFS解决了云存储的通用性和适用性之间的矛盾,底层文件系统采用稳定可靠的文件系统,通过配置自适应文件系统来实现对存储的优化机制。当云存储作为通用存储时,自适应文件系统透明存在,对文件的所有操作起到转发作用;当希望云存储作为专用存储时,根据其存储的内容自动调用相应的第二层可堆叠文件系统,实现对存储的优化;由于可堆叠文件系统是动态挂载,当需要升级的时候,只需要升级可堆叠文件系统即可实现系统的升级,解决了文件系统升级存在的问题。

2.2实现方法选择

不同的使用者存储文件的方式不尽相同,可以按照文件的特征存放、可以按照文件的位置(逻辑分区)存放或任意存放。由此带来不同的实现方法,主要体现在第一层可堆叠文件系统调用第二层可堆叠文件系统的调用方法上,可能的调用模式有:

1) 按照文件的特征调用不同的下层文件系统 即上层文件系统接收到文件服务请求之后,主动获得文件的特征(大小、类型等),并据此动态决定所调用的下层文件系统。

2) 按照目录或逻辑分区调用不同的下层文件系统 即上层文件系统接收到文件服务请求之后,获得文件的位置信息,从而动态决定所调用的下层文件系统。这种模式下要求文件的位置和第二层可堆叠文件系统之间的对应关系必须提前确定。这种模式可以满足大多数的情况,这是由于大多数使用者都会对文件进行组织,按照不同的类型存放在不同的目录或分区里,以方便检索和使用。

3) 确定的下层文件系统 当最底层文件系统安装之后,可以确定需要存储的文件的类型,即面向特定环境使用。这种调用模式实际上是第二种调用模式的一种特例而已。

三种方案的比较结果如表1所示。

本文设计的初衷是设计适用于云存储的通用自适应文件系统,必须尽可能满足大多数的实际需要,因此决定采用第二种方法。

2.3实现细节

在Linux操作系统当中,VFS中的主要数据结构如super_block,inode,dentry,file等都有一个域可以指向文件系统自身的数据(super_block结构中为u.generic_sbp,inode结构中为u.generic_ip,dentry结构中为d_fsdata,file结构中为private_data),这是在Linux中开发可堆叠文件系统的关键。Linux自适应文件系统的各种数据结构的内容和底层文件系统(如EXT2/3)的相应结构的内容大部分都是一样的,但它的特殊指针域指向对应的底层文件系统结构。

如图3所示,inode结构、dentry结构、file结构都用它们的特殊指针域指向底层的相应结构,以便调用底层文件系统的功能。而super_block结构的指针域可以用来存放新的文件系统属性。

新文件系统的新功能体现在对各种操作的改进上,它必须提供它自己的file_operations、inode_operations等结构指定的操作函数。在可堆叠文件系统中,这些操作函数大多是通过前述的特殊指针域调用底层文件系统的相应操作而实现的。但在调用底层操作前后,可以对数据进行附加的处理(如目录封装、大文件分割、I/O重定向、加密、解密等),甚至完全替代底层操作,从而实现功能的堆叠。

3性能测试

本文对AFS进行了测试,测试环境的配置为3GHz CPU,2GB内存,Linux 2.6.12内核,Ext3文件系统,测试方法是通过编译Am-utils的时间来比较有无可堆叠层时的性能,Am-utils在编译过程中,将进行大量的文件操作,是一个很好的测试工具,测试过程中编译Am-utils共10次,统计每一次编译花费的时间并计算10次的平均值。

因为AFS采用可堆叠技术实现,所以首先需要测试加入可堆叠层后的性能开销,结果如表2所示。

第二项测试的是在加载第一层自适应文件系统层,第二层为实际数据处理系统,本文以小文件文件系统可堆叠层为例的情况下文件操作,由于篇幅有限,本文中仅给出文件创建操作和文件检索操作的测试,其他测试可以见Smallfs论文。

1) 测试了当某一目录下已经包含1个、5个、10个、50个、…、50000个、100000个文件时,在该目录下新创建1000个新文件所消耗的时间。测试结果如图4所示。

2) 测试了当某一目录下已经包含1个、5个、10个、50个、…、50000个、100000个文件时,随机地进行1000次检索操作所消耗的时间(测试了10次,取其平均值),测试结果如图5所示。

从图4可以看出,在没有加载可堆叠层时,当文件数量增大时所消耗时间也随之增大,时间增长幅度是线性的,这符合预期。AFS后,对于文件数量变化所消耗时间几乎是常数。从实现上来预测,当文件数更大时,子目录下的文件增多,在其中新建文件需要一些开销,这时AFS的消耗时间才会有小幅度增加,但是相对于没有加载AFS的性能开销来说,基本可以忽略。

从图5可以看出,文件数目较少时,由于AFS需要多一层的检索,因此性能有一定的损失。但是随着文件数目的增加,未加载AFS时的检索时间线性上升,而加载AFS后性能损失很小。虽然测试中采用随机文件检索并不能完全符合实际的应用环境,但是在文件数目较多时,加载AFS无疑使检索性能有很大的提高。

从上面的测试可以看出,加载AFS后相比未加载AFS时,性能虽然有一定的损失,但对于海量文件的情况下,各种文件操作性能均有很大提高。

4结语

本文提出的AFS,面向云存储应用环境下提高文件服务系统存储各种不同类型文件时的系统性能。AFS在保持原有文件系统的完整性和透明性的基础上,通过对Linux文件系统机制进行改进,实现对不同特征的文件(小文件、超大文件、流媒体文件、加密文件等等)的自适应和优化,有效地提高了基于Linux的云存储的文件服务的性能。本文的实现方式同样可以在其他操作系统平台上实现,包括Windows平台以及Unix平台,因此研究如何高效地存储这些具有不同特征的文件是实现文件服务系统更加高效服务的关键,可以促进云存储技术的发展,而且由于AFS同样可以应用于云计算的环境,因此AFS的研究具有非常重要的现实意义和应用价值。

参考文献

[1]Nikolai Joukov,Timothy Wong,Erez Zadok.Accurate and Efficient Re-playing of File System Traces[C]//Fourth USENIX Conference on Fileand Storage Technologies(FAST 2005),Dec,2005.

[2]Nikolai Joukov,Erez Zadok.Adding Secure Deletion to Your FavoriteFile System[C]//Third IEEE Security In Storage Workshop(SISW2005),Dec 2005.

[3]Erez Zadok,Rakesh Iyer,Nikolai Joukov,et al.On Incremental FileSystem Development[J].ACM Transactions on Storage(TOS)Maga-zine,2006(8).

[4]Charles P Wright,Jay Dave,Puja Gupta,et al.Versatility and Unix Se-mantics in Namespace Unification[J].ACM Transactions on Storage(TOS)Magazine,2005(11).

[5]Gopalan Sivathanu,Charles P Wright,Erez Zadok.General storageprotection techniques:Ensuring data integrity in storage:techniquesand applications[C]//Proceedings of the 2005 ACM workshop onStorage security and survivability StorageSS'05,November 2005.

[6]Weikuan Yu,Shuang Liang,Dhabaleswar K Panda.operating systems:High performance support of parallel virtual file system(PVFS2)overQuadrics[C]//Proceedings of the 19th annual international conferenceon Supercomputing ICS’05,June 2005.

[7]Dilma Da Silva,Livio Soares,Orran Krieger.KFS:Exploring Flexibil-ity in File System Design[C]//Brazilian Workshop on Operating Sys-tems(WSO’2004),Salvador,Brazil,August,2004.

[8]Joukov N,Rai A,Zadok E.Increasing distributed storage survivabilitywith a stackable RAID-like file system[C]//Cluster Computing andthe Grid,2005.CCGrid 2005.IEEE International Symposium on Vol-ume 1:9-12 May,2005(1):82-89.

[9]Tancred Lindholm,Jaakko Kangasharju,Sasu Tarkoma.A hybrid ap-proach to optimistic file system directory tree synchronization[C]//Proceedings of the 4th ACM international workshop on Data engineer-ing for wireless and mobile access,Jun,2005.

[10]虞云翔.嵌入式Linux系统中Overlay文件系统的实现[J].微电子学与计算机,2005(10):177-180,183.

数字图书馆数据存储系统性能优化 篇3

关键词：数字图书馆,存储系统缓存,Key value

0 引言

现代化高校的数字图书馆改变传统的纸质媒体的信息查看和传播方式而借助于网络信息技术, 传播各种以数字多媒体为存储单位的知识、文献信息, 电子文献资源、教师课件、课程视频等。数字图书馆是用数字技术处理和存储各种图文并茂文献的图书馆, 实质上是一基于种多媒体的信息分享系统。通过数字图书馆所提供的搜索功能, 提高了读者检索资源的效率;同时, 通过数字图书馆提供的web端、移动端等相关应用平台极大的提高了读者的访问便利度。数字图书馆需要大量的磁、光、电等新型存储媒介来存储文本、图像、声音、动画、影视作品等文献信息资源的数字化信息[1]。海量数据信息的存储和管理是数字图书馆的显著特征之一。数字图书馆数据信息资源的种类、数量、性质及其使用方式等均对读者访问的性能、资源的传输速度、可靠性等方面起着决定性的作用。数字图书馆具有系统用户数量庞大, 并发存取海量数据及业务类型多的特点。

数字图书馆的数据信息种类繁多, 形式复杂多样, 数据的重要性程度不一, 数据访问方式各异, 因而不同的数据类型则对读写性能等方面有不同的要求[1]。大文件的顺序读写, 如视频数据等多媒体资源, 读写数据量很大, 要求数据存储吞吐量性能高。小文件随机读, 如数字期刊、数字图书等, 资源访问频率很高, 下载流量也比较大, 对存储系统的IOPS要求很高。因此如何在复杂的数据环境中提升存储系统的I/O性能以满足数字图书馆各种数据访问的要求是一个急需要解决的问题。

因此, 针对上述问题本文提出一种适用于数字图书馆应用环境的存储系统性能优化方法KVCache, 其基本原理为将最近访问的文件保持在由高速非易失性存储介质组成的缓存层中, 下次访问相同的文件数据时则不需要再访问低速的磁盘, 直接从缓存层中得到, 以获得较高的I/O性能。该优化方法的特点主要包含以下方面:

1) 采用非易失性高速存储设备, 例如SSD, 作为存储系统的缓存层存储介质, 充分保障数据在各种应用环境下的性能[8]。

2) 采用Key-Value技术实现了缓存的持久化存储, 提升了存储系统的访问性能。

3) 利用多级存储下的两段更新事务原子性管理, 在提升存储系统I/O性能的前提下, 保证多级存储数据一致性和可靠性。

1相关研究

目前缓存对于缓存的研究主要集中在通用块层。

Flash Cache是Linux内核中的一种磁盘缓存实现模块, 于2010年由Facebook公司开发, Flash Cache的具体实现, 将请求IO以一定的哈希映射关系同时映射到闪存设备和磁盘设备中。并在读写路径中, 先请求闪存设备, 再请求磁盘设备, 从而实现了使用闪存设备对传统磁盘进行缓存的设计。磁盘与闪存之间的映射, Flash Cache使用了对磁盘以及闪存逻辑上进行条带化, 哈希映射的方式完成[5]。

BCache作为同样实现在Linux内核中的一种磁盘缓存实现, 其则是基于通用块层实现的, 与Flash Cache不同, 其实现与IO调度层之上, 可以使用更少的设备来缓存整个存储子系统的数据。同时, 由于其实现于通用块层, BCache可以有效利用闪存设备对随机IO读写的优异性能, 将随机IO组合为顺序IO再写入传统磁盘中, 大大增加了磁盘的读写能力。

块存储方案用于实现持久化缓存, 可以将缓存模型简化, 也是传统缓存模型常用的解决方案。使用块存储接口调用持久化缓存设备, 可以将设备直接与内存中的缓存块相映射, 从而快速索引持久化设备中的缓存数据。然而此方式的缺点是, 由于块存储方案存储流程非常简单, 通过对内核的系统调用实现数据的存取, 如果在写入过程中阻塞等待内核块接口的完成回调则损失了缓存性能, 而如果不阻塞等待则无法达到第一阶段写事务的原子性和可靠性要求[2]。

而基于Key-Value的方式则很好地解决了块存储方案的缺点。Key-Value的方式可以很好地完成内存与磁盘设备的映射过程, 因而逻辑视图上对于持久化缓存项和内存缓存项的映射规则简单, 模型类似块存储缓存方案;而对于更新操作的一致性和可靠性以及性能特点, 又可以超越块存储缓存方案。

2 KVCache的实现

KVCache的实现主要包括:key-Value原子更新策略、缓存数据分布与置换策略。

当更新I/O请求到达时, 需要将I/O请求通过分割成多个细颗粒度的对象请求, 并且为每个对象请求将创建一个更新事务, 如图1所示。

第一阶段的写事务将对象请求更新提交到保存在内存中的缓存目录, 并同时提交到内存缓存。完成对内存缓存的更新后, 又将根据更新的缓存目录, 将缓存写入到持久化缓存设备中。

第二阶段的写事物则是待Flush线程达到某个预设值时, 将本地缓存写回到后端存储设备中。为了保证第二阶段写事务的可靠性和一致性, 需要在第一阶段写事务完成后, 以日志形式将该事务记录在持久化缓存中, 并在第二阶段写事务完成后将该日志删除。

2.1 key-Value原子更新

KVCache中使用Level DB作为持久化缓存接口, 将对象缓存数据合并成可以并行读写, 快速索引的磁盘数据因而本文选择使用键值对存储方案Level DB来完成系统对数据的持久化缓存[4]。

Level DB是一个开源的键值对存储方案, 其使用LSM树对数据进行存储, 并利用内存暂存区设计优化了写性能, 通过将内存中数据和持久化后数据进行多级存储, 简化了索引对内存产生的开销。同时, 由于Level DB本身的键值对语义与内存缓存使用的map语义十分契合, 减少了存储接口转换带来的开销。

图2为KVCache对于更新请求结合Level DB所进行的数据流图。为了提高数据写入性能, Level DB对缓存持久化的操作其实是一个异步事务。也就是图中看到当写操作写入Level DB的memtable中后, 并不是立刻会被写入Level DB SSTable。Level DB会将多个更新操作进行合并和等待到某预设值到达, 才将数据写入imm_memtable, 并分级存储到SSTable中。但是由于Level DB本身的事务原子性管理, 系统可以完全假设当数据写入Level DB的memtable时, 即完成了对持久化缓存的写入事务, 因而系统可以向系统提交缓存更新成功响应。

本文设计了缓存目录, 用于记录与管理所有的缓存数据。缓存目录只用于记录缓存的最新版本号, 本地版本号, 后端版本号以及所在位置。缓存目录主要结构如表1所示。

通过版本号记录更新事务的状态以及是否可提供读操作。写请求映射到缓存目录后, 最新缓存版本号 (version) 首先被更新, 从而表明该缓存有更新的数据将存入, 而其余本地版本号 (lversion) 以及后端版本号 (bversion) 不同则标记了该写事务并未完成, 如图3所示。由于KVCache基于内存缓存与持久化缓存进行两级缓存, 所以当写事务已成功提交给内存缓存与持久化缓存时, 第一阶段写事务已完成。对于后端的写提交为一个新的写事务, 通过异步写操作执行。当提交给后端的写操作完成后, 缓存目录的后端版本号更新至提交该操作时的最新缓存版本号。缓存更新事件在任一状态时失败, 则可以通过缓存目录有效回滚回上一个状态点, 且重新执行该写事务, 保证了更新事务的原子性。

2.2 数据分布与置换策略

由于缓存设备的空间有限, 且内存存储空间远小于持久化设备的缓存空间, 当缓存空间不足时的换出策略则变成多级缓存的另一个重要问题。KVCache中内存缓存与持久化缓存之间采用直写策略。持久化缓存到后端采用写回策略。

KVCache使用LRU (Latest Recent Update) 替换算法来完成在缓存空间不足时的剔除管理。

由于目录缓存记录了所有在缓存中的数据, 因而系统在对象缓存数据被内存缓存LRU换出后, 并不需要因此对缓存目录进行修改;而当持久化缓存设备空间不足时, 系统则需要修改缓存目录。

KVCache通过LRU类来记录存储在内存缓存中的所有对象缓存项指针以及保存在缓存目录中的所有指针。LRU类以被更新时间作为视图, 记录被定义为LRU对象的指针列表。通过该方式, 只需要在每次更新内存缓存与更新缓存目录时, 通过将LRU指针列表中该项提到列表顶部, 则在空间不足时, 只需要将LRU对象底部指针指向的数据在缓存中删除则完成了系统的缓存替换算法。

2.3 实验与评估

实验环境基于SAN的架构, 存储设备中采用8GB的内存, 使用40GB的SSD作为KVCache的持久化缓存[3,6,7]。SAN与应用服务器采用1Gb以太网进行互联。测试模拟在数字图书馆的应用环境下的流媒体文件的顺序读写和小文件的随机读写为主的数据访问方式。

读写性能对比测试见图4。

实验结果表明, 在使用了KVCache的存储系统中, 所有压力测试节点的顺序读带宽总和为111MB/s, 顺序写带宽为113MB/s, 基本接近千兆网卡传输上限。

小文件的随机读写模拟测试通过二组数据完成: (a) 没有加入缓存系统随机读写测试。 (b) 使用300G空间进行持久化缓存随机读写测试。 (c) 使用16G内存空间进行缓存随机读写测试。

图5为模拟随机小文件写性能测试结果。横坐标为不同的客户节点, 纵坐标为每一个VM使用IOSTAT获取到的IOPS。通过对于总的IOPS计算发现, 内存缓存与SSD缓存得到了几乎相同的IOPS数。由于使用内存作为缓存的过程中, 系统内存空间上限为16G, 所以仅使用10G内存空间作为缓存。而系统的持久化缓存策略与内存缓存策略均使用写回方式, 因而内存缓存和持久化缓存获得了几乎相同的每秒吞吐量。同时可以看出由于KVCache使用了高速SSD进行缓存, I/O请求在一定范围内均在SSD中命中, 因而全面提升随机I/O的性能, 可以看到其拥有几乎仅使用HDD作为后端9倍的吞吐量。

如图6模拟随机小文件读性能上, KVCache使用SSD作为持久化缓存后的性能优势更明显。实验结果可见, 由于KVCache使用SSD作为缓存, 并且采用Keyvalue的方式进行缓存数据的更新, 使得其随机读总带宽达到26.11MB/s, 其读写性能基本上达到了内存读的性能。

3 结论

针对高校数字图书馆的多样化数据访问的应用环境, 提出了适用于数字图书馆应用环境的存储系统性能优化方法KVCache, 包括key-Value原子更新策略和数据分布与置换策略等内容。KVCache利用SSD闪存设备和key-Value技术实现缓存数据的缓存持久化存储, 并且利用多级存储下的两段更新事务原子性管理, 保证多级存储数据一致性和可靠性。

通过模拟实验表明KVCache有效的增加了存储系统中的数据在顺序读写、随机读写下的性能, 并且使其随机读写性能接近本地内存读写性能。

参考文献

[1]黎春兰, 邓仲华.信息资源视角下云计算面临的挑战[J].图书与情报, 2011 (3) :23-28.

[2]Fred Douglis and John K.Ousterhout.Beating the I/O bottleneck:A case for logstructured files systems.Technical Report UCB/CSD 88/467, University of California, Berkeley, October 1988.

[3]Howard Gobioff, Garth Gibson, and Doug Tygar.Security for network attached storage devices.Technical Report TR CMU-CS-97-185, Carniege Mellon, October 1997.

[4]Level DB.leveldb:A fast and lightweight key/value database library by Google.

[5]Alex Robson.Consistent Hashing.http://sharplearningcurve.com/blog/2010/09/27/consistenthashing/, September 2010.

[6]T.Clark.Designing Storage Area Networks:A Practical Reference for Implementing Fibre Channel and IP SANS (Second Edition) .Addison-Wesley Networking Basics Series, 2003.

存储优化 篇4

关键词：农业信息,网络存储,平台,开发

我国是一个农业大国, 物联网技术、计算机技术、互联网、网络存储技术、智能终端等技术的发展, 为农业信息化数据化的实现带来充分技术准备。调研表明, 未来数据会呈现指数增长, 越来越多的农业数据需要存储、处理及管理。农业产品的种植、生产、管理、可视和销售等环节产生的数据的类型越来越多样, 数量越来越大, 用户对农业数据信息的安全和管理能力有了更多的需求, 这对传统的存储管理平台提出了挑战。为了更好地对这些农业数据信息有效的管理和方便的使用, 需要新型农业信息网络存储来应对未来农业信息的大数据时代。

1 开发目的

开发一个既具有农业信息存储和共享服务以及安全管理等基本功能, 并且具有农业信息数据下载、远程数据管理、自动数据备份、监控存储、多媒体服务器、多合一服务器等功能的农业信息网络存储平台, 来应对未来农业信息存储越来越严峻的形势。

2 开发思路

农业信息网络存储平台将采用NAS (Network Attached Storage:网络附属存储) 存储架构, 其硬件部分将由CPU、存储模块、网络功能模块作为主要构成, 其软件部分将由核心操作系统以及相应功能的软件模块构成。

3 开发分析

由于农业信息网络存储平台采用的架构是NAS存储架构, 这种存储架构能够满足目前农业领域对网络存储系统的基本要求。下面就农业信息网络存储平台系统的开发进行分析。

3.1 设计原则

设计原则分为三点, 以保证农业信息网络存储平台数据采集和管理的可靠性、健壮性、安全性。原则如下。

第一点, 数据要满足三个基本要求, 分别为高度安全性和高度可靠性以及高度可用性。为了适应未来可以扩展的网络结构及实现对容量的增加, 农业信息网络存储平台需要支持存储网络中相关设备的增加, 且不对原有设备造成不良影响。

第二点, 在整个农业信息网络存储平台网络设计中, 数据链路的设计以及硬件的选择应该全部采用冗余架构, 以提升数据的安全性、健壮性及安全性, 来应对网络结构单点故障和计算机存储设备可能对未来存储带来的不可预见的影响。要求农业信息网络存储平台, 其设备选型要对于关键部件采用冗余配件模式, 可以随时切换配合硬件设计的双链路, 软件功能可以被数据通道利用, 可以做到在线热更换部件。

第三点, 为确保数据访问的实时性, 农业信息网络存储平台要统一管理每台主机的双链路, 能够自主侦测每条链路的完好性, 在没有用户干预的情况下, 当侦测到一条数据链路发生故障后, 可以自动切换到安全的数据链路中。此外, 为了让农业信息网络存储平台具备数据流量的负载均衡能力, 实现数据链路负载均衡, 可以通过设置链路的对立长度、应用程序优先级别等方式, 对数据传输进行优化, 以此充分发挥双数据链路的优势。

3.2 架构设计

在农业信息网络存储平台架构的设计中, 采用的NAS存储架构, 这主要是平台的硬件模块部分, 其中使用企业级的存储阵列构成存储模块的主要硬件部分, 使用具备负载均衡能力的交换机构成网络连接模块。服务器部分中的数据服务器集群使用虚拟技术来搭建, 而在应用环境中进行有效的负载均衡可以通过交换机实现。而且每一个业务应用系统都需要具备负载均衡配置, 并设置系统访问认证以及身份认证, 让服务器通过FC集线器或者交换机进行负载均衡。

在农业信息网络存储平台中, 存储阵列使用专用及快速的NAS网络交换机进行连接, 而为了提供数据除传输的高度可靠性及安全性, 存储阵列则通过数据冗余实现。存储阵列的存储空间应该根据不同的应用系统对数据量的需求来进行划分。农业信息网络存储平台使用主机柜和拓展柜对存储阵列配件进行统一存放管理, 通过存储阵列之间的LVM Mirror (卷管理器的数据镜像) 达到对本地实际的冗余备份。

为了防范数据非法操作, 实现对共享过程中及数据交流时进行监控, 农业信息网络存储平台增加了一个防火墙系统在数据交换的前后台间, 这样, 有利于提高其数据安全性。

4 整体结构

为了应对不用应用服务器及主机的访问, 农业信息网络存储平台被设计成一种数据中心, 其能将分布、独立的数据整合为大型、集中化管理的数据。农业信息网络存储平台将包括核心处理器, 一个或者多个的硬盘驱动器, 文件服务管理工具。任何的网络环境当中都可以使用农业信息网络存储平台。农业信息网络存储平台支持多种计算机平台, 如Windows、Mac、Linux电脑或移动设备, 用户通过网络支持协议可调用相同的文档, 包括NFS格式 (Unix、Linux) CIFS格式、和SMB格式 (Windows) 等。农业信息网络存储平台实现了即插即用, 其物理位置非常的灵活, 只需通过物理链路与网络连接即可使用。

4.1 硬件组成

农业信息网络存储平台强调的是存储和网络功能, 所以在构造硬件结构中只考虑存储和网络两方面的问题。农业信息网络存储平台采用CPU的型号为STM STi H412, 而除CPU关键外, 存储模块主要是提供对SCSI, IDE/EIDE, 总线技术的支持, 提供工业标准阵列控制器, SCSI控制器, EIDE控制器, 使得系统可以任意连接各种设备, 如光盘塔, 磁盘阵列等, 农业信息网络存储平台采用的存储设备是由型号HTS7210109E630的日立 (HGST) 硬盘组成的磁盘阵列。网络控制模块, 实现网络适配器的功能, 用于进行地址译码, 数据编译, 数据帧的生成、识别与传输, 硬件故障的检测及数据传输的出错检测等。为了能使系统可以方便地与以太网相连或挂接在高速光纤通道连成的SAN上, 网络控制模块提供一个高速光纤通道连接口和普通网络连接口, 提供100MB或更高的速率。农业信息网络存储平台的存储设备模块为系统提供RAM, ROM, CACHE空间, 系统核心操作系统和相关系统软件都固化在磁盘阵列上, 系统启动时可以直接引导磁盘阵列中固化的程序。

4.2 软件组成

农业信息网络存储平台需要一个核心操作系统的支持, 本平台采用群辉科技公司 (Synology Inc) 研发的Disk Station Manager 6.0操作系统。该操作系统集成了对应的设备 (如存储设备, 网络设备) 的设备驱动模块, 所以在设备驱动器上一层应该是对一些基本网络协议的支持 (如UDP/IP、SPX/IPX、TCP/IP) , 然后是对专用农业信息网络存储平台进行网络数据访问的一些文件共享协议 (如CIFS、NFS、NCP、SMB) , 在网络协议之上才是农业信息网络存储平台提供的一些网络应用, 如文件共享、远程网络管理、云端同步数据、多媒体应用、电子邮件与高效生产力、数据备份、多合一服务器、数据安全、视频监控等。

5 平台特性

采用文件级的存储方法, 农业信息网络存储平台易于向基础设施增加文件存储容量, 使文件访问操作更为快捷。因此, 其用户采其文档共享、图片共享、视频资料共享等等, 并且农业信息网络存储平台拥有云存储功能, 大大方便了企业和个人用户的使用。

农业信息网络存储平台是真正即插即用的产品。农业信息网络存储平台支持多种计算机平台, 用户通过网络支持协议可进入相同的文档, 因而农业信息网络存储平台无需改造即可用于混合Unix/Windows NT局域网内。

农业信息网络存储平台采用了专业化的操作系统用于网络文件的访问, 来提高系统性能及应对不间断的用户访问。

农业信息网络存储平台局限性之一是网络传输数据的能力, 造成这一局限性的原因是网络拥堵。农业信息网络存储平台局限性还有其存储的可扩展性受到设备大小的限制等。

6 功能及应用

农业信息网络存储平台有文件共享、云端同步数据、多媒体应用、电子邮件与高效生产力、数据备份、多合一服务器、数据安全、视频监控等功能。

6.1 功能

文件共享, 农业信息网络存储平台系统提供用户各种安全又快速的方法, 无论身在何处, 都能与任何人分享文件;云端&档案同步, 农业信息网络存储平台提供了一个符合经济效益、大容量、且完全私密的云端解决方案, 来满足用户对云端操作的需求;多媒体, 农业信息网络存储平台为照片浏览、视频观赏及音乐欣赏创造更多可能性;电子邮件与工具, 农业信息网络存储平台针对电子邮件、电子表格、笔记等工具开发崭新的生产力工具;数据备份, 农业信息网络存储平台系统为用户带来了健全而弹性的备份方案;多合一服务器, 通过农业信息网络存储平台系统的模块系统, 用户可以在需要的时间点, 依照需求在农业信息网络存储平台安装丰富、全面的功能或服务;视频监控系统, 农业信息网络存储平台的视频监控系统提供了智能监控和影像管理工具。

6.2 应用

通过农业信息网络存储平台, 农业工作者可以以文档、图片、音频、视频的方式随时共享自己的研究成果或者所遇到的问题, 当然也可以查找自己所需要的资料或帮助别人解决问题, 例如果农想要了解某种果树疾病的救治方式, 就可以通过农业信息网络存储平台搜索相关资料, 以解决问题;农业工作者可以将重要的资料上传到农业信息网络存储平台的私人云空间中;在农业信息网络存储平台上的数据无须担心, 因为平台已经做好备份;通过农业信息网络存储平台的视频监控系统, 农业工作者可以随时随地观看来自多支IP摄像机的实时视频、回播录像, 例如农业工作者出差去外地, 可以通过视频监控系统随时监控生长果蔬情况, 并且可以记录农业工作者不在时段的影象, 以方便查找某些问题的原因。

7 总结

浅谈企业数据中心的存储性能优化 篇5

随着经济全球化和信息国际化, 信息技术逐渐成为了企业改进作业流程、降低成本、提高竞争力的强有力手段。信息化的建设中心总是围绕着应用的交付和数据中心的建设两个方面。近年, 连云港港先后建成使用了二十余个大型信息系统:集装箱管理系统、散杂货公司调度与商务系统、港口货源信息系统、港口计划统计系统、港口物资管理系统、港口计件工资系统、港口机电设备管理系统、港口海关监管系统、港口主题数据库、港口信息门户网站、港口船舶调度系统以及轮驳公司与引航公司等衍生系统、港口边检业务网上受理系统、港口理货业务管理系统等近二十余个系统。这些系统已经基本成为港口集团各单位支撑业务运作的核心系统, 也给连云港港口带来了实实在在的经济效益和社会效益。

应用系统的普及让我们对信息系统的依赖程度空前增强, 不得不去考虑数据的安全存储、数据的备份、数据的深度挖掘等内容, 服务性能的优化、从一般意义上的信息中心向企业数据中心的转变直接摆在我们的面前。

2 需求分析

现在, 各大中企业都在兴建信息中心。开始时都有比较好的规划, 但随着企业发展, 业务的要求随市场变化, 对信息中心的要求也不停的变化, 当经过几个时期建设时, 信息中心很可能成为短期应对项目而建设, 造成各自为政, 迷失了规划的方向。常见的现象是:各个系统独立, 那个部分不足就升级或更换更强的设备。实际上, 这样的做法是非常浪费的。

信息中心主要包含接入设备、服务器、数据库和应用系统、网络设备、存储、安全和信息系统管理设备等, 是一个整体系统, 投资建设时就应该考虑到整体性和灵活适应性。我们来看看几个方面。

一般我们会给每个应用系统分配独立的服务器, 若这个应用非常重要, 那我们就会配置两台做冗余。随着业务发展, 使用人数越来越多, 但台服务器性能无法满足时, 我们会考虑用更强壮的服务器。若某些应用使用比较少, 或者偶尔性能要求比较高, 基于兼容性、可维护的角度考虑, 我们依然要配置一个单独的服务器。随着系统越来越多, 信息中心的服务器数量越来越多, 几十上百的服务器随处可见。大量的服务器利用率其实不高, 但依然一样的耗电, 一样的需要维护和管理, 一样的需要花钱维保。解决这些问题的方法基本由两个:服务器整合和服务器集群。

服务器整合是指把几台利用率不高的, 或者是出现错时高峰的服务器整合到一台服务器上, 以提高单台服务器的利用率。因整合带来服务器数量的大幅减少, 同时降低运营费用。这个领域最具代表性的是VMware。这种方法能解决部分问题, 但若同种应用或具有同样峰值要求的环境VM ware就无法解决。这时, 我们可以用服务器集群来解决。服务器集群是上个世纪90年代就开始发展的, 有硬件也有软件的模式, 发展到后来, 硬件模式的简单可管理和不影响原服务器性能等优点占了主流, 最具代表性的有F5等, 可以有30多种的负载均衡算法支持, 并且可以随需自动变换。

服务器端相对比较独立, 容易解决。而服务器后端相对就比较复杂, 包括数据库、存储等, 而且还需要互相配合才能达到最优。比如数据库系统存储空间分配方面, 最频繁读写的是Redo Log和tmp临时空间, 而实际的Data可能对性能的要求没有这么高, 所以我们需要把最优性能的存储空间分配给它们, 才能达到整体较优。如下图标红的表明是读写最高的数据块, 实际只占很少一部分, 但我们把两个Redo Log放在同一组存储空间中时, 一定会出现资源争用, 从而影响两个数据库的性能。

3 存储优化的方法

那如何合理规划分配存储, 达到性能最优化呢?我们来看看几个基本方面:磁盘阵列柜内优化、存储性能监控调优、结构调整。

柜内优化可以从几个方面进行。最先可以考虑的是升级盘阵操作系统 (微码) , 用最新的版本来达到较优的性能。其次可以考虑硬盘方面。按照磁盘RAID的特性, 不同类型的RAID类型会有不用的性能表现, 如RAID0就比RAID5性能要好, 只是总体可用容量少了。同是RAID5也有性能差异, 按照每个厂商的不同, 一般到十几个硬盘的情况下性能达到最佳。

几乎所有的盘阵都会配置大量的缓存, 缓存的读写分配也会影响性能。针对不同的应用特性我们需要分配不同多少的缓存。

有些极端的性能要求的, 还可以使用企业级的闪盘 (Flash Disk) 来支持。企业级闪盘有非常优异的性能特点, 比如读写IO比磁记录硬盘高几十倍, 同时随着IO的增多, 响应延时几乎保持稳定。详见右图, 可以看出, 随着IO数量到一定值, 由高性能光纤硬盘组成的RAID组响应的时间急剧上升, 而闪存盘则保持几个毫秒响应时间的优美特性。

对于纯粹的性能来讲, 上述方法都是有效的, 但在众多应用系统中, 企业占到最多资源的很有可能不是核心业务, 也即非核心业务很有可能和核心业务同台竞技, 争抢资源。这样就造成核心业务响应比较慢, 即使升级到较高一级的设备也没有明显效果。在网络领域是用Qo S来解决的, 在存储中是否也有这样的工具呢?个别厂商已经考虑了这些需求, 比如EMC, 在中端盘阵CLARii ON系列中就可以选择N Q M (N a v i s p h e r e Q u a l i t y o f S e r v i c e Manager) 软件来监控和调配性能使用, 保证主要的性能分配给核心的业务。这些调配可以按照吞吐量、带宽、响应时间等参数来设置。

另外一个需要考虑的是服务器和存储之间连接的性能问题。若存储性能足够, 服务器性能也很好, 很有可能连接它们的链路是个瓶颈。我们需要配备链路冗余等软件来达到多条线路负载均衡, 消除瓶颈。

除了上述局部的性能调优外, 还有其他策略性的调优方法。比如一个企业, 总有数据量约10TB, 包括OLTP的数据库应用数据、Email数据、文件共享数据等。这个企业采购10TB容量的盘阵, 所有数据都放在一个盘阵中。实际大多数企业的数据经常使用的只占20%, 那也就意味着不大用的80%的数据影响了整个盘阵的性能, 尤其是需要对数据进行保护时, 花在备份不常用数据的时间比常用数据长4倍。所以, 我们会考虑把不常用的部分数据移出主要存储设备, 放到比较稳固的存储设备上, 比如EMC的Centera, 需要的时候可以直接访问, 即不影响访问的便利性, 又可以给主存储设备瘦身而达到性能的提高。

结语

存储优化 篇6

关键词：云存储,元数据结构,元数据存储策略,树型数据结构

1 概述

云存储由于其便捷性,数据存储空间大且收费合理被广大用户所欢迎。因此,广大互联网行业纷纷推出自己的云存储产品。并且为了更加提高其体验性,研发者不遗余力的优化其技术。

当前云存储中主要有两种架构方式:主从架构及对等架构,主从架构即系统中有一个主节点,文件所有元数据存储于主节点中,剩余的为数据节点集群,主要用于存储文件数据[1]。对等架构是无主从之分,所有节点地位平等[1],但有一个元数据逻辑层,即系统元数据单层存储。主从架构由于其易扩展性及系统稳定性更高而更广泛地应用于云存储中。但主从架构有一个明显的缺点,就是当系统存储的是小文件,且小文件数量过多时,存储元数据的主节点会成为整个系统的性能瓶颈[2]。并且在云存储中,一般是采取多副本的形式进行数据备份,对于云存储来说,是很消耗资源的,且主节点存储的元数据还包括副本的元数据,当面对海量小文件,对主节点来说,压力还是很大的。目前对于主节点性能的解决方式,大多是多用几台机器存储,但这样的做法会减少查询效率,且浪费资源[2]

2 云存储小文件系统元数据相关技术研究

典型的集中式架构的分布式存储系统有Google的GFS[2],淘宝的TFS[2],Facebook的Haystack[2]。

在集中式架构中,元数据分为应用元数据及文件系统元数据。应用元数据全部存放于主节点中,用于定位文件在分布式集群中的机器、磁盘位置。文件系统存在于每个磁盘当中,文件系统的元数据存放于相应磁盘中,以inode形式存在。存储在主节点的应用元数据为文件与集群的映射关系,应用元数据包括文件key到集群机器的映射关系,及到磁盘的映射关系等,也包括每一个文件key对应的三个副本到集群的映射关系。

文件的读取如图1所示,Web Sever首先向主节点请求文件的应用元数据,查询出文件在集群的位置,然后向数据节点查询文件的具体位置信息,取得数据。

每个小文件存储为一个文件会导致元数据太多难以被全部缓存,且过多的i/o操作会限制系统的吞吐量,为了减少小文件在文件系统的元数据i/o操作,主要是减少其系统存储的查询小文件所需的元数据,目前针对小文件元数据减少的方法是将多个小文件存储在单个大文件中,控制文件个数,维护大型文件,则文件系统只需维护其合成的大文件的元数据,大大减少了系统存储的查询所需元数据。

小文件合成大文件的方法减少了文件系统元数据数量,但是,由于每个小文件维护三个副本,文件系统同样需要维护对应三个副本的元数据,其并不利于内存的利用。且主节点维护的文件应用元数据数量为源文件元数据x,加上副本元数据数量3x,即4x,副本元数据量占源文件元数据量的三倍,当数据量大时,很容易造成主节点性能瓶颈。

3 云存储小文件系统元数据管理方式优化方案

针对集中式架构主节点性能瓶颈问题,本文应用基于Vandermonde矩阵的RS算法减少主节点应用元数据,然后引入group概念,对主节点应用元数据应用group进行管理,使其形成基于group的树型结构,改变了主节点应用元数据的数据结构,然后采用主节点与数据节点相结合的方式,改变其存储策略,从这三个角度,减少主节点的元数据数据量及信息量。

3.1 云存储分布式小文件系统元数据数量方案改进设计

通过前面分析知,小文件合成大文件方式减少了文件系统所需的查询数据的元数据量,但是其3个副本的冗余方式也导致主节点存储的应用元数据量过多。即数据节点文件的冗余方式影响着系统所需存储的元数据数量。

基于Vandermonde矩阵的RS算法是起源于通信领域的前向编码方式[2],由于其能够在接收方做到自动检测错误,并且能够运用传输方传输过来的恢复策略进行数据自动恢复,使其能够运用到数据存储领域,即对要存储的文件产生一定的编码算法,产生出一定的校验块,当有数据丢失时,运用一定的机制进行恢复。如图2所示,基于Vandermonde矩阵的RS算法利用n块数据块,生成m块校验块,且m<n,其存储开销为(其中x为数据块大小):(1+m/n)*x<2x。

如有n个源文件,应用一个文件三个副本的方式,主节点需要存储4n个应用元数据,应用基于Vandermonde矩阵的RS算法对源文件进行冗余,生成m个校验块,且m<n,则主节点需要存储(n+m)个应用元数据,由于m<n,所以(n+m)<2n,即利用基于Vandermonde矩阵的RS算法进行文件数据冗余,主节点存储的应用元数据(n+m)<2n小于一个文件存储三个副本主节点需要存储的应用元数据4n。

这样做的好处是明显的,校验块生成的数量往往比源数据块的数量少,存储开销小于源文件三个副本的存储开销,由此,应用元数据的存储开销也变少,且文件数据能够达到高可靠性。

因此,本文将一定数量的小文件合成的大文件作为一个数据块,用n个数据块(n个大文件)生成其冗余的m个校验块,由此减少主节点存储的副本应用元数据数量。主节点存储的应用元数据化简为图3.6右,图左边为小文件合成大文件后主节点应用元数据的存储,但是因为文件的冗余方式是3副本形式,则其i个文件(n个大文件)有3i个副本,应用元数据也为3i个,图右边i个文件(n个大文件)有m个校验块,但m的数量远远小于3i个副本量的元数据。

3.2 云存储分布式小文件系统应用元数据结构及存储策略改进

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

为了实现逻辑上增大RAM-to-disk比率[3],逻辑上扩充存储应用元数据的内存空间,本文采取主节点与数据节点共同存储应用元数据,由此可扩展应用元数据的存储空间。且为了实现既使主节点管控整个系统的应用元数据,又减少其存储元数据数量及信息量,分散其一部分信息到数据节点,本文引入树型索引的概念,将应用元数据形成以group为根的树型元数据结构,使主节点只存储文件名与group的映射关系,并不再存储校验块的应用元数据信息(校验块应用元数据信息交由group管理),而数据节点存储大文件数据块的地方存储自己相应的group管理的元数据信息。

形成的应用元数据结构及存储方式如图5所示,主节点存放文件与group的映射关系,即以group的树型元数据结构的根节点,主节点在应用元数据管控中只管理最重要的,而将group管理的应用元数据的具体信息分发到各个文件块对应的节点中,即每个文件块存储自己对应的应用元数据,并加载到内存。由此减轻了主节点的压力。

主节点存放的应用元数据如图6,为文件与group的映射关系。

4 实验与分析

4.1 实验设计

本文针对改进后的元数据管理方式,形成分布式小文件系统SFS,对SFS设计测试内容如下:

1)由于上传操作是当数据上传后,未做任何处理之前,主节点收到数据后就会给客户端返回OK,因此,采用单线程在外网的情况下上传1万、3万、5万文件,并与NFS文件系统作对比,分析SFS的上传性能。

2)下载操作,为了分析SFS优化过的元数据管理,对系统采取多线程下载,在不同多线程下载的情况下,与传统云存储的下载情况进行对比,分析本本文改进的元数据管理方式是否对系统性能发生了提高。下载操作分为顺序下载及随机下载操作。

测试环境:集群共配置19台机器,一台测试客户端,1台名字节点(Namenode),用于存储一级元数据,1台名字节点的备机,16台数据节点(Datanode),用于存储数据及相应的元数据。机器采用Intel(R)Xeon(R)CPU E5620×2的CPU,12G内存,操作系统centos 6.5。

4.2 文件系统上传测试

上传测试中,本文选用分布式文件系统HDFS进行对比测试,测试数据选取如表5.3,通过对SFS的整体性能测试及HDFS的性能测试进行对比,来分析SFS改进的元数据管理方式的性能。

对SFS及HDFS采取单线程上传1-4组文件,测试文件都是小于64kb的小文件,测试文件数量递增,SFS上传文件系统的平均吞吐量如表2。

从表2看出,随着小文件数量的逐渐增加,SFS上传文件的吞吐量随着文件数量的增加而增大,并且当小文件数量达到14万个时,系统吞吐量依然在增加,说明系统工作良好。HDFS一开始的时候吞吐量比SFS的吞吐量大,但是随着小文件数量的增加,系统吞吐量增长缓慢,这是由于HDFS主要是处理大文件所引起的,小文件会导致过多的I/O消耗。图5.2清晰的表现了两者的对比。

从图7中看出,在小文件数量逐渐增多的情况下,SFS的吞吐量持续增加,而HDFS的吞吐量变化不大,这是由于HDFS里面可以存储大文件及小文件,系统对于文件的处理是进行分块处理,当小文件数量增加,会导致HDFS的I/O消耗增加,所以系统性能吞吐量增加并不明显,说明SFS对于小文件系统性能良好,改进的元数据管理方式提高了系统性能,适合于小文件系统存储。

4.3 文件系统下载性能测试

本节主要测试实现的主从架构中存储元数据主服务器的性能,为了对比改进的元数据管理方式是否对分布式小文件系统元数据主服务器性能及整体性能提高,本节采取将元数据全部放置在主节点与改进的元数据管理方式进行对比,由于系统整体配置一样,环境一样,只是元数据管理方式不一样,因此,对系统整体性能测试也即表现了元数据管理方式的性能。

在所述测试环境及测试目标的情况下,对SFS及传统云存储进行顺序下载测试,采取50个线程进行下载,测试数据分为5组,最小从10000个文件开始,然后线性递增,由于本文针对的是云存储小文件系统,因此提出的文件大小不超过64K,具体选取的测试数据描述如表3:

从压测客户端执行并发50个线程依次顺序写入1组到5组的数据,首先对本文设计的系统进行测试,然后对传统的云存储将所有元数据存放在主节点的存储元数据的方式进行测试。对本文测试的结果如表4:

由表4看出,随着写入文件数的数量增大,下载文件的消耗时间逐渐变多,为了体现改进方式的性能,本本文将所有元数据都存储于主节点上,构成云存储传统元数据管理方式,对系统在5个线程的情况下,同样进行5组测试数据的测试,对系统进行顺序下载,传统云存储文件顺序下载性能测试结果如表5:

从表5看出,将元数据全部写入到主从架构的主节点时,系统顺序下载时的总消耗时间随着文件数的增加而增大,对比改进后的元数据管理方案,消耗时间呈增长趋势。图8清晰的表明了本本文设计的元数据管理方式与传统云存储元数据管理方式系统下载性能对比。

从图8看出,SFS设计的元数据管理方案对比传统云存储元数据管理方案使系统整体的下载时间降低了。由于SFS只将分布式文件的一部分元数据存储于主从架构的主节点,即将基于group的树型元数据的group信息存储于主元数据服务器节点,剩余的精简过的元数据分布于响应数据节点的内存中,查询一个数据的方式是先在主节点查询其位置信息,再到数据节点查询数据,本文设计的数据节点的元数据是分布于查询数据对应的节点内存中,并没有多余的通信开销,且元数据主服务器节点由于只存储文件对应的group信息,存储压力小,性能必会得到提高,而传统的云存储是将分布式文件系统所有元数据都存储于主节点,且主节点元数据一般存储于数据库中,所有元数据存储于主节点会导致执行查询多个表的操作,且主节点的压力是比较大的,性能也会受到一定的影响。就是说,就算系统高负载情况下,SFS的响应时间会比传统的快,一样能够提供更好的服务。

5 结论

本文分析了云存储小文件系统元数据管理存在的问题,该问题导致了小文件系统主从架构主节点性能瓶颈,即系统元数据结构、元数据放置策略及系统存储的查询所需的元数据数量问题,针对此问题,改进了主从架构小文件系统元数据管理方式,利用基于Vandermonde矩阵的RS算法改变冗余方式减少其元数据数量,引入group概念,对元数据形成集群管理,设计了基于group的树型元数据结构,并在此基础上采取主从节点相结合共同存储元数据的方式分散主节点压力。本文改进的元数据管理方式提高了主节点及系统性能,但之后主节点单点故障问题还需进一步研究。

参考文献

[1]赵黎斌.面向云存储的分布式文件系统关键技术研究[D].西安:西安电子科技大学,2011.

存储优化 篇7

Hadoop是近几年发展比较成熟的云存储平台之一, 依据其在海量大文件分布存储方面优异的表现, 现已经被广泛应用到互联网领域。但是hadoop在小文件存储方面的表现却并不令人满意。目前针对小文件存储的优化方案通常是将小文件进行合并或进行序列化操作[1,2,3], 将其转化成大文件。例如典型的hadoop序列文件技术、HAR归档技术[1]等, 但此类方案对于特定应用 - 移动终端云存储, 就会造成用户访问实时性差、存储效率低等问题[4]。

笔者综合考虑移动终端用户访问的实时性、名称节点服务器内存使用率、数据节点存储空间利用率等方面提出一种FHAR技术, 利用双层索引归档技术结合模糊多属性决策理论[5] ( FAHP) ( 具体算法在2. 4节介绍) 的系统负载预测算法实现系统的负载均衡, 提高服务效率。

2 问题描述及模型建立

2. 1 问题描述

假设数据中心, 目前等待服务的队列有Nwq个任务, 正在接受服务的队列里有Nsq个任务, 一般处理方式是一直保持高负荷工作状态, 逐个对等待队列里任务进行服务, 这种方式可能造成两个方面问题: ( 1) 作为一个完整的系统, 在提供服务时, 还应该综合考虑系统当时的负载情况, 以防止出现有时任务繁重, 有时几乎空闲的状态。 ( 2) 针对某些具体的应用还应该考虑用户访问的实时性需求。

数据中心所有任务表示为W = { w1, w2, …, wn} , 定义wi的取值意义如下

i = 1, 2, …, n。通过对wi的运算到当前系统的任务情况。

2. 2 系统服务模型建立

系统的主要工作是针对三个队列的操作。第1种为服务队列SQ, 第2种为等待队列WQ, 第三种为备用队列PQ, 系统工作时, 首先判断WQ状态 ( 过程1) , 如果为队列为满QF状态, 则系统会利用FAHP预测算法, 根据前面连续几段时间内的系统压力, 对将来一段时间的系统负载进行预测, 如果预测结果大于某个设定好的阈值, 则当前的SQ队列将被放入PQ队列中 ( 过程8) , 等待几秒时间后再进行服务 ( 过程7) 。如果预测结果不大于域值, 则对WQ进行服务 ( 过程3) 。具体流程如图1所示。

2. 3 均衡负载算法设计

系统在接收到控制信号signal后, 如果信号为队列满信号QF, 开启FAHP预测模块, 预测系统下段时间的负载, 如果负载小于阈值, 则对所有待服务队列进行服务, 并取消时间到信号将TimeIsUp重置为0, 如果大于阈值但PQ队列数量大于5, 则同上对请求队列进行服务, 如果没有达到以上条件则新建PQ, 将WQ转移到PQ, 重新设定TimeIsUp为0, 如果系统当前请求队列没有满, 则预测系统负载, 反之如果大于阈值, 则推迟当前请求服务时间, 否则重新设定TimeIsUp信号为0, 使系统继续接收服务请求。

系统控制负载均衡算法伪代码如下:

2. 4 基于 FAHP 的系统预测算法

本系统预测主要是基于名称节点内存使用率、数据节点存储空间利用率、带宽利用率和系统平均吞吐量等基本系统指标进行的多属性决策[9]。FAHP是在层次分析法 ( AHP) 的基础上提出的一种改进的多属性决策理论[5]。

定义1: 设矩阵R = ( rij) m×n, 若满足:

则称R是模糊矩阵。

定义2: 若模糊矩阵R = ( rij) m×n满足: i, j, k有

则称模糊矩阵R是模糊一致矩阵。

( 1) 下面利用模糊一致矩阵来表示各属性之间关系的比较矩阵R, R中元素定义如表1所示:

( 2) 由于判断矩阵满足一致性, 所以可以利用最小二乘法求权重向量Ω = { ω1, ω2, …, ωn}T, 即求如下约束规划问题:

( 1) 等同于其中λ是Laggrange乘子。对ωi求偏导得以下方程组

解方程组 ( 2) 即可得Ω = { ω1, ω2, …, ωn}T。

( 3) 系统负载的预测值, 根据时间顺序的重要性构造比较矩阵R之后, 按步骤 ( 1) 、 ( 2) 计算之前n时刻的决策属性值d1, d2, …, dn的权重ωi ( i = 1, 2, …, n) , 从而预测下一时刻系统 负载, 通过这一算法, 可以实现系统负载的预测, 从而将对小文件的操作控制在某个能够均衡系统负载的时刻进行。

2. 5 读取的优化方法

单个文件的访问主要是对文件名称的搜索[6]。客户端读取要查找文件的扩展名, 继而访问名称节点, 名称节点根据此扩展名和用户名返回一个文件目录的索引userIndex, 最后数据节点根据userIndex访问对应的数据块位置索引, 在此数据块位置查找此文件。

在数据节点上的查询上本方案采用的是倒序对比[7]的方法, 即查找这个字符在树的哪些元素节点上出现, 然后从树的元素节点出发向上查找, 直到找到根节点。这样就形成了一条或多条路径, 当关键词与某条路径上出现的字符完全匹配时, 查找成功。

同时本方案还采取了数据预取的机制[8], 数据预取机制是一种有效的存取优化技术。利用访问的局部性特征, 预先读取数据能够隐藏磁盘I/O带来的开销, 有效地提升读取的性能。

本方案的预取方法是: 预取当前请求文件相邻的3个文件 ( 这一值只是用于测试, 后续工作会挖掘用户的访问习惯, 调整相应的预取策略) , 对于文件数不是远大于3的文件类型, 例如联系人文档, 就实现全部预取。

3 实 验

本实验方案环境是有6个节点的hadoop集群。为体现云计算整合计算资源的思想, 实验采用设备均为普通PC机以及部分刀片机, 操作系统为Ubuntu Server 11. 10 , hadoop版本为0. 20. 0. 其中一台作为名称节点, 另外五台作为数据节点。移动终端采用Android操作系统的智能机为例进行实验。系统所用5台智能机均为Android 4. 0系统, 内存均为1G, 为方便测试内存小文件数目分别设置为300, 400, 500, 600, 700。方案分别将5台智能移动终端上的文件按照传统HDFS、HAR、FHAR方式上传到实验存储平台以及进行访问等相关操作。

3. 1 实验 1: 移动终端小文件存储效率测试

3. 1. 1 节点内存的使用情况

图2与图3显示了三种方案NameNode和Da- taNode的内存空间利用率性能对比, 从图中可以明显看出, FHAR在这两方面与HAR归档技术基本相当或略优, 但比传统HDFS优势明显。在名称节点内存使用上, FHAR分别是传统HDFS和HAR的1/ 127. 32和1 /3. 96。而DataNode节点内存使用情况上, 分别为传统HDFS和HAR的1/13和1. 41倍。

3. 1. 2 存储服务效率对比

图4显示了有三种方案存储效率上的对比, 从图中可以明显的看出, FHAR因为均衡了服务器的任务负载, 从而在存储服务效率上比HAR都得到很大的改善。虽然HAR比传统HDFS在数据节点存储空间利用率方面有一定的改进, 但因为需要归档小文件, 所以也降低了文件的存储速度。

3. 2 实验 2: 用户对文件访问效率测试

如果文件按照传统HDFS的方式存储, 由于所有文件都是可以直接通过名称节点内存中的索引获取的, 所以其读取速度会非常快, 实验2就是以传统HDFS直接存储的速度为基底, 进行对比。如图5所示, 明显可以看出, 随着小文件数的增加, HAR的读取速度会迅速下降, 由81% 下降到42%, 而FHAR由于采用了负载均衡的方法, 速度一直维持在82%左右, 在一定程度上保证了读取的实时性。

4 结 语

针对移动终端云存储系统中小文件存取效率不高的问题, 提出并实现一种基于Hadoop平台的移动终端云存储优化方案 - FHAR。方案采用FAHP模糊层次分析法, 分层归档、双层索引以及文件预取等技术实现优化目的。方案首先根据FAHP算法预测结果将终端文件归档成大文件, 并生成双层索引, 同时将索引文件预加载到节点内存中, 在用户浏览读取文件时系统将采取文件预取的机制, 提高访问的实效性。由实验结果明显可以看到, FHAR在移动终端云存储系统节点内存耗费与访问响应时间上实现了显著改善。

在以后的工作中, 我们将从以下两个方面对系统进行改进: 1) 对数据节点索引进行进一步压缩, 以减小不必要的文件查找消耗。2) 对文件的预加载进行优化, 根据用户的习惯习性等进行相应的预测加载, 进一步提高用户实时体验性。

参考文献

[1]Tom W.Hadoop:The Definitive Guide[M].United States of America:O'Reilly Media, 2009.

[2]余思, 桂小林, 黄汝维, 庄威.一种提高云存储中小文件存储效率的方案[J].西安交通大学学报, 2011 (3) :59-63.

[3]MACKEY G, SEHRI S, WANG Jun.Improving metadata management for small files in HDFS[C/OL]//Proceedings of 2009 IEEE International Conference on Cluster Computing and workshops[2010-08-10].http://ieeexplore.ieee.org/stamp/stamp.jsptp=&arnumber=528913.

[4]DONG Bo, QIU Jie, ZHENG Qinghua, et al.A norvel approach to improving the efficiency of storing and acessing small files on hadoop:a case study by PowerPoint files[C]//Proceedngs of the 7th International Conference on Services Computing.Piscataway, NJ, USA:IEEE, 2010:65-72.

[5]张吉军, 模糊层次分析法[J].模糊系统与数学, 2010 (6) ;80-88.

[6]Cafarella B, Cutting D.Hadoop:a framework for running applications on large clusters built of commodity hardware[EB/OL].http://lucene.Apache.org/hadoop/, 2005.

[7]刘小珠, 孙莎, 曾承, 彭智勇, 基于缓存的倒排索引机制研究[J].计算机研究与发展, 2007 (44) :153-158.

[8]Mingliang Liu, Lin Qiao, Fucen Zeng and Zhizhong Tang.Exploring Data Prefetching Mechanisms for Last Level Cache in Chip Multi-processors[C/OL]//2010 international Colloquium on Computiing, Communication, Control, and Management (CCCM2010) Volume 3, 2010.