Managing Microsoft Hybrid Clouds (2015)

Chapter 8. Migrating to Microsoft Azure

In the previous chapters, you learned about Azure and how you can extend your on-premises infrastructure to Microsoft Azure. Use case scenarios for linking Azure to on-premise infrastructures are, for example, using a replica of Active Directory or SQL Server in Azure. You also learned how to use Azure to back up data and for disaster recovery orchestration.

In this chapter, we will discuss how to migrate servers, including the applications running on them, to Microsoft Azure as easily as possible.

When you begin planning your migration, you need to consider several key factors, such as cost, business and technical requirements, timeline, and any testing that will be required in the migration process. This chapter focuses mainly on the technical aspects.

In this chapter, we will describe a couple of scenarios for the migration of applications to Microsoft Azure:

· Migrating a Hyper-V virtual machine to Microsoft Azure

· Migrating a VMware vSphere virtual machine to Microsoft Azure

· Migrating an Amazon EC2 virtual machine to Microsoft Azure

· Migrating a physical server to Microsoft Azure

Before moving your servers to Microsoft Azure, you should check a couple of things.

Premigration checks

Let's check the following items and make sure they are available before moving applications to Azure or any other cloud:

· Make sure Microsoft Azure supports the guest operating system. You can check this at http://msdn.microsoft.com/en-us/library/azure/ee924680.aspx.

· Check whether the disk volume size of the on-premises server is supported by Microsoft Azure.

· Make sure the application software does not require a dongle for licensing.

· Make sure the software vendor allows moving a license to the cloud or a shared server environment. Some vendors state the license is tied to the instance it was originally installed on. Moving the license to a multitenant infrastructure is not always allowed.

· If you are using an OEM license of Windows Server, you will first need to adjust the license to a volume license. After an OEM license has moved to a server with different hardware than the one it was installed on, it will not boot anymore. This is because an OEM license is glued to the hardware it was installed on.

· Does the SLA of Microsoft meet your expectations of availability? Remember, Microsoft does not provide an SLA for a single virtual machine. The VM needs to be part of an availability set to be able to get a SLA for it.

· Make sure the license is allowed by the software vendor to be moved to the cloud.

The right for movement of licenses to platforms other than the one a license was originally installed on is called license mobility by Microsoft.

License mobility

When a software license has been acquired and installed on a server (either physical or virtual), it is assigned to that server. It is very common for software vendors to disallow licenses to move freely over servers.

One of the reasons for software vendors to disallow free movement of licenses is to prevent customers purchasing a single license that can be used for 24 hours. For example, in a scenario where a customer is using the follow the sun principle, software could follow shifts of people working in Asia, then to Europe, and then to the USA. Another reason is software vendors' fear of reduced income when a virtual server running in a multitenant infrastructure is shared by multiple organizations. Instead of selling a license to each organization, only one license would technically be enough.

It is a bit like if a car manufacturer does not allow his cars to be used by a lease company. The car manufacturer only allows selling to consumers directly.

It all comes down to making sure software vendors make the best possible revenue. When software is moved to Azure or any other cloud, we need to verify that this is allowed. Each vendor has its own policies, and understanding the policies is very difficult.

We will focus on policies for Microsoft software in this chapter. We will start looking at licenses with Microsoft Windows Server and desktop operating systems such as Windows 8. It is not allowed to move those licenses to Microsoft Azure. Using Windows client operating systems on Microsoft Azure is not allowed at all.

Windows Server needs to be licensed using the Microsoft Service Provider License Agreement (SPLA). This means customers will need to lease a Windows Server license and pay Microsoft for that. The ability to move Microsoft applications to the cloud depends on the application.

First, a customer will need to have purchased Software Assurance on the product. Software Assurance (SA) is a commitment to Microsoft that provides customers with many benefits. One of the benefits of SA is the ability to reuse (move) licenses in the cloud.

Not all Microsoft products are eligible for this right, which Microsoft calls License Mobility through Software Assurance. Customer benefits of each Microsoft product are described in a document titled Product Use Rights (PUR). This document is updated almost each month. The most recent PUR is published at http://www.microsoft.com/licensing/products/products.aspx.

Examples of products that are eligible for License Mobility through SA are:

