Azure to Azure disaster recovery architecture

This article describes the architecture, components, and processes used when you deploy disaster recovery for Azure virtual machines (VMs) using the Azure Site Recovery service. With disaster recovery setup, Azure VMs continuously replicate to a different target region. If an outage occurs, you can fail over VMs to the secondary region, and access them from there. When everything's running normally again, you can fail back and continue working in the primary location.

Architectural components

The components involved in disaster recovery for Azure VMs are summarized in the following table.

Target resources

When you enable replication for a VM, Site Recovery gives you the option of creating target resources automatically.

Managing target resources

You can manage target resources as follows:

• You can modify target settings as you enable replication. Note that the default SKU for the target region VM is the same as the SKU of the source VM (or the next best available SKU in comparison to the source VM SKU). The dropdown list only shows relevant SKUs of the same family as the source VM (Gen 1 or Gen 2).
• You can modify target settings after replication is already working. Similar to other resources such as the target resource group, target name, and others, the target region VM SKU can also be updated after replication is in progress. A resource, which can't be updated is the availability type (single instance, set, or zone). To change this setting, you need to disable replication, modify the setting, and then reenable.

Replication policy

When you enable Azure VM replication, Site Recovery creates a new replication policy with the default settings summarized in the table, by default.

Managing replication policies

You can manage and modify the settings of default replication policies as follows:

• You can modify the settings as you enable replication.
• You can create a replication policy at any time, and then apply it when you enable replication.

Multi-VM consistency

If you want VMs to replicate together, and have shared crash-consistent and app-consistent recovery points at failover, you can gather them together into a replication group. Multi-VM consistency impacts workload performance, and should only be used for VMs running workloads that need consistency across all machines.

Snapshots and recovery points

Recovery points are created from snapshots of VM disks taken at a specific point in time. When you fail over a VM, you use a recovery point to restore the VM in the target location.

When failing over, we generally want to ensure that the VM starts with no corruption or data loss, and that the VM data is consistent for the operating system, and for apps that run on the VM. This depends on the type of snapshots taken.

Site Recovery takes snapshots as follows:

1. Site Recovery takes crash-consistent snapshots of data by default, and app-consistent snapshots if you specify a frequency for them.
2. Recovery points are created from the snapshots, and stored in accordance with retention settings in the replication policy.

Consistency

The following table explains different types of consistency.

Crash-consistent

App-consistent

Replication process

When you enable replication for an Azure VM, the following happens:

1. The Site Recovery Mobility service extension is automatically installed on the VM.
2. The extension registers the VM with Site Recovery.
3. Continuous replication begins for the VM. Disk writes are immediately transferred to the cache storage account in the source location.
4. Site Recovery processes the data in the cache, and sends it to the target storage account, or to the replica managed disks.
5. 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.

Replication process

Connectivity requirements

The Azure VMs you replicate need outbound connectivity. Site Recovery never needs inbound connectivity to the VM.

Outbound connectivity (URLs)

If outbound access for VMs is controlled with URLs, allow these URLs.

Outbound connectivity for IP address ranges

To control outbound connectivity for VMs using IP addresses, allow these addresses. Note that details of network connectivity requirements can be found in networking white paper.

Source region rules

Target region rules

Control access with Network Security Group rules

If you control VM connectivity by filtering network traffic to and from Azure networks/subnets using Network Security Group rules, note the following requirements:

• Network Security Group rules for the source Azure region should allow outbound access for replication traffic.
• We recommend you create rules in a test environment before you put them into production.
• Use service tags instead of allowing individual IP addresses.
  • Service tags represent a group of IP address prefixes gathered together to minimize complexity when creating security rules.
  • Microsoft automatically updates service tags over time.

Learn more about outbound connectivity for Site Recovery, and controlling connectivity with Network Security Groups.

Connectivity for multi-VM consistency

If you enable multi-VM consistency, machines in the replication group communicate with each other over port 20004.

• Ensure that there's no firewall appliance blocking the internal communication between the VMs over port 20004.
• If you want Linux VMs to be part of a replication group, ensure the outbound traffic on port 20004 is manually opened as per the guidance of the specific Linux version.

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.

Next steps

• Quickly replicate an Azure VM to a secondary region.