CN111562936A - 基于Openstack-Swift的对象历史版本管理方法和装置 - Google Patents

基于Openstack-Swift的对象历史版本管理方法和装置 Download PDF

Info

Publication number
CN111562936A
CN111562936A CN201910113190.0A CN201910113190A CN111562936A CN 111562936 A CN111562936 A CN 111562936A CN 201910113190 A CN201910113190 A CN 201910113190A CN 111562936 A CN111562936 A CN 111562936A
Authority
CN
China
Prior art keywords
version
file
version file
data
latest
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN201910113190.0A
Other languages
English (en)
Inventor
詹孟华
张永田
贺新民
何平
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
SF Technology Co Ltd
SF Tech Co Ltd
Original Assignee
SF Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by SF Technology Co Ltd filed Critical SF Technology Co Ltd
Priority to CN201910113190.0A priority Critical patent/CN111562936A/zh
Publication of CN111562936A publication Critical patent/CN111562936A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/70Software maintenance or management
    • G06F8/71Version control; Configuration management

Abstract

本申请公开了一种Openstack‑Swift的对象历史版本管理方法和装置。该方法包括:代理节点转发访问请求到对象存储节点;根据所述访问请求写入最新版本文件到所述对象存储节点;在所述对象存储节点中查找对象最新历史版本文件;根据所述最新版本文件和旧的当前版本文件,判断是否需要进行版本处理;若是,则根据预设的版本处理规则处理所述最新版本文件和旧的当前版本文件;根据预设的数据更新规则更新object表的数据。所述装置用于执行所述方法。本发明实施例通过该方法大大的提升了对象覆盖及删除时候的相应时间。

Description

