一种S3对象存储桶级数据在线迁移的方法和系统与流程

文档序号:33483173发布日期:2023-03-15 13:18阅读:36来源:国知局
一种S3对象存储桶级数据在线迁移的方法和系统与流程
一种s3对象存储桶级数据在线迁移的方法和系统
技术领域
1.本发明涉及数据存储迁移技术领域,具体为一种s3对象存储桶级数据在线迁移的方法和应用该方法的系统。


背景技术:

2.对象存储每天承载大量的数据量,当桶内数据量较大时,对于用户来说将数据从源端某个桶迁移到目的端某个桶是非常复杂繁琐的。传统的方法需要首先将桶内数据下载到本地,再将其上传到目的端存储桶中,整个过程非常繁杂,需要频繁进行操作。目前,现有的一些成熟技术也给出了能够优化数据迁移过程的方法。
3.如申请号为cn202210165741.x的中国发明专利申请文件中公开的一种对象存储数据迁移的方法,该方法包括:响应于接收到数据迁移的指令,将源端的存储桶信息和存储桶的索引分片信息同步到目的集群中;获取存储桶的索引分片的数量,目的集群上的迁移工具根据存储桶的索引分片的数量创建相同数量的线程;迁移工具控制每个线程分别读取一个索引分片信息,并根据索引分片信息将对应的对象写入目的集群。通过使用该发明的方案,能够显著提高数据迁移的性能和效率。
4.又如申请号为cn202110654199.x的中国发明专利申请文件中公开的一种对象存储跨集群海量数据迁移方法及系统,该方法包括:步s1,接收用户发出的迁移任务请求和建立的子任务;步s2,根据建立子任务的相关信息,生成迁移任务的对应配置文件,并将建立的子任务和迁移任务的对应配置文件相关信息以oss对象存储至后端数据库的任务队列中;步s3,按预定时长扫描后端数据库中已存储的任务队列,将处于正在等待状态和暂停状态的迁移任务调度起并执行;步s4,被调起的迁移任务以docker容器、k8s的job、进程中的任一种方式运行;步s5,根据迁移任务的类型启动对应类型的迁移插件进行迁移操作;步s6,所调用的对应迁移插件采用多级任务的方式完成数据迁移。而该方法的主要优势在于能够实现弹性的跨集群的海量数据的迁移。
5.但在实际的数据迁移过程中,上述的这些方法也仍然存在很多的缺陷,比如无法充分利用资源导致传输速率缓慢,无法支持随时暂停重启,无法支持失败重试,无法指定迁移规则,无法进行流量控制等,使调用对应厂商的sdk进行批量处理也无法得到有效解决。相关的系统设计也基本是单点部署,集中处理,迁移任务运行过程中出现问题需要从头开始迁移任务,错误代价高。
6.针对上述问题,本发明提供了一种新的针对s3对象存储桶级数据的迁移方法,该方法能够使得数据迁移传输的过程更为高效稳定的同时,仍然具备操作的便捷性。


技术实现要素:

7.本发明提供了一种新的针对s3对象存储桶级数据的迁移方法,该方法能够使得数据迁移传输的过程更为高效稳定的同时,仍然具备操作的便捷性。
8.本发明的上述技术目的是通过以下技术方案得以实现的:
一种s3对象存储桶级数据在线迁移的方法,先行创建任务并分配线程,获取源端对象的信息,通过任务发送模块将所述源端对象的信息按照设定的num和size两个参数分为多个batch,每个batch中存储有待迁移对象的信息,batchnum为每个批次中记录的对象总数量,batchsize为每个批次中记录的对象总大小,其中每个batch符合:总数量,batchsize为每个批次中记录的对象总大小,其中每个batch符合:对于每一个任务,该模块会创建一个队列,分好任务批次后会将其依次按顺序写入队列,进入待发送状态,任务发送模块维护这个任务批次队列,并且将分批信息反馈给任务管理中心,任务发送模块寻找空闲的迁移模块,从任务批次队列中取出一个batch信息,将其发送给空闲的迁移模块,迁移模块开启多线程执行对应的迁移任务,调取对应的接口,将一个batch中的所有源端对象的内容、元数据迁移到目的端桶中。
9.作为对本发明的优选,空闲的迁移模块判断方法为,当前迁移模块的总流量小于先前的设定阈值,且当前迁移模块没有同一任务的其他batch正在执行迁移。
10.作为对本发明的优选,若有多个迁移模块符合空闲条件,优先选择部署在目的端存储集群的迁移模块,若目标存储集群中有多个空闲迁移模块则选择目前流量最小的迁移模块。
11.作为对本发明的优选,若目标存储集群没有符合条件的空闲迁移模块,则在其他存储集群中选择符合空闲判断条件且当前流量最小的迁移模块作为空闲迁移模块。
12.作为对本发明的优选,若没有符合条件的迁移模块,那么该batch将会阻塞等待符合条件的迁移模块出现。
13.作为对本发明的优选,对迁移成功、迁移失败的对象分别打上success和failed标签,对失败对象超出阈值的batch打上abnormal标签,迁移执行完毕后将信息返回给任务管理中心,任务管理中心更新任务的相关记录。
14.作为对本发明的优选,对于被打上abnormal标记的batch,任务管理中心指定任务发送模块将其重新下发给空闲的迁移模块执行一次重试迁移操作。
15.作为对本发明的优选,重试迁移操作优先选择首次迁移过程应用到的迁移模块之外的其它迁移模块。
16.作为对本发明的优选,创建任务后,将任务状态置为run,任务迁移过程中通过手动发送暂停控制命令,任务管理中心收到命令后通知所有迁移模块暂停该任务的所有迁移线程,同时通知任务发送模块停止任务发送,并记录下此时的断点数据,将任务状态转移为pause;重新发送开始控制命令后,任务从之前暂停的地方继续进行,状态重新转移为run。
17.作为对本发明的优选,迁移过程中出现未知错误导致任务中断,则状态转移为abnormal,重新发送开始控制命令,任务重启,状态重新转移为run。
18.作为对本发明的优选,当一个任务的所有batch全部收到了迁移模块的反馈信息,任务管理中心将会停止这个任务的所有相关进程,将该任务状态置为finished,并且将成功的对象和失败的对象的信息分别记录为多个文件上传到目的端的桶中,再清除内存中所有与任务相关的记录以及本地落盘文件,释放存储空间。
19.作为对本发明的优选,在迁移任务结束后,对迁移完成后仍然被标记为failed的
对象再次进行重试,向任务管理中心发送重试命令,任务管理中心向目的端桶中获取失败对象记录文件,读取文件内容,对记录的失败对象重新进行迁移。
20.作为对本发明的优选,在创建任务前,任务管理中心确认源端和目的端相关配置,验证两端的连接性。
21.作为对本发明的优选,在创建任务前,先行确认迁移任务的相关过滤条件参数以及迁移过程中的控制参数。
22.作为对本发明的优选,通过s3相应接口执行list操作,获取所有待迁移对象的信息,对于待迁移数据量较大的任务,将信息进行落盘记录,以实现任务断点恢复。
23.一种s3对象存储桶级数据在线迁移的系统,用于实现上述任一s3对象存储桶级数据在线迁移的方法,包括任务管理中心、任务发送模块、源端桶和目标端桶,还包括有多个存储池,而单个存储池中又包括有多个迁移模块。
24.综上所述,本发明能够实现以下多项有益效果:1.本发明所给出的这种s3对象存储桶级数据在线迁移的方法,将源端庞大的数据对象按照预设的大小和数量分隔为多个批次,再将每一批次的部分数据对象通过迁移模块进行输送。由于大量的迁移模块对于各自不同批次的数据对象的传输速率和花费时间并不相同,因此会有迁移模块先行完成迁移传输并进入空闲状态。此时,任务发送模块能够快速发现处于空闲状态的迁移模块并利用该迁移模块对剩余批次的数据对象进行传输迁移,使得整个数据迁移过程始终处于高效的工作状态。
25.2.本发明所给出的这种s3对象存储桶级数据在线迁移的方法中,将用于控制管理的任务发送模块与用于对数据进行转移的迁移模块进行了分离解耦合,同时其中的迁移模块支持分布式部署,即便系统中的单个迁移模块出现问题也不会对整体的数据迁移产生较大的影响,并且根据数据迁移过程的实际场景,可以随时在需要缩短数据迁移时间的情况下增加参与传输的迁移模块,或是在空闲状态的迁移模块过多时减少参与该传输过程的迁移模块,使整个传输过程更加灵活和具有更广泛的适用性。
26.3.本发明所给出的这种s3对象存储桶级数据在线迁移的方法,迁移任务采用分批处理,以批次为单位进行管理,同时批次的数量和大小可以根据实际应用场景灵活设置,相比于常规的以单个桶为单位进行数据传输更加细化。同时这种自定义批次特性的传输方式,使得任务中断后无需从头开始,避免了额外的list请求和重复的迁移,为实现断点重启机制提供了条件。
27.4.本发明所给出的这种s3对象存储桶级数据在线迁移的方法通过对迁移过程中对象和batch打上标签的方式,来实现触发内部自动重试机制,在任务结束后还可以通过外部命令再次进行重试,多重重试机制确保了数据迁移的成功率。
28.5.本发明所给出的这种s3对象存储桶级数据在线迁移的方法可以随时控制数据迁移任务进行启动、暂停、重启等操作,具有管理灵活和可控性高的优点,也能够使得迁移任务管理体系具有更好的鲁棒性。
附图说明
29.图1为任务管理中心、任务发送模块和迁移模块之间的连接关系框图;图2为数据在线迁移过程中任务整体传输过程的流程框图;
图3为任务传输状态转移变化示意图。
具体实施方式
30.以下具体实施例仅仅是对本发明的解释,其并不是对本发明的限制,本领域技术人员在阅读完本说明书后可以根据需要对本实施例做出没有创造性贡献的修改,但只要在本发明的权利要求范围内都受到专利法的保护。
31.本方案是通过以下技术手段实现的:实施例1:在本实施例中,首先需要说明的是,所给出的这种s3对象存储桶级数据在线迁移的系统主要包括三个部分:任务管理中心,任务发送模块,迁移模块,还包括源端桶、目标端桶和多个存储池,而单个存储池中又包括有多个迁移模块。其中:1、任务管理中心:接收客户控制台的请求,以桶级为单位创建任务,对任务进行管理、控制。接收迁移模块返回的信息,同时负责记录迁移过程中产生的相关数据。
32.2、任务发送模块:将需要运行的任务进行拆分,自动寻找可用的迁移模块,以批次(batch)为单位将拆分后的任务发送给迁移模块,维护迁移模块索引。
33.3、迁移模块:以批次为单位实际执行相应的数据迁移任务,负责记录每个batch的状态,支持存在多个迁移模块,可以进行分布式部署,部署到不同的存储池,每个迁移模块启动时候会在任务发送模块进行注册。
34.通过上述的s3对象存储桶级数据在线迁移的系统,能够实现一种在保证操作的便捷性的前提下,使数据迁移传输的过程更为高效稳定的s3对象存储桶级数据在线迁移的方法。
35.具体的,该方法的实现步骤如下:首先创建任务并根据实际情况分配线程,将任务状态置为run,获取源端对象的信息,任务发送模块将其按照设定的num和size两个参数将整个任务分为多个batch,每个batch中存储一定的待迁移对象信息,要求每个batch符合:batchnum ≤ num ,batchsize ≤ size;其中batchnum表示每个批次中记录的对象总数量;而batchsize表示每个批次中记录的对象总大小。
36.对于每一个任务,该模块会创建一个队列(queue),分好任务批次后会将其依次按顺序写入队列,进入待发送状态,任务发送模块维护这个任务批次队列,并且将分批信息反馈给任务管理中心,随后任务管理中心向任务发送模块发出信号,任务发送模块寻找空闲的迁移模块,从任务批次队列中取出一个batch信息,将其发送给所寻找到的空闲迁移模块。
37.在这里需要强调的是,在整个迁移过程中,由于不同模块中数据的迁移速度、处理突发状况或是应对外界干扰的情况都是不同的,因此具体到每一个迁移模块的状态是否为空闲,也需要对其实时进行判断。
38.具体的,在本实施例所给出的这种方法中,筛选判断迁移模块的状态是否为空闲的判断条件包括:(1)当前迁移模块的总流量小于先前的设定阈值;(2)当前迁移模块没有同一任务的其他batch正在执行迁移。
39.当一个迁移模块同时满足上述条件时,说明该模块当前被占用的流量在允许范围之内,能够保证传输该batch予以分配足够的流量以保证较高的迁移传输速率,同时该迁移模块的当前流量能够全部被用于该batch的迁移,具有极高的传输迁移效率。
40.在实际进行迁移的过程中,可能会出现同时存在有多个迁移模块符合上述条件的情况,由于迁移模块分布式部署在多个存储池中,因此在选择迁移模块时,会优先选择那些部署在目的端存储集群的存储池中的迁移模块,以减少网络传输过程中的延迟;进一步的,当目标池子中又出现有多个空闲迁移模块也都同时满足上述条件时,则选择目前流量最小的迁移模块作为空闲迁移模块参与该batch的迁移过程,以实现更加对空余流量更为充分的利用,提升数据的迁移传输速率。当然,还可以在系统中设置允许使用非目标存储池模块的配置选项,当该选项开启时,如果部署在目的端存储集群的存储池中没有空闲迁移模块,那么允许选取其他存储池中当前流量最小的迁移模块作为空闲模块参与该batch的迁移传输。在极少数的情况下,若始终无法找到符合条件的迁移模块,那么该batch将会阻塞等待,直至符合条件的迁移模块出现。空闲状态的迁移模块通过开启多线程执行对应的迁移任务,调取对应的接口,将一个batch中的所有源端对象的内容、元数据迁移到目的端桶中,当全部的batch传输完成后,就实现了对数据整体的迁移。
41.实施例2:与实施例1相同的,本实施例中所涉及的s3对象存储桶级数据在线迁移的系统同样包含有任务管理中心,任务发送模块,迁移模块三个部分,还包括源端桶、目标端桶和多个存储池,而单个存储池中又包括有多个迁移模块。在本实施例中,对于所实现的s3对象存储桶级数据在线迁移的方法进行了进一步的改进优化,具体的,该方法的实现步骤如下:创建任务并根据实际情况分配线程,将任务状态置为run,获取源端对象的信息,任务发送模块将其按照设定的num和size两个参数将整个任务分为多个batch,每个batch中存储一定的待迁移对象信息,要求每个batch符合:batchnum ≤ num ,batchsize ≤ size;其中batchnum表示每个批次中记录的对象总数量;而batchsize表示每个批次中记录的对象总大小。
42.对于每一个任务,该模块会创建一个队列(queue),分好任务批次后会将其依次按顺序写入队列,进入待发送状态,任务发送模块维护这个任务批次队列,并且将分批信息反馈给任务管理中心,随后任务管理中心向任务发送模块发出信号,任务发送模块寻找空闲的迁移模块,从任务批次队列中取出一个batch信息,将其发送给所寻找到的空闲迁移模块。
43.在这里需要强调的是,在整个迁移过程中,由于不同模块中数据的迁移速度、处理突发状况或是应对外界干扰的情况都是不同的,因此具体到每一个迁移模块的状态是否为空闲,也需要对其实时进行判断。
44.具体的,在本实施例所给出的这种方法中,筛选判断迁移模块的状态是否为空闲的判断条件包括:(1)当前迁移模块的总流量小于先前的设定阈值;(2)当前迁移模块没有同一任务的其他batch正在执行迁移。
45.当一个迁移模块同时满足上述条件时,说明该模块当前被占用的流量在允许范围
之内,能够保证传输该batch予以分配足够的流量以保证较高的迁移传输速率,同时该迁移模块的当前流量能够全部被用于该batch的迁移,具有极高的传输迁移效率。
46.在实际进行迁移的过程中,可能会出现同时存在有多个迁移模块符合上述条件的情况,由于迁移模块分布式部署在多个存储池中,因此在选择迁移模块时,会优先选择那些部署在目的端存储集群的存储池中的迁移模块,以减少网络传输过程中的延迟;进一步的,当目标池子中又出现有多个空闲迁移模块也都同时满足上述条件时,则选择目前流量最小的迁移模块作为空闲迁移模块参与该batch的迁移过程,以实现更加对空余流量更为充分的利用,提升数据的迁移传输速率。当然,还可以在系统中设置允许使用非目标存储池模块的配置选项,当该选项开启时,如果部署在目的端存储集群的存储池中没有空闲迁移模块,那么允许选取其他存储池中当前流量最小的迁移模块作为空闲模块参与该batch的迁移传输。在极少数的情况下,若始终无法找到符合条件的迁移模块,那么该batch将会阻塞等待,直至符合条件的迁移模块出现。空闲状态的迁移模块通过开启多线程执行对应的迁移任务,调取对应的接口,将一个batch中的所有源端对象的内容、元数据迁移到目的端桶中。
47.在全部的batch迁移过程结束后,由于传输过过程中出现的一些错误,会导致一些batch部分或者全部无法成功完成传输的情况发生。因此在每一个batch的迁移传输过程中,迁移模块会对迁移成功、迁移失败的对象分别打上success和failed标签,对失败对象过多的batch打上异常即abnormal标签,迁移执行完毕后将这些标签信息返回给任务管理中心,同时任务管理中心更新任务的相关记录。对于被打上abnormal标记的batch,任务管理中心会指定任务发送模块将其重新下发给迁移模块执行一次重试操作。在这里,如果在有较多空闲迁移模块可选择的情况下,会优先先择与前一次传输过程不相同的另一迁移模块,以确保该batch不是因为偶然的网络原因导致的失败数量过多。而对于单次迁移完成后仍然被标记为failed的对象,也需要再次进行重试,向任务管理中心发送重试命令,任务管理中心向目的端桶中获取失败对象记录文件,读取文件内容,对记录的失败对象重新进行迁移。
48.实施例3:进一步的,由于在实际数据传输迁移的过程中,在一些特殊情况下,需要暂停数据的传输已对部分数据进行核验检查,因此在本实施例在实施例1或2的基础上,进一步引入了反应任务实时传输状况的状态指标。
49.当任务创建后,将任务状态置为run,任务整体进入传输状态,此处具体传输过程与实施例1和2相同,不在进行赘述。
50.在任务传输过程中的某一时刻,通过手动发送暂停控制命令,任务管理中心收到命令后通知所有迁移模块暂停该任务的所有迁移线程,同时通知任务发送模块停止任务发送,并记录下此时的断点数据,将任务状态转移为pause。如果需要断点重启,可以通过手动的方式重新向任务管理中心发送开始控制命令,则任务从之前暂停的地方重新进行传输,状态重新转移为run。若迁移过程中出现未知错误导致任务中断,则任务状态转移为abnormal,通过手动重新发送开始控制命令,任务同样会重启,状态重新转移为run,重新进行传输过程。
51.待一个任务的所有batch全部收到了迁移模块的反馈信息,任务管理中心将会停止这个任务的所有相关进程,将该任务状态置为finished,并且将成功的对象和失败的对象的信息分别记录为多个文件上传到目的端的桶中。清除内存中所有与任务相关的记录以
及本地落盘文件,释放存储空间。
52.实施例4:进一步的,在实施例1或2所给出的s3对象存储桶级数据在线迁移的方法的基础上,还可以在创建任务前增加任务管理中心确认源端和目的端相关配置的步骤,验证两端的连接性,同时确认迁移任务的相关过滤条件参数,例如指定前缀,指定列表,指定对象名等,以此来对源端桶中的对象进行过滤。实际迁移中只对符合条件的对象进行迁移;还可以对迁移过程中的控制参数进行确认,例如对象覆盖规则,目的端前缀,任务流量控制等。随后通过s3相应接口执行list操作,获取所有待迁移对象的信息,对于待迁移数据量很大的任务,会将信息进行落盘记录,以便突发状况下的任务断点恢复,并且可以防止信息过大占用大量的内存。
53.以上所述,仅为本发明的具体实施方式,但本发明的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,可轻易想到各种等效的修改或替换,这些修改或替换都应涵盖在本发明的保护范围之内。因此,本发明的保护范围应以权利要求的保护范围为准。
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1