Basic Workload Migration Strategies for VMware Cloud Foundation
So the day has come, your organization has deployed VMware Cloud Foundation and now its time to migrate your existing workloads over to the new environment. Before we start to move the workloads, there needs to be some planning involved. Some of this process will involve creating workload profiles to ensure each workload is properly handled, has the correct security policies and many other tasks. These tasks are critical to success down the road and although some seem to forgo this process, it is one we suggest not to take lightly!
Once workload profiles have been created, and policies have been planned, we can start looking at the different options to get our workloads migrated over. VCF is currently only intended as a greenfield installation, this means VCF will create a new vSphere infrastructure, which would also include a new SSO domain, which means we need to find a way to move our workloads between the existing vSphere environment and the new VCF environment.
There are a few options here, namely three options that we will briefly discuss below.
Live Migration, Warm Migration, and Cold Migration are the different methodologies we can use.
Let's briefly discuss each one, some of the benefits and some of the cons of each.
Live Migration, which is also referred to as a "hot migration" or "vMotion migration" has the ability to move the workload in real-time with no downtime. This option is great for mission-critical applications that from a business perspective must remain up at all times. The VM is not powered off and the IP address will not change.
Before we can decide to go with the live migration route, we need to first consider network connectivity. In this case, the migration target must be in the same L2 subnet. This may require stretching the subnet between the old and the new environments and may not be feasible in some cases.
Warm migration provides perhaps the most flexible option. During a warm migration, the VM will remain powered on while the data syncs between the source and destination. Once the sync has completed the VM will be powered off and therefor can be re-addressed. The VM would then be powered back on and life is good! The downtime for a warm migration is typically short. Generally, this is something that can easily be planned around because the workload is only down for a few minutes, so the migration can take place during a maintenance window.
During a cold migration, the VM is powered off during the entire migration process. As far as how long the VM is down would depend upon the size of the VM, transport speeds and other factors. Again, with Cold migration since the VM is powered off, we have the ability to re-address the VM if required.
As time goes one, we will dig a little deeper into the details, including using HCX as a migration tool between clouds.