如何将海量数据迁移上云

背景

众所周知,云计算的出现改变了IT世界的格局,更低廉的成本和更加易于扩展的特点都成为了传统软件行业改变的动力。而阿里云在此基础上提供了更加完善的服务,更高的可靠性,以及更加低廉的价格,成为了业界值得优先考虑的品牌。

如果您有成千上万的文档、图片、音视频文件需要上传到OSS上来,或者从其他的云存储产品上迁移过来,如何才能应对规模如此庞大的数据迁移,如何处理迁移过程中业务上的新增数据?

OSS有一套完整的无缝数据迁移方案可以帮您解决这些问题。

方案

整个迁移过程分为下面几个步骤:

  • 配置Bucket回源属性,配置好数据在OSS读取miss之后回源的地址。配置好之后如果访问某Object miss的时候你的客户端可以根据OSS返回的302重定向去配置的地址读取文件;
  • 配置迁移工具,从源端向OSS迁移数据,这一步不影响您的业务,异步的从源站将数据搬迁到OSS;
  • 数据搬迁接近完成的时候,将业务上的读写从之前的源站切换到OSS;
  • 等待迁移工具从源搬迁完所有的老数据(这种场景下如果您的业务有对数据的覆盖写是需要注意的,可能会造成老数据覆盖新数据)

如上所说,我们有两种方式Bucket回源属性可以做到无缝迁移,即镜像和重定向:

上图是“利用镜像做无缝数据迁移示意图”,图中带有数字标记的箭头就是数据访问miss时的数据流向。在镜像回源的方式下用户访问OSS如果Object miss,那么OSS会替用户从源站读回文件,并写入到OSS,这样一来,如果用户的请求可以遍历所有的文件,那么这个异步的迁移过程其实是可以省略掉的(当然,这也会带来一些新的问题,后文我们会提到)。

上图是“利用重定向做无缝迁移示意图”,图中有数字标记的箭头就是数据访问miss时的数据流向。在配置重定向回源的方式下,如果Object miss,那么需要您的客户端去源站去读取一次数据。这就要求您的客户端要能理解http协议中的3xx重定向语义(OSS的重定向回源是通过3xx重定向来实现的)。需要注意的是,在这种回源方式下,OSS不能自动帮用户搬迁数据,用户的数据必须依靠迁移工具/服务来异步的搬迁到OSS上面来。

图中也能看到在这种场景下配合CDN一起使用,那么文件会cache在CDN上,无需每次miss之后都回源站读取,也是一种减少延迟、节省源站流量的方式。如果不使用CDN,那么就需要用户自己完成回源站读取数据的过程。

纵观上面的两张图,在您配置Bucket的回源属性之后,再开启数据迁移过程,在业务数据大部分都搬迁到OSS之后,再将整个业务的读写全部切换到OSS。这个时候回源功能就能帮您处理那些尚未搬迁过来的数据,无需停服,无缝衔接。等到所有的数据都搬迁完毕之后就可以关闭回源,停掉数据迁移,整个向OSS迁移数据的方式就完成了。

使用建议

如果要迁移的文件较少,建议配置镜像回源的方式,按照文件列表逐一访问OSS,OSS会把所有的文件从源站读取出来,回写到您的Bucket,这种方式是一个最简单的迁移方案。

如果需要迁移的文件量比较大,或者文件的大小比较大,那么由于镜像回源的方式带宽有限,依靠这种方式来搬迁数据可能会花费比较长的时间,影响您的使用体验,建议使用“重定向回源+迁移工具/服务”的方式,如果Object miss,直接让客户端从源站读取数据,由迁移工具/服务来异步的搬迁数据,不影响您的服务。

如果您的业务对延迟比较敏感,建议在大部分数据迁移完成之后再将业务切到OSS上来,否则像文章开头的两张图中所示,如果数据访问miss的话,用户的请求都会经过一个比直接访问OSS上的Object更长的过程,这一过程会增加访问延迟,可能会降低您的用户体验,所以这个重定向或者镜像的数据比例要控制的尽可能小一些。

配置步骤

