Replicate VMware virtual machines to Azure with Site Recovery

Replicate VMware virtual machines to Azure with Site Recovery 

This article describes how to replicate on-premises VMware virtual machines to Azure, using the Azure Site Recovery service in the Azure portal. This was a real life Customer migrate VMware VMs to Azure.

Hihg Level Deployment steps 

• prerequisites and limitations. 
• network and storage accounts. 
• Prepare the on-premises infrastructure for deploy (configuration server). 
• Prepare VMware accounts to be used for automatic discovery of VMs, and optionally for push installation of the Mobility service. 
• Create a Recovery Services vault. 
• Specify source, target, and replication settings.
• Deploy the Mobility service on VMs you want to replicate. 
• Enable replication for the VMs.

Prerequisites

https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-vmware-to-azure#prerequisites

Limitations

https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-vmware-to-azure#limitations

Prepare the configuration server

• Install Windows Server 2012 R2 or later, on a VMware VM. 
• Make sure the VM has access to the URLs listed in prerequisites. 
• Install VMware vSphere PowerCLI 6.0

Prepare for automatic discovery and push installation

• Prepare an account for auto-discovery: The Site Recovery process server automatically discovers VMs. To do this, Site Recovery needs credentials that can access vCenter servers and vSphere ESXi hosts. 

