Migration paths from VMware to Microsoft Azure (Classic and ARM)

Hi all,

This page describes and presents the different approaches that an enterprise can think about when deciding to Migrate workloads from on-premise VMware platform to Azure. This page is a high level description where the different concepts will be explained, and a comparison will be conducted.

NB : This post also includes the possible actions (when applicable) to make in order to migrate the workloads to the Azure Resource Manager stack (IaaS V2)

1- What are the migration paths

There are many migration paths which can be used, but each one have it’s own advantages and disadvantages. The following table shows the different paths that will be discussed in this article:

  • Extend the application roles to Azure
  • Manual upload of the Virtual Machine’s virtual hard disks to Azure
  • Use MVMC (Microsoft Virtual Machine Converter)
  • Use Azure Site Recovery

2- Migration paths description

In this section, the different migration paths presented on 1- What are the migration paths. will be detailed, and the advantages and disadvantages of each one will be presented.

2.1- Extend the application roles to Azure

2.1.1- Description

This this the first path that can be took to migrate workloads to Azure. It depends on the application itself, and it’s not related to the OS underlying stack (Physical, Virtual, VMware or Hyper-V…).

This approach is only possible for application and workloads that supports high Availability or Load Balancing over multiple instances, and usually does not require using third party tools.

Example:

Active Directory Domain Services : If you have one domain controller, you can add an additional domain controller to your topology. This way, users or resources using these DCs can authenticate on either the first or the second DC. The migration path will be the following .

  1. Add a second domain controller on Azure
  2. Verify that users, servers and the other resources can successfully authenticate using the domain controller on Azure
  3. Transfer the FSMO roles to the Azure DC
  4. Stop the on-premise DC

–> This way, you migrated the ADDS infrastructure to Azure, in a transparent way, with zero downtime.

The following are the general steps that can be followed for any application that supports extending:

  1. Create 1 or more virtual machines in Azure. These VMs will hold the application roles that will be extended. The OS and VM configuration depends on the application.
  2. Extend the application role to the (or more) virtual machine in Azure
  3. Verify that the new server in Azure is operational and can handle the application services and requests. (A test plan should be run)
  4. Plan a transition step to ‘cut’ the on-premise server. This way, only Azure servers are requesting the application services.

The following ‘services’ can generally support this migration path:

Service

How

Web services (IIS, Apache…)

The Web services generally support Load Balancing. Extending a Web service farm is usually supported.

Clustered services

Generally, any service which supports clustering (SQL Server, DHCP, Hadoop…) can use this migration path.

Multi-instances roles

They generally requested via a ‘weight’ or ‘priority’ mechanism. We can mention as examples: Domain Controllers, DNS servers…0

2.1.2- Pro and Cons

The following table resumes the Pro and Cons related to this migration path:

Pro

Cons

  • Does not require resort to third-party tools
  • Zero or near-zero downtime
  • Fast and guaranteed rollback
  • Different extension method for each type application
  • Need specialized people, for each product to be extended
  • Change of the application configuration
  • Not applicable for standalone applications

2.2- Manual upload of the Virtual Machine’s virtual hard disks to Azure

2.2.1- Description

This this the second path that can be took to migrate workloads to Azure. This time, it doesn’t depend on the application.

This approach is applicable for both virtual and physical servers. And may need prerequisites prior to start the migration itself.

The next paragraph describes the different steps to successfully migrate workloads using this method:

Physical servers

  1. The physical server disks should be converted to the VHD format. There are two possible manners to do it :
    1. Use Disk2VHD : This tool can make an online conversion of physical server’s disks to  VHD files format. The obtained VHDs are a consistent point-in-time snapshots of the converted volumes. (Only for Windows supported operating systems, Linux operating systems are not supported)
    2. Convert the whole Physical server to a virtual machine. There are two ways to finally obtain the desired VHD format
      1. If your target virtualization stack is VMWare :
        1. You can use VMware vCenter Converter. This tool will allow the P2V (Physical to Virtual)  conversion of you physical server to a VMWare virtual machine.
        2. You should convert your VMDK disks to the VHD format. This can be done via several ways :
          • If you have a Hyper-V virtualization platform: You can make a V2V conversion of the VMware virtual machines to Hyper-V virtual machines. That way, you will obtain the desired VHD format. The following blog (Link1, Link2) describes the way to convert VMWare VMs to Hyper-V VMs
          • You can convert directly VMDK virtual hard disks to the VHD format using conversion tools like MVMC (Link1, Link2) or third-party tools like Starwind V2V converter (Link1). But i recommend using MVMC
      2. If your target virtualization stack is Hyper-V : Use MVMC to make a P2V conversion toward a a Hyper-V server (Only for Windows supported operating systems, Linux operating systems are not supported). Choose the VHD format for the disks type.
  2. Upload the machine VHD files to Azure. The best two options to use:
    1. For fixed VHD files format : Use AzCopy
    2. For  dynamic or fixed VHD files format : Use Add-AzureVHD powershell command. Follow this blog to optimize the usage of this tool
  3. Creation of the virtual machine using the uploaded virtual hard disks : Use the Provisioning script to create a virtual machine from an existing virtual hard disk.