· Exchange Server 2007 and 2013

· Forefront Identity Manager 2010 R2

· Lync Server 2013

· Microsoft Dynamics CRM 2013 Server

· SharePoint Server 2013

· SQL Server 2014 Standard, Enterprise, and Business Intelligence

Before you move the license to Microsoft Azure, you have to fill in a form to notify Microsoft that you are moving licenses. License Mobility is only allowed to shared data centers that are an Authorized Mobility Partner.

Once we are sure that the license can be moved, it is time to plan for the migration. Let's see what our options are.

Migration options

A few techniques are available to migrate a virtual machine from on-premises to the cloud. In this section, we will discuss the techniques for a migration using Azure as a destination:

· Offline conversion with considerable downtime: A conversion is required when the virtual machine running on-premises is using a format that is not supported by the native cloud platform. For example, VMware virtual machines use .vmdk virtual disk files. We cannot place those on Microsoft Azure without first converting the virtual disks to .vhd format.

· Move with no downtime involved: A move is basically transfer of the virtual machine without adjustments to the cloud platform. This can currently be done offline for virtual machines using VHD virtual disks running on Hyper-V. At the moment, it is not possible to perform an online migration using Hyper-V Live Migration. It is probably only a matter of time until we can do Live Migrations to the cloud and back.

· Replication with limited downtime: Replication means data on a source server is replicated to a target server. The target server is running on a cloud platform and is kept in sync with the source server. In most scenarios, replication is used for disaster recovery purposes, but it can be used to move virtual machines as well. The advantage of using replication is that there is almost no downtime. In July 2014, Microsoft acquired InMage, which has a very interesting migration tool. The tool is now calledMigration Accelerator for Azure. We will have a look at this tool later.

· Nesting: This is a new technique that is available on a few cloud platforms. Basically, nesting means that the virtual machine is not converted but is running on top of a Cloud Application Hypervisor. Ravello Systems offer such a solution for Amazon Web Services, Rackspace, HP Cloud, and Google Compute Engine. VMware virtual machines can run without modifications on those cloud platforms. For Azure, nesting is not possible at the moment. Integration with Azure remains on the Ravello road map.

Offline conversion

The most basic conversion approach available is an offline conversion. A Hyper-V or VMware virtual disk is converted to the virtual disk format supported by Azure. This conversion is done offline. Depending on the size of the virtual disk, this conversion can take many hours. So, you really need to determine for how long applications can be offline by asking the owner of the application. Microsoft offers the Microsoft Virtual Machine Converter software to perform offline conversions.

Since release 3.0, Microsoft Virtual Machine Converter can do two types of conversions:

· Convert virtual machines running on VMware vSphere to either Hyper-V or Azure

· Convert physical servers running Windows Server 2008 or later or Windows Vista or later to Hyper-V

Microsoft Virtual Machine Converter is a free tool. Before the release of Azure Migration Accelerator, this was the only option to convert servers to Azure. Migration Accelerator is a much more mature and feature-rich solution.

Migrating a Hyper-V virtual machine to Microsoft Azure

Hyper-V supports .vhd and .vhdx virtual disk files. As Microsoft Azure is running Hyper-V as well and also supports both virtual disk types, the migration is quite easy.

In this scenario, we assume the virtual machine can be switched off during the migration to Microsoft Azure. If you cannot afford much downtime, you can use the free Azure Migration Accelerator tool.

The steps involved in migration are:

1. Shut down the virtual machine.

2. Upload all of the .vhd files to Microsoft Azure using one of the methods described in the previous chapters.

3. Create one or more disks in the Management Portal using the uploaded .vhd files.

4. Create a new virtual machine in Microsoft Azure.

5. Start the virtual machine.

6. Remove the integration tool.

Moving a virtual machine from Azure to on-premises

While the cloud offers many advantages, it may be required to move virtual machines from Azure to on-premises. Currently, this is not possible using Live Migration. Microsoft Azure data centers do not offer such a feature, although technically speaking this should be possible.

Microsoft does offer Live Migration without source and target hosts sharing the same storage. Also, NVGRE allows you to move virtual machines between two networks that are not part of the same network.

We have a few options available to move virtual machines from Azure to on-premises:

· Use a third-party tool and perform a V2V conversion

