What is ASR in Azure?
Azure Site Recovery (ASR) is a DRaaS offered by Azure for the cloud and hybrid cloud architectures. Almost a constant data replication process makes sure data is in sync. At the time of failover, the consistent snapshot feature of Azure Site Recovery ensures that the data is in a usable state.
ASR offers support for multiple scenarios:
Replication of physical servers from on-premises and third-party service providers to Azure
Windows and Linux VMs hosted in VMware and Hyper-V to Azure
Windows VMs hosted in AWS to Azure
Windows and Linux VMs in Azure Stack to Azure
Note: ASR also supports replication of VMs in Hyper-V and VMware to a secondary site however, these scenarios are being deprecated and will no longer be supported by March 2023.
The Advantages of ASR:
Cost-effective: ASR will charge us for every protected instance, which is in the addition to the storage cost implemented for the data replication. For the first 31 days, we will get the service at no added cost, after which the protection charges will kick in. The data transferred to storage is compressed by approx. 50%, which further reduces the storage cost. The cost is added for computing, network infrastructure, facility rental, or software licensing fees during the process of ongoing protection.
Data resilience: The data which is replicated gets stored in Azure storage, which is resilient by default. Minimum of three copies of the data available in locally-redundant storage (LRS). Though, customers can choose to use geo-redundant storage (GRS) to protect from regional outages.
Heterogeneous workload: ASR supports
1. Windows and Linux workloads hosted on physical servers on-premises
2. VMs hosted in VMware/Hyper-V
3. Machines in the third-party hosting platforms/cloud.
4. It can also protect VMs in Azure from regional outages.
ASR console provides a unified view of the replication status of all workloads from where we can carry out maintenance tasks, tweaking recovery plans.
App consistent: ASR captures the in-memory data and transactions along with the disk data to ensures that the recovery points are application-consistent. For Windows, it is enabled through VSS, and in Linux, it is done using application custom scripts.
BCDR integration: ASR provides seamless integration BCDR features such as SQL Always-On & Oracle Data Guard which helps organizations to adopt the service without major changes in their application.
Non-disruptive testing: ASR runs non-disruptive failover and DR drills. This helps in end-to-end testing of DR plans without impacting on the replication.
RPO and RTO targets: ASR supports replication frequencies as low as 30 seconds and can be modified to meet specific RPO and RTO. By integrating automation run books with our recovery plans as well as integration with the Traffic manager, the RTO can be reduced.
Replicate Data to the Cloud With ASR
We will see how to replicate data to the cloud using ASR. As any organization will first need an agile plan to ensure a successful DRaaS strategy.
1. Planning Stage
Several factors govern a DRaaS strategy: RTO and RPO goals, storage (IOPS and storage account), capacity planning, network bandwidth, network reconfiguration, and daily change rate.
Azure Site Recovery Deployment Planner can help us analyze the environment for VMware and Hyper-V environments, and plan for capacity in the target Azure environment.
We can choose to retain existing IP addresses, but that would require a failover of the entire subnet in addition to the machine. Alternatively, a new network range from Azure can be used if that works for the application architecture after failover.
Prerequisites - support Matrix
TIPS: Lookout for limitations like supported operating systems, the 4 TB limit for managed disks, and the 8 TB limit for disks on storage on each protected VM. Also, lookout for additional charges for storage account usage, storage transactions, and outbound data transfers when configuring ASR.
2. Prepare and Configure
The first step is to prepare the source.
ASR supports several source environments like
1. VMware (with or without vCenter)
2. Hyper-V VMs (with or without SCVMM)
3. Physical servers
4. Azure VMs.
The next step is to prepare the target environment in Azure.
The first thing we do is to create a Recovery Services Vault in Azure. The Recovery Services Vault will hold the replication settings and manage the replication.
Next step is to create storage and network accounts which holds the replicated on-premises machines.
Lastly, configure and enable replication. After the source and target are prepared, we will create a replication plan that aligns with the RTO and RPO. Now select the Virtual Machines to be replicated and select the Replication policy that you defined earlier.
Finally, enable the initial replication. Once the initial replication is complete, ASR replicates data in incremental form (changed data) at an interval defined by your replication policy.
3. Failover and Failback
There are three types of failovers:
1. test failover
2. planned failover
3. unplanned failover.
A test failover has no impact on the production, but a planned or unplanned failover involves shifting the production site to the replication site such as Azure or another host.
A test Failover can be done either through a recovery plan or manually for each VM.
If you executed a planned failover, don’t forget to reprotect the machines after they have failed over. Once your source site is up, you an failback the VMs using the process server, master target server, and a failback policy.
4. Protect VMs in Azure using Azure Site Recovery
Azure Site Recovery can be used to protect VMs in Azure by replicating them from one region to another.
The quick start steps for enabling this protection are listed below:
1. From the Azure portal browse to the Virtual machine->operations->Disaster Recovery.
2. Select target region from the geographic cluster. Click on “Next:Advanced Settings.”
3. Select the target environment settings. Select the subscription for your VM, its resource group, virtual network, and availability configuration (single instance, availability set, or availability zone). Here you can choose from one of the existing resource groups, virtual network or create a new one.
4. Select the cache storage which will be used to temporarily store data in the source region before replicating to target. You can also select the disks that will be replicated and the target disk type, i.e., Standard SSD/HDD or Premium SSD. The subscription where the vault exists, the name of the vault and replication policy to be used for the replication can be selected here. Click on “ Review+start replication.”
5. In the next page, click on “Start replication.”
6. Once the initial replication is completed, the protection status can be checked from Virtual machine -> Operations->Disaster Recovery.
If you need my assistance, share us the details @techsurinder and I will get back to you.