Data Online Migration：遷移常見問題

如何評估遷移速度與遷移時間長度

關於遷移速度：

• 線上遷移服務預設會為每個任務提供固定的理論峰值頻寬和QPS，具體詳見任務頻寬與 QPS。您需要根據自身業務情況，合理設定能用於遷移的理論峰值頻寬與QPS，以避免遷移訪問與您的生產業務訪問發生競爭，影響業務的正常運行。

• 遷移任務的速度不保證能達到理論峰值頻寬和QPS。主要影響因素有：

  • 訪問源端、目的端的網路鏈路頻寬和品質。對於鏈路長、時延大、丟包率高的網路（如公網跨國傳輸），可能會導致效率低下甚至檔案傳輸頻繁失敗。建議您使用專線或加速鏈路進行傳輸，如阿里雲OSS的傳輸加速網域名稱。

  • 源端、目的端的讀寫能力及檔案的平均大小。對於源端，遷移會進行遍曆、讀取元資訊和內容操作；對於目的端，遷移會進行寫入元資訊和內容、讀取元資訊操作。源端的遍曆能力會影響任務的掃描速度；任意一端的讀寫能力都會影響任務的遷移速度。尤其是在遷移海量200KB以內的小檔案時，對兩端的讀寫能力有更高的要求。您可以用源端總資料量除以源端總檔案數來粗略估算出單個檔案的平均大小。

  • 源端目錄的數量及檔案分布。對於LocalFS、FTP等具有目錄概念的檔案系統，線上遷移服務會以目錄為單位進行逐級並發掃描。若目錄數量過多、檔案分布過於稀疏，將影響任務的掃描速度。

  • 代理機器的軟硬體設定及數量。如果您源端和（或）目的端資料地址有關聯代理，則代理可能成為瓶頸。代理配置及數量選擇請參看代理選型。

• 受制於上述因素，線上遷移服務不對遷移速度做任何保證。建議您在正式實施遷移前，先使用較小規模的資料量進行PoC驗證，以便準確評估實際的遷移速度。

關於遷移時間長度：

• 在您評估出合理的遷移速度後，就可以根據總資料量、總檔案數量估算出遷移時間長度。您可以按總儲存量 / 頻寬、總檔案數量 / QPS，分別估算出最快遷移時間長度，取二者中的較大值。

• 最終估算出的遷移時間長度只是理論時間長度。遷移期間可能會遇到頻寬波動、失敗重試等問題，請務必做好應急預案與延期風險規劃，尤其是在需要停服割接的生產環境資料移轉情境中。

• 線上遷移服務對單個任務有遷移資源分派上限，詳見任務頻寬與 QPS。

以下是綜合評估樣本：

• 情境一：

  • 問：源端為S3，共約1TB資料、1000萬個檔案，目的端為OSS，在北京地區建立任務，請問遷移需要多久時間？

  • 答：根據任務頻寬與 QPS文檔可知，北京地區單任務理論速度為2Gbps，2000個檔案/秒。做如下計算：

    • 按照儲存量計算遷移時間長度：1TB ÷ 2Gbps ≈ 1.1小時。

    • 按照檔案個數計算遷移時間長度：10000000 ÷ 2000個檔案/秒 ≈ 1.4小時。

    • 理論計算遷移時間長度：取上述二者最大值，得到理論遷移時間長度為1.4小時。

• 情境二：

  • 問：源端為OSS，共約1TB資料、10萬個檔案，目的端為阿里雲NAS，在新加坡地區建立任務，請問遷移需要多久時間？

  • 答：根據任務頻寬與 QPS文檔可知，新加坡地區單任務理論速度為1Gbps、2000個檔案/秒。但由於目的地址是LocalFS，理論QPS上限為200個檔案/秒。做如下計算：

    • 按照儲存量計算遷移時間長度：1TB ÷ 1Gbps ≈ 2.3小時。

    • 按照檔案個數計算遷移時間長度：100000 ÷ 200個檔案/秒 ≈ 500秒。

    • 理論計算遷移時間長度：取上述二者最大值，得到理論遷移時間長度為2.3小時。

代理在控制台的狀態異常

線上遷移服務的代理執行個體需要部署才能正常運行。若您按照正常流程部署後，控制台代理程式狀態仍然顯示串連異常，則可能有如下原因：

• 網路連通性問題。請參考使用代理遷移中的網路類型參數，確認代理機器到線上遷移服務網域名稱的連通性。

