deployment

when deciding to Migrate workloads from on-premise VMware platform to Azure.

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:

Web services (IIS, Apache…) — The Web services generally support Load Balancing. Extending a Web service farm is usually supported.

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

Pro:

· Does not require resort to third-party tools

· Zero or near-zero downtime Fast and guaranteed rollback

Cons:

· 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 the Pro and Cons related to this migration path:

Pro:

· Does not require a change to the application configuration

· Does not require application experts

· Fast and guaranteed rollback, Applicable for standalone workloads

Cons:

· 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:

· 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

Cons:

· 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.

(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)

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:

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:

* 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.

 

 

* 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

* 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.

Sample Enterprise Plan