With disasters on the rise and increasing adherence to IT Standards Compliance, some of the biggest driving factors for companies today are fault tolerance and business continuity. Companies need to be able to recover from disasters – the kinds of outages caused by natural events or operational failures – quickly and with as minimal downtime and monetary loss as possible.
So what are the different stages in adopting Business Continuity and Disaster Recovery with Microsoft Azure Site Recovery?
- Planning Stage
There are several factors that govern a DRaaS strategy: RTO and RPO goals, storage, 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 to 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.
- 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.
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.
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.
- 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 has no impact to production, but a planned or unplanned failover involves shifting the production site to the replication site such as Azure or another host.
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.
- 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.
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.
If you are a current ASR user or planning to become one and you are wondering, how to get your data to Azure, Redington Cloud Solutions with its expertise in Azure Site Recovery can help you seamlessly adopt BCDR solutions and ensure business continuity.
