The Technical White Paper SRM 5.0 Performance and Best Practices can give you a good starting point .
One of the topics I see a lot of discussion about is the location of vSphere swap files on a non-replicated datastore.
If you think about this concept why not also configure the guest swap file (aka page file) on a non-replicated datastore ?!
As you know the data on swap files are lost during reboots and power off.
So it’s useless during a recovery as the VM will be power on again on the recovery site and the swap files will be populated with new data from scratch.
So, placing the swap files on a non-replicated datastore would make sense.
Some benefits of this approach are:
Since you will have less data to replicate you will conserve some bandwidth on your link.
In some environments the replicated datastore could be more expensive than non-replicated datastore, allowing you to save some $$$.
Faster recovery and tests, as there’s no swap file to be replicated this step is skipped.
But it also has some downsides.
It’s a bit more complex to manage, since not all VM’s files are on the same replicated datastores.
Changing the swap file to a single datastore create a single point of failure for all your VMs, you should carefully evaluate that.
Windows assigns volumes letters to disks based on the signature of the disk, it could be trick to make Windows recognize the page-file disk after you recovery it.
Ok, let’s focus on how to do that.
• vSphere swap file.
- change the cluster settings, so the swap file location will be specified by the host.
- on the host settings, change the swap file location to the non-replicated storage.
You would need to change it on both vCenters, Protected Site and Recovery Site.
• Guest Page-File
On Protected Site
- create a new vmdk file for the VM on a non-replicate storage
- using the VM format the new disk
- change the page-file location the new disk.
On Recovery Site
- Copy the new VMDK from the Protected site to the Recovery Site to a non-replicated storage.
- Change the Placeholder VM to point the secondary disk to the disk you just copied.
As I’d like to say there’s no size that fits all.
I’m not saying it should be or should not be the design for your environment, I’m just pointing out the options you have and what the SRM is capable of, it’s up to you evaluate the options, test them on your environment and take the decision which is better for you. ; )
See you next