• 憑據填寫不正確或許可權問題，如：

  • 輸入有誤。如複製粘貼的AccessKeyId（或SecretAccessKey）不完整或有額外的幹擾字元。

  • 許可權不足。填寫的AccessKeyId必須具備以下任一許可權，且資源範圍必須是帳號層級：

    • mgw:VerifyAgentTunnel

    • AliyunOSSImportReadOnlyAccess

    • AliyunOSSImportFullAccess

  • 帳號不匹配。如填寫的AccessKeyId並不屬於本RAM子帳號，或本主帳號下的其他RAM子帳號。無論是否涉及跨帳號遷移，您都只能使用當前主帳號下的任一RAM子帳號的憑據，且該RAM子帳號必須具有上述三個許可權之一。

• 憑據被RAM中的網路訪問限制策略所限制。目前線上遷移服務的代理鑒權機制要求必須AccessKeyId必須允許所有網段都能正常訪問。您可以在RAM中的AccessKey級訪問限制策略中按照如下步驟添加允許所有公網訪問白名單：在 AccessKey 級網路訪問限制策略 頁面，選擇 啟用，單擊 允許所有公網訪問（系統自動填入 ::/0 和 0.0.0.0/0），在公網策略表格操作列單擊 確定，然後單擊頁面底部的 提交。

• 憑據所屬帳號被RAM中的權限原則所限制。若您有對此RAM帳號授予自訂權限原則，且該自訂權限原則添加了訪問IP地址的限制條件，則會導致代理運行異常。

• 代理機器的作業系統時間不準確，和現實世界偏差超過5分鐘。

• 部署命令被修改、粘貼不完整。請完整複製、粘貼控制台自動產生的代理部署命令，勿做任何修改，否則可能會導致代理運行異常。

如果代理程式狀態不穩定，則可能有如下原因：

• 網路不穩定。當代理與線上遷移服務之間的網路品質不佳時，會出現偶發性串連異常。若代理機器所處的網路環境發生了變化，請參考使用代理遷移中的網路類型參數，重新確認代理機器到線上遷移服務網域名稱的連通性。

• 代理壓力大。正在執行遷移的代理可能會出現偶發性串連異常。如果遷移任務正常運行，則屬於正常現象；如果機器出現平均負載（Load Average）較高時，請擴容代理執行個體來增強遷移能力，或降低任務的每秒遷移檔案數上限參數。

• 關聯的通道執行個體啟用了限流。由於代理的健全狀態檢查也會少量消耗通道的QPS，可能與遷移請求發生競爭而被拒絕。建議適當放大通道的請求數/秒參數，或不做通道級限流。

• 代理進程已經退出。請參考代理進程的查看、啟動與停止登入代理機器查看進程狀態。當代理機器的執行個體規格低於推薦值時，可能會導致進程因記憶體不足而退出，執行個體規格參考代理選型。

• 同一個代理執行個體部署在多台機器上。每個代理執行個體僅能部署在一台機器上，重複部署會導致相互衝突，從而出現狀態不穩定的現象。若您需要更換代理機器，請務必先停止舊代理機器上的進程，然後重新部署。

遷移任務沒有進度

• 後台調度機制。正常情況下，任務啟動後會有10-15分鐘的入隊調度時間，請耐心等待。

• 檔案被過濾。如果任務配置了檔案過濾器，且源端符合過濾條件的檔案數量很少，則將會導致任務更新緩慢。

• 清單的預先處理耗時。如果任務的源端是清單類型的資料地址，則需要有一定的預先處理時間，預先處理耗時和清單中的檔案總數量呈正相關。

• 並發遷移大檔案。若任務詳情頁面的頻寬監控圖資料趨勢符合預期，則屬於正常現象；

• 其他可能的原因：

  • 如果源端是LocalFS或FTP類型，目錄過多且檔案分布稀疏，將導致掃描時過慢；或有目錄因許可權不足、損壞等原因導致無法正常訪問，將導致掃描無法正常進行。

  • 若目的端是LocalFS類型，當大批量遷移GB級及以上的大檔案時，進度更新可能遲滯。您可以查看代理機器的實際頻寬（如ECSCloudMonitor）來確認。

  • 如果任意一端有關聯代理，當代理執行個體對應的機器負載過大甚至串連異常時，都會影響任務的進度。

如何查看遷移失敗檔案

