Migrating Workloads onto VSAN

Recently, I have been engaged in multiple deployments for customers trying to move out from their traditional datacenters to a VMware-based hyper-converged infrastructures. HCI and especially VMware VSAN brings a lot of benefits to customers such as:

  1. Simplicity to deploy and manage.
  2. Bridge the gap between virtual infrastructure administrators and storage admins.
  3. Ease of provisioning and management through a single pane of glass as the virtual infrastructure.
  4. Ability to change the availability, protection and performance profile of workloads on-the-fly via Storage Policy Based Management (SPBM) framework.
  5. Ability to easily scale up/out on-demand.

And off course, the most question they ask is how we are going to migrate workloads to VSAN with the minimal introduced downtime to their production line of business. In this blog, we are going to talk about the different available ways to perform the migration and the relevant use cases for each one.

The following table summarizes the common methods that can be used to perform the migration. We will then demonstrate briefly each one.

Backup:

  • This method requires some sort of a backup server so that you backup the VMs running on your VMFS datastores and restore them to the VSAN datastore.
  • It may require hardware for the backup server if you are running a tape system.
  • There is downtime as you have to shutdown your VMs, back them up and then restore them to VSAN datastore where you can validate and test prior to powering them up if everything is OK. Otherwise you can just failback to the original VM and leave the restored VM down if the backup and/or restore fails or is corrupted.

XvMotion:

  • There is no hardware requirement for this option as a VM will be migrated between different clusters with separate vCenter servers across network which can be either a LAN or a WAN. Obviously, it can be a migration between an on-premises datacenter and AWS cloud across WAN.
  • Depending on the amount of bandwidth between the sites, the vMotion can be fast or slow.
  • There is no downtime for this migration and neither a way to test ahead as no copy of the VM will reside in the original datacenter after the migration.
  • You can do a failover simply by doing a migration back in the opposite way.
  • Cross-vCenter and long distance vMotion features do require an enterprise plus vSphere licensing.
  • Have a look at this helpful Cross-vCenter vMotion fling for doing so:  https://labs.vmware.com/flings/cross-vcenter-workload-migration-utility

SvMotion:

  • At least one ESXi node in the VSAN cluster should have a HBA adapter so that you can connect it to the SAN fabric of the traditional storage and configure proper zoning. This host will then have access to both the traditional VMFS datastores as well as the VSAN datastore.
  • After this configuration is done, you can perform a storage vMotion of the VMs from the traditional VMFS datastores to the VSAN datastore and register them with the new vCenter before powering them up.
  • There is no pre-test that you can do prior to SvMotion but you can failback by simply doing a storage vMotion from the VSAN datastore back to the original VMFS datastore if any test fails after the migration.

VR:

  • You need to spin up a vSphere Replication Appliance on the VSAN cluster and configure VMs on the traditional cluster to replicate to it. Once replication is done, you can shutdown the original VM and power on its replica on the VSAN cluster so that you can test if everything is OK before going production. As you can see, there is an introduced downtime here.
  • Of course you can failback as you can simply leave the replica VM down on the VSAN cluster and then power on the original VM on the original datacenter.
  • vSphere replication is available with vSphere Standard licensing and above.

VR + SRM:

  • For bulky migrations, you can spin up one SRM VM per site with vSphere replication in place where you can orchestrate the failover of the VMs from original site to the VSAN cluster after all data is replicated.
  • With SRM, you can configure the VMs to power on at the Recovery site (VSAN cluster) in the required startup order.
  • You can do a test failover so that you run the migrated VMs on VSAN cluster in an isolated environment, validate and make sure everything is good, then perform the actual failover scenario to power the original VMs down and power them on the VSAN cluster. There is downtime as well during the actual failover scenario.
  • You can pre-test the migration and do a failback if anything went wrong during the process.
  • SRM is an add-on which should be purchased separately.
  • This method provides the best way to do the migration in a nice orchestrated fashion.

Again, every method has its pros and cons but depending on your vSphere licensing model, your infrastructure available hardware, your amount and size of workloads, inter-site connectivity bandwidth, and how much you can accept a workload downtime, you can select the best way to perform this migration.

Hope this post is informative,

Mohamad Alhussein

1 Star2 Stars3 Stars4 Stars5 Stars (2 votes, average: 4.50 out of 5)
Loading...