• Admin

vSphere Data Center Migration

Updated: Feb 15, 2018

I often get asked the different methods to migrate from one datacenter/environment to another from a vSphere perspective. This is generally to create a new datacenter in a co-location or office.

I ask the general questions such as how many VMs, size, how much time given to migrate, types of applications and bandwidth available on the connection (and making sure it's not saturated!). Does the application need 24/7 uptime or is there maintenance windows available to do switch overs, this will generally define what can be used.

Some of the options available are as follows

  1. Backup & Restore - vSphere Replication

  2. vMotion (Compute and Storage)

  3. SRM (With vSphere Replication or SRA's)

Backup & Restore - vSphere Replication

The backup and restore option can be used to restore a VM's disk files and then create a seed in the remote (target) site. vSphere replication can be then be used to look at the target datastore and use the restored files as replication seeds when replication is configured. vSphere replication compares the source and target sites and replicates only the changed blocks. The benefit here being the bulk of the heavy lifting happening with the backup/restore.

If bandwidth is adequate VMs can be replicated directly from source to target without any backup/restore required. This will create the initial shadow and then synchronize the changes in the same way as above.

There are some pre-requisites, the source and target sites must be connected. Users at both sites must have VRM remote > Manage VRM privilege assigned. It supports both sites being in the same SSO domain or sites in different SSO domains by registering the target site with the PSC on the target site. Details can found here.

I am always surprised how many people are not aware that with their vSphere license they have the option of running vSphere replication. In my mind this is a great tool that helps with general DR/BC but also very useful for the purpose of migrations. I also like how it's independent of the underlying storage platform e.g. replicate from storage vendor A to target site that has storage vendor B.

vMotion (Compute and Storage)

With vSphere Enterprise Plus customers are entitled to leverage Cross-vCenter and Long Distance vMotion. There are a few pre-requisites required. You will need the source and destination vCenter and ESXi hosts to be running version 6.0 or later. With the vCenter web client both vCenter's must be in enhanced linked mode and in the same vCenter SSO domain. Both vCenters must be time synchronized with each other. Details can be found here. It is also recommended to have a different TCP/IP stack to isolate traffic as per here

For Cross vCenter and Long Distance vMotion there will need to be a L2 stretched network in place as IP's will not be changed during migration. There will also need to be a RTT of less than 150 milliseconds. Details here

SRM (With vSphere Replication or SRA's)

Site Recovery Manager provides the ability to create orchestrated "recipe" for DR testing and failover. It's great at allowing you to test the DR plan on a weekly, monthly or quarterly basis. SRM is controlled by both protection groups and recovery plans. SRM can work with storage replication adapters (SRA's) that connect into supported storage array replication.

The compatibility guide lists supported SRA's for SRM that shows quite an exhaustive list. The guide can be found here

SRM can also leverage vSphere Replication to handle the block copy, you can also have a combination of both SRA's (for full LUN replication) and then vSphere Replication for individual VM replication in conjunction with one another. With standalone vSphere Replication VMs can be recovered manually 1 by 1. In a larger environment having SRM is invaluable as you have pre-tested the recovery including start up steps and leverage protection groups that can add control over application groups and consistent state of recovery. All this is automated in a pre build cookbook.

One of the use cases for SRM is data center migrations, with an example of a known disaster being predicted (think a hurricane) and the need to bulk migrate in a controlled "ahead of time" state. Using SRM we can do a planned migration and bring the workloads up on the remote site. For a DC migration this would work very well to quickly get the new environment up and running in the new environment.