You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This article describes reliability support in Azure Storage Mover, and covers cross-region resiliency with disaster recovery. For a more detailed overview of reliability in Azure, see [Azure reliability](https://docs.microsoft.com/azure/architecture/framework/resiliency/overview.md).
19
+
This article describes reliability support in Azure Storage Mover and covers cross-region resiliency with disaster recovery. For a more detailed overview of reliability in Azure, see [Azure reliability](/azure/architecture/framework/resiliency/overview).
15
20
16
21
### Regional reliability
17
22
18
-
When deploying an Azure Storage Mover resource, you must select a location. Instance metadata about the Storage Mover is stored in the region it is configured. This includes projects, endpoints, agents, job definitions, and job run history. Instance metadata does not include the actual data that is being migrated. For on-premises data sources disaster recovery is the responsiblity of the customer. Azure storage accounts used as a migration target have their own reliability support.
23
+
When deploying an Azure Storage Mover resource, you must select a location in which the resource's instance metadata is stored. Instance metadata includes projects, endpoints, agents, job definitions, and job run history, but doesn't include the actual data to be migrated. Azure storage accounts to be used as migration targets have their own reliability support. Disaster recovery for on-premises data sources is the responsibility of the customer.
19
24
20
-
Instance metadata is replicated across multiple availability zones in regions where they are available. Availability zones are unique physical locations within an Azure region. Each zone is made up of one or more data centers equipped with independent power, cooling, and networking.
25
+
Instance metadata is replicated across multiple availability zones in regions where availability zones are available. Availability zones are unique physical locations within an Azure region. Each zone is made up of one or more data centers equipped with independent power, cooling, and networking.
21
26
22
-
For regions that are paired for cross-region replication, instance metadata is also replicated to multiple regions, but will never leave the geography.
27
+
Some regions are paired in order to allow cross-region replication. When cross-region replication is utilized, instance metadata is replicated to each region, but is never permitted to leave the geography.
23
28
24
-
When registering a Storage Mover agent, the agent connects to the region of the Storage Mover resource it is registered with. If the Azure region your agent connects to is affected by an outage, the agent itself is not affected, but management operations using Azure may be unable to complete. In addition, any ongoing data migrations to storage accounts located in the affected region may fail.
29
+
When a Storage Mover agent is registered, it connects to the region in which the Storage Mover resource is registered. If an agent's Azure region experiences an outage, the agent itself isn't affected, but management operations that rely on Azure may be unable to complete. In addition, any active data migrations to storage accounts located within the affected region may fail.
25
30
26
31
In the unlikely event of a full region outage, you have the option of using one of the following strategies:
27
32
28
-
* Wait for Azure to recover the region
29
-
* Redeploy your resources to a different region
30
-
* Deploy a redundant Storage Mover in advance
33
+
- Wait for Azure to recover the region
34
+
- Redeploy your resources to a different region
35
+
- Deploy a redundant Storage Mover in advance
31
36
32
-
The last two options are a matter of timing, deployment occuring either before or after any future outage.
37
+
The last two options are a matter of timing, since deployment will occur either before or after any future outage.
33
38
34
39
### Determining reliability for target storage accounts
35
40
36
-
Any migration target storage accounts may need their own recovery steps. This will depend on the redundancy options that were choosen for the storage account. See [storage account disaster recovery](https://learn.microsoft.com/en-us/azure/storage/common/storage-disaster-recovery-guidance) to determine any additional steps.
41
+
Any migration target storage account may require its own recovery steps. This requirement depends on the redundancy options chosen for each storage account. See the [storage account disaster recovery](/azure/storage/common/storage-disaster-recovery-guidance)article to determine whether more steps are necessary.
37
42
38
-
If no reduendancy options were choosen (local storage) you may need to create a new storage account for use in migrations during the outage.
43
+
If a local storage was chosen in lieu of redundancy options, you may need to create a new storage account for use in migrations during the outage.
39
44
40
45
### SLA improvements
41
46
42
-
There are no increased SLAs for Azure Storage Mover. For more information on the Azure Storage Mover SLAs, see [TODO-replace-with-link-to-SLA-documentation-for-service].
47
+
There are no increased SLAs for Azure Storage Mover.
43
48
44
49
### Zone down experience
45
50
46
-
During a zone-wide outage, no action is required during zone recovery. Azure Storage Mover will self-heal and re-balance itself to take advantage of the healthy zone automatically.
51
+
During a zone-wide outage, no action is required during zone recovery. Azure Storage Mover is designed to self-heal and rebalance itself to take advantage of the healthy zone automatically.
47
52
48
53
## Disaster recovery: cross-region failover
49
54
50
-
In the case of a region-wide disaster, Azure can provide protection from regional or large geography disasters with disaster recovery by making use of another region. For more information on Azure disaster recovery architecture, see [Azure to Azure disaster recovery architecture](https://learn.microsoft.com/en-us/azure/site-recovery/azure-to-azure-architecture).
55
+
Azure can provide disaster recovery protection against a region-wide or large geography disaster by making use of another region. For more information on Azure disaster recovery architecture, see the article on [Azure to Azure disaster recovery architecture](/azure/site-recovery/azure-to-azure-architecture).
51
56
52
-
Azure initiated disaster recovery is only applicable for those regions that have are paried with a cross-region replication region. Azure Storage Mover uses Cosmos DB for storing instance metadata. Data loss may occur only with an unrecoverable disaster in the Azure Cosmos DB region. For more information, see [Region outages](https://learn.microsoft.com/en-us/azure/cosmos-db/high-availability#region-outages). Azure initiated recovery is active-passive, and full recovery of a region may be up to 24 hours.
57
+
Azure initiated disaster recovery is only applicable for those regions that have are paired with a cross-region replication region. Azure Storage Mover uses Cosmos DB for storing instance metadata. Data loss may occur only with an unrecoverable disaster in the Azure Cosmos DB region. For more information, see [Region outages](/azure/cosmos-db/high-availability). Azure initiated recovery is active-passive, and full recovery of a region may be up to 24 hours.
53
58
54
-
Customers can minimize downtime by following customer enabled disaster recovery steps described below. This requires additional steps to be inacted before a disaster occurs, so review and plan accordingly.
59
+
Customers can minimize downtime by following the customer enabled disaster recovery steps described in this section. These strategies may require that further steps be taken prior to a disaster, so be sure to review and plan accordingly.
55
60
56
61
### Customer enabled disaster recovery
57
62
58
63
#### Deploy resources to a different region
59
64
60
-
To redeploy resources to a different region, you must first have a snapshot of the resources you wish to redeploy. Taking a snapshot should be done periodically on a schedule or after you make substantial changes, since by definition, access to your resources may be impacted during an outage. Storing the snapshots using a version control system is a good way to store and track history of the snapshots.
61
-
62
-
See documentation on [exporting templates](https://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/export-template-portal) for further instructions on exporting resources as an Arm Resource Manager template.
65
+
Since access to your resources may be impacted during an outage. To redeploy resources to a different region, you must first have a snapshot of the resources you wish to redeploy. To ensure that you're restoring the most recent data, taking a snapshot should be done periodically, either on a schedule or after you make substantial changes. Storing the snapshots using a version control system is a good way to store and track history of the snapshots.
63
66
64
-
You should do a "Resource Group" export on the resource group containing the Storage Mover to capture the current state. This document assumes only Storage Mover and related resources are in the resource group. If this is not the case, you may need to remove or otherwise exclude unrelated resources from the template.
67
+
See the documentation on [exporting templates](/azure/azure-resource-manager/templates/export-template-portal) for further instructions on exporting resources as an Azure Resource Manager (ARM) template.
65
68
66
-
The existing agent(s) cannot be reused in a different region. If the region they were configured for is experiencing an outage, it may not be possible to completely unregister and re-register the agent. Because of this, this document assumes you will be registering a new Agent for the new region.
69
+
If your Storage Mover and related resources reside in a container with no extra resources, you should perform a **Resource Group** export to capture the current state. However, if your resource group contains unrelated resources, you may need to remove or otherwise exclude the resources from the template.
67
70
68
-
To use the exported template for disaster recovery, a few changes to the template need to be made.
71
+
Existing agents can't be redeployed to a different region. If the region in which they were originally configured experiences an outage, it may not be possible to completely unregister and re-register the agent. This document assumes that new agents are registered within a new region.
69
72
70
-
* The first is to remove any `Microsoft.StorageMover/agents` and `Microsoft.HybridCompute/machines` resources from the template. Also be sure to remove any dependency references to these resources as well.
71
-
72
-
* Remove the `agentResourceId` property from all Job Definitions. You will assign them to a new Agent after deployment.
73
-
74
-
* After removing all references to agent and Hybrid Compute machine resources, update the location property on the top level Storage Mover resource to the name of the region you will deploy into.
73
+
To use the exported template for disaster recovery, a few changes to the template are required.
75
74
76
-
* Verify if you will keep the existing storage account resource ID, or need to replace it with a different storage account.
75
+
- First, remove any `Microsoft.StorageMover/agents` and `Microsoft.HybridCompute/machines` resources from the template. Be sure to remove any dependency references to these resources as well.
76
+
- Next, remove the `agentResourceId` property from all job definitions. You'll need to assign them to a new Agent after deployment.
77
+
- After removing all references to agent and Hybrid Compute machine resources, update the location property of the top level Storage Mover resource. Replace the name of the currently deployed region with the name of the new region.
78
+
- Finally, determine whether to keep the existing storage account resource ID. If necessary, replace it with a different storage account.
77
79
78
-
The template is now ready to be deployed into a new region. Verify that the template parameters are correct. You should deploy the template to a new resource group that has the same default region as the location property in the template.
80
+
After completing the previous steps and verifying that the template parameters are correct, the template is ready for deployment to a new region. You should deploy the template to a new resource group that has the same default region as the location property in the template.
79
81
80
82
#### Registering the new agent
81
83
82
-
Go through the [deply an Azure Storage Mover agent](https://learn.microsoft.com/en-us/azure/storage-mover/agent-deploy)steps to register a new agent in the new Storage Mover resource.
84
+
Follow the steps within the [deploy an Azure Storage Mover agent](/azure/storage-mover/agent-deploy)article to register a new agent in the new Storage Mover resource.
83
85
84
86
#### Assigning the agent to job definitions
85
87
86
-
After the new agent has been registered and reports as online, use the portal or PowerShell to update the job definitions to be associated with the new Agent.
88
+
After the new agent has been registered and reports as online, use the Azure portal or PowerShell to associate the existing job definitions to the new agent. The following PowerShell example is provided for convenience.
87
89
88
-
See [define a new migration job](https://learn.microsoft.com/en-us/azure/storage-mover/job-definition-create) for steps on how to navagate to the job definitions for your project.
90
+
See the [define a new migration job](/azure/storage-mover/job-definition-create) for guidance on how to access the job definitions for your project.
89
91
90
92
```powershell
91
93
92
94
## Update the agent in a job definition resource
93
-
$resourceGroupName = "Your resource group name"
94
-
$storageMoverName = "Your storage mover name"
95
-
$projectName = "Your project name"
96
-
$jobDefName = "Your job definition name"
97
-
$agentName = "The name of an agent previously registered to the same storage mover resource"
95
+
$resourceGroupName = "[Your resource group name]"
96
+
$storageMoverName = "[Your storage mover name]"
97
+
$projectName = "[Your project name]"
98
+
$jobDefName = "[Your job definition name]"
99
+
$agentName = "[The name of an agent previously registered to the same storage mover resource]"
#### Granting agent access to the target storage container
108
110
109
-
To successfully perform a migration job, you need to assign the system managed identity of the Hybrid Compute resource created for the agent access to the resource.
110
-
111
-
See [assign a managed identity access to a resource](https://learn.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/howto-assign-access-portal) for steps on how to grant access to the target storage account resource. You need to assign the data contributor role to the managed identity.
111
+
You need to assign the data contributor role to the managed identity to successfully perform a migration job. Assign the Hybrid Compute resource's system managed identity access to the target storage account resource. The [assign a managed identity access to a resource](/azure/active-directory/managed-identities-azure-resources/howto-assign-access-portal) article provides guidance on how to grant access to the target resource.
112
112
113
-
You are now ready to start migration jobs using the newly deployed Storage Mover resources.
113
+
You're now ready to start migration jobs using the newly deployed Storage Mover resources.
114
114
115
115
## Next steps
116
116
117
117
> [!div class="nextstepaction"]
118
-
> [Resiliency in Azure](/azure/availability-zones/overview.md)
118
+
> Read more about [Resiliency in Azure](/azure/availability-zones/overview.md).
0 commit comments