Some of the biggest driving factors for companies today are fault tolerance and business continuity. Companies need to be able to recover from catastrophes – the kinds of outages caused by natural events or operational failures – quickly and with as minimal downtime and monetary loss as possible.
To this end, it is essential to have a solid Business Continuity and Disaster Recovery (BCDR) strategy in place by employing a world-leading Disaster Recovery as a Service (DRaaS) solution.
This blog post will explore some of ASR’s capabilities, inner workings, and use cases to demonstrate what makes it a world class DRaaS solution.
The Advantages of ASR
The chief benefit of ASR is its cost-effectiveness.
DRaaS solutions in the cloud vary in price, and ASR is cheaper than its industry rivals. The savings extend beyond ASR’s pricing: by providing access to Azure as a secondary site, the costs of building and maintaining a secondary site can be avoided.
Azure Site Recovery offers a low-cost alternative to traditional hosted or self-provisioned DR environments because the only ongoing costs are for storage required to support the application replicas and the desired retention of recovery points and the per machine per month service fee.
There are no compute, network infrastructure, facility rental, or software licensing fees required during ongoing protection.
ASR also has the advantage of being easy to use when replicating Hyper-V or VMware VMs, and physical Windows and Linux servers. The Azure ASR console provides a unified view on the replication status of all your different workloads and allows you to carry out maintenance tasks, such as tweaking recovery plans.
You can use ASR to migrate workloads from on-premises, AWS, or even other Azure regions. This can also provide a flexible replication option for hybrid environments.
For workload and application protection, ASR integrates with several critical workloads, including Active Directory, DNS, Exchange, SAP, SQL Always On, and Oracle Data Guard.
DRaaS is about recovery, and ASR handles recovery very well. High recovery time objective (RTO) and recovery point objective (RPO) thresholds can be costly to an organization, so ASR provides replication frequency as low as 30 seconds (for Hyper-V) and continuous replication for VMWare.
That means ASR users are provided with low RPO threshold. RTO can be reduced greatly through automation and use of Azure Traffic Manager. ASR’s rich automation and orchestration is provided through PowerShell and production-ready Azure Runbooks, which help in making the recovery process consistently accurate and repeatable.
To further prepare your system in case of a failure, ASR can run non-disruptive failover and DR drills. In addition to executing non-planned failovers during production downtime, ASR can carry out test failovers or planned failovers to test DR capabilities and planned outages.
ASR’s customizable recovery plans also allow sequenced failover and recovery of multi-tiered apps like Database and Web Services.
Here are some of the common ASR components and terminologies:
- ASR Service: Azure’s managed service, which is responsible for management and orchestration of whole processes
- Config Server: The centralized on-premises appliance coordinating VMWare and physical server replication
- Process Server(s): Caching, compression, and encryption for VMWare and physical server bi-directional replication during.
- Mobility Service: Captures block level changes in memory on each protected VMware or physical machine. Supports filesystem (Linux) and application (Windows) level consistency across multiple servers in a consistency group.
- ASR Provider and the ASR Agent: Used for replicating and controlling replication of Hyper-V VMs
- HRL Files: Files that are used to track the delta replication changes that occur after the initial replication
Replicate Data to the Cloud With ASR
This section will provide a walkthrough for how to replicate data to the cloud using ASR. As with every DRaaS and migration project, your company will first need an agile plan to ensure a successful DRaaS strategy.
1. Planning Stage
There are several factors that govern a DRaaS strategy: RTO and RPO goals, storage (IOPS and storage account), capacity planning, network bandwidth, network reconfiguration, and daily change rate.
Microsoft-provided tools Azure Site Recovery Capacity Planner and Azure Site Recovery Deployment Planner can help you analyze your source environment and compute requirements for the target environment.
One aspect of Azure ASR to keep in mind at this point is network planning. You have to determine if you want to use a stretched subnet across both sites or if you will use a subnet failover. You will also need determine the failover IP ranges.
Make sure to review the support Matrix to understand the prerequisites for replicating using ASR. It is also prudent to verify the kinds of workloads that can be migrated using ASR.
You can find the full list here.
Pro tip: Lookout for limitations like a 4TB limit for individual disks on each protected VM. If workloads are being migrated from AWS, be aware that it is a one-way migration to Azure and the replication cannot be enabled back to AWS.
Also, lookout for additional charges for storage account usage, storage transactions, and outbound data transfers when configuring ASR.
2. Prepare and Configure
Now that we have a solid plan based on source environment analysis and capacity planning, we can start preparing our environments for replication. The first step is to prepare the source.
ASR supports several source environments like VMware (with or without vCenter), Hyper-V VMs (with or without SCVMM), AWS workloads, physical servers, and Azure VMs. It is important to note that there are different requirements based on the source environment.
For example, VMware VMs would require additional resources such as a configuration server, process server, and mobility services to help manage, coordinate, and send the encrypted and compressed data chunks to the Recovery Services destination.
The next step is to prepare the destination environment. The destination or target for ASR replications can be a Hyper-V host, VMware Site, or Azure. No matter which one you choose, the very first thing to do would be to create a Recovery Services Vault in Azure (either through Resource Manager or Classic portal).
The Recovery Services Vault will house the replication settings and manage the replication.
If your target is Azure, you need to create storage and network accounts which will house the replicated on-premises machines (note: for the storage accounts you’ll have to decide between standard and premium account types, and set the LRS and GRS replication options based on your RPO).
If you are replicating to a secondary site, you will need to prepare the hosts on the secondary site by installing the configuration components: Azure Site Recovery Provider for all SCVMM servers (in case of Hyper-V hosts) and InMage Scout components for VMWare machines or physical hosts.
Lastly, it is time to configure and enable replication. After the source and target have been prepped, you need to create a replication plan that aligns with your RTO and RPO objectives. Now select the Virtual Machines to be replicated and select the Replication policy that you defined earlier.
Finally, enable the initial replica (note: this process can take quite some time). After the initial replication is complete, ASR replicates data in incremental chunks (changed data) at an interval defined by your replication policy.
3. Failover and Failback
Now that you have performed the replication, it is time to validate the setup and determine if and what changes you need to make if you have to execute a failover. There are two ways to try this: a test failover or an actual planned or unplanned failover.
A test Failover can be done either through a recovery plan (to orchestrate failover of multiple machines) or manually for each VM through the Azure console.
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 can failback the VMs using the process server, master target server, and a failback policy.
Note: In Windows VMs, don’t forget to set the SAN policy to Online All if you want to retain the drive letters after failover.
4. Manage, Monitor, and Troubleshoot
It is advisable to keep monitoring your replication settings to ensure that your RPO objectives stay aligned. You can tweak replication settings or add scaled out process servers to meet these objectives.
Apart from providing job alerts on the Azure console, ASR also has its own Event Log Source that can be useful for troubleshooting replication failures. Here is a guide on what event sources and ports need to be looked at while troubleshooting these failures.
5. ASR Migration Capabilities
In addition to being an excellent BCDR tool, ASR’s migration capabilities deserve a special mention. Not only can you migrate on-premises workloads with ASR, you can also migrate cloud workloads such as AWS VMs and Azure VMs from other regions.
The initial setup for performing such migrations is very similar to replicating physical machines to Azure.
In ASR migration, instead of executing a failover you would migrate by right clicking the VM on the Azure portal and executing “Complete Migration.” This will completely migrate the workload, stop replication, and stop ASR billing for the machine.
You can find more details on that here.
Owing to its cost-effectiveness, ease of use, and support for an extensive list of workloads, ASR has established itself as a world-leader in BCDR solutions.
However, proper capacity and deployment planning are important steps before starting an ASR migration. It is important to educate yourself about ASR technology through blogs, forums, and real-world examples such as Paul Smith, Dartmouth-Hitchcock and Duro Dakovich.