Virtual machines

  1. The goal is to obtain the virtual machines disks under VHD format
    1. If your virtualization stack is VMWare: You should convert your VMDK disks to the VHD format. This can be done via several ways :
      1. If you have a Hyper-V virtualization platform: You can make a V2V conversion of the VMware virtual machines to Hyper-V virtual machines. That way, you will obtain the desired VHD format. The following blog (Link1, Link2) describes the way to convert VMWare VMs to Hyper-V VMs
      2. You can convert directly VMDK virtual hard disks to the VHD format using conversion tools like MVMC (Link1, Link2) or third-party tools like Starwind V2V converter (Link1). But i recommend using MVMC
    2. If your virtualization stack is Hyper-V : Hyper-V supports 2 formats : VHD and VHDx
      1. If your virtual machines disks format are VHDx : You should convert the VHDx files to VHD. For that you can the powershell command Convert-VHD
      2. If your virtual machines disks format are VHD : No steps to be done
  2. Upload the machine VHD files to Azure. The best two options to use:
    1. For  fixed VHD files format : Use AzCopy
    2. For  dynamic or fixed VHD files format : Use Add-AzureVHD powershell command. Follow this blog to optimize the usage of this tool
  3. Create a  virtual machine using the uploaded virtual hard disks : Use the Provisioning script to create a virtual machine from an existing virtual hard disk.
2.2.2- Pro and Cons

The following table resumes the Pro and Cons related to this migration path:

Pro

Cons

  • Does not require a change to the application configuration
  • Does not require application experts
  • Fast and guaranteed rollback
  • Applicable for standalone workloads
  • May take long time (Conversion + Upload = Hours)
  • Require server downtime (hours)
  • Several prerequisites
  • Manual process
  • Not  supported for all Operating Systems

2.3- Use Microsoft Virtual Machine Converter (MVMC)

2.3.1- Description

This this the third path that can be took to migrate workloads to Azure.

This approach is applicable only for virtual machines residing on supported VMWare hosts (ESX/VSphere/VCenter)

The next paragraph describes the different steps to successfully migrate workloads using this method:

NB : Because the current version of MVMC (3.1) does not support Azure Resource Manager storage containers, extra steps will be conducted to successfully make the migration. These steps will be marked with green color.

  1. Install the MVMC tool on a server which ‘preferably’ belongs to the same network as the VCenter server. The following details the installation prerequisites (Link1). You can download MVMC from the following link (Link2)
  2. Make the following steps as prerequisites to use MVMC to migrate VMWare VMs to Azure. The most important step is to upload a management certificate to Azure (Link1)
  3. Create a classic (V1 Azure Service Management) storage account where the VHDs will be uploaded. This storage account will be used as an intermediate during the migration
  4. There are two options which can be used to convert VMWare virtual machines : Using the MVMC graphical wizard, or use the MVMC cmdlets.
    1. Use the MVMC GUI : Follow this link and follow the steps to connect to a VCenter/ESX server and convert/upload  VMware Virtual machine VHDs to the already created storage account in step 3 (VMWare to Azure using MVMC GUI)
    2. Use the MVMC cmdlets : The following document contains a sample script which can be used to convert and migrate  VMware virtual machines to Azure. Download the MVMC_cmdlets.doc from the following link (MVMC_cmdlets.doc)
  5. Move the uploaded virtual hard disks from the temporary classic storage account (created on step 3) to the target storage account (ARM) where the virtual machine storage should reside. The move can be easily done via few steps using the Start-AzureStorageBlabCopy Azure powershell command. Use the ‘Initiating an Asynchronous Copy Request (authenticated source)‘ section (Copy VHDs between Azure BLOBs). You should install Azure Powershell as a prerequisite (Downland Azure Powershell)
  6. Create a  virtual machine using the uploaded virtual hard disks : Use the Provisioning script to create a virtual machine from an existing virtual hard disk.
  7. Delete the VHDs residing on the classic storage account

NB: MVMC can be used with MAT (Microsoft Automation Toolkit) to make bulk conversion operations. Look the Microsoft Automation Toolkit section on this page (MVMC with MAT)

2.3.2- Pro and Cons

The following table resumes the Pro and Cons related to this migration path:

Pro