基于Openstack-Swift的对象历史版本管理方法和装置
技术领域
本发明一般涉及云计算技术领域,具体涉及一种基于Openstack-Swift的对象历史版本管理方法和装置。
背景技术
随着互联网科技的飞速发展,用户开始参与信息的制造和编辑,使得用户个人数据量成指数增长,导致数据存储和管理的业务逐渐增加,云技术随之产生,云计算是一种基于网格的计算模式,其核心是为用户提供可伸缩的虚拟化服务。OpenStack是该领域最前沿的开源云系统,作为公有云和私有云的共同技术基础,其实现了统一的云管理平台自动化。Swift是Openstack开源社区构建的一个多租户、高扩展和高可用的对象存储系统,是用于低成本存储海量非结构化数据,兼容Amazon S3(Simple Storage Service)协议的多地域、分布式对象存储解决方案,其目的是使用普通硬件来构建冗余的、可扩展的分布式对象存储集群,存储容量可达PB级。
目前基于现有技术中Openstack-Swift中的原生历史版本文件有两个问题:一是历史版本文件对用户是可见的,一旦用户误删历史版本数据,数据就会彻底丢失,此时对用户数据的使用就会存在风险;二是生成历史版本的流程复杂,会极大的影响集群的服务性能。
因此,如何提升对象数据的安全性和提升对象集群的性能比率是亟待解决的问题。
发明内容
鉴于现有技术中的上述缺陷或不足,期望提供一种基于Openstack-Swift对象历史版本管理方法和装置,能够在对象文件进行更新、删除时,实现对象的历史版本文件的自动生成和清理。
第一方面,本申请提供一种基于Openstack-Swift对象历史版本管理方法,所述方法包括:
代理节点转发访问请求到对象存储节点;
根据所述访问请求写入最新版本文件到所述对象存储节点;
在所述对象存储节点中查找对象最新历史版本文件;
根据所述最新版本文件和旧的当前版本文件,判断是否需要进行版本处理;
若是,则根据预设的版本处理规则处理所述最新版本文件和旧的当前版本文件;
根据预设的数据更新规则更新object表的数据。
可选的,所述根据预设的版本处理规则处理所述最新版本文件和旧的当前版本文件,包括:
对所述所有版本文件按照时间进行排序;
保留排序后的历史版本文件中预设数量的最新历史版本文件,并删除其他历史版本文件。
可选的,所述对所述所有版本文件按照时间进行排序之前,包括:
若需生成历史版本文件,则将所述旧的当前版本文件重命名为历史版本文件。
可选的,所述根据预设的数据更新规则更新object表的数据,包括:
对象存储节点向元数据节点发送元数据更新请求;
查询元数据节点的object表里的对象元数据信息,当查到后向历史对象表里插入所查询到的对象元数据;
根据所述更新请求更新object表的数据。
可选的,所述访问请求包括:
写入访问请求、删除访问请求、更新访问请求。
第二方面,本申请实施例提供一种基于Openstack-Swift对象历史版本管理装置,所述装置包括:
发送模块,用于代理节点转发访问请求到对象存储节点;
写入模块,用于根据所述访问请求写入最新版本文件到所述对象存储节点;
查找模块,用于在所述对象存储节点中查找对象最新历史版本文件;
判断模块,用于根据所述最新版本文件和旧的当前版本文件,判断是否需要进行版本处理;
处理模块,用于若是,则根据预设的版本处理规则处理所述最新版本文件和旧的当前版本文件;
更新模块,用于根据预设的数据更新规则更新object表的数据。
可选的,所述处理模块包括:
第一处理单元,用于对所述所有版本文件按照时间进行排序;
第二处理单元,用于保留排序后的历史版本文件中预设数量的最新历史版本文件,并删除其他历史版本文件。
可选的,所述装置还包括:
重命名模块,用于若需生成历史版本文件,则将所述旧的当前版本文件重命名为历史版本文件。
可选的,所述更新模块还包括:
请求单元,用于对象存储节点向元数据节点发送元数据更新请求;
查询单元,用于查询元数据节点的object表里的对象元数据信息,当查到后向历史对象表里插入所查询到的对象元数据;
更新单元,用于根据所述更新请求更新object表的数据。
可选的,所述访问请求包括:
写入访问请求、删除访问请求、更新访问请求。
本申请实施例的有益效果为:现有技术中原生的历史版本文件对用户是可见的,若用户误删历史版本数据,数据就会彻底丢失。除此之外原生流程要将原先的对象文件重新写入到指定的历史容器,确定对象历史版本写入成功之后再进行操作,导致对象初次写入、覆盖、删除性能下降幅度较大。本方案通过根据写入最新版本文件和查找最新历史版本文件的方法,判断该文件是否存在版本处理操作,将需要进行版本处理操作的文件按照预设的版本处理规则,具体为可以通过版本重新命名、排序、以及历史版本自动清理的方式实现了降低用户误删备份数据的风险性;通过按照预设数据更新规则更新object表的数据的方法,具体为向历史对象表里插入所查询到的对象元数据进行object表的更新处理,极大地提升了集群的性能。
附图说明
通过阅读参照以下附图所作的对非限制性实施例所作的详细描述,本申请的其它特征、目的和优点将会变得更明显:
图1为本发明的实施例的基于Openstack-Swift对象历史版本管理方法的流程示意图;
图2为本发明的实施例的版本处理规则处理文件的流程示意图;
图3为本发明的实施例的根据预设数据更新object表的数据的流程示意图;
图4为本发明的实施例的基于Openstack-Swift对象历史版本管理装置的结构示意图;
图5为本发明的另一实施例的基于Openstack-Swift对象历史版本管理装置的结构示意图;
图6为本发明的实施例的服务器的计算机系统的结构示意图。
具体实施方式
下面结合附图和实施例对本申请作进一步的详细说明。可以理解的是,此处所描述的具体实施例仅仅用于解释相关发明,而非对该发明的限定。另外还需要说明的是,为了便于描述,附图中仅示出了与发明相关的部分。
OpenStack-Swift开源项目提供了弹性可伸缩、高可用的分布式对象存储服务,适合存储大规模非结构化数据。Swift是基于一致性散列技术,通过计算可将对象均匀分布到虚拟空间的虚拟节点上,在增加或删除节点时可大大减少需移动的数据量。Swift采用完全对称、面向资源的分布式系统架构设计,所有组件都可扩展,避免因单点失效而扩散并影响整个系统运转;通信方式采用非阻塞式I/O模式,提高了系统吞吐和响应能力。其中Swift组件包括:代理服务(Proxy Server),认证服务(Authentication Server),缓存服务(CacheServer),账户服务(Account Server),容器服务(Container Server),对象服务(ObjectServer),复制服务(Replicator),更新服务(Updater),审计服务(Auditor),账户清理服务(Account Reaper)。Swift采用层次数据模型,共设三层逻辑结构:Account/Container/Object(账户/容器/对象)。每层节点数均没有限制,可以任意扩展。这里的账户和个人账户不是一个概念,可理解为租户,用来做顶层的隔离机制,可以被多个个人账户所共同使用;容器类似文件夹,代表封装一组对象;对象由元数据和数据两部分组成,该元数据(Metadata)又称中介数据、中继数据,为描述数据的数据(dataabout data)。Swift无需采用RAID(磁盘冗余阵列),也没有中心单元或主控结点。Swift通过在软件层面引入一致性哈希技术和数据冗余性,牺牲一定程度的数据一致性来达到高可用性(High Availability,简称HA)和可伸缩性,支持多租户模式、容器和对象读写操作,适合解决互联网的应用场景下非结构化数据存储问题,适用于海量的、静态的、可以长期持久保存的非结构化数据的存储,如归档文件、影像、图片、音视频、网盘、邮件、日志文件、系统备份等。在分布式对象存储中,一个关键问题是数据该如何存放。Swift是基于一致性哈希技术,通过计算可将对象均匀分布到虚拟空间的虚拟节点上,在增加或删除节点时可大大减少需移动的数据量;虚拟空间大小通常采用2的n次幂,便于进行高效的移位操作;然后通过独特的数据结构Ring(环)再将虚拟节点映射到实际的物理存储设备上,完成寻址过程。Ring是Swift中最重要的组件,用于记录存储对象与物理位置间的映射关系。在涉及查询Account、Container、Object信息时就需要查询集群的Ring信息。环是为了将虚拟节点(partition,分区)均衡地映射到一组物理存储设备上,并提供一定的冗余度而设计的,其数据结构由以下信息组成:存储设备列表、分区设备对应表。存储设备表里有设备信息包括唯一标识号(id)、区域号(zone)、权重(weight)、IP地址(ip)、端口(port)、设备名称(device)、元数据(meta);分区设备对应表中记录了每个分区应该保存在哪些设备上。总的来说,Ring引入一致性哈希的原因是为了减少由于增加结点导致数据项移动的数量来提高单调性;引入partition的原因是为了减少由于节点数过少导致移动过多的数据项;引入replica(副本)的原因是防止数据单点、提高冗余性;引入zone的原因是为了保证分区容忍性;引入weight的原因是为了保证partition分配的均衡。
如背景技术中所提到的OpenStack-Swift对象历史版本处理操作流程太长,需要代理节点先查询旧对象,再转移旧对象,最后写入新对象。因此,OpenStack-Swift自有历史版本功能在起作用的同时会导致整个对象存储集群性能下降50%-75%。
鉴于现有技术上的上述缺陷,本申请实施例提供一种基于Openstack-Swift对象历史版本管理方法,结合版本重命名旧版本的技术、历史版本的自动清理、历史版本元数据自动生成技术旨在使集群性能明显降低的情况下实现对象历史版本的管理。
需要说明的是,在不冲突的情况下,本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。
下面将结合流程图来描述本申请实施例的方法。
参考图1,其示出了本申请实施例提供的一种基于Openstack-Swift对象历史版本管理方法的流程示意图。该方法包括:
步骤S11,代理节点转发访问请求到对象存储节点。
具体的,Openstack-Swift是一套分布式的对象存储系统,有存储节点、代理节点、元数据节点。分布式文件系统会有一个元数据节点和N个对象存储节点。其中元数据节点类似于文件系统中inode模块的功能。Swift主要服务有4个,proxy-server部署在代理节点上;account-server,container-server,这两个部署在元数据节点上;object-server部署在对象存储节点上。
可以理解的,例如以原生的历史版本功能下更新对象文件为例:用户通过客户端发送更新请求,代理节点收到更新请求后,会先通过http协议,转发更新文件请求到对象存储系统的存储节点,获取旧的版本文件。最后再将新版本的数据通过http请求发送给存储节点,存储节点进行保存。因此在原生的历史版本文件有效的情况下,实际上进行了两次的http请求,一次数据落盘的操作。
步骤S12,根据访问请求写入最新版本文件到对象存储节点。
具体的,对象存储节点根据接收到的访问请求后,将数据保存为最新版本文件放到对象目录下。例如,在对象存储节点object-server是在对象存储节点将新的对象数据写入后,获取新对象的时间戳,即旧对象的删除时间。可以理解为保存一个对象,其对象名为test,内容为aaa,这一步就是在对象存储节点生成一个文件,其内容为aaa,文件名是15xxxx.data,其中所说的文件名就是请求的时间戳。
进一步的,比如用写入对象举例上传一个account(账号名)是admin,container(容器)是test,object(对象)是obj,obj对象的内容是aaa,代理节点会根据account,container,object和hash前后缀计算出对象,此处的hash值是根据哈西算法计算出来的数值。根据此数值将请求转发到相应的对象存储节点上,即对象存储节点上的objectserver根据计算出的hash值在相应的目录下创建一个对象文件,文件的内容就是aaa。
步骤S13,在对象存储节点中查找对象最新历史版本文件。
具体的,版本文件就是指当前的版本文件,同一个对象,如果今天已经生成了一个历史版本,就不会再生成历史版本文件了。正常GET对象是读取的,最新是为了与旧的当前版本文件区分,因为在写入之前也可能存在已经存有一个当前版本文件了。
可以理解的,在上一步骤中对象存储节点写入最新版本文件是指用户发一个请求,比如说更新请求,或者说写入请求。对象存储节点的object server根据代理节点转发的请求的URL网址找到对象的存储目录,在这个目录下就有对象的版本文件和对象所有的历史版本文件,根据历史版本文件的文件名,查找最新的历史版本文件。其中版本文件命名规则为:请求时间戳.data,例如1549187743.4675.data为一个版本文件,此时间戳则代表对象的生成时间,历史版本文件的命名规则:version.历史版本生成时间戳.data,其中对象生成时间戳是指对象文件生成的时间,历史版本生成时间戳是指对象文件从版本文件转化为历史版本文件的时间戳,可以根据以上文件的时间戳来查找对象最新历史版本文件。
步骤S14,根据最新版本文件和旧的当前版本文件,判断是否需要进行版本处理。
具体的,Openstack-Swift原本存在根据对象的URL网址定位到对象文件保存目录的功能,只是这个目录只能保存最新的对象文件,而历史版本文件会被写入一个新的目录下面,原目录下的旧版本文件被删除掉。现在根据旧版本的创建时间,修改时间,以及特定的前缀,将旧的文件重命名为历史版本文件保存在原来的目录下面,再利用旧的版本清理流程方案,将多余的历史版本文件进行删除。
进一步的,根据最新版本文件和旧的当前版本文件进行比对判断最新的历史版本文件的转化时间戳是否为当天,若不是,则需要进行版本操作,若是,则不需要进行版本操作,继续等待。进行版本操作的原因是保证一个对象在一天之内只会生成一个版本。
步骤S15,若是,则根据预设的版本处理规则处理最新版本文件和旧的当前版本文件。
具体的,当最新的历史版本文件的转化时间戳不是当天时,需要进行版本操作,将旧的对象文件命名为历史版本文件后,先获取所有的历史版本文件对其进行排序,再根据历史版本文件的创建时间、删除时间这两种信息,来判断哪些历史版本文件需要被删除,然后删除这些文件。如果是当天,就说明当天已经产生了一个历史版本,不需要进行版本操作了。
进一步的,例如已更新请求为实施例,对象目录下有一个版本文件,版本文件命名为:15xxx09.data,存在两个历史版本文件分别为:version.15xxx08_15xxx07.data,version.15xxx07_15xxx06.data,此时进行更新操作,写入最新版本文件15xxx10.data后,此时的对象目录下存在4个文件,2个版本文件,2个历史版本文件。此时进行预设的版本处理规则进行文件版本处理,即先把15xxx09.data文件重命名为version.15xxx10_15xxx09.data,再对现在的历史版本文件进行排序,保留最新的两个版本,即就是保留了version.15xxx10_15xxx09.data和version.15xxx08_15xxx07.data两个文件。
可以理解的,最终目录下存在的文件就是两个历史版本文件version.15xxx10_15xxx09.data和version.15xxx08_15xxx07.data,一个版本文件15xxx10.data,其中version.15xxx07_15xxx06.data文件会被删除掉。
步骤S16,根据预设的数据更新规则更新object表的数据。
具体的,object表中需要更新的数据有对象名、对象的创建时间戳、对象成为历史版本的具体时间、对象成为历史版本的时间戳,其中时间戳的具体时间精确到秒的小数点后4位100微秒。Container server根据请求里的对象名从object表里查出对象的创建时间戳,再在请求中获取对象历史版本的生成时间戳,然后根据此时间戳获取对象历史版本的生成日期,最后将这些数据插入object表中。
可以理解的,object server在写完对象后,会向container server发出更新对象元数据的http的PUT请求,container server在收到请求后,会从请求的header中获取要更新元数据的对象的名字,对象修改时间戳,即对象成为历史版本的时间戳。然后根据名字在object表里查询对象创建时间戳,并根据对象修改时间戳,计算对象修改的日期字符串,例如“20190203”,最后将获取到object表里需要更新的数据有:对象名,对象的创建时间戳,对象成为历史版本的具体时间,对象成为历史版本的时间戳,插入object表中,此处的object表叫历史数据表。
可选的,根据预设的版本处理规则处理最新版本文件和旧的当前版本文件,包括:
步骤S151,对所有版本文件按照时间进行排序。
步骤S152,保留排序后的历史版本文件中预设数量的最新历史版本文件,并删除其他历史版本文件。
具体的,对所有版本文件按照时间进行排序,此处是按照对象转化成为历史版本文件的时间进行排序。比如设定只保存3个历史版本,当历史版本超过4个的时候会将最早生成的历史版本删除掉,例如,现在有4个历史版本文件为:version.15xxx10_15xxx09.data、version.15xxx08_15xxx07.data、version.15xxx22_15xxx19.data、version.15xxx16_15xxx11.data。根据排序结果为version.15xxx22_15xxx19.data、version.15xxx16_15xxx11.data、version.15xxx10_15xxx09.data、version.15xxx08_15xxx07.data。由于只能保留三个历史版本,version.15xxx08_15xxx07.data会被删除。
可选的,对所有版本文件按照时间进行排序之前,包括:
若需生成历史版本文件,则将旧的当前版本文件重命名为历史版本文件。
具体的,如果需要生成历史版本文件,那么就将当前版本文件重命名为历史版本文件。例如,把15xxx09.data文件重命名为version.15xxx10_15xxx09.data。
可选的,根据预设的数据更新规则更新object表的数据,包括:
步骤S161,对象存储节点向元数据节点发送元数据更新请求;
步骤S162,查询元数据节点的object表里的对象元数据信息,当查到后向历史对象表里插入所查询到的对象元数据;
步骤S163,根据更新请求更新所述object表的数据。
具体的,此处的元数据节点为container server的节点,之前所有的文件的元数据都放在元数据库里。因为对象文件对其进行操作,都会影响这个数据库里面的内容。因此,不管是进行post更新请求操作或者删除请求操作,元数据库肯定会有一次修改。
进一步的,改造了元数据的数据库,让其保存对象的元数据的同时,自动生成历史版本的元数据。历史版本元数据自动生成,是在对象的元数据写入元数据数据库之前,先根据对象名,查询旧的元数据;然后将这些元数据插入到历史版本表中。
可选的,访问请求包括:
写入访问请求、删除访问请求、更新访问请求。
具体的,上述的访问请求可以包括写入文件的访问、删除文件的访问请求,以及更新文件的访问请求,对象存储节点获取以上三种访问请求,确保对象在变动时将变动前的对象作为历史版本保存,并提供了恢复指定版本的功能,为用户数据的安全性提供了进一步的保证。针对对象存储流程上进行改造,从而进一步确保了对象存储的数据安全性。
第二方面,本申请还提供一种基于Openstack-Swift对象历史版本管理装置。图4为基于Openstack-Swift对象历史版本管理装置200的结构示意图。如图所示,该装置包括:
发送模块210,配置用于代理节点转发访问请求到对象存储节点;
写入模块220,配置用于根据访问请求写入最新版本文件到对象存储节点;
查找模块230,配置用于在对象存储节点中查找对象最新历史版本文件;
判断模块240,配置用于根据最新版本文件和旧的当前版本文件,判断是否需要进行版本处理;
处理模块250,配置用于若是,则根据预设的版本处理规则处理最新版本文件和旧的当前版本文件;
更新模块260,配置用于根据预设的数据更新规则更新object表的数据。
在一些实施例中,处理模块250还包括:
第一处理单元2501,配置用于对所有版本文件按照时间进行排序;
第二处理单元2502,配置用于保留排序后的历史版本文件中预设数量的最新历史版本文件,并删除其他历史版本文件。
在一些实施例中,更新模块260还包括:
请求单元2601,配置用于对象存储节点向元数据节点发送元数据更新请求;
查询单元2602,配置用于查询元数据节点的object表里的对象元数据信息,当查到后向历史对象表里插入所查询到的对象元数据;
更新单元2603,配置用于根据更新请求更新object表的数据。
具体的,假如目录下有两个历史版本文件version.15xxx10_15xxx09.data,version.15xxx08_15xxx07.data;一个版本文件15xxx10.data,此时若客户端向代理节点发出删除请求,代理节点收到请求后,计算对象的hash值,获取对象存储目录的地址,然后转发请求到对象存储节点。对象存储节点的object server收到请求后,根据hash值查找对象存储目录,在目录下建立最新版本的空文件15xxx30.ts。对比旧的版本文件和最新的历史版本文件,判断是否进行版本操作,若需要进行版本操作,则需要将旧的版本文件重命名15xxx10.data重命名为version.15xxx30_15xxx10.data,排序后的结果version.15xxx30_15xxx10.data,version.15xxx10_15xxx09.data,version.15xxx08_15xxx07.data。
进一步的,然后version.15xxx08_15xxx07.data,接着向container节点发送请求,container server根据对象名查询object表,查出历史版本的创建时间,containerserver将对象名,对象创建时间戳,对象转化为历史版本的时间戳,对象转化为历史版本的日期这四种数据插入新的object表,最后container server在object表里将对应的记录标记为已删除文件。
请参考图5,示出了根据本申请实施例的另一实施例的基于Openstack-Swift对象历史版本管理装置的结构示意图。在一些实施例中,在处理模块250之前,判断模块240之后,存在重命名模块235,包括:
重命名模块235,配置用于若需生成历史版本文件,则将旧的当前版本文件重命名为历史版本文件。
具体的,判断是否需要将旧的对象文件重命名为历史版本文件;如果需要,可以再用新对象的时间与旧对象的时间戳、固定的前缀一起,拼装出历史版本的名字。例如,最后将旧的对象文件重命名为version_reqtimestamp_createtimestamp.data形式的文件。版本文件的名字格式是时间戳.data,例如1549787817.5482.data。历史版本文件的名字可以为version.1549787968.4896_1549787817.5482.data。此处有两个时间戳,前者表示对象文件从版本文件转化为历史版本文件的时间,后者表示该对象文件被创建的时间。
可以理解的,将旧的当前版本文件重命名为历史版本文件之后,设定全新的对象清理规则,让对象目录下面能够保存指定个数的历史版本文件,若历史版本文件过多,能自动删除最早的历史版本文件。例如,例如可以设定只保存3个历史版本,当历史版本超过4个的时候就会将最早生成的历史版本删掉。
下面参考图6,其示出了适于用来实现本申请实施例的计算机设备600的结构示意图。
如图6所示,计算机设备600包括中央处理单元(CPU)601,其可以根据存储在只读存储器(ROM)602中的程序或者从存储部分608加载到随机访问存储器(RAM)603中的程序而执行各种适当的动作和处理。在RAM 603中,还存储有系统600操作所需的各种程序和数据。CPU 601、ROM 602以及RAM 603通过总线604彼此相连。输入/输出(I/O)接口605也连接至总线604。
以下部件连接至I/O接口605:包括键盘、鼠标等的输入部分606;包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分607;包括硬盘等的存储部分608;以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分609。通信部分609经由诸如因特网的网络执行通信处理。驱动器610也根据需要连接至I/O接口605。可拆卸介质611,诸如磁盘、光盘、磁光盘、半导体存储器等等,根据需要安装在驱动器610上,以便于从其上读出的计算机程序根据需要被安装入存储部分608。
特别地,根据本公开的实施例,上文参考图1描述的过程可以被实现为计算机软件程序。例如,本公开的实施例包括一种计算机程序产品,其包括有形地包含在机器可读介质上的计算机程序,上述计算机程序包含用于执行图1的方法的程序代码。在这样的实施例中,在这样的实施例中,该计算机程序可以通过通信部分从网络上被下载和安装,和/或从可拆卸介质被安装。在该计算机程序被中央处理单元(CPU)601执行时,执行本申请的系统中限定的上述功能。
需要说明的是,本发明所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件,或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于:具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本发明中,计算机可读存储介质可以是任何包含或存储程序的有形介质,该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本发明中,计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号,其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式,包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质,该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输,包括但不限于:无线、电线、光缆、RF等等,或者上述的任意合适的组合。
附图中的流程图和框图,图示了按照本发明各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分,前述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个接连地表示的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合,可以用执行规定的功能或操作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。
描述于本申请实施例中所涉及到的单元或模块可以通过软件的方式实现,也可以通过硬件的方式来实现。所描述的单元或模块也可以设置在处理器中。其中,这些单元的名称在某种情况下并不构成对该单元本身的限定。所描述的单元或模块也可以设置在处理器中,例如,可以描述为:一种处理器包括发送模块、写入模块、查找模块、判断模块、处理模块、更新模块。其中,这些单元或模块的名称在某种情况下并不构成对该单元或模块本身的限定,例如,发送模块还可以被描述为“代理节点转发访问请求到对象存储节点”。
作为另一方面,本申请还提供了一种计算机可读介质,该计算机可读介质可以是上述实施例中描述的电子设备中所包含的;也可以是单独存在,而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个程序,当上述一个或者多个程序被一个该电子设备执行时,使得该电子设备实现如上述实施例中所述的电子设备的主题变换的方法。
例如,所述电子设备可以实现如图1中所示的,在步骤S11,代理节点转发访问请求到对象存储节点;步骤S12,根据所述访问请求写入最新版本文件到所述对象存储节点;步骤S13,在所述对象存储节点中查找对象最新历史版本文件;步骤S14,根据所述最新版本文件和旧的当前版本文件,判断是否需要进行版本处理;步骤S15,若是,则根据预设的版本处理规则处理所述最新版本文件和旧的当前版本文件;步骤S16,根据预设的数据更新规则更新object表的数据。
应当注意,尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元,但是这种划分并非强制性的。实际上,根据本公开的实施方式,上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之,上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。
此外,尽管在附图中以特定顺序描述了本公开中方法的各个步骤,但是,这并非要求或者暗示必须按照该特定顺序来执行这些步骤,或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选地,可以省略某些步骤,将多个步骤合并为一个步骤执行,以及/或者将一个步骤分解为多个步骤执行等。
通过以上的实施方式的描述,本领域的技术人员易于理解,这里描述的示例实施方式可以通过软件实现,也可以通过软件结合必要的硬件的方式来实现。