在遷移過程中，可能由於資料來源存取權限不足、網路異常等原因導致部分檔案遷移失敗。您可以通過以下兩種方式查看失敗檔案的具體原因：

• 方式一：推送遷移報告

您可以在建立任務時設定推送遷移報告，也可以在之後修改該配置。任務完成後，線上遷移服務會將完整的遷移記錄寫入到目的資料地址的指定位置。您可以通過審閱該遷移報告來定位遷移失敗檔案及其原因。

• 方式二：推送遷移日誌

在建立遷移任務時設定推送遷移日誌，線上遷移服務會將遷移過程中的日誌即時推送至您的Log Service（SLS）。您可以在Log Service中查看相關日誌，分析失敗檔案及其具體失敗原因。

常見遷移失敗原因

下表列出了遷移失敗原因的錯誤碼關鍵字（部分）。這些錯誤碼可能會出現在下列情境中：

• 建立資料地址異常時，異常報錯資訊。

• 任務運行異常中斷時，任務歷史介面的異常報錯資訊。

• 遷移報告中的異常原因欄位的內容。

underscoreUserMetaDropOrSkipUids=<UID>,drop;

遷移完成後發現兩端資料量不一致

遷移任務運行完成後，若發現源端資料量和目的端資料量不一致，則可按照以下原因排查。

若是目的端資料量偏少。則可能的原因有：

• 兩端資料有變動。如遷移過程中，源端可能有寫資料操作；或目的端資料有刪除（包括使用者業務側主動刪除，或類似生命週期策略的被動刪除）。

• 源端可能存在多版本資料（如OSS、S3、NAS資源回收筒等），線上遷移服務只會遷移最新版本的資料。

• 統計延遲。可能是目標端資料統計有小時或天層級延遲，可查看對應的統計說明文檔。或使用對應的工具（如ossutil）進行手動統計。

• 有部分資料被跳過。如某檔案在源端的大小為1GB，同時在目的端的大小為100MB。但根據遷移任務的覆蓋方式，該檔案被判為跳過。

• 源端有片段。線上遷移服務並不會遷移源端的片段等非完整對象。

• 檔案過濾器設定有誤。若啟用了檔案過濾器，請檢查配置規則是否符合預期，如是否有多餘的空格等幹擾字元。

• 來源資料地址Prefix設定有誤。如您指定了源地址的Prefix，則只會遷移此Prefix下的資料。

• 異構儲存的統計差異。如NAS等檔案系統類型的源，會將目錄自身也計入儲存佔用。而OSS等Object Storage Service類型的源，並沒有目錄的概念，Null 物件也並不會計入儲存佔用。

• 部分代理NAS掛載點異常。若源地址是LocalFS類型，且關聯有多台代理，若其中一些代理的NAS掛載點異常，當遷移請求被派發到這些代理執行個體上時，將會由於訪問源端檔案報NotFound而被判為跳過，從而導致最終遷移資料量偏少。

若是目的端資料量偏多。則可能的原因有：

• 兩端資料有變動。如遷移過程中，源端可能有刪除資料操作（包括使用者業務側主動刪除，或類似生命週期策略的被動刪除）；或目的端資料有寫資料操作。

• 目的端可能開啟了多版本功能（如OSS、NAS資源回收筒等），線上遷移服務會使用非多版本類的API將資料寫入目的端，若目的端已啟用多版本功能，則寫入操作將會產生新版本的資料。

• 有部分資料被跳過。如某檔案在源端的大小為100MB，同時在目的端的大小為1GB。但根據遷移任務的覆蓋方式，該檔案被判為跳過。

• 目的端有片段或臨時檔案殘留。線上遷移服務內部會根據檔案大小自動選擇合適的讀寫方式，若任務中斷（使用者主動操作或發生嚴重異常所致），或網路原因等導致部分檔案遷移失敗時，可能會在目的端殘留片段或臨時檔案。

• 檔案過濾器設定有誤。若啟用了檔案過濾器，請檢查配置規則是否符合預期，如是否有多餘的空格等幹擾字元。

• 目的資料地址Prefix下存在其他資料。如您目的地址的Prefix下在遷移前就已存在部分資料，遷移並不會提前清空這些資料（但根據任務的覆蓋方式，可能會覆蓋同名檔案）。

