Ossimport 大数据量迁移方案总结

本文涉及的产品
对象存储 OSS,20GB 3个月
对象存储 OSS,恶意文件检测 1000次 1年
对象存储 OSS,内容安全 1000次 1年
简介: 背景: 面临客户不断的将友商的存储数量迁移到阿里云上。ossimport 工具越来越多的暴露在用户端,但是合理的利用 ossimport 工具以及良好的迁移架构数据能否帮助用户高效的快速迁移。但是如果对 ossimport 不熟知,而且迁移架构没有经过测试,反而会降低我们的迁移效率,影响客户的全面战略上云计划安排。

背景:

面临客户不断的将友商的存储数量迁移到阿里云上。ossimport 工具越来越多的暴露在用户端,但是合理的利用 ossimport 工具以及良好的迁移架构数据能否帮助用户高效的快速迁移。但是如果对 ossimport 不熟知,而且迁移架构没有经过测试,反而会降低我们的迁移效率,影响客户的全面战略上云计划安排。

 

迁移架构的演进:

传统的迁移方式:

本地 localfile -> 迁移到 OSS 云端

第三方存储 -> 迁移到 OSS 云端

以上的传统迁移方式都会遇到一个功能的问题就是公网的干扰因素不可以避免,尤其是当下的国内网络环境错综复杂,很难保证公网没有拥塞抖动,即便是大物理带宽的情况也不可幸免。于是有了 vpc 网络环境的改进。

进化 VPC 环境迁移:

在引入了 VPC 的概念后,用户解决了网络上带来的慢速的头疼问题,带来了一系列好处,,这里的  VPC 概念是指(通过 OSS 内网传输 or 走 VPC 专线传输)

  • 迁移数据源到 OSS 端,没有带宽流量的限制(不包括 ECS 内部限制)
  • VPC 内网环境迁移,使用 OSS 内网域名,不收取流量费用。
  • VPC 环境延迟对比公网极低,基本无丢包,除非遇到线路故障

第三方 storage -> 数据盘 copy -> IDC 机器 -> VPC 专线 push->  OSS 云端

52b06baca42a60c875b4bd700006c85fc08b98fd

第三方 storage <- pull ECS -> VPC 专线 push -> OSS 云端

24ef3328ce5f3dcc2d9148c3be49ca67a184a8d0

第三方 storage <- pull ECS  -> OSS 内网 endpoint push -> OSS 云端

ac0f382b0212e241ea62bce975a6251b4477c43d

本地文件 -> OSS 内网 endpoint push -> OSS 云端

ee9ebf3c8578a0000a6823904aebff3fd10fb0fc

本地文件 -> VPC 专线 push -> OSS 云端

5b9ee61c60d09c63d9364c0316ea1eaec3536903

 

合理迁移配置:

目前还是推荐客户按照 VPC 的环境方式进行迁移,在服务体验感上有很大提升。在迁移过程中 OSS SLA 没有承诺迁移速度有明确指标,而且迁移数据和多因素有关(机器配置、数据量、网络、线程、限流等),所以根据实际情况进行问题诊断。

首先在迁移之前,要求使用者要先大致的学习一下我们的配置属性说明,和相关文件的作用,日志存储,异常处理等。

https://help.aliyun.com/document_detail/56990.html?spm=a2c4g.11174283.6.1079.sbu1ch

 

配置迁移文件单机版:

迁移前要明确用户的迁移体量和文件数量。目的是合理的配置 task 和线程数量,以及 ossimport 的工作模型。

一般迁移体量小于 30TB 的完全可以采用单机模式进行迁移,单机版可以配置多线程的方式进行迁移,调节 workerTaskThreadNum 参数,需要注意的是如果是高配,物理机的话,数量可以调大,可以参考 平均文件 size * 线程数量,对比 memory 是否够用,同时也要参考 CPU 核心数量是否能否抗住这种并发量。

当高并发,且文件的 size 较大时,如果配置数量不合理,会出现设备 OOM 的情况,可以通过 /var/log/message 看到,这是要么选择降低并发线程数量,要么是增大机器配置。

如果是本地 ECS 或者第三方存储迁移到 OSS ,请注意源是否有限流,目前经常会出现源发现有大流量流出后直接给限制住,导致迁移速度无法增长。关键参数 workerMaxThroughput(KB/s),如果源没有限制,可以释放调大这数。