Cons

  • Does not require a change to the application configuration
  • Does not require application experts
  • Fast and guaranteed rollback
  • Applicable for standalone workloads
  • Optimal for low scale migration
  • May take long time (Conversion + Upload = Hours)
  • May require server downtime (hours)
  • Extra steps  due to lack of  ARM storage accounts support
  • Manual process (though can be automated)
  • Not optimal for an Enterprise migration path

 

2.4- Use Azure Site Recovery

2.4.1- Description

This this the fourth path that can be took to migrate workloads to Azure.

This approach is applicable only for virtual machines residing on supported VMWare hosts (ESX/VSphere/VCenter), and for physical servers.

This method is the most complicated method deploy, but once deployed, it will me a one-click solution to easly migrate workloads to Azure.

NB : Azure Site Recovery  does not currently support Azure Resource Manager, hence it will not be possible to use it with Azure IaaS V2. In the meanwhile, the same steps are applicable when it will be supported in few months (Mid Q4 2015)

In this description, i will highlight the necessary steps to use Azure Site Recovery as a migration solution from VMWare to Azure (But the same steps apply to Hyper-V/Physical). For a detailed explanation, you can refer the Microsoft official documentation (Migrate VMWare to Azure using Azure Site Recovery)

2.4.1.1- What is ASR and what are its components

ASR is an Azure Service which can be used to migrate/protect different kind of workloads from a source site to a target site. For a complete list of Sources and Targets, visit this page : Azure Site Recovery Overview

The following pictures shows the components involved on a ASR protection/Migration of workloads to Azure.

asrvmware_arch

(Image Credit  : Microsoft)

The following components should be used and installed on-premise and on Azure in order to enable workloads protection (Table copied from Migrate VMWare to Azure using Azure Site Recovery)

Component

Deployment

Details

Configuration server

Deploy as a Azure standard A3 virtual machine in the same subscription as Site Recovery.

You set up in the Site Recovery portal

This server coordinates communication between protected machines, the process server, and master target servers in Azure. It sets up replication and coordinates recovery in Azure when failover occurs.

Master target server

Deploy as Azure virtual machine — Either a Windows server based on a Windows Server 2012 R2 gallery image (to protect Windows machines) or as a Linux server based on a OpenLogic CentOS 6.6 gallery image (to protect Linux machines).

Three sizing options are available – Standard A4, Standard D14 and Standard DS4.

The server is connected to the same Azure network as the configuration server.

You set up in the Site Recovery portal

It receives and retains replicated data from your protected machines using attached VHDs created on blob storage in your Azure storage account.

Select Standard DS4 specifically for configuring protection for workloads requiring consistent high performance and low latency using Premium Storage Account.

Process server

Deploy as an on-premises virtual or physical server running Windows Server 2012 R2

We recommend it’s placed on the same network and LAN segment as the machines that you want to protect, but it can run on a different network as long as protected machines have L3 network visibility to it.

You set it up and register it to the configuration server in the Site Recovery portal.

Protected machines send replication data to the on-premises process server. It has a disk-based cache to cache replication data that it receives. It performs a number of actions on that data.

It optimizes data by caching, compressing, and encrypting it before sending it on to the master target server.

It handles push installation of the Mobility Service.

It performs automatic discovery of VMware virtual machines.

On-premises machines

On-premises virtual machines running on a VMware hypervisor, or physical servers running Windows or Linux.

You set up replication settings that apply to virtual machines and servers. You can fail over an individual machine or more commonly, as part of a recovery plan containing multiple virtual machines that fail over together.

Mobility service

Installs on each virtual machine or physical server you want to protect

Can be installed manually or pushed and installed automatically by the process server when protection is enabled for the server.

The Mobility service send data to the Process Server as part of initial replication (resync.) Once the server reaches a protected state(after resync is completed) the Mobility service performs an in-memory capture of writes to disk and sends it to the Process Server. Application consistency for Windows servers is achieved using the VSS framework.

Azure Site Recovery vault

Set up after you’ve subscribed to the Site Recovery service.

You register servers in a Site Recovery vault. The vault coordinates and orchestrates data replication, failover, and recovery between your on-premises site and Azure.

Replication mechanism

Over the Internet—Communicates and replicates data from protected on-premises servers and Azure using a secure SSL/TLS communication channel over a public internet connection. This is the default option.

VPN/ExpressRoute—Communicates and replicates data between on-premises servers and Azure over a VPN connection. You’ll need to set up a site-to-site VPN or an ExpressRoute connection between the on-premises site and your Azure network.

You’ll select how you want to replicate during Site Recovery deployment. You can’t change the mechanism after it’s configured without impacting protection on already protected servers.

Neither option requires you to open any inbound network ports on protected machines. All network communication is initiated from the on-p

2.4.1.2- ASR replication mechanism

This section explains how to migrate a  VMware virtual machine to Azure using ASR. I will highlight the high level steps, explaining the End to End process:

vmware2azuresteps

(Image Credit  : Microsoft)

A- Create the Azure Site Recovery vault

The first step is to create an Azure Site Recovery vault. A vault is just a container which will be targeted later for your replication mechanism. After creating the vault, a storage account (GRS type) will be created, it will store the replicated data.

B- Set up the configuration server component on Azure

The configuration server is a server residing on your Azure subscription. As explained on  ‘2.3.1.1- What is ASR and what are its components’, the configuration server  coordinates communication between protected machines, the process server, and master target servers in Azure. It sets up replication and coordinates recovery in Azure when failover occurs. An standard A3 virtual machine is recommended for this component. This server should added to the already created vault

C- Set up the Master Target component on Azure
Now, an Azure VM should be created to hold the master target role. Disks will be attached to this VM, and each disk will receive data from its analogue disk on-premise. So if you are migrating a VM with N disks, the VM should support at least N+1 data disks (Be aware that the maximum supported data disks per VM is limited by its size and series, look to Azure Virtual Machine Sizes). If the Master Target VM reaches the maximum data disks count, you can add a second Master Target VM or upgrade the current size to a size which support the data disks count (N+1)

D- Set up the Process Server component on-premise

A server must be created on-premises and hold the Process server component. It’s recommended to create the server on the same network than the ESX infrastructure. This server with be registered with the Configuration server. It’s recommended to install VMWare VSphere CLI 5.5.0

E- Check the components server updates

It’s highly recommended to install the last windows updates on the component servers

F- Create protection groups

On the Azure portal, create a protection group and configure the default replication settings. We will add later the virtual machines to be migrated to this protection group. One protection group can include multiple virtual machines.

G- Set up the replication for the virtual machines

For each VMware virtual machine to protect, the Mobility Service agent will be installed. Then, the VM will be added to the protection group already created. The Properties for the target virtual machine in Azure can be configured (Name, IP…)

H- Planned Failover

After the initial replication completes, we can make a planned failover. A failover plan should be created which will include the failover properties (one or more VMs, order…)

NB: A planned failover will cause downtime. In fact, the source machine is stopped, the delta between hard disks is synchronized to have an exact clone of the source machine.

I- Validate migration

Once the virtual machine is running on Azure, verify its connectivity with on-premise.


2.4.3- Pro and Cons

The following table resumes the Pro and Cons related to this migration path:

Pro

Cons

  • Does not require a change to the application configuration
  • Does not require application experts
  • Fast and guaranteed rollback
  • Applicable for standalone workloads
  • Enterprise grade solution
  • Minimal downtime
  • Can be used to failback to on-premise
  • Can use VPN, ExpressRoute or Public internet for replication
  • Need deployment of different components
  • Not free*

* The protection of a virtual machine is free for the first 31 days (The Initial replication and failover time will always be less than 31 days), so the ASR service is considered free for a migration path. However, the Master Target and the process server will use Azure compute and storage resources, which will be accounted on the bill.

3- Migration paths comparison

In this final section, i will present a summary comparison table comparing the different migration options discussed in this post.

Migration path

Cost

Require a migration platform

Scalability

Manual Effort

Downtime

Rollback

Reverse Migration

Depend on the Application

Extend the application to Azure

Free

No

+

+++++

No

N/A

N/A

Yes

Manual upload of VHDs

Free

++*

+

++++

+++++**

Yes/Fast

No

No

MVMC

Free

++

++

+++

+++++**

Yes/Fast

No

No

ASR

++

+++

+++++

+

+

Yes/Fast

No

No

* Only If the source virtual machines are not under the VHD format

** Depends on the data to be uploaded to Azure and on the outbound bandwidth

4- Which migration path to choose

The following table describes my ‘personal’ recomdantions toward which migration path to choose

Migration path

When ?

Extend the application to Azure

  • Downtime is not permitted
  • Simple to accomplish

Manual upload of VHDs

  • Long downtime is permitted
  • Few machines to be migrated

MVMC

  • Long downtime is permitted
  • Few machines to be migrated
  • Minimize manual steps

ASR

  • Long-term solution (Enterprise soution)
  • Continous machine migration
  • Minimal downtime needed
  • Postpone the migration decision*

* Once the initial replication is completed, you can decide whether or not to failover the virtual machine to Azure. The VM will keep replicating with the on-premise server until you decide to make the failover.

Advertisements

2 thoughts on “Migration paths from VMware to Microsoft Azure (Classic and ARM)

    • You can reduce the Master target VM size. But, i think it’s interesting only for test purposes. The fact that the disk count and IOPS are limited by the VM size, Microsoft proposes only VM sizes with maximum disks count (16 for A4, 32 for D14). DS14 is proposed too to boost the disk throughput performances if the data churn is important during the replication.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s