• 異構儲存的統計差異。如NAS等檔案系統類型的源，會將目錄自身也計入儲存佔用。而OSS等Object Storage Service類型的源，並沒有目錄的概念，Null 物件也並不會計入儲存佔用。

• 遷移報告的額外佔用空間。如果使用者選擇推送遷移報告，則會在目的端產生遷移報告，遷移報告的佔用大小取決於任務的遷移檔案總數量。

源端產生額外下行流量、檔案被重複遷移

正常情況下，線上遷移服務只會下載一次源端資料。如果您在遷移完成過後，發現源端的下行流量偏多，則可能的原因有：

• 失敗內部重試。如果遷移過程中出現網路閃斷、讀寫限流、代理效能瓶頸（若關聯）等異常，則會自動對檔案進行有限次數的重試操作。

• 外部系統訪問。如在遷移期間，另有其他系統（如您的業務系統、cdn回源等）同時訪問源端，則會與遷移產生的下行流量相互疊加。

如果您在執行多輪遷移時，先前遷移成功的檔案仍然重複遷移，並沒有跳過。則可能的原因有：

• 遷移任務覆蓋方式參數不合理。若您的遷移任務的為強制覆蓋，則線上遷移服務無論目的端的是否已有檔案，總是會執行覆蓋。

• 目標端配置有生命策略周期。在建立遷移任務時，若您選擇保留檔案最後修改時間，則源端檔案的最後修改時間也將被設定到目的端。若目的端配置的生命週期策略有刪除操作，則可能會出現“檔案遷移後很快被刪除”的現象。

• 源端檔案頻繁更新。若遷移任務的覆蓋方式為根據最後修改時間覆蓋，在第一輪遷移成功後，一旦源端檔案的最後修改時間有更新（無論檔案內容是否有更新），下一輪就會再次遷移。

OSS跨帳號遷移問題匯總

跨帳號分為三個情境：其他帳號遷移到本帳號、本帳號遷移到其他帳號、其他帳號遷移到其他帳號（該情境操作複雜，不推薦，建議轉換成前兩種情境）。在遷移過程中，可能遇到授權的問題。總結如下：

• 授權操作的核心流程為：

  • 本帳號在RAM控制台建立RAM角色。具體步驟參考建立用於遷移資料的RAM角色。

  • 將建立的角色名稱（RoleName）告知給其他帳號的管理員。管理員在其待遷移的Bucket授權策略介面執行授權。具體請參考源Bucket授權或目的Bucket授權。

  • 至此授權完成。本帳號繼續操作線上遷移服務，建立此待遷移的Bucket資料地址時，授權角色欄位請使用上述步驟的RoleName。

• 跨帳號授權完成後，建立其他帳號的資料地址仍然報“許可權不足”相關的錯誤。可能是RoleName有大寫字母所致。即使RAM控制台上建立的原始RoleName含大寫字母（如MyOssImportRole），也務必請在bucket acl授權策略中用全小寫字母（如myossimportrole）。

NAS跨帳號遷移問題匯總

• 使用線上遷移服務時，即使遷移不同阿里雲帳號下NAS執行個體，也不涉及跨帳號情境。因為線上遷移服務只會使用POSIX標準IO介面讀寫指定目錄，並不感知其底層儲存是否為NAS及其所屬帳號。

• 您必須部署代理程式，並將NAS掛載到代理上後，按照LocalFS資料地址類型操作。請務必注意目錄映射，否則檔案可能會讀（或寫）到非預期的磁碟路徑上。

• 假設某使用者需要將帳號A的阿里雲NAS遷移到本帳號NAS下。執行步驟為：

  • 將帳號A的NAS掛載到某台機器M1上。M1可以是帳號A的ECS（推薦），也可以是其他來源。能正常掛載帳號A的NAS即可。

  • 線上遷移服務控制台上，建立一個代理執行個體agent1，並將其部署在機器M1上。

  • 將本帳號的NAS掛載到另一台機器M2上。M2可以是本帳號的ECS（推薦），也可以是其他來源。能正常掛載本帳號NAS即可。

  • 線上遷移服務控制台上，建立一個代理執行個體agent2，並將其部署在機器M2上。

  • 確認線上遷移服務控制台上代理agent1、agent2的狀態都是“正常”後，按照LocalFS之間遷移教程建立資料地址、遷移任務。

是否支援阿里雲國際帳號和中國帳號下的OSS互遷

支援。具體操作請流程參考 阿里雲OSS之間遷移教程。