Chapter 8 Azure Site Recovery (ASR)

This Chapter covers following

• Azure Site Recovery
• Replication scenarios with Azure Site Recovery
• Disaster Recovery Site option with Azure Site Recovery
• Architecture for Disaster Recovery to Azure
• Architecture for Disaster Recovery to Secondary Data Center
• Replication Architecture of Azure VMs in Azure Cloud to Azure Cloud
• Replication Architecture of VMware VMs or Physical Servers to Azure
• Replication Architecture of Hyper-V VMs Managed by VMM to Azure
• Replication Architecture of Hyper-V VMs to Azure
• Replication Architecture of Hyper-V VMs Managed by VMM to Secondary Datacenter
• Azure Site Recovery Pricing

This Chapter Covers following Lab Exercises to build below topology

• Enabling Disaster Recovery for Azure VM using Azure Site Recovery
• Demonstration of Failover of VM VMAD

Note: It is not mentioned in Exam syllabus the full scope of ASR. ASR is mentioned under VM Backups. Minimum you must focus on Replication Architecture of Azure VMs in Azure Cloud to Azure Cloud

Chapter Topology

In this chapter we will add ASR to the topology which is part of Backup and Site Recovery.

We will replicate VM VMAD in West US 2 region to East US 2 region using ASR. Site Recovery Mobility Service Extension will get installed on VM VMAD when replication is enabled on VMAD.

Azure Site Recovery

Azure Site Recovery provides Disaster Recovery as a Service (DRaaS).

Azure Site Recovery is an Azure Managed service that orchestrates and replicates Azure VMs and on-premises physical servers and virtual machines to the Azure cloud or to a secondary datacenter.

When outages occur in your primary location, you fail over to the secondary location to keep apps and workloads available. You fail back to your primary location when it returns to normal operations.

You can replicate Azure VMs in one Azure region to another Azure region.

You can replicate on-premises VMware VMs, Hyper-V VMs, Windows and Linux physical servers to Azure cloud or to a secondary datacenter.

Azure Recovery Services contribute to your BCDR strategy. The Azure Backup service keeps your data safe and recoverable. Site Recovery replicates, fails over, and recovers workloads when failure occurs.

Replication scenarios with Azure Site Recovery

Replicating Azure VMs in one region to another region in Azure Cloud: You can replicate Azure VMs from one Azure region to another Azure region.

Replicating on-premises VMs and Physical servers to Azure Cloud: You can replicate on-premises VMware VMs, Hyper-V VMs, Hyper-V VMs managed by SC VMM, Windows and Linux physical servers to Azure cloud.

Replicating to Secondary Data Center: You can replicate on-premises VMware VMs, Hyper-V VMs managed by VMM, Windows and Linux physical servers to Secondary Data Center. Note in this case we cannot replicate Hyper-V VMs to secondary Data Center.

Disaster Recovery Site option with Azure Site Recovery

1. Azure Cloud
2. Secondary Data Center ( Non applicable for Azure VMs)

Architecture for Disaster Recovery to Azure

Architecture for Disaster Recovery to Secondary Data Center

Replication Architecture of Azure VMs in Azure Cloud to Azure Cloud

You can replicate Azure VMs from one Azure region to another Azure region using Azure Site Recovery. Biggest advantage of this option is that ASR is integrated in the VM dashboard.

Figure below shows Azure to Azure replication architecture.

Requirements on Source Side

1. Cache storage accounts: Before source VM changes are replicated to a target storage account, they are tracked and sent to the cache storage account in source location

2. Site Recovery extension Mobility service: Mobility Service captures all data writes on VM disks and transfers it to Cache Storage Account.

Requirements on Target Side

Target resource group: The resource group to which Source VMs are replicated.

Target virtual network: The virtual network in which replicated VMs are located after failover. A network mapping is created between source and target virtual networks, and vice versa .

Target storage accounts: Storage accounts in the target location to which the data is replicated.

Target availability sets: Availability sets in which the replicated VMs are located after failover.

Replication Process

The Site Recovery Mobility service extension is automatically installed on the VM when you enable replication for an Azure VM.

1. The extension registers the VM with Site Recovery.
2. Continuous replication begins for the VM. Disk writes are immediately transferred to the cache storage account in the source location.
3. Site Recovery processes the data in the cache, and sends it to the target Storage Account or to the replica managed disks.
4. After the data is processed, crash-consistent recovery points are generated every five minutes. App-consistent recovery points are generated according to the setting specified in the replication policy .

Failover process

When you initiate a failover, the VMs are created in the target resource group, target virtual network, target subnet, and in the target availability set. During a failover, you can use any recovery point.

Exercise 82: Enabling Disaster Recovery (DR) for Azure VM using ASR

In this exercise we will enable DR for VMAD in West US 2 Location to East US 2. Azure VM VMAD was created in Exercise 32, Chapter 2.