Claims (10)

1.一种基于Openstack-Swift的对象历史版本管理方法,其特征在于,所述方法包括:
代理节点转发访问请求到对象存储节点;
根据所述访问请求写入最新版本文件到所述对象存储节点;
在所述对象存储节点中查找对象最新历史版本文件;
根据所述最新版本文件和旧的当前版本文件,判断是否需要进行版本处理;
若是,则根据预设的版本处理规则处理所述最新版本文件和旧的当前版本文件;
根据预设的数据更新规则更新object表的数据。
2.根据权利要求1所述的方法,其特征在于,所述根据预设的版本处理规则处理所述最新版本文件和旧的当前版本文件,包括:
对所述所有版本文件按照时间进行排序;
保留排序后的历史版本文件中预设数量的最新历史版本文件,并删除其他历史版本文件。
3.根据权利2所述的方法,其特征在于,所述对所述所有版本文件按照时间进行排序之前,包括:
若需生成历史版本文件,则将所述旧的当前版本文件重命名为历史版本文件。
4.根据权利要求3所述的方法,其特征在于,所述根据预设的数据更新规则更新object表的数据,包括:
对象存储节点向元数据节点发送元数据更新请求;
查询元数据节点的object表里的对象元数据信息,当查到后向历史对象表里插入所查询到的对象元数据;
根据所述更新请求更新所述object表的数据。
5.根据权利要求4所述的方法,其特征在于,所述访问请求包括:
写入访问请求、删除访问请求、更新访问请求。
6.一种基于Openstack-Swift的对象历史版本管理装置,其特征在于,所述装置包括:
发送模块,用于代理节点转发访问请求到对象存储节点;
写入模块,用于根据所述访问请求写入最新版本文件到所述对象存储节点;
查找模块,用于在所述对象存储节点中查找对象最新历史版本文件;
判断模块,用于根据所述最新版本文件和旧的当前版本文件,判断是否需要进行版本处理;
处理模块,用于若是,则根据预设的版本处理规则处理所述最新版本文件和旧的当前版本文件;
更新模块,用于根据预设的数据更新规则更新object表的数据。
7.根据权利要求6所述的装置,其特征在于,所述处理模块包括:
第一处理单元,用于对所述所有版本文件按照时间进行排序;
第二处理单元,用于保留排序后的历史版本文件中预设数量的最新历史版本文件,并删除其他历史版本文件。
8.根据权利要求7所述的装置,其特征在于,所述装置还包括:
重命名模块,用于若需生成历史版本文件,则将所述旧的当前版本文件重命名为历史版本文件。
9.根据权利要求8所述的装置,其特征在于,所述更新模块还包括:
请求单元,用于对象存储节点向元数据节点发送元数据更新请求;
查询单元,用于查询元数据节点的object表里的对象元数据信息,当查到后向历史对象表里插入所查询到的对象元数据;
更新单元,用于根据所述更新请求更新object表的数据。
10.根据权利要求9所述的装置,其特征在于,所述访问请求包括:
写入访问请求、删除访问请求、更新访问请求。
CN201910113190.0A 2019-02-13 2019-02-13 基于Openstack-Swift的对象历史版本管理方法和装置 Pending CN111562936A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910113190.0A CN111562936A (zh) 2019-02-13 2019-02-13 基于Openstack-Swift的对象历史版本管理方法和装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910113190.0A CN111562936A (zh) 2019-02-13 2019-02-13 基于Openstack-Swift的对象历史版本管理方法和装置

