背景：
面临客户不断的将友商的存储数量迁移到阿里云上。ossimport 工具越来越多的暴露在用户端，但是合理的利用 ossimport 工具以及良好的迁移架构数据能否帮助用户高效的快速迁移。但是如果对 ossimport 不熟知，而且迁移架构没有经过测试，反而会降低我们的迁移效率，影响客户的全面战略上云计划安排。
https://www.atatech.org/articles/105435#1 迁移架构的演进：
传统的迁移方式：
本地 localfile -> 迁移到 OSS 云端
第三方存储 -> 迁移到 OSS 云端
以上的传统迁移方式都会遇到一个功能的问题就是公网的干扰因素不可以避免，尤其是当下的国内网络环境错综复杂，很难保证公网没有拥塞抖动，即便是大物理带宽的情况也不可幸免。于是有了 vpc 网络环境的改进。
进化 VPC 环境迁移：
在引入了 VPC 的概念后，用户解决了网络上带来的慢速的头疼问题，带来了一系列好处,，这里的 VPC 概念是指（通过 OSS 内网传输 or 走 VPC 专线传输）
- 迁移数据源到 OSS 端，没有带宽流量的限制（不包括 ECS 内部限制）
- VPC 内网环境迁移，使用 OSS 内网域名，不收取流量费用。
- VPC 环境延迟对比公网极低，基本无丢包，除非遇到线路故障
第三方 storage -> 数据盘 copy -> IDC 机器 -> VPC 专线 push-> OSS 云端
第三方 storage <- pull ECS -> VPC 专线 push -> OSS 云端
第三方 storage <- pull ECS -> OSS 内网 endpoint push -> OSS 云端
本地文件 -> OSS 内网 endpoint push -> OSS 云端
本地文件 -> VPC 专线 push -> OSS 云端
https://www.atatech.org/articles/105435#2 合理迁移配置：
目前还是推荐客户按照 VPC 的环境方式进行迁移，在服务体验感上有很大提升。在迁移过程中 OSS SLA 没有承诺迁移速度有明确指标，而且迁移数据和多因素有关（机器配置、数据量、网络、线程、限流等），所以根据实际情况进行问题诊断。
首先在迁移之前，要求使用者要先大致的学习一下我们的配置属性说明，和相关文件的作用，日志存储，异常处理等。
https://help.aliyun.com/document_detail/56990.html?spm=a2c4g.11174283.6.1079.sbu1chhttps://www.atatech.org/articles/105435#3 配置迁移文件单机版：
迁移前要明确用户的迁移体量和文件数量。目的是合理的配置 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 重试。
https://www.atatech.org/articles/105435#4 配置分布式迁移文件
分布式迁移模式的数据体量都是大于 30TB ，甚至上 PB 的级别才会用到，迁移模型也比较特殊，是通过 master 带多个 worker 协同工作，类似 nginx 的模型，master 只是用来切割任务和分配任务，对数据量庞大的用户，worker 的数量也要配置好，才能高效迁移。
首先通过用户文件数量，来计算任务数，该项目中用户总文件数 424421917 个，源头限制 3Gbps ，客户的机器数量有 12 台。
计划分成 20000 个 task ，每个 task 迁移 21221 个文件。每个 worker 机器开 200 线程，并发处理 200 个 task ，并发也就是能处理 2400 个，升级 17600 个 task 在队列中。
源流限制是 3000Mbps ，其实并发 worker 全部也就能跑到 375MB ，所以即便是你的线程开的再多，机器配置在高其他的线程也只能阻塞住。
迁移过程中可能遇到的问题：
一、设备日志中出现 OOM
这种问题基本都是用户选型的机器配置不够导致 worker 的迁移进程被干掉。
二、master 的 workers 文件中 IP 顺序随便写？
master 的 worker 文件一定要将 master IP 放在第一行，worker 机器放在下面，不要随意乱放，不然用户会将 master 机器也当做 worker 分配任务，造成 master 流量过高被打死。
这个错误和单机版的原因是一致的。
四、使用分布式模式迁移过程中出现 hang 住
使用 bash console.sh stat 看下文件是否已经扫描完，如果扫描完后出现在执行任务过程中 hang 住 并且伴随有失败任务，已经超过了几个小时，直接用 bash console.sh retry 再 bash console.sh stat 看下，如果数量有再变，就已经恢复，如果任务数量依然没有变化，请提交工单到阿里云售后。
其余报错可以根据 logs/ 下的 import.log 来查找原因。
https://www.atatech.org/articles/105435#5 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) 参数进行速度限制。