1. In Azure Portal go to VM VMAD dashboard>click Disaster Recovery in left pane> Configure Disaster Recovery blade opens>For Target Region select region as per your requirement. Here I selected East US 2.

2. Click Next: Advanced settings> Here you can either select system created Resource Group and Virtual Network or Select Pre Created RG and VNET. I selected System Created Resource Group and Virtual Network> I selected System Created Cache Storage Account >In Replication Settings I selected Recovery Service Vault RSVCloud. RSVCloud was created in Exercise 76, Chapter 7> Select default values for Extension settings.

3. Click Next: Review + Start replication. Review the settings and click Start Replication. Deployment starts in the target region. First System created resources are created in target region and then replication starts for VMAD to target region.

4. Go to Recovery Services Vault dashboard and click replicated items. You can see Replication status as protected. I did this step after 45 minutes.

5. Go to System Created Resource Group RGOnPrem-asr Dashboard. You can see VMAD OS disk and System created Virtual Network in East US 2 location.

Exercise 83: Demonstration of Failover of VM VMAD

To Failover single VM or Multiple VMs individually you can go to Replicated Items in Recovery Services Vault dashboard.

To Failover Multiple VMs together you need create Recovery Plans where you can specify order of failover. You can Create Recovery Plans in Recovery Services Vault Dashboard by clicking Recovery Plans in left pane.

1. In Recovery Services Vault RSVCloud click Replicated Items in left pane.

2. In Right pane click Item VMAD>Replicated Item Dashboard opens> From here you can failover VM or Test Failover.

   Note: Disable the replication after the above exercise.

Replication Architecture of VMware VMs or Physical Servers to Azure

Replicate VMs located on-premises VMware hosts managed by vCenter to Azure Storage. vCenter is not compulsory but it is recommended.

Requirements on Azure Side

1. Storage Account: You need an Azure storage account to store replicated data. Azure VMs are created from Replicated data when failover occurs.
2. Virtual Network: You need an Azure virtual network that Azure VMs will connect to when they're created at failover.
3. Recovery Services Vault.

Requirements on-premises side

1. Configuration Server: Coordinates communications between onpremises and Azure and manages data replication.
2. Process server: It receives replication data from VMware Virtual Machines or Physical Servers and optimizes it with caching, compression, and encryption and sends it to Azure Storage. Installed by default on the configuration server.
3. Master target server: It handles replication data during failback from Azure. For large deployments, you can add an additional, separate master target server for failback. Installed by default on the configuration server.
4. Mobilty Service: Mobility Service captures all data writes on VMware virtual machine and Physical Server and sends it to Process Server. Mobility Service is installed on each VMware VM and Physical Server that you replicate.
5. VMware Virtual Machines with Mobility service Installed.
6. VMware ESXi Hosts and vCenter Server: Requires vSphere 6.5, 6.0, or 5.5 and vCenter Server 6.5, 6.0, or 5.5.

Replication Process

VMware Virtual Machines replicate in accordance with the replication policy configured. Initial copy of the VM data is replicated to Azure Storage.

After initial replication finishes, replication of delta changes to Azure Storage begins.

1. VMware Machines send replication data to the process server using the Mobility service agent running on the VM.

2. The process server receives data from source machines, optimizes and encrypts it, and sends it to Azure Storage.

3. The configuration server orchestrates replication management with Azure

Testing Failover process

After replication is set up and you can run a disaster recovery drill (test failover) to check that everything's working as expected.

1. When you run a failover, Azure VMs are created from replicated data in Azure storage.
2. VMs are created in Virtual Network which was specified in Prepared Infrastructure - Target option.
3. You can fail over a single machine or use recovery plans to fail over multiple VMs.

Replication Architecture of Hyper-V VMs Managed by VMM to Azure

You can Replicate VMs located on-premises Hyper-V hosts managed by System Center Virtual Machine Manager (SC VMM) to Azure Storage. You can replicate Hyper-V VMs running any guest operating system supported by Hyper-V and Azure.

Figure below shows the Replication Architecture of Hyper-V VMs Managed by System Center VMM.

Requirements on Azure Side

1. Storage Account: You need an Azure storage account to store replicated data. Azure VMs are created from Replicated data when failover occurs.
2. Virtual Network : You need an Azure virtual network that Azure VMs will connect to when they're created at failover.
3. Recovery Services Vault.

Requirements on-premises side

1. SC VMM: You need one or more on-premises VMM servers running System Center VMM 2012 R2 with Azure Site Recovery Provider Installed.
2. Hyper-V host: You need one or more Windows Server 2016 or Windows Server 2012 R2 Hyper-V host server. During Site Recovery deployment you'll install the Microsoft Azure Recovery Services agent on the host.
3. Azure Site Recovery Provider (Installed on VMM): The Provider coordinates and orchestrates replication with the Site Recovery service over the internet.
4. Azure Recovery Service Agent (Installed on Hyper-V host): The agent handles data replication data over HTTPS 443. Communications from both the Provider and the agent are secure and encrypted. Replicated data in Azure storage is also encrypted.

