Prerequisites for replication from on-premises to Azure by using Site Recovery

Azure Site Recovery can help you support your business continuity and disaster recovery (BCDR) strategy by orchestrating replication of an Azure virtual machine (VM) to another Azure region. Site Recovery also replicates on-premises physical servers and VMs to the cloud (Azure), or to a secondary datacenter. If an outage occurs at your primary location, you can fail over to a secondary location to keep apps and workloads available. You can fail back to your primary location when the primary location returns to normal operations. For more information about Site Recovery, see What is Site Recovery?.

In this article, we summarize the prerequisites for beginning Site Recovery replication from an on-premises machine to Azure.

You can post any comments at the bottom of the article. You also can ask technical questions in the Azure Recovery Services forum.

Azure requirements

Requirement Details
Azure account A Microsoft Azure account. You can start with a free trial.
Site Recovery service For more information about pricing for the Azure Site Recovery service, see Site Recovery pricing.
Azure Storage You need an Azure Storage account to store replicated data. The storage account must be in the same region as the Azure Recovery Services vault. Azure VMs are created when failover occurs.

Depending on the resource model you want to use for Azure VM failover, you can set up an account by using the Azure Resource Manager deployment model or the classic deployment model.

You can use geo-redundant storage or locally redundant storage. We recommend geo-redundant storage. With geo-redundant storage, data is resilient if a regional outage occurs, or if the primary region can't be recovered.

You can use a standard Azure storage account, or you can use Azure Premium Storage. Premium storage typically is used for VMs that need a consistently high I/O performance and low latency. With premium storage, a VM can host I/O-intensive workloads. If you use premium storage for replicated data, you also need a standard storage account. A standard storage account stores replication logs that capture ongoing changes to on-premises data.

Storage limitations You can't move storage accounts that you use in Site Recovery to a different resource group, or move to or use with another subscription.

Currently, replicating to premium storage accounts in Central India and South India isn't available.
Azure network You need an Azure network, to which Azure VMs connect after failover. The Azure network must be in the same region as the Recovery Services vault.

In the Azure portal, you can create an Azure network by using the Resource Manager deployment model or the classic deployment model.

If you replicate from System Center Virtual Machine Manager (VMM) to Azure, you must set up network mapping between VMM VM networks and Azure networks. This ensures that Azure VMs connect to appropriate networks after failover.
Network limitations You can't move network accounts that you use in Site Recovery to a different resource group, or move to or use with another subscription.
Network mapping If you replicate Microsoft Hyper-V VMs in VMM clouds, you must set up network mapping. This ensures that Azure VMs connect to appropriate networks when they're created after failover.
Note

The following sections describe the prerequisites for various components of the customer environment. For more information about support for specific configurations, see the support matrix.

Disaster recovery of VMware VMs or physical Windows or Linux servers to Azure

The following components are required for disaster recovery of VMware VMs or physical Windows or Linux servers. These are in addition to the ones described in Azure requirements.

Configuration server or additional process server

Set up an on-premises machine as the configuration server to orchestrate communication between the on-premises site and Azure. The below table talks about the system and software requirements of a virtual machine that can be configured as a configuration server.

Important

When deploying a Configuration Server for protecting VMware virtual machines, we recommend that you deploy it as a Highly Available (HA) virtual machine.

Hardware
Number of CPU cores 8
RAM 12 GB
Number of disks 3

- OS disk
- Process server cache disk
- Retention drive (for failback)
Disk free space (process server cache) 600 GB
Disk free space (retention disk) 600 GB
Software
Operating system version Windows Server 2012 R2
Operating system locale English (en-us)
VMware vSphere PowerCLI version PowerCLI 6.0
Windows Server roles Do not enable the following roles:
- Active Directory Domain Services
- Internet Information Services
- Hyper-V
Network
Network interface card type VMXNET3
IP address type Static
Internet access The server should be able to access the following URLs either directly or through a proxy server:
- *.accesscontrol.windows.net
- *.backup.windowsazure.com
- *.store.core.windows.net
- *.blob.core.windows.net
- *.hypervrecoverymanager.windowsazure.com
- https://cdn.mysql.com/archives/mysql-5.5/mysql-5.5.37-win32.msi (not required for Scale-out Process Servers)
- time.nist.gov
- time.windows.com
Ports 443 (Control channel orchestration)
9443 (Data transport)