1. To use a dedicated account, create a role (at the vCenter level, with these permissions. Give it a name such as Azure_Site_Recovery. 

2. Then, create a user on the vSphere host/vCenter server, and assign the role to the user. You specify this user account during Site Recovery deployment.

 Prepare an account to push the Mobility service: If you want to push the Mobility service to VMs, you need an account that can be used by the process server to access the VM. The account is only used for the push installation. You can use a domain or local account: 

 1. For Windows, if you're not using a domain account, you need to disable Remote User Access control on the local machine. 

2. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System, add the DWORD entry LocalAccountTokenFilterPolicy, with a value of 1. o If you want to add the registry entry for Windows from a CLI, type:REG ADD HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1. 

3.For Linux, the account should be root on the source Linux server.

Create a Recovery Services vault

Sign in to the Azure portal > Site Recovery 

Click New > Monitoring >Management > Backup and Site Recovery

In Name, specify a friendly name to identify the vault. If you have more than one subscription, select one of them.

Create a resource group, or select an existing one.

and then click Create.

Select the protection goal

Select what you want to replicate, and where you want to replicate to.

Click Recovery Services vaults > vault. 

In the Resource Menu, click Site Recovery > Step 1: Prepare Infrastructure > Protection goal.

In Protection goal, select To Azure > Yes, with VMware vSphere Hypervisor.

Set up the source Environment

Set up the configuration server, register it in the vault, and discover VMs. 

Click Site Recovery > Step 1: Prepare Infrastructure > Source. 

To add the  configuration server, click +Configuration server.

In Add Server, check that Configuration Server appears in Server type.

Download the Site Recovery Unified Setup installation file. 

Download the vault registration key. You need this when you run Unified Setup. The key is valid for five days after you generate it

Run Site Recovery Unified Setup

Do the following before you start, then run Unified Setup to install the configuration server, the process server, and the master target server. 

Run the Unified Setup installation file. 

In Before you begin, select Install the configuration server and process server.

In Third Party Software License, click I Accept to download and install MySQL.

In Registration, select the registration key you downloaded from the vault

In Internet Settings, specify how the Provider running on the configuration server connects to Azure Site Recovery over the Internet. 

•  If you want to connect with the proxy that's currently set up on the machine, select Connect   with existing proxy settings. 
• If you want the Provider to connect directly, select Connect directly without a proxy. 
• If the existing proxy requires authentication, or if you want to use a custom proxy for the Provider connection, select Connect with custom proxy settings. 

1. If you use a custom proxy, you need to specify the address, port, and credentials. 
2. If you're using a proxy, you should have already allowed the URLs described in prerequisites.

In Prerequisites Check, Setup runs a check to make sure that installation can run

In MySQL Configuration, create credentials for logging on to the MySQL server instance that is installed.

In Environment Details, select whether you're going to replicate VMware VMs. If you are, then setup checks that PowerCLI 6.0 is installed.

In Install Location, select where you want to install the binaries and store the cache.

In Network Selection, specify the listener (network adapter and SSL port) on which the configuration server sends and receives replication data. Port 9443 is the default port used for sending and receiving replication traffic, but you can modify this port number to suit your environment's requirements.

In Summary, review the information and click Install. When installation finishes, a passphrase is generated. You will need this when you enable replication, so copy it and keep it in a secure location.

After registration finishes, the server is displayed on the Settings > Servers blade in the vault.

Add the account for automatic discovery 

1. On your configuration server, launch CSPSConfigtool.exe. It is available as a shortcut on the desktop and located in the install location\home\svsystems\bin folder. 

2. Click Manage Accounts > Add Account.

In Account Details, add the account that will be used for automatic discovery.

Connect to VMware servers

Select +vCenter to start connecting a VMware vCenter server or a VMware vSphere ESXi host.

• In Add vCenter, specify a friendly name for the vSphere host or vCenter server, and then specify the IP address or FQDN of the server. Leave the port as 443 unless your VMware servers are configured to listen for requests on a different port. Select the account that is to connect to the VMware vCenter or vSphere ESXi server. Click OK.

Set up the target

• Click Prepare infrastructure > Target, and select the Azure subscription you want to use.

• Specify whether your target deployment model is Resource Manager-based, or classic. 

• Site Recovery checks that you have one or more compatible Azure storage accounts and networks.

If you haven't created a storage account or network, click +Storage account or +Network, to create a Resource Manager account or network inline.

Set up replication settings

• Click Site Recovery infrastructure > Replication Policies > +Replication Policy. 
• In Create replication policy, specify a policy name. 
• In RPO threshold, specify the RPO limit. 
• In Recovery point retention, specify (in hours) how long the retention window is for each recovery point. Replicated VMs can be recovered to any point in a window. Up to 24 hours retention is supported for machines replicated to premium storage, and 72 hours for standard storage. 
• In App-consistent snapshot frequency, specify how often (in minutes) recovery points containing application-consistent snapshots will be created. 
• Click OK to create the policy.

Note: When you create a new policy it's automatically associated with the configuration server. By default, a matching policy is automatically created for failback. For example, if the replication policy is rep-policy then the failback policy will be rep-policy-failback. This policy isn't used until you initiate a failback from Azure.

Plan capacity

1. Now that you have your basic infrastructure set up you can think about capacity planning, and    figure out whether you need additional resources.

2. When you’re done with capacity planning, select Yes in Have you completed capacity planning?

Click Ok to Complete the Prepare Infrastructure

Prepare VMs for replication

The Mobility service must be installed on all VMware VMs that you want to replicate. You can install the Mobility service in a number of ways: 

1. Install with a push installation from the process server. You need to prepare VMs to use this method. 

2. Install using deployment tools such as System Center Configuration Manager, or Azure automation DSC.

3. Install manually. Enable replication.

Replicate VMs

• Click Step 2: Replicate application > Source. 
• In Source, select the configuration server. 
• In Machine type, select Virtual Machines. 
• In vCenter/vSphere Hypervisor, select the vCenter server that manages the vSphere host, or select the host. 
• Select the process server. If you haven't created any additional process servers this will be the configuration server. Then click OK.

• In Target, select the subscription and the resource group in which you want to create the failed over VMs. Choose the deployment model that you want to use in Azure (classic or resource management), for the failed over VMs.
• Select the Azure storage account you want to use for replicating data. If you don't want to use an account you've already set up, you can create a new one. 
• Select the Azure network and subnet to which Azure VMs will connect, when they're created after failover. Select Configure now for selected machines, to apply the network setting to all machines you select for protection. Select Configure later to select the Azure network per machine. If you don't want to use an existing network, you can create one.

In Virtual Machines > Select virtual machines, click and select each machine you want to replicate. You can only select machines for which replication can be enabled. Then click OK.

(final image from Microsoft Site)

In Properties > Configure properties, select the account that will be used by the process server to automatically install the Mobility service on the machine. 

By default all disks are replicated. Click All Disks and clear any disks you don't want to replicate. Then click OK.

• In Replication settings > Configure replication settings, verify that the correct replication policy is selected. If you modify a policy, changes will be applied to replicating machine, and to new machines. 
• Enable Multi-VM consistency if you want to gather machines into a replication group, and specify a name for the group. Then click OK.

Note: 

• Machines in replication groups replicate together, and have shared crash-consistent and app-consistent recovery points when they fail over. 
• I recommend that you gather VMs and physical servers together so that they mirror your workloads. Enabling multi-VM consistency can impact workload performance, and should only be used if machines are running the same workload and you need consistency.

Click Enable Replication. You can track progress of the Enable Protection job in Settings > Jobs > Site Recovery Jobs. After the Finalize Protection job runs the machine is ready for failover.

After you enable replication, the Mobility service will be installed if you set up push installation. After the Mobility service is push installed on a VM, a protection job will start and fail. After the failure you need to manually restart each machine. Then the protection job begins again, and initial replication occurs.

View and manage VM properties

Click Replicated items >, and select the machine. The Essentials blade shows information about machines settings and status.

In Properties, you can view replication and failover information for the VM. 

In Compute and Network > Compute properties, you can specify the Azure VM name and target size. Modify the name to comply with Azure requirements if you need to. 

Azure Site Recovery support matrix for replicating to Azure

Azure Site Recovery support matrix for replicating to Azure

Reference Link : https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-support-matrix-to-azure#support-for-replicated-machine-os-versions

 

All About Azure Storage replication

All About Azure Storage replication

 

The data in your Microsoft Azure storage account is always replicated to ensure durability and high availability. Replication copies your data, either within the same data center, or to a second data center, depending on which replication option you choose. Replication protects your data and preserves your application up-time in the event of transient hardware failures. If your data is replicated to a second data center, that also protects your data against a catastrophic failure in the primary location.

Replication ensures that your storage account meets the Service-Level Agreement (SLA) for Storage even in the face of failures. See the SLA for information about Azure Storage guarantees for durability and availability.

When you create a storage account, you can select one of the following replication options:

·        Locally redundant storage (LRS)

·        Zone-redundant storage (ZRS)

·        Geo-redundant storage (GRS)

·        Read-access geo-redundant storage (RA-GRS)

Read-access geo-redundant storage (RA-GRS) is the default option when you create a new storage account.

The following table provides a quick overview of the differences between

Replication strategy LRS ZRS GRS RA-GRS           Data is replicated across multiple datacenters. No Yes Yes Yes Data can be read from the secondary location as well as from the primary location. No No No Yes Number of copies of data maintained on separate nodes. 3 3 6 6

Locally redundant storage

Locally redundant storage (LRS) replicates your data three times within a storage scale unit which is hosted in a datacenter in the region in which you created your storage account. A write request returns successfully only once it has been written to all three replicas. These three replicas each reside in separate fault domains and upgrade domains within one storage scale unit.

A storage scale unit is a collection of racks of storage nodes. A fault domain (FD) is a group of nodes that represent a physical unit of failure and can be considered as nodes belonging to the same physical rack. An upgrade domain (UD) is a group of nodes that are upgraded together during the process of a service upgrade (rollout). The three replicas are spread across UDs and FDs within one storage scale unit to ensure that data is available even if hardware failure impacts a single rack or when nodes are upgraded during a rollout.

LRS is the lowest cost option and offers least durability compared to other options. In the event of a datacenter level disaster (fire, flooding etc.) all three replicas might be lost or unrecoverable. To mitigate this risk Geo Redundant Storage (GRS) is recommended for most applications.

Locally redundant storage may still be desirable in certain scenarios:

·        Provides highest maximum bandwidth of Azure Storage replication options.

·        If your application stores data that can be easily reconstructed, you may opt for LRS.

·        Some applications are restricted to replicating data only within a country due to data governance requirements. A paired region could be in another country; please see Azure regions for information on region pairs.

 Zone-redundant storage

Zone-redundant storage (ZRS) replicates your data asynchronously across datacenters within one or two regions in addition to storing three replicas similar to LRS, thus providing higher durability than LRS. Data stored in ZRS is durable even if the primary datacenter is unavailable or unrecoverable. Customers who plan to use ZRS should be aware that:+

·        ZRS is only available for block blobs in general purpose storage accounts, and is supported only in storage service versions 2014-02-14 and later.

·        Since asynchronous replication involves a delay, in the event of a local disaster it is possible that changes that have not yet been replicated to the secondary will be lost if the data cannot be recovered from the primary.

·        The replica may not be available until Microsoft initiates failover to the secondary.

·        ZRS accounts cannot be converted later to LRS or GRS. Similarly, an existing LRS or GRS account cannot be converted to a ZRS account.

·        ZRS accounts do not have metrics or logging capability.

Geo-redundant storage

Geo-redundant storage (GRS) replicates your data to a secondary region that is hundreds of miles away from the primary region. If your storage account has GRS enabled, then your data is durable even in the case of a complete regional outage or a disaster in which the primary region is not recoverable.

For a storage account with GRS enabled, an update is first committed to the primary region, where it is replicated three times. Then the update is replicated asynchronously to the secondary region, where it is also replicated three times. With GRS, both the primary and secondary regions manage replicas across separate fault domains and upgrade domains within a storage scale unit as described with LRS.

Considerations:

·        Since asynchronous replication involves a delay, in the event of a regional disaster it is possible that changes that have not yet been replicated to the secondary region will be lost if the data cannot be recovered from the primary region.

·        The replica is not available unless Microsoft initiates failover to the secondary region. If Microsoft does initiate a failover to the secondary region, you will have read and write access to that data after the failover has completed. For more information, please see Disaster Recovery Guidance.

·        If an application wants to read from the secondary region, the user should enable RA-GRS.

When you create a storage account, you select the primary region for the account. The secondary region is determined based on the primary region, and cannot be changed. The following table shows the primary and secondary region pairings.

Primary	Secondary
North Central US	South Central US
South Central US	North Central US
East US	West US
West US	East US
US East 2	Central US
Central US	US East 2
North Europe	West Europe
West Europe	North Europe
South East Asia	East Asia
East Asia	South East Asia
East China	North China
North China	East China
Japan East	Japan West
Japan West	Japan East
Brazil South	South Central US
Australia East	Australia Southeast
Australia Southeast	Australia East
India South	India Central
India Central	India South
US Gov Iowa	US Gov Virginia
US Gov Virginia	US Gov Iowa
Canada Central	Canada East
Canada East	Canada Central
UK West	UK South
UK South	UK West
Germany Central	Germany Northeast
Germany Northeast	Germany Central
West US 2	West Central US
West Central US	West US 2

For up-to-date information about regions supported by Azure, see Azure Regions.

 

Read-access geo-redundant storage

Read-access geo-redundant storage (RA-GRS) maximizes availability for your storage account, by providing read-only access to the data in the secondary location, in addition to the replication across two regions provided by GRS.

When you enable read-only access to your data in the secondary region, your data is available on a secondary endpoint, in addition to the primary endpoint for your storage account. The secondary endpoint is similar to the primary endpoint, but appends the suffix –secondary to the account name. For example, if your primary endpoint for the Blob service is myaccount.blob.core.windows.net, then your secondary endpoint is myaccount-secondary.blob.core.windows.net. The access keys for your storage account are the same for both the primary and secondary endpoints.

Considerations:

·        Your application has to manage which endpoint it is interacting with when using RA-GRS.

·        Since asynchronous replication involves a delay, in the event of a regional disaster it is possible that changes that have not yet been replicated to the secondary region will be lost if the data cannot be recovered from the primary region.

·        If Microsoft initiates failover to the secondary region, you will have read and write access to that data after the failover has completed. For more information, please see Disaster Recovery Guidance.

·        RA-GRS is intended for high-availability purposes. For scalability guidance, please review the performance checklist.

Premium Storage

·        Premium Storage supports only locally redundant storage (LRS). For information about Premium Storage, see Premium Storage: High-Performance Storage for Azure Virtual Machine Workloads.