Replication Process

Virtual Machines replicate in accordance with the replication policy configured. Initial copy of the VM Hard disk is replicated to Azure Storage.

After initial replication finishes, replication of delta changes in VM to Azure Storage begins.

1. When initial replication is triggered, a Hyper-V VM snapshot is taken.
2. Azure Recovery Service Agent replicates Virtual hard disks of the VM one by one, until they're all copied to Azure.
3. When the initial replication finishes, the VM snapshot is deleted
4. After the initial replication, delta replication begins, in accordance with the replication policy.
5. Azure Site Recovery Provider (Installed on VMM) orchestrates replication management with Azure.

Failover and failback process

You can run a planned or unplanned failover from on-premises Hyper-V VMs to Azure. If you run a planned failover, then source VMs are shut down to ensure no data loss. Run an unplanned failover if your primary site isn't accessible.

• You can fail over a single machine, or create recovery plans, to orchestrate failover of multiple machines.
• You run a failover. After the first stage of failover completes, you should be able to see the created replica VMs in Azure. You can assign a public IP address to the VM if required.
• You then commit the failover, to start accessing the workload from the replica Azure VM.

Replication Architecture of Hyper-V VMs to Azure

You can Replicate VMs located on-premises Hyper-V hosts to Azure Storage. You can replicate Hyper-V VMs running any guest operating system supported by Hyper-V and Azure.

Figure below shows the Replication Architecture of Hyper-V VMs to Azure Cloud.

Requirements on Azure Side

1. Storage Account: You need an Azure storage account to store replicated data. Azure VMs are created from Replicated data when failover occurs
2. Virtual Network: You need an Azure virtual network that Azure VMs will connect to when they're created at failover.
3. Recovery Services Vault.

Requirements on-premises side

1. Hyper-V host: You need one or more Windows Server 2016 or Windows Server 2012 R2 Hyper-V host server. Azure Recovery Services agent and Azure Site Recovery Provider will be installed on Hyper-V host.
2. Azure Site Recovery Provider (Installed on Hyper-V host): The Provider coordinates and orchestrates replication with the Site Recovery service over the internet.
3. Azure Recovery Service Agent (Installed on Hyper-V host): The agent handles data replication data over HTTPS 443. Communications from both the Provider and the agent are secure and encrypted. Replicated data in Azure storage is also encrypted.

Replication Process

Virtual Machines replicate in accordance with the replication policy configured. Initial copy of the VM Hard disk is replicated to Azure Storage.

After initial replication finishes, replication of delta changes in VM to Azure Storage begins.

• When initial replication is triggered, a Hyper-V VM snapshot is taken.
• Azure Recovery Service Agent replicates Virtual hard disks of the VM one by one, until they're all copied to Azure.
• When the initial replication finishes, the VM snapshot is deleted.
• After the initial replication, delta replication begins, in accordance with the replication policy.
• Azure Site Recovery Provider (Installed on Hyper-V host) orchestrates replication management with Azure.

Failover and failback process

You can run a planned or unplanned failover from on-premises Hyper-V VMs to Azure. If you run a planned failover, then source VMs are shut down to ensure no data loss. Run an unplanned failover if your primary site isn't accessible.

1. You can fail over a single machine, or create recovery plans, to orchestrate failover of multiple machines.
2. You run a failover. After the first stage of failover completes, you should be able to see the created replica VMs in Azure. You can assign a public IP address to the VM if required.
3. You then commit the failover, to start accessing the workload from the replica Azure VM.

Replication Architecture of Hyper-V VMs Managed by SC VMM to Secondary Data Center

You can Replicate VMs located on-premises Hyper-V hosts managed by System Center Virtual Machine Manager (SC VMM) to secondary data center.

Figure below shows the Replication Architecture of Hyper-V VMs managed by VMM to Secondary Data Center.

Requirements on Azure Side

1. Recovery Services Vault.

Requirements on-premises side

VMM Server: You need VMM server in both primary and secondary location.

Hyper-V host: You need one or more Hyper-V host server (Windows Server 2016 or 2012 R2) in both primary and secondary Datacenter. Azure Site Recovery Provider will be installed on Hyper-V host.

Azure Site Recovery Provider (Installed on VMM Server): The Provider coordinates and orchestrates replication with the Site Recovery service over the internet.

Azure Site Recovery Pricing

Azure Site Recovery is billed based on number of instances protected.

If you are replicating VMs to Azure, then you also will be charged for consumed storage and storage transactions.

If a failover occurred and protected VMs in Azure become active, then you also will be charged for consumed Compute resources.