其他 sys.properties 文件中的属性不要随意改动。

 

在迁移中可能遇到的问题:

数据流量一直涨不上去速度不快,这种情况,检查几个相关因素

  • 迁移的网络环境
  • 源流是否有限制
  • 线程配置数量是否合理。
  • 本机带宽是否被打满
  • 机器负载是否飚高

 

console.sh 各项指标不明白,我们来解释一下

JobName:local_test 迁移的任务名称可改

JobState:Running 任务运行中

PendingTasks:0 挂起的任务指已经扫描完被挂起的任务数

DispatchedTasks:1 已经扫描完的任务

RunningTasks:0 运行中的任务

SucceedTasks:0 成功任务

FailedTasks:0 失败任务

ScanFinished:true 是否已经扫描完成,如果配置了增量迁移,这个数一直都是 False

以上所有的 task 相加一定等于 DispatchedTasks。如果遇到文件先用 bash console.sh stat 看下任务数量是否都正常。如果出现失败任务一定要看下日志目录下的记录 ossimport2.log ,分布式是 import.log


三、JOB running 中日志出现了以下异常

channels.OverlappingFileLockException 是在扫描源文件,拉取源流超时导致,在 log 中可以看到是哪个文件超时,手动 curl 测试一下源是否能否访问。

 

四、如果出现的 FailTask 以后怎么办

ossimport 会对每个失败的文件有三次重试,如果依然失败,请在第一遍以后直接使用 bash console.sh retry 重试。

 

配置分布式迁移文件

分布式迁移模式的数据体量都是大于 30TB ,甚至上 PB 的级别才会用到,迁移模型也比较特殊,是通过 master 带多个 worker 协同工作,类似 nginx 的模型,master 只是用来切割任务和分配任务,对数据量庞大的用户,worker 的数量也要配置好,才能高效迁移。

首先通过用户文件数量,来计算任务数,该项目中用户总文件数 424421917 个,源头限制 3Gbps ,客户的机器数量有 12 台。

计划分成 20000 个 task ,每个 task 迁移 21221 个文件。每个 worker 机器开 200 线程,并发处理 200 个 task ,并发也就是能处理 2400 个,升级 17600 个 task 在队列中。

源流限制是 3000Mbps ,其实并发 worker 全部也就能跑到 375MB ,所以即便是你的线程开的再多,机器配置在高其他的线程也只能阻塞住。

job.cfg 迁移数据配置文件

b9ceb678d5db4aaa337edc44bf842469ba9a3eea

sys.properties 迁移工具调优配置文件

1544c3426bc8761de8f5945d97931b6a4a82fc6e 

迁移过程中可能遇到的问题:

一、设备日志中出现 OOM

这种问题基本都是用户选型的机器配置不够导致 worker 的迁移进程被干掉。

 

二、master 的 workers  文件中 IP 顺序随便写?

master 的 worker 文件一定要将 master IP 放在第一行,worker 机器放在下面,不要随意乱放,不然用户会将 master 机器也当做 worker 分配任务,造成 master 流量过高被打死。

 

三、JOB running 中日志出现了以下异常

这个错误和单机版的原因是一致的。

 

四、使用分布式模式迁移过程中出现 hang 住

使用 bash console.sh stat  看下文件是否已经扫描完,如果扫描完后出现在执行任务过程中 hang 住 并且伴随有失败任务,已经超过了几个小时,直接用 bash console.sh retry 再 bash console.sh stat 看下,如果数量有再变,就已经恢复,如果任务数量依然没有变化,请提交工单到阿里云售后。

其余报错可以根据 logs/ 下的 import.log 来查找原因。

 

FAQ 

Q:配置文件中 srcPrefix 填写什么

