In the first installment of this article series, I explained the pressure and challenges that exist when moving virtual machines (VMs) to a cloud, such as Microsoft Azure. In the final part of this article series, I will discuss a number methods you can consider for migrating your virtual machines into Microsoft Azure.
Microsoft Azure was originally designed for developers by developers. Those Microsoft developers had a view of the world where everyone was using Software-as-a-Service (SaaS), where Infrastructure-as-a-Service (IaaS) was no longer needed. Years of disappointing sales proved Microsoft wrong, and IaaS was added to Azure, which has helped it mature at an incredible pace. But a lot of the concepts are still developer focused.
One of these features is the ability to upload a virtual hard disk (Azure only supports Hyper-V Generation 1 virtual machines with VHD format disks) with a generalized operating system (Sysprep for Windows). You can then create an image that appears in the gallery for your deployments. The idea here is that you’re creating an application server and you need tens, hundreds, or even thousands of instances of this VM that you can rapidly provision and scale-out services with. This is one of those things that a cloud, such as Azure, does really well.
You can do something similar with an existing one-off VM, but it requires quite a bit of work. You won’t want to generalize this VM and this is what introduces the work; you will need to prepare the guest OS and VM configuration prior to uploading the virtual hard disk(s) to Azure – this is work that is done when Azure deploys a generalized image. Once that work is done, you can shut down your production VM and upload the virtual hard disks (VHD format only, so you will need to convert any VHDX files) to a storage account in Azure. The disk(s) will be available in Azure to be used to create an Azure VM, which lets you reuse the formerly on-premises storage (containing OS, services, and data) and thus get an almost identical copy of the VM running in the public cloud.
Azure Site Recovery (ASR) is Microsoft’s solution for orchestrating and providing disaster recovery services in the public cloud. Currently it offers:
It’s that last scenario that is of interest. We can use ASR to replicate running VMs (using Hyper-V Replica’s asynchronous replication) from an on-premises Hyper-V host/cluster to Azure. Azure then becomes a virtual disaster recovery site in the public cloud, offers orchestration, and one-click business failover. We can use that failover as a stretch quick migration to move VMs from on-premises to Azure with very little downtime.
Once configured by ASR, Hyper-V Replica use asynchronous replication to first copy VMs to the cloud and then keep them in near-synch (up to 15 minutes variance). This is all done in the background while the VMs are running. We can create an orchestration in ASR to fire up VMs in a specific order, modeling their application, service, and data dependencies. Then we can perform a test failover, verifying that services will function as required. Any required modifications, such as logical network to Azure virtual network mapping, can be completed and verified, and then a planned failover can be done. This process is:
The process of using ASR to migrate virtual machines to Azure [Source: Microsoft]
Downtime is minimized to anywhere from seconds to a few minutes, depending on the size of the environment and the amount of chance required.
ASR can give a very nice and currently supported solution to move VMs to Azure. But something better is coming.
Microsoft acquired a company called InMage in 2014. InMage made products that offered business continuity by replicating them to the cloud. Microsoft has used this portfolio in a few ways to supplement their Azure services. ASR has been extended with InMage technology to expand the replication functionality of the disaster recovery solution. But Microsoft recently launched a preview of a new service called Migration Accelerator (MA) that is based on InMage’s Scout product.
The Azure Migration Accelerator currently in a preview that is limited to Azure data center regions in North America, which allows customers to migrate the following to Azure:
Oh no! MA isn’t restricted to moving workloads on Microsoft’s on-premises platform. By using MA, you can also migrate VMs running on Microsoft’s on-premises and public cloud rivals’ platforms to Microsoft Azure.
The solution will work on a per-machine basis, similar to ASR. You deploy a Scout service on the source infrastructure, and it will allow you selectively synchronize your VMs to Azure. When ready, you can flip any of the VMs over with a minimum of downtime. This is a very nice concept, and it is the solution that customers need.
Since version 2.0 of this free product, you have had the ability to convert vSphere VMs into Azure compatible virtual hard disks for upload into Azure. The tool offers a GUI for a few here-and-there migrations, but it also offers PowerShell for larger migrations and self-service migrations with the help of System Center Service Manager.
There are plenty of third-party software vendors out there that currently offer a solution to migrate VMs into Azure. They will work similarly to MA, but at a princely price. Take a wander around the exhibition hall of a Microsoft- or cloud- related conference or hit your favourite search engine to find such products.
Migrating your workloads to another platform across a latent network connection is not as easy as a vMotion or a Live Migration. But with the right tool(s), and with appropriate planning, you should be able to limit the pain and restrict the perceived downtime to business systems. I think Migration Accelerator is the perfect answer, but it is still in a preview that is limited to the US regions of Azure. Given time, it could be the solution we need to move to Azure from Hyper-V, vSphere, or AWS.