Migrating Your VMware to Azure: Challenges and Tools

DZone 's Guide to

Migrating Your VMware to Azure: Challenges and Tools

Looking to move your VMware instances into the cloud? Let's look at migrating to Microsoft Azure and the challenges, such as replication issues and recovery, you might run into.

· Cloud Zone ·
Free Resource

VMware and Azure

More and more enterprises today are moving their cloud services to Microsoft Azure. Azure has been quickly closing the gap on Amazon Web Services (AWS). It leverages its presence in the enterprise marketplace and leads with its hybrid cloud strategy and ability to provide service and workload mobility between on-premises and in-cloud workloads. Azure’s growth is driven in large part due to Microsoft’s Enterprise Agreement (EA), which provides enterprises with a single agreement for central IT and other departments to enjoy the various benefits that Azure presents to its customers.

As enterprises migrate to Azure, however, they need to consider what applications are being used in their organizations, as well as how to effectively plan and choose which tools are needed in order to ensure a smooth migration. Compatibility and the cost of running applications in on-demand cloud resources are other factors to consider for a successful migration.

In this article, we will discuss some of the challenges of migrating your VMware environment to Azure, and some solutions and best practices for ensuring a seamless migration.

VMware Migration Challenges

Moving large amounts of data from virtual machines in your on-premises environment into Azure is not without its challenges. These include having sufficient bandwidth for replication and data transfer and potential downtime that can occur for Production VMs running business operations. And, adding to that is the veteran enterprise IT environment — data centers filled with complex legacy installations that include multiple systems interdependencies.

While challenges are inevitable, all virtualized Microsoft environments are based on the same technology, Hyper-V, which makes migration significantly easier. Azure also provides the tools to migrate pools of resources from VMware as well as physical machines, using Azure Site Recovery (ASR).

Migrating With Microsoft ASR

The recommended method of migrating virtual machines to Azure is to use ASR. Using ASR, organizations can replicate their on-premises Hyper-V virtual machines, physical servers and VMware virtual machines to Azure. This is useful for disaster recovery to perform failovers, and also to migrate from an on-premises environment to Azure.

One of the major benefits of using ASR for replication of on-premises virtualized environments is that you pay only for the resources that you use, when you use them. When you actually do failover to Azure, Azure creates the VMs with the replicated data. When customers migrate from their on-premises environment to Azure, they can use their existing Windows Server licenses in Azure by using Azure Hybrid Use Benefit.

In order to use ASR, you will need first to create a new recovery vault. The recovery vault can be created in the Azure portal by clicking on More Services, and searching for ‘Recovery Services vault’. Once this is done, click Add and fill in the required information.

Once this is created, you can then start to prepare the infrastructure. This is done by choosing your protection goals, which is to replicate machines to Azure from VMware.

The next step is to prepare the Configuration Server. This server is a Windows Server 2012 R2 which should be hosted on your on-premises VMware environment. The ‘Microsoft Azure Site Recovery Unified Setup’ needs to be downloaded and installed, as well as the vault registration key. The Configuration Server needs to have PowerCLI 6.0 installed.

Note: VMware offers a capacity planning tool to help estimate the resources that the replication will use for the Configuration Server.

When ‘Microsoft Azure Site Recovery Unified Setup’ is installed, there will be a shortcut on the desktop called cspsconfigtool.exe. This tool needs to be run to add an account and give ASR access to your VMware environment. The account permissions can be found here.

Once the source is set up, the target environment needs to be set up. This consists of the Azure subscription, deployment model, a storage account for the replicated data and a dedicated virtual network.

Once the target is set up, it is time to configure the replication settings:

For a VMware machine to be replicated to Azure, the Mobility Service needs to be installed. This service captures data writes on the VM and forwards it to the Configuration Server. The Mobility Service can either be pushed out automatically or manually. To install it manually, the setup files can be found on the Configuration server at C:\Program Files (x86)\Microsoft Azure Site Recovery\home\svsystems\pushinstallsvc\repositor.

The next step is to enable replication for the VMs. This is where you select the source environment that was set up previously, select the target environment such as the storage account to replicate the VM, the destination virtual network and the VM that has the mobility service installed.

Once the virtual machine has been fully replicated, it will show up as “protected” in the Replicated items section in the Recovery Services vaults. When the virtual machine is protected, an unplanned failover can be performed.

Depending on the VMware account permissions specified earlier, the VMware machine is shut down, and Azure then creates the virtual machine from the data replicated to the Storage account. Once the virtual machine has successfully failed over and completed, ‘Complete Migration’ can be selected — which will then stop the source virtual machine from being replicated.

The virtual machine will now be running in Azure. Depending on how you have your Azure environment set up, if you have a site-to-site VPN or an Azure Expressroute, and if you migrated the virtual machine to be in the virtual network associated with the VPN or Expressroute, you can then change your on-premises DNS settings to point to the new Azure private IP, and connect to it. Providing that the virtual machine replicated successfully, you can then decommission the on-premises server.

Recovery Plans

ASR includes a failover automation feature called Recovery Plans. The Recovery Plan allows you to define groups of machines which need to be restored together (i.e., an N-tier application), as well as the order that those systems failover and are brought online. The recovery plan capability can help you test and iterate fixes to your migration plan. When you enable replication, the data is copied into the ASR Vault. The Recovery Plan controls the order that the replicated data/machines are spun up into an Azure VM.

In addition to the steps above, the following diagram nicely illustrates the steps Microsoft recommends to migrate an on-premises application to Azure using ASR. You will need to have LRS or GRS (redundant) storage and a Site Recovery Vault under your Azure account, and both should be deployed in the same region. Next you will need to create your network topology and then use recovery plans to perform migration tests.

Source: Microsoft

For more information on the prerequisites and exact steps required to migrate using ASR, take a look at this detailed Azure documentation.

Final Note

Over the last few years, the huge investments made in cloud infrastructure have enabled a new world of hosting options that make deploying a VM to the cloud more manageable than ever before. When migrating VMware to Azure, several migration paths and approaches can be considered, with each having its advantages and disadvantages.

Moving VMs to the Azure cloud provides enterprises with a huge range of scalability and redundancy options. Tools like Azure Stack enable scaling when and how enterprises need it.

cloud, cloud migration, microsoft azure, tutorial, vmware

Published at DZone with permission of Jeremy Hess , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}