Azure Storage Mover 中的可靠性

本文說明 Azure Storage Mover 的可靠性支援，並涵蓋可用性區域的區域內復原能力，以及跨區域災害復原和商務持續性。 如需更多關於 Azure 可靠性準則的詳細概觀，請參閱 Azure 可靠性。

可用性區域支援

Azure 可用性區域是每個 Azure 區域內至少三個實體上獨立的資料中心群組。 每個區域內的資料中心都配備了獨立的電源、冷卻和網路基礎結構。 可用性區域的作用是在一個區域受影響時 (例如本機區域失敗時)，讓其餘兩個區域支援區域服務、容量和高可用性。

這類失敗的範圍可從軟體和硬體故障，擴及到如地震、淹水和火災的事件。 Azure 服務的備援和邏輯隔離功能可以容錯。 如需深入了解 Azure 的可用性區域，請參閱區域和可用性區域。

已啟用 Azure 可用性區域的服務是設計來提供正確的可靠性和彈性層級。 您可以透過兩種方式加以設定。 可採用區域備援 (可跨區域自動複寫) 或區域性 (將執行個體釘選在特定區域)。 兩種方法可以結合使用。 如需區域與區域備援結構的詳細資訊，請參閱使用可用性區域和區域的建議。

Azure Storage Mover 支援區域備援部署模型。

當您部署 Azure Storage Mover 資源時，您必須選取資源的執行個體中繼資料儲存所在的特定區域。

如果該區域支援可用性區域，執行個體中繼資料便會自動復寫到該區域內的多個可用性區域。

重要

Azure Storage Mover 執行個體中繼資料包含專案、端點、代理程式、作業定義和作業執行歷程記錄，但不包含要移轉的實際資料。 作為移轉目標的 Azure 儲存體帳戶具有自己的可靠性支援。

必要條件

• 若要使用可用性區域支援進行部署，您必須選擇支援可用性區域的區域。 若要查看哪些區域支援可用性區域，請參閱支援區域清單。

• (選擇性) 如果您的目標儲存體帳戶不支援可用性區域，而且您想要將帳戶移轉至 AZ 支援，請參閱將 Azure 儲存體帳戶移轉至可用性區域支援。

區域關閉體驗

在全區域中斷期間，不需在區域復原期間採取任何動作。 Azure Storage Mover 的設計目的是自我修復和自我重新平衡，以自動利用狀況良好的區域。

任何移轉目標儲存體帳戶都可能需要自己的復原步驟。 此需求取決於為每個儲存體帳戶選擇的備援選項。 請參閱儲存體帳戶災害復原指南，以判斷是否需要執行更多步驟。

如果選擇本機儲存體來替代備援選項，您可能需要建立新的儲存體帳戶，以在中斷期間用於移轉。

跨區域災害復原和商務持續性

災害復原 (DR)是指從重大影響事件中復原，例如自然災害或不成功的部署 (導致停機和資料遺失)。 無論原因為何，解決災害的最佳辦法是定義完善且經過測試的 DR 方案，以及主動支援 DR 的應用程式設計。 開始制定災害復原方案之前，請參閱設計災害復原策略的建議。

Microsoft 在災害復原方面，採取共同責任模型。 在共同責任模型中，Microsoft 確保基準基礎結構和平台服務可供使用。 此時許多 Azure 服務不會自動複寫資料，或從故障區域恢復並交叉複寫到另一個已啟用的區域。 您需要為這些服務制定適合您工作負載的災害復原方案。 在 Azure 平台即服務 (PaaS) 供應項目上執行的多數服務，都有提供支援災害復原的功能和指導，您可以使用特定服務功能快速復原，制定災害復原方案。

註冊 Storage Mover 代理程式時，其會連線到 Storage Mover 資源註冊所在的區域。 如果代理程式的 Azure 區域發生中斷，代理程式本身不會受到影響，但依賴 Azure 的管理作業可能會無法完成。 此外，任何正在移轉至受影響區域內儲存體帳戶的資料可能會失敗。

Storage Mover 支援兩種形式的災害復原：

• Azure 起始的災害復原
• 客戶起始的災害復原

重要

內部部署資料來源的災害復原由客戶負責進行。

Azure 起始的災害復原

Azure 起始的災害復原僅適用於具有區域配對的區域。 使用跨區域複寫時，執行個體中繼資料會復寫到每個區域，但絕不允許離開該地理位置。

