IT Challenges:
Migrating from one datacenter to another is never an easy challenge especially when downtime must be minimal. There are a few tools I have access to that could have been used to get the job done. These are VMware SRM, Veeam Backup & Replication, and Zerto Virtual Replication.
First, let’s take a look at the old datacenter. There are two separate clusters. One is running vSphere 5.0 and the other is vSphere 5.5. Since I am building out a new datacenter and looking to use vSphere 6.0, using SRM was really out of the question. On the storage side, there are multiple NetApp FAS arrays. I could use Veeam, but I am looking for a very low RPO which can be a bit difficult to pull off as constant snapshots can impact application and storage performance. Zerto offers a low RPO and does not use snapshots. This sounds like a very good use case for Zerto. Unfortunately, this is not the case and I know from experience. In the past, I tried replicating a Microsoft 2012 R2 RDSH environment using Zerto and it failed miserably. I can’t completely blame Zerto for the failure. The issue was with the seeding process causing the RDSH servers so much latency when reading the VMDK’s from the NetApp, that it was not possible to seed without impacting users. Sure, you can preseed, but I still need to copy the entire VMDK to another storage device. Plus I had a very short timetable to complete this project and over 350 VMs to move.
Tintri ReplicateVM for the Win!
I already had some experience with Tintri’s ReplicateVM and it is fantastic. And since we are building out a new datacenter, this was a good time to purchase new storage. At a very high level, my plan was to purchase a Tintri VMstore T850, get a loaner T850, replicate all VMs, and perform the migration. Sounds pretty simple, right? Well, nothing is ever quite that easy, but with a little engineering, this was a project I was eager to start.
Step one, procuring the storage. Luckily Tintri is an excellent company and always willing to help out. When I explained my plan, getting a loaner to use as a swing system was not an issue. After the loaner was installed, I started to Storage vMotion all the VMs to the Tintri datastore. This took approximately a week given the number of VMs and performing most migrations after hours.
Step two, replicating all the VMs to the T850 at the new datacenter over a 1Gbps link. I decided to use a default protection policy applied to all VMs using an hourly schedule replicated every 15 minutes. Meaning it would start at 5 minutes past the hour and replicate every 15 minutes. I didn’t actually time how long the initial seed took, but it was less than two days to replicate 16TB of data. This is by far the fastest replication I have seen when compared to other storage vendors or products such as Veeam and Zerto. Best part, absolutely no performance impact to either environment!
Now for the fun part. As I mentioned, I won’t be using SRM. So some PowerShell automation will be required. Using RVTools was a great way to capture all the VM information I needed and save to a CSV file. The first part of the script was just a simple VM shutdown, but I added a loop to confirm the VM was shut down before proceeding to the next step. The next two steps use the Tintri Automation Toolkit. First, it would connect to the source Tintri and pause the VM replication.
foreach ($item in $vmlist) {
$vmname = $item.vmname
Suspend-TintriVMReplication -Name “$vmname” -TintriServer $SourceTintri -Verbose}
Next, the script connected to the destination Tintri to perform a “restore” of the VM. There is also a cloning option that I will explain later.
foreach ($item in $vmlist) {
$vmname = $item.vmname
$destination = $item.destination
Restore-TintriVM -Name “$vmname” -DestinationDirectory “$destination/$vmname” -UseLatestSnapshot -TintriServer $DestTintri -Verbose}
Using the restore option does not register the VMs in vCenter, so I added a section to my script for registering, updating, and powering on the VMs.
foreach ($item in $vmlist) {
$vmname = $item.vmname
$filepath = $item.filepath
$vmx = $item.vmx
$vmhost = $item.vmhost
$pool = $item.pool
$folder = $item.folder
$network = $item.network
New-VM -VMFilePath “$filepath” -Name $vmname -VMHost $vmhost -ResourcePool “$pool” -Location “$folder”
Get-VM -Name $vmname | Get-NetworkAdapter | Set-NetworkAdapter -NetworkName “$network” -Confirm:$false
Start-VM -VM $vmname}
Once completed, all VMs were in their correct resource pool, folder, networking was configured, and VMs powered on. There was a bit of trial and error in the beginning, but the outcome was a single script that worked perfectly for the datacenter move.
So why did I go with the restore option instead of cloning? For one, simply to keep the Tintri UI nice and clean. Instead of having the replicated VM and clone listed in the UI, the restore command makes the replicated snapshot available. More importantly, I wanted to keep all the VMs identical to the originals including the UUID and MAC. For Windows, this meant no needless re-activations and also the ability to restore domain controllers without any issues.
For more information about Tintri’s ReplicateVM, visit https://www.tintri.com/resources/productinformation/replicatevm-data-sheet.
Recent Comments