Companies should have a business continuity and disaster-recovery strategy for those unplanned (or planned) times that you don’t have regular working conditions. With this in mind, Azure has released Site Recovery to make sure you’re prepared.
Created to keep your workloads and data safe and available, Site Recovery hopes to get you returned to typical working conditions as quickly as possible. Essentially, according to Microsoft’s site, it is to “orchestrate replication, perform disaster recovery testing, and run failovers and failback.”
With this service, users can deploy application-aware replication to the cloud or a secondary site. It works with Windows or Linux-based servers that are on many different hosts, such as physical servers, VMware, or Hyper-V virtual machines.
There are quite a few different ways that application-level protection and recovery are increased with Site Recovery as seen on their blog, including low Recovery Point Objectives (RPOs) — reportedly as low as 30 seconds — replication of any workload that is running on a supported machine, and a recovery plan that allows users to recover full application stacks.
Along with app-consistent snapshots for both single and multitier applications, an automation library so users have access to specific scripts for their applications, and the ability to customize replication solutions on an app-by-app basis, Azure Site Recovery also offers these features:
- Integration with SQL Server AlwaysOn and partnership with other replication technologies, such as Oracle Data Guard and Exchange Database Availability Groups (DAGs).
- Advanced network management giving users the ability to reserve IP addresses, configure load-balancing, and integration with Azure Traffic Manager.
- The ability to recover an entire application script or include external scripts and manual actions in your flexible recover plans.
- Integrates with Microsoft applications, including SharePoint, Exchange, Dynamics, SQL Server, and Active Directory.
- Automated protection and replication of VMs and remote health monitoring.
- No-impact recovery plan testing and orchestrated recovery when necessary.
Let’s go a little more in-depth to understand more of these features and how they work.
Site Recovery is made to be both automated and controlled by you. Users are able to set and control policies of the replication of virtual machines. As mentioned before, it’s possible to use this application to protect Hyper-V, VMware, and physical servers.
Users are able to use Azure or a secondary datacenter as the recovering site. Azure Site Recovery integrates with already-existing technologies to coordinate and manage the ongoing replication of data.
Users are also able to automate processes for disaster recovery in the event of a site outage. This orchestrated Disaster Recovery as a Service (DRaaS) allows you to import applications in an orchestrated way in order to quickly restore service.
In the Microsoft Azure classic portal, users are able to create and store their disaster-recovery plans, making them either simple or complex for multitier workloads. According to Microsoft, you are able to include “the execution of custom Windows PowerShell scripts and Azure Automation Runbook, and pauses for manual interventions.”
Users also have the freedom to map virtual networks, customizing networks between their primary and recovery sites.
Send it to Azure
Of course, users are given easier options to replicate their workloads to Azure. You can either migrate your applications to Azure or temporarily send them when there is a surge in demand. You’re able to test new versions of the application with live data, then implement it into production in your datacenter. It’s also possible to run reports and analytics on copies of production workloads in Azure without impacting users.
Continuous health monitoring
Your protected instances are continuously and remotely monitored from Azure Site Recovery. For those concerned about security, it’s important to know that the data and replication of your virtual machines remain on your networks when replicating between two sites you control, and all communication with Azure is encrypted.
“Site Recovery does not intercept replicated data,” explains Microsoft, “and doesn’t have any information about what’s running on your virtual machines or physical servers.” Site Recovery, instead, has no ability to intercept the data between your servers and Azure storage or secondary site of your choice.
Is it as good as they say?
While all of these features of Azure Site Recovery seem great and simple to use, will it truly work like this for you?
It is true that in the unplanned event that affects your systems, the most recently synced data will be started up quickly. This typically takes just minutes, but of course, could take much more if it is a very complex workload.
If you have a failover that is planned, instead, they would transfer execution to the system running in Azure or your backup location after performing synchronization. Because of the data synchronization, this option takes longer, starting at around an hour for small workloads and increasing based on complexity.
On default, replication is set to 15 minutes, and although it’s not quite as quick as an instantaneous failover solution, the time is still relatively low. There is a wide range of automation options available for different applications and Azure Site Recovery is quite cost effective (more on that below).
How much is it?
Users are billed based on the number of instances protected. Azure gives all users the option to test it out first with a free 31 days for each instance that is protected with Site Recovery. After that, it’s either $16/month per instance protected to customer-owned sites or $25 to Azure.
Their website explains that the bill is calculated in units of the average daily number of instances you are protecting over a monthly period. They give the example that if you regularly protected 20 instances for the first half of the month and none for the second half, the average daily number of protected instances would turn out to be 10 for that month.
While no enterprise environment is exactly the same, there are a few different solutions that are best for you to implement Azure Site Recovery
Depending on your environment, this will likely be the easiest way to deploy Azure Site Recovery. It’ll have to meet the prerequisites that you can find here and is best suited for production environments with less strict firewall and network security rules.
Software deployment tools
Enterprises can perform an out-of-band installation using software deployment tools, such as System Center Configuration Manager (SCCM), Windows Server Update Service (WSUS), and more.
Use this method if you want to deploy at enterprise scale and avoid adding firewall exceptions or managing guest or protected virtual machine credentials. If you’d like to use a deployment tool, follow the instruction and scripts found here (the documentation given uses SCCM as an example).
Use Azure Automation Desired State Configuration (DSC)
If you use many Azure services in your production environment to manage your IT infrastructure, this is probably the choice you want. You can install and manage the lifecycle of Azure Site Recovery following the documentation page here.
Using this method, you can deploy at an enterprise scale, enforce software configuration on your protected servers, and won’t need to add firewall exceptions or manage guest credentials.
If you don’t have a software deployment tool you’d like to use and plan to protect five-10 servers, or would like to have proof-of-concept deployments, this is probably your best option.
You can use the command line or GUI to create scripts to automate installations in your production environment. All documentation for downloading it manually via the command line can be found here while installing Azure Site Recovery using GUI is here.
For more information, visit the blog post of Microsoft’ senior program manager Anoop K. Vasudavan.
Editor’s note: The article has been updated to mention that site recovery to Azure is $25 per instance, not $54 as previously stated.
Photo credit Shutterstock