Azure Storage Mover 會使用 Cosmos DB 來儲存執行個體中繼資料。 僅在 Azure Cosmos DB 發生無法復原的災害時，才會發生資料遺失。 如需詳細資訊，請參閱區域中斷。 Azure 起始的復原採「主動-被動」方式，且區域的完整復原最長可能要 24 小時。

客戶起始的災害復原

客戶起始的災害復原不限於配對的區域。

發生區域性中斷之前：

• 在支援可用性區域的區域中建立 Storage Mover 資源，以部署區域備援 Storage Mover。

• 定期 (依排程或在進行重大變更後) 建立 Storage Mover 資源的快照集。 使用版本控制系統儲存快照集是儲存和追蹤快照集歷程記錄的好方法。 在發生需要在新區域中復原資源的災害時，您會使用最新的良好快照集。

在區域性中斷期間：

您可以執行下列兩項動作之一：

• 選擇等候 Azure 復原該區域。
• 將資源重新部署至不同區域，以將停機時間降至最低。 在中斷期間，由於資源的存取可能會受到影響，因此建議您使用資源的最新良好快照集。

提示

上述任一策略仍可能需要在災害發生前就採取進一步的步驟，因此請務必據此檢閱和規劃。

將資源部署到不同的區域

如需有關將資源匯出為 Azure Resource Manager (ARM) 範本的進一步指示，請參閱有關匯出範本的文件。

如果您的 Storage Mover 和相關資源位於沒有額外資源的容器中，則請執行資源群組匯出以擷取目前狀態。 不過，如果您的資源群組包含不相關的資源，則可能需要從範本中移除或排除該資源。

現有的代理程式無法重新部署到不同的區域。 如果原本設定所在的區域發生中斷，便可能無法先將代理程式完全取消註冊再重新註冊。 本文件的假設是，已在新的區域內註冊新的代理程式。

若要使用匯出的範本進行災害復原，則需要對範本進行一些變更。

• 首先，從範本中移除任何 Microsoft.StorageMover/agents 和 Microsoft.HybridCompute/machines 資源。 請務必也移除這些資源的相依性參考。
• 接下來，從所有作業定義中移除 agentResourceId 屬性。 在部署後，您必須將其指派給新的代理程式。
• 在移除代理程式和混合式計算機器資源的所有參考後，請更新最上層 Storage Mover 資源的位置屬性。 將目前所部署區域的名稱取代為新區域的名稱。
• 最後，判斷是否要保留現有的儲存體帳戶資源識別碼。 如有必要，請將其取代為不同的儲存體帳戶。

在完成前面的步驟並確認範本參數正確後，範本便已準備好部署至新的區域。 請將範本部署到與範本中位置屬性具有相同預設區域的新資源群組。

註冊新的代理程式

請遵循部署 Azure Storage Mover 代理程式一文內的步驟，在新的 Storage Mover 資源中註冊新的代理程式。

將代理程式指派給作業定義

在新的代理程式完成註冊並回報為已上線後，請使用 Azure 入口網站或 PowerShell 將現有的作業定義與新的代理程式產生關聯。 為了方便起見，我們提供了下列 PowerShell 範例。

如需如何存取專案作業定義的指導，請參閱定義新的移轉作業。

## Update the agent in a job definition resource
$resourceGroupName  = "[Your resource group name]"
$storageMoverName   = "[Your storage mover name]"
$projectName        = "[Your project name]"
$jobDefName         = "[Your job definition name]"
$agentName          = "[The name of an agent previously registered to the same storage mover resource]"

Update-AzStorageMoverJobDefinition `
    -ResourceGroupName $resourceGroupName `
    -StorageMoverName $storageMoverName `
    -ProjectName $projectName `
    -Name $jobDefName `
    -AgentName $agentName

向代理程式授與目標儲存體容器的存取權

您必須將資料參與者角色指派給受控識別，才能成功執行移轉作業。 向混合式計算資源的系統受控識別指派目標儲存體帳戶資源的存取權。 向受控識別指派資源的存取權一文會提供有關如何授與目標資源存取權的指導。

您現在已準備好使用新部署的 Storage Mover 資源開始進行移轉作業。

下一步

• Azure 中的可靠性
• 儲存體帳戶災害復原