Menu
Azure Site Recovery (ASR) can provide quick, simple, and cost-effective means to design and deploy a functional disaster recovery plan. ASR can work with many on-premises technologies as well as within Azure. Microsoft has tested out many crucial business applications to ensure ASR can provide failover capabilities. In addition, you will find that ASR provides great flexibility and integration to test and implement your disaster recovery plan with little to no disruption in services. In this article we will review the supported workloads of ASR as well as several of the key features and capabilities that come with the solution.
Supported Workloads
ASR can replicate and protect the following types of servers to Azure or a secondary site:
ASR supports many workloads. The servers must also meet Azure VM requirements. The following list is primarily for VMWare and physical servers. ASR supports any Hyper-V VM guest OS that is supported by Azure.
Replication Policies
Recovery Time Objective (RTO) in ASR means the period when a failover starts to the time the process completes and a virtual machine is running in Azure. Recovery Point Objective (RPO) is the maximum time of acceptance for data loss. With ASR, you create replication policies to define specific settings that affect both RTO and RPO. Replication policies are used to define certain parameters to obtain your desired RTO and RPO. Replication policies are similar across supported types with some differences. With Hyper-V you must specify a copy frequency of either 30 seconds or 5 minutes for recovery points. With VMWare, physical machines, and Azure replication is continuous. Additionally, you must specify retention of the recovery points. Hyper-V allows for up to 24 hours, while all others can allow up to 72 hours of retention. Finally, you need to select App-consistent snapshot frequency. App-consistent snapshots capture disk data, all data in memory, and all transactions in process. The following shows a sample policy for Hyper-V and VMWare.
ASR replicates data to an Azure storage account using a public endpoint rather than a VPN connection or using ExpressRoute public peering. Replication over a site-to-site VPN is not supported.
Failover and Failback
Failbacks can take several hours depending on the circumstances. If the virtual machine already exists and the failover was not for an extended period, failback should be quick. If the VM no longer exists and needs recreated, the data needs to be downloaded to the failback location, which could take hours depending on size and connection speed.
Recovery Plans
A recovery plan provides custom automation to failover and failback tasks. You can group several servers together based on dependencies, such as Multi-tier web app, SQL AlwaysOn group, or Exchange DAG, so in a failover event all machines will failover together. In addition, you can specify specific tasks, such as shut down, or even apply pre-failover or post-failover PowerShell scripts or Azure Automation runbooks to be run against each machine.
ASR can provide all the capabilities of any 3rd party tool or even a secondary datacenter location. Yet no additional infrastructure is required, failover and failback can occur with a single click, and its features are designed to best meet your RTO and RPO per your Business Continuity and Disaster Recovery Plan. Our next article will go over the planning and capacity requirements for ASR. Contact Enabling Technologies to allow us to see how we can assist with your BCDR goals. You can also check out our other Azure offerings at our Azure page on our website.
Work with our team of experts who have “been there, done that” experiences to help you navigate your IT challenges. Contact us at info@eGroup-us.com to schedule time with our team.
Last updated on July 27th, 2023 at 01:37 pm
