Azure 儲存體 Mover 規模和效能目標
儲存體移轉服務的效能是任何移轉的重要層面。 在本文中，我們會共用效能測試結果，不過因為Azure 儲存體 Mover 是新的服務，您的體驗可能會有所不同。
調整目標
Azure 儲存體 Mover 會測試 1 億個命名空間專案（檔案和資料夾），從 支援的來源移轉至 Azure 中支援的目標 。
我們如何測試
Azure 儲存體 Mover 是混合式雲端服務。 混合式服務具有雲端服務元件，以及服務系統管理員在其公司環境中執行的基礎結構元件。 對於 儲存體 Mover，該混合式元件是移轉代理程式。 代理程式是在來源儲存體附近的主機上執行的虛擬機器。
只有代理程式是服務中效能測試的相關部分。 若要省略隱私權和效能考慮，資料會直接從 儲存體 Mover 代理程式移至 Azure 中的目標儲存體。 只有控制和遙測訊息會傳送至雲端服務。
效能基準
這些測試結果是在理想條件下建立的。 它們是儲存體 Mover 服務和代理程式可以直接影響的元件基準。 此測試不會考慮來源裝置、磁片和網路連線的差異。 真實世界的效能會有所不同。
從 SMB 掛接移轉至 Azure 檔案共用測試的執行方式如下：
下表說明從 SMB 掛接到 Azure 檔案共用產生效能測試結果的測試環境特性。
| 測試否。 | 否。 檔案的 | 總檔案權數 | 檔案大小 | 資料夾結構 |
|---|---|---|---|---|
| 1 | 1200 萬 | 12 GB | 每個 1 KB | 12 個資料夾，每個資料夾都有 100 個子資料夾，其中包含 10,000 個檔案 |
| 2 | 30 | 20 GB | 1 個資料夾 | |
| 3 | 一百萬 | 100 GB | 每個 100 KB | 1,000 個資料夾，每個資料夾都有 1,000 個檔案 |
| 4 | 1 | 4 TB | ||
| 5 | 1.17 億 | 117 GB | 每個 1 KB | 117 個資料夾，每個資料夾都有 100 個子資料夾，其中包含 10,000 個檔案 |
| 6 | 1 | 1 TB | ||
| 7 | 330 萬 | 45 GB | 每個 13 KB | 200,000 個資料夾，每個資料夾都包含 16\17 個檔案 |
| 8 | 5000 萬 | 1 TB | 每個 20 KB | 2,940,000 個資料夾，每個資料夾都包含 17 個檔案 |
| 9 | 1 億 | 2 TB | 每個 20 KB | 5,880,000 個資料夾，每個資料夾都包含 17 個檔案 |
SMB 端點上會測試不同的代理程式資源設定：
Minspec：4 CPU/8 GB RAM 4 個虛擬 CPU 核心，每個 2.7 GHz 和 8 GiB 的記憶體（RAM）是Azure 儲存體 Mover 代理程式的最低規格。
測試否。 執行時間 掃描時間 6 16 分鐘，42 秒 1.2 秒 7 55 分鐘，4 秒 1 分鐘，17 秒 8 9 開機規格：8 CPU/16 GiB RAM 8 虛擬 CPU 核心，每個 2.7 GHz 和 16 GiB 記憶體（RAM） 是Azure 儲存體 Mover 代理程式的最低規格。
結果：標準儲存體帳戶
測試否。 執行時間 掃描時間 1 15 小時，59 分鐘 2 小時， 36 分鐘， 34 秒 2 1 分鐘，54 秒 3.34 秒 3 1 小時， 19 分鐘， 27 秒 57.62 秒 4 1 小時，5 分鐘，57 秒 2.89 秒 結果：已啟用大型檔案的標準儲存體帳戶
測試否。 執行時間 掃描時間 1 3 小時， 51 分鐘， 31 秒 41 分鐘和 45 秒 5 25 小時，47 分鐘 23 小時，35 分鐘 6 11 分鐘，11 秒 0.7 秒 7 55 分鐘，10 秒 1 分鐘， 3 秒 8 9 結果：進階版儲存體帳戶
測試否。 執行時間 掃描時間 1 2 小時， 35 分鐘， 14 秒 24 分鐘，46 秒 5 23 小時，34 分鐘 21 小時，34 分鐘
請檢閱代理程式部署一文 中 移轉範圍的建議代理程式資源 。
移轉效能為何會有所不同
基本上，網路品質和處理檔案、資料夾及其中繼資料的能力會影響您的移轉速度。
在網路和計算的兩個核心區域中，有數個層面會影響：
- 移轉案例
相較于具有內容的目標，複製到空白目標的速度較快。 此行為是因為移轉引擎不僅評估來源，還評估目標來進行複製決策。 - 命名空間專案計數
移轉 1 GiB 小型檔案所需的時間比移轉 1 GiB 較大的檔案還要多。 - 命名空間圖形
寬資料夾階層比窄目錄結構或深層目錄結構更適合平行處理。 檔案與資料夾比率也會播放 roll。 - 命名空間變換
兩個複製之間有多少個檔案、資料夾和中繼資料已從相同的來源執行變更為相同的目標。 - Network
- 來源和移轉代理程式之間的頻寬和延遲
- 移轉代理程式與 Azure 中目標之間的頻寬和延遲
- 移轉代理程式資源
記憶體數量（RAM）、計算核心數目，甚至是移轉代理程式上可用的本機磁片容量，可能會對移轉速度產生深遠的影響。 更多計算資源有助於將可用頻寬的使用率優化，尤其是在移轉中需要處理大量較小的檔案時。
例如，傳統移轉需要策略，以將相依于要移轉之儲存體的工作負載停機時間降到最低。 Azure 儲存體 Mover 支援這類策略。 它稱為聚合式 n-pass 移轉。
在此策略中，您會從來源複製到目標數次。 在這些複製反復專案期間，來源仍可供讀取和寫入工作負載。 在最後一個複製反復專案之前，您會讓來源離線。 預計最後一個複本的完成速度會比您曾經製作的第一個複本快，而且需要大約只要緊接在它前面。 在最後一個複本之後，工作負載會容錯移轉以在 Azure 中使用新的目標儲存體，並可供再次使用。
在第一次從來源複製到目標期間，目標可能是空的，而且所有來源內容都必須移至目標。 因此，第一個複本可能會受到可用網路資源的最大限制。
在移轉結束時，當您已經將來源複製到目標數次時，自上次複本之後，只有少數檔案、資料夾和中繼資料已變更。 在此上次複製反復專案中，比較來源和目標中的每個檔案，以查看是否需要更新、需要更多計算資源和較少的網路資源。 複製會在移轉的這個後期執行，通常比較受計算限制。 儲存體 Mover 代理程式 的適當 資源變得越來越重要。
下一步
下列文章可協助成功Azure 儲存體 Mover 部署。
意見反應
即將登場：在 2024 年，我們將逐步淘汰 GitHub 問題作為內容的意見反應機制，並將它取代為新的意見反應系統。 如需詳細資訊，請參閱：https://aka.ms/ContentUserFeedback。
提交並檢視相關的意見反應