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.
Disclosure: My company does not have a business relationship with this vendor other than being a customer.
The VMStores currently do have Deduplication - on the SSD layer, not the HDD. the addition of iSCSI would be very welcome though - I agree! (although given the architecture, it would be difficult to implement)