作者：張醫博
背景：
面臨客戶不斷的將友商的存儲數量遷移到阿里雲上。ossimport 工具越來越多的暴露在用戶端，但是合理的利用 ossimport 工具以及良好的遷移架構數據能否幫助用戶高效的快速遷移。但是如果對 ossimport 不熟知，而且遷移架構沒有經過測試，反而會降低我們的遷移效率，影響客戶的全面戰略上雲計劃安排。
遷移架構的演進：
傳統的遷移方式：
本地 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 雲端
合理遷移配置：
目前還是推薦客戶按照 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 遷移數據配置文件
sys.properties 遷移工具調優配置文件
遷移過程中可能遇到的問題：
一、設備日誌中出現 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
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
3ã 遷移數據量
大於 30TB 使用分佈式遷移 小於 30TB 使用單機模式
4ã 遷移模式：
4.1、 本地文件遷移到 OSS
用戶將空白地方按照實際情況填寫即可，srcprefix 以及 destprefix 如果都是跟下面，可以直接填寫 / 即可，所有配置項都是必選，遷移數據量是已經選擇好的，不用客戶自己填寫
4.2、httpurl 遷移到 OSS
所有配置項都是必選，遷移數據量是已經選擇好的，不用客戶自己填寫
4.3、第三方雲存儲遷移到 OSS
所有配置項都是必選，遷移數據量是已經選擇好的，不用客戶自己填寫
5ã 執行效果
舉例：第三方雲存儲遷移到 OSS
6ã 一鍵部署
