In my Previous article we have discussed about planning stage. Before you start implementing Azure to Azure ASR you should be aware what are the limitations and supported configurations to implement ASR, you can refer support matrix link shared in last article.
Its commanded to implement ASR in Paired Region (Well Described), In this article I used East US and East US2 because my subscription was not having enough resources to West US region.
In this article we are going to implement ASR for replicate Azure VMs from one region to another region as DR solution. Please remember High availability (HA) & Disaster recovery (DR) both have different definition and different approach and here we are talking about DR that ideally in case of a region-wide disaster occurred.
- Create Recovery service vault in target (Paired) region.
Login to Azure Portal and create Recovery service vault.
2. Create Virtual Network in target (Paired) region (optional)
Create Virtual network in Target region.
3. Network mapping between Azure regions (optional)
Go to Recovery Vault > In Manage> Site Recovery Infrastructure> FOR AZURE VIRTUAL MACHINES> Network mappings, Click on + Icon to add network Mapping.
Network mapping ensures that when replicated virtual machine is created in the target Azure region, it is created on the virtual network that is mapped to virtual network of the source virtual machine. If network mapping is not done when you are replicating a virtual machine for the first time from one Azure region to another, then you can choose target network as part of the same process. Else Site Recovery creates a network in the target region that is identical to the source network and by adding ‘-asr’ as a suffix to the name of the source network.
Subnet of the target virtual machine is selected based on the name of the subnet of the source virtual machine. If there is a subnet of the same name as that of the source virtual machine available in the target network, then that is chosen for the target virtual machine. If there is no subnet with the same name in the target network, then alphabetically first subnet is chosen as the target subnet.
4. Create Replication Policy
You can also define your replication policy below to network Mapping.
Go to Recovery Vault > In Manage> Site Recovery Infrastructure> FOR AZURE VIRTUAL MACHINES> Replication policies, Click on + Icon to Create replication policy.
5. Enable replication
Go to Recovery Vault >GETTING STARTED>Site Recovery>Prepare infrastructure
Select source and target Azure (As you see below, No Preparation required for Azure to Azure scenario)
Click on Step 1-Enable replication and select your source details.
Select Virtual Machine which you want to protect
In Settings > Configure settings, ensure that the target location is the same as the location of the recovery vault. You can click on ‘Customize’ to change the default resource group, network, storage and availability sets.
Once you Click Create target resources, Do not close the blade when the required target resources are being provisioned. It should take about a minute to complete. If you close the blade or refresh the browser, you need to start the ‘Enable replication’ step again.
Click Enable replication once the above steps are complete.
This will trigger the VM replication and you can track progress of the Enable Protection job in Settings > Jobs > Site Recovery Jobs. Depending on the size of the disks, it can take a few hours before the initial data synchronisation is complete. From Settings > Replicated Items you can view the status of the protected VM and the initial replication progress.
Clicking on the VM name launches the VM overview blade where you can see various settings related to the replicated VM like Size of VMs, subnet, RG, IP etc.
6. Configure Recovery Plan
Recovery Plan is good and below are benefits
- Define groups of machines that fail over together, and then start up together.
- Model dependencies between machines, by grouping them together into a recovery plan group. For example, to fail over and bring up a specific application, you group all of the VMs for that application into the same recovery plan group.
- You can also define pre and post tasks in Recovery plan which ensure those task should be completed during test or unplanned failover.
Go to Recovery Vault > In Manage> Recovery Plans (Site Recovery)> + Icon >Create recovery plan. Give Recovery Plan name, Source, Traget, Deployment Model and Select VMs.
I have defined 4 VMs in 4 group than means my first group VM come online first and group 4 VMs will come online last also I can define pre and Post action in recovery plan where I can give reference of my Automation’s account runbook as pre and Post action.
7. Test Failover
Go to recovery plan and click on test failover. Choose your preference an click OK.
Once test failover complete you can access your created VMs during test failover and once you confidante enough you can click on Cleanup test failover. This will remove all the resources created during test failover.
Microsoft recommends you should failover atleast once in every 60 days.
The unplanned failover option initiates the actual failover of the VM from the original Azure location to the failover location.
Go to recovery Plan click on More and click on Failover.
Select Shut down machine before beginning failover to specify that Site Recovery should try to shut down the protected virtual machines and synchronize the data so that the latest version of the data will be failed over.
You can track progress by clicking on the VM to open its properties, or on the Unplanned Failover job in vault name > Settings > Jobs > Site Recovery jobs.
After the failover, the virtual machines are in a commit pending state. You can change the recovery point based on you need before committing the failover. Click Commit to confirm the current failover point. Committing a failover is a non-reversible operation so ensure that the failed-over VM boots and meets your failover requirements. Post a commit, all previous recovery points are removed.
9. Re-protect after failover
After failover is complete the virtual machines start up and are running at the secondary location. However, they aren’t protected or replicating. When the primary site is available again with the same underlying infrastructure, you must reverse replicate the VM. This ensures that all the data is replicated back to the primary site, and that the virtual machine is ready for failover again.
Go to recovery Plan click on More and click on Re-protect.
Once the re-protect operation completes and the VM is again under protection, you can click on the VM summary under Settings > Replicated Items and verify the direction of the replication.
After failover and reprotection of the VM, the machine is now is ready to be failed back to the original site. This involves performing an unplanned failover in the opposite direction to that done before.
The process is similar to that of the initial failover, the difference being the direction of the failover compared to the original.
11. Re-protect after failback
After failback (failover from target site to source site) is complete the virtual machines start up and are running at the secondary location. However, they aren’t protected or replicating. You need to enable replication to the target site following the same steps listed in Step 9.
For any ASR operation, you can track the progress and get details by going to Jobs > Site Recovery Jobs in the left menu of recovery services vault dashboard.
Conclusion- I would say Azure to Azure (Preview) is good enhancement for DR solution and that helping us for Planning DR solution for our clients those looking DR solution in Azure for their mission critical applications. Azure Site Recovery is less expensive and more flexible than other disaster recovery options. Even its in Preview but Microsoft providing technical support for ASR Azure to Azure scenarios.
Refer below Microsoft article for Azure to Azure architecture