Some of the biggest driving factors for companies today are fault tolerance and business continuity. Companies need to be able to recover from catastrophes – the kinds of outages caused by natural events or operational failures – quickly and with as minimal downtime and monetary loss as possible.
To this end, it is essential to have a solid Business Continuity and Disaster Recovery (BCDR) strategy in place by employing a world-leading Disaster Recovery as a Service (DRaaS) solution.
Simple BCDR Solution: Using Site Recovery, you can set up and manage replication, failover, and failback from a single location in the Azure portal.
Azure VM Replication: You can set up disaster recovery of Azure VMs from a primary region to a secondary region.
Workload Replication: Replicate any workload running on supported Azure VMs, on-premises Hyper-V and VMware VMs, and Windows/Linux physical servers.
RTO and RPO Targets: Keep recovery time objectives (RTO) and recovery point objectives (RPO) within organizational limits. Site Recovery provides continuous replication for Azure VMs and VMware VMs, and replication frequency as low as 30 seconds for Hyper-V. You can reduce RTO further by integrating with Azure Traffic Manager.
BCDR integration: Site Recovery integrates with other BCDR technologies. For example, you can use Site Recovery to protect the SQL Server backend of corporate workloads, with native support for SQL Server Always On, to manage the failover of availability groups.
Azure automation integration: A rich Azure Automation library provides production-ready, application-specific scripts that can be downloaded and integrated with Site Recovery.
Set up Azure Site Recovery simply by replicating an Azure VM to a different Azure region directly from the Azure portal. As a fully integrated offering, Site Recovery is automatically updated with new Azure features as they’re released. Minimize recovery issues by sequencing the order of multi-tier applications running on multiple virtual machines. Ensure compliance by testing your disaster recovery plan without impacting production workloads or end users. And keep applications available during outages with automatic recovery from on-premises to Azure or Azure to another Azure region.
Reduce the cost of deploying, monitoring, patching and maintaining on-premises disaster recovery infrastructure by eliminating the need for building or maintaining a costly secondary datacentre. Plus, you pay only for the compute resources you need to support your applications in Azure.
Easily comply with industry regulations such as ISO 27001 by enabling Site Recovery between separate Azure regions. Scale coverage to as many business-critical applications as you need, backed by Azure’s service availability and support. Restore your most recent data quickly with Site Recovery.
Here are some of the common ASR components and terminologies:
ASR Service: Azure’s managed service, which is responsible for management and orchestration of whole processes
Config Server: The centralized on-premises appliance coordinating VMWare and physical server replication
Process Server(s): Caching, compression, and encryption for VMWare and physical server bi-directional replication during.
Mobility Service: Captures block level changes in memory on each protected VMware or physical machine. Supports filesystem (Linux) and application (Windows) level consistency across multiple servers in a consistency group.
ASR Provider and the ASR Agent: Used for replicating and controlling replication of Hyper-V VMs
HRL Files: Files that are used to track the delta replication changes that occur after the initial replication
This section will provide a walkthrough for how to replicate data to the cloud using ASR. As with every DRaaS and migration project, your company will first need an agile plan to ensure a successful DRaaS strategy.
Planning Stage : There are several factors that govern a DRaaS strategy: RTO and RPO goals, storage (IOPS and storage account), capacity planning, network bandwidth, network reconfiguration, and daily change rate.
Prepare and Configure : 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).
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.
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
ASR Migration Capabilities : In addition to being an excellent BCDR tool, ASR’s migration capabilities deserve a special mention. Not only can you migrate on-premises workloads with ASR, you can also migrate cloud workloads such as AWS VMs and Azure VMs from other regions.