Previously we discussed the use of content migration tools to get data into public cloud services. Another alternative is to ship entire virtual machines into the cloud, including the application and data.
Why VMs?
Why would it be more practical to ship an entire VM than just the data? In some instances and with some applications, extracting out the data component of the application is just too hard to do and not worth the effort of re-architecting. Many applications (especially on Windows) have lots of either customisations or local configurations in the Registry that are hard to fully extract and transfer. In many cases, VMs might contain software that takes considerable manual effort to install and configure, so shipping the VM is more practical. There’s also the possibility that VMs are running older software with no original installation material – but these wouldn’t make good candidates for migration.
There are some negatives to consider too. VMs can be big – a standard Windows installation can run to 40GB or more (probably more with W2K16, although I haven’t tried an installation recently). That means transferring a lot of potentially redundant data across the network. At the O/S level, virtual machines (especially those built from a gold master) will have lots of repeated data, so transferring each VM in its entirety is an expensive operation. As we will see, there are also a lot of pre-requisites that have to be considered. Virtual Machines are built to run on top of varying types of virtualisation so different drivers will be needed when moving between platforms. The same also applies to the VM disk format. VMware uses VMDKs on VMFS (or an NFS share), Hyper-V uses VHD(X), while KVM supports a range of formats. Just copying a raw partition between platforms won’t work. Other considerations include networking (use of fixed IP addresses) and licensing.
Public Cloud Tools
The public cloud providers offer a range of tools to take some of the issues out of importing virtual machines.
Amazon Web Services (AWS) offers two services. EC2 VM Import/Export is an offline tool to take existing virtual hard disks and convert them into EC2. The source format can be VMDK, OVA, VHD or raw partition. The transfer process copies the virtual disk as a complete object, so VMs have to be shut down for the copy process. The initial target for the upload is into S3, from where the image can be imported into EC2. The Import/Export tool has a large number of limitations and pre-requisites, especially around non-standard images (e.g. where compression or encryption has been used). There are also restrictions on licensing (Windows, RHEL and SUSE imports need BYOL type licences) and some less obvious restrictions like lack of support for multiple network interfaces.
AWS Server Migration Service (SMS) is a more advanced offering than Import/Export in that it can support live migrations, but is currently limited to imports from VMware virtual infrastructure. SMS uses a local “connector”, running as a VM that integrates into the on-premises VMware platform and acts as the data mover to the public cloud. Virtual Machines appear as AMIs (AWS Machine Images) in AWS that can then be started on EC2. From what I can tell (I have still to try it out), SMS uses VMware snapshots to provide ongoing incremental replication of virtual machines. A single replication can be active for up to 90 days, after which (by default) it is automatically terminated. Presumably, this is to prevent the service being used as a free disaster recovery service. As with the previous tool, there are lots of pre-requisites and limitations, as well as configuration changes to firewalls in order to support the connector VM. Virtual machines require agents and some configuration changes (like paging size on Windows).
Microsoft supports migrations through Azure Site Recovery (ASR), which is primarily a tool for disaster recovery. Virtual machines can be replicated to the public cloud for up to 31 days without charge (again because 31+ days implies a DR, not migration process). The specific requirements of installation for ASR depend on the source of virtual machines. If VMM is used, then the ASR Site Recovery Provider runs on the VMM server. For more simple configurations with individual Hyper-V hosts, the software runs on the host. No specific guest configurations are required. Initial replication is based on a VM snapshot, with ongoing changes tracked through the Hyper-V Replica Replication Tracker until the initial replication is completed, after which the snapshot is deleted. After that, data is kept in sync using only delta changes.
ASR supports replication from VMware environments through a local configuration VM that manages the migration of data and a “mobility service” installed onto each replicated VM. Data is replicated through the local VM from the mobility service on each supported VM. The actual implementation of VMware support looks a little clunky, with the need to create a passphrase on the configuration server that then has to be passed to each VM. Also, running an agent to track changes on a server is prone to error or data loss, if the service crashes or when the VM is being shut down.
Google recommends doing VM migrations with their partner, CloudEndure. Replication is performed at the block level, with an agent required on each server. This has a pre-requisite of Python 2.4 or higher (Linux only). The cutover of running applications requires the application itself to be suspended while the cutover occurs. Again there is that risk scenario of having a running machine kept in sync by an agent that could crash. On the positive side, the CloudEndure software covers the process of making the VM image bootable, which presumably means installing drivers and other components inline as the replication process takes place.
3rd Party Solutions
In addition to CloudEndure, there are 3rd party replication solutions from start-ups such as Zerto, Velostrata and Racemi. VMware also has vCloud Connector as another migration option. We’ll probably cover these in a separate post, rather than turning this one into War and Peace. Note however that the public providers are in general offering free migration tools, whereas the 3rd party solutions are chargeable.
The Architect’s View®
Cloudbursting was always talked about as a way of getting on-premises applications into the cloud. However, the actual process of moving virtual machines is way more complex than it seems. Server virtualisation differences introduce challenges for driver and boot support. Environmental changes like networking, performance and licensing mean a whole range of post-configuration work also needs to be done. As a result, many IT organisations have probably shied away from VM migration, because of the complexity – which has to occur again in reverse if applications are brought back on-premises.
Two things immediately spring to mind. First, we can see the opportunity that Zerto/Velostrata have identified and are exploiting. Second, removing the overhead of the VM and moving to containers simplifies things considerably. That means application migration should be focused on the data, not the VM. That’s a more challenging piece to achieve, with either some re-engineering required or perhaps a more data-focused solution to be deployed. Either way, VM migration seems like a lot of work for little gain, unless the efforts of rebuilding the VM outweigh the migration process.
I’ll close this post with one final thought. Once a VM has moved to the cloud, how is it protected? Will the same backup software be used? If a failure occurs and the backup is still on-premises, how is a restore done? One solution is to do a post-migration backup, but this doesn’t really help when data needs to be restored from some time in the past. This means VM migration also has to be considered in the context of BC/DR and backup, making this a whole level more complex.
Related Links
- What is VM Import/Export (AWS Documentation, retrieved 15 August 2017)
- Azure Site Recovery (Microsoft website, retrieved 15 August 2017)
- Migrating VMs to Google Cloud Platform (Google website, retrieved 15 August 2017)
Copyright (c) 2007-2023 – Post #3D4B – Brookend Ltd, first published on https://www.architecting.it/blog, do not reproduce without permission.