Moving resources between Resource Groups, within same subscription is not a new thing. That goes for moving them between subscriptions as well. The process implies that we have a source set of resources, that have certain dependency between each other.
We choose the target location (another Resource Group or Subscription) and initiate the move. During the process, both source and target location are locked in changes. This means, no modifications, updates, delete operations can be performed on those resources. The default lock is for 4 hours, but the process usually finishes in less time.
And, yes, there is a difference whether we are moving Virtual Machines, Networking components, Recovery Services, Azure DevOps or App Services. Classic resource types are also supported for move operations, with specific limitations as well. More information regarding specific guidance can be found on the embedded links.
The focus of this article is the necessity to move resources between datacenter regions. The move can be initiated for various reasons. For this purpose, Microsoft introduced this Azure Resource Mover service, which is currently in Public Preview.
Preview services imply that there is no associated cost, but also no SLA. It’s not recommended to use them for production workloads.
What is Azure Resource Mover?
The service is aimed to fill in the gap of moving specific resources between different datacenter regions.
The need to move them, could be because:
- New region is available: bring the resources “closer to home”
- Services/features become available: move resources to a datacenter close to you, as those features become available
- Business reasons: move resources to specific regions due to specific market business needs, proximity of field offices/locations, mergers/acquisitions
- Governance requirements: move resources to align with specific data residency or classifications needs
- Deployment requirements: move resources due to error in deployment, or capacity needs
- Decommissioning: move resources in case a specific region is being decommissioned (worst case scenario)
Currently, the services support moving of the following resource types:
- Azure Virtual Machines (VMs) and associated disks
- Network interfaces (NICs)
- Availability sets
- Azure virtual networks
- Public IP addresses
- Network security groups (NSGs)
- Internal and public load balancers
- Azure SQL databases and elastic pools
Choosing the right tool
There are couple of tools You can use, depending on the scenario. As mentioned above, you can move resources between groups, subscriptions and/or regions.
- Move resources across regions
For this operation, you will use the Resource Mover hub. It will help you move them to target region, but also to a specific availability zone or availability set in that region.
- Move from within a resource group
Moving resources to another group/subscription, by using the Azure Portal, PowerShell, CLI or REST APIs. In case the move is between regions Resource Mover Hub will be used.
- Move resources between Azure clouds
Use the Azure Site Recovery service to move resources between public and government clouds. In addition to that, VMs can be moved to different availability zone within same region.
In Public Preview, only move to public regions is supported.
Azure Region move components and concepts
There are few components of the service, that are used during region move.
| Component | Details |
| Resource Mover | It coordinates with Azure Resource providers to orchestrate the move. It will analyze the dependencies, and manage/maintain the state during move process |
| Move collection | This is Azure Resource Manager (ARM) object. Its created during region move process. It contains metadata and configuration information of the source/target regions. |
| Move resource | Once you add resource in the collection, its being tracked by the Resource mover. It will maintain all the information in the collection (1:1 basis between source and target) |
| Dependencies | Resource mover will validate all dependencies between the resources in the Move collection. All dependencies must be resolved before you initiate the move. |
You will also need certain privileges in the subscription, in this case at least Contributor and User Access Administrator roles (or Owner).
Move process
The process of moving the resources, encompasses several steps.
As stated on the diagram, the process is as follows:
- Once resources are selected, they are added to the move collection. Then they are flagged as “Prepare pending”. In case dependencies are detected, validation process starts. Status is changed to “Validate dependency”
- All dependent resources need to be added to the collection. The process continues, until all dependencies are resolved
- Preparation process runs, and the actual preparation steps depend on the resource types. Two types are identified:
- Stateless resources: these have configuration information only, which means there is no need to continuously perform replication of data. This relates to resources, such as: virtual networks, network interfaces, load balancers and network security groups. The prepare process will generate ARM template.
- Stateful resources: these have both configuration and data that needs to move. This is relating to virtual machines and Azure SQL databases. The prepare process differs, depending on resource type, since replication of data to target region is needed.
- Once ready, move process will be initiated. Again, the actual method depends on the resource type:
- Stateless: this will deploy the imported ARM template in target region. Its based-on source settings and manual edits you made.
- Stateful: the move process will either create the resource or initiate a copy process to target region.
- After initial move is performed, we have two options to finalize the process. If we want to cancel the process, we choose Discard move. This will delete the resources created in target region. For stateful resources, the replication will continue. Use this option for testing. In case we will do a full move, we need to choose Commit move. You should be aware, that for stateful resources, this will result VMs or Azure SQL databases to be inaccessible. After it finishes, it will show it as completed or failed.
- Final phase of the commit process is the clean-up. Once it verifies that the target region resources are healthy, delete source process will start.
For more information on moving Azure VMs across regions and Azure SQL visit following Microsoft Doc locations:
You should be aware that some settings can be modified prior to move. For VMs that could be things like VM name, availability zone, VM SKU, network resources/configurations used.
In case of Azure SQL database, that would be things like name, and zone redundancy.
The recommendation would be to do it before the preparation process (Step 3). Detailed information is here.
Impact on resources during move
Different components are impacted by the move process:
- Data: resource data and metadata are moved. Metadata is stored temporarily to track status of dependencies and operations
- Resource: source is intact during the whole process, and target is being created.
- Move process: multi-step process involving manual intervention and monitoring
- Testing: important to make sure that the applications are working in the target region
- Downtime: some its expected, but no data loss
Conclusion
Yes, there are some obvious limitations, especially in the Platform services area (PaaS). I would not expect things to dramatically change in that area, though.
Overall, this proves to be an interesting and useful service that enables you to move resources between regions. You can start considering the movement of deployed resources “closer to home” even as we sepak.
Either way, keep an eye on this service and its future development
For more in-depth information, refer to the Microsoft Docs repository.
Be the first to comment