· Download the .vhd files

Using a third-party tool has the advantage that downtime can be reduced. Most tools offer the ability to copy the virtual machine data to a target server while the source server remains online. The source server is required to be offline only to copy the changed data.

Using a V2V method is described in the next section, where you will learn how to use Double-Take.

Converting a VMware vSphere virtual machine to Microsoft Azure

Virtual machines running on VMware ESXi use the VMDK virtual disk file format. As Azure is based on Hyper-V, it does not support the VMDK format. This implies we need to convert to VHD format.

Several tools can be used to perform such a migration. We will have a look at Microsoft Virtual Machine Converter (MVMC) 3.0, which is a free tool.

MVMC is designed to convert VMware virtual machines running Linux or Microsoft Windows to Hyper-V or Microsoft Azure. It supports Hyper-V running on Windows Server 2012 R2, Windows Server 2012, and Windows Server 2008 R2 SP1.

It also supports the conversion of virtual machines from VMware vSphere 5.5, VMware vSphere 5.0, and VMware vSphere 4.1 hosts.

MVMC requires an ESX, ESXi, or vCenter Server to connect to. The procedure used by MVMC is as follows:

1. A snapshot of the VMware virtual machine is taken.

2. The virtual machine is shut down.

3. The VMDK file(s) are converted to VHD format. The VHD file is initially stored on the computer that has MVMC installed.

4. The VHD file is uploaded to Microsoft Azure.

A prerequisite is to have a management certificate uploaded to Azure. This certificate is used by MVMC for authentication to Azure.

The procedure to create and upload a certificate is as follows:

1. Make sure makecert is available on the server that is used for the conversion.

2. Create the certificate.

3. Export the certificate without the private key to a .cer file.

4. Upload the .cer file to Azure using the Management Portal.

To create a management certificate, execute the following command on the machine on which you are installing MVMC (start a command prompt as an administrator for that):

makecert -sky exchange -r -n "CN=<CertificateName>" -pe -a sha1 -len 2048 -ss My "<CertificateName>.cer"

The result is a .cer file located in the working folder you started makecert in. The certificate is also added to your personal certificate store. You can check this by using MMC and adding the certificated snap-in.

The next step is to add the certificate to the Trusted Root Certificate Authorities folder. To do so, select the .cer certificate in Explorer and double-click on it. Then, perform the following steps:

1. Select Install Certificate.

2. Select Local Machine.

3. Click on Next.

4. Select Place all certificates in the following store.

5. Click on Browse.

6. Select Trusted Root Certification Authorities.

7. Click on Ok.

8. Click on Next.

9. Click on Finish.

Next, upload the certificate to the Azure portal by performing the following steps:

1. Log in to Azure.

2. Select Settings.

3. Select Management Certificates.

4. Click on Browse file.

5. Select the .cer file you created earlier.

6. Click on the checkmark.

The actual conversion of a VMware virtual machine is quite simple. It is basically a next-next-finish operation.

Microsoft announced Azure Site Recovery will support VMware vSphere in the near future. By using Site Recovery you can easily migrate virtual machines to Azure. Microsoft Migration Accelerator will be used for this conversion and replication.

Migration using Migration Accelerator for Azure

Migration of virtual machines has so far involved some manual labor and downtime of the application. If downtime should be zero or close to zero, a great new tool is Microsoft Migration Accelerator for Azure. Migration Accelerator is able to synchronize source servers with a target in Azure. This is done over HTTPS while the source server is fully operational. To reduce network bandwidth, all data is compressed.

Migration Accelerator for Azure was introduced in September 2014 by Microsoft as a tool for migrations of virtual machines to Microsoft Azure. This tool is based on a tool called Scout made by a company called InMage, which Microsoft acquired in July 2014.

Migration Accelerator is an enterprise tool for almost zero downtime migrations of VMware, Hyper-V, Amazon Web Services, and physical servers to Azure. Both Windows and Linux are supported as the source operating system. However, during the preview of Migration Accelerator, support was limited to Windows Server 2008 R2, Windows Server 2012, and 2012 R2.

Migration Accelerator automates all aspects of migration including discovery of source workloads, remote agent installation, network adaptation, and endpoint configuration. With Migration Accelerator, you reduce cost and risk of your migration project.