A:代表文件迁移的前缀,如果是 bucket/ 迁移到 bucket/ 或者 本地 local/ 迁移到 bucket/ ,直接默认为空就行,如果源是 bucket/test/* 迁移到 bucket ,prefix 填写为 bucket/test,默认所有前缀为 bucket/test 的bucket 都会迁移到目标 bucket。

 

Q:配置文件中 destPrefix 填写什么

A:同上

 

Q:源文件是 URL list 该如果迁移

A:可以采用 ossimport 的 HTTPLIST 迁移方法

 

Q:分布式版如果分配 task 给 worker

A:通过在 master 上生成公私钥,然后在 sys.properties 文件配置好你的秘钥文件。

 

Q:是否有迁移案例可以参考

A:600TB 数据。12台 8U 16G 内存,千兆网卡,源流限制 3000Mbps/s迁移时间大概 25 田。

 

Q:源文件想定期扫描如有新文件就迁移到 OSS

A:OSSimport 支持增量迁移,可以先全量迁移,然后在开启增量迁移,设置好 interval 间隔时间,定期 OSS 会去源头扫描。

 

Q:能否限制 worker 的迁移速度。

A: OSSimport 通过 workerMaxThroughput(KB/s) 参数进行速度限制。

或者降低内存 javaHeapMaxSize 

 

Q:任务启动后 worker 上没有 ossimport 迁移进程

A:检查 conf/sys.properties 文件中配置的是否正确,不要和你的 脚本同级目录。

 


重点来了:ossimport 迁移工具白屏化提供出来了。


访问地址:http://oss2.zhangyb.mobi/ossimport


迁移步骤:

迁移服务化解决的问题:

对于用户的大数据量迁移,以及不懂编写迁移配置或者不善于计算迁移线程等配置的用户进自动配置下发和安装包下载以及任务数、线程数的配置

实现 master 的一键部署

1、 迁移服务化的地址

URL : http://oss2.zhangyb.mobi/ossimport

 

3a9b473af6f02541d38cadb34730f7c643980fae

2、 迁移模式

a)       目前分为了 3 种模式

b)       Localfile-to-oss  本地文件迁移到 OSS

c)        Httpurl-to-oss  通过 httpurl 的方式迁移,需要用户提供迁移列表地址

                     i.            格式举例 http://www.taobao.com/1/2/3/  1.jpg

                   ii.            格式举例 http://www.taobao.com/1/  2/3/1.jpg

d)       Cloud-to-oss 第三方云存储迁移到 oss

 ea6c706698ca94da242d7f99611a4b42a7568ede


 

3、 迁移数据量

大于 30TB 使用分布式迁移 小于 30TB 使用单机模式

5e9fc3f221261ea3e85f676d8bde9ed81ed7350a

 

4、 迁移模式:

4.1本地文件迁移到 OSS

用户将空白地方按照实际情况填写即可,srcprefix 以及 destprefix 如果都是跟下面,可以直接填写 / 即可,所有配置项都是必选,迁移数据量是已经选择好的,不用客户自己填写


         4.2、httpurl 迁移到 OSS

         所有配置项都是必选,迁移数据量是已经选择好的,不用客户自己填写

601ce25e56ad5ebc7b38f389a18fb02549b5dc3f

         4.3、       第三方云存储迁移到 OSS

         所有配置项都是必选,迁移数据量是已经选择好的,不用客户自己填写

f63248dfff604f8636ea47c95d2701eaf1e38542

 

5、 执行效果

举例:第三方云存储迁移到 OSS

6b5a71e7e41a9eeb7e8ced29b8bc2f4862a75467

 

6、 一键部署

0c7f825eaa739826752e41afe162fa0b2a23dff3

f372f692316a69bb8659d30c70986ca1d47e88f3


相关实践学习
基于MaxCompute的热门话题分析
本实验围绕社交用户发布的文章做了详尽的分析,通过分析能得到用户群体年龄分布,性别分布,地理位置分布,以及热门话题的热度。
SaaS 模式云数据仓库必修课
本课程由阿里云开发者社区和阿里云大数据团队共同出品,是SaaS模式云原生数据仓库领导者MaxCompute核心课程。本课程由阿里云资深产品和技术专家们从概念到方法,从场景到实践,体系化的将阿里巴巴飞天大数据平台10多年的经过验证的方法与实践深入浅出的讲给开发者们。帮助大数据开发者快速了解并掌握SaaS模式的云原生的数据仓库,助力开发者学习了解先进的技术栈,并能在实际业务中敏捷的进行大数据分析,赋能企业业务。 通过本课程可以了解SaaS模式云原生数据仓库领导者MaxCompute核心功能及典型适用场景,可应用MaxCompute实现数仓搭建,快速进行大数据分析。适合大数据工程师、大数据分析师 大量数据需要处理、存储和管理,需要搭建数据仓库?学它! 没有足够人员和经验来运维大数据平台,不想自建IDC买机器,需要免运维的大数据平台?会SQL就等于会大数据?学它! 想知道大数据用得对不对,想用更少的钱得到持续演进的数仓能力?获得极致弹性的计算资源和更好的性能,以及持续保护数据安全的生产环境?学它! 想要获得灵活的分析能力,快速洞察数据规律特征?想要兼得数据湖的灵活性与数据仓库的成长性?学它! 出品人:阿里云大数据产品及研发团队专家 产品 MaxCompute 官网 https://www.aliyun.com/product/odps&nbsp;
目录
相关文章
|
2天前
|
数据库 OceanBase 索引
OceanBase迁移服务(OMS)支持不同大小和复杂度的表的迁移
【2月更文挑战第25天】OceanBase迁移服务(OMS)支持不同大小和复杂度的表的迁移
23 3
|
存储 文件存储 对象存储
S3存储服务间数据同步工具Rclone迁移教程
目前大多项目我们都会使用各种存储服务,例如oss、cos、minio等。当然,因各种原因,可能需要在不同存储服务间进行数据迁移工作,所以今天就给大家介绍一个比较通用的数据迁移工具Rclone。
S3存储服务间数据同步工具Rclone迁移教程
|
2天前
|
存储 监控 负载均衡
TiDB数据迁移工具TiCDC:高效同步的引擎
【2月更文挑战第28天】TiCDC是TiDB生态中一款强大的数据迁移工具,它专注于实现TiDB增量数据的实时同步。通过解析上游TiKV的数据变更日志,TiCDC能够将有序的行级变更数据输出到下游系统,确保数据的实时性和一致性。本文将深入探讨TiCDC的原理、架构、应用场景以及使用方式,帮助读者更好地理解和应用这一工具,实现高效的数据迁移和同步。
|
2天前
|
SQL Go 数据库
TiDB Dumpling:高效数据导出解决方案
【2月更文挑战第28天】TiDB Dumpling作为TiDB生态系统中的一款逻辑备份工具,以其高效、易用和灵活的特性,在数据库数据导出领域崭露头角。本文将对TiDB Dumpling进行详细介绍,包括其原理、架构、适用场景、使用方式及与其他工具的对比,旨在帮助读者更好地理解和应用这一工具,实现高效的数据导出。
|
9月前
|
数据采集 Cloud Native 关系型数据库
实现业务零停机!NineData的PostgreSQL数据迁移能力解析
NineData推出了PostgreSQL业务不停服数据迁移能力。NineData实现了完全自动化的结构迁移和全量数据迁移,并提供了变更数据的迁移能力。这种能力可以实时监听源PostgreSQL中的变更数据,在完成全量迁移后将变更数据实时复制到目标PostgreSQL,实现源/目标PostgreSQL的动态复制。在PostgreSQL数据迁移过程中,业务可以正常提供服务,无需停服。最终,业务可以根据需求选择对应的时间点切换到目标PostgreSQL。
553 1
|
5月前
|
存储 关系型数据库 MySQL
存储成本最高降至原来的5%,PolarDB分布式冷数据归档的业务实践
国内某家兼具投资理财、文化旅游、票务为一体的大型综合型集团公司,2015年成立至今,由于业务高速发展,业务数据增长非常快,数据库系统屡次不堪重负。该公司数据库运维总监介绍,他们目前业务压力比较大的是票务和订单系统,他们的平台每天新增几千万的订单数据,订单的数据来自于各个终端,近几年每个月以300G的数据规模在高速增长,由于数据不断增加,数据库系统迄今为止迭代过了3次。
|
5月前
|
存储 Linux Go
Habor数据迁移方式有多少,skopeo效率最好
Habor数据迁移方式有多少,skopeo效率最好
83 0
|
11月前
|
存储 缓存 监控
NineData,稳定、高效的Redis数据同步解决方案
NineData(https://www.ninedata.cloud/)在Redis的同步上,提供了稳定和高效的解决方案,并且性能上也领先其他同步工具,特别是在同步的动态限流、数据对比修复和限流、异常修复和断点续传等能力上也支持的最完善。
1545 1
|
存储 XML JSON
如何选择离线数据集成方案-全量&增量
如何选择数据离线集成方式,哪些表适合全量集成,哪些表适合增量集成
624 0
如何选择离线数据集成方案-全量&增量
|
缓存 中间件 数据库
分布式缓存的迁移方案
分布式缓存的迁移方案
454 0
分布式缓存的迁移方案