Sashkin - Fotolia
We have all heard stories of VM creation run amok, where the end result is an overabundance of virtual machines. One of the side effects to this problem can be that the virtual machines may outgrow the cluster on which they reside.
Regardless of whether you are using Hyper-V or VMware, there are both physical and practical limits to the number of virtual machines (VMs) that can exist within a cluster. Physical limits are those limits imposed by the hypervisor vendor. Practical limits exist because of your hardware. For example, a hypervisor vendor might claim that you can host 4,000 VMs on a cluster, but your hardware may limit you to hosting a few hundred VMs.
Explosive VM growth has led a number of organizations to create multiple host clusters. In some cases these multiple clusters exist as a way of overcoming the limits of a single cluster. In other situations, clusters are used as an easy way of creating service tiers. For example, an organization might have a gold, silver and bronze cluster, each of which contains varying hardware. Whatever the reason for creating multiple host clusters, there will eventually be a need to migrate a VM from one cluster to another.
There are a number of different ways to perform a cluster-to-cluster VM migration. Depending on how the network is configured, a traditional live migration might work just fine. Of course, there is also the old export/import method, although that requires taking the VM offline.
One method that is often overlooked is the VM replication method. Hyper-V and VMware both have a replication engine, but let's take a look at how this process works in a Hyper-V environment.
Hyper-V replication is often talked about in terms of being a low-cost alternative to failover clustering. In actuality, however, replication can be used in conjunction with failover clustering.
For those who might not be familiar with the Hyper-V replication feature, it was introduced in Windows Server 2012 as a way of allowing administrators to create offline copies of VMs.
In a non-clustered environment, Hyper-V replication allows a copy of a VM to be created on a secondary Hyper-V host. An asynchronous replication process periodically synchronizes any modified storage blocks within the VM to the replica. The idea behind doing so is that if a host server were to fail or if a VM were to become otherwise incapacitated, then the replica VM can take over.
There are a few important differences between replication and failover clustering. First, clustering is intended to be a high availability solution, while replication is not. Although you can "fail over" to a replica VM, the process is not automatic. It must be initiated by the administrator.
Another important difference has to do with storage. Although Windows Server 2012 eliminated Hyper-V's dependency on shared storage, most clustered environments continue to be based on the use of shared storage. The idea is that all of the hosts within the cluster share a common storage device.
On the other hand, replication works differently. VM replication copies storage blocks from the source host to a destination host. Hence, there are two complete copies of the VM on two separate storage devices. It is this redundancy that makes replication an attractive option for cluster-to-cluster migrations.
The reason why Hyper-V replication can facilitate a cluster-to-cluster migration is that the replication feature is not limited to being used solely on standalone hosts. Hyper-V clusters can also make use of the replication feature. You can't replicate a VM between cluster nodes (there would be no point), but you can replicate a VM to another host outside of the cluster. You can even replicate a VM from one cluster to another.
With that said, there are two tricks to using Hyper-V replication for a cluster-to-cluster migration. The first trick is that you have to enable the Replica Broker. The Replica Broker is a Hyper-V component that allows the replication feature to work in conjunction with failover clustering. It is an essential component and must be enabled on both the host and the destination cluster.
The other trick is to perform a planned failover. The basic idea here is that you would enable replication for a VM that is running on the source cluster. That VM is replicated to the destination cluster. Once VM replication is enabled, it will take some time for the initial synchronization process to complete. You can speed things up by using an offline copy of the VM for the initial synchronization.
Once the VMs are completely synchronized, you will need to perform a planned failover. A planned failover causes the replica VM to become the primary. When you perform a planned failover, Hyper-V will ask you if you want to reverse the replication direction. If you choose to do so, the VM that originally served as the primary will become the replica. Your new primary (which now exists on the destination cluster) will transmit copies of modified storage blocks back to the other cluster as a part of the ongoing replication process.
Of course, if your only goal is to migrate the VMs, then you can simply disable the VM replication process after you have performed the planned failover. You can then delete the original VM copy from the source cluster.
One last thing that you need to know about this process is that it does require the VM to be taken offline during the planned failover. However, the failover process usually happens quickly, so the interruption is normally very brief.