Migration Accelerator creates a replica of a source server and keeps that replica in sync with the source server on-premises. This means that once both source and target servers are in sync; you can shut down the source server and then boot the target server to complete the migration.

Let's have a look into how Migration Accelerator works under the hood.

As Migration Accelerator was in a limited preview at the time of writing of this book, Microsoft provided limited information on this service. When you initially create the configuration server, make sure you assign a fixed IP address to this server. If the IP address changes, you will need to reinstall the Migration Accelerator software.

What the software does is creates a virtual disk (VHD) in Azure for each on-premises source target volume you want to move to Azure. This VHD is then attached to a dedicated server running in Azure. The advantage of not having a replica for each source server is reducing the computing costs in Azure.

To be able to use Migration Accelerator, it is not necessary to have a dedicated connection to Azure using ExpressRoute. It is perfectly possible to use a standard HTTPS Internet connection. However, it is to be noted that the bandwidth can be limited and data security can be an issue. The preferred way of migrating is using a site-to-site VPN or an ExpressRoute connection.

To get an understanding of how Microsoft Migration Accelerator works, we will first discuss the required components.

Components of Migration Accelerator

The following figure shows the components of Migration Accelerator:

First, each on-premises source server requires a so called Mobility Service agent to be installed. This is an agent that can be deployed centrally on physical and virtual servers you would like to migrate to Azure. The agent is responsible for transferring data to the Process Server. To keep the source and target in sync, the agent captures all writes to the disk.

The Process Server (PS) is a virtual or physical server installed on-premises. It is responsible for receiving data changes from the source servers, performing compression, encryption, caching, and bandwidth management, before replicating to a secondary location for DR purposes. Data is not sent synchronously. This would have a negative effect on the performance of applications and the application would get a write acknowledge only after the write succeeded, both on the source and target server. The synchronization delay is kept at a minimum, which is about a few seconds.

Always make sure the Process Server is located at the same location as the source servers. This ensures that compute and IO overhead on the source server is kept at a minimum.

The Master Target (MT) server is a virtual machine running on Azure. This virtual machine has a virtual disk attached for each replicated on-premises volume. The MT server writes the data it receives from the PS.

If a source server requires a failover, the virtual disk is disconnected from the MT server and connected to a virtual machine on Azure. This means that during replication and synchronization, the actual target virtual machines are not running.

Make sure the size of the MT server is according to the documentation. Microsoft recommends an A4-size virtual machine. This has a maximum of 16 disks. As one disk is reserved for the retention point, an A4 virtual machine will allow the replication of 15 disks as the replication source.

The Configuration Server is a Microsoft Azure-based virtual machine that is responsible for communication between the MT server and the Migration Accelerator (MA) portal. It also controls the migration process.

The MA portal is a web portal that runs on Azure. You do not have to install this portal. It is provisioned for you when you decide to start using the MA. The portal can be accessed using a domain name such as <url that is sent to you>.cloudapp.net. The portal is the control center for your migrations. It will be able to discover source servers in your on-premises infrastructure. Also, the portal provides insight into the replication process.

Installing Migration Accelerator

Installation of the Migration Accelerator components is pretty straightforward. Make sure you have an affinity group, storage account, virtual network, and cloud service already configured before installing the Configuration Server and Master Target server.

First, install the Configuration Server and the Master Target server. Choose virtual machine size A3 for the Configuration Server and A4 for the Master Target server.

The Configuration Server communicates with the Process Server installed on-premises. To enable this communication, the Configuration Server requires a public IP address. Microsoft offers five public IP addresses for free for each standard Azure subscription. The soft limit is also five IP addresses, but this can be increased by requesting Microsoft support.

You first need to reserve a public IP address in Azure by using the PowerShell New-AzureReservedIP command. Then, use the reserved IP address for provisioning the virtual machine on which the Configuration Server will be installed.

The process of reserving a public IP is described at http://mythoughtsonit.com/2014/09/step-by-step-reserve-a-public-ip-address-in-azure/.

The Process Server requires Active Directory membership to be able to push the agent to each source virtual machine or physical server.

The following table shows the specification for the Process Server. The sizing depends on the data change rate. The cache disk is used to store replication data before it is copied to Azure.

