檔案和資料夾儲存體的雲端移轉基本概念
每個移轉都是從商務需求開始。 雲端移轉會藉由移動其相依的檔案和資料夾，來轉換工作負載。 工作負載可以是應用程式或直接使用者存取。 不論是哪一種情況，工作負載都相依于您移至雲端的儲存體。 工作負載也可能移至雲端，或保留在原處，但需要變更設定，才能指向新的雲端儲存位置。 這些詳細資料會記錄在具有儲存體區段的雲端解決方案設計 中 。
本文的目的是提供如何達成儲存體移轉至 Azure 的深入解析，讓您能夠實現儲存體的雲端解決方案設計。
將檔案和資料夾移轉至雲端需要仔細規劃和許多考慮，才能達到最佳結果。 Azure 儲存體 Mover 提供越來越多的功能和移轉案例清單，可協助您進行旅程。 在本文中，我們會將移轉的一般工作分成各有其專屬區段的階段。
階段 1：探索
在探索階段中，您決定哪些來源位置是移轉專案的一部分。 Azure 儲存體 Mover 會以檔案共用的形式處理來源位置。 這些位置可以位於網路連接儲存體（NAS）、伺服器，甚至是工作站上。 檔案共用的常見通訊協定是 SMB（伺服器訊息區）和 NFS（網路檔案系統）。
如果您的工作負載使用直接連結儲存體 （DAS），則最可能Azure 儲存體 Mover 仍可協助您進行雲端移轉。 您可以在本機資料夾路徑上建立檔案共用，然後透過局域網路共用位置。 使用適當的許可權和網路考慮，您現在可以將此位置移轉至 Azure，即使您的應用程式使用本機路徑也一樣。
首先，列出工作負載所依賴的所有共用。 請參閱您的雲端解決方案設計，以查看哪些共用會保留在內部部署，以及哪些共用是雲端移轉的範圍。 盡可能縮小移轉專案的範圍。 最後，您的工作負載必須容錯移轉至雲端位置。 來源位置數目越小，工作負載的容錯移轉就越容易。
如果您需要同時移轉多個工作負載的儲存體，您應該將它們分割成個別的移轉專案。
重要
不建議在單一移轉專案中包含多個工作負載。 每個工作負載都應該有自己的移轉專案。 以這種方式建構專案可大幅簡化移轉管理和工作負載容錯移轉。
探索階段的結果是您需要移轉至 Azure 的檔案共用清單。 每個工作負載都應該有不同的清單。
Azure 儲存體 Mover 提供 移轉專案 來建立和儲存個別清單。 常見的作法是在您要移轉的工作負載之後命名移轉專案。 這種做法可簡化規劃步驟和移轉進度的監督。
階段 2：評定
Azure 提供各種類型的雲端儲存體。 檔案移轉至 Azure 的基本層面是判斷哪一個 Azure 儲存體選項適合您的資料。 檔案和資料夾數目、其目錄結構、存取通訊協定、檔案逼真度和其他層面是完整雲端解決方案設計的重要輸入。
在評估階段中，您會調查探索到的和上市的共用，以確保您已為雲端解決方案設計挑選正確的 Azure 目標儲存體。
任何移轉的主要部分，是在將檔案從目前的儲存體位置移至 Azure 時，擷取所需的檔案精確度。 不同的檔案系統和儲存體裝置會記錄檔案逼真度資訊的陣列，並且完全保留或保留 Azure 中的資訊並非一定必要。 案例所需的檔案精確度，以及 Azure 中儲存體供應專案支援的精確度，也協助您在 Azure 中挑選正確的儲存體解決方案。 一般用途的檔案資料傳統上取決於至少一些檔案中繼資料。 應用程式資料可能不會。
以下是檔案的兩個基本元件：
- 資料流程： 檔案的資料流程會儲存檔案內容。
- 檔案中繼資料： 檔案中繼資料具有下列子元件：
- 檔案屬性，例如 唯讀
- 檔案許可權，例如 NTFS 許可權或檔案和資料夾存取控制清單 （ACL）
- timestamps，最值得注意的是 建立 和 上次修改的 時間戳記
- 替代資料流程，這是儲存大量非標準屬性的空間
移轉中的檔案精確度可以定義為能夠：
- 從來源讀取所有必要的檔案資訊。
- 使用移轉服務或工具傳輸檔案。
- 將檔案儲存在移轉的目標儲存體中。
評估階段的輸出是來源共用中找到的層面清單。 這些層面可能包括下列資料：
- 共用大小。
- 命名空間專案的數目，或檔案和資料夾的合併計數。
- 必須在 Azure 儲存體目標中保留的精確度層級。
- 必須維持在 Azure 儲存體目標中原生運作的逼真度層級。
此深入解析是儲存體雲端解決方案設計的重要輸入。
階段 3：規劃
在規劃階段中，您會將探索到的來源共用與 Azure 中的目標位置合併。
規劃階段會將每個來源共用對應至特定目的地，例如 Azure Blob 容器或 Azure 檔案共用。 若要這樣做，您必須規劃和記錄哪些 Azure 訂用帳戶和儲存體帳戶包含您的目標資源。
在 Azure 儲存體 Mover 服務中，您可以將每個來源/目標群組記錄為 作業定義 。 作業定義會巢狀于您先前建立的移轉專案中。 您需要每個來源/目標群組的新相異作業定義。
注意
在此版本的 Azure 儲存體 Mover 中，您的目標儲存體必須存在，才能建立作業定義。 例如，如果您的目標是 Azure Blob 容器，您必須先部署它，才能建立新的作業定義。
規劃階段的結果是將來源共用對應至 Azure 目標位置。 如果您的目標尚未存在，您必須先完成下一個階段「部署」，才能在 Azure 儲存體 Mover 服務中記錄移轉計畫。
階段 4：部署
完成移轉計畫之後，您必須確定已部署儲存體帳戶和容器等目標Azure 儲存體資源。 您必須先完成此部署，才能將移轉計畫記錄為Azure 儲存體 Mover 內每個來源/目標群組的作業定義。
Azure 儲存體 Mover 目前無法協助目標資源部署。 若要部署 Azure 儲存體，您可以使用 Azure 入口網站、Azure PowerShell、Azure CLI 或 Bicep 範本 。
重要
部署Azure 儲存體時， 請檢閱Azure 儲存體 Mover 的支援來源/目標群組組合 ，並確定您未設定不支援的案例。
階段 5：移轉
將檔案和資料夾複製到 Azure 目標位置的工作會在移轉階段內發生。
移轉階段有兩個主要考慮：
- 將工作負載的停機時間降到最低。
- 判斷正確的移轉模式。
將停機時間降到最低
在移轉期間，工作負載可能會有一段時間無法存取其相依的儲存體。 將這些時間週期降到最低通常是一項需求。 本節討論將工作負載停機時間降至最低的常見策略。
聚合式、n-pass 移轉
在此策略中，您會將資料從來源複製到目標數次。 在這些複製反復專案期間，來源仍可供讀取和寫入工作負載。 在最後一個複製反復專案之前，您會讓來源離線。 預期最終複本完成的速度會比初始複本快。 在最後一個複本之後，工作負載會容錯移轉，以在 Azure 中使用新的目標儲存體。
Azure 儲存體 Mover 支援視需要從來源複製到目標。 作業定義會儲存您的來源、目標和移轉設定。 您可以指示移轉代理程式執行作業定義，這會導致作業執行。 在此連結的文章中，您可以深入瞭解 mover 資源階層 儲存體。
移轉模式
檔案從來源複製到目標的方式與檔案複製到目標的位置同樣重要 。 不同的移轉案例需要不同的設定。 在移轉期間，您可能會從來源複製到目標數次，以 將停機時間 降到最低。 當檔案或資料夾在複製反復專案之間變更時， 複製模式 會決定移轉引擎的行為。 請仔細選取正確的模式，根據移轉期間對命名空間的預期變更。
有兩種複製模式：
| Copy mode | 移轉行為 |
|---|---|
| 鏡像 目標看起來像來源。 |
- 如果目標中的檔案不存在於來源中，則會加以刪除。 - 目標中的檔案和資料夾會更新為符合來源。 |
| 合併 目標的內容比來源多，而且您不斷新增至該目標。 |
- 檔案會保留在目標中，即使檔案不存在於來源中也一樣。 - 具有相符名稱和路徑的檔案會更新為符合來源。 - 複本之間的資料夾重新命名可能會導致目標內容重複。 |
階段 6：移轉後工作
在這個移轉階段中，您需要考慮其他設定和服務，讓您容錯移轉工作負載並保護您的資料。
例如，容錯移轉您的工作負載需要網路路徑，才能安全地存取 Azure 儲存體。 如果您在移轉期間使用 Azure 儲存體帳戶的公用端點，請考慮 設定儲存體帳戶 的私人端點，並 啟用防火牆規則來停用透過公用端點 的資料要求。
以下是一些建議：
下一步
這些文章可協助您利用 Azure 儲存體 Mover 進行雲端移轉：