Publications (1)

Publication Number Publication Date
CN111562936A true CN111562936A (zh) 2020-08-21

Family

ID=72071351

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910113190.0A Pending CN111562936A (zh) 2019-02-13 2019-02-13 基于Openstack-Swift的对象历史版本管理方法和装置

Country Status (1)

Country Link
CN (1) CN111562936A (zh)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102193925A (zh) * 2010-03-05 2011-09-21 新奥特(北京)视频技术有限公司 一种文稿系统中文稿在线多版本管理的方法和装置
US20130226978A1 (en) * 2011-08-12 2013-08-29 Caitlin Bestler Systems and methods for scalable object storage
CN105357201A (zh) * 2015-11-12 2016-02-24 中国科学院信息工程研究所 一种对象云存储访问控制方法和系统
CN106020935A (zh) * 2016-05-26 2016-10-12 国云科技股份有限公司 一种跨版本运行openstack组件服务的方法
US20180145983A1 (en) * 2016-11-22 2018-05-24 Nexenta Systems, Inc. Distributed data storage system using a common manifest for storing and accessing versions of an object

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102193925A (zh) * 2010-03-05 2011-09-21 新奥特(北京)视频技术有限公司 一种文稿系统中文稿在线多版本管理的方法和装置
US20130226978A1 (en) * 2011-08-12 2013-08-29 Caitlin Bestler Systems and methods for scalable object storage
CN105357201A (zh) * 2015-11-12 2016-02-24 中国科学院信息工程研究所 一种对象云存储访问控制方法和系统
CN106020935A (zh) * 2016-05-26 2016-10-12 国云科技股份有限公司 一种跨版本运行openstack组件服务的方法
US20180145983A1 (en) * 2016-11-22 2018-05-24 Nexenta Systems, Inc. Distributed data storage system using a common manifest for storing and accessing versions of an object

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
沈志豪 等: "基于分布式存储的企业文档云平台", 《电力信息与通信技术》, 31 December 2017 (2017-12-31), pages 89 - 95 *