本部分主要包含Bucket回源属性的配置,以及迁移工具/服务的使用方法。

配置Bucket回源属性

要配置Bucket的回源属性,要在Bucket属性的“回源设置”里面添加规则。如下图:


这里的规则分为两种:镜像回源和重定向回源。

  • 镜像回源:用户访问OSS上的Object,如果文件不存在,就按照镜像回源里的Url向源站去取数据,回写到OSS,回写完成之后Object就自动搬迁到了OSS上面,下一次访问就不会再出现Object不存在的情况;
  • 重定向回源:用户访问OSS上的Object,如果文件不存在,按照配置向用户的客户端返回一个302重定向跳转,用户客户端从配置的源站读取数据,这种方式下OSS不会从用户的源站拉取数据回来回写到OSS,下一次访问仍然会向用户客户端返回一次302重定向跳转,直到用户自己把这个Object写入到OSS为止。

下图为如何配置镜像回源:

下图为如何配置重定向回源:

图中可以看到镜像方式只支持http code设置为404这种方式,也就是我们所说的访问Object miss的情况下才会去做镜像。重定向回源中回源条件中的http code可以设置400-599之间的错误码,但是在用回源实现无缝迁移的时候这个地方要填成404。其他的选项依照您的实际情况使用。

使用迁移工具/服务

迁移工具可以将您本地或者第三方云存储服务上的文件同步到OSS上。 我们的迁移工具有以下主要特性:

  • 支持将本地、OSS、七牛、百度对象存储、金山对象存储的文件同步到指定OSS Bucket上;
  • 支持存量数据同步(允许指定只同步某个时间点之后的文件);
  • 支持增量数据自动同步;
  • 支持断点续传;
  • 支持上传/下载流量控制;
  • 支持并行list和并行数据下载/上传;

迁移工具Linux平台使用说明

迁移工具Windows平台使用说明

迁移服务。如果您有较大量级的数据,并且期望在较短的时间之内迁移到OSS上,除了迁移工具之外,我们的专业技术人员还可以为您提供多机器并行同步方案,请加旺旺群:904193608联系我们。

时间: 2024-10-01 06:02:46

如何将海量数据迁移上云的相关文章

每周聚划算 超值软件汇总:200元轻松迁移上云 5折抢云市场超值服务

总担心好价格稍纵即逝?云市场头条每周聚划算!超值软件汇总,致力于为大家发现.比价.筛选性价比最高的靠谱软件,让企业更加省心省力! 新年开始,小伙伴们的2017计划也要开始实现了,准备好上云.更新网站了么?本期推荐200元轻松迁移上云服务,上云随时随地随想,200元轻松搞定! 推荐1:HiShop云商城3代 多样化新零售+云商城3代+买一年送一年 云商城3代由专业的阿里云授权服务中心--HiShop自主研发.这一款可轻松打造B2C+O2O新模式的商城系统,带微信拼团特色营销,一键轻松开6大独立商城

数据迁移上云优化之 - 带宽压缩加速

现在云已经是一个趋势毋庸置疑,但是怎样在有限的时间内把数据弄上云端是个需要考虑的问题. 如果能增量复制,整个时间窗口可以不需要太关注,因为切换的时间窗口比较短. 但是如果是全量迁移,或者增量迁移前的全量迁移,则需要考虑时间窗口. 一般来说,从线下到线上,网络带宽都比较低,这个我在以前把香港机房的数据迁移到国内机房时深有同感,速度之慢难以忍受. 下面是一套加速方案: 下面是一个例子: 首先在本地服务器建立远程数据库服务器隧道 : ssh -C -L 6666:127.0.0.1:1921 post

一次数据库上云迁移性能下降的排查

背景介绍: 某客户目前正在将本地的业务系统迁移上云,测试过程中发现后台运营系统,在rds上运行时间明显要比线下PC上自建数据库运行时间要慢1倍,导致客户系统割接延期的风险.用户线下一台PC服务器的性能居然还比顶配的RDS跑的快,这让用户对RDS的性能产生了质疑,需要立刻调查原因. 问题分析: 通常SQL的执行时间在同等数据量的情况下发生变化主要有以下一些场景,其主要原因是由于优化器生成的执行计划发生了改变,这样则会导致SQL的执行时间发生较大的变化,当然可能变慢,也有可能变快,变慢是我们不想看到