VMware vCenter or vSphere host prerequisites

Component Requirements
vSphere You must have one or more VMware vSphere hypervisors.

Hypervisors must be running vSphere version 6.0, 5.5, or 5.1, with the latest updates.

We recommend that vSphere hosts and vCenter servers both be in the same network as the process server. Unless you’ve set up a dedicated process server, this is the network where the configuration server is located.
vCenter We recommend that you deploy a VMware vCenter server to manage your vSphere hosts. It must be running vCenter version 6.0 or 5.5, with the latest updates.

Limitation: Site Recovery does not support replication between instances of vCenter vMotion. Storage DRS and Storage vMotion also are not supported on a master target VM after a reprotect operation.

Replicated machine prerequisites

Component Requirements
On-premises machines (VMware VMs) Replicated VMs must have VMware tools installed and running.

VMs must meet Azure prerequisites for creating an Azure VM.

Disk capacity on each protected machine can't be more than 1,023 GB.

A minimum 2 GB of available space on the installation drive is required for component installation.

If you want to enable multi-VM consistency, port 20004 must be opened on the VM local firewall.

Machine names must be between 1 and 63 characters long (you can use letters, numbers, and hyphens). The name must start with a letter or number, and end with a letter or number.

After you've enabled replication for a machine, you can modify the Azure name.

Windows machines (physical or VMware) The machine must be running one of the following supported 64-bit operating systems:
- Windows Server 2012 R2
- Windows Server 2012
- Windows Server 2008 R2 with SP1 or a later version

The operating system must be installed on drive C. The OS disk must be a Windows basic disk, and not dynamic. The data disk can be dynamic.

Linux machines (physical or VMware) The machine must be running one of the following supported 64-bit operating systems:
- Red Hat Enterprise Linux 5.2 to 5.11, 6.1 to 6.9, 7.0 to 7.3
- CentOS 5.2 to 5.11, 6.1 to 6.9, 7.0 to 7.3
- Ubuntu 14.04 LTS server (for a list of supported kernel versions for Ubuntu, see supported operating systems)
- Ubuntu 16.04 LTS server (for a list of supported kernel versions for Ubuntu, see supported operating systems)
- Debian 7 or Debian 8
- Oracle Enterprise Linux 6.5 or 6.4, running either the Red Hat-compatible kernel or Unbreakable Enterprise Kernel Release 3 (UEK3)
- SUSE Linux Enterprise Server 11 SP4 or SUSE Linux Enterprise Server 11 SP3

Your /etc/hosts files on protected machines must have entries that map the local host name to IP addresses associated with all network adapters.

After failover, if you want to connect to an Azure VM that's running Linux by using a Secure Shell (SSH) client, ensure that the SSH service on the protected machine is set to start automatically on system start. Ensure also that firewall rules allow an SSH connection to the protected machine.

The host name, mount points, device names, and Linux system paths and file names (for example, /etc/ and /usr) must be in English only.

The following directories (if set up as separate partitions or file systems) must all be on the same disk (the OS disk) on the source server:
- / (root)
- /boot
- /usr
- /usr/local
- /var
- /etc

Currently, XFS v5 features, like metadata checksum, are not supported by Site Recovery on XFS file systems. Ensure that your XFS file systems aren't using any v5 features. You can use the xfs_info utility to check the XFS superblock for the partition. If ftype is set to 1, XFS v5 features are being used.

On Red Hat Enterprise Linux 7 and CentOS 7 servers, the lsof utility must be installed and available.

Disaster recovery of Hyper-V VMs to Azure (no VMM)

