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.
1. Manual Upload of VHDs
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.
- Positives: It is a free method.
- Negatives: There is a lot of manual effort involved, making the solution not actually free (effort is not free), and prone to error. There is also a huge amount of downtime due to the out-of-band method of uploading the virtual hard disk(s).
2. Azure Site Recovery
Azure Site Recovery (ASR) is Microsoft’s solution for orchestrating and providing disaster recovery services in the public cloud. Currently it offers:
- Hyper-V-to-Hyper-V replication and failover orchestration between two non-Microsoft locations
- vSphere-to-vSphere replication and failover orchestration between two non-Microsoft locations
- Hyper-V-to-Azure replication and failover orchestration between a customer site and Microsoft Azure
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:
- An orderly shutdown of all replicated on-premises VMs
- Any data that has not been replicated is flushed to Azure to update the replica VMs
- The VMs are powered up, in order, in Azure
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.
- Positives: The downtime is minimized. The small amount of downtime is required to maintain consistency for the required asynchronous replication (for latent network connection). The switch-over is a big bang, and the one-click process even allows for testing.
- Negatives: You have to deploy a disaster recovery solution to move VMs to the cloud. This is a big bang solution, so you might require several smaller bangs to see progress. This is possible with some planning and engineering effort. You need System Center Virtual Machine Manager installed and configured on-premises to manage your Hyper-V farm, which is often an expense that many SMEs cannot afford. There is a significant per-VM monthly cost for implementing replication using ASR. The solution is currently limited to Hyper-V virtual machines.
ASR can give a very nice and currently supported solution to move VMs to Azure. But something better is coming.
3. Migration Accelerator
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:
- Hyper-V VMs
- vSphere VMs
- Amazon Web Services (AWS) VMs
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.
- Positives: Did I mention MA is free? At least, the preview is. This solution works for Hyper-V, vSphere and AWS, giving customers near-zero downtime migrations to Azure from any major platform.
- Negatives: The MA preview has only started, and it is limited to the USA regions.
4. Microsoft Virtual Machine Converter 3.0
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.
- Positives: This is a free tool. It offers PowerShell so it is perfect for orchestration and self-service.
- Negatives: It is limited to vSphere. This product is the supported solution right now, but MA will eventually replace it as a to-Azure migration service.
5. Third-Party Tools
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.