Oracle数据库上云利器 阿里云发布数据库迁移服务ADAM

为了方便用户更安全快速地在云上开展数据库业务,阿里云在2017云栖大会•上海峰会上推出了业内首个覆盖数据全生命周期的应用与数据库迁移工具Advanced Database & Application Migration(以下简称ADAM),该服务使得企业能够将Oracle等数据库无缝迁移上云,在云上数据库MySQL.PPAS.AnalyticDB等开展业务. 阿里云提供了智能分析工具,可自动化提供迁移建议方案,最大程度简化操作流程,降低迁移成本,实现业务平滑升级.  同时,阿里云还宣布推出面向物

阿里云推出数据库迁移服务ADAM:Oracle数据库上云只需4步

为方便用户更安全快速地在云上开展数据库业务,阿里云在"2017云栖大会·上海峰会"上推出了业内首个覆盖数据全生命周期的应用与数据库迁移工具Advanced Database & Application Migration(ADAM),该服务使得企业能够将Oracle等数据库无缝迁移上云,在云上数据库MySQL.PPAS.AnalyticDB等开展业务. 传统数据库和云端数据库不兼容是阻碍企业上云的一大障碍,阿里云ADAM提供了一种绝佳的方案,全程仅需4步--迁移前,ADAM可对

平滑上云

随着云计算技术的不断发展和普及,使得对网络建设.业务运营.系统运维等多个角度对传统IT系统建设产生了深远的影响.越来越多的企业选择将应用系统迁移部署到云平台上,利用云计算平台产品特性构建低成本.弹性.高性能.高可靠性.高安全.按需获取计算能力的IT业务系统. 为了实现已有IT系统向云计算平台的迁移及新建系统的部署,保障系统迁移平滑演进.本文主要从大部分企业系统架构组件层面,比如网络层.应用服务层.文件存储层.数据库服务层等几个方面探讨如何将线下系统平滑的迁移到阿里云计算平台.   网络层 阿里云

传统大型企业平滑上云典型架构实践

      混合云构建是将企业本地数据中心资源与云资源的集成.对于大多数企业而言,为降低IT的成本和实现业务快速创新而采用云计算,在混合架构中是必然的选择.迁移老的应用和系统上云是有一定的时间和成本消耗,因此,选择一家能够帮助企业实施全面混合战略的云计算厂商,这对简化企业IT运营以及更轻松地实现业务目标至关重要.      企业对云的安全性要求优先级也是最高的,我们可以通过不同的云架构满足不同级别的安全要求,利用云计算的优势只需要给使用的服务付费,在保护云上资产安全的同时降低为安全消耗的成本.

上云有隐性成本? 用户要警惕五个坑

上云与否,早已不是企业的选择题,计算.网络.存储资源的虚拟化为业务流程带来了灵活可扩展的便利性.IT资源"拿来就用.想用就有"的理念让企业有了更多选择,也使得基础设施的部署成本有效削减.不过在企业迁移上云的过程中,想获得真正的实惠却并不简单,除了要转变传统的业务理念,还要做出合理部署,否则就会遇到一些坑. 上云有隐性成本 用户要警惕五个坑(图片来自Luke Lonergansf) 对于任何一家企业来说,每年的巨额IT支出难以避免,而且买来的资源能否充分利用也要画一个问号,更不要说背后的

MySQL数据库上云四年打磨,五大经典案例让你不再“蓝瘦”

通过以往的经验分析得出,数据库上云问题可能有以下几种情况: 1.         数据库跨平台迁移(PG->MySQL.Oracle->MySQL),淘宝以前就有大量的Oracle迁到MySQL,也是发生过很多问题. 2.         跨版本升级(MySQL:5.1->5.5.5.5->5.6),导致了性能问题. 3.         数据库的执行计划.优化器.参数配置和硬件配置. 4.         云上较明显就是网络延迟(跨可用区域访问.公网延迟.网卡饱满).   应用场