The following components are required for disaster recovery of Hyper-V VMs in VMM clouds. These are in addition to the ones described in Azure requirements.

Prerequisite Details
Hyper-V host One or more on-premises servers must be running Windows Server 2012 R2 with the latest updates and the Hyper-V role enabled, or Microsoft Hyper-V Server 2012 R2.

Hyper-V servers must have one or more VMs.

Hyper-V servers must be connected to the Internet, either directly or via a proxy.

Hyper-V servers must have the fixes described in the Knowledge Base article 2961977 installed.
Provider and agent During Site Recovery deployment, you install the Azure Site Recovery provider. The provider installation also installs the Azure Recovery Services agent on each Hyper-V server that's running VMs that you want to protect.

All Hyper-V servers in a Site Recovery vault must have the same versions of the provider and the agent.

The provider needs to connect to Site Recovery over the Internet. Traffic can be sent directly or through a proxy. HTTPS-based proxy is not supported. The proxy server must allow access to the following URLs:

*.accesscontrol.windows.net. Used for access control and identity management.

\*.backup.windowsazure.com. Used for replication data transfer and coordination.

\*.blob.core.windows.net. Used for access to the storage account that stores replicated data.

\*.hypervrecoverymanager.windowsazure.com. Used for replication management operations and coordination.

time.nist.gov and time.windows.com. Used to check time synchronization between system and global time.

URLs for the Azure Government cloud:
- .ugv.hypervrecoverymanager.windowsazure.us
- .ugv.backup.windowsazure.us
- .ugi.hypervrecoverymanager.windowsazure.us
- .ugi.backup.windowsazure.us

If you have IP address-based firewall rules on the server, ensure that the rules allow communication to Azure.

Allow the Azure datacenter IP ranges, and HTTPS (port 443).

Allow IP address ranges for the Azure region of your subscription, and for the Western US (used for access control and identity management).

Disaster recovery of Hyper-V VMs in VMM clouds to Azure

The following components are required for disaster recovery of Hyper-V VMs in VMM clouds. These are in addition to the ones described in Azure requirements.

Prerequisite Details
Virtual Machine Manager You must have one or more VMM servers running on System Center 2012 R2 or a later version. Each VMM server must have one or more clouds configured.

A cloud must have:
- One or more VMM host groups.
- One or more Hyper-V host servers or clusters in each host group.

For more information about setting up VMM clouds, see How to create a cloud in Virtual Machine Manager 2012.
Hyper-V Hyper-V host servers must be running at least Windows Server 2012 R2 with the Hyper-V role enabled, or Microsoft Hyper-V Server 2012 R2. The latest updates must be installed.

A Hyper-V server must have one or more VMs.

A Hyper-V host server or cluster that includes VMs that you want to replicate must be managed in a VMM cloud.

Hyper-V servers must be connected to the Internet, either directly or via a proxy.

Hyper-V servers must have the fixes described in the Knowledge Base article 2961977 installed.

Hyper-V host servers need Internet access for data replication to Azure.
Provider and agent During Azure Site Recovery deployment, install Azure Site Recovery Provider on the VMM server. Install Recovery Services Agent on Hyper-V hosts. The provider and agent need to connect to Azure directly over the Internet or through a proxy. An HTTPS-based proxy isn't supported. The proxy server on the VMM server and Hyper-V hosts must allow access to:

*.accesscontrol.windows.net. Used for access control and identity management.

\*.backup.windowsazure.com. Used for replication data transfer and coordination.

\*.blob.core.windows.net. Used for access to the storage account that stores replicated data.

\*.hypervrecoverymanager.windowsazure.com. Used for replication management operations and coordination.

time.nist.gov and time.windows.com. Used to check time synchronization between system and global time.

URLs for the Azure Government cloud:
- .ugv.hypervrecoverymanager.windowsazure.us
- .ugv.backup.windowsazure.us
- .ugi.hypervrecoverymanager.windowsazure.us
- .ugi.backup.windowsazure.us

