背景：
面臨客戶不斷的将友商的存儲數量遷移到阿裡雲上。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) 參數進行速度限制。