If you have a daily change rate over 1 TB, it is advised to use additional Process Servers.

Microsoft Azure supports operating system disks having a maximum size of 127 GB. Data disks can be up to 1 TB in size. If the source servers have disks larger than the supported size in Azure, you will need to shrink those source disks first.

The process of making disks smaller in size depends on the operating system. If the source server runs on Hyper-V or VMware vSphere, you need to shrink the virtual disk file. The last step is to install the Process Server on-premises.

Using Migration Accelerator

When you are done installing the components, you can configure replication. At sign up for the Migration Accelerator server, you'll receive an e-mail with a URL for the MA portal. Access this portal using that URL.

In the Cloud Services tab, select the on-premises servers you want to migrate or protect. Select Mobility Services to install the agent on the source server. Once the agent has been installed successfully, click on the Protect button and configure the replication settings.

Once replication is configured and the source and target disk are synchronized, you can start migrating the server. Migration means Azure Migration Accelerator creates a new virtual machine on Azure, disconnects the disks from the Master Target server, and attaches the disk to the virtual machine.

Migrating with Double-Take Move

Besides the Azure Migration Accelerator, we can use third-party tools to migrate a source server to Microsoft Azure. The source server can be any Windows Server either running as a physical server or as a virtual machine on VMware vSphere or Microsoft Hyper-V.

We are going to use Double-Take Move for the migration of a Windows server to Microsoft Azure. It is necessary to have a site-to-site VPN connection between your on-premises network and Microsoft Azure. This is because Double-Take uses a dynamic range of RPC ports.

Double-Take has a server and a client component. Double-Take requires an operational Windows server as a target server. This is a difference compared to the Azure Migration Accelerator.

The steps to perform a migration are as follows:

1. Set the source and target server in Double-Take.

2. Perform a migration of data.

3. Cut over the source server to the target server.

Double-Take has the following four options for migration:

· Move data only

· Move an entire server to a new target server

· Move an entire server to a virtual machine running on Hyper-V

· Move and entire server to a virtual machine running on VMware vSphere

The need for Double-Take has reduced quite a bit since Migration Accelerator became available. Double-Take needs an additional software license plus it requires operational target virtual machines. This makes using Double-Take more expensive. To save the trouble of installing, there are multiple pre-installed Double-Take images with various licensing options available in the Azure Marketplace.

Converting an Amazon EC2 virtual machine to Microsoft Azure

Reasons for leaving Amazon EC2 for Azure can be costs, missing features, or the lack of hybrid cloud scenarios. Also, Amazon does not offer the flexibility on how to use your credits like Azure does. On Amazon, customers spend money on storage and compute credits. Compute credits that are not consumed cannot be used for paying usage of storage resources. This is unlike Azure, which has a single credit. The credit can be spent on any available Azure resource.

As Amazon is using the Amazon Machine Image (.AMI), you will need to convert an Amazon virtual machine if you want to run this virtual machine on Microsoft Azure.

A couple of scenarios are possible to perform the conversion. You could use a V2V conversion tool that performs a direct conversion. You will probably need to create a direct VPN connection between Azure and Amazon.

We will focus in this paragraph on some free tools that allow a simple conversion of a virtual machine. This method is not well suited for mass conversions of virtual machines. The transfer will probably take a long time to complete depending on the WAN bandwidth available.

The steps required to migrate from Amazon to Azure are as follows:

1. Convert disks of the Windows Server instance running on AWD to .vhd files.

2. Download the VHD files to on-premises.

3. Convert to VHD and install Hyper-V Integrations Tools.

4. Upload the VHD files to Azure.

5. Create a new Azure virtual machine.

Migrating using Disk2VHD and PowerShell scripts

In this scenario, we are going to use the free SysInternals tool Disk2VHD to create a snapshot of a running virtual machine on Amazon. Then we are going to download the VHD to a Hyper-V host. When that is done, the VHD is uploaded to Azure and a virtual machine is created.

The following steps are performed for this scenario. (This is a high-level overview. For a complete, detailed, step-by-step description, search for a Microsoft blog post titled Guided Hands-on Lab: Migrate VMs to Windows Azure from Amazon AWS.)