Similar Documents

Publication Publication Date Title
US10248356B2 (en) Using scratch extents to facilitate copying operations in an append-only storage system
US8190741B2 (en) Customizing a namespace in a decentralized storage environment
US9967298B2 (en) Appending to files via server-side chunking and manifest manipulation
US10929419B2 (en) Object storage backed file system
US9323758B1 (en) Efficient migration of replicated files from a file server having a file de-duplication facility
US10671635B2 (en) Decoupled content and metadata in a distributed object storage ecosystem
US9547706B2 (en) Using colocation hints to facilitate accessing a distributed data storage system
US11321291B2 (en) Persistent version control for data transfer between heterogeneous data stores
CN112236758A (zh) 云存储分布式文件系统
US9367569B1 (en) Recovery of directory information
US20130339314A1 (en) Elimination of duplicate objects in storage clusters
US7054887B2 (en) Method and system for object replication in a content management system
US9569515B2 (en) Facilitating distributed deletes in a replicated storage system
EP3811229B1 (en) Hierarchical namespace service with distributed name resolution caching and synchronization
US11120046B2 (en) Data replication in a distributed storage system
GB2439578A (en) Virtual file system with links between data streams
US11397749B2 (en) Asynchronous replication of in-scope table data
US11151081B1 (en) Data tiering service with cold tier indexing
US9619322B2 (en) Erasure-coding extents in an append-only storage system
KR20090063733A (ko) 다중 복제를 지원하는 분산 파일 시스템에서 데이터 서버의복구 방법 및 그에 적당한 메타데이터 스토리지 및 저장방법
US20180276267A1 (en) Methods and system for efficiently performing eventual and transactional edits on distributed metadata in an object storage system
US8612717B2 (en) Storage system
CN111562936A (zh) 基于Openstack-Swift的对象历史版本管理方法和装置
US9967310B2 (en) Using an RPC framework to facilitate out-of-band data transfers
CN113448920A (zh) 管理存储系统中的索引的方法、设备和计算机程序产品

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination