Azure Site Recovery provides a method to easily replicate your on-premise workloads to Azure. Having a replicated workload in Azure enables the workload to be run in case it is not available on the on-premise systems, due to hardware or other failure. In this video, Sharon will explain the process and requirements.
- [Instructor] Azure Site Recovery, or ASR, is not a backup, but a replica of your on-premise virtual or physical machines. The replicas are directed to either Azure or a secondary data center of your choice. This replica provides a failover solution if the primary location or workload is unavailable. In this video, I will be providing an overview of ASR. But, for more specific details and scenarios, please refer to the links provided. Before we jump into this one, I think the Azure Site Recovery is probably one of the coolest services within Azure from an infrastructure point of view.
At the most basic level, ASR is disaster recovery as a service. It is easy to set up and is automated, providing near synchronous replication of your workloads. If your on-premise or primary environment becomes unavailable, the replicated workloads in Azure can be utilized to continue with the business until those on-premise environments have been restored. You can protect Hyper-V virtual machines, VMware virtual machines, and even your physical servers. With Azure Site Recovery, you can configure how often that replication of your on-premise environment will occur.
The frequency ranges from 15 minutes, all the way down to 30 seconds. This means the most data you will lose in a failover scenario, will have been from 15 minutes ago. In my experience, most companies opt for the 15 minute interval. You can choose application-consistent snapshots to ensure data in-memory is also captured. Recovery plans group specific virtual machines to failover and start together. For example, you may need your domain controllers to start prior to your application servers.
Recovery plans also enable manual processes and scripts to be applied to these groups. Recovery plans can be tested during a test failover. I would highly recommend that you test your recovery plans during a test failover scenario. So, what is a test failover? The last thing you wanna do is test your failovers during an outage. Azure Site Recovery provides a test failover option that let's you validate your solution without impacting your current environment or your users using it.
In the test failover mode, no data is lost and there is no downtime. It is in this mode, connectivity to the failover site can be tested and documented. I would highly recommend that you test your failover strategy soon after the replications have completed. You never know when an outage could occur. We may be in the situation where we have a planned failover. A planned failover is when we know that our on-premise environment will not be accessible. This could be for planned maintenance or when an outage may be predicted, for example, a weather-related outage.
In a planned failover, there is no data loss, but there will be some downtime as the systems transition to the virtual machines that are in Azure. And finally, we have the unplanned failover. This is a reactive failover because the outage has already occurred. Examples of an unplanned outage could include a hardware failure or a power outage. There is going to be some data loss, and this data loss will be based on how often that data was replicated and the last synchronization of that data.
And as with a planned failover, there will be downtime as the replica systems come online. Once our primary location is back up online, we can failback. This applies to both the planned and the unplanned failover models. The virtual machines in Azure are replicated back to the primary site. And depending on the workloads that you have replicated into Azure, you may need a configuration server to be able to fail them back to your on-premise environment. And, just as a reminder, as I have already mentioned, ASR can be used as a migration strategy to move your virtual machines into Azure instead of doing it manually through PowerShell.
- Understanding cloud technologies
- Why Azure?
- Creating virtual networks and storage
- Using Azure Active Directory for identity management and protection
- Disaster recovery with Azure Backup and Azure Site Recovery
- Working with virtual machines