1. RDP to the virtual machine running on Amazon that you want to migrate to Azure.

2. Download and install Disk2VHD.

3. Execute Disk2VHD. Select a local disk of the virtual machine as a destination.

4. Next we need to use the Amazon AWS PowerShell module. Using this module, the VHD disk is transferred from the Amazon virtual machine to an Amazon S3 bucket. This can be compared to Azure Storage. This step is required so we can download the VHD from Amazon to an on-premises Hyper-V server.

5. When the VHD file is located on a local server, we need to convert the disk. Azure does not support dynamic disks, so we need to covert the disk to a fixed sized VHD. PowerShell has a Convert-VHD cmdlet that allows us to perform such a conversion.

6. Next we need to add the Hyper-V Integration Services into the VHD. This can be done using PowerShell.

7. The next step is to upload the VHD to Azure. This can be done using PowerShell.

8. When the VHD is uploaded, we can create a new virtual machine using the VHD again using PowerShell or manually via the Azure Management Portal.

Using Windows Azure Migrator

Windows Azure Migrator is a free tool that assists in a migration from Amazon to Azure. The steps are very easy:

1. You connect using RDP to the source server running in Amazon.

2. Then you start a browser and enter the URL http://www.azuremigrator.net.

3. Select the drives you would like to migrate. Currently only the system disk C: is supported.

4. Fill in the subscription ID of Azure.

5. A certificate will be created. Upload the certificate to Azure.

6. Select the storage account or create a new account.

7. Select the virtual machine size and the cloud service.

As you can see, in a few simple steps, a virtual machine can be migrated to Azure. A detailed instruction can be found at http://miteshc.wordpress.com/2014/03/20/migratevm-fromaws-toazure/.

Migrating Azure deployments between data centers and subscriptions

It is very well possible you would like to either move a set of virtual machines to another Azure data center or duplicate a set of virtual machines from a data center and deploy those in a different data center. Think about these scenarios:

· Deploy to multiple data centers. You have built a set of virtual machines that serve an application in a single Azure data center. For high availability or disaster recovery reasons, you may want to duplicate this deployment to a different Azure data center.

· Avoid downtime because of maintenance. You have an application running on a single VM in a single Azure data center. You want to avoid the downtime when Microsoft performs maintenance. So the application needs to be deployed in a different Azure data center as well.

· Moving between subscriptions. Suppose you created virtual machines under a single Azure subscription and want to move those virtual machines to a different Azure subscription, or want to move virtual machines from a test environment to a production environment.

· Move to a different Azure data center. Suppose Microsoft opens a new data center that better fits your needs, for example, because it is located closer to your location.

Microsoft Azure at the moment does not offer a built-in feature to execute these scenarios.

However, in January 2015, Microsoft and Persistent Systems have rolled out an Azure Data Center Migration Solution 1.0 tool. This is an open source and free to use tool for migrations of Azure IaaS deployments.

You can migrate all of the following resources in the source data center:

· Affinity groups

· Networks

· Cloud services

· Storage accounts

· Virtual machines (VMs)

Basically, the tool automates the export and import of the preceding Azure services.

The big advantage of this tool is the automation. It will do all the work for you to move or duplicate deployments. Copying virtual disks is done in a parallel way. However, the source virtual machines are switched off before the copy process starts.

If you cannot accept downtime, you will have to use an agent-based tool like Migration Accelerator or Double-Take.

The Azure Data Center Migration Solution Tool can run on either an on-premises virtual machine or an Azure virtual machine. Supported operating systems are Windows 7 Service Pack 1 or higher and Windows Server 2008 R2 SP1 and higher.

The tool is based on PowerShell, so to use it successfully you need PowerShell skills. However, a key advantage of this solution is the flexibility and extensibility provided by the template-based and open source approach.

Azure Data Center Migration Solution Tool can be downloaded here:

https://github.com/persistentsystems/adcms

Summary

In this chapter, we discussed several tools that allow us to migrate servers to Microsoft Azure. The Azure Migration Accelerator is a very promising tool that allows multiple orchestrated migrations with hardly any downtime.

This chapter is the final technical chapter of this book. Chapter 9, Summary and a Look into the Near Future, will give a preview of what possible new features Azure will may bring in the future.