If you have IP address-based firewall rules on the VMM server, ensure that the rules allow communication to Azure.

Allow the Azure datacenter IP ranges and HTTPS (port 443).

Allow IP address ranges for the Azure region for your subscription, and for the Western US (used for access control and identity management).

Replicated machine prerequisites

Component Details
Protected VMs Site Recovery supports all operating systems that are supported by Azure.

VMs must meet the Azure prerequisites for creating an Azure VM. Machine names must be between 1 and 63 characters long (you can use letters, numbers, and hyphens). The name must start with a letter or number, and end with a letter or number.

You can modify the VM name after you've enabled replication for the VM.

Disk capacity for each protected machine can't be more than 1,023 GB. A VM can have up to 16 disks (up to 16 TB).

Disaster recovery of Hyper-V VMs in VMM clouds to a customer-owned site

The following components are required for disaster recovery of Hyper-V VMs in VMM clouds to a customer-owned site. These are in addition to the ones described in Azure requirements.

Component Details
Virtual Machine Manager We recommend that you deploy a VMM server on both the primary site and the secondary site.

You can replicate between clouds on a single VMM server. To replicate between clouds on a single VMM server, you need at least two clouds configured on the VMM server.

VMM servers must be running at least System Center 2012 SP1, with the latest updates.

Each VMM server must have one or more clouds. All clouds must have the Hyper-V Capacity Profile set.

Clouds must have one or more VMM host groups. For more information about setting up VMM clouds, see Prepare for Azure Site Recovery deployment.
Hyper-V Hyper-V servers must be running at least Windows Server 2012 with the Hyper-V role enabled, and have the latest updates installed.

A Hyper-V server must have one or more VMs.

Hyper-V host servers must be located in host groups in the primary and secondary VMM clouds.

If you run Hyper-V in a cluster on Windows Server 2012 R2, we recommend that you install the update described in Knowledge Base article 2961977.

If you run Hyper-V in a cluster on Windows Server 2012 and have a static IP address-based cluster, a cluster broker isn't automatically created. You must manually configure the cluster broker. For more information about the cluster broker, see Configure the replica broker role for cluster-to-cluster replication.
Provider During Site Recovery deployment, install the Azure Site Recovery provider on VMM servers. The provider communicates with Site Recovery over HTTPS (port 443) to orchestrate replication. Data replication occurs between the primary and secondary Hyper-V servers over the LAN or through a VPN connection.

The provider that's running on the VMM server needs access to the following URLs:

*.accesscontrol.windows.net. Used for access control and identity management.

\*.backup.windowsazure.com. Used for replication data transfer and coordination.

\*.blob.core.windows.net. Used for access to the storage account that stores replicated data.

\*.hypervrecoverymanager.windowsazure.com. Used for replication management operations and coordination.

time.nist.gov and time.windows.com. Used to check time synchronization between system and global time.

URLs for the Azure Government cloud:
- .ugv.hypervrecoverymanager.windowsazure.us
- .ugv.backup.windowsazure.us
- .ugi.hypervrecoverymanager.windowsazure.us
- .ugi.backup.windowsazure.us

The Site Recovery provider must allow firewall communication from the VMM servers to the Azure datacenter IP ranges, and allow the HTTPS (port 443) protocol.

URL access

These URLs must be available from VMware, VMM, and Hyper-V host servers:

URL VMM to VMM VMM to Azure Hyper-V to Azure VMware to Azure
*.accesscontrol.windows.net Allow Allow Allow Allow
*.backup.windowsazure.com Not required Allow Allow Allow
*.hypervrecoverymanager.windowsazure.com Allow Allow Allow Allow
*.store.core.windows.net Allow Allow Allow Allow
*.blob.core.windows.net Not required Allow Allow Allow
https://dev.mysql.com/get/archives/mysql-5.5/mysql-5.5.37-win32.msi Not required Not required Not required Allow for SQL download
time.windows.com Allow Allow Allow Allow
time.nist.gov Allow Allow Allow Allow