What is Azure Site Recovery and why should you care?
How to prevent business disasters
Outside of Cyber Security, one of the biggest priorities for businesses today are around fault tolerance and business continuity. Businesses need to be able to recover from any type of catastrophe – the kinds of outages caused by natural events or operational failures (such as BA unplugging their UPS!), quickly and with as minimal downtime and monetary loss as possible.
To achieve this, businesses need to have a solid Business Continuity and Disaster Recovery (BCDR) strategy in place, and many are looking to Cloud Services to provide world-leading Disaster Recovery as a Service (DRaaS) services for their organisation. Microsoft’s DRaaS offering Azure Site Recovery (ASR), which was named industry leader by Gartner in 2016.
The Advantages of ASR
The biggest advantage of ASR over many of its competition is its cheapness, I mean, cost-effectiveness. But there are loads of advantages.
DRaaS solutions in the cloud are plentiful and vary in price, and ASR is cheaper than its’ leading industry rivals. The savings extend far beyond just its initial pricing since by providing access to Azure as a secondary site, removes the costs of building, maintaining or renting a secondary physical site for DR.
Azure Site Recovery offers a powerful yet low-cost alternative to traditional hosted or self-provisioned DR environments since the only ongoing costs are for the storage required to support the application replicas and any desired retention of recovery points as well as the per-machine-per-month service fees. It is worth noting that with ASR, there is no compute, network infrastructure, facility rental, or software licensing fees required during the ongoing protection.
ASR has the advantage of being really simple to use when replicating Hyper-V or VMware Virtual Machines as well as physical Windows and Linux servers. The Azure ASR console provides a single pane of glass view on the replication status of all of the different workloads and allows you to carry out maintenance tasks, such as tweaking recovery plans.
It is possible to use ASR to migrate workloads from on-premises, Amazon Web Services (AWS) or from other Azure regions. This can help provide a flexible replication option for customers’ hybrid environments.
ASR provides application and workload protection and integrates with many critical workloads, including Active Directory, DNS, Exchange, SAP, SQL Always On, and Oracle.
The primary role of DRaaS is of course about recovery. ASR handles recovery extremely well. High recovery time objective (RTO) and recovery point objective (RPO) thresholds can be very costly to a business, and SR provides replication frequencies as low as 30 seconds (for Hyper-V) and continuous replication for VMWare. This means ASR users are provided with very low RPO thresholds. RTO can be also be reduced significantly through the automation and use of Azure Traffic Manager.
In addition to carrying out non-planned failovers during production downtime, ASR can carry out detailed test failovers or planned failovers to test DR capabilities and planned outages. ASR’s customisable recovery plans also allow sequenced failover and recovery of multi-tiered apps like Database and Web Services.
Replicating Data to the Cloud With Azure Site Recovery
In order to provide this DR and BC capability Azure Site Recovery needs to get your primary services and data into the Cloud in the first instance. Cisilion can work with you and your Microsoft Account Team to successfully implement a robust DRaaS solution with ASR through the following approach.
1.Planning and Scoping Phase
There are a number of factors that define a DRaaS strategy: RTO and RPO objectives, storage (IOPS and storage requirements), capacity planning, network bandwidth, network reconfiguration, and daily change rate.
Microsoft provides a number of brilliant tools such as Azure Site Recovery Capacity Planner and Azure Site Recovery Deployment Planner which we use to help analyse our customer’s environments, and compute requirements for the new target environment.
A vital aspect of Azure ASR that needs to be considered is network planning. This is important if you want to use a “stretched subnet” across both sites or whether you will use subnet failover. In the latter case, failover IP ranges need to be defined.
The ASR support Matrix needs to be reviewed and understand based on the applications and services for replicating using ASR. It is also prudent to verify the kinds of workloads that can be migrated using ASR.
2.Preparation and Configuration Phase
Once a migration plan has been produced, the environment needs to be preparing for replication. The first step is to prepare the source environment. 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. There are of different requirements of course based on the source environment we are looking to protect.
Next, the destination environment needs to be configured. The destination or target for ASR replications can again be a Hyper-V host, VMware Site, or Azure. No matter which one is required, a Recovery Services Vault in Azure needs to be created. The Recovery Services Vault houses the replication settings and manages the replication process within ASR.
Next, replication needs to be configured and enabled. This requires creating replication plans that aligns with the RTO and RPO objectives and defining the Virtual Machines and applications to be replicated.
Finally, the replica needs to be enabled… After the initial replication is complete, ASR then replicates data in incremental chunks (changed blocks of data) at the interval defined by the replication policy.
3.Validation of Failover and Failback Phase
Once replication is complete and working, it is important to validate the configuration determine any changes that need to be made should a failover need to be invoked. There are a couple of ways to do this – perform a test failover or of course invoke an actual planned or unplanned failover.
A test failover has no real impact to the production environment, but a planned or unplanned failover involves shifting the entire production site to the failover replication site. A test Failover can be performed either through a recovery plan or manually for each Virtual Machine. If a planned failover is performed its important to ensure that the failed virtual machines are re-protected. Once the source site is back-up, the failback can be re-invoked using the process server, master target server, and a failback policy.
4.Run – Manage, Monitor and Troubleshooting Phase
Once ASR is running, we need to keep monitoring the replication services to ensure that RPO objectives stay aligned with the business.
As well as providing “job alerts” on the Azure console, ASR also has its own Event Log Source that can be useful for troubleshooting replication failures.
Hidden Gem: Using ASR for DC / Cloud Migration Capabilities
As well as being a leading tool for DRaaS and Business Continuity, ASR’s is able to not only migrate on-premises workloads to Azure, it can also be used to migrate cloud workloads such as AWS VMs and Azure VMs from other regions.
In ASR migration scenarios, then instead of executing a “failover”, a “migration” is instead performed. This, as you would expect, completely migrates the workload, stop replication, and therefore stop ASR from “billing” for the machine.
Rob Quickenden, Chief Strategy Officer at Cisilion
Want to know more?
Book a Innovation Centre workshop with Cisilion by filling in the form below.